Nota del autor: Partimos de la regla «consultar a una persona solo al borrar datos, gastar dinero o cambiar de rumbo» para analizar tres dimensiones que delimitan las decisiones humanas en sistemas de automatización con agentes, el diseño del canal de aprobación y el reparto de verificaciones con CI.
Cuando un Agent pasa de «conversar contigo» a «trabajar por ti», lo más difícil no suele ser ponerlo en marcha, sino decidir cuándo debe detenerse. Si hay demasiados puntos de aprobación, la automatización se reduce a «hacer clic en confirmar»; si hay muy pocos, un borrado accidental o un gasto descontrolado pueden borrar meses de ganancias de eficiencia. Este artículo aborda cuándo debe detenerse un Agent para consultar a una persona y propone un método reutilizable para definir los límites de la decisión humana.
No es una reflexión genérica sobre «los peligros de la IA». Partimos de un sistema real que se ha compartido públicamente: el creador de contenido 卡兹克 lleva casi un año desarrollando un sistema de automatización con agentes que solo le pide decidir mediante tarjetas de Feishu en tres casos clave: borrar datos, gastar dinero o cambiar de rumbo. Convertimos este principio en dimensiones de evaluación y añadimos un método para diseñar el canal de aprobación.
Valor principal: al terminar, podrás decidir qué operaciones puede ejecutar un Agent de forma autónoma, cuáles requieren confirmación humana y cómo diseñar un canal de aprobación que controle los riesgos sin interrumpir la automatización.
Cuándo debe detenerse un agente para consultar a una persona: 3 tipos de decisiones clave
El sistema de Kazik da una respuesta muy acotada: las personas intervienen solo en tres momentos. La siguiente tabla relaciona cada tipo de decisión con el riesgo que implica.
| Punto de decisión | Operaciones típicas | Naturaleza del riesgo | Por qué se necesita a una persona |
|---|---|---|---|
| Eliminar datos | Limpiar registros de bases de datos, eliminar archivos, sobrescribir versiones anteriores | Irreversibilidad | Una vez ejecutada la acción, revertirla puede ser muy costoso o incluso imposible |
| Gastar dinero | Invocar servicios de pago, adquirir recursos, consumir cuotas de modelos en grandes cantidades | Salida de fondos | Implica costos reales que pueden multiplicarse en un bucle |
| Cambiar de rumbo | Ajustar los temas de contenido, cambiar la estrategia de producto, reescribir reglas establecidas | Impacto en los objetivos | El agente no cuenta con todo el contexto del negocio ni con criterio para valorar estas decisiones |
Dónde se sitúa el límite de la decisión humana en la arquitectura de cuatro capas
Según el resumen público, la idea central del sistema de Kazik es «dejar de depender de las personas para iniciar las tareas»: los eventos activan el trabajo de los agentes, en lugar de que una persona tenga que iniciar cada tarea. El sistema se divide en cuatro capas y la decisión humana se sitúa en la última, como el «freno» de toda la cadena, no como el «acelerador».
| Capa | Responsabilidad | Implementación según la información pública |
|---|---|---|
| Plataforma central de automatización | Gestionar de forma unificada los eventos y la programación de agentes | Configuración centralizada de reglas en rules.json |
| Capa de ejecución de agentes | Ejecutar las tareas de los agentes | Ejecución local en un Mac Mini |
| Plataforma central de CI | Cinco pasos: revisión, comprobación, integración, publicación y verificación | Desarrollo propio |
| Capa de decisión en Feishu | Solicitar una decisión humana en los momentos clave | Tarjetas de Feishu |
Esta división revela una decisión de diseño importante: la mayoría de las preguntas sobre si algo «es correcto» se dejan a la verificación automatizada de la plataforma de CI; solo las preguntas sobre si algo «debería hacerse» se trasladan a las personas. Las primeras pueden comprobarse con criterios objetivos; las segundas implican valorar alternativas y asumir responsabilidades. Ahí está la línea que delimita la decisión humana.
Conviene aclarar que el material original es solo un resumen. No detalla los campos concretos de las tarjetas de Feishu, la frecuencia ni los tiempos de respuesta de las decisiones humanas, ni la definición exacta de «cambiar de rumbo». Las recomendaciones posteriores de este artículo sobre el diseño de tarjetas y los criterios de evaluación son propuestas nuestras basadas en ese principio, no una descripción del sistema original.
Cómo decidir cuándo un Agent debe detenerse a preguntar: el método de las tres dimensiones
«Borrar datos, gastar dinero y cambiar de rumbo» es un buen punto de partida, pero los sistemas reales implican muchas más operaciones. Si las agrupamos en tres dimensiones reutilizables, podemos clasificar rápidamente cualquier operación nueva: reversibilidad, impacto en los costos y cambio de dirección.
Dimensión 1: la reversibilidad determina si se pueden deshacer las consecuencias
La reversibilidad responde a una pregunta: «Si algo sale mal, ¿se puede deshacer?». Redactar un borrador, crear una rama o ejecutar un script en un entorno de pruebas son operaciones reversibles: si salen mal, basta con descartarlas y empezar de nuevo. En cambio, borrar datos de producción, enviar correos a destinatarios externos o publicar contenido oficialmente son operaciones irreversibles o parcialmente reversibles. En esos casos, deshacerlas cuesta mucho más que ejecutarlas.
Para evaluarlo, hazte una pregunta concreta: si el Agent detecta un error justo después de ejecutar la operación, ¿cuánto tiempo y cuántas personas hacen falta para recuperarse? Si la respuesta supera lo que estás dispuesto a asumir, la operación debería requerir aprobación.
Dimensión dos: el impacto en los costos determina si hace falta un límite presupuestario
El impacto en los costos no se limita a «cuánto cuesta esta vez»; también importa si ese costo puede multiplicarse. El mayor riesgo financiero de un Agent suele venir de los bucles: un error en la lógica de reintentos o una condición de activación demasiado amplia pueden hacer que la invocación del modelo se repita durante horas. Una operación de bajo costo puede volverse inaceptable si se ejecuta sin control.
Por eso, resulta más práctico establecer umbrales presupuestarios: el Agent ejecuta las operaciones de forma autónoma mientras el gasto por operación y el acumulado estén dentro de los límites; si los supera, se detiene y consulta a una persona. Si tu Agent necesita invocar varios Modelos de Lenguaje Grande, puedes centralizar las invocaciones mediante una plataforma de interfaz unificada como APIYI apiyi.com. Así, el uso se agrupa en un mismo lugar y puedes comparar el gasto acumulado con los umbrales sin tener que revisar los paneles de varios proveedores.
Dimensión tres: la dirección determina quién es responsable de los objetivos
La dirección es la más difícil de delimitar de las tres dimensiones. Se refiere a si una operación puede cambiar «hacia dónde vamos», por ejemplo, al modificar la estrategia de selección de temas, ajustar la configuración de las reglas o cambiar las prioridades del producto. Un Agent es bueno encontrando la mejor ruta hacia un objetivo dado, pero no tanto decidiendo si el objetivo en sí debería cambiar, porque eso requiere contexto de negocio, criterio de marca y asumir la responsabilidad.
Una forma práctica de delimitarlo es considerar que una operación «cambia la dirección» si modifica las reglas o los objetivos del propio Agent —por ejemplo, al reescribir las condiciones de activación de rules.json— o si su resultado servirá de premisa para muchas tareas posteriores.
| Dimensión | Características de bajo riesgo | Características de alto riesgo | Tratamiento recomendado |
|---|---|---|---|
| Reversibilidad | Borradores, ramas, entornos de prueba, reversión con un clic | Eliminar, sobrescribir, publicar externamente, enviar mensajes | El riesgo alto requiere aprobación |
| Impacto en los costos | Bajo costo por operación, gasto acumulado dentro del presupuesto | Supera el umbral, puede multiplicarse por un bucle | Autonomía dentro del umbral; aprobación si se supera |
| Dirección | Ejecución dentro de los objetivos establecidos | Modificación de reglas, objetivos o estrategia a largo plazo | Siempre decide una persona |
| Evaluación conjunta | Las tres dimensiones son de bajo riesgo | Cualquiera de las dimensiones es de alto riesgo | Si una dimensión es de alto riesgo, detenerse y consultar a una persona |
El costo de aprobar demasiado o demasiado poco
Definir los límites consiste en encontrar un equilibrio entre dos tipos de fallos. Tanto el exceso como la falta de aprobaciones pueden hacer fracasar un proyecto de automatización con agentes, aunque de distintas maneras.
| Situación | Manifestación habitual | Consecuencia inmediata | Impacto a largo plazo |
|---|---|---|---|
| Demasiadas aprobaciones | Se pide confirmación en cada paso y se acumulan las tarjetas | La automatización se convierte en «pulsar botones manualmente» | Fatiga de aprobación: las personas aceptan sin leer |
| Muy pocas aprobaciones | Incluso las operaciones críticas se ejecutan de forma autónoma | Eliminaciones accidentales, gastos excesivos y desviaciones | Un solo incidente destruye la confianza en el sistema |
| Límites razonables | Solo se detiene en tres tipos de situaciones de alto riesgo | Las personas solo intervienen en asuntos que requieren su criterio | La confianza crece y se puede delegar más autonomía gradualmente |
El peligro más difícil de detectar del exceso de aprobaciones es la «fatiga de aprobación». Cuando alguien recibe decenas de tarjetas de confirmación al día, pronto adquiere el hábito de aceptar sin leer. La aprobación deja de cumplir su función y puede ser incluso más peligrosa que no tenerla, porque todos creen que hay alguien supervisando. El sistema de Katzik se limita a «acudir a una persona solo en tres tipos de situaciones» precisamente para que cada interrupción merezca una revisión cuidadosa.
Guía rápida de los límites de decisión humana para agentes: crea un canal de aprobación en cinco pasos
Estos son los pasos para diseñar un canal de aprobación desde cero. No dependen de ningún framework específico: puedes implementarlos con cualquier herramienta de programación de eventos y plataforma de mensajería instantánea.
Paso 1: Haz un inventario de todas las acciones del agente
Enumera todas las herramientas y acciones que puede invocar el agente, como leer archivos, escribir archivos, borrar registros, llamar a API externas, enviar mensajes y modificar configuraciones. Etiqueta cada una según tres dimensiones para crear una «lista de riesgos de acciones». Esta lista será la base de todas las reglas posteriores y un punto de partida común para que el equipo debata los límites.
Segundo paso: centralizar la gestión de las reglas
Siguiendo el ejemplo de Kha’zix, que usa rules.json para gestionar de forma centralizada los disparadores y la programación, incluye también en esa configuración las acciones que necesitan aprobación, en lugar de dispersarlas entre las indicaciones de cada Agent. La configuración centralizada tiene dos ventajas:
- Se puede auditar: cualquiera puede ver qué operaciones requieren confirmación humana;
- Se puede ajustar: si hay que hacer los límites más estrictos o flexibles, basta con cambiar un solo lugar.
Ten en cuenta que modificar esta configuración ya supone un «cambio de rumbo», por lo que solo debería hacerlo una persona.
Tercer paso: dejar que CI haga primero las comprobaciones automáticas
Antes de pedir la intervención de una persona, deja que las comprobaciones automáticas revisen todo lo que puedan. La plataforma central de CI de Kha’zix incluye cinco pasos: revisión, comprobación, integración, publicación y verificación. Esto significa que, cuando una decisión llega a manos de una persona, ya se han filtrado problemas básicos como errores de formato o pruebas fallidas. Las personas no deberían hacer comprobaciones que pueden hacer las máquinas, y las máquinas no deberían tomar decisiones que corresponden a las personas.
Cuarto paso: diseñar la tarjeta de decisión
Estas son nuestras recomendaciones para diseñar la tarjeta de decisión (no son detalles del sistema original). El principio central es que una persona pueda tomar una decisión en cuestión de segundos:
- Explicar en una frase qué se va a hacer: por ejemplo, «Se eliminarán los registros de borradores anteriores a marzo»;
- Indicar las dimensiones de riesgo detectadas: si la acción es irreversible, supera el presupuesto o cambia el rumbo;
- Especificar el alcance y el importe: cuántos registros se verán afectados y cuál es el costo estimado;
- Mostrar los motivos y las pruebas del agente: por qué propone hacerlo y cuál fue el resultado de la verificación de CI;
- Ofrecer botones de acción claros: aprobar, rechazar y, cuando sea necesario, «Modificar y ejecutar».
Quinto paso: definir los plazos y el comportamiento predeterminado
Las personas no están disponibles todo el tiempo. Hay que definir de antemano cuánto tiempo puede quedar una tarjeta sin atender antes de que venza el plazo y si, al vencer, la acción predeterminada será «no ejecutar» o «ejecutar con funciones reducidas». Para operaciones como eliminar datos o gastar dinero, la opción predeterminada debe ser «no ejecutar». Es mejor que la tarea espere a que el silencio se convierta en una autorización.
🚀 Para empezar rápido: durante la fase de prototipo, conviene usar un punto de acceso unificado a los modelos para probar toda la cadena: «Ejecución del agente → Verificación de CI → Aprobación mediante tarjeta». Con APIYI apiyi.com puedes invocar varios modelos populares y cambiar entre ellos sin modificar la lógica de aprobación. Así podrás comparar con qué frecuencia cada modelo solicita aprobación y la calidad de sus razones.
El reparto de tareas entre la verificación de CI y la decisión humana
Muchos equipos se preguntan: si CI puede hacer las comprobaciones, ¿por qué sigue haciendo falta una persona? La respuesta es que cada uno responde a preguntas distintas. Esta tabla muestra cómo se reparten las responsabilidades:
| Etapa | Pregunta que responde | Criterio | Responsable |
|---|---|---|---|
| Revisión / Comprobación | ¿El resultado cumple las normas? | Reglas, pruebas y formato | Plataforma central de CI |
| Integración / Publicación | ¿Puede pasar a la siguiente etapa? | Que se hayan superado todas las comprobaciones | Plataforma central de CI |
| Verificación | ¿El resultado surtió efecto? | Validación posterior | Plataforma central de CI |
| Borrar datos / Gastar dinero / Cambiar de rumbo | ¿Conviene hacerlo? | Criterio de negocio y responsabilidad | Decisión humana |
| Origen de la invocación del modelo | ¿Qué modelo usar y cuánto gastar? | Límites de presupuesto | Reglas de configuración + supervisión humana; APIYI apiyi.com puede ayudar a consolidar el consumo |
Preguntas frecuentes FAQ
Q1: ¿Qué es el límite de decisión humana de un agente?
Es una regla que separa las acciones que un agente puede ejecutar de forma autónoma de las que requieren confirmación humana. Dentro de ese límite, el agente opera sin interrupciones; cuando lo alcanza, se detiene y deja la decisión en manos de una persona. Suele definirse según tres criterios: reversibilidad, impacto en los costos y cambios de dirección.
Q2: ¿En qué se diferencian la aprobación humana y las comprobaciones automáticas de CI?
CI responde «¿es correcto?» basándose en reglas y pruebas, por lo que es una tarea adecuada para las máquinas. La aprobación humana responde «¿debería hacerse?» y se basa en el criterio de negocio y la asunción de responsabilidad. Conviene automatizar al máximo las primeras y reservar las segundas para los casos realmente importantes. Juntas permiten trabajar con rapidez y seguridad.
Q3: ¿Cómo se define una categoría tan ambigua como «cambiar de dirección»?
El material original no explica cómo la define el autor. Nuestra recomendación es tratar como «cambio de dirección» cualquier acción que modifique las reglas o los objetivos del propio agente, así como cualquier acción cuyo resultado sirva de base para muchas tareas posteriores. Si no está claro, es preferible exigir aprobación al principio y dar más autonomía gradualmente según la experiencia.
Q4: ¿En qué situaciones es más importante establecer puntos de decisión humana?
Principalmente:
– **Tareas de limpieza de datos**: eliminación periódica de registros o archivos caducados;
– **Publicación automática de contenido**: confirmación final antes de publicar;
– **Invocaciones de modelos en lote**: llamadas de pago que podrían multiplicarse dentro de un bucle;
– **Ajustes estratégicos**: cambios en la dirección de los temas, las reglas de programación de tareas, etc.
Q5: ¿Cómo controlar el gasto de un agente al invocar Modelos de Lenguaje Grande?
Recomendamos establecer dos umbrales de presupuesto: uno por operación y otro acumulado. Dentro de los límites, el agente puede actuar de forma autónoma; si los supera, debe solicitar aprobación. Centralizar la invocación de modelos en una plataforma de interfaz unificada como APIYI apiyi.com reúne el uso en un solo punto y facilita su seguimiento y revisión frente a los umbrales.
Q6: ¿Cómo comprobar rápidamente si los límites de aprobación son adecuados?
Empieza con una prueba a pequeña escala usando tareas reales y registra el número diario de aprobaciones, la tasa de rechazo y el tiempo medio de respuesta. Si hay muchas solicitudes de aprobación y la tasa de rechazo es muy baja, los límites son demasiado estrictos; si aparecen problemas que solo se detectan después, son demasiado permisivos. Al principio, puedes usar APIYI apiyi.com para ejecutar el mismo lote de tareas con varios modelos y observar las diferencias en las solicitudes de aprobación que genera cada uno.
Q7: ¿Qué limitaciones tiene este enfoque?
La aprobación humana depende de que haya alguien disponible y responda, por lo que las tareas pueden acumularse durante la noche o los días festivos. Si la información de la tarjeta está incompleta, también puede haber errores de juicio. Además, el material original en el que se basa este artículo es un resumen: todavía no hay detalles públicos sobre casos de ejecución errónea sin aprobación ni sobre los mecanismos de protección concretos. Al implementarlo, será necesario añadir mecanismos de tiempo de espera, registro y reversión adaptados al sistema.
Cuándo debe detenerse un agente para consultar a una persona: puntos clave
- Principio central: interrumpir a una persona solo en tres casos: al eliminar datos, gastar dinero o cambiar de rumbo. Así, cada aprobación conserva su importancia.
- Tres criterios: clasificar rápidamente cualquier operación nueva según su reversibilidad, su impacto en los costos y si implica un cambio de rumbo.
- Reparto claro: la CI comprueba «si es correcto»; las personas deciden «si conviene hacerlo». Una no sustituye a la otra.
- Cuidado con la fatiga: demasiadas solicitudes de aprobación pueden llevar a aceptarlas por costumbre, algo más peligroso que no pedir aprobación.
- Precaución por defecto: si vence el plazo sin respuesta, las operaciones de alto riesgo no se ejecutan.
- Punto de acceso único: usar APIYI apiyi.com para invocar distintos modelos desde un mismo lugar y facilitar la gestión de umbrales de costos y la comparación de modelos.
Resumen
Decidir cuándo debe detenerse un agente para consultar a una persona consiste, en esencia, en trazar una línea clara entre la eficiencia y el riesgo:
- Empezar con tres tipos de decisiones: eliminar datos, gastar dinero y cambiar de rumbo cubren la gran mayoría de los escenarios de alto riesgo;
- Ampliar con tres criterios: la reversibilidad, el impacto en los costos y los cambios de rumbo permiten aplicar esos límites a cualquier operación nueva;
- Reducir la carga con verificaciones automáticas: dejar que la CI filtre los problemas básicos para que las personas solo intervengan en lo que realmente requiere criterio.
Los límites no se fijan de una vez para siempre: se pueden flexibilizar gradualmente a medida que aumenta la confianza. Conviene empezar con límites estrictos en una prueba piloto y usar los datos para decidir dónde se puede dar más autonomía. Durante la implementación y el ajuste, se recomienda usar APIYI apiyi.com para acceder a distintos modelos desde un mismo lugar y comprobar rápidamente cómo funciona cada uno en tu flujo de aprobación.
📚 Referencias
- Digital Life Kazike comparte la arquitectura de un sistema de automatización con agentes desarrollado durante un año: fuente de los principios y la arquitectura descritos en este artículo
- Enlace:
aihot.news/items/dzwfvd9xp6v4qaj6olxezpier - Descripción: presenta una arquitectura de cuatro capas —plataforma de automatización, ejecución de agentes, plataforma de CI y toma de decisiones en Feishu— y el principio de «consultar a una persona solo para borrar datos, gastar dinero o cambiar de rumbo». La fuente es un resumen; consulta el artículo original para verificar los detalles.
Autor: equipo técnico de APIYI
Intercambio técnico: contáctanos desde la página principal de APIYI en apiyi.com para compartir experiencias sobre la implementación de la automatización con agentes y la colaboración entre personas y agentes. Encontrarás más recursos en el centro de documentación docs.apiyi.com.
