Every European institution of any size now has an AI governance framework. Most of them share a common defect: they were written to satisfy an auditor's template rather than to answer the question a board, a regulator or a parliamentary committee will actually ask. That question is never "which maturity level are you at?" It is, invariably, "who decided this, on what evidence, and what happens when it is wrong?"
This essay sets out a framework built backwards from that question. It assumes a European institution — a supervisory authority, a bank, a hospital group, a utility, a ministry — deploying AI inside a statutory mandate, under the EU AI Act, and usually under NIS2 or DORA as well.
Why most AI governance frameworks fail
Three failure patterns recur, and they are structural rather than accidental.
- The framework is a document, not a control. It describes principles — fairness, transparency, accountability — without naming the person who signs, the artefact they sign, and the date by which it expires. A principle with no signature attached produces no evidence when evidence is demanded.
- It is generic where the institution is specific. A copied maturity ladder cannot know that a payment authority's tolerance for a false negative is categorically different from a triage system's. Governance that is not scored against the institution's own mandate scores nothing.
- It governs the model and ignores the chain. The weights are one link. The data pipeline, the orchestration layer, the identity provider, the observability stack and the human operators are the others. Governance that stops at the model boundary will be surprised by the first incident, which will originate outside it.
Start from the mandate, not the maturity model
The first artefact is not a policy. It is a one-page mandate map: the legal basis under which the institution acts, the decisions it is empowered to take, the decisions it may never delegate, and the standard of review its decisions are subject to. Everything downstream is derived from this page.
The map is what turns abstract governance into a decidable question. "May this system rank applicants?" is unanswerable in the abstract and trivially answerable once the enabling statute, the delegation rules and the appeal mechanism are on one page. Institutions that skip this step spend the next two years re-litigating the same question per project.
A useful discipline: every AI system in the estate must be traceable to a line on the mandate map. A system that cannot be traced to one is either mis-scoped or shadow IT. Both are findings.
The five layers of a defensible framework
- Inventory. Every AI and algorithmic system in operation, in procurement and in pilot — with owner, purpose, mandate line, risk classification, data categories, and the dependency that operates it. Incomplete inventories are the single most common root cause of a failed supervisory review. The inventory is a live register, not an annual spreadsheet.
- Classification. Each entry mapped to its regulatory status: prohibited practice, high-risk under Annex III or as a safety component, transparency-obligation system, or minimal risk. Classification drives obligation; guessing here propagates through everything else. Record the reasoning, not only the conclusion — the reasoning is what a supervisor will test.
- Controls. For each classification, the control set that applies: risk management, data governance, human oversight, accuracy and robustness thresholds, logging retention, cybersecurity posture. Controls must be written as testable statements. "Meaningful human oversight" is not testable. "The duty operator can override within 30 seconds; overrides are logged and retained for ten years; override rate is reviewed monthly by the risk committee" is.
- Assurance. Who tests the controls, how often, and independently of whom. Internal audit cannot assure a system that internal audit designed. Second-line and third-line responsibilities must be separated in writing before the first incident, not during it.
- Escalation. The path from a degraded model to a board decision, with named roles and clock times. Most institutions can describe an escalation path for a data breach and cannot describe one for a model that has been quietly wrong for six weeks. Silent degradation is the characteristic AI failure mode and it needs its own route.
Evidence: what you must be able to produce
Governance is judged on artefacts, not intentions. A defensible framework produces, on demand and without a project, the following:
- The current system inventory with classifications and owners.
- For each high-risk system: technical documentation, the risk management file, the data governance record, the oversight design, and the last evaluation run against the operating environment.
- The log retention statement, and proof that logs are actually retained and readable.
- The last three escalations, with the decisions taken and by whom.
- The dependency map: infrastructure, weights, orchestration, and the jurisdictions each sits in. See data residency vs data sovereignty for why the last column decides the others.
If producing any of these requires a two-week internal exercise, the framework is not operational. That is the whole test.
The board reporting line
AI governance that reports only into a technology committee will eventually fail, because the decisions it produces are mandate decisions, not technology decisions. The reporting line should terminate where the institution's risk appetite is set.
A workable quarterly board pack is four pages: inventory movement, classification changes, control exceptions with owners and dates, and the top three dependency risks. Not a dashboard. Four pages that a non-technical board member can read and challenge — because being challengeable is the point.
The first ninety days
Weeks 1–3: mandate map and inventory. Nothing else. Resist the urge to start policy drafting; policy written before the inventory is written twice.
Weeks 4–7: classification and gap assessment against the applicable obligations. Produce a ranked exception list with owners.
Weeks 8–12: oversight design and escalation path for the top three high-risk systems; first board pack; first rehearsed escalation. A governance framework that has never been exercised is a hypothesis.
Our engagement structure for this sits in the methodology, and the sectoral variants in practice areas.
Frequently asked
What is an AI governance framework? A set of named controls, owners and evidence artefacts that lets an institution show who decided what, on which basis, and what happens when a system fails — mapped to its legal mandate and the obligations that apply to each system.
Is the EU AI Act enough as a governance framework? No. The AI Act sets obligations for classes of system; it does not tell a specific institution which decisions it may delegate. The Act is the floor; the mandate map is the shape.
Who should own AI governance in an institution? A first-line accountable owner per system, a second-line risk function that sets and tests controls, and third-line assurance that is independent of both. Concentrating all three in a single "AI office" reproduces the conflict of interest it was created to solve.
First published September 2026 · Frankfurt am Main.