O que a Europa pode aprender com os casos de segurança

Um safety case é um argumento vivo que parte de perigos e pressupostos até à evidência, ao risco residual e a uma decisão. Oferece às equipas de IA uma...

O que a Europa pode aprender com os casos de segurança

Um ficheiro que tem de responder antes de o comboio avançar

As regras ferroviárias europeias começam com uma pergunta pouco glamorosa: o que mudou. Uma alteração pode ser técnica, operacional ou organizacional. Pode envolver equipamento, um procedimento, uma afetação de pessoal ou uma interface entre organizações. O Método Comum de Segurança para a Avaliação e Apreciação do Risco pede ao proponente que avalie a importância dessa alteração, que aplique um processo de gestão do risco quando necessário e que recorra a um organismo de avaliação independente para verificar se o processo e os seus resultados foram aplicados corretamente. A regra não se interessa por saber se a alteração foi anunciada com confiança. Interessa-se por saber se o raciocínio para continuar a operar pode ser inspecionado.

Esse hábito vale a pena ser transportado para a IA. Um sistema não se torna seguro porque o seu modelo é inteligente, a sua interface é serena ou o seu fornecedor produziu um relatório de ensaio elegante. Torna-se defensável para uma utilização definida quando uma organização consegue explicar o que está a afirmar, quais os perigos que sustentam a afirmação, quais os pressupostos que tornam a afirmação possível, que provas apoiam cada elo, quem aceitou o risco remanescente e o que reabriria a decisão. O resultado é habitualmente designado por safety case: um argumento estruturado apoiado em provas, delimitado por condições e mantido ao longo da mudança.

Um safety case não é uma história sobre um acidente imaginário. É uma forma de recusar que o acidente carregue com todas as provas. Coloca as perguntas difíceis enquanto o design, o aprovisionamento e a prática operacional ainda podem mudar. Isso torna-o útil para os caminhos de ferro, a aviação, os dispositivos médicos, o controlo industrial e as infraestruturas críticas. Também o torna útil para a IA, onde um componente pode ser estatisticamente impressionante e operacionalmente despreparado ao mesmo tempo. Um modelo pode passar num teste enquanto o sistema à sua volta não tem resposta segura para a incerteza, não tem operador responsável e não tem forma de recuperar uma má decisão.

A distinção é importante na Europa porque o Regulamento Inteligência Artificial já pede aos sistemas de alto risco que vivam com um processo contínuo e documentado de gestão do risco. O artigo 9.º descreve a identificação, a estimativa, a avaliação e o tratamento iterativos dos riscos ao longo de todo o ciclo de vida do sistema, incluindo a utilização indevida razoavelmente previsível e as informações provenientes da monitorização pós-comercialização. O artigo 11.º exige documentação técnica antes de colocar um sistema no mercado e determina que esta seja mantida atualizada. Estas disposições não usam safety case como rótulo universal. Descrevem, no entanto, os hábitos que tornam um safety case credível.

Um safety case torna visível o percurso entre uma afirmação de segurança e uma decisão de disponibilização, de forma suficientemente clara para ser questionado.

Safety case não é um relatório de ensaio

Um relatório de teste responde a uma pergunta sobre um teste. Regista o que foi testado, em que condições, com que resultado e, se o trabalho for bom, com que limitações. Isso é valioso. Uma safety case coloca uma pergunta diferente: existe um argumento suficientemente fundamentado de que este sistema é aceitável para este fim, neste contexto, com estas pessoas, controlos e riscos remanescentes. Um resultado de teste pode ser uma peça desse argumento. Não pode, silenciosamente, tornar-se o argumento inteiro apenas porque a tabela tem células verdes.

Suponhamos que um classificador foi testado contra um conjunto de dados rotulado. O relatório pode dizer-nos como ele se saiu nesse conjunto de dados, talvez por classe, limiar ou ponto de operação. Não nos diz, por si só, se a informação que chega em produção tem o mesmo significado, se a população afetada está representada, se um revisor consegue reconhecer um resultado fraco, se é possível recorrer, se um fornecedor pode alterar o modelo sem aviso, ou se a organização consegue parar e reverter uma ação a jusante. Essas perguntas pertencem ao sistema e à sua utilização, não apenas ao componente.

O erro oposto também é comum. Um ficheiro de garantia extenso pode conter centenas de páginas e ainda assim não apresentar um argumento. Um catálogo de testes, políticas e atas de reuniões não é uma safety case se nenhuma alegação os ligar. A evidência precisa de uma função. Um teste pode apoiar uma alegação sobre robustez. Uma descrição de função pode apoiar uma alegação sobre autoridade. Um exercício de reversão pode apoiar uma alegação sobre recuperação. Uma trilha de auditoria pode apoiar uma alegação sobre rastreabilidade. Sem a relação entre alegação e evidência, o ficheiro é um arquivo de atividade, não uma explicação de segurança.

É por isso que uma safety case pode ser mais curta do que um relatório de teste num lugar e maior noutro. Ela cresce em torno dos perigos e das decisões. Uma ferramenta de redação de baixa consequência pode precisar de um argumento modesto que cubra âmbito, tratamento de dados, revisão e correção. Um sistema ligado a decisões clínicas, de transporte, financeiras ou de serviços públicos precisa de mais evidência porque mais pessoas dependem do resultado e porque o caminho para a reparação pode ser difícil. O tamanho segue a consequência e a incerteza, não o comprimento na moda do model card.

O argumento também deve distinguir evidência de componente de evidência operacional. A evidência de componente diz respeito ao modelo, algoritmo ou sensor isoladamente ou numa integração controlada. A evidência operacional diz respeito ao fluxo de trabalho real: acesso, atualidade dos dados, revisão humana, filas, permissões de ferramentas, tratamento de incidentes e controlo de alterações. Um modelo pode ser estável enquanto uma fila colapsa. Um fluxo de trabalho pode ser bem desenhado enquanto um fornecedor altera o esquema de entrada. As safety cases forçam ambas as perspetivas para a mesma página, o que é ligeiramente inconveniente e, portanto, saudável.

Comece com uma alegação que tenha limites

Toda a safety case começa com uma alegação de nível superior. A alegação deve ser suficientemente estreita para ser testada e suficientemente útil para orientar uma decisão. A frase esta IA é segura não é uma alegação com limites. Segura para quem, a fazer o quê, em que condições e com que controlos. Uma alegação melhor poderia dizer que uma função específica de apoio à decisão é aceitável para um grupo nomeado de operadores treinados, desde que o sistema seja usado apenas para recomendações, que a evidência e a incerteza sejam mostradas, que um humano com autoridade reveja o resultado e que rotas definidas de paragem e correção estejam disponíveis.

Essa frase é menos comercializável e muito mais valiosa. Identifica o propósito, o ator, o limite e as condições. Também revela o que tornaria a alegação falsa. Se a mesma função for ligada diretamente a uma decisão automática, a alegação deixa de a cobrir. Se os utilizadores pretendidos não forem treinados ou não puderem contestar um resultado, a alegação enfraquece. Se uma fonte de dados mudar e não puder ser rastreada, a evidência para a alegação pode expirar. Uma boa alegação de nível superior carrega a sua própria lista de formas de ser reaberta.

As alegações podem ser decompostas. O sistema mantém-se dentro do seu propósito pretendido. Os dados de entrada cumprem as condições de qualidade e de permissão declaradas. O resultado do modelo é interpretado de uma forma que não cria um enviesamento de automação inseguro. As ações de elevada consequência recebem uma revisão proporcional ao seu risco. Os operadores podem ignorar ou reverter um resultado. A organização consegue detetar desvios significativos. Uma alteração não é lançada sem verificar os pressupostos afetados. Cada subalegação precisa de controlos e de evidências. A árvore não é uma ilustração para um diapositivo; é o percurso através do qual um revisor pode localizar um elo fraco.

Uma alegação deve também indicar o que não está a tentar provar. O caso pode apoiar a utilização segura para uma tarefa sem provar inteligência geral, imparcialidade universal ou adequação a todas as populações. Pode apoiar um lançamento sob uma postura de implementação definida sem provar que uma configuração não registada se comportará da mesma forma. As não alegações não são decorações de modéstia. Evitam que um resultado restrito circule por uma organização como uma promessa muito maior.

Existe um instinto europeu útil por detrás desta precisão. O Regulamento 402/2013 pede a um proponente ferroviário que decida se uma alteração é significativa, que selecione um princípio de aceitação do risco e, quando adequado, que recorra a uma avaliação independente. Não é pedido ao proponente que prove que todos os estados futuros concebíveis do sistema ferroviário são seguros. É pedido ao proponente que torne a alteração atual e as suas interfaces suficientemente inteligíveis para uma decisão proporcional. As equipas de IA podem adotar a mesma disciplina. Nomeiem a alteração, nomeiem o contexto operacional e tornem o limite visível.

Os perigos são condições, não manchetes

Um perigo é uma condição que pode conduzir a dano. A distinção é mais útil do que parece à primeira vista. Uma decisão errada de benefício é um resultado. Um perigo pode ser um registo incompleto combinado com um sistema que apresenta uma recomendação não fundamentada como pronta para aprovação. Um alerta de manutenção atrasado é um resultado. Um perigo pode ser um feed de sensores desatualizado que o fluxo de trabalho trata como atual. Uma violação de privacidade é um resultado. Um perigo pode ser uma permissão de recuperação excessivamente ampla combinada com uma ferramenta que copia material de origem para um registo duradouro.

Descrever os perigos desta forma desloca a atenção para montante. Torna possíveis os controlos de conceção e de operação. Se o perigo é uma recomendação não fundamentada apresentada com autoridade indevida, um controlo pode exigir evidência de origem, evidenciar a incerteza, restringir a ação e fornecer um percurso de revisão. Se o perigo é um dado de entrada desatualizado, um controlo pode verificar a atualidade, assinalar o estado dos dados, bloquear a ação ou encaminhar para uma pessoa. Se o perigo é um acesso excessivo, um controlo pode restringir a recuperação, separar identidades, redigir o resultado e registar a decisão de acesso. O controlo deve abordar a condição, não apenas prometer cuidado em torno do resultado.

A análise de perigos deve incluir a utilização indevida previsível, não apenas o propósito escrito num documento de aquisição. O Regulamento IA torna isto explícito para os sistemas de alto risco. O artigo 9.º pede a avaliação dos riscos quando um sistema é utilizado como pretendido e sob utilização indevida razoavelmente previsível. Utilização indevida não significa todos os pedidos absurdos. Significa utilizações que uma equipa competente poderia antecipar a partir da interface, dos incentivos, das instruções e do fluxo de trabalho envolvente. Se o percurso mais rápido no sistema é aceitar uma recomendação sem ler a sua evidência, esse percurso pertence à análise, mesmo que a política exija revisão.

Os perigos também vivem nas interfaces. Um modelo pode produzir uma recomendação limitada, mas uma integração pode convertê-la numa instrução ilimitada. Um fornecedor pode disponibilizar um endpoint com versão, mas uma implementação pode armazenar respostas em cache para além do período de validade. Uma autoridade pública pode manter a responsabilidade pela decisão, mas um contrato pode tornar o fornecedor a única parte capaz de inspecionar o registo. A fronteira do sistema para um caso de segurança deve seguir o caminho causal até à consequência. Delimitar a fronteira apenas à volta do modelo é uma forma eficiente de ignorar o trabalho que torna o modelo relevante.

Nem todos os perigos merecem o mesmo tratamento. Alguns podem ser reduzidos através do design. Outros necessitam de controlos processuais ou revisão humana. Alguns podem ser monitorizados e aceites com condições. Outros indicam que a utilização proposta não é adequada. Um caso de segurança deve mostrar o raciocínio, não escondê-lo atrás de uma pontuação de risco universal. O método ferroviário europeu permite diferentes princípios de aceitação de risco, incluindo códigos de prática, comparação com partes semelhantes de um sistema e estimativa explícita de risco. A lição não é que um método vence em todo o lado. A lição é que o método e a sua adequação à alteração devem ser registados.

Os pressupostos são estruturais

Todo o argumento de segurança assenta em pressupostos. O operador está formado. A fonte está atual. O limiar tem o significado que a equipa pensa que tem. A pessoa que recebe o alerta consegue agir a tempo. O serviço externo estará disponível ou existe uma alternativa. O resultado continuará a ser uma recomendação, em vez de se tornar uma decisão de facto. A organização aperceber-se-á se uma atualização do modelo alterar o comportamento. Muitas falhas de segurança não são causadas por um pressuposto ser irrazoável. São causadas por um pressuposto ser invisível.

Um pressuposto pertence ao caso, com um responsável e uma forma de o verificar. Se o argumento depender de revisores formados, o caso deve indicar a competência exigida, como é estabelecida e o que acontece quando o pessoal muda. Se o argumento depender de uma fonte permanecer dentro de uma janela de atualização, o sistema deve registar a atualização e fazer depender a ação dela quando necessário. Se o argumento depender de uma integração preservar um campo, o contrato de interface e um teste devem tornar a dependência visível. Um pressuposto que não pode ser verificado é um risco com um nome mais suave.

Os pressupostos podem dizer respeito ao mundo exterior, bem como ao software. Um hospital pode depender de um percurso clínico. Um operador ferroviário pode depender de uma interface de sinalização. Um organismo público pode depender de um processo legal e de um decisor humano que mantém autoridade. Um fabricante pode depender de a manutenção ser realizada dentro de um intervalo definido. O caso de segurança não controla todas as condições externas. Mas precisa de indicar quais as condições que pressupõe, qual das partes é responsável por elas e como uma alteração é reconhecida.

Quando os pressupostos mudam, o caso não deve esticar-se silenciosamente. Uma equipa pode começar com uma utilização apenas de recomendação e depois adicionar uma transferência automática porque a recomendação tem sido aceite com frequência. O modelo não mudou, mas a autoridade e o perigo mudaram. Um fornecedor de dados pode adicionar uma nova categoria que parece inofensiva até alterar o significado de uma regra a jusante. Uma implementação pode passar de especialistas formados para uma equipa de apoio geral. Estas são alterações ao caso, mesmo que o número de versão do modelo permaneça o mesmo.

Os pressupostos são especialmente importantes para sistemas probabilísticos, porque uma média estável pode ocultar uma margem instável. O caso deve identificar onde se espera que o sistema seja incerto, que evidências sinalizam essa incerteza e qual o controlo humano ou técnico que assume o controlo. O objetivo não é fingir que a incerteza pode ser eliminada. É impedir que uma expectativa não expressa de certeza se torne a política operacional.

A evidência não é um passaporte para todos os contextos. São as suas premissas que definem até onde ela pode viajar.

A evidência precisa de uma cadeia de custódia

Num processo de segurança, a evidência é mais do que um resultado copiado para uma tabela. Tem uma identidade, um âmbito, uma data, um método, uma pessoa ou equipa responsável e uma relação com a alegação que sustenta. Um teste precisa de uma entrada e de uma configuração definidas. Uma revisão precisa de uma pergunta e de uma decisão. Um exercício precisa de uma resposta esperada e de uma observação. Um registo precisa de contexto suficiente para ser interpretado sem depender da memória. Um registo de origem precisa de um rasto de proveniência. Os detalhes variam consoante o domínio, mas o princípio é estável: a evidência deve poder ser inspecionada depois da reunião em que soou convincente.

O Regulamento IA confere peso legal a este princípio para os sistemas de risco elevado. O artigo 11.º exige que a documentação técnica esteja disponível antes da colocação do sistema no mercado e seja mantida atualizada. O artigo 12.º exige o registo automático de eventos relevantes ao longo do ciclo de vida do sistema, com capacidades de registo proporcionais à finalidade prevista e úteis para identificar riscos, apoiar a monitorização pós-comercialização e acompanhar o funcionamento. O artigo 13.º pede informações que permitam aos utilizadores compreender as capacidades, as limitações, os riscos previsíveis, a supervisão humana e os requisitos de entrada. Um processo de segurança liga estes registos em vez de os deixar em gavetas de conformidade separadas.

A evidência deve preservar as suas condições. Um resultado de desempenho sem a sua população de teste pode ser mal interpretado. Um resultado de robustez sem as perturbações utilizadas pode ser sobrestimado. Uma revisão de fatores humanos sem o fluxo de trabalho e a pressão de tempo em que foi realizada pode tornar-se um elogio genérico. Um registo de incidente sem a versão, o estado dos dados e as permissões em vigor pode produzir uma causa raiz atraente mas errada. Quanto mais consequente for a decisão, menos aceitável é separar um resultado das circunstâncias que o tornaram verdadeiro.

A evidência pode ser qualitativa ou quantitativa. Um parecer especializado documentado pode ser evidência válida quando a pergunta é adequada, a especialização é identificada e o raciocínio é registado. Uma pontuação numérica pode ser evidência fraca quando o denominador, o limiar ou as condições do teste não são claros. Não há hierarquia moral em que um número supere automaticamente uma observação cuidadosa. O processo deve explicar a adequação à finalidade e a incerteza, não prestar reverência a casas decimais.

Rastreabilidade também torna o desacordo produtivo. Quem revê deve poder dizer qual afirmação não é suportada, qual pressuposto é demasiado otimista ou qual controlo não foi exercido. O caso passa a ser um objeto partilhado para contestação, em vez de um pacote de aprovação cerimonial. Essa é uma das razões pelas quais as indústrias críticas para a segurança investem em avaliação independente e relatórios de garantia estruturados. O objetivo não é tornar o dissentimento confortável. É torná-lo localizável.

O risco residual é uma decisão, não um remanescente

O risco não desaparece porque foram adicionados controlos. O risco que resta após os controlos é o risco residual. Ele precisa de ser descrito e aceite por uma autoridade capaz de compreender as evidências, impor condições e interromper a utilização quando as condições falham. Chamar aceitável a um risco não é o mesmo que dizer que é pequeno. Significa que a organização tomou uma decisão fundamentada sobre a exposição remanescente num contexto definido e não ocultou a base dessa decisão.

O artigo 9.º do Regulamento IA utiliza esta linguagem diretamente para sistemas de alto risco. O risco residual relevante associado a cada perigo, e o risco residual global, devem ser considerados aceitáveis. O regulamento também exige a eliminação ou redução quando tecnicamente viável, e medidas de mitigação e controlo quando os riscos não podem ser eliminados. Essa é uma ordem útil. Primeiro, alterar o design quando possível. Depois, adicionar controlos. Por fim, registar o que permanece. Um rótulo de aviso não é desculpa para manter um perigo evitável na arquitetura.

O risco residual deve incluir a reversibilidade. Os critérios de risco do Regulamento IA consideram se um resultado pode ser corrigido ou revertido e assinalam que os efeitos adversos na saúde, na segurança ou nos direitos fundamentais não devem ser tratados como facilmente corrigíveis apenas porque existe um botão técnico de desfazer. Esta é uma distinção discreta mas importante. Um rascunho pode ser corrigido. Um benefício perdido, um serviço negado ou uma acusação pública podem ser muito mais difíceis de reparar. O caso deve atribuir controlos mais fortes quando a pessoa afetada não pode, na prática, optar por não participar ou desfazer o resultado.

A aceitação deve ter condições. Um sistema pode ser aceite para um piloto limitado, uma equipa formada, uma fonte de dados nomeada e um percurso de revisão. Não pode ser aceite para uma população diferente, um fluxo de trabalho não supervisionado ou uma integração que remova evidências. As condições devem ser redigidas de modo a que um operador consiga saber se ainda se verificam. Se uma condição for apenas a de que os utilizadores aplicarão discernimento, o caso não explicou como o sistema suporta esse discernimento nem o que acontece quando a carga de trabalho dificulta o exercício do discernimento.

Uma decisão de risco residual também precisa de um prazo de validade ou de um gatilho de revisão. Uma data fixa no calendário pode ajudar, mas os eventos costumam ser mais informativos: uma alteração do modelo, uma nova fonte, um incidente material, um sinal de deriva, uma mudança nos utilizadores, uma nova obrigação legal ou uma falha no exercício de um controlo. A decisão não é um amuleto colocado na versão. É uma permissão com um calendário de manutenção.

A supervisão humana deve ter autoridade

A supervisão humana é frequentemente mencionada como se uma pessoa que está algures perto do resultado tornasse o sistema seguro. O Regulamento IA é mais exigente. O artigo 14.º estabelece que os sistemas de alto risco devem ser concebidos de modo a que pessoas singulares possam supervisioná-los eficazmente durante a sua utilização. A supervisão deve ser proporcional ao risco, à autonomia e ao contexto. As pessoas designadas para essa função devem compreender as capacidades e os limites, detetar anomalias, reconhecer o enviesamento de automação, interpretar os resultados, decidir não utilizar ou anular o sistema e intervir ou interromper o sistema através de um procedimento seguro.

Estes são requisitos de conceção tanto quanto requisitos de pessoal. Um revisor não pode interpretar um resultado se a evidência estiver oculta. Um revisor não pode contestar uma recomendação se a interface apresentar a aceitação como a única via conveniente. Um revisor não pode parar um sistema se a ação de paragem exigir uma permissão que ninguém concedeu. Um revisor não pode exercer supervisão significativa se for avaliado apenas pelo débito. Um caso de segurança deve, portanto, tratar o papel humano como um controlo com entradas, autoridade, carga de trabalho, formação e comportamento observável.

A autoridade é o pormenor que as descrições educadas omitem. Quem pode suspender o fluxo de trabalho. Quem pode reverter uma ação. Quem pode declarar que uma premissa deixou de ser válida. Quem pode contactar o fornecedor. Quem é o dono do registo. Quem decide se o risco residual continua a ser aceitável. Se ninguém tiver autoridade, a descrição de humano no circuito é teatro. A pessoa pode ver o resultado, mas ver não é governar.

Uma boa supervisão também é seletiva. O objetivo não é enviar todos os rascunhos triviais para uma comissão. É colocar o julgamento humano onde as consequências, a incerteza ou a contestabilidade o exigem. Alguns casos podem ser tratados com verificações estruturadas. Alguns exigem um especialista treinado. Alguns exigem duas confirmações independentes ao abrigo da lei aplicável. Alguns devem ser recusados. O caso deve explicar a seleção e demonstrar que a via escolhida está disponível nas operações reais, e não apenas num manual de procedimentos.

Há um tipo modesto de respeito em conceber desta forma. Aceita-se que as pessoas se cansam, que as filas crescem, que as interfaces moldam a atenção e que um aviso que aparece cem vezes pode deixar de ser um aviso. A engenharia de segurança aprendeu isto através da experiência nos transportes e na indústria. As equipas de IA não precisam de repetir todas as lições ao realizar uma experiência evitável com o público.

A mudança continua a entrar no caso

Um caso de segurança está vivo porque o sistema está vivo. A versão do modelo pode mudar, mas também podem mudar o prompt, o índice de recuperação, a taxonomia, a política, o hardware, o pessoal, a interface, a fonte de dados ou o fornecedor. Uma pequena alteração pode invalidar uma premissa ou deslocar um controlo. O risco resultante pode ser maior, menor ou simplesmente diferente. A resposta correta não é congelar o sistema para sempre. É tornar a mudança visível, classificar a sua importância e decidir que partes do argumento precisam de ser revistas.

A prática ferroviária oferece um padrão claro. O Regulamento 402/2013 aplica o seu método comum quando alterações técnicas, operacionais ou organizacionais afetam o sistema ferroviário. O proponente considera a importância da alteração e, quando necessário, utiliza princípios de aceitação do risco e avaliação independente. O regulamento também alerta para o facto de a totalidade das alterações desde o último processo de risco poder ser relevante. Várias pequenas alterações podem somar-se numa significativa. A governação da IA precisa da mesma suspeita em relação a incrementos de aparência inofensiva.

Para a IA, um registo de alterações deve identificar o que mudou e o que não mudou. Os pesos do modelo mudaram. A recolha de evidências mudou. As permissões das ferramentas mudaram. A população de utilizadores mudou. O limiar mudou. O fluxo de trabalho tornou-se automático num ponto que antes era apenas consultivo. A via de recurso continuou disponível. A avaliação capturou o novo estado. O registo deve ligar cada resposta à alegação, ao perigo, ao controlo ou à premissa afetados e especificar os testes ou revisões necessários antes da publicação.

O controlo de alterações deve incluir um modo de publicação seguro. Uma execução em modo de sombra, uma via faseada, uma população limitada, uma condição explícita de reversão ou uma confirmação humana podem impedir que o novo comportamento se torne um facto institucional antes de alguém o ter inspecionado. Estes mecanismos não são evidência de que o sistema é fraco. São evidência de que a organização compreende que um novo comportamento precisa de um lugar para aprender.

O acompanhamento pós-comercialização prolonga o caso após a disponibilização no mercado. O artigo 9.º remete para os dados recolhidos ao abrigo do artigo 72.º, e o artigo 72.º exige um sistema de acompanhamento documentado para os sistemas de risco elevado ao longo de todo o seu ciclo de vida. O acompanhamento deve procurar os sinais que interessam para a alegação: padrões de erro alterados, recusas invulgares, utilizações inesperadas, resultados de recursos, provas em falta, incidentes de segurança e falhas dos controlos humanos. Um painel que apenas reporta a disponibilidade é uma forma simpática de não detetar um problema de segurança.

A avaliação independente é um incómodo útil

Quem construiu um sistema conhece a sua elegância, os seus atalhos e as pressões sob as quais foi entregue. Esse conhecimento é necessário. Não é suficiente para aceitar o risco. Uma avaliação independente cria espaço para alguém contestar o argumento sem carregar os mesmos incentivos de lançamento. A independência não exige hostilidade nem um logótipo externo em todas as páginas. Exige competência, âmbito, acesso às provas e autoridade para registar uma discordância que o proprietário não possa simplesmente apagar.

O método ferroviário europeu torna esta separação concreta. A ERA descreve um organismo de avaliação responsável por verificar a correta aplicação do processo de avaliação de riscos e dos seus resultados, com requisitos de competência, acreditação ou reconhecimento. O regulamento permite uma entidade externa ou interna independente e competente, desde que cumpra os critérios. O desenho é proporcionado e não teatral. Reconhece que a garantia pode ser interna quando a independência é real, e que um selo não pode salvar um avaliador que não consegue ver as provas relevantes.

No caso da IA, a independência pode ser aplicada em camadas. Um responsável de domínio verifica se a utilização é legítima e se a análise de perigos reflete o trabalho. Um avaliador de engenharia verifica a integração e os modos de falha. Um avaliador de segurança testa os caminhos de acesso e de manipulação. Um avaliador de operações verifica a carga de trabalho, a escalada e a recuperação. Uma função de governação ou conformidade verifica os registos e os deveres. Para utilizações de consequências graves, pode aplicar-se uma avaliação externa ou uma via de organismo notificado ao abrigo do quadro jurídico relevante. O caso de segurança deve identificar o papel de cada avaliador e as perguntas que lhe é permitido fazer.

A independência é também uma proteção contra a opacidade dos fornecedores. Um relatório do fornecedor pode apoiar uma alegação, mas o responsável pela implantação deve saber o que foi testado, em que configuração e que limitações permanecem. Se um resultado crítico não puder ser reproduzido, inspecionado ou transferido quando o contrato termina, a dependência pertence ao caso. A aquisição deve exigir acesso às provas, identidade da versão, notificação de incidentes, aviso de alterações, exportação, reversão e uma saída prática. A palavra prática faz aqui um trabalho pesado. Um direito que não pode ser exercido sob pressão de tempo não é propriamente um controlo.

Uma boa avaliação produz mais do que um carimbo de aprovação. Regista condições, conclusões em aberto, lacunas nas provas, risco residual e acompanhamento necessário. Por vezes, a decisão certa é disponibilizar com restrições. Por vezes, é adiar. Por vezes, é rejeitar a utilização proposta. Uma cultura de segurança não é aquela em que todos os casos passam. É aquela em que a decisão segue o argumento.

O que o Regulamento IA acrescenta ao argumento

O Regulamento IA não transforma todas as implantações de IA numa ferrovia. Estabelece um vocabulário europeu para a gestão de riscos, documentação técnica, registos, transparência, supervisão humana, exatidão, robustez e cibersegurança para sistemas de risco elevado. Um caso de segurança pode ajudar uma organização a integrar esses deveres numa explicação operacional, em vez de tratar cada artigo como uma tarefa de conformidade separada.

O artigo 8.º subordina a conformidade à finalidade prevista e ao estado da arte geralmente reconhecido, e permite que os ensaios, relatórios, informações e documentação necessários sejam integrados nos procedimentos de harmonização da União já existentes, quando o produto já esteja abrangido por eles. Tal é importante para a engenharia de segurança. Reconhece que um sistema pode já dispor de um processo de garantia maduro e que duplicar ficheiros é menos útil do que interligá-los. O caso deve mostrar onde se situam as provas relativas à IA no âmbito do argumento mais vasto do produto ou serviço.

O artigo 11.º e o anexo IV conferem ao processo técnico um enquadramento amplo. Este inclui a finalidade prevista, versões, interfaces, hardware, métodos de desenvolvimento, arquitetura, proveniência e características dos dados, supervisão humana, alterações predeterminadas, procedimentos de validação e ensaio, métricas, registos de ensaio e medidas de cibersegurança. Não se trata do mesmo que um safety case, mas fornece muitos dos elementos de que um safety case necessita. Uma equipa pode associar cada elemento a uma afirmação e identificar o que ainda não tem responsável ou provas.

O requisito de registo do artigo 12.º é particularmente prático. Se um sistema de alto risco tiver de permitir tecnicamente o registo automático de eventos ao longo do seu ciclo de vida, a decisão de disponibilização deve questionar o que o sistema consegue efetivamente reconstruir. Que entrada, modelo, configuração, prova, chamada de ferramenta, intervenção humana e ação a jusante podem ser interligados. Que registos estão sob o controlo do fornecedor e quais pertencem ao utilizador que procede à instalação. Como são protegidos e conservados. Pode uma pessoa afetada ou uma autoridade compreender o percurso relevante sem receber uma descarga de dados pessoais não relacionados.

O artigo 15.º acrescenta uma perspetiva de ciclo de vida sobre exatidão, robustez e cibersegurança, incluindo resiliência a erros, falhas e incoerências e, quando relevante, planos de recurso ou de segurança intrínseca. Um safety case dá a essas palavras um lugar onde assentar. A afirmação não é a de que uma pontuação é elevada. A afirmação é a de que o sistema funciona de forma consistente para a sua finalidade prevista, que as condições de falha conhecidas estão delimitadas e que o fluxo de trabalho tem uma resposta segura quando estas ocorrem. As provas devem indicar as condições em que a conclusão é válida.

As obrigações do regulamento aplicam-se em função do sistema, do fornecedor, do utilizador que procede à instalação e da utilização. Um safety case não deve fingir que um modelo genérico resolve a classificação ou dispensa aconselhamento jurídico. Deve registar a decisão de aplicabilidade, a sua fundamentação e os pontos que a alterariam. Este é outro benefício de pressupostos explícitos. Quando um facto muda, a organização sabe que parte do argumento requer atenção, em vez de redescobrir todo o mapa jurídico em pânico.

A aviação trata a aprendizagem como parte da garantia

O Documento de Reflexão sobre Inteligência Artificial n.º 2 da Agência Europeia para a Segurança da Aviação é útil porque não descreve a segurança da IA como uma propriedade isolada do modelo. O documento refina as orientações para as aplicações de nível 1 que melhoram as capacidades humanas e aprofunda o trabalho sobre garantia da aprendizagem, explicabilidade da IA e avaliação baseada na ética. Aborda igualmente os sistemas de nível 2, em que a IA pode tomar decisões automaticamente sob supervisão humana, e salienta o trabalho de equipa entre humanos e IA e a conceção de uma interação segura.

A ideia importante não é a de que todas as organizações devam copiar a terminologia da aviação. É a de que a garantia deve acompanhar a relação entre o sistema e o trabalho humano. Um modelo que ajuda um operador formado não constitui o mesmo problema de segurança que um modelo que decide enquanto uma pessoa apenas supervisiona. A capacidade do operador para compreender, intervir e recuperar faz parte do sistema. O mesmo se aplica aos limites em torno da aprendizagem, das atualizações e das provas. O documento da EASA dá às equipas de IA um exemplo europeu de uma indústria que procura tornar essas relações explícitas antes da implementação.

Garantia de aprendizagem é uma expressão útil porque a aprendizagem automática pode alterar a história habitual das evidências. Uma versão de software convencional pode ser testada em relação a uma implementação definida. Um sistema adaptativo pode mudar o seu comportamento à medida que os dados, o estado ou o ambiente mudam. O caso de segurança deve, portanto, indicar o que pode aprender, o que está congelado, como a mudança é detetada, que evidências são atualizadas e quando o sistema volta a entrar num processo de aceitação. Se a aprendizagem ficar fora do caso, o caso diz respeito ao sistema de ontem.

A colaboração humano-IA também altera o significado da supervisão. O humano não é um travão de emergência acoplado a uma máquina concebida sem condutor. A equipa é um acordo sociotécnico com funções, expectativas, sinais, autoridade e formação. Uma interação segura pode exigir que a máquina explique uma limitação, peça confirmação, recuse uma ação ou torne a incerteza visível. Pode exigir que o humano desafie a máquina e que a organização recompense esse desafio. As evidências devem examinar a interação em vez de a inferir a partir de uma frase de política.

Mais uma vez, não é necessário inventar um voo ou um acidente para ilustrar o ponto. Um documento de conceito de uma agência pública basta para mostrar que o pensamento europeu sobre segurança se move em direção à aprendizagem, à interação humana e à garantia como um único problema de conceção. As equipas de IA podem ler o material como um convite a perguntar o que o seu próprio sistema aprende, o que o operador consegue ver e que evidências sobrevivem a uma mudança.

Um portão de lançamento composto, identificado como tal

Composto ilustrativo, não um evento relatado: imagine um serviço público a considerar uma ferramenta de IA que ajuda o pessoal a organizar o material de entrada dos processos antes de uma pessoa tomar a decisão. A ferramenta não está autorizada a decidir elegibilidade, enviar uma notificação ou encerrar um processo. A alegação de segurança proposta é estreita: pessoal formado pode usar a ferramenta para preparar uma fila de revisão quando o registo de origem está completo, o painel de evidências está visível, a recomendação está claramente marcada como recomendação e o membro do pessoal pode anular, pausar ou remover a recomendação.

O primeiro ramo do caso nomeia os perigos. Um registo incompleto poderia receber uma prioridade aparentemente coerente. Um documento de política desatualizado poderia moldar a recomendação. Uma fila poderia pressionar um revisor a aceitar a ordenação sem verificar. Um erro de permissões poderia expor o material de uma pessoa noutro processo. Uma atualização do fornecedor poderia alterar o significado de uma categoria. Estas não são alegações de que tal evento tenha acontecido. São condições que a equipa pode razoavelmente prever a partir da conceção proposta.

O ramo seguinte nomeia os controlos. A completude e a atualidade da entrada são verificadas antes de uma recomendação ser apresentada. As evidências usadas para a sugestão são visíveis ao lado do processo. A ação permanece um rascunho até uma pessoa formada a aceitar ou alterar. Uma origem em falta encaminha o item para um caminho diferente. As permissões são testadas na fronteira de recuperação, não apenas na interface do utilizador. O fluxo de trabalho tem um controlo de pausa e um encaminhamento manual. Uma mudança de versão funciona em modo limitado e pode ser revertida. O caso regista por que existe cada controlo e a que perigo responde.

As evidências têm depois de exercitar os controlos. Um teste de dados fornece registos incompletos e desatualizados e regista o resultado. Uma revisão de usabilidade pergunta se o pessoal consegue encontrar as evidências e compreender a recomendação sob carga de trabalho realista. Um teste de acesso verifica que um processo não pode recuperar material fora do seu âmbito. Um ensaio de lançamento verifica que os caminhos de pausa e reversão funcionam. Uma revisão de mudança confirma que a nova categoria e a política não invalidam a lógica da fila. Estes são testes hipotéticos neste composto, não relatos de testes realizados por um serviço nomeado.

A decisão é condicional. A ferramenta pode ser utilizada para a preparação da fila dentro do âmbito indicado. Não pode ser utilizada para tomar ou comunicar a decisão substantiva. A condição de que o pessoal deve ter autoridade para anular está atribuída a uma função. A condição de que a atualidade da fonte é registada é monitorizada. Uma alteração ao modelo, à política, ao contrato de dados, à população de utilizadores ou à ação a jusante reabre o processo. Se a organização não conseguir comprovar essas condições, o portão de lançamento permanece fechado. A história é útil precisamente porque ninguém precisa de fingir que existiu uma determinada cidade, equipa ou terça-feira.

Um pequeno exemplo do nosso Centro de Confiança

Na Dweve, o nosso Centro de Confiança público faz uma distinção relacionada no seu registo de avaliação. A página de avaliações apresenta um método que identifica o modelo, a suíte exata, a configuração, o estado capturado, as evidências e a decisão do revisor. Separa a identidade da avaliação do estado mutável do modelo, distingue a cobertura preparada de um resultado real e descreve a reprodução como um contrato que depende do artefacto capturado, do grafo de execução, do encaminhamento, da ordenação, do estado, das restrições, das ferramentas e das evidências. A página também afirma que não existia nenhum resultado de primeira divulgação externa em 1 de agosto de 2026, porque essa divulgação não tinha ocorrido.

Esse é um pequeno exemplo, não uma prova de que foi concluído um caso de segurança para cada utilização dos nossos sistemas. O seu valor é o limite. Um método não é um resultado. Uma categoria não é uma pontuação. Um lançamento planeado não é uma execução histórica. Um estado capturado reproduzível não é o mesmo que um mundo vivo cujas evidências e estado adaptativo mudaram. Essas distinções são exatamente o que um caso de segurança precisa quando afirma onde as evidências se aplicam e onde terminam.

Para uma empresa tecnológica europeia, publicar tais limites pode parecer deixar espaço de marketing útil vazio. É mais útil do que preencher esse espaço com um número que ninguém consegue defender. A mesma disciplina aplica-se a uma autoridade pública, a um fornecedor, a um grupo de investigação ou a uma equipa de plataforma interna. Diga quais evidências existem, quais estão preparadas, quais estão protegidas, quais não foram recolhidas e qual evento futuro criaria um novo resultado. O leitor pode então decidir o que as evidências sustentam.

O nosso exemplo também mostra por que um Centro de Confiança deve ser lido como um índice de evidências e não como uma promessa. A página pública aponta para identidade, método, captura, revisão e limites de divulgação. Não elimina a necessidade de inspecionar uma implementação, finalidade ou população afetada específica. Um caso de segurança acrescentaria esse contexto local, os perigos do fluxo de trabalho real e a autoridade da pessoa que toma a decisão. A transparência pública é uma superfície de partida, não um certificado universal.

O que um caso de segurança pode provar

Um bom caso de segurança pode sustentar uma conclusão limitada. Pode mostrar que um sistema foi concebido para uma finalidade nomeada, que os perigos previsíveis foram identificados, que os controlos abordam esses perigos, que as evidências foram recolhidas nas condições indicadas, que os riscos residuais foram avaliados, que uma autoridade competente aceitou ou rejeitou a utilização e que a organização tem uma forma de detetar alterações e rever a decisão. Pode tornar um argumento suficientemente inspecionável para contestação e manutenção.

Também pode mostrar o que é incerto. Um caso pode demonstrar fortes evidências para uma população e evidências limitadas para outra. Pode mostrar que o sistema é robusto a uma classe definida de entrada malformada, mas não a uma classe desconhecida. Pode mostrar que um humano pode intervir quando o pessoal e as permissões estão conforme especificado. Pode mostrar que existe uma alternativa, mas que ainda não foi exercida à escala operacional total. Um caso verdadeiro não esconde essas assimetrias. Torna-as condições de utilização.

Um safety case pode igualmente apoiar decisões de aquisição e de governação. Um comprador pode comparar as provas que um fornecedor apresenta com as provas de que o fluxo de trabalho necessita. Um regulador pode ver quais as alegações que estão fundamentadas e quais os registos que faltam. Um conselho de administração pode compreender onde reside o risco residual e quem é responsável por ele. Um operador pode saber qual o sinal que deve provocar uma pausa. As pessoas afetadas podem ter um caminho mais claro para questionar um resultado. O caso torna-se um mapa de responsabilidades, e não apenas um artefacto de engenharia.

Pode apoiar a mudança sem fingir que a mudança é gratuita. Ao ligar alegações, perigos, pressupostos, controlos e provas, a organização pode identificar a menor reavaliação significativa quando um componente muda. Isso é mais eficiente do que repetir todos os testes cegamente e mais seguro do que assumir que nenhuma reavaliação é necessária. A proporcionalidade só funciona quando a estrutura é visível. Caso contrário, uma equipa ou age por ritual ou toma atalhos.

O que um safety case não pode provar

Um safety case não pode provar que nunca ocorrerá qualquer dano. Os sistemas reais enfrentam condições que não foram antecipadas, e as pessoas respondem a incentivos e pressões de formas que nenhum diagrama consegue prever totalmente. O objetivo não é a certeza. É uma base disciplinada para operar, aprender e parar quando essa base deixa de se verificar.

Não pode provar que um modelo é geralmente inteligente, geralmente justo ou seguro em todos os domínios. As provas têm um âmbito. Um teste num conjunto de dados não determina o desempenho noutro. Uma revisão bem-sucedida num fluxo de trabalho não estabelece a mesma autoridade num diferente. Uma via de paragem bem concebida não prova que todos os operadores a utilizarão sem formação, tempo ou apoio organizacional. O caso deve resistir à tentação de transformar provas locais num adjetivo global.

Não pode transferir a responsabilidade para um fornecedor, auditor ou marca de certificação. As provas podem ser produzidas por outra pessoa, mas quem implementa continua a ter uma utilização, um fluxo de trabalho e pessoas que dependem do resultado. Os contratos podem atribuir deveres e garantir acesso. Não podem tornar uma organização alheia ao sistema que opera. Nem um certificado pode justificar uma alteração que coloque o sistema fora do âmbito avaliado.

Não pode tornar aceitável uma utilização proibida ou inadequada acrescentando burocracia. Se o perigo não puder ser controlado até um nível aceitável, a resposta pode ser alterar a finalidade ou não implementar. Os safety cases são frequentemente descritos como garantia, mas o resultado mais valioso pode ser um não bem fundamentado. Um processo completo pode ainda assim apoiar uma má decisão se o argumento for fraco. O objetivo do processo é melhorar a decisão, e não apenas torná-la mais legível depois de tomada.

Por fim, não pode substituir a lei, o discernimento profissional ou a responsabilização democrática. É um instrumento de engenharia e de governação. Deve ajudar as pessoas a compreender a decisão e as suas condições, e não fingir resolver questões que pertencem a tribunais, reguladores, médicos, funcionários públicos ou às pessoas afetadas.

Perguntas para uma reunião de lançamento europeia

Uma equipa não precisa de esperar por uma norma perfeita ou por um dossiê de 400 páginas para começar. Pode fazer uma sequência de perguntas simples. O que estamos exatamente a afirmar que este sistema pode fazer. Quem é afetado quando falha. Quais os perigos que são condições no sistema e no fluxo de trabalho, em vez de maus resultados vagos. Que pressupostos têm de permanecer verdadeiros. Que provas sustentam cada alegação e sob que configuração e população. O que permanece incerto. Quem aceita esse risco residual. Quem pode parar o sistema. Que evento reabriria o argumento.

The meeting should make room for a less comfortable question: what would make us refuse the release. If the only answer is a lower score, the team has probably not described its hazards. A refusal may be triggered by missing evidence, an unowned assumption, a failed recovery exercise, an inaccessible reviewer, an unbounded integration or a change that cannot be replayed. Naming the refusal conditions turns safety into an operational control rather than a mood.

Ask how the case travels with the system. Can an operator find the intended purpose, limitations and stop route. Can an incident investigator identify the model, evidence, permissions and human decisions that mattered. Can a buyer export the records if the supplier changes. Can a regulator obtain the information needed to assess conformity. Can a new team understand why a control exists without interviewing the person who left. A safety case that lives only in a private folder is a fragile memory, not a living argument.

Ask how the case changes. What is the review trigger for a model update, source change, policy change, new user group, new tool, new jurisdiction or new downstream action. Which evaluations are repeated, and which assumptions are checked. What happens when monitoring finds a weak signal but not yet a serious incident. Is there a safe, owned route to pause and investigate. A well-run organisation should be able to answer without inventing a crisis to make the process feel real.

And ask whether the evidence can be read by the people whose decision it is supposed to support. A technical file that nobody can interpret is not transparent. A policy that nobody can apply is not a control. A dashboard full of green cells that hides the denominator is not reassurance. European safety practice is at its best when it makes the reasoning available to the person with responsibility, not only to the person who assembled the document.

The quiet advantage of an honest argument

Safety cases look bureaucratic from a distance because they contain records, roles, conditions and review points. Up close, they are a way to keep engineering honest when systems become persuasive. They prevent a test from masquerading as a decision, an assumption from masquerading as a fact, a planned evaluation from masquerading as a result and a human presence from masquerading as authority.

Europe already has pieces of this discipline in its institutions. Railways treat technical, operational and organisational change as a risk question and use common methods and independent assessment. Aviation guidance discusses learning assurance, explainability and human-AI teaming. The AI Act joins lifecycle risk management with documentation, logs, transparency, human oversight and lifecycle performance. These are not identical frameworks, and they should not be flattened into one checklist. They do share a respect for conditions, evidence and responsibility.

The practical lesson is simple enough to carry into a Monday meeting. Begin with a claim that has edges. Name the hazards that could make it false. Record the assumptions that let it stand. Put controls where the work actually happens. Attach evidence with identity and scope. Judge residual risk rather than hiding it. Give a person real authority to intervene. Reopen the argument when the system or context changes. Let an independent reviewer be inconvenient. Publish limits with the same care as successes.

That approach will not make every AI system safe, and it will not turn uncertainty into certainty. It will make unsafe confidence harder to maintain. It will give operators a route to pause, give reviewers something concrete to challenge and give affected people a better explanation of where responsibility sits. It will also make good systems easier to improve because the organisation can see which part of the argument changed.

Um safety case não é, portanto, um parágrafo final depois da engenharia. É o fio que liga propósito, conceção, pessoas, evidência e mudança. A Europa pode aprender com os safety cases porque oferecem uma versão cívica da disciplina de engenharia: nenhum slogan é aceite sem um percurso, nenhum percurso é aceite sem evidência, e nenhuma evidência pode ir mais longe do que os seus pressupostos.

Fontes