GDPR does not forbid AI in strategy work. It requires you to know which personal data you process, to send only what is necessary, and to have a reason for it. Classify your data sources once, and everything after that becomes a setting rather than a judgement call.
Most discussions about GDPR and AI end with somebody saying "we don't dare", and then no strategy work gets done with AI at all.
That is an expensive way to be careful, because it is not actually safer. It just defers the decision until somebody does it anyway without asking.
Here is the practical version.
The four levels, and why the order matters
Classification is not bureaucracy. It is the one decision that makes all the following ones automatic.
- PUBLIC. Public news, your articles of association, published prices.
- INTERNAL. Internal analyses, meeting notes without personal data, sales pipeline.
- CONFIDENTIAL. Contract terms, how you earn, pricing decisions not yet announced.
- RESTRICTED. Personal data, and exact financial figures. Employment terms, national ID numbers, private contact details, revenue, margins, EBITDA, customer acquisition cost and exact pricing.
The levels and the edge cases are worked through in the four classification levels.
What matters is that the classification sits on the source, not on the individual request. If it sits on the request, somebody has to decide every time, and they will decide it wrong on a busy Thursday.
What stops data on the way in
There are three layers between your data and the model, and they can do different things. The difference is worth understanding, because it determines what you can rely on.
Field classification. Fields marked sensitive are stripped based on which kind of model is at work. This is the only categorical layer: it does not guess, it looks up. If a field is RESTRICTED for that node type, it is not sent, and there is no phrasing that gets it through anyway.
Secrets scanner. Catches keys, passwords, tokens and certificates in free text. That sounds like something that does not happen in strategy documents. It happens in meeting notes.
Personal data in transit. Names, emails, phone numbers, national ID, IBAN and card numbers are handled by the layer closest to the provider, wrapped around the call itself.
The last two are pattern matching. Pattern matching fails in both directions: it can let something through, and it can block something harmless. Which is why classification carries the responsibility. The other two layers are a safety net, not a plan.
In practice it plays out like this. You ask for an analysis of your ten largest customer segments and attach the customer list.
You do not simply get an answer. Depending on which layer reacts, one of two things happens: the request is refused with a message to remove the sensitive material and try again, or the personal data is handled on the way to the model and the analysis proceeds without it.
Both outcomes are usable, but they are not the same, and the difference is worth knowing. A refusal is obvious. Handling in transit is not, which is why the classification belongs on the source: then you know in advance what never goes in, rather than discovering it in an analysis that is quietly missing something.
What stops data on the way out
The entrance is only half of it. The model can also end up repeating something it was handed in context.
So there is also a check on the response on the way out. If it contains credentials, it can be blocked before reaching you, and personal data is handled by the layer that wraps the call and therefore covers both directions.
Be aware that the exit check is not active on every path through the system. It is a supplement, not a guarantee, which is why the classification at the entrance is what carries the security.
Think of it as an airport with two checks. One looks at what you bring in. The other looks at what comes out at the gate. They do not catch the same things, and that is the point.
Four misunderstandings that cost time
"If it's EU-hosted, it's safe." No. EU hosting settles where data is processed. It does not settle what you send. Send an unanonymised customer list to an EU data centre and it is still a processing of personal data you need to justify.
"If the data is anonymised, anything goes." Almost. If the recipient can identify the person from context, it is still personal data. "Customer segment A" without names is genuinely anonymous. "Our largest customer in southern Denmark" is not.
"We'll just report it to the authority afterwards." That is not how it works. A personal data breach carries a notification deadline, and notifying does not make the breach lawful. Talk to your adviser before you start, not after.
"They delete data after 30 days, so we're fine." Deleting after a mistake does not make the mistake permitted. The processing happened.
Four steps before the next management meeting
1. Classify the sources, thirty minutes. Not all your data. The ten sources you actually use for strategy work. A table with source and level.
2. Write down your own red lines, thirty minutes. Beyond personal data, what should never be sent in your company? For some it is customer names. For others it is financial projections or a patent application not yet filed. That is a business decision, not a legal one.
3. Ask your vendor three questions, one minute. Where is our data processed, is it used for training, and who are the subprocessors? Get it in writing. It is one email.
4. Start on PUBLIC. Let the management team run an analysis on public data first. Market trends, competitors' annual reports. No personal data at all. Once you can see what the system does with data you are not nervous about, it is easier to decide whether to move up to INTERNAL.
The fourth point is the one that works, and it is the one most often skipped. People try to settle the question in the abstract at a meeting, instead of trying it on something harmless for twenty minutes.
Why classification sits on the node type on our side
The weak link in any data classification is that a human has to remember it at the exact moment things are busy.
In 360° Sprint, fields that are RESTRICTED are therefore bound to the node type rather than to the user. They are never sent to any AI provider, and it cannot be switched off in a setting. Every state change is logged, so it can be documented afterwards what was processed when, which is precisely what GDPR asks you to be able to show.
Processing happens on EU territory. Why that is about where rather than about the vendor's nationality is covered in AI and data security in the EU, and what the EU AI Act requires on top of it is in the EU AI Act for SMEs.
GDPR and AI work together perfectly well. It just requires the classification to happen before the request rather than during it.
The full route from the question to a decision is in can we use AI on our own data.