WorksheetsPage 1
Total questions: 54
Worksheet time: 27mins
Readiness and release into production — Purpose of a readiness assessment: A readiness assessment is best understood as:
A final performance benchmark
A structured determination of whether the AI system is safe, compliant and suitable for production use
A marketing approval step
A replacement for testing
Readiness and release into production — Readiness assessment scope: Which question is least appropriate for a readiness assessment?
Does the system achieve its intended goal?
Were all required tests completed successfully?
Has conformity been verified?
Will the model improve revenue projections?
Readiness and release into production — Data quality as a release gate: Why is data quality explicitly included in readiness assessments?
Data quality only affects speed
Poor data quality can undermine performance, fairness and reliability even if testing appears successful
Data quality is only a privacy issue
Data quality is fixed at training
Model card timing: Why must the model card exist before release?
It is only for regulators
It consolidates purpose, limits, risks and intended use needed for deployers, users and audits
It replaces technical documentation
It is optional unless required by law
Conformity verification: What does "satisfying conformity requirements" most directly mean?
The model is accurate
The system meets applicable legal, regulatory and internal governance requirements for its risk class
The vendor approved deployment
The system passed a pilot
Periodic assessment purpose: Why does the module emphasise periodic assessments rather than one-time reviews?
Models never change
AI behaviour, data and usage contexts evolve after deployment
Audits are required monthly
Periodic reviews reduce documentation
Performance assessment focus. A performance assessment primarily answers:
Is the model explainable?
Does the system achieve its intended purpose using defined metrics?
Is the system secure?
Is the data lawful?
Reliability assessment focus. Reliability assessments focus on whether the system:
Is accurate at launch
Performs consistently and robustly over time and under real-world conditions
Is fair by design
Meets privacy obligations
Safety assessment focus. Safety assessments primarily evaluate:
UI usability
Whether the system can cause harm and how operational context affects that risk
Licensing compliance
Vendor pricing
User feedback as an input Why is user feedback included in performance and reliability assessments?
It replaces metrics
Users can surface real-world failure modes not visible in controlled testing
It is required by all AI laws
It guarantees fairness
Red teaming definition Red teaming is best described as:
A marketing exercise
Simulating adversarial attacks to expose vulnerabilities, biases and misinformation risks
Accuracy testing only
Legal review
Governance value of red teaming Why is red teaming especially valuable before public release?
It improves brand perception
It identifies vulnerabilities that conventional testing may not reveal
It eliminates the need for audits
It guarantees compliance
A challenger model is used to:
Replace the champion immediately
Compare against the champion to detect drift, regressions or unexpected behaviours
Increase compute efficiency
Avoid documentation
Stress tests are most useful for:
Measuring average performance
Evaluating behaviour under extreme or unexpected conditions
Reducing bias
Meeting transparency obligations
Threat modeling contributes to governance by:
Predicting future profits
Systematically identifying and communicating security risks and attack paths
Replacing incident response
Eliminating adversarial risk
Automation bias risk: What is automation bias in this context?
Bias in training data
Over-reliance on AI outputs because users assume machines are always correct
Bias against automation
Security vulnerability
Governance response to automation bias: Which control best mitigates automation bias?
Disable human oversight
Require human interpretation, review and challenge of outputs
Increase model autonomy
Remove metrics
Anticipating unintended harms: Which method best helps anticipate unintended outputs?
Accuracy testing only
Challenger models and scenario-based analysis
Vendor assurances
UI disclaimers
Why does the module warn about misuse reflection becoming a “roadmap”?
It reduces transparency
Overly detailed misuse analysis can unintentionally guide malicious actors
It violates IP law
It replaces threat modeling
Monitoring is fundamentally about:
Improving UI
Tracking whether the system continues to meet documented purpose and risk assumptions
Reducing documentation
Increasing speed
Which is not listed as a monitoring signal?
Deviations in accuracy
Irregular decisions
Data drift
Marketing engagement metrics
AI system inventory: Why maintain an inventory of AI systems with risk scores?
To reduce audits
To allocate monitoring, review frequency and audit resources proportionally
To eliminate third-party tools
To centralise marketing
Snapshot practice: Why keep snapshots of models and outputs?
For debugging only
To compare versions, identify what changed and support incident analysis
To avoid retraining
To comply with IP law
Purpose drift detection: Why is “new purpose use” a predictable risk?
Users never repurpose tools
AI systems are often applied beyond original scope, invalidating prior risk assessments
Laws prohibit new uses
Purpose drift improves safety
Incident response and issue management — Incident treatment principle: How should AI issues be treated according to the module?
Case-by-case discretion
As incidents, using the organisation’s incident response plan
Only if harm occurs
Only if regulators ask
Incident response and issue management — First step when AI underperforms: When AI performance deviates significantly, the first step should be:
Retrain immediately
Treat it as an incident and invoke the response plan
Ignore until next audit
Disable monitoring
Incident response and issue management — Incident documentation requirement: What must be documented during AI incidents?
Only technical logs
Issue identification, mitigation actions, and communications
Only user complaints
Only vendor responses
Incident response and issue management — AI registrar purpose: Why keep incident information in an AI registrar?
To enable traceability, accountability, and audits
To reduce data storage costs by archiving quickly
To market the AI system to potential customers
To avoid any need for regulatory reporting
Incident root causes — Which set best matches listed reasons incidents may occur?
Vendor failure only
Brittleness, lack of robustness, poor data quality, insufficient testing, model or data drift
UI design errors
User negligence only
Third-party notification — Why must third-party tool users sometimes be notified during incidents?
Courtesy only
Incidents can propagate across integrated systems, affecting partners and internal users
Contracts always require it
To shift liability
Third-party dependency risk — What governance risk arises from integrated third-party tools?
Reduced transparency
Incident impact may extend beyond the primary system
Remote shutdown requirement: Why should humans be able to shut down an AI remotely?
Convenience
Rapid containment of harmful behaviour without physical access
Performance optimisation
Legal symbolism
Threshold disclosure requirement: What disclosure is common across almost all AI laws?
Source code publication
Disclosure that AI is being used or influencing decisions
Full training data lists
Algorithm accuracy
“One notice fits all” fallacy: Why is there no single disclosure that satisfies all transparency obligations?
Laws conflict
Different contexts (finance, health, employment) impose additional, specific notice requirements
Disclosures are optional
AI systems are too complex
Provider–deployer disclosure chain: Under regimes like the EU AI Act, what is required between providers and deployers?
One-time notice
Bidirectional information flow about incidents, monitoring and use context
No communication
Marketing alignment
Disclosure purpose: Why are disclosures tied to appeal and redress rights?
For UX consistency
Users must know AI is involved to exercise legal rights effectively
To reduce litigation
To improve accuracy
Timing of disclosures: Why does timing matter in communications?
Earlier is always better
Users need information when it is relevant to decision-making and risk
Timing is irrelevant
Only regulators care
Risk-level communication: How should communication vary by risk level?
All disclosures identical
Higher-risk systems require more detailed, proactive communication
Why are audits and assessments considered accountability mechanisms?
They replace regulation
They provide evidence that controls exist and function
They guarantee no harm
They reduce cost
Why does audit scope vary by system?
Auditor preference
Risk level, sector, use case and legal requirements differ
All audits are identical
Cost considerations only
Why are AI audits challenging today?
No tools exist
Widely adopted precedents are still emerging
Audits are banned
Models cannot be tested
Why is human review still required even with automation?
Automation is illegal
Humans must validate, challenge and override machine outputs where harm is possible
Machines cannot log actions
Reviews eliminate bias
Deactivation policy purpose Why must organisations have deactivation or localisation policies?
For convenience
Regulatory changes or performance issues may require rapid restriction or withdrawal
To reduce compute
To meet marketing goals
Localisation scenario Which situation best justifies localisation?
UI translation
Jurisdiction-specific legal requirements limiting use or data flows
Latency optimisation
Cost reduction
Graceful shutdown Why emphasise “graceful” shutdown?
For aesthetics
To prevent cascading failures, data loss or safety incidents
To improve performance
To meet IP obligations
Why must governance professionals collaborate with technologists during monitoring?
Technologists own compliance
Root causes of incidents often involve technical brittleness, data issues or drift
Lawyers cannot understand models
Monitoring is purely legal
Which is not a typical root cause listed?
Brittleness
Lack of robustness
Insufficient testing
Strong governance
Why is learning from incidents critical?
To assign blame
To improve system design, monitoring and future risk mitigation
To justify shutdown
To avoid transparency
End-to-end governance logic: Which statement best captures Module 7 Part 2?
Deployment ends governance
Release is a transition point into continuous oversight, not the end of responsibility
Monitoring replaces planning
Transparency is optional
Predictable vs emergent risks: Why distinguish predictable from emergent risks?
To reduce testing
Predictable risks can be mitigated in advance; emergent risks require monitoring and response capacity
To limit documentation
To shift liability
False sense of safety: What creates a “false sense of safety” per the module?
Too much testing
One-time evaluations without continuous monitoring
Excessive documentation
User feedback
Communication failure risk: What is the main risk of poor communication about AI updates?
Delayed model training schedules
Misaligned stakeholders leading to unsafe or incorrect system behavior
Reduced compute costs
Automatic compliance with all policies
Documentation as mitigation: Why does documentation mitigate predictable risks?
It replaces testing
It clarifies purpose, changes and assumptions, enabling detection of misuse and drift
It improves compute
It reduces bias automatically
Exam-level takeaway: Which statement best reflects AIGP expectations for release and post-deployment governance?
Deploy fast, fix later
Continuous monitoring, accountability, transparency and readiness to intervene are core obligations
Governance ends at launch
Incidents are unavoidable
