The AI hardware landscape just got more complicated.
For years, procurement decisions centered on familiar metrics: TFLOPS, memory bandwidth, power consumption, and price-per-compute. But with New York's RAISE Act now signed into law and the EU AI Act in full enforcement, a new variable has entered the equation: regulatory compliance.
This isn't abstract policy talk. These laws carry real teeth—up to $30 million in penalties under RAISE, and €35 million or 7% of global turnover under the EU AI Act. For organizations deploying frontier AI systems, hardware choices now have legal consequences.
The Regulatory Landscape: What Just Changed
New York's RAISE Act
The Responsible AI Safety and Education Act, signed by Governor Hochul, targets "frontier" AI models—those trained with more than $100 million in compute resources. If your organization operates such models and serves New York residents, you're now subject to:
- Mandatory safety protocols: Published security protocols and risk evaluations, reviewed by qualified third parties
- Incident disclosure: Reporting serious incidents (model theft, security breaches) to the Attorney General and Division of Homeland Security
- Critical harm prevention: Documented safeguards against AI-assisted chemical weapons development or large-scale criminal activity
- Annual audits: Independent compliance reviews every year
The threshold matters here. Unlike California's vetoed SB 1047, RAISE focuses on the largest players—companies spending $100M+ on training compute. But derivative models trained on frontier systems for $5M+ also qualify, catching more organizations than the headline number suggests.
The EU AI Act
Meanwhile, Europe's AI Act enforcement began in 2025 with bans on "unacceptable risk" AI uses. The Act classifies AI systems into risk tiers, with critical infrastructure applications—energy grids, transportation, water systems—automatically designated high-risk.
For general-purpose AI models with systemic risk, the requirements are extensive:
- Cybersecurity protection: Both the model and its physical infrastructure must meet security standards
- Standardized evaluations: Model testing against defined benchmarks
- Incident tracking: Systematic reporting of malfunctions and safety events
- Technical documentation: Detailed descriptions of hardware/software interactions and development processes
Note the phrase "physical infrastructure." This isn't just about software—the EU explicitly cares about where and how your compute runs.
Hardware-Level Safety: From Theory to Requirement
Here's where things get interesting for compute architects.
OpenAI's head of hardware, Richard Ho, recently warned at the AI Infra Summit that future AI infrastructure will need hardware-level safety features, including real-time kill switches built directly into AI clusters.
"It has to be built into the hardware," Ho stated. "Today a lot of safety work is in the software. It assumes that your hardware is secure. It assumes that your hardware will do the right thing."
The Future of Life Institute's research on hardware-backed compute governance outlines what this might look like:
- Secure boot mechanisms: Cryptographic verification of system integrity at startup
- Runtime integrity checking: Continuous validation that systems haven't been tampered with
- Anti-tamper measures: Physical and logical protections against unauthorized modifications
- Remote attestation: The ability to verify system state from outside the hardware
This isn't science fiction. The Hardware Security for AI Accelerators market reached $1.87 billion in 2024 and is projected to hit $13.69 billion by 2033. Security IP cores—reusable logic blocks providing secure boot, runtime integrity, and anti-tamper functions—are already shipping in production silicon.
What This Means for Procurement
If you're evaluating AI infrastructure today, regulatory readiness should be part of the conversation. Here's a practical checklist:
Logging and Monitoring Capabilities
| Requirement | Why It Matters | Questions to Ask |
|---|---|---|
| Comprehensive audit logging | RAISE Act requires incident disclosure | Does the system log all inference requests with timestamps? |
| Model access controls | EU AI Act requires access management | Can you restrict and track who runs what models? |
| Anomaly detection | Both laws require incident identification | Does the platform flag unusual behavior patterns? |
| Log retention | Audit requirements need historical data | How long are logs stored? Can they be exported? |
Security Architecture
| Requirement | Why It Matters | Questions to Ask |
|---|---|---|
| Secure boot | Hardware integrity verification | Does the system verify firmware/software integrity at startup? |
| Secure enclaves | Protecting sensitive operations | Are TEEs (Trusted Execution Environments) available? |
| Network isolation | Preventing unauthorized access | Can AI workloads be air-gapped or network-segmented? |
| Physical security | EU AI Act covers "physical infrastructure" | What datacenter certifications apply (SOC 2, ISO 27001)? |
Operational Requirements
| Requirement | Why It Matters | Questions to Ask |
|---|---|---|
| Uptime guarantees | Critical infrastructure classification | What SLAs are offered? What's the incident response time? |
| Graceful shutdown | "Kill switch" capabilities | Can specific models or workloads be stopped without full system shutdown? |
| Disaster recovery | Business continuity under regulation | What's the RTO/RPO? How are backups verified? |
| Geographic compliance | EU data residency requirements | Where is data processed and stored? |
Datacenter Design Implications
For organizations building or expanding AI infrastructure, these regulations have architectural consequences.
Power and Cooling Considerations
AI hardware brings unique compliance challenges. Safety testing requirements now include:
- IEC 62368-1 compliance: Insulation, grounding, and fault protection for high-power AI accelerators
- Regional certifications: CE marking (Europe), UL/NRTL (North America), CCC (Asia)
- Environmental testing: High thermal stress and power consumption require validated operating ranges
Zoning for Compliance
Consider designing infrastructure with regulatory boundaries in mind:
- Frontier model zones: Dedicated areas for RAISE Act-covered workloads with enhanced logging and access controls
- High-risk AI zones: Isolated infrastructure for EU AI Act high-risk applications
- General compute: Standard AI workloads without special compliance requirements
This zoning approach lets organizations apply compliance overhead only where legally required, avoiding unnecessary costs for lower-risk workloads.
The Vendor Landscape
How are hardware vendors responding? The picture is mixed.
What to Look For
When evaluating AI servers and accelerators, consider asking vendors about:
- Compliance documentation: Do they provide materials supporting RAISE Act or EU AI Act compliance?
- Security features: What hardware-level security is built in (secure boot, TPM, attestation)?
- Audit support: Can they provide evidence for third-party compliance audits?
- Roadmap: Are hardware-level safety features planned for future products?
Most enterprise AI hardware vendors—including those tracked in the AI Hardware Index catalog—offer some level of security features. But "regulatory readiness" as a product category is still emerging.
The Cloud Alternative
Major cloud providers are arguably ahead here. AWS, Azure, and GCP already offer:
- Comprehensive logging and monitoring (CloudWatch, Azure Monitor, Cloud Logging)
- Compliance certifications (SOC 2, ISO 27001, FedRAMP)
- Geographic data residency options
- API-based access controls with audit trails
For organizations subject to RAISE or EU AI Act requirements, cloud deployment may offer faster compliance than building equivalent capabilities on-premises.
The Road Ahead
These regulations represent the first wave, not the final word.
CNAS research recommends that U.S. policymakers accelerate hardware-enabled mechanism (HEM) R&D through direct funding and public-private partnerships. DARPA, NIST, and the DoD's Microelectronics Commons are identified as key funders for this work.
What does this suggest for hardware buyers?
- Plan for evolution: Today's compliance requirements will likely expand. Choose infrastructure that can adapt.
- Build monitoring now: Even if you're not currently covered by RAISE or EU AI Act, logging and audit capabilities are increasingly baseline expectations.
- Engage with vendors: Push hardware providers on their compliance roadmaps. Customer demand drives product development.
- Consider hybrid approaches: On-premises hardware for control, cloud for compliance-heavy workloads.
The Bottom Line
AI hardware procurement used to be a pure technical decision. Now it's also a legal one.
For frontier AI developers subject to RAISE or organizations deploying high-risk AI under the EU AI Act, hardware choices carry compliance implications. Logging, security, and operational capabilities aren't just nice-to-haves—they're regulatory requirements.
The good news: the industry is adapting. Hardware security is a $1.87 billion market and growing. Vendors are adding compliance features. Standards are emerging.
The takeaway for compute architects: add "regulatory readiness" to your evaluation criteria. The hardware you buy today will need to support the compliance requirements of tomorrow.
