AI Impact Assessment, Auditing, and Analytics

Introduction

Artificial intelligence systems increasingly influence access to employment, education, credit, healthcare, public services, insurance, safety, and information. Their effects are not limited to whether a model predicts accurately. An AI system can be technically accurate yet discriminatory, unsafe, opaque, privacy-invasive, or difficult to contest. Responsible innovation therefore requires systematic methods for identifying, measuring, documenting, and controlling impacts throughout the system life cycle.

AI impact assessment, auditing, and analytics are related but distinct activities. An impact assessment is a structured ex ante or ongoing examination of possible effects and risks. An audit is an independent or sufficiently objective examination of whether a system, process, or organisation meets specified requirements. Analytics provides the quantitative and qualitative evidence used in both activities. Together, these practices support evidence-based governance rather than relying on general assurances such as “the model is fair” or “the system is compliant.”

This chapter focuses on practical assessment of algorithmic and fundamental-rights impacts. It explains how to construct a risk register, select indicators, establish thresholds, maintain audit trails, design monitoring dashboards, interpret evidence, and recognise the limitations of metrics and audits.

Learning Objectives

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

1. Distinguish AI impact assessment, auditing, monitoring, and evaluation.

2. Identify affected stakeholders, rights, harms, and system dependencies.

3. Construct and maintain an AI risk register.

4. Select appropriate quantitative and qualitative indicators.

5. Explain common fairness, performance, privacy, security, and safety measures.

6. Design thresholds, escalation rules, audit trails, and monitoring dashboards.

7. Interpret conflicting or incomplete evidence responsibly.

8. Evaluate the limitations of metrics, datasets, audits, and assurance claims.

9. Apply an assessment framework to a realistic AI deployment scenario.

1. From Model Evaluation to Impact Assessment

Traditional machine-learning evaluation commonly asks whether a model performs well on a test set. Typical measures include accuracy, precision, recall, calibration, or mean absolute error. These measures remain important, but they are insufficient for responsible innovation because the model is embedded in a broader sociotechnical system.

A complete assessment considers at least five layers:

• The model: its inputs, outputs, performance, uncertainty, and failure modes.
• The data: provenance, representativeness, quality, labelling practices, and sensitive attributes.
• The process: how humans use outputs, whether decisions are reviewable, and how appeals operate.
• The institution: incentives, accountability, procurement, staffing, and organisational controls.
• The social context: power relationships, historical disadvantage, legal rights, cultural expectations, and likely downstream effects.

For example, a recruitment-ranking model might have high predictive validity but reproduce historical exclusion if trained on past hiring decisions. A facial-recognition system might have a low error rate overall but substantially higher error rates for particular demographic groups. A benefits-fraud model may identify genuine anomalies while also subjecting vulnerable households to intrusive investigations. Impact assessment makes these consequences visible before deployment and during operation.

Impact assessment and audit compared

An impact assessment asks: What could this system affect, who may be affected, how severe are the possible consequences, and what safeguards are needed? It is usually forward-looking, although it can be repeated after deployment.

An audit asks: Did the system and its operators meet defined requirements, controls, or standards? An audit examines evidence and forms a conclusion about conformity, effectiveness, or risk. It may be internal, independent, regulatory, or third-party.

Monitoring is the continuing collection and review of evidence after deployment. Evaluation is the broader examination of whether the intervention achieves its intended objectives and produces acceptable outcomes. A high-quality governance programme uses all four activities rather than treating a one-time audit as permanent proof of safety.

2. A Life-Cycle Assessment Framework

A practical assessment can follow seven stages.

Stage 1: Define the system and its purpose

Document the intended purpose, users, affected persons, decision points, model type, inputs, outputs, human roles, deployment environments, and dependencies such as external data or cloud services. Explicitly state uses that are prohibited or outside scope. A purpose limitation prevents a system approved for one function from silently expanding into another.

Stage 2: Map stakeholders and affected groups

Stakeholders include developers, deployers, operators, data subjects, people indirectly affected, regulators, auditors, suppliers, and representatives of vulnerable communities. Stakeholder mapping should distinguish those who make decisions from those who bear risks. Consultation should be accessible and meaningful; merely publishing a technical document is not participation.

Stage 3: Identify impacts and rights

Potential impacts include discrimination, loss of autonomy, privacy intrusion, physical injury, economic loss, denial of services, reputational damage, manipulation, exclusion, and environmental cost. A fundamental-rights analysis may consider equality and non-discrimination, privacy and data protection, freedom of expression, due process, effective remedy, human dignity, education, work, health, and social security. The relevant rights depend on the domain and jurisdiction.

Stage 4: Analyse likelihood, severity, and distribution

Risk is not simply an average expected loss. Analysts should consider who experiences the harm, whether it is reversible, whether affected persons can detect and challenge it, and whether harms accumulate across systems. A low-probability event such as an unsafe medical recommendation may require stronger controls than a frequent but easily corrected inconvenience.

Stage 5: Select controls and decide whether to proceed

Controls may include data improvement, model redesign, access restrictions, human review, uncertainty displays, explanation and appeal channels, encryption, retention limits, red-teaming, contractual requirements, or non-deployment. Controls should address root causes rather than merely documenting risks.

Stage 6: Deploy with monitoring and escalation

Approval should specify indicators, data sources, owners, review frequency, thresholds, and actions. A deployment without an escalation process is not adequately monitored.

Stage 7: Reassess and close the loop

Reassessment is required after significant model, data, purpose, supplier, legal, or environmental changes. Incident reports, complaints, appeals, and observed outcomes should update the risk register and influence future design.

3. Risk Registers and Risk Treatment

A risk register is a living management instrument, not a static list. A useful entry includes:

| Field | Purpose |

|---|---|

| Risk ID | Unique reference for traceability |

| Description | Specific event, cause, and consequence |

| Affected groups | Persons or communities exposed to the risk |

| Rights or objectives affected | Equality, privacy, safety, accuracy, and so forth |

| Inherent likelihood and severity | Risk before controls |

| Existing controls | Current technical and organisational safeguards |

| Residual risk | Remaining exposure after controls |

| Indicators and thresholds | Evidence used to detect deterioration |

| Owner | Person accountable for treatment and review |

| Treatment decision | Reduce, transfer, avoid, accept, or monitor |

| Due date and status | Implementation tracking |

| Evidence | Links to tests, decisions, incidents, and approvals |

A simple qualitative risk score can be represented as

Risk score = Likelihood × Impact

where likelihood and impact are ordinal ratings, for example from 1 to 5. This is a prioritisation aid, not a measurement of actual probability or harm. Multiplying ordinal categories can create a misleading appearance of precision. High-impact risks may require action even when likelihood is uncertain, and risks affecting fundamental rights should not be accepted solely because their numerical score is low.

Risk treatment should follow a hierarchy. First avoid unnecessary high-risk use. Second reduce risk through design and data controls. Third provide detection, human intervention, and remedy. Only then should residual risk be considered for acceptance by an authorised accountable body. Transferring responsibility to a vendor does not transfer the organisation’s ethical or legal responsibility to affected persons.

4. Indicators and Metrics

Indicators translate abstract objectives into observable evidence. They should be linked to decisions and have a named owner. A balanced indicator set normally includes several categories.

Performance and validity

For binary classification, let TP denote true positives, TN true negatives, FP false positives, and FN false negatives.

Accuracy is

Accuracy = (TP + TN) / (TP + TN + FP + FN)

It is useful when classes and error costs are reasonably balanced, but can be misleading with class imbalance.

Precision is

Precision = TP / (TP + FP)

It answers: among predicted positives, how many are positive? Recall, also called sensitivity or true-positive rate, is

Recall = TP / (TP + FN)

It answers: among actual positives, how many were detected? The false-positive rate is

FPR = FP / (FP + TN)

and the false-negative rate is

FNR = FN / (FN + TP).

These quantities must be interpreted in context. In a safety screening system, false negatives may be more serious than false positives. In an enforcement system, false positives may impose severe burdens on innocent people.

For regression, mean absolute error is

MAE = (1/n) Σ |yᵢ − ŷᵢ|

where yᵢ is the observed value, ŷᵢ is the prediction, and n is the number of observations. MAE has the same units as the target and is often easier to interpret than squared-error measures.

Fairness indicators

Let groups A and B be defined using a legally and ethically justified classification, and let Ŷ be the decision.

Selection-rate parity compares

P(Ŷ = 1 | A) and P(Ŷ = 1 | B).

A difference may indicate disparate outcomes, but it does not by itself prove discrimination. Groups may have different qualification distributions, measurement quality, or exposure to the system.

Equal opportunity requires equality of true-positive rates across groups:

P(Ŷ = 1 | Y = 1, A) = P(Ŷ = 1 | Y = 1, B).

Equalised odds requires equality of both true-positive and false-positive rates across groups. Predictive parity requires equal positive predictive values across groups. When base rates differ, these fairness conditions generally cannot all hold simultaneously except in special cases. Fairness is therefore a normative and contextual choice, not a problem solved by selecting the largest number.

Small subgroups require particular care. A difference based on very few observations may be unstable, while aggregating all groups can conceal severe harms to a minority. Confidence intervals, sample sizes, qualitative evidence, and intersectional analysis should accompany point estimates.

Privacy, security, safety, and process indicators

Relevant indicators may include unauthorised access incidents, proportion of data fields minimised, retention-period compliance, security vulnerabilities, system availability, unsafe-output rate, override rate, complaint volume, appeal success rate, time to remedy, explanation delivery rate, and percentage of model versions with complete documentation. A sudden reduction in complaints may indicate improvement—or that people no longer know how to complain.

Environmental and operational indicators

Depending on the system, organisations may monitor energy use, compute hours, hardware utilisation, model latency, service outages, and carbon emissions. These indicators should be interpreted with clear boundaries, such as whether they include training only or also inference and infrastructure.

5. Thresholds, Uncertainty, and Escalation

A threshold converts evidence into a governance action. Examples include:

• investigate if the false-negative-rate difference exceeds a specified value for two consecutive review periods;
• pause automated decisions if a safety incident reaches a defined severity;
• require human review when model confidence falls below a documented level;
• retrain or recalibrate when monitored data materially diverges from the development population;
• notify affected persons and regulators where applicable after a reportable breach.

Thresholds should be justified by law, domain risk, baseline performance, statistical uncertainty, operational capacity, and the cost of errors. A threshold is not automatically a legal safe harbour. For a difference in group rates, a confidence interval or hypothesis test may help assess uncertainty, but statistical significance does not determine ethical acceptability. Conversely, a practically serious disparity may be important even with a small sample that cannot establish statistical significance.

Thresholds should include a green-amber-red action structure. Green indicates normal operation; amber requires investigation or increased sampling; red requires escalation, suspension, remediation, or a decision by a designated authority. The dashboard should display the action associated with each status, not merely a colour.

6. Audit Trails and Documentation

An audit trail enables a reviewer to reconstruct what happened, when, by whom, using which system version and evidence. It should cover:

• data sources, licences, provenance, transformations, and labelling decisions;
• model versions, parameters, training dates, evaluation datasets, and approval decisions;
• access to sensitive data and administrative actions;
• inputs, outputs, confidence or uncertainty information where appropriate;
• human overrides, reasons, referrals, and final decisions;
• complaints, appeals, incidents, corrective actions, and closure evidence;
• changes to purpose, thresholds, suppliers, and deployment environment.

Logs must be tamper-evident, access-controlled, time-synchronised, and retained only as long as justified. Excessive logging can create privacy and security risks. Auditability also requires intelligible records: a database of raw events is not sufficient if no one can connect events to decisions and responsibilities.

Documentation practices such as model cards, data sheets, system cards, decision records, and impact assessment reports support accountability. Documentation should identify known limitations rather than presenting the system as universally valid.

7. Monitoring Dashboards and Analytics Workflows

A responsible dashboard is designed around decisions, not visual decoration. Each indicator should specify its definition, numerator and denominator, data source, population, time window, owner, update frequency, uncertainty, threshold, and required action.

A useful dashboard can contain:

1. System status: version, deployment sites, uptime, active incidents, and recent changes.

2. Outcome quality: performance by relevant group, geography, use case, and time period.

3. Fairness and rights: disparities, appeal outcomes, complaint trends, privacy events, and human-review rates.

4. Data health: missingness, distribution shifts, label delays, and provenance exceptions.

5. Controls: completion of access reviews, security tests, staff training, and audit actions.

6. Decision panel: open risks, threshold breaches, owners, deadlines, and escalation status.

Dashboards should support drill-down without encouraging inappropriate identification of individuals. Access should follow role-based permissions, and sensitive subgroup results may require aggregation or suppression. Automated monitoring must not become an excuse to eliminate human judgement. Analysts should investigate why a metric changed and whether the measurement process itself changed.

8. Worked Example: Interpreting Group Metrics

Suppose a loan-screening system produces the following results for two groups:

| Group | TP | TN | FP | FN |

|---|---:|---:|---:|---:|

| A | 72 | 108 | 12 | 8 |

| B | 48 | 72 | 24 | 16 |

For Group A, recall is 72/(72+8) = 0.90, or 90%, and the false-positive rate is 12/(12+108) = 0.10, or 10%. For Group B, recall is 48/(48+16) = 0.75, or 75%, and the false-positive rate is 24/(24+72) = 0.25, or 25%.

The recall difference is 15 percentage points and the false-positive-rate difference is also 15 percentage points. This is evidence of unequal error rates, but it does not establish the cause. Analysts should examine sample sizes, base rates, feature quality, historical decision processes, economic consequences, and whether the outcome label represents legitimate success. Possible responses include improving data, changing the threshold, using separate calibrated procedures where justified, adding human review, or not deploying the system. The organisation should not claim that the model is fair merely because its overall accuracy is high.

9. Case Study: Illustrative Public Benefits Triage System

Background

A municipal agency introduces an AI system to prioritise applications for emergency housing support. The system predicts which applications require urgent review using household information, prior service contacts, income records, and caseworker notes. It does not formally reject applications, but staff have limited capacity and usually review high-priority cases first.

Problem

After deployment, the agency reports shorter average processing times. Community organisations, however, report that applicants with unstable housing and limited digital records are being classified as low priority. The agency’s initial evaluation showed 92% overall accuracy, but it did not examine groups separately or assess the consequences of delayed review.

Analysis

An impact assessment identifies several risks: unequal access to essential services, privacy concerns arising from caseworker notes, automation bias among staff, and limited ability to appeal a priority score. The system’s indirect effect is important: although the score is described as advisory, resource constraints make it influential in practice.

The risk register records a high-severity risk concerning delayed assistance to people with incomplete records. Indicators are defined for recall of genuinely urgent cases, processing time by housing status and disability status where lawful and appropriate, appeal outcomes, missing-data rates, staff overrides, and complaints. Qualitative interviews reveal that some applicants avoid disclosing sensitive information because they distrust data sharing.

Approach and solution

The agency pauses expansion and introduces several controls. It removes unnecessary free-text fields, documents data provenance, and tests whether missingness is itself acting as a proxy for disadvantage. Cases with high uncertainty or missing critical information are routed to trained human reviewers rather than assigned low priority. Applicants receive plain-language information about the triage process and a rapid reconsideration route. A community advisory group reviews proposed indicators and communication materials.

The dashboard uses weekly monitoring, but no single metric determines safety. A red status is triggered by a severe incident, a sustained disparity requiring investigation, or evidence that staff are treating advisory scores as automatic decisions. Audit logs record model versions, score access, overrides, reasons, and appeal outcomes.

Outcome

Processing time remains improved, but overall accuracy is no longer the primary success measure. The agency observes improved urgent-case recall and a higher rate of human review for uncertain cases. Complaints initially increase because the appeal route becomes visible; this is interpreted cautiously rather than as evidence of deterioration. Independent review finds remaining data gaps and recommends a further reassessment before expanding the system.

Learning points

The case illustrates that impact is produced by the complete decision process, not merely by model predictions. Advisory systems can become de facto decision-makers. A strong assessment combines performance metrics with rights analysis, stakeholder evidence, process controls, and effective remedy. It also demonstrates that monitoring must be capable of changing or stopping deployment.

10. Limitations and Critical Interpretation

Metrics are incomplete representations

Every metric defines what counts and excludes something else. Accuracy may ignore unequal burdens; complaint counts depend on awareness and trust; average processing time may hide the people whose cases are delayed longest. Metric selection is therefore a governance decision.

Fairness criteria can conflict

As noted above, equal opportunity, equalised odds, predictive parity, and selection-rate parity may not be simultaneously achievable when groups differ in outcome prevalence. Choosing among them requires a reasoned account of the decision’s purpose, error costs, rights, and affected communities.

Correlation does not establish cause

A disparity may result from the model, the labels, historical inequality, unequal access to services, or several factors together. Removing a protected attribute does not remove its proxies. Conversely, collecting protected-attribute information may be necessary for auditing, even when it should not be used for prediction. Such collection requires a clear legal basis, safeguards, and purpose limitation.

Audits can be narrow or performative

An audit may examine documentation while missing real-world outcomes, or test a model at one point in time while ignoring drift. Vendor-provided audits may lack independence. Auditors may also face restricted access to data, proprietary code, or affected communities. Audit scope, evidence, independence, competence, conflicts of interest, and follow-up should therefore be disclosed.

Statistical uncertainty and subgroup limitations

Small samples produce unstable estimates, while large samples can make trivial differences statistically significant. Analysts should report sample sizes, intervals where appropriate, practical significance, and data limitations. Intersectional groups may be especially small, but their exclusion can conceal harm. Privacy-preserving aggregation and carefully designed qualitative research can supplement sparse quantitative evidence.

Distribution shift and feedback loops

Deployment changes behaviour and populations. A fraud model may cause investigators to focus on one neighbourhood, generating more records there and reinforcing the model’s apparent pattern. Monitoring should compare intended and actual use, examine shifts in inputs and outcomes, and test whether interventions themselves alter the data-generating process.

11. Professional, Legal, and Governance Implications

Responsibility should be allocated across the organisation. Senior leadership sets risk appetite and ensures resources. Product owners define purpose and controls. Data scientists validate performance and limitations. Domain experts assess consequences. Legal and privacy professionals interpret obligations. Security teams protect systems and logs. Operators exercise judgement and report incidents. Internal audit or independent assessors test evidence. A responsible governance structure gives each role authority, competence, and escalation access.

Regulatory requirements vary by jurisdiction and sector, but common expectations include risk management, data governance, transparency, human oversight, record keeping, security, accuracy, impact assessment, and mechanisms for contestation. Organisations should not treat a technical standard or certification as a substitute for legal advice or ethical judgement. Fundamental-rights analysis is especially important where a system affects access to essential services or imposes significant burdens.

Affected people need practical remedies: notice where appropriate, an opportunity to provide relevant information, meaningful human review, correction of inaccurate data, explanation proportionate to the decision, and a route to challenge outcomes. A technically accurate decision may still be unacceptable if no one can contest it or if the process is incomprehensible.

12. Best-Practice Checklist

Before deployment, an organisation should be able to answer yes to the following questions:

• Is the purpose specific, necessary, and authorised?
• Have affected and vulnerable groups been identified and consulted?
• Are data provenance, quality, representativeness, and sensitive uses documented?
• Have rights, harms, benefits, and alternatives been assessed?
• Does the risk register have owners, controls, thresholds, and review dates?
• Are performance and fairness indicators appropriate to the domain and decision consequences?
• Are uncertainty, subgroup limitations, and known failure modes reported?
• Can affected people obtain review and remedy?
• Are model, data, human, and organisational changes logged?
• Is monitoring connected to actions, including suspension or withdrawal?
• Is the audit sufficiently independent, competent, and appropriately scoped?
• Has residual risk been explicitly accepted by an accountable authority?

Contemporary Developments

Current practice is moving from one-time model audits toward continuous assurance across the AI life cycle. This includes automated data-quality checks, software bills of materials, model and dataset lineage, red-teaming, incident databases, independent conformity assessment, privacy-preserving analytics, and participatory governance. Generative AI adds further concerns, including hallucinated content, prompt leakage, copyright and provenance questions, inconsistent outputs, and difficulty defining a stable model boundary. These developments reinforce a central principle: responsible innovation is an organisational capability for learning and correction, not a certificate that a system is permanently safe.

Chapter Summary

AI impact assessment, auditing, and analytics provide complementary methods for responsible AI governance. Impact assessment identifies possible effects, affected groups, rights, and safeguards. Auditing tests whether requirements and controls are met. Monitoring gathers continuing evidence, while evaluation judges whether the system achieves legitimate objectives.

A robust assessment examines the model, data, process, organisation, and social context. Risk registers make risks actionable by assigning owners, controls, indicators, thresholds, and review dates. Metrics such as accuracy, precision, recall, false-positive rate, false-negative rate, MAE, selection-rate parity, equal opportunity, and equalised odds are useful only when their assumptions, denominators, uncertainty, and consequences are understood. No metric alone establishes fairness or safety.

Audit trails, documentation, dashboards, stakeholder participation, human oversight, and accessible remedies convert principles into operational practice. Thresholds must lead to specified actions, and monitoring must be capable of escalation, remediation, or stopping deployment. Finally, professionals must recognise that metrics can be incomplete, audits can be narrow, fairness criteria can conflict, and deployment can create feedback loops. Responsible innovation therefore requires continuous, evidence-informed, rights-sensitive judgement.

Key Terms

Impact assessment: Structured examination of an AI system’s potential and actual effects.

Algorithmic audit: Systematic examination of an AI system or process against defined requirements.

Fundamental rights: Basic rights and freedoms protected by law and ethical governance frameworks.

Risk register: Living record of risks, controls, owners, indicators, and treatment decisions.

Residual risk: Risk remaining after safeguards are applied.

Indicator: Observable measure used to track performance, impact, or control effectiveness.

Threshold: Defined level of evidence that triggers a governance action.

Audit trail: Traceable record of events, decisions, system versions, and responsible actors.

Accuracy: Proportion of all predictions that are correct.

Precision: Proportion of predicted positives that are true positives.

Recall: Proportion of actual positives that are correctly detected.

False-positive rate: Proportion of actual negatives incorrectly classified as positive.

Equal opportunity: Equality of true-positive rates across groups.

Equalised odds: Equality of true-positive and false-positive rates across groups.

Predictive parity: Equality of positive predictive values across groups.

Data drift: Change in the distribution of input data over time.

Automation bias: Tendency to over-rely on automated outputs.

Human oversight: Organised human ability to understand, intervene in, and govern system operation.

Remedy: Mechanism for correcting harm or challenging an AI-supported decision.

Residual uncertainty: Important uncertainty remaining after analysis and controls.

Review Questions

Short Answer Questions

1. Distinguish an AI impact assessment from an algorithmic audit.

2. What information should a risk register contain?

3. Define precision and recall.

4. Why can overall accuracy conceal unfair outcomes?

5. What is the purpose of an audit trail?

Long Answer Questions

1. Explain a life-cycle framework for assessing the impacts of an AI system.

2. Discuss how thresholds and escalation rules should be designed and interpreted.

3. Compare equal opportunity, equalised odds, and predictive parity.

4. Explain why monitoring dashboards must include qualitative and contextual evidence.

5. Evaluate the principal limitations of third-party AI audits.

Analytical / Application Questions

1. A hiring model has equal overall accuracy for two groups, but its false-positive rate is twice as high for one group. Identify possible explanations, additional evidence required, and appropriate governance responses.

2. Design a risk-register entry and dashboard indicators for an AI system that prioritises hospital patients for specialist appointments.

3. A vendor claims that removing race from a model guarantees fairness. Critically assess the claim and propose an audit plan.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily forward-looking and asks what harms and rights impacts could arise from an AI system?

A. Impact assessment

B. Audit trail reconstruction

C. Incident closure

D. Software compilation

Correct Answer: A. Impact assessment

Question 2

A classifier has TP = 80 and FN = 20. What is its recall?

A. 20%

B. 40%

C. 80%

D. 100%

Correct Answer: C. 80%

Question 3

Which metric measures the proportion of predicted positive cases that are actually positive?

A. Recall

B. Precision

C. False-negative rate

D. Accuracy

Correct Answer: B. Precision

Question 4

What is the main purpose of a risk-register owner?

A. To remove all uncertainty from the system

B. To assign accountability for treatment and review of a risk

C. To guarantee that a model is unbiased

D. To replace stakeholder consultation

Correct Answer: B. To assign accountability for treatment and review of a risk

Question 5

Equal opportunity requires equality of which quantity across groups?

A. True-positive rates

B. Training-set sizes

C. Predicted negative counts

D. Model-development costs

Correct Answer: A. True-positive rates

Question 6

Which dashboard design is most responsible?

A. Displaying colours without defining actions

B. Showing only overall accuracy

C. Linking each indicator to a definition, owner, threshold, and action

D. Publishing identifiable individual records

Correct Answer: C. Linking each indicator to a definition, owner, threshold, and action

Question 7

Why might removing a protected attribute fail to eliminate discrimination?

A. Models cannot use numerical data

B. Proxy variables and historical patterns may remain

C. It always reduces accuracy to zero

D. Protected attributes are never relevant to auditing

Correct Answer: B. Proxy variables and historical patterns may remain

Question 8

In the worked loan example, what was Group B’s false-positive rate?

A. 10%

B. 15%

C. 20%

D. 25%

Correct Answer: D. 25%

Question 9

Which event most clearly requires reassessment of an AI impact assessment?

A. A routine dashboard refresh with no changes

B. A significant change in purpose or deployment environment

C. A scheduled staff meeting

D. A document being alphabetised

Correct Answer: B. A significant change in purpose or deployment environment

Question 10

Why is a low number of complaints not necessarily evidence that an AI system is safe?

A. Complaints are always legally irrelevant

B. People may be unaware of, unable to access, or distrust the complaint process

C. Complaints cannot concern automated systems

D. Low complaint numbers prove high accuracy

Correct Answer: B. People may be unaware of, unable to access, or distrust the complaint process