Tu próximo usuario de software es un agente de IA. ¿Está preparada tu arquitectura?

Imagina un agente de IA que gestiona una disputa de facturación de un cliente. Lee la reclamación, consulta el historial de la cuenta y determina que corresponde conceder un crédito. Todo en cuestión de segundos.

Impresionante. Ahora pídele que conceda el crédito.

El contrato del cliente está en otro sistema. Las reglas de aprobación están ocultas en el código de la aplicación. La herramienta de facturación espera que una persona recorra varias pantallas haciendo clic.

El agente entiende qué debe hacer, pero la arquitectura no le permite completar la tarea.

Ese es el problema que espero que encuentren más empresas a medida que la IA agéntica pasa a producción. Sin embargo, lo curioso es que el obstáculo para completar la tarea tiene muy poco que ver con la inteligencia del agente.

Durante años, hemos modernizado el software empresarial para quienes lo utilizan. Ahora tenemos que modernizarlo para los agentes que cada vez más se encargarán de operarlo.

La interfaz de usuario nunca fue todo el producto

Pensemos en cómo funciona hoy el software empresarial. Las personas abren aplicaciones, recorren paneles, toman decisiones y trasladan el trabajo de un sistema a otro. La interfaz de usuario es el medio por el que interactúan con la empresa.

Un agente no necesariamente necesita esas pantallas. Puede recuperar información e iniciar acciones mediante API, servidores del Protocolo de contexto de modelos (MCP) y otras interfaces programáticas. Esto forma parte del cambio hacia una arquitectura sin interfaz.

Pero prescindir de la interfaz no significa que la aplicación desaparezca. Sus datos, reglas de negocio, permisos y requisitos de cumplimiento siguen siendo importantes. Yo diría que lo son aún más.

Durante años, los proveedores de software han creado ventajas competitivas en torno a interfaces de usuario pulidas, los hábitos de los usuarios y el costo de volver a capacitar a los empleados. Esas ventajas se debilitan cuando los agentes realizan más tareas sin abrir la interfaz de usuario de la aplicación. Lo que cobra más valor es el sistema de registro subyacente: datos confiables, lógica de dominio validada, gobernanza operativa y transacciones auditables.

También hay una consecuencia comercial: hasta 234.000 millones de dólares en gasto en aplicaciones empresariales podrían verse expuestos a la disrupción de la IA agéntica para 2030. Se trata de gasto en riesgo de disrupción, no de gasto que vaya a desaparecer con certeza. Y cuando los agentes realicen tareas que antes hacían las personas en los paneles, es posible que los modelos de precios por usuario den cada vez más paso a modelos basados en el uso, las acciones o los resultados.

Para los proveedores de software, esto supone un desafío para el modelo de negocio. Para las empresas que dependen de sus aplicaciones, es un desafío de arquitectura.

Hemos modernizado las piezas, no el flujo de trabajo

La mayoría de las empresas lleva años modernizándose. Un equipo actualiza las aplicaciones heredadas. Otro consolida datos fragmentados en una plataforma moderna. Un tercero crea integraciones o simplemente renueva la interfaz de usuario.

Cada proyecto puede tener éxito por sí solo. El problema empieza cuando un agente necesita ejecutar un flujo de trabajo que abarca todos esos proyectos.

Puedes proporcionarle a un agente información precisa sobre un cliente, pero, si la aplicación encargada de actuar en función de ella mantiene reglas esenciales ocultas en código heredado, ¿qué ocurre después? También puedes exponer una API clara mientras los datos que la sustentan siguen siendo incoherentes. El agente puede actuar, pero ¿puedes confiar en la decisión?

En ambos casos, hemos modernizado partes de la tecnología sin modernizar el trabajo.

A la IA agéntica no le importa qué proyecto de modernización tuvo éxito. Le importa que funcione el flujo de trabajo completo.

Así es como se ve en la práctica. Un cliente necesitaba agilizar la elaboración de presupuestos para reparaciones complejas de motores, en las que los contratos determinan qué piezas pueden repararse, reemplazarse o reacondicionarse. Cada presupuesto requería días, y a veces semanas, de investigación manual en contratos y manuales de mantenimiento. El cliente ya había modernizado su plataforma de datos, pero los presupuestos no se preparaban más rápido porque el cuello de botella nunca habían sido los datos. Era la investigación. Reconstruimos ese flujo de trabajo en torno a un conjunto de agentes de investigación, redujimos el tiempo de investigación en un 80 % y los presupuestos empezaron a prepararse a un ritmo completamente distinto.

Por eso, la modernización de aplicaciones y la de datos no pueden planificarse como dos líneas de trabajo independientes. La arquitectura debe permitir alcanzar el resultado empresarial completo.

Una API no hace que un sistema esté preparado para los agentes

Es tentador pensar que la solución es sencilla: exponer los puntos de conexión, conectar el agente y listo.

Ojalá fuera tan fácil.

Recuperar información es una cosa. Conceder un crédito, actualizar un registro financiero o pedir una pieza de repuesto es algo completamente distinto. Aquí ya hablamos de ejecución, no solo de acceso.

Aquí es donde utilizo el término superficie de control para agentes: la interfaz delimitada y gobernada mediante la cual los agentes leen y escriben en sistemas de registro.

Las API y los servidores MCP pueden poner herramientas y datos a disposición de los agentes. Pero MCP no hace cumplir automáticamente las reglas de negocio ni determina quién está autorizado para actuar. Esos controles aún deben incorporarse mediante ingeniería a los sistemas y flujos de trabajo subyacentes.

¿Puede el agente recuperar datos fidedignos? ¿Están las reglas de negocio claramente definidas y se aplican de forma coherente? ¿Puede recomendar una acción, pero ejecutar únicamente aquellas que está autorizado a realizar? Cuando algo sale mal, ¿podemos rastrear la acción, gestionar la excepción y, cuando sea posible, revertirla?

No son problemas que un modelo mejor vaya a resolver por sí solo. Son cuestiones relacionadas con los flujos de trabajo, el diseño de aplicaciones, la arquitectura de datos, la integración y la gobernanza. Y hay que resolverlas en conjunto.

Empieza por el trabajo, no por la tecnología

Entonces, ¿por dónde deberías empezar?

Yo no empezaría por convertir todas las aplicaciones en sistemas sin interfaz ni por exponer todas las API disponibles. Empezaría por un flujo de trabajo empresarial significativo.

Síguelo de principio a fin. ¿Qué sistemas contienen los registros? ¿Dónde está la lógica de negocio? ¿En qué datos puede confiar el agente? ¿Qué decisiones requieren aprobación humana? ¿Qué ocurre si un sistema falla a mitad del proceso? ¿Cómo se mantiene la gobernanza?

Encontrarás las brechas que importan. Esa es tu hoja de ruta de modernización: una cartera coordinada de tareas pendientes para aplicaciones, datos, integraciones y controles, impulsada por un resultado empresarial en lugar de por proyectos tecnológicos inconexos.

Y mídelo en consecuencia. No por cuántas API hayas expuesto ni por cuántos datos hayas migrado, sino por si el flujo de trabajo se completa de forma fiable, cómo se resuelven las excepciones y si mejoran los resultados empresariales.

El objetivo no es lograr autonomía en todas partes, sino una ejecución fiable y digna de confianza, con criterio humano allí donde corresponde.

El verdadero cambio va mucho más allá de los sistemas sin interfaz

Lo que me entusiasma no es eliminar los paneles. Es lo que ocurre cuando las personas ya no tienen que trasladar manualmente el trabajo entre sistemas desconectados para poder terminarlo.

Pero no lo conseguiremos colocando un agente sobre una arquitectura que nunca se diseñó para ello.

La próxima generación de software empresarial no se definirá únicamente por lo que permite ver a las personas. Se definirá por lo que permite hacer a los agentes, de forma fiable y responsable.