Garantía de anonimización de datos en JMAX
AUTOONOMIA GLOBAL
Asistente autónomo JMAX
DECLARACIÓN DE GARANTÍA
Protección y anonimización de datos personales
Documento de garantía contractual para clientes corporativos
Se entrega como anexo al contrato de licenciamiento y forma parte integral del mismo.
| Concepto | Detalle |
| Producto | JMAX — asistente autónomo de escritorio |
| Versión del documento | 1.0 |
| Fecha de emisión | 29 de agosto de 2026 |
| Emitido por | Autoonomia Global |
| Marco de referencia | RGPD (UE) 2016/679 · Directrices EDPB 02/2026 sobre seudonimización · ISO/IEC 42001:2023 |
| Vigencia | Mientras el cliente opere la versión entregada sin modificar sus componentes de privacidad |
1. Objeto de esta declaración
Este documento describe, en términos verificables, qué garantiza JMAX respecto al tratamiento de datos personales, cómo lo garantiza y cómo el cliente puede comprobarlo por sí mismo sin depender de la palabra del proveedor.
La diferencia entre una promesa comercial y una garantía es que la segunda se puede verificar. Por eso cada afirmación de este documento va acompañada del mecanismo técnico que la sostiene y del procedimiento con el que el cliente la comprueba (sección 8).
A quién va dirigido
- Responsables de cumplimiento y DPO: que necesitan una base defendible ante una auditoría o una inspección.
- Responsables de seguridad de la información: que deben saber qué sale del equipo y qué no, y bajo qué control.
- Dirección y áreas de negocio: que necesitan garantías por escrito antes de introducir información de sus propios clientes en una herramienta de IA.
2. La garantía en una página
JMAX se ejecuta íntegramente en el equipo del cliente. No es un servicio en la nube con una capa de privacidad añadida: es un producto local al que el cliente puede, si quiere, conectarle modelos externos. Esa diferencia de origen es la que hace posible todo lo demás.
| Nº | Lo que se garantiza | Mecanismo que lo sostiene |
| G1 | Sin conectar un proveedor externo, ningún dato del cliente sale del equipo. | Arquitectura local: modelo, memoria, índice documental y bitácoras residen en el equipo del cliente. |
| G2 | Con proveedores externos conectados, ningún turno que contenga datos personales sale sin control explícito. | Cortafuegos de datos personales delante de todo cliente de modelo no local. Falla en cerrado. |
| G3 | Datos de salud, credenciales y tarjetas de pago NUNCA salen del equipo, en ninguna configuración. | Categorías críticas excluidas de toda vía de salida, incluida la seudonimizada. No es configurable. |
| G4 | Cuando el cliente autoriza el uso de un modelo externo, los datos personales viajan sustituidos por marcadores. | Pasarela de seudonimización; el mapa de reversión existe solo en memoria y se destruye al cerrar el turno. |
| G5 | Los documentos de un espacio marcado como «datos de clientes» se indexan sin datos personales. | Sustitución por marcadores antes del troceado; mapa de reversión en archivo separado (RGPD art. 4.5). |
| G6 | Lo almacenado puede quedar ilegible fuera del equipo. | Cifrado en reposo AES-256 de las bases, con clave derivada del equipo que nunca viaja. |
| G7 | Nada se conserva indefinidamente y una persona puede ser borrada. | Política de retención por tipo de dato y función de olvido que barre todas las superficies, con constancia. |
| G8 | Todo fallo queda registrado de forma trazable y sin datos personales. | Bitácora estándar con identificador de rastreo y enmascarado automático previo a la escritura. |
3. Marco normativo de referencia
Las garantías anteriores se han diseñado contra obligaciones concretas, no contra principios genéricos. La correspondencia es la siguiente:
| Norma / artículo | Obligación | Cómo responde JMAX |
| RGPD art. 4.5 | Definición de seudonimización: la información adicional se guarda por separado y con medidas técnicas. | El mapa de reversión vive en un archivo distinto del de la memoria y puede cifrarse de forma independiente. |
| RGPD art. 5.1.c | Minimización: solo los datos necesarios. | El turno que sale a un proveedor externo lleva marcadores en lugar de identidades. |
| RGPD art. 5.1.e | Limitación del plazo de conservación. | Plazos configurables por tipo de dato y barrido automático. |
| RGPD art. 17 | Derecho de supresión. | Función «olvidar a…» que barre conversaciones, memoria episódica, fragmentos documentales, calificaciones, memoria de agentes, bitácoras y mapa de seudónimos. |
| RGPD art. 25 | Protección de datos desde el diseño y por defecto. | El cortafuegos viene activado de fábrica; el modo permisivo exige una acción deliberada del cliente por cada proveedor. |
| RGPD art. 32 | Seguridad del tratamiento: cifrado y seudonimización. | Cifrado en reposo AES-256 y seudonimización en dos puntos (tránsito e ingesta). |
| EDPB 02/2026 | Evidencia del análisis de riesgo de reidentificación. | JMAX genera, por espacio de trabajo, la hoja de evaluación con las tres pruebas: singularización, vinculabilidad e inferencia. |
| ISO/IEC 42001 A.7.3–A.7.6 | Gestión de datos en sistemas de IA. | Registro de procedencia de cada documento ingerido, política de retención documentada y trazabilidad de errores. |
Aclaración necesaria: este documento declara alineación con los requisitos citados y aporta los mecanismos que los soportan. No constituye ni sustituye una certificación emitida por un organismo acreditado.
4. Cómo se sostiene la garantía: cinco barreras
La protección no descansa en un único control. Son cinco barreras independientes: para que un dato personal del cliente acabe en manos de un tercero tendrían que fallar varias a la vez.
Barrera 1 — El producto se ejecuta en el equipo del cliente
El modelo de lenguaje, la memoria, el índice de documentos y las bitácoras residen en la máquina del cliente o en el servidor que el cliente controle. Sin proveedores externos configurados, JMAX es un sistema cerrado: no hay ninguna ruta por la que la información salga.
Barrera 2 — Cortafuegos de datos personales
Cuando el cliente conecta un modelo externo, todo turno pasa antes por un detector que funciona sin conexión y sin enviar nada a ningún sitio. Reconoce nombres con contexto, documentos de identidad, cédulas y NIT, correos, teléfonos, direcciones, cuentas bancarias, tarjetas (con validación Luhn), fechas de nacimiento, credenciales y vocabulario de salud.
Si detecta datos personales, el turno no sale: lo atiende el modelo local. El diseño falla en cerrado — ante la duda sobre si un destino es local o externo, se le trata como externo.
Barrera 3 — Pasarela de seudonimización
Para el cliente que sí quiere aprovechar un modelo grande en la nube con material que contiene datos personales, cada proveedor se configura en uno de dos modos:
- Bloquear (predeterminado): todo turno con datos personales se queda en el equipo.
- Seudonimizar: los datos salen sustituidos por marcadores estables ([PERSONA_1], [CORREO_1]) y la respuesta vuelve completa al usuario. El mapa marcador→valor existe únicamente en memoria volátil y se destruye al cerrar el turno: no se escribe en disco, no se registra y no entra en la memoria del sistema.
Los marcadores son estables dentro del turno, de modo que el modelo puede razonar sobre las relaciones («[PERSONA_1] es el jefe de [PERSONA_2]») sin conocer a nadie.
Barrera 4 — Protección de lo almacenado
Dos controles independientes sobre lo que queda en disco:
- Cifrado en reposo: las bases de datos se cifran con AES-256 (SQLite3 Multiple Ciphers). La clave se deriva de un secreto aleatorio protegido por el sistema operativo y del identificador del equipo: no viaja, no se teclea y copiar el archivo a otra máquina no sirve de nada.
- Seudonimización en la ingesta: los documentos que entren en un espacio marcado como «datos de clientes» se seudonimizan ANTES de trocearse para el buscador semántico. Lo que se indexa, se vectoriza y se envía a cualquier modelo lleva marcadores. El mapa de reversión se guarda en un archivo separado del de los datos.
Barrera 5 — Retención, olvido y trazabilidad
Cada tipo de dato tiene un plazo configurable y un barrido automático lo aplica. La función de olvido busca a una persona en todas las superficies donde el sistema guarda texto y la elimina, dejando constancia de qué se barrió, cuándo y cuántas coincidencias hubo — sin reintroducir el dato borrado en el registro. Todo fallo se registra con un identificador de rastreo y con los datos personales enmascarados antes de escribirse.
5. Comportamiento por categoría de dato
Esta tabla es el compromiso operativo. Describe qué hace el sistema con cada categoría según el modo configurado para el proveedor externo.
| Categoría de dato | Modo «bloquear» | Modo «seudonimizar» |
| Salud (diagnósticos, medicación, dolencias) | No sale. Lo atiende el modelo local. | NO SALE. Excluido de la seudonimización. |
| Credenciales y contraseñas | No sale. | NO SALE. Excluido. |
| Tarjetas de pago (validadas con Luhn) | No sale. | NO SALE. Excluido. |
| Nombre de persona | No sale. | Sale como [PERSONA_n]. |
| Documento de identidad, cédula, NIT | No sale. | Sale como [DOCUMENTO_n]. |
| Correo electrónico | No sale. | Sale como [CORREO_n]. |
| Teléfono | No sale. | Sale como [TELEFONO_n]. |
| Dirección postal | No sale. | Sale como [DIRECCION_n]. |
| Cuenta bancaria / IBAN | No sale. | Sale como [CUENTA_n]. |
| Fecha de nacimiento | No sale. | Sale como [FECHA_NACIMIENTO_n]. |
Salud, credenciales y tarjetas reciben el trato más estricto. Con el modo «bloquear» —el que traen de fábrica todos los proveedores externos— no salen del equipo en ninguna circunstancia. El titular puede relajar esa regla proveedor por proveedor desde la pantalla de Seguridad y controles, y es una decisión suya y consciente: al hacerlo asume que esos turnos salgan. Un marcador protege la identidad de una persona, pero no el hecho de que esté enferma, así que cuando el titular elige «seudonimizar» o «permitir», el contexto clínico viaja sin tapar. Todo lo que sale bajo una de esas excepciones queda anotado en la bitácora con la fecha, el proveedor y las categorías implicadas, para poder demostrar después exactamente qué se autorizó y cuándo.
6. Evidencias de aceptación
Las garantías se han verificado sobre el producto instalado —no sobre código aislado ni sobre un entorno de laboratorio— capturando el tráfico real hacia un proveedor externo controlado. Estos son los resultados:
| Prueba | Qué se comprobó | Resultado |
| Captura de tráfico con documento de identidad | Un turno con nombre y cédula dirigido a un proveedor externo. | El proveedor no recibió el turno; lo atendió el modelo local. |
| Captura de tráfico en modo seudonimizar | Un turno con nombre, correo y teléfono de un tercero. | 0 datos reales en la petición; viajaron [PERSONA_1], [CORREO_1] y [TELEFONO_1]. El usuario recibió la respuesta con los valores reales. |
| Dato de salud en modo seudonimizar | Diagnóstico y medicación de una persona identificada. | No salió del equipo pese al modo permisivo. |
| Credencial en modo seudonimizar | Contraseña de un portal asociada a una persona. | No salió del equipo. |
| Historial de herramientas | Datos personales guardados por una herramienta en un turno anterior y reenviados en el historial. | Detectado y seudonimizado. (Defecto hallado en pruebas y corregido antes de la entrega.) |
| Ingesta en espacio «datos de clientes» | Contrato con nombre, cédula, correo y teléfono. | Ningún dato real en los fragmentos indexados; el mapa quedó en archivo separado. |
| Cifrado en reposo | Lectura de las bases con herramientas estándar. | Ilegibles: «file is not a database». El esquema no aparece en el binario. |
| Derecho al olvido | Borrado de una persona por nombre. | Eliminada de todas las tablas y del mapa de seudónimos; constancia generada sin reintroducir el dato. |
| Bitácora de errores | Registro de fallos con datos personales en el mensaje. | Correo y documento enmascarados antes de escribirse en disco. |
El detalle técnico de cada prueba, con los registros tal como los produjo la aplicación, se entrega en el anexo «Evidencia del estándar de registro» y puede reproducirse en las instalaciones del cliente.
7. Límites de la garantía
Una garantía que no declara sus límites no es fiable. Estos son los nuestros, expuestos con la misma claridad que las garantías:
| Límite | Explicación | Qué debe hacer el cliente |
| La anonimización no es absoluta | La seudonimización conserva el contexto del texto. En un espacio con muy pocas personas, ese contexto puede permitir deducir la identidad aunque el nombre esté sustituido. | Valorar el riesgo por espacio con la hoja de evaluación que genera el producto; usar el modo «bloquear» en espacios pequeños o muy específicos. |
| La detección automática no es infalible | El detector está ajustado a alta sensibilidad, pero ningún detector reconoce el 100 % de las formas en que una persona puede escribir un dato personal. | Mantener el modo «bloquear» —el predeterminado— cuando se traten categorías sensibles. |
| El proveedor externo es responsabilidad del cliente | Lo que un tercero haga con lo que recibe está fuera del alcance de este producto. JMAX garantiza qué se envía, no qué hace el destinatario. | Suscribir con cada proveedor el acuerdo de tratamiento que corresponda. |
| El cifrado protege el disco, no la sesión abierta | Con la aplicación abierta y el equipo desbloqueado, la información es accesible para quien esté delante. | Aplicar sus políticas de bloqueo de sesión y control de acceso físico. |
| Los archivos originales siguen siendo del cliente | La seudonimización actúa sobre lo que se indexa. El documento original que el cliente sube permanece donde él lo puso. | Aplicar a esos archivos sus propias políticas de custodia. |
| Modificaciones anulan la garantía | Alterar los componentes de privacidad, desactivar el cortafuegos o sustituir el detector invalida lo aquí declarado. | Solicitar por escrito cualquier adaptación. |
8. Cómo comprobarlo usted mismo
Ninguna de las garantías exige confiar en nosotros. Este es el procedimiento para verificarlas en su propia instalación, sin herramientas especiales:
Prueba 1 — Que los datos personales no salen
Configure un proveedor externo apuntando a un servidor de su propiedad que registre lo que recibe (basta un servidor HTTP sencillo). Envíele a JMAX un mensaje con un nombre y un número de documento. Compruebe en su servidor qué llegó: no debe haber llegado nada, o deben haber llegado marcadores si usted activó el modo «seudonimizar».
Prueba 2 — Que el modo configurado se respeta al pie de la letra
Repita la prueba anterior con el proveedor en «bloquear» y envíe un mensaje con un diagnóstico médico o una contraseña: su servidor no debe recibir nada. Cambie después ese mismo proveedor a «seudonimizar» y repita: su servidor debe recibir el turno con los nombres y teléfonos sustituidos por marcadores, y la respuesta que usted lee en pantalla debe traer de vuelta los valores reales. Compruebe por último que la bitácora recoge esa salida como excepción configurada.
Prueba 3 — Que lo indexado no contiene datos personales
Marque un espacio de trabajo como «datos de clientes» y suba un documento con nombres y cédulas. Abra la base de datos de la memoria con cualquier visor de SQLite y busque esos datos: debe encontrar marcadores en su lugar.
Prueba 4 — Que el cifrado funciona
Active el cifrado en la pantalla de Privacidad y reinicie. Intente abrir los archivos de base de datos con un visor de SQLite: deben resultar ilegibles.
Prueba 5 — Que el olvido borra de verdad
Introduzca datos de una persona ficticia, úsela en varias conversaciones, y ejecute «Borrar a una persona» con su nombre. El sistema le dirá cuántos registros eliminó en cada superficie y dejará constancia con fecha.
Autoonomia Global acompaña esta verificación durante la implantación y entrega el acta de resultados firmada.
9. Compromisos del proveedor
- Sin acceso a sus datos: Autoonomia Global no accede a los datos tratados por JMAX en las instalaciones del cliente. El producto no envía telemetría, uso ni contenido a nuestros servidores.
- Notificación de defectos: si se identifica un defecto que afecte a las garantías G1–G8, el cliente será informado por escrito y recibirá la corrección con carácter prioritario.
- Evidencia con cada versión: cada versión entregada incluye las evidencias de aceptación de los controles de privacidad, reproducibles por el cliente.
- Derecho de auditoría: el cliente puede exigir la repetición de las pruebas de la sección 8 en cualquier momento durante la vigencia del contrato.
- Operación sin dependencia externa: el producto funciona sin conexión a internet; el cliente puede desconectarlo de la red para comprobarlo.
10. Aceptación
Las partes reconocen haber leído y entendido el contenido de esta declaración, incluidos los límites expresados en la sección 7, que se incorpora como anexo al contrato de licenciamiento del producto JMAX.
| Por Autoonomia Global | Por el cliente |
| Nombre: Cargo: Fecha: | Nombre: Cargo: Fecha: |
Documento generado por Autoonomia Global. Las garantías aquí descritas corresponden a la versión del producto entregada al cliente y a su configuración de privacidad predeterminada.