On a Wednesday in October, the fleet manager at a 180-truck regional carrier sat down with the safety director, the shop foreman, and the VP of operations for what was supposed to be a thirty-minute check-in about a new AI-assisted dispatch tool they had deployed ninety days earlier. The tool was surfacing load recommendations the dispatchers sometimes followed and sometimes ignored, and nobody was sure whether the choices that were getting committed into the TMS (transportation management system) were the AI's picks or the dispatcher's overrides. Three hours later they had mapped, for the first time, exactly which decisions the AI was touching, who was signing off on what, and who would answer the phone if FMCSA (the Federal Motor Carrier Safety Administration) called about a HOS (hours of service) violation on a load the optimizer had proposed. The answer to that last question was: nobody knew. That conversation, and the governance practice it produced, is the subject of this lesson.

Why Governance and Not Just a Policy Document

Most fleets that deploy AI tools respond to governance questions with a policy. A policy says what must happen. A governance practice is the standing body and the repeating cadence that ensure it does happen, that surfaces exceptions before they become incidents, and that carries the institutional memory of every decision made about every AI tool the carrier uses. A policy in a binder satisfies a quick review. A governance practice with meeting minutes, a tool inventory, a decision log, and clear ownership survives a deep audit, a carrier liability claim, and an FMCSA safety fitness determination review.

The distinction matters in freight because the decisions AI touches are not administrative. A dispatch optimizer that proposes a load assignment is touching an HOS clock, a driver-hours budget, a home-time promise, and a CSA (Compliance, Safety, Accountability) score simultaneously. A predictive maintenance system that flags or fails to flag a fault code is touching the question of whether a 40-ton vehicle is safe to operate on a public highway. A driver coaching algorithm that ranks performance is touching an employment relationship with a driver in a workforce 80,000 people short of what the industry needs. These are not decisions where "the AI said so" is an acceptable answer. Governance is the structure that ensures a human with authority and accountability always owns the decision, even when an AI made the recommendation.

The business case for a standing governance practice is equally clear. Carriers are deploying AI tools faster than they are building the oversight structures to manage them. A TMS integration here, a telematics-based alert there, a generative AI tool for rate emails in the back office. Each looks manageable in isolation. Together, without a governance practice, they produce a fleet that is touching dozens of decisions with AI assistance and has no coherent record of which ones, on what authority, with what human sign-off. When something goes wrong, and something eventually does, that record is what determines whether the carrier's response is defensible.

The Governance Gap in Freight

The governance gap in freight AI is not that carriers are using AI carelessly. It is that the people who know the most about each AI tool tend to be the ones who bought it or deployed it, not the people who are accountable for the fleet's safety record or its FMCSA compliance posture. The shop manager knows the telematics-to-maintenance alert system well. The safety director has not been inside that system. The dispatch team knows the load optimizer's recommendations. The shop foreman has never seen a dispatch plan. A governance practice brings these people to the same table on a repeating schedule, so that the fleet's AI program is managed as an integrated whole, not as a set of siloed tools that each department runs independently.

The practice also addresses a subtler problem: drift. AI tools are not static. A vendor updates a model. A threshold gets adjusted in the telematics dashboard. A dispatcher trains the optimizer by consistently choosing certain match patterns. Any of these changes can shift what the AI recommends and how reliably it performs, without anyone in the fleet noticing until the performance delta has been accumulating for months. A governance practice with a standing review cadence catches drift. A policy document does not.

The Fleet AI Governance Council: Charter and Structure

The governance body for a fleet AI program should be called whatever fits the carrier's culture, but for clarity this lesson will call it the Fleet AI Governance Council. The Council is a standing body, not a project team. It does not dissolve when the deployment is complete. It continues for as long as the carrier uses AI tools in operations, which in 2026 means it continues indefinitely.

The Council's charter is the document that defines what it is, who sits on it, what it has authority to decide, and how it reports upward. The charter should be approved by the carrier's owner or senior leadership, version-controlled, and reviewed annually. An examiner or an auditor who asks about AI governance should be handed the charter before they ask for anything else.

1. Purpose and Scope

The Fleet AI Governance Council is the standing oversight body responsible for all AI and machine learning tools used in the carrier's dispatch, maintenance, safety, driver management, and back-office functions. Scope includes: load optimization and dispatch recommendation tools; predictive maintenance and telematics alert systems; driver performance scoring and coaching tools; ELD (electronic logging device) monitoring and HOS compliance tools; DVIR (driver vehicle inspection report) review systems; and generative AI tools used in customer communications, rate drafting, and documentation. Scope explicitly includes vendor-provided tools regardless of which department manages the vendor relationship. Scope includes AI tools used in managing autonomous or driverless capacity booked through the TMS, including Aurora and similar platforms integrated with the carrier's TMS.

2. Mandate

The Council is responsible for: maintaining the fleet AI tool inventory; approving the deployment, material modification, and retirement of AI tools within its scope; reviewing periodic tool performance and monitoring reports; ensuring that every AI-touched decision has a documented human sign-off; overseeing the fleet's HOS compliance posture as it relates to AI-proposed dispatch plans; reviewing and acting on safety and compliance findings related to AI tools; coordinating the carrier's incident response for AI-related events; and reporting to senior leadership and the fleet owner on the AI program's performance, risk, and compliance status.

3. Membership

For a mid-size carrier of 50 to 300 trucks, the Council's core voting membership should include: the VP of Operations or the fleet manager (as Council Chair); the Director of Safety or Safety Manager; the Shop Manager or Director of Maintenance; the Lead Dispatcher or Director of Dispatch. Non-voting standing participants include: the IT or technology lead responsible for TMS and telematics integrations; the back-office or compliance manager; the HR or driver relations manager (for driver-facing AI tools). For carriers with an owner-operator structure, the owner should chair the Council directly. For enterprise carriers of 300 or more trucks, the membership should expand to include a dedicated fleet AI lead role once one is established. The Council requires a quorum of three voting members to make decisions. All voting members should attend in person or by call; proxy attendance does not count toward quorum.

4. Meeting Cadence

The Council should meet monthly at minimum. The standing monthly agenda includes: a tool performance review (each tool in the inventory on a rotating basis, with high-impact tools reviewed at least quarterly); a HOS and compliance review covering any AI-proposed dispatch plans that were modified, rejected, or that resulted in a violation; an open findings review; a new tool or material change approval queue; and a regulatory developments discussion covering FMCSA updates, autonomous operations guidance, and any changes to ELD or CSA requirements. Special meetings can be called by the Chair or any two voting members with forty-eight hours notice, and must be called immediately upon any AI-related safety event or regulatory contact.

A governance council that meets once a year before the audit is not a governance council. It is a compliance calendar item. Real governance happens monthly, between audits, when nobody is watching.

5. Decision-Making Authority

The Council has authority to approve: initial deployment of new AI tools in dispatch, maintenance, safety, or driver management; material changes to existing tools including threshold adjustments, model updates, or changes to human-override protocols; retirement of AI tools; acceptance of safety or compliance findings with a remediation plan; and exceptions to the fleet's AI governance policy. Decisions that require escalation to the fleet owner or board include: deployment of AI tools that would automate dispatch decisions without human confirmation; any AI-related safety event that affects driver welfare or public safety; any regulatory contact from FMCSA related to an AI-assisted decision; and any proposed expansion of autonomous capacity booking that changes the fleet's TMS configuration or compliance obligations.

The AI Tool Inventory: What the Fleet Actually Runs

The tool inventory is the Council's primary working document. It is a living record of every AI tool in the fleet, its current status, who owns it, and what governance oversight it is receiving. It is not a purchase order list or a vendor contact sheet. It is the document that tells the Council, the owner, and an auditor exactly what AI is doing inside the carrier's operations at any given moment.

Each entry in the fleet AI tool inventory should capture the following:

Tool identification: Name, version or release identifier, vendor name and contact, and a plain-English description of what the tool does in the fleet's operations. Example: "Aurora TMS Dispatch Integration v4.2 (vendor: Aurora) -- driverless long-haul lane booking integrated into McLeod TMS; proposes autonomous capacity as a dispatch option for eligible lanes; dispatcher confirms or declines each proposed autonomous assignment before commitment." This description must capture both what the tool does and what human step precedes every committed decision.

Deployment status: In production, in pilot, in evaluation, or retired. Every tool in production must have a named owner and a monitoring cadence. A tool in pilot must have defined success criteria and a go/no-go date. A tool in evaluation must have a defined scope that limits its use to non-production data or clearly bracketed test lanes.

Impact rating: High, Medium, or Low. High-impact tools are those whose recommendations directly inform HOS compliance, driver safety, vehicle roadworthiness, or the carrier's CSA score. Dispatch optimizers and DVIR review systems are High. Driver coaching tools are High because of their employment consequences in a driver-scarce market. Rate email generators are Low. Maintenance alert systems vary by whether they affect a go/no-go decision for a vehicle: if the alert output feeds directly into a decision about whether a truck rolls, it is High.

Human override protocol: Every High and Medium tool must have a documented protocol specifying who can override a recommendation, how overrides are logged in the TMS or the shop management system, and what the standard is for when an override is appropriate versus required. A tool that has no documented override protocol is a High governance risk regardless of its technical rating.

Monitoring cadence and last review: How often tool performance is reviewed, by whom, and what metrics are tracked. For dispatch optimizers: deadhead percentage on AI-proposed versus human-selected loads, HOS violation rate on AI-proposed plans, and dispatcher acceptance rate. For maintenance alert systems: catch rate on defects versus roadside breakdown events, false positive rate, and technician action rate on alerts. For driver coaching tools: score distribution across driver demographics, appeal rate, and correlation with safety outcomes.

Compliance status: Whether the tool has been reviewed against HOS requirements, DVIR requirements, and CSA implications. For tools that touch driver hours or vehicle inspections, this compliance review should be documented and dated. A tool whose compliance review is more than twelve months old should be flagged for re-review, particularly if FMCSA has issued any guidance updates since the last review.

Open findings: Any performance gaps, compliance concerns, or safety near-misses associated with the tool, with status and remediation plan. A finding that is more than sixty days old without a remediation plan is a governance failure, not just a technical problem.

The Dispatch AI Decision Framework: Where the Council Gets Specific

Dispatch is where AI touches the most load-bearing decisions in a carrier's day. The load optimizer proposes a match. The dispatcher accepts or overrides. The committed plan goes into the TMS. The driver rolls. If the plan violates HOS, the driver is now operating out of compliance. If the plan sends a driver over maximum hours, the fleet has a potential CSA violation that traces directly to the dispatch decision. The question the governance practice must answer is: at what point in that chain does accountability sit, and how is it documented?

The Council should establish and maintain a Dispatch AI Decision Framework that specifies, in writing, the following elements for every AI-assisted dispatch tool in the fleet:

The proposal boundary: What the AI is permitted to propose and what it is not permitted to propose without human initiation. An optimizer that surfaces the three best matches for a load is operating within a proposal boundary. An optimizer that auto-assigns a driver and triggers a TMS record without dispatcher confirmation has crossed it. The Council's job is to define and enforce that boundary, not to let it be defined by the vendor's default configuration.

The confirmation requirement: The specific human action that constitutes a commitment. This should be a named step in the TMS workflow: a dispatcher with credentials commits the plan, and that commit action is logged with the dispatcher's ID, the timestamp, and a flag indicating whether the assignment was AI-proposed or human-initiated. The distinction between AI-proposed and human-initiated matters for incident investigation. If a HOS violation occurs on an AI-proposed plan that the dispatcher accepted without modification, the audit trail should show that. If the dispatcher modified the plan before committing, the audit trail should show what changed and why.

The HOS verification gate: The specific check, whether automated or manual, that confirms the proposed plan is legal before it is committed. For fleets with integrated ELD systems, this check can be automated: the optimizer queries the driver's remaining HOS balance from the ELD before proposing a match. For fleets where the ELD and TMS are not integrated, the check is manual and must be documented. A plan committed without a documented HOS check is a governance failure with a direct safety consequence.

The override log: The record of every instance where a dispatcher overrides an AI recommendation. Overrides are not failures. A dispatcher who overrides the optimizer because they know a driver has a family commitment that changes their available hours next week is doing their job. The override log captures this context so the governance practice can distinguish systematic optimizer errors from appropriate human judgment. If the override rate is above 40%, the optimizer is probably not well-calibrated for the fleet's lanes and constraints. If it is below 5%, the dispatcher team may be rubber-stamping AI recommendations without real review. Both are governance signals.

Ops, Safety, and the Shop at One Table: Making It Work

The single most important structural feature of the Fleet AI Governance Council is that it seats operations, safety, and maintenance in the same meeting about the same AI tools. This is not how fleet decisions are usually made. Dispatch handles dispatch. Safety handles safety. The shop handles the shop. AI governance requires a different structure because AI tools do not respect functional boundaries.

A dispatch optimizer that proposes a load for a driver whose truck has an open predictive maintenance alert is generating a decision that touches both dispatch and the shop, but if those two departments are not talking to each other in the same governance meeting, neither one knows what the other is seeing. The governance practice is the mechanism that surfaces these cross-functional dependencies before they produce an incident.

Consider a worked example. A carrier's predictive maintenance system flags a wheel-end bearing temperature anomaly on Unit 47. The alert is in the telematics dashboard the shop manager monitors. Simultaneously, the dispatch optimizer proposes Unit 47 for a 1,400-mile run to Denver, because the driver is available, the hours work, and it is the best load match. The dispatcher sees a clean proposal. The shop manager sees an alert that has not escalated to a work order yet because the technician is finishing a different job. Without a governance structure that connects these two signals, Unit 47 rolls to Denver with a developing bearing failure. With a governance structure, the shop manager's maintenance alert triggers an immediate hold on Unit 47 in the TMS, the optimizer is rerun without Unit 47, and the governance record shows that the hold was applied on the basis of a predictive alert, with a named technician confirming the assessment, before the dispatch commitment was made.

This is not a hypothetical. This is the practical value of the governance practice: not preventing every possible failure, but creating the structure that catches the cross-functional gap before it becomes a roadside breakdown, a CSA violation, or a fatality.

Making the Council work operationally requires a few non-negotiable habits. First, pre-reading: the meeting agenda and supporting materials must be distributed at least five business days before each meeting, so members arrive having reviewed the performance data, not seeing it for the first time. Second, written decisions: every Council decision, including decisions to approve a tool, accept a finding, or escalate a concern, must be recorded in the meeting minutes with the names of the members who voted and any dissenting views. A Council that meets but produces no written decisions is a conversation, not a governance practice. Third, a standing open-findings register: every open finding, whether a technical performance gap, a compliance concern, or a safety near-miss, lives in the register until it is formally closed by the Council. A finding does not close because time passes. It closes because a named owner executed a remediation action and the Council reviewed and accepted the evidence that the remediation worked.

Reporting Upward: Owner and Senior Leadership Alignment

The governance practice is not complete without a defined reporting path to the fleet owner and, for larger carriers, to a board or executive committee. The Council produces information. The reporting path ensures that information reaches the people with authority to act on it.

For a carrier of 50 to 200 trucks, the reporting cadence should include a monthly one-page summary to the owner covering: the AI tool inventory count by impact rating and deployment status; the most significant performance finding from the month; the HOS compliance status for AI-assisted dispatch, showing the number of AI-proposed plans that were modified or rejected at the HOS gate versus the number committed without modification; and any open safety or compliance findings. The summary should be written in plain freight language, not technical language. The owner is not a data scientist. The owner needs to know whether the AI tools are moving more freight, keeping drivers legal, and protecting the fleet's safety rating.

For enterprise carriers with multiple terminals, the reporting cadence should include a quarterly report to the executive team or board covering the same elements at network scale, plus a summary of any AI-related safety events from the quarter, the status of the fleet's autonomous capacity integration, and the Council's forward-looking risk assessment for the next quarter. Carriers that have integrated Aurora or similar autonomous capacity through the TMS should include a dedicated section on autonomous operations governance: how many driverless lanes were booked, what the incident or exception count was, and what the human oversight protocol for autonomous dispatch looks like in practice.

The escalation protocol is equally important. Certain events must reach senior leadership immediately, outside the normal reporting cycle. These include: any AI-related event that contributes to a driver injury or public safety incident; any FMCSA contact related to an AI-assisted decision; any discovery that an AI tool has been producing HOS-non-compliant plans that were committed without the required human verification; and any data breach or unauthorized access to the fleet's TMS or telematics data. The Council's charter must specify these escalation triggers in writing, with named contacts and response timelines. An escalation protocol that lives in a governance document and is never tested is not an operational protocol. The Council should run a tabletop exercise on at least one escalation scenario each year, before an actual event requires it.

Key Takeaways

• A fleet AI governance practice is a standing body with a repeating cadence, not a policy document. It owns the AI program between audits and after the vendor's rep goes home.
• The Fleet AI Governance Council should seat operations, safety, and the shop at the same table monthly, because AI tools in dispatch, maintenance, and driver management do not respect functional boundaries.
• A charter approved by senior leadership, version-controlled, and reviewed annually is the foundational document. It specifies scope, membership, authority, meeting cadence, and escalation paths before an auditor or an FMCSA examiner asks for it.
• The AI tool inventory is the Council's operating document: every tool with its impact rating, human override protocol, monitoring cadence, compliance review date, and open findings tracked in one place.
• The Dispatch AI Decision Framework defines the proposal boundary, the confirmation requirement, the HOS verification gate, and the override log for every AI-assisted dispatch tool in the fleet.
• Written decisions, a standing open-findings register, and pre-distributed meeting materials are the three non-negotiable habits that distinguish a real governance practice from a compliance calendar item.
• The reporting path to the fleet owner must exist and must include escalation triggers for AI-related safety events, FMCSA contact, and HOS compliance failures on AI-proposed plans, with named contacts and response timelines.
• The governance practice catches cross-functional gaps, like a dispatch optimizer proposing a truck that the shop has flagged, before they become roadside breakdowns, CSA violations, or worse.