Criterios prácticos para contratar modelos LLM en la administración pública

Por qué un checklist específico para LLMs en la administración

Los grandes modelos de lenguaje (LLMs) plantean oportunidades reales para mejorar servicios públicos, pero también riesgos específicos: fuga de información, dependencias de proveedor, problemas de propiedad intelectual y responsabilidades bajo el RGPD y el AI Act. La Ley 9/2017 (contratos del sector público) y el ENS (RD 311/2022) fijan obligaciones que deben reflejarse en pliegos y contratos. A continuación encontrará un checklist accionable para diseñar criterios técnicos, jurídicos y operativos al contratar LLMs.

1. Cumplimiento legal y responsabilidades contractuales

Clasificación del sistema bajo el EU AI Act: determine si el uso del LLM entra en categorías de alto riesgo. Si es aplicable, exija al proveedor pruebas de conformidad y documentación técnica.
RGPD: exigir cooperación en la Evaluación de Impacto de Protección de Datos (DPIA), definir roles (responsable/encargado) y prohibir el reentrenamiento del modelo con datos personales sin autorización explícita.
ENS (RD 311/2022): incluya requisitos mínimos de seguridad (control de acceso, cifrado en tránsito y reposo, registros de auditoría) y la obligación de someterse a controles de seguridad.
Ley 9/2017: asegure que los criterios técnicos y de adjudicación sean evaluables objetivamente; documente la memoria técnica que justifique la solvencia técnica del modelo.

Cláusulas contractuales recomendadas

Derecho de auditoría técnica y legal periódica.
Prohibición explícita de retención y uso secundario de entradas (prompt data) para reentrenamiento sin consentimiento.
Compromisos de notificación de incidentes y tiempos de respuesta.
Condiciones de portabilidad y entrega de artefactos (model-card, weights, SBOM de componentes).

2. Transparencia y documentación técnica

Model card y data sheet: exija documentación sobre arquitectura, capacidades, límites, métricas de evaluación y conjunto de entrenamiento (en la medida que sea posible sin vulnerar acuerdos comerciales).
Registro de versiones: cada versión debe acompañarse de changelog, pruebas de regresión y métricas de desempeño.
Resultados de pruebas de seguridad: informes de red-teaming, pruebas de prompt injection y adversarial testing.

3. Seguridad técnica y protección de datos

Entorno de despliegue: prefiera opciones de despliegue que permitan control sobre datos (VPC, on-prem o nube certificada con contratos que garanticen no transferencia de datos fuera del ámbito acordado).
Cifrado y accesos: cifrado en tránsito/reposo, autenticación fuerte (SSO, MFA), control de privilegios por rol.
Logging y trazabilidad: registros inmutables de consultas y respuestas para auditoría y resolución de reclamaciones, con políticas claras de retención conforme al RGPD.
Tests de fuga de datos: solicitar pruebas de que el modelo no reproduce texto sensible/propietario (seeding tests).

4. Operaciones, SLAs y continuidad

SLA claros: disponibilidad, latencia máxima aceptable, objetivos de rendimiento y penalizaciones por no cumplimiento.
Gestión de incidentes: procedimiento de notificación (plazos y responsables), plan de contingencia y backups de configuración.
Política de actualizaciones: calendario y notificación de upgrades; pruebas de regresión garantizadas antes de activar nuevas versiones en producción.
Plan de salida: exportación de datos y, si aplica, del modelo o de los artefactos necesarios para continuidad operativa.

5. Privacidad, minimización y DPIA

Minimización de datos: diseñe prompts y flujos para evitar enviar datos personales identificables a la API del proveedor.
Anonimización y enmascaramiento: requisitos técnicos para anonimizar datos sensibles antes de uso.
Retención y eliminación: tiempos máximos de conservación de logs y disposiciones para la eliminación segura y verificable.

6. Evaluación técnica y pruebas de aceptación

Entorno de pruebas replicable: disponer de sandbox con datos sintéticos o enmascarados para pruebas reales.
Pruebas de aceptación (UAT): precisión en casos de uso reales, controles de seguridad, pruebas adversariales y métricas de usabilidad.
Indicadores de supervisión: tasa de error, tasa de hallucinations, tiempo medio de respuesta, cumplimiento de SLAs y ratio de escalado a operador humano.

7. Gobernanza interna y formación

Definir responsables: unidad técnica, jurídica y de protección de datos con roles y flujos de aprobación.
Monitoreo continuo: dashboards de uso y alertas para comportamientos anómalos.
Capacitación: formación específica para operadores y para personal que revise salidas del LLM.

Implementación práctica: pasos inmediatos (acción)

En 30 días: redacte un anexo técnico mínimo para pliegos que incluya requisitos de ENS, RGPD y AI Act, cláusulas de auditoría y política de no-reentrenamiento.
En 60 días: monte un sandbox con datos sintéticos y ejecute pruebas de seguridad y usabilidad con 3 proveedores finalistas.
En 90 días: firme un piloto con SLA acotado y criterios de aceptación documentados (inclusión de derecho de rescisión si el desempeño o cumplimiento no cumplen los requisitos).

Takeaway: No basta con evaluar rendimiento: su pliego debe integrar requisitos legales (RGPD, ENS y AI Act), controles técnicos (logging, cifrado, pruebas adversariales) y cláusulas contractuales (auditoría, no-reentrenamiento, portabilidad). Diseñe la contratación en tres fases (anexo técnico, sandbox y piloto con SLA) para reducir riesgos y asegurar cumplimiento. Para entidades que disponen de herramientas de diagnóstico de gobernanza, como OptimGov Ready, incorpore sus resultados al anexo técnico desde la fase de redacción del pliego.