The safety director at a regional flatbed carrier learned, on a Tuesday afternoon, that the dispatch floor had been running an AI load-matching tool for six weeks. Not because anyone told her. Because she overheard the conversation. The tool had already rerouted three drivers past their legal hours-of-service (HOS) limits, and no one had flagged it because no policy existed that said they should. The carrier had an ELD (electronic logging device) compliance policy, a DVIR (driver vehicle inspection report) policy, and a drug-and-alcohol testing policy. It did not have an enterprise AI policy. And it was about to have an FMCSA (Federal Motor Carrier Safety Administration) audit.

Why a Carrier Needs an Enterprise AI Policy

Ask ten fleet managers whether their carrier has an AI policy and nine will tell you yes, roughly, pointing to their transportation management system (TMS) user-access policy or their ELD data-handling agreement. Neither is an enterprise AI policy. A TMS user-access policy governs who can log in. An ELD data agreement governs what the device vendor can do with hours-of-service logs. An enterprise AI policy governs what happens when the carrier deploys AI to make decisions that affect dispatch, driver safety, regulatory compliance, and customer commitments simultaneously.

The distinction matters because AI in freight does not confine itself to a single department or a single policy boundary. A dispatch optimization tool is simultaneously a labor decision (which driver gets which load), a safety decision (does the proposed plan respect HOS, fatigue patterns, and DVIR status), a financial decision (what is the revenue and deadhead consequence of this assignment), and a compliance decision (will this plan produce a violation that raises the carrier's Compliance, Safety, Accountability (CSA) score and potentially triggers an FMCSA intervention). No single existing policy captures the intersection of all four. The enterprise AI policy is the document that does.

In 2026, the need is not academic. Carriers of every size are deploying AI tools: optimization engines inside McLeod, Samsara, Motive, and Trimble that propose load matches; predictive maintenance platforms that flag fault codes and recommend service; generative AI tools that draft rate confirmation emails, settlement sheets, and safety reports. Each of these tools touches a regulated domain. The carrier's safety director, fleet manager, and owner all need a single document they can consult to answer the question: is this AI decision defensible?

An enterprise AI policy answers that question by establishing four things: what the carrier means when it says "AI" (scope); who makes decisions about AI deployment and use (governance authority); what rules govern every AI-assisted action in dispatch, the shop, and safety (use standards); and what happens when an AI tool produces a bad outcome (incident response). Without those four pillars, the carrier is operating AI at the speed of a vendor's sales cycle rather than at the speed of its own judgment.

The FMCSA regulatory context reinforces the urgency. HOS rules require that every driver operate within legally mandated driving and on-duty time limits, with violations recorded on the ELD and surfaced in the carrier's CSA score. A dispatch plan that violates HOS is not just operationally wrong: it is a regulatory violation that the carrier, not the AI vendor, is liable for. The enterprise AI policy establishes that this liability stays with the carrier and that the AI system is a tool that assists human decisions, not a system that makes them autonomously.

The Seven Pillars of a Defensible Fleet AI Policy

A defensible enterprise AI policy for a carrier, meaning one that holds in an FMCSA audit, a shipper dispute, an insurance investigation, and an internal safety review, has seven structural pillars. Each pillar addresses a specific governance obligation. Missing any one of them creates a gap that will surface at the worst possible moment.

Pillar one: scope definition. The policy must define precisely what counts as "AI" for purposes of its coverage. This is harder than it sounds. A load-matching optimization engine is AI. A predictive maintenance alert model is AI. A generative AI tool that drafts a DVIR exception narrative is AI. An AI-powered driver coaching scorecard is AI. The scope must capture all of these: traditional optimization algorithms running inside the TMS; machine learning (ML) models that predict fault failure or safety risk; generative AI (GenAI) tools that produce human-readable text for dispatch, safety, or customer communication; and third-party AI components embedded in telematics and ELD platforms the carrier did not build itself. The scope must also define what is not covered: basic automation that follows fixed rules without prediction or learning (a static mileage calculator, for example) and standard statistical reports that do not drive or recommend decisions. The scope statement is what lets the safety director answer the question "does this tool fall under the policy?" with a yes or a no, without having to escalate to the owner every time.

Pillar two: governance authority and ownership structure. Every AI tool in scope must have a named owner: a human being at the carrier who is accountable for the tool's performance, its compliance with the policy, and its integration into the carrier's operations. For small carriers, the tool owner is often the fleet manager or the owner-operator. For enterprise carriers, different tools may have different owners (the dispatch AI reports to the operations director, the maintenance prediction platform reports to the shop manager, the safety coaching tool reports to the safety director). The policy must name the governance body responsible for overseeing the AI program at the enterprise level. This is typically a cross-functional review council that includes representatives from operations, safety, maintenance, and the back office, meeting at least quarterly. Without named ownership, accountability evaporates the moment something goes wrong, and "the system recommended it" becomes an uncontested explanation rather than an incomplete one.

Pillar three: intake and approval process. Before any AI tool is deployed in a carrier function, it must complete a defined intake process. The intake process must include: a use-case description stating what the tool does, what data it uses, what outputs it produces, and how those outputs influence decisions; a risk classification based on the potential for safety harm, regulatory exposure, and financial impact; a governance pathway appropriate to the risk level; and an inventory registration confirming the tool is logged before deployment. The intake process is specifically designed to prevent the scenario that opened this lesson: a tool in active use that no one in the safety or compliance function has reviewed. High-risk tools (any tool that influences a dispatch decision, a maintenance deferral decision, or a driver safety action) require explicit approval before deployment. Low-risk tools (back-office drafting aids with no decision influence) may proceed with documentation. The intake process is the mechanism that makes the enterprise AI policy operational rather than aspirational.

Pillar four: use standards across dispatch, the shop, and safety. This is the policy's most operationally detailed section and its most load-bearing one. The use standards establish the rules that every dispatcher, fleet manager, shop tech, and safety manager must follow when interacting with any AI tool covered by the policy. The use standards have four non-negotiable elements. First, the human accountability rule: AI outputs inform human decisions; the human who commits to a dispatch, approves a maintenance deferral, or issues a driver coaching action owns that decision and its consequences. "The system recommended it" is not a defense in an FMCSA audit, a shipper dispute, or a court. Second, the HOS verification obligation: any dispatch plan proposed or modified by an AI tool must be verified against actual HOS status in the ELD before it is dispatched. A plan that cannot be run legally is a liability, and the verification step is not optional. Third, the safety override rule: any AI recommendation that conflicts with a safety input (a driver reporting fatigue, a DVIR defect, a weather alert, a CSA intervention notice) must be overridden in favor of safety, and the override must be logged. The AI tool may propose; the human decides. Fourth, the output verification obligation: any AI-generated rate, route, mileage figure, HOS calculation, or compliance summary that will be used in a decision, a shipper communication, or a regulatory record must be verified against the source data before use. An invented lane rate or a wrong HOS calculation that reaches a load confirmation or a CSA report is a liability that the policy must prevent.

Pillar five: vendor and third-party AI governance requirements. Most carriers do not build their AI tools. They buy them from TMS vendors, telematics providers, and standalone AI software companies. The enterprise AI policy must define what the carrier requires of any vendor supplying an AI tool. The minimum vendor requirements include: a data handling agreement specifying what driver, vehicle, customer, and route data the vendor may retain, use, and share; a material change notification obligation requiring the vendor to inform the carrier when the AI tool's models, data sources, or decision logic change significantly; an examination cooperation clause confirming the vendor will provide documentation of the tool's operation in the event of an FMCSA audit or a shipper dispute; and a liability allocation clause establishing whether the carrier or the vendor is responsible for AI-generated recommendations that result in a violation. Carriers that skip the vendor governance requirements discover their exposure only when they need the documentation, which is always after the event rather than before it.

Pillar six: ongoing monitoring and performance reporting. An AI tool that is deployed and never monitored is a tool whose performance the carrier does not actually know. The policy must establish monitoring obligations for every AI tool in the inventory, calibrated to the tool's risk level. High-risk tools (dispatch optimization, maintenance prediction, safety scoring) require monitoring at least monthly: review of the recommendations the tool made, the human decisions that followed, and the outcomes those decisions produced. Did the dispatch tool's recommendations result in more HOS violations or fewer? Did the maintenance prediction tool catch the fault codes that led to roadside breakdowns, or did those events still occur? Medium-risk tools require quarterly monitoring. All monitoring results must be reported to the governance council. Material findings (a tool that has been consistently recommending illegal plans, a safety scoring model producing unfair driver rankings) must be escalated within a defined timeline rather than held for the next regular cycle.

Pillar seven: incident response and tool recall procedures. The policy must define the process for identifying, escalating, and responding to AI-related incidents. An incident is any event in which an AI tool produced an incorrect, unsafe, or non-compliant recommendation that affected a real decision. The incident response process includes: a detection mechanism (monitoring thresholds, driver and dispatcher reports, FMCSA inspection outcomes); an escalation path that reaches the owner and the governance council within a defined timeframe for safety-affecting incidents; a remediation process (suspending the tool, correcting the decision where possible, notifying affected parties, and documenting the response); and a post-incident review identifying the governance failure and updating the policy or procedures to prevent recurrence. A carrier without a defined AI incident response process is a carrier that will improvise its response under pressure after an event that should have been anticipated.

How the Policy Applies in Dispatch, the Shop, and Safety

The enterprise AI policy's strength is its cross-cutting scope. A dispatch-only AI policy, a maintenance-only AI policy, and a safety-only AI policy each miss the moments when all three functions interact, which is exactly when the most consequential decisions happen.

In dispatch, the policy establishes that the AI optimization tool is a co-pilot, not an autopilot. The dispatcher uses the tool's load-match recommendations to accelerate the matching process, but the dispatcher's commit is what makes the dispatch real. The HOS verification obligation applies to every proposed plan: the dispatcher must confirm that the recommended assignment does not push any driver past their legal driving time before accepting the AI recommendation. The dispatch policy use standard specifically prohibits the practice of accepting AI recommendations in bulk without individual review, a shortcut that becomes tempting when volume is high and staffing is thin. The audit trail requirement means that every AI-proposed match and every dispatcher commit is logged with a timestamp, so the carrier can reconstruct its dispatch process for any load in the event of an incident or an audit.

In the shop, the policy applies to predictive maintenance platforms and fault-code alert systems. The predictive maintenance economics are compelling: approximately 34% cost savings on maintenance expenses on a payback period of roughly 44 days for carriers that deploy well-calibrated systems. But those economics depend on the shop acting on alerts that are valid and ignoring alerts that are noise. The policy establishes that the shop tech is the human owner of every maintenance decision: the platform flags, the tech evaluates, and the tech signs off before a truck is cleared or grounded. A deferral decision (the platform flagged it, but we are running the truck through the weekend anyway) must be logged with the reasoning, because that log is the carrier's defense if the truck breaks down on Saturday and the shipper or insurer asks when the issue was first flagged. The policy also establishes that the predictive maintenance vendor's data handling obligations apply: the telematics data flowing to the prediction platform includes vehicle identification, fault codes, mileage, and location, all of which the vendor must handle under the carrier's data governance terms.

In safety, the policy is at its most demanding. The safety director's oversight of ELD logs, DVIR records, and CSA (Compliance, Safety, Accountability) scores is a regulatory obligation, and any AI tool that touches that function operates in a domain where errors have direct regulatory consequences. The policy establishes that safety AI tools are high-risk by definition and require the highest governance intensity: pre-deployment approval, monthly monitoring, and real-time escalation for safety-affecting findings. It also establishes the driver coaching rule: coaching decisions based on AI-generated safety scores must be reviewed by a human safety manager before delivery, because an incorrect score delivered as an automated coaching message is a fairness problem that drives driver attrition in a market that is already 80,000 drivers short. The verification obligation in the safety context means that a CSA score summary or an HOS exception report drafted by a generative AI tool must be verified against the actual ELD and inspection records before it is shared with the FMCSA, a shipper, or a driver.

The three-function integration becomes visible in edge cases. A driver reports fatigue during an active load. The dispatch AI does not know this because it is reading the HOS clock, not the driver's self-report. The maintenance platform flags a tire pressure anomaly on the same truck. The safety director's CSA monitoring shows the driver has two recent speeding violations on the same lane. None of the AI tools, operating in isolation, has the full picture. The enterprise AI policy establishes the escalation rule: when safety inputs conflict with optimization recommendations, safety wins, and the human safety manager is the decision-maker. The policy is the document that makes this rule explicit, consistent, and auditable across all three functions.

The Policy Document: Structure and What to Avoid

The enterprise AI policy is a governance document, not an operating manual. It defines what the carrier requires and why, at a level of specificity that allows the owner, the safety director, and an FMCSA auditor to assess whether the carrier has a functioning governance framework. The operational procedures for how dispatchers run the HOS verification check, how shop techs log maintenance deferrals, and how the safety director conducts monthly monitoring belong in function-specific procedures that sit below the policy, not in the policy itself.

The policy should contain: the scope definition; the governance authority structure; the intake and approval process at the design level; the four use-standards elements (human accountability, HOS verification, safety override, output verification); the vendor requirements; the monitoring obligations; and the incident response framework. Each element should be specific enough to create a clear obligation and flexible enough to accommodate changes in the carrier's AI tools without requiring a policy revision every time a vendor updates its software.

The policy should not contain: specific vendor names, which change; specific model version numbers, which change faster; detailed step-by-step procedures for operating any particular tool; specific dollar thresholds for budget approval of AI tools; or technical descriptions of how the AI tools work at the architecture level. A policy that is too technically specific becomes obsolete before the owner signs it. A policy that is too vague provides no actual governance protection.

Length matters. A policy of fewer than four pages signals a governance framework that has not been thought through. A policy of more than fifteen pages signals a document that was written by a vendor or a consultant rather than by the carrier for the carrier's own use. The right length for a carrier enterprise AI policy is six to twelve pages of substantive policy text, with appendices for the risk classification matrix and cross-references to related policies (ELD compliance, DVIR, drug-and-alcohol testing, data security).

One structural trap to avoid: the list of approved AI tools. Many carriers write their AI policy around the specific tools currently in use, which creates a policy that must be revised every time a tool is added, upgraded, or replaced. The better architecture is a policy that describes the governance process that applies to any AI tool, regardless of which specific tools are in the inventory at the moment of writing. The inventory lives in a separate, maintainable log. The policy lives in a governance document that the owner signs once and reviews annually.

Operationalizing the Policy: From Paper to the Dispatch Floor

A policy that exists in a binder and is never applied is not a governance framework. It is a liability: it establishes that the carrier knew what good governance required, documented it, and then did not do it. Operationalizing the enterprise AI policy means closing the gap between the written commitment and the daily practice on the dispatch floor, in the shop, and in the safety office.

The first operationalization challenge is the AI inventory. The policy's scope statement covers all AI tools across all carrier functions. The inventory must reflect that scope. Most carriers, when they conduct their first AI discovery audit, find tools they did not know were in use: the AI features embedded in their TMS subscription that were turned on by default; the predictive maintenance module their telematics vendor activated in a software update; the generative AI drafting tool that three dispatchers have been using on their personal devices because it saves them thirty minutes per shift. Each of these tools must be evaluated under the intake and approval process. The practical approach is to conduct a carrier-wide AI discovery audit within sixty days of policy adoption, with a findings report to the governance council. Tools that do not pass the intake process must be either remediated or discontinued before the next audit cycle.

The second challenge is training. The use standards are only enforceable if every dispatcher, shop tech, and safety reviewer understands them and has practiced applying them. The enterprise AI policy requires a training program covering the four use-standard elements: the human accountability rule, the HOS verification obligation, the safety override rule, and the output verification obligation. Training must be completed before any staff member uses an AI tool in a decision-influencing function, and it must be refreshed annually. For carriers with high driver and dispatcher turnover, the onboarding version of the training is as important as the annual refresh.

The third challenge is monitoring capacity. The policy requires monthly monitoring of high-risk AI tools. If the safety director does not have the time or the data access to conduct that monitoring, the obligation exists on paper but not in practice. Before finalizing the policy, the carrier should assess whether the people responsible for monitoring have the time, the tools, and the data to actually perform it. This is a staffing and systems question, not a policy question, but it must be answered before the policy is adopted or the monitoring commitment is meaningless.

The fourth challenge is the audit trail. The policy requires that every AI recommendation, every human commit, every override, and every monitoring finding be logged and retrievable. This sounds like an IT project, but in practice it usually means establishing a simple logging discipline: the dispatch tool's recommendation log is retained for a minimum period; override decisions are documented with a reason code; monthly monitoring results are filed in a policy folder with a date stamp. An FMCSA auditor who asks for the carrier's AI governance records should be able to see the log of AI recommendations, the human decisions that followed, and the monitoring results that confirm the system has been reviewed. That log is the carrier's primary defense when the policy is tested by an adverse event.

Connecting Policy to Safety, Data Governance, and the Autonomous Transition

The enterprise AI policy is the foundation of two adjacent governance commitments that the lessons in this chapter address separately: safety as the first constraint and data governance and cybersecurity. Understanding how the policy connects to both is essential to seeing it as a governance system rather than a standalone document.

Safety as the first constraint is expressed in the policy through the safety override rule and the high-risk classification of any AI tool that influences dispatch or driver status decisions. The policy does not say "optimize for safety when it is convenient." It says that safety inputs override AI optimization recommendations, and that this rule is not subject to dispatcher discretion. The policy makes this concrete by establishing an escalation threshold: any AI recommendation that conflicts with a safety input triggers a human review that must happen before the dispatch goes out. The safety director's authority to suspend an AI tool pending a safety review is written into the policy explicitly, not assumed.

Data governance and cybersecurity connect to the AI policy through the vendor requirements pillar and the scope definition. Every AI tool in scope processes carrier data: HOS records, fault codes, driver safety scores, customer load information, and financial rates. The policy's data classification rule specifies which categories of data may be used with which categories of AI tools, and under what contractual conditions. A dispatch optimization tool that sends real-time position data to a vendor's cloud does not have automatic permission to do so: the vendor data handling agreement must be in place and must address what the vendor may retain, process, and share. The cyber implications are discussed in depth in the data governance and cyber lesson, but the enterprise AI policy is the governance anchor that makes those obligations binding rather than advisory.

The autonomous transition is the policy's horizon challenge. Aurora's 250,000-plus driverless miles, bookable through its McLeod TMS integration serving more than 1,200 fleets, mean that enterprise carriers in 2026 are managing or planning for mixed fleets in which some lanes are human-driven and some are autonomous. The enterprise AI policy must address autonomous capacity in its scope definition: autonomous vehicles operating under a carrier's authority, whether owned, leased, or contracted, are covered by the policy. The governance council has oversight of autonomous lane deployment. The monitoring obligations apply to autonomous fleet performance. And the safety override rule applies with additional force: any autonomous vehicle operation that conflicts with a safety input (a road condition, a mechanical flag, a geofencing constraint) triggers an immediate human review and, if necessary, a mission abort. The policy is the document that establishes these rules before the first autonomous lane goes live, not after the first incident.

Key Takeaways

• An enterprise AI policy for a carrier is not a collection of existing ELD, DVIR, and TMS policies: it provides the cross-cutting governance layer that coordinates scope, authority, use standards, vendor requirements, monitoring, and incident response across all AI tools and all carrier functions in a single document the owner can sign and an FMCSA auditor can assess.
• The seven pillars of a defensible fleet AI policy are: scope definition, governance authority and ownership structure, intake and approval process, use standards across dispatch and the shop and safety, vendor and third-party AI governance requirements, ongoing monitoring and reporting obligations, and incident response and tool recall procedures.
• The four non-negotiable use standards are: the human accountability rule (the dispatcher or fleet manager who commits to a decision owns it), the HOS verification obligation (every AI-proposed dispatch plan must be checked against actual ELD data before dispatch), the safety override rule (safety inputs override optimization recommendations without exception), and the output verification obligation (AI-generated numbers, rates, and compliance summaries must be verified before use).
• The intake and approval process is the mechanism that prevents AI tools from going live without governance review: every tool in scope must complete intake before deployment, and tools already in use must be discovered and evaluated in an initial inventory audit conducted within sixty days of policy adoption.
• High-risk AI tools, meaning any tool that influences dispatch, maintenance deferral, or driver safety decisions, require the highest governance intensity: pre-deployment approval by the governance council, monthly monitoring, and real-time escalation for safety-affecting findings.
• Vendor requirements are non-optional: data handling agreements, material change notification, examination cooperation, and liability allocation must be in place for every vendor-supplied AI tool before the tool is deployed, because the carrier, not the vendor, owns the regulatory consequences of AI-assisted decisions.
• Operationalizing the policy requires four things beyond the document: a carrier-wide AI discovery audit within sixty days of adoption, a training program covering all staff using AI tools, a monitoring capacity assessment confirming the safety director and fleet manager can meet the monitoring obligations, and an audit trail discipline that logs every recommendation, commit, and override.
• The enterprise AI policy is the governance foundation for the adjacent commitments in this chapter: it makes the safety-as-first-constraint rule binding (through the safety override pillar), it anchors the data governance obligations (through the vendor requirements and data classification rules), and it establishes the governance framework for the autonomous transition before the first driverless lane goes live.