If you use AI to analyse markets, competitors and business models, you sit at the lighter end of the EU AI Act. The duty that applies broadly is AI literacy among the people using the systems. Transparency obligations attach to specific situations rather than to all use. Documentation and human oversight are good practice rather than statute.
You have heard about the EU AI Act. Somebody in management has grown nervous, and there may already be a consultancy quote on the table.
Take a breath. Most of the concern does not apply to you if you use AI for strategy work rather than for making decisions about people.
Three things to work through: what the law sorts by, where you realistically have work, and how to document it yourself.
The law's four tiers
The regulation sorts by what the system is used for, not by how advanced it is. That is the most important sentence in this article.
Unacceptable risk. Social scoring and manipulative systems. Prohibited.
High risk. Systems that genuinely decide something for a person. Hiring, credit assessment, access to education or services, critical infrastructure. Real obligations here on risk management, data quality, documentation and human oversight.
Limited risk. Systems with transparency obligations. People must know they are interacting with AI, or that content was generated.
Minimal risk. Everything else.
Strategy analysis sits in the lower half. Not because the work is trivial, but because the system does not decide anything for a person. It supplies a basis. You make the decision.
The regulation entered into force in 2024 and applies in stages, with the prohibitions arriving first and the high-risk obligations later. Which date applies precisely to your case is worth confirming with your adviser rather than with an article, because the stages land differently depending on the type of system.
Where you actually have work
It is worth separating two things here, because they get conflated almost everywhere: what the law requires of you, and what you should do anyway.
What the law actually imposes. If you use AI for internal analysis rather than for decisions about people, the list is short. The most broadly applicable obligation is the AI literacy requirement: staff working with these systems need a reasonable grasp of what they do and where they fall short. It applies widely and gets overlooked, precisely because it does not sound like compliance.
Transparency obligations, by contrast, are not general. They attach to specific situations, principally where someone interacts directly with an AI system and should know it, and where content is synthetically generated. An internal analysis for a management meeting is typically neither.
What you should do regardless. The following is good practice rather than statutory requirement, and it is still what saves you:
- Documentation. Four lines per analysis: which model, which data in, what came out, and what you used versus discarded. A folder per strategy cycle, not a system.
- Internal openness. If an AI-generated analysis goes into board material, write that down. One line is enough.
- Human oversight. Somebody must be able to explain why you followed one analysis and not another. Not as an AI expert, but as a professional.
The last point protects you best, whatever the law says. How to make it a standing part of board work is covered in three things your board should demand.
Note that the above is an introduction and not legal advice. Which provisions actually reach you depends on what you use the system for, and an adviser should confirm it.
Where it becomes real work
Be honest about when you are at the heavy end. Three cases:
- You use AI as part of hiring or in assessing employees.
- You use AI in credit assessment or in KYC and anti-money-laundering checks.
- You cannot explain what the model did. That is a problem in itself, including when the risk is low.
If you are in any of the three, get help. That is not a place to economise.
If instead you use AI to analyse markets, competitors, capabilities and alternative business models, it is manageable without outside assistance.
The checklist, before you use it the first time
- Choose a platform that can answer precisely which data goes where. If it cannot, the answer itself is informative.
- Make sure a field classification exists, so sensitive data cannot be sent by accident. The levels are described in the four classification levels.
- Write a three-line policy: we use AI for analysis, data is anonymised before sending, output is validated by a human before a decision.
- Keep the analyses. Date, input, output, who approved.
- Have the management team able to answer three questions about any AI analysis: what did we ask, what did we get, and what did we choose to do.
The list takes a few hours to set up and a couple of hours a year to maintain.
What it looks like in practice
The board has to assess an acquisition.
Without AI, members read market reports, compare accounts by hand and discuss. The documentation becomes a set of minutes.
With AI assistance you supply aggregated market data, the target's published accounts and your own key figures. The analysis runs through the five lenses relevant to an acquisition. The board reads, discusses and decides.
The documentation becomes: on 4 April we analysed company A through five lenses, the analysis showed this, the board decided that, and the reasoning was this.
That is both more useful and more defensible than the minutes. The method behind the five lenses is in from data to decision.
Why the place of processing matters
Several large platforms send data to servers outside the EU by default.
For strategy work that is sensitive, not because the content is necessarily secret, but because it reveals what you are considering. Your worries are often more revealing than your numbers.
If processing sits inside the EU, it is processing under GDPR and the documentation becomes simple to write. Note that this is about where processing happens and who can be compelled to disclose, not about the vendor's nationality. That distinction is developed in AI and data security in the EU.
Three questions for your vendor
- Where are our requests processed? If the answer is not a country, that is an answer in itself.
- Which fields are never sent to a model? If no classification exists, you build it yourself.
- Is our data used for training? That belongs in the contract, not in an email.
Why classification is bound to the model on our side
The reason compliance usually slips is that it rests on somebody remembering something.
In 360° Sprint, fields that are RESTRICTED are therefore bound to the node type and never sent to any AI provider, regardless of who is working in the system. Every state change is logged, which is precisely the documentation both GDPR and the AI Act ask for, and which otherwise has to be written by hand afterwards.
That does not solve your compliance. But it moves it from something to be remembered to something that can be shown.
How this fits with GDPR day to day is covered in GDPR and AI-assisted strategy.