Actualizado el 29 de septiembre de 2026. Dos correcciones más. Primera: este texto prometía que el modelo no llegaría a saber quién es el cliente. El proceso sustituye los identificadores que reconoce; tiene las lagunas descritas más abajo, y esa promesa era demasiado fuerte. Segunda: el texto de un paso de IA ya no va directamente del navegador al modelo. En los planes gestionados pasa por nuestro servicio de IA, ya seudonimizado, y no se almacena allí.

Actualizado el 31 de julio de 2026. Dos correcciones, dichas en voz alta y no hechas en silencio. La clase "fecha de nacimiento" se construyó el 31 de julio de 2026; este texto la nombraba antes de que existiera, lo cual era incorrecto y queda rectificado aquí. Abajo se ha añadido un cuarto límite, sobre la referencia del expediente, para que toda clase anclada a su etiqueta se declare como tal y no solo las fechas.

Existe una versión de una herramienta jurídica de IA en la que usted pega los hechos del caso en un campo, el nombre y la dirección del cliente y su número de DNI están ahí en el prompt, y se va todo a un servidor que usted no controla. El proveedor tiene una política de tratamiento de datos. Usted tiene un deber de secreto profesional. Esas dos cosas no son lo mismo, y la distancia entre ellas es donde un despacho se perjudica.

Nosotros no queríamos esa distancia en el producto, así que la cerramos en el punto donde se abre: antes de que el texto se envíe a ningún sitio para su tratamiento por la IA.

Qué ocurre antes de la salida

Cuando usted pide al asistente que redacte, resuma o analice algo sobre un asunto, se ejecuta primero un proceso de seudonimización, en su navegador, antes de que la solicitud se envíe a la IA.

Encuentra los datos personales que reconoce y sustituye cada aparición por un token estable. En un asunto español se cargan quince clases: nombres y apellidos de las partes, domicilio, código postal, fecha de nacimiento, DNI, NIE, CIF, NIF-IVA, número de la Seguridad Social, número de pasaporte, IBAN, tarjeta de pago, correo electrónico, teléfono y el número de procedimiento o expediente: más los importes, si quiere que también salgan. Cada uno de los otros cuatro mercados carga su propia lista con su propio nombre: NI number y NHS number en Inglaterra, PESEL y KRS en Polonia, Steuer-ID y Personalausweisnummer en Alemania, BSN y KvK-nummer en los Países Bajos.

"Estable" importa: la misma persona se convierte en el mismo token en todo el mensaje, de modo que el modelo puede seguir perfectamente que esta parte hizo aquello y le debe esto a aquella otra parte. Razona sobre la forma del caso sin ningún problema. Lo que no ve son los nombres reconocidos vinculados a él.

Cuando llega la respuesta, los tokens se invierten (de nuevo en su navegador) y usted lee el borrador con los nombres reales restablecidos, exactamente donde corresponden. La correspondencia entre token y nombre real se queda de su lado.

Seudonimización, y lo decimos con precisión

Hay aquí una palabra que se usa con ligereza, y usarla con ligereza en un contrato de encargo es la forma más rápida de perder la confianza de un compañero especializado en protección de datos en los primeros cinco minutos.

La anonimización es irreversible. Un dato realmente anonimizado deja de ser dato personal y sale por completo del ámbito del RGPD. No es lo que hace esto. Conservamos una tabla de correspondencia, ese es justamente el propósito, porque gracias a ella el nombre real del cliente vuelve al borrador terminado, de modo que el dato está seudonimizado en el sentido del art. 4.5 RGPD. Sigue siendo dato personal, sigue dentro del ámbito de aplicación y sigue necesitando una base jurídica.

Lo decimos abiertamente porque la versión honesta es la más sólida. Lo que ofrecemos realmente es: una sustitución reversible, ejecutada localmente, en la que la tabla de correspondencia se genera en su navegador, se utiliza en su navegador y nunca se transmite ni a nosotros ni al proveedor del modelo. Es una afirmación más concreta que "anonimizado" y, a diferencia de aquella, resiste una lectura atenta.

Es una respuesta de protección de datos, no de secreto profesional

Conviene separarlas, porque se confunden con facilidad y no deberían.

El secreto profesional cubre la comunicación y el contenido del asesoramiento: no el nombre del cliente. Un escrito sigue amparado por el secreto aunque se tache cada nombre; lo amparado es lo que dice. Eliminar la identidad responde, por tanto, a una cuestión de minimización de datos. No responde a una cuestión de secreto profesional, y no lo presentamos como tal.

La respuesta al secreto es la arquitectura que hay debajo: el expediente reside en su bóveda cifrada y no se nos entrega. Cuando un documento está clasificado como amparado por el secreto, o todavía no está clasificado, la puerta de salida lo retiene por completo frente a la llamada de IA y le indica qué archivos ha retenido. Ese es el plano en el que se responde al art. 542.3 LOPJ y al Estatuto General de la Abogacía, no el de la sustitución de nombres.

Dos controles, dos deberes. La seudonimización es la segunda capa: cubre lo que legítimamente sí sale.

Lo que no hace, dicho en voz alta

Un registro de controles que solo enumera aciertos es un folleto comercial. Cuatro límites, por escrito:

  • Un píxel no es texto. Una captura de pantalla o un documento escaneado adjunto al asunto sale tal cual: el proceso opera sobre texto. El producto avisa en el momento de la carga en lugar de dejarle suponer otra cosa.
  • Las fechas van ancladas a su etiqueta. "Fecha de nacimiento: 14 de mayo de 1974" se tokeniza. Una fecha suelta en mitad de la cronología, no, y es deliberado: reclamar todas las fechas se llevaría por delante la fecha del incumplimiento y el cómputo de la prescripción, destruyendo justo el razonamiento por el que usted paga.
  • El número de una resolución citada no se elimina. El de su procedimiento sí, porque va anclado a la etiqueta. Una resolución publicada que usted cite tiene la misma forma y queda intacta: es derecho público, no un dato de su cliente.
  • Una referencia sin etiqueta tampoco se elimina. La clase se activa con la etiqueta: "n.º de expediente", "n.º de procedimiento", "nuestra referencia", "autos". Una referencia propia del despacho escrita suelta en mitad de la frase sale tal cual. Es la otra cara del mismo canje: sin la etiqueta al lado, la suya no se distingue de la de una resolución citada. Lo dejamos escrito en lugar de que usted lo descubra. En un asunto español son dos las clases que se activan con la etiqueta: la fecha de nacimiento y la referencia del expediente. El registro del anexo al contrato marca las dos. Su propia referencia es, además, un identificador seudónimo: sin su sistema de gestión no significa nada para el proveedor del modelo, y por eso se ordena por debajo de las clases de identificadores, no por encima.

Por qué en el navegador, y no en un servidor

Esta es la parte que es fácil de hacer casi bien y aun así hacer mal.

Muchas herramientas dirán que seudonimizan. La pregunta es dónde. Si la eliminación ocurre en un servidor, entonces los datos sin eliminar llegaron a ese servidor para ser eliminados: lo que significa que llegaron a un servidor ajeno con los nombres todavía dentro, que es exactamente lo que estaba intentando evitar. La seudonimización en servidor protege los registros del proveedor. No protege a su cliente.

Hacerlo en el navegador, antes de la salida, es la única versión que realmente responde al deber. Los identificadores reconocidos no cruzan el cable: nuestro servicio de IA y el proveedor del modelo ven tokens en su lugar. Esa es una decisión de arquitectura, no una configuración, y no es algo que una herramienta basada en la nube pueda añadir a posteriori sin reconstruir su funcionamiento.

Esto se enmarca bajo el principio de minimización de datos del art. 5.1.c RGPD (se envía al modelo lo mínimo que necesita para hacer el trabajo, y quién es el cliente nunca formó parte de eso) y bajo el deber de secreto profesional del abogado conforme al art. 542.3 LOPJ. Pero la razón honesta es más simple que la cita. Si el modelo no necesita saber quién es su cliente para ayudarle a redactar, entonces no debería saberlo. Así que lo construimos para que cada identificador reconocido quede fuera de la solicitud, y dejamos por escrito los que puede pasar por alto.

No es un complemento

Tomamos aquí una decisión deliberada: la seudonimización no es una función premium, una casilla enterrada en la configuración, ni algo que hay que recordar activar. Se ejecuta en todos los planes, en cada llamada, como postura predeterminada del producto. Una protección que hay que habilitar es una protección que algún día se olvidará de habilitar, precisamente en el asunto en que más importaba.

El antes y el después

Antes: el nombre y el número de cuenta del cliente están en el prompt, usted confía en una política de privacidad, y no existe ningún registro de lo que salió del despacho.

Después: los identificadores reconocidos se sustituyen en el navegador, el texto con tokens sale, los nombres regresan de su lado, y los límites del proceso están por escrito, no ocultos.

← Todos los artículos