Guía: pasar de un asistente de IA a un agente en finanzas, con qué puede leer, preparar y contabilizar y límites validados en código

En dos frases

Un asistente de IA responde preguntas; un agente usa herramientas, y en finanzas las herramientas que importan son las que cambian la contabilidad. Esta guía propone llevar cada tarea por cuatro niveles de permiso, de una en una, con las reglas comprobadas en código y con las aprobaciones del propio ERP como última palabra.

Qué cambia cuando un asistente pasa a ser un agente

Anthropic distingue entre flujos de trabajo, en los que los pasos están fijados en código, y agentes, en los que el modelo decide qué herramientas usar y en qué orden, y recomienda empezar por la opción más sencilla y añadir autonomía solo cuando compense. Para un equipo financiero la pregunta práctica es más concreta: qué puede leer el agente, qué puede escribir y quién revisa lo que escribe.

Leer es de bajo riesgo si el acceso está limitado y queda registrado. Escribir es donde hay que diseñar los controles: un asiento en el periodo equivocado, una factura duplicada o una cuenta bancaria cambiada cuestan más de deshacer de lo que ahorra la automatización.

Cuatro niveles de permiso

Nivel	El agente puede	No puede	Controles necesarios	Tarea típica
1 Leer	Leer informes, mayores y documentos que se le dan	Cambiar nada	Usuario de solo lectura, registro de accesos	Responder sobre saldos, encontrar documentos
2 Borradores fuera del ERP	Preparar propuestas en ficheros o mensajes	Tocar el ERP	Revisión de una persona, archivo de propuestas	Borradores de conciliación, propuestas de periodificación
3 Borradores en el ERP	Crear asientos o facturas sin registrar	Registrarlos o aprobarlos	Validador en código, aprobaciones del ERP, usuario propio	Periodificaciones mensuales, reclasificaciones recurrentes
4 Registrar por debajo de un límite	Registrar una lista cerrada de tipos de asiento bajo un importe	Registrar cualquier otra cosa	Todo lo anterior, más revisión mensual de lo registrado	Asientos pequeños y recurrentes con un contrato detrás

La mayoría de equipos verá que el nivel 3 cubre lo que necesita: el agente prepara y una persona registra. El nivel 4 solo tiene sentido para asientos frecuentes, pequeños, basados en reglas y fáciles de revertir.

Lo que queda en manos de personas en todos los niveles

• Los pagos y los ficheros de pago, y cualquier cambio en los datos bancarios de proveedores o clientes.
• Crear o cambiar datos maestros que afecten a pagos o impuestos.
• Abrir y cerrar periodos, y cualquier asiento en un periodo cerrado.
• Usuarios, roles y permisos, incluidos los del propio agente.
• Las declaraciones y presentaciones de impuestos.

Escribe esta lista en las instrucciones del agente, pero no confíes en las instrucciones: hazla cumplir con los permisos del usuario del agente en el ERP.

Cuándo puede subir de nivel una tarea

Sube una tarea solo cuando todas las respuestas sean sí, y solo después de al menos dos cierres en el nivel inferior:

1. Regla clara. ¿Podrías escribir en pocas líneas cómo decide una persona el asiento?
2. Evidencia disponible. ¿El documento de soporte (contrato, albarán, calendario) está al alcance del agente y se adjunta a cada propuesta?
3. Historial. En los dos últimos cierres, ¿coincidieron las propuestas del agente con lo que hizo el equipo, con las diferencias explicadas?
4. Reversible. Si el asiento está mal, ¿se puede revertir en el periodo siguiente sin consecuencias fuera de la empresa?
5. Importe acotado. ¿Hay un límite por encima del cual aprueba una persona con nombre, y lo hace cumplir el sistema?
6. Segregación. ¿Quien aprueba es distinto de quien mantiene las reglas del agente?

Si alguna respuesta pasa a ser no, baja la tarea de nivel. La decisión y el motivo van al registro.

El agente propone; el código comprueba

El patrón más seguro que conocemos es que el agente nunca escriba texto libre en el ERP. Devuelve una propuesta en JSON con un esquema fijo, y un programa corto la comprueba antes de que pase nada más. Las API de OpenAI y de Claude ofrecen salidas estructuradas, que hacen que la respuesta del modelo siga un JSON Schema que tú defines; eso garantiza la forma de la propuesta, no que su contenido sea correcto, y por eso existe el validador.

Un prompt para la propuesta (redacción propia; los nombres de campo van en inglés para que coincidan con el validador):

Preparas borradores de asientos contables para {{EMPRESA}}. Nunca registras, apruebas ni pagas.
Para cada tarea, devuelve solo un objeto JSON con: proposal_id, date, period, status ("draft"),
description, source_documents (lista), lines (account, debit, credit, cost_center o partner),
reasoning, confidence ("high", "medium" o "low") y questions (lista).
Usa solo las cuentas de CUENTAS_PERMITIDAS y solo importes que aparezcan en los documentos de soporte.
Si hay que estimar un importe, no propongas el asiento: pon la pregunta en "questions".
Si el periodo del asiento no está en PERIODOS_ABIERTOS, no lo propongas: explica por qué en "questions".

El validador aplica las reglas que pide el prompt, porque un prompt se puede ignorar y el código no:

RULES = {
    "open_periods": {"2026-10"},
    "allowed_accounts": {"6210000", "6280000", "6290000", "4100000", "4800000", "4850000"},
    "auto_limit": 5000.00,          # above this, a named person must approve
}
if p["period"] not in RULES["open_periods"]: errors.append(f"period {p['period']} is not open")
if dr != cr: errors.append(f"not balanced: debit {dr} vs credit {cr}")
if p.get("status") != "draft": errors.append("status must be 'draft'")
if dr > RULES["auto_limit"]: warnings.append(f"amount {dr} above {RULES['auto_limit']}: route to a named approver")

• Validador (Python, solo biblioteca estándar)
• Propuesta ficticia que pasa (JSON)
• Propuesta ficticia que no pasa (JSON)

Al ejecutar python3 validate_draft.py proposal-ok.json proposal-bad.json se obtiene (los mensajes del script están en inglés):

proposal-ok.json ACCEPTED AS DRAFT []
proposal-bad.json REJECTED ['period 2026-09 is not open', 'not balanced: debit 7200.0 vs credit 7020.0',
  'line 1: account 6270000 not allowed for this agent', "status must be 'draft'",
  'amount 7200.0 above 5000.0: route to a named approver']

La primera propuesta es una periodificación de 1.850 por la limpieza de octubre, con la cláusula del contrato como evidencia. La segunda intenta registrar unos honorarios de marketing estimados a partir de un correo, en un periodo cerrado, con debe y haber distintos y el estado “posted”: justo el tipo de asiento que los niveles deben frenar.

Dónde vive la aprobación humana

Hay tres sitios donde poner a una persona en el circuito, y se pueden combinar:

• En la orquestación. n8n permite exigir aprobación humana antes de que un agente de IA ejecute una herramienta concreta: la solicitud llega por un canal como Slack o el chat de n8n, y la herramienta solo se ejecuta si alguien la aprueba.
• En el código del agente. El OpenAI Agents SDK tiene guardrails de entrada, de salida y de herramientas; cuando salta una comprobación, la ejecución se detiene. El validador de arriba puede funcionar como una de esas comprobaciones.
• En el ERP. Es la que mirará el auditor, porque forma parte del sistema contable. Úsala aunque tengas también las otras dos.

Variantes por ERP

• Microsoft Dynamics 365 Business Central: lo preparado en los diarios generales no está en la contabilidad hasta que se registra, y los flujos de aprobación pueden exigir aprobar lotes o líneas de diario, incluidos los diarios de pagos, antes de registrar. Da al usuario del agente un lote de diario propio.
• Odoo: los asientos y las facturas de proveedor se crean en borrador y solo afectan a la contabilidad cuando alguien los publica o confirma; limita al usuario del agente a crear borradores en los diarios que elijas.
• SAP: los documentos preliminares se guardan sin actualizar la contabilidad y pueden completarse y contabilizarse después por un usuario con esa autorización; el usuario técnico del agente puede crear preliminares, pero no contabilizar.
• NetSuite: se puede exigir aprobación de los asientos de diario antes de que se registren, con un circuito de aprobación para los roles implicados; el rol del agente los crea y otra persona los aprueba.

En todos los casos, el agente se conecta con un usuario técnico propio, nunca con la cuenta de una persona, para que la pista de auditoría muestre lo que hizo el agente.

Pasos de revisión humana

1. Aprueba por escrito el nivel de cada tarea, con las seis preguntas respondidas.
2. Revisa cada borrador que cree el agente hasta que la tarea tenga un historial limpio; después, una muestra más todo lo que supere el límite.
3. Comprueba cada mes que el usuario del agente en el ERP sigue teniendo solo los permisos de su nivel.
4. Lee los rechazos del validador: un patrón de rechazos indica que hay que revisar las reglas, los datos o el prompt.
5. Guarda el registro de propuestas, rechazos y aprobaciones con los papeles del cierre.

Errores frecuentes

• Controles solo en el prompt. “No registres nunca” en las instrucciones no es un control; un usuario sin permiso para registrar, sí.
• Usar la cuenta personal de alguien para el agente. La pista de auditoría deja de servir y el acceso es mucho más amplio de lo necesario.
• Saltar directamente al nivel 4. Sin dos cierres de comparación no conoces la tasa de error del agente con tus datos.
• Aceptar estimaciones. Si el importe no está en un documento, el agente debe preguntar, no proponer.
• Un único límite para todo. Los límites dependen de la cuenta y del tipo de asiento; una periodificación de 4.000 y un ajuste de ventas de 4.000 no tienen el mismo riesgo.
• No prever la marcha atrás. Decide de antemano qué hace bajar de nivel una tarea, y déjalo por escrito.

Límites

Esta guía es un punto de partida, no un marco de control aprobado por nadie. Tu auditor, tu función de control interno y tu partner del ERP deberían revisar el diseño antes de que un agente tenga permisos de escritura. Los ejemplos son ficticios y el validador cubre solo las reglas básicas; uno real necesita tu plan de cuentas, tus límites y tus tipos de asiento.