In short
Everyone is selling AI, and I am often asked what mine does. The honest answer is surprising: in our software, AI does very little. Four specific tasks, all of them reading or drafting, and three of our six applications contain not a single line of it. The rest, which is the bulk of it, is ordinary software.
Then comes the question a customer put to me exactly this way: if AI is only a small, fenced-in detail, why should my data live in the cloud? The right answer has nothing to do with AI. The cloud is first a question of cost: everything around the software is shared between customers, so each one pays a small part of it. On a server in your own shop, it is possible, and we do it. But nothing is shared there, and it shows on the bill.
The four places a model touches your data
Let's start with the inventory, because a vendor who talks about AI without saying where it sits is saying nothing. Here is the complete list, as it runs today.
| Where | What the model does | What is sent to it |
|---|---|---|
| Inspection report | Reads the dimensions and tolerances on a drawing | A window of the drawing the inspector selected himself, not the whole drawing |
| Inspection report | Transcribes a handwritten measurement sheet | The image of that sheet |
| Quality system | Drafts a proposed customer email from a non-conformity | The text of that non-conformity |
| Standards module (in progress) | Reads a PDF standard to extract verifiable requirements | The imported standard |
That is all. There is no hidden fifth row. And the table reads both ways: whatever is not in it, no model ever sees. Your non-conformity history is not shipped somewhere to be "learned". Your prices, your customers, your employees, your measurement results do not leave the database.
Three of six applications contain none at all
This is the point I lean on most when I explain my work. Metrology (calibration, certificates, instrument recalls) contains not one line of AI. Neither does shop scheduling. Neither does the production-flow module. They are fully deterministic programs: the same data gives the same result today, tomorrow, and three years from now in front of an auditor.
And inside the quality system itself, the part most people instinctively assume is AI, isn't. When a non-conformity attaches to a process, a corrective action attaches to its non-conformity, a preventive action follows from a risk analysis (the whole mesh that makes critical points visible), those are rules written one at a time. One hundred and twelve of them, exactly. Not a model guessing: a matrix you can read, argue with and correct. The system's maturity index works the same way, through a calculation whose every step I can show you.
This is not a weakness I admit reluctantly. It is a trade requirement. A quality system must return the same verdict twice on the same facts, or it proves nothing.
The model may read and propose. It never gets to decide, and never gets to write to the database.
The rule that governs all four cases
Look again at the middle column of that table: reads, transcribes, drafts a proposal, extracts. Not one verb of decision. In all four cases the result lands in front of a human who sees it, corrects it and approves it before it really exists. Dimensions read off a drawing land in a table the inspector reviews line by line. The customer email is a draft in an editing window: nobody sends it unread.
This is what I call fenced-in AI, and I have set out elsewhere what it can do and what it must never do. The fence does not rest on the model's good judgment. It rests on the software around it: the program is what refuses to save an unvalidated value, and the program is what can be audited.
What actually leaves your shop
Let's be precise, because this is where most vendors stay vague.
What is sent to a model is always a fragment someone pointed at: a drawing area framed on screen, a measurement sheet someone photographed, the text of a non-conformity someone opened. Never the database, never a batch of history, never an overnight extract.
That fragment is processed first by a service hosted in Montreal. If that service is unavailable, the call may fall back to an equivalent service outside Canada, on that same reduced fragment and nothing else. I would rather say so plainly than promise a "never" the code does not guarantee. That is exactly the kind of nuance you should demand from a vendor. The useful question is not "is it in Canada", it is what exactly, held by whom, and in which case.
One more thing: nothing that is sent is used to train a model. Your drawings do not become somebody else's general knowledge.
The cloud was never about AI
That is the logical conclusion of everything above: AI is not the argument for the cloud. It is a few percent of the software and only ever works on fragments. If the cloud is justified, it is for another reason.
It is justified by shared costs. Around any trade software there is work nobody sees and that costs real money: a server running day and night, backups checked every night, security patches applied as soon as they come out, software updates, monitoring, someone who knows how to restore the database the morning a disk dies. In SaaS that work is done once, for every customer at the same time. Each customer pays a small share of it. That is what makes it possible to sell a thirty-person shop software it could never have kept running on its own.
It also explains why I have never seen a real quality system in a small manufacturer. Software that links non-conformities to processes and instruments to inspections was not technically impossible in 2005. It was long to write and expensive to keep alive, too expensive for a thirty-person shop that had to carry all of the running costs alone. Two things have changed: the cost of building that software, and the possibility of sharing its running costs across many shops.
The cloud does not sell intelligence. It sells a shared bill.
And on a server in your own shop?
I get asked this often, mostly by careful quality managers, which is rather a good sign. The answer is yes: we also install our software on a server in the shop. But you should know what you are buying, because it is not the same product at the same price.
Nothing is shared. The server, its installation, commissioning, backups, updates and follow-up serve a single customer. Everything the cloud spreads across all customers falls on one bill. It is mechanical: a server for one shop costs more than a share of a server for a hundred shops.
Updates happen one installation at a time. In SaaS, a fix reaches everyone the same day. On a server, each installation is updated separately, on its own schedule and with its own checks. That is extra work, and it gets paid for.
Someone has to look after it on site. A power cut, a full disk, a workstation that can no longer see the server: on a local server those problems happen at your place and get fixed at your place. You need to know who calls whom, and at what time.
Drawing analysis still goes through Montreal. Even on a server, automatic dimension reading uses the same analysis service, with the same fragments the inspector selected. A local server keeps your data at your place; it does not make the table at the top of this article disappear.
This is not an argument against local servers. They have real reasons to exist: a customer who requires by contract that data stays inside the building, a shop that already has an IT person and a server room, an internal policy that is not up for negotiation. In those cases it is the right choice, and it is worth what it costs. What I want to avoid is a shop choosing it in the belief that it saves money. It is almost always the opposite.
Three commitments, either way
Cloud or server, three things have to be true, and checkable by you.
You know where your data lives. In the cloud, the database and files are hosted in Montreal, a choice made when each service was created and not added afterwards, because that decision is irreversible. On a server, they are at your place. Either way, what Quebec law requires is not something we apply grudgingly: it was the architecture from the first line.
AI stays fenced in and small. The four uses in the table, on fragments a human pointed at, with no right to decide or to write, and never used to train anything. If that list ever grows, it will grow in writing.
You leave with everything, whenever you want. A full export of your data in readable formats, at any time, without negotiation. The cloud worries people for a legitimate reason, the fear of being held hostage. The answer to that is reversibility, not location. A vendor who hosts your data but lets you leave with it is less risky than software installed at your place whose data is locked in a format nobody can read back.
Questions to ask any vendor
You don't have to take my word for it, and it would be a bad habit if you did. These questions apply to anyone selling you software that talks about AI. Vague answers are an answer in themselves.
First: exactly where does a model touch my data, and what is sent to it? A precise answer looks like a table. A fuzzy one means nobody did the inventory. Second: who decides, it or me? Look for the point where a human approves before the data exists. Third: does the software still work if the AI is unavailable? Ours does: the inspector types the dimensions by hand, as before, and everything else carries on. Software that stops without its model is not trade software, it is a demo.
Fourth, the one that settles the cloud debate: what is shared between your customers, and what would I pay for alone on a server? A vendor who cannot answer has not done the math, or does not want to show it to you.
And the last one, which holds for both options: if I leave in two years, what do I take with me, in what format, and how long does it take?
The "cloud or local server" debate is almost always framed wrong. It is not a question of AI, nor even really of place. It is a question of cost and control: knowing what you pay for alone, knowing what leaves, and being able to leave. I have described elsewhere the discipline that keeps those answers honest.
The convictions defended in this article are the ones that guided the development of Asterion Solutions, a suite of trade-specific applications built for small manufacturers who want to structure their quality without piling on administrative work.