O trabalho discreto do Regulamento da UE sobre IA: registos, não slogans

A parte difícil do Regulamento da UE sobre IA não é repetir os seus princípios. É transformar risco, documentação, registos, supervisão humana e correção em...

O trabalho discreto do Regulamento da UE sobre IA: registos, não slogans

The record that arrives after the decision

There is a moment after an automated recommendation has been accepted when the room changes shape. The screen still shows the result. The conversation has moved on to what happens next. Someone asks which version of the system produced it, what information was available at the time, whether the operator could have rejected it, and which rule made the route permissible. These questions are not a dramatic attack on technology. They are the ordinary questions institutions ask when an action acquires a consequence.

Imagine a composite case, deliberately without a named organisation, system or incident. A public body uses a high-risk AI system to assist a decision that affects a person. A trained member of staff remains responsible for the decision. The model gives an output, the member of staff checks it, and the decision is made. Later, a supervisor needs to understand the path. The output itself is present. The decision is present. The chain between them is not. There is no clear record of the instructions in force, the input that was used, the version deployed, the intervention that was available or the reason the human accepted the result. Nothing in that description requires a spectacular malfunction. A missing record is enough to turn a review into a reconstruction exercise.

The European Union’s Artificial Intelligence Act is often discussed as a catalogue of prohibitions, categories and penalties. Those parts matter, but they are not the whole work. The Act also describes a quieter infrastructure of evidence: risk management that is documented and maintained, data practices that have an origin and a purpose, technical documentation that can be assessed, logs that record relevant events, instructions that tell a deployer how to interpret a system, human oversight that has real authority, and records that remain available when a question arrives later. The law is asking an institution to remember on purpose.

That is a less cinematic task than launching a model. It is also where accountability becomes real. A slogan can state that an organisation takes responsibility. A record can show what responsibility looked like at a particular time. It can show a boundary, an uncertainty, an approval, a refusal, a correction or an absence. It cannot make an unlawful decision lawful by existing after the fact, and it cannot repair a person’s loss by itself. It can make the path inspectable enough for a remedy, a correction and a better decision about the next version.

This article is about that quiet work. It reads the record-keeping and documentation duties in the AI Act as operating requirements rather than as paperwork attached to a launch. It asks what records can establish, what they cannot establish, how a record gains meaning from context, why completeness is not the same as volume, and how an organisation can build a routine that leaves evidence without turning every human interaction into a permanent surveillance object. The examples that are not taken directly from a cited source are labelled as proposed, hypothetical or composite. There is no invented incident waiting at the end of the story. The point is to avoid needing one.

As obrigações do Regulamento não são prateleiras separadas. Formam um percurso que vai do propósito e do risco até à evidência, à supervisão e à correção.

Porque é que o trabalho discreto importa

Os registos são fáceis de interpretar mal porque existem em quase todas as organizações. Uma linha numa base de dados, um ticket, um pedido de alteração, uma decisão assinada, um carimbo temporal e uma linha de log parecem todos registos. A sua mera presença diz muito pouco. Um registo torna-se útil quando responde a uma pergunta definida com contexto suficiente para distinguir o que aconteceu daquilo que alguém agora acredita que aconteceu. Essa distinção é especialmente importante para a IA, porque o resultado visível esconde muitas vezes o número de transformações que o precederam.

Um sistema de software convencional pode deixar um rasto familiar para quem o opera. Entra um pedido, um serviço valida campos, uma regra é executada, um estado muda e sai uma resposta. Os sistemas de IA podem acrescentar categorias inferidas, contexto recuperado, instruções em linguagem natural, resultados probabilísticos, chamadas a ferramentas, edições humanas e estado adaptativo. A flexibilidade adicional pode ser útil. Também cria mais oportunidades para um facto perder a sua origem ou para uma instrução se tornar autoritativa sem ser reconhecida como tal. O registo tem de preservar as distinções que a interface tende a suavizar.

O Regulamento da IA não exige que uma organização preserve todos os bytes que alguma vez passaram por um modelo. Os seus requisitos estão ligados ao propósito, ao risco, à rastreabilidade, ao ciclo de vida e ao controlo. Esse é um ponto de partida útil. Diz que a evidência deve ser proporcionada ao propósito pretendido e aos riscos, continuando ao mesmo tempo suficientemente rigorosa para a obrigação relevante. Um registo de uma sugestão de redação de baixo impacto não deve ser tratado como se fosse um processo completo para uma decisão que afeta direitos fundamentais. Inversamente, uma decisão importante não pode tornar-se responsabilizável guardando apenas uma frase final e um visto verde.

O trabalho discreto começa portanto antes de um sistema ser colocado em serviço. Alguém tem de declarar o que o sistema se destina a fazer, onde não se destina a operar, quais as pessoas e ambientes abrangidos, que dados de entrada pode receber, quem pode agir sobre o resultado e o que acontece quando o sistema está incerto ou indisponível. Estas não são apenas questões de conceção. São as condições que dão significado aos registos posteriores. Sem elas, um carimbo temporal diz-nos quando algo aconteceu, mas não se foi permitido, esperado ou uma exceção.

Existe uma razão institucional para levar isto a sério. Quem pede provas não é muitas vezes quem construiu o sistema. Uma autoridade competente, um revisor interno, uma pessoa afetada ou uma equipa sucessora pode encontrar o registo depois de o pessoal, os fornecedores e os modelos terem mudado. Provas que só fazem sentido para o seu autor original são uma forma frágil de responsabilização. A insistência do Regulamento em documentação clara, instruções compreensíveis e acesso para as autoridades é uma resposta a essa fragilidade. Trata a continuidade como parte da conformidade.

Leia o Regulamento como uma sequência, não como um slogan

Os requisitos de alto risco do Regulamento podem ser lidos como uma sequência de perguntas. O que se pretende que o sistema faça. Que riscos pode criar nesse contexto. Que dados e pressupostos o sustentam. Como foi o sistema construído e testado. O que precisa um responsável pela implantação de saber. Que eventos devem ser registados. Quem pode supervisionar, anular ou parar o sistema. O que acontece quando o sistema não está em conformidade ou apresenta um risco. A sequência não é um pipeline de software organizado. É uma cadeia de responsabilidade que volta atrás quando as provas mudam.

O artigo 9.º descreve a gestão de riscos como um processo contínuo e iterativo, planeado e executado ao longo de todo o ciclo de vida de um sistema de IA de alto risco. Deve ser estabelecida, implementada, documentada e mantida. Esta formulação tem uma consequência prática. Uma avaliação de riscos não é um documento cerimonial que se reforma no dia do lançamento. É o registo de um processo vivo que identifica e avalia riscos conhecidos e razoavelmente previsíveis, considera informações da monitorização pós-comercialização e adota medidas direcionadas. O registo deve permitir a um leitor posterior ver o que foi considerado, o que não foi possível eliminar, o que permaneceu como risco residual e quem aceitou essa posição.

O artigo 10.º coloca os dados e a governação de dados dentro dessa mesma disciplina. As práticas relevantes incluem escolhas de conceção, a origem dos dados, operações de preparação, pressupostos sobre o que os dados representam, disponibilidade e adequação, possíveis enviesamentos, lacunas nos dados e as medidas utilizadas para as resolver. Esta é uma ideia diferente de dizer que um conjunto de dados estava limpo. Limpo é uma conclusão. Origem, preparação, pressupostos e lacunas são provas sobre como a conclusão foi alcançada e onde pode deixar de ser fiável. Um registo que preserva apenas um rótulo de qualidade esqueceu as perguntas que tornavam a qualidade significativa.

O artigo 11.º exige documentação técnica para um sistema de IA de alto risco antes de ser colocado no mercado ou colocado em serviço, e exige que essa documentação seja mantida atualizada. Destina-se a fornecer às autoridades nacionais competentes e aos organismos notificados as informações necessárias para avaliar a conformidade. O ponto importante não é que todos os leitores se tornem especialistas num anexo. É que o sistema deve ter uma descrição de si próprio suficientemente clara e abrangente para uma avaliação externa. Essa descrição precisa de uma versão, uma finalidade e uma relação com versões anteriores. Um documento que descreve um sistema que já não existe é um arquivo, não provas atuais.

O artigo 12.º faz depois do funcionamento do sistema parte das provas. Os sistemas de IA de alto risco devem permitir tecnicamente o registo automático de eventos ao longo da sua vida útil. As capacidades de registo devem registar eventos relevantes para identificar situações que possam criar um risco ou uma modificação substancial, facilitando a monitorização pós-comercialização e a monitorização do funcionamento no âmbito dos deveres do responsável pela implantação. O nível de rastreabilidade exigido está ligado à finalidade pretendida. A lei não pede que o registo seja um diário da vida humana. Pede que o sistema deixe memória operacional suficiente para as perguntas relevantes.

Os artigos 13.º e 14.º ligam essa memória às pessoas. Um sistema de risco elevado tem de ser suficientemente transparente para que os utilizadores possam interpretar o seu resultado e utilizá-lo de forma adequada, e tem de ser acompanhado de instruções de utilização. A supervisão humana tem de ser eficaz e proporcionada ao risco, à autonomia e ao contexto. As pessoas encarregadas da supervisão têm de ser capazes de compreender capacidades e limitações, detetar anomalias e desempenhos inesperados, evitar uma confiança excessiva, interpretar resultados, ignorá-los ou anulá-los e, quando adequado, interromper o sistema em segurança. Estas capacidades não podem viver apenas num diapositivo de formação. Um registo sério deve permitir perceber o que o ser humano podia saber e fazer no momento da decisão.

Os artigos 15.º a 21.º completam o percurso do desempenho à reparação. A exatidão, a robustez e a cibersegurança são propriedades que acompanham todo o ciclo de vida. Os fornecedores têm de manter um sistema de gestão da qualidade documentado de forma ordenada, que inclua procedimentos relativos a dados, gestão do risco, monitorização pós-comercialização, comunicação de incidentes, comunicações, conservação de registos e um quadro de responsabilização. A documentação e os registos têm de permanecer disponíveis durante os períodos e para os fins que o Regulamento especifica. A ação corretiva e a cooperação com as autoridades competentes são deveres, não relações públicas facultativas. O resultado não é um slogan sobre IA de confiança. É um conjunto de artefactos que permitem a uma instituição demonstrar, investigar, corrigir e explicar.

Três coisas que um registo pode fazer

Em primeiro lugar, um registo pode estabelecer um acontecimento. Pode mostrar que um sistema foi acionado, que uma versão específica estava ativa, que foi recebida uma entrada, que foi proposta uma chamada de ferramenta, que foi registada uma aprovação humana, que uma ação foi concluída ou que um sistema foi interrompido. A prova do acontecimento é a camada que a maioria das pessoas imagina quando ouve a palavra registo. É importante porque uma ação contestada não pode ser investigada se a organização não conseguir determinar se a ação ocorreu. É também a camada menos completa se existir isoladamente.

Um registo de acontecimento precisa de uma identidade estável, uma referência temporal, um ator ou função responsável, uma identidade do sistema ou componente e estado suficiente para evitar ambiguidade. Os campos exatos dependem da finalidade e da lei. Um carimbo temporal sem base temporal pode ser confuso entre sistemas. Um identificador de utilizador sem função diz pouco sobre a autoridade. Um nome de modelo sem versão não permite estabelecer qual o comportamento em causa. Um registo pode ser tecnicamente autêntico e ainda assim institucionalmente pobre.

Em segundo lugar, um registo pode estabelecer uma base. Pode mostrar qual a finalidade, regra, instrução, fonte de dados, versão de política ou avaliação que sustentou uma ação. A prova da base é o que impede uma decisão de se tornar um resultado solto. Não tem de reproduzir todos os cálculos internos. Tem de identificar as condições que tornaram o resultado significativo e os limites que restringiram o que uma pessoa podia fazer com ele. Quando falta a base, uma organização pode saber o que fez sem saber por que tinha o direito de o fazer.

Em terceiro lugar, um registo pode estabelecer uma resposta. Pode mostrar que uma anomalia foi detetada, que um operador rejeitou um resultado, que um risco foi escalado, que um sistema foi suspenso, que uma correção foi aplicada ou que uma reclamação foi recebida e encaminhada. A prova da resposta é muitas vezes ignorada porque as equipas se concentram no primeiro resultado do modelo. Na prática, a responsabilização vive no que acontece depois de a incerteza se tornar visível. Um sistema que consegue produzir um registo de um problema mas não tem registo da resposta construiu um sensor sem travão.

Estas três funções sobrepõem-se, mas não devem ser fundidas. Uma citação de fonte pode estabelecer uma base sem provar que a fonte foi efetivamente utilizada na execução. Uma aprovação humana pode estabelecer uma resposta sem provar que o revisor viu um contexto completo. Uma versão de modelo pode estabelecer identidade sem provar que a versão se comportou de forma consistente. Bons registos tornam explícitas as afirmações que conseguem sustentar. Não pedem autoridade emprestada a registos vizinhos e chamam a esse arranjo uma cadeia.

A completude não é uma contagem de bytes. É a capacidade de responder às perguntas criadas pela finalidade e pelas consequências do sistema.

O que um registo não pode fazer

Um registo não pode converter uma prática proibida numa prática permitida. Se a própria utilização está fora da lei, um registo perfeito não constitui defesa. As provas podem expor uma decisão errada, mas não podem conceder retroativamente uma autoridade que nunca existiu. É por isso que a documentação nunca deve ser apresentada como substituto da análise jurídica, da avaliação dos direitos fundamentais ou de uma finalidade clara. Uma violação lindamente indexada continua a ser uma violação. O índice apenas facilita a sua localização.

Um registo não pode provar que uma decisão foi justa apenas porque os campos estão preenchidos. A justiça não é uma propriedade que aparece quando um formulário atinge cem por cento. A questão relevante é saber se o sistema, os dados, o fluxo de trabalho e o julgamento humano trataram as pessoas de uma forma que respeita os direitos e obrigações aplicáveis. Um registo pode preservar provas sobre essa questão. Pode mostrar que informações foram utilizadas, que regra foi aplicada, que exceções foram consideradas e como um recurso foi tratado. Não pode decidir sozinho a questão moral e jurídica.

Um registo não pode tornar uma explicação fraca significativa acrescentando pormenores técnicos. Uma pessoa afetada por uma decisão pode precisar de um relato claro do papel que a IA desempenhou e dos principais elementos da decisão. Despejar identificadores internos, rastreios brutos de tokens ou um ecrã cheio de telemetria de máquina sobre essa pessoa não é automaticamente transparência. A forma das provas tem de corresponder à pergunta e ao público. A autoridade precisa de documentação avaliável. Os operadores precisam de instruções utilizáveis. As pessoas afetadas precisam de um caminho compreensível para entender e contestar.

Um registo não pode preservar o futuro. É uma perspetiva de um momento específico, criada com a informação e o estado do sistema que existiam nessa altura. Essa limitação não é uma falha. É uma razão para registar versões, períodos de vigência e incerteza. Se uma política mudou depois de uma decisão, o registo não deve apresentar silenciosamente a nova política como se tivesse regido a ação antiga. Se uma fonte foi corrigida, a informação anterior deve permanecer identificável enquanto a correção e o seu efeito são registados. O tempo faz parte do significado, não é um enfeite no lado direito de um painel de controlo.

Um registo não pode contar a uma organização aquilo que ela não registou. Isto parece óbvio, mas é um limite importante numa era de explicações geradas. Pode pedir-se a um modelo que narre uma decisão passada. O texto resultante pode ser útil como hipótese ou resumo. A menos que esteja fundamentado em provas preservadas, não é uma máquina do tempo. A prática mais segura é rotular a reconstrução como reconstrução, identificar as provas em falta e evitar apresentar um relato plausível como um relato observado. Uma incompletude honesta é mais útil do que uma ficção completa.

Os registos de atividade são provas, não uma desculpa moral

O registo de atividade é atrativo porque parece objetivo. Uma linha com um carimbo de tempo e um identificador de sistema parece mais neutra do que uma nota humana. Não é neutra. Alguém decidiu o que registar, o que omitir, quais os campos a manter, como protegê-los, como sincronizar o tempo e quem pode inspecionar o resultado. O registo de atividade é uma escolha de engenharia com consequências legais e humanas. As disposições do Regulamento IA sobre conservação de registos tornam essa escolha visível, mas não eliminam a necessidade de a conceber cuidadosamente.

A primeira questão de conceção é a finalidade. O artigo 12.º identifica a rastreabilidade, a identificação de riscos, a monitorização pós-comercialização e a monitorização do funcionamento como razões para registar eventos relevantes. Cada razão pode exigir uma perspetiva diferente. Um operador pode precisar de uma explicação concisa de uma recusa e de um caminho para um supervisor. Um especialista em segurança pode precisar do histórico de versões e da origem dos dados de entrada. Uma autoridade competente pode precisar de documentação e registos suficientes para avaliar a conformidade. Um encarregado da proteção de dados pode precisar de saber quais os dados pessoais que o registo contém e por que motivo são conservados. Um único fluxo indiferenciado pode ser simultaneamente demasiado ruidoso para uma pessoa e demasiado fraco para uma investigação.

A segunda questão é o âmbito. Um registo útil documenta os eventos que interessam para a finalidade e o risco pretendidos, não todos os gestos incidentais. Para um sistema que apenas redige texto interno, o evento relevante pode ser a invocação, o conjunto de fontes, a versão do modelo, a versão das instruções, a libertação humana e o destino final. Para um sistema que pode alterar um registo externo, as transições de estado e as confirmações de ferramentas tornam-se essenciais. Para um sistema que apoia uma decisão de alto impacto, o âmbito dos dados de entrada, o resultado, a revisão humana e o percurso de correção importam mais do que um contador decorativo de tokens. O registo deve seguir a consequência.

A terceira questão é a integridade. Um registo que pode ser editado sem deteção pode ainda ser útil para operações, mas apresenta uma pretensão mais fraca sobre a história. Os controlos de integridade podem incluir restrições de acesso, armazenamento de anexação apenas, somas de verificação, assinaturas, referências de tempo independentes, correções controladas e conservação documentada. O mecanismo adequado depende do risco. O importante é declarar o que o mecanismo protege e o que não protege. A prova de adulteração pode mostrar que um registo foi alterado. Não pode mostrar que o registo original estava completo ou que o evento capturado era lícito.

A quarta questão é a privacidade. Os registos podem conter pedidos, identificadores, excertos de fontes, resultados do modelo, argumentos de ferramentas e notas humanas. Conservá-los todos para sempre pode criar um segundo problema em nome da resolução do primeiro. O próprio Regulamento liga os deveres de registo a outro direito da União e nacional, incluindo a proteção de dados. Uma conceção sensata separa a prova operacional do conteúdo desnecessário, limita o acesso, define a retenção e apoia a correção ou eliminação quando exigido. A minimização não é inimiga da responsabilização. É o que impede a responsabilização de se tornar numa licença para recolher uma biografia privada de cada utilizador.

A quinta questão é a repetição. Repetir não significa sempre voltar a executar um modelo probabilístico e esperar a mesma frase. Pode significar reconstruir o estado relevante: as versões do modelo e da política, as referências de fontes, a classificação da entrada, o conjunto de instruções, o resultado, a intervenção humana, o resultado da ferramenta e a ação subsequente. Uma repetição pode revelar que a reprodução exata é impossível porque uma dependência remota mudou. Esse resultado continua a ser prova se o sistema indicar o que foi preservado, o que não foi e porquê. O limite honesto da repetição vale mais do que um botão teatral rotulado como reproduzir.

Por fim, os registos precisam de um responsável. Um campo sem responsável torna-se uma promessa órfã. Alguém tem de decidir quais os eventos relevantes, verificar se a gravação funciona, monitorizar falhas no caminho de registo, proteger o acesso, testar a recuperação e eliminar registos de acordo com a finalidade declarada. O responsável pode ser uma equipa em vez de uma pessoa, mas a responsabilização não pode ser delegada num contentor de armazenamento. O contentor não comparece na reunião de revisão. Também tem um domínio dececionante da proporcionalidade.

A documentação é uma descrição viva

A documentação técnica é por vezes tratada como o lugar onde uma equipa de engenharia explica um produto a si própria. Ao abrigo do Regulamento IA, tem um público mais vasto. Precisa de fornecer informações que uma autoridade nacional competente ou um organismo notificado possa utilizar para avaliar a conformidade. Isso altera o tom do documento. Não deve ser um anúncio do sistema, nem um caderno privado cheio de referências que ninguém mais consegue seguir. É uma descrição controlada da finalidade, conceção, funcionamento, limites, dados, testes e alterações.

Uma descrição viva tem uma relação com a identidade do sistema. Identifica o fornecedor, a finalidade prevista e as versões relevantes. Explica como o sistema interage com outro software e hardware. Descreve os componentes e processos que afetam os requisitos. Regista os testes e a validação que sustentam as alegações de desempenho. Identifica as condições previsíveis que podem alterar o comportamento. Indica as interfaces e as medidas de supervisão de que o implementador necessita. Isto não significa que o documento deva expor indiscriminadamente segredos comerciais. Significa que a confidencialidade não pode tornar-se numa desculpa para não existir uma prestação de contas avaliável.

O controlo de versões é o ponto central. Um documento que muda sem histórico pode ocultar uma alteração fazendo o novo estado parecer o antigo. Um histórico que regista todas as correções de pontuação pode enterrar uma alteração substancial entre ruído inofensivo. Um registo de alterações útil identifica o que mudou, por que mudou, quem o autorizou, que avaliação foi repetida, que material a jusante deve ser atualizado e quando o novo estado entrou em vigor. O Regulamento IA refere a modificação substancial em vários pontos. Uma organização precisa de uma forma de detetar alterações antes de o rótulo se tornar numa disputa.

A proveniência também se aplica a pressupostos. Um sistema pode depender de um pressuposto sobre a população representada num conjunto de dados, a atualidade de uma fonte, o significado de um campo ou a competência de quem o implementa. Os pressupostos não são imperfeições embaraçosas para esconder numa nota de rodapé. São os limites daquilo que o sistema afirma. Um registo que os nomeia dá ao operador a oportunidade de reconhecer quando esse limite foi atingido. Um registo que os esconde convida a que o sistema seja utilizado fora das condições em que as suas evidências faziam sentido.

A documentação deve tornar a incerteza legível sem fingir que todas as incógnitas podem ser quantificadas. Algumas incertezas são numéricas. Outras dizem respeito a cobertura em falta, conflitos por resolver, alterações à lei, entradas novas ou uma interação não testada com outro componente. Uma boa descrição pode dizer que uma condição não foi avaliada, que um resultado depende do julgamento humano ou que o sistema não deve ser utilizado para um fim nomeado. Estas afirmações não são sinais de um sistema fraco. São a informação que permite a um sistema robusto manter-se dentro do seu âmbito de validade.

Há uma diferença entre uma limitação e uma recusa. Uma limitação indica onde a afirmação de um sistema se torna pouco fiável. Uma recusa indica que o sistema não avançará sob uma condição. Ambas devem ser documentadas. Se o utilizador apenas vir um erro genérico, a organização perde a oportunidade de explicar se a restrição protege a segurança, a privacidade, os direitos, a qualidade ou a capacidade. Registos de recusa claros também apoiam a melhoria. Recusas repetidas podem mostrar que um fluxo de trabalho está a pedir ao sistema que faça uma tarefa para a qual nunca foi concebido.

A supervisão humana precisa de evidências à sua volta

As disposições do AI Act sobre supervisão humana são fáceis de resumir e difíceis de implementar. Atribuir uma pessoa não é o mesmo que permitir a supervisão. A pessoa precisa de competência, formação, autoridade e apoio. Precisa de compreender capacidades e limitações, detetar anomalias, evitar o viés de automação, interpretar resultados e decidir não utilizar, anular, reverter ou parar o sistema. Estes são poderes operacionais. Uma pessoa que é tecnicamente nomeada como revisora mas não consegue ver a entrada, alterar o resultado ou pausar o fluxo de trabalho é uma testemunha, não uma supervisora.

Os registos podem mostrar se a supervisão tinha força. Podem identificar a função atribuída, a informação apresentada, o aviso ou a limitação exibida, a ação tomada pela revisora e a decisão final. Podem preservar uma razão para uma anulação sem obrigar a pessoa a redigir um ensaio de cada vez. Podem também mostrar quando o sistema esteve indisponível ou quando o percurso de revisão foi contornado. A ausência de uma ação humana não é automaticamente uma má conduta. É um sinal para examinar se o design tornou a ação possível, necessária e visível.

Considere um padrão proposto em vez de um evento relatado. Um sistema fornece uma recomendação e um pequeno painel de evidências. A revisora pode aceitar, editar, rejeitar ou escalar. A interface regista a versão do sistema, as referências das fontes, o estado da política, a função da revisora e a decisão. Se a revisora rejeitar a recomendação, o registo armazena uma razão controlada e envia o caso para acompanhamento quando o padrão sugere um defeito recorrente. Isto não é uma afirmação de que o padrão é suficiente para todos os contextos de alto risco. Mostra como uma interface pode transformar a supervisão humana de uma caixa de verificação numa parte observável da decisão.

Human review also needs protection from fatigue and social pressure. A record that shows thousands of approvals but no meaningful interventions may indicate that the workflow is healthy, or it may indicate that the reviewer cannot realistically challenge the output. The numbers alone cannot decide. A useful monitoring routine combines dispositions with sampling, error findings, escalation quality, time available, training and the consequences of a wrong answer. Measurement should illuminate the work, not create a quota that teaches people to approve faster.

Oversight must include the right to stop. Article 14 describes intervention or interruption through a stop button or similar procedure that allows the system to halt in a safe state. A stop control that exists only in a runbook is not the same as a control that an authorised person can reach under pressure. The record should show whether the stop was available, who could use it, what state followed and how the workflow resumed. A system that can be stopped but cannot explain what was stopped has only solved half the problem.

There is a humane side to this evidence. When an outcome is challenged, records can protect the reviewer as well as the affected person. They can show that the reviewer saw a limitation, followed the procedure, escalated a conflict or stopped a risky action. That does not make every decision correct. It makes the conditions of judgement visible. Accountability is not the hunt for the nearest human fingerprint. It is the attempt to understand the chain well enough to improve it.

The quality system behind the paperwork

Article 17 requires providers of high-risk AI systems to put a quality management system in place and document it systematically and orderly through policies, procedures and instructions. Its list is deliberately broad. It includes regulatory compliance and modification management, design and development controls, testing and validation, technical specifications, data management, risk management, post-market monitoring, serious-incident reporting, communication with authorities and other operators, record-keeping, resource management and an accountability framework for management and staff.

Read as a whole, this is not a demand for one more compliance folder. It is a demand that the organisation can connect its decisions. The test procedure should have a relationship to the risk. The data process should have a relationship to the intended purpose. The change process should have a relationship to the documentation. The monitoring process should have a relationship to corrective action. The responsibility framework should have a relationship to the people who can actually change the system. If each document is maintained in isolation, the quality system becomes an archive of unrelated good intentions.

A useful quality record answers four practical questions. What was supposed to happen. What actually happened. How was the difference noticed. What changed as a result. The answer may be distributed across a risk register, test report, change record, incident report and release decision. That is acceptable if the relationships are stable and intelligible. It is not acceptable if a reviewer must guess which files belong to the same system state or which test result was used to support a particular release.

The system also needs a way to record a decision not to change. A risk may be assessed and judged acceptable within the documented conditions. A proposed feature may be rejected because evidence is insufficient. A release may wait because an evaluation is incomplete. These are decisions with a basis, not empty space in the calendar. Recording them prevents a later reader from confusing a deliberate boundary with an accidental omission. It also helps a team resist the pressure to turn every unresolved question into a launch plan.

A gestão da qualidade tem uma dimensão temporal. Um processo que funcionava para um modelo estático pode deixar de funcionar quando o sistema aprende após a implementação, altera o seu índice de recuperação ou recebe uma nova ferramenta. Um processo que funciona para um assistente interno pode deixar de funcionar quando o mesmo componente é integrado num fluxo de trabalho de decisão. O registo deve, por isso, identificar os fatores que desencadeiam a revisão: uma versão do modelo, uma fonte de dados, uma finalidade, uma população de utilizadores, uma permissão de ferramenta, um requisito legal, um incidente ou um padrão na monitorização. O fator desencadeante faz parte do controlo.

A proporcionalidade também é importante aqui. O Regulamento estabelece que a implementação deve ser proporcional à dimensão da organização do fornecedor, respeitando simultaneamente o rigor e a proteção necessários para a conformidade. Proporcional não significa informal. Um pequeno fornecedor pode utilizar um conjunto compacto de registos bem concebidos em vez de reproduzir a maquinaria de uma grande instituição. Continua a precisar de saber quem é responsável por cada decisão, onde está armazenada a evidência, como são avaliadas as alterações e como uma autoridade pode obter as informações de que necessita. Pequeno não significa isento de memória.

A retenção é uma escolha de conceção

O artigo 18.º exige que os fornecedores mantenham a documentação especificada à disposição das autoridades nacionais competentes durante um período que termina dez anos após a colocação no mercado ou a entrada em serviço de um sistema de IA de alto risco. O artigo 19.º aborda os registos gerados automaticamente e exige que sejam conservados, quando estejam sob o controlo do fornecedor, durante um período adequado à finalidade pretendida e de pelo menos seis meses, salvo disposição legal em contrário, incluindo a legislação em matéria de proteção de dados. Estes são requisitos legais com âmbitos precisos. Não devem ser generalizados levianamente a todos os registos em todos os fluxos de trabalho de IA.

A lição prática é que a retenção deve ser concebida por classe de registo. A documentação técnica, os registos do sistema de qualidade, o material de conformidade, os registos, os dados de origem, as notas humanas, os conjuntos de avaliação, a evidência de incidentes e as explicações públicas podem ter finalidades e durações diferentes. Uma única definição de retenção predefinida é um atalho arquitetónico, não uma estratégia de governação. Pode apagar evidência demasiado cedo ou manter material sensível muito depois de a sua finalidade ter terminado. O sistema deve saber que camada está a guardar e porquê.

A retenção também precisa de um início e de um fim. Um registo que diga conservar durante dez anos sem definir o evento a partir do qual o período é contado não está operacionalmente completo. Um registo conservado durante seis meses sem indicar se o período segue o evento, a divulgação ou o fim de um ciclo de monitorização convida a uma confusão evitável. O texto legal fornece os pontos de referência relevantes para as obrigações específicas. A organização deve mapear esses pontos de referência para os estados do sistema e tornar esse mapeamento inspecionável.

Eliminar um registo é, em si, um evento. Se um prompt de trabalho for removido porque a sua finalidade terminou, o sistema pode precisar de preservar uma referência que mostre que a remoção ocorreu e que regra de retenção a autorizou. Se um erro for corrigido, a evidência original pode precisar de permanecer disponível sob um histórico controlado, em vez de desaparecer sem explicação. Se dados pessoais forem eliminados, os artefactos derivados e os caminhos de acesso podem exigir uma análise separada. O registo da eliminação não deve ser confundido com a prova de que todas as cópias desapareceram. É evidência de uma ação controlada dentro de um limite definido.

A retenção também pode proteger a aprendizagem institucional. Uma revisão de incidente que guarda apenas a conclusão final perde as condições que produziram o problema. Um registo de avaliação que guarda apenas uma pontuação perde a carga de trabalho, a população, o método e os limites que tornaram a pontuação interpretável. Um registo de correção que guarda apenas o novo valor perde o facto de um valor errado ter circulado por um sistema. Guardar tudo não é a resposta. Guardar a evidência certa para a pergunta é.

Quando falta evidência

The most useful record systems are designed for absence. They can say that a source was unavailable, that a field was redacted, that a version identifier was unknown, that a human review did not occur, that a tool acknowledgement failed or that a replay cannot be completed. This is not an invitation to manufacture a tidy placeholder. It is a way to prevent missing evidence from being silently converted into confidence.

Absence has types. Not collected means the system never attempted to preserve the field. Not available means the field existed elsewhere but could not be obtained. Not applicable means the condition did not belong to the workflow. Redacted means the evidence exists but is restricted under a rule. Conflicted means two sources disagree. Unknown means the organisation has not established the answer. These labels are proposed operating vocabulary, not terms mandated by the AI Act. Their value is that they keep different problems from collapsing into one empty cell.

A completeness inspector should therefore ask questions, not count fields. Does the record identify the system state. Does it show the purpose and input scope. Can the source or policy basis be found. Is the human authority visible. Are uncertainty and exclusions named. Can a person correct, appeal, suspend or delete within the applicable boundary. The answers depend on context. A record may be complete for an operational alert and incomplete for an individual decision. Completeness is a relationship between evidence and consequence.

Missing records should trigger a response that matches the risk. A low-impact missing label may be repaired in the next release. A missing model version for a consequential decision may require the decision to be reviewed or the workflow suspended. A missing log of a state-changing tool call may require investigation outside the model team. The organisation should decide these thresholds before the incident, because deciding them during a heated review usually produces a policy made of adrenaline.

The absence path also needs an owner and a timestamp. If a required record cannot be produced, someone should know who is responsible for investigating, who can decide whether work continues, which evidence is being sought and when the status will be reviewed. That turns a gap into a managed state. It does not make the gap harmless. It prevents the institution from pretending that a missing page is an empty page.

The AI Office and the work of interpretation

The AI Act creates institutions and procedures that help turn the Regulation into practice. The Commission’s AI Office has a role in supervising and enforcing the obligations for general-purpose AI models, while national competent authorities and market surveillance authorities have responsibilities within the broader framework. The AI Act Service Desk provides an explainer for Article 12 that summarises the record-keeping duty and points readers to the official text. Its summary is explicitly non-binding. That distinction is worth preserving.

Guidance can make a rule usable by translating a legal requirement into examples, questions and implementation choices. It cannot replace the Regulation. An organisation should be able to show which claim comes from the binding text, which comes from guidance and which is its own control decision. This source discipline is not academic fussiness. It prevents a helpful example from becoming a fictional obligation and prevents a voluntary practice from being marketed internally as a legal minimum.

A comunicação AI@EC da Comissão oferece um exemplo institucional útil, sem pretender descrever todos os organismos públicos. Em janeiro de 2024, a Comissão definiu uma abordagem para o seu próprio desenvolvimento e utilização da IA, incluindo orientações operacionais internas, avaliação e classificação baseadas no risco, a exclusão de sistemas incompatíveis com os valores europeus ou que ameacem os direitos e a segurança, e estruturas organizativas para cumprir as obrigações. A questão não é que uma comunicação resolva a implementação. A questão é que uma instituição que se prepara para utilizar a IA também tem de preparar a sua própria capacidade de governar essa utilização.

Essa capacidade é construída a partir de registos que podem circular. Uma política deve indicar um responsável. Uma avaliação de risco deve indicar uma identidade de sistema. Uma descrição técnica deve indicar uma versão. Um registo de formação deve indicar uma função e uma competência. Um sinal de monitorização deve indicar uma ação. Uma reclamação deve indicar um canal. Quando estas relações são explícitas, as orientações podem ser aplicadas sem inventar um universo paralelo de burocracia. Quando não o são, cada nova orientação torna-se mais um documento que a organização espera que, de alguma forma, mude o comportamento.

O direito europeu tem uma textura institucional particular. As responsabilidades estão distribuídas pelas instituições da União, Estados-Membros, autoridades, fornecedores, implantadores e outros operadores. Um registo tem de tornar essa distribuição visível, em vez de nivelar todos os intervenientes numa categoria genérica de proprietário do sistema. A questão não é apenas quem construiu o modelo. É quem o colocou em serviço, quem controla os dados de entrada, quem atribuiu a supervisão, quem pode suspender a utilização e quem deve cooperar com uma autoridade. Os nomes e os contratos importam, mas também importam os poderes operacionais que um registo pode revelar.

Da linguagem jurídica à rotina diária

A lei torna-se prática quando uma organização converte cada obrigação num pequeno número de rotinas repetíveis. Este é um padrão operacional proposto, não uma lista de verificação jurídica. Na receção, classifique a finalidade pretendida, as pessoas afetadas, as categorias de dados, a autonomia, as ferramentas e a autoridade de decisão. Antes da disponibilização, vincule a identidade do sistema, a versão, o estado das instruções, as fontes de dados, os testes, os limites, a função de supervisão e o canal de interrupção. Durante o funcionamento, registe os eventos relevantes, monitorize os riscos e torne visível a incerteza. Após uma alteração ou incidente, investigue, corrija, atualize a descrição e decida se a utilização deve continuar.

Repare no que este padrão não diz. Não diz para recolher todas as mensagens para sempre. Não diz que um registo automatizado é o mesmo que uma explicação. Não diz que um painel de controlo prova a segurança. Não diz que um nome humano num fluxo de trabalho prova supervisão. Diz que o sistema deve ter um registo das condições em que está autorizado a funcionar e dos eventos que podem mostrar se essas condições se verificaram.

Uma boa rotina tem um início e um fim. Um registo é criado quando um estado relevante começa, atualizado quando as provas ou a autoridade mudam e encerrado quando a finalidade ou o período de revisão termina. O evento de encerramento é importante porque os registos abertos tornam-se silenciosamente permanentes. Deve indicar se o sistema foi disponibilizado, rejeitado, suspenso, substituído, corrigido ou retirado. Se o registo não puder ser encerrado, a organização deve saber porquê. Um estatuto provisório interminável é uma forma educada de evitar uma decisão.

As rotinas devem também distinguir factos de interpretações. Um registo pode documentar que um modelo produziu um resultado. Um revisor pode registar que o resultado foi rejeitado porque uma fonte entrava em conflito com uma política. Uma equipa de incidentes pode mais tarde inferir que uma alteração na recuperação contribuiu para o conflito. A inferência pode ser sólida, mas não é o mesmo tipo de prova que o evento. Camadas rotuladas tornam a investigação posterior mais honesta. Sem elas, cada conclusão endurece gradualmente num facto, porque ninguém se lembra de qual frase foi observada e qual foi escrita na reunião.

A propriedade deve ser visível ao nível do campo, sempre que for prático. O fornecedor pode ser o proprietário da documentação técnica. O implementador pode ser o proprietário da relevância dos dados de entrada e da monitorização operacional. O responsável pelos dados pode ser o proprietário dos direitos de origem e da qualidade. Uma função de supervisão humana pode ser a proprietária da decisão de aceitar, anular ou interromper. Uma função de registo pode ser a proprietária da retenção e do acesso. A atribuição varia consoante o contexto e o contrato. O registo deve permitir colocar uma pergunta ao proprietário certo sem enviar um e-mail em cadeia para toda a organização.

Testar a rotina é tão importante como escrevê-la. Um controlo proposto deve ser exercido com um cenário seguro e claramente identificado. A equipa consegue recuperar o registo por versão do sistema? O operador consegue ver o estado das instruções utilizado na versão? O revisor consegue rejeitar um resultado e preservar o motivo? O caminho de interrupção consegue deixar um estado claro? Uma autoridade competente consegue receber a documentação relevante sem uma caça ao tesouro? Estes são exercícios, não incidentes comunicados. Os seus resultados devem ser registados como testes, com as limitações declaradas de forma clara.

A rotina deve ser concebida para um dia calmo. Se só funciona quando um especialista está acordado, um fornecedor responde rapidamente e toda a gente se lembra do histórico de implementação, não é uma rotina. É memória coletiva com um acordo de nível de serviço. Um sistema de registo sério dá aos funcionários comuns uma forma de responder a perguntas comuns e dá aos especialistas um caminho mais profundo quando a pergunta se torna consequente. O dia calmo é onde o sistema ganha o direito de ser digno de confiança no dia ruidoso.

Há uma tentação de tornar os registos bonitos. Um design claro ajuda as pessoas a utilizá-los, mas o polimento visual não é prova. Um estado colorido, uma pontuação de maturidade ou um cartão de aspeto completo podem esconder campos em falta. A interface deve tornar a incerteza, os dados desatualizados e as afirmações não verificadas mais difíceis de ignorar. Deve apoiar as ações monótonas que mantêm um registo verdadeiro: fixar uma versão, identificar uma fonte, nomear uma função, assinalar uma limitação, ligar uma correção e encerrar um estado. Um bom design dá pegas ao registo. Não dá ao registo poderes que ele não conquistou.

Uma pequena nota nossa

Na Dweve, o nosso Trust Centre está organizado em torno desta mesma questão: o que deve outra pessoa poder inspecionar sobre um modelo e o seu funcionamento. O índice público liga a identidade do modelo, o conteúdo de formação, as avaliações, a gestão de riscos, a monitorização pós-comercialização, os incidentes, a governação de dados e a documentação técnica. Esta organização não é uma afirmação de que uma página pública prova conformidade, nem substitui a avaliação de uma autoridade. É uma tentativa deliberada de manter os registos e os seus limites visíveis. O nosso trabalho Ledger apresenta um argumento relacionado ao nível operacional: um registo deve conter identidade e histórico suficientes para que um leitor posterior possa verificar o que mudou. O teste útil não é se a página parece tranquilizadora. É se as provas dizem a verdade sobre o que podem e não podem estabelecer.

Os registos fazem parte da instituição

O erro mais profundo é tratar os requisitos de registo do AI Act como um imposto sobre a inovação. São melhor compreendidos como uma descrição do que uma instituição precisa para utilizar um sistema poderoso e em mudança sem perder a sua memória. Um modelo pode produzir um resultado rapidamente. Uma instituição tem de decidir se o resultado pertence a uma decisão, se alguém pode contestá-lo, se uma correção pode percorrer o sistema e se um leitor futuro consegue compreender o caminho.

É por isto que os registos não podem ficar à margem da arquitetura. Pertencem ao lado dos dados, das instruções, das versões de modelos, das ferramentas, das interfaces, dos papéis humanos e das soluções. O registo é o tecido conjuntivo que permite que essas partes respondam umas às outras. Transforma uma declaração de risco numa condição passível de revisão. Transforma uma fonte numa base rastreável. Transforma uma aprovação humana num ato observável. Transforma uma correção numa alteração que pode ser verificada. Transforma um campo em falta numa questão gerida, em vez de um espaço em branco que ninguém assume.

O trabalho é discreto porque parece comum. Dê um nome ao sistema. Fixe o propósito. Registe a versão. Mantenha a fronteira da fonte. Teste o registo. Dê autoridade ao revisor. Marque o que é desconhecido. Preserve a resposta. Retire o registo quando o propósito terminar. Nada disto tem o glamour de um vídeo de lançamento. Tem a propriedade mais valiosa de sobreviver a uma mudança de pessoal, a uma mudança de modelo, a uma mudança de fornecedor e a uma pergunta de alguém que não estava na sala.

Continuará a haver desacordo sobre a interpretação do Regulamento IA, sobre o nível de detalhe adequado e sobre a forma como as normas traduzirão os requisitos legais em prática técnica. Os registos não eliminam esses argumentos. Tornam-nos mais precisos. Uma organização pode mostrar em que texto se baseou, que pressuposto assumiu, que provas tinha, que controlo escolheu e onde permanece a sua incerteza. Esse é um melhor ponto de partida para um regulador, para um colega, para uma pessoa afetada e para a própria organização.

A lição prática é simples. Não pergunte apenas se um sistema de IA consegue produzir um resultado. Pergunte se a instituição consegue recordar as condições desse resultado, mostrar as provas que importaram, nomear a autoridade que agiu, identificar a incerteza que permaneceu e fazer uma correção circular. Se a resposta for não, o sistema pode ainda ser tecnicamente impressionante. Mas ainda não está institucionalmente pronto.

O trabalho discreto do Regulamento IA da UE não consiste, portanto, em fazer a tecnologia parecer séria. Consiste em tornar a seriedade observável. Os registos não são slogans com carimbos de data e hora. São provas delimitadas, criadas com um propósito, ligadas à responsabilidade e abertas a correção. Construa-os com cuidado, e uma organização pode usar IA sem pedir que a fluência substitua a memória. Deixe-os como pensamento de última hora, e a primeira pergunta difícil descobrirá que o sistema guardou o seu resultado, mas perdeu a sua história.

Fontes