In-Cab Driver Monitoring Video: Consent, Biometrics and Labels for DMS Models

This guide is for automotive DMS and occupant-monitoring computer vision teams buying footage from fleets, test programs or commissioned collections. It complements the broader video data hub and the road-facing dashcam fleet footage guide, where anonymizing faces and plates is the default.

Why driver monitoring footage cannot be anonymized

Driver monitoring models learn from exactly the features that anonymization removes, so the privacy control has to be consent rather than masking. Eyelid aperture, PERCLOS-style closure ratios, head pose, gaze vectors and mouth opening for yawns all come from the face region. Research on anonymized training data found that traditional methods such as blurring noticeably hurt model performance, and the cost depends on what is masked and how [8]; for a DMS, masking the face removes the label itself.

Synthetic face replacement (realistic face swapping) is sometimes proposed, but it alters the micro-geometry of eyes and lids that drowsiness detectors rely on. Treat it as a test you run, not an assumption. In practice, buyers should plan on licensing identifiable faces and building the deal around consent evidence, retention limits and access control. For the general framework on face-bearing media, see licensing image and video data that contains faces.

Biometric laws that apply to driver-facing video

Face geometry extracted from driver video is a biometric identifier under several US state laws, and each sets its own notice and consent rules. Illinois BIPA covers scans of face geometry and requires a written release and a publicly available retention schedule; as of October 2026, under the 2024 amendment, repeated collection of the same identifier from the same person by the same method counts as a single violation [3]. Texas Business and Commerce Code 503.001 requires informing the individual and receiving consent before capturing a record of face geometry for a commercial purpose [4]. Washington RCW 19.375.020 restricts enrolling biometric identifiers in a database for a commercial purpose without notice and consent or a mechanism to prevent later commercial use [5].

Litigation is the practical driver of buyer caution. IBM faced a biometric privacy suit over its Diversity in Faces dataset, which was built for AI training [6], and commentators note that biometric suits are an active risk for AI training data that contains faces [7]. Whether a raw video frame is itself a biometric identifier is contested; the safer assumption for buyers is that face-geometry extraction during training brings the footage into scope.

In the EU, the advanced driver distraction warning (ADDW) rules under Delegated Regulation (EU) 2023/2590 apply to new vehicle types from 7 July 2024 (and to all new vehicles from 7 July 2026) and include privacy and data protection requirements for in-vehicle systems [1]. Those rules govern the vehicle system, not your training set, but they explain why OEM and Tier 1 programs need training data that matches production camera placement and validation scenarios. Training-data processing of EU drivers is a separate GDPR question for counsel.

Consent design when the driver is also an employee

Fleet drivers are employees or contractors, so consent given to the employer that installed the camera rarely covers licensing the footage for third-party AI training. Many fleets record drivers for safety coaching under a workplace monitoring notice. That notice usually does not name AI training, a downstream licensee or biometric processing, and the power imbalance means "agree or lose the route" is weak evidence of voluntary consent.

Ask for consent that is separate from the employment safety program, names AI model training by third parties, lists the biometric processing, states retention and gives a working withdrawal route that does not affect pay or scheduling. Withdrawal must map to driver IDs in the delivered data so records can be pulled from future deliveries. The employee video consent guide and consent language for commissioned collection cover wording in more depth.

Illustrative example: invented to show structure; it does not describe an available dataset.

Label definitions DMS buyers should specify

Driver monitoring labels only transfer between datasets if every class has a written definition, a temporal rule and a frame-rate requirement. The DMD dataset, for example, covers distraction, gaze allocation, drowsiness, hands-on-wheel and context across 41 hours of RGB, depth and IR video of 37 drivers from three cameras [2]. Its authors identify the lack of large, comprehensive datasets as a bottleneck for DMS development [2], which is why commercial teams still license proprietary footage.

Specify each label at the level a reviewer can audit. Eye closure needs a threshold (for example, lid aperture below a percentage of open-eye baseline) and a minimum duration to separate blinks from microsleeps. Gaze zones need a fixed map (road ahead, mirrors, instrument cluster, infotainment, lap, passenger) tied to the camera mount. Phone use needs subclasses for handheld call, texting and holding without use, and hands-off-wheel needs a per-hand state.

Frame rate matters more than resolution for blink and microsleep work: 30 fps or higher is a common working assumption, and downsampled clips can lose short closures entirely. Ask for event segments with start and end timestamps rather than clip-level tags; the temporal action segmentation labels guide explains segment boundaries and agreement scoring.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "clip_id": "cab-000231",
  "driver_id": "drv-7f3a",
  "consent_ref": "consent-v3-2026-04",
  "camera": {"type": "NIR", "wavelength_nm": 940, "mount": "steering_column", "fps": 30},
  "conditions": {"time": "night", "eyewear": "sunglasses", "occlusion": "partial_hand"},
  "events": [
    {"label": "eyes_closed", "start_ms": 41200, "end_ms": 42150, "annotator_agreement": 0.92},
    {"label": "gaze_zone:infotainment", "start_ms": 50300, "end_ms": 52800},
    {"label": "phone_handheld_texting", "start_ms": 61000, "end_ms": 67400}
  ],
  "kss_self_report": 7
}

Camera, lighting and occlusion coverage

The most common failure in DMS training data is coverage that looks large but is concentrated in daytime, RGB, unoccluded drivers. Production systems typically use near-infrared illumination with a filtered sensor, so RGB-only footage needs domain adaptation before it helps. Ask for the distribution by camera type, mount position (steering column, A-pillar, rearview mirror), time of day, eyewear and occlusion.

Sunglasses that block visible light but pass NIR, eyeglass reflections, face masks, hats and hands on the face all change eye visibility. Request explicit coverage for each and for driver diversity in age, skin tone and facial hair, since these affect eye and landmark detection. Real drowsiness is rare in fleet footage, so ask how drowsy segments were obtained: naturalistic events, sleep-deprived study protocols, or simulator sessions. DMD itself mixes real and simulated driving [2], which is a reasonable design if the split is labeled.

Buyer checklist before licensing in-cab footage

A defensible DMS data purchase pairs per-driver consent evidence with a label specification and a coverage table you can test against. Use this checklist in diligence.

• Rights and consent: per-driver releases naming AI training and biometric processing; state of residence and recording; withdrawal log; passenger policy.
• Biometric compliance: BIPA retention schedule and destruction trigger; Texas and Washington notice evidence where relevant [3][4][5].
• Labels: written definitions, temporal thresholds, gaze-zone map, inter-annotator agreement, and a held-out QA sample.
• Coverage: NIR versus RGB, mount positions, night share, eyewear, occlusion, demographic spread, real versus simulated drowsiness.
• Documentation: machine-readable metadata such as Croissant-RAI for collection, labeling and use conditions [10]; risk mapping against the NIST AI RMF MAP and MEASURE functions [9].
• Delivery: access-controlled transfer and a format such as MP4/H.264 or MKV plus JSON or VCD annotations; see dataset delivery formats.

How SourceX handles driver-facing video requests

SourceX sources operational datasets, including new recordings of hands-on work, from US companies on request; nothing is held in stock and a request does not guarantee a match. Buyers describe the data they need, and SourceX looks for US businesses that hold it, with every release approved by the supplying company. Each dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, uses, term and delivery, through private, access-controlled workflows after an executed agreement.

SourceX removes or replaces personal details such as names, emails, phone numbers and account numbers before delivery and records the method, but for DMS footage the face itself is the training signal, so consent evidence carries the privacy load. You can describe your driver monitoring data needs on the buyers page. Teams sourcing broader video can also review licensed video recordings and logistics industry buyers.

Request driver-facing video for DMS training

SourceX sources operational datasets, including new recordings of hands-on work, from US companies on request, with rights review of ownership and consents and a license defining records, uses, term and delivery. Nothing is contracted until a supplier agrees. Start a driver monitoring data request.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.