Is AI banned in security-sensitive work, and what do the rules actually say
The assumption that AI is banned in security-sensitive work is false. Sweden's Security Service writes the opposite: its use will become necessary. What exists are separation requirements, and they follow the classification.
Key insights
- Sweden's Security Service has no general AI ban. It writes the opposite: the use of AI and new working methods for defensive purposes will become necessary.
- The requirement follows the classification, not the technology. Physical separation is required for information systems handling data classified as secret or above.
- The AI Act exemption in Article 2(3) attaches to the purpose, not the organisation. A defence company's recruitment system is therefore not exempt, but high risk under Annex III.
- The Security Service describes the risks as a business risk and a management issue, not only a technical risk. That places the decision with leadership rather than with the IT function.
Few assumptions stop as much work as the belief that AI is banned in security-sensitive activity. The assumption is rarely offered with a citation, and it is not correct.
What the Security Service actually writes
In its text on the effect of AI models on cybersecurity, published on 24 June 2026, Säkerhetspolisen, the Swedish Security Service, points to the provisions on logical and physical separation and one-way communication for information systems holding security-classified data. It is equally clear about where the strictest level sits: physical separation is a requirement for information systems that are to handle security-classified data in the classification secret or above.
Those are requirements on how a system is kept apart. They are not a prohibition on what may run inside it.
The authority goes further. The same text states that the use of AI and new working methods for defensive purposes will become necessary.
Abstaining is not a neutral choice, because what goes unbuilt carries a risk of its own.
The difference between the two readings is practical rather than academic. A prohibition ends the discussion. A requirement on working methods instead opens a question about how the activity should be divided, and that question can be worked on.
The requirement follows the classification, not the technology
What decides the position is the security classification of the data, not whether the tool contains a language model. The starting point is therefore the protective security analysis, meaning the assessment that answers what is to be protected, against what, and how.
That sounds obvious and is not, in practice. Very few organisations have their entire activity in the highest classification. Most have a bounded part that is security-classified and a considerably larger part that is not. When the whole organisation is treated as though it sat in the highest classification, that is rarely a requirement of the rules. It is the result of nobody having drawn the line.
The reason for abstaining is more often that the question was never asked than that the answer was no.
The second assumed prohibition
Closely related is the assumption that suppliers outside the EU are ruled out. That does not hold as a general rule either.
The Swedish government's cloud policy, issued by the Ministry of Finance in 2026, states that public administration will continue to be able to use market-leading products and services even where they come from companies established outside the EU. The policy instead sets out what the choice should be governed by: the requirements applying to the activity in question, including function, security, control, sovereignty, robustness and cost-effectiveness.
That is a risk-based approach rather than a list of permitted countries. It makes the decision harder to take and easier to justify, which is the trade-off Swedish security regulation often makes.
The third assumption runs the other way
The two assumptions dealt with so far concern prohibitions that do not exist. There is also an assumption running in the opposite direction, and it is at least as common: that the EU AI Act does not apply at all, because the activity is defence or national security.
The exemption exists and it is broad. Article 2(3) provides that the regulation does not apply to AI systems where and in so far as they are placed on the market, put into service, or used with or without modification exclusively for military, defence or national security purposes, regardless of the type of entity carrying out those activities.
But the exemption attaches to the purpose rather than to the organisation, and the whole boundary sits in the word exclusively. Recital 24 states plainly that a system placed on the market or put into service for an exempt purpose and at the same time for one or more non-exempt purposes, such as civilian purposes or law enforcement, falls within the scope of the regulation.
The practical consequence is uncomfortable for much of the sector. A defence company's recruitment tool is not covered by the exemption, because recruitment is an employment and commercial purpose rather than a military one. Such systems are moreover expressly high risk under Annex III point 4. The same holds for most administrative support: finance, personnel, document handling and customer service.
The two assumptions therefore pull in opposite directions and both are wrong. That nothing may be done, and that nothing needs to be done.
Why this belongs to leadership
The Security Service places the responsibility explicitly. The risks relating to AI development are a business risk and a management issue, not only a technical risk.
A business risk cannot be delegated to the IT function as a matter of configuration. It concerns what activity the organisation is going to conduct, with what data, and what it is prepared to forgo. Those are decisions that belong where business responsibility sits.
The consequence is uncomfortable in both directions. Leadership cannot blame the technology for not allowing something, and it cannot hand the question over and call that caution.
Four questions that settle it
- Which parts of the activity actually handle security-classified data, and in which classification? Without that answer everything else is guesswork. The set is almost always smaller than the organisation assumes.
- Which systems therefore fall under the separation requirements? Physical separation for secret or above; logical and physical separation together with one-way communication otherwise, for systems holding security-classified data.
- What remains outside that set? That is where the room to act lies, and it is usually larger than expected. Administration, training, open-source analysis and internal documentation rarely belong to the protected part.
- Who owns the decision? If the answer is the IT function, the question is misplaced according to the Security Service's own description.
The assessment in any given case starts from the organisation's protective security analysis, and it is that analysis that decides what is possible.
Common questions
No. Sweden's Security Service, Säkerhetspolisen, has no general prohibition on AI in security-sensitive work. Its text on the effect of AI models on cybersecurity states the opposite: that the use of AI and new working methods for defensive purposes will become necessary. What exists are requirements on how information systems are designed, and those follow the security classification of the data.
The Security Service points to the provisions on logical and physical separation and one-way communication for information systems holding security-classified data. For data in the classification secret or above, physical separation is a requirement. The requirements concern how the system is kept apart, not which technology runs inside it.
In part. Article 2(3) of the AI Act exempts AI systems placed on the market, put into service or used exclusively for military, defence or national security purposes, regardless of the type of entity carrying out those activities. The exemption attaches to the purpose rather than to the organisation, so a defence company is not exempt as such.
Yes. Recruitment is an employment and commercial purpose rather than a military one, so such systems are not covered by the Article 2(3) exemption. They are also expressly classified as high risk under Annex III point 4. Recital 24 states that a system used both for an exempt and a non-exempt purpose falls within the scope of the regulation.
Yes, on a risk-based approach. The Swedish government's cloud policy states that public administration will continue to be able to use market-leading products and services even where they come from companies established outside the EU. The choice of solution and supplier should be governed by the requirements applying to the activity in question, including function, security, control, sovereignty, robustness and cost-effectiveness.
Leadership. The Security Service writes that the risks relating to AI development are a business risk and a management issue, not only a technical risk. That is a clear placement of responsibility: the question cannot be delegated to the IT function as a technical detail, because it concerns what activity the organisation is going to conduct and with what data.
No. The separation requirements apply to the information systems that handle security-classified data. An organisation normally also has activity that handles no such data, where the same requirements do not apply. The reason to abstain entirely is therefore rarely the rules, but that nobody has divided the activity up and said which part is which.
The protective security analysis is the assessment that answers what is to be protected, against what, and how. It is the starting point for the AI question too, because it determines which data is security-classified and therefore which systems fall under the separation requirements. Without that analysis there is no way to decide what is permitted.
Most likely because the separation requirements are real and demanding, and are therefore easily read as a prohibition. A requirement that a system be physically separated is not the same as a prohibition on the technology inside it. The difference is practical: a prohibition ends the discussion, whereas a requirement on working methods opens a question about how the activity should be organised.
Establish which parts of the activity actually handle security-classified data, and in which classification. From there it becomes possible to see which systems fall under the separation requirements and which do not. That set is almost always smaller than the organisation assumes, and the room to act lies in the remainder.
If this lands on your desk, we should talk.
Ampliro Insights
New analysis, roughly weekly.
We write when the rules change and when something turns out to work in practice. One piece at a time, no sequences, and you can leave from any issue.
We store your address to send Ampliro Insights, and for nothing else. More in the privacy policy.