Model Cards and AI Transparency Documentation Requirements

Model cards started as a voluntary habit, not a legal obligation. The idea came from a 2019 paper, "Model Cards for Model Reporting"; by Mitchell and her co-authors, and for about five years, that's what it stayed: a good practice, not a rule anyone had to follow. A model card was a short write-up a team could choose to publish alongside a model, covering what it was built for and where it might fall short.

That changed once regulators stepped in. The EU AI Act now makes documentation mandatory for high-risk AI systems, and other countries and states are writing similar rules into law. A model card stopped being a courtesy and started being evidence a regulator can ask to see. The rest of this piece walks through what that change actually demands, how far today's practice falls short of it, and what companies, especially ones running AI tools built by someone else, need to do about it.

What the EU AI Act and converging regulations require from documentation

The EU AI Act sorts AI systems into four tiers: prohibited, high-risk, limited-risk, and minimal-risk. Systems used for hiring, credit decisions, law enforcement, or anything safety-critical are in the high-risk bucket, and that's where the paperwork gets heavy.

The legal duty to document a system doesn't stay with whoever built it, a detail that catches a lot of companies off guard, and if a company takes a third-party or open-source model and puts it to work in a high-risk setting, that company now owns the full documentation burden for that use, no matter what the original model builder handed over. Using someone else's model doesn't mean someone else carries the risk.

The reach of the law goes beyond EU borders too. A company outside the EU that simply serves users inside it has to meet the same requirements, and the fines that follow a violation scale up with how serious the breach is.

Then there's the retention requirement, which tends to surprise people just as much. Training data records, performance logs, and incident reports have to be kept for years after a system is pulled from the market, not just while it's actively running. A model that gets retired doesn't let its paperwork retire with it.

Other countries are moving in a similar direction, even if the details differ. California's SB 53, in effect from January 1, 2026, requires large frontier model developers to publish safety frameworks and report serious incidents. At the federal level, a bill called H.R. 8094, introduced March 26, 2026, would push the FTC to set rules forcing AI foundation model makers to disclose their training data and algorithms publicly. Neither one copies the EU AI Act line for line, but the direction is the same: documentation duties are tightening everywhere a model gets deployed.

What model cards are required to contain under compliance frameworks

A model card that satisfies a regulator looks nothing like the short narrative write-ups that used to pass for transparency. Regulators want documentation they can check against evidence, not a page of confident prose about how well a model performs.

Under the EU AI Act framework, that documentation has to cover where the training data came from, who collected it, what biases are already known, and when it was gathered. It has to break performance metrics down by demographic group rather than report one overall accuracy number, because regulators compare high-risk systems against a disparate impact threshold known as the four-fifths rule. It has to spell out limitations and failure modes in plain terms, describe the human review built into the deployment process, and explain how the system gets monitored once it's live, including what happens when drift or bias turns up.

Regulated industries add even more on top of that. Providers of general-purpose AI models carry an additional duty: they have to keep technical documentation of how the model was trained and tested, and pass that documentation down to anyone deploying it, so the deployer actually understands what the system can and can't do.

Think of it the way drug approval works. A pharmaceutical company submits a technical dossier to the regulator, the hospital or pharmacy using the drug keeps its own records of how it performs in practice, and regulators can inspect either side. A drug's dossier has to cover adverse reactions and edge cases in detail, and a compliance-grade model card has to document failure modes with that same level of specificity. That's a high bar. The next section shows how far short of it the industry currently falls.

Gaps in Current Model Card Practice

The sections regulators care about most tend to be the ones companies document least. A study of more than 32,000 Hugging Face model cards found that training details were the most complete section across the board, while environmental impact, evaluation results, and limitations were consistently and badly underreported. The parts a regulator would actually audit are the parts most often left thin.

Code quality tells a similar story. Among model cards that included example code, more than two-thirds of those code snippets didn't even run. That's a strong sign that a lot of model cards are written to be read, not to be used or checked.

The clearest sign of trouble is the trend line. The 2025 Foundation Model Transparency Index, built by researchers from Stanford, UC Berkeley, Princeton, and MIT, found that average transparency scores fell from where they stood in 2024, slipping back toward 2023 levels. Transparency is heading backward right as the legal requirement for it is getting stricter. The weakest spots across frontier model providers were training data, training compute, and what happens to a model after it's deployed, which happen to be exactly the fields the EU AI Act treats as priorities. The decline wasn't limited to one company either; scores dropped across several major labs, including Amazon, Anthropic, Google, Meta, Mistral, and OpenAI. The slide is industry-wide, not a problem at one lab.

Why documentation gaps persist despite published model cards

The gap isn't simply a matter of labs not trying hard enough. Some of the hardest sections to get right resist the very tools companies use to produce documentation at scale.

Take the "intended use" field. Deciding what a model is for is a business call, not something a log file spits out automatically. Limitations are similar: a lot of them come from edge cases a developer noticed through hands-on experience but never built a system to track. Tools built to auto-generate that kind of language, even ones using retrieval-augmented approaches, still carry a real risk of hallucinating details that were never actually tested or observed. Automating a business decision doesn't work, and automating an undocumented failure mode works even less.

Because so much of this still runs on manual judgment, there's plenty of room for error, vague wording, and gaps nobody catches until later. Even with platforms building in better support for documentation, quality and consistent use of model cards remain low across the board.

There's also a mismatch in who the documentation is written for. Model cards have historically aimed at practitioners and regulators, groups that until recently weren't enforcing much of anything, rather than the people actually affected by what the model decides. One might argue this is a solvable tooling problem, something better software will eventually fix. But that argument runs into a wall: the sections automation struggles with most, intended use, limitations, failure modes, are exactly the sections regulators weight most heavily. No pipeline fills in a missing business decision on its own.

The transparency-washing risk in compliance checklists

A model card can check every regulatory box and still tell a reader very little. Researchers at EleutherAI have pointed out that the Foundation Model Transparency Index can be gamed: a company can post a high score by copying disclosure practices other companies already use, without that score reflecting any real change in how much the company actually discloses.

That raises an important question: what is a transparency index actually measuring? The deeper worry here is that indices like this one, and compliance checklists built the same way, quietly accept a deal the industry would prefer: don't make companies show transparency in ways that cost them commercially, just hand them a form they can fill out with enough labor.

The same problem appears inside individual model cards. Naming a risk and actually fixing it are two different acts, and a card that lists a bias without saying a word about how it's being addressed can still check every box on a documentation form while leaving users fully exposed. That's also why generic compliance checklists and standard security frameworks can't catch AI-specific risk on their own: they confirm a field has something written in it, not that what's written is accurate, complete, or something a reader could actually act on.

A model card that a vendor hands over and a company accepts without checking it independently doesn't lower the company's risk but instead documents the company's exposure. It documents the company's exposure. The company has satisfied a paperwork requirement while remaining fully on the hook for whatever that paperwork failed to mention. Closing that gap takes more than a one-time review, it takes an ongoing way to track vendor AI across a company's systems and catch what a static document misses, which is the kind of assessment and continuous monitoring that dedicated AI risk intelligence platforms are built to provide.

What enterprises deploying vendor AI must do and cannot delegate

Buying AI from a vendor doesn't hand off the documentation duty along with it. Under the EU AI Act, a company deploying a high-risk third-party model owns full responsibility for documenting its own use of that model, whatever the original builder provided. That one fact should reshape how risk management, security, privacy, and legal teams approach every vendor AI contract on the table.

Meeting that duty starts with getting hold of the vendor's actual technical documentation rather than settling for the public model card, since the model card is only a summary and the full Annex IV-equivalent dossier is what the law actually requires. From there, a company has to check whether that documentation covers its own specific use case, not just the generic use the vendor had in mind when building the model, and fill in anything missing: the human review process in place, how the system gets monitored, its version history, and an incident response plan tailored to how the company is actually using it. All of that documentation needs to be kept not just while the system runs, but for the full retention period the law requires after it's retired.

For general-purpose AI models, the provider is required to hand downstream deployers documentation covering what the model can and can't do. Companies shouldn't wait for a vendor to offer that voluntarily. It belongs in the contract as a condition of the deal, not a hope.

Plenty of companies producing their own model cards now use a hybrid method: pull the factual sections automatically from MLOps tooling, then have experts write and review the interpretive sections by hand. That's become the standard way to build a card from scratch, but it doesn't replace the separate job of checking a vendor's documentation independently. A vendor's polished card isn't a reason to skip verification.

Industry-specific rules stack on top of all of this. Healthcare deployers still have to meet HIPAA's requirements for de-identifying protected health information and whatever the FDA expects of AI and machine learning medical devices. Financial services deployers still have to meet regulatory standards for managing model risk. A vendor's model card almost never covers all of these at once, so a company operating in a regulated industry has real work to do beyond whatever the vendor supplies.

None of this ends once a system goes live. The EU AI Act requires documentation of what happens after deployment, including how the company handles drift or bias once it's detected, so a single documentation check done at onboarding doesn't satisfy the law. Monitoring has to run continuously for as long as the system is in use, and that ongoing, deployment-specific obligation is exactly where generic governance checklists run out of road, and where tools purpose-built for continuous vendor AI assessment pick up the slack.

Model card requirements as enforcement begins and automation matures

Enforcement isn't a future problem. Regulatory audits are already happening in EU member states, and that machinery keeps running even where certain deadlines have shifted. The documentation a company has on file today could already be under scrutiny, whether or not that company has thought about it that way yet.

The format of model cards is changing too, moving toward versions that are machine-readable, dynamic, and verifiable, with things like hardware-attested disclosures and continuous monitoring plans built in as structured data. A static, narrative-style card is going to look increasingly out of step with what counts as compliant documentation.

There's reason to think the market wants better transparency even without a regulator forcing the issue. Adding a detailed model card to a popular model has been linked to higher download numbers, which suggests transparency carries real commercial value that most companies aren't fully capturing yet. That alone could push buyers and procurement teams to demand better documentation even ahead of stricter enforcement.

The labs most likely to supply enterprise vendor AI, the same labs whose FMTI scores have been sliding, are still putting out model cards for their major releases. Meta published model cards for Llama 4, OpenAI published a system card for GPT-5, and Anthropic published one for Claude Sonnet 4.5. But a published card closing the distance to a compliance-grade one is still the deploying company's job, not the vendor's.

Companies that treat model card compliance as a box to check once should expect to redo that work repeatedly as enforcement tightens around it. Companies that build continuous assessment into how they govern vendor AI now are setting themselves up to absorb whatever comes next without having to scramble for it.