Risk, Controls, Audit, and Incident ResponseIntroductionData governance, privacy, and artificial-intelligence ethics become operationally meaningful only when an organization can identify risk, implement controls, produce evidence, detect failure, and respond effectively. Policies alone do not guarantee responsible practice. A mature governance system connects business objectives with risk assessment, control design, assurance, monitoring, incident response, and corrective action. This chapter examines that operational chain. It focuses on how organizations can construct risk registers and control libraries; define key risk indicators (KRIs) and key performance indicators (KPIs); validate analytical and AI models; conduct algorithmic audits; preserve compliance evidence; monitor systems continuously; and manage privacy breaches and AI incidents. The emphasis is managerial and technical: governance professionals must understand both the institutional decision process and the data, model, and system properties that create exposure. Learning ObjectivesBy the end of this chapter, readers should be able to: - Construct and maintain a data, privacy, and AI risk register.
- Design preventive, detective, corrective, and compensating controls.
- Select useful KRIs, KPIs, and control-performance indicators.
- Explain model validation, algorithmic auditing, and limitations of fairness metrics.
- Assemble defensible compliance evidence and audit trails.
- Design continuous-monitoring and escalation processes.
- Distinguish privacy breaches, cybersecurity incidents, and AI incidents.
- Develop response, remediation, regulatory-reporting, and lessons-learned processes.
1. From Governance Intent to Operational ControlRisk is the effect of uncertainty on objectives. In governance practice, risk is not limited to financial loss. It may involve unlawful processing, discrimination, unsafe automated decisions, loss of confidentiality, inaccurate records, poor explainability, contractual breach, reputational damage, or inability to demonstrate compliance. A useful governance chain is: Objective → asset and process → threat or failure mode → risk → control → evidence → monitoring → response and improvement. For example, an organization may have the objective of making rapid and accurate credit decisions. Relevant assets include applicant data, training data, source code, model parameters, and decision records. Failure modes may include unauthorized data use, biased training data, model drift, or inaccessible explanations. Controls may include data minimization, access restrictions, validation, threshold monitoring, human review, and retention schedules. Risk management should be integrated with enterprise risk management, information security, privacy management, model risk management, internal audit, procurement, and business continuity. A separate “AI ethics program” that has no authority over deployment decisions is unlikely to be effective. Risk taxonomyA taxonomy provides a common vocabulary and supports consistent aggregation. A practical taxonomy may include: | Risk category | Typical examples | Primary owners |
|---|
| Privacy | Excessive collection, unlawful disclosure, re-identification | Privacy officer, process owner | | Security | Credential compromise, ransomware, unauthorized access | CISO, technology owner | | Data quality | Missing, inaccurate, stale, or duplicated data | Data owner, data steward | | Model | Drift, instability, poor calibration, invalid assumptions | Model owner, validation function | | Fairness and ethics | Disparate impact, exclusion, manipulation, opacity | Product owner, ethics committee | | Compliance | Failure to meet legal, regulatory, or contractual duties | Compliance and legal | | Operational | Process failure, unavailable service, inadequate staffing | Operations owner | | Third-party | Vendor misuse, weak controls, opaque subcontracting | Procurement and vendor owner |
A taxonomy should be tailored to the organization. Excessive categories create administrative burden; too few conceal important differences in treatment and accountability. 2. Building a Risk RegisterA risk register is a controlled record of identified risks, their causes, consequences, ratings, owners, controls, treatment decisions, and review status. It is not merely a list of fears. Each entry should support a decision. A useful risk statement follows this pattern: Because of [cause or threat], [event] may occur, resulting in [consequence] for [objective]. For instance: “Because training data exclude applicants with unstable employment histories, the lending model may systematically under-score such applicants, resulting in unequal access to credit and regulatory exposure.” This formulation separates causes, events, and consequences, which improves control design. Inherent and residual riskInherent risk is exposure before considering controls. Residual risk is exposure after controls operate. A simple ordinal matrix may rate likelihood and impact from 1 to 5, with a nominal score: R = L × I Here, R is the risk score, L is likelihood, and I is impact. The score is dimensionless and is appropriate only as a prioritization aid, not as a precise probability of loss. The method assumes that the organization has defined consistent scales and accepts the limitations of multiplying ordinal categories. A more quantitative expected-loss representation is: EL = p × C where EL is expected loss per defined period, p is the probability of the adverse event in that period, and C is the monetary consequence if it occurs. This formulation assumes that the probability and consequence are sufficiently estimable and that monetary valuation is meaningful. Privacy, dignity, and discrimination harms may not be reducible to money; therefore, qualitative impact analysis remains necessary. Risk registers should normally record: - risk identification number and title;
- objective and affected process;
- cause, event, consequence, and risk category;
- affected data subjects, systems, models, or jurisdictions;
- inherent and residual ratings;
- existing controls and control owners;
- treatment decision and target date;
- risk acceptance authority;
- indicators, review frequency, and escalation threshold;
- evidence links and change history.
Risk acceptance must be explicit. A business owner should not silently accept a risk that requires legal, privacy, safety, or board-level approval. Risk ratings should be revisited when the system, data, vendor, law, threat environment, or intended use changes. 3. Control Libraries and Control DesignA control is a policy, procedure, technical mechanism, governance activity, or combination intended to modify risk. A control library is a structured catalogue of control objectives, activities, owners, evidence, frequency, and testing methods. Control types- Preventive controls reduce the likelihood of an event: role-based access, input validation, approval gates, encryption, and data minimization.
- Detective controls identify an event or deviation: access-log review, anomaly detection, bias monitoring, and reconciliation.
- Corrective controls restore an acceptable state: credential revocation, model rollback, deletion of improperly retained data, and remediation plans.
- Directive controls establish expected behavior: policies, standards, training, and contractual clauses.
- Compensating controls provide alternative protection when a primary control is unavailable or unsuitable.
Controls should be mapped to risks rather than collected indiscriminately. A control objective states the desired condition, while the control activity specifies how it is achieved. For example: | Risk | Control objective | Control activity | Evidence | Test |
|---|
| Unauthorized model-data access | Only authorized personnel access sensitive data | Quarterly access recertification and least-privilege roles | Approval records, access report | Inspect sample and reperform | | Undetected model drift | Material performance degradation is detected promptly | Monthly monitoring against approved thresholds | Monitoring dashboard, alerts | Recalculate metrics | | Excessive retention | Personal data are deleted when no longer needed | Automated retention rules with exception review | Deletion logs, exception register | Trace sample records |
Control design must address the “who, what, when, how, and proof” questions. A control without evidence may be performed but is difficult to defend. A control that produces evidence without a responsible owner is equally weak. Control effectivenessDesign effectiveness asks whether a control, if performed as intended, could address the risk. Operating effectiveness asks whether it actually operated consistently during the review period. A control can be well designed but poorly executed, or regularly executed but incapable of addressing the stated risk. Control testing should define population, sample or full-population method, test steps, exceptions, severity, and conclusion. Sampling is appropriate only when the population and selection method support a reasonable conclusion. Automated controls may be tested through configuration review, code inspection, change-management records, and transaction reperformance. 4. KRIs, KPIs, and Continuous MonitoringA KPI measures performance against an objective. A KRI signals increasing exposure or the likelihood that an objective may be threatened. A control-performance indicator measures whether a control is operating as intended. The same measure can serve different purposes depending on context. Examples include: | Measure | Type | Interpretation |
|---|
| Percentage of subject-access requests completed within required time | KPI/compliance indicator | Service and legal timeliness | | Number of privileged accounts without current approval | KRI | Access-governance exposure | | Model false-negative rate by protected group | KRI | Potential unequal error burden | | Percentage of scheduled access reviews completed | Control indicator | Control execution | | Median time to contain a privacy incident | KPI | Response effectiveness |
A good indicator has a clear numerator, denominator, population, time period, owner, data source, threshold, and action. “Data quality is good” is not an indicator. “Percentage of customer records with valid country codes, measured weekly, with escalation below 99.5%” is more actionable. Thresholds should distinguish normal variation from meaningful deterioration. Three levels are common: green for acceptable conditions, amber for management attention, and red for escalation or intervention. Thresholds must not be chosen solely because they are easy to achieve. They should reflect legal requirements, risk appetite, historical variability, service commitments, and potential harm. Monitoring can be rule-based, statistical, or event-driven. A simple rate is: q = x ÷ n where x is the number of observed events and n is the relevant population. If 24 of 2,000 decisions are appealed, q = 24 ÷ 2,000 = 0.012, or 1.2%. Interpretation requires a defined appeal population, consistent coding, and awareness that a low rate may reflect under-reporting rather than good performance. Continuous monitoring does not mean that every activity is observed continuously. It means monitoring is proportionate, timely, automated where useful, and connected to action. Alerts without triage capacity generate alert fatigue and may reduce rather than increase control effectiveness. 5. Model Validation and Algorithmic AuditModel validation is an independent, systematic assessment of whether a model is fit for its intended purpose and used within approved boundaries. It should occur before deployment and at appropriate intervals thereafter. Validation is not the same as model development: the validator must challenge data, assumptions, methods, implementation, performance, and limitations. A validation framework commonly examines: - Conceptual soundness: Is the problem definition appropriate? Are target, features, assumptions, and intended use justified?
- Data quality and representativeness: Are data accurate, complete, relevant, lawful to use, and sufficiently representative of the deployment population?
- Development methodology: Are preprocessing, feature engineering, training, tuning, and testing reproducible and appropriately separated?
- Performance: Does the model achieve suitable accuracy, calibration, ranking, or error rates on independent data?
- Robustness: Does performance remain acceptable under plausible changes, missingness, adversarial behavior, and distribution shift?
- Fairness and explainability: Are impacts, errors, and explanations evaluated for relevant groups and decision contexts?
- Implementation and governance: Does production code match the approved model? Are access, change control, monitoring, and retirement arrangements adequate?
For binary classification, accuracy is: Accuracy = (TP + TN) ÷ (TP + TN + FP + FN) Here, TP and TN are true positives and true negatives, while FP and FN are false positives and false negatives. Accuracy assumes that the classes and error costs make this aggregate meaningful. It can be misleading when outcomes are imbalanced. Recall, or true-positive rate, is: Recall = TP ÷ (TP + FN) Precision is: Precision = TP ÷ (TP + FP) These metrics answer different questions. In fraud detection, recall may matter because missed fraud is costly; in customer intervention, precision may matter because unnecessary interventions burden legitimate customers. No metric is universally best. Fairness assessment should be context-sensitive. For example, equal opportunity compares true-positive rates across groups, while demographic parity compares positive-decision rates. These objectives can conflict with one another, particularly when groups have different base rates. Statistical parity alone cannot establish fairness, and group labels may be legally or ethically sensitive. Auditors should examine outcome distributions, error burdens, data generation processes, explanations, human overrides, and potential disparate effects. An algorithmic audit should establish scope, system inventory, decision context, affected populations, audit criteria, evidence sources, testing methods, findings, and remediation ownership. Audits may include documentation review, code and configuration inspection, data-quality testing, performance re-evaluation, subgroup analysis, interviews, user research, and adversarial testing. Audit conclusions should state limitations, confidence, unresolved uncertainties, and whether the system is approved, conditionally approved, suspended, or prohibited. 6. Compliance Evidence and AuditabilityCompliance evidence is information demonstrating that a requirement was understood, a control was designed, and an activity operated. Evidence must be authentic, complete, attributable, time-stamped, protected from inappropriate alteration, and retained for the required period. A defensible evidence structure includes: - requirement or control identifier;
- responsible owner and approver;
- system and period covered;
- source data and extraction method;
- action performed and result;
- exceptions and resolution;
- version or configuration reference;
- review and approval record;
- retention and access classification.
Examples include data inventories, processing records, consent or legal-basis records, access reviews, deletion logs, model cards, validation reports, impact assessments, vendor attestations, incident timelines, training records, and change tickets. Evidence should be generated as part of ordinary operations rather than reconstructed immediately before an audit. However, evidence collection must respect privacy and security. Storing copies of sensitive data merely to prove compliance can create additional exposure. Organizations should prefer metadata, immutable logs, controlled extracts, and minimized evidence where these adequately support assurance. Internal audit provides independent assurance and should preserve independence from management ownership of controls. External assurance, regulatory inspection, and certification reviews have different scopes and levels of reliance. Passing an audit does not prove that all risks are absent; it indicates that defined criteria were assessed within defined limitations. 7. Breach Response and AI Incident ManagementA privacy breach is generally an incident involving unauthorized or accidental destruction, loss, alteration, disclosure, or access to personal data. A cybersecurity incident may affect systems or information without involving personal data. An AI incident includes harm or material near-harm arising from an AI system, such as discriminatory decisions, unsafe recommendations, fabricated information used in consequential work, uncontrolled autonomous action, model leakage, or failure to honor restrictions. The categories overlap but are not identical. An AI model exposing personal information may be both an AI incident and a privacy breach. A denial-of-service attack on a non-personal analytics dashboard may be a cybersecurity incident but not a privacy breach or AI incident. A response lifecycle is: - Prepare: define roles, contacts, playbooks, logging, exercises, legal escalation, and decision authority.
- Detect and report: receive signals from monitoring, employees, customers, vendors, or regulators; preserve initial facts.
- Triage: determine credibility, scope, affected systems and people, severity, ongoing exposure, and reporting implications.
- Contain: isolate accounts, systems, data flows, model endpoints, or features while preserving evidence.
- Analyze: establish timeline, root causes, affected records, model behavior, control failures, and uncertainty.
- Notify and coordinate: involve legal, privacy, security, communications, senior management, affected parties, insurers, and regulators as required.
- Eradicate and recover: remove malicious access or unsafe functionality, restore trusted operations, validate recovery, and monitor for recurrence.
- Remediate and learn: address root causes, update controls, document decisions, and verify closure.
Incident severity should consider actual and potential harm, number and vulnerability of affected people, sensitivity of data, duration, reversibility, geographic scope, regulatory duties, safety implications, and whether the incident is ongoing. Near misses deserve analysis because they reveal control weakness before harm becomes substantial. AI-specific response questionsDuring an AI incident, responders should ask: - What model, version, prompt, tool, dataset, or configuration was involved?
- Was the output advisory, operational, or used in a high-impact decision?
- Did a human review the output, and was that review meaningful?
- Which individuals or groups were affected?
- Can the decision be reversed, corrected, or reprocessed?
- Did the system disclose confidential or personal information?
- Are logs sufficient to reproduce the output and decision path?
- Should the model, feature, or deployment be suspended?
A model rollback is not automatically a solution. The prior model may contain the same defect, and rollback can reintroduce older risks. Recovery requires validation of the proposed replacement and communication to affected stakeholders. Regulatory reporting must be handled by authorized personnel using current jurisdiction-specific requirements. Obligations differ according to sector, location, type of data, severity, and role in the processing relationship. Organizations should maintain a legal and regulatory obligations register rather than rely on generic time periods. Reports should be accurate, timely, appropriately cautious, and updated when material facts change. Concealing uncertainty or speculating beyond verified evidence can damage credibility. 8. Remediation and Root-Cause AnalysisRemediation should address more than the immediate symptom. A useful distinction is: - Correction: fixes the immediate instance, such as reversing an incorrect decision.
- Containment: limits continuing exposure, such as disabling an endpoint.
- Corrective action: addresses the control or process failure.
- Preventive improvement: reduces the probability of similar failures elsewhere.
Root-cause analysis methods include the “five whys,” fault-tree analysis, causal diagrams, control-gap analysis, and barrier analysis. The objective is not to assign blame but to identify why the event was possible, why it was not detected earlier, and why existing escalation did not work. Every remediation action should have an owner, due date, priority, dependency, success criterion, evidence requirement, and independent closure review. “Provide more training” is weak unless the organization defines the behavior to be changed and how improvement will be measured. Stronger action might be: “Require documented privacy review before production access to customer-level data; test 20 deployments after implementation; achieve 100% completion for two consecutive quarters.” 9. Illustrative Case: Automated Benefits Eligibility ScreeningBackgroundA public-service agency uses a machine-learning model to prioritize applications for manual review. The model does not formally deny benefits, but applications classified as low priority experience longer processing times. The model uses historical applications, employment data, address information, and prior interactions. ProblemAfter deployment, community organizations report that applicants from several rural areas experience unusually long delays. A monitoring dashboard shows overall accuracy within target, but subgroup-level recall is substantially lower. An analyst also discovers that a vendor-supplied geographic feature is updated irregularly. AnalysisThe risk register identifies potential data-quality, fairness, privacy, vendor, and operational risks. The algorithmic audit finds that the development sample underrepresents rural applicants and that the geographic feature functions partly as a proxy for service availability and socioeconomic conditions. The agency’s control library contains overall accuracy monitoring but no subgroup error monitoring. Access logs are adequate, but model-version evidence is incomplete. The incident team classifies the matter as an AI fairness and service-equity incident, with possible legal implications. It is not initially classified as a confidentiality breach because there is no evidence of unauthorized disclosure. The team preserves model outputs, freezes the current version, informs legal and senior management, and begins manual review of affected applications. Approach and solutionThe agency takes five actions: - It suspends automated prioritization for affected regions and applies a neutral queueing rule while investigation continues.
- It performs a retrospective review and corrects delayed cases.
- It removes the unstable feature, retrains the model using a more representative sample, and conducts independent validation.
- It adds subgroup performance, queue-delay, data freshness, and manual-override indicators to continuous monitoring.
- It strengthens vendor clauses, model-version controls, evidence retention, and pre-deployment impact assessment.
OutcomeThe revised system is approved conditionally. It may prioritize work only when subgroup performance remains within defined limits and when manual review capacity is available. A quarterly governance committee reviews fairness, operational effects, complaints, and changes in the data-generating process. Learning pointsOverall accuracy concealed unequal service impact. A feature can create fairness risk even when it is not explicitly protected data. A model incident may concern process outcomes rather than erroneous predictions alone. Finally, remediation requires operational correction, technical change, governance improvement, and evidence that the changes work. 10. Challenges and LimitationsRisk scoring can create false precision, especially when ordinal ratings are multiplied. Metrics can be gamed, and thresholds may encourage teams to optimize measured indicators while neglecting unmeasured harms. Fairness metrics can conflict and may be unstable for small populations. Monitoring may detect drift without explaining its cause. Automated alerts can overwhelm responders. Audit evidence can be complete yet misleading if the wrong population or time period was tested. There are also structural limitations. Some harms are difficult to quantify or reverse. Affected people may not know that an automated system influenced them. Privacy-preserving analysis can reduce the granularity available for audit, while detailed audit logs can themselves become sensitive records. Independent assurance can be weakened by limited expertise, organizational pressure, vendor opacity, or insufficient access to source data and code. These limitations support a layered approach: quantitative metrics plus qualitative investigation; automated monitoring plus human judgment; technical controls plus organizational accountability; and formal assurance plus engagement with affected stakeholders. 11. Contemporary Developments and Best PracticesGenerative AI increases the importance of prompt and output logging, retrieval-source validation, tool-use restrictions, data-loss prevention, evaluation of hallucination and refusal behavior, and clear human accountability. AI supply chains now include foundation-model providers, fine-tuning services, data brokers, software libraries, cloud platforms, and downstream integrators. Governance must therefore examine inherited risks and contractual visibility, not only internally developed code. Effective practice includes: - maintain a complete inventory of data processing, models, vendors, and system dependencies;
- link every material risk to an accountable owner and one or more controls;
- distinguish design effectiveness from operating effectiveness;
- validate models independently before deployment and after material change;
- monitor subgroup outcomes, data quality, drift, overrides, complaints, and incidents;
- preserve reproducible, privacy-conscious evidence;
- test incident playbooks through exercises and near-miss analysis;
- predefine suspension, rollback, notification, and risk-acceptance authority;
- involve legal, privacy, security, domain, technical, and affected-user perspectives;
- treat remediation as complete only after effectiveness is demonstrated.
Chapter SummaryOperational governance converts principles into accountable practice. Risk registers describe causes, events, consequences, controls, owners, and treatment decisions. Control libraries organize preventive, detective, corrective, directive, and compensating mechanisms and make their evidence requirements explicit. KRIs, KPIs, and control indicators support proportionate monitoring, but metrics require clear definitions and should not be treated as complete representations of harm. Model validation evaluates conceptual soundness, data, methodology, performance, robustness, fairness, explainability, implementation, and governance. Algorithmic audits must state scope and limitations and should examine real-world effects rather than accuracy alone. Compliance evidence must be authentic, attributable, secure, and generated through ordinary operations. Privacy breaches, cybersecurity incidents, and AI incidents overlap but require careful classification. Effective response includes preparation, detection, triage, containment, analysis, notification, recovery, remediation, and learning. AI-specific response requires attention to model versions, outputs, human oversight, reversibility, and affected groups. Mature organizations use root-cause analysis, independent closure review, continuous monitoring, exercises, and evidence-based improvement to make governance durable. Key TermsRisk: The effect of uncertainty on objectives. Risk register: A controlled record of risks, ratings, owners, controls, and treatments. Inherent risk: Exposure before considering controls. Residual risk: Exposure remaining after controls operate. Control: A measure intended to modify risk. Preventive control: A control that reduces the likelihood of an adverse event. Detective control: A control that identifies an event or deviation. Corrective control: A control that restores an acceptable condition. KPI: A measure of performance against an objective. KRI: An indicator of increasing exposure or threatened objectives. Model validation: Independent assessment of a model’s fitness, limitations, and controls. Algorithmic audit: A structured examination of an algorithmic system and its effects. Model drift: Change in data, relationships, or performance after deployment. Compliance evidence: Records demonstrating that requirements and controls were addressed. Privacy breach: Unauthorized or accidental loss, alteration, disclosure, or access involving personal data. AI incident: Harm or material near-harm arising from an AI system. Containment: Action that limits continuing exposure during an incident. Remediation: Corrective action intended to address immediate and underlying causes. Risk acceptance: An authorized decision to tolerate specified residual risk. Near miss: An event that could have caused harm but did not, or was detected before material impact. Review QuestionsShort Answer Questions- What information should a well-constructed risk register contain?
- Distinguish preventive, detective, and corrective controls.
- Why is overall model accuracy insufficient for an algorithmic audit?
- What is the difference between a KPI and a KRI?
- Why must compliance evidence be attributable and time-stamped?
Long Answer Questions- Explain how an organization can connect business objectives, risk registers, control libraries, monitoring, and incident response.
- Discuss the principal stages of model validation and explain why independent challenge is important.
- Compare privacy-breach response with AI-incident response, identifying where the processes overlap and where they differ.
- Evaluate the strengths and limitations of quantitative risk scoring using R = L × I.
- Explain how root-cause analysis and remediation closure can prevent recurrence rather than merely correct an individual incident.
Analytical / Application Questions- A model has an overall accuracy of 94%, but its false-negative rate is 8% for one group and 22% for another. Design an audit plan and recommend governance actions.
- A company discovers that a vendor retained customer data beyond the contractual period. Construct the risk-register entry, identify controls and evidence, and outline the incident-response sequence.
- Design a monitoring dashboard for a generative-AI customer-service assistant. Specify at least four indicators, their owners, escalation thresholds, and the actions triggered by a red status.
Multiple Choice Questions with AnswersQuestion 1Which statement best distinguishes inherent risk from residual risk? A. Inherent risk is measured only after an incident, while residual risk is measured before it. B. Inherent risk exists before controls are considered, while residual risk remains after controls operate. C. Inherent risk applies only to privacy, while residual risk applies only to security. D. Inherent risk is always quantitative, while residual risk is always qualitative. Correct Answer: B. Inherent risk exists before controls are considered, while residual risk remains after controls operate. Question 2Which control is primarily detective? A. Least-privilege access configuration B. Mandatory approval before production deployment C. Monthly review of access logs for anomalous activity D. Automatic deletion after the retention period Correct Answer: C. Monthly review of access logs for anomalous activity Question 3If 24 of 2,000 decisions are appealed, what is the appeal rate? A. 0.12% B. 1.2% C. 12% D. 24% Correct Answer: B. 1.2% Question 4Why can accuracy be misleading for a highly imbalanced classification problem? A. Accuracy cannot be calculated for binary outcomes. B. Accuracy ignores both true positives and true negatives. C. A model can achieve high accuracy by predicting the majority class while performing poorly on the minority class. D. Accuracy is measured only on training data. Correct Answer: C. A model can achieve high accuracy by predicting the majority class while performing poorly on the minority class. Question 5What is the primary purpose of independent model validation? A. To replace all business-owner judgment B. To confirm that the model is fit for purpose and operated within approved boundaries C. To guarantee that the model will never drift D. To eliminate the need for monitoring after deployment Correct Answer: B. To confirm that the model is fit for purpose and operated within approved boundaries Question 6Which characteristic is most important for a useful KRI? A. It has a clear definition, owner, data source, threshold, and response. B. It is as complex as possible. C. It is reported only after a severe incident. D. It measures employee satisfaction exclusively. Correct Answer: A. It has a clear definition, owner, data source, threshold, and response. Question 7What should generally occur first after a credible AI incident is detected? A. Delete all system logs to protect privacy. B. Publish an unverified public explanation. C. Triage the incident, preserve facts, and assess scope and ongoing exposure. D. Restore the same model without investigation. Correct Answer: C. Triage the incident, preserve facts, and assess scope and ongoing exposure. Question 8Which item is strongest as compliance evidence? A. An undated statement that a review probably occurred B. A time-stamped access-review record showing owner, population, exceptions, and resolution C. A marketing brochure describing the organization’s values D. An informal verbal assurance from a vendor Correct Answer: B. A time-stamped access-review record showing owner, population, exceptions, and resolution Question 9Why can fairness metrics conflict? A. Fairness metrics are always mathematically identical. B. Different metrics impose different conditions, and differing group base rates can make them impossible to satisfy simultaneously. C. Fairness metrics apply only to unsupervised learning. D. Fairness metrics do not use data. Correct Answer: B. Different metrics impose different conditions, and differing group base rates can make them impossible to satisfy simultaneously. Question 10Which remediation action best addresses an underlying control failure? A. Close the incident without documenting it. B. Correct one affected record and change nothing else. C. Define a mandatory pre-deployment review, assign an owner, test implementation, and independently verify effectiveness. D. Increase the number of dashboard colors. Correct Answer: C. Define a mandatory pre-deployment review, assign an owner, test implementation, and independently verify effectiveness.
|