Inteligência Artificial
Platform Engineering: plataformas para agentes de IA
Durante los últimos años, Platform Engineering ganó espacio como respuesta a un problema bastante concreto: la complejidad necesaria para desarrollar y operar aplicaciones creció más rápido de lo que sería razonable transferir a cada equipo de desarrollo.
Infraestructura, pipelines, seguridad, observabilidad, políticas, entornos, servicios compartidos e innumerables otras capacidades pasaron a ser organizadas por equipos de plataforma, ofreciendo a los desarrolladores caminos estandarizados para consumir todo eso sin necesidad de dominar cada detalle de la infraestructura.
Ahora, un cambio comienza a alterar una de las premisas de este modelo.
El desarrollador humano ya no es necesariamente el único consumidor de la plataforma.
Los agentes de inteligencia artificial empiezan a consultar catálogos, analizar telemetría, utilizar herramientas, ejecutar workflows e interactuar con recursos corporativos. En escenarios más avanzados, pueden participar en la investigación de incidentes, en el aprovisionamiento de recursos e incluso en procesos de despliegue de software.
Cuando esto ocurre, Platform Engineering deja de tener solo personas del otro lado de la interfaz.
La plataforma que se creó para abstraer la complejidad para los desarrolladores empieza a necesitar hacer lo mismo para los agentes de IA.
Este cambio parece pequeño, pero sus implicaciones van mucho más allá de simplemente crear nuevas APIs.
Platform Engineering nació para esconder una complejidad que no debería estar en todas partes
El principio detrás de Platform Engineering es relativamente simple.
En lugar de que cada equipo arme individualmente su propia combinación de infraestructura, automatización, seguridad, observabilidad y procesos de entrega, una plataforma interna ofrece capacidades compartidas, autoservicio y caminos previamente definidos.
Uno de los elementos utilizados para ello son las Internal Developer Platforms (IDPs), o plataformas internas para desarrolladores, que organizan capacidades de desarrollo y operación de manera estandarizada y accesible a los equipos.
Catálogos de servicios, plantillas, entornos estandarizados, automatizaciones y los llamados golden paths, caminos recomendados que incorporan prácticas y controles previamente definidos, ayudan a reducir la cantidad de decisiones que cada desarrollador debe tomar para ejecutar tareas recurrentes.
La Cloud Native Computing Foundation (CNCF), organización que mantiene y promueve importantes proyectos del ecosistema cloud native, describe esta evolución como una forma de encapsular prácticas operacionales detrás de workflows, autoservicio y entornos estandarizados, permitiendo que los desarrolladores se concentren más en la funcionalidad que necesitan entregar [1].
El modelo funcionó durante años con una premisa casi implícita: quien consume la plataforma es una persona. Es justamente esa premisa la que la IA Agéntica comienza a alterar.
El agente también comienza a consumir la plataforma
Un agente que investiga un incidente puede necesitar descubrir qué servicios están relacionados, consultar telemetría, identificar al responsable de una aplicación, verificar un cambio reciente o activar un workflow operacional.
Otro agente, actuando en el ciclo de desarrollo, puede necesitar consultar patrones arquitectónicos, descubrir qué componentes están aprobados, aprovisionar un entorno o iniciar un proceso de despliegue.
Son tareas que utilizan capacidades que muchas plataformas internas ya ofrecen a las personas.
En julio de 2026, la CNCF publicó un análisis sobre Platform Engineering para empresas agénticas argumentando justamente que los agentes de IA se están convirtiendo en consumidores de la plataforma junto a los profesionales humanos. El texto cita actividades como aprovisionamiento de infraestructura, despliegue de aplicaciones, investigación de incidentes, análisis de telemetría y ejecución de workflows operacionales [1].
Gartner llega a una conclusión semejante. En Agentic AI Readiness Requires Platform Engineering, publicado en junio de 2026, recomienda que las organizaciones ofrezcan caminos automatizados y estandarizados para que los agentes puedan construir, desplegar y operar software, utilizando componentes consumibles por máquinas con gobernanza y validación incorporadas [2].
No hablamos, por lo tanto, solo de usar IA para aumentar la productividad de los equipos de plataforma. Hablamos de algo distinto: la propia IA empieza a convertirse en usuaria de la plataforma.
La misma plataforma, pero no necesariamente la misma interfaz
Las personas y los agentes no necesitan interactuar con una plataforma de la misma manera.
Un desarrollador puede utilizar un portal, una interfaz de línea de comandos o un pipeline. Un agente probablemente consumirá esas capacidades de forma programática.
Esto no significa, sin embargo, que sea necesario construir una segunda plataforma solo para la IA.
El análisis de la CNCF defiende justamente la evolución de la plataforma existente para que humanos y agentes puedan operar sobre fundamentos comunes de identidad, gobernanza, seguridad, observabilidad, políticas y gestión del ciclo de vida [1].
Una investigación realizada por la CNCF en alianza con SlashData ayuda a mostrar cómo este movimiento ya empieza a aparecer. El CNCF Technology Radar Q1 2026, basado en respuestas de más de 400 desarrolladores profesionales, identificó diferentes estrategias para incorporar workflows de IA a las plataformas existentes. Entre los 364 encuestados que integraban workflows de IA, el 35% indicó un enfoque híbrido, con experimentación separada y despliegue en producción compartido, mientras que el 17% dijo haber extendido su plataforma de desarrollo existente para soportar esos workflows [3].
Estos números no significan que exista un modelo dominante definitivo. Muestran, sin embargo, que las empresas ya están decidiendo si la IA se integrará a la base existente o se tratará como una infraestructura separada.
Crear una plataforma paralela para cada nueva generación tecnológica puede resolver el problema inmediato, pero también puede crear nuevos silos de operación, seguridad y gobernanza.
Para los agentes, esa fragmentación puede ser particularmente problemática porque necesitarán interactuar justamente con recursos que ya pertenecen al entorno corporativo.
La plataforma pasa a tener dos tipos de consumidores
La evolución de los portales internos ayuda a hacer este cambio más concreto.
Gartner, en su Market Guide for Internal Developer Portals de julio de 2026, afirma que los equipos de Platform Engineering pasan a tener la responsabilidad de mejorar la experiencia tanto de los desarrolladores como de los agentes de IA, manteniendo una gobernanza consistente y facilitando el descubrimiento y el acceso a las capacidades de desarrollo y entrega [4].
Red Hat presenta una visión semejante al argumentar que el valor de un portal interno no está solo en su interfaz gráfica. Catálogos de servicios, documentación, plantillas, ownership, integraciones y políticas constituyen un conjunto de contexto corporativo que también pueden consumir los agentes [5].
En este modelo, el portal deja de ser solo un destino que el desarrollador visita y pasa a funcionar también como una infraestructura de contexto que los agentes pueden consultar programáticamente.
Esto cambia la manera de pensar la experiencia de plataforma.
La experiencia del desarrollador sigue siendo importante, pero surge también una especie de experiencia del agente: ¿logra descubrir qué capacidades existen? ¿Entiende cómo utilizarlas? ¿Recibe solo los permisos necesarios? ¿Logra acceder a contexto suficiente para tomar una decisión? ¿Quedan registradas sus acciones?
Las preguntas son distintas, pero la responsabilidad sigue siendo de la plataforma.
El contexto pasa a formar parte de la infraestructura
Este quizás sea el punto que considero más importante en esta evolución.
Un agente puede tener acceso a herramientas excelentes y aun así tomar malas decisiones si no comprende el entorno en el que actúa.
Para investigar un incidente, por ejemplo, no basta con tener acceso a logs. Puede ser necesario comprender topología, dependencias, ownership, cambios recientes, políticas, historial operacional y relación entre servicios.
La CNCF argumenta que, a medida que aplicaciones, recursos y agentes pasan a formar un ecosistema interconectado, comprender las relaciones entre esos elementos se vuelve tan importante como administrar los propios elementos. La telemetría sigue siendo esencial, pero debe combinarse con información sobre dependencias, cambios, propiedad y conocimiento operacional para construir una comprensión más completa del sistema [1].
Red Hat llega a una conclusión semejante al discutir portales para agentes: el catálogo, los estándares, las políticas y la documentación que ya orientan a los desarrolladores pasan a constituir contexto empresarial que también puede orientar la actuación de la IA [5].
Cuanta más autonomía entregamos al agente, menos aceptable se vuelve dejarlo reconstruir solo el contexto de la empresa en cada decisión.
Esto acerca Platform Engineering a un tema que hemos discutido a lo largo de esta serie: el contexto operacional compartido.
Personas, automatizaciones y agentes no deberían construir versiones independientes de la realidad para luego intentar conciliarlas cuando algo sale mal.
Servir a la IA también significa gobernarla
Si un agente pasa a consumir la plataforma, también necesita operar dentro de los controles de la plataforma.
Este tema se conecta directamente con lo que discutimos en Los agentes de IA también necesitan identidad: ¿quiénes son y a qué pueden acceder?
Cada agente necesita tener identidad propia, permisos delimitados y un registro de auditoría. La CNCF argumenta que los desarrolladores, los profesionales de Site Reliability Engineering (SRE), disciplina orientada a la confiabilidad y la operación de sistemas a escala, y los agentes pueden utilizar interfaces distintas, pero sus acciones deben permanecer sometidas a controles consistentes de seguridad, políticas y límites operacionales [1].
Gartner también coloca la gobernanza y la validación incorporadas a los caminos consumidos por los agentes como parte de la preparación de Platform Engineering para la IA Agéntica [2].
Esto es importante porque la abstracción que ofrece la plataforma no puede significar ausencia de control, al contrario.
Si un agente logra aprovisionar un recurso, ejecutar un workflow o iniciar un despliegue, la plataforma necesita saber quién es, qué acciones puede realizar, qué políticas se aplican y cómo registrar lo que hizo.
Platform Engineering, identidad, observabilidad y AgentOps comienzan, por lo tanto, a encontrarse en la misma arquitectura.
No estamos construyendo una plataforma para agentes
Hay una diferencia importante entre adaptar Platform Engineering a la IA Agéntica y construir una infraestructura enteramente nueva alrededor de los agentes.
La primera opción amplía una base que ya existe.
La segunda corre el riesgo de recrear, en torno a la IA, los mismos problemas de fragmentación que Platform Engineering surgió para resolver.
El objetivo no debería ser crear un camino para desarrolladores y otro completamente separado para agentes. Debería ser permitir que ambos consuman capacidades corporativas comunes por interfaces adecuadas a cada uno, compartiendo políticas, identidad, contexto, observabilidad y gobernanza.
La CNCF resume esta evolución defendiendo que la próxima generación de Platform Engineering debe ampliar la plataforma existente para que aplicaciones, recursos y agentes puedan administrarse dentro de un modelo operacional común [1].
Red Hat, al discutir la evolución de los portales internos, sigue una dirección semejante: la interfaz puede cambiar, pero el catálogo, los golden paths, las integraciones y el contexto siguen siendo relevantes porque pasan a atender a dos públicos, personas y agentes [5].
La llegada de los agentes no reduce la importancia de la plataforma. Amplía a quién necesita servir la plataforma.
Este quizás sea el principal cambio.
De la visión a la práctica: ARGUS
Esta evolución tiene una conexión directa con la propuesta actual de ARGUS.
ARGUS nació con el propósito de correlacionar eventos de múltiples fuentes, reducir el ruido y construir contexto operacional compartido. En entornos en los que los agentes comienzan a investigar incidentes, consultar recursos y participar en decisiones operacionales, ese contexto pasa a poder ser consumido no solo por las personas, sino también por las inteligencias que actúan a su lado.
Con la incorporación de AI Gateway y AgentOps (Agent Operations), esta propuesta se amplía. AI Gateway permite aplicar políticas y controlar cómo las aplicaciones y los agentes acceden a recursos de inteligencia artificial, mientras que AgentOps amplía la capacidad de orquestar agentes, acompañar sus ejecuciones y acciones y establecer mecanismos de observabilidad, gobernanza y supervisión.
El objetivo no es crear una infraestructura paralela para agentes. Es permitir que participen en la operación dentro de una arquitectura en la que políticas, contexto, acciones y resultados puedan relacionarse.
Esto significa que un agente puede recibir contexto sobre lo que ocurre en el entorno y, al mismo tiempo, su propia actuación puede pasar a formar parte de ese contexto. Decisiones, llamadas a herramientas, cambios, eventos y resultados pueden relacionarse con la infraestructura, con los servicios y con las demás informaciones operacionales disponibles.
La plataforma pasa a servir también a la IA, pero la IA necesita operar dentro del mismo contexto y de los mismos mecanismos de gobernanza que sustentan la operación.
Esta combinación ayuda a evitar que la adopción de agentes cree una nueva capa aislada de tecnología, con su propia visión del entorno y sus propios mecanismos de control.
A medida que personas, automatizaciones y agentes pasan a compartir la operación, una visión sistémica común deja de ser solo una herramienta para investigación de incidentes y pasa a formar parte de la propia infraestructura necesaria para ampliar la autonomía con seguridad.
Conozca ARGUS y vea cómo funciona en la práctica.
Sobre el autor
Paulo Florêncio de Menezes es emprendedor, socio y cofundador de empresas como Target Solutions, BiPTT y ARGUS.
Es graduado en Procesamiento de Datos por la Universidad Federal de Amazonas (UFAM), tiene MBA en Gestión Empresarial por la Fundación Dom Cabral (FDC) y Máster Profesional en Economía por la Fundación Getulio Vargas (FGV).
En su investigación de máster desarrolló el IBEOP-IA (Índice Brasileño de Exposición Ocupacional Potencial a la Inteligencia Artificial), investigando la exposición potencial de las ocupaciones brasileñas a las capacidades de la IA mediante la combinación de datos ocupacionales, patentes de inteligencia artificial y técnicas de procesamiento de lenguaje natural.
Referencias
[1] Cloud Native Computing Foundation (CNCF). Platform engineering for the agentic enterprise: Managing applications, resources, and AI agents. 21 jul. 2026.
[2] Gartner. Agentic AI Readiness Requires Platform Engineering. 5 jun. 2026.
[3] Cloud Native Computing Foundation (CNCF) y SlashData. CNCF Technology Radar Q1 2026. 2026.
[4] Gartner. Market Guide for Internal Developer Portals. 15 jul. 2026.
[5] Red Hat. Why developer portals matter more in the age of AI agents. 7 may. 2026.