Evaluación de riesgos de proveedores de IA: cuestionario, modelo de puntuación y lista de evidencias (2026)
Una evaluación de riesgos de proveedores de IA es la revisión que realizas antes de que un producto o una API de IA de terceros acceda a tus datos: clasificas el riesgo del caso de uso, planteas preguntas específicas sobre IA (entrenamiento con tus datos, conservación, subencargados del tratamiento y proveedores de modelos, pruebas de seguridad, riesgos de las respuestas y normativa), recopilas evidencias para cada respuesta, puntúas al proveedor y estableces condiciones contractuales y medidas de seguimiento. La diferencia respecto a una revisión habitual de proveedores es que los proveedores de IA añaden el comportamiento de los modelos, la reutilización de datos y una cadena de proveedores de modelos subyacentes. Esta guía ofrece un cuestionario listo para usar, un modelo de puntuación y una lista de evidencias, actualizados al 26 de octubre de 2026.
Está dirigida a los equipos de seguridad, compras y plataformas que aprueban API de IA, pasarelas de IA y herramientas SaaS con funciones de IA. No constituye asesoramiento jurídico.
Por qué el riesgo de los proveedores de IA es diferente
Una revisión tradicional de terceros pregunta por el control de acceso, el cifrado, la disponibilidad y las certificaciones. Los proveedores de IA necesitan todo eso y, además:
| Nuevo riesgo | Por qué importa | Ejemplo de pregunta |
|---|---|---|
| Reutilización de datos para entrenamiento | Tus prompts podrían mejorar un modelo que utilizan otros | ¿Se usan los datos de los clientes para entrenamiento o evaluación de forma predeterminada? |
| Proveedores indirectos | El proveedor puede reenviar datos a proveedores de modelos | ¿Qué proveedores de modelos procesan nuestros datos y en qué regiones? |
| Comportamiento del modelo | Las respuestas pueden ser incorrectas, inseguras o filtrar datos | ¿Cómo se prueba el sistema frente a la inyección de prompts y las fugas de datos? |
| Cambios rápidos | Los modelos y las versiones cambian sin previo aviso | ¿Cómo se anuncian los cambios de modelo y cómo se gestionan sus versiones? |
| Normativa | El Reglamento de IA de la UE y las normas sectoriales añaden obligaciones | ¿Cómo clasificáis este sistema según el Reglamento de IA de la UE? |
| Exposición a costes | La facturación por uso puede dispararse | ¿Hay cuotas, límites de gasto y alertas? |
El Marco de Gestión de Riesgos de IA del NIST aborda explícitamente el riesgo de la IA de terceros en sus funciones Govern y Map, y el Perfil de IA Generativa del NIST (AI 600-1) incluye los riesgos de la cadena de valor y de la integración de componentes entre los riesgos de la IA generativa.
Paso 1: Clasifica al proveedor por nivel según el caso de uso
No todas las herramientas de IA necesitan el mismo grado de revisión. Asigna primero un nivel y adapta después el cuestionario.
| Nivel | Criterios | Profundidad de la revisión |
|---|---|---|
| Nivel 1 (alto) | Datos de clientes, datos personales, datos sujetos a regulación o una IA que ejecuta acciones (envía, paga, modifica registros) | Cuestionario completo, evidencias, pruebas de seguridad y revisión jurídica |
| Nivel 2 (medio) | Datos internos; una persona revisa cada respuesta | Cuestionario básico + evidencias clave |
| Nivel 3 (bajo) | Solo datos públicos, sin integración | Formulario breve + revisión de condiciones |
Registra el nivel y su justificación en el expediente del proveedor. Revisa el nivel cuando cambie el caso de uso.
Paso 2: Envía el cuestionario de riesgos del proveedor de IA
Añade estas preguntas a tu cuestionario de seguridad habitual (por ejemplo, el SIG de Shared Assessments o la Matriz de Controles de IA de CSA).
Tratamiento de datos y privacidad
- ¿Se utilizan nuestros datos (prompts, archivos, respuestas) para entrenar o evaluar algún modelo? ¿Cuál es la configuración predeterminada? ¿Podemos excluirnos o existe un compromiso contractual?
- ¿Cuánto tiempo se conservan los prompts, las respuestas y los registros? ¿Podemos configurar una conservación nula o de corta duración?
- ¿Dónde se procesan y almacenan los datos (regiones)? ¿Podemos fijar una región?
- ¿Qué subencargados del tratamiento y proveedores de modelos reciben nuestros datos? ¿Cómo se nos notifican los cambios?
- ¿Hay un acuerdo de tratamiento de datos (DPA) disponible y cubre el procesamiento con IA y las transferencias internacionales?
Gobernanza de modelos y sistemas
- ¿Qué modelos utiliza el producto y son propios o de terceros?
- ¿Cómo se comunican y prueban los cambios de modelo o versión?
- ¿Qué evaluaciones realizáis para medir la precisión, los sesgos y la seguridad, y podéis compartir los resultados?
- ¿Disponéis de documentación sobre el uso previsto y las limitaciones conocidas (fichas de modelo o de sistema)?
Seguridad
- ¿Qué certificaciones o informes de verificación cubren el servicio de IA (SOC 2 Type II, ISO 27001, ISO 42001)? ¿El producto de IA está incluido en su alcance?
- ¿Cómo comprobáis la resistencia a la inyección de prompts, las fugas de datos y la autonomía excesiva (por ejemplo, tomando como referencia el Top 10 de OWASP para aplicaciones con LLM)?
- ¿Cómo se emiten, delimitan, rotan y revocan las claves de API?
- ¿Qué contienen los registros, quién puede acceder a ellos y podemos exportarlos?
- ¿Cuál es vuestro procedimiento de respuesta a incidentes y qué plazos de notificación aplicáis a los incidentes relacionados con IA?
Operaciones y costes
- ¿Cuál es el SLA y cubre las funciones de IA y los proveedores de modelos subyacentes?
- ¿Qué ocurre cuando un proveedor de modelos subyacente no está disponible: se utiliza una alternativa, se ofrece un servicio degradado o falla el servicio?
- ¿Hay cuotas por clave, límites de gasto y alertas de uso?
- ¿Cuáles son las condiciones de salida: exportación de datos, confirmación de eliminación y plazos de preaviso?
Normativa
- ¿Cómo clasificáis el sistema según el Reglamento de IA de la UE y qué obligaciones cumplís como proveedor o como apoyo al responsable del despliegue? El calendario de aplicación indica actualmente que los requisitos para los sistemas de alto riesgo del anexo III se aplicarán a partir del 2 de diciembre de 2027.
- ¿Las respuestas incluyen los avisos o el marcado de contenido generado por IA cuando se exige?
Paso 3: Recopila evidencias, no solo respuestas
Cada «sí» en una revisión de nivel 1 debería remitir a algo que puedas archivar.
| Respuesta | Evidencia que debes solicitar | Qué comprobar |
|---|---|---|
| «No entrenamos con tus datos» | Cláusula contractual, DPA, documentación de la configuración del producto | Si se aplica de forma predeterminada o requiere exclusión voluntaria; si también cubre a los subencargados del tratamiento |
| «Los datos se conservan durante 30 días» | Política de conservación, captura de pantalla de la configuración de administración | Si se aplica a los registros y a las copias de seguridad |
| «SOC 2 Type II» | Informe bajo acuerdo de confidencialidad, carta de continuidad de controles | Si el servicio de IA está incluido en el alcance; fecha de cierre del periodo; excepciones |
| «Realizamos pruebas de inyección de prompts» | Resumen de pruebas o informe de pruebas de penetración | Fecha, alcance, hallazgos y repetición de las pruebas |
| «Cuotas por clave» | Documentación o captura de pantalla de la consola; una prueba propia | Si los límites bloquean realmente las solicitudes |
| «Proveedores de modelos identificados» | Lista de subencargados del tratamiento con sus regiones | Si se ajusta a tus necesidades de residencia de datos |
Un certificado sirve como evidencia para una evaluación inicial, pero no demuestra que tu caso de uso sea seguro. Para evidencias específicas de pasarelas, consulta las evidencias SOC 2 para una pasarela de API de IA, la lista de comprobación del DPA de una pasarela de IA y la lista de comprobación de conservación de datos en API de IA.
Paso 4: Puntúa al proveedor
Puntúa cada área de 1-5 (5 = sólida y respaldada por evidencias) y pondérala según su importancia para tu caso de uso:
| Área | Peso (ejemplo de nivel 1) | Puntuación 1 | Puntuación 5 |
|---|---|---|---|
| Uso y conservación de datos | 25% | Entrena con los datos de forma predeterminada, conservación poco clara | Sin entrenamiento, conservación configurable y compromiso contractual |
| Seguridad y pruebas | 25% | Sin pruebas específicas de IA | Evidencias recientes de pruebas, con repetición de las pruebas |
| Proveedores indirectos y residencia de datos | 15% | Proveedores de modelos desconocidos | Lista completa, regiones y aviso de cambios |
| Gobernanza y cambios | 15% | Cambios de modelo sin aviso | Versiones identificadas, anunciadas y evaluadas |
| Operaciones y controles de costes | 10% | Sin SLA ni cuotas | SLA, alternativa ante fallos, cuotas y límites de gasto |
| Preparación normativa | 10% | Sin criterio definido | Clasificación y obligaciones documentadas |
Un script de puntuación sencillo que puedes guardar en el expediente del proveedor:
WEIGHTS = {"data": .25, "security": .25, "fourth_parties": .15,
"governance": .15, "operations": .10, "regulatory": .10}
def vendor_score(scores: dict, evidence: dict) -> dict:
"""scores: 1-5 per domain; evidence: True if the score is backed by filed evidence"""
capped = {d: (s if evidence.get(d) else min(s, 2)) for d, s in scores.items()} # no evidence -> max 2
total = sum(WEIGHTS[d] * capped[d] for d in WEIGHTS)
decision = "approve" if total >= 4 else "approve with conditions" if total >= 3 else "reject or escalate"
return {"score": round(total, 2), "decision": decision, "capped": capped}
print(vendor_score(
{"data": 5, "security": 4, "fourth_parties": 4, "governance": 3, "operations": 4, "regulatory": 3},
{"data": True, "security": True, "fourth_parties": True, "governance": False, "operations": True, "regulatory": False},
))
La regla que limita la puntuación es importante: una afirmación sin respaldo nunca debería obtener la misma puntuación que una verificada mediante pruebas.
Paso 5: Verifica por tu cuenta las afirmaciones que implican riesgo
Con los proveedores de nivel 1, comprueba algunos aspectos en un entorno de pruebas aislado antes de firmar:
- Revocación de claves: revoca una clave de prueba y confirma que las solicitudes fallan de inmediato.
- Cuotas: configura una cuota baja y confirma que las solicitudes se bloquean al alcanzarla.
- Lista de modelos permitidos: llama a un modelo que no debería estar permitido y confirma que se deniega la solicitud.
- Contenido de los registros: comprueba qué almacena el registro de una solicitud (solo metadatos o el prompt completo).
# After revoking the test key in the vendor console, this should return 401
curl -s -o /dev/null -w "%{http_code}\n" https://api.vendor.example/v1/chat/completions \
-H "Authorization: Bearer $REVOKED_TEST_KEY" -H "Content-Type: application/json" \
-d '{"model":"any-model","messages":[{"role":"user","content":"ping"}]}'
Un cuestionario te dice lo que afirma el proveedor; estas pruebas verifican directamente algunas de esas afirmaciones. Una prueba de seguridad completa de tu propia aplicación de IA es un trabajo aparte, que abordamos en nuestra guía de auditoría de seguridad de IA.
Paso 6: Incorpora los controles al contrato
| Cláusula | Motivo |
|---|---|
| Prohibición de entrenar con datos de los clientes (también para los subencargados del tratamiento) | Evita la reutilización de datos |
| Límite de conservación y eliminación al finalizar la relación | Limita la exposición |
| Aviso de cambios en subencargados del tratamiento y proveedores de modelos | Permite oponerse a nuevos proveedores indirectos |
| Plazo de notificación de brechas de seguridad e incidentes de IA | Agiliza la respuesta |
| Derechos de auditoría y acceso a evidencias | Permite volver a verificar las afirmaciones |
| SLA que cubra las funciones de IA | Permite exigir el cumplimiento de la disponibilidad |
| Residencia de datos | Garantiza el cumplimiento de las normas sobre transferencias |
Paso 7: Haz un seguimiento tras la aprobación
- Revisa de nuevo a los proveedores de nivel 1 cada año y cuando cambien sus modelos, subencargados del tratamiento o condiciones.
- Supervisa el uso y el coste por proveedor y por clave.
- Mantente al tanto de los incidentes y avisos de seguridad.
- Mantén una lista de modelos aprobados para que los nuevos modelos pasen por una revisión (flujo de aprobación de modelos de IA).
Cómo evaluar una pasarela de API de IA como proveedor
Una pasarela se sitúa entre tus aplicaciones y varios proveedores de modelos, así que evalúa ambas capas: la propia pasarela (claves, registros, cuotas, facturación y soporte) y cada proveedor subyacente al que dirige las solicitudes. Pide la lista de rutas y el detalle de qué datos recibe cada proveedor. Con Flatkey, por ejemplo, puedes consultar el modelo, los tokens, el coste y la clave de cada solicitud en el panel de uso, exportar registros en CSV/JSON como evidencia y crear o revocar claves por entorno en la gestión de claves de API. Guarda esas exportaciones en el expediente de compras junto al cuestionario. Nuestro paquete de evidencias para la compra de una pasarela de IA enumera el conjunto completo, y la revisión de evidencias de proveedores de modelos aborda los proveedores subyacentes.
Preguntas frecuentes
¿Qué es una evaluación de riesgos de proveedores de IA?
Es una revisión estructurada de un producto o una API de IA de terceros que comprueba el uso de datos, la seguridad, los proveedores indirectos de modelos, la gobernanza, las operaciones y la preparación normativa antes de su aprobación, con el respaldo de evidencias y una puntuación de riesgo.
¿Qué preguntas debe incluir un cuestionario para proveedores de IA?
Como mínimo: si tus datos se utilizan para entrenar modelos, los plazos de conservación, las regiones de procesamiento, los subencargados del tratamiento y proveedores de modelos, las certificaciones que cubren el servicio de IA, las pruebas de seguridad específicas de IA, los controles de claves y registros, el SLA y las alternativas ante fallos, los controles de costes, las condiciones de salida y la clasificación según el Reglamento de IA de la UE.
¿En qué se diferencia la gestión de riesgos de proveedores de IA de la TPRM habitual?
La IA añade la reutilización de datos para entrenamiento, proveedores indirectos de modelos, respuestas impredecibles, cambios frecuentes de modelo y normativa específica de IA. Los controles habituales de gestión de riesgos de terceros (TPRM) siguen siendo aplicables.
¿Puede ayudar la IA en la gestión de riesgos de proveedores?
Sí, las herramientas de IA pueden resumir cuestionarios y señalar evidencias que faltan, pero una persona debe decidir la aprobación y verificar las evidencias, especialmente en el caso de proveedores de nivel 1.
¿Basta un informe SOC 2 para aprobar a un proveedor de IA?
No. Comprueba que el servicio de IA esté incluido en el alcance y el periodo del informe y, aun así, plantea preguntas específicas sobre entrenamiento, conservación, proveedores de modelos y pruebas. La descripción general de SOC 2 de AICPA explica qué cubre un informe SOC 2.
¿Qué marcos ayudan a gestionar el riesgo de los proveedores de IA?
El NIST AI RMF y su Perfil de IA Generativa, el Top 10 de OWASP para LLM para los riesgos técnicos, la Matriz de Controles de IA de CSA, ISO/IEC 42001 para los sistemas de gestión de IA y el cuestionario SIG de Shared Assessments.
Fuentes
Verificadas el 26 de octubre de 2026: NIST AI RMF, NIST AI 600-1, Top 10 de OWASP para aplicaciones con LLM, Matriz de Controles de IA de CSA, SIG de Shared Assessments, calendario del Reglamento de IA de la UE, lista de comprobación del RGPD para pasarelas de API de IA.
