Una regla habitual para la autonomía de agentes es: si funciona, actívalo.
Tengo un pipeline que corre cada día y prepara artículos para este blog. Le hice una prueba de aceptación estricta para dejar que publicara sin mí. Produjo dos ejecuciones elegibles de tres. Y aun así mantuve la aprobación humana.
Qué hace el pipeline
El pipeline de blog corre a diario. En orden:
- Descubre candidatos: temas que podrían merecer un artículo.
- Selecciona uno.
- Lo escribe.
- Lo revisa con filtros independientes: evidencia, hechos, narrativa, privacidad y QA del sitio.
- Recurre a otro candidato si el seleccionado no supera las revisiones.
- Tiene una oportunidad de reparar lo que un filtro marcó, mediante un bucle de reparación acotado. No una reescritura libre hasta que algo pase.
- Prepara el artículo para publicación.
El paso de reparación es pequeño a propósito. Un bucle al que se le permite seguir editando hasta que los controles se pongan en verde optimiza para pasar los controles, no para acertar. Un intento, limitado a lo que el filtro marcó.
La prueba de aceptación
«Parece que funciona» no es un criterio en el que confíe para un interruptor de publicar solo. La prueba de aceptación era estricta y la regla era 3 de 3: las tres ejecuciones tenían que salir elegibles para autonomía.
El resultado: 2 de 3
Dos ejecuciones salieron elegibles.
La tercera se quedó en HUMAN_REVIEW_REQUIRED: el pipeline no la dio por apta para publicarse sin una persona.
Dos de tres suena a «casi funciona». Para un interruptor de publicar solo no lo es. La regla era 3 de 3.
Por qué no aflojé los filtros
Había formas fáciles de conseguir un aprobado. Relajar el control que frenó la tercera ejecución. Contar el paso de reparación de forma más generosa. Repetir hasta que un tercer intento afortunado saliera bien. Cualquiera de ellas habría convertido la prueba en un trámite.
La tercera ejecución en revisión humana es el tipo de resultado para el que existen los filtros. Es una sola ejecución, no una prueba estadística de que funcionan, pero aflojarlos para convertir 2 de 3 en 3 de 3 eliminaría el único caso en que el pipeline se frenó.
Así que los filtros se quedan exactamente como están.
La decisión
La publicación en producción sigue en HUMAN_APPROVAL. Yo sigo leyendo y aprobando lo que el pipeline prepara.
Tiene un coste real: sigo siendo el cuello de botella de cada artículo. Lo acepto porque la alternativa es un sistema que publica con mi nombre según un umbral que yo mismo doblé para alcanzarlo. El camino de vuelta a la publicación autónoma no es editar los filtros. Es pasar la misma prueba con los filtros intactos.
Es el mismo principio que usé en Traffic OS: la automatización hace el trabajo repetitivo y la decisión se queda con una persona hasta que el sistema se haya ganado el derecho a tomarla. Y enlaza con una lección de un bug silencioso en este mismo pipeline de contenido: una salvaguarda vale lo que valgan los datos y la prueba que la respaldan, y un pipeline que parece sano puede estar equivocado.
Lo que me llevo
Un agente útil no es el que siempre actúa. Es el que sabe cuándo no puede justificar actuar.
Si estás diseñando filtros de aprobación para agentes de IA, tres puntos prácticos:
- Haz binaria la regla de aceptación. «Casi todo pasó» no es un resultado que puedas poner en producción.
- Trata un rechazo como un resultado, no como un defecto. Si tus filtros nunca frenan nada, no sabes si funcionan.
- Mantén estrecho el bucle de reparación. Reintentar hasta que pasen los controles anula el sentido de tener controles.
La arquitectura general detrás de esto, con filtros de aprobación, artefactos inmutables y registros de auditoría, está en Arquitectura de agentes de IA. La parte de vídeo del mismo sistema está en cómo construí mi propio pipeline de edición de vídeo, donde también una persona aprueba el resultado final.
¿Quieres seguir el proyecto?
Cómo diseño filtros de aprobación para agentes de IA
