Tu ERP ya trae IA. Sage la lleva metida en los flujos financieros, Business Central la tiene dentro de la ficha, Odoo la integró de serie en su versión 19 y Holded la vende en el panel. Si estás pagando cualquiera de los cuatro, la pregunta que te estás haciendo es razonable: ya tengo IA incluida, ¿para qué voy a contratar nada por fuera?
La tesis en una frase: el copiloto del fabricante resuelve muy bien lo que pasa dentro de una pantalla —resumir, sugerir, rellenar, explicar un registro que ya tienes delante— y no resuelve nada de lo que cruza sistemas, que es justo donde está el trabajo caro. Y lo importante no es que aún no lo haga: es que no está construido para hacerlo. Es una frontera de arquitectura, no una fila pendiente de su hoja de ruta.
IA nativa del ERP vs agente externo: la frontera no es de funciones, es de arquitectura
Mira qué hacen realmente los copilotos nativos y verás que todos comparten la misma forma. En Odoo 19 la IA dejó de ser un módulo aparte: la documentación oficial describe agentes que se construyen con temas —las instrucciones que le dicen al agente qué hacer— y herramientas asociadas a esos temas. En Business Central, la función más citada por los equipos financieros es la conciliación bancaria asistida: propone coincidencias entre las líneas del extracto importado y los apuntes del mayor, y sugiere la cuenta contable de las que no casan. En Sage, el copiloto vive dentro de los flujos financieros y su agente de importación recorta la preparación manual de datos en migraciones e importaciones recurrentes.
Es buen producto. Fíjate en lo que tienen en común: los tres trabajan sobre datos que ya están dentro del sistema, en la pantalla donde el usuario ya está, con los permisos de ese usuario y mientras ese usuario está mirando. El ERP no es donde vive el copiloto: es todo su mundo. Esa es la frontera, y explica a la vez lo que hace bien y lo que no va a hacer nunca.
Las tres cosas que el copiloto nativo te da y deberías estar usando
- Explicarte un registro que ya tienes abierto. Resumir el histórico de un cliente, contarte por qué esta factura está en esta situación, traducir un asiento a lenguaje humano. Es contexto inmediato sobre datos que el sistema ya tiene y a los que tú ya tienes derecho.
- Proponer dentro de un formulario, con las reglas del propio sistema. Conciliación bancaria, cuenta contable sugerida, descripción de producto, texto de una oferta. El fabricante juega en casa: conoce su modelo de datos mejor que nadie y las sugerencias respetan sus propias validaciones.
- Preguntar a tus datos sin construir un informe. Lo que antes era pedirle a alguien un listado y esperar dos días ahora es una frase. No es poco: es la diferencia entre decidir con datos y decidir de memoria.
Esto viene incluido en lo que ya pagas, así que activarlo y formar a la gente es de las decisiones más baratas que vas a tomar este año. Quien te diga lo contrario te está vendiendo algo. Nosotros también: por eso lo decimos antes.
Las tres que no te va a dar nunca, y por qué es arquitectura y no roadmap
Ahora la otra cara. Hay tres tipos de trabajo que el copiloto del fabricante no hace, y ninguno de los tres se arregla esperando a la siguiente versión.
- El trabajo que cruza sistemas. La factura llega por correo, el albarán está en un PDF del proveedor, el pedido vive en el ERP y la incidencia se resolvió por WhatsApp. Cuadrar esas cuatro cosas es el trabajo que cuesta dinero, y tres de las cuatro no están dentro del ERP. Un copiloto que solo ve una de ellas no puede cerrarlo, por bueno que sea.
- El trabajo que espera a alguien de fuera. Un presupuesto que necesita el sí del cliente, un proveedor que no contesta, una aprobación que lleva cuatro días parada. Ahí el cuello de botella no es entender el dato: es perseguir a una persona que no tiene tu ERP abierto ni lo va a abrir.
- El trabajo que ocurre cuando nadie está mirando. Los procesos que corren de madrugada, detectan una excepción y tienen que decidir si escalan a alguien. El copiloto necesita a un usuario delante que le pida algo; su unidad de trabajo es la sesión, no el proceso.
La razón de fondo es la misma en los tres casos. El copiloto nativo hereda tres límites del sistema que lo aloja: el límite del dato (solo ve lo que está dentro), el límite de permisos (actúa como el usuario que lo invoca, ni más ni menos) y el límite del reloj (empieza cuando alguien escribe y termina cuando esa persona cierra la pantalla). Un agente que atraviesa procesos necesita exactamente lo contrario: identidad propia, permisos propios acotados a su tarea, y un reloj propio. Eso no es una función que Sage o Microsoft puedan añadir en la release de primavera: es otro objeto.
Dónde está el punto en el que sale a cuenta lo de fuera
La pregunta no es «cuánta IA necesito», que no se puede contestar. Es una mucho más aburrida y sí medible: cuántas veces al día alguien tiene que salir de tu ERP para terminar un trabajo. Ese número es el que decide, y lo puedes contar esta semana sin comprar nada.
- Cuenta los saltos. Coge tres procesos que te duelan y anota cada vez que alguien sale del ERP para completarlos: abrir el correo, buscar el PDF, escribir por WhatsApp, entrar en el portal del proveedor. Cada salto es trabajo que el copiloto nativo no ve.
- Mide la espera, no el tecleo. El coste real casi nunca es el minuto de escribir: es el tiempo que el trabajo está parado esperando a alguien. Un presupuesto que espera cuatro días no cuesta cuatro minutos de administrativo, cuesta cuatro días de caja.
- Pon precio al error tardío. Los errores que se descubren dentro de la pantalla son baratos; los que se descubren tres semanas después, en el cierre o en la factura del cliente, no lo son. Cuenta cuántos de los últimos diez se descubrieron tarde.
Si los tres números salen bajos, enhorabuena: activa el copiloto, forma al equipo y no gastes más. Si salen altos —y en la mayoría de las pymes con varios sistemas salen altos— tienes identificado, con nombre y apellidos, exactamente dónde hace falta algo que el fabricante no vende.
| Dimensión | Copiloto nativo del ERP | Agente que atraviesa sistemas |
|---|---|---|
| Unidad de trabajo | La pantalla / la sesión | El proceso de punta a punta |
| Qué datos ve | Los que están dentro del ERP | ERP + correo + documentos + mensajería |
| Con qué permisos actúa | Los del usuario que lo invoca | Identidad propia, acotada a su tarea |
| Cuándo arranca | Cuando alguien se lo pide | Cuando ocurre el evento, haya alguien o no |
| Quién responde si falla | El fabricante, dentro de su producto | Tú: turno, traza y procedimiento |
El error caro: pagar dos veces por lo mismo
Hay una forma de equivocarse en cada dirección. Una es la que abre este artículo: dar por hecho que con el copiloto incluido ya está todo cubierto, y seguir un año más con tres personas cuadrando documentos a mano. La otra es la contraria y se ve menos: montar por fuera lo que el fabricante ya te da dentro, con lo que acabas pagando dos veces por una conciliación bancaria y manteniendo una integración frágil que el ERP hacía sola.
El orden correcto es el aburrido: primero activas y exprimes lo que ya viene incluido; después mides qué sigue saliendo por la puerta; y solo entonces construyes fuera, y solo ahí. Cuando llegue ese momento, la decisión técnica no es «qué IA compro», sino cómo se tiende el puente hacia los sistemas que ya tienes —API, capa de orquestación o MCP—, que es de lo que va la guía de cómo integrar la IA con tus sistemas sin rehacer nada. Y la segunda decisión, la que más proyectos hunde por llegar tarde, es en qué superficie vive ese agente: dentro del propio ERP, en Teams, en el correo o en WhatsApp, según dónde esté ya la persona que lo va a usar. Esa comparativa está en en qué canal poner un agente de IA.
Qué hacemos nosotros, dicho sin adorno
No vendemos otro ERP ni te pedimos que cambies el que tienes. Montamos encima el trozo de proceso que tu ERP no puede cubrir porque está fuera de él: el documento que llega por correo, la aprobación que alguien tiene que dar desde el móvil, la excepción que aparece a las tres de la mañana. Con nombre concreto según dónde vivas: IA sobre Sage, sobre Business Central, sobre Odoo o sobre Holded. Y cuando el trabajo cruza varios sistemas a la vez, eso es automatización de operaciones en el sentido literal: el proceso entero, no la pantalla.
El resumen cabe en una línea y conviene tenerla clara antes de la próxima reunión con tu partner: el copiloto es una función de tu ERP; el agente es un proceso que atraviesa tu ERP. Confundirlos sale caro en las dos direcciones — o pagas dos veces, o esperas dos años a una versión que no va a llegar, porque lo que necesitas no cabe dentro del producto.