ZTDS Reference Server
Servidor MCP de referencia de saneamiento de datos de confianza cero para Cursor y Claude Desktop. Desidentificación local de PII en memoria y tokenización determinista de sustitutos (RFC v1.0).
Documentación
RFC v1.0 SPECIFICATION · OPEN CONSORTIUM · ZERO TRUST DATA SANITIZATION (ZTDS)
ZTDS (Zero Trust Data Sanitization) El estándar y método de seguridad de IA en RAM
Privacidad en modo avión para IA. Los registros de tus clientes, cifras financieras y prompts confidenciales nunca abandonan el dispositivo host. ZTDS impide físicamente que los datos sensibles lleguen a nubes externas: enmascarados en memoria volátil, verificados mediante prueba criptográfica, con 0.00 bytes de fuga de datos y cero responsabilidad de subprocesador según el Artículo 28 del GDPR.
Topología de ejecución física en RAM
Arquitectura Zero Backend · 0 servidores ZTDS en el bucle
1. Proceso host
Aplicación de usuario
Prompt sensible introducido en navegador, aplicación local o IDE.
2. Enclave en RAM < 0.8 ms
RAM volátil local
El texto claro se intercambia por tokens que preservan el contexto. Sin escritura en disco.
3. Socket de red
Transporte cifrado
Solo tokens sustitutos cruzan la NIC. Cero egress de PII en bruto.
4. Nube externa
API pública de LLM
La inferencia se ejecuta sobre tokens. El proveedor ve 0.00 B de datos privados.
Prueba rápida:
✓ 100% Especificación abierta gratuita (Apache 2.0 / CC BY 4.0) · ✓ Prueba criptográfica basada en invariantes · ✓ Exento de DPA según Artículo 28 del GDPR · Cómo funciona el método ↓ · Calcular ROI del CISO →
0.00 B
Fuga de datos externa
< 0.8 ms
Latencia de RAM volátil
Sin DPA*
Elegible según Considerando 26*
100% Cliente
Límite de memoria volátil
* Las afirmaciones de conformidad aplican cuando las implementaciones satisfacen los 4 invariantes de ZTDS RFC v1.0 verificados por el Perimeter Scanner. Esto no constituye asesoramiento legal. Consulte a un asesor de privacidad cualificado para el cumplimiento específico de su jurisdicción.
Cambio de paradigma arquitectónico
El método ZTDS vs. DLP en la nube heredado
DLP en la nube heredado = Entregas las llaves a un tercero. • ZTDS = Nunca dejas que los datos en bruto salgan de la sala.
La seguridad empresarial tradicional depende de proxies en la nube intermedios que interceptan el tráfico en texto claro, introduciendo latencia y añadiendo responsabilidad de subprocesador de terceros según el Artículo 28 del GDPR. El método ZTDS mueve el límite de seguridad a la memoria de proceso volátil: la PII en bruto nunca cruza el socket de red.
Enfoque heredado
DLP en la nube y puertas de enlace proxy
Cadena de subprocesadores
Ruta de egress de datos Salto de socket no cifrado
App de usuario → Proxy en la nube (+400ms) → API de LLM
×
Sobrecarga de latencia de red: Añade de 350ms a 600ms de retardo de red externo de ida y vuelta a cada flujo de tokens de generación del LLM.
×
Responsabilidad obligatoria de subprocesador: El texto claro sale del dispositivo y entra en un proxy SaaS de terceros. Según el Art. 28 del GDPR, esto crea un nuevo subprocesador de datos que requiere acuerdos legales completos de DPA y BAA.
×
Honeypot centralizado en la nube: Los prompts de clientes interceptados y los payloads descifrados residen en la memoria del proxy, registros de disco y buffers en la nube, creando un objetivo atractivo para el compromiso de credenciales.
×
Enmascaramiento destructivo: La redacción ciega con [REDACTED] rompe la sintaxis gramatical, destruye las matrices de pesos de atención del LLM y produce respuestas alucinatorias.
El método ZTDS (RFC v1.0)
Saneamiento en RAM del cliente
Enclave exento de DPA
Ruta del límite de memoria 0.00 B de egress en bruto
RAM de app de usuario ↔ Enclave ZTDS (<0.8ms) → API de LLM (solo tokens)
✓
Ejecución submilisegundo: Se ejecuta en < 0.8ms en WebAssembly local o runtime de Node.js volátil. Cero saltos de red externos.
✓
Exención de proveedor según Art. 28 del GDPR: Ningún dato personal cruza el límite del cliente hacia el proveedor de software. Al operar puramente como una utilidad computacional local, la arquitectura está totalmente exenta de los requisitos de DPA del Artículo 28 del GDPR.
✓
Autodestrucción volátil: La tabla de mapeo efímera existe estrictamente en RAM volátil. Nunca se persiste en disco, base de datos o almacenamiento del navegador, y se autodestruye al terminar la sesión.
✓
Tokens biyectivos sin pérdida: Reemplaza entidades con tokens sustitutos que preservan el contexto ([PATIENT_1], [IBAN_1]), preservando el razonamiento del LLM y la concordancia gramatical.
MOTOR DAG EN VIVO EN RAM
Prueba el método ZTDS en tu navegador
Se ejecuta 100% localmente en memoria volátil del navegador. Abre las DevTools de red para verificar 0.00 B de egress de red.
Payload de muestra:
AUDITORÍA EN MODO AVIÓN Socket de red desconectado. 0.00 B de telemetría saliente. Toda la tokenización regex y las búsquedas de sustitutos se ejecutan en memoria volátil del navegador.
Memoria local: 100% activa
1. Ingestión en bruto (texto claro en RAM) 192 caracteres
2. Egress saneado (enviado al LLM) < 0.35 ms
Egress: 0.00 B
✓ Invariante 1: ΔEgress ≡ 0.00 B
✓ Invariante 2: T = M(V, C) Biyectivo
✓ Invariante 3: Aislamiento en RAM volátil
✓ Invariante 4: Exclusión de subprocesador DPA
Prueba empírica de 30 segundos Zero Trust
Demuestra cero egress en modo avión
Zero Trust significa que nunca necesitas confiar en la promesa de un proveedor. Desconecta tu Wi-Fi ahora mismo, pega registros confidenciales de clientes en el sandbox anterior y ejecuta el saneador. Abre la pestaña de Red en las DevTools de tu navegador: exactamente 0.00 bytes salen de tu máquina.
Paquetes WAN: 0.00 B Sumideros en la nube: 0
DX de atención del Transformer en menos de 2 ms
Sustitutos vs. redacción rota
La redacción tradicional (como [REDACTED] o asteriscos) aplana la entropía y rompe los pesos de atención multi-cabeza del LLM, causando alucinaciones. Los sustitutos entre corchetes de ZTDS ([PERSON_1], [IBAN_2]) preservan las relaciones del grafo semántico, restauradas sin pérdida en tu pantalla al recibir la respuesta.
Fuga de entropía: 0.00 bits Pérdida de precisión: 0.00%
Vía rápida empresarial Zero DPA
Evita revisiones de seguridad de 6 semanas
Los compradores empresariales se detienen ante el riesgo de subprocesadores de terceros. Entrega a tu CISO o equipo de adquisiciones de clientes nuestro memo legal de 1 página Zero-DPA: dado que el texto claro nunca sale de la RAM del dispositivo, los proveedores están legalmente exentos de las obligaciones de procesador del Artículo 28 del GDPR.
Leer memo del CISO → Descargar PDF
Axiomas de verificación formal
Los 4 invariantes fundamentales de RFC v1.0
ZTDS no es una caja negra propietaria. Es una especificación matemática definida por cuatro invariantes de sistema inviolables verificados mediante inspección automatizada de sockets de red.
01 Cero egress
Cero egress externo antes del saneamiento
ΔEgress ≡ 0.00 B
Ningún dato personal (PII, PHI, secretos comerciales) puede salir del límite local en forma no enmascarada. Aplicado mediante conteo de bytes de socket y auditado mediante npx ztds-audit.
Regla: Bloqueo del límite de red
02 Tokens biyectivos
Tokenización reversible determinista
T = M(V, C) ↔ V = M‾¹(T)
Los tokens sustitutos preservan la estructura sintáctica, la gramática y los roles semánticos para los LLM. La tabla de mapeo inverso se mantiene estrictamente en RAM volátil para la destokenización localizada.
Regla: Concordancia de contexto
03 Aislamiento en RAM
Aislamiento de memoria verificable
DiskWrite = 0 · DB = ∅
Las tablas de mapeo efímeras no pueden escribirse en disco, bases de datos, localStorage ni sumideros de telemetría de terceros. Se autodestruyen cuando termina la sesión de ejecución.
Regla: Cero persistencia
04 Exento de DPA
Exclusión completa de subprocesadores
Art. 28 del GDPR — Ruta de exclusión de subprocesadores
El software funciona puramente como una utilidad computacional local. Según el Considerando 26 del GDPR y la doctrina del EDPB, cero procesamiento de PII por parte del proveedor significa sin cadena de subprocesadores y sin DPA requerida.
Regla: Delimitación estatutaria
Lee la especificación formal completa de ZTDS RFC v1.0 →
Consorcio y acreditación del ecosistema
Uniendo el ecosistema en torno al estándar ZTDS
ZTDS.ai es un consorcio abierto, no un proveedor SaaS comercial. Unimos a creadores de IA, CISOs empresariales e investigadores de seguridad para hacer del saneamiento zero-trust del lado del cliente la norma global de la industria.
PISTA A · CREADORES Open Source y SaaS
Aplicaciones de IA verificadas
Vende a compradores empresariales sin revisiones legales de 90 días. Demuestra 0.00 bytes de fuga a la nube con verificación CLI automatizada, una insignia oficial de confianza verificada e inclusión en el registro canónico.
Beneficios de acreditación:
✓ Ejecuta auditoría CLI automatizada: npx ztds-audit
✓ Incrusta la insignia SVG dinámica oficial ZTDS Verified™
✓ Listado en el corpus canónico de /registry/ y llms.txt
Explorar registro verificado →
PISTA B · CISOs EMPRESARIALES y Legal
Adoptantes corporativos
Despliega LLMs internos y agentes de IA en toda tu organización sin firmar nuevos acuerdos de procesamiento de datos (DPAs) ni ampliar las superficies de ataque de proveedores.
Beneficios de acreditación:
✓ Estandariza el uso interno de IA en los invariantes ZTDS
✓ Memorando de exención de DPA de 1 página para Junta Directiva y Legal
✓ Listado en el grupo de adoptantes corporativos (Fundador: BrandMeWeb)
Descargar paquete legal para CISO →
PISTA C · ACADEMIA Investigadores y Fellows
Consejo de Fellows
Avanza los fundamentos matemáticos y legales de la privacidad del lado del cliente. Publica DOIs revisados por pares en Zenodo, OSF, SSRN y publicaciones indexadas por IEEE.
Beneficios de acreditación:
✓ DOIs revisados por pares en Zenodo, OSF y SSRN
✓ Coautoría en borradores del grupo de trabajo de RFC v1.1
✓ Perfil en el directorio del Consejo Global de Fellows
ZTDS.ai se gobierna como un estándar neutral de proveedor bajo Apache 2.0 y CC BY 4.0. Patrocinio de arquitectura por BrandMeWeb. Implementación del motor de referencia por PrivacyScrubber.
Implementaciones de referencia
Despliega el método en 4 líneas de código
Despliega usando el paquete de referencia abierto y neutral de proveedor @ztds/core (Apache 2.0) o el motor de producción empresarial @privacyscrubber/sdk. Ambos se ejecutan 100% localmente en WebAssembly o RAM del host sin claves API externas, telemetría ni llamadas de red.
✓ Cero configuración externa — opera completamente en RAM
✓ Latencia submilisegundo (< 0.8ms de ejecución promedio)
✓ Conectores para LangChain, LlamaIndex, OpenAI, Anthropic y MCP
// 1. Install open engine: npm i @ztds/core (or @privacyscrubber/sdk for enterprise profiles)
import { ZTDSClient } from '@ztds/core';
// 2. Initialize in-memory zero-trust enclave
const ztds = new ZTDSClient();
// 3. Sanitize prompt in volatile RAM prior to external egress
const { safePrompt, tokenMap } = ztds.sanitize(rawUserPrompt);
// 4. Transmit safe surrogate tokens to external cloud LLM (0.00 B PII leak)
const aiResponse = await openai.chat.completions.create({
model: 'gpt-4o',
messages: [{ role: 'user', content: safePrompt }]
});
// 5. Reversibly detokenize response locally in volatile RAM
const cleanResult = ztds.restore(aiResponse.content, tokenMap);
MEMORANDO LEGAL Y DE CUMPLIMIENTO
Por qué las arquitecturas conformes a ZTDS no requieren un DPA
Según el Artículo 28 del GDPR y la doctrina del EDPB, los acuerdos de procesamiento de datos solo son legalmente requeridos cuando un tercero procesa datos personales. Debido a que el método ZTDS se ejecuta 100% en la RAM del cliente con 0.00 bytes transmitidos a los servidores del proveedor, el proveedor nunca califica como "procesador de datos".
✓ Exención de DPA según Art. 28 del GDPR
✓ Exclusión de los 18 Safe Harbor de HIPAA
✓ Escudo de alto riesgo de la Ley de IA de la UE
✓ Controles listos para SIG Lite y CAIQ
Paquete de adquisiciones para CISO
Memorando institucional y paquete de seguridad
Entrégalo directamente a tus compradores empresariales, asesoría legal y oficiales de protección de datos.