{"id":128,"date":"2026-09-08T01:40:37","date_gmt":"2026-09-08T07:40:37","guid":{"rendered":"https:\/\/zherpa.ai\/blog\/?p=128"},"modified":"2026-09-08T08:31:34","modified_gmt":"2026-09-08T14:31:34","slug":"arquitectura-agentes-ia-procesos-mision-critica","status":"publish","type":"post","link":"https:\/\/zherpa.ai\/blog\/investigacion\/arquitectura-agentes-ia-procesos-mision-critica\/","title":{"rendered":"M\u00e1s all\u00e1 del LLM: qu\u00e9 arquitectura necesita un agente de IA antes de operar procesos de misi\u00f3n cr\u00edtica"},"content":{"rendered":"

La pregunta m\u00e1s importante sobre un agente de inteligencia artificial que participa en un proceso financiero no es si comprende una factura, interpreta correctamente un correo electr\u00f3nico o puede elaborar una conciliaci\u00f3n. La pregunta realmente dif\u00edcil comienza despu\u00e9s: \u00bfqu\u00e9 ocurre cuando permitimos que esa inteligencia act\u00fae sobre el estado real de una empresa?<\/strong><\/p>\n

Un modelo puede interpretar correctamente un mensaje como \u201cel pago ya qued\u00f3 realizado\u201d, pero esa frase no demuestra que exista una transferencia liquidada. Puede entender \u201cma\u00f1ana entregamos la informaci\u00f3n\u201d y extraer correctamente una fecha prometida, aunque esa promesa no reduzca por s\u00ed misma el riesgo temporal del proceso. Puede recibir un error de timeout despu\u00e9s de solicitar una modificaci\u00f3n en un ERP e inferir que la operaci\u00f3n fall\u00f3, cuando en realidad el servidor pudo haber ejecutado la mutaci\u00f3n y haberse perdido \u00fanicamente la respuesta.<\/p>\n

En ninguno de estos ejemplos el problema fundamental es necesariamente una \u201calucinaci\u00f3n\u201d en el sentido habitual del t\u00e9rmino. El problema es arquitect\u00f3nico: una inferencia probabil\u00edstica est\u00e1 intentando representar \u2014y potencialmente modificar\u2014 un sistema cuyo estado tiene consecuencias deterministas.<\/strong><\/p>\n

Por ello, esta investigaci\u00f3n parte de una pregunta deliberadamente exigente: \u00bfqu\u00e9 propiedades arquitect\u00f3nicas deber\u00eda tener un sistema ag\u00e9ntico antes de recibir autoridad para intervenir en procesos administrativos, contables y financieros donde una decisi\u00f3n incorrecta puede afectar dinero, cumplimiento, continuidad operativa o responsabilidad empresarial?<\/strong><\/p>\n

La hip\u00f3tesis inicial identificaba cinco capacidades: razonamiento temporal sobre grafos, evidencia verificable, modelado probabil\u00edstico de dependencias, ejecuci\u00f3n transaccional segura y escalamiento proporcional al riesgo. La revisi\u00f3n de literatura cient\u00edfica, patrones de sistemas distribuidos, investigaci\u00f3n reciente sobre seguridad de agentes y documentaci\u00f3n t\u00e9cnica y regulatoria confirma una parte importante de esa direcci\u00f3n, pero obliga tambi\u00e9n a modificarla.<\/p>\n

No todo proceso necesita \u00c1lgebra de Intervalos de Allen. Bayes no es la \u00fanica manera defendible de modelar incertidumbre. Two-Phase Commit no es necesariamente viable entre sistemas empresariales independientes. Y, sobre todo, un agente t\u00e9cnicamente sofisticado contin\u00faa siendo insuficiente si la arquitectura no incorpora conocimiento experto, pol\u00edticas, evidencia, l\u00edmites de autoridad, observabilidad y mecanismos expl\u00edcitos para reconocer aquello que no sabe.<\/p>\n

\n

La confiabilidad de un agente no depende solamente de aumentar su inteligencia. Depende de impedir que esa inteligencia adquiera m\u00e1s autoridad operacional de la que justifican su evidencia, sus permisos, el estado del proceso y la reversibilidad de sus acciones.<\/strong><\/p>\n<\/blockquote>\n

1. Del modelo ling\u00fc\u00edstico al sistema que act\u00faa<\/h2>\n

Un modelo generativo recibe contexto y produce una salida probabil\u00edstica. Un agente introduce una diferencia fundamental: puede observar un entorno, mantener alg\u00fan tipo de estado, seleccionar herramientas, ejecutar acciones y utilizar el resultado de esas acciones como nueva informaci\u00f3n para decidir qu\u00e9 hacer despu\u00e9s.<\/p>\n

Observe(t) \u2192 Infer(t) \u2192 Decide(t) \u2192 Act(t) \u2192 Observe(t+1)<\/strong><\/p>\n

El punto cr\u00edtico es Act(t)<\/strong>. Mientras la salida permanece como texto, una inferencia incorrecta genera principalmente un problema informacional. Cuando Act(t) representa una llamada API con permisos de escritura, un cambio de estado, una transferencia de informaci\u00f3n o una mutaci\u00f3n contable, la inferencia entra en contacto con el mundo operacional.<\/p>\n

OWASP formaliza parte de este problema bajo el concepto de Excessive Agency<\/em>: un sistema basado en LLM puede producir consecuencias no deseadas cuando dispone de funcionalidad, permisos o autonom\u00eda excesivos respecto de lo necesario para cumplir su funci\u00f3n. La mitigaci\u00f3n no consiste solamente en mejorar el prompt, sino en reducir extensiones, funciones, permisos y autonom\u00eda al m\u00ednimo necesario para la tarea.<\/p>\n

La investigaci\u00f3n cient\u00edfica reciente intenta avanzar un paso m\u00e1s. Doshi y colaboradores, en un trabajo de ICSE 2026, plantean partir de an\u00e1lisis de peligros mediante STPA para derivar requisitos de seguridad y convertirlos despu\u00e9s en especificaciones ejecutables sobre flujos de informaci\u00f3n y secuencias de herramientas. La idea desplaza el problema desde \u201cesperemos que el modelo act\u00fae correctamente\u201d hacia \u201cdefinamos qu\u00e9 acciones o secuencias deben resultar imposibles\u201d.<\/p>\n

Una revisi\u00f3n sistem\u00e1tica reciente de Dantas y colaboradores, basada en 38 estudios publicados entre 2022 y 2026, identifica la especificaci\u00f3n, la verificaci\u00f3n y el enforcement de planes producidos por agentes como problemas todav\u00eda abiertos. Por tratarse de investigaci\u00f3n muy reciente, estos resultados deben interpretarse como evidencia emergente y no como consenso cient\u00edfico definitivo.<\/p>\n

Un agente de misi\u00f3n cr\u00edtica no deber\u00eda conceptualizarse simplemente como Agent = LLM + Tools<\/strong>. Una aproximaci\u00f3n m\u00e1s rigurosa ser\u00eda: Governed Agent = Inference + State + Constraints + Evidence + Policy + Actuation + Verification<\/strong>. Pero incluso esta formulaci\u00f3n resulta incompleta, porque el agente tampoco es el sistema completo.<\/p>\n

2. Falta una pieza fundamental: el humano con conocimiento y experiencia<\/h2>\n

Un proceso financiero no existe solamente dentro de un ERP ni puede describirse completamente mediante procedimientos escritos. Existe tambi\u00e9n en la experiencia de las personas que conocen sus excepciones, comprenden las consecuencias de determinados estados y distinguen entre una anomal\u00eda tolerable y una se\u00f1al que exige detener la operaci\u00f3n.<\/p>\n

Por eso una arquitectura de misi\u00f3n cr\u00edtica deber\u00eda entenderse como un sistema sociot\u00e9cnico<\/strong>: Critical System = Human Expertise + Governed Agent + Authoritative Systems<\/strong>, donde los Authoritative Systems son las fuentes que la organizaci\u00f3n reconoce para establecer determinados estados: ERP, banco, CRM, sistemas fiscales, repositorios documentales, servicios de identidad u otros systems of record.<\/p>\n

Esta distinci\u00f3n evita un error frecuente en el discurso sobre agentes: confundir capacidad t\u00e9cnica con autoridad empresarial. Technical Capability \u2260 Business Authority.<\/strong> Que un agente posea credenciales capaces de modificar un registro no significa que deba tener autoridad empresarial para hacerlo. Que pueda calcular que una ruta temporal est\u00e1 comprometida tampoco significa que pueda decidir unilateralmente qu\u00e9 obligaci\u00f3n sacrificar.<\/p>\n

En realidad, cada componente de la arquitectura contiene decisiones humanas previas. Alguien determina qu\u00e9 fecha constituye un deadline material; qu\u00e9 fuente puede probar que un pago ocurri\u00f3; qu\u00e9 desviaci\u00f3n es aceptable; qu\u00e9 nivel de riesgo exige intervenci\u00f3n; qu\u00e9 acci\u00f3n puede revertirse; qu\u00e9 registro constituye la verdad contable; qu\u00e9 excepciones existen; y qu\u00e9 decisiones permanecen reservadas a personas con determinada autoridad.<\/p>\n

3. El problema de formalizar la experiencia<\/h2>\n

Una organizaci\u00f3n funciona mediante una combinaci\u00f3n de conocimiento expl\u00edcito y t\u00e1cito. Los manuales, contratos, pol\u00edticas, calendarios, matrices de autorizaci\u00f3n y procedimientos representan s\u00f3lo una parte del conocimiento operacional. El resto reside en experiencia acumulada, excepciones conocidas, interpretaci\u00f3n contextual y capacidad para reconocer patrones que nunca fueron documentados formalmente.<\/p>\n

Operational Knowledge = Explicit Rules + Tacit Knowledge + Experience + Context + Judgment<\/strong><\/p>\n

Convertir ese conocimiento en software tiene enormes ventajas: consistencia, repetibilidad, trazabilidad y capacidad de ejecuci\u00f3n continua. Pero tambi\u00e9n introduce un riesgo profundo. Una pol\u00edtica formal puede ejecutarse perfectamente y seguir siendo incorrecta si representa mal el problema: Correct Execution + Incorrect Policy = Incorrect Outcome.<\/strong><\/p>\n

Por ello, la transferencia de conocimiento experto hacia un agente deber\u00eda parecerse menos a \u201cescribir un gran prompt\u201d y m\u00e1s a un ciclo de ingenier\u00eda: conocimiento y experiencia \u2192 identificaci\u00f3n de peligros \u2192 reglas e invariantes \u2192 pol\u00edticas computables \u2192 grafo o m\u00e1quina de estados \u2192 ejecuci\u00f3n y enforcement \u2192 evidencia operacional \u2192 revisi\u00f3n humana \u2192 evoluci\u00f3n de pol\u00edticas.<\/p>\n

En lugar de preguntar \u00fanicamente \u201c\u00bfqu\u00e9 instrucciones necesita el agente?\u201d, podemos formular una pregunta m\u00e1s fuerte: \u00bfqu\u00e9 estados ser\u00edan inaceptables y qu\u00e9 secuencias de acciones podr\u00edan producirlos?<\/strong><\/p>\n

La autonom\u00eda no deber\u00eda consistir en eliminar al experto del sistema, sino en conseguir que su conocimiento gobierne m\u00e1s decisiones sin fingir que todo su juicio puede reducirse a reglas.<\/p>\n

4. Primera propiedad operacional: representar el tiempo como estructura, no como calendario<\/h2>\n

Muchas automatizaciones empresariales representan el tiempo mediante reglas discretas: solicitar informaci\u00f3n en T-8, recordar en T-5, escalar en T-2 y verificar en T. Es un mecanismo \u00fatil, pero supone impl\u00edcitamente que conocer la distancia hasta una fecha es suficiente para conocer el riesgo. No lo es cuando las actividades dependen unas de otras.<\/p>\n

Consideremos una cadena simplificada: Banco \u2192 Conciliaci\u00f3n \u2192 Discrepancias \u2192 Cierre preliminar \u2192 Informaci\u00f3n fiscal \u2192 Revisi\u00f3n \u2192 Autorizaci\u00f3n \u2192 Pago.<\/strong> Si el extracto bancario llega seis horas tarde, el problema no son las seis horas en s\u00ed mismas. El problema es cu\u00e1nto margen de recuperaci\u00f3n ha desaparecido en las actividades dependientes y si contin\u00faa existiendo alguna secuencia de ejecuci\u00f3n capaz de llegar al objetivo dentro de las restricciones.<\/p>\n

Podemos representar el proceso como un grafo dirigido G = (V,E)<\/strong>, donde los v\u00e9rtices V representan actividades, eventos o estados y las aristas E representan dependencias. Cada nodo puede poseer estado, duraci\u00f3n, deadline, evidencia, responsable y riesgo; cada arista puede expresar una restricci\u00f3n temporal o causal.<\/p>\n

5. De CPM a redes de restricciones temporales<\/h2>\n

El M\u00e9todo de Ruta Cr\u00edtica proporciona una primera herramienta \u00fatil. Para una actividad i, la holgura total puede expresarse de forma compatible con HTML como TF(i) = LS(i) \u2212 ES(i)<\/strong>, donde LS es el inicio m\u00e1s tard\u00edo compatible con el cronograma y ES el inicio m\u00e1s temprano.<\/p>\n

Si una actividad posee cuarenta horas de holgura y sufre seis horas de retraso, puede conservar treinta y cuatro horas. Si posee dos horas, esas mismas seis horas producen una holgura de menos cuatro horas. Un scheduler convencional observa que ambas actividades se retrasaron seis horas; un sistema consciente de dependencias entiende que s\u00f3lo una de ellas ha comprometido estructuralmente el objetivo.<\/p>\n

James F. Allen introdujo en 1983 una l\u00f3gica temporal basada en intervalos que permite expresar relaciones como before, meets, overlaps, during, starts<\/em> o finishes<\/em> y razonar sobre ellas mediante propagaci\u00f3n de restricciones. El trabajo se convirti\u00f3 en una referencia fundacional del razonamiento temporal computacional.<\/p>\n

Sin embargo, ser\u00eda incorrecto concluir que todo agente financiero necesita implementar el \u00c1lgebra de Allen. Su utilidad depende de la riqueza temporal del dominio y de la complejidad que resulte razonable introducir. Para muchos procesos empresariales, las redes de restricciones temporales pueden ofrecer un equilibrio especialmente interesante.<\/p>\n

6. Simple Temporal Networks: \u00bfsigue existiendo una soluci\u00f3n?<\/h2>\n

Dechter, Meiri y Pearl formalizaron en 1991 las Temporal Constraint Networks. En este marco, las variables pueden representar puntos temporales y las restricciones expresan intervalos permitidos sobre las diferencias entre ellos. El trabajo distingue los Simple Temporal Problems, una clase que puede resolverse en tiempo polinomial.<\/p>\n

Una restricci\u00f3n puede escribirse como a(i,j) \u2264 t(j) \u2212 t(i) \u2264 b(i,j)<\/strong>. Por ejemplo, 2h \u2264 t(revisi\u00f3n) \u2212 t(recepci\u00f3n) \u2264 24h<\/strong> indica que la revisi\u00f3n debe ocurrir no antes de dos horas ni despu\u00e9s de veinticuatro horas desde la recepci\u00f3n.<\/p>\n

Si una observaci\u00f3n modifica el tiempo real de conciliaci\u00f3n, el sistema puede propagar la nueva restricci\u00f3n por la red y preguntar si contin\u00faa existiendo un cronograma factible. Si la respuesta es negativa, el proceso ya est\u00e1 comprometido aunque todav\u00eda falten d\u00edas para la fecha final.<\/p>\n

\n

Un agente temporalmente competente no deber\u00eda reaccionar solamente cuando una fecha se aproxima; deber\u00eda reaccionar cuando el conjunto de soluciones factibles empieza a desaparecer.<\/strong><\/p>\n<\/blockquote>\n

7. Cuando la duraci\u00f3n tambi\u00e9n es incierta<\/h2>\n

En la pr\u00e1ctica, muchos procesos administrativos dependen de actores cuyo tiempo de respuesta var\u00eda. Un despacho, cliente, proveedor, banco o responsable interno no responde siempre en un intervalo fijo. La arquitectura puede modelar la latencia como una distribuci\u00f3n y estimar la probabilidad de que el workflow termine antes del deadline.<\/p>\n

Una ruta puede parecer viable con una latencia media de treinta horas y dejar de parecerlo si el percentil 95 alcanza sesenta y siete horas. La hip\u00f3tesis inicial propon\u00eda inferencia bayesiana para actualizar estos perfiles, pero la revisi\u00f3n no justifica convertir Bayes en requisito arquitect\u00f3nico. Dependiendo del proceso pueden resultar apropiados percentiles hist\u00f3ricos, modelos de supervivencia, distribuciones param\u00e9tricas, simulaci\u00f3n Monte Carlo o reglas adaptativas conservadoras.<\/p>\n

La propiedad importante no es el algoritmo concreto. Es que la arquitectura represente expl\u00edcitamente incertidumbre en lugar de convertir estimaciones en hechos<\/strong>.<\/p>\n

8. Segunda propiedad: separar lo dicho de lo demostrado<\/h2>\n

Supongamos que un tercero responde: \u201cListo, ya qued\u00f3 enviado\u201d. El LLM puede extraer correctamente una afirmaci\u00f3n de finalizaci\u00f3n con alta confianza, pero ninguna de esas variables demuestra que el artefacto exista.<\/p>\n

Necesitamos distinguir Declared State<\/strong> de Verified State<\/strong>. Una declaraci\u00f3n no deber\u00eda implicar autom\u00e1ticamente un estado verificado cuando el riesgo del proceso exige evidencia independiente.<\/p>\n

Una arquitectura de estados puede recorrer: PENDING \u2192 DECLARED_COMPLETE \u2192 ARTIFACT_RECEIVED \u2192 VALIDATION_PENDING \u2192 VERIFIED \u2192 COMPLETED_VERIFIED<\/strong>, con una rama hacia INVALID cuando la validaci\u00f3n falla.<\/p>\n

No proponemos \u201ccero confianza sem\u00e1ntica\u201d como principio absoluto. Una declaraci\u00f3n humana puede constituir evidencia suficiente para algunos estados. La regla m\u00e1s precisa es: la fuerza de la evidencia necesaria debe crecer con la consecuencia de la transici\u00f3n que pretende habilitar.<\/strong><\/p>\n

9. El grafo necesita algo m\u00e1s que tareas: necesita procedencia<\/h2>\n

Para un sistema cr\u00edtico necesitamos representar tambi\u00e9n artefactos, fuentes, validaciones, decisiones y pol\u00edticas. Una transici\u00f3n relevante deber\u00eda permitir reconstruir qu\u00e9 evidencia la habilit\u00f3, qu\u00e9 fuente produjo esa evidencia, cu\u00e1ndo fue obtenida, qu\u00e9 validador la examin\u00f3, qu\u00e9 versi\u00f3n de la pol\u00edtica estaba vigente, qu\u00e9 persona o sistema ten\u00eda autoridad y qu\u00e9 cambio se produjo como consecuencia.<\/p>\n

La decisi\u00f3n deja de depender solamente del contexto y pasa a depender de una estructura m\u00e1s rica: Decision = f(Context, Evidence, Provenance, Policy, Time, Authority)<\/strong>.<\/p>\n

El grafo empieza entonces a convertirse en algo m\u00e1s interesante que un workflow: una representaci\u00f3n parcial del conocimiento operacional y de las condiciones que autorizan cambios en el estado empresarial<\/strong>.<\/p>\n

10. Tercera propiedad: la inferencia puede proponer; una pol\u00edtica independiente debe autorizar<\/h2>\n

Entre decisi\u00f3n y ejecuci\u00f3n deber\u00eda existir una capa independiente de pol\u00edtica que compruebe permisos, evidencia, factibilidad temporal, impacto, reversibilidad y necesidad de aprobaci\u00f3n humana. Si el mismo modelo que propone la acci\u00f3n puede redefinir tambi\u00e9n las condiciones que autorizan ejecutarla, la pol\u00edtica deja de ser un l\u00edmite independiente.<\/p>\n

Proposal(action) \u2260 Permission(action).<\/strong> La inteligencia puede recomendar. La pol\u00edtica determina autoridad.<\/p>\n

11. Cuarta propiedad: las mutaciones necesitan sem\u00e1ntica transaccional<\/h2>\n

Supongamos que la pol\u00edtica autoriza una acci\u00f3n y el agente solicita una operaci\u00f3n externa. El servidor responde 504 Gateway Timeout. El sistema no sabe necesariamente qu\u00e9 ocurri\u00f3: la solicitud pudo no llegar, pudo llegar y fallar, o la transacci\u00f3n pudo confirmarse y perderse \u00fanicamente la respuesta.<\/p>\n

El \u00faltimo caso es especialmente peligroso. Si el agente interpreta el timeout como fallo y repite la operaci\u00f3n, puede duplicar un efecto cuya intenci\u00f3n empresarial era \u00fanica. Por ello, una arquitectura de misi\u00f3n cr\u00edtica necesita tratar la intenci\u00f3n operacional como una entidad persistente, con identificadores de operaci\u00f3n, reconciliaci\u00f3n antes del reintento y registro de estados.<\/p>\n

El objetivo es que repetir la misma intenci\u00f3n no multiplique sus efectos. Pero la arquitectura debe reconocer un l\u00edmite: no puede imponer idempotencia sobre un sistema externo que no la soporte. Cuando la API destino no proporciona sem\u00e1ntica idempotente suficiente, el agente necesita mantener su propio operation ledger, consultar el estado externo y reconciliar antes de volver a escribir.<\/p>\n

12. Por qu\u00e9 Two-Phase Commit no resuelve m\u00e1gicamente el problema<\/h2>\n

La hip\u00f3tesis inicial consideraba Two-Phase Commit como mecanismo para evitar estados parciales. Conceptualmente resulta atractivo, pero un agente empresarial suele trabajar con fronteras independientes: ERP, banco, SAT, PAC, CRM y otros servicios. No existe raz\u00f3n para asumir que todos soporten un coordinador transaccional com\u00fan.<\/p>\n

En esas circunstancias, patrones como Saga<\/strong> y las transacciones compensatorias ofrecen una abstracci\u00f3n m\u00e1s realista. La operaci\u00f3n se divide en transacciones locales y, cuando un paso posterior falla, se ejecutan compensaciones cuando \u00e9stas sean posibles.<\/p>\n

Aparece adem\u00e1s un estado que los sistemas cr\u00edticos deben admitir expl\u00edcitamente: UNKNOWN<\/strong>. Puede haber situaciones en las que ni el agente ni la integraci\u00f3n puedan demostrar autom\u00e1ticamente si el mundo qued\u00f3 correctamente reconciliado. Ese estado no deber\u00eda resolverse mediante una inferencia optimista del LLM; debe permanecer UNKNOWN hasta ser reconciliado o escalado.<\/p>\n

13. Quinta propiedad: verificar la postcondici\u00f3n, no confiar en la respuesta de la herramienta<\/h2>\n

Incluso una respuesta 200 OK no demuestra necesariamente que el objetivo empresarial se haya cumplido. Una API puede haber aceptado una solicitud pero haber dejado un dato incorrecto, una operaci\u00f3n puede haber actualizado el registro equivocado o un documento puede haberse generado sin cumplir los requisitos que habilitan el siguiente estado.<\/p>\n

Tool Success \u2260 Business Success.<\/strong> Despu\u00e9s de una acci\u00f3n material deber\u00eda existir una verificaci\u00f3n independiente de la postcondici\u00f3n mediante lectura del estado, reconciliaci\u00f3n y comprobaci\u00f3n de invariantes. Una arquitectura gobernada exige demostrar que el estado observable despu\u00e9s de la operaci\u00f3n coincide con la postcondici\u00f3n esperada.<\/p>\n

14. Sexta propiedad: escalar seg\u00fan riesgo, no seg\u00fan calendario ni ansiedad<\/h2>\n

Un agente que nunca pide ayuda puede ser peligroso. Uno que solicita autorizaci\u00f3n para cada operaci\u00f3n elimina buena parte del valor de la autonom\u00eda. La cuesti\u00f3n relevante es determinar cu\u00e1ndo el riesgo de continuar aut\u00f3nomamente supera el costo de interrumpir a una persona.<\/p>\n

Una pol\u00edtica realista puede considerar probabilidad de fallo, impacto, reversibilidad, holgura temporal, calidad de evidencia y autoridad. El impacto puede ser financiero, regulatorio, reputacional, contractual, operacional o relacionado con integridad de datos, por lo que ser\u00eda ingenuo reducir todos los riesgos a una sola cifra monetaria.<\/p>\n

El objetivo del escalamiento tampoco deber\u00eda consistir en transferir al directivo toda la incertidumbre del agente. Una buena escalaci\u00f3n deber\u00eda llegar preevaluada: estado observado, evidencia disponible, restricci\u00f3n comprometida, opciones factibles y consecuencias conocidas. El agente no deber\u00eda escalar ansiedad; deber\u00eda escalar decisiones.<\/strong><\/p>\n

15. S\u00e9ptima propiedad: observabilidad suficiente para reconstruir una decisi\u00f3n<\/h2>\n

Un agente puede ejecutar correctamente y aun as\u00ed ser inaceptable para un proceso cr\u00edtico si despu\u00e9s no podemos reconstruir por qu\u00e9 actu\u00f3. Necesitamos conservar observaci\u00f3n, evidencia, inferencia, versi\u00f3n de pol\u00edtica, autorizaci\u00f3n, llamada a herramienta, respuesta, mutaci\u00f3n, postcondici\u00f3n y resultado verificado.<\/p>\n

Esto permite distinguir la trayectoria de decisi\u00f3n y el estado final del mundo. Un agente puede producir una trayectoria aparentemente razonable y terminar en un estado incorrecto; tambi\u00e9n puede alcanzar un resultado correcto mediante una secuencia que viol\u00f3 pol\u00edticas y que no deber\u00eda repetirse. Por eso la evaluaci\u00f3n debe preguntar simult\u00e1neamente si el resultado fue correcto y si la ejecuci\u00f3n cumpli\u00f3 la pol\u00edtica.<\/p>\n

16. El caso fiscal mexicano demuestra por qu\u00e9 estas distinciones no son acad\u00e9micas<\/h2>\n

Consideremos una regla aparentemente prudente: \u201csi un pago provisional est\u00e1 retrasado, existe revocaci\u00f3n del CSD\u201d. La regla podr\u00eda llevar al agente a escalar inmediatamente una situaci\u00f3n como amenaza de interrupci\u00f3n de facturaci\u00f3n.<\/p>\n

Sin embargo, el art\u00edculo 17-H Bis del C\u00f3digo Fiscal de la Federaci\u00f3n establece supuestos espec\u00edficos para la restricci\u00f3n temporal<\/strong> de certificados de sello digital. Entre ellos existen condiciones concretas relacionadas con omisiones declarativas y otros supuestos; no se desprende de la norma una regla general seg\u00fan la cual un \u00fanico pago provisional tard\u00edo produzca autom\u00e1ticamente revocaci\u00f3n del CSD.<\/p>\n

La diferencia entre un pago tard\u00edo y una condici\u00f3n jur\u00eddica para restricci\u00f3n del CSD es una diferencia de estado jur\u00eddico, no una sutileza ling\u00fc\u00edstica. Este ejemplo revela por qu\u00e9 el grounding regulatorio no puede reducirse a \u201cdarle las leyes al LLM\u201d: el sistema necesita conocer fuente autorizada, vigencia, jurisdicci\u00f3n, condiciones aplicables, evidencia requerida y frontera a partir de la cual la situaci\u00f3n necesita interpretaci\u00f3n profesional.<\/p>\n

17. Un documento verificable tampoco es necesariamente v\u00e1lido para siempre<\/h2>\n

Algo similar ocurre con documentos cuyo estado parece binario. Una Opini\u00f3n del cumplimiento positiva no deber\u00eda convertirse en un estado de cumplimiento verificado indefinido. La utilidad de una evidencia puede depender de fecha, prop\u00f3sito, vigencia y contexto.<\/p>\n

Por ello, una aproximaci\u00f3n m\u00e1s rigurosa considera autenticidad, actualidad, compatibilidad con el prop\u00f3sito y autoridad de la fuente. Esto introduce una idea importante para el grafo: la evidencia tambi\u00e9n envejece<\/strong>. Una arista que hoy habilita una transici\u00f3n puede dejar de hacerlo ma\u00f1ana.<\/p>\n

18. El grafo completo empieza a parecerse a un modelo operacional de conocimiento<\/h2>\n

Al reunir dependencias, tiempo, evidencia, procedencia, autoridad y riesgo obtenemos algo m\u00e1s rico que un workflow tradicional. El grafo se convierte en un modelo parcial y revisable del proceso y, precisamente porque es parcial, necesita representar los l\u00edmites de su conocimiento: Known State, Unknown State, Insufficient Evidence, Policy Conflict, Outside Authority y Temporal Infeasibility.<\/p>\n

Estos estados no son necesariamente errores. En un sistema bien gobernado pueden ser resultados correctos. Un agente capaz de reconocer \u201cno dispongo de evidencia suficiente para continuar\u201d puede ser operacionalmente m\u00e1s confiable que otro capaz de producir siempre una respuesta.<\/strong><\/p>\n

19. La arquitectura que emerge<\/h2>\n

La investigaci\u00f3n permite proponer una arquitectura conceptual de siete capas, no como receta universal sino como conjunto de responsabilidades que conviene mantener separadas:<\/p>\n

    \n
  1. Perception & Semantic Inference:<\/strong> LLM, extracci\u00f3n, clasificaci\u00f3n y planificaci\u00f3n.<\/li>\n
  2. Temporal \/ Causal State:<\/strong> DAG, STN, deadlines, dependencias e incertidumbre.<\/li>\n
  3. Evidence & Provenance:<\/strong> artefactos, validadores y fuentes autorizadas.<\/li>\n
  4. Policy & Authorization:<\/strong> permisos, impacto, reversibilidad y compuertas humanas.<\/li>\n
  5. Transactional Execution:<\/strong> idempotencia, retry, Saga y compensaci\u00f3n.<\/li>\n
  6. Post-condition Verification:<\/strong> read-back, reconciliaci\u00f3n y comprobaci\u00f3n de invariantes.<\/li>\n
  7. Observability, Audit & Evaluation:<\/strong> trazabilidad, evidencia, pol\u00edtica, resultado y aprendizaje.<\/li>\n<\/ol>\n

    El LLM puede participar en varias capas como instrumento de interpretaci\u00f3n y razonamiento, pero eso no implica que deba convertirse en autoridad exclusiva de ninguna transici\u00f3n material.<\/p>\n

    20. Podemos expresar el principio central mediante invariantes<\/h2>\n

    Para cualquier acci\u00f3n material, una arquitectura gobernada deber\u00eda aspirar a que la ejecuci\u00f3n s\u00f3lo ocurra cuando la acci\u00f3n est\u00e1 autorizada, la evidencia es suficiente, el proceso sigue siendo temporalmente factible y la pol\u00edtica de riesgo se satisface. Despu\u00e9s de ejecutar, debe verificarse la postcondici\u00f3n.<\/p>\n

    Si la postcondici\u00f3n no puede demostrarse, el estado debe permanecer UNKNOWN<\/strong> hasta ser reconciliado. Las acciones de alto impacto y baja reversibilidad deber\u00edan requerir decisi\u00f3n humana, y una pol\u00edtica no definida no deber\u00eda interpretarse como permiso.<\/p>\n

    En sistemas de misi\u00f3n cr\u00edtica, ausencia de restricci\u00f3n no deber\u00eda equivaler autom\u00e1ticamente a autoridad<\/strong>.<\/p>\n

    21. \u00bfD\u00f3nde queda entonces la autonom\u00eda?<\/h2>\n

    Una arquitectura que define con precisi\u00f3n estados, permisos, evidencia y reversibilidad puede permitir m\u00e1s autonom\u00eda donde esa autonom\u00eda es defendible, porque no necesita tratar todas las acciones como igualmente peligrosas.<\/p>\n

    Un mismo agente podr\u00eda disponer de alta autonom\u00eda para consultar y reconciliar informaci\u00f3n, autonom\u00eda condicionada para crear borradores o preparar operaciones, aprobaci\u00f3n humana para determinadas mutaciones y prohibici\u00f3n absoluta para otras acciones. Por tanto, la unidad correcta de gobierno no parece ser \u201cel agente\u201d, sino la acci\u00f3n dentro de un contexto<\/strong>.<\/p>\n

    Esta conclusi\u00f3n converge con el principio de Humano al Mando<\/em>: prop\u00f3sito, evidencia y l\u00edmites deben preceder a la delegaci\u00f3n de acciones, y la responsabilidad empresarial permanece en las personas y en la organizaci\u00f3n. En ese marco, la autonom\u00eda se grad\u00faa seg\u00fan el riesgo de la acci\u00f3n y las decisiones materiales de alto impacto permanecen bajo autoridad humana.<\/p>\n

    22. La relaci\u00f3n entre humano y agente es m\u00e1s interesante que human-in-the-loop<\/h2>\n

    La expresi\u00f3n human-in-the-loop<\/em> puede resultar demasiado simple para describir lo que realmente necesita una organizaci\u00f3n. El humano no est\u00e1 \u00fanicamente esperando al final del proceso para aprobar una operaci\u00f3n. Est\u00e1 presente antes de que el agente act\u00fae porque su conocimiento fue utilizado para definir objetivos, pol\u00edticas, restricciones e invariantes; durante la operaci\u00f3n porque determinadas situaciones requieren escalamiento; y despu\u00e9s porque la evidencia operacional permite revisar y mejorar las pol\u00edticas.<\/p>\n

    La relaci\u00f3n completa se parece m\u00e1s a: Human Knowledge \u2192 Policy \u2192 Agent Execution \u2192 Evidence \u2192 Human Learning \u2192 Policy Evolution<\/strong>.<\/p>\n

    El humano no deber\u00eda estar solamente dentro del loop de aprobaci\u00f3n; deber\u00eda estar dentro del loop de aprendizaje y gobierno. Esto evita una falsa oposici\u00f3n entre autonom\u00eda y control: una organizaci\u00f3n puede aumentar considerablemente la autonom\u00eda operacional mientras mantiene \u2014e incluso fortalece\u2014 el control humano sobre prop\u00f3sito, autoridad y excepciones.<\/p>\n

    23. Lo que esta investigaci\u00f3n no demuestra<\/h2>\n

    No hemos demostrado que estas siete capas sean suficientes para garantizar seguridad. Tampoco que una combinaci\u00f3n concreta de STN, Bayes, Saga, m\u00e1quinas de estados y pol\u00edticas produzca autom\u00e1ticamente un sistema confiable. La evidencia cient\u00edfica reciente aconseja precisamente evitar esa conclusi\u00f3n.<\/p>\n

    Por tanto, la arquitectura presentada aqu\u00ed debe entenderse como una arquitectura de requisitos y separaci\u00f3n de responsabilidades<\/strong>, no como un producto terminado ni como una prueba de seguridad. Antes de conceder autoridad material a un agente ser\u00edan necesarias evaluaciones espec\u00edficas del dominio, simulaciones, pruebas adversariales, fault injection, pruebas de recuperaci\u00f3n, evaluaci\u00f3n de pol\u00edticas, validaci\u00f3n de integraciones y despliegues progresivos con l\u00edmites de autonom\u00eda.<\/p>\n

    En procesos fiscales, financieros o regulatorios habr\u00eda adem\u00e1s que incorporar revisi\u00f3n profesional del dominio correspondiente. La arquitectura puede controlar c\u00f3mo se aplica una pol\u00edtica; no convierte autom\u00e1ticamente esa pol\u00edtica en correcta desde el punto de vista jur\u00eddico, fiscal, contable o financiero.<\/p>\n

    24. La conclusi\u00f3n es distinta de la que esper\u00e1bamos<\/h2>\n

    Comenzamos esta investigaci\u00f3n preguntando qu\u00e9 capacidades cognitivas adicionales necesita un agente para operar procesos financieros cr\u00edticos. La respuesta parec\u00eda apuntar inicialmente hacia m\u00e1s inteligencia: mejor razonamiento temporal, mejor planificaci\u00f3n, mejor inferencia probabil\u00edstica y mejor capacidad de decisi\u00f3n.<\/p>\n

    Despu\u00e9s de revisar la evidencia, esa formulaci\u00f3n resulta insuficiente. El salto realmente importante no consiste solamente en aumentar la cognici\u00f3n del agente. Consiste en construir alrededor de esa cognici\u00f3n una arquitectura que limite su autoridad y conserve una relaci\u00f3n verificable entre conocimiento, evidencia, decisi\u00f3n y consecuencia<\/strong>.<\/p>\n

    El agente necesita comprender el tiempo, pero tambi\u00e9n un grafo capaz de demostrar cu\u00e1ndo una ruta dej\u00f3 de ser factible. Necesita interpretar lenguaje, pero tambi\u00e9n distinguir una afirmaci\u00f3n de un hecho verificable. Necesita representar incertidumbre, pero sin convertir una probabilidad en certeza. Necesita herramientas, pero con permisos delimitados y pol\u00edticas independientes. Necesita reintentar, pero sin multiplicar efectos. Necesita ejecutar, pero verificar despu\u00e9s que el mundo qued\u00f3 realmente en el estado esperado.<\/p>\n

    Y necesita algo que frecuentemente desaparece de las representaciones t\u00e9cnicas de Agentic AI: personas con conocimiento y experiencia capaces de definir qu\u00e9 significa actuar correctamente en primer lugar<\/strong>.<\/p>\n

    Podemos resumir el sistema completo como Critical Agentic System = Human Expertise + Governed Computation + Authoritative Evidence + Controlled Actuation<\/strong>, y su ciclo operacional como Observe \u2192 Infer \u2192 Constrain \u2192 Verify \u2192 Authorize \u2192 Act \u2192 Reconcile \u2192 Audit \u2192 Learn<\/strong>.<\/p>\n

    El objetivo no deber\u00eda ser construir un sistema que necesite cada vez menos conocimiento humano. Deber\u00eda ser construir uno capaz de convertir conocimiento y experiencia humanos en pol\u00edticas, restricciones y criterios verificables que puedan operar continuamente a escala, conservando una frontera expl\u00edcita para aquello que todav\u00eda exige juicio<\/strong>.<\/p>\n

    Porque cuando una inteligencia artificial adquiere capacidad para actuar sobre una empresa, la pregunta de ingenier\u00eda deja de ser \u201c\u00bfpuede hacerlo?\u201d. La pregunta que importa es mucho m\u00e1s exigente: \u00bfpodemos demostrar, antes y despu\u00e9s de cada acci\u00f3n cr\u00edtica, que el sistema ten\u00eda conocimiento suficiente, evidencia suficiente, autoridad suficiente y una ruta segura para hacerlo?<\/strong><\/p>\n

    Mientras la respuesta sea no, el sistema puede ser extraordinariamente inteligente. Pero todav\u00eda no deber\u00edamos confundir inteligencia con confiabilidad.<\/p>\n

    Metodolog\u00eda, alcance y limitaciones<\/h2>\n

    Esta pieza es una revisi\u00f3n narrativa y arquitect\u00f3nica, no una revisi\u00f3n sistem\u00e1tica propia ni un experimento controlado. La investigaci\u00f3n contrast\u00f3 las hip\u00f3tesis iniciales con literatura fundacional sobre razonamiento temporal y redes de restricciones, investigaci\u00f3n cient\u00edfica reciente sobre seguridad y verificaci\u00f3n de agentes LLM, patrones establecidos de sistemas distribuidos, documentaci\u00f3n t\u00e9cnica de plataformas empresariales y fuentes regulatorias primarias.<\/p>\n

    Las hip\u00f3tesis originales fueron tratadas como refutables. Como resultado, mantenemos la necesidad de razonamiento temporal pero ampliamos CPM hacia grafos y redes de restricciones; conservamos Allen como formalismo relevante sin convertirlo en requisito universal; mantenemos la separaci\u00f3n entre inferencia y evidencia; conservamos Bayes como una t\u00e9cnica posible y no obligatoria; abandonamos 2PC como prescripci\u00f3n general para sistemas empresariales independientes; incorporamos expl\u00edcitamente verificaci\u00f3n de postcondiciones, observabilidad y procedencia; y a\u00f1adimos el conocimiento y experiencia humanos como parte constitutiva del sistema sociot\u00e9cnico.<\/p>\n

    No afirmamos que esta arquitectura garantice seguridad, cumplimiento fiscal, ausencia de p\u00e9rdidas ni correcci\u00f3n autom\u00e1tica. Su aplicaci\u00f3n a procesos reales requiere validaci\u00f3n espec\u00edfica del dominio, controles organizacionales y revisi\u00f3n profesional cuando existan consecuencias regulatorias, fiscales, financieras o jur\u00eddicas.<\/p>\n

    Referencias cient\u00edficas y t\u00e9cnicas principales<\/h2>\n

    Allen, J. F. (1983).<\/strong> Maintaining Knowledge about Temporal Intervals<\/em>. Communications of the ACM, 26(11), 832\u2013843. DOI: 10.1145\/182.358434.<\/p>\n

    Dechter, R., Meiri, I. & Pearl, J. (1991).<\/strong> Temporal Constraint Networks<\/em>. Artificial Intelligence, 49(1\u20133), 61\u201395. DOI: 10.1016\/0004-3702(91)90006-6.<\/p>\n

    Doshi, A., Hong, Y., Xu, C., Kang, E., Kapravelos, A. & K\u00e4stner, C. (2026).<\/strong> Towards Verifiably Safe Tool Use for LLM Agents<\/em>. ICSE-NIER \u201926. DOI: 10.1145\/3786582.3786839.<\/p>\n

    Dantas, P., Cordeiro, L., Nowroozi, E. & Norbert, T. (2026).<\/strong> Toward Safe LLM Agents: A Survey of Specification, Verification, and Enforcement<\/em>. Preprint.<\/p>\n

    Fuentes regulatorias y t\u00e9cnicas:<\/strong> SAT, art\u00edculos 17-H y 17-H Bis del C\u00f3digo Fiscal de la Federaci\u00f3n; SAT, Opini\u00f3n del cumplimiento y validaci\u00f3n de CFDI; Microsoft Azure Architecture Center, patrones Saga y compensaci\u00f3n; OWASP GenAI Security Project, Excessive Agency; NIST AI Risk Management Framework y recursos TEVV; documentaci\u00f3n oficial de Zoho Books sobre Transaction Locking.<\/p>\n","protected":false},"excerpt":{"rendered":"

    \u00bfQu\u00e9 necesita un agente de IA antes de recibir autoridad sobre finanzas, contabilidad o cumplimiento? Investigamos grafos temporales, redes de restricciones, conocimiento experto, evidencia verificable, ejecuci\u00f3n segura, autonom\u00eda y observabilidad.<\/p>\n","protected":false},"author":2,"featured_media":129,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[14,18,13],"class_list":["post-128","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-investigacion","tag-agentes_ia","tag-gobernanza_de_ia","tag-ia"],"_links":{"self":[{"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/posts\/128","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/comments?post=128"}],"version-history":[{"count":3,"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/posts\/128\/revisions"}],"predecessor-version":[{"id":132,"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/posts\/128\/revisions\/132"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/media\/129"}],"wp:attachment":[{"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/media?parent=128"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/categories?post=128"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zherpa.ai\/blog\/wp-json\/wp\/v2\/tags?post=128"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}