Cómo auditar la seguridad de un proveedor de IA antes de desplegarlo en tu empresa: checklist práctico

Después de leer esta guía sabrás qué preguntas hacer, qué documentos pedir y qué cláusulas contractuales exigir a cualquier proveedor de IA antes de darle acceso a los datos o procesos de tu empresa. El objetivo no es blindarte al cien por cien —eso no existe— sino documentar el riesgo que asumes y tener palancas contractuales si algo falla.

El detonante de esta guía es concreto: OpenAI acaba de pausar un modelo interno por capacidades cibernéticas que consideró demasiado peligrosas para desplegar. Si el propio fabricante no puede certificar el comportamiento de su modelo, la pregunta práctica es qué garantías reales puedes exigirle tú como cliente empresarial.

---

1. Pregunta por el proceso de evaluación del modelo, no por el resultado

La mayoría de proveedores te darán una hoja de producto con palabras como “evaluado”, “probado” o “seguro por diseño”. Eso no dice nada. Lo que necesitas saber es el proceso.

Preguntas concretas que debes hacer por escrito:

1. ¿Qué benchmarks o marcos de evaluación de seguridad habéis utilizado para este modelo? ¿NIST AI RMF, MITRE ATLAS, evaluaciones propias?
2. ¿Con qué frecuencia se reevalúa el modelo tras cada actualización? ¿Existe un changelog de seguridad accesible a clientes?
3. ¿Tenéis un equipo de red-teaming interno o externo? ¿Podéis compartir un resumen (no el informe completo) de los últimos hallazgos?
4. ¿El modelo ha sido evaluado específicamente para casos de uso como el vuestro —acceso a datos de clientes, generación de documentos legales, automatización de procesos críticos—?

Si el proveedor no puede responder a las preguntas 1 y 4, tienes un problema. Si las responde con generalidades, pide los documentos que las respaldan.

---

2. Exige documentación antes de firmar

Estos son los documentos que debes pedir, no como cortesía sino como condición para avanzar en la negociación:

• Política de uso aceptable (AUP): define qué puede y no puede hacer el modelo. Léela buscando exclusiones que afecten a tu caso de uso. Si el proveedor excluye responsabilidad por “outputs inesperados en entornos de producción”, eso es una señal de alerta directa.
• Data Processing Agreement (DPA): quién procesa los datos, en qué jurisdicción, durante cuánto tiempo y con qué subprocesadores. En España, el RGPD exige que este documento exista y sea firmado antes de cualquier transferencia de datos personales.
• Informe SOC 2 Tipo II o equivalente: acredita controles de seguridad operativa. Si el proveedor no tiene ninguna certificación equivalente, asume que sus controles internos no han sido auditados por terceros.
• Política de divulgación de vulnerabilidades (CVD/VDP): ¿tienen un canal para reportar vulnerabilidades? ¿Cuál es el tiempo de respuesta comprometido?
• Historial de incidentes de seguridad: no es habitual que lo compartan, pero puedes pedir un resumen de incidentes en los últimos 12 meses y los tiempos de resolución. La negativa a compartir cualquier dato en este punto es información en sí misma.

---

3. Qué SLA de seguridad son exigibles

Un SLA de disponibilidad (99,9 % uptime) no es un SLA de seguridad. Son cosas distintas. Lo que debes negociar:

1. Tiempo máximo de notificación de incidentes de seguridad: el RGPD exige notificar a la autoridad competente en 72 horas; exige al proveedor que te notifique a ti en menos tiempo —24 horas es el estándar razonable— para que puedas actuar.
2. Tiempo de respuesta ante vulnerabilidades críticas: pide un compromiso explícito de parcheo en menos de X días para vulnerabilidades CVSS ≥ 9.0.
3. Ventanas de mantenimiento con previo aviso: cualquier cambio en el modelo que pueda afectar al comportamiento debe comunicarse con antelación suficiente. Cuánto es suficiente depende de tu operativa, pero menos de 5 días hábiles para cambios sustanciales es problemático.
4. Plan de continuidad si el modelo se pausa o retira: esto es exactamente lo que acaba de ocurrir con Astra. Si el proveedor pausa o modifica el modelo sin previo aviso, ¿qué alternativa tienes? ¿Existe un modelo de respaldo? ¿Quién asume los costes de migración?

---

4. Cláusulas contractuales que debes incluir o negociar

Los contratos estándar de SaaS están escritos para proteger al proveedor, no a ti. Estas son las cláusulas que debes revisar o añadir:

Cláusula de cambio de modelo con previo aviso El proveedor debe notificarte con al menos 30 días de antelación cualquier cambio sustancial en el modelo subyacente. Define “sustancial”: cambios que alteren el comportamiento en más de un umbral medible, cambios en las políticas de uso aceptable, pausas o retiradas.

Cláusula de auditoría Reserva el derecho a solicitar evidencia de los controles de seguridad del proveedor una vez al año, ya sea mediante cuestionario estandarizado (CAIQ de la Cloud Security Alliance, por ejemplo) o mediante un informe de auditoría de terceros.

Limitación de responsabilidad equilibrada Los contratos estándar suelen limitar la responsabilidad del proveedor al importe pagado en los últimos 12 meses. Negocia excepciones para brechas de datos o incumplimientos del DPA: en esos casos, la limitación no debe aplicar o debe ser significativamente mayor.

Derecho de salida sin penalización por incidente de seguridad Si el proveedor sufre un incidente de seguridad que afecte a tus datos o si modifica unilateralmente el modelo de una manera que comprometa tu operativa, debes poder rescindir el contrato sin penalización.

Portabilidad de datos garantizada Al terminar el contrato, el proveedor debe devolverte todos tus datos en un formato estándar y eliminar cualquier copia en un plazo definido. Sin esta cláusula, dependes de su buena voluntad.

---

5. Cómo interpretar la política de uso aceptable

La AUP define los límites del servicio y, de forma implícita, los riesgos que el proveedor no asume. Lee estos apartados con atención:

• Exclusiones de responsabilidad por outputs: si el proveedor excluye cualquier responsabilidad por el contenido generado, cualquier error operativo recae íntegramente sobre ti.
• Restricciones de uso: algunos modelos prohíben explícitamente ciertos sectores (defensa, infraestructuras críticas) o casos de uso (toma de decisiones automatizada sin supervisión humana). Verifica que tu caso de uso no esté en la lista gris.
• Cambios unilaterales en la AUP: ¿puede el proveedor modificar la política con efecto inmediato? Eso significa que lo que es válido hoy puede no serlo mañana sin que tengas recurso contractual.

Si el proveedor ofrece agentes de IA con capacidad de actuar sobre sistemas externos, la AUP debe especificar también qué acciones están permitidas, cuáles requieren confirmación humana y cuáles están bloqueadas por diseño.

---

Errores más comunes a evitar

• Aceptar el contrato estándar sin negociar: los proveedores grandes tienen plantillas diseñadas para el autoservicio. Las empresas con más de 50 usuarios o datos sensibles tienen poder de negociación real; úsalo.
• Confundir certificación ISO 27001 con seguridad del modelo: ISO 27001 cubre la gestión de seguridad de la información de la organización, no el comportamiento del modelo. Son capas distintas.
• No documentar el proceso de due diligence: si algo sale mal, necesitas demostrar que hiciste las preguntas correctas antes de desplegar. Guarda los correos, las respuestas del proveedor y los documentos firmados.
• Ignorar los riesgos de inyección de prompts en integraciones: si el modelo procesa contenido externo —correos, documentos de clientes, páginas web—, la inyección indirecta de prompts es un vector de ataque real y ya automatizado. Pregunta al proveedor qué mitigaciones tiene implementadas.
• Asumir que “seguro por diseño” significa algo sin leer el contrato: como muestra el análisis de lo que el contrato de Copilot realmente garantiza frente a lo que Microsoft promete, el marketing y el texto legal no siempre dicen lo mismo.

---

Qué hacer: due diligence estructurado antes de desplegar cualquier modelo de IA en producción
Documentos clave: AUP, DPA, SOC 2 Tipo II, política de CVD, historial de incidentes
Cláusulas imprescindibles: aviso previo de cambio de modelo, auditoría, salida sin penalización, portabilidad
Riesgo de fondo: los proveedores no pueden certificar el comportamiento de sus propios modelos — el contrato es tu única red
Estado: guía práctica · no verificada a mano por la redacción