Aprobaciones y salvaguardas

Una aprobación es una decisión, y una decisión sin información es un sello. Para que sirva, la solicitud debe llevar lo que la persona necesita para decidir: qué acción se pide y sobre qué objetivo, la evidencia que la motiva, si se puede deshacer y qué cuesta equivocarse. Y debe tener un vencimiento: si nadie contesta a tiempo, el flujo no ejecuta por defecto; se escala o se cancela.

Otro requisito es la independencia. La persona que aprueba no puede ser la misma que lanzó la acción, o la aprobación deja de ser un control y pasa a ser un trámite.

La política escrita dice qué acciones exigen aprobación. La configuración de la plataforma dice cuáles la tienen puesta. Cuando difieren, manda la configuración, porque es lo que se ejecuta. Esta diferencia no la detecta nadie por casualidad: se encuentra cruzando las dos tablas, acción por acción.

Abre el laboratorio y compara politica_de_aprobacion con configuracion_de_playbooks.

Aun con la aprobación puesta, el control puede estar vacío si quien la concede es quien la pidió. Cuando el flujo lo lanza la «plataforma», el aprobador es siempre una persona; cuando lo lanza un analista a mano, el aprobador debe ser otra.

Revisa solicitudes y busca la que no cumple esa independencia.

Cada acción tiene un vencimiento, y una solicitud resuelta después de vencer no debería ejecutarse sin una nueva decisión. Para saberlo hay que medir el tiempo que pasó entre que se pidió y que se resolvió.

Calcula los minutos de espera de SOL-19 y compara el resultado con el vencimiento de su acción en politica_de_aprobacion.

La aprobación protege cada acción. Las salvaguardas protegen contra el flujo entero: un tope de acciones por hora que, al alcanzarse, pausa el flujo y avisa; una lista de objetivos que nunca se tocan; un modo de prueba en el que el flujo solo registra lo que haría. Ninguna sustituye a las otras.

Mira salvaguardas y piensa en el playbook que aísla equipos, que ya tiene lista de exclusión.