Entrega un fichero a alguien que nunca debería ver los datos personales que hay dentro, y asegúrate de que no puede. Cuando sacas un trozo de producción a un CSV para que un proveedor reproduzca un bug, o mandas un lote de tickets a un equipo de analítica externalizado, los nombres, los emails y los números de cuenta no están en columnas ordenadas. Viven dentro de las líneas de log y de los cuerpos de los tickets como texto libre. Puedes limpiar un fichero de texto ahora sin cuenta: súbelo, marca las categorías a quitar y descarga un .txt plano que puedes comparar con el original.
Dónde se esconden de verdad los datos personales
En una hoja de cálculo sabes qué columna tiene el email. En un volcado de logs o un export de tickets no: el apellido del cliente aparece a mitad de frase, el teléfono está incrustado en una traza de error, el número de tarjeta lo pegó en una nota un agente con prisa. Eso es lo que hace tan fugable al texto en bloque. Borrar los valores a mano en miles de filas es lento, y un fallo es una brecha, así que el trabajo tiene que ser mecánico.
Sube el fichero y elige entre las categorías que el pipeline sabe encontrar:
- Nombres de personas, incluso cuando aparecen a mitad de línea.
- Emails y teléfonos, en sus formatos internacionales habituales.
- Números de tarjeta (PAN), reconocidos por su estructura y verificados antes de eliminarlos.
- IBAN y datos bancarios, validados por su dígito de control integrado.
- Documentos de identidad —DNI, NIF, NIE, CIF y similares— detectados por su carácter de control.
- Direcciones postales que fijan un registro a un lugar.
Todo lo que ya conoces —un código interno de caso, el nombre de un proyecto, un handle concreto— va a una deny-list y se elimina en la misma pasada.
Eliminación validada, no una corazonada
Las categorías que más dolerían si se escapara un valor real son precisamente las que el pipeline se niega a adivinar. Una tira de dieciséis dígitos solo se trata como tarjeta si satisface el algoritmo de Luhn, así que un PAN auténtico se elimina mientras un número de pedido de la misma longitud queda intacto. Un IBAN solo se reescribe si su resto mod-97 es correcto. Los DNI/NIF/NIE/CIF españoles se validan por su letra de control, y los teléfonos por su patrón nacional. Como estas pruebas son aritméticas, funcionan igual sea cual sea el idioma del texto de alrededor: a un identificador estructurado le da igual que la frase a su alrededor esté en alemán o en portugués.
Los IDs estructurados viajan entre idiomas; los nombres no
El detector de nombres se apoya en modelos de español e inglés, así que los nombres de persona en texto alemán, francés e italiano se encuentran solo parcialmente. Sé honesto contigo mismo con eso: añade a la deny-list los apellidos que conozcas y repasa esos ficheros. Tarjetas, IBAN, emails, teléfonos e identificadores con dígito de control son agnósticos del idioma y no necesitan esa reserva.
Editar a mano frente a una pasada determinista
- Un buscar-y-reemplazar se salta la fila escrita de otra forma
- Cada persona que revisa quita un conjunto distinto
- No queda registro de qué se quitó, ni de dónde
- Un solo valor que se pasa por alto es una fuga
- Cada fragmento de una categoría elegida se localiza en una pasada
- La misma entrada produce la misma salida, pasada tras pasada
- Eliminar, enmascarar con
*o sustituir por<ENTITY>— tú decides - El registro de auditoría guarda desplazamientos, nunca el valor
La salida es un .txt plano, así que puedes compararlo con el origen mediante un diff y ver por ti mismo que cada fragmento detectado ha desaparecido: eliminado hasta no dejar nada, enmascarado con una tira de asteriscos, o sustituido por un marcador tipado. El estilo que elijas se aplica igual en todo el fichero. Y el rastro de auditoría registra solo dónde estaba cada fragmento —su inicio y su fin— nunca los caracteres que había, de modo que ni el propio log puede filtrar lo que quitó.
La minimización de datos es el punto legal
El artículo 5.1.c del RGPD hace vinculante la minimización: los datos personales deben limitarse a lo necesario. Un proveedor que depura una consulta, o una máquina de staging que corre una batería de tests, no necesita identidades reales, así que por el principio no debería recibirlas. El artículo 4.5 traza la línea que de verdad te importa: los registros seudonimizados todavía se pueden rastrear, mientras que eliminar los identificadores del todo empuja el fichero hacia la anonimización y fuera de ese riesgo. Entregar un export en bruto a un tercero, o copiar datos vivos a un entorno no productivo, es justo donde miran los reguladores. Quitar la PII antes es la forma más barata de quedarte del lado correcto de esa línea, y esta herramienta procesa texto y devuelve texto: no marca visualmente un PDF, no pixela una cara ni pita un audio, que son trabajos aparte con sus propias herramientas.
Limpia un fichero ahora
Sube el .txt, .docx o PDF, elige las categorías y el estilo de reescritura, confirma el precio y descarga la copia limpia. La detección encuentra los fragmentos; el código determinista los reescribe, así que el resultado es idéntico en cada pasada. Sin cuenta, paga solo por lo que limpias.
Cuándo lo necesitas
Un ingeniero tiene que entregar un fichero a alguien que nunca debería ver los datos personales que hay dentro. Puede ser un export de la base de datos de producción volcado a un CSV para que un proveedor reproduzca un bug, un lote de tickets de soporte que va a un equipo de analítica externalizado, o un trozo de logs de la aplicación que se convertirá en fixtures de test de un entorno de staging. El fichero es texto libre, así que los nombres de clientes, los emails, los teléfonos, los DNI, los IBAN y algún número de tarjeta no están en columnas etiquetadas: están desperdigados por las líneas de log y los cuerpos de los tickets. Borrarlos a mano en miles de filas es propenso a errores, y un valor que se escapa es una fuga. Sube el fichero, elige las categorías a eliminar y cada fragmento que sea un nombre, un email, un teléfono, una tarjeta, un IBAN o un identificador se localiza y se reescribe de forma determinista, de modo que el .txt que entregas conserva la estructura y ninguna de las personas.
El ángulo de cumplimiento
El artículo 5.1.c del RGPD convierte la minimización de datos en un principio vinculante: los datos personales deben limitarse a lo necesario, y un proveedor que depura una consulta o una máquina de staging que corre tests no necesita identidades reales. El artículo 4.5 traza la línea que de verdad te importa: la seudonimización todavía permite reidentificar un registro, mientras que eliminar los identificadores del todo lleva el fichero hacia la anonimización y fuera de ese riesgo. Compartir un export en bruto con un tercero o copiar datos vivos a un entorno no productivo es justo donde miran los reguladores; eliminar la PII antes es la forma más barata de quedarte del lado correcto de esa línea.
Lo que puedes comprobar
El resultado es un .txt plano que puedes comparar con el original mediante un diff. Cada fragmento detectado desaparece: eliminado hasta no dejar nada, enmascarado con una tira de asteriscos, o sustituido por un marcador tipado como <PERSON> o <IBAN_CODE> —tú eliges, y se aplica igual en cada pasada—. Las categorías arriesgadas se validan, no se adivinan: una cadena de dieciséis dígitos solo se elimina si pasa el checksum de Luhn, un IBAN solo si su dígito de control mod-97 cuadra, así que los números de tarjeta reales se van y un número de pedido cualquiera se queda. El registro de auditoría guarda solo desplazamientos de carácter —inicio y fin— nunca el valor que estaba ahí.
Preguntas frecuentes
- ¿Qué tipos de fichero puedo subir y qué recibo de vuelta?
- Sube un `.txt` de texto plano, un `.docx` de Word o un PDF. Se extrae el texto, se localizan y reescriben las categorías que hayas elegido y recibes un `.txt` limpio que puedes comparar con el original mediante un diff. Es un trabajo de fichero-entra, fichero-sale: un único fichero de texto para todo el lote de filas, no un formulario por registro.
- ¿Qué diferencia hay entre eliminar, enmascarar con asteriscos y sustituir por <ENTITY>?
- Eliminar borra el fragmento y no deja nada donde estaba el valor. Enmascarar conserva la longitud escribiendo una tira de asteriscos encima. Sustituir cambia el valor por un marcador tipado como `<PERSON>` o `<IBAN_CODE>`, que mantiene la línea legible y le muestra a quien revisa qué tipo de dato había ahí. Eliges un estilo y se aplica igual a cada fragmento detectado del fichero.
- ¿Detecta de forma fiable números de tarjeta, IBAN y DNI, o marcará dígitos al azar?
- Las categorías arriesgadas se validan, no se adivinan. Una cadena de dieciséis dígitos solo se trata como tarjeta si pasa el algoritmo de Luhn, así que un PAN real se va y un número de pedido de la misma longitud se queda. Un IBAN solo se elimina si su dígito de control mod-97 cuadra, y los DNI/NIF/NIE/CIF españoles se validan por su carácter de control. Como son comprobaciones aritméticas, se comportan igual sea cual sea el idioma alrededor.
- ¿Funciona con texto en alemán, francés o italiano, o solo en inglés y español?
- Los identificadores estructurados —tarjetas, IBAN, emails, teléfonos, documentos con dígito de control— son agnósticos del idioma y funcionan en todas partes. Los nombres de persona son otra cosa: el modelo de nombres se apoya en español e inglés, así que los nombres en texto alemán, francés e italiano se detectan solo parcialmente. Para esos ficheros añade a la deny-list los apellidos que conozcas y repasa la salida.
- Una vez eliminado un valor, ¿se puede recuperar el texto original del fichero de salida?
- No. Los caracteres detectados se reescriben fuera del propio fichero —borrados, enmascarados o sustituidos— y se escribe un `.txt` nuevo. No hay capa oculta debajo ni metadatos que guarden el texto previo. El registro de auditoría conserva solo desplazamientos de carácter, el inicio y el fin de cada fragmento, nunca el valor que había, de modo que nada en la salida se puede revertir al original.