Agree what counts as sensitive, use business tier accounts that exclude your data from training, keep personal and legal material out of general models, and log what tools are used where.
Most AI risk in a small company is not dramatic. It is someone pasting a contract into a personal account to get a summary, on a Thursday, with good intentions. The fix is clarity rather than restriction.
Open and internal material can move through business tier accounts where your inputs are excluded from training. Restricted material stays inside systems you control, or is redacted before it goes anywhere.
Anywhere an error would be expensive, public or personal, a person reads the output before it moves. That single rule prevents most of what goes wrong.
One page is enough: which tools are approved, what data classes may be used with them, and who to ask when it is unclear. Our assistants agree this with you in the first fortnight and work to it.
Blanket policies fail in both directions. Ban AI entirely and people use it anyway on personal accounts, which is the worst outcome available. Allow everything and sensitive data ends up somewhere you cannot account for.
A three tier classification takes an afternoon to write and covers almost every practical case.
Most of the risk is removed by four unglamorous controls: business tier accounts rather than personal ones, training on inputs switched off, least privilege access to source systems, and credentials held in a password manager rather than shared in messages.
Under UK GDPR, personal data pasted into a general consumer tool is a processing decision you need to be able to justify. Keeping restricted data out of those tools entirely is the simplest defensible position.
A policy nobody reads is a document, not a control. The version that works is one page, written in plain language, with examples drawn from the actual work rather than abstractions.
Pair it with a short list of approved tools and a route for requesting a new one. People follow rules that have an exit, and quietly break the ones that do not.
It will happen at some point, usually with no ill intent: someone pastes a contract or a spreadsheet with personal data into a general tool because they were in a hurry. The response matters more than the policy, and a punitive response guarantees the next incident goes unreported.
Handle it in a fixed order. Establish what was shared and with which service, check the account settings to determine whether the input could have been used for training, delete the conversation and any stored history where the provider allows it, and record what happened in a short internal note.
Then assess whether it is reportable. Under UK GDPR, whether a personal data incident needs reporting to the ICO depends on the risk to the individuals concerned, and that judgement should sit with whoever owns data protection in your business rather than with the person who made the mistake. Having that route defined in advance is the whole point of naming an owner in the policy.
Finally, fix the cause rather than the instance. Most of these incidents trace back to a missing approved tool, so if people keep reaching for a consumer account, the honest conclusion is usually that the sanctioned option is too slow or does not exist yet.
Do your assistants put our data into public AI tools? No. Work happens in approved business tier accounts under a data policy agreed with you, and restricted material stays inside your own systems.
Do you sign NDAs? Yes. Confidentiality terms are standard and assistants work under them from day one.
Who owns the accounts and credentials? You do. Assistants work inside your accounts with access you grant and can revoke.
More insights | Alvara Partners