Clasificar y anonimizar PII en WordPress: guía práctica de retención de datos | Drokio Blog | Drokio
PrivacidadPIIanonimizaciónretención de datos
🧬Clasificar y anonimizar PII en WordPress: guía práctica de retención de datos
Cómo etiquetar qué datos son PII en tu WordPress, cuánto tiempo deberías retenerlos y qué técnica de anonimización aplica en cada caso. Hashing, tokenización, generalización y supresión, con ejemplos reales de WooCommerce.
Otura··10 min de lectura
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.
Las tres categorías de PII que importan en WooCommerce: directa, indirecta y sensible
La diferencia operativa entre anonimización (irreversible) y seudonimización (reversible)
Cuatro técnicas de anonimización con ejemplos: hashing con sal, tokenización, generalización y supresión
Cómo armar una política de retención por tipo de dato, no un plazo único para todo
Los siete puntos de WordPress donde la PII se acumula sin que nadie lo note
Cuándo seudonimizar es suficiente y cuándo la ley exige anonimización completa
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).
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.
Velo escanea tu WordPress y mapea toda la PII oculta
Detecta qué campos contienen información personal en tu base, logs y backups. Propone política de retención, clasifica por categoría y marca qué necesita anonimización urgente.
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:
¿Lo necesito para cumplir el contrato con el cliente? Si no, ¿cuál es la base legal?
¿Lo necesito hoy, o "por si acaso en el futuro"? El por si acaso no es base legal.
¿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.
Preguntas frecuentes
¿Cuál es la diferencia entre anonimizar y seudonimizar?
Anonimizar es irreversible: el dato ya no puede vincularse a una persona ni con información adicional. Seudonimizar es reversible con una llave: si perdés la llave, la re-identificación se vuelve inviable, pero mientras la tengas, sigue siendo dato personal bajo la ley. GDPR trata la seudonimización como medida de seguridad, no como exención.
¿Cuánto tiempo puedo retener los datos de un cliente que nunca volvió a comprar?
No hay un plazo universal. En LATAM, lo común para ecommerce es: datos fiscales 5-10 años (obligación contable), datos de marketing hasta que el titular revoque el consentimiento, y datos de cuenta inactivos 2-3 años antes de anonimizar. Documentá el plazo en tu política y aplicalo automáticamente.
¿Hash de SHA-256 sobre un email lo convierte en dato anónimo?
No. El hash de un email es determinístico y reversible por fuerza bruta (el espacio de emails válidos es pequeño comparado con el de passwords). Se considera seudonimización, no anonimización. Si querés romper el vínculo, necesitás sal (salt) secreta y nunca reutilizar el hash entre contextos.
¿Puedo guardar direcciones IP indefinidamente si las uso para antifraude?
No. Una IP es PII bajo GDPR y la mayoría de leyes LATAM. Si la retenés por seguridad, definí un plazo proporcional (6-12 meses suelen ser defendibles). Después de ese plazo, truncá los últimos octetos o hasheala con sal. La justificación de 'antifraude eterno' no resiste una auditoría.
¿Qué pasa con los campos libres tipo 'comentario del pedido' en WooCommerce?
Son la pesadilla de la privacidad. Los clientes escriben ahí teléfonos, DNIs, referencias de vecinos, instrucciones con nombres. Tratá esos campos como PII de alto riesgo, aplicá retención igual al pedido y considerá redacción automática (regex para números largos, nombres propios) antes de exportar logs.
¿La anonimización me exime de reportar una brecha de datos?
Solo si la anonimización es real e irreversible. Si usaste seudonimización (hash, tokenización con llave recuperable), la brecha sigue siendo reportable porque el atacante podría obtener la llave. Documentá la técnica exacta que usaste y cómo destruiste la información de re-identificación.
Producto mencionado
🎭
Velo
Descubrí tu PII expuesta
Descubre datos personales expuestos en tus logs, APIs y respuestas de error — clasificados por clase y severidad, sin guardar nunca el valor. Base honesta para tu cumplimiento (Ley 1581/LGPD/GDPR). $15/mes.
Logs con PII: el riesgo silencioso que tu auditoría de WordPress está ignorando
Access logs, logs de plugins, WooCommerce logs y logs de email transaccional acumulan emails, IPs y teléfonos sin que nadie los revise. Cómo auditarlos, sanitizarlos y definir retención sin perder observabilidad.
