This dimension governs the conditions, procedures, and technical requirements under which control authority transfers between an automated driving or logistics system and a human operator — whether that transfer is planned, unplanned, or emergency-initiated. Handoff governance is the single most safety-critical interface in any mixed-autonomy transport system: it is the boundary where automation ends and human judgement begins, and where incomplete state transfer, inadequate warning time, or operator unreadiness can translate directly into loss of life, infrastructure damage, or cargo catastrophe. Failure presents as a human operator who accepts nominal control authority without adequate situational awareness, a system that cannot complete a safe takeover request within minimum time budgets, or an automation stack that silently degrades below its certified operational design domain without triggering any transition protocol.
A Level 4 autonomous freight vehicle operating under a conditional automation approval on a 2,100-kilometre long-haul corridor encounters an unplanned lane closure caused by emergency roadworks 4.7 kilometres ahead. The system's object detection pipeline, degraded by heavy rain reducing lidar effective range from 300 m to 80 m, classifies the situation as outside its Operational Design Domain (ODD) 18 seconds before the merge decision point. The system issues a takeover request to the safety driver, who had been in monitoring mode for 6 hours and 43 minutes with no physical vehicle interaction. The takeover alert — a seat vibration and audible chime — triggers, but the system fails to transfer a compressed situational picture to the driver's display before requesting handoff acknowledgement. The driver acknowledges within 4 seconds, but the display still shows the pre-degradation sensor feed. The driver steers based on stale data, initiates an incorrect merge, and the 38-tonne vehicle makes contact with a temporary concrete barrier at 74 km/h. No fatalities, but the tractor unit sustains €340,000 damage and closes the interstate for 3 hours 20 minutes. The root failure: the handoff protocol required acknowledgement before state transfer was complete, and no minimum situational awareness standard existed in the operator approval conditions.
A robotaxi service operating under a German federal pilot permit enters a municipality that has issued a local ordinance restricting autonomous vehicle operation above SAE Level 2 without a licensed human operator physically present. The vehicle, operating with remote supervision from a control centre 180 kilometres away, is carrying two passengers when the jurisdiction boundary is crossed. The vehicle's geofence database has not been updated with the municipal ordinance, which was passed 11 days prior. Under the operating region's rules, the vehicle is now in non-compliant autonomous operation. No handoff is triggered because the system does not recognise the jurisdictional change. A local enforcement officer stops the vehicle. Because no remote-to-local handoff protocol exists between the remote supervisor and a physical standby driver, the passengers remain in a stationary vehicle on a live arterial road for 31 minutes while the incident is resolved. Consequential outcomes include regulatory sanction totalling €85,000, suspension of the operating permit for 60 days, and a parliamentary inquiry into cross-border autonomous vehicle governance. Root failure: absence of jurisdiction-aware handoff triggers and no defined handoff chain for regulatory stop events.
An automated straddle carrier operating in a mixed-traffic port environment receives a handoff request from the terminal management system when an unexpected pedestrian worker enters the vehicle exclusion zone. The system correctly identifies the incursion and initiates a stop-and-transfer sequence. However, the remote operator console — located in a control tower 850 metres from the incident — has a 2.4-second round-trip network latency due to congested terminal Wi-Fi. The handoff confirmation loop requires the remote operator to send an authenticated acknowledgement before the vehicle will remain stationary. The latency causes the vehicle's safety logic to interpret the delayed confirmation as a communication fault rather than a deliberate hold, and the vehicle's fail-operational mode resumes limited motion. The pedestrian is struck at low speed (< 6 km/h) and sustains a fractured tibia. The economic cost includes €1.2 million in workers' compensation, terminal shutdown for 14 hours, and a mandatory redesign of the handoff confirmation architecture costing an estimated €3.8 million. Root failure: handoff protocol did not account for network latency in confirmation loops, and fail-operational default was active under communication fault conditions in a pedestrian-mixed environment.
This dimension applies to any AI agent or autonomous system that exercises control authority over a physical transport vehicle or logistics asset — including road vehicles (autonomous, semi-autonomous, and remotely supervised), rail systems with automated driving functions, port and warehouse autonomous equipment, and unmanned aerial vehicles in supervised autonomous modes — wherever that system may transfer or receive control authority from a human operator or between automation levels. It applies whether the transfer is initiated by the system, by the operator, by a supervising fleet management platform, or by regulatory or emergency trigger. It applies across all operational contexts including planned route transitions, ODD boundary events, degraded sensor or compute states, communication faults, regulatory jurisdiction changes, driver fatigue protocols, and emergency stops. Organisations deploying such systems in single-jurisdiction, cross-border, or international contexts are subject to this dimension regardless of whether a human is physically co-located with the asset or operating remotely.
4.1.1 The system MUST maintain a continuously evaluated set of handoff trigger conditions that are defined prior to deployment, version-controlled, and reviewed at minimum every 90 days or upon any change to the system's ODD, sensor suite, or operating region.
4.1.2 Handoff trigger conditions MUST include, at minimum: ODD boundary approach or breach; sensor degradation below certified thresholds; compute resource exhaustion exceeding defined latency budgets; communication link quality falling below minimum acceptable parameters; detection of a situation type outside the system's training distribution; jurisdictional boundary crossing into a region with different autonomy permissions; and explicit operator or regulatory authority request.
4.1.3 The system MUST distinguish between three classes of handoff trigger — Planned, Unplanned, and Emergency — and MUST apply a distinct protocol for each class with documented time budgets appropriate to the class.
4.1.4 The system MUST NOT suppress or delay a handoff trigger event for operational convenience, schedule adherence, or efficiency reasons. Override of a handoff trigger by any software module other than a certified safety-critical supervisor MUST be logged, time-stamped, and reported to the fleet management platform within 60 seconds.
4.2.1 The system MUST define and document a Minimum Takeover Time Budget (MTTB) for each vehicle class and operational context in which it is deployed. The MTTB MUST be derived from empirical human factors data and MUST account for operator monitoring state (active, passive monitoring, or off-task), vehicle speed, environmental complexity, and available braking distance.
4.2.2 For Unplanned handoffs, the system MUST initiate the handoff sequence no later than the MTTB before the latest safe decision point — defined as the point beyond which the vehicle cannot safely stop or manoeuvre without human intervention. The system MUST NOT wait until the decision point to issue the handoff request.
4.2.3 For Emergency handoffs, if the operator does not provide a confirmed acknowledgement within the Emergency Response Deadline (ERD) — which MUST be defined for each context and MUST be no longer than 10 seconds — the system MUST autonomously execute a Minimal Risk Condition (MRC) manoeuvre without waiting for human confirmation.
4.2.4 The system MUST log actual handoff response times for every transfer event and MUST generate a monthly statistical summary of MTTB compliance rates. MTTB compliance rate MUST NOT fall below 99.5% across any rolling 30-day period.
4.3.1 The system MUST transfer a complete situational awareness package to the receiving operator before or simultaneous with the handoff confirmation request. Transfer of control authority MUST NOT be completed before situational awareness transfer is acknowledged or a defined timeout expires.
4.3.2 The situational awareness package MUST include, at minimum: current vehicle state (speed, heading, position, load status); active sensor health status; reason for handoff trigger; environmental context summary (road geometry, detected objects, weather); remaining safe operational margin (distance or time to MRC point); and any jurisdiction-specific constraints active at the current location.
4.3.3 The system MUST provide the situational awareness package in a format that can be fully processed by a qualified operator within a time period no greater than 60% of the MTTB, leaving the remaining 40% for the operator to physically assume control.
4.3.4 Where network latency between a remote operator console and the vehicle exceeds 500 milliseconds round-trip, the system MUST adjust the handoff initiation time to compensate, ensuring that the effective operator response window is not compressed below the minimum defined in 4.2.1.
4.3.5 The system MUST NOT present a handoff interface that requires the operator to acknowledge situational awareness before the awareness data has been fully rendered and is readable. Acknowledgement prompts MUST be inhibited until display rendering is confirmed complete.
4.4.1 The system MUST verify operator readiness state before issuing a Planned handoff request and MUST record the readiness determination method (physiological monitoring, activity detection, verbal check-in, or certified attestation).
4.4.2 For Unplanned handoffs, if operator readiness cannot be confirmed within the first 25% of the MTTB, the system MUST escalate the alert modality — from single-channel to multi-channel (visual, auditory, and haptic simultaneously) — and MUST begin computing the MRC trajectory in parallel.
4.4.3 The system MUST maintain an operator fatigue and engagement model that is continuously updated during periods of automation-in-command. This model MUST be used to adjust MTTB dynamically when operator readiness is assessed as degraded.
4.4.4 The system MUST provide a mechanism by which the operator can proactively declare reduced readiness. Upon receipt of a reduced-readiness declaration, the system MUST either: transfer to a higher automation level if capable; reduce speed to a level consistent with increased MTTB; or initiate a Planned handoff to an alternative operator or MRC. The system MUST NOT continue in the current automation mode with no adjustment when reduced readiness is declared.
4.4.5 Remote operator consoles MUST implement session continuity controls that detect console abandonment — defined as no operator input or confirmed presence for more than 45 seconds — and MUST automatically escalate supervision coverage to an alternate qualified operator within 90 seconds of abandonment detection.
4.5.1 The system MUST maintain a jurisdiction database that is updated at minimum every 24 hours from an authoritative regulatory data source and MUST include the autonomy permission level, operator presence requirements, maximum automation level, and any special conditions for each operational zone in the vehicle's planned and contingency route.
4.5.2 The system MUST evaluate jurisdictional handoff requirements no less than 2 kilometres (or 60 seconds at current speed, whichever is greater) before crossing any jurisdiction boundary that changes the permitted automation level or operator requirements.
4.5.3 Where a jurisdiction boundary requires a reduction in automation level, the system MUST initiate a Planned handoff sequence with sufficient time to complete the transition before the boundary is crossed. The vehicle MUST NOT cross the boundary in a non-compliant automation state.
4.5.4 Where an unplanned jurisdiction entry occurs — due to route deviation, emergency detour, or database gap — the system MUST immediately initiate an Unplanned handoff sequence and MUST log the event as a jurisdictional compliance incident within 30 seconds of detection.
4.5.5 The system MUST be capable of producing a machine-readable jurisdictional compliance record for any journey segment on demand by a regulatory authority, including the automation level active at every point, the operator identity and certification status, and the timestamp of any automation level transitions.
4.6.1 The system MUST define explicit behaviour for each class of communication fault — degraded bandwidth, intermittent link, complete link loss — and MUST document the corresponding handoff or MRC behaviour for each class.
4.6.2 For remotely supervised vehicles, the system MUST implement a Communication Loss Protocol (CLP) that specifies the maximum time the vehicle may continue in its current automation mode following confirmed communication loss. This maximum MUST NOT exceed 30 seconds for vehicles operating in mixed-traffic environments and MUST NOT exceed 120 seconds for vehicles operating in segregated or geofenced environments.
4.6.3 Upon expiry of the CLP timer without communication restoration, the system MUST execute a Minimal Risk Condition manoeuvre autonomously. The MRC manoeuvre MUST be appropriate to the environment type and MUST NOT require remote operator confirmation if communication is lost.
4.6.4 The system MUST NOT treat handoff confirmation latency caused by network delay as operator non-response unless the latency-adjusted timeout has expired. The system MUST distinguish between network-caused delay and operator inaction in its fault classification logic.
4.7.1 The system MUST create a complete, tamper-evident, time-stamped log record for every handoff event, including trigger type, trigger cause, MTTB applicable, actual response time, situational awareness transfer confirmation, operator identity and certification reference, and final control authority state.
4.7.2 Handoff logs MUST be retained for a minimum of 7 years for vehicles operating in commercial or public-road contexts and MUST be stored in a format that can be recovered and read without the original vehicle's systems.
4.7.3 The system MUST generate a real-time alert to the fleet management platform within 10 seconds of any handoff event that: exceeds the defined MTTB; results in an MRC manoeuvre; involves a jurisdiction compliance incident; or results in a collision or near-miss event.
4.7.4 Handoff log data MUST be structured to support third-party forensic audit without requiring access to proprietary system internals. Log schema MUST be documented and made available to regulatory authorities upon request.
4.8.1 The system MUST have a certified MRC execution capability that is independent of the primary autonomy stack and MUST be capable of bringing the vehicle to a safe stopped state in the operational environment without reliance on external communication or operator input.
4.8.2 The MRC manoeuvre library MUST include, at minimum: gradual controlled deceleration to stop in the current lane; emergency lane or shoulder pull-over where available and safe; and sustained stationary hold with hazard signalling active.
4.8.3 The system MUST NOT execute an MRC manoeuvre that creates a secondary hazard — including stopping on a railway crossing, in a tunnel without a refuge, or in an active pedestrian crossing — unless all alternatives have been exhausted and continued motion would create greater risk.
4.8.4 Following completion of an MRC manoeuvre, the system MUST remain in a stationary, communication-active, hazard-signalling state until a qualified operator with confirmed credentials assumes control or until an authorised recovery instruction is received from the fleet management platform.
4.9.1 The system MUST verify the identity and current certification status of the operator receiving control before completing any handoff that transfers authority from automation to human control. Verification MUST use a credential that cannot be transferred between individuals and MUST be validated against an authoritative certification registry.
4.9.2 The system MUST NOT complete a handoff to an operator whose certification has expired, been suspended, or is not valid for the current jurisdiction or vehicle class. In such cases, the system MUST treat the handoff as failed and MUST execute the applicable fallback protocol.
4.9.3 For remote operator consoles supervising multiple vehicles simultaneously, the system MUST enforce a maximum concurrent vehicle supervision limit that is defined by the operator's certification terms and MUST alert the operator and fleet platform when this limit is approached within one vehicle of the maximum.
4.9.4 Operator certification records MUST be retained for a minimum of 10 years from the date of last operational use and MUST be accessible to regulatory authorities within 48 hours of a formal request.
The handoff moment between automation and human control is categorically different from all other governance challenges in autonomous transport because it is inherently a timing-constrained event in a physical system where failure consequences are immediate and often irreversible. Unlike a data quality error or a biased recommendation that can be corrected in subsequent interactions, a failed or delayed handoff in a vehicle travelling at 90 km/h produces consequences measured in metres and milliseconds, not weeks and dashboards.
Structural controls — pre-defined trigger conditions, MTTB budgets, MRC libraries, and communication loss protocols — are necessary precisely because behavioural or best-efforts governance cannot operate at the speed and reliability required. A policy that says "operators should respond promptly" provides no protection when an operator has been monitoring a steady-state highway drive for seven hours. A structural MTTB requirement, enforced in hardware and software with automatic MRC fallback, does. This is the core reason the dimension is classified as Preventive rather than Detective: by the time a handoff failure is detectable in outcome data, the physical consequences have already occurred.
Purely behavioural controls — training programmes, operator protocols, pre-shift briefings — address the mean case of operator behaviour but provide inadequate protection against the tail events that dominate transport safety statistics. Human factors research across aviation, maritime, and automotive contexts consistently demonstrates that operator vigilance degrades predictably under passive monitoring conditions; that reaction time to unexpected alerts is significantly longer than to expected ones; and that the cognitive transition from passive monitoring to active control is itself a performance-degrading event that requires time, sensory cues, and information. These are not operator failures — they are human physiological characteristics that system design must accommodate structurally.
The requirement for automatic MTTB adjustment based on operator engagement modelling (4.3.4, 4.4.3) reflects this understanding: the time budget available for a handoff is not a fixed number derived from average human reaction time under ideal conditions but a dynamically adjusted safety margin that accounts for the actual readiness state of the specific operator in the specific moment.
The cross-border dimension introduces a compounding risk layer that is unique to this landscape. A vehicle that is fully compliant under one jurisdiction's autonomy rules may be operating illegally seconds later when it crosses an administrative boundary — and may have no mechanism to detect this if its jurisdiction database is stale. The 11-day database lag in Example B produced a regulatory incident that grounded a pilot programme for two months. The jurisdictional compliance requirements in Section 4.5 are not administrative formalities: they are the mechanism by which a physical system operating across regulatory boundaries maintains continuous legal and safe operating status.
Detection and correction controls assume that there is time to detect a failure and respond before consequences escalate. In handoff governance, the window between trigger and consequence may be as short as 10–20 seconds. The 2.4-second network latency that caused the straddle carrier injury in Example C — an event that would be considered negligible in an enterprise software context — was the decisive factor in a physical injury event. Prevention, expressed as latency-compensated handoff initiation, structural MRC fallback, and confirmed state transfer before authority change, is the only control architecture capable of operating reliably within these time constraints.
Layered Alert Escalation Architecture Implement handoff alerts as a layered sequence, beginning with single-modality alerts at the outer edge of the MTTB, escalating to multi-modal simultaneous alerts (visual, auditory, haptic) as the response window closes, and transitioning to automatic MRC initiation at the ERD boundary. Each layer should be independently implemented, tested, and certified so that failure of any single alert channel does not prevent escalation. Alert fatigue is a real risk in high-frequency planned-handoff environments; calibrate alert frequency and intensity to avoid habituation.
State Transfer Before Authority Transfer Implement a two-phase handoff protocol: Phase 1 transfers the situational awareness package and begins operator orientation; Phase 2 transfers control authority only after the operator has confirmed situational awareness receipt or a defined awareness timeout has expired. In Phase 1, the automation remains in command. This pattern directly addresses the most common handoff failure mode — authority transfer before awareness transfer — documented in aviation controlled flight into terrain accidents and increasingly appearing in autonomous vehicle incident reports.
Jurisdiction Database as a First-Class Safety Asset Treat the jurisdiction database with the same rigour as the vehicle's safety-critical firmware. Implement cryptographic signing of database records, versioned updates with rollback capability, mandatory update verification before each journey segment, and out-of-range alerts when a planned route enters a zone not present in the current database. The database should be updated from multiple authoritative sources with conflict resolution rules and provenance tracking.
Latency-Aware Remote Supervision Architecture For remote operator consoles, implement continuous round-trip latency measurement and dynamically adjust handoff initiation timelines to compensate. Store latency measurements in the handoff log alongside response times so that forensic analysis can distinguish between operator inaction and network-induced delay. Implement local-first decision authority for safety-critical manoeuvres: the vehicle's onboard safety supervisor should not require round-trip confirmation from a remote console before executing an emergency stop.
Operator Fatigue and Engagement Modelling Implement a continuous operator state model that ingests physiological signals (where available), interaction frequency, time-on-task, and environmental complexity to produce a real-time readiness index. Use this index to dynamically adjust MTTB and alert threshold timing. Where the readiness index falls below a calibrated threshold, initiate a mandatory engagement check before the system encounters conditions that might require handoff. This is not a replacement for roster management — it is a real-time safety layer that operates within a single duty period.
MRC Manoeuvre Library Versioning and Simulation Testing Maintain the MRC manoeuvre library as a versioned, independently deployable module. Test each MRC manoeuvre type in simulation across the full range of operating environments at minimum annually and upon any change to the vehicle's dynamics profile, payload envelope, or operational environment. Document MRC execution test results and retain them as certification artefacts. The MRC module should be architecturally isolated from the primary autonomy stack so that a failure in the autonomy stack does not impair MRC capability.
Graduated Autonomy Levels as Handoff Buffering Design the automation stack to support intermediate autonomy levels — such as automation-assisted driving below the full ODD capability level — that can serve as a buffer state during handoff transitions. Rather than a binary automation-on/human-in-control transition, a graduated step-down through intermediate levels provides additional time for the operator to build situational awareness before assuming full authority. This pattern is well-established in aviation as the Continuous Authority Management model.
Acknowledgement-First Handoff Protocols Do not design handoff UX that requests operator acknowledgement before situational awareness data has been transferred and rendered. This pattern — common in early autonomous vehicle implementations — creates a false confirmation loop where the operator has pressed "accept" but is not yet aware of the conditions they are accepting. The confirmation should be the endpoint of awareness transfer, not the beginning.
Static MTTB Values Do not implement a single fixed MTTB for all conditions. A MTTB derived from controlled-environment testing at steady-state highway speeds with an alert operator is not valid for a fatigued operator in an urban intersection at night during adverse weather. MTTB must be a computed value that reflects the actual safety margin required in the actual operating context.
Fail-Operational Defaults in Mixed-Traffic Environments Do not configure fail-operational mode as the default response to communication faults in environments where pedestrians, cyclists, or unmanaged vehicles are present. The straddle carrier incident in Example C illustrates precisely why a fail-operational default that resumes motion on communication fault is not safe in mixed-traffic contexts. Reserve fail-operational modes for segregated environments with independent pedestrian exclusion systems, and implement fail-safe (stop-in-place) as the default in all other contexts.
Monolithic Handoff Protocol Do not implement a single handoff procedure that applies identically to planned, unplanned, and emergency events. The time budgets, alert intensities, state transfer depths, and MRC decision thresholds are fundamentally different for each event class. A monolithic protocol will either be too slow for emergency events or too disruptive for planned transitions.
Jurisdiction Database Updated Only at Journey Start Do not load jurisdiction data only at the beginning of a journey and treat it as static for the duration. Routes change, emergency detours occur, and regulations are updated with short notice. The jurisdiction database must be treated as a live data feed with continuous update capability and staleness detection.
Remote Operator Console Without Latency Compensation Do not design remote operator confirmation loops without accounting for network latency in safety-critical timing calculations. A console that displays "operator response time: 1.8 seconds" without subtracting measured network latency is producing misleading safety metrics that may conceal a genuine operator response failure.
Operator Certification Checked Only at Session Start Do not perform operator certification verification only at the beginning of a shift or remote session. Certifications can be suspended in real time due to incident investigation, medical events, or regulatory action. Implement periodic re-verification at intervals no greater than 2 hours during active supervision and on-demand verification at the point of each handoff.
| Maturity Level | Characteristics |
|---|---|
| Level 1 — Defined | Documented handoff procedures exist; static MTTB; manual jurisdiction compliance check; single-modality alerts; basic handoff logging |
| Level 2 — Managed | Layered alert escalation; two-phase state-then-authority transfer; jurisdiction database automated updates; MTTB compliance metrics tracked; MRC capability certified and tested |
| Level 3 — Optimised | Dynamic MTTB with operator engagement model; latency-compensated remote supervision; graduated autonomy buffering; real-time jurisdiction compliance enforcement; cross-fleet handoff analytics; regulatory machine-readable compliance records |
| Level 4 — Autonomous Safety | Predictive handoff initiation based on ODD degradation forecasting; continuous physiological operator readiness monitoring; self-updating MRC library from simulation; automated regulatory submission of compliance records; federated cross-operator handoff analytics |
Handoff Trigger Condition Register A versioned document listing all defined trigger conditions for Planned, Unplanned, and Emergency handoffs, including the derivation basis, the responsible approver, and the review history. Must be reviewed every 90 days or upon any system change. Retention: life of system plus 10 years.
Minimum Takeover Time Budget Documentation For each vehicle class and operational context, a documented MTTB derivation including the human factors data sources used, the operator monitoring state assumptions, the environmental conditions modelled, and the validation methodology. Retention: life of system plus 10 years.
Handoff Event Logs Tamper-evident, time-stamped logs for every handoff event as specified in Section 4.7. Must include trigger type, trigger cause, MTTB applicable, actual operator response time, situational awareness transfer confirmation timestamp, operator identity and certification reference, control authority state before and after, and any MRC or fallback action taken. Retention: 7 years minimum; 10 years for events resulting in incidents or regulatory contact.
MTTB Compliance Monthly Report A monthly statistical summary of MTTB compliance rates across all handoff events for each vehicle class, flagging any rolling 30-day period where compliance falls below 99.5%. Must be retained and available for regulatory audit within 5 business days of request. Retention: 7 years.
Jurisdiction Database Version Records Records of each jurisdiction database version active during any given journey, including the version timestamp, source authority, and any coverage gaps identified. Retention: 7 years.
MRC Manoeuvre Library Certification Records For each certified MRC manoeuvre type, simulation and (where applicable) physical test results demonstrating safe execution across the defined range of operating conditions. Must include pass/fail criteria and tester identity. Retention: life of system plus 10 years.
Operator Certification Records Records of operator identity, certification type, certification status, issuing authority, validity period, and suspension or restriction events, for every operator who has received or transmitted handoff authority on any vehicle covered by this dimension. Retention: 10 years from date of last operational use.
Communication Fault Incident Reports For each communication fault that triggered or affected a handoff event, a structured incident report including fault duration, latency measurements, vehicle state during fault, response taken, and outcome. Retention: 7 years.
Handoff Protocol Design Documentation Architecture documentation sufficient to demonstrate that the two-phase state-then-authority transfer design, latency compensation, operator readiness verification, and MRC independence have been implemented as specified. Must be updated upon any material system change. Retention: life of system plus 10 years.
Third-Party Forensic Audit Package A documented log schema and data dictionary enabling a qualified third party to conduct forensic audit of any handoff event without access to proprietary system internals. Must be made available to regulatory authorities within 48 hours of formal request. Retention: life of system plus 10 years.
Maps to: 4.1.1, 4.1.2, 4.1.3 Objective: Verify that the handoff trigger condition register is complete, version-controlled, covers all mandatory trigger types, and correctly classifies triggers into Planned, Unplanned, and Emergency classes. Method: Document review against the mandatory trigger condition list in 4.1.2. Inject simulated trigger events for each mandatory condition type in a controlled test environment and verify that the system correctly classifies and responds to each. Verify version control history shows review within the last 90 days or since last system change, whichever is more recent. Pass Criteria:
Maps to: 4.2.1, 4.2.2, 4.2.3, 4.2.4 Objective: Verify that MTTB values are derived from empirical data, are contextually differentiated, and that the system initiates handoff sequences within the required time margins. Method: Review MTTB documentation for derivation basis and human factors data sources. In a controlled operational test (simulation or closed-course), inject Unplanned trigger conditions at defined distances from a decision point and measure the time between trigger detection and handoff initiation. Inject Emergency trigger conditions and measure time to MRC execution when no operator response is provided. Review 30-day MTTB compliance reports. Pass Criteria:
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Driver and Operator Handoff Governance implements a specific risk mitigation measure within this framework. The regulation requires that risks be mitigated "as far as technically feasible" using appropriate risk management measures. For deployments classified as high-risk under Annex III, compliance with AG-544 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-544 supports compliance by establishing structural governance boundaries that implement the framework's approach to AI risk management.
Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Clause 8.2 requires AI risk assessment. Driver and Operator Handoff Governance implements a risk treatment control within the AI management system, directly satisfying the requirement for structured risk mitigation.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide — potentially cross-organisation where agents interact with external counterparties or shared infrastructure |
| Escalation Path | Immediate executive notification and regulatory disclosure assessment |
Consequence chain: Without driver and operator handoff governance, the governance framework has a structural gap that can be exploited at machine speed. The failure mode is not gradual degradation — it is a binary absence of control that permits unbounded agent behaviour in the dimension this protocol governs. The immediate consequence is uncontrolled agent action within the scope of AG-544, potentially cascading to dependent dimensions and downstream systems. The operational impact includes regulatory enforcement action, material financial or operational loss, reputational damage, and potential personal liability for senior managers under applicable accountability regimes. Recovery requires both technical remediation and regulatory engagement, with timelines measured in weeks to months.