AI Governance for Insurers: Why Data Lineage Comes Before the Model
The board wants an AI plan and the risk committee wants to know where the claims data came from. AI governance for insurers starts with lineage across policy, claims and broker data, so Consumer Duty reports and AI decisions can be explained to the FCA.
The board wants an AI plan by the next meeting. The risk committee first wants to know where the claims data came from. AI governance for insurers starts there: prove the lineage of policy, claims and broker data, then choose which AI use cases that data can safely support.
Key takeaways
- Insurers already use AI widely, yet many firms only partly understand the AI they run, and most of the risks they name are data risks.
- An AI pilot is only as defensible as the lineage of the data feeding it.
- Sort every AI idea by one question: does the output affect a customer? Customer-facing use cases need human review, a written reason and a decision log.
- Build governed pipelines from the policy admin system, claims platform and broker data before any model touches underwriting, claims or vulnerability decisions.
- Start with a low-risk internal use case to prove the pipelines and logging.
Why does AI governance break down in insurance?
AI governance breaks down in insurance because the data under the model has no single owner or lineage. Customer data sits in a policy admin system, a claims platform, broker spreadsheets and a CRM, and each one counts customers differently.
AI use is already common. In the Bank of England and FCA survey of AI in UK financial services, 75% of firms said they already use AI, and insurers led every sector at 95%. Yet 46% of firms said they have only partial understanding of the AI technologies they use. Four of the top five risks they named relate to data: privacy and protection, quality, security, and bias.
None of this is the data team’s fault. Policy admin systems were built to issue policies, not to report outcomes. Each acquisition added a system with its own customer key. Broker data arrives in whatever format the broker uses. AI vendors then assume clean, joined data that does not exist.
Data lineage is the record of where each figure came from, which systems it passed through and what changed it on the way. Without lineage, a Head of Data cannot tell the risk committee why a model scored a customer the way it did.
What does weak AI governance put at risk for an insurer?
Weak AI governance puts an insurer’s Consumer Duty evidence, its UK GDPR position and its supervisory relationship at risk. The exposure grows each quarter as staff adopt AI tools on their own.
The Financial Conduct Authority (FCA) rules in PRIN 2A require firms to monitor customer outcomes and report to the board at least once a year. When the Consumer Duty board report draws on three systems that disagree, the Head of Data cannot sign it off with confidence.
The trigger is often a deadline that collides with a discovery. The board report is due, and nobody can produce one customer view. Meanwhile, claims handlers paste customer emails into public AI tools, because the approved route does not exist yet.
The risks stack up in four places:
- Customer outcomes: a model that scores claims or renewals on unjoined data can treat similar customers differently, with no way to show why.
- Automated decisions: UK GDPR Article 22C requires safeguards for significant automated decisions, including human intervention and the right to contest.
- Accountability: the Information Commissioner’s Office (ICO) expects senior management to own AI risk, not the engineers.
- Third parties: the survey found third-party dependencies are the risk firms expect to grow most, and the Prudential Regulation Authority (PRA) SS2/21 sets expectations for managing that risk.
The ICO is plain about who owns the problem:
“You cannot delegate these issues to data scientists or engineering teams.” (ICO guidance on AI accountability)
The internal politics make it harder. The board wants visible AI progress, the risk committee wants evidence first, and IT is asked to deliver both from the same backlog. A plan that sequences governed data before customer-facing AI gives each group something it can sign off.
How do insurers build AI governance on governed data?
Insurers build AI governance by fixing data lineage first, then assessing each AI use case by its effect on customers. The six phases below take an insurer from scattered data to AI it can explain.
The diagram shows the six phases and the fork at phase 4, where customer-facing AI takes the stricter path.
- Map the data landscape. Run workshops with underwriting, claims and compliance staff, and watch daily work first hand. Outcome: a map of every system and gap, agreed by IT and the business.
- Set standards and owners. Define master data standards, quality rules, a named owner for each data set and integration priorities. Outcome: a plan your teams can follow.
- Build governed pipelines. Ingest from APIs, databases, file uploads and third-party systems. Validation rules catch errors and duplicates, and ISO standards fix dates, currencies and languages. Outcome: one trusted data set with lineage from source to report.
- Assess each AI use case. Ask one question of every idea: does the output affect a customer? Outcome: a risk-ranked backlog the risk committee sees before any model is built.
- Deliver reports and AI with oversight. Customer-facing use cases get human review, a written reason and a log entry for each decision. In internal use cases, staff keep the final say on every recommendation. Outcome: dashboards and models you can explain to the FCA.
- Hand over and train. Provide training, guides and a knowledge base, with repeat training for new starters. Outcome: your staff run the platform.
The delivery method matters as much as the phases. Agile delivery with regular demos, as the GDS Service Manual describes, lets the data team see each pipeline running against real sources before it carries board figures. The AI Playbook for the UK Government offers a usable checklist for assessing AI use cases, even outside government.
Which regulations shape AI governance for UK insurers?
Consumer Duty, UK GDPR, ICO guidance, the AI Cyber Security Code and PRA SS2/21 together shape AI governance for UK insurers. Each one asks for traceable data and accountable decisions.
| Regulation or standard | What it requires | What governed data gives you |
|---|---|---|
| FCA Consumer Duty (PS22/9) | Monitor customer outcomes with data; board report at least yearly | Outcome dashboards fed by pipelines with lineage |
| UK GDPR Article 22C | Safeguards for significant automated decisions, including human intervention | Human review and decision logs on customer-facing AI |
| ICO guidance on AI and data protection | Senior accountability and data protection impact assessments (DPIAs) | Documented data flows and model choices for the DPIA |
| AI Cyber Security Code of Practice | Baseline cyber security principles for AI systems | AI components designed to the Code’s principles |
| PRA SS2/21 | Third-party risk management for PRA-regulated insurers | Third-party AI components documented for the outsourcing register |
The Data (Use and Access) Act 2025 replaced the old Article 22 with Articles 22A to 22D. Model approvals written against the old wording need review.
How do you choose between a vendor AI tool and governed data first?
Choose a vendor AI tool for low-risk internal tasks. Build governed data first for anything that touches a customer decision or a board report.
| Criterion | Vendor AI tool on current data | Governed data first |
|---|---|---|
| Speed to first result | Fast | Slower; pipelines come first |
| Explaining a decision to the FCA | Depends on the vendor | Lineage from source to output |
| Consumer Duty evidence | Only the data the tool sees | Policy, claims and broker data joined |
| Lock-in | High | Low; you own the pipelines |
| Best for | Internal drafting and search | Underwriting, claims and board MI |
Apply these rules to your own backlog:
- If the use case never touches a customer decision, a vendor tool with a DPIA may be enough.
- If the output feeds underwriting, claims or vulnerability decisions, build governed data first.
- If three systems give three customer counts, fix master data before any model.
The original point most AI advice misses is simple: an AI pilot is only as defensible as the lineage of the data feeding it. Fix lineage first, and the model review becomes a short conversation.
When is a governed data platform not the right choice for an insurer?
A governed data platform is the wrong choice when you need one report, or when the source systems are about to be replaced.
- One report: a single monthly report from one system is simpler to build in your existing BI tool.
- Policy admin replacement already under way: pipelines built on an outgoing system get rebuilt. Plan the data mapping as part of the migration itself.
- Fully autonomous decisions: Thornacre does not build AI that decides about customers without a human in the loop.
The governed approach is slower to a first AI output. Risk and data teams must agree owners early, which is often harder than the engineering.
The usual objection is “AI is too risky for a regulated business.” The survey shows use is already happening, often with no logs or owners. Controlled AI reduces that risk; a ban moves it to personal accounts. Each quarter you wait adds unlogged data flows for a future audit to find.
What should a Head of Data at an insurer do first?
A Head of Data should first list every AI tool and idea in use, then mark which outputs touch a customer. That one list shows where governance is missing.
Take these steps this week:
- Ask each team which AI tools they use, including public tools, and what data goes into them.
- Mark each use as customer-facing or internal only.
- Pick one customer-facing use and trace its input data back to the policy admin system, claims platform or broker file.
- Note every break in that trace: a manual export, a spreadsheet step or an unowned table.
The breaks on that trace are your first governance backlog. Bring it to the risk committee before the board asks for the AI plan.
Frequently Asked Questions
Which AI use cases should an insurer start with?
An insurer should start with an internal use case that never touches a customer decision, such as summarising claims notes for handlers. It proves the pipelines and logging with low risk. Use cases that feed underwriting, claims or vulnerability decisions follow once lineage and owners are in place, with human review on every decision.
What does data lineage mean for Consumer Duty reporting?
Data lineage for Consumer Duty reporting means every outcome figure in the board report can be traced to its source system and every change along the way. PRIN 2A requires firms to monitor outcomes and report to the board at least yearly. Lineage lets the Head of Data defend each figure when the board or the FCA asks.
Will AI make decisions about our customers without a human?
AI should not make significant decisions about customers without a human. UK GDPR Article 22C requires safeguards for significant automated decisions, including human intervention and the right to contest. A governed design records a written reason and a log entry for each customer-facing decision, and staff keep the final say on internal recommendations.
Does PRA SS2/21 apply to AI tools from third parties?
PRA SS2/21 sets the PRA’s expectations for outsourcing and third-party risk management, and a third-party AI model or service can fall within that scope. Document each AI component, its supplier, the data it receives and your exit route. Your compliance team then decides how each one sits in your outsourcing register.
Can we keep our existing data warehouse and BI tools?
Insurers can keep their existing data warehouse and BI tools. Governed pipelines publish to API endpoints that feed the warehouse and BI tools, so analysts keep the tools they know. The change is upstream: validated, owned data with lineage arriving where reports are already built.
Where should AI and customer data be hosted?
AI and customer data should be hosted on infrastructure designed to the NCSC Cloud Security Principles, with the hosting region and access roles agreed and recorded for the DPIA. Thornacre’s cyber security service covers the controls in more depth.
How do we start?
Start with a discovery workshop that maps your systems, data flows and AI ideas. You leave with a risk-ranked backlog showing which use cases need governed data first. Thornacre’s data analytics and AI service runs this as its first phase, and CRM and ERP integration covers joining CRM data to the rest.
If your board wants an AI plan and your risk committee wants evidence first, book a data and AI readiness workshop with Thornacre. Email hello@thornacre.com to arrange it.
This article is general guidance only; consult your legal or compliance teams for your specific requirements.