OpenAI presentó Dots, un sistema diseñado para que los modelos de inteligencia artificial retengan contexto personalizado entre sesiones. La capacidad de persistir información sobre usuarios individuales abre interrogantes concretos sobre propiedad del dato, clasificación, retención y auditoría que los equipos de gobernanza de datos no pueden diferir.
Dots funciona como una capa de memoria estructurada: en lugar de que cada conversación comience desde cero, el modelo extrae y almacena fragmentos de contexto —preferencias, instrucciones recurrentes, datos de comportamiento— para recuperarlos en interacciones futuras. Desde la perspectiva de un Chief Data Officer, esto no es una mejora de experiencia de usuario sino un nuevo repositorio de datos con ciclo de vida propio, sin que la mayoría de las organizaciones hayan definido quién es el data steward responsable de ese almacén ni cómo se integra al catálogo corporativo.
Qué tipo de dato genera Dots y por qué importa clasificarlo hoy
El contenido que Dots retiene puede incluir desde preferencias operativas hasta información inferida sobre comportamientos o roles organizacionales. Según el DAMA-DMBOK, la clasificación es el primer control del ciclo de vida del dato: sin saber qué categoría ocupa un fragmento de memoria persistida, no es posible aplicar controles de acceso, políticas de retención ni reglas de eliminación. Si un empleado le indica a un agente de IA cuál es su área de negocio, su nivel jerárquico o las herramientas que usa, esa información inferida puede calificar como dato personal bajo la Ley 25.326 en Argentina, la LGPD brasileña o la LFPDPPP mexicana, independientemente de que el almacenamiento ocurra en infraestructura de OpenAI.
La distinción no es trivial. Bajo la LGPD (Lei 13.709/2018), el controlador —la empresa que despliega la herramienta— es responsable de garantizar que el operador (en este caso, OpenAI como proveedor) trate los datos conforme a las instrucciones contractuales. Si Dots almacena datos de colaboradores sin que exista una cláusula de data processing agreement que contemple específicamente la retención de memoria persistente, la empresa está operando fuera del marco del contrato de tratamiento.
Data lineage y el problema del contexto opaco
Uno de los desafíos de gobernanza más inmediatos que presenta Dots es el data lineage, es decir, la trazabilidad del origen y transformación de cada fragmento de dato. En un flujo tradicional, un dato entra por un sistema fuente, se transforma en pipelines auditables y llega a un destino documentado. Con memoria persistente en un modelo de lenguaje, la extracción del contexto es semideterminista: el modelo decide qué retener y qué descartar según criterios que no son completamente transparentes para el operador empresarial. Esto rompe la cadena de linaje y dificulta responder ante una solicitud de acceso o supresión bajo cualquier régimen de derechos ARCO.
El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica la capacidad de rastrear datos personales a través de sistemas de terceros como uno de los requerimientos centrales para organizaciones que operan en la nube. Los bancos colombianos sujetos a la Circular Externa 029 de la SFC, o las entidades financieras argentinas bajo la Comunicación A 8073 del BCRA, ya deben demostrar trazabilidad de datos sensibles en proveedores cloud. Un sistema de memoria de IA no certificado bajo esos esquemas representa un gap de control documentable.
Cuándo aplica el riesgo de gobernanza y cuándo no
No toda implementación de Dots genera el mismo nivel de exposición. El riesgo es alto cuando: (1) los usuarios finales son empleados que interactúan con información corporativa confidencial o datos de clientes; (2) la organización opera en sectores regulados —salud, finanzas, educación— donde la retención no autorizada tiene consecuencias específicas; o (3) no existe un data processing agreement actualizado con OpenAI que cubra explícitamente la funcionalidad de memoria persistente. El riesgo es bajo o gestionable cuando el uso se limita a entornos sandbox sin datos reales, cuando se activa la opción de deshabilitar la memoria (si OpenAI la provee a nivel enterprise), o cuando el flujo de datos ya está cubierto por un DPA vigente y revisado por el equipo legal.
La distinción importa porque la respuesta operativa es diferente: en el primer escenario, la acción es bloquear o restringir el despliegue hasta cerrar los gaps contractuales y de clasificación; en el segundo, alcanza con documentar el análisis de riesgo en el registro de actividades de tratamiento que exigen tanto el artículo 31 del GDPR como sus equivalentes en LGPD y Ley 25.326.
Tres acciones concretas para equipos de gobernanza ante el lanzamiento de Dots
- Revisar el inventario de sistemas de IA corporativos e identificar cuáles utilizan o planean utilizar OpenAI con funcionalidades de memoria activa; asignar un data steward responsable para cada caso.
- Actualizar o solicitar la actualización del data processing agreement con OpenAI para que cubra explícitamente la retención de contexto, los plazos de conservación y los mecanismos de supresión, alineados con los requerimientos de la regulación local aplicable.
- Incorporar en el catálogo de datos corporativo una categoría para “datos de memoria de IA” con clasificación, nivel de sensibilidad y política de retención definida, tal como se haría con cualquier otra fuente de datos de terceros.
La documentación técnica de Dots y los términos de servicio empresariales de OpenAI son el punto de partida obligado para cualquier análisis de brecha; el equipo de gobernanza no puede subcontratar esa lectura al área legal sin haber definido primero qué datos están en juego.
