Chapter 14
Responsible AI, Security and Governance
Advance Diploma in Artificial Intelligence and Machine Learning
Deep Learning & Neural Networks
•
Advance Diploma
Responsible AI, Security and Governance
Introduction
Neural networks are increasingly used in recruitment, credit assessment, healthcare, education, policing, insurance, industrial control and public administration. Their value arises from the ability to learn complex relationships from data, but the same capability creates risks. A model may reproduce historical discrimination, expose personal information, be manipulated by an attacker, produce an untraceable decision, or operate beyond the competence of its human supervisors.
Responsible AI is therefore not an optional layer added after model development. It is a lifecycle discipline that integrates privacy, consent, fairness, accountability, transparency, human oversight, documentation, regulatory compliance and security into problem definition, data preparation, model training, deployment and monitoring.
Governance concerns the structures through which an organisation directs and controls AI. It assigns decision rights, establishes acceptable-risk boundaries, requires evidence, and provides mechanisms for challenge and remediation. Security protects the confidentiality, integrity and availability of AI systems, while responsible-AI practices address broader societal and individual consequences. These areas overlap but are not identical: an encrypted system can still be unfair, and a transparent system can still be vulnerable to attack.
Learning Objectives
By the end of this chapter, students should be able to:
Explain the principal ethical, social, legal and security risks associated with neural networks.
Apply privacy, consent and data-minimisation principles throughout the AI lifecycle.
Analyse fairness using appropriate definitions, metrics and contextual judgement.
Design accountability, transparency, documentation and human-oversight controls.
Identify common attacks against machine-learning systems and select suitable controls.
Relate AI governance practices to frameworks and regulations such as the NIST AI Risk Management Framework, ISO/IEC 42001, the GDPR and the EU AI Act.
Evaluate a responsible-AI implementation in a realistic organisational case.
1. A Lifecycle Model for Responsible Neural Networks
A useful governance model follows the system lifecycle rather than treating deployment as the end of engineering. The lifecycle includes:
Purpose definition: establish the legitimate objective, affected groups, intended users and prohibited uses.
Data acquisition: identify data sources, legal basis, consent conditions, provenance, quality and representativeness.
Design and training: select architectures, loss functions, features and evaluation procedures while recording decisions.
Validation: test performance, robustness, fairness, privacy leakage and failure modes before release.
Deployment: control access, communicate limitations, provide human escalation and monitor operation.
Change and retirement: reassess the system after retraining, changes in data or context, incidents, complaints or regulatory developments.
Responsible AI lifecycle with governance controls
Figure: Responsible AI lifecycle with governance controls
Figure: Responsible-AI controls operate across the complete neural-network lifecycle.
A governance review should be proportionate to risk. A model recommending music does not normally require the same controls as a model influencing parole, medical treatment or employment. Risk assessment should consider severity of harm, probability, scale, affected populations, reversibility and the degree of human dependence on the output.
2. Privacy, Consent and Data Governance
Personal data and purpose limitation
Personal data is information relating to an identified or identifiable person. Neural networks may process direct identifiers, such as names, or indirect identifiers, such as device patterns, location histories and biometric embeddings. Removing names does not automatically make a dataset anonymous. Re-identification may remain possible when records are combined with other information.
Core privacy principles include:
Purpose limitation: collect and use data for specified, legitimate purposes rather than indefinite future use.
Data minimisation: use only data necessary for the stated objective.
Accuracy: correct or remove materially inaccurate data.
Storage limitation: retain data only as long as justified.
Integrity and confidentiality: protect data against unauthorised access, alteration and loss.
Accountability: maintain evidence that these principles have been applied.
Consent is one possible legal and ethical basis for processing, but it is not a universal solution. Valid consent should be informed, specific, freely given and revocable where applicable. It should not be hidden in vague terms or treated as permission for unrelated uses. In employment, education or public-service settings, power imbalances may make consent less freely given. Organisations must therefore assess the applicable legal basis and provide suitable notices, rights and safeguards.
Privacy-preserving techniques
Technical controls may include access restriction, encryption in transit and at rest, pseudonymisation, secure deletion, aggregation, federated learning and differential privacy. Each has limitations. Federated learning reduces centralised data collection but can still leak information through model updates. Pseudonymisation reduces direct exposure but does not necessarily produce anonymous data. Differential privacy provides a formal privacy mechanism by adding calibrated randomness, but stronger privacy can reduce utility.
A commonly used differential-privacy guarantee compares the probability of an output when a dataset includes an individual with the probability when that individual is absent. For a mechanism M and neighbouring datasets D and D′ differing in one person, ε-differential privacy requires:
Pr[M(D) ∈ S] ≤ e^ε Pr[M(D′) ∈ S]
Here, S is any possible set of outputs, Pr denotes probability, and ε ≥ 0 is the privacy-loss parameter. Smaller ε generally indicates stronger privacy, subject to the mechanism and composition of repeated releases. The definition assumes a clearly specified neighbouring-dataset relationship and does not by itself guarantee ethical data collection, fairness or security.
Privacy by design
Privacy should be addressed before training. A practical privacy impact assessment asks:
What data is collected, from whom and through which channels?
What is the purpose and legal basis?
Which fields are essential, and which can be removed or transformed?
Who can access raw data, features, checkpoints and predictions?
What rights can individuals exercise?
What are the retention, deletion and incident-response procedures?
Could model outputs reveal training examples through memorisation or extraction?
Privacy testing should include membership-inference and model-inversion assessments where relevant. A model that performs well but memorises sensitive examples is not necessarily fit for deployment.
3. Fairness and Non-Discrimination
Fairness is not a single numerical property. It involves legal standards, social values, domain knowledge and the distribution of benefits and burdens. Protected or sensitive attributes may include sex, race or ethnicity, disability, age, religion or other legally relevant categories. Their use requires careful legal and ethical analysis; excluding an attribute from training does not remove bias because correlated variables may act as proxies.
Suppose a binary classifier predicts whether an applicant receives a positive decision. For group g:
TPRg = TPg / (TPg + FNg)
FPRg = FPg / (FPg + TNg)
TPR is the true-positive rate, FPR is the false-positive rate, TP is true positive, FN is false negative, FP is false positive and TN is true negative. The denominators must be non-zero, and the definitions assume a binary outcome and a specified ground-truth label.
Important fairness concepts include:
Demographic parity: the positive prediction rate is similar across groups.
Equal opportunity: true-positive rates are similar across groups.
Equalised odds: both true-positive and false-positive rates are similar across groups.
Calibration: among people receiving the same predicted risk, observed outcome frequencies are comparable across groups.
Individual fairness: similar individuals should receive similar treatment under a justified similarity measure.
These criteria can conflict, particularly when groups have different base rates. Consequently, fairness cannot be solved by selecting a metric mechanically. Teams must determine which error is harmful, whether the label is a valid representation of the desired outcome, and whether the system should be used at all.
Fairness assessment workflow
A defensible workflow is to:
Define the decision, affected population and potential harms.
Examine representation, missingness, label quality and historical processes.
Establish subgroup and intersectional analyses before training.
Measure performance and error rates by group, not only overall accuracy.
Investigate causal explanations for observed disparities.
Consider interventions such as better sampling, revised labels, threshold policies, reweighting or human review.
Test after deployment because drift can change disparities.
Fairness interventions may create trade-offs. Reweighting can improve one group’s error rate while increasing variance or reducing overall performance. Threshold adjustments may be legally restricted in some contexts. A documented rationale is therefore essential.
4. Transparency, Explainability and Documentation
Transparency means making relevant information available to appropriate stakeholders. It does not require publishing source code or revealing security-sensitive details. The required explanation depends on the audience:
Affected individuals need understandable information about the decision, important factors, consequences and challenge routes.
Operators need operating limits, confidence information, escalation procedures and known failure modes.
Auditors and regulators need evidence about data, design, testing, governance and incidents.
Developers need technical details about architecture, training, dependencies and reproducibility.
Interpretability methods include feature attribution, counterfactual explanations, saliency maps, surrogate models and example-based explanations. These methods explain aspects of a model, but they are not automatically faithful. A visually persuasive explanation may be unstable or may describe a correlation rather than a causal reason. Explanations should therefore be tested for fidelity, stability, usefulness and non-deception.
Documentation should be maintained as controlled evidence. Useful artefacts include:
Artefact
Main purpose
Dataset datasheet
Records provenance, composition, collection and limitations
Model card
Describes intended use, performance, groups tested and restrictions
Data-protection impact assessment
Assesses privacy risks and controls
Risk register
Tracks hazards, likelihood, impact, owner and mitigation
System card
Describes the complete socio-technical system and dependencies
Change log
Records versions, approvals, retraining and material changes
Incident register
Records failures, complaints, investigations and corrective actions
Documentation must be accurate and current. A model card written at project completion but not updated after retraining creates false assurance.
5. Accountability and Human Oversight
Accountability requires identifiable responsibility. “The algorithm decided” is not an acceptable allocation of responsibility. Organisations should specify who owns the system, who approves release, who monitors performance, who handles complaints and who can suspend operation.
A responsibility matrix can distinguish:
Accountable owner: bears organisational responsibility for the system’s purpose and risk.
Technical team: develops, tests and maintains the model.
Data steward: manages provenance, access, quality and retention.
Domain expert: assesses contextual validity and consequences.
Risk, legal or compliance function: reviews obligations and controls.
Operator or decision-maker: uses outputs within defined authority.
Independent reviewer: challenges assumptions and evidence.
Human oversight is meaningful only when the human has competence, time, authority, relevant information and the ability to override or stop the system. A nominal “human in the loop” who merely accepts automated recommendations is automation bias, not effective oversight. High-impact systems may require pre-deployment approval, mandatory review of uncertain or adverse cases, audit sampling, appeal routes and an emergency shutdown process.
Automation should be calibrated to the task. Humans are not automatically more accurate or less biased than models. The design question is whether a human–AI arrangement produces safer and fairer decisions than either component alone.
6. Security of Neural-Network Systems
AI security covers the model, data, software supply chain, interfaces, infrastructure and operational processes.
Threats
Data poisoning: an attacker inserts or modifies training examples to influence behaviour.
Backdoor or Trojan attacks: a model behaves normally except when a trigger causes a targeted malicious output.
Evasion attacks: carefully modified inputs cause incorrect predictions during operation.
Model extraction: repeated queries are used to approximate or copy a model.
Membership inference: an attacker infers whether a particular record was in training data.
Model inversion: outputs are used to infer sensitive attributes or reconstruct representative inputs.
Prompt or input manipulation: untrusted content changes the behaviour of a model-connected application.
Availability attacks: resource exhaustion or malicious requests prevent legitimate service.
Controls
Security should follow defence in depth:
Establish asset inventories for datasets, models, credentials, endpoints and dependencies.
Apply least privilege, strong authentication, network segmentation and secrets management.
Verify dataset provenance and use checksums, signed artefacts and controlled repositories.
Scan code and dependencies; pin versions and patch vulnerabilities.
Separate development, testing and production environments.
Use input validation, rate limiting, monitoring and abuse detection.
Test robustness with threat modelling, red teaming and adversarial evaluation.
Log access, predictions, model versions and administrative changes without unnecessarily recording personal data.
Prepare incident response, rollback, model quarantine and communication procedures.
Confidentiality, integrity and availability must be considered together. A model may be confidential yet unsafe if its integrity is compromised; it may be accurate yet unusable if availability is poor.
7. Regulatory and Standards Landscape
The regulatory environment varies by jurisdiction and application. Students should distinguish binding law from voluntary standards and should obtain current legal advice for operational decisions.
The General Data Protection Regulation (GDPR) applies to relevant processing of personal data and includes principles such as lawfulness, fairness, transparency, purpose limitation, data minimisation, rights of access and, in specified circumstances, safeguards concerning solely automated decisions. It also requires appropriate security and accountability. GDPR compliance is not equivalent to general AI ethics; a system may comply with data-protection rules while still producing unacceptable social harm.
The EU AI Act adopts a risk-based regulatory approach, including prohibited practices, requirements for high-risk systems, transparency obligations and duties for certain providers and deployers. Obligations depend on role, system classification and use case. The Act should be read in its current official form because implementation dates and guidance matter.
The NIST AI Risk Management Framework organises risk management around Govern, Map, Measure and Manage. It is voluntary, but useful for structuring organisational processes. ISO/IEC 42001 specifies requirements for an AI management system, while ISO/IEC 23894 provides guidance on AI risk management. Sector rules, equality law, consumer-protection law, medical-device regulation, cybersecurity obligations and procurement requirements may also apply.
A compliance programme should create a traceable relationship among obligation, risk, control, evidence and responsible owner. Compliance checklists alone are weak if they do not alter engineering decisions or provide effective remedies.
Performance, fairness, privacy, robustness and usability results
Approve, conditionally approve or reject
Deployment
Monitoring, human oversight, appeals, incident response
Release, pilot or defer
Operation
Drift, incidents, complaints, audits and changes
Maintain, retrain, suspend or retire
A risk register should record hazard, affected party, likelihood, severity, controls, residual risk, owner and review date. Risk acceptance should be explicit and authorised at an appropriate level rather than silently embedded in technical decisions.
9. Illustrative Case: Automated University Scholarship Screening
Background
A university develops a neural network to prioritise scholarship applications. It uses academic history, household information, personal statements and previous award data. The proposed output is a priority score for human scholarship officers.
Problem
Historical awards were concentrated among applicants from well-resourced schools. Some applicants have incomplete records because of disability, displacement or limited access to technology. The university is concerned about privacy, indirect discrimination and excessive reliance on the score.
Analysis
The historical award label may reflect past institutional preferences rather than genuine scholarship potential. School attended and postcode may act as proxies for socioeconomic status or ethnicity. Personal statements may contain sensitive information. A high overall validation score could conceal poor performance for small or marginalised groups. The system also creates a security target because a leaked score could affect applicants’ privacy and confidence.
Approach and solution
The university first defines the system as decision support, not automatic rejection. It removes unnecessary direct identifiers, establishes a documented legal basis, limits access and sets a retention period. It conducts a data-protection impact assessment and consults students, disability services, admissions staff and legal advisers.
The team audits label quality and creates a more defensible outcome definition. It evaluates recall, false-positive rates and calibration by relevant groups, including intersectional groups where sample sizes permit. Sensitive attributes are restricted to auditing and are not casually exposed to operational users. Missingness is analysed as a possible signal of disadvantage rather than simply imputed and ignored.
Before deployment, independent reviewers examine the model card, fairness results, security tests and explanation design. Officers receive training on uncertainty and automation bias. Every adverse recommendation receives human review, applicants receive an explanation and appeal route, and the university monitors outcomes each cycle. A rollback procedure disables the model if disparities or data leakage exceed predefined thresholds.
Outcome
The university finds that the original model’s apparent accuracy depended substantially on school-related variables. After redesign, predictive performance is slightly lower overall, but group-level error disparities decrease and officers report better contextual understanding. The system is piloted for one cycle rather than used for automatic ranking. A governance committee reviews complaints, monitoring results and whether the model remains justified.
Learning points
A historical label is not automatically a legitimate target.
Excluding protected attributes does not eliminate proxy discrimination.
Human oversight must include authority, training and an appeal mechanism.
Privacy, fairness and security controls must be designed together.
A lower aggregate score may be acceptable when it reduces serious harms and improves legitimacy.
10. Challenges and Limitations
Responsible AI practices have unavoidable limitations. Fairness metrics can conflict, and small samples may make subgroup estimates uncertain. Privacy protections can reduce data utility. Explanations can be incomplete or misleading. Documentation can become bureaucratic if it is not connected to decisions. Audits provide evidence at a point in time, whereas models and social contexts change. Independent auditing also raises questions about access to confidential data, auditor competence and conflicts of interest.
There are deeper limits to technical fixes. A biased institution cannot be made fair merely by changing a loss function. Some uses are inappropriate even if a model is accurate. A system that predicts hardship may be statistically valid but ethically wrong if used to deny assistance rather than provide support. Responsible governance therefore requires institutional judgement, participation by affected communities and willingness to discontinue systems.
11. Contemporary Developments and Best Practice
Current practice is moving toward continuous assurance rather than one-time certification. Important developments include AI incident databases, algorithmic impact assessments, privacy-enhancing computation, secure model supply chains, red-teaming, synthetic-data evaluation and governance for foundation models. Generative and multimodal systems introduce additional concerns, including data provenance, copyright, hallucination, tool-use permissions, prompt injection and the disclosure of confidential context.
A mature organisation should:
begin with a documented purpose and harm analysis;
maintain data and model provenance;
test performance, fairness, privacy and security before release;
use independent review for high-impact systems;
provide understandable notices and effective challenge mechanisms;
monitor drift, incidents and subgroup outcomes;
preserve audit evidence while minimising personal data;
assign clear ownership and escalation authority;
train staff in both technical limitations and ethical duties; and
suspend or retire systems when risks cannot be adequately controlled.
Chapter Summary
Responsible AI is a lifecycle approach to ensuring that neural networks are lawful, secure, fair, explainable, accountable and subject to meaningful human control. Privacy requires purpose limitation, minimisation, appropriate legal basis, retention control and technical safeguards. Fairness requires contextual analysis of labels, representation, errors and group impacts; no single metric resolves every conflict. Transparency is audience-dependent and must be supported by accurate documentation such as datasheets, model cards, impact assessments and change logs. Accountability requires named owners, evidence and remedies, while human oversight requires competence and authority rather than ceremonial approval. Neural networks face poisoning, evasion, extraction, inference, supply-chain and availability threats, requiring defence-in-depth security. Frameworks such as NIST AI RMF and ISO/IEC 42001 support governance, while laws such as the GDPR and EU AI Act create context-dependent obligations. Ultimately, responsible AI is socio-technical: technical controls are necessary but cannot replace institutional judgement, stakeholder participation and the willingness to reject harmful uses.
Key Terms
Responsible AI: Development and use of AI that addresses ethical, legal, social, safety and technical responsibilities.
AI governance: Structures, policies and processes used to direct, control and oversee AI systems.
Purpose limitation: Restricting data use to specified and legitimate purposes.
Data minimisation: Collecting and processing only data necessary for the intended purpose.
Consent: An informed and freely given agreement to specified processing or participation.
Pseudonymisation: Replacing identifying information with substitutes while retaining a possible re-linking mechanism.
Differential privacy: A formal privacy guarantee limiting how much an output changes when one person’s data is added or removed.
Fairness: The ethical and legal requirement that benefits, burdens and errors are not unjustifiably distributed.
Demographic parity: Similar positive prediction rates across defined groups.
Equal opportunity: Similar true-positive rates across groups.
Calibration: Agreement between predicted probabilities and observed frequencies across groups.
Transparency: Providing relevant information about a system to appropriate stakeholders.
Explainability: The ability to communicate or analyse why a model produced an output.
Accountability: The assignment of responsibility and obligation to justify decisions and remedy harm.
Human oversight: Competent human supervision with information, authority and ability to intervene.
Model poisoning: Manipulation of training data or processes to compromise model behaviour.
Evasion attack: Deliberate input modification intended to cause an incorrect prediction.
Model card: Documentation describing a model’s uses, limitations, evaluation and performance.
Risk register: A controlled record of risks, impacts, controls, owners and review status.
AI impact assessment: A structured evaluation of likely effects and safeguards before or during deployment.
Review Questions
Short Answer Questions
Why is responsible AI described as a lifecycle discipline rather than a final testing step?
Distinguish pseudonymisation from anonymisation.
What is the difference between equal opportunity and equalised odds?
Identify three artefacts that support AI accountability.
Why is a nominal human reviewer insufficient for meaningful human oversight?
Long Answer Questions
Explain how privacy, consent, data minimisation and retention should be integrated into neural-network development.
Compare demographic parity, equal opportunity, equalised odds and calibration, including circumstances in which their objectives may conflict.
Discuss the role of documentation in transparency, reproducibility, audit and regulatory compliance.
Describe a defence-in-depth security programme for a production neural-network service.
Compare the contributions and limitations of the GDPR, EU AI Act, NIST AI RMF and ISO/IEC 42001.
Analytical / Application Questions
A loan model has equal overall accuracy across two groups but a substantially higher false-positive rate for one group. Analyse the implications, identify additional evidence required and recommend possible actions.
Design a governance gate review for a hospital neural network that predicts patient deterioration. Specify evidence, responsible roles, monitoring requirements and conditions for suspension.
A model developer proposes removing race and gender from the training data as the sole fairness intervention. Critically evaluate the proposal and design a more rigorous fairness-assessment plan.
Multiple Choice Questions with Answers
Question 1
Which principle requires an organisation to collect only data necessary for a specified AI purpose?
A. Data minimisation
B. Model extraction
C. Equalised odds
D. Availability
Correct Answer: A. Data minimisation
Question 2
For a binary classifier, which quantity is calculated as TP ÷ (TP + FN)?
A. False-positive rate
B. True-positive rate
C. Precision
D. Demographic parity
Correct Answer: B. True-positive rate
Question 3
Which statement best describes meaningful human oversight?
A. A human automatically accepts every model recommendation
B. A human has competence, relevant information and authority to intervene
C. A model is retrained without human review
D. The source code is published publicly
Correct Answer: B. A human has competence, relevant information and authority to intervene
Question 4
What is the primary purpose of a model card?
A. To encrypt model weights
B. To document intended uses, limitations and evaluation results
C. To replace incident response
D. To guarantee demographic parity
Correct Answer: B. To document intended uses, limitations and evaluation results
Question 5
An attacker inserts malicious examples into a training dataset to influence model behaviour. What type of attack is this?
A. Data poisoning
B. Model inversion
C. Rate limiting
D. Calibration
Correct Answer: A. Data poisoning
Question 6
Which fairness criterion requires similar true-positive rates across groups?
A. Demographic parity
B. Equal opportunity
C. Availability
D. Pseudonymisation
Correct Answer: B. Equal opportunity
Question 7
In differential privacy, a smaller ε generally represents what, assuming the mechanism and composition are otherwise comparable?
A. Stronger privacy
B. Higher model accuracy by definition
C. More available training data
D. A guaranteed absence of bias
Correct Answer: A. Stronger privacy
Question 8
Which NIST AI Risk Management Framework function concerns identifying and contextualising risks?
A. Map
B. Render
C. Compile
D. Automate
Correct Answer: A. Map
Question 9
Why does removing protected attributes from training data not necessarily eliminate discrimination?
A. Neural networks cannot process numerical data
B. Correlated variables may act as proxies
C. Encryption creates demographic bias
D. Documentation changes the labels
Correct Answer: B. Correlated variables may act as proxies
Question 10
Which control most directly supports recovery after a harmful model update?
A. A rollback procedure with versioned model artefacts
B. Removing all monitoring logs
C. Increasing the number of hidden layers
D. Publishing personal training records
Correct Answer: A. A rollback procedure with versioned model artefacts