Ask a German insurer which AI systems it runs and the honest answer is usually a shrug with a list attached: a policy-admin release that arrived “AI-enhanced”, a claims-triage pilot in its third extension, an assistant two people in underwriting built to see whether it would work, a feature the broker portal grew, and a handful of Copilot seats somebody put on a card. Not one of those is a bad decision. What they have in common is that nobody wrote them. No submission, no assessment, no file, no owner — and the exposure sits with you exactly as if there had been.
How it got onto your books
Each of those arrived by a route designed to be frictionless, and each of them misses the inventory for a different reason.
The vendor release. Your policy-admin or claims system cleared procurement years ago and grew a summarisation feature in a minor release. The contract was signed before the feature existed and nobody was asked to declare it, because from the outside nothing changed — same vendor, same product name, same maintenance line in the budget.
The pilot. It has a sponsor, a budget line and an end date that has moved twice. Inventories are for production systems, so it sits outside one — while handling real claims data.
The assistant somebody built. Two people wired a model up to draft the first pass of a risk note. It is not a product, so it has no product owner, and it is not a project, so nobody ever closed it out.
The portal feature. The broker portal got a smarter search. The AI is on the vendor’s side of the line, which is where it stops being visible from yours.
The licence. A team bought seats and recorded them correctly as a licence. A licence is a purchase record. It is not a system record, and it says nothing about which tenant settings are switched on or which mailbox the assistant is allowed to read.
None of this was hidden. Every one of these systems is documented somewhere — in a release note, a project sheet, a card statement, a contract. Just not in one place, and not as AI.
No insurer would take on a risk without a file. This one was taken on for you, one release note at a time.
The ground moved in 2025
None of what follows is the AI Act, Regulation (EU) 2024/1689. What changed is the shape of the questions, and an incomplete inventory now shows in the answers.
VAIT is gone. BaFin withdrew the Versicherungsaufsichtliche Anforderungen an die IT, together with KAIT and ZAIT, with effect from the end of 16 January 2025 — the German reads mit Ablauf des 16. Januar 2025, which means at the close of that day rather than on it. What stands in its place is DORA, Regulation (EU) 2022/2554, applicable from 17 January 2025. BAIT — the banking circular, which never applied to you — did not go with them.
MaGo was rewritten. The Mindestanforderungen an die Geschäftsorganisation are now BaFin Rundschreiben 09/2025 (VA), published 14 July 2025 and in force since 14 October 2025, replacing Rundschreiben 02/2017 (VA). Its new section on automated business flows (automatisierte Geschäftsabläufe) refers expressly to the AI Act. Read the instrument in the right register: a Rundschreiben is supervisory guidance, not statute. The binding duty is § 23 VAG, the general requirements for a proper business organisation, and MaGo is how BaFin reads it. So the sentence in your paper is “BaFin expects”, never “the law requires”.
DORA requires a register. Article 28(3) requires each financial entity in scope to maintain a register of information covering all contractual arrangements for the use of ICT services provided by ICT third-party service providers, on the templates set out in Implementing Regulation (EU) 2024/2956. Insurance and reinsurance undertakings are in scope under Article 2(1)(n) — unless they fall below the Solvency II thresholds, which Article 2(3)(b) takes out of DORA altogether — and ICT services are defined broadly at Article 3(21).
DORA contains no AI-specific provision, and there is no AI gap in it to complain about. The trouble sits upstream of the law. The register is filled from vendor onboarding, and AI arrives through the five channels above, none of which passes vendor onboarding. So the register can be accurate about everything in it and incomplete for exactly the services this post is about. That is an inventory problem, and inventory problems get fixed without anybody amending anything.
One more distinction, and a MaGo-literate reader will check it: Ausgliederung under § 32 VAG and DORA’s ICT third-party service provider are not synonyms, and treating them as one sorts contracts into the wrong process.
The second rulebook, and it isn’t BaFin’s
There is a second body of rules over this estate, and nobody in the DORA conversation is holding it. It is the Betriebsverfassungsgesetz, and it names AI expressly.
- § 90 Abs. 1 Nr. 3 BetrVG — the employer must inform the works council in good time about the planning of work processes, einschließlich des Einsatzes von Künstlicher Intelligenz. Those words are in the statute.
- § 80 Abs. 3 Satz 2 BetrVG — where the works council has to assess the introduction or use of AI to perform its duties, engaging an expert is deemed necessary to that extent. The argument about whether an expert is necessary is over before it starts; who it is and what it costs is still agreed with the employer.
- § 87 Abs. 1 Nr. 6 BetrVG — co-determination over the introduction and use of technical devices designed to monitor the behaviour or performance of employees — die dazu bestimmt sind, in the statute’s own words.
The test that actually applies is broader, and it is the Bundesarbeitsgericht’s construction of that phrase rather than the phrase itself: it is enough that the system is objectively capable of the monitoring, and the employer’s intention is irrelevant. The current authority is BAG, 16 July 2024, 1 ABR 16/23, on headset systems, where the absence of any recording did not take them out of scope. Quote the statute as it reads and attribute the test to the court. Then the works council’s expert is reading the same two sources you are.
Then there is a prohibition already in force. Article 5(1)(f) of the AI Act bars the placing on the market, the putting into service and the use of AI systems that infer the emotions of a natural person in the workplace on the basis of biometric data (Article 3(39)), subject to the medical and safety exceptions, and it has applied since 2 February 2025.
Take a scenario, and it is a scenario rather than a client. A contact-centre quality module in a claims department scores an agent’s tone across their own calls and puts a weekly figure into a coaching dashboard. Whether that particular feature falls inside the prohibition is a question for counsel with the product documentation in hand, and it turns on details no article can see. There is a prior question, though, and it is this post’s whole point: does anyone at your company know the module is switched on. It came with the release.
Most of the fix isn’t code — the rest is the honest part
Remediation at an insurer is rarely a code change, because most of the estate is not code you own. It is procurement, contract, tenant configuration and training — the same work seen from the other end.
- Put the question where the answer arrives on its own. Ask each vendor, at renewal and at every major release, whether the release adds or changes AI functionality and what data it processes to do it. One clause and one recurring question turn the largest arrival channel into a reporting channel.
- Make the registers you already keep check each other. The DORA register of information, the list of software under maintenance, licence and card spend, works-council agreements, the tenant admin console. Each is accurate about its own slice and blind to the rest, so every disagreement between two of them is a finding rather than noise.
- Record two facts per system, and only two, or nobody will keep it current: what data goes in, and who acts on the output. That pair is what makes an inventory usable later, when a question arrives with a deadline attached to it.
- Treat tenant settings as governance, because they are the fastest item on this list. Which connectors an assistant may reach, which mailboxes and file shares are in scope, whether a feature is on by default for everyone or off until asked for. That afternoon needs no developer.
Some of it is code, and that part is where an answer is hardest to round up. The assistant two people built has a config file naming every system it can reach; the pilot has a dependency manifest; the portal feature has a contract and an egress log that disagree with each other. Where code exists, read it rather than ask about it.
Where to start
Pull two lists you already have and read them against each other: the DORA register of information, and the list of software your company pays maintenance on. Then go down the second list and ask one question per vendor — has this product added AI functionality since we signed. That morning gives you the size of the gap, which is the number you want before choosing a method.
Then put a date on the next pass. The estate keeps taking deliveries, and delivery does not send a notification.
A risk you never wrote is still a risk you carry. The only part still up to you is whether it has a file.
This piece states the position as at 2 September 2026. The AI Act is being amended; check the current text of anything here before you rely on it.