Scrydon position on the Cloud and AI Development Act

COM(2026) 502 final, 2026/0138(COD)

September 2026

Scrydon welcomes the Cloud and AI Development Act. For the first time, Union law gives buyers a structured, harmonised way to assess the sovereignty characteristics of cloud services and gives European providers a framework (Article 16 and the Annex) in which real sovereignty engineering — rather than marketing — is what wins public contracts.

What Europe names "sovereignty" is in substance three distinct things at once: economic security, jurisdictional control, and resilience in the face of unpredictable foreign policy — sanctions, export controls and security directives that can reach into the stack at any moment. The asymmetry is revealing: Union law leaves national security to Member States and the AI Act excludes systems placed on the market or used exclusively for military, defence or national-security purposes, while the United States runs its federal cloud and AI regime through it. FedRAMP itself sets no citizenship or ownership bar; the regime layered around it does. Moderate and High baselines require US data residency and US-person access, export-controlled workloads must be handled by US persons on US soil, and Defense Impact Levels are served from dedicated, US-staffed enclaves. The point is: every serious government-grade regime draws a trust boundary somewhere. The question is where it is drawn, and by what mechanism — and CADA's assurance levels are the first instrument with which Europe answers in kind.

Sovereignty is not a binary state, and for the organisations that make up Europe's public sector and industrial base it is above all a trajectory. Almost no organisation can move its estate to a fully sovereign environment in one step. AI, moreover, is not legacy. Europe has no frontier model of its own, but the race is not settled, and the next generation of lock-ins is forming now, before the market has a winner. That is what makes this the moment: the dependencies of the last technology wave were understood only once they were irreversible; these can still be avoided. What an organisation can do is advance step by step — starting where it stands, with its compute and its data most often on a hyperscaler, and deciding deliberately what moves, and when: each part of the estate weighed by the sensitivity of the data it touches, the criticality of the function it serves and the cost of losing it, its independence and resilience raised accordingly — EU data residency and customer-held keys first, confidential computing next, European cloud or on-premises deployment where criticality requires it, air-gapped operation at the top. The same discipline applies to the models themselves: chosen by necessity, moving freely between open and closed weights and across price points, so that capability, efficiency and control are balanced workload by workload. Scrydon has built its platform around exactly this journey: the same AI and data stack runs unchanged from public cloud to edge and air-gapped environments on standard, open foundations, and models swap as freely as workloads move — so that climbing a level, or changing model, is a migration rather than a re-platforming.

CADA's four assurance levels already describe this graduation. What the Act does not yet describe is movement between them. Six changes would make the framework operational:

• Recognise the trajectory. Assurance should attach to individual services and workloads, procurement risk assessments should credit documented migration paths to higher assurance levels, and reversibility should be defined and required — so that progressive independence becomes a procurable, auditable property. An assurance level should also not be a one-time stamp: it should be re-verified, and lapse, on a material change of control or of the operating stack — otherwise a provider approved today carries its level intact through an acquisition by a non-Union owner tomorrow.
• Define sovereignty so it cannot be washed — and close the routes around it. The framework needs an enforceable definition in Article 2 — which as published skips points (23) and (24) — anchored in European legal and operational control, because data sovereignty without operational sovereignty is half a sovereignty, and centred on the question most of the published debate skirts: whether the entity operating the service can be compelled, by a production order, by sanctions or by an export-control directive, to disclose the data or to interrupt the service. Criteria at every level should be clear, auditable and consistently enforced, and the audit ecosystem should itself be under European jurisdiction. Two things then decide whether the definition holds in practice. Level 1, where the Commission expects around 70% of public contracts to sit, is met today by self-assessment and a self-issued statement of conformity; sensitive workloads below the classified threshold should require at least minimal independent verification, and FedRAMP shows that independent assessment at the lowest tier is normal and workable. And both derogations need bounding: admission of third-country providers to Level 3 on conditions such as a GDPR adequacy decision rests on an instrument annulled twice in a decade, and should be confined to providers that demonstrate the verifiable control the level itself requires rather than extended by recital to all certified organisations; the general no-adequate-or-reasonable-alternative derogation should be narrow, time-limited, published with reasons, and paired with a duty to re-tender as alternatives mature.
• Credit verifiable technical controls. Customer-held key management, hardware-attested confidential computing and a European-controlled software layer measurably reduce exposure — including on third-country infrastructure. They are not a substitute for the requirements of levels 3 and 4, and we do not ask that they be treated as one. But ownership is not self-executing either: a European provider can be reached by a foreign order — a Canadian order in 2024 reached data held in France by a European host — and an approved European provider can be acquired. Levels 3 and 4 will deliver what they promise only if their criteria are expressed in terms of verifiable control alongside ownership: who holds the keys, who can read plaintext, and whether the service can be continued without the cooperation of any single third-country-controlled party. Within levels 1 and 2, those same controls are precisely the resilience the Act should reward.
• Make the framework work for SMEs and the software layer. Presumption of conformity for services already certified under proven European schemes; division into lots under Article 46 of Directive 2014/24/EU, so that an SME can bid for the part of a contract it can deliver instead of being shut out of the whole; an adoption target for sovereign services; and a 'Union added value' test that counts software, services and open source, not only hardware and data-centre capacity. The demand-aggregation and joint-procurement machinery the Act already establishes should serve the same end, rather than concentrating demand on the handful of providers able to answer a single undivided call.
• Build on open standards, not new silos. Open standards and open interfaces enable portability and interoperability, with open-source or independently auditable components where verification matters most — not a requirement that every layer be open source: proprietary innovation on top of open foundations is how European providers differentiate. The Act already asks deployments to consider multi-vendor and multi-cloud strategies; that provision is the natural place to give portability substance — documented exit plans, data and model portability in open formats, and no contractual or technical impediment to moving a workload.
• Extend the discipline to the AI layer. Title II funds the next platform layer — agent platforms, public-sector AI, national strategies. The same sovereignty logic the Act applies to cloud must apply there: agent platforms built with Union support should be open, interoperable and model-agnostic; public-sector AI should run on open-weight models organisations can inspect, fine-tune and operate under their own control — not because openness is itself sovereignty, which it is not, but because inspection, fine-tuning and self-hosting are what make a model substitutable; and national strategies must cover the software and platform layer, not only data centres.

There is a competition logic behind these asks that deserves to be stated plainly: relying on open source alone will not produce the best sovereign solutions — portability will. When workloads, and the platforms that run them, can move across clouds, infrastructure providers compete on infrastructure: price, energy, capacity. The way is then open for higher-value services on top, in AI and data, to compete on capability at a different level. Separating those two planes of competition is what the changes we propose are designed to achieve, and it is the level at which European providers can win.

Scrydon would welcome the opportunity to discuss any of these points with the co-legislators, and to provide technical detail on the controls described above.