Model cards and data sheets in public AI procurement

Purchasing AI solutions in the public sector requires more than a price and a delivery date: it needs verifiable technical information that allows comparing bids, assessing risks, and meeting legal obligations (ENS, GDPR, EU AI Act). Model cards and data sheets are standardized documents that provide that transparency. This post explains what to request in a tender, how to score it, and what practical verifications to include to reduce risk in public procurement.

What are model cards and data sheets?

• Model card: a document that describes an AI model (version, architecture, purpose, limitations, performance metrics, robustness tests, operational requirements and model governance).
• Data sheet (or dataset sheet): a record documenting the dataset used for training/validation (origin, collection method, scope, quality indicators, presence of sensitive data, transformations and licenses).

Both help evaluators understand how the solution works, its limits, and the operational and legal obligations involved.

Why include them in public tenders

• Regulatory compliance: they make it easier to assess security requirements (ENS — Royal Decree 311/2022), data protection (GDPR) and transparency/risk management obligations under the EU AI Act.
• Technical comparability: they standardize information across bids, avoiding ambiguous answers or marketing language.
• Operational due diligence: they help identify risks like bias, reliance on sensitive data, the need for on-premise environments or integrity requirements.
• Traceability and auditability: they document versions and tests, essential for internal or external audits and to meet maintenance and notification obligations.

Practical fields to require in the tender

Below are the recommended minimum fields that each bid should include as technical annexes. They can be submitted in a structured format (JSON/YAML) in addition to a human-readable document.

Model card (minimums):

• Model identifier and version.
• Intended purpose and uses (and prohibited uses).
• Model type and technological dependencies (framework, libraries, versions).
• Referenced training and validation datasets (with link to the data sheet).
• Performance metrics (metric definitions, test datasets, reproducible results).
• Bias and fairness assessment (methodology and results).
• Robustness and security tests (adversarial tests, stress under distribution shifts).
• Explainability: methods implemented and level of interpretability for end users.
• Update and version control policy (frequency, retraining criteria).
• Deployment requirements (SaaS vs on-premise, containers, API, latency and scalability).
• Proposed ENS classification and technical security measures.
• Technical contact and availability for audit.

Data sheet (minimums):

• Dataset description: variables, size, temporal and geographic coverage.
• Collection method and legal authorizations.
• Quality indicators (completeness, null value rates, sampling bias).
• Presence of personal data and anonymization/pseudonymization measures.
• License and reuse restrictions.
• Applied preprocessing and splits (train/val/test).
• Representativeness assessments and known limitations.

Practical clauses for tenders and evaluation criteria

• Mandatory submission: "The bid must include a model card and data sheet signed by the technical lead; their absence will result in technical exclusion."
• Weight in technical evaluation: allocate between 10%–25% to governance and transparency (model card + reproducible tests + DPIA).
• Verifiable requirements: the tender should require running acceptance tests (municipal test set or sandbox), and provide access to logs/artifacts for review by an expert appointed by the contracting authority.
• DPIA and GDPR: require submission of the Data Protection Impact Assessment if the system processes personal data, in accordance with the GDPR.
• ENS: require a declaration of conformity with the ENS and the security classification proposed by the provider, with an obligation to supply evidence during verification.
• Right to audit: a clause allowing periodic technical audits and the delivery of traceability artifacts (versions, metrics and deployment records).

These clauses are aligned with Law 9/2017 on public sector contracts: technical specifications and award criteria must be objective and verifiable.

Quick checklist for procurement teams

• Include model and dataset artifacts as mandatory documentation.
• Involve legal, data protection and security teams when drafting the tender.
• Define reproducible acceptance tests (evaluation datasets or sandbox).
• Allocate scoring to transparency, bias testing and maintenance plans.
• Require SLAs for updates, vulnerability management and version traceability.
• Decide deployment requirements (on-premise / national cloud) based on data sovereignty and ENS.

Expected outcome

Requiring model cards and data sheets shortens technical evaluation time, improves legal and operational risk management, and facilitates audits and incident response. It also pushes the market to document solutions responsibly, benefiting both the administration and the public.

Takeaway / Immediate action

1. Update your tender templates to require a model card and data sheet as mandatory documentation.
2. Define 2–3 acceptance tests (performance, bias and robustness) that the provider must pass in a controlled environment.
3. Involve security and data protection in the evaluation and reserve specific scoring for transparency and governance.

Note: solutions like OptimGov include templates and workflows to manage these artifacts in procurement and evaluation processes, making it easier to integrate them into tenders and technical panels.