APMG AI Project Governance Framework (AIPGF) Foundation Exam Blueprint
Practical exam blueprint for the APMG AI Project Governance Framework (AIPGF) Foundation exam, covering AI governance, risk, roles, lifecycle controls, and final review readiness.
How to Use This Exam Blueprint
Use this checklist as a practical study map for the APMG International APMG AI Project Governance Framework (AIPGF) Foundation exam, code AIPGF Foundation. It is designed to help you check whether you can recognize, explain, and apply AI project governance concepts in exam-style scenarios.
Because exact official weighting is not provided here, treat the areas below as readiness areas rather than a weighted syllabus. Your goal is not only to memorize terms, but to decide what good governance looks like when an AI initiative has uncertainty, data dependency, stakeholder impact, ethical exposure, delivery pressure, and operational risk.
For each area, ask:
- Can I explain the concept in plain language?
- Can I identify the best next governance action in a short scenario?
- Can I choose the right artifact, role, review, control, or escalation path?
- Can I distinguish AI-specific governance concerns from general project management concerns?
- Can I recognize when an AI project should pause, escalate, re-scope, or add assurance?
Topic-area readiness map
| Readiness area | What to review | What “ready” looks like |
|---|---|---|
| AI project governance purpose | Why AI projects need explicit governance beyond normal project controls | You can explain how governance protects value, accountability, trust, risk management, and responsible delivery. |
| Framework orientation | Key terms, governance concepts, decision points, roles, and artifacts used by the AIPGF materials | You can map a scenario to the framework language without substituting only generic PM terms. |
| AI project characteristics | Uncertainty, data dependence, model behavior, explainability limits, human impact, bias, drift, automation risk | You can identify why an AI project may need different controls from a conventional IT project. |
| Governance roles and accountability | Sponsor, project leadership, governance bodies, assurance roles, technical specialists, business owners, users, affected stakeholders | You can determine who should decide, who should advise, who should be consulted, and who should be informed. |
| Project initiation and justification | Problem framing, business case, benefits, feasibility, risk appetite, ethical fit, strategic alignment | You can judge whether an AI initiative is ready to proceed or needs clarification before approval. |
| AI use-case classification | Type of AI use, impact level, criticality, stakeholder exposure, operational context | You can identify when a use case requires stronger oversight, validation, transparency, or human control. |
| Delivery approach | Predictive, agile, iterative, experimental, hybrid, proof-of-concept, pilot, production transition | You can explain how governance should be tailored without removing necessary controls. |
| Data governance | Data sourcing, quality, consent, relevance, representativeness, lineage, privacy, retention, access | You can spot data risks that threaten fairness, legality, performance, or benefits. |
| Model development or acquisition | Build vs buy, vendor solutions, configuration, training, validation, integration, intellectual property | You can identify governance checks needed before committing to a model or supplier approach. |
| Testing and validation | Functional testing, model performance testing, bias testing, robustness, security, user acceptance, operational readiness | You can select suitable validation evidence before deployment or approval. |
| Risk and control management | AI-specific risks, project risks, operational risks, compliance risks, reputational risks, control design | You can connect each risk to an owner, response, control, review point, and evidence artifact. |
| Ethics and responsible AI | Fairness, transparency, accountability, human oversight, explainability, societal impact, unintended consequences | You can recognize ethical concerns and decide when they require escalation or redesign. |
| Legal, regulatory, and policy alignment | Internal policy, external obligations, contractual duties, data protection, sector rules, audit needs | You can identify when specialist legal, compliance, or data protection input is needed. |
| Stakeholder engagement | Users, sponsors, customers, regulators, impacted communities, operational teams, technical teams | You can choose communication and involvement strategies based on impact and risk. |
| Change control | Scope changes, model changes, data changes, supplier changes, policy changes, release changes | You can identify when a change is material enough to require governance review. |
| Quality and assurance | Independent review, stage or gate reviews, peer review, auditability, evidence quality, acceptance criteria | You can separate “the team says it works” from objective evidence that governance can rely on. |
| Deployment and transition | Go-live readiness, human oversight, training, support, monitoring, incident response, rollback | You can determine whether deployment should proceed, be limited, be delayed, or require extra controls. |
| Operations and monitoring | Model drift, performance degradation, feedback loops, incidents, retraining, continuous assurance | You can explain why governance continues after project delivery. |
| Benefits and value realization | Benefit definition, measurement, ownership, timing, disbenefits, value tracking | You can identify whether benefits are credible, measurable, and linked to the AI use case. |
| Documentation and audit trail | Decisions, assumptions, approvals, risk assessments, test results, model documentation, change records | You can identify which records support accountability and future review. |
Core concepts to know cold
Governance and accountability
Be ready to explain the difference between project delivery and project governance.
| Concept | Candidate check |
|---|---|
| Governance | Can you describe how direction, oversight, decision-making, and accountability are established? |
| Management | Can you separate day-to-day delivery management from governance approval and assurance? |
| Accountability | Can you identify who owns outcomes, risks, benefits, and decisions? |
| Delegation | Can you explain what can be delegated and what still requires accountable oversight? |
| Escalation | Can you recognize when a project issue exceeds tolerance, authority, or risk appetite? |
| Assurance | Can you explain why independent or objective review matters for AI projects? |
| Evidence-based decisions | Can you identify what evidence is needed before a governance decision? |
AI project-specific concerns
| AI-specific concern | What to be ready to do |
|---|---|
| Data quality | Identify poor, incomplete, outdated, biased, or unrepresentative data as a governance risk. |
| Data provenance | Recognize when unclear data origin, consent, licensing, or lineage should block or delay progress. |
| Bias and fairness | Identify affected groups and ask whether outcomes may be unfair, discriminatory, or disproportionate. |
| Explainability | Decide whether stakeholders need understandable reasons for AI-assisted decisions. |
| Model performance | Distinguish technical accuracy from business suitability and operational acceptability. |
| Human oversight | Identify where human review, override, approval, or appeal may be necessary. |
| Automation impact | Recognize risks when AI changes decisions, jobs, controls, customer treatment, or safety. |
| Model drift | Understand why performance may degrade after deployment and require monitoring. |
| Security | Identify risks from data exposure, model misuse, adversarial inputs, and system integration. |
| Supplier opacity | Recognize risks when a vendor model cannot be fully inspected or explained. |
“Can you do this?” checklist
Use this section as a quick readiness test. If you cannot answer an item confidently, mark it for revision.
Framework and terminology
- I can state the purpose of the APMG AI Project Governance Framework (AIPGF) in exam-appropriate terms.
- I can recognize key AIPGF Foundation terminology from the official study materials.
- I can distinguish AI governance from general IT governance and from routine project administration.
- I can identify governance activities across initiation, delivery, deployment, and operation.
- I can explain why AI projects require ongoing oversight after go-live.
- I can apply framework concepts to a short scenario without relying on memorized definitions only.
Project initiation and justification
- I can check whether the problem statement is clear enough for an AI solution.
- I can identify when an AI solution is being proposed before the business need is understood.
- I can evaluate whether the business case includes benefits, risks, assumptions, costs, and constraints.
- I can spot unrealistic benefit claims or unsupported accuracy claims.
- I can identify when a proof of concept is appropriate and when it is insufficient for production approval.
- I can distinguish technical feasibility from business viability and ethical acceptability.
- I can identify when governance should stop, pause, redirect, or escalate an initiative.
Roles, responsibilities, and decision rights
- I can identify who should approve a high-impact AI use case.
- I can identify who should own data-related risks.
- I can identify when legal, compliance, security, privacy, or ethics specialists should be involved.
- I can distinguish the role of project manager, sponsor, technical lead, product owner, data owner, risk owner, and assurance reviewer.
- I can identify when affected stakeholders need consultation rather than simple communication.
- I can identify conflicts of interest in governance or validation.
Delivery approach and tailoring
- I can explain how governance works in agile, predictive, and hybrid AI projects.
- I can identify controls that should not be removed just because the delivery approach is agile.
- I can explain how iterative experimentation can be governed through clear boundaries and review points.
- I can distinguish discovery, proof of concept, pilot, minimum viable product, and production release.
- I can decide when risk level should increase governance intensity.
- I can identify when tailoring is appropriate and when it becomes under-governance.
Data and model governance
- I can identify data quality criteria relevant to an AI project.
- I can spot risks from biased, incomplete, stale, or non-representative data.
- I can identify when data privacy, consent, retention, or access needs review.
- I can explain why training data and live operating data may differ.
- I can distinguish model development risks from data governance risks.
- I can identify evidence needed before model deployment.
- I can recognize when model retraining or recalibration may require formal change control.
Risk, ethics, and compliance
- I can build a basic AI project risk view covering delivery, data, model, user, operational, legal, security, and reputational risks.
- I can connect risks to controls and accountable owners.
- I can identify when risk exposure exceeds governance tolerance.
- I can spot ethical concerns related to fairness, transparency, human agency, and unintended harm.
- I can identify when a scenario needs escalation to a governance body or specialist function.
- I can distinguish risk acceptance from ignoring a risk.
- I can explain why compliance is necessary but not always sufficient for responsible AI.
Testing, assurance, and release
- I can identify the types of testing evidence that may be needed for an AI-enabled solution.
- I can distinguish model validation from user acceptance testing.
- I can identify when independent assurance should be used.
- I can evaluate whether acceptance criteria are measurable.
- I can identify whether release readiness includes training, support, monitoring, and incident response.
- I can decide whether a go-live should proceed, be limited, be delayed, or be rejected.
- I can explain why post-deployment monitoring is a governance concern.
AI project lifecycle readiness
The AIPGF Foundation exam may present governance scenarios at different points in an AI project. Practice recognizing the lifecycle point and the most appropriate governance response.
| Lifecycle point | Governance focus | Common exam-style decision |
|---|---|---|
| Idea or demand intake | Is the AI use case legitimate, valuable, and aligned? | Clarify the problem before approving solution work. |
| Feasibility and discovery | Is there enough evidence to justify continued investment? | Approve limited exploration, request more evidence, or stop. |
| Business case approval | Are value, risk, ethics, cost, and accountability clear? | Approve, reject, defer, or escalate based on evidence. |
| Data assessment | Are data sources suitable, lawful, reliable, and representative? | Proceed with controls, remediate data, change scope, or stop. |
| Model selection or build | Is the approach explainable, testable, secure, and fit for purpose? | Choose build/buy/modify based on governance criteria. |
| Prototype or proof of concept | Does the concept show potential without overstating readiness? | Allow controlled experimentation but avoid premature production use. |
| Pilot | Can the solution work safely in a limited real-world setting? | Define pilot controls, user feedback, monitoring, and exit criteria. |
| Production release | Is evidence sufficient for operational use? | Approve release, restrict release, require remediation, or defer. |
| Operation | Is the AI solution still performing acceptably and responsibly? | Monitor, review, retrain, suspend, or escalate incidents. |
| Retirement or replacement | Should the AI capability continue? | Retire, replace, archive records, or transition controls. |
Governance decision flow
Use this simplified flow to practice “what should happen next?” scenario questions.
flowchart TD
A[AI idea or change proposed] --> B{Business need clear?}
B -- No --> B1[Clarify problem, outcomes, and stakeholders]
B -- Yes --> C{AI impact and risk understood?}
C -- No --> C1[Assess impact, data, ethics, compliance, and operational risk]
C -- Yes --> D{Evidence supports proceeding?}
D -- No --> D1[Request more analysis, prototype, or remediation]
D -- Yes --> E{Within authority and risk tolerance?}
E -- No --> E1[Escalate to appropriate governance authority]
E -- Yes --> F[Approve next stage with controls and review points]
F --> G[Monitor delivery, change, risk, benefits, and operational readiness]
G --> H{Ready for deployment?}
H -- No --> H1[Delay, remediate, or reduce scope]
H -- Yes --> I[Release with monitoring, support, and accountability]
I --> J[Review performance, drift, incidents, and benefits]
Scenario and decision-point checks
What should be done next?
| Scenario cue | Better answer pattern | Weak answer pattern |
|---|---|---|
| The sponsor wants to deploy after a successful demo, but testing used a small internal dataset. | Require broader validation, data assessment, and deployment readiness evidence. | Approve because the demo worked. |
| The team says the model is accurate, but cannot explain which data was used. | Investigate data provenance, quality, permissions, and lineage. | Treat accuracy as sufficient evidence. |
| A high-impact AI decision affects customers or employees. | Ensure stakeholder impact, human oversight, appeal, fairness, and accountability are addressed. | Focus only on delivery schedule. |
| The project uses a supplier black-box AI service. | Review contractual, assurance, transparency, security, and operational monitoring controls. | Assume supplier responsibility removes governance responsibility. |
| Agile team wants to release frequent model updates. | Tailor governance with clear thresholds, automated checks, review points, and change controls. | Remove governance because agile is iterative. |
| Data quality issues are discovered late. | Reassess scope, risk, benefit assumptions, validation evidence, and release decision. | Log as a minor issue and continue unchanged. |
| Benefits depend on user adoption, but users distrust the AI output. | Address explainability, training, stakeholder engagement, and change management. | Increase technical model tuning only. |
| A model performs well overall but poorly for a subgroup. | Treat as fairness and performance risk requiring analysis and possible redesign. | Accept the average performance metric. |
| An incident occurs after go-live. | Activate incident process, assess impact, notify appropriate parties, update risk and controls. | Wait for the next scheduled project meeting. |
| New regulation or internal policy affects the AI use case. | Escalate, assess compliance impact, update governance artifacts, and review continuation. | Continue under the original approval. |
When to escalate
Escalation is likely the right answer when:
- Risk exceeds the authority of the project team.
- Ethical, legal, privacy, security, safety, or reputational exposure is significant.
- Benefits, scope, or assumptions have materially changed.
- Data is unsuitable, unlawfully obtained, or not representative enough for the intended use.
- A stakeholder group may be adversely affected.
- Assurance evidence is missing, weak, or contradicted.
- A supplier cannot provide required transparency or control evidence.
- Production use is proposed before readiness criteria are met.
- The project no longer aligns with organizational strategy or risk appetite.
- Human oversight, appeal, or accountability is unclear.
What artifact should be updated?
| Trigger | Artifact or record to consider |
|---|---|
| New or changed risk | Risk register, issue log, risk assessment, control plan |
| Material scope change | Business case, project plan, change record, governance decision log |
| Data source change | Data assessment, data lineage record, privacy review, access control record |
| Model change | Model documentation, validation evidence, change record, release note |
| Stakeholder impact change | Stakeholder analysis, communication plan, impact assessment |
| Compliance concern | Compliance assessment, legal review record, decision log |
| Test failure | Test report, defect log, remediation plan, acceptance evidence |
| Go-live delay | Project schedule, release plan, benefits plan, stakeholder communications |
| Incident after deployment | Incident record, risk register, root cause analysis, monitoring plan |
| Benefit assumption changes | Business case, benefits realization plan, sponsor decision record |
Roles and stakeholder readiness
You do not need to memorize a generic organization chart. You do need to understand how accountability, expertise, and decision rights should work in AI project governance.
| Role or stakeholder type | Governance interest | Candidate readiness prompt |
|---|---|---|
| Sponsor or business owner | Value, funding, accountability, strategic fit | Can you identify when the sponsor must decide rather than the delivery team? |
| Project manager | Planning, coordination, risk, change, delivery control | Can you identify what the project manager should update or escalate? |
| Product owner or business representative | Requirements, user value, prioritization | Can you spot when business value conflicts with risk or ethics? |
| Data owner or steward | Data quality, access, lineage, permitted use | Can you recognize when data approval or remediation is required? |
| Technical or AI lead | Model approach, technical feasibility, testing | Can you distinguish technical advice from governance approval? |
| Security specialist | Threats, access, confidentiality, resilience | Can you identify security review needs before deployment? |
| Privacy or data protection specialist | Personal data, consent, retention, lawful use | Can you identify when privacy review is needed? |
| Legal or compliance function | Obligations, policy, contractual exposure | Can you identify when specialist interpretation is required? |
| Ethics or responsible AI reviewer | Fairness, transparency, human impact, accountability | Can you identify when ethical risk is material? |
| Assurance or audit function | Independent evidence, control effectiveness, traceability | Can you identify when independent review adds value? |
| Operations or service owner | Support, monitoring, incident management, continuity | Can you identify what must be in place before transition? |
| End users | Usability, trust, workflow fit | Can you identify adoption and training risks? |
| Affected individuals or groups | Fair treatment, transparency, recourse | Can you identify when consultation or impact assessment is needed? |
| Supplier or vendor | External capability, contractual controls, service risk | Can you identify retained governance responsibilities? |
Artifact and evidence checklist
Foundation-level scenarios often test whether you know what evidence should support a decision. Review the purpose of each artifact rather than memorizing document names only.
| Artifact or evidence type | Why it matters | Ready if you can answer |
|---|---|---|
| Problem statement | Prevents solution-first AI projects | Is the business problem clear and suitable for AI? |
| Business case | Links value, cost, risk, and benefits | Are benefits realistic and owned? |
| AI use-case assessment | Classifies impact and governance need | Is this low, moderate, or high concern in context? |
| Stakeholder analysis | Identifies affected and influential parties | Who is impacted, and how should they be involved? |
| Data assessment | Confirms data suitability and constraints | Is the data fit, permitted, and representative? |
| Risk assessment | Captures threats and responses | Who owns each risk and what controls reduce it? |
| Ethics or impact assessment | Considers fairness, transparency, harm, and accountability | Could the AI cause unacceptable harm or unfairness? |
| Model documentation | Describes model purpose, design, assumptions, limits | Can future reviewers understand what was built or configured? |
| Test and validation evidence | Supports readiness decisions | Does evidence cover the intended real-world use? |
| Acceptance criteria | Defines what good enough means | Are criteria measurable and agreed? |
| Change record | Tracks controlled changes | Was the change assessed for risk and impact? |
| Decision log | Preserves accountability | Who decided, when, based on what evidence? |
| Deployment plan | Supports safe release | Are training, monitoring, rollback, and support covered? |
| Monitoring plan | Enables post-go-live governance | What metrics, thresholds, and responses are defined? |
| Benefits realization plan | Tracks value after delivery | How will value be measured and who owns it? |
| Incident record | Supports response and learning | What happened, who was affected, and what changed? |
AI risk checklist
Risk categories to recognize
| Risk category | Example concern | Governance response |
|---|---|---|
| Strategic risk | AI use case does not support organizational objectives | Reassess alignment and business case. |
| Value risk | Benefits are vague, overstated, or not measurable | Define benefit owners, measures, and assumptions. |
| Delivery risk | Schedule pressure reduces validation or stakeholder engagement | Re-plan, escalate, or adjust scope. |
| Data risk | Data is biased, incomplete, outdated, or not permitted | Remediate, change source, reduce scope, or stop. |
| Model risk | Model behaves unpredictably or cannot be validated sufficiently | Add testing, constraints, monitoring, or alternative approach. |
| Ethical risk | Outputs may be unfair, opaque, or harmful | Conduct impact review and redesign controls. |
| Legal or compliance risk | Obligations are unclear or unmet | Seek specialist input and update governance decision. |
| Security risk | Data, model, or integration can be attacked or misused | Add security review, controls, and monitoring. |
| Operational risk | Support, monitoring, or incident response is not ready | Delay deployment until operations are prepared. |
| Reputational risk | AI outcome may damage trust | Escalate and reassess transparency and stakeholder impact. |
| Supplier risk | Vendor cannot evidence controls or performance | Strengthen contract, assurance, exit options, or selection. |
| Change risk | Model, data, or environment changes after approval | Use change control and reassess validation. |
Risk response readiness
For each material risk, can you identify:
- The risk event or condition.
- The cause.
- The likely impact.
- The accountable owner.
- The control or response.
- The evidence needed to prove the control works.
- The escalation threshold.
- The review frequency.
- The residual risk after controls.
- Whether the risk is acceptable within governance authority.
Ethics and responsible AI checklist
Be ready for scenario questions where the technically attractive answer is not the best governance answer.
| Topic | Readiness questions |
|---|---|
| Fairness | Could the AI treat individuals or groups differently in a way that is unjustified or harmful? |
| Transparency | Do users or affected parties need to know AI is involved? |
| Explainability | Can decisions or recommendations be explained at a level suitable for the context? |
| Human oversight | Is there a meaningful human review, override, or appeal route where needed? |
| Accountability | Is a human or governance body accountable for decisions and outcomes? |
| Privacy | Is personal or sensitive data used appropriately and lawfully? |
| Proportionality | Is the AI solution proportionate to the problem and risk? |
| Safety | Could failure cause harm, unsafe operation, or significant disruption? |
| Inclusion | Were affected stakeholders considered, including vulnerable or underrepresented groups? |
| Sustainability and long-term impact | Could operation, scaling, or misuse create new risks over time? |
Data governance readiness
AI project governance often fails when data assumptions are weak. Review data topics as governance issues, not only technical issues.
| Data question | Why it matters |
|---|---|
| What data is needed? | Confirms the use case is feasible and bounded. |
| Where does the data come from? | Supports lineage, trust, consent, and licensing. |
| Who owns or controls the data? | Clarifies accountability and access approval. |
| Is the data permitted for this use? | Reduces legal, privacy, contractual, and ethical risk. |
| Is the data representative? | Reduces bias and performance gaps. |
| Is the data current enough? | Reduces decisions based on stale patterns. |
| Is data quality measured? | Avoids relying on assumptions. |
| Are sensitive attributes handled correctly? | Supports privacy and fairness controls. |
| Can data be corrected or challenged? | Supports quality and stakeholder trust. |
| How will live data be monitored? | Helps detect drift and changing conditions. |
Testing, validation, and acceptance checks
Types of evidence to distinguish
| Evidence type | What it answers |
|---|---|
| Functional testing | Does the system perform required functions? |
| Model performance validation | Does the AI produce acceptable results for the intended use? |
| Data validation | Is input, training, or reference data suitable and controlled? |
| Bias or fairness testing | Are outcomes acceptable across relevant groups or conditions? |
| Security testing | Can the solution resist misuse, unauthorized access, or attack? |
| Integration testing | Does the AI component work with surrounding systems and processes? |
| User acceptance testing | Can users use the solution effectively in real workflows? |
| Operational readiness testing | Can support, monitoring, and incident processes handle live use? |
| Regression testing | Did a change create new failures or degraded behavior? |
| Pilot evidence | Does limited real-world use support wider deployment? |
Acceptance criteria prompts
- Are criteria linked to the business problem?
- Are criteria measurable rather than vague?
- Do they include risk, quality, ethics, and operational readiness where relevant?
- Do they define unacceptable outcomes?
- Do they include stakeholder or user acceptance where appropriate?
- Do they cover monitoring needs after release?
- Are decision-makers clear about what evidence is sufficient?
Agile, predictive, and hybrid governance
The AIPGF Foundation exam may test whether you understand tailoring. Governance should fit the delivery approach, but risk-based accountability remains.
| Delivery context | Governance emphasis | Watch for |
|---|---|---|
| Predictive project | Up-front definition, staged approvals, formal plans and baselines | Assuming early approval removes later validation needs. |
| Agile delivery | Iterative value, backlog refinement, incremental evidence | Confusing agility with absence of controls. |
| Hybrid delivery | Formal governance with iterative technical discovery | Losing traceability between experiments and formal decisions. |
| Proof of concept | Feasibility learning under controlled scope | Treating proof-of-concept success as production approval. |
| Pilot | Limited operational exposure with defined evaluation | Expanding pilot use without reassessing risk. |
| Continuous model improvement | Frequent updates, monitoring, change thresholds | Allowing model changes without impact assessment. |
Common weak areas and traps
| Trap | Why it is wrong | Better exam mindset |
|---|---|---|
| “AI accuracy is the only success measure.” | Accuracy may hide fairness, reliability, usability, or operational risks. | Look for value, risk, ethics, and operational fitness. |
| “The supplier owns the risk.” | Accountability often remains with the organization using the AI. | Check retained governance, contracts, assurance, and monitoring. |
| “A proof of concept proves production readiness.” | A PoC may not reflect live data, scale, users, or controls. | Require deployment and operational evidence. |
| “Agile means no formal approval.” | Agile still needs risk-based governance and decision rights. | Tailor controls without eliminating accountability. |
| “Compliance approval equals ethical approval.” | Legal compliance may not cover fairness, trust, or stakeholder harm. | Consider responsible AI factors separately. |
| “The project ends at go-live.” | AI performance can drift and incidents can emerge in operation. | Include monitoring, support, and benefits realization. |
| “Average model performance is sufficient.” | Some groups or cases may experience poor outcomes. | Check subgroup performance and impact. |
| “Technical team can accept all risks.” | Some risks exceed project authority or require business ownership. | Assign owners and escalate material exposure. |
| “Documentation is bureaucracy.” | Records enable auditability, accountability, and future change control. | Keep evidence proportionate but sufficient. |
| “Human oversight is automatically meaningful.” | A human reviewer may lack time, skill, information, or authority. | Check whether oversight can actually change outcomes. |
Foundation-level recall and application prompts
Use these prompts for active recall.
Explain in one or two sentences
- Why AI project governance is needed.
- How AI governance differs from generic project governance.
- Why data quality is a governance concern.
- Why human accountability remains important for AI-enabled decisions.
- Why monitoring is needed after AI deployment.
- Why bias risk can exist even when a model is technically accurate.
- Why supplier-provided AI still needs customer-side governance.
- Why tailoring is different from skipping controls.
- Why documentation supports trust and accountability.
- Why stakeholder engagement matters for responsible AI delivery.
Choose the best action
Practice deciding whether the best answer is to:
- Clarify the business problem.
- Request more evidence.
- Conduct an impact or risk assessment.
- Involve a specialist role.
- Update an artifact.
- Escalate to governance authority.
- Add a control.
- Delay deployment.
- Approve a limited pilot.
- Reject or stop an initiative.
- Monitor after release.
- Reassess benefits or assumptions.
Final-week review checklist
Five to seven days before the exam
- Review the official APMG International AIPGF Foundation terminology and definitions.
- Build a one-page map of the framework concepts, roles, decision points, and key artifacts.
- Revisit weak areas: data governance, ethics, risk, assurance, and post-deployment monitoring.
- Practice explaining each major concept without looking at notes.
- Work through scenario questions slowly and identify the governance trigger before choosing an answer.
- Create a list of “best next action” patterns: clarify, assess, evidence, escalate, approve, monitor.
- Review differences between agile, predictive, and hybrid governance.
Two to four days before the exam
- Re-check common traps and why the tempting answer is wrong.
- Practice artifact-selection questions: what gets updated, reviewed, or approved?
- Practice role questions: who owns, who advises, who approves, who is affected?
- Review AI-specific risks: data, bias, explainability, drift, automation, security, supplier opacity.
- Review deployment readiness: testing, training, monitoring, incident response, support, rollback.
- Summarize each topic area into short exam-ready phrases.
Final 24 hours
- Do a light review of terminology, not a full re-study.
- Revisit your missed-question notes and classify mistakes by topic.
- Review escalation triggers.
- Review evidence needed for governance decisions.
- Review the difference between PoC, pilot, and production readiness.
- Sleep, hydrate, and avoid cramming unfamiliar material at the last minute.
Quick self-assessment table
Score each area from 1 to 3:
1 = I need review 2 = I understand but need practice 3 = I can apply it in scenarios
| Area | Score |
|---|---|
| AIPGF Foundation terminology and framework concepts | |
| AI governance purpose and accountability | |
| Roles, responsibilities, and decision rights | |
| Business case, value, and benefits | |
| AI use-case risk and impact assessment | |
| Data governance | |
| Model development, acquisition, and validation | |
| Ethics and responsible AI | |
| Legal, compliance, privacy, and security considerations | |
| Stakeholder engagement and change impact | |
| Delivery approach and tailoring | |
| Testing, assurance, and acceptance | |
| Deployment readiness | |
| Operational monitoring and model drift | |
| Documentation, audit trail, and decision records | |
| Scenario judgment and best-next-action questions |
If any area is a 1, review it before doing more timed practice. If most areas are 2, focus on scenario questions. If most areas are 3, use final review to reduce careless mistakes and terminology gaps.
Practical next step
Choose one weak topic from the checklist, review the related AIPGF Foundation study material, then answer a small set of practice questions focused only on that topic. After each question, write down the governance trigger, the best action, and the artifact or role involved. This turns the checklist into exam-ready decision practice.