O direito a saber o que mudou

Uma decisão pública nunca é apenas a sua sentença final. É a regra, os dados, o sistema, o fluxo de trabalho e a autoridade humana que tornaram essa...

O direito a saber o que mudou

The document that was not there

In March 2024, the European Ombudsman opened an inquiry into how the European Commission decides on and uses artificial intelligence. The questions concerned three ordinary areas of administrative work: analysing public feedback, finding possible infringements of competition rules, and handling complaints. The Ombudsman asked about automation, the decision to use AI, transparency around that decision, and accountability. The public notice did not describe a theatrical failure. It described a need to understand how an institution makes and governs a choice.

That distinction matters. When an authority is asked why it used a system, the useful answer is rarely the final press release. A reviewer needs to know what purpose was approved, which rule and data definition were in force, what system version was used, what the operator could see, and which person had the authority to accept or reject the result. The explanation is a route through time. If the route has been overwritten by the present, the institution can offer a plausible account, but not necessarily the account that was true when the decision was made.

Public organisations have understood this problem for a long time. A permit, a policy note, a register entry, a court file and a ministerial decision all acquire meaning from their history. A law has an effective date. A public record has a creator and a context. A correction does not quietly become the original. Digital systems have not removed those facts. They have scattered them across releases, configuration, source feeds, queues, prompts, access rules and supplier services. The final status may still be visible. The path that gave it authority may be gone.

The right to know what changed is therefore not a request for every keystroke. It is a claim about accountable memory. People affected by a public decision should be able to learn which version of the relevant world produced it, within the limits set by privacy, security and other legitimate interests. Institutions need the same knowledge to correct mistakes, answer appeals and explain their own conduct. A history is not a decorative appendix to a decision. It is part of what makes the decision a decision rather than an orphaned output.

A changelog is a courtesy; history is evidence

Software teams are familiar with changelogs. A release note says that an interface was improved, a bug was fixed, or a dependency was updated. A good changelog is useful communication. It helps users decide whether to upgrade and gives maintainers a public account of their work. It is not, by itself, a decision record. It normally describes what the publisher considers important. It does not promise to reproduce the state of every case that passed through the system.

Decision history has a different job. It must answer a question about a particular act at a particular time. Which version of the eligibility rule was applied to this application. Which definition of income was available when the score was calculated. Which model and calibration produced the ranking. Which workflow route put the case in front of this reviewer. Which evidence did the reviewer see. Which notification was sent. The answer may refer to a changelog, but it cannot stop there. A release note describes a change in general. A history connects a change to an affected decision.

This is why a green line saying updated is not enough. Updated when, under whose authority, with which effective date, and for which cases. An entry saying policy improved leaves open whether the old policy remains relevant to an appeal, whether an earlier outcome needs review, and whether the change was deployed everywhere at once. A history carries relationships, not adjectives. It links an object to its previous state, its successor, the reason for the transition, and the period in which the state was valid.

Há uma diferença prática na forma como os dois registos são escritos. Um changelog pode ser escrito depois do trabalho de engenharia, porque quem o lê precisa de um resumo. Um histórico de decisões tem de ser criado à medida que o trabalho acontece, ou a partir de registos criados nessa altura. As notas retrospetivas são úteis, mas são interpretação. Não podem substituir com segurança o contexto contemporâneo. A diferença não tem romantismo. Um registo ajuda as pessoas a acompanhar um produto. O outro permite que uma instituição se responsabilize por um ato.

Um histórico de decisões liga o resultado às versões que o tornaram possível e deixa um caminho para a correção.

O que mudou raramente é uma coisa só

Quando uma decisão é revisitada, as pessoas começam muitas vezes pelo componente mais visível. O modelo mudou. O formulário mudou. A página de política tem um novo título. O fornecedor implementou uma atualização. Estas afirmações podem ser todas verdadeiras e mesmo assim não captar a mudança operativa. Uma decisão pública é composta por camadas que se movem a velocidades diferentes, com responsáveis diferentes e ideias diferentes do que conta como uma versão.

A camada de dados pode mudar quando uma autoridade de origem corrige a morada de uma pessoa, uma definição estatística, um código de classificação ou uma tabela de referência. Um pipeline pode mudar a forma como junta registos ou lida com valores em falta. Um índice de recuperação pode ser reconstruído a partir de uma coleção diferente. Uma cache pode reter uma interpretação mais antiga depois de a origem ter avançado. Nenhuma destas alterações precisa de ser chamada mudança de IA para alterar o resultado de um fluxo de trabalho assistido por IA.

A camada de regras também tem mais do que uma superfície. Pode haver um estatuto, uma política interna, uma instrução escrita, um limiar na configuração, uma tabela de exceções e uma nota de formação para revisores. A política publicada pode permanecer palavra por palavra enquanto um limiar muda num ficheiro de implementação. Inversamente, uma política pode mudar enquanto a regra antiga continua a funcionar numa região porque a versão foi distribuída por fases. Uma pessoa afetada pelo resultado não devia ter de saber que equipa é responsável por que fragmento antes de perguntar o que aconteceu.

A camada do sistema inclui o modelo, os seus pesos ou pacote, o seu prompt ou modelo de texto, a sua configuração de recuperação, as suas definições de segurança e o software que o chama. A camada do fluxo de trabalho inclui a fila, a rota, as permissões, o ecrã e a passagem de testemunho. A ação de um revisor depende do que a interface apresenta como relevante e do que torna possível. A camada da decisão inclui o resultado, a explicação, a notificação, o efeito a jusante e qualquer recurso. O histórico de versões é a disciplina de nomear as camadas que importaram, não uma tentativa de fazer um número de versão gigante realizar magia institucional.

O arquivo já sabe que as versões importam

The Dutch National Archives uses a definition that is refreshingly plain: a historical version is a previous version of an information object. Its guidance gives ordinary examples. A note can move from draft to concept to adopted text. A law can be amended. Information can be added to a permit application. A person can move, changing the value in a register. Depending on the importance of the change, earlier versions may need to remain accessible. That is not a new demand created by machine learning. It is recordkeeping applied to digital work.

The same guidance makes two points that are easy to lose in a discussion about cloud systems. Government information is covered regardless of its technical form. It can be a database entry, a webpage, a message or a video, not only a signed paper. And the place where the information is stored does not settle whether it needs to remain accessible. A supplier’s server does not make the record less relevant to the institution that used it. A private laptop does not turn official information into a personal souvenir.

These principles are useful for AI because AI hides ordinary information inside technical surfaces. A feature definition, a model card, an evaluation notebook, a prompt template, a routing rule or an approval message can determine how a public service behaves. Calling them configuration does not remove their administrative effect. It simply makes their history harder to see. Archive thinking asks a better question: what information was made or received while the organisation carried out its task, and what must remain usable so that the task can later be understood.

Archiving is not the same as keeping everything. The National Archives describes choices about which historical versions remain accessible. A draft may not need the same treatment as an adopted decision. A personal field may need a different retention path from a legal basis. The point is to make the choice deliberately and record the reason. Deleting history can be legitimate. Deleting it without knowing whether it is the history of an affected decision is merely a fast way to lose the argument later.

GDPR asks for responsibility, not archaeology

The General Data Protection Regulation does not prescribe a single version-control product for public authorities. It does something more demanding. Article 5(2) places responsibility on the controller and requires the controller to be able to demonstrate compliance with the data protection principles. Article 24 describes responsibility for appropriate technical and organisational measures. Article 30 requires records of processing activities in the circumstances set out by the Regulation. Together, these provisions make accountability a property an organisation must be able to show, not only a belief it can state.

A record of processing activities is not a complete decision history. It normally describes a processing operation at an organisational level: its purpose, categories of data and people, recipients, retention and security measures. That record answers a different question from which source value was active in an individual case. But the accountability principle creates a clear reason to preserve the relationships that let the organisation demonstrate what it did. Version history is one way to make those relationships inspectable. It supports the legal duty; it does not magically satisfy it.

Esta distinção evita dois erros comuns. O primeiro é tratar um registo como se fosse uma repetição de todas as decisões. Uma página que afirma que a organização processa dados de endereços para a prestação de serviços não pode provar qual endereço foi utilizado para uma notificação específica. O segundo é tratar registos detalhados como se fossem automaticamente provas legais. Um registo pode conter mais dados pessoais do que o necessário para a finalidade, ser conservado durante mais tempo do que o justificado, ou ser acessível a pessoas sem necessidade de o conhecer. A responsabilização inclui a minimização e a segurança. A memória deve ser concebida com uma saída, bem como uma entrada.

Para as equipas que criam ou adquirem sistemas com capacidades de IA, a implicação prática é definir o menor registo duradouro que possa responder à questão previsível. Pode ser uma referência a uma versão de origem, em vez de uma duplicação de toda a origem. Pode ser um pacote de provas selado com acesso restrito. Pode ser um identificador de regra e um intervalo de vigência, juntamente com um resultado. O teste legal não é se a organização recolheu uma quantidade impressionante de telemetria. É se a organização consegue demonstrar um processamento lícito, justo e limitado à finalidade, sem transformar cada pessoa num rasto permanente de exaustão de dados.

O Regulamento IA transforma a memória do ciclo de vida num requisito

O Regulamento IA é mais explícito sobre a memória técnica de determinados sistemas. O artigo 11.º exige que a documentação técnica de um sistema de IA de alto risco seja preparada antes de o sistema ser colocado no mercado ou colocado em serviço, mantida atualizada e suficientemente clara para que as autoridades e os organismos notificados avaliem a conformidade. O artigo 12.º exige que os sistemas de alto risco permitam tecnicamente o registo automático de eventos ao longo da vida do sistema, com registos relevantes para o risco, a monitorização pós-comercialização e o funcionamento. São obrigações de ciclo de vida, não um pedido de um folheto para o dia do lançamento.

O considerando do Regulamento sobre a rastreabilidade explica o porquê. São necessárias informações sobre a forma como um sistema de alto risco foi desenvolvido e funciona ao longo da sua vida para avaliar a conformidade e monitorizar o funcionamento. Espera-se que a documentação abranja características, capacidades, limitações, algoritmos, dados, formação, testes, validação e gestão de riscos. As palavras mantida atualizada fazem um trabalho importante. Um documento que descrevia um sistema anterior, mas que nunca foi alterado, é prova de um estado anterior, não prova de que o estado atual permanece em conformidade.

O anexo IV torna concreta a relação entre versões. A descrição geral de um sistema de alto risco inclui o seu nome e versão, com a sua relação com versões anteriores, bem como as versões relevantes de software ou firmware e os requisitos de atualização. Um número de versão sem a relação é um rótulo. A relação permite que um revisor compreenda a continuidade, a mudança e o âmbito. É a diferença entre dizer que esta é a versão quatro e mostrar quais as premissas que a versão quatro herdou, substituiu ou tornou obsoletas.

Nada disto significa que todas as decisões públicas sejam automaticamente um caso de IA de alto risco ao abrigo do Regulamento. A classificação depende do sistema, da finalidade e da utilização descritas pelo Regulamento. Significa que as organizações devem deixar de tratar a rastreabilidade como um conforto opcional para as equipas mais sofisticadas do ponto de vista técnico. Quando a lei exige que um sistema deixe um histórico operacional utilizável, a questão do design torna-se prática: que eventos, versões e autoridades deve o registo ligar para que uma revisão posterior possa saber o que aconteceu sem pedir à equipa original que se lembre disso.

A decisão pública é uma pilha

Imagine abrir um processo de há dois anos. O resultado está lá. O registo da pessoa está agora mais completo. A página de política foi revista. O modelo foi atualizado duas vezes. A interface tem um novo painel de revisão. O fornecedor alterou o seu acordo de alojamento. Um gestor diz que a equipa sempre fez uma verificação humana. Cada afirmação pode estar correta hoje. Nenhuma delas lhe diz como era o processo quando a decisão cruzou a fronteira entre recomendação e ação.

Um registo defensável trata a decisão como uma pilha. Na base está o estado da fonte, com identidade, validade, proveniência e condições de acesso. Acima estão as regras e limiares aplicáveis. O estado do sistema identifica o software, o modelo, a instrução, o índice e a configuração. O estado do fluxo de trabalho captura o encaminhamento, as permissões, a posição na fila e o papel humano. O recibo de decisão liga o resultado, a razão, a notificação, a ação e a referência a jusante. Uma correção posterior pode então percorrer a pilha para descobrir quais decisões dependiam da camada alterada.

A pilha não precisa de expor todos os detalhes internos a todos os leitores. Um aviso público pode ser conciso, enquanto um revisor autorizado pode inspecionar um registo mais profundo. O que importa é que a instituição não tenha colapsado significados distintos num único campo chamado versão. Uma versão da fonte não é uma versão da política. Uma versão do modelo não é uma versão do fluxo de trabalho. O papel de um revisor não é uma razão de aprovação. Mantê-los separados permite que a organização partilhe a explicação certa com a pessoa certa e evite inventar uma história única que nenhum sistema registou de facto.

Isto também clarifica a propriedade. O responsável pelos dados é dono do percurso de correção da fonte. O responsável pela política é dono da regra em vigor. A equipa técnica é dona do artefacto de lançamento. A equipa operacional é dona do fluxo de trabalho e da formação. Quem decide é dono do ato. A governação liga os registos e define os limites de retenção e acesso. Se ninguém puder dizer quem é dono de uma camada, o histórico de versões será uma lista de rótulos sem uma voz responsável.

O tempo tem mais do que um relógio

As datas são necessárias e muitas vezes enganadoras. Uma política pode ser publicada na segunda-feira, entrar em vigor na sexta-feira e chegar a um determinado serviço na terça-feira seguinte. Uma fonte pode ser recolhida às 09:10, corrigida às 11:00 e reprocessada às 14:00. Um pacote de modelo pode ser aprovado num ambiente e implementado noutro. Um revisor pode abrir um processo antes de uma alteração e submetê-lo depois. Um único carimbo de data e hora não pode transportar todos esses significados sem ajuda.

Um bom histórico distingue pelo menos o momento em que um artefacto foi criado, o momento em que entrou em vigor, o momento em que foi observado ou capturado e o momento em que foi utilizado. Pode também precisar do momento em que foi retirado, corrigido ou descoberto como errado. Estas não são distinções pedantes. Um recurso pode depender de saber se um novo limiar se aplicava a um pedido submetido antes da sua data de entrada em vigor, ou se uma correção deve alterar um aviso já emitido. A resposta pertence à lei e à política da instituição, mas os factos exigem relógios que possam mostrar a sequência.

A validade também tem âmbito. Um fluxo de trabalho regional pode ter uma versão em Roterdão e outra em Lyon. Um pacote de idiomas pode mudar num calendário diferente do de uma regra de decisão. Um modelo pode estar disponível para redação, mas proibido para ação final. Um registo que diz ativo sem dizer onde e para que fim é um mapa que omite os sinais de trânsito. O âmbito transforma uma versão genérica num facto utilizável.

Os relógios devem ser compreensíveis para pessoas que não mantêm o pipeline de implementação. Uma pessoa afetada não deve precisar de aprender um sistema de compilação para perguntar qual regra foi aplicada. O registo técnico pode reter identificadores precisos enquanto a explicação pública os traduz numa data efetiva, numa política nomeada e numa declaração clara do que a organização ainda pode fazer. Precisão e linguagem simples não são opostas. A precisão dá à linguagem simples algo sólido para dizer.

Replay é um método, não um botão

A palavra replay cria uma expectativa perigosa. Parece que a organização pode carregar num botão e ver o passado correr novamente, exatamente como aconteceu. Por vezes, um sistema limitado consegue fazer algo próximo disso. Mais frequentemente, replay significa reconstruir o estado relevante a partir de entradas registadas, versões, regras, permissões e ações, e depois mostrar onde a reconstrução é exata e onde permanece incerteza.

Um registo de replay genuíno separa o que foi observado do que está a ser reconstruído. A entrada original pode estar selada. Os identificadores da regra e do modelo podem ser conhecidos. A resposta exata do serviço externo pode não ter sido retida. Uma correção posterior da fonte pode estar disponível, mas não ser válida na altura. Uma revisão humana pode ter um resultado assinado, mas não uma gravação completa do ecrã. O replay não deve preencher estas lacunas com um novo parágrafo confiante. Deve assinalá-las. Uma história parcial honesta é mais útil do que uma ficção completa.

Replay também não é o mesmo que regeneração. Pedir ao sistema atual para responder à pergunta antiga pode demonstrar como o sistema se comporta hoje. Não prova o que fez então. O novo resultado pode usar um modelo, fonte, política, prompt, decisão de encaminhamento ou representação de linguagem diferentes. Pode ser valioso como comparação, desde que o registo diga que é uma comparação. Uma análise posterior não deve fazer-se passar por uma razão contemporânea.

Replay é uma janela de evidência. Mostra o que pode ser recuperado, o que mudou e onde uma correção ainda pode viajar.

Um histórico com replay altera a qualidade de um recurso. A pergunta deixa de ser por que razão a organização acredita que isto aconteceu e passa a ser quais partes do histórico podemos verificar. Esse é um ponto de partida mais saudável. Dá à instituição permissão para dizer que o registo está completo na regra e no resultado, mas incompleto numa resposta externa. Dá ao revisor uma forma de decidir se a parte em falta é material. Dá aos engenheiros um defeito preciso para corrigir, em vez de um pedido vago de mais transparência.

Transparência tem limites, não desculpas

O direito a saber o que mudou não é um direito a receber todos os registos internos na sua forma bruta. Os organismos públicos continuam a ter o dever de proteger dados pessoais, informações sensíveis em matéria de segurança, informações comerciais confidenciais e a integridade das investigações. Um histórico detalhado pode expor dados de outra pessoa ou facilitar a evasão de um controlo. Uma explicação pública útil pode, por isso, ser um registo em camadas: um relato simples da regra e do calendário aplicáveis, uma referência a um pacote de provas auditável e um percurso controlado para uma inspeção mais aprofundada.

A estratificação só funciona quando o registo mais profundo existe. A expurgação não substitui a conservação do original. Se uma instituição publica um resumo e elimina o material que permitiria a um revisor autorizado testá-lo, o resumo torna-se uma afirmação permanente. O público pode não ter direito a todos os anexos, mas alguém com um papel legítimo deve poder examinar a base. O controlo de acessos pode limitar quem vê um registo. Não pode tornar seguro um registo inexistente.

Existe uma segunda fronteira em torno do significado de transparência. Uma etiqueta de versão não é uma explicação. Mostrar que um modelo mudou não diz a uma pessoa afetada se a alteração poderia ter mudado o resultado. Mostrar uma diferença de política não lhe diz qual parte foi aplicada. Boas explicações ligam a alteração ao ato, indicam o que foi utilizado e referem qual é a solução disponível. O objetivo não é fazer a instituição parecer tecnicamente competente. É permitir que uma pessoa compreenda a sua situação.

Os registos públicos podem ajudar, tornando visíveis estados importantes do sistema antes de alguém ser obrigado a perguntar. O Regulamento IA inclui deveres de registo e documentação em contextos definidos, enquanto a prática arquivística nacional trata o acesso e a usabilidade futura como parte da gestão de documentos. Estes mecanismos não substituem o histórico ao nível do caso. São o mapa envolvente. Um mapa é valioso, mas não deve ser confundido com o caminho que uma determinada pessoa percorreu.

O inquérito chega depois de a interface ter mudado

O inquérito de 2024 do Provedor de Justiça Europeu sobre a utilização de IA pela Comissão é um exemplo útil da questão que as instituições enfrentarão com mais frequência. A descrição pública pergunta como a Comissão decide utilizar IA, que tarefas são automatizadas, como é tomada a decisão de utilizar IA e como é mantida a responsabilização. Não parte do princípio de que um resultado algorítmico é toda a decisão. Pergunta sobre a escolha administrativa em torno do sistema.

Essa escolha também tem um histórico. Uma instituição pode começar com um ensaio, definir um objetivo, restringir um papel, mudar uma fonte, alargar um volume de trabalho, alterar um percurso de revisão e publicar uma explicação posterior. Se o registo contiver apenas a política atual e a interface atual, um revisor terá de inferir a fronteira anterior. A instituição pode estar a agir de boa-fé e, ainda assim, não conseguir mostrar o que sabia, aprovava ou permitia na altura. A boa-fé é uma qualidade valiosa. Não é uma máquina do tempo.

Os inquéritos mostram também porque é que a gestão de registos deve incluir canais informais. As decisões podem ser moldadas por documentos de trabalho, mensagens, sistemas de acompanhamento de problemas, revisões de configuração e conversas que nunca se tornam uma política formal. Nem todas as frases precisam de conservação permanente. A organização precisa de uma regra para identificar quais as trocas que veiculam um ato ou compromisso institucional, e de uma forma de preservar esse material quando a sua relevância se torna clara. Caso contrário, o histórico começa no primeiro documento polido, depois de a escolha importante já ter acontecido.

A resposta não é transformar a administração pública num arquivo de vigilância dos seus próprios funcionários. É tornar explícito o estado consequente do trabalho. Uma decisão deve ter um responsável, uma razão, um âmbito, uma data de eficácia e um registo da alteração que a tornou diferente. A discussão informal pode continuar a ser discussão. Quando altera autoridade, dados, política ou ação, o resultado relevante pertence ao registo institucional.

AI torna as explicações antigas especialmente frágeis

As explicações geradas criam um risco particular porque são suficientemente fluentes para esconder a sua temporalidade. Um sistema pode produzir um relato sensato de uma decisão antiga usando o modelo e a política atuais. O relato pode não conter nenhuma frase obviamente falsa. Ainda assim, pode ser falso como registo, porque a explicação não existia quando a decisão foi tomada e não foi derivada do estado que a produziu.

A separação mais segura é entre a evidência contemporânea e a interpretação posterior. O registo contemporâneo diz o que o sistema recebeu, que versão atuou, que resultado foi produzido, o que a pessoa fez e que aviso foi enviado. Um analista posterior pode acrescentar uma reconstrução, um contrafactual, uma comparação com o comportamento atual ou uma avaliação sobre se a regra deveria ter sido diferente. Esses acréscimos são valiosos quando rotulados como trabalho posterior. Tornam-se perigosos quando o rótulo desaparece.

As pontuações de confiança têm o mesmo problema. Um número sem a sua calibração, população, limiar e finalidade não se explica a si próprio. O número pode ter sido útil para classificar a atenção e nunca ter sido autorizado para ação final. Pode ter sido mostrado a um revisor ou escondido atrás de uma interface. Pode ter sido recalibrado depois do evento. Preservar a pontuação enquanto se perdem as condições preserva a forma da evidência e remove o seu significado.

É por isso que o histórico de versões deve incluir modelos de explicação e apresentações de fontes quando estes influenciam uma decisão humana. A redação não é meramente uma camada de comunicação se diz a um revisor por que razão o sistema recomenda uma ação. A ordem da evidência pode importar. A ausência de um aviso pode importar. O conjunto de botões disponíveis pode importar. Uma decisão pública é afetada pelo que as pessoas podem ver e fazer, não apenas pelo cálculo oculto.

A correção de dados é onde o histórico mostra o seu valor

Todo o sistema administrativo acaba por aprender que um registo de origem pode estar errado. Um endereço é corrigido, uma categoria é reclassificada, um pagamento é revertido, uma medição é recalculada, ou uma pessoa fornece informação em falta. A correção pode melhorar o registo atual sem corrigir automaticamente as decisões que dependeram do valor anterior. Essa segunda tarefa exige uma ligação entre o histórico da origem e as decisões afetadas.

Sem essa ligação, uma instituição enfrenta duas más escolhas. Pode rever tudo, o que é caro e pode expor pessoas que nunca foram afetadas. Ou pode não rever nada, o que deixa o erro conhecido no lugar para qualquer pessoa cuja decisão dele dependeu. As referências com versões permitem uma questão mais restrita: que decisões consumiram este estado, sob que regra e com que consequência. A resposta pode orientar uma revisão proporcionada.

A mesma lógica aplica-se à mudança legal e política. Uma nova regra pode ser correta para novos casos sem tornar errado cada resultado antigo. Uma interpretação judicial pode exigir um novo olhar sobre decisões tomadas sob um entendimento anterior. Um processo de correção precisa de saber quando a regra antiga estava em vigor, que casos abrangia e se o remédio é reabertura, notificação, compensação, explicação ou nenhuma ação. O histórico transforma uma questão moral numa questão operacionalmente respondível sem reduzir a questão moral a uma consulta.

A correção também deve deixar o seu próprio rasto. A organização deve registar o que foi encontrado, que casos foram considerados, que ação foi tomada e por que razão alguns casos ficaram fora do âmbito. Esse registo protege a pessoa afetada e a instituição. Impede que a mesma questão seja silenciosamente redescoberta por cada novo revisor. Uma correção sem registo é um pedido de desculpas que não consegue lembrar-se de quem ajudou.

A revisão humana também precisa de uma versão

A supervisão humana é muitas vezes descrita como se a presença de uma pessoa tornasse a decisão estável. Não torna. O revisor age num contexto: um conjunto de documentos, um ecrã, uma fila, um prazo, uma função, uma nota de política, um alerta e uma lista de ações disponíveis. Se o contexto mudar, o significado da aprovação do revisor pode mudar com ele. Registar apenas um nome e um carimbo de data e hora não respeita nem o revisor nem a pessoa afetada.

Registar com versões a revisão humana não exige registar todos os pensamentos. Exige contexto suficiente para mostrar a autoridade e as provas do ato. Quais materiais foram apresentados. Quais foram excluídos ou indisponíveis. A saída era uma sugestão, um requisito ou um gatilho. Podia o revisor anulá-la. Estava visível um caminho de escalada. Acrescentou o revisor um motivo. A ação foi aplicada ou apenas redigida. Estes campos criam um registo de julgamento sem fingir que o julgamento é um número legível por máquina.

A distinção protege os trabalhadores. Se uma organização espera que os revisores assumam um resultado, não deve depois julgá-los com base numa interface diferente e num conjunto de provas diferente. Protege também os cidadãos. Uma pessoa que contesta uma decisão não deve ouvir que um humano anónimo esteve no circuito e depois descobrir que o humano só podia clicar em aprovar. A supervisão é significativa quando o registo mostra o que a pessoa podia fazer e o que aconteceu quando discordou.

Há também um benefício cultural. Quando a discordância é registada como parte normal do fluxo de trabalho, torna-se uma fonte de aprendizagem em vez de um sinal de deslealdade. As organizações podem examinar se as anulações se concentram em torno de um problema de dados, de uma ambiguidade de política ou de uma pressão da interface. Podem melhorar o sistema sem culpar as pessoas que notaram que o sistema estava errado. Um histórico dá à dissidência um lugar para onde ir além do corredor.

Memória sem acumulação

Quando uma organização compreende a necessidade de histórico, a tentação é reter tudo. Cada prompt, captura de ecrã, valor de funcionalidade, mensagem, gravação, exportação e ficheiro intermédio é guardado para sempre, por precaução. Isso não é responsabilização. É um arquivo que se esqueceu de por que existe. Aumenta a exposição à privacidade, eleva os custos de segurança e torna a prova relevante mais difícil de encontrar.

A retenção deve seguir a consequência, a necessidade legal e a possibilidade de reparação. Uma decisão de alto impacto pode exigir um pacote de provas mais completo e um período protegido mais longo. Um rascunho de baixo risco pode precisar de um recibo compacto. O conteúdo sensível pode ser referenciado por um identificador e mantido num sistema restrito. Uma representação derivada pode expirar enquanto o facto de ter existido, e o motivo da eliminação, permanece. O design deve indicar o que é retido, quem pode aceder, como é corrigido e quando é destruído.

A memória seletiva é mais fácil de defender quando o registo é estruturado. Identificadores estáveis podem ligar uma decisão a uma fonte sem copiar dados pessoais para cada registo. Intervalos de vigência podem impedir que um valor atual seja lido como o valor passado. Códigos de motivo podem tornar uma correção detetável sem preservar uma conversa privada. Uma verificação de integridade pode mostrar que um registo não mudou sem expor o seu conteúdo a todos os que perguntam. Uma boa proteção de dados parece muitas vezes uma melhor engenharia porque ambas as disciplinas desgostam de ambiguidade.

Não existe um período de retenção universal escondido na expressão histórico de versões. O período depende da tarefa, do setor, da via de recurso, do dever contratual e da lei. O que deve ser universal é a exigência de decidir deliberadamente. Se a organização não consegue indicar por que um componente deve ser mantido, pode não compreender o seu papel na decisão. Se não consegue indicar por que um componente pode ser eliminado, pode estar a guardar um risco em vez de provas.

Conceber o histórico sem criar teatro

Uma implementação útil começa por perguntas em vez de campos. Que decisão pode vir a ser contestada. Que versões podem alterar o seu significado. Quem precisa de as inspecionar. Qual é o momento mais cedo em que o registo pode ser selado. Qual é o conjunto mínimo de provas que permite a um revisor testar a alegação relevante. Que alterações devem desencadear uma nova revisão. Que eventos têm de ser visíveis a uma pessoa e quais são pormenores operacionais.

As respostas conduzem normalmente a alguns padrões duradouros. Atribua uma identidade estável a cada política, modelo, definição de origem e versão de fluxo de trabalho. Registe os intervalos de vigência separadamente dos tempos de publicação e de implementação. Ligue a decisão às identidades exatas utilizadas, e não ao que está em vigor quando alguém abre o processo. Preserve um relato legível por humanos juntamente com referências legíveis por máquina. Faça com que as alterações acrescentem um histórico ou criem um novo estado imutável. Se uma correção substituir um valor anterior, mantenha a relação entre os dois.

Teste o histórico como uma funcionalidade operacional. Pegue numa decisão conhecida e peça a um engenheiro, a um responsável pela política e a um revisor independente que a reconstituam. Chegam ao mesmo estado. Conseguem distinguir o que está confirmado do que está em falta. Conseguem identificar quem tinha autoridade. Conseguem encontrar as decisões afetadas por uma correção de origem. Conseguem explicar por que motivo uma reprodução atual difere sem considerar o passado errado por defeito. Um sistema que passa apenas num teste de esquema tem um registo arrumado. Um sistema que passa num teste de revisão tem hipótese de ser responsabilizável.

Por fim, ensaie a mudança. Substitua uma regra num ambiente de teste, atualize uma definição de origem, implemente um pacote de modelo, remova uma permissão e corrija um registo. Depois inspecione o histórico. Mostra a transição, o seu âmbito e o seu responsável. O estado antigo ainda pode ser lido por um revisor autorizado. O ponto de decisão a jusante aponta para a versão certa. Se a resposta for não, o sistema está a contar com um incidente futuro para lhe ensinar controlo de versões. Incidentes futuros são professores caros.

O que um registo público de alterações não lhe pode dizer

Um registo público de alterações pode dizer que um limiar foi revisto, que um modelo foi atualizado ou que um fluxo de trabalho foi melhorado. Não pode dizer a uma pessoa se a alteração afetou o seu processo, a menos que o registo de decisão estabeleça essa ligação. Pode dizer quando uma versão ficou disponível. Não pode dizer se uma região a recebeu mais tarde. Pode dizer que um erro foi corrigido. Não pode dizer que resultados passados foram reexaminados. Os registos de alterações são úteis precisamente porque são seletivos. As provas são úteis quando a sua regra de seleção é visível.

A distinção também é importante para a supervisão democrática. Um organismo público pode publicar um registo de modelos e uma descrição geral da finalidade. O parlamento, um tribunal, um auditor ou uma pessoa que exerça um direito podem ainda precisar de saber o que aconteceu numa data específica. Um registo dá à sociedade uma visão do panorama. O histórico de decisões dá a uma pessoa um caminho através dele. Ambos são necessários. O primeiro é informação pública. O segundo é memória institucional que pode responder por um ato.

Há um perigo silencioso em apresentar um registo de alterações como responsabilização, porque recompensa a perspetiva de quem publica. O publicador escolhe o que conta como material, usa o vocabulário atual e descreve o efeito pretendido. Uma pessoa afetada pelo sistema começa noutro ponto. Pergunta que regra afetou o meu pedido, que provas foram consideradas, se o papel do sistema estava dentro da sua autoridade e o que posso fazer agora. O registo tem de ser capaz de responder a essa pergunta mesmo quando a resposta é inconveniente.

Um bom registo público de alterações tem, por isso, duas direções. Explica as alterações ao público em linguagem simples e dá aos revisores autorizados um caminho para a prova ao nível do caso. Indica o que a alteração não mudou. Assinala correções posteriores. Liga aos responsáveis pela política, pelo sistema e pela operação. Diz quando um registo está incompleto. A confiança não se cria fingindo que toda a história é contínua. Cria-se quando as costuras são visíveis e há alguém responsável por elas.

A nossa pequena participação na questão

Na Dweve, voltamos sempre a esta distinção porque o nosso próprio trabalho no Ledger trata a história operacional como um registo tipificado e reproduzível, e não como uma pilha de mensagens pesquisáveis. O nosso trabalho sobre registos operacionais segue a mesma pergunta: o que é retido como história e o que é derivado como vista atual. Essas são escolhas de engenharia, não prova de que uma instituição pública ou um fornecedor cumpriu as suas obrigações. A lição mais ampla pertence a todos os que constroem sistemas responsáveis: mantenham o registo próximo do acontecimento, mantenham honesto o seu âmbito e não deixem que uma vista atual se faça passar silenciosamente pelo passado.

Isto é um pequeno parágrafo num argumento muito maior. O argumento não depende de um produto da Dweve. Já está presente na gestão de documentos europeia, na responsabilização pela proteção de dados e nos requisitos do ciclo de vida do Regulamento IA. Interessamo-nos pelo problema porque o software torna fácil esquecer e as decisões públicas tornam o esquecimento consequente. A resposta certa não é acrescentar o nosso logótipo à palavra transparência. É tornar a história inspecionável, limitada e útil para quem tem de viver com o resultado.

A pergunta de um cidadão está normalmente no passado

Porque foi tomada esta decisão. Que regra se aplicou. Que informação utilizaram. Houve uma pessoa a rever. O que mudou depois. Estas são perguntas no passado. São feitas por cidadãos, doentes, trabalhadores, estudantes, clientes, jornalistas, auditores, tribunais e pelo pessoal que herda um sistema que não desenhou. Um painel atual pode mostrar que o sistema está saudável. Não pode responder pela decisão de ontem se ontem foi sobrescrito.

A resposta não exige que uma instituição preserve todos os detalhes para sempre ou publique todos os registos internos. Exige que a instituição saiba quais os factos que tornam a decisão inteligível, que os mantenha numa forma que possa ser verificada e que diga claramente quando um facto não pode ser recuperado. Essa é a promessa modesta do histórico de versões. Não torna uma decisão correta. Torna uma decisão respondível.

A prática arquivística europeia tem dito isto em linguagem corrente: informações importantes podem ter versões históricas, e a informação digital continua a ser informação onde quer que esteja armazenada. A lei europeia de proteção de dados diz que a responsabilidade inclui ser capaz de demonstrar conformidade. O Regulamento IA torna a documentação técnica e o registo do ciclo de vida parte das obrigações para sistemas de alto risco definidos. As perguntas do Provedor de Justiça Europeu sobre a IA no setor público apontam na mesma direção. As instituições serão julgadas não só pelo que implementam, mas pelo que conseguem mostrar sobre a escolha.

Por isso, mantenham o registo de alterações. Escrevam a nota de lançamento. Publiquem o registo. Depois construam o registo menos glamoroso por baixo: aquele que sabe que fonte, regra, sistema, fluxo de trabalho e autoridade estavam ativos quando o caso de uma pessoa passou de possibilidade a decisão. Se a organização conseguir mostrar o que mudou, também consegue mostrar o que não mudou, o que foi aprendido e o que ainda pode ser reparado. Isso não é nostalgia arquivística. É a memória mínima exigida para que o poder público continue a ser responsável.

Fontes