The AI-Ready Fleet Data Checklist: What to Fix Before You Buy a Single Model

Before any AI project — predictive ETAs, automated planning, agentic workflows — there is a checklist, and most road freight operations have never run it. Industry surveys suggest the great majority of AI agent initiatives never reach production, with infrastructure gaps cited as the leading cause. This post turns that lesson into a practical, twenty-point audit across five dimensions: coverage, frequency, consistency, history, and accessibility. Run it in an afternoon with your fleet manager and IT lead; the score tells you whether your next investment should be intelligence — or plumbing.

Why a checklist beats a vision

AI strategy discussions in transport tend to start at the wrong end: with use cases, vendors, and demos. Six months later the pilot is stuck, and the post-mortem always finds the same culprits — half the fleet wasn't in the data, the feeds disagreed with each other, there was no history to train on, or the systems involved could only be operated by a human with a mouse.

These failures are predictable. Literally: you can predict them with a checklist, before spending anything. The five dimensions below are the load-bearing walls of every operational AI use case in road freight. Score each honestly. A "no" is not a failure — it is a work item with a known fix, and most of the fixes pay for themselves before any model runs.

Dimension 1 — Coverage: is the whole fleet in the data?

The question AI forces is brutally simple: what share of your network's movements produce data that reaches you?

1. Are all owned trucks reporting into a system you can access programmatically?
2. Are trailers tracked — including when coupled to third-party tractors?
3. Are subcontractor vehicles in the same data layer as your own fleet?
4. Do you know your coverage number — the percentage of total movements with data — rather than assuming it?

Subcontractors are where most operations fail this dimension. If partners run a major share of your kilometres outside the data layer, any AI you deploy manages the minority of your risk. Coverage is a multiplier on everything downstream.

Dimension 2 — Frequency and latency: is the data fresh enough to act on?

5. Do you know the real position-update interval per data source (not the brochure number)?
6. Are your most important traffics covered by updates at least every minute or two?
7. Does data arrive within seconds-to-minutes of the event, not in nightly batches?
8. Are there known dead zones (ferries, certain countries, certain devices) — and are they documented?

Live use cases — ETAs, exception handling, agentic actions — need live data. A 15-minute ping interval that is fine for monthly reporting is disqualifying for prediction. Frequency is also the cheapest thing to discover and among the cheapest to fix, often a configuration or contract change rather than new hardware.

Dimension 3 — Consistency: does the data agree with itself?

9. Are units, timestamps, and time zones normalised across all sources?
10. Does every vehicle have one identity across systems (not three spellings of the same plate)?
11. Are events like "arrival" and "stop" defined the same way everywhere?
12. When two systems report the same trip, do they tell the same story?

This is the Babel problem, and it is the least visible dimension because dashboards hide it — a human reading a screen unconsciously corrects inconsistencies. Models don't. They learn the inconsistencies as if they were real patterns. Normalisation is unglamorous and decisive, and it is precisely the work that should be done once, centrally, rather than per project.

Dimension 4 — History: is there anything to learn from?

13. Can you produce a year of completed trips — positions, stops, durations — per vehicle and lane?
14. Is that history queryable (database/API), not archived in monthly PDFs?
15. Are site events (arrival, departure, dwell) recorded with timestamps in the history?
16. Is measured fuel consumption stored per trip, not just aggregate monthly figures?

Models learn from the past. An operation that has been discarding or PDF-burying its movement history has no training data, no baselines, and no way to even measure whether AI helps. If history is thin, the right move is to start accumulating it now — through the same data layer that fixes dimensions 1–3 — and let it deepen while you plan.

Dimension 5 — Accessibility: can software read it without a human?

17. Is every key data source available via API, not only a vendor portal?
18. Could a developer (or an AI agent) pull yesterday's full fleet activity programmatically today?
19. Are access rights and credentials owned by you, not locked to a vendor relationship?
20. Is there one place to integrate against, rather than a dozen parallel connections to maintain?

The agentic wave sharpens this dimension: agents act by reading and writing systems. Every portal-only source in your stack is invisible to them. "Everything a human can see, software can request" is the standard to hold vendors to — and the EU Data Act is strengthening your legal position to demand exactly that for vehicle-generated data.

Scoring it — and what the score means

Count your yes answers out of twenty:

• 16–20: AI-ready. Your constraint is use-case selection and change management, not data. Start with the narrowest high-volume use case and measure hard.
• 10–15: Foundation first. One or two dimensions need targeted work — typically subcontractor coverage or API accessibility. Fix those in parallel with a contained pilot on your strongest data.
• Below 10: Plumbing before intelligence. An AI purchase now would join the failed-pilot statistics. The good news: the remediation — one normalised feed across the fleet — has standalone ROI in visibility, detention billing, and emissions reporting before any model runs.

How CO3 does this today

CO3 is, in effect, the remediation for dimensions 1–3 and 5 delivered as a service: 500+ telematics and OEM integrations covering trucks, trailers, and subcontractors (coverage), normalised into one consistent schema (consistency), delivered through a single API (accessibility), at the native frequency of each source — with no new hardware. History (dimension 4) starts accumulating from the day the feed is live, and per-leg CO2 reporting with method labelling, aligned with the GLEC Framework and ISO 14083, comes from the same pipe. One integration project instead of twenty.

Getting started

1. Run the audit this week. Twenty questions, three people (operations, fleet, IT), one afternoon. Disagreement about an answer is itself a finding.
2. Fix the cheapest disqualifier first. Usually it is discovering real ping frequencies and renegotiating them, or connecting the top five subcontractors. Visible progress in weeks builds the mandate for the rest.
3. Only then shortlist AI. With the audit in hand, vendor conversations invert: instead of being sold a model, you are qualifying who can work with — or fix — your actual data estate.

Self-assessment

The twenty questions above are the self-assessment — print the five dimensions and score them with your team. CO3 can run the audit with you against your actual fleet, including a measured coverage and frequency report per source.

What to watch over the next 12–18 months

• AI-readiness enters due diligence. Expect shippers, investors, and acquirers to start asking for exactly this audit; a documented data estate is becoming an asset on its own.
• Agent protocols standardise. Emerging standards for how AI agents talk to operational systems will reward API-first stacks and strand portal-only ones further.
• Data Act enforcement matures. Practical mechanisms for accessing your vehicles' data keep improving — renegotiate sources that score badly on accessibility.
• History compounds quietly. Every month on a normalised feed adds training data no competitor can buy retroactively. The earliest fix appreciates the most.

Closing thought

The AI projects that succeed in road freight are not the boldest — they are the best-fed. Twenty questions separate ambition from readiness, and every "no" is a fixable, fundable work item with value of its own. Run the checklist before the vendor demos, and you will be in the small group whose first AI project is not their last. CO3 can take most of the list off your desk in one integration.

Glossary

• AI-ready data: Fleet data that is complete, frequent, consistent, historical, and machine-readable enough for models and agents to consume without manual repair.
• Coverage: The share of total fleet movements (own and subcontracted) producing accessible data.
• Latency: Delay between an event happening and its data being available to you.
• Normalisation: One schema, one set of units, one identity per vehicle across all sources.
• Queryable history: Past movement data stored so software can retrieve and filter it (database/API), not document archives.
• API (Application Programming Interface): Machine-to-machine access to data; the opposite of portal-only access.
• Agent (agentic AI): Software that takes actions across systems autonomously; requires API access to function.
• EU Data Act: EU regulation strengthening users' rights to data generated by connected products, including vehicles.
• Dead zone: A known gap in data coverage (geography, device type, or operational situation), tolerable only if documented.