Cláusulas de confidencialidad que exigir a un proveedor de plataforma de IA

Un NDA estándar está diseñado para un destinatario humano; una plataforma de IA ingiere documentos, retiene prompts, genera resultados derivados y puede entrenar con lo que se le suministra. Cinco cláusulas cierran la brecha: una garantía de no entrenamiento con derecho de auditoría, subencargados nombrados y residencia de datos, eliminación al finalizar el contrato con certificado, registro de la versión del modelo y un alcance de incidentes que cubra los modos de fallo específicos de la IA.

Cláusulas de confidencialidad que exigir a un proveedor de plataforma de IA

Imagen: Decisity

Conclusiones clave

  • Optar por defecto por la no utilización de datos del cliente para el entrenamiento: restringir el uso de datos de entrada, prompts y resultados por parte del proveedor salvo autorización expresa, y adjuntar un derecho de auditoría a la garantía para que sea verificable.
  • Solicitar un certificado de eliminación de una finalización de contrato anterior antes de firmar; un proveedor que no puede presentarlo nunca ha probado su propio proceso de baja.
  • Nombrar a cada subencargado y ubicación de centro de datos en el contrato; en virtud del artículo 28 del RGPD, el encargado necesita su autorización previa y sigue siendo responsable de sus subencargados.[2]
  • Los amplios derechos sobre datos agregados y anonimizados permiten a un proveedor obtener valor de su trabajo indefinidamente; definir y prohibir expresamente en el contrato el uso de valor derivado.
  • Confirmar quién es propietario de los resultados del análisis y en qué formato se exportan antes de firmar; las condiciones de salida determinan si puede marcharse en la práctica.

La respuesta breve: cinco cláusulas que un NDA estándar no contempla

Un NDA estándar asume un destinatario humano que recibe información, la mantiene confidencial y no la divulga. Una plataforma de estrategia de IA hace algo estructuralmente diferente: ingiere conjuntos completos de documentos, genera nuevo material derivado de ellos, retiene el registro de cada interacción y, en algunas arquitecturas, aprende de lo que se le suministra. Cinco cláusulas cierran la brecha: una garantía de no entrenamiento con derecho de auditoría; subencargados nombrados y residencia de datos; eliminación al finalizar el contrato con certificado; registro de la versión del modelo; y un ámbito de notificación de incidentes que cubra los modos de fallo específicos de la IA.

Nada de lo que se recoge en este artículo constituye redacción legal ni sustituye al asesoramiento jurídico en ningún encargo concreto.

Por qué un NDA estándar es insuficiente para las plataformas de IA

Un NDA bilateral está redactado para un destinatario humano. Una plataforma de estrategia de IA ingiere conjuntos completos de documentos, genera nuevo material derivado de ellos, retiene el registro de cada interacción y, en algunas arquitecturas, aprende de lo que se le suministra. Cuatro categorías de información que un NDA convencional no cubre adecuadamente:

  • Datos de entrada: paquetes del consejo, modelos financieros y expedientes de diligencia cargados en la plataforma – mucho más extensos y sensibles que lo que toca un procesador de datos SaaS típico.
  • Resultados generados: nuevo material que produce el sistema, que puede citar, resumir o recombinar contenido confidencial.
  • Prompts: instrucciones que escribe el equipo, que a menudo contienen nombres de clientes, contexto de operaciones e intención estratégica.
  • Metadatos de interacción con el modelo: frecuencia de consultas, duración de sesiones, tiempos de interacción y ubicaciones de usuarios, que pueden mapear flujos de trabajo operativos, plazos de investigación y patrones de inteligencia competitiva.

Dos brechas adicionales merecen atención explícita. Primera: un modelo ajustado con material del cliente puede memorizar y reproducir fragmentos para otro cliente – convirtiendo una brecha de confidencialidad en un evento automatizado y repetible. Segunda: «nunca compartimos sus datos» no es lo mismo que «nunca entrenamos con ellos». Un proveedor puede mantener los documentos en estricta confidencialidad y aun así incorporar lo aprendido en un modelo que luego sirve a sus competidores.

Las definiciones que determinan el resultado

La ambigüedad en los términos definidos se propaga a través de cada disposición operativa. Los cinco términos definidos que más influyen en el resultado:

Término definidoPor qué importa la definición
Datos de entradaDebe cubrir los datos, prompts e instrucciones que proporciona el cliente, no solo los archivos cargados
ResultadosDebe cubrir todo lo que genera el sistema en respuesta a los datos de entrada
Datos del clienteDebe capturar ampliamente todos los datos que proporciona el cliente o que se derivan de su uso, incluidos los prompts
Datos de usoMetadatos sobre cómo interactúa el cliente con el sistema; los proveedores suelen reclamar derechos libres sobre ellos
Datos de entrenamiento o ajusteDebe distinguir los datos utilizados para entrenar el modelo subyacente de los datos utilizados para ajustar una instancia específica del cliente

Tres áreas merecen especial atención en la negociación: los Datos de uso deben elevarse a información confidencial. Los prompts deben tratarse como Datos del cliente en su totalidad. Una prohibición de la ingesta silenciosa de datos previene la expansión encubierta del alcance – donde el proveedor ingiere contenido de las sesiones del cliente para mejorar su servicio sin permiso explícito.

Las cinco cláusulas en las que insistir

Una firma de estrategia que evalúa una plataforma de IA debe insistir en cinco cláusulas que las plantillas estándar de los proveedores habitualmente omiten o debilitan:

  1. Una garantía de no entrenamiento con derecho de auditoría. El valor predeterminado debe ser que los datos del cliente, los prompts, los datos de entrada y los resultados no se utilicen para entrenar ningún modelo. Cualquier excepción requiere consentimiento expreso de adhesión voluntaria más salvaguardas de anonimización. Un derecho de auditoría – tal como espera la ICO en virtud del artículo 28(3)(h) del RGPD[2] – convierte la promesa en algo verificable.
  2. Residencia de datos y lista de subencargados nombrados. Indicar la región donde se almacenan y procesan los datos. Nombrar a cada subencargado y exigir autorización previa para los cambios, tal como exigen los artículos 28(2) y 28(3)(d) del RGPD. La lista de subencargados debe incluir a cualquier proveedor de modelos de base de terceros.
  3. Eliminación al finalizar el contrato, con certificado. Exigir al proveedor que, a elección del cliente, elimine o devuelva todos los datos al final del contrato y proporcione prueba escrita de que la eliminación se ha realizado. Un proveedor que no puede presentar un certificado de eliminación de una finalización de contrato anterior nunca ha probado su propio proceso de baja.
  4. Registro de la versión del modelo. Cada resultado debe ser trazable hasta la versión del modelo que lo produjo, para que el análisis pueda auditarse meses después y puedan detectarse cambios en el comportamiento del modelo. Esta cláusula apoya tanto el registro de responsabilidad como el mapa de afirmación a fuente para el trabajo regulado.
  5. Notificación de incidentes con un alcance de brecha debidamente definido. Las obligaciones de notificación y la asignación de costes deben establecerse expresamente. La definición de incidente de seguridad debe cubrir la inversión del modelo y la extracción de datos a través de los resultados – modos de fallo específicos de la IA – y no solo la intrusión en la red. Comprometerse a notificar en un plazo definido.

Cómo poner a prueba las cláusulas antes de firmar

La disciplina consiste en pedir a cada proveedor un artefacto – un documento o demostración – en lugar de una garantía verbal. Las garantías dadas en una reunión de ventas no son vinculantes; las respuestas escritas archivadas con el contrato sí lo son.

  • Eliminación: solicitar el rastro de evidencia de una baja completada – el registro y el certificado de eliminación – no una descripción del proceso. Un proveedor que no puede presentarlo nunca lo ha probado.
  • Subencargados: pedir la lista completa de subencargados vigentes, incluido cualquier proveedor de modelos de base de terceros y las ubicaciones de los centros de datos de cada uno.
  • Anonimización: indagar sobre la metodología de anonimización y si la reidentificación es técnicamente factible. Un proveedor que no puede responder no debería tener acceso a los documentos de los clientes.
  • Controles de entrenamiento: preguntar si los datos están segregados entre clientes, si el entrenamiento se realiza en modelos compartidos o dedicados, y si los datos de un cliente pueden influir en los resultados de otro.
  • Certificaciones: tratar SOC 2 e ISO 27001 como un punto de partida. Confiar únicamente en las certificaciones, sin las preguntas de diligencia debida anteriores, no es suficiente.[3]

Formule las preguntas por escrito y conserve las respuestas. El registro escrito es también evidencia de que la firma realizó la diligencia debida adecuada si la relación se convierte posteriormente en una fuente de un incidente de confidencialidad.

Condiciones de salida: exportación, titularidad y conservación de registros

La confidencialidad se gana o se pierde en silencio al final de un encargo. Tres disposiciones sobre condiciones de salida previenen el bloqueo y la exposición de datos al finalizar el contrato:

  • Formato de exportación: especificar el formato en que se devuelven los datos del cliente y los resultados del análisis, y si los prompts son recuperables junto a ellos. Si el proveedor no puede producir una exportación de datos en un formato utilizable, la capacidad práctica de marcharse es limitada independientemente del derecho contractual.
  • Titularidad de los resultados: el contrato debe confirmar como mínimo que el cliente dispone de una licencia amplia para utilizar los resultados para cualquier fin empresarial lícito sin restricciones. Cualquier modelo ajustado construido sobre los datos del cliente debe recibir un tratamiento separado y explícito en cuanto a la titularidad y la capacidad del cliente de llevárselo al finalizar el contrato.
  • Conservación de registros: indicar durante cuánto tiempo conserva el proveedor los registros de uso y los registros de interacción tras la finalización del contrato y en qué ciclo de eliminación se purgan.

El mínimo del RGPD: el artículo 28(3)(g) exige que al finalizar un contrato el encargado elimine o devuelva todos los datos personales y elimine las copias existentes, salvo que la ley exija su almacenamiento.[2] La eliminación demorada de las copias de seguridad es aceptable solo cuando los datos se ponen inmediatamente fuera de uso y se eliminan en el siguiente ciclo de eliminación del encargado.

La brecha de los resultados agregados y anonimizados

La mayoría de los cuestionarios de proveedores pasan por alto la cláusula de mejora del servicio. La mayoría de los contratos tecnológicos permiten al proveedor utilizar los datos del cliente para mejorar sus servicios, y los proveedores solicitan cada vez más derechos para extender esto al entrenamiento de modelos de IA. Este tipo de cláusula tiene implicaciones significativamente más amplias que una cláusula de mejora del servicio convencional.

El problema central: la titularidad de los datos no equivale al control de los datos. Aunque una empresa conserve la titularidad de sus datos brutos, amplios derechos sobre los derivados agregados o anonimizados pueden permitir a un proveedor construir modelos que incorporen conocimientos derivados de esos datos indefinidamente – y esos modelos seguirán sirviendo a los otros clientes del proveedor después de que finalice el contrato.

Cuatro aspectos que abordar explícitamente en el contrato:

  1. Definir explícitamente el uso de valor derivado: las referencias, los productos analíticos, las nuevas características y el entrenamiento de modelos deben nombrarse cada uno – no dejarse en una cláusula abierta de «mejorar nuestros servicios».
  2. Prohibir los usos derivados que no se acepten: nombrarlos individualmente en lugar de confiar en una disposición general de confidencialidad.
  3. Restringir cualquier uso permitido a la propia instancia del cliente – no al entrenamiento agregado de toda la base de clientes.
  4. Vincular cualquier uso permitido a la duración del contrato – no a una licencia indefinida que sobreviva a la finalización.

Ejemplo práctico: la lista de verificación precontractual de una firma de estrategia

Este ejemplo es ilustrativo, no un encargo real, y no constituye asesoramiento jurídico. Una firma de estrategia de tamaño medio que evaluaba una plataforma de IA realizó su revisión precontractual en tres pasadas.

  1. Primera pasada, definiciones: confirmó que Datos de entrada, Resultados, Datos del cliente, Datos de uso y Datos de entrenamiento estaban todos definidos, que los prompts figuraban dentro de los Datos del cliente y que la cláusula de mejora del servicio se limitaba a la propia instancia del cliente.
  2. Segunda pasada, las cinco cláusulas: solicitó un compromiso de no entrenamiento por escrito, la lista de subencargados publicada, evidencia de un certificado de eliminación previo, la especificación de registro de la versión del modelo y las condiciones de notificación de incidentes que cubrieran los ataques de extracción específicos de la IA.
  3. Tercera pasada, condiciones de salida: fijó el formato de exportación, confirmó una licencia amplia sobre los resultados y limitó la conservación de registros tras la finalización del contrato a 90 días para los registros no personales.

Una pregunta reveló la brecha más importante: el proveedor no pudo documentar su metodología de anonimización ni descartar la reidentificación de datos de la firma o del cliente, incluso tras dos solicitudes de seguimiento. El contrato se modificó antes de la firma: un estándar de anonimización definido, una prohibición de reidentificación y un fin explícito del uso de valor derivado al término del contrato.

Decisity declara claramente que los datos del cliente nunca se utilizan para entrenar modelos de IA y combina ese compromiso con trazabilidad completa de fuentes y residencia de datos en Europa. La descripción general de seguridad cubre los compromisos técnicos y contractuales en detalle.

Lecturas relacionadas:

Fuentes

Frequently Asked Questions

DECISITY

Resumen con IA

Pida a un asistente de IA que resuma Decisity.