📬Derechos ARCO y derecho al olvido en WordPress: cómo implementarlos sin romper tu contabilidad

El email llega un viernes a las 18:47.

"Solicito el ejercicio de mi derecho al olvido. Eliminen todos mis datos personales de sus sistemas. Plazo: 30 días. Si no cumplen, acudiré a la autoridad de protección de datos."

Y ahora tenés que decidir: qué borrás, qué no, cómo verificás que es la persona correcta, cómo respondés sin admitir más de lo necesario y cómo dejás evidencia de que lo hiciste bien, por si aparece una denuncia seis meses después.

Los derechos del titular de datos —ARCO en LATAM, ampliados bajo GDPR— no son opcionales. Ignorarlos cuesta multas de miles a millones, y el daño reputacional es peor. Pero cumplirlos mal también es peligroso: si borrás datos que tenías obligación de conservar, violás obligación fiscal. Si no borrás suficiente, violás privacidad. El equilibrio es ingeniería fina.

Este artículo te da el proceso operacional completo para WordPress/WooCommerce: qué significa cada derecho, cómo verificar al solicitante, qué borrar y qué retener, cómo responder en plazo, y cómo dejar evidencia que aguante una auditoría.

Los cinco derechos que tu WordPress debe poder ejecutar

Las leyes LATAM y GDPR reconocen un núcleo común de derechos. La nomenclatura cambia pero la operación es la misma.

Acceso

El titular tiene derecho a saber qué datos tuyos tenés vos, para qué los usás, a quién se los compartís y por cuánto tiempo los conservás.

Operativamente: tenés que poder generar un informe completo con todos los campos que contienen datos de esa persona, en un formato legible (PDF, CSV, JSON), entregado en plazo.

Rectificación

Si los datos están incorrectos o incompletos, el titular puede pedir que los corrijas.

Operativamente: necesitás un canal claro para recibir correcciones y un proceso para actualizar en todos los puntos donde vive el dato (no solo wp_users, también wp_postmeta de pedidos, logs, exportaciones activas).

Cancelación (o supresión)

Borrado de los datos cuando ya no hay base legal para conservarlos, o cuando el titular retira el consentimiento que era la base.

Operativamente: es la solicitud más compleja porque obliga a distinguir qué es borrable y qué retenés por obligación legal.

Oposición

El titular puede oponerse al tratamiento de sus datos para ciertos fines (marketing directo es el caso clásico). No implica borrado: implica parar el uso específico.

Operativamente: activar un flag en el perfil (opted_out_marketing = true) y asegurar que ningún proceso (newsletters, remarketing, ads personalizados) los incluya a partir de ese momento.

Portabilidad (GDPR, no siempre en ARCO clásico)

El titular puede pedir sus datos en formato estructurado, legible por máquina, para llevárselos a otro proveedor.

Operativamente: export JSON o CSV con todos los campos relevantes. Si el proveedor destino es otro ecommerce, idealmente en el formato estándar del sector (WooCommerce API, por ejemplo).

Verificación de identidad: la trampa más común

Antes de hacer nada con una solicitud, tenés que verificar que quien pide es el titular. Parece obvio, pero es donde empiezan los problemas.

Los riesgos son dos, y van en direcciones opuestas:

Verificación insuficiente. Alguien se hace pasar por el cliente, pide el borrado, y vos borrás los datos del cliente real sin su consentimiento. Ese cliente después vuelve, no puede acceder, te demanda.

Verificación excesiva. Pedís copia de DNI, factura de servicios, selfie con documento. Estás recolectando PII nueva para procesar una solicitud de borrado de PII. Absurdo y violatorio del principio de minimización.

El término medio: verificación proporcional al riesgo del dato.

• Para acceso a metadatos simples (suscripción a newsletter): confirmación desde el email registrado es suficiente.
• Para borrado completo de una cuenta con historial de compras: confirmación desde el email + código enviado al teléfono registrado + mención de un dato solo conocido por el cliente (últimos 4 del método de pago, fecha del último pedido).
• Para datos sensibles (salud, financieros): puede justificarse un paso adicional, pero siempre recolectando lo mínimo posible.

Documentá el método que usaste. Si mañana aparece una denuncia de "me borraron sin permiso", tu evidencia es el log de verificación.

El mapa completo de borrado en WordPress

Cuando un borrado es procedente, tenés que actuar en 12 ubicaciones. Saltarte una es equivalente a no hacer nada.

1. wp_users. El registro principal del usuario.
2. wp_usermeta. Metadatos: direcciones, teléfono, roles, últimas sesiones, preferencias.
3. wp_posts de tipo shop_order. Pedidos asociados — decisión clave: anonimizar o eliminar (más abajo).
4. wp_postmeta de esos pedidos. Dirección de facturación, envío, método de pago, notas.
5. wp_comments y wp_commentmeta. Comentarios en el blog con email, nombre, IP.
6. Tablas de plugins. Suscripciones de newsletter (wp_subscriptions, wp_mc_subscribers), membresías, puntos de fidelidad, referidos, wishlist.
7. Logs de plugins de seguridad. Intentos de login, 2FA, auditoría.
8. Logs de emails transaccionales. WP Mail SMTP log, WooCommerce email log.
9. Access logs del servidor. IPs, User-Agents, paths accedidos.
10. Sub-procesadores externos. CRM (HubSpot, Mailchimp), pasarela de pago, chatbot, helpdesk (Intercom, Zendesk), analytics.
11. Backups. Copias de los 12 meses anteriores.
12. Exportaciones manuales. CSVs que alguien descargó a su laptop, reportes enviados por email a contabilidad.

Las últimas tres (sub-procesadores, backups, exportaciones) son donde fallan casi todos los borrados. El cliente queda "borrado" en WordPress pero sigue en HubSpot, en el backup de septiembre y en el CSV que marketing mandó al gerente en enero.

Qué retenés aunque el titular pida borrado

No todo es borrable. Hay datos que la ley te obliga a conservar aunque el titular insista en el borrado total.

Datos fiscales y contables

Facturas, recibos, notas de crédito. En LATAM el plazo típico es de 5 años (Argentina, Uruguay, Perú, Chile) a 10 años (México, Colombia para contabilidad general).

La solución es clara: el titular pide borrado → anonimizás los datos operacionales (cuenta de WordPress, marketing, logs) → retenés el registro contable con el mínimo necesario (nombre fiscal, RFC/CUIT, dirección fiscal) hasta cumplir el plazo legal → al vencer, purgás también el registro contable.

Informale al titular qué se borró ya y qué se retiene con base legal específica, hasta cuándo. Un correo claro: "Eliminamos su cuenta, marketing, historial de navegación y comentarios. Conservamos el registro fiscal de sus facturas (IDs XX, YY) hasta [fecha], por obligación de la Ley de IVA / RFC / CUIT".

Datos necesarios para reclamos en curso

Si hay un proceso legal activo (disputa de cargo, queja formal, demanda), podés (y debés) retener los datos mientras dure el proceso. La justificación es "ejercicio de derechos" y aplica tanto para vos como para el titular.

Datos agregados o anonimizados irreversiblemente

Estadísticas, métricas de conversión, análisis de tendencias. Si están verdaderamente anonimizadas (no seudonimizadas), dejan de ser datos personales y no aplican los derechos ARCO. Pero ojo: la anonimización debe ser real, no solo quitar el nombre.

Prevención de re-registro (opcional, con cuidado)

Algunas plataformas mantienen un hash del email borrado con la única finalidad de rechazar el re-registro automático si el titular no quiso volver. Es legítimo si está documentado en la política, si el titular lo sabe, y si el hash no se usa para nada más.

El plazo y la respuesta

Cada jurisdicción define el plazo máximo para responder. Los comunes:

| Jurisdicción | Plazo | Extensión | |--------------|-------|-----------| | GDPR (UE) | 30 días | +60 días con justificación | | LFPDPPP (México) | 20 días | +20 adicionales para efectuar | | Ley 25.326 (Argentina) | 10 días corridos | — | | LGPD (Brasil) | 15 días | — | | Ley 1581 (Colombia) | 15 días hábiles | +8 | | Ley 19.628 (Chile) | 2 días hábiles para acuse, 15 días para respuesta | — |

La regla segura para ecommerce LATAM: responder dentro de 10 días hábiles siempre, sin importar la jurisdicción. Cumplís con todas y evitás discusiones.

La respuesta tiene que:

• Confirmar recepción de la solicitud.
• Identificar claramente qué derechos se ejercen.
• Ejecutar o explicar por qué no procede (en parte o totalmente).
• Listar qué datos se borraron y qué se retienen, con base legal de la retención.
• Informar al titular de su derecho a reclamar ante la autoridad si no está conforme.

Nunca respondas con silencio. Aunque no puedas ejecutar el borrado total, aunque necesites más tiempo, aunque dudes de la legitimidad: respondé acusando recibo, explicando el estado y proponiendo plazo concreto.

Evidencia: por qué necesitás un registro inmutable

El borrado no termina cuando borrás. Termina cuando podés demostrar —meses o años después— que lo hiciste correctamente y en plazo.

Un titular puede denunciarte seis meses después, diciendo que nunca le borraste los datos. La autoridad te pide evidencia. Si tu "evidencia" es un email genérico que dice "confirmamos el borrado", no alcanza.

La evidencia operativa debe incluir:

• Timestamp verificable del momento en que recibiste la solicitud.
• Método de verificación de identidad usado, con log.
• Decisiones tomadas: qué se borró, qué se retuvo, por qué.
• Log técnico de las acciones: queries ejecutadas, archivos eliminados, notificaciones a sub-procesadores.
• Respuesta enviada al titular, con timestamp de envío y acuse de lectura si aplica.
• Hash criptográfico del paquete completo de evidencia, guardado de forma inmutable.

El hash es la parte no negociable. Si tu evidencia vive en la misma base que los datos, un admin interno malicioso puede modificarla. La evidencia inmutable (blockchain, WORM storage, servicio de timestamp externo con RFC 3161) es lo que convierte un "confié en que lo hicieron bien" en una cadena de custodia defendible.

Errores comunes que convierten cumplimiento en incumplimiento

Borrar la cuenta y dejar los pedidos con datos intactos. WordPress permite borrar el usuario y "reasignar el contenido". Los pedidos quedan huérfanos con todos los datos embebidos. Sigue siendo PII en tu base. Solución: anonimizar explícitamente los campos _billing_* y _shipping_* de los pedidos que no tengan obligación fiscal pendiente.

Responder solo por email sin log del contenido. Si el titular niega haber recibido la respuesta, no tenés evidencia. Siempre generá y archivá el HTML del correo enviado, con timestamp del servidor de salida.

Verificar solo con "confirme desde su email". Si el atacante ya comprometió el email del cliente, pasa la verificación. Para datos sensibles, combinar dos canales (email + SMS, email + dato solo conocido por el cliente).

No notificar a los sub-procesadores. Ya lo mencioné arriba pero lo repito porque es el fallo más común. Tu Mailchimp, tu CRM, tu pasarela tienen copias. Un DPA correcto contempla la propagación, pero propagar no es automático: requiere notificación operativa.

Aceptar solicitudes por cualquier canal. Si alguien te pide borrado por Twitter DM, por chat web, por mensaje de Instagram, está en su derecho. Tu política debe definir un canal oficial (email dedicado, formulario web con verificación) y redirigir las solicitudes informales, sin dejar de atenderlas.

No dejar asentado cuando rechazás una solicitud. Si el titular pide borrado y vos legítimamente retenés por obligación fiscal, la respuesta fundamentada y el fundamento retenido son tan importantes como ejecutar un borrado. Sin esa evidencia, parece negligencia.

Automatizar sin supervisión humana. Un script que ejecuta borrados automáticos basándose solo en un email entrante es peligroso: un atacante manda un email falsificado, se borra un cliente real. Siempre humano-en-el-loop para la decisión final, aunque el inventario y preparación sea automático.

Plantilla de respuesta

Una respuesta mínima defendible tiene esta estructura:

Estimado/a [nombre],

Confirmamos la recepción de su solicitud de [derecho ejercido] recibida 
el [fecha] a las [hora].

Tras verificar su identidad mediante [método], hemos procesado su 
solicitud de la siguiente forma:

DATOS ELIMINADOS:
- Cuenta de usuario y datos de perfil
- Historial de navegación y preferencias de marketing
- Comentarios y contribuciones al sitio
- [detallar según caso]

DATOS RETENIDOS CON BASE LEGAL:
- Registros fiscales de las facturas #XX, #YY, por obligación [citar ley],
  hasta [fecha]. Al vencer el plazo, estos datos se eliminarán 
  automáticamente.

SUB-PROCESADORES NOTIFICADOS:
- [Lista de proveedores con copia del dato, y plazo comprometido de
  propagación]

El procesamiento se completó el [fecha] a las [hora]. 
La referencia de su solicitud es [ID interno con hash].

Si considera que su solicitud no fue atendida adecuadamente, puede 
presentar reclamo ante [autoridad de protección de datos competente].

Saludos,
[responsable del tratamiento]

Ajustá según la jurisdicción y la complejidad del caso. Lo importante es la estructura: qué se hizo, qué se retuvo y por qué, y la vía de escalado.

Cierre

Los derechos del titular no son una carga burocrática. Son el contrato básico que tenés con cada persona cuyos datos tratás: ella te presta información a cambio de un servicio, y vos te comprometés a tratarla con responsabilidad y dársela de vuelta cuando la pida.

Procesar bien una solicitud ARCO tiene costo operativo. Procesar mal una solicitud ARCO tiene costo legal, reputacional y humano mayor. La diferencia entre los dos es el proceso que documentás hoy, antes de que llegue la primera solicitud difícil.

Cuando el email llegue un viernes a las 18:47, ya vas a tener el runbook, el canal de verificación, el inventario de ubicaciones, el motor de anonimización y el sistema de evidencia. Vas a responder en diez días con tranquilidad, no en treinta con pánico.

Y el día que alguien te audite, vas a abrir el archivo de evidencia y demostrar que cada solicitud se procesó bien, se documentó y se cerró. Esa es la diferencia entre cumplir y parecer cumplir.