Is Your Site Ready for AI? Assessing Processes, Data, Infrastructure and People

Why a single 'ready or not' answer misleads

The gap between AI ambition and execution rarely comes from the technology. Research-oriented and practitioner sources converge on the same point: an organization can be well funded and digitally advanced yet still unable to move AI past a demo. The practical difference is readiness — whether strategy, processes, data, technology and people are aligned to adopt and scale a system responsibly.

At a physical operating site this distinction is especially visible. You may already run cameras, sensors and a warehouse management or CMMS system, which makes the site feel 'AI-capable.' But capability describes what equipment exists; readiness describes whether you can feed a model trustworthy inputs, deploy it without breaking operations, and act on its output. Before choosing any algorithm, decide which processes the AI will touch and whether a human can verify each recommendation.

• AI maturity models (for example, enterprise models mapping experiment → pilot → industrialization → future-ready stages) show that most value appears only after pilots become repeatable, governed operations.
• Readiness should be scoped per use case, not declared for the whole site at once.

Processes: what the model will actually attach to

AI does not reason about a vague activity; it consumes an input and predicts or proposes an output for a defined workflow. If a process is executed differently by each shift, lives only in workers' heads, or has no owner, there is nothing stable for a model to learn or for staff to be held accountable against. Automation simply reproduces undocumented variation faster and at larger scale.

Assess process readiness by asking whether a new employee can learn the task from documentation in under an hour, whether steps have named owners, whether exceptions are described, and whether completion is recorded in a system rather than in notebooks or chat. Processes worth automating first are high-frequency, high-volume and measurable, because they generate enough consistent data to train and validate a model. Simplify and stabilize the process before layering AI on top of it.

• One reliable test: pick a candidate process and ask three people who run it to describe the steps independently; if the answers diverge, the process is not ready.
• Standardize and document before you automate.

Data: the real constraint at most sites

Every model inherits the flaws of its inputs. If the data is inconsistent, incomplete, mislabeled or undocumented, the model will reproduce those defects — often invisibly and at scale. Data readiness therefore comes before model readiness. Start with an inventory: which sources exist (cameras, sensors, ERP, maintenance logs, shift reports), where they physically sit, what formats and schemas they use, how often they update, and who owns each set.

For vision-driven use cases on a site, labeling is a separate and commonly underestimated cost. Detecting 'a pallet blocking an aisle' or 'a worker without PPE' requires a validated set of annotated images or events plus a documented definition of the event, so that reviewers and the model agree on what counts. Plan for data contracts that fix formats and refresh frequency, automated quality checks on completeness and timeliness, and lineage that lets you trace any event back to its source. On the regulatory side, video and other data involving identifiable people may trigger data-protection duties; that is general context, and specific obligations vary by jurisdiction, so confirm local rules before deployment.

• Score data on availability, quality, coverage, governance and traceability — not on volume.
• A model is only as reliable as the labeling and definitions behind its training set.

Infrastructure: from pilot to production

Infrastructure readiness is not about owning the biggest servers. It is about whether the site can reliably move a model from a demo on a laptop to a governed production service. Key checks include network bandwidth and latency to carry video or sensor streams to where processing happens, storage that can retain and replay recorded events, compute capacity (cloud, on-premise or edge) for inference, and identity and access controls so that only authorized roles can view or act on results.

Equally important is integration with systems people already use — access control, work-order, ERP or incident platforms. An alert that ends in a separate portal that nobody opens creates no value. Plan the interfaces that let a detected event become a verifiable task in an existing workflow, and define security controls for data at rest and in transit, audit logging, and versioning of models so that behavior changes are explainable and reversible.

• Confirm the weakest link: a great camera feed is useless if the network drops frames or the storage deletes the evidence you need for review.
• Design for observability — dashboards, run history and monitoring of both model performance and data drift.

People: ownership, skills and change readiness

Technology accounts for only part of successful adoption; the larger challenge is cultural. Site teams will not act on an AI output they do not trust or understand. Assess whether a named person owns AI at the site and can take decisions, whether data and workflow owners exist for each critical source and process, and whether operators and supervisors have the skills to interpret results and the authority to act on them.

Plan training that connects AI to daily work rather than abstract tool demos, and create a safe space for experimentation where employees can challenge false outputs. Involve representatives of the affected functions in the assessment — finance with the CFO, data and platforms with the technical lead, people with HR — because no single individual can judge all four pillars objectively. Watch for the capability-adoption gap: what the technology can do versus what people are actually prepared and enabled to do.

• Every pilot should have a named owner with authority, or it will die once daily operations take priority.
• Communicate what the system does and where a human stays in the loop before rollout.

Scoring the site and building the roadmap

A maturity profile, not a pass/fail verdict, is the most honest output. Score each pillar on a small scale using observable evidence — for example, level 1 ad hoc, level 2 defined and documented, level 3 managed with monitoring, level 4 optimized and automated. Because few sites sit at the same level across all pillars, the value is in seeing which gap blocks the next chosen scenario rather than forcing every domain to the top, which is rarely economically justified.

Re-run the assessment quarterly and record concrete changes, not abstract 'digitalization' claims. Reassess priorities with proof-of-concept results: document development time, testing cycles and observed accuracy, then use those baselines to estimate realistic timelines for the next use case. Add buffer for learning and iteration, and let pilot lessons adjust which scenario you scale next. Schedule and vendor plans change, so confirm current details from the provider before committing.