A compliance calendar is not a governance program. Plenty of fintechs and banks now have an AI Act deadline tracked in a spreadsheet and a risk policy signed by the board, but ask them to produce the inventory of every model touching a credit decision, show who signed off on the latest version, and hand over the audit trail, and the exercise stalls. That gap between "we know the law" and "we can prove compliance on demand" is where most AI governance programs actually live or die.
This article is deliberately operational. If you want the strategic argument about why the AI Act and DORA pull in different directions for regulated financial firms, and where the two regimes leave gaps a compliance team has to fill manually, read the companion piece: the DORA / AI Act governance gap for fintechs. What follows here is the build out: the actual program you stand up once you've accepted that gap exists, roles assigned, inventory built, controls mapped, evidence captured.
Start with roles, not with policy
Most AI governance failures trace back to one unanswered question: who owns the model after it ships. A RACI that works in practice, not just on paper, looks roughly like this:
- Model/use-case owner (business line): responsible for the use case's business justification, accountable for ongoing performance and fairness monitoring, consulted on any material change.
- AI governance lead (risk or compliance function): accountable for classification under the AI Act's risk tiers, responsible for maintaining the inventory, consulted on deployment decisions.
- Technical validator (model risk management or data science): responsible for technical documentation, testing, and bias/robustness evidence, accountable for sign off before production use.
- Data protection officer: consulted on any system processing personal data, informed on classification outcomes.
- Internal audit: informed on a cycle, with the right to pull any evidence package on demand.
- Board or designated committee: accountable for the overall AI governance framework, informed quarterly on inventory changes and incidents.
The point of writing this down is not bureaucratic theatre. When a regulator or an internal auditor asks who approved this credit scoring model's latest retraining, you need a name and a timestamp, not a shrug.
Build the inventory before you build controls
You cannot govern what you haven't listed. A usable AI/ML inventory for a financial services firm needs, at minimum: system name and version, business purpose, data inputs, deployment status, risk classification under the AI Act (prohibited, high risk, limited risk, minimal risk), owner, last validation date, and link to the evidence package. Treat shadow AI, vendor embedded models in your core banking or fraud stack, and homegrown spreadsheet models with scoring logic as in scope. A surprising number of high risk systems in credit and insurance are buried inside a vendor's black box, not built in house, and the AI Act's deployer obligations still apply.
Classification is the step teams get wrong most often, usually by assuming a system is just analytics when it actually falls under Annex III (creditworthiness assessment, for example, is explicitly listed). When in doubt, classify conservatively and document the reasoning. An under classified system discovered during an audit is a worse outcome than an over classified one.
Map controls to risk tier, not to a generic checklist
Controls should scale with classification, not apply uniformly:
- Prohibited practices: a gating control at intake, confirming no use case involves social scoring, manipulative techniques, or unacceptable biometric categorisation. This should block a project before it gets a budget line.
- High risk systems: risk management system, data governance and quality controls, technical documentation, logging and traceability, human oversight design, accuracy and robustness testing, and a conformity assessment path where applicable.
- Limited risk systems: transparency controls, mainly disclosure that a user is interacting with AI, and labelling of AI generated content where relevant.
- Minimal risk: lighter touch, but still inventoried and subject to periodic review, because classification can change as a system's use expands.
The evidence trail: what an auditor actually wants to see
Controls that exist only as policy language don't survive an audit. For each in scope system, keep an evidence package: the risk classification memo with reasoning, data lineage and quality checks, the technical documentation bundle, test results for bias and robustness, the human oversight design (who can override the model and how), incident and drift logs, and the sign off chain with dates. This should be retrievable in minutes, not reconstructed under deadline pressure.
The digital omnibus: verified, but still worth watching
As of this writing, the EU has adopted amendments (the Digital Omnibus on AI, originally proposed by the Commission on 19 November 2025) that defer the AI Act's high risk obligations: Annex III standalone high risk systems now apply from 2 December 2027, and Annex I product embedded high risk systems from 2 August 2028. Article 50 transparency duties (telling users they're interacting with AI, labelling AI generated content) still apply from 2 August 2026, with only the technical watermarking requirement for pre existing generative systems getting a short grace period to 2 December 2026. A new prohibition on non consensual intimate imagery generation (nudification apps) was added, effective 2 December 2026.
The substance of the obligations hasn't changed, only the clock. Harmonised standards and Commission guidance are still catching up, and implementation detail (how conformity assessment bodies operate, how the extended AI Office powers get exercised in practice) is still settling. Treat these dates as the best verified picture at time of writing, not a permanent fixture, and build your program on the assumption that deadlines move more easily than obligations disappear.
Build once, reuse everywhere
None of this needs to be a one off project. Firms that treat AI governance as an extension of existing model risk management, rather than a parallel bureaucracy, get there faster and spend less. If you're trying to stand up this framework alongside broader automation work, our AI automation page covers how we approach that build out in practice.
If you're working through roles, inventory, or evidence gaps for your own AI governance program, reach out at team@novafin.co.