WorksheetsPage 1
Total questions: 55
Worksheet time: 28mins
Planning for deployment: core scoping questions “Who developed it?” as a governance trigger An organisation is preparing to deploy an AI system. Why is “Who developed it?” a key planning question?
It determines whether the model can be benchmarked
It affects role-based obligations, visibility into design choices, and the organisation’s liability posture
It decides whether the UI needs a disclaimer
It only impacts cloud costs
Planning for deployment: core scoping questions Customisation scope Which scenario most increases the likelihood that a “deployer” begins to resemble a “provider” from a governance burden perspective?
Using an off-the-shelf model with no changes
Making substantive modifications that change risk profile, behaviour, or intended use of the system
Running the vendor’s model with default settings
Adding a chatbot disclaimer to the UI
Planning for deployment: core scoping questions “Who will use it?” Why does identifying whether users are internal staff or external customers materially change deployment planning?
It changes the colour scheme
It alters risk exposure, transparency expectations, incident impact, and compliance duties (especially for consumer-facing contexts)
Which set of questions best reflects the module’s “planning for deployment” essentials?
GPU brand, marketing copy, competitor roadmap
Who developed it, how customisable it is, and who will use it
The model’s parameter count and training epoch number only
Whether the vendor offers a mobile app
When the module says “review existing policy framework to determine gaps,” what is the main objective?
Replace all policies with AI-specific law
Identify where current privacy, security, data governance and IP policies do not address AI’s distinct risks and lifecycle needs
Reduce the number of policies for simplicity
Avoid procurement reviews
Why does a strong existing data governance framework help with AI deployment governance?
It provides established processes for data quality, lineage, access controls and accountability that can be extended to AI workflows
It eliminates the need for model monitoring and incident response
It guarantees legal compliance without additional controls or documentation
It focuses primarily on storage costs, which are the main governance concern
Security policy updates for AI Which AI-specific security issue most directly motivates updating security policies for AI deployment?
Phishing email volume
Adversarial attacks and ML-specific vulnerabilities that can distort outputs or exfiltrate sensitive information
Password rotation rules
Printer firmware updates
Intellectual property policy gaps Which is the most AI-relevant reason to update IP policies before deployment?
IP only matters for patents
AI outputs and proprietary algorithms raise questions of ownership, reuse rights and licensing constraints
IP policies apply only to open source code
IP is irrelevant to deployment
Engineering/model ops policy purpose: Which outcome is an engineering or model ops policy most aimed at for AI deployment?
Determining lawful basis for processing
Establishing lifecycle best practices, release controls, monitoring, retraining triggers and rollback procedures
Creating marketing claims
Setting employee leave entitlements
Open source and platform policies: Why does the module suggest open source and platform policies (for example AWS or Model Garden)?
Platforms remove compliance risk
Organisations need explicit positions on acceptable platforms and models, including risk acceptance, provenance expectations and integration constraints
Open source models are always safer
Platform choice never affects governance
Key principles for adapting policies — Risk-centric approach rationale: Why does the module advocate a risk-centric approach to policy adaptation?
It ensures the fastest deployment
Organisations have limited resources, so governance effort should focus on the highest-risk deployments and harm potential
It reduces need for security testing
It ensures all systems are treated equally
Cutting-edge intent meaning: What does “evaluate cutting-edge intent” practically require from an organisation?
Always adopt frontier models
Decide how far to push advanced AI while explicitly managing privacy/security trade-offs and formal risk acceptance
Avoid any automation
Treat vendor assurances as sufficient
Holistic integration of policies: What does it mean to integrate AI governance policies “holistically”?
Write separate policies for each team with no overlap
Align AI governance with existing processes so policies apply across laws, industries and technologies where feasible
Use a single policy for everything without exceptions
Focus only on privacy policies
Procurement explicitness: Why must procurement of external AI models be explicitly addressed within governance policies?
Procurement teams do not need guidance
Third-party AI introduces distinct risks and contractual dependencies that require screening, ongoing monitoring and acceptable use controls
Cloud-based deployment advantage Which is the best governance-relevant advantage of cloud-based deployment as described?
It eliminates third-party risk
It scales easily and reduces upfront hardware investment, which can enable controlled experimentation and resource elasticity
It guarantees low latency
It ensures data never leaves the organisation
Cloud-based deployment disadvantage Which is the most accurate disadvantage for cloud-based deployments in the module?
Cannot monitor models
Potential latency and added security risks because a third party handles infrastructure and potentially sensitive data flows
Requires no contracts
Only works for edge devices
Why might on-premise deployment be preferred for sensitive data or regulated sectors?
It always improves model accuracy
It offers greater control over infrastructure and data handling, supporting stricter governance and compliance requirements
It eliminates the need for audits
It makes models explainable
Which disadvantage of on-premise deployment is most consistent with the module?
It cannot be monitored
It typically demands higher upfront hardware investment and internal expertise to operate safely
It is illegal
It prevents fine-tuning
Which is the most plausible governance-oriented advantage of edge deployment?
Unlimited compute
Reduced latency and improved privacy because data can remain on-device
Centralised control is stronger
Model behaviour never changes
What is the key constraint for edge deployment in the module?
The model cannot be audited
Edge devices may have limited hardware, constraining computational power and therefore model choice and performance
Edge always increases latency
Edge eliminates the need for policies
Why does choosing between “as-is,” fine-tuning, RAG, and agentic architectures matter for governance?
Only changes UI design
These approaches change system behaviour, data exposure, control points and failure modes, altering assurance needs
Only impacts marketing strategy
Does not affect risk
Which governance difference is most important between using a model “as-is” versus fine-tuning?
Fine-tuning always decreases risk
Fine-tuning can increase obligations by materially altering behaviour, requiring new testing, documentation and potentially different compliance classification
As-is models require no monitoring
As-is models cannot be used externally
RAG-specific risk lens Which risk is particularly relevant to Retrieval Augmented Generation (RAG) in deployment planning?
Only GPU overheating
Data access control, leakage of retrieved content, and provenance/accuracy of retrieved sources influencing outputs
Eliminating need for knowledge bases
Guaranteed factual accuracy
Agentic architectures: distinct requirements Defining feature of agentic systems Which statement best reflects the module’s definition of agentic AI systems?
They only classify images
They actively interact with and influence digital environments through multi-step actions rather than remaining passive
They cannot be monitored
They are identical to static chatbots
Infrastructure requirements for agentic AI Which infrastructure requirement is highlighted as particularly important for agentic AI?
Only serverless compute
Support for autonomy, long-term memory and multi-step actions
No need for logging
No need for access controls
Risk model requirements for agentic AI: Which set of risk controls best aligns with the module’s agentic risk model discussion?
One-time assessment only
Real-time monitoring, audit trails, explainability, human-in-the-loop and override mechanisms, accounting for emergent behaviour
Only privacy notices
Only encryption at rest
Managing emergent behaviours: Why are behavioural simulations and scenario-based risk modelling recommended for agentic AI?
They replace human oversight
Agentic systems can produce unexpected multi-step outcomes, so simulations stress-test behaviours not captured in simple unit tests
They guarantee legal compliance
They remove the need for audit trails
MAESTRO reference purpose: The module references multi-agent risk frameworks (for example MAESTRO). What is the governance intent of such frameworks?
Increasing token limits
Structuring risk assessment and controls for interacting autonomous agents across complex environments
Three-tier guardrails for agentic AI. Which mapping of guardrails tiers is correct?
Tier 1: societal; Tier 2: foundational; Tier 3: risk-based
Tier 1: foundational; Tier 2: risk-based; Tier 3: societal
Tier 1: legal only; Tier 2: marketing; Tier 3: finance
Tier 1: none; Tier 2: minimal; Tier 3: optional
Best practice: constrain action space. Why does “constraining the action space and requiring human approval” matter for agentic safety?
It makes models smaller
It reduces the set of possible harmful actions and introduces friction for high-impact steps, improving controllability
It eliminates the need for monitoring
It guarantees fairness
Best practice: least disruptive defaults. What is the governance rationale for “default behaviours the least disruptive”?
It improves latency
Defaults act as the baseline when uncertainty occurs, so conservative behaviours reduce harm in ambiguous situations
Why is “reliable attribution of agent actions” critical?
It increases model creativity
It supports accountability, incident investigation, auditability and appropriate remediation when actions cause harm
It reduces compute
It prevents all errors
What does “interruptibility (graceful shutdown)” primarily address?
Higher throughput
The ability to stop or contain unsafe agent behaviour without causing uncontrolled failures or data corruption
Better personalisation
Faster fine-tuning
Why does deploying a proprietary model increase obligations and potential liability?
Proprietary models are always high-risk by law
The organisation is both building the technology and using it operationally, increasing responsibility across design, testing, monitoring
Proprietary model opportunity: data transparency. Which opportunity is most directly linked to proprietary model ownership?
Avoiding monitoring
Better transparency about training data origin and provenance because the organisation can source and document it
Eliminating all copyright risk
Removing need for assessments
Proprietary model opportunity: governance reporting. Why might governance reporting be easier with proprietary models?
Reports can be ignored
Ownership can provide access to documentation, test results and design rationale needed for regulatory and internal reporting
Reporting is not required
External vendors prohibit reporting
Proprietary model security posture claim. The module notes proprietary models may be less susceptible to some open source and third-party issues. What is the best interpretation?
Proprietary models cannot be attacked
Controlling the supply chain can reduce provenance and dependency risks
Purpose fit advantage: Why can proprietary models offer better "purpose fit"?
They always outperform frontier models
They can be built for exact requirements rather than retrofitting generic third-party models, improving alignment to constraints and controls
They avoid documentation
They remove need for human oversight
Third-party AI products: contexts and risk management — Two common third-party contexts: Which pair best matches the module’s "two contexts" for third-party AI products?
Research use and personal use
Integration into business operations and employee tool use
Public sector and private sector
Open source and proprietary
Visibility problem: Why is third-party risk management "very challenging" according to the transcript?
Limited visibility into vendor architectures, updates, and data handling across the AI supply chain
Guaranteed regulatory violations for any third-party AI use
Absence of documentation in open-source tools prevents auditing
Employee productivity tools have no operational impact
Internal policy alignment for third-party use — What is the core requirement for policies governing third-party AI products?
Vendor policies override internal policies
Internal policies should align with organisational AI governance expectations and explicitly apply to vendor products and services
Policies should be informal
Only procurement needs policies
“Intentional strategy ahead of time” — What is the most accurate interpretation of an “intentional strategy ahead of time” for third-party AI?
Choose the cheapest vendor
Define screening criteria, expand vendor programs for AI-specific risks, and review acceptable use policies before adoption
Test only after an incident
Let employees decide tool usage
Why does integrating vendor AI into business operations generally demand a more comprehensive risk assessment than employee tool use?
Employee tools have no risks
Integration can directly affect products, customers, and core processes, increasing exposure and the consequences of failures
Employee tools are always internal
Integration always uses anonymised data
Employee tools still matter: Why are off-the-shelf employee tools still governance-relevant?
Employees never use outputs externally
Employees may incorporate tool outputs into client-facing or operational work, transferring risks into organisational decisions and communications
Employee tools are exempt from policy
Employee tools cannot process sensitive data
Risks introduced by third-party models — Data lineage and traceability risk: Which is the best example of a data lineage and traceability issue in third-party AI?
The model runs slowly
The vendor cannot clearly explain where training data originated or whether rights and minimisation practices were applied
The UI is outdated
The vendor offers an API
Downstream “take offline” risk — Which scenario best matches the module’s “downstream issue” example requiring a model to be taken offline?
Minor UI bug
A copyright lawsuit or regulatory action tied to the original training data, forcing suspension of the model’s use
A model gets more accurate
A vendor adds documentation
Output ownership and control — Why does model output ownership become a risk with third-party tools?
Ownership is always the customer’s
Licensing terms may assign ownership or reuse rights to the vendor, restrict publication, or allow vendor training on your prompts and outputs
Outputs are never copyrighted
Ownership only matters for images
Data handling and security risks by environment — Why is “development environment” relevant to third-party risk?
It determines UI features
Cloud or vendor-hosted environments change data exposure, access controls and incident response responsibilities
It guarantees bias reduction
It prevents misuse
Which is the most governance-relevant reason that “quality and model performance may not be a good fit for the task” is a risk?
Performance only matters for user satisfaction
Poor fit can create operational errors, unfair outcomes, and compliance failures if the model is applied outside validated scope
Fit can be ignored if the vendor is large
Fit is solved by disclaimers
Why does the module emphasise contracts to manage third-party AI risk?
Contracts guarantee model accuracy
Contracts allocate responsibilities for data handling, incident response, acceptable use, IP/output rights, and evidence provision
Contracts replace internal policy
Contracts are only for pricing
Which is the best explanation for why procurement, supply chain, HR and acceptable use are mentioned explicitly?
They are unrelated to AI
AI deployment risk spans organisational functions: acquisition (procurement), dependencies (supply chain), workforce use (HR), and constraints on usage (acceptable use)
Only HR matters
Only procurement matters
Vendor or licensing agreement: key evaluation areas — Data rights clause scrutiny: Which is the most critical reason to evaluate whether the vendor has legal rights to training data?
It only impacts model speed
Lack of rights can create legal exposure, forced discontinuation, and reputational harm for the deploying organisation
It improves explainability
It reduces compute needs
Minimisation and deidentification in vendor training: Why does asking whether personal data was minimised and deidentified matter?
It is only a technical preference
It signals maturity of privacy engineering and reduces risk of privacy violations and sensitive data leakage in outputs
It guarantees no bias
It makes RAG unnecessary
Security and safety: misuse and high-risk activities: Why does the agreement review ask about potential misuse or use for high-risk activity?
Because high-risk use is always allowed
Models can be repurposed, and governance must anticipate misuse pathways, safety controls, and vendor incident readiness
Terms of use: fine-tuning and IP outputs — Why are "allowed to fine-tune" and "IP and outputs" specifically high-stakes agreement terms?
They only affect pricing
Fine-tuning changes responsibility and may alter risk profile; output terms determine whether you can legally use, publish, or protect generated content
They are irrelevant if the model is accurate
They only matter for internal tools
