The adoption ladder is the first of the two axes in this site's model. It measures adoption maturity: how much work AI (artificial intelligence) is trusted to do for one role in one team. The second axis, the use-case risk tier, is decided per use case at intake and is covered in chapter 2.
This chapter gives every stage in full, the rules for stepping down, and the matrix that combines the two axes. Counts, durations and percentages on this page are illustrative.
1. Two axes, one decision
A team never asks "which stage are we at?" alone. It asks "which stage are we at, for this use case, at this risk tier?" The two axes answer different questions and are owned by different people.
| Adoption maturity (the ladder) | Use-case risk tier | |
|---|---|---|
| Measured per | Role, per team | Use case |
| Question | How much work is AI trusted to do here? | How much harm can this use case cause? |
| Values | Stage 0 to Stage 5 | Low, medium, high, prohibited |
| Decided by | The team proposes; the enablement lead checks the evidence | Intake and triage, with the second line (risk, compliance, security) |
| Changes when | Exit evidence is met, or a step-down trigger fires | The use case changes materially |
| In the due-date example | QA (quality assurance) is at Stage 3; the product owner is at Stage 1 | Explaining date code to its author is low. The coding assistant on proprietary source is medium; the resulting customer-facing software change follows the existing customer-change controls |
2. The six stages at a glance
| Stage | Name | AI does | Must exist before entering | Exit evidence |
|---|---|---|---|---|
| 0 | Foundations | Nothing yet | AI inventory and intake, risk tiers, approved tools and configurations, acceptable-use policy, data classification rules, access, logging with retention, named owners | Acceptable use attested and checked with scenarios; intake live; escalation path published |
| 1 | Personal productivity | Explains, drafts, summarizes; the human applies every change | Stage 0 for that tool and tier | Eligible users active; net time saved, including review; zero unreported policy breaches |
| 2 | Team context | Works from the team's instructions file, reusable prompts and the asset catalog | Guardrails as code: secrets block, protected paths, reuse advisory; instructions reviewed like code | Reuse, extend or create decisions recorded; secret and policy findings trend down |
| 3 | Delegated tasks | Does bounded tasks end to end; the output is always a reviewable artifact | Evaluation set per task with thresholds, traces, approval gates mapped to decision rights, reviewer capacity | Evaluation passes the threshold on every risk slice; override rate understood; rework falls |
| 4 | Agentic workflows | Runs multi-step workflows across the lifecycle, with tools | Least-privilege tool access, action boundaries, spend and rate limits, sandbox, kill switch, idempotency, independent approval for consequential actions, recovery tested | Cycle time falls with no rise in severe defects or near misses |
| 5 | Scale and sustain | Shared platform, catalog and community; continuous evaluation | Asset ownership and funding, material-change process, periodic review | Teams contribute assets; regressions are caught before release |
Each stage includes everything below it. A team at Stage 3 still has its Stage 2 instructions file and its Stage 0 inventory entry.
3. Stage by stage
The tables below use the running example: the organization must show the contractual payment due date the same way on web, mobile, statements and reminder notifications, and show the payment cutoff time in the customer's own time zone. The due date is a date-only value. The cutoff is an instant. The shared library shared-datetime already handles both.
Stage 0 · Foundations
Nothing in this stage uses AI. It builds the floor every later stage stands on. A team that skips it does not move faster; it moves into an audit finding.
| Stage 0 | |
|---|---|
| What AI does | Nothing yet |
| Must exist first | An entry in the AI inventory for the tool; intake and triage; risk tiers; the tool approved with its configuration (vendor and third-party risk review, data terms, data residency); acceptable-use policy; data classification rules; access; logging with retention rules; a named owner for each |
| Exit evidence | Users attest to acceptable use and pass short scenarios ("may I paste this statement into the assistant?"); intake accepts real requests; the escalation path is published |
| First use · product owner | Lists the team's candidate use cases on the intake card |
| First use · business analyst | Marks which fields in the due-date flow are restricted data (account number, balance, address) |
| First use · developer | Confirms the approved coding assistant configuration: data terms, telemetry, which repositories it may read |
| First use · QA engineer | Lists the test data that may never enter a prompt |
| First use · release manager | Maps where AI-produced artifacts will enter the existing change process |
| Common mistake | Buying seats before the inventory and intake exist; the tool arrives without context and without a way to ask permission |
Stage 1 · Personal productivity
AI explains and drafts. The human reads, decides and applies every change. Nothing the model writes reaches a system without a person copying it there on purpose.
| Stage 1 | |
|---|---|
| What AI does | Explains, drafts, summarizes; the human applies every change |
| Must exist first | Stage 0 complete for this tool and this risk tier |
| Exit evidence | Eligible users are active; net time saved includes the time spent reviewing; zero unreported policy breaches, with near-miss reporting switched on |
| First use · product owner | Summarizes the contract clause and recent complaints about the due date shown a day early, into a draft outcome statement |
| First use · business analyst | Asks the assistant to explain the difference between a date-only value and an instant, then drafts questions for the payment-schedule team |
| First use · developer | Asks the assistant to explain one of the ten date implementations to its own author; pastes a suggested unit test by hand |
| First use · QA engineer | Drafts boundary cases for daylight saving changes and midnight UTC (Coordinated Universal Time) from a written description, no customer data |
| First use · release manager | Summarizes last quarter's change records for recurring causes of rollback |
| Common mistake | Counting logins instead of net time saved; nobody reports the near miss when restricted data almost went into a prompt |
Stage 2 · Team context
The model now works from what the team knows: an instructions file, reusable prompts, and the asset catalog. The first guardrails become code. This is where the ten date implementations stop multiplying.
| Stage 2 | |
|---|---|
| What AI does | Answers and drafts grounded in the team's instructions file, reusable prompts and the asset catalog |
| Must exist first | Guardrails as code: a secrets block, protected paths, a reuse advisory; the instructions file reviewed like code, through a pull request |
| Exit evidence | Reuse, extend or create decisions are recorded; secret and policy findings trend down over a quarter |
| First use · product owner | A reusable prompt that turns an intake card into an outcome and metric brief |
| First use · business analyst | A reusable story-drafting prompt that uses the team glossary ("due date is date-only; cutoff is an instant") |
| First use · developer | The reuse advisory points to shared-datetime before a new date formatter is written |
| First use · QA engineer | A reusable prompt that turns the temporal-domain contract into Given / When / Then edge cases |
| First use · release manager | A release-notes prompt grounded in the organization's release-notes template |
| Common mistake | Anyone edits the instructions file with no review; the team treats the local advisory as enforcement when only CI (continuous integration) and branch protection enforce |
Stage 3 · Delegated tasks
AI now finishes a bounded task end to end. The output is always an artifact a human reviews: a story, a test suite, a PR (pull request), a draft of release notes. The person who approves it is never the person who asked for it.
| Stage 3 | |
|---|---|
| What AI does | Bounded tasks end to end: drafts stories, generates tests, reviews PRs, drafts release notes |
| Must exist first | An evaluation set per task with pass thresholds; traces; approval gates mapped to existing decision rights; reviewer capacity budgeted |
| Exit evidence | The evaluation passes the threshold on every risk slice, not only on average; the override and rejection rate is understood; rework falls |
| First use · product owner | The agent drafts the epic brief from the intake card and the contract clause; the business owner accepts the outcome |
| First use · business analyst | The agent drafts stories with acceptance criteria for the four channels; the product owner accepts them |
| First use · developer | A coding agent opens a PR that replaces one custom date formatter with shared-datetime; a second developer approves |
| First use · QA engineer | The agent generates tests from the acceptance criteria, scored against an evaluation set that includes negative cases |
| First use · release manager | The agent drafts release notes and the change-record summary from the merged PRs |
| Common mistake | No evaluation set, so nobody knows the miss rate; reviewers approve what they did not read (automation bias) |
Stage 4 · Agentic workflows
AI runs several steps in a row with tools: plan, look up, change, test, open a PR. Every consequential action still needs an independent human approval. For the product owner and business analyst, the Stage 4 shape is the front-loaded artifact pack described on ask-to-release.
| Stage 4 | |
|---|---|
| What AI does | Multi-step workflows across the lifecycle, with tools |
| Must exist first | Least-privilege tool access; action boundaries; spend and rate limits; a sandbox; a kill switch; idempotent actions; independent approval for consequential actions; recovery tested once, on purpose |
| Exit evidence | Cycle time falls with no rise in severe defects or near misses, over at least two release cycles |
| First use · product owner | One owner produces the front-loaded pack (brief, impact map, criteria) before the first meeting |
| First use · business analyst | The agent drafts the impact analysis from the catalog and code search: four display services change, payment-schedule is the source, profile supplies the zone |
| First use · developer | A workflow in a sandbox runs plan, reuse check, change, tests, and opens a PR; it has no merge right |
| First use · QA engineer | A workflow runs the regression suite on web, mobile, statements and notifications for each PR and files defects |
| First use · release manager | The agent assembles the evidence chain into the change record; it cannot deploy; the change authority approves |
| Common mistake | Giving the agent the merge or deploy permission "to save a step"; no kill switch, no tested recovery |
Stage 5 · Scale and sustain
What worked in one team becomes a shared, owned asset. The question shifts from "does it work?" to "who keeps it working when the model, the team or the policy changes?"
| Stage 5 | |
|---|---|
| What AI does | Runs on a shared platform with a shared catalog and community; evaluation runs continuously |
| Must exist first | Every shared asset has an owner and funding; a material-change process; a periodic review |
| Exit evidence | Teams contribute assets back; regressions are caught by continuous evaluation before release |
| First use · product owner | Contributes the outcome-brief prompt to the catalog with its limits written down |
| First use · business analyst | Maintains the shared story prompt that other teams reuse |
| First use · developer | Publishes the temporal-domain contract checks as a shared CI rule |
| First use · QA engineer | Shares the date and time evaluation set; other teams add their negative cases |
| First use · release manager | Continuous evaluation results appear in release readiness by default |
| Common mistake | Assets without an owner or a budget; a provider updates the model and nobody runs the material-change process |
4. Moving up a stage
A team moves up on evidence, not on time served. The team that benefits does not certify itself.
| Step | Who acts | What they produce |
|---|---|---|
| Propose | The team lead, for one role and one use case | A short request: current stage, target stage, risk tier |
| Show evidence | The team | The exit evidence from the table above, with numbers and their denominators |
| Check controls | The enablement lead; for medium and high tiers, the second line too | Confirmation that the next stage's "must exist first" items exist and work |
| Record | The enablement lead | An updated entry in the AI inventory: role, use case, stage, date, review date |
5. Stepping down
Stepping down is normal and planned. It is the ladder working, not failing. Each trigger has an owner who decides.
| Trigger | What happens | Who decides |
|---|---|---|
| Model or provider change | Affected tasks re-run their evaluation set before Stage 3 or 4 use resumes | AI and model risk, with the use-case owner |
| Failed evaluation | Below the threshold on any risk slice: the task goes back to Stage 2 (assist only) until it passes | The use-case owner; model risk is informed |
| Incident | Kill switch; the stage is frozen; incident review follows the existing incident process | The incident lead; restart needs the use-case owner and security or risk |
| Near miss | The task is paused while the cause is found; it resumes if the control held | The team lead, with the enablement lead |
| Control gap | The team drops to the last stage whose controls are evidenced; a dated remediation plan follows | The control owner in the second line tracks remediation; internal audit follows closure only for findings it raised |
| Material use-case change | New data, new users or customer impact: back to intake; the risk tier is decided again | Intake and triage |
| Exception expires | The capability the exception allowed stops until renewed or fixed | The exception owner |
| Reviewer capacity drops | Delegated tasks pause; nothing is approved unread | The team lead |
| Asset loses its owner | The asset is marked unsupported; teams that use it are warned | The catalog owner |
6. Stages are not an entitlement to autonomy
A stage describes what a team can safely do. It never says what a use case is allowed to do. The risk tier decides that.
| Rule | What it means | In the due-date example |
|---|---|---|
| Maturity is not permission | A Stage 4 team still runs high-risk use cases with a human operating every consequential step | The team is at Stage 4, but a proposal for live AI generation of customer reminder wording is high: compliance reviews it, and the team does not automate it because of its stage |
| High risk may stay manual | A high-risk use case may stay human-operated at any stage | Reissuing a statement is never done by an agent; statements are immutable once issued |
| Prohibited stays prohibited | No stage unlocks a prohibited use case | Sending real customer statements to an unapproved tool is not allowed at Stage 5 either |
| Roles move separately | Different roles sit at different stages | QA at Stage 3 and the product owner at Stage 1 is a healthy team |
7. The maturity × risk matrix
Read a row for one risk tier and a column for one stage. Each cell says whether AI may do that stage's kind of work for that tier. "With conditions" names the extra controls from the risk tier.
| Risk tier | Stage 0 | Stage 1 | Stage 2 | Stage 3 | Stage 4 | Stage 5 |
|---|---|---|---|---|---|---|
| Low | Not yet: foundations first | Allowed | Allowed | Allowed, with a reviewer | Allowed, with Stage 4 controls | Allowed |
| Medium | Not yet: foundations first | With conditions: data classification check | With conditions: classification check and traces | With conditions: evaluation set, traces, a reviewer | With conditions: all of Stage 3, plus independent approval of each consequential action | With conditions: continuous evaluation |
| High | Not yet: foundations first | With conditions: no customer data in the prompt; the human applies every change | With conditions: privacy and AI or model risk review of the use | With conditions: independent validation, monitoring, a reviewer outside the team | Rarely: consequential steps stay human-operated; kill switch tested | With conditions: periodic review and monitoring stay mandatory |
| Prohibited | Not allowed | Not allowed | Not allowed | Not allowed | Not allowed | Not allowed |
| Cell | Meaning |
|---|---|
| Allowed | The stage's controls are enough |
| With conditions | The stage's controls plus the tier's controls; the cell names the extra ones |
| Rarely | Possible only after a separate decision by the second line, and usually not worth it |
| Not allowed | No stage, exception or business case changes this |
8. One team, five stages
A healthy team rarely sits at one stage. This snapshot of the due-date team is illustrative; chapter 6 gives each role's path in full.
| Role | Stage today | Why there | Next evidence needed |
|---|---|---|---|
| Product owner | 1 | Drafts outcomes; no reusable prompt yet | A reviewed outcome-brief prompt in the team's prompt library |
| Business analyst | 2 | Story prompt grounded in the team glossary | An evaluation set for story drafts, with negative cases |
| Developer | 3 | Coding agent opens PRs; reuse decisions recorded | Least-privilege tool access and a tested kill switch |
| QA engineer | 3 | Test generation passes its evaluation set on every slice | Regression workflow in a sandbox, with recovery tested |
| Release manager | 2 | Release-notes prompt only | Traces and an approval gate for change-record drafts |
The worked example follows this team from Stage 0 to Stage 4. The measure chapter defines the exit evidence metrics, with denominators and owners.