National AI governance frameworks are proliferating. Virtually every government with an AI strategy now has a governance document alongside it, a set of principles, a regulatory roadmap, an ethics charter, a responsible AI standard. The volume of governance output is impressive. The observable impact on how AI is actually deployed in government and critical institutions is considerably less so.
What accounts for this gap is less a failure of policy intent than a failure of architectural design. Most governance frameworks are conceived to be published rather than operationalised. They articulate values without building the accountability structures needed to uphold them, and establish principles without specifying how those principles will be tested against real systems in real deployment contexts. Responsibility lands in committees that were never given the authority, the information, or the tools to exercise it.
Five design choices, in our experience, separate governance frameworks that produce observable accountability from those that produce documentation.
Choice 1: Governance at the system level, not the principle level
The first and most consequential design choice is the unit of governance. Most frameworks govern at the level of principles, fairness, transparency, accountability, human oversight. These principles are necessary but not sufficient. A framework that governs at the principle level gives an institution something to cite. A framework that governs at the system level gives an institution something to enforce.
System-level governance means that every AI system deployed in or by a regulated institution has a defined owner, a defined risk classification, a defined set of evaluation requirements appropriate to that classification, and a defined review schedule. It means that the governance function has a current inventory of deployed systems and the evidence base for each. It means that when something goes wrong with a specific AI system affecting specific citizens, there is a clear chain of accountability that runs from the system back to a decision-maker who approved its deployment.
Building this requires an AI system registry: a structured record of deployed systems with enough metadata to support both accountability and audit, not merely a list of AI projects in progress. Most governance frameworks do not require one. The ones that work do.
Choice 2: Pre-deployment standards, not post-deployment review
The second design choice is the timing of governance intervention. Frameworks that operate primarily through post-deployment review, auditing systems after they are in production, publishing assessments after harms have occurred, are systematically late. By the time a governance review identifies a problem with a deployed system, the system may have made thousands of consequential decisions, the vendor contract may have locked in the architecture, and the political cost of remediation may make meaningful change difficult.
Effective governance frameworks establish standards that must be met before a system is approved for deployment. This requires pre-deployment assessment methodology, a structured process for evaluating a system against the governance standards before it touches real users. It requires governance bodies to have the technical capacity to conduct or commission these assessments. And it requires that the approval to deploy be conditional on the assessment outcome, not retrospectively adjusted by it.
Pre-deployment governance is harder to implement and requires more institutional capacity than post-deployment review. It also produces substantially better outcomes, because it shapes the architecture of systems before the architecture is locked in.
Choice 3: Sovereignty requirements embedded in procurement
The third design choice is where sovereignty requirements are enforced. Most governance frameworks address data sovereignty, model ownership, and operational independence as policy statements. Effective governance frameworks address them as procurement requirements, specific, enforceable, contractual obligations that every AI vendor must meet to operate in the jurisdiction.
Where sovereignty requirements are embedded matters as much as whether they exist at all. A policy statement that government AI systems should preserve data sovereignty does not prevent a procurement process from selecting a vendor whose architecture routes data through foreign jurisdictions. A procurement standard that specifies in-jurisdiction data residency, in-jurisdiction model training, and contractual guarantees of operational continuity achieves something a policy statement cannot: it shapes what gets built before the architecture is locked in.
Embedding sovereignty requirements in procurement standards is the mechanism that converts a governance framework from aspiration to architecture. It is also the mechanism that creates the market signal for vendors to build sovereign-compatible offerings, rather than waiting for enforcement action after the fact.
Choice 4: Governance capacity inside the institution, not only outside it
The fourth design choice is where governance capacity lives. Frameworks that rely primarily on external oversight, independent auditors, parliamentary committees, civil society review, are necessary but not sufficient. External oversight catches failures after they emerge. Internal governance capacity prevents them.
Effective AI governance in sovereign institutions requires that the institution itself has the technical capacity to understand the systems it is deploying, evaluate vendor claims, conduct or commission meaningful pre-deployment assessments, and maintain an ongoing monitoring capability in production. This is a workforce capability question as much as a policy question, and it is one that most governance frameworks do not address directly.
Building internal governance capacity requires investment in AI-literate staff at the technical, legal, and executive levels. It requires that the governance function have access to the technical expertise necessary to evaluate systems it is asked to approve. And it requires that governance responsibilities be embedded in operational roles rather than concentrated in a central AI ethics committee that has no visibility into the systems being deployed across the institution.
Choice 5: Governance that produces intelligence, not only compliance
A fifth design choice concerns what governance is expected to produce. Frameworks oriented toward compliance outputs, such as sign-offs, documentation trails, and audit-ready records, tend to generate administrative overhead without a corresponding institutional benefit. Frameworks oriented toward intelligence produce something more useful: a persistent, structured view of how AI is being deployed across the institution, how it is performing, and where risks are accumulating before they become visible problems.
This requires that the governance architecture be designed as an information system, not just a process system. Assessment data, system inventory data, deployment outcome data, and incident data should flow into a governance intelligence layer that enables decision-makers to see patterns across systems and over time. The governance function that has this capability is not just a risk mitigation function, it is a strategic intelligence function that can inform AI investment decisions, procurement strategy, and capability development priorities.
The test of a governance framework
The test of a national AI governance framework is not whether it can be cited in a ministerial speech. It is whether, when a specific AI system deployed by a specific agency produces a harmful outcome for a specific citizen, the governance architecture can identify who approved the deployment, on what evidence, under what standards, with what ongoing monitoring in place, and produce that information quickly enough to be useful.
Few current frameworks can meet that standard. The ones that will are being designed now, by governments and institutions that have come to understand governance as infrastructure rather than documentation, something that has to be built, maintained, and held accountable to outcomes.