Jefe de estudios del área de Derecho Facultad Business & Tech A medida que las empresas incorporan sistemas de Inteligencia Artificial -en adelante, IA- a sus procesos, una parte importante del riesgo ya no nace dentro de la organización. En muchas ocasiones, la tecnología llega a través de un proveedor: una herramienta contratada como servicio, una funcionalidad añadida a una plataforma que ya se utilizaba o un modelo integrado en una solución de negocio. Esto modifica el problema, pero no lo elimina. La empresa puede externalizar el desarrollo o la prestación tecnológica, pero no puede externalizar sin más los riesgos derivados de su utilización. Por eso, la gobernanza de proveedores de IA no debería comenzar cuando se firma el contrato. Debería empezar antes, con una pregunta básica: ¿sabemos realmente qué estamos comprando y qué consecuencias puede tener su uso?
María Luisa García Torres. Dra. en Derecho Procesal
El proveedor también forma parte de la gobernanza
Una organización puede disponer de inventario, matriz de responsabilidades, AI Officer, comité de IA y políticas internas perfectamente definidas. Pero ese modelo será incompleto si no alcanza también a los terceros que suministran o modifican la tecnología.
El Reglamento (UE) 2024/1689 -en adelante, RIA- parte de una cadena de valor en la que intervienen distintos operadores. Su art. 25 regula responsabilidades a lo largo de esa cadena y, en su apartado 4, exige, en determinados supuestos relativos a sistemas de alto riesgo, acuerdos escritos entre el proveedor y terceros que suministran sistemas, herramientas, servicios, componentes o procesos necesarios para que pueda cumplir sus obligaciones.
No toda relación entre una empresa y un proveedor de IA queda sometida a ese precepto en los mismos términos. La relevancia contractual es más amplia: el contrato debe hacer operativa la distribución de responsabilidades necesaria para utilizar la tecnología de forma controlada.
Aunque las obligaciones del RIA relativas a los sistemas de alto riesgo están sometidas a un calendario gradual de aplicación, su futura exigibilidad obliga a revisar desde ahora los procesos de contratación: los contratos celebrados hoy pueden seguir desplegando efectos cuando esas obligaciones resulten plenamente aplicables.
La due diligence empieza antes de contratar
El primer error consiste en tratar la adquisición de IA como una compra tecnológica ordinaria. Antes de contratar deberían conocerse la finalidad del sistema, sus funcionalidades, grado de autonomía, datos necesarios, integraciones previstas, riesgos relevantes, medidas de seguridad, documentación disponible y capacidad del proveedor para responder cuando el sistema cambie o falle.
La contratación debería regular expresamente el tratamiento de los datos de entrada -inputs- y de las salidas -outputs-, así como impedir, salvo autorización expresa, que el proveedor o sus subproveedores utilicen información confidencial, datos corporativos o contenidos aportados por la empresa para entrenar, reentrenar o mejorar modelos de propósito general.
También importa determinar qué posición ocupará cada parte a efectos del RIA. No es lo mismo utilizar una herramienta conforme a las instrucciones del proveedor que modificar sustancialmente un sistema, cambiar su finalidad prevista o comercializarlo bajo la propia marca. En determinados supuestos, el art. 25 puede hacer que un distribuidor, importador, responsable del despliegue u otro tercero pase a ser considerado proveedor de un sistema de alto riesgo y asuma las obligaciones correspondientes.
El contrato no puede limitarse al precio y al nivel de servicio
En muchas organizaciones, el contrato tecnológico se concentra en disponibilidad, soporte, niveles de servicio y responsabilidad económica. Con la IA puede resultar insuficiente. La disponibilidad técnica no garantiza por sí sola la calidad de los resultados. Cuando resulte pertinente, el contrato puede incorporar métricas de rendimiento, umbrales de error, controles de deriva del modelo, pruebas tras actualizaciones y criterios para detectar degradaciones relevantes de su comportamiento.
La empresa necesita saber qué documentación recibirá, qué instrucciones existirán, qué registros genera el sistema, quién puede acceder a ellos, cuánto tiempo se conservan, cómo se gestionan los incidentes, qué cambios puede introducir el proveedor y qué información deberá facilitar cuando esos cambios alteren el riesgo inicialmente evaluado.
En los sistemas de alto riesgo esta cuestión adquiere especial importancia. El art. 12 RIA exige que permitan técnicamente el registro automático de acontecimientos -logs-, mientras que los arts. 19 y 26.6 establecen obligaciones de conservación para proveedores y responsables del despliegue, respectivamente. Además, el art. 26.5 obliga a estos últimos a vigilar el funcionamiento del sistema y, ante determinadas situaciones de riesgo, informar al proveedor o distribuidor y a la autoridad de vigilancia del mercado, así como suspender su utilización cuando concurran los presupuestos previstos en el propio precepto.
Si la empresa depende del proveedor para acceder a información necesaria para cumplir sus obligaciones, un derecho no previsto contractualmente puede convertirse después en una obligación difícil de ejecutar.
El cambio del modelo también debe gobernarse
Los modelos cambian. Se actualizan funcionalidades, capacidades, fuentes de datos, medidas de seguridad, condiciones de uso o proveedores subyacentes. En sistemas generativos, una actualización puede modificar de forma relevante su comportamiento sin que la empresa haya cambiado formalmente de producto.
Por ello, el contrato debería diferenciar entre actualizaciones ordinarias y cambios capaces de alterar el riesgo previamente aceptado. Ante una modificación sustancial, una nueva finalidad o una variación relevante de las capacidades, la organización debe poder reevaluar el sistema antes de continuar utilizándolo.
La gobernanza no puede consistir en aprobar una herramienta una vez y considerar que esa aprobación permanece válida indefinidamente.
Subproveedores: el riesgo que no se ve
La cadena contractual puede incorporar terceros que la empresa ni siquiera ha elegido directamente. Un proveedor puede apoyarse en modelos de propósito general, servicios cloud, APIs, proveedores de seguridad u otras infraestructuras.
No se trata necesariamente de prohibir subproveedores, sino de gobernarlos. Su incorporación o sustitución puede afectar a seguridad, protección de datos, continuidad, localización de información, propiedad intelectual o capacidad de auditoría. Cuanto más compleja sea la cadena, más difícil puede resultar determinar dónde se produjo un fallo y quién dispone de la evidencia necesaria para reconstruirlo.
Logs, evidencias y derecho de auditoría
La trazabilidad no puede aparecer por primera vez cuando surge un incidente o un litigio.
Si el sistema adopta o condiciona decisiones relevantes, la empresa necesita conocer de antemano qué evidencia podrá conservar sobre su funcionamiento. En los sistemas de alto riesgo, el RIA conecta expresamente los logs con la trazabilidad, la monitorización y la identificación de situaciones de riesgo.
El contrato debe traducir esa capacidad técnica en una posibilidad real de acceso. No siempre será necesario un derecho de auditoría ilimitado, pero sí mecanismos proporcionados: acceso a documentación, evidencias de controles, informes de auditoría independientes, información sobre incidentes o posibilidades de verificación ante riesgos relevantes.
Incidentes: quién llama a quién y cuándo
Cuando un sistema falla, el tiempo importa. El art. 26.5 RIA obliga a los responsables del despliegue de sistemas de alto riesgo a vigilar su funcionamiento y, ante determinadas situaciones de riesgo, informar y, cuando proceda, suspender su utilización. Por su parte, el art. 73 establece las obligaciones de los proveedores en materia de notificación de incidentes graves.
En determinados sistemas de alto riesgo, esta capacidad de reacción debe conectarse además con los mecanismos de supervisión humana del art. 14 RIA, incluida, cuando proceda, la posibilidad de intervenir o detener el sistema mediante un botón de parada o procedimiento equivalente que permita llevarlo a un estado seguro.
El contrato debería anticipar ese escenario: quién informa a quién, en qué plazo, quién preserva los registros, quién investiga, qué medidas de contención pueden adoptarse y cómo se coordina la relación con autoridades o terceros afectados.
También hay que gobernar la salida
La dependencia de un proveedor también aparece cuando la empresa quiere terminar la relación. ¿Qué ocurre con los datos? ¿Pueden exportarse los registros? ¿Existe documentación suficiente para migrar a otra solución? ¿Qué sucede con configuraciones, prompts, flujos, evidencias o integraciones desarrolladas durante años?
La estrategia de salida debería formar parte de la gobernanza desde el inicio. Un sistema técnicamente excelente puede generar un riesgo empresarial considerable si abandonar al proveedor resulta prácticamente imposible.
Comprar IA no significa transferir la responsabilidad
La gobernanza de proveedores exige conectar Compras, Tecnología, Jurídico, Compliance, el delegado de protección de datos -DPO-, el responsable de seguridad de la información -CISO-, el propietario funcional y, cuando proceda, el AI Officer, el comité de IA y la alta dirección.
Compras puede negociar el contrato, pero no determinar por sí sola qué riesgo es aceptable. Tecnología puede evaluar la integración, pero no asumir las cuestiones jurídicas. DPO, CISO y Compliance conservan sus competencias. El propietario de negocio sigue respondiendo por la finalidad y utilización del sistema y el AI Officer facilita la coordinación. El comité interviene cuando la relevancia, transversalidad o riesgo justifican el escalado; la alta dirección, cuando la contratación supera los límites de riesgo establecidos, genera una dependencia estratégica o exige una aceptación extraordinaria del riesgo.
La cuestión central no es si el proveedor es fiable en abstracto, sino si la empresa dispone de información, derechos contractuales y mecanismos internos suficientes para gobernar esa dependencia.
La IA puede entrar en la organización a través de un contrato. El riesgo también. Y ahí aparece la verdadera pregunta: cuando el sistema cambie, falle o sea cuestionado, ¿tendrá la empresa capacidad real para comprender qué ocurrió, exigir información, tomar decisiones y responder por el uso que hizo de esa tecnología?