Skip to content

Regulated AI Navigator

Turn an AI use case into its full regulatory footprint — every domain it touches, from AI law and data protection to cyber, product safety and sector rules — with the obligations, the architecture and the evidence you owe, in about two minutes.

Community-curated knowledge graph — every claim carries its citation across law, engineering and governance. Every change traceable →

Start where you stand →Browse 78 profiles

Where do you stand? › Route 3 · Vendors & stack

I know which systems I need — who supplies them?

Pick the components you have to put in place. For each one you get the build-vs-buy reading and the market layer that supplies it, with the same scored recommendations and confidence the full analysis uses. Nothing is stored; the selection lives in the URL.

Target market(s)European UnionUnited States (federal)change

Legally-driven components are flagged when their requiring regulation sits outside your selected markets.

Target market(s)

Where will this system be used or placed on the market? The conclusion is derived for these jurisdictions — instruments that bind only elsewhere are left out.

Europe
North America
Latin America
Asia-Pacific
Middle East
Africa

Selected: European Union, United States (federal) · thin-coverage jurisdictions need verification

density

Step 1 of 2 — pick your components2 selected

WORM / Immutable Audit VaultUnified Incident-Response Runbook
Two-Tier Air-Gapped De-Identification Ingestion (3)
Deterministic Circuit Breaker with Reversible Shadow Execution (3)
Grounded Citational RAG (5)
Deterministic Document-Validation Pipeline (3)
Dual-Agent Guardian Topology (4)
Hardened Edge / IoT Pattern (3)
Constrained GAM with Differential-Privacy Tokenisation (2)
Glass-Box EBM with Monotonic Constraints (2)
Guarded RAG Pattern (2)
Human-in-the-Loop Core Pattern (1)
Tiered-Confidence Moderation Queue (1)
Agentic RDA Stack (6 Layers) (3)
Sandboxed Execution with SAST Gates (1)
Sovereign Resilient Enterprise Pattern (5)
Four-Layer TRiSM Enterprise Stack (2)
Cross-cutting components (22)

Step 2 of 2 — the vendor & stack view

1 of 2 selected components are covered by 1 market layer · 1 with no supplier layer in the graph.

Named vendors are community-maintained, disputable examples — not an endorsement. The stable object is the market layer. Compare with the reference stack for your regulatory profile →

Build or buy, per component (2)

Unified Incident-Response Runbook build in-house US-NYEUUS
No market layer in the graph supplies this component — treat it as in-house engineering (or propose the missing supplier layer).
Required by: New York RAISE Act, NIS2 Directive, SEC Cybersecurity Disclosure Rules (Item 1.05 Form 8-K) enacted — not yet applicablein forcein force
Legally required in EU, US (your selected markets); also required in US-NY, which you have not selected. Help verify coverage →
WORM / Immutable Audit Vault buy (products exist) EUDEthinUS
A Cryptographic Evidence & Audit Ledger product can carry this; the buyer's duties stay with you.
Required by: AI Liability Directive (withdrawn), BaFin MaRisk (Mindestanforderungen an das Risikomanagement), Bank Secrecy Act / FinCEN Program Rules, FINRA Rule 4511 (General Books & Records), Revised Product Liability Directive, SEC Rule 17a-4 (US Records Retention) withdrawn — no longer lawin forcein forcein forcein forcein force
Legally required in EU, US (your selected markets); also required in DE, which you have not selected. Help verify coverage →

Cryptographic Evidence & Audit Ledger — covers 1 of your components

Covers: WORM / Immutable Audit Vault. This layer supplies 3 components in the graph.
Confidence: moderate (68/100)
Community-maintained examples
Fact0 · Traccia
Filters to self-hostable, customer-VPC and open-source options when personal or confidential data cannot leave the EU.
ExampleSub-categoryWhat it doesHostingClaimed alignments
Fact0cryptographic evidence ledgerPositions itself as a tamper-evident ledger for AI decision records. Typical: decision records, audit trail.not checkedsupports Art. 12 record-keeping (claimed)
Tracciaaudit trail & traceabilityPositions itself around traceability of AI pipeline steps and artefacts. Typical: traceability, artifact lineage.not checkedsupports Art. 12 record-keeping (claimed)

Community-maintained, disputable examples — not an endorsement and not a ranking. Alignments are as claimed by vendors or the source compilation, not verified by RAIN; a certification is shown as a certification only where a certificate or registry reference is recorded.

Disclosure: RAI·N·avigator operates in this category too, so we have a commercial interest in any comparison here. That is why this layer maps product classes to control objectives and lists named products as community-maintained examples — we publish no rankings, no quadrants and no coverage assertions about any vendor, including ourselves.

Select on
Append-only guarantees and who can rotate or delete (including the vendor); anchoring mechanism (qualified timestamp, transparency log, notarisation) and whether verification works without the vendor; retention and export in a readable format at end of contract; throughput and cost at your event volume.
Why this confidence
  • 1 in-scope component of this use case is supplied by this layer (WORM / Immutable Audit Vault) — a direct supplied_by path in the graph.
  • The catalog use-case match is strong, so the component set this layer was derived from is reliable.
  • High-risk tier: this layer carries mandatory Chapter III duties, so some tooling in it is non-optional.
  • 2 community-maintained example vendors recorded on the layer node.
  • Selection metrics for this layer are documented, so the shortlist can be compared objectively.
  • Only 1 of 3 components this layer supplies are in your scope — evaluate a narrow subset of its capabilities.

No supplier layer recorded (1)

The graph knows no market layer for these — treat them as in-house engineering, or propose the missing supplier layer.
Unified Incident-Response Runbook
One procedure reconciling AI Act Art. 73, GDPR Art. 33 (72h), DORA and NIS2 (24h/72h) timelines and recipients.

Next step: Check which use cases this stack could carry →