Artificial intelligence has become part of everyday working life remarkably quickly. Employees are using AI to draft emails, summarise documents, analyse spreadsheets, research topics and prepare reports. Developers are using AI assistants to write and troubleshoot code. People with little development experience can now build simple applications themselves. Customer service teams are exploring AI chatbots, while organisations are beginning to connect AI assistants to their own documents, customer information and internal systems.

For most businesses, the attraction is obvious. Used well, AI can save time, remove repetitive work and help people get more done. The challenge is that adoption has happened so quickly that the controls around it haven’t always kept pace.

An organisation might have an AI policy saying employees should only use an approved platform, while staff are actually using several others. Someone might use AI to build a small application without considering whether the code is secure. A team might connect an AI assistant to company data without fully understanding what it can access. A chatbot might be added to the company website without anyone considering that it has also created a new publicly accessible application for attackers to interact with.

These aren’t reasons to stop using AI. They are reasons to understand how AI is actually being used across an organisation – rather than how the business assumes it is being used – and to make sure cyber security is part of the conversation.

What are the cyber security risks of using AI in business?

There is no single “AI cyber security risk”. The risks depend heavily on how an organisation is using the technology.

For some businesses, AI use may currently consist mainly of employees using tools such as Microsoft Copilot, ChatGPT or Gemini to help with everyday office work. The primary concerns in that situation are likely to centre on what information employees are sharing, whether they are using approved services and whether the business understands how its data is being processed.

Other organisations are going considerably further. Developers may be using AI to generate code. Employees outside traditional development teams may be building applications themselves. AI systems may be connected to company documents, customer records and internal applications. Customer-facing chatbots may be able to retrieve information or perform actions on behalf of users.

The security implications become more significant as AI is given greater access to information and systems, and particularly when it is allowed to perform actions.

This is why it is unhelpful to think of AI as either “safe” or “unsafe”. Asking an approved AI tool to suggest some ideas for a presentation presents a very different level of risk from uploading a customer database to an unapproved service. Asking AI to explain a piece of code is different from deploying AI-generated code directly into a live application. A chatbot that answers questions using information already published on your website is different from one connected to customer accounts.

The first step towards using AI securely is therefore understanding exactly how it is being used.

Shadow AI: are employees using unapproved AI tools?

Many organisations already have rules about which AI platforms employees should use. A business might have approved Microsoft Copilot, for example, and instructed employees not to use other generative AI services for company work.

The difficulty is knowing whether that reflects what is actually happening.

An employee may prefer ChatGPT because they already use it personally. Another might use Gemini because they find it better for a particular task. A developer might have an AI coding assistant installed. A marketing team could be using specialist AI tools for research, writing, images or video. Someone else might discover a new service that solves a problem in minutes and begin using it without ever thinking to involve IT.

This is increasingly referred to as shadow AI: the use of AI applications within an organisation without formal approval, visibility or oversight. It is a development of the much older problem of shadow IT, where employees adopt their own software and cloud services rather than relying entirely on technology supplied by their employer.

Generative AI makes this particularly difficult to control because the barrier to adoption is so low. Employees don’t necessarily need to install software or request access to a new company system. In many cases, they can open a website, create an account and start using it immediately.

That creates a potentially significant gap between the organisation’s official AI environment and the one that actually exists. A business may have spent considerable time assessing and configuring an approved AI platform while remaining unaware that company information is also being processed through several other services.

The cyber security problem isn’t simply that employees are breaking a policy. The more important question is what they are doing with those tools and what company information is being shared with them.

Can employees put company data into ChatGPT and other AI tools?

The usefulness of generative AI often depends on providing it with information. If someone wants help rewriting an email, they paste in the email. If they want a report summarised, they upload the report. If they want help analysing some figures, they provide the spreadsheet. If they want an AI assistant to troubleshoot software, they may paste in source code or an error log.

Most employees doing this aren’t deliberately circumventing security controls. They are trying to complete a task more efficiently.

The problem is that the information being provided could include customer data, employee information, contracts, financial information, commercially sensitive documents, source code or details about the organisation’s technology and security.

There isn’t a simple rule that says company information should never be entered into an AI system. Different AI services, account types and configurations have different arrangements governing how information is processed, retained and used. An enterprise service that has been assessed and configured by an organisation may provide very different protections from a consumer account an employee created themselves.

Businesses therefore need to understand the particular services they are using rather than making assumptions about AI generally. Where is information processed? How long is it retained? Is it used to improve or train models? What contractual protections apply? Can administrators control accounts and access? What happens to the information when an account is closed?

Those questions are difficult to answer if the business doesn’t know which tools its employees are using in the first place.

Policies also need to be practical. Telling employees not to enter “sensitive information” into an AI tool sounds straightforward until someone has to decide whether a particular customer email, meeting transcript, sales spreadsheet or piece of source code counts as sensitive. Clear examples of what can and cannot be shared are much more useful than broad instructions to “use AI responsibly”.

Does remote and hybrid working increase the risks of shadow AI?

Remote and hybrid working remain much more common than they were before the pandemic, and for many organisations employees now routinely move between the office, home and other working locations. That change isn’t responsible for shadow AI, but it does form part of a much more fragmented technology environment in which businesses are trying to understand how their information is being used.

An employee working from home might have their company laptop open alongside a personal computer, tablet or phone. Accessing another AI service can take seconds and may not involve installing anything on a company device. If the organisation’s approved tool isn’t giving them the result they want, they may simply open the AI platform they already use personally.

The distinction between business and personal technology can also become less obvious when people are working outside a traditional office environment. Someone might use a personal account because they are already logged into it, move information between devices for convenience or try a new online service without thinking of it as something that needs approval from IT.

None of this is an argument against remote or hybrid working, nor is bringing everyone back into the office a realistic cyber security control for AI. It is simply part of a broader change in the way organisations use technology. The traditional boundary around the business has become less distinct as employees use cloud applications, work across multiple locations and increasingly choose digital tools for themselves.

AI adds another layer because these services are both highly accessible and information-hungry. Employees don’t need to download suspicious software or circumvent sophisticated security controls to create a potential data risk. In some circumstances, opening a browser tab and pasting information into a prompt is enough.

AI policies and security controls therefore need to reflect the reality of how people now work rather than assuming that controlling the applications officially provided by IT means controlling all of the applications employees actually use.

Should businesses ban employees from using ChatGPT and other AI tools?

For some organisations, the immediate reaction to shadow AI may be to block everything except an approved platform. There may be circumstances where restricting access to particular services is appropriate, particularly where employees handle highly sensitive information.

However, relying on prohibition alone risks treating the symptom rather than the cause.

Employees are adopting AI because it is useful. If people repeatedly choose an unapproved tool instead of the organisation’s approved alternative, it is worth understanding why. Perhaps the approved service doesn’t perform a particular task very well, employees don’t know how to access it or nobody has explained the reasons behind the restrictions.

A more sustainable approach is to understand what employees are trying to achieve and provide clear routes for doing it securely. That might mean approving several AI services for different purposes, restricting particular types of data, providing enterprise accounts or introducing additional controls around higher-risk uses.

Technical controls can form part of that approach, but governance and training matter as well. Employees are much more likely to make sensible decisions if they understand why restrictions exist and have practical guidance about what they can do.

The objective shouldn’t necessarily be to minimise AI use. It should be to prevent useful AI adoption from happening invisibly and without appropriate controls.

Is AI-generated code secure?

AI coding assistants have become one of the most significant applications of generative AI. Experienced developers can use them to generate functions, explain unfamiliar code, troubleshoot errors and speed up routine development work. Used appropriately, they can deliver substantial productivity benefits.

AI is also making software development accessible to people who previously wouldn’t have considered themselves developers. Someone can describe what they want in plain English and receive working code in seconds. With enough iteration, an employee may be able to create a form, internal application, automation, integration or even a customer-facing service without possessing the technical knowledge that would traditionally have been required.

The cyber security issue is not that AI-generated code is inherently insecure. It is that code can function correctly while still containing serious security weaknesses.

Secure development involves much more than making an application perform its intended task. Developers need to consider authentication, authorisation, input validation, session management, dependencies, encryption, secrets, permissions and how an application behaves when somebody deliberately tries to make it do something it wasn’t designed to do.

Someone with limited development experience may not know which of those questions they need to ask. AI therefore creates an unusual situation in which people can build beyond their own ability to assess what they have built.

This is particularly relevant to the growth of so-called “vibe coding”, where an application is developed largely by describing the desired outcome to an AI system and repeatedly refining the generated code until it works. For prototypes and experiments, this can be enormously useful. Problems arise when the prototype gradually becomes operational software.

An employee might build a small tool to solve an internal problem. Colleagues start using it, so it gets connected to a database. Later, someone wants to access it remotely. Eventually, the application is processing real company or customer information. If it never went through the organisation’s normal development process, there may have been no point at which somebody assessed whether it was secure.

Businesses therefore need to make sure the same secure development principles apply regardless of how the code was produced. AI-generated code should be appropriately reviewed and tested before being deployed, particularly when it will process sensitive information or be accessible from the internet.

AI can accelerate software development. It shouldn’t be allowed to bypass software security.

What are the cyber security risks of AI chatbots?

Customer-facing AI is another area where businesses need to think beyond the immediate benefit of the technology.

An AI chatbot can provide a convenient way for customers to get answers without searching through a website or waiting for a member of staff. But putting an AI chatbot onto a public website also creates a new application that anybody on the internet can interact with, including attackers.

One of the most widely discussed risks affecting these applications is prompt injection. In simple terms, this involves providing an AI system with deliberately constructed instructions or content intended to make it behave differently from the way its developer intended.

The consequences depend heavily on how the chatbot has been designed and what it can access. A chatbot that only answers questions using information already published on a company’s website presents a relatively limited risk. An attacker might be able to make it produce inappropriate responses or behave unexpectedly, but the system has little access to anything sensitive.

The situation changes significantly if the chatbot is connected to customer information or internal systems. Perhaps it can retrieve an order, check a booking or access information held in a CRM. The potential impact increases again if it can perform actions such as changing customer details, amending bookings, creating support requests or issuing refunds.

At that point, the relevant security question is no longer simply whether somebody can make the chatbot say something strange. The question is what somebody might be able to make it access or do.

Customer-facing AI applications therefore need to be treated as part of the organisation’s external attack surface. They should be designed with appropriate access controls, assessed for security weaknesses and tested with the assumption that people will deliberately interact with them in unexpected ways.

What are the security risks of connecting AI to business systems and data?

One of the most significant developments in business AI is the move from systems that simply generate information to systems that can access company data and perform actions.

An AI assistant might search internal documents, retrieve information from a CRM, read an email and create a customer record, update a database or create a support ticket. These capabilities can make AI far more useful, but they also change the potential consequences of a security failure.

The more systems an AI application can access, the more carefully its permissions need to be considered. An assistant that can only retrieve information already available to the person using it presents a very different risk from one with broad access to customer records, internal documents and business applications.

This is particularly important when organisations connect AI to large collections of internal information. Imagine an AI assistant that can search company documents. Some of those documents are available to everybody, while others contain HR information, financial data, board papers or commercially sensitive material.

Existing access controls still need to apply. An employee who isn’t authorised to open a particular HR document shouldn’t be able to retrieve the same information simply by asking an AI assistant a question about it.

The same principle applies when AI is able to perform actions. If an assistant can amend customer information, approve something, change a booking or trigger another business process, organisations need to consider what authorisation should be required and whether some actions should always require human approval.

The principle of least privilege provides a useful starting point. An AI application should only have access to the information and functionality it genuinely requires to perform its role. Giving it broad access simply because doing so is technically convenient increases the potential impact if the system is compromised, manipulated or behaves unexpectedly.

What are the third-party and supply-chain risks of AI?

Most organisations implementing AI aren’t building the underlying models themselves. They are combining products and services supplied by other companies.

There may be a model supplied by one provider, an application or chatbot platform from another, integrations with existing business software and additional components that allow the system to retrieve information or perform actions. What looks like a single AI tool to an employee may therefore involve several different organisations and systems behind the scenes.

That creates a supply chain that needs to be understood.

Before approving an AI service, businesses should consider what information the provider will process, where it will be processed and stored, how long it will be retained and what happens when it is deleted. They should understand what security controls are available, whether accounts can be managed centrally and whether access can be removed promptly when an employee leaves.

It is also important to understand what the service will be allowed to connect to. Giving an AI platform access to email, cloud storage, customer records or internal databases is a very different security decision from using a standalone tool to generate generic text.

The fact that a product uses AI doesn’t remove the need for normal supplier due diligence. If anything, the volume of information AI applications can consume and the range of systems they can increasingly access make understanding the supply chain particularly important.

Can you trust information and advice generated by AI?

Not every AI-related cyber security risk involves an attacker. Sometimes the problem is simply that an AI system gives someone the wrong answer.

Generative AI can produce information that appears convincing but is inaccurate. For everyday tasks, the consequences may be relatively minor. When people use AI to help with technical work, however, an incorrect answer can have security implications.

An employee might ask an AI assistant how to configure a cloud service, set permissions on a database or make an application accessible remotely. The AI could produce detailed instructions that solve the immediate problem while also introducing a security weakness.

This risk becomes particularly significant when people use AI to perform tasks outside their normal expertise. The reason someone is asking an AI assistant may be precisely because they don’t know how to complete the task themselves. That can also mean they don’t have enough knowledge to recognise when the answer is incomplete or unsafe.

AI can therefore increase what employees are capable of doing without necessarily increasing their ability to assess the consequences.

The appropriate level of human review should depend on the significance of the task. Nobody needs a security team to review every AI-generated paragraph or spreadsheet formula. But changes to infrastructure, security settings, permissions, live applications and other significant systems shouldn’t be trusted simply because the AI-generated instructions appear authoritative.

How can businesses use AI securely?

For organisations already using AI extensively, the prospect of bringing it under control can seem daunting. The good news is that many of the principles involved are familiar cyber security practices rather than entirely new disciplines.

The starting point is visibility, followed by proportionate controls based on how each AI service is actually being used.

Find out which AI tools employees are actually using

Before writing another policy or buying another security product, establish what is already happening.

Speak to teams across the organisation and find out which AI tools they use, what they use them for, whether they use personal or company accounts, what information they provide to those systems and whether any AI applications have already been connected to company data or other business systems.

This shouldn’t be approached purely as an exercise in catching employees using unauthorised technology. If people are repeatedly choosing an unapproved tool over the approved alternative, understanding why may reveal a genuine business requirement that isn’t currently being met.

The exercise may also uncover AI use that nobody responsible for IT or cyber security knew existed. Developers may be using coding assistants, marketing may have subscribed to several AI services, someone in operations may have built an internal application and customer services may already be trialling a chatbot.

None of those discoveries automatically represents a security incident. They give the organisation the visibility needed to assess the risk properly.

Assess how risky each use of AI is

Not all AI use deserves the same level of scrutiny.

A useful starting point is to consider the information an AI application can access, the systems it can interact with and the actions it can perform. The sensitivity of the information matters, as does whether the service is internal or publicly accessible and whether the output will affect important business systems.

This allows organisations to apply proportionate controls rather than treating every AI interaction as inherently high risk.

Using an approved enterprise AI tool to improve the wording of a generic document might require very little oversight. Connecting a customer-facing AI application to a database containing personal information deserves considerably more.

Create a practical AI security policy

An effective AI policy should make the boundaries clear without requiring employees to become AI security experts.

People need to know which services are approved, whether personal accounts can be used for company work and what types of information can be entered into AI systems. The policy should address AI-generated code and applications, explain when human verification is required and establish a process for requesting new AI tools.

Examples are particularly valuable. Employees are more likely to understand an instruction such as “don’t upload a customer spreadsheet containing names and contact details to a personal AI account” than a broad prohibition on entering “sensitive information”.

The policy also needs to evolve. AI products and capabilities are changing too quickly for a document written once and forgotten about to provide meaningful governance.

Review AI tools before approving them

AI services should go through appropriate security and supplier assessment before being approved for business use.

The depth of that assessment should reflect the risk. A service being used for generic content generation doesn’t necessarily require the same scrutiny as one that will process customer information or connect to internal systems.

Where the risk is greater, organisations should understand the provider’s data-handling arrangements, available security controls, account management, access controls, integrations and contractual protections before information begins flowing through the service.

Apply secure development practices to AI-generated code

Organisations should avoid creating a separate, lower security standard for code simply because AI helped produce it.

AI-generated code should be subject to the same appropriate review, testing and deployment controls as code written by a developer. This becomes particularly important where AI allows people outside established development teams to build applications.

Businesses may need to update their existing development policies to account for that possibility rather than assuming all software development happens within IT.

Security test customer-facing AI applications

Any AI application exposed to the internet should be treated as part of the organisation’s attack surface.

Security testing should consider not only traditional web application vulnerabilities but the way the AI itself can be manipulated, what information it can retrieve and what actions it can perform.

The greater the access and capability of the AI, the more important that testing becomes.

Limit what AI can access and do

AI applications should be given the minimum permissions they need. Existing access controls should continue to apply when AI retrieves company information, and high-impact actions may require additional authorisation or human approval.

Businesses should resist the temptation to give an AI assistant broad access simply to make integration easier. The question should always be what the application genuinely needs to perform its intended function.

Decide who is responsible for AI security

AI can easily fall between existing areas of responsibility. IT may assume data protection is handling it, data protection may assume cyber security has assessed the service and cyber security may not know a particular department has bought it.

Organisations don’t necessarily need a dedicated AI security team, but they do need clarity about who can approve new AI services, who assesses the cyber security implications and who maintains oversight of AI use across the business.

Depending on the application, that may involve IT, cyber security, data protection, legal, HR and individual departments. What matters is that responsibility isn’t left ambiguous.

Make AI part of your incident response plan

Mistakes will happen even with good controls.

An employee may realise they have uploaded sensitive information to an unapproved AI service. An AI application might be given access to more information than intended. A chatbot could return information it shouldn’t, or AI-generated code might introduce a vulnerability.

Employees need to know how to report those situations.

If somebody realises they have shared sensitive information with the wrong service, they shouldn’t stay quiet because they are worried about getting into trouble. The organisation needs an opportunity to establish what was shared, which service received it, what account was used, whether the information can be removed and whether any further action is necessary.

AI-related incidents can usually be incorporated into existing incident response processes rather than requiring an entirely separate framework.

AI security checklist for businesses

If AI adoption has moved quickly in your organisation, the following questions provide a useful starting point for understanding your exposure.

People: Do you know which AI tools employees actually use? Do they know which services are approved and what information they can share with them? Is there a practical process for requesting access to new AI tools?

Data: What company information is being entered into AI systems? Do you understand how approved providers process, retain and protect that information? Are employees using personal AI accounts for company work?

Code: Are developers using AI coding assistants? Are employees outside development teams building software or automations with AI? Is AI-generated code appropriately reviewed and tested before being deployed?

Applications: Have any teams introduced customer-facing AI, including chatbots? Has it been security tested? What information can it access and what could happen if somebody deliberately tried to manipulate it?

Access: Which company systems can AI applications connect to? Do they have the minimum permissions necessary? Are existing user access controls respected? Can the AI perform actions, and which of those actions require approval?

Third parties: Do you understand which providers are involved in delivering your AI services, what information they process and what security controls they provide?

Response: Would an employee know what to do if they accidentally shared sensitive information with an AI platform? Would the organisation know how to respond if an AI application disclosed information or behaved unexpectedly?

You don’t need to answer “yes” to every question before anyone in the organisation is allowed to use AI. The purpose of asking them is to identify where the business currently lacks visibility or control and prioritise the areas where the consequences would be greatest.

Do businesses need specialist AI cyber security software?

The growth of AI has inevitably created a growing market for products promising to protect organisations against AI-related security threats. Some of those technologies can provide useful capabilities, particularly as AI becomes more deeply integrated into business systems.

But buying an “AI security” product isn’t necessarily the first thing every organisation needs to do.

Many of the risks created by AI are variations of familiar cyber security problems. Sensitive information still needs to be protected. Users and applications should still have appropriate permissions. Software still needs to be developed securely. Internet-facing applications still need to be tested. Suppliers still need to be assessed. Security incidents still need to be detected and managed.

AI changes the circumstances in which those controls operate. It can make it easier for employees to share information with third parties, easier for people to build software and easier for organisations to connect applications to large amounts of data. AI agents also create new questions around what software should be permitted to do on a user’s behalf.

For many organisations, the priority is therefore to make sure their existing cyber security approach has caught up with the way AI is now being used.

How should businesses approach AI cyber security?

The cyber security conversation around artificial intelligence often focuses on what attackers are doing with it. That matters: AI can help cyber criminals research organisations, identify vulnerabilities, create convincing phishing messages and operate at greater scale.

But organisations also need to look at what is happening inside their own businesses.

Employees are adopting AI because it is useful. Developers are writing code faster, people who have never considered themselves developers are building applications, customer service teams are deploying chatbots and businesses are connecting AI to increasingly valuable information and systems.

Those developments can deliver genuine benefits, but they also change an organisation’s cyber security risk.

The answer isn’t to slow down AI adoption unnecessarily or assume that every use of generative AI presents a serious security threat. It is to make sure that security forms part of the decision-making process as AI becomes embedded in everyday work.

That begins with understanding which tools people are actually using, what information is being shared with them and where AI has been given access to company systems or the ability to perform actions. From there, businesses can concentrate their attention on the areas where the potential consequences are greatest and apply the same principles that underpin good cyber security elsewhere: appropriate access, secure development, testing, monitoring, clear responsibility and a plan for when something goes wrong.

For many organisations, the most useful first question is therefore not what AI might be capable of in the future, but what it is already doing inside the business today.