Quando a supervisão humana se aplica e o que fazer a seguir

A supervisão humana ao abrigo da Lei da UE sobre IA aplica-se como um requisito legal específico a sistemas de IA de alto risco. Não é satisfeito apenas porque um funcionário pode ver um resultado ou porque uma política diz que uma pessoa continua responsável. Os fornecedores devem conceber sistemas de alto risco para que pessoas singulares possam supervisioná-los de forma eficaz, enquanto os implantadores devem atribuir a supervisão a pessoas com a competência, formação, autoridade e apoio necessários.

Para uma equipe SaaS, a sequência prática é: classificar o sistema, identificar se a empresa está atuando como fornecedora ou implementadora, definir o que o ser humano pode realmente entender e mudar, testar o caminho de intervenção e reter evidências. Se o sistema não for de alto risco, a revisão humana ainda pode ser um produto, segurança, privacidade ou controle contratual apropriado – mas isso é diferente de reivindicar a aplicação do Artigo 14.

Por que a supervisão humana é importante na prática

A Lei da IA trata a supervisão como uma forma de prevenir ou minimizar os riscos para a saúde, a segurança e os direitos fundamentais que permanecem mesmo após a aplicação de outros controlos. O Artigo 14 diz que as medidas devem ser proporcionais aos riscos, autonomia e contexto de uso do sistema. Também espera que a pessoa designada seja capaz, quando apropriado, de compreender as limitações, monitorar a operação, reconhecer distorções de automação, interpretar saídas, desconsiderar ou reverter uma saída e parar o sistema com segurança.

Isso faz da supervisão uma capacidade operacional e não uma aprovação cerimonial. Um revisor sem tempo, informações do sistema, acesso ou autoridade não pode fornecer uma supervisão significativa. Nem pode uma pessoa intervir eficazmente se o produto apresentar uma recomendação como final, ocultar incerteza ou não oferecer nenhuma substituição utilizável.

Isso está intimamente ligado às expectativas de governança de IA para fornecedores de SaaS. Os compradores perguntam cada vez mais não apenas se um ser humano está “por dentro”, mas onde ocorre a intervenção e que evidências mostram que ela funciona.

Quando o requisito da Lei AI se aplica

Comece com a classificação e não com uma lista de verificação de supervisão. Nos termos do artigo 6.º, um sistema pode ser de alto risco através de duas vias principais:

1. É um produto, ou um componente de segurança de um produto, abrangido por legislação específica da UE em matéria de segurança de produtos e sujeito a avaliação de conformidade por terceiros.
2. A finalidade prevista enquadra-se num caso de utilização de alto risco do Anexo III, sujeito ao filtro do artigo 6.º, n.º 3, e às suas exceções.

O Anexo III abrange utilizações definidas em domínios como a biometria, infraestruturas críticas, educação, emprego, acesso a serviços essenciais, aplicação da lei, migração e administração da justiça. Ser “alimentado por IA”, processar dados pessoais ou influenciar um fluxo de trabalho comercial normal não torna automaticamente um sistema de alto risco nos termos do Artigo 6.º.

Para alguns sistemas do Anexo III, o artigo 6.º, n.º 3, prevê uma possível saída da classificação de alto risco quando o sistema não representa um risco significativo de danos e cumpre as condições enumeradas – por exemplo, quando executa uma tarefa processual ou preparatória restrita. A definição de perfis de pessoas singulares num caso de utilização do Anexo III continua a ser de alto risco. Um fornecedor que depende do filtro deve documentar essa avaliação.

A classificação depende muito da finalidade pretendida e da função real. Uma empresa SaaS pode ser o fornecedor quando desenvolve um sistema, ou quando desenvolve um, e o comercializa ou o coloca em serviço em seu próprio nome. Pode ser um implementador quando utiliza o sistema de IA de outro fornecedor sob a sua autoridade. Uma empresa também pode criar obrigações de fornecedor modificando substancialmente um sistema de alto risco ou alterando a sua finalidade pretendida de uma forma que o torne de alto risco. As equipas devem confirmar as regras transitórias atuais antes de tratar uma obrigação futura como já aplicável.

Leia a visão geral prática da Lei de IA da UE para provedores de SaaS junto com a avaliação de classificação.

Quando o Artigo 14 não se aplica

O Artigo 14 não é uma regra universal para todos os chatbots, resumos, recursos de recomendação, sinais de fraude ou copilotos internos. Se um sistema estiver fora do âmbito da Lei sobre IA, não for um sistema de IA ao abrigo da Lei ou não for classificado como de alto risco, o requisito do sistema de alto risco do artigo 14.º não se aplica a ele.

Isso não significa “nenhuma revisão humana necessária”. Outras obrigações podem surgir no âmbito da proteção de dados, do consumidor, do emprego, de regras setoriais, de segurança ou contratuais. Uma avaliação de risco também pode mostrar que a aprovação humana é o controlo mais proporcionado, mesmo sem um mandato legal específico.

Use uma linguagem precisa nos registros e nas respostas dos clientes:

• Requisito legal: “O sistema é de alto risco e estas medidas implementam os artigos 14 e 26.”
• Controle de risco: “O sistema não está atualmente classificado como de alto risco, mas a revisão humana é exigida por nossa política interna de risco.”
• Pergunta aberta: “A classificação depende da finalidade final pretendida e do contexto de implantação; o lançamento está bloqueado até que a avaliação seja aprovada.”

Essa distinção evita que as equipes exagerem na conformidade e facilita o gerenciamento de alterações posteriores.

Responsabilidades do provedor e do implementador

Provedores e implantadores têm trabalhos conectados, mas diferentes.

Provedores: supervisão do projeto no sistema

Um fornecedor deve traduzir a avaliação de risco em medidas técnicas e processuais utilizáveis. Dependendo do caso de uso, isso pode incluir:

• mostrar confiança, limitações e contexto de entrada relevantes;
• tornar visíveis anomalias e desempenho inesperado;
• evitar que a interface encoraje a aceitação cega;
• permitir que pessoas autorizadas ignorem, anulem, revertam ou interrompam saídas;
• definir quais medidas de supervisão o implantador deve implementar; e
• explicar claramente essas medidas nas instruções de uso.

O projeto deve corresponder às condições de trabalho previsíveis. Uma substituição oculta por trás de um fluxo de trabalho de administrador pode ser inútil quando um revisor da linha de frente precisa agir imediatamente.

Implantadores: tornar a supervisão operacional

O Artigo 26 exige que os implantadores de sistemas de alto risco atribuam a supervisão a pessoas singulares com a competência, formação, autoridade e apoio necessários. Os implantadores devem usar o sistema de acordo com suas instruções, monitorar sua operação, agir em relação aos riscos identificados ou incidentes graves e manter os logs gerados automaticamente sob seu controle por um período apropriado de pelo menos seis meses, a menos que outra lei aplicável estabeleça o contrário.

Operacionalmente, isso significa escolher funções nomeadas, proteger o tempo de revisão, controlar o acesso, definir o escalonamento e verificar se as instruções do provedor se ajustam à implantação real. Um funcionário não pode ser responsabilizado por uma substituição que não está autorizado a fazer.

Um fluxo de trabalho prático de supervisão humana

1. Escreva um registro de classificação com escopo definido

Registre o sistema, a finalidade pretendida, os usuários, as pessoas afetadas, as entradas, as saídas, o impacto da decisão, as funções do provedor/implantador e a rota considerada do Artigo 6. Vincule a conclusão à versão do produto e ao contexto de implantação. Reavalie quando alguma delas mudar.

2. Mapear decisões e modos de falha

Identifique onde o resultado da IA pode afetar uma pessoa, a segurança, o acesso, a priorização ou um processo regulamentado. Para cada ponto, descreva erros realistas: uma correspondência falsa, exceção perdida, classificação tendenciosa, resumo enganoso, recomendação insegura ou desvio de desempenho.

3. Defina a ação do humano, não apenas sua presença

Para cada decisão material, especifique:

• quais informações o revisor vê;
• o que devem verificar de forma independente;
• quando devem rejeitar ou escalar;
• se podem pausar, substituir ou reverter o resultado;
• a rapidez com que devem agir; e
• quem tem autoridade final.

Evite controles vagos, como “um gerente analisa quando necessário”. Um gatilho e uma regra de decisão tornam o controle testável.

4. Treine para a tarefa real

O treinamento deve abranger a finalidade pretendida do sistema, limitações conhecidas, sinais relevantes, viés de automação, usos proibidos, ferramentas de intervenção, manutenção de registros e escalonamento. Confirme a competência através de cenários, não apenas de atendimento. Isso complementa as perguntas mais amplas que as equipes devem fazer antes de adotar novas ferramentas de IA internamente.

5. Teste o caminho completo

Execute exercícios realistas. O revisor consegue identificar um resultado ruim? Eles têm contexto suficiente? A substituição funciona? Parar o sistema o deixa em um estado seguro? O evento está registrado? A escalada atinge alguém que pode agir?

Registre os defeitos e teste novamente após as correções. Uma captura de tela de uma tela de aprovação prova muito menos do que um cenário concluído com resultados esperados e observados.

6. Monitore e melhore

Rastreie substituições, reversões, escalonamentos, reclamações, detecções perdidas, discordâncias dos revisores e desempenho anormal. As tendências podem revelar uma formação fraca, uma interface inutilizável, entradas alteradas ou um sistema a funcionar fora do seu propósito aprovado. Defina limites que acionem investigação, suspensão ou reavaliação.

Erros comuns

• Classificação por rótulo do produto. O nome de um recurso não determina se o uso pretendido é de alto risco.
• Usar “humano no circuito” como todo o controle. Presença sem informação, tempo ou autoridade não é uma supervisão eficaz.
• A revisão após a consequência é irreversível. O ponto de intervenção deve ocorrer enquanto a pessoa ainda pode alterar o resultado.
• Deixar que o mesmo resultado seja validado. A verificação independente requer evidências adicionais, não uma segunda leitura da explicação da IA.
• Ignorando o preconceito de automação. Resultados repetidamente precisos podem diminuir a probabilidade de os revisores contestarem a falha excepcional.
• Deixando a propriedade com “o negócio”. Nomeie uma função responsável e um backup operacional.
• Não manter nenhuma evidência. As políticas por si só não mostram que os revisores foram treinados, que as substituições foram executadas ou que os problemas foram escalados.

Exemplo: triagem de candidatos assistida por IA

Suponha que um fornecedor de SaaS ofereça um software que classifica os candidatos a empregos para um empregador. As utilizações de IA relacionadas com o emprego enumeradas no Anexo III podem ser de alto risco, pelo que o fornecedor deve preencher e documentar a avaliação do Artigo 6, em vez de presumir que um recrutador que clica em “aprovar” resolve o problema.

Uma supervisão significativa pode exigir que o recrutador veja os factores relevantes para a recomendação, verifique as informações da fonte, identifique dados em falta ou enganosos, desconsidere a classificação, restaure um candidato e aumente a suspeita de preconceito sistemático. O empregador, como implementador, designaria pessoas treinadas com autoridade e monitoraria o sistema de acordo com as instruções.

Por outro lado, uma ferramenta interna que reformata um e-mail escrito pelo recrutador sem classificar os candidatos ou influenciar uma decisão de emprego pode não se enquadrar nesse caso de uso de alto risco. A equipe ainda pode proibir informações confidenciais e exigir aprovação humana antes do envio, mas deve documentar isso como um controle interno, em vez de descrevê-lo automaticamente como conformidade com o Artigo 14.

Perguntas frequentes

Qual é o propósito prático da supervisão humana?

O seu objectivo é permitir que pessoas competentes compreendam, monitorizem e intervenham para que os riscos residuais para a saúde, a segurança ou os direitos fundamentais possam ser evitados ou reduzidos. O fluxo de trabalho deve fornecer-lhes informações, tempo, ferramentas e autoridade reais.

Quando a supervisão humana se aplica às equipes de SaaS?

Os deveres específicos da Lei de IA se aplicam quando a equipe fornece ou implanta um sistema de IA de alto risco. Outros sistemas de IA podem ainda necessitar de revisão humana devido a outra lei, contrato, avaliação de risco ou política interna.

Uma aprovação humana final é suficiente?

Não automaticamente. A aprovação só é significativa se o revisor puder compreender as limitações relevantes, detectar problemas, desafiar o resultado e alterar ou interromper o resultado antes que ocorram danos.

O que as equipes devem documentar primeiro?

Comece com o registro de classificação e a finalidade pretendida. Em seguida, documente as pessoas responsáveis, revise os gatilhos, as informações mostradas, as intervenções permitidas, o caminho de escalonamento, o treinamento, os resultados dos testes e as evidências operacionais.

Cada decisão de IA deve ser verificada por duas pessoas?

Não. O artigo 14.º inclui uma regra específica de verificação por duas pessoas para determinados sistemas de identificação biométrica remota, com exceções definidas. Não é uma regra geral para todos os sistemas de IA de alto risco.

O que fazer agora

Classifique o caso de uso antes de prometer que a “supervisão humana” o resolverá. Se o sistema for de alto risco, conecte as medidas técnicas do provedor às pessoas, permissões e procedimentos reais do implementador. Em seguida, teste o caminho e guarde evidências de que um humano pode reconhecer problemas e agir a tempo.

Essa é a diferença entre uma pessoa próxima do sistema e uma supervisão humana eficaz.

Fontes

• Regulamento (UE) 2024/1689 (Lei de Inteligência Artificial)
• Artigo 6.º: Regras de classificação para sistemas de IA de alto risco
• Artigo 14: Supervisão humana
• Artigo 26.º: Obrigações dos implantadores de sistemas de IA de alto risco