Skip to main content

Conformidade com o Regulamento de IA no pipeline CI/CD

O que o regulamento exige e um pipeline CI/CD pode documentar, três fases de pipeline, como funciona o merge gate do GitHub do Scanara e onde terminam as análises baseadas em regras.

O regulamento não exige CI/CD. Os fornecedores de sistemas de IA de risco elevado devem manter atualizada a documentação técnica (artigo 11). Devem também testar antes da colocação no mercado ou em serviço (artigo 9(8)). Devem ainda manter um sistema de gestão da qualidade (artigo 17). Um pipeline pode fornecer provas destas obrigações.

Estas 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: associe cada fase do pipeline ao artigo que documenta.

Um pipeline pode fornecer provas destas obrigações; não decide a conformidade

  • A documentação técnica mantém-se atualizada (artigo 11)

    A documentação técnica é elaborada antes da colocação no mercado ou em serviço e mantida atualizada. Contém, no mínimo, os elementos do anexo IV. Um passo do pipeline pode verificar que os documentos exigidos existem e mudam em conjunto com o código.

  • Os testes realizam-se antes da colocação no mercado ou em serviço (artigo 9(6) a (8))

    Os testes realizam-se em qualquer momento do desenvolvimento e, em todo o caso, antes da colocação no mercado ou da colocação em serviço, com métricas e limiares probabilísticos definidos previamente e adequados à finalidade prevista. As fases de teste do pipeline com limiares fixos produzem resultados datados.

  • A gestão da qualidade abrange o controlo de alterações (artigo 17(1))

    O sistema de gestão da qualidade documenta o controlo da conceção, o controlo da qualidade do desenvolvimento, os procedimentos de exame, teste e validação e a gestão das modificações. Os registos do pipeline e as regras de revisão podem documentar estes passos.

  • As modificações substanciais exigem uma nova avaliação da conformidade (artigo 43(4))

    Uma alteração a um sistema após a colocação no mercado que a avaliação da conformidade inicial não previu e que afeta o cumprimento dos requisitos da secção 2 ou altera a finalidade prevista é uma modificação substancial (artigo 3, ponto 23). Um pipeline pode assinalar alterações ao modelo ou à finalidade prevista para revisão humana. Não decide se uma alteração é substancial. Nos sistemas que continuam a aprender após a colocação no mercado, as alterações predeterminadas na avaliação inicial e documentadas nos termos do anexo IV, ponto 2, alínea f), não são modificações substanciais (artigo 43(4)).

Três fases de pipeline adequadas a estas obrigações (a nossa proposta)

O regulamento não indica fases de pipeline. Esta divisão coloca verificações rápidas em cada pull request e a análise completa antes da publicação.

Fase 1: verificações no pull request

Executam-se em cada pull request e dão resposta rápida aos programadores.

  • Análise de código: A análise estática baseada em regras assinala componentes de IA e padrões em falta, por exemplo operações de IA sem registo. Só deteta padrões padrão de frameworks de ML.
  • Verificação de documentos: Regras de políticas verificam se os documentos exigidos existem e contêm as secções exigidas. Verificam que o conteúdo está presente, não que é verdadeiro nem bom.
  • Registo da classe de risco: Verifique que a classificação de risco do sistema está registada e é revista quando o código ou a finalidade prevista mudam. A classificação em si é uma decisão humana (artigo 6).

Fase 2: merge gate

Uma verificação antes do merge que pode travar alterações não conformes.

  • Limites de constatações: Defina limites para constatações críticas e elevadas. No modo bloqueante, uma análise acima dos limites faz falhar a verificação.
  • Constatações sobre os artigos 5 e 14: Uma análise de código não mostra intenção nem contexto. Uma pessoa revê cada constatação que aponte para uma prática proibida (artigo 5) ou para a falta de supervisão humana (artigo 14).
  • Alterações à documentação: Verifique que a documentação do anexo IV muda no mesmo pull request que o código que descreve.

Fase 3: análise antes da publicação

Uma análise completa da versão candidata.

  • Análise completa: Uma análise completa de código e documentos. A análise de documentos suporta oito línguas: EN, DE, FR, IT, ES, NL, PL e PT.
  • Rascunho de dossier: O Scanara redige rascunhos de documentos alinhados com os anexos IV e V a partir dos seus dados e das respostas de avaliação. O preenchimento automático é parcial; o resto escreve e verifica o utilizador.
  • Instantâneo de provas: Guarde o relatório da análise junto do registo da versão, para poder demonstrar o que foi verificado e quando.

Como funciona o merge gate do GitHub do Scanara

O Scanara recebe os eventos de pull request do GitHub, analisa a alteração e comunica o resultado como check run do GitHub. No modo apenas de relatório, uma verificação falhada é comunicada como neutra. No modo bloqueante, a verificação falha.

O merge gate só funciona com o GitHub. As análises agendadas ainda não estão disponíveis; as análises executam-se a pedido e nos pull requests.

O que as análises verificam e onde terminam

A cobertura é parcial. No instantâneo de 24 de agosto de 2026, 77 das 174 obrigações mapeadas têm regras de código, em 43 artigos, e 23 têm regras de documentos, em 23 artigos. O mapeamento é anterior às alterações do Regulamento (UE) 2026/1744, por exemplo os artigos 4a, 60a e 75a a 75d. As restantes obrigações exigem avaliações e trabalho humano.

Regras de código

  • Artigo 5: práticas proibidas

    As regras assinalam padrões de código que podem indicar uma prática proibida. Se uma prática é proibida depende da finalidade e do contexto, que o código não mostra.

  • Artigo 9: gestão de riscos

    As regras assinalam pontos de decisão de IA sem código reconhecível de avaliação de riscos ou de validação.

  • Artigo 10: dados e governação de dados

    As regras assinalam pipelines de treino sem verificações reconhecíveis da qualidade dos dados.

  • Artigo 12: registo

    As regras assinalam operações de IA sem registo reconhecível.

  • Artigo 14: supervisão humana

    As regras assinalam caminhos de decisão sem ponto de intervenção humana reconhecível, como uma anulação ou um procedimento de paragem.

  • Artigo 15: exatidão e robustez

    As regras assinalam a falta de validação do modelo e de métricas de exatidão.

Regras de documentos

  • Secções da documentação técnica (artigo 11)

    As regras do Scanara definem oito secções obrigatórias da documentação técnica, baseadas no anexo IV, e verificam se estão presentes. Verificam que o conteúdo está presente, não que é bom.

  • Instruções de utilização (artigo 13)

    Verifica se as instruções de utilização existem e contêm as secções exigidas.

  • Declaração UE de conformidade

    Verifica se a declaração contém os elementos enumerados no anexo V.

  • Oito línguas

    A análise de documentos suporta EN, DE, FR, IT, ES, NL, PL e PT.

Lista de verificação de implementação

  • Adicione uma análise de código e documentos ao fluxo de trabalho dos pull requests.
  • Comece no modo apenas de relatório e reveja as constatações.
  • Defina limites para constatações críticas e elevadas e depois passe ao modo bloqueante.
  • Exija a revisão humana de cada constatação que afete o artigo 5 ou o artigo 14.
  • Guarde o relatório da análise com cada registo de versão.
  • Assinale para revisão as alterações ao modelo, aos dados de treino ou à finalidade prevista como possíveis modificações substanciais (artigo 43(4)).
  • Repita a análise completa antes de cada versão e atualize a documentação do anexo IV.
  • Mantenha a documentação técnica no repositório junto do código e atualize-a no mesmo pull request.

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: trilhas de auditoria, análise baseada em regras 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.