Cada vez que el Redactor IA arma una demanda, hasta ahora el nombre real de tu cliente, su DNI, su domicilio y los datos de la contraparte viajaban tal cual hacia la API del modelo de IA (Gemini, en este caso). Es el mismo dato que necesitás que aparezca en el escrito final, así que tenía sentido — pero también significa que un tercero (el proveedor del modelo) ve esa información en cada mensaje, aunque sea solo para procesarla y no la guarde.

A partir de ahora eso cambia: los datos sensibles del caso se reemplazan por tokens genéricos antes de que la información salga de tu navegador. El modelo redacta usando esos tokens, y recién cuando el resultado vuelve a tu pantalla se reemplazan de nuevo por el dato real. El modelo nunca "ve" el nombre verdadero de nadie.

Un nombre real transformándose en un token genérico entre corchetes antes de salir de un navegador hacia una nube, y volviendo a ser el nombre real al regresar
Un nombre real transformándose en un token genérico entre corchetes antes de salir de un navegador hacia una nube, y volviendo a ser el nombre real al regresar

Qué se reemplaza

No es un escaneo genérico de texto libre buscando "cosas que parezcan un nombre" — eso es poco confiable y da falsos positivos y negativos. En cambio, se aprovecha algo que el Redactor IA ya tiene: los datos del caso llegan como campos estructurados (nombre del cliente, DNI, CUIT, domicilio, nombre del demandado/empleador, parte contraria, aseguradora), no como texto suelto. Como ya sabemos exactamente qué campo es cada dato, el reemplazo es exacto, no una adivinanza:

  • Juan Pérez → [[CLIENTE]]
  • 20-12345678-9 → [[CLIENTE_CUIT]]
  • Av. Siempre Viva 742, Rosario → [[CLIENTE_DOMICILIO]]
  • Constructora XYZ SA → [[DEMANDADO]]

Estos tokens no son al azar: son siempre los mismos por campo, para que el modelo pueda usar [[CLIENTE]] en el encabezado, en los hechos y en el petitorio, y sepa que se refiere siempre a la misma persona a lo largo de todo el documento.

Cómo funciona el ida y vuelta

  1. Cuando armás el mensaje para el Redactor IA, el navegador arma el mapeo dato real → token a partir de los datos del expediente vinculado (si vinculaste uno).
  2. Ese mapeo se aplica tanto al contexto del caso como al contenido ya redactado del documento, antes de mandar el mensaje al backend.
  3. El modelo redacta usando los tokens — nunca ve el dato real.
  4. Cuando el modelo llama a la tool que actualiza una sección, el navegador aplica el mapeo inverso (token → dato real) antes de mostrar el texto en la hoja o guardarlo.
  5. Si el modelo menciona una parte en el chat (por ejemplo, para preguntar un dato faltante), también se des-anonimiza antes de mostrarse — vos ves "Juan Pérez", el modelo solo vio [[CLIENTE]].

Todo este ida y vuelta pasa en tu navegador. El backend de Legio y la API del modelo reciben directamente la versión con tokens — nunca reciben ni procesan el dato real en este flujo.

Cinco campos de un formulario de datos del cliente marcados como cubiertos por el reemplazo, y un documento adjunto de un caso anterior marcado como fuera de este alcance
Cinco campos de un formulario de datos del cliente marcados como cubiertos por el reemplazo, y un documento adjunto de un caso anterior marcado como fuera de este alcance

Qué NO cubre todavía (y por qué)

Para ser honestos sobre el alcance real:

  • Cubre: los campos estructurados del expediente vinculado — cliente, demandado/ empleador, parte contraria, aseguradora, con sus datos de identificación y domicilio.
  • No cubre (por ahora): el texto libre de un documento de referencia que adjuntás manualmente desde el clip 📎 (un escrito real de OTRO cliente que subís para que la IA imite su estilo). Ese texto pertenece a un caso distinto del que tenés vinculado, así que el mapeo de anonimización no lo toca. Si vas a usar esa función, tené en cuenta que el contenido de ese archivo sí viaja tal cual.
  • No cubre: menciones de datos personales sueltas dentro de campos de texto libre como "Notas del expediente" (si ahí escribiste, por ejemplo, el nombre de un testigo que no es ni el cliente ni el demandado, ese nombre no se anonimiza).

Ir más allá de esto — anonimizar cualquier texto libre, detectar entidades no estructuradas — requeriría un modelo de reconocimiento de entidades (NER) corriendo antes de cada mensaje, con su propio costo y su propio margen de error. Preferimos ser precisos con lo que garantizamos (los campos estructurados, 100% cubiertos) antes que prometer una cobertura total que en la práctica tendría agujeros.

Por qué del lado del navegador y no del servidor

Podríamos haber hecho este reemplazo en el backend, justo antes de llamar a la API del modelo. Pero eso significa que el dato real de todos modos viaja hasta nuestro servidor — y después el servidor tendría que acordarse del mapeo para des-anonimizar la respuesta. Haciendo todo en el navegador, el dato real ni siquiera sale de tu computadora en esta parte del flujo: nuestro backend y la API del modelo solo ven la versión con tokens. Es una garantía más fuerte, y no le agrega ningún paso extra al flujo de trabajo del abogado — pasa automáticamente, sin que tengas que hacer nada distinto de lo que ya hacías.