AI Model Cards and User Disclosure: Documenting Intended Use, Limitations, and What You Tell People (2026)

Answer first: A model card is a one-to-three-page structured document that states what an AI system is for, who it is for, how well it performs, where it breaks, and what it must not be used for. User disclosure is the much shorter, user-facing version of the same truth, delivered inside the product. You need both, and they are not the same artifact. As of 2 August 2026, Article 50 of the EU AI Act makes the user-facing half a legal obligation for systems that interact directly with people or generate synthetic content. The hardest section of a model card — Limitations — cannot be written from the model's evaluation logs. It has to come from watching real people use the thing.

Most teams get this backwards. They write the model card at the end, from the eval suite, as a compliance chore, and it reads like a spec sheet. Then they bolt on an "AI-powered" badge and call that disclosure. Both artifacts end up describing the system the team hoped to build rather than the one users received.

This guide covers what actually belongs in each section, which parts require user evidence, what Article 50 requires in practice, and the counterintuitive research on what happens to trust when you tell people something was made by AI.

What a model card is (and what it is not)

The format comes from Mitchell et al., "Model Cards for Model Reporting," published at FAT* 2019 (now ACM FAccT). The paper proposed short documents accompanying trained models that report performance disaggregated across groups and conditions rather than as a single headline number, because an aggregate accuracy figure reliably hides the subgroups where a model fails.

The paper's nine sections remain the reference structure:

A system card is the same idea one level up: it documents an assembled product — model plus retrieval plus prompts plus guardrails plus human review — rather than a single trained model. A datasheet for datasets documents the data. Most product teams shipping an AI feature in 2026 need a system card more than a model card, because almost nobody ships a raw model any more. The section structure is close enough that we use "model card" as the umbrella term throughout.

What a model card is not: marketing collateral, a threat model, or an eval report. It is the honest summary a competent outsider would need to decide whether to rely on your system.

The documentation gap is enormous, and it is worst exactly where it matters

Liang et al., "Systematic analysis of 32,111 AI model cards characterizes documentation practice in AI," published in Nature Machine Intelligence (2024), analysed every model repository on Hugging Face. The findings should embarrass the field:

• Of 74,970 model repositories, only 32,111 (44.2%) had a model card at all — though those documented models accounted for 90.5% of total download traffic, so the popular models are documented and the long tail is not.
• Section completion is wildly uneven. Training: 74.3%. Limitations: 17.4%. Evaluation: 15.4%. Environmental Impact: 2.0%.
• The average model card runs 191 words. The top 100 cards by downloads average 521 words — 2.73 times longer.
• Even among the top 100 most-downloaded models, the Limitations section appears in only 39%.

Read the pattern: teams document what they did (training) and skip what a user needs (limitations, evaluation). The two sections that tell someone whether they can safely rely on the system are the two least likely to exist. That is not a documentation-tooling problem. It is that nobody on the team has the evidence to fill them in, because nobody ran the study that would produce it.

The Mitchell et al. paper's core argument is that model performance reported as a single aggregate number "hides" disparate performance across the groups and conditions that actually matter — which is precisely why the Factors and Quantitative Analyses sections exist.

Article 50: the user-facing half became law on 2 August 2026

The EU AI Act's transparency obligations under Article 50 entered application on 2 August 2026. They are separate from, and much broader than, the high-risk regime — they attach to ordinary consumer and B2B products. In plain terms:

• Article 50(1) — Providers must ensure that AI systems designed to interact directly with natural persons inform those persons that they are interacting with an AI system, "unless this is obvious" to a reasonably observant person. Narrow carve-outs exist for legally authorised law-enforcement use.
• Article 50(2) — Providers of systems generating synthetic audio, image, video or text must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated, with solutions that are "effective, interoperable, robust and reliable as far as this is technically feasible." Assistive-editing functions are carved out.
• Article 50(4) — Deployers publishing deepfakes must disclose the content is artificially generated, except where it is "evidently artistic, creative, satirical, fictional." Deployers publishing AI-generated text on matters of public interest must disclose, unless the text underwent human review or editorial control with a named person holding editorial responsibility.
• Article 50(5) — The information must be given "in a clear and distinguishable manner at the latest at the time of the first interaction or exposure."

That last clause is the one product teams under-read. Disclosure buried in a settings page, a help-centre article, or a privacy policy does not satisfy "at the time of first interaction." It has to be at the point of contact.

For research teams specifically: an AI-moderated interview is an AI system interacting directly with a natural person. If you run AI interviews with EU participants, Article 50(1) is squarely in scope for the research instrument itself, on top of your existing GDPR lawful basis and informed-consent obligations. See The EU AI Act and User Research for the full compliance mapping and AI Governance for Customer Research for how this fits ISO 42001 and the NIST AI RMF.

The uncomfortable research: disclosure costs you credibility even when you deserve none of the penalty

Here is the finding that makes honest teams hesitate, and that you should design around rather than pretend away.

Altay and Gilardi, "People are skeptical of headlines labeled as AI-generated, even if true or human-made, because they assume full AI automation," PNAS Nexus (2024) ran two preregistered experiments with 4,976 US and UK participants. Labelling a headline as AI-generated lowered both its perceived accuracy and participants' willingness to share it — regardless of whether the headline was actually true or false, and regardless of whether a human or an AI wrote it.

Two details matter enormously for how you write your disclosure:

1. The penalty was roughly three times smaller than the penalty for a "false" label. AI-aversion is real but it is not the same as being called a liar. It is a discount, not a disqualification.
2. The mechanism was an assumption of full automation with no human supervision. Participants penalised the AI label because they read it as "nobody checked this."

That second point is actionable and almost nobody acts on it. If your disclosure says only "AI-generated," you inherit the full penalty. If it says what the AI did and what a human did — "drafted by AI, reviewed by our clinical team before publication" — you are addressing the actual inference driving the discount. Article 50(4) itself carves out human-reviewed editorial text; your UI copy should reflect the same distinction, because it is the distinction users are already making in their heads.

The design implication: disclosure copy is a research question, not a legal-review question. Test the wording the same way you would test onboarding copy.

Where each section's evidence actually comes from

The reason Limitations sits at 17.4% completion is that it is the only section you cannot generate from your own telemetry. Here is the honest sourcing map.

Two of these deserve emphasis.

"Out-of-scope uses" is an empirical claim, not a wish. Writing "not intended for medical advice" does not stop anyone. The useful version of that section says what people are doing with the system that you do not support, which requires asking them. A 30-participant study asking "what did you last try to use this for, and what happened" will populate this section faster than a quarter of speculation.

"Limitations" needs the failures users don't notice. AI failure mode analysis gives you the prospective taxonomy; AI red teaming with real users gives you adversarial coverage. But the limitation class that model cards most often miss is the silent one — where the output is wrong and the user accepts it without friction. That is automation bias, and it only shows up when you observe task outcomes rather than asking about satisfaction.

A working template you can fill in this week

Keep it to two pages. Length is not the point — the top-100 cards average 521 words, and they are the good ones.

1. What this is. One sentence a non-specialist understands. Version, date, owner, date of last evaluation.

2. Who it is for and what for. Primary users, primary tasks, the top three jobs it is meant to do.

3. What it must not be used for. The empirically observed misuses, not the imagined ones. Name them.

4. How well it works. Headline metric plus at least one disaggregation that could embarrass you — by user segment, input language, input length, or device. If every cut looks identical you have not cut finely enough.

5. Where it breaks. Named failure modes with rough frequency and observed user impact. Say which ones users detect and which they don't.

6. What humans do. Which steps have human review, which are fully automated. This is the section that determines how your disclosure copy lands.

7. What we don't know yet. Open questions, un-evaluated populations, the eval set's known gaps.

8. Who to contact and how to report a problem.

Then the user-facing disclosure, which is a different artifact: one or two sentences, at first interaction, naming the AI role and the human role, in the product's own voice.

How Koji helps

Sections 2, 3, 5 and 6 of that template are user-research outputs. The traditional way to get them is six weeks of scheduling, moderating and hand-coding — which is exactly why they end up blank. The modern approach is to run the study continuously and let it fill the document.

AI-moderated interviews that probe the misuse question properly. Ask a participant "is there anything you've tried that didn't work?" in a survey and you get "no." Koji's AI interviewer follows up on every non-answer, chases specifics, and asks what happened next — the follow-up probing that turns a shrug into a documented out-of-scope use. Running 60 of these takes an afternoon, not a quarter.

Structured questions give you the disaggregation. Koji supports six question types — open_ended, scale, single_choice, multiple_choice, ranking, and yes_no — in a single conversational study. That combination is what makes a model card's Factors section possible: the single_choice and scale answers give you the cuts, the open_ended answers explain them, and both come from the same session so you never have to reconcile a survey against a separate interview round. See Structured Questions in AI Interviews.

Automatic thematic analysis, so Limitations writes itself. Koji clusters failure reports across every transcript and surfaces frequency by theme, with quotes attached. What you paste into the Limitations section is a ranked list of real failures with evidence, not a paragraph of hedging.

Disclosure copy testing in a day. Write three variants of your Article 50 notice — bare "AI-generated," AI-plus-human-review, and a version that names the specific human step — and run them as a concept test. Given the Altay and Gilardi mechanism, the variant that names the human step should recover a meaningful share of the credibility discount. Test it rather than assuming it.

A disclosed AI interviewer, by construction. Koji tells participants they are speaking with an AI at the start of the session, which is the Article 50(1) posture research instruments now need. Combine that with research consent form templates and your participant-facing paperwork is coherent with your product-facing paperwork.

Traditional survey platforms like SurveyMonkey or Qualtrics will collect the ratings for section 4. They will not chase the "what did you try that didn't work" thread, and they will not code 200 open-ends into a Limitations section for you. That gap is the whole reason Limitations sits at 17.4%.

Common mistakes

Writing the card from the eval suite. The eval suite tells you where the model fails on inputs you thought of. The card needs the failures on inputs you didn't.

Treating disclosure as a legal deliverable. Article 50 sets a floor: clear, distinguishable, at first interaction. It does not tell you which wording preserves trust. That is a research question with a measurable answer.

Skipping "what humans do." It is the cheapest section to write and, per the PNAS Nexus mechanism, the one doing the most work for your credibility.

Publishing once. A model card describing version 3 while you ship version 7 is worse than none, because it is a documented, dated claim that is now false. Tie it to your release process and re-run the underlying study on a fixed cadence — see research refresh cadence.

Aggregate-only metrics. The entire point of the 2019 paper was disaggregation. A single accuracy number in the Quantitative Analyses section means the section is unfilled in substance even if it is filled in form.

Frequently asked questions

What is the difference between a model card and a system card? A model card documents one trained model — its training data, metrics, and known limits. A system card documents the assembled product: the model plus retrieval, prompts, guardrails, fallbacks, and human review steps. Most teams ship systems, not models, so a system card is usually the more honest artifact. The section structure is nearly identical; the difference is scope.

Does Article 50 of the EU AI Act apply to my product? It applies from 2 August 2026 to providers of AI systems that interact directly with natural persons (you must tell them it is AI, unless obvious), to providers of systems generating synthetic audio, image, video or text (outputs must be machine-readably marked), and to deployers publishing deepfakes or AI-generated text on matters of public interest. It attaches to ordinary consumer products, not only high-risk ones. This is a summary, not legal advice — confirm scope with counsel.

Do I have to disclose AI to research participants? If the research instrument itself is AI — an AI-moderated interview, an AI chat probe — then yes, under Article 50(1) for participants in scope, and under ordinary research-ethics norms everywhere else. Informed consent has always required participants to understand what they are taking part in. Koji discloses the AI interviewer at the start of every session.

Will disclosing AI hurt how users perceive our product? On the evidence, somewhat — Altay and Gilardi (PNAS Nexus, 2024, N=4,976) found an AI label lowered perceived accuracy and sharing intent regardless of actual truth or authorship. Two mitigations: the penalty was about a third the size of a "false" label, and it was driven by an assumption of no human oversight. Disclosure that names the human review step addresses the actual inference. Test your wording.

How long should a model card be? Short. The average card on Hugging Face is 191 words and mostly useless; the top 100 by downloads average 521 words. Two pages is plenty. Completeness across sections matters far more than length — Limitations sits at 17.4% completion across the corpus, and that gap is what makes cards untrustworthy, not brevity.

Which sections require user research rather than engineering data? Intended Use, out-of-scope uses, Factors, Limitations, and Ethical Considerations. All five are claims about people and contexts, and none of them can be derived from training logs or offline evals. This is why they are the least-completed sections in practice.

How often should we update the model card? Every time the system changes materially — a model swap, a prompt-architecture change, a new guardrail, a new user segment. A stale card is an actively false published claim. Pair it with a scheduled re-run of the underlying user study rather than treating it as a one-off document.

Related Resources

• Structured Questions in AI Interviews — the six question types that let one study produce both the disaggregation and the explanation
• The EU AI Act and User Research — full compliance mapping for AI-moderated research
• AI Governance for Customer Research — ISO 42001, the NIST AI RMF, and what procurement asks
• AI Failure Mode Analysis — the FMEA framework that populates your Limitations section
• AI Over-Reliance and Automation Bias — finding the failures users never report
• AI Red Teaming with Real Users — adversarial coverage before the card goes public
• Research Ethics and Informed Consent — the participant-facing side of disclosure
• User Research for AI Products — the wider practice this document sits inside

Ready to fill in the sections your eval suite can't? Start free with 10 credits and run your first AI-moderated study today.