The question that shows up in the first meeting about AI is not what it can do. It is where the company data sits while the AI is working on it. The answer fits in one sentence: it stays where it is today, in your cloud, under your administration, and the model only ever receives the specific thing somebody just asked about.
The work nobody wants to do
Right now it usually looks like this. A salesperson opens a personal account because he needed a meeting note cleaned up fast. Someone in finance uploads a handful of invoices to see whether a summary can be pulled out of them. Marketing pastes the price list in because the website copy was too long. None of them is acting in bad faith. Company data simply starts moving outside anything the company controls.
It surfaces later. During a customer audit, an insurance review, due diligence, or when someone asks whether that supplier contract got stuck somewhere. Nobody can answer, because there is nowhere to look. Management then picks between two bad options: ban everything, or pretend it is not happening.
Nobody broke a rule. It just never got written down anywhere.
— A quarterly access review, abridged
What connected actually means
Connected AI does not mean company data gets uploaded somewhere. It means a small bridge stands between Claude and the system you already run: an MCP server. That bridge runs inside your environment. When someone asks about an invoice, the bridge looks into the accounting system in that person's name, returns exactly that one record, and nothing else. The data never moved.
Anthropic states in its commercial terms that inputs from commercial use are not used to train models. That is one layer. The second layer is architectural and more interesting for a board: no copy travels across the bridge, a question does, and an answer comes back. A copy ages, takes on a life of its own, and nobody knows how many exist. A query happens, gets logged, and ends.
Concretely: Pohoda, the shared drive and an internal database
A fifty-person company rarely runs an exotic stack. Accounting in Pohoda, documents on a shared drive, a CRM, mail, and one database that a single person queries in SQL while everyone else waits. None of that changes and none of it moves. A few bridges are added, one per system, plus a single environment from which people talk to them.
- Accounting: a question about invoice status or a supplier balance runs under the identity of whoever asked, and returns only their slice of the data.
- Shared drive: the model gets the contents of the one file the user is entitled to, not an index of the whole drive.
- Mail and calendar: the context of a single thread, not the archive of the entire company.
- Internal database: read access through prepared views, with the same limits that role already has in the application.
- The log: every query and every write leaves a line. Who, when, through what, with what result.
An operations director at a manufacturing company might use it like this. In the morning she asks which orders have no confirmed delivery date, gets the list, and with it the name of the person accountable for each. She opened no application and uploaded nothing. Meanwhile the person responsible for security can see that evening that the query happened and what it returned. That is an illustration, not a case study, but the mechanics are exactly this.
What this model will not do, and why that is good
It will not turn Claude into a superuser. The model does not get a service account with rights to everything, because that is precisely the situation management is afraid of, only wrapped in a nicer interface. If the person has no right, neither does their assistant. This is not a setting somebody can flip by mistake, it is how the bridge is built.
It also will not replace a decision. The model prepares the material, finds the discrepancy, drafts the reply to the customer. What leaves the building and what gets signed stays with a person. That boundary is the reason you can let a model closer to your data: you know where it ends, and you have it written down.
What it would take
It does not start with a year-long programme. It starts with the one system that generates the most manual chasing today, usually accounting or the CRM. One bridge gets built, five people are let onto it, and for three weeks you watch what shows up in the log. Only then does the next system get added. The infrastructure runs on your side, so parting ways with us later would not mean moving any data.
What is left
The model is not the bottleneck. The bottleneck is the gap between it and the data the company already has, plus the uncertainty about where that data ends up along the way. Both are solved by the same thing: one environment, bridges that carry identity, and a trail nobody writes by hand.
If you are working through this question right now with a lawyer or a customer, write to us. On a short call we will go through the systems you run, where data is leaking today, and what the first bridge would involve. No deck, and a concrete scope at the end.