An underwriter at an insurer gets an update from the vendor of the underwriting system: a new feature sorts applications by risk. That same week, a mortgage adviser asks ChatGPT to make an advice report easier to read, with the client's income and family situation still in it. Two kinds of AI, two kinds of question and one organisation that has to answer both.
That is the heart of AI governance in this sector: there are two layers. One is the AI in the processes themselves, where the AI Act asks whether an application is high-risk. The other is the everyday use of general-purpose tools by advisers, underwriters and claims handlers, where the questions are about tools, accounts and client data. Most organisations focus on the first layer and see little of the second. A workable approach covers both, and our introduction to AI governance explains why it starts with seeing what is there.
Where does AI show up in the business?
At a mortgage lender or insurer, in more places than the annual report suggests.
| Where in the business | What AI does there | Which data | The question that goes with it |
|---|---|---|---|
| Application and intake | Reading application files, writing up meeting notes | Income, IBAN, citizen service number, family situation | Which tool, which account and what goes into the prompt |
| Underwriting and pricing | Triaging applications, estimating risk, setting premiums or terms | Everything in the file, sometimes health data | Is this high-risk under the AI Act, and who oversees it |
| Claims handling | Summarising claims, assessing documents, drafting letters | Vehicle registration, policy, medical information for injury claims | Which data may go in, and is the outcome a decision about a person |
| Client contact | A chatbot on the website, drafting replies, summarising email | Name, file, the client's question | Does the client know they are talking to AI, and what does the employee paste in |
| Back office and reporting | Analysis, summaries, code | Transaction and portfolio data | Which account type, and what is shared |
The second row is the layer the board already discusses. The other four are where most of the use happens, and where usually nothing has been decided.
When is an application high-risk?
Under the heading of access to services such as credit and insurance, Annex III of the AI Act lists two applications that affect this sector directly: systems that evaluate the creditworthiness of natural persons or establish their credit score, with an exception for fraud detection, and systems for risk assessment and pricing in life and health insurance. Mortgage underwriting is, at its core, a creditworthiness assessment. A system with that purpose is in principle on the list.
Two caveats. The test is the intended purpose of the system as the provider has defined it, and whether your organisation actually deploys it that way; that has to be assessed system by system. And Article 6(3) contains a narrow exception for systems that do not materially influence the outcome of a decision, but it does not apply to systems that profile people. Our article on when an AI application is high-risk sets out what the exception does and does not cover. Motor and home insurance are not on the list; a system that assesses claims is therefore not automatically high-risk, but it makes decisions about people, and the GDPR applies to those.
An organisation that uses such a system is a deployer under the AI Act. From 2 December 2027, that brings a list of duties: use the system in line with the provider's instructions, assign human oversight to people who can intervene, monitor how it performs and inform the people affected. The Digital Omnibus moved that date and it may move again; the AI Act for employers sets out what applies now and what comes later. The same tool can be low-risk in one deployment and high-risk in another, as our article on whether one AI tool can be both explains.
What about everyday use?
The second layer rarely reaches the boardroom, yet that is where most of the use happens. An adviser writes up a meeting note in ChatGPT. A claims handler asks an AI tool to summarise a claim. That is usually not high-risk, but three other things do apply.
The GDPR, because almost every prompt contains client data, and in a free account without a data processing agreement that is a data breach. Article 4 of the AI Act, which since 2 February 2025 has required measures on AI literacy: employees need to know what does and does not belong in a prompt. And the duty of care that the Dutch financial regulators, the AFM and DNB, look at: handling client data carefully is part of it, and a tool nobody has made a decision about does not fit. Since 2 August 2026 the chatbot on the website adds one more requirement: clients must know they are talking to AI. AI in financial services explains how that plays out for a regulated firm.
DORA adds a layer that is often overlooked: the AI services employees use are third-party ICT services, and a service nobody knows about does not appear in any register.
What does a workable approach look like?
It starts with knowing what is in use, in both layers. For the processes, that means recording for each system the intended purpose the vendor has specified, the data that goes in and an owner. For everyday use: which tools people actually open, how often and on which account. You cannot build that second list with a survey; it changes every month. Both belong in one AI register, with a column that says whether an entry is process AI or an everyday tool.
Then a decision for each row. For the underwriting system: high-risk or not, who oversees it, which DPIA applies and what the vendor has to provide. For the tools: one of four statuses, with a one-sentence condition for "Limited use" and a named alternative for "Not allowed". Every row starts with the status "No decision yet", which is an honest interim position, not a failing.
The decision then has to reach people when it matters, not sit in a policy document. Suppose an insurer puts this in place. After three months, the underwriting AI has an owner and a DPIA, Perplexity is set to "Limited use" with no client data in queries and the free ChatGPT account is set to "Not allowed", with Copilot as the alternative. What does not happen: nobody has a tool cut off, and nobody is called to account for their use. The figures do the work: the share of use through allowed tools is the yardstick, and tools without a decision whose use is growing go to the top of the list for the next review.
BeeSensible matches a catalogue of over 1,000 AI tools against the use it observes in the organisation, with no user ID in the usage data. In the Inbox, an admin sees which tools have no decision yet and records one; the decision appears in the browser when someone opens the tool, and the dashboard shows aggregated figures on what happens next. It does not see your vendor's underwriting system; that goes into the register through procurement.
