What AI can do on its own with your data (and what it cannot)
Reading data is one thing. Creating audiences, sending messages and deleting records are another. That line is the most important governance decision for anyone connecting AI to the business’s base.
When someone connects an assistant to the company’s base, the immediate question is "what if it does something stupid?". The good answer is neither "trust the model" nor "do not connect". It is drawing the line between what is reversible and what is not.
The criterion is not how dangerous an action looks. It is whether it can be undone. A wrong query costs a re-read. A sent message does not come back.
The three bands
| Band | Examples | Rule |
|---|---|---|
| Reading | Query sales, list tables, build comparisons, draw a chart | Free. Worst case is a bad answer. |
| Reversible writing | Create a draft, build an audience without publishing, save a query | Free with an audit trail. It can be undone. |
| Irreversible or outward-facing | Send an email, push an audience to an ad platform, delete a record | Explicit human confirmation, every time. |
The third band is not about distrusting AI. The same rule applies to people: nobody emails the whole base without a second pair of eyes. What changes with an assistant is speed — the mistake that used to take an afternoon now takes two seconds.
Who sees what: the other half of the line
Action permission is one axis. The second is data scope: an assistant opened to a partner agency should not see payroll or customer emails. In practice the two cuts that matter most are:
- By table. The person queries sales and media but not the full customer record.
- By sensitive column. Revenue analysis does not need email, phone or tax ID to exist.
- By project. Whoever works on one client cannot reach another client’s base, even holding the identifier.
The useful question before connecting: if this access leaked today, what would leave? If the answer includes customer contact details, cut the scope before switching it on, not after.
The classic failure: a permission that exists and does nothing
One defect is more dangerous than a missing permission: a configured permission nobody reads. The screen shows the scope, the team believes it exists, and access stays complete. Nothing breaks, nothing warns.
So the right check is not to look at the configuration — it is to test it. With the scope on, ask the assistant for something it should NOT be able to get. If an answer comes back, the permission is decorative.
Checklist before connecting
- 01Define who on the team gets assistant access and to which project.
- 02Turn on reading first. Spend a week only asking.
- 03Before enabling writes, list which actions are irreversible or leave the company. Those keep confirmation.
- 04Test the scope by trying to break it. An unproven configuration is an assumed configuration.
- 05Agree what happens when someone leaves: revoking access has to take effect immediately, not when a token expires.