Un ERP completo en un día, creado por una IA. Esta afirmación me la encuentro ahora en conferencias y en casi una de cada dos publicaciones de LinkedIn. Creo que es falsa.

Después de más de 30 años en el desarrollo de software, sé dónde está el trabajo en un ERP: no en la primera pantalla, sino en los cien casos especiales que vienen después. Por eso, mi tesis es esta: quien quiera ampliar su ERP con IA debe empezar por el sistema existente. Dos ejemplos de nuestro día a día en Equitania muestran cómo hacerlo.

Un prototipo de IA todavía no es un ERP

Una IA crea en pocas horas una aplicación con inicio de sesión, lista de artículos y formulario de facturación. Parece un ERP. Pero, en la práctica, le falta casi todo lo que necesita una empresa:

• una conexión a base de datos que siga funcionando correctamente incluso bajo carga y ante errores
• un sistema de permisos y roles hasta el nivel de campo
• autenticación de usuarios con conexión a los servicios de directorio existentes
• una interfaz con la que el personal pueda trabajar ocho horas al día
• actualizaciones de seguridad, rutas de migración y datos inalterables y auditables

La gestión de permisos de Odoo por sí sola consta de grupos de usuarios, permisos de acceso por modelo de datos y reglas a nivel de registro. Los sistemas consolidados llevan años corrigiendo errores en cada uno de estos aspectos. Ninguna IA puede saltarse esos años. Por eso apostamos por sistemas que ya incorporan todo esto, preferiblemente de código abierto.

Ejemplo 1: Odoo Community con IA de su elección

Desde hace más de diez años trabajamos con Odoo, el ERP de código abierto basado en Python. Mientras tanto, hemos conectado nuestro desarrollo con Claude, el modelo de IA de Anthropic, y con Skills propios. Los Skills son instrucciones predefinidas que permiten a Claude conocer nuestras convenciones para los módulos de Odoo. Gracias a ello, los nuevos módulos se crean mucho más rápido que antes.

A nuestro parecer, los precios de licencia de la versión Enterprise llevan años subiendo. Pero hay algo que me preocupa más: las funciones de IA están integradas de forma fija y funcionan a través del fabricante Odoo S.A., en Bélgica. Así, no es su empresa quien decide qué modelo trabaja con sus datos empresariales.

Por eso, con ayuda de Claude, hemos creado nuestro propio chatbot con interfaz. Funciona en las versiones Community de Odoo 16 a 20. Está conectado a Langdock y a otros proveedores de IA con alojamiento en Alemania. Cada empresa elige el modelo y el proxy de IA con los que trabaja. El proxy es el intermediario por el que pasan todas las solicitudes al modelo, por ejemplo, para registrar los accesos o mantener los datos en Alemania.

Información según nuestro leal saber y entender, a fecha de octubre de 2026.

Hay un segundo efecto. Desarrollamos con ayuda de la IA, como módulos propios para la versión Community, funciones que solo están disponibles en la versión Enterprise. Son desarrollos propios: no copiamos el código de Enterprise, ya que está sujeto a una licencia propia y no abierta. El esfuerzo es asumible porque Odoo ya cuenta con la base de datos, los permisos y la interfaz. Aquí se ve lo que mejor sabe hacer la IA: cerrar brechas en un sistema estable.

Ejemplo 2: conectar software ERP propietario tras 20 años

El segundo ejemplo es más complicado. En nuestro grupo empresarial se utiliza desde hace más de 20 años un software ERP propietario, programado en C#. No tiene conexión con la IA ni interfaz de navegador; quien trabaja con él necesita un cliente Java.

Un cambio sería caro y arriesgado. Por otro lado, conocemos muy bien el software tras dos décadas. Así que lo ampliamos por dos vías.

Servidores MCP a través de la interfaz SOAP

MCP significa Model Context Protocol, un estándar abierto que permite a los modelos de IA trabajar con sistemas externos. Con Claude he creado un servidor MCP que accede al ERP a través de la interfaz SOAP existente. SOAP es un protocolo más antiguo basado en XML para servicios web, ofrecido por muchos sistemas heredados. Desde entonces, cualquier modelo de IA compatible con MCP puede trabajar con el sistema heredado.

Defino el alcance directamente en el servidor MCP: solo lectura o lectura y escritura. Lo que el servidor no permite, el modelo no puede hacerlo. Una solicitud sigue este recorrido:

1. El modelo de IA envía una solicitud al servidor MCP.
2. El servidor MCP comprueba si la acción está permitida (lectura o escritura).
3. Solo las acciones permitidas llegan al software ERP a través de la interfaz SOAP.
4. El resultado vuelve al modelo por la misma vía.

Paneles en el navegador, solo de lectura

La segunda vía es una aplicación web, también en C#. Lee directamente de la base de datos y no escribe nada en ella. Con solo pulsar un botón, la información de distintas áreas del sistema aparece en paneles claros y fáciles de consultar.

Para el personal, esto supone un alivio notable, ya que en la antigua interfaz tenían que abrir muchas pantallas para consultar los mismos datos. El inicio de sesión se realiza mediante inicio de sesión único (SSO) a través de LDAP, el servicio de directorio donde ya se encuentran las cuentas de usuario. Nadie necesita una contraseña adicional.

Un consejo, por si quiere replicarlo: antes de acceder directamente a la base de datos de un software propietario, compruebe qué dice al respecto su contrato de licencia.

¿Merece la pena implantar un nuevo sistema ERP en la era de la IA?

Actualmente, para la mayoría de las empresas medianas, no. No está claro cómo evolucionará la asistencia de la IA en los próximos años. Ampliar un sistema ya implantado con funciones de IA específicas cuesta menos, conlleva menos riesgos y permite dejar abiertas las decisiones futuras.

Prefiero invertir el presupuesto en tres ampliaciones específicas que en un proyecto de migración sin un final definido.

Quien implanta ahora un nuevo ERP compromete presupuesto y recursos durante años con una base que cambia constantemente. El caso es distinto si un sistema no ofrece ninguna interfaz o si el fabricante deja de prestar soporte. Entonces, a menudo no queda más remedio que cambiar, y aun así elegiría un sistema abierto como Odoo.

El personal necesita la IA dentro del sistema, no solo en el desarrollo

El punto más importante no tiene que ver con el desarrollo de software, sino con el trabajo diario en el ERP. El personal necesita poder mejorar sus propios procesos con IA: una pregunta al chatbot en vez de abrir cinco pantallas, un análisis mediante instrucciones en vez de exportar a Excel. Que funcione mediante una conexión MCP o mediante un chatbot directamente en Odoo es secundario.

Hay dos reglas que considero imprescindibles. El código generado por IA solo pasa a producción después de que lo revise un equipo de desarrollo con experiencia, porque incluso los buenos modelos cometen errores con mucha seguridad. Y los permisos de escritura para los modelos de IA son la excepción, porque muchos casos de uso funcionan con acceso de solo lectura.

Conclusión: ampliar es mejor que reconstruir

La IA no sustituye a un ERP maduro. Mejora un sistema existente en poco tiempo: en Odoo, con un margen de maniobra muy amplio; en un software propietario de 20 años, aún más de lo que la mayoría espera. El cielo es el límite, siempre que los cimientos sean sólidos.

Su próximo paso: Compruebe esta semana qué interfaces ofrece su ERP, como REST, SOAP o acceso a una base de datos. Anote las tres consultas para las que su equipo abre más pantallas. Ahí merece la pena hacer la primera prueba.