In full
The common disappointment with a business AI deployment is not that the answers are poor. It is that they are generic. The assistant is articulate and knows nothing about your clients, your pipeline, your tickets, or last month's numbers, because it has never been shown any of it.
Settle three things in writing first: which records it may read, which actions it may take unattended, and which actions need a person to approve first, with that middle list kept deliberately short. Then add a fourth if any of it holds personal information: where the processing happens. Connecting a system holding client data to a service outside your jurisdiction is a transfer question, and it is far cheaper to answer before the connection than after it.
The gap is access, not intelligence
Closing that gap means connecting the assistant to systems you already run. A standard has emerged for doing this, so that a system's capabilities can be offered to a model in a predictable way rather than wired up by hand for every combination of tool and assistant.
The practical effect is a change in what you can ask. Instead of describing a situation and receiving general advice, you ask about a specific client and get an answer drawn from the record. Instead of being told how to draft an update, the update is drafted from the actual state of the work.
A model that can only talk can only be wrong on the page. A model that can act can be wrong in your systems.
What is worth connecting first
- The system people ask questions of. Whichever one generates the most 'can you check something for me' interruptions.
- The system nobody enjoys updating. Under-maintained records are usually a data-entry problem rather than a discipline problem.
- Read-only before read-write. Retrieval is genuinely useful on its own and carries a fraction of the risk. It is also the fastest way to find out whether the underlying data is good enough.
- One system, properly. A single well-scoped connection that people trust beats five half-configured ones that occasionally surprise them.
The permission question is the whole design
The capability and the risk are the same property seen from two sides. Anything the assistant is allowed to touch, it can touch when it is wrong. So the scope of access is not an implementation detail to settle later, it is the design.
Three decisions do most of the work. Which records can it read, which actions can it take without asking, and which actions require a person to approve before they happen. The middle category should be small and the answers should be written down, because the difference between a useful assistant and an incident is usually a permission somebody granted broadly to save time.
Where the credentials live
This is worth being specific about. A connector needs credentials to reach a system, and where those credentials sit determines what happens when something goes wrong. The safer designs keep the secret out of the environment the model can see, so that instructions the model reads cannot cause it to disclose the key. That is a design property, not a policy statement, and it is worth asking a vendor to explain rather than assert.
For a South African or UK business there is a second question layered on top: where the processing happens. Connecting an assistant to a system holding personal information is a cross-border transfer question the moment the processing leaves the jurisdiction, and it is far cheaper to answer before the connection than after.
The pattern that works
The deployments that stick tend to look the same. One system, read access first, a narrow set of actions added once people trust the retrieval, and an explicit approval step on anything that leaves the building or changes a record that matters. Scope grows because it earned trust, not because it was possible on day one.
The ones that fail tend to start with broad write access to several systems on the theory that the value will emerge. What emerges is a small number of confident errors and a permanent loss of confidence in the tool.
Connectors are what turn a general assistant into one that knows your business, and the permission scope is the design rather than a detail. Start read-only on one system, keep the set of unattended actions small and written down, put an approval step on anything that changes a record or leaves the building, and settle where processing happens before you connect anything holding personal information.