The short version
- Cloud software has an address on the internet; on-premise software doesn’t. That is the whole problem — the AI’s connector has nowhere to point.
- You solve it by putting something the AI can reach between the two: a scheduled copy of the data, a small service running on your side, or a vendor’s sync if one exists.
- Never open an inbound port on the on-premise machine. Every safe pattern is outbound from your side.
- Freshness is the trade: an export is simple and safe but hours old; a live connector is current but is a running service someone has to look after.
- Whether the path can write is decided when it is built. An export can’t; a connector only can if someone adds write tools.
Why this is harder than it looks
Most of what is written about “connecting AI to your business” assumes the business runs on cloud software with a public API. Owner-operated businesses often don’t. The jewelry store’s point of sale runs on the PC under the counter. The florist’s proposal tool is installed on one laptop. The recruiting agency’s older ATS lives on a server in a closet. The liquor store’s inventory system talks to the scanner and nothing else.
Three things make these hard:
There is no public address. A cloud API is a public address with a login. On-premise software has neither; it was built to be used from the machine it runs on. Reaching it from outside means either taking data out of it or putting a program next to it.
The machine is doing a job. It is ringing sales or running payroll. Anything you add has to leave it alone: no inbound traffic, no load during business hours, nothing that fails in a way the staff has to notice.
The vendor may not help. Many on-premise vendors have no API, a partner-only API, or an export function that was designed for accountants, not for programs. What you can get out — and how — is different for every product, and finding out is often the first real task.
The approaches, honestly compared
| Approach | What it is | When it fits | What it costs you |
|---|---|---|---|
| Vendor sync or cloud edition | The vendor mirrors your data to their cloud, or offers a hosted version with an API. You connect the AI to that. | The vendor offers it and the mirrored data includes what you’d ask about. Check first — it removes most of the work below. | The vendor’s price and the vendor’s schedule. Some syncs are partial or hours behind. No vendor needed on top; this is the no-integrator path. |
| Scheduled export to a copy | On a schedule, the software’s own export runs and the file lands, outbound, in a store you control. A connector reads the copy. The original is never touched. | Questions about history and trends, a single-site business, anything where “as of last night” is good enough. The most common fit for a POS. | Someone owns the export job and the copy. Answers are as old as the last run. Writes are impossible by design — a feature for most owners, a limit for some. |
| Local connector, outbound only | A small program on your side (on or next to the machine) reads the software’s database or API and opens an outbound connection to the AI’s app or a gateway. | Questions that need the current state — stock on hand, today’s tickets — and a machine that can run one more small service. | A running service on a computer in your building: updates, restarts, the day it stops and nobody notices. Needs real access to the software’s data, which the vendor may not document. |
| Screen-scraping / robotic automation | A program drives the software’s own screens the way a person would and reads what it sees. | Last resort, when there is no export and no database access and the questions are few and fixed. | Fragile — breaks on every update. Slow. Hard to make read-only, since it is literally using the app. We list it because people ask, not because we recommend it. |
If the vendor offers a sync, take it. If the questions are about history, export to a copy and stop there — it is the cheapest, safest path and it needs no one but the person who sets up the schedule. Reach for a live connector only for the questions that truly need this minute.
What we do and why
We build the path — export or local connector — for the tools an owner-operated business already runs, keep the on-premise machine untouched, and put a gateway between the AI and the data so each person’s AI carries that person’s permissions. Every tool is a read until the business decides otherwise. We make nothing on your AI bill.
Worked example
One system we connect this way is The Edge, a jewelry point of sale that runs on a machine in the store. Once a night, the store’s own read-only export runs over a private link into a copy we host; the AI, and the app built on it, only ever see the copy, and the POS is not exposed to either. The export has run every night since go-live. Every tool the AI has on that connection is a read. For contrast: in recruiting, the assistant we run reads and writes — creating candidates, adding notes, advancing interview stages — because the business asked for writes, and the system had a path that could carry them. How The Edge and Claude connect → · Read-only first: why we sequence access this way →