Regulatory Compliance Frameworks for Enterprise AI

Enterprises are already absorbing the financial losses. The question is no longer whether AI governance costs money. It is whether you pay for governance upfront or pay for remediation afterward. EY's 2025 survey of nearly a thousand C-suite leaders across more than twenty countries found the overwhelming majority of organizations had already taken financial hits from AI-related risks. Meanwhile, McKinsey's 2025 data shows that a large majority of enterprises have deployed AI in at least one business function, but only a small fraction have a formal governance framework in place. That gap between deployment and governance is the actual compliance problem, and it is the problem this article is designed to address.

The EU AI Act, NIST AI Risk Management Framework, and ISO/IEC 42001 are the three frameworks currently shaping enterprise AI governance globally. They are not interchangeable, but they compose well. And if you read them carefully, past the documentation checklists and the certification prep guides, they are not asking for paperwork. They are asking for architecture.

What the Three Major Frameworks Actually Require When You Read Past the Documentation Checklists

The EU AI Act is a risk-tiered regulation. That means the first architectural question it forces is classification: what kind of system are you building, and does it qualify as high-risk? High-risk designation triggers requirements for human oversight, bias monitoring, and technical documentation that cannot be retrofitted after deployment. The Act's penalty ceiling was deliberately set above GDPR's maximum, which is a legislative signal worth taking seriously. Lower-tier AI Act violations carry lower penalties than GDPR's ceiling, but the top of the range communicates that legislators treat AI infractions as categorically more serious than data-protection ones. The General Purpose AI obligations became active in August 2025, with Commission enforcement beginning August 2026 and a grandfathering window for systems already on market.

NIST AI RMF is technically voluntary. In practice, that designation is a misnomer. The CFPB, FDA, SEC, FTC, and EEOC have all cited NIST AI RMF principles in their own published expectations, which means sector regulators have effectively incorporated it into their oversight posture. The framework's four functions, Map, Measure, Manage, and Govern, are a continuous loop, not a one-time audit. The Govern function in particular requires accountability structures and organizational culture, not just documented policies. If you treat it as a filing exercise, you have misread it.

ISO/IEC 42001, published in December 2023, is ascending faster than most compliance teams anticipated. Enterprise buyers now cite it alongside SOC 2 in vendor due diligence. That makes it a market-access requirement in practice, even where it carries no legal force. For organizations already certified under ISO 27001, the structure is familiar. The management system model is the same. You can layer 42001 on top with reasonable efficiency. For organizations starting from scratch, the lift is heavier, but it is not redundant with the other frameworks.

The crosswalk insight that most compliance teams miss: these frameworks are designed to compose. Running NIST for risk management, ISO 42001 for systematic AI management, ISO 27001 for information security, and the EU AI Act for high-risk obligations together reduces jurisdictional fragmentation rather than multiplying it. The duplication is lower than it looks from the outside.

There is, however, a structural gap that none of them fully address. Every framework was designed around a human at the keyboard. The compliance language assumes a person is present, reviewing, approving. Autonomous agents executing tool calls without continuous human oversight strain that assumption at its foundation. NIST launched a dedicated agentic AI standards initiative in early 2026 to close this gap, but enterprises cannot wait for the standard to be finalized before they build. The implication for your architecture is direct: compliance is not a documentation exercise because the frameworks implicitly require behaviors, logging, scoped access, human override capability, that only exist if built into the system from the start.

How Autonomous Agents Broke the Assumption That a Person Is Always in the Loop

The compliance surface shifted when agents started taking real-world actions: reading files, submitting forms, querying databases, sending messages, all without a human reviewing each step. This is not a future scenario. It is the current deployment pattern for a large share of enterprise AI use cases.

Model Context Protocol, released by Anthropic as an open standard in November 2024, is the mechanism that enabled this at scale. MCP solved a genuine problem: the fragmented, bespoke integration work that had made connecting AI to enterprise systems expensive and slow. Its three primitives, Tools (functions the AI can invoke), Resources (data it can read), and Prompts (reusable prompt templates), define exactly what an agent can do in a given integration. Adoption moved faster than governance adapted, which is the normal pattern with enabling standards.

The compliance implication sits in a detail that the protocol's documentation does not foreground: MCP shipped without built-in authentication, delegating all security enforcement to implementers. When an agent calls a tool through an MCP server, that action is a system event. The EU AI Act and NIST AI RMF both expect it to be logged, scoped, and attributable. The protocol does not enforce any of this automatically.

Enterprises that deployed MCP-connected agents quickly inherited a specific governance gap: agents operating with broad service-account permissions, no per-user scoping, and no audit trail that compliance could use. This is not a configuration error. It is a structural consequence of how the protocol was designed, and it has to be designed out at the architecture level, not patched in after the fact.

Why Inheriting Permissions from Source Systems Is the Only Way to Maintain Compliance at Agent Scale

The fast deployment path is to grant the MCP server a broad service account and let it access whatever the AI needs. This approach is operationally convenient and compliance-catastrophic.

The logic is simple. When an agent answers a question, the answer must draw only from data the requesting user is already authorized to see. If the agent can surface information the user cannot access through normal channels, the AI has become an access-control bypass. That is precisely what the EU AI Act's high-risk provisions and NIST's Manage function are designed to prevent.

Permission inheritance solves this at the architectural level. The AI system reads access rights from the source system, whether that is Salesforce, SharePoint, a data warehouse, or an internal API, and enforces them automatically. There is no separate access-control redefinition per AI tool. This matters because redefinition breaks down at scale. Each new AI surface that requires its own permission configuration creates drift: different rules in different places, inconsistent enforcement, and audit findings waiting to be discovered.

Least-privilege design at the MCP layer is the practical mechanism. An MCP server for a CRM should carry the minimum permissions necessary for its defined use case, not the maximum permissions available to a service account. Tool-level scoping, read but not write, retrieve but not send, is the implementation pattern.

Enterprise-Managed Authorization, promoted to stable status by the MCP team in 2026 and adopted by Anthropic, Microsoft, and Okta among others, standardizes centralized identity-provider control over which users can connect to which MCP servers. This is a meaningful step. It governs connection. It does not govern what happens after connection; runtime authorization for individual tool invocations still requires organization-level controls that EMA does not prescribe.

For regulated industries, the audit implication is unambiguous. If permissions are not inherited and scoped, the audit log captures actions but not the authorization chain. That log is incomplete for any framework that demands accountability, which is all three of the major frameworks discussed here.

What an Audit Trail Actually Needs to Capture When Agents Take Actions Autonomously

The NIST AI RMF Govern function and ISO 42001 both require accountability structures. In practice, that means the ability to answer a specific set of questions after the fact: who authorized this action, under what scope, at what time, using which tool version. The EU AI Act adds a higher bar for high-risk systems specifically: technical documentation and logging sufficient to enable post-hoc review of system decisions.

A standard application log does not meet this bar for agent actions. An adequate agent audit trail captures the identity of the user or agent that initiated the request; which MCP tool was called and which version of that tool was active at the time; what data sources were queried and whether access fell within the user's authorized scope; the output returned and any downstream actions triggered; and whether a human was in the loop or the action was fully autonomous.

Version control of tools is not optional for auditability. If a tool definition can change silently after deployment, and the known attack pattern called "rug pull" demonstrates that this is a live threat, then the audit log captures the action but not what the tool was actually doing when it took it. The action and the tool state at the time of the action must be tied together in the record.

Shadow AI compounds the logging problem considerably. When teams spin up their own MCP servers outside central governance, those servers produce no logs visible to IT or compliance. The governance record has gaps the organization may not discover until an external audit surfaces them. At that point, the remediation cost is substantially higher than the governance cost would have been.

The architectural fix is to enforce logging at the MCP gateway or registry layer, not leave it to individual server implementers. Some implementers will handle it well. Some will not. Centralized capture is the only approach that survives team-level variation.

The MCP Gateway as the Enforcement Point Where Policy, Logging, and Access Control Converge

A gateway sits between AI clients and MCP servers as a reverse proxy and policy enforcement layer. Every agent request passes through it before reaching enterprise systems. This placement makes it the natural home for every compliance control that needs to be consistent across deployments.

The capabilities that belong at the gateway are not optional add-ons. Centralized authentication and authorization. Policy-as-code enforcement using tools like Open Policy Agent. Rate limiting. PII detection and filtering before sensitive data reaches the model. Kill-switches for individual servers or agent identities when something goes wrong. Without a gateway, each of these controls has to be implemented by individual MCP server authors, which produces exactly the fragmentation and inconsistency that frameworks like NIST and ISO 42001 are designed to prevent.

Context bloat is a practical constraint with compliance implications. Each MCP server injects tool definitions into the agent's context window. As the number of connected servers grows, context management becomes a design problem. Gateways that expose only the tools relevant to a given user's role solve this and simultaneously reduce the attack surface. A user who should not have access to the HR system's MCP tools should not see those tool definitions in their context at all.

If an MCP server exposes customer records, patient data, or employee files, the same privacy obligations apply as to any other system handling that data. The gateway is the right enforcement point for redaction and filtering before that data reaches the model, because it is the only layer with a consistent view across all connected sources.

The compliance mapping is direct. A well-configured gateway produces the centralized audit log, enforces scoped permissions, and provides the kill-switch capability that the EU AI Act, NIST AI RMF, and ISO 42001 collectively require. The gateway is where architecture and compliance requirement converge into a single design decision.

Why Governing Context Is What the Frameworks Are Actually Asking For

Access control governs who can ask the agent a question. Context governance governs what the agent knows when it answers. Both are compliance requirements. Only the first is typically treated as an infrastructure problem.

The EU AI Act's human oversight requirements for high-risk systems implicitly demand that the system's reasoning be bounded and explicable. An agent drawing from uncontrolled, ad-hoc context is harder to audit and harder to correct when it produces a harmful output. The framework cannot say "govern your context" in those exact words, because the technical architecture did not exist when the legislation was drafted. But that is what the oversight requirements functionally require when you apply them to agent systems.

Domain context matters for accuracy and for liability simultaneously. An agent answering a compliance question using outdated policy documents gives a wrong answer. If that answer informs a business decision or a client interaction, the organization may bear responsibility for the outcome. This is not a hypothetical. It is the failure mode that makes context governance a legal concern, not just a quality concern.

Context governance in practice means grounding agents in specific, version-controlled document sets rather than open-ended retrieval; scoping which data sources an agent can draw from based on the user's role and the task at hand; and tracking which version of a prompt or skill was active when a response was generated, because that information is material to both audit trails and incident investigation.

The skill registry concept operationalizes this. When AI capabilities, prompts, workflows, agent configurations, are stored in a governed registry with version control, ownership records, and access scoping, context governance becomes auditable. Compliance teams can reconstruct what the agent knew and how it was configured at any point in time. That is the standard the frameworks require, described in architectural terms.

The problem of five teams rebuilding the same workflow independently is a compliance problem, not just an efficiency one. Five versions of the same prompt create five different context configurations, five different audit trails, and five separate opportunities for drift from approved behavior. Each of those five drifts is an audit finding waiting to be written.

How Department-Level Deployment Creates Governance Risk If Each Team Sets Its Own Rules

Most enterprise AI deployments do not start with a company-wide rollout. They start with one team's problem: RevOps connecting an agent to Salesforce, engineering using an MCP server for GitHub, support automating ticket triage. This is the normal adoption pattern and, in isolation, not inherently problematic.

The problem emerges when each team configures its own MCP servers and access rules independently. Governance becomes inconsistent across the organization: different permission models, different logging practices, different prompt versions, none of them visible to the others. Shadow AI is the natural endpoint of this pattern. Teams spin up integrations that IT does not know about, compliance cannot audit, and no one maintains. The documentation the frameworks require simply does not exist for these deployments.

Gartner's 2025 research found that organizations with AI governance platforms are substantially more likely to reach high-value AI outcomes than those without. Governance infrastructure is a performance multiplier, not just a compliance cost. That finding is worth holding onto when the budget conversation comes.

Scoped department-level MCP servers are not the problem. They are actually the right architecture. The problem is when each scoped server carries its own ungoverned access rules and produces no centralized logs. The fix is a shared governance layer, authentication, logging, version control, with department-level scoping applied within it. Each team gets a server configured for its context and its permissions. The governance infrastructure is shared, not rebuilt per team.

MIT Sloan Management Review's 2025 research on AI governance rollouts found that organizations attempting full governance implementation in a single phase failed at a substantially higher rate than those using phased approaches. Department-by-department deployment is the right sequence, provided each phase feeds into shared governance infrastructure rather than producing isolated silos. The sequence matters. The accumulation matters more.

Building a Shared Skill Registry That Satisfies Version Control, Ownership, and Audit Requirements

A shared drive of prompts does not satisfy compliance requirements. There is no version history, no ownership record, no access scoping, and no way to determine what version was active when a given agent action was taken. It is operationally convenient and compliance-invisible.

A governed registry requires four things to be defensible. Version control: every change to a skill or prompt is tracked with timestamps and author attribution, satisfying EU AI Act technical documentation requirements and NIST audit expectations. Ownership: each skill has a named owner accountable for its behavior, satisfying ISO 42001's accountability structure requirements. Access scoping: skills are published with defined access rules, so a RevOps prompt is not available to engineering unless explicitly shared, preventing context bleed across domains. Deprecation and rollback: when a skill is updated, the previous version remains available for incident investigation, which is critical for the post-hoc review that high-risk EU AI Act provisions require.

The reuse argument, reframed as a compliance argument, is more compelling in most organizations. When five teams rebuild the same workflow independently, they produce five audit trails that diverge, five permission configurations that may be inconsistent, and five skill versions that compliance must review separately. A single governed skill, reviewed once and shared to the teams that need it, is more defensible and less expensive to maintain.

Domain experts, not central IT, should own the skills relevant to their context. A legal operations team understands their compliance prompts better than a platform team does. The governed registry enables this: domain experts control the substance of their skills, while the registry provides version control, audit logging, and access scoping as shared infrastructure. Ownership within a governed system is not the same as ungoverned autonomy.

Model-agnostic registry design matters for long-term compliance continuity. If business context, permissions, and skill configurations are tied to a specific LLM, a model transition forces re-validation of every governed workflow. That re-validation is expensive and introduces a window of compliance uncertainty. A registry that travels with the organization regardless of the underlying model avoids this problem entirely.

A Practical Sequence for Enterprises Mapping Their Current AI Deployment to Framework Requirements

Start with inventory, not strategy. Before selecting a framework or hiring a compliance consultant, map what is already deployed. Which teams are running AI tools? Which MCP servers exist, whether centrally provisioned or shadow-deployed? What permissions do those servers carry, and are those permissions per-user or service-account-wide? The inventory will be uncomfortable. Do it anyway. You cannot govern what you cannot see.

Classify before you build controls. Apply the EU AI Act's risk-tiering logic to your current and planned systems. High-risk designation changes the technical requirements materially: human oversight mechanisms, bias monitoring, technical documentation. Systems that do not meet high-risk thresholds still require governance, but the architecture is lighter. Knowing which is which before you design the controls saves significant rework.

Stand up the gateway before you expand integrations. If your organization is in the early-to-mid stages of MCP adoption, the highest-leverage compliance investment is a centralized gateway before additional MCP servers are connected. Every server added without a gateway in place adds to the governance debt. Every server added through a gateway adds to a consolidated audit record. The sequencing is straightforward.

Build the registry in parallel with the gateway. The skill registry and the gateway solve related but distinct problems. The gateway governs what happens at runtime. The registry governs what the agent is configured to do. Both are necessary. Neither replaces the other. Starting them in parallel, even at small scale, means your governance record begins from the start of your governed deployment, not six months after the fact.

Adopt the NIST AI RMF Map function as your ongoing practice, not your launch checklist. Map requires cataloging AI use cases, understanding their context, and identifying risk factors. This is not a one-time exercise because the deployment landscape changes continuously. New agents, new tools, new integrations, each represents a new entry to the Map. Organizations that treat mapping as an annual audit fail the Govern function's implicit standard of continuous accountability.

Use Texas TRAIGA as a template for state-level exposure. Effective January 2026, TRAIGA names substantial NIST AI RMF compliance as an affirmative defense against enforcement. This model is already being watched by other states considering similar legislation. Substantial NIST compliance, documented and auditable, is becoming the legal safe harbor in jurisdictions that adopt this template. The work to achieve it overlaps substantially with what ISO 42001 and EU AI Act require, which is exactly why the composability of these frameworks matters.

Finally, do not defer governance until the deployment is mature. The McKinsey data on the gap between AI deployment and formal governance frameworks is a description of where most enterprises currently stand, not where they should aim. The cost of retrofitting governance into a system with broad service-account permissions, ungoverned shadow deployments, and no audit trail is substantially higher than the cost of building governance into the architecture from the first production deployment. The EY data on absorbed losses confirms this at the organizational level. The frameworks confirm it at the regulatory level. Build the governance layer first. Let the deployment expand into it.