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 — the bulk of it — is ordinary software.
Which leads straight to the question that matters, and a customer put it to me exactly this way: if AI is only a small, fenced-in detail, why should my data live in the cloud? Install the thing on a server here. That is a fair question. Here is my answer, and what I commit to giving in exchange.
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 truly 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 — and 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.
So what is the cloud for?
Here is the logical conclusion of everything above, and it is not a comfortable one for me: AI was never the argument for the cloud. If it accounts for a few percent of the software and only ever works on fragments, then hosting cannot be justified by it.
Consider what the other ninety-five percent actually is. Forms. Business rules. Links between trade objects. A well-made PDF. A searchable history. None of that was technically impossible in 2005. Software that connects non-conformities to processes and instruments to inspections was never a scientific challenge: it was long, painstaking work, and above all expensive to write. Too expensive to sell to a thirty-person shop at a price that shop would have agreed to pay. That is why I have never seen a real quality system in a small manufacturer: not because nobody thought of it, but because the quote never met the budget. What changed recently is the cost of building the software — not the difficulty of imagining it.
"Then install it here"
The request is legitimate, and I hear it mostly from cautious quality managers, which is a good sign. My answer is no, and I would rather explain it than dodge it.
Because nobody would maintain it. Software on a server means somebody applies the security patches, checks that last night's backup actually ran, and knows how to restore the database on the morning the disk dies. A thirty-person shop has no IT staff. What I would have delivered is not software: it is a second job nobody has time to learn. We know how that ends, because it is the story of the Excel file on the shared drive: it holds until the day it doesn't, and the knowledge needed to fix it left with somebody.
Because the work happens on the floor, not at a desk. Reporting a non-conformity from a phone at the machine, opening a report at a customer's site: a server inside the building does not leave the building. To make it leave, you have to open a door onto the internet — that is, recreate, unsupervised, exactly the risk you were trying to avoid. A poorly exposed local server is more dangerous than well-kept hosting.
Because the applications talk to each other. A work order crosses inspection, the quality system and metrology while being entered only once. Multiplying local installations reintroduces manual synchronization — the very problem it claimed to solve.
Because sovereignty does not require proximity. This is the most common confusion. "Here with us" is physically reassuring, but what protects data is the country it is stored in, the law that applies, and the list of people who can read it. Hosted in Montreal under Quebec law is not less under your control than a server in the electrical room — it is often more, because it is written down, logged and verifiable.
The trade-off: three verifiable commitments
Refusing local installation obliges me to something. If your data is not physically with you, then three things must be true, and checkable by you.
Your data stays in Canada. Database and files hosted in Montreal, chosen at the moment each service was created — not added afterwards, because that decision is irreversible. What Quebec law requires, we do not apply as an imposed constraint: it was the architecture from the first line.
AI stays fenced in and minimal. The four uses in the table, on fragments a human pointed at, with no right to decide and no right 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. This is the only commitment that genuinely replaces owning the server: 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 walk away with it is less risky than software installed on your premises whose data is locked in a format nobody can read.
Questions to ask any vendor
You do not have to take my word for it, and it would be a bad habit. These four questions work on anyone selling you software that mentions AI. Vague answers are themselves an answer.
First: exactly where does a model touch my data, and what is sent to it? A precise answer looks like a table. A fuzzy answer means nobody did the inventory. Second: who decides, it or me? Look for the point where a human approves before the data exists. Third: what happens when it is wrong? A vendor who never mentions human correction has not worked through the error case. Fourth: does the software still work if the AI is unavailable? With us, yes — the inspector types dimensions by hand, as before, and everything else carries on. Software that stops without its model is not trade software, it is a demo.
And if you want the question that settles the cloud debate on its own: 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 place, it is a question of control: knowing what leaves, knowing who decides, and being able to walk away. A shop that gets those three answers in writing is better protected than a shop that owns a machine in a closet, and I have described elsewhere the discipline that makes those answers sustainable.
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.