Your claims team is already using AI. Can your board govern it?

If you run an insurer or an MGA, there is a good chance someone on your team used an AI tool this week without telling you. Maybe a claims handler pasted a loss description into a chatbot to draft a summary, or an underwriter ran a spreadsheet of risks through a tool to spot the outliers. None of it was sinister, and most of it probably saved them time. The problem is that almost none of it can be answered for at board level, and as of this month, your board is expected to do exactly that.

In May 2026, ASIC wrote to every licensee and market participant in the country with a blunt warning. Frontier AI is making cyber attacks faster, cheaper and more sophisticated, and the basics of cyber resilience are no longer optional. The letter is deliberately model-agnostic, and it leans on principles that have been around for years: govern, protect, detect, respond. What makes it land is the requirement that it be tabled at your board and risk committee, and the fact that ASIC turned up with a recent scalp. It had just secured a 2.5 million dollar penalty against FIIG Securities over cyber failures. Commissioner Simone Constant described where we are as a minute to midnight, which is not language regulators use casually.

APRA was making a similar point at roughly the same time (here is their open letter), from a slightly different angle. Its concern is that financial firms are adopting AI far faster than their risk management and governance can keep up, which creates exposure around bias, weak oversight and data handling. APRA is not asking anyone to invent a new rulebook. It wants AI managed inside the frameworks you already have, with genuine board accountability and proper monitoring of how the technology is actually being used day to day.

Read the two letters together and they are really one message:

The thing the regulators are worried about is not the cleverness of any particular model. It is whether you can see, control and account for what those models are touching.

The risk is the data, not the model

Here is how AI tends to walk into an insurance business. Someone exports a claims file or a bordereaux into a spreadsheet because that is the fastest way to work with it, then runs it through whatever AI tool they have access to, to triage, score or summarise. The output goes into an email or a deck, the job gets done quicker than usual, and word gets around the team. Within a few weeks it has quietly become part of how people work, and nobody decided that on purpose.

Now try to answer the questions a board or an auditor will eventually ask. What data did that tool actually touch? A copy of regulated customer data, sitting outside your core system, on servers belonging to a third party you may never have assessed. Who signed off on using it? Nobody, in any formal sense. Can you reconstruct what the tool did, on which records, and when? Almost certainly not, because there is no log, no version of record, and no audit trail to go back to. That is the real exposure, and it has very little to do with whether the model is any good. The model might be excellent. The trouble is that it is running on data that has already left the one place you control, which means you cannot govern it and you cannot prove anything about it after the fact.

Governable AI needs a source of truth

Both regulators are asking for the same underlying thing, even if they phrase it differently. ASIC wants evidence that your controls actually work, not just a list of activity. APRA wants to see how AI risk is being assessed and managed in practice. Neither of those is achievable unless the data your AI touches lives somewhere you can stand behind.

When policy, billing, claims and accounting all sit on one platform built around a single data model, the picture changes. AI can be pointed at the core under controlled, role-based access, with every action recorded. You can see who ran what, against which records, at what time, and you can pull the audit trail when a regulator or auditor asks for it, because the system was keeping one all along. That is what governable AI looks like in practice, and it is a fairly ordinary thing to ask of a modern core platform. When the same work happens on exports and spreadsheets, none of it holds. You lose the access controls, you lose the logging, and you lose any reliable record of what happened.

I want to be honest about the limits of this argument, because a core platform does not solve AI risk on its own and nobody should pretend otherwise. What it does is fix the foundation. AI risk management is a data governance problem before it is a modelling problem, and data governance is a system-of-record problem first. Get the foundation wrong and every AI project you build on top of it inherits the same weakness.

Every AI tool you add is another third party

There is a second issue worth naming, because ASIC calls it out directly. Entities are told to actively manage third-party risk, particularly where a service introduces concentration or systemic exposure. Every AI tool bolted onto an aging core is, in practice, a new third party. It often handles sensitive data, it was frequently approved by no one in particular, and once you multiply it across claims, underwriting, finance and operations, you have assembled an AI supply chain that your board has never reviewed and probably does not know exists. The logic runs the other way too. The fewer places your data lives, the fewer doors there are for AI tools to open into it, and the shorter the list of vendors your board has to stand behind when someone finally asks.
What to do before this reaches your board


You do not need a new framework for any of this, and you should be a little suspicious of anyone who tells you that you do. Start by taking an honest inventory of where AI is already being used across the business, including the quiet, unofficial uses in claims and underwriting that never went through any approval. Most leaders are surprised by how long that list turns out to be once they actually go looking. From there, map the data each of those tools touches and where that data really sits, and put your attention first on anything running on exports outside your core, because that is your largest blind spot. Then bring AI and technology risk into your risk appetite and business continuity planning explicitly, rather than treating it as a footnote, and keep AI and cyber resilience on the board agenda as a standing item instead of a one-off that gets discussed once and quietly filed away.

None of this is about slowing down on AI, and the regulators are careful to say as much. The question they are putting to boards is simply whether you can govern what you have already started using, and for most insurers the answer comes down to something far less interesting than the AI itself. It depends on whether the business runs on one source of truth you can actually control, or on a scattering of systems and spreadsheets that nobody fully owns. So it is worth asking yourself plainly. If your board sat you down today and asked what data your AI touches, who approved it, and whether you can prove how it behaved, could you give them a straight answer?