A CIO.com em 3 de setembro de 2026: o verdadeiro risco não é a ausência de humano no ciclo, é o seu desgaste — o teste de 3 perguntas, e onde a AppH se posiciona
Em 3 de setembro de 2026, a CIO.com publicou «When AI's human in the loop really isn't», de Grant Gross: além do problema já conhecido do botão de aprovação cosmético, o artigo aponta um segundo risco, mais insidioso — a fadiga de decisão. Quando um agente acerta 95% das vezes, a vigilância humana desgasta-se e a validação torna-se uma formalidade. O artigo propõe um teste concreto de três perguntas para distinguir um controlo humano real de um carimbo automático; é assim que o gate de aprovação do AppManager responde, sem se esconder atrás de adjetivos.
Segundo Grant Gross (CIO.com, 3 de setembro de 2026), a crítica ao «human-in-the-loop» superficial não pára na ausência de controlo real — Doug Shepherd (Cloudflare) descreve o caso mais comum como um humano «adjacente ao ciclo»: consegue ver e assinalar, mas não consegue realmente parar a ação. O artigo vai mais longe com um segundo problema, distinto e igualmente real: a fadiga de decisão. Eric Billingsley (TrustScale) diz sem rodeios: «Se o sistema acerta 95% das vezes, o trabalho da pessoa torna-se esperar pelo caso raro em que erra. Os humanos não são particularmente bons em vigilância sustentada... Com o tempo, a revisão torna-se confirmação.» Robert Blumofe (CTO da Akamai) confirma: a diligência esmorece, e o human-in-the-loop transforma-se em aprovação mecânica — a sua recomendação é acrescentar, além do humano, salvaguardas não-IA capazes de pausar o trabalho do agente automaticamente, sem esperar por um clique. Darren Kimura (AISquared) resume o teste que separa um controlo real de uma simples observação em três perguntas: o revisor consegue parar a ação antes de ela produzir efeito? Consegue alterar o resultado? As suas anulações ficam registadas e são realmente aplicadas a jusante? Se a resposta a qualquer uma destas perguntas for não, avisa Kimura, o humano está apenas a monitorizar a IA — não a controlá-la.
Sobre as três perguntas de Kimura, o gate de aprovação do AppManager responde claramente que sim às três. É possível parar a ação antes de produzir efeito? Sim — nenhuma ação de agente com consequência real é executada sem validação explícita do proprietário ou de um admin no módulo Automations, não é um alerta informativo que se possa ignorar. É possível modificá-la ou rejeitá-la? Sim, na mesma interface. A anulação fica registada e é aplicada a jusante? Sim — cada decisão (aprovada, modificada, rejeitada) deixa uma entrada no registo de auditoria por ator e por módulo, consultável depois. Sobre a fadiga de decisão, porém, a AppH não finge escapar-lhe por magia — é um risco real, também para nós. A nossa resposta não é contar com a vigilância eterna do proprietário, mas sim limitar por conceção quantas decisões chegam até ele: só as ações genuinamente consequentes (aprovar uma despesa, enviar um lembrete a um cliente, confirmar um reembolso) disparam o gate — não cada micro-passo do agente. O volume mantém-se baixo por conceção, não por disciplina humana. O que a AppH honestamente ainda não tem: a salvaguarda não-IA adicional que Blumofe recomenda, capaz de pausar um agente independentemente do clique humano — hoje, o gate de aprovação É a única salvaguarda.
A favor da AppH
- Sobre as três perguntas de Kimura — parar antes da execução, modificar, registar e aplicar a jusante — o gate da AppManager responde sim às três: não é supervisão cosmética, é um controlo que bloqueia mesmo, módulo a módulo.
- O número de decisões que chegam a um humano está limitado por conceção às ações com consequência real (dinheiro, comunicação externa, reembolso) — não a cada micro-tarefa do agente — o que limita estruturalmente o risco de fadiga de decisão que Billingsley descreve, sem depender apenas da vigilância do proprietário.
Contra / o limite honesto
- A AppH não tem uma salvaguarda não-IA adicional (a recomendação de Blumofe) capaz de pausar um agente automaticamente se a aprovação humana degenerar num carimbo — hoje, o clique de aprovação continua a ser o único mecanismo, sem rede por trás.
- Hoje nada mede se um determinado aprovador deriva para a aprovação automática ao longo do tempo (por exemplo, uma taxa de aprovação de 100% sem alterações durante vários meses) — o registo guarda cada decisão, mas ainda não deteta esse padrão de fadiga de forma proativa.
O que nos marcou nesta peça é que ela recusa a resposta fácil. Muitos artigos sobre human-in-the-loop param no primeiro problema — o botão que não bloqueia nada — e ficam por aí, satisfeitos por terem uma salvaguarda técnica. A CIO.com aponta um segundo problema que sobrevive mesmo quando o primeiro está resolvido: um controlo que bloqueia mesmo pode na mesma desgastar-se com o tempo, se a pessoa que o exerce acabar por aprovar sem olhar. Não vamos fingir que a AppH está imune a isso — seria exatamente o tipo de adjetivo sem prova que esta peça critica. O que podemos dizer com honestidade é que a nossa resposta não é pedir ao proprietário que esteja vigilante para sempre, é limitar por conceção o que ele tem de olhar ao que realmente importa. E quanto à salvaguarda não-IA que Blumofe recomenda, ainda não a temos — fica anotado, não escondido.
Verificado por um humano da AppH