[Feature]: EU AI Act compliance checks for computer vision pipelines

[shotwellj]

Search before asking

• I have searched the issues and discussions and found no similar feature request.

Feature Description

What: EU AI Act compliance checks mapped to computer vision pipeline operations — risk classification for detection/tracking use cases, structured logging for detection events, confidence thresholds for human review, and adversarial robustness testing.

Why: With the EU AI Act enforcement deadline on August 2, 2026, computer vision systems built with supervision will need to demonstrate compliance. The Act specifically calls out biometric identification and real-time monitoring as high-risk categories, which are common use cases for CV pipelines. With 36K+ stars and Fortune 100 adoption, many enterprise users have EU operations where the Act applies.

Specific areas that map to the Act:

• Art. 9 (Risk Management): Risk classification for detection/tracking use cases (surveillance vs. manufacturing vs. sports analytics have different risk levels)
• • Art. 12 (Record-Keeping): Structured logging for detection events, tracking decisions, and zone analytics
• • • Art. 14 (Human Oversight): Configurable confidence thresholds, human review triggers for high-stakes detections
• • • • Art. 15 (Security): Adversarial robustness testing for detection models, input validation for video streams
        I ran supervision through AIR Blackbox, an open-source EU AI Act compliance scanner (Apache 2.0). supervision scored 7/44 checks passing (16%), but the documentation quality is exceptional: 98% type hint coverage and 66% docstring coverage, the best I've seen across any project.

You can run it yourselves:

pip install air-blackbox
air-blackbox comply --scan . --no-llm --format table --verbose

Everything runs locally, no data leaves your machine.

How (optional): A compliance module that maps supervision's existing detection/tracking/zone analytics to EU AI Act articles, with configurable risk levels per use case and structured audit logging for detection events.

Example Usage

No response

Are you willing to submit a PR?

• Yes I'd like to help by submitting a PR!

[vincenzonetti]

Hi I'll give my two cents:

From what I can tell, most of this could be implemented on top of what's already there:

sv.Detections already carries class labels, confidences, tracker IDs, and bounding boxes. Everything needed for an Art. 12 structured audit record. A logging wrapper that serializes detection events to JSONL.
Art. 14 is mostly there too, confidence filtering exists, it would mostly be about formalizing a "flagged for review" path with a callback hook.
Art. 9 risk classification could be a simple UseCase enum with a default risk-tier mapping that developers can override per deployment, living entirely outside core.
Art. 15: I'm not really sure about this one: to me it seems like something that belongs to the training pipeline rather than to a CV toolkit like supervision.

However, I'm a bit skeptical about whether all of these should be implemented, since that would require the library to stay up to date with the law. If the maintainers are interested I'd be more than happy to contribute with some implementations.
Even if not everything makes sense to implement for the reasons above, Art. 12 and Art. 14 feel like the safest: closest to supervision's core and least likely to need updates as the law evolves.

[shotwellj]

Great breakdown @vincenzonetti , you nailed the mapping.

I've been working on exactly this problem across multiple frameworks. A few things I've learned that might be useful here:

On Art. 12: JSONL logging gets you started, but the regulation expects tamper-evident records. We solved this with HMAC-SHA256 chained hashes on each log entry so you can prove after the fact that nothing was modified or deleted. Without that, a plain log file won't hold up under audit.

On Art. 14: Agreed that confidence filtering is the foundation. The piece that's missing in most implementations is a structured gate policy; a declarative way to say "if confidence < X or risk_tier == high, route to human review" with the decision itself logged to the audit chain. A callback hook works, but you want the policy and the decision record to be first-class objects.

On Art. 9: Your instinct about a UseCase enum with overridable risk tiers is solid. The tricky part is that risk classification isn't static; the same model can be high-risk or limited-risk depending on the deployment context, so it needs to be configurable per-deployment rather than per-model.

On whether supervision should own this: Your skepticism resonates with what I've seen in other ecosystems. I've been chipping away at this with an open-source project called AIR Blackbox (https://github.com/AIR-Blackbox/air-blackbox) that tries to handle the compliance layer separately so individual frameworks don't have to track legal changes themselves. It's still early, but we have trust layer integrations for LangChain, CrewAI, AutoGen, and a few others.

A supervision integration could be interesting, the detection metadata you described (class labels, confidences, tracker IDs, bounding boxes) maps pretty cleanly to what the audit chain expects. Would be happy to explore that if there's interest from you or the maintainers.