AIGP is easier to study when governance concepts are applied to concrete systems. The current exam includes scenario-based questions, and the v2.1 Body of Knowledge emphasizes use-case context, impact assessment, law, data governance, testing, vendor risk, monitoring, downstream harms, incident management, and deactivation. Those skills are inherently case driven.
The scenarios below are study exercises aligned to the current AIGP scope. They are not live exam questions. Use them to practice moving from facts to governance action rather than reciting principles.
Case one: an employer wants an AI résumé-screening system
Begin with purpose and affected stakeholders. Employment is a sensitive context for nondiscrimination and fairness. The governance team should assess data provenance, historical bias, validation across relevant groups, human oversight, transparency, appeals or review processes, vendor responsibilities, and ongoing monitoring.
The correct response is not simply “test accuracy.” A model can be accurate overall while creating disparate harms for specific groups.
Case two: a customer-service team deploys a generative AI agent
Identify whether the agent only answers questions or can take actions such as refunds, account changes, or messages. Tool permissions change the risk profile dramatically. Grounding, user disclosure, human escalation, content controls, logging, and monitoring should match the allowed actions.
If the agent can perform high-impact actions, approval boundaries and deactivation controls become especially important.
Case three: a company wants to fine-tune a model on customer conversations
Review lawful rights to use the data, purpose limitation, minimization, sensitive information, retention, cross-border transfer, vendor or processor relationships, data quality, and whether customers were told how conversations would be used.
The data and AI relationship is central here. Technical usefulness does not establish legal or ethical permission to use the data.
Case four: a vendor provides a powerful general-purpose model
Evaluate the vendor contract, licensing restrictions, transparency, security, model documentation, data handling, monitoring commitments, indemnity or liability allocation, and the organization’s own deployment role. The buyer still needs an impact assessment for its specific use case.
General-purpose capability increases reuse opportunities but can also increase uncertainty about downstream behavior.
Case five: a medical-support model performs well in testing but degrades after launch
Investigate data drift, model drift, changed workflow, new patient populations, poor monitoring, or hidden changes in upstream data. Governance should define performance thresholds, review cadence, maintenance, retraining, and escalation before the incident occurs.
The decision may be to retrain, restrict use, add human review, or deactivate until safety is restored.
Case six: an organization wants to use an open-source model on premises
Compare privacy, security, control, licensing, maintenance, patching, model provenance, infrastructure capability, and workforce readiness with managed-cloud alternatives. “Open source” can reduce some vendor dependencies while increasing internal operational responsibility.
The governance decision should reflect the organization’s ability to secure and maintain the full deployment stack.
Case seven: a regulator requires evidence of responsible development
Produce the lifecycle documentation: impact assessment, data provenance, risk analysis, testing records, acceptance thresholds, human oversight, model card, technical documentation, incident process, and monitoring plan.
This case demonstrates why documentation is a governance control. Evidence must show what was decided, why, and how controls were validated.
Case eight: an agent begins using a tool in an unintended way
Assess whether tool permissions were too broad, instructions were ambiguous, testing missed edge cases, or monitoring failed to detect the behavior quickly. Contain the system, document the incident, evaluate downstream harm, and update controls before restoring operation.
Agentic architecture introduces secondary-use and autonomy risks that ordinary chatbot governance may not capture.
Case nine: an AI use case moves from pilot to enterprise deployment
Reassess risk instead of assuming the pilot approval still applies. Scale changes affected population, data volume, system integration, business impact, security exposure, and operational dependencies.
A governance program should have a release gate that considers scale and material change.
Case ten: the system is legally permissible but socially controversial
Law is the floor, not the entire governance decision. Apply organizational ethics, risk tolerance, human-centricity, stakeholder impact, reputational risk, transparency, and long-term trust. Leadership may decide not to deploy even when no law clearly prohibits the use.
The broader IAPP certification approach is valuable because AIGP combines legal compliance with responsible governance. The case is complete when the decision can be justified through principles, evidence, and accountable ownership.
Case eleven: a financial-services team wants an AI system to recommend credit limits. Existing nondiscrimination, consumer-protection, privacy, and automated-decision requirements may apply even before AI-specific law is considered. The governance team should define decision authority, explainability needs, adverse-impact testing, human review, data quality, and complaint handling before pilot approval.
Case twelve: a marketing team wants to upload customer data to a public AI tool because it is faster than approved procurement. The governance issue is not only confidentiality. Data processing terms, purpose limitation, intellectual property, retention, third-party risk, acceptable-use policy, and vendor security can all be implicated. The correct response may be an approved enterprise alternative rather than an informal ban with no usable replacement.
Case thirteen: a model provider releases a new version automatically. The deployer’s validation assumptions may no longer hold. Version change should trigger risk review proportional to materiality, regression testing, monitoring, and documentation. A vendor’s upgrade schedule is part of the deployment lifecycle when the organization depends on a managed model.
Case fourteen: a public-sector organization wants facial recognition for building access. Biometrics are sensitive data, the use can create surveillance and discrimination concerns, and jurisdiction-specific limits may apply. Governance should assess necessity, proportionality, lawful basis, alternatives, retention, accuracy across groups, security, and human challenge procedures.
Case fifteen: an open-source model license changes after the system is already embedded in a product. Legal and operational teams should assess whether continued distribution, modification, hosted use, or downstream obligations are affected. Model governance includes license provenance and dependency tracking just as software governance does.
Case sixteen: a model meets all current technical thresholds but user complaints reveal confusing explanations. Transparency and human-centricity can still be weak even when performance is high. The organization should evaluate how users understand the system, whether notices are meaningful, and whether escalation or appeal is accessible.
Case seventeen: an agent causes a harmful downstream action that was not included in the original impact assessment. Contain the system, document the incident, trace the action path, update the assessment, revise tools or approvals, and evaluate external notification. Secondary-use risk should be incorporated into future monitoring and release criteria.
Case eighteen: a successful pilot expands from one country to several jurisdictions. Reassess legal applicability, data transfer, language, bias, cultural context, user notice, and local regulatory requirements. Geographic expansion can materially change governance even when the technical system is identical.
After each case, classify the evidence you would keep: assessment, contract, test results, model card, approval, monitoring report, incident record, user notice, or deactivation decision. Governance becomes much easier to audit when evidence is identified at the time the decision is made.
Case nineteen: a company uses a third-party AI model in customer support, but the vendor will not provide meaningful evaluation details. The governance team should treat transparency limitations as a deployment risk, consider contractual rights, independent testing, narrower use, human review, and whether an alternative supplier is needed. Convenience should not erase evidence requirements.
Case twenty: a generative model produces copyrighted material that resembles training examples. Governance should examine intellectual-property obligations, model and data provenance, user terms, output review, indemnity, and use restrictions. The legal analysis and the technical control strategy need to inform one another.
Case twenty-one: a team wants to repurpose an internal fraud model for employee monitoring. Secondary use changes affected stakeholders, legal context, proportionality, transparency, and harm. The original approval should not be treated as blanket authorization for a materially different use.
Case twenty-two: a system works well in English but performs poorly in another language used by a new market. Evaluate training data, representativeness, testing, local context, user impact, and whether deployment should be limited until thresholds are met. Geographic expansion can introduce performance and fairness risks simultaneously.
Case twenty-three: an AI system is safe under ordinary use but fails under adversarial prompts. Red teaming and security testing reveal the gap. The response may include input controls, tool restrictions, output monitoring, user training, and stronger incident detection. Security robustness is part of responsible deployment.
Case twenty-four: a regulator changes its interpretation of a high-risk category after deployment. Governance should reassess classification, required controls, documentation, conformity, and whether localization or deactivation is necessary. Regulatory monitoring is part of the ongoing lifecycle, not only a prelaunch legal review.
Case twenty-five: an organization wants AI-generated code inserted directly into production. Governance should consider secure software development, intellectual property, testing, human review, dependency risk, secrets exposure, and accountability. The risk is not only whether the model generates correct syntax; it is whether unreviewed code enters a high-impact environment.
Case twenty-six: a customer demands deletion of personal data that was used in an AI workflow. Governance should examine source records, retained prompts, logs, embeddings, fine-tuning datasets, vendor obligations, and applicable rights. The technical response depends on where personal data persists across the system.
Case twenty-seven: senior leadership wants to skip impact assessment because the use case is urgent. Governance should explain the risk of bypassing the control, propose an expedited but documented assessment if appropriate, and preserve decision authority. Urgency can change process timing but should not make accountability disappear.
These case drills are most valuable when you state what would make you change the decision later: new law, drift, incident, vendor update, new population, or expanded use. Governance is strongest when reassessment triggers are defined in advance.
For every practice case, write six lines: purpose, stakeholders, applicable law or standards, principal risks, controls, and evidence. That format forces governance reasoning to remain concrete and repeatable.