Cómo diseñar una matriz de permisos por acción y no por herramienta

Empieza por las acciones que cambian el negocio. Las herramientas suelen ofrecer roles amplios como administrador, editor o usuario, pero esas etiquetas no explican el impacto real. Una persona puede necesitar consultar clientes sin poder exportarlos, preparar una campaña sin activarla o revisar una factura sin modificarla. La matriz debe comenzar con verbos concretos: leer, crear, editar, aprobar, publicar, eliminar, transferir y configurar. Así, el permiso deja de depender del nombre del software y se vincula con una consecuencia que el equipo entiende.

Separa información, decisión y ejecución. No todas las capacidades tienen el mismo riesgo. Leer un registro permite obtener contexto; proponer un cambio genera una recomendación; ejecutar transforma el sistema. Diseña columnas distintas para cada nivel y evita que una necesidad de consulta termine entregando autoridad de modificación. Esta separación también sirve para agentes y automatizaciones: pueden preparar respuestas o borradores mientras una persona conserva la aprobación final. El diseño reduce errores sin obligar a que todo proceso permanezca completamente manual.

Clasifica el impacto antes de asignar acceso. Para cada acción, define qué ocurriría si se ejecuta de forma incorrecta. Un cambio reversible en una etiqueta tiene impacto bajo; una transferencia, eliminación masiva o publicación pública puede ser alta. Utiliza una escala breve y visible, por ejemplo bajo, medio y crítico, con criterios comunes. El nivel debe considerar dinero, datos personales, reputación, continuidad y obligaciones contractuales. Esta clasificación permite exigir controles proporcionales en lugar de aplicar la misma fricción a cualquier tarea.

Asigna responsables y condiciones. Una celda de la matriz no debería decir únicamente permitido o bloqueado. Añade quién puede realizar la acción, bajo qué condición, con qué límite y quién revisa. Un vendedor puede conceder un descuento hasta cierto porcentaje; una automatización puede enviar un recordatorio si el cliente aceptó comunicaciones; finanzas puede liberar un pago después de verificar dos documentos. Las condiciones convierten el acceso en una regla operativa y reducen interpretaciones improvisadas cuando el equipo está bajo presión.

Incluye excepciones con fecha de caducidad. Los proyectos urgentes suelen generar permisos temporales que después permanecen abiertos. Registra cada excepción con motivo, responsable, fecha de inicio y vencimiento. El sistema debería recordar la revisión o retirar el acceso automáticamente cuando sea posible. Si una excepción se renueva varias veces, probablemente representa una necesidad permanente que debe diseñarse correctamente. La caducidad evita que la estructura real de permisos quede escondida detrás de favores y soluciones provisionales acumuladas.

Revisa la matriz con evidencia de uso. Una tabla perfecta en papel puede no coincidir con el trabajo cotidiano. Cada trimestre, compara permisos asignados con acciones ejecutadas, incidentes, bloqueos y solicitudes de acceso. Retira capacidades que no se utilizan y analiza tareas que requieren constantes elevaciones. El objetivo no es minimizar acceso de forma ciega, sino otorgar la menor autoridad suficiente para cumplir el resultado. La revisión debe incluir personas, cuentas compartidas, integraciones, robots y credenciales técnicas.

Prueba un proceso completo de principio a fin. Selecciona una operación relevante, como publicar una campaña o resolver un reembolso, y recórrela usando la matriz. Comprueba quién lee, quién prepara, quién aprueba, quién ejecuta y cómo queda registrado. Simula también una ausencia o un error para confirmar que existe reemplazo y reversión. Al finalizar, corrige permisos, límites y responsabilidades. Una matriz útil no es un inventario estático: es un mapa verificable de cómo la autoridad se mueve dentro del negocio.