La evolución de la IA generativa en las empresas puede entenderse como un cambio progresivo en la relación entre los modelos de lenguaje y los sistemas corporativos. Primero llegaron los asistentes capaces de responder preguntas a partir de su conocimiento general. Después, las arquitecturas RAG permitieron conectar los modelos con documentación y bases de conocimiento internas para generar respuestas basadas en información propia. El siguiente paso es hacer que la IA no solo consulte información, sino que pueda ejecutar acciones.
Un agente puede consultar un pedido, actualizar un CRM, crear una incidencia o iniciar una aprobación. El modelo deja así de ser una interfaz de consulta y pasa a interactuar con los sistemas corporativos.
Para hacer posible esta transición, es necesario combinar dos elementos. Por un lado, un mecanismo estandarizado que permita a las aplicaciones de IA acceder y utilizar herramientas externas; por otro, una capa que conecte esas herramientas con los procesos y las APIs de las empresas. Nuestro Máster Online en IA Generativa y Automatización, aborda esta evolución con contenidos sobre agentes, automatización de procesos, herramientas no-code/low-code y MCP.
En este contexto entran en juego Model Context Protocol (MCP) y plataformas de automatización como Make. Mientras MCP proporciona un estándar para conectar aplicaciones de IA con herramientas externas, Make puede actuar como capa de ejecución y orquestación, conectando esas capacidades con las APIs y procesos que ya forman parte de la infraestructura empresarial.
MCP: un estándar para conectar modelos con herramientas
Model Context Protocol aborda la capa de interoperabilidad. Es un protocolo abierto que estandariza cómo las aplicaciones de IA pueden conectarse con servidores que proporcionan herramientas, recursos y prompts. En lugar de que cada aplicación tenga que definir su propia forma de descubrir y utilizar capacidades externas, MCP establece una interfaz común.
La arquitectura distingue entre el host, que es la aplicación de IA; el cliente MCP, que mantiene la conexión; y el servidor MCP, que expone las capacidades disponibles. Entre ellas están las tools, que permiten realizar acciones.
Es importante, sin embargo, no confundir interoperabilidad con seguridad. MCP no es una API de negocio ni una solución de seguridad por sí mismo. La autenticación, autorización, validación de parámetros y políticas de ejecución dependen de la arquitectura que se construya alrededor del protocolo.
De la herramienta al proceso: dónde encaja Make
MCP resuelve cómo una IA puede descubrir y utilizar una herramienta. Pero queda otra cuestión: ¿qué ocurre cuando esa herramienta tiene que ejecutar un proceso que atraviesa varios sistemas empresariales?
Aquí una plataforma de automatización como Make permite orquestar el proceso que hay detrás, conectando aplicaciones y APIs mediante módulos, peticiones HTTP, transformaciones, condiciones y diferentes rutas de ejecución. La diferencia está en que el agente no tiene que gestionar directamente cada una de estas conexiones: puede invocar una capacidad y dejar que el escenario se encargue de los pasos necesarios para ejecutarla.
Además, Make dispone de un MCP Server propio, que permite a sistemas de IA compatibles con MCP ejecutar escenarios de Make y acceder a las capacidades que la organización decida exponer. También cuenta con un MCP Client para conectar escenarios con herramientas ofrecidas por servidores MCP externos.
Esto permite que un escenario de Make represente una acción de negocio concreta. El agente no necesita conocer el endpoint del ERP ni los detalles de autenticación. Esa complejidad puede quedar encapsulada en el escenario de Make, que, valida los datos, realiza la petición correspondiente, procesa la respuesta y puede desencadenar otras acciones, como enviar una notificación.
Así, Make no actúa únicamente como un conector entre sistemas. Puede convertirse en la capa de ejecución que traduce una acción solicitada por el agente en un proceso empresarial completo.
Dar autonomía a la IA sin perder el control
La parte más delicada de esta arquitectura no es conectar el modelo con una API, sino decidir qué puede hacer el agente, con qué permisos y bajo qué condiciones.
Un LLM puede generar una llamada formalmente correcta y, aun así, tomar una decisión equivocada. También puede verse condicionado por un prompt injection, especialmente cuando procesa información procedente de fuentes externas. La organización especializada en ciberseguridad OWASP identifica la Prompt Injection entre los principales riesgos de las aplicaciones basadas en LLM y señala que puede alterar el comportamiento del modelo y provocar acciones no previstas.
Existe además un riesgo directamente relacionado con la IA agéntica conocido como Excessive Agency, que aparece cuando se conceden al agente demasiadas funciones, permisos o autonomía. Por eso, MCP no debería interpretarse como un mecanismo para entregar las llaves de los sistemas corporativos al agente. La arquitectura necesita controles adicionales.
Validación antes de ejecutar
Los parámetros recibidos del agente deben validarse como cualquier otra entrada externa. Si una herramienta espera un identificador concreto o un estado perteneciente a un conjunto cerrado, esos requisitos deben comprobarse antes de llegar al sistema de destino.
Aquí la capa de automatización puede desempeñar un papel importante. Un escenario de Make puede establecer condiciones sobre los datos recibidos, comprobar que se cumplen determinados requisitos y detener el flujo si una operación no debe continuar.
También conviene distinguir entre acciones reversibles y críticas. Consultar el estado de un pedido no tiene el mismo nivel de riesgo que cancelar una operación financiera, modificar datos sensibles o eliminar información.
La propia herramienta y el flujo que la ejecuta deben imponer límites técnicos a lo que puede hacerse, en lugar de confiar únicamente en que el modelo interprete correctamente la petición.
Trazabilidad y supervisión
Cada ejecución debería dejar evidencia suficiente para reconstruir qué ocurrió: qué herramienta se invocó, con qué parámetros, qué sistemas fueron consultados o modificados y cuál fue el resultado.
La capa de automatización puede contribuir a esta trazabilidad registrando las ejecuciones del flujo y permitiendo identificar los diferentes pasos que se han producido dentro de un proceso.
Para operaciones sensibles, además, el agente puede no tener la última palabra. Un patrón Human-in-the-Loop permite detener el flujo antes de una acción irreversible y solicitar la aprobación de una persona. Por ejemplo, un agente podría preparar una operación financiera y activar un paso de aprobación antes de ejecutar la llamada definitiva a la API. Así, la automatización no implica necesariamente autonomía total.
Del chatbot al sistema que actúa
La combinación de MCP y plataformas de automatización como Make apunta a un cambio relevante en la construcción de sistemas de IA empresariales.
El objetivo ya no es crear únicamente un chatbot que responda mejor, sino agentes capaces de interactuar con el software que ya utiliza una organización. MCP proporciona un mecanismo común para descubrir y utilizar herramientas; Make puede encargarse de convertir esas capacidades en procesos conectados con aplicaciones y APIs; y las capas de seguridad y gobierno determinan hasta dónde puede llegar cada agente.
Esta arquitectura no elimina la complejidad. La desplaza hacia cuestiones más importantes: ¿qué herramientas debe tener cada agente? ¿Qué permisos necesita? ¿Qué acciones requieren aprobación? ¿Cómo se registran sus ejecuciones? ¿Qué ocurre cuando una API falla o el modelo interpreta incorrectamente una petición?
Responder a estas preguntas es lo que diferencia una demostración de IA agéntica de una arquitectura preparada para producción.
