Chevron left
blog

Plan a First Production AI System: Architecture and Operation

Define the task, data path, evaluation, permissions, integration and operating handoff needed to move an AI prototype into reliable use.
Plan a First Production AI System: Architecture and Operation

Table of Contents

Reviewed and updated October 8, 2026.

Plan a first production AI system around one completed task and a clear authority boundary. The architecture must handle data, permissions, integration and failures as well as model output. A demonstration proves only what was tested in that setting.

Choose the technical route from the requirement. A predictive model estimates a defined target from features. A language-model system may retrieve, extract, summarize or generate, often with tools and workflow checks. Both need evaluation, but their outputs and failure modes differ.

Establish the baseline and data path

Define acceptable work, the current baseline and the consequence of errors. Identify source systems, permitted records, retention and ownership. Record how data enters the system, how it changes and which component treats it as authoritative.

Keep evaluation evidence separate from development data where appropriate. For learned preprocessing, scikit-learn warns against fitting on evaluation data. For a language workflow, avoid repeatedly tailoring instructions to a small test set and then describing it as independent proof.

Design the application around the model

A useful design record includes input validation, retrieval or feature preparation, model invocation, output checks, decision authority and execution. Deterministic rules should enforce conditions that do not require prediction. A generated action must still pass authorization and business validation.

OWASP recommends least privilege, default denial and permission checks on every request. Apply access control in the application and underlying systems; do not rely on a model instruction to enforce it. Private hosting alone does not settle authorization or data-handling requirements.

Illustrative production boundary

A hypothetical internal assistant retrieves approved service procedures and drafts a checklist. Users see only permitted documents. The system identifies source passages and declines when evidence is missing or conflicting. It cannot change an account or approve a transaction.

Before release, the team tests restricted records, stale sources, malformed input and unavailable dependencies. A manual procedure remains available. This is a proposed design, not evidence of a successful deployment or a fixed delivery timeline.

Evaluate the completed task

Include normal cases, edge cases, prohibited actions and failures. Measure useful quality, total review time, latency, recurring costs and exception load. Define criteria for release and a result that would reject the proposed design. A fluent answer or a high model score is not enough when the application performs the wrong action.

Record the tested versions of model, sources, prompts, code and configuration. If an evaluator uses another model, validate its judgments against qualified human review for the task rather than assume the evaluator is correct.

Stage release and recovery

Start with a limited scope, review or shadow mode where appropriate. Avoid duplicate live writes when comparing paths. Specify who can pause the system, how work in flight is reconciled and how the previous version is restored. Test dependency failure and permission errors before expanding.

Deployment location should follow actual latency, privacy, integration and operating needs. Cloud, private infrastructure and local execution each create costs and responsibilities. Anonymization, federated methods or encryption are techniques, not blanket compliance guarantees.

Make handoff a delivery requirement

Provide the architecture decisions, evaluation record, operating procedures, access responsibilities, monitoring and incident path. Assign source maintenance and change approval. A user correction does not automatically improve a model; it needs a controlled review and release process.

Keep the option to narrow or retire the system. Production operation is a continuing commitment, and a changed task or permission can require new evidence even when the interface is unchanged.

Bring the decision into a project review

Bring the prototype task, permitted actions and deployment constraints. A review can identify what must be added before production operation. Explore ALLTIPLY AI development, or request a project review with the workflow, systems and constraints you need to assess.