APMG AI Project Governance Framework (AIPGF) Practitioner Exam Blueprint

Last revised: July 1, 2026

Practical exam blueprint for the APMG International AIPGF Practitioner exam, covering AI project governance, risk, roles, assurance, and scenario readiness.

How to use this exam blueprint

Use this checklist to prepare for the APMG International APMG AI Project Governance Framework (AIPGF) Practitioner exam, code AIPGF Practitioner. The goal is not to memorize isolated definitions. At Practitioner level, you should be able to apply AI project governance concepts to scenarios, choose appropriate actions, identify governance gaps, and decide what artifact, role, control, or escalation path is needed.

Work through each readiness area and mark it:

Status	Meaning
Ready	You can apply the topic to a scenario without relying on notes.
Review	You understand the concept but miss details, role ownership, or artifact updates.
Weak	You recognize the term but cannot confidently decide what to do in a scenario.
Not started	You need structured study before attempting scenario practice.

Use this as an independent exam blueprint alongside your APMG International AIPGF Practitioner study materials and any official guidance available to you.

Topic-area readiness map

Readiness area	What to review	Practitioner-ready means you can…	Typical evidence or artifact
AI project governance purpose	Why AI projects need explicit governance beyond standard project controls	Explain the governance problem in a scenario and connect it to accountability, risk, value, ethics, and assurance	Governance approach, terms of reference, decision log
Framework application	How the AI Project Governance Framework is applied and tailored	Select proportionate governance actions for low-risk, high-risk, experimental, operational, or regulated contexts	Tailored governance plan, lifecycle controls
Roles and accountabilities	Sponsor, project board or governance body, project manager, AI/data specialists, risk/compliance, users, suppliers, assurance roles	Identify who should decide, advise, approve, escalate, or perform a control	RACI, role descriptions, escalation path
Business case and value	Strategic fit, benefits, costs, risk exposure, assumptions, ethical acceptability	Test whether the AI initiative remains justified as evidence changes	Business case, benefits profile, value measures
AI project lifecycle	Initiation, discovery, design, build, test, deployment, monitoring, closure or transition	Place governance controls at the right stage and avoid treating delivery as a one-time technical build	Stage/gate records, delivery roadmap
Predictive, agile, and hybrid delivery	How governance is maintained across different delivery approaches	Tailor controls without either over-governing innovation or under-governing material risk	Tailoring decision, backlog controls, gate criteria
Data governance	Data provenance, quality, consent or permission, lineage, access, retention, representativeness, bias	Spot data-related governance gaps before model development or deployment	Data management plan, data quality assessment
Model and solution governance	Model selection, validation, performance criteria, explainability, versioning, human oversight	Decide what evidence is needed before approving use of an AI solution	Model documentation, validation results
Responsible and ethical AI	Fairness, transparency, accountability, safety, human impact, contestability, misuse	Balance value delivery with responsible use and stakeholder impact	Ethics review, impact assessment, decision record
Risk management	AI-specific and project risks, controls, owners, responses, residual risk	Distinguish risk, issue, assumption, dependency, and change in a scenario	Risk register, issue log, control plan
Compliance and policy alignment	Organizational policies, legal or regulatory constraints, auditability, records	Identify when specialist advice or formal review is required	Compliance review, audit trail
Stakeholder engagement	Impacted users, affected communities, sponsors, operational teams, data owners, customer groups	Choose engagement actions that reduce resistance and improve responsible adoption	Stakeholder map, communication plan
Assurance and quality	Independent review, validation, acceptance criteria, test evidence, governance checks	Recognize when confidence is insufficient and further assurance is needed	Assurance plan, test report, acceptance record
Change control	Changes to scope, data, model, risk appetite, operating model, supplier terms	Decide whether a change needs approval, impact analysis, or escalation	Change request, impact assessment
Deployment and operational monitoring	Transition to live use, performance drift, incidents, feedback, retraining, withdrawal	Explain how governance continues after deployment	Monitoring plan, incident log, service controls
Supplier and third-party AI	Vendor claims, black-box models, data sharing, service dependency, contractual controls	Challenge weak supplier assurance and identify evidence needed	Supplier assessment, contract controls
Documentation and audit trail	Recording decisions, rationale, approvals, assumptions, exceptions	Identify what should be documented and why it matters for accountability	Decision log, exception report, lessons learned

Practitioner-level “can you do this?” checklist

Governance and tailoring

Explain why an AI initiative may require stronger governance than a conventional technology project.
Identify which governance controls are proportionate to project risk, complexity, novelty, and impact.
Decide when governance should be embedded in agile ceremonies, formal stage gates, or both.
Recognize when a pilot, proof of concept, or experiment has become a governed project.
Distinguish advisory review from approval authority.
Identify when a decision should be made by the project manager, sponsor, governance board, risk/compliance function, or specialist expert.
Explain why governance is not only a start-up activity; it continues through deployment and operation.
Spot weak governance language such as “the technical team will handle it” when accountability is unclear.

Business case, benefits, and value

Connect the AI solution to a defined business problem rather than a technology objective.
Identify assumptions in the business case that depend on data quality, user adoption, model performance, or operational readiness.
Decide whether benefits remain credible after new risks, costs, delays, or stakeholder concerns emerge.
Recognize when an AI initiative should pause, pivot, scale back, or seek renewed approval.
Distinguish benefit measures from model performance measures.
Explain why a high technical score does not automatically prove business value.
Identify benefits that require organizational change, not just model deployment.

Data governance

Check whether the data source is known, authorized, relevant, and fit for purpose.
Identify gaps in data lineage, representativeness, labelling, quality, or completeness.
Recognize bias risks in training data, test data, historic decisions, proxy variables, or underrepresented groups.
Decide when data issues should be escalated before model development continues.
Explain why using “available data” is not the same as using “appropriate data.”
Identify controls for access, privacy, retention, security, and permitted use.
Recognize when additional data review is needed before deployment or scaling.

Model, solution, and assurance

Distinguish model development evidence from independent assurance evidence.
Identify whether acceptance criteria are business-based, risk-based, and operationally meaningful.
Recognize when explainability is necessary for trust, auditability, or decision challenge.
Decide when a human-in-the-loop, human-on-the-loop, or automated decision model needs extra governance.
Identify when model performance, fairness, safety, or reliability evidence is insufficient.
Explain why production monitoring is required even after successful testing.
Recognize model drift, data drift, concept drift, and operational changes as governance concerns.
Identify when retraining, rollback, suspension, or redesign may be needed.

Risk, ethics, and controls

Classify AI risks by source: data, model, process, people, supplier, compliance, security, ethics, reputation, or operations.
Distinguish inherent risk from residual risk after controls.
Match a risk response to the scenario: avoid, reduce, transfer, accept, escalate, or exploit an opportunity.
Recognize when residual risk exceeds agreed tolerance or authority.
Identify ethical concerns even when the project is technically feasible.
Decide when affected stakeholders need consultation or additional communication.
Recognize that “no explicit law prohibits it” is not the same as “governance approval is justified.”
Link controls to evidence, not vague assurances.

Stakeholders, adoption, and change

Identify stakeholders affected by the AI-enabled process, including users who may not be project sponsors.
Explain the difference between informing stakeholders and involving them in governance-relevant decisions.
Decide when resistance signals a communication issue, training need, ethical concern, or benefits risk.
Identify operational changes required for adoption: process redesign, training, support, monitoring, escalation, and accountability.
Recognize when stakeholder trust is harmed by poor transparency or unclear recourse.
Explain how user feedback should feed into governance, not only product improvement.

Supplier and third-party checks

Challenge vendor claims that are unsupported by evidence.
Identify data ownership, access, retention, security, and usage concerns in supplier arrangements.
Recognize black-box AI governance risks.
Decide when independent validation or additional contractual controls are needed.
Identify dependencies on vendor monitoring, updates, service levels, or model changes.
Explain why outsourcing development does not outsource organizational accountability.

Scenario and decision-point checks

Practitioner questions often test judgment: what should be done next, who should act, what record should be updated, and whether the governance response is proportionate.

If the scenario says…	Think about…	Better exam-ready response
The team wants to proceed because early model results are promising	Technical evidence may not cover business, ethical, operational, or risk readiness	Confirm acceptance criteria, assurance evidence, risk status, and approval path before scaling
The data source is convenient but poorly documented	Provenance, permission, quality, representativeness, lineage	Pause or condition progress until data governance evidence is sufficient
Stakeholders are concerned about fairness	Bias, transparency, consultation, impact, challenge routes	Engage affected groups, assess fairness risk, document decisions, update controls
A senior stakeholder wants a rapid deployment	Governance pressure, risk appetite, authority, assurance shortcuts	Escalate if necessary; do not bypass mandatory risk or assurance controls
A supplier says its model is proprietary and cannot be explained	Black-box risk, assurance alternatives, contractual evidence, operational accountability	Request sufficient evidence, validation, monitoring, and decision accountability
The model performs well in test but poorly after launch	Drift, environment change, monitoring thresholds, incident response	Trigger operational governance, investigate, update risk and issue logs, decide rollback or remediation
A change request adds a new data source	Privacy, bias, data quality, security, consent, model validity	Perform impact assessment before approval
Users are bypassing the AI-enabled process	Adoption risk, usability, trust, training, process fit	Investigate root cause, update change plan, reassess benefits and controls
The project is agile and iterating quickly	Governance must be embedded, not skipped	Use lightweight but explicit decision points, backlog controls, definitions of done, and review evidence
The business case assumes productivity gains	Benefits realization depends on operating model and adoption	Validate assumptions, define measures, plan transition, monitor benefits
A risk has materialized	It is now an issue, not only a risk	Update issue log, assess impact, activate response, escalate if beyond authority
A new policy constraint appears late	Compliance and governance impact	Reassess scope, risk, acceptance criteria, and approval route

AI governance issue triage workflow

Use this mental workflow when a scenario introduces a new risk, issue, data concern, stakeholder objection, or assurance gap.

    flowchart TD
	    A[New concern appears in scenario] --> B{Is it a risk, issue, change, or decision?}
	    B --> C[Risk: uncertain future event]
	    B --> D[Issue: current problem]
	    B --> E[Change: requested alteration]
	    B --> F[Decision: approval or direction needed]
	    C --> G[Assess impact, likelihood, owner, response]
	    D --> H[Assess actual impact, urgency, owner, resolution path]
	    E --> I[Assess impact on scope, value, risk, data, model, controls]
	    F --> J[Identify authority, evidence needed, options]
	    G --> K{Within tolerance and authority?}
	    H --> K
	    I --> K
	    J --> K
	    K -->|Yes| L[Act, document, monitor]
	    K -->|No| M[Escalate with evidence and recommendation]
	    L --> N[Update relevant artifact]
	    M --> N

Artifact checklist: know what to update and why

Artifact or record	Use in AI project governance	Update when…
Business case	Confirms continued justification and value	Benefits, costs, risks, assumptions, or strategic fit change
Benefits profile or benefits plan	Defines expected value and measures	Delivery approach, adoption assumptions, or operational outcomes change
Governance plan	Defines decision rights, reviews, controls, tailoring	Risk level, delivery approach, supplier model, or project complexity changes
Stakeholder map	Identifies affected and influential parties	New impacted groups, resistance, ethical concerns, or adoption barriers emerge
Communication and engagement plan	Plans stakeholder involvement and messaging	Trust, transparency, training, or consultation needs change
Risk register	Records uncertain events and responses	New AI, data, supplier, compliance, or operational risks are identified
Issue log	Tracks current problems requiring action	A risk materializes or live operation exposes a defect
Assumption log	Records unproven planning assumptions	Evidence confirms, weakens, or invalidates an assumption
Dependency log	Tracks dependencies outside direct control	Data access, supplier deliverables, policy decisions, or platform readiness shift
Decision log	Preserves rationale and accountability	Governance body approves, rejects, defers, or conditions a decision
Change request	Formalizes proposed changes	Scope, model, data source, process, acceptance criteria, or operating use changes
Data management plan	Governs data sourcing, use, quality, access, retention	Data source, usage, access, quality controls, or retention requirements change
Model or solution documentation	Describes model purpose, design, limits, performance, and controls	Model version, training data, assumptions, thresholds, or intended use changes
Validation and test report	Provides evidence of fitness for intended use	New evidence, test failure, defect, drift, or changed acceptance criteria appear
Assurance report	Provides independent or structured review evidence	Governance confidence is challenged or approval requires further evidence
Operational monitoring plan	Defines live controls and thresholds	Deployment scope, environment, user behavior, model performance, or risk changes
Incident or escalation record	Documents operational problems and responses	Harm, failure, security event, policy breach, or serious stakeholder impact occurs
Lessons learned record	Captures improvement for future governance	Closure, major phase end, incident review, or governance retrospective occurs

AI-specific risk checklist

Risk area	Questions to ask	Scenario cues
Data provenance	Do we know where the data came from and whether it may be used?	“Legacy data,” “scraped data,” “third-party dataset,” “no owner identified”
Data quality	Is the data complete, accurate, timely, relevant, and suitable for the intended use?	Missing values, inconsistent labels, stale data, untested source
Bias and fairness	Could the data or model disadvantage groups or reinforce historic patterns?	Complaints, uneven outcomes, proxy variables, underrepresented users
Privacy and confidentiality	Are personal, sensitive, or confidential data protected and used appropriately?	New data source, broader access, external supplier, live customer data
Security	Could the AI system, data pipeline, model, or outputs be attacked or misused?	External access, prompt misuse, data leakage, weak controls
Explainability	Can decisions or recommendations be understood at the level needed?	High-impact decisions, user challenge, audit requirement, black-box model
Human oversight	Is human review meaningful, timely, trained, and accountable?	“Human approves automatically,” “no appeal route,” “too many alerts”
Reliability	Does the model perform consistently in relevant conditions?	Test-only success, new environment, edge cases, unstable outputs
Drift	Could performance degrade after deployment?	Changing customer behavior, new data patterns, operational process change
Misuse	Could the tool be used outside intended scope?	Informal workarounds, uncontrolled access, unclear user guidance
Supplier dependency	Can the organization govern vendor changes, outages, and evidence?	Proprietary model, limited transparency, vendor-managed updates
Compliance and policy	Are applicable policies and obligations understood?	New jurisdiction, new use case, sensitive decision area
Reputation and trust	Could failure damage stakeholder confidence?	Public-facing use, vulnerable groups, media sensitivity, opaque decisions
Operational readiness	Can the business support, monitor, and respond after go-live?	No runbook, no owner, no monitoring thresholds, no incident route

Roles, accountability, and escalation checks

You should know the role names and responsibilities used in your AIPGF Practitioner materials. For scenario practice, focus on what each role is expected to contribute and when escalation is justified.

Role or stakeholder type	Typical governance concern	Candidate readiness check
Project sponsor or executive owner	Continued justification, benefits, funding, business risk	Can you decide when the sponsor must reapprove or redirect the project?
Governance board or steering group	Decision authority, tolerances, escalation, assurance confidence	Can you identify decisions that exceed the project manager’s authority?
Project manager	Delivery control, coordination, risk and issue management, reporting	Can you choose the next management action and artifact update?
Product owner or business lead	Value, prioritization, user needs, acceptance	Can you balance user value against risk and control requirements?
Data owner or data steward	Data suitability, permission, quality, lineage, access	Can you spot when data ownership or approval is missing?
AI/model specialist	Technical design, model performance, limitations, validation support	Can you distinguish expert advice from governance approval?
Risk, compliance, legal, or policy adviser	Independent advice on obligations, risk exposure, controls	Can you identify when specialist input is needed before proceeding?
Assurance or audit role	Independent confidence, evidence review, governance compliance	Can you identify when assurance evidence is insufficient?
Operational owner	Live service, monitoring, incidents, support, user process	Can you decide whether deployment readiness is adequate?
Supplier or vendor	External capability, data handling, model updates, service support	Can you identify retained accountability and supplier control gaps?
End users and affected stakeholders	Adoption, trust, usability, impact, fairness	Can you identify when engagement is a governance need, not a communication afterthought?

Delivery approach and tailoring checklist

Delivery context	Governance focus	Watch for this trap
Early discovery or proof of concept	Clarify purpose, data permission, experiment boundaries, decision criteria	Treating a proof of concept as exempt from governance because it is “only a trial”
Predictive project	Formal decision points, defined scope, stage approvals, documented controls	Assuming stage approval is enough without AI-specific evidence
Agile delivery	Governance embedded in backlog, acceptance criteria, reviews, definitions of done, sprint evidence	Confusing speed with permission to skip assurance
Hybrid delivery	Formal governance for risk and value, iterative delivery for learning	Duplicating controls without clarifying which decision forum has authority
High-impact AI use	Stronger assurance, stakeholder involvement, explainability, monitoring, escalation	Approving on technical performance alone
Low-impact internal automation	Proportionate controls, clear ownership, data checks, monitoring	Either over-engineering governance or ignoring cumulative risk
Supplier-led solution	Contractual controls, evidence, auditability, data terms, operational handover	Assuming vendor certification or confidence removes project accountability
Live operational AI	Monitoring, drift response, incident management, retraining or withdrawal decisions	Treating go-live as the end of governance

Common weak areas and traps

Weak area	What often goes wrong	How to correct it in exam scenarios
Governance vs delivery	Candidates choose a delivery task when the scenario needs a governance decision	Ask: who has authority, what evidence is missing, and what record must be updated?
Risk vs issue	A current problem is treated as a future uncertainty	If it has happened, manage it as an issue and assess impact immediately
Technical performance vs business value	High accuracy is treated as enough for approval	Check benefits, acceptance criteria, stakeholder impact, controls, and operational readiness
Data availability vs data suitability	Data exists, so the team assumes it is usable	Check provenance, quality, permission, representativeness, and intended use
Ethics as a late review	Ethical concerns are considered only before go-live	Integrate ethics into initiation, design, testing, deployment, and monitoring
Human oversight	A human is nominally present but cannot meaningfully challenge the AI output	Check competence, authority, time, workflow design, and escalation route
Supplier assurance	Vendor statements are accepted without evidence	Request validation, documentation, contractual controls, and monitoring arrangements
Agile misunderstanding	Agile delivery is treated as reduced governance	Tailor governance into iterative work; do not remove accountability
Escalation extremes	Candidates escalate everything or nothing	Escalate when tolerance, authority, policy, risk appetite, or stakeholder impact requires it
Documentation gaps	Decisions are made informally	Record rationale, evidence, approvals, exceptions, and residual risk
Deployment readiness	Testing success is treated as operational readiness	Check monitoring, support, incident response, user training, ownership, and benefits tracking
Bias handling	Bias is treated as only a data science problem	Include stakeholder impact, fairness measures, governance review, and decision accountability
Acceptance criteria	Criteria focus only on model metrics	Include business, risk, ethical, operational, and user acceptance criteria
Change impact	A change to data or model is treated as a routine technical update	Reassess risk, validation, compliance, benefits, and approval needs

Scenario prompts for self-testing

Use these prompts to rehearse Practitioner-level reasoning. For each one, answer: what is the issue, who should act, what should be updated, and what is the next governance step?

Prompt	What a strong answer should consider
A project team wants to use historic approval data, but no one knows whether past decisions were biased.	Data bias risk, fairness review, data owner involvement, risk register update, possible redesign or additional controls
A sponsor asks the team to skip independent validation to meet a launch date.	Assurance need, risk tolerance, escalation, decision authority, documented exception or refusal
A supplier refuses to provide detail on model changes after deployment.	Contractual control, supplier dependency, operational monitoring, auditability, retained accountability
Users say the AI recommendation is hard to challenge.	Transparency, human oversight, appeal route, user training, process design, stakeholder trust
A model’s performance drops after a change in customer behavior.	Drift monitoring, issue management, remediation, rollback, retraining, updated operational controls
The business case promises reduced processing time, but staff are not trained on the new workflow.	Benefits risk, change management, training plan, adoption measures, operational readiness
The team adds a new external dataset during an agile iteration.	Change impact, data governance, privacy/security review, validation, backlog and risk updates
A proof of concept produces useful outputs and the business starts using them informally.	Governance boundary breach, operational risk, approval route, monitoring, user controls
A risk owner accepts residual risk without clear authority.	Risk appetite, delegated authority, escalation, decision log, governance body approval
Stakeholder feedback reveals possible harm to a vulnerable user group.	Ethical impact, stakeholder engagement, fairness assessment, escalation, possible pause or redesign

Final-week checklist

Seven to five days before the exam

Re-read your AIPGF Practitioner materials with a focus on application, not terminology alone.
Build a one-page map of roles, decision rights, artifacts, and escalation routes.
Review how AI project governance differs from general project governance.
Practice classifying scenario facts as risk, issue, assumption, dependency, change, or decision.
Create a personal list of weak topics: data governance, ethics, assurance, supplier controls, monitoring, or tailoring.

Four to two days before the exam

Work through scenario-style questions and explain why each wrong option is less suitable.
For every practice question, identify the artifact that would need updating.
Practice “what should happen next?” decision making.
Review common traps around pilots, agile delivery, black-box models, and stakeholder impact.
Rehearse concise definitions for key terms, but connect each definition to a scenario action.

Day before the exam

Review your weakest readiness areas rather than rereading everything.
Recheck role responsibilities and escalation logic.
Revisit artifacts: business case, governance plan, risk register, issue log, change request, data plan, validation evidence, monitoring plan.
Practice a few short scenario prompts and state the next governance step out loud.
Stop heavy study early enough to preserve focus for scenario judgment.

Exam-day mental checklist

Read the scenario for governance facts before choosing an answer.
Ask: is this a risk, issue, change, decision, or assurance gap?
Ask: who has authority to act or approve?
Ask: what evidence is missing?
Ask: what artifact should be updated?
Prefer proportionate governance over both uncontrolled speed and unnecessary bureaucracy.
Watch for answers that sound technically impressive but ignore accountability, risk, stakeholders, or value.

Practical next step

Choose three weak readiness areas from the tables above and practice applying them to short scenarios. For each scenario, write a four-part answer: decision needed, responsible role, artifact update, and governance rationale. That habit is a strong final-review bridge from knowing the AIPGF concepts to applying them on the APMG International APMG AI Project Governance Framework (AIPGF) Practitioner exam.

Study Plan

Scenario Guide