WorksheetsModule 6 Part 1
Total questions: 45
Worksheet time: 23mins
AI life cycle and planning fundamentals — Life cycle ordering: Which ordering best reflects the iterative AI development life cycle described?
Deployment → Testing → Monitoring → Data prep → Decommissioning
Planning/design → Data collection/preparation → Model development → Testing/evaluation → Deployment → Monitoring/maintenance → Decommissioning
Data prep → Planning/design → Deployment → Testing → Monitoring
Planning/design → Deployment → Data prep → Model development → Decommissioning
AI life cycle and planning fundamentals — “Planning is critical” rationale: Why does the module treat planning and design as a critical step?
It is where the model weights are set
It defines objectives, evaluates use cases and data, and establishes governance structures before building decisions become costly
It is required only for high-risk AI
It replaces monitoring and maintenance
AI life cycle and planning fundamentals — Business context definition: Which statement best matches “define the business context and use case”?
Choose the best-performing model on a benchmark
Specify the mission goal, what decision/output is needed, who is affected, and whether AI is suitable for that purpose
Start collecting as much data as possible
Write the privacy policy first
AI life cycle and planning fundamentals — Suitability decision: Which governance step most directly addresses “should we use AI at all”?
Benchmarking
Use case evaluation
Harms matrix
Pre-deployment pilot
AI life cycle and planning fundamentals — Requirements gathering trap: Which choice is most likely to be a governance failure during requirements gathering?
Documenting trade-offs between privacy and accuracy
Defining success metrics and thresholds
Starting model training before agreeing on goals, risk tolerance and oversight ownership
Identifying sector-specific compliance requirements
Stakeholder engagement and accountability — Timing of stakeholder engagement: The module’s stakeholder guidance implies stakeholder engagement should occur:
Only at deployment
After model selection, before pilots
Early and continuously through the life cycle
Only after an incident
Stakeholder engagement and accountability — Stakeholder group’s first job: What is the most defensible “first output” of a stakeholder group?
A list of model vendors
Agreement on the goal and whether AI is suitable for the mission/purpose
A pilot schedule
A marketing plan
Stakeholder engagement and accountability — Accountability assignment: Why does the stakeholder group need to establish who is ultimately responsible for risks and mitigations?
To reduce cost
To clarify accountability for failures and risk acceptance before implementation
Because regulators require a single person be blamed
Because models cannot be audited
Stakeholder engagement and accountability — Stakeholder membership: Which stakeholder set best matches the module’s examples of common stakeholders?
Only engineers and data scientists
AI governance officers, privacy experts, security experts, procurement, subject matter experts and legal
Only legal and marketing
Only leadership and HR
Operational controls and “who owns what” — Sector-specific compliance cue: The module uses HIPAA as an example of what practice?
Benchmarking
Sector-specific compliance evaluation tied to training data and system use
Vendor certification
Kill switch ownership
Stakeholder engagement and accountability — Meeting frequency purpose: Why does the module suggest deciding how frequently the stakeholder group meets?
To satisfy procurement
To continuously evaluate progress toward goals and surface risks early
To finalise model architecture
To reduce documentation needs
Stakeholder engagement and accountability — Competing values scenario: The guidance says there may not be “one perfect answer” when values compete (for example accuracy vs privacy). What is the best governance expectation?
Always prioritise privacy
Always prioritise accuracy
Decide priorities explicitly, obtain stakeholder agreement, and document the trade-off decision
Let engineering decide silently
Operational controls and “who owns what” — Stakeholder input and governance framework alignment: Why must stakeholders who wrote general governance policies also advise on specific AI systems?
They are legally required to do so
To ensure the project aligns with established governance frameworks and organisational objectives
Because they own model development
Because audits are optional
Operational controls and “who owns what” — Operational controls scope: Which list best represents the operational control ownership decisions the module highlights?
Model selection, feature engineering, dataset labelling
Real-time operational responsibility, audits/reviews, feedback/appeals, escalation, kill switch ownership
Marketing claims, pricing, branding
Data retention schedules only
Operational controls and “who owns what” — Kill switch ownership: Why is “own the kill switch” an explicit governance decision?
Because kill switches improve accuracy
Because someone must have authority to stop or suspend the system
Appeals mechanism relevance: Why do feedback and appeals mechanisms matter in planning/design?
They are only for customer support
They operationalise accountability by enabling challenge and remediation of harmful outcomes
They replace benchmarking
They eliminate legal risk
Escalation criteria: What is the strongest reason to define how issues are elevated in emergent or emergency situations?
It improves system speed
It reduces ambiguity and delays when rapid action is needed to prevent harm
It increases training data availability
It eliminates privacy requirements
Impact assessments: AIA vs PIA vs DPIA — Impact assessment definition: In this module, an impact assessment is best described as:
A marketing review
A lifecycle risk management tool assessing benefits, risks and limitations
A model benchmark score
A procurement checklist
Algorithmic impact assessment content: Which item is most appropriate within an algorithmic impact assessment based on the module?
Only model accuracy
Data issues, stakeholder decisions, risk identification/mitigation, and who approves or accepts risk
Only privacy notices
Only vendor pricing
Using existing processes: What does the module recommend regarding PIAs/DPIAs?
Avoid them because they are not AI-specific
Use them where possible as a starting point, but identify gaps for a comprehensive algorithmic impact assessment
Replace them entirely with benchmarking
Use a PIA only and skip DPIAs
DPIA vs PIA difference: Which distinction best matches the module’s descriptions?
DPIA is about financial risk; PIA is about model risk
DPIA focuses on risks from processing personal data; PIA analyses how PII is handled and privacy compliance
DPIA is only for government; PIA is only for private sector
DPIA is optional under privacy law; PIA is mandatory
Limitation of relying solely on PIA/DPIA: The module’s stated limitation of relying only on a PIA or DPIA is that:
They are illegal for AI
They are not tailored specifically for AI applications and may miss AI-specific governance requirements
They are too expensive
They cover too much
Training data assessment nuance: The module suggests considering a PIA on underlying training data. Why?
Training data is never personal data
Training data processing can create privacy risks and must be evaluated independently of deployment processing
It replaces data minimisation
It is only relevant for benchmarking
Gap identification: When adapting PIAs/DPIAs into an algorithmic impact assessment, what is the key governance task?
Remove all privacy sections
Identify gaps between existing templates and AI project needs (such as human oversight, model limits, monitoring and appeal paths)
Add marketing messaging
Focus only on data retention
Risk assessment strategies (order matters) — Sequence test: Which sequence matches the module’s recommended order of risk assessment strategies?
Harms matrix → benchmarking → stakeholder mapping → pilots → mitigation hierarchy
Use case evaluation → stakeholder mapping → probability/severity harms matrix → risk mitigation hierarchy → benchmarking → pre-deployment pilots
Stakeholder mapping → pilots → benchmarking → mitigation hierarchy → harms matrix
Benchmarking → use case evaluation → harms matrix → stakeholder mapping → pilots
Use case evaluation goal: Use case evaluation is primarily intended to:
Decide whether the model should be open source
Determine whether AI is warranted and what type of model suits the need, while flagging risks
Assign kill switch ownership
Replace stakeholder mapping
Stakeholder mapping purpose: Stakeholder mapping is best described as:
A technical test
A project management step ensuring correct decision-makers are involved and communication channels exist
A compliance filing
A pilot environment configuration
Harms matrix calculation logic: What does the probability/severity harms matrix do?
Adds probability to severity
Multiplies probability score by severity score to rate risk
Chooses benchmarks
Assigns stakeholders
Matrix misuse trap: Which is the most defensible critique of a harms matrix used alone?
It is too technical
It identifies and ranks risk but does not specify what to do next
It is illegal
It replaces stakeholder mapping
Mitigation hierarchy role: Why is the risk mitigation hierarchy described as the “now what” portion?
It generates benchmark scores
It provides structured options: avoid, minimise, remediate and offset impacts
It assigns compliance budgets
It replaces DPIAs
Avoid vs minimise: Which option best reflects "avoid" in a mitigation hierarchy?
Improve accuracy
Remove or redesign the use case so the risk no longer exists
Provide user notice
Buy insurance
Benchmarking purpose: Why is benchmarking especially useful for less transparent models?
It reveals source code
It provides standardised comparative testing to evaluate performance characteristics when interpretability is limited
It replaces pilots
It guarantees fairness
Benchmark choice: Which benchmarking approach best matches the module?
Only speed testing
Standardised tests for accuracy, speed and complex task handling, including targeted evaluation such as language understanding for LLMs
Only privacy testing
Only usability testing
Pre-deployment pilot definition: A pre-deployment pilot is best defined as:
A post-incident review
A trial phase before go-live, ideally matching production conditions closely, used to confirm behaviour and update before deployment
A legal audit
A marketing beta
Pilot environment trap: Why does the module emphasise pilots matching production conditions as closely as possible?
It increases marketing value
It reduces the risk that the system behaves differently under real constraints, distributions, and operational pressures
It removes privacy obligations
It makes benchmarking unnecessary
Documentation purpose: Why does the module emphasise documenting design and build processes?
Documentation is optional but nice
Documentation supports compliance evidence, risk management, and traceability of decisions and trade-offs
Documentation improves model accuracy directly
Documentation replaces governance
Documenting trade-offs: Which trade-off decision is most important to document according to the stakeholder guidance?
Font choice in UI
Competing values trade-off decisions, for example privacy vs accuracy thresholds
Whether to use Python
Employee preferences
Evidence of risk acceptance: Where should "who approved or accepted the risk" most appropriately be recorded?
Only in email
In the algorithmic impact assessment and governance documentation
Only in the code repository
Only in a vendor brochure
Communication audiences: The stakeholder guidance suggests communicating risks and mitigations to different audiences. Why?
Everyone needs the same detail
Different audiences need different formats and levels of detail to act appropriately
Communication increases model performance
Communication removes liability
Compliance vs governance artefacts: Why might a PIA be insufficient as the only governance document for an AI system?
It covers too much technical content
It may not cover operational controls, model behaviour limits, stakeholder trade-offs, and oversight arrangements required for AI governance
It is not recognised legally
It is always optional
Choosing the right method: A team is deciding whether to automate a decision that impacts individuals. Which two methods should be initiated earliest?
Benchmarking and pilots
Use case evaluation and stakeholder mapping
Pilots and harms matrix
Benchmarking and mitigation hierarchy
Harms matrix to mitigation: A harms matrix shows a high-severity, moderate-probability risk. What is the next most appropriate governance step?
Skip mitigation and proceed to deployment
Apply the risk mitigation hierarchy to choose avoidance, minimisation, remediation or offsetting measures
Replace the model vendor
Publish transparency notices
Operational control failure mode: An AI system causes harm and the organisation cannot quickly suspend it because authority is unclear. Which planning control was missed?
Benchmarking selection
Kill switch ownership and escalation processes
Data preparation
Model selection
Governance under uncertainty: A stakeholder group cannot agree whether to prioritise privacy or accuracy. Which response best matches module guidance?
Let engineering decide privately
Escalate to leadership, decide risk tolerance for scenarios, document the decision and revisit periodically
Choose whichever is cheaper
Delay indefinitely
Late-stage validation choice: A black box model performs well internally, but stakeholders worry it may fail in real-world conditions. Which combination best addresses this concern late in design?
Stakeholder mapping and DPIA
Benchmarking and pre-deployment pilots
Use case evaluation and harms matrix
PIA and procurement review
