Your model passes validation, the latency numbers look healthy, and the rollout meeting is on Thursday. None of that tells you whether the system will treat a 61-year-old applicant the same way it treats a 29-year-old one, or whether anyone on your team could explain a rejection to the person who received it.
Ethics reviews often arrive too late, once the architecture is frozen and the launch date has been announced. The useful work happens earlier, while changes are still cheap. A model that needs a new data source is a two-week conversation in March and a quarter-long rebuild in September. What follows is a working checklist built around five areas: bias, transparency, privacy, accountability, and monitoring.
Bias: Test the Edges, Not Just the Average
Overall accuracy is a comfort metric. It hides the cases that generate complaints, appeals, and news coverage. A model with 94% accuracy can still be wrong half the time for the smallest group in your dataset — and that group is usually the one with the least patience for being wronged.
Before deployment, break your evaluation set into slices that reflect the people the system will actually meet: age bands, gender, language, region, disability status, and any group your organisation has historically served poorly. If a slice has too few examples to measure, that is itself a finding: you do not know how the system behaves for those people.
Compare more than accuracy. Look at false positives and false negatives separately, because they carry different costs. A fraud model that flags older customers twice as often as younger ones creates a support burden and a fairness problem even if its headline precision never moves. A screening model that quietly misses qualified candidates from one university produces a less visible harm, but a harm nonetheless.
Hunt for proxies
Protected attributes are rarely in the feature set, but their shadows often are. Postcode, device model, employment gaps, and the time of day a form was submitted can all carry group information. Run a simple check: train a small model to predict the protected attribute from your remaining features. If it succeeds, you have a proxy, intended or not.
Sometimes a proxy is defensible. Postcode can encode genuine risk in insurance pricing. The question is not whether a feature correlates with a protected group, but whether you can justify using it and whether you have measured the disparity it produces.
Question the labels
Labels encode human decisions. A hiring model trained on five years of promotion records learns the promotion patterns of that period, including the ones your company would now regret. Ask who created each label, under what policy, and whether that policy has changed since. If the answer is "a spreadsheet nobody remembers," treat the label as a hypothesis rather than a ground truth.
Transparency: Explain the Decision to the Person Who Received It
Two audiences need explanations, and they need different things. Regulators and internal reviewers want documentation: data sources, known limitations, evaluation results, intended use, and the cases where the model should not be used. Write that down before a request arrives, not during the week the regulator does.
Affected people need something plainer. "The model gave you a low score" is not an explanation. If a loan application is declined or a candidate is filtered out, the person should be able to learn the main factors involved and how to contest the outcome. Feature importance charts rarely satisfy this; a short, human-readable reason usually does.
If you cannot write the rejection letter in plain language, you do not yet understand your own model well enough to ship it.
Decide, too, whether people are told a system is involved at all. Routing decisions through a model and presenting them as human judgements is the fastest way to lose trust when it comes out. And it will come out — usually in a support ticket, occasionally in a headline.
Write the model card while it is fresh
A one-page summary — what the model does, what it was trained on, who it was evaluated against, and what it must not be used for — takes an afternoon to write and saves hours every time a new team asks. Keep it next to the code and version it alongside the model, so the description and the artefact never drift apart.
Privacy: Collect Less, Keep Less, Log Carefully
Every extra field is a future liability. Ask of each feature: could we explain why we hold this, and what happens if it leaks? Data minimisation is dull advice, and it prevents more incidents than any sophisticated privacy technique.
Worth checking before deployment:
- Training data provenance: do you have the right to use it for this purpose, and can you prove it?
- Retention: does anything get deleted automatically, or does everything live forever by default?
- Logs: are inputs and outputs stored in plain text somewhere engineers can browse?
- Third parties: does your model provider retain inputs, and under what terms?
- Re-identification: could someone join your "anonymised" dataset with another and recover individuals?
Obligations vary by country, sector, and the sensitivity of the data. For anything involving health, finance, employment, or children, have a qualified professional review the approach before you deploy rather than after.
Accountability: One Name, One Escalation Path
"The team owns it" usually means nobody owns it. Name one accountable person for the model in production, plus a deputy who covers absences. That person should be able to pause the system without asking a launch committee for permission.
Human review is only meaningful if the reviewer can disagree. If an operator approves almost every flagged case because overturning one takes three extra clicks and a note, you have automation with a rubber stamp attached. Give reviewers the information, time, and authority to override, then track how often they do. An override rate near zero is not proof the model is flawless; it is evidence the review is decorative.
Write the remedy down as well. When the model is wrong, what happens: a refund, a re-run, an apology, a manual review? Decisions made calmly in advance beat decisions made during an incident.
Monitoring: The Deployment Is the Starting Line
Performance measured in a notebook is a snapshot. Production is a moving target: user behaviour shifts, upstream pipelines change, and the world the model learned about quietly stops resembling the world it now faces.
Set up alerts for input drift — the distribution of features your model actually receives — and for output drift, the balance of decisions it makes. Neither tells you the model is wrong, but a sudden shift in either is a reason to look. Track the slice metrics from your bias review on live traffic, not just on the frozen test set, and re-run the full evaluation on a schedule rather than waiting for someone to complain.
Add a feedback channel that reaches people who can act. Support agents hear about failures months before the metrics do, and a complaint that disappears into a ticket queue is a signal you paid for and threw away.
The Trade-offs You Cannot Avoid
Fairness definitions conflict with one another. You generally cannot equalise false positive rates and false negative rates across groups at the same time unless the model is nearly perfect or the base rates are identical. That is a mathematical result, not an engineering failure.
So the honest move is to choose deliberately and say so. Decide which error you would rather make, for whom, and why, and write the reasoning down next to the evaluation results. A documented trade-off is defensible; an undocumented one looks like an oversight the moment somebody examines it.
A Pre-Launch Gate
Before the rollout meeting, confirm the following, in order:
- Slice metrics are measured, not assumed, and every group large enough to evaluate has been evaluated.
- A proxy check has been run against the feature set, and the results are recorded.
- Each decision type has a plain-language explanation and a documented route to appeal.
- Retention and logging have an owner and an expiry date.
- One named person can pause the system, and they know it.
- Drift alerts and slice monitoring are live before the first real request arrives.
None of these steps is glamorous. Together they are the difference between shipping a model and shipping a problem. The checklist is short enough to finish this week, which is the point — the cheapest time to make a system fair is before anyone depends on it.
Photo: DS stories / Pexels
