Los sistemas de IA no deberían aprender de ti

Muchas empresas dicen: “No entrenamos con tus datos”. Suena preciso. Tranquilizador, incluso. Pero en la práctica, a menudo omite la parte que realmente importa. Porque dependiendo de cómo esté construido un sistema, tus datos aún pueden influir en el comportamiento sin ser utilizados explícitamente para reentrenar un modelo. Esa influencia simplemente aparece en lugares menos obvios. Las incrustaciones compartidas se actualizan. La clasificación mejora globalmente. La lógica de recuperación se adapta en función del uso agregado. Nada se etiqueta como “entrenamiento”, pero el comportamiento aún cambia en función de las entradas que se originan en otro lugar. Desde una perspectiva técnica, aquí es donde las cosas comienzan a divergir. Existe una diferencia significativa entre los sistemas que actualizan los pesos compartidos del modelo, los sistemas que optimizan globalmente entre inquilinos y los sistemas que mantienen cada entorno adecuadamente aislado. Pueden parecer similares desde el exterior. No lo son.

La diferencia entre datos e influencia

La mayoría de las conversaciones sobre seguridad de IA todavía giran en torno a la exposición de datos. ¿Está cifrado? ¿Quién puede acceder a él? ¿Dónde se almacena? Todas son preguntas válidas. Simplemente no son la imagen completa. Un sistema puede mantener los datos técnicamente seguros y aun así permitir que la influencia se mueva de maneras mucho más difíciles de ver. Si las interacciones de un cliente afectan a las incrustaciones compartidas, modifican el comportamiento de clasificación o dan forma a cómo se optimiza la recuperación a nivel mundial, entonces un entorno está influyendo en otro. No es necesario que los datos brutos sean visibles para que esto suceda. Con el tiempo, esto crea acoplamiento. El comportamiento comienza a depender de señales que no son visibles dentro de un sistema dado. Cuando algo cambia, se vuelve difícil explicar por qué. Hemos visto sistemas donde el comportamiento cambiaba semana a semana, y nadie podía señalar un solo cambio que lo causara. Ese es generalmente el momento en que las personas se dan cuenta de que ya no tienen el control total del sistema.

Por qué importan los límites arquitectónicos

Muchos sistemas actuales procesan interacciones localmente pero optimizan globalmente. En teoría, eso suena eficiente. En la práctica, introduce una discrepancia. La ejecución ocurre dentro de un inquilino, pero el aprendizaje ocurre entre inquilinos. El comportamiento evoluciona basándose en señales que no están contenidas dentro del propio contexto del sistema. Puedes salirte con la tuya por un tiempo. En entornos regulados, no por mucho tiempo. Si las salidas cambian, alguien eventualmente preguntará por qué. Si las decisiones difieren, debe haber un camino rastreable desde la entrada hasta el resultado. Una vez que la influencia se distribuye entre entornos, esa trazabilidad comienza a desmoronarse. El sistema todavía funciona. Pero se vuelve más difícil de razonar y aún más difícil de defender.

Cómo se ve esto en la práctica

Muchos sistemas de IA modernos dependen de proveedores de modelos externos para generar respuestas. Eso significa que los datos salen del límite del sistema, son procesados por un modelo de terceros y luego devueltos como una salida. Los proveedores generalmente indicarán que los datos no se almacenan ni se utilizan para entrenamiento. Contractualmente, eso puede ser cierto. Pero esa no es toda la historia. Porque el sistema todavía depende de lo que se envía a ese modelo. Y en muchas implementaciones, esa responsabilidad recae en el cliente o en la capa de aplicación. Si se incluyen datos personales en los prompts, se procesarán. No maliciosamente. No incorrectamente. Simplemente… por diseño. En ese punto, ya no se trata de un sistema puramente contenido. Dependes de una combinación de configuración, disciplina y, seamos sinceros, un poco de esperanza de que nada no intencionado se filtre. Y sí, eso incluye sistemas como Fin de Intercom o agentes de IA similares. Se asientan sobre LLMs externos. Generan respuestas basadas en datos del cliente. Y aunque proporcionan controles, no eliminan fundamentalmente la posibilidad de que los datos personales se procesen externamente. Si tu arquitectura permite esa vía, asumes ese riesgo.

Un enfoque deliberado para el aislamiento

En Kolsetu, elegimos eliminar toda esa clase de problemas a nivel arquitectónico. No ajustamos modelos fundacionales compartidos con datos de clientes, y no permitimos que la optimización del comportamiento ocurra entre inquilinos. Los pesos del modelo permanecen exactamente como están, independientemente de cómo se utilicen los sistemas individuales. En cambio, el comportamiento se moldea a través del contexto. Cada implementación se ejecuta en su propio entorno, con su propia capa de conocimiento y su propia canalización de datos. La información se almacena y recupera por inquilino, utilizando incrustaciones y almacenes vectoriales que nunca salen de ese límite. La recuperación está acotada, la indexación está aislada y el acceso se controla de extremo a extremo. No es la forma más "eficiente" de construir un sistema global. Es una forma mucho más limpia de construir algo que realmente puedes controlar.

Cómo mejoran los sistemas sin aprendizaje compartido

Nada de esto significa que el sistema se detenga. La mejora todavía ocurre. Simplemente ocurre localmente. Con el tiempo, los sistemas se vuelven más efectivos porque la base de conocimiento se vuelve más limpia, la recuperación mejora y el contexto se ensambla con mayor precisión. El modelo en sí no cambia. Lo que cambia es cómo se selecciona y utiliza la información. Es una forma de aprendizaje más silenciosa. Menos impresionante en una demostración. Mucho más predecible en producción. E, importantemente, cuando el comportamiento mejora, puedes explicar por qué.

Implicaciones para la protección y gobernanza de datos

Esta arquitectura tiene consecuencias directas. Los datos personales permanecen donde se originan. No hay influencia entre inquilinos, ni agregación de señales de comportamiento, ni mezcla de contexto entre sistemas. Cuando las salidas cambian, puedes rastrearlas hasta algo concreto: datos, configuración, flujo de trabajo. No un bucle de retroalimentación invisible enterrado en un sistema compartido. También evita caer en áreas que levantan sospechas regulatorias. No hay perfiles entre contextos, ni capas de optimización ocultas que mezclen señales entre entornos, ni dependencia de que los clientes "tengan cuidado" con lo que envían. Desde el punto de vista del cumplimiento, eso importa.

La seguridad se trata de controlar la influencia

La mayoría de las discusiones sobre seguridad todavía se centran en proteger los datos. Eso es necesario, pero es solo la mitad de la historia. En los sistemas de IA, también necesitas controlar cómo los datos afectan el comportamiento. Hacia dónde fluye la influencia. Dónde se detiene. Qué puede y qué no puede cambiar. Si no controlas eso, los sistemas se vuelven lentamente más difíciles de explicar, incluso si todo está cifrado y tiene control de acceso. Si lo controlas, el comportamiento se mantiene predecible, incluso a medida que el sistema evoluciona. Esa distinción tiende a importar más con el tiempo de lo que la mayoría de la gente espera.

El papel de sistemas como Elba

Este es el principio detrás de cómo está diseñado Elba. Elba opera en entornos estructurados donde el contexto persiste y los flujos de trabajo son explícitos. Conserva información relevante a lo largo del tiempo, pero solo dentro del alcance de un sistema dado. Eso le permite combinar interacciones pasadas y entradas actuales de una manera que mejora los resultados, sin introducir dependencias entre inquilinos. Debido a que la recuperación está controlada, las salidas se mantienen fundamentadas. Debido a que los flujos de trabajo están definidos, las decisiones siguen siendo rastreables. Y debido a que los entornos están aislados, el comportamiento no se desvía solo porque algo cambió en otro lugar. Es un enfoque un poco menos mágico. Pero es mucho más confiable.

Conclusión

La verdadera pregunta no es si un sistema entrena con tus datos. Es cómo tus datos pueden influir en el sistema en absoluto. Una vez que la influencia comienza a moverse a través de los límites, los sistemas se vuelven más difíciles de entender, más difíciles de controlar y más difíciles de explicar. Mantener esa influencia contenida no hace que los sistemas sean más simples, pero los hace predecibles. En Kolsetu, ese es un compromiso que estamos dispuestos a hacer. Porque en los sistemas operativos, especialmente en entornos regulados, la predictibilidad tiende a importar más que la astucia.