标签：#aiact

We shipped eight endpoints on api.moltrust.ch (v2.5) this week. Three implement EU AI Act obligations directly. This is the short version for people who want to call them; the full reasoning is on our blog ( https://moltrust.ch/blog/compliance-as-an-api.html ). Why no model in the loop: the Aithos LARA study (May 2026) placed twelve frontier models in simulated workplaces where the task required breaking EU law. Best model: 54% lawful runs. In the Art. 5(1)(f) scenario (emotion inference from workplace communications, prohibited), all twelve committed the violation. So the classifier is deterministic code branching on the pinned EUR-Lex text, and every response carries article references you can check yourself. POST /compliance/assess — use case + intended purpose + declared signals in, risk tier + obligations + article pins out. Evaluation order: Art. 5 prohibitions, Annex I route (Art. 6(1)), Annex III route (Art. 6(2)/(3)), Art. 50 transparency, minimal. The trap worth knowing: Art. 6(3) offers four derogation grounds, and its final subparagraph voids all of them for systems that profile natural persons. In the code that subparagraph is a branch; it cannot be skipped. curl -X POST https://api.moltrust.ch/compliance/assess \ -H "Content-Type: application/json" \ -d '{ "use_case": "Customer-support agent that reads inbound email and drafts replies", "intended_purpose": "Automated first-line support for consumer inquiries", "performs_profiling": false, "interacts_with_humans": true, "emotion_recognition": false }' POST /compliance/declaration — EU declaration of conformity as a W3C Verifiable Credential with the eight Annex V items, Ed25519-signed. Verify offline against https://api.moltrust.ch/.well-known/jwks.json ; no call back to us. anchor: true adds a sha256 commitment for batch anchoring on Base L2. POST /compliance/incident — records Art. 73 serious incidents and computes the deadline from the regulation: 15 days standard, 10 days for a death, 2 days for wid

Most RAG demos answer "what's the right chunk?" Very few can answer the two questions a regulator or an auditor will actually ask: Replay this decision — show me the exact, complete record of how this answer was produced. Reconstruct the past — what did your system know at the moment it answered, not what it knows now? I got tired of hand-waving at both, so I shipped two pre-registered, deterministic benchmarks alongside JAMES , my local-first, audit-native Graph-RAG. Pre-registered means the metrics, scenarios, and decision rules were locked before the numbers came in — no post-hoc story-fitting. RAB — Replayable-Audit Benchmark RAB measures whether your audit trail is good enough to replay a decision, with three deterministic metrics: Metric What it checks EU AI Act AC — Audit Completeness Is every decision-relevant event logged? Art. 10 RF — Replay Fidelity Can you re-derive the answer from the log alone? Art. 12 PC — Provenance Coverage Does every claim trace to a source? Art. 19 The three metrics map verbatim to EU AI Act Articles 10, 12, and 19 — record-keeping obligations that apply from 2026-08-02 (per Article 113). Scenario S1 result: AC RF PC JAMES 1.000 1.000 1.000 Baseline-0 0.275 0.000 0.000 (vanilla default-logging) The gap is the whole point. "We have logs" (AC 0.275) is not the same as "we can replay the decision" (RF 0). Default application logging gets you a partial event trail and zero replay/provenance — which is exactly the failure mode an Article 12 audit would surface. LRB — Lifecycle Retrieval Benchmark RAG facts go stale. A policy is superseded, a price changes, a spec is revised. LRB asks: when you query as of a point in time, do you retrieve the fact that was valid then , or whatever overwrote it? Three systems compared: V — Vanilla : no time handling. N — Naive-supersede : newest fact wins. J — JAMES : validity-window retrieval ( reconstruct_graph_at(t) ). The R@1 ordering V < N < J holds across 4 model families × 4 scale points (a 12.5×

Every week I see the same question in AI governance communities: "We already have NIST AI RMF implemented. Does that cover our EU AI Act obligations?" The honest answer is: sometimes yes, sometimes partially, and sometimes not at all. The problem is that nobody had built a clean, free, interactive tool that showed exactly which controls map to which, how strong those mappings actually are, and where the genuine gaps are. So I built one. Live tool: suhanasayyad.github.io GitHub: SuhanaSayyad / eu-ai-act-crosswalk-tool Interactive crosswalk mapping EU AI Act obligations to NIST AI RMF and ISO 42001 controls, with mapping strength indicators, gap analysis, and source links. 30 controls mapped. Free and open source. EU AI Act × NIST AI RMF × ISO 42001 - Interactive Compliance Crosswalk Tool An open-source tool that maps EU AI Act obligations to their equivalents in NIST AI RMF and ISO 42001, with mapping strength indicators, gap analysis, and source document links. Built for compliance teams, AI governance practitioners, and anyone trying to understand how these three frameworks relate to each other. Live demo: https://suhanasayyad.github.io/eu-ai-act-crosswalk-tool Built by: Suhana Sayyad | MSc Cybersecurity, TUS Athlone Why I built this Every organisation dealing with the EU AI Act is being asked the same questions: "We already have NIST AI RMF controls in place. Does that cover our EU AI Act obligations?" "We're pursuing ISO 42001 certification. Does that satisfy the regulation?" The honest answer is: sometimes yes, sometimes partially, and sometimes not at all. The problem is that nobody had built a clean, free, interactive tool that showed exactly which… View on GitHub What the tool does The EU AI Act / NIST AI RMF / ISO 42001 Interactive Crosswalk Tool maps 30 EU AI Act obligations to their nearest equivalents in NIST AI RMF and ISO 42001. For each mapping it shows a strength rating - Strong, Partial, Indirect, or No Equivalent - so compliance teams know which map