AI System Design Checklist: Data, Models, Retrieval, Tools, Safety, Evaluation, and Operations

 

An AI design checklist should expose unanswered engineering questions before users depend on the system. It is most useful as a review framework, not as a substitute for architecture reasoning.

Purpose and users

Define the task, target users, expected inputs, desired outputs, and consequences of error. State what the system will not do.

Solution design should begin by identifying the workload type in AI-900 learning path before selecting models, retrieval, tools, or controls.

Data

Identify source data, sensitivity, ownership, freshness, retention, and quality. Confirm that the application has a legitimate reason to process each category.

The data feeding the AI system still has storage and processing requirements; DP-900 data overview provides the foundation for reviewing those layers.

Model

Choose a model using task quality, context requirements, latency, cost, deployment, and security constraints. Keep a repeatable evaluation set for model changes.

Do not select a model solely because it is newest or largest.

Prompts and context

Define instructions, examples, context sources, output schema, and limits. Separate untrusted content from privileged application rules.

Version important prompt changes.

Retrieval

If RAG is used, test chunking, search, ranking, permissions, freshness, and source attribution. Measure retrieval separately from final-generation quality.

Tools and actions

List every tool, its schema, side effects, credentials, and allowed scope. Validate model-produced arguments before execution.

Privileged actions need explicit trust boundaries and approval paths; the SC-100 architecture overview provides the security-architecture lens for reviewing them.

Safety and security

Test prompt injection, unauthorized data access, tool abuse, secret exposure, unsafe output, and excessive autonomy.

Use least privilege and deterministic controls for high-impact rules.

Human oversight

State which decisions require human review and what information reviewers receive. Ensure the reviewer has real authority to stop or modify the action.

Evaluation

Define quality, groundedness, safety, structured-output, task-success, latency, and cost metrics relevant to the application.

An AI system should be evaluated as a complete solution rather than a model endpoint, and the Azure AI Engineer path reflects that implementation perspective.

Observability

Trace model calls, retrieval, tools, policies, latency, token use, costs, and errors. Protect sensitive content in logs.

Ensure an operator can reconstruct how a problematic response was produced.

Reliability

Set timeouts, retry policies, fallbacks, budgets, and stopping conditions. Decide what happens when the model, search index, or tool dependency is unavailable.

AI applications remain distributed systems with services, dependencies, retries, and ownership; cloud-native platform overview provides the cloud-native operating model for those concerns.

Privacy

Minimize sensitive inputs, define retention, secure evaluation datasets, and control access to prompts, outputs, traces, and embeddings.

Deployment

Version prompts, models, indexes, tool schemas, and policy configuration. Use controlled promotion and rollback.

Models, prompts, retrieval logic, tools, and policies all change over time; Microsoft DevOps solution design supplies the controlled release and rollback discipline needed around those artifacts.

Cost

Measure model usage, context size, retrieval, embeddings, tool calls, and infrastructure. Set ownership and budgets.

A design that meets quality requirements but cannot operate economically is not production-ready.

Data engineering dependencies

Confirm how current information reaches the application, how schemas evolve, and how failed or delayed pipelines affect answers.

Reliable AI also depends on the data platform beneath it; DP-700 engineering overview places ingestion, transformation, governance, and monitoring inside that supporting layer.

Security operations

Define alerting, audit trails, incident ownership, and how compromised credentials or unsafe tool behavior are contained.

Identity, encryption, and monitoring controls should be reviewed independently of model quality; AWS security and data protection develops those supporting security responsibilities.

Final review

A system is ready for production only when the team can explain not just how a good response is generated, but how bad inputs, missing data, dependency failures, unsafe requests, and model changes are handled.

The checklist succeeds when it reveals a design decision early enough to fix it.

Require evidence at every checklist gate

A design checklist should produce artifacts that can be reviewed. Data readiness can be supported by lineage, quality results, and access ownership. Retrieval quality can be supported by relevance tests. Tool permissions can be demonstrated through scoped identities and denied-action tests. Safety controls need evaluation cases, not just a policy statement. Operational readiness needs dashboards, escalation paths, and a rollback or containment plan.

This evidence-based approach also creates stop conditions. If the team cannot explain which data the system can access, cannot reproduce its evaluation results, or cannot contain a harmful tool action, the design is not ready for broader production exposure. A checklist is most valuable when it makes those gaps visible before users discover them.