A principios de este año describí lo que llamé teatro DevOps: organizaciones que cambiaron el nombre de su equipo de operaciones, compraron una herramienta CI/CD y declararon la transformación completa mientras la cultura seguía exactamente donde estaba. Unas semanas después escribí que IaC es un requisito previo para DevOps, no el destino, tras ver cómo equipo tras equipo confundía tener plantillas de Terraform con tener una práctica operativa.

Ambas publicaciones diagnosticaron qué estaba roto. Esta publicación ofrece un modelo constructivo de lo que debería reemplazarlo.

El equipo que construyó accidentalmente una plataforma

Una empresa de logística con la que trabajamos en 2024 tuvo los problemas habituales. Cuatro equipos de producto, cada uno provisionando sus propias cuentas de AWS, escribiendo su propio Terraform y manteniendo sus propios pipelines de CI/CD. Dos equipos usaron GitHub Actions, uno usó CodePipeline, el cuarto tenía una instancia de Jenkins que un desarrollador que se había ido había configurado tres años antes y nadie se queria tocar.

Cuando el CTO exigió herramientas de codificación de IA para todos los equipos a principios de 2025, la inconsistencia se volvió insostenible. Claude Code generó configuraciones de infraestructura que asumían una estructura de pipeline que coincidía con el equipo que había escrito más datos de entrenamiento. Los despliegues se rompieron de formas diferentes para cada equipo, y la depuración requirió entender cuatro pilas operativas separadas.

La responsable de infraestructura hizo algo poco glamuroso. Pasó tres meses construyendo un conjunto compartido de plantillas de despliegue, una configuración común de pipeline y un portal de autoservicio donde los equipos de producto podían aprovisionar infraestructura preaprobada sin necesidad de abrir un ticket. No lo llamó plataforma. Lo llamó «hacer que deje de ser llamada a las 3 de la madrugada porque el Terraform de otra persona no funcionaba.»

En seis meses, los fallos de despliegue entre los cuatro equipos disminuyeron de forma medible. El tiempo desde el commit del código hasta la producción pasó de días (variable según el equipo) a horas (consistente). Y las herramientas de codificación de IA empezaron a producir configuraciones de infraestructura que realmente funcionaban a la primera, porque el entorno subyacente era lo suficientemente consistente como para que el código generado fuera predecible.

Había construido una plataforma interna para desarrolladores sin conocer el término.

Qué es realmente la ingeniería de plataformas

El vocabulario proviene de Team Topologies, el libro de 2019 de Matthew Skelton y Manuel Pais que ofreció a la industria un lenguaje compartido sobre cómo deben interactuar los equipos. Su definición de equipo de plataforma es específica: un equipo cuyo trabajo es reducir la carga cognitiva innecesaria en los equipos alineados con los flujos proporcionando capacidades de autoservicio.

La definición ampliamente citada de Evan Bottcher lo refuerza aún más: «Una plataforma digital es una base de APIs, herramientas, servicios, conocimientos y soporte de autoservicio que se organizan como un producto interno atractivo.»

«Autoservicio» significa que el equipo consumidor puede usar la plataforma sin abrir un ticket, unirse a una llamada o esperar una aprobación. «Producto interno» significa que el equipo de la plataforma trata a sus desarrolladores como clientes, con una hoja de ruta, bucles de retroalimentación y un product manager, de la misma manera que una empresa SaaS trata a sus usuarios.

Esta es la distinción que separa a la ingeniería de plataformas del antiguo equipo de infraestructura centralizada que lleva una nueva insignia. El modelo antiguo era un service desk: solicitabas infraestructura, alguien la provisionaba y el bucle de retroalimentación era el estado de un ticket de Jira. El nuevo modelo es un producto: eliges de un catálogo de capacidades preaprobadas y de autoservicio, y el bucle de retroalimentación es si los desarrolladores realmente usan la herramienta voluntariamente.

La trampa de reetiquetado

El mayor riesgo con la ingeniería de plataformas es exactamente el patrón que identifiqué en DevOps Theater: cambiar el nombre del equipo sin cambiar el comportamiento.

Gregor Hohpe, cuya Estrategia de Plataforma (2024) es el tratamiento más detallado de cómo las organizaciones construyen y gobiernan plataformas internas, llama a esto «deuda organizativa»: decisiones estructurales acumuladas que ya no coinciden con el contexto operativo de la organización. Un equipo de plataforma creado por mandato, compuesto por las mismas personas que dirigían el antiguo equipo de infraestructura centralizada, sin gestor de producto y medido por tiempo de actividad en lugar de adopción por parte de los desarrolladores, es deuda organizativa con una nueva etiqueta.

Los datos confirman que esto ocurre a gran escala. La encuesta State of Platform Engineering Vol. 4 de Humanitec encontró que el 36,6% de la adopción de la ingeniería de plataforma está impulsada por el mandato, frente al 28,2% que es por el valor, y el 29,6% de los equipos de plataforma no miden su propio éxito en absoluto. Un profesional que escribió en agosto de 2026 lo expresó sin rodeos: «Los equipos de plataforma se convirtieron en los nuevos guardianes que decíamos odiar.»

Charity Majors ofrece la prueba diagnóstica: «Una plataforma que puedes evitar es un camino. Una plataforma que debes usar es un muro.» Si los desarrolladores eluden tu plataforma, esta se ha convertido en una puerta en lugar de un servicio. En uno de los proyectos que revisamos, más de la mitad de los desarrolladores habían creado sus propias soluciones alternativas para el despliegue en lugar de usar la plataforma oficial, porque el proceso de aprobación de la plataforma era más lento que hacer el trabajo manualmente.

Un portal, un catálogo y un «equipo de plataforma» en el organigrama no suman una capacidad si los desarrolladores siguen presentando tickets para lograr algo.

¿Qué diferencia a una plataforma de un equipo operativo renombrado?

En los proyectos donde hemos visto que la ingeniería de plataformas ha dado resultados reales, cinco características distinguen a una plataforma funcional de una que es simplemente operaciones centralizadas bajo un nombre nuevo.

La plataforma cuenta con un gestor de producto. Alguien es responsable de la experiencia del desarrollador igual que un product manager posee la experiencia del cliente. Realizan encuestas, hacen seguimiento de la adopción, mantienen una hoja de ruta y priorizan según lo que realmente necesitan los desarrolladores en lugar de lo que el equipo de infraestructura cree que deberían necesitar. En los proyectos que he visto, asignar la propiedad del producto suele ser la diferencia entre una plataforma que adoptan los desarrolladores y un service desk con portal.

Los desarrolladores eligen usarlo. La plataforma ofrece caminos dorados, predeterminados y preconfigurados para tareas comunes, y los desarrolladores los adoptan porque son más rápidos y fiables que la alternativa. Exigir su uso es la señal de alerta. Medir la tasa de adopción voluntariamente es el indicador de salud.

El equipo de plataforma entrega, no aprueba. Los equipos que consumen no esperan a que el equipo de plataforma aprovisione infraestructura, revise configuraciones o apruebe cambios. La plataforma proporciona las barreras de seguridad (política como código, comprobaciones automáticas de cumplimiento, plantillas preaprobadas), y el equipo consumidor opera dentro de esas barreras de forma autónoma. El trabajo del equipo de plataforma se realiza antes de que comience el equipo consumidor, no después.

La retroalimentación fluye hacia atrás. Cuando un desarrollador encuentra una limitación en la plataforma, esa limitación se convierte en un elemento pendiente para el equipo de plataforma. El bucle de retroalimentación va del consumidor al proveedor, en la misma dirección que cualquier bucle de retroalimentación de producto. En el modelo antiguo, la retroalimentación iba en la dirección opuesta: el equipo de infraestructura decía a los desarrolladores lo que podían tener. Esa inversión es el cambio de comportamiento que separa los dos modelos.

La carga cognitiva es medible y medida. El equipo de la plataforma sabe qué tareas consumen más tiempo de desarrollador, qué flujos de trabajo generan más solicitudes de soporte y qué caminos dorados tienen la mayor adopción. Mide la reducción de la carga cognitiva de la misma manera que un producto SaaS mide el tiempo hasta el valor. Si el equipo de la plataforma no puede articular qué carga cognitiva eliminó este trimestre, están manteniendo la infraestructura, no ejecutando una plataforma.

Por qué esto importa más en un entorno acelerado por IA

El informe de DORA de 2026, El ROI del Desarrollo de Software Asistido por IA, presenta la IA como un amplificador: en equipos con prácticas sólidas de entrega, la IA amplía la capacidad; en equipos con revisiones lentas, pruebas frágiles y arquitectura no documentada, la IA amplifica la disfunción que ya existe. El informe introduce un «impuesto de verificación», el esfuerzo adicional necesario para comprobar si el código generado por IA es fiable, seguro y alineado con la arquitectura del sistema. Cuando ese impuesto es alto, la velocidad que la IA añade durante la codificación se consume durante la revisión, las pruebas y la respuesta a incidentes.

Una plataforma reduce directamente ese impuesto. Cuando el entorno es consistente, los caminos dorados codifican buenos valores predeterminados y las barreras hacen cumplir la política antes del despliegue, el código generado por IA tiene menos supuestos que puedan fallar. El modelo de capacidades de IA 2025 de DORA, identificó la calidad interna de la plataforma como una de las siete capacidades que amplifican los beneficios de la IA, y la empresa logística de mi historia inicial es un pequeño ejemplo del mismo mecanismo: una vez que el entorno se estandarizó, la salida de la IA se volvió predecible.

El informe 2026 State of Platform Engineering de Puppet apunta en la misma dirección. Las organizaciones que obtuvieron una alta puntuación en madurez de plataforma auto-reportaron un 73% de éxito con flujos de trabajo de desarrollo asistidos por IA, frente al 44% de las organizaciones con baja madurez. La encuesta midió la eficacia percibida más que las métricas de entrega, pero el patrón es consistente: las plataformas reducen el impuesto de verificación y los equipos que pagan menos capturan más de la velocidad de la IA como entrega real.

El teatro DevOps persiste porque el modelo operativo subyacente nunca cambió. La ingeniería de plataformas, hecha correctamente, cambia el modelo operativo al convertir la infraestructura de un service desk en un producto. La IA acelera todo lo que funciona en ese modelo, todo. Las organizaciones con una plataforma funcional obtienen rendimientos compuestos de la IA. Las organizaciones que realizan el teatro de plataformas obtienen una complejidad acumulada.

Cómo es estar sano

Gartner predijo que el 80% de las grandes organizaciones de ingeniería tendrían equipos de plataforma dedicados para 2026, frente al 45% de 2022. La adopción ocurrió. La mayoría de esos equipos siguen operando como antes de la reorganización.

Esto es lo que veo en las organizaciones donde el modelo funciona.

El equipo de plataforma es pequeño. En los proyectos donde hemos visto este trabajo, entre cinco y ocho personas sirven a una organización de ingeniería de cien personas, aunque el número correcto depende de la carga regulatoria, el número de tipos de servicio distintos y cuántos caminos dorados necesita la organización. No gestionan la producción para los equipos consumidores; proporcionan las capacidades que permiten a los equipos consumidores gestionar su propia producción. Mantienen los caminos dorados, las barreras de política como código, la provisión de autoservicio y la línea base de observabilidad. Tienen un gestor de producto que se encarga del backlog en la experiencia de los desarrolladores.

Los equipos que consumen despliegan sin esperar a nadie. Eligen un camino dorado (una plantilla de despliegue preconfigurada, una pila estándar de observabilidad, una configuración de base de datos preaprobada), personalizan lo que necesitan y despliegan. Las barreras de seguridad están integradas en la pipeline, por lo que las violaciones de políticas fallan en la construcción en lugar de requerir una revisión humana. Los predeterminados hacen el trabajo: un equipo consumidor que sigue el camino dorado hereda los controles de cifrado, etiquetado, registro y costes sin configurar ninguno de ellos.

Las revisiones de arquitectura cambian de alcance cuando existe una plataforma. Las decisiones repetidas de infraestructura, las que se repiten en todos los equipos, se revisan a nivel de plataforma, donde una revisión pone a la luz problemas que de otro modo requerirían revisar a cada equipo individualmente. Las decisiones específicas de servicio, las que dependen del modelo de datos del equipo, los modos de fallo o el comportamiento de cara al cliente, siguen perteneciendo al equipo. Cuando los equipos acelerados por IA necesitan revisiones de arquitectura más que nunca, la plataforma absorbe los casos comunes para que las revisiones a nivel de equipo puedan centrarse en lo que es realmente único.

Y la medición está centrada en los desarrolladores, no en la infraestructura. El equipo de la plataforma controla la tasa de adopción, el tiempo para el primer despliegue de los nuevos equipos, el volumen de tickets de soporte (la tendencia a la baja es saludable) y la fracción de despliegues que usan caminos dorados frente a configuraciones personalizadas. El bypass sostenido de un camino dorado es una señal de producto: algo en la ruta no sirve al equipo, y el backlog de la plataforma debería reflejarlo.

Dónde se rompe esto

La ingeniería de plataformas puede fracasar de todas las formas en que lo hizo el teatro DevOps, y por las mismas razones. Un mandato sin product manager es un service desk. Un portal que nadie usa es una página web. Los caminos dorados que los desarrolladores evitan son sugerencias, no infraestructura.

AWS creó su propio producto de habilitación de ingeniería de plataformas, Proton, y lo va a retirar en octubre de 2026. Si el hiperescalador que vende la infraestructura subyacente no pudo hacer que su propio producto de plataforma se mantuviera, la lección vale la pena ser absorbida: una disciplina de plataforma perdura más que cualquier herramienta en particular, y las organizaciones que confundieron el producto con la práctica empezarán de nuevo cuando el producto se retire.

Para hacerlo bien requiere entender que el problema nunca fueron las herramientas. Lo importante era si la adopción cambió la forma en que las personas trabajan, o simplemente cómo se lee el organigrama.

La responsable de infraestructura de mi historia inicial no pretendía construir una plataforma. Se propuso dejar de ser llamada por problemas que no eran suyos. La plataforma surgió porque trataba el trabajo como un producto que sus compañeros necesitaban, no como un servicio que debían usar. Su plataforma funcionaba porque los desarrolladores recurrían a ella cuando necesitaban desplegar, y eso le indicaba qué partes valía la pena mantener.

Ricardo