AI in Road Freight Runs on Data Infrastructure: Why the Models Are the Easy Part

Every AI ambition in road freight — sharper ETAs, automated dispatching, agentic workflows that handle exceptions on their own — fails or succeeds on the same unglamorous question: can the AI actually read your fleet? Industry surveys suggest 88% of AI agent projects never reach production, and the leading cause is not the model — it is infrastructure gaps. This pillar explains the AI opportunity in road freight honestly, why the fleet-data layer decides the outcome, what an AI-ready data architecture looks like, and how to sequence the work so your first AI project is not also your last.

Why AI lands differently in road freight

Road freight looks like the perfect AI industry. It is drowning in repetitive decisions — which truck takes which load, when to leave, whom to call when a delivery slips — and every one of those decisions has data behind it: positions, fuel burn, driving times, dwell, weather, traffic, history. Margins are thin, planners are scarce, and the structural driver shortage means productivity per human is the binding constraint. If AI can make each dispatcher capable of managing more trucks, that is not a nice-to-have; it is the capacity plan.

And yet most AI initiatives in transport stall. Enterprise surveys in 2025/26 paint a consistent picture: the great majority of AI agent projects — by one count 88% — never make it to production, and the reasons cited are dominated by infrastructure gaps, governance, and unmeasurable ROI rather than model quality. In supply chain specifically, barely a quarter of organisations report having a formal AI strategy, and fewer than a third consider their capabilities future-ready.

The pattern behind those numbers is familiar to anyone who has run a visibility or telematics project: the intelligence layer gets the budget and the attention, while the data layer underneath it gets discovered — too late — to be fragmented, incomplete, and inconsistent. The model is the easy part. The plumbing is the project.

The brutally simple equation: AI quality = data quality × data coverage

Strip away the vendor language and every operational AI use case in road freight reduces to the same dependency chain:

A model is a function of its inputs. An ETA model fed positions every 30 seconds, with clean odometer and driving-time data, can learn what actually delays your trucks. The same model fed 15-minute pings from half the fleet learns mostly noise. No amount of model sophistication recovers information that was never collected.

Coverage is a multiplier, not a detail. If subcontractors run 40% of your kilometres and they are not in the data layer, your AI is blind on 40% of the network — typically the 40% with the most variability, which is precisely where prediction is worth the most. An AI that optimises only the owned fleet optimises the easy half of the problem.

Consistency is what makes data machine-readable. Humans tolerate a portal here, a CSV there, a field called odometer in one system and totalVehicleDistance in another. Software does not. AI consumes data at scale, automatically, without a human cleaning each row — which means normalisation (one schema, one set of units, one vehicle identity model) is not a data-engineering nicety. It is the admission ticket.

This is why "we will add AI later" is usually backwards. The organisations getting value from AI in transport did the boring work first: one feed, full fleet, normalised, with known quality. Then the models had something to learn from.

The AI use cases that actually work in road freight — and what each one eats

Predictive ETAs. The most mature use case. Machine-learning ETA engines learn from historical trips — lane variance, weekday patterns, site dwell, driver behaviour, traffic, weather — and update continuously against live positions. What they eat: high-frequency positions, accurate trip and stop detection, driving-time context, and lots of history. Data-quality gaps such as spotty GPS pings are consistently cited as the main source of ETA error — not model architecture.

Exception prediction and prioritisation. One step beyond alerting: instead of telling you the truck is late, the system learns which developing situations will become problems and ranks them. Eats: everything the ETA model eats, plus order context (time windows, customer criticality) and a labelled history of past exceptions.

Dispatch and planning support. Suggesting truck-load assignments, departure times, and realistic schedules based on measured (not assumed) transit and service times. Eats: clean historical trip data per lane and site — the difference between planning against reality and planning against the tariff book.

Fuel and driving-behaviour analytics. Identifying which drivers, routes, and vehicles burn more than they should, and predicting maintenance needs from engine data. Eats: CAN-bus level measured consumption and engine signals, normalised across mixed fleets — fuel-card data is not enough.

Agentic workflows. The 2026 frontier: software agents that do not just predict but act — rebook a slot when the ETA slips, notify the customer, document the detention claim. Agents are only as capable as the systems they can read and write. An agent cannot click through a telematics portal; it needs APIs. Which is why the agentic wave makes machine-readable fleet data more valuable, not less: every portal-only data source in your stack is a wall your future agents cannot see through.

A note of honesty, because the CO3 voice does not oversell: none of these use cases is magic. Each automates judgement that good planners already apply — at a scale and consistency humans cannot sustain across hundreds of daily movements. The gains are real and compounding, but they arrive through the dull mechanics of better inputs, not through a model with a more impressive name.

Where road freight operators get stuck

The pilot that could not scale

The classic failure: a promising AI pilot on one depot's data, hand-cleaned by an analyst for three months. The pilot works. Scaling it means repeating the hand-cleaning across twelve depots, four telematics systems, and ninety subcontractors — and the business case dies. The pilot proved the model; nobody had proven the data supply.

Buying intelligence before plumbing

Vendors sell what demos well, and prediction demos better than normalisation. Operators sign for the AI feature and discover that connecting their actual mixed fleet — OEM systems, aftermarket boxes, partner fleets — is a separate, unpriced project. (We wrote a full deep-dive on the build-vs-buy decision for AI in supply chains; the short version is that the data layer dominates the total cost either way.)

The unowned data layer

IT owns the integrations, operations owns the planning, sustainability owns the emissions numbers — and nobody owns "one consistent feed of what the fleet actually did". Without an owner, quality erodes silently, and every AI initiative re-fights the same data battles.

Mistaking dashboards for readiness

Having a visibility dashboard does not mean the underlying data is AI-ready. Dashboards are forgiving — a human interprets around the gaps. Models are not. The test is not "can a person see the fleet?" but "could software consume last quarter's complete movement history, per vehicle, without a human fixing anything?"

What an AI-ready fleet data architecture looks like

Five properties, in plain language:

1. Complete: every asset — trucks, trailers, subcontractors — in one feed. Coverage measured and reported, not assumed.
2. Normalised: one schema, one set of units, consistent identifiers across all sources. The Babel problem solved once, centrally.
3. High-frequency and low-latency: update intervals that support live decisions (seconds to low minutes, not quarter-hours), delivered as the events happen.
4. Historical: deep, query-able trip history — models learn from the past, and a feed without history is a feed without training data.
5. Machine-readable: API-first. Everything a human can see, software can request — which is exactly what agents will need.

How CO3 does this today

CO3 is the data-infrastructure layer this pillar describes: 500+ telematics and OEM integrations across trucks, trailers, and subcontractor systems, normalised into a single API — no new hardware on the vehicles. The feed carries live positions, trips, measured fuel consumption, temperature, and per-leg CO2 reporting (each leg labelled primary, hybrid, or modelled, with a primary data share metric), aligned with the GLEC Framework and ISO 14083. It is the input layer for ETA prediction and for whatever models — yours or ours — come next. We deliberately describe CO3 as the foundation AI runs on, not as the AI itself.

Getting started without betting the company

1. Audit the data layer first. Before any AI procurement: what share of your movements is in one machine-readable feed today, at what frequency, with how much history? That number — not a vendor demo — tells you how far you are from value.
2. Fix coverage and normalisation centrally. One integration layer across the mixed fleet and subcontractors. This investment pays back even if you never deploy a model, through visibility, detention billing, and emissions reporting — which is what makes the sequencing safe.
3. Deploy AI narrowest-first. Start where the data is already strong and the feedback loop is fast — typically ETAs on your highest-volume lanes. Measure against the pre-AI baseline. Expand use case by use case on proof, not promise.

Self-assessment: is your fleet AI-ready?

1. Is every vehicle — including subcontractors — reporting into one normalised feed?
2. Do you know your actual position-update frequency per data source?
3. Could software pull a year of complete trip history through an API today?
4. Is measured fuel consumption (not fuel-card data) available per vehicle and trip?
5. Does someone in your organisation own fleet-data quality as a responsibility?
6. Do you have a measured baseline (ETA accuracy, planning time, exception rate) to evaluate AI against?
7. Are your key operational systems API-accessible, or portal-only?
8. Have you sized the data-integration cost in any AI business case you are considering?

Three or more "no" answers means the honest first project is the data layer — and that project has standalone ROI before any model runs.

What to watch over the next 12–18 months

• Agentic AI moves from demo to deployment. Industry projections suggest the large majority of companies will be investing in agentic AI by the end of 2026; in logistics, the winners will be determined by whose systems agents can actually read.
• The EU AI Act phases in. Obligations are arriving in stages through 2026–2027; operational AI in transport will mostly sit in lower-risk categories, but documentation and transparency expectations are rising. Worth a compliance check before deploying customer-facing AI.
• Data access keeps improving. The EU Data Act strengthens fleet owners' rights to their vehicle-generated data — structurally good news for anyone building a unified data layer across OEM systems.
• AI claims meet procurement scrutiny. Expect shipper RFPs to start asking how AI features are trained and on what data. "Show me your input data" is becoming the new "show me your references".

Closing thought

The AI race in road freight will not be won by whoever buys the cleverest model — models are increasingly commodities. It will be won by the operators whose fleets are readable: complete, normalised, high-frequency data that any model, today's or next year's, can learn from. That layer is buildable now, it pays for itself before the first model runs, and it is the difference between the 88% of AI projects that stall and the few that compound. Build the foundation; the intelligence will keep getting cheaper.

Glossary

• Agentic AI / AI agent: Software that doesn't just predict or recommend but takes actions toward a goal — e.g., rebooking a slot or notifying a customer — by reading and writing other systems.
• Machine-readable: Data accessible to software automatically via APIs, in consistent formats — as opposed to portals and files that need a human.
• Normalisation: Converting many incompatible data feeds into one consistent schema (units, field names, identifiers).
• Training data: Historical examples a machine-learning model learns from; in transport, mostly trip and event history.
• Ping / update frequency: How often a vehicle reports position or status; a core determinant of ETA model quality.
• CAN bus: The vehicle's internal data network; source of measured fuel and engine signals.
• API-first: An architecture where every capability is exposed programmatically, not only through a user interface.
• EU AI Act: The EU's risk-based AI regulation, phasing in obligations through 2026–2027.
• EU Data Act: EU regulation strengthening users' rights to data generated by their connected equipment, including vehicles.
• Primary data share: The proportion of a report (e.g., emissions) based on measured rather than modelled inputs.