Explainable, Ethical and Secure Machine Learning

Introduction and Context

Machine-learning systems increasingly influence decisions about credit, employment, education, healthcare, insurance, policing, and access to digital services. Their technical performance is therefore only one dimension of quality. A model may achieve high predictive accuracy while relying on inappropriate features, disadvantaging a protected group, exposing personal information, or being easily manipulated. Responsible machine learning treats these concerns as engineering, organisational, and societal requirements rather than as optional additions.

This chapter examines five connected responsibilities: explaining model behaviour, assessing and mitigating unfairness, protecting privacy, improving robustness and security, and establishing governance and accountability. These responsibilities are interdependent. For example, a model explanation may reveal proxy discrimination; a privacy-preserving method may reduce accuracy or explainability; and a security control may alter the distribution of observed data. Sound practice therefore requires lifecycle management, documentation, testing, human oversight, and continuous monitoring.

The goal is not to make every model perfectly transparent or risk-free. Such goals are generally impossible. The goal is to make risks visible, proportionate controls explicit, decisions contestable, and system behaviour appropriate for its context.

Learning Objectives

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

1. Distinguish global from local explanations and select suitable explanation methods.

2. Explain algorithmic bias, fairness criteria, and the trade-offs among them.

3. Assess privacy risks and describe differential privacy, anonymisation, and privacy-aware design.

4. Analyse robustness and security threats, including adversarial examples, data poisoning, and model extraction.

5. Design documentation for datasets and models and identify appropriate human oversight.

6. Relate responsible-AI practice to accountability, risk management, and regulatory governance.

7. Evaluate an applied machine-learning system using technical, ethical, and organisational criteria.

1. Explainability: Understanding Model Behaviour

1.1 What explainability means

Explainability is the extent to which relevant stakeholders can understand how a model produces outputs and how those outputs should be used. Interpretability is often used more narrowly to describe a model whose internal operation is understandable, such as a small decision tree or a linear model. The distinction is not universal, but it is useful: an explanation is an artefact or account provided to someone, whereas interpretability concerns properties of the model itself.

Explanations serve different purposes:

• Debugging: identifying leakage, spurious correlations, or data-quality problems.
• Validation: checking whether the model uses clinically, legally, or operationally plausible evidence.
• User support: helping a professional understand and appropriately challenge a recommendation.
• Recourse: indicating which actionable conditions might change an outcome.
• Governance: supplying evidence for audit, documentation, and incident investigation.

An explanation should be evaluated for fidelity, stability, usefulness, clarity, and alignment with the intended audience. A visually attractive explanation is not necessarily a faithful one.

1.2 Global and local explanations

A global explanation describes the model’s general behaviour across a population. Examples include feature-importance summaries, partial-dependence plots, permutation importance, and surrogate models. A local explanation describes one prediction, such as why a particular loan application was classified as high risk. Global and local explanations answer different questions and should not be substituted for one another.

For a prediction function \(f(x)\), where \(x=(x_1,\ldots,x_p)\) is a feature vector, a local additive explanation can be represented as

\[

g(z')=\phi_0+\sum_{j=1}^{M}\phi_j z'_j.

\]

Here, \(g\) is an interpretable explanation model, \(z'_j\) indicates whether interpretable component \(j\) is present, \(M\) is the number of components, \(\phi_0\) is a baseline, and \(\phi_j\) is the contribution attributed to component \(j\). In SHAP-style explanations, the contributions are designed to satisfy an efficiency property: the baseline plus contributions equals the explained output, subject to the definition of the output scale and background distribution. This does not mean that the explanation proves causality. A feature contribution describes the model’s association, not necessarily what would happen if a person changed that feature.

1.3 Major explanation methods

Intrinsic models. Sparse linear models, monotonic models, small decision trees, and rule lists can be understandable by design. Their limitations include restricted representational capacity, sensitivity to feature engineering, and the possibility that a simple model still encodes biased data.

Permutation importance. A feature is randomly shuffled and the resulting performance decrease is measured. It is model-agnostic and useful for global analysis, but correlated features can share or mask importance. Shuffling must be performed using suitable validation data rather than training data alone.

Partial dependence. A partial-dependence plot estimates the average predicted response as a feature varies while other features are averaged over. It can be misleading when the plotted feature values are unrealistic combinations of correlated features.

Individual conditional expectation (ICE). ICE plots show prediction curves for individual observations, revealing heterogeneity hidden by an average partial-dependence curve.

LIME-like local surrogate methods. A simple model is fitted around a selected instance using perturbed inputs. Such explanations can be useful, but results may change with the perturbation distribution, locality definition, or random seed.

SHAP-like additive attribution. Contributions are assigned to features relative to a background expectation. They are useful for ranking and communicating contributions, but correlated variables, feature dependence, and the chosen background set require careful interpretation.

Counterfactual explanations. A counterfactual states a plausible change that could lead to a different output, for example, “with the same income and debt, reducing outstanding credit utilisation below a specified threshold would change the classification.” Counterfactuals should respect feasibility, immutable attributes, cost, and causal relationships. Suggesting that a person change age, ethnicity, or disability is inappropriate even if such a change is mathematically influential.

1.4 Explanation pitfalls

A model can produce plausible explanations while remaining wrong or unfair. Post-hoc explanations may approximate a model rather than reveal its actual reasoning. Feature importance does not establish causation. Explanations can also expose sensitive information or enable gaming. A responsible workflow therefore compares multiple explanation methods, tests stability, records the reference population, and communicates uncertainty. Explanation is not a substitute for performance evaluation, fairness testing, or human judgement.

2. Fairness, Bias, and Non-Discrimination

2.1 Sources of bias

Bias can enter at every stage:

• Historical bias: the target reflects unequal past treatment.
• Representation bias: some groups are absent or underrepresented.
• Measurement bias: variables are measured with different reliability across groups.
• Label bias: outcomes or labels encode subjective or institutional decisions.
• Aggregation bias: one model is applied to populations with different relationships between features and outcomes.
• Deployment bias: the system is used outside the setting assumed during development.
• Feedback-loop bias: predictions affect future observations, such as policing predictions increasing police presence and recorded incidents in selected areas.

Removing a protected attribute does not necessarily remove discrimination. Other variables may act as proxies, and unequal data collection can persist.

2.2 Fairness perspectives and metrics

Fairness is not a single mathematical property. Relevant perspectives include equal treatment, equal opportunity, individual similarity, group parity, procedural justice, and avoidance of unacceptable harm. Different definitions may conflict, particularly when groups have different base rates or the model is imperfect.

Let \(A\) denote a group attribute, \(Y\) the actual outcome, and \(\hat{Y}\) the predicted decision. Common group metrics include:

• Demographic parity: \(P(\hat{Y}=1\mid A=a)\) is equal across groups. It focuses on selection rates, regardless of actual outcomes.
• True positive rate (TPR): \(P(\hat{Y}=1\mid Y=1,A=a)\). Equal opportunity requires comparable TPR across groups.
• False positive rate (FPR): \(P(\hat{Y}=1\mid Y=0,A=a)\). Equalised odds requires comparable TPR and FPR across groups.
• Calibration: among people receiving a given risk score, observed outcome frequencies are comparable across groups. Calibration concerns the meaning of scores rather than equal selection rates.

For a binary classifier, the selection-rate ratio between groups \(a\) and \(b\) is

\[

\text{SRR}=\frac{P(\hat{Y}=1\mid A=a)}{P(\hat{Y}=1\mid A=b)},

\]

provided the denominator is non-zero. A ratio of 1 indicates equal selection rates; it does not by itself demonstrate fairness. Threshold choices, sample uncertainty, intersectional groups, and the social meaning of the target must be considered.

2.3 Why fairness criteria can conflict

Suppose two groups have different outcome prevalences and a risk score is well calibrated. Requiring equal false-positive and false-negative rates may be incompatible with calibration unless the score is perfectly predictive or prevalence is equal. This is a consequence of the underlying rates, not merely a software defect. Organisations must therefore identify the relevant harm, consult affected stakeholders, and justify the selected fairness objective rather than reporting whichever metric looks most favourable.

2.4 Mitigation strategies

Pre-processing changes data before training: improved sampling, reweighting, label review, removal of invalid proxies, or generation of suitable synthetic data. It may obscure legitimate differences or fail when labels are fundamentally inappropriate.

In-processing incorporates fairness constraints or penalties during training. It can directly optimise a chosen objective but may be difficult to explain and may require trade-offs with accuracy.

Post-processing changes thresholds or outputs after training. Group-specific thresholds may improve a selected metric but can raise legal, ethical, and operational concerns. Any intervention must be validated prospectively and monitored after deployment.

Fairness assessment should include confidence intervals or uncertainty analysis where sample sizes permit, intersectional groups, subgroup calibration, error severity, and qualitative review. Aggregate parity can hide serious harms to small populations.

3. Privacy and Data Protection

3.1 Privacy risks in machine learning

Machine-learning privacy risks include inappropriate collection, re-identification, linkage with external data, memorisation of rare records, inference of sensitive attributes, unauthorised secondary use, and leakage through model outputs. Privacy is broader than confidentiality: it includes purpose limitation, control over personal information, transparency, and protection from unwarranted inference.

A privacy-aware lifecycle begins with data minimisation and a clearly specified purpose. Teams should identify the lawful or otherwise legitimate basis for processing in the relevant jurisdiction, restrict access, establish retention periods, encrypt data in transit and at rest, and separate identifying information from analytical data where feasible. Legal compliance must be assessed by qualified professionals; technical controls alone do not determine compliance.

3.2 Anonymisation, pseudonymisation, and their limits

Pseudonymisation replaces direct identifiers with codes, but a re-identification key or linkable information remains. Anonymisation aims to make identification sufficiently unlikely under a stated threat model. Neither term should be treated casually: combinations of quasi-identifiers, auxiliary datasets, and rare attributes can make re-identification possible.

Access control, aggregation, suppression, and data-generation techniques may reduce exposure but can reduce utility. Data should be evaluated against realistic attackers and foreseeable linkage sources.

3.3 Differential privacy

Differential privacy provides a formal guarantee about how much the output of a data analysis changes when one individual’s record is added or removed. A mechanism \(M\) is \(\varepsilon\)-differentially private if, for neighbouring datasets \(D\) and \(D'\) differing in one person, and every possible output set \(S\),

\[

P(M(D)\in S)\le e^{\varepsilon}P(M(D')\in S).

\]

The parameter \(\varepsilon\ge 0\) is the privacy-loss budget: smaller values generally provide stronger privacy, though privacy and utility must be evaluated for the specific mechanism and data. The definition assumes a clear neighbouring-dataset relationship and does not guarantee that an individual cannot be inferred from all other available information. Repeated analyses consume a cumulative privacy budget, commonly called composition. Differential privacy is therefore a system-level accounting problem, not a label that can be attached without measuring the mechanism and query history.

Other approaches include federated learning, where data remain on participating devices or institutions while updates are aggregated; secure multiparty computation; and trusted execution environments. Federated learning is not automatically private because updates may leak information and may be attacked or poisoned. It generally requires secure aggregation, update clipping, access controls, and potentially differential privacy.

4. Robustness and Machine-Learning Security

4.1 Reliability under distribution change

Robustness is the ability to maintain acceptable behaviour under expected variation, noise, missing data, distribution shift, and deliberate manipulation. A model that performs well on an independent test set may fail when sensors change, a population evolves, or an attacker crafts inputs.

Threat modelling should specify the attacker’s goals, capabilities, access, resources, and target. Relevant threats include:

• Evasion or adversarial examples: inputs are modified at inference time to cause an incorrect prediction.
• Poisoning: training data or labels are manipulated to degrade the model or insert targeted behaviour.
• Backdoors: a trigger causes a malicious output while ordinary validation appears normal.
• Model extraction: repeated queries are used to approximate a proprietary model.
• Membership inference: outputs are used to infer whether a record appeared in training data.
• Data or prompt injection: untrusted content manipulates a system that consumes external text or tools.
• Supply-chain attacks: compromised packages, pretrained models, datasets, or pipelines introduce vulnerabilities.

4.2 Robustness controls

Controls include provenance checks, signed and versioned datasets, least-privilege access, separation of development and production environments, secure dependency management, anomaly detection, robust validation, rate limits, monitoring, incident response, and rollback capability. Security testing should include both ordinary stress tests and adversarial exercises appropriate to the threat model.

Robustness has a cost. Adversarial training, defensive preprocessing, or stricter thresholds may reduce clean-data accuracy or increase computation. Controls should be selected according to potential harm and exposure rather than applied mechanically.

5. Documentation, Human Oversight, and Accountability

5.1 Documentation as an engineering control

Documentation makes assumptions inspectable and supports reproducibility, handover, audit, and incident response. A datasheet for a dataset should record provenance, collection purpose, population, sampling, labels, missingness, known limitations, consent or permissions where relevant, sensitive attributes, transformations, licences, and recommended uses. A model card should record intended use, prohibited use, training data, evaluation data, metrics, subgroup results, limitations, ethical considerations, version, dependencies, and monitoring arrangements.

Documentation must remain current. It should identify owners, approval dates, changes, open risks, and evidence links. A document created only at project completion is unlikely to capture important design decisions.

5.2 Human oversight

Human oversight is meaningful only when the human has sufficient competence, time, authority, information, and ability to override or escalate a system. “Human in the loop” can be superficial if reviewers merely rubber-stamp outputs or are penalised for disagreement. Oversight design should specify:

1. Which decisions require human review.

2. What evidence and uncertainty information the reviewer receives.

3. When automatic decisions must be paused or escalated.

4. How reviewers record reasons and disagreements.

5. How affected people can seek correction or appeal.

6. How automation bias and reviewer workload are monitored.

Human review does not eliminate responsibility. The organisation remains accountable for the system’s design, deployment, and effects.

5.3 Governance and regulatory context

Responsible-AI governance normally includes risk classification, impact assessment, role allocation, procurement controls, testing gates, monitoring, incident reporting, and retirement procedures. International frameworks such as the NIST AI Risk Management Framework and UNESCO’s Recommendation on the Ethics of Artificial Intelligence provide guidance, while the OECD AI Principles emphasise human-centred values, transparency, robustness, and accountability.

Legal obligations vary by jurisdiction and application. The European Union’s AI Act uses a risk-based structure with prohibited practices, high-risk obligations, transparency requirements for certain systems, and provisions that continue to evolve through implementation. Data-protection laws such as the GDPR may apply to personal-data processing, automated decision-making, transparency, security, and data-subject rights. Other jurisdictions use sectoral, anti-discrimination, consumer-protection, or algorithmic-accountability rules. Students and practitioners should consult current primary sources and legal specialists rather than assuming that one framework applies globally.

Governance should allocate responsibility across the lifecycle: data stewards, model developers, domain experts, security teams, deployers, operators, executives, and independent reviewers. An accountability record should make clear who approved the system, on what evidence, with which residual risks, and under what conditions deployment must stop.

6. A Lifecycle Framework for Responsible Machine Learning

A practical workflow can be organised as follows:

Step 1: Define purpose and impact. Identify the decision, affected people, benefits, foreseeable harms, alternatives to automation, and unacceptable uses.

Step 2: Map data and stakeholders. Record sources, permissions, representation, sensitive attributes, labels, retention, and affected communities.

Step 3: Establish a baseline. Compare against a simple model, existing human process, and relevant subgroup outcomes. A more complex model is not justified by accuracy alone.

Step 4: Select performance and responsibility metrics. Include calibration, error costs, subgroup fairness, privacy, latency, robustness, and operational reliability.

Step 5: Train and validate securely. Prevent leakage, protect credentials, version artefacts, test data provenance, and use appropriate validation splits.

Step 6: Explain and review. Use global and local explanations, domain review, counterfactual plausibility checks, and documentation.

Step 7: Conduct independent challenge. Red-team security, test edge cases, examine intersectional groups, and invite stakeholder feedback.

Step 8: Deploy with controls. Apply access control, logging, human escalation, rate limits, user communication, and rollback procedures.

Step 9: Monitor and respond. Track drift, subgroup performance, privacy incidents, security alerts, override rates, complaints, and unexpected harms.

Step 10: Retire or revise. Define sunset criteria and reassess the impact when data, purpose, population, or law changes.

7. Worked Example: Fairness and Explanation in Credit Screening

Consider an illustrative case in which a bank develops a model to prioritise applications for manual review. A positive prediction means “send for enhanced review,” not “reject.” The model uses income, debt-to-income ratio, repayment history, employment length, and address-derived variables. The bank evaluates two groups, A and B, on a held-out sample.

Suppose the selection rates are 0.30 for A and 0.45 for B. The selection-rate ratio for A relative to B is

\[

\text{SRR}=0.30/0.45=0.667.

\]

Thus, A is selected at approximately two-thirds the rate of B. This result is a signal for investigation, not proof of unlawful discrimination. The team must examine sample uncertainty, legitimate business rationale, historical labels, and whether address-derived variables act as proxies.

The confusion matrices show that TPR is 0.80 for A and 0.70 for B, while FPR is 0.10 for A and 0.20 for B. The model therefore identifies more actual positive cases in A but incorrectly flags twice as many actual negative cases in B. A single fairness metric would conceal this pattern. The bank should assess the relative harm of missed cases and unnecessary review, then consult compliance and affected stakeholders.

A global permutation analysis identifies repayment history and debt-to-income ratio as the strongest contributors, but address-derived variables also rank highly. Local explanations for several applications reveal that a postal-code feature strongly increases review priority even when financial variables are similar. A counterfactual test shows that changing only the postal code often changes the prediction, which is operationally implausible and raises proxy-discrimination concerns.

The proposed response is to remove the problematic feature, audit its substitutes, retrain, and compare performance and subgroup metrics with the previous model and the manual baseline. The bank also introduces explanation text for reviewers, prohibits automatic adverse decisions, records override reasons, and monitors selection rates and error rates monthly. An independent review checks whether the revised model’s explanations are stable and whether the remaining features are justified. If performance or fairness deteriorates beyond predefined thresholds, deployment is paused.

The outcome is not judged solely by whether the new model is more accurate. A responsible decision considers whether the model improves the process without imposing unacceptable disparate harm, whether explanations assist reviewers, whether applicants have a meaningful correction route, and whether the bank can demonstrate control over the system.

8. Challenges and Limitations

First, fairness metrics can conflict and may depend on labels that are themselves biased. Second, explanations can be unstable, incomplete, or misunderstood. Third, privacy protections can reduce data utility and may complicate auditing. Fourth, robustness cannot be proved against every unknown attack or future distribution shift. Fifth, documentation can become performative if no one has authority to act on identified risks. Sixth, human oversight can fail through automation bias, fatigue, or institutional pressure. Finally, governance frameworks do not replace substantive judgement: compliance with a checklist does not guarantee just outcomes.

These limitations support a sociotechnical approach. Technical evaluation should be combined with domain expertise, stakeholder participation, legal analysis, organisational incentives, and mechanisms for appeal. The correct response to uncertainty is often restricted deployment, additional evidence, or non-deployment—not confident automation.

9. Contemporary Developments and Best Practices

Foundation models and generative systems create additional concerns: training-data provenance, memorisation, hallucination, prompt injection, tool misuse, copyright and privacy disputes, and difficulty defining a stable model boundary. Retrieval systems require controls over document permissions and source quality. Evaluation should include factuality, harmful-content testing, privacy leakage, refusal behaviour, and performance across languages and user groups.

Best practice is risk-proportionate rather than technology-specific. Use the least complex model that meets the need; minimise data; preserve provenance; test before and after deployment; measure subgroup and intersectional outcomes; prefer meaningful explanations; secure the complete supply chain; involve affected stakeholders; provide appeal and correction; document decisions; and assign accountable owners. Responsible machine learning is an ongoing organisational capability, not a one-time certification.

Chapter Summary

Explainable, ethical, and secure machine learning extends model development beyond accuracy. Global explanations describe overall behaviour, while local explanations address individual predictions; neither establishes causality, and both require fidelity and stability checks. Fairness must be defined in relation to the harm and context, because demographic parity, equalised error rates, and calibration may conflict. Bias can arise from historical institutions, sampling, measurement, labels, aggregation, and deployment.

Privacy requires data minimisation, purpose limitation, access control, retention management, and realistic threat analysis. Differential privacy offers a formal guarantee controlled by a privacy parameter and cumulative privacy budget, but it involves utility trade-offs. Robustness and security involve distribution shift, adversarial examples, poisoning, backdoors, extraction, inference, injection, and supply-chain threats.

Datasheets, model cards, impact assessments, monitoring plans, and accountability records make assumptions and responsibilities visible. Human oversight must provide real authority, competence, information, and appeal mechanisms. Governance should be risk-based and aligned with applicable law and recognised frameworks. The responsible-AI lifecycle defines purpose, maps data and stakeholders, measures technical and social outcomes, independently challenges the system, controls deployment, monitors effects, and retires systems when their risks or assumptions are no longer acceptable.

Key Terms

Explainability: The extent to which stakeholders can understand a model’s behaviour and outputs.

Interpretability: A property of a model or representation that makes its operation understandable.

Global explanation: An account of behaviour across a population or input space.

Local explanation: An account of why a particular prediction was produced.

Counterfactual explanation: A description of a plausible change that could produce a different model output.

Proxy variable: A feature that indirectly represents a sensitive attribute.

Algorithmic bias: Systematic error or disadvantage associated with data, modelling, or deployment processes.

Demographic parity: Equality of prediction or selection rates across groups.

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

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

Calibration: Agreement between predicted scores and observed outcome frequencies, often assessed by group.

Differential privacy: A formal privacy guarantee limiting the effect of one individual’s data on an analysis output.

Pseudonymisation: Replacing identifiers with codes while retaining possible linkability.

Data poisoning: Manipulating training data to degrade or control model behaviour.

Adversarial example: An input deliberately modified to induce an incorrect prediction.

Model extraction: Reconstructing or approximating a model through queries.

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

Human oversight: Structured human authority to review, override, escalate, or stop automated decisions.

Accountability: The assignment and demonstration of responsibility for system decisions and impacts.

Distribution shift: A change between the data environment used for development and that encountered in operation.

Review Questions

Short Answer Questions

1. Distinguish global explanations from local explanations and give one example of each.

2. Why does removing a protected attribute not necessarily eliminate discrimination?

3. What does the privacy parameter \(\varepsilon\) represent in differential privacy?

4. Name two machine-learning security threats and describe when they occur.

5. What information should a model card contain?

Long Answer Questions

1. Compare permutation importance, partial dependence, SHAP-like attribution, and counterfactual explanations. Discuss their uses and limitations.

2. Explain why demographic parity, equalised odds, and calibration may be incompatible. What should an organisation do when fairness criteria conflict?

3. Describe a privacy-aware machine-learning lifecycle from data collection to model retirement.

4. Discuss how human oversight can become ineffective and propose design measures to make it meaningful.

5. Explain how documentation, monitoring, incident response, and governance jointly support accountability.

Analytical / Application Questions

1. A hiring model selects 24% of applicants from Group X and 36% from Group Y. Calculate the selection-rate ratio for X relative to Y and explain why this result alone cannot establish unfairness.

2. A medical model performs well overall but has a substantially higher false-negative rate for an intersectional subgroup. Design an investigation and mitigation plan, including technical and organisational actions.

3. A company deploys a federated-learning system, believing that keeping data on devices guarantees privacy. Critically evaluate this claim and recommend additional controls.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes global and local explanations?

A. Global explanations describe one prediction, whereas local explanations describe all predictions.

B. Global explanations describe overall model behaviour, whereas local explanations address an individual prediction.

C. Global explanations are always causal, whereas local explanations are always correlational.

D. Global explanations are used only for linear models, whereas local explanations are used only for trees.

Correct Answer: B. Global explanations describe overall model behaviour, whereas local explanations address an individual prediction.

Question 2

A model has selection rates of 0.30 for Group A and 0.45 for Group B. What is the selection-rate ratio for A relative to B?

A. 0.15

B. 0.50

C. 0.667 approximately

D. 1.50

Correct Answer: C. 0.667 approximately

Question 3

Which fairness metric compares true-positive rates across groups?

A. Demographic parity

B. Equal opportunity

C. Selection-rate ratio

D. Calibration

Correct Answer: B. Equal opportunity

Question 4

What does differential privacy primarily limit?

A. The computational time required to train a model

B. The effect of one individual’s record on an analysis output

C. The number of features in a dataset

D. The accuracy difference between training and test data

Correct Answer: B. The effect of one individual’s record on an analysis output

Question 5

Which is an example of data poisoning?

A. Modifying an input during deployment to evade classification

B. Reconstructing a model through repeated queries

C. Manipulating training examples to degrade or control model behaviour

D. Explaining a prediction using feature contributions

Correct Answer: C. Manipulating training examples to degrade or control model behaviour

Question 6

Why can partial-dependence plots be misleading for correlated features?

A. They always use only categorical variables.

B. They may average over unrealistic combinations of feature values.

C. They cannot be computed for numerical variables.

D. They directly reveal causal effects.

Correct Answer: B. They may average over unrealistic combinations of feature values.

Question 7

Which document is primarily intended to describe dataset provenance, sampling, labels, and limitations?

A. A dataset datasheet

B. A firewall policy

C. A confusion matrix

D. A service-level agreement

Correct Answer: A. A dataset datasheet

Question 8

Which condition is necessary for meaningful human oversight?

A. The reviewer must always accept the model output.

B. The reviewer must have authority and ability to override or escalate.

C. The model must hide uncertainty to avoid confusion.

D. The organisation must remove all automated decisions.

Correct Answer: B. The reviewer must have authority and ability to override or escalate.

Question 9

Which statement about federated learning is most accurate?

A. It automatically guarantees privacy because raw data never leave devices.

B. It prevents all poisoning and inference attacks.

C. It can reduce direct data sharing but may still require secure aggregation and privacy controls.

D. It eliminates the need for access control and monitoring.

Correct Answer: C. It can reduce direct data sharing but may still require secure aggregation and privacy controls.

Question 10

A counterfactual explanation should generally avoid recommending changes to which type of attribute?

A. An actionable repayment amount

B. A correctable data-entry error

C. An immutable sensitive attribute such as ethnicity

D. A feasible debt-to-income ratio

Correct Answer: C. An immutable sensitive attribute such as ethnicity