¿Por qué la aprobación final la asume una persona?

Ya hablamos de que la IA encargada de ejecución solo necesita «poner manos a la obra». Después de eso, el rol de auditoría, independiente de la ejecución, se encarga de «detectar los problemas».

¿Entonces quién emite el juicio final de «seguir adelante» o «detenerlo»?

Esa es la última pieza de la separación de poderes (aquí: la distribución de ejecución / auditoría / aprobación entre agentes distintos): el rol de aprobación. En este sistema, ese rol lo asume una persona.

¿Qué es el rol de aprobación?

El trabajo del rol de aprobación es tomar la decisión de «se puede continuar».

Cuando la ejecución ha terminado su tarea y la auditoría ha realizado su revisión, quien recibe el «esto tiene luz verde» al final es el rol de aprobación.

Hay una razón para que este rol lo ocupe una persona.

Una IA puede ejecutar. También puede auditar. Sin embargo, asumir «yo soy responsable de esta decisión» es algo que, por ahora, solo puede hacer una persona. Cuando alguien tiene que hacerse responsable, el rol de aprobación lo cumple una persona como diseño estructural para dejar clara esa responsabilidad.

No se trata de «no podemos confiar si una persona no lo revisa». Se trata de que una persona ocupa ese rol como mecanismo para preservar en la estructura quién asume la responsabilidad.

¿Por qué el «adelante» final lo da una persona?

Por mucho que ejecutar y auditar estén diseñados con alta precisión, el juicio de «seguir adelante» necesita un sujeto que lo asuma.

Aquí cobra importancia cómo se relaciona con las «acciones irreversibles» (operaciones que, una vez realizadas, no se pueden deshacer).

Por ejemplo: publicar un artículo, eliminar un archivo, enviar algo a un servicio externo. Para estas operaciones, aunque después se diga «como si no hubiera pasado», no es tan sencillo. Dado que no se pueden deshacer, hace falta un punto de control que confirme «¿realmente queremos seguir adelante?» antes de ejecutarlas.

Quien se sitúa en ese punto de control es la persona del rol de aprobación.

Precisamente porque la ejecución y la auditoría son IAs, es posible crear el hecho de que «una persona lo ha confirmado» justo antes de una operación irreversible. Eso también queda registrado. Se convierte en la base para poder explicar «por qué se tomó esa decisión» si algo ocurre.

Dicho de otro modo, no es realista que una persona confirme absolutamente todo, incluyendo operaciones reversibles y de poco impacto. Si se detiene el flujo en cada tarea menor para confirmarla, el proceso general se atasca.

Por eso, la confirmación humana se acota a lo «irreversible e importante». Las tareas reversibles y de poco peso se delegan a las IAs. Al establecer esa diferencia de prioridad, la concentración del rol de aprobación se dirige a los momentos donde realmente se necesita. Este es el truco práctico a la hora de poner el sistema en marcha.

¿Qué hace y qué no hace el rol de aprobación?

Lo que el rol de aprobación «hace» es, básicamente, decidir «adelante / parar».

No se adentra en los detalles de implementación. Si en el momento de la aprobación se introduce un cambio de diseño del tipo «quizás habría sido mejor hacerlo así», el proceso se desestabiliza. Aprobar es decidir, «como resultado de haber pasado por todo este proceso hasta aquí, si se avanza o no». Cuando se quiere volver al diseño, hay que hacerlo antes de la aprobación.

Hay algo más que tenemos presente. La idea de no cerrar la aprobación en solitario.

Cuando se trata de una decisión irreversible e importante, con una sola perspectiva es fácil pasar cosas por alto. Cuando otra persona revisa el mismo contenido, pueden aflorar problemas que no se habían detectado. La estructura de «no decidir todo uno solo» resulta especialmente efectiva en decisiones de gran peso. Profundizaremos en otro momento, pero en este sistema también se aplica la regla de dos personas (revisar las operaciones irreversibles entre dos) para las acciones irreversibles.

Además, el criterio de aprobación queda registrado. Se deja escrito «por qué se dio luz verde». Esto conecta con el principio de documentación (la práctica de dejar por escrito el fundamento de cada decisión). La aprobación no es un acto que responda al ánimo del momento o al flujo de la situación; necesita quedar como un acto explicable. Tener un registro que se pueda revisar más adelante permite consultar las decisiones anteriores cuando llegue una decisión de la misma naturaleza.

Los tres roles encajan y entonces el sistema funciona

La ejecución (IA) completa la tarea, la auditoría (IA) detecta los problemas, y la aprobación (persona) asume si se avanza o no. Que estos tres roles estén distribuidos en responsables distintos permite que cada uno se concentre en su propio trabajo.

El estado en el que la estructura deja visible «quién confirma qué cuando alguien hace algo, y quién asume la responsabilidad». Eso es lo que este sistema persigue.

Cuando los tres roles están integrados en uno, la tarea, la auditoría y la aprobación ocurren en el mismo lugar. Si surge algún problema, resulta difícil rastrear dónde y qué pasó. Al separar los tres, cuando surge un problema se vuelve más fácil ver «en qué capa ocurrió».

Al ponerlo en marcha de verdad, el beneficio de esta estructura no se siente en «los momentos en que surge un problema», sino que se va notando poco a poco en «el día a día en que no pasa nada». Cada tarea se va acumulando como registro, y queda constancia de quién decidió qué. Cuando eso continúa dos semanas, un mes, la confianza en el sistema crece gradualmente.

Hasta aquí la explicación de los tres roles de la separación de poderes.