
Inteligencia simbiótica · Parte VII · Capítulo 30
Datos, secreto, propiedad y contratación
Un sistema de IA no recibe «datos» en abstracto.
Un sistema de IA no recibe «datos» en abstracto.
Recibe documentos de clientes, comunicaciones, imágenes, registros, instrucciones, obras, secretos, datos personales, metadatos y correcciones. Cada material llega con una historia y una posición jurídica.
La facilidad de cargarlo todo en una misma interfaz produce una ilusión de homogeneidad.
El gobierno empieza devolviendo diferencias.
Finalidad y trayectorias de tratamiento
En protección de datos no basta preguntar si una herramienta «cumple RGPD».
Hay que identificar tratamientos concretos:
- incorporación de datos a una consulta;
- almacenamiento de conversaciones;
- recuperación desde un repositorio;
- generación de embeddings o índices;
- uso para mejorar un servicio;
- entrenamiento o ajuste;
- evaluación;
- registro de seguridad;
- revisión humana;
- y comunicación del resultado.
Cada operación puede implicar actores, finalidades, bases, plazos y riesgos distintos.
El Comité Europeo de Protección de Datos ha subrayado que un modelo entrenado con datos personales no puede considerarse anónimo en todos los casos: la evaluación debe hacerse caso por caso y atender tanto a la posibilidad de extraer datos como de obtenerlos mediante consultas. También exige, cuando se invoque interés legítimo, identificar un interés lícito, preciso y actual, comprobar necesidad y realizar ponderación.[^20]
La afirmación «el modelo no contiene una base de datos legible» no resuelve la cuestión.
Minimizar contexto sin amputar la función
La minimización no significa aportar tan poco que el sistema produzca una respuesta peligrosa.
Significa construir el contexto mínimo suficiente para la función.
Puede requerir:
- seudonimizar identidades;
- excluir anexos irrelevantes;
- recuperar fragmentos bajo demanda;
- separar expedientes;
- limitar herramientas por rol;
- resumir con vínculo a la fuente;
- usar entornos distintos según sensibilidad;
- y borrar contexto situado al cerrar.
Una arquitectura pobre obliga a elegir entre privacidad y calidad. Una arquitectura mejor diseña el paso exacto por el que la información necesaria llega sin convertir toda la memoria en entrada permanente.
Secreto, confidencialidad y privilegio
Secreto profesional, deber contractual de confidencialidad, secreto empresarial y privilegio procesal no son sinónimos.
Pueden proteger materiales distintos, frente a sujetos distintos y con consecuencias distintas. El sistema debe conocer qué protección se invoca y no tratar «confidencial» como una etiqueta genérica.
En la práctica profesional, el CCBE ha advertido que no deben introducirse datos personales o confidenciales de clientes en herramientas generativas sin salvaguardas adecuadas, y vincula el uso a deberes de competencia, independencia, transparencia, conflicto y verificación.[^21]
Las salvaguardas no se reducen a una modalidad empresarial. Incluyen:
- diligencia sobre proveedor y subproveedores;
- instrucciones y finalidad;
- control de acceso;
- segregación;
- cifrado;
- retención;
- incidentes;
- uso secundario;
- auditabilidad;
- y formación sobre los canales autorizados.
La política debe alcanzar también a herramientas personales y usos invisibles. Prohibir sin ofrecer una vía operativa segura suele desplazar el tratamiento a la sombra.
Obras, materiales y outputs
La propiedad intelectual abre al menos cuatro preguntas distintas:
- ¿con qué materiales se desarrolló el modelo?;
- ¿qué materiales introduce la organización?;
- ¿qué reproduce o transforma la salida?;
- ¿quién puede explotar el artefacto humano–IA resultante?
No existe una respuesta universal sobre titularidad o licitud del output por el mero hecho de haber sido generado con IA. Depende de jurisdicción, naturaleza de la aportación humana, condiciones del proveedor, materiales utilizados, grado de reproducción y finalidad.
En la Unión Europea, los proveedores de modelos de propósito general están sujetos a obligaciones de documentación y a políticas para cumplir el Derecho de autor, junto con reglas de transparencia sobre contenido de entrenamiento; el Código de Buenas Prácticas para GPAI ofrece una vía voluntaria para demostrar determinadas obligaciones.[^22]
Para la organización usuaria, la diligencia sigue siendo concreta:
- no asumir exclusividad de una salida;
- controlar similitudes materiales cuando el uso lo exige;
- conservar aportación y transformación humanas relevantes;
- respetar licencias de entradas y fuentes;
- y pactar garantías y límites realistas.
El artefacto compuesto
Un sistema simbiótico produce objetos difíciles de reducir a una obra única:
- un corpus seleccionado;
- una arquitectura de memoria;
- una taxonomía;
- criterios;
- instrucciones;
- herramientas;
- código;
- evaluaciones;
- conversaciones;
- correcciones;
- y documentos finales.
El valor puede residir en la relación entre capas más que en cada elemento.
La contratación debe identificar qué puede:
- usar cada parte durante la relación;
- reutilizar después;
- transferir;
- revelar;
- entrenar o mejorar;
- y destruir.
No todo lo valioso necesita apropiación exclusiva. Parte puede protegerse mediante acceso, secreto, licencia, marca, gobernanza o ventaja operativa. Exigir propiedad total sobre cada capa puede impedir colaboración. Dejarlo todo en silencio convierte la dependencia en conflicto futuro.
Diligencia sobre el proveedor
La evaluación contractual y técnica debe responder, como mínimo:
- qué servicio se presta y qué puede cambiar;
- qué datos recibe;
- con qué finalidades los usa;
- dónde y cuánto tiempo los conserva;
- qué terceros intervienen;
- qué garantías de seguridad ofrece;
- cómo notifica incidentes y cambios;
- qué documentación y logs facilita;
- qué niveles de servicio son verificables;
- qué restricciones impone a la evaluación;
- cómo coopera en derechos, auditorías y reclamaciones;
- qué indemnidades y límites existen;
- y cómo se exporta y elimina al terminar.
La respuesta «utilizamos un proveedor líder» no es diligencia.
La reputación reduce algunas incertidumbres y concentra otras.
Contratos encadenados
Un integrador puede prometer al cliente más de lo que recibe del proveedor del modelo. El proveedor puede modificar funciones sin aceptar responsabilidad por el uso. Una plataforma puede reservarse amplias facultades sobre datos mientras el profesional promete confidencialidad absoluta.
La cadena contractual debe comprobar correspondencia descendente y ascendente:
- ¿puede el proveedor local cumplir lo prometido?;
- ¿puede imponer a sus subproveedores los límites asumidos?;
- ¿recibirá la información necesaria para notificar?;
- ¿dispone de derechos suficientes sobre los componentes?;
- ¿puede prestar asistencia en una investigación o litigio?;
El contrato no crea control que la parte no posee.
Puede obligarla a construirlo, adquirirlo o declarar honestamente su ausencia.
Datos de corrección y trabajo humano
Las correcciones de profesionales pueden convertirse en un recurso valioso para evaluar o mejorar sistemas. No son un residuo libre.
Pueden contener:
-
datos personales;
-
secretos;
-
conocimiento de cliente;
-
decisiones internas;
-
estilo profesional;
-
y trabajo protegido o remunerado bajo otra finalidad.
Antes de reutilizarlas hay que separar lo que corrige una salida general de lo que revela contexto situado. También decidir quién obtiene el valor de ese aprendizaje.
La inteligencia simbiótica no debe convertirse en un mecanismo por el que una plataforma extrae sin forma la experiencia de quienes la hacen fiable.
La soberanía no es aislamiento
Control no significa necesariamente alojarlo todo dentro de la organización.
Una infraestructura externa puede ofrecer más seguridad, mantenimiento y resiliencia. Un sistema local puede ser opaco, mal actualizado y dependiente de una sola persona.
La soberanía relevante es capacidad de conocer, decidir, cambiar y salir.
Se mide por:
- portabilidad;
- observabilidad;
- alternativas;
- control de identidad y claves;
- comprensión de dependencias;
- y continuidad ante una retirada.
El objetivo no es no depender.
Es no depender a ciegas.
El mapa de circulación
Una descripción fiable puede seguir un dato desde origen hasta cierre:
| Momento | Pregunta |
|---|---|
| Captura | ¿De dónde procede y quién podía aportarlo? |
| Preparación | ¿Se limpia, transforma, seudonimiza o fragmenta? |
| Envío | ¿Qué recibe el proveedor y bajo qué canal? |
| Procesamiento | ¿Con qué finalidad, localización y subproveedores? |
| Contexto | ¿Con qué otros materiales puede combinarse? |
| Salida | ¿Qué dato reproduce, infiere o crea? |
| Decisión | ¿Quién utiliza la salida y con qué efecto? |
| Registro | ¿Qué logs, evaluaciones y correcciones quedan? |
| Reutilización | ¿Se usa para mejora, entrenamiento o conocimiento? |
| Cierre | ¿Qué se devuelve, conserva, bloquea o suprime? |
El mapa debe incluir metadatos e inferencias. Una salida que no repite el dato original puede seguir revelando una categoría sensible o un secreto.
La frontera entre contexto y entrenamiento
Introducir información para obtener una respuesta no equivale necesariamente a entrenar el modelo. Puede utilizarse como contexto efímero, almacenarse en historial, incorporarse a índices, servir para evaluación o contribuir a mejora posterior.
La diferencia técnica debe corresponder con condiciones contractuales y configuración verificable.
La frase «no entrenamos con sus datos» deja abiertas preguntas:
- ¿se conservan prompts y outputs?;
- ¿pueden revisarlos personas?;
- ¿se usan para seguridad o evaluación?;
- ¿se generan embeddings?;
- ¿qué ocurre con feedback y correcciones?;
- ¿qué subproveedores reciben contenido?;
- ¿qué control tiene la organización?
Una salvaguarda no se deduce de una consigna comercial.
Secretos compuestos
Algunos secretos no están contenidos en un documento. Emergen al combinar:
- nombres de proyecto;
- calendario;
- personas;
- volúmenes;
- patrones de consulta;
- y decisiones.
Un proveedor puede no acceder al contrato completo y conocer, por metadatos, que una empresa prepara una adquisición, un despido colectivo o una investigación.
La minimización debe considerar la forma que aparece al juntar piezas.
Matriz de derechos sobre el artefacto
Para evitar cláusulas totales puede utilizarse una matriz:
| Capa | Aporta | Usa durante | Reutiliza después | Transfiere | Debe suprimir |
|---|---|---|---|---|---|
| Datos del cliente | Cliente/terceros | Según finalidad | Solo si se autoriza | Formato acordado | Según cierre |
| Método general | Proveedor/núcleo | Para prestar | Sí, sin revelar contexto | Licencia si procede | No necesariamente |
| Configuración situada | Conjunta | Para el sistema | Según reparto | Necesaria para continuidad | Partes sensibles |
| Correcciones | Profesionales | Para validar | Solo tras clasificar | Según contrato | Contexto no reutilizable |
| Output final | Unidad humano–IA | Para el encargo | Según derechos y secreto | Al destinatario legítimo | Copias según régimen |
La matriz no decide la ley aplicable. Obliga a formular el reparto que el contrato pretende realizar.
La diligencia continúa después de firmar
El proveedor cambia. Aparecen subprocesadores, nuevas funciones, modelos y condiciones. La evaluación inicial caduca.
El contrato debe alimentar un registro de cambios y la operación debe saber qué cambio requiere:
- mera actualización documental;
- prueba de regresión;
- nueva evaluación de impacto;
- autorización del cliente;
- modificación contractual;
- o suspensión.
La gobernanza de datos no es el peaje de entrada.
Es una función de mantenimiento de la relación.