AI system from idea to approved production use¶
Trigger¶
A business area wants to deploy a model or an AI-assisted workflow.
Intended outcome¶
An AI system classified, assessed, monitored, and accountable to a named human.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | AI Governance Officer | registers the use case and classifies its risk | risk classification and inventory entry | No production AI without a classification and an accountable human |
| 2 | Data Protection Officer | assesses lawfulness of the data and the decisioning | privacy and fairness position | Impact assessment before processing, not retrospectively |
| 3 | Data Scientist | builds and honestly characterises the model | model with held-out performance and stated limits | Failure modes and the population it must not be applied to are stated |
| 4 | AI and ML Architect | designs serving, monitoring and the human override path | serving and monitoring architecture | Drift, degradation and harmful-output monitoring designed in |
| 5 | AI Safety and Model Red Team Specialist | probes the deployment configuration for harm and misuse | adversarial findings with severity and owners | Tested against the configuration users will actually get |
| 6 | Machine Learning Engineer | productionises with full lineage | reproducible training and traceable deployed version | Every deployed version traceable to its training run |
| 7 | MLOps Engineer | operates the lifecycle with rollback | monitored model with defined thresholds and rollback | Automatic or documented rollback route exists |
| 8 | AI Governance Officer | approves, and re-tests at the review date | approval record and review date | Route to challenge the system's decisions is published |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
ai-system-approvalworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.