From European Technology Sovereignty to Operational Reality

Personal submission to Ireland's consultation on the proposed Cloud and AI Development Act

Corin Bishop | Technology Infrastructure & Strategy Leader | Ireland
Personal submission | September 2026

I am submitting in a personal capacity as a technology infrastructure and strategy leader with experience across cloud platforms, technology economics, AI infrastructure, governance and organisational change. This submission does not represent my employer and contains no confidential employer information.

My comments primarily address consultation questions 7 to 10 on sovereignty, proportionality and implementation, with supporting observations relevant to questions 2 to 4 on enterprise competitiveness and adoption.

Overall position

I support the objective of strengthening European cloud and AI capability and reducing critical technological dependencies. European organisations should have credible choices about the technologies on which essential services depend. Achieving that requires investment in competitive European capability, but it also requires organisations to be able to use that capability in practice.

CADA provides a substantial foundation. Its proposed sovereignty assurance levels, risk-assessment methodology, provider evidence requirements and adoption measures address important parts of the problem. In particular, the framework recognises that technological sovereignty is not only concerned with where data is stored. It includes jurisdiction, operational control, software dependencies and the risk of service disruption.

My principal concern is the connection between assurance and operational reality.

A provider can satisfy an assurance framework while a customer's business service remains difficult to continue or relocate. Identity, data, connectivity, integrations, monitoring, security controls, operational processes and skills can all sit outside the component being assessed. Conversely, a customer may have technically portable software but no alternative environment with the capacity, connectivity, support or operational readiness required to run it.

For critical services, sovereignty assurance should provide proportionate evidence that the service can continue or transition when an important technology dependency becomes unavailable or unacceptable.

A dependency does not have to fail technically to create this situation. It may become unacceptable because of a jurisdictional change, regulatory requirement, loss of support, change in ownership or control, security concern or other strategic constraint.

Continuity is the business objective. Substitution, portability and transition are mechanisms that may allow an organisation to achieve it.

Assurance should therefore not establish only that a provider or service has particular characteristics. For important services, it should provide evidence that dependencies are understood and that continuity or substitution is credible for the scenario being addressed.

The proposed framework already contains elements of this approach. However, they are not applied consistently. I recommend three improvements:

• Strengthen assurance around demonstrated continuity and substitutability, and connect provider assurance to buyer readiness.
• Retain a clear transition timetable while providing a tightly controlled mechanism for cases where the transition itself cannot safely be completed within the maximum period.
• Reduce the practical cost of transition by investing in target-environment readiness, reusable implementation patterns and evidence of what actually makes complex services portable.

1. Assurance should measure demonstrated continuity and substitutability

Relevant provisions: Article 16(2), Article 21, Article 29(2) and 29(3), Annex II and Annex III.

Article 29(2)(c) requires the risk assessment to consider the risk and impact of possible service disruption. The assurance framework should therefore give buyers meaningful evidence about the ability of a service to withstand or respond to that disruption.

There appears to be an important inconsistency in how this is implemented across the assurance levels.

At Levels 2 and 3, Annex II requires controls intended to block remote features capable of materially tampering with or disrupting systems or software. It also requires a documented migration plan where a vendor fails or a third country imposes restrictions.

At Level 4, those requirements are replaced by a test concerned with retaining effective control over software components or products and whether a third country holds or exercises effective control over their design, development, maintenance and evolution.

This means that two operational controls present at Levels 2 and 3, disruption resistance and migration planning, are no longer explicitly present at the level intended to provide the strongest sovereignty assurance.

Annex III goes further by identifying evidence including tests and a switchover plan enabling migration to alternative solutions. However, Annex III is indicative evidence rather than the binding assurance criterion itself.

I recommend that the operational intent already present in the framework be made consistent across the assurance levels. In particular, the tested substitution and switchover requirements described in Annex III should be reflected in the binding criteria in Annex II, using the mechanism available under Article 16(2).

The purpose should not be to require every provider or customer to perform a full production migration simply to demonstrate compliance. Testing must remain proportionate.

A documented plan, a component replacement test, a restore exercise and a complete service transition demonstrate different things. The evidence should state what was tested, what succeeded, what remains dependent on the existing provider, and when the test took place.

A viable continuity option may also provide reduced functionality. For some business services, continuing a minimum critical function for a defined period is more important than reproducing the entire production environment immediately.

Provider assurance and buyer readiness are different

Strengthening provider assurance solves only part of the problem.

Recognition of a provider does not establish that a customer's business service can move to it.

This distinction matters in established technology estates. The core platform is often only a small part of the transition problem. Applications can depend on identity services, data interfaces, network connectivity, security controls, monitoring platforms, operational tooling and integrations that have accumulated over many years.

Changing the underlying provider does not remove those dependencies.

In practice, this integration surface can determine whether an alternative is viable long before the basic compute, storage or software capability does. A technically comparable target can therefore still require substantial redesign or remediation before it becomes an operational alternative.

I recommend that the Article 29(3) methodology include a proportionate buyer-readiness record for critical services. It should cover:

• the minimum business functionality that must continue, including acceptable interruption and data-loss tolerances;
• the important dependencies inside and outside the assessed provider;
• the identified alternative, including required capacity, support and operational skills;
• what has actually been tested, when it was tested, and any residual risks or limitations requiring explicit acceptance.

This should reuse existing architecture, resilience and risk-management evidence wherever possible rather than creating a parallel governance process.

The provider should not be expected to guarantee that an individual customer's environment is ready to move. The provider-side requirement should instead demonstrate that exit or substitution is technically possible and supported. The customer then remains responsible for determining whether its own complete service is capable of exercising that option.

This also supports the judgement already present in Article 29(9) around multi-vendor and multi-cloud strategies.

More providers do not automatically create more resilience. Two apparently independent alternatives may still depend on the same identity system, software component, operational service or supply chain. Additional platforms can also create additional engineering and operational complexity.

The desired outcome should therefore be a credible and maintained alternative for the relevant business scenario, not a prescribed number of vendors.

2. Make required transitions achievable without weakening the obligation

Relevant provisions: Articles 29(6) and 30(4).

Article 29(6) requires a migration triggered by the risk assessment to take place within a reasonable transition period not exceeding twelve months. It appropriately recognises technical feasibility, service continuity and portability.

I support retaining a clear timetable.

Without one, there is a risk that identified dependencies are repeatedly accepted without meaningful action. A transition plan with no deadline can easily become a permanent plan.

However, there will be cases where the controls surrounding a critical service make the transition substantially more complex than moving the technology itself.

One example is a service operating within an existing certified or formally assured boundary. Changing a significant component can trigger reassessment or recertification of the wider service. In such a case, the technical migration may be achievable within the required period while the assurance process surrounding it becomes the critical path.

This is important because forcing a transition before the receiving environment and its controls are ready can increase the service-continuity risk that the legislation is intended to reduce.

The answer should not be to remove the twelve-month maximum.

Instead, I recommend a narrowly defined, evidence-based extension mechanism for exceptional cases where completing the transition within the maximum period would create a demonstrably greater continuity or assurance risk.

An extension should require:

• a decision by the responsible authority;
• evidence explaining why the normal period cannot safely be met;
• appropriate independent challenge;
• interim controls for the dependency that remains;
• funded transition milestones;
• a fixed expiry and review date.

Administrative convenience, lack of prioritisation or a preference for the incumbent should not justify an extension.

The framework should also clarify when the transition period begins and how Article 29(6) interacts with the exceptional procurement circumstances in Article 30(4). The published text of Article 30(4) also appears to contain a lettering error in its three grounds, which are labelled (a), (b) and (a), and would benefit from correction.

A related implementation issue is the treatment of reassessment or recertification required specifically because an organisation is replacing a technology dependency in response to a sovereignty assessment.

Where possible, the implementation framework should provide an expedited change path for sovereignty-motivated substitutions inside already-assured environments. Otherwise an organisation may be required by one part of the framework to replace a dependency while another assurance process makes completing that replacement within the required period impractical.

This is not an argument for lower assurance.

It is an argument for making the different assurance and transition mechanisms work together.

3. Reduce the cost of transition by funding readiness, not just migration

Relevant provisions: Articles 3 to 9, Article 5, Article 31(2), and Impact Assessment Annex 12.

The Commission's impact assessment recognises that migration costs vary substantially and that much of the cost comes from human effort rather than from the price of the destination infrastructure itself.

That reflects an important practical distinction.

The cutover is not necessarily the migration programme.

For complex services, much of the work happens before anything moves. The target environment must exist. Network connectivity, identity, security controls, logging, monitoring, data paths, operational processes and support arrangements must be established and tested before a production service can safely use it.

Once that target exists, the actual movement of a workload can be comparatively straightforward.

This is why European capability and enterprise usability need to be considered together. A European service can exist in the market and still require significant engineering work before an established organisation can consume it as an alternative to its current platform.

The Commission's own evidence also illustrates the difficulty of generalising migration estimates. Annex 12 notes that its quantified model covers movement of an application deployed on a virtual machine from IaaS to IaaS, rather than PaaS-to-PaaS or SaaS-to-SaaS transitions. Elsewhere the impact assessment includes an illustrative PaaS migration case. These are different classes of transition and can involve very different dependencies.

Replacing a managed database, integrated application platform or business SaaS service may require changes to data models, interfaces, permissions, operational tooling and user processes that are not represented by moving a virtual machine.

I therefore recommend that adoption support under CADA place significant emphasis on target-environment readiness and reusable transition capability.

The proposed Experience and Acceleration Centres for AI and other capacity-building mechanisms could help develop and publish:

• standardised landing-zone and target-environment patterns;
• reference architectures for common transition scenarios;
• interoperability and conformance tests;
• reusable approaches to identity, connectivity, security and observability;
• practical evidence showing which dependencies remain after a service has been moved.

This has a multiplier effect.

Funding one migration helps one organisation. Reducing the engineering effort required to make an alternative usable can help every organisation attempting the same class of transition.

Targeted buyer-provider pilots may still be useful, particularly where there is little evidence for managed platforms, SaaS or AI transitions. However, their primary purpose should be to produce reusable implementation evidence rather than simply demonstrate that a European service can host a workload.

Economic comparisons should similarly compare equivalent business outcomes over the same period. In particular, they should distinguish three broad costs:

• Engineering and assurance: work required to establish the alternative.
• Transition: temporary duplication and transition costs while both environments operate.
• Ongoing operation: continuing operational cost of maintaining the new environment and any required contingency.

Ordinary renewal and modernisation costs should be separated from costs directly caused or accelerated by a sovereignty intervention.

AI illustrates why technical compatibility is not enough

AI provides a useful example of this wider issue.

Common APIs and model gateways can make provider substitution appear technically simple. At the routing layer, changing provider can sometimes be little more than a configuration change.

That does not mean the underlying capability is interchangeable.

Models can differ materially in task quality, safety behaviour, latency, context handling, tool use, structured outputs, data-processing arrangements and operating cost. Applications built around one model may therefore require evaluation and adjustment before another can safely replace it.

For AI services, credible substitutability should therefore be demonstrated at the level of the business task rather than inferred from API compatibility.

This is also an area where CADA's treatment of cloud and AI should remain coherent. The assurance framework is principally expressed in terms of cloud computing services, while other provisions of the proposed Act explicitly address both cloud computing services and AI systems.

As implementation develops, the Article 29 assessment methodology and Article 31(2) guidance should make clear how material AI-service dependencies consumed through cloud services are to be considered.

Operational sovereignty has an operational cost

Relevant provisions: Annex II Levels 2 to 4.

The requirements around where technical and operational support is performed and which personnel can operate higher-assurance services have practical consequences that should be recognised in implementation and proportionality assessments.

A global technology service can normally distribute operational coverage across regions and time zones. Restricting support and privileged operational activity to a European perimeter can remove that operating model.

This does not make the requirement wrong.

It does mean that higher sovereignty can require specialist expertise to be duplicated within the Union rather than shared across an existing global support organisation. Twenty-four-hour operational coverage, escalation engineering, security response and specialist platform knowledge all have to be considered.

The cost is therefore not simply the cost of hosting infrastructure in Europe. It includes the people and operating model required to sustain that infrastructure to the expected service level.

There also appears to be terminology within Annex II that would benefit from clarification, including references to Union citizens in one personnel requirement and Union residents in another. For organisations designing operating models against these requirements, ambiguity is likely to be interpreted conservatively and therefore increases implementation cost.

Clear definitions of the operational perimeter and personnel requirements would improve both compliance and cost estimation.

Enterprise adoption and interoperability

Article 31 provides a route for assessments and guidance for private-sector entities in sectors of high criticality, with mandatory measures possible through delegated acts. The initial assessment provision should not be interpreted as a general migration obligation for all European enterprises.

For private-sector adoption, guidance should help organisations incorporate dependency decisions into existing procurement, architecture, financial planning, resilience and service-risk processes rather than creating an additional standalone governance structure.

Interoperability also deserves continued attention.

Article 29(9) asks buyers to consider whether multi-vendor or multi-cloud strategies are appropriate. That objective becomes difficult if each sovereign platform behaves operationally as an entirely separate technology environment.

This is not only a buyer problem.

European software companies deciding which platforms to support face duplicated engineering, testing, certification and operational effort for every incompatible environment. Smaller vendors are least able to absorb that cost. Fragmentation can therefore reduce the software and services available on European platforms and indirectly make those platforms less attractive to buyers.

CADA already helps reduce one form of fragmentation through common assurance. Open standards, portability and practical interoperability should similarly be encouraged so that growth in European sovereign capability produces an ecosystem rather than a collection of isolated alternatives.

Conclusion

European technological autonomy will not be established simply because alternatives exist or because a provider satisfies an assurance level.

It becomes operational when organisations can demonstrate that critical services can continue or transition when an important dependency becomes unavailable or unacceptable, within understood business tolerances.

CADA has many of the components needed to support that outcome. Applying its operational continuity tests consistently, connecting provider assurance to buyer readiness, making difficult transitions achievable, and reducing the engineering cost of adopting alternatives would help turn European technology sovereignty from a characteristic of providers into a capability that European organisations can actually exercise.

Technical clarification points

The following points identified while reviewing the proposed text may benefit from clarification during the legislative process:

1. Annex III criterion I. It includes migration and switchover evidence for Levels 2, 3 and 4, while the corresponding Level 4 criterion in Annex II does not appear to contain the migration requirement present at Levels 2 and 3.
2. Annex II 3.1(g). It appears to refer to an implementing act under Article 19 in relation to the Level 3 third-country derogation. Clarification may be useful as to whether Article 18 is intended.
3. Personnel terminology. Annex II uses both Union citizenship and Union residency requirements for personnel within related operational criteria. The intended populations and requirements should be made explicit.
4. Article 30(4). The three exceptional grounds are labelled (a), (b) and (a).
5. Reassessment frequency. Article 29(1) requires reassessment every two years or whenever necessary. The Impact Assessment appears to use a four-year reassessment cycle in part of its costing. The implementation cost assumptions should be checked against the frequency in the proposed Regulation.

References

1. European Commission, COM(2026) 502 final. Proposal for a Regulation on the development of cloud and AI in the Union (Cloud and AI Development Act), particularly Articles 5, 16, 21 and 29 to 31, and Annexes II and III.
2. European Commission, SWD(2026) 502 final. Impact Assessment accompanying the proposal for the Cloud and AI Development Act, Parts 1 and 2, including Annex 12 on porting and migration costs.
3. Department of Enterprise, Tourism and Employment. Public Consultation on the proposed Cloud and AI Development Act, explanatory note and consultation questions, 2026. The Regulatory Scrutiny Board opinion is also available in the Council document archive.