Disciplines → 1 of 6
AI in every stage of the lifecycle, from business concept to retirement, inside the delivery practices you already run.
AI-Augmented Delivery is where AI meets the work itself. It covers how AI takes part in each stage of the lifecycle, from shaping a business case to decommissioning a service, and how the pipeline proves that every AI-assisted change was checked before it shipped.
The discipline does not introduce a separate "AI process". It adds AI contributions and matching controls to the stages teams already run, so adoption changes how work is done without changing where it is recorded.
| Practice | Today | With AI-Augmented Delivery |
|---|---|---|
| Refinement | Stories written by hand | AI drafts stories and acceptance criteria; the product owner owns acceptance |
| Design | ADRs record a decision | AI proposes options; the ADR records AI involvement and the human decision |
| Development | Engineer writes the change | AI generates code, tests and IaC; the engineer owns intent and correctness |
| CI/CD | Build, test, deploy | Adds provenance, licence and eval checks, and approvals driven by risk tier |
| Decommissioning | Servers and services | Also prompts, agents, integrations and non-human credentials |
Assign a risk tier when an epic or change is planned, not when it reaches review. The tier decides how much AI may contribute and which approvals the pipeline will demand, so engineers know the rules before they generate anything.
Generated code is only as good as the specification it answers. Acceptance criteria, interface contracts and test cases are agreed first, often drafted by AI and approved by a person. Verification then checks the change against an agreed intent, not against whatever the model produced.
Record AI involvement where the work is already recorded: a vendor-neutral commit trailer such as AI-assisted: yes, a field on the pull request, a line in the ADR. The audit trail then comes from the version control system and tracker, with no separate store to maintain.
Keep the existing stages and add controls: secret scanning and context hygiene before commit; licence and IP checks on generated code; evals for prompts, agents and AI features; and a policy gate that maps the change's tier to the approvals required. The reference pipeline shows where each control sits.
Every element created during delivery has an owner, a tier, a provenance record and a state from proposed to retired. Start with what you already track, such as code, releases and access, and add the AI-specific elements: prompts, context packs, agents, tool integrations and non-human identities. See the element register.
AI adoption creates assets that outlive their purpose: prompts nobody owns, agents with standing credentials, integrations to tools no longer approved. Retirement is a lifecycle stage. It finds dependants, revokes access and archives provenance, so nothing keeps running without an owner.
| Tier | Prevent (Guardrails) | Prove (Audit Trail) | Detect (Self-Monitoring) |
|---|---|---|---|
| Low | Approved tools only; automated checks must pass | Provenance trailer on the change | Pipeline failure rate on AI-assisted changes |
| Medium | One qualified human reviewer; licence and secret checks | Pull request links spec, review and provenance | Change failure and rework rate, AI-assisted vs not |
| High | Two reviewers incl. a specialist; evals or security tests mandatory | Evidence bundle attached to the release record | Enhanced monitoring for a defined window after release |
| Critical | Human-only authorship and decision; AI may analyse, never act | Documented rationale; second-line sign-off | Any AI involvement triggers review |
For organisations deploying AI tools, the EU AI Act's AI literacy duty (Art. 4) applies to everyone using them in delivery. ISO/IEC 42001 expects documented information on AI use (clause 7.5) and operational control (clause 8); marking changes and keeping the element register provide both from the systems already in use.