30 de setembro de 2026 · KI · Automatisierung · Regulatorik · Mittelstand

A aprovação que ninguém vê

Uma aprovação pode funcionar como planeado e, ainda assim, esperar muito tempo sem ser notada. Porque monitorizar estados de espera em automação e agentes de IA.

Quem deixa automações ou agentes de IA assumirem tarefas inclui um ser humano nos pontos críticos: antes que uma alteração entre em produção, que dados saiam da empresa ou que algo deixe de ser reversível, alguém tem de aprovar. O princípio está correto, e os quadros regulatórios adotam-no. Sobre uma propriedade dessas aprovações, porém, raramente se fala: são invisíveis enquanto ninguém olha.

Um cenário típico

Suponha que um fluxo automatizado – uma sincronização de dados, um rollout de software, uma alteração de permissões – chegue a etapas que exigem uma aprovação humana. Estas ficam à espera durante muitas horas, sem que ninguém se aperceba. Nada está avariado. A porta de aprovação funciona exatamente como foi construída: para e espera. O que falha é apenas a sua visibilidade.

O motivo é estrutural. Um processo que espera de forma bloqueante por uma aprovação em geral não se manifesta por conta própria – afinal, está bloqueado. Visto de fora, um processo em espera parece um processo tranquilo: nenhuma mensagem de erro, nenhum alarme, nenhuma saída. Quem não verifica de forma direcionada toma o silêncio por operação normal ou por uma etapa de trabalho que ainda está em curso. E quem deveria conceder a aprovação talvez nem saiba que ela está pendente – o pedido está numa interface que ninguém abriu naquele momento.

Esses tempos de espera normalmente só se tornam visíveis depois, quando alguém analisa os carimbos de data e hora dos logs. Daí decorre uma segunda coisa: sem esses carimbos de data e hora, nem sequer a ordem de grandeza seria conhecida – apenas a vaga impressão de que «desta vez demorou um pouco mais».

O que os quadros regulatórios entendem por supervisão humana

O regulamento europeu da IA (Regulamento (UE) 2024/1689) trata, no artigo 14, da supervisão humana de sistemas de IA de risco elevado. Estes devem ser concebidos de modo que pessoas singulares os possam supervisionar efetivamente durante a sua utilização. O n.º 4 enumera o que as pessoas encarregadas da supervisão devem estar aptas a fazer. Isso inclui acompanhar o funcionamento para detetar anomalias, disfunções e desempenho inesperado, bem como «estar conscientes da possível tendência para confiar automaticamente ou confiar excessivamente nos resultados produzidos pelo sistema de IA de risco elevado (enviesamento da automatização)», desconsiderar, anular ou reverter o resultado e “intervir no funcionamento do sistema de IA de risco elevado ou interromper o sistema por meio de um botão de «paragem» ou de um procedimento similar”.

Se um sistema concreto se enquadra nessa disposição é uma questão de classificação caso a caso. Como referência, a ideia serve também onde o regulamento não se aplica.

O NIST AI Risk Management Framework (AI RMF 1.0, janeiro de 2023) formula isso como tarefa da organização: os processos de supervisão humana devem ser definidos, avaliados e documentados (MAP 3.5), e os papéis e responsabilidades na interação entre humanos e IA, claramente delimitados (GOVERN 3.2). O framework regista ainda que pode ser útil recolher dados sobre com que frequência e por que motivos as pessoas anulam os resultados de sistemas de IA em utilização.

Ambos os textos pressupõem que o ser humano está presente quando é necessário. Como fica a saber disso a tempo é assunto da implementação – e é exatamente aí que está a lacuna do cenário.

Esperar é um estado que tem de ser monitorizado

Do cenário podem derivar-se quatro regras. Valem para scripts, pipelines e ferramentas de workflow tanto quanto para agentes de IA – e tanto mais quanto mais autónomo for um fluxo, pois menos alguém o acompanha.

«A aguardar aprovação» passa a ser um estado próprio e monitorizado. Com o momento em que o pedido foi feito, um limite acordado e um alarme quando este for ultrapassado. O alarme vai para um responsável nomeado, com substituto, e não para uma caixa de entrada que ninguém lê. Como um processo em espera bloqueante em geral não se manifesta por conta própria, outro processo tem de consultar o estado – a monitorização vem de fora. O limite depende do que está à espera por trás da etapa: uma tarefa de rotina noturna tolera horas; uma alteração pela qual uma equipa está à espera, não.

Etapas sujeitas a aprovação são anunciadas antes de serem desencadeadas. Quem sabe que dentro de poucos minutos será necessária uma aprovação presta atenção. Uma mensagem curta para a pessoa que aprova não custa nada – e é a última notificação que o processo ainda consegue enviar por conta própria antes de ficar bloqueado.

A etapa sujeita a aprovação vai para o fim. Se estiver no meio do fluxo, tudo o que vem depois espera também – incluindo trabalho que nem precisa de aprovação. No fim, só se bloqueia a si mesma. Onde isso não for possível, etapas independentes devem ser concluídas antes ou continuar em paralelo.

Tempos de espera são medidos, não estimados. O início do pedido e o momento da decisão constam dos logs; a diferença é um indicador que pode ser analisado. Isto coincide com a indicação do framework do NIST de recolher dados sobre intervenções humanas: quem não mede como a supervisão de facto acontece não sabe se ela acontece.

Aprovações a mais também não são supervisão

A reação óbvia a uma aprovação despercebida seria incluir mais controlo. Isso apenas desloca o problema. Quem tem de confirmar dez vezes por dia, a certa altura confirma sem olhar. A aprovação torna-se formalidade, e a supervisão passa a existir apenas no papel – essa é a forma de enviesamento da automatização que o artigo 14 descreve, só que um nível acima.

O padrão é conhecido da área dos alertas. O BSI descreve no módulo DER.1 do IT-Grundschutz, como ameaça, que, com alertas mal configurados, podem ocorrer cada vez mais alarmes falsos; os responsáveis então «eventualmente já não conseguem distinguir entre um alarme falso e um evento relevante para a segurança» e possivelmente não se apercebem das notificações com rapidez suficiente. Para aprovações vale o mesmo. O livro de SRE da Google formula para alertas um princípio que pode ser transposto: «Every page should be actionable.» (todo o alerta deve exigir uma ação). Uma aprovação em que a pessoa que aprova não tem nada a decidir não é uma aprovação.

O outro extremo – nenhuma aprovação – também não é solução. O objetivo são poucas aprovações, mas significativas. Candidatas a isso são etapas que não podem ser revertidas de forma fiável, cujo efeito vai além da própria área de responsabilidade, em que dados saem da empresa ou em que são concedidas permissões. O que pode ser revertido de forma limpa e cujo resultado é verificado automaticamente em geral não precisa de um ser humano antes, mas de um controlo depois.

Checklist para aprovações em automações

  • Cada aprovação tem uma pessoa responsável nomeada, com substituto.
  • O estado «a aguardar aprovação» é visível, tem um limite e dispara um alarme.
  • A aprovação é anunciada antes de o processo ficar bloqueado.
  • A etapa sujeita a aprovação fica o mais tarde possível no fluxo.
  • Tempos de espera e decisões são registados em log e analisados regularmente.
  • O alarme para aprovações pendentes foi disparado pelo menos uma vez como teste e chegou de facto.
  • A lista de aprovações é revista regularmente para verificar se cada uma ainda cumpre a sua finalidade.

Como a sector7 apoia

Avaliamos consigo o que a sua utilização de IA desencadeia segundo o EU AI Act e definimos a classificação de risco, as obrigações de documentação e responsabilidades claras – mais em IA soberana. Ambientes sob a nossa gestão são monitorizados de forma automatizada pelo nosso NOC 24 horas por dia; anomalias detetadas são tratadas segundo os processos acordados em contrato, como descrito em Managed Services & Suporte.

Fontes

Vamos falar sobre a sua situação.

Marcar uma conversa+49 212 240915 0