Cuando escribimos sobre el modelo de gobernanza de la nube Azure en abril de 2024, los fundamentos ya estaban claros. Entorno multiproveedor, reparto de responsabilidades, control de costes y seguridad. Dos años después, los mismos aspectos siguen siendo centrales, pero el juego ha cambiado. NIS2 ha entrado en vigor en Finlandia y afecta a un grupo sorprendentemente amplio de organizaciones. Las facturas de la nube ahora también se revisan en la mesa del CFO, y «la nube es flexible» ya no es una respuesta suficiente.En este artículo actualizado, el ‘consigliere’ de Above IT Juha Kari repasa cómo es un modelo de gobernanza de Azure razonable, es decir, Azure governance, en 2026.
El entorno multiproveedor sigue siendo la realidad de Azure
Azure es un entorno multiproveedor para la mayoría de las empresas. La dirección de TI se encarga de las partes principales, un partner proporciona el Data Warehouse, otro gestiona la plataforma de integración, un tercero se responsabiliza de las identidades y se ocupa de los servicios de Modern Workplace. En el conjunto caben proveedores de aplicaciones cuyas soluciones se migraron a Azure en algún momento, y nadie recuerda realmente por qué.
Esta es una situación de partida habitual, y no es un problema en sí misma. Se convierte en problema cuando nadie ha documentado cómo todos estos actores operan juntos en el entorno. El modelo de gobernanza es un manual común al que se puede hacer referencia cuando un nuevo partner se incorpora. Sin él, el entorno deriva fácilmente hacia un estado en el que, al cabo de unos años, nadie se atreve a tocar nada.
La responsabilidad sigue recayendo en quien escucha
Las suscripciones de Azure están a nombre de su dirección de TI, la factura le llega a usted y la responsabilidad de seguridad es suya. Aunque un partner cree un recurso, la responsabilidad de su existencia y coste recae en última instancia en usted. Mi consejo de cinco estrellas para todas las organizaciones que utilizan la nube Azure es: para que el barco no haga agua, un aspecto básico es definir presupuestos para las suscripciones de Azure.
Un buen partner solicita directrices y las cumple, pero debe tener directrices que seguir. Si no existe un modelo de gobernanza, el partner actúa según su mejor criterio. Generalmente es razonable, pero cuando la misma situación se repite con tres partners diferentes, en el entorno hay tres formas distintas de hacer lo mismo. La tarea de la dirección de TI es establecer el marco, y el modelo de gobernanza proporciona un vocabulario común para ello.
Qué incluye el modelo de gobernanza en 2026
La estructura técnica no ha cambiado mucho en un par de años. El modelo de gobernanza describe típicamente la estructura de los management groups y la organización de las suscripciones, la arquitectura de red, los roles RBAC y los principios para su asignación, las Azure Policies con las que se guía la creación y configuración de recursos, las convenciones de nomenclatura y etiquetado, las copias de seguridad y la continuidad, la base técnica de seguridad, así como el reparto de responsabilidades entre la dirección de TI, los partners y los equipos internos. El propio Cloud Adoption Framework de Microsoft proporciona un buen marco de referencia para esto, pero un manual puro no es suficiente tal cual para el uso de nadie.
El año 2026 ha traído más bien un cambio de énfasis. El peso de la seguridad ha aumentado con NIS2 y el control de costes se ha convertido en un requisito más concreto. A continuación, repaso estos dos aspectos con más detalle.
FinOps en Azure: costes bajo control
La nube se vendió en su momento como flexible y económica. La flexibilidad es cierta, pero la economía solo se materializa si alguien realmente controla los costes. Si no se controlan, la factura crece silenciosamente hasta que en algún momento alguien hace preguntas para las que no hay buenas respuestas.
La sección FinOps del modelo de gobernanza responde a tres preguntas. A dónde va el dinero es una cuestión de etiquetado: si los recursos no están etiquetados al menos con propietario, centro de costes e identificador de entorno, la generación de informes de costes no funciona de forma creíble para el negocio. Si el dinero se gasta de forma razonable es una cuestión de revisión: en todos los entornos Azure funcionan máquinas de prueba que quedaron encendidas, SKU sobredimensionadas, snapshots obsoletas y discos cuyas máquinas virtuales se eliminaron. La limpieza de estos elementos suele suponer un ahorro anual de decenas de miles de euros en un entorno de tamaño medio. Y la previsión de costes es una cuestión de Reservations y Savings Plans, con los que se puede reducir significativamente el precio de las cargas de trabajo estables siempre que se sepa predecir el uso.
Detalle útil. FinOps no es solo un asunto de TI. En un buen modelo de gobernanza, los costes se reparten al negocio de modo que cada unidad vea su parte de la factura de la nube. Cuando la factura de la nube está en la propia línea presupuestaria, el comportamiento adquiere una disciplina completamente diferente.
NIS2 y modelo de gobernanza de Azure: reparto de responsabilidades en orden
La directiva NIS2 se incorporó a la legislación nacional finlandesa como ley de ciberseguridad en abril de 2025. Afecta a un grupo claramente más amplio de organizaciones de lo que muchos aún comprenden. Las obligaciones son proporcionales al tamaño y criticidad de la organización, pero se exige algo a todos los que están dentro del ámbito de la directiva.
Desde la perspectiva del modelo de gobernanza de Azure, NIS2 introduce tres requisitos prácticos. La gestión de la cadena de proveedores significa que debe saber quién procesa sus datos y con qué permisos. Si cinco partners diferentes tienen roles de Owner y se otorgaron hace un par de años, la situación de partida no es buena. La gestión de incidentes y la generación de informes significa que el registro, las alertas y los procesos de respuesta deben estar en orden, porque las incidencias significativas deben notificarse a las autoridades en plazos determinados. Y la responsabilidad de la dirección significa que el modelo de gobernanza no debería ser solo un documento técnico, sino incluir también un resumen comprensible para la dirección sobre cómo se gestionan los riesgos del entorno de nube.
Para un auditor rara vez basta con decir que el asunto está resuelto. Hay que poder mostrarle un documento.
Por dónde empezar con el modelo de gobernanza de Azure
Como hace dos años, la respuesta es la misma. No conviene intentar hacer un documento perfecto de 50 páginas de una vez. Lleva meses, nadie tiene ganas de leerlo y al cabo de un año ya está obsoleto.
Un buen punto de partida son 10 páginas, no 50. En ellas se describe la estructura de suscripciones, los principios RBAC, la política de etiquetado, el ritmo de seguimiento de costes, el nivel mínimo de seguridad y la matriz de responsabilidades de las áreas más importantes. Esto se amplía a medida que las necesidades se concretan. Igual de importante es que alguien se responsabilice del mantenimiento del modelo y que la dirección esté comprometida con ello. Un modelo de gobernanza sin aprobación de alto nivel es solo una recomendación, a la que es difícil apelar con un partner.
Nube gestionada como servicio
A lo largo de los años hemos construido nuestra propia estructura de modelo de gobernanza preparada, que utilizamos como base con todos nuestros clientes de nube gestionada. Se adapta a las necesidades de cada organización, pero el núcleo permanece igual. En la implementación definimos juntos las responsabilidades, llevamos las políticas técnicas al entorno y después apoyamos a su dirección de TI y a sus partners en el día a día.
Si desea hablar sobre cómo debería construirse o actualizarse su modelo de gobernanza, reserve una conversación de 15 minutos en mi calendario, ¡y empezamos!
Como asesor de confianza de su dirección de TI, nuestra tarea es garantizar que el entorno Azure funcione para sus necesidades y las de sus partners con costes razonables y seguridad sostenible. Trabajando juntos, es posible.