Dossier Enclave B2B Privacy & Zero-Data Retention

Última actualización: 8 de julio de 2026
Clasificación del Documento: Confidencial / Privilegiado / Anexo de Cumplimiento B2B

RECITALS & MARCO JURÍDICO APLICABLE

Esta Política de Privacidad (en adelante, la "Política") detalla los compromisos contractuales, salvaguardas y especificaciones técnicas que el Licenciante (en adelante, "Dossier Enclave" o el "Operador") implementa de forma inalterable para garantizar la confidencialidad, integridad y soberanía de los datos sensibles ingresados por la Firma en el Aplicativo.

La arquitectura del Aplicativo se rige por el principio de Privacidad por Diseño (Privacy-by-Design). Sus parámetros de seguridad, saneamiento y gobernanza de la información están estrictamente alineados con la convergencia de dos marcos regulatorios y éticos de alto rigor profesional:

  1. La Norma 1.6 de las Reglas Modelo de Conducta Profesional de la American Bar Association (ABA Rule 1.6): Que exige a las firmas de abogados realizar "esfuerzos razonables" y adoptar medidas técnicas avanzadas para evitar la divulgación no autorizada o el acceso accidental a la información confidencial de sus clientes.
  2. La Doctrina de Preservación del Privilegio (Estándar Heppner): Derivada del precedente federal norteamericano United States v. Heppner. Este estándar establece que el uso de herramientas de procesamiento que retengan o almacenen de manera persistente datos de los clientes en servidores de terceros puede destruir el privilegio abogado-cliente (Attorney-Client Privilege), exponiendo la información a procesos de revelación forzosa (discovery). Para preservar este blindaje, la infraestructura de Dossier Enclave está diseñada para actuar estrictamente como un conducto necesario efímero y nunca como un depósito de almacenamiento.

Al utilizar el Aplicativo, la Firma declara conocer y aceptar que la totalidad de los flujos de datos se sujetará estrictamente a los términos de esta Política.


SECCIÓN PRIMERA: NATURALEZA DUAL DEL TRATAMIENTO DE DATOS (RESPONSABLE VS. ENCARGADO)

Para efectos de la legislación de protección de datos personales y privacidad corporativa, el tratamiento de la información dentro del Aplicativo se divide estrictamente en dos capas operativas independientes:

1.1. El Operador como "Responsable del Tratamiento" de Metadatos de Registro B2B.
El Operador actúa como Responsable únicamente respecto a la información de contacto, credenciales de acceso y facturación del personal autorizado de la Firma (tales como nombre del abogado, correo corporativo, datos transaccionales de cobro e identificadores lógicos de sesión).

  • Finalidad Limitada: La única finalidad del tratamiento de estos metadatos es el aprovisionamiento de las fichas de acceso, la gestión del cobro del cargo de configuración inicial (Setup Fee) y de la suscripción mensual, y la auditoría de seguridad del portal de entrada (Token Gate).

1.2. El Operador como "Encargado del Tratamiento" de la Evidencia Legal (Carga Útil o Payload).
Respecto a la totalidad de los datos sensibles, secretos comerciales y documentos fácticos de los clientes de la Firma (tales como extractos bancarios, actas corporativas, currículums, declaraciones de impuestos, organigramas, contratos y planes estratégicos) que son ingresados al Aplicativo para su análisis forense y estructuración de expedientes corporativos, la Firma actúa como la única y exclusiva "Responsable del Tratamiento", y el Operador opera estrictamente en calidad de "Encargado del Tratamiento".

  • Instrucción Contractual Exclusiva: El Operador procesará dicha carga de datos únicamente bajo la instrucción digital e interactiva del abogado adquirente al presionar el comando de ejecución, de conformidad con el Adendum de Preservación de Privilegio Legal incorporado a los Términos de Servicio. El Operador carece de autonomía para utilizar dicha información para fines diversos a los expresamente autorizados.

SECCIÓN SEGUNDA: LA DOCTRINA DEL PROCESAMIENTO ESTRICTAMENTE EFÍMERO (ZERO-DATA RETENTION – ZDR)

El pilar de seguridad y cumplimiento fiduciario sobre el cual se edifica Dossier Enclave es la imposibilidad fáctica y técnica de retención de información. El Aplicativo opera bajo las siguientes reglas innegociables de almacenamiento y procesamiento:

2.1. Cero Escritura en Disco Persistente (RAM-Only Processing).
Toda la evidencia legal, documentos e insumos provistos por la Firma son procesados temporalmente en la memoria de acceso aleatorio (RAM) volátil del contenedor de cómputo de nuestra infraestructura.

  • Aislamiento Físico (/dev/shm): El sistema escribe los archivos temporales directamente en el sistema de archivos virtual en memoria volátil de los contenedores, eludiendo por completo la capa de almacenamiento en discos físicos de estado sólido (SSD) en reposo. Los archivos e información ingresados se tratan exclusivamente como datos en tránsito.

2.2. Clausura Absoluta del Motor Cognitivo (Anti-Training Shield).
El Operador garantiza contractualmente que las peticiones de inferencia lingüística y estructuración forense se canalizan de forma exclusiva a través de interfaces de programación de aplicaciones (APIs) corporativas con la retención de logs y telemetría de entrenamiento desactivada por defecto en el proveedor de modelos.

  • Garantía de No Ingesta: Ningún dato confidencial, proyección financiera o secreto comercial enviado por la Firma será utilizado para el entrenamiento, re-entrenamiento, ajuste fino (fine-tuning) o calibración de los pesos de los modelos de inteligencia artificial propios o de terceros.

2.3. Saneamiento del Lado del Cliente (RAM Wipe en Frontend).
La higiene de datos se aplica de extremo a extremo. Al completarse la transmisión de los resultados, o en el evento de ocurrir un fallo de validación o un error de red, el frontend del Aplicativo ejecutará una función de limpieza inmediata (finally block). Esta función sobrescribe y purga inmediatamente el espacio de memoria RAM del navegador del usuario, convirtiendo en valores nulos (null) la evidencia legal cruda para evitar que permanezca de forma latente en el dispositivo del abogado.

SECCIÓN TERCERA: EL CICLO DE VIDA EFÍMERO Y LA PURGA AUTOMÁTICA A LOS 60 MINUTOS

Para extinguir de forma definitiva la responsabilidad por custodia de la información y proteger la confidencialidad de la Firma, la persistencia temporal de los reportes y expedientes generados dentro del Aplicativo está sujeta a una estricta y automatizada "bomba de tiempo" digital.

3.1. Activación del Programador de Tareas Efímero.
En el microsegundo exacto en que concluye el ensamblaje y renderizado del expediente final en formato PDF en el contenedor de cómputo, el orquestador de la infraestructura de red del Operador programa de forma determinista una tarea de destrucción en su cola de ejecución de sistemas de alta seguridad. Esta tarea cuenta con un tiempo de vida (Time-To-Live - TTL) inalterable e improrrogable de 60 minutos (3,600 segundos).

3.2. Ejecución del Borrado Doble Síncrono.
Al cumplirse la ventana temporal de 60 minutos, el programador de tareas despierta de forma automatizada un microservicio de saneamiento de un solo propósito que ejecuta una purga doble síncrona:

  1. Purga Binaria en la Capa de Almacenamiento: Se realiza la destrucción física e irreversible del archivo PDF del expediente. La política de almacenamiento de nuestra infraestructura en la nube tiene completamente inhabilitada la función de papelera de reciclaje o recuperación pasiva (Soft-Delete), ejecutando un Hard Delete inmediato.
  2. Purga de Metadatos en la Capa de Base de Datos: Se ejecuta la eliminación síncrona de todos los campos, registros lógicos, tablas de datos e identificadores transitorios asociados al proceso en la base de datos temporal de la sesión.

3.3. Certificación Criptográfica Post-Purga (Proof of Purge).
Una vez concluida la destrucción física del archivo y sus metadatos lógicos, la función de borrado de la infraestructura calcula y emite de forma autónoma una firma criptográfica inmutable en los registros de auditoría de red de nuestra infraestructura segura. Este registro contiene exclusivamente la fórmula matemática y servirá como Certificado Oficial de Destrucción de Datos (Proof of Purge), el cual se remite automáticamente al correo electrónico de la Firma para certificar el cumplimiento de los estándares éticos pactados sin necesidad de retener el documento confidencial original.

SECCIÓN CUARTA: GEOGRAFÍA DEL PROCESAMIENTO Y SOBERANÍA TERRITORIAL DE LOS DATOS (US-ONLY DATA BOUNDARY)

4.1. Confinamiento Territorial del Plano de Datos (US-to-US Containment).
El Operador garantiza contractualmente que la totalidad del ciclo de vida del procesamiento de datos confidenciales —incluyendo la ingesta de archivos de soporte, la tokenización, la inferencia matemática del motor cognitivo, el ensamblaje de capítulos y el renderizado final del expediente en formato de impresión— ocurre de manera exclusiva en servidores físicos y de red localizados dentro de las fronteras lógicas y geográficas de los Estados Unidos de América.

  • Regiones Seguras: Las instancias y microservicios de cómputo efímero asignados a la sesión de la Firma se restringen estrictamente a zonas de red seguras localizadas en territorio estadounidense.
  • Prohibición de Tránsito Transfronterizo: Los datos confidenciales de los clientes de la Firma nunca son replicados, enrutados, distribuidos ni almacenados temporalmente en centros de datos ubicados fuera de los Estados Unidos de América.

4.2. Desacople Absoluto de Plano de Control y Plano de Datos (Control Plane Decoupling).
La Firma acepta y reconoce que las actividades de mantenimiento del código fuente, configuración de infraestructura como código (IaC), soporte operativo lógico y administración del sistema son ejecutados de manera remota por el equipo de ingeniería del Operador (el cual se encuentra distribuido de forma global, incluyendo personal en la República de Colombia). Sin embargo, para blindar la Regla ABA 1.6 de confidencialidad, la arquitectura impone un desacople estricto de accesos:

  1. Aislamiento de Carga Útil (Payload Isolation): Ningún desarrollador, administrador de sistemas o personal de soporte del Operador tiene acceso, facultad ni canales técnicos para visualizar, interceptar o descargar la evidencia fáctica cargada por la Firma o el expediente PDF estructurado resultante.
  2. Inexistencia de Acceso por Base de Datos: Debido a la arquitectura de Zero-Data Retention (ZDR), no existen registros de bases de datos persistentes en reposo que puedan ser consultados de forma remota por el personal de ingeniería.
  3. Sanitización de Logs y Telemetría: Los paneles de observabilidad de infraestructura y los registros de error en el plano de control externo se limitan estrictamente a telemetría de rendimiento técnico cuantitativo (tales como latencia de red, volumen de memoria RAM asignada, códigos de respuesta de red o recuento de tokens de procesamiento). Se prohíbe la captura de payloads, cadenas de texto fiduciario, cifras financieras o identificadores reales en cualquier log de diagnóstico estándar.

SECCIÓN QUINTA: ESTÁNDAR DE SEGURIDAD Y ROBUSTECIMIENTO DE LA INFRAESTRUCTURA (APPSEC HARDENING)

El búnker virtual de procesamiento del Aplicativo implementa un esquema de Seguridad Defensiva en Profundidad diseñado bajo los estándares más estrictos de la industria de software legal de alta sensibilidad:

5.1. Cifrado de Datos de Extremo a Extremo (In-Transit Encryption).

  • Canal Seguro: Todo flujo de datos entre la terminal de trabajo local de la Firma y las pasarelas de entrada del Aplicativo se encripta obligatoriamente mediante protocolos criptográficos criptoseguros Transport Layer Security (TLS 1.3) o superior.
  • Cripto-Fragmentación (Crypto-Shredding): Durante el procesamiento temporal en la memoria RAM volátil, las cargas de trabajo de la sesión se aíslan lógicamente utilizando llaves de encriptación únicas y exclusivas para cada transacción. Al concluir el ciclo de vida de la transacción a los 60 minutos, la destrucción atómica de la clave de encriptación de sesión asegura que cualquier residuo físico en los chips de silicio de la infraestructura sea matemáticamente irrecuperable.

5.2. Aislamiento Hermético del Contenedor de Impresión (Air-Gapped Document Rendering).
El microservicio dedicado a transformar el expediente estructurado a su formato de impresión PDF opera dentro de un entorno de ejecución contenedorizado y lógicamente aislado (Air-Gapped Sandbox).

  • Mitigación de SSRF (Server-Side Request Forgery): El motor de renderizado de impresión tiene completamente inhabilitada y bloqueada la capacidad de ejecutar consultas externas de red o solicitudes de protocolo HTTP/HTTPS hacia internet. Esta restricción previene de manera absoluta que payloads o imágenes maliciosas incrustadas en los archivos de los clientes puedan ser utilizados como vectores para extraer metadatos de seguridad o credenciales de la red interna del Operador.

5.3. Sanitización Perimetral de la Sesión en Navegador (Pre-Handshake Wiping).
Para repeler vulnerabilidades asociadas a la persistencia residual en el lado del cliente o interceptación de tokens por extensiones maliciosas instaladas en el navegador de la Firma:

  1. Barrido del Historial: Una vez que la abogada ingresa a la sesión de trabajo segura mediante su enlace criptográfico efímero de acceso (Magic Link), el frontend de la plataforma captura el token, lo traslada exclusivamente a una variable de estado en memoria volátil y ejecuta un comando de sobreescritura inmediata del historial del navegador (window.history.replaceState).
  2. Ocultación de Referer: Este procedimiento limpia por completo la barra de direcciones, evitando que la clave criptográfica quede registrada en los logs locales de navegación o se filtre en los encabezados HTTP ante saltos de página.

SECCIÓN SEXTA: DERECHOS DE ACCESO, RECTIFICACIÓN Y CONTROL DE LA FIRMA (DATA SUBJECT CONTROL UNDER EPHEMERAL ARCHITECTURE)

6.1. Cumplimiento por Amnesia Física.
Dada la arquitectura de procesamiento temporal del Aplicativo, las solicitudes tradicionales de acceso, rectificación, cancelación u oposición de datos (derechos de privacidad y control de información de los titulares) se resuelven de forma material y biológica por el propio diseño de la infraestructura:

  • Imposibilidad de Consulta Histórica: Debido a que el Operador no almacena, archiva ni conserva datos en reposo una vez transcurridos los 60 minutos de la transacción, el Operador es física y legalmente incapaz de "entregar", "modificar" o "borrar" registros históricos a solicitud de la Firma o de sus clientes finales, en tanto que dichos registros han dejado físicamente de existir en la realidad.
  • Garantía de Saneamiento: El derecho al borrado se ejecuta de forma automatizada y por defecto en cada transacción, extinguiendo cualquier riesgo de persistencia involuntaria.

6.2. Procedimiento de Corrección de Datos en Sesión Activa.
Si durante la ventana activa de procesamiento de 60 minutos la Firma detecta que la evidencia cargada contiene imprecisiones fácticas, errores tipográficos o requiere modificaciones estratégicas:

  1. La Firma deberá corregir los parámetros directamente en los campos de entrada de la interfaz del Aplicativo.
  2. Al enviar la nueva solicitud, el sistema destruirá de inmediato el entorno de RAM anterior, inyectará los nuevos parámetros y generará un nuevo ciclo de procesamiento con su respectiva ventana temporal independiente de 60 minutos, garantizando la estanqueidad y exactitud del nuevo expediente.

SECCIÓN SÉPTIMA: GOBERNANZA, MODIFICACIONES Y SOPORTE DE INCIDENCIAS LÓGICAS

7.1. Control de Versiones Documentales (Docs-as-Code).
En alineación con las políticas de gobernanza de la organización, esta Política de Privacidad es un artefacto vivo pero inmutable en su historial. Toda modificación a este documento será registrada bajo un control de versiones estricto, requiriendo la aprobación conjunta de la Dirección de Cumplimiento Normativo y la Dirección Ejecutiva, y se congelará de forma cifrada en el repositorio maestro del Licenciante.

7.2. Protocolo de Soporte Fiduciario ante Expiración de Descarga (Error 404).
En caso de que la Firma experimente problemas de conectividad local o cortes eléctricos que impidan la descarga del PDF final antes de su auto-destrucción a los 60 minutos, el canal de soporte técnico operará estrictamente bajo las siguientes reglas de protección de datos:

  1. Prohibición de Almacenamiento Intermedio: El agente de soporte tiene estrictamente prohibido solicitar a la Firma el envío de la evidencia cruda o de los reportes generados por correo electrónico, WhatsApp o canales de chat abiertos.
  2. Activación de Re-Run Idempotente: El soporte técnico autorizará la reactivación de la tarea de compilación únicamente mediante el uso del identificador transaccional encriptado (transaction_id) asociado a la orden original. Este token permitirá a los servidores efímeros levantar un contenedor limpio en RAM, procesar las variables de entrada originales y habilitar una nueva ventana efímera de descarga de 60 minutos, asegurando que el dato fiduciario nunca toque almacenamiento permanente.