Executive summary
What we are building. AICS (AI Compute Safety) institute is an independent technical research organisation working on a neglected layer of AI safety: the security, verifiability, and governability of the physical compute that frontier and edge AI run on. Most AI-safety work implicitly assumes that the underlying hardware faithfully executes the intended model — and that software alone is sufficient to ensure safety. Our mission is to make that assumption explicit, measurable, testable, and where possible enforceable, and to make hardware verification more affordable and more transparent than it is today.
Why it matters. AI performance and infrastructure are scaling at a speed and capital intensity never seen in history. The largest data-centre operators are on course to spend on the order of three-quarters of a trillion dollars in 2026 alone, while capable models are simultaneously spreading beyond the datacenter perimeter into open-weight releases, edge devices, and robots. Yet the hardware layer remains one of the least examined parts of AI safety. Every model evaluation, deployment monitor, and governance regime assumes that chips compute faithfully. When that assumption fails, safety checks can still pass while the system is corrupted; demonstrated attacks have shown significant model collapse targeting hardware infrastructure. Powerful adversaries have every incentive to reach this layer, with consequences running straight into national security and economic stability. Because compute is the most governable input to advanced AI, hardware assurance could be one of the highest-leverage interventions in the field; today it remains under-studied, under-secured, and under-represented. Hardware-layer verification is a necessary complement to model-level safety — software checks inherit the trustworthiness of the substrate they run on — though it is not a substitute for them.
Why the Netherlands. The Netherlands hosts ASML, the single most critical lithography system on which every leading-edge AI chip depends, alongside major players such as NXP and a dense deep-tech ecosystem around Eindhoven’s Brainport region. Dutch and EU agendas on compute governance and technological sovereignty are advancing: the National AI Delta Plan (November 2025) calls for flagship AI research institutes and a national computing-capacity plan. Yet there is almost no independent organisational capacity focused specifically on hardware-layer AI safety, compute assurance, and the translation of semiconductor realities into AI governance. We are deliberate about what Europe can and cannot do here: Europe will not out-compete the US or China in supplying high-volume AI silicon and cannot dictate standards through market leverage. Its tractable contribution — and ours — is different: neutral, affordable, transparent verification capacity anchored next to the supply chain’s most critical chokepoint. AICS is designed to fill that gap.
What we will do. We narrow the field into four focused research streams rather than one undifferentiated end-to-end domain: (1) hardware identity and supply-chain verification — proving that a shipped chip matches its claimed design and reached its owner unaltered, without exposing the design; (2) compute ownership — verifying that the loaded model, the data, and the output are the ones intended; (3) hardware-level interception — the capability, in higher-risk output domains such as physical AI, edge, and robotics, to intercept model behaviour at the hardware level; and (4) a verification-oriented EDA stream that makes chip designs ZK-verifiable by construction, offered to companies through a shared consortium. A cross-cutting program translates the technical work into policy, and a fieldbuilding program brings strong technical and policy people into this niche through fellowships and convenings. Next-generation substrates (photonic, analog, quantum) are maintained as an explicit watching brief rather than a standalone program.
What we are careful not to claim. We think an honest account of our own uncertainty is part of a credible technical proposal, so several limits are stated explicitly in this document rather than left for a reviewer to find. Hardware verification is a necessary complement to model-level safety, not a substitute for it. Proving that a chip is the design its vendor claimed is a different and more tractable problem than proving that the claimed design is itself trustworthy — we pursue the former and are explicit about the boundary (Section 3.1, Program 4). Register-level hardware filters are non-bypassable but syntactic; they enforce externally specified boundaries and do not make semantic judgements about hazardous content. And frontier-scale zero-knowledge verification remains an open feasibility question, which our first year measures rather than assumes. Section 3.4 collects these open questions in one place, with what would resolve each.
Expected impact. Our long-term aim is to reduce the risk of unsafe operation of both foundational and edge models by making the hardware they run on verifiable. Near term, we aim to create a solid technical research organization with a clear, rigorous, bottom-up technical roadmap along with the capabilities to drive it. The primary near-term goal is to build trusted institutional capacity in a domain where the need is growing faster than the field’s ability to respond.
Who we are. AICS has an unusually precise founder-market fit for this problem.
Founder & Executive Director: Aytunc Ilhan combines technical, industrial, and policy experience across the domains this work must bridge: electronics and AI; technology-policy work at NATO Headquarters; semiconductor and lithography-adjacent work at ASML across Europe and the US; and AI-governance research on verifiable semiconductor manufacturing (he authored the inaugural paper of Oxford’s Hardware & AI Governance group).
Co-founder & Head of Research: Mert Koc is an AI expert and leader at NXP Semiconductors, a Fulbright scholar, and holds a double master’s in AI and robotics and a bachelor’s in electronics engineering; he brings the technical credibility and semiconductor-industry grounding to make AICS’s agenda practically rigorous.
Together, the founding team combines AI, semiconductor knowledge, infrastructure security, strategy, and policy networks across industry, NATO-adjacent institutions, EU and Dutch policy circles, and the AI safety ecosystem.
While the core value proposition of AICS is credible technical research capability in AI safety at the hardware layer, we aim for the organisation to be a connective institution: one that can make infrastructure risks legible to AI governance, make AI safety concerns concrete for semiconductor and cloud actors, and help ensure that the physical substrate of advanced AI becomes more secure, verifiable, and governable before the window for shaping norms and technical standards narrows. Existing verification efforts — from frontier labs’ internal assurance work to commercial attestation vendors — concentrate on verifying what runs inside the system. Very few groups work on verifying the hardware itself. AICS exists to close that gap.
1. Mission & Scope
1.1 Mission
To mitigate risks from advanced AI by making the compute layer verifiable: ensuring that hardware identity, faithful execution, and safety-relevant behaviour are explicit, testable, and — where practical — enforceable, while making verification more affordable and more transparent and building field capacity.
1.2 Vision
A future where the physical stack of both frontier and edge AI is verifiable at scale. From hardware identity and execution provenance to hardware-level safety interception in high-risk domains, AICS provides technical foundations and adaptive architectures to ensure AI safety keeps pace with scaling laws and benefits humanity.
1.3 Scope
In scope: hardware identity and supply-chain verification; compute-ownership verification (model, data, and output); hardware-level interception for high-risk output domains (physical AI, edge, robotics); verification-oriented EDA/DFT and ZK-compatible design flows; firmware and orchestration security; supply-chain mapping and governance; and the policy translation of all of those.
Out of scope: model-level alignment and interpretability research; general AI policy unrelated to compute; and industrial-competitiveness plays — e.g., Industry 4.0 factory automation or attempts to set standards through supplying high-volume competitive products. Those paths belong to actors with different market positions; the relevant question for us is whether verification can be made more affordable and more transparent. We aim to complement, rather than duplicate, the existing verification ecosystem.
2. Strategic context
2.1 The gap (importance, neglectedness, tractability)
AI-safety work often assumes the hardware is faithful at every stage, yet each stage is under-verified. Upstream, there is no easy way for a third party to confirm that a chip is what it claims to be, was made as specified, or is free of undetected backdoors and vulnerabilities. Downstream, as inference moves to enterprise edge, private servers, consumer GPUs, and open-weight deployments, hardware-originating faults (accidental or adversarial) can degrade safety-relevant behaviour. Verification methods exist in pockets but are not joined up into an enforceable and scalable assurance picture. We are explicit about tractability: detecting arbitrary trojans inside another firm’s proprietary design is out of reach — it would require visibility into every design house’s IP, or a black-box verifier that does not exist. The tractable formulation is claim-based: a firm makes a claim about its design; we verify that the shipped chip is that design without exposing it, and that nothing was inserted or spoofed between the foundry and the end user.
Leading semiconductor firms already run rigorous pre-silicon validation, post-silicon testing, and Design-for-Test (DFT) flows for their own reliability. What is missing is an independent, affordable, publicly legible layer of assurance: today, third parties, states, and customers must simply trust vendor self-attestation. Making verification cheaper and more transparent changes who can demand assurance and who can provide it.
Compute is the most physically governable input to frontier AI. Yet the supply-chain debate too often stays vague, long on high-level ambition but short on practical enforcement. Many proposals are technically weak, effectively unenforceable, or written without domain expertise. Clear threat models and prioritisation frameworks are scarce, and there is no playbook for post-incident response.
Serious technical compute-security work is concentrated in the US and UK. Europe hosts the most critical chokepoint in the supply chain and major semiconductor players, yet has very little dedicated organisational capacity on this question. Europe’s advantage here is credibility and chokepoint proximity, not market leverage; we build on the former and do not premise our strategy on the latter.
2.2 Two structural shifts
The decentralization of frontier capabilities. Current control frameworks often assume that tracking centralized, hyperscale training clusters is sufficient to guarantee safety. As capabilities proliferate via open-weight releases and distillation into compact models, advanced intelligence spreads across distributed topologies — private clusters, consumer GPUs, edge devices, and robots — where datacenter-perimeter monitoring observes only a fraction of the picture, including possible coordinated, distributed misuse patterns that no single datacenter-side monitor sees in full. This does not make centralized governance useless, but it does mean the hardware that capable models actually run on becomes a governance surface in its own right.
The substrate constraint. In multi-tenant clouds, virtualized software isolation cannot eliminate physical side-channel leakage, transient hardware execution faults, or hypervisor-level bypass; software-only guarantees stop at the boundary of physics. This is the core of our case for hardware: a monitor implemented in hardware, beneath the hypervisor, cannot be disabled by the software it is watching. Non-bypassability — not raw capability — is what a hardware safeguard buys, and it is the property we test throughout our programs.
Meanwhile, zero-knowledge (ZK) verification of AI workloads is mathematically attractive — it can in principle prove that a specific model ran a given workload without revealing the weights — but faces a computational bottleneck that software alone cannot practically bridge at frontier scale. Two obstacles are concrete enough to name: floating-point non-determinism in parallel GPU execution, which complicates the reproducible arithmetic that proof systems assume, and circuit expansion factors commonly reported in the 10³–10⁴× range when translating computation into provable form. We treat this as an open empirical question rather than a settled premise. Our first-year commitment is deliberately modest and checkable: a measured proving-overhead budget for representative inference workloads, quantifying how much of that gap dedicated hardware acceleration and design-time support (Program 4) could realistically close. If the honest answer turns out to be “not enough, yet”, that is a finding worth publishing — it would redirect effort toward the attestation properties that are reachable today.
2.3 Theory of change
A technically credible and well-networked organisation can (1) produce empirical findings and threat models that rebase compute-governance debates in physical reality, (2) prototype verification and assurance mechanisms — from claim-based chip verification to hardware-supported ZK attestation — that labs, regulators, standards bodies, and defence can adopt, and (3) build capacity with a talent pipeline. Those outputs produce outcomes: better threat models and verification methods adopted by others, and people and institutions moving into the field. Ultimately, those outcomes contribute to the end goal of a more secure and verifiable hardware base for advanced AI, end to end.
2.4 Theory of impact: how hardware work bears on catastrophic risk
Because our funder’s mandate is catastrophic risk from advanced AI, we state plainly how hardware-layer work connects to it — and, equally plainly, where each link is strong and where it is currently a hypothesis. We have deliberately written this section so that no claim here exceeds what the corresponding program can actually deliver. Where the mapping is speculative, we say so.
Vector 1: containment escape and supply-chain-assisted compromise.
A model capable of situational awareness and of exploiting its own execution environment is a standard catastrophic-risk scenario. Hardware bears on it twice. Program 1 aims to establish that deployed silicon corresponds to its claimed design, removing fabrication- and transit-stage tampering as an exploitable path. Because we cannot mathematically guarantee that the claimed design is itself free of undiscovered vulnerabilities, Programs 2 and 3 pursue the complementary fail-safe: monitors sitting beneath the software they observe, which cannot be disabled by a compromised hypervisor or host OS. We regard this as the strongest of our three mappings, and note honestly that it depends on the anomaly-detection question in Program 2 resolving favourably.
Vector 2: preserving the integrity of safety-relevant behaviour under physical compromise.
A more tractable framing than “hardware blocks dangerous outputs”, which we do not claim. Register-level hardware filters are fast and non-bypassable, but they are syntactic: they can enforce hard, externally specified boundaries, not semantic judgements about whether a given output is hazardous. Recognising hazardous content is a model-level problem and we do not claim to solve it in silicon. What hardware can plausibly contribute is assurance that the safety behaviour a model was evaluated as having is the behaviour it still exhibits at runtime — that alignment properties have not been silently degraded by faults, side-channels, or substrate-level poisoning (Programs 2 and 3). Whether such degradation is detectable at the hardware boundary is an open question we intend to answer empirically, not an assumption.
Vector 3: physical action by autonomous systems.
Where AI drives actuators, the failure mode is kinetic and a software kill-switch may be exactly what fails. Program 3 develops isolated monitors at the actuator boundary that enforce an externally specified physical action envelope and cryptographically attest that a command originated from an authorised, unmodified model. We are careful about the strength of this claim: such a monitor constrains a system only within the envelope it was given, only on the actuators it instruments, and only if it is itself correct and tamper-resistant. It is a meaningful containment layer, not a guarantee, and specifying good envelopes is itself an unsolved problem we expect to spend real effort on.
We think stating these limits improves rather than weakens the case. The value of hardware-layer work does not rest on any single mechanism being airtight; it rests on adding an independent layer whose failure modes are uncorrelated with those of the software safety stack.
2.5 Positioning and complementarity
AICS complements existing organisations by focusing on the hardware layer that model-centric safety groups do not cover. By design, we are already pursuing partnerships with peer safety organisations, universities, and standards bodies, so that our work multiplies impact through a shared network rather than duplicating effort.
2.6 How do we differentiate from existing orgs?
A small but growing set of organisations now works at the hardware layer of AI governance and security. This work is valuable, and we expect to collaborate with much of it. The landscape today falls into roughly four groups:
HAIGL, hosted by the Oxford Martin AI Governance Initiative, investigates how oversight, verification, and control mechanisms can be embedded at the hardware layer, with an emphasis on translating governance goals into hardware “design profiles”. Its centre of gravity is university-based research and design. AICS’s founder authored HAIGL’s inaugural paper on verifiable semiconductor manufacturing, so we know this agenda intimately. We differentiate by moving from design research into empirical engineering: where HAIGL proposes profiles and policies, AICS builds and tests the artefacts — verification-oriented EDA/DFT flows, claim-based chip verification methods, and prototype interceptors — needed to bring these ideas into practice.
CAISH is a field-building and talent organisation. It runs fellowships and programmes (including a dedicated Hardware Assurance Programme) that move engineers and researchers into AI assurance, verification, and compute-governance work. It builds the talent pipeline for the field rather than maintaining a sustained research-and-engineering agenda of its own. AICS is a natural downstream home for that talent and a potential collaborator on programming, but our output is research, methods, and hardware, not training.
Lucid Computing is a venture-backed company building cryptographic attestation and compute-tracking software oriented largely to export-control compliance and data-residency assurance (e.g., US export controls, the EU AI Act, GDPR) — a commercial product business serving regulators and chip buyers, operating primarily at the software and orchestration layer. We view Lucid as complementary: their work, like most verification efforts including frontier labs’ internal assurance, verifies what runs inside the system. AICS focuses on the layer beneath — verifying the hardware itself — and on the design-time and hardware-acceleration research (Programs 1, 2, and 4) on which software-layer attestation will ultimately need to rest.
Amodo Design is an engineering consultancy that designs and builds hardware for AI verification (network taps, data-centre power and signal measurement, enclosure and guarantee-processor work) on a project basis for startups, universities, and funders. It is the closest neighbour to our technical programme and a natural collaborator. AICS differs in being an institution that owns a sustained, end-to-end research agenda — including design-time verification and consortium-based EDA work — rather than executing discrete builds as a contractor.
Ultimately, AICS’s relative advantage is the combination of the following:
- Industry-native execution at the EDA and fab level: AICS’s founders come directly out of the core semiconductor chokepoints (ASML and NXP). That provenance gives in-group credibility with the semiconductor ecosystem — which an academic lab or a young startup typically spends years earning — and the technical authority to integrate verification mechanisms (such as ZK-proof-oriented DFT) directly into standard EDA flows, shifting safety left to the design phase rather than bolting it onto finished chips.
- A credibility and network ripple effect: when senior engineers leave established industry roles to work full-time on public-interest AI safety, the move itself carries a message. We expect the founders’ transition to draw talent, advisors, and partners from across the semiconductor, cloud, and hardware-security spaces.
- Empirical and bare-metal first: AICS starts from physical work — building dual-scale emulation environments, inspecting chips, injecting and measuring faults on contemporary production silicon — so that findings apply directly to the compute environments frontier and edge models actually run on. We aim to provide both theoretical and product-driven solutions.
- Feasibility-driven, low-overhead safeguards: we prioritise hardware safeguards that are economically, technologically, and practically viable. Verification that imposes heavy latency or integration friction will be rejected by operators regardless of its merits; our design goal throughout is assurance with minimal computational overhead, so that rigorous AI safety does not become a bottleneck to computational speed.
3. Programs & activities
AICS’s mandate is to make the hardware layer of AI verifiable at the points where failures or hidden modifications could impact system security or behaviour — from design and fabrication, through data-centre and cluster operation, to deployment and inference on heterogeneous hardware. Rather than treating this as one undifferentiated end-to-end domain, we narrow the work into four focused research streams, each mapped to a program below. Programs 1 and 4 address design, fabrication, and delivery; Program 2 addresses operating datacenters; Program 3 addresses high-risk deployment domains. Next-generation substrates (photonic, analog, quantum) are tracked as a standing watching brief inside our Tier-1 threat-mapping funnel rather than as a standalone program, and will be promoted only if the watching brief surfaces near-term, tractable safety work. We make the breadth of covered areas tractable through the organising frame below and a technical roadmap with a prioritised initial portfolio of anchor projects.
| Compare | Stream 1Program 1: Hardware Identity & Supply-Chain Verification | Stream 2Program 2: Compute Ownership & Execution Verification | Stream 3Program 3: Hardware-Level Interception (Physical AI & Edge) | Stream 4Program 4: Verification-Oriented EDA (DFT-for-ZK Consortium) |
|---|---|---|---|---|
| Lifecycle stage | Design, fabrication & delivery | Training & datacenter inference | Deployment & inference in high-risk domains | Design & EDA |
| Scope | Claim-based chip verification; post-foundry provenance and anti-spoofing | Hyperscalers, TEEs, and active compute clusters | Robotics, edge devices, and heterogeneous open-weight deployments | EDA plug-ins, verification-oriented DFT flows, shared consortium |
| Core objective | Prove a shipped chip matches its claimed design and reached its owner unaltered — without exposing the design. | Verify that the loaded model, the data, and the output are the ones intended, and that execution stays faithful under physical stress. | Establish feasibility of hardware interceptors between neural engines and actuators; empirically assure open-weight execution in the field. | Make designs ZK-verifiable by construction: instrument points and pins so system-level properties can be proven without revealing the design. |
| Illustrative physical threats | Covert safety-bypassing modifications, counterfeit fabrication, in-transit substitution or spoofing | Model substitution, data tampering, power/EM side-channel leaks, hardware-mediated poisoning, silent behavioural collapse | Bit-flips, silent data corruption, firmware interference, unsafe autonomous actuation | Unverifiable designs, opaque compliance claims, IP-exposure barriers to independent auditing |
3.1 Hardware trust & verification across the compute lifecycle
Program 1: Hardware Identity & Supply-Chain Verification
We value upstream considerations highly because upstream interventions shape many downstream outcomes and can be invisible to downstream actors, while downstream interventions get fragmented across deployment contexts. This program establishes that a chip is what it claims to be and reached its owner unaltered — the foundation on which all downstream trust rests. We deliberately do not attempt trojan detection inside third-party proprietary designs: that would require visibility into every firm’s IP, or a black-box verifier that does not exist. The tractable formulation is claim-based verification plus post-foundry integrity. Anchor projects:
leading semiconductor firms already employ rigorous pre-silicon validation, post-silicon testing, and traditional Design-for-Test (DFT) flows to guarantee functional reliability and to identify manufacturing defects or macro-tampering. The primary vulnerability is not a lack of internal testing but the absence of an independent, publicly auditable guarantee. AICS develops mechanisms that allow end users to independently verify that the physical chip architecture exactly matches the specified design — proving the absence of post-design alterations or fabrication-stage backdoors — without requiring access to proprietary IP.
attestation and tamper-evidence establishing that a device was fabricated to specification and was not modified, substituted, or spoofed anywhere between the foundry and deployment (building on the founder’s Oxford HAIGL paper on verifiable semiconductor manufacturing).
building highly parameterized emulations of frontier accelerators that accurately reflect true physical responses (e.g., thermal crosstalk, voltage drops) while running actual AI software stacks. This applied research is the foundational methodology for our “shift-left” strategy, allowing us to safely prototype defensive hardware architectures before physical fabrication, without requiring raw pre-silicon IP from vendors.
developed with chip designers, foundries, and memory makers (target partners include NVIDIA, ASML, Intel, TSMC, and Micron), since credible upstream verification cannot be built without the people who make the hardware.
Program 2: Compute Ownership & Execution Verification (Datacenters)
Establishing that active compute clusters execute the intended workload faithfully, resilient to both adversarial physical compromise and environmental degradation. The stream is organised around three concrete questions: is the loaded model the one you intended? Is the data the data you intended? Is the output what you expected? Anchor projects:
research into hardware-supported mechanisms — TEE-anchored attestation and hardware-accelerated zero-knowledge proof generation — that can answer the three ownership questions without revealing proprietary model weights or data. We treat frontier-scale ZK proof generation as an open feasibility question rather than a promised product: near-term work benchmarks proof-system overheads on representative inference workloads, identifies which properties (model identity, data lineage, output integrity) can be attested at acceptable cost, and maps where dedicated hardware support — including Program 4’s design-time instrumentation — changes the economics. The concrete Year-1 output is a measured proving-overhead budget: an empirical account of proving latency on representative inference workloads, and of the two obstacles specific enough to quantify — floating-point non-determinism in parallel GPU execution, which unsettles the reproducible arithmetic proof systems assume, and circuit expansion factors commonly reported in the 10³–10⁴× range. The question we actually want answered is what fraction of that gap dedicated hardware can close, and we would rather publish a disappointing number than an optimistic promise.
the justification for placing a monitor in hardware rather than software is not that hardware is smarter — it plainly is not — but that a monitor beneath the hypervisor cannot be switched off by the software it is watching. We split this work explicitly by how confident we are that it will work. Track A, our Year-1 deliverable, is fast, deterministic, rule-based filtering at the register level, enforcing hard externally specified boundaries such as token-vocabulary constraints, repetition limits, and immediate boundary violations, demonstrable on FPGA development boards. These checks are syntactic by nature, and we do not represent them as semantic safety filters. Track B is a genuinely open research question that we find one of the most interesting in the agenda: whether stable, cross-architecture invariants exist in hidden-layer activations that a concurrent hardware monitor could watch for signs that a model’s safety-relevant behaviour has degraded. We will evaluate this on digital-twin co-simulation (Program 1) before committing any design to hardware, precisely because the honest answer may be that no such invariants survive across model architectures. Both tracks target reprogrammable substrates — embedded FPGA fabrics rather than fixed-function silicon — since model architectures change on a timescale of weeks and fabrication does not; treating reprogrammability as a requirement rather than a nicety is our mitigation for obsolescence risk.
traditional side-channel research focuses almost entirely on security in the classic sense (stealing cryptographic keys or model weights). AICS pivots this domain toward operational safety. Modern confidential computing (hardware TEEs) neutralizes software-based memory scraping, but TEEs do not change the laws of physics: they do not flatten power-consumption curves or mask electromagnetic emissions. This project analyzes how physical side-channels, environmental fluctuations, hardware aging, thermal stressors, or targeted fault injections on modern multi-tenant GPU architectures can subtly corrupt a model’s internal state or activation boundaries — leading to degraded safety compliance or silent behavioural collapse — and proposes hardware-level masking and resilient design solutions.
once the reciprocal digital twins are stabilized via our CPU-heavy simulation clusters, both hardware pools switch modes to execute advanced reinforcement-learning and adversarial training schemes. This project investigates how physical side-channels, clock-cycle anomalies, and transient hardware faults can be exploited to facilitate data-poisoning and model-parameter poisoning at the substrate layer, and designs prototype hardware-level monitoring blocks to block parameter degradation during live execution.
as inference and training distribute globally, data centres are moving to non-standard environments such as space-based orbital nodes, distributed mass-scale edge networks, and underwater facilities. These extreme locations require zero-touch maintenance and face unique degradation conditions (radiation, pressure, thermal dynamics). This project explores hardware safety requirements for remote, physically inaccessible environments, focusing on verifiable remote attestation and tamper-evident architectures that guarantee uncompromised execution when physical inspection is impossible.
Program 3: Hardware-Level Interception for Physical AI & Edge
Frontier training still depends on centralised hyperscale clusters, but inference and deployment are spreading into private enterprise clusters, national “AI factories”, edge devices, humanoid robots, and increasingly heterogeneous environments. In higher-risk output domains — where model outputs become physical actions — software monitors are the weakest link, and the capability to intercept model behaviour at the hardware level becomes directly safety-relevant. This program establishes that a model that passed evaluation is still being faithfully and safely executed in the real environments it ends up in. Anchor projects:
an empirical testbed that injects and observes hardware-originating faults (bit-flips, silent data corruption, firmware-level interference) and measures whether they degrade safety-relevant behaviour — and whether such degradation can be detected in the field. A guiding question: can hardware systems adapt to the active model and its safety requirements as part of the inference flow, to ensure on-field safety?
existing edge platforms and robotic systems already implement low-level, rule-based guardrails — velocity limits, electrical cutoffs — and it is a fair challenge to ask what we add beyond them. Two things. First, provenance: our interceptor cryptographically attests that a command originated from an authorised, unmodified model, which conventional kinematic cutoffs do not check at all; a compromised or substituted model driving the same actuator within the same velocity limits passes every existing guardrail. Second, an externally specified physical action envelope, defined and signed outside the model, so that the constraint does not inherit the trustworthiness of the system it constrains. AICS researches local, hardware-isolated interceptors that sit directly between the neural processing block and the physical actuator controllers, evaluating the safety of an intended action before it translates into physical effect. Near-term work starts with fast, deterministic, rule-based hardware filters evaluating hard boundaries at the register level. Learned in-hardware monitors — e.g., small concurrent models watching internal activation signatures — are treated as an open research question, not a committed build: their dependence on model internals and their exposure to model-architecture churn are exactly the risks to be characterised, with reprogrammable substrates (such as embedded FPGA fabrics) studied as the mitigation for obsolescence rather than fixed-function silicon.
Scope note on coordinated edge-swarm extraction. An earlier draft anchored this program on distributed “swarm” attacks in which many low-cost edge nodes pool queries to map a frontier model’s safety boundaries, evade rate limits, or assemble hazard fragments. We have deliberately moved it out of the technical program for two reasons we think are worth stating rather than burying: query aggregation against a central API is a serving- and software-layer problem that providers are better positioned to defend, and edge hardware under an adversary’s control will simply not run our interceptors. Neither objection makes the threat uninteresting — it is a real and under-modelled pattern — so it survives as a Tier-1 threat-mapping and policy publication under Section 3.3, where the useful contribution is a rigorous threat model rather than a hardware defense we are not well placed to build. If that mapping surfaces a component that genuinely sits at the hardware boundary, it can re-enter the funnel on its merits.
Program 4: Verification-Oriented EDA (DFT-for-ZK Consortium)
What this program does and does not prove. Reviewers of an earlier draft rightly pressed on a conflation that runs through much of the hardware-verification literature, and we want to resolve it explicitly rather than let it sit in the background. Three claims are routinely blurred together: (1) that the shipped silicon corresponds to the design its vendor claimed; (2) that a particular execution faithfully ran the model it claimed to run; and (3) that the claimed design is itself free of hidden malicious modification. Design-time instrumentation of the kind described below delivers (2), and — when the instrumentation is bound to a public commitment to a design — a meaningful version of (1). It does not deliver (3). A design containing a deliberate backdoor will emit perfectly valid proofs that it executed that backdoored design faithfully; the proof attests to the trace, not to the trustworthiness of the design that produced the trace. Reaching (3) requires either visibility into the design itself, which no design house will grant, or a multi-party approach in which a design is verified as belonging to a repository of architectures a cohort has vetted — and even then the guarantee is only ever relative to what that cohort actually examined. That is precisely the limitation the System Cohort work below is aimed at, and we regard closing the gap between (2) and (3) as one of the genuinely open problems in this field rather than something our EDA flow quietly solves.
Design-for-Test (DFT) infrastructure is ubiquitous in modern chip design, but no existing stream makes designs verifiable in a ZK-compatible way. This program builds that missing stream and offers it to companies through a shared consortium. The pitch to industry is deliberately low-friction: participants do not need to invest in verification R&D themselves — AICS provides an EDA plug-in; they run their designs through verification-oriented DFT; and the design becomes ZK-provable automatically. Anchor projects:
shifting safety left by embedding zero-knowledge verification capability directly into EDA pipelines. The project adapts traditional DFT infrastructure — instrumenting specific observation points and pins — so the hardware can output a compact cryptographic proof of faithful, system-level behaviour (“this design does X”) without revealing the design and without slowing production flows. Rather than attempting intractable transistor-level verification, the focus is on the system-level behaviours that drive the functionality of the hardware, so that covert safety-bypassing modifications become mathematically detectable.
for mature designs and standardized compute primitives, expand DZK into an ecosystem-wide auditing capability: verifying not only that a chip matches its own company blueprint, but that a design belongs to a vetted repository of approved architectures validated by a multi-party semiconductor safety cohort. Designs remain closed-source and proprietary, secured by multi-party cryptographic audits rather than the internal trust of a single corporate entity. The adoption logic is deliberately modest and aligned with Europe’s actual position: we do not assume leverage from supplying a high-volume competitive product and we do not attempt to dictate standards. The incentive we offer is cost-sharing and compliance. We are precise about the current regulatory picture rather than overstating it: existing frameworks such as the EU AI Act bind general-purpose model providers — Article 51’s training-compute threshold is addressed to model providers, not to foundries — and there is today no hardware-substrate mandate for us to point to. What is accelerating is export-control and supply-chain-integrity pressure on hardware more broadly. Our claim is therefore forward-looking and conditional: as compute-security expectations firm up, foundries and design houses will face growing pressure to demonstrate integrity without exposing trade secrets, and a neutral non-profit platform lets them do so cryptographically at a fraction of the cost of building the capability in-house. Mapping which existing and proposed regulatory provisions can concretely reference such audits is joint work with the policy translation program (Section 3.3).
The technical programs are designed to move through a three-tier funnel. The funnel is broad at the top and selective at the bottom.
- Tier 1 is comprehensive: we map the entire threat space of the AI compute stack and hold nothing out. This is useful for mapping the space and creating a taxonomy along with prioritization. Tier 1 also hosts the standing watching brief on next-generation substrates (photonic, analog/thermodynamic, quantum): we track their threat surface and promote work into Tier 2 only when near-term, tractable safety questions emerge.
- Tier 2 admits only a prioritised shortlist of that space into simulation.
- Tier 3 admits only the narrow subset of simulated work whose results justify the cost of real hardware — the most feasible and most promising defenses.
The funnel is simultaneously our research methodology and our cost-control mechanism. Each tier has distinct infrastructure, distinct unit costs, and distinct exit criteria. For example: dozens of threat classes catalogued and prioritised in Tier 1, a handful carried into Tier 2 for simulated impact-verification and defensive design, and at least one carried all the way to an end-to-end hardware demonstration in Tier 3. Narrowing in the funnel concentrates the expensive, hardware-dependent work on the threats that matter most and the defenses most likely to work; the broad upper tiers still produce valuable, shareable outputs (e.g., a public taxonomy, replicable simulation evidence). Appendix A has a more detailed overview of this funnel.
3.2 Field-building & talent
To multiply impact, AICS is explicitly designed to also build capacity. We will run (1) visiting research residencies / fellowships that draw strong technical people into hardware-layer safety and let them lead individual portfolio projects, and (2) expert convenings that bridge hardware engineering, AI safety, and policy. Over time, we aim to create a landing spot for senior industry and policy professionals moving into AI safety. This program is also AICS’s clearest capacity-building contribution: it brings people from outside the traditional ML-safety pipeline (semiconductor engineers, hardware-layer AI safety engineers, and technically literate policy professionals) into the field.
3.3 Compute supply-chain security & governance (policy translation)
This program is the policy translation of the technical work above, and it spans the whole lifecycle. We decompose the supply chain into tractable problem areas and produce domain-expert-grade analysis where current proposals are weakest:
- Mapping & prioritisation. Identify the real chokepoints and critical, under-secured dependencies across EDA and IP, designers, equipment, and foundries/memory, plus cross-cutting layers: power and grid, critical minerals, firmware and orchestration, and the human talent pipeline.
- Verification & inspection (policy). Turn the technical verification and attestation methods from Programs 1 and 4 into something a third party could actually use and a regulator could actually require.
- Provenance & tracking. Tamper-resistant tracking, cryptographic attestation, and supply-chain audit trails.
- Sovereignty & defence. Tiered regulations for critical sectors (military, healthcare, communications) vs. consumer products, developed with NATO, EU, and Dutch stakeholders.
- Distributed misuse & edge-swarm threat mapping. A Tier-1 threat model of coordinated, distributed extraction and misuse patterns — pooled querying to map safety boundaries, rate-limit evasion, and fragment assembly across many low-cost nodes. This is where the edge-swarm question relocated from Program 3 (see the scope note there). The deliverable is a rigorous public threat model and a policy assessment of who is actually positioned to defend against it, which we expect to be model providers at the serving layer rather than hardware defenders at the edge.
3.4 Open questions and known limitations
We would rather a reviewer learn our uncertainties from us than discover them unaided, so this section collects the load-bearing open questions in one place. Each is a research question we find genuinely interesting, each has a stated way of being resolved, and in several cases a negative answer would be a publishable result that redirects the field. We regard the ability to say clearly which parts of an agenda are not yet known to work as a marker of technical seriousness rather than a weakness in the proposal.
Q1Does design-time proof generation reach acceptable overhead?
The DZK flow (Program 4) is our most distinctive bet, and its viability turns on whether instrumentation and proof generation can be made cheap enough that a real design team would accept them.
Resolution: the measured proving-overhead budget in Year 1, followed by area and timing characterisation on an instrumented design. A clear account of why current techniques cannot meet a plausible overhead budget would define the research frontier for others.
Q2Can chip identity be established at operationally useful error rates?
Claim-based verification (Program 1) assumes that physically derived signatures can separate a genuine part from a substituted or altered one under real variation in temperature, aging, and workload.
Resolution: the bench measurement campaign, reported with false-accept and false-reject rates rather than qualitative claims. If the separation is not there, the honest consequence is that assurance must lean harder on custody controls, which is itself a finding the policy program can use.
Q3Do cross-architecture activation invariants exist at all?
Track B of the interception work (Program 2) presumes that a hardware monitor could watch for signatures of degraded safety-relevant behaviour. This may simply be false: the invariants may not survive a shift from dense transformers to mixture-of-experts or state-space architectures.
Resolution: digital-twin co-simulation before any hardware commitment. This is the question we are least confident about and the one we are most curious to answer.
Q4Is substrate-mediated poisoning a real attack path?
Program 2’s poisoning work assumes an adversary could bias training or fine-tuning through transient faults and side-channels. It is plausible and, to our knowledge, not well established.
Resolution: simulated attack campaigns on the digital twin, with a credible “this is not a practical attack path” as an acceptable and useful outcome.
Q5Do hardware faults actually degrade safety-relevant behaviour in the field?
Demonstrated attacks show that model accuracy can be collapsed by induced faults, but the narrower question of whether realistic field conditions degrade safety-relevant behaviour specifically — and whether that degradation is detectable without model internals — is open.
Resolution: the open-weight fault-injection testbed, released as a public dataset so others can check our answer.
Q6Can the gap between execution proof and design trustworthiness be closed?
As stated at the head of Program 4, proving faithful execution is not the same as proving the design is free of hidden modification. The multi-party cohort route is our candidate answer, and its guarantee is only ever relative to what the cohort examined. We consider this the deepest open problem in our agenda and expect to make partial rather than complete progress on it within this grant period.
Two further limitations are structural rather than empirical, and we state them plainly. Our micro-scale datacenter pod is built for physical fidelity, not throughput; questions that genuinely require hyperscale will need partner access rather than our own hardware, and part of the value of the pod is discovering early which questions those are. And hardware assurance is a complement to model-level safety work, not a replacement for it: nothing in this agenda reduces the importance of alignment and evaluation research, and we would regard any framing that suggested otherwise as a misrepresentation of what this layer can do.
4. Organization & governance
4.1 Organizational Chart
AICS is a lean research organisation built around four technical research programs, a policy program, a fellowship program, and an operations function, overseen by an Executive Board. AICS employs a phased hiring timeline: core technical staff will be onboarded in Year 1 (targeting ~16 FTE lines, including the specialized Simulation/EDA Engineer and Hardware/Side-Channel Safety Researcher tracks), with expansion of the EDA-consortium engagement and dedicated Policy staff deferred to mid-to-late Year 2 (scaling to 22 FTE lines). The structure below maps each function to its lead and scope. (The organizational chart figure will be redrawn to reflect the revised program structure.)
4.2 Founding team: why this team
Aytunc Ilhan — Founder & Executive Director
- Electrical & Electronics Engineering degree plus a Strategy master’s (valedictorian). Brings a rare technical-plus-strategic base.
- Extensive experience in technology and policy work at NATO Headquarters and across its strategic commands, with a deep institutional network.
- 4 years at ASML, working with leading chipmakers across the EU, US and Asia. First-hand exposure to the most critical part of the supply chain.
- Authored the inaugural paper of Oxford’s Hardware & AI Governance group on verifiable semiconductor manufacturing; active across the US, UK, and Brussels AI-safety circles.
Mert Koc — Founding member and Head of Research
- Double master’s in AI and robotics; Fulbright scholar; AI expert and lead at NXP Semiconductors, a leading chip designer and manufacturer.
- Strong electronics engineering background; high context on AI safety; experienced directing multiple research streams.
Why this team. Together the founders combine AI, semiconductor knowledge, infrastructure security, strategy, and policy networks across industry, NATO-adjacent institutions, EU and Dutch policy circles, and the AI-safety ecosystem.
4.3 Board & advisory
The Stichting will be governed by an Executive Board (target three to five members, with an independent majority established over time) responsible for oversight, finance, and conflict-of-interest management, distinct from executive management. Specific board and advisory members to be confirmed; candidates exist within the founders’ network.
5. Operations
5.1 Operating model
A lean research organization with four technical research programs, a policy program, a fellowship program, and an operations function, run on a regular research-management cadence. We aim to hire seniority early (an experienced operations manager and senior researchers) rather than relying only on junior staff.
5.2 Location & facilities
AICS will establish its initial operations at the High Tech Campus Eindhoven (HTCE), possibly in direct affiliation with TU Eindhoven, placing the org within Europe’s leading deep-tech Brainport region. This immediate physical proximity to industry leaders like ASML and NXP is highly relevant to attract local talent, embedded knowledge, and networks.
5.3 Research infrastructure
In our first 12 months, AICS’s technical priority is to build a structured threat-discovery and mitigation funnel for future AI accelerators. We will begin by mapping potential injection, tampering, and adversarial workload attack modes across the AI hardware stack, using a combination of automated, agentic Electronic Design Automation (EDA) simulations, literature synthesis, expert input, and localized LLM/RL adversarial workload testing. From this broader threat landscape, we will select a smaller set of high-impact and high-likelihood attack modes for defensive design exploration. For the most relevant subset, we will synthesize and prototype defensive hardware layers, with the aim of demonstrating practical mitigations on representative accelerator or chip-design environments.
To execute this funnel, AICS will deploy a self-contained, air-gapped physical infrastructure architected as a Dual-Scale Emulation Environment. Rather than a homogeneous cluster, the setup mirrors the two most safety-relevant operational scales in the modern AI ecosystem:
Rather than attempting to match the massive throughput of a hyperscale commercial cloud — which no newly formed non-profit realistically can — AICS will construct a functional, micro-scale datacenter replica cluster built around the contemporary accelerator architectures currently deployed by top-tier AI labs, major clouds, and leading research universities. Focusing on contemporary production silicon (rather than legacy parts or abstract simulators) ensures that discovered vulnerabilities, physical side-channel profiles, and hardware fault-injection mitigations are immediately applicable to the real-world compute environments powering frontier models today.
High-performance workstation-class GPUs emulating edge and open-weight deployment environments, operating alongside a decoupled, CPU-heavy EDA simulation server. This bifurcated pool supports the reciprocal co-simulation loop for our digital twins and the empirical fault-injection testbed of Program 3, allowing us to map and mitigate hardware-mediated vulnerabilities such as data and parameter poisoning triggered by physical side-channels.
We will also explore potential collaborations with universities, hardware-security researchers, and accelerator labs. While standard philanthropic grants often favor capital-light cloud compute, localized bare-metal infrastructure is important for our hardware-safety methodology because it enables controlled adversarial testing, reproducibility, secure handling of potentially dual-use results, and internal proof-of-concept prototyping before broader engagement. More specific items include:
- Infohazard containment: discovering zero-day hardware vulnerabilities or systemic injection modes for frontier AI accelerators generates severe dual-use infohazards. Running automated attack-discovery simulations on commercial cloud providers risks telemetry leaks, Terms-of-Service violations, and unacceptable exposure of these vulnerabilities. An on-premise, air-gapped cluster ensures strict containment of offense-relevant findings until defensive architectures are implemented (see the institutional policy in Section 6.3).
- Deep-stack bare-metal access: cloud virtualization abstracts away the physical layer (firmware, schedulers, interconnects) where hardware-originating faults occur, and standard cloud ToS strictly prohibits the low-level physical fault-injection and EDA-level manipulation our research requires. A local cluster grants researchers bare-metal access to run live machine-learning workloads while observing true physical hardware behaviors. AI/ML execution runs on 4–16 datacenter GPUs, essential for running actual frontier AI inference workloads and adversarial ML scripts that trigger physical hardware states.
- Simulation infrastructure for digital twins: digital EDA workloads — specifically RTL and gate-level co-simulation — are strictly bound by single-thread CPU performance and massive memory requirements, not GPUs. We are provisioning 4–10 high-RAM, CPU-heavy nodes exclusively for the EDA team, providing the computational headroom to run emulated hardware behaviors simultaneously with deep-stack AI inference workloads.
- IP protection and value-add for co-design: to collaborate with labs building next-generation accelerators, we must ingest highly sensitive proprietary hardware designs to help them build defensive interceptors. A secure local cluster guarantees to partners that their pre-silicon IP remains totally isolated. Crucially, AICS operates as a low-friction partner: we provide manufacturers with robust hardware-layer resilience without requiring them to dedicate internal engineering effort or implement complex software-level changes — we do the heavy lifting of testing and validating physical safeguards directly within their design flows.
5.4 Security & responsible disclosure
Because AICS handles sensitive hardware-security findings, we operate a strong information-security posture (need-to-know access, secure storage, staff vetting) and a coordinated responsible-disclosure policy: we engage affected vendors before publication, observe embargoes, and publish defensive methods and findings rather than operational exploit detail. A dual-use review precedes external release of sensitive work. Section 6.3 sets out the institutional infohazard policy that operationalizes these commitments.
5.5 Partnerships & dissemination
We will build partnerships with universities, peer AI-safety organisations (including in the US and UK), standards bodies, and industry and policy institutions, leveraging the founders’ networks. Outputs are disseminated through papers, briefs, an annual convening, and public (or, where necessary, restricted) reports.
To incentivize cooperation from leading hardware manufacturers, AICS will employ a bifurcated disclosure strategy:
Industry-wide learnings: we will release generalized findings, hardware-agnostic vulnerabilities, and fundamental lessons learned in a sanitized, non-disclosure-compliant format to elevate the baseline security of the entire field.
Partner-exclusive solutions: the specific, high-fidelity models, threat-mitigation designs, and tailored testing architectures developed during a co-design phase will be provided exclusively back to the partner company. Collaborating with AICS thus offers a direct, proprietary competitive advantage in security without risking exposure of underlying IP.
6. Legal & administrative
6.1 Entity & status
The Lab will be incorporated as a Dutch foundation (officially referred to as “Stichting” in Dutch), a nonprofit form suited to public-benefit research. We intend to seek ANBI (public-benefit organisation) status; alongside its tax treatment, this non-commercial research status underpins the academic licensing route described in Section 7.4.
6.2 Governance & compliance
Governance separates board oversight from executive management, with a conflict-of-interest policy, financial controls, and an annual external audit. We will meet Coefficient Giving’s minimum standards for organisational policies (we confirm intent to review and comply before any grant payment), and maintain a code of conduct, safeguarding, and whistleblower policy.
We comply with the GDPR, minimise personal data, and apply data governance to testbed and experimental data. Employment follows Dutch labour law (contracts, pension, statutory leave and allowances). The Lab carries director-and-officer, professional-liability, and property (equipment) insurance.
6.3 Institutional infohazard policy & responsible disclosure framework
Given that AICS’s technical programs involve active red-teaming, hardware fault-injection, and the mapping of physical side-channel vulnerabilities on cutting-edge production substrates (including multi-tenant Trusted Execution Environments), the institute operates under a strict, mandatory institutional infohazard policy. To ensure that discovered physical vulnerabilities or substrate-level degradation pathways are never weaponized by malicious actors, AICS implements the following operational controls:
all raw signal analyses, side-channel leakage profiles, and potential exploit vectors generated within the Contemporary Datacenter Pod are hosted exclusively on physically isolated, air-gapped servers under strict, logged, need-to-know access control.
all research teams follow a standardized responsible-disclosure workflow with a minimum 90-day vendor window. When a substrate-level vulnerability or physical bypass is confirmed, a comprehensive technical remediation package is securely submitted directly to the affected hardware manufacturer (e.g., NVIDIA, AMD, TSMC) first.
public standards, architecture taxonomies, and open-source verification protocols are published only after the affected vendor has acknowledged the vulnerability and deployed mitigation pathways (such as microcode patches or structural masking guidance), ensuring AICS’s outputs exclusively elevate the global safety baseline without creating immediate deployment liabilities.
This section operationalizes, and takes precedence within, the general security posture described in Section 5.4; a dual-use review precedes any external release of sensitive work.
6.4 Intellectual property & publication
Default-open: research papers, datasets, and tools are published openly and, where appropriate, open-sourced, subject to the responsible-disclosure and dual-use processes in Sections 5.4 and 6.3. The Lab does not seek to monetise restricted IP in its grant-funded phase.
7. Financials & Compensation Philosophy
7.1 The ask & phased headcount scaling
The funding request is structured as a tiered, risk-mitigated ask: a €4.48M core base over 24 months and an optional additive stretch of €1.42M (€5.90M total) to fund the intensive physical lab requirements and modern accelerator hardware described in Sections 5.3 and 7.2. All figures are indicative and subject to change.
To maintain a sustainable burn rate while scaling institutional capacity, AICS employs a phased hiring timeline over the 24-month grant period. Core technical staff for the Hardware Identity, Compute Ownership, and Hardware Interception programs — including the specialized Simulation/EDA Engineer and Hardware/Side-Channel Safety Researcher tracks — will be onboarded in Year 1 (targeting ~16 FTE lines). Scale-up of the Verification-Oriented EDA consortium engagement and dedicated Policy Translation staff is strategically deferred to mid-to-late Year 2 (scaling to 22 FTE lines), ensuring foundational simulation research is stabilized before we expand.
7.2 Capital Expenditure Justification
While standard AI-safety grants often favor capital-light cloud compute, AICS requires upfront physical infrastructure. The proposed stretch budget incorporates the necessary CapEx for our digital-twin environments, the Contemporary Datacenter Pod, and Tier 2/Tier 3 testing. Securing air-gapped, bare-metal CPU/GPU clusters and specialized Electronic Design Automation (EDA) licenses is non-negotiable for safely probing deep-stack, hardware-originating faults without risking infohazard leaks or violating cloud provider terms of service.
7.3 Compensation & Talent Strategy
AICS operates in a highly competitive and highly constrained talent market. To build a credible, industry-native organization, we must recruit directly against frontier AI labs and top-tier semiconductor and AI-infrastructure firms for talent that understands both deep-stack AI inference and physical side-channel vulnerabilities.
Consequently, our compensation model is deliberately benchmarked against senior engineering and research leadership roles in the private tech sector — concretely, private semiconductor firms such as ASML and NXP, and frontier AI labs — rather than standard Dutch non-profit averages. We view competitive compensation as a structural requirement to guarantee the organization has the technical depth and industry respect needed to execute its mandate.
7.4 Operational Expenditure (OpEx) Optimization Strategy
A primary financial hurdle in hardware-security research is the licensing cost of commercial Electronic Design Automation (EDA) software, which can scale to €300,000–€600,000 annually for a team of our size. To maximize the leverage of philanthropic capital, AICS is executing a deliberate OpEx optimization strategy. AICS intends to secure academic and research-tier licensing from leading EDA vendors (e.g., via EUROPRACTICE), building on the non-commercial research-institute status described in Section 6.1. Successfully securing this status is expected to compress our EDA licensing OpEx to approximately €15,000–€40,000 per year.
Appendix A. The Funnel
Tier 1Tier 1: Taxonomy, Mapping and Prioritization
Tier 2Tier 2: Simulation and Verification of Threats and Defenses
Tier 3Tier 3: Prototype Demonstration
Notes
BloombergNEF (Mar 2026) projects capex of the 14 largest data-centre operators near $750bn in 2026, up from roughly $450bn in 2025, with 23+ GW of capacity under construction. https://about.bnef.com/insights/commodities/ai-data-center-build-advances-at-full-speed-five-things-to-know/
E.g., GPUHammer demonstrated the first practical bit-flip attack on NVIDIA GPUs, collapsing model accuracy from 80% to under 1% via user-level cloud access, with follow-on work showing targeted jailbreaks and cross-VM memory leakage over NVLink. The empirical case that hardware faults can subvert safety-relevant model behaviour is made. See https://www.gpuhammer.com/
More broadly, compromised firmware, counterfeit accelerators, and multi-tenant side-channels can do the same.
National AI Delta Plan, commissioned by the Dutch Ministry of Economic Affairs and presented November 2025: 52 recommendations, including flagship AI research institutes and a national computing-capacity plan. https://nltimes.nl/2025/11/24/dutch-experts-call-ambitious-plan-dominate-global-artificial-intelligence-race
See https://brainporteindhoven.com/int/
for additional context on the Brainport high-tech ecosystem.
While we will aggressively pursue these non-profit research discounts, our “Stretch” funding request conservatively reserves capital for standard commercial licensing. This ensures that our foundational digital-twin and shift-left research programs remain completely insulated from vendor approval timelines or shifting consortium rules. Any capital saved through research-tier licensing will be redirected straight into accelerating our Tier 3 hardware prototyping and expanding the bare-metal GPU/CPU cluster.