Customer Contracts, Not Regulators, Are Forcing Enterprise AI Guardrails

AI regulation is arriving through procurement, not statute. Customers are demanding guardrails on AI systems already deployed in enterprises, and the wrong answer on a security questionnaire or RFP response can stall a B2B deal outright, according to a new analysis on Unite.AI.

The argument is simple: the regulatory honeymoon for AI is over, and one of the few areas of agreement is that controls should sit outside the models, with independent verification. Model developers aren't the only ones on the hook — security obligations and liability also fall on enterprises using already-released models, particularly in high-risk use cases.

What's actually changing in the rulebooks?

Regulators are already moving on several fronts:

• 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.
• The OWASP Top 10 for LLM Applications has become a common reference in security reviews worldwide.
• ISO/IEC 42001 certification is appearing in procurement documents.

That last point matters most for practitioners. Procurement language moves faster than legislation, and that's exactly the mechanism the author says will reshape the market.

PCI DSS shows the way

We've seen this movie before, the analysis argues. Twenty years ago, web application security relied mostly 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 either review all application code for vulnerabilities or install automated technical controls. Later, the code-review option disappeared and technical controls became required.

The key lesson: PCI DSS didn't start as law. It started as a contractual standard that reshaped the market — probably faster than legislation would have, because contracts move faster than government statutes. Today's equivalent pressure on AI comes from customers and partners, through security questionnaires, RFP clauses, and insurance policy requirements.

The operational problem behind the compliance ask

What does this change for security teams? The core challenge is that AI governance isn't about policy documents — it's about continuous technical evidence.

Many enterprises are running a half-dozen or more models in production, frequently chaining or orchestrating them so one model's output feeds another's input. Try demonstrating system-wide enforcement of a single policy — say, preventing model output from containing PII — across that stack. Manually auditing multiple, individually configured models would drain developer time.

There's also the shadow problem: employees pasting sensitive data into consumer AI tools, and SaaS providers quietly enabling new AI features. Yet liability falls entirely on the enterprise.

The requirements distill into one task, per the analysis: "Demonstrate that you can continuously constrain model input and output while recording that activity for verification." What needs controlling 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. When inference is routed through shared infrastructure, the inference path becomes the ideal control point across models — and even across unsanctioned AI use. Inference traffic needs to be delivered, inspected, authenticated, and governed like any other important application interaction, based on where traffic comes from and what it's trying to do. Unlike manual auditing, inference traffic governance scales.

How to start now

The analysis recommends three immediate steps:

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

What qualifies as adequate monitoring and enforcement is still being settled. But enterprise operations and security teams already know what's genuinely enforceable, what control costs in latency and complexity, and where a well-intentioned rule might backfire. Get them involved now — because customers and executives care more about the AI risks they face today than about frontier-model threats tomorrow.