Take control of your AI requirements and risks.

Requirements depend on your operations, the information involved and how AI is used. The EU AI Act, GDPR, NIS2 and DORA have different purposes and scopes. The same AI solution may be affected by several frameworks at once.

The first step is to map your AI systems, data flows and roles. Are you developing your own solution, integrating an external model or using a finished service? A clear assessment of applicable requirements makes security work more precise and reduces the risk of important obligations falling between organisational boundaries.

A supplier’s documentation is one input. You also need to assess how the service is used in your particular organisation.

The EU AI Act sets different requirements depending on the system’s risk classification and the organisation’s role. For high-risk systems, these include risk management, documentation, human oversight, robustness and cybersecurity. The obligations of the provider and the deploying organisation, and when they apply, must be clarified. (Shaping Europe’s digital future)

Procurement, implementation and ongoing management therefore need to connect. Who approves use? Who monitors changes? And who acts if the system begins to behave in a way that creates risk?

When AI processes personal data, GDPR applies. You need a lawful basis, clear purposes and security proportionate to the risks. Data minimisation, retention periods, access rights and data-processing agreements must be managed. Processing likely to result in high risk may require a data protection impact assessment. (imy.se)

Information flows include more than uploaded documents. Instructions, responses, logs and backups can also contain protected information. You need to know what is retained, for how long and whether it is used for other purposes.

Storage in the EU does not automatically resolve the question of international transfers. Access by a recipient outside the EU/EEA may be subject to transfer rules. You must assess the applicable transfer mechanism and any supplementary safeguards. Encryption can contribute to protection, but does not replace the legal assessment. (imy.se)

NIS2, implemented in Sweden through the Cybersecurity Act, imposes security requirements on organisations within scope. Key areas include risk management, incident handling, continuity, supply chains, access control and cryptography. AI services must be included when they affect the organisation’s network and information systems. (mcf.se)

For financial entities within scope, DORA requires digital operational resilience, including ICT risk management, incident reporting, testing and control of external ICT providers. An AI service must therefore be assessed according to its importance and the impact of failure or disruption. (eba.europa.eu)

Suppliers not directly in scope may still encounter security requirements through customers’ contracts and procurement. The ability to demonstrate security therefore becomes a commercial issue as well.

Encryption at rest and in transit are important safeguards. But how is information protected during processing? Who controls the keys, and which users, administrators or subcontractors can gain access?

DORA’s supplementary technical rules connect cryptographic controls to information classification and risk assessment. They address encryption at rest and in transit, where appropriate data in use, key management and the updating of cryptographic technology. (EUR-Lex)

This requires an integrated assessment of technology, permissions and working practices. An encrypted connection does not, for example, prevent an authorised AI agent from sharing information with the wrong recipient.

The Cyber Resilience Act may be relevant when you provide software or other products with digital elements on the EU market. It covers cybersecurity and vulnerability management throughout the product lifecycle. Scope must be assessed for the specific product; not every standalone AI cloud service is automatically covered. (Shaping Europe’s digital future)

For activities important to Sweden’s security, the Protective Security Act adds further obligations. AI use must then be considered against the protective security analysis and information-security requirements. Procurement and collaboration may also require protective security agreements. (sakerhetspolisen.se)

Policies must be translated into accountability, controls and follow-up. You need to show which risks have been identified, which measures have been implemented and how deviations are handled.

ISO/IEC 27001 for information security and ISO/IEC 42001 for AI management systems can provide structure. They are standards, not laws, and certification does not automatically mean that all legal requirements have been met. (Popular standards)

Sufficiently powerful quantum computers could break major asymmetric cryptosystems such as RSA and ECC. When this becomes practical is uncertain, but information requiring long-term protection is already relevant to the Harvest Now, Decrypt Later threat: attackers can collect encrypted data today and attempt to decrypt it later. Post-quantum cryptography, PQC, is designed to resist such quantum attacks. (NIST)

The EU’s coordinated roadmap says member states should begin the transition by the end of 2026 and that critical infrastructure should transition to PQC by the end of 2030. This is a common roadmap, not a general legal requirement for every company to be fully quantum-safe by 2030. (Shaping Europe’s digital future)

At the same time, the risk-based security requirements of NIS2 and DORA make it relevant to assess quantum-related risks and the need to update cryptography. Non-compliance can lead to supervisory measures and penalties, but there is no general PQC penalty deadline for every organisation. Begin by inventorying cryptographic dependencies, identifying information that must remain secret for a long time and requiring suppliers to provide migration plans. (EUR-Lex)