There is a sentence I keep hearing in enterprise conversations, usually from a leader who is genuinely trying to move fast on AI and feeling pulled in two directions by their org.
We do not want to over-govern this. We are just trying to ship.
I understand the impulse. I have made the same complaint about governance programs for fifteen years of writing API Evangelist. Bad governance is real, and it shows up in the form of design-review committees that stop everything, style guides that nobody reads, and CISO sign-off processes that turn a four-week project into a four-quarter project. If governance for you has historically meant the office down the hall that exists to say no, you are right to be wary of it.
But the framing buried inside that sentence — governance versus speed — is the wrong framing, and it is going to cost the people who hold it the agent era.
Governance is not the brake. Governance is the engine.
The engine analogy is not a metaphor — it is the literal job
Pop the hood of a car. The engine has a governor. The governor’s job is not to slow the engine down. The governor’s job is to find the speed the engine can sustain without flying apart. Sometimes that speed is high. Sometimes that speed is low. The governor is what makes the engine useful at all. Remove it and the engine either screams up to a speed that destroys its own components, or it bogs down to a speed that produces no power. Either way the car does not move.
The agent era is the same.
A regulated bank cannot floor it. They will be sued and fined and lose customers before the demo is done. A growth-stage startup cannot creep along at the regulated bank’s speed — they will run out of runway. A healthcare network operating across thirty hospitals cannot pick one speed; they need to be fast on internal workflows and slow on patient-record-handling and exactly-medium on payer integration. Each of those is governance work. Each is finding the right speed for the right component to keep the engine running.
The leaders who say “we do not want to over-govern” usually mean “the way our org has done governance in the past was unfit for the job.” They are correct. The fix is not to remove the engine. It is to install one that can find a speed faster than zero.
The three lenses
I have been writing about this as the cost, velocity, and risk lenses on AI investment. Each is a different axis of the same governance work.
Cost tells you what each agent invocation actually costs. Not the model bill — the full unit cost when you multiply token spend, upstream API spend, retry overhead, and the time of the human who has to clean up the output. Without that view, you cannot know whether a capability is paying for itself, and any “should we let an agent do this” conversation is vibes-based. Capabilities, done properly, make this attributable.
Velocity tells you how fast the right thing can happen in the right place. The wrong question is “how fast are we going?” The right question is “is this part of the system going as fast as it should be and the rest of the system going at the speed it can absorb?” Sometimes the answer is the experimentation team is going too slow because the platform team is going too fast in the wrong direction. Velocity is not a global number. It is a per-component setting.
Risk tells you the cost of being wrong. Per workflow. The risk of an agent miscategorizing a support ticket is bounded; the risk of an agent miscoding a clinical record is not. Treating the two as the same risk because they share a model and a runtime is what gets organizations into the lawsuits the board is paying lawyers to prevent.
A real governance program tunes these three knobs per capability, not per organization. The reason most governance programs feel like brakes is that they were built to apply one setting to the whole car. The agent era requires per-component governance, because the agent era is going to put the same engine into a hundred different workloads with a hundred different cost, velocity, and risk profiles.
A regulated enterprise cannot move at the speed of a four-person seed startup
This is the part that gets glossed over in every AI keynote, so I will say it plainly: the largest, most regulated, most consequential enterprises in the economy physically cannot move at the speed the AI vendors keep telling them to move. They will be sued and fined and lose their customers. That is not a failure of imagination on their part. It is a correct read of the constraints they operate under.
A heavily-regulated enterprise — pick your favorite bank, insurer, healthcare network, defense contractor — is going to be slow on the workflows that matter, and that is the right answer. The engine governor in that car is calibrated for the specific risks of the cargo it carries. A four-person startup serving consumer marketing has a completely different governor calibration, and that is also right. Confusing the two — telling the regulated enterprise to ship at startup demo-day speed, or telling the startup to adopt SOC 2 controls before they have a product — is the actual governance failure.
The job of the governance program is not to pick a global speed. It is to pick the right speed for this engine, with this cargo, in this weather.
What this changes for AI teams
If you are leading an AI initiative in an enterprise right now, three implications fall out of the engine framing.
Stop treating governance as a separate workstream. Governance is not the workstream that runs in parallel to the build. It is the workstream that defines what can be built at all. The cost-velocity-risk tuning is the architecture. If your build team and your governance team have separate roadmaps, your governance team is going to keep showing up as a brake — because it will. The only way out is to make governance part of the build, expressed as capability declarations, allow-lists, observability, and metering inside the same artifacts the build team is shipping.
Stop picking a single speed for the org. A modern enterprise has dozens of workflows with completely different governance profiles. Pretending they are all the same — applying the bank’s risk calibration to the marketing team’s experimentation, or vice versa — is the source of most of the “governance is killing us” complaints. Per-capability governance is harder, and it is the only thing that actually works.
Start building the speedometer. You cannot govern what you cannot see. Most enterprises do not currently have an answer to “how many capabilities do we have in production, what does each cost, who is calling them, how often, and what is the risk surface of each one?” The honest answer right now is we don’t know. That is the cost of the previous decade’s governance posture — the office down the hall could say no but could not produce a dashboard. The agent era forces the issue. You will either build the speedometer or you will keep flying blind.
The closer
The leaders who get this right are not the ones who treat governance as something to minimize. They are the ones who treat it as the engine of the entire program. They build the cost view, the velocity view, and the risk view into the same fabric as the capability declarations. They tune per workflow, not per org. They expect the regulated workloads to move slow and the experimentation workloads to move fast and they instrument both so they know which is which.
Governance is what lets the car keep going. Without it you are either smoking your own engine or sitting in the driveway. Pick the speed the engine can sustain, and then go.
