¿Qué es una matriz RACI? Definición, plantilla y ejemplos (2026)
La guía completa para aclarar roles, eliminar la confusión y entregar proyectos sin bloqueos inesperados
¿Qué es una matriz RACI?
Una matriz RACI es una matriz de asignación de responsabilidades que vincula cada tarea de un proyecto con las personas que realizarán, aprobarán, asesorarán y serán informadas sobre ese trabajo. El acrónimo significa Responsable, Aprobador (Accountable), Consultado e Informado: cuatro niveles distintos de participación que, cuando se asignan correctamente, eliminan la fuente más común de fracaso en los proyectos: la ambigüedad sobre quién hace qué.
Las matrices RACI se muestran normalmente como una cuadrícula. Las tareas o entregables se enumeran en las filas de la izquierda, y los roles o individuos específicos en las columnas de la parte superior. En cada intersección, una sola letra (R, A, C o I) indica la participación de esa persona en esa tarea. El resultado es un recurso visual de una página que responde, para cada parte del trabajo, a las cuatro preguntas que un gestor de proyectos escucha con más frecuencia: quién está haciendo esto, quién lo aprueba, quién debe opinar y quién debe estar al tanto.
El marco se originó en la gestión de procesos industriales en la década de 1950 y fue formalizado como herramienta de gestión de proyectos por el Project Management Institute en la década de 1980. Hoy en día se utiliza en el desarrollo de software, la construcción, la sanidad, el marketing, la fabricación, el sector público y la consultoría. Las variantes modernas incluyen RACIO (añadiendo "fuera del ciclo"), RASCI (añadiendo Soporte) y DACI (Conductor, Aprobador, Contribuidor, Informado para trabajos centrados en decisiones), pero el RACI original sigue siendo la forma más enseñada y adoptada.
Una matriz RACI bien construida convierte las suposiciones implícitas sobre la propiedad en compromisos explícitos y documentados. Cuando una parte interesada pregunta por qué algo se retrasó, se puede señalar la matriz y tener una conversación precisa sobre qué persona desempeñaba qué rol y dónde ocurrió el fallo. Sin una matriz RACI, la misma conversación deriva en señalamientos y revisionismo histórico.
Qué significan R, A, C e I — Con ejemplos
Responsable (R) es la persona que realmente realiza el trabajo. Son quienes escriben el código, redactan el documento, ejecutan las pruebas, construyen la funcionalidad. Puede haber más de una persona Responsable en una sola tarea; por ejemplo, un ingeniero frontend y uno backend podrían ser ambos Responsables de entregar una funcionalidad que abarque ambas capas. El rol de Responsable trata sobre la ejecución: manos en el teclado, manos en las herramientas.
Aprobador (A) es la única persona que es dueña del resultado y firma la finalización. Esta es la regla más importante en RACI: debe haber exactamente una persona Aprobadora por tarea. Si dos personas son Aprobadoras, nadie lo es; cuando algo sale mal, ambos asumirán que el otro se está encargando. El Aprobador puede o no hacer el trabajo por sí mismo, pero es aquel cuyo nombre aparece junto al entregable cuando se envía, y es cuya revisión desbloquea el siguiente paso. Para el lanzamiento de una funcionalidad, el rol de Aprobador suele pertenecer al gerente de producto o al líder de ingeniería.
Consultado (C) es una persona cuya opinión es requerida antes de que el trabajo se finalice. Las relaciones de consulta son bidireccionales: la persona Responsable busca activamente sus comentarios y ellos los proporcionan activamente. Los roles comunes de Consultado incluyen expertos en la materia, revisores de seguridad, asesores legales, diseñadores que revisan el trabajo de ingeniería y equipos de éxito del cliente que asesoran sobre cambios orientados al usuario. La consulta ocurre antes de que el entregable se cierre, no después.
Informado (I) es una persona que necesita saber que el trabajo se ha realizado, pero no necesita opinar de antemano. Las relaciones de información son unidireccionales: reciben notificaciones o resúmenes después de hitos clave. Los roles comunes de Informado incluyen ejecutivos que siguen el progreso a nivel de hoja de ruta, equipos adyacentes cuyos planes dependen del tuyo y clientes que reciben notas de la versión. Confundir Consultado con Informado es el segundo error más común de RACI (después de tener múltiples Aprobadores); arrastra a las personas a ciclos de revisión de los que no deberían formar parte.
Un ejemplo hará concretas estas distinciones. Considere la tarea "Implementar servicio de autenticación en producción". El ingeniero backend senior es Responsable porque realmente realiza el despliegue. El gerente de ingeniería es el Aprobador porque firma el lanzamiento y es el dueño de cualquier incidente en producción. El arquitecto de seguridad es Consultado porque se requiere su revisión del flujo de autenticación antes del despliegue. El equipo de soporte al cliente es Informado porque necesita saber que el despliegue ocurrió para responder a las preguntas de los clientes, pero no bloquea el despliegue. Cuatro roles, cuatro niveles de participación, cero ambigüedad.
Cuándo usar una matriz RACI (y cuándo no)
Las matrices RACI son más valiosas en proyectos multifuncionales donde varios equipos o roles deben coordinarse para entregar un resultado. El desencadenante clásico es la pregunta "¿quién es el dueño de esto?" formulada más de una vez en una sola reunión. Si su equipo se encuentra debatiendo la propiedad en tiempo real, una matriz RACI se amortizará en una semana.
Use una matriz RACI para lanzamientos de nuevos proyectos, lanzamientos de funcionalidades importantes, reestructuraciones organizacionales, programas de cumplimiento y auditoría, incorporación de proveedores y cualquier iniciativa que involucre a cinco o más personas en dos o más equipos. La matriz también es invaluable al incorporar nuevos miembros al equipo: les da un mapa de una página sobre con quién hablar sobre qué.
Evite la matriz RACI para trabajos pequeños, bien entendidos y de un solo equipo. Una tarea de dos personas donde ambos conocen obviamente sus roles no se beneficia de un marco de cuatro letras. El gasto de crear y mantener la matriz supera su valor cuando el entendimiento implícito ya es claro. Use el juicio: si el equipo tuviera que inventar la matriz solo para completarla, probablemente sea la herramienta equivocada para ese nivel de trabajo.
Evite las matrices RACI en trabajos altamente experimentales donde los roles cambian legítimamente de una semana a otra. La investigación y el descubrimiento en etapas tempranas a menudo se benefician de una propiedad más laxa donde quien asume una tarea es su dueño. Fijar los roles demasiado pronto puede suprimir el tipo de ejecución oportunista de la que depende el trabajo exploratorio. Recurra a RACI una vez que el trabajo se haya estabilizado en un plan de proyecto estructurado con entregables y plazos.
Cómo construir una matriz RACI en 7 pasos
Paso 1: Liste cada entregable, tarea o decisión del proyecto. Sea lo suficientemente detallado como para que cada fila represente una pieza de trabajo que podría asignarse a una persona específica, típicamente de una a dos semanas de esfuerzo. Evite filas vagas como "Gestión de proyectos" o "Comunicación"; en su lugar, use elementos específicos como "Aprobar presupuesto final" o "Firmar contrato con el proveedor". Un proyecto típico de tamaño medio tiene de 15 a 40 filas.
Paso 2: Liste todos los roles o personas con nombre en la parte superior de la matriz. Use roles cuando el equipo sea grande y las personas puedan rotar (Gerente de Proyecto, Ingeniero Principal, Diseñador, Líder de QA). Use nombres individuales cuando el equipo sea pequeño y estable. Incluya roles externos cuando sea relevante (Cliente, Proveedor, Asesor Legal, Auditor Externo) para que los traspasos entre organizaciones sean explícitos.
Paso 3: Para cada fila, identifique a la única persona Aprobadora. Este es el paso más difícil en el trabajo con RACI y donde la mayoría de las matrices fallan. Oblíguese a elegir exactamente a una persona. Si dos personas parecen ser Aprobadoras, pregunte: cuando este entregable esté terminado, ¿el recordatorio del calendario de quién dirá "firmar versión final"? ¿El nombre de quién estará junto a la casilla de verificación completada? La respuesta es su Aprobador.
Paso 4: Identifique a las personas Responsables. Puede haber más de una. Para cada tarea, pregunte: ¿quién hará el trabajo real? Enumere a todos los que ejecutarán, no solo a los que liderarán la ejecución. En una tarea de rediseño de UI, tanto el diseñador que crea las maquetas como el ingeniero que las implementa son Responsables.
Paso 5: Identifique a las partes Consultadas. Pregunte: ¿de quién debemos tener su opinión antes de que esto sea final? Sea implacablemente minimalista aquí. Cada rol de Consultado añade tiempo al ciclo porque la persona Responsable debe esperar su revisión. Si el trabajo puede entregarse con una persona siendo Informada en lugar de Consultada, márquela como Informada. El valor predeterminado debe ser Informado; Consultado es la excepción que requiere justificación.
Paso 6: Identifique a las partes Informadas. Pregunte: ¿quién necesita saber que esto sucedió, incluso si no necesitan opinar? Esta suele ser una lista más larga que la de Consultados. Incluya a ejecutivos, líderes de equipos adyacentes, equipos orientados al cliente y cualquier persona cuyos planes se crucen con el resultado.
Paso 7: Valide la matriz con el equipo. Repásela fila por fila en una sesión de trabajo. Problemas comunes que detectará: filas sin Aprobador (asigne uno), filas con dos Aprobadores (negocie quién es el dueño real), filas con demasiadas personas Consultadas (bájelas a Informadas) y roles en columnas que no aparecen en ninguna fila (elimínelos o añada el trabajo que deberían estar haciendo). Después de la validación, guarde la matriz en un lugar donde todos puedan consultarla y actualícela siempre que cambie el alcance.
Ejemplo de matriz RACI: Lanzamiento de un producto de software
Considere un lanzamiento de un producto de software de seis semanas con los siguientes roles: Gerente de Producto, Líder de Ingeniería, Diseñador, Líder de QA, Gerente de Marketing, Líder de Éxito del Cliente y CEO. Los entregables incluyen la aprobación del alcance de la funcionalidad, revisión del diseño técnico, aprobación del diseño de la interfaz de usuario, ejecución de la construcción y pruebas, revisión de seguridad, lanzamiento del programa beta, lanzamiento de la campaña de marketing y puesta en marcha final.
La aprobación del alcance de la funcionalidad tiene al Gerente de Producto como Aprobador, al Líder de Ingeniería y al Diseñador como Responsables (aportan información sobre el alcance), al CEO como Consultado (el lanzamiento es lo suficientemente estratégico como para requerir la opinión ejecutiva sobre lo que entra o sale) y al Gerente de Marketing y al Líder de Éxito del Cliente como Informados.
La revisión del diseño técnico tiene al Líder de Ingeniería como Aprobador y Responsable (es el dueño y quien escribe el diseño), al Gerente de Producto y al Líder de QA como Consultados, y a otros roles como Informados. La aprobación del diseño de la interfaz de usuario (UI) invierte la propiedad: el Diseñador es el Aprobador, el Gerente de Producto es Consultado y el Líder de Ingeniería es Informado (ya que implementará lo que el diseñador especifique, pero no bloquea el diseño).
La ejecución de la construcción y las pruebas enumera a varias personas Responsables (cada ingeniero que realiza el trabajo de implementación), mientras que el Líder de Ingeniería permanece como Aprobador. El Líder de QA es Responsable de la parte de ejecución de las pruebas. La revisión de seguridad tiene a un Arquitecto de Seguridad (añadido a la lista de roles como una columna de solo Consultado) como el guardián, con el Líder de Ingeniería como Aprobador para resolver cualquier hallazgo.
La fila final del lanzamiento (go-live) es la más funcionalmente cruzada del gráfico: el Gerente de Producto es el Aprobador, todos los roles de ingeniería y QA son Responsables, el Gerente de Marketing y el Líder de Éxito del Cliente son Consultados (su preparación afecta la decisión de lanzamiento) y el CEO es Informado. Esta es la fila donde el gráfico demuestra su valor: cuando llega el día del lanzamiento, cada persona sabe exactamente qué puerta custodia y quién necesita su luz verde.
Errores comunes en la matriz RACI que se deben evitar
Tener múltiples personas Aprobadoras es el error más común y dañino. Cuando dos personas son Aprobadoras, ninguna se adueñará del resultado y ambas asumirán que la otra es quien lidera. Oblíguese a elegir exactamente a una. Si el trabajo es genuinamente compartido, divídalo en dos filas donde cada persona sea Aprobadora de su mitad.
Demasiadas personas Consultadas es el segundo error más común. Cada rol Consultado añade días o semanas de espera para la revisión. Una fila con cinco roles Consultados tardará cinco veces más que una con uno solo. Audite sus asignaciones de Consultados trimestralmente y baje de categoría a todos aquellos cuyo rol de Consultado no modifique activamente el entregable.
Confundir roles con personas crea fragilidad. Si la matriz dice que el Ingeniero Principal es el Aprobador de la revisión de seguridad, el gráfico sigue funcionando cuando el ingeniero principal cambia de puesto; solo hay que actualizar el mapeo de rol a persona. Si la matriz dice que Sara es la Aprobadora, se rompe en el momento en que Sara cambia de equipo. Use roles cuando el proyecto vaya a sobrevivir a personas específicas e individuos cuando el proyecto sea corto y el personal sea estable.
Dejar que la matriz se quede obsoleta es el modo de fallo a cámara lenta. Los gráficos RACI son más útiles cuando reflejan la realidad actual, pero es fácil ignorarlos una vez que el proyecto empieza a avanzar. Cree el hábito de revisar y actualizar la matriz en cada hito importante del proyecto: transiciones de fase, cambios de alcance, incorporaciones o salidas del equipo. Una matriz de hace dos meses que nadie ha tocado es peor que no tener ninguna, porque induce activamente a error.
Omitir el paso de validación del equipo permite que los errores iniciales se propaguen. La primera versión de una matriz RACI casi siempre es incorrecta en detalles sutiles. La columna de Aprobador que asignó en soledad no coincide con la forma en que el equipo piensa realmente sobre la propiedad de las tareas. Revise siempre la matriz con el equipo en una sesión de trabajo real antes de declararla definitiva. La discusión en sí misma es la mitad del valor: incluso si no cambia ninguna fila, el equipo sale de la reunión con un entendimiento compartido de quién es dueño de qué.
Combinación de matrices RACI con diagramas de Gantt en Instagantt
Las matrices RACI responden al quién, mientras que los diagramas de Gantt responden al cuándo. Las dos herramientas son complementarias, no alternativas. Un gran plan de proyecto cuenta con ambas: una matriz RACI que define la propiedad de cada entregable y un diagrama de Gantt que sitúa esos entregables en una línea de tiempo con dependencias e hitos.
En Instagantt, puede reflejar su estructura RACI configurando a un asignatario en cada tarea como el propietario principal (la persona Aprobadora), añadiendo colaboradores adicionales para los Responsables y usando los comentarios o las descripciones de las tareas para capturar a las partes Consultadas e Informadas. El cronograma de Gantt hace que el trabajo RACI sea visible a lo largo del tiempo: cuando un Aprobador tiene múltiples entregables agrupados en la misma semana, la vista de carga de trabajo los marca antes de que el cuello de botella se materialice.
La función de instantánea pública de Instagantt le permite compartir ambas vistas con las partes interesadas sin darles acceso de edición. Envíe a las partes Consultadas un enlace de instantánea unos días antes de que se necesite su aportación; envíe a las partes Informadas una vista de solo hitos que puedan escanear en segundos. Combinar el mapa de propiedad RACI con una línea de tiempo de Gantt en vivo convierte la comunicación del proyecto de una reunión recurrente en un enlace de autoservicio.
Para programas más grandes, los libros de trabajo de Instagantt le permiten agrupar múltiples proyectos en un solo espacio de trabajo. Los roles RACI que defina para cada proyecto se consolidan en una vista de portafolio donde puede ver, por ejemplo, que la misma persona Aprobadora está en la ruta crítica en tres proyectos simultáneos. Ese tipo de visibilidad de propiedad entre proyectos es imposible en una matriz RACI de hoja de cálculo estática y es uno de los argumentos más sólidos para gestionar RACI dentro de una herramienta de proyectos en lugar de hacerlo de forma paralela.
Pruebe el plan gratuito de Instagantt para crear su primer diagrama de Gantt consciente de RACI. Importe su lista de tareas desde una hoja de cálculo, asigne propietarios utilizando las definiciones RACI anteriores, añada dependencias entre entregables y comparta una instantánea pública con su equipo. La combinación de propiedad explícita y línea de tiempo visible convierte la matriz de un artefacto de documentación en una herramienta de planificación diaria.