Your Team Builds AI in Weeks. Why Does Shipping Take Quarters?

The demo took three weeks. Production took seven months.

I have watched this movie enough times to recite it. An AI engineering team, sitting close to the business, builds something genuinely useful — an agent that reads contracts, a copilot that answers data questions, a workflow that used to eat someone’s Tuesdays. The demo lands. The sponsor is thrilled. Everyone agrees it should go live.

Then it enters the tunnel.

A cloud service approval request, written from scratch, for services the last project already requested. A security review that starts from zero context, asking questions the last review already answered. A stack debate that relitigates decisions the organization has already made twice. A deployment path assembled by hand, again. Seven months later the app ships — into a business moment that has partly passed.

Most enterprises do not have an AI building problem. They have an AI shipping problem.

And the two failure modes it produces are worse than slowness itself.

What Actually Breaks

The first casualty is belief. The business funded an AI engineering org to get working software into production while the opportunity is still warm. When every app pays a two-quarter approval tax, the ROI story never fully lands — not because the technology failed, but because the delivery system around it did.

The second casualty is discipline. Engineers are pragmatic. When the approved path takes seven months and the unapproved path takes seven days, some of them will take the seven days — a portal-configured agent here, a local copy of governed data there. The slow lane creates the shadow estate. Every ungoverned agent in your company is a receipt for an approval process that was slower than the demand it was supposed to manage.

Most organizations respond by trying to speed up the review board. That treats the symptom. The reviews are slow because every request arrives novel — security has never seen this stack shape before, so every question must be asked again, for every app, forever.

The fix is not a faster review. It is removing the novelty.

Pave the Road Before the Traffic Arrives

The pattern I now recommend — and have seen work inside a large, regulated enterprise — is what I call pre-approved AI delivery architecture: decide, ahead of demand, three things at once.

1. 1.The reference pattern every AI app will follow.
2. 2.The exact services and sub-services that pattern requires.
3. 3.The guardrail configuration under which each service is approved.

Approve that package once. Then every subsequent app inherits an already-approved path instead of starting its own approval journey. The pattern is approved once; apps ship on it many times.

In the Azure implementation this draws on, the pattern pairs Azure Databricks for the governed data estate — medallion layers under Unity Catalog, Genie for natural-language access, vector search for grounding, MLflow for custom models — with Azure AI Foundry for the application layer: Agent Service, the model catalog, content safety, managed identity end to end. The specific products matter less than the posture: one paved road, chosen before the first app asks for it. Anything on the road inherits its approvals.

Name the Ways an App Touches Data — All Four of Them

The most quietly powerful move in the whole pattern is an act of naming. The pattern declares exactly four ways any app touches data: through the Genie connector, through governed SQL against gold-layer tables, through vector search for RAG grounding, or through a custom model serving endpoint.

“How does your app access data?” is an open question that produces ten minutes of prose and a follow-up meeting. “Which of the four paths?” is a thirty-second check. And the interesting case identifies itself: an app that fits none of the four is, by definition, the conversation worth having. In my experience it is usually a local data copy that should not exist.

Prompts Are Code. Ship Them Like Code.

In the AI era, the artifact that changes your app’s behavior most often is not a class file — it is a prompt, an agent configuration, a model selection. If those live in a portal, your app’s behavior changed last Tuesday and nobody can tell you who changed it or why.

So the delivery pipeline treats AI artifacts as first-class citizens of the SDLC. Prompts and agent configs live in the repo and pass pull-request review. An eval regression gate sits right beside the static-analysis scan — prompts do not ship if evals fail. Model and API versions are pinned. Prompt bundles are published as versioned artifacts next to the container images. The sleeper risk this closes is the portal-configured agent that exists nowhere in source control and bypasses the entire pipeline.

There is a second-order benefit here that I think is underrated: the pipeline pre-approves the iteration loop, not just the launch. AI apps do not earn their value at the first release; they earn it at the tenth revision. Because the pattern approves the path rather than the individual artifact, a prompt improvement clears the same eval gate and ships through the same pipeline — without re-opening any approval. The fast lane compounds.

Approve Services Under Stated Configuration — Never Unrestricted

The move that makes all of this tractable for a security organization: approval of a service means approval under its stated guardrail configuration. Managed identity only — no static keys anywhere in the chain. Private endpoints. Gold-layer access only. Pipeline-only deploys. Never unrestricted use.

Written this way, the approval inventory reads like the security team’s own requirements document — because it effectively is. This framing turns security from an opponent into a co-author of the pattern, and it is why the approval survives contact with the second, tenth, and fortieth app. It also changes what an approval request looks like: a full bill of materials — every service, every sub-service, its purpose in one line — gets answered in days. “We need AI Foundry” gets answered in quarters.

Speed and Rigor Are the Same Decision

The instinct is to see this as a trade — give the business speed, give up some control. It is the opposite. The organization keeps full compliance with its standards because the standards are embedded in the pattern itself, checked by the pipeline on every release, evidenced by observability across the whole chain. The business ships faster because of that embedding, not despite it.

A paved road is both the safest and the fastest way through the terrain. And if the governed path is not also the easiest path, your engineers will find the other one — so making the right way the easy way is not a convenience. It is the control.

Where I’d Temper It

An honest caveat list, because a paved road is a bet. If the platform pair is wrong for a class of workloads, the road becomes a detour — the pattern needs an owner, a review cadence, and a sanctioned exception process. If you have only one or two AI apps on the horizon, the fixed cost may never amortize; adopt the practices (prompts as code, stated-configuration approvals) and skip the pattern investment. And the four-paths framing is only as good as its enforcement — without observability that can detect off-pattern access, the named paths describe intent, not reality.

But if you are an AI engineering org with a pipeline of apps, a regulated environment, and a business that is starting to ask why the demos never seem to become products — the answer is almost never “build faster.”

Build once, approve once, then let every app after that inherit the road.

I’ve published the full reference pattern — the platform diagram, the ownership map, the delivery pipeline, and the complete service approval inventory — as an architecture page: Pre-Approved AI Delivery Architecture, linked below.