APMG AI Project Governance Framework (AIPGF) Practitioner Cheat Sheet
Cheat sheet: AIPGF Practitioner reference for AI project governance, lifecycle gates, roles, artifacts, risks, assurance, and scenario decisions.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context
Use this independent Cheat Sheet for candidates preparing for APMG International’s APMG AI Project Governance Framework (AIPGF) Practitioner exam, exam code AIPGF Practitioner.
Practitioner-style questions usually test applied judgment: which governance action, artifact, role, escalation, or control best fits the scenario. The strongest answer is normally the one that is proportionate, evidence-based, value-linked, risk-aware, and accountable.
Core Answer Pattern
| Step | Ask | Strong practitioner response |
|---|---|---|
| 1. Identify context | Is this idea, feasibility, development, deployment, operation, or change? | Match the action to the lifecycle point. Do not jump to deployment, procurement, or escalation too early. |
| 2. Confirm value | What business outcome or public/service value justifies AI? | Validate the business case and benefits before technical optimization. |
| 3. Classify risk | Who could be affected? How autonomous, novel, opaque, or sensitive is the use case? | Tailor governance intensity to impact and uncertainty. |
| 4. Check evidence | What artifact proves readiness? | Require data, model, security, human oversight, testing, and benefits evidence as applicable. |
| 5. Assign accountability | Who can accept the decision or residual risk? | Keep decision rights with the proper sponsor, board, owner, or assurance function. |
| 6. Decide next action | Continue, remediate, escalate, pause, or stop? | Prefer controlled progression over unmanaged experimentation. |
Use this Cheat Sheet before working through topic drills, mock exams, and detailed explanations for the APMG International APMG AI Project Governance Framework (AIPGF) Practitioner exam, code AIPGF Practitioner.
The Practitioner level is best approached as an application exam: you are not only recalling governance concepts, but deciding what should happen in a project scenario. Focus on:
- Choosing proportionate governance for an AI project’s risk and context.
- Identifying accountability gaps, weak controls, and missing evidence.
- Connecting AI-specific risks to project governance decisions.
- Distinguishing good governance from excessive paperwork or late-stage compliance checks.
- Selecting responses that protect business value, stakeholders, data, users, and long-term operational performance.
This page is PM Mastery review support. Use it alongside your AIPGF study materials and original practice questions to strengthen exam decision-making.
| Item | Review note |
|---|---|
| Vendor/provider | APMG International |
| Official exam title | APMG AI Project Governance Framework (AIPGF) Practitioner |
| Official exam code | AIPGF Practitioner |
| Cheat Sheet focus | Applying AI project governance principles to realistic project situations |
| Best practice method | Review the concept, answer scenario questions, then study detailed explanations |
After this Cheat Sheet, use PM Mastery practice to convert recognition into exam performance.
Topic drills
Use topic drills for one governance area at a time:
- AI governance principles.
- Lifecycle controls.
- Data governance.
- Model validation.
- Risk and assurance.
- Human oversight.
- Supplier governance.
- Operational monitoring and change control.
For each missed question, write down:
- The clue you missed in the scenario.
- The governance principle being tested.
- Why the correct option is more proportionate or better evidenced.
- Why the tempting option is incomplete.
Mock exams
When working full mock exams:
- Read the scenario before judging the options.
- Identify the project stage and risk level.
- Look for missing owners, missing evidence, or missing lifecycle controls.
- Eliminate answers that defer governance, rely on assumptions, or solve only the technical issue.
- Review detailed explanations, including questions you answered correctly by guessing.
AI Project Governance Decision Path
flowchart TD
A[AI idea, project issue, or change request] --> B{Clear business outcome and owner?}
B -- No --> B1[Clarify objective, benefits, sponsor, and success measures]
B -- Yes --> C{AI is justified over simpler options?}
C -- No --> C1[Reassess solution approach or stop AI route]
C -- Yes --> D{Impact, uncertainty, or autonomy is significant?}
D -- Low --> D1[Use proportionate controls and standard project governance]
D -- High --> E[Complete risk, data, ethics, security, and assurance checks]
E --> F{Evidence supports next stage?}
F -- No --> F1[Remediate, time-box discovery, or escalate]
F -- Yes --> G{Residual risk within delegated authority?}
G -- No --> G1[Escalate to appropriate governance body or sponsor]
G -- Yes --> H[Authorize next stage with monitoring and change controls]
Lifecycle Governance Map
| Lifecycle point | Governance question | Key evidence/artifacts | Common trap | Best next action |
|---|---|---|---|---|
| Idea / mandate | Is there a justified need for AI? | Problem statement, objectives, sponsor, initial benefits hypothesis | Starting with model choice or vendor demo | Clarify outcome, users, decision context, and whether AI is appropriate |
| Feasibility | Is the use case viable, valuable, and governable? | Business case, options analysis, initial risk/impact assessment | Treating proof of concept as approval for production | Time-box feasibility and define stage-gate evidence |
| Data readiness | Is data suitable, authorized, representative, and controlled? | Data inventory, provenance, lineage, quality report, data management plan | Assuming more data automatically improves fairness or performance | Fix data issues before model claims are accepted |
| Solution design | Are architecture, oversight, explainability, security, and integration addressed? | Solution design, control design, human oversight model, threat model | Designing governance after build completion | Build controls into design, not as late documentation |
| Development / experimentation | Are experiments traceable and bounded? | Experiment logs, version control, model registry, test datasets | Unmanaged notebooks, undocumented feature changes | Maintain reproducibility and decision records |
| Validation | Does the system perform acceptably for intended use and affected groups? | Evaluation report, bias/fairness testing, robustness tests, user acceptance evidence | Relying only on aggregate accuracy | Validate against business, ethical, operational, and subgroup criteria |
| Authorization / deployment | Is release justified with residual risk understood? | Go/no-go recommendation, deployment plan, rollback plan, operational readiness checklist | Sponsor pressure overrides unresolved assurance findings | Authorize only within delegated tolerances or escalate |
| Operation | Is the AI system still performing safely and usefully? | Monitoring dashboard, incident log, drift reports, benefits tracking | Treating deployment as project closure with no model ownership | Monitor performance, harms, drift, and benefit realization |
| Change / retraining | Does the change alter risk, behavior, users, or accountability? | Change request, impact reassessment, updated model/system card | “It is only a retrain” avoids change control | Reassess based on effect, not label |
| Retirement | Should the AI capability be decommissioned or replaced? | Retirement plan, data retention/disposal evidence, transition plan | Keeping unused models active indefinitely | Retire safely, preserve records, and protect users/data |
Governance Roles and Accountability
| Role or group | Primary accountability | Practitioner exam cue | Avoid this error |
|---|---|---|---|
| Sponsor / senior responsible owner | Business justification, benefits, funding, acceptance of business risk within authority | Benefits unclear, strategic alignment questioned, funding decision needed | Making the project manager own business justification alone |
| Project board / governance board | Stage authorization, tolerances, escalation decisions, continued viability | Residual risk exceeds delegated limits; go/no-go decision needed | Escalating every routine technical issue |
| Project manager | Delivery control, issue/risk management, coordination, reporting, escalation | Work is off plan, evidence missing, unresolved dependencies | Personally accepting ethical, legal, or strategic risk outside authority |
| Product owner / business owner | Requirements, user value, prioritization, operational fit | Conflicting feature priorities or acceptance criteria | Optimizing model metrics while ignoring user workflow |
| Data owner | Data access, permitted use, quality expectations, retention constraints | New dataset, unclear provenance, access request | Assuming the AI team can use any available data |
| Data steward / data governance lead | Metadata, lineage, quality rules, data handling controls | Inconsistent labels, missing provenance, quality defects | Treating data cleaning as a purely technical task |
| AI / ML lead | Model design, training approach, technical evaluation, reproducibility | Model performance, feature engineering, experiment control | Deciding production risk without governance input |
| Security lead | Threat modeling, access control, secure deployment, adversarial risk | API exposure, model theft, prompt injection, supply chain issue | Addressing security only after deployment |
| Privacy / legal / compliance specialist | Interpretation of applicable obligations and compliance risks | Personal, sensitive, regulated, or cross-border data concern | Inventing legal conclusions without specialist input |
| Ethics / responsible AI reviewer | Fairness, accountability, transparency, human impact, contestability | Potential harm, vulnerable groups, opaque automated decisions | Treating ethics as optional communication activity |
| Independent assurance / audit | Objective review of controls, evidence, and governance operation | High-impact release or unresolved control weakness | Having only the build team validate its own work |
| Operations / service owner | Production support, monitoring, incidents, service continuity | Model is live or about to be handed over | Closing project without operational ownership |
| Supplier / vendor manager | Third-party obligations, service levels, assurance access, exit planning | Black-box model, SaaS AI, external data processor | Assuming supplier reputation removes due diligence |
Artifact Selection Matrix
| Artifact | Use when | What it proves | High-yield distinction |
|---|---|---|---|
| AI use case brief | Early idea or mandate | Problem, decision context, users, intended value | Prevents technology-first project initiation |
| Business case | Funding, prioritization, continuation, stage approval | Value, cost, risk, options, disbenefits, benefits owner | A technically feasible AI model is not automatically a viable project |
| AI risk / impact assessment | Any meaningful AI use case; especially high impact, autonomous, sensitive, or novel | Risk level, affected groups, control needs, escalation route | Drives proportional governance intensity |
| Stakeholder analysis | Users, affected parties, operators, regulators, support teams, or impacted communities are unclear | Interests, influence, communication and engagement needs | Affected people may not be system users |
| Data management plan | Data is collected, reused, acquired, transformed, or retained | Source, permissions, quality, lineage, retention, access control | Data governance starts before model training |
| Data quality report | Model depends on dataset reliability | Completeness, consistency, bias, label quality, missingness | Clean-looking data may still be unrepresentative |
| Model card / system card | Model/system behavior must be explained to governance, operators, or stakeholders | Intended use, limitations, metrics, training data summary, risks | Documentation should support decisions, not just describe algorithms |
| Evaluation and test strategy | Before accepting model performance or release | Test methods, acceptance criteria, subgroup performance, robustness | Accuracy alone is rarely enough |
| Human oversight plan | Humans review, approve, override, or contest AI outputs | Decision rights, escalation, competence, workload, override process | “Human in the loop” is not effective if humans cannot challenge outputs |
| Security threat model | AI system is exposed, integrated, high value, or supplier-based | Attack surfaces, controls, monitoring, response | AI adds threats such as data poisoning, model extraction, prompt injection |
| Responsible AI / ethics assessment | Harms, fairness, transparency, vulnerable users, or significant autonomy are present | Ethical risks, trade-offs, mitigations, accountability | Ethics is a governance input, not public relations |
| Deployment and rollback plan | Production release or major change | Release steps, fallback, monitoring, owner, support readiness | Production readiness includes failure handling |
| Monitoring plan | Live AI service, changing data, model drift risk | Metrics, thresholds, alerts, ownership, review cadence | Monitoring must include business and harm indicators, not only uptime |
| Incident response plan | AI failure could harm users, operations, trust, or compliance | Detection, triage, escalation, containment, communication | AI incidents can be model, data, security, or human-process failures |
| Benefits realization plan | Business case benefits must be tracked after delivery | Baseline, target, owner, measurement method, review point | Model performance is not the same as realized benefit |
| Change control record | Retraining, threshold change, new data, new users, or supplier update occurs | Impact assessment, approval, traceability | “Minor technical change” can be major governance change |
Tailoring Governance Intensity
| Factor increasing governance intensity | Why it matters | Stronger controls to consider |
|---|---|---|
| High impact on people, rights, access, safety, money, employment, or essential services | Consequences of error or unfairness are greater | Formal impact assessment, independent assurance, explicit board approval |
| High autonomy | Less human correction before harm occurs | Human oversight design, fail-safe controls, tighter monitoring |
| Sensitive or personal data | Higher privacy, security, and trust risk | Data minimization, access controls, provenance, specialist review |
| Vulnerable or disadvantaged affected groups | Harm may be uneven or harder to contest | Fairness testing, stakeholder engagement, accessible redress |
| Novel model, novel data, or novel use case | Historical assurance evidence is weaker | Time-boxed discovery, staged gates, pilot limits |
| Opaque model or black-box supplier | Harder to explain, validate, and challenge | Explainability requirements, supplier assurance, operational limits |
| Dynamic environment | Drift and decay are more likely | Monitoring thresholds, retraining triggers, change control |
| Integration with critical systems | Failure can cascade | Resilience, rollback, service continuity, security testing |
| Regulatory, contractual, or reputational exposure | Accountability extends beyond the project team | Specialist review, evidence retention, formal approvals |
| Low organizational readiness | Users may misuse or over-trust outputs | Training, communication, adoption controls, support model |
Common Scenario Decisions
| Scenario cue | Weak answer | Strong AIPGF Practitioner-style action |
|---|---|---|
| Sponsor wants rapid deployment before validation is complete | Accept the pressure because benefits are urgent | Explain missing evidence, assess risk, seek appropriate governance decision, and do not bypass required assurance |
| Proof of concept achieved high accuracy | Move straight to production | Confirm production data, controls, monitoring, security, user workflow, and benefits case |
| Dataset has missing fields and uncertain provenance | Train anyway and document later | Pause or time-box investigation; establish provenance, quality, permitted use, and remediation |
| Model performs worse for a subgroup | Report only overall metric | Investigate cause, assess fairness and impact, adjust data/model/process, and escalate if residual risk is material |
| New dataset becomes available | Add it to improve performance | Reassess permitted use, quality, bias, lineage, and change impact before use |
| Supplier offers a proprietary black-box model | Accept supplier assurance at face value | Require evidence, contractual controls, explainability/operational limits, and exit arrangements |
| Human reviewers always accept AI recommendations | Claim oversight exists | Investigate automation bias, improve training/interface, define override expectations, and monitor reviewer behavior |
| Model drift alert triggers | Ignore until next planned review | Triage as operational issue; assess impact, rollback/retrain if needed, record decision |
| Benefits are not being realized despite good model metrics | Improve algorithm only | Revisit workflow, adoption, baseline, user behavior, and benefits ownership |
| Risk exceeds project manager tolerance | Project manager decides alone | Escalate to the role/body with authority to accept, reduce, transfer, or reject residual risk |
| A change affects users, data, or decision thresholds | Treat as routine technical update | Use change control and update risk, testing, documentation, monitoring, and approvals |
| Users do not understand AI output | Add technical model details | Provide role-appropriate explanation, limitations, confidence guidance, and escalation route |
| Incident causes incorrect decisions | Retrain quietly | Contain, assess harm, communicate as required by governance route, preserve evidence, fix root cause |
Notes and examples
Scenario decision rules
| If the scenario says… | Prefer an answer that… | Avoid an answer that… |
|---|---|---|
| The project is moving fast | Adds proportionate controls without stopping delivery unnecessarily | Skips governance to protect the schedule |
| The model is highly accurate | Checks suitability, fairness, explainability, and operational impact | Treats accuracy as the only acceptance criterion |
| A vendor provides the AI | Requires due diligence, evidence, contractual controls, and monitoring | Accepts vendor assurances without challenge |
| Data comes from a new source | Reassesses data rights, quality, bias, and security | Reuses old approvals automatically |
| Users distrust the AI | Improves transparency, training, feedback, and oversight | Forces adoption without addressing concerns |
| AI affects people materially | Strengthens impact assessment, human review, appeal, and monitoring | Uses a fully automated process without justification |
| The system performs worse after go-live | Investigates drift, data changes, incidents, and thresholds | Assumes the original validation is still sufficient |
| The project lacks clear ownership | Assigns decision rights and accountability | Leaves responsibility with “the team” or “the algorithm” |
| There is pressure to deploy | Uses readiness criteria and documented risk acceptance | Lets senior pressure override unresolved high risks |
| The use case changes | Reassesses governance, controls, and approvals | Treats it as a minor technical change |
Change Control for AI Systems
| Change type | Reassessment needed? | Include these roles | Evidence to update |
|---|---|---|---|
| Code defect fix with no behavioral change | Light, unless controls or outputs change | AI lead, project/service owner, tester | Change log, regression test evidence |
| Retraining on refreshed data for same use | Yes, because behavior can change | AI lead, data owner, service owner | Data quality, evaluation report, model/system card |
| New data source | Yes | Data owner, privacy/compliance as applicable, AI lead | Data provenance, permitted use, quality, risk assessment |
| Feature engineering change | Yes, if explainability, fairness, or performance changes | AI lead, data steward, responsible AI reviewer | Evaluation, fairness checks, documentation |
| Decision threshold change | Yes, often material | Business owner, AI lead, risk owner | Impact analysis, false positive/false negative trade-off |
| New user group or population | Yes, high importance | Sponsor, stakeholder lead, responsible AI reviewer | Impact assessment, subgroup testing, communications |
| New purpose or business process | Treat as new or materially changed use case | Sponsor, board, risk/compliance specialists | Business case, risk assessment, governance approvals |
| Increased automation / reduced human review | Yes, high importance | Sponsor, operations, risk, ethics, assurance | Oversight plan, risk acceptance, monitoring thresholds |
| Supplier model version change | Yes, depending on impact | Supplier manager, AI lead, security, service owner | Supplier release notes, test results, assurance evidence |
| Decommissioning or replacement | Yes | Service owner, data owner, sponsor | Retirement plan, data disposal/retention evidence, transition plan |
Responsible AI Controls
| Principle | Practical control | Evidence to look for | Common trap |
|---|---|---|---|
| Accountability | Named owners for business outcome, data, model, risk, and operation | RACI, governance approvals, decision logs | “The algorithm decided” is treated as accountability |
| Transparency | Clear explanation of intended use, limitations, and decision influence | Model/system card, user guidance, communication plan | Giving users technical detail that does not help them act |
| Fairness | Test for uneven error rates or harmful outcomes across relevant groups | Fairness analysis, subgroup metrics, mitigation records | Relying on overall performance only |
| Privacy and data governance | Minimize data, control access, confirm provenance and permitted use | Data management plan, access logs, lineage | Using available data without confirming suitability |
| Robustness and safety | Test failure modes, edge cases, drift, and resilience | Robustness tests, monitoring plan, incident process | Assuming test performance remains stable in production |
| Security | Protect data, model, pipeline, prompts, APIs, and outputs | Threat model, secure architecture, vulnerability testing | Treating AI security as ordinary application security only |
| Human agency and oversight | Enable meaningful review, override, escalation, and challenge | Oversight plan, training, audit of override behavior | Human review is nominal or overloaded |
| Contestability | Allow affected parties or users to question outcomes | Appeals or review route, support scripts, audit trail | No route to correct harmful or incorrect outputs |
| Proportionality | Match controls to risk, impact, and uncertainty | Tailoring record, risk acceptance rationale | Applying either no governance or excessive bureaucracy |
| Sustainability and maintainability | Consider operating cost, environmental/resource burden, lifecycle support | Architecture and operations assessment | Selecting a model that cannot be supported responsibly |
Risk Reference
| Risk category | Example causes | Impact | Controls |
|---|---|---|---|
| Strategic / value risk | Weak business case, AI not needed, benefits unclear | Waste, reputational damage, opportunity cost | Options analysis, benefits owner, stage reviews |
| Data risk | Poor quality, biased labels, uncertain provenance, unauthorized use | Inaccurate or unfair outputs, compliance issues | Data governance plan, quality checks, lineage, access controls |
| Model risk | Overfitting, poor calibration, low robustness, opaque logic | Wrong decisions, inconsistent behavior | Validation, stress testing, explainability, model documentation |
| Fairness / ethics risk | Uneven performance, proxy variables, harmful automation | Discrimination, loss of trust, user harm | Impact assessment, subgroup testing, oversight, redress |
| Security risk | Data poisoning, model extraction, prompt injection, insecure APIs | Breach, manipulation, service compromise | Threat modeling, secure pipeline, monitoring, access control |
| Operational risk | Drift, poor handover, weak incident response, support gaps | Service failure, accumulating harm | Monitoring, runbooks, ownership, rollback |
| Change risk | Retraining changes behavior, supplier update, new context | Undetected degradation or new harm | Change control, regression testing, reauthorization |
| Supplier risk | Black-box model, unclear data use, lock-in, weak assurance | Loss of control, hidden obligations, poor exit options | Due diligence, audit evidence, contract controls, exit plan |
| Stakeholder risk | Low adoption, poor understanding, over-trust, resistance | Benefits not realized, misuse | Engagement, training, clear guidance, feedback channels |
| Governance risk | Unclear accountability, weak escalation, missing evidence | Unauthorized risk acceptance | RACI, decision records, stage gates, independent assurance |
Notes and examples
Useful Formulas
Use formulas only when the scenario provides the variables and asks for prioritization, risk exposure, project control, or evaluation metrics.
\[ \text{Risk Exposure} = P(\text{event}) \times \text{Impact} \]\[ \text{Expected Monetary Value} = P(\text{outcome}) \times \text{Monetary Impact} \]\[ \text{Cost Performance Index} = \frac{\text{Earned Value}}{\text{Actual Cost}} \]\[ \text{Schedule Performance Index} = \frac{\text{Earned Value}}{\text{Planned Value}} \]\[ \text{Precision} = \frac{TP}{TP + FP} \]\[ \text{Recall} = \frac{TP}{TP + FN} \]\[ F_1 = 2 \times \frac{\text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}} \]Metric Interpretation
| Metric | Plain meaning | Governance caution |
|---|---|---|
| Accuracy | Share of correct predictions | Can hide poor performance on minority classes or high-impact cases |
| Precision | Of positive predictions, how many were correct | Important when false positives cause harm or cost |
| Recall / sensitivity | Of actual positives, how many were found | Important when missed cases are harmful |
| False positive rate | How often negatives are incorrectly flagged | May create unfair burden, cost, or unnecessary intervention |
| False negative rate | How often positives are missed | May create safety, access, or service failure risk |
| F1 score | Balance between precision and recall | Useful when classes are imbalanced, but still not a business outcome |
| Calibration | Whether confidence scores reflect real likelihood | Poor calibration can mislead human decision-makers |
| Drift | Change in data, concept, or performance over time | Requires monitoring, thresholds, and response ownership |
| Latency | Time to produce output | May affect user workflow, safety, or service levels |
| Explainability | Ability to understand key factors or rationale | Must fit the audience and decision context |
Agile, Predictive, and Hybrid Delivery
| Situation | Better delivery stance | Governance implication |
|---|---|---|
| Uncertain data quality or model feasibility | Time-boxed agile discovery | Permit learning, but keep boundaries, records, and decision gates |
| Stable compliance, procurement, or infrastructure requirements | Predictive or controlled planning | Define approvals, dependencies, evidence, and acceptance criteria early |
| AI model development inside a regulated or high-impact service | Hybrid | Iterate technically, but retain formal governance gates |
| Frequent model experimentation | Agile technical workflow | Version experiments, document assumptions, and prevent uncontrolled production use |
| Production deployment and operational handover | Controlled release management | Require readiness, rollback, monitoring, and support ownership |
| Benefits realization after launch | Iterative improvement | Track outcomes and adjust workflow, model, or adoption plan |
Notes and examples
Agile Governance Traps
- Agile does not remove the need for risk assessment, data controls, or authorization.
- A sprint review is not the same as independent assurance.
- A working model is not the same as an operationally safe service.
- Backlog priority should consider risk, value, dependencies, and governance evidence.
- Technical experimentation should be sandboxed and traceable.
Stage-Gate Readiness Checklist
| Gate | Minimum readiness questions |
|---|---|
| Start feasibility | Is the problem clear? Is AI plausibly justified? Is there a sponsor and benefits hypothesis? |
| Start development | Is data access authorized? Are quality and provenance understood? Are evaluation criteria defined? |
| Start validation | Are model versions, test data, expected performance, and acceptance thresholds documented? |
| Deploy pilot | Is scope limited? Are users briefed? Are monitoring, fallback, and incident routes in place? |
| Full production | Are residual risks accepted by the right authority? Are operations, support, monitoring, and benefits tracking ready? |
| Continue operation | Are performance, fairness, drift, incidents, and benefits still acceptable? |
| Major change | Has the change been classified and reassessed? Are documentation and approvals updated? |
| Retire | Are users transitioned, data handled appropriately, records preserved, and dependencies removed? |
Stakeholder and Communication Reference
| Stakeholder group | Needs | Useful evidence or communication |
|---|---|---|
| Sponsor / governance board | Value, risk, options, tolerances, decision request | Business case, risk summary, stage report, recommendation |
| End users | How to use outputs, limitations, escalation route | User guidance, training, confidence/limitations explanation |
| Affected parties | How decisions affect them and how to challenge errors | Clear notices, review/appeal route, support process |
| Operations and support | How to monitor, triage, and restore service | Runbook, incident plan, monitoring thresholds |
| Data owners | How data is used, protected, retained, and changed | Data management plan, lineage, access records |
| Compliance / legal / privacy specialists | Facts needed to interpret obligations | Data flows, purpose, controls, risk assessment |
| Security team | Attack surfaces, access paths, deployment model | Threat model, architecture, vulnerability results |
| Assurance / audit | Objective evidence of control design and operation | Decision logs, approvals, tests, monitoring records |
| Supplier manager | Obligations, assurance evidence, change and exit controls | Supplier documentation, contract controls, service reports |
Benefits and Value Control
| Item | Good practice | Exam cue |
|---|---|---|
| Benefit definition | Measurable outcome with baseline, target, owner, and review date | “Improve decisions” is too vague |
| Benefit owner | Business role accountable for realization | Project team cannot realize operational benefits alone |
| Leading indicators | Adoption, cycle time, accuracy, recall, user compliance, override rates | Indicators help but do not prove final value |
| Disbenefits | Negative outcomes that may occur even if project succeeds | Increased workload, user mistrust, unfair burden |
| Value-risk trade-off | Compare benefit against residual risk and cost of controls | High performance may not justify unacceptable harm |
| Benefits review | Continue after deployment | Project closure is not the end of benefits governance |
Supplier and Third-Party AI Governance
| Supplier issue | Governance response |
|---|---|
| Proprietary or black-box model | Define minimum explainability, testing, monitoring, and assurance evidence required |
| Supplier uses customer data for improvement | Confirm permitted use, controls, and opt-in/opt-out position through appropriate review |
| Model updates are controlled by supplier | Require notification, versioning, test evidence, rollback, and change impact review |
| Service-level dependency | Define availability, incident, support, and continuity expectations |
| Exit or lock-in risk | Plan data export, replacement approach, knowledge transfer, and termination handling |
| Unclear intellectual property or data rights | Seek specialist review before commitment |
| Supplier claims compliance generally | Ask for evidence specific to the use case, data, deployment, and operating context |
Assurance and Escalation
When to Escalate
Escalate when:
- Residual risk exceeds delegated authority or tolerance.
- Business case viability is uncertain or benefits no longer justify risk.
- Data use, fairness, privacy, security, or ethics concerns cannot be resolved by the team.
- Required evidence for a stage gate is missing or disputed.
- Model behavior changes materially after retraining, new data, or supplier update.
- An incident causes or could cause harm, service failure, or loss of trust.
- Stakeholder objections reveal a material impact not previously assessed.
- A decision requires acceptance by a sponsor, governance board, or specialist authority.
When Not to Escalate
Do not escalate merely to avoid routine management responsibility. Handle within the team when the issue is inside delegated limits, controls are known, and no material change to risk, scope, benefits, or accountability is involved.
Common Exam Traps
| Trap | Better reasoning |
|---|---|
| “AI is innovative, so it should be used.” | Confirm AI is justified against simpler, safer, cheaper options. |
| “The model is accurate, so it is ready.” | Check data, fairness, robustness, security, oversight, operations, and benefits. |
| “The project manager can accept the risk.” | Risk acceptance must match delegated authority and governance structure. |
| “A pilot success authorizes full deployment.” | Production needs operational readiness, wider impact assessment, monitoring, and approval. |
| “Human oversight solves accountability.” | Oversight must be meaningful, trained, resourced, and auditable. |
| “Supplier assurance removes customer responsibility.” | The organization still needs use-case-specific governance and evidence. |
| “More data reduces bias.” | More data can amplify bias if source, labels, or representation are flawed. |
| “Documentation can be completed later.” | Key artifacts support decisions before progression. |
| “Agile means governance can be lightweight always.” | Governance is tailored to risk, not delivery style. |
| “No personal data means no ethical risk.” | AI can still create unfair, unsafe, opaque, or harmful outcomes. |
| “Retraining is routine maintenance.” | Retraining can change behavior and may require reassessment. |
| “Explainability is only for technical staff.” | Explanations must be useful to decision-makers, users, affected parties, and governance bodies. |
Final Revision Checklist
Before answering a scenario question, check:
- What lifecycle point is the project in?
- What decision is being asked: proceed, pause, remediate, escalate, approve, or stop?
- Is the business outcome clear and still justified?
- Is AI appropriate compared with non-AI alternatives?
- Which risks are material: data, model, ethics, security, operations, supplier, stakeholder, or benefits?
- What evidence is missing?
- Which role has authority to decide or accept residual risk?
- Is the proposed action proportionate to impact and uncertainty?
- Does the answer preserve traceability, accountability, and monitoring?
- Does the answer avoid overreacting, bypassing controls, or solving governance issues with technical fixes only?
Practitioner mindset: the answer usually depends on governance fit
In scenario questions, the strongest option is often the one that:
- Starts governance early, not after technical build.
- Makes accountability explicit.
- Uses risk-based proportionality.
- Requires evidence, not assumptions.
- Includes lifecycle monitoring after deployment.
- Protects affected stakeholders, not only project sponsors.
- Integrates AI controls into project delivery rather than treating governance as a separate checklist.
Avoid options that sound efficient but bypass governance, rely only on technical accuracy, defer ethics or risk assessment, or accept vendor claims without validation.
flowchart TD
A[AI project idea or change] --> B{Clear business purpose?}
B -- No --> C[Clarify outcomes, users, value, constraints]
B -- Yes --> D{Material AI risk or stakeholder impact?}
D -- Yes --> E[Apply proportionate governance, assurance, and approval]
D -- No --> F[Use lightweight documented controls]
E --> G[Validate data, model, controls, and human oversight]
F --> G
G --> H{Ready for deployment?}
H -- No --> I[Remediate gaps and update evidence]
H -- Yes --> J[Operate, monitor, report, and manage change]
J --> K{Drift, incident, new use, or data change?}
K -- Yes --> E
K -- No --> J
Core governance concepts to know cold
| Concept | What it means in an AI project | Common exam trap |
|---|---|---|
| Governance | Decision rights, oversight, assurance, accountability, and control | Confusing governance with day-to-day project management |
| Accountability | Named people or bodies own decisions and outcomes | Saying “the algorithm decided” or “the vendor is responsible” |
| Proportionality | Controls match risk, complexity, impact, and uncertainty | Applying either no controls or excessive controls without risk basis |
| Transparency | Stakeholders can understand purpose, limitations, and decision logic at the right level | Assuming transparency means exposing all code or model internals |
| Explainability | Ability to provide meaningful reasons for outputs or decisions | Treating a black-box result as acceptable because accuracy is high |
| Fairness | Risks of bias, exclusion, or unequal impact are identified and managed | Testing only overall performance and ignoring subgroup impact |
| Human oversight | Humans have authority, competence, and practical ability to intervene | Adding a nominal “human in the loop” who cannot challenge the system |
| Assurance | Independent or objective checking that controls work | Treating self-certification by the delivery team as sufficient |
| Traceability | Decisions, data, assumptions, changes, and approvals are recorded | Poor documentation that prevents audit, learning, or incident response |
| Lifecycle governance | Governance continues through operation, monitoring, change, and retirement | Assuming the project ends when the model goes live |
AI project lifecycle: high-yield governance questions
| Stage | Key governance questions | Evidence to expect |
|---|---|---|
| Idea / use case | What problem is AI solving? Is AI necessary and appropriate? Who is affected? | Use case statement, business objective, initial risk screening |
| Initiation | Who owns benefits, risks, funding, and decisions? | Business case, governance structure, role assignments |
| Data discovery | Is data lawful, suitable, representative, secure, and traceable? | Data inventory, quality checks, provenance records, data risk assessment |
| Design | What controls, thresholds, oversight, and explainability are required? | Solution design, control plan, human oversight model |
| Build / configure | Are development practices controlled and reproducible? | Version records, development logs, configuration documentation |
| Validation | Does the solution meet business, risk, fairness, safety, and performance criteria? | Test results, validation report, exception log, approval record |
| Deployment | Are users trained and operational controls ready? | Deployment plan, user guidance, monitoring plan, incident process |
| Operation | Is performance stable and are harms detected? | Monitoring reports, drift checks, service metrics, issue logs |
| Change | Do new data, model updates, prompts, or use cases alter risk? | Change impact assessment, re-validation evidence, approval record |
| Retirement | Is the system safely decommissioned and records retained appropriately? | Retirement plan, data handling records, lessons learned |
AI risk areas and practical controls
| Risk area | What to look for in scenarios | Strong governance response |
|---|---|---|
| Business alignment | AI solution is impressive but not tied to measurable value | Reconfirm objectives, benefits, decision criteria, and sponsor ownership |
| Data quality | Missing, stale, biased, incomplete, or unrepresentative data | Data profiling, cleansing, suitability assessment, documented limitations |
| Privacy and confidentiality | Sensitive or personal data used without clear control | Privacy review, minimisation, access controls, retention rules |
| Security | Model, data, prompts, or integrations can be attacked or misused | Security review, threat assessment, access management, testing |
| Bias and fairness | Performance varies by user group or context | Subgroup testing, fairness criteria, remediation, monitoring |
| Explainability | Users cannot understand or challenge outputs | Appropriate explanations, user guidance, escalation paths |
| Model performance | Accuracy is measured narrowly or in lab-only conditions | Fit-for-purpose metrics, acceptance thresholds, real-world validation |
| Operational resilience | Model failure disrupts services or decisions | Fallback process, incident response, continuity planning |
| Human impact | Decisions affect rights, access, safety, employment, or welfare | Impact assessment, stronger oversight, appeal or review mechanisms |
| Supplier dependency | Vendor system is treated as a black box | Due diligence, contractual controls, assurance evidence, exit planning |
| Drift and degradation | Model changes behavior as data or environment changes | Monitoring, thresholds, retraining triggers, change control |
| Regulatory / policy exposure | Project team assumes compliance is someone else’s job | Early legal, risk, compliance, or policy engagement where relevant |
Data governance: quick decision rules
AI governance usually fails when data is treated as a technical input instead of a governed asset.
Review these data questions
- Purpose: Is the data being used for the purpose originally intended or approved?
- Provenance: Where did it come from, and can the source be trusted?
- Permission: Are rights, consents, licences, contracts, or internal policies respected?
- Quality: Is it accurate, complete, timely, consistent, and relevant?
- Representativeness: Does it reflect the population or operating environment?
- Sensitivity: Does it include personal, confidential, regulated, or high-risk information?
- Lineage: Can the team trace transformations from source to model input?
- Retention: How long is data kept, and how is it deleted or archived?
- Access: Who can view, modify, export, or reuse it?
- Change: What happens when a data source, schema, supplier, or collection method changes?
Notes and examples
Common data traps
- Assuming more data is always better.
- Using historical data that embeds past unfairness.
- Ignoring data that was collected for a different purpose.
- Treating synthetic data as automatically safe or unbiased.
- Failing to document exclusions, transformations, or known limitations.
- Validating the model without validating the data pipeline.
Model governance and validation
A Practitioner candidate should be able to choose a validation approach that matches the AI use case and risk level.
| Validation focus | Strong practice | Weak practice |
|---|---|---|
| Performance | Metrics reflect the actual decision or service outcome | Only reporting a single aggregate accuracy score |
| Thresholds | Acceptance criteria are agreed before deployment | Adjusting success criteria after seeing results |
| Robustness | Model is tested under realistic variation and edge cases | Testing only clean examples from development data |
| Fairness | Impact is assessed across relevant groups and contexts | Assuming fairness because the model does not use protected attributes |
| Explainability | Explanations are suitable for users, reviewers, and affected parties | Technical explanations that decision-makers cannot use |
| Security | Attack paths and misuse cases are considered | Assuming AI security is covered by general IT security |
| Reproducibility | Versions of data, code, prompts, parameters, and models are recorded | Inability to recreate a result or investigate an incident |
| Independence | High-risk validation has objective review or challenge | Delivery team validates only its own work |
| Operational readiness | Monitoring, support, escalation, and fallback are tested | Treating go-live as the end of governance |
Generative AI and large-model considerations
If the scenario involves generative AI, foundation models, chatbots, summarisation, code generation, document search, or decision support, look for additional governance issues.
| Issue | What can go wrong | Governance response |
|---|---|---|
| Hallucination | Plausible but false outputs are trusted | Use verification, citations, confidence guidance, and human review |
| Prompt injection | Malicious input changes system behavior | Security testing, input controls, output filtering, monitoring |
| Data leakage | Sensitive data is exposed through prompts or outputs | Usage rules, access controls, redaction, approved tools |
| Retrieval errors | System cites irrelevant or outdated documents | Curated knowledge sources, retrieval testing, content ownership |
| Overreliance | Users stop applying professional judgment | Training, warnings, review requirements, escalation criteria |
| Content safety | Harmful, biased, or inappropriate content is generated | Guardrails, testing, monitoring, incident handling |
| IP and licensing | Inputs or outputs create ownership or usage issues | Supplier review, policy checks, approved data sources |
| Model updates | External model changes affect behavior | Supplier monitoring, regression testing, change controls |
Human oversight: more than “human in the loop”
Human oversight is credible only when the human can actually govern the AI-supported decision.
| Oversight requirement | What good looks like |
|---|---|
| Competence | Reviewers understand the AI’s purpose, limits, and escalation rules |
| Authority | Humans can override, stop, or escalate the AI-supported process |
| Time and information | Reviewers have enough context to make a meaningful judgment |
| Independence | Sensitive decisions can be challenged by someone not invested in delivery success |
| Accountability | Decision ownership remains clear even when AI provides recommendations |
| Feedback loop | Human interventions and errors improve monitoring and future controls |
Exam trap: an answer may say a human approves every output, but if the human lacks training, time, or authority, the control is weak.
Business case, benefits, and value governance
AI projects can fail by being technically successful but commercially or operationally unjustified.
Check the business case for
- Clear problem statement and expected outcomes.
- Reason AI is appropriate compared with simpler alternatives.
- Measurable benefits and benefit owners.
- Costs beyond build: data management, assurance, monitoring, retraining, licences, support, security, and change management.
- Risks, assumptions, dependencies, and constraints.
- Stakeholder impact and operational readiness.
- Exit or fallback options if the AI solution underperforms.
Practitioner decision rule
Choose the option that keeps the business case alive through the lifecycle. AI value should be rechecked when assumptions change, not only approved at project start.
Roles and responsibilities to recognise
Exact role names may vary by organisation, but scenario answers should preserve clear decision rights and accountability.
| Role or stakeholder | Governance responsibility to look for |
|---|---|
| Sponsor / senior responsible owner | Owns business justification, risk appetite alignment, funding, and benefits |
| Project board / governance body | Provides direction, approval, challenge, and escalation |
| Project manager | Coordinates delivery controls, plans, risks, issues, and reporting |
| AI / technical lead | Ensures technical design, build, testing, and limitations are understood |
| Data owner / steward | Owns data suitability, quality, access, lineage, and usage controls |
| Model owner / service owner | Owns operational performance and lifecycle monitoring after go-live |
| Risk / compliance / legal specialists | Advise on obligations, risk controls, and evidence requirements |
| Security specialists | Assess threats, access, resilience, and technical protection |
| Ethics or responsible AI reviewers | Challenge stakeholder impact, fairness, transparency, and acceptable use |
| End users | Validate usability, workflow fit, and operational practicality |
| Affected stakeholders | Provide insight into impact, harm, accessibility, and fairness |
| Supplier / vendor | Provides evidence, documentation, support, and contractual commitments |
| Independent assurance | Tests whether controls and claims are reliable |
Assurance and auditability
A well-governed AI project leaves an evidence trail. In scenario questions, missing evidence is often the clue that governance is weak.
Useful evidence pack
- Use case and approved purpose.
- Stakeholder and impact assessment.
- Risk register with AI-specific risks.
- Data inventory, provenance, and quality assessment.
- Model design or configuration documentation.
- Validation and test results.
- Fairness, explainability, robustness, and security assessments where relevant.
- Human oversight design.
- Supplier due diligence and assurance evidence.
- Approval records and decision logs.
- Deployment readiness checklist.
- Monitoring plan and thresholds.
- Incident and escalation process.
- Change control records.
- Retirement or decommissioning plan where applicable.
Assurance decision rule
For higher-risk AI, assurance should be more independent, more evidence-based, and more lifecycle-oriented. Do not choose an answer that relies only on informal confidence from the delivery team.
Common candidate mistakes
- Memorising definitions but not applying them to the scenario.
- Selecting the most technically sophisticated answer instead of the best-governed answer.
- Choosing heavy governance for every situation without considering proportionality.
- Ignoring post-deployment monitoring.
- Treating AI risk as only a data science issue.
- Missing stakeholder harm because the business benefit sounds strong.
- Assuming a human review step automatically solves accountability.
- Assuming supplier tools are already compliant or validated.
- Forgetting that changes to data, context, prompts, model versions, or usage can require reassessment.
- Choosing answers that document risks but do not assign owners or actions.
- Confusing project approval with operational acceptance.
- Overlooking fallback, incident response, and service continuity.
Fast review checklist before practice
Use this checklist when reviewing any AIPGF Practitioner scenario:
- What is the AI use case and business objective?
- Who benefits, who is affected, and who could be harmed?
- Is AI justified, or would a simpler solution be more appropriate?
- What is the project’s risk level and impact profile?
- Who owns business value, risk, data, model performance, and operations?
- Are data sources suitable, lawful, secure, and representative?
- Are model limitations known and documented?
- Are validation metrics fit for the intended decision?
- Has fairness or differential impact been considered?
- Are explanations appropriate for users and affected parties?
- Is human oversight meaningful and accountable?
- Are security and misuse risks addressed?
- Are supplier claims independently checked where needed?
- Are approvals based on evidence?
- Are go-live criteria clear?
- Are users trained and operational processes ready?
- Are monitoring thresholds defined?
- Is there a fallback or incident response route?
- Does change control cover data, model, prompt, supplier, and use-case changes?
- Is the evidence trail strong enough for audit, assurance, and learning?
Final last-pass summary
For the APMG International APMG AI Project Governance Framework (AIPGF) Practitioner exam, code AIPGF Practitioner, think like a governance practitioner: protect value, clarify accountability, control AI-specific risk, require evidence, and keep oversight active after deployment.
Your next step: work through original practice questions by topic, then complete a timed mock exam and review every explanation until you can consistently identify the governance decision behind each scenario.