Enterprise AI Guardrails May Matter More Than the Frontier

Forget the AI frontier. Customers are pushing enterprises for more guardrails on AI already in use, and experience with PCI DSS provides a useful model.

The regulatory honeymoon for AI is over. Recent disclosures have prompted conversations about slowing the frontier and mandating controls. One of the few areas of agreement is that controls should sit outside the models, with independent verification.

What happens next is being debated, but regulators are moving. The European Union AI Act is phasing in security obligations, including buyer liability. In the United States, the NIST AI Risk Management Framework is being adopted as a standard for reasonable care. Globally, the OWASP Top 10 for LLM Applications has become a common reference in security reviews, and ISO/IEC 42001 certification is appearing in procurement documents.

That means model developers aren’t the only ones on the hook. Security obligations and risks also fall on enterprises using models already released, particularly for high-risk use cases. The wrong answers on a customer security questionnaire or in an RFP response could stall a B2B deal.

PCI DSS Shows the Way

Fortunately, we’ve seen this movie before. Twenty years ago, web application security mostly relied on periodic code audits, static scans, and developer discipline. Then PCI DSS Requirement 6.6, released in 2006 and enforced from 2008, mandated that organizations handling cardholder data must either review all application code for vulnerabilities or install automated technical controls. Later, the option for code review went away and technical controls were required.

But PCI DSS did not start as law. It started with a contractual standard that reshaped the market, probably faster than legislation would have because contracts move faster than government statutes.

Similarly, organizations are now feeling pressure for guardrails on deployed AI not from regulators but from customers and partners—through security questionnaires, RFP clauses, and insurance policy requirements.

Solve the Operational Problem and Compliance Will Follow

That pressure can be hard to address, because AI governance is not only about policy. It’s about continuous technical evidence.

Many enterprises I talk with are running a half dozen or more models in production, frequently chaining or orchestrating them so the output of one provides input to another. Imagine demonstrating system-wide enforcement of any one policy—such as preventing model output from containing PII—in these conditions. Manually auditing multiple, individually configured models would drain developer time. Plus most organizations struggle with unsanctioned and high-risk AI use such as employees pasting sensitive data into consumer AI tools or SaaS providers quietly enabling new AI features. Yet liability falls entirely on the enterprise.

In such challenging scenarios, the requirements can be distilled to one simple task: Demonstrate that you can continuously constrain model input and output while recording that activity for verification. As applications call models, agents invoke tools, and models take actions or trigger workflows, what needs to be controlled is the action—the tool call, the API request, the workflow trigger.

Move Security to the Inference Path

That action is the enforcement point application security experts have spent 20 years building for application traffic. Especially when inference is routed through shared infrastructure, that inference path becomes the ideal control point across models and even across unsanctioned AI use. AI inference traffic needs to be delivered, inspected, authenticated, and governed like any other important app interaction, based on where the traffic is coming from and what it is trying to do. Unlike manual auditing, inference traffic governance will scale.

How to Start

Given where regulations are heading, organizations need to start three things now:

1. Map your liability surface, from SaaS APIs and hosted endpoints to shadow AI.
2. Decouple security policy and enforcement from models and put it in the inference path.
3. Ensure audit trails are generated beyond the control of models and agents, which have been shown to try to alter records of their own actions.

What qualifies as adequate monitoring and enforcement is still being determined, but your enterprise operations and security teams know what is genuinely enforceable, what control costs in latency and complexity, and where a well-intentioned rule might have the wrong result. Get them involved now. The security risks and obligations attached to AI use are real, and your customers and executives undoubtedly care more about those they face today than about the frontier model threats of tomorrow.