DPO & HEAD OF IT
Data protection and sovereignty
For a long time, digital sovereignty was a trade-fair topic. Since 2026, it has been a purchasing requirement: tenders demand exit strategies, supervisory authorities ask about third-country transfers, and since 12 September 2025 the Data Act has given you enforceable rights when switching cloud providers. At the same time, AI is shifting the data protection question: personal data ends up in prompts, training data and tool integrations, often without anyone having reported it. For DPOs and heads of IT, this means the role is changing from the checkpoint at the end to the architect at the beginning. We support you in designing data flows with sovereignty – with robust contracts, realistic exit scenarios and an AI record of processing activities worthy of the name.
Legal status as of 24 September 2026
Sovereignty has become measurable
In 2026, the term lost its vagueness. Three developments have made it concrete. First, the Data Act, applicable since 12 September 2025: it gives cloud customers binding rights to switch providers, obliges providers to ensure portability and interoperability, and gradually phases out switching charges. An exit scenario is therefore no longer contractual cosmetics; it is applicable law with enforcement leverage. Second, the geopolitical situation: the dependence of European companies on non-European cloud and AI providers has gone from a strategic footnote to a board-level topic, and third-country access rights to the data of European customers have never been conclusively resolved in legal terms since Schrems II (CJEU, C-311/18): following the dismissal at first instance (General Court, T-553/23, judgment of 3 September 2025), an appeal against the EU-US Data Privacy Framework is pending before the CJEU, and the Court has already struck down the two predecessor agreements. Third, procurement practice: public and regulated contracting authorities now write sovereignty requirements directly into tender documents. Anyone who cannot deliver loses contracts – without any fine at all.
AI has rewired data protection in three places
First, at the input: employees enter personal data into AI tools, often into tools that have not been approved. Each of these operations is processing within the meaning of the GDPR, with all the consequences for legal basis, purpose limitation and, where applicable, third-country transfer. Second, in the system: AI functions find their way into existing software via updates, from the office suite to the CRM. In most organisations, the record of processing activities under Article 30 GDPR does not reflect this, and the data protection impact assessment under Article 35 GDPR becomes due for systems that were still harmless two years ago. Third, at the output: enrichment functions, automated assessments and generated content create new personal data whose origin and accuracy must be demonstrable. Anyone who waits here until something happens will end up managing a reportable incident under Article 33 GDPR instead of a process. The supervisory authorities’ benchmark is no secret: the guidance of the German Data Protection Conference (DSK) on AI explicitly names closed, in-house systems as preferable.
The new division of labour between DPO and head of IT
The classic division of roles – IT builds and data protection checks afterwards – no longer works for AI and the cloud. The decisions with the greatest data protection impact are made in the architecture: which model runs where, which data leaves which region, which logs are created, who can view them. If the DPO only gives a verdict after procurement, only expensive options remain. The effective approach brings data protection and sovereignty into the definition of requirements: data classification before tool selection, transfer impact assessment before signing the contract, exit scenario before migration. This sounds like extra effort and, in every project we have supported, it saves the later retrofitting, which is regularly more expensive than proper planning.
What needs to be done now, in concrete terms
Four work packages in a clear order. First, the AI inventory: record all AI systems and AI functions, including built-in ones, and transfer them to the record of processing activities. Second, the transfer situation: review third-country transfers for each system, document each provider’s certification status under the Data Privacy Framework (without active certification, only standard contractual clauses plus a transfer impact assessment will hold), and realistically assess third-country access scenarios. Third, exit capability: for the two to three most critical cloud and AI dependencies, draw up a documented switching scenario with data formats, deadlines and costs, based on the rights under the Data Act. Fourth, reporting capability: a process that meets the 72-hour deadline of Article 33 GDPR for data breaches in an AI context, including the question of how to detect an incident in an externally operated AI system in time in the first place.
Four work packages in a clear order.
Our offer
We work where the GDPR, the Data Act and the AI Act overlap, and translate the legal situation into architecture and contract decisions. Specifically: AI record of processing activities, DPIAs for AI systems, transfer assessments, exit strategies, sovereignty assessment of your cloud and AI stack. As a starting point, we offer a compact checklist for sovereignty assessment that lets you roughly classify your own stack within an hour. For everything else, our standard applies: modular, transparent pricing, cancellable at any time.
DOWNLOAD · PDF (GERMAN) · 107 KB
Sovereignty assessment checklist (PDF, German)
Roughly classify your cloud and AI stack within an hour.
Book an initial consultation
The logical second step after the checklist: we translate the legal situation into architecture and contract decisions.
MODULAR · TRANSPARENT PRICING · CANCEL AT ANY TIME
