Cloud AI Services versus On-Premises AI: Different Challenges

This chapter compares consuming AI as a cloud service, whether a model API, a managed platform, or a feature embedded in a software-as-a-service product, with running open-weight models on accelerators the organisation controls. Chapter 13 treated placement at the level of infrastructure; this chapter asks what the organisation takes on with each choice, challenge by challenge, so that the choice is deliberate and its obligations are staffed and funded.

Three ways of consuming AI

The binary framing of cloud against on-premises hides most of what matters, because there are three consumption models and responsibilities shift at each boundary. With an AI feature embedded in a SaaS product, such as a drafting assistant in the office suite, the organisation configures a tenant and signs a contract but does not choose the model, see its version, or control when it changes. With a model API or managed AI platform, it builds its own application and owns the prompts, retrieval, evaluation, and gateway, but not the weights or the serving stack. With a self-hosted open-weight model on owned hardware, in colocation, or in a private cloud, it owns every layer from the licence to the incident response.

Amazon Web Services describes the same gradient in its Generative AI Security Scoping Matrix, which orders five scopes from "least ownership to greatest ownership" (196, AWS, n.d.), and most differences in this chapter follow from where a workload sits on it.

Middle paths also exist, such as rented GPU capacity from European operators and sovereign hyperscaler variants; Amazon, for example, launched its AWS European Sovereign Cloud in Brandenburg in January 2026, stating that it is operated exclusively by EU residents (206, Amazon, 2026). That is a vendor claim, and Chapter 13's caution about foreign legal reach still holds.

Cost and its predictability

A model API is operating expenditure that scales with use, so the risk is volume: a looping agent or a rollout to ten thousand users can multiply the bill within a month, as Chapter 22 discusses.

Self-hosting inverts this. The cost is capital expenditure plus people, and the unit cost of a token depends on how busy the hardware is. Patil measured effective cost on identical H100 hardware running vLLM and found it ranged from $0.21 to $15.25 per million output tokens depending on load; at one request per second the cost was 17.5 to 36.3 times the saturated cost (181, Patil, 2026). The paper is a preprint with synthetic workloads, but the direction is clear: a model serving office-hours users runs most of the day at a fraction of capacity and pays for all of it.

Published break-even analyses look favourable until you read their assumptions. Pan and colleagues modelled 54 scenarios and found break-even against commercial APIs within 0.3 to 3 months for small models, 3.8 to 34 months for medium models such as Llama-3.3-70B on dual A100 hardware, and up to five to nine years for large models against aggressively priced APIs (184, Pan et al., 2025). Their model excludes staffing, which in my experience costs more over three years than the hardware, so treat such figures as lower bounds.

Hardware prices are moving against the self-hoster. TrendForce reported in August 2026 that server DRAM contract prices rose a cumulative 64 per cent in the second half of 2025 and were expected to rise by about a further 270 per cent during 2026 (180, TrendForce, 2026). This is an analyst forecast, but an enterprise buying a handful of servers, unlike a hyperscaler, has no long-term agreement to soften it. Cloud cost risk is therefore volume, managed at the gateway, whereas self-hosted cost risk is utilisation and staffing.

Capacity, accelerator supply and power

With a cloud service, capacity is the provider's problem, at the price of shared fate when the provider fails. Self-hosting brings power, cooling, and, for larger deployments, grid connections into the organisation's planning; EirGrid's May 2026 overview records that contracted data centres will be nearly a third of Irish electricity demand once connected (183, EirGrid, 2026). A few inference servers fit in an existing data centre, but capacity cannot be added on the cloud's timescale, so order hardware against a measured forecast and keep a cloud fallback above the owned baseline.

Model change: who controls the version

This is where the two models differ most. A model behind an API is not a fixed artefact: the provider decides when it is retired, with how much notice, and sometimes whether to upgrade it automatically.

OpenAI commits to at least six months' notice for generally available models and announced in June 2026 that gpt-5, o3, and related models would shut down on 11 December 2026 (185, OpenAI, 2026); Anthropic commits to at least 60 days and retired seven models in 2026 up to August (186, Anthropic, 2026). On Amazon Bedrock, after End-of-Life "migration will not happen automatically" (187, AWS, 2026), and Microsoft's Foundry policy of July 2026 retires generally available models at 18 months (12 months for some publishers' models, including Anthropic's), states that retirement dates "aren't extendable", and upgrades standard deployments automatically unless the customer opts out (188, Microsoft, 2026).

A cloud-hosted AI system therefore has a forced migration, and a re-run of the evaluation suite of Chapter 20, built in every one to two years; a pinning policy must name the platform as well as the model; and managed customisation can disappear: OpenAI announced in May 2026 that self-serve fine-tuning would end for new jobs on 6 January 2027 (185, OpenAI, 2026), and Bedrock allows no new fine-tuning once a model is Legacy (187, AWS, 2026). The organisation owns its training data and evaluation results, but not the artefact.

Behaviour can also change without any change to the model identifier. Anthropic's September 2025 postmortem describes infrastructure bugs, one of which at its worst affected 16 per cent of requests to one model in a single hour, with no change of model name (193, Anthropic, 2025). Continuous evaluation in production (Chapter 21) is therefore a requirement for cloud AI. Self-hosting, by contrast, puts the upgrade trigger inside the change management of Chapter 7, not on a provider's deprecation page.

Security and the shared-responsibility split

Consumption model Provider holds Customer holds
AI feature embedded in SaaS Model, hosting, safety filters and upgrades Tenant settings, contract terms and exit
Model API or managed platform Weights, serving stack, patching and default filters Gateway, prompts, evaluation and version pinning
Self-hosted open-weight model Nothing beyond the licence Weights, licence, serving stack and patching; safety filters, capacity, monitoring and incident response

In every model the customer holds data classification and lawful basis, identity, access and keys, and human oversight and acceptable use. Control and burden grow from the first row to the third.

In Microsoft's AI shared-responsibility model, updated in October 2026, hosting the base model and filtering unsafe content are Microsoft's tasks when the model is consumed as a service and the customer's when it self-hosts; data, identity, human-in-the-loop approval, and acceptable use are the customer's in every model (194, Microsoft, 2026). The table above summarises the allocation. The Cloud Security Alliance's AI Controls Matrix, version 1.1 of July 2026, with 247 control objectives across 18 domains, shows per role which controls a self-hosting organisation takes over (195, Bregkou, 2026).

The self-hosted side is where the incidents are. A Cloud Security Alliance research note of May 2026 reports that 31 per cent of queried Ollama servers, 1,652 of more than 5,200, answered unauthenticated prompts (197, CSA, 2026): tools built for a laptop are deployed to servers with their defaults intact. The serving software also has severe vulnerabilities. The US National Vulnerability Database lists a vLLM flaw published in March 2026 that enabled remote code execution from a malicious model repository even when the user had opted out of remote code (173, NVD, 2026), and Cyera reported in May 2026 a heap out-of-bounds read in Ollama's model loader, CVE-2026-7482, scored 9.1 (198, Cyera, 2026).

With self-hosting, the organisation patches this remote-code-execution surface under the exploitation pressure that Chapter 18 describes, and time from advisory to patched server becomes an operational metric. A cloud service, for its part, moves the customer's attack surface to API keys, the gateway, and tenant configuration (Chapter 16).

Data protection, residency and retention terms

On premises, every log, cache, and retention period is the organisation's own decision, and so is the obligation to build those controls and evidence them under Article 5(2) of the GDPR (2, European Union, 2016).

With a cloud service, the terms vary by provider, model, and feature. Anthropic's documentation, read in November 2026, offers inference geography of "global" or "us" on its own platform and no EU-only option, while on Bedrock and Google's Vertex platform the region follows the endpoint (189, Anthropic, 2026). OpenAI offers regional storage and processing in Europe to eligible organisations as a per-project setting, keeps abuse-monitoring logs for up to 30 days unless longer retention is required by law or is reasonably necessary to protect against harm, and makes zero data retention subject to prior approval and additional requirements (190, OpenAI, 2026).

Terms also move after signature: Microsoft's in-country processing for Microsoft 365 Copilot, announced for fifteen countries, was narrowed in April 2026 (191, Lorimer, 2025). Retention promises can also be overridden by third-country litigation: a preservation order in the New York copyright litigation against OpenAI required output logs to be kept until an October 2025 order ended the obligation and excluded logs from requests originating in the EEA, Switzerland, and the United Kingdom (192, SDNY, 2025). Retention terms thus answer to the provider's home jurisdiction.

Treat data terms as configuration to verify per model and feature, check them quarterly, and repeat the transfer analysis of Chapter 13 whenever they change.

Regulatory roles: AI Act, DORA, Data Act and NIS 2

The AI Act. Under Regulation (EU) 2024/1689, an organisation that puts an AI system into service under its own name is its provider however the model is hosted (1, European Union, 2024); hosting matters for the general-purpose AI model obligations. The Commission's guidelines of July 2025 state that a downstream modifier becomes provider of the modified model only if the modification significantly changes its generality, capabilities, or systemic risk, with an indicative criterion of modification compute above one third of the original model's training compute (205, European Commission, 2025). Fine-tuning open weights on your own hardware puts the weights, and the question, squarely with you, so record fine-tuning compute in the lineage from the first experiment.

DORA. For financial entities, Regulation (EU) 2022/2554 treats a model API provider and the supplier of on-premises hardware and software alike as ICT third-party service providers, with register, risk-assessment, and exit obligations (3, European Union, 2022). In November 2025 the European Supervisory Authorities designated 19 critical ICT third-party providers, including the three largest hyperscalers, but no AI model company (204, ESAs, 2025). A model reached directly from its vendor thus sits outside that oversight.

The Data Act. Chapter VI of Regulation (EU) 2023/2854 gives customers of data processing services the right to switch (5, European Union, 2023). The Commission's FAQ of January 2026 states that "from 12 January 2027 onwards, providers will no longer be allowed to charge for switching (including data egress)", and that functional equivalence applies only to infrastructure services (203, European Commission, 2026). My reading is that this gives portability of data but no right to an equivalent model, which the exit plan must supply.

NIS 2. Directive (EU) 2022/2555 lists cloud computing service providers in Annex I, so a cloud AI provider is likely to be in scope in its own right (4, European Union, 2022). Under Article 21, self-hosting changes who implements the controls, not whether they are needed.

Operational burden, lock-in and sustainability

Self-hosting adds capacity scheduling, patching, safety filters, observability, upgrade evaluation, and incident response that a cloud provider would otherwise run. Together these are a platform team, and an organisation that self-hosts without one has not saved the provider's margin but moved the provider's risks to where nobody watches them.

Because a shared provider fails for all its customers at once, give every production AI workload a degraded mode (Chapter 12) and critical workloads a second model on another provider or the organisation's own platform.

Swapping an API endpoint is easy; what binds is prompts tuned to one model, fine-tunes held by the provider, and managed features, such as OpenAI's evaluation platform, which is read-only ahead of its shutdown on 30 November 2026 (185, OpenAI, 2026). Keep prompts, evaluation sets, and fine-tuning data in your own repository. Self-hosting replaces this with licence dependency. The Llama 4 Community License requires a separate licence above 700 million monthly active users (199, Meta, 2025), and the 2026 licence for Mistral Medium 3.5 bars use by a company whose global monthly revenue exceeded $20 million in the preceding month (200, Hugging Face, 2026), so large European enterprises need a commercial licence for that model despite its European origin. Record the exact licence in the model card of Chapter 5, remembering that the Open Source AI Definition demands more than permissive weights (29, OSI, 2024).

Energy follows utilisation, so a penalty of the kind Patil measured for cost (181, Patil, 2026) is likely to apply to energy per token as well, although self-hosting allows direct measurement and a small adequate model. Apply the Software Carbon Intensity specification to self-hosted workloads (30, Green Software Foundation, 2024), ask providers for energy data per unit of service, and see Chapter 22 for the method.

The challenges side by side

Challenge Cloud AI service Self-hosted or private cloud
Cost Operating expenditure; risk is runaway volume Capital plus staff; risk is low utilisation and rising hardware prices
Capacity and power Provider's problem; shared outages Organisation's problem, including power and grid
Model change Provider retires and upgrades on its schedule Organisation fixes the version and owns upgrades
Security Customer secures keys, gateway, and tenant Organisation patches inference servers and controls exposure
Data terms Set per provider and feature; can change Organisation decides and builds controls
AI Act role Provider of the AI system if deployed under own name Same, plus possible model-provider role when fine-tuning
Lock-in Prompts, fine-tunes, and managed features bind Licence conditions bind; hardware is sunk cost

Hybrid patterns

Most large organisations will run both, using four patterns. One gateway in front of both: applications call a logical model name, so moving a workload between tiers is a configuration change. Routing by data class: the gateway routes on data classification and risk class, using the matrix of Chapter 13 as policy, so that special-category or classified data reaches only the self-hosted tier. Self-hosted baseline, burst to cloud: owned capacity is sized for the steady baseline, where utilisation is high, and overflow goes to an evaluated cloud service with equivalent data terms where the data class permits. Sovereign private cloud: a rented operator runs the self-hosted tier, and the gateway treats its jurisdiction as a tested attribute (Chapter 13).

The same patterns reach agentic work tools, which send whatever context they gather to their model; there the routing must be fixed per workspace before the session starts and enforced outside the client. Chapter 15 treats that pattern in full (hybrid agentic work).

Public-sector specifics

European public bodies now face placement rules that distinguish suppliers by jurisdiction, and these reach AI services whether or not they mention AI. The Dutch government announced in July 2026 that critical organisations should avoid providers subject to non-EU or non-EEA law for core tasks and that public cloud is advised against for e-mail and document management (201, Rijksoverheid, 2026), which is exactly what an office-suite AI feature processes. Sweden's cloud policy of May 2026 asks public bodies to assess dependency risks, as guidance (202, Regeringskansliet, 2026), and the Commission's June 2026 proposal for a Cloud and AI Development Act includes an EU-wide sovereignty assessment framework (182, European Commission, 2026).

The direction is consistent: sensitive public functions are steered towards self-hosted or EU-operated AI, so a public body's placement policy must carry the national rule as an explicit input. AI Governance, Chapter 17 treats the wider context.

Putting it into practice

The defaults below suit a large organisation with moderate risk appetite; adapt them to your own risk appetite, sector rules, and legal advice.

Practical guide: placing a workload

Purpose. Decide for each new AI workload whether it runs on a cloud AI service, the organisation's own platform, or a hybrid arrangement, and record why.

Roles. The solution architect proposes; the data protection officer confirms the data class; the platform owner confirms readiness; the AI governance board approves high-risk and public-sector cases.

Decision flow for placing an AI workload: exclusion, evaluation, capability, volume and service-terms questions lead to self-hosting, hybrid, cloud or decline

Figure 14.1: A workload enters with its data class and risk class; exclusion rules lead to self-hosting if an open-weight model passes evaluation, capability needs lead to a cloud service if its terms pass, steady volume leads to a hybrid pattern, and every placement is recorded in an AI decision record with a review date.

  1. Register the workload with its data class, its risk class from AI Governance, Chapter 8, its volume profile, and any sector or national rule.
  2. Apply exclusion rules first. If external processing is excluded, the options are self-hosting or redesign.
  3. For self-hosting, evaluate at least two licence-compatible open-weight models with the suite of Chapter 20. If none passes, minimise the data, change the design, or decline.
  4. If the task needs capability available only as a service, take the cloud route, subject to step 6.
  5. Otherwise, expected average utilisation of at least 40 per cent of an inference node, plus a platform that has passed the readiness gate below, favours a self-hosted baseline with cloud burst.
  6. Check any cloud route against the controls in the third guide.
  7. Record the placement, reasons, and review date in an AI Decision Record (Chapter 5), and generate the gateway configuration from it.
# placement-policy.yaml - evaluated at intake; adapt thresholds to risk appetite
apiVersion: ai-platform.example.org/v1
kind: WorkloadPlacementPolicy
metadata:
  name: default-placement
  owner: enterprise-architecture
rules:
  - id: P1-excluded-external
    when:
      any:
        - data_class: [special-category, classified, base-registry]
        - public_sector_rule: no-non-eu-law-provider
    place: self_hosted
    require: [open_weight_eval_passed, licence_reviewed]
    otherwise: redesign-or-decline
  - id: P2-capability-only-as-service
    when: {capability_only_as_service: true}
    place: cloud_service
    require: [cloud_controls_passed, gateway_routed, exit_plan]
  - id: P3-steady-volume
    when:
      all:
        - expected_avg_utilisation_gte: 0.40
        - self_hosting_readiness: passed
    place: self_hosted
    burst_to: cloud_service
    burst_requires: [cloud_controls_passed, same_data_class_permitted]
  - id: P4-default
    place: cloud_service
    require: [cloud_controls_passed, gateway_routed]
record:
  decision_record: required
  re_evaluate_on: [model_retirement_notice, terms_change, data_class_change]

Definition of done. An approved AI Decision Record names the placement, the rule that produced it, and a review date; the gateway routes the workload only to the permitted tier; and a retirement notice, terms change, or data-class change triggers re-evaluation automatically.

Worked example: a cloud versus on-premises decision matrix

Illustrative example. Hansa Mutual, whose EU entities fall under DORA, wants to summarise incoming claims correspondence for its handlers: about 40,000 claims a month, steady during business hours, in four languages. Roughly a fifth are injury claims containing health data, a special category under Article 9 of the GDPR. The architect scores each option from 1 (poor) to 5 (good).

Criterion Weight Cloud model API, EU region Score Self-hosted open-weight model Score
Data class and legal rules 3 Health data needs zero retention, which this model does not offer 2 Data stays in Hansa's data centre 5
Cost at expected volume 2 Predictable per claim 4 45 per cent utilisation on two nodes; staff included 3
Model change 2 Retirement within 18 months 2 Upgrades on Hansa's schedule 4
Security and operations 2 Provider patches 4 Platform team exists; patch SLA required 3
Capability 2 Best summary quality: 0.91 5 Passes threshold of 0.85: 0.88 4
DORA and exit 2 Direct vendor contract outside CTPP oversight 2 Hardware supplier already in DORA register 4
Weighted total 40 51

Rule P1 already routes injury claims to the self-hosted tier, and the scores favour self-hosting for the rest, so the decision is a self-hosted baseline for all claims, with cloud burst permitted only for claims without health data and only after the cloud service passes the controls guide; the decision record cites rule P3 and sets a review twelve months out.

Practical guide: readiness check before self-hosting a model

Purpose. Establish, before the first self-hosted model reaches production, that the organisation can run it safely.

Roles. The platform owner is accountable; security, evaluation, facilities, and legal sign off their items.

  1. Licence. Check the exact model's licence and record it in the model card.
  2. Exposure. Bind inference servers to a private interface behind the AI gateway, and verify by external scan that no model endpoint answers.
  3. Patching. Subscribe to advisories for the serving engine, model loader, and drivers. Default: seven days for critical vulnerabilities, 24 hours where exploitation is known.
  4. Provenance. Load weights only from the internal registry, signed and in a safe format, with remote-code options disabled.
  5. Safety filtering and upgrades. Configure and evaluate the input and output filters a provider would supply, and re-run the evaluation suite on every model, driver, or serving-engine upgrade.
  6. Operations and capacity. Connect monitoring (Chapter 21), name an on-call rota, and confirm power and a measured forecast.
  7. Regulatory record. Log fine-tuning compute in the lineage and confirm the AI Act and, where relevant, DORA position.
# self-hosting-readiness.yaml - all items must pass before production
gate: self-hosting-readiness
platform: onprem-se-1
checks:
  licence_reviewed: {owner: legal, evidence: model-card#licence}
  no_unauthenticated_endpoint: {owner: security, test: external-scan, expect: zero-open}
  patch_sla_days: {critical: 7, known_exploited: 1}
  weights_from_registry_only: {signed: true, format: safetensors, trust_remote_code: false}
  safety_filters_evaluated: {owner: evaluation, suite: safety-baseline}
  monitoring_connected: {owner: platform, on_call: required}
  capacity_confirmed: {power_kw_per_rack: required, cloud_fallback: required}

Definition of done. Every check has an owner and evidence in the architecture repository, an external scan finds no unauthenticated model endpoint, and the platform is in the runbooks and on-call rota before the first production request.

Practical guide: contract and configuration controls before relying on a cloud AI service

Purpose. Confirm, before a production workload depends on a cloud AI service, that its terms and configuration meet requirements on retention, residency, versions, deprecation, and exit.

Roles. Procurement owns the contract; security and data protection verify the configuration; the solution architect owns the exit plan.

  1. Retention. Record retention for prompts, outputs, and abuse-monitoring logs per model and feature. Default: at most 30 days, no training use, stateful features off unless approved.
  2. Residency. Record processing and storage regions per model on the specific platform. Default: EU or EEA for personal data, with exceptions in the transfer assessment of Chapter 13.
  3. Version pinning. Use dated versions, disable automatic upgrades where possible, and keep preview models out of production.
  4. Deprecation and notification. Record the minimum notice, subscribe the owning team to announcements, and require notice of material changes. Default: six months for generally available models.
  5. Exit. Keep prompts, evaluation sets, and fine-tuning data in your repository, name an evaluated substitute model, and test the switch annually.
  6. Regulatory position. Record the provider's NIS 2 status and, for financial entities, whether it is a designated critical provider.
# cloud-ai-service-controls.yaml - one file per service and platform
service: example-model-api
platform: hyperscaler-eu-region
models:
  - {id: example-model-2026-09-15, auto_upgrade: disabled}
controls:
  retention: {prompts_outputs_days_max: 30, training_use: prohibited, stateful_features: disabled-unless-approved}
  residency: {processing: eu, storage: eu}
  versioning: {preview_models_in_production: false}
  deprecation: {min_notice_days_ga: 180, subscribed_team: ai-platform}
  exit:
    assets_in_own_repository: [prompts, eval_sets, finetune_data]
    substitute_model: self-hosted/open-weight-candidate
    switch_test_interval_days: 365
  regulatory: {dora_register_entry: required-if-financial-entity, nis2_status: recorded}
review: {on_terms_change: true, interval_days: 90}

Definition of done. The controls file is approved in the architecture repository, the deployed configuration matches it, the substitute model has passed evaluation, and the quarterly review confirms the provider's terms are unchanged since approval.

Across the usage modes

The choice between cloud and on-premises consumption is a real decision only in some of the usage modes of Chapter 2 (usage-mode matrix).

Mode Consumption Is placement a decision?
Mode 0 – Ambient AI SaaS, inside supplier software No; govern through the contract
Mode 1 – Conversational assistants SaaS Mostly no; a self-hosted chat service is the alternative
Mode 2 – Embedded workplace assistants SaaS tenant No; fixed by the suite
Mode 3 – Agentic work tools Cloud API, sometimes local models Partly: routed per workspace (Chapter 15)
Mode 4 – Built AI applications API, managed platform or self-hosted Yes; the full analysis applies
Mode 5 – Autonomous production agents As Mode 4 Yes, with fallback capacity weighted for continuity

Placement is answered per workload in Modes 4 and 5 and per data class in the others.

Nordvik Region and Hansa Mutual

Nordvik Region runs its case-note summariser for 180 social-services caseworkers on its own platform under rule P1, on two nodes in separate data centres with all egress denied and overflow queued rather than burst to the cloud. Its challenge is skills and capacity: a small team must patch, evaluate, and upgrade models it would otherwise buy. Cloud services remain its choice for workloads without sensitive data, procured under the placement rules for public bodies described above.

Hansa Mutual uses both, routing by classification: sensitive information goes only to self-hosted models in Frankfurt, while less sensitive work may burst to a hyperscaler's EU region under a baseline checked nightly for drift, and its engineers' agentic work tools follow the same routing, as Chapter 15 shows. Jurisdiction adds a second axis: the burst tier suits the EU entities, whose DORA register records the provider (3, European Union, 2022), but crosses the UK and Swiss entities' transfer rules (248, UK Parliament, 2018), (244, Swiss Confederation, 2020), so the routing policy carries the market of origin and keeps their sensitive data on self-hosted capacity.

Summary

Cloud AI services and self-hosted AI present different challenges, not a simple trade between convenience and control. A cloud service brings volume risk and the provider's schedule for retirements and data terms; self-hosting brings utilisation and staffing risk, control of the version, and servers to patch, licences to read, and power to secure. Data, identity, human oversight, and acceptable use remain the customer's in every model, and the AI Act, DORA, the Data Act, and NIS 2 draw their lines differently. Most organisations will therefore combine both behind one gateway, with the placement policy, readiness gate, and cloud controls making that combination a recorded decision.

Chapter 15, which completes Part III, applies these patterns where they are hardest to hold: agentic work tools on the desks of engineers, analysts, and operators.

Sources

  1. Amazon Web Services. Generative AI Security Scoping Matrix. aws.amazon.com, undated. (196, AWS, n.d.)
  2. Amazon (2026). AWS Launches AWS European Sovereign Cloud and Announces Expansion Across Europe. Amazon press release, 15 January 2026. (206, Amazon, 2026)
  3. Patil, C. (2026). Beyond Per-Token Pricing: A Concurrency-Aware Methodology for LLM Infrastructure Cost Estimation. arXiv:2606.11690 (preprint), June 2026. (181, Patil, 2026)
  4. Pan, G., Chodnekar, V., Roy, A. & Wang, H. (2025). A Cost-Benefit Analysis of On-Premise Large Language Model Deployment: Breaking Even with Commercial LLM Services. arXiv:2509.18101v3 (preprint), 11 November 2025. (184, Pan et al., 2025)
  5. TrendForce (2026). Memory Prices Soar; DRAM and NAND Flash to Account for 68% of Major CSP CapEx in 2027, Says TrendForce. TrendForce press centre, 25 August 2026. (180, TrendForce, 2026)
  6. EirGrid (2026). Data Centre Constrained Area Overview. EirGrid, May 2026. (183, EirGrid, 2026)
  7. OpenAI (2026). Deprecations. OpenAI API documentation, latest entry 14 October 2026. (185, OpenAI, 2026)
  8. Anthropic (2026). Model deprecations. Claude Platform documentation, latest entry 30 September 2026. (186, Anthropic, 2026)
  9. Amazon Web Services (2026). Model lifecycle. Amazon Bedrock User Guide, policy for models launched on or after 7 September 2026. (187, AWS, 2026)
  10. Microsoft (2026). Foundry Models lifecycle and support policy. Microsoft Learn, 24 July 2026. (188, Microsoft, 2026)
  11. Anthropic (2025). A postmortem of three recent issues. Anthropic Engineering, 17 September 2025. (193, Anthropic, 2025)
  12. Microsoft (2026). Artificial intelligence shared responsibility model and AI agent shared responsibility model. Microsoft Learn, August 2026, updated 8 October 2026. (194, Microsoft, 2026)
  13. Bregkou, M. (2026). AI Controls Matrix v1.1: Strengthening the Foundation for Trustworthy AI. Cloud Security Alliance, 14 July 2026. (195, Bregkou, 2026)
  14. Cloud Security Alliance AI Safety Initiative (2026). Exposed AI Infrastructure: Self-Hosted Services Under Attack. CSA Labs research note, 7 May 2026. (197, CSA, 2026)
  15. National Vulnerability Database (2026). CVE-2026-27893: vLLM model files hardcode trust_remote_code=True. NIST NVD, published 27 March 2026. (173, NVD, 2026)
  16. Cyera Research (2026). Bleeding Llama: A Critical Memory Leak in the World's Most Popular Local AI Platform. Cyera, 5 May 2026; with NIST NVD, CVE-2026-7482, 4 May 2026. (198, Cyera, 2026)
  17. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)
  18. Anthropic (2026). Data residency and API and data retention. Claude Platform documentation, living pages read 1 November 2026. (189, Anthropic, 2026)
  19. OpenAI (2026). Data controls in the OpenAI platform. OpenAI API documentation, living page read 1 November 2026. (190, OpenAI, 2026)
  20. Lorimer, P. (2025). Microsoft offers in-country data processing to 15 countries to strengthen sovereign controls for Microsoft 365 Copilot. Microsoft 365 Blog, 4 November 2025, editor's note of 3 April 2026. (191, Lorimer, 2025)
  21. United States District Court for the Southern District of New York (2025). Stipulation and Order to Terminate OpenAI's Ongoing Obligations under the Preservation Order at ECF 33. In re OpenAI, Inc. Copyright Infringement Litigation, 25-md-03143, Document 922, 9 October 2025. (192, SDNY, 2025)
  22. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  23. European Commission (2025). Guidelines on the scope of the obligations for general-purpose AI models established by Regulation (EU) 2024/1689 (AI Act). Annex to C(2025) 5045 final, 18 July 2025. (205, European Commission, 2025)
  24. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  25. European Supervisory Authorities: EBA, EIOPA and ESMA (2025). European Supervisory Authorities designate critical ICT third-party providers and List of designated CTPPs. ESMA, 18 November 2025. (204, ESAs, 2025)
  26. European Parliament and Council of the European Union. Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act). Official Journal of the European Union, 22 December 2023. (5, European Union, 2023)
  27. European Commission (2026). Frequently Asked Questions – Data Act, version 1.4. 22 January 2026. (203, European Commission, 2026)
  28. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (4, European Union, 2022)
  29. Meta Platforms (2025). Llama 4 Community License Agreement. 5 April 2025. (199, Meta, 2025)
  30. Hugging Face (2026). Model cards and licence files for google/gemma-4-31B-it, mistralai/Mistral-Medium-3.5-128B, mistralai/Mistral-Large-3-675B-Instruct-2512, Qwen/Qwen3-8B, Qwen/Qwen3.8-27B and openai/gpt-oss-120b. huggingface.co, read 1 November 2026. (200, Hugging Face, 2026)
  31. Open Source Initiative. The Open Source AI Definition, version 1.0. 28 October 2024. (29, OSI, 2024)
  32. Green Software Foundation. Software Carbon Intensity (SCI) Specification (ISO/IEC 21031:2024).. (30, Green Software Foundation, 2024)
  33. Rijksoverheid (2026). Strengere regels voor het gebruik van clouddiensten door de Rijksoverheid. Ministerie van Economische Zaken en Klimaat, 3 July 2026. (201, Rijksoverheid, 2026)
  34. Regeringskansliet (2026). Ny molnpolicy ska bidra till ökad digital suveränitet i offentlig förvaltning. Finansdepartementet, 28 May 2026, with the policy En molnpolicy för Sverige. (202, Regeringskansliet, 2026)
  35. European Commission (2026). Proposal for the Cloud and AI Development Act (CADA). COM(2026) 502, 3 June 2026. (182, European Commission, 2026)
  36. United Kingdom (2018). Data Protection Act 2018 (c. 12), with the UK General Data Protection Regulation. (248, UK Parliament, 2018)
  37. Swiss Federal Assembly (2020). Federal Act of 25 September 2020 on Data Protection (Data Protection Act, FADP), SR 235.1. Fedlex, in force 1 September 2023. (244, Swiss Confederation, 2020)