The One-Page AI Governance Framework (Even in Regulated Industries)

Governance is five decisions, not fifty pages

Five decisions. Make them once and almost every future question answers itself.

Data boundaries. Classify once: green for any approved tool, yellow for enterprise tools with contractual data protection only, red for data that never leaves controlled systems. Every future question comes down to which bucket.

Access. Which roles get which capabilities. Read widely, write narrowly is the default that survives contact with reality.

Log the writes.

Evaluation. Every production AI workflow names its owner and its check: sampled human review, regression cases, tripwire metrics. A workflow without evaluation is a pilot, and pilots do not touch customers.

Spend. Budgets and caps per team, visible weekly. Runaway cost is a governance failure before it is a finance problem.

Accountability. A human owns every agent's output, the same way a manager owns a report's output. No orphan automations.

Regulated industries: constraint as clarity

Healthcare, finance, insurance, and law adopt AI successfully by turning the question around. Instead of "can we use AI?", ask "which of our workflows have no regulated data in them at all?"

Marketing drafts, internal documentation, code without PHI or PII, research synthesis. There is usually a wide green zone that needs no regulator conversation whatsoever.

For the regulated zone, your existing compliance machinery is the asset, not the obstacle. The same access controls, audit logs, and review chains that govern human work extend to machine work. Regulators do not require that AI be absent.

They require that accountability be present.

One rule keeps you safe in every jurisdiction: a human owns every consequential output, and the log can prove who.

Rolling out coding agents without leaking the company

Coding tools such as Claude Code and its peers deserve their own checklist, because they touch source code, credentials, and infrastructure.

Enterprise accounts only, with training-data exclusion in the contract. Repository access scoped per team, never org-wide by default. Secrets out of repositories entirely, so there is nothing to leak.

Agent-written code enters through the same pull-request review gate as human code. Spend caps per seat. A kill switch someone actually knows how to use.

None of this is exotic. It is your existing engineering hygiene applied to a faster contributor. Teams with weak hygiene discover that the agent did not create the risk.

It sped up the discovery of it.

Making it stick

Publish the page. Name the owner. Review it quarterly against incidents and new tools.

Tie exceptions to the ask-first contact, not to silence.

Governance that lives in a shared document people have actually read beats a policy portal nobody visits.

Governing workflows and agents: governance as code

The five decisions govern a company. They also have to govern each workflow, and that is where most frameworks go quiet.

A policy page that says "a human owns every output" means nothing to an automation that runs at 3 a.m., unless the owner's name, the spend cap, the data scope, and the kill switch are written where the automation lives. That is what the phrases execution governance, workflow governance, and governance as code all point at: the same five decisions, applied per workflow, stored next to the workflow so the policy and the running system cannot drift apart.

In practice it is four lines at the top of every automation's definition. What triggers it and what it may touch. The hard limits enforced outside the model.

How its output is checked and how often. Who owns it and how it is stopped.

The first and the last are the ones that matter in an incident. The one in the middle, the check, is what separates a production workflow from a pilot. Our article on the agent harness covers the technical layer those four lines live in, and how to evaluate AI agents covers what a real check looks like.

The payoff is that governance stops being a document people read once and becomes a property of the system. An auditor, a regulator, or a new hire can open any workflow and see its scope, its limits, its check, and its owner without hunting for the policy page first.

Anthropic's guidance on building effective agents makes the same argument from the engineering side: simple, composable, bounded, with the human checkpoints explicit.

What the external frameworks actually ask for

Companies in regulated industries often assume governance means adopting a hundred-page standard. The standards are useful for the opposite reason: they map straight onto the five decisions.

The NIST AI Risk Management Framework organizes everything under govern, map, measure, and manage. Its govern function is accountability and policy, and its measure function is evaluation.

ISO/IEC 42001 is a management-system standard. It asks whether you have named owners, documented controls, and a review cycle, which is the Making It Stick section above with a certificate attached. The OECD AI Principles are the shared vocabulary most national policies borrow from.

The EU AI Act adds a risk tiering. Most business automations are minimal or limited risk and carry transparency duties, while a short list of uses are high risk and carry documentation, human-oversight, and logging duties. Notice that the high-risk duties are the five decisions with evidence attached.

For security specifically, the OWASP Top 10 for LLM applications is the list to check an agent's access and data boundaries against. And the vendors' own rules set the floor on what the tools may be used for at all: Anthropic's usage policy, Google's AI principles, Microsoft's responsible AI standard.

For healthcare, the one document to read before any customer-facing automation is the Department of Health and Human Services' guidance on online tracking technologies, because it decides what counts as protected information the moment a visitor interacts with a page or a form.

Read with the five decisions in hand, none of these documents asks for anything the one-page framework does not already contain. They ask for proof that it is followed. Write the page, keep the log, and the proof is already sitting there when someone asks.