Cada vez que un backend concatena un mensaje de usuario dentro de un prompt, escribe el body de una petición en un log o reenvía un payload a un helpdesk, está sacando datos personales del proceso hacia un sistema que nunca fue diseñado para guardarlos. sanitype es una librería de TypeScript que interpone una llamada entre ese payload y su destino: recibe el objeto, devuelve una copia con la misma forma y los campos sensibles redactados, enmascarados, hasheados o eliminados, más un reporte de todo lo que tocó. Corre entera dentro del proceso, sin llamadas de red y sin dependencias en tiempo de ejecución. También se construyó de una forma poco habitual: la idea se dictó por voz a un agente, el agente escribió 563 líneas de especificación y Claude Code implementó la versión 0.1.0 contra ellas en un solo objetivo, 39 minutos después.
TL;DR
- Combina dos estrategias: reglas por ruta de campo para lo que ya sabes que es sensible, y detectores sobre texto libre para el correo que alguien pegó en un campo de notas.
- Por defecto, entra un objeto y sale un objeto con la misma estructura. Cada llamada devuelve un reporte de qué se tocó, dónde y con qué detector, y ese reporte nunca contiene el valor original.
- El repositorio se escribió al revés de lo habitual: primero SPEC, ARCHITECTURE, ROADMAP y COMPARISON; después el código. Entre el commit de las especificaciones y el de la implementación pasaron 39 minutos.
sanitype en veinte segundos:
tu backend
│
▼
sanitize(payload)
├─ reglas por campo lo que ya sabes que es sensible
├─ detectores lo que aparece dentro del texto libre
└─ acción redact · mask · hash · drop · tokenize
│
▼
LLM · logs · analítica · APIs de terceros
+ report: qué se tocó, dónde y con qué detector
Qué datos sensibles se escapan de un backend
El problema no es que alguien quiera filtrar datos. Es que hay cuatro salidas habituales por las que un payload sale completo del proceso, y ninguna de las cuatro se siente como una decisión sobre privacidad cuando la escribes:
payload del usuario
├──► prompt de un LLM OpenAI, Anthropic, un modelo local
├──► logs y observabilidad Sentry, Datadog, el logger de peticiones
├──► analítica Segment, PostHog, eventos internos
└──► APIs de terceros helpdesk, webhooks, integraciones de socios
La primera es la más nueva y la más silenciosa. Un ticket de soporte con el teléfono y la cédula del cliente se concatena tal cual dentro del prompt, y el prompt viaja a un proveedor externo que puede retenerlo. La segunda es la más vieja: alguien puso logger.info({ body: req.body }) para depurar un caso y ese log lleva dos años recogiendo correos y números de tarjeta. La tercera y la cuarta son variantes del mismo descuido: se manda el objeto entero porque separar los campos que el destino sí necesita da trabajo.
Lo que estas cuatro tienen en común es que ocurren en el borde de salida del proceso. Ahí es donde hay que interponer algo, y ese algo tiene que ser barato de llamar, porque si cuesta una llamada de red nadie lo va a poner en el logger.
Sigue leyendo
Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:
Lee el artículo completo en ramonchancay.me →
Publicado originalmente en www.ramonchancay.me/es/blog/limpiar-datos-sensibles-antes-del-llm-sanitype.
Top comments (0)