The compliance examiner from FMCSA (the Federal Motor Carrier Safety Administration) called the carrier's safety director on a Tuesday at 9:15 AM and said she would need access to six months of records: HOS (hours of service) logs, DVIR (driver vehicle inspection report) records, and dispatch decisions for a subset of loads she had already identified. The safety director said she would have everything ready. What she did not say was that she spent the next eighteen hours in a cold panic, pulling records from four different systems, a TMS (transportation management system) that had not been exporting cleanly, an ELD (electronic logging device) platform that required a vendor call to generate the right report format, a shop management system, and a dispatch log that existed partly on paper. The AI-assisted dispatch optimizer had been running for eight months. No one had ever assembled the records it created into a coherent file. This lesson is about building that file before anyone asks for it.

What FMCSA Actually Wants to See

FMCSA auditors conduct safety audits, compliance reviews, and focused compliance reviews under 49 CFR Part 385. A new entrant safety audit looks at whether the carrier has functioning compliance systems. A focused compliance review examines a specific area of concern, typically triggered by crash data, roadside inspection results, or a complaint. A comprehensive safety audit, which can lead to a safety fitness determination, examines the full range of the carrier's safety and compliance obligations. In all three types, the auditor is looking for the same underlying evidence: that the carrier's compliance programs are real, that they produced documented outcomes, and that the outcomes are traceable to the decisions the carrier actually made.

When an AI-assisted dispatch system, a predictive maintenance alert system, or an AI-assisted DVIR review tool is in the loop, the auditor's question becomes more specific: did the AI tool produce compliant outputs, did a human verify those outputs before they were acted upon, and is there a record of both the AI output and the human verification? A carrier that can answer all three questions with documentary evidence is in a strong position. A carrier that says "yes, we had those processes" but cannot produce the records is in the same position as a carrier that did not have the processes.

The specific records FMCSA examines in a dispatch-and-AI context include: the actual driver logs from the ELD, which must match the dispatch records; the dispatch records, which must show which loads were assigned to which drivers with what hours; the DVIR records for each vehicle, pre-trip and post-trip; the maintenance records for each vehicle, including any work orders generated by predictive maintenance alerts; and, for carriers that have integrated autonomous capacity, the dispatch and booking records for autonomous lanes alongside the records for human-driven lanes. A carrier running AI in any of these areas must be able to show the auditor the complete trail from AI output to human action to documented outcome for every record the auditor requests.

The Audit File Structure: Building It Before They Call

The single most effective compliance posture for a carrier running AI tools is to build and maintain the audit file as a continuous operational discipline, not as an emergency assembly exercise every time an auditor schedules a visit. The audit file is not a separate system. It is a structured view of records that the carrier's systems are already creating, organized in a way that makes them producible and traceable on demand.

For a carrier running AI-assisted dispatch, the audit file for dispatch has five components:

Component 1: The HOS record. The ELD platform generates driver logs in a format FMCSA accepts. The carrier's audit file must be able to produce, for any driver and any date range an examiner requests, the complete HOS log in the standard FMCSA-compliant format. This is table stakes for any motor carrier. The AI addition is: the carrier must also be able to produce, alongside the HOS log, the dispatch record for each duty period, showing the loads proposed and committed during that period and the hours calculation the AI optimizer used when it proposed each load. If the AI's hours calculation for a proposed load differed from what the ELD record shows the driver actually had available, that discrepancy is a finding. The carrier needs to be able to show that discrepancy was caught and resolved before dispatch commitment, or explain why it was not caught.

Component 2: The dispatch decision record. Every committed load must have a traceable dispatch record that shows: the load identifier; the driver assigned; the committed departure and arrival times; whether the assignment was AI-proposed or human-initiated (the flag from the TMS confirmation requirement); the name and credentials of the dispatcher who committed the load; and the timestamp of the commitment. This record must be produced by the TMS in a format that is exportable and searchable, not reconstructed from memory or manual logs. A carrier whose TMS does not flag AI-proposed versus human-initiated assignments, or whose TMS export function has been generating errors for three months, has an audit-readiness problem that will not be solved by a last-minute vendor call when the examiner is sitting in the lobby.

Component 3: The HOS verification record. For every AI-proposed load that was committed, the carrier must be able to show the HOS verification step was performed before commitment. If the verification was automated (the optimizer queries the ELD directly and the result is logged in the TMS), this record exists in the TMS export. If the verification was manual (the dispatcher checked the driver's remaining hours and recorded the check), the record must exist as a documented step in the dispatcher's workflow, timestamped, with the hours figure recorded. A dispatcher's assurance that she "always checks HOS" is not a record. A timestamped TMS entry showing the HOS balance at commitment is a record.

Component 4: The override log. Every AI recommendation that was modified or rejected by a dispatcher must have a log entry: what the AI proposed, what the dispatcher committed instead, and if the carrier's governance practice requires it, a brief note on the reason. The override log is not just a governance document. It is compliance evidence. In an audit focused on a specific HOS violation, the override log establishes whether the load the driver ran was the AI's proposal or the dispatcher's modification. Without the override log, the carrier cannot distinguish these two cases in its own records.

Component 5: The AI tool governance record. The carrier must be able to produce, for any AI tool that touched the dispatch records under review, the tool inventory entry showing the tool's version at the time of the records, the compliance review date, the human override protocol in effect, and any open findings or incidents that affected the tool's performance during the period. An auditor who discovers that the carrier was running a dispatch optimizer with a known calibration issue during the period under review will ask: when did the carrier know, what did it do about it, and what happened to the loads dispatched during that period? The governance record is the carrier's answer.

Maintenance Records and the Predictive Maintenance Trail

FMCSA's maintenance record requirements under 49 CFR Part 396 require carriers to maintain records of systematic inspections, repairs, and maintenance for every vehicle in the fleet. The records must include the vehicle identification, the nature of the repair or maintenance, the date, the name and address of the repair facility or technician, and a record of each inspection. AI predictive maintenance and AI-assisted DVIR review systems are creating new layers of records that both support this obligation and create new audit exposure if they are not integrated correctly with the carrier's maintenance record system.

The maintenance audit file for a carrier using AI predictive maintenance must connect three sets of records:

The alert record: Every fault code, sensor anomaly, or predictive maintenance alert generated by the telematics system, with the timestamp, the vehicle identifier, and the alert severity. This record shows what the AI saw. An alert that was generated and not acted upon is a finding. The carrier must be able to show why it was not acted upon: either the technician reviewed it and determined it did not warrant immediate action (documented), or it was in a queue behind higher-priority work (documented with the work order for the higher-priority repair). An alert that simply disappeared because the system was logging too many low-priority items is an audit problem, and it is also the symptom of the alert fatigue governance issue the program has addressed elsewhere.

The work order record: Every work order generated in response to a predictive maintenance alert, with the alert that triggered it, the technician assigned, the work performed, the parts replaced, and the sign-off. This record shows what the carrier did about what the AI saw. If the alert record shows 47 alerts for Unit 23 over a six-month period and the work order record shows 3 work orders, the auditor has 44 alerts to ask about. For each of those 44 alerts, the carrier needs a documented disposition: reviewed and deferred with technician sign-off, folded into a later PM visit, or addressed through a different repair not yet linked to the alert in the system.

The inspection record: Every DVIR, pre-trip and post-trip, for every vehicle, with the driver's signature and the technician's certification where defects were found and repaired. For carriers using AI-assisted DVIR review tools, the inspection record must also show whether the AI review output was used as part of the inspection process, what the AI flagged, and what the technician independently verified. As discussed in the incident response lesson, automation bias in DVIR review is a specific audit risk: if the technician's sign-off on the DVIR reflects the AI output without independent inspection, and the AI missed a defect, the DVIR is not a valid inspection record under Part 396.

The connection between these three records is the audit trail that demonstrates the carrier is running a proactive, AI-enhanced maintenance program, not a reactive one with an AI tool bolted on for appearances. A carrier that can show an auditor a fault code alert, the work order it triggered, the technician inspection record, and the corrected DVIR is showing a functioning maintenance governance system. A carrier that can show alerts but no corresponding work orders, or work orders with no connection to the alerts that triggered them, is showing a system that exists on paper and in the telematics dashboard but not in the shop.

The audit file is not a document you create when FMCSA calls. It is a continuous output of the compliance practice you run every day. If you have to scramble to assemble it, you do not have an audit file. You have a pile of records and a very stressful week ahead.

HOS and ELD Audit Readiness: Where AI Changes the Standard

HOS compliance is the heart of most FMCSA dispatch audits. The ELD mandate, which requires electronic logging of driver hours for most commercial vehicle operators, has made HOS records more consistent and harder to falsify. It has also made discrepancies more visible. An ELD record that shows a driver running 12 hours when the dispatch record shows a 10-hour planned run raises the question: did the driver extend the run, did the shipper add a stop, or did the dispatch plan assume hours the driver did not have? All three are audit concerns. In a fleet using AI-assisted dispatch, the auditor also asks: did the AI optimizer know about the full 12 hours, or did it propose based on a shorter estimated run?

ELD audit readiness for an AI-assisted carrier has three requirements beyond the standard ELD record:

Sync integrity. The carrier must be able to demonstrate that the ELD data the optimizer used when proposing a load was current at the time of the proposal. If the optimizer pulls ELD data via API and the API has a sync interval (as the Driver Kowalski scenario in the preceding lesson illustrated), the carrier must know what that interval was, what the data was at the time of each proposal, and whether any discrepancies between the API data and the ELD record have been investigated. A carrier that cannot demonstrate ELD sync integrity for the period under audit cannot demonstrate that its AI-assisted dispatch plans were based on accurate hours data.

Plan-versus-actual matching. The audit file should include a plan-versus-actual comparison for the period under review: for each AI-proposed and committed load, what hours did the optimizer plan and what hours did the driver actually use? Systematic discrepancies in one direction are a finding. An optimizer that consistently plans to the legal maximum with no buffer produces drivers who routinely reach or exceed HOS limits when any variable (shipper delay, weather, traffic) extends the run. An optimizer that consistently underestimates drive time is generating plans that do not reflect the fleet's actual lanes. Either pattern is a compliance signal, and a carrier that has been tracking this comparison over time can demonstrate proactive HOS monitoring to an auditor. A carrier that has not tracked it discovers the pattern for the first time when the auditor presents it.

Exception documentation. Every HOS exception, every violation, and every near-miss (loads where the driver came within 30 minutes of the HOS limit) must be documented with the dispatch record for that load, the AI optimizer's plan for that load, and the reason for the exception or near-miss. Exceptions should not accumulate without a response. A carrier with three HOS exceptions in a month that has no documented root cause review for any of them is a carrier that is not running a proactive HOS compliance program, regardless of whether AI is involved.

The CSA Score and AI Audit Risk: Connecting the Dots Before the Examiner Does

The CSA (Compliance, Safety, Accountability) scoring program uses data from roadside inspections, crash reports, and violation history to create a Behavior Analysis and Safety Improvement Category (BASIC) score for each carrier. High BASIC scores in categories like Hours of Service Compliance, Vehicle Maintenance, and Unsafe Driving trigger increased scrutiny and intervention. A carrier running AI-assisted dispatch that has a rising HOS Compliance BASIC score has a specific obligation: to determine whether the AI tool's outputs are contributing to the score, and to document that determination before an examiner makes it independently.

The connection between AI tools and CSA scores works in both directions. A well-calibrated dispatch optimizer that reliably proposes HOS-compliant plans and flags near-misses for dispatcher review should reduce the HOS Compliance BASIC score over time. A predictive maintenance system that catches fault codes before they produce roadside breakdowns and out-of-service violations should reduce the Vehicle Maintenance BASIC score. The carrier that is tracking this relationship, with the data to show the improvement, is in a strong audit position. The carrier that has deployed AI tools, has not tracked their CSA impact, and is now facing a compliance review with a rising BASIC score in the affected categories is in a weak one.

The pre-audit CSA review is a simple but important discipline. Before any scheduled or announced compliance review, the carrier's safety manager should pull the carrier's current BASIC scores and dataQ (the FMCSA data quality challenge system) status, identify any violations from the review period that involved loads where AI-assisted dispatch was used, and determine whether those violations appear in the CSA record as the carrier reported them. If a violation in the CSA record relates to a load the AI optimizer proposed, the carrier should have the dispatch record, the HOS verification record, the AI optimizer's plan, and any governance record related to that event ready to produce. An auditor who finds a CSA violation on a load that turns out to have been AI-proposed will want the full trail. A carrier that has it organized already is ahead of the audit.

Assembling the File: The 30-Day Readiness Checklist

A carrier does not need to be under audit pressure to maintain audit readiness. The following checklist, run monthly by the safety manager or the compliance officer, ensures the audit file is current. Each item takes less time to execute as a monthly discipline than it takes to reconstruct under pressure. The checklist connects to the Fleet AI Governance Council's monthly agenda so that compliance gaps identified in the checklist become governance findings before they become audit findings.

ELD and HOS record review: Pull a sample of 10 completed loads from the prior month that were AI-proposed. For each, compare the optimizer's planned hours with the ELD record for the driver on that load. Document the comparison and flag any discrepancy for investigation. If the ELD and the optimizer's plan do not match and no investigation was conducted at the time, log it as an open finding with a due date for root cause review.

Dispatch record completeness check: Confirm the TMS export function is producing complete records that include the AI-proposed versus human-initiated flag, the dispatcher's name and credentials, the commitment timestamp, and the load identifier. Export a 30-day sample and check it for completeness. A TMS export with missing fields is a compliance gap, not an IT inconvenience.

DVIR and maintenance record alignment: Pull the DVIR records for the prior month for a sample of 10 vehicles. Confirm each DVIR is in the system with driver signature and technician certification where applicable. For vehicles that received predictive maintenance alerts during the period, confirm each alert has a documented disposition in the work order system. Any alert with no disposition is an open finding.

AI tool governance current: Confirm the tool inventory entries for all AI tools currently in production are current: compliance review date within 12 months, human override protocol documented and dated, open findings current with named owners and deadlines, and the tool version recorded. A tool that has been updated by the vendor without the inventory entry being updated is a compliance gap.

CSA score review: Pull the current BASIC scores and compare against the prior month. If any score has increased, identify the violations from the period that contributed to the increase and cross-reference them with the dispatch record for those loads. If an AI-assisted load is in the violation set, pull the full dispatch and governance record for that event and add it to the audit file.

Override log integrity: Review the override log for completeness. Confirm the override count and the AI acceptance rate for the prior month. If the override rate is outside the expected range (above 40% or below 5%), log it as a governance finding for Council review.

POD (proof of delivery) and back-office record alignment: Confirm that the loads showing in the AI dispatch record as committed and completed have corresponding POD records in the TMS. Gaps between committed loads and POD records are either invoicing problems or record-keeping problems. Either triggers a compliance question if the period is under audit review.

Incident and finding status: Review the open findings register. Confirm every open finding has a named owner and a current remediation deadline. Any finding that has passed its deadline without closure should be escalated to the Council at the next monthly meeting. Close any findings that have completed remediation with documented evidence.

Key Takeaways

• FMCSA auditors want to see that AI-touched decisions produced compliant outputs, that a human verified those outputs before they were acted upon, and that there is a record of both the AI output and the human verification. All three must be present.
• The audit file for AI-assisted dispatch has five components: the HOS record with the optimizer's hours calculation; the dispatch decision record with the AI-proposed versus human-initiated flag; the HOS verification record showing the check was performed before commitment; the override log; and the AI tool governance record.
• ELD sync integrity is a specific AI audit risk: the carrier must be able to demonstrate that the hours data the optimizer used was current at the time of the proposal, not cached or stale from a delayed sync interval.
• The maintenance audit trail must connect three records: the predictive alert, the work order it triggered, and the DVIR inspection record. An alert with no disposition is a finding. A DVIR sign-off that reflects the AI output without independent inspection is not a valid inspection record under 49 CFR Part 396.
• A rising CSA BASIC score in HOS Compliance or Vehicle Maintenance in a carrier running AI tools requires a carrier-initiated investigation into whether the AI tool's outputs are contributing to the score, before the examiner identifies the connection independently.
• The 30-day readiness checklist, run monthly by the safety manager, ensures the audit file is current: ELD-to-optimizer plan comparison, TMS export completeness, DVIR-to-alert alignment, tool governance currency, CSA score review, override log integrity, POD alignment, and open findings status.
• The audit file is a continuous output of the compliance practice, not an emergency assembly project. A carrier that scrambles to build the file when FMCSA calls does not have audit readiness. It has a stressful week and a compliance gap that the auditor will likely find before the carrier does.
• POD records, back-office settlement documentation, and TMS export integrity are part of the audit file. A carrier that runs AI across dispatch and invoicing must be able to show the full chain from load commitment to delivered proof of delivery to settled invoice, without gaps that a discrepancy audit would flag.