Bases de Datos Protección de Datos 23 jun 2026 · 10 min de lectura

Anonimización de datos con PostgreSQL: lo que su empresa necesita implementar antes de diciembre

La Ley 21.719 exige medidas técnicas para proteger datos personales. La anonimización es una de las más efectivas. En este artículo revisamos técnicas concretas en PostgreSQL que puede implementar hoy mismo.

Contenido

1. La ley exige medidas técnicas: ¿dónde entra la anonimización?
2. Anonimización vs. seudonimización: la diferencia legal importa
3. Por dónde empezar: inventario de datos personales
4. Técnicas SQL para anonimizar datos en PostgreSQL
5. Automatización con funciones y disparadores
6. Extensiones y herramientas disponibles
7. Casos de uso: entornos de desarrollo, análisis y testing
8. Errores comunes al anonimizar datos
9. Cómo puede ayudar Lanedu

1. La ley exige medidas técnicas: ¿dónde entra la anonimización?

La Ley 21.719 (que analizamos en detalle en nuestro artículo anterior) exige que las organizaciones implementen medidas técnicas y organizativas apropiadas para proteger los datos personales. El artículo 12 de la ley es claro: el responsable debe adoptar las medidas necesarias para garantizar la seguridad y confidencialidad de los datos.

Una de esas medidas es la anonimización: transformar datos personales de forma irreversible para que no puedan asociarse a una persona identificada o identificable. Cuando los datos están verdaderamente anonimizados, dejan de ser "datos personales" a los ojos de la ley, y por lo tanto quedan fuera del alcance de la normativa.

¿Qué significa esto en la práctica? Que si su organización usa datos reales de clientes para pruebas de software, análisis internos o capacitación, está tratando datos personales sin las garantías que exige la ley. La anonimización le permite seguir operando sin el riesgo de una multa o una filtración.

⚠️ Dato clave

Los datos anonimizados no están sujetos a la Ley 21.719. Los datos seudonimizados sí lo están. La diferencia no es solo técnica, es legal.

2. Anonimización vs. seudonimización: la diferencia legal importa

Antes de escribir una línea de SQL, hay que entender la diferencia porque determina cómo trata la ley los datos resultantes:

	Anonimización	Seudonimización
Reversibilidad	Irreversible	Reversible con clave adicional
Aplica la ley	No	Sí
Ejemplo	Reemplazar RUT con un hash irreversible	Reemplazar RUT con un token y guardar el mapeo por separado
Riesgo	Bajo (no se puede reidentificar)	Moderado (depende de la protección del mapeo)

En la práctica, la seudonimización es útil cuando necesita conservar la trazabilidad (por ejemplo, para auditorías internas), mientras que la anonimización es la opción correcta para datos que se usarán en analytics, testing o desarrollo, donde no se necesita volver al dato original.

3. Por dónde empezar: inventario de datos personales

Antes de anonimizar, hay que saber qué datos personales existen y dónde están. La Ley 21.719 exige llevar un Registro de Actividades de Tratamiento que debe incluir:

• Qué datos personales se recolectan y procesan.
• En qué bases de datos, tablas y columnas están almacenados.
• Quiénes tienen acceso y con qué propósito.
• Qué medidas de protección existen (o deberían existir).

En PostgreSQL, puede comenzar identificando tablas y columnas con datos sensibles:

-- Identificar columnas que podrían contener datos personales
SELECT
  table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
  AND (column_name ILIKE '%rut%'
    OR column_name ILIKE '%email%'
    OR column_name ILIKE '%nombre%'
    OR column_name ILIKE '%telefono%'
    OR column_name ILIKE '%direccion%'
    OR column_name ILIKE '%fecha_nacimiento%');
        

Una consulta como esta es solo el punto de partida. Un inventario completo requiere revisar también la lógica de la aplicación, los archivos de log y los backups.

4. Técnicas SQL para anonimizar datos en PostgreSQL

A continuación, técnicas prácticas que puede aplicar directamente sobre sus tablas. Recomendamos probarlas en un entorno de staging antes de aplicarlas en producción.

4.1. Enmascaramiento de correos electrónicos

Reemplazar el nombre local del correo con un valor genérico o aleatorio, conservando el dominio:

-- Opción 1: Reemplazar con un patrón fijo
UPDATE clientes
SET email = 'cliente-' || id || '@' || split_part(email, '@', 2);

-- Resultado: juan.perez@gmail.com → cliente-123@gmail.com

-- Opción 2: Usar md5 para un hash irreversible
UPDATE clientes
SET email = md5(email) || '@anonimizado.local';

-- Resultado: juan.perez@gmail.com → d41d8cd98f00b204e9800998ecf8427e@anonimizado.local
          

La opción 2 es más segura porque es irreversible. La opción 1 conserva el dominio real (útil si necesita probar envíos de correo), pero es seudonimización, no anonimización.

4.2. Enmascaramiento de nombres

Para nombres se puede usar una combinación de iniciales y valores genéricos:

-- Reemplazar nombres con iniciales y un apellido genérico
UPDATE clientes
SET nombre = concat(
    left(nombre, 1), '.*** ',
    left(split_part(nombre, ' ', 2), 1), '.***'
);

-- Resultado: Juan Pérez → J.*** P.***

-- Opción más segura: reemplazar completamente
UPDATE clientes
SET nombre = 'Usuario-' || id;
          

La primera opción conserva iniciales (seudonimización), útil si necesita mantener alguna referencia. La segunda es anonimización pura.

4.3. Enmascaramiento de RUT (Chile)

El RUT es un identificador único especialmente sensible. Debe tratarse con cuidado:

-- Opción 1: Hash irreversible
UPDATE clientes
SET rut = encode(
    sha256(convert_to(rut, 'UTF8')),
    'hex'
);

-- Resultado: 12.345.678-9 → a8f5f167f44f4964e6c998d13ddf3a9c...

-- Opción 2: Valor genérico con ID secuencial
UPDATE clientes
SET rut = '99.999.999-' || lpad((id % 9 + 1)::text, 1, '0');

-- Resultado: 99.999.999-K
          

SHA-256 es irreversible y genera un valor único por RUT (mismo RUT produce mismo hash), lo que permite detectar duplicados sin revelar el original.

4.4. Generalización de fechas

Reemplazar fechas exactas por rangos o períodos más amplios:

-- Reemplazar fecha exacta por solo año y mes
UPDATE clientes
SET fecha_nacimiento = date_trunc('month', fecha_nacimiento) + interval '1 month - 1 day';

-- 1998-05-12 → 1998-05-31

-- Opción más agresiva: solo año
UPDATE clientes
SET fecha_nacimiento = date_trunc('year', fecha_nacimiento);
          

Útil para análisis demográficos donde la fecha exacta no es necesaria, pero el año o mes sí.

4.5. Perturbación de valores numéricos

Para montos, sueldos o valores numéricos, agregar ruido estadístico:

-- Agregar ruido aleatorio de ±10%
UPDATE empleados
SET sueldo = round(sueldo * (1 + (random() - 0.5) * 0.2));

-- Reemplazar con valor por rango
UPDATE empleados
SET sueldo = CASE
    WHEN sueldo < 500000 THEN floor(random() * (500000-300000+1) + 300000)
    WHEN sueldo < 1000000 THEN floor(random() * (1000000-800000+1) + 800000)
    ELSE floor(random() * (3000000-1500000+1) + 1500000)
END;
          

La segunda opción preserva distribuciones de ingresos sin revelar valores exactos.

4.6. Crear un duplicado anonimizado de una tabla

Para entornos de testing, es útil crear una copia anonimizada de la tabla original:

CREATE TABLE clientes_test AS
SELECT
    id,
    'Cliente-' || id AS nombre,
    md5(email) || '@test.local' AS email,
    '99.999.999-' || lpad((id % 9 + 1)::text, 1, '0') AS rut,
    date_trunc('month', fecha_nacimiento) AS fecha_nacimiento,
    telefono, -- sin anonimizar por ahora
    fecha_registro
FROM clientes;
          

Este enfoque crea un conjunto de datos funcional para desarrollo sin exponer datos reales.

5. Automatización con funciones y disparadores

Para que la anonimización sea sostenible en el tiempo, conviene automatizarla con funciones y disparadores (triggers) de PostgreSQL:

-- Función que anonimiza un registro antes de insertarlo en una tabla de log/auditoría
CREATE OR REPLACE FUNCTION anonimizar_cliente()
RETURNS TRIGGER AS $$
BEGIN
    NEW.email := md5(NEW.email) || '@anonimo.local';
    NEW.nombre := 'Usuario-' || NEW.id;
    NEW.rut := encode(sha256(convert_to(NEW.rut, 'UTF8')), 'hex');
    NEW.telefono := '+569XXXXXXXX';
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Aplicar el trigger en cada inserción a la tabla de auditoría
CREATE TRIGGER anonimizar_auditoria
BEFORE INSERT ON auditoria_clientes
FOR EACH ROW
EXECUTE FUNCTION anonimizar_cliente();
        

También puede crear una vista anonimizada para que los equipos de análisis accedan a datos sin ver los valores reales:

CREATE VIEW clientes_anonimo AS
SELECT
    id,
    'Cliente-' || id AS nombre,
    md5(email) || '@anonimo.local' AS email,
    encode(sha256(convert_to(rut, 'UTF8')), 'hex') AS rut,
    date_trunc('year', fecha_nacimiento) AS fecha_nacimiento,
    round(sueldo * (1 + (random() - 0.5) * 0.2)) AS sueldo
FROM clientes;
        

Con esta vista, los analistas pueden consultar datos sin acceder nunca a la tabla real. Es una capa de seguridad adicional que funciona incluso si alguien tiene permisos de lectura sobre la vista.

6. Extensiones y herramientas disponibles

PostgreSQL cuenta con extensiones que facilitan la anonimización a escala:

pg_anonymize

Extensión que permite definir reglas de anonimización por columna. Soporta masking, generalización, perturbación y más. Se configura mediante funciones SQL y se puede integrar con el motor de reglas de la base de datos.

anon (PostgreSQL Anonymizer)

Extensión open-source que declara reglas de anonimización directamente en las tablas usando comentarios. Soporta masking dinámico, estático, y generación de datos sintéticos. Es la más completa del ecosistema PostgreSQL.

Data masking nativo (PostgreSQL 17+)

Las versiones recientes de PostgreSQL incluyen mejoras en seguridad a nivel de fila (RLS) y columnas que pueden usarse como base para masking. No es tan completo como las extensiones, pero para casos simples puede ser suficiente.

La elección de la herramienta depende del volumen de datos, la complejidad de las reglas y si necesita anonimización estática (transformar datos en reposo) o dinámica (enmascarar en tiempo real según el usuario).

7. Casos de uso: entornos de desarrollo, análisis y testing

Estos son los escenarios más comunes donde la anonimización marca la diferencia:

💻 Desarrollo

Los developers necesitan datos realistas pero no reales. Una copia anonimizada de la BD de producción evita filtraciones en entornos de desarrollo.

📊 Analítica

Los equipos de BI pueden trabajar con datos anonimizados que conserven propiedades estadísticas sin exponer a personas reales.

🧪 Testing

Las pruebas automatizadas requieren datasets consistentes. Datos anonimizados permiten tests repetibles sin riesgo legal.

🎓 Capacitación

Cursos y talleres con datos reales de clientes. Con anonimización, los alumnos aprenden con datos que parecen reales pero no lo son.

🔍 Demos comerciales

Mostrar el producto a prospectos con datos que simulan su industria sin exponer información de clientes reales.

8. Errores comunes al anonimizar datos

Estos son los errores que vemos más seguido cuando las organizaciones intentan anonimizar por su cuenta:

❌

Cifrar no es anonimizar

El cifrado es reversible. Si alguien obtiene la clave, recupera los datos originales. La anonimización debe ser irreversible.

❌

No revisar reidentificación por combinación de datos

Aunque anonimice columnas individuales, la combinación de varias puede reidentificar a una persona (código postal + fecha de nacimiento + género identifica al 87% de las personas en EE.UU., según estudios).

❌

No revisar backlogs, logs ni backups

Si anonimiza la BD pero los datos originales siguen en logs de aplicación, backups antiguos o archivos CSV, la anonimización no sirve de nada.

❌

Aplicar el mismo hash a todos los entornos

Si su BD de desarrollo y producción usan el mismo hash, un developer con acceso a ambas puede cruzar datos y reidentificar registros.

9. Cómo puede ayudar Lanedu

En Lanedu no solo escribimos sobre estas técnicas: las implementamos a diario para nuestros clientes. Contamos con experiencia práctica en PostgreSQL, adecuación normativa y seguridad de datos.

🔍 Diagnóstico de datos personales

Identificamos qué datos tiene, dónde están y qué medidas necesita.

🗃️ Implementación de anonimización

Configuramos extensiones, escribimos funciones y automatizamos el proceso en PostgreSQL.

🛡️ Seguridad en bases de datos

Cifrado, control de acceso, RLS, backups cifrados y monitoreo en PostgreSQL, MySQL y SQL Server.

📋 Registro de actividades de tratamiento

Creamos el inventario de datos que exige la Ley 21.719 y lo mantenemos actualizado.

🐳 Infraestructura para entornos seguros

Diseñamos pipelines de CI/CD que separan datos reales de anonimizados en contenedores Docker.

🎓 Capacitación para equipos

Formamos a sus desarrolladores y administradores de BD en técnicas de anonimización y seguridad.

Solicitar diagnóstico gratuito

Cristian López

Consultor en protección de datos e infraestructura · Lanedu

Este artículo fue elaborado con base en la experiencia práctica de Lanedu en administración de bases de datos PostgreSQL y procesos de adecuación a la Ley 21.719. Para consultas específicas sobre tu organización, no dudes en contactarnos.

Ley 21.719: guía completa Volver al blog