Definição numa frase
Diseño que reserva a una persona una revisión, decisión o autorización dentro de un proceso automatizado.
Definição: uma intervenção humana em um ponto definido
Humano no circuito, ou human-in-the-loop (HITL), é um padrão de projeto no qual uma pessoa participa de uma etapa definida do funcionamento de um sistema automatizado. Ela pode revisar informações, classificar um caso, corrigir uma saída, autorizar uma ação ou fornecer feedback. O termo descreve a participação humana no processo, mas não determina, por si só, qual tarefa a pessoa executa nem quanta autoridade mantém.
Por isso, dizer que um sistema é HITL não significa necessariamente que uma pessoa examine cada entrada e cada resultado. A intervenção pode se limitar a casos duvidosos, ocorrer antes de uma ação específica ou fornecer informações para uma etapa posterior. Para entender o projeto, é preciso especificar o ponto de intervenção, as opções disponíveis para a pessoa e o que acontece com a decisão dela.
As definições introdutórias consultadas descrevem HITL como participação humana no ciclo de vida do aprendizado de máquina ou no funcionamento, na supervisão e na tomada de decisões de um processo. São formulações gerais, não uma especificação técnica única nem uma garantia de qualidade.
Onde uma pessoa pode intervir
A intervenção pode ocorrer em diferentes etapas. Na revisão das entradas, a pessoa verifica ou completa dados antes de o sistema processá-los. Na revisão das saídas, avalia uma recomendação ou classificação antes que ela seja usada. Em uma autorização prévia, decide se uma ação será executada. Durante a operação, pode acompanhar o processo e agir quando surge uma exceção. Depois, seu feedback pode ajudar a revisar regras ou preparar melhorias futuras.
Essas funções não são intercambiáveis. Revisar uma resposta não equivale a ter autoridade para bloqueá-la; aprovar uma transação não equivale a verificar como seus dados foram extraídos; e receber uma notificação não equivale a ter tempo e capacidade para intervir. Um projeto claro separa a tarefa da pessoa da tarefa automatizada e especifica o resultado produzido por cada uma.
Também é preciso definir o que acontece quando a pessoa não está disponível, não responde ou discorda do sistema. Se a operação continuar automaticamente depois de um prazo, essa regra faz parte do projeto. Se for interrompida, deve ficar claro quem resolverá o bloqueio. Sem essas condições, a expressão HITL deixa sem resposta uma parte prática importante.
Mapa de possíveis decisões
| Ponto de intervenção | O que a pessoa pode fazer | O que convém especificar |
|---|---|---|
| Antes do processamento | Revisar ou completar uma entrada | Quais dados ela vê e quais alterações pode salvar |
| Antes de usar uma saída | Corrigir, aceitar ou rejeitar uma recomendação | Se o sistema aguarda a decisão ou continua |
| Antes de executar uma ação | Autorizar, negar ou solicitar uma revisão adicional | Qual é sua autoridade e como a decisão é registrada |
| Durante uma exceção | Investigar, interromper ou encaminhar um caso | Quais sinais acionam a intervenção e quem responde |
| Depois do resultado | Fornecer feedback sobre o caso | Se o feedback altera uma regra, um processo ou um modelo |
Como funciona o ciclo de intervenção
Um ciclo HITL deve poder ser descrito do início ao fim. Primeiro, o sistema identifica o caso que exige participação humana ou apresenta todos os casos, se essa for a política escolhida. Depois, mostra à pessoa as informações necessárias para avaliar a situação. A pessoa dispõe de uma ou mais ações concretas. Por fim, o sistema aplica, registra ou encaminha a decisão de acordo com regras definidas previamente.
A interface e o contexto são tão importantes quanto a existência de uma etapa de revisão. Se a pessoa vê apenas uma pontuação sem conhecer seus limites, se faltam dados relevantes ou se não está claro o que é uma recomendação e o que já é uma decisão tomada, ela pode não estar em condições de avaliar o caso. O projeto deve permitir entender o que está sendo proposto, o que ainda está pendente e quais serão as consequências de aceitar ou rejeitar.
Uma implementação técnica pode pausar uma execução até receber uma decisão humana. Por exemplo, a documentação do LangChain descreve um mecanismo que pode interromper chamadas a ferramentas e aguardar uma decisão. Esse mecanismo ilustra uma forma específica de inserir uma pausa; não estabelece uma definição universal de HITL nem demonstra, por si só, que a revisão seja adequada para qualquer processo.
Processo que convém documentar
- 01Defina qual evento aciona a intervenção: todos os casos, uma exceção ou um limite estabelecido.
- 02Indique quais informações a pessoa recebe e quais elementos podem estar ausentes ou ser incertos.
- 03Enumere as ações permitidas: aceitar, corrigir, rejeitar, encaminhar, interromper ou reverter.
- 04Explique o que o sistema faz depois de cada ação e o que acontece se não houver resposta.
- 05Registre quem tomou a decisão, quando a tomou e quais informações tinha disponíveis.
Três exemplos práticos
Os cenários a seguir são exemplos de projeto, não afirmações sobre o funcionamento de um serviço específico. Em cada um, separamos o trabalho automatizado da decisão que fica a cargo de uma pessoa. Essa separação permite verificar se a intervenção é substancial ou se existe apenas uma possibilidade formal de encaminhar um caso.
Na moderação de conteúdo, o sistema pode classificar publicações e enviar para revisão humana aquelas que se enquadram em uma categoria duvidosa. O modelo pode organizar a fila ou propor uma categoria; a pessoa revisora examina o conteúdo e decide, dentro das regras aplicáveis, se o mantém, remove ou encaminha. O projeto deve esclarecer se a pessoa pode discordar da recomendação, quanto contexto recebe e o que acontece com os casos que aguardam por muito tempo. Uma fila de encaminhamento não significa que todas as decisões serão revisadas nem que a classificação inicial estará correta.
Na triagem de solicitações de saúde, um sistema pode ordenar pedidos ou sinalizar informações que exigem atenção. Em um exemplo de projeto, um profissional revisa as informações disponíveis e decide a prioridade ou a próxima etapa; a automação pode ajudar a organizar dados, mas esta descrição não pressupõe que ela possa emitir um diagnóstico nem que a pessoa receba todas as informações clínicas necessárias. É preciso especificar a autoridade profissional, a possibilidade de corrigir a classificação e o procedimento para casos urgentes ou incompletos. O rótulo HITL não basta para determinar se o processo é clinicamente seguro ou adequado.
Na automação de pagamentos, um sistema pode extrair campos de uma fatura e compará-los com os registros disponíveis. Se detectar uma divergência, uma pessoa pode revisar os dados e autorizar, rejeitar ou encaminhar o pagamento conforme sua função. A extração automatizada de informações não é o mesmo que a autorização: convém indicar quem valida cada etapa, quais evidências são apresentadas e se o pagamento fica bloqueado até a decisão. Também é preciso especificar o que acontece se não houver resposta ou se a pessoa detectar um erro depois que a operação tiver sido executada.
Conceitos próximos que convém distinguir
HITL é usado como um rótulo amplo para a participação humana em um processo. Não convém tratá-lo automaticamente como sinônimo de supervisão humana em sentido regulatório. A supervisão pode ter requisitos específicos conforme o contexto e o marco aplicável; as fontes consideradas aqui não bastam para descrever obrigações legais concretas. Portanto, esta ficha explica um padrão de projeto, não determina conformidade regulatória.
Também se usam expressões como human-on-the-loop para descrever uma pessoa que observa o funcionamento e pode intervir, e human-out-of-the-loop para um processo que opera sem intervenção humana individual nessa etapa. Esses rótulos são úteis como contraste geral, mas seu uso não é uniforme. Em uma implementação real, é mais preciso descrever as ações, a autoridade e o momento do que confiar apenas no nome do padrão.
A intervenção durante a operação deve ser distinguida do feedback usado para desenvolver ou ajustar um modelo. Em RLHF — aprendizado por reforço a partir de feedback humano — a participação humana é utilizada durante um processo de treinamento ou ajuste. O fato de pessoas terem fornecido feedback nessa etapa não implica que alguém revise cada decisão do sistema quando ele está em uso. Por outro lado, uma pessoa pode intervir durante a operação sem que sua decisão seja usada para treinar um modelo.
O aprendizado ativo também é diferente: em termos gerais, designa uma estratégia para selecionar exemplos que poderiam se beneficiar de anotação ou revisão. Essa seleção pode envolver pessoas, mas não determina, por si só, quem tem autoridade sobre uma ação operacional. As fontes verificadas para esta ficha não oferecem uma comparação técnica detalhada entre aprendizado ativo e RLHF; essas distinções devem ser entendidas como orientação conceitual, não como uma taxonomia completa.
Não confunda a presença humana com a função humana
| Conceito | Pergunta a que responde | O que não permite concluir por si só |
|---|---|---|
| HITL | Em que ponto uma pessoa participa? | Que ela revise todos os casos ou tenha autoridade suficiente |
| Supervisão humana | Como um sistema é supervisionado e em quais condições? | Que exista um único modelo aplicável a todos os contextos |
| RLHF | O feedback humano é usado em uma etapa de treinamento ou ajuste? | Que haja revisão humana de cada saída durante a operação |
| Aprendizado ativo | Quais exemplos são selecionados para revisão ou anotação? | Que a pessoa autorize ações do sistema |
Limites e erros frequentes
Uma etapa humana não garante, por si só, que o sistema seja seguro, preciso, eficaz ou esteja em conformidade com uma norma. Para detectar um problema, a pessoa precisa de informações pertinentes, tempo, conhecimentos adequados e autoridade para agir. Se algum desses elementos faltar, a intervenção pode existir no diagrama do processo sem funcionar como uma verificação efetiva.
Um risco de projeto é presumir que a pessoa detectará qualquer erro porque pode revisar uma recomendação. Ela pode não ter contexto, estar atendendo a casos demais ou não dispor de uma opção clara para rejeitá-la. Também pode haver pressão para aceitar a saída automatizada ou um caminho de encaminhamento que não leva a uma solução. Esses são limites possíveis que devem ser avaliados em cada contexto; as fontes consultadas não fornecem uma medição de sua frequência nem permitem quantificar seu efeito.
Outro erro é usar a revisão como um rótulo geral sem indicar seu alcance. «Há uma pessoa no circuito» não esclarece se ela vê todos os casos, apenas as exceções ou uma amostra; se revisa antes ou depois da ação; nem quem responde por uma decisão. Também não explica como corrigir uma saída equivocada ou se uma ação pode ser revertida.
Por fim, é importante não confundir supervisão com aprovação. Uma pessoa que pode observar uma tela, mas não interromper uma ação, tem uma função diferente daquela de quem precisa autorizá-la. Da mesma forma, uma pessoa disponível para receber um encaminhamento não equivale a alguém designado, informado e capacitado para resolvê-lo.
Critérios práticos para descrever um projeto HITL
Para avaliar ou documentar um sistema, descreva o ponto exato em que a pessoa intervém e qual acontecimento aciona essa intervenção. Indique se a participação é obrigatória, seletiva ou posterior à ação. Se apenas exceções forem revisadas, explique como elas são identificadas e quais casos podem ficar fora da revisão.
Especifique quais informações a pessoa vê, quais opções pode exercer e que autoridade respalda essas opções. Uma recomendação que pode ser aceita, corrigida ou rejeitada exige controles diferentes dos de um alerta que só pode ser reconhecido. Também convém indicar quem pode interromper o processo, solicitar uma segunda revisão ou reverter uma ação.
Descreva o que acontece se a pessoa não responder, não estiver disponível ou discordar do sistema. Defina os tempos de resposta pertinentes ao processo, sem presumir que um único prazo sirva para qualquer contexto. Registre decisões e alterações de modo que seja possível reconstruí-las: quem interveio, com base em quais informações e com que resultado.
Em conjunto, uma descrição útil responde a seis perguntas: onde a pessoa intervém; o que vê; o que decide; o que pode alterar; o que acontece diante de uma exceção ou da ausência de resposta; e como se avalia se o mecanismo funcionou como esperado. Essas perguntas tornam explícitas as responsabilidades que o rótulo, por si só, deixa em aberto.
Lista breve de avaliação
- 01Ponto: em que etapa do processo ocorre a intervenção?
- 02Contexto: quais informações e limitações são apresentadas a quem revisa?
- 03Autoridade: a pessoa pode corrigir, rejeitar, autorizar, interromper ou reverter?
- 04Exceções: o que acontece diante de uma divergência ou da ausência de resposta?
- 05Rastreabilidade: a decisão e seu resultado ficam registrados?
- 06Avaliação: quais evidências permitiriam verificar se a revisão cumpre seu objetivo?
Escopo das fontes
As fontes verificadas para esta ficha incluem explicações gerais de HITL, uma publicação institucional sobre mecanismos de intervenção e a documentação técnica de um mecanismo específico que pausa chamadas a ferramentas enquanto aguarda uma decisão humana. O escopo de cada uma é diferente: uma definição introdutória não equivale a uma norma, e a documentação de um produto não estabelece como todos os sistemas devem ser projetados.
Não foi fornecida uma fonte regulatória que permita resumir obrigações legais específicas, nem evidências que meçam a eficácia dos exemplos hipotéticos ou a incidência dos riscos descritos. Por isso, a ficha não afirma que um projeto HITL atende a requisitos regulatórios nem que a participação humana, por si só, produz resultados melhores. As categorias e os exemplos servem para formular perguntas de projeto que devem ser respondidas com evidências adequadas ao contexto.
