La pregunta más importante sobre un agente de inteligencia artificial que participa en un proceso financiero no es si comprende una factura, interpreta correctamente un correo electrónico o puede elaborar una conciliación. La pregunta realmente difícil comienza después: ¿qué ocurre cuando permitimos que esa inteligencia actúe sobre el estado real de una empresa?
Un modelo puede interpretar correctamente un mensaje como “el pago ya quedó realizado”, pero esa frase no demuestra que exista una transferencia liquidada. Puede entender “mañana entregamos la información” y extraer correctamente una fecha prometida, aunque esa promesa no reduzca por sí misma el riesgo temporal del proceso. Puede recibir un error de timeout después de solicitar una modificación en un ERP e inferir que la operación falló, cuando en realidad el servidor pudo haber ejecutado la mutación y haberse perdido únicamente la respuesta.
En ninguno de estos ejemplos el problema fundamental es necesariamente una “alucinación” en el sentido habitual del término. El problema es arquitectónico: una inferencia probabilística está intentando representar —y potencialmente modificar— un sistema cuyo estado tiene consecuencias deterministas.
Por ello, esta investigación parte de una pregunta deliberadamente exigente: ¿qué propiedades arquitectónicas debería tener un sistema agéntico antes de recibir autoridad para intervenir en procesos administrativos, contables y financieros donde una decisión incorrecta puede afectar dinero, cumplimiento, continuidad operativa o responsabilidad empresarial?
La hipótesis inicial identificaba cinco capacidades: razonamiento temporal sobre grafos, evidencia verificable, modelado probabilístico de dependencias, ejecución transaccional segura y escalamiento proporcional al riesgo. La revisión de literatura científica, patrones de sistemas distribuidos, investigación reciente sobre seguridad de agentes y documentación técnica y regulatoria confirma una parte importante de esa dirección, pero obliga también a modificarla.
No todo proceso necesita Álgebra de Intervalos de Allen. Bayes no es la única manera defendible de modelar incertidumbre. Two-Phase Commit no es necesariamente viable entre sistemas empresariales independientes. Y, sobre todo, un agente técnicamente sofisticado continúa siendo insuficiente si la arquitectura no incorpora conocimiento experto, políticas, evidencia, límites de autoridad, observabilidad y mecanismos explícitos para reconocer aquello que no sabe.
La confiabilidad de un agente no depende solamente de aumentar su inteligencia. Depende de impedir que esa inteligencia adquiera más autoridad operacional de la que justifican su evidencia, sus permisos, el estado del proceso y la reversibilidad de sus acciones.
1. Del modelo lingüístico al sistema que actúa
Un modelo generativo recibe contexto y produce una salida probabilística. Un agente introduce una diferencia fundamental: puede observar un entorno, mantener algún tipo de estado, seleccionar herramientas, ejecutar acciones y utilizar el resultado de esas acciones como nueva información para decidir qué hacer después.
Observe(t) → Infer(t) → Decide(t) → Act(t) → Observe(t+1)
El punto crítico es Act(t). 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ón o una mutación contable, la inferencia entra en contacto con el mundo operacional.
OWASP formaliza parte de este problema bajo el concepto de Excessive Agency: un sistema basado en LLM puede producir consecuencias no deseadas cuando dispone de funcionalidad, permisos o autonomía excesivos respecto de lo necesario para cumplir su función. La mitigación no consiste solamente en mejorar el prompt, sino en reducir extensiones, funciones, permisos y autonomía al mínimo necesario para la tarea.
La investigación científica reciente intenta avanzar un paso más. Doshi y colaboradores, en un trabajo de ICSE 2026, plantean partir de análisis de peligros mediante STPA para derivar requisitos de seguridad y convertirlos después en especificaciones ejecutables sobre flujos de información y secuencias de herramientas. La idea desplaza el problema desde “esperemos que el modelo actúe correctamente” hacia “definamos qué acciones o secuencias deben resultar imposibles”.
Una revisión sistemática reciente de Dantas y colaboradores, basada en 38 estudios publicados entre 2022 y 2026, identifica la especificación, la verificación y el enforcement de planes producidos por agentes como problemas todavía abiertos. Por tratarse de investigación muy reciente, estos resultados deben interpretarse como evidencia emergente y no como consenso científico definitivo.
Un agente de misión crítica no debería conceptualizarse simplemente como Agent = LLM + Tools. Una aproximación más rigurosa sería: Governed Agent = Inference + State + Constraints + Evidence + Policy + Actuation + Verification. Pero incluso esta formulación resulta incompleta, porque el agente tampoco es el sistema completo.
2. Falta una pieza fundamental: el humano con conocimiento y experiencia
Un proceso financiero no existe solamente dentro de un ERP ni puede describirse completamente mediante procedimientos escritos. Existe también en la experiencia de las personas que conocen sus excepciones, comprenden las consecuencias de determinados estados y distinguen entre una anomalía tolerable y una señal que exige detener la operación.
Por eso una arquitectura de misión crítica debería entenderse como un sistema sociotécnico: Critical System = Human Expertise + Governed Agent + Authoritative Systems, donde los Authoritative Systems son las fuentes que la organización reconoce para establecer determinados estados: ERP, banco, CRM, sistemas fiscales, repositorios documentales, servicios de identidad u otros systems of record.
Esta distinción evita un error frecuente en el discurso sobre agentes: confundir capacidad técnica con autoridad empresarial. Technical Capability ≠ Business Authority. 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á comprometida tampoco significa que pueda decidir unilateralmente qué obligación sacrificar.
En realidad, cada componente de la arquitectura contiene decisiones humanas previas. Alguien determina qué fecha constituye un deadline material; qué fuente puede probar que un pago ocurrió; qué desviación es aceptable; qué nivel de riesgo exige intervención; qué acción puede revertirse; qué registro constituye la verdad contable; qué excepciones existen; y qué decisiones permanecen reservadas a personas con determinada autoridad.
3. El problema de formalizar la experiencia
Una organización funciona mediante una combinación de conocimiento explícito y tácito. Los manuales, contratos, políticas, calendarios, matrices de autorización y procedimientos representan sólo una parte del conocimiento operacional. El resto reside en experiencia acumulada, excepciones conocidas, interpretación contextual y capacidad para reconocer patrones que nunca fueron documentados formalmente.
Operational Knowledge = Explicit Rules + Tacit Knowledge + Experience + Context + Judgment
Convertir ese conocimiento en software tiene enormes ventajas: consistencia, repetibilidad, trazabilidad y capacidad de ejecución continua. Pero también introduce un riesgo profundo. Una política formal puede ejecutarse perfectamente y seguir siendo incorrecta si representa mal el problema: Correct Execution + Incorrect Policy = Incorrect Outcome.
Por ello, la transferencia de conocimiento experto hacia un agente debería parecerse menos a “escribir un gran prompt” y más a un ciclo de ingeniería: conocimiento y experiencia → identificación de peligros → reglas e invariantes → políticas computables → grafo o máquina de estados → ejecución y enforcement → evidencia operacional → revisión humana → evolución de políticas.
En lugar de preguntar únicamente “¿qué instrucciones necesita el agente?”, podemos formular una pregunta más fuerte: ¿qué estados serían inaceptables y qué secuencias de acciones podrían producirlos?
La autonomía no debería consistir en eliminar al experto del sistema, sino en conseguir que su conocimiento gobierne más decisiones sin fingir que todo su juicio puede reducirse a reglas.
4. Primera propiedad operacional: representar el tiempo como estructura, no como calendario
Muchas automatizaciones empresariales representan el tiempo mediante reglas discretas: solicitar información en T-8, recordar en T-5, escalar en T-2 y verificar en T. Es un mecanismo útil, pero supone implícitamente que conocer la distancia hasta una fecha es suficiente para conocer el riesgo. No lo es cuando las actividades dependen unas de otras.
Consideremos una cadena simplificada: Banco → Conciliación → Discrepancias → Cierre preliminar → Información fiscal → Revisión → Autorización → Pago. Si el extracto bancario llega seis horas tarde, el problema no son las seis horas en sí mismas. El problema es cuánto margen de recuperación ha desaparecido en las actividades dependientes y si continúa existiendo alguna secuencia de ejecución capaz de llegar al objetivo dentro de las restricciones.
Podemos representar el proceso como un grafo dirigido G = (V,E), donde los vértices V representan actividades, eventos o estados y las aristas E representan dependencias. Cada nodo puede poseer estado, duración, deadline, evidencia, responsable y riesgo; cada arista puede expresar una restricción temporal o causal.
5. De CPM a redes de restricciones temporales
El Método de Ruta Crítica proporciona una primera herramienta útil. Para una actividad i, la holgura total puede expresarse de forma compatible con HTML como TF(i) = LS(i) − ES(i), donde LS es el inicio más tardío compatible con el cronograma y ES el inicio más temprano.
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ólo una de ellas ha comprometido estructuralmente el objetivo.
James F. Allen introdujo en 1983 una lógica temporal basada en intervalos que permite expresar relaciones como before, meets, overlaps, during, starts o finishes y razonar sobre ellas mediante propagación de restricciones. El trabajo se convirtió en una referencia fundacional del razonamiento temporal computacional.
Sin embargo, sería incorrecto concluir que todo agente financiero necesita implementar el Álgebra 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.
6. Simple Temporal Networks: ¿sigue existiendo una solució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.
Una restricción puede escribirse como a(i,j) ≤ t(j) − t(i) ≤ b(i,j). Por ejemplo, 2h ≤ t(revisión) − t(recepción) ≤ 24h indica que la revisión debe ocurrir no antes de dos horas ni después de veinticuatro horas desde la recepción.
Si una observación modifica el tiempo real de conciliación, el sistema puede propagar la nueva restricción por la red y preguntar si continúa existiendo un cronograma factible. Si la respuesta es negativa, el proceso ya está comprometido aunque todavía falten días para la fecha final.
Un agente temporalmente competente no debería reaccionar solamente cuando una fecha se aproxima; debería reaccionar cuando el conjunto de soluciones factibles empieza a desaparecer.
7. Cuando la duración también es incierta
En la práctica, muchos procesos administrativos dependen de actores cuyo tiempo de respuesta varía. Un despacho, cliente, proveedor, banco o responsable interno no responde siempre en un intervalo fijo. La arquitectura puede modelar la latencia como una distribución y estimar la probabilidad de que el workflow termine antes del deadline.
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ótesis inicial proponía inferencia bayesiana para actualizar estos perfiles, pero la revisión no justifica convertir Bayes en requisito arquitectónico. Dependiendo del proceso pueden resultar apropiados percentiles históricos, modelos de supervivencia, distribuciones paramétricas, simulación Monte Carlo o reglas adaptativas conservadoras.
La propiedad importante no es el algoritmo concreto. Es que la arquitectura represente explícitamente incertidumbre en lugar de convertir estimaciones en hechos.
8. Segunda propiedad: separar lo dicho de lo demostrado
Supongamos que un tercero responde: “Listo, ya quedó enviado”. El LLM puede extraer correctamente una afirmación de finalización con alta confianza, pero ninguna de esas variables demuestra que el artefacto exista.
Necesitamos distinguir Declared State de Verified State. Una declaración no debería implicar automáticamente un estado verificado cuando el riesgo del proceso exige evidencia independiente.
Una arquitectura de estados puede recorrer: PENDING → DECLARED_COMPLETE → ARTIFACT_RECEIVED → VALIDATION_PENDING → VERIFIED → COMPLETED_VERIFIED, con una rama hacia INVALID cuando la validación falla.
No proponemos “cero confianza semántica” como principio absoluto. Una declaración humana puede constituir evidencia suficiente para algunos estados. La regla más precisa es: la fuerza de la evidencia necesaria debe crecer con la consecuencia de la transición que pretende habilitar.
9. El grafo necesita algo más que tareas: necesita procedencia
Para un sistema crítico necesitamos representar también artefactos, fuentes, validaciones, decisiones y políticas. Una transición relevante debería permitir reconstruir qué evidencia la habilitó, qué fuente produjo esa evidencia, cuándo fue obtenida, qué validador la examinó, qué versión de la política estaba vigente, qué persona o sistema tenía autoridad y qué cambio se produjo como consecuencia.
La decisión deja de depender solamente del contexto y pasa a depender de una estructura más rica: Decision = f(Context, Evidence, Provenance, Policy, Time, Authority).
El grafo empieza entonces a convertirse en algo más interesante que un workflow: una representación parcial del conocimiento operacional y de las condiciones que autorizan cambios en el estado empresarial.
10. Tercera propiedad: la inferencia puede proponer; una política independiente debe autorizar
Entre decisión y ejecución debería existir una capa independiente de política que compruebe permisos, evidencia, factibilidad temporal, impacto, reversibilidad y necesidad de aprobación humana. Si el mismo modelo que propone la acción puede redefinir también las condiciones que autorizan ejecutarla, la política deja de ser un límite independiente.
Proposal(action) ≠ Permission(action). La inteligencia puede recomendar. La política determina autoridad.
11. Cuarta propiedad: las mutaciones necesitan semántica transaccional
Supongamos que la política autoriza una acción y el agente solicita una operación externa. El servidor responde 504 Gateway Timeout. El sistema no sabe necesariamente qué ocurrió: la solicitud pudo no llegar, pudo llegar y fallar, o la transacción pudo confirmarse y perderse únicamente la respuesta.
El último caso es especialmente peligroso. Si el agente interpreta el timeout como fallo y repite la operación, puede duplicar un efecto cuya intención empresarial era única. Por ello, una arquitectura de misión crítica necesita tratar la intención operacional como una entidad persistente, con identificadores de operación, reconciliación antes del reintento y registro de estados.
El objetivo es que repetir la misma intención no multiplique sus efectos. Pero la arquitectura debe reconocer un límite: no puede imponer idempotencia sobre un sistema externo que no la soporte. Cuando la API destino no proporciona semántica idempotente suficiente, el agente necesita mantener su propio operation ledger, consultar el estado externo y reconciliar antes de volver a escribir.
12. Por qué Two-Phase Commit no resuelve mágicamente el problema
La hipótesis 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ón para asumir que todos soporten un coordinador transaccional común.
En esas circunstancias, patrones como Saga y las transacciones compensatorias ofrecen una abstracción más realista. La operación se divide en transacciones locales y, cuando un paso posterior falla, se ejecutan compensaciones cuando éstas sean posibles.
Aparece además un estado que los sistemas críticos deben admitir explícitamente: UNKNOWN. Puede haber situaciones en las que ni el agente ni la integración puedan demostrar automáticamente si el mundo quedó correctamente reconciliado. Ese estado no debería resolverse mediante una inferencia optimista del LLM; debe permanecer UNKNOWN hasta ser reconciliado o escalado.
13. Quinta propiedad: verificar la postcondición, no confiar en la respuesta de la herramienta
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ón puede haber actualizado el registro equivocado o un documento puede haberse generado sin cumplir los requisitos que habilitan el siguiente estado.
Tool Success ≠ Business Success. Después de una acción material debería existir una verificación independiente de la postcondición mediante lectura del estado, reconciliación y comprobación de invariantes. Una arquitectura gobernada exige demostrar que el estado observable después de la operación coincide con la postcondición esperada.
14. Sexta propiedad: escalar según riesgo, no según calendario ni ansiedad
Un agente que nunca pide ayuda puede ser peligroso. Uno que solicita autorización para cada operación elimina buena parte del valor de la autonomía. La cuestión relevante es determinar cuándo el riesgo de continuar autónomamente supera el costo de interrumpir a una persona.
Una política 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ía ingenuo reducir todos los riesgos a una sola cifra monetaria.
El objetivo del escalamiento tampoco debería consistir en transferir al directivo toda la incertidumbre del agente. Una buena escalación debería llegar preevaluada: estado observado, evidencia disponible, restricción comprometida, opciones factibles y consecuencias conocidas. El agente no debería escalar ansiedad; debería escalar decisiones.
15. Séptima propiedad: observabilidad suficiente para reconstruir una decisión
Un agente puede ejecutar correctamente y aun así ser inaceptable para un proceso crítico si después no podemos reconstruir por qué actuó. Necesitamos conservar observación, evidencia, inferencia, versión de política, autorización, llamada a herramienta, respuesta, mutación, postcondición y resultado verificado.
Esto permite distinguir la trayectoria de decisión y el estado final del mundo. Un agente puede producir una trayectoria aparentemente razonable y terminar en un estado incorrecto; también puede alcanzar un resultado correcto mediante una secuencia que violó políticas y que no debería repetirse. Por eso la evaluación debe preguntar simultáneamente si el resultado fue correcto y si la ejecución cumplió la política.
16. El caso fiscal mexicano demuestra por qué estas distinciones no son académicas
Consideremos una regla aparentemente prudente: “si un pago provisional está retrasado, existe revocación del CSD”. La regla podría llevar al agente a escalar inmediatamente una situación como amenaza de interrupción de facturación.
Sin embargo, el artículo 17-H Bis del Código Fiscal de la Federación establece supuestos específicos para la restricción temporal 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ún la cual un único pago provisional tardío produzca automáticamente revocación del CSD.
La diferencia entre un pago tardío y una condición jurídica para restricción del CSD es una diferencia de estado jurídico, no una sutileza lingüística. Este ejemplo revela por qué el grounding regulatorio no puede reducirse a “darle las leyes al LLM”: el sistema necesita conocer fuente autorizada, vigencia, jurisdicción, condiciones aplicables, evidencia requerida y frontera a partir de la cual la situación necesita interpretación profesional.
17. Un documento verificable tampoco es necesariamente válido para siempre
Algo similar ocurre con documentos cuyo estado parece binario. Una Opinión del cumplimiento positiva no debería convertirse en un estado de cumplimiento verificado indefinido. La utilidad de una evidencia puede depender de fecha, propósito, vigencia y contexto.
Por ello, una aproximación más rigurosa considera autenticidad, actualidad, compatibilidad con el propósito y autoridad de la fuente. Esto introduce una idea importante para el grafo: la evidencia también envejece. Una arista que hoy habilita una transición puede dejar de hacerlo mañana.
18. El grafo completo empieza a parecerse a un modelo operacional de conocimiento
Al reunir dependencias, tiempo, evidencia, procedencia, autoridad y riesgo obtenemos algo más 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ímites de su conocimiento: Known State, Unknown State, Insufficient Evidence, Policy Conflict, Outside Authority y Temporal Infeasibility.
Estos estados no son necesariamente errores. En un sistema bien gobernado pueden ser resultados correctos. Un agente capaz de reconocer “no dispongo de evidencia suficiente para continuar” puede ser operacionalmente más confiable que otro capaz de producir siempre una respuesta.
19. La arquitectura que emerge
La investigación permite proponer una arquitectura conceptual de siete capas, no como receta universal sino como conjunto de responsabilidades que conviene mantener separadas:
- Perception & Semantic Inference: LLM, extracción, clasificación y planificación.
- Temporal / Causal State: DAG, STN, deadlines, dependencias e incertidumbre.
- Evidence & Provenance: artefactos, validadores y fuentes autorizadas.
- Policy & Authorization: permisos, impacto, reversibilidad y compuertas humanas.
- Transactional Execution: idempotencia, retry, Saga y compensación.
- Post-condition Verification: read-back, reconciliación y comprobación de invariantes.
- Observability, Audit & Evaluation: trazabilidad, evidencia, política, resultado y aprendizaje.
El LLM puede participar en varias capas como instrumento de interpretación y razonamiento, pero eso no implica que deba convertirse en autoridad exclusiva de ninguna transición material.
20. Podemos expresar el principio central mediante invariantes
Para cualquier acción material, una arquitectura gobernada debería aspirar a que la ejecución sólo ocurra cuando la acción está autorizada, la evidencia es suficiente, el proceso sigue siendo temporalmente factible y la política de riesgo se satisface. Después de ejecutar, debe verificarse la postcondición.
Si la postcondición no puede demostrarse, el estado debe permanecer UNKNOWN hasta ser reconciliado. Las acciones de alto impacto y baja reversibilidad deberían requerir decisión humana, y una política no definida no debería interpretarse como permiso.
En sistemas de misión crítica, ausencia de restricción no debería equivaler automáticamente a autoridad.
21. ¿Dónde queda entonces la autonomía?
Una arquitectura que define con precisión estados, permisos, evidencia y reversibilidad puede permitir más autonomía donde esa autonomía es defendible, porque no necesita tratar todas las acciones como igualmente peligrosas.
Un mismo agente podría disponer de alta autonomía para consultar y reconciliar información, autonomía condicionada para crear borradores o preparar operaciones, aprobación humana para determinadas mutaciones y prohibición absoluta para otras acciones. Por tanto, la unidad correcta de gobierno no parece ser “el agente”, sino la acción dentro de un contexto.
Esta conclusión converge con el principio de Humano al Mando: propósito, evidencia y límites deben preceder a la delegación de acciones, y la responsabilidad empresarial permanece en las personas y en la organización. En ese marco, la autonomía se gradúa según el riesgo de la acción y las decisiones materiales de alto impacto permanecen bajo autoridad humana.
22. La relación entre humano y agente es más interesante que human-in-the-loop
La expresión human-in-the-loop puede resultar demasiado simple para describir lo que realmente necesita una organización. El humano no está únicamente esperando al final del proceso para aprobar una operación. Está presente antes de que el agente actúe porque su conocimiento fue utilizado para definir objetivos, políticas, restricciones e invariantes; durante la operación porque determinadas situaciones requieren escalamiento; y después porque la evidencia operacional permite revisar y mejorar las políticas.
La relación completa se parece más a: Human Knowledge → Policy → Agent Execution → Evidence → Human Learning → Policy Evolution.
El humano no debería estar solamente dentro del loop de aprobación; debería estar dentro del loop de aprendizaje y gobierno. Esto evita una falsa oposición entre autonomía y control: una organización puede aumentar considerablemente la autonomía operacional mientras mantiene —e incluso fortalece— el control humano sobre propósito, autoridad y excepciones.
23. Lo que esta investigación no demuestra
No hemos demostrado que estas siete capas sean suficientes para garantizar seguridad. Tampoco que una combinación concreta de STN, Bayes, Saga, máquinas de estados y políticas produzca automáticamente un sistema confiable. La evidencia científica reciente aconseja precisamente evitar esa conclusión.
Por tanto, la arquitectura presentada aquí debe entenderse como una arquitectura de requisitos y separación de responsabilidades, no como un producto terminado ni como una prueba de seguridad. Antes de conceder autoridad material a un agente serían necesarias evaluaciones específicas del dominio, simulaciones, pruebas adversariales, fault injection, pruebas de recuperación, evaluación de políticas, validación de integraciones y despliegues progresivos con límites de autonomía.
En procesos fiscales, financieros o regulatorios habría además que incorporar revisión profesional del dominio correspondiente. La arquitectura puede controlar cómo se aplica una política; no convierte automáticamente esa política en correcta desde el punto de vista jurídico, fiscal, contable o financiero.
24. La conclusión es distinta de la que esperábamos
Comenzamos esta investigación preguntando qué capacidades cognitivas adicionales necesita un agente para operar procesos financieros críticos. La respuesta parecía apuntar inicialmente hacia más inteligencia: mejor razonamiento temporal, mejor planificación, mejor inferencia probabilística y mejor capacidad de decisión.
Después de revisar la evidencia, esa formulación resulta insuficiente. El salto realmente importante no consiste solamente en aumentar la cognición del agente. Consiste en construir alrededor de esa cognición una arquitectura que limite su autoridad y conserve una relación verificable entre conocimiento, evidencia, decisión y consecuencia.
El agente necesita comprender el tiempo, pero también un grafo capaz de demostrar cuándo una ruta dejó de ser factible. Necesita interpretar lenguaje, pero también distinguir una afirmación de un hecho verificable. Necesita representar incertidumbre, pero sin convertir una probabilidad en certeza. Necesita herramientas, pero con permisos delimitados y políticas independientes. Necesita reintentar, pero sin multiplicar efectos. Necesita ejecutar, pero verificar después que el mundo quedó realmente en el estado esperado.
Y necesita algo que frecuentemente desaparece de las representaciones técnicas de Agentic AI: personas con conocimiento y experiencia capaces de definir qué significa actuar correctamente en primer lugar.
Podemos resumir el sistema completo como Critical Agentic System = Human Expertise + Governed Computation + Authoritative Evidence + Controlled Actuation, y su ciclo operacional como Observe → Infer → Constrain → Verify → Authorize → Act → Reconcile → Audit → Learn.
El objetivo no debería ser construir un sistema que necesite cada vez menos conocimiento humano. Debería ser construir uno capaz de convertir conocimiento y experiencia humanos en políticas, restricciones y criterios verificables que puedan operar continuamente a escala, conservando una frontera explícita para aquello que todavía exige juicio.
Porque cuando una inteligencia artificial adquiere capacidad para actuar sobre una empresa, la pregunta de ingeniería deja de ser “¿puede hacerlo?”. La pregunta que importa es mucho más exigente: ¿podemos demostrar, antes y después de cada acción crítica, que el sistema tenía conocimiento suficiente, evidencia suficiente, autoridad suficiente y una ruta segura para hacerlo?
Mientras la respuesta sea no, el sistema puede ser extraordinariamente inteligente. Pero todavía no deberíamos confundir inteligencia con confiabilidad.
Metodología, alcance y limitaciones
Esta pieza es una revisión narrativa y arquitectónica, no una revisión sistemática propia ni un experimento controlado. La investigación contrastó las hipótesis iniciales con literatura fundacional sobre razonamiento temporal y redes de restricciones, investigación científica reciente sobre seguridad y verificación de agentes LLM, patrones establecidos de sistemas distribuidos, documentación técnica de plataformas empresariales y fuentes regulatorias primarias.
Las hipótesis 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ón entre inferencia y evidencia; conservamos Bayes como una técnica posible y no obligatoria; abandonamos 2PC como prescripción general para sistemas empresariales independientes; incorporamos explícitamente verificación de postcondiciones, observabilidad y procedencia; y añadimos el conocimiento y experiencia humanos como parte constitutiva del sistema sociotécnico.
No afirmamos que esta arquitectura garantice seguridad, cumplimiento fiscal, ausencia de pérdidas ni corrección automática. Su aplicación a procesos reales requiere validación específica del dominio, controles organizacionales y revisión profesional cuando existan consecuencias regulatorias, fiscales, financieras o jurídicas.
Referencias científicas y técnicas principales
Allen, J. F. (1983). Maintaining Knowledge about Temporal Intervals. Communications of the ACM, 26(11), 832–843. DOI: 10.1145/182.358434.
Dechter, R., Meiri, I. & Pearl, J. (1991). Temporal Constraint Networks. Artificial Intelligence, 49(1–3), 61–95. DOI: 10.1016/0004-3702(91)90006-6.
Doshi, A., Hong, Y., Xu, C., Kang, E., Kapravelos, A. & Kästner, C. (2026). Towards Verifiably Safe Tool Use for LLM Agents. ICSE-NIER ’26. DOI: 10.1145/3786582.3786839.
Dantas, P., Cordeiro, L., Nowroozi, E. & Norbert, T. (2026). Toward Safe LLM Agents: A Survey of Specification, Verification, and Enforcement. Preprint.
Fuentes regulatorias y técnicas: SAT, artículos 17-H y 17-H Bis del Código Fiscal de la Federación; SAT, Opinión del cumplimiento y validación de CFDI; Microsoft Azure Architecture Center, patrones Saga y compensación; OWASP GenAI Security Project, Excessive Agency; NIST AI Risk Management Framework y recursos TEVV; documentación oficial de Zoho Books sobre Transaction Locking.
