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 nada abandone su navegador.

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 máquina, en el navegador, antes de que se envíe un solo byte a ningún sitio.

Encuentra los datos personales 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. Simplemente nunca llega a conocer los nombres 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. El texto sin seudonimizar nunca existió en ningún lugar que no fuera su propia máquina.

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 máquina y no sale de ella. 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 abandonaron su máquina 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 datos identificativos no cruzan el cable en absoluto. 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 de manera que no pueda.

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 se eliminan en el navegador, el texto con tokens sale, los nombres regresan localmente, y el servicio externo nunca llega a saber quién es el cliente.

← Todos los artículos