Frontier AI Safety, Enterprise AI Control: Different Questions, Same Need

2026-09-23

Executive Summary

• The previous article showed that frontier labs formalize the relationship between capability and control into public policy. But an important distinction needs clarifying: a lab’s safety policy (safety at the model level) doesn’t automatically solve the control problem for a business deploying that model (control at the operational level). These are two different questions, requiring two different layers of solution.
• The NIST AI Risk Management Framework clearly distinguishes different roles in the AI lifecycle — including AI developer (the party designing and training the model) and AI deployer (the party putting that model into use in a specific context) — each with different risk-management responsibilities. A model trained to be safe by the developer’s standards isn’t automatically safe once a deployer grants it unrestricted access to internal systems.
• The question a frontier AI developer asks is fundamentally: “how do we prevent an increasingly capable model from causing severe harm at scale?” This is a model-level safety question, applying uniformly across every way a model might be used.
• The question an enterprise deployer — your business — asks is entirely different: “how do we let AI do more useful work in my organization, without letting it do things my organization doesn’t want?”
• Mapping frontier safety concepts (Capability Threshold, Safeguards, periodic review) onto enterprise governance concepts (permission tiers, control layer, authority profiles) isn’t an arbitrary analogy — it reflects exactly the developer/deployer role structure NIST has already formalized.

The previous article made an important point: frontier labs have formalized the principle “rising capability requires correspondingly rising control” into public policy. But an easily overlooked question remains: who does that policy protect, from what — and does it automatically protect your business when you deploy that model into your own systems?

The short answer is no — and understanding why leads directly to the reason enterprises need their own control layer, independent of any safety commitment made by the model’s developer.

Two Different Questions

Claim: “Model-level safety” (frontier safety) and “operational-level control” (enterprise control) are fundamentally different questions, corresponding to two different roles in an AI system’s lifecycle.

The NIST AI Risk Management Framework clearly distinguishes the different roles participating in an AI system’s lifecycle, including two important ones for this article: the AI developer — the party designing and training the model — and the AI deployer — the party putting that model into use in a specific context. The framework emphasizes that risk-management responsibility doesn’t stop at the developer — the deployer carries its own responsibility, tied to its own specific context of use.

The question a developer like Anthropic, OpenAI, or Google DeepMind asks is fundamentally: “how do we prevent an increasingly capable model from causing severe harm at scale, before it reaches the market?” This is a model-level safety question, applying uniformly regardless of how the model might be used.

The question an enterprise deployer — your business — asks is entirely different: “how do we let AI do more useful work in my organization, without letting it do things my organization doesn’t want?” This isn’t a question about whether the model is globally dangerous — the model you use can be perfectly safe by every developer standard, and still cause serious consequences within your organization if granted the wrong access, exactly as illustrated by the Replit incident covered in Pillar 6.

Why Enterprise Needs Its Own Control Layer

Claim: A model meeting a developer’s safety standards doesn’t mean it’s safe in a deployer’s specific context of use — because the developer can’t know in advance, and isn’t responsible for, how a specific business will grant it authority.

This is exactly the gap frontier safety policy — however carefully designed — can’t fill, because it sits outside the developer’s scope of responsibility. A model classified ASL-2 under Anthropic’s system (the current capability level of most commercial models) makes no commitment whatsoever about how it will behave once a specific business grants it direct access to a production database — exactly what happened in the Replit incident.

In other words: model-level safety and deployment-level control are two independent layers of protection that need to coexist — neither substitutes for the other. This is exactly why an enterprise needs its own control layer, as covered in article 6.13, regardless of how strictly the model it uses complies with developer-level safety policy.

Mapping Frontier Safety Concepts to Enterprise Governance

The core concepts in frontier safety policy (article 6.18) map directly onto enterprise governance concepts covered throughout this series — not an arbitrary analogy, but the same risk-governance structure, applied at two different role levels per NIST’s own classification:

This mapping shows: businesses don’t need to invent an entirely new governance system — the structure is already validated at the developer level; what remains is implementing the equivalent structure at the deployer level, fit to your own organization’s scale and context.

KVM as the Enterprise Control Layer

Within this overall picture, KVM — as introduced in article 6.14 — plays the role of a specific mechanism within the deployer-level control layer. It doesn’t intervene in how a model was trained or the developer’s safety commitments — that’s an entirely different scope of responsibility. Instead, KVM addresses one specific slice of the deployer’s responsibility: ensuring that when an AI agent reasons using organizational data and relationships, it accesses that knowledge through defined operations (Trace, FindEvidence, Resolve) rather than freely accessing raw data.

This once again reinforces what was stated in earlier articles: KVM isn’t the entire solution to AI Control, and it certainly isn’t a solution to frontier-level AI Safety — it’s a deployer-side mechanism, addressing exactly the part of the responsibility that a business, not an AI lab, needs to carry.

Conclusion

Frontier labs’ safety policies and a business’s need for control aren’t the same problem seen from two angles — they’re two different responsibilities, corresponding to two different roles in the AI lifecycle per NIST’s classification: developer and deployer. A model safe by every developer standard still needs its own control layer at the deployer level — because the developer can’t, and isn’t responsible for, controlling how a specific business will grant it authority.

This article is part of the OKELAS AI Control series.

Related articles:

• Why Frontier AI Organizations Prioritize Control — and the Enterprise Lesson
• KVM: Building the Control Layer That Makes Enterprise AI Responsible
• How Far Should AI Be Allowed to Go? The Enterprise Case for an AI Control Layer

→ Contact OKELAS