Derecho al olvido RGPD artículo 17 en PrestaShop: supresión de cuenta sin romper la trazabilidad fiscal en 2026

El artículo 17 RGPD: una obligación simple de formular, compleja de ejecutar

«El cliente puede solicitar la supresión de sus datos». La frase es lapidaria en el artículo 17 del RGPD. Su implementación en una tienda PrestaShop o WooCommerce que tiene 5 años de existencia es cualquier cosa menos simple. Porque una «supresión de cuenta» bien hecha debe navegar entre cuatro exigencias contradictorias:

• El derecho al olvido del cliente (RGPD artículo 17).
• La obligación de conservación contable de 10 años (Código de Comercio francés L.123-22).
• La trazabilidad fiscal de las ventas (CGI, FEC).
• El derecho de respuesta a un litigio eventual (Código del Consumo, garantías legales hasta 2 años después de la compra).

El reto práctico: un módulo que suprime todo brutalmente pone a la empresa en infracción contable. Un módulo que no suprime nada pone a la empresa en infracción RGPD (sanción de hasta el 4 % de la facturación mundial). La buena práctica es la pseudonimización selectiva — suprimir lo que no es necesario a una obligación legal, conservar el resto en una forma no vinculable a una persona identificada.

Lo que el artículo 17 RGPD dice exactamente

El artículo 17.1 enumera seis motivos que justifican la solicitud de supresión:

1. Los datos ya no son necesarios para la finalidad para la que se recogieron.
2. La persona retira su consentimiento y no existe otro fundamento jurídico.
3. La persona se opone al tratamiento y no existe motivo legítimo imperioso.
4. Los datos han sido objeto de un tratamiento ilícito.
5. Los datos deben suprimirse para respetar una obligación legal.
6. Los datos se recogieron en el marco de la oferta de servicios a un niño.

Pero el artículo 17.3 prevé cinco excepciones que se aplican frecuentemente al e-commerce:

1. Ejercicio de la libertad de expresión y de información.
2. Respeto de una obligación legal (por ejemplo: conservación contable).
3. Motivo de interés público en el ámbito de la salud pública.
4. Fines de archivo, investigación científica o histórica, estadísticas.
5. Constatación, ejercicio o defensa de derechos en justicia.

La excepción (b) — obligación legal — es la que se aplica a los datos contables. Pero no cubre todos los datos de una cuenta cliente: solo los estrictamente necesarios para llevar la contabilidad y respetar la duración de conservación (10 años).

Cartografiar los datos de una cuenta cliente

En una tienda PrestaShop con 5 años de historial, una cuenta cliente contiene típicamente:

Categoría de dato	Ejemplos	Supresión artículo 17	Conservación legal
Identificación	nombre, apellido, email, teléfono	Pseudonimizar	10 años (contabilidad)
Direcciones	envío, facturación	Conservar dirección de facturación, suprimir envío antigua	10 años para facturación
Pedidos	número, fecha, importes, items	Conservar	10 años (contabilidad) + 2 años (garantía legal)
Pagos	tokens Stripe/PayPal, últimos dígitos	Suprimir si ya no se usan	Sin obligación, pero útil en litigio
Contraseñas	hash bcrypt	Suprimir inmediatamente	Ninguna
Preferencias	newsletter, marketing, cookies	Suprimir	Ninguna (salvo prueba de consentimiento útil 3 años)
Historial de navegación	logs visitas, carritos abandonados	Suprimir	Ninguna
Reseñas y comentarios	opiniones producto, mensajes SAT	Anonimizar («Cliente anónimo»)	Variable según visualización pública
Programa fidelidad	puntos, estatus	Suprimir	Ninguna
Wishlist	productos favoritos	Suprimir	Ninguna

La regla de selección: ¿es este dato necesario para la trazabilidad contable o para un eventual litigio? Si sí, se conserva en forma pseudonimizada. Si no, se suprime.

Pseudonimización: el mecanismo central

Pseudonimizar no es anonimizar. La diferencia es jurídica y técnica:

• Anonimización: supresión irreversible del vínculo entre el dato y la persona. El dato ya nunca puede vincularse. La anonimización saca el dato del perímetro RGPD.
• Pseudonimización: reemplazo de los identificadores directos por un seudónimo, pero el vínculo sigue siendo teóricamente reconstruible (por ejemplo vía una tabla de correspondencia cifrada). El dato permanece en el perímetro RGPD, pero el tratamiento se considera menos arriesgado.

Para el e-commerce, generalmente se apunta a una pseudonimización fuerte que se aproxima a una anonimización práctica:

• customer.firstname → "Cliente"
• customer.lastname → "#" + id_customer (p. ej. "#42851")
• customer.email → "deleted-" + id_customer + "@invalid" (prefijo especial, dominio inválido)
• customer.phone → NULL
• customer.passwd → bytes aleatorios (cuenta efectivamente inutilizable)
• customer.note → NULL
• address.firstname, address.lastname sobre direcciones antiguas → seudónimo
• address.firstname, address.lastname sobre la dirección de facturación de pedidos existentes → conservar (necesario para la factura)

La clave está en el matiz: se mantiene la factura tal como fue emitida (obligación contable), pero se suprime todo lo que ya no sirve.

Arquitectura de un módulo de supresión conforme

Un módulo serio para PrestaShop como DfAccountDelete implementa cinco capas:

Capa 1 — Identificación de la solicitud

Tres canales posibles:

• Botón en el espacio cliente — «Eliminar mi cuenta» accesible desde «Mi información». UX de autoservicio.
• Formulario de solicitud — para los antiguos clientes que ya no pueden conectarse. Verificación de identidad por email con enlace de confirmación.
• Solicitud al DPO/contacto RGPD — por email o correo, tratada manualmente con retranscripción en el sistema.

Capa 2 — Verificación de identidad

Antes de la supresión, se verifica que la persona es realmente titular de la cuenta. Para los clientes conectados: el hecho de estar conectado + entrada de la contraseña o validación por email (magic link bis). Para los clientes no conectados: envío de un email de confirmación con un enlace de validación single-use de duración limitada (1 hora típicamente). Para las solicitudes por correo: copia de un documento de identidad conservada 1 año y luego destruida.

Capa 3 — Plazo de reflexión

Opcional pero recomendado: un plazo de 7 a 30 días entre la solicitud y la ejecución efectiva. El usuario recibe un email «su solicitud será tratada el [fecha], haga clic aquí para cancelar». Esto evita las supresiones accidentales y los arrepentimientos. Es una buena práctica CNIL.

Capa 4 — Ejecución de la pseudonimización

El módulo ejecuta en transacción MySQL atómica:

1. Pseudonimiza ps_customer (nombre, email, teléfono, etc.).
2. Pseudonimiza las ps_address no vinculadas a pedidos finalizados.
3. Suprime ps_cart abandonados, ps_compare, ps_wishlist.
4. Suprime las entradas del programa de fidelidad, alertas de precio, alertas de stock.
5. Anonimiza las reseñas públicas («Cliente anónimo») o las suprime según la política.
6. Suprime los logs de sesión, tokens magic link, carritos guardados.
7. Suprime las suscripciones a newsletter (y propaga a Mailchimp, Brevo vía API si está conectado).
8. Marca la cuenta como suprimida (active=0, deleted=1, deleted_at = now).
9. Conserva intactos los pedidos, facturas, abonos (ps_orders, ps_order_invoice, ps_order_slip).

Capa 5 — Audit log y notificación

Una entrada en un diario de auditoría RGPD:

• Fecha de la solicitud, fecha de la ejecución.
• Email de origen (antes de la pseudonimización).
• ID cliente.
• Método de verificación de identidad.
• Lista de tablas afectadas y número de filas afectadas.

Este log se conserva 3 años (duración recomendada por la CNIL para demostrar la conformidad). Sirve en caso de inspección CNIL o de solicitud de la persona («¿realmente ha suprimido mis datos?»).

Se envía un email de confirmación a la dirección de origen, con mención de que los datos han sido suprimidos salvo los necesarios para la contabilidad (transparencia artículo 12 RGPD).

El puente con el FEC: lo que hay que preservar absolutamente

Como se explica en nuestro artículo sobre el FEC y la exportación contable, ciertos datos son necesarios para la producción de un FEC conforme:

• Identificación del cliente en la factura emitida (nombre + dirección de facturación en el momento de la emisión). Pero no necesitamos que ese nombre sea siempre recuperable desde la base de clientes viva — está en la factura PDF archivada y en ps_orders.
• Importes sin IVA, IVA, portes, total con IVA — datos contables puros, a conservar intactos.
• Fecha del pedido, de la factura, del pago — ídem.
• Método de pago (Stripe, PayPal, transferencia) — útil para la conciliación bancaria.

El patrón práctico: se pseudonimiza ps_customer, pero se deja ps_orders.firstname, ps_orders.lastname, ps_orders.email tal como estaban en el momento del pedido. Es lo que aparece en la factura emitida. La factura es el registro contable, inmutable. La cuenta cliente es un agregado vivo, que se puede anonimizar.

En PrestaShop, esta lógica se ve facilitada por el hecho de que la factura se gestiona por ps_order_invoice con sus propios campos (el nombre no es solo referenciado por id_customer, también está congelado en el pedido). En WooCommerce es más delicado: las orders WC almacenan el customer ID y reconstruyen la información en la visualización. Por tanto, hay que congelar el nombre y la dirección de facturación en el order en el momento de la pseudonimización, si no la factura regenerada muestra «Cliente anónimo».

Las reseñas y comentarios: un caso aparte

Una reseña de producto mostrada públicamente con el nombre del cliente es un dato personal (artículo 4 RGPD). Su supresión a petición plantea dos problemas:

• El contenido de la reseña tiene valor para los demás clientes (información al consumidor).
• El historial de reseñas sirve para la media de notación.

La resolución jurídica estándar: anonimizar el nombre («Cliente anónimo» o «C.A.»), conservar el contenido de la reseña y la nota. Es un tratamiento estadístico en el sentido del artículo 17.3.d. Si el cliente solicita explícitamente la supresión completa de la reseña («ya no quiero que este texto exista»), entonces se suprime totalmente, pero se puede recalcular la media sin el dato perdido.

Este matiz debe presentarse al usuario en el formulario: «¿Desea suprimir sus reseñas o hacerlas anónimas?».

Casos particulares difíciles

Cuenta cliente con un litigio en curso

Si un pedido está en litigio (devolución bloqueada, impugnación, acción en garantía), la supresión de los datos del cliente compromete la defensa de la empresa. El artículo 17.3.e cubre este caso: se puede rechazar la supresión hasta la resolución del litigio, informando al cliente de esta razón. La conservación se hace bajo el estado «en litigio», con acceso restringido.

Cuenta B2B con multi-usuarios

En una cuenta B2B con varios usuarios, la supresión de la cuenta de un usuario no debe suprimir la sociedad. Se suprime al usuario (que tiene un derecho individual), se conservan los pedidos a nombre de la sociedad (que no tiene derecho al olvido, al ser persona jurídica).

Newsletter sin cuenta (anónima)

Un email inscrito en la newsletter sin cuenta cliente: la supresión es inmediata, sin pseudonimización. Sin obligación contable vinculada. Una excepción: si el consentimiento de marketing está trazado como prueba, se puede conservar el historial del consentimiento (fecha, IP, opt-in) durante 3 años después de la desuscripción. Más allá, supresión completa.

Suscriptores a un servicio recurrente (suscripción)

Para las tiendas en suscripción, la supresión de la cuenta exige primero la parada de la suscripción (imposible cargar una tarjeta de una cuenta que ya no existe). El módulo debe secuenciar: cancelación de las suscripciones → espera de un ciclo para confirmación → pseudonimización. Saltarse la secuencia provoca cargos huérfanos y contenciosos con clientes.

El plazo de respuesta impuesto por el RGPD

Artículo 12.3 RGPD: la respuesta a una solicitud debe intervenir en menos de 1 mes, prolongable a 2 o 3 meses para las solicitudes complejas (con notificación de la prolongación al solicitante). En la práctica para el e-commerce:

• Solicitud simple vía el botón «eliminar mi cuenta»: ejecución inmediata (según plazo de reflexión opcional) — muy por debajo del plazo legal.
• Solicitud por email/correo que exige una verificación de identidad: 1 a 2 semanas de tratamiento, por debajo del mes.
• Solicitud en un contexto complejo (litigio, suscripción activa, multi-cuentas): 1 mes con información al solicitante del estado.

El incumplimiento del plazo expone a sanciones CNIL. Un módulo automatizado que responde en 24-48 h cubre ampliamente el riesgo.

Coste y ROI

El ROI de un módulo de supresión de cuenta conforme se mide de forma distinta al de un módulo de conversión:

• Coste del módulo: 39 € licencia para PrestaShop.
• Coste evitado de una sanción CNIL: variable, pero las sanciones e-commerce 2023-2025 van de 5 000 € para PYMES a varios millones para grandes marcas. La relación coste/riesgo es extremadamente favorable.
• Coste evitado de retratamiento manual: en una tienda de 50 000 clientes, tratar 5 a 10 solicitudes/mes manualmente representa 2 a 4 h/mes de trabajo interno — unos 1 200 €/año.
• Beneficio de confianza: mostrar un botón «eliminar mi cuenta» bien visible se ha convertido en una señal de confianza fuerte en 2026, medible en tasa de creación de cuenta (+3 a 6 % observado).

FAQ

¿Realmente hay que mantener los pedidos 10 años después de la supresión de la cuenta?

Sí, es la obligación contable (Código de Comercio francés L.123-22). El RGPD no exime del derecho fiscal. La resolución: los pedidos permanecen en base en forma pseudonimizada (el nombre del cliente ya no está vinculado a una cuenta viva pero figura aún en la factura emitida, como es necesario). Al término de los 10 años, supresión completa posible.

¿Qué hacer si Mailchimp o Brevo siguen enviando la newsletter?

El RGPD artículo 19 impone la propagación de la supresión a los destinatarios de los datos. Si ha sincronizado su base con Mailchimp/Brevo/Klaviyo, el módulo debe llamar a su API para suprimir el contacto (y no solo desuscribirlo). Es un punto a validar en la instalación: todos los conectores de marketing deben recibir la señal de supresión.

¿Cómo gestionar la supresión en los subcontratistas (Stripe, PayPal)?

Stripe y PayPal conservan los tokens de pago y el historial de transacciones según su política (generalmente 10 años para conformidad fiscal + lucha antiblanqueo). No puede forzar su supresión — es su obligación legal, distinta de la suya. La mención en su política de privacidad debe indicar que los subcontratistas de pago conservan los datos según su propia duración legal.

¿Se puede suprimir una cuenta sin informar al cliente?

Si es el cliente quien ha solicitado la supresión: se le informa de la ejecución. Si es la empresa la que suprime por su iniciativa (inactividad prolongada, por ejemplo): debe haber previsto esta política en las CGV/política de privacidad, e idealmente notificar 30 días antes de la supresión para permitir la oposición. La supresión sin notificación es arriesgada.

¿Cuánto tiempo después de una solicitud de olvido puede un cliente volver a nosotros?

El derecho al olvido no es un derecho a la inversión. Una vez suprimidos (o pseudonimizados) los datos, el cliente que vuelve crea una nueva cuenta ex nihilo. El historial permanece en el audit log RGPD (que sirve para probar que se ha ejecutado la solicitud), pero no puede reutilizarse para reconstituir la cuenta inicial.

En síntesis

La supresión de cuenta conforme al artículo 17 RGPD es un ejercicio de equilibrio entre cuatro obligaciones legales contradictorias. La resolución pasa por la pseudonimización selectiva: se suprime o anonimiza todo lo que no está cubierto por una obligación de conservación, se conserva intacta la trazabilidad contable necesaria al FEC y al control fiscal.

El módulo DfAccountDelete para PrestaShop implementa esta lógica con las cinco capas de un flujo de trabajo conforme: identificación, verificación de identidad, plazo de reflexión opcional, pseudonimización atómica, audit log. Se integra con la exportación FEC para no romper la cadena contable y con las principales herramientas de marketing (Mailchimp, Brevo, Klaviyo) para propagar la supresión.

El buen reflejo en 2026: mostrar un botón «eliminar mi cuenta» bien visible en el espacio cliente (señal de confianza, conformidad explícita), documentar el flujo en la política de privacidad (transparencia artículo 12), conservar el audit log 3 años para demostrar la conformidad en caso de inspección CNIL.

Para las tiendas que desean una auditoría completa de su conformidad RGPD, nuestra auditoría PrestaShop cubre los seis puntos críticos: cookies y consentimiento, base de tratamiento de los datos clientes, plazos de conservación parametrizados, derecho de acceso y portabilidad, derecho al olvido, registro de tratamientos artículo 30.