Methods · Topic T4

How an AI prototype should be taken to production and kept running

Reviewed October 18, 2026

It prints in full from the browser, on A4 or Letter.

Block 1

The problem

Taking an AI prototype to production and keeping it healthy, cheap and safe once it is published.

Summary in three lines

A prototype goes to production when it passes written conditions that have already been seen failing. The checks that run before publishing are unit, integration and end-to-end tests, accessibility, performance and the secret blocking, and if there is a model, test questions that run on every change like any other test.
Code comes before AI: the model only goes where a rule falls short, behind a layer that lets the provider change and with a simpler, announced way out for when it fails.
Publishing is where validation starts: it is kept running with metadata and not with its users’ content, with written limits and a written cost ceiling, and with a summary of every cycle that turns the failure into a rule.

Block 2

The map

From prototype to production, and from production to the next version

Swipe to see the whole map.

Legend of shapes and colors

Actor — who does the work
Data — what is stored and read
Control — a rule that gets checked
Person — a person decides
External — what comes from outside

Reading the map, node by node

A prototype starts with a written decision: if it needs a model, why a rule is not enough. Then it goes through the publishing controls —tests at three levels, accessibility, performance and, if there is a model, test questions—, the secret blocking and the dependency review. With everything green, the change is deployed to its own preview, a person reviews it and decides to publish it. In production, with no server of its own, the product calls the model through a layer that switches providers by configuration; limits and the cost ceiling bound those calls, and if the provider fails, the product offers a simpler function and tells its user so. Operations leave metadata —not content— and every cycle closes with a summary and a recorded decision, which is where the next version starts.

Node 1 Prototype (Data) — Something that already works on one machine: it is not a product yet.
Node 2 Written decision (Control) — Code first: a model only comes in with an architecture decision that says what a rule cannot solve.
Node 3 Tests and evaluations (Control) — Unit, integration and end-to-end tests, accessibility, performance and, if there is a model, test questions: all of them on every change.
Node 4 Secrets and dependencies (Control) — A secret is blocked before it enters the history; a vulnerable dependency stops the change.
Node 5 Preview per change (Data) — Every change is deployed on its own and looked at before it reaches production.
Node 6 Whoever approves (Person) — A person reviews the preview and, with every required control green on its own, decides to publish.
Node 7 Production with no server of its own (External) — Static pages, functions at the edge and a managed database with row-level security: nothing to operate by hand.
Node 8 Provider layer (Actor) — The only module that knows concrete providers: one variable picks which, and consecutive failures open the circuit.
Node 9 Announced degradation (Control) — Without a provider, the product offers a simpler function that keeps the essentials, and says so.
Node 10 Limits and cost ceiling (Control) — Rate, size, tokens, time and history written down as numbers, and a monthly budget the bill does not get to decide alone.
Node 11 Metadata, not content (Control) — Provider, model, milliseconds, tokens and errors: what is needed to know what failed, where and what it cost.
Node 12 Cycle summary (Data) — Every cycle closes with what failed and why; a failure that repeats becomes a rule with its test.
Node 13 Whoever uses the product (Person) — Gets the full answer or the simple function, and in both cases knows which one it was.

Connections

from Prototype to Written decision (justified)
from Written decision to Tests and evaluations
from Tests and evaluations to Secrets and dependencies
from Secrets and dependencies to Preview per change (all green)
from Preview per change to Whoever approves (reviewed)
from Whoever approves to Production with no server of its own (publishes)
from Production with no server of its own to Provider layer (calls the model)
from Limits and cost ceiling to Provider layer (bounds)
from Provider layer to Announced degradation (if it fails)
from Announced degradation to Whoever uses the product (says so)
from Production with no server of its own to Metadata, not content (leaves)
from Metadata, not content to Cycle summary (learned from)
from Cycle summary to Prototype (next version)

Block 3

The phases

1
Phase 1
Decide whether a model is needed
Inputs
- The problem and the process it lives in.
- What a rule, a search or an algorithm already solves.
Activities
- Write down which part requires interpreting, generating, retrieving by context or coordinating tools.
- Solve with code first whatever code solves.
- Leave the decision on record, including what the model must not do.
Artifacts
- A written architecture decision.
Who decides
Whoever answers for the product.
Control that closes the phase
Without a written decision, the generative feature is not switched on.
Evidence
In the author’s apps, switching on a generative feature requires a written architecture decision: Innmobiliaria has zero models as a product rule, and where there is one it is optional and has a deterministic fallback.
2
Phase 2
Turn the prototype into something verifiable
Inputs
- The prototype.
- The publishing conditions, written down.
Activities
- Unit, integration and end-to-end tests; accessibility and a performance budget.
- If there is a model: test questions and cases where it must abstain, say it does not know or refuse.
- Watch every new control fail against what it means to catch, before accepting it.
Artifacts
- The suite in continuous integration.
- The red demonstration of every new control.
Who decides
Whoever builds.
Control that closes the phase
A new control only goes in after it has been seen failing.
State of the field
Microsoft recommends building qualitative tests into release pipelines, because AI is nondeterministic, and having monitoring feed the quality gates across the whole life cycle.^[8]
3
Phase 3
Protect what gets published
Inputs
- The repository, which may be public.
- The provider’s and the database’s credentials.
Activities
- Block secrets before the commit and test that block with a bait that actually triggers it.
- Keep keys only in the deployment’s environment variables, never in the code that reaches the browser.
- Test every credential before building against it.
- Audit dependencies and update them in small batches, verified one at a time.
Artifacts
- The secret block and its verified bait.
- The environment configuration, outside the repository.
Who decides
Whoever builds.
Control that closes the phase
A commit with a secret never comes to exist.
State of the field
GitHub turned on secret scanning push protection by default for pushes to public repositories: if it detects one, it blocks the push until the secret is removed or the block is deliberately bypassed.^[9]
4
Phase 4
Take it to production: the checks run before publishing and a person decides
Inputs
- The change’s preview.
- The conclusions of every required control.
Activities
- Review the preview the way its users will see it.
- Check that every required control ran and finished green on its own: a skipped one is not green.
- Publish from the main branch, with the previous version at hand to go back to.
Artifacts
- The change in production.
- A way back to the previous version.
Who decides
Whoever owns the product.
Control that closes the phase
No required control skipped or red.
Evidence
Every control is asked three questions before it is accepted: was it seen failing?, was it seen running? —a skipped job is not green— and can it fail at all?
5
Phase 5
Operate: measure, bound and degrade
Inputs
- Real use.
- The written budget.
Activities
- Log structured metadata and report errors, without the content of the product’s users.
- Set limits on rate, length, output, time and history.
- Open the circuit after consecutive failures and switch to the simple function, saying so.
- Keep a switch that turns off the generative feature without taking down the rest.
Artifacts
- Structured logs and error alerts.
- The degraded mode, tested.
Who decides
Whoever pays for and answers for the operation.
Control that closes the phase
With the provider down, the product still does the essentials and says so.
Evidence
In this site’s chat, after three consecutive failures the circuit opens and the browser searches the same index, saying it is not the model’s answer.
6
Phase 6
Learn and start the next version
Inputs
- The failures, the measurements and what the product’s users found.
Activities
- Write the cycle’s summary: what was done, what failed and what was left pending.
- Turn the incident into a rule with its test, not into an anecdote.
Artifacts
- The summary and the recorded decision.
- The new rule and its red demonstration.
Who decides
Whoever owns the method.
Control that closes the phase
Without a written summary, the cycle does not close.
Evidence
In this site’s sprint 3 a provider credential returned a 401 in integration; since then every credential goes through a smoke test before anything is built against it, and continuous integration repeats it on every run.

Block 4

The design decisions

Code first or a model
When yes
A model, when the problem requires interpreting, generating, retrieving by context or coordinating tools flexibly, and a rule falls short.
When no
When a rule, a structured search or an algorithm does the job: they are more predictable, cheaper and easier to test.
Why
Evidence
It is rule 13 of the author’s pipeline: before using generative AI, the feature of the problem that requires it has to be shown, and switching it on calls for a written architecture decision.
Judgment
The question is not whether AI can be added, but whether the improvement justifies what it brings along: dependencies, cost, variability and an evaluation someone has to keep up.
A fixed provider or a layer that changes it
When yes
A switchable layer, when the product must survive a model being retired, a quota changing or a provider going down.
When no
A fixed provider, when the feature depends on something only one offers and that dependency is accepted in writing.
Why
Evidence
In the chat an environment variable chooses among five adapted providers, and an adaptation layer is the only module that knows them: who writes changes, not the index or the facts.
Judgment
Switching providers is easy when the knowledge does not live in the provider; what has to be tested is that the new one keeps the citations, the refusals and the answer length.
What gets evaluated on every change and what gets reviewed by hand
When yes
On every change, whatever can be measured cheaply and deterministically: that retrieval brings back its source, that destinations exist, that off-topic questions get stopped.
When no
A model-based judge on every commit, when it costs more than it protects: there it goes in batches, before publishing.
Why
State of the field
Microsoft documents, in preview, a GitHub Action that evaluates agents inside continuous integration, with confidence intervals and significance tests to tell whether a change improved or merely varied, and advises against running it on every commit to keep costs down.^[3]
Evidence
On this site retrieval is evaluated on every change with in-house questions and questions from outside; the answer that tries to slip in something not retrieved is caught today by reading, not by a gate.
Own containers or serverless deployment
When yes
No server of its own, when the product is static or made of short functions and nobody should have to operate a machine: the edge and the browser are enough.
When no
When the workload needs long processes, in-memory state or control over the environment that the platform does not give: there a container pays for what it costs to run.
Why
Evidence
The author’s deployments run with no server of their own —Vercel, Cloudflare Workers, the user’s browser— and that is why they have never needed a container.
State of the field
To deploy a model, Microsoft recommends starting with platform as a service and serverless solutions to simplify adoption and management; managed compute is a viable option for advanced needs, and self-hosting is another option.^[8]
What gets stored in order to observe
When yes
Metadata —provider, model, milliseconds, tokens, errors— to know what failed, where and what it cost.
When no
The content of the product’s users, unless the product needs it, it is said before the first word and it has its recorded decision.
Why
Evidence
In the author’s apps what is observed travels as metadata through Pino and Sentry; this site’s chat does store question and answer since September 21, 2026, and warns about it before the visitor writes.
State of the field
Microsoft Foundry (formerly Azure AI Foundry) traces every call to the model and to tools on the OpenTelemetry standard, and its production monitoring follows token consumption, latency, error rates and quality, with alerts when an output fails its thresholds.^[2]

Block 5

What is new in 2026

State of the field
Microsoft Foundry, one platform that brings together evaluating, observing and guarding
What changes from common practice
Microsoft Foundry brings agents, models and tools together in a single resource, with tracing, monitoring and evaluations built in; its guardrails can scan the input, the output and, for agents and in preview, the call to a tool and its response.^[1]^[12]
Evidence
The author’s experience with Microsoft Foundry —its limits are in block 9—: it was connected to the chat as one of its providers, and its syllabus is studied on the AI-103 path, which is in progress.
State of the field
Evaluations as one more test in the pipeline
What changes from common practice
Observability no longer starts in production: Foundry plugs automated quality gates into continuous integration (with a GitHub Action in preview), applies quality, RAG and safety evaluators to a set of queries, and afterwards evaluates a sample of real traffic.^[2]^[3]
Evidence
On this site the test questions already run on every change like any other test; for the model’s answer there is no automatic judge.
State of the field
Attacking one’s own system before publishing
What changes from common practice
Foundry’s red teaming agent probes the application with PyRIT attack strategies and measures the attack success rate; Microsoft warns that the judge is generative, that it can produce false positives and that results are reviewed before acting on them.^[4]
Judgment
It should run before a new generative feature opens to the public, and the attacks that got through should be read before touching a single filter.
State of the field
Sending each request to the model that is enough
What changes from common practice
Foundry’s model router analyzes each request and sends it to a small model when that is enough and to a frontier one when it is needed; it says which model answered, and Microsoft makes clear it does not remove the need to evaluate.^[5]
Evidence
The savings of this site’s chat happen before the model: out-of-scope questions consume no tokens and only the relevant passages travel, not the whole site.
State of the field
Reusing the beginning of the prompt
What changes from common practice
If the first 1,024 tokens of a request are identical to an earlier one, the service reuses the computation and bills that read at a discount; that is why what is stable goes first and what changes goes last.^[6]
Judgment
It is a lever when the instructions are long and repeat identically; before relying on it, it is worth measuring how much of the request is truly stable.
State of the field
Unbounded consumption, treated as a security risk
What changes from common practice
OWASP’s 2025 Top 10 for LLM applications treats uncontrolled consumption as a risk —denial of service, economic losses— and asks for input size validation, rate limits per user or entity, timeouts and monitoring of resource usage.^[10]
Evidence
This site’s chat has those limits written as numbers, not as intentions: 800 characters per question, 700 output tokens, 30 seconds and 12 messages of history.
State of the field
The supply chain is also AI’s
What changes from common practice
OWASP extends the supply chain to models, data and platforms, and asks for vetting suppliers, keeping an up-to-date inventory of components —a software bill of materials— and a patching policy for what is vulnerable or outdated.^[11]
Evidence
Anonimizador Velo audits its dependencies in continuous integration against three banned families of AI SDKs, and a transitive dependency counts the same as a direct one.
State of the field
Operating AI is now a certification
What changes from common practice
Microsoft’s study guide for its machine learning and generative AI operations certification asks for versioning prompts in Git, setting up automated evaluations with quality and safety metrics, and tracking token cost alongside latency and throughput.^[7]
Evidence
The AI-300 path is in progress, followed since July 2026, and is not presented as earned.

Block 6

Failure modes and how to anticipate them

What breaks
A control that is always green
How it shows up
Nobody saw it fail; a skipped job shows up among the required ones with no alarm.
Control that catches it
The red demonstration travels in the same commit as the control, and every required check has its own conclusion.
What breaks
A secret reaches the repository
How it shows up
A key in a commit, in a log or in the code that reaches the browser.
Control that catches it
Secret scanning before the commit, tested with a bait that actually triggers it; keys only in the deployment’s environment.
What breaks
An invalid credential is found out at the end
How it shows up
The first real use returns a 401.
Control that catches it
A smoke test of every credential before building against it, repeated in continuous integration.
What breaks
The provider goes down, runs out of quota or retires the model
How it shows up
Consecutive failures, timeouts, a model that stops existing.
Control that catches it
A switchable provider layer, a circuit breaker and a degraded function announced as such.
What breaks
Cost grows without anyone deciding it
How it shows up
More tokens per answer, off-topic requests reaching the model, spikes from a single source.
Control that catches it
A filter before the model, rate and size limits, and a written cost ceiling.
What breaks
Quality degrades silently after publishing
How it shows up
Retries piling up with an integration, answers that stop citing, latency going up.
Control that catches it
Per-session telemetry with metadata and the test questions running against every change.
What breaks
A vulnerable or outdated dependency
How it shows up
A security advisory, or a package that drops a version without anyone asking.
Control that catches it
Dependency auditing in continuous integration and updates in small batches, each one verified.
What breaks
Telemetry carries away its users’ data
How it shows up
A user’s content in a log or in a reported error.
Control that catches it
Structured logging with metadata only; whatever is stored is declared beforehand and has its written decision.

Block 7

Metrics and controls

What is measured
Required controls with their own green conclusion
Threshold
All of them; a skipped one counts as not green.
Who approves the step to production
Whoever publishes, reading every conclusion.
What is measured
New controls seen failing
Threshold
All of them, before going in.
Who approves the step to production
Whoever builds, with the demonstration on record.
What is measured
Test questions with their source among those that go in
Threshold
A written floor that does not drop from one change to the next.
Who approves the step to production
Whoever owns the content.
What is measured
Secrets in the history
Threshold
Zero: a single one stops the commit.
Who approves the step to production
The secret block, with no exceptions.
What is measured
Monthly cost against the written ceiling
Threshold
Below the ceiling; if it gets close, context and length are trimmed before switching models.
Who approves the step to production
Whoever pays for the operation.
What is measured
Provider latency and errors
Threshold
Within the maximum time per request; consecutive failures open the circuit.
Who approves the step to production
Whoever answers for the product.
What is measured
Essential function with the provider down
Threshold
Available and labeled as degraded.
Who approves the step to production
Whoever answers for the product.
What is measured
Users’ content in telemetry
Threshold
Zero.
Who approves the step to production
Whoever answers for the data.

The thresholds are examples of the method, not figures from a specific project.

Block 8

Evidence from projects

EvidenceLevel: Real use
The publishing chain the author’s apps share
The sibling apps and this site share criteria and, in essence, this chain: Git and GitHub, continuous integration with unit, integration and end-to-end tests, accessibility with axe, a performance budget with Lighthouse and deployment on Vercel with one preview per change (Innmobiliaria is served from the edge on Cloudflare Workers and Dash Agent is not deployed); no branch reaches production with one of those jobs red.
See where
EvidenceLevel: Real use
This site: continuous integration against a real database
The integration job spins up a real Supabase, applies the migrations and tests against Postgres; a database permission counts as verified when a test tries to get around it and cannot.
See where
EvidenceLevel: Real use
A control proves itself by failing
Every new control brings its red demonstration in the same commit. The rule was born on July 15, 2026, when secret scanning passed silently twice with a weak bait: since then the canonical bait has been verified.
EvidenceLevel: Real use
The provider layer and degradation, tested by a real failure
An environment variable picks the chat’s provider. In sprint 3 a credential returned a 401 in integration, the circuit opened and local search answered over the same index, saying it was not the model’s answer.
See where
EvidenceLevel: Real use
A cost ceiling and the measured cost
The chat runs under a ceiling of US$20 a month and an observed real cost of US$0, because usage fits in the initial provider’s free quota and off-topic queries are resolved without calling it: it is a measurement, not a promise of free service.
EvidenceLevel: Real use
Observing agents in production
At Vesting a platform was designed that observed up to 23 agents at a time in production: events traveled to Microsoft Fabric and from there to Power BI, and per-session telemetry showed an agent piling up retries before a user reported it.
See where
EvidenceLevel: Real use
Data with row-level security and access only through functions
This site’s database has row-level security on and no policies: the anonymous role can only run definer-privilege functions, and the service key neither travels to the browser nor lives in the repository.
EvidenceLevel: Real use
Models in production, sustained
The half of MLOps that is about taking models to production and keeping them there is done: predictive models at Banco Pichincha and TransMilenio, agent monitoring at Vesting and public applications with continuous integration and automatic deployment, operated by the author.

Block 9

Limits and scope

Evidence
Containers in production with Docker and Kubernetes are not part of the author’s experience: Kubernetes is known from study, not from operating it, and the half of MLOps that packages and orchestrates with containers has not been done.
Evidence
With Microsoft Foundry the experience is this chat’s provider adapter, fine-tunes of models done there, in several prototypes of the author’s own, and studying for the AI-103, which is in progress; no deployment of the author’s own on Azure is described.
Evidence
The AI-300 is in progress: it is the certification for operating models and agents, and it is not presented as earned.
Evidence
The model’s answer is still reviewed by reading: the one that tries to bring in information that was not retrieved is caught by reading, not by a gate.
Evidence
The launch and operation phases of the author’s app factory have still not been validated in a real run: they are written method, not experience.
Judgment
What should be done differently today: evaluation with a calibrated judge as one more continuous integration job from the first sprint with AI, and automated red teaming before opening a generative feature to the public.
Judgment
And it is better not to start with the platform: start with the publishing conditions, written down and seen failing; the platform is chosen afterwards, for what those conditions need.

Block 10

Sources and review date

Reviewed October 18, 2026

[1]
What is Microsoft Foundry?
Microsoft Learn · August 13, 2026
https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry
[2]
Observability in Generative AI
Microsoft Learn · October 15, 2026
https://learn.microsoft.com/en-us/azure/foundry/concepts/observability
[3]
How to run an evaluation in GitHub Action
Microsoft Learn · April 30, 2026
https://learn.microsoft.com/en-us/azure/foundry/how-to/evaluation-github-action
[4]
AI Red Teaming Agent
Microsoft Learn · August 19, 2026
https://learn.microsoft.com/en-us/azure/foundry/concepts/ai-red-teaming-agent
[5]
How model router works in Microsoft Foundry
Microsoft Learn · September 9, 2026
https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-router-how-it-works
[6]
Prompt caching with Azure OpenAI in Microsoft Foundry Models
Microsoft Learn · August 11, 2026
https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching
[7]
Study guide for Exam AI-300: Operationalizing Machine Learning and Generative AI Solutions
Microsoft Learn · February 18, 2026
https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/ai-300
[8]
MLOps and GenAIOps for AI Workloads on Azure (Azure Well-Architected Framework)
Microsoft Learn · November 1, 2024
https://learn.microsoft.com/en-us/azure/well-architected/ai/mlops-genaiops
[9]
Keeping secrets out of public repositories
GitHub · February 29, 2024
https://github.blog/news-insights/product-news/keeping-secrets-out-of-public-repositories/
[10]
LLM10:2025 Unbounded Consumption (OWASP Top 10 for LLM Applications 2025)
OWASP GenAI Security Project · November 17, 2024
https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/
[11]
LLM03:2025 Supply Chain (OWASP Top 10 for LLM Applications 2025)
OWASP GenAI Security Project · November 17, 2024
https://genai.owasp.org/llmrisk/llm032025-supply-chain/
[12]
Guardrails and controls overview in Microsoft Foundry
Microsoft Learn · July 31, 2026
https://learn.microsoft.com/en-us/azure/foundry/guardrails/guardrails-overview

Summary in three lines

From prototype to production, and from production to the next version

Legend of shapes and colors

Reading the map, node by node

Connections

Inputs

Activities

Artifacts

Inputs

Activities

Artifacts

Inputs

Activities

Artifacts

Inputs

Activities

Artifacts

Inputs

Activities

Artifacts

Inputs

Activities

Artifacts

Code first or a model

Why

A fixed provider or a layer that changes it

Why

What gets evaluated on every change and what gets reviewed by hand

Why

Own containers or serverless deployment

Why

What gets stored in order to observe

Why

Microsoft Foundry, one platform that brings together evaluating, observing and guarding

Evaluations as one more test in the pipeline

Attacking one’s own system before publishing

Sending each request to the model that is enough

Reusing the beginning of the prompt

Unbounded consumption, treated as a security risk

The supply chain is also AI’s

Operating AI is now a certification

The publishing chain the author’s apps share

This site: continuous integration against a real database

A control proves itself by failing

The provider layer and degradation, tested by a real failure

A cost ceiling and the measured cost

Observing agents in production

Data with row-level security and access only through functions

Models in production, sustained