TL;DR La FinOps Foundation define seis principios que orientan la forma en que las organizaciones gestionan el gasto en tecnología y en la nube. La mayoría de los equipos puede recitarlos. Muchos menos logran traducirlos en las decisiones, estructuras y flujos de trabajo del día a día que hacen que la gestión financiera de la nube realmente funcione.
Los seis principios son: colaboración, valor de negocio, ownership, accesibilidad de los datos, habilitación centralizada y aprovechamiento del modelo de costo variable. La FinOps Foundation actualizó cuatro de los seis principios en 2025, la primera revisión desde 2019, para reflejar un alcance más amplio de "Cloud+" que va más allá de la nube pública. Las tres fases de FinOps (Inform, Optimize, Operate) traducen los principios en ejecución. Llevar los principios a la operación requiere una base de datos sólida, una función central de habilitación, showback antes de chargeback y ciclos continuos de optimización. DoiT ayuda a los equipos a cerrar la brecha entre principio y práctica con analítica unificada de costos, flujos de trabajo automatizados y arquitectos de nube certificados en FinOps.
La mayoría de los equipos que adoptan FinOps dedica tiempo real a estudiar los seis principios. Se alinean en las definiciones, consiguen el respaldo del liderazgo y arman una presentación. Luego vuelven a revisar las facturas de la nube a fin de mes.
Ahí es donde aparece la brecha entre FinOps como concepto y FinOps como práctica en marcha. Los principios describen el modelo operativo correcto para la gestión financiera de la nube, pero no describen cómo construirlo. Ese trabajo de traducción —del principio al proceso y de la intención al hábito organizacional— es donde la mayoría de los programas se estanca.
Esta guía cubre lo que significa cada principio en la práctica, cómo se conectan con las tres fases de FinOps y las acciones concretas de implementación que convierten los principios en resultados que tu equipo puede medir. Para profundizar en cómo estos principios se conectan con una estrategia de implementación más amplia, revisa la guía de DoiT sobre implementación de FinOps.
¿Qué son los principios de FinOps y de dónde vienen?
Los principios de FinOps son los valores fundacionales publicados por la FinOps Foundation, la organización sin fines de lucro y neutral respecto a proveedores que mantiene el FinOps Framework. Funcionan como el norte de cualquier práctica FinOps y orientan los comportamientos culturales y las decisiones organizacionales que determinan si la gestión financiera de la nube entrega valor duradero o se queda en lo performativo.
Los seis principios se elaboraron originalmente en 2019. En marzo de 2025, la FinOps Foundation los actualizó por primera vez como parte de una revisión más amplia del Framework, para reflejar cómo FinOps se ha expandido más allá de la nube pública hacia lo que la Foundation llama ahora un enfoque "Cloud+". Cuatro de los seis principios se reformularon para reconocer que quienes practican FinOps hoy gestionan SaaS, data centers, costos de licenciamiento y nube privada junto con el gasto tradicional en infraestructura. El significado central de cada principio se mantuvo intacto; el lenguaje se puso al día con la realidad de la práctica moderna.
Este artículo usa la redacción vigente de 2025.
Los 6 principios de FinOps en detalle
Cada principio implica una expectativa operativa concreta. Entender lo que el equipo de FinOps tiene que construir para respetarlo distingue a los equipos que aplican el framework de los que solo lo mencionan.
1. Los equipos deben colaborar
El costo de la nube es un problema interfuncional. Finanzas define los presupuestos, pero no puede interpretar los patrones de uso. Engineering entiende los workloads, pero tiene visibilidad limitada del impacto financiero. Producto es dueño de las decisiones de roadmap que impulsan el gasto. Cuando estos grupos operan en silos, las facturas de la nube crecen y nadie se hace cargo del resultado.
La colaboración como principio significa construir las condiciones estructurales para la toma de decisiones compartida: revisiones interfuncionales regulares, un vocabulario común sobre el costo de la nube y KPI compartidos que le den a finanzas y a engineering una base común para negociar tradeoffs. El trabajo del equipo de FinOps es facilitar esa conversación, no apropiársela en nombre de todos los demás. Los equipos que tratan la colaboración como una aspiración y no como un flujo de trabajo diseñado suelen quedarse cortos en los resultados de FinOps. Revisa cómo las mejores prácticas de FinOps sostienen la colaboración interfuncional a escala.
2. El valor de negocio guía las decisiones tecnológicas
Antes de 2025, este principio decía: "Las decisiones se guían por el valor de negocio de la nube". La actualización amplió el alcance. El cambio de "valor de la nube" a "guía las decisiones tecnológicas" indica que FinOps ahora aplica el mismo lente de valor a las suscripciones SaaS, los workloads de IA y la infraestructura de datos, no solo al cómputo en la nube.
En términos operativos, este principio significa que cada decisión relevante de infraestructura se conecta con un resultado de negocio. No "esta familia de instancias es más barata", sino "esta arquitectura reduce el costo por transacción manteniendo el SLA". Exige que los equipos construyan la capacidad de medición que hace explícitas esas conexiones: unit economics, costo por cliente, costo por feature, costo por entorno. Sin esa infraestructura, el principio se queda en lenguaje aspiracional.
3. Cada persona asume el ownership de su uso de tecnología
La actualización de 2025 reemplazó "uso de la nube" por "uso de tecnología", ampliando el modelo de ownership a todo el rango del gasto tecnológico que los equipos de FinOps gestionan hoy. La expectativa de fondo sigue siendo la misma: los ingenieros, los product managers y los equipos de aplicaciones deben entender las implicancias de costo de sus decisiones y sentirse responsables por ellas.
Lograrlo requiere dos cosas. Primero, visibilidad de costos a nivel de equipo: los ingenieros no pueden asumir el ownership de lo que no pueden ver. Los reportes de showback, la asignación de costos por equipo o producto y los dashboards de gasto en tiempo real le dan a cada persona la información necesaria para actuar. Segundo, permiso cultural: los equipos no van a optimizar el gasto si creen que la responsabilidad sobre el costo choca con la velocidad de entrega. El programa de FinOps tiene que dejar claro que el ownership significa tomar decisiones informadas, no vigilar los costos. Para más sobre estrategia de asignación de costos, revisa el desglose de DoiT sobre asignación de costos por entorno.
4. Los datos de FinOps deben ser accesibles, oportunos y precisos
La revisión de 2025 sumó "preciso" a este principio, que antes decía "accesible y oportuno". La adición refleja un dolor real de quienes practican FinOps: los equipos que reciben datos de costo a tiempo, pero llenos de errores de asignación o con etiquetas faltantes, no pueden actuar sobre ellos de forma efectiva. La precisión no está implícita en la accesibilidad.
Operativamente, este principio define los requisitos de la base de datos de FinOps: los datos de costo deben llegar rápido a los equipos que los necesitan (a diario o casi en tiempo real, no mensualmente), deben estar correctamente atribuidos a los equipos y productos que corresponden, y deben ser lo suficientemente completos para sustentar decisiones. Los datos tardíos generan respuestas reactivas. Los datos inexactos erosionan por completo la confianza en el programa de FinOps. Los datos faltantes crean puntos ciegos que se acumulan con el tiempo.
5. FinOps debe habilitarse de forma centralizada
Esta es una de las reformulaciones más significativas de 2025. El principio original decía "Un equipo centralizado impulsa FinOps". La actualización cambió a "FinOps debe habilitarse de forma centralizada", que según la FinOps Foundation captura mejor el enfoque bottom-up que emplea un FinOps efectivo.
La distinción importa. Un equipo centralizado que impulsa FinOps puede convertirse en un cuello de botella, otro grupo más haciendo el trabajo de costos en nombre de todos los demás. La habilitación central significa que la función de FinOps crea las herramientas, procesos, frameworks y expertise que los equipos distribuidos usan para gestionar el costo por sí mismos. Se construye capacidad en toda la organización en lugar de centralizar el trabajo. El equipo central se encarga de las negociaciones de Precios, la gestión de commitments, el tooling y la gobernanza. Los equipos de engineering se hacen cargo del right-sizing y del ciclo de vida de los recursos dentro de sus propios workloads.
6. Aprovecha el modelo de costo variable de la nube
Los costos de la infraestructura en la nube varían con el uso. A diferencia del gasto de capital fijo de la infraestructura on-premises, el gasto en la nube responde a decisiones que se toman a nivel de workload. Es una ventaja operativa enorme que muchas organizaciones no logran aprovechar del todo.
Aprovechar el modelo variable significa construir las prácticas de engineering y financieras que usan la variabilidad de forma estratégica: auto-scaling para ajustar la capacidad a la demanda, uso de commitments (Reserved Instances, Savings Plans, descuentos por uso comprometido) para reducir el precio en workloads predecibles, right-sizing para eliminar capacidad ociosa y mover workloads a configuraciones de menor costo cuando los requisitos del negocio lo permitan. Los equipos que tratan la nube como infraestructura fija se pierden la palanca de costo fundamental que hace valioso a FinOps. Para enfoques específicos por plataforma, revisa las mejores prácticas de FinOps para Google Cloud de DoiT.
Las tres fases de FinOps (Inform, Optimize, Operate) y cómo se conectan con los principios
La FinOps Foundation organiza la ejecución en tres fases: Inform, Optimize y Operate. Estas fases describen lo que hace el equipo de FinOps, mientras que los principios describen por qué y cómo debe hacerlo. Las fases traducen los principios en trabajo.
1. Inform: visibilidad, atribución y presupuestos
La fase Inform aborda directamente el principio de accesibilidad y precisión de los datos. Antes de que sea posible cualquier optimización, los equipos necesitan ver su gasto: qué existe, quién es su dueño, cuánto cuesta y cómo evoluciona. El trabajo en Inform incluye establecer la asignación de costos mediante tagging, construir reportes de showback que muestren el gasto por equipo, crear presupuestos y forecasts, y configurar detección de anomalías para detectar cambios inesperados de costo antes de que se agraven.
La mayoría de las organizaciones invierte poco aquí. Da por hecho que la visibilidad es un problema resuelto porque su proveedor de nube envía una factura. No lo es. Una factura detallada no es visibilidad de costos. La visibilidad de costos significa que cada equipo puede ver su gasto, correctamente atribuido, con la granularidad suficiente para actuar. Llegar ahí requiere gobernanza de tagging, lógica de asignación e inversión en tooling. Sin una base sólida de Inform, los esfuerzos de Optimize se topan con muros: los equipos intentan hacer right-sizing de workloads que no logran identificar por completo, o atienden anomalías de las que se enteran semanas después de que empezaron.
2. Optimize: right-sizing, commitments, automatización
La fase Optimize es donde el principio del modelo de costo variable se vuelve ejecutable. Con la visibilidad precisa a nivel de equipo que aporta Inform, los equipos pueden tomar decisiones estructuradas sobre la reducción del gasto: hacer right-sizing de recursos sobredimensionados, comprar commitments contra workloads base predecibles, eliminar recursos ociosos y huérfanos, e implementar scheduling para entornos que no son de producción. Para un desglose completo de las palancas de optimización, revisa las estrategias de optimización de costos en la nube de DoiT.
El trabajo en Optimize también lleva a la operación el principio de valor de negocio. Cada decisión de optimización debe conectarse con un encuadre de negocio: costo por workload, costo por transacción, costo como porcentaje de ingresos. Los equipos que optimizan sin esa conexión tienden a perseguir ahorros de forma aislada, a veces sacrificando rendimiento o confiabilidad a cambio de una reducción marginal de costo. El lente del valor de negocio mantiene las decisiones de optimización ancladas a los resultados que importan.
3. Operate: práctica continua e integración cultural
Operate es donde los principios de colaboración y ownership se vuelven hábitos culturales en lugar de compromisos declarados. En esta fase, FinOps pasa de proyecto a práctica: las revisiones de costo se vuelven parte habitual de los ciclos de planificación de engineering, las recomendaciones de optimización alimentan directamente el trabajo de los sprints y el gasto en la nube se conecta con las conversaciones del roadmap de producto.
La fase Operate también hace visible el principio de habilitación central en su forma más clara. Un equipo de FinOps que tiene que impulsar cada optimización de forma manual no escala. La fase Operate funciona cuando la función central de FinOps ya ha embebido suficiente capacidad en los equipos de engineering como para que la responsabilidad sobre el costo se sostenga por sí sola: los equipos identifican y atienden sus propias ineficiencias, escalan a la función central cuando hay decisiones complejas y participan en las revisiones interfuncionales como parte rutinaria de su forma de trabajar.
Cómo traducir los principios de FinOps en una práctica en marcha
Los principios no se convierten en resultados por sí solos. La siguiente secuencia de implementación construye la capa operativa que convierte los seis principios en una práctica medible. Para más contexto sobre el recorrido completo de implementación, revisa la guía de DoiT sobre implementación de la gestión financiera de la nube.
Construye primero la base de datos
Antes que cualquier otra cosa, establece una atribución de costos precisa y completa. Implementa un estándar de tagging que cubra cada recurso: equipo, entorno, aplicación, centro de costo. Aplícalo en el momento del provisionamiento, no como una campaña retroactiva de limpieza. Configura la lógica de asignación para la infraestructura compartida para que los costos caigan en los equipos correctos. Establece detección de anomalías con umbrales de alerta para que las sorpresas de costo salgan a la luz rápido.
Sin esta base, cada iniciativa FinOps aguas abajo opera con información incompleta. Las decisiones de right-sizing dejan afuera los workloads que no tienen tags. Las conversaciones de presupuesto fracasan porque finanzas y engineering manejan números distintos. La base de datos no es negociable y requiere inversión inicial antes de que los equipos vean resultados.
Establece la función central de habilitación (no un equipo de control de costos)
El mandato del equipo de FinOps importa. Plantéalo como una función que crea capacidad y genera valor, no como un equipo que hace cumplir presupuestos o que tiene la reducción de costos como meta. La distinción moldea cómo se relacionan los equipos de engineering con FinOps y determina si el principio de colaboración se afianza.
La función central se hace cargo del trabajo que exige expertise especializado y alcance organizacional: compra y gestión de commitments, negociación de Precios, selección y mantenimiento de tooling, política de gobernanza y facilitación de revisiones interfuncionales. Los equipos de engineering se hacen cargo de las decisiones a nivel de workload que requieren un conocimiento del dominio que el equipo de FinOps no tiene. Esa división de responsabilidades es lo que permite que la habilitación central escale.
Implementa showback antes que chargeback
Showback significa dar a los equipos visibilidad de su gasto en la nube sin consecuencia financiera. Chargeback significa asignar esos costos directamente a los presupuestos de equipo o producto. Empieza con showback.
Hacer chargeback antes de que los equipos tengan datos de costo confiables y un ownership establecido genera una fricción que daña la credibilidad del programa de FinOps. Los equipos objetan los métodos de asignación, disputan facturas que no entienden y pierden confianza en los datos. El showback construye la familiaridad y la calidad de datos necesarias para que el chargeback funcione. También saca a la luz preguntas de ownership que hay que resolver antes de que la responsabilidad financiera se afiance. La mayoría de las organizaciones que se apuran al chargeback pasa el año siguiente relitigando las mismas disputas de asignación que podría haber resuelto en la fase de showback.
Haz que la optimización sea continua, no trimestral
Las revisiones manuales trimestrales no van al ritmo al que cambian los entornos en la nube. Se provisionan servicios nuevos. Los workloads escalan. Las configuraciones se desvían. Una auditoría trimestral detecta lo que pasó hace tres meses. Para entonces, el costo del problema ya se materializó.
La optimización continua significa detección automatizada de oportunidades de right-sizing, recursos ociosos y anomalías de costo, canalizada hacia una cadencia regular de revisión con engineering. Las recomendaciones aparecen en un ciclo semanal o de sprint, se priorizan junto al trabajo de features y se les hace seguimiento hasta completarse. Este flujo lleva a la operación tanto el principio de accesibilidad de los datos como el del modelo de costo variable: usa datos oportunos para tomar decisiones permanentes que aprovechan la flexibilidad que ofrece la nube. Para un set de referencia de métricas que seguir, revisa la guía de KPIs de FinOps de DoiT y la visión general más amplia sobre herramientas de FinOps.
Conecta el gasto en la nube con los resultados de negocio
Los unit economics anclan el principio del valor de negocio en algo medible. Costo por usuario activo, costo por transacción, gasto en la nube como porcentaje de ingresos, costo por feature desplegada: estas métricas traducen el gasto en infraestructura a un lenguaje que producto, finanzas y los stakeholders ejecutivos entienden y usan para tomar decisiones.
Construir unit economics requiere combinar datos de costo con datos de producto y uso: volúmenes de transacciones, cantidad de usuarios, eventos de despliegue. La mayoría de los programas de FinOps posterga este trabajo porque exige integración entre sistemas. Los equipos que hacen la integración de forma consistente toman mejores decisiones de tradeoff, porque pueden responder "¿cuánto cuesta realmente este cambio de arquitectura por cliente?" en lugar de operar sobre totales mensuales agregados.
Errores comunes al aplicar los principios de FinOps
Hay varios patrones que parecen FinOps pero no logran entregar los resultados que describen los principios.
Confundir reporting con FinOps. Construir dashboards y distribuir reportes de gasto no es una práctica FinOps. El reporting es el prerrequisito. FinOps empieza cuando los equipos usan esos datos para tomar decisiones que cambian los resultados. Las organizaciones que invierten fuerte en tooling de reporting y luego se saltan el trabajo de gobernanza y optimización han construido la infraestructura de una práctica que en realidad no han iniciado.
Tratar la reducción de costos como el objetivo. La reducción de costos es un resultado del FinOps efectivo, no el objetivo. El objetivo es generar valor de negocio a partir del gasto en tecnología: los recursos correctos, corriendo los workloads correctos, al punto de costo más eficiente para el rendimiento y la confiabilidad requeridos. Los equipos que apuntan directamente a la reducción de costos suelen optimizar de formas que comprometen la confiabilidad, socavan la confianza de engineering o generan ahorros de corto plazo que cuestan más de mantener de lo que valían.
Invertir de menos en la función central de habilitación. Los programas de FinOps con un solo analista y una hoja de cálculo no pueden entregar la capacidad que exigen los principios. La gestión de commitments, la gobernanza, la facilitación interfuncional, el tooling y la respuesta a anomalías requieren capacidad dedicada. Las organizaciones que dejan corta la función central y luego expresan frustración con los resultados de FinOps han confundido el principio de habilitación central con la idea de que FinOps debe ser barato de operar.
Ignorar la confianza de engineering. Si los ingenieros viven FinOps como vigilancia de costos, alertas de presupuesto, revisiones obligatorias y fricción añadida al provisionamiento, se desconectan. Los principios de colaboración y ownership requieren que los equipos de engineering quieran participar. Eso exige que el equipo de FinOps se relacione como un partner que quita obstáculos y aporta eficiencia, no como una función de compliance que agrega overhead. La confianza toma tiempo en construirse y se puede perder rápido si las primeras acciones visibles del programa de FinOps se sienten punitivas.
De los principios de FinOps a la práctica de FinOps
Los seis principios de FinOps describen el destino. Definen cómo se ve una práctica madura de gestión financiera de la nube cuando funciona: colaboración interfuncional, decisiones conectadas al valor de negocio, ownership distribuido, datos confiables, capacidad habilitada centralmente y aprovechamiento sistemático del modelo de costo variable de la nube.
Llegar ahí requiere la capa operativa que va debajo: una base de tagging y asignación, un equipo de FinOps con el mandato correcto, un rollout que empieza por el showback, flujos de optimización continua y unit economics que conecten el gasto con las métricas de negocio que los ejecutivos efectivamente siguen. Nada de eso ocurre automáticamente. Requiere inversión, secuenciación y compromiso sostenido entre engineering, finanzas y operaciones.
DoiT acompaña este recorrido con analítica unificada de costos, flujos de optimización automatizados y arquitectos de nube certificados en FinOps que trabajan codo a codo con tu equipo para convertir el insight en ejecución. Si ya estás listo para pasar del principio a la práctica, habla con un experto de DoiT FinOps.
Preguntas frecuentes sobre los principios de FinOps
¿Cuántos principios de FinOps hay?
Hay seis principios de FinOps, según los define la FinOps Foundation. Son: los equipos deben colaborar; el valor de negocio guía las decisiones tecnológicas; cada persona asume el ownership de su uso de tecnología; los datos de FinOps deben ser accesibles, oportunos y precisos; FinOps debe habilitarse de forma centralizada; y aprovecha el modelo de costo variable de la nube. Estos seis principios se aplican a todo el rango del gasto tecnológico que gestionan los equipos de FinOps, incluyendo nube pública, SaaS, data centers e infraestructura de nube privada.
¿Cuál es la diferencia entre los principios y las fases de FinOps?
Los principios de FinOps son los valores fundacionales que definen cómo debe funcionar FinOps, qué representa la práctica y hacia dónde se dirige. Las fases de FinOps (Inform, Optimize, Operate) describen cómo los equipos ejecutan contra esos valores. Los principios responden a la pregunta de qué tipo de práctica construir. Las fases responden a cómo construirla y qué trabajo hacer en cada etapa de madurez. Un equipo puede estar en la fase Inform mientras trabaja simultáneamente hacia los seis principios, usando el trabajo de visibilidad para llevar a la operación los principios de accesibilidad de datos y colaboración antes de pasar a la optimización.
¿De dónde vienen los principios de FinOps?
Los seis principios de FinOps vienen de la FinOps Foundation, la organización sin fines de lucro y neutral respecto a proveedores que mantiene el FinOps Framework. La Foundation es la autoridad reconocida en la práctica de FinOps y sus principios reflejan el aporte de una comunidad global de practicantes. Los principios se elaboraron originalmente en 2019 y se actualizaron por primera vez en 2025 para reflejar cómo FinOps se ha expandido más allá de la nube pública hacia un enfoque Cloud+ más amplio. La FinOps Foundation también publica guías detalladas sobre cada principio, junto con indicadores de madurez, vistas específicas por persona y capacidades de apoyo que ayudan a los equipos a aplicarlos en la práctica.text