Trilhos de auditoria criptográficos: evidência que um regulador consegue inspecionar
Pergunte a uma equipa como vai explicar a decisão de um agente depois do facto, e a resposta habitual é "registamos tudo". Os registos parecem responsabilização. Há um apontamento com data e hora, vai para um repositório central, e quando alguém pergunta o que aconteceu basta ir lá ler. Para muitos sistemas, isso chega genuinamente.
Só que um registo comum não sobrevive ao único momento para que existe: um regulador, um auditor ou um tribunal a dizer "prove que este registo não foi alterado depois da decisão, e prove que não falta nada". Um registo padrão não consegue responder. É escrevível, por isso as entradas podem ser mudadas. É muitas vezes escrito depois da ação, por isso pode atrasar-se ou perder-se. E não tem estrutura interna que revele adulteração, por isso uma entrada apagada ou editada não deixa rasto. Quando o que está em jogo é uma ação de fiscalização, "confiem nos nossos registos" não é evidência. É uma afirmação, e o ponto todo do exercício é que a sua afirmação é exatamente o que está em causa.
O reenquadramento é deixar de pensar em registo e começar a pensar em evidência: um registo construído para que a sua própria integridade seja demonstrável, produzido de forma a tornar "alterámos depois" ou "faltou uma entrada" detetável em vez de negável. É um alvo de engenharia diferente, e tem uma forma bem conhecida.
Append-only e encadeado por hash: a adulteração torna-se visível
Duas propriedades transformam um registo em evidência, e funcionam em conjunto.
A primeira é ser append-only. Os registos podem ser acrescentados mas nunca editados ou apagados no lugar. Não há operação de atualização nem de eliminação, apenas de acrescento. Só isso remove a forma mais comum de um registo perder credibilidade, a edição silenciosa depois do facto, porque a operação que a faria não existe.
A segunda é o encadeamento por hash, e é o que torna o append-only demonstrável em vez de apenas prometido. Cada registo inclui um hash criptográfico do registo anterior, por isso as entradas formam uma cadeia em que cada elo se compromete com o anterior. Organize esses hashes numa estrutura de Merkle, uma árvore em que cada nó é o hash dos seus filhos, e obtém um único hash-raiz que resume toda a história. Mude um campo num registo e o hash dele muda, o que muda todos os hashes acima, o que muda a raiz. A alteração não se consegue esconder. Quem tiver a raiz antiga consegue provar, matematicamente, que a história foi modificada, e consegue prová-lo sem ter de confiar em si.
É essa a passagem de "acreditem no nosso registo" para "verifiquem a nossa evidência". A integridade do registo deixa de assentar na sua palavra ou nos seus controlos de acesso. Assenta em criptografia que uma parte externa consegue verificar de forma independente.
Armazenamento WORM: o suporte impõe o que o software promete
Append-only em software é uma disciplina forte, mas um operador com privilégios suficientes, ou um atacante suficientemente determinado, consegue por vezes chegar por baixo. Para evidência que tem de aguentar escrutínio adversarial, o próprio suporte de armazenamento deve impor a propriedade.
O armazenamento WORM, write-once-read-many, faz exatamente isso. Depois de um registo ser gravado, a camada de armazenamento impede fisicamente que seja sobrescrito ou apagado durante um período de retenção definido, independentemente dos privilégios de quem chama. A garantia deixa de depender apenas de a aplicação se comportar corretamente. É imposta abaixo da aplicação, onde nem um administrador consegue reescrever a história em silêncio. Combine WORM com encadeamento por hash e tem cinto e suspensórios: o suporte recusa deixar o registo mudar, e a criptografia revelaria se o suporte falhasse.
Escrito antes de a decisão se concretizar: sem evidência, não há decisão
Eis a escolha de desenho que separa evidência real de uma reconstituição, e é a que a maioria das equipas faz ao contrário.
A evidência tem de ser escrita antes de a decisão produzir efeito, não depois. Isto inverte a ordem habitual, em que um sistema atua e depois, como efeito secundário, regista o que fez. Nessa ordem habitual, o registo é uma reflexão tardia, e reflexões tardias podem falhar: a ação tem sucesso, a chamada de registo lança uma exceção, e fica com uma decisão sem evidência por trás. Num processo regulado é o pior dos dois mundos: uma consequência no mundo e nenhum registo do porquê.
Por isso a sequência é imposta ao contrário. O sistema monta o registo da decisão e grava-o primeiro no repositório de evidências. Só depois de essa escrita ter sucesso é que a decisão pode produzir efeito. Se o repositório de evidências estiver indisponível, ou a escrita falhar, a decisão não avança. Sem repositório de evidências, não há decisão. O sistema falha fechado: quando não consegue provar o que está prestes a fazer, recusa fazê-lo. Essa única regra garante uma propriedade que os reguladores valorizam profundamente. Nesta arquitetura, não existe ação com consequência sem um registo correspondente e resistente a adulteração, porque o registo é uma pré-condição da ação, e não um subproduto dela.
O que um registo de decisão tem de conter
A integridade não vale nada se o registo estiver vazio de sentido. Um registo à prova de adulteração que diz "decisão tomada: aprovada" só prova que não consegue alterar um registo que não diz nada de útil. Por isso o conteúdo importa tanto como a criptografia. Um registo de decisão apto para inspeção deve captar, no mínimo:
- A decisão e o seu veredicto. O que foi decidido, e sob que resultado explícito (permitir, permitir com condições, negar, ou exigir uma pessoa).
- Os dados de entrada. Os documentos, dados e contexto específicos sobre que a decisão assentou, referenciados para que a base de evidência exata possa ser reconstruída.
- A autoridade. Que identidade de agente atuou, a que nível de autonomia, e sob que versão da política.
- A avaliação da política. Que regras foram aplicadas e o que cada uma devolveu, para que o "porquê" seja explícito e não inferido.
- O raciocínio e a fundamentação. A justificação do agente e as fontes citadas por trás de cada afirmação material.
- A pessoa, quando houve uma. Se a decisão exigiu uma pessoa, quem foi e o que aprovou, fechando o ciclo de responsabilização.
- Tempo e posição na cadeia. Quando aconteceu e onde se situa na cadeia de hashes, para poder ser localizado e verificado.
Um registo com estes campos responde à pergunta que uma inspeção faz mesmo: não apenas "o que decidiu o sistema?", mas "com que fundamento, sob que autoridade, contra que política, e consegue provar que este relato está intacto?".
O artigo 12.º do EU AI Act, e porque é que isto não é opcional
Esta arquitetura não é luxo. Para sistemas de IA de alto risco, está a caminho de ser a base que a lei espera.
O artigo 12.º do EU AI Act exige que os sistemas de IA de alto risco mantenham registos, com registo automático de eventos ao longo da vida do sistema, em grau adequado à sua finalidade, para que o funcionamento do sistema seja rastreável e os seus riscos possam ser monitorizados depois do facto. Leia esse requisito contra um registo comum, editável e de melhor esforço, e a lacuna é óbvia. "Rastreável" e "conservação adequada de registos" não se satisfazem com um repositório cuja integridade não consegue demonstrar e cuja completude não consegue garantir. Evidência append-only, encadeada por hash, assente em WORM e escrita antes de a decisão se concretizar não é uma interpretação mais rígida do que o necessário desse artigo. É uma leitura direta do que "registos em que um supervisor pode confiar" tem de significar quando o sistema é probabilístico e as decisões pesam.
Por isso, a pergunta a levar à próxima revisão não é "estamos a registar os nossos agentes?". Toda a gente regista alguma coisa. É conseguimos entregar a um regulador o registo de qualquer decisão de um agente e provar, sem lhe pedir que confie em nós, que está completo e não foi alterado depois? Se a resposta honesta for não, tem registos. Ainda não tem evidência, e é para a evidência que serve uma inspeção.
Se quiser ver como é um registo de decisão inspecionável num dos seus processos reais, marque uma reunião.