Gobernanza y cumplimiento
Quién puede decidir qué, con qué reglas y con qué evidencia; y qué obligaciones (legales, contractuales, organizativas, técnicas) tiene que cumplir el proyecto y su producto. Sin burocracia, y desde el principio.
- Distinguir gobernanza de gestión y describir los cinco elementos de la gobernanza.
- Distinguir buena gobernanza de burocracia usando sus principios (proporcionalidad, trazabilidad…).
- Clasificar las obligaciones de cumplimiento (legales, contractuales, organizativas, técnicas, IA) y llevar una obligación por la cadena requisito → diseño → implementación → evidencia → verificación.
- Situar las normas clave: RGPD, NIS2, AI Act (y saber qué exigen a un proyecto software), ISO/IEC 38500, 27001, 27701.
Tema 2, diap. 79-88. Objetivo del tema: "conocer los conceptos de gobernanza y cumplimiento en proyectos software". La diap. 88 cita "otras normas relevantes: RGPD, NIS2 y AI Act" sin desarrollarlas; aquí se explican (ampliación) a nivel de lo que un ingeniero debe saber para gestionar un proyecto. Las preguntas típicas: "¿esto es gobernanza o gestión?", "¿quién debe decidir X?", "¿de qué tipo es esta obligación?", "¿por qué el cumplimiento no debe dejarse para el final?".
1. Gobernanza ≠ gestión
La idea central del bloque:Tema 2, diap. 80.
- Gobernanza: establece quién tiene autoridad, qué decisiones deben tomarse y bajo qué reglas.
- Gestión: ejecuta el proyecto dentro de ese marco.
La gobernanza define: responsabilidades, autoridad y escalado, mecanismos de decisión, controles, y transparencia y rendición de cuentas.
Ejemplo en TusBus: que "cualquier cambio de alcance que supere 2 semanas o 10.000 € lo aprueba el comité de dirección del ayuntamiento" es gobernanza. Que el JP analice el impacto de la petición de pagos y la lleve al comité con una recomendación es gestión. En la lección 2 ya viste un caso: en PRINCE2 el comité define las tolerancias (gobernanza) y el JP gestiona dentro de ellas. La norma ISO/IEC 38500 (gobernanza de las TI, citada en la bibliografía de las diapositivas) lo resume en tres verbos para el órgano de gobierno: evaluar, dirigir, supervisar; la gestión planifica, construye, ejecuta y opera.Ampliación. ISO/IEC 38500:2024, Governance of IT for the organization. El PMBOK 8 incorpora la Gobernanza como dominio de desempeño (lección 2).
Por qué hace falta
Un proyecto toma decisiones que afectan a negocio y usuarios, presupuesto y recursos, seguridad y privacidad, datos, propiedad intelectual, proveedores, calidad y operación, y cumplimiento normativo. Sin gobernanza no hay responsabilidad: las decisiones se dispersan, las responsabilidades son difusas y es difícil saber quién decidió y, sobre todo, por qué.Tema 2, diap. 81. (Recuerda el ADR de la lección 6: es una herramienta de gobernanza de las decisiones de arquitectura.)
2. Los cinco elementos de la gobernanza
Cada uno responde a una pregunta:Tema 2, diap. 82.
- Autoridad: ¿quién puede aprobar?
- Responsabilidades: ¿quién ejecuta?
- Decisiones: ¿qué decisiones requieren escalado?
- Controles: ¿qué debe verificarse?
- Información: ¿qué información necesita cada responsable?
Los ejemplos de las diapositivas:
| Decisión | Responsable | Por qué ahí |
|---|---|---|
| Cambio de alcance | Sponsor / comité | Afecta a coste, plazo y valor: lo decide quien financia |
| Decisión arquitectónica | Equipo técnico | Es quien tiene el conocimiento (y la registra en un ADR) |
| Aceptación del producto | Cliente / Product Owner | Es quien valida que cubre la necesidad |
| Riesgo crítico | PM + responsable correspondiente | El propietario vigila; el PM integra y escala si hace falta |
| Tratamiento de datos | Responsable designado | Obligación legal (RGPD): responsable del tratamiento, delegado de protección de datos |
Una herramienta práctica para escribir esto (ampliación) es la matriz RACI: para cada decisión o entregable, quién es Responsable de hacerlo, quién Aprueba y rinde cuentas (Accountable, uno solo), a quién se Consulta y a quién se Informa. La regla de oro: una sola A por fila. Si dos personas "aprueban", ninguna lo hace.
3. Gobernanza no significa burocracia
El contraste de las diapositivas:Tema 2, diap. 83.
- Mala gobernanza: "Para cambiar una línea de código necesitamos tres reuniones y cuatro firmas."
- Buena gobernanza: "Las decisiones importantes tienen responsable, criterios, evidencia y trazabilidad."
Principios:
| Principio | Qué significa |
|---|---|
| Proporcionalidad | El control es proporcional a lo que está en juego: una errata en un texto no pasa por comité; un cambio en el tratamiento de datos de ubicación, sí |
| Claridad | Todo el mundo sabe quién decide qué |
| Transparencia | Las decisiones y sus razones son visibles para quien debe conocerlas |
| Trazabilidad | Se puede reconstruir qué se decidió, quién, cuándo y por qué |
| Responsabilidad | Cada decisión tiene un responsable que rinde cuentas |
| Adaptación al riesgo | Más control donde más riesgo hay (conecta con la gestión de riesgos, lecciones 12-13) |
4. Qué es el cumplimiento (compliance)
Compliance = cumplimiento de las obligaciones aplicables al proyecto y al producto. Las obligaciones proceden de varias fuentes:Tema 2, diap. 84.
| Tipo | Incluye | TusBus |
|---|---|---|
| Legales | Protección de datos, propiedad intelectual, normativa sectorial | RGPD (geolocalización de usuarios), accesibilidad del sector público, Esquema Nacional de Seguridad |
| IA | Regulación de la inteligencia artificial | Si se añade un chatbot de atención: obligación de transparencia (AI Act) |
| De contrato | Requisitos del cliente, SLA, licencias, condiciones de proveedores | SLA de disponibilidad 99,5 %; términos de uso de la API de mapas; licencias de las bibliotecas open source |
| De organización | Políticas internas, procedimientos, estándares | Política de seguridad del ayuntamiento, guía de estilo de la consultora |
| Técnicas | Estándares, requisitos de seguridad, controles de calidad | WCAG 2.1 AA, OWASP ASVS, cobertura mínima de pruebas |
Y la frase clave: cumplir no es simplemente "pasar una auditoría". Una auditoría comprueba una muestra en un momento; el cumplimiento es que la obligación se respete de verdad, siempre, y que se pueda demostrar.
Dos obligaciones "pequeñas" que se olvidan mucho en proyectos software:
- Licencias open source: una biblioteca con licencia copyleft (p. ej. GPL) puede obligar a publicar el código del producto que la incluye; una permisiva (MIT, Apache 2.0) sólo exige mantener el aviso de copyright. Elegir una dependencia es también una decisión de cumplimiento.
- Términos de servicios de terceros: la API de mapas puede prohibir cachear datos o limitar el uso comercial.
5. El cumplimiento desde el principio
La cadena que propone el temario:Tema 2, diap. 85.
Con el ejemplo de las diapositivas, "los datos personales deben estar protegidos", hay que plantearse desde el principio cinco preguntas. Aplicado a TusBus:
| Pregunta | TusBus |
|---|---|
| ¿Qué exige exactamente? | RGPD: base legal para tratar la ubicación, minimización, información al usuario, seguridad adecuada; probablemente una evaluación de impacto (EIPD) por tratar ubicación |
| ¿Qué decisión arquitectónica lo garantiza? | Calcular "paradas cercanas" en el móvil sin enviar la ubicación al servidor; si se envía, no almacenarla. Registrado en un ADR |
| ¿Cómo se implementa? | Permiso de ubicación sólo "mientras se usa la app"; cifrado en tránsito; sin identificadores persistentes |
| ¿Qué evidencia demuestra el cumplimiento? | EIPD firmada, ADR, registro de actividades de tratamiento, resultados de pruebas, logs que muestran que no se guarda la ubicación |
| ¿Cómo se verifica? | Pruebas automáticas que comprueban que el API no recibe coordenadas; revisión del DPO; auditoría |
Esto conecta directamente con la gestión del proyecto: requisitos (lección 4, como RNF/requisito legal), trazabilidad (la matriz enlaza la obligación con diseño, código y prueba), arquitectura (lección 6), pruebas y calidad (lección 15). Un requisito legal sin prueba en la matriz de trazabilidad es un riesgo grave (lección 5).
Consecuencias del incumplimiento
Retrasos, repetición de trabajo, costes adicionales, bloqueo de una entrega, incidentes de seguridad, problemas contractuales, daño reputacional. Por eso compliance → riesgo del proyecto, y no debería considerarse únicamente al final.Tema 2, diap. 86. Descubrir en la semana 15 que TusBus necesitaba una EIPD que nadie hizo puede bloquear la publicación justo antes de la feria: es el coste del error creciente (lección 1) aplicado al cumplimiento.
6. Gobernanza en ágil y DevOps
La gobernanza no desaparece al trabajar con ágil: cambia su forma.Tema 2, diap. 87.
| Antes | Plan → aprobación → desarrollo → auditoría |
|---|---|
| Ahora | Planificación continua → desarrollo → controles automatizados → feedback → decisión |
Ejemplos de controles de gobernanza integrados en el trabajo diario:
- Definition of Done con requisitos de seguridad (una historia no está "hecha" si no pasa el análisis de seguridad).
- Revisiones de código (nadie integra solo: control de "cuatro ojos").
- Controles de calidad automáticos.
- Análisis de dependencias (vulnerabilidades y licencias).
- CI/CD con gates (puertas que bloquean el despliegue si no se cumplen condiciones).
- Evidencias generadas automáticamente (los logs del pipeline son la evidencia de que se probó).
- Auditoría y trazabilidad (commit → PR → revisión → build → despliegue).
La automatización DevSecOps permite integrar chequeos y pruebas de compliance en el flujo de desarrollo (a veces se llama compliance as code). Es la forma de tener gobernanza proporcionada sin burocracia: el control existe, pero no requiere una reunión (lección 18).
7. Las normas que hay que conocer
La bibliografía de las diapositivas cita normas ISO y "otras normas relevantes: RGPD, NIS2 y AI Act".Tema 2, diap. 88. Lo que sigue es ampliación: no hace falta saber artículos de memoria, sí qué exige cada una a un proyecto software.
Estándares ISO (voluntarios, certificables)
| Norma | Sobre qué |
|---|---|
| ISO/IEC 38500 | Gobernanza de las TI en la organización (evaluar, dirigir, supervisar) |
| ISO 31000 | Gestión del riesgo (de ahí la definición de riesgo, lección 12) |
| ISO/IEC 27001 | Sistema de gestión de la seguridad de la información (SGSI); certificable |
| ISO/IEC 27701 | Extensión de la 27001 para la gestión de la privacidad |
RGPD · Reglamento General de Protección de Datos
Reglamento (UE) 2016/679, aplicable desde mayo de 2018 (en España, complementado por la LOPDGDD).Ampliación. Texto: EUR-Lex 2016/679. Guías en español: AEPD. Lo que más afecta a un proyecto software:
- Principios: licitud, limitación de la finalidad, minimización (sólo los datos necesarios), exactitud, limitación del plazo de conservación, seguridad, y responsabilidad proactiva (demostrar que cumples).
- Protección de datos desde el diseño y por defecto (art. 25): la privacidad es un requisito desde el inicio, no un parche. Es exactamente la cadena de la sección 5.
- Evaluación de impacto (EIPD, art. 35) cuando el tratamiento implica alto riesgo (p. ej., geolocalización a gran escala).
- Notificación de brechas a la autoridad en 72 horas (art. 33).
- Derechos de los interesados (acceso, rectificación, supresión, portabilidad…): el sistema debe permitir atenderlos.
- Sanciones de hasta 20 millones de euros o el 4 % de la facturación mundial anual.
NIS2 · Ciberseguridad de entidades esenciales e importantes
Directiva (UE) 2022/2555; los Estados debían transponerla en octubre de 2024.Ampliación. EUR-Lex 2022/2555. Amplía mucho la NIS original:
- Se aplica a entidades esenciales e importantes de sectores críticos (energía, transporte, salud, banca, infraestructura digital, administración pública, proveedores de servicios TIC gestionados…). Una app de transporte público para un gran ayuntamiento puede quedar dentro o ser proveedora de alguien que lo está.
- Exige medidas de gestión de riesgos de ciberseguridad, incluida la seguridad de la cadena de suministro (lección 12) y del desarrollo y mantenimiento de sistemas.
- Notificación de incidentes significativos: alerta temprana en 24 h, notificación en 72 h, informe final en un mes.
- Responsabilidad de la dirección: los órganos de dirección deben aprobar y supervisar las medidas, y pueden responder personalmente. Es gobernanza en estado puro.
AI Act · Reglamento de Inteligencia Artificial
Reglamento (UE) 2024/1689, en vigor desde agosto de 2024, con aplicación escalonada. Su lógica es un enfoque basado en el riesgo:Ampliación. artificialintelligenceact.eu (explorador del texto, incluido el Digital Omnibus).
| Nivel | Ejemplos | Qué exige |
|---|---|---|
| Inaceptable (prohibido) | Puntuación social, manipulación que cause daño, ciertos usos de identificación biométrica | Prohibido desde el 2 de febrero de 2025 |
| Alto riesgo | IA en selección de personal, educación, crédito, infraestructuras críticas, productos regulados (dispositivos médicos…) | Gestión de riesgos, calidad de datos, documentación técnica, registros, supervisión humana, robustez y ciberseguridad, evaluación de conformidad |
| Riesgo limitado (transparencia) | Chatbots, contenido generado o manipulado (deepfakes) | Informar de que se interactúa con una IA; marcar el contenido generado |
| Riesgo mínimo | Filtros de spam, IA en videojuegos | Nada específico (códigos de conducta voluntarios) |
Además regula los modelos de IA de uso general (GPAI, como los grandes modelos de lenguaje), con obligaciones aplicables desde agosto de 2025. Calendario actualizado: el llamado Digital Omnibus sobre IA, en vigor desde julio de 2026, aplazó las obligaciones de alto riesgo al 2 de diciembre de 2027 (usos del anexo III) y al 2 de agosto de 2028 (IA integrada en productos regulados, anexo I). Las prohibiciones y las obligaciones de los modelos de uso general no cambiaron. Si te preguntan fechas, ten en cuenta que pueden variar: lo estable es el enfoque por niveles de riesgo.
Las sanciones pueden llegar a 35 millones de euros o el 7 % de la facturación mundial por prácticas prohibidas.
Otras normas que te encontrarás (ampliación)
- Cyber Resilience Act (Reglamento (UE) 2024/2847): requisitos de ciberseguridad para productos con elementos digitales, incluido el software, durante todo su ciclo de vida (gestión de vulnerabilidades, actualizaciones de seguridad). Las obligaciones de notificación se aplican desde septiembre de 2026 y el resto, desde diciembre de 2027.
- Esquema Nacional de Seguridad (ENS, Real Decreto 311/2022): obligatorio para los sistemas de las administraciones públicas españolas y sus proveedores. TusBus, al ser para un ayuntamiento, probablemente debe cumplirlo.
- Accesibilidad: el Real Decreto 1112/2018 obliga a que las webs y apps del sector público sean accesibles (norma UNE-EN 301549, alineada con WCAG). Otra obligación legal para TusBus.
- "Gobernanza y gestión son lo mismo": la gobernanza define las reglas; la gestión ejecuta dentro de ellas.
- "Más controles = mejor gobernanza": la buena gobernanza es proporcional al riesgo.
- "Cumplimiento = pasar la auditoría": es cumplir de verdad y poder demostrarlo siempre.
- "El cumplimiento se revisa al final, antes de publicar": desde el principio (requisito → … → verificación); al final es carísimo.
- "En ágil no hay gobernanza": cambia de forma; controles automatizados, DoD, gates.
- "Las licencias de software son un tema legal, no del proyecto": son obligaciones contractuales que condicionan qué dependencias puedes usar.
- "El AI Act prohíbe la IA de alto riesgo": la permite con requisitos estrictos; prohíbe sólo los usos de riesgo inaceptable.
Práctica
¿Gobernanza o gestión?
- Establecer que los cambios de más de 10.000 € los aprueba el comité
- Analizar el impacto de una petición de cambio y preparar la recomendación
- Definir quién puede aceptar formalmente el producto
- Reasignar tareas porque una persona está sobrecargada
- Exigir que toda decisión de arquitectura quede registrada con su justificación
Clasifica cada obligación según su origen.
- Obtener una base legal para tratar la ubicación de los usuarios
- Garantizar una disponibilidad del 99,5 % según el SLA firmado
- Seguir la política interna de gestión de contraseñas de la empresa
- Cumplir el nivel AA de las pautas de accesibilidad WCAG
- Mantener el aviso de copyright de una biblioteca con licencia MIT
¿Cuál es un ejemplo de buena gobernanza según el temario?
- Cualquier cambio de código requiere la firma de cuatro responsables
- No hay reglas para no frenar al equipo, y cada uno decide por su cuenta
- Las decisiones importantes tienen responsable, criterios, evidencia y traza
- Todas las decisiones, grandes y pequeñas, pasan por el mismo comité
El equipo de TusBus descubre en la semana 15 de 16 que, al tratar la ubicación, necesitaba una evaluación de impacto de protección de datos. ¿Qué principio del temario se incumplió?
- Abordar el cumplimiento desde el principio, como requisito
- Más controles implican siempre una mejor gobernanza del proyecto
- La gobernanza en ágil desaparece y la sustituye la autogestión
- El cumplimiento consiste en superar una auditoría al terminar
¿Qué controles son ejemplos de gobernanza en un entorno ágil/DevOps?
- Una Definition of Done que incluye pasar el análisis de seguridad
- Un pipeline que bloquea el despliegue si una dependencia tiene una vulnerabilidad crítica
- Un documento de 200 páginas aprobado una vez al inicio y no revisado
- Revisión de código obligatoria antes de integrar cada cambio
- Evidencias de pruebas generadas automáticamente en cada build
Asocia cada obligación con la norma de la que procede.
- Notificar una brecha de datos personales a la autoridad en 72 horas
- Enviar una alerta temprana de un incidente significativo en 24 horas
- Informar a los usuarios de que están hablando con un chatbot
- Aplicar protección de datos desde el diseño y por defecto
- Gestionar la seguridad de la cadena de suministro en una entidad esencial
Verdadero o falso: "El AI Act prohíbe desarrollar sistemas de IA de alto riesgo, como los usados en la selección de personal".
- Verdadero
- Falso
TusBus quiere añadir un asistente de IA que responda dudas de los usuarios sobre líneas y horarios. Desde el punto de vista de gobernanza y cumplimiento, ¿qué tendrías que plantear antes de desarrollarlo? Menciona al menos tres cosas.
Repaso espaciado · lecciones 2, 12, 16
En PRINCE2, el comité fija tolerancias y el JP decide dentro de ellas. Esto es un ejemplo de…
- Gestión de riesgos
- Gobernanza y gestión separadas
- Control de la calidad
- Planificación gradual
¿Cuál es la segunda fase del modelo de Tuckman?
- Normalización (norming)
- Desempeño (performing)
- Formación (forming)
- Conflicto (storming)
Para profundizar
Para el RGPD aplicado a desarrollo: la Guía de Privacidad desde el Diseño de la AEPD (en español, pensada para ingenieros). Para el AI Act: resumen de alto nivel del AI Act (inglés). Para la gobernanza de proyectos: PMBOK 8, dominio de Gobernanza.
Toma tu proyecto de prácticas y escribe: (1) una tabla de decisiones con su responsable, (2) tres obligaciones de cumplimiento de tipos distintos, y (3) para una de ellas, la cadena requisito → diseño → implementación → evidencia → verificación. Pídele a un asistente que lo critique. Si dudas de cuánto detalle de RGPD/NIS2/AI Act espera el profesor, pregúntalo en tutoría.