Local AI
AI that never leaves your building.
For programs where the answer to “where does our data go” has to be “nowhere”. Here is what that actually buys you, and what it costs — including the parts that make it the wrong choice for most work.
What "local" actually means
A model runs on hardware you own, inside your network. Your documents, drawings, and production images are read by that machine and by nothing else. There is no API call, no vendor, no retention policy to negotiate, and no subprocessor list — because there is no third party in the chain at all.
The data-handling question stops being a contract question and becomes a network question. That matters more than it sounds: your IT and quality functions already know how to answer network questions, and have a procedure for it.
Local AI is not more secure because it is better technology. It is more secure because there is no one to trust.
The honest trade-offs
Anyone selling you local AI without this section is selling you something.
| Frontier cloud model | Local model | |
|---|---|---|
| Raw capability | Meaningfully better, and the gap is largest on exactly the hard reasoning you would most want help with | Good enough for extraction, classification, structured drafting, and comparison — the bulk of document work |
| Data exposure | Governed by contract | None. Nothing transits. |
| Cost shape | Per use, no capital, scales down to zero | Capital up front, then near-zero marginal cost. Cheaper at volume, wasteful at low volume. |
| Maintenance | Someone else's problem | Yours: hardware, updates, and the model going stale relative to what is current |
| Getting better over time | Automatically, without you doing anything | Only when someone deliberately upgrades it |
The last row is the one most people miss. A cloud model quietly improves underneath you; a local deployment is a snapshot that ages. That is a real operating cost, not a footnote, and it is why we do not recommend local deployment for work that does not need it.
When it is the right answer
- The mechanism is not filed yet. Pre-filing invention disclosures and novel-mechanism design inputs are the clearest case: the loss is irreversible and no contract undoes it.
- Production images from the line. Vision inspection generates images of your process continuously. Nobody wants that leaving the building, and at that volume the capital cost is the cheaper option anyway.
- A customer or partner agreement forbids third-party processing. Sometimes the question is already answered and the job is to comply with it, not to relitigate it.
- The volume makes it cheaper. Continuous document analysis across a large file estate reaches the crossover point where per-use pricing stops being the economical choice.
When it is the wrong answer
For work on published standards, cleared labelling, generic procedure structure, or anything already public, local deployment buys you nothing and costs you capability. Using it there is the expensive kind of caution: it looks rigorous, protects nothing, and slows down the work that would have benefited most from a stronger model.
Most device companies need a governed cloud tier for most work and a local option for a narrow band of it. A vendor telling you it is all one or all the other has not asked what your content is.
What we deploy
- Document analysis on your hardware. The same gap-scanning and drafting tooling used in our documentation and verification lines, running inside your network, so design history files, requirements, and drawings are read locally and stay local.
- Inspection models at the line. Machine-vision final test with the models running on hardware in the building. Production images never leave, which removes a whole class of question from your quality agreement rather than answering it.
- The documentation that makes it auditable. Whatever runs locally still produces the review record and, for inspection, the test-method validation package. Running on your own hardware changes where the compute happens, not whether a named human signed for the output.
How to find out if it fits
A local-AI feasibility consult is a scoping review like any other: we look at what content you actually need processed, what volume, and what your constraint really is — because it is often narrower than the blanket policy suggests, and the narrow version is much cheaper to satisfy. If a governed cloud tier would serve you better, that is what the review will say.