Cualquier conexión entre tu ERP y WhatsApp se reduce a tres caminos: lectura directa de base de datos, API REST oficial del ERP, o una capa MCP que abstrae las dos anteriores. Este post explica los tres en lenguaje claro y te ayuda a elegir el que aplica a tu caso.
La decisión técnica suele tomarse en cinco minutos cuando uno conoce los tres caminos. Lo que suele atascar la conversación es que el equipo TI piensa en uno solo (el que ya usó) y descarta los otros sin compararlos. Vale la pena revisar las tres opciones para evitar elegir mal por costumbre.
El escenario
Una empresa LATAM con un ERP estándar — Microsip, Defontana, Aspel, Tango, Bind, Alegra, SAP Business One, Odoo, o uno desarrollado in-house. La operación quiere que un agente IA atienda WhatsApp Business leyendo y, en algunos casos, escribiendo datos del ERP. Los casos típicos: cobranza, consulta de saldo, registro de promesas de pago, briefing comercial.
La pregunta no es si se puede conectar — siempre se puede. La pregunta es por dónde, con qué costo de implementación y qué pasa cuando el ERP cambia.
Antes de revisar los tres caminos, conviene fijar un principio: la integración la define tu ERP, no la herramienta de IA. Una herramienta seria de agentes IA soporta los tres caminos y elige el que funciona para tu caso. Una herramienta inflexible pide que tu ERP encaje en su camino — eso suele significar migración o reescritura.
Camino 1 — Base de datos directa
El más simple cuando se tiene acceso. El agente IA se conecta a la base de datos del ERP con un usuario de solo lectura y consulta las tablas que necesita: clientes, facturas, pagos, vendedores, productos. Las consultas son SQL estándar, los datos llegan en tiempo real, no hay capa intermedia que mantener.
Cuándo conviene. ERP on-premise o en VPS con acceso de DBA controlado. Empresa con equipo TI que conoce el esquema. ERPs sin API o con API limitada. Volumen de operaciones razonable (millones de filas no, pero cientos de miles sí).
Cómo se implementa. Tres pasos:
- Crear un usuario de solo lectura en la base. Sin permisos de escritura, sin acceso a tablas sensibles innecesarias.
- Construir vistas (
VIEWSQL) sobre las tablas críticas — clientes, facturas, pagos. Las vistas aíslan al agente de los cambios de esquema del ERP y permiten agregar lógica de filtro (excluir clientes inactivos, sumarizar pagos parciales). - Configurar el agente para consultar contra las vistas, no directamente contra las tablas.
Ventajas. Velocidad de implementación. Datos en tiempo real. Sin dependencia del roadmap del proveedor del ERP. Funciona con cualquier ERP que tenga una base accesible.
Desventajas. Si el ERP cambia esquema, hay que ajustar las vistas. No funciona si el proveedor del ERP no permite acceso externo a la base (algunos SaaS lo bloquean). Requiere alguien con SQL en el equipo de implementación.
Camino 2 — API REST oficial del ERP
Usar la API que el ERP expone para integraciones externas. Cada ERP que tiene API documenta sus endpoints — GET /facturas, POST /pagos, GET /clientes/{id} — y el agente consume esos endpoints como cualquier otra integración.
Cuándo conviene. ERPs en la nube con API REST documentada. Defontana, Alegra, Bind, Tiendanube, Odoo, Holded son ejemplos típicos. También Microsip cuando la operación está en su nube.
Cómo se implementa.
- Solicitar credenciales de API al proveedor del ERP. Suelen ser un token o un par client_id/client_secret. Algunos proveedores cobran por el acceso a API, otros lo incluyen.
- Identificar los endpoints relevantes para los procesos a automatizar. No todos los ERPs exponen todo — algunos tienen API solo para facturas, no para pagos.
- Configurar autenticación, paginación y manejo de rate limits en el agente.
- Probar contra un entorno sandbox cuando el ERP lo provee.
Ventajas. Estabilidad frente a cambios internos del ERP. El proveedor mantiene compatibilidad. Documentación oficial. Soporte del proveedor si algo falla.
Desventajas. No todos los ERPs LATAM tienen API. Los que tienen, no siempre cubren todos los casos (puede haber endpoint para leer facturas pero no para leer pagos). Algunos cobran por uso de API. Rate limits pueden ser apretados.
Camino 3 — MCP (Model Context Protocol)
El estándar abierto que Anthropic publicó en 2024 para que modelos de lenguaje puedan conectarse a sistemas externos a través de una capa común. En lugar de que cada agente IA tenga su propia integración con cada ERP, se monta un servidor MCP entre el agente y el ERP que expone "herramientas" estandarizadas ("consultar factura", "registrar pago", "buscar cliente").
Cuándo conviene. Empresas con varios ERPs o sistemas que se quiere consultar desde el mismo agente. Empresas que proyectan sumar más agentes y quieren una capa de integración única. ERPs custom donde tiene sentido construir la capa una vez y reusarla.
Cómo se implementa.
- Identificar qué herramientas necesita el agente — "buscar factura por número", "listar facturas vencidas", "registrar promesa de pago".
- Construir un servidor MCP que expone esas herramientas. Internamente, cada herramienta consulta la base de datos o la API del ERP — pero el agente no ve esa diferencia.
- Conectar el agente IA al servidor MCP como una integración estándar.
Ventajas. Una sola capa de integración para múltiples agentes. Si el ERP cambia, solo cambia la implementación del MCP — los agentes no se enteran. Estandarización: si en el futuro se cambia de ERP, solo hay que reescribir el MCP, no el agente.
Desventajas. Más complejo que los dos caminos anteriores. Requiere construir y mantener el servidor MCP. Solo paga la complejidad si se proyecta escala — un solo agente contra un solo ERP no justifica el overhead.
Cómo se conecta Pacunex con cualquier ERP
La estrategia es pragmática: usamos el camino que aplica a tu caso, no el que tenemos predefinido. Si tu ERP tiene API REST documentada, la usamos. Si tu ERP es on-premise con base de datos accesible, leemos la base. Si tu ERP es custom o se proyecta sumar más agentes, montamos MCP.
El conector específico lo construye el equipo de Pacunex durante la implementación, con tu equipo TI participando solo en la parte de accesos. No es un onboarding tipo formulario; es trabajo de construcción con dos personas técnicas.
Para casos específicos hay posts dedicados: agente IA para Microsip, agente IA para Defontana. Y la lista de integraciones que ya tenemos resueltas vive en agentes IA por ERP.
Casos típicos
ERP en VPS con SQL Server o PostgreSQL. Camino 1. Vista materializada sobre tablas de cartera. Tiempo de implementación: días, no semanas.
ERP en la nube con API REST documentada (Defontana, Alegra, Bind). Camino 2. Credenciales de API, prueba en sandbox, validación de endpoints. Tiempo similar.
ERP propio o muy custom. Generalmente Camino 3 (MCP) si se proyectan varios agentes. Camino 1 (base directa) si es un solo caso.
ERP que no permite ningún acceso externo. Caso raro pero existe. Se monta un agente local que sincroniza un subset de datos hacia una base intermedia accesible. Funciona, no es ideal, pero existe.
Qué hacer si algo sale mal
El ERP no permite lectura externa. Verificar si hay versión cloud, plan superior con API, o posibilidad de réplica local. Si no hay ninguna opción, evaluar sync programado.
La API tiene rate limits muy bajos. Cachear consultas, batch de operaciones, agendar gestión en horarios distribuidos.
Cambio de esquema rompe la integración. Si la integración va por vistas, ajustar la vista. Si va por API y el proveedor cambió endpoints, leer changelog y ajustar.
Performance lenta en consultas masivas. Mover lógica pesada a vistas materializadas o a la capa MCP. Evitar que el agente haga consultas repetidas sobre los mismos datos.
Seguridad de la integración
Sea cual sea el camino elegido, hay cuatro principios de seguridad que aplican siempre.
Usuario dedicado con permisos mínimos. El agente nunca usa credenciales humanas ni cuentas de servicio con permisos amplios. Un usuario propio, solo lectura sobre lo necesario, sin acceso a tablas que no se usan.
Conexiones cifradas. TLS en API REST, conexiones SSL/TLS en bases de datos. Sin excepciones, incluso si el ERP está en la misma red corporativa.
Logs auditables. Cada consulta que el agente hace contra el ERP queda registrada. Quién (qué agente, qué cliente atendía), cuándo, qué consultó, qué obtuvo. Esto permite responder a auditorías y diagnosticar problemas.
Rotación de credenciales. Tokens y contraseñas se rotan cada periodo definido por la política de seguridad de la empresa. La integración debe soportar la rotación sin caer.
Cómo medir si está funcionando
KPIs operativos para validar la integración una vez en producción:
- Latencia promedio de consulta. Si el agente espera cinco segundos para saber el saldo de un cliente, la conversación se siente robotizada. Lo razonable es por debajo del segundo en consultas habituales.
- Tasa de errores de consulta. Idealmente cero. Cualquier error que llegue al cliente final es un problema, porque rompe la confianza del cliente con la empresa.
- Frescura de datos. Cuánto tiempo pasa entre que un pago entra al ERP y el agente lo ve. En la mayoría de operaciones, 1-2 horas alcanza para no molestar a un cliente que ya pagó.
- Volumen de consultas. Para dimensionar el rate limit de la API o la carga sobre la base. Una operación bien diseñada cachea lo estable y consulta solo lo necesario.
Errores comunes al planear la integración
Empezar por la herramienta y no por el caso. Si la conversación arranca con "queremos usar MCP", está mal. Debe arrancar con "queremos automatizar cobranza para 1.500 facturas mensuales". La herramienta sale de ahí.
Subestimar el plazo de obtención de accesos. Especialmente con APIs cloud que requieren proceso interno del proveedor del ERP. Empezar a tramitar accesos el primer día del proyecto, no a mitad.
No involucrar al equipo TI desde el inicio. Si el equipo TI se entera del proyecto cuando ya está aprobado, suele oponer resistencia técnica legítima. Conviene incluirlos en la decisión.
Aceptar datos sucios sin limpieza. El agente reproduce los errores del ERP. Si hay clientes duplicados, números de teléfono inválidos o facturas con datos incompletos, el primer paso del proyecto debería ser limpieza.
Próximos pasos
Cuéntanos tu ERP por WhatsApp y te decimos qué camino conviene en tu caso, antes de cualquier compromiso. La conversación es técnica, no comercial: si el camino más limpio es uno que ya tienes resuelto internamente, te lo decimos.