Anonimización de datos personales: guía RGPD e IA 2026

Cada nómina, contrato, transcripción de exit interview y correo de cliente que tu equipo gestiona contiene datos personales que deben eliminarse antes de que el documento se comparta, se archive o se pase a un modelo de inteligencia artificial. La redacción de datos — la eliminación deliberada de información personal identificable (PII) de los documentos — ya no es una tarea de cumplimiento de nicho. Es la puerta operativa que determina si tu despacho puede usar IA generativa con seguridad, compartir archivos con terceros sin vulnerar el RGPD y sobrevivir a una inspección de la autoridad de control sin producir logs que ojalá no hubieras escrito nunca. La anonimización de documentos y el enmascaramiento de datos son los dos mecanismos prácticos de los que hablaremos; mantenemos esta terminología a lo largo de toda la guía.

Esta es la referencia long-form que nos habría gustado encontrar cuando construimos Redactic. Cubre qué es realmente la redacción de datos y qué no es, cómo la encuadra el RGPD (pseudonimización del artículo 4(5) versus anonimización del Considerando 26), los dos modos operativos que usarás en la práctica, las categorías de PII que deben enmascararse antes de cualquier uso de IA, un workflow de cinco pasos que escala desde un único PDF hasta una hoja de cálculo de nóminas multi-hoja, el riesgo real RGPD del shadow AI dentro de despachos profesionales, una checklist de ocho puntos para elegir una herramienta y una FAQ con las preguntas que los clientes nos hacen cada semana.

Puedes leer el artículo de principio a fin — está escrito para ser escaneable — o saltar a la sección que coincida con tu problema inmediato. Si en tu despacho ya tuvisteis la conversación de "qué hacemos con ChatGPT" y la perdisteis, empieza por la sección de shadow AI. Si tu preocupación son las inspecciones de la AEPD, empieza por el marco RGPD.

1. Qué es la redacción de datos — y qué no es

La redacción de datos es el proceso de identificar información personal o sensible dentro de un documento y eliminarla de la versión que se compartirá, procesará o archivará aguas abajo. El término proviene de la práctica legal de tachar pasajes de expedientes antes de su publicación; en flujos digitales cubre un conjunto mucho más amplio de operaciones, desde sustituir un nombre con un marcador hasta destruir permanentemente una región de una imagen con un ennegrecimiento pixel-perfect.

A menudo se usan "redacción", "anonimización", "pseudonimización", "enmascaramiento", "cifrado" y "borrado" como sinónimos. No lo son, y la diferencia pesa bajo el RGPD. Volveremos a los matices jurídicos en la sección 2; por ahora ten en mente estas distinciones.

• La redacción es la operación paraguas: convertir un documento que contiene PII en una versión que ya no las contiene (o ya no de una forma que atacantes o lectores no autorizados puedan recuperar).
• El enmascaramiento (o enmascaramiento de datos, también llamado máscara de datos) es una técnica: sustituir cada span PII detectado con un marcador como [PERSONA_1] o ⟦NOMBRE⟧. El marcador es significativo para el proceso aguas abajo (por ejemplo un LLM), pero no contiene en sí ningún identificador.
• La pseudonimización es enmascaramiento más una correspondencia de retorno guardada por separado. El RGPD la reconoce explícitamente en el artículo 4(5) y la premia a lo largo del texto, pero no convierte los datos en datos "anónimos".
• La anonimización es unidireccional e irreversible. Después de anonimizar nadie — tú incluido — debería poder re-identificar al sujeto. El RGPD coloca el listón en el Considerando 26 y los datos anónimos quedan fuera del ámbito del reglamento.
• El cifrado es reversible por cualquiera con la clave. Las PII cifradas siguen siendo datos personales bajo RGPD; el cifrado es un control de seguridad, no una técnica de redacción.
• El borrado elimina el documento; la redacción elimina las PII de un documento que se conserva.

La implicación práctica para cualquier equipo que adopte una herramienta de anonimización o software de anonimización PDF es esta: si solo quieres compartir una única versión limpia con un tercero y nunca mirar el original, la anonimización (un ennegrecimiento permanente) es la herramienta correcta. Si quieres dar el documento a un modelo de IA para análisis y leer la respuesta con los nombres reales restaurados, quieres la pseudonimización — es decir, enmascaramiento reversible. La mayoría de los flujos profesionales necesitan ambos, frecuentemente en el mismo documento. Una buena herramienta soporta los dos modos de forma nativa en vez de obligarte a elegir un único camino para toda la pipeline.

El otro anti-patrón que vemos constantemente es tratar la redacción como un paso puntual de pre-compartición. En un despacho multi-usuario con drives compartidos, uso semanal de LLM y subcontratistas externos, la redacción tiene que vivir dentro del workflow — al upload, en el momento de la petición a la IA, al export — no como una revisión mensual a mano de un becario con un rotulador negro.

2. El marco RGPD: artículo 4(5) pseudonimización vs Considerando 26 anonimización

Tres referencias RGPD estructuran toda conversación seria sobre la protección de datos personales mediante redacción en la UE.

El artículo 4 RGPD, apartado 5, define la pseudonimización como "el tratamiento de datos personales de manera tal que ya no puedan atribuirse a un interesado sin utilizar información adicional". La información adicional debe "conservarse por separado y estar sujeta a medidas técnicas y organizativas destinadas a garantizar que los datos personales no se atribuyan a una persona física identificada o identificable". Los datos pseudonimizados siguen siendo datos personales: el RGPD sigue aplicando, sigue haciendo falta base jurídica, y el interesado conserva los derechos de acceso y supresión. Esto es la pseudonimización RGPD en sentido estricto, y se la cita a menudo abreviada como "artículo 4 RGPD".

El Considerando 26 RGPD traza la línea para la anonimización: "los principios de protección de datos no deben aplicarse a la información anónima, es decir, información que no guarda relación con una persona física identificada o identificable, ni a los datos convertidos en anónimos de forma tal que el interesado no sea o ya no pueda ser identificable". Los datos anónimos están fuera de ámbito. El listón es alto y se entiende mejor a través de los tres criterios del Dictamen 05/2014 WP29: singling out (aislamiento), linkability (vinculabilidad), inference (inferencia). Si un documento redactado todavía permite aislar un individuo, vincular registros entre datasets o inferir atributos de una persona específica, has pseudonimizado, no anonimizado. La anonimización RGPD al umbral legal es más rara de lo que el material de marketing sugiere.

El artículo 25 RGPD (Protección de datos desde el diseño y por defecto) y el artículo 32 RGPD (Seguridad del tratamiento) empujan juntos la pseudonimización como medida técnica prudente para tratamientos arriesgados. El art. 32.1.a) la nombra expresamente. Por eso un programa de cumplimiento que ha invertido en una pseudonimización correcta es premiado por las autoridades de control: es un control que el propio reglamento prescribe por nombre.

El AI Act de la UE, en vigor desde 2024 con disposiciones de alto riesgo escalonadas entre 2026 y 2027, añade otra capa. Los sistemas de IA usados para RR. HH. (selección, evaluación del desempeño, decisiones de promoción) se clasifican como de alto riesgo en el Anexo III. Exigen gestión de riesgos, gobernanza de datos, documentación técnica, transparencia, supervisión humana, controles de exactitud/robustez/ciberseguridad y una evaluación de impacto sobre los derechos fundamentales. La RGPD IA, en otras palabras, no son dos normas apiladas; es un único modelo operativo. La inteligencia artificial RGPD, la conformidad IA y la redacción de documentos RGPD pasan en la práctica por el mismo proceso de pseudonimización preventiva, porque satisface a la vez la minimización (art. 5 RGPD) y la gobernanza de datos del AI Act (art. 10).

Un mito que hay que matar: muchos proveedores comercializan su herramienta como "anonimización RGPD" cuando es, de hecho, pseudonimización. Si la correspondencia del marcador al valor original existe en algún sitio — en tu filesystem, en el navegador del usuario, en un servicio que operamos — los datos están pseudonimizados, no son anónimos. La pseudonimización RGPD es una salvaguarda valiosa, y no hay nada de malo en ofrecerla; llamarla anonimización es engañoso y expone al cliente a una trampa de cumplimiento. El certificado de Redactic distingue explícitamente las dos y etiqueta cada job reversible como pseudonimización al amparo del art. 4(5).

La jurisprudencia ha estrechado aún más la línea. En Breyer c. Alemania (C-582/14, 2016) el TJUE estableció que una dirección IP en manos del operador de un sitio web es un dato personal si el operador tiene medios legales razonables para obtener la información identificativa adicional de un tercero. El test de "medios razonables" es más amplio de lo que muchos ingenieros suponen: datos que tu servicio por sí solo no puede identificar pueden seguir siendo personales si una orden judicial o un acuerdo contractual puede aportar las piezas que faltan. Para la redacción esto significa que un split de marcador y correspondencia entre dos organizaciones no es automáticamente anonimización — si una de las partes puede obligar legalmente a la otra a revelar la correspondencia, los datos están pseudonimizados para ambas. La sentencia 2023 SRB c. EDPS (T-557/20) reforzó la naturaleza contextual del test distinguiendo datos pseudonimizados en manos de un destinatario que no puede re-identificar de los mismos datos en manos del responsable que sí puede.

El Dictamen 05/2014 WP29 (hoy adoptado por el EDPB) operacionaliza el Considerando 26 con tres modelos de ataque concretos. Singling out: ¿puede un atacante aislar un registro correspondiente a un individuo? Linkability: ¿pueden dos registros del mismo dataset, o de datasets diferentes, vincularse al mismo individuo? Inference: ¿puede deducirse el valor de un atributo de la combinación de los otros? Si la respuesta a una cualquiera es sí, el documento está pseudonimizado, no anonimizado. La conclusión práctica es que enmascarar el nombre en una hoja de nóminas no la anonimiza — la fila sigue aislando a un único empleado — y que el caso genuinamente anónimo es más raro de lo que los proveedores dejan entrever. El considerando 26 RGPD no es una receta para sentirse seguro; es una vara muy difícil de superar.

3. Los dos modos: reversible (mapa de marcadores) e irreversible (ennegrecimiento)

En producción usarás constantemente dos modos. Entender la diferencia es la diferencia entre un workflow que sobrevive a una inspección y uno que filtra nombres porque usaste la herramienta equivocada para la tarea.

La redacción reversible (pseudonimización) sustituye cada entidad detectada con un marcador estable y guarda una correspondencia separada del marcador al valor original. La correspondencia es lo que hace reversible la operación: pasas el texto enmascarado a un LLM, recibes la respuesta referenciando los marcadores y sustituyes los valores originales en la salida renderizada. El usuario ve los nombres reales; el modelo nunca los vio. Es el único modo que permite anonimizar PDF u ocultar datos PDF y seguir usando la IA de forma útil. El trade-off es que debes proteger la correspondencia. Si se filtra, la pseudonimización queda deshecha para cada registro que cubría.

La reversibilidad tiene dos arquitecturas. Correspondencias del lado cliente: viven en el navegador del usuario y no alcanzan nunca el servidor — el modo más paranoico, útil cuando no se puede confiar en ningún estado del lado del servicio. Correspondencias del lado servidor: viven en un almacén efímero (Redis con TTL corto es el patrón habitual) para permitir al usuario retomar el job desde otro dispositivo. Redactic usa correspondencias efímeras del lado servidor cifradas con Fernet con TTL de 120 segundos sobre el input y 300 segundos sobre el output, más un modo explícito de restauración local en el navegador para los flujos más sensibles. Ambos modos enrutan la petición a IA mediante texto pseudonimizado, así que el proveedor LLM nunca ve las PII originales.

La redacción irreversible (ennegrecimiento) destruye permanentemente la región del documento donde vivían las PII. Censurar un PDF y ennegrecer PDF en este sentido estricto es lo que la mayoría de los reguladores tiene en mente cuando dice "anonimización". En un PDF digital la herramienta retira el contenido textual y superpone un rectángulo negro; en un PDF escaneado o una imagen, la herramienta corre OCR para encontrar las PII y luego pinta sobre los píxeles. No hay correspondencia. La salida es el documento que tu despacho entrega a la contraparte; no hay vuelta atrás. Es el único modo que conviene cuando el objetivo es "este archivo sale del despacho y nunca volveremos a necesitar el original". El ennegrecimiento irreversible es lo más cercano a la anonimización del Considerando 26 a nivel documental, pero sé honesto con los límites: si el documento todavía permite singling-out (una organización pequeña, un rol único, una fecha específica), el estatus jurídico sigue siendo "pseudonimizado de hecho" aunque no haya correspondencia.

El error que vemos más a menudo es el inverso: un despacho ejecuta una pasada de "anonimización" que en realidad es enmascaramiento reversible, comparte el archivo externamente y conserva la correspondencia en un drive compartido al que el destinatario acaba teniendo acceso. Resultado: un registro re-identificable en el servidor de un tercero. Elige el modo en función del destino, no por costumbre.

Redactic expone ambos modos desde el mismo upload: un interruptor de reversibilidad en la pantalla de carga y un botón de confirmación en la ruta irreversible que exige reconocimiento explícito. El modo reversible soporta formatos text-first end-to-end (TXT, DOCX run-preserving, XLSX cell-preserving, Markdown, JSON, CSV, HTML, XML); para PDF la ruta reversible que preserva formato pasa por un intermedio en texto plano, una elección honesta que funciona para flujos de análisis pero no es un PDF reversible real. La verdadera redacción de datos en PDF dentro de Redactic es solo blackout, y se lo decimos a los clientes.

4. Categorías de PII que deben redactarse antes de usar IA

No todo dato personal tiene el mismo peso regulatorio. El RGPD distingue entre "datos personales" (art. 4.1) — todo lo que identifique o pueda identificar a una persona física — y "categorías especiales" (art. 9) como datos de salud, identificadores biométricos, origen racial o étnico, opiniones políticas, convicciones religiosas, afiliación sindical, orientación sexual y datos genéticos. Para las categorías especiales el listón para tratar es mucho más alto (consentimiento explícito, intereses vitales, interés público en salud, etc.) y el riesgo de divulgación involuntaria del lado LLM es proporcionalmente mayor. Los datos personales PDF de estas categorías nunca deben tratarse en claro fuera del entorno controlado.

La tabla siguiente es el checklist operativo que usamos. Antes de que un documento vaya a ChatGPT, Claude, Gemini, Mistral o cualquier otro proveedor LLM, cada entrada debajo debe estar enmascarada con un marcador o ennegrecida, según necesite reversibilidad el workflow.

Categoría	Ejemplos	Por qué importa
Identificadores directos	Nombre completo, email, teléfono, dirección postal	El conjunto mínimo de PII; re-identificación trivial.
Identificadores nacionales	DNI/NIE español, NIR/INSEE francés, Codice Fiscale italiano, Steuer-ID alemán, números de pasaporte UE	A menudo los pierden los modelos entrenados en inglés. Redactic usa GLiNER multilingüe + regex nacionales.
Financieros	IBAN, SWIFT, números de tarjeta, cuenta bancaria, CIF/NIF	Disparan riesgo PCI-DSS adyacente y riesgo de fraude directo.
Empleo	ID de empleado, línea de nómina, fecha de alta, retribución, valoración	Re-identifican dentro de una organización pequeña incluso sin nombre.
Salud (art. 9)	Diagnósticos, medicación, motivos de baja, notas de medicina del trabajo	Categoría especial, requiere consentimiento explícito u otra base del art. 9.
Biométricos / documentos de identidad	Números de DNI, permiso de conducir, pasaporte, fotografías faciales	Categoría especial si se usan para identificación unívoca.
Cuasi-identificadores	Fecha de nacimiento + CP + género, rol+departamento exacto, título raro	Usados en ataques de linkage. Regla de Sweeney al 87 %: CP+DOB+género re-identifica a la mayoría de los adultos en EE. UU.
Divulgaciones en texto libre	Transcripciones de exit interview, reclamaciones de clientes, tickets de soporte	La categoría más difícil. Suele escapar a los redactores basados en patrones y necesita NER ML.

La detección automática de PII en documentos de texto libre es el problema difícil — la parte de la anonimización de documentos que separa un producto real de un wrapper de regex. Las regex capturan IBAN, identificadores fiscales, emails y teléfonos de forma fiable; no capturan los nombres de personas que nunca has oído en tres idiomas sobre un PDF escaneado. Aquí es donde la elección del modelo cuenta. Redactic usa urchade/gliner_multi_pii-v1, un GLiNER multilingüe afinado sobre categorías PII que corre en CPU sin cambio de modelo por idioma. Los documentos se trocean en ventanas de 180 palabras con solapamiento para sortear la truncación de GLiNER a 384 subtokens — detalle sutil pero crítico: sin troceo, un PDF largo pierde toda entidad a partir de la página 2.

Para PDF escaneados e imágenes, la pipeline corre primero Tesseract OCR con el paquete eng+ita+fra+deu+spa para extraer el texto, luego la detección, y luego pinta la redacción sobre los píxeles originales. Así funciona censurar PDF u ocultar datos PDF sobre escaneos — no esperando a que el archivo fuese digital desde el inicio. La calidad sobre escaneos torcidos o rotados varía; Redactic salta páginas muy rotadas y las muestra para revisión manual en lugar de producir una salida "confiadamente errónea".

5. El workflow de cinco pasos que escala

La razón principal por la que los programas de redacción fallan en despachos profesionales es que viven enteramente en la cabeza de un becario: un ritual ad-hoc Word-y-rotulador que no sobrevive a la semana de vacaciones de ese becario. El siguiente workflow es la baseline que recomendamos; es el workflow que Redactic implementa end-to-end y el que hemos auditado contra el principio de accountability del RGPD.

1. Upload. Sube el archivo fuente (PDF, DOCX, XLSX, imagen, texto, CSV, HTML, XML, Markdown). Para flujos multi-documento, agrupa el upload pero mantén el audit trail separado por documento. El upload debe aterrizar en un almacén cifrado efímero, no en un disco que sobreviva a la petición. Redactic almacena inputs en Redis con cifrado Fernet y TTL de 120 segundos.
2. Detección. Corre la cascada: dictionary match exacto (para rosters conocidos como tu lista de clientes), regex nacionales (DNI/NIE español, NIR francés, CF italiano, Steuer-ID alemán, IBAN, email), NER multilingüe (GLiNER multilingüe sobre nombres residuales, organizaciones, lugares) y fallback OCR para escaneos e imágenes. Muestra los spans detectados agrupados por categoría con score de confianza.
3. Revisión. Muestra al usuario cada span con un toggle conservar/redactar. La detección recall-biased sobre-redacta a propósito — los falsos positivos son baratos de corregir, los falsos negativos filtran. Deja que el usuario desmarque spans que no son PII reales (un nombre de marca detectado como persona, un número que parece DNI pero es código de producto) y reejecuta del lado servidor con keep_values. Este paso es innegociable para flujos legales.
4. Aplicación. Elige el modo: reversible (correspondencia del lado cliente o en almacén efímero del servidor) o irreversible (ennegrecimiento). Para la reversible, guarda la correspondencia por separado, cifrada, con TTL corto. Para la irreversible, también limpia los metadatos del documento (/Info PDF + XMP, core-properties DOCX, properties XLSX) — muchos fallos de redacción filtran el nombre del autor desde las propiedades del documento aun con el cuerpo limpio.
5. Compartir o restaurar. Descarga el archivo enmascarado, mándalo a un LLM, compártelo con un tercero. Para flujos reversibles, cuando vuelva la respuesta, restaura los valores originales dentro del navegador del usuario para que los nombres reales no hagan nunca round-trip por el modelo. Para auditoría, genera un certificado de redacción SHA-256 que liste el hash de input, el hash de output, los conteos por categoría, el modo y el timestamp — pero nunca los valores originales. El certificado es el documento que produces si la autoridad de control pregunta cómo se generó una salida dada.

El punto del certificado merece énfasis. Un certificado de redacción es el artefacto que transforma "hemos usado una herramienta de redacción" en "aquí está el registro criptográfico de este job específico". También es el artefacto que prueba que no almacenaste el documento ni sus PII, porque solo contiene hashes y conteos por categoría, no contenido. Redactic genera uno por cada job, descargable en PDF, firmado con la clave de la aplicación.

Un ejemplo concreto: redactar una hoja de nóminas. Supongamos que una asesoría sube un XLSX a 12 hojas con 80 empleados, columnas para nombre, DNI, IBAN, salario bruto, deducciones y notas. Un find-and-replace genérico corrompería las fórmulas de salario; la edición manual con rotulador en Excel llevaría media jornada. El workflow correcto procesa las celdas de cadena de cada hoja mediante librería estructurada (openpyxl en nuestro stack), deja intactas las celdas numéricas y de fórmula, y corre la cascada — dictionary lookup sobre el roster de empleados que la asesoría sube, regex DNI sobre la columna fiscal, regex IBAN sobre la columna bancaria, GLiNER sobre la columna de notas para nombres libres. La pantalla de revisión muestra 240 spans detectados agrupados por columna; el revisor acepta las correspondencias canónicas y rechaza tres falsos positivos (un código de producto que coincidió con el patrón IBAN, dos nombres de organización clasificados como personas). El export es un XLSX con marcadores en las celdas de cadena, fórmulas y celdas numéricas intactas, propiedades del documento vaciadas del nombre del producer. El certificado adjunto registra el SHA-256 de input y output, el conteo por categoría (80 nombres, 80 DNI, 80 IBAN, 14 nombres libres de las notas), el modo (reversible) y el timestamp. Tiempo total: menos de 60 segundos para la detección, menos de tres minutos incluyendo la revisión manual. La correspondencia se mantiene en Redis para el round-trip LLM y se destruye automáticamente al expirar el TTL.

6. Shadow AI: por qué el uso ciego de ChatGPT vulnera el RGPD

La conversación que tenemos más a menudo con clientes empieza así: "Prohibimos ChatGPT para datos sensibles. Luego descubrimos que todo el mundo sigue pegando cosas, desde cuentas personales, en el móvil, fuera de horario". Esto es el shadow AI: el uso de endpoints LLM públicos con datos sensibles, fuera de la visibilidad de IT, normalmente con la mejor intención. Es el riesgo IA dominante dentro de despachos profesionales en 2026.

El shadow AI vulnera el RGPD de tres formas específicas. Primera, el proveedor LLM se convierte en encargado del tratamiento sin Acuerdo de Tratamiento de Datos. El art. 28 requiere un DPA — el art. 28.3 lista las ocho cláusulas mínimas — antes de cualquier tratamiento por cuenta del responsable. Un usuario que pega nombres de clientes en una cuenta ChatGPT personal crea tratamiento sin DPA, sin registro de actividades de tratamiento (art. 30), sin vetting del art. 28, sin cadena de subencargados documentada. El binomio ChatGPT RGPD solo se sostiene si se cambia al tier enterprise con contrato firmado. Segunda, según los defaults del tier consumer del proveedor, el input puede usarse para entrenar el siguiente modelo, creando una divulgación irreversible que el derecho de supresión (art. 17) no puede deshacer. Tercera, las transferencias cruzan la frontera UE hacia un centro de datos de EE. UU. sin que el responsable haya realizado una transfer impact assessment tras Schrems II. La privacidad ChatGPT con defaults consumer no pasa el test; los tiers enterprise sí, pero requieren tanto diligencia de procurement como una capa de redacción delante para ser defendibles.

La respuesta honesta no es "prohíbe más fuerte". Los usuarios bordearán la prohibición cada vez que la herramienta oficial sea más lenta o peor que la consumer. La respuesta es hacer del camino oficial el camino de menor resistencia — un chat IA seguro que enmascara las PII antes de que el mensaje salga del navegador, envía el texto pseudonimizado a un LLM EU-hosted bajo DPA firmado, y restaura los valores reales en la respuesta localmente. Es lo que hace Redactic Secure Chat: las PII se enmascaran en el navegador mediante la misma pipeline de detección que el flujo documental, la petición va a OpenAI, Anthropic, Google o Mistral en sus endpoints UE (zero retention, no entrenamiento sobre el input), y la restauración ocurre del lado cliente para que los valores originales no acaben jamás en un log de servidor.

No es una preocupación teórica. Samsung prohibió ChatGPT y otras herramientas de IA generativa en mayo de 2023 después de que, según se informó, empleados introdujeran en el chatbot información de la empresa, incluido código fuente. La Garante italiana suspendió temporalmente ChatGPT el 30 de marzo de 2023 sobre el art. 6 (base jurídica), art. 13 (informativa) y la falta de verificación de edad; el servicio se restableció el 28 de abril de 2023 solo después de que OpenAI implementara un age gate, un opt-out y una informativa explícita. La Garante emitió decisión final el 20 de diciembre de 2024 con sanción de 15 millones de euros. En paralelo, la AEPD española abrió investigación en abril de 2023, y el EDPB formó una task force dedicada a ChatGPT en abril de 2023 que publicó sus hallazgos preliminares en mayo de 2024. El estudio Cyberhaven 2023 encontró que el 11 % de los prompts ChatGPT corporativos contenían datos sensibles — registros de nómina, código fuente, información de clientes — subidos desde dentro de los firewalls. El AI Act UE añade obligaciones sobre GPAI desde agosto de 2025 que constriñen aún más cómo pueden usarse los endpoints LLM consumer en contextos regulados. Construir una historia de privacidad IA para tu despacho ya no es opcional; es la pre-condición operativa para la adopción IA.

El patrón es coherente en cada incidente: la brecha técnica raramente es sofisticada, la respuesta de policy siempre es reactiva, y el coste lo paga el despacho cuyo becario pegó el contrato en un chatbot gratuito a las 23 horas. La conformidad IA empresarial no es un problema top-down de policy; es un problema bottom-up de UX. Si el camino seguro es más lento, gana el camino inseguro. Redactic Secure Chat es más rápido que ChatGPT en el round-trip "enmascarar-luego-chatear" porque el enmascaramiento ocurre del lado cliente en milisegundos, el modelo responde con latencia normal, y la restauración es local. El usuario no percibe un impuesto de cumplimiento; percibe un flujo más fluido que la alternativa consumer porque las respuestas llegan con los nombres reales ya restaurados, sin limpieza de copia-y-pega.

Al dimensionar el riesgo de shadow AI en su propio despacho, conviene tratar con cautela las estadísticas que circulan: nuestra auditoría de las estadísticas de shadow AI más repetidas rastrea cada cifra hasta su fuente primaria y muestra varias que no miden lo que suele atribuírseles.

7. Elegir una herramienta de redacción: checklist de 8 puntos

Si estás comprando una herramienta o evaluando build interno versus producto de mercado, la siguiente checklist es la que usamos con prospects. Puntúa cada item 0-2 (no / parcial / sí) y pondera los items de postura de privacidad por el doble. Si terminas por debajo de 18 sobre 32 posibles, tienes un riesgo de cumplimiento; por debajo de 12, también un riesgo de productividad.

1. Arquitectura no-trace. ¿Procesa el servicio el documento en memoria y lo descarta de inmediato? ¿Los inputs están cifrados en reposo en el almacén efímero, con TTL corto, y nunca escritos en un log persistente? Por qué importa: una copia conservada sigue siendo dato personal — el propio proceso de redacción se convierte en una actividad de tratamiento separada si el input sobrevive a la petición.
2. Detección PII multilingüe. ¿Maneja el modelo DNI/NIE español, NIR francés, Codice Fiscale italiano, Steuer-ID alemán, PESEL polaco, etc., o solo nombres en inglés y SSN de EE. UU.? Por qué importa: los detectores anglocéntricos pierden el 30-50 % de los identificadores nacionales en documentos UE.
3. OCR para escaneos. ¿Puede la herramienta redactar un PDF escaneado o una foto de DNI con ennegrecimiento pixel-perfect? Por qué importa: los casos que más asustan a tu DPO — contratos antiguos, documentos fotografiados — son justo los que un redactor solo-texto no resuelve.
4. Soporte de dos modos. ¿Puede la herramienta producir salidas reversibles (marcador) e irreversibles (ennegrecimiento) desde el mismo upload? Por qué importa: las herramientas mono-modo obligan a mantener dos pipelines.
5. Revisión manual. ¿Permite la UI a un humano aceptar o rechazar cada span detectado antes de aplicar la redacción? Por qué importa: la detección recall-biased es el default correcto pero produce falsos positivos que necesitan una ruta de revisión rápida.
6. Limpieza de metadatos. ¿Retira la herramienta también las propiedades del documento (autor, last-modified-by, XMP, EXIF)? Por qué importa: la fuga más común en producción es un cuerpo limpio con un nombre de autor en las propiedades del PDF.
7. Certificado de auditoría. ¿Genera la herramienta un registro criptográfico por job de lo procesado, con hashes y conteos por categoría pero sin contenido? Por qué importa: el certificado es lo que muestras a la autoridad de control, al asegurador, al cliente.
8. Postura de cumplimiento. Residencia de datos UE, DPA incluido en el signup, registro de subencargados, consentimiento click-wrap con snapshot criptográfico, separación de roles (tu herramienta como encargado, no responsable). Por qué importa: son los items que determinan si la herramienta encaja en tu programa RGPD existente o crea nuevas actividades de tratamiento que ahora hay que gobernar.

Las herramientas que llegan como extensión Chrome pueden ser elegantes pero puntúan mal en (1) y (8) — pocas veces hay un DPA real detrás de una extensión gratuita. Las librerías open source como Presidio o Piiranha puntúan bien en (2) pero heredas la huella operativa (no-trace, OCR, auditoría, certificado) que es la mayor parte del trabajo. Las herramientas comerciales hospedadas varían; la pregunta no es "¿tienes una funcionalidad llamada redacción?", sino "muéstrame el certificado de un job de muestra y la lista de subencargados".

Build vs buy. El argumento de construirlo en casa suele venir de CTO que observan que GLiNER, Tesseract y la capa de regex nacionales son open source. El argumento tiene razón sobre los componentes y se equivoca sobre el coste total. El trabajo real no es el motor de detección — eso es un prototipo de fin de semana — sino la capa operativa: un almacén efímero cifrado con disciplina de TTL que sobrevive a crashes, una UI de revisión manual que maneja miles de spans sin colgar el navegador, un generador de certificado de redacción que firma con una clave estable, un limpiador de metadatos que maneja las idiosincrasias de cada producer PDF, un workflow DPA con captura de consentimiento click-wrap, un flujo de notificación de cambio de subencargado y el mantenimiento continuo para seguir el paso a nuevos identificadores nacionales, nuevos idiomas OCR, nuevos endpoints LLM. El valor del vendor raramente es el modelo; es la disciplina alrededor del modelo. La software anonimización PDF que cumple esto en serio cuesta más para construir desde cero que para comprar.

Redactic se diseñó contra esta checklist desde el día uno: no-trace by design (Redis cifrado Fernet con TTL 120s/300s, sin modelos de DB, sin logs de contenido), GLiNER multilingüe con fallback de regex nacionales, Tesseract OCR con paquete de cinco idiomas, modos reversible e irreversible, consola de revisión manual, limpiador de metadatos sobre PDF/DOCX/XLSX, certificado SHA-256 de auditoría con PDF descargable, residencia UE en Hetzner Helsinki y Cloudflare R2 jurisdicción UE, DPA firmado en el signup con snapshot de consentimiento click-wrap, y rol explícito de encargado en las páginas trust. El DPA y la lista de subencargados son públicos; la arquitectura está documentada; el certificado de redacción es descargable desde el dashboard para cada job.

Caveats honestos: la redacción reversible para PDF en Redactic pasa por un intermedio en texto plano (el PDF verdadero es blackout-only); la ruta OCR blackout se ha testeado end-to-end en el navegador solo en el despliegue de producción de junio 2026; en casos de nombre multi-forma ("María García" y el parcial "María" más adelante en el documento), la regla del lado servidor de mantenimiento como forma canónica puede dejar una máscara parcial que la UI cliente muestra como conservada. Se lo decimos a los prospects en la primera llamada, no después del contrato.

8. Preguntas frecuentes

¿Cuál es la diferencia entre redacción de datos y anonimización?

La redacción es la operación; la anonimización es uno de los resultados posibles. La redacción puede producir salida pseudonimizada (reversible, RGPD art. 4(5)) o anonimizada (irreversible, Considerando 26). La anonimización saca los datos del ámbito RGPD completamente; la pseudonimización los mantiene dentro pero reduce el riesgo.

¿La pseudonimización es lo mismo que el cifrado?

No. El cifrado es reversible para cualquiera con la clave y es un control de seguridad; la pseudonimización sustituye valores identificativos con marcadores y mantiene la correspondencia de retorno bajo control de acceso más estricto. El RGPD reconoce explícitamente la pseudonimización en el art. 4(5) y art. 32(1)(a); los datos personales cifrados siguen siendo datos personales.

¿Puedo usar ChatGPT con documentos redactados con seguridad bajo RGPD?

Sí, bajo dos condiciones. Primera, la redacción debe ocurrir antes de que el documento salga de tu entorno — enmascarar después del upload a ChatGPT no ayuda. Segunda, el endpoint LLM debería ser idealmente el tier UE/enterprise con DPA firmado y defaults no-train. Un chat IA seguro que enmascara las PII en el navegador antes de la petición y restaura los valores reales en la respuesta localmente es el patrón más limpio.

¿Funciona la detección automática de PII en PDF escaneados?

Solo si la herramienta corre OCR primero. Una herramienta que solo maneja texto digital producirá silenciosamente un escaneo "redactado" con todas las PII intactas. Tesseract con el paquete de idiomas correcto es la ruta open-source estándar; el OCR comercial cloud existe pero introduce un subencargado que necesita su propio DPA. Redactic corre Tesseract en el worker con el paquete eng+ita+fra+deu+spa. Si buscabas "anonimizar PDF" o "censurar PDF" esperando una solución de un solo clic, la respuesta honesta es que los escaneos necesitan OCR antes de cualquier enmascaramiento — y la calidad del OCR limita la calidad de la redacción.

¿Cuánto debe conservarse la correspondencia de marcadores?

El tiempo estrictamente necesario para el workflow. Para un round-trip LLM la correspondencia se necesita solo entre la petición y la respuesta — minutos, no días. Redactic usa 120 segundos en el almacén input y 300 segundos en el almacén output. Para un expediente multi-documento la correspondencia puede tener que vivir durante el caso, en cuyo caso debe cifrarse en reposo, registrarse los accesos y listarse explícitamente en tu registro de actividades de tratamiento.

¿Qué es el shadow AI y por qué es un problema RGPD?

El shadow AI es el uso de endpoints LLM públicos con datos sensibles, fuera de la visibilidad de IT, normalmente vía cuentas personales. Crea tratamiento sin DPA (art. 28), transferencias internacionales no documentadas (Schrems II) y posible exposición a entrenamiento del input. La mitigación no es una prohibición más estricta — las prohibiciones se bordean — sino un camino oficial más rápido y seguro que el shadow.

¿El AI Act cambia algo sobre la redacción?

Sí. Los sistemas IA de alto riesgo bajo el Anexo III (RR. HH., selección, evaluación del desempeño) deben cumplir obligaciones de gobernanza de datos (art. 10), gestión de riesgos (art. 9), supervisión humana (art. 14). Pseudonimizar los datos de input antes de dárselos a tal sistema es la forma más limpia de satisfacer simultáneamente la minimización bajo art. 5 RGPD y el art. 10 AI Act. El AI Act no exige explícitamente la redacción pero la premia operativamente.

¿Qué es un certificado de redacción y por qué lo necesito?

Un registro criptográfico de un job de redacción: hash de input, hash de output, modo, conteos de redacción por categoría, timestamp, firma aplicativa. No contiene contenido ni PII, así que es seguro de almacenar y compartir. Lo necesitas para demostrar la accountability del art. 5(2) — que puedes mostrar cómo se generó una salida dada meses después, sin conservar el documento.

¿Puedo redactar una hoja Excel con datos de empleados sin romper las fórmulas?

Sí si la herramienta entiende la diferencia entre una celda de cadena y una celda de número/fórmula. El find-and-replace genérico rompe las fórmulas. Redactic procesa las celdas de cadena por hoja vía openpyxl dejando intactos números, fórmulas y formato — es el workflow que usamos para ficheros de nóminas multi-empleado y el que el reciente trabajo multi-hoja sobre redacción por columna está refinando.

¿Dónde almacena mis datos Redactic?

En ningún sitio persistente. Los documentos viven en Redis con cifrado Fernet y TTL corto durante el job, y son destruidos por el bloque finally del worker independientemente del resultado. La aplicación no tiene un modelo DB para contenido de documento. El certificado de redacción almacena solo hashes y conteos. Compute y almacén de metadatos son UE (Hetzner Helsinki + Cloudflare R2 jurisdicción UE). La lista de subencargados y el DPA son públicos en las páginas trust.

Si lees solo una cosa de esta guía, lee la sección 6 sobre shadow AI. El mayor riesgo individual en tu despacho en 2026 no es una redacción manual mal hecha; es el efecto acumulado de mil pequeños copia-y-pega en ChatGPT desde cuentas personales. La respuesta no son reglas más estrictas — se bordearán — sino un camino oficial más rápido con redacción correcta y un DPA firmado. Construye el camino antes de que el regulador lo construya por ti.

Si quieres ver cómo funciona en la práctica, la landing de Redactic recorre los cuatro modos de uso (Redactar, Anonimizar, Usar con IA, Chatbot seguro) con una demo en vivo sobre un contrato de ejemplo. El plan Solo cubre a un profesional individual a 19 €/mes; el plan Firm añade el chat IA seguro y hasta cincuenta puestos a 49 €/mes; Enterprise es a medida. El DPA se firma en el signup y el certificado de redacción es descargable desde cada job completado.