Una casilla marcada en un formulario no basta para construir un proceso fiable de consentimiento. La aplicación debe saber qué autorización se concedió, para qué acción, cuándo y bajo qué alcance; también debe poder dejar de actuar cuando se retira. Este diseño es especialmente relevante para funciones opcionales, como comunicaciones o tratamientos que no son necesarios para prestar el servicio principal.
El diseño de consentimiento revocable en aplicaciones PHP exige separar decisiones que a menudo terminan mezcladas en una sola bandera. No determina por sí solo si una práctica cumple la normativa aplicable: convierte las decisiones de producto y las instrucciones revisadas por especialistas en comportamiento técnico verificable.
Delimitar la acción y separar conceptos
Empieza por describir la acción concreta que requiere autorización. “Aceptar todo” es difícil de interpretar y de revocar; “recibir comunicaciones promocionales por correo electrónico” delimita mejor el propósito y el canal. Si cambian el propósito o el alcance de forma material, no asumas que el consentimiento anterior sirve automáticamente.
Distingue el consentimiento de conceptos relacionados:
- Términos de uso: expresan condiciones contractuales o de acceso; aceptarlos no equivale por sí mismo a autorizar un tratamiento opcional.
- Preferencias: describen elecciones de presentación o configuración. Pueden requerir consentimiento, pero no siempre lo representan.
- Permisos de acceso: controlan qué puede hacer una identidad autenticada dentro del sistema. Revocar una autorización opcional no debería desactivar automáticamente la cuenta.
- Consentimiento: registra una decisión sobre un propósito y un alcance definidos, según el criterio funcional y jurídico adoptado.
Documenta cada propósito en un catálogo estable, con una descripción comprensible para la interfaz y una referencia interna para el código. Evita reutilizar una clave genérica como accepted para fines distintos.
Modelar el estado y sus cambios
Un modelo útil identifica al sujeto, el propósito, el alcance, el estado, el origen de la decisión y las marcas de tiempo. El sujeto puede ser una cuenta o una identidad vinculada; la elección depende de cómo se relaciona el consentimiento con personas, cuentas y canales. Guarda únicamente los datos necesarios para operar y explicar la decisión.
En lugar de representar todo con un booleano sin contexto, conserva un registro actual consultable y, si el requisito de auditoría lo justifica, eventos de cambio inmutables o append-only. Un evento puede incluir:
- Identificador del sujeto y clave del propósito.
- Acción registrada, por ejemplo, concesión o retirada.
- Alcance aplicable, como canal o categoría.
- Fecha y hora del servidor en un formato coherente.
- Origen, como formulario autenticado o flujo administrativo, sin recopilar datos excesivos.
- Identificador de correlación o versión de la definición, cuando ayude a investigar cambios.
El registro de eventos aporta trazabilidad, pero no demuestra automáticamente que la solicitud fuera clara, que la interfaz estuviera bien presentada o que la decisión sea jurídicamente válida. Evita almacenar copias innecesarias de formularios, direcciones IP u otros datos sensibles como sustituto de un diseño correcto.
En PHP, concentra las operaciones en un servicio de dominio, por ejemplo ConsentService, en vez de permitir que cada controlador escriba directamente el estado. La actualización del estado vigente y la inserción del evento deben realizarse en una transacción de base de datos cuando comparten almacenamiento.
Comprobar la autorización en el punto de ejecución
La interfaz puede ocultar una opción si no hay autorización, pero no es un control suficiente. La comprobación debe ocurrir en el punto que inicia la acción: antes de encolar un envío, procesar un tratamiento opcional o llamar a una integración externa. Un mensaje pendiente generado antes de una retirada también debe verificarse antes de enviarse.
Una operación de dominio puede consultar una interfaz como ConsentRepository::isGranted($subjectId, $purpose, $scope). El nombre es ilustrativo: el resultado debe considerar el estado vigente, el propósito exacto, el alcance y cualquier regla de expiración o versión que el producto haya definido. No conviertas un consentimiento para un canal en autorización para otro.
Si la ejecución es asíncrona, transmite identificadores y vuelve a consultar el estado al procesar el trabajo, en vez de confiar en una copia antigua enviada desde el formulario. Ante una caída del repositorio, decide explícitamente el comportamiento: para una acción opcional sensible, normalmente es más seguro no ejecutarla hasta poder verificar la autorización. Registra el fallo operativo sin exponer datos innecesarios.
Retirar el consentimiento y propagar el cambio
La retirada es una transición explícita del estado, no un borrado silencioso del historial ni una revocación de la sesión. El usuario puede seguir autenticado y conservar acceso al servicio mientras se detiene la acción opcional autorizada. Del mismo modo, retirar un consentimiento no implica automáticamente borrar todos los datos: la conservación, supresión o tratamiento posterior pueden depender de requisitos distintos que deben definirse con asesoramiento adecuado.
Al registrar la retirada, actualiza el estado consultado por la aplicación y emite un evento que permita coordinar tareas posteriores. Identifica los puntos de propagación: trabajos en cola, planificadores, sistemas de comunicaciones e integraciones. Para evitar efectos inconsistentes, usa patrones como una tabla de salida transaccional (outbox) y consumidores idempotentes; define qué ocurre si una integración no está disponible.
No siempre es posible deshacer un efecto ya ejecutado, como un mensaje entregado. Por eso, distingue entre impedir acciones futuras, cancelar tareas todavía pendientes y corregir efectos ya producidos. Expón el resultado con precisión y conserva un mecanismo de reintento o revisión operativa para fallos de propagación.
Probar límites, repetición y fallos parciales
Las pruebas deben cubrir el ciclo completo, no solo que el formulario guarde una opción. Incluye concesión, rechazo, retirada, cambios de propósito y solicitudes repetidas. Verifica que repetir una retirada no reactive el consentimiento y que los eventos duplicados no produzcan envíos duplicados ni estados contradictorios.
- Comprueba que una acción no comienza si no existe autorización vigente para ese propósito y alcance.
- Retira el consentimiento después de crear un trabajo y confirma que el consumidor vuelve a verificarlo antes de actuar.
- Simula un fallo entre la actualización del estado y la notificación a una integración; verifica que la reconciliación puede completar la propagación.
- Prueba estados antiguos, datos ausentes y errores del repositorio, con el comportamiento seguro definido.
- Verifica que retirar un propósito no cambia otros propósitos, los permisos de acceso ni la sesión.
Registra métricas operativas y errores de procesamiento sin convertir los registros técnicos en un repositorio paralelo de información personal. Revisa periódicamente tareas pendientes y discrepancias entre el estado central y las integraciones.
Acordar responsabilidades antes de desplegar
Producto debe definir propósitos, alcance, texto y experiencia de retirada; tecnología debe hacer cumplir esas decisiones en cada camino de ejecución. Seguridad y especialistas legales pueden revisar el modelo de amenazas, la minimización de datos, los plazos de conservación y la interpretación aplicable. La implementación no sustituye esa revisión.
Antes de desplegar, documenta qué acciones dependen de cada propósito, quién puede cambiar sus definiciones y cómo se corrigen errores. Así, el consentimiento deja de ser una casilla aislada y se convierte en una condición comprobable, trazable y propagable dentro de la aplicación PHP.
