IA en SaaS y cloud: quién asume el riesgo según los contratos

Las empresas usan cada vez más la inteligencia artificial generativa como servicio: una suscripción a ChatGPT, las funciones de Copilot dentro de Microsoft 365, una API integrada en una aplicación interna. Un análisis jurídico publicado por ICT Security Magazine el 11 de octubre de 2026 estudia cómo se encajan estos servicios en los contratos SaaS y cloud ya existentes y cómo los términos de los proveedores reparten el riesgo entre quien ofrece el servicio y quien lo usa. En ARX News hablamos del AI Act desde el lado de los proveedores de modelos, a propósito de las obligaciones de notificación de incidentes; esta vez el punto de vista es el del cliente.

Este artículo se basa en una sola fuente, un análisis jurídico y no un aviso técnico. El texto que hemos podido consultar trata a fondo los términos de ChatGPT y se interrumpe en la parte sobre Microsoft Copilot: de los demás servicios citados, como Google Gemini, no damos detalles.

El contexto: normas europeas y contratos de adhesión

Según ICT Security Magazine, el marco europeo sobre la IA se centra en la prevención del riesgo, la gobernanza y el reparto previo de obligaciones entre los actores de la cadena, pero deja abiertas varias cuestiones prácticas, en las que decide el contrato. Los modelos generativos no se compran: el cliente obtiene un derecho de uso limitado en el tiempo y en las modalidades, mientras que el modelo y la infraestructura siguen siendo del proveedor (el paradigma AI-as-a-Service, una forma de SaaS).

El autor señala que estos contratos suelen ser estándar, redactados por operadores extranjeros y en la práctica no negociables, con efectos sobre riesgos, responsabilidad, datos y propiedad intelectual. La alternativa, un sistema desarrollado a medida con datasets elegidos por el cliente, da más control (acceso al código fuente y a los algoritmos, posibilidad de recurrir a otros desarrolladores), pero cuesta más y está menos extendida.

Qué prevén los términos: el caso ChatGPT

Del análisis de los términos de OpenAI que recoge la fuente surgen varios puntos que interesan directamente a quien gestiona TI y seguridad:

• Documentos que hay que leer juntos: términos de uso, condiciones de los planes de pago (Plus, Team, Enterprise), política de privacidad y, para las empresas, el Data Processing Addendum (DPA).
• Datos de entrada y de salida: el usuario conserva la titularidad de los inputs y recibe los derechos sobre los outputs dentro de los límites de la ley, sin garantía de originalidad. En los planes para consumidores, los contenidos pueden usarse para entrenar los modelos salvo opt-out; en los planes enterprise, según la fuente, normalmente no.
• Servicio “as is” y “as available”: ninguna garantía sobre exactitud, fiabilidad, continuidad o idoneidad para un fin. El usuario es responsable de las decisiones tomadas a partir de los outputs y debe verificarlos.
• Responsabilidad limitada: un tope de indemnización ligado a lo pagado en un periodo (por ejemplo, los últimos doce meses) o a un umbral fijo, y exclusión de los daños indirectos, incluidos pérdida de datos, lucro cesante y daños reputacionales.
• Indemnidad a cargo del usuario por los usos ilícitos; en los contratos business puede haber protecciones para el cliente, por ejemplo sobre propiedad intelectual, dentro de límites concretos.
• Usos prohibidos: ingeniería inversa y extracción del modelo, desarrollo de sistemas competidores con los outputs, uso en ámbitos de alto riesgo sin supervisión humana. El incumplimiento puede llevar a la suspensión de la cuenta.
• Cambios unilaterales: el proveedor puede modificar, suspender o interrumpir el servicio y actualizar las condiciones con preaviso.

En los planes enterprise y en los contratos negociados, siempre según la fuente, aparecen SLA con garantías de disponibilidad y service credits, topes de responsabilidad más altos y cláusulas más detalladas sobre seguridad y protección de datos. Con el DPA, el cliente es responsable del tratamiento de los datos que introduce y el proveedor actúa como encargado. La conclusión del autor: el régimen de responsabilidad no es uniforme, sino que depende del poder contractual del cliente.

La cadena de suministro: el caso Copilot

En el caso de Microsoft, la fuente describe un ecosistema más estratificado: Copilot gratuito en Windows, Edge y Bing, Copilot Pro, Copilot for Microsoft 365 en las aplicaciones de oficina y en Teams, GitHub Copilot para el código y Copilot Studio para crear agentes. Los modelos los desarrolla OpenAI y se licencian a Microsoft, que los ofrece desde su propia infraestructura Azure: cuando un usuario utiliza Copilot en Word o Excel, el prompt llega a los servidores de Microsoft, que eligen qué modelo usar.

Para quien evalúa el riesgo de terceros, esto significa que detrás de un solo contrato hay una cadena de proveedores. El texto disponible se detiene en este punto.

Impacto para las empresas europeas e italianas

El análisis es jurídico, pero las consecuencias son operativas. Un servicio de IA que trata documentos, código o datos de clientes es un proveedor TIC a todos los efectos. Para las entidades NIS2 (en Italia, el Decreto Legislativo 138/2024), la seguridad de la cadena de suministro forma parte de las medidas de gestión del riesgo: unos términos “as is” con topes de responsabilidad bajos y sin SLA deben tratarse como un riesgo residual que hay que evaluar, no como un detalle legal. Donde hay datos personales, el DPA y las transferencias a terceros países son materia del RGPD; en el sector sanitario, los datos de salud introducidos en un prompt son categorías especiales de datos.

El punto más concreto es la diferencia entre planes: el mismo servicio puede tener reglas opuestas sobre el uso de los datos para el entrenamiento, según el empleado use una cuenta personal o la de la empresa.

Qué hacer ya

1. Inventario: enumera los servicios de IA en uso, incluidas las funciones activadas dentro de plataformas ya contratadas (suites ofimáticas, entornos de desarrollo), y el tipo de plan de cada uno.
2. Cuentas personales: define qué servicios están autorizados y con qué cuentas; donde sea posible, permite el acceso solo con la identidad corporativa (SSO) y limita los demás desde el proxy.
3. Datos y entrenamiento: comprueba en el contrato y en la consola de administración si los inputs y outputs pueden usarse para el entrenamiento, y documenta la configuración elegida.
4. DPA y subencargados: revisa roles, medidas de seguridad, lista de subencargados, lugar del tratamiento y transferencias fuera del Espacio Económico Europeo.
5. Riesgo contractual: compara el tope de responsabilidad, los SLA y los service credits con lo críticos que son los procesos que dependen del servicio; para los críticos, negocia otras condiciones o prevé una alternativa.
6. Revisión humana de los outputs: el contrato la pone a tu cargo. Conviértela en una regla escrita para las decisiones relevantes, el código generado y los textos dirigidos a clientes.
7. Cambios en los términos: encarga a alguien el seguimiento de las comunicaciones de los proveedores y vuelve a evaluar el riesgo cuando cambien las condiciones o los modelos.
8. Salida: comprueba cómo se recuperan y se borran los datos al terminar el contrato.

Cómo ayuda ARXDOME

Si los términos ponen a cargo del cliente el uso del servicio y las decisiones tomadas con sus outputs, necesitas pruebas de lo que ha ocurrido. ARX Sentry reúne en un solo lugar los logs de servidores y firewalls, y ARX Retain los conserva durante los años necesarios, en almacenamiento europeo con bloqueo de objetos y legal hold, listos para una auditoría o una reclamación al proveedor.

Última actualización: 11 de octubre de 2026