Responsible AI: fairness, reliability, transparency, explainability and accountability

Why this matters

Responsible AI sounds like an ethics committee's business, and in many organisations it starts there. It ends up on the security team's desk for a plain reason: every responsible-AI principle, once you try to prove it, turns into a control with an owner, a test and evidence. "Our hiring model is fair" is a claim. "Selection rates across groups are measured on every retrain and a gap above an agreed threshold blocks release" is a control, and it looks exactly like the release gates lesson 9 described for guardrails.

The other reason is that a failure of any principle is experienced as an incident. A support chatbot that answers one customer politely and the next abusively, a credit model nobody can explain to a regulator, a code assistant that gives different answers to the same question on different days: each one produces a complaint, an escalation and a request for logs, and the people asked to reconstruct what happened are usually the security and operations teams.

This lesson takes the principles one at a time and asks the same question of each: what would you measure, and who would act on the measurement? Scenario questions in this area tend to reward the answer that converts a value into something checkable, and to treat the answer that writes another statement of values as the distractor.

The lesson

Fairness and inclusiveness, measured rather than asserted

Fairness means a system's outcomes do not systematically disadvantage people because of a protected or sensitive characteristic, directly or through a proxy. The proxy is the part practitioners underestimate. Removing a column called gender or ethnicity from the training data does not remove the signal, because postcode, first name, school, employment gaps and purchasing patterns can carry it. A model trained on historical decisions learns the historical pattern, including whatever bias produced it.

Fairness becomes testable once you choose a metric, and there are several, each answering a different question:

• Demographic parity: do groups receive the favourable outcome at similar rates?
• Equal opportunity and equalised odds: among people who genuinely qualify, are they approved at similar rates, and are error rates similar across groups?
• Calibration: when the model says 70% likely, is it right about 70% of the time for every group?

These cannot in general all be satisfied at once when the groups' underlying rates differ, so choosing the metric is a decision with consequences, and it belongs to an accountable business owner with legal and HR input, not to whoever happens to build the evaluation. The security professional's contribution is the mechanism: the metric is computed on a held-out set that includes the relevant groups, recorded on every retrain, and compared against a threshold agreed in advance.

Inclusiveness is the wider design question of who the system works for. A voice assistant that misrecognises some accents, a chatbot that only works well in one language, an interface that a screen reader cannot use: none of these may show up as a bias metric, because the people failed by them often do not appear in the evaluation data at all. The control is representative testing, including users with disabilities and non-native speakers, and treating "who did we not test with?" as a standing review question.

Reliability, safety and consistency of behaviour over time

Reliability is whether the system does what it is meant to do, under the conditions it will meet, at a known error rate. Safety is whether it avoids causing harm when it fails or is misused. They are different: a medical triage assistant can be reliable on average and still unsafe if its rare errors fall on the most urgent cases.

Generative models add a property traditional software rarely needed stated explicitly: consistency. The same question can produce different answers because sampling is non-deterministic, because the provider changed the model behind a stable name, because a system prompt was edited, or because the retrieval index in a RAG application now returns different documents. Consistency does not mean identical wording; it means answers that do not contradict one another on matters of fact or policy.

Consistency over time is maintained with ordinary engineering discipline applied to unfamiliar components:

• Pin model versions where the provider allows it, and treat a version change as a change requiring evaluation, as lesson 27 described for model testing in a pipeline.
• Keep a regression set of prompts with known-good answers, and run it on every change to the model, the prompt template or the retrieval corpus.
• Lower randomness for tasks where variation is a defect rather than a feature, such as policy answers or classification.
• Monitor live behaviour for drift, using the baselines from lesson 15, because the world the model answers questions about changes even when the model does not.

Safety additionally needs defined failure behaviour. When the model is uncertain, out of scope or receives a request it should not serve, what does it do? A safe design answers that explicitly: refuse, hand over to a person, or fall back to a deterministic path. A scenario describing a system that "made something up" when it lacked information is usually asking for this missing fallback.

Transparency and explainability, and the difference between them

These two are paired so often that they are treated as synonyms. They are not, and a question can turn on the difference.

Transparency is openness about the system: that AI is being used at all, what it is for, what data it was built from, what it is known to get wrong, and who is responsible for it. It operates at the level of the system and is delivered through documents and notices. Model cards describe a model's intended use, evaluation results and limitations. Datasheets for datasets describe how data was collected and what it contains. A chatbot telling users they are talking to an AI is transparency, as is publishing that an HR screening tool is in use.

Explainability is the ability to account for a particular output: why this applicant was declined, why this transaction was flagged. It operates at the level of the individual decision. Techniques depend on the model. A decision tree or a scoring model with few features can be explained directly. Complex models are usually explained after the fact with feature attribution methods such as SHAP or LIME, which estimate how much each input contributed, or with counterfactual explanations ("had the income been higher, the outcome would have changed").

Two cautions matter in practice. First, an attribution method produces an approximation of the model's behaviour, not a readout of it, so treat it as evidence rather than proof. Second, a large language model asked to explain its own answer produces a plausible narrative, generated the same way as the answer; it is not a reliable account of the computation. Where a decision needs to be explained to the person affected or to a regulator, that is an argument for using an inherently interpretable model for that decision, or for keeping the generative model in an advisory role with a human making and recording the decision.

A system can be transparent and unexplainable (everyone knows a complex model scores loan applications, nobody can say why one was declined) or explainable and opaque (each decision can be accounted for, but users were never told an algorithm was involved). The exam-style trap is offering a transparency measure, such as a published model card, as the answer to an explainability problem, such as a customer demanding reasons for a specific refusal.

Privacy, security and accountability as responsible-AI principles

Privacy as a responsible-AI principle is broader than confidentiality. It covers whether personal data should be used for this purpose at all, whether people were told, whether the model can reveal information about individuals in its training data, and whether outputs infer sensitive facts nobody disclosed. The controls are the ones lessons 13 and 14 covered: minimisation, anonymisation, masking and encryption, plus the model-specific risks of inversion and membership inference from lesson 19.

Security in this list means the system resists deliberate misuse and attack: prompt injection, poisoning, model theft and the rest of this course. Its inclusion among responsible-AI principles is a useful argument when budgeting, because it ties security work to commitments the organisation has already made publicly.

Accountability is the principle that makes the others enforceable. Every AI system has a named owner who answers for its behaviour; decisions are logged with enough context to reconstruct them; there is a route for an affected person to challenge an outcome and reach a human; and there is authority to suspend the system. A scenario in which a harmful output occurs and three teams each say it belongs to another is describing an accountability failure, and the answer is an owner and a record, not a better model. The roles that hold these responsibilities are the subject of lesson 29.

Awareness training that changes how people use AI at work

Most AI risk in an ordinary organisation is created by well-meaning staff: pasting a customer spreadsheet into a public chatbot, accepting generated code without review, trusting a summary of a contract that omitted a clause, or connecting an unapproved assistant to a mailbox. Policy alone does not reach these people at the moment they decide. Training does, if it is designed to change behaviour rather than to record attendance.

Training that works has a few recognisable features:

• It is concrete and local. It names the approved tools, shows where to find them, and shows which data classes may go into each. "Be careful with AI" changes nothing; "customer records never go into anything except the internal assistant" does.
• It is role-based. Developers need secure use of code assistants and review of generated code. Analysts need to verify summaries against sources. Managers need to recognise deepfake voice and video in approval requests, covered in lesson 23. Builders of AI systems need the responsible-AI principles above as engineering requirements.
• It teaches verification habits, especially that fluent output is not evidence of correct output, and that the person who uses an AI result owns it.
• It tells people what to do when it goes wrong: whom to report an accidental disclosure to, and that early reporting is welcomed.
• It is measured. Useful measures are behavioural: reduced traffic to unsanctioned AI services, data-loss alerts per user over time, reports of suspected AI-generated phishing.

A scenario that describes repeated leakage despite a written policy is usually pointing at training as the missing control, often paired with a sanctioned alternative, which lesson 33 treats in detail.

What the exam is really asking

Questions here usually describe a symptom and ask which principle failed or which measure addresses it. Map the symptom first: unequal outcomes is fairness; different answers to the same question is consistency; users unaware AI was involved is transparency; nobody can say why one decision was made is explainability; nobody owns the outcome is accountability. Then prefer the answer that makes the principle measurable and assigns someone to act.