Quem pode parar um modelo quando ele erra?

Supervisão humana não é uma pessoa ao lado do modelo. É a autoridade, a evidência e o estado seguro que permitem a alguém recusar um resultado, interromper...

Quem pode parar um modelo quando ele erra?

The European Union's Artificial Intelligence Act uses a surprisingly physical word for a digital obligation. Article 14 says that people assigned to oversee a high-risk AI system must be able to intervene, or interrupt the system through a stop button or similar procedure that allows it to come to a halt in a safe state. The sentence is about software. It reads like someone has sensibly remembered that machines can be switched off.

That memory is more important than it sounds. In many organisations, human oversight is treated as the presence of a person somewhere near the system. A reviewer receives a recommendation. An operator can open a dashboard. A manager is named in a policy. A support address exists for complaints. The arrangement is then described as human-in-the-loop, as if a human being had been placed inside a loop and the loop had consequently become wise.

The real question is harder and more useful: when the model is wrong, uncertain, outside its approved purpose or behaving in a way that the evidence cannot support, who has the authority to stop the work? Who can pause new actions without waiting for a supplier? Who can prevent already-generated outputs from becoming decisions? Who can preserve the state that needs investigating? Who can reopen the route, and on what evidence? A person who can notice a problem but cannot alter the system is a witness. A person who can click a button but does not know what the button stops is operating a prop.

This is why the right to stop has to be designed before deployment. It needs a named role, a scope, a safe state, an evidence trail, a route for escalation and a way back into service that does not quietly reintroduce the same failure. It needs enough technical detail to work when the system is busy, the supplier is unavailable and the person who built the original workflow has moved to another project. It also needs enough institutional clarity that a person can use the authority without being accused of having interrupted innovation.

A stop is a capability, not a courtesy

Stopping is often described as a last resort, which gives it an unfortunate ceremonial quality. The organisation promises that somebody may stop the system if the circumstances become serious enough. The circumstances arrive. The person looks for the authority. The authority turns out to be a paragraph in a document, a permission held by another team, or an escalation address that is monitored during office hours. The system continues, very politely.

A stop is not a mood. It is a capability with an interface and a contract. The interface may be a button, a command, a policy gate, a revoked token, a disabled route, a queue hold or a controlled shutdown. The contract says what the action does, what it does not do, which work is prevented, which work is allowed to finish, what state is retained, who is notified, and how the organisation knows that the stop took effect. If those answers are missing, the word stop means only that everyone agrees stopping would be nice.

There is a useful distinction between stopping a model and stopping a consequence. A model can be running while its outputs are held for review. A service can remain available for low-impact drafting while its recommendation route is closed. A tool can return read-only information while write access is withdrawn. A workflow can accept new cases but refuse to advance them into an external decision. These are different control surfaces. Treating them as one large red switch either stops too little or destroys more work than necessary.

Proporcionalidade importa, mas proporcionalidade não é autorização para tornar a intervenção vaga. Um assistente de baixo risco pode precisar de uma recusa local e de um caminho para um humano. Um sistema utilizado num domínio de alto impacto pode precisar de uma barreira rígida antes de um resultado poder afetar os direitos de uma pessoa ou o acesso a um serviço. Uma ferramenta autónoma que pode alterar um registo externo pode precisar de uma via de intervenção separada de um modelo que apenas escreve um rascunho. O risco, o grau de autonomia e o contexto de utilização determinam a força do controlo. Não eliminam a necessidade do controlo.

A linguagem do Regulamento IA é útil precisamente porque liga a supervisão humana a um objetivo de risco real. A supervisão destina-se a prevenir ou minimizar riscos para a saúde, a segurança e os direitos fundamentais. Não serve para decorar um sistema com uma silhueta humana. Se a pessoa designada não conseguir reconhecer uma anomalia, interpretar um resultado, anulá-lo ou parar a operação em segurança, o acordo não cumpriu o objetivo prático da supervisão, independentemente de quantas assinaturas constem do ficheiro do projeto.

Leia o artigo 14.º como uma especificação de engenharia

O artigo 14.º aplica-se a sistemas de IA de alto risco, não a qualquer software que tenha adquirido um rótulo de IA. O seu primeiro requisito é que o sistema seja concebido e desenvolvido para que pessoas singulares possam supervisioná-lo eficazmente durante a sua utilização. A expressão durante a sua utilização é importante. Uma revisão no momento da aquisição não é supervisão de um sistema em funcionamento. Uma formação ministrada antes do lançamento não é supervisão de um modelo alterado. Uma explicação após um incidente não substitui um controlo que poderia ter prevenido a ação.

O segundo requisito dá um propósito à supervisão. Deve prevenir ou minimizar riscos que surjam quando o sistema é utilizado para o fim a que se destina ou sob uma utilização indevida razoavelmente previsível. Esta redação resiste a um truque conveniente em que a organização trata toda a utilização prejudicial como uma surpresa imprevisível. As pessoas utilizarão os sistemas sob pressão, com informação incompleta, através de traduções, em combinações invulgares e no limite das instruções. Um design sério pergunta que utilização indevida é razoavelmente previsível e dá ao revisor uma forma de responder antes de o resultado adquirir força institucional.

O terceiro requisito torna a supervisão proporcional ao risco, à autonomia e ao contexto. O fornecedor pode incorporar medidas no sistema e pode também especificar medidas que o utilizador deve implementar. Esta é uma divisão de trabalho, não uma divisão de responsabilidade. Um fornecedor não pode entregar um sistema sem forma exequível de o interromper e apontar para o utilizador. Um utilizador não pode ignorar os limites fornecidos e dizer que o fornecedor prometeu segurança em abstrato. O controlo deve sobreviver à fronteira entre a coisa entregue e a forma como é utilizada.

O número quatro é onde a linguagem jurídica se torna uma lista de verificação prática. As pessoas designadas para a supervisão devem ser capazes de compreender as capacidades e limitações relevantes do sistema. Devem ser capazes de o monitorizar, incluindo anomalias, disfunções e desempenho inesperado. Devem estar cientes do enviesamento de automatização, a tendência para confiar ou confiar em excesso num resultado de máquina. Devem ser capazes de interpretar o resultado. Devem ser capazes de decidir não o utilizar, ignorá-lo, anulá-lo ou revertê-lo. Por fim, devem ser capazes de intervir ou interromper a operação através de um botão de paragem ou procedimento semelhante que a conduza a um estado seguro.

Cada verbo cria uma obrigação de design diferente. Compreender exige informação utilizável sobre o âmbito e as limitações. Monitorizar exige sinais, tempo e um caminho para os inspecionar. A consciência do enviesamento de automação exige formação e uma interface que não transforme uma recomendação num veredicto por defeito. Interpretar exige evidência e contexto. Anular exige autoridade e um registo de discordância. Interromper exige uma transição de estado que seja mais segura do que continuar. Um único painel verde não pode satisfazer cinco verbos diferentes apenas por ser grande.

O Regulamento inclui também uma regra mais específica para certos sistemas de identificação biométrica de alto risco. Nos casos abrangidos pela disposição, uma decisão não pode ser tomada com base no resultado da identificação, a menos que tenha sido separadamente verificada e confirmada por, pelo menos, duas pessoas singulares competentes, formadas e autorizadas, sujeita às exceções legais previstas. Este é um exemplo europeu concreto de supervisão expressa como autoridade independente, em vez de um revisor isolado a clicar numa recomendação. Mostra também porque é que o design tem de nomear o tipo de decisão e a evidência necessária para ela.

O artigo 14.º não prescreve um modelo único universal de pessoal. Estabelece um limite. A pessoa deve ter competência, formação e autoridade suficientes para desempenhar a função. O fornecedor e o utilizador devem tornar o controlo proporcional ao sistema. A organização continua a ter de decidir quais as funções que executam quais ações, quando é obrigatório parar, como é tratado um caso suspenso e o que conta como retoma segura. A lei pode exigir a porta. Não pode escolher a pessoa que tem a chave em cada edifício.

Parar não é o fim da governação. É a transição que torna possível a investigação, a correção e uma retoma defensável.

Os cinco poderes escondidos na palavra supervisão

É útil analisar os cinco poderes práticos do artigo 14.º um a um. O primeiro é compreender. Uma função de supervisão não pode funcionar com base num slogan como o modelo é geralmente preciso. A função exige a finalidade prevista, as limitações conhecidas, as condições de entrada, a evidência de desempenho relevante, os modos de falha, a política de atualização e o significado do resultado no fluxo de trabalho real. Compreender não é o mesmo que ler um cartão de modelo. É a capacidade de reconhecer quando um caso real fica fora das condições em que o sistema foi avaliado.

The second is monitoring. Monitoring is often reduced to uptime, latency and a model score. Those measures matter, but a service can be available and wrong. A model can retain its aggregate performance while a source collection becomes stale, a language distribution changes, a policy deadline passes or a downstream team starts using a recommendation as an automatic decision. Operational monitoring follows the consequence. It looks for unexpected performance, changes in the inputs, changes in the route, unusual override patterns, blocked cases, complaints and signs that the system is being asked to do a job it was not given.

The third is interpretation. A person cannot exercise oversight if the output arrives without its conditions. Interpretation may require the relevant source, confidence information, policy version, input quality signal, explanation method or comparison with a safe baseline. It does not require a mystical view into every parameter. It requires enough context to answer the question the person is responsible for: what does this output mean here, what does it not mean, and what should happen if the evidence is insufficient?

The fourth is refusal and reversal. Article 14 explicitly gives the oversight role the ability to decide not to use the system, disregard its output, override it or reverse it. This is stronger than asking a person to add a comment after accepting the result. It means the workflow must allow a different decision to survive. The alternative must not be treated as an exception that disappears in the next automated step. If a human can disagree but the system will execute the original recommendation anyway, the human has been invited to express an opinion, not given oversight.

The fifth is interruption. Interruption acts on the operation itself. It may stop a tool call before an external change, place a case on hold, prevent new work from entering a route, revoke a permission or switch the service to a bounded fallback. The technical method varies. The safety property does not: the operation must come to a defined state in which the next consequential action cannot happen by momentum alone.

These powers are related but not interchangeable. A person may understand a system but lack the rights to stop it. A person may have a stop button but no useful signal that tells them when to press it. A person may override one result while a batch process continues to produce the same result for everyone else. A person may halt intake while existing jobs keep writing to an external system. The oversight design has to connect the powers across the actual lifecycle of work.

That connection is also where the human role becomes dignified. The reviewer is not there to absorb the system's uncertainty with a signature. The reviewer is there to exercise a bounded authority that the organisation has deliberately made possible. The work may still be difficult. It may require domain expertise, judgement and courage to challenge a popular system. But difficulty is not a reason to hide the control. It is a reason to specify it.

Who gets the key?

There is no single human in the loop. There are usually several authorities, each with a different reason to intervene. The provider controls parts of the design and release. The deployer controls the purpose, configuration and operational use. The person assigned to oversight controls a particular decision or intervention at runtime. A domain owner controls whether an output is acceptable in a professional context. A security or privacy role may control access to evidence or data. An affected person may have a right to challenge an outcome. A competent authority may require information, corrective action or withdrawal. Treating all of these as one role makes the system sound simple and the accountability impossible.

A responsabilidade do fornecedor começa antes de o sistema chegar ao utilizador. É o fornecedor que decide que controlos são incorporados, que limitações são documentadas, que registos podem ser produzidos e que alterações são tratadas como materiais. Um fornecedor que afirma que o implementador pode simplesmente monitorizar o sistema tem de demonstrar como o implementador pode fazê-lo com a interface e a informação fornecidas. Se a paragem depender de um comando interno não documentado ou de um pedido de suporte com resposta incerta, a paragem não é uma capacidade do implementador. É uma esperança de que o fornecedor continue acordado.

O implementador tem uma autoridade diferente. É o implementador que decide onde o sistema é utilizado, para que finalidade, com que dados, em que fluxo de trabalho e com que pessoas responsáveis pela supervisão. Um implementador pode transformar um resultado meramente indicativo numa decisão de facto através do design da interface, de incentivos ou de pressão, mesmo quando o fornecedor descreveu o sistema com cuidado. O implementador precisa, por isso, de mapear o percurso local e não apenas repetir a finalidade pretendida pelo fornecedor. O mesmo componente pode ter um perfil de risco diferente quando está ligado a uma ação diferente.

A função de supervisão em tempo real precisa de um mandato mais restrito e mais claro. Esta pessoa pode ter autorização para reter um caso, rejeitar uma recomendação, pedir mais provas, escalar para o responsável do domínio ou ativar uma paragem segura. Pode não ter autorização para alterar o modelo, eliminar provas, fazer uma determinação jurídica ou retomar um percurso suspenso. Esses limites não são um insulto à função. Impedem que a pessoa que pode parar um processo possa também apagar a razão que justifica a paragem.

A autoridade deve acompanhar a consequência. Um revisor que pode suspender um rascunho não precisa de poder suspender todos os percursos da organização. Uma pessoa que pode parar uma ação relevante para a segurança pode precisar de acesso a uma equipa de incidentes mais alargada e do dever claro de notificar. Um profissional do domínio pode ser a única pessoa autorizada a reverter um resultado numa decisão regulada. Um operador de segurança pode conseguir isolar um serviço enquanto outra autoridade decide se a utilização deve ser retomada. O importante não é criar uma grande hierarquia. É tornar explícitas as passagens de testemunho.

O escalamento não deve ser confundido com abdicação. Se o primeiro revisor encaminha todos os casos difíceis para uma comissão, o sistema não ganhou supervisão. Ganhou uma fila mais lenta. Um percurso de escalamento deve indicar que questão está a ser escalada, que trabalho fica suspenso enquanto a resposta está pendente, quem deve responder, que provas acompanham o caso e o que acontece se o percurso não estiver disponível. A primeira pessoa continua responsável por preservar o caso e por utilizar a opção segura por defeito. Não lhe é exigido que invente sozinha a resposta final.

A autoridade também precisa de um caminho de regresso. Uma paragem sem forma de devolver o controlo torna-se num corte permanente ou numa contornação silenciosa. O caminho de regresso deve indicar quem pode retomar, que condições têm de ser cumpridas, se o estado capturado continua válido, que trabalho pendente precisa de ser reavaliado e como os utilizadores são informados de que o percurso mudou. A retoma é outra decisão. Merece a mesma seriedade que a interrupção, embora raramente tenha um botão tão atraente.

A paragem tem de ser segura

A expressão estado seguro do Regulamento IA merece mais atenção do que a imagem de hardware do botão de paragem. Um sistema pode deixar de enviar novos pedidos e ainda assim deixar trabalho perigoso em curso. Pode terminar um processo a meio de uma transação. Pode abandonar um resultado sem informar a pessoa que aguardava uma decisão. Pode desativar a interface visível enquanto uma tarefa agendada continua em segundo plano. Pode parar o modelo e deixar uma recomendação em cache disponível para o próximo serviço. Uma paragem só é segura em relação aos efeitos reais do sistema.

Defina os estados antes de escolher o controlo. Uma rota em execução pode aceitar, avaliar, recomendar e agir. Uma rota em espera não pode aceitar nada de novo, mas preserva o material já recebido. Uma rota parada pode rejeitar todo o trabalho consequente, permitindo ao mesmo tempo uma inspeção autorizada. Uma rota degradada pode fornecer um serviço limitado, apenas de leitura ou apenas humano. Uma rota retirada pode exigir uma nova aprovação antes de regressar. Estas são escolhas de conceção, não nomes universais. Tornam-se úteis quando as pessoas conseguem ver em que estado se encontram e o que cada estado permite.

O trabalho em curso precisa da sua própria regra. Algumas operações são reversíveis e podem concluir em segurança. Algumas já ultrapassaram uma fronteira externa e precisam de uma ação compensatória. Algumas têm de ser descartadas e regeneradas porque a evidência já não é fiável. Algumas têm baixo impacto e podem permanecer como rascunhos. O sistema não deve obrigar o operador a adivinhar a partir de um único rótulo de estado. Deve expor o conjunto de trabalho, o seu ponto de transição e a ação que ocorrerá se nada mais for feito.

Um estado seguro também protege a evidência. Parar um sistema ao eliminar os seus ficheiros temporários pode remover exatamente o contexto necessário para compreender a falha. Pará-lo ao deixar segredos numa exportação de diagnóstico alargada pode criar um segundo incidente. O controlo precisa de um caminho de preservação de evidência com limites de acesso, regras de retenção e um proprietário nomeado. Segurança e privacidade não são rivais aqui. Ambas exigem um tratamento deliberado, em vez da prática de emergência habitual de copiar tudo para uma pasta chamada urgente.

Testar a paragem faz parte da implementação do sistema. Um botão que só foi clicado numa demonstração prova que o botão pode ser clicado. Não prova que a receção para, que as ações assentam, que os registos permanecem coerentes, que as notificações chegam às pessoas certas ou que um reinício não repete trabalho duas vezes. O teste deve exercitar a rota real, incluindo uma falha parcial e um operador que tem a autoridade pretendida, mas não o conhecimento privado do programador. Se a paragem não puder ser ensaiada sem uma performance especial, ainda não é um controlo operacional.

Uma fila faz parte da decisão

Parar um sistema de IA é muitas vezes imaginado como parar o modelo. Na prática, a fila à volta do modelo faz parte da decisão. O trabalho pode estar à espera de entrar, à espera de um resultado do modelo, à espera de revisão humana, à espera de uma ferramenta a jusante ou à espera de uma notificação. Cada posição tem um risco diferente. Uma paragem que protege apenas o modelo pode permitir que a fila circundante continue a tratar resultados antigos como válidos.

O trabalho pendente precisa de uma política. Um novo pedido recebe uma recusa clara, um aviso de atraso ou uma rota humana? Um resultado produzido antes da paragem continua utilizável? Os casos que ainda não foram revistos ficam marcados como a exigir nova avaliação? O sistema distingue o trabalho que foi pausado por uma pessoa do trabalho que falhou tecnicamente? Pode um utilizador retirar um pedido enquanto este está em espera? Os detalhes dependem do serviço, mas a decisão não pode ser deixada ao comportamento de repetição predefinido da fila.

As repetições são particularmente reveladoras. Uma fila técnica assume muitas vezes que uma operação que não foi concluída deve ser tentada novamente. Uma fila de governação não pode assumir que a mesma recomendação deve ser produzida novamente depois de o motivo da paragem ser incerteza, âmbito ou dano potencial. A repetição pode ser segura para uma leitura idempotente e insegura para uma ação externa. A política de paragem deve, portanto, conter um motivo e um próximo passo permitido, e não apenas um estado vermelho.

Os resultados existentes precisam de ser classificados. Alguns são rascunhos em que nenhuma pessoa se baseou. Alguns foram mostrados a um trabalhador. Alguns foram copiados para um registo de decisão. Alguns acionaram uma notificação ou alteraram um sistema fora do percurso de IA. Uma organização não pode decidir o que fazer com eles até saber qual fronteira cada resultado atravessou. É por isso que a rastreabilidade não é um enfeite administrativo. É o mapa das consequências que uma paragem deve conter.

A fila também altera a carga de trabalho humana. Uma paragem pode proteger as pessoas de uma ação automatizada insegura, criando ao mesmo tempo uma grande quantidade de trabalho de revisão. Esse trabalho tem de ser reconhecido, priorizado e dotado de recursos. Caso contrário, a organização acabará por reabrir o percurso porque os casos retidos se tornaram inconvenientes, não porque a evidência melhorou. Uma pausa que apenas transfere o dano para uma fila manual exausta é um adiamento com boas intenções.

Não há vergonha em que uma fila fique mais lenta quando a alternativa é uma consequência não examinada. Há um problema de conceção quando a fila não tem modelo de capacidade, regra de triagem ou forma de informar as pessoas afetadas sobre o que está a acontecer. A supervisão humana não é atenção gratuita. É um serviço operacional com limites que devem ser conhecidos antes de se pedir à máquina para funcionar à escala.

Depois da paragem, a memória

Uma paragem é um evento que altera o que a organização sabe e o que é obrigada a fazer. O registo deve conter o gatilho, o momento, o percurso, o estado antes da intervenção, a autoridade utilizada, o âmbito da retenção, o trabalho afetado, a evidência capturada, as notificações feitas e as condições de revisão. Deve distinguir observação de conclusão. Um operador pode registar que um resultado era inconsistente com a evidência fornecida sem afirmar que um incidente foi comprovado. A precisão no registo protege tanto a investigação como as pessoas envolvidas.

O Regulamento IA trata o registo como uma propriedade técnica para sistemas de alto risco. O artigo 12.º exige que esses sistemas permitam o registo automático de eventos ao longo da sua vida útil, com capacidades de registo que apoiem a rastreabilidade, a identificação de riscos, a monitorização pós-comercialização e a monitorização do funcionamento. O artigo 19.º aborda a conservação dos registos gerados automaticamente sob o controlo do fornecedor, sujeita à finalidade prevista e à legislação aplicável em matéria de proteção de dados. Este é um lembrete útil de que uma paragem não pode depender de uma captura de ecrã montada depois do facto. O sistema deve ser capaz de deixar um rasto enquanto está em funcionamento.

O registo não é uma instrução para recolher todos os dados pessoais para sempre. É um requisito para registar os eventos relevantes para a finalidade e o risco. Um bom registo de paragem pode usar referências, hashes, identificadores de versão, conteúdo redigido e controlos de acesso separados. Pode preservar a entrada necessária para reprodução numa área protegida, em vez de a colocar num painel comum. Deve ser possível investigar sem transformar o repositório de evidência num segundo património de dados não controlado.

O dever de ação corretiva do fornecedor também é importante. Quando um fornecedor considera, ou tem motivos para considerar, que um sistema de alto risco não está em conformidade, o Regulamento exige a ação corretiva necessária, que pode incluir repor a conformidade, retirar o sistema, desativá-lo ou recolhê-lo, conforme adequado. A escolha não é uma decisão de marketing. É uma resposta ligada à evidência, ao âmbito e ao risco. Um utilizador pode precisar de parar um percurso local antes de o fornecedor concluir essa avaliação. Um fornecedor pode precisar de desativar ou retirar um percurso que o utilizador manteve em funcionamento. As duas autoridades devem poder comunicar sem perder a evidência que explica a alteração.

A monitorização pós-comercialização prolonga a memória para além de um único evento. O Regulamento descreve um sistema que recolhe, documenta e analisa ativa e sistematicamente dados relevantes ao longo de todo o ciclo de vida do sistema de alto risco. O objetivo não é fazer com que o fornecedor fique a olhar para um painel de controlo. É descobrir se o sistema continua a cumprir os requisitos e se o contexto à sua volta mudou. Uma paragem pode ser o primeiro sinal útil nesse processo. Uma série de pequenas intervenções pode dizer mais sobre a aptidão de um sistema do que uma avaliação de lançamento impecável.

Os incidentes graves têm um canal de comunicação próprio no Regulamento, incluindo o dever de investigar e tomar medidas corretivas após a comunicação. O artigo não transforma todas as anulações num incidente grave. Essa distinção é importante. Um operador que inverte uma recomendação pode estar a exercer um controlo saudável, e não a descobrir um evento comunicável. O registo deve preservar informação suficiente para que a organização decida o que aconteceu, em vez de forçar cada divergência para o silêncio ou para um rótulo dramático.

A escalada é uma transferência controlada de uma questão, não uma forma educada de fazer desaparecer a responsabilidade.

A escalada é um percurso, não um estado de espírito

As pessoas dizem muitas vezes que um caso difícil deve ser escalado. A expressão parece responsável e não contém quase nenhuma informação operacional. Escalar para quem? Para que decisão? Com que provas? Em que prazo? O que fica suspenso enquanto se aguarda a resposta? O que acontece se ninguém responder? Um percurso que não responde a nenhuma destas perguntas recompensará a persistência em vez do discernimento. O caso será passado de mão em mão até o prazo se tornar a decisão, ou será devolvido discretamente à pessoa que primeiro detetou o problema.

Uma escalada útil começa com uma pergunta. O resultado está fora do objetivo aprovado? As provas estão incompletas? O sistema mudou desde a avaliação? Existe um risco para um direito fundamental? Já ocorreu alguma ação externa? A questão é técnica, jurídica, específica do domínio, relacionada com segurança ou uma combinação destas? A pergunta determina qual o papel que pode responder. Uma escalada que envia o mesmo caso indiferenciado a todas as equipas não é exaustiva. É um e-mail de grupo com um tempo futuro.

The local oversight role should have a safe default while the question is open. That may be hold, refuse, revert to a human-only path, preserve a draft, or limit the system to read-only information. The default should be visible to the person and to the affected user where appropriate. Silence is not a safe default when the workflow continues underneath it.

Evidence has to travel with the escalation. The receiving role should not have to reconstruct the case from a model output and a timestamp. It should receive the relevant input reference, output, model and policy versions, source material, confidence or uncertainty signal, action status, previous interventions and the precise decision needed. This is also where privacy discipline matters. Send enough to answer the question, not an entire person's life because the export button was nearby.

Escalation needs a clock, but not every clock is a deadline to approve. A low-impact question may wait for a normal review. A high-impact action may require an immediate hold and an on-call route. The timing rule should say what happens when the response window expires. It might extend the hold, transfer authority, notify a supervisor or require a fresh decision. It should not silently convert a missing answer into permission.

Closure is part of escalation. The record should say what was decided, by whom, on which evidence, with which limitations and which follow-up. If the answer is that the system may continue only in a narrower context, the new boundary should be applied, not admired. If the answer is that the system must be withdrawn, the affected work and users need a plan. If the answer is that the anomaly was benign, the evidence should still inform monitoring and training. An escalation that disappears after a meeting has not become institutional knowledge.

Good escalation also protects the person who raises the issue. The authority to stop a system is useless if using it is treated as disloyalty. Organisations teach their real priorities through what happens after a person says no. If the response is curiosity, evidence and support, people learn that oversight is part of the work. If the response is blame, delay and a request to be more positive, the system will receive fewer warnings and the warnings it receives will arrive later.

Human oversight is a workload

The law's reference to competence, training and authority is easy to read as a human-resources requirement. It is also a capacity requirement. A person cannot monitor an AI system effectively if the interface shows too much noise, the queue leaves no time for inspection, the evidence arrives in a different tool, the decisions are measured only by speed or the organisation has assigned the work to someone without domain knowledge. The role may exist on paper and still be impossible to perform.

Training should include the system's limits, the approved purpose, the signs of unexpected performance, the meaning of uncertainty, the mechanics of override and stop, the privacy of the evidence, and the route after intervention. It should include cases in which the output looks plausible. Oversight is needed most when the answer is not absurd enough to reject immediately. A course that teaches people to spot a cartoonishly wrong answer prepares them for a demonstration, not for a working service.

O enviesamento de automatização merece atenção prática. Uma recomendação pode tornar-se uma âncora antes de o revisor ter lido as provas que a sustentam. Um rótulo de confiança pode ser interpretado como uma probabilidade, mesmo quando não o é. Uma explicação polida pode parecer uma confirmação independente quando não passa de uma reformulação. A ordem da interface é importante. Se o sistema apresentar primeiro a sua resposta e só depois as provas, o revisor pode passar o resto do processo a defender ou a corrigir uma impressão inicial. Um controlo de paragem escondido atrás do mesmo fluxo de trabalho que a aprovação também está a comunicar qual é a ação que a organização espera.

Os limites de carga de trabalho são controlos de segurança. Um revisor que tenha de esvaziar uma fila extensa pode aprender a tratar a predefinição do modelo como a escolha segura mais rápida. Um especialista que recebe todos os casos ambíguos pode começar a aprovar apenas para manter o serviço em movimento. Uma equipa pequena que detém uma rota de paragem de prevenção pode estar indisponível durante as horas em que o sistema realmente funciona. Não são falhas pessoais. São respostas previsíveis a um desenho operacional que pede ao julgamento humano que compense uma automatização ilimitada.

Meça o próprio trabalho de supervisão. Com que frequência os resultados são anulados? Com que frequência é tentada uma paragem? Que sinais levam à intervenção? Durante quanto tempo permanecem abertas as retenções? Que grupos ou línguas geram mais incerteza? Quanta correção é necessária antes de um resultado poder ser utilizado? As métricas não substituem o julgamento, mas podem revelar que o controlo prometido se está a tornar um carimbo de borracha. O objetivo não é punir uma taxa elevada de anulações. É perguntar o que essa taxa nos diz sobre o sistema e o fluxo de trabalho.

As tradições europeias de segurança já sabem isto

A linguagem política europeia sobre IA fiável não começou com o AI Act. Em 2019, o Grupo de Peritos de Alto Nível da Comissão Europeia sobre IA publicou as Ethics Guidelines for Trustworthy AI. As orientações identificam a agência e a supervisão humanas como um dos sete requisitos e descrevem abordagens human-in-the-loop, human-on-the-loop e human-in-command. Ligam também a supervisão à robustez técnica, aos planos de recurso, à transparência, à rastreabilidade e à responsabilização. O ponto importante não é o vocabulário. É a decisão de descrever a fiabilidade como um conjunto de condições que podem ser avaliadas.

O trabalho de avaliação posterior da Comissão dá às organizações uma forma de transformar essas condições em perguntas. As pessoas estão cientes de que estão a interagir com um sistema de IA? Conseguem compreender as capacidades e as limitações do sistema? Conseguem intervir e decidir não o utilizar? Existem mecanismos de reparação? Uma lista de verificação não torna uma operação segura. Mas torna mais difícil fingir que uma pessoa designada para a supervisão é automaticamente uma pessoa com poder para a exercer.

O trabalho da ENISA sobre cibersegurança da IA aborda o tema através do ciclo de vida e do ecossistema em torno do modelo. O seu AI Threat Landscape de 2020 mapeia ativos, atores, ameaças e fases, dos requisitos à implementação. Essa perspetiva é valiosa para a paragem, porque aquilo que precisa de ser isolado pode não ser o modelo. Pode ser uma fonte de dados, uma permissão de ferramenta, um pacote de implementação, um caminho de monitorização ou um componente de fornecedor. Uma paragem desenhada em torno do nome do modelo pode deixar a capacidade real intacta noutro ponto da cadeia.

São abordagens europeias documentadas, não afirmações de que a Europa resolveu a supervisão. As orientações e o AI Act definem expectativas. A ENISA mapeia um problema de segurança. O trabalho de implementação permanece local, técnico e inevitavelmente banal. Alguém tem de decidir que função pode manter a rota às três da tarde, que provas aparecem no seu ecrã e quem responde quando a paragem é utilizada.

A aquisição decide antes dos operadores

Muitas falhas de paragem são decisões de aquisição disfarçadas de problema operacional. O contrato pode permitir que o fornecedor altere um modelo sem um aviso utilizável. O serviço pode não expor registos ou um identificador de versão. A exportação pode omitir trabalho pendente e histórico de intervenções. O acordo de suporte pode não oferecer qualquer via de resposta para uma suspensão de segurança. O comprador pode ter aceite uma declaração genérica de que o cliente é responsável pela utilização sem obter os controlos necessários para exercer essa responsabilidade. Quando um operador pede o interruptor de desligar, o contrato já decidiu se ele existe.

A aquisição deve, por isso, fazer perguntas operacionais. Qual das partes pode desativar cada via? Pode o responsável pela implementação parar uma ação consequente sem esperar pelo suporte do fornecedor? O que acontece ao trabalho em curso e em fila de espera? Que estado é capturado? Como são anunciadas as alterações? Pode o cliente obter registos e provas num formato utilizável? Qual é a alternativa quando o serviço está indisponível? Que funções recebem formação e quem financia essa formação? Como é corrigido um resultado contestado? Como sai a organização sem perder os registos necessários para explicar decisões anteriores?

Estas perguntas não são uma tentativa de fazer com que todos os fornecedores se comportem como uma autoridade pública. São uma forma de manter a autoridade alinhada com a utilização. Se uma organização tem o dever de proteger as pessoas afetadas por um sistema, precisa de controlo suficiente sobre a via para cumprir esse dever. Um contrato que deixa o cliente responsável mas operacionalmente impotente não é um modelo de governação. É uma transferência de responsabilidade com um logótipo.

Uma breve nota nossa

Na Dweve, o nosso trabalho em IA responsável baseada em estados faz o mesmo ponto modesto do lado da engenharia: um fluxo de trabalho responsável tem estados nomeados, proteções, registos, responsáveis e saídas. Isto não é uma afirmação de que um diagrama pode resolver a governação. É um lembrete de que os princípios precisam de um lugar onde assentar quando um sistema está em funcionamento. Quer a ferramenta seja um componente Dweve, um serviço do setor público ou um modelo de um fornecedor, o teste é o mesmo. Pode uma pessoa real ver o problema, exercer autoridade, parar a próxima consequência, preservar as provas e devolver o trabalho a um estado defensável?

Perguntas antes da implementação

Antes de um modelo entrar num fluxo de trabalho consequente, faça as perguntas de paragem na sala onde o sistema vai realmente operar. Não as deixe para uma revisão de políticas que nunca vê a fila de espera, o portal da ferramenta ou a pessoa que vai receber o alerta.

  • O que pode ser exatamente interrompido? Indique a rota do modelo, a chamada de ferramenta, a fila, a notificação, a ação de escrita e o serviço a jusante. Se a resposta for apenas o processo do modelo, procure a capacidade que permanece depois de ele parar.
  • Quem pode interromper sem pedir autorização ao criador? Indique a função em tempo de execução, a sua autoridade, o seu substituto e o seu limite. A pessoa não deve precisar de conhecimento privado da implementação para utilizar o controlo.
  • Que sinal indica que devem agir? Defina anomalias, evidências em falta, conflito de âmbito, incerteza inaceitável, alteração de política, preocupação de segurança e contestação do utilizador em termos que o operador possa observar.
  • O que acontece ao trabalho já em curso? Separe novas entradas, trabalho em fila, operações em execução, resultados apresentados a pessoas e ações já aplicadas. Atribua um tratamento seguro a cada um.
  • Qual é o estado seguro? Descreva o que o sistema aceita, rejeita, retém, conclui ou expõe após a interrupção. Verifique se o estado é real e não apenas um rótulo num ecrã.
  • Que evidências sobrevivem? Preserve a entrada relevante, a saída, as versões, a política, as referências de origem, as ações humanas, os tempos e as notificações com os controlos de privacidade adequados.
  • Quem recebe a escalada? Indique a questão a decidir, o prazo de resposta, o pacote de evidências e o comportamento predefinido enquanto se aguarda. Uma lista de distribuição não é um mapa de autoridade.
  • Quem pode retomar, restringir ou retirar a rota? Torne explícita a decisão de regresso. Identifique as condições, a reavaliação, a comunicação ao utilizador e o gatilho de revisão que a acompanham.
  • O que indicará que o controlo está a falhar? Observe padrões de substituição, duração de retenção, incidentes repetidos, efeitos desiguais, pressão na fila, queixas de utilizadores e desvios no fluxo de trabalho envolvente. Uma paragem raramente utilizada pode significar um sistema seguro ou um controlo oculto.

As perguntas são deliberadamente simples. Não substituem uma avaliação de risco, um processo de conformidade, um plano de incidentes ou uma revisão jurídica. São o ponto em que essas atividades se tornam operacionais. Se a organização não conseguir respondê-las, o trabalho em falta não é um desacordo filosófico sobre se a IA deve ser confiável. É uma parte em falta do sistema.

A autoridade para parar é a autoridade para cuidar

Um modelo pode estar errado de uma forma que parece normal. A fonte é antiga. A entrada está incompleta. A rota expandiu-se. Um limiar foi alterado. Uma tradução mudou o significado. Uma permissão de ferramenta sobreviveu ao seu propósito. Um revisor vê a conclusão, mas não as evidências. Nenhum alarme soa porque o sistema continua disponível e o painel continua verde. O dano começa como um pequeno desfasamento entre o que o sistema foi autorizado a fazer e o que a organização agora espera que ele faça.

A supervisão humana é a resposta da instituição a esse desfasamento, mas apenas quando é mais do que presença. A função de supervisão precisa do conhecimento para reconhecer um problema, do tempo para investigá-lo, da autoridade para recusar ou interromper, do estado seguro que torna a interrupção significativa e dos registos que permitem que outras pessoas compreendam o que aconteceu. Precisa de uma escalada que transporte uma questão e evidências, e não um pedido vago de ajuda. Precisa de uma retoma que seja uma decisão, e não o fim de uma indisponibilidade.

O Regulamento Europeu sobre a IA tem razão em usar a linguagem de intervenção e paragem segura para sistemas de alto risco. Dá à governação uma vantagem prática. Pede às pessoas que concebem e implementam sistemas que tornem o controlo humano possível durante a utilização, e não apenas admirável em princípio. O trabalho anterior da Comissão sobre IA fiável e a abordagem do ciclo de vida da ENISA reforçam a mesma direção: a supervisão pertence ao funcionamento do sistema, às suas evidências e à sua cadeia de fornecimento envolvente.

Na Dweve, preferimos a versão pouco romântica desta ideia. Um sistema sério deve conhecer os seus estados, os seus limites e o seu dono. Deve ser capaz de reter trabalho, mostrar por que o reteve e parar honestamente quando a evidência não é suficiente. Isso não é uma virtude especial de uma arquitetura. É o mínimo de respeito devido às pessoas que têm de viver com o resultado.

Quando o modelo está errado, a questão decisiva não é se um humano estava tecnicamente presente. É se uma autoridade humana nomeada poderia mudar o que aconteceu a seguir e se a organização conseguiria recordar a mudança. Se a resposta for sim, a supervisão está a cumprir a sua função. Se a resposta for não, o sistema tem uma pessoa por perto, um botão em algum lugar e nenhum travão.

Fontes