La mayoría de evaluaciones de proveedores de IA terminan en una llamada con el equipo de sales del proveedor donde te explican su portal de trust. Y luego el DPO te pregunta cosas concretas que sales no sabe responder y el proyecto se atasca.
Esta checklist son las 15 preguntas que tu equipo de compras o tu DPO debería mandar por escrito al proveedor antes de firmar. Con respuestas-ejemplo buenas, respuestas-ejemplo malas y qué conclusión sacar.
Descargable en PDF al final si necesitas pasárselo a tu equipo.
Bloque 1: transferencia internacional (5 preguntas)
Pregunta 1. ¿Dónde se procesan físicamente los prompts?
Qué buscar: región concreta (ej: "eu-west-1 Dublín") y jurisdicción aplicable.
Respuesta buena: "Procesamos en Frankfurt y París bajo jurisdicción UE. El sub-procesador de infraestructura es X con contrato UE."
Respuesta mala: "Nuestros servidores están en la nube y cumplen los estándares más altos."
Conclusión: si no saben concretar región, probablemente no saben dónde están los datos.
Pregunta 2. ¿Hay transferencia internacional de datos? ¿A qué países?
Qué buscar: respuesta categórica. "No" o "Sí, a EEUU bajo DPF + SCC".
Respuesta buena (caso EEUU): "Sí, a EEUU. Bajo Data Privacy Framework desde julio 2023, con SCCs como salvaguarda adicional. TIA disponible bajo NDA."
Respuesta mala: "Cumplimos todas las normativas aplicables."
Conclusión: una respuesta evasiva aquí es red flag. La transferencia a EEUU no es delito, ocultarla sí es problema.
Pregunta 3. ¿Tenéis Transfer Impact Assessment (TIA) para transferencias UE→país tercero?
Qué buscar: documento real, fecha de actualización.
Respuesta buena: "Sí, TIA de 2025-Q4 revisado tras consulta legal externa. Cubrimos FISA 702, Executive Order 12333, CLOUD Act. Disponible bajo NDA."
Respuesta mala: "No es necesario porque tenemos DPF."
Conclusión: DPF no exime de TIA en sectores regulados. Si dicen que no es necesario, no entienden el estado post-Schrems II.
Pregunta 4. ¿Cuál es vuestra posición si cae el Data Privacy Framework (Schrems III)?
Qué buscar: plan concreto de mitigación.
Respuesta buena: "Tenemos región UE alternativa ya operativa. En caso de invalidez DPF, activaríamos migración a esa región en X semanas. Contrato incluye cláusula de continuidad."
Respuesta mala: "Confiamos en que el marco se mantenga."
Conclusión: la respuesta "fe en el marco" implica que no tienen plan B. Para un proyecto a 3 años, es debilitante.
Pregunta 5. ¿Quiénes son los sub-procesadores y dónde están?
Qué buscar: lista actualizada, enlazada desde la web, con mecanismo de notificación de cambios.
Respuesta buena: "Lista en [dominio]/sub-procesadores. 7 sub-procesadores activos. 4 en UE, 2 en EEUU bajo DPF, 1 en UK bajo adequacy UK. Notificación de cambios 30 días antes."
Respuesta mala: "Los sub-procesadores son confidenciales por motivos de seguridad."
Conclusión: si no publican la lista, mal punto. RGPD Art. 28 obliga a que conozcas sub-procesadores y puedas objetar.
Bloque 2: datos y retention (4 preguntas)
Pregunta 6. ¿Cuánto tiempo retenéis prompts y respuestas?
Qué buscar: plazo concreto, en días u horas. Si dicen "zero", profundiza (ver P7).
Respuesta buena: "30 días estándar para abuse monitoring. 0 días con ZDR activado para clientes aprobados. Logs de metadata (no contenido) retenidos 90 días."
Respuesta mala: "El tiempo mínimo necesario para prestar el servicio."
Conclusión: plazos vagos son plazos infinitos en práctica. Exige cifras.
Pregunta 7. ¿Tenéis Zero Data Retention disponible? ¿En qué endpoints?
Qué buscar: endpoints concretos cubiertos, proceso para activarlo, excepciones.
Respuesta buena: "ZDR disponible en [endpoints concretos]. Proceso de activación: solicitud a sales → evaluación caso uso → anexo contractual → activación por región. Excepciones: detección CSAM, requerimientos legales bajo orden judicial."
Respuesta mala: "Sí" (sin detalle).
Conclusión: la respuesta corta esconde que o no existe o tiene tantas excepciones que no cuenta.
Para profundidad sobre ZDR: Zero Data Retention en IA.
Pregunta 8. ¿Usáis mis datos para entrenar vuestros modelos?
Qué buscar: "No" categórico para planes empresariales.
Respuesta buena: "No. Planes Team y Enterprise tienen cláusula contractual de no-entrenamiento. Planes consumer free/individual sí pueden usar datos de chat para mejora de producto — por eso no los recomendamos para uso empresarial."
Respuesta mala: "Podríamos, pero no lo hacemos."
Conclusión: "podríamos" es reservarse el derecho. Exige "no, contractualmente imposible en este plan".
Pregunta 9. ¿Cómo respondéis a un data subject request (Art. 15-22) cuando trabajáis con ZDR?
Qué buscar: procedimiento real, tiempos.
Respuesta buena: "Si aplicáis ZDR, el dato no se retiene y no hay nada que devolver o borrar. Confirmamos por escrito la ausencia de dato. Para DSR que involucre datos que sí retenemos (logs de metadata 90 días), respuesta en 30 días según Art. 12."
Respuesta mala: "Depende del caso."
Conclusión: el ejercicio de derechos tiene plazos fijos. Respuesta ambigua es señal de procedimiento inmaduro.
Bloque 3: contractual y gobernanza (3 preguntas)
Pregunta 10. ¿Tenéis DPA específico RGPD o usáis uno generalista?
Qué buscar: DPA adaptado a UE, no una versión traducida de un DPA americano.
Respuesta buena: "DPA conforme Art. 28 RGPD, cláusulas SCC anexadas, jurisdicción aplicable UE, idioma español disponible."
Respuesta mala: "Nuestro Master Services Agreement cubre el tratamiento de datos."
Conclusión: si el DPA no es específico, no es DPA. MSA ≠ DPA.
Pregunta 11. ¿Cuál es el régimen de notificación de brecha de seguridad?
Qué buscar: plazo ≤ 72 horas, canal concreto, información mínima que envían.
Respuesta buena: "Notificación en 48h máximo desde detección. Canal email a DPO de cliente + notificación en trust portal. Información incluye: naturaleza, datos afectados, categorías, impacto estimado, medidas aplicadas."
Respuesta mala: "Informamos con la mayor diligencia."
Conclusión: RGPD Art. 33 exige 72h para controlador. El encargado (proveedor IA) debe notificar antes de eso para que tú llegues a plazo. Si no lo garantizan por escrito, tu exposición es total.
Pregunta 12. ¿Qué certificaciones / informes de auditoría externa tenéis?
Qué buscar: certificaciones reales con número de certificado y auditor.
Respuesta buena: "SOC 2 Type 2 (Deloitte, último audit 2025-Q4), ISO 27001 (número certificado XXX, AENOR), HIPAA BAA disponible. Para España, ENS medio en evaluación."
Respuesta mala: "Cumplimos con los más altos estándares de seguridad del sector."
Conclusión: frase sin número de certificado es frase sin certificado.
Bloque 4: técnico y operacional (3 preguntas)
Pregunta 13. ¿Qué logs generáis? ¿Qué contienen? ¿Quién accede?
Qué buscar: separación entre logs operacionales (infra) y logs de contenido.
Respuesta buena: "Logs operacionales (timestamp, request ID, tamaño, latencia, código respuesta): retenidos 90 días, accesibles solo a equipo SRE bajo audit trail. Logs de contenido (prompt/response): 0 con ZDR, 30 días sin ZDR, accesibles a abuse review team bajo procedimiento documentado."
Respuesta mala: "Registramos lo necesario para operar el servicio."
Conclusión: si no separan logs operacionales de contenido, asume lo peor.
Pregunta 14. ¿Cómo cifráis datos en tránsito y en reposo?
Qué buscar: estándares concretos.
Respuesta buena: "Tránsito: TLS 1.3 obligatorio, HSTS. Reposo: AES-256, keys rotadas con KMS bajo control del cliente (BYOK opcional en plan Enterprise). Backups cifrados con claves separadas."
Respuesta mala: "Cifrado estándar de la industria."
Conclusión: sin cifras ni protocolos, no hay seguridad demostrable.
Pregunta 15. ¿Tenéis proceso de exit / portabilidad de datos?
Qué buscar: qué se exporta, en qué formato, en cuánto tiempo.
Respuesta buena: "Exit process documentado: exportación de todos tus datos en formato JSON (chats) y CSV (metadata) en 15 días máximo desde terminación. Borrado verificable en 30 días post-exportación con informe firmado. Fine-tuned models tuyos disponibles para descarga 90 días."
Respuesta mala: "Puedes pedirnos tus datos cuando quieras."
Conclusión: lock-in silencioso. Si el exit no está documentado, asume que va a costar.
Tabla de puntuación rápida
Para cada pregunta, puntúa:
2: respuesta buena, documentada.
1: respuesta parcial, con vaguedad.
0: respuesta mala o evasiva.
Interpretación (30 posibles):
|
Puntos |
Veredicto |
|---|---|
|
26-30 |
Proveedor maduro, firmable con poca fricción. |
|
20-25 |
Proveedor serio con lagunas concretas. Negociar cláusulas específicas antes de firmar. |
|
14-19 |
Riesgo significativo. Mejor buscar alternativa o plantear TIA exhaustivo. |
|
<14 |
No apto para uso empresarial regulado. |
Red flags automáticos (descarte inmediato)
Si el proveedor responde cualquiera de estas, descarte sin pasar a negociación:
❌ "No necesitamos DPA porque no procesamos datos personales." (falso — prompt con nombre es dato personal)
❌ "Schrems II no aplica a nuestro servicio." (aplica a todo proveedor americano)
❌ "No publicamos lista de sub-procesadores." (violación Art. 28)
❌ "El DPA es parte de nuestro contrato general y no es negociable." (DPA debe ser separable y auditable)
❌ "Los logs son confidenciales, no os podemos decir qué contienen." (si no saben qué registran, no puedes cumplir)
Bonus: preguntas específicas para sectores
Sanidad (datos Art. 9)
¿Tenéis HIPAA BAA disponible?
¿Qué controles específicos hay para datos Art. 9?
¿Sub-procesadores pueden acceder al contenido incluso bajo ZDR?
Banca / servicios financieros
¿Cumplimiento DORA? ¿Plan de continuidad de negocio?
¿Registro en la lista de proveedores críticos?
¿Derecho de auditoría in situ?
Sector público
¿Esquema Nacional de Seguridad (ENS) nivel alto?
¿Marco sectorial CCN-CERT?
¿Infraestructura España o solo UE?
Educación
¿Datos de menores: procedimientos específicos?
¿Marcado de contenido generado por IA (AI Act Art. 50)?
¿Logs accesibles a padres/tutores en DSR?
Cómo usar esta checklist operativamente
Mándala por escrito al proveedor antes de la demo. Te ahorra 2 llamadas.
Exige respuestas por email o en formulario trackable, no en una llamada.
Pide que cada respuesta referencie el documento fuente (DPA cláusula X, política de privacidad sección Y).
Puntúa con tu DPO antes de la decisión.
Archiva las respuestas — forman parte de tu TIA si el proveedor es extracomunitario.
FAQ
¿Esta checklist cubre el AI Act además del RGPD?
Cubre RGPD. Para AI Act específico (FRIA, logs de sistemas alto riesgo, transparencia IA), añade preguntas de AI Act en España. Hay solape en preguntas 11, 12, 13 que sirven para ambos.
¿Cómo de largo suele tardar un proveedor serio en responder 15 preguntas?
Con un vendor maduro (OpenAI, Anthropic, Mistral, Google, Microsoft, AWS), 3-5 días hábiles. Startups IA pueden tardar 2-3 semanas porque necesitan preparar respuestas. Si tardan más de un mes, probablemente no tienen la documentación.
¿Puedo negociar cláusulas del DPA del proveedor?
Enterprise/empresas grandes: sí, muchas veces. Plan estándar: rara vez. Para compras >€50K/año, negociar DPA con anexo específico es normal.
¿Qué hago si el proveedor da respuesta mala a una pregunta pero a nivel técnico el producto es el mejor?
Documenta el riesgo residual, pásalo a dirección para decisión informada. Si aceptas, anótalo como riesgo en tu registro de tratamiento con mitigaciones operativas (ej: no meter datos Art. 9 en ese sistema).
¿Hay plantillas oficiales AEPD / EDPB para esto?
AEPD tiene guía sobre contratación de encargados del tratamiento y EDPB tiene recomendaciones 01/2020 sobre transferencias tras Schrems II. Esta checklist es una destilación operativa de ambas.
Recapitulando
Evaluar un proveedor de IA no es misticismo — son 15 preguntas con respuestas verificables. Un DPO junto al equipo técnico las puede revisar en un par de reuniones y decidir antes de firmar.
La checklist no sustituye el juicio legal profesional en casos complejos, pero detecta el 80% de red flags sin abogado. Para el marco completo RGPD + IA: IA y RGPD en 2026. Para el complemento AI Act: AI Act en España. Si quieres un proveedor que ya pase esta checklist en verde, Levante Platform.
Basada en: RGPD Art. 28, EDPB Recommendations 01/2020, AEPD guía sobre encargados del tratamiento.
