Over the last period, I am seeing a lot of parallels with the implementation of BCBS239 and the AI Act. The BCB239 implementation has taught banks an uncomfortable lesson: regulatory implementation take tremendous time and do not end when the programme ends. More than a decade after the BCB239 principles were published, banks continue to address challenges. AI Act implementation risks following the same path, but it does not have to. The opportunity is to learn and use the regulatory programme to build something more durable: a continuous AI Governance closed loop management system.
BCBS239 and the AI Act pursue different regulatory objectives, but their implementation depends on several of the same capabilities: traceability, accountability, monitoring and the ability to act when conditions change. BCBS239 applies these disciplines to risk data aggregation and reporting. The AI Act introduces comparable lifecycle management demands for relevant AI systems and operators. Their implementation challenges are quite similar: defining scope, ownership, requirements, implementation, demonstration of effectiveness, and detecting changes. Therefore, BCBS239 should serve as an important implementation analogue to the AI Act.
Moreover, AI has a strong dependency on data, robust AI depends on mature data environments. BCBS239 has pushed organisations to develop disciplines around data lineage, quality, ownership, and transparency, providing crucial building blocks. Understanding data’s origin, transformation, quality, and accountability helps feed and control AI systems. So I firmly believe that BCBS239 practices can accelerate the AI Act compliance journey. To leverage this, start with applying lessons learned from BCBS239 into your AI Act journey. To get you going, I distilled 5 core lessons:
One of the long lasting challenges with BCBS239 has been scope. Which reports and key risk indicators are material? Which data is critical? Which transformations sit between the source and the report? Where does accountability begin and end?
Without a reliable scope definition, everything that follows becomes more difficult. The same is true for AI. Before discussing sophisticated controls, an organisation first needs to know what AI it actually has. That sounds trivial. In a large enterprise, it is not. The legal definition exists, but applying it consistently to thousands of technologies and use cases still requires interpretation, governance and repeatable decision criteria.
Furthermore, where do we draw the scope boundary: AI can enter the organisation through centrally developed models, vendor applications, embedded software functionality, public websites, local experimentation, machine-learning solutions that have existed for years, and increasingly through generative AI capabilities added to existing products.
For a large enterprise, that makes a comprehensive internal AI inventory a foundational capability – even where the Act itself does not prescribe one universal internal registry. This so called AI registry should not become another regulatory database – or an enormous system trying to contain every piece of information about AI. Its role should be to act as the authoritative index and connective tissue of the AI landscape. BCBS239 provides a useful warning here. Banks have spent years addressing fragmented data management metadata (lineage, data quality and ownership), because these capabilities were not consistently embedded into the underlying architecture from day one. We should avoid rebuilding the same fragmentation around AI.
Doing this right from the start will put a regulation-driven registry as the basis for portfolio management to drive AI reuse and value acceleration to strengthen your overall AI strategy execution.
Data Governance often becomes weakest at the point where responsibility moves from the central function to the business. BCBS239 journeys combated this for years. Central Data & AI functions, Risk, Compliance and Legal set direction, define frameworks, interpret requirements, set standards, build tools and provide challenge. But they cannot own every AI system in the bank. The domain using AI to make or support decisions needs meaningful accountability for that use.
This should feel familiar from Data Governance. A Data Owner who exists only in a governance document is not really an owner. The same will be true for AI. The accountable owner of an AI system should understand at least:
This does not mean every accountable owner needs to understand every technical detail. It does mean accountability cannot sit exclusively with the people who understand the technology. As AI becomes embedded into ordinary business processes, this distinction becomes increasingly important. The more AI scales, the less sustainable it becomes for a central AI governance team to act as the organisation’s de facto owner of AI risk. Governance must therefore move from central ownership to centrally orchestrated, federated accountability as fast as possible.
One of the most useful concepts from BCBS239 is lineage. In Data Management, lineage allows us to follow a number in a report backwards through transformations, systems and data sources. For AI, data lineage remains essential: we need to understand which data enters the AI system and how its output influences a decision. But we also need a second form of traceability – what I call regulatory lineage.
Therefore a regulatory obligation should be traceable. That traceability also helps avoid over-governance: not every AI system should be subject to the same requirements.
Traceability should work both ways. If I select a material AI system, I should be able to answer:
It is fundamentally different from producing policy documentation based on the regulation. Documentation is an artefact. Traceability is a capability. A bank can have thousands of pages of AI documentation and still have weak control if nobody can reliably connect those documents to the actual systems, controls and management decisions.
BCBS239 has shown how expensive it becomes to reconstruct lineage after processes and systems have already been built. For AI, we have the opportunity to design traceability in from the beginning and avoid one-size-fits-all mentality.
Regulation does not become operational because it has been translated into policy. A requirement becomes meaningful when something in the organisation changes as a result. That could be:
BCBS239 implementations have often relied heavily on retrospective documentation and practices. The direction of travel should therefore be from policy as text, to policy as process and, where appropriate, policy as code.
And not everything can be automated as code; questions concerning appropriateness, fundamental rights, human oversight, materiality or acceptable risk will continue to require human judgement. But repeatable and deterministic controls should at least be assessed for automation.
A development pipeline can retain evidence of testing. An AI registry can automatically receive model metadata. Monitoring can detect changes in performance. An approval can expire automatically. A substantial change in model or purpose can trigger reassessment. A control failure can create a remediation action rather than waiting for the next quarterly review. This is where technology and governance need to converge.
Otherwise, AI regulation risks creating a new manual reporting industry: spreadsheets, questionnaires and attestations that consume significant capacity while adding limited management insight. Manual controls will inevitably be part of the starting point. The mistake is allowing them to become the permanent operating model.
The principle should be: automate evidence where it is reliable and valuable. Preserve human capacity for judgement. And do it incrementally; first learn manually, then automate. Automation itself is not the objective. Better control is.
BCBS239 programmes produced tons of roadmaps over the last years. But often the lesson that is forgotten is that this focus can also create the wrong mental model. The organisation works towards a deadline, programme delivers and finally everyone moves on. Data and AI don’t work like that; it should never be seen as a one-off effort. Systems change, models change, data changes, vendors change, purposes evolve, users populations change, and performance might drift. Therefore organisations need a closed loop management control system to embed the regulation into business as usual as soon as possible.
Consider this simple example: A bank introduces an AI assistant to support customer-service employees. Initially, it is used only to summarise information and help employees work more efficiently. Six months later, a new version begins using additional customer information and recommending specific actions. The name of the system may not have changed, but its role has.
That immediately raises questions: Has its purpose materially changed? Does its risk classification still hold? Are the existing controls sufficient? Has the vendor changed the underlying model? Does the evidence need to be updated? Who is accountable for making that determination?
A static inventory may show that the system exists. A lifecycle control environment detects that the system has changed. That is the real challenge.
Being in control and compliant when a system enters production is not enough. The relevant question is: does the organisation remain in control throughout the lifecycle? That requires changes to have defined consequences. If the model substantial is modified, reassess it. If the intended purpose expands, reconsider classification and controls. If performance deteriorates, determine whether continued use remains acceptable. If the vendor changes the underlying model, understand the impact. If internal risk appetite or regulation changes, identify the affected systems.
This is the transition from compliance management to lifecycle management. And again, the lesson is not to solve everything at once. But use the regulatory programme to build momentum, then move quickly from milestone delivery into embedding, monitoring and continuous improvement.
The result should look less like a compliance programme and more like a** closed-loop AI management system**. Where the last part is crucial: without reassessment and learning, governance becomes a checklist. With it, governance becomes a management system – and over time, a learning system that helps the organisation understand where AI can create value safely and at scale.
Where do you see the biggest risk today: defining the AI perimeter, establishing ownership, or moving governance into continuous monitoring?
The AI Act Is Not a Compliance Project: Five Lessons from BCBS 239 was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.