Como as regras da Scanara são criadas e verificadas
Esta página é para engenheiros e responsáveis de conformidade que querem avaliar a fiabilidade das regras da Scanara. Cada regra remete para um artigo, número e alínea do Regulamento de IA, e uma versão do conjunto de regras tem de passar seis verificações. A última secção indica o que os números não medem.
Medido em 9 de setembro de 2026.
Como as regras são criadas
O pipeline de regras da Scanara analisa o texto do Regulamento (UE) 2024/1689 na versão alterada e ancora cada regra ao seu artigo, número e alínea exatos. Um único ficheiro de mapeamento atribui a cada obrigação um de três resultados: detetável no código, verificável num documento de política, ou não detetável automaticamente e deixada a uma avaliação orientada.
A escada de portas de publicação
O conjunto de regras passa por seis verificações em série, de verificações estruturais amplas até uma comparação exata com uma saída de referência. As seis são executadas no pipeline de CI da Scanara.
L2.5
Coerência do catálogo
Verifica se o catálogo de artigos, o mapeamento de obrigações e quaisquer regras de supressão de sobreposição permanecem sincronizados entre si.
L1/L2
Estrutura do corpus
Verificações estruturais ao corpus de regras: cobertura de artigos, sem padrões duplicados, metadados completos, valores de enumeração válidos, IDs de regra únicos e limites para regras stub.
L3
Fixtures por obrigação
Para cada obrigação detetável no código, um fixture positivo deve gerar pelo menos uma constatação e um fixture negativo deve gerar zero — em cada linguagem suportada.
L4
Limiares de KPI
17 limiares de cobertura, completude e determinismo — ver a tabela abaixo.
L5
Instantâneos de referência
Uma comparação exata de cada constatação com um resultado esperado registado, para as 27 aplicações de teste que têm um instantâneo de referência, fixada numa versão concreta do conjunto de regras.
R1
Porta de remediação
Confirma que um fixture não corrigido gera uma constatação não satisfeita, e que o mesmo fixture com a remediação recomendada aplicada é reconhecido como satisfeito.
Como a Scanara avalia a documentação com OPA e Rego
As verificações de documentos da Scanara são executadas sobre Open Policy Agent (OPA). O OPA avalia a documentação técnica face às obrigações do Regulamento (UE) 2024/1689. É uma abordagem policy-as-code: regras declarativas e avaliação determinística, de modo que o mesmo documento dá sempre o mesmo resultado. Isto ocorre em paralelo com a análise de código-fonte da Scanara. A análise de código verifica o que o código faz. O OPA verifica o que a documentação diz.
Cada ficheiro de documentação segue os mesmos passos. Primeiro, a Scanara analisa-o e deteta o idioma (são suportados 8 idiomas da UE). Depois normaliza-o num documento de entrada estruturado: secções, títulos, texto extraído. O OPA avalia este documento estruturado face a um pacote de políticas Rego compilado.
A Scanara gera estas regras a partir de um mapeamento canónico entre o texto dos artigos do Regulamento (UE) 2024/1689 e requisitos verificáveis automaticamente. Nenhuma regra é escrita manualmente por repositório. Cada regra é rastreável até um artigo, número e alínea específicos. A avaliação produz um resultado por obrigação: satisfeita, em falta ou parcial. Estes resultados alimentam o relatório de conformidade juntamente com os resultados do código-fonte.
O exemplo abaixo mostra o padrão, simplificado para a documentação pública. O conjunto de regras de produção é maior e também trata vários idiomas de documentos e a ponderação por gravidade.
package eu_ai_act.example.article_11
# Illustrative pattern only — simplified for public documentation.
# Scanara's production ruleset is larger and also handles several document
# languages and severity weighting.
default satisfied := false
# A document satisfies this (illustrative) Article 11 check when its parsed
# sections include the required topic, with non-empty content.
satisfied if {
some section in input.document.sections
section.topic == "risk_management_process"
count(trim_space(section.content)) > 0
}
finding := {
"article": "11",
"obligation": "technical_documentation.risk_management_process",
"status": "satisfied",
} if satisfied
finding := {
"article": "11",
"obligation": "technical_documentation.risk_management_process",
"status": "missing",
"severity": "high",
} if not satisfiedNo instantâneo de 24 de agosto de 2026, as regras automáticas cobrem 66 de 113 artigos (cerca de 58 %). As regras de código cobrem 43 artigos e as regras de documentos 23, em 8 idiomas de documentos da UE. Os restantes artigos são tratados por avaliações orientadas e documentação gerada, ou vinculam as autoridades e não os operadores. Estes números são um instantâneo datado e mudam a cada geração de regras. Os resultados de ambos os motores alimentam o relatório de conformidade, e cada resultado remonta a um resultado real de scan, não a uma lista de verificação autodeclarada.
Valores atualmente medidos
| Métrica | Limiar | Atual |
|---|---|---|
| Artigos considerados pelo pipeline de regras (119 no regulamento) | 100% | 100% |
| Cobertura de padrões reais de artigos elegíveis para código | 100% | 100% |
| Artigos documentais/de política com cobertura OPA | 100% | 100% |
| Obrigações detetáveis no código com pelo menos uma regra | 100% | 100% |
| Regras com metadados de nível de risco | 100% | 100% |
| Regras com metadados de ator | 100% | 100% |
| Regras com orientação de remediação estruturada | 100% | 100% |
| Dispersão no número de regras entre as 12 linguagens suportadas | ≤ 1 | 0 |
| IDs de regra duplicados | 0 | 0 |
| Regras stub (sem padrão de código) por artigo | ≤ 1 | 0 |
| Limiares de KPI L4 ultrapassados | 17/17 | 17/17 |
O que estes números não medem
Os valores de 100 % na cobertura de artigos significam que o pipeline de regras contempla todos os artigos; não significam que cada artigo seja verificado automaticamente. Estas métricas medem cobertura, completude e determinismo: quanto do regulamento está mapeado e com que consistência o pipeline se comporta entre linguagens e versões. Não existe um indicador de precisão, abrangência ou taxa de falsos positivos, porque exigiria um corpus de referência rotulado por pessoas que a Scanara não tem. A prova estrutural contra falsos positivos é esta: cada fixture negativo por obrigação deve gerar zero constatações, e uma aplicação de teste de risco mínimo, com todas as regras de risco elevado, de modelos de IA de finalidade geral e de risco limitado suprimidas, também deve gerar zero constatações.
A Scanara deteta as lacunas no código e nos documentos que as suas regras cobrem. Pode não detetar código personalizado, não padrão ou ofuscado, e passar uma verificação não significa que uma organização cumpra as regras. A classificação e a interpretação jurídica continuam a cargo de si e do seu consultor jurídico.