We keep discussing how to comply with the AI Act. Perhaps the better question is: "What controls are common across all our regulatory obligations, and how do we implement them once?"
Every regulated organization deploying AI is navigating the same landscape: multiple frameworks, overlapping obligations, and a growing pressure to demonstrate compliance across all of them simultaneously. The EU AI Act. GDPR. DORA. NIS2. ISO 27001. ISO 42001. Internal risk frameworks. Each arrives with its own vocabulary, its own audit trail, its own set of documentation requirements.
The instinctive response is to treat each framework as a separate project. A dedicated workstream for the AI Act. A separate program for DORA. Another initiative for ISO 42001 certification. The result is a governance estate that is expensive to maintain, difficult to audit, and structurally fragile — because it was built as a collection of compliance responses rather than as a coherent operational capability.
The convergence insight
Look closely at what each framework actually requires, and a pattern emerges. Asset inventory. Classification. Access management. Monitoring and logging. Human oversight mechanisms. Incident management. Audit trail. Third-party risk controls. These are not AI Act requirements. They are not DORA requirements. They are not GDPR requirements. They are all of the above — the same underlying controls, expressed in different regulatory vocabularies.
The diagram below illustrates this convergence. Multiple regulatory frameworks — each with its own scope, its own enforcement mechanism, its own timeline — all pointing toward the same set of operational controls. The question is not which framework to comply with first. The question is how to implement those controls once, in a way that satisfies all of them.
Regulatory convergence on common controls — the Verydion perspective
Governance as architecture
The shift in framing is significant. When governance is treated as a collection of compliance projects, the organization builds point solutions: a model risk register for the AI Act, a separate incident log for DORA, a third data classification scheme for GDPR. Each is technically compliant. None of them talk to each other. The audit burden multiplies. The operational overhead grows. And when a new regulation arrives — and it will — the organization starts again.
When governance is treated as architecture, the logic inverts. You identify the common controls. You implement them once — in your data platforms, your AI systems, your operational processes. You map each regulatory obligation to the controls that satisfy it. When a new framework arrives, you assess the delta, not the whole. The governance estate becomes a capability, not a cost.
"Governance should not be a collection of projects. It should be architecture."
What this means in practice
Implementing governance as architecture requires three things that most organizations have not yet done together.
First, a control inventory. Not a list of regulatory requirements — a list of the operational controls that satisfy them. Asset inventory, classification, access management, monitoring, human oversight, incident management, audit trail, third-party risk. These are the building blocks. They need to be defined, owned, and implemented as operational capabilities, not as compliance artefacts.
Second, a mapping layer. Each regulatory obligation maps to one or more controls. The AI Act's requirement for human oversight maps to the same control as DORA's requirement for operational continuity oversight. GDPR's data minimization principle maps to the same classification and access management controls as ISO 27001's information classification requirements. The mapping makes the convergence explicit — and makes the audit trail defensible.
Third, platform-level implementation. Controls that live in documents do not govern AI systems. Controls that are implemented in the data and AI platforms — in the pipelines, the model registries, the monitoring infrastructure, the access layers — do. The implementation layer is where governance becomes operational. It is also where most organizations have the largest gap.
The strategic advantage
Organizations that build governance as architecture gain a compounding advantage. Each new regulatory obligation costs less to satisfy, because the underlying controls already exist. Each audit is faster, because the evidence is already structured. Each AI deployment is more defensible, because the governance infrastructure is already in place.
The organizations that treat governance as a collection of projects will spend the next decade rebuilding the same controls in different shapes for different regulators. The organizations that treat governance as architecture will spend that time deploying AI at scale — with confidence.