AI traffic-offence enforcement cameras (phone use at the wheel, seatbelt violations)

Phone use and missing seatbelts are major causes of serious road injuries, yet police patrols can only observe a tiny fraction of drivers. Cameras with on-device vision models look through the windscreen, discard the vast majority of vehicles immediately and pass only suspected violations to a police officer, who decides whether a fine is issued. The technology works; the hard part is the legal basis, data minimisation and a defensible evidence chain.

Problem & value

• Today: enforcement relies on officers spotting offences by eye, so detection probability is low and fines are unevenly applied. Conventional speed cameras cannot see hands or belts.
• AI value: screening of every passing vehicle at the roadside, with humans reviewing only the flagged few. In the Netherlands the police "Monocam" flags possible phone use; an officer reviews the image, a second officer checks the record, and the file goes to the central collection agency (CJIB) which issues the fine [1][2].
• Reported results: Rheinland-Pfalz reported more than 300 phone violations from its first mobile Monocam within a few months of starting operation in mid-April, and plans one system for each of its five police headquarters [3]. No independent, comparable accident-reduction figures are assumed here; evaluate against your own baseline.
• Known failure: a Dutch AI expert was fined after the system read a head-scratching gesture as phone use; his appeal can take months [4]. Such cases drive the demand for human review and appeal handling.

Variants

• Phone-use detection: classify hand-near-ear/lap/wheel postures plus handheld device.
• Seatbelt detection: presence of diagonal belt strap across torso; harder through tinted glass.
• Combined multi-offence cameras: phone, belt and sometimes occupant count for lane rules.
• Fixed gantry, trailer/tripod-mounted and vehicle-mounted units; mobile ones dominate pilots because they limit the data collected to a deployment period.
• Evaluated in other German Länder and Australian states (Australia runs state-wide programmes with human verification). EU deployments exist at police level in NL and DE-RP; others remain pilots [1][3].

How it works

1. camera + IR flash (vehicle in lane)
2. edge detection of vehicle + windscreen region + front occupants
3. action/attribute classifier (phone held? belt worn?) with confidence
4. on-device filter: discard all non-suspect frames immediately (no storage)
5. candidate image encrypted and queued
6. officer review #1 (confirm/reject, see only the cropped evidence)
7. second verification / legal check (four-eyes)
8. case creation, plate lookup, notice by the competent authority
9. audit log, retention clock, deletion of rejected images

• Models: small detectors (YOLO-class) locate the windscreen and people; a fine-grained classifier or compact VLM judges posture/object; thresholds are tuned for high precision, since a false positive means a wrongly fined citizen.
• Human-in-the-loop: mandatory. The model never issues a sanction; officers see the flagged crop and decide. Rejected images are deleted at once.

Data preparation

Data are camera images of vehicles, windscreens and occupants, plus plate lookups, case records and officers' confirm/reject decisions. They live in the camera system, an encrypted evidence queue and the authority's case-management system, not in classic ERP or DMS. Typical gaps: no representative labelled images for local lighting, windscreen and weather conditions, privacy rules that forbid keeping non-suspect frames, class imbalance, and unclear retention rules.

Preparation steps: define what may be stored and for how long (PREP-025, PREP-024); collect a legally cleared or pseudonymised test set (PREP-022); harvest labels from officers' confirmed and rejected cases (PREP-020) and capture their corrections as feedback (PREP-021); fix the violation class scheme (PREP-019); and build a precision-focused evaluation set with traffic experts (PREP-018). Export case data from the case-management system via a defined interface (PREP-005).

Rough share of effort: moderate. Most of it goes into legal clearance of image data and a clean evaluation set; the vendor product usually ships trained models.

Implementation paths

Which path for whom

• Public (police, traffic authorities): Path A, because enforcement requires type-approved, evidentially validated systems from established vendors; own builds would not stand up in court.
• Enterprise (fleet operators, logistics, road operators): Path C, because monitoring of own drivers is sensitive, and an edge model on HW1 keeps images on the device.
• Developer: Path C, because small detectors and classifiers run on edge hardware, which allows prototypes with on-device filtering and no image storage.

Path A — Buy (recommended)

Turnkey enforcement systems certified or accepted by the police authority. Examples: the Dutch police Monocam system [2]; Acusensus (Australia) with road-safety camera programmes in several Australian states; established enforcement-camera vendors such as Jenoptik (DE, EU) and Vitronic (DE, EU) in the broader traffic-enforcement market (check each vendor's current AI product line). Only authorities with a legal mandate can operate these; private parties cannot enforce. Check: type approval, evidence-chain features, EU hosting, on-device discard, audit trail.

Path B — Build on cloud APIs

Not suitable for the live path: sending windscreen images of all drivers to a general cloud VLM conflicts with data minimisation. A narrow role remains for offline analysis of already-consented test data or for labelling support under a controller-processor agreement in an EU region.

Path C — Self-host (open source)

For research or an authority's own prototype: open detectors (Ultralytics YOLO, RT-DETR), pose models (RTMPose/MMPose), tracking, and small open VLMs for review assistance; run on edge devices (NVIDIA Jetson Orin class, HW1) with TensorRT or ONNX Runtime. Check the licences (e.g. AGPL for Ultralytics) against your deployment.

Path D — Custom training

Always needed in practice: the camera geometry, illumination, glass tint and local phone/belt appearance drive accuracy. Needs tens of thousands of labelled windscreen images across weather, seasons and vehicle types, legally collected (often via a dedicated pilot with its own legal basis), and a held-out test set per site. Labelling by officers doubles as quality control.

State of the art (2026)

• Fine-grained action recognition through glass with IR illumination is commercially deployed; published accuracy figures are mostly vendor-reported, so insist on independent site acceptance tests (precision at the chosen threshold, by lighting, vehicle class, windscreen tint).
• Trend: from pure detection to explainable evidence (crop plus highlighted region), edge-side anonymisation of passengers and non-suspect frames, and statistical audits of error rates.
• Limits: reflections, sun glare, tinted or stickered glass, passengers, hands near the face (the scratching case), phones used legally via holders, and drivers in large trucks/vans seen from odd angles. Seatbelt detection can be fooled by clothing patterns. Performance may differ across demographics and must be audited.

Shared resources & combinations

• Same stack as VIS-028 (in-cabin monitoring), VIS-024 (pose analysis), VIS-011 (plate recognition for case assignment) and VIS-012 (traffic analytics); edge hardware is shared with VIS-010.
• Evidence images need redaction tooling like VIS-030 when they are used in statistics or training.
• Do not combine with face recognition (VIS-016): identifying drivers by face is a different, far more restricted regime.

Effort, cost & KPIs

• Path A: quarters (procurement, type approval, legal and data-protection clearance, training of officers). Cost drivers: hardware per site, officer review time, back-office integration.
• Path D additions: data collection and annotation dominate.
• KPIs: precision of officer-confirmed vs. flagged cases, share of flags rejected, appeal and withdrawal rate, review minutes per case, violation rate per site over time, casualty trend, percentage of data deleted within the retention limit.

People & change

Start with management and the department lead in the authority, together with legal/compliance, because enforcement needs a statutory basis, type approval and clear fine procedures. The data protection officer is involved from day one: cameras capture identifiable drivers and passengers, so a DPIA (Art. 35 GDPR) is required, with on-device deletion of non-suspect frames and short retention for rejected images. IT handles secure transfer and logging. Officers who review cases are the main end users; citizens are affected by the outcome and need clear information and a route to appeal.

Works council: depends. For public bodies the staff council (Personalrat) under BPersVG or state law applies; for fleet use by companies, §87(1) no. 6 BetrVG applies because driver monitoring is suited to monitor behaviour, and §90(1) no. 3 requires early information. Driver monitoring by employers is also a GDPR issue, so the DPO and works council should negotiate a works agreement.

Support AI literacy (AI Act Art. 4): train reviewers on false positives and automation bias. Pilot on one site or mobile unit with dual review and publish precision figures. Address fairness concerns openly: the model never issues a sanction, two humans decide, and rejected images are deleted at once. See GUIDE-005, GUIDE-004, GUIDE-014.

Risks, regulation & compliance

• EU AI Act: do not assume a class. Annex III point 6 lists specific law-enforcement uses (e.g. risk assessment of persons, evidence reliability evaluation); detecting a traffic offence is not named as such, but classification must be assessed per deployment (Art. 6) and documented. Art. 5 prohibitions must be excluded in design: no real-time remote biometric identification in public spaces for law enforcement, no biometric categorisation or inference of sensitive traits, no profiling of individuals' criminal risk. Keep the system limited to action classification without identifying faces. Treat as a high-risk-equivalent control set anyway [5].
• Data protection: police processing falls under the Law Enforcement Directive (EU) 2016/680 as transposed in national police and traffic law, not the GDPR alone. A specific statutory basis for the capture and for storing suspected violations is needed; the Dutch system is reported to rely on a police-law basis (check the exact provision) and Rhineland-Palatinate had to amend its police law (§ 30 POG, in force since 1 March 2025) [1][3]. Check the national position in Germany with the Land data-protection authority.
• Data minimisation: on-device discard of non-suspects, short fixed retention, access logging, encryption, no secondary use, DPIA before launch.
• Due process: reviewable evidence, clear appeal path, error statistics published.
• Public acceptance: transparent signage and communication, independent evaluation.

Getting started

1. Confirm the statutory basis and competence of your authority; involve the data-protection officer and a DPIA from the start.
2. Run a time-limited pilot with one mobile unit and 100% officer review.
3. Define acceptance metrics (precision, false-positive handling) and an independent test set.
4. Design the evidence chain: four-eyes review, audit log, deletion jobs, appeal process.
5. Publish pilot results and decide on roll-out with the oversight body.

Sources

1. IETL — Monocam to detect the use of a mobile phone while driving — https://www.ietl.net/news-details/monocam-to-detect-the-use-of-a-mobile-phone-while-driving.html
2. Dutch police camera system to spot drivers using mobiles (trans.info) — https://trans.info/en/dutch-police-using-smart-camera-system-to-spot-drivers-using-mobiles-244274
3. teltarif.de — Monocam: cell phone speed camera registers more than 300 violations — https://www.teltarif.de/en/handy-blitzer-monocam-rheinland-pfalz/news/99015.html
4. Jerusalem Post — AI falsely accuses expert of using phone while driving — https://www.jpost.com/business-and-innovation/tech-and-start-ups/article-787534
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. ETSC — Netherlands to install more cameras to detect mobile phone use at the wheel — https://etsc.eu/netherlands-to-install-more-cameras-to-detect-mobile-phone-use-at-the-wheel/
7. Utrecht University — How the Dutch police aim to use algorithms responsibly — https://www.uu.nl/en/news/how-the-dutch-police-aim-to-use-algorithms-responsibly