Por qué el mapa de reemplazos va cifrado: seudonimización y la «información adicional» del art. 4.5

3 de noviembre de 2026 · 8 min de lectura

Anonimizar es irreversible por defecto: no guarda nada que permita volver a los datos reales. Pero tiene una opción, el mapa de reemplazos, que dice quién es cada PERSONA_01 y permite revertir el cambio; es lo que hace posible el flujo anonimizar → IA → rehidratar. Desde la versión 1.1.4 (3 de noviembre de 2026), ese mapa se guarda siempre cifrado con una contraseña de 12 caracteres o más, y ya no se puede guardar en claro. Esta nota explica por qué.

El origen: el informe de un DPO

Un DPO que trabaja con nosotros como partner revisó la app y nos mandó un informe con una observación precisa. Con el mapa activado, el resultado no es una anonimización sino una seudonimización, en el sentido del art. 4.5 del RGPD. Y el mapa es exactamente lo que ese artículo llama «información adicional»: la que permite atribuir los datos a una persona y que, según la definición, tiene que figurar por separado y estar sujeta a medidas técnicas y organizativas que impidan esa atribución.

Hasta ese momento, el mapa salía como un CSV (o un Word) con CONFIDENCIAL en el nombre. El informe lo resumía así: un archivo en claro con un nombre que avisa que es confidencial es una medida organizativa (le dice a una persona cómo tratarlo), no una medida técnica (no impide que lo lea quien lo encuentre). Tenía razón, y lo cambiamos.

Con mapa, el resultado es una seudonimización

La diferencia entre las dos cosas no es de nombre. Un documento seudonimizado sigue conteniendo datos personales: mientras alguien tenga el mapa, puede volver a saber de quién se habla. Un documento anonimizado no permite identificar a nadie por ningún medio razonable. El RGPD aplica entero a lo primero y no a lo segundo.

Para quien trabaja en Argentina o en otro país de Latinoamérica el razonamiento es el mismo aunque cambien las palabras: la Ley 25.326 no habla de seudonimización sino de disociación, y un documento cuya tabla de correspondencias sigue existiendo no está disociado. Todo esto (art. 4.5, considerando 26, la AEPD, el TJUE y la Ley 25.326) está desarrollado en anonimización vs. seudonimización; acá nos concentramos en el mapa.

Sin mapa tampoco es automáticamente anónimo. No guardar el mapa saca de en medio la forma directa de revertir, pero que el resultado sea anónimo depende además de que no queden datos a la vista ni combinaciones que identifiquen a alguien («la única jefa de contabilidad, de 47 años»). La app detecta identificadores y patrones; no evalúa combinaciones, y su detección no es infalible. La revisión humana antes de compartir sigue siendo parte del método.

Cómo se guarda el mapa ahora

Al activar el mapa, la app pide elegir una contraseña y guarda el mapa en un archivo aparte, …MAPA-CONFIDENCIAL.anonmap, junto a la salida. Por dentro:

Cifrado AES-256-GCM. Es un cifrado autenticado: además de ocultar el contenido, detecta si alguien modificó el archivo. Un mapa alterado no abre.
La clave sale de la contraseña con scrypt, una función de derivación deliberadamente lenta y que exige memoria (unos 128 MiB por intento), con una sal aleatoria distinta en cada archivo. La sal hace que dos mapas con la misma contraseña no se parezcan y que no sirvan tablas precalculadas.
No hay modo sin contraseña. No existe una casilla para «guardarlo en claro igual».
Anonimizar no guarda la contraseña en ningún lado y no hay forma de recuperarla. Si se pierde, el documento no se puede revertir. La app lo explica y pide confirmarlo antes de activar el mapa.
Revertir pide la contraseña. Si es incorrecta o si el archivo fue alterado, el mensaje es el mismo: no se dan pistas sobre cuál de las dos cosas falló.

Todo esto ocurre en el equipo, sin conexión: ni el mapa ni la contraseña pasan por ningún servidor nuestro, porque no lo hay.

Por qué 12 caracteres, y por qué conviene una frase

La pregunta razonable es por qué tanto, si muchos servicios en línea piden menos. La diferencia está en cómo se ataca cada cosa:

Una contraseña de un servicio en línea se prueba contra un servidor, que bloquea después de unos pocos intentos fallidos.
Un archivo cifrado se puede copiar y atacar sin conexión y sin límite de intentos. Nadie bloquea nada: quien tenga el archivo puede probar contraseñas durante meses con el equipo que quiera.

Contra ese ataque protegen dos cosas, y se multiplican entre sí: el costo de cada intento (por eso scrypt, que hace que cada prueba cueste tiempo y memoria; para quien escribe la contraseña correcta es una fracción de segundo, para quien prueba millones es ese mismo costo millones de veces) y la cantidad de contraseñas posibles, que crece con el largo de forma exponencial.

Una idea del crecimiento, con letras minúsculas elegidas al azar: con 8 caracteres hay 26⁸ ≈ 2,1 × 10¹¹ combinaciones; con 12, 26¹² ≈ 9,5 × 10¹⁶. Cuatro caracteres más multiplican el trabajo del atacante por 26⁴, unas 457.000 veces. Cada carácter extra lo vuelve a multiplicar.

El problema es que las personas no eligen letras al azar: eligen palabras, fechas y patrones, que son lo primero que prueba un atacante. Por eso la app sugiere una frase de 4 o 5 palabras elegidas al azar (con espacios, si se quiere): es fácil de recordar y es larga. Como referencia, si cada palabra sale al azar de una lista de 7.776 (el tamaño de las listas tipo «Diceware», que se eligen tirando dados), 4 palabras dan unas 3,7 × 10¹⁵ combinaciones y 5 palabras unas 2,8 × 10¹⁹. Esos números valen solo si las palabras son realmente al azar: una frase célebre o un verso conocido no cuentan.

La política, en concreto

Mínimo 12 caracteres, sin máximo. Se aceptan espacios y frases.
Sin reglas de complejidad del tipo «una mayúscula, un número y un símbolo»: no se exigen.
Se rechazan las obvias: un mismo carácter repetido, secuencias como 123456…, qwerty… o abcdef…, y palabras como «contraseña», «password», «confidencial» o «anonimizar» repetidas o con números al final.

Tomamos como referencia la guía NIST SP 800-63B (revisión 4), que prioriza el largo por sobre las reglas de complejidad, pide aceptar espacios, no poner un tope corto y rechazar contraseñas conocidas o predecibles. Esa guía está pensada para iniciar sesión en sistemas y, cuando la contraseña es el único factor, pide 15 caracteres; nuestro mínimo es 12 y la recomendación de 4 o 5 palabras queda, en la práctica, bastante por encima de ese largo.

Qué más cambió en la app

La app lo dice. Al activar el mapa, explica que el resultado es una seudonimización (se puede revertir y los datos siguen siendo personales) y pide confirmar.
La salida se llama distinto: con el mapa activado, el archivo resultante lleva .seudonimizado en el nombre, el encabezado del documento ya no dice «irreversible» y el indicador de la app muestra «Seudonimización (mapa ON)».
La ficha de auditoría ya no guarda valores originales, tampoco con el mapa activado. Antes, con el mapa, salía una ficha en claro con los datos reales; ahora el único lugar donde están es el mapa cifrado.
Los textos no dependen del RGPD. La explicación de la app sirve para usuarios de Latinoamérica: el art. 4.5 aparece entre paréntesis, como referencia de la UE.

Qué hacer con los mapas viejos en CSV o Word

Los mapas generados con versiones anteriores se siguen pudiendo usar para Revertir: no queríamos dejar a nadie sin poder recuperar un trabajo en curso. La app los abre, pero avisa que están sin protección. La recomendación práctica:

Actualizar a la 1.1.4. Cómo hacerlo, paso a paso: cómo actualizar la app.
Buscar los mapas viejos (los archivos con MAPA-CONFIDENCIAL en el nombre que sean CSV o Word) en las carpetas de trabajo, y también en copias de seguridad, carpetas sincronizadas y adjuntos de correo.
Para los que todavía hacen falta: volver a procesar el documento original con el mapa activado, para obtener un mapa cifrado nuevo, y después borrar el viejo.
Para los que ya no hacen falta: borrarlos. Un mapa que no se va a usar no protege a nadie y sigue permitiendo revertir.

Lo que el cifrado no resuelve

El cifrado es la medida técnica que el art. 4.5 pide para la información adicional, y Anonimizar la aplica sin que haya que configurar nada. Eso ayuda a cumplir, pero no reemplaza el resto:

La contraseña es la llave. Si se guarda en una nota junto al mapa, o se manda por el mismo correo, el cifrado deja de servir. Conviene guardarla en un gestor de contraseñas y decidir quién del despacho la conoce. Esa es la parte organizativa, y es del despacho.
Cifrar no es anonimizar. Con el mapa y su contraseña, los datos siguen siendo personales para el despacho, con todas las obligaciones que eso implica. Si no hace falta volver a los datos reales (publicar una sentencia, compartir un modelo), lo indicado es no activar el mapa.
La responsabilidad del tratamiento sigue siendo del despacho. En la UE, el art. 32 del RGPD menciona la seudonimización y el cifrado entre las medidas de seguridad posibles; en Argentina, el art. 9 de la Ley 25.326 pide medidas técnicas y organizativas que garanticen la seguridad y confidencialidad de los datos. Una herramienta aporta una pieza; la evaluación de riesgos, el registro y las decisiones las toma el responsable.

Para un DPO que necesite el detalle técnico (qué hace la app, qué conexiones abre, cómo se guarda el mapa y cómo se mapea cada punto al RGPD), está el dossier de seguridad.

Irreversible por defecto. Reversible, y cifrado, solo si lo elegís.

Anonimizar trabaja 100% en tu equipo, sin nube ni telemetría, con revisión humana de cada dato antes de exportar. Desde la 1.1.4, el mapa para volver a los datos reales sale cifrado con tu contraseña. Si ya la tenés instalada, actualizala a la 1.1.4.

Probala gratis · 15 archivos

Para seguir: el flujo completo con IA está en ¿Podés usar ChatGPT con datos de tus clientes? y en IA para abogados sin romper el secreto profesional; si sos DPO y tenés que autorizar el uso de IA, mirá el checklist para el DPO.

Este artículo es informativo y no constituye asesoramiento legal. Las referencias al RGPD, a la Ley 25.326 y a la guía del NIST son un resumen general: conviene consultar el texto vigente y las obligaciones que aplican en cada jurisdicción. El uso de la herramienta no implica por sí solo el cumplimiento de ninguna norma.

Anonimizar is irreversible by default: it keeps nothing that would let you get back to the real data. But it has an option, the replacement map, that records who each PERSONA_01 is and lets you reverse the change; it's what makes the anonymize → AI → re-hydrate flow possible. Since version 1.1.4 (November 3, 2026), that map is always encrypted with a password of 12 characters or more, and it can no longer be saved in plain text. This article explains why.

Where it came from: a DPO's report

A DPO who works with us as a partner reviewed the app and sent us a report with a precise observation. With the map turned on, the result isn't anonymisation but pseudonymisation, in the sense of Article 4(5) of the GDPR. And the map is exactly what that article calls "additional information": the information that allows the data to be attributed to a person and that, under the definition, must be kept separately and be subject to technical and organisational measures that prevent that attribution.

Until then, the map came out as a CSV (or Word) file with CONFIDENCIAL in its name. The report put it like this: a plain-text file whose name warns that it's confidential is an organisational measure (it tells a person how to handle it), not a technical one (it doesn't stop whoever finds it from reading it). It was right, and we changed it.

With a map, the result is pseudonymisation

The difference isn't just a label. A pseudonymised document still contains personal data: as long as someone holds the map, they can find out who it's about. An anonymised document can't identify anyone by any reasonable means. The GDPR applies in full to the first and not to the second.

For users in Argentina or elsewhere in Latin America the reasoning is the same even if the words change: Law 25.326 doesn't speak of pseudonymisation but of dissociation, and a document whose correspondence table still exists isn't dissociated. All of this (Art. 4(5), Recital 26, the Spanish DPA, the CJEU and Law 25.326) is covered in anonymization vs. pseudonymization; here we focus on the map.

No map doesn't automatically mean anonymous either. Not saving the map removes the direct way to reverse the change, but whether the result is anonymous also depends on no data being left in plain sight and no combinations that identify someone ("the only head of accounting, aged 47"). The app detects identifiers and patterns; it doesn't assess combinations, and its detection isn't infallible. Human review before sharing is still part of the method.

How the map is saved now

When you turn the map on, the app asks you to choose a password and saves the map in a separate file, …MAPA-CONFIDENCIAL.anonmap, next to the output. Inside:

AES-256-GCM encryption. It's authenticated encryption: besides hiding the content, it detects whether someone modified the file. A tampered map won't open.
The key is derived from the password with scrypt, a deliberately slow, memory-hungry function (about 128 MiB per attempt), with a random salt that's different for every file. The salt means two maps with the same password don't look alike and precomputed tables are useless.
There's no password-free mode. There's no checkbox to "save it in plain text anyway".
Anonimizar doesn't store the password anywhere and there's no way to recover it. If it's lost, the document can't be reversed. The app explains this and asks you to confirm before turning the map on.
Reversing asks for the password. A wrong password and a tampered file give the same message: no hints about which of the two failed.

All of this happens on your machine, offline: neither the map nor the password goes through any server of ours, because there isn't one.

Why 12 characters, and why a passphrase helps

The fair question is why so many, when plenty of online services ask for fewer. The difference is in how each one gets attacked:

An online account password is tried against a server, which locks you out after a few failed attempts.
An encrypted file can be copied and attacked offline, with no limit on attempts. Nobody locks anything: whoever has the file can try passwords for months, on whatever hardware they like.

Two things protect against that attack, and they multiply: the cost of each attempt (hence scrypt, which makes every guess cost time and memory; for whoever types the right password it's a fraction of a second, for someone trying millions it's that same cost millions of times) and the number of possible passwords, which grows exponentially with length.

To get a sense of the growth, with lowercase letters chosen at random: 8 characters give 26⁸ ≈ 2.1 × 10¹¹ combinations; 12 give 26¹² ≈ 9.5 × 10¹⁶. Four more characters multiply the attacker's work by 26⁴, about 457,000 times. Every extra character multiplies it again.

The catch is that people don't pick random letters: they pick words, dates and patterns, which are the first thing an attacker tries. That's why the app suggests a passphrase of 4 or 5 words chosen at random (with spaces, if you like): easy to remember and long. For reference, if each word is drawn at random from a list of 7,776 (the size of "Diceware"-style lists, picked by rolling dice), 4 words give about 3.7 × 10¹⁵ combinations and 5 words about 2.8 × 10¹⁹. Those figures only hold if the words really are random: a famous quote or a well-known line of verse doesn't count.

The policy, specifically

At least 12 characters, no maximum. Spaces and phrases are accepted.
No complexity rules like "one uppercase letter, one number and one symbol": they aren't required.
Obvious ones are rejected: a single repeated character, sequences like 123456…, qwerty… or abcdef…, and words like "contraseña", "password", "confidencial" or "anonimizar" repeated or followed by numbers.

Our reference is NIST SP 800-63B (revision 4), which puts length ahead of complexity rules, asks to accept spaces, not to impose a short cap and to reject known or predictable passwords. That guidance is written for logging into systems and, when the password is the only factor, asks for 15 characters; our minimum is 12, and the recommended 4 or 5 words land, in practice, well above that length.

What else changed in the app

The app says so. When you turn the map on, it explains that the result is pseudonymisation (it can be reversed and the data is still personal) and asks you to confirm.
The output is named differently: with the map on, the resulting file carries .seudonimizado in its name, the document header no longer says "irreversible" and the app's indicator shows "Seudonimización (mapa ON)".
The audit record no longer keeps original values, not even with the map on. Before, with the map, a plain-text record with the real data was saved; now the only place they live is the encrypted map.
The wording doesn't depend on the GDPR. The app's explanation works for Latin American users: Art. 4(5) appears in parentheses, as the EU reference.

What to do with old CSV or Word maps

Maps generated with earlier versions can still be used to Reverse: we didn't want to leave anyone unable to recover work in progress. The app opens them but warns that they're unprotected. The practical recommendation:

Update to 1.1.4. Step by step: how to update the app.
Find the old maps (files with MAPA-CONFIDENCIAL in the name that are CSV or Word) in your working folders, and also in backups, synced folders and email attachments.
For the ones you still need: process the original document again with the map on, to get a new encrypted map, and then delete the old one.
For the ones you don't: delete them. A map nobody will use protects no one and still allows reversal.

What encryption doesn't solve

Encryption is the technical measure Art. 4(5) asks for the additional information, and Anonimizar applies it without any setup. That helps you comply, but it doesn't replace the rest:

The password is the key. If it's kept in a note next to the map, or sent in the same email, encryption stops helping. Keep it in a password manager and decide who at the firm knows it. That's the organisational part, and it belongs to the firm.
Encryption isn't anonymisation. With the map and its password, the data is still personal data for the firm, with all the obligations that implies. If you don't need to get back to the real data (publishing a ruling, sharing a template), the right call is not to turn the map on.
Responsibility for the processing stays with the firm. In the EU, Art. 32 of the GDPR lists pseudonymisation and encryption among possible security measures; in Argentina, Art. 9 of Law 25.326 requires technical and organisational measures that ensure the security and confidentiality of the data. A tool provides one piece; the risk assessment, the records and the decisions belong to the controller.

For a DPO who needs the technical detail (what the app does, which connections it opens, how the map is stored and how each point maps to the GDPR), there's our security dossier (in Spanish).

Irreversible by default. Reversible, and encrypted, only if you choose.

Anonimizar runs 100% on your machine, no cloud, no telemetry, with human review of every item before exporting. Since 1.1.4, the map that gets you back to the real data is encrypted with your password. If you already have it installed, update to 1.1.4.

Try it free · 15 files

Further reading: the full AI flow is in Can you use ChatGPT with your clients' data? and AI for lawyers without breaking professional secrecy; if you're a DPO who has to authorise AI use, see the DPO checklist.

This article is informational and does not constitute legal advice. References to the GDPR, Law 25.326 and the NIST guidance are a general summary: check the current text and the obligations that apply in each jurisdiction. Using the tool does not, by itself, mean compliance with any regulation.