Model Cards › Limitations and Practical Challenges

Model cards are not a solution to the problems they document; they are a structured way to communicate those problems so that deployers can address them. Several practical challenges limit how effective model cards are in practice.

The first challenge is the documentation burden. A thorough model card requires disaggregated evaluation data, which in turn requires demographic annotations on evaluation sets. These annotations are expensive, raise privacy considerations, and may not be available for all relevant subgroups. Large language models are especially difficult to document fully because their capabilities span so many tasks that no fixed evaluation suite can characterize them. The evaluation budget required to produce a complete model card for a frontier language model would dwarf the budget typically allocated for documentation.

The second challenge is the incentive structure. Model cards are most useful when they document failures, but developers face commercial incentives to present models favorably. Incomplete documentation is not always dishonest; some limitations are not discovered until deployment. But the asymmetry between the costs of negative documentation (reduced perceived quality) and the benefits (reduced downstream harm) creates structural pressure toward incomplete cards. This pressure is particularly acute in competitive markets where benchmark performance is a primary sales metric and documented limitations are treated as weaknesses rather than evidence of rigor.

The third challenge is the reader problem. Model cards are often written by ML engineers and read by procurement officers, policymakers, or product managers who may lack the technical background to interpret performance metrics correctly. A model card that accurately states "95% accuracy on held-out test set" requires the reader to understand what held-out evaluation means, what the test set composition was, and why held-out accuracy may not predict deployment performance. Without that background, the number is easily misinterpreted. Bridging this communication gap without either oversimplifying (losing accuracy) or over-explaining (losing accessibility) is a writing challenge that most model card authors have not been trained for.

The fourth challenge is that model cards describe static snapshots of dynamic systems. A model deployed in a new context accumulates real-world usage that reveals limitations not visible in pre-deployment evaluation. A card written at release does not update itself as these limitations emerge. Maintaining model cards as living documents requires organizational processes and tooling that most teams have not built. The gap between initial release documentation and actual deployed system behavior tends to grow over time as the model is adapted, fine-tuned, and applied to increasingly diverse contexts.

A fifth challenge is the verification gap. Model cards are self-reported documents. There is no standard mechanism for verifying that the evaluation results reported in a model card are accurate, that the training data description is complete, or that the documented limitations are the complete set of known problems. External audits can partially address this verification problem, but auditing is expensive and typically occurs only for high-profile or high-stakes deployments. For the vast majority of models, model card contents are taken on trust. As regulatory requirements for AI documentation tighten, the demand for verifiable documentation will likely increase, but the infrastructure to support verification at scale does not yet exist.

Despite these limitations, model cards represent a meaningful advance over the pre-2018 norm of no structured documentation. They create a vocabulary for discussing model capabilities and limitations, establish accountability through documented deployment decisions, and provide a framework that regulatory requirements are increasingly built around. As documentation tooling matures and evaluation infrastructure becomes more automated, the practical barriers to high-quality model cards are likely to decrease. The current state is imperfect, but the direction of travel is toward more complete, more verifiable, and more current documentation as a standard expectation for any model deployed in consequential contexts.