From AI Prototype to Production: The Architecture Checklist Most Teams Skip

Before choosing a provider or tuning a prompt, define what the system is allowed to do, what counts as success, and what must cause refusal or escalation. Without this contract, every model comparison becomes subjective.

A useful acceptance contract names the users, approved data sources, supported tasks, prohibited actions, minimum evidence, latency and cost boundaries, and the human owner of the final decision. It also includes negative cases: missing evidence, conflicting documents, malicious input, unavailable tools, and malformed output.

Free-form text is convenient for demos and fragile for software. Downstream code should receive a versioned schema with explicit status, typed fields, evidence references, confidence signals, and validation errors.

Schema validation is only the first boundary. The server must verify that citations came from the approved retrieval set, tool calls match an allow-list, identifiers exist, totals reconcile, and values respect domain rules. If validation fails, the system retries within a strict budget or returns a controlled failure.

Prompt injection is not solved by telling the model to ignore bad instructions. Retrieved documents, webpages, emails, and tool responses are untrusted input. They must not be able to redefine policy, expand permissions, or silently trigger side effects.

Identity and authorization belong before retrieval and before every tool execution. Tools need narrow scopes, validated parameters, timeouts, rate limits, idempotency where possible, and a clear distinction between read and write actions. High-impact writes require confirmation or human approval.

A production evaluation set should include ordinary cases, edge cases, intentionally unanswerable requests, permission boundaries, injection attempts, tool failures, and examples where a human reviewer disagrees. Store expected behavior and grading notes with the test case.

article12Page.section4P2

When an incident occurs, a chat transcript is not enough. The team needs a trace of the policy version, prompt or workflow version, model, retrieved source IDs, tool decisions, validation results, latency, cost, and final reviewer action.

This does not mean logging every confidential document or complete prompt forever. Logs should be minimized, access-controlled, and retained according to a defined purpose. The objective is reproducibility and accountability, not indiscriminate surveillance.

Providers time out. Search returns nothing. Documents conflict. A parser corrupts a table. A tool succeeds but the callback is lost. Production architecture names these states explicitly and decides which ones are retried, queued, degraded, escalated, or rejected.

Retries need limits and idempotency. Queues need dead-letter handling. External writes need reconciliation. User interfaces must distinguish “processing,” “needs review,” “insufficient evidence,” and “failed”—because a polished but ambiguous spinner is not an operational strategy.

Human-in-the-loop is not a safety control if reviewers merely click approve. The interface must show the source evidence, uncertainty, changed fields, policy warnings, and the exact action that approval will trigger.

Feedback should become structured data: accepted, corrected, rejected, reason category, and reviewer role. That creates material for evaluation and improvement without automatically training on every correction or treating all feedback as equally reliable.

A system is not production-ready until someone owns model and prompt changes, evaluation thresholds, data-source quality, security review, budget alerts, incident response, and rollback. These responsibilities may be shared, but they cannot remain unnamed.

Model upgrades are software releases. They need a change record, regression evaluation, canary or staged rollout, monitored thresholds, and a rollback path. The same applies to embedding models, rerankers, extraction prompts, tool schemas, and policy rules.