Gestión de riesgos de terceros para IA: una guía completa

La rápida adopción de herramientas de IA de terceros está creando un punto ciego crítico en la gestión de riesgos corporativos. En los más de 200 equipos de privacidad de nuestra comunidad, observamos constantemente organizaciones que adquieren desde software de marketing asistido por IA hasta modelos fundacionales empresariales utilizando los mismos cuestionarios de proveedores que emplean para bases de datos estáticas. Este enfoque no logra captar la naturaleza dinámica y voraz de datos de los algoritmos modernos.

Gestionar mal a los proveedores de IA conlleva riesgos extremadamente altos. Con la inminente aplicación de la Ley de IA de la UE, sumada a las obligaciones de protección de datos existentes, implementar un modelo de terceros inseguro o que no cumpla con la normativa puede derivar en graves sanciones regulatorias, daños a la reputación y pérdida de la confianza del cliente. La gobernanza de la IA ya no es un ejercicio teórico de cumplimiento; es un requisito fundamental para la resiliencia operativa de su organización.

Esta guía está dirigida a líderes de privacidad, seguridad e ingeniería responsables de gobernar el uso de IA de terceros. Proporciona un marco práctico paso a paso para construir un programa moderno de gestión de riesgos de terceros para IA.

En las siguientes secciones, describimos qué es exactamente el TPRM en un contexto moderno, por qué los enfoques tradicionales fallan con los algoritmos dinámicos y cómo implementar un ciclo de vida de riesgo dedicado a proveedores de IA. También aprenderá a abordar el complejo desafío del riesgo de terceros (Nth-party) y descubrirá los errores más comunes que debe evitar al evaluar proveedores externos de IA.

¿Qué es la gestión de riesgos de terceros (TPRM)?

La gestión de riesgos de terceros (TPRM) es el proceso sistemático de identificar, evaluar y mitigar los riesgos operativos, de seguridad y de cumplimiento que surgen al externalizar servicios o utilizar tecnologías de proveedores externos. Un marco de TPRM exitoso se basa en cuatro componentes principales: diligencia debida inicial, controles contractuales estrictos, monitoreo continuo y procedimientos seguros de finalización de contrato.

El alcance ampliado para datos e IA

En el contexto de los datos y la IA, la definición de "tercero" se extiende mucho más allá de los proveedores tradicionales de software como servicio (SaaS). Ahora incluye a intermediarios de datos que suministran conjuntos de datos de entrenamiento externos, proveedores de infraestructura en la nube que alojan API de modelos fundacionales y consultores de ingeniería externos que procesan datos confidenciales para ajustar algoritmos. Cada una de estas entidades externas amplía su superficie de ataque y su huella de cumplimiento.

El ciclo de vida tradicional del TPRM

El ciclo de vida tradicional del proveedor sigue una ruta altamente lineal. Comienza con la selección del proveedor y la clasificación de riesgos, pasa a la integración técnica y la evaluación de seguridad, requiere un monitoreo anual periódico y concluye con la rescisión del contrato y la eliminación de datos.

Los objetivos principales de este ciclo de vida tradicional están bien establecidos. Los equipos buscan garantizar el cumplimiento normativo, como cumplir con los requisitos del Artículo 28 del RGPD para los encargados del tratamiento de datos, mantener estándares estrictos de seguridad de datos y garantizar la continuidad del negocio. Históricamente, evaluar los certificados de seguridad de un proveedor y firmar un acuerdo estándar de procesamiento de datos era suficiente para alcanzar estos objetivos.

Por qué el TPRM tradicional falla con los sistemas de IA

El TPRM tradicional falla con los sistemas de IA porque evalúa software estático en un momento puntual, mientras que los modelos de IA son sistemas dinámicos y ávidos de datos que cambian su comportamiento según las entradas continuas.

Software estático frente a sistemas de aprendizaje dinámico

Las evaluaciones tradicionales de terceros evalúan la postura de seguridad y cumplimiento de un proveedor en el momento de la adquisición, lo cual es fundamentalmente incompatible con el funcionamiento de los algoritmos de aprendizaje automático.

Lógica del sistema

• Software estático, como el almacenamiento en la nube: Lógica fundamental fija a menos que el proveedor lance una actualización importante.
• Sistemas de IA dinámicos: Inherentemente dinámico, adaptándose constantemente a medida que los algoritmos procesan datos en tiempo real.

Riesgos de rendimiento

• Software estático: Funcionalidad estable y resultados operativos predecibles.
• Sistemas de IA dinámicos: Susceptibles a la deriva del modelo, la degradación de la precisión y resultados sesgados con el paso del tiempo.

Necesidad de evaluación

• Software estático: Revisiones anuales de cumplimiento y comprobaciones de adquisición estáticas.
• Sistemas de IA dinámicos: Monitoreo continuo del rendimiento del modelo y la seguridad de los resultados.

Un modelo que supera una evaluación de adquisición inicial podría comenzar a generar resultados inexactos o sesgados seis meses después, lo que exige un enfoque totalmente nuevo para la validación continua.

Riesgos de modelos de IA y datos

Los sistemas de IA externos introducen riesgos que los marcos de seguridad estándar no pueden medir. El más destacado es el problema de la "caja negra", donde los proveedores externos ofrecen una transparencia limitada sobre cómo su modelo pondera las entradas o genera resultados específicos.

Los riesgos de privacidad de datos y sesgo también se ven amplificados. Si los datos de entrenamiento de un proveedor contienen sesgos demográficos inherentes o violan los derechos de privacidad, esas responsabilidades pueden transferirse directamente a sus procesos operativos. Además, los sistemas de IA enfrentan amenazas de seguridad únicas que los firewalls tradicionales no pueden bloquear, como ataques adversarios diseñados para engañar al algoritmo, técnicas de inversión de modelos que extraen los datos de entrenamiento subyacentes y el envenenamiento intencional de datos.

Obligaciones legales y de cumplimiento cambiantes

El panorama regulatorio impone obligaciones estrictas y directas a las organizaciones que implementan IA, no solo a los proveedores que la desarrollan. Bajo marcos como la Ley de IA de la UE, la implementación de un sistema de IA de alto riesgo conlleva evaluaciones de conformidad obligatorias, requisitos de supervisión humana y deberes de monitoreo continuo. No es posible delegar estas obligaciones del implementador mediante contrato.

Seguridad

• Enfoque tradicional de TPRM: Revisión de informes SOC 2, ISO 27001 y pruebas de penetración estándar.
• Desafío específico de la IA: Evaluación de la resiliencia algorítmica y la vulnerabilidad ante ataques de inyección de prompts.

Rendimiento

• Enfoque tradicional de TPRM: Verificación de los SLA básicos de tiempo de actividad y planes de continuidad del negocio.
• Desafío específico de la IA: Supervisión de la deriva del modelo, la degradación de la precisión y las alucinaciones en los resultados.

Cumplimiento

• Enfoque tradicional de TPRM: Firma de acuerdos de procesamiento de datos según el artículo 28 del RGPD.
• Desafío específico de la IA: Evaluación de la procedencia de los datos de entrenamiento, el cumplimiento de los derechos de autor y las obligaciones de los implementadores según la Ley de IA.

Un ciclo de vida práctico para gestionar el riesgo de IA de terceros

La gestión del riesgo de IA de terceros requiere un ciclo de vida de cuatro fases que adapte los flujos de trabajo de adquisición estándar para evaluar continuamente la procedencia de los datos, la equidad algorítmica y el rendimiento del modelo.

Fase 1: Descubrimiento y clasificación de riesgos

No se puede gobernar lo que no se puede ver. El primer paso es establecer un inventario exhaustivo de todos los sistemas de IA en uso en toda su organización. Esto debe tener en cuenta activamente la "IA en la sombra", donde los equipos comerciales adquieren herramientas de IA generativa con tarjetas de crédito corporativas sin una supervisión de seguridad centralizada.

Una vez identificados, debe evaluar y clasificar a los proveedores según el riesgo inherente. Un marco práctico clasifica a los proveedores evaluando la sensibilidad de los datos que procesan, el impacto operativo si el algoritmo falla y su alcance normativo. Por ejemplo, una herramienta de IA que filtra solicitudes de empleo entra en las categorías de alto riesgo de la Ley de IA de la UE y requiere un escrutinio de nivel uno, mientras que una herramienta interna de resumen de IA para comunicaciones de prensa públicas representa un nivel de riesgo significativamente menor.

Fase 2: Debida diligencia y evaluación

Los cuestionarios de seguridad estándar, como las listas de verificación de Recopilación de Información Estandarizada (SIG) o la Iniciativa de Evaluación de Consenso (CAIQ) de Cloud Security Alliance, son insuficientes para la IA. Debe profundizar en las prácticas específicas de ingeniería de aprendizaje automático del proveedor.

Las áreas clave a evaluar incluyen la gobernanza de datos, específicamente cómo el proveedor obtuvo sus datos de entrenamiento y si gestionan el consentimiento de manera efectiva. También debe evaluar las prácticas de desarrollo de modelos, solicitando evidencia explícita de pruebas de equidad y estrategias de mitigación de sesgos. Solicite acceso a tarjetas de modelo, hojas de datos y resultados de pruebas algorítmicas independientes. Si un proveedor se niega a proporcionar documentación sobre la precisión, confiabilidad y arquitectura de seguridad de su modelo, representa un riesgo de cumplimiento crítico.

Fase 3: Contratación y cláusulas clave

Los contratos comerciales deben actualizarse para reflejar las dependencias específicas de la IA. Los límites de responsabilidad estándar a menudo no tienen en cuenta las multas regulatorias y los daños a la reputación únicos que puede causar un fallo en la toma de decisiones automatizada.

Asegúrese de que sus contratos aborden la responsabilidad por resultados sesgados, ofensivos o inexactos. Es fundamental definir explícitamente los derechos de uso de los datos. Debe documentar si el proveedor tiene permiso para utilizar sus datos corporativos o las entradas de sus clientes para entrenar y ajustar sus futuros modelos. Además, establezca derechos estrictos de auditoría y prueba, junto con requisitos de notificación obligatorios que estipulen que el proveedor le alertará inmediatamente sobre actualizaciones importantes del modelo, degradación del rendimiento o brechas de seguridad.

Fase 4: Monitoreo y respuesta ante incidentes

La aprobación de un proveedor de IA no es un evento único; marca el comienzo de un proceso de supervisión continua. Debido a que los algoritmos se degradan y los datos de entrada cambian, su marco de gobernanza debe aplicar una revisión constante.

Monitoree el sistema para detectar desviaciones en el rendimiento, cambios inexplicables en los resultados de los datos y vulnerabilidades recién descubiertas en los modelos base subyacentes. Además, debe desarrollar un plan de respuesta ante incidentes específico para la IA. Si un algoritmo de terceros comienza repentinamente a tomar decisiones automatizadas sesgadas que afectan a sus clientes, sus equipos de privacidad e ingeniería necesitan un manual operativo predefinido para pausar el servicio, mitigar el daño e informar del incidente a las autoridades pertinentes.

Cómo gestionar el riesgo de terceros indirectos en su cadena de suministro de IA

La gestión del riesgo de IA de terceros indirectos requiere mapear las dependencias ocultas dentro de su pila tecnológica para identificar qué modelos base y proveedores de nube impulsan a sus proveedores directos.

Visualización de su cadena de suministro de IA

El riesgo de terceros indirectos es el riesgo que plantean los proveedores de sus proveedores. En el software tradicional, esto suele implicar que un proveedor de SaaS dependa de un proveedor de infraestructura en la nube específico. En el ecosistema de la IA, estas cadenas de suministro son significativamente más complejas, opacas y estratificadas.

Considere un ejemplo concreto y muy común. Su equipo de privacidad aprueba una nueva aplicación de marketing basada en IA, que es su tercero directo. Sin embargo, esa herramienta de marketing no crea sus propios modelos de aprendizaje automático; opera utilizando la API GPT-4 de OpenAI, lo que convierte a OpenAI en su cuarto nivel. OpenAI, a su vez, ejecuta su infraestructura en Microsoft Azure, su quinto nivel. Una brecha de seguridad, una interrupción del servicio o un fallo de cumplimiento en cualquier punto de esta cadena afecta directamente a su resiliencia operativa y a la seguridad de sus datos.

Estrategias para la visibilidad de terceros indirectos

Obtener visibilidad sobre esta compleja cadena de suministro debe comenzar durante la fase de adquisición. Debe introducir requisitos contractuales estrictos que exijan transparencia a sus proveedores directos con respecto a sus dependencias críticas de IA. Si un proveedor no puede o no quiere revelar qué modelo base impulsa las funciones principales de su producto, usted no podrá evaluar el riesgo derivado.

Utilice fuentes de datos especializadas y herramientas de análisis de composición de software para mapear activamente estas cadenas de suministro. Centre sus esfuerzos de monitoreo en identificar el riesgo de concentración. Es posible que descubra que diez herramientas de terceros críticas diferentes en toda su organización dependen secretamente del mismo modelo base. Si ese modelo específico sufre un ataque adversario, alucina gravemente o se enfrenta a una prohibición regulatoria, su organización se enfrentará a un fallo en cascada grave.

Mapear estas dependencias externas con precisión es un paso fundamental para construir un inventario completo de IA.

Errores comunes y conceptos erróneos en la evaluación de proveedores de IA

El concepto erróneo más frecuente en la evaluación de proveedores de IA es tratar los algoritmos como aplicaciones de software estándar, lo que hace que los equipos de privacidad pasen por alto los flujos de datos y los mecanismos de supervisión humana.

Aceptar la opacidad "propietaria"

Los proveedores suelen citar secretos comerciales o tecnología propietaria cuando se niegan a explicar cómo funcionan sus modelos. Si bien la protección de la propiedad intelectual es una preocupación comercial válida, los proveedores deben proporcionar suficiente transparencia para que usted pueda realizar una evaluación de riesgos significativa. Rechace la opacidad absoluta; solicite tarjetas de modelo, resúmenes de auditorías independientes o resultados de pruebas agregados que demuestren la seguridad y equidad del sistema sin exponer el código fuente subyacente.

Uso de cuestionarios de seguridad genéricos

Enviar una hoja de cálculo de seguridad de la información estándar a un proveedor de IA evaluará correctamente su cifrado de red, pero pasará por alto por completo los riesgos algorítmicos. Las listas de verificación de seguridad de la información estándar no preguntan cómo evalúa un proveedor el sesgo del modelo, la equidad demográfica o la explicabilidad. Debe implementar cuestionarios especializados y específicos para IA para estas evaluaciones.

Ignorar el flujo de datos

Muchos equipos se centran exclusivamente en la sofisticación matemática del algoritmo mientras ignoran por completo los datos que lo alimentan. Los riesgos operativos y de privacidad más graves suelen originarse en los datos utilizados para entrenar y ajustar el modelo. Haga hincapié en una diligencia debida exhaustiva sobre las prácticas de gobernanza de datos del proveedor, asegurándose de que hayan establecido una base legal clara para procesar los datos de entrenamiento originales.

Pasar por alto la supervisión humana

Los controles de seguridad técnica y la arquitectura del sistema de un proveedor son solo una parte de la ecuación de riesgo. Sus procesos operativos para la revisión humana y la intervención manual son mitigadores de riesgo críticos. No evaluar exactamente cómo y cuándo los operadores humanos pueden anular las decisiones automatizadas deja a su organización altamente vulnerable a alucinaciones de IA no controladas o errores algorítmicos en cascada.

Desarrollar una capacidad madura de TPRM para IA

Desarrollar una capacidad madura de gestión de riesgos de terceros (TPRM) para IA implica capacitar a equipos interfuncionales, establecer un consejo de gobernanza central y desplegar plataformas automatizadas para monitorear el riesgo de los proveedores a escala.

Capacitar a equipos interfuncionales

Una gobernanza de IA eficaz es un esfuerzo interdisciplinario. Sus funciones principales requieren nuevas habilidades especializadas para evaluar a los proveedores de IA con precisión. Los equipos legales deben comprender las responsabilidades específicas de la IA, las complejas implicaciones de los derechos de autor y los matices precisos de la Ley de IA. Los equipos de adquisiciones necesitan criterios de evaluación actualizados para cuestionar a los proveedores sobre los SLA de deriva del modelo y los derechos sobre los datos de entrenamiento. Mientras tanto, los equipos de riesgo y seguridad deben capacitarse para comprender la validación de modelos, las vulnerabilidades de inyección de prompts y las metodologías de prueba de sesgo algorítmico.

Establecer un consejo de gobernanza de IA

La toma de decisiones aislada conduce a una gestión de riesgos fragmentada y a puntos ciegos en el cumplimiento. Recomendamos establecer un consejo de gobernanza de IA centralizado e interfuncional para revisar y aprobar a todos los proveedores de IA de alto riesgo. Este consejo debe incluir representantes de privacidad, seguridad, legal, ingeniería y unidades de negocio clave. Al actuar como un órgano asesor y de aprobación, el consejo garantiza que las herramientas de IA se evalúen desde todos los ángulos regulatorios y operativos antes de que se implementen en producción.

Aprovechar la automatización y las herramientas

Depender de hojas de cálculo manuales para gestionar los riesgos dinámicos de la IA es, en última instancia, insostenible. A medida que crece su cadena de suministro de IA, necesita plataformas dedicadas que proporcionen visibilidad en tiempo real del riesgo de los proveedores. Las herramientas modernas pueden automatizar los flujos de trabajo de evaluación de proveedores, mantener inventarios de IA dinámicos y proporcionar un monitoreo de seguridad continuo para dependencias complejas de terceros.

El uso de plataformas como TrustWorks le permite centralizar estas evaluaciones, conectar las herramientas que ya utiliza y gestionar el riesgo de proveedores externos sin problemas, sin necesidad de tickets de ingeniería.

Preguntas frecuentes

La gestión del riesgo de IA de terceros plantea con frecuencia preguntas sobre evaluaciones de impacto, métricas de contrato, responsabilidades de código abierto y escalabilidad de la supervisión de proveedores.

¿Cuál es la diferencia entre una EIPD y una evaluación de impacto de IA para una herramienta de terceros?

La diferencia entre una Evaluación de Impacto de la Protección de Datos (EIPD) y una evaluación de impacto de IA para una herramienta de terceros radica en su alcance. Una EIPD se centra específicamente en mitigar los riesgos de datos personales según el Artículo 35 del RGPD. Por el contrario, una evaluación de impacto de IA evalúa cuestiones más amplias como la equidad algorítmica, la seguridad física y el impacto social según la Ley de IA de la UE.

¿Cómo incluyo métricas de rendimiento de IA en un contrato con un proveedor?

Para incluir métricas de rendimiento de IA en un contrato con un proveedor, debe definir Acuerdos de Nivel de Servicio (SLA) altamente medibles y adaptados al aprendizaje automático. Incluya umbrales estrictos para la precisión del modelo, la latencia de salida y los límites aceptables de deriva del modelo. Además, describa claramente los recursos financieros, los requisitos de reentrenamiento obligatorio o los derechos de rescisión inmediata si las métricas se degradan.

¿Debo realizar una gestión de riesgos de terceros (TPRM) de IA para modelos de código abierto?

Es necesario realizar una gestión de riesgos de terceros (TPRM) de IA para modelos de código abierto, ya que presentan riesgos operativos significativos. Estos sistemas introducen sesgos integrados, vulnerabilidades de seguridad y problemas complejos de licencias comerciales. El riesgo suele ser mayor debido a la falta de soporte comercial, y la Ley de IA de la UE aplica explícitamente obligaciones regulatorias a ciertos proveedores de IA de código abierto según su contexto de implementación específico.

Nuestro proveedor dice que su IA no es de "alto riesgo" según la Ley de IA de la UE. ¿Aun así debemos evaluarla?

Debe evaluar una herramienta de IA incluso si su proveedor afirma que no es de "alto riesgo" según la Ley de IA de la UE. La clasificación regulatoria es solo una perspectiva de evaluación. Una herramienta de IA no clasificada aún podría procesar datos confidenciales de manera inadecuada, generar resultados sesgados que causen graves daños a la reputación o introducir vulnerabilidades operativas importantes que requieran una revisión documentada.

¿Cómo puede un equipo de privacidad pequeño gestionar la escala del riesgo de los proveedores de IA?

Un equipo de privacidad pequeño puede gestionar la escala del riesgo de los proveedores de IA adoptando un enfoque estricto basado en el riesgo. Centre sus evaluaciones manuales y exhaustivas únicamente en los proveedores de mayor riesgo que procesen datos confidenciales o afecten a operaciones críticas. Para las herramientas de bajo riesgo, escale su supervisión de manera eficiente utilizando flujos de trabajo de evaluación automatizados, revisiones más ligeras y listas de verificación de autoservicio.

Conclusión

La naturaleza dinámica del aprendizaje automático hace que la gestión de riesgos de terceros (TPRM) tradicional sea totalmente insuficiente para gestionar los complejos riesgos de la inteligencia artificial. Un enfoque estructurado basado en el ciclo de vida, que abarque una diligencia debida rigurosa, controles contractuales actualizados y un seguimiento continuo, es esencial para una gobernanza eficaz de la IA. Además, obtener una visibilidad clara de su compleja cadena de suministro de IA para gestionar el riesgo de terceros (Nth-party risk) ya no es un ejercicio opcional; es un requisito de seguridad fundamental.

A medida que la inteligencia artificial se integra más profundamente en las operaciones comerciales diarias, desarrollar una capacidad de gestión de riesgos de terceros (TPRM) de IA madura y automatizada será un facilitador crítico para una innovación responsable y sostenible.

Si su plataforma actual tarda meses en configurarse y sigue necesitando hojas de cálculo para cubrir las brechas, descubra cómo TrustWorks le ayuda a automatizar las evaluaciones de proveedores de IA y a construir un programa de privacidad resiliente.

‍