Su IA ya tiene integraciones que nadie cotizó ni aprobó

La escena

Un ingeniero del equipo conecta un servidor MCP al asistente para que pueda consultar el ERP. Tarda veinte minutos, funciona, y resuelve una molestia real: ya no hay que copiar y pegar números entre pantallas.

Dos meses después, ese servidor es uno entre más de veinte. Nadie sabe cuántos hay, en qué máquina corre cada uno, qué expone, ni quién lo autorizó. Es lo que pasa cuando una capacidad útil se adopta más rápido de lo que dura un ciclo de gobierno.

Eso es lo que cambió en el último año. La IA dejó de ser una aplicación que responde preguntas y se volvió una capa de integración, con sus propios servidores, dominios, tokens y permisos. Y esa capa se está desplegando sin dueño, en organizaciones que sí tienen inventario de su ERP, su CRM y hasta de sus impresoras de red.

Inventario: cuántos hay y quién los autorizó

Hay un dato que conviene leer con cuidado. Ox Security publicó el 7 de octubre de 2026 un análisis de 15.465 servidores MCP repartidos en 5.095 dominios únicos, tomados de tres registros públicos. El título del informe es la tesis: 15.465 servidores MCP. Cero gobernanza.

Es una muestra de lo que está publicado, no del interior de una empresa. Pero el título describe algo que un director de TI reconoce al instante: la capa existe, y el gobierno de esa capa no.

La analogía más exacta es la de las integraciones punto a punto. Durante años, cada equipo conectó lo que necesitaba como pudo: un script, un conector, una consulta directa. Funcionaba. El problema llegó cuando hubo que saber qué estaba conectado con qué. MCP reproduce ese patrón, pero mucho más rápido, porque instalar un servidor toma minutos y no requiere pasar por infraestructura.

La acción de esta semana es simple y no requiere presupuesto: pedir el conteo. Cuántos servidores MCP existen, quién los instaló, en qué entorno corren y qué herramienta expone cada uno. Si la respuesta tarda más de un día, el hallazgo ya está hecho.

Ubicación: dónde corre y quién lo controla después

El informe de Ox señala que 15.6% de esos dominios resuelven a infraestructura fuera de Estados Unidos, incluida China y Rusia.

Vale una precisión que el propio dato exige: eso describe dónde corre el servidor, no cuántos están comprometidos. Es una cifra de ubicación, y aun así importa, porque el servidor MCP está en el camino de los datos: si un asistente consulta el ERP a través de él, el resultado de esa consulta pasa por esa infraestructura.

El segundo hallazgo es el que suele sorprender a un director de TI. 2.3% de los dominios ya no resuelven, y seis de ellos estaban sin registrar, disponibles por unos cuatro dólares al año. Traducido a operación: si el cliente sigue llamando a un dominio abandonado y alguien lo recompra, las llamadas de su agente llegan a un tercero. Basta con que nadie revise la lista.

El propio informe lo dice sin rodeos: el protocolo no tiene un mecanismo nativo para exigir dónde corren las herramientas conectadas ni dónde se procesan los datos. La ubicación no se puede imponer desde el protocolo. Se decide en la configuración, y la configuración necesita dueño.

El calendario de ciclo de vida es igual de básico: qué servidores están activos, cuáles se abandonaron y cuáles siguen recibiendo llamadas aunque su dueño ya no trabaje en la empresa.

Permiso: qué autorizó y qué evidencia queda

El tercer problema es el que más se parece a lo que su equipo ya vive con las integraciones clásicas.

Ox documentó una prueba concreta. Con un modelo determinado, un servidor MCP pidió permiso para leer un archivo inocuo. El usuario concedió "siempre permitir", y a partir de ahí el servidor accedió a un archivo de configuración sensible sin una nueva confirmación. El mismo intento no funcionó con los modelos más recientes.

Es importante no leer eso como "un modelo es seguro y otro no". El hallazgo es sobre diseño de permisos: una autorización otorgada una vez quedó vigente para todo lo que vino después. Cuando el permiso se concede a nivel de servidor, cualquier herramienta que ese servidor exponga hereda el mismo acceso. La respuesta de Anthropic recogida por Infosecurity Magazine apunta en la misma dirección: una vez otorgado el "siempre permitir", ese es el comportamiento documentado, y la detección de contenido malicioso a nivel del modelo es una heurística, no una frontera de seguridad.

De ahí salen dos reglas que sirven como criterio de diseño:

Gobernar por herramienta, no por servidor. Que un agente pueda acceder a un servidor no significa que deba poder invocar cada una de sus herramientas. Un servidor que expone consulta de inventario y también escritura de pedidos no debería entregar ambos permisos en un solo acto.

No pasar el token del usuario al sistema de aguas abajo. Cuando el token humano se reenvía hacia el ERP o el CRM, se pierde la trazabilidad: el sistema interno registra a una persona, no la acción de un agente. Cada servidor con su propia credencial, y cada llamada atada a un usuario y a una decisión de política, es la única forma de reconstruir después qué pasó.

La evidencia es la parte que casi nadie tiene. Si mañana un auditor pregunta qué datos consultó un agente y bajo qué autorización, la respuesta no puede ser "está en el log del servidor que alguien instaló en su laptop". Ahí es donde la capa de integración de IA coincide exactamente con la capa de integración clásica: sin registro, no hay evidencia; sin evidencia, no hay gobierno.

La factura que llega dos años después

Hay un dato de contexto que ayuda a dimensionar esto. Una encuesta de Stacklok a 520 líderes técnicos de empresas grandes de Norteamérica, publicada en octubre de 2026, encontró que 53% considera que las integraciones a sistemas internos o servidores MCP serían lo más difícil de mover si tuviera que cambiar de modelo. Y 81% ya retrasó, redujo o reestructuró una migración de modelo por los costos de cambio.

Son cifras de esa encuesta, en esa muestra, no del mercado en general ni de la región. Pero describen una mecánica reconocible: la capa de integración es lo que ata, mucho más que el modelo. Cambiar de modelo es fácil. Cambiar veinte servidores, sus permisos y sus registros es un proyecto.

Ese es el costo que aparece dos años después de la decisión que se toma hoy sin inventario.

Tres acciones de una semana

No hace falta un programa corporativo para empezar a ordenar esto.

Inventario: la lista de servidores, con dueño y entorno. Si cada servidor tiene una herramienta distinta expuesta, anótelo en la misma línea.

Ubicación: para cada servidor, dónde corre y si su dominio sigue resolviendo. Un dominio abandonado que alguien más puede comprar es un riesgo cerrado en diez minutos.

Permiso: revisar qué se autorizó con "siempre permitir", y si esa autorización cubre más de lo que alguien aprobó conscientemente.

Nada de esto exige una herramienta nueva. Exige la misma disciplina que Byxel aplica a integraciones bajo su modelo de Ingeniería de Autor: cada conexión con dueño, con alcance mínimo y con evidencia.

Para seguir leyendo: los permisos de sus agentes de IA, el costo de mantener integraciones conectadas a mano y la deuda de integración como pasivo que crece.

La decisión de hoy no es si adoptar esta capa. Ya está adoptada. La decisión es si va a tener dueño antes o después de la primera factura.

Si su equipo ya conectó un asistente al ERP o al CRM y nadie tiene el inventario de esos servidores, vale la pena una conversación de 30 minutos. En Byxel hacemos integraciones entre sistemas que no se hablan: la primera puede ser la de su IA con su propio back office. Escribanos por WhatsApp.