AI security: you may already trust your data to the cloud
Many organisations reject AI because it is “in the cloud” while already trusting email, documents and customer data to other cloud providers. That contradiction does not prove that AI is safe; it shows that we need to apply the same coherent analysis to every service.
One of the most common responses when I propose exploring AI is, “We cannot send our data to the cloud.” The concern may be entirely legitimate. What is strange is hearing it in a video call while we share an online document and discuss information that already lives in a third-party CRM.
I am not saying this to ridicule the risk. Nor am I claiming that, because we already use cloud services, we can use any AI. Existing trust is not a blank cheque. It is a starting point for a coherent analysis.
“AI” is not a data-processing model
Two products that use similar models can make very different commitments. Account type, contract, retention, region, administrative controls, connectors and the provider’s use of data can all differ.
Before approving or banning a tool, we need to know:
- What information it receives and what it generates.
- Whether data is used to train or improve models, and under which conditions.
- How long data is retained and where it is processed.
- Who can access it and how that access is revoked.
- Which external systems it can read from or modify.
- Which logs and administrative controls exist.
- What happens after an incident or deletion request.
The answer cannot be inferred from a logo or screenshot. It must be verified in the specific product, configuration and contract.
Shared responsibility
Cloud computing has worked for years with a useful idea: the provider protects part of the infrastructure while the customer remains responsible for identities, configuration, applications and data. Something similar happens with AI.
A provider may encrypt information and exclude business data from training by default. That does not prevent someone from copying information they should not, granting excessive permissions to a connector or approving an action without reviewing it. Security is a property of the complete system, not a feature bought in a box.
Compare risk with risk, not risk with imagination
I propose inventorying the current data flow and placing the new tool on the same map. What information already leaves the organisation? For what purpose? Which provider processes it? What controls do we have? What new risk does AI add, and what risk might it reduce?
Sometimes we will discover that the proposed use is unacceptable. At other times, the difference from an approved service will be smaller than imagined. Frequently, we will find a middle ground: anonymise data, limit the use case, use an enterprise account, disable a connector or retain human approval.
From generic prohibition to usable rules
“Do not enter anything sensitive” sounds like a policy, but it forces each person to interpret what sensitive means. Useful guidance classifies data and connects each class to permitted tools and actions.
It also distinguishes between generating a suggestion and allowing an agent to act. Reading a document, sending an email and changing a record have different blast radii. Permissions should grow with need and shrink when no longer required.
The aim is not to eliminate risk. It is to understand it, compare it with the expected value and design controls that let us learn without hiding what is happening.