When I tell colleagues that effective AI governance creates legal certainty — and through that certainty, the room in which AI potential can actually be realised — the reaction is usually a polite pause. The phrase sounds counterintuitive. Governance is supposed to slow things down, not speed them up. To filter, not to enable.
That framing is wrong. And the next twelve months will demonstrate why.
The deadline most insurers are still treating as theoretical
The EU AI Act took effect in August 2024. The first obligations — AI literacy and the prohibition of certain practices — became applicable in February 2025. General Purpose AI provisions followed in August 2025. The Digital Omnibus for AI, currently working its way through the European institutions, may shift parts of the high-risk regime. But it does not shift everything.
Transparency obligations under the AI Act become applicable in August 2026. That is three months away. They apply regardless of where the Digital Omnibus lands. Any insurer running customer-facing AI — a chatbot, an automated claims acknowledgement, an underwriting decision support tool — needs to be ready to disclose its use. Not in 2027, when the standalone high-risk provisions kick in. Now.
In conversations across the German insurance industry, I keep hearing the same assumption: that the next real deadline is December 2027, when Annex III high-risk obligations become enforceable. That assumption is incorrect. The next real deadline is August 2026. Organisations that start preparing now will manage. Those that wait will not.
Why a compliance filter at the end of the process fails
The reflex when new regulation arrives is to build a compliance check at the end of the pipeline. A gate before deployment. A review board that signs off. A checklist that gets ticked.
This works for low-volume, slow-moving topics. It does not work for AI.
AI development inside a large insurer is not a single annual project. It is a continuous flow of proofs-of-concept, experiments, vendor evaluations, third-party tool integrations, embedded model deployments. By the time a system reaches a compliance gate, the architectural decisions that determine its risk classification have already been made. Walking those decisions back is expensive. Often it is impossible. The only realistic option is to wave the system through with reservations — which is precisely the failure mode regulators are watching for.
Governance as a design principle works differently. It enters the conversation at the moment a business unit first considers an AI use case. It shapes how the requirement is formulated, which data sources are considered, which architecture is chosen, whether the system can be designed to fall outside the high-risk category in the first place. By the time the project reaches what would have been the compliance gate, the substantive decisions have already been governance-aware. The gate becomes a formality, not an obstacle.
This is not a theoretical preference. At Versicherungskammer, we have currently no AI systems in the high-risk category — not because we avoid ambitious applications, but because we design them carefully from the start. Many use cases that look like high-risk on the surface can be scoped differently: keeping meaningful human decision authority in the loop, separating the AI recommendation from the binding decision, structuring the workflow so the AI augments rather than replaces. These are design choices. They have to be made early, or they cannot be made at all.
Visibility first: the unglamorous foundation
Before any of this design work can happen, you need to know what AI systems you actually have.
This sounds trivial. It is not. In a group the size of Versicherungskammer, AI shows up in research projects, in proofs-of-concept, in procurement processes for third-party tools, in vendor offerings embedded in larger systems, in production. Without a central register, none of this is steerable. You cannot classify risks for systems you do not see. You cannot report to supervisors about what you do not track. You cannot make design decisions for projects that have already been delegated to a vendor.
Our AI register is the foundation everything else rests on. It captures every AI system — at every stage of its lifecycle — together with its risk classification under the AI Act, its mapped business process, the responsible business and technical owners, and links to the documentation generated by adjacent processes such as requirements management and the project lifecycle. It is integrated into the routine processes through which AI systems come into being, so that completeness is not a quarterly exercise but a continuous property of the system.
The discipline of not doing the IT’s job
There is a second failure mode I want to flag, because it is more subtle than the compliance-filter problem and at least as damaging.
AI governance functions, particularly young ones still establishing their scope, often drift into operational territory that belongs to IT. They start selecting monitoring tools. They define statistical thresholds for bias detection. They write incident response procedures. The motivation is good — make sure something actually happens, not just that it is required on paper. The result is bad. Governance loses its regulatory sharpness because it gets entangled in implementation details. IT gets second-guessed in its own domain. Neither function performs at its best.
The cleaner separation, which we have built into our model, looks like this: AI governance defines what must be ensured. IT decides how to do it.
Concretely: governance specifies that AI systems must have mechanisms in place to detect data drift, concept drift, and bias. Governance does not specify which monitoring tool, which statistical methodology, or which alert thresholds apply. Those decisions sit with IT, where the technical expertise and operational accountability are located. The same logic applies across the full range of AI-specific obligations — robustness, cybersecurity, transparency, the documentation requirements that come with high-risk classification or general purpose AI.
This separation is what allows AI governance to remain a small, focused, regulatory-facing function rather than ballooning into a parallel IT organisation. It is also what allows IT to remain operationally effective rather than being micromanaged by people who do not run the systems.
Effective AI governance knows what to delegate.
Three principles, repeated
The argument compresses to three principles, in the order they matter.
Integrate rather than duplicate. Every AI system is, at its core, an IT system. Do not build a parallel governance universe for AI. Use your existing governance for IT security, data protection, and risk management — and extend it for the AI-specific deltas: prompt injection, personal data in LLMs, bias detection. Focus on the genuine deltas the AI Act introduces. Most of the regulatory work is already covered by frameworks you already have.
Governance as a design principle. Not a filter at the end of the process, but a design guideline from the start. Organisations that scope AI initiatives correctly from the beginning avoid unnecessary high-risk classifications and build trust along the way. This saves time, effort, and supervisory dialogue — and accelerates the path to production.
Visibility first. What you cannot see, you cannot steer. A well-maintained AI register is both a compliance artefact and a steering instrument. From proof-of-concept to production. Without it, everything else is theatre.
August 2026 is three months away. The Digital Omnibus for AI will not push that deadline. Organisations that have already started preparing have a working chance of being ready. Organisations that have not, do not.
Many thanks to Juliane Bormann and the team at V.E.R.S. Leipzig for the invitation to present these ideas at their AI Network for the insurance industry, and to the participants for the engaged discussion.