Human-in-the-Loop Não É Supervisão. É Uma Disciplina de Conceção.

A Aprovação Que Não Era Aprovação

Na Marrowfield Specialty Risk, a auditoria à triagem de sinistros desta primavera produziu uma troca breve e embaraçosa. A corretora, com cerca de 150 colaboradores num mercado sob supervisão regulamentar, mantinha há dezoito meses um sistema de sinalização por IA. Mariela Okafor, Responsável de Operações de Sinistros, ocupava o cargo há doze anos. Os gestores de processos tratavam mais de 200 casos por dia; o modelo sinalizava cerca de 8 %. A auditoria extraiu dois números: 96 % de aprovação nos casos sinalizados pela IA e 23 segundos de tempo médio de revisão. A responsável de conformidade perguntou: «Que limiares afinou?» A resposta: «Nenhum. Limito-me a aprovar o que a IA me envia.»

A Marrowfield Specialty Risk é uma entidade compósita, construída a partir de entrevistas com corretoras especializadas do segmento intermédio e da literatura de conformidade do BoE/FCA e do EU AI Act. Os nomes estão anonimizados; as métricas ilustram padrões dos inquéritos citados.

Perante reguladores de três continentes, essa troca lê-se hoje como prova de supervisão em falta. A data de aplicação do EU AI Act, agosto de 2026, marca no calendário a falha de conceção, mas a falha é mais antiga do que o calendário.

§1 — A Aprovação Passiva É Teatro de Auditoria, Não Supervisão

O modelo mental por defeito — «a IA sinaliza, o humano aprova» — é estruturalmente indistinguível de não haver supervisão. Uma interface de um só botão, sem dados de entrada, sem raciocínio do modelo e sem grau de confiança produz exatamente as métricas que a Marrowfield trouxe à superfície. A assinatura operacional corresponde a um fluxo de trabalho totalmente automatizado com uma pessoa de prevenção.

Os dados de supervisão confirmam-no à escala da população. O inquérito AI in UK Financial Services 2024 do BoE/FCA concluiu que «55 % de todos os casos de utilização de IA têm algum grau de tomada de decisão automatizada, sendo 24 % desses semiautónomos, ou seja, embora possam tomar uma variedade de decisões por si próprios, foram concebidos para envolver supervisão humana em decisões críticas ou ambíguas» [9]. A implicação, coerente com o enquadramento do risco da configuração humano-IA do NIST AI 600-1: a maior parte da população de decisões automatizadas não tem um ponto de intervenção significativo.

Os reguladores agiram para fechar a lacuna. A posição do ICO é clara: uma decisão não sai do âmbito do Article 22 do UK GDPR «só porque um humano a 'carimbou'» [2]. A mesma orientação é mais incisiva quanto à prova operacional: os revisores que «concordam rotineiramente com os resultados do sistema de IA e não conseguem demonstrar que os avaliaram genuinamente» podem ser classificados como exclusivamente automatizados ao abrigo do UK GDPR [3]. O EU AI Act estabelece um teste paralelo no Article 14, exigindo que os sistemas sejam «concebidos e desenvolvidos de modo a ... poderem ser efetivamente supervisionados por pessoas singulares» [1]. A palavra efetivamente é determinante em ambas as tradições jurídicas. A questão de conceção já não é «está lá um humano?», mas «a conceção é tal que um humano consegue detetar, anular e interromper — e fá-lo-ia?».

§2 — O HITL É Um Sistema de Limiares, Não Um Passo de Revisão

O human-in-the-loop (HITL — intervenção humana no processo de decisão), tratado a sério, é um sistema: limiares de confiança explícitos, três vias de decisão, uma camada de ponderação pelo risco e uma política de filas. O modelo devolve um grau de confiança no intervalo 0,0–1,0, e aplicam-se três cortes — rejeição automática abaixo do limite inferior, revisão humana na faixa intermédia, aprovação automática acima do limite superior. Os pontos de partida conservadores para fluxos de trabalho regulados situam-se à volta de 0,3 / 0,95; as operações moderadas perto de 0,5 / 0,9; a classificação de baixo risco em 0,7 / 0,95. Os cortes são deliberadamente assimétricos: os falsos positivos e os falsos negativos têm custos diferentes, e o sistema de limiares codifica essa assimetria em vez de a esconder num único número. O NIST AI RMF 1.0 chega ao mesmo ponto — a sua função MANAGE «implica afetar recursos de risco aos riscos mapeados e medidos numa base regular» [5], e os limiares são o mecanismo de afetação, dimensionados pelo risco e não pela conveniência.

Por cima assenta uma camada ponderada pelo risco. A confiança multiplica-se por um grau de severidade do risco de negócio — dimensão do sinistro, irreversibilidade da decisão, exposição regulamentar — para produzir uma matriz de encaminhamento 3×3. Um caso de risco elevado e baixa confiança é escalado para o supervisor; um caso de risco elevado e confiança elevada continua a ser encaminhado para a revisão HITL padrão, e não para a aprovação automática. A escolha entre 2 níveis e 3 níveis importa: um sistema de 2 níveis canaliza todos os casos incertos para uma única fila, a fila transborda, os gestores de processos recorrem por defeito à aprovação em massa — o padrão que produziu a taxa de 96 % da Marrowfield. Um sistema de 3 níveis dá à rejeição automática um papel produtivo. O encaminhamento depende de uma estratégia de IA centralizada^EN, com uma pilha tecnológica sancionada a produzir uma pontuação de confiança consistente; a proliferação de ferramentas ad hoc impossibilita a disciplina de limiares, porque as pontuações de modelos diferentes não são comparáveis.

§3 — As Vias de Recurso São Concebidas, Não Implícitas

A «via de recurso» não é tratamento de erros. É o ramo explícito que o sistema percorre quando a IA está insegura, e precisa de um caminho, de uma pessoa e de um SLA. Três conceções cobrem o terreno.

Conceção A — humano no circuito, síncrona: a IA suspende e devolve o caso a uma fila com o registo de entrada, o raciocínio e a confiança anexados, contra um SLA de 2 a 4 horas; adequada a decisões quase em tempo real. Conceção B — fila para lote, assíncrona: a IA devolve uma resposta provisória e depois apresenta-a num lote diário ou semanal, com uma janela retroativa de anulação; adequada a trabalho não crítico em tempo. Conceção C — escalar para perito, hierárquica: encaminha em função da incerteza da IA mais a severidade do risco para um conjunto de revisores multinível (padrão → perito → supervisor), com SLA de 4h / 24h / 72h; adequada a decisões reguladas — referências de subscrição, triagem médica, sinalizações de conformidade.

Cada via de recurso precisa de um responsável designado e de um SLA documentado. O AI Playbook do UK DSIT coloca-o em termos operacionais — «processos de revisão e escalamento claramente documentados ... e um conselho de revisão de IA ou um conselho ao nível do programa» [4] — e o NIST AI RMF MANAGE traz a mesma instrução por outro ângulo, exigindo monitorização pós-implantação com canais de retorno designados. O antipadrão de auditoria é constante: uma fila genérica de «revisão humana» sem SLA e sem responsável, onde a fila cresce e a recomendação da IA se torna a decisão de facto. Na Marrowfield, a reconceção atribuiu cada via de recurso: os sinistros de pequeno valor abaixo de uma faixa de materialidade são processados automaticamente; os casos da faixa intermédia seguem a Conceção A com um SLA de 4 horas; os casos da faixa elevada e os abaixo do limiar seguem a Conceção C com subscritores designados. As filas deixaram de ser um único canal de transbordo e tornaram-se três linhas de produção com métricas e responsáveis próprios.

§4 — O Registo de Anulações É o Artefacto de Conformidade

O que os auditores inspecionam de facto é o registo de anulações. A ausência de registo, ou um registo sem fundamentação estruturada, falha o teste antes de qualquer defesa narrativa ser sequer ouvida. O artefacto mínimo por decisão HITL é um esquema fixo: case_id, confiança da IA, recomendação da IA, ID do revisor, duração da revisão em segundos, decisão humana, motivo da anulação, carimbo temporal, policy_version. Sem policy_version, a pista torna-se ininterpretável um ano depois, porque os limiares terão mudado. O Article 14(4) do EU AI Act exige que os revisores possam «intervir no funcionamento ... ou interromper o sistema» [1] — e o corolário operacional é que a capacidade tem de deixar registo, ou então não aconteceu. O NIST AI 600-1 coloca-o ao nível da ação: «Monitorizar e documentar os casos em que operadores humanos ou outros sistemas anulam as decisões da IA generativa» [6]. O registo é a prova central de uma revisão significativa.

A responsabilização situa-se a montante do registo. O AI Update do FCA fixa o princípio: «linhas de responsabilidade claras estabelecidas ao longo de todo o ciclo de vida da IA» [10]. As empresas britânicas sujeitas ao SM&CR atribuem a pilha de IA e operações à função de Chief Operations; as empresas norte-americanas mantêm comités de IA ao nível do conselho de administração; as empresas da UE seguem a orientação da EBA e do BCE sobre a responsabilização da direção de topo. O princípio é transferível entre as três tradições, o que torna construir governação de IA desde o primeiro dia mais barato do que a adaptação posterior. A norma ISO/IEC 42001:2023 enquadra o conjunto de controlos mais amplo como «uma abordagem integrada à gestão de projetos de IA, da avaliação do risco ao tratamento eficaz desses riscos» [8].

Os auditores procuram sinais inversos. Uma duração de revisão inferior a 10 segundos lê-se como validação meramente formal. Uma taxa de aprovação acima de 98 % lê-se como ausência de revisão. Um campo de fundamentação vazio lê-se como significância não documentada. Mais de 200 decisões por dia por revisor lê-se como fadiga. Cada um é, por si só, uma constatação de auditoria.

§5 — Como É Que a Afinação Trimestral Mantém o HITL Honesto?

Os limiares não se definem e esquecem. Os modelos derivam, as regras de negócio mudam, surgem casos-limite. Um ciclo trimestral é a disciplina mais barata que impede um sistema HITL bem concebido de regredir para teatro, e tem peso entre jurisdições: o teste de supervisão «efetiva» do Article 14 é insatisfazível sem ele, e o NIST AI RMF MANAGE espera «planos para hierarquizar o risco e para a monitorização e melhoria regulares» implementados [5].

Mês um — medir a linha de base: volume HITL por semana, taxa de anulação por faixa de confiança, distribuição do tempo até à decisão, taxa de escalamento por nível. Mês dois — identificar sinais de deriva: as faixas em que a anulação excede 20 % significam que o modelo é pouco fiável e que a faixa HITL precisa de alargar ou o modelo de ser retreinado; as faixas abaixo de 2 % podem estreitar com segurança; os casos da Conceção B sem revisão dentro da janela significam que o processo em lote está avariado. Mês três — ajustar e documentar: atualizar as definições dos limiares, incrementar a policy_version com o motivo da alteração, notificar as operações, repor a linha de base.

O ciclo pressupõe uma cultura de revisão que apoie a anulação. O ICO é explícito: a revisão significativa exige que «os revisores tenham autoridade para anular o resultado gerado pelo sistema de IA e tenham a confiança de que não serão penalizados por o fazer» [3]. A mesma expectativa consta da contratação pública norte-americana ao abrigo do NIST AI RMF e das regras de responsabilização da UE ao abrigo da EBA e do BCE — jurisdições diferentes, teste operacional idêntico. Onde a cultura pune o desvio, as taxas de anulação colapsam por razões culturais e não técnicas, e os dados de que o ciclo depende tornam-se ininterpretáveis. O Playbook do UK DSIT designa a propriedade: um conselho de revisão de IA ou um conselho ao nível do programa é dono do ciclo [4]. A resposta típica do segmento intermédio a «quem é o dono disto» é uma promoção interna — veja-se a argumentação a favor de a melhor contratação de um Responsável de IA^EN estar dentro de casa.

§6 — Que Cinco Antipadrões Falham Uma Auditoria ao Article 14?

Os mesmos cinco modos de falha aparecem em todas as auditorias.

Interface de aprovar/rejeitar de um só botão. O revisor vê apenas a decisão. Sintoma: taxas de aprovação acima de 95 %, revisões de menos de 10 segundos. Correção: expor a confiança, o registo de entrada e os fatores de incerteza declarados. O Article 14(4)(b) é explícito quanto ao enviesamento de automação — os revisores têm de «continuar conscientes da possível tendência para confiar automaticamente ou confiar em excesso nos resultados produzidos por um sistema de IA de risco elevado» [1].

Revisor único, sem rotação. Um único diretor de operações revê todos os casos HITL. Sintoma: estrangulamentos ao fim de semana, erros de fadiga ao fim do dia, um único ponto de falha. Correção: um conjunto formado de 3 a 5 revisores num calendário de rotação documentado.

Limiar definido uma vez, nunca afinado. Os valores predefinidos do fornecedor mantêm-se inalterados. Sintoma: volume HITL muito afastado da faixa; taxas de anulação suspeitosamente baixas ou cronicamente acima de 20 %. Correção: o ciclo trimestral do §5.

Sem captura do motivo da anulação. Os revisores podem anular, mas o campo de fundamentação é opcional ou está vazio. Sintoma: não se consegue demonstrar a significância. Correção: captura estruturada — uma lista pendente com os três principais motivos mais um campo de texto livre, ambos obrigatórios.

Fila de recurso sem SLA. Os casos são encaminhados para «revisão humana» sem responsabilidade por os resolver dentro de uma janela definida. Sintoma: comprimento da fila a crescer de mês para mês, revisores a saltar as entradas mais antigas. Correção: um SLA explícito por via de recurso, mais um painel de monitorização de filas com um responsável designado. A propriedade difusa é o risco estrutural; o inquérito do BoE/FCA observa que a responsabilização «é frequentemente dividida, com a maioria das empresas a reportar três ou mais pessoas ou órgãos responsáveis» [9], e o Article 14 do EU AI Act coloca a supervisão numa «pessoa singular» designada [1].

§7 — O Article 14 e o Calendário de Agosto de 2026

O enquadramento de conformidade não é teatro específico de uma jurisdição. Vários reguladores convergem para o mesmo teste operacional; o EU AI Act associa-lhe o prazo mais público. O Article 113 fixa a data de aplicação das obrigações de risco elevado — incluindo o Article 14 — em 2 de agosto de 2026 [1]. A partir dessa data, as empresas que implantem IA em âmbitos de risco elevado do Anexo III (emprego, notação de crédito, infraestruturas críticas, dados de aplicação da lei) passam a ter a obrigação.

O UK GDPR Article 22 já é vinculativo, e o seu teste é o de «contributo humano significativo» [3] — autoridade, competência, ponderação dos dados de entrada e das alternativas, uma cultura de apoio e ausência de penalização por anular o modelo. Onde o Article 22 se aplica — sempre que uma decisão tem efeito jurídico ou semelhante significativo —, «carimbar» falha o teste [2]. A posição norte-americana não está ausente: estatutos ao nível estadual (Colorado AI Act, NYC AEDT, as regras ADMT propostas na Califórnia) e a aplicação setorial (a FTC sobre decisões automatizadas, o NIST AI RMF como referência de contratação para uso federal) impõem a mesma disciplina. A norma ISO/IEC 23894:2023 normaliza a abordagem subjacente de gestão do risco como «orientação sobre o modo como as organizações ... podem gerir o risco especificamente associado à IA» [7] — a âncora não regulamentar mais limpa para os mercados cujos estatutos específicos de IA ainda não entraram em vigor, e a espinha dorsal de qualquer política operacional multijurisdicional.

Os reguladores setoriais reforçam o ponto: o FCA é agnóstico quanto à tecnologia [10], os equivalentes da UE ao abrigo da EBA e do BCE alinham na responsabilização da direção de topo, e o inquérito de 2024 do BoE/FCA mostra que a responsabilização está tipicamente fragmentada por três ou mais partes responsáveis na maioria das empresas inquiridas [9].

As questões de conceção dos §§2–5 são as questões de conformidade nas três tradições jurídicas. Construir o HITL desta forma paga-se uma vez; adaptá-lo depois de uma auditoria falhada paga-se todos os trimestres.

§8 — Como É o Sprint de Conceção HITL de Quatro Semanas?

A reconceção é delimitada: um sprint de Responsável de Operações, não um programa.

Semana 1 — Medir o estado atual. Inventariar todos os passos de «revisão humana». Extrair as taxas de aprovação, as distribuições de duração da revisão, o estado da captura de anulações e os comprimentos das filas. Assinatura da aprovação passiva: taxa de aprovação elevada, duração de revisão baixa, sem fundamentação estruturada da anulação.

Semana 2 — Conceber as vias de decisão. Definir os cortes de confiança por fluxo de trabalho a partir dos pontos de partida do §2. Conceber as vias de recurso conforme o §3. Definir o esquema do registo de anulações conforme o §4. Documentar a policy_version v1.0 com os valores dos limiares, os responsáveis e os SLA.

Semana 3 — Implementar, formar, recolher dados. Ligar as alterações da interface — expor o raciocínio do modelo e a confiança no ecrã do revisor. Formar o conjunto de revisores com exemplos resolvidos. Iniciar a operação ao vivo com registo de auditoria completo desde o primeiro dia.

Semana 4 — Primeira revisão de afinação e documentação pronta para auditoria. Executar o ciclo do §5 com os dados da semana 3; os sinais de deriva óbvios surgem mesmo numa janela curta. Reunir o conjunto de artefactos: definições dos limiares, painel da taxa de anulação, inventário das vias de escalamento, mapa de propriedade. O resultado é a posição com que testar as 50 perguntas que os decisores fazem antes de implementar IA^EN, que cobre as Q3.10, Q5.4, Q5.5 e Q5.7.

Faixa de custo: 20 a 40 horas de tempo de Responsável de Operações. Resultado: um protocolo de supervisão pronto para o Article 14, uma posição de «revisão significativa» defensável ao abrigo do Article 22 e uma função MANAGE alinhada com o NIST RMF.

Da Aprovação à Disciplina

Quatro semanas após a reconceção, o quadro operacional mudou. O volume HITL no fluxo de trabalho de sinistros caiu 70 %, porque a rejeição automática está a fazer trabalho real na faixa abaixo do limiar. O tempo médio de revisão nos casos que chegam ao HITL subiu para cerca de quatro minutos — o tempo que a revisão estruturada de facto leva. A taxa de anulação estabilizou nos 14 %, dentro da faixa saudável de 5–20 %, com cada caso anulado a transportar fundamentação estruturada. A pergunta da responsável de conformidade tem agora uma resposta com números de versão anexados.

A diferença entre o teatro de auditoria e a supervisão defensável em auditoria não está no grau de seriedade com que uma empresa fala de revisão humana. Está em saber se a revisão é um sistema de limiares concebido ou uma aprovação com um só clique. Um passa o Article 14. O outro não.

Para uma leitura de onde se situa a conceção HITL nos fluxos de trabalho regulados de uma organização, o easy-audit.ai mapeia-a em duas horas de perguntas estruturadas.

Síntese

HITL — designed oversight, not passive sign-off
│
├─ The failure · audit theatre
│   ├─ Passive sign-off — one-click approve, no reasoning shown
│   └─ Rubber-stamp test — >98% approve, <10s review fails it
│
├─ The system · thresholds & routes
│   ├─ Three routes — auto-reject / HITL review / auto-approve
│   ├─ Risk overlay — confidence × severity sets escalation
│   └─ Fallback paths — named owner, SLA, override audit log
│
└─ The discipline · stays honest
    ├─ Healthy band — 5–20% override; outside it, tune or retrain
    └─ Quarterly cycle — measure, spot drift, re-version, document