Cuestionario de seguridad para proveedores de IA en la UE: 45 preguntas antes de firmar

Un cuestionario de seguridad para proveedores de IA debe hacer más que recopilar enlaces a políticas. Debe obligar al proveedor a describir el flujo de datos, aportar evidencias, aceptar controles contractuales e identificar quién asume cada responsabilidad de la Ley de IA de la UE. Las 45 preguntas siguientes convierten esos requisitos en una decisión de compra.

Úsalo cuando ya tengas un caso de uso real y una lista corta de proveedores. Es un artefacto de procurement, no una herramienta de clasificación legal. Nuestra guía de costes de la Ley de IA explica la regulación y nuestra guía de residencia de datos en la UE muestra por dónde viajan los datos. Esta página comprueba si un proveedor concreto satisface tus requisitos operativos y contractuales.

Usa aquí la checklist indexable o llévala a procurement

La página HTML es la versión completa y canónica. El spreadsheet añade responsables, estado, enlaces a evidencias, puntuación y notas de decisión.

 Descargar el spreadsheet multilingüe

Cómo puntuar una evaluación empresarial de proveedores de IA

Puntúa conjuntamente la respuesta, la evidencia y el contrato. Una política impecable sin evidencia del producto no es un aprobado. Este modelo es una ayuda de procurement de Wavect, no un estándar regulatorio. Si tu equipo necesita una revisión técnica independiente, nuestro servicio de AI enablement convierte la evidencia en un registro de riesgos y una decisión lista para el contrato.

• 76 a 90: candidato de compra, sujeto a aprobación legal, de seguridad y de negocio.
• 58 a 75: aprobación condicionada a una remediación, responsable y fecha concretos.
• 0 a 57: pausa. El comprador está aceptando demasiado riesgo sin valorar.
• Cualquier hard stop prevalece sobre la puntuación total.

Ocho hard stops antes de firmar

• El contenido del cliente puede usarse para entrenamiento o evaluación sin opt-in explícito y exclusión vinculante.
• El proveedor no puede identificar todos los encargados, subencargados, proveedores de modelo y regiones de hosting del flujo de datos.
• Los prompts u outputs sensibles se conservan indefinidamente, o la eliminación excluye logs, backups, embeddings o fine-tunes sin un límite justificado.
• El servicio carece de aislamiento entre tenants, administración con mínimo privilegio o los controles de identidad que exige tu nivel de riesgo.
• Los cambios materiales de modelo, seguridad, región o subencargado pueden ocurrir sin aviso, reevaluación o rollback.
• La notificación de incidentes no tiene plazo contractual, contenido mínimo ni obligación de preservar evidencias.
• El proveedor no tiene una evaluación representativa del caso de uso o no revela métodos, versiones, límites y resultados.
• Las partes no pueden acordar quién es proveedor, responsable del despliegue u otro actor según la Ley de IA para el uso previsto.

Entrenamiento y retención de datos del cliente: Preguntas 1 a 4

Una promesa de no entrenar es demasiado limitada si el feedback, el control de abuso, la revisión humana o un subencargado todavía pueden reutilizar contenido. Pregunta por cada clase de dato y cada copia, incluido cualquier proceso de fine-tuning.

1. ¿Se usan prompts, archivos, outputs, feedback o telemetría para entrenar, ajustar, destilar o evaluar algún modelo, también por subencargados?

Evidencia que pedir: Matriz de uso por clase de dato, finalidad, modelo y destinatario, más la configuración actual y versión de la política.

Incluir en el contrato: Ningún uso del contenido fuera de prestar y proteger el servicio sin un opt-in separado y explícito del cliente.

2. ¿La mejora del modelo está desactivada por defecto y en qué nivel puede imponerlo el comprador?

Evidencia que pedir: Capturas o documentación API para organización, workspace, proyecto y endpoint, junto con una prueba de administrador.

Incluir en el contrato: La exclusión se aplica a todas las cuentas, APIs, canales de soporte y futuras funciones del acuerdo.

3. ¿Qué plazos predeterminados y configurables se aplican a prompts, outputs, cargas, embeddings, logs, backups y copias de control de abuso?

Evidencia que pedir: Calendario de conservación separado para sistemas activos, logs, cachés, backups, tickets de soporte y colas de revisión de seguridad.

Incluir en el contrato: Los máximos, finalidades y excepciones no configurables figuran en el DPA o formulario de pedido.

4. ¿Puede el proveedor demostrar que la configuración prometida funciona para este tenant?

Evidencia que pedir: Exportación de configuración, prueba de control, resultado de auditoría o certificación firmada para el nivel contratado.

Incluir en el contrato: Una exclusión mal configurada o eludida es un incidente con obligaciones de corrección, aviso y eliminación.

Subencargados: Preguntas 5 a 7

El EDPB indica que los responsables deben tener disponible la identidad de todos los encargados y subencargados y verificar sus garantías. Una lista genérica de categorías no basta para un flujo de datos real.

5. ¿Quiénes son todos los encargados y subencargados, qué hace cada uno, dónde está establecido y qué datos recibe?

Evidencia que pedir: Registro actual con razón social, dirección, servicio, país, categorías de datos y lugar de tratamiento.

Incluir en el contrato: El registro se incorpora por referencia y permanece completo para los servicios incluidos.

6. ¿Con cuánta antelación se avisa de un nuevo subencargado y puede el comprador objetar o resolver?

Evidencia que pedir: Flujo de notificación, historial y ejemplo de aviso de cambio.

Incluir en el contrato: Plazo definido, proceso de objeción razonada y salida sin penalización si no existe alternativa razonable.

7. ¿Se transmiten obligaciones equivalentes de seguridad, confidencialidad, transferencia, asistencia y eliminación por toda la cadena?

Evidencia que pedir: Extractos contractuales relevantes, alcance de assurance independiente y control de subencargados críticos.

Incluir en el contrato: El proveedor responde por los subencargados y aporta las evidencias necesarias para demostrar cumplimiento.

Ubicación del modelo y la infraestructura: Preguntas 8 a 10

Prometer una región de almacenamiento no dice dónde ocurren la inferencia, el logging, el acceso de soporte o la recuperación. Mapea el recorrido completo con los controles de nuestra guía de residencia de datos para IA.

8. ¿En qué países ocurren inferencia, almacenamiento, logging, backup, soporte y failover?

Evidencia que pedir: Diagrama de arquitectura y flujo de datos con servicios, regiones y rutas de replicación entre regiones.

Incluir en el contrato: Las ubicaciones aprobadas se enumeran por actividad de tratamiento, no solo como disponibilidad en la UE.

9. ¿Puede bloquearse la región y en qué casos de soporte, seguridad o recuperación pueden salir los datos?

Evidencia que pedir: Documentación de configuración, comportamiento de routing probado y procedimiento de excepción.

Incluir en el contrato: Ningún cambio de ubicación ni acceso remoto fuera de países aprobados sin mecanismo jurídico y controles acordados.

10. ¿Cuál es la cadena exacta de modelo, gateway, cloud y soporte, y qué mecanismo cubre cada tramo fuera del EEE?

Evidencia que pedir: Cadena de suministro, evaluaciones de impacto cuando proceda, módulos SCC y medidas complementarias.

Incluir en el contrato: El proveedor mantiene la documentación válida y avisa si cambia el mecanismo o destino.

Logging de prompts y outputs: Preguntas 11 a 13

El logging ayuda a la seguridad y auditoría, pero crea otro conjunto sensible. Separa contenido de metadatos operativos y define el acceso.

11. ¿Qué se registra exactamente en las capas de aplicación, gateway, proveedor de modelo e infraestructura?

Evidencia que pedir: Esquema de campos con payloads, metadatos, redacción, hashing e identificadores de correlación.

Incluir en el contrato: Solo se registran campos y finalidades acordados, con redacción de datos sensibles antes de persistir.

12. ¿Puede desactivarse el logging de contenido manteniendo la telemetría operativa y de seguridad necesaria?

Evidencia que pedir: Prueba de control a nivel de tenant y ejemplos de los logs resultantes.

Incluir en el contrato: El modo elegido y cualquier excepción obligatoria de seguridad quedan fijados para el nivel de servicio.

13. ¿Quién puede leer los logs, con qué finalidad, aprobación y plazo?

Evidencia que pedir: Matriz de roles, flujo de acceso privilegiado, revisión de accesos y registro de ejemplo.

Incluir en el contrato: Finalidades, mínimo privilegio, frecuencia de revisión y retención se aplican al personal y subencargados.

Permisos: Preguntas 14 a 17

La IA empresarial hereda los permisos de cada fuente y herramienta a la que llega. Un modelo fuerte tras controles de identidad débiles sigue siendo un sistema débil, sobre todo cuando los permisos RAG abarcan SharePoint, Confluence o Drive.

14. ¿Admite el servicio SSO, MFA, SCIM y controles de acceso por rol requeridos?

Evidencia que pedir: Demostración, catálogo de roles y prueba de altas, cambios, bajas y acceso de emergencia.

Incluir en el contrato: Las funciones de identidad necesarias están incluidas en el nivel comprado y no pueden retirarse durante el contrato.

15. ¿Cómo se impone y prueba el aislamiento entre tenants en almacenamiento, retrieval, cachés, fine-tunes y soporte?

Evidencia que pedir: Diseño de aislamiento, alcance de pentest, resultados y arquitectura de claves de cifrado.

Incluir en el contrato: El acceso entre tenants es un incidente y los controles críticos se someten a pruebas independientes.

16. ¿Se conservan los permisos de origen a través de RAG, conectores, cachés, enlaces generados y exportaciones?

Evidencia que pedir: Prueba negativa que demuestre que contenido revocado o no autorizado no puede recuperarse, citarse o exportarse.

Incluir en el contrato: El retrieval aplica permisos actuales antes de que los resultados lleguen al modelo.

17. ¿Pueden limitarse, rotarse, revocarse y atribuirse a un propietario las API keys, agents y cuentas de servicio?

Evidencia que pedir: Controles de claves, modelo de scope, registro de rotación y atribución de uso.

Incluir en el contrato: No hay credenciales compartidas sin dueño; rotación y revocación siguen la política del comprador.

Logs de auditoría: Preguntas 18 a 20

El comprador necesita trazabilidad suficiente para investigar un resultado, probar un control y cumplir una retención aplicable sin crear vigilancia ilimitada.

18. ¿Qué eventos de autenticación, configuración, acceso a datos, modelo, política y administración aparecen en el audit trail?

Evidencia que pedir: Exportación de ejemplo con logins, cambios de rol, acceso de conectores, cambios de modelo, seguridad y acciones administrativas.

Incluir en el contrato: El catálogo acordado permanece disponible y materialmente completo durante el contrato.

19. ¿Incluyen los eventos hora fiable, actor, tenant, acción, objeto, resultado, valores anterior y posterior y un ID de correlación?

Evidencia que pedir: Ejemplo de campos que reconstruya un prompt o acción desde la petición hasta el resultado.

Incluir en el contrato: Se mantienen sincronización, protección de integridad y controles de acceso privilegiado.

20. ¿Puede el comprador exportar logs a su SIEM y conservarlos durante el plazo requerido?

Evidencia que pedir: Documentación API o streaming, prueba de exportación, rate limits y configuración de retención. Para sistemas de alto riesgo aplicables, probar al menos seis meses.

Incluir en el contrato: Acceso, formato, latencia y retención se ajustan a las obligaciones de incidentes y regulación.

Cambios de modelo: Preguntas 21 a 23

Una actualización silenciosa puede invalidar una evaluación, cambiar el comportamiento o alterar el perfil jurídico y de seguridad. Trátala como un cambio de dependencia de producción.

21. ¿Qué cambios de modelo, system prompt, seguridad, región y subencargado activan un aviso previo?

Evidencia que pedir: Política de cambios, release notes y avisos anteriores ligados a criterios de materialidad.

Incluir en el contrato: Un plazo definido se aplica a cambios que afecten rendimiento, riesgo, flujo de datos o cumplimiento.

22. ¿Puede el comprador fijar una versión, probar un canary, aprobar el rollout y hacer rollback?

Evidencia que pedir: API de versionado, flujo de despliegue y rollback demostrado con logs conservados.

Incluir en el contrato: Los flujos críticos reciben una ventana de validación y ruta de rollback soportadas.

23. ¿Qué ventana de compatibilidad y deprecación se aplica y qué reevaluación acompaña a un cambio material?

Evidencia que pedir: Política de soporte, guía de migración, evaluación delta y limitaciones actualizadas.

Incluir en el contrato: No hay migración material forzosa antes de la ventana de prueba, salvo razón urgente de seguridad documentada.

Respuesta a incidentes: Preguntas 24 a 27

El lenguaje clásico de brechas puede omitir prompt injection, uso inseguro de herramientas, corrupción del modelo y resultados automatizados dañinos. Define los incidentes de IA antes de que ocurran.

24. ¿Qué cuenta como incidente de seguridad o safety de IA?

Evidencia que pedir: Taxonomía que cubra exposición de datos, retrieval entre tenants, prompt injection, abuso de herramientas, output dañino, manipulación de modelo o política, caída y cambio no autorizado.

Incluir en el contrato: La definición cubre confidencialidad, integridad, disponibilidad, seguridad e impacto en derechos, no solo brechas confirmadas.

25. ¿Con qué rapidez avisará el proveedor, por qué canal y con qué información mínima?

Evidencia que pedir: Plan de respuesta, árbol de escalado, aviso de ejemplo y plazos por severidad.

Incluir en el contrato: Plazo inicial, canal, contenido mínimo y frecuencia de actualización son explícitos.

26. ¿Preservará evidencias, apoyará la investigación y entregará informes de causa y acción correctiva?

Evidencia que pedir: Procedimiento forense, cadena de custodia e informe post-incidente redactado.

Incluir en el contrato: Preservación, cooperación, actualizaciones e informe final tienen plazos definidos.

27. ¿Cómo se ensayan los planes y qué incidentes relevantes han ocurrido?

Evidencia que pedir: Último tabletop o simulación, seguimiento de remediación y divulgación de incidentes materialmente similares en un periodo acordado.

Incluir en el contrato: Los ejercicios regulares y regresiones materiales de control son eventos de assurance notificables.

Revisión humana: Preguntas 28 a 30

La etiqueta human in the loop significa poco si el revisor no tiene tiempo, información, autoridad y un control real de parada.

28. ¿Pueden personas autorizadas revisar, anular, detener y apelar un resultado asistido por IA?

Evidencia que pedir: Demostración con output erróneo, escalado y parada segura.

Incluir en el contrato: El servicio no elude aprobaciones obligatorias ni ejecuta acciones irreversibles antes de la revisión requerida.

29. ¿Qué información y formación ayudan a entender límites y evitar el sesgo de automatización?

Evidencia que pedir: Instrucciones de uso, avisos de limitaciones, formación y evidencia de interfaz que no presenta incertidumbre como certeza.

Incluir en el contrato: El proveedor mantiene instrucciones y formación actualizadas tras cambios materiales.

30. ¿Se registran las decisiones de revisión, override y escalado sin recopilar datos personales innecesarios?

Evidencia que pedir: Esquema de decision log, reglas de acceso y revisión de privacidad.

Incluir en el contrato: Los registros apoyan accountability y apelación bajo limitación de finalidad y retención.

Evidencia de evaluación: Preguntas 31 a 34

Los benchmarks genéricos no son evidencia de aceptación. NIST AI RMF pide pruebas documentadas y repetibles en condiciones cercanas al despliegue y evaluación regular en producción. Define tasas aceptables de alucinación y presupuesta el trabajo recurrente descrito en nuestra guía de costes y ROI de evaluación de LLM.

31. ¿Se ha evaluado el sistema exacto en tareas, idiomas, usuarios y condiciones de fallo representativos del caso de uso?

Evidencia que pedir: Diseño del test set, muestreo, versión de modelo y prompt, resultados, análisis de errores y límites.

Incluir en el contrato: La aceptación depende de pruebas acordadas del caso de uso, no de un leaderboard general.

32. ¿Qué métricas y umbrales cubren calidad, alucinación, sesgo, seguridad, robustez, latencia y coste?

Evidencia que pedir: Definiciones, baseline, tratamiento de incertidumbre, umbrales y scorecard actual.

Incluir en el contrato: Umbrales críticos, frecuencia y disparadores de remediación son criterios de aceptación o SLA.

33. ¿Quién evaluó y qué independencia tenía respecto al equipo de delivery?

Evidencia que pedir: Roles, assurance externa proporcionada, métodos reproducibles y acceso a limitaciones materiales.

Incluir en el contrato: El comprador puede revisar métodos y reproducir pruebas críticas sin exponer secretos ajenos.

34. ¿Se probaron prompt injection, exfiltración, uso inseguro de herramientas y abusos específicos, y se repiten las pruebas tras cambios?

Evidencia que pedir: Threat model, alcance de red team, hallazgos, remediación y regresión de la versión actual.

Incluir en el contrato: Las pruebas críticas se repiten tras cambios materiales y los hallazgos de alto riesgo bloquean el rollout.

Eliminación de datos: Preguntas 35 a 37

Eliminar debe cubrir copias derivadas y operativas del sistema de IA, no solo la carga original.

35. ¿Puede eliminar datos de producción, logs, embeddings, fine-tunes, cachés, soporte y backups?

Evidencia que pedir: Mapa de eliminación, plazos por sistema, caducidad de backups y procedimiento probado.

Incluir en el contrato: Alcance, plazo y excepciones estrechas se enumeran por almacén.

36. ¿Puede eliminar una persona, registro, workspace o tenant y propagarlo a subencargados?

Evidencia que pedir: API o flujo operativo, propagación y traza de finalización.

Incluir en el contrato: El proveedor asiste con solicitudes relevantes y confirma la finalización aguas abajo.

37. ¿Qué evidencia de eliminación se aporta y cómo se evita que un restore reintroduzca datos?

Evidencia que pedir: Certificado, registro de excepciones, controles de restore y procedimiento de re-eliminación.

Incluir en el contrato: La certificación nombra alcance, fecha, retenciones legales y control sobre backups restaurados.

Salida y portabilidad: Preguntas 38 a 40

El Data Act establece obligaciones de cambio para servicios de tratamiento cubiertos. Aunque el alcance exacto requiera revisión, procurement debe definir qué sale, en qué formato, con qué rapidez y coste. Registra las respuestas como parte de la due diligence técnica del comprador.

38. ¿Puede el comprador exportar inputs, outputs, configuración, prompts, eval sets, logs, metadatos y otros activos controlados?

Evidencia que pedir: Exportación completa y diccionario de datos en formatos comunes legibles por máquina.

Incluir en el contrato: Las categorías exportables y exclusiones justificadas se enumeran exhaustivamente antes de firmar.

39. ¿Qué APIs, herramientas, límites, plazos, asistencia y tarifas se aplican al cambio?

Evidencia que pedir: Guía de salida, documentación API, prueba de volumen, plazo estimado y tarifas.

Incluir en el contrato: Soporte, continuidad, seguridad, aviso, recuperación y tarifas cumplen la ley y SLA acordados.

40. ¿Puede el comprador hacer una transición segura, validar un sustituto y retrasar la eliminación hasta confirmar la exportación?

Evidencia que pedir: Walkthrough con acceso read-only, ejecución paralela, sustitución de modelo, validación y eliminación final.

Incluir en el contrato: Una ventana definida evita bloqueo o borrado prematuro.

Responsabilidades de la Ley de IA de la UE: Preguntas 41 a 45

La Ley de IA asigna obligaciones por rol y uso, no por quién redactó el MSA. El artículo 25 puede convertir al responsable del despliegue u otro tercero en proveedor de alto riesgo tras rebranding, modificación sustancial o cambio de finalidad.

41. Para el uso previsto, ¿qué parte es proveedor, responsable del despliegue, importador, distribuidor, proveedor GPAI o proveedor downstream?

Evidencia que pedir: Matriz firmada ligada al producto, modelo, finalidad y ruta al mercado europeo.

Incluir en el contrato: Cada deber tiene un accountable owner y obligaciones de cooperación.

42. ¿Qué análisis documentado cubre prácticas prohibidas, alto riesgo, transparencia del artículo 50 y obligaciones GPAI?

Evidencia que pedir: Memo actual con supuestos, exclusiones, fecha de versión y revisión legal proporcionada.

Incluir en el contrato: El proveedor avisa cuando un cambio pueda alterar el análisis.

43. ¿Aportará la información necesaria sobre instrucciones, logging, supervisión, límites, incidentes y cumplimiento downstream?

Evidencia que pedir: Instrucciones, documentación técnica, información del modelo, contactos y ejemplo de compliance pack.

Incluir en el contrato: Información, capacidades, acceso técnico y asistencia son entregables sujetos a actualización.

44. ¿Quién opera el seguimiento, reporte de incidentes graves, transparencia, alfabetización en IA y cualquier evaluación de derechos requerida?

Evidencia que pedir: Mapa de ciclo de vida, procedimientos, responsables formados y contactos de autoridad.

Incluir en el contrato: Los plazos dejan tiempo suficiente para que actúe la parte legalmente responsable.

45. ¿Qué ocurre si marca, modificación o finalidad desplazan la responsabilidad de proveedor al comprador?

Evidencia que pedir: Escenario de change control, evaluación de modificación sustancial y paquete de handover.

Incluir en el contrato: Ningún cambio que desplace responsabilidad sin aprobación, documentación, asistencia, reparto de costes y derecho de salida.

Cómo convertir 45 respuestas en una decisión de compra

1. Haz primero una llamada de alcance de 45 minutos. Fija caso de uso, datos, usuarios, herramientas, regiones e impacto.
2. Pide al proveedor que responda en el spreadsheet y adjunte evidencias. Un enlace a política no supera Parcial.
3. Seguridad, privacidad, legal, producto y operaciones revisan solo las secciones que pueden aceptar o rechazar.
4. Convierte cada brecha aceptada en control contractual, remediación, responsable y fecha.
5. Antes de producción, prueba los cinco controles más importantes. Repite tras cambios materiales de modelo o flujo.

Por qué este cuestionario se basa en evidencias

La estructura sigue la asignación de responsabilidades, supervisión, logging e incidentes de la Ley de IA; la cadena de encargados y eliminación del RGPD; las reglas de switching del Data Act; las prácticas de pruebas y terceros de NIST AI RMF; y el enfoque por capas de ENISA. Exige evidencia del sistema porque una certificación o política no demuestra cómo se comporta tu tenant configurado.

Fuentes primarias y base de investigación

1. Reglamento (UE) 2024/1689, Ley de IA. Artículos 12, 14, 15, 25, 26, 50, 72 y 73 sobre cadena de valor, logs, supervisión, robustez, transparencia, seguimiento e incidentes.
2. Comisión Europea, panorama y calendario de la Ley de IA. Resumen actual de obligaciones de proveedor, responsable del despliegue, GPAI y transparencia, revisado el 17 de julio de 2026.
3. Reglamento (UE) 2016/679, RGPD. Artículos 28 y 32 sobre contratos, subencargados, auditorías, eliminación o devolución y seguridad.
4. Opinión 22/2024 del EDPB sobre encargados y subencargados. Identidad de la cadena, garantías suficientes y documentación de transferencias.
5. Opinión 28/2024 del EDPB sobre modelos de IA. Anonimato, interés legítimo y datos personales tratados ilícitamente en desarrollo y uso de modelos.
6. Reglamento (UE) 2023/2854, Data Act. Artículos 23 a 30 sobre contrato, exportación, transición, recuperación, eliminación y cargos en servicios cubiertos.
7. NIST AI Risk Management Framework Core. Riesgo de terceros, supervisión humana, pruebas documentadas, evaluación independiente y seguimiento.
8. ENISA Multilayer Framework for Good Cybersecurity Practices for AI. Fundamentos, controles específicos de IA y controles sectoriales a lo largo del ciclo de vida.