Integrar IA con CRM, ERP y herramientas internas: arquitecturas que funcionan en empresa

La pregunta que más nos llega en Everglow no es “¿qué modelo usamos?” ni “¿qué prompt es mejor?”. Es esta: cómo integramos la IA con el CRM, el ERP y el resto del software que ya tenemos sin romper nada. Y es la pregunta correcta. Porque la IA aislada del sistema operativo de tu empresa es una demo bonita que nadie usa. La IA conectada a tus datos y a tus procesos es lo que mueve la aguja.

El problema es que la mayoría de proyectos fallan en este punto exacto: no en el modelo, no en el prompt, no en el caso de uso, sino en la fontanería. Falla la integración. Y cuando falla la integración, falla el ROI.

Este post explica las arquitecturas que funcionan de verdad cuando integras IA con CRM, ERP y herramientas internas en una empresa mediana o grande. Sin diagramas de consultora, sin frameworks inventados. Con nombres concretos, decisiones reales y los errores que ya hemos visto cargarse pilotos enteros.

Por qué la integración es el cuello de botella real (y no el modelo)

Llevamos dos años con la sensación social de que el modelo lo es todo. Que si llega un LLM más potente, todo se resuelve. Es falso. Llevamos seis modelos generacionales y la mayoría de empresas españolas siguen sin un solo agente en producción tocando su CRM.

¿Por qué? Porque entre el LLM y el sistema de tu empresa hay una distancia enorme que nadie cuenta en las demos:

• El modelo necesita leer datos reales (no un PDF de muestra, sino la cuenta del cliente en tu CRM).
• El modelo necesita escribir datos reales (crear oportunidades, actualizar pedidos, mover tickets).
• El modelo necesita respetar permisos, roles y auditoría (no puede escribir cualquier cosa, ni en cualquier sitio, ni sin trazabilidad).
• El modelo necesita convivir con procesos existentes (no romper flujos, no duplicar registros, no saltarse validaciones).

Cuando hablas de integrar IA con SAP, Dynamics, HubSpot, Salesforce, Odoo, Holded, NetSuite, Zoho, Pipedrive o lo que sea que tengas, todo eso son requisitos no negociables. Si tu arquitectura no los cubre, no estás haciendo un proyecto de IA: estás haciendo un experimento que en algún momento se cancelará.

El modelo no es el cuello de botella. El cuello de botella es la capa que conecta el modelo con tu sistema real, lo hace seguro y lo hace observable.

Las tres arquitecturas que vemos funcionar (y la que casi nunca lo hace)

En Everglow llevamos implantando IA en empresas medianas y grandes en España el tiempo suficiente para que se repitan los patrones. Hay tres arquitecturas que funcionan según el caso. Hay una cuarta que se vende mucho y casi nunca llega a producción seria.

1. IA como capa de lectura sobre tus sistemas (read-only assistant)

Es la arquitectura más sencilla y la primera que recomendamos cuando una empresa empieza. La IA lee datos de tu CRM, ERP o herramientas internas, los procesa con un LLM y devuelve respuestas, resúmenes, recomendaciones o briefings. No escribe nada. Cero efectos secundarios.

Casos típicos:

• Un copiloto que resume el histórico de un cliente antes de la llamada (lee CRM + tickets + facturación).
• Un agente que prepara el briefing semanal del equipo de ventas (lee CRM + pipeline + emails).
• Una búsqueda semántica sobre la wiki interna o el repositorio documental (lee Notion, SharePoint, Confluence, Google Drive).
• Un asistente que responde dudas internas sobre políticas, procesos o productos (lee documentación + ERP).

¿Por qué funciona? Porque el riesgo es bajísimo. Si el modelo se equivoca, devuelve algo erróneo, pero no cambia nada en tu sistema. Y porque la integración es relativamente simple: solo necesitas conectores de lectura, no de escritura.

Stack habitual: APIs nativas del CRM/ERP + un orquestador (n8n, Make o código propio) + un LLM con función de búsqueda + una capa RAG sobre datos no estructurados. Si quieres profundizar en esa parte, ya escribimos sobre RAG empresarial en el blog de Everglow.

2. IA con escritura controlada (write-with-guardrails)

Cuando el read-only ya está funcionando y el equipo confía, se pasa a permitir que la IA escriba, pero con barreras claras. Esto es lo que de verdad libera horas, porque automatizas trabajo administrativo real.

Casos típicos:

• Un agente que crea o actualiza oportunidades en el CRM a partir de emails entrantes.
• Un asistente que da de alta facturas en el ERP a partir de PDFs recibidos.
• Un bot que mueve tickets de soporte entre cola y cola según contenido.
• Un copiloto que actualiza inventario o stock a partir de albaranes escaneados.

Las barreras que siempre ponemos en este patrón:

• Validaciones explícitas antes de cada escritura (esquema del dato, campos obligatorios, reglas de negocio).
• Confirmación humana en operaciones de alto riesgo (importes, cancelaciones, registros nuevos sin match).
• Logs detallados de cada acción (qué leyó, qué decidió, qué escribió, con qué prompt y qué modelo).
• Modo dry-run activable para auditorías y para los primeros días en producción.

Sin estas cuatro cosas, no es una arquitectura. Es una bomba de relojería.

3. Agentes IA con orquestación multi-paso (agentic workflow)

El siguiente nivel: agentes que ejecutan flujos de varios pasos coordinando varias herramientas internas. No es un copiloto, no es una automatización clásica, es un agente que decide dentro de un margen acotado.

Casos típicos:

• Un agente que procesa una queja en atención al cliente: lee el ticket, consulta el pedido en el ERP, mira el histórico en el CRM, decide la acción (reembolso, reposición, escalado) según política, ejecuta y notifica.
• Un agente comercial que, ante un lead, enriquece datos, cualifica, asigna a un representante, registra en CRM y dispara secuencia.
• Un agente de cuentas a pagar que valida facturas contra órdenes de compra, marca discrepancias y aprueba dentro de umbral.

Esta es la arquitectura más potente y la más exigente. Requiere:

• Definición clara del espacio de decisión del agente (qué puede y qué no puede hacer).
• Herramientas (tools) bien diseñadas: cada una hace una sola cosa y devuelve datos estructurados.
• Observabilidad seria: trazas completas de cada decisión, métricas de éxito por tipo de caso.
• Fallback humano siempre disponible para casos fuera del espacio de decisión.

4. La que casi nunca funciona: el LLM hablando “directamente” con tu base de datos

Es la arquitectura que más se vende en posts virales y la que más pilotos rompe. Suena bien: “el LLM genera SQL directamente sobre tu base de datos y responde lo que le pidas”. En la práctica:

• Tu base de datos no es analítica. Es transaccional, con joins complejos y nombres internos.
• El LLM se equivoca con queries no triviales y nadie revisa el SQL antes de ejecutarlo.
• No hay control de permisos por fila (un comercial podría ver datos de toda la empresa).
• El coste por consulta es impredecible (queries pesadas, timeouts, locks).

Funciona en demos sobre una tabla limpia. No funciona como sistema productivo sobre un ERP real con 15 años de evolución. Si oyes a alguien proponerte esto, pide ver tres referencias en producción con auditoría completa antes de firmar.

Los conectores que de verdad importan

Cuando integramos IA con herramientas internas en una empresa española, el 80% del trabajo está en estos puntos:

• CRM (Salesforce, HubSpot, Pipedrive, Zoho, Microsoft Dynamics, Odoo CRM): API REST nativa siempre que exista. Atención a límites de rate y a campos custom.
• ERP (SAP, Dynamics 365, Odoo, Holded, Sage, NetSuite, A3): aquí hay más fragmentación. Algunos tienen API decente, otros requieren middleware o webservices SOAP. Si el ERP es muy antiguo, valora añadir una capa de integración intermedia.
• Email y comunicación (Outlook/Microsoft 365, Gmail/Google Workspace, Slack, Teams): críticos como input (emails que llegan, mensajes, tickets) y como output (notificaciones, respuestas).
• Documentación interna (SharePoint, Notion, Confluence, Drive): clave para RAG. Cuidado con permisos: si el LLM accede a documentos que no debería, tienes una fuga.
• Ticketing y soporte (Zendesk, Freshdesk, Intercom, Jira Service Management): conectores estándar.
• Datos analíticos (BigQuery, Snowflake, Redshift, PostgreSQL): conectores read-only y bien parametrizados.

Para todo lo demás, o tiene API moderna o necesitarás un orquestador (n8n, Make o código propio) que actúe de pegamento. La elección entre n8n/Make/código depende de tres factores: volumen de operaciones, complejidad lógica y necesidad de control sobre datos sensibles. Para empresas medianas españolas, n8n self-hosted suele ser el punto óptimo en coste/control. Para volúmenes muy bajos, Make basta. Para casos muy críticos o muy específicos, código propio en Python/TypeScript.

Errores típicos al integrar IA con CRM y ERP en empresa española

Los hemos visto repetidos. Si vas a hacer esto en tu empresa, evítalos:

1. Conectar el LLM directamente a producción sin entorno de pruebas. Cada agente que vaya a escribir debe pasar por un sandbox o un dry-run en datos reales anónimos antes de tocar producción.
2. No mapear permisos. Si el agente lee con un usuario admin, tarde o temprano leerá lo que no debería. Cada agente debe tener su propio usuario con permisos mínimos.
3. No versionar prompts y configuraciones. Si un cambio de prompt rompe el flujo, necesitas poder volver atrás. Versiona prompts como versionas código.
4. No medir. Sin métricas de éxito por caso, no sabes si el sistema mejora o empeora con cada iteración. Mide tasa de éxito, intervención humana, latencia y coste por operación.
5. Subestimar el cambio organizativo. La integración técnica es el 50%. El otro 50% es que el equipo confíe, sepa usarlo y reporte lo que no funciona.
6. Confundir piloto con producción. Un PoC que sale bien no es un sistema productivo. Hay que pasar por hardening, monitorización, alertas, runbooks y postmortems.

Cómo medimos si una integración está lista para producción

Antes de declarar productivo un agente de IA conectado a CRM o ERP, validamos que cumple esto:

• Precisión mayor o igual al umbral acordado en el caso de uso (medido sobre dataset real, no sintético).
• Cobertura del caso (qué porcentaje de operaciones puede manejar sin intervención humana).
• Latencia dentro del SLA del proceso (un agente de atención al cliente que tarda 90 segundos no sirve).
• Coste por operación estable y predecible.
• Observabilidad completa: logs de prompts, respuestas, llamadas a APIs, decisiones y resultados.
• Plan de rollback claro: cómo desconectarlo en 5 minutos si algo se tuerce.
• Documentación operativa: el equipo cliente debe saber operarlo sin nosotros sentados al lado.

Sin estos siete puntos cubiertos, lo que tienes no está listo. Es un prototipo que da resultados, no un sistema productivo.

El orden importa: por dónde empezar si tu empresa quiere hacer esto bien

Si tu empresa está en este punto y no sabe por dónde empezar, este es el orden que recomendamos:

1. Caso de uso pequeño y medible. Uno solo. Con un dueño claro en el negocio.
2. Arquitectura read-only primero. Conectores de lectura, RAG si aplica, copiloto interno. Cero escritura.
3. Métricas desde el día uno. No se ajusta lo que no se mide.
4. Iteración corta (2-4 semanas). Cada iteración mejora algo concreto y se mide.
5. Cuando el equipo confía, pasar a escritura con guardrails.
6. Cuando la escritura es estable, considerar agentes multi-paso.
7. Escalar a otro caso de uso solo cuando el primero está sólido en producción.

Saltarse pasos cuesta. Hemos visto empresas intentar montar un agente multi-paso conectado al ERP como primer proyecto. Acaban con un piloto roto, un equipo escéptico y un comité directivo desconfiado. Recuperar esa confianza tarda meses.

Conclusión: la IA en empresa se gana o se pierde en la integración

El modelo es un commodity. Lo que va a diferenciar a las empresas que usen IA en serio en 2026 y 2027 no es qué LLM tienen, sino cómo lo han integrado con su sistema operativo real. CRM, ERP, herramientas internas, datos, permisos, procesos. Ahí está la palanca.

En Everglow integramos IA con CRM, ERP y herramientas internas en empresas medianas y grandes en España. No vendemos modelos: implantamos arquitecturas que funcionan en producción, con métricas, con observabilidad y con un equipo cliente capaz de operarlas. Pocos clientes, alto compromiso, foco en ROI medible.

Si tu empresa tiene un caso claro y quieres una conversación honesta sobre arquitectura, alcance y plazos, contacta con nosotros. Te decimos en una hora si tiene sentido y, si no lo tiene, también.