8 Min. tiempo de lectura<\/p>\n
FinOps sale en 2026 de la fase de dashboards. El 78 % de las pr\u00e1cticas de FinOps est\u00e1n ya integradas en la organizaci\u00f3n del CTO o el CIO, no en el \u00e1rea de control de gesti\u00f3n. Esto significa para los equipos de cloud: la pregunta ya no es si los costes de la nube son visibles, sino con qu\u00e9 rigor las decisiones de ingenier\u00eda se basan realmente en los datos de costes. El paso del seguimiento de costes a la disciplina de ingenier\u00eda determinar\u00e1 si la inversi\u00f3n en FinOps genera el retorno prometido.<\/strong><\/p>\n Lo esencial en pocas palabras<\/p>\n Relacionado<\/span>Costes de inferencia de IA: FinOps para cargas de trabajo con GPU<\/a> \/<\/span> Opus 4.7 vs. GPT-5.4: Inferencia en la nube europea 2026<\/a><\/p>\n 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\u00f3 los ahorros prometidos, porque la visibilidad no se traduc\u00eda autom\u00e1ticamente en acci\u00f3n. Un equipo de ingenier\u00eda que detecta un pico de costes en un cl\u00faster de Kubernetes un lunes debe saber qu\u00e9 puede cambiar, qui\u00e9n debe aprobarlo y qui\u00e9n libera el tiempo para hacerlo. Si esta cadena no existe, el dashboard se queda en un informe sin consecuencias.<\/p>\n La segunda ola (ya en el mainstream en 2026) integra FinOps directamente en los flujos de trabajo de ingenier\u00eda. 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\u00f3n de PR, y las decisiones de arquitectura se presentan con un c\u00e1lculo de TCO. La diferencia no est\u00e1 en la herramienta, sino en la definici\u00f3n de lo que un ingeniero debe entregar. Se trata de un cambio cultural que, en muchas organizaciones, requiere entre tres y cuatro trimestres.<\/p>\n Otro aspecto que gana visibilidad en la segunda ola de FinOps es la integraci\u00f3n con el equipo de ingenier\u00eda de plataformas. Si una organizaci\u00f3n 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\u00edmites de presupuesto y se\u00f1ales 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\u00e1s eficiente de integrar FinOps en el d\u00eda a d\u00eda, pero tambi\u00e9n la m\u00e1s exigente, ya que requiere una organizaci\u00f3n de ingenier\u00eda de plataformas que funcione.<\/p>\n 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\u00e1cticas. Un peque\u00f1o equipo central establece est\u00e1ndares, herramientas y formaciones, mientras que la ejecuci\u00f3n operativa recae en los equipos de producto. El modelo *Hub-and-Spoke*, con un 21 %, es com\u00fan 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\u00eda muy maduras.<\/p>\n La elecci\u00f3n del modelo depende del tama\u00f1o de la infraestructura en la nube y de la cultura de ingenier\u00eda. 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\u00f1\u00eda con diez millones al mes no puede escalar con un equipo central sin un modelo de federaci\u00f3n. El error m\u00e1s 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.<\/p>\n Lo que a menudo se subestima en la estructura del equipo es el papel del socio financiero. Un equipo FinOps sin conexi\u00f3n directa con el *controlling* pierde influencia en la disciplina presupuestaria. Por el contrario, un *controlling* sin contacto t\u00e9cnico con FinOps se convierte r\u00e1pidamente en un gestor de presupuestos en papel, que no entiende las estructuras reales de costes de la nube. Los *setups* exitosos en 2026 contar\u00e1n 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\u00f3n.<\/p>\n Otro aspecto estructural es la clara delimitaci\u00f3n entre FinOps y *Procurement*. FinOps no decide por s\u00ed solo sobre *commits*, *Reserved Instances* o acuerdos plurianuales. Estas decisiones requieren al departamento de compras, la gesti\u00f3n financiera y, a menudo, la direcci\u00f3n. FinOps proporciona la base de datos y los c\u00e1lculos 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\u00e9cnico. Ambas situaciones generan problemas. Una delimitaci\u00f3n clara de roles ahorra, en la pr\u00e1ctica, muchas reuniones y acelera notablemente las decisiones, ya que las v\u00edas de escalada est\u00e1n definidas de antemano. La colaboraci\u00f3n se convierte en una rutina operativa.<\/p>\n D\u00f3nde se estancan las pr\u00e1cticas FinOps en 2026<\/p>\n Qu\u00e9 caracteriza a las pr\u00e1cticas FinOps maduras<\/p>\n La integraci\u00f3n con los OKRs de ingenier\u00eda es un aspecto que en 2026 tendr\u00e1 mucho m\u00e1s \u00e9xito que en 2024. Quien vea FinOps como un freno de costes encontrar\u00e1 resistencia. Quien trate FinOps como una m\u00e9trica de eficiencia junto a rendimiento, disponibilidad y velocidad, contar\u00e1 con equipos que se eval\u00faan a s\u00ed mismos con estas cifras. La diferencia en el lenguaje es peque\u00f1a, pero el impacto en la aceptaci\u00f3n es grande.<\/p>\n 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\u00eda m\u00e1s concretas. Crawl es concienciaci\u00f3n: el equipo comprende de d\u00f3nde proceden los costes y qu\u00e9 servicios son caros. Paralelamente, queda claro qui\u00e9n opera cada recurso. Duraci\u00f3n t\u00edpica: entre tres y seis meses. Walk es propiedad: el equipo asume la responsabilidad de los recursos que opera. Las primeras decisiones de optimizaci\u00f3n se toman a nivel de equipo. Duraci\u00f3n: entre seis y doce meses despu\u00e9s del inicio de Crawl. Run es optimizaci\u00f3n: las decisiones basadas en datos forman parte del d\u00eda a d\u00eda, y se aplican pol\u00edticas automatizadas. Las decisiones sobre costes se integran en el flujo normal de trabajo de ingenier\u00eda.<\/p>\n En la pr\u00e1ctica, 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\u00f1os para consolidar Walk. Los niveles de madurez se asignan por equipo, no por organizaci\u00f3n. La funci\u00f3n central de FinOps mide y reporta, pero la decisi\u00f3n sobre la velocidad la toma el responsable de ingenier\u00eda correspondiente.<\/p>\n Una pregunta frecuente es cu\u00e1ndo llegan las organizaciones a Run. Los datos del informe *State of FinOps* muestran que en 2026 la proporci\u00f3n de pr\u00e1cticas Run ronda un tercio, con tendencia al alza. La mayor\u00eda sigue trabajando en la fase Walk, con objetivos de optimizaci\u00f3n claros, pero sin una integraci\u00f3n completa en la ingenier\u00eda. La transici\u00f3n 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.<\/p>\n Dos temas est\u00e1n transformando la pr\u00e1ctica de FinOps en 2026, m\u00e1s all\u00e1 de las categor\u00edas tradicionales de costes en la nube. El primero es la gesti\u00f3n de costes de IA. Las instancias de GPU, la facturaci\u00f3n 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\u00e1sicos, y la volatilidad de precios, mayor. Tambi\u00e9n difieren las palancas de optimizaci\u00f3n. Quien integre los workloads de IA en los procesos FinOps existentes subestimar\u00e1 sus particularidades.<\/p>\n El segundo tema es FinOps de sostenibilidad. La vinculaci\u00f3n entre optimizaci\u00f3n de costes y reducci\u00f3n de CO\u2082 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\u00e1ctica, no una opci\u00f3n.<\/p>\n Un tercer factor que cobra mayor relevancia en 2026 es la integraci\u00f3n con el aprovisionamiento y la gesti\u00f3n contractual. Quien quiera aprovechar al m\u00e1ximo 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\u00eda. No es una tarea exclusiva del equipo de FinOps, sino una disciplina compartida con compras y arquitectura. Las organizaciones que logran alinear estos tres \u00e1mbitos ahorran entre un 15 y un 30 % en costes puros de computaci\u00f3n sin comprometer la calidad del servicio.<\/p>\n La medici\u00f3n de la madurez FinOps en 2026 comienza con los fundamentos y termina en la cultura de ingenier\u00eda. Las organizaciones maduras no solo documentan ahorros mensuales, sino la calidad de sus procesos de decisi\u00f3n: \u00bfcon qu\u00e9 rapidez reacciona un equipo ante un pico de costes? \u00bfCon qu\u00e9 frecuencia se respaldan las decisiones de arquitectura con datos de costes? \u00bfCu\u00e1l 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\u00eda o si sigue siendo un proyecto de dashboards.<\/p>\n Otro aspecto cada vez m\u00e1s relevante es la conexi\u00f3n con la gesti\u00f3n de producto. Las decisiones sobre funcionalidades tienen consecuencias en costes que solo se hacen evidentes durante la operaci\u00f3n. Una nueva funci\u00f3n de dashboard con anal\u00edtica en tiempo real sobre varios terabytes de datos consume muchos m\u00e1s recursos que un informe est\u00e1tico. Los product owners que colaboran con los roles de FinOps pueden abordar estos trade-offs antes de la implementaci\u00f3n. Quienes mantienen separados producto y FinOps acaban, al cabo de doce meses, con funcionalidades cuyos costes nadie hab\u00eda estimado previamente.<\/p>\n Para concluir, una reflexi\u00f3n que suele quedar relegada en muchos informes de FinOps: en 2026, FinOps no es una disciplina de optimizaci\u00f3n para quienes buscan ahorrar, sino una competencia b\u00e1sica de cualquier organizaci\u00f3n con alta dependencia de la nube. Las empresas que lo tratan como un proyecto secundario ser\u00e1n 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\u00edgitos de dos cifras en el c\u00e1lculo del TCO. El momento adecuado para impulsar la madurez de FinOps no es el pr\u00f3ximo a\u00f1o presupuestario, sino el trimestre en curso.<\/p>\n 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\u00f3n 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.<\/p>\n<\/details>\n 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\u00f3n depende del tama\u00f1o, la combinaci\u00f3n de nubes y la integraci\u00f3n deseada con las herramientas de ingenier\u00eda existentes.<\/p>\n<\/details>\n La clave est\u00e1 en la visibilidad en el d\u00eda a d\u00eda. Los datos de costes que aparecen en el mismo panel que el rendimiento y la disponibilidad se toman m\u00e1s en serio que los informes mensuales aislados. A ello se suma la integraci\u00f3n en los OKR: un equipo cuyos objetivos trimestrales incluyen una dimensi\u00f3n de costes act\u00faa de forma distinta a aquel en el que los costes son responsabilidad exclusiva de FinOps.<\/p>\n<\/details>\n Los costes de IA requieren categor\u00edas propias. Los presupuestos de tokens por equipo, la utilizaci\u00f3n de GPU por carga de trabajo y las estrategias de enrutamiento de modelos son las palancas operativas. Los patrones cl\u00e1sicos de right-sizing tienen aqu\u00ed menos impacto. Resulta \u00fatil una subpr\u00e1ctica espec\u00edfica de costes de IA dentro de la funci\u00f3n FinOps, que colabore estrechamente con los ingenieros de ML.<\/p>\n<\/details>\n En la pr\u00e1ctica, entre dos y tres a\u00f1os, dependiendo del tama\u00f1o y la cultura de la organizaci\u00f3n. Quien prometa menos de doce meses suele trabajar en quick-wins en la fase Walk y lo vende como Run. Quien planifique m\u00e1s de cuatro a\u00f1os pierde la atenci\u00f3n de la direcci\u00f3n. El camino realista pasa por un progreso visible cada trimestre, con hitos claros por equipo.<\/p>\n<\/details>\n\n
Qu\u00e9 implica en concreto el salto del seguimiento de costes a la disciplina de ingenier\u00eda<\/h2>\n
Estructuras de equipo que funcionar\u00e1n en 2026<\/h2>\n
\n
\n
Las fases Crawl-Walk-Run aplicadas de forma concreta<\/h2>\n
Los temas de costes que llegan nuevos a la agenda en 2026<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfCu\u00e1ntas personas necesita un equipo FinOps en una mediana empresa?<\/strong><\/summary>\n
\u00bfQu\u00e9 herramientas ser\u00e1n est\u00e1ndar en el stack FinOps en 2026?<\/strong><\/summary>\n
\u00bfC\u00f3mo consigo que los equipos de ingenier\u00eda se tomen en serio los KPI de costes?<\/strong><\/summary>\n
\u00bfC\u00f3mo gestiono los costes de IA en la pr\u00e1ctica de FinOps?<\/strong><\/summary>\n
\u00bfCu\u00e1nto dura real\u00edsticamente el camino de Crawl a Run?<\/strong><\/summary>\n
M\u00e1s del MBF Media Netzwerk<\/h2>\n