APMG AI Project Governance Framework (AIPGF) Foundation Cheat Sheet
Cheat sheet: AIPGF Foundation reference for AI project governance lifecycle, roles, artifacts, risks, controls, and scenario decisions.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context
The Foundation-level focus is usually not “how to build the most advanced AI model.” It is closer to:
- How AI projects should be governed from idea to operation.
- How risk, ethics, data, assurance, accountability, and benefits fit together.
- How AI project governance differs from ordinary technology project control.
- Which decision points require evidence, escalation, or independent review.
- How to avoid confusing technical model activity with organizational governance.
This page is PM Mastery practice support and is not affiliated with APMG International.
Exam Orientation
This independent Cheat Sheet 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
Notes and examples
| 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 |
AI project governance lifecycle
Use the lifecycle view to answer many scenario questions. Ask: Where are we in the project, what decision is being made, what evidence is needed, and who should be accountable?
flowchart LR
A[Idea and opportunity] --> B[Business case and risk screening]
B --> C[Data and feasibility assessment]
C --> D[Design, build, or procure]
D --> E[Validation and assurance]
E --> F[Deployment decision]
F --> G[Operational monitoring]
G --> H[Change, incident, or retirement decision]
Lifecycle review table
| Stage | Governance focus | Evidence to look for | Candidate trap |
|---|---|---|---|
| Idea and opportunity | Define problem, users, intended outcomes, and why AI is appropriate. | Problem statement, expected benefits, stakeholder impact, initial risk view. | Choosing AI before confirming the business problem. |
| Business case | Compare value, cost, risk, feasibility, and alternatives. | Benefits case, cost estimates, risk register, governance approach. | Ignoring non-AI alternatives that may be simpler or safer. |
| Risk screening | Identify potential harm, legal exposure, operational impact, and ethical concerns. | AI risk assessment, impact assessment, escalation criteria. | Treating risk screening as a one-time checklist. |
| Data assessment | Confirm data quality, access rights, lineage, bias risk, and representativeness. | Data inventory, data quality checks, source approvals, privacy/security review. | Assuming large data volume means good data. |
| Design or procurement | Choose solution approach, controls, acceptance criteria, and supplier responsibilities. | Design records, model approach, supplier due diligence, control design. | Buying a vendor tool without clarifying accountability. |
| Development/configuration | Build or configure under controlled methods and traceable decisions. | Development logs, experiment records, version control, design decisions. | Allowing uncontrolled model or prompt changes. |
| Testing and validation | Test performance, robustness, bias, security, explainability, and user impact. | Test results, validation reports, acceptance evidence. | Treating accuracy as the only acceptance criterion. |
| Deployment approval | Decide whether the AI system is ready for controlled release. | Go-live recommendation, residual risk acceptance, monitoring plan, support model. | Deploying a pilot as if it were production-ready. |
| Operation | Monitor outcomes, drift, incidents, usage, user feedback, and benefits. | Monitoring dashboard, incident log, benefits review, change records. | Assuming model behavior remains stable after go-live. |
| Change or retirement | Control changes, retraining, decommissioning, and replacement. | Change approvals, retraining evidence, retirement plan, audit trail. | Updating models without revalidating impact. |
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 |
Notes and examples
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 |
Notes and examples
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 |
Notes and examples
| 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.
Notes and examples
Human oversight and automation
Human oversight is valuable only if it is designed realistically.
| Oversight pattern | Description | Governance concern |
|---|---|---|
| Human-in-the-loop | Human approves or rejects AI output before action. | Human must have time, skill, authority, and meaningful information. |
| Human-on-the-loop | Human monitors AI operation and intervenes when needed. | Monitoring thresholds and escalation routes must be clear. |
| Human-out-of-the-loop | AI acts without routine human intervention. | Requires stronger assurance, monitoring, and risk acceptance. |
| Human-over-the-loop | Humans set policy and review system-level performance. | Must not be used to hide lack of operational control. |
Automation bias trap
A human reviewer is not an effective control if they:
- Always accept AI recommendations.
- Do not understand limitations.
- Lack authority to override outputs.
- Face time pressure that makes review superficial.
- Cannot see the evidence needed to challenge the AI.
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 |
Notes and examples
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.
Risk Prioritization Formulas
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 |
Notes and examples
Controls across the AI project
Controls should be proportionate to risk. Low-risk internal productivity tools may not need the same assurance as high-impact automated decisions, but both still need governance.
| Control type | Examples | Best use |
|---|---|---|
| Preventive controls | Approval gates, access limits, design standards, prohibited-use rules. | Stop unsuitable AI use before harm occurs. |
| Detective controls | Monitoring, audit logs, bias checks, anomaly detection, user feedback. | Identify problems during testing or operation. |
| Corrective controls | Incident response, rollback, retraining, user notification, remediation. | Restore control after failure or harm. |
| Directive controls | Policies, standards, training, playbooks, decision rules. | Guide consistent behavior across teams. |
| Assurance controls | Independent review, evidence checks, supplier audits, validation sign-off. | Confirm governance is working. |
Change control for AI systems
AI change is broader than software change.
| Change type | Why it matters |
|---|---|
| New training data | Can change model behavior and bias profile. |
| Model retraining | May improve performance but can introduce new errors. |
| Prompt changes | Can materially change generative AI behavior. |
| Feature changes | May affect fairness, explainability, and performance. |
| Threshold changes | Can alter false positive/false negative balance. |
| Supplier model update | May change outputs without internal development activity. |
| Business process change | Can change how AI outputs affect people. |
| User group expansion | May expose the model to populations it was not validated for. |
Common mistake: treating AI retraining as routine maintenance. It may require renewed testing, approval, and communication.
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?
Notes and examples
If the scenario mentions model performance
- 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
- 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
- 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
- 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.
Core exam mindset
For the APMG AI Project Governance Framework (AIPGF) Foundation, keep this mental model in mind:
AI project governance is the decision and control system that ensures an AI initiative remains valuable, lawful, ethical, safe, explainable, accountable, and operationally sustainable.
A strong answer usually connects business purpose, risk, data, model behavior, human oversight, evidence, and accountability.
A weak answer often focuses only on model accuracy, technical delivery, or speed of implementation.
High-yield governance themes
| Theme | What to remember | Common exam trap |
|---|---|---|
| Business justification | AI must solve a real business problem and deliver measurable value. | Treating AI adoption as valuable simply because it uses AI. |
| Accountability | Named people or governance bodies must own decisions, risks, and outcomes. | Assuming the data science team is accountable for all consequences. |
| Data governance | Data quality, provenance, consent, representativeness, and security matter before model work starts. | Starting model development before checking whether data is usable or appropriate. |
| Risk-based control | Higher-impact AI requires stronger controls, assurance, and oversight. | Applying the same governance depth to every AI use case. |
| Responsible AI | Fairness, transparency, explainability, privacy, safety, and human oversight are governance concerns. | Treating ethics as a communication issue rather than a design and control issue. |
| Lifecycle governance | Governance continues after deployment through monitoring, incident handling, change control, and retirement. | Thinking governance ends at go-live. |
| Assurance | Evidence should support decisions at key gates. Independent review may be needed for higher-risk uses. | Relying only on developer claims or vendor statements. |
| Benefits realization | The project should track whether expected benefits actually occur. | Measuring only technical performance, not business outcomes. |
What makes AI project governance different?
AI projects share many features with ordinary technology projects, but several issues create extra governance pressure.
| Area | Traditional project concern | AI-specific governance concern |
|---|---|---|
| Requirements | Are requirements complete and approved? | Are intended and prohibited uses clear enough to control model behavior? |
| Data | Is data available? | Is data appropriate, lawful, representative, secure, and fit for model use? |
| Testing | Does the system meet requirements? | Does the model behave acceptably across cases, groups, edge conditions, and changing data? |
| Change control | Are system changes approved? | Are model retraining, parameter changes, prompt changes, and data changes governed? |
| Accountability | Who owns the system? | Who owns decisions made or supported by the AI system? |
| Transparency | Is documentation sufficient? | Can affected stakeholders understand, challenge, or trust outputs where needed? |
| Operations | Is the service stable? | Is model performance, drift, misuse, and unintended impact monitored? |
| Supplier management | Does the vendor deliver to contract? | Can vendor model behavior, data usage, explainability, and updates be governed? |
Key governance decision points
Foundation questions often test whether you know the right decision at the right time.
1. Should this be an AI project?
Good governance asks whether AI is justified, not just whether AI is possible.
Use AI when:
- The business problem is well understood.
- The expected value justifies cost and risk.
- Suitable data or model capabilities are available.
- The organization can govern, monitor, and support the solution.
- Human roles, escalation paths, and accountability can be defined.
Notes and examples
Be cautious when:
- The problem is vague.
- Stakeholders want AI mainly for innovation optics.
- Data rights or quality are unclear.
- Potential harm is high and controls are immature.
- The organization cannot explain, monitor, or challenge outputs.
2. Build, buy, or adapt?
| Option | Governance advantage | Governance concern |
|---|---|---|
| Build internally | More control over design, data, documentation, and validation. | Requires capability, cost, and disciplined lifecycle controls. |
| Buy from supplier | Faster access to capability and specialist expertise. | Supplier opacity, contractual gaps, update control, and accountability risk. |
| Adapt/configure existing tool | Can reduce time and cost. | Hidden assumptions, inherited bias, prompt/configuration drift, unclear limitations. |
A common exam trap is assuming that buying a solution transfers risk to the supplier. It usually does not. The organization using the AI system still needs governance over purpose, deployment, monitoring, and impact.
3. Pilot or production?
A pilot should explore feasibility and risk. Production requires operational controls.
| Pilot evidence | Production evidence |
|---|---|
| Feasibility results | Validated acceptance criteria |
| Limited-user feedback | Support and incident process |
| Early risk assessment | Residual risk approval |
| Data suitability check | Monitoring and drift plan |
| Prototype documentation | Change control and audit trail |
| Initial benefits hypothesis | Benefits measurement approach |
Do not treat a proof of concept as production-ready just because it produces impressive outputs.
4. Approve, reject, or escalate?
Escalation is likely when:
- Potential harm to individuals or groups is significant.
- Legal, privacy, safety, or ethical questions are unresolved.
- Model behavior cannot be adequately tested or explained for the use case.
- Residual risk exceeds agreed tolerance.
- There is disagreement about accountability or acceptable use.
- A supplier cannot provide enough evidence for responsible operation.
Responsible AI concepts to review
Responsible AI principles are not just ideals. In project governance, they become controls, evidence, decisions, and monitoring requirements.
| Principle | Governance question | Example evidence |
|---|---|---|
| Accountability | Who is responsible for decisions, outcomes, risks, and remediation? | RACI, decision log, named risk owners, approval records. |
| Transparency | Can relevant stakeholders understand that AI is used and why? | User notices, documentation, explanation approach, stakeholder communications. |
| Explainability | Can outputs be explained to the level needed for the context? | Explanation method, model documentation, decision rationale. |
| Fairness | Are outcomes checked for inappropriate bias or unequal impact? | Bias testing, representative data review, fairness criteria. |
| Privacy | Is personal or sensitive data used appropriately and protected? | Data protection review, access controls, minimization evidence. |
| Security | Is the AI system protected against misuse, leakage, and attack? | Security review, threat assessment, access management, logging. |
| Robustness | Does the system perform reliably under expected and edge conditions? | Stress tests, robustness tests, monitoring thresholds. |
| Human oversight | Are humans involved where judgment, appeal, or intervention is required? | Human-in-the-loop design, escalation route, override process. |
| Contestability | Can affected users challenge or seek review of outcomes where appropriate? | Appeals process, support route, decision review procedure. |
| Sustainability | Are operational cost, resource use, and long-term maintainability considered? | Cost model, operational plan, retirement plan. |
Data governance quick review
Data is one of the most tested governance areas because weak data undermines model quality, legality, fairness, and trust.
Data questions to ask
| Question | Why it matters |
|---|---|
| Where did the data come from? | Establishes provenance, rights, quality, and trust. |
| Was the data collected for a compatible purpose? | Reduces privacy, consent, and misuse risk. |
| Is the data representative of the intended population or operating environment? | Reduces bias and poor real-world performance. |
| Is the data complete and accurate enough? | Prevents unreliable model behavior. |
| Are sensitive attributes present or inferable? | Supports fairness, privacy, and ethical assessment. |
| Who can access the data? | Controls confidentiality and misuse. |
| How is data updated? | Supports monitoring, retraining, and drift management. |
| What data must be retained or deleted? | Supports auditability, privacy, and lifecycle control. |
Notes and examples
Common data traps
- Assuming more data automatically means better AI.
- Ignoring data lineage because the model appears to work.
- Using historical data without considering historical bias.
- Testing only on data that resembles training data too closely.
- Failing to separate training, validation, and test data.
- Ignoring whether data use is compatible with stakeholder expectations.
- Treating synthetic or anonymized data as automatically risk-free.
- Allowing uncontrolled production data to feed model updates.
Model and AI system concepts
A Foundation candidate does not usually need to be a data scientist, but must understand enough to govern model decisions.
| Concept | Quick meaning | Governance relevance |
|---|---|---|
| Model | A learned or configured mechanism that produces outputs from inputs. | Must be documented, tested, monitored, and controlled. |
| Algorithm | A method or procedure for processing data. | Not all algorithms are AI, and algorithm choice affects risk. |
| Training data | Data used to create or tune a model. | Poor or biased training data can produce poor or biased outcomes. |
| Validation data | Data used to tune and compare model options. | Helps avoid overfitting to training data. |
| Test data | Data used to assess final performance. | Supports acceptance decisions. |
| Inference | The model producing an output from new input. | Operational controls apply at this point. |
| Drift | Change in data, relationships, or environment that affects performance. | Requires monitoring and possible retraining or withdrawal. |
| Explainability | Ability to provide understandable reasons for outputs. | Important for trust, challenge, accountability, and compliance. |
| Human-in-the-loop | Human reviews or approves AI outputs before action. | Useful control, but only effective if humans have authority and competence. |
| Human-on-the-loop | Human monitors AI operation and can intervene. | Useful for operational oversight. |
| Automation bias | Human tendency to over-trust automated outputs. | Requires training, interface design, and challenge culture. |
Testing and validation
Testing should match the risk and intended use of the AI system.
| Test area | What it checks | Weak answer pattern |
|---|---|---|
| Functional performance | Does the system produce useful outputs? | Looking only at headline accuracy. |
| Robustness | Does performance hold under variation, edge cases, or noisy inputs? | Testing only ideal examples. |
| Bias and fairness | Are outcomes inappropriate for protected or vulnerable groups? | Assuming bias is absent because sensitive fields were removed. |
| Explainability | Can decisions be explained at the needed level? | Claiming a black box is acceptable in every context. |
| Security | Can the model or system be attacked, manipulated, or leaked? | Treating AI security as ordinary application security only. |
| User acceptance | Can users understand and use the system responsibly? | Assuming users will challenge AI outputs without training. |
| Operational readiness | Can the system be supported, monitored, and changed safely? | Approving go-live based on model test results alone. |
| Benefits | Does the system improve the targeted outcome? | Confusing technical performance with business value. |
Notes and examples
Accuracy is not enough
High model accuracy may still be unacceptable if:
- Errors are concentrated in vulnerable groups.
- False positives or false negatives have serious consequences.
- Users cannot understand limitations.
- Outputs cannot be challenged.
- The model performs poorly when conditions change.
- The business process cannot absorb the AI output responsibly.
- Benefits do not justify operational risk.
AI risk categories
| Risk category | Example | Governance response |
|---|---|---|
| Strategic risk | AI project does not support organizational objectives. | Strong business case, portfolio review, benefits tracking. |
| Data risk | Data is poor quality, biased, unlawfully used, or insecure. | Data assessment, access control, lineage documentation. |
| Model risk | Model is inaccurate, unstable, biased, or hard to explain. | Validation, explainability review, model monitoring. |
| Operational risk | Users misuse outputs or processes fail. | Training, process design, escalation routes, support model. |
| Ethical risk | System causes unfair, opaque, or harmful outcomes. | Impact assessment, responsible AI controls, stakeholder review. |
| Legal/regulatory risk | Requirements are not identified or met. | Compliance review, legal input where relevant, evidence retention. |
| Security risk | Model, prompts, data, or outputs are attacked or leaked. | Threat assessment, controls, logging, incident process. |
| Supplier risk | Vendor tool is opaque or changed without control. | Due diligence, contractual controls, assurance evidence. |
| Reputational risk | Public trust is damaged by inappropriate AI use. | Communications, approval gates, monitoring, incident response. |
| Change risk | Users resist, over-trust, or bypass the system. | Change management, training, adoption measures. |
Governance roles and responsibilities
Foundation questions often test role clarity. The exact role names may vary by organization, but the governance logic is consistent.
| Role or group | Primary governance concern | Should not be confused with |
|---|---|---|
| Sponsor or senior responsible owner | Owns business justification, strategic fit, benefits, and major risk acceptance. | Day-to-day model development. |
| Project board or steering group | Makes key decisions, resolves escalations, and confirms continued viability. | Performing detailed technical validation. |
| Project manager | Coordinates delivery, plans, risks, issues, resources, and governance activities. | Owning all AI ethical or technical decisions personally. |
| Product owner or business owner | Defines business need, usage context, and operational value. | Approving technical risk without expert input. |
| Data owner | Authorizes and governs data use, quality expectations, and stewardship. | Building the model. |
| Data scientist or AI engineer | Designs, trains, configures, tests, and documents model behavior. | Owning business accountability for outcomes. |
| Risk, compliance, legal, or privacy specialists | Advise on obligations, risk controls, and evidence. | Replacing accountable business decision-makers. |
| Security specialist | Reviews threats, access, confidentiality, and resilience. | Validating business benefits. |
| Independent assurance or review function | Challenges evidence and confirms controls for higher-risk decisions. | Managing delivery. |
| Operational owner | Runs the live service, monitors performance, handles incidents and changes. | Assuming the project team remains responsible forever. |
| Users and affected stakeholders | Provide practical feedback and reveal real-world impact. | Being a substitute for formal approval. |
| Supplier or vendor | Provides contracted capability, information, and support. | Taking over the customer organization’s accountability. |
Notes and examples
Accountability rule of thumb
- Technical teams can recommend.
- Risk and compliance teams can advise and challenge.
- Suppliers can provide evidence and contractual commitments.
- Governance bodies and accountable business owners decide whether risk is acceptable.
Governance artifacts to recognize
| Artifact | Purpose |
|---|---|
| Business case | Explains why the AI initiative is worth doing. |
| Governance plan | Defines decision points, roles, controls, reporting, and assurance. |
| Stakeholder map | Identifies affected groups, decision-makers, users, and consultation needs. |
| AI risk assessment | Identifies and rates AI-specific and project risks. |
| Data assessment | Checks data source, quality, rights, representativeness, and security. |
| Impact assessment | Evaluates potential effects on people, processes, rights, fairness, or safety. |
| Model documentation | Records model purpose, assumptions, limitations, data, and performance. |
| Acceptance criteria | Defines what must be true before approval or deployment. |
| Test and validation report | Provides evidence that the system has been evaluated appropriately. |
| Decision log | Records important decisions, rationale, approvers, and conditions. |
| Risk register | Tracks risks, owners, actions, and status. |
| Monitoring plan | Defines metrics, thresholds, review frequency, and escalation routes. |
| Incident response plan | Explains how AI-related failures, misuse, or harm will be handled. |
| Change control record | Tracks changes to data, model, prompts, configuration, or operating process. |
| Benefits realization plan | Defines how expected benefits will be measured after deployment. |
| Retirement plan | Controls withdrawal, replacement, data retention, and user transition. |
Explainability and transparency
Do not treat explainability as a single technical feature. It depends on audience and use case.
| Audience | What they may need |
|---|---|
| Senior decision-makers | Risk, benefits, limitations, assurance conclusions. |
| Operators and users | How to use outputs, when to challenge, escalation triggers. |
| Affected individuals | Clear information about AI involvement and review options where relevant. |
| Technical teams | Model behavior, data, parameters, error patterns, monitoring results. |
| Assurance or audit teams | Evidence trail, control design, validation results, decision rationale. |
A simple model is not automatically better, but higher-risk decisions usually require a level of explanation that supports trust, challenge, and accountability.
Supplier and third-party AI governance
When AI capability is supplied externally, governance must cover both contract and operational reality.
Supplier questions to review
- What data will the supplier access, store, process, or learn from?
- Can the supplier explain model purpose, limitations, and update approach?
- Who approves model changes, version updates, or configuration changes?
- What evidence is available for validation, security, bias, and reliability?
- What happens if the supplier changes terms, features, or model behavior?
- How are incidents, vulnerabilities, or harmful outputs reported?
- Can the organization exit or replace the supplier safely?
- What audit, assurance, or reporting rights exist?
Supplier traps
- Believing supplier certification or reputation removes the need for local governance.
- Accepting “commercial confidentiality” as a reason for no assurance evidence at all.
- Failing to control automatic updates.
- Ignoring data reuse by the supplier.
- Not defining service levels for AI-specific failures.
- Not planning for vendor lock-in or model withdrawal.
Generative AI governance points
If a scenario involves generative AI, prompts, chatbots, summarization, or content generation, add these review points.
| Risk | Governance response |
|---|---|
| Hallucinated or fabricated output | Require verification, confidence handling, source grounding, and user training. |
| Confidential data leakage | Restrict inputs, configure data handling, educate users, log appropriately. |
| Prompt injection | Apply security testing, content controls, input/output filtering, monitoring. |
| Inappropriate content | Define prohibited outputs, safety filters, review processes. |
| Copyright or intellectual property concern | Review data sources, output use, licensing, and policy constraints. |
| Over-reliance by users | Set usage rules, disclaimers, human review, and escalation paths. |
| Uncontrolled prompt changes | Version prompts, test changes, and include them in change control. |
| Weak audit trail | Log key interactions, decisions, approvals, and evidence proportionate to risk. |
Do not answer as if generative AI is automatically unsuitable. The better governance answer is usually to classify risk, define controls, validate use, and monitor operation.
Benefits realization
AI projects can appear successful technically while failing commercially or operationally. Benefits governance keeps attention on the original purpose.
| Benefit type | Example measure |
|---|---|
| Efficiency | Reduced processing time, reduced manual effort, faster response. |
| Quality | Fewer errors, better consistency, improved decision support. |
| Customer or user experience | Faster service, improved accessibility, higher satisfaction. |
| Risk reduction | Better detection, fewer incidents, improved compliance evidence. |
| Revenue or value | Increased conversion, improved targeting, new capability. |
| Knowledge support | Better search, summarization, insight discovery. |
Benefits traps
- Counting model accuracy as a benefit by itself.
- Measuring savings before considering support and assurance costs.
- Ignoring user adoption.
- Ignoring negative side effects, such as increased appeals or manual review.
- Failing to define a baseline before deployment.
- Continuing a project after benefits no longer justify risk.
Monitoring after deployment
AI systems need ongoing observation because data, behavior, users, and operating environments change.
| Monitoring area | What to watch |
|---|---|
| Model performance | Accuracy, precision/recall where relevant, error rates, confidence patterns. |
| Data drift | Changes in input data distribution or quality. |
| Concept drift | Changes in the relationship between inputs and expected outputs. |
| Fairness | Different outcomes across groups or use contexts. |
| User behavior | Over-reliance, workarounds, misuse, unexpected usage patterns. |
| Incidents | Harmful outputs, failures, security events, complaints. |
| Business outcomes | Whether expected benefits are being realized. |
| Supplier changes | Model updates, feature changes, service changes. |
| Cost and capacity | Usage cost, latency, resource demands, support burden. |
Monitoring decision rule
Monitoring should define:
- What is measured.
- Who reviews it.
- How often it is reviewed.
- What threshold triggers action.
- What action is taken.
- Who has authority to pause, rollback, retrain, or retire the system.
Auditability and evidence
Governance requires an evidence trail. If a question asks what should support an approval decision, choose the answer that includes documented evidence rather than informal confidence.
High-value evidence includes:
- Approved business case.
- Risk assessment and risk acceptance.
- Data source and quality evidence.
- Model or system documentation.
- Validation and test results.
- Responsible AI assessment.
- Stakeholder consultation where appropriate.
- Supplier due diligence.
- Security and privacy review.
- Monitoring and incident plan.
- Decision log with rationale.
Weak evidence includes:
- “The model performed well in a demo.”
- “The supplier says it is compliant.”
- “The project team is confident.”
- “Users liked the prototype.”
- “The technology is widely used elsewhere.”
Common exam traps and how to avoid them
| Trap | Better exam approach |
|---|---|
| Equating AI governance with technical model development. | Governance is about decisions, accountability, controls, evidence, and outcomes. |
| Assuming the highest-accuracy model is always best. | Consider risk, fairness, explainability, cost, robustness, and business fit. |
| Treating ethical review as optional or late-stage. | Responsible AI should be considered from idea through operation. |
| Believing pilots do not need governance. | Pilots still need scope, data controls, risk screening, and learning objectives. |
| Assuming anonymization removes all privacy risk. | Re-identification, inference, and context can still create risk. |
| Treating human review as automatic risk reduction. | Human oversight must be meaningful and supported. |
| Ignoring operations after go-live. | Monitoring, incident handling, change control, and benefits review are essential. |
| Letting suppliers own accountability. | Suppliers provide services and evidence; the using organization still governs use. |
| Confusing transparency with full technical disclosure. | Transparency should be appropriate to audience and decision context. |
| Overlooking affected stakeholders. | AI governance considers people affected by system outputs, not just project sponsors. |
| Treating all AI uses the same. | Governance should be proportionate to risk and impact. |
| Forgetting retirement. | AI systems need controlled withdrawal when no longer suitable. |
Scenario-question method
When you see a scenario, work through this quick sequence.
flowchart TD
A[Read the scenario] --> B[Identify lifecycle stage]
B --> C[Identify main risk or decision]
C --> D[Ask who is accountable]
D --> E[Ask what evidence is needed]
E --> F[Choose proportionate governance action]
Five-question checklist
What decision is being made? Start, continue, approve, deploy, change, pause, escalate, or retire?
What is the main governance concern? Value, data, risk, ethics, security, supplier, assurance, operation, or benefits?
Who should own or approve it? Sponsor, board, project manager, data owner, risk specialist, operational owner, or supplier?
What evidence is missing? Business case, validation, impact assessment, monitoring plan, supplier evidence, or risk acceptance?
What is proportionate? Avoid both under-governance and unnecessary bureaucracy.
Fast comparison: good vs weak governance answers
| If the answer says… | It is likely… |
|---|---|
| “Proceed because the model has high accuracy.” | Too narrow. Look for broader governance evidence. |
| “Escalate because residual risk exceeds tolerance.” | Stronger governance logic. |
| “The supplier is responsible, so internal review is unnecessary.” | Usually weak. Accountability remains with the using organization. |
| “Define acceptance criteria before validation.” | Strong. Testing needs a target. |
| “Monitor after deployment for drift and unintended outcomes.” | Strong. AI governance continues in operation. |
| “Remove sensitive attributes, so fairness risk is solved.” | Weak. Bias can remain through proxies. |
| “Use a human reviewer without changing process or training.” | Weak. Human oversight must be meaningful. |
| “Document rationale and decision ownership.” | Strong. Governance requires traceability. |
| “Deploy the pilot because users liked it.” | Weak. Production readiness requires more evidence. |
| “Review data provenance and permitted use before model development.” | Strong. Data governance starts early. |
Quick terminology check
| Term | Review meaning |
|---|---|
| Governance | System of direction, control, accountability, and decision-making. |
| Assurance | Confidence supported by evidence that controls and outcomes are adequate. |
| Residual risk | Risk remaining after controls are applied. |
| Risk appetite or tolerance | Amount and type of risk an organization is willing to accept. |
| Impact assessment | Structured assessment of potential effects on people, operations, rights, or obligations. |
| Bias | Systematic distortion or unfairness in data, design, or outcomes. |
| Drift | Change that reduces model reliability or suitability over time. |
| Audit trail | Records that allow decisions and actions to be traced. |
| Acceptance criteria | Conditions that must be met before approval. |
| Explainability | Ability to provide understandable reasons for model outputs or behavior. |
| Transparency | Openness about AI use, purpose, limitations, and governance. |
| Accountability | Clear ownership of decisions, risks, and outcomes. |
Notes and examples
Final quick check before practice
Before starting your next mock exam or topic drill, make sure you can answer these without notes:
- Why is AI project governance more than model development?
- What evidence should support a deployment decision?
- Why is data governance needed before model building?
- Why is high accuracy not enough?
- What makes human oversight meaningful?
- Why does governance continue after go-live?
- How should supplier AI risk be controlled?
- What should happen when residual risk is too high?
- Who remains accountable for AI use in the organization?
- How do monitoring, change control, and retirement fit into the lifecycle?
Next step: use this Cheat Sheet as your checklist, then move into PM Mastery practice with topic drills, original practice questions, mock exams, and detailed explanations to test whether you can apply the governance concepts under exam conditions.
Last-week review plan
Use this sequence before mock exams.
Day 1: Governance foundations
- Review lifecycle stages.
- Memorize the difference between delivery, governance, assurance, and operations.
- Practice questions on accountability and decision gates.
Day 2: Data and model risk
- Review data provenance, quality, representativeness, and permitted use.
- Practice topic drills on data risk, model validation, drift, and bias.
- Read detailed explanations carefully, especially when two answers seem plausible.
Day 3: Responsible AI
- Review fairness, transparency, explainability, privacy, security, robustness, and human oversight.
- Practice scenario questions that involve affected stakeholders or high-impact decisions.
Day 4: Supplier, deployment, and monitoring
- Review vendor accountability, production readiness, monitoring, incident management, and change control.
- Practice questions on pilot-to-production decisions.
Day 5: Mixed mock exam
- Take a timed mock exam.
- Review every missed question by identifying the lifecycle stage, risk, accountable role, and missing evidence.
- Create a short list of recurring traps.