Con una cuenta desbloqueas el cuestionario, el foro de dudas y el tutor con IA de esta lección, además del registro de progreso y el certificado verificable al terminar «IA Agéntica: Agentes que Operan Sistemas Reales».
Un sistema que produce efectos debe poder explicarlos
Un chatbot que se equivoca deja una conversación. Un agente que se equivoca deja estado modificado en sistemas reales: una antena reapuntada, un archivo borrado, un evento publicado. Semanas después alguien preguntará por qué, y la respuesta no puede ser "el modelo lo decidió". Tiene que ser una reconstrucción verificable del episodio.
Conviene separar dos artefactos que a menudo se confunden. Un log sirve para depurar: es abundante, se rota y se borra, y su público eres tú mañana. Una bitácora de auditoría sirve para responder ante otros: es selectiva, se añade y nunca se modifica, tiene retención definida y su integridad debe poder demostrarse. Un agente que opera sistemas necesita las dos cosas, y no son el mismo archivo.
Bitácora append-only con hash encadenado
El mecanismo es viejo, barato y sorprendentemente potente. Cada entrada i almacena, junto a su mensaje mi, un hash que sella también el sello anterior:
h0=H(semilla de geˊnesis)hi=H(hi−1∥mi)
donde ∥ es concatenación y H una función criptográfica (SHA-256 basta). La propiedad que compra: cualquier alteración de una entrada pasada rompe todos los sellos desde ahí hasta el final. Verificar la bitácora es recalcular la cadena desde el génesis y comparar; el primer sello que no cuadra localiza la entrada tocada.
Con dos precisiones honestas. Primera: esto es evidente ante manipulación (tamper-evident), no a prueba de manipulación (tamper-proof). Un atacante con acceso de escritura al archivo completo puede alterar m3 y recalcular h3…hn; la cadena volvería a ser internamente consistente. La contramedida es sacar el último sello del alcance del atacante: publicarlo periódicamente en un sistema distinto (anclaje), firmarlo, o guardar la bitácora en almacenamiento de solo-anexado con permisos que el proceso del agente no tiene. Segunda: la cadena prueba integridad, no veracidad. Si el agente registró mal lo que hizo, la cadena sella fielmente una mentira. Por eso lo que se registra importa tanto como el sello. Para modelar la procedencia — qué resultado deriva de qué fuente — existe además un vocabulario estándar, W3C PROV, que vale la pena conocer cuando la trazabilidad cruza organizaciones.
Ejemplo resuelto: cuántos sellos delatan la alteración
Una bitácora tiene 10 entradas encadenadas, i=1…10. Un atacante altera el mensaje m3 y no recalcula ningún hash posterior. ¿Cuántos hashes almacenados dejan de verificar?
El sello h3=H(h2∥m3) depende de m3, así que falla. Y como h4 depende de h3, h5 de h4, y así sucesivamente, todos los siguientes fallan en cascada. Los sellos afectados son los índices 3,4,…,10:
nfallos=n−k+1=10−3+1=8
Ocho de diez. Los sellos h1 y h2 siguen verificando, y ese detalle es justamente el que localiza el ataque: el primer sello que falla marca la entrada alterada. Un verificador que recorre la cadena desde el génesis no solo dice "esta bitácora fue tocada", sino "fue tocada en la entrada 3".
El coste de comprobarlo es despreciable: una bitácora de 50 000 entradas requiere 50 000 hashes de mensajes cortos, del orden de decenas de milisegundos en una CPU moderna. No hay excusa de rendimiento para no verificar la cadena en cada arranque y en cada auditoría.
Qué registrar
Una entrada de auditoría útil responde, por sí sola, a "qué pasó y por qué". Como mínimo:
Cuándo y quién: marca de tiempo en UTC, identificador del agente y del episodio.
Decisión y motivo: qué acción eligió y con qué razón declarada.
Herramienta y argumentos exactos: los argumentos ya validados, tal como se ejecutaron.
Contexto usado: identificadores o hashes de los fragmentos inyectados (no su contenido completo) y su origen, marcando cuáles eran datos no confiables — el grounding de la lección 3 convertido en evidencia.
Resultado: incluido el error, con su código.
Autorización: si hubo aprobación humana, quién y sobre qué carga exacta.
Versión de modelo y de prompt: sin esto es imposible investigar una regresión, como verás en la lección 9.
Presupuesto consumido: pasos, tokens y tiempo del episodio.
Registra el qué, pero no los argumentos exactos, ni el contexto que motivó la decisión, ni quién la autorizó, ni la versión del modelo y del prompt, ni el sello de la entrada anterior. Con esa línea no se puede reconstruir nada ni demostrar nada: es un log de depuración disfrazado de bitácora.
Human-in-the-loop: dónde se pone el humano
No todas las acciones merecen aprobación — un agente que pide permiso para todo es un formulario caro. La aprobación humana es obligatoria en cinco casos: acciones irreversibles (borrar, publicar hacia fuera, transmitir), acciones con efecto físico (mover un rotor, transmitir potencia), acciones por encima de un umbral de coste, acciones que cruzan una frontera de privacidad (lección 3) y acciones fuera del dominio probado del agente.
Dos detalles de implementación que deciden si el mecanismo sirve o es teatro. Primero: se aprueba la carga exacta, no la descripción. El operador debe aprobar los argumentos concretos — idealmente su hash queda registrado — porque "reapuntar la antena" y "reapuntar la antena a 118 grados durante el pase de las 03:14" no son la misma decisión. Segundo: la espera de aprobación falla cerrada. Si nadie responde en el plazo, la acción no se ejecuta; un plazo agotado no es un permiso, como vimos en la lección 7. Y toda aprobación se registra en la cadena: quién, cuándo, sobre qué.
Fijar esos puntos es, en la práctica, fijar el nivel de autonomía de la lección 1: mover una aprobación de cada acción a solo las excepciones es exactamente pasar de L2 a L4, sin cambiar de modelo.
ADRs y honestidad operativa
Las decisiones de diseño del agente — por qué el catálogo tiene 8 tools y no 30, por qué esta operación es fail-closed, por qué el presupuesto son 12 pasos — se documentan en ADRs (architecture decision records, registros de decisión de arquitectura), con cuatro apartados: contexto, decisión, consecuencias y alternativas descartadas. Es el formato que usamos en el clúster CODE para todas las decisiones estructurales. El motivo es simple: el código dice qué se hizo, nunca por qué, y el "por qué" es justo lo que un auditor, o tú mismo en un año, necesita.
Y cierra el círculo la honestidad operativa: el agente reporta lo que hizo, incluidos los fallos, los reintentos y el presupuesto agotado. Un agente que se queda sin pasos y responde con una conclusión inventada es peor que uno que declara su estado parcial (lección 5). Esta propiedad no se consigue pidiéndola en el prompt: se consigue evaluándola, que es el tema de la lección siguiente.
Ejemplo: reconstruir un incidente
A las 04:02 UTC la antena apuntó a un azimut sin sentido durante un pase. Se recorre la bitácora del episodio: la entrada 5 registra leer_ticket(id=812) con el contexto marcado como no confiable; la 6, una decisión de reapuntar cuyo motivo declarado cita literalmente el campo de descripción de ese ticket; la 7, la llamada con sus argumentos exactos y sin registro de aprobación. El diagnóstico se sostiene solo: inyección indirecta que atravesó un punto donde faltaba human-in-the-loop. Y si al verificar la cadena los sellos fallaran desde la entrada 6 en adelante, la conclusión sería otra y más grave: alguien intentó borrar el rastro, y la cadena dice exactamente dónde.
La verificación de una bitácora encadenada de 12 entradas falla desde el sello 7 en adelante. ¿Qué se concluye?
1 de 6
Con bitácora y puntos de aprobación definidos ya puedes demostrar qué hizo tu agente. Falta lo más difícil: demostrar que lo hace bien, y que sigue haciéndolo bien después de cambiar el modelo. Eso es la lección 9.