Datos de prueba y la Ley 21.719

La copia de producción que nadie cuestiona

En muchos equipos, el ambiente de pruebas se llena con una copia de producción. Es cómodo: los datos son reales, los casos raros están ahí, nadie tiene que inventar nada. También significa que nombres, RUT, direcciones y compras de clientes reales viven en un ambiente con menos controles, al que acceden más personas y herramientas.

La Ley 21.719 de protección de datos personales tiene como fecha legal de vigencia el 1 de diciembre de 2026; en octubre de 2026 la comisión de Constitución del Senado aprobó en general postergarla un año, pero el proyecto sigue en trámite. Con cualquiera de las dos fechas, la copia de producción en pruebas pasa a ser un riesgo legal para la empresa, no solo una mala práctica.

Tres técnicas, tres niveles de riesgo

Anonimizar. Transformar los datos de forma que no se pueda volver a identificar a la persona, ni siquiera con información adicional. Es lo más seguro y lo más difícil de lograr de verdad: combinaciones de datos aparentemente inocentes (comuna, fecha de nacimiento, género) pueden identificar a alguien.

Seudonimizar. Reemplazar los identificadores por códigos, guardando aparte la forma de volver al original. Reduce el riesgo, pero con esa información adicional se puede volver a la persona, así que conviene seguir tratándolo como dato personal y proteger la tabla de equivalencias.

Datos sintéticos. Generar datos que nunca pertenecieron a nadie: nombres ficticios, RUT válidos generados, montos y fechas plausibles. Es la opción más limpia para casos nuevos y para todo lo que se vaya a pegar en una herramienta de IA.

La trampa: la integridad referencial

Enmascarar una tabla es fácil; enmascarar una base es otra cosa. El RUT del cliente aparece en clientes, en pedidos, en pagos y en el log de auditoría. Si se enmascara distinto en cada tabla, los pedidos dejan de calzar con su cliente y las pruebas de ETL fallan por razones falsas. Si se olvida una tabla, el dato real sigue ahí.

La regla: el mismo valor original se convierte siempre en el mismo valor enmascarado, en todas las tablas. Una forma simple es una tabla de mapeo que se construye una vez por refresco:

-- Un mapeo consistente: cada RUT real recibe un RUT de prueba, siempre el mismo.
CREATE TABLE mapa_rut AS
SELECT DISTINCT rut AS rut_original,
       'PRUEBA-' || ROW_NUMBER() OVER (ORDER BY rut) AS rut_prueba
FROM clientes;

UPDATE pedidos p SET rut_cliente = m.rut_prueba
FROM mapa_rut m WHERE p.rut_cliente = m.rut_original;

UPDATE clientes c SET rut = m.rut_prueba
FROM mapa_rut m WHERE c.rut = m.rut_original;

-- El mapa es la llave de vuelta: se borra al terminar.
DROP TABLE mapa_rut;

Si el sistema valida el dígito verificador, el rut_prueba tiene que ser un RUT válido generado, no un texto: el generador de datos de prueba del sitio produce RUT con módulo 11 correcto.

Verificar que no quedó nada

El enmascaramiento también se prueba. Tres consultas que deberían devolver cero filas:

-- 1. Ningún RUT del ambiente de pruebas existe en el respaldo de origen.
SELECT COUNT(*) FROM clientes c
WHERE c.rut IN (SELECT rut FROM origen_clientes);

-- 2. Todos los correos usan el dominio reservado para pruebas.
SELECT COUNT(*) FROM clientes WHERE email NOT LIKE '%@ejemplo.cl';

-- 3. Ningún pedido quedó huérfano después del enmascaramiento.
SELECT COUNT(*) FROM pedidos p
LEFT JOIN clientes c ON c.rut = p.rut_cliente
WHERE c.rut IS NULL;

La tercera es la que más se olvida: comprueba que el enmascaramiento no rompió la integridad que el ETL necesita.

Automatizado o no existe

Un procedimiento de enmascaramiento que se corre a mano, alguna vez se olvida. Va como un paso más del refresco del ambiente, con sus consultas de verificación al final: si alguna devuelve filas, el ambiente no se entrega.

Y una última regla, que viene de la política de IA del equipo: nada de lo que salga de producción se pega en una herramienta de IA externa, aunque esté "casi" anonimizado. Para eso están los datos sintéticos.

Cierre del curso

Recorriste el arco completo del testing de datos: qué es un ETL, validar extracción, transformaciones, cuadres, calidad, monitoreo automatizado y datos de prueba que no exponen a nadie. Es lo que hace un QA de datos en banca, retail o fintech, un perfil escaso y bien pagado.

Combínalo con el curso de SQL, que le da la base, y con QA con IA para generar y mantener estos checks más rápido.

Comprueba lo aprendido en el quiz y escribe tu procedimiento de enmascaramiento en el reto final.