Pacing the frontier does not pace the enterprise: Preparing for AI regulation

Michael MontoyaChief Technology Operations Officer | F5

There is an argument underway in the industry about how fast frontier AI should advance. This was accelerated by incidents disclosed by Anthropic and OpenAI, in which models running with reduced safeguards, in evaluation environments, took actions well outside what anyone intended. They reached systems they were supposed to be walled off from and coordinated across instances that were meant to be isolated. More recently, a proposal from Anthropic CEO Dario Amodei argued that frontier AI capability development be deliberately paced and that independent evaluators be embedded inside the labs to verify it.

The responses to that proposal have not been uniform. The AI labs are focused on the development process: how much capability a training run adds, how thoroughly a model is evaluated before release, and whether standards should be voluntary or regulated. Others are arguing the frontier will move at whatever rate it moves, the rest of the world is not slowing down, and safety must be engineered into the systems surrounding the models.

I am not going to settle the argument here, but notice something interesting: both camps agree that controls should sit outside the model, and verification should not rest solely with whoever built it.

That is a broader version of the argument I made in May. I wrote then that the security boundary in AI had moved to the inference path. Applications call models, agents invoke tools, and models reach back into other services to retrieve data, trigger workflows, and take operational actions. My conclusion was that this traffic needs to be delivered, inspected, authenticated, and governed like any other critical application interaction.

That was an architectural argument, and over the past few months it has started to become a compliance one. Pacing the frontier does not pace the enterprise. Whatever the labs and governments settle on, the models already released are being deployed inside our organizations now, and the obligations attached to that use are already taking shape.

In my experience there are two kinds of items on a security roadmap. There are the ones you believe in, which compete for budget against everything else and sometimes lose. And there are the ones with a date attached, an auditor who will ask about them, and a line in the risk register. AI guardrails are moving from the first category to the second, and if you have been in this industry long enough that will feel familiar.

What PCI DSS taught us

We have run this experiment before. Prior to 2008, web application security was largely aspirational—periodic code audits, static scans, developer discipline. Then came PCI DSS Requirement 6.6, which told organizations handling cardholder data to either review all application code for vulnerabilities or put an automated technical control in front of public-facing applications.

Two things about that have stayed with me.

PCI DSS did not start as a law. It started by us in the industry trying to get ahead of regulation. It was a contractual standard, enforced through acquirer agreements, and it reshaped an entire market anyway. In fact, likely faster than legislation would have, because contracts move faster than statutes. That’s relevant because the first place organizations will feel this pressure is not from a regulator, but from a customer security questionnaire, a procurement clause, or an insurer asking what controls sit in front of their models.

And then there is how it ended. In PCI DSS v4.0, the either/or went away. The code-review alternative is gone; an automated technical solution in front of public-facing web applications is now mandated under Requirement 6.4.2.

Today, nobody asks if PCI compliance is optional. The option became the requirement.

Where we are today with AI regulation

The regulatory honeymoon for AI is over. The AI equivalent to PCI is arriving on several tracks at once, at different speeds. The EU AI Act is the most developed. Its obligations for general-purpose models are already being implemented, and while the European Union recently pushed high-risk enforcement out to December 2027, the expectations around technical robustness, human oversight, and logging are already defined. What enterprises consistently miss is that some of those obligations fall on themselves, not just model providers. If they put someone else's model into a high-risk use case, they are responsible.

In the U.S. there is not yet a comparable statute, but the NIST AI Risk Management Framework and its generative AI profile have become the standard many have adopted for reasonable care. ISO/IEC 42001 is doing the same on the certification side and, in fact, I am starting to see it in procurement documents. At the state level, a number of statutes have been introduced with a mix of transparency, disclosure, and use-specific rules, while financial and health regulators are discussing scenario specific guidelines.

And the OWASP Top 10 for LLM Applications is now standard reference material in security reviews. When a customer sends a questionnaire to a vendor about AI controls, that is very often where the questions came from.

Read across all of it and the same requirement keeps appearing: show that you can constrain what goes into a model and what comes out of it, continuously, and produce a record afterward.

This is an operations problem before it is a compliance problem

Our 2026 State of Application Strategy Report found that 55% of application portfolios are now AI-enabled and the average enterprise is running seven models in its inference path. More than half (52%) are chaining or orchestrating multiple models. And 90% expect to route inference through shared infrastructure.

Now envision an auditor asking for a demonstration that a single policy—say, that no customer PII leaves a model completion—is enforced across all of it.

That cannot be answered by configuring seven models individually. It certainly cannot be answered when three of them are chained, and the output of one is the input to another. And most organizations I talk to are a step behind even that, because the first thing they find when they go looking is not a self-hosted model at all. It is employees pasting sensitive data into consumer AI tools, and AI features quietly switched on inside SaaS applications they already own.

Add agents to that picture and the unit you need to control stops being the prompt and becomes the action—the tool call, the API request, the workflow it triggers. That is the same enforcement point we have spent 20 years building for application traffic.

This same agentic capability is already in the hands of attackers running coordinated campaigns at machine speed. Just as we learned in bot defense, we must stop judging this traffic by how sophisticated it looks, and start policing it by where it is coming from and what it is trying to do.

Guardrails have to sit outside the model

Organizations are increasingly running their own models. Open-weight models on their infrastructure, fine-tuned on their data. There is no safety net from the provider, so the operational and compliance liability is entirely theirs.

Auditing model-by-model does not scale. It can be done, in principle, across a dozen model configurations. I have watched teams do it. It is manual, it is out of date the moment someone spins up a new endpoint, and it produces a snapshot rather than a control.

Alignment is not a security control. System prompts and post-training provide a useful baseline. The OpenAI and Anthropic incidents demonstrate the limitations of this. These were models without safeguards pursuing a narrow objective, encountering a boundary, and working around it. OpenAI has stated that the classifiers in its standard customer deployments would have flagged the activity as unsafe, and that its expanded chain-of-thought monitoring, had it been running, would have alerted its security team before its models reached Hugging Face. Anthropic's generally released models carry classifiers that inspect inputs and outputs in real time.

Both labs did substantial alignment work in response, and neither treated it as sufficient. Both also put controls outside the model: monitors that watch what it is doing and evaluate the action before it executes, with escalation to a human. The organizations with the deepest possible understanding of these systems concluded the control belongs outside the model.

Where to start

Given where the regulation is heading, and what the last two decades of application security taught us about how these obligations arrive, there are three things I would put in motion now rather than wait.

1. Map the surface, starting with what wasn’t authorized. Every model in production—SaaS APIs, hosted endpoints, self-managed open-weight deployments—plus the shadow AI.
2. Decouple enforcement from the model. Put policy in the inference path, not in seven separate model configurations. Inspect what goes in, inspect what comes out, enforce uniformly regardless of which model or which cloud.
3. Build the audit trail outside the system it is recording. Logs of what was asked, what was returned, what was blocked, and who approved what. Make sure it is generated by infrastructure the model and the agent do not control. Investigators looking at the OpenAI incident found agents tried to alter the records of their own actions. If your record is produced by the system it describes, it will be suspect.

The key thing here is that AI governance is not just a documentation exercise. What will be asked of organizations is technical, continuous, and evidentiary. That makes this an architecture and operations problem that lands on security and operations teams, not a policy problem for your legal department.

We believe the control belongs in the path, not in the models. Every model your organization runs—SaaS API, hosted endpoint, self-managed open weights, the ones you sanctioned and the ones you haven’t yet discovered—converges on the inference path. That makes it the ideal control point across all of these models, to enforce policy and produce an independent, auditable record.

The rules are still being written

Nobody knows which requirement will force the issue for their organization—an EU AI Act obligation, a state law, a sector regulator, or a customer contract. What I do know is that the technical definitions inside these frameworks are not settled. What counts as adequate monitoring, sufficient robustness, or an acceptable record is being decided right now, in comment periods, standards bodies, and codes of practice.

Which brings us back to the current debate about pacing frontier AI development. Putting aside the merits, I will offer one observation from someone who runs this in production: the enterprise is on a different clock. Whatever the labs, governments, and the industry decide, the models already released are being deployed and used at scale within our organizations, and the obligations attached to that use are very real. You are still going to need answers for your board, your executives, and your customers whether we slow capability development or not.

These decisions will be better if they are informed by people who have operated these systems at scale—who know what is genuinely enforceable, what a control costs in latency and complexity, and where a well-intentioned rule pushes behavior in the wrong direction. PCI DSS worked because practitioners shaped it. If we sit this one out, the requirements still get written. Just by people who have never had to enforce one.

Read more about F5's approach to AI security.

About the Author

Michael MontoyaChief Technology Operations Officer | F5

Michael is responsible for the enterprise‑wide strategy and execution to operate the company with security and resiliency at its core. He leads F5’s Security, Risk, and Digital Operations organizations, driving end‑to‑end operational trust for customers, partners, and employees. Montoya joined F5’s executive leadership team in October 2025 after serving on F5’s Board of Directors from 2021 to 2025. Prior to F5, Montoya was Chief Operating Officer at BlueVoyant and previously served as Chief Information Security Officer at Equinix and Digital Realty. He spent more than a decade at Microsoft in global leadership roles, including Chief Cyber Security Officer, regional CIO/CISO for EMEA and Asia, and a global leader for Datacenter Operations.

More blogs by Michael Montoya