🧬Clasificar y anonimizar PII en WordPress: guía práctica de retención de datos

Tu base de datos de WordPress está llena de información personal que nadie etiquetó como tal.

El email del cliente que compró hace tres años y no volvió. La dirección de envío con el piso y el apartamento. El comentario del pedido donde alguien escribió su DNI "por si hay problema con el envío". La IP del comentario del blog de 2021. El nombre de usuario que coincide con el nombre real de la persona.

Todo eso es PII —Personally Identifiable Information, información personal identificable—. Y si tu política de retención dice "conservamos los datos el tiempo necesario", estás incumpliendo la ley y aumentando tu superficie de daño en caso de brecha.

Este artículo te da el mapa: cómo clasificar qué es PII en un WordPress típico, cuánto tiempo deberías retener cada categoría, y cuál de las cuatro técnicas de anonimización aplica en cada escenario. Es la base para una política de privacidad que aguante una auditoría y reduzca tu riesgo real.

Qué es PII y qué no, en un WordPress real

La definición legal suena abstracta. La operativa es concreta: PII es cualquier dato que, solo o combinado con otros, permite identificar a una persona física. Y el combinado con otros es la trampa donde muchos ecommerce caen.

PII directa

Identifica sin necesidad de cruzar con nada más:

• Nombre completo + apellido. En un wp_usermeta o en wp_postmeta de un pedido.
• Email. Identificador más común en WordPress; aparece en wp_users, en pedidos, en comentarios, en suscripciones a newsletter.
• Teléfono. Campo estándar de WooCommerce Checkout.
• DNI, cédula, RFC, CPF, RUT y cualquier identificador nacional.
• Dirección postal completa (calle + número + ciudad + código postal).
• Número de tarjeta de crédito. Técnicamente no debería vivir en tu base si usás una pasarela tokenizada, pero sí vive el últimos 4 dígitos.

PII indirecta (quasi-identificadores)

Por sí solos no identifican, pero combinados sí:

• Fecha de nacimiento.
• Código postal.
• Género + edad + ciudad. El estudio clásico de Sweeney demostró que el 87% de la población de EE.UU. es identificable únicamente con esos tres campos.
• Dirección IP.
• User-Agent del navegador + resolución de pantalla + timezone. Fingerprint pasivo.
• Historial de compras. Lo que comprás revela más de lo que pensás.

El error típico es tratar los quasi-identificadores como datos "no personales" porque no llevan nombre. Bajo GDPR y las leyes LATAM modernas, si la combinación permite re-identificar, es PII.

PII sensible (categorías especiales)

Tienen protección reforzada y en varios países requieren consentimiento expreso adicional:

• Datos de salud (relevante si vendés productos médicos o suplementos con indicaciones).
• Orientación sexual, ideología política, afiliación religiosa.
• Datos biométricos (huellas, reconocimiento facial, voz).
• Datos genéticos.
• Datos de menores de edad.
• Antecedentes penales.

Si tu ecommerce toca cualquiera de estas categorías, la regla es: minimizar agresivamente, cifrar a nivel de columna, y documentar una base legal específica para cada procesamiento.

Los siete puntos de WordPress donde la PII se acumula

Un WordPress con WooCommerce, un plugin de membresías y un formulario de contacto acumula PII en siete lugares que casi nadie audita.

1. wp_users y wp_usermeta. Email, nombre, apellido, teléfono en billing_phone, direcciones en billing_address_1 y shipping_address_1, DNI si usás un plugin LATAM.

2. Pedidos de WooCommerce (wp_posts tipo shop_order, wp_postmeta). Copia completa de la dirección de facturación y envío en el momento de la compra, método de pago, últimos 4 dígitos de tarjeta, notas del cliente, notas internas del admin que a veces contienen PII cruzada.

3. Comentarios del blog (wp_comments). Email del comentarista, IP, User-Agent, nombre (que puede ser real).

4. Logs del servidor. Access logs de nginx/Apache guardan IP, User-Agent, referer y a veces parámetros de URL con PII (un ?email=cliente@dominio.com).

5. Logs de plugins. WooCommerce logs, logs de WP Mail SMTP que guardan el body de los emails enviados, logs de plugins de seguridad que registran intentos de login fallidos con el usuario intentado.

6. Backups. Cada backup es una copia completa de todo lo anterior. Un backup de hace dos años puede contener datos de personas que ya ejercieron su derecho al olvido.

7. Exportaciones CSV y reportes. Lo que sale del admin a un CSV se convierte en una copia no controlada. Contabilidad, marketing, soporte —todos exportan y nadie borra.

Clasificación: el inventario que te falta

Antes de anonimizar o retener, necesitás saber qué tenés y dónde. El ejercicio es incómodo la primera vez y ridículamente útil todas las siguientes.

Armá una tabla con cinco columnas por cada campo que contenga PII:

• Ubicación. Tabla + columna, o archivo + campo.
• Categoría. Directa, indirecta, sensible.
• Base legal. Consentimiento, contrato, obligación legal, interés legítimo.
• Plazo de retención. En meses o años.
• Técnica al expirar el plazo. Anonimizar, seudonimizar, eliminar.

Te va a sorprender cuántos campos no tienen base legal clara. Ese es el primer riesgo que tenés que cerrar: si no podés justificar por qué guardás algo, no deberías guardarlo.

Retención: un plazo por categoría, no uno para todo

"Conservamos sus datos el tiempo que sea necesario" no es una política de retención. Es una confesión de que no pensaste el tema.

Una política real tiene plazos diferenciados por categoría. Estos son los que suelen defenderse en LATAM:

| Categoría | Plazo típico | Base | |-----------|--------------|------| | Datos de facturación (nombre, RFC/CUIT, dirección fiscal) | 5-10 años | Obligación contable/tributaria | | Pedidos con datos de envío | Plazo del producto + garantía + 2 años | Contrato + obligación fiscal | | Cuentas de cliente inactivas | 24-36 meses | Interés legítimo + consentimiento tácito | | Marketing (suscripción a newsletter) | Hasta que el titular revoque | Consentimiento | | Comentarios del blog | Vida útil del contenido publicado | Interés legítimo/contrato | | IPs en logs de acceso | 6-12 meses | Seguridad | | Intentos de login fallidos | 90 días | Seguridad | | Backups completos | Plazo del dato más largo que contengan | Continuidad operativa |

Los plazos de arriba son orientativos. El ejercicio real es mapear tu propia operación contra la regulación que te aplica y documentar la lógica. Un plazo defensable tiene tres ingredientes: base legal explícita, proporcionalidad al propósito y mecanismo automático de expiración.

El último punto es donde fallan la mayoría de los ecommerce. Definen plazos en el papel y no hay ningún cron que los aplique. La política sirve de nada si la base sigue creciendo indefinidamente.

Las cuatro técnicas de anonimización

Cuando un dato cumple su plazo de retención y no hay base legal para seguir reteniéndolo, hay cuatro caminos. Cada uno tiene sentido en un contexto distinto.

1. Hashing con sal

Aplicás una función hash criptográfica (SHA-256, Argon2) al dato, junto con una sal secreta. El resultado es un valor fijo que parece random.

• Reversibilidad. Teóricamente irreversible. En la práctica, reversible por fuerza bruta si el espacio de entradas es pequeño (emails, teléfonos).
• Cuándo usar. Cuando necesitás mantener la capacidad de verificar igualdad ("¿este email ya se registró?") sin almacenar el email original. Con sal única por contexto, previene ataques de rainbow table.
• Cuándo no. No uses hashing simple para emails sin sal. Tampoco lo uses como sustituto de anonimización si la ley exige irreversibilidad: seguís teniendo seudonimización.

Ejemplo operativo: en vez de guardar cliente@dominio.com en un log de analytics, guardás sha256(cliente@dominio.com + sal_específica_de_analytics). Podés agrupar eventos por cliente sin saber quién es, y si te roban el log no tienen los emails originales.

2. Tokenización

Reemplazás el dato original con un token aleatorio. La relación token-dato se guarda en un vault separado con acceso muy restringido.

• Reversibilidad. Reversible solo con acceso al vault.
• Cuándo usar. Cuando el sistema operacional necesita un identificador estable pero no necesita el dato real. Clásico en pasarelas de pago: la pasarela guarda la tarjeta, vos guardás tok_abc123.
• Cuándo no. No tokenices si tu "vault" vive en la misma base que los datos operacionales. El valor de la tokenización es la separación.

Ejemplo operativo: en lugar de guardar el número de DNI en wp_usermeta, guardás user_token_7f8a9b y mantenés la relación en un servicio separado al que solo accede el proceso de validación.

3. Generalización

Reemplazás el dato específico por un rango o categoría más amplia que ya no identifica.

• Reversibilidad. Parcialmente reversible (podés adivinar el rango pero no el valor exacto).
• Cuándo usar. Para análisis y reportes donde necesitás estadísticas agregadas. Edad 34 → rango 30-39. Código postal 03100 → primera mitad 031xx. Fecha de compra 2026-04-17 → mes 2026-04.
• Cuándo no. Cuando el análisis requiere precisión individual (cálculo de comisiones, facturación).

Ejemplo operativo: tu reporte mensual de marketing no necesita saber que Pedro compró el martes a las 14:07. Necesita saber "X ventas en martes de abril, rango 12:00-18:00". La granularidad extra es riesgo sin beneficio.

4. Supresión (borrado selectivo)

Eliminás campos específicos o filas completas. Es el camino más honesto cuando el dato ya no tiene propósito.

• Reversibilidad. Irreversible (si lo hacés bien, incluyendo backups).
• Cuándo usar. Al expirar el plazo de retención sin obligación de conservación, al ejecutar un derecho al olvido, al detectar que estás guardando campos que nunca deberían haberse recolectado.
• Cuándo no. Cuando tenés obligación legal de conservar (datos fiscales antes de cumplir el plazo contable). En ese caso, acotá el acceso y dejá que expire naturalmente.

Ejemplo operativo: un cliente que ejerce derecho al olvido y no tiene facturas pendientes → borrado de wp_users, wp_usermeta, anonimización de pedidos antiguos (mantener el pedido para estadísticas, reemplazar email y nombre por [anonimizado]), purga del backup en el siguiente ciclo.

Errores típicos al anonimizar WordPress

La teoría es clara. La implementación es donde la mayoría se tropieza.

Borrar solo de wp_users y creer que terminaste. WordPress guarda el email y nombre del cliente copiado en wp_postmeta de cada pedido, en wp_comments, en logs de plugins, en CSV exportados. Borrar wp_users sin tocar el resto deja la PII intacta en cinco lugares.

Confiar en el "anonymizer" de WordPress por defecto. El wp_privacy_anonymize_data() core solo maneja emails y IPs. No toca nombres en campos personalizados, no toca comentarios embebidos, no toca metadatos de plugins. Sirve como punto de partida, no como solución completa.

Anonimizar pedidos históricos sin preservar datos fiscales. Si ya tenés la factura emitida con el nombre del cliente, no podés simplemente borrar el nombre del pedido: rompés la trazabilidad. Anonimizá el registro operacional (el pedido en WooCommerce) pero mantené el registro contable (la factura) con los datos fiscales hasta cumplir el plazo legal.

No anonimizar backups. Los datos anonimizados en producción siguen en el backup de hace 6 meses. Si te roban ese backup, la anonimización sirve de nada. La política debe incluir rotación de backups con purga efectiva.

Usar el mismo hash sin sal en varios contextos. Si hasheás emails con la misma fórmula en analytics, CRM y logs, cualquier filtración en uno te compromete los tres. Sal por contexto.

Olvidar los campos libres. Notas de pedido, comentarios internos del admin, descripciones de tickets de soporte. Ahí se acumula PII cruzada que ningún campo estructurado captura. Tratalos como texto libre sensible y aplicales la misma retención que al pedido.

Minimización: la técnica más barata

La mejor anonimización es la que no necesitás porque nunca recolectaste el dato.

Antes de agregar un campo al checkout, al formulario de contacto o al onboarding, preguntate tres cosas:

1. ¿Lo necesito para cumplir el contrato con el cliente? Si no, ¿cuál es la base legal?
2. ¿Lo necesito hoy, o "por si acaso en el futuro"? El por si acaso no es base legal.
3. ¿Qué pasa el día que me roben esta columna? Si la respuesta es "me arruinan", reconsiderá si debe existir.

Un ejemplo típico: el campo "fecha de nacimiento" en el checkout. Si no vendés productos con restricción de edad, no lo necesitás. Si lo necesitás, ¿por qué guardás el día y mes exactos? Guardá año de nacimiento o rango etario. Menos dato = menos riesgo, menos cumplimiento, menos problemas.

Cómo armar el ciclo operativo

Una política de clasificación y retención no es un documento que archivás. Es un ciclo con cuatro pasos que corre siempre.

Descubrir. Auditoría inicial del inventario. Qué campos tenés, dónde, en qué formato. Repetir al agregar cada plugin nuevo.

Clasificar. Asignar categoría (directa/indirecta/sensible) y base legal a cada campo. El resultado es una tabla viva que evoluciona con el producto.

Retener. Aplicar el plazo definido con automatización. Un cron que corre mensual y marca para anonimización todo lo que cumplió su plazo, o un worker que procesa expiraciones diarias.

Anonimizar o eliminar. Ejecutar la técnica que corresponde (hash, token, generalización, supresión) con cobertura de todos los puntos: producción, logs, backups, exportaciones.

Cada paso deja rastro auditable. Si mañana te auditan, tenés que poder demostrar: qué se recolectó, con qué base, cuándo expiró, qué se hizo al expirar. Sin logs de esas acciones, no hay cumplimiento.

Cierre

Los datos personales no son neutros. Cada byte que guardás más tiempo del necesario es un byte más de riesgo si te roban la base, si hay un empleado interno malicioso, si tu proveedor de hosting tiene un incidente. La única PII totalmente segura es la que nunca recolectaste. La segunda más segura es la que borraste a tiempo.

Clasificar, retener y anonimizar no son tareas legales sueltas que tercerizás al abogado. Son ingeniería de datos aplicada a tu WordPress, con decisiones concretas: qué hasheás, qué tokenizás, qué generalizás, qué suprimís, y cuándo.

La próxima brecha de PII la va a tener alguien. Que no sea la tuya —y si lo es, que sea la mínima posible porque ya hacés este trabajo todos los días.