Successful AI workflows – those that can provide answers about costs, as well as security risks – call for visibility into what they are doing, when, and how. Eric Anthony Pace, a former chief AI officer and founder of The Remade Agency, argues that enterprises require four cornerstones to solidify control over these workflows.
The first time I felt the need to support an AI governance initiative was the day I owned one.
We were in one of our first AI Council reviews inside a Fortune 500-sized enterprise. My finance business partner asked a question that sounded simple. "How many models are we running in production, and what do they cost us?"
Ten people in the room. Nine blank stares. Among them, the leaders of strategy, architecture, research and development, product, cybersecurity, infrastructure, data privacy, and legal. Mine was one of the nine, and I was the chief AI officer.
We had a policy. Three pages, plus links to our code management guidelines and our standards for generated images. Approved by that same council, circulated, filed. It was a good policy. And it could not answer the question.
Nobody in that room was negligent. We had written a policy where we needed a platform.
Governance is the machinery that makes the permitted thing the easy thing. A policy gets written by a committee. The platform for AI workflows gets built, deployed, and wired into your production path, where it either exists or it does not.
Most Teams Are Still in That Room
Of 200-plus enterprise AI leaders running agents in live production, surveyed by TrueFoundry in spring 2026, 76% had no unified logging across their models and agents, so nobody could reconstruct what happened after the fact. Fifty-six percent had no centralized control layer, so there was no single place to enforce a rule. And 61% had no spend caps on AI workflows.
Read that last one twice. Six in ten had shipped software that can call paid APIs in a loop, with no cost ceiling. We were in that six in ten, and we found out live, in front of Finance.
Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027. That is a finance number wearing a technology costume. Projects die when nobody can answer four questions: what did it cost, who approved it, what did it touch, and can you prove it.
Long before any of this discussion is about cost, it is about visibility. You cannot manage, monitor, or measure what you cannot see. So narrow the discussion. Focus on the most important question. What has to exist before agents touch production? Four things.
The Four Cornerstones of Visibility for an AI Workflow
A gateway. A single control point that proxies your AI traffic regardless of source, user, or model. If you run an API gateway in front of your services today, this is that gateway for model calls: one endpoint, one credential, one place the bill comes from. It makes every model call visible in one place, and every call goes to a model you have registered. It is the first cornerstone because it is the only one of the four that creates a chokepoint.
The objection to setting up a gateway arrives immediately and it is fair: you have just built a single point of failure. Not if you build it right. A gateway is a layer. It means that multiple instances of AI or agentic AI, scaled horizontally, are active under one management plane. Centralize the control and distribute the infrastructure.
Then the most useful question in a gateway evaluation is a simple one. Can a developer bypass the gateway? If the answer involves the word "policy," you are buying a suggestion that developers obey the rules. By making the gateway the path of least resistance, the default in the service template with credentials already provisioned, it becomes a control point that you can monitor. Anything else and coverage is voluntary.
Runtime security enforces in the request and response path of the AI workflow, before the damage lands. It makes visible what was attempted and what was refused. Your security program was built around software that does what it was written to do. AI systems drop that guarantee, because the system picks its own actions and calls tools nobody authorized for that specific step. Many are spun up for one task and torn down when it finishes, so the thing that took the action may be gone before anyone looks for it. A chatbot has one risk surface, the text it returns. An agent produces effects in your systems.
In the TrueFoundry survey, 78% of teams ran six or more active tool or model context protocol endpoints (that connect AI applications to external data sources) and 51% could not confirm all of them were authenticated. Cannot confirm. The inventory does not exist. That is a lateral movement path, a route an attacker can take from one system to the next, with a natural language interface bolted to the front of the workflow. Assume the model gets fooled. Build the platform so that nothing important is within reach when it does.
Observability is the part everyone thinks they already have. It makes visible the sequence of steps inside a single AI workflow. A unified, queryable record of every model and agent interaction, structured enough to answer questions you have not thought of yet. This is where most programs are weakest, and the weakness hides because the logs do exist. They sit in several systems, in several formats, with no shared identifier. Every enterprise already owns observability, and that is the problem with the word. Infrastructure health tells you almost nothing about an agent. What you need is the reasoning path: which tool it picked, and what data it had retrieved when it picked it.
Workflow quality degrades silently. A gateway failure surfaces in minutes. A provider updating a model underneath you does not throw a single error. The only thing that catches it is a record you were already keeping.
Inference classification means running a model across your own AI traffic to label what is in it. It makes visible what the work was for, and whether what came back was any good.
The first three cornerstones establish that a thing happened, that it was permitted, what it cost, and what it touched. They cannot tell you what the work was for. I should be direct about this one, because I have been on the wrong end of it. We built the first three and never built inference classification. It was not for lack of understanding. We chose against pointing our engineering capacity at it, and there was nothing on the market to buy instead.
We chose poorly.
The objection here is that you already do this. You have evaluations in the build pipeline and test prompts that run before release. Keep them. They tell you about the model. They tell you nothing about your traffic, because your traffic is what your users typed, using your data, in untested waters. Pre-deployment evaluation is a quality gate. This is a quality signal. You need both. Be skeptical of every vendor here, including the ones I work with.
What To Buy First When Building Your AI Platform
Prioritize the gateway. It is the chokepoint and everything else enforces through it. A gateway that 60% of your traffic bypasses is worth less than a simpler one carrying all of it. Make observability second. It is nearly free once the gateway exists, and once implemented, it converts every argument from opinion into data.
Those two are the dependency. After that the order in which you implement these capabilities forks, and the order in which you address visibility comes down to who is asking questions and how loudly. Focus on runtime security third if it is your CISO. Classification becomes third if it is Finance. Whichever route you take third, the other is fourth. Teams that skip the first two and buy an evaluation product discover there is no unified pipe to plug it into. You cannot inspect traffic you do not route.
What You Are Building
Each cornerstone produces a record that makes all your work with AI visible.
| Cornerstone What it makes visible |
| Gateway Every model call, and who made it |
| Runtime security What was attempted, and what was refused |
| Observability The sequence, cost, and latency of every step |
| Inference classification What the work was for, and which outputs held up |
Individually, these cornerstones look like compliance artifacts. Step back and they are a queryable account of how your company uses AI.
Call this account system context. Nobody can sell it to you. It accrues only to whoever bothered to instrument early, and it is what lets you walk into a provider renewal holding per-workload consumption data instead of an invoice.
You cannot govern what you cannot see. Start with the pipe. Then you will know what to say in the meeting when someone asks about anything – including costs.
This article is derived from a longer paper.
Written by Eric Anthony Pace
Eric Anthony Pace is an enterprise technology operator and advisor, and founder of The Remade Agency. He spent most of his career implementing large-scale platform programs for global enterprises, then moved to the buying side as Chief AI Officer at a Fortune 500-sized communications operator, where he shipped 50+ productized AI solutions and on-prem AI infrastructure serving 10,000+ enterprise users. He now advises AI infrastructure companies on go-to-market and enterprise readiness, and co-chairs the AGENTIC Conference. He is a paid advisor to TrueFoundry, whose survey data is cited above.