Convert principles into decisions
Responsible AI becomes useful when a project can show how a concern changes its design or release decision. A statement that a team values fairness does not identify the affected people, the possible harm or the evidence needed to assess that harm. Begin with the actual use and the decision the system influences.
This workbook uses a fictional employee knowledge-search assistant. It retrieves internal guidance and proposes answers; it does not approve leave, evaluate employees or make employment decisions. Writing that boundary clearly helps prevent later expansion into uses the project has not assessed.
Identify stakeholders and foreseeable misuse
List users, people described in the data, the process owner, support staff and reviewers who can stop a release. Ask what happens when the answer is wrong, confidential information is retrieved or a user relies on an outdated policy. Include foreseeable misuse rather than considering only cooperative users.
Document an accountable person for each risk and an escalation route. A project team should obtain the legal, privacy, security and domain review appropriate to the use. PMI’s AI project approach provides a delivery structure; it does not remove requirements imposed by applicable law or organisational policy.
Build a data and access record
For each source, record the owner, permitted purpose, access rules, freshness and retention. A search assistant must not expose a document merely because it can technically index it. Test access using accounts with different permissions and include document removal in the data lifecycle.
Use synthetic examples to explore failure cases before involving confidential records. If a real pilot needs personal information, obtain the appropriate authorisation and controls. Record how inaccurate source content is corrected and how the correction reaches the assistant.
Define evaluation before demonstration
Write evaluation cases that include ordinary questions, ambiguous wording, outdated content, requests for restricted information and questions with no supported answer. Decide what counts as an acceptable response in each case. A refusal or referral can be the correct outcome when evidence is missing.
Keep evaluation examples separate from development examples where possible. Record the model or service version, retrieval configuration and relevant prompts. Review outcomes with domain specialists rather than reducing every case to whether the answer sounded fluent.
Use release gates and a fallback
A release gate should identify the decision maker, evidence required and unresolved risks. For the assistant, that might include permission tests, source citations, an approved escalation workflow and user instructions. A risk acceptance must have an authorised owner; the project manager should not silently accept it for everyone.
Prepare a fallback such as disabling automated answers while keeping links to approved guidance. Assign incident handling, monitoring and change review after launch. Reassess when new data, a new model or a new use changes the risk, rather than assuming the first approval covers future behaviour.
Use the workbook for study
PMI-CPMAI preparation is stronger when you explain the consequences of each governance decision across the lifecycle. Ask how a new data restriction changes feasibility, preparation, evaluation and operation. Build scenario questions from those changes without copying examination content.
The practical output is a traceable set of decisions: purpose, stakeholders, data rules, evaluation, release and operation. It is not a claim that certification alone makes an AI system lawful or safe. Keep the evidence proportional to the actual use and seek the specialist review the project requires.
Official references
Certification requirements and programme terms can change. Use the issuer’s current page and your account to confirm details before applying or paying.