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 roughly 70% of the EU AI Act that has 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

Code scanners include Regula (419 patterns, 8 languages, offline), AIR Blackbox (51 checks, Python-only, Apache 2.0), and Systima Comply (tree-sitter AST, TS/JS/Python). Questionnaire-based tools include the EU Commission ALTAI checker and EuroComply. Enterprise platforms like Credo AI and Holistic AI combine both approaches at enterprise pricing.

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.

The Omnibus Regulation provisional agreement of 7 May 2026 postpones Annex III high-risk obligations to 2 December 2027 (EP approved 16 Jun 2026, Council approved 29 Jun 2026; pending OJ publication). This gives teams more time to build both technical and organisational compliance — but the prohibited practice prohibitions under Article 5 already apply (since 2 February 2025).

Last verified: 11 June 2026 · Author: Kuziva Muzondo · 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.