At 11:47 PM on a Tuesday in February, a dispatcher at a 90-truck regional carrier got a phone call she never wants to get again. Driver Kowalski was on I-70 outside Salina, Kansas, out of hours, 38 miles from the nearest truck stop, with a load of refrigerated product that had to hit a distribution center in Denver by 6:00 AM. The AI-assisted dispatch optimizer had proposed the run. The dispatcher had accepted it. The HOS (hours of service) check had been skipped because the tool showed green on the dashboard and she trusted it. The optimizer had a calibration error that was pulling stale hours data from the ELD (electronic logging device) sync. Driver Kowalski was legally parked on the shoulder. The product was at risk. The shipper was about to be furious. And nobody at the carrier had a documented plan for what happened next. This lesson is the documented plan.

Defining an AI-Related Incident in Freight

An AI-related incident in fleet operations is any event in which an AI tool's output, recommendation, or failure to flag contributed to a safety event, a regulatory violation, an operational failure, or significant financial harm. The definition is deliberately broad because the causal chain between an AI output and a harmful outcome is not always obvious at first. The optimizer that pulled stale hours data did not directly strand Driver Kowalski. It generated a recommendation. The dispatcher accepted it. The ELD sync was not working. The driver ran out of hours. Each link in that chain is real, and a narrow definition of "AI-related incident" that focuses only on direct causation will miss events where AI was a contributing factor in a chain that a human could have broken if the governance structure had been stronger.

For a practical fleet incident response runbook, incidents are classified on a two-axis severity framework. The first axis is safety impact: did the event affect, or create material risk to, a driver, the public, or other road users? The second axis is compliance impact: did the event produce or create material risk of an HOS violation, a CSA (Compliance, Safety, Accountability) point, a DVIR (driver vehicle inspection report) failure, or FMCSA (the Federal Motor Carrier Safety Administration) regulatory contact?

Severity 1 (Critical): The incident involves a driver safety event (accident, stranding, or medical emergency) attributable in whole or in part to an AI-assisted decision, or an HOS violation on a load the AI optimizer proposed and the dispatcher accepted without independent HOS verification, or a vehicle dispatched over an AI-assisted DVIR review that missed a defect that caused a breakdown or an out-of-service violation. Severity 1 events require immediate response, immediate escalation to the fleet owner, and mandatory FMCSA notification where required by regulation.

Severity 2 (Significant): The incident involves an AI tool recommendation that, if acted upon, would have produced a Severity 1 event but was caught by human review before commitment, or a pattern of AI tool errors discovered in retrospect that affected more than one dispatch or maintenance decision even if no immediate safety event resulted. Severity 2 events require prompt investigation within 24 hours and a root cause report within 72 hours.

Severity 3 (Notable): A single AI tool recommendation that was clearly wrong, was caught by the dispatcher or technician before harm, and does not show a pattern. Severity 3 events are documented, added to the open findings register, and reviewed at the next monthly Council meeting. They do not require immediate escalation.

The most important point about this classification: every event starts at the highest plausible severity and gets downgraded as evidence accumulates, not the other way around. A dispatcher who gets a bad AI recommendation at 11 PM does not have time to investigate whether it is Severity 2 or Severity 3 before deciding whether to wake up the fleet owner. The default is to escalate and downgrade, not to wait and see.

The Incident Response Runbook: Phase by Phase

The runbook is the operationalized version of the governance practice's incident response commitment. It is a written, step-by-step procedure that any dispatcher, safety manager, or fleet manager can execute at 11:47 PM without having to improvise. It lives in the TMS (transportation management system), in the safety department's shared drive, and in a laminated one-page version on the dispatch board. It is not a policy. It is a checklist. Here is the full runbook, phase by phase.

Phase 1: Contain (0 to 60 Minutes)

The goal of Phase 1 is to stop the immediate harm and protect affected people and assets. For a driver stranded by an HOS violation: dispatch a rescue plan, whether a relay driver, a tow to a compliant rest location, or a direct communication protocol to ensure the driver is legally parked and safe. For a vehicle dispatched with a missed DVIR defect: issue an immediate hold on that unit in the TMS, notify the driver by phone, and coordinate with the nearest shop or service point. For a batch of AI-generated dispatch plans that may contain the same calibration error: hold all AI-proposed plans in the queue pending manual review. The contain action does not wait for classification. If a driver is at risk, contain first and classify second.

Parallel to containment, the dispatcher or first responder preserves the record. This means: take a screenshot of the AI tool's output at the time of the event (including the timestamp and version indicator if visible); save the TMS record showing the committed plan and the confirmation timestamp; note the ELD sync status at the time the plan was committed; and note any anomalies in the tool's dashboard that were visible before the event. This evidence is perishable. Systems get updated. Logs get overwritten. The first person who knows about the incident has a 60-minute window to capture evidence that may take weeks to reconstruct later.

At the end of Phase 1, the first responder classifies the incident at the highest plausible severity and initiates the escalation chain. For Severity 1 and Severity 2 events: the fleet owner or the person in the on-call escalation chain must be notified by phone, not by text, not by email, before the 60-minute mark. The governance charter must specify who is on that chain, in order, with current contact information. A contact list that was last updated in 2024 is not an escalation chain. It is an out-of-date spreadsheet.

Phase 2: Investigate (1 to 72 Hours)

Phase 2 begins when the immediate safety situation is stable and the record is preserved. Its goal is to establish, with evidence, exactly what happened and what role the AI tool played. The investigation must answer five specific questions:

Question 1: What did the AI tool recommend, precisely? Not a paraphrase. The exact output: the load match proposed, the hours calculation shown, the alert generated or not generated, the maintenance recommendation or its absence. If the tool's output is not retrievable from the TMS or the tool's own log, that is itself a finding: the fleet's governance practice does not retain AI output records in a form that supports investigation.

Question 2: What did the human do with the recommendation? Did the dispatcher accept without modification? Override and then accept? Miss the recommendation entirely because the dashboard was presenting data in a way that made the problem invisible? The dispatcher's actions are not a judgment question at this stage. They are an evidentiary question. The investigation is establishing what happened, not who to blame.

Question 3: What verification steps were performed and what did they find? Was the HOS gate executed? What did it show? Was the ELD sync status checked? Was the DVIR review AI-assisted, and if so, what did the review output show before the vehicle was dispatched? Any verification step that was specified in the governance runbook and was not performed is a finding, not an excuse.

Question 4: What was the tool's technical state at the time of the event? Was the model running the current production version? Was there a recent update that changed the tool's behavior? Were there known anomalies or alerts in the tool's performance dashboard in the days before the event? For optimizers that pull data from the TMS or the ELD via API: was the data connection functioning correctly, and when was the last successful sync? The Driver Kowalski scenario in this lesson's opening turned on a stale ELD sync. Establishing the tool's technical state is not optional.

Question 5: Is this a one-time error or a pattern? If the optimizer pulled stale hours data for Driver Kowalski, it may have done so for other drivers on other loads. The investigation must check: are there other loads in the same time window where the ELD sync may have been stale? Are there other loads where the optimizer's hours calculation differs from the ELD record? A one-time error produces a Severity 3 finding. A pattern produces a Severity 1 finding and a mandatory hold on all AI-proposed loads until the pattern is resolved.

The investigation is documented in real time, not reconstructed after the fact. The investigator keeps a running log with timestamps, source references for every piece of evidence, and the names of every person interviewed. This log becomes the root cause report, the governance record, and, if needed, the carrier's defense in a regulatory or liability proceeding.

Phase 3: Communicate (Ongoing from Phase 1)

Communication in an AI-related incident has four audiences with different needs and different timelines. Getting the audience wrong produces either a panicked driver who does not know what to do, or a fleet owner who finds out about a Severity 1 event from a shipper before they hear it from their own team.

The driver: The first call. Before anything else, if there is a driver in a difficult situation because of the event, they need to know: what to do right now, that the fleet is taking care of the problem, and that they will not be blamed for following a dispatch plan the carrier committed. A driver who has been stranded and then ignored is a driver who is calling a recruiter in the morning. The 80,000-driver shortage is not an abstraction at 11:47 PM on I-70.

The fleet owner or on-call escalation contact: By phone, within 60 minutes, for any Severity 1 or Severity 2 event. The message should be: what happened (one sentence), what the immediate containment action is (one sentence), what the preliminary severity classification is (one sentence), and what the next update time will be (one sentence). Four sentences. The owner does not need a root cause analysis at midnight. They need to know the situation is being handled and when they will hear more.

The shipper or customer: Only after the fleet owner has been notified. The communication should be honest, calm, and operationally focused: there is a delay, the carrier is managing it, the updated delivery time is X. No carrier should tell a shipper that an "AI problem" caused the delay before they have completed Phase 2 investigation and established what actually happened. "Our optimizer had a calibration error" is a statement for the root cause report and the governance record, not for a midnight shipper call.

FMCSA and regulatory bodies: Only when required by regulation, only after the fleet owner and legal counsel have been consulted, and only with the language the owner and counsel have approved. An HOS violation on a single load does not automatically require a regulatory notification beyond the standard ELD record. A pattern of HOS violations on AI-proposed loads that was discovered during investigation may trigger different obligations. Carriers should establish in the governance charter which regulatory notifications are mandatory for which event types, and who has authority to make them.

Phase 4: Remediate and Close (72 Hours to 30 Days)

Remediation is the set of actions that prevents the same event from happening again. It is specific, it has a named owner, and it has a deadline. A remediation plan that says "improve the HOS verification process" is not a remediation plan. A remediation plan that says "the VP of Operations will complete a reconfiguration of the ELD sync interval in the optimizer from 4 hours to 15 minutes by June 30, will document the reconfiguration in the tool inventory entry, and will present evidence of the change to the Council at the July monthly meeting" is a remediation plan.

Remediation actions fall into three categories. Technical remediation addresses the tool itself: recalibrating the optimizer, restoring the ELD sync interval, correcting the DVIR alert threshold, updating the model version, or implementing a change to the tool's configuration that prevents the failure mode from recurring. Process remediation addresses the human workflow: adding a manual HOS cross-check as a required step before committing any AI-proposed load, requiring technician sign-off on any AI-assisted DVIR review before dispatch, or implementing a pre-commit checklist that the dispatcher must complete before a plan is locked in the TMS. Governance remediation addresses the oversight structure: updating the open findings register, revising the governance charter if the incident revealed a gap in its scope or authority, scheduling a tabletop exercise on the identified failure mode, or adding a new monitoring metric to the tool inventory entry.

Closure requires evidence, not the passage of time. The finding is not closed when the remediation action is technically complete. It is closed when the Council reviews evidence that the failure mode has been addressed and the monitoring data from the subsequent period does not show recurrence. For the Driver Kowalski scenario: the finding is not closed when the ELD sync interval is reconfigured. It is closed when four weeks of monitoring data show that the optimizer's hours calculations are matching ELD records within the expected tolerance, the reconfiguration is documented in the tool inventory, and the Council has accepted the evidence at a monthly meeting.

Preserving the Audit Trail: Making the Response Defensible

A well-executed incident response produces three things: a contained situation, a remediated root cause, and a defensible record. The third is as important as the first two, because the carrier that cannot reconstruct what happened, what it did about it, and how it prevented recurrence is in a worse regulatory position than the carrier that had the event in the first place.

The incident record must contain, in a retrievable form: the initial detection timestamp and the identity of the first responder; the containment actions taken, with timestamps; the classification decision with the reasoning; the escalation chain execution, with confirmation that each person in the chain was notified and when; the complete investigation documentation including all five questions answered with evidence; the root cause statement (not a guess, not a vendor explanation accepted at face value, but the investigated and evidenced cause); the remediation plan with named owner and deadline; the evidence of remediation completion; and the Council's formal close of the finding with the date and the names of the members who voted.

This record should be stored in a location that is: persistent (not a personal email thread), access-controlled (not a shared drive anyone can edit or delete), and retrievable (organized so the specific incident record can be found and produced in response to an FMCSA request within one business day). Many carriers already have a document management system that can serve this function. The question is whether the incident response record is being treated as a governance document requiring these properties, or as an internal email chain that will be forgotten in ninety days.

The audit trail also requires that the carrier can demonstrate the difference between an AI-proposed decision and a human decision in the TMS record. This connects directly to the governance practice covered in the preceding lesson: the dispatcher confirmation log must flag AI-proposed versus human-initiated assignments. Without this flag, an audit of a HOS violation cannot establish whether the optimizer or the dispatcher produced the illegal plan, and the carrier cannot defend the boundary between AI recommendation and human accountability.

The carrier that can reconstruct a bad event, show what it did about it, and prove it prevented recurrence is the carrier that survives the audit. The carrier that cannot reconstruct it is the one that faces the safety fitness determination review.

Special Scenarios: Autonomous Capacity and Missed Defect Events

Two incident scenarios in 2026 freight deserve specific treatment because they involve governance questions that did not exist five years ago.

An incident on an autonomous lane booked through the TMS. Aurora's 250,000 driverless miles and its McLeod TMS integration serving 1,200-plus fleets have made autonomous capacity booking a real operational event for a growing number of carriers. When something goes wrong on a driverless lane, the carrier faces a new version of the AI accountability question: did the incident result from Aurora's autonomous system, from the carrier's booking decision (which may have been AI-assisted), from the TMS integration, or from some combination? The carrier's incident response runbook must address this scenario specifically. The key governance points are: the carrier's booking and dispatch decision for an autonomous lane is within its own AI governance scope regardless of who operates the vehicle; the carrier must preserve the same evidence from the TMS booking record as it would from a human dispatch decision; and the carrier must have a defined protocol for communicating with Aurora's operations team in the event of an incident, including the named contacts and the expected response timeline. Carriers using Aurora or similar services should request this protocol from the vendor before they need it, not the morning after.

An AI-assisted maintenance review that missed a defect. An AI-assisted DVIR review system flags items for technician follow-up. A technician reviews the AI output, does not find an issue, and the vehicle is dispatched. The vehicle has a defect that the AI missed, and the defect results in a roadside breakdown or an out-of-service violation. This is a Severity 1 event regardless of who is nominally responsible for the DVIR. The carrier's incident response for this scenario must investigate: what did the AI output show; what was the technician's review process; was the technician's review independent or was it anchored to the AI output (a form of automation bias where a technician assumes the AI would have caught anything important); and does the fleet's DVIR AI tool have a documented accuracy rate for the defect type that was missed. The predictive maintenance economics the program has tracked throughout, approximately 34% cost savings on a 44-day payback, are contingent on the AI actually catching defects. A DVIR AI tool that is producing automation bias in technicians is not producing those economics. The investigation must establish whether the tool is performing to its stated accuracy, and whether the training and process around technician review is creating a false sense of AI reliability.

Key Takeaways

• An AI-related incident in freight is any event where an AI tool's output, recommendation, or failure to flag contributed to a safety event, regulatory violation, or significant operational harm. The causal chain may be indirect.
• Classify at the highest plausible severity and downgrade with evidence. Never wait for full information before escalating a Severity 1 or Severity 2 event to the fleet owner.
• Phase 1 (Contain, 0 to 60 minutes): stop the harm, protect the driver, preserve the evidence. The evidence preservation window is 60 minutes; logs and screenshots that are not captured in that window may be unrecoverable.
• Phase 2 (Investigate, 1 to 72 hours): answer five specific questions with evidence, not assumption. Is this a one-time error or a pattern? A pattern produces a mandatory hold on all AI-proposed loads in the affected category.
• Phase 3 (Communicate): the driver gets the first call. The fleet owner gets a four-sentence phone call within 60 minutes. The shipper gets an operationally focused update only after the owner is notified. FMCSA notification follows regulation and counsel, not assumption.
• Phase 4 (Remediate and Close): remediation is specific, owned, and dated. Closure requires evidence of remediation effectiveness, not the passage of time. The Council formally closes findings after reviewing that evidence.
• The audit trail must reconstruct the full event chain: AI output, human action, verification steps performed, escalation execution, investigation, remediation, and Council closure. A carrier that cannot reconstruct this chain is in a worse regulatory position than a carrier that had the event and documented it fully.
• Autonomous capacity incidents and missed-defect events from AI-assisted DVIR reviews require specific runbook entries because they involve accountability questions that standard dispatch-error protocols do not fully address.