Debida diligencia a proveedores de IA: checklist práctico para entidades públicas

Por qué la debida diligencia a proveedores de IA es crítica

Los proyectos de IA en la administración pública no son solo una decisión tecnológica: implican riesgos legales (RGPD, Ley 9/2017, Ley 38/2003, EU AI Act), de seguridad (ENS RD 311/2022) y operativos. La evaluación riguroso del proveedor antes y durante la contratación reduce sorpresas: fugas de datos, incumplimientos regulatorios, modelos poco robustos o falta de continuidad. Aquí tienes una guía práctica y accionable para auditar proveedores de IA en procesos públicos.

Tres pilares de la debida diligencia

Divide tu evaluación en tres dominios claros:

• Legal y cumplimiento
• Técnica y de desempeño del modelo
• Seguridad y operativa

A continuación, un checklist concreto que puedes incorporar en un RFI/RFP o en una evaluación previa al acuerdo.

1) Legal y cumplimiento — lo imprescindible

• Identificación de roles respecto al RGPD:

  • ¿El proveedor actúa como encargado del tratamiento (Art. 28 RGPD) o como responsable?
  • Solicita el modelo de Contrato de Encargado con cláusulas obligatorias de Art. 28.

• Documentación de cumplimiento:

  • DPIA completo y actualizado si el sistema procesa datos personales sensibles o es de alto riesgo (EU AI Act obliga evaluaciones de riesgo para determinados sistemas).
  • Evidencia de cumplimiento con el EU AI Act para sistemas clasificados como "alto riesgo": gestión de riesgos, registros técnicos, documentación de transparencia, protocolos de supervisión humana.
  • Declaración sobre encaje contractual con Ley 9/2017 (contratación pública) o Ley 38/2003 (subvenciones), según aplique.

• Subcontratación y transferencias:

  • Lista de subcontratistas y ubicación física de los datos; condiciones para subencargados.
  • Política de transferencias internacionales de datos (si aplica).

• Propiedad intelectual y portabilidad:

  • Derechos sobre modelos y resultados; condiciones de salida y portabilidad de datos/modelos en formato reutilizable.
  • Cláusulas de continuidad (exportación de datos al terminar el contrato).

2) Técnica — evidencia tangible del funcionamiento

• Model cards y data sheets:

  • Solicita una model card que detalle arquitectura, datasets de entrenamiento (o su caracterización), límites conocidos y métricas públicas de evaluación.
  • Data sheet que explique sesgos potenciales y cobertura por subgrupos demográficos o territoriales.

• Evaluación y métricas:

  • Resultados de pruebas en datasets de evaluación representativos y unidos a la realidad local.
  • Métricas de precisión, falsos positivos/negativos, y rendimiento por subgrupo.

• Robustez y seguridad del modelo:

  • Pruebas de resistencia a entradas adversariales, estrés y hallazgos de red teaming.
  • Políticas de monitorización: detección de deriva (model drift), umbrales de retraining, procedimientos de rollback.

• Explicabilidad y límites operativos:

  • Nivel de explicabilidad disponible (local/global) y ejemplos de explicaciones entregadas a un usuario/humano supervisor.
  • Documentación de limitaciones técnicas y escenarios en los que no usar el modelo.

• Versionado y reproducibilidad:

  • Control de versiones de modelos y datos, registros de experimentos, y prácticas MLOps que permitan reproducir resultados.

3) Seguridad y operaciones — garantizar continuidad y protección

• Cumplimiento ENS (RD 311/2022):

  • Evidencia de controles técnicos organizativos alineados con ENS: clasificación de activos, control de accesos, cifrado en tránsito/ reposo, planes de continuidad.
  • Informes de auditoría o pruebas de penetración recientes.

• Gestión de incidentes:

  • SLAs de notificación de incidentes y tiempos de respuesta acordes al RGPD (notificación a la autoridad y afectados).
  • Playbook operativo para incidentes de IA (p. ej. decisiones erróneas en producción).

• Control de acceso y segregación de entornos:

  • Entornos dev/test/sandbox separados de producción; políticas de acceso privilegiado.
  • Registro y trazabilidad de acciones sobre modelos y datos.

• Backup, recuperación y continuidad:

  • Procedimientos de backup, RTO/RPO y pruebas periódicas de recuperación.

Proceso práctico recomendado

1. RFI inicial: solicita evidencias básicas (DPIA, model card, lista de subencargados, certificaciones).
2. RFP técnico-jurídico: incluye requisitos obligatorios (puntos críticos del checklist) y criterios de valoración ponderados.
3. PoC controlado en sandbox municipal: pruebas con datos sintéticos o anonimización, aceptación por KPIs definidos.
4. Aprobación contractual: incluir cláusulas de cumplimiento (RGPD, ENS, AI Act), SLAs, derecho a auditoría y plan de salida.
5. Monitorización post-implantación: revisiones trimestrales, reportes de sesgo/deriva y auditorías anuales.

Documentos mínimos a pedir al proveedor

• DPIA y política de protección de datos.
• Model card y data sheets.
• Informe de pruebas de seguridad (pentest / red teaming).
• Lista de subcontratistas y localización de datos.
• SLA y políticas de continuidad.
• Registro de cambios y plan de monitorización.

Toma de acción (takeaway)

Acción inmediata: prepara una plantilla de due diligence que combine las listas anteriores y úsala en el próximo proceso de contratación o convenio. Pondera las pruebas técnicas y el cumplimiento legal como requisitos eliminatorios en tus pliegos. OptimGov Ready puede ayudarte a convertir este checklist en un flujo operativo dentro de tu entidad, pero el primer paso es siempre institucionalizar la verificación: sin evidencia, no se contrata.

Si solo retienes una idea: solicita siempre la DPIA y la model card antes de adjudicar —si faltan, no avances hasta obtenerlas y validarlas.