At 2:47 a.m. on a Sunday in January 2026, the dispatch screens went dark at a 340-truck regional carrier's operations center in Memphis. The ransomware group that breached the carrier's network had entered through an API (application programming interface) connection between the carrier's TMS (transportation management system) and a third-party AI load-matching platform whose security had been compromised two weeks earlier. By the time the IT vendor restored operations 31 hours later, the carrier had missed 87 load commitments, its driver-location data for the prior 90 days had been exfiltrated, and its insurance underwriter had opened a coverage investigation. The carrier had excellent operational AI. It had no data governance framework and no cybersecurity architecture that treated its telematics, TMS, and AI vendor connections as a unified attack surface. A connected fleet is an attack surface. A fleet AI program that does not start with that premise is a program that will eventually learn it the hard way.

Why Data Governance Is the Foundation of Fleet AI

Every AI tool a carrier deploys is only as reliable as the data that feeds it. This is not a statistical observation. It is an operational one. A dispatch optimization tool trained on the carrier's lane history and driver availability data produces recommendations that reflect that specific fleet's reality. A predictive maintenance model calibrated on the carrier's actual vehicle fault codes and repair records can distinguish between a fault code that reliably precedes a failure and one that fires at the start of every cold morning. A driver safety scoring model that uses verified event data from calibrated sensors produces defensible coaching inputs. The quality of each of these tools is inseparable from the quality, completeness, and integrity of the data beneath them.

Data governance is the formal discipline that ensures that quality. It establishes: what data the carrier collects and how; who has access to each category of data and under what conditions; how long data is retained; what the carrier's obligations are when sharing data with AI vendors; how the carrier audits the data it provides to AI systems for completeness and accuracy; and what happens when data is lost, corrupted, or breached. A carrier without a data governance framework is a carrier that is providing its AI tools with data it cannot describe, cannot verify, and cannot defend.

The freight data environment in 2026 is not simple. A single truck equipped with a modern ELD and a telematics platform generates position reports (typically every 30 seconds to 2 minutes), engine performance metrics (RPM, coolant temperature, oil pressure, diesel particulate filter pressure, dozens of additional fault codes), driver behavior events (hard braking, rapid acceleration, following distance alerts, speed-above-posted), HOS logs (driving, on-duty not driving, sleeper berth, off-duty, personal conveyance), and DVIR (driver vehicle inspection report) records. A fleet of 100 trucks generates several gigabytes of this data per day. That data flows from the truck to the telematics platform (typically Samsara, Motive, or Trimble), from the telematics platform to the TMS, and from the TMS to any AI tools integrated into the dispatch or maintenance workflow. Each transfer is a data governance decision, and each connection is an attack surface.

Driver data is especially sensitive. The ELD and telematics data stream includes the driver's legal name (tied to the CDL (commercial driver's license) record in the FMCSA's system), their location at every moment of their work period, their hours-of-service status, and their safety event record. This data is used by the carrier for compliance and dispatch. It is used by AI vendors for model training and performance monitoring. It is sought by insurers for claim investigation. It is discoverable in litigation. A carrier that does not know where its driver data goes, who can access it, and how long it is retained is a carrier with a privacy and liability exposure that its AI program has made larger, not smaller.

The Data Governance Framework for a Carrier

A carrier data governance framework has five components. Each addresses a specific category of risk that fleet AI introduces or amplifies.

Component one: data inventory and classification. The carrier must know what data it has, where it lives, and what its sensitivity classification is. The data inventory for a fleet AI program covers: vehicle telematics data (position, engine metrics, fault codes, event data); driver data (HOS logs, DVIR records, safety scores, CDL status, personal conveyance data); load and customer data (load tender details, shipper and consignee identities, commodity descriptions, rate confirmations, POD (proof of delivery) records); financial data (lane rates, driver pay calculations, fuel costs, maintenance invoices); and AI model data (the training data used by AI vendors, the inference logs produced by AI tools in operation). Each data category receives a sensitivity classification: public (aggregated, anonymized fleet statistics), internal (operational data used in daily dispatch), confidential (driver personal information, customer rate sheets, carrier financial data), and restricted (ELD records subject to regulatory retention requirements, data subject to litigation hold).

The classification drives the access controls, the sharing rules, and the retention schedule. A dispatcher who needs access to real-time driver location data for dispatch does not need access to the driver's historical safety score record from the prior 24 months. A TMS vendor that needs route history data for optimization does not need access to driver CDL numbers or medical certificate status. A predictive maintenance AI vendor that needs fault code streams does not need access to customer rate data. The principle of minimum necessary access, applied systematically across the data inventory, reduces the attack surface and reduces the liability if any one system is compromised.

Component two: data quality standards and auditing. AI tools produce recommendations based on the data they receive. A dispatch optimization tool that receives stale driver availability data will propose loads for drivers who are already committed or who are in reset. A predictive maintenance platform that receives incomplete fault code streams will miss failure signatures. A safety scoring model that receives sensor data from an improperly calibrated hard-braking detector will produce inflated safety scores for an entire vehicle population. The carrier's data governance framework must establish: the freshness standard for each data category (position data must be no older than two minutes at the time of use in a dispatch recommendation; HOS data must be pulled live from the ELD at the time of dispatch commit; fault code data must be current as of the prior engine-on event); the completeness audit process (a monthly review of each vehicle's data completeness against the fleet's full data catalog); and the error correction procedure (who is responsible for correcting a data quality finding and within what timeframe).

Data quality auditing is not an IT function alone. The safety director is the owner of safety-relevant data quality (ELD completeness, DVIR record integrity). The shop manager is the owner of maintenance-relevant data quality (fault code completeness, repair record accuracy). The fleet manager is the owner of dispatch-relevant data quality (driver availability accuracy, vehicle assignment records). The data governance framework assigns ownership explicitly, because unowned data quality is unchecked data quality.

Component three: data sharing and vendor agreements. Every AI vendor the carrier uses receives some category of carrier data. The data governance framework specifies, for each vendor relationship, exactly what data categories the vendor receives, under what contractual terms, for what permitted uses, with what retention limits, and with what obligations in the event of a breach. The minimum contractual requirements for any AI vendor receiving carrier data are: a data processing agreement specifying the permitted uses and the prohibited uses; a data retention limit specifying that the vendor may not retain carrier data beyond the contracted service period or the regulatory retention requirement, whichever is longer; a breach notification clause requiring the vendor to notify the carrier within 24 to 48 hours of discovering a breach affecting carrier data; a data portability clause giving the carrier the right to extract all its data from the vendor's platform in a standard format if the carrier terminates the relationship; and an audit right allowing the carrier to request documentation of the vendor's data handling practices.

The data sharing rules also govern what the carrier may not share. ELD records are legally protected under 49 CFR 395.8(k) from distribution beyond the driver, the carrier, enforcement agencies, and parties authorized by a subpoena. A carrier that sends full ELD records to an AI vendor without proper authorization is potentially in violation of that protection. Driver medical certificate and CDL status data is similarly restricted. The data governance framework must establish a review gate: before any new data category is added to a vendor's data feed, a designated data governance reviewer (typically the fleet manager or the owner, with input from the carrier's legal counsel for enterprise carriers) must confirm that the sharing is permissible and document the basis for that determination.

Component four: data retention and deletion. Carrier data must be retained for the periods required by FMCSA regulations and deleted on a defined schedule after those periods expire. The principal FMCSA retention requirements are: ELD records and HOS supporting documents, minimum six months (49 CFR 395.8(k)(1)); accident registers, three years (49 CFR 390.15(b)); driver qualification files, three years after employment ends (49 CFR 391.51); inspection and maintenance records, one year for the vehicle's service life plus six months after transfer (49 CFR 396.3(c)); and drug and alcohol testing records, varying by test type from one to five years (49 CFR 382.401). The data governance framework specifies the retention schedule for each category, the system of record where each category is stored, the deletion process, and the litigation hold procedure that suspends the deletion schedule when data is subject to a legal hold.

AI vendor contracts must align with these retention requirements. A vendor that retains carrier ELD data for 24 months "for model improvement purposes" when the FMCSA requires only six months of retention is retaining data beyond the regulatory requirement without a clear authorization. The carrier's data governance framework should specify that vendor retention periods may not exceed the carrier's own retention schedule without explicit written authorization, and that "model improvement" is not a sufficient basis for indefinite data retention.

Component five: data governance roles and accountability. Data governance does not operate without assigned human owners. The framework must specify: the data governance lead (typically the fleet manager or the VP of operations for enterprise carriers, or the owner for smaller carriers) who is responsible for the framework's maintenance and annual review; the data owners for each data category (safety director for ELD and DVIR data, shop manager for maintenance data, fleet manager for dispatch data); the data stewards who handle day-to-day access requests and data quality issues; and the vendor data governance contacts at each AI vendor relationship. The annual data governance review must update the data inventory, review vendor contract compliance, assess new data categories introduced by new AI tools, and confirm that retention schedules are being followed. The review is documented and signed by the data governance lead.

The Cybersecurity Architecture for a Connected Fleet

A connected fleet is an attack surface. A carrier with ELD units on 50 trucks, a cloud-based TMS, three AI tool API integrations, a mobile dispatch app, and a telematics platform has at minimum six categories of access points, each of which is a potential entry point for a threat actor. The cybersecurity architecture for a fleet AI program must treat each of those entry points as a deliberate design decision, not as an inherited default from the vendor's standard configuration.

The freight industry is a target. Commercial carriers hold data that threat actors value: real-time vehicle locations (valuable to cargo thieves and insurance fraudsters), customer load information (valuable for competitive intelligence and targeted theft of high-value cargo), driver personal information (valuable for identity theft), and financial data (valuable for business email compromise fraud targeting the carrier's billing and payment processes). The 2026 threat environment for trucking companies includes ransomware attacks targeting TMS and ELD systems (the Memphis incident described in the opening is representative of a documented pattern), cargo theft facilitated by telematics data access, and load fraud schemes that exploit API connections between carriers and load boards.

The cybersecurity framework for a fleet AI program has five architectural requirements.

Requirement one: network segmentation. The carrier's operational technology (OT) network, which carries ELD data, telematics streams, and vehicle communication, must be separated from the carrier's information technology (IT) network, which carries TMS data, email, financial systems, and AI tool connections. A breach that enters through the IT network should not be able to reach the OT network, and vice versa. For carriers that run a flat network (all systems on the same subnet), this is the highest-priority cyber architecture change because the Memphis scenario, in which an AI vendor's compromised API connection reached the carrier's TMS, happens only in a flat network where the vendor connection is not isolated.

Requirement two: API security controls. Every API connection between the carrier's systems and an AI vendor's platform is a data channel that must be governed. The minimum API security requirements are: authentication using API keys or OAuth 2.0 tokens, not shared passwords; rate limiting that prevents a compromised credential from extracting the carrier's full data catalog in a single burst; logging of every API transaction with timestamps and data categories; and a defined offboarding process that revokes API access when a vendor contract ends. Many carriers discover during a security audit that they have active API connections to vendors whose contracts expired months or years earlier. Those connections represent access that neither party is actively monitoring, which is exactly the attack surface that sophisticated threat actors use.

Requirement three: access control and identity management. Every user of a carrier system that contains sensitive data, whether a dispatcher in the TMS, a shop tech in the maintenance management system, or an AI vendor with API access to the telematics platform, must be authenticated with appropriate controls. The minimum requirements are: multi-factor authentication (MFA) for all access to systems containing driver personal data, customer load data, or financial data; role-based access control (RBAC) ensuring that each user can access only the data and functions their role requires; and a quarterly access review confirming that access rights are still appropriate for each user's current role. Former employees, contractors whose projects have ended, and AI vendors whose contracts have lapsed must have access revoked at the time of separation, not at the next quarterly review.

Requirement four: incident detection and response. A carrier cannot respond to a cyber incident it does not detect. The minimum detection capabilities for a fleet AI program are: centralized logging of authentication events, API transactions, and network access; anomaly alerting that flags unusual patterns (a user account logging in at 3 a.m. from an unfamiliar IP address, an API connection transferring ten times its normal daily data volume); and a defined escalation path from IT monitoring to operations leadership when a potential incident is detected. The incident response plan must specify: who is contacted within the first hour of a confirmed incident; what systems are isolated and in what sequence; how operations are maintained during an IT outage (a documented manual dispatch and communication procedure is essential); who communicates with customers, drivers, and insurers; and what regulatory notification obligations apply (a breach involving personally identifiable driver information may trigger state breach notification laws).

Requirement five: vendor security assessment. The carrier cannot directly control the security posture of its AI vendors. But it can contractually require a minimum security standard and verify compliance through the vendor procurement and renewal process. The minimum vendor security requirements are: SOC 2 Type II certification (an independent audit of the vendor's security controls for cloud-based service providers) or an equivalent security standard appropriate to the vendor's size and scope; a penetration testing obligation (the vendor must conduct annual penetration testing and provide the carrier with a summary of findings and remediations); a breach notification clause (the vendor notifies the carrier within 24 to 48 hours of any breach affecting carrier data); and a right-to-audit clause allowing the carrier to request security documentation during the contract term. A vendor that cannot provide SOC 2 Type II or equivalent documentation is a vendor whose security posture is unknown, and an unknown security posture is a liability in a fleet AI program that depends on that vendor's platform for operational continuity.

The Telematics and ELD Data Security Obligations

Telematics and ELD data occupies a special position in the carrier's data security architecture because it is simultaneously operationally essential (dispatch and safety depend on real-time access) and legally sensitive (FMCSA regulations govern who may access ELD records and under what conditions). The security architecture for telematics and ELD data must balance both requirements.

ELD records are accessed by three legitimate parties in the normal course of operations: the driver (who can review their own logs at any time), the carrier (who uses the records for dispatch, HOS compliance, and DVIR management), and the FMCSA or a state enforcement agency (who may request records during a roadside inspection or an audit). The security architecture must ensure that ELD records are accessible to all three parties when legitimately needed and inaccessible to any other party. This means: the ELD platform must require driver authentication before displaying an individual driver's log; the carrier's TMS integration must use an API that authenticates the carrier's identity before providing bulk record access; and the enforcement access pathway must be compliant with 49 CFR 395.8(n), which specifies the format and the data transfer protocol for roadside ELD inspection. A carrier whose ELD platform makes driver logs readable without authentication is a carrier with a data security failure that also constitutes a regulatory non-compliance.

Telematics data security has an additional dimension: vehicle cybersecurity. Modern commercial vehicles are networked systems. The OBD-II (On-Board Diagnostics) port provides access to the vehicle's CAN (Controller Area Network) bus, through which a malicious actor with physical access to the port could, in principle, read or inject vehicle data. The ELD is connected to the CAN bus. A compromised ELD could, in a sophisticated attack, manipulate HOS records in ways that are not immediately detectable. The carrier's security architecture must include: physical security controls at the OBD-II port (a port lock or a sealed ELD installation), a process for inspecting ELD hardware for signs of tampering during vehicle inspections, and a vendor requirement that the ELD platform includes tamper-detection capabilities and audit logging of any configuration change.

AI tool connections to the telematics platform must be governed by the API security controls described in the cybersecurity architecture section. The predictive maintenance AI vendor's connection to the telematics platform is a read-only API that receives fault code and engine performance data. It should not receive position data, driver personal information, or HOS records unless those specific data categories are necessary for the AI tool's function and are explicitly authorized in the data sharing agreement. A telematics platform that provides an AI vendor with an undifferentiated data feed (all vehicle data, all driver data, all at once) is providing far more data than any single AI tool needs and creating a data exposure that the carrier has not authorized and may not be aware of.

Building the Resilient Fleet AI Program

Data governance and cybersecurity are not one-time projects. They are ongoing disciplines that must be built into the carrier's operating rhythm alongside the AI tools they protect.

The annual data governance review is a scheduled event, not an ad hoc response to an incident. It covers: the data inventory update (new tools, new data categories, new vendor connections); the vendor contract compliance review (are the data handling agreements current and are the vendor security requirements being met); the retention schedule audit (is data being deleted on schedule, and are any litigation holds active); the access control review (are access rights still appropriate); and the cyber incident log review (what security events occurred in the prior year and what was the resolution). The review is documented and signed by the data governance lead. If the review reveals a gap (a vendor whose data handling agreement expired, an AI tool generating data the carrier has not classified), the gap is remediated within a defined period, typically 60 to 90 days for non-critical gaps and immediately for security-critical gaps.

The carrier's business continuity plan must include a specific AI system outage scenario. The Memphis incident illustrates the operational risk: a carrier that depends on AI-assisted dispatch and has no documented manual dispatch procedure is a carrier that cannot operate during a system outage. The business continuity plan must specify: how dispatchers confirm driver availability without the TMS (phone confirmation is the baseline); how load assignments are communicated to drivers without the digital dispatch app (a text or call protocol); how the carrier maintains HOS compliance awareness without real-time ELD data access (drivers call in HOS status at defined checkpoints); and how the carrier communicates with shippers and consignees when it cannot meet commitments due to an IT outage. This plan must be tested at least annually: a scheduled tabletop exercise in which the dispatch team practices operating without AI tools for a four-hour window.

Carrier size determines the depth of the data governance and cyber program, but not its existence. A 10-truck owner-operator network is not too small to have a data breach: it is too small to absorb the financial consequences of one. The minimum viable data governance program for a small carrier is: a written data sharing agreement with every AI vendor; a password manager with unique, strong credentials for every system; MFA on the TMS, the ELD platform, and the carrier's email; a monthly backup of critical operational data to an offsite or cloud storage system; and a one-page incident response plan that tells the owner what to do in the first hour of a suspected breach (disconnect the affected system from the network, call the IT contact, call the insurance underwriter, call the primary shipper if the breach may have exposed their load data). A large enterprise carrier needs all of this plus the network segmentation, the security operations center monitoring, the annual penetration testing, and the formal data governance committee. But the minimum viable program is within reach of every carrier that takes the question seriously.

Key Takeaways

• A connected fleet is an attack surface: every ELD connection, every telematics API, every TMS integration, and every AI vendor relationship is a potential entry point for a threat actor, and the carrier that treats its data governance and cybersecurity as an afterthought to its AI program will eventually learn that lesson through an incident rather than a policy review.
• The five components of a carrier data governance framework are: data inventory and classification, data quality standards and auditing, data sharing and vendor agreements, data retention and deletion schedules aligned with FMCSA requirements, and data governance roles with assigned accountability for each data category.
• The five cybersecurity architectural requirements for a fleet AI program are: network segmentation separating OT from IT systems, API security controls with authentication and transaction logging, access control with MFA and role-based permissions and quarterly reviews, incident detection and response with a documented manual operations procedure, and vendor security assessment requiring SOC 2 Type II or equivalent.
• ELD records are legally protected under 49 CFR 395.8(k) and may only be accessed by the driver, the carrier, FMCSA enforcement agencies, and parties authorized by subpoena: a carrier that provides ELD records to an AI vendor without proper authorization is potentially in regulatory non-compliance, independent of any cybersecurity exposure.
• Vendor data handling agreements are non-optional: every AI vendor receiving carrier data must have a current data processing agreement specifying permitted uses, retention limits, breach notification requirements, data portability rights, and the carrier's audit right, and the carrier must verify compliance annually.
• AI tool performance is directly dependent on data quality: a dispatch optimization tool fed stale availability data, a predictive maintenance platform receiving incomplete fault codes, and a driver safety scoring model calibrated on uncalibrated sensor data will all produce recommendations that are worse than the data they receive, which means data quality is not an IT concern but an operational and safety concern.
• Every carrier, regardless of size, needs a minimum viable data governance and cyber program: written vendor data agreements, unique strong credentials with MFA on all critical systems, a monthly offsite backup, and a one-page incident response plan are the floor, not the ceiling, of a defensible fleet AI program.
• The data governance and cyber disciplines must be built into the carrier's annual operating calendar, not left to respond to incidents: an annual data governance review, an annual access control audit, a business continuity exercise that tests manual operations without AI tools, and a vendor security compliance review are the recurring practices that keep the foundation sound.