Static Analysis for AI Compliance: Why Code Scanning Complements Questionnaires

What code scanning finds that questionnaires miss

Code scanners detect concrete, verifiable signals that questionnaire respondents may not know about or may describe inaccurately: Article 5 prohibited-practice indicators, AI framework imports that suggest risk tier, credential exposure and unsafe deserialisation affecting Article 15 cybersecurity, and agent autonomy patterns without human oversight gates relevant to Article 14.

Code scanners analyse source code directly. The findings exist in the repository regardless of how anyone answers a questionnaire.

• Article 5 prohibited practice indicators — patterns in code that match behaviours the AI Act bans outright. A questionnaire asks whether your system does these things; a code scanner checks.
• AI framework imports and risk patterns — the presence of specific libraries (face recognition, reinforcement learning, biometric processing) that indicate risk tier before anyone fills in a form.
• Credential exposure and unsafe deserialisation — security risks that affect Article 15 (accuracy, robustness, cybersecurity) and exist entirely in code.
• Agent autonomy without human oversight gates — agentic AI systems that make decisions without breakpoints for human review, relevant to Article 14 (human oversight).

These are facts about the codebase. A questionnaire respondent may not know about them, may understate them, or may describe them inaccurately. Code scanning provides an independent check.

What questionnaires cover that code scanning cannot

Questionnaires capture the obligations that have no source-code footprint: risk management systems (Article 9), deployment context that determines risk tier, fundamental rights impact assessments (Article 27), post-market monitoring plans (Article 72), and data governance policies (Article 10). These are organisational obligations that no scanner can verify.

Questionnaires capture organisational and contextual information that does not exist in source code.

• Risk management system (Article 9) — whether your organisation has a documented process for identifying and mitigating AI risks. This is a policy question, not a code question.
• Deployment context — the same model can be high-risk or minimal-risk depending on where it is deployed. A facial recognition model used for phone unlock is different from one used for law enforcement. Code scanning sees the model; it does not see the deployment.
• Stakeholder consultation and impact assessments — fundamental rights impact assessments (Article 27) require engagement with affected communities. No code scanner can evidence this.
• Post-market monitoring plans — Article 72 requires ongoing monitoring after deployment. This is an operational commitment, not a code property.
• Data governance policies — Article 10 requires data quality and governance measures. Code scanning can detect some data handling patterns, but the broader governance framework lives in documentation and process.

Honest comparison: tools in this space

Examples include Regula (423 tiered risk regexes, 8 detected source languages, offline), AIR Blackbox (whose repository describes 51 checks and a local Python scanner), and Systima Comply (whose repository describes AST-assisted analysis for TypeScript/JavaScript and Python projects). Questionnaire-based approaches include the European Commission's ALTAI. These are maintainers' published descriptions, not independently validated performance comparisons.

When you need both

Most teams building AI systems that may fall under the EU AI Act need code scanning in CI and a questionnaire or governance platform for organisational obligations. The combination looks like this:

• CI pipeline: run a code scanner on every commit to catch prohibited practice indicators, new framework imports, and security risks before they reach production.
• Quarterly or milestone review: complete a compliance questionnaire to document risk management processes, deployment context, stakeholder engagement, and data governance.
• Legal review: neither tool replaces a lawyer. The AI Act is complex legislation with delegated acts still being published. If your system is high-risk under Annex III, get legal advice.

Regulation (EU) 2026/1744 is in force and sets 2 December 2027 for Annex III high-risk provisions. The original Article 5 prohibitions have applied since 2 February 2025, while the amendment's new Article 5 points apply from 2 December 2026. Scope and classification still require contextual review.

Last reviewed: 14 August 2026 · Author: Regula maintainers · Not legal advice. Regula is a code scanning tool that identifies risk indicators for developer review. It does not determine your system’s risk classification or replace professional legal counsel.