Responsible AI Governance and the Model Lifecycle

Introduction

Artificial intelligence governance is the organized system through which an institution directs, controls, documents, and evaluates AI across its entire lifecycle. It is not limited to checking a model after development. Governance begins when an organization frames a problem and decides whether AI is appropriate at all; it continues through data acquisition, design, testing, deployment, monitoring, modification, and retirement.

This lifecycle perspective is strategically important because AI systems can create value and risk simultaneously. A credit-scoring model may improve consistency while disadvantaging groups whose historical data reflect structural inequality. A clinical prediction system may support earlier intervention while producing unsafe recommendations when deployed in a new hospital. A generative AI assistant may increase productivity while disclosing confidential information or generating fabricated content.

Responsible AI governance therefore connects technical controls with organizational accountability. It requires clear ownership, proportionate risk controls, reliable documentation, meaningful human oversight, evidence-based approval, and continuing monitoring. Two important reference points are the NIST AI Risk Management Framework (AI RMF) and ISO/IEC 42001, an international standard for an artificial intelligence management system (AIMS). The NIST AI RMF is a voluntary, risk-management framework organized around Govern, Map, Measure, and Manage. ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an AIMS. They are complementary: NIST offers a practical risk-management vocabulary and process, while ISO/IEC 42001 provides a management-system structure suitable for organizational governance and auditing.

Learning Objectives

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

1. Explain why AI governance must cover the complete model lifecycle.
2. Design an AI inventory and classify systems using proportionate risk tiers.
3. Apply approval gates, documentation, and accountability mechanisms.
4. Relate lifecycle activities to the NIST AI RMF and ISO/IEC 42001.
5. Evaluate validation, deployment, monitoring, change management, and retirement practices.
6. Analyze the managerial, ethical, privacy, and regulatory implications of a responsible AI operating model.

1. From Model Management to AI Governance

Traditional model risk management often focused on statistical models used in finance, insurance, or forecasting. Modern AI governance is broader. It includes machine-learning models, generative AI applications, automated decision systems, retrieval systems, foundation-model integrations, rule-based components, and combinations of software and human judgment.

A model is only one component of an AI system. The system may also include:

• a business purpose and decision policy;
• input data and data pipelines;
• feature engineering and preprocessing;
• a model or foundation-model service;
• prompts, retrieval indexes, and guardrails;
• user interfaces and workflows;
• human reviewers and escalation procedures;
• vendors, cloud infrastructure, and monitoring tools; and
• affected individuals, customers, employees, or communities.

Governance must consequently address both model risk and socio-technical system risk. Model risk concerns errors, instability, bias, poor calibration, or misuse of a model. Socio-technical risk also includes inappropriate objectives, weak organizational incentives, privacy violations, automation bias, inaccessible explanations, and harmful effects that cannot be inferred from technical metrics alone.

A useful governance principle is:

The organization that benefits from an AI system must also be able to explain who is accountable for its risks, how those risks are controlled, and when the system must be suspended.

This principle rejects “accountability by algorithm.” A model cannot own a decision, interpret a legal obligation, or compensate an affected person. Human and organizational roles remain necessary even where decisions are highly automated.

2. A Lifecycle Architecture for Responsible AI

The lifecycle should be treated as a controlled sequence of decisions rather than a purely technical pipeline. The stages below may overlap and may require iteration.

Figure: A governed AI lifecycle in which decisions and controls occur at explicit approval gates.

2.1 Problem formulation

The first governance question is not “Which algorithm should we use?” but “What decision or service problem are we trying to address?” A responsible problem statement identifies the intended benefit, affected populations, decision owner, alternatives, and unacceptable outcomes.

Teams should test whether AI is necessary. A simpler rule, improved process, or additional staffing may be safer and more explainable. The problem statement should also distinguish prediction from decision. Predicting a probability does not by itself justify taking an adverse action. A decision policy determines how a prediction is used, including thresholds, human review, appeals, and exceptions.

At this stage, the organization should complete an initial impact and risk assessment. Questions include:

• Could the system affect rights, access to essential services, employment, safety, or livelihood?
• Are children, vulnerable populations, or legally protected groups affected?
• Will personal, confidential, biometric, health, or location data be processed?
• Is the proposed use compatible with the organization’s authority and stated purpose?
• What is the credible worst-case harm, not merely the average expected benefit?

A proposed system may be rejected at this stage. “No AI” is a valid governance outcome.

2.2 Data acquisition and preparation

Data governance is inseparable from AI governance. Teams should record provenance, collection purpose, consent or other legal basis where relevant, retention, access restrictions, known gaps, labeling procedures, and permitted uses. Data collected for one purpose may not automatically be appropriate for another.

Quality assessment should examine validity, completeness, accuracy, timeliness, representativeness, duplication, missingness, and measurement error. An apparently accurate data set may still encode historical discrimination or omit populations who matter to the decision.

Privacy-preserving practices may include data minimization, pseudonymization, access controls, aggregation, retention limits, secure computation, or differential privacy where appropriate. Pseudonymization reduces direct identifiability but does not make data anonymous; re-identification may remain possible when records are combined with other information.

Sensitive attributes require careful treatment. Removing a protected attribute from a training table does not necessarily remove its influence: correlated variables, geography, language, purchasing patterns, or educational history may act as proxies. Conversely, retaining sensitive attributes in a controlled validation environment may be necessary to evaluate disparate performance. Governance must distinguish operational use from protected auditing use.

2.3 Development and testing

Development documentation should identify the model type, training procedure, data versions, features, labels, hyperparameters, software dependencies, intended operating range, and known limitations. For generative systems, documentation should additionally cover the base model, prompt templates, retrieval sources, content filters, output constraints, and vendor changes.

Testing should include more than aggregate accuracy. Depending on the use case, teams may assess calibration, robustness, subgroup performance, privacy leakage, security, explainability, accessibility, and harmful content. Test data should be separated appropriately from training data. Leakage occurs when information unavailable at decision time, or information derived from the outcome, enters training and produces an unrealistically optimistic result.

2.4 Independent validation and approval

Validation is a critical challenge to the development team. It should evaluate whether the system is fit for its stated purpose, whether evidence supports performance claims, whether limitations are disclosed, and whether controls are operational. Independence does not always require a separate legal entity; it requires sufficient organizational separation, competence, authority, and freedom from inappropriate incentives.

Approval should be evidence-based. A high-risk system should not be approved merely because its average performance exceeds a benchmark. The approval record should state scope, conditions, residual risks, monitoring requirements, accountable owners, and the authority that can suspend use.

2.5 Deployment and operation

Deployment changes the risk environment. Production data may differ from development data; users may apply the system outside its intended context; vendors may update models; and affected people may react strategically. Deployment controls can include access restrictions, rate limits, human review, confidence thresholds, fallback procedures, logging, incident escalation, and user training.

Human oversight must be meaningful rather than ceremonial. A reviewer who lacks time, expertise, authority, or access to relevant information may simply approve automated outputs. Governance should specify when a person must review, what evidence they receive, when they may override the system, and how overrides are recorded.

2.6 Monitoring, change, and retirement

Monitoring should cover performance, data drift, concept drift, subgroup outcomes, privacy and security incidents, user complaints, override rates, abstention rates, and changes in the operating environment. Drift is not automatically evidence of harm, but it is a signal requiring investigation.

A change-control process should classify modifications such as data refreshes, feature changes, retraining, threshold changes, prompt changes, model-provider updates, and changes in business use. Minor changes may receive delegated approval, whereas material changes require revalidation or a new impact assessment. Version identifiers and reproducible records are essential.

Retirement is a governance stage, not an administrative afterthought. Organizations should define retirement triggers, preserve records required for accountability, revoke access, handle data according to retention policy, communicate the change, and provide a replacement or fallback where necessary. A system that is no longer accurate, supported, lawful, secure, or aligned with organizational purpose should be withdrawn even if it remains technically operational.

3. Inventories, Ownership, and Risk Tiers

An AI inventory is the authoritative register of AI systems and significant components. It should include systems developed internally, procured from vendors, embedded in enterprise software, and used informally through consumer or workplace tools.

A practical inventory record contains:

Risk tiers should be based on credible impact, not on whether the system is fashionable or technically complex. A simple rules engine used to deny essential services may be higher risk than a sophisticated forecasting model used for internal planning.

One illustrative four-tier scheme is:

The tiers are illustrative, not a substitute for applicable law or sector requirements. Risk can increase when several moderate factors combine, such as sensitive data, large scale, vulnerable subjects, opaque vendors, and irreversible decisions.

4. Documentation as an Accountability Infrastructure

Documentation is not paperwork added after innovation. It is an information architecture that allows people to understand, challenge, reproduce, operate, and retire a system.

Important artifacts include:

• Use-case or impact assessment: purpose, affected groups, benefits, harms, alternatives, legal and ethical analysis, and residual risk.
• Data documentation: provenance, collection method, permissions, representativeness, labeling, transformations, missingness, and limitations.
• Model card or system card: intended use, performance, subgroup results, limitations, out-of-scope use, and evaluation conditions.
• Technical design record: architecture, dependencies, security controls, interfaces, and failure modes.
• Validation report: methods, data separation, tests, findings, unresolved issues, and conclusion.
• Decision log: approvals, conditions, exceptions, incidents, changes, and responsible decision makers.
• Operations record: monitoring metrics, alerts, incidents, overrides, retraining, and retirement evidence.

Documentation must be audience-specific. A regulator or auditor needs traceability; an engineer needs configuration and reproducibility; a decision maker needs limitations and escalation rules; an affected person may need a clear explanation and a route to contest an outcome. A technically complete document can still fail if it is inaccessible or incomprehensible to its intended audience.

5. Mapping Governance to NIST AI RMF and ISO/IEC 42001

NIST AI RMF

The NIST AI RMF’s four functions are iterative rather than strictly sequential:

• Govern: establish policies, roles, accountability, culture, risk tolerance, and organizational processes.
• Map: establish context, intended purpose, stakeholders, impacts, assumptions, and risks.
• Measure: use appropriate qualitative and quantitative methods to assess performance, validity, reliability, fairness, privacy, security, and other characteristics.
• Manage: prioritize and respond to identified risks, including mitigation, monitoring, communication, and cessation where necessary.

The framework encourages organizations to consider trustworthy characteristics such as validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy enhancement, and fairness with harmful bias managed. These characteristics may conflict. For example, greater transparency can expose security-sensitive information, and optimizing average accuracy may worsen subgroup performance. Governance therefore requires explicit trade-off analysis rather than a claim that every desirable property can be maximized simultaneously.

ISO/IEC 42001

ISO/IEC 42001 frames AI governance as a management system. Its logic includes organizational context, leadership, planning, support, operation, performance evaluation, and continual improvement. An organization seeking conformity would need to define its AIMS, assign responsibilities, establish policies and objectives, manage risks and impacts, control operations, evaluate performance, and address nonconformities.

The standard does not guarantee that every AI output is fair or accurate. A management system can be well implemented while a particular system remains harmful if the organization’s objectives, risk assessment, controls, or evidence are inadequate. Certification, where obtained, should therefore be interpreted as evidence about a management system’s conformity—not as a blanket guarantee that all AI is trustworthy.

Complementarity

NIST AI RMF can guide the substance of risk analysis and control design, while ISO/IEC 42001 can structure responsibilities, documented processes, audits, corrective action, and continual improvement. Organizations should avoid “framework theatre,” in which terminology is adopted without authority, resources, evidence, or consequences. A useful mapping table is:

6. Metrics, Thresholds, and Evidence

No single metric establishes responsible AI. Metrics must be selected according to the decision, harm model, population, and operating context.

For a binary classifier, a confusion matrix distinguishes true positives, false positives, true negatives, and false negatives. Common measures include:

Here TP means true positives, FP false positives, TN true negatives, and FN false negatives. Precision is the proportion of predicted positives that are correct; recall is the proportion of actual positives detected. These measures apply to binary classification with defined positive and negative classes. They do not by themselves establish fairness, causality, or suitability for deployment.

A subgroup comparison may reveal materially different error rates. However, fairness criteria can conflict, especially when groups have different base rates. Therefore, governance should not select a metric mechanically. It should justify which errors matter, who bears them, what evidence is adequate, and what compensating controls exist.

For probabilistic predictions, calibration is relevant: among cases assigned a probability near 0.7, approximately 70% should have the outcome in a sufficiently large and appropriate reference population. Calibration can vary across groups and can degrade when the environment changes. Monitoring must therefore define reference populations, sampling procedures, alert thresholds, statistical uncertainty, and actions after an alert.

Quantitative evidence should be accompanied by qualitative evidence, including user research, affected-person consultation, red-team testing, complaint analysis, and review of plausible worst-case scenarios. A low incident rate may reflect under-reporting rather than low harm.

7. Governance Gates and the Three Lines of Responsibility

A mature operating model places explicit gates at consequential points:

1. Intake gate: Is the problem legitimate, necessary, and sufficiently specified?
2. Data gate: Are collection, use, quality, privacy, and representativeness acceptable?
3. Development gate: Has the system been built and tested within approved scope?
4. Validation gate: Has an independent party challenged the evidence and limitations?
5. Deployment gate: Are people, controls, monitoring, appeals, and incident procedures ready?
6. Change gate: Does a modification require partial or complete reapproval?
7. Retirement gate: Can the system be withdrawn safely with records and fallback arrangements?

A three-lines model can clarify accountability. The first line—product, business, and engineering teams—owns day-to-day risks and controls. The second line—risk, privacy, legal, compliance, and responsible-AI functions—sets standards, challenges decisions, and advises. The third line—internal audit or an equivalent independent assurance function—evaluates whether governance is designed and operating effectively. Boards or executive committees provide strategic oversight and risk appetite; they should not delegate accountability merely because a system is technically complex.

8. Illustrative Case: Automated Benefits-Triage System

Background

A public agency, Northbridge Services, receives a large volume of applications for temporary income support. It proposes an AI system to prioritize applications for staff review. The system would estimate the likelihood that an application is incomplete or requires urgent human attention.

This is a fictional illustrative case.

Problem

The initial proposal describes the system as an “eligibility model,” although the agency intends only to prioritize review. The training data contain historical case outcomes, processing times, postal codes, language preferences, and previous interactions. Some communities have historically experienced longer processing times and more requests for additional documentation.

The governance team identifies risks: proxy discrimination, automation bias, privacy concerns, feedback loops, and the possibility that prioritization becomes an unofficial denial mechanism.

Analysis

At the problem-formulation gate, the agency rewrites the purpose: the system may recommend review priority but may not determine eligibility, terminate benefits, or suppress an application. The agency considers a non-AI alternative—staff-defined urgency rules—and concludes that a constrained model may offer operational value only if human review remains mandatory.

At the data gate, postal code and historical processing time are removed from the primary model because they may encode institutional disadvantage. A controlled fairness evaluation retains relevant demographic information where lawful and appropriate. Data retention and access controls are specified, and the agency documents missingness and language coverage.

At the development gate, the team evaluates false negatives because failure to prioritize an urgent case may cause harm. It also measures performance across language groups, disability-related accommodation requests, and other relevant populations. The agency does not treat aggregate accuracy as sufficient evidence.

At validation, an independent team discovers that the model’s confidence is overstated for applications translated through a particular workflow. The system is modified to abstain and route those cases to specialist review. The validation report records the limitation rather than hiding it.

Approach and solution

Northbridge deploys a limited pilot with:

• a clear notice that the tool supports—not replaces—staff judgment;
• mandatory review for high-impact cases and all low-confidence outputs;
• an appeal and correction process for applicants;
• dashboards for subgroup error rates, queue effects, complaints, and overrides;
• weekly incident review during the pilot;
• a suspension trigger if material disparities or data-integrity failures appear; and
• a change-control rule requiring revalidation after feature, threshold, vendor, or workflow changes.

Outcome

The pilot reduces average routing time, but it also reveals a higher false-negative rate for applications submitted in less-supported languages. The agency does not simply celebrate the average improvement. It expands language support, changes the routing policy, and continues the pilot only after evidence shows improved performance. The system remains prohibited from making eligibility decisions.

Learning points

The case illustrates that responsible AI governance changes the problem definition, not just the model. It also shows why historical outcomes require interpretation, why human oversight must have real authority, why subgroup monitoring must be operational, and why a successful pilot does not remove the need for continuing governance.

9. Challenges and Limitations

First, governance can become a bottleneck if approval processes are identical for every use case. Proportionate tiers, delegated authority, standard templates, and reusable controls can reduce unnecessary delay without weakening oversight.

Second, vendors may provide insufficient information about training data, model updates, or evaluation results. Contracts should address documentation, audit rights, incident notification, service changes, data use, security, subcontractors, retention, exit, and responsibility allocation. A vendor’s assurance does not eliminate the deployer’s accountability for its use.

Third, explainability has limits. A technically interpretable model may still be difficult for an affected person to understand, while a complex model may provide useful local explanations that should not be mistaken for causal proof. Explanations should be matched to the decision, audience, and remedy available.

Fourth, fairness is context-dependent. Statistical parity in one setting may be inappropriate in another, and fairness metrics cannot resolve political or moral disagreements about allocation. Organizations must disclose value choices rather than presenting a metric as an objective answer.

Fifth, generative AI introduces nondeterminism, prompt sensitivity, fabricated outputs, copyright and confidentiality concerns, and rapid provider changes. Retrieval grounding, output review, logging, restricted use cases, and user training reduce but do not eliminate these risks.

Finally, governance itself can fail through weak incentives. If teams are rewarded only for speed or deployment count, risk documentation becomes performative. Senior leadership must resource independent review, protect escalation, and treat suspension as a legitimate control rather than a career failure.

10. Contemporary Strategic Directions and Best Practices

Organizations are increasingly moving toward integrated AI inventories, machine-readable model metadata, continuous evaluation, privacy-enhancing technologies, and evidence pipelines that connect code, data, tests, approvals, and production monitoring. These practices can improve traceability, but automation of governance is not a substitute for judgment.

Strong practice generally includes:

• a single authoritative inventory with accountable owners;
• risk tiers linked to specific controls and approval authority;
• documented consideration of non-AI alternatives;
• privacy, security, accessibility, and human-rights review early in design;
• independent validation proportionate to impact;
• performance and harm metrics defined before deployment;
• monitoring that triggers investigation and action, not merely dashboards;
• meaningful human review, appeal, correction, and incident response;
• contractual controls for third-party and foundation-model dependencies;
• versioned documentation and reproducible change records;
• periodic management review and internal audit; and
• planned retirement, fallback, and record preservation.

The strategic objective is not to remove all uncertainty. That is impossible in complex socio-technical systems. The objective is to make uncertainty visible, allocate responsibility, reduce preventable harm, and ensure that the organization can intervene when evidence changes.

Chapter Summary

Responsible AI governance covers the complete lifecycle from problem formulation and data acquisition to development, validation, deployment, monitoring, change, and retirement. AI systems must be governed as socio-technical arrangements rather than isolated algorithms. Inventories establish visibility; risk tiers make controls proportionate; documentation creates traceability; approval gates convert principles into decisions; and monitoring keeps governance active after deployment.

The NIST AI RMF organizes risk work through Govern, Map, Measure, and Manage. ISO/IEC 42001 provides a management-system structure for leadership, planning, operation, performance evaluation, corrective action, and continual improvement. Neither framework guarantees ethical outcomes automatically. Their value depends on authority, evidence, competence, independence, and willingness to restrict or retire harmful systems.

A mature organization evaluates technical performance alongside privacy, security, fairness, explainability, accessibility, human oversight, user experience, and real-world impacts. It treats vendors, model updates, feedback loops, and changing populations as lifecycle risks. Ultimately, responsible AI is a strategic capability: it enables innovation while preserving accountability, trust, resilience, and the ability to stop when a system no longer deserves to operate.

Key Terms

AI inventory: An authoritative register of AI systems, owners, purposes, dependencies, risks, and lifecycle status.

AI management system (AIMS): An organizational management system for governing AI-related policies, processes, risks, and continual improvement.

Approval gate: A formal decision point at which evidence is reviewed before a lifecycle stage proceeds.

Automation bias: The tendency to give excessive weight to an automated recommendation.

Calibration: The correspondence between predicted probabilities and observed frequencies.

Concept drift: A change in the relationship between inputs and the outcome being predicted.

Data drift: A change in the distribution or characteristics of input data.

Data provenance: Information about the origin, collection, transformation, and use of data.

Independent validation: Critical evaluation by a party sufficiently separate from development incentives.

Model card: Documentation describing a model’s intended use, performance, limitations, and evaluation conditions.

Model lifecycle: The stages through which an AI model or system is conceived, built, used, monitored, changed, and retired.

NIST AI RMF: A voluntary risk-management framework organized around Govern, Map, Measure, and Manage.

Pseudonymization: Replacing direct identifiers while recognizing that re-identification may remain possible.

Residual risk: Risk remaining after controls and mitigations have been applied.

Risk tier: A classification that links an AI system’s potential impact to proportionate governance controls.

Socio-technical system: A system consisting of technology, data, people, organizational processes, and institutional context.

System card: Documentation covering an AI system’s components, uses, risks, evaluations, and limitations.

Use-case assessment: A structured analysis of purpose, affected parties, benefits, harms, alternatives, and controls.

Review Questions

Short Answer Questions

1. Why must AI governance begin before model development?
2. What information should an AI inventory contain?
3. Distinguish data drift from concept drift.
4. What are the four functions of the NIST AI RMF?
5. Why does ISO/IEC 42001 certification not guarantee that every AI output is fair?

Long Answer Questions

1. Explain how approval gates can be designed across the AI lifecycle. Include the evidence required at each major gate.
2. Compare the purposes and complementarities of the NIST AI RMF and ISO/IEC 42001.
3. Discuss why human oversight can become ineffective and identify controls that make it meaningful.
4. Analyze the role of documentation in accountability, auditability, privacy, and change management.
5. Explain why aggregate model performance is insufficient for responsible deployment in high-impact settings.

Analytical / Application Questions

1. Design a four-tier risk-classification scheme for a university that uses AI in admissions, teaching, student support, and administration. Justify the controls assigned to each tier.
2. A vendor changes the foundation model underlying an organization’s customer-service assistant without changing its interface. Determine whether revalidation is required and specify the evidence and decision process you would use.
3. Using the Northbridge Services case, propose a monitoring dashboard and define the actions that should follow three possible findings: subgroup performance deterioration, a privacy incident, and a high override rate.

Selected References

National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST, 2023.

International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001: Information Technology—Artificial Intelligence—Management System.

National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST, 2024.

OECD. OECD Recommendation on Artificial Intelligence. OECD Legal Instruments.

Multiple Choice Questions with Answers

Question 1

Which activity belongs most directly to the NIST AI RMF Govern function?

A. Establishing organizational roles, policies, and accountability

B. Calculating a model’s precision on a test set

C. Removing duplicate records from a training data set

D. Archiving a retired model’s source code

Correct Answer: A. Establishing organizational roles, policies, and accountability

Question 2

What is the primary purpose of an AI inventory?

A. To replace independent validation

B. To provide authoritative visibility into systems, owners, purposes, and risks

C. To guarantee that all models are unbiased

D. To eliminate the need for monitoring

Correct Answer: B. To provide authoritative visibility into systems, owners, purposes, and risks

Question 3

A model produces 80 true positives and 20 false positives. What is its precision?

A. 20%

B. 40%

C. 80%

D. 100%

Correct Answer: C. 80%

Question 4

Which statement about pseudonymization is correct?

A. It always makes data anonymous

B. It replaces direct identifiers but re-identification may remain possible

C. It eliminates the need for access controls

D. It prevents all privacy attacks

Correct Answer: B. It replaces direct identifiers but re-identification may remain possible

Question 5

Why is independent validation important?

A. It ensures that developers control the approval decision

B. It provides a critical challenge to development evidence and limitations

C. It allows monitoring to be skipped after deployment

D. It guarantees legal compliance in every jurisdiction

Correct Answer: B. It provides a critical challenge to development evidence and limitations

Question 6

Which event most clearly requires review under change management?

A. A documented correction to a typographical error in an internal report

B. A material change to a model provider or decision threshold

C. A routine password change by an administrator

D. A user reading the system card

Correct Answer: B. A material change to a model provider or decision threshold

Question 7

Which NIST AI RMF function focuses on understanding context, stakeholders, intended purpose, and impacts?

A. Govern

B. Map

C. Measure

D. Manage

Correct Answer: B. Map

Question 8

What is the main limitation of relying only on aggregate accuracy?

A. Accuracy cannot be calculated for any classifier

B. It may conceal subgroup disparities and serious errors affecting particular populations

C. It is relevant only to unsupervised learning

D. It automatically measures privacy risk

Correct Answer: B. It may conceal subgroup disparities and serious errors affecting particular populations

Question 9

Which is an appropriate retirement activity?

A. Continuing operation without an owner

B. Revoking access, preserving necessary records, and implementing a safe fallback

C. Deleting all documentation immediately

D. Ignoring incidents because the system is no longer being improved

Correct Answer: B. Revoking access, preserving necessary records, and implementing a safe fallback

Question 10

What does ISO/IEC 42001 primarily provide?

A. A guarantee that every model prediction is correct

B. A management-system structure for governing AI and continually improving controls

C. A single fairness metric for all applications

D. A replacement for applicable law

Correct Answer: B. A management-system structure for governing AI and continually improving controls