AI security in the workplace: 6 areas to address before deploying Copilot
Grzegorz Strząbała September 9, 2026 You're reading:
An AI assistant plugged into a corporate environment doesn’t create new security holes. It makes the old ones visible -instantly, in the form of an answer to an ordinary question asked by an ordinary employee.
That’s the most important shift in how we think about AI security in a company. The risk doesn’t sit in the model; it sits in the backlog an organization has been piling up for years: in permissions granted “temporarily,” in files shared with “everyone,” in data nobody ever classified.
Below are six areas worth reviewing before deployment, plus a second layer that gets discussed far less often – the legal one.
But first – you don’t need a perfect starting point
A list of six areas sounds like a six-month project to complete before launching anything. It isn’t. No organization has perfectly clean data, and none ever will.
The approach that works is different: identify where the biggest risks are, decide which ones you close first, and tighten the system step by step. Basic configuration is usually a matter of a few days’ work for one person, plus writing the operating procedures the expensive part isn’t the technology, it’s the decisions and the documentation.
If you had to pick one thing to do tomorrow: DLP policies.
1. Order in your document repositories
The best answer to “does Copilot give good answers?” is a counter-question: is your SharePoint well organized?
The assistant has no magical knowledge about your company. It only uses what has been made available to it. If the board shared a file with “everyone in the organization,” then sooner or later even an employee who doesn’t know the file exists will see its contents in a set of results. They don’t have to go looking for it – they just have to ask about the topic it covers.
So it’s worth starting with an inventory: where the documents actually live, which links have been made public, which libraries have “everyone” permissions, and whether the structure reflects today’s organization or the one from three reorgs ago.
2. Sensitivity labels
The model won’t work out on its own which document is strategic, which is public, and which contains personal data. You have to tell it – and that’s what sensitivity labels are for.
Their structure should reflect how the organization actually classifies data, not a textbook model. In practice, a handful of levels is enough: public, internal, confidential, contains personal data. Labels are far simpler to design and roll out than most companies assume, and the payoff is immediate – from that moment on, both the assistant and your DLP mechanisms have something to go on.
3. Permissions
The most common risk when deploying an AI assistant isn’t authentication and isn’t DLP — it’s the backlog in permissions.
Copilot doesn’t break into resources. Copilot exposes our mistakes.
If an employee has access to a document they shouldn’t be able to see, the assistant will find that document and use it in an answer. Not because it broke through security, but because the security either wasn’t there or has been misconfigured for years – usually a leftover from a project, a migration, or someone who changed roles long ago.
It’s worth treating this as a benefit rather than a threat. An AI rollout works like the permissions audit the organization never carried out. Better to run that audit deliberately and early than to learn the results from an answer generated for an employee.
4. MFA and Conditional Access
In Microsoft environments, multi-factor authentication is now the standard and works natively in many tenants. This is an area most companies have already closed out. The importance of getting the configuration right grows, however, as you start launching agents and automations that operate on business data. With ordinary mailbox access, a compromised account means access to that mailbox. With an agent integrated into line-of-business systems, it means access to a far wider range of information and operations. So it’s worth reviewing your conditional access policies with an eye on the accounts that run those automations.
5. DLP policies
This is the fastest way to reduce the most serious real-world risk: data leaving for external AI tools.
The biggest threat isn’t the corporate assistant — it’s the use of AI tools from personal accounts, which are subject to no monitoring, logging, or security mechanisms at all. The same people who are careful with the assistant at work will, in the evening, paste contracts, client documents, or reports bought from an outside vendor into a public chat. Data leaks out piece by piece, without a single incident anyone could detect.
Two things don’t work here:
- Blocking. It just moves the activity onto personal devices, where you have no visibility at all.
- One-off training. There are observations that people who’ve been through AI security training reach for unauthorized tools more often — because they feel they already know what to watch out for.
What does work is a combination of three things: data classification, a few DLP policies that close the riskiest channels, and a safe tool that’s more convenient than the unsafe one. If an employee has an assistant with access to company data and still sends that data to a private chat, something went wrong in the rollout, the training, or the whole adoption concept.
6. Separating environments
Practice reveals a pattern worth taking seriously: a test agent has a strong tendency to become a production agent. With no decision, no testing, no owner – someone simply started using it, because it worked.
That’s why it pays to define up front what counts as the test environment, where the business actually works, and what the promotion path from one to the other looks like. It’s the least technical point of the six and the one most often skipped.
The second layer: legal
Technically, changing a setting is a few minutes’ work. The legal consequences are entirely out of proportion to that effort.
A typical example: extending retention of meeting recordings and transcripts beyond the default. The right question isn’t “can we click this?” but “what’s the justification?” System settings are one thing; the legal environment is another – data protection, NIS2, the AI Act, and increasingly specific clauses in client contracts.
The consequences won’t land immediately. They’ll land at the annual audit, during an ISO implementation, in due diligence, or in a conversation with a client whose contract contains the relevant clauses. So with every change, it’s worth having not just the setting but the paperwork: a justification, a procedure, an owner.
The list of regulations you need to deal with is finite. The history of GDPR implementation is a good reference point: a lot of noise, then a big one-off effort, and today the procedures run in the background and paralyze no one.
And one principle that organizes the rest: the legal layer should be implemented in the system, so that users don’t break the law for their own convenience. A policy document everyone forgets about is not a safeguard. The health-and-safety analogy fits here – a hard hat in a high-bay warehouse works not because people read the manual, but because the environment and enforcement make it mandatory.
The overlooked thread: the cost of data hoarding
Every meeting recording, every transcript, and every generated document lands on a disk, takes up space, and costs money. The scale at which AI generates content means terabytes nobody ever goes back to.
Retention, then, isn’t just a compliance matter – it’s a line in the IT budget. Retention policies play a double role: they limit the volume of data that could leak in an incident, and they perform the natural clean-up nobody will ever do by hand.
Checklist: what to do first
- Inventory "everyone" shares across your document repositories and close the ones with no justification.
- Review permissions in the most sensitive libraries — HR, finance, the board, contracts.
- Design a handful of sensitivity labels that reflect your real data classification and roll them out in the most important areas.
- Turn on basic DLP policies blocking the riskiest channels for data leaving the organization.
- Check conditional access policies for the accounts that run automations.
- Establish what is the test environment and what is production, and describe the path between them.
- Prepare the documentation — justifications, procedures, owners. Not after the fact, but alongside the change.
- Set retention policies deliberately, with a justification for every deviation from the defaults.
Frequently asked questions
Does Copilot have access to all our documents?
Only to those the signed-in user has access to — no more, no less. That’s why a permissions review is a precondition, not an option.
Does data leave the European Union?
In default configurations of EU tenants, anything that could cause data transfer outside the EU is turned off. The risk appears with deliberate configuration changes and with the use of external tools on personal accounts.
Where should we start if we only have resources for one thing?
With DLP policies. It’s the fastest way to reduce the risk of data leaving the organization.
Do we need everything in order before we start?
No. You need to know where the biggest risks are and close them in order. Waiting for perfectly clean data means your employees are using personal tools in the meantime.
Can an AI assistant generate an answer based on a document I don’t have access to?
No. But it will generate one based on a document you have access to by mistake — and that’s exactly what this article is about.
Nine times out of ten, AI security in a company is about tidying up things that should have been tidy regardless of AI: permissions, classification, data leakage policies, retention. The assistant only brings forward the moment when the backlog becomes visible.
You don’t need a perfect starting point to begin. You need to know which risk you’re closing first — and to do it before your employees solve the problem their own way, on personal accounts.