MCP en empresas: qué revisar antes de conectar IA y herramientas
Por Carlos Isidoro De Ayala Diaz ·
MCP en empresas: cómo conectar asistentes de IA con herramientas internas, limitar permisos, aprobar acciones, registrar llamadas y preparar la retirada.
Empieza por la tarea, los datos y la acción permitida
Model Context Protocol, o MCP, permite que una aplicación de inteligencia artificial descubra y utilice recursos o herramientas mediante una interfaz común. Puede servir para consultar documentación, buscar un pedido o iniciar una operación en otro sistema. El protocolo facilita la conexión, pero no decide qué datos debe ver un usuario, qué acción resulta adecuada ni quién asume el resultado. Antes de instalar un servidor o aceptar un conector, la empresa debe describir una tarea concreta y el límite que no debe cruzar.
Un caso de uso se puede expresar como una secuencia observable: una persona autorizada consulta el estado de un pedido, el asistente llama a una herramienta de lectura y muestra la fuente utilizada. Si además puede cambiar la dirección o cancelar el pedido, ya existe una capacidad de escritura con otro impacto. Separar consulta, propuesta y ejecución evita conceder permisos de modificación para resolver una pregunta. También permite medir precisión, tiempo y errores frente al proceso actual antes de ampliar el alcance.
El inventario inicial recoge cliente MCP, servidores, herramientas, recursos, prompts, sistemas finales, identidades, datos y responsable. También identifica si la conexión se ejecuta en el equipo del usuario o a través de un servicio remoto. Una herramienta con un nombre amable puede ocultar una API con privilegios amplios; la revisión debe llegar hasta la cuenta y los permisos que utiliza en el ERP, el repositorio o la base de datos. La descripción que recibe el modelo no sustituye ese análisis.
La versión del protocolo y del SDK forma parte del alcance. La especificación MCP de 28 de julio de 2026 introduce un núcleo sin sesión, peticiones autodescriptivas, cabeceras para método y herramienta y cambios de autorización. También depreca mecanismos anteriores con un periodo de transición. Un prototipo que funciona con una revisión no demuestra compatibilidad con otra. Cliente, servidor y extensiones deben declarar qué versión soportan, cómo se prueban las actualizaciones y quién decide adoptarlas.
Reduce herramientas, funciones y parámetros antes de conectarlos al modelo
El catálogo de herramientas debe contener solo las funciones necesarias para el caso aprobado. Un asistente que resume correos necesita lectura; incluir envío, borrado y administración multiplica el daño posible ante un error o una instrucción manipulada. OWASP describe este patrón como agencia excesiva y lo relaciona con funcionalidad, permisos o autonomía innecesarios. La medida más eficaz comienza en el diseño: no ofrecer al modelo una capacidad que el proceso no necesita.
Las funciones deben ser específicas. Una herramienta como consultarPedido con identificador, empresa autorizada y campos limitados tiene una superficie más controlable que ejecutarConsulta o llamarURL con entradas abiertas. Los parámetros se validan con tipos, formatos, longitudes y listas permitidas, y la aplicación comprueba las reglas de negocio. El texto generado por el modelo se trata como una propuesta no confiable; no se convierte directamente en SQL, comandos, rutas o destinatarios sin una capa determinista que lo limite.
Los resultados de recursos y herramientas tampoco son instrucciones de confianza. Un documento, un correo o la respuesta de otro servicio puede contener texto diseñado para desviar al asistente, solicitar secretos o inducir otra llamada. El cliente debe mantener separadas las reglas de la aplicación, los datos recuperados y las decisiones de autorización. Si una herramienta devuelve contenido, ese contenido no gana permiso para invocar otras funciones. Las cadenas de llamadas se prueban porque una acción inocua aislada puede adquirir impacto al combinarse con otra.
Cada herramienta necesita condiciones de éxito y error. Se documentan efectos secundarios, operaciones idempotentes, límites de volumen, coste y tiempo máximo. Una respuesta ambigua no debe provocar reintentos que dupliquen facturas, mensajes o pedidos. Para acciones de escritura se puede usar una fase de preparación que devuelva un resumen y otra de confirmación que ejecute con un identificador inequívoco. La confirmación muestra al usuario datos concretos, no una pregunta genérica que pueda aceptarse sin entender el efecto.
Conserva identidad, autorización y aprobación en cada llamada
El modelo no debe decidir si una persona tiene permiso. El servidor y el sistema final validan identidad, empresa, rol, objeto y operación en cada petición. Si el asistente actúa para un usuario, la llamada debe conservar ese contexto con el alcance mínimo, evitando una cuenta compartida con acceso a todos los clientes. OWASP recomienda ejecutar las extensiones en el contexto del usuario y aplicar la autorización en los sistemas posteriores, donde no puede eludirse cambiando una instrucción.
En conexiones remotas, OAuth y la configuración del proveedor de identidad requieren una revisión propia. La especificación de julio de 2026 refuerza la validación del emisor de autorización y vincula credenciales con el servidor que las emitió. Estos cambios reducen ciertos errores de mezcla entre servidores, pero no sustituyen la selección de scopes ni el control de las API finales. Los tokens no se incluyen en prompts, registros abiertos, URL o mensajes de error, y se define cómo caducan, se renuevan y se revocan.
Las acciones de impacto necesitan una aprobación proporcional. Leer una ficha pública, preparar un borrador y enviar una comunicación no comparten el mismo riesgo. La interfaz debe indicar qué herramienta se usará, sobre qué objeto y con qué consecuencia antes de pedir confirmación. Para transferencias, borrados, cambios de permisos o publicaciones puede requerirse una persona con un rol distinto. La aprobación humana ayuda cuando es informada y verificable; no compensa una herramienta con permisos generales o parámetros sin restricciones.
También se preparan altas y bajas. La empresa necesita saber quién autorizó cada servidor, qué usuarios lo tienen disponible y qué ocurre cuando alguien cambia de puesto o termina su relación. Revocar el acceso del cliente no basta si quedan credenciales activas en el servidor o en el sistema conectado. Una prueba de baja verifica que desaparecen sesiones, tokens, claves y permisos posteriores. Las cuentas de servicio tienen propietario, finalidad y fecha de revisión, sin quedar ligadas a la cuenta personal de quien hizo el prototipo.
Prueba, observa y prepara la retirada antes de pasar a producción
El piloto se ejecuta con datos sintéticos o un entorno controlado y preguntas representativas. Incluye instrucciones normales, solicitudes ambiguas, intentos de saltar permisos, contenido recuperado con órdenes maliciosas, errores del sistema final y acciones que requieren confirmación. Se comprueba no solo la respuesta del modelo, sino la herramienta seleccionada, los parámetros, la identidad, la decisión del control y el efecto real. NIST AI 600-1 propone gestionar riesgos generativos durante el ciclo de vida y prestar atención a la integración de componentes y proveedores.
La observabilidad debe reconstruir una operación sin registrar secretos ni conversaciones completas por defecto. Conviene conservar usuario o identidad técnica, herramienta, versión, parámetros depurados, resultado, sistema final, duración, aprobación y correlación entre llamadas. Los métodos y nombres incluidos en las cabeceras de la revisión MCP de julio de 2026 facilitan aplicar rutas, límites y métricas en una pasarela HTTP, pero el contenido sensible sigue necesitando filtrado. Las alertas se vinculan a alguien que pueda investigar y revocar.
El despliegue gradual limita usuarios, herramientas y volumen. Se establecen topes de coste, frecuencia y concurrencia, además de un interruptor para desactivar una función sin retirar todo el asistente. Las actualizaciones del servidor, SDK o definición de una herramienta pasan por inventario, revisión y pruebas porque pueden cambiar permisos, parámetros o resultados. También se revisa la procedencia del código y de las dependencias. El registro de INCIBE o una certificación técnica del equipo no convierten un componente de terceros en confiable sin esta comprobación.
Élite Solutions Tech puede preparar desde Murcia un prototipo MCP para empresas regionales o proyectos nacionales, conectando IA con sistemas mediante un alcance y una evaluación definidos. La propuesta concreta casos de uso, herramientas, identidades, proveedores, datos, aprobaciones, pruebas, registros, costes recurrentes y mantenimiento. También incluye cómo retirar la conexión y volver al proceso anterior. Para una primera reunión basta indicar la tarea, el sistema implicado y la acción que nunca debería ejecutarse sin aprobación; los accesos se coordinan después por un canal autorizado.