PROGEN
Tienes un ERP que lleva ocho años funcionando, un CRM con el histórico comercial de toda la empresa y una hoja de cálculo que nadie se atreve a tocar porque la mantiene una persona concreta. Y ahora te piden «meter IA». La primera propuesta que te llega suele ser cambiar de sistema o contratar el módulo de IA del fabricante, que resulta que solo funciona si estás en la última versión y en la nube.
No hace falta. La mayoría de los casos de uso que interesan a una pyme —clasificar correos, extraer datos de facturas, resumir el estado de una cuenta, redactar respuestas a partir de datos reales— se resuelven conectando un modelo a los sistemas que ya tienes. El problema no es técnico, es de diseño: si cada caso de uso se integra por su cuenta, acabas con cinco integraciones frágiles que rompen cada vez que alguien actualiza algo.
El error habitual: integrar el modelo directamente contra el sistema
El camino corto es tentador. Coges la API del modelo, la API de tu CRM, escribes un script que las une y en dos días tienes una demo que funciona. El problema aparece al tercer caso de uso.
Cada nueva automatización repite la misma lógica: autenticarse contra el ERP, saber qué campos existen, traducir el resultado del modelo a algo que el sistema acepte, controlar errores. Si mañana cambias de proveedor de modelo —y vas a cambiar, porque salen versiones mejores y más baratas cada pocos meses— tocas los cinco scripts. Si el ERP actualiza un endpoint, tocas los cinco scripts.
El segundo error es darle al modelo acceso directo a la base de datos. Funciona en la demo y es una mala idea en producción: pierdes el control de qué se lee, no puedes auditar nada, y una consulta mal generada puede tumbar el rendimiento del ERP en horario de trabajo.
La capa intermedia: pocas piezas, bien definidas
La alternativa que usamos en casi todos los proyectos es meter una capa entre el modelo y los sistemas. No es un producto que haya que comprar, es una decisión de arquitectura. En la práctica son tres piezas:
- Un catálogo de acciones. Funciones concretas y acotadas:
buscar_cliente_por_cif,obtener_pedidos_pendientes,crear_incidencia. Cada una con sus parámetros, sus validaciones y sus permisos. El modelo no ve el ERP, ve este catálogo. - Un adaptador por sistema. El código que sabe hablar con tu ERP concreto, con su autenticación y sus rarezas. Es la única pieza que hay que tocar si cambias o actualizas el sistema.
- Un registro de todo lo que pasa. Qué se pidió, qué datos se leyeron, qué decidió el modelo, qué se escribió. Sin esto no puedes depurar nada ni justificar nada ante una auditoría.
Con esta separación, añadir un caso de uso nuevo es escribir dos o tres acciones más, no rehacer la integración. Y cambiar de modelo es cambiar una configuración.
El estándar que conviene conocer
Desde 2024 hay un protocolo abierto pensado exactamente para esto: MCP (Model Context Protocol), publicado por Anthropic y adoptado después por otros proveedores. Define una forma común de exponer datos y herramientas a un modelo, de manera que el mismo servidor de acciones sirva para distintos asistentes.
No es obligatorio usarlo. Si tu caso es una automatización interna y cerrada, un API propia bien diseñada hace lo mismo. Pero si prevés que varios asistentes o varias herramientas van a necesitar acceso a los mismos datos, montar la capa siguiendo MCP te ahorra rehacerla. Es la diferencia entre un enchufe estándar y soldar el cable.
Lectura y escritura no son el mismo problema
Conviene separar mentalmente dos niveles de integración, porque el riesgo y el esfuerzo son muy distintos.
Solo lectura. El modelo consulta datos para responder, resumir o clasificar. Aquí el riesgo principal es de confidencialidad y de exactitud: que se filtre información a quien no debe verla, o que el modelo afirme algo que no está en los datos. Se controla con permisos por usuario y obligando a citar el registro concreto del que sale cada dato.
Lectura y escritura. El modelo crea o modifica registros: abre una incidencia, actualiza el estado de un pedido, genera un presupuesto. Aquí el riesgo es operativo. La regla que aplicamos es sencilla: toda escritura pasa por validación de negocio en la capa intermedia, nunca en el prompt. Si un presupuesto no puede superar cierto importe sin aprobación, eso se comprueba en código. Un modelo no es un mecanismo de control.
En los primeros meses conviene además dejar las escrituras en modo propuesta: el sistema genera el borrador y una persona lo confirma con un clic. Cuando tienes cientos de casos revisados y sabes la tasa real de error, decides qué se automatiza del todo.
Qué mirar en tu ERP antes de prometer nada
No todos los sistemas se dejan integrar igual. Antes de comprometer plazos, comprueba cuatro cosas:
1. Si hay API documentada y en qué versión. Muchos ERP españoles la tienen solo a partir de determinada versión, o cobran el módulo aparte. Si tu instalación está muy retrasada, el coste real del proyecto incluye la actualización. 2. Si es instalación local o en la nube. En local hace falta resolver la conectividad y decidir si el tráfico sale a un modelo externo o usas uno alojado en tu propia infraestructura. 3. Cómo son los permisos. Si la API solo admite un usuario técnico con permisos totales, tendrás que replicar el control de acceso en la capa intermedia. Es factible, pero es trabajo. 4. Dónde está el dato de verdad. En bastantes empresas el dato bueno no está en el ERP, está en una hoja de cálculo compartida o en la cabeza de alguien. Eso no lo arregla la IA, y conviene saberlo antes.
Este diagnóstico es la parte menos vistosa y la que más discusiones evita después. Cuando abordamos un proyecto de integración de IA en empresas dedicamos las primeras sesiones exactamente a esto, antes de escribir una línea de código.
Costes: lo que se subestima
El coste por consulta a un modelo ha bajado mucho y sigue bajando. Casi nunca es la partida principal. Lo que se subestima es:
- El trabajo de mapeo de datos. Entender qué significa cada campo de tu ERP, cuáles están vacíos y cuáles se usan para otra cosa distinta de la que dice su nombre.
- El mantenimiento del catálogo de acciones. Cada cambio de proceso de negocio se refleja ahí.
- La revisión humana del primer periodo. Es un coste real de personas, y hay que planificarlo.
A cambio, si la capa está bien hecha, el segundo y tercer caso de uso cuestan una fracción del primero. Es donde se recupera la inversión, no en el piloto.
Cuándo no merece la pena
Seamos claros: hay situaciones en las que esto no sale a cuenta.
Si el proceso se ejecuta veinte veces al mes y tarda cinco minutos, el ahorro no paga la integración ni el mantenimiento. Si el ERP no tiene API y la única vía es raspar pantallas, la solución será frágil y romperá con cada actualización; a veces es mejor esperar a la migración que ya tenías prevista. Y si el proceso está mal definido —cada persona lo hace distinto y no hay criterio escrito—, lo que necesitas primero es ordenar el proceso. Automatizar el desorden solo lo hace más rápido.
El caso favorable es el contrario: volumen alto, criterio razonablemente estable, datos accesibles y un resultado que se puede verificar. Ahí la integración se amortiza en meses y, sobre todo, deja base para lo siguiente.
Preguntas frecuentes
¿Tengo que cambiar de ERP para usar IA?
En la gran mayoría de los casos, no. Si tu ERP tiene API documentada, se conecta mediante una capa intermedia sin tocar el sistema. El único escenario en el que la migración se vuelve inevitable es cuando la versión instalada no ofrece ninguna vía de integración soportada y la alternativa sería automatizar contra la interfaz de usuario, algo que rompe con facilidad.
¿Los datos de mi empresa se usan para entrenar el modelo?
Depende del proveedor y del contrato. Los planes empresariales de los principales proveedores excluyen por defecto el uso de datos de clientes para entrenamiento, pero hay que verificarlo en las condiciones concretas y no darlo por hecho. Si trabajas con datos especialmente sensibles, existe la opción de usar modelos alojados en infraestructura propia o europea, a cambio de más coste de operación y, normalmente, algo menos de calidad.
¿Cuánto tarda una integración de este tipo?
Un primer caso de uso bien acotado, con el ERP accesible y los datos razonablemente limpios, suele estar en producción en unas semanas. Lo que alarga los plazos casi nunca es el modelo: es conseguir accesos, aclarar reglas de negocio que estaban solo en la práctica y limpiar datos.
¿Qué pasa si mañana sale un modelo mejor?
Si la arquitectura separa el modelo de la lógica de integración, cambiarlo es una tarea de horas: mismas acciones, mismo control de permisos, distinto proveedor. Este es el argumento principal para no integrar el modelo directamente contra el sistema, aunque al principio parezca más rápido.