Por qué '¿es seguro?' invita a la respuesta equivocada
Antes de subir un dossier del consejo o material de diligencia a una plataforma de estrategia con IA, sustituya la pregunta '¿es seguro?' por una lista de documentos que solicitar: un contrato de encargo de tratamiento, una lista nominal de subencargados, una región de residencia de datos declarada, una política escrita de retención y supresión, y un documento de medidas de seguridad.
Un dossier del consejo está a punto de salir del edificio. También una presentación de dirección, un conjunto de estados financieros internos o un expediente de diligencia que solo debían ver cuatro personas. La pregunta que precede de forma natural a la subida es alguna versión de: ¿es seguro? El problema de esa pregunta es que está construida para responderse mal. Pide al proveedor una sensación, y los proveedores tienen práctica en dar sensaciones. Tranquilizador no es lo mismo que verificado, y una conversación segura sobre cifrado no dice nada de lo que ocurre con sus documentos después de que lleguen.
La Information Commissioner's Office del Reino Unido expone el fondo del asunto en el apartado sobre contratos y terceros de su marco de auditoría de protección de datos para inteligencia artificial: sin contratos adecuados, los incumplimientos de las obligaciones de responsables y encargados no pueden evaluarse ni atribuirse, y con acuerdos meramente verbales falta vía de recurso si se produce una infracción de los requisitos del RGPD del Reino Unido.[1] Una garantía verbal no tiene un modo de fallo que usted pueda señalar. Un documento sí.
Por eso este artículo adopta otro enfoque. En lugar de preguntar si un proveedor es seguro, convierte cada preocupación del comprador en un artefacto concreto: un documento que existe, en una forma que usted puede leer, o no existe. Para cada preocupación que importa cuando hay material confidencial en juego, hay un artefacto con nombre que un proveedor serio ya debería publicar. Las secciones siguientes cubren cinco de ellos:
- El contrato de encargo de tratamiento y las cláusulas de uso de datos del contrato, que responden a si el proveedor solo trata sus documentos o entrena con ellos.
- Una región de residencia de datos declarada, que responde a dónde residen físicamente los datos y qué ocurre si se mueven.
- Una lista nominal y publicada de subencargados, que responde a quién más toca el material.
- Una política escrita de retención y supresión, que responde a qué ocurre con los datos durante el encargo y después de que termine.
- Un documento de medidas de seguridad, que responde a quién dentro del proveedor puede ver su material y cómo se controla ese acceso.
Dos advertencias antes de la lista. Primera: nada de lo aquí escrito es asesoramiento jurídico; los puntos regulatorios están anclados a instrumentos vigentes y con nombre, pero su asesoría debe revisar las condiciones contractuales reales antes de subir material confidencial. Segunda: la lista es deliberadamente neutral respecto al proveedor. Sirve para cualquier plataforma de estrategia con IA que esté evaluando, incluida aquella que publica este artículo.
Entrenar con sus datos frente a tratarlos
La distinción más determinante en el contrato con un proveedor de IA está entre tratar sus documentos para entregar su análisis y retener derechos para entrenar o afinar modelos con ellos. Tratar significa que el proveedor lee su dossier del consejo, lo cruza, produce el entregable que usted pidió y no usa el material para nada más. Entrenar significa que el proveedor puede incorporar lo aprendido de sus documentos a modelos que sobreviven al encargo y sirven a otros clientes. Son relaciones distintas con su información confidencial, y los contratos no siempre hacen evidente la diferencia.
Morgan Lewis, al escribir sobre proveedores que buscan cada vez más derechos expresos para usar datos de clientes en el entrenamiento de sus modelos de IA, señala que en la práctica la cuestión crítica no suele ser quién es propietario de los datos subyacentes, sino qué derechos recibe el proveedor para usar, conservar y extraer valor de esos datos con el tiempo, y que aun cuando la empresa conserve la propiedad de sus datos brutos, unos derechos de entrenamiento amplios pueden permitir al proveedor crear modelos que incorporen indefinidamente aprendizajes derivados de ellos.[2] La propiedad de los datos brutos no equivale al control de lo que un proveedor deriva de ellos. El mismo análisis describe la posible exposición de información confidencial y secretos empresariales como una de las preocupaciones más significativas, y enumera las preguntas a considerar: qué categorías de datos se usarán para el entrenamiento, si se mantienen las protecciones de confidencialidad y de secreto empresarial, y si el entrenamiento puede restringirse a conjuntos de datos concretos.[2]
El artefacto que hay que solicitar aquí es el contrato mismo, leído en dos lugares. Primero, las cláusulas de uso de datos y entrenamiento del contrato principal: ¿otorgan al proveedor derechos para mejorar servicios, desarrollar productos o crear conjuntos de datos agregados, y puede excluirse o limitarse el entrenamiento a una adhesión expresa? Segundo, el contrato de encargo de tratamiento, que rige cómo se manejan los datos personales contenidos en sus documentos y debe establecer que el encargado actúa únicamente siguiendo instrucciones documentadas suyas. Morgan Lewis observa además que las condiciones jurídicas son solo una parte del análisis y que las salvaguardas técnicas son igual de importantes, y enumera lo que las organizaciones deberían entender: si los datos se segregan entre clientes, si el entrenamiento se produce en modelos compartidos o dedicados, si el proveedor usa modelos fundacionales de terceros y si los datos del cliente pueden excluirse de ciclos de entrenamiento futuros.[2] Un proveedor que declara con claridad, por escrito, que nunca usa datos de clientes para entrenar modelos de IA ha respondido a la pregunta. Uno que responde con un párrafo sobre anonimización y agregación le está diciendo que siga leyendo.
Dónde residen físicamente los datos y por qué importa en Europa
La residencia de datos es un hecho, no una expresión. 'Seguridad de nivel bancario' y 'listo para empresas' no dicen nada sobre en qué servidores de qué país están sus documentos, qué jurisdicciones pueden alcanzarlos o qué ocurre cuando un técnico de soporte de otra región abre una sesión. Para un comprador europeo, la cuestión de la ubicación tiene un filo jurídico específico, porque el RGPD, Reglamento (UE) 2016/679, restringe las transferencias de datos personales a terceros países salvo que se cumplan las garantías de su capítulo V. Si sus documentos contienen datos personales, y un dossier del consejo o un archivo financiero interno casi siempre los contienen, el lugar donde el proveedor los aloja y trata determina si existe siquiera una restricción de transferencia.
Los artefactos que hay que pedir son igual de concretos. Primero, una región de residencia de datos declarada en el contrato o en la documentación del proveedor: una región con nombre, por escrito, no una afirmación de marketing. Segundo, si hay tratamiento o acceso fuera del EEE, el mecanismo de transferencia en el que se apoya. El instrumento estándar es la Decisión de Ejecución (UE) 2021/914 de la Comisión, de 4 de junio de 2021, relativa a las cláusulas contractuales tipo para la transferencia de datos personales a terceros países en virtud del Reglamento (UE) 2016/679, que sigue vigente.[3] Si la respuesta del proveedor a '¿dónde están los datos?' es una conversación sobre infraestructura global en lugar de una región con nombre en un documento, trátelo también como una respuesta.
Conviene conocer un matiz antes de leer la documentación del proveedor. Las Recomendaciones 01/2020 del Comité Europeo de Protección de Datos, sobre medidas que complementan las herramientas de transferencia, adoptadas en su versión final el 18 de junio de 2021, establecen una hoja de ruta por pasos para los exportadores de datos que comienza por conocer sus transferencias, y afirman que el acceso remoto desde un tercer país, por ejemplo en situaciones de soporte, y el almacenamiento en una nube situada fuera del EEE también se consideran transferencia.[4] Un proveedor puede alojar en la UE y aun así generar una transferencia si personal o subencargados fuera del EEE pueden alcanzar los datos. Pregunte por el acceso, no solo por el almacenamiento.
Subencargados: pida una lista nominal y publicada
Detrás de cada plataforma de estrategia con IA hay una cadena de suministro: alojamiento, proveedores de modelos, herramientas de soporte, servicios de analítica. Cada uno es otra parte que puede tocar sus documentos, y cada uno es un punto en el que su confidencialidad depende de alguien con quien usted no contrató. La pregunta '¿quién más puede ver nuestros datos?' no es paranoia: es la pregunta de la cadena de suministro, y tiene una forma jurídica precisa bajo el RGPD.
El artículo 28, apartado 2, del RGPD dispone que el encargado no recurrirá a otro encargado sin la autorización previa por escrito, específica o general, del responsable, y que en el caso de autorización general por escrito el encargado informará al responsable de cualquier cambio previsto en la incorporación o sustitución de otros encargados, dando así al responsable la oportunidad de oponerse a dichos cambios.[5] El artículo 28, apartado 4, exige que se impongan las mismas obligaciones de protección de datos a cualquier otro encargado al que se recurra para realizar actividades de tratamiento específicas, y dispone que si ese otro encargado incumple sus obligaciones de protección de datos, el encargado inicial seguirá siendo plenamente responsable ante el responsable del tratamiento del cumplimiento de las obligaciones de aquel.[5] En términos claros: el proveedor no puede externalizar sus documentos sin autorización, debe avisarle cuando la cadena cambie y sigue respondiendo por lo que hagan sus subencargados.
El artefacto que hay que pedir es una lista nominal de subencargados, publicada y fechada, junto con el mecanismo de aviso y oposición que rige sus cambios. 'Publicada y fechada' pesa más de lo que parece. Una lista descrita en una conversación no se puede comprobar después, no se puede comparar con lo que el proveedor dijo el trimestre pasado y no le da nada a lo que oponerse. Una lista publicada con un plazo de preaviso le permite ver exactamente quién está hoy en la cadena y le da una ventana definida para oponerse cuando cambie. Una respuesta comprobable se ve así: el contrato de encargo obliga al proveedor a notificar nuevos subencargados actualizando la lista publicada, fija por escrito un plazo de oposición y nombra la región en la que puede producirse el tratamiento.
Retención y supresión, también al terminar el contrato
La mayoría de los compradores piensa en qué ocurre con sus documentos cuando se suben. Menos piensan en qué ocurre cuando el encargo termina, y en ese segundo momento la confidencialidad se gana o se pierde en silencio. Un documento que sigue en las copias de seguridad de un proveedor tres años después de cerrado el proyecto es todavía un documento que salió de su edificio. La pregunta de evaluación no es solo '¿están seguros los datos ahora?', sino '¿quién decide cuándo dejan de existir, y puedo comprobar que así fue?'
El artefacto que hay que pedir es una política escrita de retención y supresión que indique plazos de conservación, cómo se tratan las copias de seguridad y los plazos de borrado. Bajo el RGPD esto no es una cortesía opcional: el artículo 28, apartado 3, letra g), exige que el encargado, a elección del responsable, suprima o devuelva todos los datos personales una vez finalice la prestación de los servicios de tratamiento, y suprima las copias existentes salvo que el Derecho de la Unión o de los Estados miembros exija su conservación.[5] Las condiciones de fin de vida del contrato deben coincidir con la política publicada: si el contrato dice supresión al terminar y la política dice archivo por un periodo indeterminado, ha encontrado una brecha que conviene resolver antes de la firma, no después.
Dos detalles merecen atención específica al leer la política. Primero, los artefactos derivados. Sus documentos brutos no son lo único que crea una plataforma: incrustaciones, resultados de análisis, registros y exportaciones derivan todos de su material, y una política de supresión que solo cubra los archivos de origen deja atrás los derivados. Pregunte qué dice la política sobre cada uno. Segundo, la mecánica del fin del contrato. Un contrato de encargo bien redactado prevé que, antes de que expire el acuerdo, el encargado suprima o devuelva de forma segura todos los datos personales a elección e instrucción del cliente, y que el cliente pueda solicitar constancia escrita de las medidas adoptadas al completar el tratamiento. Una confirmación escrita de la supresión es la diferencia entre creer que los datos ya no están y saber que alguien se comprometió por escrito a decírselo.
Control de acceso dentro del proveedor
El cifrado protege sus documentos de los de fuera. El control de acceso los protege de los de dentro, y con material confidencial la pregunta interna suele ser la más afilada: ¿qué empleados del proveedor pueden abrir un dossier del consejo, en qué condiciones y con qué registro de haberlo hecho? Una plataforma puede estar bien defendida en el perímetro y aun así permitir por defecto un acceso interno amplio. El artefacto que responde a esto es un documento de medidas de seguridad que describa el acceso basado en roles, los permisos de mínimo privilegio y el registro de auditoría con detalle operativo.
El RGPD da a ese documento un respaldo jurídico. El artículo 28, apartado 3, letra b), exige que el contrato de tratamiento estipule que el encargado garantiza que las personas autorizadas para tratar datos personales se han comprometido a respetar la confidencialidad o están sujetas a una obligación de confidencialidad de naturaleza estatutaria.[5] El artículo 28, apartado 3, letra h), exige que el encargado ponga a disposición del responsable toda la información necesaria para demostrar el cumplimiento de las obligaciones establecidas en ese artículo y permita y contribuya a la realización de auditorías, incluidas inspecciones, por parte del responsable o de otro auditor autorizado por este.[5] Leídas juntas, estas disposiciones significan que usted tiene derecho a ver cómo restringe y registra el proveedor el acceso interno, no simplemente a oír que está restringido.
El consejo práctico es leer el documento de medidas de seguridad junto a la cláusula de derechos de auditoría del contrato, en lugar de aceptar un resumen de certificaciones. Una afirmación de certificación es una afirmación sobre un proceso ocurrido en un momento dado; el documento de seguridad describe los controles que operan sobre sus datos cada día. Un proveedor bien preparado publica este material, por ejemplo en una página de integraciones y seguridad que describa el control de acceso basado en roles con permisos de mínimo privilegio, registros de auditoría exportables y políticas de retención configurables por encargo. Y donde un proveedor sí afirme una certificación, verifique la afirmación contra la propia documentación publicada del proveedor en lugar de darla por supuesta: pregunte qué cubre la certificación, qué entidad la ostenta y si el alcance incluye la plataforma que realmente le están vendiendo. Un proveedor serio ya habrá publicado las respuestas.
Cuando la respuesta es verbal, y cómo es un proveedor preparado
Antes o después, en una evaluación, un proveedor responderá a alguna de estas preguntas solo de palabra. La reacción no es discutir, sino pedir la respuesta por escrito antes de la firma. El marco de auditoría del ICO para sistemas de IA explicita la razón: con acuerdos meramente verbales falta vía de recurso si se produce una infracción de los requisitos del RGPD del Reino Unido, y sin contratos adecuados los incumplimientos de las obligaciones de responsables y encargados no pueden evaluarse ni atribuirse.[1] Un proveedor que no puede aportar el documento ha respondido igualmente a la pregunta. La respuesta es que el artefacto no existe, o existe en una forma que el proveedor prefiere que usted no lea. En cualquier caso, ha aprendido algo aprovechable antes de la subida, no después.
La lista completa, en el orden en que debería discurrir una evaluación seria:
- Contrato de encargo de tratamiento y cláusulas de uso de datos: ¿entrena el proveedor con sus datos y puede excluirse el entrenamiento?
- Región de residencia de datos declarada: una región con nombre en el contrato o la documentación, más el mecanismo de transferencia si hay tratamiento o acceso fuera del EEE.
- Lista de subencargados nominal, publicada y fechada: quién está en la cadena y qué mecanismo de aviso y oposición rige los cambios.
- Política escrita de retención y supresión: plazos de conservación, tratamiento de copias de seguridad, plazos de borrado, tratamiento de los artefactos derivados y devolución o supresión al terminar el contrato con confirmación escrita.
- Documento de medidas de seguridad: acceso basado en roles, permisos de mínimo privilegio y registro de auditoría, leído junto a la cláusula de derechos de auditoría del contrato.
Este es el estándar contra el que se construyó Decisity. Como plataforma de estrategia nativa de IA, ni consultora ni proveedor de seguridad, espera que le hagan estas preguntas y las responde con documentos publicados en lugar de con tranquilidad verbal: un contrato de encargo publicado con compromisos de tratamiento en la UE y el EEE, una lista de subencargados con una ventana de oposición definida y una página de seguridad que expone sus controles de acceso, registro y retención con detalle operativo. Para los compradores europeos que manejan material estratégico confidencial, esa postura se extiende a la residencia europea de datos como principio de diseño declarado y no como argumento de venta, también para el Mittelstand y las empresas medianas cuyos documentos de consejo así lo exigen. El mismo estándar se aplica a todo proveedor que evalúe, incluido este: lea los documentos y, donde una afirmación importe, verifíquela contra lo que el proveedor haya publicado realmente.
Un punto final corresponde a su asesoría jurídica y no a este artículo: pídale que revise las condiciones contractuales, incluidos el contrato de encargo de tratamiento, la cláusula de derechos de auditoría y las disposiciones de responsabilidad, antes de subir cualquier material confidencial. La lista anterior le dice qué documentos poner delante de ella. Su firma le dice que las condiciones se sostienen.
Fuentes
- ICO: Contracts and third parties (AI and data protection audit framework)
- Morgan Lewis: Key Considerations When Allowing a Vendor to Train Its AI Models on Customer Data
- Commission Implementing Decision (EU) 2021/914 on standard contractual clauses
- EDPB Recommendations 01/2020 on measures that supplement transfer tools
- GDPR Article 28: Processor

