Los equipos de finanzas pasaron 2025 preguntándose si un agente de IA podía cerrar los libros. La pregunta correcta es qué parte del trabajo debería tocar un modelo probabilístico. La respuesta que se está imponiendo en la práctica es una arquitectura dividida: el modelo lee y propone, mientras que una capa determinística independiente, construida a partir de reglas aprobadas por personas, ejecuta el registro contable, la aprobación y el pago.
Esto es un diseño de control, no una preferencia. Un agente con 97 por ciento de exactitud al codificar facturas resulta impresionante como investigación e inaceptable como auxiliar contable: ese 3 por ciento aterriza en un libro mayor que los auditores van a probar y en una cuenta bancaria que mueve dinero real. El mercado convergió rápido. El 4 de agosto de 2026, Kognitos anunció Context Graph for Finance, que combina contexto financiero específico y reglas aprobadas por personas con ejecución determinística, comenzando por cuentas por pagar. agentOS de Fiserv, lanzado en mayo de 2026 y con disponibilidad amplia prevista para agosto de 2026, incorpora controles de política, auditabilidad y supervisión humana por diseño. Gartner ha proyectado que el 40 por ciento de las aplicaciones empresariales incluirán agentes de IA para tareas específicas antes de que termine 2026, frente a menos del 5 por ciento en 2025. Los agentes van a llegar, haya usted diseñado o no los controles que los rodean.
Porque un modelo de lenguaje grande produce la respuesta más plausible, no la misma regla aprobada aplicada de forma idéntica en cada ejecución. Eso es una virtud para redactar y un defecto para ejecutar. Los controles financieros dependen de tres propiedades que un modelo sin restricciones no puede ofrecer:
La exactitud no es el control. Lo que ocurre entre la sugerencia y el asiento contable sí lo es.
Trace la línea en el cambio de estado y el movimiento de dinero. El no determinismo está bien dondequiera que la salida sea una propuesta que una regla o una persona validará, y es inaceptable dondequiera que sea el acto final.
Aceptable (percepción y razonamiento): extraer campos de una factura no estructurada, leer un contrato para identificar condiciones de pago, normalizar nombres de proveedores, resumir una variación, redactar un memorando de provisión, proponer una conciliación de línea bancaria, clasificar excepciones.
Inaceptable (ejecución): registrar un asiento contable, liberar un archivo de pagos, cambiar los datos bancarios de un proveedor, aprobar contra una delegación de autoridad, ajustar una reserva, cerrar un periodo, castigar un saldo. Eso le corresponde a código con número de versión y batería de pruebas.
Deje que el modelo perciba y proponga; nunca deje que ejecute. Todo cambio de estado debe pasar por un ejecutor determinístico que aplique reglas aprobadas por personas, rechace las entradas que no reconoce y registre la versión de la regla y los datos que utilizó.
Construya dos componentes con un contrato entre ellos, no un único agente con credenciales de escritura.
Convierte una realidad desordenada en una propuesta estructurada: entidad, proveedor, montos, fechas, codificación propuesta, orden de compra y recepción coincidentes, evidencia y una señal de confianza. Tiene acceso de lectura y cero credenciales de escritura. Aquí es donde los agentes de IA a la medida demuestran su valor, porque lo difícil es la comprensión, no hacer clic.
Acepta o rechaza esa propuesta: la valida contra un esquema, evalúa las reglas aprobadas en un orden fijo, verifica la conciliación a tres vías y la delegación de autoridad, y luego registra a través de la API soportada del ERP o la deriva a una cola humana con un código de motivo identificado. Ninguna llamada a un modelo vive dentro de él. Es software común y corriente, versionado en Git, probado en CI y desplegado por la misma canalización de AI DevOps que produce. Nunca permita que interprete una propuesta parcial.
Los umbrales pertenecen a la política, no se descubren en el código. Un patrón inicial para cuentas por pagar, ajustado a su materialidad:
Dos reglas mantienen honesta la supervisión humana. La aprobación debe ser un acto afirmativo sobre una propuesta específica, no un reconocimiento masivo de una cola. Y mida su tasa de corrección: si los aprobadores aceptan más del 98 por ciento de las propuestas sin editarlas, la revisión se convirtió en un trámite. La segregación de funciones también aplica al agente: quien puede cambiar una regla no debe poder aprobar un pago que esa regla libera, lo cual es una extensión de sus controles de identidad y acceso.
Suponga que un auditor le pide reejecutar una transacción de hace un año. Capture, en almacenamiento de solo anexado y conforme a su política de retención:
Dos detalles importan más de lo que los equipos esperan. Registre las reglas que se evaluaron como falsas, porque la evidencia negativa es la forma de demostrar que un control operó. Y versione las reglas con fechas de vigencia, de modo que una transacción de marzo se explique con las reglas de marzo y no con las de hoy. Combine esto con observabilidad de agentes para que la desviación en la extracción aparezca como una alerta y no como un hallazgo de auditoría.
Asigne a cada propuesta una clave de idempotencia determinística: un hash del identificador del proveedor, el número de factura, la fecha de la factura, la moneda y el monto. El ejecutor verifica esa clave antes de escribir y devuelve el resultado anterior en lugar de crear un segundo documento. Cuando el ERP o la API bancaria carece de idempotencia nativa, mantenga su propio registro de operaciones intentadas y trate una respuesta agotada por tiempo como algo que exige conciliación antes de reintentar, nunca como permiso para reenviar.
Un pago duplicado convierte un logro de automatización en una conversación sobre reexpresión de estados financieros. Los reintentos, la reentrega de colas y las interrupciones parciales crean las condiciones, y un agente que decide intentarlo de nuevo empeora las cosas.
La seguridad de reejecución es la misma disciplina mirando hacia atrás: reproduzca un día de propuestas contra una nueva versión de reglas en un entorno aislado y compare los resultados. Si reproducir lo de ayer genera registros distintos hoy, o bien cambiaron sus reglas (algo válido, si está documentado) o su ejecutor tiene estado oculto.
Los controles preventivos detienen lo que usted anticipó. La conciliación detecta lo que no anticipó, y es la mejor alerta temprana de que un agente empezó a comportarse de otra manera. Concilie a diario en lugar de mensualmente: auxiliar contra libro mayor, banco contra caja, y el registro de propuestas del agente contra los asientos que realmente existen en el ERP. La tercera comparación es la importante: detecta asientos sin propuesta, propuestas que se registraron sin pasar por el ejecutor y diferencias de conteo que señalan un problema de reintentos. Fije un umbral de variación, alerte cuando se supere y asigne un responsable a cada partida antigua. La mayoría de los programas de conciliación automatizada cubren las dos primeras y omiten la tercera.
No haga el piloto sobre pagos reales. Ejecute el agente contra volumen histórico real con la escritura deshabilitada, comparando las propuestas con lo que hizo su equipo.
Después opere en paralelo, con el agente proponiendo y las personas decidiendo, y mida la coincidencia. Nuestro enfoque de pruebas de simulación para agentes de IA profundiza en esto. Esta es la fase que los equipos más lamentan haber acortado.
Ordene por reversibilidad. Empiece donde un error sea barato de deshacer.
Espere que esto sea más lento y más aburrido que las demostraciones, y espere que eso sea justamente el punto. Las organizaciones que obtienen resultados duraderos no son las que tienen más agentes financieros autónomos, sino las que decidieron temprano qué decisiones puede tomar un modelo y escribieron el resto como código.
Infonaligy es una firma de consultoría en IA y servicios de TI con sede en Dallas-Fort Worth que atiende de forma remota a todo el país. Ayudamos a los líderes de finanzas y de TI a diseñar la separación entre razonamiento y ejecución, y a comprobar que la capa de control funciona antes de que toque el libro mayor. Si está dimensionando la automatización de cuentas por pagar sin intervención o una Automatización de Procesos más amplia, nuestro equipo de consultoría puede ponerla a prueba: hello@infonaligy.com o 800-985-1365.
Infonaligy apoya a líderes de finanzas y TI desde nuestra base en Dallas-Fort Worth, con entrega remota para empresas con múltiples entidades en todo el país.
Un proyecto con Infonaligy comienza con un diagnóstico de dos semanas de sus flujos financieros, sus sistemas y sus controles actuales, y luego diseña la separación entre un agente que razona y un ejecutor determinístico: reglas aprobadas, umbrales de aprobación, una pista de auditoría inmutable y conciliación diaria. Construimos alrededor de su ERP existente, lo comprobamos en modo sombra contra su propio historial y capacitamos a su equipo para operarlo.
Infonaligy