Should You Invest in AI Yet? An Honest Answer for Manufacturers

You can price a machine in your head.

The quote is the smallest part. Rigging and electrical, tooling, training, plus the weeks where output dips while people learn it. The spares you'll be buying in year three. You know roughly what it should cost, what it's worth if you sell it in year eight, and when it will have paid for itself. When a capital request lands on your desk you can tell inside a minute whether the person who wrote it has done that work.

Then someone brings you AI, and every one of those questions gets answered in language built to avoid them.

That is the actual problem here, and it has little to do with whether the technology works. Everyone advising you to move has a financial interest in the answer being yes. The vendors, the integrators, the large consultancies, and firms like ours. So the question you actually have, should we do this yet, is precisely the one nobody around you can answer straight.

Here's how you answer it yourself. For a fair number of manufacturers reading this, the answer today is no, and I'll show you how to tell whether you're one of them. The way you get there is the same discipline you already use when buying any other asset: four questions, asked in order, and your answers put you in one of three places by the end of this piece.

There is real money here, and the sum takes ten seconds

A point of margin at a $50M manufacturer is about $500,000 a year. At $250M it's $2.5M. That's multiplication. You don't have to believe anything I say for it to hold.

Do that sum before anything else, because it sets the size of problem that deserves a capital conversation. It also rules a lot out fast. A chatbot on your website isn't a $500,000 problem. Neither is a pilot that produces a dashboard.

I'm not going to tell you AI will deliver you a point of margin. Plenty of what gets sold under that label never comes close, and I'll get to why. But that's the number this decision has to be measured against. If you can't draw a line from what you're being offered to something of that size, you can stop reading and keep your money.

You're not behind, whatever you heard at the trade show

The pitch you keep getting says adoption is nearly universal and you're the last one standing still. The numbers say otherwise, once you separate who's actually running AI inside an operation from who opened a chat window at a desk.

A December 2025 survey by Kaufman Rossin with NewtonX put 73% of mid-market manufacturers in the testing phase, with none of the hundred companies surveyed fully deployed. Take that for what it is: one survey, a hundred firms between $5M and just under $1B, all self-reported. McKinsey's work puts adoption at roughly 5% of manufacturing functions as of 2024. The headline figures showing 90%-plus are counting somebody in accounting using ChatGPT.

The pressure you're feeling is manufactured. Nobody in your peer group has this solved either. Being early on this doesn't mean much without a result to show for it, and most of what's called early right now is a pilot with no baseline and no clear owner, quietly on its way to getting shelved. Doing this slower, but doing it in a way that actually holds up, puts you ahead of a competitor who moved first and has nothing to point to.

This gives you room. Use it to make the decision properly, because that's the only route to the money in the section above.

Put the two purchases side by side

Take the discipline you already apply to a machine and point it at an AI purchase. Four questions fall out of it. Nobody selling you AI will ask you these, because AI mostly fails them in year one.

1. What is it attacking, and is that thing worth the money?

A machine gets bought because something is constraining you. A bottleneck operation. A scrap rate you can't get under. Quote turnaround that's losing you work. On-time delivery that's costing you a customer. Impressive has nothing to do with it.

Same test here. Name the constraint before you name the technology, then hold it against the figure above. If what you're pointing at can't plausibly move a number in that range, it doesn't belong in a capital request.

One filter kills a lot of ideas quickly. If your continuous improvement people could have fixed it and just haven't got to it, you don't have an AI problem. You have a challenge with scheduling, and AI is an expensive way to solve those.

2. Could you prove what it changed?

Replace a machine and you know what the old one ran at. Cycle time, uptime, scrap. Whether it improved isn't a matter of opinion.

Ask the same of the initiative on your desk. Two parts to it.

First, the data. Does it exist, does anyone trust it, and can you get it out of the system it's sitting in. The Kaufman Rossin survey has 55% naming legacy ERP integration as their top barrier and 45% still running siloed data. KPMG's 2025 work has 56% naming data as the primary obstacle. Different surveys, same finding.

Now the part vendors turn into a disqualification when they shouldn't. Your data being a mess is the normal condition for manufacturers, and it's fixable. It usually looks like this: three buildings, one shared terminal for logging job numbers, and operators who skip it half the time because typing it in costs them minutes they don't have. A walk to the floor tells you more about why than a data strategy deck ever will. Treat it as the first paid step rather than a reason to walk away.

The baseline is a different matter, and there's no way around it. If you can't say what the process costs you today, in dollars or hours or scrap, then no result afterwards can be defended. That's the quiet reason so many pilots that technically worked died anyway. Somebody in a review asked what changed, and nobody in the room could answer with a number.

3. Who owns it in eighteen months?

You know exactly who maintains the machine. There's a PM schedule, a parts supplier, and somebody who can tell from the sound that a bearing is going.

Ask who does that for the system after launch and the room usually goes quiet.

This is where these things die. A model drifts as your product mix changes and nobody notices for a quarter. The one IT person is already carrying the ERP. The engineer who understood it takes another job. An alert fires and nobody acts, because no workflow was ever built behind the alert.

That last one deserves saying plainly. A detection with no response attached is worse than having nothing, because now you're paying for something you've trained your people to ignore.

Whoever owns it is a budget line, whether you staff it or contract it out. Decide which before you sign, because "we'll figure that out after launch" is how the last system ended up abandoned. Somebody has to watch for drift, retrain it when the product mix moves, and keep what it costs to run under control. That's ongoing reliability work, and it costs something whether or not you plan for it.

4. Is the quoted number the real number?

You do this instinctively on a machine, adding the rigging and the first year of teething before anybody asks. Do it on purpose here.

Run the same exercise on the AI proposal, because usually nobody will run it for you. The license is the cheap part of an AI system. The lines that get left out of the quote are the ones carrying the cost:

• Integration into an ERP that's fifteen years old and was customized by people who no longer work there
• Instrumentation, if the data you need isn't being captured anywhere today
• The data work, usually the largest single line and the one nobody wants to quote
• Change management, meaning the weeks before people actually use the thing
• Running it in year two and year three, which is a permanent line item rather than a project cost

Here's a number worth knowing, because it holds up. For a SaaS product, budget another one to two times the first year's subscription just to get it integrated and running. For a system you're licensing outright, that multiple runs two to three times the license cost. After that, plan on fifteen to twenty-five percent of the license fee every year just to keep it working. Price the five lines above against the quote on your desk with that range in hand, and you'll know inside a day whether the number you were given was the real one.

There's a reason almost everything gets sold to you as a subscription instead of a project, and it isn't for your convenience. A subscription lands in the operating budget. A capital purchase has to clear an approval threshold that, dollar for dollar, sits roughly twice as high. The pricing model isn't an accident. It's built to get past the person who'd ask the four questions in this article, and that's worth knowing before you sign, whatever you end up buying.

There's a second question hiding inside the cost one, and it matters more than it looks. At the end of the machine purchase, you own the machine. Ask what you own at the end of this one. The models, the data work, the integration, the documentation: if those stay with the vendor, you've bought a liability with a monthly payment, and your CFO is right to treat it that way. If they're yours, you've bought an asset that can be extended, moved to another partner, or brought in-house.

Three honest answers

Run those four questions and you land in one of three places.

Not yet. Usually a missing baseline, or nobody to own it. This is the answer we give most often and the easiest one to act on. Spend the next quarter measuring the process you were about to point AI at, and name the person who'd own the system if you built it. Both are useful whether or not you ever build anything.

Not this. The constraint is real and AI is the wrong instrument for it, or the application is oversold at your size. The one we run into most is bespoke predictive maintenance, and it deserves a specific answer rather than a blanket one. Targeted work on a handful of instrumented, high-value assets does pay back. Rolling it across a plant generally doesn't, and roughly a quarter of manufacturers who pilot it ever get it past the first line.

Where you land depends more on what you actually run than most people admit. A CNC line is thick with sensors but thin on value per machine, so the math rarely closes. A bank of injection-molding presses running three shifts is a different animal: enough value riding on each asset, enough run hours behind it, for the case to hold together. If that's closer to your floor, it's worth a real look. If it isn't, and you don't have a maintenance owner or a failure history worth training on, you're funding a science project. I'd rather tell you that than sell it to you, and it's a category we could comfortably sell.

Two things get marketed as one here, and separating them saves money. Forecasting a failure weeks out needs sensor density and failure history most shops your size don't have. Helping the engineers you already employ find a fault faster, while it's still small, needs a great deal less.

We built the second kind on a line carrying thousands of sensors across hydraulics, pressure and temperature. None of it was reachable by the people who needed it, so faults got diagnosed after they had escalated and taken the line down with them. We connected that sensor data to something an engineer could question in plain English and get an answer back from. The data had been sitting there for years. What was missing was any way to talk to it.

Smaller problem than prediction, and the raw material was already bought. That is usually the shape of the one that pays.

Yes, and smaller than you were pitched. One constraint carrying real money. A baseline measured before anything gets built. A named owner with the time to own it. Kill criteria agreed in writing before the spend, so the thing can be stopped without anyone losing face. And an asset you own at the end.

You don't have to take this on faith. A chemical toll manufacturer working with Georgia's NIST-affiliated MEP center put $300,000 into digitizing batch data across two plants, mostly turning more than a hundred paper batch sheets into something that could be checked in real time. It caught a chiller heading for failure before it took a line down, and it's saving them $30,000 a month. Modest, slow to arrive, unglamorous to describe at a trade show. It's exactly the shape this piece has been arguing for: a real constraint, a modest scope, and data made usable before anything predictive got built on top of it.

Prove it pays on your own data before the capital moves. Validating feasibility and return takes weeks and costs a fraction of the build, and that order is the whole difference between a validated investment and a write-off you find out about in month seven.

A real yes is less exciting than the demo you were shown. It's also the one still running in year two, still paying, and worth more each time you extend it, because the data work and the plumbing underneath it are already bought.

Where it usually pays first, and it isn't the shop floor

Get to a yes and the instinct is to point it at the plant. Almost everything you've been shown lives there: predictive maintenance, vision inspection, digital twins. That instinct isn't wrong, either. The floor is usually the biggest number on the table, the one returning the most once you're actually running it properly.

But at mid-market scale the first money, and the first proof, is usually in the front office, and the reason is boring. Quoting and RFQ response, where cutting turnaround from days to hours means more quotes out the door and a better shot at the ones worth winning. It's also usually one person's problem, guessing under pressure, and getting the call when a quote comes in high or low. SOPs and work instructions, which is how you keep what your most experienced people know before they retire. Document and compliance handling. Forecasting on data your ERP already holds.

None of that needs a retrofit. None of it touches a control loop. None of it waits on your IT and controls people to agree on anything, which at some sites is the actual blocker.

That's also why it's where the discipline shows up first. Before you commit real capital to the floor, this is where you find out whether your organization can actually run the process: measure a baseline, hold a kill criterion, name an owner, own the result. Getting that wrong here costs you a quarter. Getting it wrong on the floor costs you a lot more, and you won't find out until later.

To be clear about our own position: we do floor work, and the example above is ours. It's also the harder one. It takes longer to stand up and costs more to integrate than the front-office equivalent, every time. If you're making a first move, make it the cheap one that proves the discipline works. That first move proves it both ways: whether your organization can actually hold a baseline and name an owner, and whether whoever's building it with you can do the same, before either of you commits to the expensive one. Then earn your way onto the floor with a baseline and a track record behind you.

So, should you?

For a good many of you the answer today is not yet, and that's worth more than a yes would be. It costs you a quarter of measurement instead of six figures and a conversation with your board you'd rather not have.

For the rest, the answer is yes. One constraint, smaller than the version you were pitched, with a baseline and an owner and something you own at the end. Do that once and the second one costs less, because the data work and the plumbing are already paid for. Get three or four of them running against constraints that matter and you're inside the range we started with, the $500,000 at $50M or the $2.5M at $250M. That's the actual path to it. There isn't a single purchase that gets you there.

Either way you now have the four questions, and you can run them on the next person who walks into your office with a deck. You've never had trouble judging a capital purchase. What's been missing is anyone willing to hand you a way to judge this one that doesn't depend on you saying yes.

Running them in the abstract only gets you so far. Against your own constraint, your own data, and your own answer to who would own the thing, they get sharper and they get uncomfortable faster. The AI Investment Diagnostic Tool is where you run them that way. Answer a short set of questions about your data, your budget, your timeline, and the problem you're actually trying to solve, and it comes back with a scored diagnostic of where you stand, the gaps most likely to sink a build, and which of the four questions above you'd struggle to answer today. It'll tell you where the value tends to sit in an operation your size before it tells you anything about us.