Pre-Approved AI Delivery Architecture
Shrinking AI ideation-to-production from quarters to weeks — a platform pattern selected before demand arrives, a service stack approved once under stated guardrails, and a delivery pipeline where prompts and agent configs ship like code.
By Jai Ganesh
What is pre-approved AI delivery architecture?
Pre-approved AI delivery architecture is the practice of deciding — ahead of demand — the reference pattern AI applications will follow, the exact cloud services and sub-services that pattern requires, and the guardrail configuration under which each is approved, so that 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. Done this way, the organization keeps its rigor — compliance is baked into the pattern, not negotiated per project — while the business gets what it actually funded the AI engineering org for: working software in production, fast, and iterating.
The Problem
Most enterprises do not have an AI building problem. They have an AI shipping problem.
The arc is familiar: an AI engineering org, embedded close to the business, builds a working app in weeks. Then the app spends months getting to production. It fights through a cloud service approval request written from scratch, a security review that starts from zero context, a stack debate that relitigates decisions the last app already made, and a deployment path assembled by hand. Multiply by every app, and the delay compounds: each project pays the full approval tax individually, and none of the payments accrue to the next one.
Two things break under this model. The business stops believing — by the time an app ships, the moment that justified it has often passed, and the ROI of the AI capability the organization invested in never fully lands. And the engineers start routing around — a portal-configured agent here, a local data copy there — because the unapproved path is faster than the approved one. The slow lane creates the shadow estate.
The failure is architectural, not procedural. Approvals are slow because every request arrives novel: security has never seen this stack shape before, so every question must be asked again. The fix is not a faster review board. It is removing the novelty — deciding the pattern, the stack, and the guardrails once, before the first request is ever written.
The Architecture
How It Works
The pre-selected platform pattern
One reference architecture, chosen before the first app asks for it. In the implementation this page draws on — a large enterprise building on Azure — the pattern pairs Azure Databricks for the governed data and ML estate (medallion layers under Unity Catalog, Genie for natural-language access, vector search for grounding, MLflow for custom model serving) with Azure AI Foundry for the application layer (Agent Service, model catalog, content safety, managed identity). The pattern is not a suggestion; it is the paved road. Anything on it inherits its approvals.
The four integration paths
The pattern names exactly four ways an app touches data: ① agent-to-Genie through the native connector, ② governed SQL against gold-layer tables, ③ RAG grounding through vector search, ④ custom model serving endpoints. Naming the paths converts a vague governance concern into a thirty-second per-app check — which of the four does this app use? — and makes the interesting case self-identifying: anything that fits none of the four is, by definition, the conversation worth having. It is usually a local data copy that should not exist.
The ownership map
A layer-by-layer anatomy of a typical app — UI, API, orchestration, tools, model access, state — with every component colored by who owns it: custom-built, platform-managed, or data-platform-owned. The map is a triage instrument. Platform-managed components need only conformance; data-platform components route to data governance; the custom-built components are where review effort, build friction, and reuse opportunity all concentrate. The standing question it puts on the table: which custom boxes could a managed equivalent or a shared template replace?
The AI-ready delivery pipeline
One recommended CI/CD flow where the AI-specific artifacts are first-class citizens of the SDLC, not portal state. Prompts and agent configurations live in the repo and pass pull-request review like code. An eval regression gate sits beside the static-analysis scan — prompts do not ship if evals fail. Model and API versions are pinned; prompt and config bundles are published as versioned artifacts next to the container images. The sleeper risk this design closes: the portal-configured agent that exists nowhere in source control and bypasses the entire pipeline.
The service approval inventory
The pattern’s full bill of materials, written before anyone asks: every service and sub-service the pattern requires — across AI/ML, hosting, data, identity, networking, DevOps, and third-party dependencies — each with its purpose stated in one line and a status column ready for the review meeting. An approval request that anticipates the questions gets answered in days. One that says only “we need AI Foundry” gets answered in quarters.
Approval under stated configuration
The principle that makes the whole thing tractable for security: approving a service means approving it under its stated guardrail configuration — managed identity only, private endpoints, gold-layer access, pipeline-only deploys — never unrestricted use. This framing turns the security organization 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.
Design Decisions
Approve the pattern once, not each app
Per-app approval scales linearly with demand and pays no dividends. Pattern approval is a fixed cost that every subsequent app amortizes. The review conversation shifts from “is this safe?” — asked forty times — to “does this app conform to the approved pattern?” — a materially easier question with a materially faster answer.
Name the integration paths
An enumerable set beats an open question. “How does your app access data?” produces ten minutes of prose; “which of the four paths?” produces an answer and, occasionally, a productive exception. Discovery, conformance checking, and onboarding all get faster when the options have names.
Prompts are code
Anything that changes an app’s behavior belongs in source control, and in the AI era that includes prompts, agent configurations, and model selections. The delivery pipeline treats them accordingly — reviewed, eval-gated, versioned, published. The alternative is behavior that changed last Tuesday and no record of who changed it.
Pre-approve the iteration loop, not just the launch
The first release is not where AI apps earn their value; the tenth revision is. Because the pattern pre-approves the path and not the individual artifact, iteration inherits the same fast lane as initial delivery — a prompt improvement clears the same eval gate and ships through the same pipeline, without re-opening any approval.
Speed and rigor are the same decision
The win-win is not a compromise; it is the design goal. The organization keeps full compliance with its standards because the standards are embedded in the pattern itself — and 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. If the governed path is not also the easiest path, engineers will find the other one.
Trade-offs & Limits
- ›A pre-selected pattern is a bet. If the platform pair is wrong for a class of workloads, the paved road becomes a detour — the pattern needs an owner, a review cadence, and an explicit process for sanctioned exceptions.
- ›Pre-approval front-loads work before demand proves itself; in an organization with only one or two AI apps on the horizon, the fixed cost may exceed what it ever amortizes.
- ›Guardrail configurations drift out of date as cloud services evolve — tiers, features, and API surfaces change quarterly, and a stale inventory quietly reintroduces the per-app negotiation it was built to remove.
- ›The four-paths framing is only as good as its enforcement; without the pipeline and observability to detect off-pattern data access, the named paths describe intent rather than reality.
When To Use It
- ✓An AI engineering org shipping — or about to ship — multiple apps into the same enterprise environment
- ✓Ideation-to-production measured in months while build time is measured in weeks
- ✓Regulated environments where every production app must demonstrably conform to org standards
- ✓Platform and architecture teams asked to make AI delivery faster and safer at the same time — pre-approval is the mechanism that does both
When Not To
- ✕A single app with no successor in sight — adopt the practices (prompts as code, stated-configuration approvals), skip the pattern investment
- ✕Genuine exploration phases where constraining the stack would strangle the learning the org is paying for
- ✕As a document without an enforcement path — a pattern nobody can verify conformance against converges on the per-app review it replaced
Enterprise architect and independent AI consultant — I help teams take agentic systems from deck to production, with the governance story intact.
Seen In Practice
- Your Team Builds AI in Weeks. Why Does Shipping Take Quarters? — the essay version of this pattern →
- AI Governance & Cost Architecture — the governance layer this pattern pre-approves →
- Agent Evaluation Architecture — the eval gates the delivery pipeline enforces →
- Multi-Agent Enterprise Architecture — what ships on the paved road at scale →