Saltar al contenido principal
Blog
Volver al blog

Flujo de aprobación de agentes de IA: control sin bloqueos

Un flujo de aprobación de agentes de IA es la ruta de control entre una acción propuesta y su ejecución. Una aprobación útil no es un botón genérico de «continuar». Le dice a quien revisa qué va a ocurrir, sobre qué destino, con qué datos o costo, cómo se comprobará el éxito y dónde debe detenerse la acción.

Vincula la aprobación a seis campos exactos

  • Acción: la operación—publicar, enviar, cambiar código, desplegar, gastar o ejecutar una investigación de pago.
  • Destino: la cuenta, el destinatario, el repositorio, el entorno, la audiencia o el recurso del proveedor.
  • Contenido: el texto, los archivos, el parche, la consulta, el presupuesto o la configuración exactos que se revisan.
  • Alcance: la cantidad, los permisos, la duración y los efectos secundarios permitidos.
  • Comprobación de éxito: la evidencia que distingue una acción completada de una acción solo intentada.
  • Condición de parada: el tiempo, el costo, el error, la ambigüedad o la señal que pone fin a la ejecución.

Usa una máquina de estados visible

  1. Propuesta: el agente prepara una acción acotada y explica por qué importa ahora.
  2. En revisión: el usuario puede inspeccionar el destino, el contenido, el alcance, los criterios de aceptación y los efectos secundarios probables.
  3. Revisada o rechazada: las correcciones cierran la propuesta anterior y generan una nueva versión cuando corresponde.
  4. Aprobada: el consentimiento queda registrado sobre la versión exacta revisada.
  5. En ejecución: el especialista intenta solo el alcance aprobado e informa de pausas o fallos.
  6. Verificada: la evidencia del proveedor, la salida de las pruebas, una URL pública u otra comprobación explícita demuestra el resultado.
  7. Aprendida: el resultado y la señal vuelven al contexto del proyecto antes de la siguiente propuesta.

Ejemplo práctico: revisar una tarjeta de investigación antes de aprobarla

Este ejemplo sigue el contrato de aprobación actual de Soloop, pero es deliberadamente ilustrativo y no pretende ser la ejecución real de un cliente. Muestra cómo una propuesta vaga se convierte en una tarea exacta y auditable.

Propuesta · v1

Investiga a los competidores y recomienda qué deberíamos construir. Faltan el destino, el límite de fuentes, el costo, los criterios de aceptación y la condición de parada, así que esta versión no debería aprobarse.

Solicitud de revisión

Limita la tarea a un competidor concreto y a dominios públicos aprobados. Exige enlaces a fuentes con fecha, contraevidencia, incógnitas explícitas y un traspaso orientado a la decisión. Prohíbe iniciar sesión, comprar, crear pruebas gratuitas y establecer contacto.

Aprobada · v2

Revisa la página de inicio oficial, la documentación, la página de precios y los términos. Costo: $0 en servicios de pago. Detente antes de cualquier autenticación o cuando no se pueda verificar un hecho relevante.

Registro de ejecución

Registra la versión aprobada, el ejecutor, las marcas de tiempo, las fuentes abiertas, la evidencia inaccesible y si se activó alguna condición de parada. Una búsqueda completada sin este registro sigue siendo un intento, no una finalización verificada.

Resultado verificado

Devuelve el registro de evidencia con fechas, separa la observación de la inferencia e identifica la decisión exacta del fundador que cambió gracias al trabajo. No conviertas la investigación secundaria en una afirmación sobre la demanda.

Aprendida

Guarda el resultado y la incógnita más importante en el proyecto antes de proponer la siguiente tarea. Una acción posterior de publicación, correo, código, despliegue o gasto necesita su propio límite de aprobación aplicable.

Controla según las consecuencias, no según el entusiasmo del agente

El análisis reversible y de bajo riesgo a menudo puede avanzar con controles ligeros. Los mensajes externos, las publicaciones públicas, los cambios de código, los despliegues, las conexiones de cuentas, los servicios de pago, las modificaciones de bases de datos y el gasto merecen una revisión explícita. El riesgo también depende del destino: editar un borrador no es lo mismo que publicarlo con la identidad de un fundador.

Traspasar una tarea a un especialista no debería aprobar automáticamente la acción externa de ese especialista. La tarjeta posterior puede incluir el destinatario, el texto, el repositorio, el diff o el costo reales que no estaban disponibles en el momento del traspaso.

Evita la fatiga de aprobación

  • Pregunta una sola vez, en el último momento seguro, cuando quien revisa pueda ver el contenido real.
  • Agrupa solo acciones con el mismo riesgo, destino y condición de parada.
  • Muestra los campos modificados en una revisión en lugar de obligar al usuario a releerlo todo.
  • Usa valores predeterminados que bloqueen la acción (fallo cerrado) cuando falten la titularidad, la autenticación o el alcance.
  • Mantén la investigación de solo lectura separada de los servicios de pago y de las escrituras externas.
  • Permite al usuario pausar o rechazar sin perder el rastro de evidencia de la propuesta.

Mantén un registro de auditoría que explique qué ocurrió

Soloop usa rutas de aprobación para la investigación, las publicaciones públicas, el correo en beta, los cambios de código y los despliegues. Sus límites públicos actuales importan: X/Twitter está activo con OAuth; el correo en frío está en beta y requiere Gmail; la publicación en Reddit es manual; los anuncios se limitan a la planificación; y el código se ejecuta en un sandbox. La interfaz de aprobación debe describir la ruta de ejecución real en lugar de insinuar que un canal planificado ya está activo.

  • ¿Quién propuso la acción y quién la aprobó?
  • ¿Qué versión inmutable y qué destino se revisaron?
  • ¿Cuándo se produjeron la aprobación y la ejecución?
  • ¿Qué proveedor, cuenta, repositorio o entorno se utilizó?
  • ¿Qué evidencia demuestra el éxito, el fallo o la finalización parcial?
  • ¿Qué costo, resultado, señal y decisión de seguimiento se produjeron?

Una tarjeta de revisión práctica

  1. Objetivo: la decisión o el resultado que respalda esta acción.
  2. Por qué ahora: la evidencia que convierte esto en el siguiente paso.
  3. Acción y destino exactos: qué cambiará, dónde y con qué cuenta.
  4. Vista previa: el texto final, los archivos, el diff, la consulta o el presupuesto.
  5. Comprobaciones de aceptación y parada: cómo se juzgarán la finalización y el fallo.
  6. Controles: aprobar, revisar, rechazar o pausar.