No organization adopts AI as one crowd, and a large regulated one least of all. A chief information officer (CIO) adopts it through funding and risk appetite. A developer adopts it through a coding agent and then by building AI features into products. A production support engineer adopts it at three in the morning, during an incident. One common ladder cannot describe all of that, so this chapter gives nineteen role tracks, each written to the same template. Every track opens with your first steps and ends that section with the fully adopted workflow: how the work runs at Stage 4 to 5 and what changes for the organization.
Treat each track as a starting shape: rename the roles to match your org chart and tune the steps to your own workflow.
1. Start from what you need to do
| I need to… | Start with |
|---|---|
| Fund and steer AI adoption, set risk appetite | Executive sponsor |
| Lead a team through the change, protect reviewer time | Engineering manager · Project and delivery lead |
| Shape what gets built and accept it | Product owner · Business analyst · Experience designer |
| Build software and agentic products | Architect · Developer · AI engineer |
| Prepare data and the platform | Data engineer and steward · Platform engineer and FinOps |
| Test and produce first-line release evidence | QA engineer |
| Independently challenge or validate | Independent validation |
| Release and run in production | Release manager · Production support and SRE |
| Govern and secure | Risk and compliance · Security |
| Use AI in customer operations | Business operations |
| Run the enablement program | AI enablement lead |
2. From requirement to production, every role on one path
AI does not wait for full adoption to reach production. At Stage 1 every change still reaches production through the normal process; AI only helps people draft. What adoption changes is how much of each step agents do, and how much evidence surrounds it. The accountable decision at each step stays with the same role.
| Step | Roles | At the start (Stage 1 to 2) | Fully adopted (Stage 4 to 5) | Decision that stays human |
|---|---|---|---|---|
| Ask | Executive sponsor · Product owner | Summarize the request with an approved tool; log the use case at intake | Agents turn an accepted intake into a brief, a risk-tier draft and a metric | Fund it, set the risk tier, accept the outcome |
| Shape | Business analyst · Experience designer · Architect | Draft stories and criteria; a human rewrites each one | Impact analysis across every service; the reuse check runs before any design | Reuse, extend or create; accept the stories |
| Build | Developer · AI engineer · Data engineer · Platform engineer | Explain code, suggest a test; the human types the change | A bounded workflow drafts the pull request in a sandbox and fixes failing checks | Approve the merge (never the requester) |
| Test | QA engineer · Independent validation | Suggest edge cases; QA chooses | Generated tests and evaluation sets on every change; independent validation for high-tier use | Pass or fail against thresholds; accept residual risk |
| Release | Release manager | Draft release notes | The change record assembles itself from CI, tests and approvals | Go or no-go; rollback |
| Run | Production support · Business operations | Summarize logs and tickets | Agents correlate alerts and propose runbook steps; staff use AI with customers behind a fallback path | Incident command; every action on production |
| Govern, throughout | Risk and compliance · Security · AI enablement lead | Approve tools, set acceptable use, run the first labs | Monitoring, periodic review and material-change review run on evidence the pipeline already produces | Set the standards; challenge; stop the work |
3. In any organization
The tracks are written for a large regulated organization because that is the hardest case. A smaller or unregulated organization follows the same order with fewer people and lighter paperwork.
| In a large regulated organization | In a small or unregulated organization |
|---|---|
| Nineteen separate roles | One person covers several tracks: the tech lead is architect and release manager; a founder is the executive sponsor |
| A second-line risk function and independent validation | A peer from another team challenges high-impact use cases |
| Formal change authority and change records | A pull request template and a short release checklist |
| Full evidence retention under policy | Keep the traces, decision records and evaluation results you would need to explain an incident |
What never scales down: no customer or secret data in unapproved tools; the requester of an agent task never approves it; a kill switch for anything that acts on its own; a human in command of incidents.
4. Two kinds of adoption, on every track
| Kind | What it means | Example |
|---|---|---|
| AI in how you work | The role's own tasks: drafting, analysis, review, triage | A business analyst drafts stories from approved policy text |
| AI in what you deliver | The product, platform, control or service the role is responsible for contains AI | An AI engineer ships a policy assistant; security threat-models it; operations staff use it with customers on the line |
The ladder stage describes the controls, context and evaluation around a use case. It is not seniority, and it is never permission to hand an accountable decision to an agent. Every track names at least one activity that stays human-operated even at Stage 5.
5. Decision relationships
"Who approves" is too coarse once AI is in the work. Every track uses five relationships.
| Relationship | Means | Example |
|---|---|---|
| Owner or approver | Holds the decision and its accountability | The product owner accepts the feature |
| Independent validator or challenger | Tests the claim without being part of the team that built it | Independent validation reviews the policy assistant's evaluation design |
| Consulted control partner | Gives a control view before the decision | Privacy reviews the data flow |
| Evidence recipient | Receives records to keep or assess | Internal audit receives the inventory and validation evidence |
| Notified | Told after the decision | The contact-center lead learns of the release date |
6. Nineteen tracks in eight families
Families follow the lifecycle. The badge on each track shows its line of defense: 1st line delivers and owns the risk, 2nd line sets standards and challenges, and internal audit (the 3rd line) assesses independently.
Lead
Shape
Build
Data & platform
Assure
Release & run
Govern
Adopt
7. The common template
Every track uses the same fifteen sections in the same order, so a reader can compare roles side by side.
| # | Section | What it answers |
|---|---|---|
| 1 | At a glance | Mandate, main decision, first safe win, biggest failure mode |
| 2 | Your journey | First steps, the fully adopted workflow, what changes for the organization, how it looks in any organization |
| 3 | Your decisions | What you own, advise or challenge, and what you never delegate |
| 4 | Two kinds of adoption | AI in how you work, AI in what you deliver |
| 5 | Your ladder | Stage 0 to 5: AI use, guardrail, evidence, decision relationship, step-down trigger |
| 6 | Priority scenarios | Value, risk tier, stage, first step, when not to use AI |
| 7 | The due-date ask from your seat | Your part of the worked example |
| 8 | Hand-offs | What you give, receive, challenge and hear about |
| 9 | Evidence and records | What you produce or consume, and where it is kept |
| 10 | Skills and learning path | Foundation, practitioner, advanced, with labs |
| 11 | Measures and incentives | How the role is judged, with anti-gaming notes |
| 12 | Cost, capacity and workforce | Budget, reviewer time, jobs and skills |
| 13 | Anti-patterns and stop conditions | What goes wrong and what stops the work |
| 14 | Action kit and 30/60/90 | A copy-ready card and the first ninety days |
| 15 | One diagram | The role's decision, evidence or operating loop |
8. Separation of duties, in one table
| Artifact | Requested or produced by | Approved by |
|---|---|---|
| Epic brief | PO, with an agent drafting | Business owner |
| User stories | BA, with an agent drafting | PO |
| Temporal-domain contract | Architect | Architecture review board, not the author |
| PR | Developer or coding agent | A different developer, under branch protection |
| Generated test suite | QA engineer or agent | A different QA engineer or the test lead |
| Change record | Release manager or agent | Change authority |
| Validation report | Independent validation | Use-case owner or the policy-named authority accepts or approves the use, subject to recorded restrictions and residual risk |
An agent is never an approver. When an agent does the work, the person who delegated it is the requester, and the approval goes to someone else with the existing authority.
9. Internal audit: the third-line interface
Internal audit is not a track and not part of the second line. It receives evidence (the AI inventory, control design, validation reports, change records, monitoring and exceptions) and independently assesses whether governance works. It never approves a first-line release and never designs controls for management. The risk and compliance and executive sponsor tracks show the interface in detail.