Cómo se crean y verifican las reglas de Scanara
Esta página es para ingenieros y responsables de cumplimiento que quieren juzgar la fiabilidad de las reglas de Scanara. Cada regla remite a un artículo, apartado y punto del Reglamento de IA, y una versión del conjunto de reglas debe superar seis comprobaciones. La última sección indica lo que los números no miden.
Medido el 9 de septiembre de 2026.
Cómo se construyen las reglas
El pipeline de reglas de Scanara analiza el texto del Reglamento (UE) 2024/1689 en su versión modificada y ancla cada regla a su artículo, apartado y punto exactos. Un único archivo de mapeo asigna a cada obligación uno de tres resultados: detectable en el código, comprobable en un documento de política, o no detectable automáticamente y dejada a una evaluación guiada.
La escalera de puertas de publicación
El conjunto de reglas pasa por seis comprobaciones en serie, desde controles estructurales amplios hasta una comparación exacta con una salida de referencia. Las seis se ejecutan en el pipeline de CI de Scanara.
L2.5
Coherencia del catálogo
Comprueba que el catálogo de artículos, el mapeo de obligaciones y cualquier regla de supresión de solapamientos permanezcan sincronizados entre sí.
L1/L2
Estructura del corpus
Comprobaciones estructurales sobre el corpus de reglas: cobertura de artículos, sin patrones duplicados, metadatos completos, valores de enumeración válidos, identificadores de regla únicos y límites para reglas stub.
L3
Fixtures por obligación
Para cada obligación detectable en el código, un fixture positivo debe generar al menos un hallazgo y uno negativo debe generar cero — en cada lenguaje soportado.
L4
Umbrales de KPI
17 umbrales de cobertura, integridad y determinismo — ver la tabla a continuación.
L5
Instantáneas de referencia
Una comparación exacta de cada hallazgo con un resultado esperado registrado, para las 27 aplicaciones de prueba que tienen una instantánea de referencia, fijada a una versión concreta del conjunto de reglas.
R1
Puerta de remediación
Confirma que un fixture sin remediar genera un hallazgo no satisfecho, y que el mismo fixture con la remediación recomendada aplicada se reconoce como satisfecho.
Cómo evalúa Scanara la documentación con OPA y Rego
Las comprobaciones documentales de Scanara se ejecutan sobre Open Policy Agent (OPA). OPA evalúa la documentación técnica frente a las obligaciones del Reglamento (UE) 2024/1689. Es un enfoque policy-as-code: reglas declarativas y evaluación determinista, de modo que el mismo documento da el mismo resultado siempre. Se ejecuta junto con el escaneo de código fuente de Scanara. El escaneo de código comprueba lo que hace el código. OPA comprueba lo que dice la documentación.
Cada archivo de documentación sigue los mismos pasos. Primero, Scanara lo analiza y detecta su idioma (se admiten 8 idiomas de la UE). Después lo normaliza en un documento de entrada estructurado: secciones, encabezados, texto extraído. OPA evalúa este documento estructurado frente a un paquete de políticas Rego compilado.
Scanara genera estas reglas a partir de un mapeo canónico entre el texto de los artículos del Reglamento (UE) 2024/1689 y requisitos verificables automáticamente. Ninguna regla se escribe a mano por repositorio. Cada regla se remonta a un artículo, apartado y punto concretos. La evaluación produce un hallazgo por obligación: cumplida, ausente o parcial. Estos hallazgos se incorporan al informe de cumplimiento junto con los hallazgos de código fuente.
El ejemplo siguiente muestra el patrón, simplificado para la documentación pública. El conjunto de reglas de producción es más amplio y también gestiona varios idiomas de documentos y la ponderación por gravedad.
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 satisfiedEn la instantánea del 24 de agosto de 2026, las reglas automáticas cubren 66 de 113 artículos (cerca del 58 %). Las reglas de código cubren 43 artículos y las reglas documentales 23, en 8 idiomas de documentos de la UE. Los demás artículos se tratan mediante evaluaciones guiadas y documentación generada, o vinculan a las autoridades y no a los operadores. Estas cifras son una instantánea fechada y cambian con cada generación de reglas. Los hallazgos de ambos motores alimentan el informe de cumplimiento, y cada hallazgo se remonta a un resultado de escaneo real, no a una lista de comprobación autodeclarada.
Valores medidos actuales
| Métrica | Umbral | Actual |
|---|---|---|
| Artículos contemplados por el pipeline de reglas (119 en el reglamento) | 100% | 100% |
| Cobertura de patrones reales de artículos elegibles para código | 100% | 100% |
| Artículos documentales/de política con cobertura OPA | 100% | 100% |
| Obligaciones detectables en código con al menos una regla | 100% | 100% |
| Reglas con metadatos de nivel de riesgo | 100% | 100% |
| Reglas con metadatos de actor | 100% | 100% |
| Reglas con orientación de remediación estructurada | 100% | 100% |
| Dispersión en el número de reglas entre los 12 lenguajes soportados | ≤ 1 | 0 |
| Identificadores de regla duplicados | 0 | 0 |
| Reglas stub (sin patrón de código) por artículo | ≤ 1 | 0 |
| Umbrales de KPI L4 superados | 17/17 | 17/17 |
Lo que estos números no miden
Los valores del 100 % en la cobertura de artículos significan que el pipeline de reglas contempla todos los artículos; no significan que cada artículo se compruebe automáticamente. Estas métricas miden cobertura, completitud y determinismo: cuánto del reglamento está mapeado y con qué coherencia se comporta el pipeline entre lenguajes y versiones. No hay un indicador de precisión, exhaustividad ni tasa de falsos positivos, porque requeriría un corpus de referencia etiquetado por personas que Scanara no tiene. La evidencia estructural frente a los falsos positivos es esta: cada fixture negativo por obligación debe generar cero hallazgos, y una aplicación de prueba de riesgo mínimo, con todas las reglas de alto riesgo, de modelos de IA de uso general y de riesgo limitado suprimidas, también debe generar cero hallazgos.
Scanara detecta las carencias en el código y en los documentos que sus reglas cubren. Puede pasar por alto código personalizado, no estándar u ofuscado, y superar un escaneo no significa que una organización cumpla la normativa. La clasificación y la interpretación jurídica siguen siendo cosa tuya y de tu asesoría jurídica.