Cybersecurity Considerations for AI Adoption

AI adoption in most organizations does not arrive as a project. It arrives as individual teams trying tools that solve an immediate problem, often before anyone has considered what data those tools receive or what access they hold.

The first question is about data, not models

Before evaluating how an AI system works, it is worth establishing what it is given. Source code, customer records, internal documents and support conversations are all commonly pasted into AI tools because doing so is genuinely useful.

The questions that follow are familiar ones from any vendor assessment: where is that data processed, how long is it retained, is it used to improve the provider's models, who at the provider can access it, and what happens to it if you stop using the service. These are ordinary third-party risk questions. AI does not change them, it simply makes them apply to more tools, more quickly.

Shadow adoption is the common starting point

Most organizations we speak to have more AI usage than their inventory reflects. Browser extensions, features quietly added to existing SaaS products, and personal accounts used for work tasks all contribute.

A blanket prohibition rarely works - it pushes usage further out of view. A short, clear position on what is acceptable, which tools are approved, and what categories of data must never be shared tends to produce far better visibility than a policy people quietly ignore.

Where AI features introduce genuinely new risk

When AI is embedded into a product rather than used as a standalone tool, some considerations are less familiar:

• Untrusted input reaching the model. If a model processes content from emails, documents or web pages, that content can contain instructions. Treat model output as untrusted input, particularly when it feeds into another system.
• Access inherited by the assistant. An AI feature connected to internal systems typically operates with some set of permissions. It should follow the same least-privilege approach as any other service account.
• Actions rather than answers. Risk increases sharply when a system moves from generating text to taking action - sending messages, modifying records, executing code. Those paths need explicit authorisation boundaries and human review where the impact is material.
• Retrieval crossing permission boundaries. An assistant searching internal documents can surface content a user was never meant to see if the underlying access controls are inconsistent.
• Logging. Prompts and responses may contain sensitive data and often end up in logs that were never classified for it.

A proportionate starting point

For most growing organizations, a sensible baseline is modest: maintain a list of AI tools in use, define what data may be shared with them, apply the same vendor review you would to any processor of comparable data, and require review before an AI system is given the ability to act on production systems.

The aim is not to slow adoption. It is to ensure that when AI tools become part of how the organization works, that happened deliberately rather than by default.

← Back to Insights