Model Cards and AI Documentation: What to Record About Every AI System

A model card is a one-to-three page record of what an AI system does, the data it runs on, where it breaks, how it was tested, and who's keeping an eye on it. Document every system this way and you can actually show accountability — which happens to line up almost point for point with what the EU AI Act (Regulation (EU) 2024/1689) and ISO/IEC 42001 expect you to produce on request. Put simply: if you can't describe a system on one page, you can't govern it.

Why Did Documentation Quietly Become a Compliance Requirement?

For most of the last decade, AI documentation was a nice-to-have — the sort of thing a research team wrote up when a paper was going out the door. Then AI moved into hiring, lending, health triage, and customer service, and the questions got sharper. Regulators and auditors began asking something blunt: what does this system do, what was it trained on, and how do you know it works? Miss that answer on paper and you've got nothing to point to on accountability — which is the load-bearing idea in nearly every framework that touches AI right now.

A model card answers those questions in one to three pages that anyone can pick up. Plain language: what the system is, what it's for, what it was built from, where it fails, who watches it. The nutrition-label comparison gets overused, but it fits — you're not handing over the recipe, just enough for a reasonable person to decide whether and how to use the thing.

What Belongs on a Model Card

Six areas cover it. And no, you don't need a machine-learning PhD to fill in most of them — you need to know how the system actually gets used in your shop.

1. Purpose and intended use. Say plainly what the system is meant to do, and — just as important — what it should *not* be used for. A tool built to summarize support tickets should say exactly that, and add that it's no substitute for medical, legal, or financial advice. Spelling out the intended use also draws the line that later tells you when someone has wandered off-label.

2. Data. Describe what the system was trained on or grounded in, and what it processes once it's running. Flag whether personal information is involved, where that data came from, and any gaps you know about — say, a résumé-screening model trained mostly on applicants from one industry. Under PIPEDA and Quebec's Law 25 you already need to know what personal information you hold and why, a job that starts with data discovery; the data section of a model card is where your AI work meets that obligation.

3. Limitations and known risks. Every model fails somewhere. Write down the failures you know about: languages it handles poorly, groups it may treat unevenly, moments when its confidence is misleading, and what it costs when it's wrong. Being candid here isn't a liability — it's the proof that you sized up the system before turning it loose.

4. Evaluation. How do you actually know it works? Note how it was tested, on what, and what came back — accuracy, error rates, fairness checks, or just a plain qualitative review for low-stakes tools. Put the date on it, because a model checked a year ago against stale data isn't the same system today.

5. Human oversight. Say who reviews the outputs, when, and with what power to overrule them. A card that reads "outputs are reviewed by a trained adjudicator before any adverse decision" tells a very different governance story than one that goes quiet on the question.

6. Ownership and change history. Name the person or team on the hook, the version, and the date of the last review. That's the difference between a living record and a one-time artifact gathering dust.

Why It Matters for the EU AI Act and ISO/IEC 42001

Sell into Europe, or run systems that touch people in the EU, and the EU AI Act — Regulation (EU) 2024/1689 — is your reference point now. It's risk-based, so the heaviest documentation and record-keeping duties land on high-risk systems: employment, credit, essential services. For those, technical documentation, logging, transparency to users, and human oversight aren't optional extras. A model card won't tick every box by itself, but it's the natural backbone — most of what the Act asks you to be able to show maps straight onto the six areas above.

ISO/IEC 42001, the international standard for AI management systems, comes at the same problem from the management side. It expects you to identify your AI systems, weigh their impacts, and keep the documentation current. Model cards are how a lot of organizations make that real: one card per system, and your inventory and your evidence get built in the same stroke.

Closer to home, Canada's proposed Artificial Intelligence and Data Act (AIDA), part of Bill C-27, points the same way for "high-impact" systems — keep records, describe how the thing works, be ready to explain how you're managing the risk. The bill is still in motion, but the habit is worth building now. It costs almost nothing and ages well no matter how the final text lands.

A Simple Template You Can Start Today

You don't need a governance platform to get going. A shared doc with these headings is plenty for a first pass:

• System name and version
• Owner / accountable person
• Purpose — what it does, in one or two sentences
• Not intended for — the off-label uses
• Data — training/grounding sources, whether personal information is involved, known gaps
• Limitations and risks — where it fails and what happens if it does
• Evaluation — how it was tested, results, date
• Human oversight — who reviews, when, override authority
• Last reviewed — date and by whom

Fill one out for your highest-stakes system first — the one making or shaping decisions about people. That single exercise tends to surface more governance gaps than a week of meetings ever will.

Making It a Habit, Not a Binder

The way this goes wrong isn't writing bad model cards. It's writing good ones once, then letting them quietly rot. So tie each card to a review rhythm: revisit it when the model changes, when the vendor pushes an update, or on a set schedule — quarterly for high-stakes tools, yearly for the rest. A card with a stale "last reviewed" date is worse than none, because it advertises oversight that isn't happening.

This article is general information, not legal advice; how these frameworks apply comes down to your specific systems and where you operate.

At Canuckt, we built Valdra so none of this has to live in a spreadsheet someone forgot about — an AI governance registry that holds purpose, data, limitations, evaluation, and oversight in one place, next to your other compliance documents, and nudges you when a card is due. Tool or shared doc, the discipline doesn't change: if you can't describe it on a page, you can't govern it.