¿Dónde van a correr tus agentes de IA? Dos preguntas que no son la misma

Hay una pregunta que me están haciendo cada vez más seguido en reuniones con bancos, aseguradoras y diversas industrias: «¿en qué plataforma deberíamos correr nuestros agentes de IA?»

El problema es que esa pregunta, hecha así, mezcla dos conversaciones completamente distintas. Una la hace el área de negocio. Otra la hace la gente de plataforma y arquitectura. Y si no las separamos desde el día uno, terminamos comprando una herramienta que resuelve el problema equivocado.

Vamos a las dos perspectivas.

Perspectiva 1: el agente como producto de negocio

Desde el lado de negocio, la pregunta real no es «qué motor de IA usamos», sino «quién arma el agente, qué tan rápido lo pone en producción, y a qué sistemas se conecta sin que TI tenga que meter mano en cada iteración».

Aquí es donde entran las plataformas orientadas a low-code/no-code: constructores visuales donde un equipo de operaciones, cobranzas o atención al cliente puede definir el rol del agente, los datos a los que accede y las acciones que puede ejecutar, sin escribir una línea de código. Estamos hablando de herramientas tipo Agentforce de Salesforce, Watson Orchestrate de IBM, Kore.ai, o plataformas de automatización visual como n8n y Dify, que priorizan la velocidad de despliegue y la conectividad out-of-the-box con Slack, correo, CRMs y bases de datos.

El criterio de éxito acá no es la sofisticación del razonamiento del modelo. Es:

– ¿Cuánto se tarda en pasar de idea a agente funcionando?
– ¿El equipo de negocio puede iterar sin depender de un sprint de desarrollo?
– ¿Hay un catálogo de conectores para lo que ya tenemos (core bancario, ticketing, ERP)?
– ¿Cómo se mide el ROI? En la banca de la región ya estamos viendo casos con retornos de 4-5x sobre la inversión anual y paybacks de tres a cuatro meses cuando el agente ataca un proceso bien acotado (triage de tickets, calificación de leads, seguimiento de cobranza).

El riesgo de esta perspectiva, si se queda sola, es el famoso «shadow AI»: decenas de agentes de negocio corriendo en plataformas SaaS distintas, cada uno con su propia gobernanza (o sin ninguna), sin trazabilidad ni control de acceso a datos sensibles. Y en sector financiero, eso no es un detalle menor — es un hallazgo de auditoría esperando a suceder.

Perspectiva 2: el agente como carga de trabajo de plataforma

Desde el lado de arquitectura e infraestructura, la pregunta es otra: «¿dónde corre esto en producción, cómo lo observo, cómo lo aíslo, y cómo lo gobierno igual que gobierno cualquier otra carga en mi clúster?»

Acá el año 2026 dejó algo bastante claro: los agentes se están volviendo ciudadanos de primera clase de Kubernetes, no un anexo raro que vive en un notebook o en un SaaS aparte. Proyectos como kagent (de los fundadores de Istio, hoy en CNCF Sandbox) o Krypton tratan al agente como un CRD más — versionado en Git, desplegado con Helm, con RBAC, con scaling desde cero, con observabilidad vía OpenTelemetry y Prometheus desde el primer día.

Dos protocolos se consolidaron como el estándar de facto para esta capa:

– MCP (Model Context Protocol), que conecta un agente con sus herramientas y fuentes de datos.
– A2A (Agent-to-Agent), que conecta agentes independientes entre sí, permitiendo que descubran capacidades e intercambien mensajes sin exponer su implementación interna.

Red Hat OpenShift AI ya se movió en esta dirección con su catálogo de MCP: en lugar de que cada equipo cace, containerice y asegure servidores MCP a mano, la plataforma ofrece un catálogo curado, con gobernanza centralizada y tiempos de puesta en marcha bastante más cortos.

El criterio de éxito acá es completamente distinto al de negocio:

– ¿El agente respeta el mismo modelo de identidad, RBAC y zero-trust que el resto de la plataforma?
– ¿Hay trazabilidad de cada prompt, cada tool call, cada token consumido?
– ¿El diseño es agnóstico de framework (LangGraph, CrewAI, Google ADK) y de proveedor de LLM?
– ¿Cómo aíslo el radio de explosión si un agente se comporta de forma inesperada, dado que ahora tiene permisos para ejecutar acciones, no solo para responder texto?

Las dos perspectivas no compiten, se necesitan

La tensión real no es «low-code vs. Kubernetes» ni «negocio vs. plataforma». Es que ambas capas van a existir en toda organización financiera seria de la región, y la madurez está en decidir qué vive en cada una.

Mi recomendación de campo, después de varias conversaciones con clientes bancarios y aseguradoras en Perú: dejen que el área de negocio prototipe y valide valor rápido en herramientas low-code, pero definan desde el principio cuál es la puerta de entrada a producción — el gateway de agentes, el catálogo de MCP gobernado, el control plane sobre OpenShift — para que ningún agente llegue a tocar datos de clientes sin pasar por ahí.

La plataforma de negocio responde «¿esto genera valor rápido?». La plataforma técnica responde «¿esto es seguro, auditable y sostenible en el tiempo?». Un programa de agentes de IA maduro necesita una respuesta afirmativa a las dos preguntas, no a una sola.