Gestión del consentimiento

1) Términos y límites de responsabilidad

Consentimiento (consent): voluntad voluntaria, informada, específica e inequívoca; puede ser revocado.
Fundamento jurídico: el consentimiento es sólo una de las opciones (contrato, fundamento legal, interés legítimo, etc.). El modelo debe almacenar tanto la base como el propósito.
Propósito del tratamiento (purpose): causa atómica: analítica, personalización, ads, email_marketing, data_sharing_vendor_X.
Granularidad: Los consentimientos se almacenan por objetivos, canales, vendedores, regiones, categorías de datos.
Perfil del sujeto: persona, dispositivo, hogar, cuenta del niño (reglas especiales para menores).

2) Ciclo de vida del consentimiento

1. Colección: banner/SMR, configuración de perfil, API/SDK, canal offline (centro de contacto).
2. Validación: edad, región, disponibilidad de alternativas (sin «patrones oscuros»).
3. Registro: crear un evento de consentimiento y una instantánea de estado actual para fines.
4. Distribución: publicación en el bus de eventos, actualización de cachés en edge, sincronización con vendedores.
5. Ejecución: aplicación en tiempo real (gateways/píxeles/SDK), en batch (ETL/analytics), en pipelines ML.
6. Cambio/revocación: prohibición inmediata de nueva recopilación/activación, posterior «limpieza» de datos históricos sobre políticas.
7. Auditoría/Reporting: la probabilidad del consentimiento en el momento del procesamiento (quién, cuándo, qué versión del texto).

3) Componentes arquitectónicos

CMP (Consent Management Platform): UI/SDK + API que formatea las opciones de consentimiento bajo UX/jurisdicción; fuente de la verdad sobre textos y versiones.
Registro de consensos (registro): almacén confiable de estados y eventos de concordancia (registro único de aplicaciones + proyección actual).
Consent PDP/PEP: Policy Decision/Enforcement Point. PDP decide "¿es posible? ", PEP aplica la solución en la puerta de enlace API, en ETL, en SDK, etc.
Edge caché de consentimiento: baja latencia para la verificación perimetral.
Partner/GPP/IAB gateway: retransmitir los objetivos locales hacia y desde las señales de afiliación.
Data Lineage & Tagging: marcando los datos con banderas de consentimiento/fundación en toda la cadena.

4) Modelo de datos (diagramas)

json
{
"subject_id": "usr_123",
"subject_scope": "user",
"region": "EU",
"legal_basis": {
"analytics": "consent",
"personalization": "consent",
"security": "legitimate_interest",
"contract_core": "contract"
},
"purposes": {
"analytics": {"status": "granted", "version": "v5", "updated_at": "2025-10-31T13:20:10Z"},
"personalization": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"ads": {"status": "denied", "version": "v5", "updated_at": "2025-10-31T13:21:31Z"},
"email_marketing": {"status": "granted", "channel":"email","updated_at":"2025-10-31T13:22:05Z"}
},
"text_bundle": {"locale":"uk-UA","policy_version":"2025-09"},
"evidence": {"capture_ip":"203. 0. 113. 5","capture_ua":"Chrome/142"}
}

json
{
"event_id": "cse_987",
"subject_id": "usr_123",
"purpose": "personalization",
"previous": "denied",
"current": "granted",
"legal_basis": "consent",
"policy_version": "2025-09",
"captured_at": "2025-10-31T13:21:31Z",
"channel": "web",
"evidence": {
"banner_id": "cmp_v3",
"text_hash": "sha256:...",
"ip": "203. 0. 113. 5",
"ua": "Chrome/142",
"locale": "uk-UA"
}
}

5) Protocolos de señal y distribución

Web/App/SDK: almacenamiento del marcador de consentimiento (cookie/almacenamiento local/almacenamiento seguro) + firma/verificación de integridad; auto-resink con inicio de sesión.
Server-side: headers 'X-Consent-Token '/' X-Purposes', intercambio bidireccional en SSR/edge-renderizado.
Socios/vendedores: emisión en sus formatos (por ejemplo, vector de objetivos, señal general «GPP/TCF»); si falla, señal cero/modo restringido.
Canal offline: registro de audio-concordancia/checkbox por parte del operador, seguido de verificación y enlace a 'subject _ id'.

6) Ejecución: dónde y cómo se «corta» el tráfico

• Bloquear endpoints/campos sin consentimiento (/profile/enrich ,/ads/,/events/track).
• Mutar respuesta/consulta: cortar rastreadores, campos de personalización, identificadores.
• Asignar un contexto de consentimiento a una solicitud de respaldo (etiquetas JWT o encabezados individuales).

• El transformador de eventos elimina/enmascara los campos mediante marcas de consentimiento.
• Marcando datasets: 'dataset. consent_scope=analytics:granted; ads:denied`.
• En la pipeline ML se excluyen los registros sin el consentimiento correspondiente; se desactiva la formación/activación para fines prohibidos.

7) Pseudocódigo: solución en gateway

python def enforce_consent(request, consent_snapshot):
purpose = map_endpoint_to_purpose(request. path) # /ads/ -> "ads"
basis  = consent_snapshot. legal_basis. get(purpose)
status = consent_snapshot. purposes. get(purpose, {}). get("status", "denied")

if basis! = "consent": # e.g. security/contract - allowed without return ALLOW banner

if status!= "granted":
return DENY # or ALLOW with redaction if degradation is allowed

return ALLOW

8) Versificación y probabilidad

Versión del texto de consentimiento: almacena 'policy _ version', 'text _ hash', 'banner _ id'.
Local y región: qué texto y en qué idioma se muestra.
Instantánea en el momento del procesamiento: la capacidad de responder "¿por qué se mostró la publicidad 2025-10-15 a las 09:03? ».
Registro inmutable: WORM/append-only con escritura criptográfica de eventos.

9) Casos especiales

Menores: validación de la edad, consentimiento parental, objetivos y plazos separados.
Invitado → inicio de sesión: fusión de un marcador anónimo con una cuenta; reglas en caso de conflicto (el más estricto gana).
Multiestructuración: resink consistente; cuando se revoca - push-discapacidad tokens en todos los dispositivos.
Regímenes regionales: «estricto» (UE) vs «al por mayor» (algunos mercados) - cambio de presets CMP.
Pruebas A/B: experimentos con datos - un objetivo separado de experimentación; sin ella - sólo pruebas funcionales sin datos personales.
Derecho de eliminación: una revocación puede iniciar la eliminación/anonimización de datos históricos sobre un objetivo (política «purge on revoke»).

10) Anti-patrones

Una caja de comprobación «compartida» para todo.
Falta de versiones de los textos y probabilidad de la exhibición.
Almacenar sólo las cookies de la bandera sin registro del servidor.
Aplicación del consentimiento sólo en IU, pero no en ETL/ML/exportaciones.
Fuentes conflictivas de la verdad (SDK ≠ backend).
Patterns oscuros, la imposición del consentimiento: riesgos legales y de reputación.

11) Observabilidad y métricas

Coverage: una fracción del tráfico con un marcador de consentimiento válido.
Latency PDP: tiempo de decisión en el perímetro.
Drift: discrepancia entre el SDK y la instantánea del servidor.
Revoke SLA: tiempo de revocación → tiempo de desactivación/limpieza completa.
Vendor Compliance: porcentaje de llamadas de afiliados con la señal correcta.
Incidents: intentos de procesamiento sin consentimiento, llamadas bloqueadas.

Dashboards: «embudos de consentimiento», mapa de regiones/canales, tarjetas térmicas de rechazo.

12) Pruebas y verificación

Pruebas contractuales PDP/PEP: tabla de la verdad sobre combinaciones de objetivos/regiones.
Pruebas Chaos/Drift: estados SDK no sincrónicos ↔ servidor; caducidad de la caché TTL.
Versiones CMP: validación A/B de textos y neutralidad UX (sin patrones oscuros).
Seguimiento E2E: evento user-revoke → sin envío a píxeles de afiliados y paipelines.

13) Capacidades interrelacionadas

Anonimización/seudonimización: ejecución de fallos antes y después de la despersonalización.
Cifrado y KMS: protección de marcadores/registro.
Geo-routing: selección de textos/reglas regionales.
Observabilidad: dashboards privados sin PD; correlación sólo por tokens.
Data Lineage: en cada dataset está la huella de los consentimientos.

14) Mini recetas

yaml purposes:
analytics:
legal_basis: consent enforcement: redact_fields: [ad_id, gaid, idfa]
personalization:
legal_basis: consent enforcement: deny_endpoints: [/recs/, /profile/enrich]
security:
legal_basis: legitimate_interest enforcement: allow email_marketing:
legal_basis: consent channel: email

event. meta. consent. analytics = granted    denied event. meta. consent. ads    = denied event. meta. legal_basis    = consent    contract    li

on user_revoke(purpose):
mark subject_id + purpose as "purge_pending"
schedule purge jobs over datasets with lineage(purpose)
emit audit_event("purge_started", scope=purpose)

15) Check-list del arquitecto

1. ¿Existe un registro único y un registro de consentimiento inmutable?
2. ¿Hay objetivos en todas partes que sean atómicos y versionables?
3. ¿Hay ejecución en el perímetro, en los flujos, en la analítica y en el ML?
4. ¿Se ha implementado una política de revocación y depuración de datos históricos?
5. ¿Se han negociado las imágenes de UI/SDK/servidor y los mecanismos de resina?
6. ¿Ha configurado las métricas SLA de Coverage/Drift/Revoke y los informes?
7. ¿Hay un runbook sobre incidentes (infracciones, quejas, regulador)?
8. ¿Se apoyan los regímenes especiales (niños, regiones, socios B2B)?

Conclusión

La gestión de los consentimientos no es una ventana modal, sino una función arquitectónica transversal: desde la declaración de objetivos y la versificación de textos hasta la ejecución automática de decisiones en tiempo real y la posterior presentación de informes. Un modelo de datos riguroso, un registro único, PDP/PEP en todas las capas, telemetría completa y procedimientos de limpieza convierten el cumplimiento en una ventaja competitiva, una plataforma en la que se confía.