Responsibility, Law & Governance
Model Card
The package insert of a model: what it was built for, what it was trained on, where it is good, where it is dangerously weak, how it was tested. Honest model cards make limits visible before you find them in operation. When purchasing, the rule is: a vendor without a meaningful model card asks for trust where it owes evidence.
An example
A useful model card answers six things in two pages: What is the model intended for? What explicitly not? What was it measured against, and with what result? What data was it trained on? Where is performance weaker for which groups? And who is the contact? Most published cards answer the first three and evade the last three — which in itself is information.
A closer look
A short document about a model: purpose, training data in outline, measured performance, known limits, unsuitable uses. For your own systems the same format is worthwhile, because it forces you to write limits down.
Why it matters
The card is interesting less for purchased models than for your own systems. Whoever maintains such a page for every productive AI application in-house has, as a side effect, the system register that the EU AI Act presupposes anyway, and a way to hand over when responsibilities change. The effort is half a day per system, and the benefit shows at the first incident — when someone asks what the thing was actually approved for.
Commonly misunderstood
Manufacturer statements are self-reports. They do not replace measurement in your own use case; they only narrow down where measuring is worthwhile at all.
Where this term does its work in the magazine.
2 articles use the term or take up its principle.
From Science
Benchmark Performance ≠ Bedside Performance
A good average can hide precisely the cases in which a system becomes dangerous.Read the articleFrom Science