Constrained AI Workflow Readiness Checklist (2026)

Use this to retrofit an existing AI feature (often: chat + RAG) into a constrained workflow you can operate.

1) Define the blast radius
- List the actions the AI can trigger (tickets, emails, refunds, user changes, deployments).
- Mark which actions are reversible vs irreversible.
- For irreversible actions, decide the required gate: human approval, policy check, or “read-only only.”

2) Make the control flow explicit
- Write the workflow as states with transitions (e.g., COLLECT_INPUT → FETCH_RECORDS → PROPOSE_ACTION → VALIDATE → EXECUTE → LOG).
- Define timeouts and retry rules per state.
- Add an explicit “REFUSE/ESCALATE” state with a clear reason code.

3) Replace prose with typed tool calls
- Enumerate tools the model is allowed to call (API endpoints, DB queries, internal services).
- For each tool: define a JSON schema for arguments and validate server-side.
- Prohibit regex parsing of free-form text for execution.

4) Authorization and least privilege
- Ensure tool calls inherit the user’s entitlements (OAuth scopes, RBAC) or a tightly scoped service account.
- Maintain per-tool allowlists (which workflows can call which tools).
- Log “who requested” and “which credentials executed.”

5) Verification gates before action
- Schema validation: reject/clarify on invalid arguments.
- Policy validation: deterministic checks (limits, required fields, forbidden operations).
- Data validation: confirm referenced IDs exist; avoid acting on ambiguous entities.

6) Observability and replay
- Store immutable run records: user input, retrieved context versions, tool trace, validation results, final decision.
- Use correlation IDs across model calls and tools.
- Ensure you can replay a run with the same inputs and inspect every step.

7) Evaluation as a deployment gate
- Maintain a golden set of realistic tasks for the workflow.
- Add adversarial cases: ambiguous requests, missing fields, permission edge cases.
- Run evaluations when you change prompts, tools, models, retrieval config, or policies.

8) Operational ownership
- Assign an on-call owner for the workflow.
- Write a runbook: common failure modes, how to disable execution, how to force read-only mode.
- Add a kill switch and a safe degradation path.

Success criterion: You can explain any executed action with a step-by-step trace and a deterministic policy rationale. If you can’t, keep the feature read-only until you can.