ServiceNow en la era de la IA agéntica: AI Control Tower, AI Agent Fabric y el nuevo moat de la ejecución gobernada

Durante más de dos décadas, el software empresarial se ha vendido por asiento. Cuánta gente entra. Cuántos módulos adopta. En cuántos asientos creces el año que viene. El valor de una plataforma SaaS iba, más o menos, ligado al número de humanos que la usaban.

Los agentes rompen eso. Un agente puede consultar datos, resumirlos, abrir un ticket, llamar a una API, hablar con otro agente y cerrar un workflow. Sin login. Sin pantalla. Sin clic. Así que el miedo es razonable. Si el humano deja de tocar la interfaz, el modelo por asiento empieza a hacer agua.

Creo que ese miedo es real, pero incompleto. Un agente no trabaja en el vacío. Para hacer algo útil dentro de una empresa grande necesita contexto, identidad, permisos, reglas de negocio, acceso seguro a los datos, una traza de auditoría y alguien que lo gobierne y lo pague.

Y aquí está la parte a la que no dejo de volver. Casi nada de eso sale del modelo. Casi todo vive en las plataformas que los agentes, supuestamente, van a sustituir.

ServiceNow está justo encima de esa tensión. AI Control Tower y AI Agent Fabric son sus dos apuestas. Una es el plano donde inventarías, gobiernas y cobras por los agentes. La otra es el tejido por el que hablan los agentes internos y externos.

No tengo claro que lo consigan. Pero creo que el relato pesimista —el SaaS ha muerto, y ServiceNow con él— se queda corto. El resto del artículo es mi intento de explicar por qué.

La adopción de IA en empresas grandes casi nunca es ordenada. Cada equipo compra herramientas distintas. Conectan modelos externos, levantan sus propios copilots, montan automatizaciones locales, enchufan agentes de terceros. Casi siempre sin un gobierno común.

A esto se le ha empezado a llamar Shadow AI. Es la IA que se usa dentro de la empresa y que nadie ha inventariado, aprobado ni monitorizado.

El riesgo no es solo técnico. Es operativo, financiero, regulatorio y reputacional a la vez. Una empresa puede perder la pista, sin enterarse, de qué datos van a modelos externos, qué prompts llevan información sensible, qué agentes tocan sistemas críticos y cuánto cuesta todo eso en tokens y ejecuciones.

En un Fortune 500, eso no se sostiene. Y los agentes lo empeoran, porque no se quedan en el texto. Ejecutan. Un agente mal gobernado puede abrir, cambiar o cerrar registros, leer datos sensibles, disparar flujos, mandar información a terceros. Y hacerlo sin una cadena clara de responsabilidad detrás.

Así que la pregunta de verdad no es si la empresa usará agentes de OpenAI, Anthropic, Microsoft, Google, AWS o ServiceNow. Los va a usar. La pregunta es cómo se inventarian, autorizan, observan, auditan y facturan esas interacciones. Ese es el hueco al que apunta AI Control Tower: convertir un montón fragmentado de IA en un sistema gobernado de activos, riesgos, consumo y valor medible.

La arquitectura agéntica de ServiceNow la veo en tres capas. Una de fundación/datos. Una de gobernanza/control. Una de orquestación. La separación ayuda porque distingue los datos que dan contexto, la maquinaria que gobierna el riesgo, y los protocolos que dejan a los agentes ejecutar.

La capa de abajo es contexto, el suelo operativo sobre el que se apoyan los agentes. En ServiceNow descansa sobre la CMDB, el AI Asset Inventory, el modelo de discovery e inventario, el Knowledge Graph, los propios activos de IA y el multi-instance framework. La CMDB es el registro estructurado de activos y sus relaciones. En el contexto de IA se estira para cubrir sistemas de IA, modelos, prompts, datasets, agentes y servidores MCP, de modo que los activos de IA pasan a ser entidades gobernables y no herramientas sueltas. El Knowledge Graph añade la capa semántica que hace navegable el contexto para un agente: usuarios, roles, los activos que poseen, incidentes previos, servicios afectados, dependencias técnicas.

La capa de en medio decide quién puede usar qué activo de IA, bajo qué condiciones, con qué riesgo, mediante qué controles y medido contra qué valor. Aquí vive AI Control Tower, junto con AI Asset Lifecycle Management, AI Risk and Compliance, el rol de AI Steward, la auditoría, el runtime monitoring, el consumo y los dashboards de ROI. AI Control Tower es el hub de estrategia, gobierno y analítica. Inventaría activos, gestiona su ciclo de vida, evalúa el riesgo, mapea el cumplimiento y mide resultados.

La capa de arriba es donde los agentes actúan de verdad, entre ellos y con sistemas externos: AI Agent Fabric, AI Agent Studio, cliente y servidor MCP, A2A, Agent Cards, agentes externos y el AI Gateway. AI Agent Fabric es la capa de comunicación y coordinación.

El AI Gateway es la pieza que yo destacaría. Es el punto de control transaccional. En un diseño bien gobernado, las llamadas no van directas desde los agentes a los sistemas críticos. Pasan por identidad, permisos, observabilidad, auditoría y la opción de bloquear.

Un agente empresarial vale lo que vale su contexto. Un agente genérico puede redactar, clasificar y resumir. Pero para ejecutar un proceso crítico tiene que saber quién pregunta, qué tiene permiso de hacer, qué activos posee, qué servicio está afectado, qué incidentes ya existen, qué dependencias hay en juego y qué reglas de negocio aplican.

Aquí aparece una parte real del moat de ServiceNow. La ventaja no es el mejor modelo fundacional: no están en ese negocio. La ventaja es estar pegado al sistema de registro y al sistema de acción. La CMDB, los workflows de ITSM, CSM y HR, años de reglas de negocio, el historial de incidentes, los catálogos de servicio y las aprobaciones. Todo junto, es un contexto realmente difícil de reconstruir desde fuera.

Y este moat es operacional, no teórico. Una empresa grande no migra a la ligera años de personalizaciones, tablas, reglas, integraciones y flujos críticos a un stack de agentes puramente externo. Puedes conectar agentes externos por API o MCP, claro. Pero mantener intactos seguridad, trazabilidad, permisos, workflows y cumplimiento a través de ese movimiento es lo bastante caro como para crear costes de cambio reales.

Así que incluso cuando el usuario está en Microsoft Copilot, Slack, Teams o algún agente externo, la ejecución del proceso crítico puede seguir corriendo sobre ServiceNow como backend gobernado.

Los protocolos abiertos juegan un papel ambiguo en esta tesis. Por un lado recortan el lock-in técnico, porque ponen fácil la interoperabilidad. Por otro, aumentan la necesidad de un plano de gobierno. Precisamente porque ponen fácil que agentes externos lleguen a sistemas corporativos.

MCP, el Model Context Protocol, es cliente-servidor. Deja que una aplicación de IA, un agente o un LLM alcance herramientas, APIs, bases de datos o fuentes de contexto expuestas por un servidor MCP. Lo que me parece interesante es que ServiceNow puede estar en cualquiera de los dos lados. Cliente cuando un agente interno consume herramientas externas. Servidor cuando expone sus propias capacidades a agentes de terceros.

A2A, Agent-to-Agent, va más de colaboración entre agentes que de exponer herramientas. Agentes intercambiando tareas, negociando capacidades, delegando subtareas. La Agent Card es la unidad clave: una tarjeta estructurada que describe qué puede hacer un agente, en qué endpoint y con qué capacidades.

Juntos, MCP y A2A no son simples conectores. Son la infraestructura de comunicación sobre la que se construiría una fuerza laboral digital distribuida. Y la pregunta estratégica no es si existen. Van a existir. La pregunta es quién controla esa interoperabilidad, quién decide qué agentes son confiables y quién registra cada interacción.

MCP te da una forma de estructurar la relación entre clientes y servidores de herramientas. En outbound, un agente de ServiceNow usa un cliente MCP para llamar a una herramienta externa. En inbound, un agente externo llama a capacidades de ServiceNow a través de un servidor MCP.

El caso inbound es el que yo vigilaría. Convierte a ServiceNow en un sistema de acción que los agentes de fuera pueden consumir. En concreto: una aplicación de IA externa —Microsoft Copilot, Claude, lo que sea— pide contexto o ejecución a través del AI Gateway. La petición entra en ServiceNow, pasa autenticación y routing, llega al MCP Server Console y finalmente toca workflows o datos internos.

Esa forma deja que ServiceNow conserve un rol estratégico aunque la interfaz visible sea de otro. Si el usuario interactúa desde una superficie externa pero la ejecución segura, los datos estructurados y los workflows empresariales viven en ServiceNow, la plataforma sigue capturando valor como sistema de acción.

Aquí está la versión defendible de la tesis. ServiceNow intenta ser el punto de control para agentes que necesiten ejecutar acciones sobre procesos empresariales regulados. Microsoft, Google, AWS, Anthropic u OpenAI pueden poseer parte de la interfaz o del modelo. ServiceNow puede seguir poseyendo la ejecución gobernada dentro del workflow.

La versión más pesimista del relato de mercado asume que si los agentes reducen el uso de las interfaces SaaS, también reducen el valor de las plataformas. En algunos casos es plausible. Lo que infravalora es el giro hacia precios por consumo.

ServiceNow no tiene que abandonar el licenciamiento por asiento. Más bien parece que lo está complementando. Unidades de consumo atadas a assists, acciones, ejecuciones, llamadas a herramientas, logs de uso y medición de valor. Eso importa porque deja a la compañía capturar valor aunque la interacción no empiece nunca en la interfaz tradicional.

Esta es la parte en la que, durante el último año, he cambiado de idea. Antes leía ServiceNow por crecimiento de asientos. Ahora estoy bastante seguro de que esa es la métrica equivocada.

Si un agente externo invoca una capacidad de ServiceNow, si un flujo corre en background, si una herramienta se llama por MCP, si un agente termina una tarea sin humano en el bucle, el valor deja de medirse solo por usuarios conectados. Empieza a medirse por volumen de automatización, consumo de IA, tiempo ahorrado, éxito de ejecución, productividad capturada.

Los logs de uso, los dashboards de assist consumption, la medición de tokens y las métricas de ejecución te dan la infraestructura para tratar la IA como coste y como fuente de valor. La IA agéntica puede presionar los modelos por asiento. Pero también abre un nuevo eje de monetización construido sobre ejecución gobernada. Si tuviera que elegir la métrica que importa dentro de tres años, me quedaría con ejecuciones por trimestre antes que asientos por año. Puede que me equivoque en esto.