Nota do autor: partindo da regra “só consultar uma pessoa ao apagar dados, gastar dinheiro ou mudar de direção”, este artigo apresenta três dimensões para definir os limites de decisão humana em sistemas de automação com Agents, além do desenho do fluxo de aprovação e da divisão das verificações com a CI.
Quando um Agent deixa de apenas “conversar com você” e passa a “trabalhar por você”, o mais difícil muitas vezes não é colocá-lo para funcionar, mas definir quando ele precisa parar. Com pontos de aprovação demais, a automação vira uma sequência de confirmações manuais; com poucos, uma exclusão acidental ou um gasto fora de controle pode anular meses de ganhos de eficiência. Neste artigo, apresentamos uma abordagem reutilizável para definir os limites da decisão humana, a partir da pergunta: quando um Agent deve parar e consultar uma pessoa?
Esta não é uma discussão vaga sobre “os perigos da IA e a necessidade de cautela”. Partimos de um sistema real, já apresentado publicamente: o criador de conteúdo Kazike passou quase um ano construindo um sistema de automação com Agents que só pede sua decisão por meio de cartões no Feishu em três situações críticas: apagar dados, gastar dinheiro e mudar de direção. Transformamos esse princípio em dimensões de avaliação e acrescentamos orientações para desenhar o fluxo de aprovação.
O que você vai aprender: ao terminar a leitura, você saberá identificar quais operações podem ficar a cargo do Agent e quais precisam de confirmação humana, além de como criar um fluxo de aprovação que controle os riscos sem interromper a automação.
Quando um agente deve parar e consultar uma pessoa: 3 pontos de decisão
O sistema de Kazik oferece uma resposta bem objetiva: as pessoas entram em cena apenas em três situações. A tabela relaciona cada ponto de decisão à natureza do risco envolvido.
| Ponto de decisão | Operações típicas | Natureza do risco | Por que uma pessoa é necessária |
|---|---|---|---|
| Excluir dados | Limpar registros do banco de dados, excluir arquivos, sobrescrever versões anteriores | Irreversibilidade | Depois da execução, reverter pode ser muito caro ou até impossível |
| Gastar dinheiro | Usar serviços pagos, comprar recursos, consumir cotas de modelos em grande escala | Saída de recursos financeiros | Há custos reais envolvidos, que podem se multiplicar em um loop |
| Mudar de direção | Alterar temas de conteúdo, mudar a estratégia do produto, reescrever regras estabelecidas | Impacto nos objetivos | O agente não tem todo o contexto de negócios nem a capacidade de fazer julgamentos de valor |
Onde fica o limite para decisões humanas na arquitetura de quatro camadas
Segundo o resumo divulgado, a ideia central do sistema de Kazik é “tirar das pessoas o ponto de partida das tarefas”: eventos acionam o trabalho dos agentes, em vez de alguém iniciar cada tarefa. O sistema tem quatro camadas, e a decisão humana fica na última, funcionando como o “freio” da cadeia, não como o “acelerador”.
| Camada | Responsabilidade | Implementação descrita nas informações divulgadas |
|---|---|---|
| Plataforma central de automação | Gerenciar de forma unificada os eventos e o agendamento dos agentes | Regras configuradas de forma centralizada em rules.json |
| Camada de execução dos agentes | Executar as tarefas dos agentes | Execução local em um Mac Mini |
| Plataforma central de CI | Realizar cinco etapas: revisão, checagem, integração, publicação e verificação | Desenvolvida internamente |
| Camada de decisão no Feishu | Solicitar uma decisão humana em momentos críticos | Cartões do Feishu |
Essa divisão revela uma escolha importante de projeto: a maioria das questões sobre “estar certo ou errado” fica a cargo da verificação automatizada na plataforma de CI. Só as decisões sobre “fazer ou não fazer” são encaminhadas a uma pessoa. No primeiro caso, há critérios objetivos que podem ser verificados; no segundo, há escolhas e responsabilidades envolvidas. Essa é a principal linha divisória do limite para decisões humanas.
Vale esclarecer que o material original é apenas um resumo. Ele não informa os campos específicos dos cartões do Feishu, a frequência das decisões humanas, o tempo de resposta nem a definição exata de “mudar de direção”. As sugestões apresentadas adiante sobre o design dos cartões e os critérios de avaliação são extensões nossas, baseadas nesse princípio, e não uma descrição do sistema original.
Como decidir quando um Agent deve parar e perguntar a uma pessoa: o método das três dimensões
“Excluir dados, gastar dinheiro e mudar de rumo” é um ótimo ponto de partida, mas os sistemas reais envolvem muito mais que esses três tipos de ação. Ao transformá-los em três dimensões reutilizáveis, você consegue classificar rapidamente qualquer nova operação: reversibilidade, impacto nos custos e direcionamento.
Dimensão 1: a reversibilidade determina se é possível desfazer as consequências
A reversibilidade responde à pergunta: “Se der errado, dá para desfazer?”. Escrever um rascunho, criar uma branch ou executar um script em um ambiente de testes são operações reversíveis: se algo der errado, basta descartar e recomeçar. Já excluir dados de produção, enviar e-mails para destinatários externos ou publicar conteúdo oficialmente são operações irreversíveis ou parcialmente reversíveis, cujo custo de reversão é muito maior que o de execução.
Para avaliar, faça uma pergunta específica: se o Agent perceber o erro imediatamente após executar a ação, quanto tempo e quantas pessoas serão necessários para restaurar a situação? Se a resposta ultrapassar o limite que você considera aceitável, a operação deve passar por aprovação.
Dimensão dois: o impacto no custo determina se é preciso estabelecer um limite de orçamento
O impacto no custo não se resume a “quanto isso vai custar agora”, mas também inclui “esse custo pode aumentar?”. O maior risco financeiro de um Agent costuma vir de loops: um erro na lógica de repetição ou uma condição de acionamento ampla demais pode fazer com que a invocação do modelo se repita por horas. Uma operação barata pode se tornar inaceitável quando multiplicada por um número descontrolado de execuções.
Por isso, uma abordagem mais prática é definir limites de orçamento: o Agent executa as tarefas de forma autônoma enquanto os gastos por operação e acumulados estiverem dentro dos limites; se ultrapassá-los, ele para e consulta uma pessoa. Se o seu Agent precisar acessar vários Modelos de Linguagem Grande, centralizar as chamadas em uma plataforma de interface unificada como APIYI apiyi.com reúne o uso em um único lugar. Assim, fica mais fácil acompanhar o gasto acumulado em relação aos limites, sem precisar conferir os painéis de vários fornecedores.
Dimensão três: o impacto na direção determina quem é responsável pelos objetivos
O impacto na direção é o mais difícil de definir entre os três. Ele diz respeito a se uma operação muda “para onde estamos indo”, como alterar a estratégia de escolha de pautas, ajustar a configuração de regras ou mudar as prioridades do produto. O Agent é bom em encontrar o melhor caminho para um objetivo definido, mas não em avaliar se o próprio objetivo deve mudar. Isso exige contexto de negócio, julgamento sobre a marca e alguém que assuma a responsabilidade.
Uma forma prática de identificar esse impacto é considerar que uma operação “muda a direção” se ela altera as próprias regras ou objetivos do Agent (por exemplo, reescrevendo as condições de acionamento em rules.json) ou se seu resultado servir de premissa para muitas tarefas posteriores.
| Dimensão | Características de baixo risco | Características de alto risco | Tratamento recomendado |
|---|---|---|---|
| Reversibilidade | Rascunhos, branches, ambientes de teste, reversão com um clique | Exclusão, sobrescrita, publicação externa, envio de mensagens | Alto risco exige aprovação |
| Impacto no custo | Baixo custo por operação, gasto acumulado dentro do orçamento | Limite ultrapassado, possibilidade de aumento por loops | Autonomia dentro do limite; acima dele, aprovação |
| Impacto na direção | Execução dentro dos objetivos estabelecidos | Alteração de regras, objetivos ou estratégia de longo prazo | Sempre deixar a decisão para uma pessoa |
| Avaliação combinada | As três dimensões têm risco baixo | Qualquer uma delas tem risco alto | Se uma dimensão tiver risco alto, parar e consultar uma pessoa |
O custo de aprovar demais ou de menos
Definir limites é, essencialmente, encontrar um equilíbrio entre dois tipos de falha. Tanto o excesso quanto a falta de aprovações podem levar um projeto de automação com agentes ao fracasso, mas de maneiras diferentes.
| Situação | Manifestação típica | Consequência imediata | Impacto a longo prazo |
|---|---|---|---|
| Aprovações em excesso | Cada etapa pede confirmação, e os cartões se acumulam | A automação vira um processo de “clicar em botões” | Fadiga de aprovação: as pessoas passam a concordar sem ler |
| Aprovações insuficientes | Até operações críticas são executadas de forma autônoma | Exclusões acidentais, gastos excessivos e desvios de rumo | Um único incidente destrói a confiança no sistema |
| Limites adequados | O agente só para em três tipos de situação de alto risco | As pessoas lidam apenas com o que realmente exige julgamento | A confiança cresce aos poucos, permitindo delegar mais autonomia |
O risco mais sutil do excesso de aprovações é a “fadiga de aprovação”. Quando alguém recebe dezenas de cartões de confirmação por dia, logo passa a concordar sem ler o conteúdo. A aprovação vira mera formalidade e pode ser ainda mais perigosa do que não ter aprovação alguma, porque todos acreditam que alguém está supervisionando. O cuidado do sistema Kazik de “recorrer a uma pessoa apenas em três tipos de situação” existe justamente para garantir que cada interrupção mereça atenção.
Guia rápido para definir os limites das decisões humanas de um Agent: cinco passos para criar um fluxo de aprovação
A seguir, você encontra um roteiro para criar um fluxo de aprovação do zero. Ele não depende de nenhum framework específico: você pode implementá-lo com qualquer ferramenta de orquestração de eventos e plataforma de mensagens instantâneas.
Primeiro passo: mapeie todas as ações do Agent
Liste todas as ferramentas que o Agent pode invocar e todas as ações que ele pode executar, como ler e gravar arquivos, excluir registros, chamar APIs externas, enviar mensagens e alterar configurações. Classifique cada item de acordo com três dimensões para criar uma “lista de riscos das ações”. Essa lista serve de base para todas as regras seguintes e ajuda a equipe a discutir os limites usando uma linguagem comum.
Segundo passo: centralize o gerenciamento das regras
Inspirando-se na forma como 卡兹克 usa o rules.json para centralizar gatilhos e agendamentos, inclua também na configuração central quais ações precisam de aprovação, em vez de espalhar essas regras pelos comandos de cada agente. Isso traz duas vantagens:
- Auditabilidade: qualquer pessoa pode ver quais operações exigem confirmação humana;
- Flexibilidade: quando for necessário restringir ou ampliar os limites, basta alterar um único lugar.
Observe que modificar essa configuração já é, por si só, uma “mudança de direção” e deve ser feito apenas por uma pessoa.
Terceiro passo: deixe o CI fazer as verificações automáticas primeiro
Antes de solicitar a aprovação humana, deixe que as verificações automáticas avaliem tudo o que puderem. A plataforma central de CI de 卡兹克 inclui cinco etapas: revisão, checagem, mesclagem, publicação e verificação. Isso significa que, quando uma decisão chega a uma pessoa, problemas básicos, como erros de formatação e falhas nos testes, já foram filtrados. Pessoas não deveriam fazer verificações que as máquinas podem fazer, assim como máquinas não deveriam tomar decisões que cabem às pessoas.
Quarta etapa: criar o cartão de decisão
Estas são nossas sugestões de design para o cartão de decisão, não detalhes do sistema original. A ideia central é permitir que a pessoa tome uma decisão em poucos segundos:
- Uma frase explicando a ação: por exemplo, “Excluir os registros de rascunho anteriores a março”;
- Dimensões de risco identificadas: indicar se a ação é irreversível, ultrapassa o orçamento ou muda a direção do trabalho;
- Escopo do impacto e valor: quantos registros serão afetados e qual é o custo estimado;
- Justificativa e evidências do agente: por que a ação é necessária e quais foram os resultados da verificação pelo CI;
- Botões de ação claros: aprovar, rejeitar e, quando necessário, oferecer a opção “Modificar e executar”.
Quinta etapa: definir o tempo limite e o comportamento padrão
As pessoas não ficam online o tempo todo. É preciso definir com antecedência quanto tempo um cartão pode ficar sem resposta e se, após esse prazo, o padrão será “não executar” ou “executar de forma limitada”. Para ações como excluir dados ou gastar dinheiro, o padrão deve ser “não executar”. É melhor deixar a tarefa aguardando do que interpretar o silêncio como autorização.
🚀 Comece rápido: na fase de prototipagem, vale usar um ponto de acesso unificado aos modelos para testar todo o fluxo: “Execução pelo agente → Verificação pelo CI → Aprovação no cartão”. Com a APIYI apiyi.com, você pode acessar vários modelos populares e alternar entre eles sem alterar a lógica de aprovação. Assim, fica mais fácil comparar a frequência com que cada modelo solicita aprovação e a qualidade das justificativas.
A divisão de tarefas entre a verificação por CI e a decisão humana
Muitas equipes se perguntam: se o CI consegue fazer as checagens, por que ainda precisamos de pessoas? A resposta é que cada um responde a perguntas diferentes. A tabela abaixo mostra essa divisão:
| Etapa | Pergunta respondida | Critério de decisão | Responsável |
|---|---|---|---|
| Revisão / checagem | O resultado está em conformidade com os padrões? | Regras, testes e formatação | Plataforma central de CI |
| Merge / publicação | Pode passar para a próxima etapa? | Todas as verificações foram aprovadas? | Plataforma central de CI |
| Verificação | O resultado realmente entrou em vigor? | Validação posterior | Plataforma central de CI |
| Excluir dados / gastar dinheiro / mudar de direção | É a decisão certa? | Avaliação de negócio e responsabilidade | Decisão humana |
| Origem da invocação do modelo | Qual modelo usar e quanto gastar? | Limites de orçamento | Regras de configuração + supervisão humana, com apoio da APIYI apiyi.com para consolidar o uso |
Perguntas frequentes FAQ
Q1: O que é o limite de decisão humana de um agente?
É uma regra que separa as ações que o agente pode executar sozinho daquelas que exigem confirmação humana. Dentro desse limite, o agente opera sem interrupções; ao alcançá-lo, pausa e deixa a decisão para uma pessoa. Esse limite costuma ser definido por três critérios: reversibilidade, impacto nos custos e mudança de direção.
Q2: Qual é a diferença entre aprovação humana e verificações automáticas de CI?
A CI responde à pergunta “está correto?” com base em regras e testes, uma tarefa adequada para máquinas. A aprovação humana responde “deve ser feito?”, com base em julgamento de negócio e responsabilidade. A primeira deve ser automatizada sempre que possível; a segunda deve ser usada com moderação e nos pontos certos. Juntas, elas permitem trabalhar com rapidez e segurança.
Q3: Como definir uma categoria vaga como “mudar de direção”?
O material original não informa como o autor define essa categoria. Nossa sugestão é tratar como “mudança de direção” qualquer ação que altere as regras ou os objetivos do próprio agente, assim como ações cujo resultado sirva de premissa para muitas tarefas posteriores. Na dúvida, é melhor exigir aprovação primeiro e ampliar gradualmente a autonomia conforme a experiência.
Q4: Em quais situações é mais importante estabelecer pontos de decisão humana?
Principalmente nestes casos:
– **Limpeza de dados**: exclusão periódica de registros ou arquivos expirados;
– **Publicação automática de conteúdo**: confirmação final antes da publicação externa;
– **Invocação do modelo em lote**: chamadas pagas que podem se multiplicar em um loop;
– **Ajustes estratégicos**: mudanças na direção dos temas, nas regras de agendamento etc.
Q5: Como controlar os gastos de um agente com Modelos de Linguagem Grande?
Recomendamos definir dois limites de orçamento: um por chamada e outro para o gasto acumulado. Dentro dos limites, o agente executa as tarefas sozinho; ao ultrapassá-los, solicita aprovação. Concentrar as invocações de modelos em uma plataforma de interface unificada como APIYI apiyi.com facilita o monitoramento do uso em relação aos limites e a análise posterior.
Q6: Como verificar rapidamente se os limites de aprovação são adequados?
Comece com um teste em pequena escala usando tarefas reais e registre o número diário de aprovações, a taxa de rejeição e o tempo médio de resposta. Muitas solicitações de aprovação com uma taxa de rejeição muito baixa indicam que o limite está rígido demais; problemas descobertos apenas depois indicam que está permissivo demais. No início, você pode usar APIYI apiyi.com para executar o mesmo conjunto de tarefas com vários modelos e observar as diferenças nas solicitações de aprovação.
Q7: Quais são as limitações dessa abordagem?
A aprovação humana depende da disponibilidade e da resposta das pessoas, o que pode gerar acúmulo de tarefas durante a madrugada ou em feriados. Se as informações no cartão estiverem incompletas, também pode haver erros de julgamento. Além disso, o material original que serviu de base para este artigo é um resumo: ainda não há detalhes públicos sobre casos de execução indevida sem aprovação nem sobre mecanismos específicos de proteção. Na implementação, é preciso acrescentar mecanismos de tempo limite, registro de logs e reversão adequados ao seu sistema.
Quando um Agent deve parar e consultar uma pessoa: pontos principais
- Princípio central: interrompa uma pessoa apenas em três situações: excluir dados, gastar dinheiro ou mudar de direção. Assim, cada aprovação mantém sua importância.
- Avaliação em três dimensões: classifique rapidamente qualquer nova operação por reversibilidade, impacto nos custos e mudança de direção.
- Divisão clara de responsabilidades: o CI verifica “se está correto”; a pessoa decide “se deve ser feito”. Um não substitui o outro.
- Atenção à fadiga: aprovações em excesso levam as pessoas a concordar por hábito, o que pode ser mais perigoso do que não pedir aprovação.
- Padrão conservador: se o prazo de resposta expirar, operações de alto risco não devem ser executadas.
- Ponto de acesso único: use a APIYI apiyi.com para centralizar a invocação de vários modelos, facilitando a gestão de limites de custo e a comparação entre modelos.
Resumo
Decidir quando um Agent deve parar e consultar uma pessoa é, no fundo, traçar uma linha clara entre eficiência e risco:
- Comece com três tipos de decisão: excluir dados, gastar dinheiro e mudar de direção cobrem a maioria dos cenários de alto risco;
- Amplie a análise com três dimensões: reversibilidade, impacto nos custos e mudança de direção ajudam a aplicar esses limites a qualquer nova operação;
- Use verificações automáticas para reduzir a carga: deixe o CI filtrar problemas básicos, enquanto as pessoas cuidam apenas do que realmente exige julgamento.
Esses limites não precisam ser definitivos: eles podem ser flexibilizados à medida que a confiança aumenta. Comece com regras rigorosas em uma fase de teste e use dados para decidir onde dar mais autonomia ao Agent. Durante a implementação e os ajustes, vale usar a APIYI apiyi.com para acessar diferentes modelos em um só lugar e testar rapidamente como cada um se comporta no seu fluxo de aprovação.
📚 Referências
- Digital Life 卡兹克 compartilha a arquitetura de um sistema de automação com Agents desenvolvido ao longo de um ano: fonte dos princípios e das informações de arquitetura deste artigo
- Link:
aihot.news/items/dzwfvd9xp6v4qaj6olxezpier - Descrição: apresenta uma arquitetura de quatro camadas — plataforma central de automação, execução por Agents, plataforma central de CI e tomada de decisões no Feishu — e o princípio de “recorrer a uma pessoa apenas para excluir dados, gastar dinheiro ou mudar de direção” (o material é um resumo; consulte o texto original para confirmar os detalhes)
Autor: Equipe técnica da APIYI
Troca de experiências técnicas: entre em contato conosco pela página inicial da APIYI, em apiyi.com, para trocar experiências sobre a implementação de automação com Agents e colaboração entre pessoas e IA. Para mais materiais, acesse a central de documentação em docs.apiyi.com.
