Governance, Compliance and Cloud Transformation

Introduction

Cloud computing has changed the technical foundations of artificial intelligence and machine learning (AI/ML). Organizations can now obtain elastic compute, managed data platforms, foundation models, and specialized accelerators without building every capability themselves. However, technical availability does not guarantee organizational value. Cloud adoption also creates questions about authority, accountability, data location, security, regulatory compliance, operational responsibility, cost, and the social consequences of automated decisions.

Governance provides the structures through which these questions are answered. It defines who may make decisions, which rules apply, how risks are measured, and how evidence is retained. Compliance translates external obligations—such as privacy, cybersecurity, financial regulation, intellectual-property law, and sector-specific requirements—into organizational controls. Cloud transformation is the broader process of changing technology, operating models, skills, processes, and investment priorities to use cloud capabilities responsibly and effectively.

For AI/ML systems, governance must extend beyond infrastructure. It must address data provenance, model validity, explainability, human oversight, monitoring, bias, security, and accountability throughout the system life cycle.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the relationship among cloud governance, compliance, risk management, and accountability.

2. Design a governance structure for cloud accounts, policies, data residency, identity, cost, and audit.

3. Apply a risk-based approach to AI/ML governance.

4. Compare cloud operating models and explain the role of a Cloud Center of Excellence.

5. Develop a migration roadmap, skills plan, and technology investment case.

6. Evaluate the limitations and ethical implications of cloud-based AI transformation.

1. Governance in the Cloud

1.1 Meaning and purpose

Governance is the system of decision rights, policies, processes, controls, and assurance mechanisms used to direct and control an organization. Management performs day-to-day activities; governance establishes the boundaries and evaluates whether those activities support organizational objectives.

Cloud governance is not simply a security checklist. It coordinates several dimensions:

• Strategic governance: whether cloud investments support business and public value.
• Financial governance: how consumption is budgeted, forecast, allocated, and optimized.
• Technical governance: how architectures, services, reliability, and interoperability are controlled.
• Security governance: how confidentiality, integrity, availability, identity, and resilience are protected.
• Data governance: how data is classified, owned, retained, shared, and deleted.
• AI governance: how models are designed, validated, deployed, monitored, and retired.
• Regulatory governance: how obligations are interpreted and evidenced.

A useful principle is that governance should be centralized where consistency is essential and federated where domain expertise and speed are important. For example, identity standards and encryption requirements may be centrally mandated, while business units may select approved analytical services for their specific needs.

1.2 Shared responsibility

Cloud providers secure the underlying facilities, hardware, and many managed services. Customers remain responsible for aspects such as identity configuration, data protection, access permissions, application security, workload configuration, and lawful use. The exact boundary varies by service model:

• In infrastructure as a service, the customer manages more of the operating system and application stack.
• In platform as a service, the provider manages more infrastructure and runtime components.
• In software as a service, the provider manages most of the platform, but the customer still controls users, data, configuration, and business use.

Shared responsibility is not shared accountability. An organization may outsource infrastructure operations, but it generally cannot outsource responsibility for choosing lawful purposes, protecting sensitive information, or ensuring that an AI decision is appropriate.

2. A Governance Architecture for Enterprise Cloud

2.1 Decision rights and accountability

A practical governance architecture assigns named owners to major decisions. Typical roles include:

• Board or executive risk committee: approves risk appetite and oversees material exposure.
• Chief information officer or technology executive: aligns cloud strategy with enterprise strategy.
• Chief information security officer: establishes security requirements and assurance.
• Data protection or privacy officer: interprets privacy obligations and individual rights.
• Chief data officer: governs data ownership, quality, classification, and lifecycle.
• AI governance committee: evaluates high-impact use cases, model risk, human oversight, and accountability.
• Cloud platform team: supplies landing zones, reusable services, security guardrails, observability, and automation.
• Product or business owners: remain accountable for outcomes, users, and acceptable use.
• Internal audit: independently evaluates controls and evidence.

A responsibility assignment matrix, often called a RACI matrix, can clarify who is Responsible, Accountable, Consulted, and Informed. A useful rule is that every important control should have one accountable owner, even when several teams perform it.

2.2 Organizational hierarchy: organizations, accounts, and projects

Cloud providers commonly offer an enterprise hierarchy in which a top-level organization contains accounts, subscriptions, or projects. A controlled structure normally separates:

• production and non-production environments;
• security, logging, and audit functions;
• networking and shared services;
• business units or legal entities;
• regulated workloads from lower-risk experimentation.

Separate accounts or projects improve isolation, billing attribution, and blast-radius reduction. They are not a substitute for identity governance. Excessive fragmentation can create duplicated controls, difficult networking, and unclear ownership. The design should therefore reflect legal boundaries, risk boundaries, operational boundaries, and team responsibilities.

A landing zone is a preconfigured cloud foundation containing approved identity integration, network patterns, logging, encryption, monitoring, policy controls, and account structures. It allows teams to deploy quickly without repeatedly designing basic safeguards.

2.3 Policy hierarchy and preventive controls

Governance policies should be expressed at multiple levels:

1. Enterprise principles, such as least privilege, lawful processing, and resilience.

2. Mandatory standards, such as encryption, retention, and vulnerability remediation periods.

3. Technical guardrails, such as restrictions on public storage, unapproved regions, or untagged resources.

4. Procedures and runbooks describing implementation and response.

Preventive controls block prohibited activity; detective controls identify violations; corrective controls restore an acceptable state. For example, a policy may prevent creation of storage without encryption, detect anomalous access, and trigger automated quarantine when a violation occurs.

Policy-as-code makes rules executable and testable. It can check infrastructure templates before deployment and continuously evaluate running resources. Nevertheless, automated controls require maintenance: an obsolete policy can block legitimate innovation or create a false sense of security.

2.4 Identity and access governance

Identity is the primary control plane in cloud environments. Important practices include single sign-on, multifactor authentication, centralized identity lifecycle management, role-based access, privileged-access management, short-lived credentials, and periodic access reviews.

Least privilege means granting only the permissions required for a defined task and duration. It must be applied to human users, applications, pipelines, notebooks, model endpoints, and service accounts. AI projects often create hidden access paths through notebooks, feature stores, data pipelines, and model registries. These paths should be inventoried and reviewed.

Access should be based on both identity and context. Context can include device health, network location, workload identity, time, data sensitivity, and transaction risk. Emergency access should be time-limited, logged, and reviewed after use.

3. Data Residency, Sovereignty, and Lifecycle Governance

3.1 Residency and sovereignty

Data residency refers to the physical or selected geographic location where data is stored or processed. Data sovereignty concerns the legal authority and jurisdiction under which data falls, including the possibility that a provider or government may be subject to laws outside the storage location. These concepts are related but not identical.

A residency policy should distinguish:

• primary storage location;
• backup and disaster-recovery location;
• processing location;
• support and administrative-access location;
• location of logs, telemetry, and model artifacts;
• location of subprocessors and data transfers.

For AI systems, residency analysis must include training datasets, prompts, embeddings, vector indexes, feature stores, checkpoints, evaluation data, and outputs. A model artifact can reveal sensitive information even when the original database is inaccessible.

Organizations should create a data inventory and classification scheme. A simple scheme may include public, internal, confidential, and restricted information. Classification should consider personal data, health and financial information, national-security concerns, intellectual property, biometric information, and commercially sensitive data.

3.2 Lifecycle controls

Data governance follows a lifecycle:

1. Collection and lawful purpose definition.

2. Validation, quality assessment, and provenance recording.

3. Storage and controlled use.

4. Sharing, transformation, and model training.

5. Retention and archival.

6. Deletion or anonymization.

Retention should be justified by law, business need, and model usefulness. Keeping all data indefinitely increases breach impact, discovery obligations, and the chance of using obsolete or unfair information. Deletion must include replicas, caches, backups where technically and legally required, derived datasets, and model artifacts when they contain or reproduce the information.

4. Compliance and Auditability

4.1 Compliance as evidence

Compliance is not merely the existence of policies. It is the ability to demonstrate that obligations have been interpreted, controls implemented, controls operated, and exceptions managed. A control-evidence mapping connects each requirement to an owner, implementation, test method, frequency, and evidence repository.

Common control families include:

• identity and access management;
• asset inventory and configuration management;
• secure development and change management;
• vulnerability and incident management;
• business continuity and disaster recovery;
• privacy and records management;
• supplier and subprocessor management;
• AI model validation and monitoring.

Organizations may use recognized security and privacy frameworks, sector regulations, contractual requirements, and internal policies. Frameworks help organize controls, but they do not automatically establish legal compliance. Applicability depends on jurisdiction, sector, data, business activity, and contractual context.

4.2 Audit trails

An audit trail should answer: who performed an action, what was changed, when it occurred, from where, under which authorization, and with what result. Logs should be centralized, time-synchronized, protected from alteration, retained for a defined period, and monitored for suspicious behavior.

AI auditability also requires records of dataset versions, feature definitions, model code, hyperparameters, training environment, evaluation results, approvals, deployment changes, prompts or instructions where appropriate, and post-deployment performance. The records should be sufficient to reconstruct a material decision without retaining unnecessary personal information.

4.3 Compliance failure modes

Frequent failures include treating a provider certification as proof that every customer workload is compliant, neglecting backups and logs in residency analysis, failing to monitor subcontractors, and documenting controls that are not actually operated. Another failure is “checkbox governance,” in which teams optimize for an audit rather than for real risk reduction.

5. Risk Management and AI Accountability

5.1 Risk-based governance

Risk can be analyzed as the combination of a harmful event, its likelihood, and its impact. Qualitative matrices commonly classify likelihood and impact as low, medium, or high. Quantitative estimates may use an expected-loss model:

Expected annual loss = probability of loss during a period × monetary impact if loss occurs.

This relationship is useful when probabilities and impacts can be estimated with reasonable confidence. It should not be treated as a precise truth when uncertainty is high, impacts are non-monetary, or harms are irreversible. Privacy, discrimination, safety, and human-rights impacts may require separate assessment rather than being reduced to money.

Risk treatment options are to avoid, reduce, transfer, accept, or share risk. Acceptance should be explicit, time-bounded, and approved by an authority with sufficient accountability.

5.2 AI system life-cycle governance

AI governance should begin before model development. A proportionate life-cycle process includes:

1. Use-case registration: purpose, users, affected people, data, jurisdiction, and owner.

2. Impact assessment: potential safety, privacy, discrimination, security, labor, and social harms.

3. Data assessment: provenance, consent or lawful basis, representativeness, quality, licensing, and retention.

4. Design review: model choice, explainability needs, human role, fallback procedures, and security.

5. Validation: accuracy, robustness, calibration, fairness indicators, privacy tests, and stress tests appropriate to the use case.

6. Approval: independent review proportional to impact.

7. Deployment controls: access, rate limits, content safeguards, monitoring, and rollback.

8. Operations: drift, incidents, complaints, overrides, and changing regulatory requirements.

9. Retirement: secure deletion, replacement, and communication to affected stakeholders.

Fairness cannot be established by one metric in every context. Different fairness measures can conflict, particularly when groups have different base rates. The appropriate assessment depends on the decision, legal context, harms, and available evidence. Technical metrics should therefore be combined with domain review and affected-person feedback.

5.3 Generative AI accountability

Generative AI introduces risks including fabricated outputs, prompt injection, data leakage, copyright disputes, insecure code, excessive autonomy, and unclear provenance. Governance should define approved uses, prohibited uses, human review thresholds, data-handling rules, model-selection criteria, evaluation sets, output labeling where relevant, and incident escalation.

Human oversight must be meaningful. A person who merely clicks approval without sufficient time, information, authority, or competence does not provide effective oversight. High-impact decisions should include mechanisms for explanation, contestability, correction, and appeal where applicable.

6. Cloud Operating Models and the Cloud Center of Excellence

6.1 Operating models

An operating model describes how people, processes, technology, and suppliers work together. Three broad patterns are common:

• Centralized model: one central team controls most cloud decisions. It promotes consistency but can become a bottleneck.
• Federated model: a central platform or governance group sets standards while domain teams operate workloads. It balances control and autonomy.
• Decentralized model: business units make most decisions independently. It can move quickly but increases duplication, inconsistent security, and unmanaged cost.

For many enterprises, a federated model with strong central guardrails is effective. The appropriate model depends on regulatory exposure, technical maturity, organizational scale, and the need for local expertise.

6.2 Cloud Center of Excellence

A Cloud Center of Excellence (CCoE) is a cross-functional group that accelerates safe and repeatable cloud adoption. It should not become a permanent approval bureaucracy. Its activities may include:

• reference architectures and reusable templates;
• landing zones and platform engineering;
• security, privacy, and compliance patterns;
• migration methods and factory tooling;
• FinOps and resource-tagging standards;
• training, communities of practice, and coaching;
• approved service catalogs;
• metrics, lessons learned, and exception management.

A mature CCoE gradually transfers capability to product teams. Its success measures should include deployment lead time, control coverage, reliability, adoption of reusable patterns, cost transparency, audit findings, and user outcomes—not merely the number of cloud projects completed.

6.3 FinOps and investment governance

Cloud cost is variable and can grow rapidly through idle resources, data transfer, excessive logging, oversized instances, uncontrolled experimentation, and model inference. FinOps combines engineering, finance, and business accountability. Practices include budgets, forecasting, allocation tags, unit-cost metrics, anomaly detection, rightsizing, scheduling, reserved capacity where appropriate, and workload-level ownership.

AI investment should consider total cost of ownership, including data preparation, experimentation, storage, network transfer, inference, monitoring, security, compliance, human review, and retirement. A cheaper model may create greater operational or legal cost if it requires extensive review or produces unreliable decisions.

Investment decisions should compare alternatives such as building, buying, consuming a managed service, or using an open model. Criteria include strategic differentiation, data sensitivity, performance, portability, vendor concentration, skills, lifecycle cost, and exit feasibility.

7. Cloud Transformation and Migration Roadmaps

7.1 Transformation is more than migration

Migration moves workloads; transformation changes how the organization creates and governs value. A server relocation without process, skills, security, and operating-model change may reproduce old inefficiencies in a new environment.

Common migration strategies include:

• Retain: keep the workload where it is when migration value is low or constraints are significant.
• Retire: remove obsolete systems.
• Rehost: move with minimal change.
• Replatform: make limited changes to use managed capabilities.
• Refactor or rearchitect: redesign substantially for cloud-native operation.
• Repurchase: replace with a software service.
• Relocate: move a large environment with limited application change.

No single strategy is universally superior. Rehosting may reduce immediate effort but preserve technical debt. Refactoring may improve agility but require greater skills, testing, and investment.

7.2 A staged roadmap

A credible roadmap usually contains:

Stage 1—Discover: inventory applications, dependencies, owners, data classes, contracts, utilization, technical debt, and regulatory constraints.

Stage 2—Assess and prioritize: score workloads by business value, complexity, risk, readiness, and interdependency. Identify quick wins and high-risk systems requiring deeper analysis.

Stage 3—Prepare the foundation: establish identity, network connectivity, landing zones, logging, backup, security monitoring, policy-as-code, service management, and financial controls.

Stage 4—Pilot: migrate a bounded workload, test controls, measure outcomes, and refine patterns.

Stage 5—Scale migration: use repeatable waves with entry and exit criteria, automated testing, rollback plans, and stakeholder communication.

Stage 6—Transform and optimize: modernize selected systems, improve reliability and data products, optimize cost, and retire duplicate infrastructure.

Stage 7—Operate and improve: monitor business outcomes, control effectiveness, resilience, model performance, skills, and supplier risk.

Migration sequencing should consider dependencies and risk, not just technical convenience. A low-risk application may be a good pilot, while a highly interconnected regulated system may require foundation work first.

7.3 Skills and workforce planning

Cloud transformation requires more than cloud-provider certificates. A skills plan should address:

• cloud architecture and platform engineering;
• identity, security, privacy, and resilience;
• data engineering and governance;
• MLOps, model evaluation, and responsible AI;
• FinOps and commercial management;
• automation, infrastructure as code, and observability;
• product management, communication, and change leadership.

Organizations can build, buy, borrow, or partner for skills. Sustainable transformation combines formal training with supervised practice, communities of practice, internal mobility, and clear career paths. Skills plans should identify critical single points of failure and succession arrangements.

8. Illustrative Case: Northstar Health Network

This is a fictional illustrative case.

Background

Northstar Health Network operates hospitals and outpatient clinics. It wants to use cloud-based machine learning to predict appointment no-shows and prioritize follow-up for patients at risk of deterioration. Its data includes clinical records, contact information, and historical appointment data. The organization has multiple hospitals, separate IT teams, and inconsistent data definitions.

Problem

The initial proposal sends extracts to a public cloud account controlled by a data-science team. The design has no clear owner for residency, no formal model-impact assessment, excessive analyst privileges, and no documented process for patients or clinicians to challenge a prediction. Cost estimates also exclude data-transfer charges, monitoring, and human review.

Analysis

The use case has potential operational value but affects health-related decisions and vulnerable individuals. Northstar identifies several risks: unauthorized disclosure, inaccurate predictions for underrepresented populations, inappropriate clinical reliance, retention beyond purpose, and unclear accountability. The organization also discovers that backup regions and vendor support access were not included in the original residency review.

Approach and solution

Northstar establishes a federated governance model. A central platform team creates separate development, validation, and production accounts with centralized logging, managed identities, encryption, private connectivity, and regional restrictions. A data owner approves the minimum dataset, while the privacy office documents the lawful purpose, retention period, access conditions, and data-subprocessor requirements.

The AI governance committee classifies the system as high impact for internal oversight. The team records dataset lineage, evaluates performance across clinically relevant groups, tests calibration and failure modes, and defines a rule that the model supports outreach prioritization but cannot independently deny care. Clinicians receive training and can override results. A monitoring service tracks drift, missingness, subgroup performance, complaints, overrides, and incidents.

The CCoE provides reusable templates, and FinOps introduces workload tags and a monthly unit-cost review. The migration roadmap begins with a non-production pilot using de-identified data, followed by a controlled clinical trial and an independent review before production.

Outcome

The project takes longer than the original technical prototype but has clearer ownership, lower privilege exposure, auditable evidence, and a defined clinical safety boundary. The organization identifies that model accuracy alone is insufficient: operational workload, patient communication, and equity monitoring are necessary to determine whether the system creates value.

Learning points

1. Governance should be designed before production, not added after deployment.

2. Data residency includes backups, logs, support access, and derived artifacts.

3. High-impact AI requires human authority, contestability, and operational monitoring.

4. Reusable platform controls can accelerate delivery without removing accountability.

5. Business value should include safety, trust, compliance, and total lifecycle cost.

9. Challenges, Limitations, and Contemporary Developments

Cloud governance faces tensions that cannot be solved by technology alone. Strong controls may slow experimentation; weak controls create unacceptable exposure. Central teams may improve consistency but limit domain innovation. Multi-cloud strategies can reduce dependence on one provider but increase complexity, duplicated skills, and inconsistent controls.

Vendor lock-in is not only a technical issue. It may involve proprietary data formats, operational knowledge, identity integration, contractual restrictions, and specialized AI services. Exit planning should identify export formats, replacement options, data deletion procedures, portability tests, and the cost and time of transition.

Regulation of AI and digital services continues to develop across jurisdictions. Organizations should monitor changes in privacy, cybersecurity, AI, consumer protection, employment, intellectual property, and sector regulation. A legal review is necessary for particular deployments; general governance frameworks do not replace legal advice.

Contemporary practices include confidential computing, privacy-enhancing technologies, software bills of materials, continuous control monitoring, model registries, retrieval-augmented systems, smaller specialized models, and automated evaluation. These technologies may reduce particular risks, but they do not eliminate the need for accountable owners, proportional assessment, and human judgment.

Best practice is therefore adaptive governance: establish minimum non-negotiable safeguards, classify use cases by impact, automate repeatable controls, review exceptions, measure outcomes, and revise policies as evidence and technology change.

Chapter Summary

Cloud transformation is an organizational governance challenge as well as a technical migration. Effective governance assigns decision rights, establishes account and policy structures, protects identity and data, manages residency, creates auditable evidence, and aligns investment with risk and value. Compliance requires operating controls and producing evidence, not merely possessing policies or provider certifications.

AI/ML governance extends across use-case registration, data provenance, impact assessment, validation, approval, deployment, monitoring, human oversight, and retirement. A federated operating model and Cloud Center of Excellence can provide reusable safeguards while preserving business-team agility. Migration should proceed through discovery, foundation building, pilots, controlled waves, modernization, and continuous improvement. Skills, FinOps, supplier management, exit planning, and ethical accountability are essential to sustainable transformation.

Key Terms

Governance: Structures and processes used to direct, control, and oversee an organization.

Cloud governance: Decision rights, policies, controls, and assurance mechanisms for cloud use.

Shared responsibility: Division of operational security duties between provider and customer.

Landing zone: A preconfigured cloud foundation for secure and repeatable deployment.

Guardrail: A preventive or detective control that constrains cloud activity.

Least privilege: Granting only the access necessary for an authorized task.

Data residency: Geographic location in which data is stored or processed.

Data sovereignty: Legal jurisdiction and authority governing data and its processing.

Data classification: Categorization of data according to sensitivity and required protection.

Audit trail: Protected records showing actions, actors, times, authorizations, and results.

Control evidence: Documentation demonstrating that a control exists and operates.

Risk appetite: The amount and type of risk an organization is willing to accept.

AI accountability: Assignment of responsibility for AI purposes, impacts, decisions, and controls.

Model drift: Change in data or relationships that reduces model usefulness over time.

Cloud Center of Excellence: Cross-functional group that enables standardized and responsible cloud adoption.

Federated operating model: Model combining central standards with delegated domain execution.

FinOps: Collaborative practice for managing and optimizing cloud financial value.

Replatforming: Migrating a workload with limited changes to use cloud capabilities.

Policy-as-code: Expressing governance rules in machine-readable, executable form.

Human oversight: Meaningful human authority to review, intervene in, or challenge an AI system.

Review Questions

Short Answer Questions

1. Why is shared responsibility not the same as shared accountability?

2. Distinguish data residency from data sovereignty.

3. What functions are commonly performed by a Cloud Center of Excellence?

4. State two purposes of a cloud landing zone.

5. Why should AI governance include model retirement?

Long Answer Questions

1. Explain how an enterprise can design governance for accounts, identities, policies, logging, and audit evidence.

2. Discuss the relationship among data classification, residency, retention, and AI model artifacts.

3. Compare centralized, federated, and decentralized cloud operating models.

4. Describe a risk-based life-cycle governance process for a high-impact AI system.

5. Explain why cloud migration should be treated as organizational transformation rather than simple infrastructure relocation.

Analytical / Application Questions

1. A bank discovers that an AI credit-screening system is trained on data stored in one region, backed up in another, and accessed by an overseas support team. Analyze the governance issues and propose controls.

2. An organization wants to rehost 200 legacy applications within six months. Develop criteria for sequencing migration waves and identify conditions under which rehosting should be rejected.

3. A generative-AI assistant produces occasional confidential information in its responses. Design an investigation and remediation plan covering data, identity, model behavior, monitoring, human oversight, and communication.

Multiple Choice Questions with Answers

Question 1

Which statement best describes cloud governance?

A. A process limited to reducing infrastructure cost

B. A system of decision rights, policies, controls, and assurance for cloud use

C. A provider guarantee that every customer workload is compliant

D. A replacement for organizational risk management

Correct Answer: B. A system of decision rights, policies, controls, and assurance for cloud use

Question 2

Which item should normally be included in a residency analysis for an AI workload?

A. Only the primary database

B. Only the model's user interface

C. Backups, logs, support access, and derived model artifacts

D. Only data entered by administrators

Correct Answer: C. Backups, logs, support access, and derived model artifacts

Question 3

What is the principal purpose of a cloud landing zone?

A. To eliminate the need for application owners

B. To provide a preconfigured and controlled cloud foundation

C. To guarantee zero downtime for every workload

D. To replace all existing enterprise policies

Correct Answer: B. To provide a preconfigured and controlled cloud foundation

Question 4

Which operating model combines central standards with delegated execution by domain teams?

A. Centralized

B. Federated

C. Fully decentralized

D. Unmanaged

Correct Answer: B. Federated

Question 5

Which practice is most directly associated with FinOps?

A. Ignoring variable consumption because cloud is inexpensive

B. Allocating costs, forecasting usage, and optimizing consumption collaboratively

C. Prohibiting all managed services

D. Removing workload ownership from engineering teams

Correct Answer: B. Allocating costs, forecasting usage, and optimizing consumption collaboratively

Question 6

Which statement about compliance is most accurate?

A. A provider certification automatically proves customer compliance

B. Compliance requires evidence that applicable controls are implemented and operated

C. Compliance is achieved when a policy document is written

D. Compliance eliminates the need for internal audit

Correct Answer: B. Compliance requires evidence that applicable controls are implemented and operated

Question 7

What is a key requirement of meaningful human oversight for high-impact AI?

A. A person must approve every low-risk automated calculation

B. A reviewer must have sufficient information, authority, time, and competence to intervene

C. Human reviewers should be unable to override the model

D. Human involvement is needed only during model training

Correct Answer: B. A reviewer must have sufficient information, authority, time, and competence to intervene

Question 8

Which migration strategy involves substantial redesign to exploit cloud-native capabilities?

A. Retain

B. Rehost

C. Refactor or rearchitect

D. Retire

Correct Answer: C. Refactor or rearchitect

Question 9

An expected annual loss estimate uses a 0.02 probability of an incident and an impact of $500,000. Under the stated expected-loss assumptions, what is the estimate?

A. $1,000

B. $10,000

C. $25,000

D. $100,000

Correct Answer: B. $10,000

Question 10

Which activity should occur before deploying a high-impact AI use case?

A. Delete all evaluation records

B. Register the use case and perform an impact and data assessment

C. Disable audit logging to improve performance

D. Grant permanent administrator access to the data-science team

Correct Answer: B. Register the use case and perform an impact and data assessment