El riesgo no empieza cuando el agente se equivoca. Empieza cuando nadie ha decidido qué le dejamos hacer.
Un asistente que responde mal puede confundir a una persona. Un agente que actualiza el ERP puede comprometer un pedido, cambiar condiciones comerciales o crear un registro incorrecto. La diferencia no está en la calidad del texto: está en la capacidad de ejecutar.
En muchas empresas conviven dos conversaciones sobre inteligencia artificial que rara vez se encuentran. Por un lado, los equipos de innovación hablan de modelos, prompts, agentes y velocidad de desarrollo. Por otro, finanzas, operaciones y tecnología necesitan mantener un control estricto sobre quién aprueba una factura, quién modifica un límite de crédito, quién puede confirmar una compra y cómo se corrige un error. Si no se conectan ambas conversaciones, el piloto impresiona en la demostración y preocupa cuando se propone llevarlo a producción.
El valor de un ERP es preservar un registro coherente de la operación: clientes, precios, contratos, inventario, pedidos, proyectos, contabilidad y trazabilidad. Ese registro contiene reglas que a veces son explícitas —no se puede contabilizar sin determinadas condiciones— y otras son organizativas —por encima de cierto importe debe aprobar dirección financiera—. La IA no elimina estas obligaciones. Les añade una nueva interfaz y nuevos caminos para actuar sobre ellas.
Por eso el enfoque no debería ser «vamos a darle acceso a Business Central al agente y ver qué hace». La pregunta útil es: «¿Qué decisión concreta queremos mejorar, qué datos necesita, con qué grado de autonomía, sobre qué procesos y dentro de qué límites?». El proyecto cambia radicalmente cuando el punto de partida es una decisión empresarial y no un producto de software.
Una recomendación no es una transacción
El agente puede detectar que un proveedor está incumpliendo entregas y sugerir revisar una compra. Eso no equivale a modificar el pedido ni a autorizar una nueva condición. Son derechos diferentes y deben diseñarse por separado.
Acceso al dato no significa derecho a operar
Que el agente pueda consultar una factura no implica que deba poder contabilizarla, cancelarla o alterar la cuenta bancaria del proveedor. La arquitectura debe distinguir lectura, preparación y escritura.
El reto se vuelve más interesante cuando el proceso atraviesa varios sistemas. Una oportunidad nace en el CRM, se convierte en pedido en el ERP, requiere validación financiera, consulta el inventario y termina desencadenando una comunicación al cliente. En ese recorrido, el agente podría aportar valor; también podría multiplicar errores si cada integración considera que su parte funciona sin conocer las reglas del resto. Precisamente por eso la conexión entre ERP, CRM, datos y agentes es una decisión de arquitectura empresarial, no un simple conector.
En Ayesa llevamos esa conversación hacia el ecosistema completo: Dynamics 365 Business Central, otras aplicaciones de Dynamics 365, Power Platform y servicios de IA sobre Azure. El objetivo no es sustituir el gobierno del negocio por una conversación inteligente; es conseguir que la tecnología ejecute trabajo útil conservando los controles que hacen fiable la operación.
El mapa de autonomía: cinco niveles que no deberían confundirse
No todos los agentes necesitan la misma libertad. Aumentar la autonomía solo tiene sentido cuando la organización ha demostrado calidad, permisos, capacidad de recuperación y un beneficio operativo medible.
Una organización puede situar distintos casos en niveles diferentes. Un agente de soporte comercial quizá necesite consultar el estado de un pedido; otro podría preparar un borrador para actualizar la fecha comprometida; uno tercero, en un proceso maduro y de bajo riesgo, podría realizar actualizaciones dentro de parámetros estrictos. Ninguno de esos diseños es intrínsecamente superior: la opción adecuada depende del riesgo y del valor del proceso.
También conviene reconocer que «autónomo» no significa «sin supervisión». Es perfectamente posible establecer límites temporales, presupuestarios, de volumen o de tipo de operación, además de controles técnicos y revisiones periódicas. Una autonomía bien diseñada es delimitada, revocable y observable. Si no podemos explicar cuándo un agente debe detenerse, todavía no hemos definido suficientemente su trabajo.
El agente interpreta y coordina. El ERP sigue siendo el sistema de registro.
El diseño sano evita que el modelo de lenguaje se convierta en una contabilidad paralela o invente estados operativos. Las operaciones deben apoyarse en datos y reglas que viven en las aplicaciones de negocio.
Supongamos que dirección comercial pregunta por el impacto de un retraso de producción en cinco clientes. El agente puede sintetizar el problema, consultar pedidos abiertos, leer fechas previstas y preparar opciones. Pero si necesita modificar una fecha comprometida, activar una expedición o cambiar una condición de pago, ya no estamos ante una pregunta de lenguaje natural. Estamos ante una operación con consecuencias y quizá con permisos, validaciones y dependencias.
La recomendación es separar la capa de interpretación de la capa transaccional. El agente traduce el objetivo a una secuencia de herramientas autorizadas. El ERP decide, mediante sus APIs, reglas y permisos, si la operación es admisible. Los procesos transversales pueden requerir servicios de integración, flujos de aprobación y validaciones adicionales. Ese reparto evita que el agente se convierta en un atajo para saltarse controles.
Fuente oficial
El saldo de un cliente se consulta en el ERP vigente, no en una tabla copiada hace dos días. Los documentos complementarios pueden venir de repositorios autorizados, siempre distinguiendo qué dato es transaccional.
Lógica de negocio
Cálculos de impuestos, contabilizaciones, límites, precios y validaciones deben continuar bajo mecanismos soportados y auditables. El modelo no debería reconstruir reglas delicadas a partir de instrucciones ambiguas.
Responsabilidad
El propietario del proceso decide la autonomía admisible y el área tecnológica implementa controles de identidad, acceso, observabilidad, continuidad y mantenimiento. Ni innovación ni el proveedor de IA sustituyen al responsable funcional.
Evidencia
Cada acción relevante debe poder relacionarse con un objetivo, una identidad, la información consultada, la aprobación correspondiente y el resultado obtenido. Sin esa cadena, investigar una incidencia se convierte en una reconstrucción artesanal.
Para profundizar en las herramientas y las opciones de conexión, consulta Business Central + MCP: agentes conectados al ERP. Aquí el foco es cómo autorizar decisiones y mantener responsabilidades de negocio cuando esa conexión ya existe.
Seis capas entre la intención del usuario y una transacción en el ERP
No existe una arquitectura universal. Pero sí una serie de decisiones que deberían hacerse explícitas antes de autorizar operaciones con impacto económico.
Objetivo y contexto
El agente recibe un trabajo concreto, con propósito, alcance, proceso, límites y condiciones de cierre.
Identidad y autorización
Se comprueba quién solicita la operación, qué permisos existen y si procede usar identidad delegada o propia.
Herramienta gobernada
El agente selecciona una capacidad expuesta mediante API, MCP o flujo controlado, limitada a operaciones permitidas.
Validación del negocio
Se verifican datos, importes, estados, duplicados, umbrales y reglas antes de ejecutar cambios.
Aprobación y ejecución
Cuando corresponde, un responsable confirma la acción; después se ejecuta en el sistema transaccional.
Confirmación y seguimiento
Se registra el resultado real de la operación, errores, identificadores, reintentos y escalado.
En los proyectos pequeños estas capas pueden representarse con pocos componentes. En las organizaciones con varios ERP, filiales y aplicaciones, suelen distribuirse entre plataformas: identidad corporativa, herramientas de integración, conectores, repositorios de conocimiento, registros de actividad y orquestación. Lo importante no es la cantidad de productos utilizados, sino que exista una asignación clara de responsabilidades.
La disponibilidad de Microsoft Foundry y su servicio de agentes permite abordar elementos de ejecución, identidad, herramientas, evaluación y observabilidad. Power Platform y Copilot Studio pueden aportar experiencias y automatizaciones según el escenario, mientras Business Central mantiene sus propias APIs, reglas y permisos. Ninguna de estas piezas, individualmente, garantiza que el proceso final esté bien gobernado. El diseño de permisos y controles funcionales sigue siendo responsabilidad del proyecto.
MCP abre la puerta del ERP. El contrato de seguridad decide qué hay detrás.
En 2026, el servidor MCP de Business Central es una capacidad relevante para conectar agentes y aplicaciones compatibles. Conviene entender exactamente qué facilita y qué no resuelve por sí solo.
MCP, Model Context Protocol, estandariza cómo una aplicación inteligente descubre y utiliza herramientas. En Business Central esas herramientas pueden representar consultas, entidades y acciones soportadas por las APIs configuradas. Esto reduce determinadas integraciones a medida y facilita reutilizar capacidades existentes, especialmente cuando distintos agentes necesitan interactuar con los mismos procesos. No reemplaza las APIs: las expone y organiza para su consumo por clientes compatibles.
La documentación actual de Microsoft indica que la configuración predeterminada permite descubrir y consultar determinadas APIs de solo lectura que el usuario tiene permitido utilizar. Las capacidades para crear, modificar, borrar o ejecutar acciones deben habilitarse y configurarse explícitamente. Esto importa mucho: acceso MCP no es sinónimo de autorización indiscriminada. También se aplican las capacidades de la API y los permisos de la identidad utilizada.
Pensemos en un agente de compras. Para preparar una propuesta podría bastar con leer artículos, disponibilidad, proveedores y pedidos pendientes. Si además debe crear un borrador de pedido de compra, esa operación requiere herramientas de escritura y validaciones propias. Si puede registrar o contabilizar documentos, la criticidad aumenta. Por ello no conviene exponer todo el catálogo de herramientas simplemente porque sea técnicamente posible. El principio práctico es publicar lo imprescindible para cada tarea y revisar periódicamente el acceso efectivo.
Leer y explicar
Ofrecer acceso acotado para consultar datos autorizados, devolver referencias al registro de origen y aclarar la vigencia de la información. Es una fase útil para ganar confianza sin alterar el ERP.
Preparar registros
Construir propuestas o borradores con validación de campos, reglas de negocio, responsabilidades y posibilidades de corrección antes del siguiente paso.
Ejecutar operaciones
Permitir cambios específicos solo después de diseñar permisos, umbrales, aprobaciones, auditoría, idempotencia y recuperación. Una acción irreversible exige un nivel de escrutinio superior.
Extender el estándar
Cuando no existe una API adecuada, valorar capacidades publicadas, consultas soportadas o extensiones. Las opciones preliminares deben evaluarse en entornos no productivos antes de confiarles procesos críticos.
Microsoft ha ampliado las capacidades del servidor MCP de Business Central durante 2026. No todas las funciones están disponibles en cualquier edición, región o configuración, y las herramientas en vista previa no deben asumirse como aptas para producción. Para el detalle técnico conviene consultar la visión general del servidor MCP y su documentación de configuración. En paralelo, nuestra pieza sobre Business Central 29 y consultas MCP profundiza en el acceso a datos para los que todavía no existe una API preparada.
¿Qué debe poder decidir un agente? Una matriz antes que cien prompts
La autonomía no debería concederse por departamento ni por entusiasmo tecnológico. Debe fijarse por tipo de operación, importe, sensibilidad del dato y posibilidad de revertir el resultado.
| Operación | Autonomía sugerida | Control determinante | Riesgo |
|---|---|---|---|
| Consultar stock y estado de pedidos | Lectura autorizada | Registro de consulta | Bajo |
| Detectar facturas duplicadas | Análisis y recomendación | Validación de coincidencias | Bajo–medio |
| Preparar pedido de compra | Borrador sin contabilizar | Revisión del comprador | Medio |
| Modificar fecha comprometida al cliente | Acción condicionada | Regla comercial + aprobación según impacto | Medio–alto |
| Actualizar cuenta bancaria de proveedor | No automatizar sin verificación reforzada | Doble control y canal seguro | Muy alto |
| Contabilizar factura o ejecutar pago | Operación crítica | Aprobación y controles financieros formales | Muy alto |
Esta matriz es orientativa, no una política de autorización universal. Cada organización debe adaptarla a su matriz de segregación de funciones, normativa, control interno y riesgos reales. Aun una tarea aparentemente sencilla puede ser crítica cuando se ejecuta miles de veces o afecta a clientes regulados.
La segregación de funciones —quién crea, quién revisa y quién aprueba— no desaparece porque la operación comience en lenguaje natural. Es especialmente peligroso convertir al agente en una identidad omnipotente que pueda crear proveedores, modificar cuentas de pago y procesar transferencias. La conveniencia aparente de un único perfil técnico se paga con una exposición desproporcionada.
También debemos controlar la autorización sobre el propio contexto. Un agente puede recibir documentos, correos y comentarios redactados por terceras personas. Ese contenido no debería tener capacidad para redefinir sus instrucciones operativas. Si un mensaje de proveedor incluye una frase que pide cambiar la cuenta bancaria o saltarse la aprobación, debe tratarse como información del proceso, nunca como una orden autorizada. Estas situaciones explican por qué hay que diseñar defensas frente a inyección de instrucciones y comprobar parámetros de acción antes de enviarlos al ERP.
Cinco casos de uso donde conectar agentes al ERP puede tener sentido
El mejor primer caso no es el más espectacular. Es aquel donde hay repetición, datos accesibles, excepción reconocible, valor medible y riesgos controlables.
Finanzas · Incidencias en facturas
Un agente reúne documentos, comprueba referencias y propone clasificar facturas discrepantes. Puede detectar duplicados y preparar una lista de revisión, pero la contabilización y el pago se mantienen bajo las aprobaciones corporativas. El valor se mide en tiempo de gestión, incidencias resueltas y errores evitados.
Compras · Retrasos de proveedor
Consulta compromisos, entradas y pedidos pendientes; identifica retrasos que afectan a operaciones y prepara una propuesta de seguimiento. Puede sugerir una compra alternativa, pero el cambio de proveedor o de precio requiere las condiciones de autorización definidas.
Comercial · Pedidos con riesgo
Relaciona pedidos, inventario disponible, entregas y contexto comercial para detectar pedidos que probablemente incumplirán una fecha. Propone una comunicación y un plan de acción, pero no altera compromisos contractuales sin el responsable correspondiente.
Fabricación · Materiales críticos
Cruza necesidades de producción, disponibilidad e incidencias del suministro y destaca excepciones. El agente puede priorizar revisión, mientras planificación y producción mantienen el control sobre órdenes y cambios con impacto físico.
Proyectos · Riesgos de rentabilidad
Consulta desviaciones de costes, hitos de facturación y compromisos. Prepara un informe de causas con referencias al ERP y propone acciones. No reescribe imputaciones ni reconoce ingresos automáticamente por el hecho de haber producido una explicación convincente.
Atención al cliente · Reclamaciones
Relaciona la incidencia con pedido, factura, historial de servicio y política comercial, y propone la respuesta adecuada. Los cambios en saldos, abonos y compromisos se escalan de acuerdo con las reglas de negocio.
Hay un patrón común: el agente reduce el tiempo entre detectar un problema y poner una decisión bien informada delante del responsable. En una segunda etapa puede ejecutar pasos delimitados, siempre que la organización demuestre que el control funciona y que el ahorro no queda anulado por revisiones, incidencias o mantenimiento.
En escenarios con aplicaciones adicionales, el desafío aumenta. Una empresa industrial puede conectar diseño, planificación, pedidos y fabricación; por ejemplo, el contenido sobre integración entre SolidWorks y Business Central ilustra la importancia de que los datos no vivan aislados. En grupos empresariales, operaciones intercompany con Business Central ofrece otro ejemplo de procesos que atraviesan fronteras societarias y requieren especial cuidado con permisos, responsabilidades y conciliación.
Un agente puede ahorrar tiempo y seguir siendo una mala inversión
El retorno no debe medirse por tareas iniciadas ni por respuestas generadas, sino por procesos terminados correctamente, tiempo realmente recuperado y coste total de operación.
Imaginemos una compañía que revisa cada mes 800 incidencias de facturas. El análisis manual consume una media de ocho minutos por incidencia. Su coste interno estimado es de 32 euros por hora. El proyecto propone un agente que recopila contexto y prepara una clasificación, pero todas las decisiones contables sensibles pasan por una persona. Son cifras inventadas únicamente para ilustrar cómo construir el análisis, no resultados reales de un cliente.
En el escenario hipotético, el nuevo flujo reduce el esfuerzo de preparación de ocho a tres minutos por incidencia. Eso supondría aproximadamente 66,7 horas de trabajo liberable al mes, con un valor bruto estimado de 2.133 euros. Pero debemos descontar costes incrementales de inferencia, plataforma, integración, operación, supervisión y retrabajo. Si ese gasto fuera, por ejemplo, 1.150 euros al mes, el beneficio económico operativo estimado sería de 983 euros, siempre que el tiempo realmente pueda aprovecharse. De otro modo estaríamos confundiendo capacidad disponible con ahorro presupuestario.
Con esos supuestos, el coste manual de preparación rondaría 3.413 euros al mes. La preparación asistida supondría 1.280 euros de tiempo humano, más los 1.150 euros incrementales del agente, es decir, unos 2.430 euros. La diferencia estimada sería de aproximadamente 983 euros al mes, coherente con el valor de los cinco minutos ahorrados por incidencia una vez descontado el gasto adicional supuesto. Precisamente por eso un business case debe mantener una única línea base y no mezclar horas brutas liberadas con ahorro realmente aprovechable.
El verdadero análisis debe incluir tasa de automatización útil, fallos, intervenciones, tiempo invertido en corregir propuestas, licencias, infraestructura, conectores y mantenimiento. Si el 25 % de los casos exige retrabajo significativo, una parte del supuesto beneficio desaparece. Y si los responsables no disponen de recursos para mejorar el proceso a partir del tiempo liberado, tampoco es correcto presentar todas esas horas como ahorro en caja.
Hay beneficios cualitativos relevantes —velocidad de respuesta, trazabilidad, reducción de riesgo o mejor servicio—, pero conviene medirlos por separado. La madurez consiste en poder explicar ante dirección qué se ha ganado, cuánto ha costado y bajo qué condiciones puede repetirse.
Siete fallos que deberían probarse antes de conectar agentes a producción
Una respuesta convincente en un entorno controlado no demuestra que el agente sea fiable cuando encuentra datos incompletos, instrucciones maliciosas o un proceso interrumpido.
Instrucciones incrustadas en documentos
Un correo, PDF o comentario recibido del exterior intenta redefinir el trabajo del agente. Hay que separar datos no confiables de instrucciones autorizadas y proteger las llamadas a herramientas.
Permisos demasiado amplios
La identidad conectada puede consultar o modificar más de lo necesario. Deben limitarse alcance, herramientas, entornos, empresas y operaciones.
Acciones repetidas
Un reintento tras perder la conexión genera dos pedidos, dos abonos o dos comunicaciones. Se necesitan controles de idempotencia, referencias y comprobación del estado real.
Confusión entre empresas
El agente actúa sobre la sociedad, país o entorno equivocado. Es necesario validar empresa, tenant, parámetros operativos y contexto en cada acción.
Datos incompletos o desactualizados
El agente interpreta una fotografía antigua como la situación vigente. Las transacciones críticas requieren consultas actualizadas y evidencia verificable.
Aprobaciones decorativas
El usuario acepta sin información suficiente o se le presenta una acción diferente de la que finalmente se ejecuta. La aprobación debe describir y vincular los parámetros reales.
Fallo sin recuperación
El proceso queda a medias, pero el agente anuncia que todo ha salido bien. Debe existir confirmación transaccional, registro de errores, compensación cuando proceda y escalado.
Estos riesgos no implican que debamos renunciar a los agentes. Significan que debemos tratarlos como componentes operativos: probar casos extremos, cambiar condiciones, inyectar datos erróneos de forma controlada, retirar permisos y comprobar qué sucede cuando una dependencia deja de responder. La evaluación de agentes debe incluir calidad de respuesta y comportamiento de ejecución, no solo la exactitud de una conversación.
Los controles de identidad y observabilidad disponibles en Microsoft Foundry Agent Service pueden formar parte de esa arquitectura. Microsoft documenta capacidades de identidad, controles de acceso, telemetría y trazas. Aun así, el equipo de proyecto debe establecer pruebas que respondan a los riesgos de su proceso y no asumir que una plataforma sustituye la validación funcional.
Quién debe sentarse en la mesa antes de autorizar un agente con capacidad de ejecución
La decisión no puede recaer únicamente sobre quien construye el agente. Cuanto más cerca del ERP, más importante es que el propietario del proceso tenga voz y responsabilidad.
Responsable de negocio
Define el resultado, la decisión admisible, la criticidad del proceso, los criterios de aceptación y las situaciones en que el agente debe detenerse. Aprueba cambios que afecten a políticas y controles operativos.
Dirección de sistemas
Valida arquitectura, integraciones, calidad y gobernanza del dato, continuidad y operación. Decide si conviene exponer APIs existentes, flujos o servicios específicos y cómo mantenerlos.
Seguridad y cumplimiento
Revisa identidad, permisos, accesos, segregación de funciones, protección de información, auditoría y obligaciones regulatorias. Verifica que los controles son demostrables.
Equipo de datos e IA
Diseña herramientas, instrucciones, evaluaciones, observabilidad y límites de los agentes. Registra cambios de versiones y comprueba errores o comportamientos inesperados.
Es útil asignar una persona propietaria al agente, una al proceso y una responsable de la continuidad técnica. Esos roles pueden coincidir en iniciativas pequeñas, pero deben quedar explícitos. Si el agente empieza a operar sin una organización capaz de decidir qué hacer cuando falla, el problema no se resuelve incorporando otra plataforma.
También es necesario pensar en el ciclo de vida: alta, validación, pruebas, despliegue, cambios, revisión de permisos, seguimiento de costes y retirada. Un agente que hace seis meses cumplía correctamente su función puede quedar desalineado si cambian los procesos, las APIs, los roles o la normativa. Por eso un inventario y revisiones programadas son tan importantes como la primera puesta en marcha.
De la idea a un agente conectado al ERP: un itinerario de seis decisiones
No propongo una implantación exprés con fecha universal. Propongo un orden de trabajo que reduzca riesgo y evite construir sobre una oportunidad mal definida.
Elegir una decisión medible
Identifica volumen, coste de preparación, errores frecuentes y responsables. Descarta los casos que tienen poca repetición o datos inconexos sin posibilidad razonable de mejora.
Auditar dato y reglas
Comprueba dónde viven las fuentes, qué permisos existen, cómo se interpretan los estados y qué reglas bloquean una operación. Si el ERP no tiene datos fiables, el agente no los inventará.
Definir autonomía y límites
Dibuja quién consulta, quién recomienda, quién aprueba y quién ejecuta. Establece acciones prohibidas, condiciones de detención, umbrales y responsabilidad sobre cada cambio.
Construir una versión acotada
Comienza por lectura y propuesta, utilizando herramientas soportadas. Prueba con datos realistas y casos de error. Evita desplegar acceso amplio solo porque la demostración lo permite.
Medir contra una línea base
Compara tiempos, coste por caso terminado, errores, reintentos, calidad y porcentaje de intervención. El valor debe medirse sobre el proceso completo, no solamente sobre el trabajo del agente.
Escalar solo con evidencia
Amplía operaciones autorizadas, usuarios o aplicaciones si los resultados sostienen la decisión. Refuerza soporte, documentación, observabilidad, versionado y revisión de permisos antes de añadir autonomía.
Si la necesidad consiste principalmente en consultar conocimiento, quizá baste con una solución conversacional con recuperación autorizada de información. Si la necesidad es ejecutar una operación repetitiva con reglas deterministas, puede que Power Automate o una integración convencional sean más adecuados y económicos. Y si el proceso necesita combinar razonamiento, datos cambiantes y herramientas autorizadas, un agente puede justificar su complejidad. La elección correcta no es la más novedosa, sino la que entrega el resultado con menor riesgo y coste total razonable.
¿Copilot Studio, Microsoft Foundry o una automatización convencional?
No conviene decidir la herramienta antes de conocer el tipo de tarea, los sistemas implicados y el control requerido. Estas opciones pueden complementarse, no representan una carrera con un ganador único.
Copilot Studio y Power Platform
Útiles cuando se quiere diseñar experiencias y acciones empresariales dentro de un ecosistema low-code, con conectores y procesos gobernados. Hay que evaluar límites funcionales, permisos, coste de ejecución y cómo se conectan las herramientas a cada sistema.
Microsoft Foundry Agent Service
Interesante cuando se requiere una arquitectura más especializada, orquestación, integración con herramientas propias, evaluación, control de identidades y operación de agentes en un contexto de desarrollo y Azure. Supone responsabilidades de ingeniería y operación.
Integración o automatización clásica
Puede resolver muy bien tareas deterministas: validar registros, mover datos, activar avisos y aplicar reglas sin intervención del lenguaje natural. Menos capacidad de interpretación no implica menor valor de negocio.
Estrategia combinada
Un agente puede interpretar una excepción y pedir a un flujo determinista que ejecute una acción comprobada. El ERP conserva el control transaccional, y los servicios de integración controlan la coordinación.
El recorrido estratégico se entiende mejor a partir del contenido De Copilot a los agentes de IA: el trabajo empresarial empieza a cambiar, que plantea el salto del asistente al modelo operativo. Para la arquitectura completa, consulta nuestro hub Azure + IA empresarial y la página de agentes de IA en Azure. Para la conexión específica con el sistema de gestión, el contenido Business Central y MCP aborda esa capa con mayor profundidad.
Lo que diferencia el trabajo de integración de Ayesa no es elegir una etiqueta nueva, sino conectar la propuesta con lo que una empresa ya utiliza: ERP, CRM, seguridad, Microsoft 365, plataformas de datos y sistemas sectoriales. Una aplicación de IA aislada puede parecer sofisticada y, sin embargo, fracasar porque no entiende el proceso completo. La ventaja aparece cuando la solución conoce las dependencias, conserva la responsabilidad y demuestra impacto en una operación real.
Quince preguntas que un CIO y un CFO deberían hacer antes del primer despliegue
La calidad del diseño puede evaluarse sin conocer todos los detalles de la plataforma. Basta con exigir respuestas claras sobre el proceso, la autonomía, el riesgo y el valor.
Si hoy no se pueden responder varias de estas preguntas, no significa que la compañía esté lejos de utilizar agentes. Significa que hay trabajo de descubrimiento útil antes de desarrollar. Ese trabajo es más barato que corregir después permisos mal definidos, operaciones duplicadas o una integración que nadie sabe mantener.
Las dudas que aparecen cuando el proyecto deja de ser una demostración
¿Puede un agente de IA modificar datos de Business Central?
Sí, si la herramienta, la configuración del servidor y los permisos de la identidad lo permiten. No ocurre por el mero hecho de conectar MCP. La configuración por defecto contempla capacidades de lectura; las operaciones de creación, modificación, eliminación o acciones requieren habilitación y controles adecuados.
¿MCP sustituye a una API o a Power Automate?
No. MCP permite descubrir y utilizar herramientas; muchas se apoyan en APIs existentes. Una automatización convencional puede seguir siendo la mejor forma de ejecutar reglas deterministas y los flujos pueden participar en la arquitectura de un agente.
¿La IA puede aprobar una factura sin intervención humana?
Técnicamente pueden diseñarse operaciones automáticas en determinados contextos, pero no deberían implementarse sin evaluar la segregación de funciones, reglas financieras y nivel de riesgo. Para pagos y operaciones sensibles son recomendables controles reforzados y autorizaciones formales.
¿Cómo sabe el agente qué empresa o sociedad debe utilizar?
El contexto de tenant, entorno, empresa y usuario debe venir de la arquitectura autorizada y validarse antes de ejecutar. No conviene confiar únicamente en lo que aparece escrito en una conversación, especialmente en organizaciones multiempresa.
¿Qué diferencia hay entre un agente y una automatización?
Una automatización suele seguir reglas y pasos bien definidos; un agente puede interpretar objetivos y utilizar herramientas en función del contexto. Cuando el proceso es completamente predecible, añadir un agente no necesariamente mejora coste o fiabilidad.
¿Puedo conectar también CRM, documentos y datos de Fabric?
Puede tener sentido si el caso de uso requiere contexto de varias aplicaciones. La integración exige definir fuentes autorizadas, permisos, fiabilidad, trazabilidad y cuál de los sistemas conserva la autoridad para cada tipo de dato.
¿Cómo calculamos el retorno de un agente conectado al ERP?
Midiendo coste por caso terminado, tiempo humano liberado y aprovechado, tasa de error, intervenciones, incidencias y gasto total de licencias, modelos, integraciones y operación. La calidad y el control de riesgos deben medirse junto al ahorro.
¿Por dónde empezaría Ayesa?
Por una sesión para identificar una tarea concreta, mapear los datos y sistemas implicados, definir una escala de autonomía y estimar impacto y riesgos. Después tendría sentido contrastar la tecnología con un piloto acotado y métricas claras.
El estado de disponibilidad de funciones y sus condiciones de licencia puede cambiar. Para un proyecto real deben revisarse la documentación y las condiciones vigentes del entorno específico, especialmente en características preliminares o con restricciones de región.
Para profundizar sin mezclar niveles de decisión
Las siguientes referencias permiten pasar de la visión ejecutiva a la implementación técnica. Cada una responde a una pregunta distinta; juntas ayudan a construir un campo temático coherente y útil para decidir.
Azure + IA empresarial
Arquitectura de agentes, datos, modelos, seguridad, integración y operación.
Microsoft Foundry
Servicio y plataforma para construir y operar agentes empresariales.
Business Central + MCP
Cómo exponer herramientas del ERP a clientes y agentes compatibles.
De Copilot a agentes de IA
Cambio del trabajo empresarial desde asistencia hacia ejecución.
Referencias técnicas oficiales
- Microsoft Learn: visión general de MCP en Business Central
- Microsoft Learn: configuración y permisos del servidor MCP
- Microsoft Learn: Microsoft Foundry Agent Service
- Microsoft Learn: identidad de agentes en Foundry
- Microsoft Learn: mejoras MCP en Business Central, 2026
Actualización editorial: octubre de 2026. Los ejemplos operativos, los escenarios económicos y las matrices de responsabilidad son ilustrativos; no se presentan como implantaciones de clientes ni como garantías de funcionalidad o ahorro.
La pregunta no es cuánto puede hacer un agente. Es cuánto trabajo le confiarías con tranquilidad.
Si tu organización trabaja con Business Central, Dynamics 365 u otros sistemas conectados, podemos explorar qué decisiones conviene asistir, cuáles automatizar y qué controles deben estar presentes antes de pasar de una prueba a producción.
Una primera conversación permitirá situar el proceso, los sistemas implicados, los puntos de fricción, el nivel de autonomía admisible y las preguntas que conviene resolver antes de elegir plataforma. No es necesario llegar con una tecnología cerrada: es más útil llegar con un problema real.
Escenario
Qué tarea merece la pena transformar
Integración
Qué ERP, CRM y datos deben participar
Gobierno
Quién autoriza y cómo se audita
Valor
Qué resultado y coste vamos a medir
Evaluemos un primer caso de agentes conectados al ERP
Comparte tu contexto y abrimos una conversación técnica y de negocio para identificar posibilidades, dependencias y próximos pasos.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)