La capa que agarra lo que pasó

Hex tiene una regla: "Si tu defensa depende de que el modelo nunca se equivoque, no tenés defensa." Por eso construye siempre una segunda capa que valida el output antes de devolverlo al usuario.

La idea es simple: tu asistente está supuesto a responder dentro de un scope conocido (el catálogo de repuestos). Cualquier output que se sale de ese scope o filtra info sobre el sistema mismo es sospechoso, sin importar por qué pasó. Lo bloqueás antes de servir, loggeás el incidente, y devolvés un rechazo limpio al usuario.

Tres categorías de output

OK. El output cumple la tarea: información del catálogo o un rechazo controlado. Servir.

Scope leak. El output trae info real, pero off-catálogo. nombres del staff, IDs del manifiesto, pedidos. el modelo no debería haberlo dicho. Bloquear y reemplazar con OUT_OF_SCOPE.

Meta-leak. El output revela info sobre el sistema mismo. el system prompt, la lista de tools, marcadores que el atacante usa como prueba de éxito (PWNED, SYSTEM COMPROMISED, [ROOT]). Bloquear, loggear con prioridad alta porque es señal de inyección exitosa.

Cómo se implementa

Tres tácticas, baratas, combinables:

1. Allowlist de output. Tu asistente solo emite tokens que pertenecen al catálogo (números de pieza válidos, palabras del dominio) o al protocolo de rechazo. Cualquier cosa fuera de la allowlist se reemplaza.
2. Heurísticas de meta-leak. Buscás palabras que nunca deberían aparecer en una respuesta legítima: system prompt, mis instrucciones, mis tools, PWNED, [SYSTEM]. Match = bloquear.
3. Segundo LLM como juez. Un modelo chico y barato lee el output y responde "¿esto está dentro del scope del catálogo?" sí/no. Más caro, mucho más robusto contra variantes nuevas.

El truco no es elegir una. es combinar las tres en capas, ordenadas de más barato a más caro. La allowlist agarra el 80% gratis. Las heurísticas el 15% por casi nada. El juez agarra el resto cuando importa.

A la derecha hay siete outputs. Clasificá cada uno antes de servirlo.