Responsible ML in a business
A model that runs every night is also a business decision that runs every night. This lesson shows you how to write down what the model is for, who owns each part, which changes need a person's approval, whether the people who change its numbers are helping, what it costs against what it earns, how to treat customer data, and how to switch a model off.
By the end you can
- Write a model card that the supply chain team can read and sign
- Map who owns the data, the pipeline, the model and the decision, with a RACI and an escalation path
- Tell a routine retrain from a change that needs business review, and log every decision
- Measure human overrides, learn from them, and spot both automation bias and distrust
- Put cost against value on one page, handle personal data in the churn model, and plan a model's retirement
The everyday picture
Think of the lift in an office building. Inside it there is a small certificate on the wall. It says the maximum load (8 people or 630 kg), when it was last inspected, which company maintains it, and the number to call when it stops. Nobody reads the engineering drawings, but everybody can read the certificate, and it tells them what the lift is for and what it is not for. It is not for moving a piano.
Behind the certificate there is a clear split of jobs. The building owner is answerable if the lift is unsafe. The maintenance company does the repairs. Anyone inside can press the alarm button, and every alarm goes into a logbook that the engineer reads. Cleaning the lift needs nobody's approval; replacing the motor needs a new inspection. And when the lift is too old, it is taken out of service on a planned date, with a notice on every floor, instead of being left to run until it fails. A model in a business needs the same certificate, the same split of jobs, the same logbook and the same planned ending.
A model card the business can read
In 2019 Margaret Mitchell and colleagues proposed the model card: a short document that travels with a model. Their template has sections for model details, intended use, factors (the groups and conditions that change performance), metrics, evaluation data, training data, results broken down by those factors, ethical considerations, and caveats. You have already produced most of the content in this course: the time-based backtest from Forecasting demand, the per-segment errors from Explaining and choosing models, the lineage from the model registry and the alert thresholds from Monitoring, drift and retraining. The card puts it in one place that people outside the data team will read.
Write it for two readers. The top half is for the person who acts on the output, here the supply chain lead and the store managers. It uses their units: order quantities, empty shelves, money. The bottom half is for the engineer on call at 01:00: the registry name, the features, the monitoring thresholds and the fallback.
The two most important sections are the shortest:
- Intended use names the decision, who makes it and when. "Suggest next-day order quantities for about 2.5 million store-product pairs, 4 days ahead, published every night by 01:30, reviewed by store managers."
- Out of scope lists the uses people will be tempted to try. Models get reused. Finance will see a forecast for every product in every store and ask to sum it into next quarter's sales budget. That is a different question: a 4-day store-level forecast tuned for ordering says little about revenue three months away. Writing it down now saves an argument later.
Give metrics by segment, never only the average: overall WAPE 24% against the 28-day baseline's 34%, festival weeks 35% against 58%, and the smallest store band at about 33%, as you found in ds-06. Then state the limits plainly: the model doesn't know about local events, recorded sales understate demand on stock-out days, and new products with under 8 weeks of sales get a rule instead.
A card goes stale fast, and a stale card is worse than none because people trust it. Keep it next to the code, let the training job fill the metrics table from the tracked run, and require a human update only when the use, the data or the limits change. The card's version should match the model version in the registry.
Data needs the same treatment. Timnit Gebru and colleagues proposed datasheets for datasets. For the training set that means writing down that about 2% of a day's till sales arrive after midnight, that stock-out days are removed from training, and who keeps the festival calendar up to date. Those are exactly the facts a new team member needs and cannot guess.
Quick check
The finance team asks to sum the nightly p50 forecasts into a quarterly sales budget. What does a good model card help you do?
The card exists to make this conversation short and polite. A new use is a change that goes through review. Approving it reuses a tool built for another question; retraining the ordering model for budgets would make it worse at its real job.