MCL · OneTrust · Análisis de integración

Reconciliación de modelos de datos:
middleware de consentimiento ↔ modelo OneTrust de Mapfre

Proyecto mcl-onetrust · Estado análisis para decisión · 23 de junio de 2026
Insumos: respuesta de Nelson Quintanilla (Mapfre) del 10 de junio de 2026 y su modelo de datos adjunto; esquema Oracle del middleware (capa de persistencia ya diseñada).

En una frase: el modelo de datos que entregó Mapfre y el esquema del middleware (MW) parten de filosofías opuestas —Mapfre guarda el consentimiento completo; el MW no lo guarda y solo lo despacha—. No es un conflicto de columnas: es una decisión de arquitectura que conviene cerrar con Mapfre antes de avanzar.

Quedan tres puntos concretos por resolver y un conjunto de consultas para Mapfre al final de este documento.

1. Punto de partida

Mapfre respondió el levantamiento técnico y adjuntó su modelo de datos de OneTrust (seis tablas en su base prdman). Por nuestro lado ya existe el esquema Oracle del MW. Al ponerlos lado a lado aparece una diferencia de fondo en qué persiste cada uno.

MAPFRE Modelo entregado

Seis tablas. Guarda el consentimiento y su evidencia.

A9009072_MCL — registro de consentimientos (con receipt, versión de propósito, respuesta y estado de revocación)
A9009082_MCL — cola de sincronización hacia OneTrust
G2999731 / G2999728 — propósitos y sus versiones
G2999761 / G2999733 — puntos de recolección y su relación con cada propósito

MIDDLEWARE Esquema diseñado

Ocho tablas + paquetes PL/SQL. No guarda el consentimiento: lo despacha.

Bandeja de salida (outbox) de mensajes a despachar, con reintentos y arrendamiento
Reserva de idempotencia con respuesta en caché
Auditoría inmutable (solo inserción) y pares petición/respuesta saneados
Claves de API por satélite, control de tasa por ventana deslizante

Fuente del lado MW: esquema Oracle del repositorio (directorio de DDL del middleware). Detalle de rutas en el anexo.

2. Cómo se relacionan los dos modelos: lo confirmado y lo abierto

De las seis tablas de Mapfre, hoy solo hay una relación confirmada: el catálogo de propósitos alimenta la pantalla del satélite, que lo usa para mostrar al usuario la lista de propósitos a consentir. En cambio, cómo el registro de consentimientos y la cola de sincronización se relacionan con el middleware —ambos al mismo nivel— está sin definir, y es el centro de la reconciliación.

relación confirmada relación sin definir (❓)

Lo único confirmado: el catálogo de propósitos (G…) alimenta la pantalla del satélite. Cómo el registro y la cola de Mapfre (A…) se relacionan con el middleware —ambos al mismo nivel— y quién despacha finalmente a OneTrust son las preguntas abiertas.

3. Dos filosofías de persistencia

Dimensión	Middleware (MW)	Modelo Mapfre
Estado del consentimiento	No lo guarda. Viaja dentro del cuerpo del mensaje de salida.	Lo guarda completo en `registro_consentimientos`.
Fuente de verdad	OneTrust. La lectura se resuelve contra OneTrust en tiempo real.	Conserva copia local para trazabilidad (Ley 21.719).
Receipt de OneTrust	No se persiste; queda en caché temporal de idempotencia.	Se persiste en `txt_evidencia_receipt_jwt`.
Identificador del titular	Solo el hash (SHA-256). Nunca el RUT en claro.	RUT en claro (`tip_docum`/`cod_docum`).
Propósitos y versiones	No se modelan.	Catálogo versionado propio; lo lee el satélite.

4. Mapa de correspondencia

Concepto	Modelo Mapfre	Middleware	Veredicto
Consentimiento del titular	`A9009072` (tabla completa)	dentro del cuerpo del mensaje de salida	filosofía distinta
Cola de envío a OneTrust	`A9009082 cola_sync_onetrust`	`outbox_mensajes`	posible duplicación
Receipt de OneTrust	`txt_evidencia_receipt_jwt`	no se persiste	sin camino de retorno
Identificador del titular	RUT en claro	hash SHA-256	frontera de datos personales
Catálogo de propósitos	`G2999731` + `G2999728` (lo lee el satélite)	no se modela	relación confirmada
Idempotencia	sin definir (consulta pendiente)	`idempotencia_respuestas`	solo MW
Auditoría · tasa · claves API	no aparece	resuelto en el MW	solo MW

5. Los tres puntos a resolver

Dos colas hacia OneTrust. Mapfre tiene cola_sync_onetrust con estado y reintentos; el MW tiene su bandeja de salida con la misma función. Dos colas de envío resiliente al mismo destino son redundancia o un malentendido de responsabilidad. Hay que definir quién despacha a OneTrust: el MW a través de su bandeja de salida, o Mapfre a través de su cola.
El receipt no tiene camino de retorno. Mapfre quiere el receipt en su tabla, pero OneTrust lo emite cuando se despacha —de forma asíncrona, después del 202—. El MW hoy no lo persiste ni lo devuelve; solo lo retiene en caché con vencimiento. Falta definir cómo llega ese comprobante a registro_consentimientos: devolución por llamada de retorno, consulta posterior, o una vía nueva.
RUT en claro frente a hash. Todo el diseño de protección de datos del MW parte de no tocar el RUT en claro (se guarda solo su hash). Mapfre lo conserva en claro para su trazabilidad legal. Es una decisión coherente de su lado, pero marca la frontera donde el dato personal entra y sale, y condiciona qué viaja hacia el MW.

6. Consultas para Mapfre

Para cerrar la reconciliación se necesita confirmar con Mapfre la relación entre los dos modelos. Estas son las preguntas que destraban la decisión.

Relación del registro y la cola con el middleware. Entendemos que el catálogo de propósitos (G…) alimenta la pantalla del satélite. Sobre las otras dos tablas: ¿cómo se relacionan A9009072 registro_consentimientos y A9009082 cola_sync_onetrust con el middleware? ¿El MW escribe en ellas, las lee, o son un camino paralelo de Mapfre hacia OneTrust?
Responsable del despacho. Si cola_sync_onetrust ya existe del lado de Mapfre, ¿quién envía a OneTrust: Mapfre a través de esa cola, o el middleware a través de su bandeja de salida? ¿Conviven o una reemplaza a la otra?
Retorno del comprobante. El receipt lo emite OneTrust de forma asíncrona al despachar. ¿Cómo espera Mapfre recibirlo para guardarlo en registro_consentimientos: respuesta de una consulta posterior, notificación de retorno, u otra vía?
Frontera del RUT. ¿El middleware debe recibir el RUT en claro para construir el envío a OneTrust, o Mapfre prefiere que el dato en claro no salga de su dominio?
Lectura del catálogo desde el middleware. Confirmado que el satélite lee el catálogo para la lista de propósitos. ¿El middleware también necesita leerlo (por ejemplo, para resolver o validar la versión vigente del propósito al despachar), o el satélite ya entrega la versión consentida dentro del envío?

Anexo

A · Modelo de datos entregado por Mapfre

Esquema de datos de OneTrust que entregó Mapfre (base prdman): catálogo de propósitos (G2999731) y sus versiones (G2999728), puntos de recolección (G2999761) y su relación con cada propósito (G2999733), registro de consentimientos (A9009072) y cola de sincronización hacia OneTrust (A9009082).

Modelo de datos de OneTrust entregado por Mapfre: tablas de propósitos, versiones, puntos de recolección, registro de consentimientos y cola de sincronización, con sus relaciones de clave foránea — Modelo de datos original de Mapfre (base `prdman`). Es el insumo que este documento interpreta.

B · Referencias del esquema del middleware

Objetos Oracle del MW citados en este documento, para el equipo técnico interno.

Bandeja de salida y su paquete de operaciones —encolar, tomar pendientes con arrendamiento, marcar enviado o descartado—.

ddl/01_mmw_cns_outbox_mensajes.sql · ddl/08_mmw_cns_k_outbox.sql · ddl/14_mmw_cns_k_outbox_body.sql

Reserva de idempotencia con respuesta en caché y vencimiento.

ddl/02_mmw_cns_idempotencia_respuestas.sql · ddl/09_mmw_cns_k_idempotencia.sql · ddl/15_mmw_cns_k_idempotencia_body.sql

Auditoría inmutable y pares petición/respuesta saneados.

ddl/05_mmw_cns_auditoria_log.sql · ddl/06_mmw_cns_auditoria_req_resp.sql

Identidad de negocio del consentimiento (id_consentimiento) y hash del sujeto, añadidos en el delta 16.

ddl/16_mmw_cns_outbox_identity.sql · ddl/18_mmw_cns_k_outbox_delta_t8x.sql