Exam Orientation
This independent Quick Reference supports candidates preparing for the APMG International APMG AI Project Governance Framework (AIPGF) Foundation exam, code AIPGF Foundation. Use it to revise how AI projects should be governed, not just how AI models are built.
Foundation-level questions usually reward the answer that:
- Protects business value, accountability, and stakeholder trust.
- Uses evidence, risk assessment, and governance controls before action.
- Recognizes that AI outputs are probabilistic and data-dependent.
- Escalates significant ethical, legal, security, safety, or reputational concerns.
- Maintains human accountability even when AI supports decisions.
Core AIPGF Exam Lens
| Concept | What to remember for the exam | Common trap |
|---|
| AI project governance | Direction, oversight, decision rights, assurance, and control for AI-enabled initiatives | Treating governance as only documentation or approval bureaucracy |
| AI project management | Day-to-day planning, delivery, coordination, issue management, and reporting | Confusing project manager authority with governance board accountability |
| Responsible AI | Practices that address fairness, transparency, accountability, safety, privacy, and human impact | Assuming a technically accurate model is automatically responsible |
| Assurance | Independent or objective confidence that controls, evidence, and decisions are adequate | Leaving assurance until the end of the project |
| Human oversight | Defined human review, intervention, appeal, and accountability mechanisms | Saying “the AI decided” as if accountability moved to the system |
| Data governance | Ownership, quality, provenance, access, retention, and permitted use of data | Starting model development with unclear data rights or quality |
| Model governance | Control of model design, validation, approval, deployment, monitoring, change, and retirement | Treating the model as a one-time deliverable |
| Benefits governance | Ensuring AI use remains aligned to expected value and measurable outcomes | Optimizing technical metrics while business benefits disappear |
AI Projects vs Conventional IT Projects
| Area | Conventional project emphasis | AI project governance emphasis |
|---|
| Requirements | Often definable upfront | May evolve through experimentation and data discovery |
| Outputs | Usually deterministic if coded correctly | Probabilistic, confidence-based, and error-prone |
| Main dependency | Software design and build | Data suitability, model behavior, context, and monitoring |
| Testing | Functional and non-functional testing | Also bias, drift, explainability, robustness, safety, and misuse testing |
| Change | Requirements, scope, design, configuration | Also data changes, model retraining, thresholds, prompts, features, and operating context |
| Acceptance | Meets specified requirements | Meets business, risk, ethical, performance, and oversight criteria |
| Operation | Stable once deployed, subject to support | Needs ongoing monitoring for drift, degradation, and unintended consequences |
| Accountability | Usually clear through system ownership | Must remain explicit despite automated or AI-assisted decisions |
Governance Lifecycle Reference
Use this lifecycle map to reason through AIPGF Foundation scenarios. The exam is likely to ask what should happen next, which artifact is most relevant, or which governance control is missing.
flowchart LR
A[Idea or AI opportunity] --> B[Initial governance screening]
B --> C[Business case and risk profile]
C --> D[Data readiness and feasibility]
D --> E[Design and build]
E --> F[Validation and assurance]
F --> G[Approval to deploy]
G --> H[Operate and monitor]
H --> I[Change, retrain, or retire]
H --> C
| Lifecycle point | Governance question | Key evidence | Typical decision |
|---|
| Idea / opportunity | Is AI appropriate for the problem? | Problem statement, expected value, alternatives, affected stakeholders | Proceed to assessment, refine, or reject |
| Initial screening | Is this use high impact, sensitive, or risky? | Risk triage, stakeholder impact, data sensitivity, regulatory context | Set governance level and escalation route |
| Business case | Is the value worth the risk and cost? | Benefits case, costs, assumptions, risk appetite, success measures | Approve discovery or request more evidence |
| Data readiness | Is data lawful, relevant, representative, and usable? | Data provenance, quality assessment, access controls, permitted use | Approve data use, remediate, or stop |
| Feasibility | Can AI meet the required performance and control needs? | Prototype results, constraints, explainability needs, operating context | Continue, change approach, or abandon AI option |
| Design / build | Are controls built into the solution? | Architecture, model approach, human oversight, security, logging | Continue with controlled development |
| Validation | Does the solution meet acceptance and risk criteria? | Test results, bias checks, validation report, assurance findings | Approve, remediate, or reject |
| Deployment approval | Is operational ownership ready? | Runbook, monitoring plan, rollback plan, training, support model | Go live, defer, or pilot only |
| Operation | Is the AI still safe, useful, and controlled? | Monitoring results, incidents, drift indicators, benefit tracking | Continue, adjust, retrain, suspend |
| Retirement | Should the AI be decommissioned? | Obsolescence, unacceptable risk, replaced process, benefits review | Retire, archive evidence, update controls |
Governance Roles and Accountability
Role names can vary by organization. For exam scenarios, focus on accountability, decision rights, and independence.
| Role / body | Primary governance responsibility | Should not be confused with |
|---|
| Sponsor | Owns the business justification, funding, and senior commitment | The technical model owner |
| Governance board / steering group | Makes or endorses major decisions, monitors risk and value, resolves escalations | The delivery team doing the work |
| Project manager | Plans and controls delivery, coordinates stakeholders, manages issues and risks | Final owner of all AI ethical or business risk |
| Business owner / product owner | Defines business need, value, acceptance criteria, and operational fit | Data scientist optimizing only model performance |
| Data owner | Authorizes data use, ensures data responsibilities are clear | Data engineer who only prepares pipelines |
| Data steward | Manages data quality, definitions, lineage, and stewardship activities | Sponsor or project manager |
| AI / ML lead | Leads model approach, experimentation, performance evaluation, technical feasibility | Independent assurance function |
| Responsible AI / ethics lead | Advises on fairness, transparency, accountability, and human impact | A substitute for sponsor accountability |
| Risk / compliance / legal specialists | Advise on obligations, risk exposure, controls, and escalation | Delivery resources who accept project risk alone |
| Security / privacy specialists | Assess confidentiality, access, threat, privacy, and misuse controls | General IT support |
| Assurance / audit reviewer | Provides objective review of governance evidence and controls | The team marking its own work without independence |
| Model owner in operation | Owns model performance, monitoring, change, and retirement after go-live | Original project team after closure |
| End users / SMEs | Validate operational practicality, user impact, and decision workflow | Passive recipients of the solution |
Accountability Rules to Remember
| Scenario | Best governance interpretation |
|---|
| AI recommends a decision but a human approves it | The human and organization remain accountable; oversight must be meaningful |
| Vendor supplies the AI model | The adopting organization still needs governance, assurance, and risk ownership |
| Model is highly accurate in testing | Approval still needs business, ethical, operational, and monitoring evidence |
| Data is available but provenance is unclear | Do not assume it can be used; investigate ownership, permission, quality, and risk |
| Project team wants to bypass review to meet deadline | Governance should protect value and trust; escalate material risk |
Key Artifacts and When to Use Them
| Artifact | Purpose | High-yield exam cue |
|---|
| AI opportunity statement | Defines the problem, expected outcome, and why AI may help | “What problem are we solving?” |
| Business case | Justifies investment, benefits, options, risk, and affordability | “Should this initiative proceed?” |
| Governance plan | Defines decision points, roles, escalation, assurance, and reporting | “Who approves and controls what?” |
| Stakeholder map | Identifies affected groups, influence, concerns, and engagement needs | “Users or impacted parties were not consulted” |
| Risk register | Records AI, project, operational, ethical, security, and compliance risks | “A risk has been identified and needs ownership” |
| Data management plan | Defines data sources, quality, ownership, access, retention, and controls | “Data is central to feasibility” |
| Data quality assessment | Assesses completeness, accuracy, representativeness, timeliness, and bias | “Model results may reflect poor data” |
| Data provenance / lineage record | Shows origin, transformations, and permitted use | “Where did this data come from?” |
| Model design record | Captures selected approach, assumptions, features, constraints, and rationale | “Why was this model approach chosen?” |
| Model card or equivalent summary | Summarizes intended use, limitations, performance, risks, and monitoring | “Users need to understand model limits” |
| Validation report | Shows testing against acceptance, risk, and performance criteria | “Can this be approved?” |
| Bias / fairness assessment | Examines disparate impact or unfair outcomes for affected groups | “Some groups may be disadvantaged” |
| Explainability assessment | Determines whether outputs can be understood sufficiently for the use case | “Decision makers need reasons, not just scores” |
| Human oversight plan | Defines review, intervention, appeal, and override mechanisms | “Humans need to remain in control” |
| Security assessment | Identifies threats, vulnerabilities, access controls, and misuse scenarios | “Could the model or data be attacked?” |
| Deployment plan | Defines release approach, readiness, training, support, and communication | “Move from project to operation” |
| Rollback / contingency plan | Defines how to suspend or revert if unacceptable behavior occurs | “What if the model causes harm?” |
| Monitoring plan | Defines metrics, thresholds, drift checks, incidents, and review cadence | “How do we know it remains fit?” |
| Change control record | Controls changes to model, data, prompts, thresholds, integrations, or use | “Something material is changing” |
| Benefits realization plan | Tracks expected value after delivery | “Did the AI produce the intended benefit?” |
| Lessons learned | Captures governance, technical, and stakeholder learning | “Improve future AI projects” |
AI Risk and Control Matrix
| Risk area | Example risk | Governance controls |
|---|
| Strategic misalignment | AI is used because it is fashionable, not because it solves a business problem | Clear problem statement, options analysis, business case challenge |
| Value uncertainty | Benefits cannot be measured or are based on unrealistic assumptions | Benefits map, measurable outcomes, staged funding, review gates |
| Data quality | Incomplete, inaccurate, stale, or inconsistent data weakens outputs | Data profiling, cleansing plan, data owner sign-off |
| Data representativeness | Training data does not reflect the population or operating context | Sampling review, bias analysis, SME validation |
| Data provenance | Unknown source, unclear permission, or untrusted lineage | Provenance records, permitted-use checks, access approvals |
| Privacy / confidentiality | Sensitive data is exposed or used beyond approved purpose | Privacy review where applicable, minimization, masking, access control |
| Bias / unfairness | Outcomes disadvantage individuals or groups | Fairness assessment, diverse validation, human review, appeal process |
| Lack of explainability | Users cannot understand or challenge AI-supported decisions | Explainability requirements, model summaries, reason codes, user guidance |
| Automation bias | Users over-trust AI output | Training, confidence indicators, human challenge process |
| Model drift | Performance degrades as data or environment changes | Monitoring thresholds, drift detection, retraining criteria |
| Concept drift | The meaning of the prediction target changes over time | Periodic business review, SME review, recalibration |
| Security threat | Model, data, prompts, or APIs are attacked or misused | Threat assessment, access control, logging, adversarial testing |
| Generative AI hallucination | AI produces plausible but false content | Source verification, human review, restricted use cases, output warnings |
| Inappropriate autonomy | AI takes action without sufficient human control | Decision authority matrix, manual approval, kill switch |
| Vendor dependency | Third-party AI limits transparency, portability, or assurance | Supplier due diligence, contractual controls, exit plan |
| Operational readiness | Support team cannot maintain or monitor the AI service | Runbooks, ownership transfer, training, support model |
| Reputational harm | AI decision causes loss of trust | Stakeholder engagement, communications plan, escalation protocol |
| Uncontrolled change | Model is retrained or tuned without approval | Model change control, versioning, audit trail |
| Decommissioning gap | Retired AI leaves unmanaged data, access, or decisions | Retirement plan, archive evidence, revoke access, update processes |
Decision Tables: What Should Happen Next?
Project Start and Feasibility
| Situation in a question | Best next action | Why |
|---|
| Business wants AI but problem is vague | Clarify problem, outcomes, and alternatives | Governance starts with purpose, not technology |
| AI is proposed for a sensitive decision | Perform impact and risk assessment; set stronger governance | Higher impact needs stronger oversight |
| Data availability is unknown | Assess data sources, ownership, quality, and permitted use | AI feasibility depends on data |
| Prototype looks promising but uses unapproved data | Pause or constrain use until data approval is resolved | Good results do not override governance |
| Benefits are unclear | Strengthen business case and measurable benefits | Project should not proceed on novelty alone |
| Stakeholders may be harmed by errors | Define oversight, appeal, safeguards, and acceptance thresholds | Harm potential changes governance requirements |
Delivery and Validation
| Situation in a question | Best next action | Why |
|---|
| Accuracy is below acceptance threshold | Investigate data, model, features, and criteria before deployment | Do not approve unfit performance |
| Accuracy is high but bias concerns exist | Perform fairness and impact assessment | Overall performance may hide group-level harm |
| Team wants to skip validation to meet deadline | Escalate risk; maintain validation gate | Governance protects value and accountability |
| Model is hard to explain but affects important decisions | Assess explainability needs and add human oversight or change approach | Explainability requirement depends on use and impact |
| Scope changes to a new user group | Reassess data representativeness, risks, and acceptance criteria | New context can change model behavior |
| Supplier claims model is proprietary and cannot be reviewed | Seek sufficient assurance through documentation, testing, contracts, or alternatives | Vendor secrecy does not remove governance duty |
Deployment and Operation
| Situation in a question | Best next action | Why |
|---|
| Operational owner is not identified | Do not complete handover until ownership is assigned | AI needs post-project accountability |
| No monitoring thresholds are defined | Create monitoring and escalation criteria before go-live | Drift and degradation must be detectable |
| Model behavior changes after deployment | Treat as incident or change; investigate drift and impact | Operational AI must be controlled |
| Users rely blindly on recommendations | Improve training, user interface cues, and oversight process | Reduces automation bias |
| New data source is added | Reassess data governance, quality, bias, and security | Data change can change outcomes |
| Model is no longer delivering benefits | Review business case; adjust, retrain, replace, or retire | Governance includes continued value |
Governance Gates and Approval Evidence
| Gate | Approve when evidence shows | Do not approve when |
|---|
| Proceed to discovery | Problem, sponsor, expected value, and initial risk are understood | AI is a solution looking for a problem |
| Proceed to data use | Data ownership, access, quality, provenance, and permitted use are acceptable | Data rights or quality are unclear |
| Proceed to build | Feasibility, approach, roles, controls, and success criteria are defined | Team lacks acceptance criteria or risk controls |
| Proceed to validation | Model and solution are ready for structured testing | Testing is informal or undocumented |
| Proceed to deploy | Validation, assurance, monitoring, support, training, and rollback are ready | No operational owner or monitoring plan exists |
| Continue in operation | Benefits, performance, risk, and controls remain acceptable | Drift, incidents, or harm exceed thresholds |
| Retire | Replacement, decommissioning, data handling, and records are controlled | System is simply abandoned |
Tailoring Governance Effort
AIPGF-style exam scenarios often test proportionality: governance should be sufficient for risk, not identical for every project.
| Factor increasing governance intensity | Why it matters |
|---|
| High impact on individuals, safety, finance, employment, health, access, or rights | Errors may cause serious harm |
| Sensitive or personal data | Higher privacy, confidentiality, and trust implications |
| Automated decisions with limited human review | Accountability and appeal risks increase |
| Low explainability in a high-impact context | Harder to challenge or justify outcomes |
| External users or public exposure | Reputational and stakeholder trust risk increases |
| Novel data, new model type, or new operating context | Uncertainty is higher |
| Third-party or opaque AI components | Assurance may be harder |
| Frequent model updates or retraining | Stronger change control is needed |
| Regulatory, contractual, or audit scrutiny | Evidence and traceability become more important |
| Lower-risk AI use may allow | Higher-risk AI use usually needs |
|---|
| Lightweight documentation | Formal governance plan and approvals |
| Limited pilot | Structured impact assessment |
| Basic monitoring | Defined thresholds, incident routes, and assurance |
| Informal stakeholder review | Formal stakeholder engagement and communication |
| Standard project change control | Model, data, prompt, threshold, and use-case change control |
Agile, Predictive, and Hybrid Delivery
| Delivery approach | When useful for AI projects | Governance caution |
|---|
| Agile / iterative | Data exploration, prototyping, model improvement, user feedback | Iteration does not remove approval gates or risk controls |
| Predictive | Fixed compliance, procurement, infrastructure, deployment, or assurance milestones | Overly rigid planning may ignore discovery uncertainty |
| Hybrid | Most AI projects: iterative technical work inside controlled governance stages | Governance must define what can iterate and what needs approval |
Exam Distinctions
| Question wording | Better answer |
|---|
| “The team has learned the original model approach will not work” | Reassess options, update business case/risk, and seek appropriate approval |
| “The sprint produced a better model using extra data” | Check data approval, quality, provenance, and change control |
| “The sponsor wants a fixed date and fixed performance guarantee before discovery” | Explain uncertainty, use staged feasibility, and define decision gates |
| “Agile team says governance slows innovation” | Tailor governance, but keep accountability, risk, and assurance controls |
Human Oversight Reference
| Oversight level | Description | Suitable when |
|---|
| Human-in-the-loop | Human reviews before action is taken | Decisions are important, contestable, or error-sensitive |
| Human-on-the-loop | AI acts, but humans monitor and can intervene | Lower-risk automated operation with clear alerts and controls |
| Human-over-the-loop | Humans set policy, thresholds, and audits but do not review each case | Low-impact or highly controlled contexts |
| No meaningful oversight | Human cannot understand, challenge, or intervene | Usually a governance red flag in higher-impact scenarios |
Oversight Quality Checks
- The human has authority to override the AI.
- The human has enough information to challenge the output.
- Review is timely enough to prevent harm.
- Escalation and appeal routes are clear.
- User training addresses over-reliance and limitations.
- Oversight is documented and monitored.
Model Validation and Monitoring Metrics
The Foundation exam is not a data science certification, but candidates should recognize why governance decisions cannot rely on a single metric.
| Metric / evidence | What it indicates | Governance caution |
|---|
| Accuracy | Overall proportion of correct predictions | Can hide poor performance for minority or critical cases |
| Precision | How many positive predictions were correct | Important when false positives are costly |
| Recall / sensitivity | How many actual positives were found | Important when false negatives are costly |
| F1 score | Balance of precision and recall | Useful when classes are imbalanced, but still context-dependent |
| False positive rate | How often negative cases are wrongly flagged | May create unnecessary intervention or unfair burden |
| False negative rate | How often positive cases are missed | May create safety, loss, or missed-opportunity risk |
| Confusion matrix | Breakdown of correct and incorrect classifications | More informative than accuracy alone |
| Calibration | Whether confidence scores reflect actual likelihood | Important when users rely on probabilities |
| Drift indicators | Whether input data or performance changes over time | Key for post-deployment monitoring |
| User override rate | How often humans reject AI output | May indicate trust, usability, or performance issues |
| Incident reports | Harm, near misses, or unexpected behavior | Should trigger review and possible escalation |
Key formulas:
\[
\text{Precision} = \frac{TP}{TP + FP}
\]\[
\text{Recall} = \frac{TP}{TP + FN}
\]\[
\text{F1} = 2 \times \frac{\text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}}
\]
Where:
- TP = true positives.
- FP = false positives.
- FN = false negatives.
- TN = true negatives.
Use risk formulas only as decision aids. Governance decisions also require judgment, accountability, and risk appetite.
\[
\text{Risk exposure} = \text{Probability} \times \text{Impact}
\]\[
\text{Expected monetary value} = \text{Probability} \times \text{Financial impact}
\]
| Formula use | Exam interpretation |
|---|
| Higher probability and higher impact | Prioritize treatment and escalation |
| Low probability but severe harm | May still require senior attention |
| Risk above tolerance | Escalate or add controls; do not ignore |
| Residual risk remains after treatment | Must be accepted by the appropriate authority |
Change Control for AI Projects
AI change control covers more than code.
| Change type | Why it matters | Governance response |
|---|
| New training data | May alter bias, performance, or permitted use | Reassess data governance and validation |
| Model retraining | May change behavior even if code is unchanged | Version, test, approve, and document |
| Threshold adjustment | Changes false positives and false negatives | Review business impact and acceptance criteria |
| Prompt change in generative AI | May change outputs unpredictably | Test, version, and control prompt changes |
| Feature change | May introduce bias, leakage, or new dependencies | Validate and review explainability |
| New user group | Original validation may not apply | Reassess representativeness and impact |
| New business purpose | Data permission and risk profile may change | Revisit business case and governance approval |
| Vendor model update | Behavior may change outside the project team | Require notification, testing, and assurance |
| Integration change | Downstream process risk may change | Update testing, security, and support plans |
Common Exam Traps
| Trap answer | Why it is weak | Stronger exam answer |
|---|
| “Deploy because the prototype works” | Prototype evidence is not full governance evidence | Validate, assure, approve, and prepare operations |
| “Let the technical team decide ethical acceptability” | Ethics and impact need broader accountability | Involve accountable governance roles and stakeholders |
| “Accuracy is enough” | AI quality includes fairness, robustness, explainability, and context | Use risk-based acceptance criteria |
| “The vendor is responsible for governance” | The adopting organization remains accountable | Perform due diligence and retain oversight |
| “Agile means no formal controls” | Agile delivery still needs governance gates | Tailor controls to risk and lifecycle |
| “Human oversight exists because a person is nearby” | Oversight must be meaningful and empowered | Define review, override, and escalation |
| “Retraining is routine maintenance” | Retraining can materially change decisions | Use model change control |
| “No incidents means no monitoring needed” | Problems may be undetected without monitoring | Define metrics, thresholds, and review cadence |
| “Bias is only a data science issue” | Bias affects stakeholders, trust, and governance | Combine technical assessment with business and ethical review |
| “Documentation is optional if the team is expert” | Governance requires traceability and evidence | Record decisions, assumptions, tests, and approvals |
Scenario Answering Checklist
When a question asks what the project manager, sponsor, or governance body should do next, scan for these triggers.
If the scenario mentions data
Ask:
- Who owns the data?
- Is use permitted for this purpose?
- Is the data representative and good enough?
- Are sensitive fields controlled?
- Is lineage documented?
- Could data encode bias or historical unfairness?
Ask:
- Which metric matters for the business decision?
- What are the costs of false positives and false negatives?
- Are results consistent across relevant groups?
- Has the model been validated independently or objectively?
- Are thresholds and acceptance criteria agreed?
- Is there a plan to monitor degradation?
If the scenario mentions stakeholders
Ask:
- Who is affected by the AI output?
- Have users and impacted groups been consulted appropriately?
- Is there a communication and training plan?
- Can decisions be challenged or appealed?
- Are responsibilities clear after deployment?
If the scenario mentions pressure to proceed
Ask:
- What evidence is missing?
- Is the risk within tolerance?
- Who has authority to accept the residual risk?
- Is escalation required?
- Can a limited pilot reduce uncertainty safely?
If the scenario mentions operation
Ask:
- Who owns the model after project closure?
- What monitoring thresholds are defined?
- What happens when thresholds are breached?
- How are incidents, drift, retraining, and retirement handled?
- Are benefits still being realized?
Compact “Best Answer” Heuristics
| If two answers seem plausible | Prefer the answer that |
|---|
| Action vs assessment | Assesses material AI risk before irreversible action |
| Technical fix vs governance response | Adds accountability, evidence, and controls, not just model tuning |
| Speed vs assurance | Protects value, safety, and trust over schedule pressure |
| Local team decision vs escalation | Escalates when risk exceeds authority or tolerance |
| Deployment vs pilot | Uses pilot when uncertainty is high and risk can be contained |
| More data vs better data governance | Confirms data quality, rights, and representativeness first |
| Automation vs human oversight | Maintains meaningful human accountability in higher-impact contexts |
| One-time approval vs lifecycle control | Includes monitoring, change control, and retirement |
Final Revision Checklist
Before exam day, be able to explain:
- Why AI governance is needed beyond normal project governance.
- How business value, risk appetite, assurance, and accountability guide decisions.
- Which roles own sponsorship, delivery, data, model operation, assurance, and oversight.
- Which artifacts provide evidence at each governance gate.
- Why data provenance, quality, bias, and permitted use are early feasibility concerns.
- Why validation must cover performance, fairness, explainability, security, and operational readiness.
- Why deployment approval requires monitoring, support, rollback, and ownership.
- How model drift, retraining, threshold changes, and vendor updates are controlled.
- How to choose the next best action in risk, change, stakeholder, and assurance scenarios.
Practical Next Step
Use this Quick Reference as a checklist while answering scenario-based practice questions for the APMG International APMG AI Project Governance Framework (AIPGF) Foundation exam. After each question, identify the missing governance evidence, the accountable role, the relevant artifact, and the safest next decision.