The Sovereign AI Stack in 2026: Architecture, Compliance, and the End of Cloud Dependency

Key Takeaways

• Compliance has become an infrastructure problem. In regulated sectors, AI architecture now determines how much legal, audit, and vendor risk you carry.
• The winning stack is bounded, not magical. Sovereign AI means local inference, self-hosted retrieval, internal logging, and explicit egress control.
• Local models reduce friction, not responsibility. You still need governance, documentation, and human review for high-impact use cases.
• Migration is operationally realistic. Most teams can pilot a sovereign workflow in 30 to 60 days without rebuilding their entire application stack.

Direct Answer: What is a sovereign AI stack in 2026?
A sovereign AI stack is a self-controlled AI architecture in which model inference, embeddings, retrieval, logs, and security controls run inside an organization’s trusted boundary rather than through third-party cloud APIs. In 2026, that usually means open-weight or auditable models, local or region-locked serving, self-hosted vector storage, explicit network egress rules, signed audit logs, and internal supply-chain verification. The point is not ideology. The point is to reduce transfer risk, vendor dependency, and audit complexity for regulated workflows.

Introduction: The Architecture Shift No One Planned For

In 2023, enterprise AI adoption followed a simple formula: send a prompt to a cloud API, receive an answer, and let procurement sort out the paperwork later. That pattern spread because it was fast, cheap to start, and easy to demo.

By 2026, that default is breaking down for any team handling sensitive data. Privacy regulators want demonstrable control over transfers and retention. Security teams want logs they actually own. Platform teams want predictable latency and fewer external failure points. Legal teams want less ambiguity around subprocessors, training exposure, and deletion guarantees.

That combination is what created the sovereign AI stack. It is not a rejection of cloud computing in general. It is a rejection of opaque inference paths for regulated data.

The decisive shift is this: AI compliance is no longer primarily about what policy you publish. It is about what your architecture can prove.

Why Regulation Is Now Shaping the AI Architecture

Cloud AI vendors optimized for scale and convenience. Regulators optimized for traceability, accountability, and lawful processing. In regulated environments, those priorities increasingly collide.

European Union

The EU AI Act has made documentation, risk management, logging, and human oversight central design requirements for high-risk deployments. At the same time, GDPR transfer rules still matter whenever prompts, files, or metadata leave the EEA. In practice, many teams are discovering that “region selection” is not enough if the broader inference path, support access, or subprocessor chain remains opaque.

One more complication: the EU’s 2026 Omnibus discussions created uncertainty around some high-risk AI deadlines. That uncertainty does not remove the underlying compliance burden. It simply means mature teams are building as if they may still need to evidence Articles 9, 10, 11, 12, and 14-style controls on short notice.

United States

The US has no single AI statute equivalent to the EU AI Act, but the practical pressure is still rising. HIPAA pushes healthcare organizations toward minimum necessary access, audit controls, and accountable business associate relationships. State laws such as CPRA and biometric or automated-decision rules raise the bar on retention, notice, and deletion. NIST’s AI RMF remains voluntary, but it has become a governance baseline for security and procurement teams that need structured evidence.

For US buyers, the lesson is straightforward: every third-party inference vendor creates one more contractual and technical dependency around sensitive data.

United Kingdom

The UK ICO has been clear that AI systems must still satisfy core UK GDPR duties such as lawfulness, fairness, transparency, and international transfer compliance. The UK has streamlined some transfer guidance and adequacy pathways, but that does not eliminate scrutiny. If a prompt containing personal or confidential data is processed by a foreign-controlled vendor, the organization still has to understand the transfer mechanism, retention policy, and practical chain of custody.

That is why UK finance, legal, and public-sector teams increasingly treat domestic or self-hosted inference as a governance advantage rather than a niche preference.

Bottom line: In 2026, the architecture you choose directly affects how much compliance work you must do later.

Core Architecture: The 5-Layer Sovereign Stack

A sovereign AI stack is not just running Ollama on a server. It is a deliberately bounded system where data, compute, and governance never cross untrusted perimeters. Here is the 2026 production blueprint, with layer-wise internal paths for buyers who want deeper implementation detail across Local LLMs, Self-Hosting, Law & Policy, Post-Quantum Cryptography, and Vulnerability Management.

Layer 1: Inference Boundary (Local and On-Device)

• Engine: Ollama 5.x, llama.cpp, or vLLM for high-throughput serving
• Model format: GGUF with 4-bit to 8-bit quantization, or AWQ where memory is tighter
• Hardware boundary: Apple Silicon with MLX, NVIDIA with CUDA or TensorRT, or AMD ROCm systems
• Sovereignty control: Zero external API calls during inference. Network egress is blocked at the OS or firewall layer so prompts and outputs remain in local memory or encrypted local storage
• Internal links: Local LLMs, How to Run AI Locally With Ollama, How to Optimize LLM Inference Speeds

This layer is where sovereignty becomes measurable. If inference never leaves the boundary, cross-border transfer exposure drops immediately and buyers gain control over latency, model pinning, and rollback mechanics.

Layer 2: Knowledge and Memory (Vector Storage and RAG)

• Vector database: pgvector, Qdrant, or ChromaDB
• Embedding pipeline: Local embedding models such as nomic-embed-text, BGE-M3, or Snowflake Arctic Embed
• Chunking and retrieval: Semantic search plus hybrid retrieval with BM25 and cross-encoder reranking
• Sovereignty control: Documents never leave the perimeter. Embedding inference runs on the same hardware stack and retention policies can be enforced through TTL, row-level controls, and audit triggers
• Internal links: Self-Hosting, Data Sovereignty, Sovereign Home Server Guide 2026

For infra buyers, this is the layer that usually carries the highest hidden risk. Contracts, clinical notes, source documents, and retrieval logs often matter more than the prompt text itself. Keeping RAG local closes the biggest accidental leakage path in enterprise AI.

Layer 3: Application and Orchestration

• Framework: LangGraph, CrewAI, or custom Python or Node.js orchestration services
• State management: Redis for session state, SQLite or DuckDB for ephemeral analytics, and task queues where concurrency is required
• API layer: OpenAI-compatible endpoints behind authenticated reverse proxies such as Nginx or Caddy
• Sovereignty control: Tool calls are scoped to local resources. External MCP or SaaS connectors require explicit consent, logging, and review gates. Human-in-the-loop approval stays at the application layer
• Local LLMs, Law & Policy, Why OpenClaw’s Local-First Architecture Is the Blueprint for Sovereign AI in 2026

This layer decides whether a sovereign deployment is actually governable. A local model attached to over-permissive tools is still a compliance and security problem. Buyers should insist on approval paths, scoped permissions, and attributable actions per user or workflow.

Layer 4: Security and Observability

• Logging: Structured JSON logs with model version, prompt hash, token count, user role, and workflow outcome
• Storage: WORM volumes or tamper-evident retention paths for audit trails
• Monitoring: Prometheus plus Grafana or Loki for local metrics and log aggregation
• Sovereignty control: Metrics are not exported to third-party SaaS by default. Logs are cryptographically signed for tamper evidence and access is controlled through RBAC with Keycloak or ZITADEL
• Zero-Knowledge, Self-Hosting, NIST AI RMF Implementation Guide for Local AI 2026

If you cannot show who ran which model against which corpus under which policy, you do not have a regulated AI platform. You have a prototype. This is the layer that transforms local AI into something a risk committee can approve.

Layer 5: Cryptographic and Supply Chain Boundary

• TLS and mTLS: Internal PKI via step-ca or equivalent service-to-service encryption paths
• SBOM generation: Syft and Trivy for containers, dependencies, and provenance scanning
• PQC readiness: Hybrid TLS 1.3 with X25519 plus ML-KEM for forward-looking key exchange
• Sovereignty control: Full software bill of materials remains auditable internally. There are no hidden subprocessors in the inference path, and keys can live in local HSMs or secure enclaves
• Post-Quantum Cryptography, Vulnerability Management, Zero-Knowledge Architecture: Why Standard Encryption Alone Fails 2026

This layer is where sovereign AI becomes an enterprise procurement answer rather than a local-dev story. Supply-chain visibility, artifact signing, and crypto agility are the controls buyers use to justify long-term deployment.

This architecture is not theoretical. Variants of it are already visible in EU healthcare networks, US financial compliance environments, and UK legal or public-sector stacks. What changed since 2024 is operational maturity: better logging, cleaner documentation, and deployment patterns that are no longer tied to a single hardware vendor.

Infrastructure Buyers: What Good Looks Like

Most sovereign AI articles stop at architecture diagrams. Infrastructure buyers need selection criteria. The practical question is not “can we run a model locally?” It is “can we run the workload we actually own, at the concurrency we need, with evidence an auditor will accept?”

The fastest way to evaluate a stack is to score it on six dimensions:

Buyer Question	What Good Looks Like in 2026	Red Flag
Can it run inside our boundary?	Full local inference, local embeddings, documented egress controls	”EU region” marketing with opaque subprocessors
Can we prove what ran?	Model version pinning, checksums, signed images, rollback support	Silent model updates or mutable tags
Can we operate it?	Metrics, tracing, structured logs, backup and restore procedures	CLI-only setup with no monitoring story
Can we govern access?	RBAC, SSO, service identities, approval gates	Shared admin tokens or flat network trust
Can we survive patch week?	SBOMs, vulnerability scans, artifact provenance	No dependency inventory, no patch workflow
Can we scale economically?	Known concurrency limits, model sizing guidance, hardware plan	”Bring any GPU” claims with no benchmark methodology

For infra buyers, the crucial maturity signal is boringness. The platform should look like enterprise infrastructure, not an AI hobby project. That means reproducible builds, documented failure modes, and predictable runbooks.

Deployment Profiles Buyers Actually Purchase

In 2026, most sovereign AI purchases cluster into three patterns:

Profile	Typical Hardware	Best For	Tradeoff
Single-team pilot	Apple Silicon workstation or 1 GPU server	Legal review, internal copilots, policy search	Limited concurrency
Department deployment	1 to 2 GPU nodes plus local vector store	Healthcare admin, compliance ops, analyst workflows	Needs stronger queueing and failover
Enterprise regulated platform	Multi-node inference tier, separate data tier, internal PKI, observability stack	Banks, hospital groups, public sector	Higher platform engineering overhead

That framing helps procurement teams avoid the most common mistake: buying hardware for model size alone instead of buying for users, concurrency, retention, and uptime targets.

Deployment Matrix for Technical Buyers

Enterprise buyers usually need a faster mapping from use case to topology than a narrative section provides. This matrix is the practical starting point:

Use Case	Recommended Topology	Latency Target	Data Tier	Control Priority
Private document Q&A	1 inference node plus 1 vector DB node	Sub-3s median	Local vector store	Residency and retrieval accuracy
Compliance copilot	2 inference nodes behind proxy plus signed logging	Sub-5s median	Local vector plus WORM logs	Auditability and rollback
Clinical or legal drafting assist	Dedicated inference tier with strict corpus isolation	Sub-5s median	Encrypted document and trace store	Access control and evidence retention
Analyst workflow automation	Orchestrator plus queue plus multi-model routing	Sub-8s median	Mixed relational and vector data	Tool scoping and throughput
Enterprise shared AI platform	Multi-node inference, HA proxy, internal PKI, observability cluster	SLA-driven	Segmented data plane	Uptime, governance, tenancy

For conversion-minded buyers, this is the real message: a sovereign AI stack is not a single-server science project. It is a platform shape you can size, price, govern, and expand in stages.

Sizing Beyond Model Headlines

Infra buyers should pressure-test four numbers before approving any deployment:

• Concurrent users: Peak simultaneous sessions matter more than total licensed seats.
• Context footprint: RAG-heavy workloads often bottleneck memory and storage IOPS before raw compute.
• Latency SLOs: A compliance assistant with a 10-second median response may still fail internal adoption.
• Audit retention: Signed logs, retrieval traces, and artifact histories create storage requirements that teams routinely underestimate.

The right buying motion is therefore capacity planning, not benchmark theater.

Hardware Tiers and Budget Reality

The most useful hardware guidance is not model-maximalist. It is workload-aligned.

Tier	Example Hardware Profile	Practical Model Range	Concurrent Users	Best Fit
Tier 1: Pilot	Apple M3/M4 Pro, 32GB to 64GB RAM, fast NVMe	7B to 14B quantized	1 to 5	Proof of value, legal review, policy search
Tier 2: Department	Single NVIDIA GPU server or high-memory Apple workstation	14B to 32B quantized	5 to 25	Compliance teams, internal assistants, RAG-heavy use
Tier 3: Multi-team	2 GPU nodes, separate vector DB, HA proxy	32B-class serving or mixed-model routing	25 to 100	Shared internal platforms with steady traffic
Tier 4: Regulated Enterprise	Multi-node cluster, isolated data plane, observability and PKI services	Mixed inference estate with pinned models	100+ or strict SLO segments	Banks, hospital groups, public sector

What matters commercially is not the headline model count. It is whether the tier matches your adoption path. Many teams overspend by buying for a future frontier model instead of funding the control plane, logging, storage, and support processes that actually make the deployment production-safe.

Enterprise Procurement Signals

If you are buying rather than tinkering, require these deliverables before signature:

• reference architecture with network boundaries,
• benchmark methodology with median and p95 latency,
• rollback and disaster recovery process,
• SBOM and vulnerability reporting format,
• support model for model upgrades and runtime patching,
• and a clear statement of where prompts, embeddings, logs, and admin access live.

That is the difference between a serious private AI platform and a vendor demo wearing compliance language.

Compliance Mapping: How Local AI Solves Cross-Border Friction

Cloud AI compliance usually fails at the data boundary. Sovereign stacks succeed at it because they reduce the number of legal and operational handoffs you need to explain.

Regulatory Requirement	Cloud API Reality	Sovereign Stack Reality	Vucense Subcategory Alignment
GDPR Article 5(1)(c) - Data Minimization	Vendor collects prompts, metadata, and telemetry in a vendor-controlled path	Only necessary data is processed locally with explicit retention TTLs	Data Sovereignty, Self-Hosting
EU AI Act Article 10 - Training and Validation Data Governance	Training provenance and downstream handling remain partly opaque	Local fine-tuning or retrieval datasets can be documented with consent, provenance, and deletion triggers	Law & Policy, Local LLMs
HIPAA 164.312 - Technical Safeguards	BAA may exist, but logging detail and control depth vary by vendor	Full audit trail, access control, encryption, and retention remain under organizational control	Data Sovereignty, Law & Policy
UK GDPR - Lawful Basis and Transparency	Cross-border processing often requires transfer analysis and detailed vendor review	Domestic or self-hosted processing supports clearer model cards, override procedures, and chain-of-custody evidence	Law & Policy, Zero-Knowledge
CRA 2026 and NIST SBOM Expectations	Vendor SBOMs may arrive late, incomplete, or redacted	Internal Syft or Trivy pipelines provide dependency provenance and faster CVE triage	Vulnerability Management, Post-Quantum Cryptography

The sovereignty advantage is not privacy theater. It is audit reduction.

When sensitive data never leaves your perimeter, you reduce four recurring burdens:

• vendor DPA negotiation cycles,
• cross-border transfer impact assessments,
• third-party audit dependencies,
• and data retention ambiguity.

You still need governance. You just stop outsourcing your evidence.

Buyer Reality: Cost, Procurement, and ROI

The commercial case for sovereign AI is rarely “local is always cheaper.” The real buyer advantage is more specific: predictable cost, lower legal friction, and less exposure to vendor pricing or policy changes.

Cloud APIs win when:

• workloads are bursty and low-volume,
• data sensitivity is modest,
• and time-to-first-demo matters more than long-term control.

Sovereign stacks win when:

• the same workflow runs every day,
• prompts and attached documents are sensitive,
• auditability has board-level visibility,
• or teams cannot tolerate vendor-side retention ambiguity.

Where the ROI Actually Shows Up

The savings are usually spread across four buckets:

• fewer transfer assessments and vendor reviews,
• lower repeat token spend on stable internal workflows,
• reduced rework from vendor model changes,
• and better reuse of an internal knowledge stack across multiple teams.

That means the strongest sovereign AI business case is usually not “replace ChatGPT.” It is “stabilize three to five expensive, recurring regulated workflows on infrastructure we can govern.”

Commercial Evaluation Checklist

Before approving any private AI platform, buyers should ask:

• What is the cost per month at expected concurrency, not lab benchmarks?
• Which components require paid enterprise support?
• What happens if we need to change models, vector stores, or identity providers in six months?
• Can we prove deletion, rollback, and retention behavior without a vendor ticket?
• Which logs, metrics, and artifacts remain available during an incident?

Those questions separate a credible sovereign deployment from an expensive proof of concept.

Enterprise CTA: What To Do Next

If your team is already reviewing AI vendor renewals, data transfer exposure, or copilots in regulated workflows, this is the point to stop treating sovereign AI as a future-state concept. The highest-return next step is a scoped architecture review of one workflow with real compliance pressure and measurable usage.

Start with:

• one workflow that already sends sensitive data to a third party,
• one success metric tied to cost, latency, or auditability,
• one hardware tier sized for real concurrency,
• and one rollback-safe pilot that procurement, security, and legal can all inspect.

That approach converts sovereign AI from an abstract strategy into a buyable platform decision.

Security Boundary: PQC, SBOMs, and Zero Trust

Sovereignty without security is just isolation. In 2026, the strongest operators are combining local AI with modern cryptography and measurable supply-chain controls.

Post-Quantum Readiness

The immediate PQC priority is not replacing every classical primitive overnight. It is identifying where long-lived sensitive data moves through the stack and making those paths crypto-agile.

For sovereign AI environments, the usual starting points are:

• hybrid TLS for internal control planes and administrative paths,
• signed model artifacts,
• stronger key management for log stores and secrets,
• and inventorying any long-retention encrypted archives.

NIST’s finalized ML-KEM, ML-DSA, and SLH-DSA standards give security teams a stable naming and migration reference point. The practical 2026 posture is hybrid first, especially for systems carrying legal, healthcare, or financial records with a long confidentiality horizon.

SBOMs and Provenance

Self-hosting does not remove supply-chain risk. It makes it visible.

Teams running sovereign AI in production now routinely generate:

• container SBOMs with Syft,
• dependency scans with Trivy or Grype,
• signed images with Cosign,
• and deployment manifests pinned to exact versions.

That matters operationally. When a critical CVE lands in a tokenizer library, inference runtime, or reverse proxy, you can answer “where are we exposed?” in minutes instead of waiting for a vendor email.

Zero-Trust Inside the Perimeter

The sovereign model is sometimes misread as “everything is local, so internal trust is enough.” In practice, mature stacks do the opposite. They apply zero-trust discipline inside the perimeter:

• mTLS between services,
• explicit service identities,
• rate limits at the proxy,
• least-privilege tool access,
• and tamper-evident audit trails.

The goal is not just to keep outsiders out. It is to prevent accidental privilege creep and silent lateral movement inside the system you now control.

Industry Deployment Patterns

The same architectural logic applies across sectors, but the priority order changes depending on the data type and audit model.

Healthcare

Hospitals and health platforms use sovereign stacks for documentation assistance, triage support, coding support, and patient communication. The key requirement is that protected health information never drifts into unapproved consumer tools or opaque third-party inference paths.

Typical focus areas:

• minimum necessary access,
• clinician override logging,
• segregation between inference, records, and analytics,
• and strong approvals around any autonomous actions.

Financial Services

Banks, insurers, and compliance teams care less about novelty and more about repeatability. They use sovereign stacks for document review, policy search, suspicious activity analysis, and explainability support around decision workflows.

Typical focus areas:

• reproducible model versions,
• human approval gates for high-impact outputs,
• immutable audit trails,
• and documented risk controls for bias, drift, and misuse.

Typical buying trigger:

• replacing recurring external review spend with internal AI-assisted workflows,
• consolidating fragmented vendor copilots,
• and reducing risk around sensitive transaction narratives or KYC material.

Legal and Compliance

Law firms and internal legal teams increasingly want local RAG for privileged documents, discovery support, and contract review. Here the central issue is not just personal data. It is preserving confidentiality and limiting unnecessary third-party exposure.

Typical focus areas:

• strict matter-level access control,
• signed logs,
• deletion on request,
• and explicit separation between privileged corpora.

Typical buying trigger:

• matter-level confidentiality,
• demand for faster document review without privilege leakage,
• and pressure to keep client material out of general-purpose AI SaaS tools.

Public Sector and Critical Infrastructure

Government and infrastructure operators are often driven by domestic processing requirements, procurement restrictions, and resilience planning. They use sovereign stacks where public accountability and national dependency risk matter as much as privacy.

Typical focus areas:

• domestic hosting,
• hardened clusters,
• supply-chain evidence,
• and longer-term PQC migration planning.

Typical buying trigger:

• domestic sovereignty mandates,
• procurement pressure to reduce foreign model dependence,
• and the need for offline or degraded-mode operation during disruption.

Migration Playbook: Cloud API to Sovereign Inference in 30-60 Days

The fastest failures happen when teams try to “replace all AI” in one move. The successful pattern is phased migration with one measurable workflow at a time.

Phase 1: Inventory and Risk Classification

Map every workflow touching third-party AI. Identify the data class, business owner, legal basis, and user population. The output should be a practical inventory, not a slide deck.

Phase 2: Local Inference Pilot

Choose one workflow with real value but limited blast radius. Compare a local model against the current cloud path for latency, answer quality, failure cases, and operational burden.

For infra buyers, this is where you benchmark the stack honestly:

• median and p95 latency,
• throughput per hardware profile,
• retrieval precision on internal documents,
• and operator effort to patch, monitor, and roll back.

Phase 3: RAG and Knowledge Integration

Move embeddings and vector search on-premise. Test retrieval quality before scaling model size. In many regulated workflows, better retrieval beats a larger general-purpose model.

Phase 4: Security and Audit Hardening

Add reverse proxy policy, egress control, RBAC, signed logs, backup policy, and SBOM generation. This is the step that turns a pilot into something audit-ready.

Phase 5: Production Cutover

Route one live workflow to the sovereign stack. Keep rollback options, version-pin the model, measure user outcomes, and document every governance decision while the deployment is still small enough to understand.

Critical success factor: Start with one workflow that is painful enough to matter and constrained enough to govern. Prove that sovereignty improves both control and operations, then expand.

Final Note: Control Is the New Scalability

The cloud AI era sold infinite elasticity. Regulated buyers discovered the hidden trade: dependency, opaque retention, and governance you cannot fully inspect. Sovereign AI changes that equation. It gives enterprises a stack they can price, secure, audit, and explain.

For B2B buyers, that is the real conversion point. You are not buying local inference for ideology. You are buying lower audit drag, clearer data custody, and a platform you can still operate when vendor terms, model behavior, or regulatory expectations shift.

If your organization is already budgeting for AI in 2026, the strategic question is no longer whether you will pay for intelligence. It is whether you will rent it on someone else’s terms or deploy it inside a boundary you control.

Frequently Asked Questions

Does local AI inference guarantee GDPR or EU AI Act compliance?

No. It reduces transfer and vendor-exposure risk, but compliance still depends on lawful processing, oversight, documentation, and evidence.

Can self-hosted LLMs match cloud API performance?

For document-heavy and domain-specific workflows, often yes. For broad frontier generation and massive concurrent traffic, cloud platforms may still lead on raw scale.

How do I update models without breaking compliance?

Version-pin models, test in staging, record provenance, document performance changes, and keep a rollback path. Reproducibility matters as much as benchmark gains.

Is PQC mandatory right now?

Usually no. But for data that must remain confidential for many years, hybrid planning is prudent now rather than later.

What hardware is enough to start?

A serious pilot can begin with 32GB to 64GB RAM, fast NVMe storage, and either Apple Silicon or a modern NVIDIA GPU. Production sizing depends more on concurrency, retention, and isolation requirements than on the headline model name alone.

What should a buyer ask a sovereign AI vendor or integrator?

Ask for benchmark methodology, not just screenshots. Require model versioning, rollback mechanics, SBOM output, retention controls, observability examples, and a written explanation of where prompts, embeddings, logs, and support access actually live.

Related Articles

• Why OpenClaw’s Local-First Architecture Is the Blueprint for Sovereign AI in 2026
• NIST AI RMF Implementation Guide for Local AI 2026
• EU AI Act Developer Compliance Guide
• Zero-Knowledge Architecture: Why Standard Encryption Alone Fails 2026
• Sovereign Home Server Guide 2026

Sources & Further Reading

• Council of the European Union - Artificial Intelligence: Council and Parliament agree to simplify and streamline rules - 2026 AI Act timing and policy changes
• NIST AI Risk Management Framework - Governance baseline for trustworthy AI
• NIST AI RMF Generative AI Profile - GenAI-specific risk categories and controls
• ICO - A brief guide to international transfers - UK restricted transfer guidance
• ICO - Receiving personal information from the EEA - UK adequacy context after 2025 renewal
• NIST FIPS 203 - ML-KEM standard
• NIST FIPS 204 - ML-DSA standard
• NIST FIPS 205 - SLH-DSA standard