Institutional sovereignty is the missing layer in AI governance

Most enterprises are writing AI policies right now. They are also standing up review boards, model inventories, and risk registers. That’s progress.

Then the first real incident happens: An agent changes a configuration. A staff member pastes sensitive data into a tool they were not approved to use. A model output drives a decision nobody can fully explain. As a result, the post-incident review ends up being the same argument every time.

Who authorized this

Who owned the intent

Who is accountable for the outcome

When I interview executives and review modernization failures, I keep seeing the same structural pattern: the barriers are constitutional, not technical. Decision rights fragment, continuity breaks, and external actors shape the agenda more than internal governance.

AI amplifies that weakness because AI turns decisions into workflows, and workflows into automated action. If you cannot prove authorship and authority in normal operations, you will not be able to prove it once AI enters the loop.

That is why I use institutional sovereignty as the missing layer in AI governance. It is a governance model focused on authorship, decision rights, accountability, and continuity, expressed in a way leaders can implement and audit. It also explains why AI adoption often stalls due to non-technical factors such as contractual ambiguity and liability uncertainty.

Healthcare makes this painfully visible. One physician leader described the current state like this:

“AI, I call it the wild wild west… we are operating in a gun slinging stagecoach environment, where people are doing almost anything they want, and the regulatory environment has to catch up.”

That is not a regulation problem. It is an institutional ownership problem.

Policy is not proof

Policies describe what should happen. Proof is what you can demonstrate happened, who caused it, and on what authority.

In practice, the gap between policy and proof manifests in three ways.

First, intent is not owned. The institution does not define its own modernization agenda, and external parties introduce direction without an internal mandate. That is authorship failure.

Second, authority is not bounded. Decision authority is spread across committees, departments, or external partners, creating unclear boundaries and inconsistent governance. That is jurisdiction leakage.

Third, oversight becomes theater. Governance bodies exist without enforceable authority. They perform oversight symbolically while real decisions occur outside formal channels.

AI makes each of these worse.

An AI policy that says “humans remain accountable” is meaningless if you cannot answer a basic operational question: who had the right to delegate this action to the system? This is why governance is a core function in the NIST AI Risk Management Framework.

This need for core governance functions is echoed in other frameworks. For example, the same logic applies in ISO/IEC 42001, which frames AI management as an organizational system rather than a model documentation exercise.

Now, add the human reality inside healthcare. A security leader warned that intent is often split between technical goals and executive pressure:

“CISO might have their own agenda… The problem is, you might have folks on the board of directors that put pressure on the C suite to say, We want AI to help us reduce staff.”

When intent is neither explicit nor ratified, trust quickly collapses, and people begin to circumvent governance. This risk connects back to broader organizational dynamics.

I also see organizations self-block innovation by treating compliance as folklore. A healthcare technology executive put it bluntly:

“Regulatory compliance is often used as a… artificial barrier… It is a perception… often perceived what the regulatory needs are, but they’re not frequently well understood.”

This kind of authority failure means decisions are vetoed without a cited basis, remediation path, or a named decision owner.

Given these patterns, the real question becomes: what is the constitutional layer beneath your AI program? This sets the stage for a more structured approach.

The decision rights stack behind institutional sovereignty

Institutional sovereignty defines a constitutional layer of governance using five pillars. If any pillar is weak, sovereignty is incomplete, and the institution becomes vulnerable to dependence on external authority.

I apply these pillars to AI governance as a decision rights stack.

1. Decision architecture

This is your formal answer to the question of who can decide what.

In AI terms, decision architecture must explicitly cover: who can approve a use case, who can approve deployment, who can approve autonomy, who can approve exceptions, and who can suspend or roll back an agent.

This is where most AI programs quietly fail. They create an AI committee, but they do not publish a decision map that names owners and defines delegation boundaries.

2. Risk authorship

Many dependent institutions allow vendors, regulators, or consultants to define what is urgent, acceptable, or possible. Risk narratives are outsourced, creating a structural dependency.

In AI governance, risk authorship means the institution defines its own thresholds for safety, privacy, integrity, and operational impact. You can align with external principles, such as the OECD AI principles, but you still need an internal doctrine that turns those principles into enforceable decisions.

In healthcare, risk authorship must also be honest about the stakes. People do not tolerate vague accountability when harm is possible.

3. Workflow authority

AI does not live in a policy binder. It lives in workflows.

Many organizations operate on vendor workflows, consultant playbooks, or politically imposed processes. Workflow authority reestablishes institutional control by redesigning governance rituals, approval pathways, and operational workflows.

In AI terms, workflow authority means you control where AI can act, what approvals are required, which escalation paths exist, and how exceptions are handled.

A former CMIO captured the core problem:

“The technology has outpaced the people and the process… physicians and health systems are bringing in technology tools… but from a process standpoint, it’s not really clear how the governance works.”

That is the birth of shadow AI.

4. Data authorship

If you do not own your data definitions, you do not own your truth.

AI governance without data authorship becomes performative because you cannot validate outputs, measure drift, or prove provenance.

In healthcare, this is magnified by fragmented systems, inconsistent definitions, and the operational reality that data is created by workflows, not by dashboards.

5. Boundary control

Boundary control is the process of constructing enforceable limits that prevent vendors and external platforms from shaping modernization strategy, controlling evidence, or owning the audit trail.

In AI governance, boundary controls cover tool access, third-party integrations, data egress, audit rights, logging requirements, retention requirements, and who owns agent behavior at runtime.

This is where governance often dies. If the contract does not provide auditability, exportability, and incident visibility, your internal policy has no teeth.

Two lived experiences that show the gap

In one health system, I saw a high-risk shadow pilot form almost overnight. Clinicians were exhausted by documentation and adopted an ambient listening tool on their own to reduce after-hours charting. The intent was understandable. The governance path was bypassed.

The moment leadership discovered it, everything stopped. Security and privacy had to run a retroactive assessment, clinical leadership had to calm down teams that felt punished for innovation, and the organization lost weeks of momentum.

The fix was not to shame people. The fix was to create a sanctioned living lab: a safe-to-fail sandbox with clear data boundaries, mandatory logging, named intent owners, and an explicit stop authority from day one.

In another case, we were implementing an enterprise scheduling platform across newly acquired clinics. The executive team chose a standardized system to scale operations. A middle manager informally vetoed the change through quiet resistance. Adoption slowed, teams lost confidence, and the project risk grew.

That pattern matters for AI governance because informal authority will override formal policy every time unless decision rights are explicit and enforced. If someone can slow-roll an AI control change, your governance is decorative.

A checklist leaders can implement this quarter

Here is the checklist I give CIOs and governance leaders who want AI governance that can survive audits, incidents, and leadership transitions. It is designed to be implementable, not aspirational.

1. Publish a decision rights map for AI. List the decisions that matter: use case approval, data approval, deployment approval, autonomy approval, exception approval, suspension, and rollback. Assign a single accountable owner for each decision and a backup owner.
2. Define intent ownership as a required field. For every AI system and agent, record the business intent, the owner of that intent, and the measurable outcome they are accountable for. If you cannot name the intent owner, you do not have a legitimate use case.
3. Establish risk authorship with explicit thresholds. Write down what not allowed means in your environment. Examples: categories of data that cannot be used, actions that cannot be automated, decisions that require human review. Use NIST AI RMF as a structure, but keep thresholds internal and enforceable.
4. Require an action log that supports forensic reconstruction. If an agent can act, you need records that establish what happened, when it happened, where it happened, the source of the event, the outcome, and the identity of the actor. This maps cleanly to audit control expectations like NIST SP 800 53 AU 3.
5. Implement reversibility as an architectural rule. Every agentic workflow must have a defined rollback or compensation mechanism. If rollback is impossible, autonomy must be restricted to recommendations.
6. Put workflow authority into the approval design. Do not approve the use of AI in the abstract. Approve specific workflow insertions: where the AI reads, where it writes, where it triggers actions, and where a human gates the process. Your workflow maps should show escalation paths and negative authority, meaning what the system is explicitly forbidden to do.
7. Lock down data authorship before model debates. Define the authoritative sources for the key metrics the AI will touch. Define who owns the meaning of each metric. If that ownership is unclear, the AI project is premature.
8. Use sovereignty blockers as a pre-deployment diagnostic. Before deploying, look for the constitutional failure modes that predict collapse: authorship failure, mandate distortion, jurisdiction leakage, and stewardship theater. If you see them, fix governance before you scale the AI.
9. Add contract language that matches boundary control. If you cannot audit, log, export records, or enforce retention, AI governance is dead on arrival. Contracts must match your evidence and accountability requirements.
10. Score your organization on sovereignty maturity. Use a maturity ladder to identify whether governance is enforceable, stable across leadership transitions, and able to defend institutional priorities against external pressure.

Why this works, especially in healthcare

Institutional sovereignty treats AI governance as a constitutional design. That framing matters because the failure modes of AI governance are usually not mathematical problems. They are mandate, jurisdiction, boundary, and continuity problems.

Healthcare is safety-critical, cross-generational, and resource-constrained. When governance is unclear, people route around it because pain is real and time is scarce. That is why sovereignty is not an academic layer. It is a prerequisite for trustworthy AI to survive real-world operations.

When you solve sovereignty, frameworks and standards become accelerators instead of decorations. The result is simple: you can prove who owned intent, authority, and outcomes when AI enters your workflows.

If you want AI governance that survives the real world, build sovereignty first.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?