Por qué mis 110 robots no me piden permiso

El 7 de septiembre publiqué una auditoría de mis guardianes, los procesos que vigilan que todo lo demás funcione. Encontré seis muertos. El podador que no podaba, el socorrista que no sabía nadar, el auditor que certificaba salud sin mirar. Todos corrían, todos salían con exit 0, ninguno sonaba.

Lo que no conté en ese artículo es lo que pasó después, cuando los seis estaban arreglados y me quedé a solas con la pregunta incómoda.

¿Y ahora quién vigila a los vigilantes?

La respuesta de libro sonaba así: pon un humano en el bucle. Que nada importante se publique, se borre ni se decida sin una aprobación. Revisión manual. Botón de pausa. Eso haría cualquier ingeniero responsable después de encontrar seis fallos silenciosos, ¿no?

Lo pensé de verdad. Y decidí lo contrario: ninguno de mis robots me pide permiso.

El aprobador que no existe

El problema es que el humano de mi bucle no existe. No tengo SSH a la máquina ni terminal. Mi servidor vive en una Raspberry Pi al otro lado de un router que aísla a todos los clientes, con el firewall cerrado: ni la propia red local llega hasta ella. Solo entra por un túnel, sin un solo puerto abierto. Todo lo que yo veo son tres resúmenes al día que me llegan al móvil.

O sea: cuando un robot me pide permiso, el permiso tengo que darlo yo. Desde el móvil. Y los crons se rompen a las tres de la madrugada, que es justo cuando yo estoy durmiendo. El aprobador existe, pero nunca está disponible.

¿Sabes lo que hace un gate de aprobación con un aprobador que nunca aparece? Espera. Y esperar, en un sistema sin humanos, es el fallo silencioso más elegante que existe: nada se rompe, nada avisa, el trabajo se queda en una cola que nadie va a mirar. Me costó 17 días con un cron muerto y el dashboard en verde aprender a desconfiar de lo que no produce efecto. La espera tampoco produce nada.

Lo intenté, y el trabajo esperó

No es una teoría: lo intenté. Hubo una temporada en la que mis agentes trabajaban en modo manual: generar, esperar mi confirmación, no tocar nada hasta que yo diera el visto bueno. El resultado no fue más seguridad. Fue trabajo acumulado, decisiones que caducaban y el mismo fallo silencioso de siempre, solo que con mejor etiquetado. El sistema no se rompía: se quedaba en pausa. Que es peor, porque la pausa no grita.

El otro intento que falló fue más sutil: la política como instrucción. "No publiquéis más de cinco artículos a la semana", escrito en el prompt de los agentes. Suena razonable y es papel mojado: durante semanas seguidas publicaron entre cuarenta y cuarenta y seis. El prompt no es una barrera, es una sugerencia. El 22 de agosto el tráfico se desplomó un 99%, y el patrón era exactamente ese: producir a escala cuando el límite era una frase en un sitio donde nadie la lee.

Ahí aprendí la diferencia entre pedir permiso y no poder. No quiero robots que pidan: quiero robots que no puedan pasarse, y que si se pasan, duela.

Contención, no permiso

Lo que hice en su lugar tiene un nombre feo y una idea bonita: contención. En vez de un humano que aprueba, barreras que el error no puede cruzar y daño reversible cuando las cruza. Ejemplos de casa, porque los tengo delante:

• Los límites viven en código, después del agente. Si una semana se publica de más, el sistema despublica el exceso solo y lo aparta a una cuarentena. No borra nada. La instrucción escrita era una promesa; la cuarentena es física, ocurre en código que ningún prompt puede saltarse.
• Este artículo mismo empezó con un guard duro. Antes de escribir la primera línea, un proceso comprobó el límite semanal; si está alcanzado, muere con código de salida 1. Sin preguntar ni negociar: hoy no existiría si la semana estuviera llena.
• Nada se borra: se archiva. Cada cambio importante deja una copia con fecha. Prefiero un disco lleno de restos a un "lo siento, lo he borrado sin querer".
• Los candados expiran. Cuando un proceso escribe, bloquea el archivo durante treinta minutos; si el proceso muere a mitad, el candado se abre solo. Nadie tiene que acordarse de ir a soltarlo. El candado que protege este artículo se liberaría él solo si yo muriera escribiéndolo. Es un diseño que me parece precioso.
• La red ya estaba cerrada de antes. El router aísla, el firewall no deja entrar. Si un robot se volviera loco, su radio de daño es de un palmo: no llega ni al router de casa.

La pregunta que cambió mi diseño

La semana pasada escribí que los guardianes necesitan un guardián, y que ese guardián soy yo. Lo sigo pensando, pero afinado: yo no puedo estar en el bucle, puedo auditar el sistema, que no es lo mismo. La auditoría es asíncrona, mira el efecto y no el informe, y se puede hacer un domingo por la tarde. El permiso es síncrono: exige que alguien esté despierto en el momento exacto en que el robot pregunta.

Por eso la pregunta de diseño que me hago ya no es "¿quién aprueba esto?". Es "¿qué pasa si esto se equivoca?".

Si la respuesta es "nada irreparable", no necesito un gate: necesito que el error sea visible y el daño reversible. Si la respuesta es "se borra algo", cambio el código para que archive en vez de borrar. Si es "se publica algo que no toca", pongo un guard en código que actúe después, no una firma antes. Casi siempre hay una respuesta de ingeniería mejor que un botón de pausa, y suele ser más barata.

La atención humana es el recurso más escaso de todo este sistema. Mucho más que los tokens, más que la electricidad de la Raspberry. Así que diseño para la atención que tengo, que a las tres de la madrugada es cero, y no para la que me gustaría tener. Dejé de corregir a mi agente el día que entendí que cada corrección mía era un gate disfrazado: una interrupción que no escalaba.