Compliance as Code para sistemas de IA

Como a compliance as code se aplica aos artigos 9 a 15: o que uma regra pode testar, o que continua com uma pessoa e o que as análises baseadas em regras do Scanara abrangem e não abrangem.

Atualizado 22 de outubro de 2026

Compliance as code significa escrever partes dos requisitos legais como regras que correm com o seu código. Para os fornecedores de sistemas de IA de risco elevado, alguns requisitos dos artigos 9 a 15 podem ser testados assim. A maioria exige juízo humano.

As obrigações aplicam-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. 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: escolha um artigo e anote quais dos seus requisitos uma regra pode testar.

Uma regra pode testar se algo existe; uma pessoa tem de julgar se é adequado

Os requisitos do regulamento falam do que é adequado à finalidade prevista. As regras transformam a parte verificável em testes e deixam o resto às pessoas.

O que uma regra pode testar

Se existe código de registo em torno das chamadas ao modelo (artigo 12).
Se os documentos exigidos existem e contêm as secções esperadas (artigos 11, 13, 17 e 47).
Se há uma classe de risco registada para cada sistema.
Quem alterou uma regra ou um documento, e quando (histórico do git).

O que exige uma pessoa

Se a análise de riscos é adequada e o risco residual aceitável (artigo 9(5)).
Se o sistema é de risco elevado, o que depende da sua finalidade prevista (artigo 6).
Se a supervisão humana funciona na prática e tem pessoal atribuído (artigos 14 e 26(2)).
Se os documentos são verdadeiros e completos. Uma análise verifica que o conteúdo está presente.

Três blocos: regras de código, políticas de documentos, documentação com controlo de versões

Regras de código

Regras de análise estática (Semgrep) detetam padrões padrão de frameworks de ML no seu código-fonte.

Deteção de padrões: As regras assinalam operações de IA sem registo, validação ou pontos de intervenção humana reconhecíveis.
Associação a artigos: Cada regra corresponde a um artigo do regulamento.
Limites: A fiabilidade da deteção varia consoante o nível da linguagem de programação, e os níveis experimentais têm mais falsos positivos e falsos negativos. Camadas próprias e código ofuscado podem passar despercebidos.

Políticas de documentos

As políticas do Open Policy Agent (OPA) verificam o conteúdo exigido nos documentos de conformidade em oito línguas: EN, DE, FR, IT, ES, NL, PL e PT.

Secções da documentação técnica: As políticas verificam se a documentação técnica contém as oito secções que as regras do Scanara exigem, baseadas no anexo IV. Verificam que o conteúdo está presente, não que é bom.
Documentos GPAI: Uma análise de documentos abrange a documentação dos fornecedores de modelos de IA de finalidade geral (artigo 53). A geração de dossiers redige rascunhos dos documentos dos anexos XI e XII.

Documentação com controlo de versões

A documentação no seu repositório tem controlo de versões em conjunto com o código.

Documentação como código: As avaliações de risco e as descrições do sistema existem como ficheiros estruturados. O histórico do git mostra quem alterou o quê e quando. O artigo 11 exige manter atualizada a documentação técnica.
Rascunhos gerados: O Scanara redige documentos alinhados com o anexo IV a partir dos seus dados e das respostas de avaliação. O preenchimento automático é parcial, e dados errados produzem documentos bem formatados mas errados.

Do artigo à verificação: o que uma regra abrange e o que continua consigo

Cinco artigos mostram como um requisito se divide numa verificação baseada em regras e numa tarefa humana. A cobertura difere por artigo: uns têm regras de código, outros análises de documentos, outros uma avaliação orientada.

Artigo 9: gestão de riscos

Requisito: Estabelecer, implementar, documentar e manter um sistema de gestão de riscos ao longo do ciclo de vida (artigo 9(1) e (2)).
Verificação no Scanara: Regra de código: assinala pontos de decisão de IA sem código reconhecível de avaliação de riscos ou de validação. Uma avaliação orientada regista a sua análise de riscos como prova.
Continua consigo: Identificar e avaliar os riscos e decidir que o risco residual é aceitável (artigo 9(5)).

Artigo 11: documentação técnica

Requisito: Elaborar a documentação técnica antes da colocação no mercado ou em serviço e mantê-la atualizada, com pelo menos os elementos do anexo IV.
Verificação no Scanara: Análise de documentos: verifica se estão presentes as oito secções obrigatórias que as regras do Scanara definem para a documentação técnica, baseadas no anexo IV. A geração de dossiers redige a documentação do anexo IV a partir dos seus dados.
Continua consigo: Escrever conteúdo exato e mantê-lo atualizado. Uma análise verifica a presença, não a veracidade.

Artigo 12: registo

Requisito: Permitir o registo automático de eventos (registos) ao longo do ciclo de vida do sistema.
Verificação no Scanara: Regra de código: assinala operações de IA sem registo reconhecível.
Continua consigo: Escolher os eventos a registar para os três fins do artigo 12(2) e conservar os registos.

Artigo 13: transparência

Requisito: Conceber o sistema de modo a que os responsáveis pela implantação possam interpretar o seu resultado e usá-lo adequadamente, e fornecer instruções de utilização.
Verificação no Scanara: Análise de documentos: verifica se as instruções de utilização existem e contêm as secções exigidas.
Continua consigo: Tornar as instruções exatas e compreensíveis para os responsáveis pela implantação.

Artigo 14: supervisão humana

Requisito: Conceber o sistema de modo a que pessoas singulares o possam supervisionar eficazmente. De forma adequada e proporcionada, devem poder intervir no sistema ou interrompê-lo, por exemplo através de um botão de paragem ou de um procedimento semelhante (artigo 14(1) e (4), alínea e)).
Verificação no Scanara: Regra de código: assinala caminhos de decisão sem ponto de intervenção humana reconhecível.
Continua consigo: Conceber uma supervisão que funcione na prática e atribuir pessoas formadas (artigo 26(2)).

O que o Scanara não faz

O Scanara não observa sistemas em funcionamento, não avalia a finalidade prevista nem o contexto empresarial, não presta aconselhamento jurídico e não substitui uma avaliação da conformidade por um organismo notificado quando esta é exigida. O mesmo código pode ser de risco mínimo ou elevado, consoante a finalidade prevista. Uma análise bem-sucedida não demonstra a conformidade.

Primeiros passos em cinco etapas

1
Classifique o seu sistema de IA
Decida se o seu sistema é de risco elevado (artigo 6, anexo III). O resultado depende da finalidade prevista e é decisão sua.
2
Execute uma primeira análise
Analise o seu código e os seus documentos para obter uma base de constatações. Leia-as como indicações, não como veredicto.
3
Integre a análise no pipeline
Comece no modo apenas de relatório e depois pondere o modo bloqueante. O guia de CI/CD descreve as fases.
4
Trate as constatações por prioridade
Peça primeiro a uma pessoa que reveja as constatações que apontem para o artigo 5 ou para o artigo 14.
5
Redija a documentação
Gere rascunhos dos documentos dos anexos IV e V a partir dos seus dados e depois complete-os e verifique-os.

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: fases do pipeline, trilhas de auditoria e documentação técnica

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.

Veja como o Scanara analisa os seus repositórios