# Cómo integrar agentes de IA con el ERP paso a paso

> Cómo integrar IA con el ERP paso a paso: lectura antes que escritura, permisos por operación, idempotencia y qué hacer si el ERP no tiene API.

- Canonical: https://arkatai.com/integrar-agentes-con-el-erp/
- Site: Arkatai (https://arkatai.com) — agentic operations as a service
- Language: es
- Published: 2026-07-19

---


Integrar un agente de IA con el ERP no consiste en enchufar el modelo al sistema y dejarlo suelto. Consiste en darle a un agente el mismo tipo de acceso que tiene un operador —leer donde vive el caso, escribir donde corresponde— pero con límites por operación, capacidad de deshacer y un sitio donde probar antes de tocar producción. El orden importa. Primero se enseña al agente a leer y proponer, y solo cuando eso es fiable se le permite escribir. Aquí está la secuencia que sigo, y qué hacer cuando el ERP es antiguo o no expone una API.

Hablo de "un ERP" en genérico porque el patrón es el mismo con cualquiera. Lo que cambia entre uno y otro es cuánta ceremonia hace falta para cada paso, no la lógica.

## Primero leer, después escribir

La primera integración de cualquier agente debería ser de solo lectura. Que consulte el pedido, la factura, el estado del stock, y proponga lo que haría —sin ejecutarlo—. Durante ese periodo una persona revisa las propuestas y se comprueba contra los casos reales si el criterio del agente coincide con el que aplicaría un buen operador.

Esta fase parece un rodeo y es justo lo contrario. Es la que evita el desastre. Un agente que solo lee no puede romper nada, así que puedes dejarlo funcionar sobre la operación real sin riesgo mientras acumulas evidencia de su calidad. Cuando los datos demuestran que acierta, se le concede la escritura para esa operación concreta, no para todo. La escritura se gana operación a operación, no se regala de golpe.

## Permisos por operación, no por sistema

El error clásico es dar al agente una credencial de ERP con los permisos de un usuario avanzado y confiar en que "solo hará lo que debe". Un agente no debería tener acceso de usuario, sino de tarea.

En la práctica eso significa definir el permiso al nivel de la operación concreta: este agente puede leer facturas y crear un asiento de conciliación dentro de una tolerancia, pero no puede modificar maestros, ni aprobar pagos, ni tocar nada fuera de ese verbo. Cada capacidad se concede de forma explícita y se puede retirar sin desmontar el resto. Este diseño de permisos es una pieza de gobierno por derecho propio, y lo trato con más detalle en [permisos y controles de agentes](/permisos-y-controles-de-agentes/).

| Nivel de acceso | Qué habilita | Riesgo si se concede de más |
|---|---|---|
| Lectura | Consultar el caso y su contexto | Bajo; contenerlo aquí al principio |
| Escritura acotada | Crear o actualizar un registro dentro de reglas | Medio; exige idempotencia y traza |
| Escritura sensible | Pagos, maestros, cierres | Alto; suele quedar en escalado humano |

## Idempotencia y reversibilidad

Dos propiedades técnicas que no son opcionales cuando un agente escribe en el ERP.

**Idempotencia**: que ejecutar la misma acción dos veces produzca el mismo resultado que ejecutarla una. Los agentes reintentan, los procesos se cruzan, las redes fallan a mitad. Si el agente crea un pedido y no recibe confirmación, no puede permitirse crear un segundo pedido duplicado al reintentar. Se resuelve con claves de operación que el ERP reconozca como "esto ya lo hice", de modo que el reintento no duplica.

**Reversibilidad**: que toda acción tenga una forma definida de deshacerse o compensarse. No todo se puede borrar en un ERP —un asiento contable se corrige con un contraasiento, no con un delete—, así que "reversible" significa que existe un camino conocido para dejar las cosas como estaban. Antes de permitir una escritura, exijo saber cómo se revierte. Si no hay forma de deshacerla, esa operación se queda en la lista de las que un humano confirma.

## Un entorno donde probar sin miedo

Ningún agente toca producción sin haber trabajado antes contra un entorno de prueba con datos representativos. Ahí es donde se corren las evaluaciones —casos con respuesta conocida— y donde se observa cómo se comporta el agente con los bordes: la factura mal escaneada, el proveedor duplicado, el pedido a medio cerrar.

Si tu ERP tiene un entorno de test o preproducción, ese es el sitio. Si no lo tiene, se construye uno acotado: una copia de datos o un conjunto sintético que reproduzca los casos que importan. Montar esa medición es la diferencia entre desplegar con criterio y desplegar con fe. Cómo se hace está en [evaluación de agentes de IA](/evaluacion-de-agentes-de-ia/). Saltarse este paso es una de las causas por las que tantos pilotos no sobreviven al primer contacto con la realidad, algo que analizo en [por qué fracasan los pilotos de IA](/por-que-fracasan-los-pilotos-de-ia/).

## Cuando el ERP es antiguo o no tiene API

Buena parte del parque de ERP en empresas medianas no expone una API moderna, o expone una parcial. No es un obstáculo insalvable, sino una decisión sobre qué mecanismo de conexión usar, del más limpio al más artesanal.

- **API o conectores nativos.** Si existen, es la vía preferente: contrato explícito, permisos granulares, comportamiento predecible. Un protocolo como el que describo en [MCP, el Model Context Protocol](/mcp-model-context-protocol/) estandariza cómo un agente se conecta a herramientas y sistemas, y reduce el trabajo a medida.
- **Exports e imports por fichero.** Muchos ERP antiguos hablan bien por lotes: el agente lee un export programado y deja sus resultados en un import que el sistema recoge. Menos inmediato, pero robusto y fácil de auditar.
- **Colas intermedias.** Una capa de mensajería entre el agente y el ERP desacopla los dos ritmos, absorbe los picos y da un punto natural donde registrar cada operación y reintentar con seguridad.
- **La interfaz de usuario como último recurso.** Cuando no hay otra puerta, un agente puede operar la propia pantalla del ERP como lo haría una persona. Funciona, pero es lo más frágil: cualquier cambio de la interfaz lo rompe. Lo reservo para operaciones acotadas y siempre con vigilancia estrecha.

La regla que aplico: cuanto más artesanal es el canal, más estrecho el mandato y más traza se exige. Un agente que opera por la pantalla merece menos confianza autónoma que uno con una API contractual detrás.

## El sitio de esta integración en el conjunto

Conectar el ERP es una pieza de una arquitectura más amplia —memoria, orquestación, controles— que describo en [arquitectura de agentes de IA](/arquitectura-de-agentes-de-ia/). Dos temas quedan deliberadamente fuera de este artículo porque son suyos: qué datos necesita el agente antes de integrarlo, en [qué datos necesita un agente](/que-datos-necesita-un-agente/); y qué pasa con los casos que la integración no puede resolver sola, en [excepciones y escalado a humanos](/excepciones-y-escalado-a-humanos/). Y como toda conexión a un sistema crítico abre superficie de riesgo, conviene leerla junto a [seguridad de agentes de IA](/seguridad-de-agentes-de-ia/). El marco general está en [agentes de IA para empresas](/agentes-de-ia-para-empresas/).

## Preguntas frecuentes

### ¿Puede un agente de IA escribir directamente en el ERP?

Sí, pero se gana por fases. La primera integración es de solo lectura: el agente propone y una persona revisa. Cuando las evaluaciones demuestran que su criterio es fiable, se le concede la escritura para esa operación concreta, con idempotencia y una forma definida de revertir. La escritura sensible —pagos, maestros, cierres— suele quedar en confirmación humana.

### ¿Cómo integro un agente si mi ERP no tiene API?

Por otros canales. Exports e imports por fichero funcionan bien con ERP antiguos, una cola intermedia desacopla ritmos y da trazabilidad, y como último recurso el agente puede operar la propia interfaz de usuario. Cuanto más artesanal el canal, más estrecho debe ser el mandato y más vigilancia se exige.

### ¿Qué es la idempotencia y por qué importa al integrar IA con el ERP?

Es la propiedad de que ejecutar una acción dos veces produzca el mismo resultado que ejecutarla una. Como los agentes reintentan y las redes fallan a mitad, sin idempotencia un reintento crearía pedidos o asientos duplicados. Se resuelve con claves de operación que el ERP reconoce como ya ejecutadas.

### ¿Necesito un entorno de pruebas para conectar un agente al ERP?

Sí. Ningún agente debería tocar producción sin haber trabajado antes contra un entorno de prueba con datos representativos, donde se corren las evaluaciones y se observa su comportamiento con los casos límite. Si el ERP no tiene preproducción, se construye un entorno acotado con una copia de datos o un conjunto sintético.