Capstone — Your Responsible AI Adoption Plan

Module 2 · Unit 4 | Module capstone (final lesson)

By the end of this lesson, you will be able to:

• Describe the six components of a Responsible AI Adoption Plan and explain what each requires of your project (K1, K2, K3, K15)
• Produce a structured risk register covering legal, ethical, human-impact and change-management risks with likelihood, impact and mitigation (K2, K15, S3, S15)
• Integrate your business case, risk work, stakeholder analysis and oversight design into one coherent, actionable governance document (K1, K2, K3, K15, S15, S24, B2)
• State your project's compliance position honestly — distinguishing what is confirmed, what is uncertain, and what requires further action (S2, B1)

Why this is the capstone of the module

Everything you have done across this module has been leading here. You framed the problem and pitched it (Unit 1); you defined goals, scope and a delivery approach (Unit 2); you built a risk register and applied the responsible-AI lens of human impact and meaningful oversight (Unit 3); and you mapped stakeholders, planned the change and designed your communications and governance gates (Unit 4). The Responsible AI Adoption Plan is where those threads become a single document.

This is not an administrative exercise. It is a professional record of how you have thought about your project — evidence a senior colleague, a client, or a regulator could examine. It is also the single AO1 evidence thread for the programme: the dispersed strategic-and-ethical-adoption work you do in later modules feeds back into this plan rather than being assessed in fragments. Practically, it is the document that unlocks the build: with it complete, you and your organisation can decide whether to proceed, on what terms, and with what safeguards.

🌱 A living governance baseline. Your project has no working AI agent yet — so this plan is a baseline, not a final governance document. It captures the risks you can assess now: data, legal, stakeholder, human-impact and oversight-design risks. The technical agent-security risks — prompt injection, tool permissions, least-privilege scoping — are added to this same plan later, once you actually build the agent (Module 6 onwards). Treat the plan as a document you will return to and extend, not one you complete and file away.

What to bring together

You are not writing from scratch — you are synthesising work you have already produced:

• Your AI Opportunity Business Case from Module 1 — the foundation this plan extends.
• Your workflow map from Module 1, now annotated in Unit 3 with human-oversight checkpoints and error-recovery paths.
• Your risk register from Unit 3 — including the human-impact risks and the oversight stress-test.
• Your stakeholder map, RACI and governance gates from Unit 4.
• The data-protection and responsible-AI essentials you learned in Module 1 (UK GDPR lawful bases, special-category data, the five ethical principles, the Equality Act) — applied here to your project.

Each component below draws on a specific set of these outputs and adds the integration layer.

Component 1 — Stakeholder Impact Summary

Covers: who is affected by this automation and how, what your stakeholder work revealed, and what design decisions resulted.

Draw on: your Unit 4 stakeholder map and the human-impact risks from Unit 3.

Should demonstrate: genuine engagement with the human dimension — not just who is affected but what that means for how the system should be designed. The strongest entries are specific: a particular concern raised by a particular role, and the specific design change that resulted from it.

🔑 Key term: Stakeholder impact — the totality of effects, intended and unintended, that an AI deployment has on the people directly and indirectly involved, including job role changes, skill requirements, workload shifts, psychological impact, and changes to professional identity.

A strong Stakeholder Impact Summary names the people affected (by role, not necessarily by name), describes the nature of the impact, and records what you did in response — whether through a design change, a consultation commitment, or an escalation to a decision-maker with the authority to act.

Component 2 — Legal and Data Compliance Position

Covers: based on the data-protection and legal essentials from Module 1 applied to your project, what is your current compliance position?

Should demonstrate: an honest position, in three categories:

• Confirmed: where you have identified the relevant framework, established a lawful basis or compliance approach, and have sufficient confidence the design meets it.
• Requires further action: where you identified a risk or uncertainty not yet resolved — name the specific issue and the specific next step.
• Sign-offs needed: decisions that are not yours to make (DPO, HR, legal, line manager) — name the role, the question, and by when it is needed.

📌 Honesty beats false certainty. A compliance position that presents everything as "confirmed" is a liability. Gaps acknowledged accurately show you understand the framework well enough to know where your knowledge ends. The plan does not need to resolve every uncertainty — it needs to be accurate about where the uncertainties are.

Component 3 — Responsible Design Decisions

Covers: the key ethical and governance choices in your design, with rationale for each.

Should demonstrate: that the responsible-AI principles from Module 1 are visible in specific choices, not just described. For each: what the choice was, why (the ethical or governance rationale), and what alternative you chose against. For example:

• Including a human review step that slows throughput, because the output affects a person in a way that requires genuine oversight.
• Not connecting the system to a data source that would improve performance, because the data-protection risk was disproportionate to the benefit.
• Designing a confidence threshold below which the system escalates rather than responds, because the consequences of a wrong confident answer are significant.
• Planning least-privilege access for any future system integration (e.g. read-only on specific fields) as a design principle now, ahead of the technical build in Module 6 onwards.

Component 4 — Human Oversight Framework

Covers: every human-oversight checkpoint in your workflow — what the human reviews, what information they have, what they can do if they disagree, and why this is meaningful oversight.

Draw on: the four oversight questions and the pseudo-oversight test from Unit 3.

Should demonstrate: oversight that is genuine, not nominal. For each checkpoint the four questions must be answerable: Does the reviewer see the input? Is the review time realistic? Can they actually override? Is the output explainable? If you cannot answer all four for a checkpoint, you have found a design gap to resolve before the plan is finalised.

🐾 Did you know? The UK's Algorithmic Transparency Recording Standard requires publication of structured records of algorithmic systems used in significant decisions, including a description of human oversight arrangements. It has been mandatory since 2025 for central government departments and their arm's-length bodies that provide public or frontline services or routinely interact with the public. It does not apply to private-sector deployments, but it is a useful template for what meaningful oversight documentation looks like — the hub carries the guidance and the published example records.

Component 5 — Risk Register

Covers: the key risks — legal, ethical, human-impact and change-management — with likelihood, impact and mitigation. This extends the register you built in Unit 3.

• Legal: data-protection gaps, Equality Act exposure, automated decision-making safeguards (UK GDPR Articles 22A to 22D), outstanding compliance questions.
• Ethical: fairness concerns, transparency gaps, accountability gaps.
• Human-impact: displacement, deskilling, automation bias, changes to roles not yet consulted on.
• Change management: staff resistance, skill gaps, insufficient training.

🌱 Placeholder for the technical layer. Add a stub row now — "Technical agent-security risks (prompt injection, tool permissions, least-privilege scoping) — to be assessed once the agent is built (Module 6 onwards)." This keeps the plan honest about what it does not yet cover and creates the hook you will return to.

Component 6 — Next Steps and Governance Sign-Off

Covers: what needs to happen before the project moves into design and build, who needs to approve it, and what conversations have happened or need to.

Structure it around three questions: What decisions are outstanding, and who has the authority to make them? What conversations have already happened, and what was agreed? What is the proposed sequence and a realistic timeline? Write it as if your line manager will read it and decide whether the governance of this project is in good hands.

What a strong plan looks like

• Integrated — it references and builds on your business case, risk register, stakeholder map and annotated workflow; it synthesises rather than restates.
• Honest — it distinguishes confirmed, uncertain, and needs-further-input, without false certainty.
• Actionable — named people, specific conversations, real timelines; not "consult relevant stakeholders".
• Written for a real audience — readable by your line manager, jargon explained, acronyms defined on first use.

Quick Check

📝 Produce your Responsible AI Adoption Plan

Estimated time: 90–120 minutes

Produce your plan using the six-component structure above. This extends and annotates your Module 1 business case — you do not rewrite it, you build the responsible-adoption layer on top and pull together the risk, stakeholder and oversight work from this module.

1. Stakeholder Impact Summary — who is affected and how, and the design decisions that resulted.
2. Legal and Data Compliance Position — confirmed / requires-further-action / sign-offs-needed.
3. Responsible Design Decisions — the choice, the rationale, and the alternative chosen against.
4. Human Oversight Framework — each checkpoint answered against the four oversight questions.
5. Risk Register — legal, ethical, human-impact and change risks, plus the technical-layer placeholder row.
6. Next Steps and Governance Sign-Off — outstanding decisions, conversations held, proposed sequence.

💡 Distinction note: A distinction-level plan analyses interdependencies between risks — where one risk can amplify or trigger another — and proposes mitigations that are proportionate, specific, and connected to the responsible-design decisions already described.

KSB coverage — Module capstone

✅ Module 2 complete. With your Responsible AI Adoption Plan produced, you have established the governance baseline for your project and demonstrated the strategic, legal and ethical awareness responsible AI practice requires. You will return to this plan as your project develops. Module 3 moves into designing the AI systems and architectures that will deliver it.