Segunda entrega de nuestra serie sobre seguridad y privacidad en herramientas de IA legal. El primer post cubrió el riesgo del entrenamiento de modelos con datos del usuario. Este cubre la retención de datos, específicamente la diferencia entre quién controla lo que se guarda. El tercer post cubrirá el cifrado de los datos que sí se conservan.
Parte I: El problema
La pregunta que importa: ¿quién decide que se guardan?
Cuando hablamos de retención de datos en herramientas de IA, la conversación suele centrarse en cuánto tiempo se guardan las conversaciones. Ese es el parámetro equivocado.
La pregunta correcta no es cuánto tiempo: es quién decide que se guardan.
Hay dos modelos de retención fundamentalmente diferentes:
Retención controlada por el proveedor. El proveedor guarda las conversaciones en sus sistemas para mostrar el historial al usuario, generar logs de sistema, analizar el uso u otras finalidades propias. El usuario puede o no tener la opción de borrar el historial visible, pero los datos que el proveedor retiene en sus sistemas de backend existen con independencia de lo que el usuario haga en la interfaz. Mientras esos datos existan en los sistemas del proveedor, están bajo la ley del proveedor, sujetos a órdenes judiciales, solicitudes de autoridades e incidentes de seguridad que escapan al control del usuario.
Retención controlada por el usuario. El usuario decide activamente qué conservar y qué eliminar. El proveedor no mantiene logs del contenido de las conversaciones en sus propios sistemas. Lo que existe en el sistema es lo que el usuario eligió que existiera, y cuando el usuario lo elimina, se elimina de verdad.
La diferencia entre ambos modelos no es técnica en apariencia, pero tiene consecuencias legales y de seguridad radicalmente diferentes.
El caso que ilustra el riesgo de la retención del proveedor
El 17 de febrero de 2026, el juez Jed Rakoff del Distrito Sur de Nueva York publicó su opinión en Estados Unidos v. Heppner, el primer fallo federal sobre confidencialidad y conversaciones con IA.
Bradley Heppner había usado una herramienta de IA pública para preparar análisis de su estrategia defensiva en un caso de fraude. No tomó una decisión activa de guardar esas conversaciones como registro permanente. Simplemente usó la herramienta.
La herramienta, como la mayoría de las del mercado, retuvo el historial de conversaciones en sus servidores por defecto. Cuando el FBI incautó los dispositivos de Heppner e investigó su actividad digital, esas conversaciones existían en los sistemas del proveedor, sujetas a la misma jurisdicción legal que cualquier otro dato en posesión de un tercero.
El juez ordenó que fueran entregadas a la fiscalía. Entre las razones del fallo, una directamente relacionada con la retención: la política de privacidad de la herramienta permitía compartir datos con autoridades gubernamentales. La existencia de datos retenidos por el proveedor fue el vector que hizo posible la divulgación.
Si la herramienta no hubiera retenido esas conversaciones en sus sistemas, si el contenido no hubiera existido en los servidores del proveedor, no habría habido datos que ordenar entregar.
Lo que "logs" significa en la práctica
El concepto de "logs de sistema" es técnico, pero sus implicaciones son directas. Los sistemas de software mantienen registros de las operaciones que ejecutan. Esos registros pueden incluir desde metadatos puros (timestamps, uso de recursos, errores) hasta el contenido completo de las conversaciones.
En la mayoría de las plataformas de IA, los logs de sistema registran al menos fragmentos del contenido de las conversaciones, por razones de debugging, moderación de contenido o auditoría de seguridad. Esos logs tienen períodos de retención propios, frecuentemente más largos que el historial visible del usuario, y están gobernados por políticas internas de ingeniería que el usuario no controla ni, en la mayoría de los casos, conoce.
La distinción relevante para la privacidad legal es esta: los logs que registran contenido de conversaciones son datos en posesión del proveedor. Son datos que el proveedor puede ser obligado a entregar. Son datos que pueden ser expuestos en una brecha de seguridad. Y son datos que existen independientemente de lo que el usuario haga en la interfaz.
El segundo problema: borrar el historial visible no borra los datos de backend
Un malentendido frecuente entre usuarios de herramientas de IA es creer que eliminar el historial visible en la interfaz equivale a eliminar los datos del sistema.
En la mayoría de las plataformas, no lo es.
El historial que se muestra en la interfaz es la capa de presentación, lo que el sistema eligió mostrar al usuario. Los datos de backend son la capa de almacenamiento: los registros reales en bases de datos, logs, sistemas de backup y caches. Borrar el historial visible frecuentemente desvincula la conversación de la interfaz del usuario sin eliminarla de los sistemas de almacenamiento subyacentes.
Esto tiene una implicación directa: un usuario que "borró" sus conversaciones de la interfaz de una herramienta de IA puede no haber borrado nada de lo que existe en los servidores del proveedor. Y si esos servidores son objeto de una orden judicial o un incidente de seguridad, los datos pueden estar disponibles aunque el usuario creyera haberlos eliminado.
Por qué la retención del proveedor es especialmente problemática para datos legales
Cada tipo de dato tiene un perfil de riesgo específico. Los datos legales tienen características que hacen que la retención no controlada por el usuario sea especialmente problemática:
Son estratégicamente sensibles para partes adversariales. Las conversaciones de estrategia legal, los análisis de posición contractual y las evaluaciones de riesgo tienen valor económico concreto para la contraparte en un litigio o negociación. El nivel de motivación de un atacante para acceder a esos datos es proporcional a ese valor.
Pueden estar sujetos a procedimientos de descubrimiento dirigidos al proveedor. Como demostró Heppner, las órdenes de descubrimiento pueden dirigirse al proveedor directamente, no al abogado. Si el proveedor retiene datos, esos datos son potencialmente alcanzables por esa vía aunque el abogado nunca hubiera imaginado que era posible.
Su confidencialidad tiene consecuencias profesionales específicas. La Regla 1.6 del Modelo de Conducta Profesional de la ABA impone al abogado el deber de hacer "esfuerzos razonables para prevenir la divulgación inadvertida" de información de clientes. Usar una herramienta que retiene datos de conversaciones en sistemas del proveedor sin control del usuario difícilmente satisface ese estándar.
Parte II: La solución
El modelo que LexBuddy implementa: sin logs, con control del usuario
LexBuddy no implementa un modelo de retención cero en el sentido de que las conversaciones desaparezcan inmediatamente. Las conversaciones en LexBuddy pueden guardarse, porque un abogado que trabaja en un asunto durante semanas necesita poder retomar el hilo.
Lo que LexBuddy implementa es un modelo diferente, con dos elementos que juntos cambian la arquitectura de riesgo:
Elemento 1: Sin logs de contenido de conversaciones
LexBuddy no mantiene logs de sistema que registren el contenido de lo que los usuarios escriben. Los logs técnicos de la plataforma registran metadatos operativos (timestamps, estados de sistema, errores técnicos), pero no el texto de las conversaciones.
Esto tiene una implicación concreta: LexBuddy no tiene en sus sistemas una copia del contenido de las conversaciones que exista independientemente de la voluntad del usuario. Si LexBuddy recibiera una orden judicial sobre el contenido de las conversaciones de un usuario, no habría logs que entregar, porque esos logs no existen.
Eso es fundamentalmente diferente de la situación en Heppner, donde la herramienta tenía datos del usuario en sus sistemas que podían ser objeto de una orden de divulgación.
Elemento 2: El usuario decide qué se guarda y cuándo se elimina
Las conversaciones en LexBuddy pueden guardarse en el espacio de trabajo del usuario, porque eso es funcionalmente útil para el trabajo legal. La diferencia está en quién controla esa decisión.
En LexBuddy, el usuario decide qué conversaciones conservar y cuáles eliminar. Cuando un usuario elimina una conversación, esa conversación se elimina de los sistemas de LexBuddy. No hay copias de backend que persistan después de una eliminación del usuario. No hay caché de conversaciones que sobreviva a la decisión de borrar.
Lo que existe en los sistemas de LexBuddy es lo que el usuario eligió que existiera. No más.
La diferencia con el modelo de Heppner
En el caso Heppner, el problema no fue que el acusado hubiera elegido guardar sus conversaciones como registro. El problema fue que el proveedor las guardó por defecto, independientemente de la intención del usuario, y esas conversaciones quedaron en los sistemas del proveedor sujetas a las leyes que gobiernan los datos en posesión de terceros.
En LexBuddy, la lógica está invertida: lo que existe en los sistemas de LexBuddy existe porque el usuario lo eligió. Y cuando el usuario lo elimina, se elimina de verdad.
Eso no crea privilegio abogado-cliente automáticamente. El privilegio depende de otros factores legales que están fuera del alcance de cualquier herramienta tecnológica. Pero sí elimina el vector específico que hizo posible la divulgación en Heppner: la existencia de datos en los sistemas del proveedor que podían ser objeto de una orden de divulgación sin que el usuario lo supiera ni pudiera evitarlo.
Lo que las conversaciones guardadas necesitan: el papel del cifrado
El modelo de retención controlada por el usuario responde a la pregunta de quién decide qué existe. Pero genera una segunda pregunta: cuando el usuario sí decide guardar una conversación, ¿cómo está protegida?
Esa pregunta la responde la arquitectura de cifrado de LexBuddy, que es el tema del tercer post de esta serie. Las conversaciones que el usuario decide mantener en su espacio de trabajo están cifradas con la llave de cifrado de la organización, de forma que ni siquiera el equipo de LexBuddy puede acceder a su contenido. La retención bajo control del usuario y el cifrado por organización son dos capas de protección que se complementan: la primera define quién decide qué existe, la segunda protege lo que existe.
Dos preguntas en secuencia: primero, ¿tiene la herramienta logs de sistema que registren el contenido de mis conversaciones? Y segundo, si elimino una conversación desde la interfaz, ¿desaparece de todos los sistemas de backend? Si la respuesta a la primera es "sí" o "no lo sé", o si la respuesta a la segunda es "no" o "no estamos seguros", el proveedor retiene datos sobre los que el usuario no tiene control real.
Siguiente entrega: Cifrado por organización y MFA, cómo se protege lo que el usuario decide guardar.
Este artículo es de carácter informativo y no constituye asesoría legal. Para aplicaciones específicas a tu práctica, consulta con un especialista en ética profesional de tu jurisdicción.
Fuentes
| Fuente | Enlace |
|---|---|
| Harvard Law Review Blog: United States v. Heppner | harvardlawreview.org |
| Gibson Dunn: AI privilege waivers, SDNY rules against privilege for consumer AI outputs | gibsondunn.com |
| Akin Gump: SDNY rules that a public AI platform is not protected by privilege | akingump.com |
| Perkins Coie: Heppner and Gilbarco, courts apply privilege and work product to AI | perkinscoie.com |
| ABA: 2024 Legal Technology Survey Report | americanbar.org |
| ABA Formal Opinion 512 (PDF, 29 de julio de 2024) | americanbar.org |
| GDPR: Artículo 5, principios relativos al tratamiento de datos personales | gdpr-info.eu |
| GDPR: Artículo 17, derecho de supresión | gdpr-info.eu |