Site AI
AI on your hardware, on your site.
Models that read shift reports, logs and spreadsheets on a server you own. It keeps working when the link drops, and every output is logged with its input, model version and the person who approved it.
The problem
Shift reports, logs and spreadsheets are the documents a site runs on, and the ones it cannot send to a public AI service.
- Public AI tools send site data to servers you do not control
- Cloud tools stop working when the site link drops
- Nobody can say which model produced an answer, from what input, or who checked it
What we do
- Document-reading and data models running on hardware at your site, working offline
- Connected to the data you already have: spreadsheets, reports, and historians read-only
- A person approves each output before anyone relies on it
- An audit record for every output: its input, the model version and the person who approved it
- You own the hardware and the data
Before a deployment
Six things a site settles before AI runs on its hardware. Count how many you already have.
How it runs
Diagnostic
Fixed scope and price.
You get the problem in writing, an acceptance test and a priced next step. All three are yours to keep, even if you stop here.
Prototype
Built on a copy of your data, not on your live systems.
It has to pass the acceptance test from the diagnostic before anything goes to site.
Site deployment
Installed on your network and signed off by your IT.
You get a runbook and two named owners on opposite rotations, so each rotation has an owner.
Support
Once the system is running, support continues on a retainer.
System-down incidents get a 24/7 response.
Training and handover
Both rotation crews are trained, not only the one on shift at handover.
Training materials are in the site’s language.
Every phase ends in a go/no-go decision.
How we already build
The same rules already run in three of our products.