Como as regras da Scanara são criadas e verificadas
Cada regra está ancorada ao artigo, número e alínea exatos do regulamento — e passa por seis camadas de verificação antes de ser publicada.
Medido em 4 de agosto de 2026 — reverificado a cada versão.
Como as regras são criadas
O pipeline de regras da Scanara analisa o texto integral do Regulamento (UE) 2024/1689 e ancora cada regra ao seu artigo, número e alínea exatos. Um único ficheiro de mapeamento classifica cada obrigação do regulamento como uma de três coisas: detetável no código, detetá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
Cada versão do conjunto de regras passa por seis portas em série, desde verificações estruturais amplas até uma comparação exata com um resultado conhecido como correto. Uma versão só é publicada se todas as portas forem ultrapassadas.
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
Nove verificações estruturais sobre o corpus de regras: cobertura de artigos, ausência de padrões duplicados, metadados completos, valores de enumeração válidos, IDs de regra únicos e limites de 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, em 25 aplicações de benchmark, fixado numa versão específica 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 conformidade da Scanara ao nível dos documentos 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. Isto segue a mesma abordagem policy-as-code usada em todo o ecossistema OPA: regras declarativas, avaliação determinística, um resultado auditável sempre. 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. Está simplificado para documentação pública. O conjunto de regras em produção abrange dezenas de categorias de obrigações, além de deteção multilingue, ponderação de gravidade e verificações de consistência entre documentos não apresentadas aqui.
package eu_ai_act.example.article_11
# Illustrative pattern only — simplified for public documentation.
# Scanara's production ruleset covers dozens of obligation categories with
# multi-language detection, severity weighting, and cross-document
# consistency checks not shown here.
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 satisfiedJuntos, os dois motores detetam automaticamente 66 artigos do Regulamento (UE) 2024/1689: 44 detetáveis no código e 22 ao nível documental através do OPA. A cobertura abrange os 8 idiomas da UE. Os resultados de ambos os motores alimentam diretamente o dossier de conformidade gerado. O rasto de evidências remonta a um resultado real de scan, não a uma lista de verificação autodeclarada.
Valores atualmente medidos
| Métrica | Limiar | Atual |
|---|---|---|
| Cobertura de artigos (113 artigos do regulamento) | 100% | 100% |
| Cobertura de padrões reais de artigos elegíveis para código | 100% | 100% (44/44) |
| Artigos documentais/de política com cobertura OPA | 100% | 100% (22/22) |
| Obrigações detetáveis no código com pelo menos uma regra | 100% | 100% (77/77) |
| Regras com metadados de nível de risco | 100% | 100% (522/522) |
| Regras com metadados de ator | 100% | 100% (522/522) |
| Regras com orientação de remediação estruturada | 100% | 100% (522/522) |
| 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
Estas são métricas de cobertura, completude e determinismo — mostram quanto do regulamento está mapeado e quão consistente é o comportamento do pipeline entre linguagens e versões. Não existe um KPI de precisão, exaustividade ou taxa de falsos positivos, porque isso exigiria um corpus de referência rotulado por humanos que não temos. A evidência estrutural contra falsos positivos é esta: cada fixture negativo por obrigação deve produzir zero constatações, e uma aplicação de benchmark de risco mínimo dedicada — com todas as regras de alto risco, GPAI e risco limitado suprimidas — também deve produzir zero constatações.
O Scanara deteta lacunas de conformidade ao nível do código e dos documentos. Para interpretações jurídicas complexas, recomendamos a consulta de assessoria jurídica especializada.