Skip to main content

Requisitos de trilha de auditoria do Regulamento de IA

O que os artigos 12, 19 e 26(6) exigem em matéria de registo, o que o regulamento deixa em aberto e que práticas de engenharia protegem os registos como prova.

Os fornecedores de sistemas de IA de risco elevado devem concebê-los para registarem automaticamente os eventos (registos) durante o ciclo de vida (artigo 12.º). Fornecedores e responsáveis pela implantação (que usam o sistema) conservam os registos sob o seu controlo durante, pelo menos, seis meses. Outra norma pode dispor de outro modo (artigos 19 e 26(6)).

Aplica-se a partir de 2 de dezembro de 2027 (anexo III) e de 2 de agosto de 2028 (anexo I). O artigo 2 enumera exclusões. Os sistemas anteriores só ficam abrangidos após alterações significativas da conceção (artigo 111(2)). As coimas chegam a 15 milhões de EUR ou 3 % do volume de negócios anual mundial, consoante o que for mais elevado (artigo 99(4)). Próximo passo: faça uma lista dos eventos a registar.

O regulamento exige capacidade de registo, conservação e acesso, não um formato de registo

  • Artigo 12(1): o sistema tem de poder registar eventos automaticamente

    Um sistema de IA de risco elevado tem de permitir tecnicamente o registo automático de eventos (registos) ao longo do seu ciclo de vida.

  • Artigo 12(2): os registos servem três fins

    O registo tem de permitir anotar eventos relevantes para identificar situações de risco (artigo 79(1)) ou modificações substanciais, para a monitorização pós-comercialização (artigo 72) e para a vigilância do funcionamento pelos responsáveis pela implantação (artigo 26(5)). O regulamento não enumera tipos de eventos.

  • Artigo 12(3): a identificação biométrica à distância tem um mínimo

    Os sistemas de identificação biométrica à distância (anexo III, ponto 1, alínea a)) têm de registar, no mínimo, o período de cada utilização, a base de dados de referência consultada, os dados de entrada que conduziram a uma correspondência e as pessoas que verificaram o resultado.

  • Artigo 19(1): os fornecedores conservam os registos durante, pelo menos, seis meses

    Os fornecedores conservam os registos gerados automaticamente, na medida em que estejam sob o seu controlo. O período é adequado à finalidade prevista e de, pelo menos, seis meses, salvo disposição em contrário do direito da União, em especial sobre proteção de dados pessoais, ou do direito nacional. Os fornecedores que são instituições financeiras conservam os registos como parte da documentação prevista no direito dos serviços financeiros (artigo 19(2)).

  • Artigo 26(6): os responsáveis pela implantação conservam os registos durante, pelo menos, seis meses

    Um responsável pela implantação é uma pessoa singular ou coletiva, autoridade pública, agência ou outro organismo que utiliza o sistema sob a sua própria autoridade (artigo 3, ponto 4). Os responsáveis pela implantação conservam os registos gerados pelo sistema, na medida em que estejam sob o seu controlo, durante um período adequado à finalidade prevista e de, pelo menos, seis meses, salvo disposição em contrário do direito da União ou nacional. Os que são instituições financeiras conservam os registos como parte da documentação mantida ao abrigo do direito da União sobre serviços financeiros e governação interna.

  • Artigo 21(2): as autoridades podem pedir acesso aos registos

    A pedido fundamentado de uma autoridade competente, os fornecedores dão acesso aos registos gerados automaticamente, na medida em que estejam sob o seu controlo.

  • Não consta do regulamento: formato de registo, imutabilidade, cadeias de hash, região de armazenamento

    Os artigos 12, 19 e 26(6) não indicam nenhum formato de registo, armazenamento de escrita única, cadeia de hash nem região de armazenamento. As palavras «imutável», «adulteração» e «hash» não ocorrem no regulamento consolidado de 27 de julho de 2026. Tais medidas protegem os registos como prova; são uma opção de conceção sua.

Práticas de engenharia que protegem os registos como prova (as nossas recomendações)

O regulamento fala de registos, não de trilhas de auditoria. Aqui, uma trilha de auditoria são registos conservados como prova. Estas práticas servem os objetivos dos artigos 12 e 19; o regulamento não as exige.

  • Eventos estruturados

    Escreva cada evento em JSON com sempre os mesmos campos, para o poder consultar. O exemplo abaixo é um esquema possível.

Evento de exemplo (esquema ilustrativo, não imposto pelo regulamento)

{
  "event_type": "AI_DECISION",
  "timestamp": "2026-10-22T14:22:33.456Z",
  "trace_id": "abc-123-def-456",
  "system_id": "credit-scoring-v2",
  "actor_id": "user-789",
  "metadata": {
    "model_version": "v2.3.1",
    "input_hash": "sha256:a1b2c3...",
    "decision": "refer_to_human"
  }
}

  • Apenas acrescentar, armazenamento separado

    Guarde os registos onde ninguém os possa alterar depois, por exemplo num armazenamento de objetos de escrita única, separado da base de dados da aplicação. Os registos guardados na base de dados da aplicação podem ser alterados ou apagados pelos seus administradores.

  • Verificações de integridade

    Encadeie as entradas por hash ou bloqueie os objetos guardados, e verifique-os periodicamente. Assim pode demonstrar que os registos guardados não foram alterados.

  • Identificadores de rastreio

    Passe um identificador de rastreio por cada serviço e coloque-o em cada entrada. Assim pode seguir um único pedido por toda a cadeia de IA.

  • Identificadores pseudonimizados

    Registe identificadores opacos e metadados do evento, não nomes nem endereços de e-mail, quando a finalidade o permitir. Que dados pessoais um registo pode conter é uma questão de RGPD para o seu encarregado da proteção de dados ou o seu advogado.

  • Escritas sem bloqueio

    Envie os eventos para uma fila e tente de novo em caso de falha, para que uma escrita de registo falhada não pare a aplicação.

  • Consulta e exportação

    Permita filtrar os registos por data, tipo de evento e sistema. Assim pode responder a um pedido fundamentado de uma autoridade ao abrigo do artigo 21(2) e fazer a sua própria monitorização.

O que o Scanara verifica e o que não verifica

As regras de código do Scanara assinalam operações de IA sem padrões de registo reconhecíveis. As verificações são análise estática baseada em regras que deteta padrões padrão de frameworks de ML; a fiabilidade varia consoante o nível da linguagem de programação. O Scanara mantém também um registo de escrita única das ações na plataforma, e pode repetir as análises a pedido.

O Scanara não observa o seu sistema em funcionamento, não verifica o conteúdo nem a integridade dos seus registos e não demonstra que o artigo 12 é cumprido. Uma análise bem-sucedida não prova a conformidade, e a decisão continua a ser sua.

Lista de verificação da trilha de auditoria: primeiro o que o regulamento exige, depois as boas práticas

  • Obrigatório (artigo 12(1)): o sistema permite tecnicamente o registo automático de eventos ao longo do seu ciclo de vida.
  • Obrigatório (artigo 12(2)): o registo abrange eventos relevantes para situações de risco e modificações substanciais, monitorização pós-comercialização e vigilância pelo responsável pela implantação.
  • Obrigatório (artigo 12(3)): os sistemas de identificação biométrica à distância registam o conteúdo mínimo.
  • Obrigatório (artigos 19(1) e 26(6)): os registos sob o seu controlo são conservados durante, pelo menos, seis meses, salvo disposição em contrário de outra norma.
  • Obrigatório (artigo 21(2)): pode dar a uma autoridade acesso aos registos a pedido fundamentado.
  • Boa prática: os eventos seguem um esquema JSON fixo com carimbo de data/hora, tipo de evento, ID do sistema e identificador de rastreio.
  • Boa prática: o armazenamento de registos é apenas de acrescento e está separado da base de dados da aplicação.
  • Boa prática: as escritas de registos não bloqueiam a aplicação.
  • Boa prática: os registos contêm identificadores pseudonimizados, não dados pessoais em bruto, quando a finalidade o permitir.
  • Boa prática: a integridade dos registos guardados é verificada periodicamente.

Exclusões, sistemas mais antigos e limites das coimas

O regulamento não se aplica a sistemas de IA usados exclusivamente para fins militares, de defesa ou de segurança nacional (artigo 2(3)). Não se aplica a sistemas de IA desenvolvidos e colocados em serviço especificamente e com o único objetivo de investigação e desenvolvimento científicos (artigo 2(6)), nem à investigação, aos testes ou ao desenvolvimento antes da colocação no mercado ou em serviço, exceto os testes em condições reais (artigo 2(8)). Os sistemas com licenças livres e de código aberto estão excluídos, salvo se forem colocados no mercado ou em serviço como sistemas de risco elevado ou se enquadrarem no artigo 5 ou 50 (artigo 2(12)). As pessoas singulares que usam um sistema numa atividade puramente pessoal e não profissional não estão vinculadas como responsáveis pela implantação (artigo 2(10)). Para os sistemas de risco elevado ligados a produtos abrangidos pela legislação do anexo I, secção B, como veículos a motor, aviação, caminhos de ferro, equipamentos marítimos, veículos agrícolas e máquinas, aplicam-se apenas o artigo 6(1), o artigo 60a e os artigos 102 a 112. Os artigos 57 a 59 aplicam-se apenas na medida em que essa legislação integre os requisitos (artigo 2(2)).

Os sistemas de risco elevado colocados no mercado ou em serviço antes da data de aplicação só ficam abrangidos após alterações significativas da conceção. Em qualquer caso, os fornecedores e os responsáveis pela implantação de sistemas de IA de risco elevado destinados a ser utilizados por autoridades públicas devem tomar as medidas necessárias para cumprir até 2 de agosto de 2030 (artigo 111(2)).

Para as PME, cada coima chega, no máximo, à percentagem ou ao montante mais baixo (artigo 99(6)). Para as pequenas empresas de média capitalização (artigo 3, ponto 14b), o mesmo limite aplica-se às coimas do artigo 99, n.os 4 e 5 (artigo 99(6a)). O nível de 15 milhões de EUR abrange também as obrigações dos fornecedores e operadores do artigo 25, n.os 2 e 4 (artigo 99(4), alínea da).

A seguir: verificações no pipeline, análise baseada em regras e artigo 12

O Scanara prepara evidências a partir dos seus repositórios

O Scanara lê os seus repositórios GitHub ligados e executa análises baseadas em regras para padrões comuns de IA e de aprendizagem automática. Pode não detetar código fora do padrão. Em separado, gera rascunhos de documentação a partir de modelos e das suas respostas nas avaliações, como evidências para o seu trabalho de conformidade. A classificação é decidida por si.