Ask a bank's executive committee to name the pillars of AI governance and you will get a fluent answer inside a minute. Policies. Inventory. Data. Vendors. Lifecycle. Validation. Documentation. The vocabulary is in general circulation now, it is nearly free to hold, and holding it feels like progress.
Ask the same room which documents those pillars refer to, who wrote each one, and when each was last changed, and the fluency stops.
That gap is not a communication problem. It is the whole of the problem. A governance pillar is a heading on a slide, and headings cannot be missing, cannot go stale and cannot be produced on request. The things underneath them can be all three, which is what makes them worth counting.
The framework I am describing was built for a consumer and SME banking group operating across several European markets, as part of a board-level programme covering AI strategy, target operating model and regulatory readiness. It is a proposal. It went to a board for approval, and what follows is the shape of the document rather than a record of controls with an operating history behind them. The reason it is worth publishing is not that it worked. It is the rule we imposed on ourselves while drawing it, which is that no pillar was allowed onto the page until it had resolved into objects.
Seven headings, fifteen objects
The rulebook pillar carried three documents: a responsible AI policy covering ethics, fairness and transparency; a model risk policy carrying the validation requirements and the risk-tiering logic; and a set of data standards covering quality, privacy and permitted use. Three separate files with three different authors, not one policy with three sections, because they get reviewed on different clocks and challenged by different people.
Inventory carried two: a central registry of algorithms, and the risk classification applied to every entry in it.
Data governance carried two: lineage and provenance tracking, and the handling of personal data with its consent record.
Third-party governance carried two: due diligence on vendor models in the form of model cards, and the contractual liability and service-level controls that sit in the purchase agreement.
Lifecycle carried two: a standardised set of gates from build to deploy, and the change management procedure that governs anything moving through them afterwards.
Validation carried two: pre-deployment testing for fairness and bias, and drift monitoring wired to an incident response path.
Documentation carried two: the technical file the Act's Annex IV asks for, and the audit trails and decision logs that make an individual decision reconstructable after the fact.
Three plus twelve is fifteen, and that number is useful in a way the seven is not. Nobody can walk into a bank and check whether it has seven pillars. Anyone can walk in and ask for the fifteen.
Inventory is not one pillar among seven
The list looks flat on the page and it is not. One artefact has to exist before the other fourteen mean anything.
A central registry of algorithms is a plain thing: every model, every assistant, every automated decision aid in the bank, in one place, with an owner and a purpose against each entry. It is unglamorous and it is the only artefact whose absence makes the rest unenforceable. Fairness testing applies to something. Drift monitoring watches something. A technical file documents something. Without a register, each of those controls exists in the abstract and attaches to whatever happens to be in front of the person applying it, which in practice means the systems the governance team already knew about.
That is precisely the population that does not need governing. The exposure is in the systems nobody put on a list, and this bank had a live example of the mechanism: a small number of initiatives in flight, more of them in early testing, and no structure that required any of them to be declared. That pattern gets called shadow AI, which makes it sound like defiance. It is arithmetic. Pilots outrun policy in every institution, and the register closes the gap without anyone having to be caught.
Risk tiering is what converts the register from a list into a work plan. The four statutory tiers, prohibited through minimal, decide how much control weight each entry attracts, and they let a bank do the thing every governance programme needs and few manage, which is to govern most of the estate lightly so it can govern a small part of it seriously. Creditworthiness assessment and recruitment sit in the heavy tier. An assistant that drafts internal meeting notes does not.
Most of the artefacts belong to procurement
The single most reorienting number in this engagement was the split of the bank's own regulatory position. Around ninety percent of its exposure arises as a deployer, from third-party tools and vendor systems used inside business processes. Around ten percent arises as a provider, from models it builds itself, including its own credit scoring and internal risk models.
Read the artefact list again with that split in mind and it changes shape. Vendor due diligence, model cards, contractual liability, service-level controls: those are not the sixth-most-important pillar, they are where nine tenths of the risk actually enters the building. Yet almost every AI governance programme I see gets staffed as though the bank were mostly a builder, with the third-party artefacts handled as ordinary procurement paperwork.
This gets sharper, not softer, as agentic operations arrive. When a bought system stops being a model that returns a score and becomes a loop that calls tools, writes to systems and takes steps on its own, the registry entry is no longer the model. It is the agent, its permissions, its escalation path and the human who can stop it. That is the design question behind our Agentic OS work: an agent is governable only when the harness around it is a declared object with an owner, and the graded autonomy it runs under is written down somewhere a second line of defence can challenge.
- 7
- Governance pillars in the framework
- 15
- Named artefacts underneath them
- 4
- Statutory risk tiers used for classification
- ~90%
- Share of exposure arising as a deployer, not a provider
What makes an artefact an artefact
Three properties, and a pillar has none of them.
It has an author, meaning a person who wrote the current version rather than a committee that endorsed it. It has an owner, again a person, who can be asked why it says what it says and who is accountable when it stops being true. And it has a date, which is the property that does the quiet work, because an artefact with a review date can be found stale, and a heading never can.
Add those three properties to fifteen objects and you have something a board can approve in a single sitting and an internal audit function can test the following quarter. Approve the seven headings instead and you have approved a mood.
A pillar is a heading. An artefact is a file with an author, an owner and a date on it. Only one of those two things can be handed to an auditor, and only one of them can be found missing.
Do not build a second risk function
The last thing worth carrying out of this framework is what it deliberately did not add.
The bank already runs three lines of defence: business owners who own, risk and compliance who challenge, internal audit who assure. The AI artefacts were mapped onto those three lines rather than into a new AI risk organisation. The lifecycle was expressed as six gates from idea through design, build and validation, deployment, monitoring and retirement, which is the same gate structure model risk management already applies to conventional models. Two bodies were proposed, a board-level oversight committee and a working council staffed from risk, legal, data, technology and business, and neither was given delivery work.
The same instinct applies to the regulation. The privacy impact assessment the bank already performs extends to cover fundamental-rights impact. The vendor contracts it already holds pick up liability terms for AI. The validation lifecycle it already runs gains gates rather than a parallel process. Nothing in the statute demands a second risk function, and a bank that builds one has usually mistaken the size of the regulation for the size of the machine it requires.
Four numbers were set against all of it as targets: complete coverage of the high-risk inventory, no prohibited practices in operation, drift held under five percent, incidents reported inside twenty-four hours. They were proposed thresholds rather than measurements. What they demonstrate is the same point the artefact list demonstrates in a different register. Governance stops being a position and starts being an operation at the moment it acquires objects, owners and thresholds, and the high-risk obligations for credit and recruitment land this August whether or not that has happened.
Drawn from a board-level AI governance and operating model deliverable prepared for a consumer and SME banking group operating across several European markets. The pillars, the artefact list and the deployer-versus-provider framing are our design work for that client. The four numeric thresholds are proposed targets inside that document, not delivered results, and the risk tiers and documentation requirements referenced are the EU AI Act's own.
“A pillar is a heading. An artefact is a file with an author, an owner and a date on it. Only one of those two things can be handed to an auditor, and only one of them can be found missing.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.