PISIGuard y el problema de pegar datos sensibles en un chat

Un punto y cero comentarios. Ese era el marcador de PISIGuard en Hacker News pocas horas después de aparecer en la sección de IA del agregador, esta mañana del 3 de agosto. La tracción es mínima, pero el problema que ataca sale en casi todos los proyectos de integración con Claude que pasan por nuestra mesa: el momento en que alguien pega un contrato entero, con nombres, DNI y números de cuenta, dentro de una ventana de chat.

La descripción del repositorio en GitHub es escueta: proteger tu información personal y sensible cuando hablas con una IA. El hilo en Hacker News todavía no ha generado debate. Con tan poca superficie pública, lo relevante no es la herramienta concreta sino la categoría a la que pertenece, que lleva un par de años creciendo sin nombre asentado en español: filtros de redacción, capas DLP para prompts, proxies de anonimización que sustituyen datos identificables por marcadores antes de que la petición salga del equipo.

Dónde está el riesgo real

Conviene separar dos cosas que suelen mezclarse. Una es el tratamiento que hace el proveedor del modelo, y ahí manda el contrato: los términos comerciales de las APIs serias establecen desde hace tiempo que las entradas y salidas de cliente no se usan para entrenar por defecto. Revisar los términos vigentes antes de firmar sigue siendo obligatorio, pero no es donde se rompe la mayoría de las cosas.

La otra capa es interna, y es la que se lleva los sustos. Un becario que pega la base de datos de leads en un chat personal con su cuenta de Gmail. Un desarrollador que copia un log de producción con tokens dentro. Una hoja de cálculo con datos de pacientes que acaba en una herramienta contratada por marketing y no por IT. Nada de esto lo arregla un contrato: es un problema de perímetro, y un filtro local que intercepte el texto antes del envío es una respuesta razonable al problema correcto.

Qué mirar antes de instalar nada

Una herramienta de este tipo se coloca en el punto más sensible del flujo, así que la lista de comprobación es corta pero innegociable.

1. Dónde corre la detección. Si el filtro llama a un servicio externo para decidir qué es dato personal, has movido el problema de sitio en lugar de resolverlo.
2. Qué método usa. Las expresiones regulares detectan IBAN, tarjetas y correos con fiabilidad alta. Los nombres propios, las direcciones y el contexto clínico necesitan reconocimiento de entidades, con sus falsos negativos.
3. Si hay reversión. Sustituir Marta López por `[PERSONA_1]` sirve de poco si luego no puedes deshacer el mapeo para leer la respuesta con los nombres reales.
4. Licencia y mantenimiento. Un repositorio recién publicado, sin historial ni tests visibles, no es candidato para producción por buena que sea la idea.

Alternativas dentro del stack de Claude

Quien trabaje con Claude Code tiene una vía menos vistosa y más controlable: los hooks. Un `PreToolUse` que inspeccione el payload antes de una llamada de red permite bloquear o reescribir contenido con un script propio, auditado por el equipo y sin dependencias de terceros. Para flujos de escritorio, un MCP server intermedio puede hacer de aduana entre el usuario y los datos, con la ventaja de que la política queda escrita en un sitio y no repartida en la cabeza de cada persona.

Ninguna de las dos opciones sale gratis en mantenimiento. Una regex mal calibrada rompe prompts legítimos y enseña a la plantilla a desactivar el filtro, que es el peor resultado posible: la sensación de control sin el control.

Nos parece sano que aparezcan proyectos así, aunque este llegue verde y sin comunidad detrás. La higiene de datos en la interfaz de chat es la parte del despliegue de IA que más se aplaza y la que peor envejece cuando llega una auditoría. Si el repositorio no acaba convenciendo, la conversación que provoca dentro del equipo ya justifica el rato invertido.