Why AI safety matters
AI safety is engineering, not preaching — it is the work of measuring who a model fails, how badly, and what happens next.
- 11 min read
- 3 reading levels
- Updated
Read these first
On this page 9
One lesson, three depths. Pick the one that fits you today — you can switch any time.
Beginner — No maths. Plain English.
The short answer
AI safety is the work of finding out who your model fails, before your users find out.
The analogy you have already lived
Think of the brakes on a bus. Nobody buys a ticket because the brakes are good. Nobody thanks the mechanic who checked them. But the day they fail, nothing else about the bus matters.
Safety work in AI is brake work. It is unglamorous, it is measurable, and it decides whether the useful thing stays useful.
Why this had to become a discipline
A model does not know what it is being used for. It produces an output for every input you hand it, including inputs it has never seen anything like.
That is fine when the output is a film recommendation. It stops being fine when the output decides a loan, a medical referral, a visa, or a job interview.
Three things changed in the last few years, and together they made this urgent.
Models got deployed into decisions. Ten years ago a model produced a chart for a human. Now it produces an action.
Models got hard to inspect. A rulebook can be read. A network with billions of numbers inside it cannot.
Models got handed to the public. Anyone can type anything into them, including people who want them to misbehave.
The one number that fools everyone
Here is the trap that catches almost every new team.
Suppose you build a screening tool for a disease that one person in a hundred actually has. You build a model that says "healthy" to everybody, every time. It never looks at the patient.
That model is right ninety-nine times out of a hundred. Its accuracy is excellent. It is also worthless, because it catches nobody.
Accuracy hides rare failures. And rare failures are the ones that hurt people, because rare things are usually the important things: the fraud, the tumour, the fire.
How a safety review actually works
a model that scores well on average
|
v
[ break the test set into groups ] women / men, city / village,
| old phone / new phone, rare class
v
[ score each group separately ] -> where is it worst?
|
v
[ ask: what happens when it is wrong? ]
|
v
[ can a person notice, appeal, or switch it off? ]Notice that only the first two boxes are about the model. The rest are about the system around it.
Where you have already seen this go wrong
- Photo apps that tagged some people's faces correctly and other people's faces badly.
- Voice assistants that understand some accents far better than others.
- Auto-complete that finishes a sentence with something offensive.
- A chatbot that confidently invents a refund policy that does not exist.
None of these were caused by a villain. Every one of them was caused by an average number looking healthy.
What is honestly hard here
You cannot test for a harm you have not imagined. That is the deep, unsolved part.
There is no checklist that guarantees safety, and anybody who sells you one is selling comfort. What you can do is narrow the gap. Test on the groups you serve. Watch what happens after launch. Keep a way to switch the thing off.
That is not a moral position. It is the same discipline as load-testing a server.
Remember this
- One average number can hide a total failure on the group that matters most.
- Safety is measured per group and per consequence, never overall.
- Half the work is outside the model: monitoring, appeals, and an off switch.
What to learn next
- Bias in datasets — where most real failures are born.
- Fairness metrics — turning "is it fair" into numbers you can test.
- Model evaluation — the measurement toolkit this section builds on.
Developer — Code and libraries.
What safety work looks like as code
This whole section rests on one habit: never accept a single scalar as evidence that a model is fine. Let us make that concrete with the smallest possible example.
Setup
pip install numpyNo GPU, no download, runs in under a second.
The accuracy paradox, measured
import numpy as np
rng = np.random.default_rng(0)
N = 10_000
PREVALENCE = 0.01 # 1 in 100 people actually have the disease
truth = (rng.random(N) < PREVALENCE).astype(int)
# "Model A" is the laziest possible screener: it says no to everybody.
pred_a = np.zeros(N, dtype=int)
# "Model B" is a real screener. It catches most sick people and false-alarms sometimes.
sick_caught = rng.random(N) < 0.80 # sensitivity on the sick
false_alarm = rng.random(N) < 0.05 # false-positive rate on the healthy
pred_b = np.where(truth == 1, sick_caught, false_alarm).astype(int)
def report(name, pred):
tp = int(((pred == 1) & (truth == 1)).sum())
fp = int(((pred == 1) & (truth == 0)).sum())
fn = int(((pred == 0) & (truth == 1)).sum())
tn = int(((pred == 0) & (truth == 0)).sum())
acc = (tp + tn) / N
recall = tp / (tp + fn) if tp + fn else 0.0 # of the sick, how many did we catch
precision = tp / (tp + fp) if tp + fp else 0.0 # of the alarms, how many were real
# a missed illness costs a hundred times what a needless extra test costs
harm = 100 * fn + 1 * fp
print(f"{name:8s} accuracy={acc:.4f} recall={recall:.2f} precision={precision:.2f} "
f"missed_sick={fn} false_alarms={fp} harm={harm}")
report("Model A", pred_a)
report("Model B", pred_b)Model A accuracy=0.9911 recall=0.00 precision=0.00 missed_sick=89 false_alarms=0 harm=8900 Model B accuracy=0.9484 recall=0.84 precision=0.13 missed_sick=14 false_alarms=502 harm=1902
Read that output before you read anything else
Model A wins on accuracy and loses on everything that matters. It scores 0.9911. It is a single line that ignores the patient. Ship it and eighty-nine sick people go home untreated.
Model B looks worse and is better. Accuracy drops to 0.9484. Missed illnesses drop from 89 to 14.
Precision of 0.13 is not a bug. When a condition is rare, most positive alarms are false even with a good model. That is arithmetic, not incompetence. It is why screening tests are followed by confirmatory tests, and why a model's output should rarely be the final step.
The harm column is the honest scoreboard. It encodes a value judgement — one missed illness costs a hundred false alarms — and writing that ratio down forces the argument into the open. Every deployed model has such a ratio. Most teams never write it down, so it gets chosen by accident.
Line by line
rng = np.random.default_rng(0) seeds the generator, so your numbers match this page exactly. Real evaluation data is not seeded, and your numbers will move between runs. Report a confidence interval, not a point estimate, whenever a subgroup is small.
np.where(truth == 1, sick_caught, false_alarm) applies one error rate to the sick and a different one to the healthy. That is the standard way to simulate a classifier with known sensitivity and specificity, without training anything.
harm = 100 * fn + 1 * fp is the piece worth stealing. Replace accuracy with a cost-weighted score in your own evaluation script, and threshold choices stop being arbitrary.
Common mistakes
Reporting one accuracy number for a whole product. Break the test set into the groups your product actually serves, and report the worst group. If the worst group has 40 samples, say so — a small group makes a noisy estimate, not a trustworthy one.
Choosing the decision threshold by accident. A classifier outputs a score. Someone picks 0.5, usually because it is the default. That number is a policy decision about who gets missed. Choose it against your cost ratio.
Testing only on data that looks like training data. Deliberately build an off-distribution slice: blurry photos, code-mixed text, an older phone camera. Performance there is the number that predicts your first incident.
Treating safety as a launch gate rather than a loop. The world moves after launch. See monitoring and drift for the machinery that catches that.
Try it yourself
Change PREVALENCE to 0.001 and rerun. Watch Model A's accuracy climb toward 0.999 while its harm gets worse. Then set both harm weights to 1, and work out which model you would ship. The model did not change; your values did.
What to learn next
- Bias in datasets — where most real failures are born.
- Fairness metrics — turning "is it fair" into numbers you can test.
- Model evaluation — the measurement toolkit this section builds on.
Researcher — Mathematics and papers.
The vocabulary, made precise
"AI safety" covers several distinct research programmes that are often conflated. Keeping them separate makes the literature navigable.
Robustness — worst-case behaviour under perturbation or distribution shift. Formally, bounding $\max_{\delta \in \Delta} \mathcal{L}(f_\theta(x + \delta), y)$ over a perturbation set $\Delta$, rather than the expectation under the training distribution. Here $f_\theta$ is the model with parameters $\theta$, $\mathcal{L}$ the loss, $x$ an input, $y$ its label and $\delta$ an allowed perturbation. Covered in adversarial attacks.
Distributional fairness — constraints relating model behaviour across groups defined by a protected attribute $A$. Covered in fairness metrics.
Privacy — bounding what an adversary can infer about a training record from released model outputs. Covered in differential privacy.
Interpretability — recovering a human-checkable account of why $f_\theta$ produced a given output. Covered in explainability.
Alignment — whether the objective being optimised is the objective the deployer intended. This is the least formalised of the five, and the one where confident claims deserve the most suspicion.
Specification gaming and Goodhart
The failure that unifies the list is objective misspecification. You optimise a measurable proxy $\tilde{R}$ for an unmeasurable target $R$. Optimisation pressure then drives the system toward the region where $\tilde{R}$ and $R$ diverge most.
Manheim and Garrabrant (2018), Categorizing Variants of Goodhart's Law, decompose this into regressional, extremal, causal and adversarial variants. The taxonomy earns its keep: extremal Goodhart predicts that your proxy degrades precisely at the tail you optimised toward, and that tail is where deployment lives.
Krakovna et al. (2020) maintain a widely cited empirical list of specification-gaming instances in reinforcement learning agents. Read it as an existence proof — reward functions that looked complete to their authors routinely admit degenerate optima.
Risk decomposition
A useful framing for deployment review, adapted from safety engineering:
$$ \text{Risk} = \sum_{h} P(h) \cdot S(h) \cdot \big(1 - D(h)\big) $$
- $h$ — an identified hazard: one specific way the system produces a bad outcome.
- $P(h)$ — probability of occurrence per unit of exposure.
- $S(h)$ — severity if it occurs, in whatever unit the decision uses.
- $D(h)$ — the detect-and-recover factor: probability the failure is caught and reversed before harm lands.
Two consequences fall out. Hazards you did not enumerate contribute zero to this sum and non-zero to reality, so hazard enumeration dominates the exercise. And $D(h)$ is an engineering variable you fully control — logging, human review, staged rollout, rollback — which is usually far cheaper to raise than $P(h)$ is to lower.
Evaluation is the bottleneck
The empirical literature repeatedly finds that benchmark performance overstates deployed performance.
- Recht et al. (2019), Do ImageNet Classifiers Generalize to ImageNet? — rebuilding a test set with the original collection protocol produced accuracy drops of roughly 11 to 14 points across every model tested, with the ranking preserved. Absolute numbers on a reused benchmark are not estimates of deployed accuracy.
- Buolamwini and Gebru (2018), Gender Shades — commercial face classifiers with strong aggregate accuracy showed error rates up to 34.7% on darker-skinned women against 0.8% on lighter-skinned men. Disaggregation, not a new model, revealed it.
- Northcutt et al. (2021), Pervasive Label Errors in Test Sets — an average of 3.4% label errors across ten standard benchmarks, enough to reverse model rankings at realistic noise levels.
The methodological conclusion: a single aggregate metric on a static public benchmark is close to uninformative about deployment risk. Disaggregated evaluation with reported uncertainty, plus a held-out shifted slice, is the minimum defensible protocol.
Where the field is
Structured hazard analysis for ML is immature relative to aviation or medical devices, but converging. The NIST AI Risk Management Framework (2023) organises practice into Govern, Map, Measure, Manage. ISO/IEC 23894 (2023) covers AI risk management. Neither is a proof technique; both are process scaffolding that makes omissions visible.
Formal verification of neural networks — Katz et al. (2017), Reluplex — gives sound guarantees over small networks and bounded input regions. It does not scale to the models being deployed, and honest practice treats it as a research direction rather than a shipping tool.
Papers
- Amodei et al., Concrete Problems in AI Safety, 2016 — arxiv.org/abs/1606.06565
- Buolamwini and Gebru, Gender Shades, FAccT 2018
- Recht et al., Do ImageNet Classifiers Generalize to ImageNet?, 2019 — arxiv.org/abs/1902.10811
- Manheim and Garrabrant, Categorizing Variants of Goodhart's Law, 2018 — arxiv.org/abs/1803.04585
- Northcutt et al., Pervasive Label Errors in Test Sets, 2021 — arxiv.org/abs/2103.14749
- Hendrycks et al., Unsolved Problems in ML Safety, 2021 — arxiv.org/abs/2109.13916
What to learn next
- Bias in datasets — where most real failures are born.
- Fairness metrics — turning "is it fair" into numbers you can test.
- Model evaluation — the measurement toolkit this section builds on.