Cómo integrar la IA con los sistemas de la empresa (ERP, CRM y lo que ya existe)

El proyecto de integración no fracasa por la API, fracasa porque tres sistemas dicen tres cosas distintas

Una empresa mediana decide montar agentes de IA empresariales para que respondan directamente a sus clientes sobre el estado de un pedido, sin pasar por un asesor. El área de TI cotiza la conexión con el ERP, porque ahí vive, en teoría, el dato bueno. La primera semana de pruebas, el agente contesta con una fecha de entrega que el cliente ya sabe que es falsa: el vendedor le prometió otra por WhatsApp y la anotó en una hoja de cálculo que nadie conectó a nada. La segunda semana, el agente contesta con un precio que en el ERP figura correcto, pero que el área comercial cambió hace dos semanas en el CRM, porque negoció un descuento que todavía no viajó al sistema madre. Nadie mintió. Cada sistema dijo lo que sabía. El problema es que nadie, antes de conectar la IA, se sentó a decidir cuál de los tres manda cuando discrepan.

Esto se repite en casi cada proyecto de integración que llega a mi mesa. La conversación arranca en “necesitamos conectar la IA con el ERP y el CRM” y termina, semanas después, en una discusión incómoda sobre qué área es dueña del dato de precio, de stock o de estado de cuenta. La API casi nunca es el obstáculo real: casi cualquier sistema moderno expone una, y hasta los más viejos suelen tener alguna puerta de salida. El obstáculo real es que integrar sin resolver antes esa pregunta no reduce el caos, lo automatiza. Antes, la inconsistencia la resolvía un vendedor con criterio, que llamaba para confirmar antes de prometer algo. Con la IA conectada, la misma inconsistencia le llega al cliente en el mismo segundo, con la misma seguridad con la que antes decía la verdad.

Qué significa integrar la IA con tus sistemas, en criterio de negocio y no de TI

Integrar la IA con el ERP, el CRM o cualquier otro sistema no es, en el fondo, un problema de cables ni de protocolos. Es el acto de decidir, antes de escribir una sola línea de conexión, qué sistema tiene autoridad sobre cada dato que la IA va a usar para responder o para actuar. Cuando esa decisión no se toma de forma explícita, la toma la IA sola, por default, casi siempre eligiendo el primer sistema al que alguien la conectó, que no necesariamente es el que la empresa hubiera elegido si se lo hubieran preguntado directamente.

Esa decisión, quién manda cuando dos sistemas dicen cosas distintas, es lo que separa una integración que reduce trabajo de una que multiplica los tickets de soporte. Cuando el dato de origen está claro, conectar el sistema es, técnicamente, la parte más sencilla del proyecto: leer una tabla, llamar a una API, procesar un archivo. Cuando no está claro, no hay arquitectura de integración que lo arregle, porque el problema no vive en el cableado: vive en el organigrama, donde dos áreas creen, con razón, que ellas son las dueñas del dato correcto.

Por qué la fuente única de verdad se decide antes de integrar, no después

La fuente única de verdad no es un concepto técnico, es un acuerdo de negocio que alguien con autoridad tiene que firmar antes de que el equipo técnico toque un solo sistema. Significa elegir, campo por campo, cuál sistema manda: si el precio lo define el ERP o el CRM, si el estado de cuenta lo dice contabilidad o el sistema de cobranzas, si el dato de contacto vigente lo tiene el CRM o la plataforma de marketing. Decidirlo después de integrar sale más caro, porque para entonces la IA ya construyó respuestas, automatizó acciones y, en algunos casos, escribió de vuelta en más de un sistema.

• Precio y condiciones comerciales: casi siempre lo decide el ERP o el sistema de facturación, no el CRM, aunque el CRM sea donde el vendedor negocia.
• Estado de cuenta y cobranza: lo dice el sistema contable o financiero, nunca una hoja de cálculo paralela que el área comercial usa para hacer seguimiento.
• Dato de contacto vigente: suele mandar el CRM, porque es donde el vendedor actualiza el teléfono o el correo con el que habla todos los días.
• Stock e inventario disponible: lo define el sistema de operaciones o el ERP, y ningún otro sistema debería sobrescribirlo sin pasar por ahí.

Este acuerdo no lo redacta el proveedor de la integración ni el área de sistemas: lo redactan las áreas de negocio, porque son las que conviven con la consecuencia de que la IA le diga al cliente un precio o una fecha equivocada. Eso es, en el fondo, ordenar la memoria organizacional de la empresa antes de dejar que un sistema nuevo lea de ella y actúe. Sin ese acuerdo, cada integración nueva que se agrega no reduce la confusión: le suma una fuente más a la lista de fuentes que ya no cuadran entre sí.

Los 3 caminos para integrar la IA con tus sistemas, y lo que cada uno cuesta mantener

Una vez que la empresa decidió quién manda cada dato, queda la pregunta técnica, que es mucho más simple de lo que el discurso comercial de muchos proveedores hace parecer. En la práctica hay tres caminos, y la elección no depende de cuál es “mejor” en abstracto, sino de cuánto la empresa está dispuesta a pagar en mantenimiento, no en construcción inicial. El costo de construir una integración casi nunca es el problema. El costo de mantenerla viva los próximos tres años sí lo es, y es el que casi nadie presupuesta.

• Conexión directa vía API: la IA, o la capa que la conecta, llama en tiempo real al sistema de origen y lee o escribe el dato en el momento. Es la opción más rápida de respuesta y la que exige más mantenimiento, porque cualquier cambio de versión, de permisos o de estructura en el sistema de origen puede romper la conexión sin avisar, y alguien tiene que estar mirando para notarlo.
• Capa intermedia o middleware de integración: en vez de conectar la IA directo a cada sistema, se conecta a una capa central que traduce y sincroniza entre todos. Cuesta más armar al inicio, porque hay que diseñar esa capa, pero absorbe mejor los cambios futuros: si el ERP cambia de versión, se ajusta un solo punto en vez de todas las conexiones que dependen de él.
• Exportaciones periódicas o por lotes: el sistema de origen exporta sus datos cada cierto tiempo, cada hora o cada noche, y la IA trabaja sobre esa copia, no sobre el sistema en vivo. Es la opción más barata de mantener y la más tolerante con sistemas viejos, con el costo de que la IA nunca responde con el dato del segundo exacto, sino con el de la última exportación.

Ninguno de los tres caminos es incorrecto por sí solo: cada uno resuelve un problema distinto y cuesta distinto de sostener. La pregunta que sí conviene hacerse antes de elegir es qué tan “fresco” necesita ser el dato para que la respuesta de la IA sea útil. Un agente que confirma stock antes de prometer una fecha de entrega necesita algo cercano al tiempo real. Un agente que resume el historial de compras de un cliente para el equipo de marketing puede trabajar perfectamente con una exportación de la noche anterior. Esa decisión, más que la tecnología en sí, es la que define cómo hacer que la IA use las herramientas de tu empresa y sus sistemas sin que el proyecto se encarezca innecesariamente.

Qué hacer cuando el sistema viejo no tiene API, que es más común de lo que parece

Buena parte de las empresas que más necesitan IA tienen, al mismo tiempo, el sistema más viejo, ese que corre hace quince años, que nadie quiere tocar porque “si funciona, no se toca”, y que casi nunca tiene una API pensada para conectarse con nada moderno. Aquí es donde muchos proyectos se frenan, no porque sea imposible, sino porque el proveedor de turno solo sabe vender el camino de la API directa y, cuando no existe, concluye que “no se puede integrar”. Casi siempre se puede, solo que no de la forma más elegante.

• Leer directamente la base de datos, cuando el sistema lo permite, en modo de solo lectura y sobre una réplica, nunca sobre la base productiva. Es más frágil que una API, porque cualquier cambio de estructura interna rompe la lectura, pero funciona cuando no hay otra puerta.
• Exportar archivos de forma periódica desde el propio sistema viejo, algo que casi cualquier ERP antiguo sabe hacer aunque no tenga API, y dejar que la IA trabaje sobre esa exportación en vez de pedirle al sistema una respuesta en vivo.
• Automatización de interfaz, donde un proceso automatizado lee la pantalla del sistema viejo como lo haría una persona, cuando ni la base de datos ni la exportación son viables. Es la opción más costosa de mantener de las tres, porque cualquier cambio visual en el sistema rompe la automatización.
• Reemplazar el sistema, que rara vez es la primera conversación pero a veces es la conclusión honesta: si un sistema no tiene API, no expone su base y no genera exportaciones confiables, el problema ya no es de integración con IA, es de que ese sistema debió reemplazarse hace tiempo por otras razones.

Antes de elegir cualquiera de estas rutas conviene tener claro qué es una API y por qué la necesitas para conectar IA, porque buena parte de la frustración con sistemas viejos viene de pedirle a un sistema algo que nunca fue diseñado para dar. No es un defecto del sistema: es que se construyó en una época en la que nadie imaginó que un modelo de IA iba a necesitar leerlo en tiempo real.

El costo real de una integración a medida no es construirla, es mantenerla viva

Cuando un proveedor cotiza “la integración”, casi siempre cotiza el desarrollo inicial: las horas de programar la conexión, probarla y dejarla funcionando en producción. Esa es la parte barata y la más fácil de medir. El costo real, el que decide si el proyecto fue una buena inversión o un dolor de cabeza recurrente, aparece después, cuando el sistema de origen cambia de versión, cuando el proveedor del ERP modifica un campo, cuando cambia una regla de permisos y la conexión deja de funcionar un lunes a las ocho de la mañana sin que nadie lo haya anticipado.

Una integración a medida no es un objeto que se entrega y queda terminado, es una relación que hay que sostener mientras ambos sistemas sigan vivos y cambiando por su cuenta. Entender qué es una API de IA y cómo se integra en una empresa ayuda a dimensionar esto: cada API tiene su propio ciclo de versiones, y una integración construida hoy sobre una versión específica puede quedar obsoleta cuando el proveedor la actualiza, sin la anticipación que uno esperaría. Por eso, en cualquier cotización seria, tiene que aparecer, además del desarrollo, quién se hace cargo del monitoreo, quién recibe la alerta cuando algo se rompe y con qué urgencia se atiende.

En el mercado se suele hablar del costo de una integración como si fuera un número fijo, cuando en realidad depende de cuántos sistemas toca, qué tan documentadas están sus APIs y cuánta gente interna sabe explicar cómo funciona el sistema viejo. Lo que sí puedo decir, por lo que he visto en proyectos reales, es que el presupuesto de mantenimiento casi nunca se calcula, y que el costo de no calcularlo aparece de todas formas, solo que como una emergencia no planificada en vez de como una línea de presupuesto.

Cuándo conviene no integrar nada todavía y trabajar con exportaciones

No todo proyecto de IA necesita una integración en tiempo real, y asumir que sí es una de las formas más rápidas de encarecer un proyecto que podía resolverse con mucho menos. Antes de cotizar cualquier conexión, conviene repasar qué necesito antes de implementar IA (el checklist previo), porque buena parte de esa lista es, precisamente, entender qué tan urgente es de verdad la frescura del dato que la IA va a usar.

• El proyecto está en etapa de piloto o prueba de concepto: integrar en vivo antes de validar que el caso de uso funciona es construir infraestructura para algo que todavía puede cambiar de forma o cancelarse.
• La decisión que la IA apoya no es urgente por minuto: un reporte semanal, un resumen de tendencias o una recomendación de compra no necesitan el dato del segundo exacto, y una exportación diaria o incluso semanal resuelve el caso sin el costo de una conexión en vivo.
• El sistema de origen es frágil o está por reemplazarse: conectar en tiempo real un sistema que la empresa ya sabe que va a migrar en el corto plazo es construir sobre algo que se va a desarmar, y ese esfuerzo se pierde.

Trabajar con exportaciones no es una versión inferior de integrar, es una decisión de negocio legítima cuando el caso de uso lo permite. El error no está en usar un archivo en vez de una conexión en vivo: está en no decidirlo a propósito, y terminar con una integración compleja y cara para un caso de uso que nunca necesitó tanta inmediatez.

Mi criterio sobre por dónde empezar de verdad

La integración no es el proyecto: es la consecuencia de haber ordenado quién manda

Cuando una empresa entiende esto, el orden de trabajo deja de ser “conectemos todo y después vemos” y pasa a ser el que de verdad rinde: primero se acuerda, con nombre y apellido, quién es dueño de cada dato crítico. Después se elige el camino de integración según qué tan urgente es la frescura de ese dato, no según la moda del momento. Y solo al final se construye la conexión técnica, que para entonces es la parte más simple y más barata de todo el proyecto. Este orden es, en esencia, el mismo que siguen las fases de implementación de IA en una empresa que funcionan de verdad: el acuerdo de negocio va antes que la arquitectura técnica.

La API nunca fue el problema. El problema fue siempre organizacional: decidir, entre personas con intereses distintos, cuál sistema tiene la última palabra cuando dos fuentes se contradicen. Una empresa que resuelve esa pregunta antes de integrar gasta menos en desarrollo, menos en mantenimiento, y evita el momento en que un cliente descubre, antes que el propio equipo, que sus sistemas internos no se ponen de acuerdo entre sí.