La pipeline DLP documental: máscaras que se mantienen

El documento entra una vez; el placeholder se queda

La base de conocimiento de un workspace AI ingiere documentos reales - contratos, cartas de RRHH, facturas. Algunos llevan los datos que nadie debería leer con descuido, y un LLM nunca debería citarlos. La respuesta de Simmetric Chat para los workspaces habilitados: un pipeline de escaneo documental que convierte las entidades sensibles en placeholders numerados a lo largo de todo el documento y guarda la única copia limpia cifrada. El punto del diseño es la última frase - el placeholder se queda: el enmascaramiento es de una vía por construcción, de modo que "el documento" y "el corpus buscable" pasan a ser objetos distintos por diseño.

Este artículo recorre el pipeline como se lo encuentra el operador: el escaneo asíncrono, las tres capas de detección, lo que garantiza un placeholder, qué pasa al re-embeddizar, cómo se guardan los originales, y las dos puertas de unmask (re-composición en el chat, unmask de la vista previa) que hacen la copia limpia alcanzable solo con intención.

Una función opcional de la edición Enterprise, habilitable por workspace y desactivada por defecto (el interruptor del workspace + la puerta de evaluación). El dato: FACT-CENSUS.md F-DLP-1.

El escaneo: asíncrono, en cola, tras el ingest

Cuando el escaneo documental está habilitado para un workspace, cada documento subido pasa por un escaneo asíncrono vía pg-boss después de que el ingest complete - la vía de subida queda responsiva, y el escaneo se comporta como cualquier otro trabajo de fondo de la plataforma: en cola, con reintentos, observable. Un corpus legacy lleva su propio backfill (gated en la evaluación y confirmado explícitamente en la interfaz), limitado por debajo de la cola viva y reanudable: una columna de marca (dlpScannedAt) acota cada re-corrida a los documentos que nunca fueron escaneados.

Detectar: tres capas

La detección es un pipeline de 3 capas, cada una para lo que es:

1. Patrones regex configurables por el admin - el servicio de patrones que el admin cultiva (activa/desactiva cualquier patrón, vistas previas de prueba).
2. La validación por checksum para los identificadores italianos/europeos de formato fijo - Codice Fiscale (la validación de omocodia incluida), P.IVA, IBAN: esas clases son deterministas; una cadena que falla su checksum no es un identificador, así que los números ordinarios nunca las disparan.
3. La detección contextual vía LLM para nombres/direcciones - las clases contextuales pasan por el modelo; su recall es un valor medido y documentado, no una promesa.

Dos clases nombradas son deterministas (los checksums) y dos son contextuales (las clases del LLM) - y la puerta de evaluación mide exactamente esa división: la barra de calidad para habilitarlo = cero falsos positivos suprimidos en las clases deterministas, con el recall de las clases contextuales documentado por corrida.

El número que este post no imprimirá nunca: un recuento de "cuántos tipos de PII existen". El contrato del census es explícito - los números sin rastro no salen; las clases se nombran, el código dice lo que detecta.

Enmascarar: placeholders numerados que no pueden re-empatar

Las entidades detectadas pasan a ser placeholders numerados a lo largo del documento ([PERSON_1], [GOV_ID_2], ...). Tres propiedades lo vuelven significativo:

• Coherencia a lo ancho del documento - la misma entidad es el mismo placeholder en todo el documento; el LLM sigue leyendo un documento coherente.
• Idempotencia - el enmascaramiento es su propio punto fijo: la sintaxis del placeholder nunca puede re-empatar, así que un re-escaneo jamás produce artefactos de clase [PERSON_1_1].
• La reescritura es total - los chunks se reescriben con el texto enmascarado, los vectores FTS se recaptulan, y los embeddings se re-generan sobre el texto enmascarado. Ningún vector no tachado queda buscable.

Cifrar: la única copia limpia es AES-256-GCM

El texto original y cada valor de entidad aterrizan cifrados (AES-256-GCM bajo el contrato de clave de la plataforma). Eso vuelve honesto al pipeline: el enmascaramiento no es "esconder en una capa de vista" - los bytes no tachados simplemente no existen sin cifrar en el almacén. Los originales cifrados son la única copia limpia.

Las dos puertas de unmask

La copia limpia se alcanza por exactamente dos puertas, ambas explícitas:

1. Re-composición en el chat - al final del stream, exactamente una vez, el servidor re-compone los placeholders en el mensaje terminal solo para usuarios con el permiso dlp:unmask en el workspace del documento citado. El texto re-compuesto viaja en el payload done del SSE; los visitantes del widget jamás reciben texto re-compuesto (impuesto en el servidor, no ocultando un botón).
2. Unmask de la vista previa - el endpoint del texto documental sirve el texto enmascarado por defecto; un parámetro de unmask vale sólo por la escalera de la puerta (el parámetro presente, el interruptor del workspace activo, el rol resolviendo el permiso). Cada brazo que falla sigue devolviendo texto enmascarado con un 200 - el endpoint no es nunca un oráculo de derechos.

La matriz de audit

Cada vía de lectura queda clavada por un test de comportamiento (la vista del texto, la vista previa OCR, la síntesis, las citas, el widget, las herramientas MCP, la búsqueda de texto completo, los exports, el re-embed del admin). Los tres clavos más duros son los brazos del "nunca": los visitantes del widget, las superficies de citas, y las herramientas MCP reciben texto enmascarado y nunca una re-composición. La clase del registro de audit (el log inmutable de la plataforma, F-AUDIT-1) anota las operaciones que tocan la superficie.

Para seguir

La guía lleva el recorrido completo del operador - el interruptor, el corredor de evaluación, el backfill, cada endpoint - en /es/docs/document-dlp-pipeline:

• Document DLP pipeline - la guía
• Datos de este post: filas FACT-CENSUS.md F-DLP-1 (el pipeline), F-DLP-2 (la decisión del recuento sin rastro), F-AUDIT-1 (el registro de eventos)

Provenance: Simmetric Chat docs/DLP_DOCUMENT_PIPELINE.md (v0.28.1, Phase 192 DLP-01..06), packages/server/src/services/ (dlpPatternService/dlpChecksum/quota services), encryptionService - en el estado documental fijado por el census (SHA aca5b8ff).