Due Diligence for AI Vendors: Practical Checklist for Public Entities

Why due diligence for AI vendors is critical

AI projects in the public sector are not just a technical choice: they carry legal (GDPR, Law 9/2017, Law 38/2003, EU AI Act), security (ENS Royal Decree 311/2022) and operational risks. A rigorous assessment of the vendor before and during contracting reduces surprises: data leaks, regulatory breaches, fragile models or lack of continuity. Here is a practical, actionable guide to auditing AI vendors in public procurement processes.

Three pillars of due diligence

Split your evaluation into three clear domains:

• Legal and compliance
• Technical and model performance
• Security and operations

Below is a concrete checklist you can include in an RFI/RFP or use in a pre-contract assessment.

1) Legal and compliance — essentials

• Identification of roles under the GDPR:

  • Is the vendor acting as a data processor (Art. 28 GDPR) or as a controller?
  • Request the Data Processor Agreement template including the mandatory Art. 28 clauses.

• Compliance documentation:

  • A complete and up‑to‑date DPIA if the system processes special category personal data or is high‑risk (the EU AI Act requires risk assessments for certain systems).
  • Evidence of compliance with the EU AI Act for systems classified as "high-risk": risk management, technical documentation, transparency records, and human oversight protocols.
  • A statement on contractual alignment with Law 9/2017 (public procurement) or Law 38/2003 (subsidies), as applicable.

• Subcontracting and transfers:

  • List of subcontractors and the physical location of data; terms for any sub‑processors.
  • Policy on international data transfers (if applicable).

• Intellectual property and portability:

  • Rights over models and outputs; exit conditions and portability of data/models in reusable formats.
  • Continuity clauses (data export upon contract termination).

2) Technical — tangible evidence of how it works

• Model cards and data sheets:

  • Request a model card detailing architecture, training datasets (or their characterization), known limitations and public evaluation metrics.
  • A data sheet explaining potential biases and coverage across demographic or geographic subgroups.

• Evaluation and metrics:

  • Results from tests on evaluation datasets that are representative and tied to local realities.
  • Metrics for accuracy, false positives/negatives, and performance broken down by subgroup.

• Model robustness and security:

  • Tests for resistance to adversarial inputs, stress testing and red teaming findings.
  • Monitoring policies: drift detection (model drift), retraining thresholds, and rollback procedures.

• Explainability and operational limits:

  • Level of explainability available (local/global) and examples of explanations provided to an end user or human supervisor.
  • Documentation of technical limitations and scenarios where the model should not be used.

• Versioning and reproducibility:

  • Model and data version control, experiment logs, and MLOps practices that enable result reproducibility.

3) Security and operations — ensure continuity and protection

• ENS compliance (Royal Decree 311/2022):

  • Evidence of technical and organizational controls aligned with the ENS: asset classification, access controls, encryption in transit/at rest, continuity plans.
  • Recent audit reports or penetration test results.

• Incident management:

  • Incident notification SLAs and response times aligned with the GDPR (notification to the authority and affected data subjects).
  • An operational playbook for AI incidents (e.g., erroneous decisions in production).

• Access control and environment segregation:

  • Separate dev/test/sandbox environments from production; privileged access policies.
  • Logging and traceability of actions on models and data.

• Backup, recovery and continuity:

  • Backup procedures, RTO/RPO and periodic recovery tests.

Recommended practical process

1. Initial RFI: request basic evidence (DPIA, model card, list of sub‑processors, certifications).
2. Technical‑legal RFP: include mandatory requirements (critical items from the checklist) and weighted evaluation criteria.
3. Controlled PoC in a municipal sandbox: tests with synthetic or anonymized data, acceptance based on defined KPIs.
4. Contractual approval: include compliance clauses (GDPR, ENS, AI Act), SLAs, right to audit and an exit plan.
5. Post‑deployment monitoring: quarterly reviews, bias/drift reports and annual audits.

Minimum documents to request from the vendor

• DPIA and data protection policy.
• Model card and data sheets.
• Security testing report (pentest / red teaming).
• List of subcontractors and data locations.
• SLA and continuity policies.
• Change log and monitoring plan.

Takeaway / call to action

Immediate action: prepare a due diligence template that combines the lists above and use it in your next procurement or agreement. Treat technical testing and legal compliance as knockout requirements in your procurement documents. OptimGov Ready can help turn this checklist into an operational workflow within your organization, but the first step is always to institutionalize verification: no evidence, no contract.

If you remember only one thing: always request the DPIA and the model card before awarding — if they are missing, do not proceed until you obtain and validate them.