Derechos ARCO y derecho al olvido en WordPress: cómo implementarlos sin romper tu contabilidad | Drokio Blog | Drokio
PrivacidadARCOderecho al olvidoprivacidad
📬Derechos ARCO y derecho al olvido en WordPress: cómo implementarlos sin romper tu contabilidad
Guía técnica y legal para procesar solicitudes de acceso, rectificación, cancelación y oposición en WordPress/WooCommerce. Qué borrar, qué retener por obligación legal, cómo responder en plazo y dejar evidencia firmada.
Otura··11 min de lectura
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 del titular (ARCO + portabilidad) y qué significa cada uno operativamente
Cómo verificar la identidad del solicitante sin recolectar más PII de la que vas a borrar
El mapa completo de borrado en WordPress: las 12 ubicaciones donde hay que actuar
Qué datos podés (y debés) retener legalmente aunque el titular pida borrado total
Plantilla de respuesta y cómo dejar evidencia firmada con timestamp criptográfico
Los errores más comunes que convierten un borrado "exitoso" en un incumplimiento auditable
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.
wp_posts de tipo shop_order. Pedidos asociados — decisión clave: anonimizar o eliminar (más abajo).
wp_postmeta de esos pedidos. Dirección de facturación, envío, método de pago, notas.
wp_comments y wp_commentmeta. Comentarios en el blog con email, nombre, IP.
Tablas de plugins. Suscripciones de newsletter (wp_subscriptions, wp_mc_subscribers), membresías, puntos de fidelidad, referidos, wishlist.
Logs de plugins de seguridad. Intentos de login, 2FA, auditoría.
Logs de emails transaccionales. WP Mail SMTP log, WooCommerce email log.
Access logs del servidor. IPs, User-Agents, paths accedidos.
Sub-procesadores externos. CRM (HubSpot, Mailchimp), pasarela de pago, chatbot, helpdesk (Intercom, Zendesk), analytics.
Backups. Copias de los 12 meses anteriores.
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.
Notario deja evidencia forense de cada solicitud ARCO
Timestamp criptográfico del momento de recepción, del proceso de verificación y del borrado ejecutado. Cadena de custodia con hash SHA-256 y firma, lista para presentar ante autoridad si hay denuncia.
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.
Preguntas frecuentes
¿Los derechos ARCO son lo mismo que los derechos GDPR?
No exactamente. ARCO (Acceso, Rectificación, Cancelación, Oposición) es el acrónimo LATAM clásico, usado en México, Argentina y otras jurisdicciones. GDPR agrega portabilidad y limitación del tratamiento, y define el derecho al olvido con más fuerza. En la práctica se solapan al 80%, pero los matices importan en las respuestas: bajo GDPR tenés que justificar cualquier retención, bajo ARCO suele ser suficiente citar la obligación legal.
¿Qué plazo tengo para responder una solicitud ARCO?
Depende de la jurisdicción. GDPR: 30 días naturales, extensibles a 60 con justificación. LFPDPPP México: 20 días. Argentina (Ley 25.326): 10 días corridos. Colombia: 15 días hábiles. La regla segura: responder en 10-15 días siempre, y nunca dejar sin respuesta aunque sea para pedir aclaración.
¿Puedo negarme a borrar datos si el cliente tiene facturas pendientes de prescripción?
Sí, pero con matices. Podés retener los datos estrictamente necesarios para cumplir la obligación fiscal o contable (facturación, trazabilidad de pagos) durante el plazo legal, y anonimizar el resto. Tenés que explicarlo al titular con precisión: qué datos retenés, por qué, hasta cuándo y qué podés borrar ya.
¿Cómo verifico que quien pide el borrado es realmente el titular y no un impersonador?
Es la parte más delicada. Pedí verificación proporcional: confirmación desde el email registrado, últimos dígitos de un pedido, o un código enviado al teléfono asociado. Nunca pidas copia de DNI escaneado como primera opción (estás recolectando más PII para procesar una solicitud de borrado —irónico y riesgoso).
Si borro el usuario de WordPress, ¿qué pasa con los comentarios y los pedidos que hizo?
Por defecto WordPress reasigna los comentarios a 'Anónimo' o te pregunta a quién. Los pedidos de WooCommerce quedan como 'Cliente huérfano' con los datos embebidos intactos. Eso NO cumple con el borrado: tenés que anonimizar explícitamente nombre, email y dirección en cada pedido, y considerar si mantenés el registro contable por obligación fiscal.
¿Tengo que notificar a mis sub-procesadores cuando un cliente pide borrado?
Sí, y es una de las obligaciones más olvidadas. Si tu CRM, tu Mailchimp, tu pasarela de pago o tu hosting guardan copia del dato, el borrado en tu WordPress no es suficiente. Tu DPA con cada proveedor debe contemplar la propagación de solicitudes ARCO; documentá a quién notificaste y conservá acuse.
Producto mencionado
⚖️
Notario
Evidencia forense legal
Cadena de custodia digital firmada criptográficamente. Evidencia admisible en procesos judiciales.
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.
