En los equipos DevOps modernos es habitual escuchar frases como: pensé que eso lo hacia infraestructura o el equipo de seguridad de la información debería encargarse de eso. La cultura DevOps promueve la responsabilidad compartida y la colaboración continua, pero cuando no existe una definición clara de roles, esa responsabilidad compartida puede transformarse en inseguridad. Cuando todos son responsables, muchas veces nadie lo es realmente.

La matriz RACI es un modelo de asignación de responsabilidades que permite definir quién ejecuta una tarea, quién responde por ella, quién debe ser consultado y quién debe ser informado.

DevOps promueve y fomenta la automatización y reduce la separación histórica entre áreas. Sin embargo, esta integración no elimina la necesidad de definir responsabilidades claras. De hecho, cuanto más autónomos son los equipos y más automatizados están los procesos, mayor es la necesidad de establecer ownership explícito. Sin una matriz de responsabilidades bien definida pueden surgir conflictos, retrasos en incidentes críticos, vulnerabilidades sin dueño claro o decisiones que se postergan porque nadie asume la responsabilidad final.

En DevSecOps la situación es aún más delicada. La seguridad ya no es un gate final antes de producción, sino una capacidad integrada en todo el ciclo de vida del software. Sin embargo, integrar seguridad no significa diluirla. Muchas organizaciones cometen el error de asumir que “la seguridad es responsabilidad de todos” sin establecer quién es accountable del riesgo. Cuando ocurre una brecha o una vulnerabilidad crítica queda expuesta, se descubre que nadie tenía realmente la responsabilidad final de gestionarla.

Uno de los puntos más importantes al aplicar RACI en DevSecOps es entender que debe existir un único accountable por actividad crítica. Puede haber varias personas ejecutando tareas, pero la responsabilidad final debe estar claramente asignada. En entornos ágiles y altamente automatizados, esta definición evita que los incidentes escalen sin dirección o que los controles de seguridad se conviertan en simples recomendaciones sin seguimiento.

RACI significa:

• R – Responsible (Responsable): quien ejecuta la tarea.
• A – Accountable (Aprobador / Dueño): quien asume la responsabilidad final y toma decisiones.
• C – Consulted (Consultado): quien debe ser consultado antes de ejecutar.
• I – Informed (Informado): quien debe estar al tanto del avance o resultado.

Sin embargo, implementar RACI en DevOps no significa introducir burocracia pesada. El error más común es convertir la matriz en un documento estático que nadie consulta. En un entorno dinámico, donde los equipos evolucionan y las arquitecturas cambian rápidamente, la matriz debe revisarse periódicamente y mantenerse alineada con la realidad operativa. No se trata de crear silos ni de frenar la colaboración, sino de clarificar el ownership dentro de esa colaboración.

DevOps no implica ausencia de estructura, sino estructura inteligente. La matriz RACI no contradice la filosofía DevOps, sino que la fortalece al proporcionar claridad en medio de la colaboración constante. En entornos donde la automatización avanza a gran velocidad y los despliegues son continuos, la claridad en las responsabilidades no es un lujo organizativo, sino un habilitador estratégico.