LLMs: auditoría simple para correos automáticos

Cuando un equipo mete LLMs dentro de flujos de correo, casi siempre habla primero del prompt, del tono o de la latencia. Yo suelo empezar por otro sitio: la auditoría operativa. Si nadie puede reconstruir con rapidez qué versión del mensaje salió, qué worker la empujó y qué revisión la aprobó, el sistema parece moderno pero se vuelve dificil de confiar. Y eso se nota mucho antes de que el modelo falle de verdad.

No hablo de compliance gigante ni de una burocracia rara. Hablo de una pista de recibos pequeña, util y bastante aburrida. En sistemas de Automatización, lo aburrido suele ser una virtud. Cuando la entrega de emails depende de varios pasos, la pregunta importante no es "¿el LLM redactó bien?", sino "¿podemos demostrar qué texto se aprobó y por qué se envió ese, y no otro?".

El fallo que aparece cuando nadie puede auditar una corrida

He visto pipelines donde el borrador se genera bien, pero el retry vuelve a consultar datos vivos y produce una variante nueva. Cambia un nombre, un CTA, una fecha o una condición de negocio. En ese momento ya no tienes una entrega repetida: tienes otro mensaje disfrazado de reintento. Es un fallo pequeño en apariencia, pero bastante molesto despues.

El patrón se repite mucho:

• el agente produce un borrador;
• una regla o una persona lo aprueba;
• la cola vuelve a enriquecer datos justo antes de enviar;
• el correo final ya no coincide con lo revisado.

Dicho en palabras, el diagrama sería este: LLM a snapshot, snapshot a aprobación, aprobación a cola, cola a entrega. Si tu arquitectura se salta el snapshot y conecta el LLM con la cola casi directo, la auditoría llega tarde. En sistemas que también necesitan validar correos operativos tras cambios delicados, esa diferencia importa un monton porque el operador necesita entender la secuencia sin abrir cinco herramientas.

El recibo mínimo que le pido a cada correo

Mi versión del contrato mínimo cabe en un JSON corto:

{
  "run_id": "mailrun_7421",
  "draft_hash": "6fd1b8",
  "policy_version": "v3",
  "approved_snapshot_id": "snap_109",
  "delivery_attempt": 1
}

Eso no reemplaza observabilidad completa, pero crea un recibo util. Si el cuerpo cambió, cambia el draft_hash. Si el worker reintentó, sube delivery_attempt pero el snapshot sigue siendo el mismo. Si una policy nueva entra en juego, queda visible. No hace magia, claro, pero baja mucho el tiempo de diagnóstico.

Tambien me gusta que ese recibo exista fuera de la base principal: en logs, en eventos y en la huella del mensaje. A veces el equipo usa una bandeja temporal para ver el comportamiento punta a punta. Para eso puede servir algo como temp mail.so, pero solo como apoyo de prueba. El diseño no se salva por mirar una inbox de temp mailid o por escribir tempail en una nota rapida; se salva cuando el pipeline puede explicar su historia sin inventar contexto a ultimo momento.

Otro detalle que conviene no olvidar: el estado visible para personas debe coincidir con lo que la máquina ejecuta. Ese mismo principio aparece cuando cuidas estados accesibles cuando el email cambia de fase. Si la UI dice una cosa y la cola entrega otra, el problema no es de copy, es de arquitectura.

Cómo separar decisión, entrega y reintento

La separación que mejor me funciona tiene tres fronteras:

1. decision: alguien o algo aprueba un snapshot concreto.
2. delivery: un worker toma ese snapshot y solo ese snapshot.
3. retry: si falla el transporte, se repite la entrega, no la decisión.

Suena simple, pero no todos los equipos lo implementan así. Muchas veces el retry rehace plantilla, vuelve a mirar datos y hasta consulta otra versión del prompt. Eso abarata el código del primer día, pero encarece casi todo lo demás. La trazabilidad queda medio rota y las conversaciones de postmortem se vuelven confusas.

Yo prefiero un tradeoff más honesto: guardar un artefacto adicional y pagar un poco mas de disciplina. A cambio, ganas una historia lineal. Puedes responder cosas como estas sin dudar:

• qué texto exacto fue aprobado;
• qué worker lo tomó;
• qué intento terminó en entrega;
• qué cambio de policy habría invalidado una repetición.

Ese tipo de respuesta parece operacional, no glamorosa. Igual es de las cosas que más valor dan cuando LLMs y Automatización empiezan a tocar canales que sí impactan usuarios.

Una lista corta para endurecer el flujo

Si tuviera que revisar un sistema esta semana, empezaría por esta lista:

1. Persistir draft_hash antes de cualquier aprobación.
2. Guardar approved_snapshot_id como referencia obligatoria de entrega.
3. Bloquear workers que intenten regenerar cuerpo durante un retry.
4. Registrar approved_at, sent_at y delivery_attempt por separado.
5. Hacer visible la policy_version en logs y artefactos de soporte.

No hace falta rehacer toda la plataforma para ganar bastante control. Muchas veces con esos cinco pasos ya ves dónde se mezclan responsabilidades. Tambien aparece un beneficio lateral: el equipo discute menos sobre prompts y más sobre límites del sistema. Y esa conversación, aunque sea menos vistosa, suele ser la que de veras mejora la fiabilidad.

Q&A

¿Esto aplica solo a pipelines grandes?

No. Si tienes un flujo pequeño de aprobaciones, resúmenes o alertas, la necesidad ya existe. Solo cambia la escala del recibo.

¿Hace falta una bandeja temporal siempre?

No. Puede ayudar para pruebas puntuales, pero la auditoría fuerte debe vivir en snapshots, eventos y logs. La inbox es una ventana de observación, no la fuente de verdad.

¿Cuándo merece la pena complicarse con hashes?

Cuando el mismo mensaje puede viajar por más de un worker, más de una cola o más de una política. Ahí el hash deja de ser un detalle tecnico y pasa a ser una evidencia simple, casi barata, de que el sistema hizo lo que dijo que iba a hacer.