Most AI Governance Is Theater. Yours Doesn’t Have to Be.

Right-sizing NIST, ISO 42001 and the EU AI Act to the risk you actually carry

The Governance Nobody Uses

Somewhere in your organization, or an organization very much like yours, there is a document. It is titled something like “Responsible AI Policy” or “AI Governance Framework.” It runs to eight or twelve pages. It cites NIST, alludes to ISO 42001, and includes a section on the EU AI Act. The document was assembled under tight deadlines by someone who was already managing three other jobs, and it was approved in a meeting where it wasn't reviewed closely enough to raise objections.

That document has changed nothing. No AI system was built differently because of it. No launch was stopped because of it. No engineer has opened it since it was published. It exists to be pointed at, in a board deck, in a customer security review, in a due diligence questionnaire, as evidence that the company takes AI seriously. It is a prop.

This is the open secret of AI governance in 2026. An enormous amount of it is theater. And the uncomfortable part, the part governance vendors and consultants will not tell you, is that the theater is not an accident or a shortcut taken by lazy companies. It is the predictable output of doing exactly what everyone told you to do. Adopt the frameworks. Produce the documentation. Stand up the committee. Follow the enterprise example.

The enterprise example is the trap. The playbook often used as the standard to imitate was engineered for a company with a risk profile, regulatory exposure, and operating model that are likely not yours. When you copy it, you inherit its costs and its pathologies while getting almost none of its benefits. And escaping that trap is the single highest-leverage governance decision most companies can make, because the alternative is not weaker governance. It is more real governance, matched to the risk you actually carry rather than to the risk someone else carries.

Three Frameworks, Three Different Things, One Persistent Confusion

Before anything else, we have to clear up a confusion that underpins almost every bad governance decision. People treat NIST AI RMF, ISO/IEC 42001, and the EU AI Act as three competing options, three flavors of the same thing, and then they try to “comply” with all three at once, as though governance were a buffet where the goal is to load your plate.

They are not the same kind of thing. They are not in the same category. Getting this wrong is the original sin from which most governance theater descends.

NIST AI RMF is guidance. It tells you how to think.

The NIST AI Risk Management Framework, published by the US National Institute of Standards and Technology in January 2023, is voluntary. Nobody certifies you against it. Nobody audits it. There is no badge. It is a mental model, and a good one, organized around four functions that you cycle through continuously rather than complete once.

Govern is the accountability layer. Who owns AI risk, what your risk tolerance is, and how decisions escalate. Map is the context. What a system is for, who it affects, what could go wrong, and what are the consequences of those failures. Measure is assessment. The actual testing, evaluation, and monitoring that tells you how a system behaves. Manage is action. Prioritizing risks, deploying mitigations, and making the actual go/no-go and retirement calls.

The reason NIST has become the default reference point is that it describes an operating rhythm rather than a checklist. Govern, Map, Measure, Manage are verbs you repeat, not boxes you tick. That makes NIST the right tool for one specific job. Being the actual workflow your teams follow. It is guidance about how to think, and thinking is not something you can outsource to a document.

ISO/IEC 42001 is a management system. It tells you how to prove it.

ISO/IEC 42001, published in December 2023, is the first international standard for AI management systems. If you have lived through ISO 27001 for security or ISO 9001 for quality, this will feel familiar, because it is built on the same architecture. Documented policy, defined roles, risk assessment processes, internal audits, management review, and continual improvement.

The thing that makes 42001 categorically different from NIST is its certifiability. An accredited body can audit your AI management system and issue a certificate. That certificate is an external trust signal, useful in enterprise sales, vendor questionnaires, and partner due diligence. But notice what 42001 does not do. It does not tell you which bias metric to use or how often to test for drift. It tells you that you must have a systematic, documented, reviewed approach. It is the skeleton, not the muscle. It provides structure and auditability, the scaffolding that turns informal good intentions into something durable and provable.

The EU AI Act is law. It tells you where the stakes are highest.

The EU AI Act, adopted by the European Union in 2024, is neither guidance nor a voluntary standard. It is a binding regulation with real financial penalties, and it works through a risk-based classification. Unacceptable-risk practices, such as social scoring and certain manipulative systems, are prohibited. High-risk systems in domains such as employment, credit, essential services, and law enforcement carry the heaviest obligations, including documented risk management, data governance, technical documentation, human oversight, and conformity assessment. Limited-risk systems, such as chatbots, face lighter transparency duties. Minimal-risk systems face nothing specific.

Worth noting, because it makes the larger point about regulation, the Act’s own timeline has moved. High-risk obligations under Annex III were originally scheduled to take effect in August 2026. As of mid-2026, EU lawmakers agreed, through the Digital Omnibus on AI, to defer standalone high-risk obligations to December 2027, largely because the technical standards and conformity infrastructure needed actually to comply were not yet ready. Prohibited practices and AI literacy duties have applied since February 2025, and general-purpose AI model obligations since August 2025. If you have EU exposure, please verify the current dates against live guidance rather than relying on fixed dates you see elsewhere, including here, because they can change.

The functional role of the Act, though, remains stable even when its dates change. It does not hand you an operating model like NIST, nor does it give you an auditable system like 42001. It tells you where society has decided the stakes are highest. Its risk tiers are, in effect, a pre-built prioritization map that reflects a broad consensus about where AI does the most harm. That is useful to you even if you never touch the EU market.

So here is the whole distinction, and it is the load-bearing idea of this entire piece.

NIST tells you how to think. ISO 42001 tells you how to organize and prove it. The EU AI Act tells you what you are legally required to do and where the highest stakes lie. Guidance, management system, regulation. Three layers of one problem, not three items on a menu. When companies treat them as interchangeable, they end up doing all three poorly.

The Enterprise Checklist Is the Disease, Not the Cure

Now the provocative part, and I mean it literally rather than as a rhetorical flourish. The enterprise governance playbook that everyone holds up as the standard to imitate is, for a company whose risk and operating models differ from those of the enterprise it was built for, actively harmful. Copying it does not make your governance more serious. It makes it more fake.

Here is why, and there are three mechanisms.

The enterprise optimizes for documentation because documentation is what survives an audit.

A large regulated company has armies of auditors, regulators, and litigators pointed at it. In that environment, the rational move is to generate a paper trail proving that a process was followed, because the paper trail is the thing that gets examined when something goes wrong. This produces a specific pathology. Governance activity becomes measured by artifacts produced rather than harms prevented. Model cards for everything. Risk assessments for everything. Attestations for everything, including the internal meeting notes summarizer. When a company copies this without inheriting the scrutiny that made it rational, it ends up with the pathology stripped of its context. It produces the same undifferentiated pile of paper, except now the one genuinely consequential system gets the same shallow treatment as the harmless one, because attention is finite and it gets spread evenly across things that do not deserve equal attention. Volume of paperwork masquerades as depth of oversight. It is the opposite.

The enterprise checklist assumes a way of building software that you may have correctly abandoned years ago.

Enterprise governance gates were designed for waterfall delivery. Design review, then build, then a formal validation stage, then a deployment approval. A distinct, sequential, heavyweight process with a committee at each door. That is not how a company shipping on foundation model APIs works. You prototype against an API on Monday, ship an MVP by Friday, and iterate on real user feedback the following week. When you bolt a waterfall governance process onto an iterative build process, one of two things happens, and both are bad. Either governance becomes the bottleneck that kills your speed, or your teams quietly route around governance entirely, which means the policy exists and the practice ignores it. Governance theater is usually the second outcome. The policy is real. The compliance is fictional.

Committees are where accountability goes to die.

The enterprise loves a governance committee, and there is a reason. In a large organization, a committee distributes accountability so widely that no single person can be blamed, which is a feature if your deepest institutional instinct is blame-avoidance. But distributed accountability is not accountability. It is its absence, dressed formally. When a council reviews a summary slide and nods, no one has actually decided anything, and no one can actually be held responsible when the system fails. A company that imports this structure before it needs it also imports the dilution. Below a certain scale, you do not need a council to make an AI risk decision. You need one named person with the authority to say no, and the spine to use it. The council is what you build when you have grown too large for that to be possible. Treating it as a marker of maturity before you have reached that point is confusing the scar tissue of scale for a sign of health.

The deeper error underneath all three is a category mistake about what a framework is. The frameworks are tools. The enterprise applies them at enterprise depth because it faces enterprise risk, enterprise scrutiny, and enterprise sprawl. When you copy the depth without the underlying conditions, you get cost without benefit. You get the theater.

Depth Should Track Risk, Not Imitation

Here is the reframe, and it is the reason this topic is worth a whole issue rather than a footnote. The question that actually determines whether your governance is real is not how much of the enterprise playbook you have reproduced. It is whether the depth of your controls tracks the actual risk of each system. Uniform depth is the tell of theater, in either direction. A portfolio with identical documentation for every system suggests that no one looked closely at any of them.

Consider why the enterprise playbook encodes uniform, heavyweight processes in the first place. A large enterprise runs hundreds or thousands of AI systems, many undocumented, spread across business units that do not communicate with one another, built over the years by people who have since left. Its hardest governance problem is often simply knowing which AI it has, and its second-hardest is imposing any consistent practice across a workforce large enough that some meaningful fraction will ignore whatever policy gets published. Uniform process is a rational, if blunt, response to scale, legacy, and coordination failure. It is a solution to problems that come from bigness.

If those are not your dominant problems, adopting a solution to them would add overhead without a clear benefit. The heavyweight, uniform apparatus was never designed to improve governance. It was designed to make governance consistent across an organization too large and too fragmented to govern any other way. Reproducing that uniformity without that fragmentation does not buy you rigor. It buys you the appearance of rigor, spread so thin that your highest-stakes system and your lowest-stakes system receive the same shallow glance.

The alternative is to let depth follow risk. Concentrate real scrutiny, real testing, and real monitoring on the systems that make or shape consequential decisions about people, and deliberately spend almost nothing on the ones that cannot hurt anyone. This is not the discount version of governance. It is more demanding because it requires you to assess each system rather than rely on a policy that treats them all the same. Uniform process is the easy answer. Risk-matched depth is the honest one. And the frameworks, read correctly, are built to support exactly this, which is what the rest of this comes down to.

Start With What Is Real

The mapping starts by refusing to start with the frameworks. Do not open the NIST document. Do not open the ISO standard. Open a blank spreadsheet and inventory every AI system you actually have in production or active development, and for each one, answer plain questions. Who is affected by its outputs? What is the worst plausible thing that could happen if it fails or behaves strangely? Does it make or materially shape a decision about a person, hiring, credit, pricing, health, or access to a service? Is it customer-facing, internal-only, or sold as a product?

This inventory, built from reality rather than from a framework’s table of contents, is the ground on which everything else stands. And it is, not coincidentally, exactly what NIST’s Map function is for. Map is the discipline of understanding context and consequence before you reach for controls. You are already doing NIST, and you did not need to read NIST to do it.

From that inventory, the frameworks slot into distinct roles, each doing the one job it is good at.

NIST becomes your operating model, the rhythm your teams actually follow.

Govern names who owns the risk call and what your tolerance is. Map is the inventory exercise, made repeatable for every new initiative rather than done once. Measure is the testing and monitoring you define per system, scaled to its risk. Manage is where the real deploy decisions get made and written down. Because NIST is voluntary and flexible, it is the language of your day-to-day, in standups and product reviews, not a bureaucracy you erect. It asks you to build a habit, not a department.

ISO 42001 becomes your structural backbone and your maturity path, applied later than you think.

You do not build a management system on day one. Once your NIST rhythm is real and repeated, 42001 becomes a lens for auditing what you already do. Is there a written policy, even a short one? Is there a named owner, even a fractional one? Do your risk assessments get reviewed on any cadence at all? You can extract enormous value from 42001’s clause structure as a gap-analysis tool without ever hiring a certification body. And if a customer eventually demands the certificate, often in financial services or healthcare, you will already have the scaffolding, which turns a brutal certification scramble into a manageable one.

Regulation becomes your prioritization filter, not a parallel track.

Do not run EU AI Act compliance as a separate governance universe. Lay its risk classifications over your inventory and let them pull your depth toward the systems that deserve it. If a system lands in a high-risk category, whether or not you touch the EU today, that is your signal to apply your most rigorous NIST testing and to formalize that system’s documentation first. Regulation tells you where the stakes concentrate. Let it concentrate your effort there instead of smearing rigor evenly across a portfolio where most systems do not warrant it.

Start with the inventory, which is the map itself. NIST provides the ongoing discipline, while ISO 42001 offers the structure that discipline builds over time. Regulations act as the filter, guiding where to dive deeper. At no point is an entire framework adopted, and that’s not a compromise. It’s intentional.

Minimal Governance That Is Real

Right-sized governance is not a smaller pile of the enterprise’s paperwork. It is a different, smaller set of things applied at depths that vary with risk rather than uniformly. Four components carry almost all the weight.

An honest inventory with risk tiers is the foundation, and a well-kept spreadsheet is genuinely fine at first with every system, its owner, what it does, and its tier. A simple structure works. Low risk for internal productivity tools and non-consequential recommendations. Medium for systems that materially affect operations or customers. High for systems that make or shape consequential decisions about people. Prohibited for things you have chosen not to build, regardless of feasibility. The discipline of keeping it current beats the precision of the cut points.

A short policy with real ownership comes next. A few pages, not a few dozen. Your principles, who owns the risk call, and what has to be true before a system moves from prototype to production. The load-bearing word is owner. One named person with the authority to stop a launch, even if the role is a slice of a bigger job. Accountability that lives on an org chart and never in an actual decision is not accountability. It is decoration.

A risk register and testing approach, calibrated by tier, is where governance grows teeth. For medium and high-risk systems, document the risks, the mitigations, and the residual risk after mitigation, and pair that with testing that fits the tier. A high-risk system that touches credit or hiring undergoes bias testing, adversarial robustness checks, and human oversight review before it ships. A low-risk summarizer earns none of it. The error to avoid runs in both directions, skipping testing on your highest-stakes system and burying your lowest-stakes one under processes it does not need. Uniform depth is the enterprise disease. Do not import it.

Monitoring and incident handling close the loop. Once a system is live, someone watches it at a depth proportional to its tier. High-risk means active monitoring for degradation, drift, and anomalous output, plus a defined answer to what happens and who gets called when it misbehaves. Lower-risk may need only periodic spot checks. What matters is that a process exists at all, so you learn about problems before a customer or a regulator does.

Those four, kept honest, are a governance program a lean team can actually run and that will still hold up under real scrutiny. Everything past this is refinement. None of it is a prerequisite for having something real.

What This Looks Like When It Is Real

Picture a roughly 250-person B2B software company that sells workforce analytics. It had shipped AI features fast, and when a large customer’s security team asked about its AI governance, the company did what most do. It found a governance template, started drafting a policy citing all three frameworks, and floated the idea of a cross-functional AI review board to sign off on every AI feature.

That board would have reviewed everything at the same shallow depth and decided almost nothing, which is where this story usually ends. Instead, before building any of it, the company spent an afternoon on an inventory. Four AI systems mattered, including an internal tool that summarized meeting notes, a model that routed inbound support tickets, a feature that recommended next actions to customer administrators, and a capability that scored employees for attrition risk and surfaced those scores to their managers.

Written down side by side, the systems were obviously not equivalent. The meeting summarizer could embarrass someone with a bad summary at worst, so it was entered into the inventory as low risk and received no further review. The ticket router and the recommendation feature were medium risk, affecting operations and customer experience, but making no consequential call about a person, so they got a short risk entry and a basic monitoring check, nothing more.

The attrition-scoring system was of a different kind. It shaped decisions about people’s jobs, placing it squarely in the territory the EU AI Act treats as high-risk employment use, regardless of whether the company had EU customers that quarter. So that system, and that system alone, got the full treatment. Bias testing across demographic groups before the scores ever reached a manager. A documented human-oversight step, so that a score could never trigger an action on its own. Active monitoring for drift once it was live. And a single named owner is personally accountable for whether it remains fit to run.

The whole program took weeks, not quarters, and it fit on a handful of pages. The customer’s security team was satisfied because the answers to their hardest questions were about the one system that warranted hard questions. And the company had avoided the outcome that it had been an afternoon away from choosing: a review board that would have spread attention evenly across four systems and looked hardest at the one that could hurt someone least.

Operationalizing Without Building a Bureaucracy

Concepts are cheap. The test is whether this survives contact with how work actually happens. Here is what it looks like when each framework is operationalized rather than framed.

NIST gets embedded into workflows and never runs beside them. Map happens during design and scoping, captured in the kickoff template your team already uses, with a field or two added for risk tier and affected stakeholders. Measure happens within the testing you already do, with extra evaluation criteria layered in for medium and high-risk systems, bias or robustness checks added to the existing suite rather than run as a separate exercise anyone can skip. Manage happens at the same go/no-go point you already have for any launch, with an explicit risk sign-off required above the low tier. Govern is the periodic check, quarterly suits most organizations, where the owner reviews the inventory, any incidents, and whether the tiers still reflect reality. The governing rule is that the governance step should be the path of least resistance within an existing workflow, not a gate that teams learn to circumvent. The moment governance becomes a detour, it becomes theater.

ISO 42001 gets layered in over time, as evidence, not aspiration. Do not attempt full alignment at the start. After the NIST rhythm has run for a few months and produced real artifacts, actual assessments, actual test records, and actual incident logs, it begins to formalize. Bring the policy in line with the standard’s expected content. Stand up a light internal audit, even a semiannual self-review against the clauses. Institute a management review in which leadership actually assesses governance performance and makes adjustments. This is the shift from “we do sensible things” to “we can prove we do sensible things consistently,” which is precisely the base that supports certification later, if you ever decide the certificate is worth the audit.

The EU AI Act gets applied where the law demands it and, crucially, nowhere else. If systems fall into high-risk categories, they receive full rigor, documented risk management, data governance, technical documentation, human oversight, and conformity assessment ahead of the applicable deadline. But refuse the reflexive overcorrection of applying that rigor to everything out of anxiety. A low-risk internal tool does not need a conformity assessment. Treating it as though it does is not caution, it is the enterprise disease wearing the mask of prudence. The Act is risk-based on purpose, so that the burden concentrates where the stakes are highest. You need to mirror that logic internally instead of flattening your program to the standard your single most regulated system requires.

Phasing It So It Does Not Collapse

Trying to stand all of this up at once is how governance programs die before they live. Best practices recommend sequencing it over roughly 12 to 18 months, depending on your size and footprint.

Phase one, the first month or two, is an inventory, a short policy with a named owner, and your risk tiers. This is about visibility, and the biggest surprise is almost always how much AI is already deployed and that nobody was tracking it.

Phase two, the next two to four months, focuses on testing and risk management for your medium- and high-risk systems specifically, plus a basic incident process. This is where governance starts changing behavior, because you are now doing something genuinely different for your higher-risk systems than before.

Phase three, the following three to six months, is about mapping your rhythm explicitly onto the NIST functions and beginning to layer in the ISO 42001 structure, formalized policy, internal audit, and management review.

Phase four is expansion and, only if it pays for itself, formalization and certification. Extend coverage to the gaps, strengthen the evidence for whichever frameworks your customers and regulators actually care about, and decide whether ISO 42001 certification is worth the cost. For companies selling into regulated industries or for enterprise buyers with rigorous due diligence, the certificate becomes a real differentiator. For others, the substance, real testing, real monitoring, real accountability, delivers nearly all the value without the badge.

Resist skipping ahead. A company that lunges straight at certification with phases one and two hollow will find itself documenting practices that do not exist, which is the exact theater this whole argument is built to prevent.

Coherent, Not Comprehensive

The companies that get this right are not the ones with the most frameworks or the thickest binders. They are the ones whose governance is coherent, where NIST’s rhythm, ISO 42001’s structure, and the EU AI Act’s priorities reinforce each other instead of running as three disconnected compliance rituals that share nothing but a slide.

Coherence starts with a decision that is trivial to state and genuinely hard to hold under pressure. Start with what is real, your actual systems and their actual risk, rather than with what a framework says you should have. Scale governance on purpose, adding depth and formality as your footprint and maturity grow, rather than importing an enterprise checklist wholesale just because it photographs well in a board deck.

And here is the thing worth sitting with. None of the three frameworks asks you to become a miniature enterprise. NIST is voluntary by design. ISO 42001 explicitly permits proportionate implementation scaled to context. Even the EU AI Act builds its entire structure around risk tiers, so that obligations concentrate where harm is greatest. The frameworks themselves are telling you that matching depth to risk is not the discount version. It is the intended version. The only people insisting otherwise are the ones selling you the enterprise checklist.

The real risk was never that your governance looks leaner than a global bank’s. The real risk is a governance program that looks good on paper but changes nothing, that produces the prop document, the unread policy, the committee that decides nothing, while your one genuinely consequential system ships with the same shallow attention as your meeting-notes bot. That is the failure that ends careers and reputations, and it is the failure the enterprise checklist quietly walks you into while making you feel responsible the whole way.

So build something matched to what you actually carry. Build something a real person is accountable for, and that actually shapes what gets shipped. Fake governance is worse than none, because at least none lies to you about what you have. The goal was never to be comprehensive. It was to be real.