The AI Runtime published a piece recently that every CTO with a stalled pilot should read. Its argument: enterprise AI strategies fail because companies never build the production system, the repeatable engineering, governance, and ownership infrastructure that turns a validated prototype into a deployed product. Use-case selection is rarely the problem. The companies that scaled (BBVA, Lowe's, Intercom, Booking.com) built their path to production first, then ran use cases down it.
We agree with all of it. We'd add one thing, because we watch it happen from inside the deals. When you trace a stalled pilot back to the exact moment it stopped moving, you almost always land on the same spot. The model was fine. The eval suite was fine. The pilot stalled the day the prototype needed to touch production data.
The pilot trap is an access trap
Reread the pilot trap as the article describes it. The prototype needs production data, but nobody wants to approve datasets large enough for the AI to prove itself. It needs a compliance review, but legal has no framework for AI-specific risk. It needs guardrails, but nobody has defined what the system must never be allowed to do. Six months pass with zero progress and zero realizable ROI.
Those blockers are the same blocker wearing different badges: nobody will let the AI touch production directly, and nobody should. Because right now, in most companies, here is what "an agent in production" actually means: a process running on a human's borrowed credentials, holding the same standing access that human has, executing commands inside a session that nothing watches. Your identity provider granted the session. Your SIEM will log that a session happened. Nothing in between can see the actual queries, which means nothing can stop one or escalate for approval.
Every security leader knows this, even the ones who haven't articulated it yet. The compliance review takes a quarter because the honest answer to "what happens if the agent does something it shouldn't?" is "we find out afterward."
One security leader we spoke with counted 41 AI tools already active in their environment, "governed" by a policy document that enforced nothing at runtime. Another watched an AI-suggested fix ship to production and trigger a twelve-hour outage. The policy said that shouldn't happen, but paper policies enforce nothing.
This is the missing floor in the production system. The article's five decisions (infrastructure, engineering fluency, reuse, causal measurement, production ownership) are the right five. But four of them quietly depend on a layer the article never names: runtime control over what humans and agents actually do once they're connected to production.
The fast path has to be the compliant path
The article's best example is Figma's "compliance fast path": pre-classified data, pre-defined guardrails, pre-approved experiment categories, so any team can move without a per-project review. That's the right idea. The question is how much process it takes to pave. If clearing access still requires reviews and meetings, every new use case burns weeks and the enforcement gap never closes.
The fast path becomes fast when the guardrails are structural: enforced on the wire, at the moment of execution, regardless of who or what is connecting. A sidecar proxy attached to each data source, the same sidecar pattern every platform engineer already runs in Kubernetes, gives you exactly that. The sidecar masks sensitive fields in the response stream, schema-less, in real time, so "is this dataset approved for AI use?" collapses from a data-classification project into a masking policy that's already running. It holds destructive commands for human approval or blocks them outright, so "what are the guardrails?" has a demonstrable answer instead of a documented one. Access is just-in-time and least-privilege, so agents stop inheriting standing human credentials.
Now rerun the article's five infrastructure questions. Data readiness? The data needs no per-project scrubbing, because the masking travels with the connection. Governance framework? Pre-approved means whatever passes the rules on the wire; escalation is a command-level approval routed to a human, not a meeting. Deployment pipeline? A sidecar attaches to the Postgres, the Mongo cluster, the agent sandbox you already run. No code changes, no new credentials, no re-architecture. The first one is running in an afternoon, not a quarter. The infrastructure investment the article says to make before your first use case stops being a six-month platform build.
The behavioral reliability owner needs something to watch
The article's sharpest section is on ownership. AI products drift as models change, so someone must own behavioral reliability after launch. Its best line is a warning: the most common enterprise AI failure is "a slow, invisible degradation where the model gets slightly worse over weeks and nobody notices because nobody is watching."
Watching with what? You can assign the role tomorrow. The moment your new behavioral-reliability owner asks what the agent actually did in production last Tuesday, they hit the blind spot. IAM shows a session was granted. The SIEM shows it occurred. The commands in between, the queries run, the rows touched, the writes nobody requested, were captured nowhere. The role exists. The instrument is missing.
Runtime control is the instrument. When every connection to production runs through a sidecar, every session is recorded at the command level, every blocked action is an event, and every approval carries a name and a timestamp. Drift becomes an observable behavioral difference attached to a record instead of a feeling. When something goes wrong, the owner has a kill switch that operates at the command level, not a Slack thread asking whose credentials the agent was using.
This is also where the article's measurement argument (Decision 4) gets its teeth. Causal measurement, counterfactuals, and incident review all presume a ground-truth record of what the system actually did. "How do you know the AI did what you intended?" is answerable from the wire, and only from the wire. Adoption metrics will never tell you.
Decisions 2 and 3 get cheaper
Briefly, because the pattern repeats. The article says the bottleneck is Tier-3 production engineering capacity: engineers who can build guardrails, observability, and regression infrastructure. True, and scarce. Every guardrail enforced at the access layer is a guardrail your scarce Tier-3 engineers skip rebuilding per project. And the article's reuse math, scoring each use case on standalone value times infrastructure leverage, is precisely the case for putting control at the connection layer. One sidecar pattern covers every protocol, so your second, fifth, and twentieth use case inherit the same masking, the same approvals, the same evidence trail on day one. That is compounding infrastructure leverage made concrete.
What the fast path looks like at runtime
The fast path looks like a transcript. An agent connects to a production database through a sidecar and gets to work with enforcement built into the moment it takes action.
It reads customer records to build context. The rows come back with PII masked. The agent never sees the real emails, and nobody had to pre-scrub the table. It moves to update an order status: the write freezes mid-flight, an approval lands with the on-call engineer, one click, and the command completes with the approver's name in the audit line. Then, unprompted, it reaches for something nobody asked it to touch: DROP TABLE orders_archive. Blocked. Stopped while the query ran, months before an audit or a postmortem would have found it. Session recorded end to end.
That's the whole model. Compliant means you can prove what happened: every command, every mask, every approval, evidence that collects itself. De-risked means you can prevent what shouldn't: while the query runs, not in a postmortem. The AI Runtime is right that your strategy document should specify a production system rather than a use-case list. Make sure page one covers the layer where every pilot actually stalls: the point where the AI touches production.
You don't install that layer. You attach it.
