¿Qué es la gestión de riesgos de IA de terceros?
Gobernanza, riesgo y aseguramiento
La gestión de riesgos de IA de terceros es el proceso de identificar, evaluar, contratar, supervisar y, si es necesario, abandonar las dependencias externas de IA en las que se apoya una organización. Abarca proveedores de modelos, proveedores de nube y plataformas, suministradores de datos, integradores, contratistas, componentes de código abierto y socios en la cadena de distribución. A diferencia de la gestión genérica de proveedores, se centra en cuestiones específicas de la IA, como el comportamiento del modelo, la procedencia de los datos, la explicabilidad, la asignación de roles legales, la seguridad, la propiedad intelectual, la supervisión humana y el control de cambios.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Cuando las organizaciones adquieren o integran IA, rara vez compran un producto único y bien delimitado. Con frecuencia dependen de una cadena que puede incluir un proveedor de aplicaciones, una API de modelo, un proveedor de modelo fundacional, servicios de moderación o búsqueda, alojamiento en la nube, conjuntos de datos externos, componentes de código abierto y subencargados del tratamiento. La gestión de riesgos de IA de terceros mapea esa cadena y verifica dónde reside realmente el riesgo material.
A continuación, se plantea si la organización puede utilizar esa cadena para el fin previsto sin perder el control sobre la privacidad, la seguridad, la fiabilidad, la explicabilidad, la continuidad del servicio o la responsabilidad legal. Esto incluye comprobar quién hace qué, qué evidencia puede aportar el proveedor, cómo puede probarse el sistema, qué puede cambiar tras el lanzamiento y cómo respondería la organización si un proveedor falla o modifica sus condiciones.
Por eso se trata de un mecanismo de gobernanza, no de un simple paso en el proceso de compra. Genera la evidencia que respalda la garantía de la IA, el control interno, la auditoría y la supervisión directiva.
Por qué es importante
La gobernanza de la IA suele fallar en los límites de la organización, donde una dependencia oculta del proveedor, una actualización del modelo o una práctica con los datos moldea silenciosamente lo que el sistema desplegado puede hacer. Un componente de terceros puede afectar a la privacidad, la resiliencia cibernética, la exposición de la propiedad intelectual, el tratamiento transfronterizo de datos, la equidad, la explicabilidad, la revisión humana y la capacidad de responder a preguntas de reguladores o usuarios.
En muchos marcos normativos, adquirir la herramienta no transfiere la responsabilidad. Las obligaciones de protección de datos pueden permanecer en el responsable del tratamiento, y la regulación de la cadena de valor también puede desplazar obligaciones en sentido contrario, por ejemplo cuando un actor en la cadena de distribución cambia la marca, modifica sustancialmente o reutiliza un sistema. Una gobernanza de la IA madura trata, por tanto, la diligencia debida con terceros como un control del ciclo de vida, no como una lista de verificación puntual en la contratación.
Cómo funciona
Comenzar mapeando la cadena de valor de la IA
La gestión de riesgos de IA de terceros comienza con un mapa de dependencias, no con el nombre de un proveedor. El enfoque útil abarca toda la cadena de valor: hay que analizar a los proveedores de insumos de IA, a los actores del ciclo de vida de la IA y a los usuarios del sistema, no solo a la entidad que emitió la factura. Se deben registrar la parte contratante directa, el proveedor del modelo, cualquier socio de ajuste fino, el proveedor de alojamiento en la nube, los complementos, los conjuntos de datos externos, los componentes de código abierto, los anotadores y los subencargados del tratamiento. Conviene anotar qué datos fluyen hacia dónde, qué jurisdicciones están implicadas, qué puede cambiar sin previo aviso, dónde se sitúa la revisión humana y qué componentes son críticos para la misión.
En el caso de la IA generativa, esto suele implicar mantener una lista de proveedores aprobados y un registro de todos los terceros con acceso al contenido de la organización. También implica distinguir entre un modelo fundacional, un modelo con ajuste fino, un modelo integrado dentro de otro producto y una plataforma que simplemente aloja o intermedia el acceso. Se trata de posiciones de control distintas que raramente generan los mismos riesgos.
Determinar el rol legal y de gobernanza propio
Una vez visible la cadena, conviene determinar el rol propio. Si se tratan datos personales, hay que decidir si se actúa como responsable, corresponsable o encargado del tratamiento, y si el servicio permite atender solicitudes de derechos, normas de retención y restricciones de transferencia. Si se utiliza IA en un contexto regulado, hay que determinar si se actúa únicamente como desplegador o si la marca, la modificación sustancial o el cambio de finalidad prevista podrían trasladar obligaciones propias del proveedor.
La titularidad debe ser compartida, pero no difusa. Un responsable de negocio designado debe patrocinar el caso de uso y asumir el riesgo residual dentro de la autoridad acordada. El área de contratación lidera la diligencia comercial; los equipos de privacidad, seguridad y legal revisan las cuestiones reguladas; los equipos de producto, datos e ingeniería prueban la integración y el diseño de controles; y la alta dirección establece los umbrales de escalada y la tolerancia al riesgo. La garantía y la auditoría llegan después para comprobar si el mecanismo funciona realmente, pero no sustituyen el análisis inicial de roles.
Realizar la diligencia debida específica de IA antes de la aprobación
La diligencia debida debe ser proporcional al caso de uso. Un modelo utilizado en selección de personal, crédito, seguros, identidad, seguridad o toma de decisiones en servicios públicos merece una revisión mucho más profunda que una herramienta de redacción de bajo riesgo. El objetivo no es aplicar un mismo cuestionario a todas las herramientas de IA, sino solicitar evidencia acorde con la relevancia legal, operativa y social del despliegue.
La evidencia útil incluye documentación del sistema o del modelo, uso previsto y limitaciones, resúmenes de los datos de entrenamiento o fuente cuando estén disponibles, métodos de evaluación, modos de fallo conocidos, controles de seguridad, listas de subencargados, registros de cambios, acuerdos de soporte, historial de incidentes, condiciones de eliminación y retención, y el enfoque del proveedor respecto a la supervisión humana y el uso indebido. Para usos de mayor riesgo, conviene preguntar si el proveedor puede respaldar pruebas independientes, explicabilidad, verificaciones de tipo red team y evaluaciones como una EIPD o una evaluación de impacto de la IA. En la práctica, una diligencia sólida con terceros también verifica si el proveedor puede explicar cómo se sustentan sus afirmaciones, no limitarse a repetir el lenguaje de marketing.
Plasmar la posición de control en contratos y normas operativas
Los contratos convierten la diligencia en control exigible. Deben asignar roles, definir usos permitidos y prohibidos, exigir notificación de cambios en el modelo o el servicio, establecer niveles de servicio, indicar quién gestiona incidentes y reclamaciones de usuarios, controlar el subencargo del tratamiento, regular la devolución o eliminación de datos, y preservar la capacidad del comprador de realizar pruebas, revisiones u obtener evidencia de garantía. En la contratación de IA, el contrato también suele necesitar abordar la propiedad intelectual, la procedencia, las restricciones sobre datos de entrenamiento o de entrada, el bloqueo por caja negra, la transferencia de conocimiento y los acuerdos de fin de vida.
Aquí es también donde la diligencia sobre la plataforma se vuelve real. Un contrato con el proveedor del servicio de interfaz no es suficiente si el riesgo material reside en el proveedor del modelo subyacente o en el proveedor de nube. La organización necesita saber qué obligaciones se trasladan, cuáles no, y qué ocurre si cambia una dependencia en la cadena ascendente. Las normas internas de uso aceptable deben reflejar el contrato, de modo que el personal sepa, por ejemplo, si pueden incluirse datos personales en los prompts, si los resultados requieren revisión humana y cuándo un cambio de versión del modelo activa una nueva aprobación.
Probar, supervisar y ensayar el plan de contingencia tras el lanzamiento
La gestión de riesgos de IA de terceros no termina con la firma ni con el lanzamiento. Los proveedores actualizan modelos, retiran funcionalidades, modifican configuraciones de moderación, cambian el alojamiento, añaden conectores y modifican condiciones. Un proceso de control maduro incluye, por tanto, supervisión continua, reevaluaciones periódicas, revisión de versiones y lanzamientos, canales de notificación de incidentes, umbrales de reaprobación para cambios materiales y planes de contingencia.
En el caso de la IA generativa en particular, esto implica supervisar no solo el servicio directo, sino también los efectos en la cadena de distribución derivados de complementos, contenido recuperado, deriva del modelo, gestión de prompts y cambios en las políticas del proveedor. Si el servicio de IA es crítico, la organización debe saber cómo continuar de forma segura si el proveedor degrada, suspende o retira la capacidad. En ocasiones eso significa cambiar de proveedor; en otras, aplicar un procedimiento manual de respaldo. En segmentos concentrados del mercado de IA, especialmente donde solo existen unos pocos proveedores de modelos o infraestructura, la desvinculación inmediata puede no ser realista, por lo que la capacidad de negociación, la supervisión adicional y la planificación de contingencias son fundamentales.
Crear un rastro de evidencia para la garantía y la auditoría
El mecanismo justifica su existencia al producir evidencia que pueda verificarse posteriormente. Los artefactos habituales incluyen un inventario de la cadena de valor, un memorando de clasificación de riesgos, cuestionarios de diligencia debida, una EIPD u otra evaluación de impacto, anexos contractuales, documentación del proveedor, registros de pruebas, decisiones de aprobación, registros de incidentes, avisos de cambio y notas de desmantelamiento. Cuando el ámbito incluye IA de alto riesgo de la UE, la base de evidencia también puede incluir documentos de conformidad, instrucciones de uso y registros de inscripción relacionados.
Este archivo es lo que revisan los equipos de garantía y los auditores. Les permite comprobar si la organización comprendió la cadena de dependencias, formuló las preguntas adecuadas, estableció los controles correctos y los mantuvo actualizados. Normas como ISO/IEC 42001 pueden organizar este material dentro de un sistema de gestión de la IA formal, e ISO/IEC 42006 explica cómo los organismos de certificación de terceros auditan ese tipo de sistema. Esto puede reforzar la confianza externa, pero no elimina la necesidad de un juicio legal y operativo a nivel de caso de uso.
Ejemplos
Una empresa desea utilizar un servicio de modelo de lenguaje grande de terceros para redactar respuestas de atención al cliente que pueden contener datos personales. Un flujo de trabajo adecuado consiste en realizar la diligencia debida antes de la contratación, evaluar si se requiere una EIPD, documentar si la empresa actúa como responsable o encargado del tratamiento, confirmar los subencargados y las transferencias internacionales, exigir soporte para solicitudes de derechos, establecer condiciones de incidentes y eliminación, y supervisar los cambios del proveedor tras el lanzamiento. Este es exactamente el tipo de caso en que una revisión cibernética genérica resulta insuficiente.
Un empleador en la UE adquiere un sistema de IA que filtra candidatos a puestos de trabajo. Los usos relacionados con la selección de personal y la gestión de trabajadores se consideran de alto riesgo en virtud del EU AI Act, por lo que el comprador necesita algo más que una revisión estándar de software. Debe obtener la documentación técnica y de cumplimiento del proveedor, comprender las instrucciones de uso y los requisitos de supervisión humana, y evitar cambios que pudieran convertir al comprador en proveedor, como cambiar la marca del sistema o realizar una modificación sustancial.
Un organismo público que lleva a cabo una contratación de IA debe comenzar por el problema y los datos, no por un producto preferido. La orientación oficial del Reino Unido aconseja a los compradores evaluar la calidad de los datos y los sesgos antes de salir al mercado, preguntar a los proveedores cómo funcionan los algoritmos y los modelos, solicitar claridad sobre los datos de entrenamiento aportados al proyecto, considerar una auditoría independiente, evitar el bloqueo por caja negra, asignar la responsabilidad a la parte mejor capacitada para gestionarla, y mantener registros de procesos y supervisión durante toda la vida del contrato.
Malentendidos frecuentes
La gestión de riesgos de IA de terceros es simplemente la gestión ordinaria de proveedores con una etiqueta de IA. No lo es. Examina el comportamiento del modelo, la procedencia de los datos, la explicabilidad, la asignación de roles legales, la deriva, el control de versiones y las dependencias de la cadena de valor que una revisión ordinaria de proveedores puede pasar por alto.
Solo los proveedores de pago cuentan como terceros. No es así. Los modelos de código abierto, los conjuntos de datos públicos, los wrappers de API, los contratistas, los complementos y las plataformas alojadas pueden generar dependencias externas de IA.
Si el proveedor construyó el sistema, el proveedor asume toda la responsabilidad. No necesariamente. Las obligaciones de privacidad, despliegue y sector pueden permanecer en el comprador, y algunos cambios en la cadena de distribución pueden trasladar obligaciones propias del proveedor al comprador.
Una revisión puntual antes del contrato es suficiente. No lo es. Los servicios de IA cambian tras el lanzamiento, y esos cambios pueden alterar el cumplimiento, el riesgo y el rendimiento.
Un certificado o informe de auditoría resuelve la cuestión. No lo hace. La garantía externa puede ser evidencia útil, pero no sustituye al juicio interno, al control contractual ni a la supervisión continua.
Riesgos y límites
La gestión de riesgos de IA de terceros no puede eliminar la opacidad. Algunos proveedores no revelarán todos los detalles del entrenamiento, los métodos internos ni todas las dependencias en la cadena ascendente, especialmente en entornos propietarios o de código abierto mixto. En esos casos, la verdadera pregunta de gobernanza es si la incertidumbre restante es aceptable para el caso de uso.
Tampoco es un sustituto de la gobernanza interna del producto, la supervisión humana o la responsabilidad sobre cómo se utiliza realmente un sistema. Una organización puede adquirir un servicio bien documentado y aun así desplegarlo de forma deficiente.
El marco legal no es idéntico en todas partes. Las normas específicas de IA, la ley de protección de datos, las normas sectoriales, las normas de contratación pública y el derecho contractual pueden aplicarse simultáneamente. Algunas obligaciones en la cadena de valor son explícitas, como en el EU AI Act. En otros contextos surgen a través de normas más amplias de responsabilidad, privacidad, externalización o gobernanza de productos. La salida también puede ser difícil cuando solo existe un número reducido de proveedores de modelos o infraestructura, por lo que la planificación de contingencias forma parte del mecanismo, no es un complemento opcional.
Próximos pasos
Crear un registro único de dependencias de IA de terceros en toda la organización, incluidos los componentes de código abierto e integrados, no solo los proveedores nominados.
Establecer umbrales para una revisión reforzada, por ejemplo cuando haya datos personales, uso en el ámbito laboral, uso crítico para la seguridad, soporte a decisiones de cara al público, sectores regulados o cualquier sistema que pueda cambiar materialmente sin previo aviso.
Actualizar las plantillas de contratación y las cláusulas contractuales para que soliciten evidencia específica de IA en lugar de basarse en cuestionarios genéricos de TIC.
Exigir una decisión de lanzamiento documentada para los usos de mayor riesgo, con responsables designados, registros de pruebas, contactos para incidentes, normas de tratamiento de datos y un plan de contingencia.
Vincular la evidencia resultante al programa de garantía y auditoría de IA, de modo que el área de cumplimiento, la auditoría interna y la alta dirección puedan verificar si los controles sobre terceros siguen funcionando en la práctica.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿La gestión de riesgos de IA de terceros es lo mismo que la gestión de proveedores?
No. Incluye las verificaciones ordinarias de proveedores, pero va más allá al examinar cuestiones específicas de la IA, como la procedencia del modelo, los cambios de versión, la explicabilidad, el cumplimiento de derechos, la supervisión humana y si el uso modifica el rol legal propio.
¿Quién debe ser responsable internamente de la gestión de riesgos de IA de terceros?
Debe ser una función transversal. Un responsable de negocio debe patrocinar el caso de uso, el área de contratación debe liderar las verificaciones comerciales, los equipos de privacidad y legal deben revisar las cuestiones reguladas, el área de seguridad debe probar la resiliencia, y los equipos técnicos deben evaluar la integración, la supervisión y el plan de contingencia.
¿La IA de código abierto cuenta como dependencia de terceros?
Sí. Los modelos, bibliotecas, conjuntos de datos y herramientas de código abierto pueden generar riesgo de terceros incluso cuando no existe un contrato de proveedor clásico. Siguen afectando a la procedencia, el mantenimiento, la seguridad, las licencias y el soporte.
¿Qué evidencia debemos solicitar a un proveedor de modelos?
Conviene solicitar documentación sobre el uso previsto, las limitaciones, el tratamiento de datos, los métodos de evaluación, los modos de fallo conocidos, los controles de seguridad, los subencargados, la gestión de cambios, las condiciones de soporte, la gestión de incidentes y cualquier artefacto de transparencia disponible, como documentación del modelo o del sistema.
Si realizamos un ajuste fino o cambiamos la marca de un sistema, ¿puede cambiar nuestro rol?
Sí. En algunos marcos normativos puede ocurrir. El EU AI Act es un ejemplo claro, ya que un actor en la cadena de distribución puede convertirse en proveedor de un sistema de IA de alto riesgo en determinadas circunstancias, incluidos el cambio de marca, la modificación sustancial o el cambio de finalidad prevista que convierta el sistema en de alto riesgo.
¿Es suficiente una EIPD o una evaluación de impacto de la IA por sí sola?
No. Es un artefacto importante, pero no constituye el mecanismo completo. Siguen siendo necesarios el mapeo de dependencias, el control contractual, las pruebas, la supervisión, la gestión de incidentes y un plan de salida o contingencia.
¿Cómo encajan la residencia de datos y la soberanía de datos en este tema?
Se integran en el proceso de diligencia como preguntas de control sobre dónde se almacenan, acceden, tratan y gestionan los datos, qué ley es aplicable, qué subencargados están implicados y si el proveedor puede cumplir los requisitos de localización o transferencia.
¿La certificación implica que el sistema cumple la normativa?
No por sí sola. La certificación puede aportar evidencia externa útil de que un sistema de gestión ha sido auditado, pero el cumplimiento sigue dependiendo del caso de uso concreto, la jurisdicción, las condiciones contractuales y la forma en que la organización despliega y supervisa realmente la IA.