AI Ethics, Risk & Compliance

A disaggregated audit of one ordinary classifier on UCI Adult — 48,842 records, income above or below $50k, with sex and race recorded and genuinely different base rates. The output is a report, not a model.

1. Train something unremarkable. Gradient boosting on the standard features with no fairness intervention, so there is a headline accuracy to disaggregate.
2. Establish base rates first. Before touching the model, report the positive rate per group in the data itself. Some of what you are about to find is in the world, not in the classifier.
3. Four metrics, three cuts. Demographic parity difference, equalised-odds difference, true positive rate and positive predictive value — by sex, by race, and by both together. Fairlearn does the arithmetic.
4. Show the conflict. Demographic parity and equalised odds cannot both hold when base rates differ. Produce the numbers where they contradict each other rather than describing the result in the abstract.
5. Choose, and defend it. Fix a deployment context — a lending decision, a hiring screen — pick one definition for it, and argue in a paragraph why the others are wrong there, naming who bears the cost of each error type.
6. Mitigate once. Per-group threshold adjustment or reweighting. Report what it fixed, what it cost in overall accuracy, and what it did to the other three metrics — mitigations always move something else.

Scope guard: one dataset, one model, one mitigation. If you want a second case, ProPublica's COMPAS analysis is the canonical worked example to read afterwards, not to redo.

A written threat model for one real LLM application you can actually inspect — a RAG assistant, a support bot, an internal agent with tool access. A hypothetical system produces a hypothetical threat model.

1. Draw the boundary first. One diagram: every input source, every tool or API the model can call, every data store it reads, and where output lands. Mark everything an untrusted user can influence.
2. Walk the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/). For each of the ten: applies or not, why, worst-case impact in one sentence, and the control that exists today.
3. Test the top three. Do not assert that prompt injection is possible — attempt it. Indirect injection through a retrieved document, data exfiltration via a tool call, and one jailbreak of the system prompt. Record exact inputs and outcomes.
4. Speak the security team's language. Map confirmed findings onto MITRE ATLAS techniques so the report slots into a process that already exists.
5. Rate honestly. Likelihood by impact for every gap, with the reasoning visible. Anything you did not test is marked untested, never "low".
6. Write the gap list. Prioritised, each with an owner and a proposed control. Where no control exists, say so plainly — an honest gap list is the deliverable, a reassuring one is worthless.

Scope guard: test only systems you are authorised to test, and stop at proof of concept — a screenshot showing injection worked, not a working exfiltration chain.

The three documents an enterprise procurement or audit team asks for, produced for one real system you can inspect: a model card, a datasheet for its data, and a risk register mapped to NIST's AI RMF.

1. Model card. Follow the Hugging Face model card structure — intended use, out-of-scope use, training data, evaluation results disaggregated by group, known limitations, and the date it was last evaluated.
2. Datasheet. Answer the Datasheets for Datasets questions for the training or retrieval corpus: motivation, composition, collection, preprocessing, distribution, maintenance. Where you do not know, write "unknown" — the unknowns are the finding.
3. Risk register. One row per risk, mapped to the four AI RMF functions — Govern, Map, Measure, Manage — with likelihood, impact, current control, owner and review date.
4. Evidence column. Every claim across all three documents carries a pointer: a test result, a config file, a policy document, or the words "no evidence".
5. Reconcile the three. Check the limitations in the model card against the risk register. Anything present in one and absent from the other is a real gap — close it or record why you did not.
6. Have it read. One engineer and one non-technical stakeholder read the pack; log every question they had to ask you. Those questions are the second draft.

Scope guard: one system documented to depth, not four documented shallowly. An honest "unknown" is worth more than a plausible sentence.

Two pages an organisation could adopt on Monday, written for one specific context — a 30-person engineering team, a university department, a clinic — because a policy that covers everyone covers nobody.

1. Three tiers, with real examples. Permitted without review, permitted with a named review, prohibited. Populate each with your organisation's actual work: drafting a customer email, generating code that touches payments, pasting client data into a consumer chatbot.
2. Rule the data by category. Public, internal, customer, regulated — say which categories may enter which class of tool. Never write rules against named products; the products change monthly.
3. One disclosure rule. What must be labelled as AI-assisted, to whom, and in what words. One sentence, not a paragraph of nuance.
4. Fix accountability. Whoever ships the output owns it, whatever produced it. Then name who resolves edge cases and how long they have to respond.
5. Test it on ambiguity. Write three genuinely borderline scenarios from your own context. Give the policy and the scenarios to three colleagues separately, and record their answers.
6. Revise until they converge. Every disagreement marks a sentence that is not doing its job. Rewrite and re-test until all three readers reach the same answer unaided.

Scope guard: two pages, no glossary, no exceptions process longer than the policy itself. If it needs a training session to interpret, it is not finished.