Humano no circuito não é uma configuração. É uma linha traçada por processo, e traçá-la depois do build produz um carimbo que ninguém lê.
Conteúdo6 seções
A configuração que não é configuração
Humano no circuito aparece na maioria das propostas de IA como uma caixinha. Está marcada, o cliente se tranquiliza e a conversa passa para o cronograma.
Depois o sistema entra no ar, e a fila de revisão acaba tendo quatrocentos itens por dia, e na terceira semana alguém a esvazia em lotes às seis da tarde sem ler. A taxa de aprovação é de noventa e nove por cento. A trilha de auditoria diz que um humano aprovou cada um.
Isso é pior do que não ter revisão, porque fabrica evidência de supervisão que não aconteceu.
A linha se move por processo
A única pergunta que produz um limite útil é quanto custa aqui uma saída errada.
- Reversível, interno, barato de corrigir: roda sem supervisão e com monitoramento.
- Voltado ao cliente, irreversível ou caro de desfazer: uma pessoa decide antes de ter efeito.
Essas duas categorias raramente coincidem com departamentos, sistemas ou hierarquia, e é por isso que uma política corporativa sempre acaba no lugar errado. Um rascunho de nota interna e uma mensagem de saída para um cliente não são o mesmo tipo de erro e não podem compartilhar regra.
Os quatro comportamentos a que isso se reduz na prática estão em o arcabouço de IA segura.
O que entra na especificação
Escrito antes do build, não depois.
O que o revisor vê. Não a saída crua. A saída mais o necessário para julgá-la: a origem, um sinal de confiança, como casos parecidos foram resolvidos na semana passada.
O que ele está decidindo. Uma pergunta com poucas respostas, não um convite a dar uma olhada.
O que acontece na rejeição. De volta à fila, escala para uma pessoa nomeada, ou cai no caminho manual. É a parte mais deixada sem definição, e é a que decide se a revisão é real: uma rejeição sem destino acaba virando aprovação.
Medir se funciona
Dois números, ambos desconfortáveis.
Taxa de rejeição. Em zero ou perto disso, a revisão não está acontecendo, e o painel não distingue um sistema preciso de uma fila não lida.
Tempo mediano de decisão. Quatro segundos não é uma decisão.
Quando os dois parecem ruins, a causa costuma não ser indisciplina. É que a linha foi traçada larga demais e o revisor está se afogando. Estreitá-la às saídas que de fato carregam custo devolve a atenção às que importam.
O que quebra sem a etapa
Duas falhas, opostas em forma e idênticas no desfecho.
Apertada demais, e você construiu uma fila que ninguém esvazia com honestidade. Frouxa demais, e o primeiro erro irreversível ensina onde a linha deveria estar, na frente de um cliente.
As duas vêm da mesma raiz: a linha foi traçada depois que o sistema já existia, por quem estivesse na sala quando deu errado. Traçada durante o Cast, contra o custo medido de uma saída errada, ela é decisão de projeto. Traçada depois, é um pedido de desculpas com um fluxo anexado.
Onde ela fica
Cast é a quinta de seis etapas, e a outra metade dela é construir contra uma especificação congelada em vez de contra uma conversa. As duas metades protegem da mesma coisa que afunda a maioria dos deploys conversacionais, descrita em por que seu último chatbot falhou. A sequência completa aplicada a um deploy está em o protocolo de ponta a ponta.
Perguntas frequentes
Por que uma política de humano no circuito para a empresa toda é má ideia?
Porque ela fica ou rígida demais para ser usada ou frouxa demais para proteger alguma coisa, e na prática vira as duas coisas em pontos diferentes do mesmo sistema. Coloque a política em tudo é revisado e você criou uma fila que uma pessoa esvazia em lotes no fim do dia sem ler, o que é pior do que não ter revisão porque fabrica uma trilha de auditoria dizendo que um humano aprovou. Coloque em nada é revisado e o primeiro erro irreversível vai lhe ensinar onde a linha deveria estar. A linha precisa se mexer por processo, porque o custo de uma saída errada se mexe por processo: uma nota interna arquivada errado e uma mensagem incorreta a um cliente não são o mesmo tipo de erro e não podem compartilhar política.
O que entra exatamente na especificação?
Três coisas, todas concretas. O que o revisor vê, que não é a saída crua e sim a saída mais o contexto necessário para julgá-la: o documento de origem, o sinal de confiança, os casos parecidos decididos na semana passada. O que se pede que ele decida, colocado como uma pergunta com poucas respostas e não como um convite a dar uma olhada. E o que acontece na rejeição: se o item volta para a fila, escala para uma pessoa nomeada ou cai no caminho manual. Esse terceiro é o mais omitido e é o que determina se o passo de revisão é real, porque uma rejeição sem destino definido acaba virando uma aprovação.
Como saber se a revisão funciona ou está sendo carimbada?
Medindo a taxa de rejeição e o tempo gasto. Um passo de revisão com taxa de aprovação em cem por cento ou perto disso não é evidência de que o sistema é preciso, é evidência de que ninguém lê, e as duas coisas são indistinguíveis pelo painel. O mesmo vale para o tempo de revisão: se a decisão mediana leva quatro segundos, a decisão não está sendo tomada. O remédio normalmente não é mais disciplina e sim uma fila menor: o revisor está se afogando porque a linha foi traçada larga demais, e estreitá-la às saídas que de fato carregam custo devolve a atenção às que importam.
O limite se move depois do go-live?
Deveria, numa direção e sobre evidência. O caminho normal é uma categoria de saída que exigiu revisão no primeiro mês acumular decisões corretas suficientes para ser liberada a rodar sem supervisão, e essa liberação é uma mudança deliberada com data, não uma deriva. Mover na outra direção, apertar o limite, é mais raro e sempre vem depois de um incidente. O que não pode acontecer é movimento silencioso: um limiar afrouxado em silêncio para esvaziar um atraso é como um sistema acaba sem revisão efetiva enquanto a documentação ainda descreve uma, que é o estado real da maioria dos deploys de IA auditados.
