The VP of operations toured a competitor's plant last month and came back with a phrase that has been ringing in your ears ever since: "smart factory." She saw a wall of dashboards, a digital twin spinning on a screen, and a vision system grading parts at line speed, and now she wants to know what your plant's AI plan is, with a budget number, by the end of the quarter. You walk back out to your own floor to think about it. The flagship line still runs on a PLC (the programmable logic controller, the industrial computer that runs the machine's logic) that was commissioned in 1997. The historian, the database that is supposed to be quietly logging every sensor reading from the line, has tags that stopped updating two years ago and nobody noticed. Your best quality inspector, Dave, retires in November, and his twenty years of "this machine likes to be warmed up before the first run" lives nowhere but his head. You are short three maintenance techs. And when you ask your IT manager whether you can even see the network traffic on the plant floor, he gives you a look that tells you the honest answer is no. This is the gap between the keynote and the floor, and the single most valuable thing you can do before you spend a dollar on AI is to measure that gap honestly. That measurement is what a plant AI readiness assessment is, and the plants that skip it are the plants that buy a beautiful system that quietly dies in its first month because the plant it was bought for does not actually exist.

Readiness Is About the Plant You Have, Not the One in the Brochure

The first discipline of a readiness assessment is honesty about the starting point, because almost every AI failure on the floor traces back to a plant that assessed itself against the brochure instead of against the mirror. The brochure assumes a clean, instrumented, greenfield plant, one built new with modern controls and full data capture from day one. Your plant is almost certainly brownfield, meaning it is an existing facility with aging controls, partial instrumentation, and decades of accumulated workarounds. That distinction is not a minor footnote. Research consistently shows that greenfield plants deploy AI 40 to 60 percent faster than brownfield plants, and the difference is not the algorithm. It is everything underneath the algorithm: the data, the network visibility, the workforce, and the governance.

A readiness assessment is the structured process of measuring those four foundations before you commit to a use case, so that your AI roadmap starts from the plant you actually have. The four foundations are data readiness, OT visibility, workforce readiness, and governance readiness. Think of them as the four legs of the table the AI will sit on. A model is only the tabletop. If any leg is missing, the tabletop falls over no matter how beautifully it is finished, and the most expensive mistake in plant AI is buying a gorgeous tabletop for a table that has two legs.

Here is why the honesty matters in dollars. Suppose your VP approves a 250,000 dollar vision-QA project on the strength of the competitor tour, and the project gets installed on a line where the lighting changes between shifts, the part-tracking data lives on a paper traveler that nobody digitizes, and the operators were never consulted. Within two months the false rejects pile up, the operators tape over the reject light, and the system is quietly switched off. The 250,000 dollars is gone, and worse, the organization now believes "AI does not work here," which poisons the well for the next three years. A readiness assessment that cost a few weeks of an engineer's time would have flagged every one of those failure points before the purchase order was signed. The assessment is not a delay to the AI plan. It is the cheapest insurance the AI plan can buy.

Assess the plant you have, not the plant in the brochure, because the AI you buy will be deployed on the first one and not the second.

The output of the assessment is not a grade for its own sake. It is a map that tells you two things: which use cases are reachable now with the foundations you have, and which foundations you must strengthen before the high-value use cases become possible. That map is what turns the VP's vague demand for an "AI plan" into a sequenced, defensible roadmap, which is exactly what the next lesson builds. This lesson builds the assessment that the roadmap stands on.

Data Readiness: The Fuel or the Fiction

AI on the floor runs on data the way the line runs on compressed air, and most plants overestimate how much usable data they actually have. Data readiness is the assessment of whether the data an AI use case needs exists, is accessible, is accurate, and is labeled. Each of those four words is a place where the fuel turns out to be fiction, and you have to check all four honestly.

Does the data exist at all? The historian is the obvious place to look. The historian is the time-series database that logs sensor tags, temperatures, pressures, vibration, cycle counts, over time, and a healthy historian is the single richest fuel source a plant has for predictive maintenance. But the brief's reality holds: many plants have a historian nobody has queried in years, with tags that quietly stopped updating after a sensor failed or a configuration changed. The first data-readiness check is brutally simple: pull the last 90 days of the tags your use case would need and look at them. If a third of them are flatlined, frozen, or missing, you do not have the data you thought you had, and the predictive-maintenance model you were dreaming about cannot be trained on a flatline.

Is the data accessible? Data that exists but is locked inside a PLC, a proprietary controller, or a vendor system you cannot export from is, for AI purposes, data you do not have. Accessibility is an integration question, and it is where the OT boundary (covered in the next section) starts to bite. A common trap is finding rich data trapped behind a 1997 PLC that speaks a protocol no modern system reads without a translation gateway. The data is there; reaching it is a project unto itself, and that project must appear in your readiness map with a cost attached.

Is the data accurate? A historian tag can be updating and still be wrong, a drifted sensor reading a temperature ten degrees low, a flowmeter that was never recalibrated. Accuracy matters because a model trained on inaccurate data learns the inaccuracy and repeats it with confidence. The readiness check here is a sampling exercise: cross-check a sample of the logged values against a known reference or a manual measurement, because a model is only as trustworthy as the worst sensor feeding it.

Is the data labeled? This is the one that ambushes vision-QA projects. A vision model that grades parts must be trained on images that a human has already labeled as good or defective, and a predictive model that predicts failures must be trained on history where the failures are marked. Most plants have neither. They have thousands of part images nobody labeled and a CMMS (the computerized maintenance management system, the software that holds work orders and maintenance history) full of free-text notes like "fixed it" that no model can learn a failure pattern from. Labeled data is the scarcest fuel of all, and the readiness assessment must be honest that creating it is often the single largest hidden cost of a floor-AI project.

Here is the worked number that makes data readiness concrete. A vision-QA model for a subtle cosmetic defect might need a few thousand labeled defect images to train and validate honestly. If your defect rate is 0.5 percent and you inspect 2,400 parts a day, you produce only about 12 defects a day, so collecting 2,000 labeled defect images at the natural rate takes nearly 170 days of production before you can even train. A readiness assessment that surfaces this fact changes the whole plan: you either start collecting and labeling images now while you build the rest, or you pick a use case where the labeled data already exists. The plants that skip this check discover the 170 days after they have signed the contract, when the vendor asks for training images the plant does not have.

OT Visibility: You Cannot Secure or Feed What You Cannot See

The second foundation is the one most quality and reliability engineers underweight because it lives in a different department, and it is the foundation that can stop an otherwise perfect AI plan cold. OT visibility is your ability to see, monitor, and safely connect to the operational technology on your floor. OT (operational technology) is the world of PLCs, SCADA (the supervisory control and data acquisition system that operators watch and use to run the line), sensors, drives, and the network that ties them together. It is distinct from IT (information technology), the world of business computers, email, and the corporate network. The boundary between them, the OT/IT boundary, is where floor-AI projects either get safely fed with data or create a security hole that an auditor and a hacker both walk through.

The hard number from the brief sets the stakes: 78 percent of OT networks lack centralized monitoring, according to Dragos. Read that plainly. More than three quarters of plants cannot centrally see what is talking to what on their own floor network. You cannot bolt AI onto a plant you cannot see, for two separate reasons. The first is data: if you do not know what devices exist and what they emit, you cannot reliably feed a model. The second is security: connecting an AI system, especially one that reaches back to the cloud, to an OT network you cannot monitor is opening a door in a wall you cannot watch.

The OT-visibility portion of the readiness assessment asks a sequence of concrete questions. Do you have an asset inventory? A list of every device on the OT network, its make, model, firmware, and what it connects to. Most plants do not, and you cannot govern what you have not inventoried. Can you monitor the traffic? Centralized monitoring that would show you anomalous communication, the thing 78 percent of plants lack. Where is the OT/IT boundary, and how is it controlled? Is there a firewall, a demilitarized zone, a one-way data diode that lets sensor data out to your analytics without letting commands back in. Can AI stay advisory? The brief's hard constraint holds: keep AI advisory and out of direct control of anything that moves unless it is properly governed, and never put AI first into a safety-critical control loop.

This last point deserves a worked example because it is where engineers get seduced. Imagine a vendor demo where the AI does not just predict a bearing failure but automatically adjusts the drive speed to extend the bearing's life. It looks brilliant. On a brownfield plant with no OT monitoring, it is reckless, because you have put an AI system with cloud connectivity into a position to change how a machine physically moves, on a network you cannot watch, with no way to prove what it did when an auditor asks. The readiness-honest version keeps the AI advisory: it writes a prioritized work order and a human makes the change. The advisory version is deployable today. The control version waits until the OT foundation is built. A readiness assessment is what tells you which version your plant can actually support, and selling the advisory version to the VP as "phase one" is far better than selling the control version and having it become the incident that ends the program.

Workforce Readiness: The Talent Cliff Is the Real Constraint

The third foundation is the one the brochures ignore entirely and the one that actually decides whether AI survives on your floor, because AI on a plant is not a system you install, it is a system people have to trust, run, and verify. Workforce readiness is the assessment of whether your people can adopt, operate, and verify AI, and it sits on top of the defining reality of 2026 manufacturing: the talent cliff. Roughly 2 million manufacturing workers need reskilling by 2026 against about 500,000 unfilled roles, 78 percent of manufacturers report skills shortages, and 85 percent say those shortages are already hurting product quality. The talent cliff is not a reason to delay AI. It is the reason AI matters now, because AI is the knowledge multiplier that lets a thinner, greener crew run a safe, high-quality line. But a multiplier still needs something to multiply, and that is where workforce readiness comes in.

The assessment asks four workforce questions. Who will verify the AI? Every floor-AI output, a flagged defect, a predicted failure, a drafted work instruction, needs a human who can judge whether it is right. If your plant has no one with the time and skill to verify, the AI will either be blindly trusted (dangerous) or blindly ignored (wasteful). Who will operate it day to day? The operator at the station and the tech in the field are the real users, and if they were not consulted, the system will be resented and bypassed. Will the crew trust it? This is the false-alarm social contract: an operator who has been burned by a false reject will disable the green light, so workforce readiness includes asking whether your crew has the bandwidth to live through the early false alarms without giving up. Who is retiring, and what walks out with them? Dave in November is not a side issue, he is a core readiness finding, because the knowledge that would make the AI smart is leaving the building.

The single most important workforce finding ties to a number worth holding onto: structured training programs see 3 to 4 times higher adoption than self-directed learning. This is the difference between buying AI and having AI actually used. A plant that hands operators a new vision system and a one-page PDF will see adoption stall. A plant that runs a structured program, hands-on, role-specific, with the operators who will use the system, sees three to four times the uptake. The readiness assessment must therefore measure not just whether you have skilled people but whether you have a structured way to bring them along, because the cheapest model in the world delivers nothing if the crew never adopts it.

Work the dollars on the retiring expert, because it reframes the whole assessment. When Dave retires, the plant loses the only person who can hear a bearing going bad before the sensor catches it and the only eyes that spot a subtle cosmetic defect at line speed. If his absence raises the escape rate by even half a point on a line that ships safety-relevant parts, a single resulting containment can cost more than a month of the entire AI program. Capturing Dave's knowledge before November is therefore not a soft, nice-to-have item on the assessment. It is one of the highest-return moves a thinning plant can make, and a readiness assessment that does not flag the retirement wave has missed the most valuable and most perishable asset in the building.

Governance Readiness: Can You Prove What the AI Did?

The fourth foundation is the one that turns a working AI deployment into a defensible one, and it is the foundation that decides whether you survive the customer audit. Governance readiness is the assessment of whether you can control, document, and stand behind every AI-touched decision. It is the plant-level version of the cardinal rule that runs through this whole program: the customer audits you, not the vendor, and accountability for an AI-touched quality or maintenance decision stays with the plant and the human who signs the record. "The model flagged it" is never a sufficient answer to an auditor or a customer.

The governance portion of the assessment asks whether the structures that make AI accountable already exist or need building. Is there an audit trail? Can you reconstruct an AI-touched decision to the part or the work order, with the input, the model output, the human disposition, and the owner. A plant that already keeps disciplined quality records is closer to AI-ready than it realizes; a plant whose records live on paper travelers and operators' memories has a governance gap to close before AI in the loop is safe. Who signs? Every AI-assisted decision needs a named human owner, and the assessment must confirm that ownership is assigned, not assumed. Does AI fit the quality system? The customer's quality framework, IATF 16949 in automotive, AS9100 in aerospace, already has slots for control plans, FMEAs, and the PPAP, and AI must appear inside them honestly rather than running as an ungoverned bolt-on. Is there a verification discipline? The job has shifted from producing the draft to verifying the draft against the drawing, the standard, and the historian, and a plant must have, or build, the habit of verifying every AI-touched spec, procedure, and root cause before it is trusted.

The reason governance readiness is a foundation and not an afterthought is timing. You can bolt an audit trail onto a deployed system, but it is far cheaper and more reliable to design the recording in from the start. A plant that assesses its governance readiness before deployment builds the audit trail into the workflow; a plant that skips it discovers, on the morning the customer's supplier quality engineer arrives, that it has a system making decisions it cannot reconstruct. The worked consequence is the same forty-thousand-dollar containment and the major nonconformity that the vision-QA governance lesson details, except now it is compounded because the plant deployed AI without ever asking whether it could stand behind the decisions. Governance readiness is the question that prevents that morning.

Scoring the Assessment and Turning It Into a Go or No-Go

An assessment that produces four impressions is interesting. An assessment that produces a defensible go-or-no-go decision for a specific use case is useful, and the difference is a simple scoring discipline you can run with a spreadsheet and a cross-functional team. The point is not a precise number; it is a structured, honest, shared picture that the VP, the quality manager, the maintenance lead, and the OT engineer all looked at together.

Score each of the four foundations for the specific use case you are considering, because readiness is always relative to a use case, not absolute. A plant can be perfectly ready for an AI-assisted work-instruction drafting tool, which needs almost no floor data and touches nothing that moves, and completely unready for a closed-loop predictive-maintenance system on the same day. Use a simple three-level scale for each foundation: ready (the foundation supports the use case now), gap (the foundation needs defined work first), or blocker (the foundation makes the use case unsafe or impossible until rebuilt). The scale is coarse on purpose, because false precision is its own form of dishonesty.

Then apply the decision rule that keeps plants out of trouble: any blocker is a no-go for that use case until the blocker is resolved. A plant with excellent data, a trusting workforce, and strong governance but zero OT visibility is a no-go for anything that connects to the control network, no matter how green the other three foundations are, because the blocker is a blocker. This rule is what stops the seductive failure where three strong foundations talk a team into ignoring the one fatal one. The brief's kill-criteria thinking applies directly: no labeled data, an unstable process, a safety-critical control loop, or an unmonitored OT network are each, on their own, a reason not to deploy yet.

Here is the assessment turning into a roadmap, which is the whole payoff. Suppose you score three use cases. AI-assisted root-cause drafting comes back ready, ready, ready, ready: deployable now, low risk, real value, so it goes first and earns the early trust. Vision-QA on the cosmetic defect comes back gap on data (you need 170 days to collect labeled images), ready on OT (it does not touch control), gap on workforce (operators need a structured program), ready on governance: deployable soon, once you start the image collection and the training now, so it goes second and you start its prerequisites today. Closed-loop predictive control comes back blocker on OT (no monitoring) and blocker on governance (no audit trail for an automated action): no-go until the OT foundation and the audit trail are built, so it goes last or not at all. That sequence, the ordered list of what to do first, second, and never-yet, is the readiness assessment's real product, and it is exactly the input the roadmap lesson turns into a plan the VP can fund. You walk back into her office not with a vague "smart factory" promise but with a sequenced, honest plan grounded in the plant you actually have, and that is the difference between an AI program that survives its first year and one that becomes the cautionary tale the next plant tours.

Key Takeaways

• A readiness assessment measures the gap between the keynote and your floor before you spend a dollar, because the AI you buy is deployed on the brownfield plant you have, not the greenfield plant in the brochure, and greenfield plants deploy AI 40 to 60 percent faster for reasons that live underneath the algorithm.
• Readiness rests on four foundations: data, OT visibility, workforce, and governance. The model is only the tabletop; if any leg is missing the table falls over, and buying a gorgeous tabletop for a two-legged table is the most expensive mistake in plant AI.
• Data readiness checks four things honestly: does the data exist (pull 90 days and look for flatlines), is it accessible (or trapped behind a 1997 PLC), is it accurate (sample against a reference), and is it labeled. Labeled data is the scarcest fuel; collecting 2,000 defect images at a 0.5 percent rate on a 2,400-part line takes nearly 170 days, and that hidden cost must surface before the contract, not after.
• OT visibility is a hard constraint: 78 percent of OT networks lack centralized monitoring, and you cannot safely feed or secure an AI system on a network you cannot see. Keep AI advisory and out of direct control of anything that moves unless properly governed, and never put AI first into a safety-critical control loop.
• Workforce readiness is the real constraint behind the talent cliff: 2 million workers need reskilling, 85 percent of manufacturers say shortages hurt quality, and structured training programs see 3 to 4 times higher adoption than self-directed learning. AI is the knowledge multiplier for a thinner crew, and capturing a retiring expert like Dave before November is one of the highest-return, most perishable moves a plant can make.
• Governance readiness asks whether you can prove what the AI did: an audit trail to the part, a named human who signs, a fit inside the customer's quality system, and a verification discipline. The customer audits you, not the vendor, and building the audit trail in from the start is far cheaper than bolting it on the morning the auditor arrives.
• Score each foundation per use case on a coarse three-level scale (ready, gap, blocker), because readiness is relative to a use case, not absolute. Apply the decision rule that any single blocker is a no-go until resolved, which stops three strong foundations from talking a team past one fatal one.
• The assessment's real product is a sequenced roadmap: deploy the ready-ready-ready-ready use case now to earn trust, start the prerequisites for the gap use cases today, and defer the blocker use cases until their foundations are built. That sequence is what turns a VP's vague demand for an AI plan into a defensible, fundable program grounded in the plant you actually have.