Pode um regulador auditar um alvo em movimento?

Sim, mas não fingindo que um sistema adaptativo é um objeto estático. Uma auditoria exige um estado capturado, uma alegação delimitada, evidências com...

Pode um regulador auditar um alvo em movimento?

Uma auditoria pode tirar uma fotografia

Um alvo em movimento não está fora do alcance do escrutínio. Está apenas fora do alcance do tipo de escrutínio que faz uma pergunta intemporal e espera uma resposta intemporal. Essa distinção é importante. Os sistemas de IA mudam de várias formas ao mesmo tempo. Um fornecedor lança uma nova versão do modelo. Um implementador altera o prompt ou o limiar de decisão. Um corpus de recuperação ganha um novo documento de política. Uma regra de identidade altera quem pode chamar uma ferramenta. Uma ferramenta ganha um campo, perde um campo ou começa a devolver um significado diferente sob o mesmo nome de campo. Uma equipa humana altera o seu procedimento. O mundo que fornece os dados de entrada muda sem pedir autorização ao gestor de lançamentos de ninguém.

Nada disto torna uma auditoria inútil. Torna o objeto da auditoria mais preciso. A questão não é se uma organização pode provar que um sistema permanecerá inalterado para sempre. Essa seria uma promessa estranha até para uma calculadora ligada a uma base de dados. A questão é se a organização pode mostrar que sistema estava em funcionamento num momento relevante, o que se pretendia que fizesse, que provas sustentavam essa utilização, que condições limitavam essas provas, quem era responsável pela decisão e que alteração posterior deveria levar a que a decisão fosse reaberta.

Uma auditoria pode tirar uma fotografia. Só não deve chamar à fotografia a paisagem. Um registo adequado identifica o estado que foi inspecionado e mantém o percurso desse estado para o seguinte. Pode então dizer algo útil: esta avaliação dizia respeito a este modelo, a estas definições, a esta fronteira de dados, a estas ferramentas, a esta política, a este fluxo de trabalho e a esta decisão de lançamento. Também pode dizer algo menos confortável e mais valioso: a conclusão não viajou automaticamente para o estado seguinte.

Esse é um melhor ponto de partida do que o teatro familiar dos distintivos imutáveis. Um distintivo sugere que alguém resolveu a questão. Um registo de auditoria deve tornar possível ver o que foi resolvido, com que base, para que utilização e durante quanto tempo essa base permaneceu aplicável. Um regulador não precisa de uma organização congelada. Um regulador precisa de uma organização que consiga distinguir um registo congelado de um serviço ativo sem tratar nenhum deles como um objeto místico.

As regras europeias sobre IA já apontam nesta direção. Para os sistemas de IA de alto risco, o Regulamento Inteligência Artificial exige documentação técnica antes de o sistema ser colocado no mercado ou colocado em serviço, e exige que esta seja mantida atualizada. Exige também o registo automático de eventos relevantes ao longo da vida útil do sistema e um sistema documentado de monitorização pós-comercialização proporcional à tecnologia e ao risco. Não são instruções para capturar um único ecrã cerimonial. São instruções para manter um rasto de provas através da mudança.

O alvo em movimento é normalmente um sistema

É tentador descrever um sistema de IA como um modelo e depois discutir o versionamento como se um novo ficheiro de pesos do modelo fosse a história completa. Isso é conveniente para apresentações e impreciso para a maioria das questões operacionais. Um modelo é um componente importante. Raramente é o objeto completo cujo comportamento afeta uma pessoa, um fluxo de trabalho ou uma obrigação legal.

Considere um percurso comum de apoio à decisão, descrito aqui como um exemplo hipotético e não como um relato de uma implementação real. Um utilizador submete um pedido. O serviço recupera documentos que está autorizado a utilizar. Um modelo redige uma recomendação. Uma regra verifica se as provas exigidas estão presentes. Um revisor treinado pode aceitar, alterar ou rejeitar a recomendação. Um fluxo de trabalho regista então uma ação. O resultado observado depende de mais do que o modelo. Depende das versões das fontes, das definições de recuperação, das permissões, da redação da interface, dos limiares, das regras de fila, da autoridade humana e da fronteira da ação.

Se o corpus de origem mudar, o modelo pode receber uma base factual diferente sem que um único parâmetro seja alterado. Se um prompt mudar, pode ser pedido ao modelo que faça um tipo diferente de julgamento. Se um ecrã de revisão deixar de mostrar a incerteza, a supervisão humana descrita num ficheiro de risco pode deixar de ser a supervisão que as pessoas efetivamente exercem. Se uma integração começar a aplicar recomendações automaticamente, o sistema adquiriu uma nova autoridade, mesmo que a resposta do modelo seja byte por byte idêntica.

É por isso que um registo de auditoria sensato começa pela finalidade pretendida e pela fronteira do sistema. Os requisitos de documentação técnica do Regulamento IA no Anexo IV incluem descrições da finalidade pretendida, versões, funções de monitorização e controlo, validação e teste, gestão de riscos, alterações efetuadas durante o ciclo de vida e métricas de desempenho relevantes. A questão não é que todos os sistemas precisem de uma catedral de papelada. A questão é que um revisor não consegue avaliar uma afirmação quando o objeto nomeado por essa afirmação vai mudando silenciosamente de forma.

Chamar sistema ao objeto mais amplo não é uma forma de fazer o trabalho parecer mais grandioso. É uma forma de evitar um erro categorial. Uma avaliação de modelo pode responder a uma pergunta sobre o modelo. Uma auditoria de sistema tem de responder a uma pergunta sobre o sistema. A primeira pode estabelecer como um componente se comportou em condições definidas. A segunda tem de mostrar como esse componente foi ligado a pessoas, dados, regras, ferramentas e consequências. Nenhuma substitui a outra. Uma pontuação de modelo não é uma descrição de fluxo de trabalho, tal como um bom teste de pneus não é um plano de rota.

O que um auditor procura realmente estabelecer

Auditar um sistema em mudança não significa reproduzir todos os momentos da sua vida numa sala de reuniões. Significa tornar proposições específicas inspecionáveis. O sistema foi utilizado dentro da finalidade declarada? A decisão de lançamento foi apoiada por evidências adequadas a essa finalidade? A organização preservou a informação necessária para investigar um resultado contestado? As alterações significativas desencadearam uma reavaliação? A monitorização tornou visível a diferença entre uma atualização benigna e uma alteração material? As pessoas responsáveis conseguiam pausar, limitar ou corrigir a rota quando as evidências deixavam de se sustentar?

Estas são perguntas práticas porque cada uma tem um correspondente observável. A finalidade pretendida pertence a um registo. Uma avaliação tem uma suíte, configuração, população de teste ou fronteira de entrada, método, resultado e limitação. Uma decisão de lançamento tem um responsável e condições. Uma alteração tem uma identidade, uma data, uma razão e um efeito avaliado. A monitorização tem sinais nomeados, limiares ou gatilhos de revisão. Uma rota de pausa tem uma autoridade e uma operação. Os detalhes variam, mas a auditabilidade vem de transformar garantias abstratas em coisas que outra pessoa possa inspecionar.

Há aqui um limite importante. Uma auditoria não prova que todos os resultados futuros serão corretos, justos ou inofensivos. Não pode transformar um mundo incerto num mundo determinístico. Pode estabelecer se uma organização fez afirmações suficientemente restritas para serem examinadas, se recolheu evidências capazes de apoiar essas afirmações e se manteve a capacidade de as reconsiderar. Isso pode parecer modesto. É também onde começa a responsabilização.

A diferença entre evidência e linguagem de garantia é importante. Dizer que um modelo foi avaliado ainda não é evidência de uma avaliação útil. A palavra precisa de um objeto. Avaliado em relação a que tarefa, critérios e dados? Com que modelo e estado do sistema? Em que condições operacionais? Quem verificou o método? O que ficou fora do âmbito? O que tornaria o resultado desatualizado? Sem estas perguntas, avaliação é apenas um pretérito tranquilizador.

As Orientações Éticas para uma IA de Confiança, publicadas anteriormente pela Comissão Europeia, apresentam a reprodutibilidade em termos simples: uma experiência de IA deve exibir o mesmo comportamento quando repetida nas mesmas condições. É uma definição útil porque contém o seu próprio limite. As mesmas condições fazem um trabalho real. Uma experiência repetida pode mostrar se a afirmação registada é reprodutível. Não pode mostrar que um comportamento inalterado surgirá após uma alteração na fonte de dados, na política ou na via de implementação. A reprodutibilidade não é, portanto, uma promessa de que o mundo fica parado. É uma disciplina para dizer exatamente o que aconteceu.

Uma avaliação capturada é um ponto no tempo. A auditoria torna-se duradoura quando o estado seguinte pode ser comparado com ela.

Um número de versão é necessário, mas não suficiente

Os números de versão são úteis porque impedem que um registo finja que os nomes são suficientes. No entanto, um rótulo de versão também pode criar uma falsa sensação de segurança. Um rótulo como versão 4.2 pode identificar uma versão de software, mas não identifica necessariamente o estado efetivo de uma via de IA. Um valor de configuração pode estar fora do repositório do modelo. Um índice de recuperação pode ser reconstruído a partir de documentos em mudança. Uma flag de funcionalidade pode escolher um caminho de ferramenta diferente. Um motor de políticas pode alterar uma ação permitida. Um serviço pode, portanto, ter um número de versão impecavelmente formatado e ainda assim ser difícil de reconstruir.

O que importa é a identidade adequada à afirmação. Se a afirmação diz respeito a uma referência de modelo offline, o artefacto do modelo, o código de inferência, as definições de parâmetros, a versão do conjunto de dados, a definição da métrica e o ambiente de execução podem ser essenciais. Se a afirmação diz respeito a um serviço de apoio à decisão em tempo real, o registo pode precisar adicionalmente do prompt ou modelo, da configuração de recuperação, dos identificadores e da atualidade das fontes, do estado das permissões, dos esquemas das ferramentas, da versão da política, da interface do revisor e da regra do fluxo de trabalho. Um pacote de auditoria não precisa de conter todos os bytes de todos os sistemas. Precisa de conter ou apontar de forma fiável para os elementos que poderiam alterar o significado da afirmação.

É por isso que um manifesto é muitas vezes mais útil do que um arquivo despejado num disco rígido. Um manifesto indica quais os artefactos que pertencem ao mesmo conjunto, os seus identificadores, as suas referências de integridade, as suas relações e as suas condições de acesso. Permite que um auditor localize o pacote relevante sem assumir que todas as fontes podem ser copiadas para uma pasta sem restrições. Algumas provas contêm dados pessoais, detalhes sensíveis em termos de segurança, material licenciado ou segredos comerciais. A auditabilidade exige acesso controlado e rastreabilidade significativa, não divulgação pública obrigatória de tudo o que faz um sistema funcionar.

O anexo IV adota uma abordagem prática semelhante. Não trata a documentação técnica como uma breve descrição do produto. Exige informações sobre o sistema e o seu ciclo de vida, incluindo alterações introduzidas durante o desenvolvimento e após a colocação no mercado, funções de monitorização e controlo, procedimentos e resultados de validação e ensaio, medidas de gestão de riscos e uma descrição das métricas de desempenho. O documento tem de ser suficientemente claro para que as autoridades nacionais competentes e os organismos notificados possam avaliar a conformidade. Por outras palavras, a informação tem de estar organizada para ser examinada, e não apenas recolhida porque existia um sistema de armazenamento disponível.

Há uma questão de conceção pequena mas decisiva por detrás de tudo isto: o que teria de ser diferente para que as provas anteriores deixassem de sustentar a alegação atual? A resposta define o limite da versão. Se uma nova fonte de recuperação alterar a base factual das recomendações, pertence à identidade. Se uma nova interface de revisão ocultar um aviso, pertence à identidade. Se uma alteração meramente editorial não puder afetar o comportamento avaliado, provavelmente pertence ao histórico de alterações, mas não à impressão digital da avaliação. Uma boa gestão de versões não é a recolha máxima. É a relevância fundamentada.

Registar o contrato, não apenas o resultado

Um resultado é prova de algo, mas nem sempre é prova suficiente. Uma captura de ecrã pode mostrar o que apareceu num ecrã. Muitas vezes não consegue mostrar qual o modelo que o produziu, qual a fonte recuperada, o que uma ferramenta devolveu, qual a regra aplicada, quais os dados omitidos ou se a vista ocultou um aviso. Esta é uma das razões pelas quais as capturas de ecrã se acumulam nas pastas de conformidade com a solenidade de achados arqueológicos e consideravelmente menos poder explicativo.

Um contrato registado é mais rico. Liga o resultado às condições em que se esperava que o sistema atuasse. Para uma avaliação, pode incluir o conjunto exato, os dados ou uma referência protegida aos mesmos, as asserções esperadas, a configuração do modelo e do serviço, as versões relevantes das políticas e ferramentas, o ambiente de execução quando afeta o resultado e a regra de aceitação. Para uma execução em direto, pode incluir a identidade do pedido, o âmbito autorizado, os registos de fonte e recuperação, a rota do modelo, as chamadas de ferramentas, os controlos, a intervenção humana e a alteração de estado resultante. O objetivo não é registar um diário interminável. É reter informação causalmente relevante suficiente para poder colocar uma questão séria mais tarde.

Há uma distinção útil a fazer. Um registo de avaliação demonstra uma alegação sobre um teste ou exercício definido. Um registo operacional ajuda a reconstruir um evento ou decisão específicos. Um registo de lançamento explica por que razão uma organização permitiu que um sistema entrasse numa rota definida. Um registo de alteração explica o que foi alterado posteriormente. Estes registos sobrepõem-se, mas não devem ser confundidos. Tratar um registo de produção como um referencial, ou um referencial como prova de um fluxo de trabalho de produção, é uma forma eficiente de fazer com que cada registo suporte mais do que pode suportar.

A regra de registo do Regulamento IA para sistemas de alto risco está igualmente ligada à finalidade. O artigo 12.º exige o registo automático de eventos relevantes ao longo da vida do sistema, com capacidades de registo adequadas à finalidade prevista. O Regulamento refere-se à rastreabilidade do funcionamento do sistema, à monitorização do funcionamento e à monitorização pós-comercialização. Não exige um hábito de registo indiscriminado. Exige registos com uma função.

Essa expressão, registos com uma função, é um guia melhor do que uma exigência genérica de observabilidade. O identificador do modelo pode ajudar a distinguir uma atualização. A proveniência dos dados de entrada pode explicar uma recomendação surpreendente. Uma versão de regra pode explicar por que um resultado foi bloqueado. Uma anulação por revisor pode explicar por que a ação operacional difere da proposta do modelo. Um carimbo de data e hora pode estabelecer a ordem. Um design consciente da privacidade ainda questiona se cada campo é necessário, proporcionado, retido por um período definido e protegido do próprio sistema que se destina a inspecionar.

A reprodutibilidade tem duas formas honestas

As pessoas usam frequentemente reprodutível para significar várias coisas diferentes. A confusão é compreensível. Uma equipa pode querer dizer que consegue voltar a executar uma avaliação fixa e obter a mesma pontuação. Um investigador pode querer dizer que outra equipa consegue executar o método indicado e inspecionar o resultado. Um operador pode querer dizer que uma investigação consegue recriar o estado utilizado para uma decisão específica. Um cliente pode querer dizer que um fluxo de trabalho dá um tratamento consistente, em vez de mudar arbitrariamente de terça para quinta. Estes são objetivos relacionados. Não são uma única propriedade com várias roupagens.

Primeiro, há a reprodutibilidade da execução capturada. Se o artefacto, a configuração, as entradas, o estado relevante e as condições de execução forem mantidos fixos, uma repetição deve produzir o resultado documentado dentro das condições prometidas pelo sistema. Alguns sistemas conseguem fazer uma afirmação determinística mais forte para um caminho de execução definido. Outros dependem de aleatoriedade controlada, infraestrutura distribuída ou serviços de terceiros e só conseguem fazer uma afirmação mais restrita. A linguagem responsável é específica. Diz o que está fixo, o que é medido, que variação permanece possível e como é feita a comparação.

Segundo, há a reprodutibilidade do argumento de avaliação. Um revisor deve conseguir ver por que o conjunto representa a afirmação, se a métrica tem o significado indicado, se o limiar de aceitação é justificado e se a evidência pode transitar para o contexto operacional. Isto não se resolve com uma soma de verificação. Uma soma de verificação pode estabelecer que um ficheiro não mudou. Não pode estabelecer que o ficheiro testou a pergunta certa, que a população era adequada ou que uma pontuação sustenta a decisão a ela associada.

As duas formas devem encontrar-se. Um teste perfeitamente repetível que mede a coisa errada continua a ser o teste errado. Um argumento sofisticado associado a uma execução irrepetível deixa os revisores incapazes de distinguir uma descoberta de uma tarde de sorte. O padrão útil não é uma exigência abstrata de reprodutibilidade perfeita. É uma correspondência visível entre a afirmação, o método, as condições capturadas, o resultado observado e o uso que a organização pretende permitir.

As orientações da Comissão sobre as obrigações dos fornecedores de IA de uso geral também mantêm a avaliação ligada à documentação e ao risco. Descrevem documentação técnica para as autoridades e informações separadas para fornecedores a jusante, incluindo capacidades, limitações e informações de integração. Para modelos de IA de uso geral com risco sistémico, o artigo 55.º exige avaliação com protocolos normalizados e ferramentas de última geração, incluindo testes adversariais documentados para identificar e mitigar riscos sistémicos. Uma avaliação que não consegue dizer o que foi testado, em que condições e com que limitações não se torna mais útil por ser chamada normalizada.

A evidência tem uma condição de validade

As provas não caducam porque alguém decidiu ser difícil. Caducam quando as condições que permitiam sustentar uma alegação mudaram o suficiente para que a ligação deixe de poder ser assumida. Isto é raciocínio corrente. Um teste a um projeto de ponte não cobre automaticamente um material diferente. Uma verificação de segurança alimentar não cobre um novo fornecedor por força do otimismo. Uma avaliação de uma rota de IA não deve cobrir automaticamente um modelo alterado, um limite de dados alterado, uma autoridade de ferramenta alterada ou uma consequência de decisão alterada.

O trabalho difícil é decidir quais alterações interessam. Isto é uma questão de juízo técnico, análise de risco e governação, não uma única percentagem escrita numa política. Uma correção que altera a cor de um botão pode não ter relevância para uma avaliação. Uma alteração que torna um aviso menos visível pode ser material se o argumento de segurança depender de um revisor o ver. Reindexar um corpus de origem pode ser inofensivo para uma tarefa e crítico para outra. Um novo endpoint de modelo pode preservar uma capacidade ampla enquanto altera a latência, o comportamento de recusa, a cobertura linguística ou os padrões de utilização de ferramentas que interessam para a rota.

Um controlo de alterações útil começa, portanto, com uma pergunta de impacto, não com um ritual de lançamento. Que alegação pode esta alteração afetar? Que pressuposto perturba? Que provas dependiam do estado anterior? Uma verificação limitada responde à pergunta, ou a rota precisa de uma nova avaliação e decisão de lançamento? Quem pode tomar essa decisão, e quem pode contestá-la? As respostas devem ser registadas porque, caso contrário, o próximo revisor terá de as inferir a partir de títulos de tickets, folclore e uma ligeira alteração no tipo de letra usado no painel de lançamento.

É também aqui que a monitorização passa a fazer parte das provas, em vez de ser um passatempo separado de observabilidade. O artigo 72.º exige que os fornecedores de sistemas de IA de alto risco recolham, documentem e analisem ativa e sistematicamente dados relevantes sobre o desempenho ao longo do ciclo de vida do sistema, para poderem avaliar a conformidade contínua. O plano de monitorização pós-comercialização faz parte da documentação técnica. A monitorização não é, portanto, apenas uma forma de saber se o serviço está ocupado. É uma forma de saber se as condições subjacentes à alegação original continuam a verificar-se.

A monitorização não torna todos os resultados autoexplicativos. Um aumento do desacordo entre revisores e um sistema pode ter muitas causas. Uma alteração na atualidade das fontes pode refletir um problema no pipeline de dados, em vez de deriva do modelo. Uma taxa de recusa mais elevada pode representar uma política mais segura, uma integração avariada ou uma nova população de pedidos. O registo deve preservar contexto suficiente para uma investigação humana. As métricas são sinais. Não são testemunhas.

As provas são válidas num contexto definido. Uma alteração material cria uma questão para revisão, não uma lacuna que a contorne.

Uma alteração material precisa de um caminho de decisão

A expressão alteração material é muitas vezes tratada como se designasse uma propriedade evidente por si só. Não designa. Material para que alegação, que risco e que utilizador? A resposta tem de ser suficientemente específica para que as pessoas a possam usar quando estão cansadas, atrasadas e com vontade de classificar uma alteração como menor. Uma boa política não promete classificar antecipadamente todas as atualizações possíveis. Nomeia os fatores que determinam se é necessária uma reavaliação.

Esses fatores incluem habitualmente a finalidade pretendida, as pessoas afetadas, a autoridade concedida à via, as fontes de dados e os seus controlos de qualidade, a arquitetura do modelo ou do sistema, o âmbito da avaliação, os limiares de decisão, os sinais de monitorização, a supervisão humana, os controlos de segurança e os caminhos de recuperação. Uma modificação que altere qualquer um destes elementos pode ou não ser material. O que importa é se pode alterar as provas exigidas para a alegação existente ou o risco remanescente após os controlos.

O Regulamento IA contém uma responsabilidade explícita em torno da modificação substancial. A sua aplicação jurídica exata depende do sistema e dos intervenientes envolvidos, pelo que não deve ser comprimida num slogan. A lição operacional é mais simples e mais ampla: uma organização deve saber quando uma alteração transfere ou cria responsabilidade, quando a documentação existente deixa de ser adequada e quando o sistema deve ser avaliado novamente antes de um novo uso prosseguir. É menos entusiasmante do que o lançamento de uma funcionalidade. É também menos suscetível de produzir uma decisão difícil em que todos concordam que o sistema mudou, mas ninguém assume a decisão.

Um caminho de decisão dá a uma alteração um destino. Um caminho pode permitir uma conclusão documentada de ausência de impacto. Outro pode exigir uma avaliação de regressão direcionada. Outro pode exigir uma revisão de risco mais ampla, uma alteração às instruções de utilização, um plano de monitorização revisto ou uma nova aprovação de lançamento. O caminho mais grave pode exigir que a via permaneça limitada ou suspensa até existirem provas. O objetivo não é tornar cada edição dispendiosa. É tornar impossível disfarçar a edição importante como manutenção de rotina.

Há uma ausência de romantismo satisfatória nisto. Um registo de alteração pode mostrar o estado anterior, o estado proposto, as alegações afetadas, as provas analisadas, a decisão, a autoridade e as condições após o lançamento. É a governação na sua roupa de trabalho. Nunca parecerá tão emocionante como uma demonstração de modelo. Tem a propriedade mais útil de ajudar uma organização a explicar-se quando uma demonstração se tornou um serviço real.

A avaliação deve poder falhar em público, ou pelo menos no ficheiro

A avaliação torna-se performativa quando se assume que todos os resultados são resultados de lançamento. Um programa de avaliação maduro deve poder concluir que as provas estão incompletas, que um limiar não foi atingido, que uma limitação conhecida impede um uso proposto ou que uma alegação precisa de ser restringida. Não são exceções embaraçosas ao processo. São resultados do processo.

Isto é particularmente importante para sistemas adaptativos ou ligados externamente. Uma equipa pode descobrir que um conjunto de testes já não representa uma população de entrada viva. Um contrato de ferramenta pode tornar-se demasiado instável para sustentar uma alegação de repetição. Uma atualização de modelo pode melhorar uma tarefa, mas tornar uma via protegida mais difícil de supervisionar. Um sinal operacional pode mostrar que a transição do sistema para o revisor falha sob carga de trabalho normal. A resposta certa não é necessariamente um encerramento dramático. Pode ser um limite, um fluxo de trabalho revisto, um teste adicional, uma nova condição de aceitação ou uma decisão de não fazer a alegação original.

The record must let a reviewer see that negative result. Otherwise an organisation builds a very effective machine for collecting only the evidence it likes. The quality-management requirements in Article 17 are relevant here. They cover, among other things, techniques and procedures for design, development and quality control; examination, test and validation; data management; risk management; post-market monitoring; incident reporting; and communication with authorities. A quality system is not a folder that makes failures disappear. It is a way to detect, document and address them.

The same principle governs access. An external regulator, notified body or authorised reviewer may need technical evidence that cannot be published openly. A public summary may be appropriate for other parts of the record. These are different access routes, not different facts. The public should not be offered a cheerful account while the controlled record describes a narrower and more conditional reality. Confidentiality can be legitimate. Contradiction is a governance failure.

At Dweve, our public Trust Centre makes a small, deliberately limited example of this distinction. Its evaluations page says that an evaluation identifies the model, exact suite, configuration, captured state, evidence and reviewer decision. It also says that a repeated captured contract should produce byte-identical results on supported architectures, while a live rerun can differ when external evidence or adaptive state changes. The page separates the public method from a filled-in marketing result. That is not proof of a model's quality. It is simply the right shape of a claim about evaluation records.

Live monitoring is not a substitute for a pre-release decision

Monitoring is sometimes described as the answer to uncertainty: release the system, watch the dashboard, improve continuously. There is a useful instinct in that sentence. Systems need observation after release because deployment produces information that a laboratory cannot. But monitoring cannot retroactively support a decision for which the evidence was never adequate. It cannot tell a person affected by a flawed high-consequence action that the organisation will learn from the graph next month.

Pre-release evaluation and post-release monitoring answer different questions. Evaluation asks whether the organisation has enough evidence to permit a defined use now. Monitoring asks whether the conditions behind that permission still hold and whether new risks or failures are emerging. The first establishes a starting boundary. The second watches the boundary in operation. A credible system needs both, as well as a route for data and operational learning to return to risk assessment, documentation and change control.

That loop is what turns a static assurance packet into a living record. An evaluation gives a baseline. A deployment record says which baseline was adopted. Logging and monitoring show relevant behaviour. A change may alter the baseline or reveal its limits. A review then updates the claim, its evidence, its constraints or its status. The system moves. The record moves with it, but does not rewrite its own past. An auditor can see both the current position and the path by which it arrived there.

For high-risk systems, the AI Act is explicit that post-market monitoring should gather and analyse relevant performance data throughout the lifetime and allow continuous compliance to be evaluated. It also requires deployers to monitor operation based on instructions for use, and to inform the provider and relevant authority without undue delay where they have reason to consider that use may present a risk. Those requirements do not remove the need for professional judgement. They give professional judgement records, triggers and routes.

Existe uma tentação organizacional de tratar a monitorização como responsabilidade da equipa de operações e a avaliação como responsabilidade da equipa de modelos. Essa divisão falhará na primeira pergunta significativa sobre uma rota em produção. O modelador pode saber por que razão um teste foi escolhido. O operador pode saber que as fontes estavam desatualizadas. O responsável pela política pode saber que uma regra de decisão mudou. O revisor pode saber que a interface cria viés de automação. Uma trilha de auditoria deve unir as suas evidências sem fingir que uma única pessoa vê o sistema inteiro.

Pode um regulador reproduzir uma decisão?

Por vezes, a resposta deve ser sim, dentro de um âmbito definido. Se uma organização afirma que uma decisão ou avaliação pode ser reproduzida, precisa de definir o que significa reprodução. Significa repetir uma chamada ao modelo com o mesmo prompt? Significa reconstruir a sequência completa de recuperação e ferramentas? Significa reconstruir o registo que um revisor viu? Significa validar um cálculo determinístico a partir de dados preservados? Cada uma é útil. Cada uma tem pré-requisitos técnicos e legais diferentes.

Uma reprodução significativa começa com identidade preservada. O revisor precisa de saber qual versão do sistema e configuração estavam em vigor, quais entradas e versões de fontes eram admissíveis, quais políticas e permissões se aplicavam, quais dependências externas responderam e quais ações humanas alteraram o caminho. Alguns elementos podem precisar de ser armazenados diretamente. Outros podem ser referenciados por identificadores estáveis e reconstruídos através de sistemas controlados. O que não é aceitável é chamar a um exercício de reproduzível quando este depende de uma pesquisa web em direto, de uma linha de base de dados sobrescrita e de uma definição lembrada do portátil de um engenheiro.

Mesmo assim, uma reprodução pode reproduzir um registo em vez de repetir o mundo. Uma fonte em direto pode ser atualizada ou retirada. Um serviço de terceiros pode mudar. Um serviço adaptativo pode acumular novo estado governado. Um humano pode fazer um julgamento diferente quando confrontado com a mesma informação. Estas não são falhas na ideia de reprodução. São distinções que o registo deve preservar. A reprodução pode mostrar o que o sistema fez sob o contrato capturado. Não afirma que o mundo atual é idêntico a esse contrato.

É por isso que os registos de decisões humanas pertencem ao lado dos registos técnicos quando a supervisão humana faz parte do argumento de segurança ou de direitos. Uma auditoria pode precisar de saber que uma pessoa reviu uma recomendação, que informação estava disponível para ela, o que escolheu e que autoridade detinha. Não precisa de transformar cada revisor num alvo de vigilância nem de preservar material pessoal ilimitado. Precisa de informação suficiente para estabelecer se a supervisão prometida existiu no evento em questão.

A reprodução é, portanto, uma escada, não uma ostentação. Num degrau, um revisor pode identificar a versão. No seguinte, pode inspecionar a evidência. Mais acima, pode recriar um teste ou analisar um caminho de decisão em direto. A organização deve indicar qual degrau suporta, onde estão os limites e quais partes exigem acesso autorizado. Uma alegação de reprodução modesta e testável é muito mais forte do que uma garantia vaga de que tudo é rastreável.

As auditorias precisam de registos que discordam entre si

O registo público de estado de uma organização, o registo interno de versões, o relatório de avaliação, os registos operacionais e o registo de incidentes não devem dizer coisas diferentes sobre o mesmo estado básico. Mas também não devem ser documentos idênticos. Cada um tem um público e um propósito diferentes. O registo público pode indicar o propósito pretendido, o estado, as limitações conhecidas e um caminho para mais informações. O ficheiro técnico pode conter arquitetura detalhada, dados, testes e controlos. O registo operacional pode conter rastreabilidade ao nível do evento. O ficheiro de alterações pode explicar por que razão uma conclusão anterior foi revisitada.

A integridade vem da correspondência. Se uma página pública diz que uma rota está limitada a recomendação, os registos técnicos e operacionais não devem descrever ação automática. Se uma avaliação diz que diz respeito a um conjunto de fontes capturado, o registo de lançamento não deve aplicá-lo silenciosamente a um conjunto posterior. Se um registo de alteração diz que uma atualização do modelo foi imaterial, a avaliação de impacto deve indicar a alegação afetada e as provas. Se um sinal de monitorização suscita uma revisão, a decisão subsequente deve ser rastreável. Os documentos podem divergir em granularidade. Não devem divergir quanto à realidade.

Essa correspondência é útil para os reguladores porque reduz a necessidade de confiar num único artefacto polido. Um revisor pode comparar registos. É útil para as organizações porque expõe a divergência entre equipas antes de uma auditoria externa o fazer. E é útil para as pessoas afetadas porque a explicação pública pode tornar-se uma via real de responsabilização, em vez de uma camada decorativa colocada sobre um sistema privado separado.

A arquitetura não tem de ser elaborada. Uma pequena organização pode usar um registo controlado, documentos com versões, exportações assinadas e revisões de alterações disciplinadas. Uma organização maior pode usar manifestos estruturados, registos de anexação, motores de políticas e captura automatizada de provas. A questão importante é se o método consegue ligar de forma fiável alegação, estado, provas, decisão e alteração posterior. Um enorme parque de ferramentas que perde esta relação é simplesmente uma forma mais cara de ser vago.

Há uma virtude particularmente europeia em tornar o registo inspecionável sem o tornar teatral. Nem toda a resposta pertence a um painel público. Nem toda a incerteza documentada precisa de um ícone alegre. Mas quando uma organização fez uma alegação consequente sobre um sistema adaptativo, deve ser capaz de mostrar a um regulador onde essa alegação vive, a que estado se refere e como a organização saberia que ela se tornou desatualizada.

A questão da auditoria altera a questão do design

Pergunte cedo se um regulador poderia auditar o sistema tal como este irá realmente operar. A resposta altera escolhas de design muito antes de começar uma auditoria formal. Favorece identificadores estáveis em vez de rótulos ambíguos. Favorece versões de políticas explícitas em vez de regras embutidas em prosa. Favorece contratos de ferramentas que possam ser registados e testados. Favorece marcadores de proveniência e frescura das fontes. Favorece uma fronteira clara entre recomendação e ação. Favorece ecrãs de revisão que preservem a informação de que um revisor precisa. Favorece mecanismos de pausa e recuperação com autoridade nomeada.

Também altera a aquisição. A declaração de um fornecedor de que um modelo é regularmente melhorado não é suficiente quando a implementação depende de um estado avaliado definido. O comprador precisa de saber como as alterações são notificadas, que artefactos podem ser identificados, que informação está disponível para avaliação de impacto, se os registos históricos permanecem interpretáveis e como uma rota pode ser limitada ou posta em pausa. Não são exigências exóticas. São os termos práticos sob os quais uma organização permanece responsável por um sistema que contém um componente de fornecedor.

A mesma questão altera o design da avaliação. Uma suíte útil tem uma identidade e uma justificação. As suas entradas ou referências são controladas. As suas métricas e limiares são definidos antes de o resultado ser lido. As suas exclusões são visíveis. Os seus resultados ligam-se ao estado do sistema efetivamente em discussão. As suas falhas têm uma via para uma decisão. As suas condições de nova execução são claras. Uma avaliação com estas propriedades pode ser contestada. Isso é uma característica, não um efeito secundário infeliz de ser minucioso.

Acima de tudo, a questão muda o papel da mudança. A mudança deixa de ser um constrangimento que a documentação tenta esconder. Passa a ser um evento de primeira classe no modelo de evidências do sistema. Algumas mudanças exigirão pouco mais do que um registo. Outras desencadearão um teste. Outras reabrirão a decisão de lançamento. A organização disciplinada não confunde estas categorias e não precisa de um incidente futuro para descobrir que elas existiam.

Portanto, sim: um regulador pode auditar um alvo em movimento. A auditoria começa por recusar a falsa escolha entre um modelo de cartão congelado e um serviço em direto completamente incognoscível. Capture o estado. Declare a alegação. Preserve as condições. Ligue as evidências à decisão. Registe o que muda. Reavalie quando a ligação deixar de se verificar. O alvo pode mover-se. O rasto tem de permanecer legível.

Fontes