[{"data":1,"prerenderedAt":526},["ShallowReactive",2],{"footer":3,"listing:projects":43},{"id":4,"title":5,"author":6,"body":7,"date":6,"description":35,"extension":36,"meta":37,"navigation":38,"path":39,"seo":40,"status":6,"stem":41,"__hash__":42},"pages\u002Ffooter.md","Footer",null,{"type":8,"value":9,"toc":31},"minimark",[10],[11,12,13,14,21,22,26,27,30],"p",{},"Hosted at the Center for Language and Speech Technology (CLST) at Radboud University and supported by the Dutch Research Council. Website design & development © 2026 by ",[15,16,20],"a",{"href":17,"rel":18},"https:\u002F\u002Fwww.bstn.nl",[19],"nofollow","BSTN",". This version of the index generated ",[23,24],"versionlink",{"repo":25},"data",", website content last updated ",[23,28],{"repo":29},"website",".",{"title":32,"searchDepth":33,"depth":33,"links":34},"",2,[],"Hosted at the Center for Language and Speech Technology (CLST) at Radboud University and supported by the Dutch Research Council. Website design & development © 2026 by BSTN. This version of the index generated , website content last updated .","md",{},true,"\u002Ffooter",{"description":35},"footer","7Qh-i2kmD_zE-5kAib-fTmn3mu7iahT60fikvrwHzyc",[44,215,371],{"id":45,"title":46,"author":47,"body":48,"date":207,"description":208,"extension":36,"meta":209,"navigation":38,"path":210,"seo":211,"status":212,"stem":213,"__hash__":214},"pages\u002Fprojects\u002Fsovereign-ai-infrastructure.md","Sovereign AI infrastructure","AI Infrastructure Lab",{"type":8,"value":49,"toc":196},[50,53,56,69,74,77,80,83,87,90,93,96,105,109,112,115,118,121,125,128,131,134,138,141,144,147,151,154,157,160,164,167,170,173,177,180,183,187,190,193],[11,51,52],{},"This project compares how governments, universities, and public institutions define and operationalise AI sovereignty. Sovereignty is often invoked as a policy ambition, but it can refer to many different things: domestic cloud capacity, public compute, data governance, local model development, procurement autonomy, standards participation, or reduced dependence on foreign technology providers.",[11,54,55],{},"We study how these ambitions become infrastructure. A sovereignty strategy is not only a document or funding programme. It is expressed through contracts, facilities, standards, procurement rules, research partnerships, energy systems, and institutional capabilities. The project follows those material choices to understand what forms of autonomy are actually being built.",[57,58,59,60,59,65],"figure",{},"\n  ",[61,62],"img",{"src":63,"alt":64},"\u002Fimages\u002Fservers3-web.webp","Dense computing infrastructure with cables and server hardware",[66,67,68],"figcaption",{},"Sovereign AI infrastructure depends on practical control over facilities, procurement, data flows, standards, and technical expertise, not only national strategy documents.",[70,71,73],"h2",{"id":72},"research-focus","Research focus",[11,75,76],{},"The project compares different models of AI sovereignty. Some approaches emphasise national compute capacity and public investment in high-performance infrastructure. Others focus on trusted cloud procurement, open-source software, data spaces, sector-specific platforms, or regulatory alignment. Each model creates different dependencies and different forms of institutional capability.",[11,78,79],{},"We ask what is meant by sovereignty in each case, which actors are expected to provide it, and what technical arrangements support it. We also examine where sovereignty claims become ambiguous. A government may fund local infrastructure that relies on imported chips, foreign cloud software, external maintenance contracts, or global developer ecosystems. These dependencies do not necessarily make sovereignty impossible, but they need to be described precisely.",[11,81,82],{},"The project treats sovereignty as a gradient rather than a fixed status. Institutions can have more control over some layers of the AI stack and less over others. They may control data but not compute, procurement rules but not software maintenance, or research infrastructure but not deployment platforms. Mapping these layers makes the debate more concrete.",[70,84,86],{"id":85},"from-policy-ambition-to-operational-control","From policy ambition to operational control",[11,88,89],{},"Sovereignty language often compresses several goals into one term. It can mean strategic autonomy, economic competitiveness, national security, data protection, public-sector bargaining power, research independence, democratic accountability, or resilience against geopolitical disruption. These goals may overlap, but they are not identical. A strategy that improves one form of sovereignty may leave another untouched.",[11,91,92],{},"For example, a country may attract a major cloud region and describe it as sovereign capacity. That may improve latency, data-residency options, and local service availability. It may not provide control over hardware supply, software roadmaps, pricing, audit rights, or emergency access. Another country may invest in a public research cluster that offers stronger academic control but less commercial scalability. Both are infrastructure choices, but they solve different problems.",[11,94,95],{},"The project therefore asks institutions to define sovereignty in operational terms. What decisions should public actors be able to make? What systems must they be able to inspect? What services must they be able to continue if a vendor changes terms? What data must remain under specific legal or institutional controls? What expertise must be maintained internally rather than outsourced?",[57,97,59,98,59,102],{},[61,99],{"src":100,"alt":101},"\u002Fimages\u002FHyperscaler-example-image-1.jpeg","Industrial data centre infrastructure and server systems",[66,103,104],{},"AI sovereignty strategies often meet existing cloud and data centre markets, where public ambitions are negotiated through commercial facilities and long-term contracts.",[70,106,108],{"id":107},"method","Method",[11,110,111],{},"Our research combines policy analysis, infrastructure mapping, and comparative case studies. We analyse national AI strategies, public procurement frameworks, cloud agreements, research infrastructure plans, standards initiatives, and public compute programmes. We also track how sovereignty language changes across policy domains, from economic competitiveness to security, education, research, and public-sector modernisation.",[11,113,114],{},"Interviews and document analysis help connect policy claims to operational details. We are interested in who makes infrastructure decisions, what constraints they face, how public institutions evaluate vendor dependence, and how technical requirements are translated into procurement and governance processes.",[11,116,117],{},"The project compares strategies across several institutional settings. National governments tend to frame sovereignty through competitiveness, security, and industrial policy. Universities and research infrastructures often focus on access, reproducibility, scientific autonomy, and long-term stewardship. Public agencies may prioritise procurement rules, data protection, service reliability, and accountability. Regional institutions may emphasise economic development, local capacity, and alignment with wider regulatory frameworks.",[11,119,120],{},"By comparing these settings, we can identify recurring patterns. Sovereignty claims often become more concrete when they reach procurement teams, infrastructure managers, legal departments, and research computing staff. These actors must translate broad ambition into contracts, access controls, staffing plans, service-level expectations, and budget lines.",[70,122,124],{"id":123},"layers-of-sovereignty","Layers of sovereignty",[11,126,127],{},"The project uses a layered model of AI infrastructure. The compute layer includes chips, servers, clusters, data centres, cloud regions, and high-performance computing facilities. The data layer includes data governance, storage location, access controls, sharing agreements, and sector-specific data spaces. The software layer includes operating systems, orchestration tools, model-serving frameworks, monitoring systems, and security tooling.",[11,129,130],{},"The model layer includes foundation models, fine-tuned models, evaluation methods, documentation, safety systems, and licensing terms. The procurement layer includes vendor selection, contract duration, exit rights, auditability, switching costs, and compliance requirements. The expertise layer includes the public-sector capacity to evaluate systems, negotiate contracts, maintain infrastructure, and respond to failures. The governance layer includes accountability mechanisms, standards participation, public oversight, and institutional decision-making.",[11,132,133],{},"Different strategies strengthen different layers. A public compute programme may improve the compute and expertise layers while leaving software dependencies unresolved. A trusted cloud procurement framework may improve compliance and contractual governance while maintaining dependence on commercial platforms. An open-source model strategy may improve adaptation and transparency while still requiring external compute and maintenance capacity.",[70,135,137],{"id":136},"tensions-and-trade-offs","Tensions and trade-offs",[11,139,140],{},"Sovereign AI infrastructure involves trade-offs. Full domestic control over every layer may be unrealistic, slow, or prohibitively expensive. Complete reliance on global cloud providers may be efficient in the short term but can weaken bargaining power, auditability, and resilience. Hybrid models can be pragmatic, but they need clear governance so that dependencies are visible rather than hidden behind sovereignty branding.",[11,142,143],{},"Cost is one tension. Public infrastructure requires long-term funding for hardware refreshes, facility operations, security, staffing, and software maintenance. A one-time capital investment may produce a strong announcement but weak operational capacity if ongoing budgets are missing. Another tension is expertise. Institutions cannot exercise meaningful control over infrastructure they do not understand, even if contracts assign them formal rights.",[11,145,146],{},"There is also a tension between openness and security. Public institutions may benefit from open-source systems and shared research infrastructure, but some applications require restricted access, compliance controls, or national-security considerations. The project does not assume that one model fits all cases. Instead, it asks which form of control is appropriate for each use case.",[70,148,150],{"id":149},"procurement-as-infrastructure-policy","Procurement as infrastructure policy",[11,152,153],{},"Procurement is one of the most important sites where AI sovereignty becomes practical. Contract terms can determine whether public institutions can audit systems, move workloads, access logs, control data flows, understand subcontracting arrangements, or maintain services during disruption. Procurement can also shape markets by rewarding interoperability, transparency, and public-interest requirements.",[11,155,156],{},"Yet procurement teams often work under pressure to deliver services quickly, control costs, and comply with complex legal frameworks. They may not have the technical support needed to evaluate AI infrastructure dependencies. The project studies how procurement processes can be improved without turning every acquisition into an unrealistic exercise in full-stack self-sufficiency.",[11,158,159],{},"We pay particular attention to exit rights, portability, documentation, data access, model governance, and security responsibilities. These details are easy to treat as legal boilerplate, but they determine whether sovereignty claims survive contact with operational reality.",[70,161,163],{"id":162},"policy-relevance","Policy relevance",[11,165,166],{},"AI sovereignty is becoming a key term in European and national policy debates, but vague use of the term can obscure difficult trade-offs. Building everything domestically may be unrealistic or inefficient. Depending entirely on external providers may create unacceptable risks. Public institutions therefore need sharper language for describing which capabilities matter, which dependencies are acceptable, and which require intervention.",[11,168,169],{},"This project helps separate symbolic sovereignty from operational sovereignty. Symbolic sovereignty appears in announcements and labels. Operational sovereignty depends on whether institutions can inspect systems, switch providers, govern data, maintain expertise, negotiate contracts, and sustain infrastructure over time.",[11,171,172],{},"The work is relevant to public agencies, universities, research infrastructures, and policy teams that need to make decisions about cloud procurement, model deployment, open-source adoption, and compute investment. It provides a way to evaluate infrastructure choices before they become long-term dependencies.",[70,174,176],{"id":175},"working-framework","Working framework",[11,178,179],{},"The project is developing a practical framework for assessing sovereignty claims. The framework asks which layer of the AI stack is being controlled, which actor holds that control, what evidence supports the claim, what dependencies remain, and what mechanisms exist for accountability. It also asks what would happen under stress: vendor withdrawal, price increases, geopolitical disruption, security incidents, hardware shortages, or regulatory change.",[11,181,182],{},"This stress-test approach is useful because infrastructure autonomy is most meaningful during constraint. A system that works only when markets are stable and vendors are cooperative may still be useful, but it should not be described as a robust sovereign capability. Conversely, a smaller system with clear governance, skilled operators, and realistic continuity plans may provide more meaningful autonomy for specific public tasks.",[70,184,186],{"id":185},"outputs","Outputs",[11,188,189],{},"The project will produce comparative reports, policy briefs, and a layered framework for analysing AI sovereignty. The framework will describe sovereignty across compute, data, software, models, standards, procurement, expertise, and governance.",[11,191,192],{},"We will also publish short case studies showing how sovereignty is operationalised in different institutional settings. These cases will identify practical patterns, recurring constraints, and opportunities for public-interest infrastructure that is accountable, maintainable, and technically realistic.",[11,194,195],{},"Later outputs will include a procurement checklist, a glossary of sovereignty claims, and a set of diagrams that help public institutions distinguish ownership, access, control, resilience, and accountability.",{"title":32,"searchDepth":33,"depth":33,"links":197},[198,199,200,201,202,203,204,205,206],{"id":72,"depth":33,"text":73},{"id":85,"depth":33,"text":86},{"id":107,"depth":33,"text":108},{"id":123,"depth":33,"text":124},{"id":136,"depth":33,"text":137},{"id":149,"depth":33,"text":150},{"id":162,"depth":33,"text":163},{"id":175,"depth":33,"text":176},{"id":185,"depth":33,"text":186},"2026-03-04","Comparing national and regional strategies for AI sovereignty through cloud procurement, public compute, standards, and research infrastructure.",{},"\u002Fprojects\u002Fsovereign-ai-infrastructure",{"title":46,"description":208},"published","projects\u002Fsovereign-ai-infrastructure","szIMcCnoDa11pstZeJmriLQL5hU1dtA-mE7nNdCc3jE",{"id":216,"title":217,"author":47,"body":218,"date":364,"description":365,"extension":36,"meta":366,"navigation":38,"path":367,"seo":368,"status":212,"stem":369,"__hash__":370},"pages\u002Fprojects\u002Fopen-model-supply-chains.md","Open model supply chains",{"type":8,"value":219,"toc":353},[220,223,226,235,237,240,243,246,250,253,256,259,263,266,269,272,281,283,286,289,292,295,299,302,305,308,312,315,318,321,323,326,329,332,336,339,342,344,347,350],[11,221,222],{},"This project examines what has to be in place for open AI systems to be produced, maintained, evaluated, and reused. Public debate often treats “open” as a property of a released model: weights are available, code is published, or a license allows certain forms of reuse. We approach openness as a supply chain that depends on many upstream and downstream conditions.",[11,224,225],{},"Open-weight and open-source AI systems rely on datasets, training code, evaluation pipelines, model documentation, hosting infrastructure, developer communities, safety practices, and long-term maintenance. Some of these elements are visible in repositories and model cards. Others are distributed across organisations, labour arrangements, funding sources, compute access, and informal norms.",[57,227,59,228,59,232],{},[61,229],{"src":230,"alt":231},"\u002Fimages\u002Fservers2-web.webp","Server infrastructure used for computational workloads",[66,233,234],{},"Open models still depend on scarce infrastructure: compute clusters, storage, evaluation environments, and hosting systems that shape who can build and reuse them.",[70,236,73],{"id":72},[11,238,239],{},"The project investigates the practical infrastructure of openness. We ask what resources are required to reproduce, adapt, evaluate, and govern open AI systems after publication. This includes technical artefacts such as checkpoints and training scripts, but also organisational artefacts such as funding models, moderation policies, contribution processes, and maintenance routines.",[11,241,242],{},"Our starting point is that open release does not automatically create open capability. A model may be downloadable but impossible for most organisations to inspect, fine-tune, or deploy responsibly. A repository may contain code but lack the data lineage, compute budget, or evaluation detail needed for meaningful reuse. A permissive license may enable experimentation while leaving accountability questions unresolved.",[11,244,245],{},"We therefore study openness across the full model lifecycle: data collection, training, release, evaluation, deployment, community adaptation, and retirement. This lifecycle view helps identify where openness is strong, where it is partial, and where it depends on invisible forms of labour or infrastructure.",[70,247,249],{"id":248},"openness-as-a-supply-chain","Openness as a supply chain",[11,251,252],{},"The supply chain begins before training. Data must be collected, filtered, deduplicated, labelled, licensed, documented, and stored. Those processes involve legal assumptions, cultural judgements, moderation decisions, and labour that may be poorly documented. When a model is released without sufficient information about its data history, downstream users inherit uncertainty even if the weights are technically accessible.",[11,254,255],{},"Training introduces another set of dependencies. Open projects need compute budgets, accelerator access, distributed training expertise, experiment tracking, checkpoint storage, and failure recovery. If only a small number of organisations can afford to produce the base models that everyone else adapts, then openness at the release layer may coexist with concentration at the production layer.",[11,257,258],{},"After release, the supply chain continues through hosting, inference optimisation, fine-tuning libraries, safety filters, benchmarking tools, community documentation, integration examples, and support channels. Many users encounter an open model through a platform interface rather than through a local deployment. In those cases, open artefacts may travel through closed hosting, proprietary optimisation layers, or commercial terms of service.",[70,260,262],{"id":261},"research-questions","Research questions",[11,264,265],{},"This project asks how open models become usable infrastructure rather than isolated artefacts. What information is needed to assess a model’s training history, limitations, and appropriate uses? Which parts of the release are reproducible in practice? Who maintains the libraries, datasets, evaluation suites, and deployment recipes that make the model usable? What happens when maintainers leave, funding ends, or a community shifts attention to a newer release?",[11,267,268],{},"We also ask how openness affects accountability. If a model is adapted by thousands of downstream actors, who is responsible for documenting changes, reporting harms, correcting vulnerabilities, or communicating limitations? Where should governance sit: with the original model producer, the hosting platform, the fine-tuner, the deployer, or the community that maintains shared tools?",[11,270,271],{},"These questions are especially important for public-interest organisations. Universities, public agencies, journalists, civic technologists, and small companies may turn to open models because they promise control and transparency. The project examines when that promise is real, when it is partial, and when it depends on forms of infrastructure that are not themselves open.",[57,273,59,274,59,278],{},[61,275],{"src":276,"alt":277},"\u002Fimages\u002FHyperscaler-example-image-2.jpeg","Data centre and server equipment used for cloud infrastructure",[66,279,280],{},"Open model ecosystems are shaped by commercial infrastructure as well as community practice: hosting, distribution, and inference often remain tied to large-scale platform providers.",[70,282,108],{"id":107},[11,284,285],{},"The project combines repository analysis, documentation review, interviews, and case studies of prominent open AI initiatives. We examine model cards, licenses, issue trackers, evaluation reports, dataset documentation, governance statements, and community practices. We also compare how different projects define openness and how those definitions change when models move from research artefacts to deployed systems.",[11,287,288],{},"This work pays close attention to maintenance. Many discussions of open AI focus on the moment of release, but the long-term value of an open system depends on updates, vulnerability response, dataset corrections, documentation improvements, and community support. Maintenance is where the social organisation of openness becomes visible.",[11,290,291],{},"Repository analysis allows us to trace how projects are organised. We look at contribution patterns, dependency management, issue resolution, release notes, reproducibility claims, and links between model artefacts and supporting code. Documentation review helps identify what is explained, what is missing, and what assumptions are made about the expertise of downstream users.",[11,293,294],{},"Interviews add context that public repositories cannot provide. We speak with maintainers, researchers, infrastructure providers, public-sector adopters, and community contributors about the practical work of keeping open systems usable. These conversations focus on constraints: compute costs, legal uncertainty, abuse response, benchmark pressure, documentation debt, funding gaps, and the difficulty of coordinating distributed contributors.",[70,296,298],{"id":297},"degrees-of-openness","Degrees of openness",[11,300,301],{},"One of the project’s goals is to move beyond a binary distinction between open and closed systems. We distinguish between access to weights, access to code, access to training data, access to evaluation methods, access to deployment tools, and access to governance processes. A system may be open in one dimension and closed in another.",[11,303,304],{},"For example, a project may publish model weights and inference code but keep the training dataset undisclosed. Another may release detailed documentation but restrict commercial use. A third may publish everything needed for local experimentation while relying on a closed platform for practical distribution. These differences matter because they shape what users can audit, adapt, reproduce, and contest.",[11,306,307],{},"The project also considers temporal openness. A model can be open at release but become difficult to use later if dependencies break, links disappear, hardware requirements become impractical, or maintainers stop responding. Long-term openness requires stewardship, not just publication.",[70,309,311],{"id":310},"labour-and-community-governance","Labour and community governance",[11,313,314],{},"Open model ecosystems depend on labour that is often undervalued. Documentation writers, dataset curators, safety evaluators, issue triagers, benchmark maintainers, infrastructure volunteers, and community moderators all contribute to whether an open model is usable. Their work may be distributed across institutions and time zones, and it may not be captured in formal project metrics.",[11,316,317],{},"Community governance is therefore part of the supply chain. Projects need ways to decide which contributions are accepted, how vulnerabilities are handled, how harmful use is discussed, how licenses are interpreted, and how disagreements are resolved. Without governance, openness can become brittle: technically available but socially difficult to maintain.",[11,319,320],{},"This is particularly important when open models are adopted by public institutions. Public users may need clearer documentation, stronger support channels, audit trails, and risk-management procedures than hobbyist or research users. The project studies how open communities respond when their artefacts become part of institutional infrastructure.",[70,322,163],{"id":162},[11,324,325],{},"Open AI systems are frequently presented as an alternative to concentrated proprietary control. They can support research transparency, local adaptation, education, and smaller-scale experimentation. Yet openness can also reproduce dependencies if the underlying supply chain remains concentrated in a small number of infrastructure providers, dataset sources, or model producers.",[11,327,328],{},"Understanding these dependencies matters for universities, public agencies, civil society organisations, and companies that want to use open systems responsibly. It helps clarify what can realistically be audited, what can be modified, what requires specialised infrastructure, and what kinds of governance are needed around shared technical resources.",[11,330,331],{},"The project also contributes to policy debates about open-source AI regulation. Effective policy needs more than a binary distinction between open and closed systems. It needs a way to describe degrees of openness, points of dependency, and the responsibilities of actors who publish, host, adapt, or deploy open models.",[70,333,335],{"id":334},"practical-assessment-framework","Practical assessment framework",[11,337,338],{},"We are developing a framework that helps institutions assess open models before adoption. The framework asks whether the model can be inspected, reproduced, adapted, hosted, monitored, and retired under realistic organisational conditions. It also asks whether the institution has the expertise and resources required to take advantage of openness.",[11,340,341],{},"The framework separates artefact access from capability access. Downloading weights is not the same as understanding the training process. Reading a license is not the same as having a governance plan. Running a demo is not the same as sustaining a service. This distinction helps institutions avoid overestimating the control that open release provides.",[70,343,186],{"id":185},[11,345,346],{},"The project will produce case studies, supply-chain diagrams, and analytical briefs. These outputs will document how open AI projects are assembled, where key dependencies emerge, and how institutions can evaluate the practical openness of models they intend to use.",[11,348,349],{},"We are also developing a comparative framework for assessing open model ecosystems. The framework will help distinguish access to artefacts from access to capability, and it will support more precise discussions about transparency, reuse, maintenance, and public-interest governance.",[11,351,352],{},"Future outputs will include a glossary of openness dimensions, a maintenance checklist for public-interest deployments, and short case studies showing how open models move from research release to operational use.",{"title":32,"searchDepth":33,"depth":33,"links":354},[355,356,357,358,359,360,361,362,363],{"id":72,"depth":33,"text":73},{"id":248,"depth":33,"text":249},{"id":261,"depth":33,"text":262},{"id":107,"depth":33,"text":108},{"id":297,"depth":33,"text":298},{"id":310,"depth":33,"text":311},{"id":162,"depth":33,"text":163},{"id":334,"depth":33,"text":335},{"id":185,"depth":33,"text":186},"2026-02-12","Investigating the software, datasets, labour, hardware access, and governance practices behind open-weight and open-source AI systems.",{},"\u002Fprojects\u002Fopen-model-supply-chains",{"title":217,"description":365},"projects\u002Fopen-model-supply-chains","HnkyMR6pzRRtBaKtgX27WbEJAxsh4SBEMiyKoaDin8I",{"id":372,"title":373,"author":47,"body":374,"date":519,"description":520,"extension":36,"meta":521,"navigation":38,"path":522,"seo":523,"status":212,"stem":524,"__hash__":525},"pages\u002Fprojects\u002Fcompute-geographies.md","Compute geographies",{"type":8,"value":375,"toc":508},[376,379,382,391,393,396,399,402,406,409,412,415,419,422,425,428,436,438,441,444,447,450,454,457,460,463,467,470,473,476,478,481,484,487,491,494,497,499,502,505],[11,377,378],{},"This project studies where AI compute is built, how those locations are selected, and what dependencies emerge around land, energy, water, tax incentives, network connectivity, chips, and operational labour. Rather than treating compute as an abstract cloud resource, we investigate it as situated infrastructure: built in specific places, governed by local constraints, and connected to wider industrial supply chains.",[11,380,381],{},"The geography of AI compute is becoming a central question for public institutions, research organisations, and policymakers. Training and serving advanced models depends on specialised facilities, high-capacity power connections, fibre routes, cooling systems, chip availability, and long-term procurement contracts. These requirements concentrate capability in some places while leaving others dependent on remote infrastructure and commercial access terms.",[57,383,59,384,59,388],{},[61,385],{"src":386,"alt":387},"\u002Fimages\u002Fservers-web.webp","Rows of server racks in a data centre corridor",[66,389,390],{},"AI compute appears immaterial to users, but its practical capacity depends on physical facilities, power delivery, cooling, maintenance labour, and regional network access.",[70,392,73],{"id":72},[11,394,395],{},"The project maps the relationship between compute facilities and the conditions that make them possible. We examine where data centres and cloud regions are located, what kinds of energy systems they draw upon, how land and permitting decisions shape expansion, and how public-sector strategy interacts with private infrastructure investment.",[11,397,398],{},"Our work asks three connected questions. First, what locations are becoming important for AI compute, and why? Second, how do local environmental, regulatory, and economic conditions influence the infrastructure that can be built there? Third, how do these geographic patterns affect claims about AI sovereignty, research autonomy, and public-interest access?",[11,400,401],{},"The aim is not simply to produce a map of facilities. We are interested in the relationships behind the map: grid capacity, ownership structures, procurement agreements, regional development narratives, tax incentives, public resistance, and the technical standards that determine whether a facility can support contemporary AI workloads.",[70,403,405],{"id":404},"why-geography-matters-for-ai","Why geography matters for AI",[11,407,408],{},"Cloud platforms are often described through a language of availability zones, regions, capacity, and elastic scaling. That vocabulary is useful for developers, but it can hide the political and environmental choices that make cloud services possible. A model endpoint may be accessed through an API, yet the request is served by a chain of physical dependencies: substations, backup generation, cooling systems, water rights, fibre landing points, logistics routes, security staff, maintenance teams, and hardware replacement cycles.",[11,410,411],{},"These dependencies are not distributed evenly. Some regions have a combination of cheap energy, permissive planning environments, existing industrial land, tax incentives, and network connectivity. Others may have strong research institutions and policy ambitions but lack grid capacity or suitable facilities. The resulting geography shapes who can train models, who can deploy them at scale, who can negotiate favourable access, and who must accept the conditions set by external providers.",[11,413,414],{},"For public institutions, this matters because compute location is not only a technical parameter. It affects procurement resilience, data governance, environmental accountability, regional economic policy, and democratic oversight. A public agency may procure AI services from a cloud region described as local, while important operational dependencies remain controlled elsewhere. Conversely, a smaller research compute cluster may provide less raw capacity but more meaningful institutional control.",[70,416,418],{"id":417},"infrastructure-layers","Infrastructure layers",[11,420,421],{},"We study compute geography across several layers. The facility layer includes data centres, colocation sites, cloud regions, high-performance computing centres, and specialised AI clusters. The energy layer includes grid connections, power purchase agreements, backup generation, cooling requirements, and local debates about industrial electricity demand. The network layer includes fibre routes, exchange points, latency requirements, and interconnection markets.",[11,423,424],{},"The hardware layer focuses on accelerator supply, server design, procurement timelines, repair capacity, and the replacement cycles that determine whether a facility can support frontier or applied AI workloads. The governance layer includes planning permissions, tax arrangements, environmental reporting, procurement rules, security classifications, and contractual terms. The labour layer includes the engineers, technicians, construction workers, facility managers, and policy teams required to keep infrastructure operational.",[11,426,427],{},"Seeing these layers together helps avoid two common simplifications. The first is the idea that compute is simply wherever a cloud provider says a region exists. The second is the idea that local ownership alone guarantees local control. In practice, compute capability is assembled through layered dependencies, and different actors control different parts of the stack.",[57,429,59,430,59,433],{},[61,431],{"src":100,"alt":432},"Large industrial data centre infrastructure",[66,434,435],{},"Hyperscale facilities sit at the intersection of industrial land use, energy planning, network connectivity, and corporate strategy.",[70,437,108],{"id":107},[11,439,440],{},"The project combines infrastructure mapping, policy analysis, and interviews. We collect public information about data centres, cloud regions, energy constraints, chip clusters, research computing facilities, and national compute initiatives. We then connect those sources to planning documents, grid connection debates, company reports, procurement frameworks, and public investment programmes.",[11,442,443],{},"This mixed approach is necessary because compute geography is only partly visible. Some infrastructure is publicised through cloud-region announcements or national AI plans. Other elements are hidden in leasing agreements, colocation contracts, energy infrastructure applications, or vendor-specific capacity planning. We therefore treat the geography of compute as an evidence problem as much as a mapping problem.",[11,445,446],{},"Our mapping work follows facilities through multiple sources rather than relying on a single dataset. We compare company announcements, real-estate filings, planning applications, energy regulator documents, procurement records, industry reports, and local news coverage. Where a facility is publicly visible but its AI relevance is uncertain, we mark it as such instead of overclaiming. Where a national compute initiative depends on commercial cloud access, we distinguish between public funding, public ownership, and public control.",[11,448,449],{},"The interview component focuses on people who make infrastructure decisions: public-sector technology teams, research infrastructure managers, cloud procurement specialists, energy planners, data-centre developers, civil-society observers, and researchers who depend on compute access. These conversations help explain why certain options are chosen even when public documents present them as obvious or inevitable.",[70,451,453],{"id":452},"case-comparison","Case comparison",[11,455,456],{},"The project compares different kinds of compute sites rather than treating all capacity as equivalent. Hyperscale cloud regions usually offer high availability, mature tooling, and substantial capacity, but access is mediated by platform contracts and pricing models. National research computing facilities may provide more direct public-interest alignment, but they face constraints around funding cycles, hardware refreshes, staffing, and allocation procedures.",[11,458,459],{},"Colocation facilities occupy a middle ground. They can host public, academic, or private compute clusters, but they also embed those clusters in commercial real-estate and energy markets. University and regional compute facilities can support local research communities, yet they may struggle to keep pace with specialised AI hardware requirements. Edge and inference facilities raise a different set of questions around latency, data proximity, energy efficiency, and distributed governance.",[11,461,462],{},"By comparing these models, the project asks what each site actually enables. A facility optimised for enterprise cloud workloads may not support large-scale model training. A research cluster may be excellent for experimentation but difficult to use for continuous public-service deployment. A national procurement agreement may provide access to impressive capacity while leaving switching costs and audit rights unresolved.",[70,464,466],{"id":465},"environmental-and-regional-stakes","Environmental and regional stakes",[11,468,469],{},"AI compute expansion places new pressure on regional energy systems. Data centres may compete with housing, industry, transport electrification, and climate-transition infrastructure for grid capacity. In some locations, new facilities are framed as engines of regional development. In others, they become flashpoints for concerns about water use, land conversion, noise, emissions, and unequal distribution of benefits.",[11,471,472],{},"The project does not treat these concerns as externalities that appear after the technical design is complete. They are part of the design space. A compute strategy that cannot secure sustainable power, local legitimacy, or credible environmental reporting is not a stable infrastructure strategy. Likewise, a regional development plan that counts data-centre investment as economic success without examining ownership, employment, and public value may overstate its benefits.",[11,474,475],{},"We therefore document both the enabling conditions and the local controversies around compute sites. This includes the language used to justify facilities, the actors included in consultation processes, the public information available about energy use, and the mechanisms for accountability when infrastructure imposes costs on host communities.",[70,477,163],{"id":162},[11,479,480],{},"Compute access increasingly shapes what kinds of AI research can be conducted, which organisations can experiment at scale, and which policy goals are technically realistic. A university, public agency, or civic organisation may have strong ideas about AI governance, but those ideas depend on whether suitable infrastructure is available under acceptable conditions.",[11,482,483],{},"Geography also changes the politics of AI infrastructure. A cloud region can be described as a national capability, but it may be operated by a foreign firm, depend on imported chips, draw on constrained local energy systems, and serve multiple jurisdictions. Conversely, a smaller public compute initiative may be limited in scale but more accountable to research and public-interest goals.",[11,485,486],{},"By tracing these tensions, the project contributes to a clearer understanding of what “compute capacity” means in practice. It helps distinguish symbolic infrastructure announcements from durable public capability, and it identifies the local dependencies that are often missing from high-level AI strategies.",[70,488,490],{"id":489},"working-questions","Working questions",[11,492,493],{},"The project is guided by a set of practical questions that can be used by policymakers, researchers, and public institutions. What part of the compute stack is controlled locally, and what part is leased or contracted? Which energy, water, land, and network constraints determine whether capacity can expand? How are environmental costs measured and reported? Who receives the economic benefits of infrastructure investment? What contractual terms govern access, portability, auditability, and exit?",[11,495,496],{},"We also ask how compute geography changes research agendas. If some research groups have privileged access to large-scale clusters while others rely on small grants or retail cloud pricing, then the geography of compute becomes a geography of knowledge production. The location and ownership of infrastructure affects what questions are affordable to ask.",[70,498,186],{"id":185},[11,500,501],{},"The project will produce a set of public-facing maps, short policy briefs, and research articles. These outputs will compare compute geographies across regions, describe common infrastructure bottlenecks, and document how public institutions negotiate access to facilities that are usually owned or operated by commercial actors.",[11,503,504],{},"We are also developing a vocabulary for describing AI infrastructure that avoids both cloud abstraction and simple territorial ownership claims. The goal is to support more precise public debate about what kinds of infrastructure are needed, who controls them, and what trade-offs come with different models of provision.",[11,506,507],{},"Later outputs will include a typology of compute sites, a checklist for public compute procurement, and short regional case studies that show how energy systems, planning processes, and platform strategies combine to shape the practical availability of AI infrastructure.",{"title":32,"searchDepth":33,"depth":33,"links":509},[510,511,512,513,514,515,516,517,518],{"id":72,"depth":33,"text":73},{"id":404,"depth":33,"text":405},{"id":417,"depth":33,"text":418},{"id":107,"depth":33,"text":108},{"id":452,"depth":33,"text":453},{"id":465,"depth":33,"text":466},{"id":162,"depth":33,"text":163},{"id":489,"depth":33,"text":490},{"id":185,"depth":33,"text":186},"2026-01-18","Mapping how data centres, cloud regions, chips, energy infrastructure, and policy incentives shape the geography of AI compute.",{},"\u002Fprojects\u002Fcompute-geographies",{"title":373,"description":520},"projects\u002Fcompute-geographies","RffeO_CbfKd0DFscFS7wVUAX-TLN5WLsf38OJGku9no",1783692932892]