8 Min. tiempo de lectura
FinOps sale en 2026 de la fase de dashboards. El 78 % de las prácticas de FinOps están ya integradas en la organización del CTO o el CIO, no en el área de control de gestión. Esto significa para los equipos de cloud: la pregunta ya no es si los costes de la nube son visibles, sino con qué rigor las decisiones de ingeniería se basan realmente en los datos de costes. El paso del seguimiento de costes a la disciplina de ingeniería determinará si la inversión en FinOps genera el retorno prometido.
Lo esencial en pocas palabras
- FinOps reside en la organización de ingeniería. El 78 % de las prácticas reportan al CTO o al CIO, un aumento de 18 puntos porcentuales respecto a 2023. La disciplina ha logrado pasar de ser un tema de control de gestión a una tarea de plataforma.
- Federado supera a centralizado. El 60 % trabaja con equipos centrales de habilitación, mientras que el 21 % lo hace con modelos hub-and-spoke. La centralización pura no escala con el crecimiento de la nube.
- Crawl-Walk-Run sigue siendo el núcleo. La FinOps Foundation no ha sustituido la lógica de fases en 2026. Lo que ha cambiado: cada fase tiene responsabilidades claras de ingeniería, no solo métricas del equipo de FinOps.
RelacionadoCostes de inferencia de IA: FinOps para cargas de trabajo con GPU / Opus 4.7 vs. GPT-5.4: Inferencia en la nube europea 2026
Qué implica en concreto el salto del seguimiento de costes a la disciplina de ingeniería
En la primera ola de FinOps, el objetivo era la visibilidad: dashboards, alertas de presupuesto, informes mensuales de desviaciones. Fue un paso necesario, pero rara vez generó los ahorros prometidos, porque la visibilidad no se traducía automáticamente en acción. Un equipo de ingeniería que detecta un pico de costes en un clúster de Kubernetes un lunes debe saber qué puede cambiar, quién debe aprobarlo y quién libera el tiempo para hacerlo. Si esta cadena no existe, el dashboard se queda en un informe sin consecuencias.
La segunda ola (ya en el mainstream en 2026) integra FinOps directamente en los flujos de trabajo de ingeniería. Esto significa, en concreto: las etiquetas de costes son un requisito obligatorio en los despliegues, los nuevos servicios incluyen un comentario sobre costes en la revisión de PR, y las decisiones de arquitectura se presentan con un cálculo de TCO. La diferencia no está en la herramienta, sino en la definición de lo que un ingeniero debe entregar. Se trata de un cambio cultural que, en muchas organizaciones, requiere entre tres y cuatro trimestres.
Otro aspecto que gana visibilidad en la segunda ola de FinOps es la integración con el equipo de ingeniería de plataformas. Si una organización construye una plataforma interna para desarrolladores, FinOps no es un complemento, sino parte de la disciplina de la plataforma. Las plantillas de golden path incluyen etiquetado, límites de presupuesto y señales de compromiso desde el principio. Los desarrolladores no tienen que ocuparse activamente de FinOps, porque la plataforma proporciona los valores predeterminados correctos. Esta es la forma más eficiente de integrar FinOps en el día a día, pero también la más exigente, ya que requiere una organización de ingeniería de plataformas que funcione.
Estructuras de equipo que funcionarán en 2026
La FinOps Foundation distingue tres modelos principales para organizar esta disciplina. El *Enablement* centralizado es el modelo por defecto, con un 60 % de las prácticas. Un pequeño equipo central establece estándares, herramientas y formaciones, mientras que la ejecución operativa recae en los equipos de producto. El modelo *Hub-and-Spoke*, con un 21 %, es común en grandes empresas: un grupo FinOps central junto a *champions* dedicados por unidad de negocio. Los modelos completamente descentralizados son raros y solo funcionan en organizaciones de ingeniería muy maduras.
La elección del modelo depende del tamaño de la infraestructura en la nube y de la cultura de ingeniería. Una empresa con un gasto mensual en la nube de 500.000 euros no necesita un *setup* *Hub-and-Spoke* con diez *champions*. Una compañía con diez millones al mes no puede escalar con un equipo central sin un modelo de federación. El error más frecuente es implementar un modelo demasiado grande demasiado pronto, ya que los proveedores de FinOps suelen vender la complejidad empresarial. Por lo general, una empresa de *mid-market* comienza con una persona o un equipo de dos como *enablers* y escala cuando el gasto en la nube lo justifica.
Lo que a menudo se subestima en la estructura del equipo es el papel del socio financiero. Un equipo FinOps sin conexión directa con el *controlling* pierde influencia en la disciplina presupuestaria. Por el contrario, un *controlling* sin contacto técnico con FinOps se convierte rápidamente en un gestor de presupuestos en papel, que no entiende las estructuras reales de costes de la nube. Los *setups* exitosos en 2026 contarán con una persona de finanzas dedicada que colabore estrechamente con el equipo FinOps, elabore informes mensuales conjuntos y asuma la responsabilidad compartida de las cifras en los informes de gestión.
Otro aspecto estructural es la clara delimitación entre FinOps y *Procurement*. FinOps no decide por sí solo sobre *commits*, *Reserved Instances* o acuerdos plurianuales. Estas decisiones requieren al departamento de compras, la gestión financiera y, a menudo, la dirección. FinOps proporciona la base de datos y los cálculos de escenarios, pero el contrato se firma en otro lugar. Las organizaciones que mezclan estos roles acaban teniendo equipos FinOps con demasiado poder contractual o departamentos de compras con poco contexto técnico. Ambas situaciones generan problemas. Una delimitación clara de roles ahorra, en la práctica, muchas reuniones y acelera notablemente las decisiones, ya que las vías de escalada están definidas de antemano. La colaboración se convierte en una rutina operativa.
Dónde se estancan las prácticas FinOps en 2026
- Equipo FinOps sin autoridad para decidir sobre estándares de *tagging*
- *Dashboards* sin *playbooks* de reacción definidos
- Equipos de ingeniería sin KPIs de costes en sus propios OKRs
- Falta de conexión entre contratos especiales y planificación de *workloads*
Qué caracteriza a las prácticas FinOps maduras
- Política de *tagging* como *gate* estricto en el *deployment*
- Métricas de costes en las vistas diarias de ingeniería (*Datadog*, *Grafana*)
- OKRs de costes por equipo, con *ownership* directo
- Estrategia de *Reserved Instances* y *commits* vinculada a la hoja de ruta de *workloads*
La integración con los OKRs de ingeniería es un aspecto que en 2026 tendrá mucho más éxito que en 2024. Quien vea FinOps como un freno de costes encontrará resistencia. Quien trate FinOps como una métrica de eficiencia junto a rendimiento, disponibilidad y velocidad, contará con equipos que se evalúan a sí mismos con estas cifras. La diferencia en el lenguaje es pequeña, pero el impacto en la aceptación es grande.
Las fases Crawl-Walk-Run aplicadas de forma concreta
La FinOps Foundation no ha sustituido en 2026 su modelo Crawl-Walk-Run, sino que lo ha perfeccionado. Las tres fases se mantienen, pero cada una ha adquirido responsabilidades de ingeniería más concretas. Crawl es concienciación: el equipo comprende de dónde proceden los costes y qué servicios son caros. Paralelamente, queda claro quién opera cada recurso. Duración típica: entre tres y seis meses. Walk es propiedad: el equipo asume la responsabilidad de los recursos que opera. Las primeras decisiones de optimización se toman a nivel de equipo. Duración: entre seis y doce meses después del inicio de Crawl. Run es optimización: las decisiones basadas en datos forman parte del día a día, y se aplican políticas automatizadas. Las decisiones sobre costes se integran en el flujo normal de trabajo de ingeniería.
En la práctica, no todos los equipos avanzan por las fases al mismo ritmo. Un equipo de DevOps con gran sensibilidad hacia los costes puede estar en Run a los nueve meses. Un equipo de producto centrado en la entrega de funcionalidades puede necesitar a veces dos años para consolidar Walk. Los niveles de madurez se asignan por equipo, no por organización. La función central de FinOps mide y reporta, pero la decisión sobre la velocidad la toma el responsable de ingeniería correspondiente.
Una pregunta frecuente es cuándo llegan las organizaciones a Run. Los datos del informe *State of FinOps* muestran que en 2026 la proporción de prácticas Run ronda un tercio, con tendencia al alza. La mayoría sigue trabajando en la fase Walk, con objetivos de optimización claros, pero sin una integración completa en la ingeniería. La transición de Walk a Run es el momento en el que FinOps deja de ser un programa independiente. En su lugar, se convierte en parte de la disciplina normal de la plataforma.
Los temas de costes que llegan nuevos a la agenda en 2026
Dos temas están transformando la práctica de FinOps en 2026, más allá de las categorías tradicionales de costes en la nube. El primero es la gestión de costes de IA. Las instancias de GPU, la facturación por tokens de las API de LLM y los costes de almacenamiento y red de las grandes pipelines de entrenamiento e inferencia representan una nueva clase de costes. La transparencia es menor que en los recursos cloud clásicos, y la volatilidad de precios, mayor. También difieren las palancas de optimización. Quien integre los workloads de IA en los procesos FinOps existentes subestimará sus particularidades.
El segundo tema es FinOps de sostenibilidad. La vinculación entre optimización de costes y reducción de CO₂ ya no es solo un reclamo de marketing, sino un criterio medible en los informes CSRD y en las licitaciones europeas. Los proveedores cloud ofrecen datos de huella de carbono a nivel de recurso, y los dashboards de FinOps muestran costes y emisiones en paralelo. Para las empresas sujetas a la CSRD, esto es ya una necesidad práctica, no una opción.
Un tercer factor que cobra mayor relevancia en 2026 es la integración con el aprovisionamiento y la gestión contractual. Quien quiera aprovechar al máximo las Reserved Instances, Savings Plans y Enterprise Discount Programs debe planificar conjuntamente la hoja de ruta de los workloads, las negociaciones contractuales y las decisiones de ingeniería. No es una tarea exclusiva del equipo de FinOps, sino una disciplina compartida con compras y arquitectura. Las organizaciones que logran alinear estos tres ámbitos ahorran entre un 15 y un 30 % en costes puros de computación sin comprometer la calidad del servicio.
La medición de la madurez FinOps en 2026 comienza con los fundamentos y termina en la cultura de ingeniería. Las organizaciones maduras no solo documentan ahorros mensuales, sino la calidad de sus procesos de decisión: ¿con qué rapidez reacciona un equipo ante un pico de costes? ¿Con qué frecuencia se respaldan las decisiones de arquitectura con datos de costes? ¿Cuál es la tasa de acierto en el etiquetado dentro del flujo de despliegue? Estos indicadores meta revelan si FinOps se ha integrado realmente en la cultura de ingeniería o si sigue siendo un proyecto de dashboards.
Otro aspecto cada vez más relevante es la conexión con la gestión de producto. Las decisiones sobre funcionalidades tienen consecuencias en costes que solo se hacen evidentes durante la operación. Una nueva función de dashboard con analítica en tiempo real sobre varios terabytes de datos consume muchos más recursos que un informe estático. Los product owners que colaboran con los roles de FinOps pueden abordar estos trade-offs antes de la implementación. Quienes mantienen separados producto y FinOps acaban, al cabo de doce meses, con funcionalidades cuyos costes nadie había estimado previamente.
Para concluir, una reflexión que suele quedar relegada en muchos informes de FinOps: en 2026, FinOps no es una disciplina de optimización para quienes buscan ahorrar, sino una competencia básica de cualquier organización con alta dependencia de la nube. Las empresas que lo tratan como un proyecto secundario serán superadas por competidores que consideran el cost engineering como algo natural. La diferencia en cifras no se aprecia de inmediato, pero tras dieciocho meses de crecimiento en la nube, se traduce en dígitos de dos cifras en el cálculo del TCO. El momento adecuado para impulsar la madurez de FinOps no es el próximo año presupuestario, sino el trimestre en curso.
Preguntas frecuentes
¿Cuántas personas necesita un equipo FinOps en una mediana empresa?
Con un gasto mensual en la nube de entre 100.000 y 500.000 Euro, suele ser suficiente una persona como facilitadora, apoyada por arquitectos cloud y roles financieros existentes. A partir del millón de euros mensuales, merece la pena un equipo de dos o tres personas. Cuando se superan varios millones al mes, se aplica el modelo hub-and-spoke con campeones de FinOps por unidad de negocio.
¿Qué herramientas serán estándar en el stack FinOps en 2026?
Los exploradores de costes propios de los hyperscalers (AWS Cost Explorer, Azure Cost Management, GCP Billing) son la base. Sobre ellos operan plataformas especializadas como Flexera, CloudHealth, Apptio Cloudability o Vantage. Para los costes de Kubernetes, OpenCost se ha consolidado. La elección depende del tamaño, la combinación de nubes y la integración deseada con las herramientas de ingeniería existentes.
¿Cómo consigo que los equipos de ingeniería se tomen en serio los KPI de costes?
La clave está en la visibilidad en el día a día. Los datos de costes que aparecen en el mismo panel que el rendimiento y la disponibilidad se toman más en serio que los informes mensuales aislados. A ello se suma la integración en los OKR: un equipo cuyos objetivos trimestrales incluyen una dimensión de costes actúa de forma distinta a aquel en el que los costes son responsabilidad exclusiva de FinOps.
¿Cómo gestiono los costes de IA en la práctica de FinOps?
Los costes de IA requieren categorías propias. Los presupuestos de tokens por equipo, la utilización de GPU por carga de trabajo y las estrategias de enrutamiento de modelos son las palancas operativas. Los patrones clásicos de right-sizing tienen aquí menos impacto. Resulta útil una subpráctica específica de costes de IA dentro de la función FinOps, que colabore estrechamente con los ingenieros de ML.
¿Cuánto dura realísticamente el camino de Crawl a Run?
En la práctica, entre dos y tres años, dependiendo del tamaño y la cultura de la organización. Quien prometa menos de doce meses suele trabajar en quick-wins en la fase Walk y lo vende como Run. Quien planifique más de cuatro años pierde la atención de la dirección. El camino realista pasa por un progreso visible cada trimestre, con hitos claros por equipo.
Más del MBF Media Netzwerk
SaaS-Sprawl: consolidar el portfolio de aplicaciones en 2026
Fuente imagen de portada: Pexels / Hanna Pad (px:6801639)
