Scope: This dossier examines how distributed artificial intelligence can improve resilience, industrial capability and access while preserving service quality, cybersecurity and information integrity worldwide, with separate European Union, Italian, French, German and United Kingdom assessments and an outlook to November 2031.

Executive Summary / BLUF

The strongest architectural direction is selective distribution under verifiable governance: execute tasks where operational requirements justify them, while maintaining enforceable controls over identity, model changes, data access and consequential actions.

Distribution improves resilience only when alternative execution sites can operate through failures of shared orchestration, identity, communications and update services.

Official security guidance establishes that federated learning remains exposed to malicious updates and privacy leakage; distributing computation does not establish the trustworthiness of its participants.

Global service quality must cover operational availability, task accuracy, security, privacy and recoverability; aggregate uptime alone cannot establish acceptable performance.

The IEA’s April 2026 outlook projects global data-centre electricity consumption rising from 485 TWh in 2025 to 950 TWh in 2030; these figures cover all data centres, rather than AI alone. IEA

Europe’s amended AI Act timetable places relevant Annex III high-risk requirements on 2 December 2027, and relevant product-related high-risk requirements on 2 August 2028. eur-lex.europa.eu

The immediate decision is to require measured continuity, bounded agent permissions and independently reviewable evidence before expanding distributed deployment.

The decisive uncertainty is whether these safeguards retain acceptable quality and cost under heterogeneous hardware, compromised participants and interrupted connectivity.

Equity Tokenisation and Financial-Market Security: Systemic Risks, Issuer Control and AI-Enabled Cyber Threats

Distributed AI’s Real Bottleneck Is Institutional Control

Europe should buy the capacity to control AI services before committing itself to the scale of their deployment. Distributed computing can widen access and reduce selected dependencies, but it can also disperse execution while leaving authority, evaluation and integration concentrated in a few suppliers. The European Commission’s Apply AI Strategy encourages adoption across industry and public administration; the harder procurement decision is whether receiving organisations can supervise the resulting applications, replace their providers and preserve essential functions when automated support fails. Infrastructure spending will produce durable industrial value only if contracts, skills and operating procedures develop alongside computational capacity. Otherwise, public money will finance access to systems whose behaviour and continued availability remain governed elsewhere, transferring dependency rather than reducing it.

The adoption gap makes infrastructure an incomplete answer

The OECD’s November 2026 assessment puts AI adoption in 2025 at 20% of enterprises with at least 10 employees, against 52% of large enterprises with at least 250 employees. The difference is 32 percentage points; the large-enterprise rate is 2.6 times that of the broader covered population. These figures measure adoption, not productivity or successful integration. Their significance is that organisations already possessing capital, expertise and operating capacity are better positioned to use the technology. Distributing access without strengthening those complementary capabilities can preserve the advantage of established adopters.

EuroHPC’s Fast Lane access offers eligible projects up to 50,000 GPU hours for a maximum of three months, with approval described as occurring within four working days. Playground access can be granted within two working days after the relevant assessment. These arrangements lower the cost of experimentation; they do not establish that an application will survive outside the supported environment. Italy’s IT4LIA procurement makes the distinction financially material: the April 2026 announcement records a €290 million budget for acquisition, delivery, installation and maintenance, with half financed by EuroHPC. That commitment purchases infrastructure and associated services. Its industrial return depends on what receiving organisations can subsequently operate.

The OECD’s research across 15 member countries identifies human and technological capital as important enablers of adoption and attributes part of adopters’ observed productivity advantage to those underlying differences. Infrastructure policy therefore needs an explicit transmission mechanism: compute access must lead to a reproducible application, an identified operating owner and evidence of sustained benefit. Without that progression, programme managers can report allocations and completed pilots while firms remain unable to maintain the service.

Distribution can move the bottleneck without removing it

ETSI’s Multi-access Edge Computing reference architecture combines dispersed hosts with system-level management and orchestration. Its implication for institutional power is direct: spreading execution across locations does not necessarily spread control over admission, placement or updates. A customer can acquire more places to run an application while remaining dependent on one organisation to make the application work.

NVIDIA’s Dynamo documentation exposes a further constraint through the transfer of live inference state between prompt-processing and generation engines. The ability to start work on another machine is different from the ability to continue an interaction with its required context and permissions. Procurement that tests only the availability of alternative hardware can consequently overstate continuity. The buyer needs evidence that the relevant service, including its state and dependencies, can move.

The Competition and Markets Authority’s October 2026 cloud update identifies continuing barriers to switching and multi-cloud use, including identity integration and container portability. Those findings explain why an export clause is an inadequate substitute for an exercised alternative. Migration requires the receiving environment to reproduce acceptable operation, not merely accept transferred files. Unless that capability is demonstrated before dependence grows, a nominally distributed architecture can strengthen the bargaining position of the integrator controlling its connections.

Public contracts must purchase evidence and an exit

The European Commission’s Public Buyers Community provides AI model contractual clauses, but its accompanying commentary states that they are not a complete agreement and do not supply all terms on acceptance, payment, delivery, applicable law or liability. Their adoption cannot discharge the buyer’s responsibility to define what it is purchasing. The commercially decisive annex is the one connecting a concrete application to acceptance evidence, operating limits and remedies when the supplied configuration changes.

NIST’s AI Risk Management Framework supports governing, measuring and managing risk in the intended context. Applied to procurement, that means fixing the baseline and acceptance conditions before the supplier’s demonstration. An application should proceed because it improves an identified process under declared conditions, with supervision and rework included. Acceptance for internal drafting should not silently authorise autonomous public-facing decisions.

The EU Data Act removes switching charges for the switching process from January 2027, while separately permitting cost-based egress charges for continuing parallel use. This distinction limits claims that legislation will make distributed operation frictionless. Even where the provider cannot charge for the mandated switching process, the customer still faces its own engineering, revalidation and transition costs. Contracts should preserve the information and assistance needed to exercise an alternative before renewal makes the existing arrangement harder to unwind.

Security regulation cannot compensate for missing operational authority

NIST’s adversarial-machine-learning taxonomy documents how malicious contributions can alter a federated model, including through targeted behaviour that does not necessarily destroy average performance. The institutional consequence is that admission to a network, acceptance of a contribution and release of a model require separate decisions. A valid credential establishes neither the safety of an update nor the suitability of its downstream use.

The National Cyber Security Centre’s analysis of adversarial attacks identifies manipulation through retrieved information, tool responses and other agents. Once a model can initiate actions, the damage depends on the authority attached to its output. An agent reading an external document should not inherit permission to send messages, change infrastructure or release information because the document instructs it to do so. Those permissions must remain enforceable outside the model.

The EU AI Act assigns obligations to different models, systems and actors; Article 25 can change an integrator’s position when it makes specified modifications or changes a system’s intended purpose. An institution therefore cannot assume that assurances covering the original product settle the status of its altered deployment. Legal classification and operational approval must follow the application actually used, including the actions it can initiate.

European coordination must make competence transferable

Italy’s Legislative Decree No. 179 of October 2026 specifies national and sectoral authority arrangements, while Germany’s KI-MIG gives the Bundesnetzagentur a general surveillance role subject to statutory exceptions. These frameworks provide routes for accountability, but the receiving institution still needs the records and competence to answer the relevant authority. A supplier-operated dashboard is insufficient if the customer cannot explain its own processing purposes, changes and consequential actions.

France’s published governance description remains expressly conditional on parliamentary acceptance of the proposed allocation. That qualification matters because a proposed institutional map cannot be treated as an enacted allocation. It also illustrates why reusable technical evidence is valuable: an accurate inventory of configurations, purposes and responsible organisations can support scrutiny without depending on a premature assumption about one supervisory route.

The United Kingdom’s Algorithmic Transparency Recording Standard offers a separate implementation precedent: scoped publication of public-sector algorithmic use, with defined organisational coverage and treatment of sensitive information. Its practical value depends on maintaining a record that corresponds to operation. Across these national arrangements, coordination should make evidence and expertise easier to reuse, while preserving the legal competence of each authority.

The Commission’s July 2026 Action Plan on Cybersecurity and Artificial Intelligence announces stronger evaluation capacity and secure testing arrangements. These could reduce duplicated effort and help smaller institutions obtain specialist scrutiny. Their effectiveness must be judged through completed assessments, coverage and corrections. A shared evaluator becomes another strategic dependency if its methods cannot be examined or its queues prevent timely decisions.

The next two years will expose who bought capability

Over the next 12–24 months, the Apply AI Strategy will be judged through the transition from supported experimentation to maintained services. Procurement authorities should approve bounded applications, reserve the right to examine material changes and require representative substitution exercises before major expansion. Funding bodies should connect computational access to the transfer of operating competence. Governing institutions should retain an explicit decision to restrict or terminate an application when its evidence no longer supports reliance.

The cost of inaction will fall unevenly. Under EuroHPC-supported access, smaller firms risk reaching the end of assistance with a technically successful demonstration they cannot maintain. Public administrations risk paying for integration and repeated remediation without retaining the expertise needed to challenge the supplier. Taxpayers carry the opportunity cost when infrastructure commitments are counted as delivery before their institutional benefit is established.

The architecture described by ETSI and the switching barriers identified by the Competition and Markets Authority point to the same procurement test: can the receiving organisation continue to perform its function when one component, supplier or support arrangement changes? Distributed AI serves institutional autonomy when the answer is demonstrated. Where that answer remains unknown, expansion increases the commitment before it establishes control.

European Cold-Chain Cyber Intrusions: Industrial Control Vulnerabilities – Operational Sabotage and Systemic Infrastructure Risk

---

Navigational Index

Pillar I — Distributed Intelligence and the Physical Foundations of Service

• Chapter 1 — The Architecture of Distributed AI: Centralised training, federated learning, local inference and shared computational capacity.
• Chapter 2 — Service Quality Across Heterogeneous Networks: Performance, continuity, measurement and operational availability.
• Chapter 3 — Industrial Economics and Infrastructure Constraints: Accelerators, communications, electricity, incentives and switching costs.

Pillar II — Security, Authenticity and Accountable Control

• Chapter 4 — Cybersecurity Across the Distributed Lifecycle: Identity, supply chains, poisoning, privacy leakage and recovery.
• Chapter 5 — Agentic Systems and the Integrity of Digital Evidence: Delegated authority, synthetic media, provenance and manipulation.
• Chapter 6 — Legal Authority and European Implementation: EU obligations and separate Italian, French, German and United Kingdom implications.

Pillar III — Strategic Pathways and Institutional Decisions

• Chapter 7 — Immediate Impacts and the Outlook to 2031: Adoption pathways, systemic dependencies and observable indicators.
• Chapter 8 — Courses of Action and Final Net Assessment: Procurement, assurance, interoperability, operational thresholds and institutional responsibility.

---

Master Abstract

Distribution must follow the task and its failure consequences

AI should become more distributed where local execution improves continuity, limits unnecessary data movement or satisfies operational latency requirements. This does not establish a universal case for replacing concentrated computing infrastructure. Several distinct arrangements require separate assessment: distributing a training workload across accelerators; training collaboratively while retaining source datasets at participating institutions; running inference near the user; and allocating separable tasks to intermittently available equipment. These arrangements have different communications requirements and trust boundaries. NVIDIA’s NeMo documentation, for example, recommends confining tensor parallelism to high-bandwidth intra-node networks because of its communications overhead. That documented constraint supports a narrower conclusion than the proposition that geographically dispersed spare GPUs can substitute directly for a tightly connected training cluster. Their suitability depends on the workload, synchronisation requirements and cost of validating returned work. Performance Tuning Guide — NVIDIA, NeMo Framework User Guide 25.11 — versioned documentation. NVIDIA NeMo Framework User Guide

The central governance distinction concerns the distribution of execution and the distribution of authority. ETSI’s edge-computing reference architecture combines multiple hosts with system-level management and an orchestrator that maintains an overview of the system. Distributed execution is therefore compatible with concentrated operational coordination. The analytical implication is that resilience depends on which functions remain shared: an organisation gains limited independence from remote infrastructure if local applications still require a continuously reachable central authorisation or orchestration service. Procurement should consequently test the loss of these dependencies individually, including whether a local service retains an authorised and sufficiently capable operating mode. Physical separation becomes a meaningful resilience measure when the service can survive the specific failure being mitigated. Multi-access Edge Computing (MEC); Framework and Reference Architecture, ETSI GS MEC 003 V4.1.1, sections 6–7 — ETSI — May 2025. etsi.org

Global service quality requires local evidence and common accountability

A defensible global service framework should establish common definitions, evidence requirements and escalation procedures while allowing application-specific thresholds. A translation assistant, an industrial inspection system and an agent authorised to change infrastructure cannot share a single meaningful accuracy or response-time requirement. NIST’s AI Risk Management Framework treats validity, reliability, security, resilience and accountability as distinct characteristics and calls for measurement in the intended deployment context. On that basis, this assessment proposes measuring distributed AI through task success, response-time distributions, service interruptions, security events, recovery performance and the quality retained during degraded operation. Results should be disaggregated by relevant language, location, hardware class and user population. Otherwise, a satisfactory global average can conceal unacceptable performance in a smaller operational segment. These are proposed assurance requirements; the retrieved record does not establish a universally adopted global AI service-quality regime. Artificial Intelligence Risk Management Framework (AI RMF 1.0), sections 3 and 5 — NIST — Jan 2023. nvlpubs.nist.gov

Cybersecurity introduces an additional distinction between authentic participation and trustworthy contribution. NIST documents how compromised federated-learning clients can submit updates that degrade a global model or introduce targeted behaviour, including backdoors. The same publication identifies limitations in defensive aggregation and notes that some mitigations reduce accuracy without eliminating attacks. A participant’s valid credentials therefore cannot establish the substantive safety of its update. The institutional consequence is to separate admission to the network, acceptance of a contribution and authorisation to release a resulting model. These decisions require different evidence. An attacker able to influence training need not produce an obvious outage: a narrowly targeted alteration can preserve ordinary benchmark performance while changing a consequential subset of outputs. Distributed deployment must therefore assess integrity failures alongside availability failures. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, section 2.3.4 — NIST — Mar 2025. nvlpubs.nist.gov

Privacy protection and operational inspection create a design trade-off

Federated learning reduces the need to centralise original training records, but model updates can still reveal information about those records. NIST’s technical explanation distinguishes protection of updates during training from protection against information extracted from the released model. Its companion discussion explains how secure aggregation can conceal individual contributions from the aggregator. These protections address specific exposure pathways; they do not establish the correctness of the contributions being combined. The analytical tension is consequential: reducing an operator’s visibility into individual updates can constrain conventional inspection of suspicious contributions. A deployment must therefore specify its privacy guarantees, integrity checks, participant assumptions and incident procedures together, rather than claiming that keeping raw data locally resolves all four questions. Privacy Attacks in Federated Learning — NIST — Jan 2024; Protecting Model Updates in Privacy-Preserving Federated Learning — NIST — Mar 2024. NIST

The October 2026 release of NIST’s Privacy-Preserving Federated Learning Testbed provides a concrete instrument for examining part of this trade-off. The release supports comparisons between centralised and federated configurations, with or without differential privacy, and includes a curated genomic dataset. It demonstrates the availability of an evaluation environment, rather than certification that an arbitrary distributed system is secure or economically efficient. Its immediate institutional value lies in reproducible testing before deployment: organisations can examine how configuration changes affect model performance and privacy protection in a defined setting. Claims about broader operational readiness still require evidence from the proposed workload, participating infrastructure and threat environment. Privacy-Preserving Federated Learning (PPFL) Testbed and Curated Dataset — NIST National Cybersecurity Center of Excellence — Oct 2026. NCCoE

Agentic AI changes the consequences of manipulation

As AI systems acquire permission to call tools, retrieve confidential records and initiate actions, the main security question extends beyond the quality of generated text. The UK NCSC warns that prompt injection requires architectural safeguards and specifically emphasises deterministic controls constraining what an LLM-connected system can do. The immediate implication for distributed agents is that permissions must remain enforceable outside the model. An agent processing an untrusted document should not acquire authority merely because that document contains persuasive instructions. Delegated permissions should be limited to the task, with separate authorisation for consequential actions and a recorded relationship between the request, the model version, the tool call and the approving authority. This recommendation follows the documented mechanism: manipulation becomes operational harm when model output can exercise excessive privileges. Prompt injection is not SQL injection (it may be worse) — National Cyber Security Centre — Dec 2025. National Cyber Security Centre

Synthetic audiovisual systems create a parallel requirement for preserving evidence. Translation, voice replacement, editing and personalised presentation should remain distinguishable from the original record through retained originals and documented transformations. C2PA’s own explanation states that provenance can inform an assessment of origin and modification but cannot establish whether content is factually true; it also acknowledges that provenance metadata can be removed. Accordingly, a signed media history supports a narrower claim than factual authenticity. For public authorities, journalism and investigations, the proposed control is to preserve the original asset, the transformation history and the contextual evidence supporting any factual assertion. A personalised rendering should not silently become the authoritative record of what a speaker originally said. C2PA and Content Credentials Explainer, sections 7.2.1–7.2.3 — Coalition for Content Provenance and Authenticity — version 2.2, undated. spec.c2pa.org

Industrial benefits depend on the full cost of assured computation

Distributed AI can create opportunities in local inference, privacy-preserving collaboration, orchestration and verification. Its economic merit should nevertheless be assessed through the cost of an accepted result, including communications, failed tasks, validation, security operations and energy. The IEA’s April 2026 outlook projects total data-centre electricity demand increasing from 485 TWh in 2025 to 950 TWh in 2030 and identifies constraints across electricity infrastructure and advanced chip supply chains. These are projections for the broader data-centre sector. They support treating electricity and infrastructure as material constraints, while providing no basis for assuming that transferring workloads to dispersed devices automatically lowers total energy use. Such a claim requires comparable measurements of completed workloads and their associated overheads. Key Questions on Energy and AI, Executive summary — International Energy Agency — Apr 2026. IEA

Related inventions should be evaluated according to their documented development stage. The USPTO explains that a patent confers a right to exclude others from specified uses; it does not itself grant a right to practise the invention. A patent record therefore cannot establish commercial deployment, user participation or operational performance. For distributed-compute markets, the decision-relevant evidence would include implementation documentation, independently reproducible performance, explicit resource-owner participation, workload isolation and auditable remuneration. Where rewards depend on completed computational work, payment should follow validated contribution under disclosed rules. Additional collection of behavioural or bodily information requires a separate justification; it does not establish the quality of computation. Managing a patent, “Nature of rights” — United States Patent and Trademark Office — undated, accessed Nov 2026. USPTO

European implementation requires distinct national decisions

European Union. The operative timetable must reflect Regulation (EU) 2026/1744, rather than the original AI Act schedule alone. Its amendments set 2 December 2027 for the relevant requirements governing Annex III high-risk systems and 2 August 2028 for the corresponding product-related category. Separately, the Commission’s service desk identifies transparency obligations applying from 2 August 2026, with a transitional deadline of 2 December 2026 for Article 50(2) compliance by providers of qualifying systems already placed on the market before August. The analytical consequence is that implementation planning must distinguish obligation, system category and transition provision. Distributed architecture cannot serve as a substitute for identifying the responsible provider and deployer. Regulation (EU) 2026/1744, Article 1, amendments to Articles 111 and 113 — European Parliament and Council — Jul 2026; When does enforcement start? — European Commission, AI Act Service Desk — undated, accessed Nov 2026. eur-lex.europa.eu

Italy. The Chamber of Deputies records AgID’s definitive adoption of public-administration AI adoption guidelines through Determination No. 169 of 9 November 2026. Its account identifies governance, risk classification, data quality, cybersecurity, transparency and staff competence as central elements, while distinguishing the separate development and procurement guidelines whose adoption remained in progress. The immediate Italian implication is to connect distributed-AI pilots to accountable administrative ownership and measurable service outcomes. A public administration should be able to identify which institution accepts a model change, which operator maintains continuity and which authority can suspend a malfunctioning service. Adopting an architecture should follow demonstrated administrative capacity to operate and supervise it. Intelligenza Artificiale, section “Agenzia per l’Italia digitale” — Camera dei deputati — Nov 2026. temi.camera.it

France. ANSSI’s generative-AI security recommendations provide a concrete continuity benchmark: recommendation R15 calls for a degraded business-service mode without AI, while other recommendations address trusted hosting, separation of environments and controls over automated actions. This supports a French implementation approach centred on demonstrable operational control. Local or nationally hosted AI should be evaluated for its ability to maintain the required service when its normal model, hosting environment or management infrastructure becomes unavailable. The important distinction is between preserving the AI component and preserving the underlying public or industrial function. A workable non-AI procedure can provide greater assurance for a critical process than an untested alternative model. Recommandations de sécurité pour un système d’IA générative, recommendations R9, R12–R15 — ANSSI — Apr 2024. messervices.cyber.gouv.fr

Germany. BSI’s Generative KI-Modelle addresses risks affecting industry and public authorities, including indirect prompt injection through external sources and applications. The German implementation implication is to evaluate the complete application chain: a locally hosted model can still process malicious material or produce output consumed by a privileged downstream system. For industrial adoption, the proposed assurance boundary should therefore include retrieved documents, model configuration, interfaces and the systems authorised to act on the result. Local ownership of hardware improves control over some dependencies, but its operational value depends on secure integration and maintenance. Generative KI-Modelle: Chancen und Risiken für Industrie und Behörden, risk R28 — Bundesamt für Sicherheit in der Informationstechnik — Jan 2025. bsi.bund.de

United Kingdom. NCSC’s secure-development guidelines organise assurance across design, development, deployment, and operation and maintenance. This provides a lifecycle basis for evaluating distributed deployments rather than relying on a one-time model assessment. The proposed UK priority is to make supplier evidence usable throughout that lifecycle: documented dependencies, security-relevant changes, monitoring responsibilities and incident procedures should accompany the service. Cross-border interoperability should preserve this evidence when workloads move between providers. The coordination opportunity with European partners lies in compatible assurance records and test procedures, while each jurisdiction retains its own legal responsibilities. Guidelines for secure AI system development — National Cyber Security Centre — Nov 2023. National Cyber Security Centre

Key Evidence Table

Indicator	Value/status	Reference date	Definition/scope	Issuer	Exact source
Global data-centre electricity demand	485 TWh in 2025; projected 950 TWh in 2030	Apr 2026 outlook	All data centres; forecast distinguished from historical estimate	IEA	Key Questions on Energy and AI — Executive summary. IEA
Federated-learning evaluation infrastructure	Open-source PPFL testbed released	29 Oct 2026	Evaluation resource; does not certify production systems	NIST NCCoE	Privacy-Preserving Federated Learning Testbed and Curated Dataset. NCCoE
Agentic attack taxonomy	Initial public draft	9 Nov 2026	Draft SP 2400-102e2026; distinct from final guidance	NIST	Adversarial Machine Learning Taxonomy and Terminology. CSRC
Relevant Annex III high-risk requirements	Application from 2 Dec 2027	Jul 2026 amendment	Chapter III, sections 1–3, subject to the specified exception	European Parliament and Council	Regulation (EU) 2026/1744. eur-lex.europa.eu
Relevant product-related high-risk requirements	Application from 2 Aug 2028	Jul 2026 amendment	Systems classified under Article 6(1) and Annex I	European Parliament and Council	Regulation (EU) 2026/1744. eur-lex.europa.eu
Italian public-administration adoption guidelines	Definitively adopted	9 Nov 2026	Determination No. 169; separate procurement/development processes distinguished	AgID, recorded by Camera dei deputati	Intelligenza Artificiale. temi.camera.it
Continuity without AI	Explicit recommendation R15	Apr 2024	Degraded business-service operation following AI failure	ANSSI	Recommandations de sécurité pour un système d’IA générative. messervices.cyber.gouv.fr

Architecture of accountable distribution

The following component presents a proposed relationship between execution, assurance and authority. It synthesises documented edge-management, zero-trust and data-integrity principles; it does not represent a certified architecture. NIST’s zero-trust publication rejects implicit trust based solely on network location or asset ownership, while the joint AI data-security guidance recommends provenance, integrity verification and trusted infrastructure. Zero Trust Architecture — NIST — Aug 2020; AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems — NSA, CISA, FBI and international partners — May 2025. NIST

Competing Pathways

Managed hybrid distribution is the leading architectural assessment. It combines local execution for selected tasks with shared infrastructure where coordination or computational requirements justify it. Its advantage depends on demonstrating that operational gains exceed the additional costs of management and assurance. Evidence that would strengthen this assessment includes successful disconnection exercises, acceptable task performance across hardware classes and independently reviewable recovery records.

Concentrated infrastructure remains defensible for demanding workloads. Where communications overhead and model requirements favour tightly integrated resources, concentration can remain operationally preferable. The countervailing risk is shared dependency. This pathway should therefore be assessed through demonstrated service continuity and credible substitution arrangements, rather than a general claim that concentrated infrastructure is either inherently efficient or inherently fragile.

Open participation in computational networks remains conditional. Broadly admitting resource owners creates additional questions about participant identity, returned-work integrity, confidentiality and incentives. This pathway would become more credible for consequential workloads if public evidence established reproducible validation, reliable exclusion of malicious participants and competitive total costs under realistic failure conditions.

These pathways can coexist within one organisation. The principal selection criterion should be the requirements and failure consequences of each workload.

Principal Gaps and Watch Indicators

Consequential gap	Record or observation needed	Proposed decision threshold	Implication
Independence from common infrastructure	Witnessed loss-of-dependency tests covering identity, orchestration, networking and updates	Critical functions meet their approved recovery and degraded-service requirements	Establishes whether distribution provides actual continuity
Integrity of distributed contributions	Workload-specific adversarial evaluation and release records	Contributions and releases meet documented acceptance criteria; unresolved integrity failures block promotion	Limits propagation of malicious or defective changes
Quality across users and locations	Disaggregated task evaluations by relevant language, region and hardware class	Each deployment segment meets its approved minimum	Prevents global averages from concealing local failure
Privacy and inspection compatibility	Documented privacy model, aggregation assumptions and integrity-testing method	Privacy claims and attack-detection claims are demonstrated together	Reveals whether safeguards undermine one another
Agent authority	Permission inventories, tool-call records and adversarial integration tests	Consequential actions remain constrained by controls outside the model	Contains harm after manipulation
Authenticity of transformed media	Original assets, transformation histories and verification records	Authoritative use requires recoverable originals and disclosed material transformations	Preserves evidentiary traceability
Economic and energy advantage	Comparable measurements per successfully validated task	Savings persist after communications, validation, recovery and security overheads	Distinguishes useful distribution from transferred costs

For the immediate period, deployment decisions should turn on these observable controls. Across the horizon to November 2031, the principal signpost is whether distributed systems can preserve accountable service under adverse conditions at an acceptable total cost. Wider participation becomes strategically valuable when it expands dependable capability without allowing failures or manipulation to propagate beyond defined boundaries.

---

Pillar I — Distributed Intelligence and the Physical Foundations of Service

Assessment date: 15 November 2026. This pillar examines the engineering, service and industrial conditions under which distributed AI can deliver dependable capability, distinguishing documented specifications, announced investments and explicitly identified analytical calculations.

Chapter 1 — The Architecture of Distributed AI

The appropriate unit of distribution is the workload

The architecture of distributed AI should be selected according to the information that must move, the frequency with which participating machines must coordinate and the consequences of delayed or incorrect work. An organisation can distribute access to a service while retaining its computation in one facility; it can distribute computation across many machines while retaining one administrative authority; or it can distribute data ownership while coordinating the development of a common model. These arrangements answer different institutional needs. The first architectural decision should therefore identify whether the objective is to expand training capacity, collaborate across datasets, reduce inference latency, preserve operation during disconnection or purchase additional computational work. A design that addresses one objective should not receive credit for satisfying the others without supporting evidence. For procurement and infrastructure planning, this requires a workload description that identifies the model, input characteristics, output requirements, participating organisations and required operating conditions before specifying a preferred topology. The resulting architecture should make explicit which functions remain shared, which functions can operate independently and what information crosses each boundary. This is an analytical selection rule grounded in the distinct resource and placement constraints recognised by the Multi-access Edge Computing (MEC); Framework and Reference Architecture, sections 7.1.4 and Annex A.1 — ETSI — May 2025. etsi.org

Training distribution creates several different communications problems

Within a managed training cluster, distributing a workload can mean assigning different training examples to model replicas, dividing the model’s operations across accelerators, placing successive groups of layers on different machines or distributing the specialised components of a mixture-of-experts model. The communications consequences differ substantially. NVIDIA’s versioned NeMo 25.11 documentation describes data, tensor, pipeline and expert parallelism and recommends keeping communication-intensive arrangements within suitable high-bandwidth domains. That record is useful as documented engineering guidance, although the page is now marked as archived and should not be treated as the latest implementation specification. Its enduring architectural implication is that an accelerator contributes useful capacity only when its memory, execution speed and interconnect suit the assigned role. Adding a machine to a synchronised workload can create additional waiting, redistribution and coordination requirements. Consequently, a public institution assessing a distributed-training proposal should require scaling measurements for its actual configuration, including time spent communicating and waiting, rather than accepting an aggregate count of accelerators as a sufficient measure of usable capacity. Performance Tuning Guide, “Parallel mapping strategies” — NVIDIA NeMo Framework 25.11 — archived versioned documentation. NVIDIA NeMo Framework User Guide

Arrangement	What is distributed	Main coordination requirement	Appropriate acceptance evidence
Data-parallel training	Training examples across model replicas	Combining training information while maintaining a consistent model state	Time per training step, scaling efficiency and convergence under the declared configuration
Tensor-parallel execution	Operations within model layers	Frequent exchange between participating accelerators	Measured interconnect behaviour and end-to-end task performance
Pipeline-parallel execution	Successive model stages	Transfer of intermediate results and balanced stage scheduling	Stage utilisation, waiting time and completed-work throughput
Federated learning	Training across separately held datasets	Coordinating contributions, evaluation and model promotion	Local and combined model quality, participation effects and privacy evaluation
Replicated inference	Complete model instances across locations	Request routing, version management and capacity allocation	Task quality, response-time distributions and tested failover
Shared computational tasks	Separable work across admitted resource providers	Task assignment, returned-work validation and settlement	Validated output, completion reliability and full delivery cost

The table provides an analytical comparison of acceptance requirements. Its training distinctions follow the versioned NVIDIA documentation above; its federated-learning distinctions follow the TechDispatch on Federated Learning, sections 3.2–3.4 — European Data Protection Supervisor and Agencia Española de Protección de Datos — Jun 2025. The proposed evidence requirements are not a claim that one universal certification procedure exists. edps.europa.eu

Model storage establishes a lower bound rather than a deployment specification

The memory required to store model parameters provides a transparent starting point for examining local execution, but it cannot establish the total memory required to run or train the model. Parameter storage can be calculated by multiplying the parameter count by the bits used per parameter and dividing by eight. Under an idealised uniform representation, eight billion parameters require 16 GB at 16 bits, 8 GB at eight bits and 4 GB at four bits; seventy billion parameters require 140 GB, 70 GB and 35 GB respectively. These are decimal gigabytes and calculated payloads, excluding quantisation metadata, runtime buffers, activations, session state and training-specific requirements. Actual storage can differ where parts of a model retain different numerical representations. NVIDIA documents quantisation as a method for reducing memory footprint and computational cost by lowering the precision of weights or activations; the practical consequence must still be evaluated against the intended task. A model becoming small enough to load on a device does not establish that it will meet the required accuracy, concurrency or response time. This distinction matters when proposals advertise the number of devices technically capable of holding a model without demonstrating the number capable of delivering an acceptable service. Quantization — NVIDIA TensorRT LLM — undated technical documentation, accessed Nov 2026. TensorRT LLM

Federated learning distributes the statistical problem as well as the computation

Federated learning introduces an additional architectural issue because participating datasets can differ in their structure, population and collection process. Horizontal federation concerns participants holding comparable types of information for different records, whereas vertical federation concerns different information associated with overlapping records. Cross-device arrangements also differ from collaboration among a smaller number of institutional data holders. The EDPS and AEPD technical dispatch distinguishes these configurations and identifies distributed data-quality management as an implementation challenge. The decision consequence is that joining more participants cannot be treated as a mechanically equivalent increase in useful training data. A federation needs compatible definitions of the task, a documented approach to sampling and transformation, and evaluation that reveals whether the combined model serves the relevant participating populations. This is particularly important when the fastest or most consistently connected participants contribute more often: a resource-selection policy can change which data influence the model. A proposed deployment should therefore report participation patterns together with local and combined performance, and should preserve the ability to determine whether an apparent improvement in overall results conceals deterioration at particular sites. TechDispatch on Federated Learning, sections 3.2, 3.4 and 5.2 — European Data Protection Supervisor and Agencia Española de Protección de Datos — Jun 2025. edps.europa.eu

The live session becomes an infrastructure dependency

Inference distribution becomes more demanding when the system must preserve the state of an ongoing interaction. NVIDIA’s TensorRT LLM documentation describes a key-value cache that retains previously calculated information for reuse during generation and supports reuse across requests. Separately, Dynamo documents an architecture in which prompt processing and subsequent token generation run on different engines, requiring transfer of that cache between them. These are documented implementation mechanisms, rather than proof that any geographical separation will improve service. Their significance is that inference placement concerns both the model and its live working state: moving an interaction can require transferring state or reconstructing information already calculated. A service that can restart elsewhere may still interrupt the user, repeat expensive processing or lose access to session-specific context. Accordingly, an architecture review should distinguish the ability to start a new request on another host from the ability to continue an existing request under the same quality and confidentiality constraints. It should also establish how long state persists, which execution environments can receive it and whether changing the model or runtime invalidates its reuse. KV Cache System — NVIDIA TensorRT LLM — undated technical documentation, accessed Nov 2026; Disaggregated Serving — NVIDIA Dynamo — undated technical documentation, accessed Nov 2026. GitHub

Key judgments

The defensible architecture is a combination of arrangements selected for different functions, with explicit boundaries between training, model distribution and live service delivery. The strongest immediate opportunities arise where a workload can be divided without excessive synchronisation or where local execution satisfies a defined operational requirement. More demanding claims require configuration-specific evidence: federated participation must improve the intended statistical task, quantisation must retain acceptable utility, and inference relocation must preserve the required interaction rather than merely restart computation elsewhere.

What would change the assessment

Reproducible evidence that a proposed configuration maintains task quality and competitive completion times across realistic participant interruptions would support broader distribution. Conversely, repeated dependence on a single state store, excessive reconstruction after relocation or performance gains confined to unusually favourable test conditions would narrow the set of workloads for which the architecture is justified.

Open official record

The consequential missing records for any particular deployment are its dependency map, training and inference configuration, distributed evaluation results, session-state handling specification and witnessed relocation tests. General product specifications cannot substitute for these records because they do not establish the behaviour of the integrated service.

Chapter 2 — Service Quality Across Heterogeneous Networks

Quality must be defined at the point where the institution uses the result

A distributed AI service should be assessed through the outcome it delivers to its institutional user, including the conditions under which that outcome remains acceptable. A response can arrive quickly while containing an incorrect answer, omit a necessary verification step or rely on information that the receiving organisation is not authorised to use. The service definition should therefore identify the completed task and its acceptance conditions before measuring speed or uptime. For an analytical assistant, completion might require a supported answer with usable citations; for an inspection application, it might require an adequately accurate classification delivered within the operational window; for a document-processing pipeline, it might require a validated record entered into the receiving system. This assessment proposes treating a successful service event as one that satisfies all applicable requirements, rather than recording independent indicators and assuming that strong performance in one compensates for failure in another. NIST’s AI Risk Management Framework supports context-specific measurement, documentation of uncertainty and continuing assessment after deployment. The resulting institutional standard should preserve separate measures of correctness, timeliness and recoverability while identifying when their combined failure makes a task unusable. Artificial Intelligence Risk Management Framework (AI RMF 1.0), “Measure” and “Manage” — NIST — Jan 2023. nvlpubs.nist.gov

Token speed and service completion answer different questions

For generative systems, the time before an initial response appears, the rate at which subsequent output arrives and the time required to complete the task should be measured separately. NVIDIA’s benchmarking documentation records request throughput and token throughput and, when streaming is enabled, time to first token and inter-token latency. These indicators describe different aspects of the serving process. The practical implication is that a comparison requires a declared distribution of input length, output length and concurrent demand, together with the model and runtime configuration. A system can provide an early token without completing the substantive task quickly, while a configuration optimised for aggregate throughput can create an unacceptable experience for an individual user. Benchmarks should also report cancelled requests and errors rather than allowing these to disappear from the denominator. For a distributed service, measurements should be repeated at the actual access points and under the intended connectivity conditions, because a server-side result excludes portions of the user’s delivery path. TensorRT LLM Benchmarking — NVIDIA — undated technical documentation, accessed Nov 2026. TensorRT LLM

Proposed contractual measure	Definition to fix before testing	Necessary reporting conditions	Institutional decision supported
Accepted-task rate	Share of submitted tasks satisfying the declared quality and completion rules	Task set, denominator, failure categories and evaluation procedure	Whether the service is usable
Time to first token	Elapsed time from the defined request boundary to the first delivered token	Client/server measurement point, prompt length and load	Whether interaction begins within the required window
Inter-token latency	Time between successive delivered output tokens	Distribution, interruptions and streaming configuration	Whether an ongoing response remains usable
End-to-end completion time	Time from submission to an accepted completed task	Retrieval, tools, verification and downstream integration	Whether the business process meets its deadline
Tail latency	A specified percentile of the measured latency distribution	Percentile, sample size, observation period and exclusions	Whether slower requests remain acceptable
Degraded-service quality	Performance while specified dependencies are unavailable	Functions retained, restrictions and test conditions	Whether continuity preserves a useful service
Recovery time	Time from the defined disruption to the approved restoration state	Detection, restoration, validation and accumulated backlog	Whether the interruption remains within tolerance
Segment performance	Results for relevant language, location, device and user categories	Coverage and uncertainty for each reported segment	Whether service quality is unevenly distributed

These are proposed contract fields, not universal numerical thresholds. The required values should follow the task, its consequences and the institution’s operating requirements.

The importance of measuring the complete workflow is becoming explicit in benchmark design. MLCommons’ August 2026 introduction of an end-to-end retrieval-augmented generation benchmark separates ingestion from question answering and reports documents per second for ingestion and tasks per second for answering. Its initial implementation uses an offline scenario, with server testing left for future rounds. That limitation is analytically important: a result obtained when all work is available at once cannot by itself establish performance under live arriving demand. The same distinction should govern institutional procurement. A retrieval-based application includes the preparation and indexing of documents, selection of evidence and generation of an answer, and an apparently efficient model can remain embedded in a slow or unreliable pipeline. The acceptance exercise should preserve the model-level measurements but add tests of the complete service, including the freshness of the underlying index and the behaviour of dependencies. This avoids confusing the performance of one engine with the capability of the application in which that engine is used. Introducing the MLPerf End-to-End RAG Inference Benchmark — MLCommons — Aug 2026. mlcommons.org

Availability percentages require an explicit service boundary

Availability claims become meaningful only after defining the service being observed, the observation period and the events counted as failure. A percentage attached to one component cannot automatically describe a chain of components on which the user depends. To illustrate the arithmetic, a service available for 99.9% of a continuous 365-day year has 525.6 minutes outside the availability condition; at 99.99%, the corresponding figure is 52.56 minutes. These calculated durations do not describe any provider’s contract and make no assumption about maintenance exclusions or compensation. A second illustrative calculation shows the effect of mandatory dependencies: if five components each have availability of 99.9%, if every component must work for the service to work and if their states are statistically independent, combined availability is 0.999⁵, or approximately 99.501%. That corresponds to approximately 2,622.75 minutes outside the combined availability condition over the same year. The purpose is to expose the assumptions behind a percentage, rather than forecast an actual outage. Real shared failures, conditional dependencies and overlapping incidents require an operational model supported by observed records.

Explicitly illustrative case	Calculation	Result over a 365-day year	Limitation
One service at 99% availability	525,600 minutes × 0.01	5,256 minutes outside the availability condition	No contractual exclusions
One service at 99.9%	525,600 × 0.001	525.6 minutes	No statement about incident distribution
One service at 99.99%	525,600 × 0.0001	52.56 minutes	Does not measure answer quality
Five mandatory independent components, each at 99.9%	Combined availability = 0.999⁵	Approximately 99.501%; 2,622.75 minutes outside the combined condition	Assumes statistical independence and an all-components-required structure
Two interchangeable independent instances, each at 99.9%	Combined unavailability = 0.001²	99.9999% availability; 31.536 seconds outside the combined condition	Assumes perfect substitution and no shared dependency

Calculated for this assessment. The examples are mathematical illustrations, not measured service performance or recommended contractual commitments.

Redundancy must preserve authority and usable application state

The apparent improvement in the final row depends on conditions that a deployment must demonstrate. Two instances are not operational substitutes merely because they contain the same model. They also need the required application configuration, authorised data access, available capacity and a functioning method for directing work to the surviving instance. A service can therefore be replicated at the execution layer while retaining a common failure point in routing, identity, storage or release management. Testing should identify the business function that survives each dependency loss and the restrictions necessary during that period. For example, an approved local mode could retain low-consequence functions while suspending actions that require unavailable verification or current authorisation. This is a proposed continuity pattern whose suitability depends on the application; it should not be presented as an automatic property of edge computing. ETSI’s reference architecture explicitly considers available resources, required services, location, connectivity and application-state relocation when selecting hosts or supporting mobility. These documented dependencies support testing relocation as an integrated application event. Multi-access Edge Computing (MEC); Framework and Reference Architecture, Annex A.1 and A.4 — ETSI — May 2025. etsi.org

Global measurement must preserve the visibility of local failure

A global service-quality framework should require comparable evidence without assuming that every location or language has the same workload. The proposed reporting structure should establish common definitions for accepted tasks, interruptions and recovery, then retain separate results for materially different deployment segments. Statistical confidence matters because a service can appear reliable when tested too rarely against uncommon but consequential conditions. Evaluation should also distinguish the distribution of routine demand from targeted stress tests: an aggregate service result describes the observed workload, while a controlled disruption exercise establishes behaviour under a specified failure. Neither should silently stand in for the other. MLPerf’s published rules reinforce the importance of declared scenarios, quality conditions and reproducibility, including the provision of conversion procedures when model formats change. Institutional acceptance should extend this discipline to local configuration changes, so that a modification in numerical precision, model version or retrieval source triggers evaluation proportionate to the behaviour it can affect. This approach creates a continuing evidence obligation rather than allowing a historical benchmark to become a permanent claim about a changing service. MLPerf Inference Rules — MLCommons — undated rules repository, accessed Nov 2026. GitHub

Key judgments

The controlling service measure is the rate at which the system completes acceptable tasks under declared conditions. Token throughput, component availability and recovery mechanisms remain necessary supporting evidence, but none alone establishes institutional readiness. A distributed network should consequently be assessed through normal demand, segment-specific evaluation and defined dependency-loss exercises, with the denominators and exclusions preserved.

What would change the assessment

A service would justify stronger reliance if repeated exercises demonstrated acceptable task completion during shared-service failure and orderly restoration afterwards. Evidence that failover depends on the same unavailable control services, that slower requests are excluded from reporting or that degraded operation materially changes the task without disclosure would weaken the assessment.

Open official record

The necessary deployment records are the service-level definitions, workload distributions, segment evaluations, dependency-loss results and recovery logs. Where suppliers disclose only aggregate throughput or component uptime, the public record remains insufficient to establish the quality of the complete institutional service.

Chapter 3 — Industrial Economics and Infrastructure Constraints

The scarce resource is dependable completed work

The economic assessment of distributed AI should compare the total cost of delivering an accepted result across feasible architectures. An advertised accelerator-hour excludes important determinants of value: whether the model fits the available memory, whether the runtime supports the required operations, how much work must move across networks and how often execution fails or requires validation. Shared capacity can be attractive for separable workloads, but its price must be evaluated after communications, isolation, rejected contributions, repeated work and administrative overhead. Dedicated infrastructure also carries costs beyond acquisition, including unused capacity, maintenance, specialised staff and operational reserves. This assessment therefore proposes a consistent accounting boundary: count all costs necessary to submit, execute, validate and deliver the work, then divide by the number of outputs meeting the declared acceptance conditions. Such a denominator discourages the appearance of efficiency created by accepting lower-quality results or omitting failed attempts. The comparison should be repeated for the expected demand pattern because the economics of a continuously utilised service differ from those of a lightly used installation held for operational independence.

Memory and interconnect specifications constrain substitution

A concrete hardware reference illustrates why accelerator counts cannot be treated as interchangeable productive capacity. NVIDIA’s H100 datasheet specifies 80 GB of memory, 3.35 TB/s of GPU memory bandwidth and configurable thermal design power up to 700 W for the SXM variant. These are manufacturer specifications, not measurements of a particular application. Applied to the earlier calculated payload, a uniformly represented 70-billion-parameter model at 16 bits requires 140 GB for weights alone and therefore exceeds the specified memory of one such accelerator; a four-bit payload of 35 GB changes that storage comparison without establishing the performance or utility of the resulting deployment. The economic consequence is that hardware selection must follow a declared model representation and serving configuration. Similarly, power accounting should separate a component’s design limit from its measured energy use. Eight components at 700 W produce a calculated aggregate design-power figure of 5.6 kW; continuous operation at that power for 30 days would equal 4.032 MWh. This explicitly hypothetical calculation excludes the rest of the server, networking and cooling and should not be presented as observed consumption. NVIDIA H100 Tensor Core GPU Datasheet — NVIDIA — undated manufacturer specification, accessed Nov 2026. NVIDIA

Network transfer imposes an equally transparent lower bound on the mobility of computational work. Moving a 140 GB parameter payload over a fully available 1 Gbit/s link requires at least 1,120 seconds, or 18 minutes and 40 seconds; the corresponding arithmetic is 112 seconds at 10 Gbit/s and 11.2 seconds at 100 Gbit/s. The calculation converts bytes to bits and divides by the stated rate, assuming decimal units, continuous utilisation and no overhead. Real transfers add protocol costs, contention, preparation and storage access, while repeated training exchanges or session-state transfers introduce different traffic patterns. These illustrative values show why distribution policy should distinguish preparing a remote site before demand arrives from moving a large model after a failure has occurred. They also explain the economic value of maintaining approved copies where continuity is required: pre-positioning consumes storage and management effort but can avoid placing model transfer inside the recovery window. This is a workload-specific trade-off whose solution requires the institution’s actual bandwidth, model size, update frequency and interruption tolerance.

Calculated transfer case	Payload	Ideal transfer duration	Interpretation
1 Gbit/s continuously available	140 GB	1,120 seconds	18 minutes 40 seconds before overhead
10 Gbit/s continuously available	140 GB	112 seconds	1 minute 52 seconds before overhead
100 Gbit/s continuously available	140 GB	11.2 seconds	Does not establish equivalent application recovery time

These are transfer arithmetic examples calculated for this assessment. They do not measure any commercial network, training configuration or service.

Electricity and grid connections determine the pace of expansion

Infrastructure expansion operates on a different timetable from software deployment. The IEA’s 2025 assessment estimated that around 20% of planned data-centre projects could face delay if electricity-infrastructure risks were not addressed and reported transmission-development periods of four to eight years in advanced economies. Those figures remain a dated assessment, rather than a current measurement of delayed projects. Their industrial significance is that distributing workloads can alter where demand appears without eliminating the need for dependable electricity. Capacity purchased at an attractive computational price may remain constrained by the host’s local connection, cooling or power arrangements. The appropriate procurement question is therefore whether the proposed execution site has deliverable infrastructure for the contracted service period, supported by connection status and commissioning evidence. A plan to acquire hardware, a plan to construct power infrastructure and an operational installation represent different stages of capability. Energy and AI, Executive summary — International Energy Agency — Apr 2025. IEA

The IEA’s April 2026 update further identifies an anticipated high-bandwidth-memory shortage lasting through at least the end of 2027 and a possible 20–25 GW of battery storage installed in data centres worldwide by 2030. These are an assessment and a prospective range, respectively. Battery power capacity in GW does not establish stored energy or backup duration; those require energy-capacity figures and an operating specification. For institutional buyers, the implication is to require evidence about the complete infrastructure supporting the service, rather than interpreting equipment announcements as assured delivery. Key Questions on Energy and AI, Executive summary — International Energy Agency — Apr 2026. IEA

Infrastructure indicator	Documented value or status	Reference vintage	Decision-relevant qualification
Data-centre projects exposed to potential delay	Around 20% if identified risks were not addressed	IEA, Apr 2025	Conditional estimate; not a count of completed delays
New transmission development in advanced economies	Four to eight years	IEA, Apr 2025	General infrastructure lead time, not a project-specific schedule
High-bandwidth-memory constraint	Shortage anticipated through at least end-2027	IEA, Apr 2026	Outlook dependent on supply and demand developments
Data-centre battery storage	Possible 20–25 GW globally by 2030	IEA, Apr 2026	Power capacity; does not specify storage duration

European infrastructure is developing through different institutional models

Italy’s IT4LIA programme illustrates the importance of separating existing access from contracted expansion. EuroHPC’s announcement of 22 April 2026 records a procurement contract for a new AI-optimised system at CINECA in Bologna and a total budget of €290 million covering acquisition, delivery, installation and maintenance, with 50% financed by EuroHPC. The same announcement states that IT4LIA had already provided resources and services through existing infrastructure, particularly Leonardo, since April 2025. The appropriate Italian industrial assessment therefore concerns both the accessibility of current services and the commissioning of the contracted system. Its national value should be tested through the ability of firms and research users to prepare workloads, obtain access and carry useful models into production. A procurement budget establishes the financial scope of an infrastructure commitment; it does not measure subsequent utilisation or economic return. EuroHPC JU Signs Contract to Boost AI Capabilities with IT4LIA AI Factory — EuroHPC Joint Undertaking — Apr 2026. eurohpc-ju.europa.eu

France’s AI2F model places greater emphasis on federating access to an existing ecosystem of computing facilities, expertise and support. Its first-party description identifies Jean Zay, Adastra and Joliot-Curie among the facilities used, while distinguishing the forthcoming Alice Recoque system. The CORDIS record describes a GENCI-led consortium and a project period running from October 2025 to September 2028. For France, the industrial question is consequently whether this coordination reduces the practical distance between available infrastructure and deployable applications. Shared access routes and expertise can address barriers that additional hardware alone would leave intact, but that benefit should be assessed through service records and completed workloads. This model also demonstrates that distributing access across institutions does not require treating every participating facility as one seamlessly interchangeable machine. AI Factory France — AI2F — undated first-party description, accessed Nov 2026; AI Factory France, project 101260391 — European Commission, CORDIS — record updated Oct 2026. aifactory-france.eu

Germany’s official EuroHPC description identifies both HammerHAI in Stuttgart and the JUPITER AI Factory in Jülich. HammerHAI’s stated industrial orientation includes engineering, manufacturing, mobility and automotive applications, accompanied by technical support and skills development. The relevant German comparison should therefore focus on sector-specific conversion of compute access into usable capability: whether an industrial user can prepare its data, evaluate a model and integrate the result into its operating environment. The United Kingdom provides a different evidentiary baseline through a parliamentary answer dated 27 April 2026, which reports operational AIRR capacity of approximately 5,448 NVIDIA accelerator chips at Isambard-AI and 1,024 Intel accelerator chips at Dawn in April 2026. Those counts establish reported installed resources at a defined date and should not be added into a single performance figure. Different hardware and software environments require separate workload measurements before their practical substitutability can be established. Germany — EuroHPC Joint Undertaking — undated programme description, accessed Nov 2026; Artificial Intelligence: Research, Written Question 128826 — UK Parliament — Apr 2026. eurohpc-ju.europa.eu

Jurisdiction	Documentary baseline	Status distinction to preserve	Industrial acceptance question
Italy	IT4LIA existing services and €290 million procurement scope	Current access versus contracted expansion	Does available support convert compute access into accepted production workloads?
France	AI2F coordination of facilities, services and expertise	Existing facilities versus forthcoming infrastructure	Does coordination reduce preparation and deployment barriers?
Germany	HammerHAI and JUPITER AI Factory	Programme services versus workload-specific capability	Can sector users validate and integrate applications?
United Kingdom	AIRR hardware counts reported for April 2026	Installed accelerator counts versus comparable performance	Can workloads move between environments with acceptable cost and quality?

Switching costs persist beyond the movement of data

An institution’s ability to change provider depends on the portability of its application, data, identity arrangements, operating procedures and evaluation evidence. The CMA’s October 2026 update reports continuing barriers to switching and multi-cloud use despite steps taken by major providers, and identifies cross-cloud identity and access management and Kubernetes portability as areas for further work. This supports a more demanding procurement test than asking whether a supplier offers an export function: the customer should demonstrate that another environment can deliver an accepted result using the transferred application and its required controls. Migration expenditure can include rebuilding interfaces, validating numerical behaviour, reproducing permissions and operating both environments during transition. These costs create a practical dependence even where a contractual right to leave exists. A credible exit plan should therefore be treated as an exercised operational capability, with a defined destination configuration and a record of what can be transferred, reconstructed or replaced. Update on cloud actions — Competition and Markets Authority — Oct 2026. assets.publishing.service.gov.uk

The EU Data Act changes part of this cost structure while preserving an important distinction between switching and continuing parallel use. Article 29 prohibits switching charges for the switching process from 12 January 2027. Article 34 separately allows egress charges for in-parallel use, limited to passing on incurred costs. It would therefore be incorrect to infer that all continuing transfers within a multi-cloud AI system become free on that date. The Commission’s October 2026 recommendation provides non-binding contractual clauses addressing switching and exit, including cooperation and continuity. For buyers, the immediate implication is to distinguish provider switching charges, ordinary service fees, permitted parallel-use costs and the customer’s own engineering expenditure. Removing one charge category does not eliminate the technical work necessary to make an alternative environment usable. Regulation (EU) 2023/2854, Articles 29 and 34 — European Parliament and Council — Dec 2023; Commission Recommendation (EU) 2026/2394, Annex VI — European Commission — Oct 2026. EUR-Lex

Key judgments

Distributed AI creates economic value when it increases the supply of acceptable completed work, preserves an institutionally necessary operating capability or reduces a demonstrable dependency at a justified cost. Hardware counts, procurement budgets and headline performance specifications describe different inputs and should remain separate. The industrial opportunity consequently extends beyond accelerator supply to workload preparation, memory-efficient execution, communications, evaluation, infrastructure operation and exercised portability.

What would change the assessment

Evidence of sustained utilisation, competitive accepted-result costs and successful movement of real workloads between environments would strengthen the case for expanding shared infrastructure. Conversely, persistent commissioning delays, underused reserved capacity, expensive state movement or repeated revalidation failures would favour a narrower deployment pattern. Energy claims require comparable metering boundaries, while economic claims require the same task quality and demand assumptions.

Open official record

The remaining decisive records are commissioning and acceptance documents, workload-level utilisation, metered energy use, complete cost allocations and destination-tested exit plans. These observations would establish whether announced infrastructure is producing dependable industrial capability and whether architectural distribution is delivering measurable value.

---

Pillar II — Security, Authenticity and Accountable Control

Assessment date: 15 November 2026. This pillar examines how distributed AI can preserve security, constrain delegated authority and maintain reliable digital evidence, distinguishing enforceable legal requirements, official guidance and proposed institutional controls.

Chapter 4 — Cybersecurity Across the Distributed Lifecycle

Security depends on controlling changes to the system

The principal cybersecurity challenge in distributed AI is to prevent an authorised interaction from becoming an unauthorised change in the system’s behaviour. An institution must distinguish permission to join a network, permission to submit data or model updates, permission to approve a release and permission to exercise operational tools. Combining these permissions creates a pathway through which one compromised participant can affect functions beyond its intended role. The relevant security boundary consequently extends across the lifecycle: acquisition, preparation of datasets, training, evaluation, deployment, operation and retirement. NIST’s secure-development profile for generative AI explicitly extends software-development practices to model provenance, components, derivatives and the data used for training and evaluation. Its significance for distributed deployment is that the accepted unit should be a documented release package, encompassing the model and the components needed to interpret and operate it. The proposed institutional requirement is to preserve enough information to identify exactly what changed, who authorised that change and which deployed services received it. This moves assurance beyond checking whether a model file arrived intact and towards establishing whether the institution is running the configuration it actually approved. Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, practices PS.3 and PW.3–PW.4 — NIST — Jul 2024. doi.org

Identity, operating condition and task authority require different evidence

A distributed participant can possess valid credentials while running an unsuitable configuration, and an approved configuration can still be used for an unauthorised task. Remote attestation addresses part of this distinction by providing evidence about an execution environment for evaluation against an appraisal policy. The IETF’s RATS architecture separates the party producing evidence, the verifier evaluating it and the relying party using the resulting assessment; RFC 9334 is an informational architecture rather than an Internet Standards Track specification. This separation supports a precise institutional interpretation: attestation can contribute evidence about an operating condition, but the relying organisation must still decide whether that condition is acceptable for the requested operation. It does not establish that a dataset is representative, an output is correct or an operator has lawful authority to process particular information. The proposed admission procedure should therefore evaluate identity, environment and task permissions separately, with limits on the duration and scope of the resulting authorisation. If a participant’s credentials, software state or assigned role changes, continued access should depend on a renewed decision proportionate to the change. Remote ATtestation procedureS (RATS) Architecture, sections 3–5 — Internet Engineering Task Force — Jan 2023. rfc-editor.org

Security boundary	Evidence to establish	What that evidence cannot establish by itself	Proposed decision owner
Participant identity	Which person, organisation or workload holds the credential	Whether its contribution is safe	Identity and access authority
Execution environment	Whether reported operating conditions meet the appraisal policy	Whether the requested processing is lawful	Platform security authority
Dataset admission	Origin, permitted use, integrity and relevant quality checks	Whether all downstream behaviour is acceptable	Data owner and development authority
Contribution acceptance	Whether an update or result passes defined checks	Whether an entire release is ready	Training or task-validation authority
Model release	Whether the complete configuration meets release criteria	Whether every future use is authorised	Accountable provider or service owner
Operational action	Whether the specific action is permitted in its current context	Whether the model’s explanation is reliable	Application owner and authorising official

These are proposed functional responsibilities. They do not replace the legal roles examined in Chapter 6.

The supply chain includes information that changes model behaviour

A distributed AI supply chain includes more than executable software. Training data, evaluation datasets, model weights, tokenisers, retrieval sources and configuration can influence the behaviour of the resulting service. The joint AI data-security guidance issued by the NSA, CISA, FBI and international partners recommends data provenance, digital signatures, integrity verification and protected infrastructure across the lifecycle. The institutional consequence is to bind an admitted dataset or component to its approved purpose and version, rather than allowing a familiar supplier name to substitute for acceptance evidence. A cryptographic signature can establish that a particular key signed a particular object, subject to the validity of the verification process; it does not establish the object’s substantive quality. If a signing system is compromised, malicious material can acquire apparently legitimate distribution credentials. Accordingly, proposed release procedures should combine technical integrity checks with independent evaluation of behaviour and preserve the ability to suspend a supplier, dataset or release lineage without disabling unrelated services. The purpose is to limit how far one accepted but defective component can propagate through the institution. AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems — NSA, CISA, FBI and international partners — May 2025. ic3.gov

Poisoning must be distinguished from ordinary changes in data

An adverse change in model behaviour can arise from malicious modification, defective data preparation or a legitimate change in the population being served. These explanations require different responses. NIST distinguishes availability-oriented poisoning, targeted poisoning and backdoor mechanisms, and documents limitations in defensive aggregation for federated models. The analytical implication is that an unusual contribution should trigger investigation without automatically being labelled an attack: an institution holding a different population can produce an update that differs materially from the majority for legitimate reasons. Conversely, acceptable average performance cannot establish the absence of narrowly targeted malicious behaviour. A defensible acceptance process should therefore retain evaluations for consequential subgroups and defined attack conditions, and should compare changes against both operational data and controlled reference tests. The proposed threshold for promotion is evidence that a release meets the declared task and security conditions, rather than evidence that most participants agree with it. Where the integrity of a contribution remains unresolved, withholding promotion protects the deployed service while preserving material for investigation. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, section 2.3 — NIST — Mar 2025. nvlpubs.nist.gov

Observed condition	Plausible explanation to investigate	Proposed immediate response	Evidence needed before promotion resumes
Broad deterioration after an update	Defective processing, unsuitable training or availability poisoning	Suspend promotion and preserve the previous approved release	Reproduction of the deterioration and identification of affected components
Deterioration confined to a consequential category	Distribution differences, sampling defects or targeted manipulation	Expand category-specific evaluation	Performance and integrity results for the affected category
Behaviour activated by a particular input pattern	Legitimate special-case behaviour or a backdoor	Isolate the candidate release	Controlled tests and investigation of its development lineage
Unexpected disclosure through outputs	Access-control failure, memorisation or privacy attack	Restrict the affected interface and preserve evidence	Exposure assessment and validated corrective controls
Changes without corresponding release records	Administrative error or unauthorised modification	Contain the affected deployment	Reconciled inventory, authorisation and integrity records
Repeated suspicious contributions from related participants	Faulty configuration or coordinated manipulation	Review admission and related identities	Participant relationships, execution evidence and contribution histories

The table is an investigative decision framework. Its rows do not assign probabilities or establish attribution.

Privacy guarantees must survive repeated participation

Privacy in a distributed service must be assessed across the repeated use of the same information. NIST’s differential-privacy guidance describes how privacy guarantees depend on the mechanism, the definition of the protected entity, the parameters and the composition of multiple analyses. A claim that one training round or output satisfies a particular guarantee therefore needs an account of how repeated rounds, releases or queries affect the overall protection. The proposed institutional record should identify whether protection applies to an individual record, a person or another defined unit, together with the accounting method and the assumptions about the parties observing the computation. Encryption, secure aggregation and differential privacy address different exposures and should not be presented as interchangeable controls. In particular, concealing individual updates from an aggregator does not itself establish a limit on what can be inferred from the released model. The governance consequence is to approve a continuing privacy configuration, including its monitoring and change rules, rather than approve a technology label. Changes in participant numbers, release frequency or the use of outputs should trigger review where they affect the assumptions supporting the claimed guarantee. Guidelines for Evaluating Differential Privacy Guarantees, sections on privacy units, parameters and composition — NIST — Mar 2025. nvlpubs.nist.gov

Recovery must remove compromised trust relationships

Cybersecurity recovery differs from restarting an interrupted service because the components used for restoration may themselves be implicated in the compromise. Restoring a previous model does not resolve a stolen administrative credential, a compromised signing service or a poisoned source that will feed the next release. The UK’s AI Cyber Security Code of Practice calls for asset inventories, restoration of a known-good state, incident and recovery plans, and renewed testing for major updates. Building on those requirements, this assessment proposes a recovery sequence that first identifies the affected identities, artefacts and data sources, then establishes an approved restoration configuration outside the compromised path. The release record should make clear why that configuration is considered acceptable and which residual restrictions remain. Evidence should also be preserved before destructive remediation where it is needed to establish exposure, downstream effects or legal reporting duties. Finally, the institution must address outputs and actions already produced: restoring the service cannot retract confidential information already disclosed or automatically correct decisions made from manipulated results. Code of Practice for the Cyber Security of AI, principles 5, 6 and 10–12 — UK Government — Jan 2025. GOV.UK

Key judgments

The decisive security controls govern transitions between identities, contributions, releases and operational permissions. Distributed execution creates additional places where these transitions occur, making complete inventories and traceable release decisions necessary. No single admission mechanism establishes all the required properties: identity, environmental integrity, data quality, privacy and authorised action require evidence appropriate to each claim.

What would change the assessment

Broader deployment would be supported by repeatable evidence that compromised participants can be contained without uncontrolled model promotion, that privacy guarantees remain valid across repeated operation and that restoration removes the affected trust relationships. Recurrent unexplained changes, incomplete lineage or recovery procedures that reuse compromised credentials would weaken the case for reliance.

Open official record

For an individual deployment, the consequential records are its release inventory, contribution-admission rules, privacy accounting, adversarial evaluations and security-recovery results. Without these, the institution cannot establish how far a compromise could propagate or whether a restored service has returned to an acceptable condition.

Chapter 5 — Agentic Systems and the Integrity of Digital Evidence

Delegated action requires an authority model outside the model

Agentic AI changes the security question because a generated interpretation can initiate an operation in another system. The NCSC’s April 2026 analysis identifies model-input manipulation through direct inputs, reference databases, tool responses and other agents. The institutional consequence is that the origin of a message and its role in the workflow must remain visible after the model processes it: an instruction embedded in a supplier document does not acquire the authority of the official who requested analysis of that document. This assessment therefore proposes treating model-generated actions as requests to an external authorisation mechanism. That mechanism should evaluate the requesting identity, permitted purpose, target resource, operation and current conditions before execution. Where an action requires human approval, the approver should receive a concrete description of the operation and its consequences rather than a general assurance from the model. A second model can contribute analysis, but its agreement should not replace an enforceable permission check, particularly when both systems have consumed the same potentially manipulated material. Understanding adversarial attacks against Machine Learning and AI, section 2.5 — National Cyber Security Centre — Apr 2026. National Cyber Security Centre

Authority should narrow as work moves between agents

A chain of agents should preserve the scope of the initiating task rather than accumulate permissions as work is delegated. The proposed delegation record should identify the delegating principal, the receiving agent, the permitted resources, the operation class and the conditions under which the delegation expires or is withdrawn. A research agent permitted to read public material should not gain permission to send communications because it passes its findings to another agent that happens to possess a messaging tool. Similarly, an agent allowed to prepare a proposed configuration should not infer permission to apply it. The practical control is to bind permissions to explicit task roles and re-evaluate them at the point of action. The architecture should also distinguish evidence supplied by another agent from an instruction issued by an authorised principal. These are proposed institutional controls derived from the documented possibility of cross-agent and tool-mediated manipulation; they are not a claim that a universal agent-delegation standard has already resolved the problem. Their value is measurable through attempts to exceed scope and through records showing whether the external controls rejected those attempts.

Agent capability	Proposed authority boundary	Evidence before execution	Record retained
Read information	Restrict sources and data classes to the task	Requesting identity and access decision	Sources accessed and applicable permissions
Prepare a draft	Permit composition without implying release	Intended audience and purpose	Draft version and supporting evidence
Send a communication	Require recipient, content and sending authority	Concrete approved message	Approval and transmission record
Change a system	Limit target, operation and execution conditions	Validated change and required approval	Applied configuration and execution result
Delegate work	Pass a defined subset of permissions	Delegator’s authority and permitted scope	Delegation chain, limits and termination
Publish transformed media	Require provenance and disclosure checks	Approved asset and transformation record	Published version and associated disclosures

This table defines a proposed control model. The legal conditions for particular activities remain jurisdiction- and use-specific.

Human oversight must permit an effective intervention

A human approval step provides limited protection when the reviewer cannot understand the proposed action, inspect its evidentiary basis or prevent execution. The relevant institutional design should give the reviewer sufficient information, time and authority to intervene, while avoiding interfaces that encourage routine confirmation of an opaque recommendation. For high-risk systems, Article 14 of the EU AI Act identifies oversight capabilities including understanding limitations, interpreting outputs, disregarding or overriding results and interrupting operation. These provisions should be read with the amended application timetable and the relevant system classification; they are not a universal rule applying identically to every AI tool today. As an engineering implication, the action presented for approval should identify what will change, which resources will be affected and whether reversal is possible. The review record should preserve the action actually approved, so that subsequent execution can be checked against it. Approval of a description that later changes should not silently authorise the changed operation. Regulation (EU) 2024/1689, Article 14 — European Parliament and Council — Jun 2024; Regulation (EU) 2026/1744 — European Parliament and Council — Jul 2026. EUR-Lex

Digital evidence requires a history of handling and transformation

For institutional analysis, the evidentiary record should preserve the relationship between the acquired asset, subsequent transformations and the conclusions drawn from it. A generated transcript, translated speech segment or enhanced image can assist analysis while introducing an additional layer that must remain distinguishable from the acquired material. NIST’s forensic guidance describes integrity preservation, handling records and examination of copies; its 2006 publication is used here for those established procedural principles, rather than as a current guide to synthetic-media detection. The proposed record for AI-assisted evidence handling should retain the original asset, acquisition context, integrity checks, the tools and versions used for material transformations and the analyst’s assessment of the resulting limitations. Where a system produces different versions for different audiences, each material variant should remain linked to the source and its transformation record. This does not make every derivative equally authoritative. It enables an institution to reconstruct which version informed a decision and to separate observed content from an inference or reconstruction. Guide to Integrating Forensic Techniques into Incident Response, sections 2–3 — NIST — Aug 2006. nvlpubs.nist.gov

Evidence layer	Question it addresses	Proposed preservation record	Remaining limitation
Acquisition	What was obtained, from where and when?	Original asset and acquisition context	Does not establish the truth of the depicted event
Integrity	Has the retained object changed?	Hashes, protected copies and verification results	Does not establish that the original was genuine
Provenance	What creation and editing history is asserted?	Credentials, manifests and validation results	Assertions depend on their issuers and verification
Transformation	What did the analytical tool change?	Tool version, settings and derivative linkage	The transformation can introduce error
Interpretation	What conclusion follows from the material?	Analyst reasoning, corroboration and limitations	Conclusions remain revisable
Decision use	Which version informed an action?	Decision record and referenced evidence version	Does not establish that the decision was justified

Provenance systems require their own incident response

Content-provenance technology depends on the security of the keys, issuers and verification procedures supporting it. C2PA’s version 2.4 security considerations discuss compromised signing keys, certificate revocation, freshness of revocation information and the treatment of validation that cannot be completed. The document is explicitly non-normative, and the cited version should not be presented as proof that every implementation follows those practices. Its institutional implication is that content credentials require an operational trust policy: an organisation should establish what its viewer verified, when it checked the relevant status and what happens when the issuer or signing system is compromised. A previously accepted asset may require reassessment following a trust event. This makes archived validation context important, particularly when evidence is used over an extended period or examined offline. The institution should also avoid converting absence of credentials into a definitive judgment that an asset is false; C2PA’s explainer recognises incomplete or removed provenance and distinguishes provenance from factual truth. C2PA Security Considerations, sections 4.3.2 and 5 — Coalition for Content Provenance and Authenticity — version 2.4, undated; C2PA and Content Credentials Explainer, section 7.2 — C2PA — version 2.2, undated. spec.c2pa.org

Disclosure obligations do not settle evidentiary reliability

The EU AI Act distinguishes machine-readable marking by providers of systems generating synthetic content from disclosure obligations applying to deployers in specified circumstances. Article 50 also contains qualifications, including for assistive standard editing, certain legally authorised activities and evidently artistic or analogous works. The institutional consequence is to preserve separate assessments of legal disclosure, technical provenance and factual reliability. A marked synthetic asset can still be useful evidence of what was published or communicated, while an apparently authentic recording can remain factually misleading because of context, selection or attribution. Conversely, retaining an original internally does not by itself satisfy an applicable disclosure duty towards recipients. A public authority or publisher should therefore identify the nature of the transformation, the audience receiving it and the purpose for which it will be used before determining the required notice and evidentiary treatment. The applicable transition provisions must be checked for the particular system; transparency should not be reduced to a generic label applied without regard to the operative provision. AI Act, Article 50 — European Commission, AI Act Service Desk, consolidated-text presentation as at Jul 2026. AI Act Service Desk

Key judgments

Agentic systems require enforceable limits on the transition from interpretation to action, while digital evidence requires a reconstructable transition from acquisition to decision use. These are distinct forms of accountability that meet when an agent acts on transformed or externally supplied information. Their common requirement is a preserved record linking the relevant input, authority, version and consequence.

What would change the assessment

Operational reliance would be strengthened by demonstrated rejection of unauthorised delegated actions, usable human intervention and successful reconstruction of decisions from retained evidence. It would be weakened by approvals detached from the executed operation, undocumented transformations or provenance viewers that conceal incomplete verification.

Open official record

The decisive deployment records are delegation policies, external permission checks, consequential-action logs, evidence-handling procedures and provenance-validation policies. For particular media, the necessary records include the original asset, material derivatives and the verification context supporting their use.

Chapter 6 — Legal Authority and European Implementation

Legal responsibility follows functions and statutory roles

Distributed architecture does not remove the need to identify the persons and organisations responsible for processing, supply and operational use. Under the GDPR, controller and processor status depends on the functions performed, including the determination of purposes and means; the EDPB’s guidance explains that contractual descriptions cannot displace the factual allocation of responsibilities. An institutional federation must therefore examine who decides the training objective, selects participating datasets, determines significant processing arrangements and uses the resulting model. Some arrangements can involve joint controllership, but that conclusion should follow the actual decisions and processing rather than the presence of a shared technical platform. The proposed implementation record should map the relevant entities, purposes, data flows and contractual obligations before operational admission. It should also distinguish data-protection roles from the AI Act’s provider and deployer roles, because the same organisation can occupy different positions under the two frameworks. A technical coordinator should not be assumed to be the sole legally responsible actor simply because it operates the aggregation or routing service. Guidelines 07/2020 on the concepts of controller and processor in the GDPR — European Data Protection Board — Jul 2021. edpb.europa.eu

Modifying a system can change the obligations of its integrator

The AI Act’s value-chain provisions require attention when an organisation modifies a supplied system rather than merely deploying it within its documented purpose. Article 25 identifies circumstances in which a distributor, importer, deployer or third party becomes a provider of a high-risk system, including specified rebranding, substantial modification and changes of intended purpose that make a system high-risk. Those conditions must be applied with the relevant classification and application dates; routine configuration should not automatically be described as a substantial modification. The practical consequence for distributed services is that responsibility should be reassessed when an integrator changes the model, its purpose or the action capabilities surrounding it. Supplier assurances about the original system cannot automatically establish the compliance of a materially different configuration. Contracts should consequently specify access to the information and technical assistance necessary for the applicable obligations, while release procedures should identify changes that require a fresh legal and conformity assessment. AI Act, Article 25 — European Commission, AI Act Service Desk, consolidated-text presentation as at Jul 2026. AI Act Service Desk

Legal question	Relevant framework	Required distinction	Implementation consequence
Who determines personal-data processing?	GDPR and EDPB controller/processor guidance	Factual role versus contractual label	Map purposes, means and actual decisions
Who supplies or materially changes the AI system?	AI Act, Article 25	Original system versus modified high-risk configuration	Reassess provider status and supporting documentation
What security requirements attach to a high-risk system?	AI Act, Article 15	Classification and application date	Establish appropriate accuracy, robustness and cybersecurity evidence
What additional duties attach to a systemic-risk GPAI model?	AI Act, Article 55	Model-provider duties versus downstream system duties	Maintain evaluations, risk mitigation, incident records and cybersecurity
What duties attach to synthetic content?	AI Act, Article 50	Provider marking versus deployer disclosure	Assess the content, use, exceptions and transition provisions
Which authority receives an incident report?	GDPR, NIS2, DORA or AI Act, as applicable	Different triggers, regulated entities and reporting routes	Maintain a regime-specific notification map

Article 15 requires appropriate accuracy, robustness and cybersecurity for high-risk systems and consistency in those respects throughout their lifecycle. Article 55 separately requires providers of general-purpose AI models with systemic risk to conduct evaluations, assess and mitigate systemic risks, document and report serious incidents without undue delay, and ensure adequate cybersecurity for the model and its physical infrastructure. These provisions address different regulated objects and should not be merged into a single claim that every distributed node must obtain an identical AI approval. Their implementation should follow the provider, model, system and use concerned, together with the amended timetable. Regulation (EU) 2024/1689, Article 15 — European Parliament and Council — Jun 2024; AI Act, Article 55 — European Commission, consolidated-text presentation as at Jul 2026; Regulation (EU) 2026/1744 — European Parliament and Council — Jul 2026. EUR-Lex

Incident reporting requires several separate legal assessments

A distributed-AI incident can simultaneously affect service operation, personal data and regulated decision-making, but those consequences do not produce one interchangeable reporting clock. NIS2 requires an early warning within 24 hours of awareness of a significant incident and a subsequent notification within 72 hours, subject to its scope, national implementation and specific exceptions. The GDPR’s 72-hour rule concerns notification by a controller of a personal-data breach, where feasible and unless the breach is unlikely to create a risk to individuals’ rights and freedoms; processors must notify controllers without undue delay. DORA establishes a sector-specific framework for covered financial entities, including major ICT-related incident reporting and ICT third-party risk, and has applied since 17 January 2025. The operational implication is to classify the event against each applicable regime promptly, rather than wait for a complete attribution or forensic conclusion. A model-integrity incident can require action before an organisation knows whether personal data were exposed, while a disclosure through an agent can constitute a personal-data breach without interrupting availability. Directive (EU) 2022/2555, Article 23 — European Parliament and Council — Dec 2022; Regulation (EU) 2016/679, Article 33 — European Parliament and Council — Apr 2016; Regulation (EU) 2022/2554, Articles 19 and 28–30 — European Parliament and Council — Dec 2022. EUR-Lex

Reporting framework	Trigger to assess	Timing established in the cited record	Qualification
NIS2	Significant incident affecting a covered entity	Early warning within 24 hours; notification within 72 hours	National implementation, scope and exceptions matter
GDPR, controller notification	Personal-data breach meeting the notification threshold	Without undue delay and, where feasible, within 72 hours of awareness	Exception where risk to individuals is unlikely
GDPR, processor notification	Awareness of a personal-data breach	Notify the controller without undue delay	Different obligation from the controller’s authority notification
DORA	Major ICT-related incident involving a covered financial entity	Sector-specific reporting framework	Applicable technical rules must be checked for the incident
AI Act, Article 55	Serious incidents concerning a systemic-risk GPAI model	Without undue delay	Applies to the specified model providers

Italy: competence must be mapped beyond the two principal agencies

Italy’s Legislative Decree No. 179 of 7 October 2026, effective from 23 October 2026, provides a more detailed national authority framework than a simple reference to AgID and ACN would convey. The decree identifies AgID as the national notifying authority and records ACN’s market-surveillance and single-contact functions, while preserving specified responsibilities for financial authorities, the Garante and sectoral bodies. The institutional consequence is that an Italian deployment should identify its relevant supervisory route through the use and regulated sector, rather than send every question to the same agency. Procurement and operational contracts should preserve access to the documentation required by the competent authority and allocate who prepares the response when several organisations participate. For a distributed service, this also means retaining a usable Italian accountability map even where computational work is performed abroad. Technical outsourcing can alter the supply chain and processing arrangements, but it does not eliminate the obligations attached to the Italian provider, deployer or regulated institution. Decreto legislativo 7 ottobre 2026, n. 179, Articles 1 and 4–5 — Repubblica Italiana, Normattiva — Oct 2026. Normattiva

France: the verified governance proposal must remain distinct from enacted allocation

The French government’s published governance description proposes reliance on existing sectoral authorities, with DGCCRF coordination and technical support from ANSSI and PEReN. Crucially, the page expressly makes implementation of that allocation subject to parliamentary acceptance. The retrieved record therefore supports describing the proposed institutional model, but does not establish every element as an enacted allocation at the assessment date. This distinction has a practical consequence for French operators: existing obligations under applicable EU and national law should continue to be assessed, while the competent AI Act authority for a particular category must be verified against the operative designation. The distributed architecture should preserve documentation that can support either sectoral or cross-cutting scrutiny, including the intended use, responsible entities, system changes and incident handling. The unresolved designation record should not be treated as an absence of substantive obligations or as permission to defer security controls. Les autorités compétentes pour la mise en œuvre du règlement européen sur l’intelligence artificielle — Direction générale des Entreprises — Sep 2025, page accessed Nov 2026. Direction générale des Entreprises

Germany: central coordination coexists with sectoral surveillance

Germany’s KI-MIG provides a statutory allocation in which the Bundesnetzagentur is the competent market-surveillance authority unless the law specifies otherwise. Section 2 preserves relevant product-sector authorities and assigns specified financially related systems to BaFin. Section 6 establishes the central contact function. The Bundesnetzagentur’s September 2026 presentation records its central role from 29 July 2026, but that coordinating role should not be read as replacing every sectoral competence. The German implementation consequence is to connect the technical configuration to the applicable authority path: an AI service integrated into a regulated product or financial activity requires analysis of that context. For distributed suppliers, the useful common documentation is a system inventory linking versions, intended purposes, responsible organisations and deployment locations, with enough detail to answer the competent authority’s questions without reconstructing the service after an incident. KI-Marktüberwachungs-und-Innovationsförderungs-Gesetz, §2 — Bundesrepublik Deutschland — Jul 2026; KI-MIG, §6 — Bundesrepublik Deutschland — Jul 2026; Die neue nationale KI-Governance — Bundesnetzagentur — Sep 2026. Einzelnorm

United Kingdom: voluntary security guidance and binding decision safeguards differ

The UK’s AI cybersecurity code provides a voluntary security baseline, and its imperative drafting should not be confused with a universal statutory obligation applying to every AI system. Binding duties arise separately through applicable law and regulated activities. An important current distinction concerns automated decisions: section 80 of the Data (Use and Access) Act 2025 replaces the former UK GDPR Article 22 structure with Articles 22A–22D, and the relevant commencement regulation brought section 80 into force on 5 February 2026 insofar as it was not already in force. The new provisions define solely automated decisions by the absence of meaningful human involvement, address significant effects, restrict specified processing and require safeguards including information, representations, human intervention and contestation. An institution should therefore avoid applying an outdated description of UK automated-decision law. For distributed agents, the practical requirement is to identify when the system is participating in such a decision and preserve a working route through which the individual can obtain the applicable safeguards. AI Cyber Security Code of Practice — UK Government — Jan 2025; Data (Use and Access) Act 2025, section 80 — United Kingdom — Jun 2025; S.I. 2026/82, regulation 2 — United Kingdom — 2026. GOV.UK

Coordination should standardise evidence while preserving competence

The practical European coordination problem is to make evidence reusable without assuming that one authority’s assessment resolves every legal question. A common technical dossier can identify the model and system versions, processing purposes, responsible organisations, security controls, evaluation results and incident history. Different authorities can then examine the portions relevant to their mandates. This assessment proposes using that shared record to reduce repeated reconstruction while preserving separate decisions on data protection, system conformity, sectoral resilience and individual rights. The same approach supports cooperation with the United Kingdom where technical assurance practices overlap but the legal route differs. Its value depends on disciplined change management: once the model, purpose, delegation structure or data flow changes materially, the organisation must determine which previous assessments remain valid. A shared format can improve institutional coordination; it cannot create legal permission, erase national competence or convert an evaluation performed for one purpose into universal approval.

Key judgments

Accountable control requires both an operational authority chain and a correct legal allocation of duties. The most consequential implementation errors arise when organisations treat a technical coordinator as the sole responsible entity, apply an outdated legal description, confuse a proposed governance arrangement with enacted law or assume that one incident notification satisfies every applicable regime.

What would change the assessment

The assessment would change with operative amendments, final national designations, authoritative interpretations or deployment evidence showing that current allocations leave a material function unaccounted for. For France, the decisive additional record is the enacted designation and its implementing provisions for the relevant category; the conditional government description cannot settle that question.

Open official record

Each deployment requires a current role-and-authority map, the applicable classification and transition analysis, data-protection arrangements, sector-specific obligations and an exercised reporting procedure. These records determine whether the institution can explain who authorised the processing, who controls the system, who can stop its actions and who must answer for its consequences.

---

Pillar III — Strategic Pathways and Institutional Decisions

Assessment date: 15 November 2026. The outlook extends to November 2031. Future pathways are conditional analytical assessments; implementation periods and decision thresholds presented below are proposals rather than forecasts of completed capability.

Chapter 7 — Immediate Impacts and the Outlook to 2031

The immediate constraint is the capacity to absorb AI

The immediate strategic challenge is to convert access to AI into sustained organisational capability. The OECD’s November 2026 assessment estimates that, in 2025, AI was used by 20% of enterprises with at least 10 employees, compared with 52% of large enterprises with at least 250 employees. Calculated from those published figures, the difference is 32 percentage points, and the large-enterprise adoption rate is 2.6 times the rate for the broader covered population. These comparisons do not describe productivity gains, the intensity of use or the distribution of centralised and distributed architectures; they establish a substantial difference in reported adoption within the specified statistical population. The strategic implication is that making computation more widely available will address only part of the adoption problem. Organisations also need suitable information, staff able to evaluate results, integration with existing processes and authority to change how work is performed. Without those complementary capabilities, distributed access can expand experimentation while leaving the most consequential uses concentrated among organisations already equipped to develop, supervise and finance them. AI adoption accelerates across the OECD, but major gaps persist among businesses and generations — Organisation for Economic Co-operation and Development — Nov 2026. oecd.org

Indicator	Published value	Reference population and period	Interpretation
Enterprise AI adoption	20%	Enterprises with at least 10 employees across the OECD; 2025 estimate	Adoption, rather than intensity or demonstrated benefit
Large-enterprise AI adoption	52%	Enterprises with at least 250 employees; 2025 estimate	The large-enterprise category is part of the broader covered population
Adoption difference	32 percentage points	Calculated as 52% minus 20%	A difference between rates, not a relative percentage increase
Adoption-rate ratio	2.6	Calculated as 52 divided by 20	Large-enterprise rate relative to the broader covered population

Source: OECD, November 2026, linked above. Derived comparisons were calculated for this assessment. The figures do not cover all microenterprises and should not be presented as a census of every business.

The institutional response should consequently distinguish technical access, organisational adoption and demonstrated benefit. A firm can obtain an account, complete a pilot and begin regular use without establishing that the service improves the intended process after verification, rework and supervision are included. OECD research using microdata from 15 member countries identifies human and technological capital as important enablers of adoption and finds that part of the observed productivity advantage of adopters reflects those underlying differences. That evidence supports caution about treating the performance of early adopters as an estimate of what every organisation will obtain from the same tool. The proposed policy objective should be to reduce the distance between available technology and an organisation’s ability to use it responsibly, including preparation of information, process redesign and continuing evaluation. For distributed AI, this means financing the work around the computational resource as well as access to the resource itself. Otherwise, public support can subsidise technically successful demonstrations that remain dependent on external specialists and cannot be maintained by the receiving institution. Digital technology diffusion in the age of AI: Cross-country evidence from microdata — OECD — 2026. OECD

Public access programmes create an entry route, not a production guarantee

EuroHPC’s published access arrangements provide a concrete example of how public infrastructure can lower the entry barrier while preserving distinctions between experimentation and operational reliance. Playground access is directed towards entry-level users and smaller allocations, with an eligibility and technical assessment that can result in access within two working days. Fast Lane access is intended for users familiar with high-performance computing, permits requests of up to 50,000 GPU hours for a maximum of three months, and describes approval within four working days. Both arrangements specify access to a single system. These are programme conditions and allocation procedures; they do not establish that every applicant receives immediate unrestricted capacity, that allocated hours are consumed or that the resulting application is ready for production. Their strategic value is to permit relatively bounded testing before an organisation incurs a larger commitment. A useful public-support model would connect such access to a documented exit from experimentation: a reproducible workload, an evaluation record, an identified operating owner and a decision on whether the application should proceed, change direction or stop. Playground Access to AI factories — EuroHPC Joint Undertaking — undated, accessed Nov 2026; Fast Lane Access to AI factories — EuroHPC Joint Undertaking — undated, accessed Nov 2026. eurohpc-ju.europa.eu

Access route	Published allocation characteristics	Published processing indication	What the record does not establish
Playground	Smaller allocations; one to three months; one system	Access can be granted within two working days after the relevant assessment	Production readiness or uninterrupted commercial service
Fast Lane	Up to 50,000 GPU hours; maximum three months; one system	Approval within four working days	Actual consumption or equivalent performance across hardware
Large Scale	More than 50,000 GPU hours	Governed by the relevant access procedure	A universal delivery time or automatic entitlement

The access-mode overview states that Industrial Innovation routes are free for eligible AI SMEs, including startups, for innovation purposes, while other industrial applications can use commercial access. AI Factories Access Modes — EuroHPC Joint Undertaking — undated, accessed Nov 2026. eurohpc-ju.europa.eu

The strategic dependency can migrate towards evaluation and integration

As access to computational resources expands, dependence can migrate towards the organisations that define interfaces, maintain integration software, supply evaluations and decide which configurations are acceptable. This is an analytical possibility rather than a measured redistribution of market power. Its mechanism is straightforward: an institution that can move a workload but cannot reproduce its evaluation or maintain its operational interfaces remains dependent on the party providing those functions. The distinction matters for sovereignty policy because the location of execution captures only one part of institutional control. The European Commission’s Apply AI Strategy places adoption, workforce readiness, reusable solutions and interoperability within a broader implementation agenda, while the public-sector AI toolbox announced in November 2026 brings together standards, examples, training and procurement resources. These initiatives demonstrate recognition of the complementary requirements; their existence does not establish that the adoption barriers have been resolved. The indicator to monitor is whether receiving organisations can use those resources to maintain applications after initial support ends, transfer knowledge to their staff and obtain credible alternatives when a supplier changes terms or withdraws support. Apply AI Strategy — European Commission — undated policy presentation, accessed Nov 2026; AI toolbox supports public administrations to put the Apply AI Strategy into practice — Interoperable Europe Portal — Nov 2026. Shaping Europe’s digital future

Workforce effects should be assessed through tasks and retained expertise

The near-term workforce issue is how AI changes the allocation of tasks, review effort and responsibility inside organisations. The OECD’s June 2026 skills brief reports that shortages of relevant skills constrain adoption and distinguishes specialist AI capability from the broader digital, analytical and interpretative skills required by users. For institutional planning, this supports a task-level assessment rather than a general assumption that deploying an assistant releases an equivalent amount of staff capacity. Time saved in preparation can be offset by review, exception handling or correction, while a useful application can create a new need for staff capable of supervising it. The proposed measurement should therefore examine completed processes, the distribution of work between staff and systems, and the organisation’s ability to perform essential functions when automated support is restricted. A further strategic concern is the loss of internal expertise if staff cease to practise the judgment needed to detect errors. That outcome is conditional on how work is reorganised; it should be monitored through review quality, escalation competence and the availability of staff able to operate the alternative procedure. AI and skills: What we know so far — OECD — Jun 2026. oecd.org

The outlook to 2031 depends on which capabilities institutions build

The planning reference for the period to November 2031 is selective expansion: organisations extend AI where accepted benefits survive operational testing, while retaining more restrictive arrangements where supervision, integration or assurance remain costly. This is a conditional architectural judgment, not a numerical forecast of adoption. A more open and interoperable pathway becomes credible if organisations can move real applications between environments while preserving acceptable outcomes and legal accountability. A concentration pathway becomes more credible if the cost of integration and evaluation makes dependence on a small number of service ecosystems economically preferable, even when computation itself is dispersed. A fragmentation pathway emerges if national, sectoral and supplier-specific requirements create incompatible acceptance procedures that smaller organisations cannot afford to navigate. These pathways can coexist across sectors and countries, and the present evidence does not justify assigning them probabilities or forcing them to sum to a single distribution. Their value is to identify the observations that would change institutional choices before infrastructure commitments become difficult to reverse.

Conditional pathway	Mechanism	Evidence strengthening the pathway	Evidence weakening it	Decision implication
Selective, interoperable expansion	Reusable integration and assurance reduce the cost of deploying bounded applications	Successful transfers and independently repeatable evaluations	Transfers require extensive rebuilding or fail acceptance	Expand applications with demonstrated portability
Concentration around service ecosystems	Integrated suppliers reduce coordination and operating burden	Increasing dependence on supplier-specific tools and assessments	Customers can replace components at acceptable cost	Preserve exit capacity before increasing reliance
Fragmented institutional adoption	Incompatible requirements and limited specialist capacity raise participation costs	Repeated redesign across otherwise similar deployments	Shared evidence is accepted across institutions	Harmonise evidence formats and support smaller users

The Commission’s July 2026 Action Plan on Cybersecurity and Artificial Intelligence introduces another signpost: it announces stronger European evaluation capacity, structured access to advanced AI for cybersecurity and a secure testing platform. Those are stated actions and intentions, not evidence that the complete capability was operational at the assessment date. Their strategic effect will depend on whether evaluation capacity becomes accessible, sufficiently independent and useful for actual deployment decisions. A central facility can improve consistency and reduce duplicated effort, but it can also become a bottleneck if demand grows faster than its ability to assess changing systems. The appropriate watch indicators are completed evaluations, the range of configurations covered, turnaround for consequential assessments and evidence that findings lead to corrections. Announcing a testing platform should therefore be recorded separately from the number of operators able to use it and the operational decisions it has supported. EU Action Plan on Cybersecurity and Artificial Intelligence — European Commission — Jul 2026. Shaping Europe’s digital future

National priorities should follow the remaining implementation gap

For Italy, France, Germany and the United Kingdom, the next strategic question is what additional institutional capability would make existing resources more useful. The priorities below are proposals derived from the architecture, industrial and authority assessments developed in the preceding pillars; they are not statements of newly adopted national policy. Italy’s proposed emphasis is to connect supported access with maintainable applications in receiving organisations. France’s is to turn coordination of facilities and expertise into reproducible routes from experimentation to deployment. Germany’s is to connect sector-specific development with acceptance evidence that industrial users can retain and reuse. The United Kingdom’s is to link public-compute access and procurement with clear records of public-impact applications and demonstrated substitution. At EU level, the proposed common function is to make technical evidence reusable across projects without erasing the different legal responsibilities of providers, deployers and sectoral authorities. These priorities avoid measuring success primarily through programme counts or procurement announcements; they ask whether organisations can perform useful work, retain oversight and continue operating when a particular supplier or support arrangement changes.

Jurisdiction	Proposed implementation priority	Evidence of progress	Principal downside to monitor
Italy	Connect supported access to maintainable institutional and SME applications	Continued operation and internal ownership after pilot support	Permanent dependence on external integration assistance
France	Make shared expertise and infrastructure access reproducible	Documented onboarding-to-deployment routes	Coordination adds another administrative layer
Germany	Reuse sector-specific evaluation and integration evidence	Accepted applications transferred across relevant operating settings	Sector requirements become unnecessarily incompatible
United Kingdom	Link procurement and compute access to public-impact records and tested alternatives	Current records and successful substitution exercises	Transparency becomes detached from operational evidence
European Union	Support reusable assurance methods and cross-border technical evidence	Reduced repeated evaluation for genuinely comparable configurations	Common procedures become slow or excessively uniform

Key judgments

The outlook to 2031 will be shaped by the distribution of organisational competence as well as computational resources. Expansion is justified where institutions can retain useful applications, evaluate changes and replace dependencies at an acceptable cost. The most consequential warning sign is an increase in nominal access accompanied by persistent reliance on a narrow group of integrators, evaluators or service ecosystems.

What would change the assessment

Evidence that smaller organisations sustain applications after initial support, that evaluations can be repeated independently and that transfers preserve acceptable outcomes would strengthen the interoperable-expansion pathway. Evidence that adoption statistics rise while operating benefits remain unverified, internal competence declines or substitution becomes more difficult would strengthen the concentration or fragmentation pathways.

Open official record

The decisive collection gaps are longitudinal records connecting compute allocations to maintained applications, comparable results before and after deployment, actual migration exercises and completed third-party assessments. Adoption surveys and infrastructure inventories cannot establish these outcomes on their own.

Chapter 8 — Courses of Action and Final Net Assessment

Procurement should purchase an accountable operating arrangement

The principal procurement decision is how much operational dependence the institution is prepared to accept in exchange for the proposed capability. The contract should identify the business function, the evidence supporting acceptance, the configuration that will be supplied and the responsibilities retained by both parties. European model contractual clauses provide a starting point for AI-specific terms, with versions intended for different risk contexts and accompanying commentary. The commentary expressly states that the clauses do not constitute a complete agreement and do not supply all terms concerning acceptance, payment, delivery, applicable law or liability; it also identifies adaptations needed for general-purpose systems. The consequence is that adopting a recognised clause set cannot substitute for completing the commercial and operational agreement. A distributed-AI procurement should connect payment and expansion to concrete deliverables, preserve access to the evidence needed for supervision and specify what happens when the supplied configuration changes. It should also identify obligations that the buyer cannot reasonably transfer to the supplier because the buyer controls the relevant data, purpose or deployment decision. Updated EU AI model contractual clauses — European Commission, Public Buyers Community — undated, accessed Nov 2026; Commentary to the Model Contractual Clauses for AI — Public Buyers Community — 2025 version. Public Buyers Community

Acceptance thresholds should be approved before the result is known

A credible evaluation separates the definition of success from the supplier’s final demonstration. The proposed procurement process should establish the task set, quality conditions, representative operating conditions and failure categories before acceptance testing begins. The buyer should identify which conditions are mandatory, which permit a documented restriction and which require redesign or rejection. Where numerical thresholds are justified, they should follow the task and the consequences of error; a universal response-time limit or accuracy percentage would create false comparability across applications. The evaluation should include a baseline representing the existing process, because an AI system can pass a technical test without improving the institution’s overall outcome. Acceptance should also specify the permitted deployment envelope: an application accepted for internal drafting should not silently become an autonomous public-facing decision service. These proposals apply NIST’s distinction between governing, mapping, measuring and managing risk to the procurement decision, without treating the voluntary framework as a universal statutory certification scheme. Artificial Intelligence Risk Management Framework (AI RMF 1.0), sections 5.1–5.4 — NIST — Jan 2023. nvlpubs.nist.gov

Proposed decision gate	Evidence required before the decision	Advance condition	Restrict, redesign or stop condition
Authorise evaluation	Defined purpose, responsible owner and lawful test arrangements	The evaluation can answer a material institutional question	Purpose, authority or necessary information remains unresolved
Accept a bounded pilot	Baseline, representative tasks and explicit operating limits	The pilot is controllable and its results interpretable	Results cannot be compared or consequences cannot be contained
Approve production	Completed acceptance evidence and assigned operating responsibilities	Mandatory task and control conditions are met	A mandatory condition fails or an essential assumption remains unsupported
Expand use	Results from the existing deployment and evaluation of the proposed extension	The extension stays within supported capability	New users, data or actions exceed the evaluated envelope
Accept a material change	Change record and proportionate re-evaluation	Previous assurances remain valid or are replaced	The impact of the change cannot be established
Renew or exit	Operating results, costs, dependency review and alternative assessment	Continued reliance remains justified	Benefit deteriorates or unacceptable dependence persists

Course of action: establish a controlled portfolio of bounded applications

The first proposed course is to organise a portfolio of applications with explicit owners, purposes and acceptance conditions, rather than commission a single broad AI transformation programme whose benefits are difficult to attribute. The authority should sit with the institution’s accountable business owners and procurement leadership, supported by security, data-protection and technical functions within their mandates. The expected effect is to make expansion selective: successful applications can proceed while unsuccessful ones stop without requiring the institution to defend the entire programme. Implementation burden is moderate because the approach requires common records and review procedures, but it can begin within the first procurement or budget cycle without waiting for new infrastructure. Reversibility is relatively high while applications remain bounded and long-term commitments are limited. A second-order benefit is improved demand information for future infrastructure and skills planning. The principal risk is administrative fragmentation if every team invents different records and acceptance methods; the remedy is a common minimum framework with application-specific thresholds, preserving comparison without forcing different tasks into one score.

Course of action: pool scarce assurance expertise

The second proposed course is to establish or procure shared evaluation capacity that can serve multiple public bodies or smaller firms, while retaining the receiving organisation’s responsibility for deciding whether the application is appropriate. The relevant authority is the sponsoring institution or consortium acting within its procurement and funding powers; technical reviewers should have access to the configuration and evidence necessary for the agreed assessment. The expected effect is to reduce repeated setup costs and improve the consistency of specialist testing. Implementation burden is higher than maintaining a register because it requires skilled staff, protected test environments and procedures for conflicts of interest. Time to effect depends on whether an existing competent facility can be used or new capacity must be created. Reversibility is moderate: evaluation methods and records can be retained, but specialist teams require continuing support. The principal risk is that the shared service becomes a gatekeeper whose queues or narrow methods constrain legitimate adoption. Performance should therefore be judged through completed assessments, coverage and correction outcomes. The Commission’s announced evaluation and testing initiatives provide a policy basis for cooperation, while their delivery must remain separately evidenced. New EU plan to address the risks and opportunities of advanced AI for cybersecurity — European Commission — Jul 2026. European Commission

Course of action: exercise substitution before dependence grows

The third proposed course is to require a representative substitution exercise before approving major expansion or renewal of a consequential service. The authority belongs to the contracting institution, which should reserve the necessary information, assistance and access rights in the agreement. The expected effect is to establish which parts of the service can be transferred, which require replacement and how long the institution would remain exposed during transition. Implementation burden is moderate to high because the exercise must include the application and its controls rather than merely export data. Time to effect should be aligned with the acceptance or renewal decision; the test itself should be planned against the actual workload and destination environment instead of an arbitrary universal deadline. Reversibility improves because the institution gains a documented alternative before increasing reliance. A second-order consequence is stronger bargaining power, but a poorly designed requirement can create unnecessary parallel operating costs. The principal risk is a staged demonstration that avoids the difficult dependencies. The receiving team should therefore select representative functions and retain the destination acceptance results. This recommendation follows the continuing interoperability and switching issues identified by the CMA, rather than assuming contractual portability establishes practical substitutability. Update on cloud actions — Competition and Markets Authority — Oct 2026. assets.publishing.service.gov.uk

Course of action: tie support to organisational capability transfer

The fourth proposed course is to combine computational access with defined capability transfer to the receiving organisation. Funding and programme authorities should require a proportionate plan identifying who will operate the application, review its outputs and maintain the necessary records after initial assistance ends. The expected effect is to improve the durability of supported projects and reduce the gap between technically successful pilots and sustained use. Implementation burden is moderate, involving staff time, training and documentation, and the first effects should be assessed within the supported project rather than postponed until programme closure. Reversibility is high for training and reusable documentation, although withdrawing operating support too early can disrupt a promising application. A second-order benefit is a more informed customer base able to distinguish service value from marketing claims. The principal risk is turning support conditions into paperwork that smaller organisations cannot absorb. Requirements should therefore follow the complexity and consequences of the application, with direct assistance where the institution lacks capacity. OECD evidence on adoption barriers supports this emphasis on complementary competence, while it does not establish one universally effective training model. AI and skills: What we know so far — OECD — Jun 2026. oecd.org

Public accountability requires a maintained record of use

A fifth proposed course is to maintain an institutional AI-use record that connects public-facing explanations with the fuller internal evidence needed for oversight. The authority should remain with the deploying institution, which must determine the applicable disclosure requirements and legitimate restrictions. The expected effect is to make responsibility and purpose visible while preserving access to more detailed operational records for authorised reviewers. Implementation burden is moderate where the institution already has a complete application inventory and substantially greater where it must first discover informal or decentralised use. Time to effect should be tied to deployment and material change, with continuing ownership rather than a one-time publication exercise. Reversibility is limited once information has been published, so sensitive material requires review before release. A second-order benefit is improved internal discipline, because maintaining a public description exposes changes in purpose or responsibility that otherwise remain undocumented. The principal risk is publishing a polished description that no longer matches operation. The UK’s Algorithmic Transparency Recording Standard provides a concrete precedent for scoped publication, including defined organisational coverage and treatment of sensitive information; it should not be described as a universal requirement for every public body or every tool. Algorithmic Transparency Recording Standard: Mandatory Scope and Exemptions Policy — UK Government — undated policy text, accessed Nov 2026. GOV.UK

Implementation should follow evidence gates rather than a fixed expansion timetable

The proposed sequence is to establish the portfolio and responsibilities first, evaluate selected applications second, and expand only after the acceptance record supports the additional use. This is a sequence of decisions, not a claim that all institutions can complete the work within the same number of months. The first stage should identify existing commitments and the applications whose consequences justify priority attention. The second should produce a baseline, a bounded test and a reasoned choice among deployment, redesign and termination. The third should connect production approval to operating ownership, change procedures and a practical alternative where continuity or dependence warrants one. Subsequent reviews should examine whether the original benefit remains visible and whether the organisation still possesses the capability to supervise the service. This sequencing avoids spending the whole programme budget before the institution learns which applications are valuable. It also prevents an unsuccessful pilot from becoming a justification for indefinite experimentation: the record should state what further evidence would resolve the uncertainty and whether obtaining it is worth the additional commitment.

Institutional responsibility must include the decision to stop

The final governance requirement is a practicable withdrawal decision. Institutions should specify who can restrict a service, who determines that remediation is sufficient and who can terminate further investment when the expected benefit does not materialise. This responsibility should be separate from the commercial interest of the supplier and the reputational interest of the team that sponsored the application. The proposed review should examine evidence accumulated during use, including adverse results and the effort required to keep the service acceptable. It should also distinguish a temporary problem worth correcting from a persistent mismatch between the application and the institution’s needs. A stop decision can preserve value by retaining reusable data preparation, evaluations and staff knowledge while ending an unsuitable operating arrangement. Equally, excessive caution can prevent useful adoption if every minor change requires a complete restart. The appropriate balance is proportionate review: material changes reopen the relevant decisions, while routine maintenance proceeds within a documented authority and operating envelope.

Institutional function	Decision responsibility	Evidence it should retain
Business owner	Define the intended benefit and acceptable operating consequences	Baseline, operating results and review decisions
Procurement authority	Secure the deliverables, assistance and remedies needed for the arrangement	Contract, acceptance record and change terms
Technical and security functions	Assess the configuration and relevant technical controls	Evaluation results, limitations and unresolved findings
Data and legal functions	Establish the applicable processing and regulatory conditions	Role analysis, data arrangements and legal assessments
Operating owner	Maintain the service within its approved scope	Configuration, incidents and material changes
Independent review function	Challenge the evidence supporting continued reliance	Findings, conflicts of interest and corrective decisions
Accountable executive or governing body	Approve consequential expansion, restriction or withdrawal within its mandate	Recorded decision, rationale and assigned follow-up

The allocation is a proposed governance model. It should be adapted to the institution’s statutory structure, regulated activities and existing delegations.

Key judgments

The preferred course is a controlled portfolio of applications supported by shared expertise, exercised substitution and capability transfer. This combination is feasible because it can begin with existing procurements and support arrangements while preserving the option to expand infrastructure later. Its central discipline is that each increase in reliance requires evidence appropriate to the additional consequences.

What would change the assessment

A more extensive distributed deployment would be justified by sustained benefits, repeatable acceptance results and demonstrated organisational capacity to maintain control across changes. Continued concentration would be more defensible for particular workloads where alternatives fail the same task and assurance conditions at acceptable cost. Neither conclusion should be generalised from one application to the institution’s entire AI portfolio.

Open official record

The principal unresolved records are maintained operating results, completed substitution exercises, the performance of shared evaluation services and evidence of capability retained after initial support. These determine whether an institution has acquired a durable service, a temporary demonstration or a dependency whose consequences remain poorly understood.

Final net assessment

Distributed AI offers a credible path towards wider access, more adaptable service placement and greater institutional choice, provided that distribution is matched by the capacity to evaluate, operate and replace what is deployed. The evidence supports neither an unconditional migration away from concentrated infrastructure nor the assumption that integrated suppliers will indefinitely provide the best arrangement for every task. Through November 2031, the defensible policy is to expand where accepted benefits and accountable operation are demonstrated, retain concentrated resources where workload requirements justify them, and preserve practical alternatives before dependence becomes difficult to reverse. The measure of success is the institution’s sustained ability to perform its functions with acceptable quality and control. Procurement, funding and oversight should make that ability observable, assign responsibility for maintaining it and permit withdrawal when the evidence no longer supports reliance.

---

Copyright of debuglies.com – Even partial reproduction of the contents is not permitted without prior authorization Reproduction reserved