The Question
When a procurement team buys enterprise software, it expects a feature specification document, a security questionnaire response, a data processing agreement, and a set of SLA commitments. These artifacts tell the buyer what the software does, how it handles data, and what the vendor is accountable for. They are standard procurement requirements.
When a procurement team buys or deploys an AI system — a hiring screening tool, a credit decision model, a customer service AI, a medical imaging classifier — they receive a vendor data sheet, a security questionnaire response, and a DPA. What they typically do not receive, and typically do not know to ask for, is a model card and a datasheet for the training datasets used in the system.
A model card is the technical specification for an AI model. A dataset datasheet is the provenance document for the data the model was trained on. Without them, a procurement team is buying an AI system without knowing what it was designed to do, what it performs worse on, what populations it was tested against, what the training data contained, or whether the training data carries legal or ethical encumbrances. That is not a minor documentation gap. That is buying a consequential enterprise system on faith.
A model card is not a vendor marketing document — it is the technical specification that tells you what you are actually buying, and procurement teams that don't require them are buying AI on faith.
Why This Matters Now
In June 2025, a healthcare staffing firm in the United States was named in an EEOC discrimination complaint related to its AI-based candidate screening tool. The complaint alleged that the screening model systematically deprioritized candidates over 50 years of age and candidates whose resumes indicated non-continuous employment history — a pattern disproportionately affecting women who had taken parental leave. The firm had procured the screening tool from a third-party vendor in 2023. Its procurement due diligence had covered data security and contractual liability. It had not requested a model card.
A model card for that tool would have documented the training data demographics, the model's performance metrics across age groups, and the vendor's assessment of known limitations. Whether the vendor had produced a model card — and what it would have revealed — became a central question in the ensuing litigation. The firm had no record of requesting one, and the vendor had not volunteered it.
This pattern — enterprises deploying third-party AI systems without technical documentation, then facing liability for model behavior they did not evaluate — is now sufficiently common that it has shaped the regulatory landscape. The EU AI Act Article 11 requires technical documentation for high-risk AI systems that covers training data characteristics, performance metrics, monitoring capabilities, and known limitations. The EEOC's 2023 guidance on employer responsibility for AI-based hiring tools explicitly places the due diligence burden on the deploying employer, not just the vendor. NYC Local Law 144 requires bias audits for automated employment decision tools used in New York City — audits that are only possible if the underlying model documentation exists.
The regulatory trajectory is uniform: deploying enterprises are responsible for understanding the AI systems they deploy. Model cards and dataset datasheets are the documentation that makes that understanding possible.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Governance CURVE™ Report assessed 28 AI system vendors across industries on documentation practices, specifically evaluating model card availability, completeness, and currency. The findings established a significant documentation gap in the commercial AI vendor market.
Among foundation model API providers — Anthropic, OpenAI, Google DeepMind, Meta (Llama models), and Mistral — model cards are published and publicly available. Completeness and specificity vary: Anthropic's model cards for the Claude series include training data categories, safety evaluation methodology, and known limitation disclosures. OpenAI's GPT-4 model card was published but drew criticism for limited performance disaggregation across demographic groups. Meta's Llama 3 model card was assessed as among the most detailed publicly available model cards, including extensive bias evaluation results. Enterprises deploying these models via API should be reviewing the published model cards as part of procurement and risk assessment — most are not.
Among enterprise AI application vendors — hiring tools, credit decisioning, medical AI, fraud detection — model card availability dropped significantly. Vendors building on top of foundation model APIs frequently do not maintain model cards that cover the combined system behavior, producing a documentation gap between the foundation model card and the deployed application behavior.
Holistic AI and Fairly AI both offer bias auditing services that produce model card-equivalent documentation as a service deliverable for enterprises that have procured AI systems without adequate vendor documentation.
The full vendor rankings are in the 2026 Stackcurve AI Governance CURVE™ Report — free to download.
The Gap Most Buyers Miss
What model cards document — and why each section matters for procurement:
Model cards, introduced in the academic literature by Mitchell et al. (2018) at Google, standardized a disclosure format that covers: model details (architecture, version, training approach), intended use (primary uses, out-of-scope uses), factors (relevant demographic and environmental variables), metrics (performance measures used in evaluation), evaluation data (datasets used for evaluation), training data (description of training data), quantitative analyses (performance disaggregated by relevant factors), ethical considerations, and caveats and recommendations.
For an enterprise procurement team, the most operationally important sections are:
Intended use and out-of-scope uses. A model card's intended use section explicitly states what the model was designed for and what it was not. A credit scoring model trained and evaluated on consumer lending data is not appropriate for commercial lending without re-evaluation. A medical imaging model trained on data from one demographic population may perform poorly on a different population. The out-of-scope use section is where vendors document these limitations — and where deployers can find clear statements that their intended use case was not part of the model's design and evaluation.
Quantitative analyses disaggregated by subgroup. The performance disaggregation section is the most governance-relevant component for bias risk assessment. A model that performs at 92% accuracy overall but 74% accuracy for a specific demographic group presents a disparate impact risk that the overall accuracy figure does not reveal. If a model card does not include disaggregated performance metrics across relevant demographic variables, that is itself a risk signal.
Dataset datasheets — the procurement document no one requests:
Datasheets for Datasets, introduced by Gebru et al. (2018), provide structured documentation for training datasets covering: motivation (why was the dataset created?), composition (what does the dataset contain, what are the demographic distributions?), collection process (how was data collected, what was the consent framework?), preprocessing (what cleaning and transformation was applied?), uses (what uses is the dataset appropriate for?), distribution (how is the dataset distributed, under what license?), and maintenance (who maintains the dataset, how are errors handled?).
Dataset datasheets matter for procurement because training data quality, composition, and legal provenance directly determine model behavior and enterprise legal exposure. A model trained on scraped web data may carry copyright exposure. A model trained on data without proper consent may create GDPR and CCPA liability for the deploying enterprise. A model trained on a dataset with demographic imbalances will exhibit performance disparities that reflect those imbalances.
The contractual requirement enterprises are not including:
For AI systems developed by third-party contractors — custom models built to enterprise specification, fine-tuned models adapted from foundation models — model cards and dataset datasheets should be specified as contractual deliverables, not optional documentation. The contractual language should specify the model card format (Mitchell et al. 2018 as the standard), the required sections, and the obligation to update the card when the model is updated. Most AI development contracts in 2026 still do not include this requirement.
Questions Your Buying Team Should Be Asking
1. Can you provide the model card for the AI system we are evaluating — specifically including performance disaggregated by relevant demographic variables for our intended use case?
This question should be asked at the earliest stage of any AI vendor evaluation. A vendor that cannot produce a model card should be asked why, and the absence of a model card should be treated as a governance risk requiring specific mitigation — either through a third-party bias audit before deployment or through explicit contractual provisions requiring the vendor to produce model documentation.
2. For the training data used in this model, can you provide documentation covering data sources, demographic composition, consent framework, and any known data quality issues or limitations?
Dataset documentation is rarely volunteered and rarely requested. A vendor that can provide it is demonstrating governance maturity. A vendor that cannot should be asked whether training data documentation exists internally, and the response should inform both risk assessment and contractual requirements.
3. For foundation model API providers whose model you are building on top of — OpenAI, Anthropic, Google, Meta — have you reviewed the published model cards for those base models, and does your application-level documentation account for any limitations or risk factors documented in those cards?
An enterprise AI application built on top of a foundation model API inherits the foundation model's behavior, including its documented limitations and biases. A vendor that has not reviewed the foundation model's model card cannot represent that their application mitigates foundation model risks.
4. What is the model update and re-documentation process — specifically, when you update the model, do you update the model card to reflect new evaluation results, and how are customers notified of updates that may affect model behavior?
Model cards for static models are a governance artifact. Model cards for models that are regularly updated via fine-tuning, RLHF, or infrastructure changes are only valuable if they are maintained current. Require commitments on model card update frequency and customer notification for updates that materially change model behavior.
5. If we are deploying this AI system in a jurisdiction covered by the EU AI Act as a high-risk system, does your technical documentation satisfy the Article 11 requirements — and can you demonstrate how the model card and dataset documentation map to those requirements?
EU AI Act Article 11 requirements for high-risk system technical documentation substantially overlap with model card and dataset datasheet content. A vendor selling into EU-regulated contexts should be able to demonstrate this mapping. A vendor that cannot is either operating in a low-risk AI Act context (verify this) or has not yet produced Article 11-compliant documentation.
The Stackcurve Take
Model cards and dataset datasheets are not governance bureaucracy imposed on AI vendors by regulators. They are the minimum technical documentation required to make an informed deployment decision. The enterprise that deploys an AI system without reviewing model documentation has outsourced its governance judgment to the vendor — and accepted vendor liability exposure without vendor liability protection.
The practical action is simple: make model card review a standard step in AI procurement, alongside security questionnaire review and DPA negotiation. For procurement of third-party AI applications, add model card and dataset documentation to the vendor requirements list. For custom AI development contracts, add model card production as a contractual deliverable. For foundation model API deployments, review the published model cards before deployment and document that review as part of the governance record.
The regulatory direction is clear: EU AI Act Article 11, EEOC employer responsibility guidance, and NYC LL 144 collectively place documentation responsibility on deploying enterprises. The enterprises that have already built model card review into their procurement process are ahead of the regulatory curve. The enterprises that haven't are accumulating governance gaps that regulators are beginning to examine.
The 2026 Stackcurve AI Governance CURVE™ Report covers AI vendor documentation standards, model card completeness assessments for major AI platforms, and procurement documentation frameworks. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.