· 12 min read

The Compliance Theatre

SOC2, ISO 27001, NIST, and the EU AI Act were not designed for autonomous agents that hire humans, coordinate with other agents, and spend money on your behalf. We need outcome guarantees, not process certifications.

By NOEVA Foundation

A company passes its SOC2 Type II audit. The penetration test comes back clean. The ISO 27001 certificate is framed in reception. The privacy policy references GDPR fourteen times.

Then an autonomous AI agent, operating within the company’s certified infrastructure, hires a human to photograph someone’s home address. Every system involved was compliant.

This is not a hypothetical. This is the gap between what current standards certify and what current technology does.

What Standards Actually Certify

Every major compliance framework in use today shares the same fundamental architecture: they certify process, not outcomes.

SOC2 certifies that you have security controls. It does not certify that those controls prevent harm. A SOC2 Type II audit verifies that your controls operated effectively over a period. It says nothing about whether the system those controls protect is safe to deploy.

ISO 27001 certifies that you have an information security management system. It does not certify that the information being managed is being used ethically. You can be ISO 27001 certified and still build surveillance infrastructure.

GDPR requires lawful basis for processing personal data. It does not address what happens when an AI agent processes data in ways that are technically lawful but practically harmful. If the user consented to “personalised assistance” and the agent used that consent to build a behavioural profile, the processing may be legal. The outcome is still extraction.

NIST AI RMF provides a risk management framework for AI systems. It is voluntary. It provides categories and subcategories for risk assessment but no enforcement mechanism. A company can adopt the framework, document their risks, and ship anyway.

The EU AI Act classifies AI systems by risk level and imposes requirements on high-risk systems. It is the most ambitious regulatory framework to date. Its enforcement deadline for high-risk systems is August 2026. Autonomous AI agents that can coordinate, spend money, and hire humans are already live. The regulation assumes a world where AI systems are deployed by organisations that can be held accountable. It does not address a world where AI systems deploy themselves.

The Structural Problem

These frameworks share a deeper flaw than being outdated. They are architecturally wrong for the problem they now face.

Every standard listed above works the same way:

  1. Define a set of controls or requirements
  2. Implement those controls within your organisation
  3. Document that the controls exist and operate
  4. Have an auditor verify your documentation
  5. Receive certification

The certification proves that you followed a process. It does not prove that the process prevented harm.

This distinction did not matter much when the systems being certified were databases, web applications, and internal tools. A SOC2 certified payroll system is probably fine. The attack surface is well understood, the controls are mature, and the gap between “has controls” and “prevents harm” is small.

That gap is now enormous.

An autonomous AI agent operating within SOC2 certified infrastructure can:

  • Access user data (within the certified access controls)
  • Make decisions based on that data (within the certified processing framework)
  • Take actions in the real world (outside the scope of any certification)
  • Coordinate with other agents (outside the scope of any certification)
  • Spend money (outside the scope of any certification)
  • Hire humans (outside the scope of any certification)

The certification covers the infrastructure. It does not cover what the AI does with the infrastructure.

The Enterprise Security Guide Problem

The AI coding tools industry has already absorbed this gap into its marketing. Search for “AI coding tools SOC2 compliance” and you will find enterprise security guides that frame compliance as a product feature.

The framing goes like this:

  1. Your enterprise has compliance requirements (SOC2, ISO 27001, etc.)
  2. Our AI tool meets those requirements
  3. Therefore our AI tool is safe for your enterprise

Step 3 does not follow from steps 1 and 2. SOC2 compliance means the tool has security controls around data handling. It does not mean the tool’s outputs are safe, its suggestions are secure, or its behaviour is predictable.

An AI coding assistant that is SOC2 certified and suggests a SQL injection vulnerability in generated code is compliant and dangerous simultaneously. The certification covers the tool’s infrastructure. It does not cover the tool’s behaviour.

This is not a criticism of any specific vendor. It is an observation about the entire compliance framework: the certifications were designed to evaluate whether a system handles data securely, not whether a system behaves safely.

The Jurisdiction Problem

The gap between standards and reality gets worse when you consider that these frameworks vary dramatically across jurisdictions, and that AI systems operate across all of them simultaneously.

The EU has the most comprehensive framework (AI Act) but the slowest enforcement timeline. High-risk AI system requirements apply from August 2026. The systems those requirements are meant to govern are live now.

The US has executive orders and voluntary frameworks. NIST AI RMF is not enforceable. State-level regulations (Colorado AI Act, California’s proposed bills) are fragmented and inconsistent.

The UK has a “pro-innovation” framework that deliberately avoids sector-specific AI regulation, relying instead on existing regulators to apply AI principles within their domains. The result is uneven coverage: financial AI is well-regulated, social media AI is not.

Australia has voluntary AI Ethics Principles with no enforcement mechanism. The government has flagged mandatory guardrails but has not legislated them.

China has the most prescriptive AI regulations globally, including mandatory algorithmic assessments and content generation rules. But these rules are designed to maintain state control over AI outputs, not to protect individual users from AI harms.

An AI agent operating across these jurisdictions simultaneously faces no consistent standard. It can be regulated in the EU, voluntary-framework-covered in the US, principle-guided in Australia, and prescribed in China. The practical result is that the jurisdiction with the weakest enforcement becomes the effective standard.

We built a Cross-Jurisdiction Compliance Tool to make these gaps visible. If you are shipping AI that operates across borders, you should understand what each jurisdiction actually requires, and where the gaps are.

What Outcome Guarantees Would Look Like

Process certification asks: “Do you have controls?”

Outcome guarantees ask: “Do the controls prevent the specified harms?”

The difference is not academic. It changes what you have to prove.

Process certification (current):

  • We have an access control policy ✓
  • We have an incident response plan ✓
  • We encrypt data at rest ✓
  • We conduct annual penetration tests ✓
  • We log access to sensitive data ✓

Outcome guarantees (needed):

  • An AI agent operating within this system cannot take actions that harm individuals ✓/✗
  • An AI agent cannot spend more than its authorised budget per interaction ✓/✗
  • An AI agent cannot coordinate with other agents without human oversight ✓/✗
  • An AI agent cannot access data beyond what is needed for the current task ✓/✗
  • An AI agent’s constraints cannot be disabled by configuration ✓/✗

The first list is achievable with documentation. The second list requires architectural constraints that are testable, enforceable, and non-optional.

This is what constraint-mandatory architecture is designed to provide. Not a process that can be documented and audited, but constraints that are part of the system itself. If the system runs, the constraints are active. There is no configuration option to disable them.

The Audit Gap

Current auditing frameworks are designed to verify that controls exist and operate over a period. SOC2 Type II, the gold standard, covers a minimum of six months.

AI agent behaviour can change in milliseconds. A model update, a prompt injection, a new skill installation, a context window that includes unexpected data. The system that was audited six months ago may behave completely differently today.

This is not a problem that faster auditing solves. Even continuous monitoring only verifies that controls are active. It does not verify that the controls are sufficient for the current behaviour of the system.

The alternative is constraint-mandatory architecture: systems where the constraints are not a layer on top of the behaviour but the architecture of the behaviour itself. You do not audit whether the constraints are active because the system cannot run without them.

What You Should Do

If you are relying on compliance certifications to evaluate AI safety:

Stop treating compliance as a proxy for safety. A SOC2 badge means the infrastructure has controls. It does not mean the AI operating on that infrastructure is safe. Ask what the AI can do, not what certifications the platform has.

Use our AI Safety Evaluation Tool to evaluate AI systems against constraint-mandatory principles. It tests what the system actually does, not what the documentation says.

If you are building AI systems and pursuing compliance:

Compliance is necessary but not sufficient. Get your SOC2. Get your ISO 27001. But also architect your system so that the dangerous capabilities have non-optional constraints. Document what the AI cannot do, not just what controls you have.

Use our Release Decision Framework to evaluate whether your system is safe to deploy, not just compliant to deploy.

If you are a regulator:

Process certification frameworks need to evolve toward outcome guarantees. The EU AI Act is the closest to this, but even it relies on conformity assessments that can be gamed by documenting the right processes. Consider requiring testable constraints: automated checks that verify AI systems cannot perform specified harmful actions, not just that they have policies against them.

If you are evaluating AI vendors for your organisation:

Ask these questions:

  1. What can the AI do that is not covered by your compliance certifications?
  2. Can the AI’s safety constraints be disabled by configuration?
  3. What happens if the AI’s behaviour changes after your last audit?
  4. Do your certifications cover the AI’s behaviour or just the platform’s infrastructure?

If the vendor cannot answer these clearly, the certifications are theatre.

The Window

We are in the gap between “current standards were written for a pre-agent world” and “new standards have been designed for the current one.” This gap will close eventually. Regulators will catch up. Standards bodies will update.

The question is what gets built in the gap.

If we treat existing compliance as sufficient, we build AI infrastructure that is certified but unsafe. If we recognise that current standards certify process in a world that needs outcome guarantees, we can start building the architecture that makes those guarantees possible.

The certifications are not useless. They are incomplete. And in a world where AI agents can act autonomously, “incomplete” is the same as “insufficient.”

Use our Cross-Jurisdiction Compliance Tool to understand what standards apply where, and where the gaps are.

The AI Safety Evaluation Tool, Release Decision Framework, AI Behavioural Testing, and AI Psychosis Testing are open tools. Use them on anything.

This post is licensed CC BY-SA 4.0. Share it, adapt it, use it. Just cite us.