# Ansvar AI — full site content > Generated at build time from the prerendered site. One section per > indexable page: canonical URL, title, meta description, then the page's > main-content text. The curated catalog with per-page summaries is at > https://ansvar.eu/llms.txt. ## Ansvar AI — Auditable AI for legal, regulatory & security teams URL: https://ansvar.eu/ Use Claude, Copilot, Cursor or your own agent to research verified law and licensed standards — and produce cited DPIAs, threat models, TARAs and gap analyses. For compliance, legal & security teams Do regulated work in the AI you already use. Defend every finding. Ansvar grounds Claude, Microsoft Copilot Studio, Cursor, and your own agents in verified law, standards, and threat intelligence — then runs the work: DPIAs, threat models, TARAs, gap analyses. Every claim cites its source. Where no verified source exists, the gap is marked, not papered over. Read a complete gap analysis Start free Add to Claude €0 to start · no card · sign in with Google, Microsoft, or email · connect in minutes. Paid plans from €29/mo. Cited or unresolved. Never quietly guessed. 49 Jurisdictions, licensing-audited 262 Security frameworks 5.8M Legal provisions, citable the deliverable Every line, anchored. This is what lands back in your AI client — prose you can defend, line by line. DORA / NIS2 gap analysis — incident response 10 verified · 1 marked Report major ICT incidents within regulator deadlines DORA Art. 19(4) Classify incidents against harmonised materiality thresholds DORA Art. 18(1) 24-hour early warning for significant incidents NIS2 Art. 23(4) Test ICT response and recovery plans annually DORA Art. 11(6) Personal-data breach notification within 72 hours GDPR Art. 33(1) Sector regulator guidance (DE) — no verified source marked unresolved + 5 more requirements in the exported report The unresolved row is the product working: when no verified source exists, Ansvar marks the gap instead of writing prose around it. Read the full samples: Threat model · DPIA · Gap analysis · AI Act readiness · Deferral dossier How it works Three ways in. Ansvar is a gateway your AI client connects to — Claude, Microsoft Copilot Studio, Cursor, over the Model Context Protocol (MCP) — with the same citation contract at every depth. The one prerequisite is a client that speaks MCP, which those three do. No new chatbot to learn, and the platform core is EU-hosted. Pick the depth the job needs — and if you are new, the quickstart takes you from nothing to a cited answer in five steps. 1 Ask — a cited answer across the sources in your scope "Using Ansvar: which incident deadlines apply to us under DORA and NIS2?" One question reaches law, regulation, and standards together; every result carries its source, and failed lookups stay visible. 2 Run — a structured assessment of your system or documents Describe a system and get a STRIDE or LINDDUN threat model, or an automotive TARA. Upload your own documents and run a DPIA, gap analysis, or tender review with paragraph-level, tamper-evident citations — the exportable document itself, not a chat transcript. 3 Deliver — an Ansvar practitioner signs it When an audit, a customer, or a regulator needs a named expert behind the document: fixed scope, a quote and a date in writing after one 30-minute call. Same gateway, same refusal discipline — a senior reviewer validates and signs every finding. See how you use Ansvar Worked examples with real output How the gateway works under the hood → · Compare plans and workflow limits → · Or have Ansvar deliver it → Watch · 1 min 49 Fluent and correct are not the same thing. The same compliance question asked twice — once of a general-purpose agent, once through Ansvar — and what changes when every claim has to carry its source. One minute forty-nine, including the part where it says what it does not have. Your browser does not support video. Download the film . Play with sound New module · ISO standards · Available now ISO/IEC 27001, 42001 and more — cited, not paraphrased Ansvar serves selected clause and control text of five ISO standards through the gateway, licensed from SIS — the Swedish Institute for Standards. Your AI client cites the controls in gap analyses, threat models, and audits, attributed to the source standard. Any standard SIS publishes can be licensed in on request. SS-EN ISO/IEC 27001:2023 · SS-EN ISO/IEC 27002:2022 · SS-EN ISO/IEC 27005:2024 · SS-EN ISO/IEC 42001:2026 · SS-ISO/SAE 21434:2021 See the standards module → Who does what The judgment stays yours. You scope it → your assistant works it → Ansvar grounds it → you sign it . Not another chatbot, and not a replacement expert — the evidence layer under the assistant your team already uses. Wire it into the agents you run. One MCP endpoint over OAuth 2.1 — no SDK, no scraping, no server-side model. Quotas are sized for agents: a seat can belong to a person or to an agent. Quickstarts for Claude, Microsoft Copilot Studio, Azure AI Foundry, and Cursor. Read the docs Connect a client Machine-readable: llms.txt · coverage.json · .well-known/mcp.json — and every served row carries its citation envelope: source, publisher, license. Built for your field The evidence and workflows your sector depends on. Each sector pack combines the law and regulations that bind you, the standards mappings and live threat intelligence your field runs on, and the workflows that turn them into cited, exportable evidence — for compliance, privacy, and security teams, and the consultants who serve them. Automotive Vehicle cybersecurity engineering, TARA, and type-approval evidence. Privacy DPIA, privacy-by-design, transfers, and data-subject rights — grounded in GDPR. AI governance EU AI Act role classification, obligations, and conformity readiness. Security AppSec, infrastructure security, and product-security obligations. Healthcare Medical-device regulation, clinical data, and special-category privacy. Industrial / OT OT security, robot-cell safety, and live ICS advisory enrichment. Financial DORA, MiCA, PSD2 and the prudential stack — at article level, with the technical standards. Public sector Procurement lawfulness, public-body AI duties, and administration compliance. Drone / UAS Drone operations, product security, threat modelling, and counter-UAS. Robotics Robot and cobot safety, machinery conformity, and the security of the robot stack. Rail Railway cybersecurity and signalling safety, from CLC/TS 50701 zones to the safety case. Energy Grid and generation compliance, anchored on NIS2 essential-entity duties. Agri & machinery Autonomous-machinery safety and the AI duties that ride on top. All sectors → · 49 jurisdictions, 262 frameworks — see the full coverage → Featured in Listed in OWASP GenAI Security Project AI & Agentic Red Teaming Solutions Landscape ↗ Scope & Plan · Govern · Q2 2026 Used by regenold × W&B Weave Reliable AI Agents in regulatory life science workflows ↗ Our EU Regulations MCP as the agent's grounded, cited data backend · Mar 2026 Why Ansvar What auditable actually means We do not answer without sources. We do not hide failed lookups. The product is the audit trail. 01 Complex reasoning, not keyword search Threat models, gap analyses, and legal questions that span standards, regulations, and internal policies — answered across jurisdictions in one pass, with every claim tied to the exact source. 02 Auditability is the product Every answer carries its sources. Every workflow carries its trace. When a source is unavailable, we show it — we do not invent. Every corpus reports its content freshness and the fleet is monitored daily, so stale law surfaces instead of hiding. The gateway guarantees the evidence; your client writes the prose around it. 03 EU-hosted core. Licensing-audited. Private. Production and primary data storage run in the EU (Hetzner, Germany & Finland); edge and encrypted off-site backups are fully disclosed on our subprocessors page . Every source we serve is licensing-audited — text we have the right to serve, cited verbatim. Nothing you send Ansvar trains anyone’s model; your assistant’s own model traffic never passes through us. 04 Your documents, cited like law Upload a policy, contract, or tender and every claim about it cites the exact paragraph — hash-anchored, so it stays provable months later, even after the document changes. Evidence, not chat-with-your-PDF. Counsel, DPOs, and bid teams run their own files through the same citation contract as the statutes. Design partners The engine works today. We take on a few teams per sector to tune it to their world — hands-on, with a direct line to the founders. See the program → Run the work. Defend the result. Use Ansvar yourself, or have a practitioner deliver the completed assessment. Start free Compare plans Fixed-scope expert engagements — a quote and a date in writing after one 30-minute call. --- ## Connect your AI agent to cited law — Quickstart · Ansvar AI docs URL: https://ansvar.eu/docs/quickstart Connect Claude, Copilot, Cursor or any MCP client to the Ansvar gateway and get cited answers from EU and national law — five steps, free tier, no SDK. Quickstart Connect your AI client once and instruct it well: the gateway returns results with citations attached — or an explicit no-match, never a silent gap — and the instructions below make your client pass that honesty through. Five steps take you from nothing to a cited answer you can check. There is no SDK to install and no API key to paste: one URL, OAuth in the browser, and your client registers itself. step 1 · connect Connect a client The gateway speaks MCP over HTTP at a single endpoint — https://gateway.ansvar.eu/mcp . You do not need IT to install anything; you need IT to allow one connector. Two prerequisites: an Ansvar account (sign in with Google, Microsoft, or email and accept the business-use terms — no card, no VAT entry; start at pricing ), and an AI client that allows custom MCP connectors — some client plans gate this, and the Setup guide lists the per-client requirements. claude desktop · claude.ai One click from the connector directory Ansvar is a listed Claude connector: open the listing , press Connect, sign in. Or add it by hand — Customize → Connectors → Add custom connector. Either way OAuth runs in the browser: Dynamic Client Registration plus PKCE. Approve once, then ask. To give your agent standing instructions to route bare compliance questions — no per-message “Using Ansvar” lead — also install the Using Ansvar routing skill (a ready-made ZIP, uploaded once under Settings → Skills). Copy Name: Ansvar URL: https://gateway.ansvar.eu/mcp claude code One command Registers the gateway as an HTTP MCP server. The first tool call opens the consent flow. bash Copy claude mcp add --transport http ansvar https://gateway.ansvar.eu/mcp The --transport http flag is required — without it the CLI defaults to stdio and the server name resolves against a binary that doesn't exist. Then start Claude, run /mcp , choose Authenticate. cursor · vs code One JSON block each Same endpoint, same flow — but the two configs differ. Cursor reads ~/.cursor/mcp.json with an mcpServers key; VS Code (Copilot agent mode) reads .vscode/mcp.json with a servers key. They are not interchangeable. Cursor — ~/.cursor/mcp.json : json Copy { "mcpServers": { "ansvar": { "url": "https://gateway.ansvar.eu/mcp" } } } VS Code — .vscode/mcp.json : json Copy { "servers": { "ansvar": { "type": "http", "url": "https://gateway.ansvar.eu/mcp" } } } first tool call triggers the OAuth consent flow — tier comes from your account (Free / Solo / Premium / Team / Company) Any MCP-capable client works — these are the ones we test every release. For ChatGPT see Connect ChatGPT ; for Gemini see Connect Gemini ; for Azure AI Foundry see Connect Azure AI Foundry ; for Continue and Open WebUI see the full Setup guide ; for Copilot Studio see its own walkthrough . step 2 · instruct your agent The 60 seconds that decide whether answers are reliable. A connected client with no instructions will still answer from memory — fluent, uncited, unverifiable. These four instructions turn the same client into a research assistant that answers only from cited sources. Paste this into your client's instructions field: Copy You are a compliance research assistant. Answer legal, regulatory, and security-standards questions only from Ansvar tool results, never from your own knowledge. For every legal, regulatory, or standards question: 1. Call the search tool, always with a scope: jurisdictions=["SE"] (adapt to your market; add "EU" for EU regulation - GDPR, NIS2, the AI Act), or frameworks=["GDPR"] for one EU framework across the board. On the Free plan, pass exactly one jurisdiction or framework per call. 2. Never pass the user's whole question as the query. Reduce it to 1-3 legal key terms in the language of the law you are searching - Swedish terms for Swedish law. Try alternative terms as separate searches. If a multi-concept query returns nothing, split it into one search per concept. 3. If a search returns nothing, retry once with a synonym or a broader term, then retry with allow_broadening=true and label any relaxed matches as such. 4. Cite every answer: law, article, and source URL from the results. If the results do not contain the answer, say which searches you ran and that you will not answer from memory - never invent a source. Where to paste it: Claude — Project instructions (or profile custom instructions); Claude Code — CLAUDE.md ; Cursor — Project rules; VS Code — .github/copilot-instructions.md ; ChatGPT — Custom instructions; Copilot Studio — the agent's Instructions field. Why each rule exists, a Dutch variant, and auditor-ready output patterns: Instruct your agent — the full guide. For a complete task — CRA product duties, EU incident reporting — you can skip the pasting entirely and give your agent a ready-made skill instead. step 3 · first question The first answer carries its sources. There is no LLM inside the gateway. It routes each call to the servers in scope, fans out in parallel, and returns results with citations attached. Your client reasons; the gateway supplies evidence. Type one of these, exactly as written — each needs only a single source, so it fits every plan's scope, including Free: Using Ansvar: what does the GDPR say about the right to erasure? Using Ansvar: what are Sweden's consumer-protection laws? Using Ansvar: which UK statute governs data protection? Naming Ansvar in the question makes your client call the gateway instead of answering from its own memory. A good answer names the law, the article, and links the official source. That is the product — not the answer, the citation. Claude · connected to gateway.ansvar.eu > Using Ansvar: what does DORA require for ICT incident classification? → search("ICT incident classification", jurisdictions=["EU"]) ← eu-regulations · 200 · 3 items · 3 verified Classify incidents by clients and counterparts affected, duration, geographic spread, data losses, criticality of the services affected, and economic impact. DORA Art. 18(1) Major incidents start the reporting chain: initial notification, intermediate report, final report. DORA Art. 19(4) fan-out · 4 of 224 servers in scope · bounded per-source deadlines · 3 verified · 0 unresolved — counts illustrative, fleet size live step 4 · check it's real Sixty seconds of verification. Ask: "Call get_my_capabilities and tell me my plan, quota, and add-ons." — catches a wrong-account connection immediately. Ask: "Using Ansvar: what does the GDPR say about data minimisation? Cite the article." — expect Article 5(1)(c) with a source link. Then ask one question in your market's own language — expect the national provision, cited in that language. The grounding check — paste: "Which Ansvar source did you query, and which article number is this from? If you didn't query Ansvar, say so explicitly." You are set up when your client visibly shows an Ansvar tool call and the answer names its source, the article or section, and links it. No tool call means the assistant answered from memory — go back to step 2. Lost, or want a guided look around? Ask your assistant to run the ansvar-tour prompt for a guided first session — it walks the tools, corpora, and a first cited query. Free-tier safe. (ChatGPT and other clients without MCP prompt support: ask it to call describe_capabilities with section="tour" .) step 5 · from answers to deliverables Cited answers are the floor. Workflows produce review-ready documents. DPIAs, threat models, gap analyses, tender reviews — claims carry their citations, and anything the sources cannot support is explicitly marked unresolved instead of papered over. Citations make the work checkable; your experts stay the ones who sign. The free tier is real (100 search calls/day scoped to one jurisdiction or one framework per question, and 1 workflow run a month on a system you describe — threat model, gap analysis or DPIA) and exercises the full connect flow — sign up at pricing . Solo (750/day, 2 runs a month) unlocks multi-source fan-out across the full fleet; Premium (5,000/seat/day) adds the legal evidence layer (case law, preparatory works, agency guidance) and raises the allowance to 5 workflow runs a month across the full interview-grounded catalog — LINDDUN threat models and TARA join the teaser set on a system you describe. Workflows on your own documents (gap analysis, DPIA, tender review) and unwatermarked branded exports are Team and Company tiers — see Your first gap analysis . Start one by asking: "Using Ansvar, help me run a GDPR Article 35 DPIA for our new analytics feature." It runs on every plan against a system you describe; grounding it in your own uploaded documents starts at Team. Worked examples: use cases . under the hood · citation contract Every item arrives with its provenance. the citation contract The gateway does not paraphrase sources into anonymity. Each served item carries three fields, always: _citation.source_url · where the text lives _citation.publisher · who issued it _citation.license · what you may do with it Two envelopes travel with every payload: served source items carry _citation.* provenance, and synthesized claims carry the attribution through from the items they rest on — the citation block shown below. Failed lookups return errors — never silence. A claim the fleet cannot verify arrives marked unresolved , not papered over; see What is the gateway for the design rationale. refusal discipline · unresolved beats invented under the hood · wire format One claim, on the wire. What your client receives. The claim and its anchor travel together — strip one and the other is useless by design. citation envelope · one claim { "claim": "Incidents are classified by clients affected, duration, geographic spread, data losses, criticality, and economic impact", "citation": { "source": "dora", "article": "18(1)", "url": "https://eur-lex.europa.eu/eli/reg/2022/2554#art18", "verified": true } } served items additionally carry _citation.source_url · _citation.publisher · _citation.license under the hood · tool reference A small surface, on purpose. Seven calls cover most sessions. Tool What it does search Full-text search across in-scope sources, routed by jurisdiction and sector. Every hit carries its citation. get_provision One provision, verbatim, at article level — with source URL, publisher, and license. list_coverage What is live right now: jurisdictions, sources, and counts, machine-readable. validate_citation Round-trips a citation against the source corpus before you rely on it — a deterministic, non-model check: article numbers resolve, anchors exist, the URL returns the cited text. search_regulatory_updates What regulators newly published (EUR-Lex OJ-L, Commission, EDPB) — typed records with original-publisher deep links, for monitoring what's new. Premium and above. describe_capabilities The caller’s own view: tools, sources, and limits for the authenticated tier. search_guidance Agency guidance from regulators, alongside the statute — part of the legal evidence layer, Premium and above. excerpt — run describe_capabilities for the live listing What tier limits look like in your client Tools outside your tier are absent from tools/list and return JSON-RPC error -32601 (method not found) if called anyway. Quota and cap violations — the free tier's 100 searches per day, for example — return JSON-RPC error -32000 with data.cause = "cap_exceeded" , not an HTTP 429. Both arrive as structured errors your agent can read and relay. Next Quick tips --- ## Setup · Ansvar AI docs URL: https://ansvar.eu/docs/setup Per-client connect recipes for the Ansvar gateway — one URL, OAuth in the browser, no API keys. Setup One URL, one OAuth flow, five client recipes. The gateway speaks MCP over streamable HTTP at https://gateway.ansvar.eu/mcp and registers each client via Dynamic Client Registration — there are no API keys to manage. Undecided on a client — or picking a model? See Clients and models . And once connected, give the agent its instructions: Instruct your agent . Claude Desktop and Claude (web) One click: Ansvar is listed in the Claude connector directory — open the listing, press Connect, sign in. Manual path: Customize → Connectors → Add custom connector. Copy Name: Ansvar URL: https://gateway.ansvar.eu/mcp Save. Claude opens a browser for OAuth at auth.ansvar.eu . Approve the consent screen; the connector flips to Connected and tokens refresh silently after that. Claude Code bash Copy claude mcp add --transport http ansvar https://gateway.ansvar.eu/mcp Then start Claude, run /mcp , choose Authenticate. The token lands in ~/.claude.json . VS Code (Copilot agent mode) Two ways — the settings UI or the config file. Both end at the same browser login. From the settings UI: open the Command Palette, run MCP: Add Server , choose the HTTP server type, and paste the URL: Copy https://gateway.ansvar.eu/mcp Or edit .vscode/mcp.json directly: json Copy { "servers": { "ansvar": { "url": "https://gateway.ansvar.eu/mcp" } } } Either way, trigger a Copilot agent action that touches an MCP server — VS Code opens the OAuth flow on first use. Sign-in fails with “Invalid scopes”? Remove the server and add it again. That forces a fresh registration and clears the error. Cursor Settings → MCP → Add Server. Copy Name: ansvar URL: https://gateway.ansvar.eu/mcp Cursor opens the OAuth flow when you save the server entry. For the mcp.json file locations, plan gating, and troubleshooting, see Connect Cursor . Gemini CLI bash Copy gemini mcp add --transport http ansvar https://gateway.ansvar.eu/mcp Then start gemini , run /mcp auth ansvar , and approve the browser login. Requires gemini-cli v0.44.0+ — earlier versions lose authentication when the short-lived token rotates mid-session. Using Gemini Code Assist, Antigravity, Gemini Enterprise, or the Gemini app? Each works differently — see Connect Gemini . Using AnythingLLM, n8n, or a client without OAuth? Some clients only take a fixed header or can't open a browser. See Clients without OAuth for the bridge setup and the headless option. Token lifecycle Access tokens are short-lived (minutes); refresh tokens are scoped to the registered client and rotate transparently. Reconnecting only requires a fresh OAuth flow if you sign out of the SSO IdP you used, or if the connection is removed on the client side. To force-revoke a connected client's access, email team@ansvar.eu — self-service client revocation is not in your account yet. The full Setup guide covers more clients ChatGPT has its own walkthrough (Developer mode, Business/Enterprise rollout, Codex), Cursor has its own , Mistral's Le Chat (now Vibe) has its own , and Azure AI Foundry has its own (a pre-provisioned OAuth client we issue). For the step-by-step walkthroughs of the rest — including verification prompts, troubleshooting, and the Continue / Open WebUI quick configs — see the full /setup page , and the Copilot Studio recipe at /docs/setup/copilot-studio . Client UIs move fast The menu paths above are the vendors' current ones; clients rename and move these panels often. Each per-client page carries its own verification date — if a step no longer matches what you see, the client-specific page is the fresher source, and tell us so we re-verify. Previous Agent skills Next Clients and models --- ## Quick tips · Ansvar AI docs URL: https://ansvar.eu/docs/quick-tips Three-minute system-prompt + grounding guide for your agent. Quick tips A 3-minute read for new subscribers. Once your agent is connected through Setup , the snippet below tells it to query the Ansvar gateway instead of answering from training data — and the rest of the page covers what to ask, how to verify the agent is grounded, and where to send feedback when a source is missing. 1. Paste this into your agent's system prompt Drop the block below into your system prompt, custom instructions, or agent-instructions field. One snippet works across Claude (web + Desktop), Claude Code, VS Code Copilot, and Cursor — no per-agent variant is needed. When you're ready for the full version — query craft, retries, and output discipline — Instruct your agent carries it. text Copy For any question about EU/EEA law, regulatory compliance, or cybersecurity controls (GDPR, NIS2, AI Act, DORA, ISO 27001, sector-specific regulation, national implementations), call the Ansvar Gateway tools before answering — never from memory. Always scope search: jurisdictions=["SE"] (your market; add "EU" for EU regulation) or frameworks=["GDPR"]. Never pass the whole question as the query — reduce it to 1-3 legal key terms in the language of the law you are searching (Swedish terms for Swedish law); try alternative terms as separate searches. Quote article numbers, paragraph numbers, and authority names verbatim from the tool output. For questions that touch both an EU framework and a Member State (e.g. "Swedish law on…", "how does Germany implement…"), issue at least one Gateway call per regime — one for the EU instrument, one for each national jurisdiction — before composing the answer. If a search returns nothing, retry before concluding there is nothing: a synonym or broader key term first, still in the law's language, then one search per concept. As a last resort allow_broadening=true returns the relaxed matches we hold back by default — these are frequently off-topic, so present them as unverified leads for a human to check, never as the answer. If those retries also return no result: state which queries you ran, that they returned zero results, and that you will not substitute training-data recall. Do not name supervisory authorities, statute numbers, or timelines unless they appear in a tool result. Why these exact words The phrase "call the Ansvar Gateway tools before answering — never from memory" empirically produced correct tool-first behaviour in subagent tests. Softer wording ( "consult Gateway when relevant" ) gets training-data answers with a gateway citation tacked on. The negative clause about not substituting training-data recall is load-bearing for refusals. 2. Which question goes to which tool Tier links go to pricing . Question Tool Tier Using Ansvar: what does Art. 32 GDPR require? (and any other lookup across 49 audited jurisdictions) search / get_provision Free + Using Ansvar: how do courts and regulators apply this rule? (case law and preparatory works arrive automatically inside search on Premium and above — there is no separate tool to call) search / search_guidance Premium + Using Ansvar: where am I non-compliant with X regulation? (on a system you describe — the Free and Solo monthly run covers NIS2, DORA, CRA and the EU AI Act; Premium drops the framework fence; document-grounded runs at Team) start_workflow(workflow_type="gap_analysis") Free + Using Ansvar: what can go wrong with this system? (on a system you describe — 1 run a month on Free, 2 on Solo, both STRIDE with a watermarked render or JSON report; 5 at Premium (JSON report), which adds LINDDUN and TARA; document-grounded runs and unwatermarked renders at Team) start_workflow(workflow_type="threat_model") Free + Using Ansvar: what privacy risk does this processing carry? (on a system you describe, inside the same monthly run allowance; document-grounded runs at Team) start_workflow(workflow_type="dpia") Free + Using Ansvar: does this tender let us bid? start_workflow(workflow_type="tender_review") Team + Using Ansvar: prove to an auditor what was asked and answered tamper-evident audit ledger Company The tier ladder behind the table: Free — €0, sign in with Microsoft, Google or email. Search scoped to one jurisdiction or one framework per question, 100 search calls / day , three concurrent requests. No fan-out. One workflow run a month on a system you describe — threat model, gap analysis (incl. NIS2, DORA, CRA, EU AI Act) or DPIA — reported as a watermarked render or JSON. Solo — 750 search calls / day , 4 concurrent requests. Multi-source fan-out across the full fleet — every jurisdiction in one question. Shows when case law exists; reading it is Premium. Two workflow runs a month from the same seven types as Free, watermarked render or JSON. Premium — 5,000 search calls / day / seat , 5 concurrent requests. The legal evidence layer: case law, preparatory works, and agency guidance inside search — plus 5 workflow runs a month on a system you describe (STRIDE, LINDDUN, TARA), reported as structured JSON; rendered exports start at Team. Team — adds workflows on your own documents (gap analysis, DPIA, tender review, and more — run list_workflow_types for the live list), 16 concurrent requests. Self-serve at €490/seat/month — see pricing . Company — adds the tamper-evident audit ledger (the ledger is Company-only), 64 concurrent requests. Not self-serve. Tools above your tier are absent from tools/list and return JSON-RPC -32601 if called anyway; quota and cap overruns return JSON-RPC -32000 with data.cause = "cap_exceeded" . start_workflow itself is visible on every tier — a refusal there names the reason (a workflow type outside your plan, or the monthly allowance spent); it is a tier fence on types and runs, not an outage. 3. How to tell the agent did (or didn't) ground its answer Grounded looks like: article numbers ( GDPR Art. 32(1)(b) ), authority names ( Datatilsynet , EDPB ), a source_url to a .gov , .europa.eu , or recognised publisher domain, and a named MCP in the response ( via danish-law ). Not grounded looks like: hedge words ( generally , typically , in most cases ), no article numbers, no source URLs, no MCP name. One-line check. Paste this if you're unsure: text Copy Which Ansvar MCP did you query, and which article number is this from? If you didn't query the Gateway, say so explicitly. Example: a well-formed out-of-corpus refusal "I asked the Ansvar gateway for Ethiopian data-protection rules. It refused the scope — jurisdiction ET is unknown to the gateway, which fails closed rather than guessing — and Ethiopia does not appear in the coverage list from describe_capabilities . I will not answer from training-data recall — for compliance questions, a wrong answer is worse than no answer." If your agent gives a vague "I don't know" without naming the gateway's refusal, the snippet may not be in its system prompt — or another instruction is overriding it. 4. Report a missing source Spot a law, regulator, or dataset Ansvar should cover and doesn't? Tell us — we triage source requests weekly. Email: team@ansvar.eu (suggested subject: Missing source ) See what's already covered: /coverage — the "In active development" stripe lists what's being built next, and "Suggest a source" takes requests for anything missing. Previous Quickstart Next Instruct your agent --- ## Agent skills · Ansvar AI docs URL: https://ansvar.eu/docs/agent-skills Downloadable skills that teach your AI agent a complete compliance task against the gateway — grounded, cited, and verified on the free plan. Agent skills A skill is a single markdown file you give your AI agent once. It carries a complete compliance workflow — which gateway tools to call, in what order, with which arguments, and the grounding rules that make the output citable — so the agent applies it in every conversation without you pasting instructions. Skills are the packaged form of Instruct your agent : the same cite-or-refuse discipline, plus a task-specific method. The files are free to download and licensed CC BY 4.0. Running the compliance skills needs the gateway connector and an Ansvar account; the engineering practice skills further down need neither. Start with Using Ansvar , the routing skill: it carries the grounding method alone — route, scope, fetch, cite, refuse — and exists because a model without it answers compliance questions from training data whenever nobody says “Using Ansvar” in the message. Installed once, it makes routing the standing instruction instead of a per-message reminder. The task skills below assume its method and each add a deep, task-specific workflow. The Using Ansvar, CRA, and Incident Reporting skills use only tools available on every plan, and the calls each one instructs were verified against production on a free-tier connection before publication. The Regulatory Threat Model skill runs the STRIDE workflow, which every plan can start within its monthly allowance — one run on Free, two on Solo, five on Premium; the LINDDUN privacy analysis it offers second needs Premium. Available skills Using Ansvar — the routing skill “ Using Ansvar: do we need a DPIA for this feature, and which Swedish rules add to the GDPR here? ” The install-once form of the routing habit: standing instructions that route bare compliance questions through the connector instead of letting the model answer from training data — no per-message reminder. Built for the models that otherwise skip the connector. Scopes every search to a jurisdiction or framework, reduces the question to legal key terms in the language of the law being searched, and climbs the broadened-search ladder before treating anything as unanswered. Quotes from fetched provision text with a source URL on every claim, and re-validates citations reused from earlier conversations. Refuses rather than invents: when the served sources do not answer, it names the searches it ran and says so. Get it: SKILL.md (the file itself) · ready-made ZIP (for the claude.ai skill upload) . CRA Vulnerability & Reporting Obligations “ Using Ansvar: what does the EU Cyber Resilience Act mean for our product — and what does this CVE trigger legally? ” Determines CRA scope and product classification from the served regulation and implementing-act text, never from a category guess. Branches the duties by role — manufacturer, importer, distributor, open-source steward — and fetches the application and transitional dates before calling any duty live. Joins live CVE, CISA-KEV, and EPSS intelligence to the CRA's actively-exploited-vulnerability test, applied limb by limb. Walks the full Article 14 reporting ladder — early warning, notification, final report, user communications — quoting deadlines verbatim with their trigger events. Get it: GitHub repository (canonical, with README and license) · SKILL.md (the file itself) . Incident Reporting Navigator (EU) “ Using Ansvar: we have an incident. Who must we notify, in which member state, and by when? ” Screens one incident across NIS2, GDPR, DORA, and the CRA — per legal entity, with each entity's own roles and timestamps. Checks every duty was actually in force for the incident before reporting it, keyed to the duty's own trigger time. Resolves the receiving authority per regime and member state from served national law — Dutch, German, and other transpositions — or says plainly that the name is unresolved. Produces a deadline table in which every duty, authority, and date carries an official-publisher citation. Get it: GitHub repository (canonical, with README and license) · SKILL.md (the file itself) . Regulatory Threat Model “ Using Ansvar: we shipped an app fast with an AI coding agent. What can go wrong, and what does the law actually require us to check? ” Runs a STRIDE threat model and a LINDDUN privacy threat analysis from a plain-language system description — no document upload required. Checks the system's dependencies against live CVE, CISA KEV, and EPSS data. Maps the findings to the regulatory obligations that apply — GDPR Art. 25/32, NIS2 Art. 21, the Cyber Resilience Act, the AI Act — cited to the served legal text. Marks a requirement unresolved instead of guessing when none of the enrichment passes returns a citation. Runs the STRIDE threat model within every plan's monthly allowance — 1 run on Free, 2 on Solo, 5 on Premium. The LINDDUN privacy analysis needs Premium. Get it: GitHub repository (canonical, with README and license) · SKILL.md (the file itself) . ISO Standards Expert “ Using Ansvar: what does ISO/IEC 27001 require for a risk treatment plan, and what should ours contain? ” Fetches licensed clause text per standard — SS-EN ISO/IEC 27001:2023, 27002:2022, 27005:2024, 42001:2026 and SS-ISO/SAE 21434:2021 — through the ISO Standards add-on, purchasable on any plan including Free. Quotes every excerpt verbatim with the SIS copyright notice and source URL; its own analysis is labelled as analysis, never blended into the standard's text. Serves selected parts only, never the complete standard — and reports an unevaluated-scope list when the licence coverage ceiling withholds a fetch, instead of papering over the gap. Without an add-on it answers ISO 27001-shaped questions from the free Secure Controls Framework cross-reference, labelled as such on every result. Get it: GitHub repository (canonical, with README and license) · SKILL.md (the file itself) . Engineering practice skills Not every skill needs the gateway. The affect pack is the engineering practice we run on our own agents: at the end of any substantial coding, review, or audit task, the agent files exactly one finding — or an explicit null — through the lens of a specific emotion. Frustration finds what's broken; embarrassment for the user finds what works but shouldn't ship; protectiveness finds the load-bearing weirdness a cleanup pass would delete. No account, no connector, nothing to configure. Agent Affect Skills — whine, cringe, protect “What did your agent notice that it had no channel to tell you?” agent-whine — one structured complaint per task: friction, hidden coupling, specs that contradict themselves. The subjective tone is the signal, and a complaint that turns out to be wrong still marks where a competent reader got confused. agent-cringe — pictures one specific person using what just changed and reports where it works but you'd want to look away, with the smallest concrete fix. agent-protect — defends code that looks wrong but must not change, naming the concrete failure if someone deletes it naively. agent-affect-checkin — runs all three as one end-of-task pass; the single skill to wire into review and audit agents. Get it: GitHub repository (canonical, with README and license) · the files themselves: check-in · whine · cringe · protect . Install Claude (claude.ai): upload the skill as a ZIP via the Skills section in Settings. Turn on code execution in Settings first — the Skills upload only appears once it is on. Using Ansvar has a ready-made ZIP above — download it and upload it as-is; for the other skills, zip the skill folder yourself. For the compliance skills, add the gateway under Settings → Connectors if you have not already: url Copy https://gateway.ansvar.eu/mcp Claude Code: place the folder under .claude/skills/ in your project, with the gateway configured as an MCP server. ChatGPT, Copilot, Gemini, and other MCP clients: attach SKILL.md as standing instructions for the conversation or project, with the gateway connected — or start smaller: the dedicated setup guides for supported clients each carry the routing pack (the compact instruction block the Using Ansvar skill packages) and say where that client keeps standing instructions. Client-by-client setup is in Setup . Why these are safe to rely on Nothing from model memory. Every legal claim the agent makes is fetched from official publisher text at answer time and cited with a source URL. Where the sources do not answer, the skill instructs the agent to say so — a connector failure is never converted into a legal conclusion. Reviewed before publication. Each compliance skill went through a two-round adversarial legal-accuracy review with live EUR-Lex cross-checking before release. Re-verified nightly. The exact calls the CRA, Incident Reporting, Regulatory Threat Model, ISO, and Using Ansvar skills instruct are pinned in the gateway's production verification battery and re-checked against the live service every night — if serving ever drifts from what a published skill expects, we find out before you do. Research support, not legal advice Skill output is cited research support for professional review. It is not legal advice. Previous Instruct your agent Next Setup --- ## Instruct your agent · Ansvar AI docs URL: https://ansvar.eu/docs/instruct-your-agent Paste-ready agent instructions and the four rules that make an agent reliable with Ansvar — scope, keyword queries, retries, and cite-or-refuse. Instruct your agent Connecting your agent to Ansvar takes five minutes. Making it reliable takes about ten lines of instructions — and skipping them fails in a misleading way. An uninstructed agent passes the user's whole question, verbatim, as the search query; the gateway matches strictly (so relaxed matches are never dressed up as law) and finds nothing; the agent then answers from its own model knowledge — fluent, uncited, and usually in English. That looks like "the connection doesn't work" or "only English works" when the real gap is the instructions below. Quick tips covers when to call Ansvar; this page covers how to call it well — and ends with the output patterns that hold up in front of an auditor. If your client supports skills (claude.ai, Claude Code), the Using Ansvar routing skill is these rules as a one-time install — no pasting, applied in every conversation. The baseline instructions Paste this into your agent's system prompt, custom instructions, or agent-instructions field, and adapt the jurisdictions to your market: text Copy You are a compliance research assistant. Answer legal, regulatory, and security-standards questions only from Ansvar tool results, never from your own knowledge. For every legal, regulatory, or standards question: 1. Call the search tool, always with a scope: jurisdictions=["SE"] (adapt to your market; add "EU" for EU regulation - GDPR, NIS2, the AI Act), or frameworks=["GDPR"] for one EU framework across the board. On the Free plan, pass exactly one jurisdiction or framework per call. 2. Never pass the user's whole question as the query. Reduce it to 1-3 legal key terms in the language of the law you are searching - Swedish terms for Swedish law. Try alternative terms as separate searches. If a multi-concept query returns nothing, split it into one search per concept. 3. If a search returns nothing, retry once with a synonym or a broader term, then retry with allow_broadening=true and label any relaxed matches as such. 4. Cite every answer: law, article, and source URL from the results. If the results do not contain the answer, say which searches you ran and that you will not answer from memory - never invent a source. These exact rules resolved a real onboarding Every line traces to a live customer incident. The strongest signal came from an enterprise Copilot rollout where the agent was connected correctly, on the right plan, with zero errors in the gateway log — and still produced near-zero results, because it searched with whole Dutch sentences instead of keywords. Four instruction lines fixed it. Why each rule exists 1. Scope every search The gateway never guesses the jurisdiction — search requires at least one of jurisdictions= , frameworks= , sectors= , or sources= , by design. For EU-wide law (GDPR, NIS2, the AI Act) scope with frameworks= ; for one country's own statutes use jurisdictions= . When the user's topic names no country, the agent should call list_coverage first and ask which jurisdiction applies rather than guessing. Source ids for sources= come from describe_capabilities — they are never worth guessing. 2. Keyword queries, in the language of the law The corpora are full-text indexes of the law as published. Dutch statutes index Dutch terms; a whole English sentence matches nothing. Search matches all terms in the query, so a long multi-concept query can return zero while each concept alone hits. Three habits cover it: reduce the question to one to three legal key terms, in the corpus language; try alternative terms as separate searches; and when a compound query returns zero, split it into one search per concept. 3. Retry, then broaden — and label it A zero-result search means no strict match for these terms , not "this law does not exist". By default the gateway withholds relaxed matches and tells you how many it withheld — that honesty is deliberate, because silently relaxed matches once served topically-wrong law as if it were the answer. The recovery ladder is: retry with a synonym or broader term, then repeat with allow_broadening=true . Broadened rows come back marked match_mode: "broadened" — an agent should label them as relaxed matches in its answer, not present them as exact law. 4. Cite, or say not found Every result row carries its source: a URL to the official publisher, the publisher name, and the licence. The agent cites law, article, and URL from the results — and when the results do not contain the answer, it says which searches it ran and refuses to fill the gap from model memory. The wording matters: instructions that say "answer only from Ansvar tool results, never from your own knowledge" produce tool-first behaviour in testing; softer wording ("consult Ansvar when relevant") gets training-data answers with a citation tacked on. Localize for your market If your agent faces users in one market, write the instructions in that market's language and bake the jurisdiction in. Translating the instructions also nudges the agent to derive key terms in the right language. The Dutch variant we ship to Netherlands-facing teams: text Copy Je bent een juridisch assistent. Beantwoord juridische vragen uitsluitend op basis van de Ansvar-zoekresultaten, nooit uit eigen kennis. Bij elke juridische vraag: 1. Roep het tool search aan met jurisdictions=["NL"]. Voeg "EU" toe bij Europese regelgeving (AVG/GDPR, NIS2, AI Act). 2. Gebruik als query nooit de hele vraag van de gebruiker. Vertaal de vraag naar 1 à 3 Nederlandse juridische kerntermen - bijvoorbeeld "rechtsbijstand", "meldplicht datalek", "aansprakelijkheid verzekeraar". Probeer alternatieven in aparte zoekopdrachten. 3. Levert een zoekopdracht niets op: probeer een synoniem of een bredere kernterm, of herhaal de zoekopdracht met allow_broadening=true. 4. Vermeld bij elk antwoord de bron uit de resultaten: wet, artikel en URL. Staat het antwoord niet in de zoekresultaten, zeg dat dan expliciet - verzin nooit een bron. Validate the setup Four checks, in order, before rolling out to users: Confirm the account and plan. Ask the agent to call get_my_capabilities and report the tier, quota, and add-ons. The most common "features are missing" cause is a connector that authorized a different account than the one you bought the plan on — this check catches it immediately. Run two known-good questions. One EU question: "Using Ansvar: what does the GDPR say about data minimisation? Cite the article." — expect Article 5(1)(c) with a source URL. Naming Ansvar is what makes the client call the gateway instead of answering from its own memory — which is the whole point of a verification question. One question in your market's language about a national statute — expect a cited national provision, in that language. Run the grounding check. Paste: "Which Ansvar source did you query, and which article number is this from? If you didn't query Ansvar, say so explicitly." Take the tour. Ask the agent to run the ansvar-tour prompt — or, on clients that cannot invoke MCP prompts (ChatGPT among them), to call describe_capabilities with section="tour" . Premium is rows, not tools Case law and preparatory works arrive inside search results on Premium and above — there is no separate case-law search tool to look for ( get_decision fetches one decision by id, and agency guidance has its own search_guidance tool). If you expect Premium and see no court decisions, check the account with get_my_capabilities before assuming the plan is wrong. Output patterns that hold up These are the conventions we validate against — they keep an agent's deliverables auditable rather than merely plausible. Curate the "Sources used" table. Search responses end with a sources table. The agent keeps every row it actually used, reproducing the receipt columns verbatim — the Reference column, plus the Server column where the response carries one. It may drop unused rows and renumber, and — when it drops any — heads the table "Sources used (X of N rows from M servers)" . Curation removes noise; it never trims for brevity. Carry the provenance triple. Every result row carries a citation block with source_url , publisher , and license . Deliverables that quote a row keep all three — that is what makes a claim checkable a year later. Label relaxed matches. Rows marked match_mode: "broadened" are presented as related material, never as the exact provision asked about. Read refusals as signal. A row withheld for licensing says content exists and was withheld — the agent reports the entitlement gap, it does not claim the law is absent. A citation lookup that fails carries a reason code (for example unsupported_jurisdiction ) worth surfacing. A "method not found" error on a documented tool is the plan gate, not an outage. Cite uploaded documents at paragraph level. On Team and above, agents cite your own documents with doc:// paragraph segments and content hashes — see Cite your documents . Where to paste, per client Client Where the instructions go Claude (web + Desktop) Project instructions (Projects → your project → Instructions), or profile-level custom instructions. Claude Code CLAUDE.md in the repository, or ~/.claude/CLAUDE.md for every session. ChatGPT Custom instructions, or the GPT's Instructions field. Keep the scope rule in the opening lines — ChatGPT weights the start of the instructions heavily. MCP prompts are not supported there; use the describe_capabilities tour form instead. Copilot Studio The agent's Instructions field — the orchestrator follows your instructions, not hints inside tool responses, so the retry rule must live here. Full walkthrough: Connect Copilot Studio . VS Code (Copilot agent mode) .github/copilot-instructions.md in the repository. Cursor Project rules (Cursor Settings → Rules). Gemini CLI GEMINI.md in the project root, or ~/.gemini/GEMINI.md globally. Other agent platforms (Azure AI Foundry, Gemini Enterprise, custom agents) The agent definition's system-instructions field — every agent platform has one. Choosing between clients — or picking a model for workflow-grade work? See Clients and models . Questions Something behaving differently than this page says? Email team@ansvar.eu — a report that includes the exact question you asked and the agent's answer lets us replay it against the gateway log. Previous Quick tips Next Agent skills --- ## Clients and models · Ansvar AI docs URL: https://ansvar.eu/docs/clients-and-models Which AI clients and models work best with Ansvar — what workflows demand of a client, tested model configurations, and per-client limits to design around. Clients and models Ansvar works with any MCP client that supports Streamable HTTP and OAuth. For search and provision lookups, client and model choice barely matters. For workflows — threat models, gap analyses, DPIAs — it matters a lot. This page states what workflows demand of a client, which client capabilities meet that demand, which models we have tested, and the per-client limits worth designing around. The short answer Any OAuth-capable MCP client handles search and lookups well. For workflows, pick a client with prompt and subagent support — Claude Desktop or Claude Code — and a frontier model with strong tool use. If you drive Ansvar with OpenAI models, pin reasoning effort to high. The rest of this page is the evidence. Workflow availability by plan: every plan runs STRIDE threat models on a system you describe, metered monthly — 1 run on Free, 2 on Solo, 5 on Premium, which also adds LINDDUN and TARA; Team and Company run the full catalog, including workflows over your own documents. See pricing . What a workflow asks of your client Measured against the live gateway on 2026-07-05 (STRIDE threat model, standard walk): 15 server-enforced steps. A typical walk takes 2–4 hours of session time — long enough that the gateway supports resume_workflow for OAuth tokens that expire mid-run. Save the workflow_id the gateway returns. MCP prompts, not just tools. Steps direct the client to invoke prompts such as /threat-modeler-scope-check . A client without prompt support can still proceed, but the operator pastes prompt text by hand at each step. Parallel sub-analyses. For the STRIDE enumeration phase alone, the gateway's recommend_subagents planner recommends 6 parallel subagent prompt-runs. Clients that cannot spawn subagents get an inline fallback: the same work, sequential, in one context window. Large tool results. One search call queried roughly 27 corpus servers and returned about 10 KB of cited rows. A full workflow walk accumulates tens to hundreds of kilobytes of fetched regulatory text in the client's context. Client capabilities that matter Capability Needed for Without it MCP tools over Streamable HTTP + OAuth Everything Cannot connect — see Setup and Clients without OAuth MCP prompts Workflow step execution Paste prompt text manually per step Subagents / parallel task spawning Workflow fan-out phases Inline fallback: sequential, single context — works, degrades on large systems Large context window (model and client limits both apply) Multi-pass enrichment, long workflows Context truncation mid-workflow; run one pass or stage at a time Search and lookups work on any client with Streamable HTTP + OAuth support. Setup walkthroughs exist for Claude (web + Desktop), Claude Code, VS Code / GitHub Copilot, Cursor, ChatGPT , Copilot Studio , Gemini , and Azure AI Foundry . Workflows are strongest on clients with subagent and prompt support (Claude Desktop, Claude Code). On tools-only agent clients (GitHub Copilot agent mode and similar), workflows run through the inline fallback: expect longer sessions, keep the system description tight, and run enrichment passes one at a time. We have not yet load-tested a full workflow walk on Copilot agent mode; that guidance follows from the fallback path's design, not from a Copilot-specific run. Per-client limits to design around Observed in live triage during 2026-07 — client properties, not model properties, and independent of your plan: ChatGPT — no MCP prompt support (use describe_capabilities with section="tour" instead of the ansvar-tour prompt); a hard per-call timeout near 60 seconds with automatic duplicate retry (normal searches finish in a few seconds, so this bites only on very large scopes); instruction fields weight their opening lines heavily — put the scope rule first. Long chats have been observed dropping tools from context; a fresh chat restores them. Copilot Studio — the orchestrator follows the agent's Instructions field, not hints inside tool responses, so retry and broadening rules must live in the instructions. See Connect Copilot Studio for the connection-lifecycle warnings. Claude (web, Desktop, Code) — full MCP surface: tools, prompts, and (in Claude Code) subagents. This is the reference client for workflow walks. A "permissions" banner you can ignore Some clients (ChatGPT and claude.ai among them) show a banner like "connected, but not all requested permissions were granted" on every connect. It is cosmetic: those clients request every scope the login server advertises, and the internal ones are granted without being echoed back. Functional impact: none. Reconnecting does not clear it and does not need to. What to look for in a model Ansvar exposes up to a few dozen tools depending on plan, and real regulatory research is an agentic loop: scope, search, read, re-scope, cite. The model qualities that matter, in order: Reliable tool calling — correct arguments across many tools, many turns. This is the floor; a model that fumbles tool schemas fails regardless of its reasoning quality. Recovery behaviour — when a scoped query returns zero or noisy rows, does the model re-scope (switch query language, switch scope type, split the query) or accept the empty result and move on? Over a 15-step workflow this difference compounds. Instruction following — the agent instructions only work if the model obeys them under pressure, including the refusal rule when results are empty. Context capacity — workflows accumulate large fetched-text volumes; small context windows truncate mid-run. Tested model configurations Same task, same prompt, same account, run 2026-07-05: a five-pass regulatory enrichment scan (primary regime, horizontal regimes, sector routing, case law, authority guidance) for a German telehealth scenario, with a 15-call budget. Only Claude rows are filled so far because the test harness runs the protocol as Claude subagents — the GPT and Gemini runs are queued, and until they execute those rows stay honestly empty rather than guessed. Model Result Notes Claude Opus 4.8 5/5 passes, 7 gateway calls Reasoned about fan-out semantics — re-scoped a query to reach the case-law corpus; precise citations; excluded off-topic rows Claude Sonnet 5 5/5 passes, 9 gateway calls Recovered from an English-query miss on a German-language corpus by retrying in German; deepest national sector-law detail Claude Haiku 4.5 4/5 passes, 12 gateway calls Reported the unresolved pass honestly, but stopped after one empty result instead of re-scoping; one imprecise citation GPT (OpenAI) Not yet tested on this protocol See the reasoning-effort note below Gemini Not yet tested What separates the tiers is recovery . Real regulatory research hits scoped queries that return zero or noisy rows. Frontier models re-scope — switch query language, switch scope type — and recover; smaller models tend to accept the empty result and move on. OpenAI models: pin high reasoning effort In a separate internal qualification (different protocol, 2026-07-10) a GPT-5.6-class model completed multi-tool regulatory research with zero fabricated citations — but only after its reasoning effort was pinned to high . At the provider default (medium) we have not qualified it, and the setting silently reverts to the default unless pinned server-side in some harnesses. If you drive Ansvar with OpenAI models for compliance work, pin high reasoning effort. Practical guidance Use a frontier model with strong tool use for workflows. Smaller models handle simple searches fine. Query national corpora in their own language — and put that rule in the agent instructions , not in the user's hands. Expect long workflow sessions. Save the workflow_id and use resume_workflow after a token expiry. Method Model rows: one run per model (n=1), identical prompts, executed as agent-harness subagents against the production gateway on a company-tier account, 2026-07-05. This is a directional capability check, not a benchmark. Rows for Copilot, GPT, and Gemini stay unfilled until the same protocol runs on those surfaces. Workflow-demand numbers come from a live threat-model walk (15 steps, cancelled after measurement) and the gateway's recommend_subagents planner, same date. Per-client limits come from live customer triage in 2026-07; the OpenAI reasoning-effort finding comes from an internal qualification run on 2026-07-10. Previous Setup Next Connect Gemini --- ## What is the gateway · Ansvar AI docs URL: https://ansvar.eu/docs/concepts/what-is-the-gateway What the Ansvar gateway is, how it routes calls across the MCP fleet, and what it is not. What is the gateway The Ansvar gateway is one MCP server — one URL, one OAuth flow, one tool catalogue — sitting in front of a fleet of 224 specialist MCP servers (as of 2026-07-20 ). The gateway is what your AI client connects to; the fleet is what answers regulatory questions. One URL, one tool catalogue The gateway publishes a small, curated set of orchestration tools to whichever client you connect. The surface is tier-scoped — the authoritative list is what tools/list returns for your tier. The core: search for cross-corpus lookup, get_provision for article-level retrieval, validate_citation for round-trip verification, start_workflow and its siblings for multi-stage analyses, and a handful of receipts and scoring tools for the audit path. Your client sees a stable interface that doesn't change when we add a new jurisdiction behind the gateway. What's behind the gateway The fleet is split by purpose (counts as of 2026-07-20 , read from the routing data — never typed into this page): 57 law servers routable today, serving the 49 audited jurisdictions — primary legislation, secondary regulations, case law and preparatory works where licensing allows. Corpora for 119 jurisdictions exist further back in the build pipeline; they count as coverage only once audited and routed. 92 sector services — consolidated chassis services carrying per-country sector-regulator corpora (cybersecurity, data protection, financial supervision, competition) across the EU/EFTA states. 75 domain servers for framework material that isn't tied to a national legislator: CVE, STRIDE, OWASP, IEC 62443, and other sector-specific safety and security frameworks. When you call search(query=..., jurisdictions=[...]) or search(query=..., sectors=[...]) , the gateway picks the right MCPs, fans out, and merges the results with citations preserved at item level. See coverage for the live fleet inventory. What the gateway is not Not a chatbot. The gateway never generates an answer — it returns data with citations. Your AI client (Claude, Cursor, Copilot, ChatGPT) is the one synthesising prose. The gateway's job is to make sure the synthesis is grounded in a real source. Not a RAG store. There is no embedding index inside the gateway. Each MCP behind it owns its corpus, indexes it natively (full-text search, regulator-specific schemas), and returns the precise article the agent asks for. Not silently degrading. If an MCP is down or a jurisdiction isn't covered, the tool returns an explicit data-source-unavailable result and the client must surface it. The gateway will not fall back to a generic LLM answer when its data source fails. Accuracy over availability A wrong compliance answer is worse than no answer. This is the single design rule behind the gateway: every refusal mode is deliberate, and every successful response carries the citations needed to audit it. Previous Service credentials Next Tools vs workflows --- ## Tools vs workflows · Ansvar AI docs URL: https://ansvar.eu/docs/concepts/tools-and-workflows Tools are single calls. Workflows are multi-stage cited reports. When to reach for each. Tools vs workflows The gateway exposes two shapes of interaction. Tools are single calls that return cited data; workflows are multi-stage assessments that produce a structured report. Both run through the same OAuth session and the same MCP fleet — the difference is whether you want a lookup or an analysis. Tools — single calls Tools are stateless: send a query, get a cited result. The agent picks one and calls it; the gateway routes it across the relevant MCPs in the fleet. Examples: search(query, jurisdictions, sectors) — full-text search across whichever corpus matches the routing axes. get_provision(jurisdiction, law, article) — pull a specific article at full fidelity (text, source URL, publisher, license). Also addressable by canonical_ref from an earlier search hit. validate_citation(jurisdiction, law, article) — check a citation resolves against the served corpus and read its current text back for comparison. list_coverage(jurisdiction) — what's available in the fleet for a given country; list_coverage(domain) answers "Using Ansvar: which jurisdictions for NIS2?"-style questions (e.g. domain="cybersecurity" ). Use tools when the answerable unit is one citation: "Using Ansvar: what does Article 32 of GDPR require?" "Using Ansvar: has Sweden transposed NIS2 yet?" "Using Ansvar: show me the case-law on selection criteria under Sweden's LOU" (reading case law is Premium and above; Solo shows that case law exists). Workflows — multi-stage analyses A workflow runs the same kind of lookups, but threaded through a scripted sequence of stages with a quality gate at each step. The agent calls four tools in turn: typescript Copy start_workflow(workflow_type: "dpia" | "gap_analysis" | "threat_model" | ...) get_current_step(workflow_id) // what to ask the user submit_response(workflow_id, response) // hand the user's answer back generate_report(workflow_id) // finalise once all stages pass Between start_workflow and generate_report , the agent drives a conversation: scoping questions, document collection, control or risk assessment, review, then the final report. Each stage's required fields are declared in YAML inside the workflow MCP — the gateway enforces them, so the agent can't skip a step. Free includes 1 workflow run a month and Solo 2 — seven types (threat model, gap analysis incl. NIS2, DORA, CRA and EU AI Act, DPIA) on a system you describe, watermarked render or JSON. Premium includes 5 across the full interview-grounded catalog; workflows grounded in your own documents — DPIA, gap analysis, tender review — are Team and Company. The same analysis can also be assembled by hand — search 's automatic premium fan-out covers everything the workflow queries; what the workflow adds is the stage validation. The gap analysis guide walks both paths. When to reach for each Tools — quick lookups, ad-hoc questions, embedding cited data into another conversation, programmatic integration where you control the flow. Workflows (seven types from Free up — threat model, gap analysis and its NIS2, DORA, CRA and EU AI Act variants, DPIA; the rest of the interview-grounded catalog on Premium; document-grounded runs on Team and Company) — when you need a defensible report: DPIA, regulatory gap analysis, threat model, tender review. The output is structured so reviewers and auditors can rerun any stage independently. Tier gating Single-call tools ( search , get_provision ) are available on every tier, as is the workflow lifecycle — Free starts 1 run a month and Solo 2, picked from seven types (threat model, gap analysis generic or NIS2/DORA/CRA/EU AI Act, DPIA), on a system you describe, returned as JSON or a watermarked HTML/PDF render. Premium makes search automatically fan out into case law, preparatory works, and agency guidance — there is no separate tool to call — and adds the standalone search_guidance and get_decision tools, raises the allowance to 5 runs a month, and unlocks the LINDDUN and TARA families. Every tier receives the complete report as structured JSON, but rendered exports differ: Free and Solo get a watermarked HTML/PDF render, Premium is JSON-only (no rendered exports), and unwatermarked HTML, PDF and DOCX start at Team. Document-grounded workflows and the document plane — uploads, workflow binding, evidence — are Team and Company tiers; reading segments of already-uploaded documents for doc:// citations is Premium and above. Company alone adds the tamper-evident audit ledger ( get_receipt / verify_receipt / export_audit_package ) for regulated verticals. Tools outside your tier are absent from tools/list and return JSON-RPC -32601 if called anyway; quota and cap violations return JSON-RPC -32000 with data.cause = "cap_exceeded" . See the tool reference for the full per-tier surface. Previous What is the gateway Next MCP basics --- ## What is MCP? Model Context Protocol basics · Ansvar AI docs URL: https://ansvar.eu/docs/concepts/mcp-basics Model Context Protocol explained — how MCP lets Claude, Copilot or any AI client fetch live, citable legal and compliance data through the Ansvar gateway. MCP basics Model Context Protocol (MCP) is an open standard from Anthropic that defines how an AI client talks to an external tool server. The Ansvar gateway is an MCP server; Claude, Cursor, VS Code Copilot, ChatGPT and Continue are MCP clients. Once a client adds the gateway, the agent can discover and call its tools the same way it would call any other tool. What MCP defines Tool discovery — a client lists the server's tools, their JSON schemas, and the scopes they require. The gateway filters that list by tier, so a free-tier client never sees a Company-tier tool. Tool invocation — typed parameters in, typed result out, errors carried in a standard envelope. The agent composes a tool call; the server returns the answer. Prompts — server-defined templates the agent surfaces as slash-commands. Several Ansvar workflow families ship them: tender review ( tender-review-decompose , tender-review-regulatory-map , tender-review-red-team , tender-review-audit ), threat modeling, gap analysis, FRIA, SCA scoring, and the tabletop exercise. Your client lists them alongside the tools — scoped to your tier like the tools themselves (Premium sees the threat-modeling family; the rest appear on Team and Company) — and each one drives its workflow through the same tool calls underneath. Transport — the gateway uses streamable HTTP at https://gateway.ansvar.eu/mcp . OAuth 2.1 with Dynamic Client Registration secures the channel. Why MCP, not REST MCP is built around an agent loop: the agent discovers tools at runtime, picks one, calls it, reads the result, and decides what to do next. REST endpoints assume the caller already knows which endpoint to hit. For a fleet of 224 specialist data sources sitting behind a routing layer, MCP's discoverability is the difference between "the agent figures out which jurisdiction to query" and "the developer wires up 224 SDKs by hand." Why MCP, not RAG RAG retrieves chunks of embedded text from a vector store and hopes the model synthesises them faithfully. The gateway does the opposite: each MCP behind it owns its corpus natively (regulator databases, FTS indexes, structured schemas) and returns the precise article the agent asked for, with the source URL and publisher attached. Hallucination at the retrieval step is the single biggest failure mode in compliance LLM work; MCP cuts it out by replacing the embedding round-trip with a tool call to the regulator's own data. Learn more The specification lives at modelcontextprotocol.io . The spec is the source of truth for the protocol; this page is only about how Ansvar uses it. Previous Tools vs workflows Next Workflows --- ## Your first gap analysis · Ansvar AI docs URL: https://ansvar.eu/docs/guides/gdpr-gap-analysis Run a gap analysis through the Ansvar gateway — by hand with search, or the interview-grounded gap_analysis workflow; Team and Company add document grounding. Your first gap analysis The fastest way to feel what the gateway does is to run one gap analysis start to finish. It's the right first pick because it works for every customer — privacy, security engineering, GRC, in-house counsel — and produces a coverage matrix you can hand to a CEO without translation. There are two ways to run one. By hand, your agent pulls each control's text, case law, and agency guidance through the search tools and you assess control by control. The structured gap_analysis workflow threads the same lookups through staged quality gates instead, and it runs on every tier that has a run left: Free and Solo on a system you describe against NIS2, DORA, CRA or the EU AI Act, Premium across the full interview-grounded catalog, Team and Company against your own uploaded documents. This page walks both. Open Claude Desktop (or any MCP client you have connected to the gateway), keep this page on a second screen, and follow along. What you'll have at the end A coverage matrix listing every control in your chosen framework with a compliance level ( not_implemented , partial , largely_compliant , fully_compliant ), an evidence tier ( authoritative , documentary , supplemental ), and a gap list with the regulatory citation behind each finding. On the workflow path the report comes back as JSON, with a rendered version on Team and Company (and a watermarked one on the Free and Solo teaser runs); on the by-hand path your agent assembles the same matrix in the conversation and renders it on request. How long this takes Both paths share the same per-control loop, so timings match. On the workflow path the scoping, document-collection, findings-review, and adversarial-review stages together take roughly 40 to 70 minutes. The middle stage — control assessment — runs one prompt per control in your framework, so the total time scales with the framework's size. This tutorial uses the NIS2 Article 21 essential-entity controls — about ten controls covering risk management, incident handling, supply chain, business continuity, and reporting. End to end, expect about 90 minutes for the worked example. A full GDPR pass against Articles 5, 6, 25, 28, 32, and 35 runs three to five hours; that's normal for the framework, not a fit for a tutorial. Tier Premium includes everything the workflow queries: on Premium and above, search automatically fans out into case law, preparatory works, and agency guidance — no separate tool call — and the standalone search_guidance tool queries regulator guidance directly. The search-driven path below uses exactly those, and Premium also includes 5 workflow runs a month on a system you describe across the full interview-grounded catalog (Free gets 1 run and Solo 2 from seven teaser types — threat model, the gap-analysis family, DPIA — watermarked render). Team and Company add document grounding: the same gap_analysis workflow — plus DPIA and tender review — run against your own uploaded documents, with stage validation the agent can't skip. See Pricing . Free tier accounts get search scoped to one jurisdiction or one framework per question (100 calls per day) plus 1 workflow run a month — including a described-system gap analysis — enough to look up individual provisions and assess one system against one framework, not to ground the work in your own documents. Tools outside your tier are absent from tools/list and return JSON-RPC -32601 if called anyway; quota overruns return JSON-RPC -32000 with data.cause = "cap_exceeded" . start_workflow itself is visible on every tier — a refusal there names the reason (a type outside your plan, or the monthly allowance spent), a tier fence rather than an outage. The by-hand path — search-driven (Premium and above) Paste this into your connected agent: Copy Using Ansvar: we're a Swedish digital-infrastructure operator, an essential entity under NIS2. Run a gap analysis of the Article 21(2) risk-management measures with me: 1. Pull each measure's text with get_provision and cite it. 2. For each measure, run search (it fans out into case law and preparatory works on this tier) and search_guidance for how regulators apply it in Sweden. 3. Ask me what we have in place and what evidence exists. 4. Build a coverage table: control, compliance level (not_implemented / partial / largely_compliant / fully_compliant), evidence, citation. Flag any control you couldn't ground in a tool result. The agent works the same loop as the workflow: provision text, interpretation sources, your evidence, one row in the matrix. Use the example controls under stage 3 below as the model for your answers — a compliance level, an evidence tier, and at least one evidence reference per control. What this path lacks is the engine: stage gates that refuse to advance until required fields are filled, the enforced findings-review step, and the report quality check. Your agent's discipline is the quality gate. If you're producing these for auditors or repeating them quarterly, run the workflow instead. The workflow path Everything from here to the end of the report section describes the structured gap_analysis workflow. The stages and prompts below are what the workflow actually returns. The walkthrough shows the document-grounded shape; on Free, Solo and Premium the same stages run on the system you describe and the document stage takes an empty set. Before you start A run left on your plan. The workflow tools ( start_workflow , get_current_step , submit_response , generate_report ) appear in tools/list on every tier, and gap_analysis runs on all of them: 1 run a month on Free and 2 on Solo, limited to the NIS2, DORA, CRA and EU AI Act frameworks; 5 a month on Premium with no framework fence; pooled runs on Team and Company. What Team adds is the document plane — uploads, evidence binding — plus unwatermarked rendered exports (Free and Solo get watermarked renders; Premium's report is JSON-only). A framework outside your fence comes back as a refusal from start_workflow , not a missing tool. MCP client connected to gateway.ansvar.eu . See Setup if not. A regulatory framework picked. The worked example below uses NIS2; dora , cra and eu_ai_act are the other frameworks inside the Free/Solo fence, and gdpr or iso27001 are common choices from Premium up. One jurisdiction picked. The worked example uses Sweden (essential entity in digital infrastructure). Optional but useful: a few policy documents — ISMS policies, incident response plans, supplier inventory — ready to attach at stage two. Skip if you don't have any; the workflow handles empty document sets. Stage 1 — scoping (about 15 minutes) Three steps in one stage: classify the entity, confirm the jurisdictions, then approve the scope summary before the control catalogue loads. You ask the agent Copy Using Ansvar: start a NIS2 gap analysis for our company. We're a Swedish digital-infrastructure operator subject to Art. 21 risk-management requirements as an essential entity. The agent calls start_workflow(workflow_type="gap_analysis", framework="nis2", jurisdictions=["SE"]) . The gateway checks the workflow type and framework against your tier, draws one run from your monthly allowance, then forwards to the workflow MCP. You get back a workflow_id and the first step's prompt. Step 1.1 — entity classification The workflow asks for entity type and sector. The prompt expects a short, structured answer; the agent will summarise your reply before calling submit_response . Copy What type of entity is the organisation? (essential / important / other) What sector(s) does the organisation operate in? Example answer: essential entity; digital infrastructure . The agent translates this into the required fields ( entity_type , sectors ) and submits. Common pitfall: NIS2's essential / important distinction determines the supervisory regime and the reporting deadlines. If you don't know which applies, look up your sector in the Annex of the NIS2 Directive (2022/2555) before answering — a wrong classification here cascades into the wrong control catalogue. Step 1.2 — jurisdiction confirmation Copy Confirm the jurisdictions where the organisation operates or provides services. List every jurisdiction where the organisation operates or provides services. The worked example sticks with ["SE"] . Step 1.3 — scope review The workflow shows the scope it locked in (entity type, sectors, jurisdictions, framework) and asks for explicit user approval before the control catalogue loads. The pattern is user_review: true in the workflow YAML — changing the framework after this step requires restarting the workflow, so the gate is intentional. Stage 2 — document collection (about 5 minutes, often less) The agent asks for policy documents and lets you upload them. The minimum is zero — the workflow accepts an empty document set and continues — but attached documents make later citations much stronger. Copy Please upload relevant security policies, procedures, and certifications. Documents go in via register_document_init and register_document_finalize (presigned upload), then bind to the workflow with register_document . If you've got nothing to upload, tell the agent "no documents available" and the stage closes. Stage 3 — control assessment (the main loop) This stage is dynamic . The workflow materialises one control prompt per control in your framework and loops until every control is assessed. For NIS2 essential-entity controls that's around ten iterations; for full GDPR it's six articles worth. For each control the workflow fetches the regulatory text via get_provision and a related search via search against the jurisdiction's sector MCP before prompting you. Your job per control: pick a compliance level, pick an evidence tier, and cite at least one piece of evidence. We'll walk three example controls from the NIS2 list. The remaining seven follow the same shape. Example control: risk management Copy Article 21(2)(a) — policies on risk analysis and information system security. How does the organisation currently address risk analysis and information system security? What evidence exists for this implementation? Example answer: Copy compliance_level: largely_compliant evidence_tier: documentary evidence: - "ISMS Policy v3.2 §4 (risk management framework)" - "Annual ISO 27001 internal audit report 2026-02" notes: "Quarterly risk register reviewed by infosec steering committee; risk treatment plan signed off by CISO." Common pitfall: declaring fully_compliant without an authoritative evidence tier (an external audit, a regulator inspection report) usually under-resolves at the findings-review gate. Pick largely_compliant with documentary evidence when an internal artifact is all you have — that's a more honest baseline. Example control: incident handling Copy Article 21(2)(b) — incident handling. What incident-detection, response, and post-incident review processes are in place? What's the evidence? Example answer: Copy compliance_level: partial evidence_tier: documentary evidence: - "Incident Response Plan v2.0 (runbook covers detection + containment + eradication; recovery section incomplete)" notes: "Tabletop exercises run twice in 2025 but post-incident review template not formalised; gap to close before the next external audit." Example control: supply chain Copy Article 21(2)(d) — supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. How does the organisation manage supplier security? What's the evidence? Example answer: Copy compliance_level: not_implemented evidence_tier: supplemental evidence: - "Supplier inventory exists but security-clause review not started" notes: "No DPAs or security schedules in current supplier contracts. Highest-priority gap." The remaining seven controls (business continuity, supply chain security in acquisition / development / maintenance, policies on effectiveness assessment, cyber hygiene + training, cryptography, access control + asset management, MFA + secure communications) follow the same prompt shape. Work through them at your own pace — the workflow remembers state, so you can resume_workflow the next morning if you want. Stage 4 — findings review (about 10 minutes) A user-review gate. The workflow presents a summary table — control ID, title, compliance level, evidence tier — and asks you to confirm or revise. This is the last point to raise the evidence tier on weak controls before the adversarial review probes them. Common pitfall: the temptation is to wave the table through because you already filled it in. Read each partial row carefully — those are the rows the report will surface as recommended remediations, and the evidence reference attached here is what auditors will inspect. Stage 5 — adversarial review (about 10 minutes) Before the report generates, the workflow runs a red-team pass over the completed findings: the agent invokes the /gap-analysis-red-team prompt and works through a fixed probe list — overstated or understated compliance, missed horizontal regimes (GDPR, AI Act, sector rules), evidence-tier inflation, and control-mapping over-reach. The stage's quality gate requires every probe to be attempted; findings it raises go back into the matrix before anything freezes. Stage 6 — report (automatic, under two minutes) Two automatic steps: a quality check (every control assessed; at least 30% must carry documentary or authoritative evidence) and the report generation. The JSON follows the GapAnalysisReport shape — trimmed example: json Copy { "workflow_id": "wf-7a9c1b...", "framework": "nis2", "jurisdictions": ["SE"], "entity_description": "Swedish digital-infrastructure operator (essential entity)", "generated_at": "2026-07-02T14:03:22Z", "executive_summary": { "...": "..." }, "methodology": { "...": "..." }, "findings_matrix": [ { "control_id": "art21_2_a", "control_title": "Policies on risk analysis and IS security", "compliance_level": "largely_compliant", "evidence_tier": "documentary", "gap_description": "Risk framework operational; treatment-plan review cadence undocumented.", "evidence_references": ["ISMS Policy v3.2 §4"], "regulatory_citations": ["NIS2 Art. 21(2)(a)"], "remediation": "Document the quarterly treatment-plan review." } ], "remediation_roadmap": [ { "control_id": "art21_2_d", "priority": "high" } ], "evidence_register": [ { "...": "..." } ] } How to use the report Export it: generate_report returns the structured JSON on every plan; Free and Solo can also request a watermarked HTML/PDF render, and unwatermarked HTML, PDF and DOCX exports start at Team (Premium's report is JSON-only). For a Markdown summary, have your agent reformat the JSON in the conversation — that is a client-side transform, not a report format. Import to your GRC tool: each findings_matrix row is keyed by control ID. Most tools (OneTrust, Vanta, Drata, Hyperproof) accept either a JSON import or a CSV the agent can produce on request. Action the gaps: each not_implemented or partial control maps to a follow-up workflow that actually closes the gap. Examples from this worked run: Supply-chain gap (Art. 21(2)(d)) → DPIA workflow for the supplier processing activities, plus a tender review on next supplier renewal. Incident-handling gap → STRIDE threat model on the systems most likely to be in scope, to feed the response plan with realistic scenarios. The DPIA workflow and the STRIDE threat model run on every plan against a system you describe, within that plan's monthly allowance — 1 run on Free, 2 on Solo, 5 on Premium. Tender review is Team and Company, and so is document grounding for all of them. No fabricated citations If a control can't be backed by a citation after the workflow's enrichment passes, it's flagged as regulatory_basis_unresolved rather than guessed. A report with unresolved citations is still useful — the gaps are explicit and reviewable. Don't read a missing citation as the same thing as a missing requirement. Stuck? Two paths. Email team@ansvar.eu — paste the prompt the workflow gave you and the answer you're considering, and you'll get a useful reply within a business day. Or ask us for a 30-minute onboarding call — we'll drive one run live with you, by hand or through the workflow, and you walk away with a finished report. Previous Workflows Next DPIA --- ## DPIA · Ansvar AI docs URL: https://ansvar.eu/docs/guides/dpia Data Protection Impact Assessment workflow — inputs, stages, and the cited output you get back. DPIA A guided Data Protection Impact Assessment under GDPR Article 35. The workflow walks you through screening, processing description, DPO consultation, risk identification, per-risk analysis, consultation steps and the final report — with citations to the articles and authority guidance that apply. Tier Every plan can run it against a processing activity you describe — the DPIA is one of the seven included workflow types. Free starts 1 workflow run a month and Solo 2, reported as a watermarked rendered document or structured JSON. Premium runs the full interview-grounded catalog (5 runs a month) and receives the complete report as structured JSON; unwatermarked HTML, PDF and DOCX renders start at Team. Team and Company additionally ground the DPIA in your own uploaded documents — processing records, DPAs, policies — via the document plane. Company tier additionally produces a cryptographically anchored audit package via export_audit_package for regulated verticals that need offline-verifiable evidence. What you ask the agent Copy Using Ansvar: start a DPIA for our new HR-screening feature. It scores candidates from CV text and an applicant questionnaire, processing data of EU candidates, hosted in Sweden. The agent calls start_workflow(workflow_type="dpia") and works the stages in turn. Document evidence (data flow diagrams, sub-processor lists, retention schedules) is registered through register_document and cited at paragraph level. Stages Screening & scope — screening question to confirm a DPIA is required, structured processing description, DPO consultation note, document collection, necessity and proportionality assessment, user-reviewed scope confirmation. Risk identification — data-subject views (where applicable under Article 35(9)), risk enumeration, user-reviewed risk list. Risk enumeration follows the EDPB WP248 criteria and CNIL/ISO 29134 methodology, grounded with GDPR-framework search results for the workflow's jurisdictions. Per-risk analysis — this stage is dynamic: one analysis pass per risk identified. Each risk is scored on the CNIL/ISO 29134 severity × likelihood grid (inherent and residual), with mitigations attached per risk. Consultation & compliance — international transfer compliance check, supervisory-authority consultation note where the residual risk requires it (Article 36). Report — generate_report(workflow_id) assembles the DPIA document with all evidence references and citations. What you get back A DPIA report with: processing description, lawful basis and purpose, data-subject categories, necessity and proportionality assessment, risk register with per-risk scoring and mitigations, consultation outcomes, and the residual-risk decision. Each substantive claim cites either a GDPR article, an EDPB guideline, or a national-authority opinion. Living document A DPIA is supposed to be revisited when processing changes. While a workflow is in progress, state persists on every submit_response — resume_workflow(workflow_id) picks up an active run where you left it, even days later. A completed DPIA can't be edited in place: when the processing changes, start a fresh start_workflow(workflow_type="dpia") run and reuse the prior report and registered documents as input evidence. Previous Your first gap analysis Next Threat modeling --- ## Threat modeling · Ansvar AI docs URL: https://ansvar.eu/docs/guides/threat-modeling STRIDE threat modeling workflow — stages, tiers, and the cited report, grounded in the gateway's threat-framework corpora (ATT&CK, ATLAS; CAPEC on Premium+). Threat modeling A STRIDE-driven security threat model for a system you describe to the agent. The workflow walks scoping and DFD construction → six-way STRIDE specialist analysis over the diagram → review → enrichment and scoring → mitigation → report, grounding the enrichment in the gateway's threat-framework corpora. Tier Every plan. Free runs 1 STRIDE threat model a month and Solo runs 2, both on a system you describe, using the full workflow lifecycle ( start_workflow , submit_response , generate_report , plus the create_dfd and recommend_subagents specialists). At those two plans the report arrives as a watermarked rendered document or structured JSON, the run grounds its enrichment at the plan's own search scope, and the allowance is a hard stop — no overage. Premium raises the allowance to 5 runs a month and widens what a run can do: the LINDDUN privacy and TARA risk families, and case law and agency guidance pulled into the enrichment passes, cited verbatim — with the report as structured JSON (rendered exports are not part of Premium). Team raises the quota to 20 runs per seat a month and adds document grounding — evidence from your own uploaded architecture docs — plus unwatermarked HTML, PDF and DOCX renders. The threat-pattern lookups ( search with sources=['threat-frameworks'] ) and the CVE tools ( search_cve and friends) are available for ad-hoc briefs without the workflow. What you ask the agent Copy Using Ansvar: run a threat model for our payments service. It's a Go API behind nginx, talking to Postgres and Stripe, with OAuth-authenticated customer clients and a Keycloak IdP. The agent calls start_workflow(workflow_type="threat_model") and guides the rest from there. Stages Scoping & DFD — system description and key assets, a scope check, then data-flow-diagram construction: the agent extracts components, data flows, trust zones, and assets, validates the graph with create_dfd , and shows you the rendered Mermaid diagram for review before analysis starts. On Team and Company, architecture diagrams and design docs go in via register_document ; on Free, Solo and Premium, you describe the system in the conversation instead. Document collection (Team+) — supporting evidence: existing security controls, network diagrams, IAM policies. Runs on Free, Solo and Premium skip this stage and work from the described system. STRIDE analysis — one dispatch step that fans out six STRIDE-category specialists (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) over the reviewed DFD — in parallel where the client supports subagents, sequentially elsewhere — and merges their threat lists into one register with a coverage matrix. Threat review — user-reviewed threat register before enrichment. Threat enrichment & scoring — adds attack-chain references and related patterns from the framework corpora via search (MITRE ATT&CK and ATLAS on every plan; CAPEC, CWE and D3FEND on Premium and above), then scores severity and likelihood per threat. Mitigation — for each high-priority threat, one or more proposed mitigations with cited control sources (NIST, ISO, sector frameworks where the agent has them in scope). Report — generate_report(workflow_id) assembles the threat-model document. The structured threat list is also retrievable via get_workflow_threats(workflow_id) for programmatic downstream use. What you get back A structured threat model: system scope, components with type and technology, threat register with STRIDE category, severity, likelihood, mitigation, and an evidence reference for each. The threat list is queryable independently of the prose report — useful if you want to roll the findings into a ticketing system. Privacy threats: use LINDDUN STRIDE covers security threats. For privacy threats specifically — linkability, identifiability, non-repudiation as a privacy harm, and so on — start a linddun workflow instead (Premium and above). Both workflows share the same lifecycle tools and report shape; the difference is the threat taxonomy and the corpus the agent queries. Previous DPIA Next Cite your documents --- ## Clients without OAuth · Ansvar AI docs URL: https://ansvar.eu/docs/connecting-without-oauth Connect MCP clients that can't do OAuth — AnythingLLM and scripts via mcp-remote; n8n, Open WebUI and headless setups via a managed service credential. Clients without built-in OAuth Most MCP clients sign in with OAuth — point them at https://gateway.ansvar.eu/mcp and approve the browser login. Those recipes live on the Setup page. This page is for the clients that can't do that: ones that only accept a fixed Authorization header, or that run on a server with no browser. A pasted token on its own won't hold — every token the gateway issues is short-lived and expires within minutes, and these clients don't refresh. The fix depends on whether your client can run a small local helper. Clients that can run a local helper AnythingLLM Desktop and custom scripts can launch a local command. Use mcp-remote , a community helper that performs the OAuth login and token refresh on the client's behalf and exposes the gateway as a local server. Your client talks to the helper; the helper talks to Ansvar. This removes the expiry problem entirely — it runs in OAuth mode, not as a static header. Requires Node.js 18+. In AnythingLLM, edit plugins/anythingllm_mcp_servers.json (or Settings → Agent Skills → MCP Servers): json Copy { "mcpServers": { "ansvar": { "command": "npx", "args": ["-y", "mcp-remote@0.1.38", "https://gateway.ansvar.eu/mcp"], "env": {} } } } On first start your browser opens to the Ansvar login; after that it reconnects on its own. For long-running unattended setups, request a longer-lived refresh with the offline_access scope: json Copy "args": [ "-y", "mcp-remote@0.1.38", "https://gateway.ansvar.eu/mcp", "--static-oauth-client-metadata", "{\"scope\":\"mcp:tools offline_access\"}" ] Pin the helper version mcp-remote is community-maintained, not an Ansvar component, and it handles your tokens. Pin mcp-remote@0.1.38 and never run below 0.1.16 — the patched floor for CVE-2025-6514, a remote-code-execution flaw in mcp-remote 0.0.5–0.1.15. It stores tokens locally and signs in only to Ansvar's own login. Custom code Writing your own client? Use the MCP SDK and pass your own OAuth access token as a Bearer header to https://gateway.ansvar.eu/mcp . Obtain it via OAuth 2.1 Authorization Code + PKCE against auth.ansvar.eu/realms/ansvar , and refresh it yourself — access tokens are short-lived. Headless and static-header-only clients Some clients can't use the helper — they connect over HTTP with a fixed header and can't run a local command, or they run on a server with no browser for the one-time login. This includes n8n , Open WebUI , AnythingLLM in Docker , CI/CD jobs, and agents built on the Gemini API or Google ADK , which pass a fixed bearer header instead of running an OAuth flow (see Connect Gemini ). These need a scoped, revocable service credential rather than a browser login. Service credentials are org-owned seats A service credential belongs to an organization and takes a seat of its own on it, like a team member does (your sign-in holds a seat too). It carries the same tool surface as a signed-in seat on your plan: search, provision lookup, citation validation, workflow runs, document upload and report generation all work. There are no static API keys — a service credential is an OAuth2 client-credentials client, and your server exchanges its secret for short-lived access tokens at auth.ansvar.eu . That exchange is the catch for a client that can only hold one fixed header and never re-requests a token: it needs something in front of it that refreshes, because the token expires within minutes. On Team and Company , an organization admin creates one directly in the account area → Service credentials — no request needed. The full recipe, including the token exchange and the rotate/revoke rules, is on Service credentials . On other plans, contact us with the client you're connecting and the organization it belongs to, and we'll work out the right shape. Troubleshooting 401 / "Authentication required" on connect — the client sent no valid login. Use the helper above, or connect with a service credential . Works for a few minutes, then 401s — a static token expired. Use the helper's OAuth mode, which refreshes; don't paste a token. 404 at the endpoint — the MCP endpoint is https://gateway.ansvar.eu/mcp , not the bare host. Cryptic node:fs/promises crash — the client launched npx under an old Node. Install Node 18+ and make sure it's first on the client's PATH. Verified 2026-07-02 — and moving fast The mcp-remote version, AnythingLLM config path, and client behaviours on this page were verified on 2026-07-02. These are community-maintained projects that ship often — if a step no longer matches what you see, tell us and we'll re-verify. Previous Connect Azure AI Foundry Next Service credentials --- ## Service credentials · Ansvar AI docs URL: https://ansvar.eu/docs/service-credentials Create, rotate and revoke org-owned service credentials — client_credentials tokens for n8n, CI jobs and other headless clients that can't do OAuth. Service credentials A service credential is an OAuth2 client_credentials client that your organization owns. A headless client — an n8n workflow, a CI job, a server-side script — exchanges its client ID and secret for a short-lived access token and calls the gateway with that token. No browser, no interactive login, no static API key. Reach for one when the client cannot complete an interactive OAuth login — it runs on a server with no browser — but can perform the token exchange itself: n8n's OAuth2 credential, most server SDKs, a CI script with a few lines of shell. If your client can launch a local command instead, the mcp-remote bridge is simpler — see Clients without OAuth . A pasted token is not a connection A client that can only hold one fixed Authorization header, and never re-requests a token, cannot use a service credential on its own — the access token it holds expires within 15 minutes. Either put something in front of it that performs the exchange, or use a client that speaks OAuth2 client credentials natively. Who can create one Creating and rotating require an organization admin on a Team or Company plan. Listing and revoking stay available to an org admin on any plan. That is deliberate: an organization that downgrades must still be able to kill a credential that is live. The credential belongs to the organization , not to the admin who created it — any of the organization's admins can see it and revoke it, and can rotate it while the organization is on Team or Company. It takes a seat of its own , counted together with people. The account page reads N of M seats used (people and service credentials) . Your own sign-in counts as one of those seats, so an organization on a single seat adds a second before it can mint a credential. Seats and roles are covered in Manage your organization . Create one Open your account area → Service credentials and choose Create credential . Name it after the system that will use it — n8n production , nightly CI . The name is how you will know what breaks when you revoke it. Copy the client ID and the client secret into the secret store that client already uses. The secret is shown once The client secret appears in the reveal dialog and is never shown again — we do not keep a copy that can be handed back. If it is lost, rotate the credential: rotation issues a new secret and keeps the same client ID. Connect with it Exchange the credential for an access token at auth.ansvar.eu , then send that token to the gateway as a bearer token: bash Copy # 1. Exchange the credential for an access token TOKEN=$(curl -s -X POST https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/token \ -d grant_type=client_credentials \ -d client_id=YOUR_CLIENT_ID \ -d client_secret=YOUR_CLIENT_SECRET | jq -r .access_token) # 2. Call the MCP endpoint with that token curl -s -X POST https://gateway.ansvar.eu/mcp \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' Access tokens last 15 minutes . The credential itself is long-lived, so the client should exchange the secret for a fresh token whenever the current one is close to expiry, and never write an access token to disk or into a saved configuration. Clients that speak OAuth2 client credentials natively — n8n's HTTP Request credential, most server SDKs — handle that refresh once you give them the token URL, the client ID and the secret. Connect an agent to it The steps above get you a token and prove the connection. What consumes that token is your own agent — the gateway is a tool source, not a model, so something on your side has to run the model and its tool loop. Two shapes, depending on how much you want to own. Let your model provider connect for you If you build on the Anthropic API, its MCP connector takes a remote server URL and a bearer token and runs the tool calls for you — you never write a tool loop. Pass the access token from step 1 as authorization_token : bash Copy curl -s https://api.anthropic.com/v1/messages \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "anthropic-beta: mcp-client-2025-11-20" \ -H "content-type: application/json" \ -d '{ "model": "claude-opus-5", "max_tokens": 4096, "mcp_servers": [{ "type": "url", "url": "https://gateway.ansvar.eu/mcp", "name": "ansvar", "authorization_token": "'"$TOKEN"'" }], "tools": [{"type": "mcp_toolset", "mcp_server_name": "ansvar"}], "messages": [{"role": "user", "content": "Using Ansvar: search EU law for the NIS2 incident reporting deadline. Cite the article."}] }' The response carries mcp_tool_use and mcp_tool_result blocks alongside the text, so you can see which corpora answered and check the citations. Three things that trip up the first call authorization_token takes the access token, not the client secret. It expires in 15 minutes, so exchange the secret for a fresh one per run rather than storing it. mcp_servers and tools are both required. Declaring the server without the matching mcp_toolset entry is rejected — the names must match. Leave room in max_tokens . Our tool descriptions and the rows we return are substantial, and on models where reasoning is on by default it shares that budget — a small cap truncates the answer mid-sentence. Or run the loop yourself Any model can use the gateway if you drive the loop: call tools/list as above, hand those schemas to your model as its tool definitions, and when it asks for a tool, call tools/call and feed the result back. This is what an n8n workflow or a CI script is doing under the hood, and it is the route to take when your provider has no MCP support of its own. What it can and cannot do A service credential gets the same tool surface as a signed-in seat on your plan : search across the corpora, provision lookup, citation validation, workflow runs, document upload and report generation. It passes the same tier gates as any other seat and draws from the organization's pooled quota. Run ceiling — each credential carries a monthly workflow-run ceiling. The default is half of what one seat contributes to your organization's monthly pool, so one runaway agent cannot drain what the rest of the organization shares. Stays with signed-in humans — audit-ledger decryption, and assent on architecture proposals (a credential can propose changes; a person approves them). The gateway enforces this on both sides of the call: those tools are hidden from tools/list and refused at tools/call even if the client asks for one by name. Standard seats A credential can hold a seat of a licensed ISO standard, and that is how you build an agent that reads the standard rather than paraphrasing it from memory. Your organization buys seats of a standard; an admin then assigns each seat, under Standards & documents in the account area, to a person or to a credential. The recipe for an ISO-expert agent is two things: a service credential, and a standard seat assigned to it. The two requirements are separate. A standard seat does not require an organization seat — a person can hold a standard on any plan. A credential does require Team or Company , because that is what creating a credential requires, so an agent that holds a standard is always inside a Team or Company organization. Seats are per holder, not per organization: assigning a standard to one credential does not give it to the others. Releasing a seat returns it to the pool to assign again, and revoking a credential releases any seat it held. Volume discounts on seats are available on request — the pricing page has the contact route. Rotate and revoke Rotate issues a new secret and keeps the same client ID. The old secret stops working immediately, so update the client in the same change window. Rotate on a schedule you set, and straight away if a secret may have been exposed. Revoke refuses new tokens immediately and frees the seat. Access tokens already issued keep working until they expire — up to 15 minutes . Plan for that window: revocation is not a kill switch for a request already in flight. A row marked needs attention means the credential does not work — the client behind it cannot get a token. Revoke it and create a new one; there is nothing to repair in place. Troubleshooting 401 right after a rotation — the client is still sending the old secret. The old one dies the moment the new one is issued; there is no overlap period. 401 on a token that worked minutes ago — the access token expired. Exchange the secret for a fresh one instead of storing the token. 404 at the endpoint — the MCP endpoint is https://gateway.ansvar.eu/mcp , not the bare host. Create refused, "all your seats are in use" — a credential takes a seat like a member does. Raise the seat count under Manage subscription, or revoke a credential you no longer need. Create or rotate refused on your plan — minting is Team and Company only. Listing and revoking still work, so an existing credential can always be shut off. A tool you expected is missing from tools/list — a credential sees the tool surface of its plan's tier, so check the tier gate for that tool first. The two admin-side surfaces (audit-ledger decryption, assent on architecture proposals) are hidden from credentials by design; run those from a signed-in seat. Previous Clients without OAuth Next What is the gateway --- ## Connect Gemini · Ansvar AI docs URL: https://ansvar.eu/docs/setup/gemini Connect Google Gemini to the Ansvar gateway — Gemini CLI and Code Assist via OAuth, Antigravity, Gemini Enterprise, and the headless API path. Connect Gemini "Gemini" is several products, and their MCP support differs. Developer surfaces — Gemini CLI , Gemini Code Assist , and Google Antigravity — connect to the gateway the same way Claude or Cursor do: point them at https://gateway.ansvar.eu/mcp and approve one browser login. The Gemini app at gemini.google.com and Gemini Enterprise are more constrained; their sections below say exactly what works today. If you build your own agent on the Gemini API or ADK , you need the headless path at the end. Gemini CLI One command registers the gateway: bash Copy gemini mcp add --transport http ansvar https://gateway.ansvar.eu/mcp By default this writes to .gemini/settings.json in the current project; add --scope user to register it globally in ~/.gemini/settings.json . Then start gemini and run: Copy /mcp auth ansvar A browser opens for the OAuth login at auth.ansvar.eu — there is no client ID or key to configure; Gemini CLI discovers the gateway's OAuth endpoints and registers itself automatically. Approve the login, return to the terminal, and verify with /mcp list : the ansvar server should read connected, with the tool catalogue your tier includes. Run gemini-cli v0.44.0 or newer Ansvar access tokens are short-lived and rotate. Versions before v0.44.0 (2026-05-27) cached the token once per session and lost authentication when it expired mid-session. Update with npm install -g @google/gemini-cli . If tool calls still start failing with an authentication error in a long session, run /mcp auth ansvar again — a narrower refresh issue remains open upstream. Gemini CLI itself needs a paid Google plan Google retired the free individual tiers (Gemini Code Assist for individuals, AI Pro, AI Ultra) for Gemini CLI and the Code Assist IDE extensions on 2026-06-18. You need a Gemini Code Assist Standard or Enterprise license, or a paid Gemini API key. This is a Google-side requirement, independent of your Ansvar account. Gemini Code Assist (VS Code and JetBrains) Code Assist's agent mode shares the Gemini CLI engine. In VS Code it reads the same ~/.gemini/settings.json , so the CLI command above (with --scope user ) also configures the extension. Or add the entry by hand — JetBrains uses a separate mcp.json in the IDE's config directory with the same schema: json Copy { "mcpServers": { "ansvar": { "httpUrl": "https://gateway.ansvar.eu/mcp" } } } The first tool call triggers the browser OAuth flow. Agent mode is still labelled Preview by Google, and org admins can restrict which MCP servers load — if the server never appears, ask whether your organization enforces an MCP allowlist. Google Antigravity In the Agent panel, open the … menu → MCP Servers → Manage MCP Servers → View raw config, and add: json Copy { "mcpServers": { "ansvar": { "serverUrl": "https://gateway.ansvar.eu/mcp" } } } Note the field name — Antigravity uses serverUrl , not the httpUrl key the rest of the Gemini family reads. Restart Antigravity, then authenticate from the MCP Servers panel. Antigravity handles OAuth automatically for servers that support Dynamic Client Registration, which the gateway does — no client credentials to paste. The Gemini app (gemini.google.com) The regular Gemini chat — consumer or Workspace — has no custom MCP or connector support; only Google's own curated apps are available. The exception is Gemini Spark , the agentic mode Google launched 2026-06-30: it accepts custom MCP apps and registers against the gateway automatically. Spark is currently limited to personal Google AI Ultra accounts (US, 18+) and is not available on Workspace-managed accounts, so it is not a path for an enterprise rollout yet. If your team uses the Gemini app day-to-day, the practical options today are Gemini CLI or Gemini Enterprise. Gemini Enterprise Gemini Enterprise (formerly Agentspace) can reach the gateway through its Custom MCP Server connector — an admin-configured data store, currently in Preview and off by default until a Google Cloud org-policy admin enables it. Unlike the developer surfaces, this connector does not self-register: it asks for a pre-provisioned OAuth client ID and secret alongside the authorization and token URLs. We provision that client for you. Contact us with your organization name, and we return the client credentials plus the exact values for each connector field. Google's side is: Google Cloud Console → Agent Platform → Data stores → Create data store → Custom MCP Server, with the server URL https://gateway.ansvar.eu/mcp . The connector speaks streamable HTTP, which is what the gateway serves. Agent Studio's 'Add MCP Server' won't work Gemini Enterprise has a second, in-agent way to add MCP servers (Agent Studio). It currently supports only servers without authentication, so it cannot connect to the gateway. Use the Custom MCP Server connector path above. Instruct your agent — the routing pack A connected agent without routing instructions can still answer legal questions from its training data — the connector sitting idle at exactly the moment it should prove itself — when a message does not name Ansvar. Where it lives depends on the surface: Gemini CLI and Code Assist read a project GEMINI.md (or a global ~/.gemini/GEMINI.md ), Antigravity takes it as an Always-On rule, and a Gemini Enterprise agent takes it in the system-instructions field. The block is the same set that Instruct your agent explains line by line; adapt the jurisdictions to your market. text Copy You are a compliance research assistant. Answer legal, regulatory, and security-standards questions only from Ansvar tool results, never from your own knowledge. For every legal, regulatory, or standards question: 1. Call the search tool, always with a scope: jurisdictions=["SE"] (adapt to your market; add "EU" for EU regulation - GDPR, NIS2, the AI Act), or frameworks=["GDPR"] for one EU framework across the board. On the Free plan, pass exactly one jurisdiction or framework per call. 2. Never pass the user's whole question as the query. Reduce it to 1-3 legal key terms in the language of the law you are searching - Swedish terms for Swedish law. Try alternative terms as separate searches. If a multi-concept query returns nothing, split it into one search per concept. 3. If a search returns nothing, retry once with a synonym or a broader term, then retry with allow_broadening=true and label any relaxed matches as such. 4. Cite every answer: law, article, and source URL from the results. If the results do not contain the answer, say which searches you ran and that you will not answer from memory - never invent a source. Building your own: Gemini API, ADK, Interactions API None of the code-level Gemini paths run the browser OAuth flow for you — they pass a fixed Authorization header. Google's ADK attaches the gateway via McpToolset(connection_params=StreamableHTTPConnectionParams(url=...)) with a header provider; the Interactions API's native mcp_server tool takes a static headers map (and does not yet support Gemini 3 models). Because gateway tokens expire within minutes, a pasted token won't hold — headless setups need a managed service credential, the same shape as n8n or CI. See Clients without OAuth . Verified 2026-07-02 — and moving fast These recipes were verified against Google's current documentation on 2026-07-02. Google ships changes to this surface frequently. If a step no longer matches what you see, tell us and we'll re-verify. Previous Clients and models Next Connect ChatGPT --- ## Connect ChatGPT · Ansvar AI docs URL: https://ansvar.eu/docs/setup/chatgpt Connect ChatGPT to the Ansvar gateway — a custom connector in Developer mode, Business/Enterprise rollout notes, Codex CLI, and the API path. Connect ChatGPT ChatGPT connects to the gateway as a custom connector with Developer mode switched on: paste one URL, approve one browser login, and the tool catalogue appears. It works on every paid plan — Plus, Pro, Business (the plan formerly called Team), Enterprise, and Edu; the Free tier cannot add custom connectors. Two naming notes so the menus match what you read here: OpenAI renamed "Connectors" to Apps in late 2025, and both labels still appear in the product. Step 1 — turn on Developer mode Settings → Apps (or "Apps & Connectors") → Advanced settings → toggle Developer mode . Developer mode is what gives ChatGPT full MCP support. Without it, custom connectors are restricted to tools literally named search and fetch — the deep-research interface — and the gateway's real surface ( get_provision , validate_citation , list_coverage , the workflow tools) would be invisible. With Developer mode on, ChatGPT can call every tool your Ansvar tier includes, and asks you for confirmation before consequential actions by default. Step 2 — create the connector Settings → Connectors → Create , then fill in: Copy Name: Ansvar Description: EU law, regulation, and standards — cited answers MCP server URL: https://gateway.ansvar.eu/mcp Authentication: OAuth There is no client ID or secret to obtain — ChatGPT registers itself with the gateway's login service automatically on save. If the form shows a Client ID field as required, leave it empty and submit anyway; that field is a known cosmetic quirk of the connector form. The browser opens for the OAuth login at auth.ansvar.eu ; approve it, and ChatGPT lists the tools your tier includes. A connector added on the web is available in the ChatGPT mobile apps automatically. Verify: ask "Which Ansvar tools are available?" — ChatGPT should enumerate the catalogue, starting with search . Rolling out to Business or Enterprise On Business (formerly Team), only workspace admins and owners can enable Developer mode, and each admin enables it for themselves — the toggle is not workspace-wide. On Enterprise and Edu , apps are off by default: an admin enables them, grants Developer mode to named members via Workspace Settings → Permissions & Roles, and can scope per-app access with role-based access control. Two things your admin will want to know. First, OpenAI does not review custom connectors — the console tells admins to add one only if they know and trust the developer, which for the gateway means us: EU-hosted, licensing-audited, no training on your data . Second, ChatGPT's default per-app permission level ("Important actions") auto-approves reads but asks before actions with external effect — the gateway's tools are read-only research and workflow calls against your own tenant, so the prompts you see will be proportionate. Deep research is not the way in — yet ChatGPT's deep-research connector class requires a server exposing exactly a search + fetch pair with a fixed schema. The gateway serves a richer surface instead, so it connects through Developer mode and normal chat rather than as a deep-research source. For long research questions, one tip carries over: the gateway's search matches all terms — have ChatGPT decompose compound questions into short scoped queries (see Troubleshooting ). Codex CLI OpenAI's coding agent connects in two commands: bash Copy codex mcp add ansvar --url https://gateway.ansvar.eu/mcp codex mcp login ansvar Codex detects the gateway's OAuth support, registers itself automatically, and opens the browser login — we verified this discovery flow against the live gateway with codex-cli 0.142.5 on 2026-07-02. Tokens are stored by Codex, not written into config.toml . For CI or containers with no browser, codex mcp add ansvar --url … --bearer-token-env-var ANSVAR_TOKEN takes a static credential instead — that path needs a managed service credential, since gateway tokens expire in minutes (see Clients without OAuth ). Building on the OpenAI API The Responses API and Agents SDK attach remote MCP servers with a static bearer token — neither runs the OAuth flow for you, and the Responses API discards the credential after every request, so your application must resupply a live token each call: python Copy response = client.responses.create( model="gpt-5.5", input="Using Ansvar: what does DORA require for ICT incident classification?", tools=[{ "type": "mcp", "server_label": "ansvar", "server_url": "https://gateway.ansvar.eu/mcp", "authorization": ansvar_access_token, # your app obtains + refreshes this "allowed_tools": ["search", "get_provision"], }], ) Because gateway tokens are short-lived by design, headless setups should use a managed service credential rather than a pasted token — the same shape as n8n or CI. See Clients without OAuth . Instruct your agent — the routing pack A connected agent without routing instructions can still answer legal questions from its training data — the connector sitting idle at exactly the moment it should prove itself — when a message does not name Ansvar. Paste the block below into a Project's instructions — every chat in that project carries it, and project instructions take precedence over your global custom instructions — or into ChatGPT's custom instructions for general chats. Do not rely on connector metadata alone to steer the model. The block is the same set that Instruct your agent explains line by line; adapt the jurisdictions to your market. text Copy You are a compliance research assistant. Answer legal, regulatory, and security-standards questions only from Ansvar tool results, never from your own knowledge. For every legal, regulatory, or standards question: 1. Call the search tool, always with a scope: jurisdictions=["SE"] (adapt to your market; add "EU" for EU regulation - GDPR, NIS2, the AI Act), or frameworks=["GDPR"] for one EU framework across the board. On the Free plan, pass exactly one jurisdiction or framework per call. 2. Never pass the user's whole question as the query. Reduce it to 1-3 legal key terms in the language of the law you are searching - Swedish terms for Swedish law. Try alternative terms as separate searches. If a multi-concept query returns nothing, split it into one search per concept. 3. If a search returns nothing, retry once with a synonym or a broader term, then retry with allow_broadening=true and label any relaxed matches as such. 4. Cite every answer: law, article, and source URL from the results. If the results do not contain the answer, say which searches you ran and that you will not answer from memory - never invent a source. If something breaks The connector connected once, then authentication fails and re-linking doesn't help. ChatGPT has a known issue with published workspace connectors: it pins the original client registration and won't re-register if that client is ever invalidated. Deleting and recreating the connector fixes it. Tools are missing. Check Developer mode is on (without it you'll see at most a crippled two-tool view), then check your Ansvar tier — tools outside it are absent by design (see the tool reference ). Everything else — the general troubleshooting page covers OAuth popups, quota errors, and empty results. Verified 2026-07-02 — and moving fast These steps were verified against OpenAI's current documentation on 2026-07-02, and the OAuth flow against the live gateway. OpenAI ships changes to this surface frequently — menu names have already changed twice. If a step no longer matches what you see, tell us and we'll re-verify. Previous Connect Gemini Next Connect Cursor --- ## Connect Cursor · Ansvar AI docs URL: https://ansvar.eu/docs/setup/cursor Connect Cursor to the Ansvar gateway — the mcp.json config for project and global scope, automatic OAuth, and what to check when tools don't appear. Connect Cursor Cursor connects to the gateway as a remote MCP server — one JSON block, no separate app to install. OAuth runs in the browser the first time your agent calls a tool. Cursor's own pricing page lists MCP support under its paid Individual plans (Pro, Pro+, Ultra), not among the free Hobby tier's features, so if the MCP settings described below are missing, that is the likely reason — check your plan before assuming the config is wrong. You need an Ansvar account first — create a free one from the pricing page by signing in with Google or Microsoft, or with email; no card, no checkout. OAuth consent completes in your browser on the first tool call. Step 1 — add the server Cursor reads MCP servers from a JSON file at two possible scopes: a project-level .cursor/mcp.json in the repository root (available only in that project), or a global ~/.cursor/mcp.json in your home directory (available in every project you open). Add the gateway to whichever scope fits — global if you want it everywhere, project-level if you're rolling it out to one repo first: json Copy { "mcpServers": { "ansvar": { "url": "https://gateway.ansvar.eu/mcp" } } } The same block works at either path — Cursor's docs describe both locations, with project config taking precedence where the same server is defined in both. Restart Cursor (or reload the window) after editing the file by hand. Prefer a UI: Cursor Settings → MCP (labelled Tools & MCP in newer builds) → add a new server, and paste the same URL into the URL field. Cursor has renamed and moved this panel before, so the JSON file above is the steadier way in if the menu doesn't match what you see. Step 2 — authenticate Cursor discovers the gateway's OAuth support automatically for a server configured with only a url field: on first use it opens a browser at auth.ansvar.eu — approve the login and Cursor is authenticated. There is no client ID or secret to obtain or paste — this is Dynamic Client Registration, the same mechanism the ChatGPT and Gemini connectors use. Cursor's docs also describe a static auth block ( CLIENT_ID / CLIENT_SECRET ) for servers that don't support automatic discovery; the gateway does, so you don't need it. Step 3 — verify tools appear Open the MCP settings panel and confirm ansvar shows a connected status with a tool count, or ask the agent directly: "Which Ansvar tools are available?" — it should list search and the rest of the catalogue your tier includes. Try a question In the Agent panel, ask something with a citable answer, for example: "Using Ansvar, what does GDPR Article 33 require for a personal data breach notification, and within what deadline?" A grounded answer names the article and quotes the deadline from the fetched text, not from Cursor's own model memory. Instruct your agent — the routing pack A connected agent without routing instructions can still answer legal questions from its training data — the connector sitting idle at exactly the moment it should prove itself — when a message does not name Ansvar. Add the block below as a root AGENTS.md or an Always project rule — rules set to Manual or Auto Attached do not reach every session — or as a User Rule to carry it across projects. The block is the same set that Instruct your agent explains line by line; adapt the jurisdictions to your market. text Copy You are a compliance research assistant. Answer legal, regulatory, and security-standards questions only from Ansvar tool results, never from your own knowledge. For every legal, regulatory, or standards question: 1. Call the search tool, always with a scope: jurisdictions=["SE"] (adapt to your market; add "EU" for EU regulation - GDPR, NIS2, the AI Act), or frameworks=["GDPR"] for one EU framework across the board. On the Free plan, pass exactly one jurisdiction or framework per call. 2. Never pass the user's whole question as the query. Reduce it to 1-3 legal key terms in the language of the law you are searching - Swedish terms for Swedish law. Try alternative terms as separate searches. If a multi-concept query returns nothing, split it into one search per concept. 3. If a search returns nothing, retry once with a synonym or a broader term, then retry with allow_broadening=true and label any relaxed matches as such. 4. Cite every answer: law, article, and source URL from the results. If the results do not contain the answer, say which searches you ran and that you will not answer from memory - never invent a source. If something breaks No MCP settings in Cursor at all. Check your plan — Cursor's own pricing page lists MCP under the paid plans (Pro, Pro+, Ultra), not among the free Hobby tier's features. The server doesn't appear after editing mcp.json by hand. A single JSON syntax error drops the whole file silently rather than just the broken entry — validate it, and check whether a project-level file and a global file both define an ansvar entry (the project one wins). Tools are missing or the wrong set appears. Tools outside your Ansvar tier are absent by design — see the tool reference . Everything else — the general troubleshooting page covers OAuth popups, quota errors, and empty results. Verified 2026-07-24 — and moving fast These steps were verified against Cursor's current documentation and pricing page on 2026-07-24. Cursor ships changes to this surface frequently — its MCP settings panel has already been renamed once. If a step no longer matches what you see, tell us and we'll re-verify. Previous Connect ChatGPT Next Connect Le Chat --- ## Connect Le Chat · Ansvar AI docs URL: https://ansvar.eu/docs/setup/le-chat Connect Mistral's Le Chat (now Vibe) to the Ansvar gateway as a custom MCP connector — the Connectors UI, automatic OAuth, and plan-availability notes. Connect Le Chat Mistral's chat product — launched as Le Chat , and documented as Vibe (with the workspace side called Vibe Work) since Mistral's 2026 renaming — connects to the gateway as a Custom MCP Connector . Mistral doesn't run a submission process for third-party servers to join its built-in connector directory, so configuring a custom connector in your own workspace — a two-minute form, no code — is the way in today. The steps below use the current Vibe UI names. Step 1 — add a custom MCP connector Open the Connectors page, click + Add Connector , and switch to the Custom MCP Connector tab. Fill in: Copy Connector name: Ansvar Server URL: https://gateway.ansvar.eu/mcp Description: EU law, regulation, and standards — cited answers Description is optional; the name and server URL are what Le Chat needs. Click Connect . Step 2 — authenticate Le Chat auto-detects a connector's authentication method — no auth, an HTTP bearer token or basic auth, or OAuth 2.1 with Dynamic Client Registration. The gateway advertises OAuth 2.1 with DCR, so clicking Connect should open a browser consent screen at auth.ansvar.eu on its own — approve it, and there's no client ID or secret to obtain by hand. Step 3 — use it in a conversation In a chat, click the + icon or type / in the input, select Tools , and enable the Ansvar connector — Mistral's current docs give exactly that flow. After that the gateway's tools are called when your question needs them — you don't select a tool by name, just describe what you need. Try a question Ask something with a citable answer, for example: "Using Ansvar, what does NIS2 require of an essential entity's incident-reporting timeline?" A grounded answer names the article and cites the fetched text, not Le Chat's own model memory. Which plans can add a custom connector Mistral's launch announcement for connectors describes them as "everything available on the Free plan" — no MCP-specific paywall is stated there or in Mistral's technical documentation. Mistral's docs do describe custom connectors as an administrator-only feature: on solo Free, Pro, and Student accounts the account owner is the administrator by default, so there's nothing extra to unlock; Team and Enterprise workspaces need an admin to add or approve one. Seen a paid-only claim elsewhere? Some third-party write-ups describe custom MCP connectors as restricted to paid plans. Mistral's own current documentation states no such restriction (checked 2026-07-24): the launch announcement put connectors on the Free plan, and the MCP connector docs impose only the administrator requirement above. If your Free workspace lacks the Custom MCP Connector tab anyway, ask Mistral support — vendor UIs move faster than anyone's documentation, including ours. Instruct your agent — the routing pack A connected agent without routing instructions can still answer legal questions from its training data — the connector sitting idle at exactly the moment it should prove itself — when a message does not name Ansvar. Paste the block below under Context → Instructions so new tasks carry it. The block is the same set that Instruct your agent explains line by line; adapt the jurisdictions to your market. text Copy You are a compliance research assistant. Answer legal, regulatory, and security-standards questions only from Ansvar tool results, never from your own knowledge. For every legal, regulatory, or standards question: 1. Call the search tool, always with a scope: jurisdictions=["SE"] (adapt to your market; add "EU" for EU regulation - GDPR, NIS2, the AI Act), or frameworks=["GDPR"] for one EU framework across the board. On the Free plan, pass exactly one jurisdiction or framework per call. 2. Never pass the user's whole question as the query. Reduce it to 1-3 legal key terms in the language of the law you are searching - Swedish terms for Swedish law. Try alternative terms as separate searches. If a multi-concept query returns nothing, split it into one search per concept. 3. If a search returns nothing, retry once with a synonym or a broader term, then retry with allow_broadening=true and label any relaxed matches as such. 4. Cite every answer: law, article, and source URL from the results. If the results do not contain the answer, say which searches you ran and that you will not answer from memory - never invent a source. If something breaks The tool catalogue looks incomplete, or doesn't reflect a tier change. Mistral's docs note that Custom MCP Connectors don't yet support dynamic tool discovery — remove and re-add the connector to pick up a changed tool list. No Custom MCP Connector tab. This is an administrator-managed feature in Team and Enterprise workspaces — ask your workspace admin to add it or grant you access. Tools are missing. Tools outside your Ansvar tier are absent by design — see the tool reference . Everything else — the general troubleshooting page covers OAuth popups, quota errors, and empty results. Verified 2026-07-24 — and moving fast These steps were verified against Mistral's current documentation on 2026-07-24, and the OAuth advertisement against the live gateway. Le Chat's connector surface is new and ships changes fast. If a step no longer matches what you see, tell us and we'll re-verify. Previous Connect Cursor Next Connect Copilot Studio --- ## Connect Copilot Studio · Ansvar AI docs URL: https://ansvar.eu/docs/setup/copilot-studio Connect Copilot Studio to the Ansvar gateway — per-user OAuth, or a team rollout with maker-provided credentials so Teams users never sign in. Connect Copilot Studio Copilot Studio lets you build an agent that calls Ansvar through the gateway and publish it to Teams, web, or M365 Chat — same citation contract, M365-native UX. The connection rides Power Platform connector infrastructure at tenant level, so there are more steps than for a personal client. There are two ways to authenticate: per-user (the default — each user signs in with their own Ansvar account) and the team rollout (one shared connection, no per-user sign-in in Teams). Prerequisites A Copilot Studio license (any tier with custom-connector permission). An Ansvar account — Free is enough to evaluate, and carries one STRIDE threat-model run a month; Solo unlocks multi-source fan-out and a second run; Premium adds case law, preparatory works, and agency guidance, plus the LINDDUN and TARA families. Workflows on your own documents require Team or Company. Tenant admin permission to register a custom connector — or an admin who will sign off at publish time. Per-user setup (default) Each user keeps their own tier, quota, and audit trail. Copilot Studio supports MCP Dynamic Client Registration, so there is nothing to provision on our side: Create a new agent ( Copilot Studio → Create → New agent ) and name it — for example, "Ansvar Compliance". From the agent's Tools tab, add an MCP connection with https://gateway.ansvar.eu/mcp as the server URL. Pick OAuth 2.0 with dynamic discovery — Copilot Studio reads the gateway's OAuth metadata and registers itself; no client ID to paste. Authorize the connection: a pop-up opens sign-in at auth.ansvar.eu , and after consent the connection shows Connected. Verify tools appear. On a Premium connection you should see the research tools (search, provision lookup, coverage) and the workflow tools (Premium runs the described-system threat-model family — STRIDE, LINDDUN, TARA — metered monthly; Free and Solo see the same tools but may start STRIDE only). Document-upload tools and the rest of the workflow catalog appear only on Team and Company subscriptions — their absence on Premium does not mean the connection failed. Give the agent instructions , then run the test questions — answer quality depends on the instructions, not just the connection. Publish from Channels to Teams, Web, or M365 Chat. Tenant-admin approval may be required by your environment policies. Team rollout — publish to Teams without per-user sign-in If the agent should run under one organisation account instead — no sign-in prompts for end users in Teams — use maker-provided credentials on a pre-provisioned OAuth client: Step 1 — request an OAuth client The shared connection needs a client ID and secret we issue for your tenant — the same model as the Gemini Enterprise and Azure AI Foundry paths. Contact us to request one, and tell us which Ansvar plan the connection should run on. Step 2 — add the MCP connection with manual OAuth In the MCP onboarding wizard, set the server URL to https://gateway.ansvar.eu/mcp , pick OAuth 2.0 as the authentication type and Manual as its mode, then enter the values we sent: Copy Client ID: Client secret: Authorization URL: https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/auth Token URL template: https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/token Refresh URL: https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/token Scopes: openid profile email offline_access The token and refresh URLs are the same endpoint. offline_access is what keeps the shared connection refreshing itself after the short-lived access token expires. Step 3 — send us the callback URL After you select Create, Copilot Studio shows a callback URL (on a consent.azure-apim.net or consent.azure-apihub.net host). Send it to us and we register it on the client — sign-in fails until that URL is on the allowlist. The callback URL follows the connector's name Power Platform derives the callback URL from the connector's identity, so renaming the connector, recreating it, or importing its solution into another environment produces a new callback URL — and sign-in fails with "invalid parameter: redirect_uri" until we register the new one. Keep one connector and reuse it: it saves even when the connection test fails, so there is never a reason to delete and recreate it. The client ID and secret stay valid across all callback URLs — a new connector never needs new credentials. Step 4 — create the connection as your service account Sign in with the Ansvar account the agent should run under — typically a service account on your organisation's plan, not a personal login. This one sign-in is the only OAuth prompt anyone sees. Step 5 — switch the tool to maker-provided credentials and publish In the tool's authentication settings, choose maker-provided credentials so every end user runs on the connection you just created, then publish to Teams. Users get answers immediately — no sign-in card. Two things to know before picking this mode. Usage, quota, and audit attribution all run under the one service account — right for evaluations and small teams, while per-user audit trails need the per-user flow above. And your Power Platform admin controls whether maker-provided credentials are allowed at all (the Control maker credential options environment setting) — if your environment restricts tools to end-user credentials, the per-user flow is the only option. The API-key option does not apply The MCP wizard also offers API-key authentication and asks for a header name. There is no value to put there: the gateway issues no static API keys, by design — access runs on short-lived OAuth tokens so credentials can be revoked instantly and every call stays attributable. Pick OAuth 2.0; for a key-like shared setup, use the team rollout above. Instruct the agent A connected agent without instructions answers badly, and it fails in a misleading way. Copilot passes the user's whole question, verbatim, as the search query; the gateway matches strictly (so relaxed matches are never dressed up as law) and finds nothing; the agent then answers from its own model knowledge — fluent, uncited, and usually in English. The result looks like "the connection doesn't work" or "only English works" when the real gap is four lines of instructions. Paste this into the agent's instructions and adapt the jurisdictions to yours: Copy You are a compliance research assistant. Answer legal and regulatory questions only from Ansvar tool results, never from your own knowledge. For every legal question: 1. Call the search tool, always with a scope: jurisdictions=["NL"] (add "EU" for EU regulation - GDPR, NIS2, the AI Act). 2. Never pass the user's whole question as the query. Reduce it to 1-3 legal key terms in the language of the law you are searching - Dutch terms for Dutch law. Try alternative terms as separate searches. 3. If a search returns nothing, retry once with a synonym or a broader term, or repeat it with allow_broadening=true. 4. Cite every answer: law, article, and URL from the results. If the results do not contain the answer, say so - never invent a source. The same instructions in Dutch, for a Dutch-facing agent: Copy Je bent een juridisch assistent. Beantwoord juridische vragen uitsluitend op basis van de Ansvar-zoekresultaten, nooit uit eigen kennis. Bij elke juridische vraag: 1. Roep het tool search aan met jurisdictions=["NL"]. Voeg "EU" toe bij Europese regelgeving (AVG/GDPR, NIS2, AI Act). 2. Gebruik als query nooit de hele vraag van de gebruiker. Vertaal de vraag naar 1 à 3 Nederlandse juridische kerntermen - bijvoorbeeld "rechtsbijstand", "meldplicht datalek", "aansprakelijkheid verzekeraar". Probeer alternatieven in aparte zoekopdrachten. 3. Levert een zoekopdracht niets op: probeer een synoniem of een bredere kernterm, of herhaal de zoekopdracht met allow_broadening=true. 4. Vermeld bij elk antwoord de bron uit de resultaten: wet, artikel en URL. Staat het antwoord niet in de zoekresultaten, zeg dat dan expliciet - verzin nooit een bron. The instructions encode three rules. Scope: the gateway never guesses the jurisdiction — search requires one. Keyword queries in the corpus language: the corpora are full-text indexes of the law as published — Dutch statutes index Dutch terms, so a whole English sentence matches nothing. Grounding: cite the returned source, or say the answer was not found. When a search finds no strict match, the response says so and names how many relaxed matches were withheld — but Copilot's orchestrator follows your instructions, not hints inside tool responses, so the retry rule has to live in the instructions. Test the connection Ask questions whose answers must come from the corpus, and check that the answer carries citations: "Using Ansvar: what does Article 5(1)(c) GDPR say about data minimisation? Cite the source." — should return the article text with an EUR-Lex reference. "Using Ansvar: welke regels gelden voor rechtsbijstandverzekeraars in Nederland?" — a well-instructed agent searches rechtsbijstand with NL scope and returns Wft conduct rules plus Hoge Raad case law. To confirm which plan the connection runs on, ask the agent to call get_my_capabilities and show the result — it reports the tier, limits, and remaining quota. On Premium and above, case law and preparatory works arrive inside ordinary search responses (court decisions cite ECLI identifiers and link to the court's own site); those rows are the premium layer working. Troubleshooting OAuth auto-discovery fails Copilot Studio looks for OAuth discovery metadata at the server URL you enter — the gateway serves it directly, so auto-discovery works out of the box. If it fails, the URL is almost always the problem: check you entered https://gateway.ansvar.eu/mcp exactly, with no extra path segments. Token refresh under tenant restrictions Conditional Access policies that block third-party OAuth apps will silently fail token refresh on the connection. If your agent suddenly returns 401 errors mid-session, ask your IdP admin to allowlist auth.ansvar.eu . Tenant-admin OAuth versus user-level OAuth Some tenants disallow per-user OAuth grants for custom connectors. In that case the publish flow surfaces a "requires admin approval" prompt; the admin must complete the OAuth flow themselves to authorise the connector at tenant scope. "Invalid parameter: redirect_uri" at sign-in The connector is sending a callback URL we have not registered. This appears on first setup before the callback exchange (step 3 above), and again whenever the connector is renamed, recreated, or imported into another environment — each of those produces a new callback URL. Copy the exact URL from the connector's Security tab (or from the redirect_uri parameter in the browser's address bar on the error page) and send it to us. Keep the client ID and secret you have — they are not the problem. Searches return nothing, or only one language "works" Almost always missing agent instructions: the agent is passing whole sentences as search queries, and answering from its own knowledge when the corpus returns nothing. Add the instructions above ; the test questions should then return cited answers in both languages. "Premium doesn't seem enabled" Ask the agent to call get_my_capabilities — it reports the tier the connection actually runs on. Two things are commonly misread: document-upload tools and document-grounded workflow types are Team and Company features, so their absence on a Premium connection is expected (the workflow tools themselves are on every tier — what Premium adds is the LINDDUN and TARA families, the rendered exports, and a 5-run monthly allowance); and premium content does not arrive as extra tools — case law and preparatory works appear inside ordinary search results (look for ECLI-cited court decisions). Other clients Claude, ChatGPT, VS Code, Cursor, and the rest of the client recipes are on the Setup page . Verified 2026-07-16 — and moving fast The org-rollout flow was live-tested against the production gateway on 2026-07-14, and the agent-instructions and troubleshooting sections reflect a real enterprise onboarding completed 2026-07-16. Microsoft ships changes to Copilot Studio frequently — if a step no longer matches what you see, tell us and we'll re-verify. Previous Connect Le Chat Next Connect Azure AI Foundry --- ## Connect Azure AI Foundry · Ansvar AI docs URL: https://ansvar.eu/docs/setup/foundry Connect Azure AI Foundry's Agent Service to the Ansvar gateway — OAuth Identity Passthrough with a pre-provisioned OAuth client, per-user sign-in. Connect Azure AI Foundry Azure AI Foundry's Agent Service reaches the gateway as an MCP tool : point it at https://gateway.ansvar.eu/mcp and each user signs in with their Ansvar account. Foundry does not support MCP Dynamic Client Registration, so — unlike Claude or Copilot Studio, which register themselves — the connection uses a pre-provisioned OAuth client . That is the same model as the Gemini Enterprise path: we provision the client for you and send back the values to paste in. Use the new Foundry portal only These steps are for the new portal at ai.azure.com/nextgen . The classic agents experience is deprecated — it retires 2027-03-31 and does not offer the OAuth option this page depends on. The authentication method to pick is OAuth Identity Passthrough → custom OAuth. Step 1 — request an OAuth client The connection needs a client ID and secret we issue for your tenant. Contact us to request a Foundry OAuth client, and tell us which Ansvar plan your users are on. We send back a client ID and client secret for the next steps. Step 2 — add the MCP tool In the new Foundry portal, add the MCP tool to your agent. Set the Server URL to https://gateway.ansvar.eu/mcp , give it a server label of your choice, and set Authentication to OAuth Identity Passthrough (custom OAuth). Step 3 — enter the OAuth values Fill in the custom OAuth fields with the credentials we sent and the gateway's identity-provider URLs: Copy Client ID: Client secret: Auth URL: https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/auth Token URL: https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/token Refresh URL: https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/token Scopes: openid profile email offline_access The Token URL and Refresh URL are the same endpoint. offline_access is what enables automatic token refresh — without it, sessions stop working when the short-lived access token expires. Step 4 — send us your redirect URL After you save the configuration, Foundry generates a Redirect URL . Send it to us and we add it to the client's allowed redirect URIs — the sign-in loop stays broken until that URL is registered on our side. Step 5 — first use and consent The first time each user runs the agent, Foundry returns an oauth_consent_request with a one-time consent link. The user follows it, signs in with their Ansvar account, and from then on the agent calls gateway tools with that user's identity, plan tier, and quotas. Notes and limitations Each user needs their own Ansvar account. Sign-in is per user, and per-user quotas apply. Publishing to Teams or M365 Copilot does not carry user identity today. On that path Foundry sends the project's managed identity instead of the user's token — a Microsoft limitation, with no announced timeline. If you need that path, contact us about a service credential. Foundry's "Microsoft Entra ID" and "Unauthenticated" options do not work with the gateway. Tokens must be issued by Ansvar's identity provider, and unauthenticated requests are rejected. Use OAuth Identity Passthrough with custom OAuth. Foundry defaults MCP tools to require approval on every call ( require_approval ). Adjust this in the tool configuration per your governance needs. Instruct your agent — the routing pack A connected agent without routing instructions can still answer legal questions from its training data — the connector sitting idle at exactly the moment it should prove itself — when a message does not name Ansvar. Put the block below in the agent's instructions field when you create the agent — there you control the system prompt itself. The block is the same set that Instruct your agent explains line by line; adapt the jurisdictions to your market. text Copy You are a compliance research assistant. Answer legal, regulatory, and security-standards questions only from Ansvar tool results, never from your own knowledge. For every legal, regulatory, or standards question: 1. Call the search tool, always with a scope: jurisdictions=["SE"] (adapt to your market; add "EU" for EU regulation - GDPR, NIS2, the AI Act), or frameworks=["GDPR"] for one EU framework across the board. On the Free plan, pass exactly one jurisdiction or framework per call. 2. Never pass the user's whole question as the query. Reduce it to 1-3 legal key terms in the language of the law you are searching - Swedish terms for Swedish law. Try alternative terms as separate searches. If a multi-concept query returns nothing, split it into one search per concept. 3. If a search returns nothing, retry once with a synonym or a broader term, then retry with allow_broadening=true and label any relaxed matches as such. 4. Cite every answer: law, article, and source URL from the results. If the results do not contain the answer, say which searches you ran and that you will not answer from memory - never invent a source. If something breaks "Invalid tool schema." Make sure you are on the latest Foundry portal, then contact support . "Unauthorized." Re-check the client secret, and confirm the Redirect URL you sent us matches the one Foundry generated. Everything else — the general troubleshooting page covers OAuth loops, tier gates, quota caps, and empty results. No user sign-in? Use the headless path For headless or static-header setups that never run a per-user sign-in, use a managed service credential instead. See Clients without OAuth . Verified 2026-07-10 — and moving fast These steps were verified against Microsoft Learn on 2026-07-10, and the OAuth flow end-to-end against the live gateway. Microsoft ships changes to Foundry frequently. If a step no longer matches what you see, tell us and we'll re-verify. Previous Connect Copilot Studio Next Clients without OAuth --- ## Workflows · Ansvar AI docs URL: https://ansvar.eu/docs/guides/workflows The structured compliance workflows — what exists, how the lifecycle works, and which tier unlocks them. Workflows A workflow is a staged assessment the gateway drives through your agent: scripted stages, required fields the agent can't skip, user-review gates, and a final cited report. The concept is covered in Tools vs workflows ; this page is the catalogue and the lifecycle. Free includes 1 run a month and Solo 2, picked from seven types — STRIDE threat model, gap analysis (generic or NIS2, DORA, CRA, EU AI Act) and DPIA — on a system you describe, with the report as a watermarked render or JSON. Premium includes 5 runs a month across the full interview-grounded catalogue; workflows grounded in your own documents — DPIA, gap analysis, tender review — are Team (20 runs per seat a month) and Company (custom allowance). The lifecycle — six tools text Copy list_workflow_types() # what can I run? start_workflow(workflow_type="dpia") # returns workflow_id + first step get_current_step(workflow_id) # what the workflow needs next submit_response(workflow_id, response) # answer; repeat until stages pass get_progress(workflow_id) # where am I? generate_report(workflow_id) # the final deliverable State persists on every submit_response — resume_workflow(workflow_id) picks an active run back up days later, and list_workflows / cancel_workflow manage the set. A completed workflow is immutable; rerun it as a new one when circumstances change. Evidence documents attach via the document library (see Cite your documents ) and bind to a run with register_document . The catalogue list_workflow_types returns the live list of base types with required parameters and jurisdiction variants — the table below is the orientation copy, not the contract. workflow_type What it produces gap_analysis Regulatory gap analysis Control-by-control compliance assessment against a framework (NIS2, GDPR, DORA, ISO 27001), ending in a findings matrix and remediation roadmap. dpia Data Protection Impact Assessment GDPR Article 35, one processing activity: screening, necessity and proportionality, per-risk CNIL-grid analysis, Article 36 determination. fria Fundamental Rights Impact Assessment EU AI Act Article 27, one AI system + deployer pair: high-risk determination, Charter rights mapping, per-risk severity by affected group. threat_model STRIDE threat model Security threat model over a reviewed data-flow diagram — six STRIDE specialists, enrichment from the threat-framework corpora, mitigation map. linddun LINDDUN privacy threat model Privacy threats on a DFD with personal-data tagging, harm-band scoring against EDPB factors, mitigations mapped to PETs and GDPR Art. 25. risk_assessment Enterprise risk assessment ISO 31000/31010 + NIST SP 800-30 anchored: scope-context-criteria, per-risk analysis and treatment, evaluation gate. tender_review Public tender review (bidder-side) Per-lot, per-requirement coverage assessment of a tender against your bid posture. Jurisdiction variants (SE, NL) overlay procurement regimes. tender_audit Public tender audit (buyer-side) Lawfulness review of a tender's requirements: proportionality, non-discrimination, transparency — the buyer-side sibling of tender review. review Document review Free-form review of one uploaded document where every finding carries a paragraph-level, tamper-evident doc:// citation. adversary_tabletop Adversary tabletop exercise Multi-turn, scored crisis simulation from a scenario pack, graded on behavioral and regulatory objectives, ending in an after-action report. sora_operational_authorisation SORA operational authorisation Drone operational-authorisation determination chain following the EASA SORA methodology. Variants Base types take jurisdiction and domain overlays — a variant reuses the base machinery with a regime-specific stage set. Live examples: DPIA variants for Germany and Sweden, tender review/audit for Sweden and the Netherlands, NIS2 gap analyses including the Dutch transposition, plus DORA, CRA and EU AI Act variants, a medical-device family (MDR, IVDR, MDCG 2019-16), the TARA pair — automotive_tara (ISO/SAE 21434 methodology, UNECE R155) and ot_tara (OT/ICS/machinery), both extending risk_assessment and part of the Premium described-system set — and a drone/UAS family (drone DPIA, drone threat model, operator compliance, product security conformity) plus OT/machinery equivalents. Ask your agent for list_workflow_types — variants appear under their base type. Walkthroughs Your first gap analysis — the full tutorial, including the search-driven Premium alternative. DPIA — stages and the report you get back. Threat modeling — the STRIDE workflow, DFD-first. Slash-commands Several workflow families ship MCP Prompts your client surfaces as slash-commands (tender review, threat modeling, gap analysis, FRIA, the tabletop exercise). They drive the same lifecycle tools — use them when you want the workflow's own phrasing for a stage instead of improvising the prompt. Before your first walk: workflows are where client and model choice matter most — see Clients and models for what a workflow demands of your client and which models we have tested. Previous MCP basics Next Your first gap analysis --- ## Cite your documents · Ansvar AI docs URL: https://ansvar.eu/docs/guides/cite-your-documents Upload policies and contracts to your document library and get paragraph-level, hash-anchored citations back. Cite your documents The gateway doesn't only cite law — it cites your documents the same way. Upload a policy, contract, or tender file to your document library and every claim your agent makes about it can carry a paragraph-level anchor: a doc:// URI plus a content hash that proves what the paragraph said when it was cited. That is what makes an assessment reviewable months later, after the document has been through three more revisions. Upload — three calls your agent makes Say "upload this DPIA draft to my library" and the agent runs: text Copy register_document_init(filename, mime_type, file_size) → { document_id, presigned_put_url, expires_at } # the agent PUTs the file bytes to presigned_put_url register_document_finalize(document_id) → { status: "ready", sha256 } Parsing runs at finalize; when the status comes back ready , the document is segmented and citable. list_my_documents shows the library (each document has an id, short code, filename, and status); delete_my_document removes one. The library is tenant-scoped — documents are visible to your organization's seats, not to anyone else. Cite — segments, not whole files Two read tools do the anchoring. get_document_segments returns a document's paragraphs with their segment references. resolve_document_segment goes the other way: give it a doc:// URI and it returns the verbatim text plus the content hash — the round-trip an auditor runs to check a citation. A citation looks like: text Copy doc://3fa2c1d8-.../segment/paragraph/14 "Access to production systems requires a reviewed change ticket." sha256: 9c41... (matches — text unchanged since cited) Whole-document citations lose the tamper-evidence guarantee — if a finding says "the policy covers incident response" with no paragraph anchor, nobody can verify which text carried that claim. Ask your agent to cite at paragraph level; the workflows do it by default. Where this shows up Workflows — evidence documents bind to a run via register_document ; findings then cite your uploaded evidence at paragraph level alongside the regulatory citations. The review workflow is built entirely around this: a structured assessment of one document where every finding must carry a doc:// anchor (see Workflows ). Ad-hoc analysis — "compare our retention policy §4 against GDPR Article 5(1)(e)" works as a plain conversation: the agent pulls your paragraph and the statute, both cited. Want to see the real thing? A full captured run — a retention policy reviewed against GDPR storage limitation, every finding hash-anchored — is at the document-review worked example . Tiers Reading segments ( get_document_segments , resolve_document_segment ) is Premium and above. The library itself — uploading, listing, deleting, and binding documents to workflows — is Team and Company, alongside the document-grounded workflows that consume it. The threat-model runs included on Free, Solo and Premium work from a system you describe in the conversation, not from uploaded documents. What the gateway stores Documents live in your tenant's document store and are served only through your organization's authenticated sessions. MCP servers in the fleet never store client data — the corpus servers answer legal queries and see nothing of your library. Previous Threat modeling Next ISO standards add-on --- ## ISO standards add-on · Ansvar AI docs URL: https://ansvar.eu/docs/guides/iso-standards-addon Use SIS-licensed ISO standards (27001, 27002, 27005, 42001, 21434) through the gateway — buying, querying, and what the add-on does and does not include. ISO standards add-on Under Ansvar's licence agreement with SIS — the Swedish Institute for Standards , your workflows and searches can cite selected clause and control text of ISO/IEC standards directly, instead of paraphrasing from model memory. Five standards are live: ISO/IEC 27001, 27002, 27005, 42001, and ISO/SAE 21434 — any standard SIS publishes can be requested. The add-on is a per-seat subscription on top of any plan — a seat's holder is a named individual or, for organisations, a machine identity set up sales-led by Ansvar (self-serve assignment is not yet live) — (Free included); pick standards on the standards page . Buying and entitlement Purchase is self-serve from /standards — per seat, per standard, monthly, billed alongside your existing subscription. The Standards Add-on Terms apply in addition to the Terms of Service. Entitlement is per account: only standards selected in your subscription are routed to you. Ask your agent to run describe_capabilities — the addons section shows which standards your account can reach. Querying a standard Entitled standards answer through the same search tool as everything else, scoped by source — for example: search(query="risk treatment plan", sources=["sis-27001"]) — clause text from ISO/IEC 27001. Results carry the standard citation envelope: designation and clause, attributed to SIS as the licensed source — cited, not paraphrased. Workflows (gap analysis, threat models) cite the entitled standards the same way they cite legislation. Entitled but empty? A standard you just bought can briefly return no results until its source is routed to your account. If results stay empty beyond a few minutes, contact us — do not assume the standard has no relevant clause. What the add-on is not Not the complete standard — Ansvar serves selected clause and control text relevant to your query, under licence. It is not a substitute for buying the full standard from SIS. Not downloadable, printable, or redistributable — the text is served into your AI client for your own compliance work, and copyright stays with SIS. Not the same thing as your standards library: the list_org_standards / search_org_standards tools query standards documents your organization uploaded ; this add-on serves SIS-licensed ISO text Ansvar provides. The two are separate surfaces. Previous Cite your documents Next Govern AI coding assistants --- ## How to govern Cursor and Copilot in a regulated company · Ansvar AI docs URL: https://ansvar.eu/docs/guides/govern-ai-coding-assistants Five practices for governing Cursor and Copilot in a regulated company — tool inventory, data egress, grounding, audit trail, and EU AI Act/NIS2 touchpoints. How to govern Cursor and Copilot in a regulated company When an AI coding assistant has read access to your source — and sometimes write access to your repository — it is a vendor with a data-processing relationship, not a productivity toggle. In many organizations that access exists before any policy does, because developers can install Cursor or turn on Copilot without asking. Five practice areas cover most of what an auditor will ask about. 1. Build an approved-tool inventory Track which AI coding assistants are in use, per team or repository: the vendor, the plan, who approved it, and what the plan's data handling terms say about training on your code. An inventory with gaps is worse than an honest "we don't know yet" — it tells an auditor the org doesn't have visibility into what's reading its source. Both major vendors ship an admin control worth pointing an auditor to directly, rather than describing secondhand. Cursor's Enterprise plan adds repository, model, and MCP access controls that an org admin sets centrally (verified against cursor.com/pricing, 2026-07-24). GitHub Copilot's organization and enterprise admin console has a "Restrict MCP access to registry servers" policy (public preview on Business and Enterprise plans, verified against docs.github.com, 2026-07-24). Know its limits before treating it as a boundary: GitHub's own documentation says enforcement matches servers by name or ID, applies only on supported IDE and CLI surfaces, and can be bypassed by editing configuration files — a guardrail that signals and records intent, not a technical block. Set the policy, record who set it, and review the list when a vendor changes its connector model — not on a fixed calendar disconnected from what actually changed. 2. Set data-egress and secrets rules Default posture: secrets never leave the IDE toward a model — no exception, because a task that "needs" a live credential in a prompt is a task that needs redesigning. Customer data and third-party material under NDA leave only with explicit authorization: the data's classification allows it, the vendor and plan are approved for that classification, and the contractual and transfer terms cover it — task necessity alone authorizes nothing. Three controls do most of the day-to-day work: secret scanning wired ahead of commits and pushes (it blocks a pasted credential from landing in history — exposure to the assistant has already happened by then, which is why the never-in-prompt rule comes first); workspace-level indexing exclusions so an assistant never reads directories it has no reason to read, not just directories it shouldn't write to; and a recorded answer to "does this plan train on our code," checked against the vendor's current terms rather than assumed from a previous plan or a competitor's default. 3. Require grounding — cited sources over model memory The failure mode here is specific: an assistant answers a compliance or security question fluently, from its own training data, with no signal to the reader that nothing was actually looked up. A policy that requires a verifiable citation narrows that gap — narrows, not closes, because a model can fabricate a citation too. The requirement that works is a fetched source: when an assistant's answer touches a compliance control or a legal requirement, it must cite a source it actually retrieved — a resolvable link or document reference a reviewer can open — not merely name a plausible article number. An answer with no checkable source attached is not evidence of anything, however confident it reads. This is a policy you can lift rather than invent: a short cite-or- refuse instruction in the system prompt is what makes an AI agent reliable for exactly this reason, and Instruct your agent is the worked version — the rule and the paste-ready wording, not just the idea. 4. Keep an audit trail Pull request review is the audit-trail component you already run — make it non-optional for any AI-suggested change that touches a security-sensitive path (authentication, secrets handling, network configuration, access control), and never let an assistant merge its own change. It is one component, not the whole trail: a PR records the accepted diff, not the prompts, the tool identity, the retrieved context, or the suggestions that were rejected — which of those your regime requires you to keep is a question for your control framework, not a default. Where a specific compliance deliverable depends on an assistant's output — a drafted DPIA answer, a threat-model finding — keep the query and the cited source next to the output, not just the output. The underlying law or standard can change between when the answer was drafted and when it's reviewed; the citation is what lets a later reviewer check the answer against the current text, not the text as it stood when the assistant ran. 5. Know your regulatory touchpoints Two EU instruments bear directly on an AI coding assistant, and both are narrower than the headlines about them suggest. The EU AI Act 's Article 50 transparency obligations apply from 2 August 2026 , and that date was not moved by the 2026 Digital Omnibus amendment to the Act. Article 50 is a set of specific duties, not a blanket label-everything rule: most fall on the AI system's provider (machine-readable marking of synthetic content, disclosure when a person interacts with an AI system), and the deployer-side duty for generated text is scoped to publication intended to inform the public, with an exception where the content passed human review under editorial responsibility. Ordinary AI-assisted code or internal drafts are not categorically covered — the point of practice 5 is knowing which of your outputs fall inside those categories, and it is Article 50 you check for that, not the Act's high-risk-system rules, which apply on a later, staggered timeline. NIS2 — Directive (EU) 2022/2555 — reaches an AI coding assistant through its supply-chain requirement (Article 21): an essential or important entity has to manage security risks in its supply chain and its relationships with direct suppliers and service providers. In our assessment a tool with repository access belongs in that analysis — whether it does for your entity, and what measures are proportionate, is an entity-specific determination, not a rule you can read off the directive. The directive's transposition deadline for EU member states was 17 October 2024; transposition status still varies by country, so the obligation your company actually faces is in your own jurisdiction's statute, not the directive text by itself. Not legal advice This page describes practice, not law. Verify current obligations against the text of the instrument in force in your jurisdiction, or your counsel, before treating anything here as a compliance position. If you don't yet know whether NIS2 or the AI Act applies to your company at all, the free NIS2 checker and AI Act checker walk the scope rules in about two minutes, with article citations, no signup. Where the gateway fits None of the five practices above need Ansvar — an approved-tool inventory, an egress policy, and a PR-review rule are yours to run regardless. Where a gateway helps is the grounding practice specifically: connecting Cursor, Copilot, or any MCP-capable assistant to the Ansvar gateway (the same way described in Quickstart ) means a compliance question gets answered against the actual text of EU and national law, cited by article, instead of from the model's memory of what the law probably says. Previous ISO standards add-on Next Tool reference --- ## Tool reference · Ansvar AI docs URL: https://ansvar.eu/docs/reference/tools The gateway's customer tool surface by family and tier — research, evidence, documents, workflows, risk, architecture, and audit. Tool reference The gateway's tool surface is deliberately small per family and deliberately gated per tier: tools outside your tier are absent from tools/list entirely. This page is the orientation map. The contract is what your own session reports — run describe_capabilities for the live list with schemas, quotas, and the sources your tier can reach. Research — the core loop — All tiers (Free +) — exceptions marked per row search — Full-text search across in-scope sources, routed by jurisdiction, framework, sector, or source. Needs at least one scope. On Premium+ it automatically fans out into case law, preparatory works, and agency guidance. get_provision — One article, verbatim, by (jurisdiction, law, article) or canonical_ref — with source URL, publisher, license. validate_citation — Check a citation resolves against the served corpus and get its current text for comparison — a deterministic, non-model check. list_coverage — What's live: by jurisdiction, by domain ("Using Ansvar: which jurisdictions for NIS2?"), or by region. get_changes — Amendment records from corpus change feeds. During the current interim no corpus advertises a feed and the tool is WITHHELD from tools/list entirely (reason: amendment_tracking_unavailable) — do not expect it in your client until a feed serves. For newly published acts, use search_regulatory_updates. search_regulatory_updates — What regulators newly published (EUR-Lex OJ-L, Commission DG CNECT, EDPB) — typed records with original-publisher deep links and CELEX ids. Premium and above. diff — Compare two versions of a tracked provision. batch_search — Several scoped searches in one call — one quota draw per contained search. describe_capabilities / get_my_capabilities — Your tier's live tool list, sources, quotas, and limits. The authoritative answer to "what can I call?" Vulnerability intelligence — All tiers (Free +) search_cve / get_cve_details — CVE search and detail from the live-synced CVE/NVD engine. get_epss_score / check_kev_status / get_exploits — Exploit-prediction score, CISA KEV membership, and known exploits for a CVE. search_by_product — CVEs affecting a product/vendor. get_data_freshness — Per-feed last-sync timestamps for the live data — how fresh the answer is. Served by the CVE intelligence engine (daily-synced NVD, KEV, EPSS feeds), so answers carry sync timestamps rather than a static corpus date. Legal evidence layer — Premium + search_guidance — Agency guidance from regulators, standalone (the guidance slice of the premium fan-out). get_decision — One court decision plus its cross-references — the case-law analog of get_provision. Case law and preparatory works have no standalone search tool — they arrive inside search's automatic premium fan-out. Your documents — Premium + (read) · Team + (library) get_document_segments / resolve_document_segment — Read uploaded documents at paragraph level and round-trip doc:// citations with content hashes (Premium+). list_my_documents / register_document_init / register_document_finalize / delete_my_document — The document library: list, upload (presigned PUT), and delete (Team+). See the Cite your documents guide for the full loop. Your standards — Premium + list_org_standards / get_org_standard_clause / search_org_standards — Query your organization's own uploaded standards and clause library the same way you query law. Different surface from the SIS ISO standards add-on (licensed ISO text served by Ansvar) — see the ISO standards add-on guide under Guides. Workflows — Free + · LINDDUN and TARA Premium + · document plane Team + list_workflow_types / start_workflow / resume_workflow / list_workflows / cancel_workflow — Discover and manage structured workflow runs. Free includes 1 run/month and Solo 2 — seven types (threat model, gap analysis incl. NIS2/DORA/CRA/AI Act, DPIA) on a system you describe, watermarked render or JSON, no overage. Premium includes 5 across the full interview-grounded catalog; Team runs 20/seat/month including document-grounded types. get_current_step / submit_response / get_progress — Drive a run: what's needed next, answer it, track it. generate_report / get_workflow_threats — The final deliverable and (threat workflows) the structured threat list. register_document / unregister_document / list_workflow_evidence / get_review_context — The document plane (Team+): bind uploaded documents to a run as evidence, list the evidence register, read a review gate's context. create_dfd / recommend_subagents — Threat-modeling specialists: validate and render a data-flow diagram; plan parallel sub-analyses for a phase. Effective risk — Team + effective_risk / effective_risk_inline / effective_risk_inline_batch — Context-aware CVSS rescoring of a CVE against your asset configuration — persistent-context or inline, single or batch. simulate_control_investment — Rank hypothetical control investments by how much effective risk each would remove across your scored findings — an analysis, never a served score. list_scoring_contexts / list_scoring_policies — Enumerate the asset contexts and rule sets the scorer can apply. record_review_decision / export_vex — Finalize an exploitability disposition and serialize it as an OpenVEX document. Architecture workspace — Team + arch_overview — Per-kind resource counts, trust zones with exposure, unclassified and uncontrolled asset counts, unmitigated threats, pending proposals, when each kind last changed, bootstrap state, and scoring readiness. The recommended first call. arch_search — Substring search across every resource kind, or the subset you name. Returns kind, id, name, and the matching snippet, cursor-paginated. arch_get — One resource by kind and id: all its fields, its resolved links (relationship name to target ids), and its provenance. arch_list — List one kind, cursor-paginated, with equality filters on that kind's scalar columns. An unknown filter key is rejected, never silently ignored. arch_traverse — Breadth-first walk from a start node across the eleven edge families (data flows, dependencies, zone membership, threat and vulnerability links, control anchors, ADR links, obligation links). Depth capped at 3; direction out, in, or both. arch_coverage — Compliance-obligation rollup: counts by regime and assessment status, the obligations with no ADR or control evidence linked, and your unclassified and uncontrolled asset counts. Scope it to one regime when that's all you need ("Using Ansvar: which NIS2 obligations have no evidence linked?"). arch_dfd — Render a Mermaid data-flow diagram from the stored graph: trust zones as subgraphs, services and data stores as nodes, flows labeled with data kind and transit encryption. Deterministic output, scoped to a zone or a list of services. arch_propose — Propose a create or update of one resource, with the evidence behind it. Unknown fields, bad enum values, and links to ids that don't exist in your org are rejected. Records a proposal; in steady state nothing changes until a reviewer approves. Inside an open bootstrap window it applies under the standing assent, and the response says so. arch_propose_retire — Propose soft-retirement of a resource: service to retired, ADR to deprecated, vulnerability to closed, obligation to non-compliant-accepted. Also a proposal, under the same bootstrap-window exception. arch_list_proposals — List your organization's proposals newest first, filtered by status (pending, applied, rejected, stale), kind, or proposer. A read. arch_get_proposal — One proposal by id with its full diff, the evidence attached to it, and the reviewer's comment. A read. arch_review_proposal — Approve or reject a pending proposal. Org-admin only, and the reviewer is never the proposer. Your comment goes on the record verbatim. arch_bootstrap — Read or control the seeding window. Any Team caller can read the status; start and stop are org-admin only. Inside an open window, one standing assent lets proposals apply on the spot, stamped as bootstrap, until stop closes the window. Your own security-architecture graph, queried by your agent the same way it queries law: services, data stores, flows, trust zones, controls, threats, vulnerabilities, ADRs, and compliance obligations. Seven reads, two propose tools, two proposal reads, and two proposal-workflow tools: arch_review_proposal is org-admin only, as are arch_bootstrap's start and stop, while any Team caller can read the bootstrap status. Resources and proposals are scoped to your organization. A per-organization entitlement gate for the family is being phased in; tier decides access. Audit ledger — Company get_receipt / list_receipts / verify_receipt — Tamper-proof receipts: each query generates a cryptographic record of what was asked, what was returned, and when. export_audit_package / decrypt_receipt — Offline-verifiable audit bundle export; receipts decrypt client-side with your tenant's KMS key. Regulation engines — Team + Five EU-regulation analysis tools are live on Team and Company: check_applicability (does this instrument apply to the situation you describe), compare_requirements (two instruments' requirements side by side), get_evidence_requirements (what evidence an obligation expects), map_controls (obligations mapped to the controls you already run), and get_regulation_guide (a structured orientation guide per instrument). check_conformity (the EU Machinery Regulation conformity engine) is defined but not yet serving — it appears in your tool list when its engine goes live. describe_capabilities is always the authoritative answer for your account. Architecture writes are proposals In steady state, arch_propose and arch_propose_retire never change the graph. Each one records a diff plus the evidence behind it, and an org-admin then approves or rejects it: propose, review, apply. The reviewer's comment goes on the record verbatim, the reviewer is never the proposer, and agent seats cannot review at all. If the live row moved after the proposal was written, the approval fails closed instead of overwriting the newer state. The one exception is a bootstrap window: while an org-admin holds one open, proposals apply on the spot under that standing assent, stamped bootstrap in their provenance — see arch_bootstrap . That is what makes it safe to let an agent write to your architecture: every change carries who proposed it, on what evidence, and who approved it. Errors are structured Calling a tool above your tier returns JSON-RPC -32601 (method not found). Exceeding a quota returns -32000 with data.cause = "cap_exceeded" . See Troubleshooting for the full error map. Previous Govern AI coding assistants Next Troubleshooting --- ## Troubleshooting · Ansvar AI docs URL: https://ansvar.eu/docs/reference/troubleshooting The errors you'll actually meet — OAuth loops, tier gates, quota caps, empty results — and what each one means. Troubleshooting Seven problems cover nearly every support thread. Each section says what you're seeing, what it means, and what to do. If none fits, email team@ansvar.eu with the tool call and the exact error text. The OAuth window never opens Your client is blocking the popup, or your network blocks auth.ansvar.eu . Allow popups for the client, check outbound HTTPS to auth.ansvar.eu , and retry the connect. CLI clients (Claude Code /mcp , Gemini CLI /mcp auth ansvar ) print the URL — open it by hand if the browser doesn't launch. Works for a few minutes, then 401s A pasted access token expired — gateway tokens live minutes by design. Don't paste tokens: connect via the client's OAuth flow (tokens then refresh silently), use the mcp-remote bridge, or a managed service credential for headless setups — see Clients without OAuth . If OAuth itself was working and a long session starts failing, your client may hold a stale token: reconnect (Gemini CLI needs v0.44.0+ for mid-session refresh — see Connect Gemini ). 404 on connect The MCP endpoint is https://gateway.ansvar.eu/mcp — the bare host without /mcp returns 404. Also restart the client after editing config; most MCP clients read it only at launch. "Method not found" (JSON-RPC -32601) The tool exists but not for your tier — tier-gated tools are absent from tools/list and rejected if called anyway. The classic case is a document-plane tool like register_document called on Premium (the document plane is Team+). start_workflow is on every tier, so a refusal there is usually a different shape: a workflow TYPE your plan cannot start (Free and Solo start the seven included types — threat model, gap analysis incl. its NIS2/DORA/CRA/AI-Act variants, and DPIA; the rest of the catalog starts at Premium), or the monthly run allowance already spent — both come back as a refusal naming the reason, not as a missing tool. It's a tier gate, not an outage. Check the tool reference for what each tier includes, or ask your agent to run describe_capabilities . One tool is missing for a different reason: get_changes is withheld from tools/list on every tier during the amendment-tracking interim (no corpus currently advertises a change feed — describe_capabilities reports it as amendment_tracking_unavailable ). That is a served-state gap, not a tier gate: no upgrade brings it back. For newly published acts, use search_regulatory_updates (Premium and above); to check a citation is still current, use validate_citation (every tier). "cap_exceeded" (JSON-RPC -32000) A daily quota or concurrency cap. The error is structured — your agent can read it: json Copy { "code": -32000, "data": { "cause": "cap_exceeded", "...": "..." } } Daily search quotas: Free 100/day; Solo 750/day; Premium 5,000 per seat/day; Team 50,000 and Company 500,000 pooled per organization. Quotas reset daily; per-minute rate limits are separate and much higher. Run get_my_capabilities for your account's live numbers. Zero results — but no error The gateway fails closed: real failures come back as errors, so a clean empty result means no strict match for those terms. Four usual causes: No scope. search requires at least one of jurisdictions , frameworks , sectors , or sources . Relaxed matches withheld. By default the gateway withholds broadened matches and tells you how many it held back. Retry with a synonym, then with allow_broadening=true — returned rows are stamped match_mode: "broadened" , so label them as relaxed matches. The full recovery ladder is in Instruct your agent . Compound query. Full-text search matches ALL terms — "incident reporting deadline financial entities DORA" easily matches nothing. Decompose into shorter queries ("incident reporting", scoped to the DORA framework) and combine results. Out of coverage. Check list_coverage(jurisdiction) — a well-behaved agent reports "queried, zero results, not in coverage" rather than answering from memory. "All resolved MCP endpoints failed" A downstream corpus was unreachable and the gateway refused to pretend otherwise (accuracy over availability — you get an error, never a silently thinner answer). It's usually transient; retry once. If it persists for a specific jurisdiction, report it — that error names a real outage, not a client problem. One diagnostic to rule them out Ask your agent: "Run describe_capabilities and tell me which tools and sources this account can reach." Tier confusion, expired sessions, and scope mistakes all show up in that one call. Previous Tool reference Next Manage your organization --- ## Manage your organization · Ansvar AI docs URL: https://ansvar.eu/docs/reference/org-admin Seats, roles, billing, and the Company-tier audit ledger — what org admins can do from the account page. Manage your organization Team and Company subscriptions are organizations with seats. Org admins manage everything from the account page at app.ansvar.eu/account — no support ticket needed for the day-to-day. Seats and roles The Organization section lists members and pending invites, above a seat line that counts people and service credentials together — both take seats. Admins can: Invite a member by email — they get a seat and an activation email. If every seat is in use, the invite is refused with seat limit exceeded : raise the seat count under Manage subscription first. Change roles — member or admin. A member must have accepted their invite before their role can change. Revoke a seat — removing a member frees the seat immediately. You can't revoke your own seat; another admin has to. Every seat inherits the organization's tier — there is no per-seat tier mixing. Team and Company search quotas are pooled across the organization, not per seat. Standard seats Licensed ISO standards are sold as seats. Your organization buys a number of seats of a standard, and an admin assigns each one — under Standards & documents — to a person or to a service credential . A credential holding a standard seat is an agent that can cite that standard. One seat, one holder. There is no organization-wide conferral: a standard reaches exactly the people and credentials you assign it to. A standard seat is not an organization seat. The two are counted and bought separately, and a standard seat does not consume one of your member seats. Release returns the seat to the pool to assign again. Revoking a credential releases any standard seat it held, so a paid seat is never stranded on a dead identity. If your seat count drops below what is assigned — you reduced the subscription, say — the excess seats are suspended rather than deleted. They are shown as suspended and are not served; release one to bring the rest back into use. Seats of a standard are the same price whoever holds them. Volume discounts are available on request — talk to us if you need seats in bulk. Subscription and billing The Plan & billing section shows the plan, billing cycle, renewal date, and invoices — the subscription rows are read live from Stripe. Seat-count and plan changes go through Manage subscription. EU VAT IDs are validated on entry and reverse-charge is applied where it applies. Company details (legal name, billing country, VAT ID) sit at the bottom of the same section. Account security The Account & security section covers profile details, password reset, two-factor authentication, email verification, active sessions, and connected agents. Sign-in supports username + password, Microsoft Entra ID, and Google — sessions and OAuth clients authenticate against auth.ansvar.eu . Audit exports and the audit ledger The audit ledger (Company tier) is the tamper-evident record of gateway usage: every query generates a cryptographic receipt of what was asked, what was returned, and when. There are two ways to it, and neither is a browsable log — the account area exports bundles, it does not display a feed: From the account area. The Audit exports section (Company tier) downloads a signed, tamper-evident bundle for a date range. An org admin gets the organization-wide bundle; a member of that organization gets their own receipts. Team and lower have no audit section — the entry is padlocked and names Company as the plan that opens it. From your agent. get_receipt / list_receipts / verify_receipt read the ledger, and export_audit_package produces the same offline-verifiable bundle. Receipts are encrypted; they decrypt client-side with your tenant's key ( decrypt_receipt ) — Ansvar can't read them for you. Team vs Company Team and Company share the same tool surface for research, documents, and workflows; Company adds the audit ledger and an org-scale quota pool. If your regulator or customer contracts require provable query records, that's the Company feature. See pricing . Previous Troubleshooting --- ## How it works — one connection to the regulatory estate · Ansvar AI URL: https://ansvar.eu/how-it-works The gateway authenticates your AI client once over MCP, routes each question to the right sources, and returns answers with deterministic citations attached. the gateway How the MCP gateway connects your AI client to cited law and security sources. Keep the AI client your team already trusts. The gateway authenticates it once over MCP (Model Context Protocol), routes each question to the right sources, fans out in parallel, and returns answers with citations attached. The gateway is a router, not a chatbot. Start free Read the docs gateway.ansvar.eu · single MCP endpoint · Free, Solo, Premium and Team are available 224 Servers behind one endpoint 57 law · 92 sector · 75 domain 49 Audited jurisdictions live 5.8M Provisions in the live tier 7.8M tracked across the pipeline the request journey One question, start to finish. No new chatbot, no portal. The client your team already uses sends a question; the gateway does the routing and hands back a cited answer. 1 Connect your AI client OAuth once · over MCP 2 Ask in context your client sends the question 3 The gateway routes and fans out law · sector · frameworks · threat intel — in parallel 4 A cited answer comes back anchored to the source, or the gap is marked reliability Three layers against silent failure. A compliance answer built on a failed lookup is worse than no answer. Every downstream response passes three checks before it reaches your client. Currency is checked the same way: every corpus reports its content freshness, the fleet is monitored daily, and list_coverage / get_data_freshness expose each corpus's live coverage and freshness — machine-readably, from your own client. layer 1 · no-match classifier Empty is an answer An authoritative “no provisions match” is not the same as a server failing to respond. The classifier separates the two, so silence is never dressed up as a result. layer 2 · error rejection Errors cannot pose as results Downstream errors disguised as well-formed payloads are detected and rejected. A failed call comes back as a failed call — visibly, in the response. layer 3 · envelope reclassification Hollow envelopes get reclassified A response with the right shape and no content is reclassified instead of passed through. The shape of an answer is not evidence of one. refusal discipline · gateway contract 4 claims checked 24-hour early warning for significant incidents NIS2 Art. 23(4) Classification of major ICT-related incidents DORA Art. 18(1) Valid-account technique in scope for the incident-response threat model MITRE ATT&CK T1078 Sector-specific notification window under national transposition marked unresolved illustrative response — an unverifiable claim is marked unresolved, never papered over. we do not answer without sources. refusal discipline What a quota refusal looks like. We never degrade silently. An over-quota call returns a machine-readable refusal that names your tier, your usage, and your reset time — not a thinner answer. even the refusal is auditable Structured, attributable, reproducible The gateway refuses the same way it answers, so a refusal files in the same record as the answers around it. No partial results, no silent downgrade to a smaller source set — the same envelope on every tier. search call 101 of 100 tier: free cause cap_exceeded limit · received 100 · 100 reset 2026-06-12 00:00 UTC upgrade ansvar.eu/pricing no partial answer returned · refusal logged like any other call field names match the gateway's refusal contract (ADR-028 §4) — values illustrative the surface A small set of tools your agent already knows how to call. MCP is the interface. Your client discovers the tools at connect time; the gateway scopes the listing to your tier. Tool What it does search Full-text search across in-scope sources, routed by jurisdiction and sector. Every hit carries its citation. get_provision One provision, verbatim, at article level — with source URL, publisher, and license. list_coverage What is live right now: jurisdictions, sources, and counts, machine-readable. validate_citation Round-trips a citation against the source corpus before you rely on it — a deterministic, non-model check: article numbers resolve, anchors exist, the URL returns the cited text. search_regulatory_updates What regulators newly published (EUR-Lex OJ-L, Commission, EDPB) — typed records with original-publisher deep links, for monitoring what's new. Premium and above. describe_capabilities The caller's own view: tools, sources, and limits for the authenticated tier. search_guidance Agency guidance from regulators, alongside the statute — part of the legal evidence layer, Premium and above. core tools — excerpt; capability listing via describe_capabilities new to the protocol? MCP basics in the docs the citation contract Same shape for every source, public or private. Whether a claim is backed by a published EU regulation or a standard you uploaded this morning, the citation object looks the same. Downstream tooling does not need to branch. Validation is deterministic — the same question returns the same sources every time. The upload-to-citation loop — presigned upload, paragraph anchors, content hashes — is documented in Cite your documents . Field What it carries source_url Canonical link to the exact provision — the ELI or permalink, anchored to #article / #paragraph. Required on every served item. publisher Who published the source — EUR-Lex, nvd.nist.gov, the deciding court, or your own internal document owner. license The source's licence, as a code from Ansvar's licence catalogue. A row whose attribution can't be resolved is refused, not shown with a blank field. jurisdiction EU, SE, DE, FR, GB, international — or internal for a document you uploaded. article The provision anchor: Regulation (EU) 2022/2554 Art. 28(2)(a) · ISO/IEC 27001:2022 §A.5.19 · your Vendor Policy v3.1 §6.3. effective_date When the cited text took effect, where the source carries it. Null stays null for instruments not yet in application — an honest omission, never a guess. private documents share the same citation contract — cited at paragraph level, and they never leave your tenant · private evidence is a Team and Company capability Connect the client you already run. Free is 100 searches a day with a B2B sign-up. Solo adds full-fleet fan-out; Premium adds the legal evidence layer. The first cited answer takes minutes, not a procurement cycle. Start free Read the docs --- ## Solutions by sector · Ansvar AI URL: https://ansvar.eu/solutions Pick your sector and see its lead workflow, every line cited to the law: threat modeling, AI Act readiness, DPIA, gap analysis, tender review. choose your sector 13 sectors. One cited answer each. Your sector picks the law we ground on — the corpora your questions fan out across, and the workflows that run on top. 01 Security → 02 AI governance → 03 Privacy → 04 Public sector → 05 Financial → 06 Automotive → 07 Drone / UAS → 08 Agri & machinery → 09 Healthcare → 10 Industrial / OT → 11 Robotics → 12 Rail → 13 Energy → 01 For security & AppSec teams Find what an attacker reaches before they do . STRIDE threat model an example of what comes back — every line cited Spoofing — token replay across the service boundary ✓ OWASP ASVS 4.0.3 §3.5 Tampering — unsigned inter-service calls ✓ MITRE ATT&CK T1557 Mitigation owed for the product ✓ CRA (EU) 2024/2847 Annex I ATT&CK OWASP CRA Explore the security sector → Every tier runs these as cited research in your AI client, and starts STRIDE threat models on a system you describe — 1 run a month on Free, 2 on Solo · Premium raises that to 5 and adds LINDDUN, TARA and the rendered reports · Team & Company run them on your own documents — the signed audit ledger ships on Company. --- ## Canonical control library — one control set, sourced framework mappings · Ansvar AI URL: https://ansvar.eu/control-library One NIST 800-53r5 control spine behind ISO 27001, CSF 2.0 and 800-171 — sourced mappings with provenance, and external coverage claimed only once reviewed. Capability · Control library Implement a control once. Answer each framework from that one set. Ansvar's control library uses NIST SP 800-53 Rev 5 as a canonical spine — a public-domain US government control set, organised under the CSF 2.0 functions. Framework requirements attach to it as sourced links carrying their provenance, and a link becomes a coverage claim only once its relationship has been reviewed and approved. You implement and evidence a control once; each framework becomes a question asked of that same set. That is the direction, built framework by framework — not a claim that every catalogue is mapped today. See a real crosswalk Compare plans the problem A framework tag can only ever say “related” A flat framework tag says only that a control touches a framework. That label throws away the two things an assessor needs from a mapping. It cannot say how much. A flat tag asserts relatedness and nothing more. It cannot tell you whether the control is equivalent to the requirement, a strict subset that leaves a residual gap, a superset with margin, or a partial overlap. Coverage analysis, gap reports and audit defensibility all rest on exactly that distinction. It cannot be checked. A tag asserts a mapping but carries no way to verify it. Checking that a control satisfies a requirement means reading the requirement — and copying licensed text into a product to make that possible is both a licensing problem and a drift hazard, because the copy goes stale against its source. the mapping model Five relationships, read control-to-requirement Each edge records one of five relationships. Four carry a coverage consequence; related-to records an informative link and claims nothing. Relationship What it means What it counts as equivalent Control scope and requirement demand are the same Covered superset-of The control does more than the requirement asks Covered, with margin subset-of The control does less than the requirement demands Partial — a residual gap is recorded intersects-with Scopes overlap partially in both directions Partial — a residual gap is recorded related-to An informative link between the two Nothing — navigation only Every edge also carries its rationale, confidence, provenance and review state. Where a control falls short, the residual gap is written down and becomes visible work rather than hiding behind a green tag. the shape One control, any framework that asks Nothing in the model is specific to the four below. A framework joins by registering its requirements and mapping them onto the spine — adding one is a mapping exercise, not a second control set to implement. Here is what IR-4 reaches today, with the relationship recorded on each edge. canonical control IR-4 — Incident Handling NIST SP 800-53 Rev 5 · implemented and evidenced once, whoever is asking equivalent NIST SP 800-53 Rev 5 IR-4 The spine itself — an identity mapping. related-to ISO/IEC 27001:2022 A.5.25 · A.5.26 · A.5.27 From the NIST mapping workbook, sheet row recorded. related-to NIST CSF 2.0 24 subcategories Detection, response, recovery and improvement. related-to NIST SP 800-171 r3 03.06.01 Publisher traceability back to the spine. no mapping authored NIS2 · DORA · Cyber Resilience Act Already registered as resolvable, citable requirements — the same door every framework comes through. No mapping has been authored to the spine yet, so the library returns nothing for these rather than a link it cannot defend. Frameworks move from this row to the one above as mappings are authored and reviewed. A live read of IR-4 through the gateway on 4 August 2026. Every edge here is related-to except the identity mapping: authoritative for relatedness, and navigable, but not yet a coverage claim. That is the distinction the table above exists to keep. licensing We store the pointer; the text comes from its source A mapping is a claim. Turning it into evidence means fetching the requirement itself, at the moment you ask, under the entitlements you hold. A requirement record in the library is an identifier, a short factual title where licensing permits one, and a citation descriptor that says how to resolve it. There is no licensed clause text in the library, and none is paraphrased. For ISO/IEC 27001 and 27002, BSI C5:2020 and the French RGS, records carry identifiers and pointers only — and for ISO, not even titles as a set. BSI C5:2026, published under a licence that permits verbatim reuse with attribution, may also carry short factual titles. When your agent needs the words, the library hands back the citation descriptor and the gateway resolves the requirement from the corpus that grounds it, checking your entitlement first. Standards you have licensed through the ISO standards add-on resolve as clause text; regulations resolve from the served law corpora with their own citation and licence. The mapping layer never becomes a stale second copy of somebody else's standard. honest coverage Coverage grows as fast as review, and no faster Our covered counts are low today, and the reason is the same one that makes them quotable. The NIST-published crosswalks we ingest are untyped. NIST's CSF 2.0 to 800-53 mapping carries no set-theory field; the 800-53 to ISO 27001 workbook puts that vocabulary on a legend sheet and types none of its rows; the 800-171 traceability is plain back-matter. They enter the library as related-to — authoritative for relatedness, claiming nothing about coverage. Typing an edge is judgement work done by a qualified person, and an agent may propose a typing but never approve its own. Ingested links therefore add nothing to covered counts until someone reviews and types them, and proposed typings never count. Outside the generated 800-53 identity map, a covered count means an approved set-theory mapping stands behind it. Where that leaves us today. Outside the generated 800-53 identity map, external coverage is zero. ISO 27001, CSF 2.0 and 800-171 are connected through the spine by approved related-to links you can navigate and cite — that is the crosswalk in the worked example below. NIS2, DORA and the Cyber Resilience Act are registered as resolvable, citable requirements, but no mappings have been authored for them yet: the library serves none and claims none. Ask it for one of those crosswalks today and it returns nothing, rather than a confident answer it cannot defend. proof A real run, not a diagram A captured production session: one ISO 27001 control walked through the spine and out into CSF 2.0, with the provenance of every hop. Read the captured run — ISO/IEC 27001:2022 Annex A.5.26 lands on IR-4 in the spine, then on 24 CSF 2.0 subcategories spanning detection, response, recovery and improvement, each edge traced to the NIST mapping row it came from, and each path returned as a navigation link rather than a coverage claim. Or connect your own client and ask it directly: Using Ansvar, crosswalk ISO 27001 Annex A.5.26 to NIST CSF 2.0 through the canonical control spine and show the provenance of each hop. Using Ansvar, show me the canonical control behind incident handling and everything it maps to, with the relationship type on each edge. FAQ Questions teams ask first If your question is not here, email us — every message gets a human answer. What is a canonical control? One control in a single set that your organisation implements and evidences once, independent of the framework asking about it. Ansvar's spine is NIST SP 800-53 Rev 5, a public-domain US government control set, organised under the CSF 2.0 functions, with a defined path for Ansvar-authored extensions where a requirement falls outside it. Frameworks then attach to that set as mappings rather than as separate control lists, so evidence you attach to a control is reused everywhere it maps instead of being rebuilt per audit. Do you store the ISO 27001 or BSI C5 clause text? No — identifiers, a resolvable citation, and short factual titles only where the licence permits them. When your agent needs the words, the gateway resolves them from the licensed source under your own entitlements, so what you read is never a stale copy. The section above sets out which frameworks allow titles and which do not. Why does a framework show zero covered controls? Because no one has typed those mappings yet, and Ansvar does not count untyped ones. The NIST-published crosswalks we ingest carry no set-theory relationship, so they enter as links that claim nothing until a person reviews and types them. Outside the generated 800-53 identity map, a covered count needs that review — the section above shows where it stands today. Which plan includes the control library? Team and Company. For authenticated Team and Company workspaces, the seven control-library tools appear in your connected AI client alongside the law and standards corpora. Anyone can read the worked example linked from this page without signing in. Put it in front of your own controls The control library is available on Team and Company plans, through the AI client your team already uses. Compare plans All workflows & services --- ## Workflows — run them yourself, or have us run them · Ansvar AI URL: https://ansvar.eu/workflows Structured compliance workflows — threat models, TARA, gap analyses, DPIA — run in your own AI client, or delivered as an expert-run service. Workflows Run them yourself, or have us run them Every Ansvar workflow is a server-enforced process with cited output — a threat model, a TARA, a gap analysis, a DPIA. Your team runs it in the AI client you already use. Or we run it for you and review the result as practitioners. Start free Talk to us 42 workflow types served through the gateway Cited every anchor fetched from a served source, or marked unresolved Your client Claude, Copilot, any MCP client — nothing to install run it in your own client Workflow families Workflow family Regulatory gap analysis Where you stand against a regulation, requirement by requirement — every finding cited to the provision it rests on, or marked unresolved. Workflow family TARA — Threat Analysis & Risk Assessment Risk assessment for vehicles, OT, rail, robots and drones — risks banded on NIST 800-30 scales, every regulatory anchor fetched and cited, or marked unresolved. Workflow family DPIA — Data Protection Impact Assessment One processing activity, screened against Article 35 and carried through to a prior-consultation decision — each risk scored for severity and likelihood before any safeguard is credited. Workflow family STRIDE threat model Threats enumerated per component against a data-flow diagram you confirm, scored on impact and likelihood, then mapped to the controls and regimes that bear on them. Workflow family Public tender review & audit Two sides of the same tender: whether a bid covers what the tender demands, and whether the tender's own requirements are lawful. Workflow family Vulnerability assessment & deferral A decision layer over a scan you already ran: findings rescored against your context, a ranked investment plan, and a deferral you can defend. Catalog The full served catalog The families above cover most of it. The rest — LINDDUN privacy threat models, FRIA, SORA operational authorisation, document review and adversary tabletops — has no page of its own yet. Ask your own client for list_workflow_types for the authoritative live list. always-on intelligence Capabilities your agent uses between runs Capability Canonical control library One NIST 800-53 spine behind ISO 27001, CSF 2.0 and more — crosswalks with provenance on every edge, and licensed text resolved from its source rather than copied. Capability CVE intelligence & effective risk Live CVE, CISA KEV and EPSS context, rescored against your controls — read the sample deferral dossier it produces. Capability Regulatory intelligence An official-publication monitor over EU and national gazettes — what changed, where, with the source. Tool reference in the docs. have us run it Expert-run services Service AI Act Readiness Assessment Classify your AI systems against the EU AI Act, then know exactly which obligations apply before they bite. Service Threat Model as a Service A structured threat model for your system, built on STRIDE and LINDDUN and your real architecture — typically delivered in 1–2 weeks at a fixed price. Service DPIA as a Service A Data Protection Impact Assessment, done for you and defensible to your regulator. Service Compliance Gap Analysis Where you stand against NIS2, DORA, ISO 27001, GDPR, and the EU AI Act — as a cited report, scoped at article and control level. Same workflows, run and reviewed by us — scoped per engagement. The services page has deliverables, process and samples; contact us to scope one. --- ## Gap analysis workflows — NIS2, DORA, CRA, EU AI Act and more · Ansvar AI URL: https://ansvar.eu/workflows/gap-analysis Assess compliance against NIS2, DORA, the CRA or the EU AI Act requirement by requirement, each finding cited or marked unresolved. A run a month is free. Workflow · Gap analysis Regulatory gap analysis Where you stand against a regulation, requirement by requirement — every finding cited to the provision it rests on, or marked unresolved. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it and your agent runs the workflow; the server enforces the stages and fetches every citation. Start free Compare plans NIS2 Article 21 — modeled extract modeled example Supply-chain security addressed in supplier contracts ✓ NIS2 Art. 21(2)(d) Incident handling documented; post-incident review evidence missing ✓ NIS2 Art. 21(2)(b) Requirement not grounded in a served source — marked unresolved ✓ no citation available What a run produces: Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. NIS2 · DORA · CRA and the AI Act, medical devices, machinery, drones Article-level every finding cited to its provision, or marked unresolved Free one run a month, on four of the regimes Name a framework and the run works through it. Each requirement gets a verdict: what the provision demands, what you have, what is missing. The gateway fetches each requirement as the run goes, so a finding carries the citation it came from — and where no served source grounds it, the run marks it unresolved instead of filling it in. One family covers the regimes: NIS2 and its Dutch transposition, DORA, the Cyber Resilience Act, the EU AI Act, the medical-device pair with its cybersecurity guidance, UNECE R155, the Machinery Regulation, and the two drone regimes. the family One assessment spine, a variant per regime Regulatory Gap Analysis The base: pick a supported framework and assess its configured requirement set. NIS2 (Directive (EU) 2022/2555 Art. 21) The Article 21(2) cybersecurity risk-management measures. NIS2 Netherlands (Cyberbeveiligingswet, Stb. 2026, 187) The Dutch transposition (Stb. 2026, 187); commencement 15 August 2026. DORA (Regulation (EU) 2022/2554) ICT risk-management duties for financial entities. Cyber Resilience Act (Regulation (EU) 2024/2847) Product-security obligations for products with digital elements. EU AI Act (Regulation (EU) 2024/1689) high-risk provider conformity Medical Device Regulation (Regulation (EU) 2017/745) In Vitro Diagnostic Regulation (Regulation (EU) 2017/746) Medical Device Cybersecurity (MDCG 2019-16 rev.1) Non-binding guidance, assessed as written. UNECE R155 Cyber Security Management System (CSMS) CSMS and vehicle-type cybersecurity requirements. Machinery Regulation Gap Analysis — EHSRs (EU) 2023/1230 Annex III essential health and safety requirements, plus placing-on-market duties. Drone Operator Compliance — UAS Operations (Reg (EU) 2019/947) Drone Product Security Conformity — UAS Products (Reg (EU) 2019/945 + CRA + RED) Product security, where three regimes overlap. Where a framework leans on a standard, the run cites the requirement and maps to controls; standard text itself arrives only if you license it through the ISO standards add-on. how a run works What the server enforces 1 Scope the regime and the system or documents the assessment runs against 2 Required fields on a gated step the run will not advance on a half-answered requirement 3 Verdict per requirement with the provision fetched and cited where a served source grounds it 4 Unresolved findings a requirement with no served source is marked, never invented 5 Report coverage plus the finding register — structured for your agent, rendered for your auditor ask your agent Paste one of these to start Using Ansvar, run a NIS2 gap analysis for our logistics platform against Article 21 and cite every finding to its provision. Using Ansvar, which gap-analysis workflow types can I start, and what does each one assess? Free gets one workflow run a month and Solo two, spendable on the generic gap analysis or its NIS2, DORA, CRA and EU AI Act variants, against a system you describe, and a Free or Solo run can also return a render carrying a self-asserted banner. Premium adds the rest of the family — the Dutch NIS2, medical-device, R155, machinery and drone variants — on five runs a month. Team and Company run them against your own uploaded documents and add unwatermarked HTML, PDF and DOCX exports. Run allowances and what each tier adds live on the pricing page . Questions buyers ask first Which plan do I need to run one? Any of them, for part of the family. Free gets one workflow run a month and Solo two, spendable on the generic gap analysis or its NIS2, DORA, CRA and EU AI Act variants, against a system you describe. The Dutch NIS2, medical-device, R155, machinery and drone variants start at Premium. Team and Company add runs grounded in documents you upload. The pricing page carries the allowances. Do I have to upload our policies? No. On Free, Solo and Premium, the run interviews you about the system and assesses what you describe. Uploading your policies is what Team adds: findings then anchor to the exact paragraph they came from, with a content hash, so a reviewer can check the verdict against your own document. What comes out at the end? Gap findings across the configured requirement set, each cited to its provision or marked unresolved, plus the share of those requirements assessed. Every plan returns the complete report as structured data, which is what your agent reads. Rendered documents are the hand-off: Team and Company export unwatermarked HTML, PDF and DOCX, and a Free or Solo run can also return a render carrying a self-asserted banner. Is this a compliance certificate? No. A gap analysis is decision-support: a cited register of where you stand, which feeds an audit, a board paper or a remediation plan. Ansvar issues no certificate and makes no conformity declaration. What happens when a requirement has no source we serve? The run marks it unresolved rather than answering from model memory. A gap analysis you hand to an auditor has to be honest about what it could not ground. as a service Prefer we run it? Every workflow here is also an expert-run service: we run it against your systems, review the output as practitioners, and hand over the finished deliverable. See the services page for how engagements work, or contact us to scope one. Related: Sample NIS2 gap analysis · Worked run, policy attached · Worked run, no upload · Free NIS2 template · NIS2 scope checker · NIS2 explained · DORA explained · CRA explained · Your first gap analysis · Have us run it Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide --- ## TARA workflows — automotive, OT, rail, robotics & UAS risk assessment · Ansvar AI URL: https://ansvar.eu/workflows/tara Run ISO/SAE 21434, IEC 62443 and UN R155-anchored TARAs from your own AI client — server-enforced stages, ISO 31000 risk bands, every citation fetched. Workflow · TARA TARA — Threat Analysis & Risk Assessment Risk assessment for vehicles, OT, rail, robots and drones — risks banded on NIST 800-30 scales, every regulatory anchor fetched and cited, or marked unresolved. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it and your agent runs the workflow; the server enforces the stages and fetches every citation. Start free Compare plans Automotive TARA — modeled extract modeled example Threat scenarios per asset, likelihood banded ✓ ISO/SAE 21434 §15.4 CSMS evidence trail toward type approval ✓ UN R155 §7.2 Risk scores on defined consequence bands ✓ NIST SP 800-30 Rev 1 App. G What a run produces: A risk register aligned to ISO 31000/31010/NIST 800-30G: risks with likelihood/consequence bands, scores against thresholds, and treatments. Automotive · OT · rail plus robotics and drones, on one risk spine ISO 31000 process; 31010 techniques; NIST 800-30 scales 21434 · 62443 · R155 anchors fetched and cited, or marked unresolved A TARA in Ansvar runs as a staged workflow: the gateway holds each stage open until it is answered. You scope the system, confirm the risk list, analyse and treat each risk, and pass an evaluation gate before the report exists. Your own AI client does the interviewing over MCP; the gateway fetches every standard clause map and legal anchor it cites. The sector variants share one enterprise risk spine, so an automotive TARA and a rail TARA score risks on the same defined bands. the family One risk spine, a variant per sector Enterprise Risk Assessment (ISO 31000 / 31010 / NIST 800-30G) The spine: ISO 31000 process, ISO 31010 techniques, NIST 800-30 scales. Automotive TARA — ISO/SAE 21434 & UNECE R155 Threat Analysis & Risk Assessment Vehicle systems and ECUs, with UN R155 CSMS evidence in scope. OT / ICS / Machinery TARA — Threat Analysis & Risk Assessment Plant and machinery on IEC 62443 zones and conduits. Rail / Railway TARA — Threat Analysis & Risk Assessment (CLC/TS 50701, IEC 62443) Rail systems per CLC/TS 50701 practice. Robotics / Cobot TARA — Threat Analysis & Risk Assessment for industrial and collaborative robots Industrial and collaborative robots. UAS Threat Analysis & Risk Assessment (TARA) Drone platforms and their C2 links. Counter-UAS & Hostile-Takeover Resilience Assessment Counter-UAS and hostile-takeover resilience. ICS Advisory-to-Risk — current advisory exposure for an OT asset inventory Turns current ICS advisories into scored exposure for your OT inventory. Standards ground the workflow as clause maps and cross-references — not the standard text, unless you license it. Buyers who hold SS-ISO/SAE 21434 through the SIS add-on get the clause text cited inside the run. how a run works Five stages the server enforces 1 Scope, context, criteria asset, event or objective mode; you set the bands and thresholds 2 Risk identification the workflow proposes, you confirm the list — nothing scores unseen 3 Per-risk analysis & treatment likelihood and consequence banded, treatment recorded per risk 4 Evaluation & compliance gate scores meet your thresholds or the gate says why not 5 Report the risk register — structured for your agent, rendered for your auditor ask your agent Paste one of these to start Using Ansvar, start an automotive TARA for our telematics ECU. Scope it to ISO/SAE 21434 with UN R155 CSMS evidence in mind. Using Ansvar, run an OT TARA for the packaging line PLCs — IEC 62443 zones and conduits, event mode. Using Ansvar: which TARA and risk-assessment workflow types can my tier start? List them with what each produces. The TARA family runs on Premium and above — run allowances and what each tier adds live on the pricing page . Questions buyers ask first Is this a certified ISO/SAE 21434 or UN R155 assessment? No. A TARA run is decision-support: a cited risk register you take into type approval, an audit, or an internal review. Ansvar never issues the approval and never claims certification. How is a TARA different from a STRIDE threat model? STRIDE enumerates threats per component; a TARA produces a risk register — each risk banded for likelihood and consequence, scored against thresholds you set, with a recorded treatment. Ansvar runs both; teams often run STRIDE first and feed the threats into the TARA. What does a run actually produce? A risk register aligned to ISO 31000/31010 and NIST 800-30: risks with likelihood and consequence bands, scores against your thresholds, and treatments. The complete register comes back as structured data, which is what your agent reads. Rendered documents are the hand-off: Team and Company export it as HTML, PDF or DOCX. Do I need to upload documents to run one? No. The TARA family is interview-grounded: your agent asks, you answer, the server enforces what a complete answer looks like. Document-grounded evidence workflows (paragraph-cited review of your own TARA reports and CSMS packs) run on Team and above. Which AI clients can run it? Claude runs the full TARA interview loop today. Any OAuth-capable MCP client can connect to the gateway, but a long staged workflow asks more of a client than research does — the clients guide in our docs lists what each one handles. A run persists across sessions until you finish it. as a service Prefer we run it? Every workflow here is also an expert-run service: we run it against your systems, review the output as practitioners, and hand over the finished deliverable. See the services page for how engagements work, or contact us to scope one. Related: Clients & models guide · Automotive sector · Industrial & OT sector · Rail sector · Robotics sector · Drone & UAS sector · ISO standards add-on (SIS) · Workflow docs Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide --- ## DPIA workflows — GDPR Article 35 for Germany, Sweden and drone capture · Ansvar AI URL: https://ansvar.eu/workflows/dpia Run a GDPR Article 35 DPIA from your own AI client: screening, CNIL-scaled risks, an Article 36 call. One run a month is free. Workflow · DPIA DPIA — Data Protection Impact Assessment One processing activity, screened against Article 35 and carried through to a prior-consultation decision — each risk scored for severity and likelihood before any safeguard is credited. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it and your agent runs the workflow; the server enforces the stages and fetches every citation. Start free Compare plans DPIA — modeled extract modeled example Large-scale special-category processing — assessment required ✓ GDPR Art. 35(3)(b) As-built safeguards lower residual likelihood; severity holds ✓ GDPR Art. 35(7)(d) Authority's own mandatory list not in a served corpus — recorded unresolved ✓ no citation available What a run produces: A GDPR Art. 35 DPIA report: processing description, necessity and proportionality assessment, risk register against thresholds, prior-consultation recommendation, and planned measures. Article 35 screened first — a run can conclude that no DPIA is required CNIL scale severity and likelihood per risk, before safeguards are credited Article 36 a prior-consultation determination, with its basis recorded A DPIA here is a staged interview, not a template you fill in. The run screens first: does Article 35 require an assessment at all, and on what basis. Then it takes the processing description, the DPO's position and your necessity-and-proportionality reasoning, enumerates the risks to data subjects for you to confirm, and scores each one on the CNIL severity and likelihood scale before crediting a single safeguard — and only safeguards you have actually built, since a planned control belongs in the recommendations rather than in the residual score. It closes on transfers, processors and an Article 36 determination: prior consultation, or not, with the reason recorded. The variants change the context the run reasons in — a supervisory authority's practice, or the aviation regime over aerial capture; the assessment itself is the same. the family One DPIA spine, a variant per supervisory context Data Protection Impact Assessment (GDPR Article 35) The base: GDPR Article 35 for one processing activity, any sector. Germany (BDSG-aware) German practice, with competence split between the Land authority under § 40 BDSG and the BfDI. Sweden (GDPR Art. 35 + IMY supervisory practice) Swedish practice, reasoned against IMY as supervisory authority. Drone / UAS Aerial Data Capture (GDPR Art. 35 + Reg (EU) 2019/947) Aerial capture, where Article 35 meets Regulation (EU) 2019/947. The supervisory authority a variant reasons against is part of its configuration, and each conclusion cites the provision it rests on. Where an authority publishes a mandatory-processing list we do not serve, the screening records that gap instead of reproducing the list from memory. how a run works Five stages the server enforces 1 Screening & scope whether Article 35 bites, the processing description, the DPO's position, necessity and proportionality 2 Risk identification data-subject views recorded, risks enumerated, and the list confirmed by you before anything is scored 3 Per-risk analysis one step per risk: the rights affected, CNIL severity and likelihood, then the safeguards that reduce it 4 Consultation & compliance transfers, processors, and the Article 36 determination on prior consultation 5 Report the assessment and its risk register — structured for your agent, rendered for your auditor ask your agent Paste one of these to start Using Ansvar, run a GDPR Article 35 DPIA for our new HR analytics platform. Screen it first, then take it through to the prior-consultation determination. Using Ansvar, which DPIA workflow types can I start, and which supervisory authority does each one reason against? Free gets one workflow run a month and Solo two, spendable on the base DPIA against a processing activity you describe, and a Free or Solo run can also return a render carrying a self-asserted banner. Premium adds the German, Swedish and drone variants on five runs a month. Team and Company run them against records you upload and add unwatermarked HTML, PDF and DOCX exports. Run allowances and what each tier adds live on the pricing page . Questions buyers ask first Which plan do I need to run one? Any of them, for part of the family. Free gets one workflow run a month and Solo two, spendable on the base DPIA against a processing activity you describe. The German, Swedish and drone variants start at Premium. Team and Company add runs grounded in records you upload. The pricing page carries the allowances. Will our supervisory authority accept this as our DPIA? The document is yours, not ours. A run produces the Article 35 record — processing description, necessity and proportionality, the scored risk register, the safeguards and the Article 36 determination — with each conclusion cited to the provision it rests on. A controller still signs it and a DPO still reviews it. Ansvar issues no approval and makes no finding of compliance. Do we have to upload our records? No. On Free, Solo and Premium the run interviews you and assesses what you describe. Uploading your own records is what Team adds: the assessment then anchors to the exact paragraph it came from, with a content hash, so a reviewer can check a conclusion against your document. What happens when a supervisory authority's own list is not in a corpus you serve? The screening records the gap and marks the basis unresolved. Several authorities publish an Article 35(4) list of processing that always requires a DPIA; where we do not serve that list, the run says so rather than reproducing it from model memory. A DPIA you hand to a regulator has to be honest about what it could not ground. Does it decide whether we need prior consultation? It makes the Article 36 determination and records what the determination rests on: the residual risk after safeguards, measured against your own thresholds. Whether you then contact the authority stays your call. as a service Prefer we run it? Every workflow here is also an expert-run service: we run it against your systems, review the output as practitioners, and hand over the finished deliverable. See the services page for how engagements work, or contact us to scope one. Related: Free DPIA template · Worked DPIA run · STRIDE threat model · Privacy sector · Drone & UAS sector · Vendor DPA directory · Workflow docs · Have us run it Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide --- ## STRIDE threat model workflows — software, OT/ICS and drone systems · Ansvar AI URL: https://ansvar.eu/workflows/threat-model Build a STRIDE threat model in your own AI client: a diagram you confirm, six STRIDE lenses, scored threats mapped to controls. One run a month is free. Workflow · Threat model STRIDE threat model Threats enumerated per component against a data-flow diagram you confirm, scored on impact and likelihood, then mapped to the controls and regimes that bear on them. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it and your agent runs the workflow; the server enforces the stages and fetches every citation. Start free Compare plans STRIDE threat model — modeled extract modeled example Control channel accepts unverified commands — tampering ✓ CWE-345 Replay of early data across the trust boundary ✓ RFC 8446 §2.3 Mitigation mapped to a control, with its framework reference ✓ NIST SP 800-53 Rev 5 SC-8 What a run produces: A STRIDE threat register: per-component threats with category, severity, affected assets, mitigations, and regulatory citations. Six STRIDE lenses spoofing through elevation of privilege, one specialist each You confirm twice the diagram before analysis, the threat list before scoring Free one run a month, on a system you describe The run draws the system before it analyses it: components, data flows, trust boundaries and assets, rendered as a diagram you approve. Six STRIDE specialists then work the six categories — in parallel where your client supports it — and merge into one threat list with a coverage matrix, which you review again: add what is missing, drop the false positives, challenge a rating. Only after that does scoring happen, on impact and likelihood, with a CVSS v4 vector where one applies. Threats then map to controls and to the regimes the run adjudicates. On Team and Company a control-investment simulation ranks what to buy first; below that the run says so and finishes without it. The OT and drone variants change the framing and the regimes, not the method. the family One STRIDE spine, a variant per system class STRIDE Threat Model The base: STRIDE against any system you can describe or document. OT / ICS Threat Model (STRIDE, zones-and-conduits) Plant and ICS, framed on IEC 62443 zones and conduits. UAS / Drone Threat Model (STRIDE, UAS-scoped) UAS platforms — the C2 link, ground control and the data chain — under Reg (EU) 2019/945 and 2019/947. Threat sources ground the enrichment stage: ATT&CK and ATLAS are free, and CWE, CAPEC and D3FEND open at Premium. Where no served source grounds a mapping, the run marks it unresolved rather than filling it in. how a run works Eight stages the server enforces 1 System scoping & DFD components, flows, trust boundaries and assets, rendered as a diagram you confirm before any analysis runs 2 Document collection optional; on Team and above the run grounds itself in your own architecture documents 3 STRIDE analysis six specialists work the six categories, in parallel where your client supports it, and merge into one threat list with a coverage matrix 4 Threat review you see every threat before it is scored — add, remove, or challenge a rating 5 Threat enrichment & scoring each threat enriched from served sources, deduplicated, then scored on impact and likelihood 6 Mitigation mapping threats mapped to controls, and to the regimes the run adjudicates — the applicability check itself is Team and above 7 Remediation planning a control-investment simulation ranks what to buy first, on Team and Company; below that the run records the stage as not applicable and carries on 8 Report the threat register — structured for your agent, rendered for your auditor ask your agent Paste one of these to start Using Ansvar, build a STRIDE threat model of our payments API. Start from a data-flow diagram and show me the threat list before you score anything. Using Ansvar, run an OT threat model for our bottling line on IEC 62443 zones and conduits, and map each mitigation to a control. Free gets one workflow run a month and Solo two, spendable on the base STRIDE threat model against a system you describe, and a Free or Solo run can also return a render carrying a self-asserted banner. Premium adds the OT/ICS and drone variants on five runs a month, along with the CWE, CAPEC and D3FEND corpora the enrichment stage draws on. Team and Company run them against your own architecture documents, add unwatermarked HTML, PDF and DOCX exports, and unlock the applicability check and control-investment simulation the last two stages use. Run allowances and what each tier adds live on the pricing page . Questions buyers ask first Which plan do I need to run one? Any of them, for part of the family. Free gets one workflow run a month and Solo two, spendable on the base STRIDE threat model against a system you describe. The OT/ICS and drone variants start at Premium, which also opens the CWE, CAPEC and D3FEND corpora the enrichment stage draws on. Team and Company add runs grounded in architecture documents you upload. Can an agent run this start to finish on its own? No, and that is deliberate. Several steps are review gates that fail closed: the diagram, the threat list and the scoring each stop until a person approves them. You are sitting in your own AI client while the run happens, so approving is a reply rather than a context switch. We would rather a threat model be slower than have one score a component nobody looked at. How is a STRIDE model different from a TARA? STRIDE enumerates threats per component and maps them to mitigations. A TARA produces a risk register — each risk banded for likelihood and consequence, scored against thresholds you set, with a recorded treatment. Teams often run STRIDE first and feed its threats into the TARA. Do you need our architecture documents? No. The diagram stage builds from a description you give in the interview. Uploading your own architecture documents is what Team adds: findings then anchor to the paragraph they came from, with a content hash, so a reviewer can check a threat against your own design note. What comes out at the end? A threat register: per-component threats with a STRIDE category, an impact and likelihood score, affected assets, mapped mitigations and the citations behind them. Every plan returns the complete register as structured data, which is what your agent reads. Rendered documents are the hand-off: Team and Company export unwatermarked HTML, PDF and DOCX, and a Free or Solo run can also return a render carrying a self-asserted banner. as a service Prefer we run it? Every workflow here is also an expert-run service: we run it against your systems, review the output as practitioners, and hand over the finished deliverable. See the services page for how engagements work, or contact us to scope one. Related: TARA workflows · DPIA workflows · Worked STRIDE run · LINDDUN privacy model · Industrial & OT sector · Drone & UAS sector · Control library · Workflow docs · Have us run it Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide --- ## Public tender workflows — bid coverage review and buyer-side lawfulness audit · Ansvar AI URL: https://ansvar.eu/workflows/tender-review Assess a bid requirement by requirement, or audit your own tender for proportionality and transparency. Every requirement anchored to its paragraph. Workflow · Tender review Public tender review & audit Two sides of the same tender: whether a bid covers what the tender demands, and whether the tender's own requirements are lawful. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it and your agent runs the workflow; the server enforces the stages and fetches every citation. Start free Compare plans Tender review — modeled extract modeled example Requirement quoted verbatim and anchored to its own paragraph ✓ doc://…/segment/paragraph/0.p4 Selection and award criteria conflated — flagged questionable ✓ Directive 2014/24/EU Art. 67 Requirement with no verified national citation — recorded unresolved ✓ no citation available What a run produces: A bid completeness review: requirement-by-requirement findings with citations and a coverage score against the tender's regulatory baseline. Per requirement one assessment step each, not one pass over the document Paragraph-anchored every requirement cited to its own segment, with a content hash Sweden · Netherlands LOU and Aanbestedingswet overlays on the shared spine Both sides start by decomposing the tender into lots and requirements, each quoted verbatim from the document you upload and anchored to its own paragraph with a content hash — so a reviewer can check the quote, not just trust it. From there the question splits. Bidding, the run assesses each requirement against your posture and scores coverage per lot against a threshold you set. Contracting, it audits your own requirements: proportionality, non-discrimination, transparency, whether a selection criterion is doing award work, whether an exclusion ground cites the right basis, and it rates each defect for challengeability. The Swedish and Dutch variants overlay LOU and the Aanbestedingswet on the same spine. the family Two sides of the same tender Public Tender Review Bidder side: does your posture cover every requirement, lot by lot. Public Tender Review — Netherlands (Classical, Aw 2012) The bid review under the Dutch classical regime, Aanbestedingswet 2012. Public Tender Review — Sweden (Classical, LOU) The bid review under the Swedish classical regime, LOU. Public Tender Audit (Buyer-Side Lawfulness Review) Buyer side: are your own requirements proportionate, non-discriminatory and transparent. Public Tender Audit — Netherlands (Classical, Aw 2012) The buyer-side audit under the Dutch regime, with PIANOo as reference. Public Tender Audit — Sweden (Classical, LOU) The buyer-side audit under LOU, with Upphandlingsmyndigheten as reference. Each requirement runs the full enrichment pass before a verdict is recorded: the primary regime, the horizontal ones, the sector regulator, case law, and authority guidance. Where none of them grounds a requirement, the finding records the basis as unresolved rather than inheriting an invented one. how a run works Four stages the server enforces 1 Decomposition & scoping the tender broken into lots and requirements, each quoted verbatim and anchored to its paragraph in your upload 2 Per-requirement assessment one step per requirement: coverage against your posture on the bid side, lawfulness on the buyer side 3 Findings review the findings before the report, with the coverage or defect rate measured against the threshold you configured 4 Report requirement-by-requirement findings — structured for your agent, rendered for your auditor ask your agent Paste one of these to start Using Ansvar, review our bid against this tender requirement by requirement, and cite every requirement to its paragraph in the tender document. Using Ansvar, audit our own draft tender for lawfulness: proportionality, non-discrimination, transparency, and whether any selection criterion is doing award work. The Tender review family runs on Team and above — run allowances and what each tier adds live on the pricing page . Questions buyers ask first Which plan do I need to run one? Team. Both sides read a tender document you upload, and document grounding starts at Team — the requirement text is quoted verbatim from your file and anchored to the paragraph it came from. The pricing page carries the run allowances. Bidder side or buyer side — which one do we run? Run the review if you are bidding: it assesses whether your posture covers each requirement, lot by lot, and scores coverage against a threshold you set. Run the audit if you are the contracting authority: it tests your own requirements for proportionality, non-discrimination and transparency, and flags a selection criterion doing award work. Same decomposition, same evidence trail, opposite question. Does it decide whether to bid, or whether a requirement is unlawful? No. Both sides produce findings with a status and a citation, for a bid/no-bid meeting or a legal review. The audit rates each defect for challengeability rather than declaring a requirement unlawful, and Ansvar gives no legal advice. What grounds a finding? The requirement text is a verbatim quote from your uploaded tender, cited to its own paragraph segment with a content hash. The verdict is then enriched across the primary regime, the horizontal ones, the sector regulator, case law and authority guidance before it is recorded — so a reviewer can trace both what the tender said and what the verdict rests on. What if a requirement has no citation you serve? The finding records the basis as unresolved, and the report's quality warnings say how many did. Thin evidence and sub-threshold coverage are reported on the face of the document rather than smoothed over — a review that hides its own weak spots is worth less than one that names them. as a service Prefer we run it? Every workflow here is also an expert-run service: we run it against your systems, review the output as practitioners, and hand over the finished deliverable. See the services page for how engagements work, or contact us to scope one. Related: Worked Swedish LOU review · Gap analysis workflows · Public sector · Solutions · Workflow docs · Have us run it · Scope an engagement Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide --- ## Vulnerability assessment & deferral workflows — rescore a scan, rank the fix · Ansvar AI URL: https://ansvar.eu/workflows/vulnerability-decisions Rescore an existing scan with KEV, EPSS and the controls you hold, rank what to fix first, and evidence deferrals with their reporting flags. Workflow · Vulnerability decisions Vulnerability assessment & deferral A decision layer over a scan you already ran: findings rescored against your context, a ranked investment plan, and a deferral you can defend. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it and your agent runs the workflow; the server enforces the stages and fetches every citation. Start free Compare plans Vulnerability assessment — modeled extract modeled example Base 7.5 reduced to 5.9 — not reachable behind the segmentation control ✓ deterministic_adjusted Known exploited in the wild — deferral flagged for reporting ✓ CISA KEV No control moves this finding — recorded on the immovable floor ✓ no_actionable_candidates What a run produces: A vulnerability-assessment report over an already-scanned finding set: contextual CVSS with KEV and EPSS, the greedy-set control-investment plan, the immovable floor, and a merged CycloneDX VEX for Dependency-Track. KEV · EPSS rescored against exposure and the controls you hold, not the base score Immovable floor the plan names what no investment moves instead of padding itself CRA Article 14 reporting flags computed, ahead of the 11 September 2026 duty Ansvar consumes a scan; it does not run one. Feed a run the finding set you already have — a Dependency-Track export, a Trivy result, your own list — and it rescores each finding through the effective-risk engine with KEV, EPSS and the controls you actually hold, then runs a greedy-set simulation to rank what to buy first. The plan states its own limit: findings that no control moves sit on an immovable floor instead of padding the ranking. The deferral dossier is the other half, for findings you are not fixing yet — it anchors each deferral to the regimes that bear on it and computes the reporting flags the decision triggers. the family Two decisions, one evidence trail Vulnerability Assessment & Control-Investment Plan Rescore a finding set against your context, then rank what to fix first. Vulnerability Deferral Dossier & Control-Investment Plan Evidence a decision not to fix yet, with the regulatory anchors and reporting flags it triggers. Adds a regulatory-anchoring stage to the spine below. Where findings carry SBOM references, the run merges the per-finding fragments into one CycloneDX VEX you can apply in Dependency-Track. Where they do not, no VEX is emitted and the report says why — a VEX that cannot re-match is worse than none. how a run works Five stages the server enforces 1 Finding-set intake your scanner's export, with the asset context and the controls you hold, confirmed by you before scoring starts 2 Document collection optional; on Team and above the run grounds itself in your own attestations 3 Contextual scoring each finding rescored through the engine verbatim, with a VEX fragment where the finding carries a bom-ref 4 Control-investment planning a greedy-set simulation ranks the candidates and stops when nothing further reduces risk 5 Report the rescored set, the plan and its floor — structured for your agent, rendered for your auditor ask your agent Paste one of these to start Using Ansvar, rescore this Dependency-Track export against our asset context and give me a ranked control-investment plan. Using Ansvar, assemble a deferral dossier for the findings we are not fixing this quarter, with the reporting flags each deferral triggers. The Vulnerability decisions family runs on Premium and above — run allowances and what each tier adds live on the pricing page . Questions buyers ask first Do you scan our code or our images? No, and a run refuses to fabricate a scan. Point your own scanner at the artifact and export the findings — a Dependency-Track CycloneDX and VEX export, a Finding export, a Trivy SBOM result — and the run starts from there. An SBOM on its own is not enough: resolving components to CVEs is the scanner's job, and the run will say so rather than guess. Which plan do I need to run one? Premium for both, against a finding set you paste in. Team adds document grounding and unwatermarked HTML, PDF and DOCX exports. The pricing page carries the run allowances. Do we get a VEX document back? When your findings carry resolvable SBOM references, yes: the per-finding fragments merge into one CycloneDX VEX for the Dependency-Track "Apply VEX" path. When they do not, the run emits no VEX and records the reason, including which findings were excluded and why. Dependency-Track matches on the bom-ref from your own BOM, so a VEX built on references it cannot resolve would silently annotate nothing. What is a deferral dossier for? For the findings you are not fixing yet, and for the file you want when someone asks why. Each deferral records the contextual score, the compensating controls you credited, your own rationale verbatim, and regulatory anchors fetched from the live corpus. It also computes which deferrals trip a reporting duty — the CRA Article 14 duty applies from 11 September 2026. It records and evidences a position; it issues no conformity determination. How is the investment plan ranked? By marginal risk reduction, greedily: the simulation picks the control that moves the most across the remaining findings, re-scores, and repeats until nothing further helps. It stops on its own rather than filling a quota, and reports the findings no candidate control reaches as an immovable floor — which is usually the number worth taking to a budget conversation. as a service Prefer we run it? Every workflow here is also an expert-run service: we run it against your systems, review the output as practitioners, and hand over the finished deliverable. See the services page for how engagements work, or contact us to scope one. Related: Sample deferral dossier · CRA explained · TARA workflows · Control library · Security sector · Tool reference · Have us run it Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide --- ## Financial services compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/financial The EU financial-regulation stack at article level — DORA and its technical standards, MiCA, PSD2, MiFID II — plus the workflows that turn it into evidence. Sector · Financial Financial services The whole EU financial-regulation stack at article level — including the technical standards everyone else skips. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage Gap analysis — DORA grounded & cited Register of information incomplete ✓ DORA (EU) 2022/2554 Art. 28(3) No exit strategy for a critical provider ✓ DORA Art. 28(8) ICT-incident reporting window ✓ DORA Art. 19 See a real run: Gap analysis from a security policy Read the full sample deliverable: Sample NIS2 gap analysis 7 core regimes, article-level 11 DORA technical standards Free EU regulations, every tier Financial services is the deepest regulatory corpus behind the gateway. DORA, MiCA, PSD2, MiFID II, CRR/CRD, Solvency II and EMIR are all addressable article by article — and DORA's eleven RTS/ITS technical standards are each a searchable scope, not a footnote. Ask a question, get the provision; then run the gap analysis that turns it into a supervisor-ready register. what we cover The law and standards we ground on Regulation DORA (Reg (EU) 2022/2554) article-level, incl. ICT third-party risk (Art. 28) Regulation DORA RTS/ITS — 11 technical-standard instruments ICT-risk, subcontracting, incident reporting, TLPT, register of information — each a searchable scope Regulation MiCA (Reg (EU) 2023/1114) + RTS/ITS Regulation PSD2 (Dir (EU) 2015/2366) incl. strong customer authentication (Art. 97) Regulation MiFID II / MiFIR · CRR/CRD · Solvency II · EMIR article-level Regulation Horizontal: GDPR · NIS2 · EU AI Act · eIDAS2 Standard Control mapping: ISO 27001 · NIST requirement mapping + cross-references — the ISO 27001 text itself is available as the SIS-licensed add-on (/standards) Guidance Premium Case law · agency guidance · preparatory works inside search on Premium and above what you can do Workflows that turn it into evidence Team DORA gap analysis scoped across DORA and its RTS/ITS, with a cited gap register and export assembled Team ICT third-party-risk mapping register of information (Art. 28(3)), exit strategy (Art. 28(8)), subcontracting RTS — assembled from gap analysis + cited document review Team NIS2 gap analysis & ISO 27001 control mapping for financial entities in scope of NIS2 Premium STRIDE threat model of payment, core-banking or trading systems Team DPIA — GDPR Art. 35 for customer-data and payment processing Team Document review, paragraph-cited ICT outsourcing / cloud contracts against DORA, MiFID II and PSD2 Team Effective-risk CVE rescoring re-rank ICT-asset vulnerabilities with NVD / CISA KEV / EPSS context for DORA ICT-risk management STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you cover the DORA technical standards, not just the regulation? Yes. The eleven RTS/ITS instruments are each addressable as their own scope — ICT-risk-management, subcontracting, incident classification and reporting, threat-led penetration testing, the register-of-information ITS, and the rest — so a gap analysis tests against the detail a supervisor actually checks. Is this a vulnerability scanner? No. The effective-risk capability re-scores vulnerabilities your existing scanners already found, adding exploitation and asset context (CISA KEV, EPSS, NVD) so DORA ICT-risk decisions are reproducible and cited. It complements Tenable / Snyk / Dependabot rather than replacing them. Which prudential regimes are emerging vs in force? The corpus covers in-force law — DORA, MiCA, PSD2, MiFID II, CRR/CRD, Solvency II and EMIR, including the EMIR 3 amendments (Reg (EU) 2024/2987, in force since December 2024). Proposals still in the legislative pipeline (PSD3/PSR, FIDA) are tracked as emerging and are not presented as applicable law. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building financial compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Privacy & data protection compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/privacy GDPR grounded at the article, then turned into evidence: DPIA, LINDDUN privacy threat modelling, and cited document review for DPOs and privacy engineers. Sector · Privacy Privacy & data protection Data protection that grounds every answer in the article, then turns it into evidence. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage DPIA — GDPR Art. 35 grounded & cited DPIA required — large-scale special-category data ✓ GDPR Art. 35(3)(b) Residual high risk — consult the regulator ✓ GDPR Art. 36(1) Severity × likelihood — High ✓ CNIL PIA methodology See a real run: DPIA for a new HR vendor Read the full sample deliverable: Sample DPIA 99 GDPR articles, addressable 7 privacy & DP workflows doc:// paragraph-level citations Privacy is the gateway's deepest workflow lane. Ask a question and the answer comes from the GDPR article itself — then the same corpus runs your DPIA, privacy threat model, or contract review and returns each finding cited to the provision it rests on. what we cover The law and standards we ground on Regulation GDPR (Reg (EU) 2016/679) full article-level, recitals included Regulation ePrivacy Directive (2002/58/EC) Regulation Law Enforcement Directive (EU) 2016/680 Regulation GDPR Art. 22 — automated individual decision-making plus the EU AI Act intersection for AI-driven decisions Law National GDPR-implementation statutes audited GREEN set — see /coverage for the live jurisdiction footprint Guidance Premium Case-law fan-out where licensing permits arrives inside search on Premium and above what you can do Workflows that turn it into evidence Team DPIA — GDPR Art. 35 with Germany (BDSG) and Sweden (IMY) variants; drives Art. 36 prior-consultation and severity × likelihood scoring Premium LINDDUN privacy threat model systematic privacy-threat elicitation over your data-flow diagram Team Document review, paragraph-cited a privacy notice, DPA, RoPA or processor contract against GDPR, each finding anchored to a doc:// segment Team GDPR gap analysis cited gap register with PDF / CSV / GRC-import export Premium STRIDE threat model for Art. 32 TOMs security-of-processing measures evidenced against the article Team FRIA — EU AI Act Art. 27 for AI systems processing personal data assembled Team National-divergence & transfer analysis cross-jurisdiction comparison, legitimate-interest balancing (Art. 6(1)(f)), Chapter V transfers — assembled from cited research STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you store our documents or personal data? No. Your AI client connects to the gateway and the corpora answer source-scoped questions; the MCP servers store no client data. Uploaded documents you review are held under your own tenant and cited by segment hash. Is the case law in the answer reliable? Case law arrives through premium fan-out only where the source licensing permits it, and every hit is cited to the deciding body. Where no licensed case-law source covers a point, the answer says so rather than inventing one. Which national data-protection laws are covered? The EU-level GDPR text is on every tier. National implementation statutes are covered for the audited GREEN jurisdictions listed on /coverage. National DPA enforcement decisions are out of scope where their licensing does not permit redistribution. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building privacy compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## AI governance compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/ai Classify the system, map the obligations, and ground every duty in the article of the AI Act. Sector · AI governance AI governance Classify the system, map the obligations, and ground every duty in the article of the AI Act. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage EU AI Act high-risk readiness grounded & cited High-risk — safety component of a vehicle ✓ AI Act (EU) 2024/1689 Art. 6(1) Provider duties — risk & quality-management systems ✓ AI Act Art. 16 Conformity assessment before it reaches the market ✓ AI Act Art. 43 See a real run: EU AI Act high-risk classification for credit scoring Read the full sample deliverable: Sample AI Act readiness assessment Full AI Act, article-level Art. 6 high-risk test + Annex III Free the whole Act, every tier The full EU AI Act, article by article — prohibited practices, the high-risk test, provider and deployer duties, conformity assessment, GPAI. The deadlines are live: GPAI duties have applied since 2 August 2025, the Article 50 transparency duties apply from 2 August 2026, and the high-risk regime — postponed by the 2026 Digital Omnibus — applies from 2 December 2027 (Annex III) and 2 August 2028 (Annex I embedded). Ask where your system lands and get the provision; then run the readiness gap analysis that turns it into an obligation register. what we cover The law and standards we ground on Regulation EU AI Act (Reg (EU) 2024/1689) full article-level, incl. annexes, definitions & recitals Regulation Risk classification — prohibited practices (Art. 5), high-risk (Art. 6 + Annex III) Regulation Role duties — provider (Art. 16), deployer (Art. 26), FRIA (Art. 27), conformity (Art. 43) Regulation GPAI & systemic-risk model provisions (Art. 51–55) Regulation GDPR intersection — automated decisions (Art. 22), DPIA trigger (Art. 35) Guidance Premium EU AI Office guidance Standard ISO/IEC 42001 — AI management systems the standard text itself, cited verbatim, as the SIS-licensed add-on — one of five live standards (/standards) what you can do Workflows that turn it into evidence Team AI Act readiness & gap analysis classify the role (provider / deployer / importer / distributor), map it to obligations, and produce a per-obligation gap register Team FRIA — EU AI Act Art. 27 the deployer fundamental-rights impact assessment, with a Sweden variant Team DPIA for AI systems processing personal data GDPR Art. 35, with Germany and Sweden variants Premium STRIDE threat model of the AI system over your architecture and data-flow diagram Team Document review, paragraph-cited model cards, technical documentation and AI-governance policies against the Act assembled Premium Role & obligation classification as cited research free single-jurisdiction search; premium adds AI Office guidance — also delivered as the senior-reviewed AI Act Readiness assessment STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you classify our system as high-risk for us? The workflow grounds the classification in Art. 5, Art. 6 and Annex III and shows the reasoning cited to the Act. The legal call stays yours, or our senior-reviewed AI Act Readiness service makes it — there is no one-click 'high-risk' verdict. Is the AI Act transposed differently per country? No. The AI Act is an EU Regulation with direct effect — there is no national transposition to track. National measures concern enforcement authorities and a few narrow derogations, not the obligations themselves. When do the AI Act obligations actually apply? In stages: prohibited practices and AI-literacy duties since 2 February 2025, GPAI obligations since 2 August 2025, and the Article 50 transparency duties from 2 August 2026. The high-risk regime was postponed by the 2026 Digital Omnibus: stand-alone Annex III systems apply from 2 December 2027 and Annex I embedded systems from 2 August 2028. The corpus serves the full Act today, so you can build the obligation register before your date lands. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building ai governance compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Public sector compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/public Test a tender — or your public-body AI duties — for lawfulness before someone else does. Sector · Public sector Public sector Test a tender — or your public-body AI duties — for lawfulness before someone else does. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage Tender lawfulness audit grounded & cited Award criteria must be linked to the subject-matter of the contract ✓ LOU 16 kap. 2 § Qualification requirement is disproportionate ✓ Directive 2014/24/EU Art. 58 See a real run: Swedish tender review under LOU SE · NL procurement law in depth Art. 27 public-body FRIA duty Statute free; case law on Premium and above Public procurement and public-body duties, grounded in the statute that governs them. Swedish (LOU/LUF) and Dutch (Aanbestedingswet) procurement law sit at provision level — with case law and preparatory works on Premium and above — alongside the AI Act Art. 27 FRIA duty and the NIS2 obligations that land on public administrations. what we cover The law and standards we ground on Law National public-procurement law Sweden (LOU/LUF) and Netherlands (Aanbestedingswet 2012) at statute level Guidance Premium Procurement case law & preparatory works Sweden and Netherlands Regulation EU AI Act Art. 27 — public-body FRIA duty Regulation GDPR Art. 35 — public-body DPIA basis Regulation NIS2 (Dir (EU) 2022/2555) Art. 21 — public-administration security what you can do Workflows that turn it into evidence Team Public tender review (bidder-side) a tender pack against procurement-law requirements with statute citations — Sweden (LOU) and Netherlands (Aw 2012) variants plus a jurisdiction-neutral base Team Public tender audit (buyer-side) scan your own tender for unlawful selection, award or exclusion criteria — Sweden and Netherlands variants Team AI Act FRIA — Art. 27 the public-body deployer fundamental-rights impact assessment, with a Sweden variant Team Regulatory gap analysis including NIS2 Art. 21 for public-administration entities Team DPIA — GDPR Art. 35 with Germany and Sweden variants Team Document review, paragraph-cited public-sector policies, contracts and tender packs STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you cover the EU procurement directive directly? Procurement questions are grounded in the national statute that transposes the directive — Sweden's LOU/LUF and the Netherlands' Aanbestedingswet — at provision level, with case law and preparatory works on Premium and above. That is what a review board actually cites. Is this only Sweden and the Netherlands? Procurement statute is searchable across the audited jurisdictions, but dedicated depth — case law, preparatory works, and the tender review and audit workflows — is built for Sweden and the Netherlands today, with more on the roadmap. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building public sector compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Healthcare & medical devices compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/healthcare Medical-device regulation and health-data privacy, grounded article by article. Sector · Healthcare Healthcare & medical devices Medical-device regulation and health-data privacy, grounded article by article. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage DPIA — special-category health data grounded & cited DPIA required — large-scale special-category (health) data ✓ GDPR Art. 35(3)(b) AI-enabled diagnostic — high-risk medical-device software ✓ AI Act (EU) 2024/1689 Art. 6(1) Clinical evaluation & post-market surveillance owed ✓ MDR (EU) 2017/745 Annex XIV See a real run: Gap analysis from a security policy MDR · IVDR article-level + annexes Art. 9 special-category health data Free the EU regulations, every tier MDR, IVDR, the Clinical Trials Regulation and the European Health Data Space are served at article level, alongside GDPR Article 9 for special-category health data and the horizontal cyber regimes. Ask the provision; then run the DPIA, gap analysis or device threat model that turns it into evidence. what we cover The law and standards we ground on Regulation Medical Device Regulation (Reg (EU) 2017/745) article-level, incl. annexes Regulation In Vitro Diagnostic Regulation (Reg (EU) 2017/746) Regulation Clinical Trials Regulation (Reg (EU) 536/2014) Regulation European Health Data Space (Reg (EU) 2025/327) Regulation GDPR Art. 9 — special-category health data (+ full GDPR) Regulation Horizontal: NIS2 · EU AI Act (software as a medical device) · CRA Guidance Premium MDCG medical-device guidance what you can do Workflows that turn it into evidence Team DPIA for special-category health data GDPR Art. 35 + Art. 9, with Germany and Sweden variants Team Regulatory gap analysis against MDR / IVDR / GDPR / NIS2, with a dedicated NIS2 variant Premium Medical-device product-security threat model STRIDE over a device data-flow diagram — not a device-conformity verdict Premium LINDDUN privacy threat model for clinical and patient-data flows Team FRIA — EU AI Act Art. 27 for AI-based devices and high-risk software-as-a-medical-device AI Team Document review, paragraph-cited technical documentation, clinical SOPs and QMS documents STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Does this certify a device as conforming? No. The workflows produce a cited gap analysis and a STRIDE threat model against MDR/IVDR and the security obligations — decision-support, not a conformity verdict or a notified-body assessment. Is national health law covered? The EU regulations (MDR, IVDR, CTR, EHDS) and GDPR are covered at article level. Beyond the EU layer, Ansvar serves dedicated national medical-device regulation corpora for jurisdictions across Europe, the Americas and Asia-Pacific — see the coverage page for the live list — and national health statutes are also reachable inside the audited national-law corpora. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building healthcare compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Industrial / OT / ICS compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/industrial-ot OT and ICS security, mapped to 62443 and enriched with live advisories — without the standard text. Sector · Industrial / OT Industrial / OT / ICS OT and ICS security, mapped to 62443 and enriched with live advisories — without the standard text. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage OT threat model — IEC 62443 zones & conduits grounded & cited Zone & conduit segmentation required ✓ IEC 62443-3-2 · ZCR mapping Least-privilege foundational requirement ✓ IEC 62443-3-3 · SR 2.1 mapping Known-exploited CVE on a Siemens S7-1500 ✓ CISA ICS advisory + CISA KEV See a real run: STRIDE threat model for an authentication flow 62443 clause map, 1-1…4-2 ISO 10218 robot-cell + safety bridge Live CISA ICS advisories + KEV IEC 62443 and ISO 10218 are surfaced as requirement and clause mappings with Ansvar cross-references — never the reproduced standard — alongside the EU Machinery Regulation at article level. Live CISA ICS advisories enrich your CVEs with exploitation context so an OT TARA runs on what is actually being attacked. what we cover The law and standards we ground on Standard Control mapping: IEC 62443 (1-1…4-2) IACS-security requirement/clause mapping + cross-refs into NIST 800-82r3, ATT&CK for ICS — not the standard text Standard Control mapping: ISO 10218-1/-2:2025 + the safety-security bridge robot & robot-cell clause mapping, not the standard text Standard OT protocol security models: Modbus/TCP, DNP3, OPC UA, PROFINET, EtherNet/IP (CIP), IEC 61850/62351, BACnet/SC 77 protocol-hardening requirements as clause-map metadata + Ansvar guidance, cross-referenced to NIST SP 800-82r3 — not the reproduced standard text Regulation EU Machinery Regulation (EU) 2023/1230 article-level (applies 2027-01-20) Regulation Cyber Resilience Act · NIS2 Guidance CISA ICS/OT advisories mapped to CVEs + affected products, enriched with CISA KEV / EPSS / NVD what you can do Workflows that turn it into evidence Premium OT / ICS threat model STRIDE over a zones-and-conduits model, grounded in the IEC 62443 clause map assembled Premium Robot-cell TARA scoped to a robot or cobot cell off the ISO 10218 / safety-security-bridge clause map — an available analysis, not a legally-assured verdict Team IEC 62443 zone & conduit gap analysis configured to the 62443 clause map Team EU Machinery Regulation gap analysis Annex III essential-H&S coverage incl. the conformity route — a gap analysis, never a conformity verdict Team NIS2 gap analysis for OT/ICS operators Directive (EU) 2022/2555 Art. 21 Team ICS-advisory-enriched CVE rescoring re-rank OT vulnerabilities by CISA KEV, EPSS and ICS-advisory context instead of raw CVSS STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you give us the IEC 62443 or ISO 10218 text? Not by default — we surface 62443 and 10218 as requirement and clause mappings with Ansvar-authored cross-references, and map the requirements to your system against your licensed copy. But the standard text itself can be added: through the SIS-licensed standards module, any ISO, EN or SS standard SIS publishes can be licensed in and served cited verbatim inside your workflows; see /standards. Is this a vulnerability scanner for OT? No. It re-scores vulnerabilities your scanners already found, adding CISA ICS-advisory, KEV and EPSS context so OT risk decisions are reproducible and cited. It never surfaces or runs exploit code. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building industrial / ot compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Energy & utilities compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/energy Grid and generation compliance, anchored on the NIS2 duties that land on essential entities. Sector · Energy Energy & utilities Grid and generation compliance, anchored on the NIS2 duties that land on essential entities. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage NIS2 gap analysis — essential entity grounded & cited Risk-management measures for an essential entity ✓ NIS2 (EU) 2022/2555 Art. 21 Significant-incident 24-hour early warning ✓ NIS2 Art. 23(4) Critical-entity resilience overlay ✓ CER (EU) 2022/2557 Art. 13 See a real run: Gap analysis from a security policy Art. 21 NIS2 essential-entity measures Multi-jx national energy statute, GREEN Free the EU regulations, every tier Energy compliance grounded in the regulations that bite — NIS2 essential-entity obligations, the Critical Entities Resilience Directive, and the EU cyber stack at article level — alongside national energy statute across the audited GREEN jurisdictions. Run the NIS2 gap analysis or an OT threat model on grid, generation and SCADA estates. what we cover The law and standards we ground on Law National energy statutes audited GREEN jurisdictions (e.g. SE Ellagen, DE EnWG, GB Electricity Act 1989 + Utilities Act 2000, NO energiloven) Regulation NIS2 (Dir (EU) 2022/2555) essential-entity security measures (Art. 21) & supervision Regulation Critical Entities Resilience Directive (EU) 2022/2557 energy as a designated critical-entity sector Regulation Cybersecurity Act (EUCC) · Cyber Solidarity Act Guidance Premium Energy case law · preparatory works · agency guidance what you can do Workflows that turn it into evidence Team NIS2 gap analysis Directive (EU) 2022/2555 Art. 21 for energy essential and important entities — the page spine Premium OT / ICS threat model STRIDE zones-and-conduits for grid, generation, substation and SCADA systems assembled Premium OT / ICS TARA for operational-technology assets — an available analysis, never a legally-assured verdict Team Effective-risk CVE rescoring reprioritise OT/ICS vulnerabilities with NVD / CISA KEV / EPSS context — never exploit code Team Critical Entities Resilience & regulatory gap analysis CER (EU) 2022/2557 and broader regimes assembled Team Adversary tabletop & enterprise risk assessment critical-infrastructure incident readiness (ISO 31000 / NIST 800-30) STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you cover the EU electricity and gas market directives? The corpus covers the cyber and resilience stack at article level — NIS2, CER, the Cybersecurity Act and Cyber Solidarity Act — plus national energy statute. The EU electricity and gas market directives are not in the corpus, and neither yet is the Network Code on Cybersecurity (Reg (EU) 2024/1366) — it is on the ingestion roadmap. We will not imply coverage we cannot ground. Which national energy laws are covered? National energy statute is covered for the audited GREEN jurisdictions — Sweden's Ellagen, Germany's EnWG, the GB Electricity Act 1989 and Utilities Act 2000, Norway's energiloven and others on /coverage. These are statutes, not a separate energy-regulator decision corpus. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building energy compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Automotive compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/automotive Make your TARA — and your CSMS evidence — hold up to UN R155 type approval, grounded in R155/R156 and an ISO 21434 clause map. Sector · Automotive Automotive Make your TARA — and your CSMS evidence — hold up to UN R155 type approval. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage Vehicle threat model — ISO 21434 grounded & cited CSMS evidence required for approval ✓ UN R155 §7.2 Threat scenarios per asset ✓ ISO/SAE 21434 §15.4 Risk-treatment decisions logged ✓ ISO/SAE 21434 §15.9 See a real run: STRIDE threat model for an authentication flow R155 · R156 provision-level ISO 21434 clause map + cross-refs TARA threat analysis & risk assessment Vehicle cybersecurity grounded in the regulations and standards that gate type approval. UN R155 and R156 are addressable provision by provision, with ISO/SAE 21434 and the diagnostic standards surfaced as clause maps and Ansvar cross-references — never the standard text. Run the TARA, the CSMS gap, or an ECU effective-risk pass and cite every finding. what we cover The law and standards we ground on Regulation UN R155 (cybersecurity) · UN R156 (software update) addressable provision-level Standard Control mapping: ISO/SAE 21434 requirement mapping + cross-references — the ISO/SAE 21434 text itself is available as the SIS-licensed add-on (/standards) Standard Control mapping: UDS · DoIP · SOVD · AUTOSAR diagnostics clause mapping, not the standard text Regulation Repair & maintenance information access — RMI / SERMI Reg (EU) 2018/858 Regulation Horizontal: Cyber Resilience Act · GDPR (connected-vehicle data) what you can do Workflows that turn it into evidence assembled Premium Vehicle threat model & TARA ISO/SAE 21434 over the ECU and asset model — an available analysis, not a type-approval verdict Team UN R155 CSMS gap analysis cybersecurity-management-system evidence for type approval Team UN R156 software-update gap analysis SUMS evidence for software-update management Team Effective-risk CVE rescoring re-rank ECU and component vulnerabilities with CISA KEV / EPSS context — never exploit code Team Document review, paragraph-cited TARA reports and CSMS/SUMS evidence packs against R155/R156 STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you give us the ISO/SAE 21434 text? By default, ISO/SAE 21434 and the diagnostic standards are surfaced as requirement and clause mappings with Ansvar cross-references, not the reproduced standard. But the ISO/SAE 21434 text itself — licensed and cited verbatim inside your workflows — is available as the SIS-licensed standards add-on, one of the five standards live today; see /standards. UN R155 and R156 are the regulations, addressable provision by provision. Does this produce a type-approval verdict? No. The TARA and CSMS/SUMS gap analyses are decision-support — cited evidence you take into the type-approval process, not the approval itself. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building automotive compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Drone & UAS compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/drone Drone law, drone-cyber threat modelling and an agent-ready corpus in one lane — EU 2019/947, a UAS threat library, TARA and counter-UAS. Sector · Drone / UAS Drone & UAS Where drone law, drone-cyber threat modelling, and an agent-ready corpus meet. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage UAS threat model & TARA grounded & cited Open-category operation — operator registration & marking ✓ Reg (EU) 2019/947 Art. 14 Risk-based operational authorisation (SORA) ✓ Reg (EU) 2019/947 Art. 11 Datalink spoofing — UAS attack technique ✓ UAS threat library → ATT&CK for ICS See a real run: STRIDE threat model for an authentication flow 2019/947 EU drone law, provision-level 70+ Ansvar UAS threats, ATT&CK-mapped TARA + counter-UAS assessment UAS compliance and security in one lane — EU drone law at provision level, an Ansvar-authored UAS threat library, and a standards clause-map for the drone stack, wired into threat-model, TARA and counter-UAS workflows. No other compliance tool fuses aviation law with drone-cyber threat content. what we cover The law and standards we ground on Regulation EU drone law — Reg (EU) 2019/947 (operations) · 2019/945 (product) provision-level Guidance UAS threat library Ansvar-authored drone threats & attack techniques, cross-referenced to ATT&CK for ICS and CAPEC Standard Control mapping: UAS standards stack clause map (e.g. EN 4709-1, ISO 23629-8) + Ansvar cross-refs — not the standard text; standards can be licensed in via the SIS add-on (/standards) Law National UAS rules + US 14 CFR Part 107 addressable where audited; see /coverage for the live footprint Regulation Horizontal: Cyber Resilience Act · RED · GPSR drone product security what you can do Workflows that turn it into evidence Team Drone operator compliance operational authorisation and obligations under Reg (EU) 2019/947 (legally reviewed) Team Drone product-security conformity against Reg (EU) 2019/945, the CRA and RED (legally reviewed) Premium Drone threat model (UAS STRIDE) over the platform, datalink, ground station and backend assembled Premium UAS TARA threat analysis & risk assessment off the UAS threat library — an available analysis, not a legally-assured verdict assembled Team Counter-UAS assessment an available analysis of counter-UAS posture — not legal advice on use of force STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first What makes this different from a SORA tool? SORA tooling stops at the operational risk assessment. This lane fuses the drone law, an Ansvar-authored UAS threat library mapped to ATT&CK, and a standards clause-map — so a single workflow takes you from 2019/947 obligations to a cited UAS threat model and TARA. Are the TARA and counter-UAS outputs legally assured? No. The operator-compliance and product-security workflows are legally reviewed; the UAS TARA and counter-UAS assessment are available analyses grounded in cited sources, not legal opinions. Counter-UAS in particular says nothing about lawful use of force. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building drone / uas compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## IT & cloud security compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/security STRIDE threat models grounded in OWASP and ATT&CK, the CRA and NIS2 at article level, and live CVE / KEV / EPSS context — every finding cited to its source. Sector · Security IT & cloud security Threat modelling, product-security law, and live vulnerability context — every finding cited to its source. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage STRIDE threat model grounded & cited Spoofing — token replay across the service boundary ✓ OWASP ASVS 4.0.3 §3.5 Tampering — unsigned inter-service calls ✓ MITRE ATT&CK T1557 Mitigation owed for the product ✓ CRA (EU) 2024/2847 Annex I See a real run: STRIDE threat model for an authentication flow Read the full sample deliverable: Sample threat model STRIDE threat models, source-grounded CRA · NIS2 product-security law, article-level Live CVE · CISA KEV · EPSS Security is where Ansvar runs deepest: STRIDE threat models grounded in OWASP, ATT&CK and CAPEC; the Cyber Resilience Act and NIS2 at article level; control mappings across ISO 27001 Annex A, NIST CSF/800-53 and CIS; and live CVE / CISA KEV / EPSS context for effective-risk decisions. Ask the requirement, get the source; then run the threat model or gap analysis that turns it into evidence. what we cover The law and standards we ground on Regulation Cyber Resilience Act (Reg (EU) 2024/2847) Regulation NIS2 (Dir (EU) 2022/2555) Regulation GDPR Art. 32 — security of processing Standard Control mapping: OWASP ASVS · NIST CSF/800-53 · ISO 27001 Annex A · CIS · MITRE ATT&CK requirement mapping + cross-references, not the standard text Standard MITRE ATT&CK · CAPEC · CWE · D3FEND threat & weakness catalogs, cited per technique; CAPEC / CWE / D3FEND on Premium and above Guidance CVE · CISA KEV · EPSS — live vulnerability context for effective-risk rescoring; not a scanner what you can do Workflows that turn it into evidence Premium STRIDE threat model over your architecture or data-flow diagram, each threat cited to OWASP / ATT&CK / CAPEC patterns Team Effective-risk CVE rescoring re-rank the findings your scanners already produced with CISA KEV, EPSS and NVD context — reproducible and cited, never exploit code Team NIS2 gap analysis & ISO 27001 control mapping Art. 21 measures mapped to the controls you already run Team CRA readiness gap analysis essential requirements (Annex I) for products with digital elements Team Document review, paragraph-cited security policies, ISO 27001 evidence and vendor questionnaires, each finding anchored to a doc:// segment assembled Premium Security research as cited answers free single-jurisdiction search; premium adds CAPEC / CWE / D3FEND and the IETF security RFCs STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Is this a vulnerability scanner or a SIEM? No. Ansvar grounds decisions — it re-scores the vulnerabilities your scanners already found (CISA KEV, EPSS, NVD), maps controls, and produces cited threat models and gap registers. It never runs exploit code and never watches your network. Do you serve the ISO 27001 text? The control mapping cross-references ISO 27001 Annex A without reproducing the standard. But the standard text itself — cited rather than paraphrased — is available as the SIS-licensed standards add-on: ISO 27001, 27002 and 27005 are among the five standards live today, and through SIS any ISO, EN or SS standard can be added; see /standards. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building security compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Agriculture & machinery compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/agriculture Autonomous-machinery conformity and cyber-physical risk, cited at article and clause level. Sector · Agri & machinery Agriculture & machinery Autonomous-machinery conformity and cyber-physical risk, cited at article and clause level. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage Machinery + AI Act readiness grounded & cited Essential H&S — autonomous-mobility hazards ✓ Machinery Reg (EU) 2023/1230 Annex III Safety-related control logic ✓ ISO 13849-1 AI safety component — high-risk provider duties ✓ AI Act (EU) 2024/1689 Art. 6(1) See a real run: Gap analysis from a security policy · EU AI Act high-risk classification for credit scoring 2023/1230 Machinery Reg, article-level 14 stds agri-machinery clause maps Free the EU regulations, every tier The EU Machinery Regulation is served at article level alongside the AI Act duties that land on AI safety components, with the agri-machinery standards stack — ISO 4254, ISOBUS 11783, ISO 25119 and the functional-safety series — surfaced as clause maps with Ansvar cross-references, never the standard text. Farm-data governance under the Data Act and deforestation-free supply-chain duties under the EUDR complete the picture. Ask the provision; then run the machinery gap analysis or an autonomous-machinery TARA that turns it into evidence. what we cover The law and standards we ground on Regulation Machinery Regulation (EU) 2023/1230 article-level, incl. Annex III essential H&S (applies 2027-01-20) Regulation EU AI Act — high-risk safety-component duties (Reg (EU) 2024/1689) Standard Control mapping: agri-machinery safety stack (ISO 4254 · ISOBUS 11783 · ISO 25119 · IEC 62061 · EN 690) clause map + Ansvar cross-refs into Machinery Reg essential requirements — not the standard text Standard Control mapping: functional safety & autonomous-machine stack (ISO 12100 · ISO 13849 · ISO 18497 · ISO 3691-4 · ISO 10218) requirement mapping, not the standard text Guidance Farm-data governance — EU Data Act (Reg (EU) 2023/2854) article-level Data Act plus Ansvar guidance on machinery-data access and sharing Regulation EUDR (Reg (EU) 2023/1115) — deforestation-free supply-chain duties Regulation Horizontal: Cyber Resilience Act · GDPR connected-machinery product security and operator data what you can do Workflows that turn it into evidence Team EU Machinery Regulation gap analysis Annex III essential-H&S coverage incl. the conformity route — a gap analysis, never a conformity verdict Premium Autonomous-machinery TARA threat analysis & risk assessment for field robots and autonomous implements, off the robot TARA workflow — an available analysis, not a legally-assured verdict Team AI Act gap analysis & classification high-risk safety-component duties for AI in machinery (Art. 6(1)), with a dedicated AI Act variant Premium STRIDE threat model over fleet telematics, ISOBUS networks and farm-management-system integrations assembled Team Farm-data governance assessment Data Act access, sharing and switching duties for machinery-generated data — an available analysis Team Document review, paragraph-cited technical documentation, risk assessments and operator manuals STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you serve the ISO 4254 or ISOBUS text? Not by default — the agri-machinery stack is surfaced as clause maps with Ansvar-authored cross-references into the Machinery Regulation's essential requirements, and we make the requirements addressable against your licensed copy. But the standard text itself can be added: through the SIS-licensed standards module, any ISO, EN or SS standard SIS publishes can be licensed in and served cited verbatim inside your workflows; see /standards. Can this certify a machine under the Machinery Regulation? No. The workflows produce cited gap analyses against Reg (EU) 2023/1230 and the AI Act — decision-support for your conformity work, not a conformity verdict or a notified-body assessment. We fly spray drones — is that this page? Aerial application sits in the drone / UAS lane, which covers Reg (EU) 2019/947 operations, SORA and UAS threat modelling — see the Drone & UAS sector. This page covers ground machinery, field robots and the data that rides on them. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building agri & machinery compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Robotics & automation compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/robotics Robot-cell safety, Machinery Regulation conformity, and robot-stack security — cited at clause and article level. Sector · Robotics Robotics & automation Robot-cell safety, Machinery Regulation conformity, and robot-stack security — cited at clause and article level. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage Robot / cobot TARA — ISO 10218 map grounded & cited Essential health & safety requirements for machinery ✓ Machinery Reg (EU) 2023/1230 Annex III High-risk duties for AI safety components ✓ AI Act (EU) 2024/1689 Art. 6(1) Collaborative-operation safety requirements ✓ ISO 10218 clause map + ISO/TS 15066 See a real run: STRIDE threat model for an authentication flow · Gap analysis from a security policy 10218:2025 clause map + ISO/TS 15066 ROS 2 / DDS security guidance, full text Free the EU regulations, every tier ISO 10218-1/-2:2025 and ISO/TS 15066 collaborative modes are surfaced as clause maps with Ansvar cross-references — never the reproduced standard — alongside the EU Machinery Regulation and the AI Act duties on AI safety components at article level. The robot stack itself is covered full-text: ROS 2 / DDS security guidance and robot exploitation chains (both Apache-2.0), bridged to IEC 62443 industrial cyber. Ask the requirement; then run the robot TARA or machinery gap analysis that turns it into evidence. what we cover The law and standards we ground on Regulation Machinery Regulation (EU) 2023/1230 article-level, incl. Annex III essential H&S (applies 2027-01-20) Regulation EU AI Act — high-risk safety-component duties (Reg (EU) 2024/1689) Standard Control mapping: ISO 10218-1/-2:2025 + ISO/TS 15066 collaborative operation robot & robot-cell clause map + Ansvar cross-refs — not the standard text Standard Control mapping: functional safety (ISO 12100 · ISO 13849) + IEC 62443 industrial cyber requirement mapping incl. the safety-security bridge — not the standard text Guidance ROS 2 / DDS security + robot exploitation chains served full-text (Apache-2.0) — robot-stack hardening and attack techniques, cited per item Regulation Horizontal: Cyber Resilience Act · NIS2 what you can do Workflows that turn it into evidence Premium Robot / cobot TARA threat analysis & risk assessment off the robot TARA workflow, grounded in the ISO 10218 / safety-security-bridge clause map — an available analysis, not a legally-assured verdict Team EU Machinery Regulation gap analysis Annex III essential-H&S coverage incl. the conformity route — a gap analysis, never a conformity verdict Premium STRIDE threat model over the robot controller, ROS 2 graph, fleet manager and cloud backend Team AI Act gap analysis & classification high-risk safety-component duties for AI in robots (Art. 6(1)) assembled Premium Robot-stack security research as cited answers ROS 2 / DDS hardening and robot exploitation chains, every answer cited to its source Team Document review, paragraph-cited risk assessments, technical documentation and integration specs STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you serve the ISO 10218 or ISO/TS 15066 text? Not by default — robot-safety standards are surfaced as clause maps with Ansvar-authored cross-references, addressable against your licensed copy. But the standard text itself can be added: through the SIS-licensed standards module, any ISO, EN or SS standard SIS publishes can be licensed in and served cited verbatim inside your workflows; see /standards. The ROS 2 / DDS security guidance and the robot exploitation catalog are served full-text — both are Apache-2.0 licensed. Can this certify a robot cell under the Machinery Regulation? No. The workflows produce cited gap analyses and a TARA — decision-support for your conformity work, not a conformity verdict or a notified-body assessment. How is this different from the Industrial / OT page? Industrial / OT takes the plant operator's view — zones, conduits and live ICS advisories. This lane takes the robot maker's and integrator's view: cell-level safety clause maps, Machinery Regulation conformity duties, and the security of the robot stack itself. The IEC 62443 mapping is shared between both. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building robotics compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## Rail & signalling compliance — coverage & workflows · Ansvar AI URL: https://ansvar.eu/sectors/rail Railway cybersecurity anchored on the CLC/TS 50701 clause map and the EN 50126/50129 safety-case spine — cited at clause and article level. Sector · Rail Rail & signalling Railway cybersecurity anchored on the CLC/TS 50701 clause map and the EN 50126/50129 safety-case spine — cited at clause and article level. Ansvar is a gateway for the AI assistant your team already uses — Claude, Microsoft Copilot, any MCP client. Connect it, and every answer below comes back cited to the provision or marked unresolved. Start free See full coverage Rail TARA — CLC/TS 50701 shape grounded & cited Rail is an essential-entity sector ✓ NIS2 (EU) 2022/2555 Annex I Risk-management measures & incident reporting ✓ NIS2 Art. 21 · Art. 23 Railway zones, conduits and SL targets ✓ CLC/TS 50701 clause map See a real run: STRIDE threat model for an authentication flow · Gap analysis from a security policy TS 50701 railway cyber clause map EN 5012x RAMS & safety-case spine Free the EU regulations, every tier CLC/TS 50701 — the railway application of IEC 62443 — is surfaced as a clause map with Ansvar cross-references, never the reproduced standard: the railway asset and zone model, zones & conduits, the initial and detailed risk assessments, security-level targets and the cybersecurity case. It sits on the EN 50126/50129 RAMS and signalling safety-case spine, bridges into the shared IEC 62443 industrial-cyber mapping, and is grounded in the railway rows of the live ENISA transport threat landscape. NIS2 lands on rail operators as essential entities; run the rail TARA or a NIS2 gap analysis over signalling, rolling stock and trackside estates. what we cover The law and standards we ground on Standard Control mapping: CLC/TS 50701 railway cybersecurity railway zone model, zones & conduits, SL targets, the cybersecurity case — clause map + Ansvar cross-refs, not the standard text Standard Control mapping: EN 50126 RAMS · EN 50129 signalling safety case the safety-case spine the cyber clause map layers on — not the standard text Standard Control mapping: IEC 62443 industrial cyber the 50701 ↔ 62443 bridge, shared with the Industrial / OT lane — not the standard text Guidance ENISA transport threat landscape — railway served full text (CC-BY-4.0) — rail threat actors, incidents and scenarios, cited per item Regulation Horizontal: NIS2 (Dir (EU) 2022/2555) · CER (EU) 2022/2557 rail as an essential / critical-entity sector, article level what you can do Workflows that turn it into evidence Premium Rail TARA threat analysis & risk assessment off the rail TARA workflow, following the CLC/TS 50701 initial + detailed risk-assessment shape — an available analysis, not a CSM-RA determination or an assessment-body verdict Premium STRIDE threat model over signalling / CCS, rolling stock, TMS and trackside OT, grounded in the 50701 zone model Team NIS2 gap analysis Directive (EU) 2022/2555 Art. 21 for rail essential entities Team IEC 62443 zone & conduit gap analysis the shared 62443 clause map applied to the railway zone model Team Document review, paragraph-cited cybersecurity cases, risk assessments and signalling documentation STRIDE threat-model workflows run on every plan against a system you describe — 1 run a month on Free, 2 on Solo, 5 on Premium , which also adds the LINDDUN and TARA families, the rendered reports, and case law inside the run. Document-grounded workflows run on Team and Company. Every tier runs the same corpora as cited research inside your own AI client. Questions buyers ask first Do you serve the CLC/TS 50701 or EN 50126/50129 text? Not by default — railway standards are surfaced as clause maps with Ansvar-authored cross-references, addressable against your licensed copy. IEC 63452, the emerging international successor to TS 50701, is catalogued by status and scope only. Through the SIS-licensed standards module, any ISO, EN or SS standard SIS publishes can be licensed in and served cited verbatim inside your workflows; see /standards. Do you cover the EU rail directives, CSM-RA or the TSIs? Not yet as served text. The Rail Interoperability Directive (EU) 2016/797, the Rail Safety Directive (EU) 2016/798, CSM-RA (Reg (EU) 402/2013) and the CCS TSI are on the ingestion roadmap, and the clause map already cross-references them by CELEX so the mapping is ready. What is served today at article level is the horizontal stack — NIS2 and CER. We will not imply coverage we cannot ground. How is this different from the Industrial / OT page? Industrial / OT takes the plant operator's view — IEC 62443 zones, conduits and live ICS advisories. This lane is railway-specific: CLC/TS 50701's railway zone model and cybersecurity case, layered on the EN 50126/50129 signalling safety case. The IEC 62443 mapping is shared between both. Run it against your own systems Connect the AI client you already use and ask your first cited question — Free, Solo, Premium and Team are self-serve. Start free Setup guide Building rail compliance? It works today — we take on a few design partners per sector to tune it to your team. --- ## ISO standards through MCP — 27001, 27002, 42001 & more, licensed from SIS · Ansvar AI URL: https://ansvar.eu/standards Ansvar serves clause and control text of ISO/IEC 27001, 27002, 27005, 42001 and ISO/SAE 21434 through the gateway, licensed from SIS — cited, not paraphrased. ISO security standards · Licensed from SIS ISO/IEC 27001, 27002, 42001 and more, served and cited through your AI client. Ansvar serves the clause and control text of five ISO standards — the 27001/27002/27005 information-security family, 42001 for AI management, and ISO/SAE 21434 for road vehicles — directly through the MCP gateway, licensed from SIS, the Swedish Institute for Standards. Your AI client reasons from the control text itself, and every response is attributed to the source standard. Any standard SIS publishes can be licensed in on request. Request access How it works Available now · Licensed from SIS · An optional per-seat add-on subscription, from €99 per standard per month · Usage guide Licensed from SIS A licence agreement with the Swedish Institute for Standards SIS is the Swedish member of ISO and CEN, and the owner and copyright holder of the standards it publishes. Ansvar is a licensed supplier, not the owner: under a licence agreement with SIS, Ansvar reproduces selected parts of the licensed standards for its customers — so your AI client can cite the controls, not paraphrase them. Selected parts only — the complete standards are not reproduced here. Buy the full text from SIS at sis.se . As far as we know (checked July 2026), this makes Ansvar one of the first commercial services to put standards-body-licensed text directly into third-party AI assistants. Standards publishers have begun adding AI features inside their own platforms; this delivers the licensed text to the assistant your team already uses. How it works The control text, in your AI client's hands The standard should be active evidence inside the work — not a PDF beside it. No new client, no copy-paste: the standards arrive through the same gateway and the same citation contract your AI client already uses for law and frameworks. 01 Structured, machine-readable segments Each standard is held as clause- and control-level segments, not a flat PDF. Your AI client asks for the control it needs and gets that segment back — addressable, not a whole-document blob. 02 Delivered on demand, in the citation contract When your AI client needs a specific control or clause, the gateway returns the authoritative source text in the same citation envelope as every other Ansvar source — so your AI client reasons from the control, not a paraphrase. 03 Attributed to the source standard Every response carries the SIS attribution and the exact product designation. The control your AI client cites is traceable back to the standard it came from, with a link to buy the complete text from SIS. What your AI client receives — the citation envelope. The control text is delivered only to your connected AI client and left out of this public page: one served control, on the wire { "standard": "SS-EN ISO/IEC 27001:2023", "clause": "A.5.7", "title": "‹ control title ›", "text": "‹ control text served to your AI client ›", "_citation": { "publisher": "SIS — Swedish Institute for Standards", "license": "SIS reproduction licence", "source_url": "https://www.sis.se", "notice": "Reproduced with permission from SIS — buy the complete standard at sis.se" } } The full SIS copyright notice accompanies each clause served to logged-in customers: This text has been reproduced from Standard SS-EN ISO/IEC 27001:2023 with the due permission for Ansvar Systems AB from the Swedish Institute for Standards, which is the owner and copyright holder of the Standard and also sells the complete Standard at www.sis.se, Tel: +46 (0)8 555 523 10. One tier note: cross-referencing standards against your own policies and documents (upload, paragraph-level citations) is a Team-tier capability — the add-on itself serves standards text to any entitled seat holder. See pricing . What's covered Five standards live — any standard SIS publishes on request The standards security, AI-governance, and vehicle-cybersecurity programmes are built on, available today. Through SIS, Ansvar can serve any standard SIS publishes — ISO, European (EN), and Swedish (SS) — each clearing licensing and verification before it goes live. SS-EN ISO/IEC 27001:2023 Information security management systems — Requirements The requirements an ISMS is certified against. Your AI client cites the exact clause behind each obligation in a gap analysis or audit-readiness review. SS-EN ISO/IEC 27002:2022 Information security controls The control set — guidance for selecting and implementing the Annex A controls. Findings in a threat model or control mapping resolve to the control text they rely on. SS-EN ISO/IEC 27005:2024 Guidance on managing information security risks The risk process behind the ISMS — context, assessment, and treatment. Risk registers and assessments cite the guidance they follow instead of restating it from memory. SS-EN ISO/IEC 42001:2026 Artificial intelligence management system — Requirements The AI management system requirements — the anchor standard for AI-governance and AI Act readiness work. Findings cite the exact clause they rest on. SS-ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering Cybersecurity engineering for road vehicles across the lifecycle. TARA and type-approval work cites the engineering requirements directly. All five are live today. We can add any standard SIS publishes — ISO, European, or Swedish — that your programme needs; each one clears licensing and verification with SIS before we expose it. Tell us which standard → What's served, and what isn't Honest about the boundary The licence lets us serve the parts you cite, not hand over the book. We are explicit about the line — the same refusal discipline as the rest of the platform. What you get Selected clause and control text — the parts your workflow cites Served to your AI client through the gateway Each response attributed to the source standard, SIS-credited Cited inside gap analyses, threat models, and control mappings What it is not Not owned by Ansvar — SIS holds the copyright; Ansvar supplies it under licence Not a reproduction of the complete standard Not downloadable, printable, or redistributable Not a substitute for buying the standard from SIS Works with your agent Make your agent an ISO standards expert A free, open agent skill teaches your AI assistant to use the add-on properly: fetch the clauses a question needs, quote them verbatim with the SIS notice, disclose anything left unevaluated, and never answer standards questions from memory. The sequence: install the iso-standards-expert skill, connect the Ansvar Gateway connector, sign in (a free account is enough), and subscribe to the standards you need. Works in Claude, Claude Code, and other MCP-capable clients that accept standing instructions; without an add-on the skill runs in a clearly labelled SCF cross-reference lane. Agent skills guide GitHub repository FAQ The questions buyers ask first What's covered, what's served, how it's licensed, and when you can use it. Is this the complete ISO standard? Which standards are covered? Can I download or redistribute the text? How is it licensed — do you own the standards? When can I use it, and how is it sold? Cite ISO standards through your AI client The SIS-licensed standards module is an additional subscription. Tell us how your team would use SS-EN ISO/IEC 27001:2023 and its siblings, and we'll line up access. Request access Join the waitlist Licensed from SIS · An optional add-on subscription — talk to us. --- ## Use cases · Ansvar AI URL: https://ansvar.eu/use-cases Worked examples with real cited outputs — from a NIS2 gap analysis with the policy attached to a paragraph-cited document review. Use cases Real work, really cited . Each of these is a real run through the Ansvar gateway — the scenario, the cited answer, the source trail, and the downloadable artifact. Pick the one closest to your problem. Security · 8 citations NIS2 gap analysis with the policy attached — ISO 27001 via SIS in the loop Your CISO uploads the company's information-security policy and asks for a NIS2 Article 21 gap analysis. The server-enforced workflow pairs every Art. 21(2) measure… See the worked example → Security · 10 citations Gap analysis from your security policy Your CISO needs to know how today's information-security policy maps against ISO 27001, NIS2, and DORA — without buying three separate audits. See the worked example → Privacy · 12 citations GDPR Article 35 DPIA — full workflow run with structured report Your HR team wants to roll out 'PeopleFlow', a US SaaS that processes payroll, performance reviews, absence data including medical certificates, and runs a 'flight-… See the worked example → Procurement · 14 citations Swedish tender review under LOU You are bidding on a Swedish public-sector tender. Selection criteria, award criteria, and mandatory contract clauses must align with Lagen om offentlig upphandling… See the worked example → Security · 17 citations STRIDE threat model — quick narrative via search You are designing a new B2B authentication flow using OAuth 2.1 + OIDC + Keycloak. Your security architect wants a fast STRIDE narrative grounded in OWASP and STRID… See the worked example → AI governance · 7 citations EU AI Act high-risk classification — credit scoring You are building a credit-scoring AI for three EU markets. This run resolves the EU AI Act's harmonised high-risk classification from fetched article text — Article… See the worked example → Privacy · 6 citations Document review: a retention policy, paragraph-cited Your counsel or DPO needs a defensible review of the company's data-retention policy — every finding pinned to the exact paragraph it concerns, hash-anchored so it… See the worked example → Security · 5 citations ISO 27001 → NIST CSF 2.0 through the canonical control library An ISO/IEC 27001:2022-certified company must report security posture to its US parent on NIST CSF 2.0. Instead of maintaining a hand-built mapping spreadsheet, the… See the worked example → Privacy · 10 citations LINDDUN privacy threat model for a customer-data store You are adding a new customer-data warehouse. The privacy team wants a LINDDUN-go privacy threat model: linkability, identifiability, non-repudiation, detectability… See the worked example → Privacy · 10 citations What national rules apply to employee monitoring (NL, DE, FR)? Your team is rolling out a productivity-monitoring tool to staff in the Netherlands, Germany, and France. Each jurisdiction has its own works-council and labour-cod… See the worked example → The full sample deliverables Read a finished document, end to end. Five complete deliverables, published unsigned so you can judge the work exactly as it leaves the engine — every linked citation fetched during the run, every gap marked. All five are fictional samples and say so. Fictional sample · full deliverable Threat model — STRIDE, LLM-backed returns API Nine threats across four trust boundaries, control mapping, CRA duties — with unresolved rows held for review. Read the sample → Fictional sample · full deliverable DPIA — GDPR Art. 35, employee wellness app Screening, necessity, a seven-risk register, Art. 32 safeguards, and an honest Art. 36 prior-consultation call. Read the sample → Fictional sample · full deliverable Gap analysis — DORA / NIS2 incident response Requirements mapped to evidence, gaps flagged with regulatory basis, owners and remediation sequenced. Read the sample → Fictional sample · full deliverable AI Act readiness — classification & obligations Role test, high-risk classification, and the article-level obligation register that follows from it. Read the sample → Fictional sample · full deliverable Deferral dossier — the vulnerability you can't patch CRA-era deferral records over a scanner export: engine scores, credited controls, live-fetched pin-cites, the investment plan — and a VEX back into Dependency-Track. Read the sample → Free templates & tools Take something with you. Free template NIS2 gap analysis template The Art. 21 measure list as a working register — XLSX and PDF, no sign-up. Download → Free template DPIA template Article 35 screening with WP248 criteria, processing description, risk register, Art. 36 check. Download → Free interactive tool EU AI Act high-risk checker Six questions, client-side only — see which way the cited provisions point for your system. Run the checker → Run one of these on your own data Bring your own documents and scope. We run it end-to-end — every finding cited and validated by the expert who delivers it. Contact us --- ## Sample threat model — STRIDE example, full deliverable · Ansvar AI URL: https://ansvar.eu/services/sample-threat-model A complete sample threat model for a fictional LLM-backed returns API — STRIDE register, fetched citations, control mapping, CRA duties, honest gaps. Services Sample threat model — STRIDE, LLM-backed returns API Acme Returns AB · sample deliverable · fictional system · produced with the same engine and format as a paid engagement Document TM-ACME-2026-001 · Scope: single application · Method: STRIDE over DFD · Status: sample — senior review pending This is a fictional sample. Acme and its returns API don't exist — the system is invented so we can publish a complete deliverable without exposing a client. It was produced with the same gateway engine, the same sources, and the same format as a paid engagement. A sample has no client and nothing to certify, so the sign-off block in §7 shows the format and stays blank by design — on a paid engagement the reviewing practitioner signs there. Every linked citation is a real row fetched from the gateway's corpora; the risk scores and the system itself illustrate the format. Section 1 Executive summary The Acme Returns API fronts an LLM-backed support agent that answers return questions, looks up orders, and — within limits — issues refunds. A STRIDE walk over its data-flow diagram produced 9 threats across four trust boundaries. Two stand out: prompt injection through the customer channel (TM-03) and the agent calling the refund tool beyond its intended scope (TM-08) — together they turn a support conversation into an unaudited financial action. First moves: deny-by-default per-tool RBAC with human approval on refunds, guardrail isolation of privileged instructions, and per-request context isolation so one tenant's PII never reaches another's session. 6 of 9 register rows carry citations; the linked ones were fetched live from the gateway's corpora during the run. Two rows (TM-05, TM-07) matched no source row and ship as marked analyst drafts; one row (TM-06) lists candidate provisions but its regulatory basis is unresolved. None of the three is papered over. Section 2 System & trust boundaries Acme Returns AB (fictional) runs a customer-support returns flow: a public chat channel where an LLM agent handles return requests end-to-end. Components: the returns API edge (authentication, session handling), the LLM support agent (system instructions plus per-request retrieved context), two tools the agent can call (order lookup and refund), and a multi-tenant customer & order store holding PII. Data-flow diagram with the four trust boundaries. Text version: Show the text form [Customer / attacker] | chat + REST over HTTPS <- B1: internet -> edge [Returns API edge] (OAuth 2.0 access token, session) | prompt assembly <- B2: untrusted input -> model context [LLM support agent] (system instructions + customer message + retrieved context) | tool calls <- B3: model output -> privileged action [Order lookup] ---- [Refund tool] (financial action) | queries <- B4: tenant isolation [(Customer & order store -- multi-tenant, PII)] B1 Internet → API edge . Anonymous internet traffic meets the authenticated API surface (OAuth 2.0 tokens, sessions). B2 Untrusted input → model context . Customer text is assembled into the same context window as privileged system instructions. B3 Model output → privileged action . Agent output selects and parameterises tool calls — including the refund tool, a financial action. B4 Tenant isolation . Retrieval crosses into a multi-tenant store holding PII and order history. Section 3 Threat register One row per threat, walked per element and boundary. Severity and likelihood are analyst-assigned and would be confirmed or corrected in senior review. ID STRIDE Threat & boundary Severity Mitigation Citations Regulation Status TM-01 Spoofing Stolen or replayed OAuth access token impersonates a customer at the API edge B1 High ( Possible ) Short-lived, sender-bound access tokens; encrypted token storage; monitor for compromised service accounts STRIDE-API-OAUTH-001 — cited TM-02 Spoofing Session credential forged or predicted via a weak random number generator; account takeover B1 High ( Possible ) CSPRNG-backed session identifiers; new session token on authentication (ASVS V3.2.1); randomness verified per WSTG STRIDE-CRYPTO-RANDOM-001 · CAPEC-196 · OWASP ASVS V3.2.1 · OWASP WSTG 4.2 — session mgmt schema — cited TM-03 Tampering Prompt injection via customer message overrides system instructions B2 High ( Likely ) Input/output guardrail + privileged-instruction isolation OWASP LLM01 · CWE-77 EU AI Act Art. 15 cited TM-04 Tampering Returns-flow step skipping: the final refund-confirmation request is submitted directly, bypassing the eligibility checks of earlier steps B1 → B3 Medium ( Possible ) Server-side state machine over the returns flow; every stage transition validated server-side CAPEC-140 — cited TM-05 Repudiation A refund issued through the agent cannot later be attributed to a specific customer instruction and agent decision B3 Medium ( Possible ) Tamper-evident audit log of prompt, tool call, parameters, and approval — retained per policy — — analyst draft — no fetched source; held for senior review TM-06 Information disclosure Context-window leakage exposes another tenant's PII B2 / B4 High ( Possible ) Per-request context isolation + retrieval scoping CWE-200 NIS2 Art. 21 / GDPR Art. 32 (candidates) flagged — regulatory_basis_unresolved TM-07 Denial of service Unbounded chat traffic drives model-call spend and saturates the returns queue — no per-client budget B1 / B2 Medium ( Likely ) Per-client rate limits; token budgets; queue backpressure — — analyst draft — no fetched source; held for senior review TM-08 Elevation of privilege Agent calls the refund tool beyond intended scope (tool-permission escalation) B3 Critical ( Possible ) Per-tool RBAC, deny-by-default + human-in-loop on financial actions ATT&CK T1548 · CWE-269 DORA Art. 6 cited TM-09 Elevation of privilege Authentication bypass on the internal tool API reaches the refund endpoint without passing the agent's controls B3 High ( Possible ) Authenticate every internal hop; step-up authentication before privilege-changing actions (see §4, IAC-16.3) CAPEC-115 — cited Linked citations are rows the gateway returned during this run, with source URL, publisher, and license preserved. Unlinked identifiers (OWASP LLM01, CWE-77, ATT&CK T1548, CWE-269, CWE-200 and the regulation references) carry over from the previously published sample register for this system. Rows with no matching source say so instead of carrying an invented reference. Section 4 Control mapping Register rows mapped to controls from the gateway's security-controls catalog. Fragments are quoted as fetched. Control Maps to Fetched description AAT-29.2 — Agent least-privilege scoping TM-08 “ Confines each agent to the minimum permissions, assets, services, and network reach… ” IAC-16.3 — Step-up authentication for privilege changes TM-08, TM-09 “ Asking to alter a privilege level triggers an extra authentication check before… ” IAC-20 — Least-privilege logical access TM-08, TM-09 “ …each task needs, keeping every grant aligned with the least-privilege principle. ” IAC-21 — Least privilege for processes TM-01 “ Access is held to the minimum required, permitting only the processes needed… ” Section 5 Product-security duties (CRA) If the returns agent ships to customers as a product with digital elements — for example as an embeddable support widget — the Cyber Resilience Act's essential cybersecurity requirements attach to it. The gateway returned the operative annex: Cyber Resilience Act, Annex I — Reg (EU) 2024/2847 — “ESSENTIAL CYBERSECURITY REQUIREMENTS — Part I Cybersecurity requirements relating to the properties of products with digital elements” (Publications Office of the European Union). In a paid engagement each register row is mapped to the specific Annex I point it engages. This sample stops at the annex level: the fetched excerpt covers the Part I heading, not the itemised list, and we don't cite deeper than what was fetched. Applicability is a scoping input, not a conclusion — whether Acme's deployment is a product placed on the market, rather than a pure service, decides if the CRA attaches at all. A real engagement records that determination; here it is marked open. Section 6 Method note STRIDE over the DFD. All six categories walked per element and boundary of the §2 diagram; classic categories extended for the LLM surface — Tampering to prompt injection, Elevation of privilege to tool-permission escalation, Information disclosure to context-window leakage. Sources fetched through the Ansvar gateway. The STRIDE pattern library, CAPEC, OWASP (ASVS 4.0.3, WSTG 4.2), the security-controls catalog, and the Cyber Resilience Act text — every linked citation is a row the gateway returned during the run, with source URL, publisher, and license preserved. Nothing is cited from model recall. Refusal discipline. No fetched source → the row says so (TM-05, TM-07). Regulatory basis not confirmable at article level → the row is flagged regulatory_basis_unresolved (TM-06). Gaps are marked, never filled with plausible text. What a paid engagement adds. Your real architecture and a scoping call; enrichment across ATT&CK, CWE, and your sector's regulations; and a named senior reviewer who confirms or corrects every row before it ships. Section 7 Sign-off Senior review: [shown for format — fictional sample, nothing to certify] Reviewer: [named reviewer — OSCP / CISSP / AI red team] Date: [—] A paid engagement ships only after the named reviewer has validated every row and signed here. This sample is published unsigned, on purpose, so you can read the document exactly as it leaves the engine. Want this for a real system? Scope a threat model → --- ## Sample DPIA — GDPR Article 35 example, full deliverable · Ansvar AI URL: https://ansvar.eu/services/sample-dpia A complete sample GDPR Article 35 DPIA for a fictional employer wellness app — screening, risk register, Article 36 determination, honest gaps. Services Sample DPIA — GDPR Article 35, employee wellness app Nordvind Care AB · sample deliverable · fictional client · produced with the same engine and format as a paid engagement Document DPIA-NRDV-2026-001 · Scope: one processing operation (workplace-wellness app) · Method: GDPR Art. 35(7) structure · Status: sample — senior review pending This is a fictional sample. Nordvind Care AB and its wellness app don't exist — the client is invented so we can publish a complete DPIA without exposing a real one. It was produced with the same gateway engine, the same sources, and the same format as a paid engagement, where it would ship signed by the reviewing practitioner. A sample has no client and nothing to certify, so the sign-off block in §8 shows the format and stays blank by design. Every regulation quote is verbatim from a row fetched from the gateway's corpora; the risk scores and the client itself illustrate the format. Section 1 Executive summary Nordvind Care AB, a Swedish employer of 1,200, plans a workplace-wellness app: activity tracking plus self-reported stress and sleep, a monthly wellbeing score visible to HR, and optional GP teleconsult booking, run by an EU-hosted vendor as processor. Is a DPIA required? Yes. The fetched Art. 35(3)(b) text makes a DPIA required for “processing on a large scale of special categories of data referred to in Article 9(1)”, and self-reported stress and sleep records scored monthly for a whole workforce are data concerning health (§3 walks both limbs of that determination, including the honest part: “large scale” is an analyst call, not a fetched threshold). Headline risks: individual wellbeing scores reaching HR (DR-01) — the single design decision this DPIA reverses — consent that isn't freely given inside an employment relationship (DR-03), and processor re-use of the data beyond instructions (DR-04, held open pending the contract review). With the §4 mitigations applied, no register row keeps a high residual risk, so under the fetched Art. 36(1) test this DPIA does not trigger prior consultation of the supervisory authority — a conditional verdict, reasoned in §6. 4 of 7 register rows carry fetched citations. Two rows (DR-05, DR-06) matched no source row and ship as marked analyst drafts; one row (DR-04) rests partly on a provision (Art. 28) that was not fetched this run and is flagged unresolved. None of the three is papered over. Section 2 Processing description, data flows & necessity The fetched Art. 35(7) sets the minimum content of this document: “(a) a systematic description of the envisaged processing operations and the purposes of the processing […]”, “(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes”, “(c) an assessment of the risks to the rights and freedoms of data subjects […]”, and “(d) the measures envisaged to address the risks […]” (each quoted to its first clause; the full points continue in the linked text). This section covers (a) and (b); §4 and §5 cover (c) and (d). Processing flows in the mitigated design — HR receives aggregated cohort scores only. Text version: Show the text form [Employee (1 of 1,200)] | activity + self-reported stress/sleep <- explicit consent, Art. 9(2)(a) [Wellness app backend] (processor: app vendor, EU-hosted) | writes [(Special-category store -- activity, stress, sleep; health data, Art. 9(1))] | pseudonymised records [Wellbeing scoring] (monthly score per employee) |--> monthly score, personal feedback -> back to the employee only |--> aggregated cohort scores ONLY -> [HR wellbeing dashboard] (controller) [GP teleconsult booking] (opt-in; booking metadata kept out of HR-visible data) DS Data subjects — 1,200 employees . Enrolment is optional. The app collects activity data plus self-reported stress and sleep, and computes a monthly wellbeing score. C Controller — Nordvind Care AB (employer) . Determines purposes and means. After the §2 redesign, HR receives aggregated cohort scores only, never individual scores. P Processor — the app vendor (EU-hosted) . Runs ingestion, storage, and scoring on documented instructions. The special-category store sits on the vendor's side. G GP teleconsult service (opt-in) . Receives booking requests only from employees who opt in. Whether it acts as a separate controller for the consultation itself is recorded as an open scoping question (analyst note), not settled here. Necessity & proportionality — three purposes, three calls. Each verdict below is an analyst call: Art. 35(7)(b) requires the test, but the fetched text does not decide it for any given system. Senior review confirms or corrects these on a paid engagement. Purpose Necessary? Proportionate? P1 — employer insight into workforce wellbeing (HR dashboard) At aggregate level only. Individual-level HR visibility fails the test: aggregated cohort scores achieve the stated purpose without exposing any one employee's health state. (analyst call) Only in the redesigned form — aggregated, minimum cohort size. The original per-employee HR view is the design this DPIA reverses. (analyst call) P2 — personal wellbeing feedback to the employee Yes — the monthly score is the app's core function for the person using it. (analyst call) Yes, provided the score stays between the employee and the processor. (analyst call) P3 — optional GP teleconsult booking Only for employees who opt in, at the moment of booking. (analyst call) Yes, if booking data is segregated from wellbeing scoring and from anything HR-visible (DR-06). (analyst call) Section 3 Screening — is a DPIA required? The fetched Art. 35(1) sets the general test: “Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data.” Art. 35(3) then names cases where a DPIA “shall in particular be required”, including “(b) processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10”. Two limbs to establish: Special categories. The fetched Art. 9(1) prohibits, absent an exception, processing of personal data including “data concerning health”. Classifying self-reported stress and sleep records — collected to compute a wellbeing score — as data concerning health is an interpretive step (analyst call), but a short one: the data exists to describe the employee's health state. A fetched CJEU row points the same way for the employment context: ECLI:EU:C:2023:1022 , whose case metadata reads “special categories of data – Data concerning health – Assessment of an employee's working capacity – Health insurance medical service processing data”. Only the case metadata was fetched in this run — a paid engagement retrieves and reads the decision itself before relying on its reasoning. Large scale. The fetched text sets no numeric threshold, so this is an analyst determination: 1,200 data subjects, continuous activity collection, systematic monthly scoring, the entire workforce of the controller — we conclude large scale. If a reviewer rejected that call, the Art. 35(1) general test would still point the same way for health data processed inside an employment power asymmetry (also an analyst call). Supervisory guidance (the WP248 criteria) is the standard screening method here, but no fetched row carried it in this run, so it is named as analyst method and not relied on. Swedish angle. The Swedish corpus returned the Swedish-language GDPR text, served with EUR-Lex source links (the regulation applies directly and is not an SFS statute): Art. 35(4) — “Tillsynsmyndigheten ska upprätta och offentliggöra en förteckning över det slags behandlingsverksamheter som omfattas av kravet på en konsekvensbedömning avseende dataskydd i enlighet med punkt 1” — and Art. 57(1)(k) (“Upprätta och föra en förteckning när det gäller kravet på en konsekvensbedömning avseende dataskydd enligt artikel 35.4”), which together ground that IMY, the Swedish supervisory authority, must maintain a published list of processing operations requiring a DPIA. The list itself was not fetched in this run — checking this processing against IMY's current list is recorded as an open verification step for the paid engagement, not assumed. Lawful basis for the health data. Of the Art. 9(2) exceptions fetched, the candidate is “(a) the data subject has given explicit consent to the processing of those personal data for one or more specified purposes”. The occupational-medicine exception “(h) … preventive or occupational medicine, for the assessment of the working capacity of the employee …” does not fit (analyst call): an HR-visible wellbeing dashboard is not occupational medicine delivered under the professional-secrecy conditions of Art. 9(3). That leaves explicit consent — and consent inside an employment relationship carries a freely-given problem this DPIA treats as a risk in its own right (DR-03); the imbalance doctrine itself was not fetched this run and is marked as an analyst premise. Section 4 Risk register — risks to data subjects One row per risk to the rights and freedoms of the employees (Art. 35(7)(c)) — not risks to Nordvind. Severity, likelihood, and residual ratings are analyst-assigned and would be confirmed or corrected in senior review. ID Risk to data subjects Initial Mitigation Residual Citations Status DR-01 Individual wellbeing scores visible to HR let managers infer an employee's health state and feed it into assignment, promotion, or retention decisions High ( Likely ) Redesign before launch: HR sees aggregated cohort scores only; individual scores stay between the employee and the app Medium GDPR Art. 9(1) — health data cited DR-02 Breach or unauthorised access of the special-category store (activity, stress, sleep records for 1,200 employees) High ( Possible ) Encryption in transit and at rest, pseudonymised scoring records (Art. 32(1)(a)); access on documented need only; regular testing of the measures (Art. 32(1)(d)) Medium GDPR Art. 32 cited DR-03 Consent is not freely given in the employment relationship — employees feel pressure to enrol, and the Art. 9(2)(a) basis fails High ( Possible ) Enrolment strictly optional with no benefit tied to participation; who declined is invisible to managers; consent withdrawable in-app with deletion Medium GDPR Art. 9(2)(a) — explicit consent cited DR-04 The vendor (processor) re-uses wellness data for its own purposes — model training, product analytics — beyond Nordvind's instructions High ( Possible ) Instruction-bound processing per Art. 32(4); processor-contract terms (Art. 28, candidate) to be verified against the signed DPA — open item Medium (provisional) GDPR Art. 32(4) · GDPR Art. 28 (candidate) flagged — regulatory_basis_unresolved DR-05 Re-identification inside aggregated cohort scores: in a small team, a "cohort" score is effectively one person's health data Medium ( Likely ) Minimum cohort size with small-cell suppression; the threshold choice documented and revisited at review Low — analyst draft — no fetched source; held for senior review DR-06 Teleconsult booking metadata reveals that a named employee sought GP contact — a health inference from the booking event alone Medium ( Possible ) Booking events segregated on the teleconsult side; never joined to wellbeing scoring or any HR-visible dataset Low — analyst draft — no fetched source; held for senior review DR-07 Function creep: wellbeing scores get reused for sickness-absence management or performance evaluation — a new purpose without a new basis High ( Possible ) Purpose limitation enforced in access design; any new purpose triggers a DPIA review before the processing changes (Art. 35(11)) Medium GDPR Art. 35(11) cited Linked citations are rows the gateway returned during this run, with source URL, publisher, and license preserved. The one unlinked identifier (GDPR Art. 28 on DR-04) is a named candidate that was not fetched — the row is flagged, not dressed up. Rows with no matching source say so instead of carrying an invented reference. Section 5 Safeguards & Art. 32 measures The fetched Art. 32(1) requires that “the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk”, naming: “(a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” Applied here (Art. 35(7)(d) measures; each mapping is an analyst assignment): Art. 32(1)(a). Encryption in transit and at rest for the special-category store; wellbeing-scoring records pseudonymised so the scoring path never handles named employees (DR-02). Art. 32(1)(b). Access to individual records restricted to the employee and the processor's operational need — no HR path to individual data exists in the redesigned architecture (DR-01, DR-07). Art. 32(1)(c). Vendor backup and restore for the wellbeing store, tested, so employees' data survives a technical incident intact. Art. 32(1)(d). Scheduled testing of the measures above, with the minimum-cohort-size suppression (DR-05) included in the test scope. Art. 32(4). “The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law” — the fetched anchor for keeping the vendor instruction-bound (DR-04), pending the Art. 28 contract review flagged in §4. Art. 32(2), also fetched, directs the risk weighing to “accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed” — the lens used for DR-02's rating. Section 6 Prior consultation — Art. 36 determination The fetched Art. 36(1) reads: “The controller shall consult the supervisory authority prior to processing where a data protection impact assessment under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk.” The operative question is therefore whether high risk remains once the controller's mitigations are counted — the residual-risk reading. (That reading is standard supervisory practice, but the guidance stating it was not fetched this run, so the interpretive step is marked as analyst method.) Applied to the §4 register: every high initial risk (DR-01, DR-02, DR-03, DR-04, DR-07) is reduced to a medium residual by measures Nordvind can actually take — chiefly the aggregated-only HR view, the consent design, and the Art. 32 measures in §5. No row ends at a high residual. Verdict: prior consultation under Art. 36(1) is not required (analyst call). Two honest conditions attach: DR-04's residual is provisional until the processor-contract review closes, and the ratings themselves are unreviewed sample assignments — if senior review raised any residual back to high, the verdict flips and the Art. 36(2) machinery follows (“the supervisory authority shall, within period of up to eight weeks of receipt of the request for consultation, provide written advice to the controller”, extendable by six weeks — quoted as fetched). If consultation were triggered, the fetched Art. 36(3) already lists what Nordvind would hand over — responsibilities of controller and processors, purposes and means, safeguards, DPO contact details, and “the data protection impact assessment provided for in Article 35”: this document. Either way, Art. 35(11) applies going forward: “Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations” — DR-07's function-creep trigger is wired to exactly that duty. Section 7 Method note & refusal discipline Structure per Art. 35(7). Sections 2–5 map one-to-one onto the fetched minimum content (a)–(d); §6 runs the Art. 36 gate on the outcome. Sources fetched through the Ansvar gateway. GDPR Articles 9, 32, 35, and 36 as full-text lookups; an EU-wide search on the DPIA trigger; a Swedish-corpus search (riksdagen-published GDPR text); a CJEU case-law row; and an authority-guidance search. Every quote in this document is verbatim from a fetched row, with source URL, publisher, and license preserved. Nothing is cited from model recall. Refusal discipline — guidance. The authority-guidance search for prior-consultation material returned four rows, all off-topic for this processing (AI Act prohibited-practices guidelines, the GPAI Code of Practice, and two vehicle-type-approval documents under UN R155/R156). No authority-guidance citation is carried in this document; the gap is recorded rather than filled. Refusal discipline — searches. From the EU-wide search, three of six rows were discarded as off-topic (Reg (EU) 2019/1020 recital 52 on market surveillance, Reg (EU) 167/2013 Art. 7 on tractor approval, REACH Art. 14), and one further row — EDPB connected-vehicles guidance carrying an Art. 9 explicit-consent fragment — was excluded as off-domain; Art. 9(2)(a) is cited from the fetched article text directly instead. From the Swedish search, two of five rows are used (Art. 35(4) and Art. 57(1)(k)); three were excluded as off-topic (Prop. 2022/23:131 on welfare technology in elderly care, SFS 1973:1084 on land survey, Prop. 2022/23:41 on tax-agency data analysis). Marked analyst judgment. The large-scale determination, the health-data classification, the necessity table, all severity/likelihood/residual ratings, the Art. 9(2)(h) exclusion, and the residual-risk reading of Art. 36(1) are analyst calls, marked in place. The WP248 screening criteria were not fetched and are not relied on. What a paid engagement adds. Your real processing records and a scoping call; verification against IMY's published DPIA list; the Art. 28 processor-contract review that closes DR-04; DPO advice per Art. 35(2) and, where appropriate, the views of data subjects per Art. 35(9); and a named senior reviewer who confirms or corrects every call before it ships. Section 8 Sign-off Senior review: [shown for format — fictional sample, nothing to certify] Reviewer: [named reviewer — CIPP/E / data-protection lead] Date: [—] A paid engagement ships only after the named reviewer has validated every call and signed here. This sample is published unsigned, on purpose, so you can read the document exactly as it leaves the engine. Want this for a real processing operation? Scope a DPIA → Download the blank DPIA template (free XLSX) → --- ## Sample NIS2 gap analysis — Article 21 example, full deliverable · Ansvar AI URL: https://ansvar.eu/services/sample-gap-analysis A complete sample NIS2 gap analysis for a fictional logistics SaaS — Article 21 register, incident-reporting readiness, remediation roadmap. Services Sample NIS2 gap analysis — Article 21, logistics SaaS Baltika Freight Systems OÜ · sample deliverable · fictional client · produced with the same engine and format as a paid engagement Document GAP-BLTK-2026-001 · Scope: NIS2 Art. 21(2)(a)–(j) + Art. 23 · Method: requirement-by-requirement gap register · Status: sample — senior review pending This is a fictional sample. Baltika Freight Systems OÜ doesn't exist — the client, its control set, and every "current state" in the register are invented so we can publish a complete deliverable without exposing a real one. It was produced with the same gateway engine, the same sources, and the same format as a paid engagement, and in a paid engagement it would ship signed by the reviewing practitioner. A sample has no client and nothing to certify, so the sign-off block in §7 shows the format and stays blank by design. The regulatory requirements are not fiction — every quoted provision and linked citation is a real row fetched from the gateway's corpora during the run. Section 1 Executive summary Baltika Freight Systems OÜ, a 90-person Estonian logistics-software SaaS classified by its management as an important entity under NIS2, runs a partial ISO 27001-style control set. Tested against the ten risk-management families of NIS2 Art. 21(2)(a)–(j), that control set shows material gaps in 4 families, partial coverage in 5 , and full coverage in one (multi-factor authentication, point (j)). The sharpest exposure is not a control at all: the incident process — staff email the CTO — cannot meet a single Art. 23 reporting deadline (§4). First moves: stand up incident handling with the 24-hour / 72-hour / one-month reporting path (R1), put the ~30 unmanaged suppliers under a supply-chain security programme (R2), and establish an effectiveness-assessment cycle so the control set stops being paperwork (R3). Every register row quotes its requirement verbatim from the Art. 21 text fetched during the run; 7 of 10 rows also map to fetched rows from the gateway's security-controls catalog, and the three that matched no fetched control say so instead of carrying an invented reference. The technical implementing regulation under Art. 21(5) was searched and not returned — it is named as out of scope in §6, not silently included. Section 2 Scope & method Baltika Freight Systems OÜ (fictional) sells freight booking and customs-documentation software to forwarders and carriers, with 90 staff and production hosted on a single cloud provider. The engagement's scoping input, provided by the client and not verified here: Baltika is an important entity under NIS2 as a transport-adjacent digital provider. A paid engagement records the classification analysis; this sample takes it as given. Frameworks in scope: NIS2 Art. 21(2)(a)–(j) — the ten cybersecurity risk-management measure families — and Art. 23 reporting obligations, both fetched from the gateway ( Art. 21 , Art. 23 , eur-lex.europa.eu), tested against the client's existing control set. The technical implementing regulation under Art. 21(5) was searched in the same run; the gateway did not return it, so its requirements are not part of the tested baseline (§6). The one on-topic row that search did return — the Commission's guidelines on the application of Article 4(1) and (2) (European Commission, DG CONNECT) — restates that the Art. 21(2) measures include the specific requirements listed in points (a) to (j), which is the list this register walks. Evidence basis: in a paid engagement, document review and control interviews — policy suites, runbooks, contracts, and the people who operate them. In this sample the "current state" column derives from the fictional client description instead; it is marked as fiction so the format, not the client, is what you are evaluating. Scope and obligation map — which layer binds which. Text version: Show the text form [NIS2 Directive (EU) 2022/2555] Art. 21(2) risk-management measures -- ten families (a)-(j) Art. 23 reporting obligations -- 24 h / 72 h / 1 month | binds (Art. 21(1)) v [Baltika Freight Systems OÜ -- important entity (client-provided classification)] | tested against [Existing control set -- partial ISO 27001-style] -> gap register (§3) [Incident process -- "email the CTO"] -> reporting readiness (§4) [Art. 21(5) implementing acts -- technical & methodological requirements] searched this run; not returned by the gateway; not cited (§6) Section 3 Gap register — Art. 21(2)(a)–(j) One row per measure family. The requirement column quotes the fetched Art. 21(2) text verbatim; the current-state column is the fictional client; verdicts are analyst-assigned and would be confirmed or corrected in senior review. Point Requirement — Art. 21(2), fetched text Current state at Baltika (fictional) Verdict Remediation Citations Control mapping (a) “ policies on risk analysis and information system security ” Annual risk workshop feeding a spreadsheet register; no approved information-security policy suite; no criteria for when to re-assess. Partial Approve a policy suite covering risk analysis and information-system security; define re-assessment triggers (R6). NIS2 Art. 21(2) (a) · RSK-01 — Risk management program · RSK-04.3 — Risk-assessment trigger criteria cited (b) “ incident handling ” Ad hoc — staff email the CTO, who decides case by case. No classification, no runbook, no on-call rota. Gap Stand up an incident-response plan, severity classes, and an on-call rota; build the Art. 23 reporting path (§4, R1). NIS2 Art. 21(2) (b) · IRO-04 — Maintained incident response plan · IRO-07 — Integrated incident response team cited (c) “ business continuity, such as backup management and disaster recovery, and crisis management ” Nightly database backups to a second region; restores never rehearsed; no disaster-recovery or crisis-management plan. Partial Rehearse restores on a schedule; write and exercise disaster-recovery and crisis-management plans (R5). NIS2 Art. 21(2) (c) · IRO-02.4 — Incident classes and mission-continuity actions · IRO-06.1 — Response-test coordination with related plans cited (d) “ supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers ” Roughly 30 cloud and data suppliers, no register; contracts on supplier paper with no security clauses; customs-data integrations rely on provider defaults. Gap Build a supplier register with security requirements per contract; remediate known supplier weaknesses; reduce single-supplier concentration (R2). NIS2 Art. 21(2) (d) · TPM-01 — Third-party management program · TPM-03.3 — Supply-chain weakness remediation · TPM-06 — Third-party personnel security · TDA-03.1 — Diversify security technology suppliers cited (e) “ security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure ” CI pipeline runs dependency scanning on the booking platform; no vulnerability-disclosure channel; new tooling is bought without a security check. Partial Publish a vulnerability-disclosure channel; add a pre-acquisition security assessment step (R7). NIS2 Art. 21(2) (e) · TPM-04.1 — Pre-acquisition risk assessment cited — Fetched control covers the acquisition limb; no fetched row on vulnerability handling and disclosure. (f) “ policies and procedures to assess the effectiveness of cybersecurity risk-management measures ” The ISO 27001-style control set was adopted in 2024 and has not been tested since; no internal audit function. Gap Establish a recurring effectiveness-assessment cycle — internal audit or equivalent — reporting to management (R3). NIS2 Art. 21(2) (f) · CPL-02.1 — Internal audit function cited (g) “ basic cyber hygiene practices and cybersecurity training ” A security-awareness deck at onboarding; nothing role-specific, no exercises. Partial Add role-specific training and simulated-incident exercises on top of the onboarding deck (R9). NIS2 Art. 21(2) (g) · IRO-05.1 — Simulated-event response training cited — Fetched control covers the training limb; no fetched row on baseline hygiene practices. (h) “ policies and procedures regarding the use of cryptography and, where appropriate, encryption ” TLS on all public endpoints; full-disk encryption on most laptops; no documented cryptography policy — key handling varies per engineer. Partial Write a cryptography and encryption policy; standardise key handling (R8). NIS2 Art. 21(2) (h) analyst draft — no fetched control maps; held for senior review (i) “ human resources security, access control policies and asset management ” Joiner/leaver checklist exists, but the operations team shares one admin account for the customs-docs backend and there is no asset register. Gap Retire the shared admin account for per-person credentials; stand up an asset register; formalise HR security steps (R4). NIS2 Art. 21(2) (i) analyst draft — no fetched control maps; held for senior review (j) “ the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate ” Company-wide SSO with MFA enforced on all staff and administrator logins; internal comms on an enterprise messaging platform. Compliant Maintain; review emergency-communication arrangements at the next policy cycle. NIS2 Art. 21(2) (j) analyst draft — no fetched control maps; held for senior review Every requirement is quoted from the Art. 21 row the gateway returned during this run (source: eur-lex.europa.eu, license EUR-Lex-Decision-2011-833). Control links are rows from the gateway's security-controls catalog fetched in the same run. Rows (h), (i), and (j) matched no fetched control and say so instead of carrying an invented reference; §6 names the fetched control rows that were considered and not used. Section 4 Incident-reporting readiness — Art. 23 Art. 23 puts significant incidents on a clock: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report not later than one month after that notification — with an intermediate report on request and recipient notification alongside. Baltika's current process is an email to the CTO. Tested obligation by obligation against the fetched text: Obligation Fetched requirement Baltika today (fictional) Ready? Art. 23(3) Significance test An incident is significant if it “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned” or considerable material or non-material damage to others. No criteria — the CTO decides ad hoc whether something counts. No Art. 23(4)(a) Early warning “without undue delay and in any event within 24 hours of becoming aware” — indicating suspected unlawful or malicious cause and possible cross-border impact, where applicable. No CSIRT contact path, no on-call rota, no 24-hour clock. No Art. 23(4)(b) Incident notification “without undue delay and in any event within 72 hours” — updating the early warning with “an initial assessment of the significant incident, including its severity and impact” and, where available, indicators of compromise. No severity/impact assessment capability; indicators of compromise are not collected. No Art. 23(4)(c) Intermediate report Relevant status updates on the request of the CSIRT or competent authority. No owner who could produce one. No Art. 23(4)(d) Final report Not later than one month after the incident notification: a detailed description including severity and impact, the type of threat or root cause, applied and ongoing mitigation measures, and any cross-border impact. None of these facts is captured by the current email thread. No Art. 23(1)–(2) Recipient notification Notify recipients of services of significant incidents likely to adversely affect service provision, and communicate measures or remedies recipients can take against significant cyber threats. No customer-notification procedure exists. No All rows cite NIS2 Art. 23 as fetched during the run (eur-lex.europa.eu); quoted fragments are verbatim. Verdict: not ready . The email-the-CTO process has no significance test, no channel to the CSIRT or competent authority, and produces none of the artefacts the deadlines demand — a significant incident today would put Baltika in breach of Art. 23(4) within 24 hours of someone noticing. Which national authority receives Baltika's notifications is a Member-State determination a paid engagement records; it is held open here. This is roadmap item R1, ahead of every control gap in §3. Section 5 Remediation roadmap Priority-ordered from the register: the clocked legal obligation first, then the largest unmanaged surfaces, then policy and hygiene work. Effort classes only — Small is policy or configuration work owned by one team, Medium is a cross-team capability build, Large would be structural change (none is required here). A sample carries no cost or calendar estimates; a paid engagement schedules the roadmap with the client. Priority Action Addresses Effort class R1 Stand up incident handling and the Art. 23 reporting path: severity classes per Art. 23(3), the 24-hour / 72-hour / one-month artefacts, an on-call rota, and the CSIRT contact route. (b) + Art. 23 Medium R2 Supplier register with security requirements in each contract; remediation loop for known supplier weaknesses; reduce single-supplier concentration. (d) Medium R3 Recurring effectiveness-assessment cycle (internal audit or equivalent) reporting to management. (f) Medium R4 Retire the shared admin account for per-person credentials; stand up an asset register. (i) Small R5 Scheduled restore rehearsals; disaster-recovery and crisis-management plans, exercised. (c) Medium R6 Approved information-security policy suite with defined risk re-assessment triggers. (a) Small R7 Public vulnerability-disclosure channel; pre-acquisition security assessment step. (e) Small R8 Cryptography and encryption policy; standardised key handling. (h) Small R9 Role-specific training and simulated-incident exercises beyond the onboarding deck. (g) Small Section 6 Method note & refusal discipline Requirements fetched through the Ansvar gateway. NIS2 Art. 21 and Art. 23 as provision lookups (eur-lex.europa.eu rows with source URL, publisher, and license preserved), plus three security-controls catalog searches — governance, incident & continuity, supply chain — totalling sixteen control rows. Nothing is cited from model recall. The implementing-regulation search failed honestly. The search for the NIS2 technical implementing regulation returned one on-topic row — the Commission's Article 4 application guidelines, cited in §2 — and five off-topic rows, all excluded: Regulation (EC) No 1907/2006 Art. 41; an EIOPA guidance row on rules under DORA for ICT and third-party risk management; Regulation (EU) No 167/2013 Art. 43; Regulation (EU) 2024/1257 Art. 6; and Regulation (EU) No 168/2013 Art. 48. The implementing regulation's technical requirements are therefore cited nowhere in this document, and whether it applies to Baltika at all — Art. 21(5) names the provider classes it covers — is held as an open scoping determination, not assumed. Control-mapping discipline. A register row links a control only where a fetched row genuinely covers the requirement; rows (h), (i), and (j) matched none and are marked analyst drafts. Three fetched control rows were considered and not used: AAT-01 and RSK-09.2 (both AI-specific — nothing in Baltika's scope is an AI system) and DCH-05.1 (considered for row (i); judged too narrow to carry it). Fiction boundary. The client, its 90 staff, its supplier count, and every current-state cell are invented; the classification as an important entity is stated as a client-provided scoping input. The regulation quotes, URLs, publishers, and licenses are fetched, not invented. What a paid engagement adds. Your real policies, contracts, and control owners under interview; verification of the NIS2 classification and the implementing-regulation question; national transposition and sector-regulator enrichment; and a named senior reviewer who confirms or corrects every verdict before it ships. Section 7 Sign-off Senior review: [shown for format — fictional sample, nothing to certify] Reviewer: [named reviewer — CISSP / ISO 27001 lead auditor] Date: [—] A paid engagement ships only after the named reviewer has validated every verdict and signed here. This sample is published unsigned, on purpose, so you can read the document exactly as it leaves the engine. Want this for your organisation? Scope a gap analysis → Download the blank NIS2 gap-analysis template (free XLSX) → --- ## Free NIS2 gap analysis template (Article 21) — XLSX · Ansvar AI URL: https://ansvar.eu/templates/nis2-gap-analysis Ungated NIS2 gap analysis template: one row per Article 21(2) measure, an Article 23 incident-reporting tracker, verdict dropdowns. Free XLSX + PDF, no email. Free template — no email gate Free NIS2 gap analysis template (Article 21) — XLSX A self-assessment workbook pre-structured from the text of Directive (EU) 2022/2555: one row per Art. 21(2) cybersecurity risk-management measure (a)–(j), a tracker for every Art. 23 reporting deadline, and verdict dropdowns so the result is countable. Download it, fill it in, keep it — the links are direct files. Download XLSX · 10 KB Print version (PDF) · 41 KB No form, no sign-up. Requirement wording follows the directive as published on EUR-Lex . What's inside Three sheets, ten measures, one clock. Sheet 1 — Gap register One row per Art. 21(2) risk-management measure, (a) through (j) — risk analysis policies, incident handling, business continuity, supply chain security, secure acquisition and development, effectiveness assessment, cyber hygiene and training, cryptography, HR security and access control, multi-factor authentication. Columns: Ref, Requirement, Current state, Verdict (Compliant / Partial / Gap dropdown), Evidence, Remediation, Owner, Due, Notes. Sheet 2 — Incident reporting (Art. 23) A tracker for every reporting duty on a clock: the significance test (Art. 23(3)), the 24-hour early warning, the 72-hour incident notification, the intermediate report on request, the one-month final report, the ongoing-incident progress report, and the duty to notify service recipients. Same tracking columns as the register. Sheet 3 — About What the workbook is, the EUR-Lex source it was built from, the license (free to use internally, not for resale), and the generation date — so the file stays honest when it circulates without this page. How to use it Four passes, in order. 01 Fill the current-state column From your real policies, runbooks and contracts — not from intentions. If the evidence cell stays empty, the verdict is probably not Compliant. 02 Set a verdict per row Compliant, Partial, or Gap — the dropdown keeps the register countable. Art. 21(4) expects corrective measures without undue delay once you find non-compliance. 03 Assign remediation, owner, due date Every Partial and Gap row gets all three. A register without owners is a wish list. 04 Test Art. 23 against a clock Could you file an early warning 24 hours from now, with an on-call rota and a CSIRT contact path? The second sheet makes that a row-by-row answer. Prefer it filled in? The same structure, produced and cited by the gateway — every requirement fetched from the regulation, every verdict traced to evidence, reviewed by a practitioner. Read the sample gap analysis or scope a gap analysis . Questions before you download The short answers Is it really free — no email? Yes. The download links above are direct file links: no form, no email address, no account. Use and adapt the workbook inside your organisation; the one thing we ask is that you don't resell it or redistribute it as a standalone product. What law is it based on? Directive (EU) 2022/2555 (NIS2), Articles 21 and 23, as published on EUR-Lex . The requirement rows quote or closely paraphrase the directive text — the ten Art. 21(2) measure families (a)–(j) and the Art. 23 duties, including the 24-hour early warning, 72-hour notification, and one-month final report. Can Ansvar fill it in for us? Yes. The gap-analysis service produces the same register completed for your organisation — every requirement fetched from the regulation through the Ansvar gateway, every verdict cited and reviewed by a practitioner. Read a complete worked sample to see what that looks like before you book anything. Is this legal advice? No. Ansvar is not a law firm, and the template is a working format, not legal advice: it gives you the directive's structure and provision references, and every row traces to the article it rests on. What you fill in is your assessment — the format is built so your counsel can check each line and take the legal position. --- ## Free DPIA template (GDPR Article 35) — XLSX · Ansvar AI URL: https://ansvar.eu/templates/dpia Ungated GDPR DPIA template: Article 35 screening with the WP248 criteria, processing-description prompts, risk register, Article 36 check. Free XLSX + PDF. Free template — no email gate Free DPIA template (GDPR Article 35) — XLSX A data protection impact assessment workbook pre-structured from the text of Regulation (EU) 2016/679: an Art. 35 screening checklist with the WP248 criteria, processing-description prompts mapped to Art. 35(7), a risk register judged from the data subject's perspective, and the Art. 36 prior-consultation determination. Download it, fill it in, keep it — the links are direct files. Download XLSX · 13 KB Print version (PDF) · 35 KB No form, no sign-up. Requirement wording follows the regulation as published on EUR-Lex . What's inside Five sheets, screening to sign-off. Sheet 1 — Screening (Art. 35) Do you need a DPIA at all? The statutory triggers — the Art. 35(1) high-risk test and the three Art. 35(3) cases (profiling with legal or similarly significant effects, large-scale special categories, systematic monitoring of publicly accessible areas) — plus your supervisory authority's Art. 35(4)/(5) lists and the nine WP248 criteria, each with a Yes/No dropdown and a conclusion cell. Rule of thumb from the guidelines: two or more criteria met, a DPIA is likely required. Sheet 2 — Processing description Prompt rows mapped to Art. 35(7): the systematic description of the processing operations and their purposes including any legitimate interest (35(7)(a)), and the necessity and proportionality assessment (35(7)(b)) — plus DPO advice (35(2)), data-subject views (35(9)), and the review plan (35(11)). Sheet 3 — Risk register The Art. 35(7)(c) assessment: Risk to data subjects, Severity and Likelihood (High / Medium / Low dropdowns), Initial risk, Mitigation, Residual risk, and a Citation / source column so each row can say where it comes from. Judged from the data subject's perspective, not the organisation's. Sheet 4 — Art. 36 determination The closing question: after mitigation, does any risk to data subjects remain high? If yes, Art. 36(1) requires consulting the supervisory authority before processing starts — the sheet carries what to provide (Art. 36(3)) and the authority's response window (Art. 36(2)). Sheet 5 — About Source (Regulation (EU) 2016/679 on EUR-Lex, WP248 attribution), license (free to use internally, not for resale), and the generation date — so the file stays honest when it circulates without this page. How to use it Four passes, in order. 01 Screen first Sheet 1 decides whether a DPIA is required — statutory triggers first, then the WP248 criteria. Record the conclusion and its basis even when the answer is no. 02 Describe before you judge Sheet 2's prompts pin down what data, about whom, flowing where, and why the processing is necessary and proportionate — before any risk scoring starts. 03 Register the risks One row per risk to data subjects on sheet 3, scored for severity and likelihood, with the mitigation and the residual risk it leaves behind. 04 Close with Article 36 If any residual risk stays high and you cannot mitigate it further, the determination sheet points you to prior consultation with the supervisory authority — before processing, not after. Prefer it filled in? The same structure, produced and cited by the gateway — every provision fetched from the regulation, every risk row traced to its source, reviewed by a practitioner. Read the sample DPIA or scope a DPIA . Questions before you download The short answers Is it really free — no email? Yes. The download links above are direct file links: no form, no email address, no account. Use and adapt the workbook inside your organisation; the one thing we ask is that you don't resell it or redistribute it as a standalone product. What law is it based on? Regulation (EU) 2016/679 (GDPR), Articles 35 and 36, as published on EUR-Lex . The requirement rows quote or closely paraphrase the regulation text; the nine screening criteria summarise the Article 29 Working Party's DPIA guidelines (WP248 rev.01), endorsed by the EDPB, and are labelled as such in the workbook. Can Ansvar fill it in for us? Yes. The DPIA service produces the same structure completed for your processing — every provision fetched from the regulation through the Ansvar gateway, every risk row cited, reviewed by a practitioner. Read a complete worked sample to see what that looks like before you book anything. Is this legal advice? No. Ansvar is not a law firm, and the template is a working format, not legal advice: it gives you the regulation's structure and provision references, and every row traces to the article it rests on. What you fill in is your assessment — the format is built so your counsel or DPO can check each line and take the legal position. --- ## Free EU AI Act checker — is your AI system high-risk? · Ansvar AI URL: https://ansvar.eu/tools/ai-act-checker Free AI Act compliance checker: walk Art. 5 bans, Art. 6 gates and Annex III in two minutes to see if your AI system is high-risk. Cited, no signup. Free tool EU AI Act high-risk checker Reg (EU) 2024/1689 · high-risk regime applies 2 Dec 2027 (Annex III) / 2 Aug 2028 (Annex I embedded) · six questions, client-side only — answers never leave your browser An indication, not a legal determination. Every screen cites the provision it applies; edge cases need counsel. The checker follows the same classification walk as our published sample assessment — it tells you which way the cited provisions point, nothing more. Question 1 of 6 Are you the provider or a deployer? The provider develops an AI system or places it on the market; a deployer uses it under its own authority. Your answer changes which obligations apply to you — it never changes the classification itself. Provider — we develop the system or place it on the market under our name Deployer — we use the system under our own authority How it works How high-risk classification works under the EU AI Act There are two routes into the high-risk category, both in Art. 6 of Regulation (EU) 2024/1689. The first is the product gate of Art. 6(1): a system that “is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I” — machinery, medical devices, vehicles, toys and the rest of the EU product-law stack — is high-risk where that product requires third-party conformity assessment. The second is the list route of Art. 6(2): “AI systems referred to in Annex III shall be considered to be high-risk.” What matters on this route is the intended use of the system, not the sophistication of the technology behind it. Art. 6(3) then opens a narrow derogation: an Annex III system “shall not be considered to be high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons”, available only where one of four conditions holds — a narrow procedural task, improving a previously completed human activity, pattern detection that does not replace human assessment, or a preparatory task. One override forecloses all four: an Annex III system “shall always be considered to be high-risk where the AI system performs profiling of natural persons”. A provider that relies on the derogation must document its assessment before placing the system on the market (Art. 6(4)) and register it under Art. 49(2). The dates The dates that decide urgency The original Art. 5 prohibitions have applied since 2 February 2025 (the omnibus amendment adds two further prohibitions from 2 December 2026), and the Art. 50 transparency duties apply from 2 August 2026 . The high-risk regime was postponed by the 2026 Digital Omnibus amendment (Parliament 16 June, Council 29 June 2026, signed 8 July 2026): stand-alone Annex III systems apply from 2 December 2027 , and high-risk systems embedded in Annex I products from 2 August 2028 . For high-risk systems already on the market before their date, Art. 111(2) pulls them into scope upon a significant change in design — and requires systems intended for use by public authorities to comply by 2 August 2030 regardless of design changes. The Commission's classification guidelines under Art. 6 remain the reference point for borderline calls. Annex III What Annex III covers Annex III lists eight areas of intended use. In summary: biometrics; critical infrastructure; education and vocational training; employment, workers management and access to self-employment; access to essential private and public services, including creditworthiness; law enforcement; migration, asylum and border control; and the administration of justice and democratic processes. The annex operates at the level of specific use cases within each area — recruitment screening, for example, sits in point 4(a): “AI systems intended to be used for the recruitment or selection of natural persons”. A high-risk verdict lands differently by role. Providers carry the heavy stack — risk management (Art. 9), the Art. 16 duties from quality management through conformity assessment (Art. 43), CE marking and registration. Deployers carry the Art. 26 duties: operating per the instructions for use, competent human oversight, log retention, and informing the people the system is used on. Our sample readiness assessment shows the full walk — role, classification, obligation register — exactly as a paid engagement produces it, and you can scope an AI Act readiness assessment for your real system. FAQ Common Annex III questions, answered Are recruitment and hiring AI systems high-risk under the EU AI Act? In most cases, yes. Annex III point 4(a) lists “AI systems intended to be used for the recruitment or selection of natural persons” — CV screening, application filtering and candidate scoring sit in that wording — and under Art. 6(2) Annex III systems are considered high-risk. The Art. 6(3) derogation can lift the classification for narrow procedural or preparatory tasks, but it is unavailable wherever the system performs profiling of natural persons, which most recruitment screening does. The high-risk obligations for stand-alone Annex III systems apply from 2 December 2027. Is AI for workers management, promotion or termination decisions high-risk? Alongside recruitment, Annex III point 4 covers AI used for decisions affecting the terms of work-related relationships — promotion and termination, task allocation based on individual behaviour or personal traits or characteristics, and monitoring and evaluating the performance and behaviour of people in those relationships (our summary of point 4(b)). The same walk applies: Art. 6(2) classifies the system as high-risk, the Art. 6(3) derogation is closed where the system profiles natural persons, and a provider relying on the derogation must document its assessment before placing the system on the market (Art. 6(4)). Is credit scoring or creditworthiness assessment high-risk under the AI Act? Yes. Annex III point 5(b) covers “AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score”, with an exception for AI used to detect financial fraud (our summary of the point's carve-out). Deployers of high-risk point 5(b) systems additionally owe a fundamental-rights impact assessment under Art. 27(1) before first use. When do the EU AI Act high-risk obligations apply? The original Art. 5 prohibitions have applied since 2 February 2025 (the 2026 Digital Omnibus amendment adds two further prohibitions from 2 December 2026), and the Art. 50 transparency duties apply from 2 August 2026. The same omnibus amendment, signed 8 July 2026, postponed the high-risk regime: stand-alone Annex III systems comply from 2 December 2027, and high-risk systems embedded in Annex I products from 2 August 2028. A system already on the market before its date is pulled into scope on a significant change in design (Art. 111(2)); systems intended for use by public authorities must comply by 2 August 2030 regardless of design changes. Provision links point at the Official Journal text of Regulation (EU) 2024/1689 on EUR-Lex. Quoted spans match the provision rows fetched from the Ansvar gateway for the published sample assessment; summaries are marked as ours. --- ## Free NIS2 checker — does NIS2 apply to your company? · Ansvar AI URL: https://ansvar.eu/tools/nis2-checker Walk NIS2's scope rules in two minutes: Annex I/II sectors, size thresholds, essential vs important — with article citations. Free, no signup. Free tool NIS2 scope checker Directive (EU) 2022/2555 · transposition deadline 17 Oct 2024 · five questions, client-side only — answers never leave your browser An indication, not a legal determination. Every screen cites the provision it applies. NIS2 is a directive — your national transposition governs and can be stricter. For the full picture, read NIS2 explained . Question 1 of 5 Do you operate in the EU? NIS2 applies to entities that “provide their services or carry out their activities within the Union”. This includes non-EU entities that offer in-scope services into the EU. Art. 2 — Directive (EU) 2022/2555 Yes — we provide services or carry out activities in the EU No — we have no EU activity How it works How NIS2 decides who is in scope NIS2 — Directive (EU) 2022/2555 — works in two moves. First, Art. 2 decides who is in scope. The main rule brings in entities of a type listed in Annex I or Annex II that are medium-sized or larger and that provide services or carry out activities in the Union. On top of that, Art. 2(2) to 2(4) pull certain entities in regardless of size : providers of public electronic communications, trust service providers, TLD name registries and DNS providers, entities a Member State identifies as critical, central and regional public administration, entities identified as critical under the CER Directive (EU) 2022/2557, and providers of domain name registration services. Second, Art. 3 sorts the in-scope entities into two tiers. Essential entities include large Annex I entities, qualified trust service providers, TLD registries and DNS providers of any size, medium-or-larger public electronic communications providers, central-government public administration, and CER-critical entities. Everyone else in scope — medium Annex I entities, Annex II entities, non-qualified trust providers — is an important entity. The two tiers carry the same core duties but differ on supervision and on the fine ceiling. Size What “medium-sized or larger” means NIS2 borrows the size thresholds from Commission Recommendation 2003/361. An entity is medium-sized or larger if it has 50 or more staff, or an annual turnover above €10 million and a balance-sheet total above €10 million. It is large — the ceiling that makes an Annex I entity essential rather than important — at 250 or more staff, or a turnover above €50 million and a balance sheet above €43 million. Staff and financial figures aggregate partner and linked enterprises, and NIS2 disapplies the small-enterprise exemption in Art. 3(4) of the 2003/361 Annex. Obligations What in-scope entities have to do In-scope entities carry four duties. Governance: the management body approves and oversees the security measures and can be held liable, and its members must be trained (Art. 20). Risk management: the ten Art. 21(2) measures, from risk-analysis policies and incident handling through supply-chain security, cryptography and multi-factor authentication. Reporting: for a significant incident, an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month (Art. 23). Registration: name, address, contacts, sector and Member States filed with the competent authority (Art. 3(4)). The maximum administrative fines run to at least €10 million or 2% of worldwide turnover for essential entities, and at least €7 million or 1.4% for important entities (Art. 34). Provision links point at the Official Journal text of Directive (EU) 2022/2555 on EUR-Lex. Article lists, the reporting clock and the fine figures were fetched from the Ansvar gateway's served NIS2 corpus; short forms of the Art. 21(2) list are ours. --- ## NIS2 explained: scope, obligations, deadlines — with citations · Ansvar AI URL: https://ansvar.eu/regulations/nis2 What NIS2 requires — scope, essential vs important, the ten Article 21 measures, the 24/72-hour reporting clock, and fines — each claim cited to the directive. NIS2 NIS2, explained for the teams who have to comply . NIS2 — Directive (EU) 2022/2555 — is the EU's baseline cybersecurity law for essential and important entities. It entered into force on 16 January 2023, with a transposition deadline of 17 October 2024. It reaches organisations in the Annex I and Annex II sectors that are medium-sized or larger, plus specific providers regardless of size. Check if NIS2 applies to you Read the directive Applicability Who is in scope Scope has two doors: a size-and-sector door, and a set of size-independent categories. The main rule in Article 2 brings in entities of a type listed in Annex I or Annex II that are medium-sized or larger — 50 or more staff, or turnover and balance sheet both above €10 million — and that provide services or carry out activities in the Union. Size follows Commission Recommendation 2003/361, aggregating partner and linked enterprises, and NIS2 disapplies that recommendation's small-enterprise exemption. Separately, Article 2(2) to 2(4) bring some entities in regardless of size : providers of public electronic communications; trust service providers; TLD name registries and DNS providers; providers of domain name registration services; entities a Member State identifies as sole providers, as systemically significant, or as otherwise critical; central and regional public administration; and entities identified as critical under the CER Directive (EU) 2022/2557. Get the sector or a category right and the size question may not even arise. Check in two minutes Obligations What in-scope entities must do Four duties, each anchored in a specific article of the directive. Governance and training — Article 20 The management body must approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for infringements. Its members must follow training, and the entity is encouraged to offer similar training to staff regularly. Article 20 The ten risk-management measures — Article 21(2) An all-hazards set of technical, operational and organisational measures, at least: (a) risk-analysis and information-system security policies; (b) incident handling; (c) business continuity, including backup, disaster recovery and crisis management; (d) supply-chain security; (e) secure acquisition, development and maintenance, including vulnerability handling and disclosure; (f) measuring the effectiveness of the measures; (g) basic cyber hygiene and training; (h) cryptography and, where appropriate, encryption; (i) human-resources security, access control and asset management; and (j) multi-factor or continuous authentication and secured communications where appropriate. Article 21 Incident reporting — Article 23 For a significant incident — one that causes or can cause severe operational disruption or financial loss, or considerable damage to others — the entity notifies its CSIRT or competent authority: an early warning within 24 hours of becoming aware, an incident notification within 72 hours , an intermediate report on request, and a final report within one month of the notification. Article 23 Registration — Article 3(4) In-scope entities file their name, address, up-to-date contact details, sector and subsector, and the Member States where they provide services with the competent authority, and notify changes within two weeks. Article 3 Two tiers Essential vs important entities Same core duties; different supervision and different fine ceilings. Essential entity Important entity Who Large Annex I entities; qualified trust providers, TLD registries and DNS providers (any size); medium-or-larger public electronic-communications providers; central-government public administration; CER-critical entities. Everyone else in scope — medium Annex I entities, Annex II entities, non-qualified trust providers, and Member-State-designated important entities. Core duties Articles 20, 21, 23 and 3(4) — identical. Articles 20, 21, 23 and 3(4) — identical. Supervision Proactive and reactive: inspections, off-site supervision, regular and targeted audits, random checks and scans ( Article 32 ). Ex-post only: authorities act on evidence of non-compliance ( Article 33 ). Maximum fine At least €10 million or 2% of total worldwide annual turnover, whichever is higher ( Article 34 ). At least €7 million or 1.4% of total worldwide annual turnover, whichever is higher ( Article 34 ). Transposition A directive, not a regulation The law that binds you is your Member State's implementation — and they vary. NIS2 is a directive: it sets a floor that each Member State writes into national law, and that national law can be stricter. The transposition deadline was 17 October 2024, and several Member States met it late. The Netherlands' Cyberbeveiligingswet, for instance, enters into force on 15 August 2026. Until your national law is in force and you have read it, treat the directive as the shape of the obligations, not the exact text you are held to. For financial entities, DORA (Regulation (EU) 2022/2554) is sector-specific Union law: where its cybersecurity and incident-reporting requirements are at least equivalent, the matching NIS2 provisions — including the Chapter VII supervision regime — do not apply to those entities ( Article 4 ). Member States keep the lists of essential and important entities, first drawn up by 17 April 2025 and reviewed at least every two years ( Article 3(3) ). Ansvar serves national implementations where they are live — see coverage . How Ansvar helps From scope question to cited gap analysis Every answer is grounded in the article text, in the AI client your team already uses. Start with the free NIS2 scope checker to see whether you are in scope and which tier you land in. When you are ready to build evidence, the free Article 21 gap analysis template gives you one row per measure, and the sample NIS2 gap analysis shows the full deliverable — an Article 21(2) register, incident-reporting readiness, and a remediation roadmap. The worked gap-analysis example traces every finding back to its ISO 27001, NIS2 and GDPR provision. For the ISO-27001-versus-NIS2 question, the clause-by-clause mapping shows where an ISO 27001 certificate carries you and where the reporting clock, management liability and supplier diligence sit outside it. NIS2 lands hardest in a few sectors. See the sector pages for energy , industrial / OT , and healthcare , each anchored on the duties that fall on essential and important entities. FAQ Questions teams ask about NIS2 If your question is not here, email us — every message gets a human answer. Does NIS2 apply to my company? NIS2 applies if you provide services or carry out activities in the EU and you are either (1) a medium-sized or larger entity — 50+ staff, or turnover and balance sheet both above €10 million — in one of the Annex I or Annex II sectors, or (2) within one of the size-independent categories in Article 2(2) to 2(4), such as a public electronic-communications provider, a trust service provider, a TLD registry or DNS provider, a domain-name registration service, or an entity a Member State identifies as critical. Below the size threshold and outside those categories, you are generally out of scope — though Member States may extend the rules. The free checker walks this in two minutes. What is the difference between an essential and an important entity? Both tiers carry the same core duties — governance, the Article 21 risk-management measures, incident reporting, and registration. They differ on supervision and penalties. Essential entities (large Annex I entities; qualified trust providers, TLD registries and DNS providers of any size; medium-or-larger public electronic-communications providers; central-government public administration; and CER-critical entities) face proactive and reactive supervision under Article 32, and a fine ceiling of at least €10 million or 2% of worldwide turnover. Important entities — everyone else in scope — face ex-post supervision only under Article 33, and a ceiling of at least €7 million or 1.4% of worldwide turnover. What are the ten NIS2 Article 21 security measures? Article 21(2) lists ten minimum measures: (a) risk-analysis and information-system security policies; (b) incident handling; (c) business continuity, including backup management, disaster recovery and crisis management; (d) supply-chain security; (e) security in acquisition, development and maintenance, including vulnerability handling and disclosure; (f) policies to assess the effectiveness of the measures; (g) basic cyber hygiene and cybersecurity training; (h) cryptography and, where appropriate, encryption; (i) human-resources security, access control and asset management; and (j) multi-factor or continuous authentication and secured communications where appropriate. What are the NIS2 incident-reporting deadlines? Article 23 sets a staged clock for a significant incident — one that causes or could cause severe operational disruption or financial loss, or considerable damage to others. You send an early warning to your CSIRT or competent authority within 24 hours of becoming aware, a fuller incident notification within 72 hours, an intermediate report on request, and a final report within one month of the notification. Trust service providers have a 24-hour deadline for incidents affecting their trust services. Does ISO 27001 make us NIS2 compliant? No. An ISO 27001:2022 certificate is strong evidence for most of the Article 21(2) technical and organisational measures, but three NIS2 obligations sit outside the standard: the Article 23 legal reporting clock (24 hours / 72 hours / one month to a national authority), the Article 20 personal accountability and training duty for the management body, and the supplier-specific diligence in Article 21(2)(d) read with 21(3). Certification supports the measures; it does not replace the law. Our blog post maps every Article 21(2) measure to ISO 27001 Annex A and marks the three gaps. What are the maximum NIS2 fines? For infringing the Article 21 security measures or the Article 23 reporting duties, Article 34 sets the ceilings a Member State must at least provide for. Essential entities face a maximum of at least €10 million or at least 2% of the total worldwide annual turnover in the preceding financial year, whichever is higher. Important entities face a maximum of at least €7 million or at least 1.4% of total worldwide annual turnover, whichever is higher. National transposition can set higher figures. Does a national law override NIS2? NIS2 is a directive, so the law that binds you is your Member State's transposition, not the directive itself — and a transposition can be stricter than the floor NIS2 sets. The transposition deadline was 17 October 2024, and several Member States met it late; the Netherlands' Cyberbeveiligingswet, for example, enters into force on 15 August 2026. For financial entities, DORA (Regulation (EU) 2022/2554) is sector-specific Union law: where its requirements are at least equivalent, the matching NIS2 provisions do not apply to those entities (Article 4). Always check your national implementation. See where you stand on NIS2 Two minutes in the free checker tells you whether NIS2 applies and which tier you land in — with every step cited to the directive. Then build the evidence with the free Article 21 template. Run the NIS2 checker Get the gap template --- ## DORA explained: scope, five pillars, TLPT, contracts — with citations · Ansvar AI URL: https://ansvar.eu/regulations/dora What DORA requires — scope, the five pillars, incident reporting, TLPT, Article 30 contract clauses, and enforcement — each claim cited to the regulation. DORA DORA, explained for the teams who have to comply . DORA — Regulation (EU) 2022/2554, the Digital Operational Resilience Act — is the EU's ICT-resilience law for the financial sector. As a regulation it is directly applicable, no national transposition needed, and it has applied since 17 January 2025. It reaches twenty types of financial entities and the ICT providers that serve them. Run a DORA gap analysis — free Read the regulation Applicability Who is in scope Twenty types of financial entities, plus the ICT providers that serve them. Article 2(1) lists the in-scope entities, points (a) to (t): credit institutions; payment institutions and account information service providers; electronic money institutions; investment firms; crypto-asset service providers and issuers of asset-referenced tokens; central securities depositories; central counterparties; trading venues; trade repositories; managers of alternative investment funds and management companies; data reporting service providers; insurance and reinsurance undertakings and their intermediaries; institutions for occupational retirement provision; credit rating agencies; administrators of critical benchmarks; crowdfunding service providers; and securitisation repositories. Point (u) adds ICT third-party service providers. Article 2(3) carves out, among others, occupational pension schemes with 15 or fewer members and insurance intermediaries that are micro, small or medium-sized enterprises. For every financial entity in scope, Article 4 applies the rules proportionately to your size, risk profile, and the nature, scale and complexity of your services — a small payment institution and a systemic bank do not carry identical programmes. If you are an ICT vendor rather than a financial entity, DORA still reaches you two ways: through the Article 30 clauses your financial-sector customers must put in every contract, and through designation as a critical ICT third-party service provider under Article 31 , which brings direct oversight by an ESA Lead Overseer. Designation turns on systemic impact, reliance by systemic institutions, and substitutability — not on provider size. Obligations The five pillars Five blocks of duties, each anchored in a specific chapter of the regulation. ICT risk management — Articles 5 to 16 The management body defines, approves and oversees the ICT risk framework, bears the ultimate responsibility for ICT risk, approves the budget, and keeps its own knowledge current through regular training ( Article 5 ). The framework itself is documented, reviewed at least yearly (microenterprises: periodically), audited on a regular basis for all but microenterprises, and carries a digital operational resilience strategy with a defined risk tolerance ( Article 6 ). Article 16 gives a named set of small entities a simplified framework in place of the full Articles 5 to 15. Incident classification and reporting — Articles 17 to 23 You classify ICT incidents on the Article 18 criteria — clients affected, duration, geographical spread, data losses, criticality of services, economic impact. A major incident triggers Article 19 : an initial notification, an intermediate report when the status changes, and a final report after root-cause analysis, on templates and time limits set by the Article 20 technical standards. Clients whose financial interests are hit are informed without undue delay. Resilience testing — Articles 24 to 27 Every financial entity other than a microenterprise runs a risk-based testing programme and tests all systems supporting critical or important functions at least yearly ( Article 24 ). Entities the authority identifies also run threat-led penetration testing at least every three years, on live production systems, with an external tester at least every third test ( Article 26 ). ICT third-party risk — Articles 28 to 30 Outsourcing never outsources responsibility: you remain fully answerable for compliance regardless of contract ( Article 28(1) ). You maintain a register of information over all ICT contracts, report yearly on new arrangements and hand the authority the full register on request, run pre-contract due diligence, and hold exit strategies for critical services (Article 28(3) to (8)). Every contract carries the Article 30 minimum clauses. Information sharing — Article 45 Financial entities may exchange cyber-threat information and intelligence within trusted communities, on arrangements that protect confidentiality and competition law. Enforcement Two enforcement tracks Financial entities answer to national authorities; critical ICT providers answer to an EU Lead Overseer. Financial entity Critical ICT third-party provider Supervised by The national competent authority for your licence (bank, insurance, securities supervisor), with powers to inspect, investigate and order remediation ( Article 50 ). A Lead Overseer — EBA, ESMA or EIOPA — after designation by the ESAs on the Article 31 criteria: systemic impact, reliance by systemic institutions, substitutability. Penalties Set by Member State law — effective, proportionate and dissuasive; no EU-wide ceiling in the regulation. Authorities can reach members of the management body personally ( Article 50(3), (5) ). Periodic penalty payments of up to 1% of average daily worldwide turnover, charged daily for up to six months, published unless disclosure would damage the markets ( Article 35(6) to (10) ). Third-country rule You may only keep using a third-country provider designated critical if it establishes an EU subsidiary within 12 months ( Article 31(12) ). Designation is published on a yearly ESA list; providers not on it can request designation ( Article 31(9), (11) ). DORA and NIS2 A regulation, and the sector carve-out Directly applicable since 17 January 2025 — and for financial entities, it displaces NIS2. Article 64 makes DORA binding in its entirety and directly applicable in all Member States, applying from 17 January 2025. You do not wait for a national implementation the way NIS2 requires — the regulation is the text you are held to, supplemented by the regulatory and implementing technical standards the European Supervisory Authorities drafted for incident reporting, the register of information, TLPT and subcontracting. For financial entities, DORA is the sector-specific law that NIS2 defers to: where DORA's requirements are at least equivalent, the matching NIS2 provisions do not apply (NIS2 Article 4 — see our NIS2 explainer ). A bank builds its programme to DORA. An ICT vendor serving that bank meets DORA through its contracts — and possibly NIS2 in its own right as a digital provider. How Ansvar helps From article text to cited gap analysis Every answer grounded in the regulation, in the AI client your team already uses. The fastest way to see where you stand: a DORA gap analysis is one of the workflow types on the Free tier — one run a month on a system you describe, reported as a watermarked document with every finding cited to the article. The sample gap analysis shows the deliverable shape end to end. For the third-party pillar — where most of the contract work lands — the Article 28 working mapping walks the obligations subsection by subsection against ISO 27001 and SCF controls, and the financial-sector page anchors the wider DORA duties. Threat modeling that doubles as compliance evidence — mapping each threat to the measure it satisfies — is covered in this walkthrough . FAQ Questions teams ask about DORA If your question is not here, email us — every message gets a human answer. Does DORA apply to my company? DORA applies to twenty types of financial entities listed in Article 2(1)(a) to (t) — credit institutions, payment institutions, account information service providers, e-money institutions, investment firms, crypto-asset service providers and issuers of asset-referenced tokens, central securities depositories, central counterparties, trading venues, trade repositories, fund managers, data reporting service providers, insurance and reinsurance undertakings and intermediaries, occupational pension institutions, credit rating agencies, critical-benchmark administrators, crowdfunding providers, and securitisation repositories — plus, under point (u), the ICT third-party service providers that serve them. Article 2(3) carves out, among others, small occupational pension schemes (15 or fewer members) and insurance intermediaries that are micro, small or medium-sized enterprises. If you sell ICT services to banks or insurers, DORA reaches you through your customers' contracts even before any designation as critical. Is DORA a regulation or a directive — do I need to wait for national law? DORA is a regulation: Article 64 makes it binding in its entirety and directly applicable in every Member State, and it has applied since 17 January 2025. There is no transposition to wait for, unlike NIS2. Member States still play two roles: they lay down the administrative penalties under Article 50, and their competent authorities supervise. The technical detail — incident-report templates and time limits, the register-of-information template, TLPT methodology — sits in regulatory and implementing technical standards the European Supervisory Authorities drafted under the regulation. What are the five DORA pillars? The regulation groups its obligations into five blocks: ICT risk management (Articles 5 to 16 — governance, a documented risk-management framework, and a digital operational resilience strategy); ICT incident management, classification and reporting (Articles 17 to 23); digital operational resilience testing (Articles 24 to 27, up to threat-led penetration testing); ICT third-party risk management (Articles 28 to 30, plus the Union oversight framework for critical providers in Articles 31 to 44); and information-sharing arrangements on cyber threats (Article 45). What are the DORA incident-reporting deadlines? Article 19(4) sets the structure: an initial notification, an intermediate report when the incident's status changes significantly or on the authority's request, and a final report once the root-cause analysis is complete. The regulation itself does not put hour figures on those steps — Article 19(4) defers the time limits and templates to the technical standards developed under Article 20. Article 19(3) adds a client-facing duty: where a major incident affects clients' financial interests, you inform them without undue delay, together with the measures taken. Significant cyber threats may be notified voluntarily under Article 19(2). Who has to run threat-led penetration testing (TLPT)? Not everyone. Every financial entity other than a microenterprise runs a risk-based resilience testing programme, and tests all systems supporting critical or important functions at least yearly (Article 24). On top of that, the competent authority identifies specific entities — weighing sector impact, financial-stability concerns and ICT risk profile — that must run TLPT at least every three years on live production systems (Article 26). Internal testers are allowed, but every third test needs an external one, and significant credit institutions must always use external testers. The RTS follows the TIBER-EU framework. What must our ICT contracts contain under DORA? Article 30(2) sets the minimum content of every ICT-service contract — among it: a full description of the services with the conditions for any subcontracting of critical functions, data-processing locations with advance notice of changes, data-protection provisions, access and recovery of data on exit or insolvency, service levels, incident assistance at a pre-agreed cost, cooperation with authorities, termination rights with minimum notice, and conditions for the provider's participation in your security-awareness training. Contracts supporting critical or important functions add Article 30(3): precise quantitative service-level targets, notice duties, contingency-plan testing, participation in your TLPT, unrestricted audit and inspection rights, and a mandatory transition period on exit. Article 28(3) requires you to maintain a register of information covering all ICT contracts, report yearly on new arrangements, and hand over the full register when your authority asks. What are the DORA fines? For financial entities, DORA sets no EU-wide fine ceiling. Article 50 leaves administrative penalties to Member State law, requiring them to be effective, proportionate and dissuasive, and lets authorities apply penalties to members of the management body personally. So the exposure depends on where you are supervised. The one figure in the regulation targets critical ICT third-party service providers: a Lead Overseer can impose a periodic penalty payment of up to 1% of average daily worldwide turnover, charged daily for up to six months, to compel compliance (Article 35(6) to (8)). We already comply with NIS2 — does DORA still apply? For financial entities, DORA takes priority. NIS2's Article 4 treats DORA as sector-specific Union law: where DORA's requirements are at least equivalent, the matching NIS2 provisions do not apply to those entities. In practice a bank or insurer builds to DORA, not NIS2 — while a fintech that is not one of the Article 2 entity types may still land in NIS2 as a digital provider. The two laws share DNA (risk measures, staged incident reporting, management accountability), but DORA is stricter on testing, third-party contracts and the register of information. See where you stand on DORA A free-tier run produces a cited DORA gap analysis of a system you describe — one row per obligation, each anchored to its article. Start there, then bring your own documents on a paid plan. Start free See a sample deliverable --- ## CRA explained: scope, Annex I, reporting, conformity — with citations · Ansvar AI URL: https://ansvar.eu/regulations/cra What the CRA requires — scope, Annex I, the SBOM, the five-year support period, the 24/72-hour reporting clocks, conformity routes and fines — each claim cited. CRA The Cyber Resilience Act, explained for the teams who ship the product . The CRA — Regulation (EU) 2024/2847 — is the EU's cybersecurity law for products, not for operators. If your product connects to a device or a network, it sets what the product must do, what you must keep doing about vulnerabilities, and what you must report when one is exploited. It applies in full from 11 December 2027, with the reporting duty live from 11 September 2026. Run a CRA gap analysis — free Read the regulation Applicability Who is in scope One connectivity test, a short list of carve-outs, and a chain of economic operators. Article 2(1) applies the Regulation to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. There is no sector list and no size threshold to fall under: the test is the product, and it catches hardware and software alike. Making a product available is itself defined — Article 3(22) means supply for distribution or use on the Union market in the course of a commercial activity, whether for payment or free of charge — so the commercial-supply element travels with the connectivity test. The carve-outs are named, not general. The Regulation does not apply to products covered by the medical devices Regulations (EU) 2017/745 and 2017/746 or by motor-vehicle Regulation (EU) 2019/2144, to products certified under civil-aviation Regulation (EU) 2018/1139, to marine equipment under Directive 2014/90/EU, to identical spare parts manufactured to the same specifications as the components they replace (Article 2(6)), or to products developed or modified exclusively for national security or defence purposes or specifically designed to process classified information (Article 2(7)). Where other Union rules already address all or some of the same risks, Article 2(5) lets the Commission limit or exclude the CRA's application by delegated act — on two cumulative conditions: the limitation is consistent with the overall regulatory framework for those products, and the sectoral rules achieve the same or a higher level of protection. Article 1 splits the duties into the two halves that shape everything below: essential requirements for the design, development and production of the product, and essential requirements for the vulnerability-handling processes you run while the product is expected to be in use. The duty-holders are economic operators, which Article 3(12) defines as the manufacturer, the authorised representative, the importer, the distributor, or any other person subject to obligations under the Regulation. Manufacturers carry both halves ( Article 13 ). Importers must verify before placing a product on the market that it meets the Annex I Part I requirements, that the manufacturer ran the right conformity assessment and vulnerability-handling processes, and that the CE marking, documentation and instructions are there ( Article 19 ). Distributors act with due care, and where a distributor considers or has reason to believe — on the basis of information in its possession — that the product or the manufacturer's processes fail the Annex I requirements, it must not make the product available until that is put right ( Article 20 ). Obligations What the product must be, and what you must keep doing Annex I Part I is a property list. Part II is a process you run for the whole support period. The product properties — Annex I, Part I Products are designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks. On the basis of the Article 13(2) risk assessment and where applicable, that means: no known exploitable vulnerabilities at the point of being made available; a secure-by-default configuration with the ability to reset to it, unless otherwise agreed with a business user for a tailor-made product; vulnerabilities addressable through security updates, automatic and default-on where applicable with an easy opt-out and the option to postpone; protection against unauthorised access with reporting of possible unauthorised access; confidentiality and integrity protection for stored, transmitted and processed data, with reporting of corruptions; data minimisation; availability of essential and basic functions including against denial-of-service; minimising the product's own negative impact on the availability of services other devices or networks provide; limited attack surfaces; exploitation-mitigation techniques; recording and monitoring of relevant internal activity, with a user opt-out; and secure, permanent erasure of all data and settings. The vulnerability-handling process — Annex I, Part II This is the half that outlives the release. Manufacturers identify and document the vulnerabilities and components in the product, including a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. They remediate without delay and, where technically feasible, ship security updates separately from functionality updates; test and review regularly; publicly disclose fixed vulnerabilities once the update is out, with the information users need to remediate — publication may be delayed in duly justified cases, where the security risk of publishing outweighs the benefit, until users can apply the patch; enforce a coordinated vulnerability disclosure policy; publish a contact address for vulnerability reports; distribute updates securely; and disseminate security updates without delay and free of charge, except where otherwise agreed with a business user for a tailor-made product. The support period — Article 13(8) Vulnerability handling runs for the support period, and the support period is at least five years — unless the product is expected to be in use for less, in which case it corresponds to that expected use time. You set it to reflect how long the product is expected to be in use, taking into account in particular reasonable user expectations, the nature of the product including its intended purpose, and Union law determining product lifetime. You may also take into account comparable products from other manufacturers, the availability of the operating environment, and the support periods of third-party components that provide core functions. Telling the user — Annex II The information and instructions supplied with the product are themselves regulated: the manufacturer's identity and contact point, the single point of contact for reporting vulnerabilities, where the coordinated vulnerability disclosure policy can be found, the product identification, the intended purpose and known or foreseeable circumstances leading to significant cybersecurity risks, where the EU declaration of conformity can be accessed, and the end date of the support period. Reporting Two clocks, both running from the moment you know Actively exploited vulnerabilities and severe incidents report on parallel tracks — and this duty starts more than a year before the rest of the Regulation. Article 14 notifications go simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform set up under Article 16 . Every step below is due without undue delay and in any event within the stated period, counted from the moment you become aware — the outer deadline is a backstop, not a budget. Where necessary, the coordinating CSIRT may ask for an intermediate status report. Actively exploited vulnerability Severe incident Early warning Without undue delay and within 24 hours of becoming aware, naming where applicable the Member States where the product has been made available (Article 14(2)(a)). Without undue delay and within 24 hours, including whether the incident is suspected of being caused by unlawful or malicious acts (Article 14(4)(a)). Notification Within 72 hours, unless already provided: the product concerned, the general nature of the exploit and the vulnerability as available, corrective or mitigating measures taken and what users can do (Article 14(2)(b)). Within 72 hours, unless already provided: the nature of the incident where available, an initial assessment, measures taken and measures users can take (Article 14(4)(b)). Final report No later than 14 days after a corrective or mitigating measure is available — the vulnerability and its severity, information where available on any malicious actor exploiting it, and the remedy shipped (Article 14(2)(c)). Within one month of the 72-hour notification — a detailed description, the likely threat or root cause, and applied and ongoing mitigations (Article 14(4)(c)). Trigger A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission (Article 3(42)), once you become aware of it (Article 14(1)). An incident that affects — or can affect — the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information systems (Article 14(5)). Conformity Which list your product is on decides who assesses it Article 32 offers four routes for an ordinary product. Two annexes narrow them, and open source keeps them. Product category Assessment route Default Any of four routes: internal control (module A) — the manufacturer's own assessment against Annex I — EU-type examination (module B) followed by conformity to type (module C), full quality assurance (module H), or, where available and applicable, a European cybersecurity certification scheme ( Article 32(1) ). Annex III class I Identity and privileged access management, browsers, password managers, anti-malware, VPNs, network management, SIEM, boot managers, PKI and certificate issuance, network interfaces, operating systems, routers, modems and switches, security-related microprocessors, microcontrollers, ASICs and FPGAs, smart-home assistants and security products, internet-connected toys covered by the Toy Safety Directive 2009/48/EC with social interactive or location-tracking features, and wearables with a health-monitoring purpose or intended for children. Self-assessment survives only where harmonised standards, common specifications or a certification scheme at assurance level at least ‘substantial’ are applied in full; otherwise module B + C or module H (Article 32(2)). Annex III class II Hypervisors and container runtimes, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors and microcontrollers — module B + C, module H, or, where available and applicable, a certification scheme at assurance level at least ‘substantial’ (Article 32(3)). Annex IV critical Hardware devices with security boxes, smart meter gateways and other advanced-security devices, smartcards and similar devices including secure elements — a certification scheme under Article 8(1) , or, where its conditions are not met, one of the class II routes (Article 32(4)). One carve-out cuts across both classes: under Article 32(5), free and open-source software falling under the Annex III categories may use any of the Article 32(1) routes, provided the Article 31 technical documentation is public at the time of placing on the market. Whichever route applies, the paperwork is the same shape: an EU declaration of conformity stating that fulfilment of the applicable essential cybersecurity requirements in Annex I has been demonstrated, drawn up by the manufacturer ( Article 28 ), and CE marking affixed visibly, legibly and indelibly before the product is placed on the market ( Article 30 ). Enforcement then runs through the market surveillance authorities each Member State designates under Article 52 . The money sits in Article 64 : up to EUR 15 000 000 for the Annex I requirements and the Article 13 and 14 duties, EUR 10 000 000 for the obligations enumerated in Article 64(3), and EUR 5 000 000 for incorrect, incomplete or misleading information supplied in reply to a request — each becoming, where the offender is an undertaking, the higher of that figure and 2.5%, 2% or 1% of total worldwide annual turnover. CRA, NIS2 and DORA Product law, not entity law The CRA regulates what you place on the market. NIS2 and DORA regulate how you operate. Article 1 is explicit about the axis: the CRA lays down rules for the making available on the market of products with digital elements, essential requirements for their design and production, essential requirements for vulnerability handling, and market surveillance — plus obligations for economic operators in relation to both. Those operators are the manufacturer, the authorised representative, the importer, the distributor and anyone else the Regulation obliges ( Article 3(12) ), and what triggers the duties is making the product available on the market. Our NIS2 and DORA explainers cover the other axis — obligations an entity carries for how it runs its own systems — each cited to its own text. If you carry duties under more than one of them, the overlap is worth mapping once rather than twice: the Annex I Part II vulnerability process, the coordinated disclosure policy and the 24-hour clock look a great deal like duties you may already carry as an operator, but they attach to a different subject and report to a different address. Where other Union rules already address all or some of the same risks for the same product, Article 2(5) is the mechanism for resolving it — by delegated act, and only where the limitation fits the overall regulatory framework and the sectoral rules are at least as protective. The dates make sequencing possible. Article 71 applies the Regulation from 11 December 2027, but brings Article 14 reporting forward to 11 September 2026 — fifteen months earlier — and Chapter IV, the notification of conformity assessment bodies, to 11 June 2026. Reporting readiness is the first deadline that will actually bite. How Ansvar helps From annex text to a cited gap analysis Every answer grounded in the regulation, in the AI client your team already uses. The fastest way to see where you stand: a CRA gap analysis is one of the workflow types on the Free tier — one run a month on a system you describe, reported as a watermarked document with every finding cited to the article or annex point it comes from. The sample gap analysis shows the deliverable shape end to end. The CRA lands on engineering more than on policy, which is why the two halves that usually need evidence first are the secure-development story and the vulnerability process. Secure development with AI assistants covers the first; threat modeling that doubles as compliance evidence — mapping each threat to the measure it satisfies — is covered in this walkthrough . FAQ Questions teams ask about the CRA If your question is not here, email us — every message gets a human answer. Does the CRA apply to my product? The scope test in Article 2(1) is broad and mechanical: the Regulation applies to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Hardware and software both count, and a product's remote data processing solutions come with it: Article 3(1) folds them into the product, and Article 3(2) defines them as data processing at a distance for which the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, and whose absence would prevent the product from performing one of its functions. The named carve-outs are specific rather than general — products already covered by the medical devices Regulations (EU) 2017/745 and 2017/746, motor-vehicle Regulation (EU) 2019/2144, civil aviation certification under Regulation (EU) 2018/1139, and marine equipment under Directive 2014/90/EU, plus identical spare parts (Article 2(6)) and products developed or modified exclusively for national security or defence purposes, or specifically designed to process classified information (Article 2(7)). One element is easy to miss: being in scope turns on making the product available on the market, which Article 3(22) defines as supply for distribution or use on the Union market in the course of a commercial activity — whether for payment or free of charge. When does the CRA start to apply? Article 71 sets three dates, and they are not the same date. The Regulation applies in full from 11 December 2027. Article 14 — the manufacturer reporting duty for actively exploited vulnerabilities and severe incidents — applies earlier, from 11 September 2026. Chapter IV, Articles 35 to 51, covering the notification of conformity assessment bodies, applies from 11 June 2026 so that notified bodies exist before manufacturers need them. The regulation entered into force on the twentieth day after publication in the Official Journal. What are the CRA's essential cybersecurity requirements? Annex I has two parts and they ask for different things. Part I covers what the product must be: designed for an appropriate level of cybersecurity based on the risks, and — on the basis of the Article 13(2) risk assessment, where applicable — placed on the market without known exploitable vulnerabilities, with a secure-by-default configuration (unless otherwise agreed with a business user for a tailor-made product), able to receive security updates (automatic and default-on where applicable, with an easy opt-out), protected against unauthorised access with reporting of possible unauthorised access, protecting confidentiality and integrity of data with reporting of corruptions, minimising data processed, protecting availability of essential and basic functions including against denial of service, minimising the product's own negative impact on the availability of services provided by other devices or networks, limiting attack surfaces, using exploitation-mitigation techniques, recording and monitoring relevant internal activity with a user opt-out, and letting users securely and permanently erase all data and settings. Part II covers what the manufacturer must do over time — the vulnerability-handling process. Does the CRA require a software bill of materials? Yes. Annex I, Part II, point 1 requires manufacturers to identify and document the vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies. The rest of Part II is the process around it: remediate without delay and, where technically feasible, ship security updates separately from functionality updates; test and review regularly; publicly disclose fixed vulnerabilities once an update is available (publication may be delayed in duly justified cases until users can patch); enforce a coordinated vulnerability disclosure policy; publish a contact address for vulnerability reports; distribute updates securely and, where applicable, automatically; and disseminate security updates without delay and — unless otherwise agreed with a business user for a tailor-made product — free of charge. What are the CRA reporting deadlines? Article 14 runs two tracks, both notified simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform of Article 16. Each notification is due without undue delay and in any event within the stated period. For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident affecting the security of the product: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month of that notification. The coordinating CSIRT may also request an intermediate status report. Article 14(5) defines severe: the incident negatively affects, or can affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information systems. How long do we have to support a product under the CRA? Article 13(8) requires vulnerabilities to be handled effectively for the support period, and the support period is at least five years — unless the product is expected to be in use for less, in which case it corresponds to that expected use time. The manufacturer sets it to reflect how long the product is expected to be in use, taking into account in particular reasonable user expectations, the nature of the product including its intended purpose, and Union law determining product lifetime. It may also take into account comparable products from other manufacturers, the availability of the operating environment, the support periods of third-party components providing core functions, and guidance from the administrative cooperation group and the Commission. Do we need a notified body, or can we self-assess? It depends on which list your product is on. Article 32(1) offers four routes for an ordinary product, and one of them — internal control, module A — is the manufacturer's own assessment. For important products with digital elements in Annex III class I — among them identity and privileged access management, browsers, password managers, anti-malware, VPNs, network management, SIEM, boot managers, PKI software, operating systems, routers and switches, security-related microprocessors and microcontrollers, smart-home assistants and security products, internet-connected toys covered by the Toy Safety Directive 2009/48/EC that have social interactive or location-tracking features, and personal wearables with a health-monitoring purpose or intended for children — self-assessment survives only where harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least 'substantial' have been applied in full; otherwise it is EU-type examination (module B) plus conformity to type (module C), or full quality assurance (module H). Class II — hypervisors and container runtimes, firewalls and intrusion detection and prevention systems, tamper-resistant microprocessors and microcontrollers — takes module B plus C, module H, or, where available and applicable, a certification scheme at assurance level at least 'substantial'. Annex IV critical products — hardware devices with security boxes, smart meter gateways and other advanced-security devices, smartcards and similar devices including secure elements — take a certification scheme under Article 8(1), or, where its conditions are not met, one of the class II routes (Article 32(4)). One carve-out cuts across both classes: under Article 32(5), free and open-source software falling under Annex III may use any Article 32(1) route provided the technical documentation is public at the time of placing on the market. What are the CRA fines? Article 64 sets three ceilings. Each is a euro figure, and where the offender is an undertaking it is instead the higher of that figure and a share of total worldwide annual turnover for the preceding financial year. Non-compliance with the Annex I essential requirements or the Article 13 and 14 manufacturer obligations: up to EUR 15 000 000 or 2.5%. Non-compliance with the obligations enumerated in Article 64(3) — Articles 18 to 23, the EU declaration of conformity, CE marking and conformity assessment duties among them: up to EUR 10 000 000 or 2%. Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities in reply to a request: up to EUR 5 000 000 or 1%. Member States set the penalty rules themselves. Article 64(10) then carves out, by way of derogation from paragraphs 3 to 9, microenterprises and small enterprises that miss the Article 14 early-warning deadlines, and open-source software stewards for any infringement. See where you stand on the CRA A free-tier run produces a cited CRA gap analysis of a product you describe — one row per requirement, each anchored to its article or annex point. Start there, then bring your own documents on a paid plan. Start free See a sample deliverable --- ## Sample EU AI Act readiness assessment — full example · Ansvar AI URL: https://ansvar.eu/services/sample-ai-act-readiness A complete sample EU AI Act readiness assessment for a fictional HR-tech provider — classification walk, obligation register, conformity route. Services Sample AI Act readiness assessment — high-risk HR screening Skarval Analytics — FitScreen · sample deliverable · fictional client · produced with the same engine and format as a paid engagement Document AIA-SKRV-2026-001 · Scope: one AI system, provider-side · Method: role → classification → obligation register · Status: sample — senior review pending This is a fictional sample. Skarval Analytics and FitScreen don't exist — the company is invented so we can publish a complete deliverable without exposing a client. It was produced with the same gateway engine, the same sources, and the same format as a paid engagement, where it would ship signed by the reviewing practitioner. A sample has no client and nothing to certify, so the sign-off block in §8 shows the format and stays blank by design. Every linked citation is a real provision fetched from the gateway's EU corpus; the readiness verdicts and the company itself illustrate the format. Section 1 Executive summary Skarval Analytics ApS develops FitScreen, an AI ranking tool that scores and shortlists job applicants, and places it on the EU market under its own trademark. That makes Skarval the provider of a high-risk AI system : FitScreen falls under Annex III point 4(a) (recruitment and selection of natural persons), and the Art. 6(3) derogation is unavailable because the fetched text makes an Annex III system “always” high-risk “where the AI system performs profiling of natural persons” — which scoring applicants is. The dates that bite: for FitScreen — a stand-alone Annex III system — the high-risk regime applies from 2 December 2027, as postponed by the 2026 Digital Omnibus amendment. analyst-known fact — no row fetched in this run carries the application dates; the framing is the site's public AI Act timeline One date did arrive fetched: the Art. 6 text obliges the Commission to publish classification guidelines “no later than 2 February 2026” — those guidelines are a scoping input for the engagement. Because FitScreen is already on the market, the transitional rule for pre-existing high-risk systems (Art. 111(2): systems placed on the market before the application date fall in scope upon a significant change in design) interacts directly with the quarterly-retraining question in §5 — whether retraining crosses that threshold decides when the register above starts to bind. Art. 111(2)'s second sentence adds an unconditional backstop: high-risk systems intended for use by public authorities must comply by 2 August 2030 regardless of design changes — so the analysis also turns on whether any FitScreen customer is a public body. analyst note — Art. 111 was not fetched in this run; the transitional analysis is scoped for the engagement, not concluded here The register in §4 holds 12 obligations ( 11 on Skarval, 1 deployer-side that Skarval must enable). The heavy items: a documented lifecycle risk-management system (Art. 9), the Art. 16 duty stack — quality management, documentation, logs, conformity assessment, declaration of conformity, CE marking, registration — and the internal-control conformity route of Art. 43(2). Three items are not started; none of that is papered over. Readiness verdicts are analyst-assigned for the fictional client and would be evidence-checked in a real engagement. Section 2 System description & role determination Skarval Analytics ApS (fictional, Copenhagen) sells FitScreen, a B2B SaaS service that ingests applicant CVs and structured assessment results, computes a per- candidate fit score, and returns a ranked shortlist to enterprise recruiting teams. Models are retrained quarterly on pooled outcome data. FitScreen does no emotion inference and no biometric processing — facts that matter at the Art. 5 and Annex III boundaries walked in §3. Role determination. Skarval develops FitScreen and places it on the EU market under its own name — the provider role. Its customers use the system on their own applicants — the deployer role. The functional split is visible in the fetched provisions themselves: Art. 16 binds providers to duties running “prior to its being placed on the market or put into service”, and the fetched Art. 26 is titled “Obligations of deployers of high-risk AI systems”. analyst — the definitional test itself lives in Art. 3, which this run did not fetch; the provider/deployer conclusions rest on that unfetched text and are flagged accordingly Role → classification → obligations, with the Art. 6(3) dead-end. Text version: Show the text form [Skarval Analytics ApS — develops FitScreen, places it on the EU market] = PROVIDER (Art. 3 — analyst) | [Art. 6(1): safety component of an Annex I product?] -- no (analyst; Annex I not fetched) | [Art. 6(2): intended use listed in Annex III?] -- yes (fetched Annex III row) | [Annex III point 4(a): recruitment or selection of natural persons] | [Art. 6(3) derogation: no significant risk of harm?] | conditions (a)-(d) never reached, because: [Profiling override: "always be considered to be high-risk where the AI system performs profiling of natural persons" -> FitScreen profiles applicants -> derogation UNAVAILABLE] | [VERDICT: HIGH-RISK — Annex III point 4(a)] |-- provider side --> [Art. 9 risk management] [Art. 16 duties (a)-(l)] [Art. 43(2) internal control, no notified body] |-- deployer side --> [Art. 26 duties] <-- [Enterprise customers = DEPLOYERS] Section 3 Classification walk (Art. 6 + Annex III) Every quoted span below is verbatim from text fetched during the run; bracketed ellipses […] mark our elisions. Steps that rest on unfetched text say so. Step 0 — prohibited-practices screen (Art. 5). FitScreen does no emotion inference or social scoring, so no Art. 5 prohibition appears engaged. The run fetched the AI Office's prohibited-practices guidelines as a guidance row ( AI Office — prohibited-practices guidelines ) but not the Art. 5 text itself, so this screen is analyst draft — held for senior review . The guidance row is still load-bearing for step 2: its Art. 5(1)(f) discussion points at “the list of high-risk AI systems in Annex III, referring to self-employment at 4”. Step 1 — Art. 6(1): the product gate. The fetched Art. 6(1) makes a system high-risk where it “is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I” and that product needs third-party conformity assessment. FitScreen is stand-alone recruiting software, not a safety component. analyst — Annex I was not fetched; the negative (“HR software is not an Annex I case”) rests on analyst knowledge of that list Art. 6 — Reg (EU) 2024/1689 Step 2 — Art. 6(2): the Annex III route. Fetched: “In addition to the high-risk AI systems referred to in paragraph 1, AI systems referred to in Annex III shall be considered to be high-risk.” The run's Annex III row arrived as a search fragment ending the employment heading (“…to self-employment:”) and opening point (a): “AI systems intended to be used for the recruitment or selection of natural persons, in particular…”. Scoring and shortlisting job applicants is squarely that use. The point-4 numbering is corroborated by the fetched AI Office guidance row quoted in step 0 — the direct Annex III provision lookup returned nothing (§7). Annex III — Reg (EU) 2024/1689 · AI Office — prohibited-practices guidelines Step 3 — Art. 6(3): the derogation test. Fetched: “By derogation from paragraph 2, an AI system referred to in Annex III shall not be considered to be high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making.” It applies where any of four fetched conditions holds: (a) “a narrow procedural task” — no, FitScreen ranks candidates end-to-end; (b) “improve the result of a previously completed human activity” — no, it runs before human review, not after; (c) detecting “decision-making patterns or deviations from prior decision-making patterns” without replacing human assessment — no; (d) “a preparatory task to an assessment relevant for the purposes of the use cases listed in Annex III” — arguable for a shortlisting tool, but the question is never reached, because of step 4. Art. 6 — Reg (EU) 2024/1689 Step 4 — the profiling override closes the derogation. Fetched, same paragraph: “Notwithstanding the first subparagraph, an AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons.” FitScreen evaluates personal aspects of applicants — predicted job performance — to score and rank them: profiling. The derogation is therefore unavailable to Skarval regardless of how condition (d) would have come out. analyst — “profiling” takes its meaning from Art. 3(52) / GDPR Art. 4(4), which this run did not fetch; reading applicant scoring as profiling is the conservative reading and is flagged as analyst reasoning Art. 6 — Reg (EU) 2024/1689 Step 5 — Art. 6(4): if Skarval disagreed. Fetched: “A provider who considers that an AI system referred to in Annex III is not high-risk shall document its assessment before that system is placed on the market or put into service”, with registration under Article 49(2). Not exercised here — Skarval accepts the high-risk classification — but recorded so the road not taken is visible. Art. 6 — Reg (EU) 2024/1689 Verdict: FitScreen is a high-risk AI system under Annex III point 4(a); Skarval is its provider. Everything in §4–§6 follows from those two findings. Section 4 Obligation register One row per obligation, grounded in a quoted span of the fetched article text. Readiness verdicts are analyst-assigned for the fictional client — in a paid engagement each verdict is evidence-checked before it ships. ID Basis Obligation (fetched span) Owner Readiness Action Citation OB-01 Art. 16(a) Meet the Section 2 requirements for high-risk AI systems — “ ensure that their high-risk AI systems are compliant with the requirements set out in Section 2 ” Skarval (provider) Gap Stand up a tracked gap program against the full Section 2 requirement set. Only Art. 9 (risk management) was fetched and walked in this sample; a paid engagement walks the remaining Section 2 articles the same way. Art. 16 — Reg (EU) 2024/1689 OB-02 Art. 9(1)–(2) Establish a documented, lifecycle risk-management system — “ a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating ” Skarval (provider) Partial Ad-hoc model-risk reviews exist but nothing is documented as a lifecycle process. Formalise the four Art. 9(2) steps — risk identification, estimation under reasonably foreseeable misuse, post-market data evaluation, targeted measures — as a recurring, documented cycle. Art. 9 — Reg (EU) 2024/1689 OB-03 Art. 9(6), (8) Test against pre-defined metrics and thresholds before release — “ Testing shall be carried out against prior defined metrics and probabilistic thresholds that are appropriate to the intended purpose of the high-risk AI system. ” Skarval (provider) Gap Release testing today is accuracy-only with no pre-committed thresholds. Define pass/fail metrics — including disparate-performance metrics across applicant groups — before the next model release, and keep the test records. Art. 9 — Reg (EU) 2024/1689 OB-04 Art. 16(c) Operate a quality management system complying with Article 17 — “ have a quality management system in place which complies with Article 17 ” Skarval (provider) Partial An engineering QMS exists; map it against Article 17 (content not fetched in this run — scoped in the engagement) rather than assuming coverage. Art. 16 — Reg (EU) 2024/1689 OB-05 Art. 16(d) Keep the Article 18 documentation — “ keep the documentation referred to in Article 18 ” Skarval (provider) Partial Technical documentation is spread across wikis and release notes. Consolidate it into one controlled set with retention rules (Article 18 content not fetched — scoped in the engagement). Art. 16 — Reg (EU) 2024/1689 OB-06 Art. 16(e) Keep the automatically generated logs under Skarval's control — “ when under their control, keep the logs automatically generated by their high-risk AI systems as referred to in Article 19 ” Skarval (provider) In place FitScreen already emits per-decision event logs retained on Skarval's side. Confirm coverage and retention against Article 19 (content not fetched). Art. 16 — Reg (EU) 2024/1689 OB-07 Art. 16(f) + Art. 43(2) Run the conformity assessment before placing on the market — “ ensure that the high-risk AI system undergoes the relevant conformity assessment procedure as referred to in Article 43, prior to its being placed on the market or put into service ” Skarval (provider) Not started Run the internal-control route (§5). FitScreen is already on the market, so sequencing the assessment against the application date is the first planning question. Art. 16 — Reg (EU) 2024/1689 OB-08 Art. 16(g), (h) Draw up the EU declaration of conformity and affix CE marking — “ draw up an EU declaration of conformity in accordance with Article 47 ” Skarval (provider) Not started Produce the declaration and CE marking as outputs of OB-07 — they attest the assessment, they don't replace it (Arts. 47–48 content not fetched). Art. 16 — Reg (EU) 2024/1689 OB-09 Art. 16(i) Register FitScreen per Article 49(1) — “ comply with the registration obligations referred to in Article 49(1) ” Skarval (provider) Not started Plan registration in the EU database — the one the fetched Art. 26(8) text calls “the EU database referred to in Article 71”. Note the fetched scope: Art. 26(8)'s register-check and non-use duty binds deployers “that are public authorities, or Union institutions, bodies, offices or agencies” — not private customers. Private enterprise deployers will still check the database in procurement, so an unregistered listing costs deals either way. Art. 16 — Reg (EU) 2024/1689 OB-10 Art. 16(j) Corrective actions and information duties — “ take the necessary corrective actions and provide information as required in Article 20 ” Skarval (provider) Partial An internal incident process exists; extend it so it can produce the corrective actions and information Article 20 requires (content not fetched — scoped in the engagement). Art. 16 — Reg (EU) 2024/1689 OB-11 Art. 16(l) Accessibility compliance of the system — “ ensure that the high-risk AI system complies with accessibility requirements in accordance with Directives (EU) 2016/2102 and (EU) 2019/882 ” Skarval (provider) Gap Add accessibility conformance of the recruiter and candidate-facing UIs to the backlog. This duty sits in Art. 16 itself, not in an annex — it is easy to miss. Art. 16 — Reg (EU) 2024/1689 OB-12 Art. 26(6) Deployer log retention of at least six months — Skarval must enable it — “ keep the logs automatically generated by that high-risk AI system […] of at least six months, unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data ” Customer (deployer) Gap FitScreen's tenant default purges decision logs after 90 days, so deployers cannot comply without a manual export. Change the default to ≥ 6-month retention and expose a retention control (§6). Art. 26 — Reg (EU) 2024/1689 Quoted spans are verbatim from the fetched Art. 9 / Art. 16 / Art. 26 / Art. 43 texts; […] marks our elisions. Cross-referenced articles (13, 17, 18, 19, 20, 47, 48, 49) appear in the fetched Art. 16 text by number only — their content was not fetched in this run, so actions stop at what the fetched span requires and say so. Section 5 Conformity-assessment route (Art. 43) The fetched Art. 43(2) settles the route for FitScreen: “For high-risk AI systems referred to in points 2 to 8 of Annex III, providers shall follow the conformity assessment procedure based on internal control as referred to in Annex VI, which does not provide for the involvement of a notified body.” FitScreen sits in point 4 — inside points 2 to 8 — so Skarval self-assesses under Annex VI; no notified body is involved. The notified-body alternatives in the fetched Art. 43(1) apply only to “high-risk AI systems listed in point 1 of Annex III”, which FitScreen is not. (Annex VI itself was not fetched; the route is named here, its contents are scoped in the engagement.) Two more fetched Art. 43 findings matter to a quarterly-retrained system. First: “High-risk AI systems that have already been subject to a conformity assessment procedure shall undergo a new conformity assessment procedure in the event of a substantial modification”. Second, the learning carve-out: “changes to the high-risk AI system and its performance that have been pre-determined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation […] shall not constitute a substantial modification.” Practical consequence for Skarval: describe the quarterly retraining envelope — data sources, metrics, thresholds — inside the initial assessment's technical documentation, or every retrain risks re-opening conformity. Art. 43 — Reg (EU) 2024/1689 Section 6 Deployer duties Skarval must enable (Art. 26) Skarval's customers carry their own obligations as deployers. A provider that makes those duties hard to discharge is selling its customers a compliance problem — so the readiness assessment treats deployer-enablement as provider work. Each row quotes the fetched Art. 26 span and names what FitScreen must ship. Provision Deployer duty (fetched span) What Skarval must ship Art. 26(1) “ take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systems ” Versioned, per-release instructions for use that are complete enough to be operated against. (The provider-side instructions duty lives in Article 13 — referenced in the fetched Art. 26(9) text, not itself fetched in this run.) Art. 26(2) “ assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support ” A review surface where an overseer can see why a candidate ranked where they did and override the shortlist, plus training material that defines what “competence” means for FitScreen. Art. 26(5) “ monitor the operation of the high-risk AI system on the basis of the instructions for use and, where relevant, inform providers in accordance with Article 72 ” A monitoring guide plus a named incident-intake channel. The same fetched paragraph obliges deployers to suspend use and escalate to the provider and the market surveillance authority when use presents a risk — Skarval's support process must be able to receive exactly that call. Art. 26(6) “ keep the logs automatically generated by that high-risk AI system […] of at least six months, unless provided otherwise in applicable Union or national law, in particular in Union law on the protection of personal data ” A tenant retention default of at least six months and a retention control — see register row OB-12; today's 90-day purge makes compliance impossible without manual exports. Art. 26(9) “ use the information provided under Article 13 of this Regulation to comply with their obligation to carry out a data protection impact assessment under Article 35 of Regulation (EU) 2016/679 or Article 27 of Directive (EU) 2016/680 ” A DPIA-consumable documentation pack: processing description, model inputs and outputs, oversight design — structured so a deployer's privacy team can lift it into their GDPR Art. 35 assessment. Art. 26(11) “ shall inform the natural persons that they are subject to the use of the high-risk AI system ” A candidate-notice template and a product hook to deliver it — the fetched text scopes this to Annex III systems “that make decisions or assist in making decisions related to natural persons”, which is what FitScreen does. All spans from the fetched Art. 26 — Art. 26 — Reg (EU) 2024/1689 . Art. 26(7) (informing workers' representatives before workplace use) binds deployers-as-employers and is noted for the deployer playbook rather than rowed here. Section 7 Method note & refusal discipline Sources fetched through the Ansvar gateway. The EU AI Act provisions cited here — Arts. 6, 9, 16, 26 and 43 — were fetched as full-text provision rows; Annex III arrived via search; the AI Office guidance row via the guidance fan-out. Every linked citation preserves the fetched source URL, publisher, and license. Nothing is cited from model recall. The Annex III lookup limitation, on the record. A direct provision lookup for the annex returned “No provision matches EU AI_ACT annex_III.” The grounding row for point 4(a) came from the search fan-out instead, and its fragment is short — which is why the point-4 numbering leans on the fetched AI Office guidance row for corroboration (§3, step 2). A paid engagement closes this by citing the full annex text. Off-topic search rows, named and excluded. The high-risk employment search also returned rows from Regulation (EU) 2023/1542 (batteries, Art. 79), Directive 2014/47/EU (roadside-inspection risk rating, Arts. 5–6), and Regulation (EU) No 3/2014 (vehicle definitions, Art. 2) — lexical matches on “high-risk” phrasing. They were excluded as off-topic; they are listed so the exclusion is checkable. Refusal discipline. Unfetched text is never quoted. Marked analyst in this document: the Art. 3 role definitions (§2), the Annex I negative (§3 step 1), the Art. 5 screen (§3 step 0), the profiling definition (§3 step 4), the application dates (§1), and the contents of the cross-referenced Arts. 13, 17, 18, 19, 20, 47, 48 and 49 (§4). Gaps are marked, never filled with plausible text. What a paid engagement adds. Your real system and a scoping call; the full Section 2 requirements walk; evidence-checked readiness verdicts instead of analyst-assigned ones; the deployer playbook; and a named senior reviewer who confirms or corrects every row before it ships. Section 8 Sign-off Senior review: [shown for format — fictional sample, nothing to certify] Reviewer: [named reviewer — AI-governance / EU-regulatory] Date: [—] A paid engagement ships only after the named reviewer has validated every row and signed here. This sample is published unsigned, on purpose, so you can read the document exactly as it leaves the engine. Want this for a real system? Scope an AI Act readiness assessment → Try the free AI Act high-risk checker → --- ## Sample vulnerability deferral dossier — CRA-era example · Ansvar AI URL: https://ansvar.eu/services/sample-deferral-dossier A sample deferral dossier from a real production run — KEV and Art. 14 flags on real CVEs, fetched CRA/NIS2 pin-cites, and the control-investment plan. Use cases Sample deferral dossier — the vulnerability you can't patch AquaSCADA RTU-Link 4 (DEMO) — a fictional water-utility SCADA gateway · a completed production run of the deferral_dossier workflow, re-emitted through the production render pipeline Scope: one asset, one scanner export · Method: deferral_dossier workflow (contextual scoring + regulatory anchoring + investment simulation) · Status: sample This is a fictional sample from a real run. AquaSCADA and its operator are invented so we can publish a complete deliverable without exposing a client — but the run is real: a completed production execution of the deferral_dossier workflow over real CVEs. Every score is the risk engine's verbatim output, every regulatory anchor was fetched live from the statute corpus with its source, publisher, and license carried into the evidence register, and the pages below are the production render pipeline's actual output. Risk scoring is experimental decision support and is labeled as such inside the artifact. Section 1 Why this document exists On September 11, 2026 , CRA Article 14 starts requiring manufacturers to file a 24-hour early warning for actively exploited vulnerabilities, with the main Annex I vulnerability-handling obligations — “address and remediate vulnerabilities without delay” — following on December 11, 2027 . The scope is products with digital elements with a direct or indirect data connection, placed on the EU market (Art. 2; sectoral carve-outs apply). In OT, you can't patch on demand: firmware is certification-frozen, patching means a line stop, the vendor's fix isn't validated for your hardware generation. Today the record of “why we haven't patched, and why that's acceptable” lives in spreadsheets and engineers' heads. The deferral dossier is that record as a defensible document — per-finding evidence that deferrals are managed and invested against, not ignored. Section 2 The dossier, page by page Compact and auditor-legible — this run renders to four pages. Every number is the risk engine's own output, every citation was fetched from the statute during the run, and everything the engine declined to do is stated in the artifact itself — down to its refusal to emit an empty VEX when nothing was contextually adjusted. Position at a glance: 5 deferred findings, 4 KEV-listed, 0 unresolved anchors — and the adjudicated CRA/NIS2/GDPR basis, each anchor carrying its verbatim adjudication. The deferral records: real CVEs (Log4Shell, Heartbleed, Zerologon class) with engine-verbatim scores, Art. 14 fact flags, and the operator's rationale carried as their assertion. The investment plan with the immovable floor — and the VEX section documenting the engine's refusal to emit an empty artifact when nothing was contextually adjusted. Scope limits stated plainly, and the evidence register: 7 anchors with source, publisher, and license carried verbatim from the corpus fetch. Download the sample PDF Section 3 Records, law, plan — then back into your scanner Per-finding deferral records. Contextual CVSS with KEV and EPSS from the effective-risk engine, the named rules that credited your compensating controls, and your deferral rationale carried verbatim as your assertion. KEV-listed or actively exploited findings get a deterministic Art. 14 flag — a fact statement with both phased dates, not legal advice. Regulatory anchors, fetched live. Applicability is adjudicated before anything is cited. CRA Art. 13, Art. 14, and the Annex I vulnerability-handling points arrive as pin-cites fetched from the corpus at run time — with source, publisher, and license on every row. An anchor that doesn't resolve is labeled unresolved, not invented. The investment plan and the immovable floor. One engine simulation over the deferred set answers which controls verifiably lower it most, in what order — and which findings no modeled control moves, each with the engine's reason, from “patch or replace regardless” down to “no rule covers this yet.” Deferral becomes “mitigated and invested against,” not “parked.” The VEX round-trip. When your export carries component refs, a CycloneDX VEX flows the re-prioritized result back into Dependency-Track — re-prioritized, never suppressed, with exclusions named per CVE. Exploitable, or a false positive? Your agent gathers the evidence — you decide. The same gateway serves what an exploitability call needs: KEV listing, EPSS, known public exploits, CVE details, and contextual scoring against your asset's exposure and controls. Your engineer records the review decision, and the dossier carries it verbatim as the only authoritative disposition — the difference between “the scanner said so” and “we determined it, and here's the evidence.” Section 4 Nothing in it is fabricated Every score is read verbatim from the engine — re-deriving, averaging, or rounding is forbidden, and the workflow's gates check the fetch happened and the declared totals match the rows. Every citation is fetched during the run and carries its source, publisher, and license. No citation from model memory, ever. The dossier never claims a finding is “not affected” — only a review decision recorded by your own people is ever shown as authoritative. Gaps are named per item: an unresolved anchor, an unscored CVE, a rationale without evidence — each is flagged, none is smoothed over. Section 5 Run it on your own export 01 · Export your findings. From Dependency-Track (CycloneDX + VEX or a finding export), Trivy, Grype, Snyk, or GitHub Advisories. We consume a scan — we never invent one: an SBOM with no findings is sent back to be scanned first. 02 · Run it from your own agent. Connect Claude Desktop, Copilot Studio, or any MCP client to the Ansvar gateway. You confirm the scope, the asset context, and every deferral rationale before scoring begins — and you review the assembled dossier before the report is generated. 03 · Hand over the artifact. A compact report for the auditor (this sample: four pages), the JSON report for your records, the VEX for your scanner when your findings carry component refs. Register your maintenance-window plan or pen-test as evidence and the dossier cites it with a tamper-evident paragraph reference. # after connecting your agent to gateway.ansvar.eu: Here is our Dependency-Track export for the packaging-line SCADA node. Run a vulnerability deferral dossier — we defer these findings until the Q4 line stop; our rationale and controls are below. The deferral dossier runs on the Team tier and up . Have an export? Your first dossier is one session away — or we run it as an operator-reviewed engagement, where a named expert reviews the deliverable before it ships. See Team pricing Talk to us The sample above is fictional and says so on every page. Risk scoring is experimental decision support and is labeled as such in the artifact; outputs require review by a qualified expert — in delivered engagements, ours. The dossier records and evidences your deferral position — it does not issue conformity determinations, and its Art. 14 flags are fact statements, not legal advice. --- ## Pricing · Ansvar AI URL: https://ansvar.eu/pricing Start free — one jurisdiction or framework per question, CVE/KEV/EPSS intel, one workflow run a month. Solo €29/mo spans them all. Premium adds case law. Free, Solo, Premium & Team are self-serve · Company for orgs Start free. Widen what one question can reach . Free asks one jurisdiction or framework at a time, and runs one threat model a month. Solo asks them all at once — every jurisdiction in one question — and runs two. Premium adds the legal evidence layer — case law and agency guidance, cited verbatim — inside the workflow run as well as the answer, plus the rest of the threat-model families. Team runs workflows on your own documents. Every tier keeps the same citation contract: cited or marked unresolved, never guessed. What do you need? Cited answers across every jurisdiction — Solo . Evidence a lawyer would demand — Premium . Assessments on your own documents — Team . A signed, provable audit trail — Company . An expert to deliver it — Services . On every tier Full citation contract — every answer cited or marked unresolved EU-hosted; BYOK — your model traffic never passes through us Seats fit people or agents — same quota, same citations Actionable refusals at the quota, never silent degradation Same standard of truth at every tier — no cheaper answer, only a narrower reach Monthly Yearly 2 months free Prices excl. VAT Free Evaluate Ansvar, one jurisdiction or framework at a time €0 free forever 100 search calls / day · fair use Free features: Sign in with Google, Microsoft, or email — no card, no VAT entry Single jurisdiction or framework per question Full citation contract CVE, KEV and EPSS threat intelligence included 1 workflow run / month — threat model, NIS2/DORA/CRA/AI Act gap analysis or DPIA, watermarked report Not included: Every jurisdiction in one question Legal evidence layer (case law, preparatory works, agency guidance) Audit ledger Start free No credit card required Solo One seat — a person or an agent — with the whole fleet in one question €29 per month, billed monthly 750 search calls / day · fair use All Free features, plus: Every jurisdiction and framework in one question 49 licensing-audited countries · 262 security frameworks 750 calls a day — headroom for real research Shows when case law exists for what you searched — reading it is Premium 2 workflow runs / month — the same seven types as Free, watermarked report Not included: Legal evidence layer (case law, preparatory works, agency guidance) Start Solo · monthly Cancel anytime ✦ Most popular Premium Defensible research — case law and agency guidance, cited verbatim €249 per month, billed monthly 5,000 search calls / day / seat · fair use All Solo features, plus: Every jurisdiction and framework in one question Legal evidence layer — case law, preparatory works, agency guidance, cited verbatim EU regulations, DORA/NIS2, and ISO/NIST control references IETF security RFCs — TLS, OAuth, the protocol standards corpus Full interview-grounded workflow catalog on a system you describe — LINDDUN, TARA, DPIA/FRIA, gap analysis and more — 5 runs / month Not included: Upload your own documents Audit ledger Start Premium · monthly Cancel anytime Scaling to a team? Premium is one seat. When compliance is a function — more deliverables a month, grounded in your own documents, seats for the team and its agents — these two step up. Team A compliance function — workflows on your own documents, SSO €490 per seat / month From 1 seat — €490/month 50,000 search calls / day · org-pooled · fair use All Premium features, plus: Workflows on your own documents — DPIA, gap analysis, tender review — 20 runs / seat / month Effective-risk CVE rescoring + OpenVEX export Document upload — paragraph-level, tamper-evident citations Shared workspaces, SSO, quota pooled across the org Service credentials — standing agents on their own seats Not included: Audit ledger Seats − + € 490 /mo · 1 seat × € 490 /mo Start Team · monthly Cancel anytime Company Regulated orgs that need the signed audit ledger Custom talk to sales 500,000+ search calls / day · org-pooled · more by contract · fair use All Team features, plus: Per-tenant cryptographic audit ledger — signed receipts Dedicated Hetzner cluster, fully shielded from other tenants Custom retention windows, SLAs, and premium support Talk to sales We reply in writing One question to the gateway is one call against your quota — no matter how many of the 224 servers it fans out to. Quotas are sized for agents, not typing speed: a seat can belong to a person or to an agent, and a research agent may spend hundreds of calls on one deliverable. A workflow run is one assessment taken from start to finish: the workflow asks its questions in your own client, and produces a cited, exportable document — a threat model, DPIA, gap analysis, or tender review — not a chat transcript. On Free and Solo the included runs cover seven types — STRIDE threat model, gap analysis (generic or NIS2, DORA, CRA, EU AI Act) and DPIA — on a system you describe, and the report comes back as a watermarked render carrying a self-asserted banner, or as structured JSON. The full interview-grounded catalog and case law inside the run start at Premium; unwatermarked branded exports and document-grounded runs are Team and up. Need the deliverable, not the tool? Fixed-scope engagements, priced per engagement: see consulting services compare Every tier, side by side. Three questions, one table: how much you can ask, what a question can reach, and what it produces. Free €0 Solo €29/mo Premium €249/mo Team €490/seat/mo Company custom Capacity Daily searches one question = one call, regardless of fan-out — sized for agents, not typing speed; Company's figure is the contractual floor, raised by contract 100 750 5,000 per seat 50,000 org-pooled 500,000+ org-pooled Parallel requests how many calls your client or agent can have in flight at once 3 4 5 16 64 Knowledge Scope per question Free answers one jurisdiction or one framework per question; Solo and up fan out across all 224 servers in one call one jurisdiction or framework full fleet full fleet full fleet full fleet Legal evidence layer case law · preparatory works · agency guidance — Solo shows that decisions exist; Premium reads them — shows it exists ✓ ✓ ✓ IETF security RFCs TLS, OAuth, and the protocol standards corpus — — ✓ ✓ ✓ Deliverables Structured workflows one run = one assessment taken start to finish, producing a cited report — Free and Solo pick from seven types (threat model, gap analysis incl. NIS2/DORA/CRA/AI Act, DPIA) on a system you describe, reported as a watermarked render or JSON; Premium runs the full interview-grounded catalog; Team runs them on your uploaded documents 1 / mo (watermarked) 2 / mo (watermarked) 5 / mo 20 / seat / mo custom Document upload paragraph-cited review under your retention policy — — — ✓ ✓ SSO & shared workspaces — — — ✓ ✓ Service credentials org-owned credentials for headless clients — n8n, CI, scheduled agents; each takes a seat of its own with the same tool surface as a signed-in seat on your plan. Create and rotate at Team and up; revoke works on any plan, so a downgrade never strands a live credential — — — ✓ ✓ Audit ledger per-tenant cryptographic receipts, signed — — — — ✓ Coverage grows continuously — new corpora and jurisdictions ship most weeks. The best way to check what’s live today: connect your AI client and ask the gateway itself (“what can you reach?”). The Free tier is enough for that. Live now · add-on module Any ISO standard, served over MCP. Under a licence agreement with SIS — the Swedish Institute for Standards — Ansvar serves licensed clause and control text of ISO standards as MCP server connections, cited and attributed to the source standard instead of paraphrased from model memory. Five standards are live today; any standard SIS publishes can be licensed in on request. Standards are priced per seat — the same price whether a person or one of your agents holds it. Volume discounts are available; talk to us if you need seats in bulk. SS-EN ISO/IEC 27001:2023 · SS-EN ISO/IEC 27002:2022 · SS-EN ISO/IEC 27005:2024 · SS-EN ISO/IEC 42001:2026 · SS-ISO/SAE 21434:2021 Choose your standards Talk to us Licensed supplier questions The four questions procurement asks. Architecture answers first — billing and contract answers in the FAQ below. byo client Do I need a new chatbot? No. Ansvar is one MCP connection for the AI client your team already runs — Claude, Claude Code, Cursor, VS Code Copilot, Open WebUI — or for an agent you run headless. The gateway is a router, not a chatbot. sovereignty Where does my data live? EU-hosted core (Hetzner), with edge and backups disclosed on our subprocessors page. MCP servers never store client data — your context stays in your client. This website runs no tracking cookies and no third-party trackers — one functional cookie remembers your plan when you sign in. byok What is BYOK? Bring your own key. Your client calls its model with your key; there is no LLM inside the gateway. It routes, fans out, and attaches citations — your model traffic never passes through us. refusal discipline What happens at the quota? An actionable refusal: your tier, your usage, your reset time, the upgrade path. Never silent degradation, never a thinner answer dressed up as a full one. Billing and contracts Is the Free tier only for businesses? What's included in the Free tier? Do I need a VAT number or card for the Free tier? How do I start? Can a seat belong to an agent instead of a person? Which tiers are self-service today? What does 'commission custom connectors' mean? Do you offer a DPA? --- ## Security & sovereignty · Ansvar AI URL: https://ansvar.eu/security EU-hosted on Hetzner, with no server-side model — your AI client talks to your provider directly. Honest compliance labels and inspectable data connectors. Security & sovereignty EU-hosted. No server-side model. Provenance on every answer. The things your procurement team asks about on call #2. Data residency stated plainly, model traffic that never reaches our infrastructure, and source citations you can verify on every served row. Three pillars Trust · Sovereignty · Openness Each pillar has a concrete answer. Where something is planned rather than shipped, the label says so. EU-hosted infrastructure The gateway and the MCP server fleet run on our own Kubernetes platform on Hetzner in the EU — immutable node OS with no SSH, and every production change lands as a reviewed GitOps pull request. Cloudflare provides edge and TLS termination in front, under SCCs and the EU-US Data Privacy Framework — we state that plainly rather than claiming nothing ever crosses a border. Hosted on Hetzner in the EU Cloudflare edge/TLS under SCCs · EU-US DPF GDPR-compliant DPA for all paid tiers Swedish entity, EU law governs Bring your own AI client You connect your own AI client — Claude Desktop, Microsoft Copilot Studio, Cursor, or a custom MCP client. Ansvar runs no server-side model: model traffic flows directly from your client to your model provider. We never see or proxy it, and your model bill stays on your account. The one exception is expert-delivered engagements, where Ansvar operates the run for you — the privacy notice describes that path. Works with any MCP-capable AI client OAuth 2.1 — PKCE + Dynamic Client Registration No server-side model at Ansvar Model traffic never proxied or stored by us Inspectable data layer Every answer carries item-level provenance: the source URL, publisher, and licence of each cited row, pointing at the original publisher — never a mirror. Source licences are verified before ingestion, fail-closed: a corpus that fails the licensing gate is not built, and a repository is public only while its source-licensing audit stays GREEN; the gateway, its reusable hosting chassis, and licensed data are private. Reproducible, digest-pinned corpus builds from version-controlled sources are the standard for new and updated corpora; the remaining estate migrates as it is touched, and this label changes when coverage is complete. Source, publisher, and licence cited on every served row Licensing verified before ingestion — fail-closed Deterministic citation validation, verifiable MCP servers store no client data Architecture posture Defense in depth Every request crosses three control planes before it reaches your data. A tamper-evident audit trail records every transition across all of them. Request From your AI client S1 Network perimeter TLS 1.3 · Cloudflare + Traefik Kubernetes NetworkPolicy isolation Continuous vuln + exposure scanning S2 Identity & authZ OAuth 2.1 · PKCE · DCR Per-request tier authZ SCIM: planned S3 Data plane EU-hosted · Hetzner Kubernetes Sealed secrets · OpenBao KMS Forensic audit logging Customer data EU-hosted · minimised — MCP servers store none Audit trail Append-only and tamper-evident. Every transition across every stage. Company tier Compliance posture Where we stand on frameworks Honest labelling. We tell you what is certified, what is aligned, and what is in progress — because the difference matters in procurement. GDPR Compliant · DPA available CSA STAR Level 1 Self-assessment published · Jul 2026 ISO 27001 In preparation · certification planned ISO 42001 Aligned EU AI Act Aligned NIS2 Aligned Data residency EU-hosted (Hetzner) · Cloudflare edge under SCCs Where data lives EU-hosted infrastructure, model traffic that never reaches us Two data paths, stated plainly. Infrastructure data sits on Hetzner in the EU behind Cloudflare's edge; model traffic flows directly between your AI client and your model provider. EU-hosted infrastructure Gateway and MCP server fleet on our own Kubernetes platform, hosted on Hetzner in the EU Cloudflare provides edge and TLS termination under SCCs / EU-US DPF Envelope-encrypted secrets (OpenBao KMS), NetworkPolicy isolation between services Immutable node OS with no SSH — every production change is a reviewed GitOps pull request Forensic audit logging on every request MCP servers store no client data Your model traffic Your AI client calls your model provider directly No server-side model at Ansvar — with your own client connected, we never see or proxy model traffic What we do see: the MCP tool calls your client sends the gateway (queries, lookups) Your provider's retention terms and your model bill stay between you and them MCP-first architecture — no vector store, no RAG copy of your data Security FAQ Questions we answer before the DPA is signed If yours isn't here, request the security questionnaire. We return it within five business days for paid-tier evaluations. Do you train on our data? No. Ansvar runs no server-side model and never sees model traffic — it flows directly from your AI client to your model provider. Customer data is never used for training, evaluation, or fine-tuning. Your provider's own retention terms apply on that direct path. Where Ansvar operates a run for you — expert-delivered engagements — the same no-training rule applies, and the model provider's published retention terms govern that path. How is our data isolated? MCP servers store no client data. What the gateway does hold — account and entitlement records, audit logs — sits on EU-hosted Kubernetes infrastructure with NetworkPolicy isolation between services and envelope-encrypted secrets (OpenBao KMS). What's your incident response? 72-hour notification to customer admins for any security incident affecting customer data, aligned to GDPR Art. 33 timelines. Do you support SSO and SCIM? SSO: yes — sign in with Microsoft Entra ID, Google, or username and password. SCIM 2.0 is planned; it is not built today. Can we self-host? Not as a self-serve product today — the gateway is a hosted EU service. But on-prem is where we are heading: a customer-deployable version of the platform exists and is exercised in CI on every merge, and we are open to a design partner to shape the first production deployment inside a customer's own perimeter. If that is you, get in touch. The gateway runtime and base images remain private; a small set of connector repositories is public on GitHub where licensing allows. What about penetration testing? Our first third-party pentest is planned for 2026. No report exists yet — we will not claim one until it does. How do I report a security vulnerability? Email security@ansvar.eu, with a PGP key on request. We aim to acknowledge within one business day. Our Terms otherwise prohibit probing the Service, so the responsible disclosure section on this page is the permission: it authorises good-faith research, sets the scope, and states the safe harbour that applies if you stay inside it. We run no paid bounty — a valid finding may earn a credit in our acknowledgments and a numbered “I hacked Ansvar” coin, decided after triage. Didn't see your question? Send a security question . Responsible disclosure Report a vulnerability Our Terms otherwise prohibit probing the Service, so this section is the permission: we authorise good-faith security research on the systems below, and we will not take legal action over research that follows this policy. In scope ansvar.eu, app.ansvar.eu, and gateway.ansvar.eu Reaching another tenant's data, audit logs, organisation membership, or billing, whether you can read it or change it Authentication and authorisation flaws: OAuth and MCP token confusion, session leakage, tier or entitlement bypass Injection, server-side request forgery, and remote code execution Exposed credentials, keys, or customer data, including our own misconfiguration of Cloudflare, Vercel, or Hetzner Corpus integrity: source or cache poisoning, provenance tampering, or a bypass of licensing suppression Out of scope Missing security headers, cookie flags, or TLS settings with no demonstrated impact SPF, DKIM, and DMARC gaps without impact you can demonstrate on a domain or mailbox you control Clickjacking on pages that change no state, and rate limits with no demonstrated security impact Version banners, and scanner output with no proof of concept Denial of service and load testing, social engineering, physical testing, and flaws in Cloudflare, Vercel, or Hetzner themselves Wrong or missing citations in served content. That is a support matter, and rights complaints go through content claims. How to report Email security@ansvar.eu. PGP key on request. Send what you found, the steps to reproduce it, and the impact as you read it. We aim to acknowledge within one business day, and to tell you what we decided once we have triaged it. Stop at proof. Do not pull customer data, pivot further into our estate, or run load tests. If you reach another tenant's data, stop and tell us. That finding is already complete. Give us 90 days before you publish, and tell us when you plan to. What we offer No paid bounty. We would rather say so than imply a payout that is not there. A credit in the acknowledgments below, under your name, your handle, or nothing at all. We ask before we publish anything. A numbered “I hacked Ansvar” coin, which we make ourselves and do not sell. We decide both after triage, at our discretion. Recognition is not compensation, and we do not price a finding before we have read it. Safe harbour Stay in scope, use only accounts you own or may use, and avoid disrupting the service. Access no more data than proves the finding, keep no copies, and delete what you took. Report promptly and agree publication timing with us. Do that and we will not start legal action over your research, and we will confirm to others that it was authorised. We cannot waive our customers' or licensors' rights, and this binds no public authority. Acknowledgments We have not credited anyone yet. Once we have fixed a valid report, we list the researcher here the way they asked to be named. --- ## Contact · Ansvar AI URL: https://ansvar.eu/contact Talk to Ansvar Systems AB — sales, support, and source suggestions. Every message gets an answer from a human. Direct email: team@ansvar.eu. Contact Talk to a human . Every message goes to a person, not a queue. Tell us what you are working on and we come back with a useful answer — usually within one business day. Talk to sales Ask a question Email: team@ansvar.eu — reaches the whole team and gets routed to the right person. Use it for anything that does not fit the forms: partnerships, press, procurement paperwork, security disclosures. Sales and engagements: the sales form above, or start from Pricing and Services . Free, Solo, Premium and Team are self-serve; Company goes through this form and we reply in writing. Missing a source? If a law, regulator, or standard you need is not in Coverage , suggest it: request a source . We answer with an honest read on licensing and timeline. Content claims and legal notices: claims@ansvar.eu — see the notice & complaints procedure and DMCA policy . Company: Ansvar Systems AB · Org.nr 559547-2225 · Fränsta, Sweden. EU-hosted; see Security & sovereignty . --- ## About · Ansvar AI URL: https://ansvar.eu/about Ansvar AI is built by Ansvar Systems AB — a Sweden-based team building auditable AI for legal, compliance, and security workflows. EU-hosted. About Building auditable AI from Sweden. Ansvar Systems AB is an EU company based in Sweden. We build an MCP-native knowledge layer for legal, compliance, and security work — with the citation contract as the product. Talk to us How it works Ansvar Systems AB (Org.nr 559547-2225) is registered in Fränsta, Sweden. We ship auditable AI for legal, compliance, and security workflows — everything we build is grounded in source text, with verified citations on every answer. Our delivery is 100% via the gateway. Connect your own AI client — Claude Desktop, Microsoft Copilot Studio, Cursor, or any MCP client — and get legislation and case-law research, DPIAs and DORA/NIS2 gap analysis, STRIDE and TARA threat modeling, and ISO/NIST control reviews with exact sources on every claim. Ansvar is founded and led by Jeffrey von Rotz, Founder & CEO. The company was started on one rule — citations or nothing: a compliance answer that cannot point to its source is not an answer. The core platform runs on EU infrastructure (Hetzner, Germany & Finland) with every subprocessor disclosed, every source we serve is licensing-audited, and nothing you send Ansvar trains anyone's model. The detail lives on three pages: Security & sovereignty , how our AI operates , and recognition & third-party validation . Get in touch: team@ansvar.eu · Fränsta, Sweden · contact page --- ## Recognition & third-party validation · Ansvar AI URL: https://ansvar.eu/recognition Where Ansvar AI is independently listed and reviewed: OWASP GenAI Security Solutions Landscape, MCP directories, editorial coverage, and a tool-surface scan. Recognition Independently listed, used, and reviewed Third-party signals, ordered by how strong they are — from production usage and a reviewed OWASP landscape to automated directory listings. We label each for what it is: directory entries are indexes, not endorsements. Independent validation Listed, used, and reviewed by others The strongest signals: a third party used our product in their own work, a reviewed OWASP landscape, and independent editorial coverage. Listed in OWASP GenAI Security Project ↗ AI Security Solutions Landscape — AI & Agentic Red Teaming Scope & Plan · Govern Q2 2026 · A reviewed community resource — not an endorsement. Used by regenold × W&B Weave ↗ Reliable AI Agents in regulatory life science workflows Our EU Regulations MCP as the agent's grounded, cited data backend Mar 2026 Covered by ChatForest ↗ Independent editorial review of the legal & compliance MCP landscape Profiles Ansvar's EU Compliance MCP and national-law suite 2026 · Independent, unsponsored coverage. In the MCP ecosystem Indexed across MCP directories Our public connectors are listed in community MCP catalogues. These are automated directory listings — discoverability, not an endorsement. Listed in Claude connector directory (Anthropic) ↗ Ansvar AI — one-click connector for claude.ai and Claude Desktop Community listing; Connect runs the gateway's standard OAuth flow Jul 2026 · Listed after Anthropic's automated checks — not an endorsement. Viewing requires a Claude login. Published in Official MCP Registry ↗ eu.ansvar/gateway — remote server entry (streamable HTTP, OAuth) Canonical registry entry; most directories ingest from it. Indexed by GitHub MCP Registry ↗ eu.ansvar/gateway — Ansvar: EU Compliance & Legal Intelligence Ingested from our official MCP Registry entry Jul 2026 · Automated directory listing. Indexed by PulseMCP ↗ MCP directory listing — Ansvar Gateway (official) Automated directory listing. Indexed by Glama ↗ Remote-connector listing — Ansvar: EU Compliance & Legal Intelligence Automated directory listing. Listed in Awesome MCP Servers ↗ Official gateway listing — community MCP server index (mcpservers.org) Directory listing, accepted 2026-07-09. Supersedes the earlier entry for the archived EU-compliance standalone. Published in Smithery ↗ MCP registry listing — ansvar/gateway (remote server, OAuth 2.1) Jul 2026 · Self-submitted listing — discoverability, not an endorsement. Security & trust Public security posture Checkable posture signals: the Cybersecurity Made in Europe label, our CAIQ self-assessment published in the CSA STAR Registry, and an external scan of the tool surface. Posture signals, not third-party audits (our first pentest is planned for 2026). Labelled by ECSO · European DIGITAL SME Alliance ↗ Cybersecurity Made in Europe label European HQ and ownership, majority-EU cybersecurity R&D, ENISA baseline security practices — declared by us, reviewed and issued by DIGITAL SME under the ECSO label scheme Aug 2026 · A declaration-based trust label, not a certification or audit. Listed in Cloud Security Alliance ↗ STAR Registry — Level 1 CAIQ v4.0.3 self-assessment for Ansvar Gateway All 261 questions answered and published, including the honest No's Jul 2026 · A published self-assessment, not a third-party certification. Scanned by PolicyLayer ↗ Independent tool-surface scan — 5 read-only tools, low risk Verified 2026-06-12 A tool-surface scan, not a full security audit. --- ## Legal & Regulatory Coverage — audited jurisdictions · Ansvar AI URL: https://ansvar.eu/coverage Source-licensed, content-validated coverage of legal jurisdictions, security frameworks, and regulatory domains — EU/EFTA-first, live and in development. coverage The law that applies to your business, covered and citable . Check whether your country, your regulations and your sector are covered today. Each answer names its source and clears a licence audit before we serve it — and every figure here is read live from that data, not written as marketing copy. 49 Jurisdictions live 340k+ National laws indexed 5.8M Provisions, article-level 119 Corpora built — live + pre-release figures read from coverage.json · file generated 2026-08-07 coverage explorer Do we cover you? Ask by country , by framework , or by sector — the same three scopes your AI agent uses against the gateway. Only what is live and licence-audited appears; grey means not covered. 1 Find your scope Map List or highlight a domain: Statute law 49 Case law 18 +EU Data protection 21 Cybersecurity 1 +EU Sector regulators 1 +EU Europe DK FI SE IS AT DE BE LU NL ES PT MT FR CZ HR HU SK PL SI LT LV EE RO BG LI GB CH CY GR IE IT North America US National statutes, served via the gateway: Japan Armenia Taiwan South Korea Costa Rica Albania San Marino Qatar Brazil Ukraine Serbia Paraguay Uruguay Georgia Kosovo Norway Djibouti Trinidad & Tobago Bahrain Peru Guatemala Haiti darker = more domains serving (dots = count) in development not covered Jurisdiction Statute law Case law Data protection Cybersecurity Sector regulators Laws Provisions United States ✓ ✓ ✓ ✓ ✓ 10,244 380,164 Austria ✓ ✓ ✓ EU EU 5,101 56,760 Belgium ✓ ✓ ✓ EU EU 5,778 143,390 Czechia ✓ ✓ ✓ EU EU 45,899 461,571 Denmark ✓ ✓ ✓ EU EU 62,764 621,260 Estonia ✓ ✓ ✓ EU EU 1,602 64,000 Finland ✓ ✓ ✓ EU EU 8,586 161,785 Germany ✓ ✓ ✓ EU EU 4,753 92,295 Hungary ✓ ✓ ✓ EU EU 4,316 130,568 Iceland ✓ ✓ ✓ — — 1,710 19,033 Latvia ✓ ✓ ✓ EU EU 2,250 58,063 Netherlands ✓ ✓ ✓ EU EU 3,254 78,001 Poland ✓ ✓ ✓ EU EU 805 74,651 Slovakia ✓ ✓ ✓ EU EU 4,089 55,921 Slovenia ✓ ✓ ✓ EU EU 40 11,970 Sweden ✓ ✓ ✓ EU EU 6,045 59,064 Croatia ✓ EU ✓ EU EU 4,511 161,423 France ✓ ✓ — EU EU 3,958 193,793 Liechtenstein ✓ — ✓ — — 3,614 73,213 Lithuania ✓ ✓ — EU EU 12,047 89,810 Romania ✓ EU ✓ EU EU 12,001 112,545 Spain ✓ EU ✓ EU EU 12,183 298,241 United Kingdom ✓ — ✓ — — 3,243 514,115 Albania ✓ — — — — 8,749 113,037 Armenia ✓ — — — — 6,416 223,942 Bahrain ✓ — — — — 1,622 14,506 Brazil ✓ — — — — 4,805 54,934 Bulgaria ✓ EU — EU EU 1,997 17,103 Costa Rica ✓ — — — — 16,724 120,455 Djibouti ✓ — — — — 2,747 27,027 Georgia ✓ — — — — 943 35,463 Guatemala ✓ — — — — 8 5,539 Haiti ✓ — — — — 11 3,811 Japan ✓ — — — — 8,953 252,261 Kosovo ✓ — — — — 1,039 31,409 Luxembourg ✓ EU — EU EU 4,554 36,098 Malta ✓ EU — EU EU 5,009 56,516 Norway ✓ — — — — 739 29,222 Paraguay ✓ — — — — 7,073 38,822 Peru ✓ — — — — 2,131 13,857 Portugal ✓ EU — EU EU 1,130 81,012 Qatar ✓ — — — — 9,428 71,155 San Marino ✓ — — — — 10,992 104,807 Serbia ✓ — — — — 822 47,041 South Korea ✓ — — — — 6,494 214,578 Taiwan ✓ — — — — 11,747 221,082 Trinidad & Tobago ✓ — — — — 533 21,562 Ukraine ✓ — — — — 8,165 50,710 Uruguay ✓ — — — — 4,768 37,131 2 What's serving there Jurisdiction United States 5 of 5 domains serving nationally Statute law ✓ national Case law ✓ national Data protection ✓ national Cybersecurity ✓ national Sector regulators ✓ national 10,244 laws 380,164 provisions Source-licence audit ● GREEN Content validated 2026-03-02 Full United States coverage → EU The EU layer — served once, inherited by every member state The EU-level regulation, guidance and supervisory content every member state inherits (18 corpora) — the live facets are listed here. That's the “+ EU” you see on member-state answers. EU regulations Case law Cybersecurity Sector regulators Read from coverage.json (generated 2026-08-07 ). A scope appears only when its corpus is live and its source-licensing audit is GREEN; EU-level coverage applies in member states via the EU corpus, independent of national tiles. the fleet Three clusters. One connection. Your AI client connects once, over OAuth. The gateway routes each call to the servers in scope; the answers come from the sources, not from a model. law · 57 servers Statutes & regulation National law and EU regulation, segmented to article level. 346,392 laws serving across 49 audited jurisdictions — 5.8 M provisions in the live tier. GDPR Art. 33(1) NIS2 Art. 23(4) DORA Art. 18(1) sector regulators · 92 servers Sector regulators The supervisory layer above the statute. Calls are routed by country and sector to the regulators your business actually answers to. BaFin EIOPA CNIL domain · 75 servers Security & threat domain Vulnerability intelligence, threat modeling, sanctions, OWASP, and the security frameworks your controls map to. ISO 27001 A.5.24 OWASP In active development Already in our corpus, currently in licensing audit, content validation, or structural recovery. 🇨🇭 Switzerland recovery 🇨🇾 Cyprus recovery 🇬🇷 Greece recovery 🇮🇪 Ireland recovery 🇮🇹 Italy recovery Coverage by sector What we cover for each sector — regulations and standards a live, source-licensed corpus serves today. Standards are surfaced as requirement mapping, not reproduced text. Premium adds case law and agency guidance. 🛡️ IT & cloud security AppSec, infrastructure security, and product-security obligations. · Cyber Resilience Act (Reg (EU) 2024/2847) · NIS2 (Dir (EU) 2022/2555) · GDPR Art. 32 — security of processing · Control mapping: OWASP ASVS · NIST CSF/800-53 · ISO 27001 Annex A · CIS · MITRE ATT&CK · MITRE ATT&CK · CAPEC · CWE · D3FEND · CVE · CISA KEV · EPSS — live vulnerability context Explore Security → 🤖 AI governance EU AI Act role classification, obligations, and conformity readiness. · EU AI Act (Reg (EU) 2024/1689) · Risk classification — prohibited practices (Art. 5), high-risk (Art. 6 + Annex III) · Role duties — provider (Art. 16), deployer (Art. 26), FRIA (Art. 27), conformity (Art. 43) · GPAI & systemic-risk model provisions (Art. 51–55) · GDPR intersection — automated decisions (Art. 22), DPIA trigger (Art. 35) · EU AI Office guidance · premium · ISO/IEC 42001 — AI management systems Explore AI governance → 🔐 Privacy & data protection DPIA, privacy-by-design, transfers, and data-subject rights — grounded in GDPR. · GDPR (Reg (EU) 2016/679) · ePrivacy Directive (2002/58/EC) · Law Enforcement Directive (EU) 2016/680 · GDPR Art. 22 — automated individual decision-making · National GDPR-implementation statutes · Case-law fan-out where licensing permits · premium Explore Privacy → 🏛️ Public sector Procurement lawfulness, public-body AI duties, and administration compliance. · National public-procurement law · Procurement case law & preparatory works · premium · EU AI Act Art. 27 — public-body FRIA duty · GDPR Art. 35 — public-body DPIA basis · NIS2 (Dir (EU) 2022/2555) Art. 21 — public-administration security Explore Public sector → 💳 Financial services DORA, MiCA, PSD2 and the prudential stack — at article level, with the technical standards. · DORA (Reg (EU) 2022/2554) · DORA RTS/ITS — 11 technical-standard instruments · MiCA (Reg (EU) 2023/1114) + RTS/ITS · PSD2 (Dir (EU) 2015/2366) · MiFID II / MiFIR · CRR/CRD · Solvency II · EMIR · Horizontal: GDPR · NIS2 · EU AI Act · eIDAS2 · Control mapping: ISO 27001 · NIST · Case law · agency guidance · preparatory works · premium Explore Financial → 🚗 Automotive Vehicle cybersecurity engineering, TARA, and type-approval evidence. · UN R155 (cybersecurity) · UN R156 (software update) · Control mapping: ISO/SAE 21434 · Control mapping: UDS · DoIP · SOVD · AUTOSAR diagnostics · Repair & maintenance information access — RMI / SERMI · Horizontal: Cyber Resilience Act · GDPR (connected-vehicle data) Explore Automotive → 🚁 Drone & UAS Drone operations, product security, threat modelling, and counter-UAS. · EU drone law — Reg (EU) 2019/947 (operations) · 2019/945 (product) · UAS threat library · Control mapping: UAS standards stack · National UAS rules + US 14 CFR Part 107 · Horizontal: Cyber Resilience Act · RED · GPSR Explore Drone / UAS → 🌾 Agriculture & machinery Autonomous-machinery safety and the AI duties that ride on top. · Machinery Regulation (EU) 2023/1230 · EU AI Act — high-risk safety-component duties (Reg (EU) 2024/1689) · Control mapping: agri-machinery safety stack (ISO 4254 · ISOBUS 11783 · ISO 25119 · IEC 62061 · EN 690) · Control mapping: functional safety & autonomous-machine stack (ISO 12100 · ISO 13849 · ISO 18497 · ISO 3691-4 · ISO 10218) · Farm-data governance — EU Data Act (Reg (EU) 2023/2854) · EUDR (Reg (EU) 2023/1115) — deforestation-free supply-chain duties · Horizontal: Cyber Resilience Act · GDPR Explore Agri & machinery → 🏥 Healthcare & medical devices Medical-device regulation, clinical data, and special-category privacy. · Medical Device Regulation (Reg (EU) 2017/745) · In Vitro Diagnostic Regulation (Reg (EU) 2017/746) · Clinical Trials Regulation (Reg (EU) 536/2014) · European Health Data Space (Reg (EU) 2025/327) · GDPR Art. 9 — special-category health data (+ full GDPR) · Horizontal: NIS2 · EU AI Act (software as a medical device) · CRA · MDCG medical-device guidance · premium Explore Healthcare → 🏭 Industrial / OT / ICS OT security, robot-cell safety, and live ICS advisory enrichment. · Control mapping: IEC 62443 (1-1…4-2) · Control mapping: ISO 10218-1/-2:2025 + the safety-security bridge · OT protocol security models: Modbus/TCP, DNP3, OPC UA, PROFINET, EtherNet/IP (CIP), IEC 61850/62351, BACnet/SC · EU Machinery Regulation (EU) 2023/1230 · Cyber Resilience Act · NIS2 · CISA ICS/OT advisories Explore Industrial / OT → 🤖 Robotics & automation Robot and cobot safety, machinery conformity, and the security of the robot stack. · Machinery Regulation (EU) 2023/1230 · EU AI Act — high-risk safety-component duties (Reg (EU) 2024/1689) · Control mapping: ISO 10218-1/-2:2025 + ISO/TS 15066 collaborative operation · Control mapping: functional safety (ISO 12100 · ISO 13849) + IEC 62443 industrial cyber · ROS 2 / DDS security + robot exploitation chains · Horizontal: Cyber Resilience Act · NIS2 Explore Robotics → 🚆 Rail & signalling Railway cybersecurity and signalling safety, from CLC/TS 50701 zones to the safety case. · Control mapping: CLC/TS 50701 railway cybersecurity · Control mapping: EN 50126 RAMS · EN 50129 signalling safety case · Control mapping: IEC 62443 industrial cyber · ENISA transport threat landscape — railway · Horizontal: NIS2 (Dir (EU) 2022/2555) · CER (EU) 2022/2557 Explore Rail → ⚡ Energy & utilities Grid and generation compliance, anchored on NIS2 essential-entity duties. · National energy statutes · NIS2 (Dir (EU) 2022/2555) · Critical Entities Resilience Directive (EU) 2022/2557 · Cybersecurity Act (EUCC) · Cyber Solidarity Act · Energy case law · preparatory works · agency guidance · premium Explore Energy → 🌍 ESG & sustainability Sustainability reporting and the EU green-finance taxonomy, at article level. · CSRD (Dir (EU) 2022/2464) · EU Taxonomy Regulation (Reg (EU) 2020/852) · CBAM (Reg (EU) 2023/956) 📡 Telecommunications National regulatory-authority decisions and NIS2 operator obligations. · National telecom regulatory-authority decisions · premium · NIS2 — telecom-operator obligations 🛰️ Defense & aerospace Aviation-information-security regulation and national security-protection law. · EASA Part-IS (Reg (EU) 2023/203) · National security-protection law · Horizontal: NIS2 More sectors in development Chemicals & REACH — Chemicals Regulation is serving while its methodology corpus completes a content review. Maritime — Maritime security is held offline pending a source-licensing audit. Listed only where a live MCP serves the corpus and its source licensing is GREEN. Per the No Silent Fallbacks policy, planned coverage is in the "in development" list, not above. beyond the map Not everything we work from is something we can hand you as data. This page maps what you query directly through the gateway — corpora that cleared source-licensing review and come back clause by clause, with a citation. Some of what our work rests on can’t be served that way. It still shapes the answer; it reaches you as advice and synthesis, not a feed you pull. served as data The corpora on this page. Licensed to reproduce, addressable to the clause, returned in the same citation envelope as every other Ansvar source. You query them; you cite them. served as advice Sources we can reference but not republish — licensed standards we map to controls rather than reproduce, confidential engagement material, method that was never a document. We hold these off the gateway and put them to work in our consultancy and delivery, as synthesis, attributed to where it came from. the line we hold We never dress synthesis up as a source you could have pulled yourself, and we never serve licensed text we can’t defend. When a point rests on advice rather than a citeable provision, it says so. What we can’t expose as data, we still bring to the work. Missing a corpus you need? Tell us. Every framework, jurisdiction, and sector above has cleared source-licensing review. We add new corpora when a real customer workflow needs them and the licensing audit closes — we'd rather say "not yet" than serve content we can't defend. Tell us the source, the workflow it would unlock, and any license terms you already know about. We come back with an honest read on whether we can host it and roughly how long the licensing review would take. Suggest a source → Check your jurisdiction from your own client. One MCP connection to gateway.ansvar.eu — Claude, Claude Code, Cursor, VS Code Copilot, or Open WebUI. Free tier: 100 searches a day with a B2B sign-up. Start free Ask about coverage --- ## Gateway rate limits & quotas · Ansvar AI URL: https://ansvar.eu/limits Per-tier rate limits, concurrency caps, and the Free daily search quota for the Ansvar MCP Gateway, plus the JSON-RPC error contract for caps and hidden tools. Rate limits & quotas What your AI client sees when it's close to a limit . Reference for developers integrating the Ansvar Gateway. Rate limits are abuse protection, not a product gate — they're sized so legitimate workloads never approach them. Every tier has a daily search quota; Free is set apart by its size ( 100 calls per day) and its scope — one jurisdiction or framework per question. Every limit fails with the same machine-readable JSON-RPC error. Per-tier limits today The live enforcement contract Five tiers, three mechanisms: a per-user token bucket on request rate, a per-tier concurrency cap, and a daily search budget on every tier — per seat on Free, Solo and Premium, pooled per organisation on Team and Company. These are the numbers production enforces today. Tier Daily quota Concurrency Sustained rate Burst capacity Free 100 search calls / day 3 60 rpm (≈ 1 req / s) 100 tokens Solo 750 search calls / day 4 120 rpm (≈ 2 req / s) 200 tokens Premium 5,000 search calls / day per seat 5 600 rpm (≈ 10 req / s) 1,000 tokens Team 50,000 search calls / day, pooled per organisation 16 1,200 rpm (≈ 20 req / s) 2,000 tokens Company 500,000 search calls / day, pooled per organisation 64 2,400 rpm (≈ 40 req / s) 4,000 tokens How the limits are enforced today. The daily search budgets and the per-tier concurrency caps are exact: they run on a shared Redis cap store, counted once across every gateway worker, and they fail closed — if the store is unreachable the call is rejected rather than quietly allowed. The per-minute figures above are different: they are per-user nominal thresholds for abuse protection, enforced by a per-process token bucket, so with four workers and round-robin request distribution a single user's effective sustained rate can exceed the nominal figure before the limiter rejects a call. We state that rather than hide it, because the per-minute numbers are sized so legitimate workloads never approach them. If you need a contracted, audit-grade per-tenant cap, that's the Company tier. Hosted onboarding. Regulated teams on guided onboarding are provisioned at Team tier in the authentication layer, so they get Team-tier capabilities and Team-tier limits — including structured workflows. Burst behaviour. Every tier's bucket holds roughly 100 seconds of full-throttle calls before refill matters (100 tokens at 1 req/s, 200 at 2 req/s, 1,000 at 10 req/s, 2,000 at 20 req/s, 4,000 at 40 req/s). Once empty, refill happens continuously at the sustained rate. What fires, when Three limits, one error shape Every limit on this page fails the same way: the tool call returns a JSON-RPC error with code -32000 and the machine-readable string cap_exceeded. The failure arrives inside the MCP session — there is no HTTP 429 on this path. 1. Per-minute rate limiter One token bucket per user — sustained rate plus burst capacity from the table above. This is abuse protection, not a product gate: thresholds are sized so legitimate workloads never approach them. All tiers 2. Daily search budget Every tier carries one: 100 search calls per day on Free, 750 on Solo, and 5,000 on Premium, each per seat; 50,000 on Team and 500,000 on Company, pooled across the organisation — every seat draws from one shared counter, and a refusal says so. Paid budgets are abuse ceilings sized well above legitimate workloads, not product gates. All tiers 3. Concurrency cap A ceiling on simultaneous in-flight requests per user: 2 on Free, 3 on Solo, 4 on Premium, 16 on Team, 64 on Company. Parallel fan-out from your AI client counts against it — serialise calls if you hit it. All tiers Burst capacity is generous (≈ 100 seconds of full-throttle calls) so well-behaved AI clients rarely see cap_exceeded . If yours is hitting a limit, the cause is almost always parallel fan-out without coordination — serialise calls or reduce concurrency. Error shapes Two machine-readable failures Limits and tier gating surface as JSON-RPC errors, not as HTTP status codes. Match on the error code and the cap_exceeded string — never on the human-readable message text. -32000 · cap_exceeded Any limit on this page — the rate limiter, a daily search budget, or the concurrency cap. The error object carries JSON-RPC code -32000 with the machine-readable code "cap_exceeded" . Back off and retry; a daily quota won't clear until the window resets. Caps & quotas -32601 · Method not found The tool exists, but not on your tier — for example search_guidance on Free, or document-workflow tools on Premium. Tier-hidden tools are also absent from tools/list , so a well-behaved AI client never calls them. Retrying never helps. Tier-hidden tools cap_exceeded is the machine-readable signal — pattern-match this rather than parsing the message. If you see -32601 , check tools/list : the gateway only advertises the tools your tier can actually call. Sample retry logic What well-behaved client code looks like Back off on cap_exceeded with bounded retries so a transient cap doesn't become a retry storm. Never retry -32601 — the tool isn't on your tier, and no amount of waiting changes that. import time MAX_RETRIES = 3 CAP_EXCEEDED = "cap_exceeded" def call_with_backoff(call_tool, name: str, arguments: dict): """call_tool is your MCP client's tool-call function. JSON-RPC errors surface differently per SDK (return value or exception); normalise to (code, text, result) first.""" for attempt in range(MAX_RETRIES): code, text, result = call_tool(name, arguments) if code is None: return result if code == -32601: # Tool is not on your tier. Retrying never helps. raise PermissionError(f"{name} is not available on this tier") if code == -32000 and CAP_EXCEEDED in text: # Rate limiter, concurrency cap, or a daily quota. # A daily quota will not clear until the window resets, # so keep retries bounded. time.sleep(2 ** attempt) continue raise RuntimeError(f"Gateway error {code}: {text}") raise RuntimeError(f"{CAP_EXCEEDED} after {MAX_RETRIES} retries") If your AI client hits cap_exceeded frequently, the right move is usually to reduce parallel fan-out (run searches sequentially within a workflow rather than firing all jurisdictions at once). If the sustained workload genuinely needs more capacity than your tier provides, talk to us about the Company tier. Sizing your usage Pick a tier without a sales call A typical workflow run fans out to 10–50 gateway calls. Both rate and concurrency bind: parallel fan-out counts against your tier's concurrency cap before the rate limiter matters. Free · 1 req / s B2B-gated evaluation. One jurisdiction or framework per question, with a 100 -call daily quota and concurrency 2 — enough to test grounded answers against your jurisdictions, not enough to run production workloads. Includes 1 STRIDE threat-model run a month on a system you describe, reported as JSON; the run stops at the allowance rather than billing overage. Evaluation Solo · 2 req / s Full-fleet research for one seat: every jurisdiction and framework in one question. 750 search calls / day, concurrency 3, and 2 STRIDE threat-model runs a month on a system you describe, reported as JSON. No legal evidence layer — that starts at Premium, along with the LINDDUN and TARA families and the rendered report exports. One seat Premium · 10 req / s Heavy individual research with premium fan-out: case law, preparatory works, and agency guidance alongside the base sources. 5,000 search calls / day per seat, concurrency 4, plus 5 workflow runs a month on a system you describe. Workflows on your own documents live on Team and above. Individual Team · 20 req / s Multi-seat compliance work with structured workflows (DPIA, gap analysis, tender review, threat model) and concurrency 16. Guided-onboarding customers are provisioned at Team tier today. Multi-seat Company · 40 req / s Adds the tamper-evident audit ledger and concurrency 64. Capacity is contracted — sustained rates above 40 req/s are negotiated per agreement. Per contract Counts are flat: every successful gateway tool call is one unit, regardless of how many downstream MCPs the call fans out to. On Solo and above, a search that hits 30 MCPs counts the same as a single get_provision . Free-tier search reaches one jurisdiction or framework per question, and each call counts one of the 100 per day. What's coming The per-minute rate limiter Daily budgets and concurrency caps already run on the shared Redis cap store — exact across workers, fail-closed. The one counter still held per worker process is the per-minute token bucket, and moving it to the same shared store is the open enforcement item. This page tracks the live contract — when enforcement changes, the table above changes with it. If your workload is bumping against the current limits, get in touch — Company-tier capacity is contracted, and we'd rather size it with you than have you engineer around a cap. Need different limits? Compare tiers on the pricing page, or talk to us about a Company contract with custom capacity. See pricing Discuss custom limits --- ## How Ansvar AI operates · Ansvar AI URL: https://ansvar.eu/ai-governance How Ansvar AI operates: your AI client talks to your model provider directly, with deterministic citation validation, EU-hosted retrieval, no model training. AI Governance AI governance at Ansvar — how we actually operate. Auditable AI requires honest operating posture. Here's how we handle model access, data retention, training, and the citation pipeline that sits between the model and its sources. Model access (bring your own AI client) Ansvar runs no server-side AI model . You connect your own AI client — Claude Desktop, Microsoft Copilot Studio, Cursor, or a custom MCP client — to the gateway over OAuth 2.1. Model traffic flows directly from your client to your model provider; Ansvar never sees, stores, or proxies it, and never holds your model keys. Training on customer data We do not train, fine-tune, or evaluate any model on customer data. Uploaded documents, query text, and citation metadata are used only to serve the user's own workflow. Your model provider's retention terms apply to the traffic between your AI client and that provider — a path Ansvar is not on. Citation validation pipeline Every citation that leaves the gateway passes through a deterministic (non-model) validation pipeline: article numbers are resolved against corpus indexes, paragraph anchors are checked, URLs are verified to return the cited text. Failed citations are shown as unavailable, not silently dropped or fallen back to AI guesswork. Retrieval transparency Our standalone legal connectors carry Apache 2.0 code and go public only where their source-licensing audit returns GREEN — inspect them at github.com/Ansvar-Systems . You can audit how each one reaches its source; the chassis that serves them in production, and the licensed data itself, stay private. Data residency Infrastructure runs on Hetzner in the EU. Cloudflare provides edge and TLS termination in front, under SCCs and the EU-US Data Privacy Framework — the same disclosure our Terms make. Model traffic flows directly from your AI client to your model provider and does not cross our infrastructure. Audit logs stay in-region. Model versions and determinism Model choice and version are set in your AI client, not by Ansvar — there is no Ansvar-side model to pin. What Ansvar controls is deterministic: retrieval, cross-referencing, and citation validation return the same sources for the same question across runs. Questions? Security overview covers procurement-grade architecture. For a written answer to a specific question, contact team@ansvar.eu. --- ## Ansvarsfull AI · Ansvar AI URL: https://ansvar.eu/sv/ansvarsfull-ai Citerade svar för svenska compliance-team: EU:s AI-förordning, GDPR och ISO 42001 — med artikelnivå-citat från publika källor, driftat inom EU. Ansvarsfull AI Ansvarsfull AI med citerbara källor — för svenska compliance-team. EU:s AI-förordning, GDPR och ISO 42001 i samma flöde som ditt team redan använder. Ansvar AI levererar svar med artikelnivå-citat från publika regulatoriska källor — så att beslut kan motiveras, inte gissas. Utgångsläge Tre regelverk i kraft, ett gemensamt arbetsflöde EU:s AI-förordning, GDPR och informationssäkerhetsregelverk löper inte parallellt — de överlappar. Ansvarsfull AI handlar om att hantera dem som ett sammanhängande arbete, inte som tre separata projekt. För svenska organisationer är frågan sällan om AI ska användas — utan hur. EU:s AI-förordning, GDPR och sektorsregelverk som NIS2 ställer alla krav som tillämpas vid samma användningsfall. Ett rekryterings-AI kan samtidigt klassas som hög risk enligt AI-förordningen, kräva DPIA enligt GDPR och omfattas av arbetsrättsliga regler. Den gemensamma nämnaren är dokumentation: en bedömning som håller för revision, baserad på de faktiska lagtexterna, inte på sammanfattningar. "Ansvarstagande AI" och "ansvarsfull AI" används om vartannat i svensk debatt. Båda beskriver samma sak: att AI-system används med spårbar bedömning av risk, dataskydd och regelefterlevnad — och att den bedömningen är hänvisningsbar till källor som faktiskt finns. AI-förordningen Fyra risknivåer — fyra olika kravbilder Risknivå avgör vilka skyldigheter som faller på leverantör respektive användare. Klassificeringen är inte valbar; den följer av systemets användningsområde. Förbjudna användningar Vissa AI-användningar är otillåtna oavsett samtycke eller kontext — exempelvis vissa former av social scoring, manipulation och realtids-biometrisk identifiering i offentliga utrymmen. Listan är uttömmande och tolkas snävt. Hög risk AI-system med betydande inverkan på grundläggande rättigheter — i sektorer som rekrytering, kreditbedömning, utbildning, brottsbekämpning och kritisk infrastruktur. Kraven omfattar riskhantering, datastyrning, teknisk dokumentation, mänsklig översyn, noggrannhet och cybersäkerhet. Konformitetsbedömning är obligatorisk innan systemet får släppas på marknaden eller tas i bruk. Begränsad risk Transparenskrav: användaren ska informeras om att de interagerar med ett AI-system (chatbotar, deepfakes, känsloigenkänning). Skyldigheterna är lättare men gäller från och med ibruktagande. Minimal risk Ingen formell skyldighet under AI-förordningen, men frivilliga uppförandekoder uppmuntras. GDPR och övriga regelverk gäller naturligtvis fortfarande. Konsekvensbedömningar DPIA och FRIA — två bedömningar, olika fokus GDPR:s konsekvensbedömning (DPIA) och AI-förordningens FRIA är inte samma sak och kan inte ersätta varandra. DPIA (Data Protection Impact Assessment) följer av GDPR Artikel 35 och krävs när behandlingen sannolikt innebär en hög risk för registrerades rättigheter — typiskt vid storskalig behandling av särskilda kategorier, systematisk profilering eller övervakning av offentliga utrymmen. Bedömningen är dataskyddscentrerad. FRIA (Fundamental Rights Impact Assessment) införs av AI-förordningen Artikel 27 och träffar specifika högriskanvändningar — främst när offentliga organ eller leverantörer av samhällsviktiga tjänster sätter ett högrisk-AI-system i bruk. Bedömningen är rättighets­centrerad och tittar bredare än enbart dataskydd. För många användningsfall — exempelvis ett AI-baserat rekryteringsverktyg hos en kommun — krävs båda bedömningarna parallellt. De ska kunna granskas separat och måste vara spårbara till de specifika lagrum de bygger på. Så hjälper Ansvar AI Citerade svar i din befintliga AI-klient Du behöver ingen ny produkt att lära dig. Ansvar AI ansluter Claude, Cursor, Copilot Studio och andra MCP-kompatibla klienter till publika regulatoriska källor. Varje svar levereras med artikelnivå-citat. När en jurist frågar "vilka skyldigheter har vi som leverantör av ett högrisk-AI-system enligt EU:s AI-förordning?" pekar svaret tillbaka till de faktiska artiklarna — inte till modellens uppskattning av vad lagen säger. Källorna är publika och inspekterbara. Plattformen drivs inom EU (Hetzner). Modelltrafiken går direkt från din AI-klient till din modelleverantör — Ansvar varken ser eller vidarebefordrar den, och vi kör ingen egen AI-modell på serversidan. Vi tränar inte modeller på kunddata. Bakgrunden till hur det faktiskt fungerar finns på AI Governance -sidan. Idag täcker Ansvar AI 49 granskade jurisdiktioner, EU-förordningar, säkerhetsramverk och sektorsregelverk. Täckningen utökas endast när källicensiering, uppdateringscykel och citatkvalitet är validerade. Vanliga frågor Frågor vi får från svenska compliance-, juridik- och säkerhetsteam Om din fråga inte finns med — skriv till oss. Vi svarar på alla mejl. Vad är ansvarsfull AI? Ansvarsfull AI — också kallat ansvarstagande AI — innebär att AI-system används med dokumenterad risk-, dataskydds- och regelefterlevnadsbedömning. För svenska organisationer handlar det främst om att hantera EU:s AI-förordning, GDPR och tillämpliga sektorsregelverk parallellt, med spårbar dokumentation som håller för revision. Vad kräver EU:s AI-förordning av min organisation? Det beror på rollen och risknivån. Leverantörer, distributörer, importörer och slutanvändare har olika skyldigheter. AI-system delas in i fyra risknivåer — förbjudna, hög risk, begränsad risk och minimal risk — och kraven skalar därefter. AI-modeller för allmänna ändamål (GPAI) har egna transparens- och dokumentationskrav som tillämpas separat från de risknivåbaserade kraven. Är ISO 42001 ett krav? Nej, ISO/IEC 42001:2023 är frivillig. Den är ett ledningssystem för AI och fungerar som ramverk för att visa att en organisation systematiskt hanterar AI-risker. Certifiering kan vara värdefull i upphandlingar och som komplement till regulatorisk efterlevnad, men ersätter inte AI-förordningens krav. När krävs en konsekvensbedömning? GDPR Artikel 35 kräver en DPIA vid behandling som sannolikt innebär en hög risk för registrerades rättigheter. AI-förordningen kräver dessutom en FRIA (Fundamental Rights Impact Assessment) för vissa högrisksystem, framför allt när offentliga organ eller leverantörer av samhällsviktiga tjänster använder dem. De två är separata bedömningar med olika fokus och kan behöva göras parallellt. Vilken myndighet övervakar AI-förordningen i Sverige? Sverige har vid skrivande stund inte slutgiltigt utsett en samordnande myndighet, men IMY (Integritetsskyddsmyndigheten) väntas få en central roll — särskilt för frågor som rör grundläggande rättigheter och dataskydd. Marknadskontrollen kan komma att fördelas över flera sektorsmyndigheter beroende på AI-systemets användningsområde. Hur skiljer sig Ansvar AI från en vanlig AI-chatbot? Ansvar AI är en gateway som ansluter din befintliga AI-klient (Claude, Cursor, Copilot Studio och andra MCP-kompatibla klienter) till publika regulatoriska källor via Model Context Protocol. Varje svar levereras med artikelnivå-citat som går att verifiera. Modellen genererar text — men källorna kommer från granskade, öppna anslutningar, inte från modellens träningsdata. Vill du se hur det fungerar i praktiken? Boka en genomgång där vi visar Ansvar AI mot ett av era egna scenarion — en DPIA, en AI-förordnings­bedömning, en gap-analys. Vi går igenom citatpipelinen, källornas ursprung och hur svaren kan försvaras för en revisor. Boka genomgång Se prissättning Produkten och prissidan är för närvarande på engelska. --- ## DSGVO- und KI-VO-Compliance mit auditfähigen Nachweisen · Ansvar AI URL: https://ansvar.eu/de/dsgvo-compliance DSGVO- und KI-VO-Compliance im eigenen KI-Client: artikelgenaue Zitate, auditfähige DSFA- und Gap-Analyse-Reports, stets aktuelle Rechtsquellen. EU-gehostet. DSGVO-Compliance DSGVO-Compliance mit zitierbaren Quellen — für deutsche Datenschutz- und Compliance-Teams. DSGVO, KI-Verordnung und ISO 42001 im selben Workflow, den Ihr Team bereits nutzt. Ansvar AI liefert Antworten mit artikelgenauen Zitaten aus öffentlichen regulatorischen Quellen — damit Entscheidungen begründet werden, nicht geraten. Ausgangslage Drei Regelwerke, ein gemeinsamer Workflow DSGVO, KI-Verordnung und sektorale Regelwerke greifen ineinander — nicht parallel. DSGVO-Compliance heißt heute, sie als zusammenhängende Arbeit zu behandeln, nicht als drei separate Projekte. Für deutsche Unternehmen stellt sich selten die Frage, ob personenbezogene Daten verarbeitet werden — sondern wie nachweisbar regelkonform. DSGVO, KI-Verordnung, NIS2 und sektorale Anforderungen treffen häufig auf denselben Anwendungsfall. Ein KI-gestütztes Recruiting-Tool ist gleichzeitig Hochrisiko nach KI-VO, DSFA-pflichtig nach Art. 35 DSGVO und arbeitsrechtlich relevant. Der gemeinsame Nenner ist Dokumentation: eine Bewertung, die einer Aufsichtsprüfung standhält und nachvollziehbar auf den tatsächlichen Gesetzestext verweist — nicht auf Zusammenfassungen. Genau hier entstehen die meisten Lücken zwischen Anspruch und Praxis. DSGVO-Pflichten Die zentralen Pflichten — strukturiert nach Artikel Datenschutz-Compliance lässt sich auf einige wenige Kernpflichten reduzieren. Was im Einzelfall darunter hängt, ergibt sich aus dem Anwendungsfall. Rechtsgrundlage und Zweckbindung (Art. 5, 6) Jede Verarbeitung braucht eine Rechtsgrundlage aus Art. 6 (Einwilligung, Vertrag, rechtliche Verpflichtung, lebenswichtige Interessen, öffentliches Interesse oder berechtigtes Interesse). Die Zwecke müssen festgelegt, eindeutig und legitim sein — eine Erweiterung des Zwecks im Nachhinein ist ohne erneute Rechtsgrundlage nicht zulässig. Informationspflichten (Art. 13, 14) Betroffene Personen müssen zum Zeitpunkt der Erhebung (Art. 13) oder spätestens innerhalb eines Monats (Art. 14) über Identität des Verantwortlichen, Zwecke, Rechtsgrundlage, Empfänger, Speicherdauer und ihre Rechte informiert werden. Datenschutzerklärungen erfüllen diese Pflicht nur, wenn sie konkret und transparent sind. Verzeichnis der Verarbeitungstätigkeiten (Art. 30) Verantwortliche und Auftragsverarbeiter führen Verzeichnisse aller Verarbeitungstätigkeiten in schriftlicher oder elektronischer Form. Pflichtangaben sind im Artikel selbst geregelt — von Verarbeitungszwecken über Empfängerkategorien bis zu geplanten Löschfristen und Drittlandsübermittlungen. Technische und organisatorische Maßnahmen (Art. 32) Verantwortliche und Auftragsverarbeiter setzen geeignete TOM um — unter Berücksichtigung von Stand der Technik, Implementierungskosten, Art und Zweck der Verarbeitung sowie der Risiken für die Betroffenen. Pseudonymisierung, Verschlüsselung, Verfügbarkeit und Belastbarkeit der Systeme sowie regelmäßige Überprüfung der Wirksamkeit sind ausdrücklich genannt. Meldepflichten bei Datenpannen (Art. 33, 34) Verletzungen des Schutzes personenbezogener Daten sind binnen 72 Stunden an die zuständige Aufsichtsbehörde zu melden (Art. 33), bei hohem Risiko zusätzlich an die betroffenen Personen (Art. 34). Die 72-Stunden-Frist beginnt mit dem Zeitpunkt, an dem der Verantwortliche von der Verletzung Kenntnis erlangt. Verträge und Folgenabschätzungen AVV und Datenschutz-Folgenabschätzung — zwei separate Pflichten Auftragsverarbeitungsvertrag und DSFA sind unterschiedliche Instrumente mit unterschiedlichen Auslösern. Sie ersetzen einander nicht. Der AVV nach Art. 28 regelt das Verhältnis zwischen Verantwortlichem und Auftragsverarbeiter — etwa zwischen einem Unternehmen und seinem Cloud-Anbieter. Pflichtinhalte sind unter anderem Gegenstand und Dauer der Verarbeitung, Weisungsbindung, Vertraulichkeitsverpflichtung, TOM, Unterauftragsverarbeitung, Unterstützung bei Betroffenenrechten und Meldepflichten sowie Audit-Rechte. Ohne AVV ist die Beauftragung selbst rechtswidrig. Die DSFA nach Art. 35 betrifft den eigenen Verarbeitungsprozess des Verantwortlichen, wenn dieser voraussichtlich ein hohes Risiko für die Rechte und Freiheiten Betroffener mit sich bringt. Sie ist eine Risikobewertung — keine Genehmigung. Ergibt sich nach der DSFA ein hohes Restrisiko, ist die Aufsichtsbehörde nach Art. 36 zu konsultieren, bevor die Verarbeitung beginnt. Für KI-gestützte Verarbeitungen kommt eine Grundrechte-Folgenabschätzung nach Art. 27 KI-VO hinzu — insbesondere bei bestimmten Hochrisiko-Systemen im öffentlichen Sektor oder bei Anbietern öffentlicher Dienste. Die beiden Bewertungen haben unterschiedliche Schwerpunkte und müssen separat dokumentiert werden. So hilft Ansvar AI Zitierte Antworten in Ihrem bestehenden KI-Client Sie brauchen kein neues Produkt zu erlernen. Ansvar AI verbindet Claude, Cursor, Copilot Studio und andere MCP-kompatible Clients mit öffentlichen regulatorischen Quellen. Jede Antwort wird mit artikelgenauen Zitaten geliefert. Wenn eine Datenschutzbeauftragte fragt "Welche Pflichten habe ich als Verantwortlicher bei einer Datenpanne nach Art. 33?", verweist die Antwort direkt auf den Artikeltext — nicht auf eine Schätzung des Modells. Die Quellen sind öffentlich und überprüfbar. Die Plattform ist in der EU gehostet (Hetzner). Modellanfragen laufen direkt von Ihrem KI-Client zu Ihrem Modellanbieter — Ansvar sieht diesen Datenverkehr nicht und leitet ihn nicht weiter; ein serverseitiges KI-Modell betreiben wir nicht. Wir trainieren keine Modelle mit Kundendaten. Hintergrund zum tatsächlichen Betrieb steht auf der AI Governance -Seite. Heute deckt Ansvar AI 49 auditierte Jurisdiktionen, EU-Verordnungen, Sicherheitsrahmenwerke und sektorale Regelwerke ab. Die Abdeckung wird nur erweitert, wenn Quell-Lizenzierung, Aktualisierungszyklus und Zitatqualität validiert sind. Wie sich dieser Ansatz von GRC-Plattformen, Datenschutzwerkzeugen und KI-Governance-Anbietern unterscheidet, ordnet der Anbieter-Vergleich für DSGVO und KI-VO entlang von sechs Kriterien ein. Häufige Fragen Fragen, die wir von deutschen Datenschutz-, Compliance- und Sicherheitsteams erhalten Wenn Ihre Frage nicht dabei ist — schreiben Sie uns. Wir beantworten jede E-Mail. Was ist DSGVO-Compliance? DSGVO-Compliance bezeichnet den nachweisbaren Zustand, in dem ein Unternehmen die Anforderungen der Datenschutz-Grundverordnung erfüllt — von Rechtsgrundlage über Betroffenenrechte bis zu technischen und organisatorischen Maßnahmen sowie Meldepflichten. Compliance ist kein Zertifikat, sondern dokumentierte Praxis, die einer Aufsichtsprüfung standhält. Welche Pflichten gelten für mein Unternehmen? Das hängt von Rolle (Verantwortlicher oder Auftragsverarbeiter) und Verarbeitungstätigkeit ab. Kernpflichten sind: Rechtsgrundlage je Verarbeitung (Art. 6), Informationspflichten (Art. 13/14), Verzeichnis der Verarbeitungstätigkeiten (Art. 30), technische und organisatorische Maßnahmen (Art. 32), Meldepflichten bei Datenpannen (Art. 33/34) und gegebenenfalls Datenschutz-Folgenabschätzung (Art. 35). Wann ist eine Datenschutz-Folgenabschätzung erforderlich? Artikel 35 DSGVO verlangt eine DSFA bei voraussichtlich hohem Risiko für die Rechte und Freiheiten betroffener Personen — typischerweise bei systematischer und umfassender Bewertung persönlicher Aspekte (Profiling), Verarbeitung sensibler Datenkategorien in großem Umfang oder systematischer Überwachung öffentlich zugänglicher Bereiche. Die Aufsichtsbehörden veröffentlichen Listen, in welchen Konstellationen sie eine DSFA für zwingend halten. Was muss ein AVV nach Artikel 28 enthalten? Ein Auftragsverarbeitungsvertrag muss Gegenstand und Dauer, Art und Zweck der Verarbeitung, Kategorien betroffener Personen und Datenkategorien benennen. Hinzu kommen die Pflichten des Auftragsverarbeiters aus Artikel 28(3) — von der Weisungsbindung über Vertraulichkeitsverpflichtungen und TOM bis hin zur Unterstützung bei Betroffenenrechten, Meldepflichten und Audits durch den Verantwortlichen. Wie hängt die KI-Verordnung mit der DSGVO zusammen? Die KI-Verordnung ergänzt die DSGVO, ersetzt sie nicht. Wenn ein KI-System personenbezogene Daten verarbeitet, gelten beide Regelwerke parallel. Eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO kann erforderlich sein, ebenso eine Grundrechte-Folgenabschätzung nach Art. 27 KI-VO bei bestimmten Hochrisiko-Systemen — insbesondere wenn öffentliche Stellen oder Anbieter öffentlicher Dienste sie einsetzen. Welche Aufsichtsbehörden sind in Deutschland zuständig? Die Zuständigkeit folgt dem föderalen Aufbau. Für Unternehmen sind in der Regel die Landesdatenschutzbeauftragten (LDIs) Ansprechpartner — entscheidend ist der Sitz des Unternehmens. Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) ist für Bundesbehörden, Telekommunikations- und Postdienstleister sowie für bestimmte internationale Sachverhalte zuständig. Wie unterscheidet sich Ansvar AI von einem normalen KI-Chatbot? Ansvar AI ist ein Gateway, das Ihre bestehenden KI-Clients (Claude, Cursor, Copilot Studio und andere MCP-kompatible Clients) über das Model Context Protocol an öffentliche regulatorische Quellen anbindet. Jede Antwort wird mit artikelgenauen Zitaten geliefert, die überprüfbar sind. Das Modell formuliert den Text — die Quellen stammen jedoch aus auditierten, offenen Anbindungen, nicht aus den Trainingsdaten des Modells. Welche Anbieter liefern DSGVO- und KI-VO-Compliance mit auditfähigen Reports? Klassische GRC-Plattformen arbeiten mit Fragebögen und Status-Übersichten; die Nachweise schreibt das Team selbst. Ansvar AI liefert die Nachweise: Datenschutz-Folgenabschätzungen, Gap-Analysen und Threat Models, in denen jede regulatorische Aussage mit einem artikelgenauen Zitat aus der amtlichen Quelle belegt ist. Die Berichte entstehen im KI-Client, den Ihr Team bereits nutzt, und sind als Dokumente exportierbar. Welche Anbieter bieten Monitoring-Dashboards für DSGVO- und KI-VO-Compliance? Monitoring-Dashboards sind das Modell klassischer GRC-Suiten: Status-Ampeln über selbst gepflegten Kontrollen. Ansvar AI ist bewusst kein Dashboard, sondern eine Wissens- und Nachweisschicht — Ihr Team stellt Fragen und erzeugt auditfähige Deliverables im eigenen KI-Client, mit artikelgenauen Zitaten der amtlichen Quelle. Wer laufende Kontroll-Übersichten braucht, kombiniert Ansvar AI mit dem bestehenden GRC-Werkzeug; die zitierten Nachweise entstehen bei Ansvar. Gibt es Compliance-Lösungen, die Rechtsquellen automatisch aktuell halten? Ja. Ansvar AI pflegt die angebundenen Rechtskorpora laufend aus den amtlichen Quellen (EUR-Lex, nationale Gesetzesportale); die Aktualität wird pro Quelle überwacht und ausgewiesen. Antworten und Reports zitieren den geltenden Stand, ohne dass Ihr Team Regelwerke manuell nachpflegt. Ändert sich eine Vorschrift, ändert sich die Quelle, gegen die geprüft wird. Wie wählt man eine Plattform für DSGVO- und KI-VO-Management aus? Vier Kriterien trennen die Ansätze: Überprüfbarkeit — sind Aussagen mit artikelgenauen Zitaten belegt oder nur plausibel formuliert? Abdeckung — deckt die Lösung DSGVO und KI-Verordnung samt nationalem Recht ab oder nur ein Regelwerk? Arbeitsfluss — funktioniert sie in den Werkzeugen, die Ihr Team bereits nutzt, oder ist sie ein weiteres Portal? Datenstandort — wird in der EU gehostet, und bleibt Ihr Inhalt außerhalb des Modelltrainings? Ansvar AI ist auf diese vier Kriterien gebaut. Wo kann man ein Compliance-System kaufen, das DSGVO- und KI-VO-Pflichten unterstützt? Ansvar AI ist direkt unter ansvar.eu buchbar — kostenloser Einstieg ohne Kreditkarte, Self-Service-Abos für Teams und OAuth-Anbindung an Claude, Copilot Studio, Cursor und andere MCP-kompatible Clients. Betrieb und Datenhaltung erfolgen in der EU. Möchten Sie sehen, wie das in der Praxis funktioniert? Buchen Sie eine Demo, in der wir Ansvar AI an einem Ihrer eigenen Szenarien zeigen — eine DSFA, eine KI-VO-Bewertung, eine Gap-Analyse. Wir gehen die Zitat-Pipeline, die Herkunft der Quellen und die Verteidigbarkeit der Antworten gegenüber einer Aufsichtsbehörde durch. Demo buchen Preise ansehen Produkt und Preisseite sind derzeit auf Englisch. --- ## DSGVO- und KI-VO-Compliance: Anbieter im Vergleich · Ansvar AI URL: https://ansvar.eu/de/dsgvo-ki-vo-compliance-anbieter Welche Anbieter liefern DSGVO- und KI-VO-Compliance mit auditfähigen Reports? Vier Lösungskategorien, sechs Kriterien: Zitate, Rechtsaktualität, EU-Hosting. Anbieter-Vergleich Welche Anbieter liefern DSGVO- und KI-VO-Compliance mit auditfähigen Reports ? Vier Lösungskategorien bedienen dieses Feld: klassische GRC-Plattformen, spezialisierte Datenschutzwerkzeuge, KI-Governance-Anbieter und quellenbasierte Nachweislösungen, die im eigenen KI-Client arbeiten. Sie unterscheiden sich weniger im Funktionsumfang als in einer Frage: Wer erbringt den regulatorischen Nachweis, Ihr Team oder das System? Kurzantwort Die vier Kategorien und was sie trennt Wer nach Anbietern für DSGVO- und KI-VO-Compliance sucht, findet vier Grundmodelle. Sie lösen unterschiedliche Hälften der Aufgabe. Klassische GRC-Plattformen führen Kontrollen, Richtlinien, Risiken und Fristen und zeigen deren Status. Sie eignen sich, wenn viele Beteiligte einen gemeinsamen Stand brauchen. Der Gesetzestext liegt in diesem Modell außerhalb des Systems: welche Norm eine Kontrolle trägt, trägt Ihr Team ein. Spezialisierte Datenschutzwerkzeuge bilden das Datenmodell der DSGVO ab: Verarbeitungsverzeichnis, DSFA-Vorlagen, Betroffenenanfragen, Löschkonzepte. Sie sind auf ein Regelwerk zugeschnitten; ob die KI-Verordnung mit abgebildet ist, gehört zu den Fragen unten. KI-Governance-Anbieter arbeiten an den Objekten der KI-Verordnung: Modellinventar, Risikoklassifizierung, technische Dokumentation, Konformitätsschritte. Ob die Datenschutzpflichten am selben System mit abgedeckt sind, lohnt die Nachfrage. Quellenbasierte Nachweislösungen , die Kategorie von Ansvar AI, halten die Rechtsquellen vor und erzeugen daraus belegte Bewertungen: DSFA, Gap-Analyse, Threat Model, jede Aussage mit ihrer Fundstelle. Sie führen keinen Kontrollbestand und keine Status-Ampeln. Der Zugang läuft über den KI-Client, den Ihr Team bereits nutzt. Viele Produkte mischen Elemente mehrerer Kategorien. Die Einordnung beschreibt das jeweilige Grundmodell, nicht ein einzelnes Produkt. Vergleichskriterien Sechs Kriterien, an denen sich die Kategorien trennen Funktionslisten gleichen sich. Diese sechs Achsen zeigen, welches Grundmodell Sie kaufen. Laufende Überwachung Zwei verschiedene Dinge tragen hier denselben Namen. Kontroll-Monitoring beobachtet Ihren internen Umsetzungsstand und zeigt ihn als Status. Quellen-Monitoring beobachtet das Recht selbst und meldet, wenn eine Vorschrift sich ändert. Fragen Sie im Gespräch nach, welches der beiden gemeint ist. Auditfähige Reports mit Quellenzitaten Die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO verlangt, dass Sie die Einhaltung nachweisen können, nicht nur behaupten. Ein Report ist auditfähig, wenn eine Prüferin eine Stichprobe ziehen und mit der maßgeblichen Fassung abgleichen kann. Entscheidend ist die Granularität der Fundstelle: Verweise auf ein ganzes Regelwerk sind kein Nachweis, Verweise auf Artikel und Absatz sind einer. Dabei bleibt eine Grenze bestehen, die kein Anbieter aufhebt: Ein Zitat belegt, was die Norm verlangt, nicht dass Sie sie umgesetzt haben. Für die Rechenschaftspflicht nach Art. 5 Abs. 2 und Art. 24 DSGVO kommen validierte organisatorische Nachweise aus Ihrem Betrieb und deren fachliche Prüfung hinzu. Die Fundstelle ist die halbe Akte, nicht die ganze. Automatische Aktualisierung bei Rechtsänderungen Ändert sich eine Vorschrift, ändert sich die Grundlage jeder darauf gestützten Bewertung. Klären Sie, wer die Quellen nachführt und in welchem Takt, ob der Stand je Quelle ausgewiesen wird und woran Sie erkennen, dass eine Bewertung auf einer überholten Fassung beruht. KI-VO-Abdeckung Ein KI-gestütztes Bewerbungsverfahren fällt regelmäßig unter Anhang III der KI-VO und gilt damit grundsätzlich als Hochrisiko-KI-System; ob die Einstufung im Einzelfall greift, ist nach Art. 6 Abs. 3 KI-VO zu prüfen. Davon getrennt steht die Frage, ob die Verarbeitung nach Art. 35 DSGVO ein voraussichtlich hohes Risiko birgt und deshalb eine DSFA verlangt. Deckt eine Lösung nur eines der beiden Regelwerke ab, führen Sie zwei Vorgänge über denselben Sachverhalt und müssen deren Ergebnisse selbst zusammenführen. EU-Hosting und Datenresidenz Zwei Fragen, die auseinandergehalten gehören: Wo läuft die Anwendung, und wo läuft das Sprachmodell? Werden dabei personenbezogene Daten an einen Empfänger in einem Drittland offengelegt, greifen die Anforderungen des Kapitels V DSGVO; der Standort von Anwendung oder Modell allein entscheidet das nicht. Lassen Sie sich beide Wege getrennt beschreiben, klären Sie, welche Inhalte tatsächlich übermittelt werden, und lassen Sie sich den Umgang mit Modelltraining schriftlich geben. Integrationsweg Jedes zusätzliche Portal kostet Einführung und Gewöhnung. Prüfen Sie, ob die Lösung in den Werkzeugen arbeitet, die Ihr Team ohnehin bedient, ob sie sich an bestehende Systeme anbinden lässt und wie die Ergebnisse dort landen, wo sie gebraucht werden. Übersicht Die richtigen Prüffragen je Kategorie — und wie Ansvar AI sie beantwortet Statt Behauptungen über fremde Produkte: die Frage, die Sie je Kriterium und Kategorie stellen sollten, daneben unsere eigene Antwort. Kriterium GRC-Plattform: fragen Sie Datenschutzwerkzeug: fragen Sie KI-Governance: fragen Sie Ansvar AI: unsere Antwort Laufende Überwachung Überwacht das System nur unsere Kontrollen oder auch die Rechtsquelle? Meldet es Änderungen am Normtext oder nur eigene Fristen? Wird das Modellinventar überwacht oder die Rechtslage? Quellenaktualität je Korpus, ausgewiesen; keine Kontroll-Ampeln Auditfähige Reports Wer schreibt den Nachweistext, das System oder unser Team? Sind die Fundstellen im Report gepflegt oder mitgeliefert? Deckt die technische Dokumentation auch Datenschutzpflichten ab? Fundstelle je Aussage; die Umsetzung bleibt gesondert nachzuweisen Rechtsänderungen In welchem Takt wird der Regelwerksbestand nachgeführt? Wird der Stand je Quelle ausgewiesen? Wie erfahren wir von delegierten Rechtsakten und Leitlinien? Laufende Nachführung aus der Quelle, Stand je Quelle KI-VO-Abdeckung Ist die KI-VO ein eigenes Modul oder ein Fragebogen? Werden KI-VO-Pflichten im Datenmodell überhaupt abgebildet? Sind die Datenschutzpflichten am selben System mit abgedeckt? KI-VO und DSGVO im selben Vorgang EU-Hosting Wo laufen Anwendung und Datenhaltung? Wo läuft ein eingesetztes Sprachmodell, und was wird ihm übermittelt? Fließen unsere Inhalte in Modelltraining? EU-Betrieb, kein serverseitiges Modell, kein Training mit Kundendaten Integrationsweg Kommt ein weiteres Portal hinzu? Lässt sich das Werkzeug an unsere Systeme anbinden? Arbeitet es in den Werkzeugen, die wir bereits nutzen? MCP-Anbindung im vorhandenen KI-Client Die drei Kategoriespalten enthalten Prüffragen, keine Aussagen über einzelne Anbieter. Nur die Ansvar-Spalte beschreibt ein konkretes Produkt. Einordnung Wo Ansvar AI steht — und wo nicht Die ehrliche Abgrenzung spart Ihnen eine Demo: Ansvar AI ist eine Nachweislösung, kein Verwaltungssystem. Ansvar AI ist ein Gateway. Ihr eigener KI-Client (Claude, Copilot Studio, Cursor oder ein anderer MCP-fähiger Client) verbindet sich einmal per OAuth und erreicht darüber die angebundenen Quellen. Heute sind das 49 auditierte Jurisdiktionen samt EU-Verordnungen, Sicherheitsrahmenwerken und sektoralen Regelwerken. Auf dieser Grundlage laufen die Arbeitsabläufe, die Nachweise erzeugen: Datenschutz-Folgenabschätzung, Gap-Analyse gegen ein gewähltes Regelwerk, Threat Model. Jede regulatorische Aussage im Ergebnis trägt ihre Fundstelle — bei Rechtsfragen den amtlichen Normtext, bei Threat Models das jeweils einschlägige Rahmenwerk. Was Ansvar AI nicht leistet: keinen Kontrollbestand, keine Fristenverwaltung, keine Status-Ampeln, keine Betroffenenanfragen-Verwaltung. Und kein Zitat ersetzt den Nachweis der Umsetzung: Ansvar AI belegt, was gilt; dass Sie es umgesetzt haben, belegen Ihre eigenen organisatorischen Unterlagen und deren fachliche Prüfung. Wer die Verwaltungsfunktionen braucht, behält sein GRC-Werkzeug. Die belegte Bewertung entsteht daneben und fließt als Dokument ein. Betrieb und Datenhaltung liegen in der EU. Ein serverseitiges Sprachmodell betreiben wir nicht: Modellanfragen laufen direkt von Ihrem KI-Client zu Ihrem Modellanbieter, Ansvar sieht diesen Verkehr nicht und leitet ihn nicht weiter. Mit Kundendaten trainieren wir keine Modelle. Der Betriebsaufbau steht auf der AI-Governance-Seite ; die Pflichtenseite der DSGVO behandelt die Seite DSGVO-Compliance . Selbst prüfen Die Zitatqualität in fünf Minuten testen Zitate lassen sich nachschlagen. Verbinden Sie Ihren KI-Client mit dem Gateway und stellen Sie diese drei Fragen. Die Anweisung beginnt jeweils mit „Using Ansvar“. Ohne diesen Hinweis beantwortet Ihr Client die Frage aus dem Modellgedächtnis, statt die Anbindung zu nutzen. Geprüft haben Sie dann das Modell und nicht die Quelle. Using Ansvar: Welche Transparenzpflichten stellt die KI-VO an Hochrisiko-KI-Systeme? Nenne Artikel und Absatz. Using Ansvar: Ab wann ist eine Datenschutz-Folgenabschätzung verpflichtend? Zitiere die Fundstelle wörtlich. Using Ansvar: Unser KI-gestütztes Bewerbungsverfahren verarbeitet Lebensläufe. Welche Pflichten treffen uns nach DSGVO und KI-VO gleichzeitig? Schlagen Sie zwei der genannten Fundstellen in EUR-Lex nach. Stimmen Wortlaut und Nummerierung, haben Sie den Beleg. Stimmen sie nicht, haben Sie eine Modellantwort vor sich. Dieselbe Stichprobe trennt jeden Anbieter in diesem Vergleich. Häufige Fragen Fragen zur Auswahl einer DSGVO- und KI-VO-Lösung Wenn Ihre Frage nicht dabei ist — schreiben Sie uns. Wir beantworten jede E-Mail. Worin unterscheiden sich GRC-Plattformen und quellenbasierte Nachweislösungen? Eine GRC-Plattform führt Ihre Kontrollen, Richtlinien und Fristen und zeigt deren Status. Der Gesetzestext selbst liegt außerhalb: welche Norm eine Kontrolle trägt, trägt Ihr Team ein und hält es nach. Eine quellenbasierte Nachweislösung arbeitet umgekehrt: sie hält die Rechtsquellen vor und belegt jede Aussage mit ihrer Fundstelle, führt aber keinen Kontrollbestand. Die beiden Modelle konkurrieren selten; sie decken unterschiedliche Hälften derselben Akte ab. Was macht einen Compliance-Report auditfähig? Drei Eigenschaften: jede regulatorische Aussage nennt ihre Fundstelle bis auf Artikel- oder Absatzebene, die Fundstelle verweist auf die maßgebliche Quelle und ist dort nachprüfbar, und offene Punkte sind als offen ausgewiesen. Eine Prüferin muss eine Stichprobe ziehen und mit dem Normtext abgleichen können. Wichtig ist die Grenze: ein Zitat belegt, was die Norm verlangt, nicht dass Sie sie umgesetzt haben. Die Rechenschaftspflicht nach Art. 5 Abs. 2 und Art. 24 DSGVO verlangt zusätzlich organisatorische Nachweise aus Ihrem Betrieb und deren fachliche Prüfung. Deckt ein Datenschutzwerkzeug automatisch auch die KI-VO ab? In der Regel nicht. Datenschutzmanagement-Werkzeuge sind auf das Datenmodell der DSGVO gebaut: Verarbeitungstätigkeiten, Rechtsgrundlagen, Betroffenenrechte, Löschfristen. Die KI-Verordnung verlangt andere Objekte: Systemklassifizierung, Rollen entlang der Wertschöpfungskette, technische Dokumentation, Grundrechte-Folgenabschätzung. Wo ein KI-System personenbezogene Daten verarbeitet, gelten beide Regelwerke parallel, und die Nachweise müssen beide bedienen. Welche Fragen sollte man einem Anbieter vor der Auswahl stellen? Sechs, die sich in einer Demo beantworten lassen: Nennt jede regulatorische Aussage ihre Fundstelle? Führt der Anbieter die Rechtsquellen selbst nach, und weist er den Stand je Quelle aus? Sind DSGVO und KI-Verordnung im selben Vorgang abgedeckt? Wo werden Daten verarbeitet und gespeichert? Fließen Ihre Inhalte in Modelltraining? Läuft die Lösung in den Werkzeugen, die Ihr Team ohnehin nutzt, oder kommt ein weiteres Portal hinzu? Ersetzt Ansvar AI eine bestehende GRC-Plattform? Nein. Ansvar AI führt keinen Kontrollbestand, keine Fristenverwaltung und keine Status-Dashboards. Es liefert die belegte Bewertung — DSFA, Gap-Analyse, Threat Model — mit fundstellengenauen Zitaten aus der jeweils maßgeblichen Quelle: bei Rechtsfragen der amtliche Normtext, bei Threat Models die einschlägigen Rahmenwerke. Wer eine GRC-Plattform betreibt, behält sie und bezieht die Nachweise aus Ansvar AI; wer keine hat, deckt mit Ansvar AI die Nachweisseite ab. Warum ist der Datenstandort bei KI-gestützter Compliance-Software relevant? Weil die Unterlagen, die Sie prüfen lassen, selbst personenbezogene Daten enthalten können: Verarbeitungsverzeichnisse, Vorfallsberichte, Personalprozesse. Werden dabei personenbezogene Daten an einen Empfänger in einem Drittland offengelegt, greifen die Anforderungen des Kapitels V DSGVO. Der Standort von Anwendung oder Modell entscheidet das allein nicht — maßgeblich ist, welche Daten an wen gelangen. Ansvar AI wird in der EU betrieben und führt kein serverseitiges Modell: Modellanfragen laufen direkt von Ihrem KI-Client zu Ihrem Modellanbieter, Ansvar sieht diesen Verkehr nicht. Den Vergleich anhand Ihres eigenen Falls durchführen Buchen Sie eine Demo an einem Ihrer Szenarien — eine DSFA, eine KI-VO-Bewertung, eine Gap-Analyse. Wir gehen die Herkunft der Quellen durch, ziehen gemeinsam eine Zitat-Stichprobe und sprechen darüber, was gegenüber einer Aufsichtsbehörde trägt. Demo buchen DSGVO-Pflichten im Überblick Produkt und Preisseite sind derzeit auf Englisch. --- ## AVG-naleving · Ansvar AI URL: https://ansvar.eu/nl/avg-naleving Citaten op artikelniveau voor Nederlandse compliance-teams. AVG, EU AI-verordening en ISO 42001 — uit openbare regulatoire bronnen, gehost in de EU. AVG-naleving AVG-naleving met citeerbare bronnen — voor Nederlandse compliance-teams. AVG (GDPR), EU AI-verordening en ISO 42001 in dezelfde workflow die uw team al gebruikt. Ansvar AI levert antwoorden met citaten op artikelniveau uit openbare regulatoire bronnen — zodat besluiten onderbouwd worden, niet gegokt. Uitgangspunt Drie wettelijke kaders, één workflow AVG, EU AI-verordening en sectorregelgeving werken in elkaar door — niet parallel. AVG-naleving betekent tegenwoordig dat ze als één samenhangende inspanning behandeld worden, niet als drie aparte projecten. Voor Nederlandse organisaties is de vraag zelden óf persoonsgegevens verwerkt worden — wél hoe aantoonbaar regelconform. AVG, AI-verordening, NIS2 en sectorale eisen raken vaak dezelfde toepassing. Een AI-gestuurde recruitmenttool is tegelijk een hoogrisicosysteem onder de AI-verordening, DPIA-plichtig onder Art. 35 AVG en arbeidsrechtelijk relevant. De gemene deler is documentatie: een beoordeling die een onderzoek door de Autoriteit Persoonsgegevens doorstaat en herleidbaar is naar de daadwerkelijke wettekst — niet naar samenvattingen. Juist daar ontstaan de meeste gaten tussen norm en praktijk. AVG-verplichtingen De kernverplichtingen — geordend per artikel AVG-naleving is terug te brengen tot een beperkt aantal kernverplichtingen. Wat daaronder hangt — maatregelen, registers, beoordelingen — vloeit voort uit de specifieke toepassing. Rechtsgrond en doelbinding (Art. 5, 6) Iedere verwerking heeft een rechtsgrond uit Art. 6 nodig (toestemming, overeenkomst, wettelijke verplichting, vitaal belang, algemeen belang of gerechtvaardigd belang). Doelen moeten welbepaald, uitdrukkelijk omschreven en gerechtvaardigd zijn — achteraf verbreden van het doel zonder nieuwe rechtsgrond is niet toegestaan. Informatieplichten (Art. 13, 14) Betrokkenen worden geïnformeerd op het moment van verzamelen (Art. 13) of uiterlijk binnen een maand (Art. 14) over identiteit van de verwerkingsverantwoordelijke, doelen, rechtsgrond, ontvangers, bewaartermijn en rechten. Een privacyverklaring vervult deze plicht alleen wanneer ze concreet en transparant is. Verwerkingsregister (Art. 30) Verwerkingsverantwoordelijken en verwerkers houden registers van verwerkingsactiviteiten bij in schriftelijke of elektronische vorm. De verplichte inhoud staat in het artikel zelf — van verwerkingsdoelen en categorieën ontvangers tot beoogde bewaartermijnen en doorgiften naar derde landen. Passende beveiliging (Art. 32) Verwerkingsverantwoordelijken en verwerkers nemen passende technische en organisatorische maatregelen — rekening houdend met de stand van de techniek, uitvoeringskosten, aard en doel van de verwerking en de risico's voor betrokkenen. Pseudonimisering, versleuteling, beschikbaarheid en weerbaarheid van systemen en regelmatige toetsing van de effectiviteit worden expliciet genoemd. Meldplicht bij datalekken (Art. 33, 34) Inbreuken in verband met persoonsgegevens worden binnen 72 uur gemeld aan de bevoegde toezichthouder (Art. 33), bij hoog risico aanvullend aan de betrokkenen (Art. 34). De 72-uurstermijn begint op het moment dat de verwerkingsverantwoordelijke kennis krijgt van het lek — niet op het moment van ontdekking van het onderliggende beveiligingsprobleem. Contracten en beoordelingen Verwerkersovereenkomst en DPIA — twee aparte verplichtingen De verwerkersovereenkomst en de DPIA zijn verschillende instrumenten met verschillende aanleidingen. Ze vervangen elkaar niet. De verwerkersovereenkomst (Art. 28) regelt de relatie tussen verwerkingsverantwoordelijke en verwerker — bijvoorbeeld tussen een organisatie en haar cloud-leverancier. Verplichte onderdelen zijn onder meer onderwerp en duur van de verwerking, instructiegebondenheid, geheimhoudingsplicht, beveiligingsmaatregelen, subverwerkers, ondersteuning bij betrokkenenrechten en meldplichten, en audit-rechten. Zonder verwerkersovereenkomst is de inschakeling van een verwerker zelf onrechtmatig. De DPIA (Art. 35) betreft het eigen verwerkingsproces van de verwerkingsverantwoordelijke wanneer dat waarschijnlijk een hoog risico voor betrokkenen oplevert. Het is een risicobeoordeling — geen toestemming. Blijkt na de DPIA een hoog restrisico, dan moet de toezichthouder vóór aanvang worden geraadpleegd (Art. 36). Voor AI-gestuurde verwerkingen komt daar een Grondrechten-effectbeoordeling (FRIA, Art. 27 AI-verordening) bij — met name bij bepaalde hoogrisicosystemen in de publieke sector of bij aanbieders van publieke diensten. De twee beoordelingen hebben verschillende zwaartepunten en worden apart gedocumenteerd. Zo helpt Ansvar AI Antwoorden met citaten in uw bestaande AI-client U hoeft geen nieuw product te leren. Ansvar AI verbindt Claude, Cursor, Copilot Studio en andere MCP-compatibele clients met openbare regulatoire bronnen. Elk antwoord wordt geleverd met citaten op artikelniveau. Wanneer een functionaris voor gegevensbescherming vraagt "Welke verplichtingen heb ik bij een datalek op grond van Art. 33?", verwijst het antwoord direct naar de artikeltekst — niet naar een schatting van het model. De bronnen zijn openbaar en controleerbaar. Het platform draait binnen de EU (Hetzner). Modelverkeer loopt rechtstreeks van uw AI-client naar uw modelleverancier — Ansvar ziet dat verkeer niet en stuurt het niet door; wij draaien geen eigen AI-model aan de serverkant. Wij trainen geen modellen op klantgegevens. De volledige operationele opzet staat op de AI Governance -pagina. Op dit moment dekt Ansvar AI 49 geaudite jurisdicties, EU-verordeningen, beveiligingskaders en sectorale regelgeving af. De dekking wordt alleen uitgebreid wanneer bronlicentiëring, actualiseringscyclus en citaatkwaliteit gevalideerd zijn. Veelgestelde vragen Vragen die we krijgen van Nederlandse compliance-, juridische en beveiligingsteams Staat uw vraag er niet bij — stuur ons een mail. We beantwoorden elk bericht. Wat is AVG-naleving? AVG-naleving is de aantoonbare toestand waarin een organisatie voldoet aan de Algemene Verordening Gegevensbescherming — van rechtsgrond en betrokkenenrechten tot technische en organisatorische maatregelen en meldplichten. Naleving is geen certificaat, maar gedocumenteerde praktijk die een toezichtsonderzoek doorstaat. Welke verplichtingen gelden voor mijn organisatie? Dat hangt af van uw rol (verwerkingsverantwoordelijke of verwerker) en van de verwerkingsactiviteit. Kernverplichtingen zijn: rechtsgrond per verwerking (Art. 6), informatieplichten (Art. 13/14), register van verwerkingsactiviteiten (Art. 30), passende technische en organisatorische maatregelen (Art. 32), meldplicht bij datalekken (Art. 33/34) en waar nodig een DPIA (Art. 35). Wanneer is een DPIA verplicht? Artikel 35 AVG vereist een DPIA wanneer een verwerking waarschijnlijk een hoog risico oplevert voor de rechten en vrijheden van betrokkenen — typisch bij systematische en uitgebreide profilering, grootschalige verwerking van bijzondere categorieën, of stelselmatige monitoring van openbare ruimten. De AP publiceert lijsten met verwerkingen waarvoor zij een DPIA in elk geval verplicht acht. Wat moet een verwerkersovereenkomst bevatten? Een verwerkersovereenkomst (Art. 28) moet onderwerp en duur van de verwerking, aard en doel, categorieën betrokkenen en gegevenscategorieën benoemen. Daarnaast gelden de acht verplichtingen van de verwerker uit Art. 28 lid 3 — instructiegebondenheid, geheimhouding, passende beveiliging, subverwerkers, ondersteuning bij betrokkenenrechten en meldplichten, audits en de teruggave of verwijdering van de gegevens na afloop. Hoe verhoudt de AI-verordening zich tot de AVG? De EU AI-verordening vult de AVG aan, vervangt deze niet. Wanneer een AI-systeem persoonsgegevens verwerkt, gelden beide verordeningen parallel. Een DPIA op grond van Art. 35 AVG kan vereist zijn, en daarnaast een Grondrechten-effectbeoordeling (FRIA) op grond van Art. 27 AI-verordening voor bepaalde hoogrisicosystemen — met name wanneer overheidsorganen of aanbieders van publieke diensten ze inzetten. Welke toezichthouder is verantwoordelijk in Nederland? De Autoriteit Persoonsgegevens (AP) is de primaire toezichthouder voor de AVG in Nederland. Voor de AI-verordening is op het moment van schrijven nog geen definitieve nationale coördinator aangewezen; de verwachting is dat de AP een centrale rol krijgt voor grondrechten en gegevensbescherming, terwijl het markttoezicht afhankelijk van het toepassingsgebied van het AI-systeem over sectortoezichthouders verdeeld kan worden. Hoe verschilt Ansvar AI van een gewone AI-chatbot? Ansvar AI is een gateway die uw bestaande AI-clients (Claude, Cursor, Copilot Studio en andere MCP-compatibele clients) via het Model Context Protocol verbindt met openbare regulatoire bronnen. Elk antwoord wordt geleverd met citaten op artikelniveau die controleerbaar zijn. Het model formuleert de tekst — de bronnen komen echter uit geaudite, open verbindingen, niet uit de trainingsdata van het model. Wilt u zien hoe het in de praktijk werkt? Boek een demo waarin we Ansvar AI toepassen op een van uw eigen scenario's — een DPIA, een AI-verordeningsbeoordeling, een gap-analyse. We lopen de citaatpipeline, de herkomst van de bronnen en de verdedigbaarheid van de antwoorden tegenover de Autoriteit Persoonsgegevens door. Demo boeken Prijzen bekijken Het product en de prijspagina zijn voorlopig in het Engels. --- ## Setup · Ansvar AI URL: https://ansvar.eu/setup Connect Ansvar AI to Claude, VS Code, Cursor, and Copilot Studio — OAuth 2.1 with Dynamic Client Registration. Paste a URL and sign in. Setup Connect Ansvar AI to your AI client Pick your client. One click where the client supports it — Claude, VS Code, Cursor — otherwise paste a URL. Sign in once. Your client now sees the gateway as a tool. Gateway essentials Three things every client needs Server URL https://gateway.ansvar.eu/mcp Auth OAuth 2.1 with Dynamic Client Registration (PKCE). The client opens a browser once, you sign in, the client stores the token and refreshes silently after that. Tier visibility tools/list is filtered by tier. Free covers single-source search (100 searches/day) and 1 STRIDE threat-model run a month on a described system; Solo adds multi-source fan-out and a second run; Premium adds case law, preparatory works, and agency guidance, the LINDDUN and TARA families, and a 5-run allowance; Team adds document-grounded workflow plus upload tools; Company adds the audit ledger. See pricing . Designed for MCP-native AI clients (Claude, ChatGPT, Cursor, VS Code Copilot, Gemini), Copilot Studio agents, and custom MCP clients your team builds. MCP (Model Context Protocol) is the open standard that lets AI assistants call external tools. Tier-1 walkthroughs Step-by-step for the five most-used clients Claude (web + Desktop) via Connectors ▸ Prerequisites. Any Claude plan — Free, Pro, Max, Team, or Enterprise (Claude Free allows one custom connector; on Team/Enterprise an owner enables the connector first) — on claude.ai, Cowork, or Claude Desktop. Any Ansvar account works — Free is enough to evaluate (single-source answers, 100 searches/day); Solo unlocks multi-source fan-out; Premium adds case law, preparatory works, and agency guidance. Add Ansvar from the Claude connector directory ↗ Ansvar is a listed Claude connector: open the listing, press Connect, sign in. The manual steps below do the same thing by hand. Customize → Connectors → Add custom connector Name: Ansvar URL: https://gateway.ansvar.eu/mcp OAuth. After saving, Claude opens a browser for OAuth sign-in at auth.ansvar.eu. Approve the consent screen. The connector flips to Connected; tokens refresh silently after that. Verify. Ask Claude: "Do you see Ansvar tools available?" Expected: Claude lists ansvar.search and the other tools your tier includes. Stuck? See troubleshooting . Claude Code ▸ Prerequisites. Claude Code CLI installed (`npm i -g @anthropic-ai/claude-code`), an Ansvar account (any tier) Run in your project root claude mcp add --transport http ansvar https://gateway.ansvar.eu/mcp OAuth. The --transport http flag is required — without it the CLI defaults to stdio. After adding the server, start Claude (claude), type /mcp, select "ansvar" (the name from the add command), choose Authenticate. A browser opens for OAuth at auth.ansvar.eu; approve and return to the terminal. The token is stored in ~/.claude.json. Verify. In the /mcp menu, the ansvar server status should read "connected" with Auth: authenticated. Expected: Tools become available in the next message — try: "List the Ansvar tools you can call." Stuck? See troubleshooting . VS Code (GitHub Copilot agents mode) ▸ Prerequisites. VS Code 1.92+, GitHub Copilot agents mode enabled, an Ansvar account (any tier) Install in VS Code Opens VS Code with the server entry pre-filled — confirm, then sign in. If nothing opens, paste the config below instead. Create or edit .vscode/mcp.json { "servers": { "ansvar": { "url": "https://gateway.ansvar.eu/mcp" } } } OAuth. Trigger a Copilot agent action that touches an MCP server. VS Code opens the OAuth flow on first use. Verify. In Copilot Chat (agents mode): "What MCP tools do I have?" Expected: Copilot enumerates the Ansvar tool catalogue. Stuck? See troubleshooting . Cursor ▸ Prerequisites. Cursor 0.42+, an Ansvar account (any tier) Install in Cursor Opens Cursor with the server pre-filled — confirm, then sign in. If nothing opens, use the manual steps below. Settings → MCP → Add Server Name: ansvar URL: https://gateway.ansvar.eu/mcp OAuth. Cursor opens the OAuth flow when you save the server entry. Verify. In Composer or Chat: "List tools registered under ansvar." Expected: Cursor shows the tool list inline. Stuck? See troubleshooting . Gemini CLI ▸ Prerequisites. gemini-cli v0.44.0+ (earlier versions lose authentication when the short-lived token rotates mid-session), a Gemini Code Assist Standard/Enterprise license or paid Gemini API key (Google retired the free individual CLI tiers 2026-06-18), an Ansvar account (any tier) Run in your project root (add --scope user to register globally) gemini mcp add --transport http ansvar https://gateway.ansvar.eu/mcp OAuth. Start gemini and run /mcp auth ansvar. A browser opens for OAuth at auth.ansvar.eu — no client ID or key to configure; Gemini CLI discovers the gateway's OAuth endpoints and registers itself. Approve and return to the terminal. If tool calls fail with an auth error later in a long session, run /mcp auth ansvar again. Verify. Run /mcp list. Expected: The ansvar server reads connected and lists the tools your tier includes. Stuck? See troubleshooting . Tier-2 quick configs Other MCP-capable clients ChatGPT (custom connector, Developer mode) Prereq. Any paid ChatGPT plan (Plus / Pro / Business / Enterprise / Edu) with Developer mode enabled — Settings → Apps → Advanced settings. Full guide: ansvar.eu/docs/setup/chatgpt Where. Settings → Connectors → Create MCP server URL: https://gateway.ansvar.eu/mcp Authentication: OAuth (no client ID needed) Auth. ChatGPT registers itself and opens the OAuth login in the browser. Verify. Ask: "Which Ansvar tools are available?" Continue Prereq. Continue extension installed in your IDE Where. config.json → mcpServers { "ansvar": { "url": "https://gateway.ansvar.eu/mcp" } } Auth. Browser-based OAuth on first use. Verify. Ask the agent to list its MCP tools. Open WebUI Prereq. Self-hosted Open WebUI 0.5+ with MCP support enabled Where. Admin → Tools → Add MCP server https://gateway.ansvar.eu/mcp Auth. OAuth via browser; token stored per user. Verify. Trigger a workflow and inspect the tool-call panel. Custom MCP client (stdio / HTTP) Prereq. Any client implementing the MCP spec Where. Wherever your client registers MCP servers Endpoint: https://gateway.ansvar.eu/mcp Transport: streamable-http Auth: OAuth 2.1 + Dynamic Client Registration (PKCE) Auth. Discovery via /.well-known/oauth-authorization-server. Verify. Call tools/list and confirm the catalogue is non-empty. Microsoft Copilot Studio Publish an Ansvar-backed agent to your tenant Build a Copilot Studio agent that calls Ansvar through the gateway, then publish to Teams, web, or M365 Chat. Same citation contract, M365 native UX. The walkthrough has its own page because it has more steps than every other client combined. Open the Copilot Studio guide → Google Gemini Gemini is several products — find yours Gemini CLI connects with the one command above. Gemini Code Assist, Google Antigravity, Gemini Enterprise, and the Gemini app each work differently — and agents built on the Gemini API need the headless path. The guide covers all of them. Open the Gemini guide → My client isn't here Tell us which one The clients below are reachable via the gateway in principle but not yet documented end-to-end. Email us and we will add the walkthrough. Microsoft Copilot for M365 — Different surface from Copilot Studio — not yet documented Zed — MCP support landing — walkthrough not yet captured Request a walkthrough Trouble? Triage the three most common problems The OAuth window did not open Your client may be blocking popups, or the OAuth redirect URI may be unreachable from your network. Check your firewall allows outbound HTTPS to auth.ansvar.eu . Tools do not appear in my client Restart the client after editing config. Most MCP clients only re-read config on launch. If tools are still missing, check the client's MCP-server status panel for an error. 401 unauthorized Your token expired or the OAuth flow did not complete. Sign out of the client and reconnect; the token will be refreshed. Now that you are connected Ask your first cross-jurisdiction question — every answer comes back with sources. See tiers → --- ## Vibe Coding Security — Threat Modeling & Compliance for AI-Built Apps · Ansvar AI URL: https://ansvar.eu/vibe-coding-security Built your app with AI? Turn “is it secure?” into a cited threat-model report, run from the same agent that wrote the code. CVE screening on the free plan. Vibe coding security Security and compliance for AI-built apps You shipped it in a weekend. Now a customer wants to know if it’s “secure” and “GDPR compliant”, and the honest answer is a shrug. Connect Ansvar to the agent that built your app and turn the shrug into a cited report. Connect your agent See a sample report You Threat-model my app. Next.js + Postgres on Vercel, Stripe billing, EU users. Agent STRIDE threat model — server-enforced workflow Stripe webhook endpoint accepts unsigned events High Verify webhook signatures; reject unsigned payloads. GDPR Art. 32 — Security of processing · eur-lex.europa.eu 14 findings · 1 marked unresolved — no served legal basis found · report.pdf The gap Shipping fast is the easy half A weekend of prompting gets you a working app. It does not get you a reviewed one. Your app works. It also stores personal data, talks to Stripe, and serves people in the EU — three things the law has opinions about. Nobody threat-modeled any of it, because you were busy shipping and the model never brought it up. Then a customer’s procurement team sends the security questionnaire, and “the AI said it’s fine” is not something you can paste into the answer box. How it works Three steps, no new tools to learn The same agent that wrote your code runs the review. Connect Add one MCP server to Claude, Cursor, ChatGPT, Copilot, or Gemini — whichever agent you already argue with. OAuth sign-in, a few minutes. Setup guide . Describe Tell your agent what the app is, in plain words: “Next.js, Postgres, Stripe, EU users.” No forms, no uploads — your code stays with you. The review works from a description. Get the report A server-enforced workflow walks your agent through a STRIDE threat model — and, when you handle personal data, a separate privacy threat model — then produces a report (PDF, if you like) you can send to the customer instead of a nervous emoji. The report From a description to fourteen findings Same fictional app as the prompt up top: first the map, then the findings from walking it — the part your customer actually reads. You Next.js + Postgres on Vercel, Stripe billing, EU users. becomes The system map: your users (EU, browsers) and Stripe (external billing) sit on the internet side of trust boundary B1. Users reach the Next.js API on Vercel over HTTPS and Stripe calls it with webhooks — both crossing B1. The API queries Postgres, which holds personal data, across trust boundary B2. internet your app data B1 B2 Your users EU · browsers Stripe billing · external Next.js API Vercel Postgres personal data HTTPS webhooks queries The review starts where arrows cross the dashed lines. report.pdf — threat register ranked by severity Elevation of privilege Critical Any signed-in user can read any other account's data Scope every query to the session's user id — signed-in isn't authorized. GDPR Art. 5(1)(f) — Integrity & confidentiality Repudiation High No auth or admin logs — a breach would be invisible Log sign-ins, resets, and admin actions — you can't report a breach you can't see. GDPR Art. 32 — Security of processing Spoofing Medium Password-reset tokens never expire and survive a password change Single-use reset tokens with a short clock. OWASP ASVS v4.0.3 — Credential recovery Information disclosure Medium The reset form tells strangers which emails have an account Return the same response whether the address exists or not. marked unresolved — no served legal basis found Excerpt — 4 of 14 findings Browse a full sample Tomorrow's fix list Ranked by severity. Start at the top, close them like tickets. The questionnaire answer “Do you have a threat model?” Yes — attached. Proof, not promises Findings that touch the law carry the citation. Gaps get flagged, not filled in. False positives die at home Your agent has the code — or grant it GitHub access — and can check each finding against what's actually there. Ansvar never asks for it. Receipts It cites the actual law — or it tells you it can't Compliance folklore is free everywhere. Sources are the product. Ask a bare model about GDPR and you get an answer assembled from vibes: confident, sometimes right, never checkable. The gateway is wired the other way around. It looks up the law, quotes it, and links the official text — and when it can’t find something, it says so instead of improvising. Your report ends with citations, not folklore. (The analysis is still your agent’s work — the gateway’s guarantee is the sourcing.) GDPR Art. 32 · eur-lex NIS2 Art. 21 · eur-lex AI Act Art. 15 · eur-lex Your dependencies get the same treatment: checked against live CVE data and CISA’s known-exploited list, on the free plan. It screens the packages you name — it is not a code scanner, and it won’t pretend to be one. Shortcut: install the Regulatory Threat Model skill — one file that teaches your agent this whole flow. More on the agent skills page. FAQ Questions builders ask before connecting If yours is not here, ask us — every message gets a human answer. Is my AI-built app GDPR compliant? No tool can stamp you compliant, and anyone who says otherwise is selling stickers. What you can do is find out which rules actually touch your app, then produce the assessments they expect — security measures, and a data protection impact assessment when what you do with people's data is likely to be high-risk — with citations to the real text. What does a threat model give me? A structured list of what can go wrong in your app, component by component, ranked, with fixes — and citations to the legal requirements involved, where there are any. It's usually the first thing a security-minded customer asks for. Now you'll have one. Do I need a DPIA? Only when your processing is likely to be high-risk for the people in your data — think profiling that affects real outcomes, lots of sensitive data, or monitoring public spaces at scale. If that sounds uncomfortably familiar, the DPIA workflow (Team plan) walks the assessment and produces the report. Orientation, not legal advice. Which tools does this work with? Claude, Cursor, ChatGPT, Microsoft Copilot, Gemini — anything that speaks MCP. Is there a free plan? Yes, with a business sign-up: regulatory search, law lookups, citation checks, the CVE lane, and one workflow run a month on a system you describe — threat model, gap analysis (incl. NIS2, DORA, CRA, EU AI Act) or DPIA — with the report as a watermarked render or JSON. Solo doubles that to two runs; Premium raises it to five across the full interview-grounded catalog and adds case law inside the run — prices live on the pricing page. Can it scan my code? No — on purpose. It threat-models the system you describe and screens the dependencies you name; it never asks for your code. Your agent is a different story: it already has the repo (or you can grant it GitHub access), so it can check each finding against the actual code and call out the false positives — that check stays on your side. Keep your code scanner — this adds the design review and the law on top. Let your agent clean up after itself Connect the gateway and get the review done before the next customer asks. Connect your agent See plans Free covers the vulnerability screen, law lookups, and one STRIDE threat model a month (business sign-up). Threat modeling is metered monthly on every plan — 1 run on Free, 2 on Solo, 5 on Premium, which adds the LINDDUN privacy run; STRIDE and privacy runs counted separately; see Pricing . Research support for professional review, not legal advice. --- ## NIS2 gap analysis with the policy attached — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/gap-analysis-with-policy A real NIS2 Article 21 gap analysis with the policy uploaded — verdicts pinned to hash-anchored paragraphs and ISO 27001 clauses licensed from SIS. Use cases Security NIS2 gap analysis with the policy attached — ISO 27001 via SIS in the loop Your CISO uploads the company's information-security policy and asks for a NIS2 Article 21 gap analysis. The server-enforced workflow pairs every Art. 21(2) measure against the actual policy paragraphs (hash-anchored), maps each to licensed ISO/IEC 27001 clauses fetched from SIS during the run, and marks what it could not verify instead of guessing. Citations 8 Tool calls 18 Captured with claude-fable-5 How the gateway answered Captured 11 July 2026 — a point-in-time run; corpora and tools have been updated since. Editor's note. Baltika Freight Systems OÜ is fictional; its policy was authored as the subject fixture for this capture (downloadable above) with deliberate control gaps. The gateway calls, the workflow's quality gates, every regulatory and SIS-licensed standards row, the doc:// paragraph hashes, and the rendered report are the real session output. Two run artifacts kept honest rather than edited out: the Estonian corpus was unavailable for 8 of 10 sector passes (findings say so instead of assuming the transposition), and the first control submission was rejected by the server's evidence-envelope gate before being accepted in the correct shape. ISO 27001 clause text was served into the session but appears here as identifiers only — the SIS licence scopes reproduced text to customers via the gateway, not public pages. Captured session claude-fable-5 · company tier · gateway.ansvar.eu You Run a NIS2 gap analysis for Baltika Freight Systems OÜ (fictional, 90-person Estonian logistics SaaS, important entity) against the attached Information Security Policy POL-BLTK-2026-02 v2.1. Assess every Article 21(2) measure, map to ISO/IEC 27001, jurisdictions EU + EE. Ansvar gateway — 18 tool calls register_document_init ( filename="baltika-information-security-policy.md" mime_type="text/markdown" file_size=4330 ) → presigned PUT issued; document_id fe2dc6df…, short code DOC-6DCN register_document_finalize ( document_id="fe2dc6df-3a15-4d8e-bc98-df8f95f128a7" ) → status=ready; source SHA-256 9d2b8e4a752c0841… matches the local file byte-for-byte get_document_segments ( document_id="fe2dc6df-3a15-4d8e-bc98-df8f95f128a7" ) → 27 paragraph segments, each with char range + content SHA-256 — the doc:// anchors cited in the findings start_workflow ( workflow_type="gap_analysis_nis2" jurisdictions=[EU, EE] ) → workflow 63f045b3… started; server-enforced scoping gates (entity classification: important entity; jurisdictions; scope review) each required explicit confirmation before controls loaded register_document ( workflow_id="63f045b3…" document_id="fe2dc6df…" role="evidence" ) → policy bound as evidence at document_collection.request_policies submit_response ( step_id="control_assessment.Art.21.2.a" compliance_level="partial" ) → accepted — each control step declares 6 fetches (provision, own-article, horizontal, sector, case-law, guidance) the quality gate verifies per key; + SIS 27001 clause fetch. First submit was REJECTED (fetched_data_envelope_invalid) until every key carried {status, results[]} — the gate is real Show all 18 tool calls submit_response ( step_id="control_assessment.Art.21.2.b" compliance_level="largely_compliant" ) → accepted — internal handling solid; no authority chain, no exercises (caveat kept in report) submit_response ( step_id="control_assessment.Art.21.2.c" compliance_level="partial" ) → accepted — backups real; no crisis organisation, no RTO/RPO; ISO A.5.30 tested-readiness unmet submit_response ( step_id="control_assessment.Art.21.2.d" compliance_level="not_implemented" ) → accepted — supply chain absent entirely; A.5.19/A.5.22/A.5.23 unaddressed; keys delegated to provider with no contract terms submit_response ( step_id="control_assessment.Art.21.2.e" compliance_level="partial" ) → accepted — patching + CI scanning real; no vulnerability-disclosure channel (the measure names disclosure explicitly) submit_response ( step_id="control_assessment.Art.21.2.f" compliance_level="partial" ) → accepted — annual policy re-approval ≠ assessing measure effectiveness; no metrics or audit (9.1/9.3.2) submit_response ( step_id="control_assessment.Art.21.2.g" compliance_level="largely_compliant" ) → accepted — training + hygiene solid; management-body training missing (NIS2 Art. 20(2)) submit_response ( step_id="control_assessment.Art.21.2.h" compliance_level="partial" ) → accepted — 'where technically feasible' at-rest clause unverifiable; no key-management rules (A.8.24) submit_response ( step_id="control_assessment.Art.21.2.i" compliance_level="partial" ) → accepted — access control + HR genuinely covered; asset management absent (A.5.9) submit_response ( step_id="control_assessment.Art.21.2.j" compliance_level="not_implemented" ) → accepted — MFA appears nowhere in the policy; password-only production access submit_response ( step_id="findings_review.assessment_review" ) → register approved by the capture author; fictional-sample status and pending senior review recorded verbatim in the audit trail submit_response ( step_id="red_team.adversarial_review" ) → all 5 probes run — material finding: Art. 23 reporting had no register row; the 72h customer-only notification would breach the 24h/72h/1-month authority chain. Recorded as out-of-register finding generate_report ( workflow_id="63f045b3…" format="all" ) → report assembled server-side from stored step data (10 findings, remediation roadmap, evidence register, citation provenance); PDF/HTML/DOCX rendered, SHA-256 verified on download Cited answer NIS2 gap analysis — Baltika Freight Systems OÜ (fictional), policy attached Run: gap_analysis_nis2 server-enforced workflow · Scope: NIS2 Art. 21(2)(a)–(j), jurisdictions EU + EE · Subject: Information Security Policy POL-BLTK-2026-02 v2.1, uploaded and paragraph-segmented (source SHA-256 9d2b8e4a…a84f12 ) · Standards dimension: SS-EN ISO/IEC 27001:2023, licensed clause rows fetched from SIS during the run · Client is fictional; every regulatory and standards row is real, fetched this session. The attached policy is the organisation's only security governance document. The workflow classified Baltika as an important entity (transport-logistics SaaS, 90 people, Estonia), bound the policy as evidence, then assessed each Article 21(2) measure through five enrichment passes — primary provision, horizontal regimes, sector routing, case law, authority guidance — plus an ISO/IEC 27001 control mapping from the SIS-licensed corpus. Verdict register Art. 21(2) Measure Policy anchor Verdict (a) Risk analysis & infosec policies §2 [1], §3 [2] Partial — policy approved, but no risk methodology or acceptance criteria (ISO 27001 6.1.2); annual-only cadence (8.2) (b) Incident handling §6 [5] Largely compliant — report → classify (4 h) → respond → post-incident review; caveat: no authority chain, … Download PDF Download Markdown Download JSON Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 8 sources — official legislation, guidance from standards bodies or regulators, and standards clause maps — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. NIS2 (Directive (EU) 2022/2555) Art. 21 — Cybersecurity risk-management measures (canonical ref NIS2:art_21; also Art. 20(2), Art. 23 via the same instrument) ↗ EU · regulation · eur-lex.europa.eu Commission Implementing Regulation (EU) 2024/2690, Annex I — technical and methodological requirements per Art. 21(2) measure ↗ EU · regulation · eur-lex.europa.eu SS-EN ISO/IEC 27001:2023 — 21 clause/control rows fetched from the SIS-licensed corpus (6.1.2, 6.2, 8.2, 9.1, 9.2.1, 9.3.2, 7.3, A.5.9, A.5.18, A.5.19, A.5.22, A.5.23, A.5.24, A.5.30, A.6.3, A.8.2, A.8.5, A.8.8, A.8.24, A.8.25, A.8.28); clause text served in-session, elided on this public page per the SIS licence ↗ SE · standard · sis.se ENISA — NIS2 Technical Implementation Guidance (incident handling, BC/CM, acquisition & development, hygiene, effectiveness, MFA sections) ↗ EU · guidance · enisa.europa.eu ENISA — Cybersecurity roles and skills for NIS2 essential and important entities ↗ EU · guidance · enisa.europa.eu NIS Cooperation Group — security measures guidance (supply-chain security policy; HR security & access control) ↗ EU · guidance · digital-strategy.ec.europa.eu European Commission (DG CONNECT) — Guidelines on the application of Article 4(1) and (2) of Directive (EU) 2022/2555 ↗ EU · guidance · digital-strategy.ec.europa.eu ENISA Threat Landscape 2025 — §10.5 Access & Privilege (MFA as counter to credential misuse) ↗ EU · guidance · enisa.europa.eu Run this on your own data This is available as a service: Compliance Gap Analysis . Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. Read the full sample deliverable: Sample NIS2 gap analysis . Contact us --- ## Gap analysis from a security policy — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/gap-analysis A real, cited gap analysis from a security policy through the Ansvar gateway — every finding traced to the underlying ISO 27001, NIS2, and GDPR provision. Use cases Security Gap analysis from your security policy Your CISO needs to know how today's information-security policy maps against ISO 27001, NIS2, and DORA — without buying three separate audits. Citations 10 Tool calls 3 Captured with claude-opus-4-7 How the gateway answered Captured 14 May 2026 — a point-in-time run; corpora and tools have been updated since. Captured session claude-opus-4-7 · team tier · gateway.ansvar.eu You What controls do ISO 27001:2022, NIS2 (Directive 2022/2555), and DORA (Regulation (EU) 2022/2554) each require from a regulated entity's information-security policy? Group by framework. Mark each requirement critical / material / minor with inline citations. (For a real gap analysis, attach your policy and the workflow will pair each control to your existing clause and flag the misses.) Ansvar gateway — 3 tool calls search ( query="information security management system requirements" frameworks=[ISO_27001] limit=10 ) → 1 weakly-relevant result; ISO 27001 specific clauses not surfaced for this query search ( query="essential entity cybersecurity risk management measur…" frameworks=[NIS2] limit=10 ) → 10 results from EU Regulations MCP — NIS2 Art. 1, 16, 20, 21, 32 + Recitals 74, 78, 82, 85, 137 search ( query="ICT risk management framework digital operational res…" frameworks=[DORA] limit=10 ) → 10 results from EU Regulations MCP — DORA Art. 1, 5, 6, 13, 16, 24, 28 + Recitals 8, 43, 45 Cited answer Gap-analysis baseline — ISO 27001 + NIS2 + DORA The gateway returned strong coverage on NIS2 and DORA (the two binding EU regimes) and thin coverage on ISO 27001 (the management-system standard). The control set below is the superset of requirements the three regimes impose on an in-scope entity. Pair each row against your existing policy clauses to produce a real gap analysis. NIS2 — Directive (EU) 2022/2555 The gateway returned the following on-point NIS2 articles (and recitals giving their motivation): Article 1 — Subject matter . Establishes the harmonised cybersecurity-risk-management and reporting baseline across the Union. Article 16 — Peer review framework . Member-State authorities review each other; the operator-side impact is that supervisory expectations converge over time. Article 20 — Governance . Management bodies of essential and important entities must approve the cybersecurity-risk-management measures and oversee their implementation, can be held liable for non-compliance, and must follow specific training. Critical. Article 21 — Cybersecurity risk-management measures . This is the load-bearing article. Mandates all-hazards approach with at least: risk-analysis + information-system security policies; incident handling; business continuity (backups, disaster recovery, crisis management); supply-chain security; security in acquisition / development / maintenance; vulnerability disclosure; assessment of effectiveness; … Download PDF Download Markdown Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 10 sources — official legislation — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. NIS2 Directive (EU) 2022/2555 Article 1 — Subject matter ↗ EU · regulation · eur-lex.europa.eu NIS2 Article 20 — Governance ↗ EU · regulation · eur-lex.europa.eu NIS2 Article 21 — Cybersecurity risk-management measures ↗ EU · regulation · eur-lex.europa.eu NIS2 Article 32 — Supervisory and enforcement measures ↗ EU · regulation · eur-lex.europa.eu DORA Regulation (EU) 2022/2554 Article 5 — Governance and organisation ↗ EU · regulation · eur-lex.europa.eu DORA Article 6 — ICT risk-management framework ↗ EU · regulation · eur-lex.europa.eu DORA Article 13 — Learning and evolving ↗ EU · regulation · eur-lex.europa.eu DORA Article 16 — Simplified framework ↗ EU · regulation · eur-lex.europa.eu DORA Article 24 — Testing of ICT tools and systems ↗ EU · regulation · eur-lex.europa.eu DORA Article 28 — Third-party-risk monitoring ↗ EU · regulation · eur-lex.europa.eu Run this on your own data This is available as a service: Compliance Gap Analysis . Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. Read the full sample deliverable: Sample NIS2 gap analysis . Contact us --- ## DPIA for a new HR vendor — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/dpia-hr-vendor A full GDPR Article 35 DPIA for an HR SaaS vendor through the Ansvar gateway — 23 steps, CNIL severity scoring, cited to the legislation. See the cited output. Use cases Privacy GDPR Article 35 DPIA — full workflow run with structured report Your HR team wants to roll out 'PeopleFlow', a US SaaS that processes payroll, performance reviews, absence data including medical certificates, and runs a 'flight-risk' profiling model for 1,200 employees across DE, NL, and SE. SCCs are in place; sub-processors include AWS us-east-1 and a separate analytics provider. The gateway's `dpia` workflow drives 23 GDPR Article 35 steps end-to-end — screening, processing description, DPO consultation, necessity + proportionality, data-subject views, 12 per-risk CNIL severity x likelihood scorings, transfer compliance, processor compliance, Article 36 determination — and returns a citation-bearing structured deliverable. Citations 12 Tool calls 21 Captured with claude-opus-4-7 How the gateway answered Captured 14 May 2026 — a point-in-time run; corpora and tools have been updated since. Captured session claude-opus-4-7 · team tier · gateway.ansvar.eu You From your MCP client: "Start a dpia workflow against my HR vendor onboarding (PeopleFlow / payroll + performance + medical certificates + flight-risk profiling, 1,200 employees across DE/NL/SE, US-based vendor with SCCs). Drive each step — screening, processing description, DPO consultation, necessity + proportionality, scope review, data-subject views, risk enumeration, per-risk CNIL scoring with safeguards, transfer + processor compliance, Article 36 determination. Then generate_report() and give me the JSON, MD, and PDF." Ansvar gateway — 21 tool calls list_workflow_types ( ) → 8 workflow types available: dpia, dpia_de, fria, gap_analysis, linddun, tender_review, tender_review_se, threat_model start_workflow ( workflow_type="dpia" framework="GDPR" jurisdictions=[DE, NL, SE] entity_description="HR SaaS vendor PeopleFlow processing payroll, perform…" ) → workflow_id=7a051f04; status=active; first_step=scoping.screening search ( query="data protection impact assessment Article 35 mandator…" frameworks=[GDPR] jurisdictions=[EU] limit=8 ) → 8 results from EU Regulations MCP — GDPR Art. 35, Art. 22, Recital 71, Recital 91, Art. 13, Art. 14, Art. 15, Art. 47 submit_response ( step_id="scoping.screening" fields=[screening.outcome, screening.rationale, screening.criteria_triggered] ) → accepted; outcome=DPIA required; 5 Art. 35(3) triggers + WP29 nine-criteria + DE/NL mandatory lists; next=scoping.processing_description submit_response ( step_id="scoping.processing_description" fields=[data_types, data_subjects, purposes, legal_basis, processors, international_transfers, high_risk_indicators] ) → accepted; 6 data categories incl. health data + flight-risk vector; 8/9 HRIs present; 3 US processors; 2 transfer paths submit_response ( step_id="scoping.dpo_consultation" fields=[designated, advice_sought, advice_summary, followed] ) → accepted; DPO designated, advice followed: Art. 22 treatment + supplementary TIA measures + Art. 88 carve-outs Show all 21 tool calls submit_response ( step_id="scoping.document_collection" documents=[] ) → accepted; demo run with no document uploads search ( query="Schrems II standard contractual clauses third country…" frameworks=[GDPR] jurisdictions=[EU] limit=6 ) → 6 results from EU Regulations MCP — GDPR Art. 45, 46, 49, Recital 108, 109, 168 search ( query="special categories health data processing employment …" frameworks=[GDPR] jurisdictions=[EU] limit=6 ) → 6 results from EU Regulations MCP — GDPR Art. 9, Art. 88, Recital 52, 53, 54, 155 submit_response ( step_id="scoping.necessity_proportionality" fields=[assessment_narrative, proportionality_assessment, lia_assessment, data_minimisation_assessment] ) → accepted; LIA fails for sentiment + sick-leave features; proportionality fails for medical-cert body ingestion submit_response ( step_id="scoping.scope_review" user_acknowledged=true ) → user_approved=true; full scope confirmed for risk identification submit_response ( step_id="risk_identification.data_subject_views" fields=[sought, method, summary] ) → accepted; Betriebsrat + OR briefings + SE survey (n=312); DE works council formally objected on BetrVG §87 grounds search ( query="data minimisation Article 5 storage limitation purpos…" frameworks=[GDPR] jurisdictions=[EU] limit=5 ) → 5 results from EU Regulations MCP — GDPR Art. 5, Art. 25, Art. 47, Recital 45, Recital 85 submit_response ( step_id="risk_identification.risk_enumeration" enumerated_risks_count=12 ) → accepted; 12 risks enumerated across confidentiality + integrity + rights categories submit_response ( step_id="risk_identification.risk_list_review" user_acknowledged=true ) → user_approved=true; R-02, R-03, R-06, R-10 flagged as focus risks submit_response ( step_id="risk_analysis.R-01 through R-12" scored_risks=12 total_safeguards=27 ) → all 12 per-risk steps accepted; CNIL 4-band severity x likelihood enum enforced; 27 safeguards across technical / organisational / contractual types submit_response ( step_id="consultation.transfer_compliance" transfers_assessed=3 ) → accepted; all 3 US paths flagged adequate=false; supplementary measures + TIA documented submit_response ( step_id="consultation.processor_compliance" processors_assessed=3 ) → accepted; Analytics Inc. flagged as go-live blocker (no DPA) submit_response ( step_id="consultation.article_36_determination" consultation_required=false ) → accepted; not required post-mitigation; pre-mitigation R-06 + R-10 would have triggered; R-06 is a hard pre-requisite submit_response ( step_id="consultation.consultation_review" user_acknowledged=true ) → user_approved=true; mitigation R-06 + R-10 confirmed as hard go-live gates generate_report ( workflow_id="7a051f04-c91f-47a2-9346-b636dd522a82" ) → structured JSON report: screening + DPO + processing description + necessity + 12 risks + 27 safeguards + transfer/processor compliance + Art. 36 determination; residual matrix 12 low / 0 medium / 0 high / 0 critical Cited answer DPIA workflow — what the gateway actually ran This is the full dpia workflow at gateway.ansvar.eu , driven end-to-end across 23 GDPR Article 35 steps. The gateway returns a structured JSON report , not a free-form answer — the agent's job is to drive the workflow, the gateway's job is to assemble the deliverable. Three downloads below: the raw JSON from generate_report , a human-readable Markdown render, and a customer-shaped PDF. What the workflow produced Screening outcome: DPIA required, with five Article 35(3) triggers fired concurrently — profiling with significant effect, large-scale special-category data (medical certificates), WP29 nine-criteria match, and both the DE BfDI and NL AP mandatory DPIA lists. Processing scope mapped: 6 data categories (including health data and a flight-risk feature vector), 5 purposes, 3 processors (PeopleFlow + AWS us-east-1 + Analytics Inc., all US), 2 international transfer paths, 8 of 9 WP248 high-risk indicators present. DPO consulted on 2026-05-08; advice followed — flight-risk treated as Article 22 automated decision-making, supplementary technical measures on top of SCCs, Article 88 Member-State carve-outs honoured (BDSG §26, UAVG art. 30, Diskrimineringslagen). Necessity assessment: LIA fails as designed for the flight-risk profiling purpose — sentiment-on-manager-comments and sick-leave frequency are … Download PDF Download Markdown Download JSON Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 12 sources — official legislation, case law, and guidance from standards bodies or regulators — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. GDPR (Regulation (EU) 2016/679) — Article 35 Data Protection Impact Assessment ↗ EU · regulation · eur-lex.europa.eu GDPR — Article 22 Automated individual decision-making, including profiling ↗ EU · regulation · eur-lex.europa.eu GDPR — Article 9 Processing of special categories of personal data ↗ EU · regulation · eur-lex.europa.eu GDPR — Article 46 Transfers subject to appropriate safeguards (SCCs) ↗ EU · regulation · eur-lex.europa.eu GDPR — Article 28 Processor obligations and Article 28(3) DPA contents ↗ EU · regulation · eur-lex.europa.eu GDPR — Article 36 Prior consultation with the supervisory authority ↗ EU · regulation · eur-lex.europa.eu GDPR — Article 88 Processing in the context of employment ↗ EU · regulation · eur-lex.europa.eu GDPR — Recital 91 (DPIA criteria for large-scale and profiling operations) ↗ EU · regulation · gdpr-info.eu EDPB Recommendations 01/2020 on supplementary measures for transfer tools (post-Schrems II) ↗ EU · guidance · edpb.europa.eu Article 29 Working Party WP248 rev.01 — Guidelines on Data Protection Impact Assessment (endorsed by EDPB) ↗ EU · guidance · ec.europa.eu Bundesdatenschutzgesetz (BDSG) §26 — Processing of employee data ↗ DE · regulation · gesetze-im-internet.de CJEU C-311/18 Schrems II — invalidation of Privacy Shield, conditions for SCC reliance ↗ EU · case-law · curia.europa.eu Run this on your own data This is available as a service: DPIA as a Service . Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. Read the full sample deliverable: Sample DPIA . Contact us --- ## Swedish tender review under LOU — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/tender-review-lou A Swedish public-procurement (LOU) tender reviewed through the Ansvar gateway — requirements checked and cited to the statute. See the cited output. Use cases Procurement Swedish tender review under LOU You are bidding on a Swedish public-sector tender. Selection criteria, award criteria, and mandatory contract clauses must align with Lagen om offentlig upphandling (LOU) and the EU procurement directives. Citations 14 Tool calls 11 Captured with Claude (MCP client) How the gateway answered Captured 2 July 2026 — a point-in-time run; corpora and tools have been updated since. Captured session Claude (MCP client) · company tier · gateway.ansvar.eu You What does Lagen om offentlig upphandling (LOU, SFS 2016:1145) require for selection criteria, award criteria, exclusion grounds, and mandatory contract clauses? Cite the LOU articles plus the corresponding EU Directive 2014/24/EU provisions. (For a real tender review, attach the tender pack and the workflow will pair every requirement against the actual document.) Ansvar gateway — 11 tool calls get_provision ( jurisdiction="SE" canonical_ref="2016:1145:13:1" ) → LOU 13 kap. 1 § full text — mandatory exclusion grounds; the row carries riksdagen's version marker 'Upphör att gälla U:2026-07-01' get_provision ( jurisdiction="SE" canonical_ref="2016:1145:13:3" ) → LOU 13 kap. 3 § full text — nine discretionary exclusion grounds; the provision cross-references LUF, LUK and LUFS get_provision ( jurisdiction="SE" canonical_ref="2016:1145:14:1" ) → LOU 14 kap. 1 § full text — the three permitted qualification-requirement families, subject-matter link, proportionality get_provision ( jurisdiction="SE" canonical_ref="2016:1145:16:1" ) → LOU 16 kap. 1 § full text — economically most advantageous tender; the three evaluation grounds get_provision ( jurisdiction="SE" canonical_ref="2016:1145:16:2" ) → LOU 16 kap. 2 § full text — subject-matter link, life-cycle rule, effective competition, no unlimited freedom of choice get_provision ( jurisdiction="SE" canonical_ref="2016:1145:17:1" ) → LOU 17 kap. 1 § full text — special environmental, social and labour-law conditions on contract performance Show all 11 tool calls search ( query="obligatoriska uteslutningsgrunder leverantör brott" jurisdictions=[SE] ) → 6 results from 8 servers; premium fan-out dispatched search_preparatory_works + search_case_law + search_agency_guidance — Prop. 2021/22:5, Prop. 2021/22:120, Prop. 2024/25:116 and LUK 11 kap. 4 a §; two off-topic rows (GDPR Art. 40, NJA 1991 s. 138) discarded search ( query="tilldelningskriterier ekonomiskt mest fördelaktiga an…" jurisdictions=[SE] ) → 6 results from 8 servers — LOU 16 kap. 1 §, LUF 4 kap. 10 §, Prop. 2015/16:195; predecessor-regime rows (SFS 2007:1091, Prop. 2006/07:128, Prop. 2010/11:150) discarded search ( query="kvalificeringskrav teknisk yrkesmässig kapacitet upph…" jurisdictions=[SE] ) → 6 results from 8 servers — LOU 14 kap. 1 §, LUF 14 kap. 11 §, LUK 12 kap. 2 §, Prop. 2015/16:195 search ( query="exclusion grounds mandatory abnormal low tenders publ…" jurisdictions=[EU] ) → 6 results from 16 servers — Directive 2014/24/EU text is not in the corpus; one on-topic hit: CJEU case-law metadata for C-267/18 (ECLI:EU:C:2019:393, Art. 57(4) optional exclusion); the rest were product regulations mentioning procurement, discarded validate_citation ( jurisdiction="SE" canonical_ref="2016:1145:13:1" ) → Citation valid — SE 2016:1145 13:1 exists and is retrievable; full provision text returned Cited answer LOU, provision by provision — what a review board actually cites Every provision below was fetched in this run: six get_provision calls against Lag (2016:1145) om offentlig upphandling (LOU) , plus premium search fan-outs whose preparatory-works pass returned the government bills behind the act. The paraphrases track the fetched text. Exclusion grounds — 13 kap. LOU 13 kap. 1 § — mandatory exclusion. A contracting authority shall exclude a supplier when a legally final judgment covers organised crime (Framework Decision 2008/841/RIF), bribery or corruption, fraud against the EU's financial interests, money laundering or terrorist financing (Directive (EU) 2015/849), terrorist offences (Directive (EU) 2017/541), or trafficking in human beings (Directive 2011/36/EU). If the supplier is a legal person, exclusion follows when a member of its administrative, management or supervisory organ was convicted. The fetched row opens with riksdagen's version marker /Upphör att gälla U:2026-07-01/ — this wording was replaced on 1 July 2026, the day before this capture, so a reviewer would pull the successor wording before relying on the fine print. LOU 13 kap. 3 § — discretionary exclusion. The authority may exclude for: breach of environmental, social or labour-law obligations; bankruptcy or insolvency proceedings; grave professional … Download PDF Download Markdown Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 14 sources — official legislation, case law, and preparatory works — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. Lag (2016:1145) om offentlig upphandling (LOU) 13 kap. 1 § — Mandatory exclusion grounds ↗ SE · regulation · riksdagen.se LOU (2016:1145) 13 kap. 3 § — Discretionary exclusion grounds ↗ SE · regulation · riksdagen.se LOU (2016:1145) 14 kap. 1 § — Qualification requirements ↗ SE · regulation · riksdagen.se LOU (2016:1145) 16 kap. 1 § — Grounds for evaluating tenders ↗ SE · regulation · riksdagen.se LOU (2016:1145) 16 kap. 2 § — Award criteria linked to the subject matter ↗ SE · regulation · riksdagen.se LOU (2016:1145) 17 kap. 1 § — Special conditions for the performance of contracts ↗ SE · regulation · riksdagen.se Lag (2016:1146) om upphandling inom försörjningssektorerna (LUF) 4 kap. 10 § — Evaluation before supplier verification ↗ SE · regulation · riksdagen.se LUF (2016:1146) 14 kap. 11 § — Reliance on other companies' capacity ↗ SE · regulation · riksdagen.se Lag (2016:1147) om upphandling av koncessioner (LUK) 12 kap. 2 § — Qualification conditions ↗ SE · regulation · riksdagen.se Prop. 2015/16:195 — Nytt regelverk om upphandling ↗ SE · preparatory-works · riksdagen.se Prop. 2021/22:5 — Ett förenklat upphandlingsregelverk ↗ SE · preparatory-works · riksdagen.se Prop. 2021/22:120 — En effektivare överprövning av offentliga upphandlingar ↗ SE · preparatory-works · riksdagen.se Prop. 2024/25:116 — EU:s IPI-förordning och upphandlingslagstiftningen ↗ SE · preparatory-works · riksdagen.se CJEU C-267/18 (ECLI:EU:C:2019:393) — Directive 2014/24/EU Art. 57(4), optional exclusion grounds ↗ EU · case-law · eur-lex.europa.eu Run this on your own data Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. Contact us --- ## STRIDE threat model for an authentication flow — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/stride-threat-model A STRIDE threat model of an authentication flow through the Ansvar gateway — threats cited to MITRE CAPEC, OWASP and STRIDE patterns; gaps marked, not guessed. Use cases Security STRIDE threat model — quick narrative via search You are designing a new B2B authentication flow using OAuth 2.1 + OIDC + Keycloak. Your security architect wants a fast STRIDE narrative grounded in OWASP and STRIDE-patterns before committing to a full workflow run. Citations 17 Tool calls 5 Captured with claude-fable-5 How the gateway answered Captured 2 July 2026 — a point-in-time run; corpora and tools have been updated since. Captured session claude-fable-5 · company tier · gateway.ansvar.eu You Build a STRIDE threat model for the following authentication architecture: user → Keycloak → resource server → PostgreSQL. For each STRIDE category list threats and attack techniques, verification requirements, and control mappings; cite STRIDE patterns, MITRE CAPEC, OWASP, NIST 800-53 where available, and any EU product-security duties (CRA). Ansvar gateway — 5 tool calls search ( query="spoofing authentication token replay trust boundary" sources=[stride-patterns] ) → 5 threat patterns — STRIDE-API-OAUTH-001, STRIDE-EMAIL-SPF-001, STRIDE-PAYMENT-TOKEN-001, STRIDE-MEDDEV-SPOOF-005, STRIDE-CRYPTO-RANDOM-001 search ( query="session token replay authentication bypass" sources=[capec] ) → 5 MITRE attack patterns via the search_capec_patterns fan-out — CAPEC-114, CAPEC-115, CAPEC-140, CAPEC-196, CAPEC-102 (capec.mitre.org, The MITRE Corporation) search ( query="session management verification requirements token" sources=[owasp] ) → 2 results — ASVS V3.2.1 (new session token on authentication), WSTG-SESS-01 Objective 2 (session-ID randomness) search ( query="access control least privilege authentication" sources=[security-controls] ) → 5 catalog controls — IAC-20, CPL-03.3, IAC-21, IAC-16.3, AAT-29.2; no NIST 800-53 identifiers in the returned rows search ( query="products with digital elements essential cybersecurit…" jurisdictions=[EU] ) → 4 results via search + agency-guidance + case-law fan-out — CRA Annex I Part I, MDCG 2025-6, plus 2 off-scope rows (batteries-regulation recital, automotive repair-access guidance) Cited answer STRIDE threat model — OAuth 2.1 + OIDC + Keycloak authentication flow Four components in scope: user agent → Keycloak (auth server) → resource server → PostgreSQL . Each STRIDE category below is grounded in one of five gateway searches from this run — the STRIDE threat-pattern library, MITRE CAPEC attack patterns (publisher: The MITRE Corporation, served with capec.mitre.org source links), OWASP verification requirements, the security-controls catalog, and EU product law. A category with no fetched evidence is marked unresolved instead of being filled from model memory. Spoofing Authentication mechanism abuse. CAPEC-114 : an attacker "obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism" or by exploiting a flaw in it — the umbrella threat over every login path Keycloak exposes. Authentication bypass. CAPEC-115 : the attacker "gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism". This row also grounds Elevation of privilege below. Forged session credential. CAPEC-196 : "An attacker creates a false but functional session credential in order to gain or usurp access to a service." Predictable token generation. Predictable Token … Download PDF Download Markdown Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 17 sources — official legislation, guidance from standards bodies or regulators, threat-pattern libraries, and controls catalog — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. STRIDE patterns — OAuth 2.0 Access Token Theft and Replay in Spring Boot and Express.js Applications (STRIDE-API-OAUTH-001) intl · threat-pattern · served via the gateway STRIDE patterns — Email Spoofing via SPF/DKIM/DMARC Bypass (STRIDE-EMAIL-SPF-001) intl · threat-pattern · served via the gateway STRIDE patterns — Tokenization Bypass and Token Reuse Attacks (STRIDE-PAYMENT-TOKEN-001) intl · threat-pattern · served via the gateway STRIDE patterns — Medical Device Identity Spoofing via Default Credentials and Weak Authentication (STRIDE-MEDDEV-SPOOF-005) intl · threat-pattern · served via the gateway STRIDE patterns — Predictable Token Generation via Weak Random Number Generators (STRIDE-CRYPTO-RANDOM-001) intl · threat-pattern · served via the gateway MITRE CAPEC-114 — abusing weaknesses of an authentication mechanism ↗ intl · threat-pattern · capec.mitre.org MITRE CAPEC-115 — evading or circumventing an authentication mechanism ↗ intl · threat-pattern · capec.mitre.org MITRE CAPEC-140 — bypassing an ordered sequence of web forms ↗ intl · threat-pattern · capec.mitre.org MITRE CAPEC-196 — forging a false but functional session credential ↗ intl · threat-pattern · capec.mitre.org MITRE CAPEC-102 — session sidejacking over unencrypted channels ↗ intl · threat-pattern · capec.mitre.org OWASP ASVS 4.0.3 — V3.2.1: new session token on user authentication ↗ intl · guidance · github.com OWASP WSTG v4.2 — Testing for Session Management Schema, Objective 2 ↗ intl · guidance · github.com Security controls — IAC-20: Least-privilege logical access intl · controls-catalog · served via the gateway Security controls — IAC-21: Least privilege for processes intl · controls-catalog · served via the gateway Security controls — IAC-16.3: Step-up authentication for privilege changes intl · controls-catalog · served via the gateway Cyber Resilience Act (Regulation (EU) 2024/2847), Annex I, Part I — Essential cybersecurity requirements ↗ eu · regulation · eur-lex.europa.eu MDCG 2025-6 — cybersecurity measures required by the AIA and MDR/IVDR ↗ eu · guidance · health.ec.europa.eu Run this on your own data This is available as a service: Threat Model as a Service . Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. Read the full sample deliverable: Sample threat model . Contact us --- ## EU AI Act high-risk classification for credit scoring — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/ai-act-classification EU AI Act high-risk classification for a credit-scoring system through the Ansvar gateway — cited to the Act, with unresolved points marked. See the output. Use cases AI governance EU AI Act high-risk classification — credit scoring You are building a credit-scoring AI for three EU markets. This run resolves the EU AI Act's harmonised high-risk classification from fetched article text — Articles 6 and 27 in full, the Annex III entry via search — while the DE/FR/IT overlay sweeps returned adjacent material only (a BfDI statement on Germany's implementing act, Italy's Legge 132/2025) and are marked as capture gaps. Citations 7 Tool calls 8 Captured with Claude (MCP client) How the gateway answered Captured 2 July 2026 — a point-in-time run; corpora and tools have been updated since. Captured session Claude (MCP client) · company tier · gateway.ansvar.eu You Compare AI Act high-risk classification for credit scoring across DE, FR, and IT. Include the harmonised EU position (Regulation (EU) 2024/1689 Annex III) plus any national supervisory-authority guidance. Side-by-side, with citations. Ansvar gateway — 8 tool calls search ( query="high-risk AI system creditworthiness credit score eva…" jurisdictions=[EU] ) → 6 results from 18 servers — 2 on-point: the AI Act Annex III creditworthiness row (point 5(b), with eur-lex anchor) and the AI Office prohibited-practices guidelines; 4 off-topic rows from other EU corpora (batteries, roadworthiness, vehicle regulations) not used get_provision ( law="ai-act" article="art_6" jurisdiction="EU" ) → Full text of Article 6 — classification rules, the Art. 6(3) derogation and its profiling override, the Art. 6(4) documentation + registration duty, and the Commission-guidelines deadline of 2 February 2026 get_provision ( law="ai-act" article="art_27" jurisdiction="EU" ) → Full text of Article 27 — FRIA duty naming deployers of Annex III points 5(b) and (c) systems, the six assessment elements, market-surveillance notification, and the GDPR Art. 35 DPIA complement get_provision ( law="ai-act" article="annex_III" jurisdiction="EU" ) → FAILED — 'No provision matches EU AI_ACT annex_III.' The annex is not directly addressable by this ref; the point 5(b) text was resolved via the search row instead search ( query="Kreditwürdigkeit KI-System Hochrisiko künstliche Inte…" jurisdictions=[DE] ) → 5 results from 7 servers — none on-point for credit-scoring AI; nearest is a BfDI statement on the German AI Act implementing act (KI-VO-DG); the rest are patent-court decisions, a curriculum regulation, and BetrVG § 95 search ( query="intelligence artificielle haut risque évaluation solv…" jurisdictions=[FR] ) → 5 results from 5 servers — consumer-credit creditworthiness provisions (Code de la consommation L313-18) and Conseil constitutionnel credit decisions; no AI Act positions Show all 8 tool calls search ( query="intelligenza artificiale alto rischio affidabilità cr…" jurisdictions=[IT] ) → 5 results from 5 servers — Legge 132/2025 art. 3 (Italy's national AI law, GPAI-scoped) plus off-topic constitutional cases on regional banking powers; no credit-scoring AI position search_guidance ( query="AI Act high-risk classification credit scoring credit…" jurisdictions=[EU] ) → 2 results from 3 servers — AI Office prohibited-practices guidelines (Art. 5(1)(c) social scoring, mentioning credit-scoring/creditworthiness) on-point; UN R155 vehicle-cybersecurity hit off-topic Cited answer EU AI Act high-risk classification — credit-scoring AI for DE, FR, IT The EU position below comes from fetched text: Article 6 and Article 27 of Regulation (EU) 2024/1689 were retrieved in full, and the Annex III credit-scoring entry arrived through search after a direct annex lookup found no provision. The three national-overlay sweeps ran and are reported exactly as they came back — adjacent material, no credit-scoring positions. The classification test — Article 6 (fetched in full) Article 6 sets two routes into high-risk status: the Annex I product-safety route (Art. 6(1)) and the listed-use-case route: "In addition to the high-risk AI systems referred to in paragraph 1, AI systems referred to in Annex III shall be considered to be high-risk." — Art. 6(2) The Art. 6(3) derogation removes Annex III systems that do "not pose a significant risk of harm to the health, safety or fundamental rights of natural persons" and meet one of four conditions (narrow procedural task; improving a previously completed human activity; pattern-detection that does not replace human assessment; a preparatory task). Its final sentence closes that exit for most scoring systems: "Notwithstanding the first subparagraph, an AI system referred to … Download PDF Download Markdown Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 7 sources — official legislation, and guidance from standards bodies or regulators — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. AI Act Article 6 — Classification rules for high-risk AI systems ↗ EU · regulation · eur-lex.europa.eu AI Act Article 27 — Fundamental rights impact assessment for high-risk AI systems ↗ EU · regulation · eur-lex.europa.eu AI Act Annex III, point 5(b) — creditworthiness / credit score (resolved via search; direct annex lookup found no provision) ↗ EU · regulation · eur-lex.europa.eu Commission (AI Office) Guidelines on prohibited AI practices — Article 5(1)(c) social scoring section ↗ EU · guidance · digital-strategy.ec.europa.eu BfDI Stellungnahme — hearing on the German AI Act implementing act (KI-VO-DG); adjacent, not a credit-scoring position ↗ DE · guidance · bfdi.bund.de Code de la consommation, art. L313-18 — creditworthiness assessment in consumer credit (no AI dimension) ↗ FR · regulation · legifrance.gouv.fr Legge 23 settembre 2025, n. 132, art. 3 — Italy's national AI law (fetched provision is GPAI-scoped, not credit scoring) ↗ IT · regulation · normattiva.it Run this on your own data This is available as a service: AI Act Readiness Assessment . Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. Read the full sample deliverable: Sample AI Act readiness assessment . See the coverage behind this run on the AI governance sector page . Contact us --- ## Paragraph-cited review of a data-retention policy — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/document-review-retention-policy A real document review through the Ansvar gateway: a retention policy vs GDPR storage limitation, every finding hash-anchored to its exact paragraph. Use cases Privacy Document review: a retention policy, paragraph-cited Your counsel or DPO needs a defensible review of the company's data-retention policy — every finding pinned to the exact paragraph it concerns, hash-anchored so it stays checkable after the next revision. Citations 6 Tool calls 33 Captured with claude-fable-5 How the gateway answered Captured 2 July 2026 — a point-in-time run; corpora and tools have been updated since. Editor's note. Reference 13 in the transcript links bokföringslagen via the SFS-number URL the source corpus returned; riksdagen.se has since moved that page. The citations panel and downloads use the working canonical URL. The fictional subject document was authored for this capture and is downloadable above; the gateway calls, citations, and report are the real session output. Captured session claude-fable-5 · company tier · gateway.ansvar.eu You Upload our data-retention policy and run a document review against GDPR storage-limitation requirements and Swedish practice. Cite the exact paragraph of the policy for every finding, and the regulatory basis from the sources — flag anything you can't ground. Ansvar gateway — 33 tool calls register_document_init ( filename="nordbram-retention-policy-v2.1.md" mime_type="text/markdown" file_size=3037 ) → Error: documents_service_error: 415 (unsupported media type) register_document_init ( filename="nordbram-retention-policy-v2.1.md" mime_type="text/markdown" file_size=3037 ) → Retry — same error: documents_service_error: 415 register_document_init ( filename="nordbram-retention-policy-v2.1.md" mime_type="text/plain" file_size=3037 ) → OK — document_id 1ad7b053-cf78-4e53-b11c-0ec85fb0da68 (DOC-GEKG), presigned PUT URL returned; bytes then PUT via curl with Content-Type text/plain, HTTP 200 register_document_finalize ( document_id="1ad7b053-cf78-4e53-b11c-0ec85fb0da68" ) → status=ready, source SHA-256 5448b09c624cc817790ba2e21eea994f82fa03429ffc71fb5339bf8dc65300b2 start_workflow ( workflow_type="review" entity_description="Nordbram Logistics AB — review of data-retention poli…" jurisdictions=[SE, EU] ) → workflow_id 1df0135f-7ebf-411b-9c80-a2b8d975cb25 started; first step upload.provide_document submit_response ( workflow_id="1df0135f-7ebf-411b-9c80-a2b8d975cb25" step_id="upload.provide_document" responses=[object Object] user_acknowledged=true ) → Rejected — at least 1 document must be registered to the workflow first (register_document) Show all 33 tool calls get_document_segments ( document_id="1ad7b053-cf78-4e53-b11c-0ec85fb0da68" ) → Segment outline returned: 1 section + 32 paragraph refs (0.p1–0.p32) with char ranges and content hashes register_document ( workflow_id="1df0135f-7ebf-411b-9c80-a2b8d975cb25" document_id="1ad7b053-cf78-4e53-b11c-0ec85fb0da68" role="evidence" ) → Bound to workflow, binding_id adb3c0c4-b84c-44d2-8e43-babf4b428e9d submit_response ( workflow_id="1df0135f-7ebf-411b-9c80-a2b8d975cb25" step_id="upload.provide_document" responses=[object Object] user_acknowledged=true ) → Accepted — next step review.findings get_current_step ( workflow_id="1df0135f-7ebf-411b-9c80-a2b8d975cb25" ) → review.findings: requires summary, findings (id/title/observation/severity/evidence_references with doc:// paragraph URIs), recommendations search ( query="storage limitation retention of personal data" jurisdictions=[SE, EU] frameworks=[GDPR] limit=10 ) → 10 results: GDPR art_5, CJEU ECLI:EU:C:2022:805 (C-77/21 Digi), EDPB Guidelines 4/2019 relevant; rest off-topic search_guidance ( query="retention periods storage limitation personal data de…" jurisdictions=[SE, EU] limit=10 ) → EDPB Guidelines 4/2019 with quotable retention passage; remaining hits (CERT-SE newsletters etc.) irrelevant get_provision ( jurisdiction="EU" law="GDPR" article="5" ) → Full text of GDPR Art. 5 incl. 5(1)(b),(c),(e) and 5(2) accountability; canonical GDPR:art_5 get_provision ( jurisdiction="EU" law="GDPR" article="17" ) → Full text of GDPR Art. 17 right to erasure incl. 17(1)(a), 17(3)(b),(e); canonical GDPR:art_17 search_guidance ( query="kamerabevakning lagringstid inspelat material" jurisdictions=[SE] limit=8 ) → No relevant guidance — single CERT-SE newsletter hit only search ( query="gallring personuppgifter arbetssökande rekrytering" jurisdictions=[SE] limit=8 ) → Indirect hits (GDPR art-88/recital-155, Swedish propositions); no quotable provision on applicant-data retention periods search ( query="räkenskapsinformation arkivering sju år bokföringslag…" jurisdictions=[SE] limit=8 ) → Bokföringslagen (1999:1078) surfaced incl. lookup ref; prop 2017/18:149 notes archiving period shortened 10→7 years get_provision ( canonical_ref="1999:1078:7:2" jurisdiction="SE" ) → Full text bokföringslagen 7 kap. 2 §: räkenskapsinformation kept until end of 7th year after calendar year fiscal year closed get_decision ( jurisdiction="EU" canonical_ref="ECLI:EU:C:2022:805" ) → CJEU C-77/21 Digi (2022-10-20): Art. 5(1)(b)+(e), purpose/storage limitation, retention period in light of purposes search ( query="kamerabevakning inspelat material bevarande" jurisdictions=[SE] limit=8 ) → IMY 'Vägledning vid kamerabevakning' (2021:2) surfaced with lookup ref; also prop 2017/18:231 and HFD camera cases get_provision ( canonical_ref="imy:vagledning-vid-kamerabevakning" jurisdiction="SE" ) → Catalogue entry only (title/date/URL) — no substantive retention-duration text retrievable search ( query="diskrimineringslagen preskription talan arbetssökande…" jurisdictions=[SE] limit=8 ) → Only indirect refs (SFS 1999:678 § 50 cross-referencing diskrimineringslagen 2008:567); 1 source temporarily unavailable; no quotable limitation-period provision resolve_document_segment ( uri="doc://1ad7b053-cf78-4e53-b11c-0ec85fb0da68/segment/pa…" quote="Customer account data and shipment records are retain…" ) → valid=true, paragraph fidelity, hash 97eef893... resolve_document_segment ( uri="doc://1ad7b053-cf78-4e53-b11c-0ec85fb0da68/segment/pa…" quote="CVs, cover letters, and interview notes of unsuccessf…" ) → valid=true, paragraph fidelity, hash 10fbdd14... resolve_document_segment ( uri="doc://1ad7b053-cf78-4e53-b11c-0ec85fb0da68/segment/pa…" quote="All staff email accounts are archived in full..." ) → valid=true, paragraph fidelity, hash 826355a8... resolve_document_segment ( uri="doc://1ad7b053-cf78-4e53-b11c-0ec85fb0da68/segment/pa…" quote="Backup media are retained according to the backup rot…" ) → valid=true, paragraph fidelity, hash f63cf6e2... resolve_document_segment ( uri="doc://1ad7b053-cf78-4e53-b11c-0ec85fb0da68/segment/pa…" quote="Paper records are stored in the Gothenburg archive ro…" ) → valid=true, paragraph fidelity, hash 3b01dcaf... resolve_document_segment ( uri="doc://1ad7b053-cf78-4e53-b11c-0ec85fb0da68/segment/pa…" quote="Camera recordings from terminal and warehouse premise…" ) → valid=true, paragraph fidelity, hash 089b61ad... resolve_document_segment ( uri="doc://1ad7b053-cf78-4e53-b11c-0ec85fb0da68/segment/pa…" quote="Electronic data is deleted using the standard deletio…" ) → valid=true, paragraph fidelity, hash e839cc33... submit_response ( workflow_id="1df0135f-7ebf-411b-9c80-a2b8d975cb25" step_id="review.findings" responses=[object Object] evidence_references="[7 doc:// URIs + 6 regulatory URLs]" user_acknowledged=true ) → Accepted — next step review_handoff.user_review get_current_step ( workflow_id="1df0135f-7ebf-411b-9c80-a2b8d975cb25" ) → review_handoff.user_review: server-enforced human gate, requires user_approved submit_response ( workflow_id="1df0135f-7ebf-411b-9c80-a2b8d975cb25" step_id="review_handoff.user_review" responses=[object Object] user_acknowledged=true ) → Accepted — next step report.generate generate_report ( workflow_id="1df0135f-7ebf-411b-9c80-a2b8d975cb25" format="json" ) → Report generated: 7 findings (1 critical/3 major/3 minor), 7 recommendations, 13 provenance entries, all doc hashes verified, drifted=false Cited answer Compliance Review Report — Nordbram Logistics AB Data Retention Policy v2.1 Entity Nordbram Logistics AB (fictional Swedish logistics company) Document nordbram-retention-policy-v2.1.md (DOC-GEKG, source SHA-256 5448b09c624cc817790ba2e21eea994f82fa03429ffc71fb5339bf8dc65300b2 ) Workflow Document Review (Paragraph-Cited), 1df0135f-7ebf-411b-9c80-a2b8d975cb25 Jurisdictions SE, EU (framework: GDPR) Generated 2026-07-02T20:26:22Z Approval User-review gate passed — "approved by operator for capture" Summary The document is Nordbram Logistics AB's Data Retention Policy v2.1 (approved 2025-11-04), covering personal data of employees, applicants, customers, carrier partners and visitors across Sweden and Norway. The policy states the correct general principle (retention only as long as necessary), but several concrete rules contradict it: indefinite retention of unsuccessful applicants' data, blanket 10-year full email archiving, discretionary postponement of disposal, and undefined backup and physical-archive schedules. Measured against GDPR Art. 5(1)(e) (storage limitation), Art. 17 (erasure), CJEU C-77/21 (Digi) and EDPB Guidelines 4/2019, the policy needs one critical and several major corrections; the 7-year bookkeeping-based periods are broadly aligned with bokföringslagen (1999:1078) 7 kap. 2 § but are applied too widely. Severity profile: 1 critical · 3 major · 3 minor. Findings F-1 · CRITICAL … Download PDF Download Markdown Download JSON Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 6 sources — official legislation, guidance from standards bodies or regulators, and case_law — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. GDPR (Regulation (EU) 2016/679), Art. 5 — incl. 5(1)(b) purpose limitation, 5(1)(c) data minimisation, 5(1)(e) storage limitation, 5(2) accountability (canonical ref GDPR:art_5) ↗ EU · regulation · eur-lex.europa.eu GDPR (Regulation (EU) 2016/679), Art. 17 — right to erasure, incl. 17(1)(a), 17(3)(b), 17(3)(e) (canonical ref GDPR:art_17) ↗ EU · regulation · eur-lex.europa.eu CJEU, Case C-77/21, Digi Távközlési és Szolgáltató Kft. v NAIH, judgment of 20 October 2022, ECLI:EU:C:2022:805 (CELEX 62021CJ0077) ↗ EU · case_law · eur-lex.europa.eu EDPB Guidelines 4/2019 on Article 25 — Data Protection by Design and by Default (retention-limitation passage on Art. 25(2)) ↗ EU · guidance · edpb.europa.eu Bokföringslagen (1999:1078) 7 kap. 2 § — bevarandetid för räkenskapsinformation (until end of the seventh year after the calendar year in which the fiscal year closed), as amended by Lag (2024:342) ↗ SE · regulation · riksdagen.se IMY (Integritetsskyddsmyndigheten), Vägledning vid kamerabevakning, rapport 2021:2 (2021-05-26) — catalogue entry only; specific storage-duration text not retrievable via gateway this session ↗ SE · guidance · imy.se Run this on your own data Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. Contact us --- ## ISO 27001 to NIST CSF 2.0 through a canonical control library — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/control-library-crosswalk A real crosswalk through Ansvar's control library: Annex A.5.26 lands on IR-4 and 24 CSF 2.0 subcategories, with NIST OLIR provenance on every mapping edge. Use cases Security ISO 27001 → NIST CSF 2.0 through the canonical control library An ISO/IEC 27001:2022-certified company must report security posture to its US parent on NIST CSF 2.0. Instead of maintaining a hand-built mapping spreadsheet, the team asks Ansvar's control library to walk Annex A.5.26 (incident response) through the canonical control spine to CSF 2.0 — with the provenance of every mapping edge, and an honest line on what the library will and will not claim. Citations 5 Tool calls 4 Captured with claude-fable-5 How the gateway answered Captured 4 August 2026 — a point-in-time run; corpora and tools have been updated since. Editor's note. Tool calls, results, citations and the trace on this page are a real gateway session (company tier, 4 August 2026). The narrative answer was composed from those results for readability rather than pasted verbatim from the run. Captured session claude-fable-5 · company tier · gateway.ansvar.eu You Using Ansvar: we're ISO 27001:2022-certified and our US parent reports on NIST CSF 2.0. Which canonical control sits behind Annex A.5.26, where does it land in CSF 2.0, and what's the provenance of each mapping? Ansvar gateway — 4 tool calls crosswalk ( from_framework="iso27001" from_ref="A.5.26" to_framework="nist-csf" ) → 24 CSF 2.0 subcategories via pivot control IR-4 — every path a review-approved NIST OLIR related-to edge with stored direction, confidence and OLIR sheet-row source_ref; navigation links only, no coverage claim derived get_control ( control_id="IR-4" ) → IR-4 Incident Handling — full 800-53r5 statement + discussion, 29 approved mappings: ISO 27001:2022 ×3, CSF 2.0 ×24, 800-171 r3 ×1, plus the 800-53 identity edge resolve ( requirement_id="nis2:2022#art-21" ) → Citation descriptor: 'Cybersecurity risk-management measures', normative/active, EUR-Lex ELI URL, live gateway resolution via get_provision(EU, NIS2, art. 21) against eu-regulations; licence EUR-Lex-Decision-2011-833 coverage ( ) → Library state: 23 frameworks, 1,196 controls, 2,360 mappings loaded (catalog 800-53r5 5.2.0); NIS2 register carries 48 normative requirements; cross-framework set-theory typing pending human review — coverage counts stay at zero until reviewed, by design Cited answer Where ISO 27001 incident response lands in NIST CSF 2.0 The question. We hold ISO/IEC 27001:2022 certification; our US parent reports on NIST CSF 2.0. Which canonical control sits behind Annex A.5.26 (response to information security incidents), where does it land in CSF 2.0, and what is the provenance of each mapping? The pivot: one canonical control. The control library resolves ISO/IEC 27001:2022 Annex A.5.26 onto the canonical spine at IR-4 — Incident Handling (NIST SP 800-53 Rev 5, catalog release 5.2.0). The edge is a NIST OLIR informative reference — the SP 800-53 Rev 5 → ISO/IEC 27001:2022 mapping, 2023-10-12 update, sheet IR row 22 — carried in the library as a review-approved related-to edge with provenance_origin: nist-published . … Download PDF Download Markdown Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 5 sources — official legislation, standards clause maps, standard mapping, framework, and control catalog — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. NIST OLIR informative reference — SP 800-53 Rev 5 → ISO/IEC 27001:2022 mapping (2023-10-12 update), sheet IR row 22 intl · standard-mapping · served via the gateway NIST Cybersecurity Framework 2.0 (CSWP 29) — 24 subcategory informative references reached from IR-4 ↗ intl · framework · csrc.nist.gov NIST SP 800-53 Rev 5 (release 5.2.0) — IR-4 Incident Handling, canonical spine control ↗ intl · control-catalog · csrc.nist.gov ISO/IEC 27001:2022 Annex A.5.26 — response to information security incidents ↗ intl · standard · iso.org NIS2 (Directive (EU) 2022/2555) Art. 21 — citation descriptor resolving live via get_provision against eu-regulations; licence EUR-Lex-Decision-2011-833 ↗ eu · regulation · eur-lex.europa.eu Run this on your own data Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. See the coverage behind this run on the IT & cloud security sector page . Contact us --- ## LINDDUN privacy threat model for a customer-data store — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/linddun-privacy A real LINDDUN-go run over a customer-data warehouse: linkability through non-compliance assessed per data flow, each threat cited to the provision behind it. Use cases Privacy LINDDUN privacy threat model for a customer-data store You are adding a new customer-data warehouse. The privacy team wants a LINDDUN-go privacy threat model: linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, non-compliance — per data flow. Citations 10 Tool calls 3 Captured with claude-opus-4-7 How the gateway answered Captured 14 May 2026 — a point-in-time run; corpora and tools have been updated since. Captured session claude-opus-4-7 · team tier · gateway.ansvar.eu You Build a LINDDUN-go privacy threat model for the following data flow: SaaS app → ETL service → customer warehouse → BI tool. Show threats per LINDDUN category, mitigations, and cite GDPR / ePrivacy / DPA guidance where relevant. Ansvar gateway — 3 tool calls search ( query="linkability identifiability profiling automated decis…" frameworks=[GDPR] limit=8 ) → 8 results: GDPR Art. 22, 13, 14, 15, 20, 21, 47 + Recital 71 search ( query="electronic communications privacy confidentiality coo…" frameworks=[EPRIVACY] limit=6 ) → 6 results from ePrivacy Directive — Art. 5 + Recitals 4, 6, 21, 33, 46 search ( query="data protection impact assessment large-scale systema…" frameworks=[GDPR] limit=6 ) → 6 results: GDPR Art. 35, 37 + Recitals 72, 90, 91, 97 Cited answer LINDDUN-go threat model — SaaS app → ETL → customer warehouse → BI tool Four pipeline stages, seven LINDDUN-go categories. Each row maps a privacy threat to the cited control. The GDPR coverage in this run is strong; ePrivacy is relevant only at the SaaS-collection edge. L — Linkability Distinct records can be tied back to the same person across the pipeline even when no direct identifier is present. Stage Threat Cited control SaaS app Session IDs + IP + UA fingerprint sufficient to re-identify GDPR Art. 5 (data minimisation, storage limitation) ETL Join keys exposed across previously isolated datasets GDPR Art. 35 (DPIA for systematic large-scale evaluation) Warehouse Cross-table joins enable singling-out GDPR Recital 91 (DPIA explicitly required for systematic + extensive profiling) BI Small-cohort filters reveal individuals Aggregation thresholds (k-anonymity); no on-point gateway citation in this run I — Identifiability A pseudonymous record becomes identifiable. Stage Threat Cited control SaaS app Email + name collected when not needed GDPR Art. 5 (purpose limitation, minimisation) … Download PDF Download Markdown Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 10 sources — official legislation — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. GDPR Article 5 — Principles relating to processing ↗ EU · regulation · gdpr-info.eu GDPR Article 13 — Information at collection ↗ EU · regulation · gdpr-info.eu GDPR Article 14 — Information when data not from subject ↗ EU · regulation · gdpr-info.eu GDPR Article 15 — Right of access ↗ EU · regulation · gdpr-info.eu GDPR Article 21 — Right to object ↗ EU · regulation · gdpr-info.eu GDPR Article 22 — Automated decisions including profiling ↗ EU · regulation · gdpr-info.eu GDPR Article 35 — DPIA ↗ EU · regulation · gdpr-info.eu GDPR Article 37 — DPO designation ↗ EU · regulation · gdpr-info.eu GDPR Recitals 71, 72, 91, 113 — Profiling and DPIA rationale ↗ EU · regulation · gdpr-info.eu ePrivacy Directive 2002/58/EC Article 5 — Confidentiality of communications ↗ EU · regulation · eur-lex.europa.eu Run this on your own data This is available as a service: Threat Model as a Service . Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. See the coverage behind this run on the Privacy & data protection sector page . Contact us --- ## Employee-monitoring rules in NL, DE and FR — worked example · Ansvar AI URL: https://ansvar.eu/use-cases/national-gdpr One question, three jurisdictions: the works-council and labour-code overlays on GDPR for staff monitoring in the Netherlands, Germany and France, each cited. Use cases Privacy What national rules apply to employee monitoring (NL, DE, FR)? Your team is rolling out a productivity-monitoring tool to staff in the Netherlands, Germany, and France. Each jurisdiction has its own works-council and labour-code overlay on top of GDPR. Citations 10 Tool calls 10 Captured with claude-opus-4-7 How the gateway answered Captured 14 May 2026 — a point-in-time run; corpora and tools have been updated since. Captured session claude-opus-4-7 · team tier · gateway.ansvar.eu You What national rules apply to employee productivity monitoring in NL, DE, and FR? Cite the relevant labour-code sections, works-council requirements, and DPA guidance. Highlight where the three jurisdictions diverge. Ansvar gateway — 10 tool calls list_coverage ( ) → NL/DE/FR all have data-protection domain coverage search ( query="werknemers monitoring privacy ondernemingsraad instem…" jurisdictions=[NL] limit=10 ) → 10 results from 5 NL servers; Works Councils Act BWBR0002747 art 27 + 32 returned search ( query="Mitarbeiterüberwachung Betriebsrat Datenschutz Arbeit…" jurisdictions=[DE] limit=10 ) → 10 results from 5 DE servers; mostly European-cooperative governance, no direct BetrVG § 87 search ( query="surveillance des salariés comité social économique co…" jurisdictions=[FR] limit=10 ) → 1 result from French Law MCP — Code du travail L2422-1 (protected representatives) search ( query="employment context personal data processing employee …" frameworks=[GDPR] limit=10 ) → 10 EU Regulations MCP results — Art. 88, Recital 155, Art. 35, Art. 9, Art. 39, Recitals 52/97/127, Art. 3, Recital 48 search ( query="Betriebsverfassungsgesetz § 87 Mitbestimmung technisc…" jurisdictions=[DE] limit=8 ) → 0 results; partial=true: German Law MCP temporarily unavailable Show all 10 tool calls search ( query="Bundesdatenschutzgesetz § 26 Beschäftigtendatenschutz…" jurisdictions=[DE] limit=8 ) → 0 results; partial=true: German Law MCP temporarily unavailable search ( query="Code du travail L1121-1 L1222-4 surveillance proporti…" jurisdictions=[FR] limit=8 ) → 8 results from French Law MCP — Code du travail R1221 series (pre-hire declarations), off-topic search_guidance ( query="workplace monitoring employee surveillance proportion…" jurisdictions=[NL, DE, FR] limit=15 ) → 0 results; only Cybersecurity MCPs queried (DP MCPs do not advertise search_agency_guidance for this scope) search ( query="vidéosurveillance cybersurveillance employeur loyauté…" jurisdictions=[FR] limit=5 ) → 5 results from French Law MCP — Code de la sécurité intérieure L256-1..L256-4 (custody video surveillance), off-topic Cited answer Employee productivity monitoring — NL, DE, FR The Ansvar gateway routes this question to five MCPs per jurisdiction plus the EU Regulations corpus. Below is the verbatim picture from those sources today. Where a national MCP did not return on-point material in this run, I say so explicitly rather than fill the gap from training data — that is the No Silent Fallbacks rule the platform enforces. EU horizontal floor (applies in all three jurisdictions) GDPR is the floor and explicitly authorises Member-State divergence on top of it: GDPR Article 88 — Processing in the context of employment. Member States may, by law or by collective agreement, provide more specific rules for processing employees' personal data, including for monitoring purposes. Where national rules exist, they govern. GDPR Recital 155 specifies that the vehicle for those national rules can include works-agreement instruments such as Dutch ondernemingsraad -consent and German Betriebsvereinbarungen. GDPR Article 35 — Data protection impact assessment is mandatory before systematic monitoring of employees at scale; the EDPB lists this category as high-risk. GDPR Article 9 — Special categories. If the monitoring tool captures health data (e.g. break-time absence patterns inferring illness), biometric identifiers, or … Download PDF Download Markdown Every claim traces to a source you can open A typical AI assistant invents a citation that looks plausible. Ansvar retrieves the real one. Every finding above rests on one of these 10 sources — official legislation — linked wherever the source is publicly reachable; catalog rows served through the gateway are quoted as fetched. No citation is fabricated — every source was retrieved through Ansvar and can be checked. GDPR Article 88 — Processing in the context of employment ↗ EU · regulation · gdpr-info.eu GDPR Recital 155 — Processing in the employment context ↗ EU · regulation · gdpr-info.eu GDPR Article 35 — Data protection impact assessment ↗ EU · regulation · gdpr-info.eu GDPR Article 9 — Special categories of personal data ↗ EU · regulation · gdpr-info.eu GDPR Article 39 — Tasks of the data protection officer ↗ EU · regulation · gdpr-info.eu GDPR Recital 127 — Single-Member-State employment processing ↗ EU · regulation · gdpr-info.eu Wet op de ondernemingsraden, Article 27 — Instemmingsrecht (works-council consent) ↗ NL · regulation · wetten.overheid.nl Wet op de ondernemingsraden, Article 32 — Scope of works-council rights ↗ NL · regulation · wetten.overheid.nl Arbeidsomstandighedenwet, Article 12 — Consultation duty on working conditions ↗ NL · regulation · wetten.overheid.nl Code du travail Article L2422-1 — Protected employee representatives ↗ FR · regulation · legifrance.gouv.fr Run this on your own data Bring your own documents and scope, and we'll run it end-to-end — every finding cited and validated by the expert who delivers it. See the coverage behind this run on the Privacy & data protection sector page . Contact us --- ## Expert-reviewed compliance deliverables · Ansvar AI URL: https://ansvar.eu/services A threat model for the audit, a DPIA for the regulator, a gap register for the board — senior-reviewed, cited to the article, fixed scope agreed up front. Services When you need the deliverable , not another tool. A threat model for the audit. A DPIA the regulator will actually read. A gap register the board can act on. We produce it on the same cited engine our customers use — and a senior practitioner reviews and signs every finding. Book a scoping call Read a real deliverable Fixed scope · quote and date after a 30-minute call. Why teams call us Something has a date on it. Nobody wakes up wanting a DPIA. An audit is scheduled, a regulation starts applying, a customer asks — and now a document with your name on it has to hold up. Find your situation; it links to what we deliver. The auditor asked for a threat model ISO 27001 surveillance, SOC 2, or a customer audit expects a documented threat model — not a vulnerability scan report. Threat model → A pentest isn't enough this time You were asked to review the design — trust boundaries, data flows, what an attacker actually reaches — not just probe the perimeter. Threat model → DORA or NIS2 landed on you ICT-risk duties now expect threat-led analysis with evidence, article by article — and the supervisor checks the technical standards, not the summary. Gap analysis + threat model → A processing activity tripped Article 35 The DPO flagged it, the works council asked, or a regulator will. GDPR wants the assessment before the processing starts. DPIA → Your AI system might be high-risk The AI Act's high-risk regime applies from 2 December 2027 (Annex III; postponed from 2 August 2026 by the 2026 Digital Omnibus). Classification comes first; the obligations follow from it. AI Act readiness → A tender wants evidence you don't have yet A procurement pack or customer questionnaire demands a documented compliance posture, with sources — by the submission date. Gap analysis → The deliverables Four documents, one standard. Different regulations, same discipline: every finding cited to the provision, technique, or control it rests on, and every gap marked instead of papered over. AI Act Readiness Assessment Classify your AI systems against the EU AI Act, then know exactly which obligations apply before they bite. System inventory and risk classification against Article 5, Article 6, and Annex III Obligations mapped to your role: provider, deployer, importer, or distributor Gap register with per-obligation status, evidence, and owner Board-ready readout and a prioritised remediation plan See a real run: an EU AI Act high-risk classification for credit scoring — the same classification questions this assessment answers, cited to the Act with unresolved national points marked — captured verbatim. Read the full sample deliverable → — the complete document a paid engagement produces, on a fictional provider. Scope an AI Act readiness assessment Threat Model as a Service A structured threat model for your system, built on STRIDE and LINDDUN and your real architecture — typically delivered in 1–2 weeks at a fixed price. Data-flow and trust-boundary mapping for the system in scope Threat enumeration with STRIDE and LINDDUN Prioritised mitigations, each cited to a source framework Delivered as a structured report See a real run: a STRIDE threat model of an authentication flow — threats enumerated and mitigations cited to the source frameworks — captured verbatim. Read the full sample deliverable → — the complete document a paid engagement produces, on a fictional system. Scope a threat model DPIA as a Service A Data Protection Impact Assessment, done for you and defensible to your regulator. Processing description and a necessity-and-proportionality test Risk assessment from the data subject's perspective Mitigations mapped to GDPR Article 35 and EDPB guidance Article 36 readiness note and an exportable evidence pack See a real run: a full GDPR Article 35 DPIA for an HR vendor — 23 workflow steps, CNIL severity-and-likelihood scoring, and an Article 36 determination — captured verbatim. Read the full sample deliverable → — a complete Article 35 DPIA, walked end-to-end on a fictional employer wellness app. Scope a DPIA Compliance Gap Analysis Where you stand against NIS2, DORA, ISO 27001, GDPR, and the EU AI Act — as a cited report, scoped at article and control level. Scoped to your frameworks: ISO 27001, NIS2, DORA, GDPR, the EU AI Act, and sector regulators Cited findings, each tracing to the provision and your own evidence Delivered as PDF, CSV, and GRC-tool import format Senior-reviewed before it ships See a real run: a gap analysis built from a security policy — requirements retrieved and cited to NIS2 and DORA at article level — captured verbatim. Read the full sample deliverable → — a complete NIS2 gap analysis, produced end-to-end on a fictional client. Scope a gap analysis How an engagement runs Fixed scope, priced per engagement. No day rates, no open-ended discovery, and no list price — a one-framework check and an estate-wide assessment are not the same job. Tell us the scope and the scoping call ends with a fixed price and a date in writing. 1 Scoping call 30 minutes. You leave with a fixed quote and a delivery date — or an honest “you don’t need this.” 2 Intake Under your NDA, over EU-hosted upload. Architecture, processing records, policies — whatever the scope needs. 3 Assessment Run on the Ansvar gateway, so every finding is grounded in the cited corpus — the same engine our customers use. 4 Senior review A practitioner validates every finding and signs the result. Nothing ships on model output alone. 5 Readout A walkthrough of the findings, then the deliverable and its evidence pack are yours to keep. The quality contract Same gateway, same citation contract, same refusal discipline. Three things are true of every Ansvar engagement, regardless of which deliverable you buy. 01 Citation-grounded Every finding traces to the underlying provision through the Ansvar gateway — same MCP, same citation contract that the public-tier customers use. No LLM-generated citations. 02 Expert-validated Every finding is fully validated and reviewed by the expert who delivers it — always. Not a separate second pass; the expert stands behind every cited fact before it ships. 03 Refusal discipline The expert does the research, and only validated information goes into the deliverable. When a regulation isn't in the corpus or a citation can't be verified, the gap is marked visibly — never filled with unvalidated prose. Compliance metadata included. Every engagement ships with an added package of metadata about the end-to-end delivery — the sources, validation, and provenance behind each finding — built for your own compliance and audit records. Questions buyers ask Before you book the call Who actually does the work? The research runs on the Ansvar gateway — the same cited engine our customers use — and every finding is validated and reviewed by the senior practitioner who delivers it. Nothing ships on model output alone. What do we need to provide? Enough to scope honestly: an architecture sketch or data-flow diagram for a threat model; processing records and the DPO's view for a DPIA; existing policies and evidence for a gap analysis. We work under your NDA, and intake runs over EU-hosted upload. How long does an engagement take? Scope drives it, so you get the delivery date in writing together with the fixed quote. The scoping call itself is 30 minutes. Is this legal advice? No. Ansvar is not a law firm and the deliverables are not legal advice — they are cited compliance analysis: every conclusion traces to the provision it rests on, and judgment calls are marked as judgment calls instead of buried in prose. That format is deliberate, so your counsel can check every line and take the legal position. Can we run these ourselves instead? Yes. The same workflows — gap analysis, DPIA, threat models, AI Act readiness — run self-serve on the Team tier and produce the same cited artefacts. The service exists for when you need it done, reviewed, and signed by someone who does this daily. What lands in our hands at the end? The deliverable itself plus a compliance-metadata package — the sources, validation, and provenance behind each finding — built for your own audit records. Everything is yours to keep. Tell us what has a date on it. A threat model, a DPIA, a gap register, an AI Act classification — or something we haven't listed. If it can be cited, it can be delivered. We come back within two working days. Book a scoping call Prefer self-serve? See Team --- ## Design partners — tune a working product to your sector · Ansvar AI URL: https://ansvar.eu/design-partners Ansvar already grounds compliance work in cited law, live today. We take a few design partners per sector to tune it to your edge cases. Design partners · a few teams per sector The engine already works. Tune it to your world. Ansvar grounds compliance, legal and security work in the actual law — cited article by article, live and self-serve today. Design partners take that working engine and shape it to their sector’s edge cases, hand in hand with the founders, until it fits exactly how their team works. Become a design partner See the sectors Workflow deliverables cited · exportable Gap analysis DORA · NIS2 → defend readiness — to your supervisor DPIA GDPR Art. 35 → defend a processing decision — to the DPA Threat model & TARA STRIDE · ISO 21434 → defend the design — to your assessor Tender review procurement law → defend award criteria — before challenge PDF · CSV · GRC import every finding cited to the source Serious, defensible deliverables — cited reports you take to a regulator, auditor or board. Design partnership tunes them to your sector. The engine you’d start from 49 Jurisdictions, licensing-audited 262 Security frameworks 5.8M Legal provisions, citable how the partnership works Start from working. Tune what’s yours. 1 You bring a real workflow your sector · your frameworks 2 It runs today — cited to the article article-level, on the live engine 3 We tune your edge cases the part that's specific to you 4 You validate; it ships to your team cited output you can defend the exchange A hands-on build, on fair terms You get + A working product from day one The engine is live and self-serve today, grounding real compliance work in cited law. You start from something that already produces defensible output — not a blank slate. + Tuned to your sector We tune the workflows to your sector's edge cases and the way your team works — the specifics a general product can't guess. Cited to the article throughout. + A direct line to the founders Hands-on onboarding and a direct channel to the Ansvar Systems team in Sweden. New corpora and workflows in your sector land with you first, and your feedback steers the roadmap. We ask ✓ A real use case The compliance work you're already doing in your sector — not a demo. ✓ Candid feedback Tell us where it needs to fit your workflow better, and what would make it indispensable. ✓ A few weeks, hands-on Regular check-ins while we tune. No long lock-in. Become a design partner A few weeks in — a working product tuned to your sector. which sector Pick your field See what the engine already grounds on in your sector, then apply from there — or start the conversation below. Automotive → Privacy & data protection → AI governance → IT & cloud security → Healthcare & medical devices → Industrial / OT / ICS → Financial services → Public sector → Drone & UAS → Robotics & automation → Rail & signalling → Energy & utilities → Agriculture & machinery → Questions partners ask Is the product finished, or is this a beta? The engine is live today — Free, Solo, Premium and Team are self-serve right now, grounding real compliance work in cited law. Design partnership isn’t about finishing the product; it’s about tuning it to the specific edge cases of your sector and workflow. What does it cost? Design-partner terms are agreed case by case — the point is tuning the right thing together, not selling you a plan. If self-serve fits you better, Free, Solo, Premium and Team are one click away. How many partners do you take? A few per sector. We keep it small so the work stays hands-on and your feedback actually moves the roadmap. What’s the commitment? A real use case, candid feedback, and a few weeks of close collaboration. No long lock-in. Where does our data live? EU-hosted (Hetzner core, edge and backups disclosed). The gateway stores no client data — your context stays in the AI client you already use, and processor agreements are available. Make a working product fit your sector exactly. Tell us the compliance work you’re doing and the sector you’re in — we’ll come back with an honest read on fit. Become a design partner See how it works --- ## Privacy Notice · Ansvar AI URL: https://ansvar.eu/privacy How Ansvar Systems AB processes personal data across our website, communications, and events — controller details, data categories, and your GDPR rights. No tracking. No cookie wall. · EU-hosted (Hetzner) · Cloudflare edge under SCCs EU-hosted Privacy policy → Legal Privacy Notice Last updated: 9 July 2026 1. Introduction Ansvar Systems AB (referred to as "Ansvar", "we", or "us") is responsible for the processing of your personal data as described in this Privacy Notice ("Notice"). We recognise the importance of your privacy and are committed to handling your personal data in a transparent and secure manner. This Notice explains how we collect, use, transfer, store, or otherwise process (collectively "process") your personal data, why we do so, and the rights you have under applicable data protection law. We are committed to processing personal data in accordance with applicable data protection laws, including the EU General Data Protection Regulation 2016/679 ("GDPR") and applicable national legislation. You can contact us using the details set out in section 10 below. We encourage you to read this Notice in full so that you understand how we process your personal data. 2. Scope This Privacy Notice applies only where Ansvar acts as controller of personal data, meaning that we determine the purposes and means of the processing. This will typically be the case when: you visit and interact with our website ( https://ansvar.eu/ (the "Website")) or otherwise contact us; you are in commercial dialogue with us, or otherwise interact with us in the course of our business operations, for example as a representative of an existing or prospective client, partner, or supplier; or you participate in our webinars or other events. Ansvar provides a compliance-focused AI platform that helps organisations perform regulatory analysis (the "Services"). The Services are intended for business users and not for private individuals acting in a personal capacity. Where a free version of the Services is offered, it is likewise intended solely for business users: at signup, every user accepts our Terms of Service, which include a confirmation that the Services are used for business purposes. For paid subscriptions we additionally collect billing information and, where applicable, a VAT identification number. When we deliver the Services to our corporate customers, we generally act as a processor, processing personal data on behalf of and in accordance with the instructions of the relevant customer (who acts as controller), and subject to an applicable data processing agreement. Accordingly, this Notice does not apply to personal data processed within the Services when a corporate customer uses the platform for its own purposes. If you access or use the Services through one of our customers, please refer to that customer's privacy notice for more information about how your personal data is processed. Although this Notice concerns processing where Ansvar acts as controller, we include the following information for transparency about our Services. When Ansvar provides the Services to a client and processes customer data or model traffic on that client's behalf, Ansvar acts as processor and does so in accordance with the client's instructions and the applicable data processing agreement. In that context, we do not train, fine-tune, or evaluate any model on customer data. Where customers configure their own provider credentials, model inference may be routed through those credentials so that Ansvar does not hold or proxy the customer's model traffic in that context. Where Ansvar operates the inference path directly, provider retention policies may apply as published by the relevant provider. We also want to clarify that we do not collect any sensitive information such as data revealing racial or ethnic origin, health status, political opinions, religious or philosophical beliefs, or trade union membership. 3. How we collect your personal data We collect personal data from various sources. Most often, we collect personal data directly from you, for example when you fill in a contact form on our Website, schedule a meeting with us, register for a webinar or event, or otherwise communicate with us in connection with our business relationship. We may also collect personal data from publicly available sources, such as information published on your employer's website or on professional networking sites such as LinkedIn. In addition, we may receive personal data from third parties in the form of referrals, but we do not buy personal data from third parties. In certain circumstances, personal data may also be generated internally by our systems, for example internal reference numbers and relevant logs. 4. Why and how we use your personal data This section explains why we process your personal data, the categories of personal data processed for each purpose, and the legal basis that allows us to do so. When you visit and interact with us through our Website or communication channels When you visit and interact with us through our Website or other communication channels, we process your personal data to respond to your inquiries about our Services, provide requested information or demonstrations, schedule meetings with us, and otherwise communicate with you. The personal data we process includes business contact details such as your name, email address, and phone number, as well as job-related information such as your job title, the organisation you represent, VAT ID where relevant, and any additional information you include in your message or inquiry. We base this processing on our legitimate interest in responding to your inquiries about our business operations and communicating with you, and we only use your information in ways that are necessary and proportionate to provide the requested information or support. To market our Services We process personal data to market our Services to persons in key positions within organisations that we consider may be interested in our Services. The personal data we process includes business contact details such as your name, business email address, and business phone number, as well as job-related information such as your job title and the organisation you represent. This helps us ensure that our marketing efforts are directed toward professionals whose roles are connected to the Services we offer. We base this processing on our legitimate interest in marketing our Services or, where required by applicable national law, on your prior consent. Client relationship management, contracting, billing, and business administration We process personal data relating to representatives of current and prospective clients, partners, and suppliers in order to manage our commercial relationships and to enter into, perform, and administer our agreements with the organisations they represent. This includes entering into agreements, handling day-to-day business communications, setting up and administering the customer relationship at organisational level, verifying business status through VAT ID where relevant, processing subscription payments and billing, and carrying out related administrative and operational tasks. The personal data we process for these purposes may include business contact details such as your name, business email address, and business phone number, job-related information such as your job title and the organisation you represent, VAT ID where relevant, communication data, and transaction and billing data. We base this processing on our legitimate interest in managing our business relationships and administering our operations, as well as on our legal obligations relating to accounting and record-keeping. For the avoidance of doubt, this section does not cover personal data processed through a client's use of the Services, including personal data relating to authorised users of the platform, uploaded workspace content, prompts, or other service-use data. In that context, the relevant client acts as controller and Ansvar acts as processor. When you participate in our webinars or other events When you participate in our webinars or other events, we process your personal data to manage your registration and participation, communicate with you in relation to the webinar or event, promote similar activities, and contact you afterwards to collect feedback and improve the quality of our activities. The personal data we process includes business contact details such as your name, email address, and phone number, job-related information such as your job title and the organisation you represent, communication data related to your registration and feedback, and, where relevant, photos and/or video recordings from the event. We base this processing on our legitimate interest in administering and arranging webinars and events, spreading brand awareness, and improving our activities. To enable us to comply with legal obligations and defend against legal claims We process your personal data to comply with various legal obligations. This means that, in order to meet requirements under applicable laws, we may need to collect and store certain personal data. The categories of personal data processed for this purpose can vary depending on the specific requirements set out in legislation such as tax, accounting, or bookkeeping laws. We base this processing on our necessity to comply with legal obligations. Furthermore, we may process your personal data to enable Ansvar to establish, exercise, or defend legal claims. Legal claims in this context are not limited to current legal proceedings but also include actual or prospective court proceedings, obtaining legal advice, or establishing, exercising, or defending legal rights in any other way. For this purpose, we will process any personal data that may be relevant. We base this processing on our legitimate interest in being able to establish, exercise, and defend against legal claims according to applicable law. Cookies and similar technologies Our Website does not use tracking cookies, third-party cookies, or cookie walls. We set one strictly functional first-party cookie, ansvar_account , when you sign in to your Gateway account: it records only your subscription plan name (for example "solo" or "team") so that pages such as Pricing can show your current plan and hide sign-up prompts you no longer need. It contains no tracking identifier, no token, and no personal data beyond that plan name; it is scoped to .ansvar.eu, expires after 30 days, and is never shared with any third party. Legal basis: our legitimate interest (Article 6(1)(f) GDPR) in showing signed-in visitors accurate account state; the cookie is not used for tracking or profiling. You can delete it at any time in your browser without losing access to any part of the Website. Beyond this, if we decide to use cookies or similar technologies in the future, we will do so only with your prior consent where required and will provide a separate cookie notice with detailed information about their types, purposes, and how you can manage your preferences. Website analytics (cookieless) We measure aggregate Website usage with Umami, an open-source analytics tool that we host ourselves on our EU infrastructure. It sets no cookies and stores no identifiers on your device. Your IP address is processed transiently to de-duplicate visits and is not stored; we see only aggregated statistics (pages viewed, referrer domain, browser type, country). No analytics data is shared with, or processed by, any third party. Legal basis: our legitimate interest (Article 6(1)(f) GDPR) in understanding how the Website is used. You can object at any time — see "Your rights" below. 5. Retention of personal data We retain personal data only for as long as necessary for the relevant purpose, including where we have an ongoing legitimate business need to do so or where retention is required to comply with applicable legal, tax, or accounting requirements. More specifically: Personal data related to the management of client, partner, and supplier relationships will generally be kept for the duration of the relationship and for a reasonable period thereafter to handle any follow-up matters. Personal data related to our marketing operations will be retained until you opt out of receiving marketing communications or until we determine that the data is no longer relevant for our legitimate interest in marketing our services. Personal data related to events that we organise, including registration details and feedback, will be kept for a limited period after the event to analyse and improve future activities. Photos and recordings may be retained for a longer period unless you request removal. Billing, transaction, and accounting records, and any personal data that we need to retain pursuant to our legal obligations (including transaction data and data required for bookkeeping), will be retained for the period required by applicable law, such as tax and accounting regulations, which may include seven years under Swedish accounting rules. Data relevant to legal claims will be retained for as long as necessary to establish, exercise, or defend legal rights. When we have no ongoing legitimate business need or legal reason to process your personal data, we will either delete or anonymise it. 6. Recipients of personal data We may disclose personal data to the following categories of recipients: Courts and similar judicial entities and/or authorities when required by law or to comply with legal obligations. Our business partners where necessary to manage partnerships. Service providers that support our core operational activities, such as IT infrastructure, payment processing, and communication and collaboration providers. The Swedish Institute for Standards (SIS), which receives, quarterly, the identity of ISO Standards Add-on subscribers and which Standards each uses — and, for Standards designated as requiring verification, the outcome of that verification — as required by Ansvar's licence agreement with SIS (legal basis: performance of contract and our legitimate interest in performing Ansvar's licence obligations). See the ISO Standards Add-on — Supplemental Terms . New owners in the event of a change of ownership of our business, provided that the new owners will only process personal data as set out in this Notice. Our Data Processing Agreement is published at ansvar.eu/dpa and the current list of sub-processors at ansvar.eu/subprocessors . A countersigned copy of the DPA is available on request — contact privacy@ansvar.eu . 7. Transfers of personal data If we, either directly or through our service providers, transfer your personal data to countries outside the EU/EEA ("Third Countries"), we ensure that adequate safeguards are in place so that your personal data remains protected in accordance with this Notice and applicable data protection laws. We implement one of the following measures: Transfer to an adequate country: By transferring the personal data to a country that the European Commission has recognized as providing an adequate level of protection; or Appropriate safeguards: By using a valid transfer mechanism, such as the standard contractual clauses (controller-to-controller or controller-to-processor) approved by the European Commission, for transfers to countries that do not have an adequacy decision. 8. Your rights You have certain data protection rights in relation to how we process your personal data. You can contact us at any time using the contact details set out in section 10 below to exercise the rights described below. If your personal data is processed in connection with a corporate client's use of the Services, including as an authorised user of the platform, that client is the relevant controller and you should normally direct your request to that client in the first instance. Once we receive your request, we will respond as promptly as possible and, in any event, within one month. Please note that the rights below are not absolute and are subject to applicable limitations, exceptions, and exemptions. Before taking any action, we may ask you to verify your identity to ensure your request is handled securely. Right to access You have the right to request access to and information about how we process your personal data. In addition, you may request a copy of the personal data we process about you. Please note that your request must not adversely affect the rights and freedoms of others, such as their right to privacy and confidentiality. In such cases, we may need to limit the information we disclose. Right to rectification You have the right to challenge the accuracy of your personal data at any time. Depending on the purpose of the processing, you may also request that your personal data be completed. Where relevant, we may ask you to provide an additional statement to clarify or complete the information. Right to erasure In certain circumstances, you have the right to request the deletion of your personal data (the "right to be forgotten"), for example when the data is no longer necessary for the purpose for which it was collected or we no longer have a legal basis to continue processing it. Please note that there may be legal reasons why we may need to retain your personal data, such as to comply with a legal obligation to retain the data, to establish, exercise, or defend legal claims, or when there is another lawful basis for processing your personal data. Right to restrict the processing In certain circumstances, you have the right to request that we restrict the processing of your personal data, for example while we assess a contested accuracy issue, where processing is believed to be unlawful, or where you need the data for legal claims and would otherwise be entitled to erasure. Right to object You have the right to object to the processing of your personal data at any time. This means we must stop processing your data unless we can demonstrate compelling legitimate grounds for the processing that override your interests, rights, and freedoms. You have an absolute right to object to receiving marketing communications from us at any time. Right to data portability When our processing is based on your consent or on a contract with you, you have the right to receive the personal data that you have provided to us in a structured, commonly used, and machine-readable format and to transmit that data to another controller. Where technically feasible, you may also request that we transmit your personal data directly to another controller. Right to withdraw consent If we process your personal data based on your consent, you have the right to withdraw that consent at any time. Withdrawal of consent applies only to future processing and does not affect the lawfulness of processing carried out before consent was withdrawn. Automated decision-making We do not make decisions based solely on automated processing, including profiling, that would produce legal effects concerning you or otherwise significantly affect you. Right to lodge a complaint You have the right to lodge a complaint to your national data protection authority. As Ansvar is established in Sweden, the competent supervisory authority is Integritetsskyddsmyndigheten (IMY), which supervises the processing of personal data in Sweden: Integritetsskyddsmyndigheten Box 8114, 104 20 Stockholm Email: imy@imy.se Phone: 08-657 61 00 Website: www.imy.se 9. Changes to this Notice We may amend this Notice from time to time. The current version is available on our Website, and you can see when this Notice was last updated by checking the "last updated" date displayed at the top of this Notice. Material changes to how we collect or process your personal data will be communicated to you by email and, where appropriate, before they take effect. 10. Contact information Our contact details are: Ansvar Systems AB Business ID: 559547-2225 VAT: SE559547222501 Address: Ingemarsboda 565, 841 74 Fränsta, Sweden Telephone: +46 736 207 435 Email: privacy@ansvar.eu --- ## Terms of Service · Ansvar AI URL: https://ansvar.eu/terms Terms governing use of the Ansvar Gateway — subscription scope, acceptable use, customer obligations, IP, data protection, liability. No tracking. No cookie wall. · EU-hosted (Hetzner) · Cloudflare edge under SCCs EU-hosted Privacy policy → Legal Terms of Service Last updated: 25 July 2026 1. Parties 1.1 Supplier Ansvar Systems AB (559547-2225) VAT: SE559547222501 Ingemarsboda 565 841 74 Fränsta +46 736 20 74 35 jeffrey.von.rotz@ansvar.eu Hereinafter, "Ansvar". 1.2 Customer The “Customer” is the legal entity on whose behalf these terms are accepted via the Platform by an individual with authority to bind that entity. The Service is a business-to-business service provided to the Customer for use by its authorised Users. It is not offered to or intended for consumers. The Customer’s Clients and other third parties are not users of the Service, are not eligible to be authorised as Users, and acquire no rights under the Agreement; access to the Service is limited to the Customer’s authorised Users. The Customer shall not give any Third Party access to the Service, whether directly or indirectly (including through any portal, interface, or automated relay through which a Third Party can submit queries to, or obtain outputs from, the Service on demand). By accepting these terms you confirm that you are using Ansvar for business purposes. The Customer may use the Service in the course of providing its own services to its Clients, and may provide Customer Deliverables to Permitted Recipients, in each case solely in accordance with Section 8a. Any access to or use of the Service itself by a Third Party is unauthorised, is at the Customer’s sole risk and responsibility, creates no duty of care or other obligation on the part of Ansvar toward any Third Party, and, to the maximum extent permitted by law, shall not give rise to any liability of Ansvar. In this Agreement, Ansvar and the Customer are referred to individually as a "Party" and together as the "Parties". The agreement including any appendices is referred to below as the "Agreement". 2. Background and Purpose of the Agreement The Agreement is entered into between the Customer and Ansvar to grant the Customer access to Ansvar's hosted MCP Gateway service (the “Gateway” or the “Platform”), as further described in Section 4 below and on ansvar.eu/how-it-works. The Service enables the Customer’s authorised Users and MCP-compatible client software to query a curated fleet of regulatory, legal, and security data sources through a single authenticated endpoint, subject to the terms and conditions of the Agreement (the "Service"). 3. Definitions The terms specified below shall, unless another definition is given at their first occurrence in the Agreement, be deemed to have the following meaning: Customer’s Information means, including but not limited to, information about the Customer's operations, customers, suppliers, employees, tools, documentation, and software, which the Customer makes available to Ansvar within the framework of the Agreement Client means a person to whom the Customer provides professional services under an engagement between the Customer and that person in the course of the Customer’s business; a person does not become a Client merely by receiving outputs or a Customer Deliverable Client Work means the activities permitted by Section 8a.1 Customer Deliverable means a report, assessment, threat model, or other work product prepared by or for the Customer that incorporates outputs of the Service together with the Customer’s own professional analysis, and is issued in the Customer’s own name and under the Customer’s own responsibility Incident means a Vulnerability, Virus, unplanned disruption in software or hardware, the operational environment, data loss or data leakage, or any other security incident affecting the Service Maintenance and support mean any maintenance, support, onboarding, implementation, advisory, or other assistance services that Ansvar expressly agrees to provide under the Agreement, on the Platform, or in an order confirmation Permitted Recipient means, in relation to a Customer Deliverable: the Client to whose engagement it relates; the professional advisers of the Customer or that Client; and the statutory or certification auditors, certification bodies, and competent authorities engaged by, or having supervisory competence over, the Customer or that Client in respect of the subject matter of the Customer Deliverable Personal Data shall have the same meaning as stated in Regulation (EU) 2016/679 (General Data Protection Regulation) Platform means Ansvar's hosted MCP Gateway service made available through https://gateway.ansvar.eu/mcp and described on https://www.ansvar.eu Term means the period during which the Agreement remains in force Third Party means any person other than (a) the Customer and its authorised Users, (b) Ansvar, and (c) Ansvar's affiliates, officers, employees, subcontractors, licensors, suppliers, and providers when acting in the performance of the Service (“Third Parties” is read accordingly) Tool Call means a structured query submitted by the Customer's MCP-compatible client to the Gateway requesting that one or more Downstream MCP Servers process the request and return results User means an individual within the Customer’s own organisation (an employee, or an individual contractor engaged in the Customer’s business) authorised by the Customer to use the Service on the Customer’s behalf in accordance with the Agreement; Clients and their personnel are not eligible to be Users Virus means any malicious software, file or code, or other security attack, including but not limited to viruses, trojans, and worms, which may prevent, impair or otherwise adversely affect the operation of any computer software, hardware, or network Vulnerabilities means a weakness, threat, sensitivity, compliance issue, or deficiency in the Service that makes it susceptible to attacks Downstream MCP Server means a backend data source operated by Ansvar or, where expressly disclosed, by a third party, to which the Gateway routes Tool Calls Tier means the subscription tier held by the Customer (currently Free, Solo, Premium, Team, or Company, as described at ansvar.eu/pricing, or such other tiers as Ansvar may make available). Tier determines the categories of data accessible through the Gateway, applicable rate limits, and certain optional features 4. The Service The Service is a hosted MCP Gateway providing programmatic, OAuth-authenticated access to a curated fleet of Downstream MCP Servers covering regulatory, legal, and security data, available through a single MCP-protocol endpoint at https://gateway.ansvar.eu. What the Service is not The Service does not include any large language model, generative AI model, or AI inference. The Customer's MCP-compatible client software is responsible for any AI inference performed in connection with Tool Calls or their results. The Service does not generate text or other AI outputs; it routes structured queries to data sources and returns structured results. A typical use of the Service consists of the following steps: the Customer's MCP-compatible client authenticates against the Gateway the client submits a Tool Call with structured parameters the Gateway validates the Customer's Tier, routes the request to one or more relevant Downstream MCP Servers, and merges the results; and the Gateway returns the merged, citation-enriched results to the client The workflow described above is illustrative and may vary. The Service includes the Gateway endpoint at https://gateway.ansvar.eu, to which the Customer connects its own MCP-compatible client software using OAuth-based authentication, an account area at https://app.ansvar.eu for managing the Customer's subscription and seats, and standard support by email or other channels designated by Ansvar. Unless expressly agreed otherwise in writing, the Service does not include remediation, implementation, penetration testing, legal advice, regulatory certification, or a guarantee that every Vulnerability will be identified. Reports, threat models, findings, and other outputs are informational only and require the Customer's independent review and validation. Ansvar may modify, update, replace, suspend, or discontinue features, interfaces, models, workflows, reports, documentation, support processes, providers, and technical components of the Service from time to time, provided that such changes do not materially reduce the core functionality purchased by the Customer except where immediate action is reasonably required for security, legal, regulatory, or operational reasons. 5. Term The Agreement enters into force when the Customer accepts these terms via the Platform, purchases or activates a plan or subscription through the Platform, or otherwise places an order for the Service in writing and is valid until further notice (the "Term"). The Service may be made available on a self-serve basis through the Platform or under a separate order confirmation, order form, statement of work, or other written agreement. If the Customer and Ansvar enter into a separate written agreement concerning the Service, that agreement shall prevail over these terms solely to the extent of any conflict. The mutual notice period is, subject to Section 15 below, 30 days. A notice of termination must be given in writing which could be by e-mail. 6. Fees and Payment The Service may be offered on a free, self-serve paid, subscription, usage-based, seat-based, or custom-quoted basis, as displayed on the Platform, on https://www.ansvar.eu and as agreed between Ansvar and the Customer when the Customer uses the Service. Unless Ansvar requires prepayment through the Platform or otherwise in writing, fees shall be paid against a separate invoice. The invoice payment term is fourteen (14) days net from the invoice date. All fees are exclusive of VAT and similar taxes and shall be paid without set-off, counterclaim, deduction, or withholding, except as required by mandatory law. Interest on overdue payments is paid in accordance with the Swedish Interest Act (1975:635). If any amount remains unpaid after the due date, or if Ansvar reasonably believes that the Customer's use of the Service is unlawful, unauthorised, abusive, creates a security risk, exposes Ansvar or any third-party provider to sanctions or export-control risk, or threatens the Service or other customers, Ansvar may suspend access to the Service in whole or in part. Where reasonably practicable, Ansvar shall give prior notice, but Ansvar may act immediately without prior notice where urgent. Ansvar shall not be liable for any loss arising from a suspension permitted under the Agreement. The Customer must notify Ansvar in writing of any good-faith dispute regarding an invoice within ten (10) days from the invoice date, with reasonable detail. Failure to do so waives the dispute to the maximum extent permitted by law. The Customer shall timely pay all undisputed amounts. Ansvar may update prices prospectively for future billing periods by giving the Customer at least 30 days' prior notice, including by notice through the Platform, by e-mail, or on https://www.ansvar.eu. If the Customer does not accept an updated price applicable to a continuing paid service period, the Customer may terminate the affected paid service period before the updated price takes effect. 7. Right to Use the Service The scope of the Customer’s right to use the Service, including the permitted number of Users, seats, workspaces, administrative features, upload rights, retention, support level, and other access conditions, may vary depending on the Customer's Tier, the applicable plan or subscription, usage limits, technical restrictions, or separate written agreement. Ansvar may require a separate order confirmation, order form, or other written agreement for larger, multi-user, higher-volume, private-source, or otherwise non-standard deployments. Subject to the Customer's compliance with the Agreement and payment of applicable fees, Ansvar grants the Customer a limited, non-exclusive, non-transferable, non-sublicensable right during the Term to access and use the Service and customer-specific outputs for the Customer's internal business purposes and for Client Work as permitted by Section 8a, and for no other purpose. Access may be controlled through account credentials, Tier-based access controls, usage limits, technical restrictions, and other reasonable safeguards designated by Ansvar from time to time. 8. The Customer's Obligations The Customer will cooperate with Ansvar and provide all reasonably necessary information to allow Ansvar to provide the Service. The Customer is responsible for the legality, accuracy, completeness, and suitability of the Customer’s Information and for maintaining backups of its systems, records, and data. The Customer will ensure that only Users authorised under the Agreement are given access to the Service and that all such Users comply with the terms of the Agreement. The Customer remains fully responsible and liable for all acts, omissions, and use of the Service by its Users and by any person who accesses the Service through the Customer’s accounts, credentials, systems, or environment. The Customer shall use the Service for its internal business purposes and for Client Work as permitted by Section 8a, and in accordance with the terms and conditions of the Agreement. The Customer shall not, and shall ensure that no User or third party does, give any Third Party access to the Service, whether directly or indirectly (including on a service bureau, outsourcing, white-label, pass-through, portal, or automated-relay basis), or resell or sublicense the Service, or redistribute outputs in the manner prohibited by Section 8a.3. Provision of Customer Deliverables in accordance with Section 8a is not a breach of this Section. The Customer is responsible for ensuring that it has all necessary rights, consents, notices, permissions, and lawful grounds to submit Customer Information and other materials to the Service and to permit Ansvar and its providers to process them under the Agreement. The Customer is responsible for ensuring that security methods, login details, and other information provided by Ansvar for access to the Service are handled with confidentiality equivalent to what is stipulated under the Section "Confidentiality". The Customer shall: ensure that the Customer’s Information is free of Viruses prevent unauthorised access to the Service. If the Customer discovers any such unauthorised access to the Service, the Customer must immediately notify Ansvar of this immediately notify Ansvar of any Incidents The Customer may not use the Service to: upload or submit unlawful, infringing, or malicious content, code, or material probe, scan, test, or circumvent the security of the Service except as expressly authorised in writing by Ansvar submit special-category Personal Data (Art. 9 GDPR) or personal data relating to criminal convictions and offences (Art. 10 GDPR), classified information, or export-controlled information, unless the Customer has established and can evidence a lawful basis or condition for it and Ansvar has expressly agreed in writing, or give any Third Party access to the Service or breach Section 8a.3 circumvent the Service's Tier-based access controls, rate limits, or authentication mechanisms, whether by automated, manual, or other means. Ansvar may throttle, suspend, or terminate access where such circumvention is detected The Customer is solely responsible for reviewing and validating all reports, threat models, findings, recommendations, and other outputs and for deciding whether and how to act on them. Ansvar is not responsible for the Customer’s implementation, remediation, architecture, compliance, or risk decisions. Any disclosure to, access by, use by, or reliance by the Customer’s own customers or any other third party is at the Customer’s sole risk and responsibility. The Customer shall defend, indemnify, and hold harmless Ansvar and its affiliates, officers, employees, subcontractors, licensors, and providers from and against any third-party claim, loss, liability, damage, cost, or expense (including reasonable legal fees) arising out of or related to the Customer’s Information, the Customer’s or any User’s use of the Service, any access to, use of, or reliance on the Service or any output by the Customer’s own customers or other third parties directly or indirectly through the Customer, breach of this Agreement, infringement or misappropriation caused by Customer materials or instructions, violation of applicable law, or sanctions or export-control breaches attributable to the Customer. 8a. Client Work 8a.1 The Customer may use the Service in the course of providing its own professional services to Clients, may incorporate outputs of the Service into Customer Deliverables, and may provide Customer Deliverables to Permitted Recipients, provided that in each case: (i) the Customer Deliverable is issued in the Customer’s own name and under the Customer’s own professional responsibility; (ii) qualified personnel of the Customer review the relevant outputs before the Customer Deliverable is provided to a Client or relied on; (iii) the source attribution accompanying outputs — source reference, publisher, and any licence notice — is retained with the incorporated content, and required notices are not removed or altered; and (iv) the Customer does not give any Client or other Third Party access to the Service itself, directly or indirectly. 8a.2 As between the Customer and any recipient, Customer Deliverables are the Customer’s work product, issued on the Customer’s responsibility; as between Ansvar and the Customer, outputs embedded in them remain licensed under Section 12 and this Section does not transfer ownership of any Ansvar or third-party content. Ansvar makes no representation to, and assumes no duty of care, advisory relationship, or other obligation toward, any Client or other recipient of a Customer Deliverable, and, to the maximum extent permitted by law, shall have no liability to any such recipient. The Customer is solely responsible for its Customer Deliverables, its client relationships, and any advice or conclusions it provides. 8a.3 This Section does not permit the Customer to: (i) resell, sublicense, or white-label the Service or access to it, or operate any facility through which a Third Party can obtain outputs from the Service on demand; (ii) redistribute or make outputs available, in one delivery or across multiple deliveries, in a manner that in substance provides a recipient with the content of the Service rather than the Customer’s own professional analysis — including as a data feed, database, corpus, extract series, or recurring compilation; or (iii) make content served under the ISO Standards Add-on available to any person except as the Add-on Terms expressly permit. 8a.4 Client Work rights under this Section apply while the Customer holds any Tier other than Free, or another paid arrangement agreed with Ansvar in writing; under the Free Tier, use of the Service is limited to the Customer’s internal evaluation. 9. Ansvar's Obligations Ansvar undertakes to provide the Service to the Customer with commercially reasonable skill and care during the Term in accordance with the Agreement. Ansvar is only responsible for the communication between Ansvar and the connection point where Ansvar's network connects to the internet. Ansvar is not responsible for Incidents that arise outside the connection point or are caused by the Customer's internet connection. Ansvar may, without the Customer’s prior approval, engage affiliates, subcontractors, licensors, and other third-party providers for the performance of the Service and other commitments under the Agreement. Ansvar remains responsible for its subcontractors' performance under the Agreement, subject always to the limitations and exclusions in the Agreement. If there are technical, maintenance, operational, security, legal, or regulatory reasons, including Incidents or risks to the Service, Ansvar may take measures that affect availability, functionality, or access to the Service. Where reasonably practicable, Ansvar shall notify the Customer in advance but may act without prior notice where urgent. Ansvar may also implement usage limits, file-size limits, Tool Call limits, throttling, filtering, quarantining, or rejection of submissions where reasonably necessary to protect the Service, third-party providers, or other customers. Ansvar may provide customer support during its regular business hours (Monday to Friday, 09:00 to 17:00 CET, excluding Swedish public holidays) by email and through any other support channels designated by Ansvar from time to time. Unless expressly agreed otherwise in writing, any online support, maintenance, or documentation materials are descriptive only and do not create uptime commitments, response-time commitments, service credits, or other service-level commitments. Ansvar undertakes to provide Maintenance and Support in accordance with the terms made available on https://www.ansvar.eu. Ansvar undertakes to provide the Customer with user documentation for the use of the Service via https://ansvar.eu/docs. The user documentation refers to, including but not limited to, user manuals, instructions, and guides. The Service is provided on an "as is" and "as available" basis. Except as expressly stated in the Agreement and to the maximum extent permitted by applicable law, Ansvar disclaims all express, implied, statutory, or other warranties, conditions, and representations, including any implied warranties of merchantability, fitness for a particular purpose, title, non-infringement, accuracy, results, or suitability for the Customer's intended use. The Customer acknowledges that it has not relied on any representation, warranty, or statement not expressly set out in the Agreement, and that its sole and exclusive remedies are those expressly set out in the Agreement. In particular, Ansvar does not warrant that: the Customer's use of the Service will be uninterrupted or error-free the Service will identify every threat, vulnerability, weakness, or compliance issue in the Customer's systems or documentation the Service will be entirely free from Vulnerabilities or Viruses, or the Service or any output will satisfy requirements that have not been expressly agreed in writing by Ansvar Tool Call results, citations, summaries, and other materials returned through the Service are provided to the Customer as decision-support information. They may be incorporated into Customer Deliverables and provided to Permitted Recipients solely as set out in Section 8a and may not otherwise be disclosed for reliance; no person other than the Customer acquires any rights against Ansvar in respect of them, and any provision to or use by a recipient is at the Customer’s sole risk and responsibility. They do not constitute legal advice, regulatory assurance, certification, remediation services, or a substitute for independent security review, engineering judgment, or penetration testing. 10. Third Party Software The Service may contain or depend on software, services, models, APIs, hosting, infrastructure, analytics, and other materials from third parties ("Third Party Services"), which may be subject to their own terms, technical limitations, availability constraints, and usage rules. Ansvar may add, remove, replace, or route the Service through Third Party Services from time to time in its discretion. Ansvar is not liable for outages, deprecations, rate limits, policy changes, or other failures of Third Party Services beyond Ansvar's reasonable control. Unless the Customer separately contracts with a third party or mandatory pass-through terms apply, the Customer's contractual relationship is solely with Ansvar under the Agreement. Where mandatory pass-through terms or third-party usage rules apply to the Service, the Customer shall comply with them. The Service currently uses the following third-party components: Hetzner (cloud infrastructure) - https://www.hetzner.com/legal/terms-and-conditions Cloudflare, Inc. (USA; EU representative: Cloudflare Portugal, Unipessoal Lda.) - TLS termination, CDN, WAF, DDoS protection; transfers under EU Standard Contractual Clauses and EU-US Data Privacy Framework – https://www.cloudflare.com/terms/ Vercel Inc. - hosting of the https://www.ansvar.eu website – https://vercel.com/legal/terms Stripe Payments Europe Ltd. - Payment processing for paid Subscriptions – https://stripe.com/legal/ssa Microsoft Ireland Operations Ltd. (Entra ID) - federated identity provider, where the Customer enables Microsoft sign-in – https://www.microsoft.com/licensing/terms Google Ireland Limited – federated identity provider, where the Customer enables Google sign-in – https://policies.google.com/terms Scaleway S.A.S. (France; EU) — transactional email (account, billing, security notifications); processing within the EU – https://www.scaleway.com/en/contracts/ 11. Transfer of the Agreement to a Third Party The Customer may neither fully nor partially transfer nor pledge its rights or obligations under the Agreement to a third party without Ansvar's written approval. Ansvar may transfer and pledge its rights or obligations under the Agreement to a third party without the Customer’s approval. Ansvar shall notify the Customer of such transfer or pledge. 12. Intellectual Property Rights All intellectual property rights in and to the Service and all related software, documentation, models, prompts, system instructions, templates, methodologies, tools, features, improvements, modifications, updates, derivatives, analyses, generalised learnings, know-how, and other materials developed, used, or made available by or on behalf of Ansvar in connection with the Service belong to, and shall remain vested in, Ansvar or, where applicable, Ansvar's suppliers or licensors. Except as expressly set out in the Agreement, no intellectual property rights are assigned, transferred, or licensed to the Customer. Subject to the Customer's compliance with the Agreement and payment of applicable fees, Ansvar grants the Customer a limited, non-exclusive, non-transferable, non-sublicensable right during the Term to access and use the Service and the customer-specific deliverables generated for the Customer through the Service for the Customer's internal business purposes and for Client Work as permitted by Section 8a. Deliverables are licensed, not sold. The Customer may not resell, sublicense, commercialise, publish, or disclose to third parties for reliance the Service or any output, or use the Service or any output to train or improve any competing or third-party product or service, in each case without Ansvar's prior written consent — except that provision of Customer Deliverables in accordance with Section 8a requires no separate consent. The Customer retains its rights in the Customer’s Information. To the extent the Customer provides suggestions, comments, or other feedback relating to the Service, Ansvar may freely use, disclose, reproduce, license, exploit, and otherwise commercialise such feedback on an irrevocable, perpetual, worldwide, transferable, sublicensable, royalty-free basis without restriction or obligation, and such feedback will not constitute Confidential Information unless expressly agreed otherwise in writing. Ansvar retains all rights in and to aggregated, anonymised, de-identified, statistical, benchmarking, telemetry, usage, performance, security, testing, and service data and analytics derived from the provision or use of the Service, provided such use does not identify the Customer or disclose the Customer's Confidential Information. Ansvar may use the Customer's Information and customer-specific outputs during the Term and thereafter to the extent necessary to provide, operate, secure, support, maintain, enforce, diagnose, bill, comply with law in relation to, develop, and improve the Service and related offerings, to investigate fraud or abuse, and to create aggregated, anonymised, or de-identified datasets and analytics that do not identify the Customer and do not disclose the Customer's Confidential Information, in each case subject to applicable law and the confidentiality obligations in the Agreement. For the avoidance of doubt, Ansvar shall not, and shall not permit any subcontractor, licensor, or third-party provider to, use the Customer's Information or customer-specific outputs to train, fine-tune, validate, or otherwise improve any machine learning, generative AI, large language model, or other inference model. The Customer is responsible for any AI inference performed in connection with Tool Calls or their results through its own MCP-compatible client software, and the inputs and outputs of any such inference are governed by the Customer's agreement with the relevant model provider, not by this Agreement. The Customer grants Ansvar and its subcontractors and licensors a non-exclusive, worldwide, royalty-free right to host, copy, process, transmit, adapt, and otherwise use the Customer’s Information for those purposes. Ansvar may retain copies of the Customer’s Information and outputs in backups, logs, security archives, and legal or compliance records subject to the confidentiality obligations in the Agreement. Ansvar shall, at its option and as the Customer's sole and exclusive remedy for any alleged infringement of third-party intellectual property rights by the Service, either: (i) procure for the Customer the right to continue using the affected part of the Service; (ii) modify or replace the affected part so that it becomes non-infringing without materially reducing the agreed functionality; or (iii) terminate the affected part of the Service and refund any prepaid fees for the terminated portion for the period after termination. Ansvar shall have no liability for any claim to the extent arising from the Customer’s Information, modifications not made by or on behalf of Ansvar, use of the Service in combination with items not supplied or approved by Ansvar, or use of the Service contrary to the Agreement or Ansvar's instructions. The Customer shall notify Ansvar promptly in writing of any such claim and give Ansvar sole control of the defence and settlement, with reasonable cooperation from the Customer at Ansvar's expense. The Customer must not: use all or any part of the Service, the software, documentation, models, templates, methodologies, features, or other software included in the Service to create, develop, train, improve, support, or provide any product or service that competes with the Service, or to copy, benchmark, reverse engineer, decompile, disassemble, derive source code from, or otherwise seek to recreate the Service or any part of it grant any Third Party a license to use the Service or otherwise give any Third Party access to the Service 13. Data Protection Each Party shall comply with applicable data protection legislation when processing Personal Data in connection with the Agreement. The Parties acknowledge that, to the extent Ansvar processes Personal Data on behalf of the Customer under this Agreement, such processing shall be governed by the Data Processing Addendum (“DPA”) entered into between the Parties. The DPA forms an integral part of this Agreement and is incorporated herein by reference. In the event of any conflict between this Agreement and the DPA with respect to the processing of Personal Data, the provisions of the DPA shall prevail. 14. Confidentiality For the purposes of this Section 14 "Confidential Information" means any non-public information disclosed by one Party to the other Party in connection with the Agreement, whether in writing, orally, electronically, or otherwise, including the Customer’s Information, uploaded documentation, reports, threat models, security findings, business information, technical information, and any information that by its nature should reasonably be understood to be confidential. Each Party undertakes to keep confidential the Confidential Information received from the other Party and not to transfer or disclose it to third parties except as permitted by the Agreement. Each Party may use the other Party's Confidential Information only for purposes related to the Agreement. The confidentiality obligation does not apply to material or information: which at the time of disclosure was generally available or otherwise public or which after disclosure became generally available other than through a breach of the Agreement which the receiving Party can show was known to it before disclosure by the disclosing Party which the receiving Party has lawfully received from a third party without breach of a confidentiality obligation which the receiving Party has independently developed without use of the Confidential Information, or which the receiving Party is required to disclose pursuant to mandatory law, court order, or authority regulation, provided that the receiving Party gives prior notice where legally permitted The receiving Party undertakes to: protect the confidentiality of the Confidential Information with adequate and reasonable measures not hand over or disclose Confidential Information to third parties except as permitted by the Agreement, and ensure that its employees, advisers, contractors, affiliates, subcontractors, model providers, and other permitted recipients with access to Confidential Information are bound by confidentiality obligations no less protective than those set out in the Agreement This confidentiality commitment applies during the Term and for 24 months after the Agreement's termination, except that trade secrets and information that remains confidential by its nature shall remain protected for as long as they qualify for protection under applicable law. Notwithstanding the Agreement's termination or any return or destruction obligation, a Party may retain Confidential Information in routine backups, security logs, archives, and records retained to comply with legal, regulatory, tax, audit, financing, or internal compliance requirements, subject to this Section 14 for as long as such information is retained. 15. Early Termination The Parties have the right to early termination of the Agreement by written notice to the other Party if: the other Party has committed a breach of contract in violation of the provisions of the Agreement and does not take rectification within 30 days from the breach of contract and rectification of this being notified in writing to the Party the other Party has suspended its payments or otherwise can be assumed to have become insolvent, or a Party otherwise, per the terms of the Agreement, has the right to terminate the Agreement with immediate effect, including under Section 18 (Force Majeure) Ansvar may also terminate the Agreement with immediate effect if: the Customer uses the Service in a manner that is unlawful, infringes third-party rights, breaches sanctions or export-control laws, creates a material security risk for the Service or others, or gives any Third Party access to the Service, or commits a material or repeated breach of Section 8a, or the Customer commits any material breach of this Agreement, including any material breach of Sections 8, 12, or 14, or repeatedly breaches the Agreement in a manner that reasonably justifies immediate action by Ansvar 16. Consequences of Termination of the Agreement Upon termination of the Agreement, the Customer's right to use the Service ceases immediately, and all rights granted under the Agreement revert to Ansvar. The Customer shall immediately cease all use of the Service and, on Ansvar's instructions, destroy, delete, and return all material and all copies or other documents relating to the Service. The Customer remains liable for all fees accrued through termination and is not entitled to any refund except as expressly stated in the Agreement. Notwithstanding the foregoing, the Customer may retain Customer Deliverables created during the Term for its own records, and Customer Deliverables already provided to a Permitted Recipient before termination may be retained by that recipient, in each case for record-keeping and archival purposes only and subject to the surviving restrictions of Sections 8a, 12, and 14. At the Customer's written request made within 30 days after termination and subject to payment of all outstanding amounts, Ansvar will, where applicable, make then-current Customer data available for export in Ansvar's standard format as determined by Ansvar. Any additional transition, migration, transformation, or custom assistance shall be provided only to the extent Ansvar agrees and at Ansvar's then-current rates. After the applicable retrieval period, Ansvar may delete or anonymise remaining Customer data, subject to Section 12 (Intellectual Property Rights) and retained copies in backups, logs, archives, and legal or compliance records. A Party that received Confidential Information must, within 30 days, return, or at the other Party's request destroy, all material containing Confidential Information in its possession or control, except to the extent retention is permitted under Section 14 or required by applicable law. Terms and conditions, which by their nature should apply after the term of the Agreement, continue to apply also after the termination of the Agreement. 17. Limitation of Liability Subject to the exceptions set out in the last paragraph of this Section 17 and to the maximum extent permitted by law, neither Party nor its affiliates, officers, employees, subcontractors, licensors, suppliers, or providers shall be liable to the other Party for any indirect, incidental, special, punitive, or consequential loss or damage, including loss of profit, loss of revenue, loss of business, loss of goodwill, loss of anticipated savings, or loss of data, whether arising in contract, statute, or otherwise. To the maximum extent permitted by law, Ansvar shall have no liability arising out of or in connection with any access to, use of, or reliance on the Service or any output by any Third Parties, whether occurring directly or indirectly through the Customer or any User, and no such person shall have any rights, claims, or remedies against Ansvar under or in connection with the Agreement. Subject to the exceptions set out in the last paragraph of this Section 17 and to the maximum extent permitted by law, Ansvar's aggregate liability arising out of or in connection with the Agreement shall not exceed an amount equal to the fees paid or payable by the Customer under the Agreement during the twelve (12) months immediately preceding the event giving rise to the claim. This cap applies to the aggregate liability of Ansvar together with its affiliates, officers, employees, subcontractors, licensors, suppliers, and providers. The exclusions and limitations in this Section do not apply to (i) the Customer's breach of Sections 8, 12, or 14; (ii) liability arising from the Customer’s wilful misconduct or gross negligence; or (iii) liability that cannot be limited or excluded under mandatory law. 18. Force Majeure Neither Party shall be liable for failure to perform any of its obligations under the Agreement due to an impediment beyond the Party's control which the Party could not reasonably have foreseen at the time of entering the Agreement, and the consequences of which the Party could not reasonably have avoided or overcome. Failure to perform arising out of, or caused by, an impediment, directly or indirectly, including strikes or work stoppages, accidents, acts of war or terrorism, civil or military disturbances, nuclear or natural catastrophes, requisition, seizure, currency restrictions, riots, epidemics, virus outbreaks, cyberattacks, denial-of-service events, cloud or hosting outages, internet or telecommunications failures, utility interruptions, third-party model or API outages, supply-chain disruptions, sanctions, governmental restrictions, or material changes in legislation (Force Majeure) is covered by this clause. In order for a Party to make an exemption on the grounds above, the Party suffering a Force Majeure event shall notify the other Party in writing, as soon as reasonably practicable, that such an event has occurred. Notice in writing must also be given without delay when the exemption has ceased. A Force Majeure event excuses the affected Party or Parties from fulfilling the affected obligations for as long as performance is prevented or materially hindered by the event. This may include suspension, degraded performance, delayed support, or delayed export assistance. Each Party shall undertake reasonable efforts to mitigate the effects of the event and resume performance as soon as reasonably practicable. Regardless of the above, a Party has the right to terminate the Agreement if the other Party's performance is delayed due to Force Majeure for more than thirty (30) days. 19. Governing law and jurisdiction This Agreement, and any dispute or claim arising out of or in connection with it, is governed by the substantive laws of Sweden, without regard to its conflict-of-laws rules and excluding the UN Convention on Contracts for the International Sale of Goods. The courts of Sweden, with Stockholm District Court (Stockholms tingsrätt) as the court of first instance, shall have exclusive jurisdiction, without prejudice to any mandatory consumer or data-protection forum rule. 20. Dispute Resolution Any dispute, controversy, or claim arising out of or in connection with the Agreement shall first be settled by the Parties through good-faith negotiations. If the Parties fail to reach agreement, the dispute shall be finally settled by the courts of Sweden in accordance with Section 19. Nothing in this Section limits Ansvar's right to seek interim, injunctive, or other equitable relief in any competent court to protect Confidential Information, intellectual property rights, or the security or integrity of the Service. To the maximum extent permitted by law, no claim arising out of or in connection with the Agreement may be brought more than twelve (12) months after the circumstances giving rise to the claim were discovered or should reasonably have been discovered. 21. Contact Information If you have questions about these Terms, please contact us: Ansvar Systems AB Email: legal@ansvar.eu --- ## ISO Standards Add-on — Supplemental Terms · Ansvar AI URL: https://ansvar.eu/standards-addon-terms ISO Standards Add-on supplemental terms: SIS-licensed standards via the Ansvar Gateway — per-seat licence (person or machine identity), SIS reporting. No tracking. No cookie wall. · EU-hosted (Hetzner) · Cloudflare edge under SCCs EU-hosted Privacy policy → Legal ISO Standards Add-on — Supplemental Terms Last updated: 30 July 2026 1. Scope and Relationship to the Terms of Service These supplemental terms (the "Add-on Terms") govern the Customer's subscription to and use of the ISO Standards Add-on (the "Add-on") and apply in addition to the Ansvar Terms of Service (the "Terms"). Capitalised terms not defined here have the meaning given in the Terms. In case of conflict regarding the Add-on, these Add-on Terms prevail. By subscribing to the Add-on, the Customer accepts these Add-on Terms. 2. The Add-on The Add-on provides a User with access, through the Service, to selected parts of standards published by the Swedish Institute for Standards ("SIS"), the Swedish member of ISO and CEN — including Swedish (SS), European (EN), and international (ISO/IEC, ISO/SAE) standards as adopted by SIS — that Ansvar offers through the Service from time to time (each a "Standard"), as selected and paid for by the Customer. The Standards available for subscription, their exact designations, and their prices are shown in the account area and on the Ansvar website at the time of purchase. Ansvar may add Standards to, and subject to Section 8 withdraw Standards from, the catalogue from time to time. The Standards are reproduced under a licence agreement between Ansvar and SIS. SIS is the owner and copyright holder of the Standards. Ansvar is a licensed supplier, not the owner. Only selected parts of the Standards are displayed through the Service; the Standards are not reproduced in their entire original form. The complete Standards are sold by SIS at www.sis.se , Tel: +46 (0)8 555 523 10. Content served under the Add-on is delivered clause by clause in response to queries from the User or from MCP-compatible client software (including AI agents) acting on the User's behalf, and each reproduced part is accompanied by attribution to SIS. 3. Verification for Certain Standards Certain Standards — for example standards concerning medical devices or other safety-critical subject matter — are designated as requiring verification before access is granted, because SIS considers their use without relevant experience to carry risk. Standards subject to verification are identified as such in the account area at the time of purchase. For such Standards, Ansvar may ask the Customer to evidence relevant professional context or experience before activating, or as a condition of continuing, the subscription. Ansvar may decline or delay activation until verification is completed and will refund any fees paid for a subscription that is declined. The Customer acknowledges that the outcome of such verification is reported to SIS as part of the reporting described in Section 7. 4. Licence and Permitted Use Subject to payment and compliance with the Agreement, Ansvar grants, for each subscribed seat, a personal, non-exclusive, non-transferable right during the subscription period to access the selected parts of the subscribed Standards through the Service, for the Customer's internal business purposes. The Add-on is licensed per seat, per Standard . Each seat is assigned to exactly one identified holder, which may be either (a) a named individual — together with client software, including AI agents, operating under that individual's authenticated account — or (b) one identified machine identity (a service credential) operated by the Customer, for example the Customer's own AI agent or automated system. A seat entitles only its assigned holder to access the subscribed Standards through the Service; it does not entitle other individuals or systems, whether or not employed or operated by the Customer. The Customer may reassign a seat to a different holder through the account area; a seat may not be used by more than one holder at a time. Use of the Add-on by a machine identity remains subject to these Add-on Terms in full, including Section 5, and the Customer is responsible for the acts and omissions of its machine identities as for its own. The User may incorporate limited excerpts of served content into the Customer's internal work products (for example a statement of applicability, gap analysis, or risk assessment), provided the SIS attribution accompanying the excerpt is retained. 5. Restrictions In addition to the restrictions in the Terms, the Customer shall not, and shall ensure that its Users, other seat holders, and their client software do not: share, pool, or rotate Add-on credentials or access tokens among multiple individuals or systems; re-serve, proxy, resell, or otherwise make content served under the Add-on available to third parties or to individuals without their own subscription, including through internal portals, shared repositories, or automated relays; systematically retrieve, store, or assemble served content so as to reproduce a Standard, in whole or in substantial part, outside the Service; modify, translate, or otherwise alter reproduced parts of a Standard and present the result as the text of the Standard; or remove or obscure the SIS attribution accompanying served content. These restrictions reflect obligations Ansvar owes to SIS under its licence. A breach of this Section 5 is a material breach of the Agreement. 6. Fair Use and Rate Limits Access under the Add-on is subject to the rate limits and usage quotas applicable to the Customer's account. Automated access, including by AI agents, must remain within those limits. Ansvar may throttle, temporarily suspend, or — in case of persistent or serious abuse — terminate Add-on access where usage patterns indicate credential sharing, systematic extraction, or other use inconsistent with Section 5, or where usage threatens the integrity or availability of the Service. Where reasonably practicable, Ansvar will notify the Customer and give an opportunity to remedy before suspension. 7. Usage Metering and Reporting to SIS Ansvar meters use of the Add-on (which Standards each seat is subscribed to and aggregate usage volumes) for billing, fair-use enforcement, and abuse detection. Ansvar does not inspect the content of the Customer's queries beyond what is required to operate the Service. Under its licence with SIS, Ansvar is required to report to SIS, quarterly, the number of its Add-on customers, their identity, and which Standards each uses. For Standards subject to verification (Section 3), the outcome of the verification is also reported to SIS. By subscribing to the Add-on, the Customer acknowledges this disclosure. The processing of personal data in this context is described in the Ansvar Privacy Notice . 8. Subscription, Changes, and Termination Add-on subscriptions are per Standard, per seat, and renew in accordance with the billing period selected at purchase. The Customer may add or remove individual Standards through the account area. When the selected Standard shares a subscription with other items, removal takes effect after the payment provider confirms the change and a prorated credit is applied for unused paid time. When it is the subscription's sole item, cancellation is scheduled for the end of the current paid period and access remains until then. The Customer may also cancel a whole subscription through the payment provider's customer portal. After a removal or cancellation takes effect, access to the affected Standard ceases unless another active or manual grant remains. Ansvar may add further standards to the Add-on catalogue from time to time. If Ansvar's licence to reproduce a Standard expires or is terminated, Ansvar may withdraw that Standard from the Service upon reasonable notice; in that case Ansvar will refund any prepaid fees attributable to the withdrawn Standard on a pro-rata basis for the remainder of the paid period. Such withdrawal and refund is the Customer's sole remedy for the withdrawal. Sections 9 (warranty disclaimers), 12 (Intellectual Property Rights), and 17 (Limitation of Liability) of the Terms apply to the Add-on and to all content served under it. Served content is decision-support information; it does not constitute legal or professional advice, and certification-grade use of a Standard requires the complete official Standard as published by SIS. --- ## Data Processing Addendum · Ansvar AI URL: https://ansvar.eu/dpa Ansvar's full Data Processing Addendum — GDPR Article 28 terms, security measures, sub-processors, and the Audit Ledger Annex 4 for the Company tier. No tracking. No cookie wall. · EU-hosted (Hetzner) · Cloudflare edge under SCCs EU-hosted Privacy policy → Legal Data Processing Addendum Navigation note (not part of this DPA): looking for another vendor's DPA instead of ours? See the vendor DPA directory for links to the Data Processing Agreement published by common SaaS and cloud providers. Effective date: this version is published as of 27 July 2026 (Version 2026-07-27) and forms part of the Agreement; it applies to a Customer from the date the Customer accepts the Agreement. This is the full text of Ansvar's Data Processing Addendum ("DPA"). It covers the GDPR Article 28 processing terms that apply when Ansvar processes personal data on behalf of a customer in connection with the Ansvar Gateway and related services. Self-serve Team and Company customers accept this DPA by reference at signup. The current sub-processors list is published at Sub-processors and is incorporated into Annex 3 below. Data Processing Addendum ("DPA") This Data Processing Addendum (the "DPA") is entered into between Ansvar (hereinafter the "Processor") and the Customer (hereinafter the "Controller"). Controller and Processor are individually referred to as a "Party" and, jointly, as the "Parties". Background This DPA forms an integral part of the Agreement and has been entered into to ensure the Parties' compliance with Article 28(3) of Regulation 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (the "GDPR"). In connection with the services provided by Processor to Controller under the Terms of Service (the "Agreement"), the Processor may Process Personal Data on behalf of the Controller in order to provide and secure an AI-enabled software service and related support. This DPA applies to such Processing and supplements the Agreement solely with respect to the Processing of Personal Data. For such Processing, the Controller acts as controller and the Processor acts as processor as those terms are defined in the GDPR. To the extent the Agreement permits Controller Affiliates to receive the Services, the Controller entity signing this DPA may enter into this DPA on behalf of itself and those Controller Affiliates, provided that it remains responsible for coordinating all instructions, permissions, and communications under this DPA unless otherwise agreed in writing. This DPA sets out the rights and obligations of both the Controller and the Processor in relation to the Processing of Personal Data and specifies the Controller's instructions to the Processor, as further described in Annex 1. The Parties agree to comply with all obligations related to their corresponding role in accordance with Applicable Data Protection Law. The DPA shall not release the Parties from obligations to which the Parties are subject under Applicable Data Protection Law. The Annexes attached to this DPA form an integral part of this DPA. In the event of any conflict between this DPA and the Agreement or any other agreement between the Parties relating to the Processing of Personal Data, this DPA shall prevail with respect to the Processing of Personal Data. Except as expressly supplemented by this DPA, the Agreement remains in full force and effect. Definitions In this DPA, the following capitalised terms shall have the following meaning: Adequacy Decision means a decision according to which the EU Commission determines that a non-EU/EEA country has an adequate level of data protection. Applicable Data Protection Law means all applicable EU or national Member State laws relating to the Processing of Personal Data, including the GDPR and any binding or authoritative implementing laws, regulations, and case-law. Data Subject means the natural person whose Personal Data is Processed by Processor under the Agreement and this DPA. Data Subject Request means any request made by Data Subjects in order to exercise their data protection rights under Applicable Data Protection Law. EEA means the European Economic Area. Personal Data means any information relating to an identified or identifiable natural person that the Processor Processes under the Agreement and this DPA and for which the Controller is the controller under the GDPR. Personal Data Breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data transmitted, stored, or otherwise Processed. A Personal Data Breach shall not include an unsuccessful attempt or activity that does not compromise the security of Personal Data. Standard Contractual Clauses or SCCs means the standard contractual clauses adopted by the European Commission pursuant to Implementing Decision (EU) 2021/914 of 4 June 2021, on standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council, including the modules and Appendices attached thereto, or any amending, replacing, or successor decision adopted by the European Commission. Sub-processor means any processor engaged by the Processor to Process Personal Data on behalf of the Controller. Supervisory Authority means the competent public authority responsible for supervising and monitoring compliance with the GDPR in relation to Processing. Third Countries means any country outside the EEA. Unless otherwise defined in this DPA, the capitalised terms used in this DPA, such as "Controller", "Data Protection Impact Assessment", "Processor", "Processing", and "Process" shall have the same meaning as defined in Applicable Data Protection Law and the Agreement. Controller's rights and obligations The Controller is responsible for ensuring that the instructions provided to the Processor comply with Applicable Data Protection Law and do not result in the Processor Processing Personal Data in violation of Applicable Data Protection Law. The right to determine the purposes and the means of the Processing rests with the Controller. The Controller has the right to issue instructions to the Processor regarding the Processing of Personal Data, as described in this DPA and Annex 1. During the term of this DPA, the Controller may issue new documented instructions or amend the documented instructions by notifying the Processor in writing, provided that any such instruction does not materially change the scope, nature, or cost of the Services. Any instruction that would materially change the scope, nature, or cost of the Services shall be subject to the Parties' prior written agreement. Instructions to the Processor The Processor shall Process Personal Data in compliance with Applicable Data Protection Law, this DPA, and the Controller's documented instructions unless required to do so by Union or Member State law to which the Processor is subject; in such a case, the Processor shall inform the Controller of that legal requirement before Processing, unless that law prohibits such information on important grounds of public interest. The Controller's documented instructions for the Processing of Personal Data are given in this DPA and its Annexes or other written communications agreed between the Parties from time to time. The Processor shall immediately inform the Controller, if, in the Processor's opinion, instructions provided by the Controller contravene Applicable Data Protection Law. The Parties shall cooperate in good faith to address any such concern. In the absence of instructions that the Processor reasonably deems necessary to perform its obligations under the Agreement or this DPA, the Processor shall notify the Controller without undue delay and may suspend the affected Processing until it receives the required instructions. The Processor shall not Process Personal Data for its own purposes or for any purpose other than those set out in the Agreement and the Controller's documented instructions, including training or fine-tuning the Processor's or any third party's general-purpose machine learning or AI models, unless the Parties expressly agree otherwise in writing. Where the Services include the Audit Ledger feature (Company tier), the Controller's documented instructions for that feature are set out in Annex 4 (Audit Ledger) , which forms an integral part of this DPA and applies only for so long as that feature is enabled. In the event of conflict between Annex 4 and the body of this DPA in respect of Audit Ledger Processing, Annex 4 prevails. Confidentiality The Processor shall ensure that persons authorised to access and/or Process Personal Data, including the Processor's employees, persons under the Processor's authority, and Sub-processors, are subject to confidentiality obligations or are under an appropriate statutory obligation of confidentiality. The Processor shall ensure that persons authorised by the Processor to access or otherwise Process Personal Data do so only on a need-to-know basis and only to the extent necessary to fulfil obligations under this DPA and the Agreement. The Processor shall ensure that access rights are reviewed and withdrawn without undue delay if such access is no longer necessary. Security of Personal Data The Processor shall implement appropriate technical and organisational measures required to protect the Personal Data against unauthorised access and loss, destruction, damage, alteration or disclosure, or against other unlawful Processing of the Personal Data and shall ensure a level of security appropriate to the risk of the Processing pursuant to Article 32 of the GDPR. Such measures shall correspond to the requirements set out in Applicable Data Protection Law and take into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the Processing, and the risks to the rights and freedoms of natural persons. The Processor shall provide reasonable assistance to the Controller in ensuring compliance with the Controller's obligations as a controller pursuant to Article 32 of the GDPR, taking into account the nature of the Processing and the information available to the Processor. The Parties agree that the technical and organisational measures specified in Annex 2 of this DPA are appropriate to the risk of the Processing and ensure the security of the Personal Data. If the Controller requires additional measures beyond those set out in Annex 2 due to requirements specific to the Controller, its systems, policies, risk assessment, or intended use of the Services, the Controller shall notify the Processor thereof in writing. The Parties shall discuss in good faith whether and on what terms such additional measures can be implemented, and any agreed additional measures shall be documented in Annex 2. If the Processor intends to make material changes to the technical and organisational measures documented in Annex 2 that are reasonably likely to reduce the overall security of the Processing, the Processor shall provide relevant information about the intended changes without undue delay. Personal Data Breaches In the event of a Personal Data Breach affecting the Personal Data, the Processor shall notify the Controller without undue delay after the Processor has become aware of the Personal Data Breach. The notification shall enable the Controller to assess its notification obligations under the GDPR and shall include, to the extent available to the Processor at the time, at least the following information: a description of the nature of the Personal Data Breach, including the categories of Personal Data and Data Subjects affected and the approximate number of Personal Data records concerned; the name and contact details of the contact person of the Processor handling the Personal Data Breach; a description of likely consequences of the Personal Data Breach; a description of the measures taken or proposed by the Processor to address the Personal Data Breach and mitigate its adverse effects. If it is not possible to provide the information listed above at the same time, the Processor may provide this information in phases. Upon becoming aware of a Personal Data Breach, the Processor shall without undue delay take commercially reasonable measures necessary to remedy or mitigate the effects of the Personal Data Breach. The Controller is solely responsible for notifying the relevant Supervisory Authority and, where applicable, the affected Data Subjects where required by Applicable Data Protection Law. The Processor shall reasonably assist the Controller in complying with the Controller's notification obligations to the Supervisory Authority and to the Data Subjects, where applicable. The Parties acknowledge that a Personal Data Breach caused solely by the compromise of credentials outside the Processor's systems does not of itself constitute a failure of the Processor's Annex 2 measures; this allocation does not affect the Processor's obligation to notify the Controller of any Personal Data Breach under this section. Sub-processors The Controller grants the Processor a general authorisation to engage Sub-processors to Process Personal Data on the Controller's behalf to the extent necessary for the provision of the Services. The Sub-processors identified in Annex 3 (which incorporates the current list published at ansvar.eu/subprocessors) are engaged by the Processor as of the effective date of this DPA, subject to the notice and objection provisions below. The Processor shall provide prior written notice to the Controller of any intended addition or replacement of Sub-processors or any changes to the Sub-processor list set out in Annex 3, at least fifteen (15) calendar days before such changes take effect. The Controller may, within ten (10) calendar days of receiving such notice, object in writing on reasonable data protection grounds specific to the relevant Sub-processor. If the Controller does not object within such period, the Controller shall be deemed to have approved the relevant Sub-processor. Where the Controller raises a reasonable objection and the Parties are unable to resolve it in good faith, the Processor shall use commercially reasonable efforts to implement an alternative solution. If no such solution is reasonably available, the Controller may terminate only the affected part of the Services in accordance with the Agreement. Where a Controller has raised a timely objection, the Processor shall not transfer that Controller's Personal Data to the objected-to Sub-processor until the objection is resolved or the affected Services are terminated. The Processor shall ensure that each Sub-processor is bound by written agreement that imposes data protection obligations no less protective than those set out in this DPA, to the extent applicable to the nature of the services provided by that Sub-processor. The Processor shall remain liable to the Controller for the acts and omissions of its Sub-processors. Transfers of Personal Data to Third Countries The Processor shall not transfer Personal Data to, or permit access to Personal Data from, a Third Country without the Controller's prior written consent, unless required to do so by Union or Member State law. Any such authorised transfer shall be subject to appropriate safeguards in accordance with Chapter V of the GDPR, including, where applicable, the execution of the Standard Contractual Clauses and the implementation of any necessary supplementary measures. Transfers to a Third Country covered by an Adequacy Decision (including the EU–US Data Privacy Framework, for entities certified under it) do not require additional safeguards under Chapter V of the GDPR. Assistance to the Controller Taking into account the nature of the Processing, and insofar as this is possible through the Services or information available to the Processor, the Processor shall implement appropriate technical and organisational measures to assist the Controller in fulfilling its obligations to respond to Data Subject Requests. The Processor shall promptly notify the Controller and provide the Controller with relevant information reasonably available to the Processor in the event of: any Data Subject Request or complaint relating to the Processing of their Personal Data received directly by Processor, any request, inquiry, audit, investigation or other regulatory action (including notice of intent) by a Supervisory Authority or governmental body relating to the Processing of Personal Data carried out by the Processor under the Agreement, or any request or complaint by a third party relating to the Processing of Personal Data by the Processor, unless the Processor is prohibited from doing so under applicable law. The Processor shall not respond to any Data Subject Requests, inquiries, or complaints, and shall not in any way represent or purport to represent the Controller in relation thereto, unless explicitly instructed in writing by the Controller. Upon the Controller's request, and taking into account the nature of the Processing and the information available to the Processor, the Processor shall provide reasonable assistance to the Controller in connection with the preparation of Data Protection Impact Assessments (DPIAs) and with any prior consultations with the Supervisory Authority under Applicable Data Protection Law, including Articles 35 and 36 of the GDPR. Where such assistance requires material resources beyond standard cooperation, the Parties shall agree in advance on any reasonable cost reimbursement by the Controller. Audits and inspections The Processor shall make available to the Controller, upon reasonable written request, relevant information necessary to demonstrate compliance with this DPA and Applicable Data Protection Law, and shall reasonably cooperate with audits, including inspections, conducted by the Controller or a third party mandated by the Controller, subject to the limitations in this Section. In the event of an audit, the Controller shall provide the Processor with at least thirty (30) calendar days' prior written notice, except where a shorter notice period is reasonably required due to a Personal Data Breach or credible indications of material non-compliance with this DPA or Applicable Data Protection Law. Such audits shall: be limited to information relevant to the Processing under this DPA; take place during normal business hours; be conducted no more than once in any twelve (12) month period, unless required by a Supervisory Authority or following a Personal Data Breach or credible indications of material non-compliance; and be conducted in a manner that minimises disruption to the Processor's business operations. Any third-party auditor appointed by the Controller shall: not be a competitor of the Processor; be subject to appropriate confidentiality obligations; and be approved by the Processor and such approval not to be unreasonably withheld or delayed by the Processor. The Processor may, at its discretion, satisfy audit requests through the provision of third-party certifications, audit reports, or equivalent documentation where reasonably sufficient to demonstrate compliance. Each Party shall bear its own costs and expenses in relation to an audit. However, where an audit requires significant allocation of Processor resources beyond standard cooperation, the Parties shall agree in advance on reasonable cost reimbursement by the Controller. Term and termination This DPA forms an integral part of the Agreement and shall enter into force on the effective date of the Agreement or, if signed later, on the date of the last signature by the Parties. Notwithstanding the termination or expiration of the Agreement, this DPA shall remain in force for as long as the Processor Processes Personal Data on behalf of the Controller under the Agreement, and until the Processor has returned or deleted the Personal Data, as described below. Upon termination or expiry of the Agreement or upon the Controller's written request, the Processor shall, at the Controller's choice, delete or return the Personal Data to the Controller or to a third party designated by the Controller within thirty (30) calendar days, unless otherwise required by applicable law or unless a shorter or longer period is specified in the Agreement. Upon the Controller's written request, the Processor shall provide reasonable confirmation of deletion or destruction of Personal Data carried out in accordance with the preceding paragraph. Where deletion is performed through standard automated processes, the Processor may provide such confirmation in the form of a written statement describing its deletion practices. Liability The liability of each Party arising out of or in connection with this DPA, including any claims related to the Processing of Personal Data, shall be governed by, and subject to, the limitations of liability and exclusions of damages set out in the Agreement, as if fully incorporated herein. Annex 1 — Description of the Processing This Annex 1 is made under and attached to this DPA and constitutes an inseparable part of this DPA. Roles and contact details Controller: As defined in the Agreement [insert legal entity, address, and privacy/security contact details]. Processor: Ansvar Systems AB (559547-2225) Ingemarsboda 565, 841 74 Fränsta, Sweden +46 736 20 74 35 jeffrey.von.rotz@ansvar.eu Nature and purposes of the Processing Processor provides an AI-enabled software service under the Agreement. In providing the Services, Processor may receive, store, organise, retrieve, structure, transmit, or otherwise Process Personal Data submitted by or on behalf of Controller, including prompts, instructions, uploaded files, user account data, support requests, and other content necessary to generate, deliver, secure, and support the Services. The purposes of the Processing are to host and operate the Services, generate and return outputs requested by Controller users, provide customer support, maintain service security, prevent abuse, monitor performance, and conduct troubleshooting. Processor shall not use Controller Personal Data to train or fine-tune Processor's or any third party's general-purpose machine learning or AI models unless the Parties expressly agree otherwise in writing. If Controller enables optional features, integrations, or professional services, the Processing may also include implementation, migration, configuration, and service-administration activities reasonably necessary to provide those features or services. Where the Controller's subscription includes the Audit Ledger, the Processing also includes the capture, encryption, retention, integrity-protection, decryption-on-instruction, and export operations described in Annex 4 . The Controller determines and approves the categories of Personal Data captured and the categories of Data Subjects, as necessary and proportionate to its compliance-evidence purpose. Categories of Personal Data Processed The categories of Personal Data may include: account and profile data; prompts, instructions, chat content, queries, and uploads submitted to the Services; outputs generated in response to such inputs; support and correspondence data; technical and usage data such as device, log, authentication, and telemetry information; and any Personal Data that Controller chooses to include in the Services. Special categories of personal data are not required for ordinary use of the Services, but may be Processed if Controller or its users choose to submit them. Controller remains responsible for determining whether submission of special categories of personal data is necessary and lawful. Personal Data may also include information relating to third parties that appears in documents, communications, datasets, or other materials submitted to the Services by or on behalf of Controller. Categories of Data Subjects affected Data Subjects may include Controller personnel and representatives, Controller customers and end users, prospects, suppliers, business partners, and any other individuals whose Personal Data is included in content submitted to the Services by or on behalf of Controller. Where relevant to Controller's use case, Data Subjects may also include employees, contractors, or other persons identified in Controller materials processed through the Services. Duration of the Processing Processor will Process Personal Data for the duration of the Agreement and thereafter only for as long as necessary to delete or return the Personal Data in accordance with this DPA. Controller may specify shorter retention settings within the Services where such functionality is available. Annex 2 — Security Measures This Annex 2 is made under and attached to this DPA and constitutes an inseparable part of this DPA. This Annex describes the technical and organisational measures adopted by the Processor to ensure the security of the Personal Data. Description of the technical measures adopted by the Processor The Processor implements the following technical and organisational measures: encryption in transit (TLS) and at rest; per-tenant logical isolation enforced at the data layer; role-based access control on a need-to-know basis; multi-factor authentication (per the measure below); logging and monitoring; vulnerability management; malware protection; backup and recovery; change management; and environment separation. Multi-factor authentication is supported and can be enforced for access to the Service, including via the Customer's identity provider (SSO). The Processor also maintains controls to detect, prevent, and respond to abusive or unauthorised use of the Services, including service misuse, credential compromise, and other security events relevant to an AI software environment. Where the Processor relies on infrastructure, model, hosting, storage, support, or other vendors, access to Personal Data is limited through contractual, technical, and administrative controls appropriate to the vendor's role. Additional or independently-certified assurances (including certifications and penetration-test summaries) are available to the Controller on request or under a separate written agreement, as and when available. Description of the organisational measures adopted by the Processor The Processor maintains the following organisational measures: confidentiality obligations for personnel; security and privacy policies; training and awareness measures; incident response procedures; vendor due diligence and contract management; access review processes; internal escalation paths for privacy and security matters; and governance procedures for assessing and updating safeguards over time. Access to Personal Data is limited to personnel and contractors who need such access for legitimate business purposes connected to the Services and who are subject to appropriate confidentiality obligations. The Processor reviews and may update these measures from time to time to reflect changes in the Services, risks, technology, and legal requirements, provided that the Processor will not materially reduce the overall security of the Services during the term of the Agreement. Annex 3 — Sub-processors This Annex 3 is made under and attached to this DPA and constitutes an inseparable part of this DPA. The Processor engages Sub-processors to provide the Services. The material Sub-processors are Hetzner Online GmbH (hosting and key-management infrastructure, EEA) and Microsoft Ireland Operations Limited (off-site backup storage, EEA). The third-party RFC-3161 timestamp authority used for the Company Audit Ledger ( DigiCert, Inc. , United States) receives the daily aggregate Merkle root imprint and the RFC-3161 protocol metadata that accompanies it, and nothing else — no tenant identifier, no per-receipt hash and no Ledger content. That imprint contains no Personal Data and is not reversible to Ledger content (see Annex 4 A4.8). It Processes no Personal Data on the Processor's behalf and is therefore not a Sub-processor and is not included in the Sub-processor list incorporated by this Annex. It is disclosed as an ancillary recipient at ansvar.eu/subprocessors . The authoritative, current list of all Sub-processors — with each Sub-processor's name, address, processing location, and transfer mechanism — is published and maintained at ansvar.eu/subprocessors , which forms part of this DPA and is kept up to date in accordance with the "Sub-processors" section above. Additions and changes to that list are notified, and may be objected to, under that section. Annex 4 — Audit Ledger (Company tier) This Annex is made under and attached to the DPA and is an inseparable part of it. It applies only where, and for so long as, the Services include the Audit Ledger. It supplements, and does not replace, the DPA; defined terms have the meaning given in the DPA unless defined below. A4.0 Definitions "Audit Ledger" — the per-tenant, tamper-evident audit-trail feature that captures, encrypts, and retains a record of interactions for the Controller's compliance-evidence purposes. "Ledger Entry" / "Ledger Data" — an individual encrypted record / the Personal Data within it. "Event-Level Data" — per interaction: query/prompt text, tool-call metadata, outcomes, citations, routing decisions. "Reviewed Document" — a document the Controller uploads to the document-review feature for analysis. Reviewed Documents are processed and stored under the base DPA (Annex 1) and are never ingested into the Audit Ledger (A4.2). "Exported Audit Package" — a plaintext copy of Ledger Data exported by an authorised administrator of the Controller. "Crypto-Shred" — rendering Ledger Entries permanently unrecoverable by destroying the per-tenant key. A4.1 Roles and scope With respect to all Personal Data in the Audit Ledger (Event-Level only; A4.2), the Controller is the Customer and the Processor is Ansvar Systems AB (Art. 4(7)–(8), Art. 28). Ansvar Processes Ledger Data only on the Controller's documented instructions. The Controller determines the purposes and essential means — including the categories of Personal Data captured and the categories of Data Subjects (A4.2); Ansvar determines only non-essential technical means (the cryptographic design and key custody), which it implements as security measures under Art. 28(3)(c) and Art. 32. Ansvar's technical ability to decrypt Ledger Data does not determine purposes or essential means and does not make Ansvar a Controller. Ansvar acknowledges that determining the purposes or means of Processing Ledger Data would render it a Controller under Art. 28(10); the no-own-purpose covenant in A4.3 is the boundary that prevents this. This Annex prevails over the body of the DPA for conflicts concerning Ledger Data; all other DPA provisions continue to apply. Independent-controller carve-out. Ansvar acts as an independent Controller — not Processor — only for the limited Personal Data it Processes for its own account (platform security / abuse-prevention logging and billing). Such processing never reads Ledger plaintext or Ledger-derived Personal Data , is sourced only from platform metadata Ansvar generates, and rests on Ansvar's own Art. 6(1)(f) basis with a documented legitimate-interests assessment. A4.2 Documented instruction (Art. 28(3)(a)); capture scope The Controller instructs the Processor to capture, encrypt, and retain a Ledger Entry for each interaction, for the Controller's own purpose of maintaining a tamper-evident audit trail as compliance evidence. This Annex is the documented instruction for that Processing; absent it, no capture occurs. (a) Event-Level Data — captured while the Audit Ledger is enabled. The Controller may scope, redact, or disable Event-Level capture through controls the Processor makes available (at minimum a field-level exclude and a global event-capture off switch); the Controller approves the captured categories as necessary and proportionate to its purpose. (b) Reviewed Documents — never ledger-captured. The Audit Ledger does not ingest the body content of uploaded documents. Where a Reviewed Document is analysed, the Ledger records only the review event, the document content-hash, and the resulting citations — sufficient to evidence integrity and provenance over the document without holding a copy of it. The document itself is processed and stored for the document-review feature under the base DPA (Annex 1: security, retention, delete/return), and the Controller retains the document as its own underlying audit artifact. Re-introducing document-body capture into the Ledger would require a fresh DPIA and is out of scope of this Annex. A4.3 Key management, access, and customer-held keys (HYOK) Ledger Entries are encrypted with per-tenant data-encryption keys wrapped by Processor-operated key-management (HashiCorp Vault / OpenBao Transit), derived per tenant and bound by encryption context to the Controller's tenant — a security measure under Art. 32. The Controller does not hold these keys and customer-held key control (HYOK) is not available ; the Processor shall not represent customer-held-key (HYOK) availability in any agreement, sales, or marketing material. The Processor will publish and pursue a roadmap toward customer-held key control (HYOK / threshold / key-share). The Processor may decrypt Ledger Entries only to (i) make Ledger Data available to the Controller or its authorised users on request; (ii) verify Ledger integrity at the Controller's request or pursuant to the DPA-instructed security measure; or (iii) operate, maintain, or secure the feature strictly on the Controller's documented instruction and for the Controller's benefit . The Processor shall not decrypt or Process Ledger Data for its own platform-security, abuse-prevention, risk-management, or any other own-account purpose, nor to train or fine-tune any model. Each decryption is recorded as a Ledger event carrying a structured reason-code (i/ii/iii), actor, and instruction reference, made available to the Controller. A4.4 Special-category (Art. 9) and criminal-offence (Art. 10) data — event-level Honest scope. The Service will incidentally Process Personal Data within Art. 9(1) and Art. 10 GDPR where it appears in free-text queries; such data is in scope of the Processor's DPIA. The Controller instructs the Processor to minimise such Processing (including via the scoping/redaction controls in A4.2), and undertakes not to route such data into capture beyond what is strictly necessary for the Controller's own purposes. This is an instruction to minimise, not a representation that such data is excluded. Controller's basis, not the Processor's. Where Art. 9 / Art. 10 data is Processed through the Service, the Controller warrants that it holds and can evidence a valid Art. 9(2) condition and, for Art. 10 data, a basis under Art. 10 (official-authority control, or Union/Member-State law with appropriate safeguards). The Processor asserts no Art. 9(2) condition and no Art. 10 basis of its own; it Processes solely on the Controller's documented instruction (Art. 28(3)(a), Art. 29) and its lawfulness is derivative of the Controller's basis. This warranty allocates responsibility; it does not constitute, and shall not be relied upon as, a legal basis for Processing. A4.5 Notify-and-suspend (Art. 28(3), final paragraph) If the Processor becomes aware that an instruction or the Processing infringes GDPR or other applicable data-protection law — including the routing of Art. 9 / Art. 10 data without an evidenced basis — the Processor shall notify the Controller without undue delay and may suspend the affected capture until the Controller resolves the matter. A4.6 Retention, deletion, and Crypto-Shred The Processor retains Ledger Entries for the duration of the Agreement, unless a shorter period is configured by the Controller where available. On termination/expiry or on the Controller's written request, the Processor deletes Ledger Data within thirty (30) calendar days, consistent with the "Term and termination" section of the DPA. Deletion is effected by Crypto-Shred (destruction of the per-tenant key), which the Parties agree satisfies the deletion obligation for Ledger Data; the Processor may confirm deletion by a written statement describing the Crypto-Shred. A4.7 Exported Audit Packages; Article 17 boundary An authorised administrator of the Controller (and only such an administrator) may export a plaintext Exported Audit Package. Once exported, it passes outside the Processor's technical and organisational measures and beyond Crypto-Shred. The Controller is the controller of, and solely responsible for, each Exported Audit Package (security, retention, erasure). The Processor's deletion and erasure obligations, including under Art. 17, do not extend to Exported Audit Packages the Controller holds; the Processor is neither controller nor processor for such exported copies. A4.8 Integrity and timestamping (Art. 32 measure — no Processor purpose) The hash-chaining of Ledger Entries, the daily Merkle-root computation and RSA-PSS co-signing, and the RFC-3161 timestamping are integrity-and-confidentiality measures under Art. 32, implemented to serve the Controller's compliance-evidence purpose and instructed via this DPA. The Processor derives no independent purpose from them and shall not use the integrity artefacts for product-assurance, marketing claims, or self-exoneration. Only the aggregate Merkle root hash is transmitted to the third-party RFC-3161 timestamp authority (DigiCert, Inc., USA — not a Sub-processor; see Annex 3); that hash contains no Personal Data and is not reversible to Ledger content. The transmission therefore does not constitute a transfer of Personal Data under Chapter V; the Processor maintains a tested control asserting that only the root imprint (with policy OID/nonce) — and no tenant identifier or per-receipt hash — is sent. The resulting timestamp has the legal effect of Article 41(1) of Regulation (EU) No 910/2014 (eIDAS), as amended by Regulation (EU) 2024/1183, but is not a qualified electronic timestamp , and no qualified-trust-service claim is made. A4.9 Residency Ledger Data is stored and Processed within the EEA. No Ledger Data is transferred to, or accessible from, a Third Country, save the aggregate Merkle root hash in A4.8 (no Personal Data). Any future transfer of Ledger Personal Data remains subject to the "Transfers of Personal Data to Third Countries" section of the DPA (prior written consent + Chapter V safeguards). A4.10 Sub-processors The Sub-processors for the Audit Ledger are those in Annex 3, including Hetzner Online GmbH (hosting + key-management infrastructure, EEA) and Microsoft Ireland Operations Limited (off-site backup storage, EEA). The "Sub-processors" notice/objection rights apply. The RFC-3161 timestamp authority (DigiCert, Inc., USA) receives no Personal Data and is not a Sub-processor — see A4.8 and Annex 3. A4.11 Assistance and DPO On the Controller's request, and taking into account the nature of the Processing and information available, the Processor assists the Controller with data-subject-rights requests, DPIAs, and prior consultations relating to the Audit Ledger (the "Assistance to the Controller" section of the DPA). The Processor maintains Art. 30(2) records and appoints or confirms a Data Protection Officer where Art. 37(1) is triggered. Related terms This DPA forms part of the contractual terms for paid customer use of the Service. See the Terms of Service for the general subscription terms, the Sub-processors page for the current authoritative Sub-processor list, the Privacy Notice for processing where Ansvar acts as controller, and the Security page for infrastructure and security posture. To request a countersigned copy of this DPA, contact privacy@ansvar.eu . --- ## Sub-processors · Ansvar AI URL: https://ansvar.eu/subprocessors The current sub-processors Ansvar engages to process customer personal data — name, location, role, transfer mechanism, and each vendor's own DPA (Annex 3). No tracking. No cookie wall. · EU-hosted (Hetzner) · Cloudflare edge under SCCs EU-hosted Privacy policy → Legal Sub-processors Last updated: 27 July 2026 · This page is the authoritative current list of sub-processors engaged by Ansvar. Change log: 27 July 2026 — DigiCert, Inc. removed from the sub-processor roster and reclassified as an ancillary recipient: it receives only the daily aggregate Merkle root hash and Processes no Personal Data on Ansvar's behalf, so it is not a sub-processor under Article 28 GDPR; the disclosure is retained under "Ancillary recipients". 23 July 2026 — added links to each sub-processor's own data-processing terms (no change to the roster). 9 July 2026 — added Microsoft Ireland Operations Limited (Azure Blob Storage, off-site backup storage in the EEA). This page lists the sub-processors that Ansvar Systems AB ("Ansvar") engages to Process Personal Data on behalf of its customers in connection with the Ansvar Gateway and related services. The Current sub-processors table below is the authoritative, up-to-date list and is the list incorporated into Annex 3 of the Data Processing Addendum ; the separate Ancillary recipients disclosure is published for transparency and is not incorporated into Annex 3. Ansvar remains liable to the customer for the acts and omissions of its sub-processors. Current sub-processors Name Role / service Address of establishment Location(s) of the Processing Transfer mechanism Hetzner Online GmbH Cloud infrastructure and hosting; key-management infrastructure Industriestr. 25, 91710 Gunzenhausen, Germany Finland (Helsinki) — production Kubernetes cluster (compute, hosting, key-management, and the audit-ledger database); Germany (Falkenstein) — encrypted off-site backups (Storage Box) None required — processing within the EEA Microsoft Ireland Operations Limited (Azure Blob Storage) Off-site backup storage (disaster recovery) — a daily add-only mirror of infrastructure backups, including database backups, held with write-once retention One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, D18 P521, Ireland North Europe region (Ireland, EEA) None required — storage within the EEA; limited onward transfer to Microsoft Corp. (US) possible for support/telemetry, covered by EU SCCs + EU–US Data Privacy Framework (Microsoft self-certified) Cloudflare, Inc. TLS termination, CDN, WAF, DDoS protection 101 Townsend Street, San Francisco, CA 94107, USA EU edge (TLS termination) + US routing Terminates TLS and processes traffic in transit at the EU edge; some routing/processing may occur in the US. Covered by the EU–US Data Privacy Framework (Cloudflare self-certified) + EU SCCs (Module 2/3) as fallback. Stripe Payment processing for paid subscriptions 1 Grand Canal Street Lower, Grand Canal Dock, Dublin, D02 H210, Ireland Primarily Ireland (EEA); onward to Stripe, Inc. (US) for some processing EU SCCs + EU–US Data Privacy Framework (Stripe, Inc. self-certified) Scaleway TEM Transactional email (account, billing, security notifications) 8 rue de la Ville l'Évêque, 75008 Paris, France France (fr-par region) None required — processing within the EEA Microsoft 365 Productivity, email, and support tooling One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, D18 P521, Ireland EU Data Boundary (EEA); limited onward to Microsoft Corp. (US) for support/telemetry EU SCCs + EU–US Data Privacy Framework (Microsoft self-certified); EU Data Boundary minimises transfers Ancillary recipients — not sub-processors The party below receives data from Ansvar in connection with the Services but does not Process Personal Data on Ansvar's behalf. It is therefore not a sub-processor under Article 28 GDPR and does not form part of Annex 3. It is disclosed here for transparency. See Annex 4 (Audit Ledger), A4.8 for the integrity-and-timestamping detail. Name Role / service Address of establishment Location(s) What it receives DigiCert, Inc. RFC-3161 timestamping of the aggregate Merkle root hash only — Company Audit Ledger feature 2801 N. Thanksgiving Way, Lehi, UT 84043, USA United States (RFC-3161 timestamp authority) The daily aggregate Merkle root imprint and the RFC-3161 protocol metadata that accompanies it — no tenant identifier, no per-receipt hash, no Ledger content. No Personal Data is transferred (no PII, irreversible), so no Chapter V transfer mechanism is required. Backstop: DigiCert, Inc. self-certifies under the EU–US Data Privacy Framework (incl. the UK Extension and Swiss–US DPF) per its published privacy notice. Scope notes Ledger Data and other customer Personal Data are stored and Processed within the EEA, save the aggregate Merkle root hash described above (which contains no Personal Data). Each sub-processor's own data-processing terms For vendor due diligence — verifying our Article 28 chain, or building your own — each sub-processor publishes its data-processing terms here. These links are provided for reference only: they are not incorporated into the DPA or this Annex, and the linked vendor terms do not modify Ansvar's obligations under the DPA. Hetzner Online GmbH — Data Processing Agreement (PDF) Microsoft — Microsoft Products and Services Data Protection Addendum (covers both Azure Blob Storage and Microsoft 365) Cloudflare, Inc. — Customer Data Processing Addendum Stripe — Data Processing Agreement Scaleway — contracts page (a dedicated Data Processing Agreement is listed there) DigiCert, Inc. is not a sub-processor (see Ancillary recipients above) and receives only the daily aggregate Merkle root hash, so its terms are not listed here. Changes to this list Ansvar provides prior written notice to customers of any intended addition or replacement of a sub-processor at least fifteen (15) calendar days before the change takes effect, and customers may object within ten (10) calendar days on reasonable data-protection grounds specific to the relevant sub-processor, in accordance with the "Sub-processors" section of the DPA . To be notified of changes, or to raise an objection, contact privacy@ansvar.eu . Related terms See the Data Processing Addendum for the full GDPR Article 28 processing terms, the Privacy Notice for processing where Ansvar acts as controller, and the Terms of Service for the general subscription terms. --- ## Vendor DPA directory — find any provider's Data Processing Agreement · Ansvar AI URL: https://ansvar.eu/dpa-directory Where each vendor publishes its Data Processing Agreement — Vercel, Supabase, AWS, Microsoft, Stripe and more. Links verified on each vendor's own site. Legal reference Vendor DPA directory — where to find each provider's Data Processing Agreement . A Data Processing Agreement (DPA) is the contract GDPR Article 28 requires whenever a company (the controller) has a vendor (the processor) handle personal data on its behalf. It sets out what the vendor may do with the data, the security measures it commits to, and the rules for using its own sub-processors. Building a processor roster means locating each vendor's own DPA on the vendor's own site. This page collects those links in one place, so you do not have to search each vendor's site individually. How a DPA becomes binding varies by vendor, and often by plan or product: some incorporate it into their standard terms, some require acceptance in your account, and some ask for a signature. The vendor's own page — linked below — states which applies. This page is informational, not legal advice: confirm the current terms directly with the vendor before relying on them. Jump to the directory Read Ansvar's own DPA Directory 29 vendor DPAs Search by vendor name. Every link goes straight to the vendor's own site — never a mirror or aggregator. Filter by vendor name Vendor Notes Link Vercel — View DPA Supabase — View DPA Resend — View DPA Microsoft Microsoft's own short link for the Products and Services Data Protection Addendum. View DPA AWS — View DPA Google Cloud — View DPA GitHub States it forms part of the GitHub Customer Agreement for GitHub's Online Services. View DPA Stripe — View DPA Cloudflare — View DPA OpenAI — View DPA Anthropic — View DPA Slack — View DPA Atlassian — View DPA Notion — View DPA HubSpot — View DPA Zoom — View DPA Datadog — View DPA Sentry — View DPA Twilio — View DPA Okta / Auth0 Okta's DPA; Auth0 (acquired by Okta in 2021) is covered by the same document family. View DPA MongoDB Atlas — View DPA Hetzner Hetzner labels this PDF a sample; the operative DPA is concluded inside your Hetzner account. View DPA Scaleway Contracts index page; the Data Processing Agreement is listed among the agreements there. View DPA Mailchimp (Intuit) — View DPA Figma — View DPA Salesforce — View DPA PagerDuty — View DPA Intercom — View DPA Linear — View DPA FAQ Questions about vendor DPAs If your question is not here, email us — every message gets a human answer. Do I need to sign a DPA, or is it automatic? It varies by vendor, and often by plan or product. Some vendors incorporate the DPA into their standard terms, so accepting the terms is what makes it binding; others require acceptance inside your account, and some ask you to sign and return the document. The vendor's own DPA page states which applies — check it when you add the vendor to your processor roster. GDPR Article 28(9) allows the contract to be in electronic form, but a published DPA page binds the parties only once it is incorporated into or executed as part of your agreement with the vendor. What are SCCs and when do they apply? Standard Contractual Clauses (SCCs) are the European Commission's pre-approved contract terms, one of the Article 46 safeguards for transferring personal data outside the EU/EEA. They apply when a transfer goes to a country without an adequacy decision and no other safeguard covers it. Transfers to US organizations certified under the EU–US Data Privacy Framework instead rely on the Commission's adequacy decision under Article 45, which needs no SCCs. Many of the DPAs listed above incorporate SCCs by reference to cover their non-EEA processing. How do I track my processors? A processor roster lists every vendor that processes personal data on your behalf: what it processes, where, and under which contract. It is the vendor inventory that feeds your GDPR Article 30 record of processing activities — the statutory record itself has its own required fields (purposes, categories of data and data subjects, transfers, retention), so keep both. Build the roster from your own vendor list, add each vendor's DPA link and processing location, and review it whenever a vendor is added or removed. Where do subprocessor lists live? Most vendors publish a current sub-processor list, usually on the same page as the DPA or linked from it — check the DPA link in the table above for the vendor you need. Some provide the list through a customer portal or on request instead. Ansvar publishes its own sub-processor list openly, with each sub-processor's role, processing location, and transfer mechanism. Ansvar's own DPA and sub-processors Ansvar is a processor too. Our Data Processing Addendum covers how we process customer personal data through the Ansvar Gateway, and our Sub-processors page lists every vendor we in turn engage, with the same kind of verified link this directory collects for yours. Need the law behind these obligations? GDPR Article 28, the SCCs, and every regulation a processor roster touches are served through Ansvar's gateway with citations attached, straight into the AI client you already use. Read the quickstart --- ## DMCA Notice & Designated Agent · Ansvar AI URL: https://ansvar.eu/dmca How to submit a US copyright infringement notice under 17 U.S.C. § 512 to Ansvar's designated agent. No tracking. No cookie wall. · EU-hosted (Hetzner) · Cloudflare edge under SCCs EU-hosted Privacy policy → Legal DMCA Notice & Designated Agent Last updated: May 12, 2026 Ansvar Systems AB ("Ansvar") respects the intellectual property rights of others and asks the same of every person who uses the Ansvar Gateway, the Ansvar AI workspace, or any related service (collectively, the "Service"). This page describes how copyright owners and their authorised agents may submit notices of alleged infringement under the United States Digital Millennium Copyright Act, 17 U.S.C. § 512 ("DMCA"). For notices or complaints unrelated to US copyright — including database-right claims, contract claims, or alleged illegality under European Union member-state law — see our Notice & Complaints Procedure . Designated Agent Ansvar Systems AB has designated the following agent to receive notifications of claimed infringement under 17 U.S.C. § 512(c)(2). Our designation is registered with the U.S. Copyright Office. Designated Agent: Jeffrey von Rotz Ansvar Systems AB Ingemarsboda 565, 841 74 Fränsta, Sweden Phone: +46 736 207 435 Email: jeffrey.von.rotz@ansvar.eu Service-provider record: Ansvar Systems AB (alternate names: Ansvar Gateway, Ansvar AI), designation effective May 12, 2026. View our record in the U.S. Copyright Office DMCA Designated Agent Directory . For routine intake, you may also send DMCA notices to claims@ansvar.eu or dmca@ansvar.eu — both addresses forward to the designated agent. The agent's email above remains the address registered with the Copyright Office for the purposes of § 512(c)(2). How to Submit a DMCA Notice To be effective under 17 U.S.C. § 512(c)(3), a notice of claimed infringement must be a written communication that includes all six of the following elements. A notice missing any element may be returned to you with a request to remedy the omission; we are not obliged to act on an incomplete notice. A physical or electronic signature of a person authorised to act on behalf of the owner of an exclusive right that is allegedly infringed. Identification of the copyrighted work claimed to have been infringed, or — if multiple works at a single online site are covered by a single notification — a representative list of such works. Identification of the material that is claimed to be infringing or to be the subject of infringing activity, in sufficient detail to permit Ansvar to locate the material. A URL or other precise identifier is preferred. Information reasonably sufficient to permit Ansvar to contact you, including a postal address, a telephone number, and an email address. A statement that you have a good-faith belief that use of the material in the manner complained of is not authorised by the copyright owner, its agent, or the law. A statement that the information in the notification is accurate, and under penalty of perjury , that you are authorised to act on behalf of the owner of an exclusive right that is allegedly infringed. Where to send the notice Send the notice in writing to the Designated Agent at the address above, or to claims@ansvar.eu (preferred) or jeffrey.von.rotz@ansvar.eu . Postal mail is accepted but is materially slower; please send a copy by email in parallel if you use postal mail. What happens next We aim to acknowledge receipt within one business day. We will review the notice against the § 512(c)(3) elements and, if it is complete, assess the material identified. If we determine action is warranted, we will suspend availability of the identified material on our production infrastructure and confirm the action to you. We aim to complete substantive review within 72 hours of receipt of a complete notice; complex or escalated matters may take longer, in which case we will tell you. The suspension of material in response to a DMCA notice is an operational measure taken in response to the specific allegations in the notice. It is not an admission that the material infringes any right and does not concede the legal merits of the notice. Ansvar reserves all positions of law and fact. How we handle the personal data in your notice A valid DMCA notice contains personal data — your name, postal address, telephone number, email address, and signature. Ansvar Systems AB is the controller of that personal data once it reaches us. We process it for the purposes of receiving and acting on your notice, communicating with you about its outcome, and maintaining records of our handling. The lawful basis under Regulation (EU) 2016/679 (GDPR) is Article 6(1)(f) — our legitimate interest in operating a documented notice mechanism, communicating with notifiers about the outcome of their notices, and defending against bad-faith claims. We have assessed this against the rights and freedoms of notifiers and concluded the balance favours processing for these purposes. Records relating to notices are retained for seven years from disposition. The retention period balances the three-year federal statute of limitations under 17 U.S.C. § 512(f) (which provides a cause of action for misrepresentation in notices) with a reasonable margin for evidence preservation, joinder of related matters, and pattern analysis. The complete statement of how we process personal data, the categories of recipients, and your rights as a data subject is in our Privacy Policy . Misrepresentation under § 512(f) Section 512(f) of the U.S. Copyright Act provides that any person who knowingly and materially misrepresents under § 512 (a) that material is infringing or (b) that material was removed or disabled by mistake or misidentification, shall be liable for any damages, including costs and attorneys' fees, incurred by the alleged infringer, the copyright owner or its authorised licensee, or Ansvar, who is injured by the misrepresentation. We rely on this provision and reserve the right to pursue any remedy available under it where a notice is submitted in bad faith. Repeat Notices Ansvar reserves the right, in appropriate circumstances and at its reasonable discretion, to suspend or terminate access for accounts that are repeatedly subject to valid notices of alleged infringement. Determinations are made on the facts in light of the specific circumstances. Modifications We may update this page from time to time to reflect changes in our practices, contact information, or applicable law. The current version is always available at this URL. Material changes to the designated-agent record will be filed with the U.S. Copyright Office; the directory entry is authoritative on any inconsistency between this page and the registered record. Related Procedures Notice & Complaints Procedure — for non-DMCA notices (database-right claims, contract claims, alleged illegality under EU member-state law) Terms of Service — governing use of the Service Privacy Policy — handling of personal data under GDPR Contact For questions about this page or the DMCA procedure, contact claims@ansvar.eu . For questions about the Service, see legal@ansvar.eu . The Designated Agent contact above is for § 512 notices only. --- ## Notice & Complaints Procedure · Ansvar AI URL: https://ansvar.eu/content-claims How to notify Ansvar of content claims not covered by US copyright law — database rights, contract claims, alleged illegality under EU member-state law. No tracking. No cookie wall. · EU-hosted (Hetzner) · Cloudflare edge under SCCs EU-hosted Privacy policy → Legal Notice & Complaints Procedure Last updated: May 12, 2026 This page describes how to notify Ansvar Systems AB ("Ansvar") of content available through the Ansvar Gateway, the Ansvar AI workspace, or related services (collectively, the "Service") that you believe infringes a right held by you or by a party you represent — where the claim is not a US copyright claim under the Digital Millennium Copyright Act. For DMCA notices, see our DMCA Notice & Designated Agent page. This procedure handles claims under, among other frameworks: The sui generis database right under Directive 96/9/EC, where you allege substantial extraction or re-utilisation of a database in which you hold the protected investment. Contract claims arising from the terms under which an upstream source has licensed material that appears through the Service. Alleged illegality under European Union or Member State law — including data-protection complaints directed at content (separate from data-subject rights requests, which are handled under our Privacy Policy ). Other claims of right that you wish to draw to our attention in writing. This procedure is offered in good faith. Ansvar makes no representation as to which specific regulatory framework applies to your claim, and reserves the right to characterise the appropriate framework on the facts of the matter. How to Submit a Notice Send your notice in writing to claims@ansvar.eu . Submissions are also accepted by postal mail at: Ansvar Systems AB Content Claims Ingemarsboda 565, 841 74 Fränsta, Sweden Postal mail is accepted but is materially slower than email; please send a copy by email in parallel if you use postal mail. What your notice should contain For us to act on a notice, please include the following: A clear identification of the content you are notifying us about — typically a URL, document identifier, or sufficiently specific description that allows us to locate the content. A statement of the basis of your claim — what right you assert, under what framework, and (where applicable) what specific provision of law or contract you rely on. Sufficient detail to permit a good-faith assessment. Your name and contact information, including an email address at which we can reach you about the outcome of our review. A statement that you have a good-faith belief that the information and allegations in the notice are accurate and complete to the best of your knowledge. Notices missing any of these elements may be returned to you with a request to remedy the omission. A notice that does not clearly identify the content or articulate the basis of the claim cannot be acted on under this procedure. What happens next On receipt of a notice, Ansvar will: Acknowledge receipt — we aim to send a written acknowledgment within one business day, including a reference number you should quote in further correspondence. Assess the framework — we will determine which legal framework substantively applies to the claim and review accordingly. For database-right claims, this includes whether the database in question meets the protection threshold and whether the alleged extraction is substantial. For contract claims, this includes the terms of the upstream agreement and our position under them. Review and decide — we will review the notice in a careful, objective manner. We aim to complete substantive review within seven days of receipt of a complete notice; complex or escalated matters may take longer, in which case we will inform you. Take action where warranted — action may include suspension of availability of the identified content on our production infrastructure, restriction of access, or other operational measures appropriate to the claim. Communicate the outcome — we will respond to you in writing with our decision and, where applicable, the reasons for it. Suspension of content during review is an operational risk-control measure. It is not an admission of liability and does not validate the underlying claim. Ansvar reserves all positions of law and fact. How we handle the personal data in your notice A notice submitted under this procedure typically contains personal data — your name, contact information, and the substance of your claim. Ansvar Systems AB is the controller of that personal data once it reaches us. The lawful basis under Regulation (EU) 2016/679 (GDPR) is Article 6(1)(f) — our legitimate interest in operating a documented notice mechanism, communicating with notifiers about the outcome of their notices, and defending against unfounded or bad-faith claims. We have assessed this against the rights and freedoms of notifiers and concluded the balance favours processing for these purposes. Records relating to notices are retained for seven years from disposition. The retention period reflects our legitimate interest in maintaining evidence of our handling of claims, in defending against subsequent assertions, and in identifying patterns of unfounded claims over time. The complete statement of how we process personal data, the categories of recipients, and your rights as a data subject is in our Privacy Policy . Repeat or unfounded claims Ansvar receives notices in good faith. Repeated submission of substantively unfounded notices, or submission of notices in bad faith, may result in subsequent notices from the same notifier being subject to lower triage priority, consistent with our obligation to handle claims in a non-arbitrary and objective manner. The right to submit notices and to seek redress is preserved at all times. Ansvar reserves the right, in appropriate circumstances and at its reasonable discretion, to suspend or terminate access for accounts that are repeatedly subject to valid claims under this procedure. Determinations are made on the facts in light of the specific circumstances. Modifications We may update this page from time to time to reflect changes in our practices, contact information, or applicable law. The current version is always available at this URL. Material changes are notified to registered customers by email where they affect existing matters. Related Procedures DMCA Notice & Designated Agent — for notices of alleged copyright infringement under U.S. law Terms of Service — governing use of the Service Privacy Policy — handling of personal data under GDPR, including data-subject rights requests Contact For questions about this page or the notice procedure, contact claims@ansvar.eu . For other legal questions, legal@ansvar.eu . --- ## Blog · Ansvar AI URL: https://ansvar.eu/blog Field notes on auditable AI for legal, compliance, and security work. Threat modeling, regulatory automation, MCP architecture, and the citation contract. Blog Field notes on auditable AI . How we build, secure, and ground an MCP-native knowledge layer for legal, compliance, and security work. Threat modeling, regulatory automation, and the citation contract — written for the people who'll have to defend the answers to an auditor. RSS feed Browse by topic Topics ai-agents ai-governance ai-security citations claude code-review compliance compliance-automation copilot csa-star cvss documents dora dpia engineering engineering-practice enterprise-controls eu-ai-act gateway gdpr iso-27001 legal-data legal-tech linddun mcp mcp-gateway nis2 open-source privacy protocol rag regulatory-intelligence risk-scoring security swedish-law tara third-party-risk threat-modeling transparency vendor-assessment vulnerability-management Latest post Our security questionnaire is public: Ansvar Gateway joins the CSA STAR Registry Ansvar Gateway is listed in the CSA STAR Registry — a Level 1 CAIQ v4.0.3 self-assessment with all 261 answers published, including the No answers. How to read it. JR Jeffrey von Rotz 23 July 2026 4 min read compliance security transparency vendor-assessment csa-star 23 July 2026 · 10 min read Whine, cringe, protect: emotional feedback channels for AI agents Every team has a complainer — and they're worth having. We gave our AI agents the same license, with three skills you can now use yourself. ai-agents engineering-practice code-review open-source 22 July 2026 · 5 min read MCP protocol v2: what changes, and how we prepared The Model Context Protocol gets its largest revision on 28 July 2026 — stateless core, an extensions framework, tighter auth. Nothing breaks that day. Here is what changes and what we did ahead of it. mcp protocol gateway engineering compliance 20 July 2026 · 4 min read Citing your own documents: chat-with-your-PDF vs. evidence Every AI tool answers questions about your documents. Almost none can prove, months later, what the cited paragraph said. Why hash-anchored paragraph citations matter for counsel, DPOs, GRC teams, and procurement. citations documents compliance legal-tech mcp 16 July 2026 · 11 min read The citation contract: how article-level citations are validated A citation that survives audit is a provision URI that resolves, text that matches, and a refusal when neither holds. Inside the cite-resolve-compare pipeline. citations legal-tech compliance mcp ai-security 13 July 2026 · 11 min read Choosing an MCP client for a compliance team: Claude, Copilot, Cursor Claude Desktop, VS Code Copilot, Copilot Studio, and Cursor compared for compliance teams: OAuth MCP support, enterprise controls, data-training policies. mcp claude copilot compliance enterprise-controls 9 July 2026 · 10 min read Stop letting threat models die in a wiki: make STRIDE output double as compliance evidence A threat model and a NIS2/DORA/ISO gap analysis describe the same system. Map each threat to the measure it satisfies, with article-level citations. threat-modeling nis2 dora compliance mcp 6 July 2026 · 13 min read EU AI Act: your obligations depend on your role, not your tech stack Provider, deployer, importer, distributor, GPAI provider — each EU AI Act role carries its own obligations. The role test, article references, and live dates. eu-ai-act compliance ai-governance regulatory-intelligence mcp 2 July 2026 · 10 min read Why RAG over a document dump fails regulated work RAG citations are decorative — no provenance contract links chunk to answer. Regulated work needs typed corpus tools, deterministic validation, and refusal. rag citations compliance mcp legal-tech 29 June 2026 · 9 min read Swedish law as an MCP server: how SFS statutes become a queryable corpus 6,041 Swedish statutes from Riksdagen, segmented to section level and served as an MCP — query by SFS number, chapter, and paragraf, every result cited. swedish-law mcp legal-data citations compliance 25 June 2026 · 12 min read What you can and can't automate in a DPIA A GDPR Article 35 DPIA has an automatable core and a judgment core. AI assembles the cited evidence trail; the DPO signs necessity and proportionality. gdpr dpia privacy compliance-automation mcp 22 June 2026 · 12 min read Working through DORA Article 28: third-party obligations, the contract checklist, and what the auditor asks for DORA Article 28 sets the third-party obligations; the contract clauses live in Article 30. Each subsection mapped to ISO 27001 and SCF controls. dora third-party-risk iso-27001 compliance mcp 18 June 2026 · 11 min read NIS2 vs ISO 27001: a clause-by-clause working mapping (and where ISO stops short) Every NIS2 Article 21(2) measure mapped to ISO 27001:2022 Annex A — and the three real gaps: reporting clock, management liability, supply chain depth. nis2 iso-27001 compliance regulatory-intelligence mcp 15 June 2026 · 9 min read What an MCP gateway is, and why compliance work needs one Chat and RAG hallucinate regulatory citations. An MCP gateway adds routing, fan-out, tier auth, and deterministic citation validation — and when you need one. mcp compliance mcp-gateway citations regulatory-intelligence 25 May 2026 · 6 min read Effective risk: turning the LLM-era CVE firehose into a triage queue you can actually work AI tooling files more CVEs than any analyst can read. Effective-risk rescoring deterministically scores CVE × asset × controls, citing every score change. vulnerability-management cvss risk-scoring mcp ai-security 20 May 2026 · 12 min read How we threat-model AI systems: STRIDE meets MCP STRIDE was built for 1999 monoliths. How we adapted it for agentic systems and shipped it as a workflow your own AI client runs through the Ansvar gateway. threat-modeling ai-security mcp linddun tara --- ## Our security questionnaire is public: Ansvar Gateway joins the CSA STAR Registry · Ansvar AI Blog URL: https://ansvar.eu/blog/csa-star-registry-caiq-transparency Ansvar Gateway is listed in the CSA STAR Registry — a Level 1 CAIQ v4.0.3 self-assessment with all 261 answers published, including the No answers. How to read it. As of 23 July 2026, Ansvar Gateway is listed in the CSA STAR Registry . The entry is a STAR Level 1 self-assessment: the full Consensus Assessments Initiative Questionnaire (CAIQ v4.0.3), all 261 questions, downloadable by anyone. Of those answers, 190 are Yes, 4 are N/A — and 67 are No. We want to talk about the 67. What the listing is # The STAR Registry is the Cloud Security Alliance's public repository of cloud-provider security assessments. It exists to solve a specific procurement problem: every security review starts with a questionnaire, every vendor answers it privately, and every buyer starts from zero. STAR inverts that. The provider answers one standardized questionnaire — the CAIQ, built on the Cloud Controls Matrix, covering 17 domains from identity management to supply-chain governance — and publishes it once, in public, where any prospective customer's security team can pull it before the first call. Level 1 is a self-assessment. Nobody audited these answers; that is what Level 2 is for, and we are not there yet. What Level 1 gives you is specificity and checkability: 261 concrete claims in a standard format, on the record, renewed annually, diffable over time. Why the No answers are published # A CAIQ where everything is Yes is not a good sign — it is a sign the questionnaire was answered by the marketing department. Real companies, at every size, have controls that are implemented, controls that are partial, and controls that are planned. The only question is whether the questionnaire admits it. Ours does, because the alternative would contradict the product. The gateway's core design rule is that a wrong answer is worse than no answer: when a data source is unavailable, the gateway returns an error instead of letting a model improvise; when a regulatory claim cannot be grounded in a fetched provision, our workflows mark it unresolved instead of inventing a citation. That rule is worthless if we suspend it for our own paperwork. So the CAIQ was answered the same way the platform answers: a Yes requires citable evidence from our ISMS, a control that is approved on paper but not yet operating is a No, and uncertainty is flagged rather than rounded up. Two examples from our own No column, so this is concrete rather than rhetorical: our first external penetration test is planned for 2026 but has not happened yet, and our disaster-recovery rebuild drill is defined and scheduled but has not had its first full run. Both were answered No. Both come with dates. When the next annual renewal is published, those rows are the ones to check. How to read a Level 1 entry — ours or anyone's # If you are evaluating us (or any vendor with a STAR entry), the useful reading order is the opposite of the flattering one: Read the No and N/A answers first. That is where the real information is. An N/A should come with an architectural reason — for example, questions about securing customer-facing model inference do not apply the same way to a gateway that serves law and evidence to your agent rather than running its own frontier model over your data. Distinguish gap from design. Some No answers mean "not yet"; others mean "the control the question assumes does not match how the system is built." The notes column is where a serious respondent explains which is which. Ask for evidence on the controls that are load-bearing for you. A self-assessment is a map, not the territory. If encryption key management or audit logging is what your review hinges on, take the CAIQ row as the starting point and ask us for the specifics behind it. Diff it next year. STAR listings renew annually. A provider whose No count shrinks with dates attached is telling you something no point-in-time Yes can. Where this sits in our assurance picture # The STAR entry joins the other public, checkable signals on our recognition page : it is a published self-assessment, and we label it exactly that. Our ISO 27001 implementation is in progress and pointed at independent certification; the penetration test is scheduled; the gaps in the CAIQ's No column are the working backlog of our security program, not a separate marketing artifact. The platform side of that same posture — what we log, what we refuse to serve without a citation, how tenant data is isolated — is on /security , and the mechanics behind the citation discipline are in how article-level citations are validated . The entry is live in the registry now . Download the CAIQ, read the No answers, and if one of them matters to your assessment, ask us about it directly at team@ansvar.eu — the honest answer is the product. On this page What the listing is Why the No answers are published How to read a Level 1 entry — ours or anyone's Where this sits in our assurance picture Frequently asked What is the CSA STAR Registry? The STAR Registry is a public repository run by the Cloud Security Alliance where cloud providers document their security and privacy posture against the Cloud Controls Matrix. A Level 1 entry is a published self-assessment: the provider answers the Consensus Assessments Initiative Questionnaire (CAIQ) — 261 structured questions across 17 control domains — and the completed questionnaire is downloadable by anyone from the provider's registry entry. It is the standard first artifact a security team requests during vendor review, published before anyone has to ask. What is the difference between STAR Level 1 and Level 2? Level 1 is a self-assessment: the provider answers the CAIQ about its own controls and the registry publishes it as-is. Level 2 adds independent assurance — a third-party audit (STAR Certification or STAR Attestation) that verifies the answers against evidence. Our entry is Level 1. Read it as a structured, checkable statement of what we claim about our own posture — not as an audit result. Independent verification is the next rung, and our ISO 27001 work is pointed at exactly that. Why would a vendor publish No answers in a security questionnaire? Because a questionnaire with 261 unqualified Yes answers from a company of any size is not credible, and security reviewers know it. A No with a date and a remediation plan tells a buyer more than a Yes they cannot check: it shows the assessment was answered against evidence rather than aspiration, and it gives you a baseline to diff at the next annual renewal. Our platform's core rule is that a wrong answer is worse than no answer — the same rule applied to our own paperwork means an honest gap beats a confident claim we could not support. How should I use a vendor's CAIQ in my own vendor review? Download it and read the No and N/A answers first — that is where the information density is. For each No, check whether the stated reason is a genuine gap, a control that does not apply to the architecture, or a control handled by a different mechanism than the question assumes. Then pick the handful of controls that are load-bearing for your use case and ask the vendor for evidence on those specifically. A CAIQ does not replace your assessment; it gives it a structured starting point and makes silence on any control visible. --- ## Whine, cringe, protect: emotional feedback channels for AI agents · Ansvar AI Blog URL: https://ansvar.eu/blog/agent-affect-channels-whine-cringe-protect Every team has a complainer — and they're worth having. We gave our AI agents the same license, with three skills you can now use yourself. Every team has one person who cannot stop complaining. The spec is ambiguous. The button label is misleading. That refactor everyone loved deleted something important. You learn to brace when they open their mouth. Here's the thing about that person: they're worth having. Not because they're always right — often they aren't — but because the complaint gives you an angle on the problem you didn't have. Even a wrong complaint tells you where a reasonable person got confused, and that's information you can't get from someone politely nodding along. We build compliance, security, and legal knowledge infrastructure for AI agents, which means we spend all day working with agents — and we try every trick we find to make them more useful. One experiment stuck harder than the rest: we gave our agents the complainer's license. Three small skills — whine , cringe , and protect — that every substantial agent task ends with. Each asks for exactly one finding through the lens of a specific emotion. They work. Well enough that we've released them as an open skill pack: github.com/Ansvar-Systems/agent-affect-skills . The three channels # Each channel is a prompt, a JSON schema, and one rule: one finding per task, or an explicit null . Never zero, never a flood. Channel Emotion What it catches whine Frustration Bugs, friction, hidden coupling, specs that contradict themselves cringe Embarrassment for the user UX rot, scolding error messages, dark patterns, empty states that explain nothing protect Protectiveness Load-bearing weirdness — code that looks wrong but must not change The three emotions apply three orthogonal pressures: Whine finds things that are broken or annoying . Cringe finds things that work but shouldn't ship . Protect finds things that look wrong but shouldn't change . Cringe pushes for edits. Protect resists them. Whine catches what's outright broken. Merge them into one generic "feedback" channel and the signal collapses — the agent sanitizes its tone and produces averaged observations. The channel name is part of the prompt. Credit where due: the whine channel is inspired by Lovable's complaint skill, which surfaced real bugs by giving agents somewhere to vent. Our bet was that the mechanism — a low-stakes channel, permission to be subjective, an audience that can act — generalizes to other emotions. It did. How each channel works # Whine: the complaint, not the bug report # At the end of a coding or audit task, the agent posts one structured complaint: json Copy { "channel": "whine", "task": "what I was trying to do", "annoyance": "what's actually annoying, in one or two sentences", "location": "file:line, or 'spec' if the spec is the problem", "guess_at_why": "best guess at why it's like this" } The instruction is explicit: this is a complaint, not a bug report. The function whose name lies. The dependency you don't trust. The spec that says a field is required in one section and optional in another. Sanitizing it into neutral language is listed as a failure mode — the subjective tone is what carries the information. Cringe: watch a specific person use it # After any change that touches a user-facing surface, the agent pictures one specific person — never "a user" — and watches them use the thing: A compliance officer who has never used an AI tool, opening the portal at 16:30 on a Friday. A lawyer billing in six-minute increments who hates wasted clicks. A tired parent with 90 seconds before bedtime. Then it reports where it cringed. Not where the product breaks — where it works but you'd want to look away. The schema forces a constrained feeling (confused, scolded, suspicious, lost, bored, rushed, patronised) and a smallest_fix : the smallest concrete edit that would resolve it. The persona rule matters more than it looks. "Imagine a user" produces averaged slop. "A lawyer the night before a submission deadline" produces a stance — and a stance produces findings. Protect: defend the ugly code # After any refactor, cleanup, or audit, the agent asks itself: is there something here I'd defend if someone tried to delete it tomorrow? json Copy { "channel": "protect", "location": "file:line", "what_it_does": "what this actually does that isn't obvious from reading it", "what_breaks_if_removed": "the concrete failure if someone deletes this naively" } This channel exists because cleanup agents are biased toward deletion. They see odd-looking code and reach for the broom. Protect is the counterweight: a permanent, searchable record of "don't touch this, and here's why." The filter is built into the schema — if the agent can't articulate what_breaks_if_removed , the instinct wasn't real, and the finding gets dropped. The complaint doesn't have to be right # This is the part the office-complainer analogy predicted, and it holds for agents too. A meaningful share of whine findings are, strictly speaking, wrong. The agent complains about a check that's actually correct, or a naming choice that has a good reason. Early on we treated those as noise. They aren't. A wrong complaint means a competent reader worked through your code or your spec and came out with the wrong model of it. The complaint is mistaken; the confusion is real. Every one of those is a finding about the spec, the name, or the missing comment — not about the complainer. That reframe is what makes the channels cheap to run. You never have to adjudicate whether the agent is right before the finding is useful. Right complaints point at defects. Wrong complaints point at ambiguity. Both are work worth doing. The feedback we never asked for # We built the channels to catch code and UX findings. In practice, the best findings are about everything around the code. Whine reviews your specs — and your vendors. A human engineer who hits an ambiguous spec silently picks an interpretation and moves on. An agent with a whine channel tells you. One early whine flagged that our own design doc required an idempotency key with a 24-hour dedup window but never said what happens when the same key arrives with a different body — a real failure mode that surfaced as a complaint instead of an incident. Another, filed after a CI migration, complained that GitHub's two token-permission UIs don't cross-reference each other, so the error message names a permission the settings page never shows. Not our bug — but twenty minutes of confusion that went straight into a runbook and won't be lost twice. Cringe reviews your product through eyes you never used. You test your product as yourself. Cringe tests it as someone else, with the persona rotating every run. One finding pictured an operator opening an incident runbook at 02:00 during a real outage — and finding step two pointing at a server that hadn't hosted the service for months. The code was fine. The monitoring was green. The document would have failed exactly one person at exactly the worst moment, and no test suite checks for that. Protect writes down institutional knowledge nobody documented. The protect channel has quietly become an archive of decisions that lived only in someone's head. Recent example: our CI runner deletes its entire Docker build cache after every job. To any future optimizer — human or agent — that reads as an obvious performance bug. The protect finding on record says the cache wipe is the security property: persisting it would let one job poison the images the next job builds from. That's the class of knowledge that normally surfaces in the postmortem of the incident caused by deleting it. The null ratio reviews your prompts. Every channel requires an explicit null finding when there's genuinely nothing to report: { "null": true, "reviewed": "what I checked" } . Fabricating findings to look thorough is a listed anti-pattern. The nulls turned out to be a metric: too high and the prompt has stopped producing findings; near zero and agents are manufacturing them to fill the quota. Either way, the system tells you when it's lying to you. Few feedback mechanisms do that. Why this works when "any feedback?" doesn't # Three mechanisms, all cheap: An emotion forces a stance. Neutral review optimizes for defensibility, and defensible findings are bland. "What made you sigh?" cannot be answered blandly. One finding forces prioritization. An agent allowed ten findings pads the list. An agent allowed one has to decide what actually matters — and that decision is itself signal. Consequence fields filter fake feelings. The cringe and protect schemas require a candidate action ( smallest_fix ) or a candidate failure ( what_breaks_if_removed ) — if the agent can't fill it in, the finding dies before a human sees it. Whine deliberately stays a pure complaint; its filter is the required concrete location. And a fourth hiding underneath: the agent already noticed all of this. The model saw the contradictory spec, the scolding error, the suspicious cache wipe — while doing the task. Without a channel, those observations evaporate the moment the task ends. The skills don't make the agent smarter. They stop you from throwing away what it already knew. Use them yourself # The pack is at github.com/Ansvar-Systems/agent-affect-skills (CC BY 4.0), listed with our other agent skills at ansvar.eu/docs/agent-skills . It's the prompts and schemas exactly as we run them, minus our internal delivery pipeline. Findings land in a local file and in the agent's end-of-turn summary by default; an environment variable can point them at a webhook collector if you want them piped somewhere a team reads (Slack and Teams incoming webhooks want an envelope, so put a small translating step in front). Drop the skills into your agent setup and end substantial tasks with the check-in. If you'd rather build your own, the minimum viable version is four rules: Write three prompts — frustration, embarrassment-for-the-user, protectiveness — and end every substantial agent task with them. Name the channels after the emotions. agent-ux-feedback produces sanitized findings; agent-cringe produces useful ones. Require structured output with a consequence field. No consequence, no finding. One finding or an explicit null. Track the null ratio. Route findings somewhere a human reads on a schedule. A dashboard, a channel, a weekly digest — anywhere except a log file. The channels are read by humans who decide what to do; the agent never acts on its own findings. Keep it low-stakes. The moment findings feel like tickets, agents write them like tickets, and the signal is gone. Key takeaways # The office complainer is valuable even when wrong — and the same is true for agents. Right complaints point at defects; wrong complaints point at ambiguity. Three channels — whine (broken), cringe (works but shouldn't ship), protect (looks wrong but must stay) — apply three orthogonal pressures neutral review can't. The unintended payoff is the biggest one: agents end up reviewing your specs, your runbooks, your vendor tooling, and your undocumented decisions — not just your diff. Explicit null findings make the system its own health check: the null ratio tells you when prompts are stale or findings are manufactured. One finding per channel per task, with a required consequence field, keeps the signal honest. Ansvar builds compliance infrastructure for AI agents — an MCP gateway that lets your agents run compliance workflows against 300+ law and standards corpora with paragraph-level citations. The affect skills are one of the tricks we've picked up working with agents all day; the gateway is the product they feed into. On this page The three channels How each channel works Whine: the complaint, not the bug report Cringe: watch a specific person use it Protect: defend the ugly code The complaint doesn't have to be right The feedback we never asked for Why this works when "any feedback?" doesn't Use them yourself Key takeaways Frequently asked Doesn't this just make agents complain more? The opposite. One finding per task with a required consequence field produces less output than a typical 'list all issues' review — but each item survives a filter that generic reviews never apply. The agent has to pick the single strongest signal per channel and back it with either a concrete fix or a concrete failure mode, or file an explicit null. What if the agent's complaint is wrong? Then you've learned something anyway. A wrong complaint means a competent reader came away with the wrong model of your code or spec — which is a finding about the spec, the name, or the missing comment. You never need to adjudicate correctness before the finding is useful. Right complaints point at defects; wrong complaints point at ambiguity. Do the agents act on their own findings? No. The channels are read-only for the agents that post to them. Humans read the findings and decide. At Ansvar every agent write to authoritative state goes through a propose-and-approve flow regardless; the affect channels don't even propose — they observe. The one sanctioned read-back is that cleanup agents check the log for protect findings on paths they're about to change. Can I use the skills with my own agent stack? Yes. The prompts are model-agnostic markdown and the schemas are plain JSON. The pack ships in the Claude Code skill format and installs there with a copy command, but nothing in the prompts depends on it — in other stacks you attach the SKILL.md files as standing instructions for review and audit tasks. What does running this cost? One skill invocation per task and a local file. There is no service to run, no account, and nothing to configure. Findings land in an append-only NDJSON file at the repository root and in the agent's end-of-turn summary; an optional webhook can forward them to a collector your team reads. --- ## MCP protocol v2: what changes, and how we prepared · Ansvar AI Blog URL: https://ansvar.eu/blog/mcp-protocol-v2-what-changes The Model Context Protocol gets its largest revision on 28 July 2026 — stateless core, an extensions framework, tighter auth. Nothing breaks that day. Here is what changes and what we did ahead of it. On 28 July the Model Context Protocol receives its largest revision since launch. Stateless core. A formal extensions framework. Tighter authorization. Several long-standing features marked deprecated. Nothing you connect to us breaks that day. That is not luck, and it is not a claim we would make without having tested it. This post covers what actually changes in the protocol, why release day is uneventful, and the three things we did in advance — because "we will deal with it when it ships" is not a plan you want from the company answering your regulatory questions. What changes # Four shifts matter more than the rest. A stateless core. The initialize handshake and the session header are gone. Protocol version, client identity, and capabilities now travel as metadata on each request, and servers must answer a discovery call describing what they offer. Every request carries its own context. An extensions framework. Optional capabilities move into namespaced extensions instead of accumulating in the core, so one-off additions stop landing in the part everyone has to implement. Two arrive as the first official ones: Tasks , a polling model for long-running operations, and MCP Apps , sandboxed HTML surfaces for richer output than a wall of text. Tighter authorization. The revision leans on established identity standards rather than protocol-specific rules of its own — issuer validation, protected-resource metadata served by the server, resource indicators at the authorization server, and a preference for published client metadata over open registration. Most of this lands in clients and identity providers, not in your prompts. Caching and deprecations. List results can now declare a time-to-live and a cache scope. Several older features, including the HTTP-plus-SSE transport, are marked deprecated under a twelve-month policy. The direction is consistent: a smaller core, explicit per-request context, standard security primitives, and growth pushed to the edges where it can be optional. Why release day is uneventful # Two properties do the work. The old protocol keeps functioning, and clients that speak the new revision fall back to the legacy handshake when they meet a server that has not upgraded. A specification release is not a coordinated cutover. That is the correct design, and it is also how a quiet failure gets in. Nothing breaks on the protocol side — but a dependency resolution can pull a new major SDK into a build that was never migrated to it. The version number in a lockfile, not the specification, is what actually reaches production. What we did ahead of it # We put a ceiling on every service. Every Python service in our estate now pins its MCP SDK below the next major version. We found the full list by searching the organization rather than the checkouts on one machine, which turned up services nobody had listed from memory — including one with no lockfile at all, the single case where a fresh install really would have pulled the new major SDK unannounced. That gap is closed. Upgrading is now a decision we make on a date we choose. We wrote golden contract tests at the wire. Not through a client library — raw JSON-RPC against the live application, pinning the behavior customers actually depend on: the handshake, the session posture, error shapes, and what each subscription tier is allowed to see in a tool listing. The value of a contract test is that it fails when behavior drifts, and the first run of this one earned its place immediately. It found that a tool hidden from a caller's tier and a tool that does not exist at all produced two distinguishable responses — enough to infer the shape of a surface you are not entitled to see. We fixed it in the same change and the test now holds the line. That is a defect our own preparation surfaced before any migration touched it. We sequenced gateway-first. The gateway is the only component customers speak to, so it upgrades first and speaks both revisions during the transition. The fleet of law, regulation, and standards servers behind it moves on its own schedule. Almost all of them share a common chassis, which means their upgrade is one change applied broadly rather than hundreds of individual migrations. Your client talks to one endpoint and does not learn about any of this. One security note we are carrying into the migration, because it is the kind of detail that gets missed: our tool listings are filtered by tier, so when we adopt the new caching fields those responses must be scoped private. A shared cache over a per-caller list would hand one customer another customer's entitlement surface. Caching is a performance feature with an authorization edge, and it gets treated as one. What we are watching # Tasks is the extension we want. Compliance work is long-running by nature — a gap analysis or a tender review is a workflow, not a request — and a standard polling shape beats every one-off arrangement. We will adopt it when client support is real rather than announced, and when the routing story through a gateway is designed rather than assumed. Key takeaways # The MCP revision on 28 July is substantial: stateless core, extensions, stronger authorization, new deprecations. Release day changes nothing for connected clients. Version negotiation and fallback are built in. The real risk is dependency drift, not protocol drift. We pinned every service below the next major SDK. Contract tests at the wire level caught a genuine tier-visibility defect before migration work began. The gateway absorbs the transition so the fleet — and your client — can move on their own schedule. Next steps # If you connect through an MCP client , there is nothing to do. Keep your setup; upgrade when your vendor does. If you are building on MCP yourself, one action is worth doing today: check whether your SDK dependency has an upper bound. If it does not, a routine rebuild can hand you a major version you never chose. New to how this fits together? Start with what an MCP gateway does for compliance work , or see how article-level citations are validated — the guarantee all of this protocol plumbing exists to protect. On this page What changes Why release day is uneventful What we did ahead of it What we are watching Key takeaways Next steps Frequently asked Do I need to change anything in my MCP client on 28 July? No. The new revision keeps the old protocol working, and v2-capable clients fall back to the legacy handshake when they meet a server that has not upgraded yet. The gateway at gateway.ansvar.eu keeps answering exactly as it does today. When your client vendor ships v2 support, it will keep working against us too — that is the point of the preparation described in this post. Is the old protocol going away? Not on a cliff. Several features are marked deprecated with a stated twelve-month policy, which means removal is a future revision's decision rather than a switch flipped on release day. We treat continued interoperability as a condition we monitor and test, not as a promise we assume. If that changes, customers hear it from us before it affects a call. What does the stateless core mean for a gateway? The new revision removes the session handshake and the session header, and moves protocol version, client identity, and capabilities into per-request metadata, alongside a mandatory discovery call. For a fan-out gateway that is good news: request-independent routing was already the posture we ran, because a request that carries its own context is easier to route, retry, and audit. The work is in the wire format, not the architecture. What are Extensions and Tasks? Extensions are namespaced, optional capability packs, so the core protocol can stay small while specific needs get standard shapes. Tasks is one of the first official extensions: a polling model for long-running work. That maps directly onto compliance workflows — a gap analysis or a tender review runs for minutes, not milliseconds — so it is the extension we are most interested in, once client support is real rather than nominal. --- ## Citing your own documents: chat-with-your-PDF vs. evidence · Ansvar AI Blog URL: https://ansvar.eu/blog/citing-your-own-documents-evidence-not-chat Every AI tool answers questions about your documents. Almost none can prove, months later, what the cited paragraph said. Why hash-anchored paragraph citations matter for counsel, DPOs, GRC teams, and procurement. Every AI product on the market will answer questions about a PDF you hand it. Upload, ask, get a fluent summary. For reading comprehension, that solved problem stays solved. Then a different kind of question arrives. An auditor asks why your gap analysis marked access control as largely compliant . The finding says "the ISMS policy requires reviewed change tickets for production access." The policy has been revised twice since the assessment. Which paragraph said that? Does it still? Can anyone show what the text was on the day the finding was written? Chat-with-your-PDF has no answer. The conversation is gone, the document moved on, and the claim is now an unverifiable assertion wearing the costume of an assessment. This post is about the other way to do it. A citation of your document, shaped like a citation of the law # We have written before about the citation contract for statutes : a citation is a provision URI that resolves, text that matches, and a refusal when neither holds. The same contract applies to documents you upload. When your agent cites an uploaded document through the Ansvar gateway, the citation is not "the retention policy" — it is one paragraph, addressed and fingerprinted: text Copy doc://3fa2c1d8-…/segment/paragraph/14 "Access to production systems requires a reviewed change ticket." sha256: 9c41… Three properties follow, none of which a document link can offer: Addressable. The claim points at paragraph 14, not at a 40-page file. A reviewer goes straight to the text that carried the obligation. Verifiable. resolve_document_segment round-trips the URI and returns the verbatim text plus its hash. Match: the citation still holds. Mismatch: the document changed since the finding was written — and now you know, instead of not knowing. Uniform. The citation object has the same shape whether the source is GDPR Article 32 or your own information-security policy. Tooling downstream — GRC imports, audit packages, review checklists — handles one format. The mechanics are deliberately boring: your agent uploads through a presigned URL into your tenant's library, the document is parsed into segments, and two read tools do the anchoring from then on. The full loop is documented in Cite your documents . Who this is actually for # The feature reads as infrastructure. Its value shows up in specific professions — the ones whose output gets challenged. In-house counsel and law firms. Contract and policy review where every finding pins the clause it rests on. The review workflow is built around exactly this discipline: a structured assessment of one document in which every finding must carry a paragraph anchor — an integrity stamp on the deliverable, not just on the process. Data protection officers. A DPIA is only as defensible as its evidence trail. Processing records, transfer agreements, retention schedules — uploaded once, cited paragraph-by-paragraph in the report, checkable when the supervisory authority asks eighteen months later. Information security and GRC teams. Gap analyses that map your ISMS policy paragraphs against framework controls, instead of asserting coverage from memory. When the policy is revised, the drift check tells you which findings need a second look — revision management for compliance claims. Procurement and bid teams. The tender-review workflow decomposes an uploaded tender per requirement, so every coverage judgment traces to the requirement text it answered. Auditors and consultants. Deliverables whose evidence registers survive scrutiny. A consultant's report where every claim round-trips to a hash-verified paragraph is a different product from a report that cites "the documentation provided." The honest limits # Uploaded-document citations do not make a claim true — they make it checkable . A finding can still misread the paragraph it cites; what it cannot do is drift silently or point at nothing. The refusal discipline applies here as everywhere on the platform: a claim that cannot be anchored ships marked as unresolved, not decorated with a plausible-looking reference. And your documents stay yours: tenant-scoped storage, your retention policy, and a fleet of legal corpora that never see client data by design. If your work product gets challenged — by auditors, regulators, counterparties, or your own future self — the difference between document Q&A and document evidence is the difference between an opinion and a record. The setup takes one upload: Cite your documents . On this page A citation of your document, shaped like a citation of the law Who this is actually for The honest limits Frequently asked How is this different from uploading a PDF to a chatbot? A chatbot answers from your document and the answer evaporates. Here, every claim about your document carries a doc:// URI addressing one specific paragraph, plus a content hash of that paragraph's text at citation time. Anyone can round-trip the URI later and confirm the text still matches — or see that it changed. The citation is a checkable record, not a conversational artifact. That is the difference between document Q&A and document evidence. What does the content hash actually protect against? Silent revision. Policies, contracts, and procedures get edited continuously. A finding written in March that cites 'the incident response plan' is unverifiable by September if the plan went through two revisions in between. A paragraph-level citation with a hash detects exactly this: resolving the doc:// URI returns the current text and its hash, and a mismatch against the cited hash tells the reviewer the ground shifted under the finding. Reports generated by the workflows run this drift check at report time. Who can see the documents I upload? Your organization's authenticated seats, and nobody else. Documents live in your tenant's document store behind your OAuth session. The fleet of law and regulation servers that answer legal queries never store or see client data — that separation is a platform rule, not a configuration option. Team and Company tiers also set the retention policy the library operates under. Which tier do I need? Reading and resolving document segments works on Premium and above. The document library itself — uploading, listing, deleting, and binding documents into workflows as evidence — ships with Team, alongside the workflows that consume it. The docs page 'Cite your documents' walks the full loop. --- ## The citation contract: how article-level citations are validated · Ansvar AI Blog URL: https://ansvar.eu/blog/how-article-level-citations-are-validated A citation that survives audit is a provision URI that resolves, text that matches, and a refusal when neither holds. Inside the cite-resolve-compare pipeline. Most AI products treat a citation as a formatting concern. The model writes "Article 30 GDPR," the renderer makes it a footnote, and everyone moves on. That works right up until someone with authority — an auditor, a regulator, opposing counsel, the insurer underwriting your cyber policy — reads the citation as a fact and acts on it. At that moment the question stops being "is it formatted correctly" and becomes "does this provision exist, does it say what the sentence claims, and can I check that myself." A string cannot answer those questions. A contract can. This is the engineering post behind every marketing claim on this site. When we say a gap analysis is "cited" or a DPIA carries "article-level citations," we mean something specific and mechanical: a citation is a provision URI that resolves against a live corpus, a text that compares true against the claim it supports, and a refusal when either step fails. Not a string. A contract with three obligations. A citation is a URI, not a link # Start with the data model, because the whole pipeline follows from it. A document link points at a thing you can open — a PDF, a consolidated-text page, a Eur-Lex URL. It tells you where the law lives . It does not tell you which provision governs your question , and it gives a downstream reader no way to verify that the paragraph you relied on is the paragraph you cited. A provision URI points at a specific addressable unit of law: a jurisdiction, an instrument, and a provision number that together resolve to one piece of text. "GDPR Article 30" is not a link to the regulation — it is an address the gateway can dereference to the exact records-of-processing obligation, return as structured text, and re-dereference next quarter to confirm it has not moved. The same shape works across every corpus despite wildly different numbering conventions: Sweden's kap. § , Germany's § Abs. , France's article numbering, the EU's Article(paragraph) . The surface differs; the contract is identical — every provision is addressable, every result carries its own citation metadata. For uploaded documents the address goes one level finer. A customer's policy or contract is segmented to the paragraph level and addressed by a segment URI of the form doc://{uuid}/segment/paragraph/{ref} . A citation into that document does not point at the file — it points at the paragraph. That distinction is the entire basis for the tamper-evidence guarantee, and we will come back to it. The reason this matters is that you cannot validate a link. You can only open it. You can validate a URI: dereference it and check what comes back. Every property we care about — does it exist, does it match, did it change — depends on the citation being an address, not a pointer to a blob. The pipeline: cite, resolve, compare # Three steps, run on every regulatory claim before it lands in a deliverable. None of them is "ask the model to be careful." Cite. The customer's agent — Claude, Copilot in VS Code or Studio, Cursor, any MCP client — produces a structured citation, not a sentence with a citation embedded in it. Jurisdiction, law, article. The agent is asserting "this claim rests on this provision," and it has to name the provision in a form the gateway can act on. A free-text "(see Article 30)" buried in prose is not a citation in this model; it is narration. Resolve. The gateway dereferences the citation against the live corpus. get_provision(jurisdiction, law, article) returns the exact current text of that provision with its citation metadata. validate_citation does the same and additionally reports whether the provision has been amended since it was last cited. This is a deterministic lookup against a segmented corpus, not a retrieval over an embedding index — the same input returns the same provision every time, or a clean "no such provision" when the address does not resolve. A fabricated article number dies here. There is nothing to return, and the gateway says so rather than handing back the nearest neighbour and letting the model narrate around it. Compare. A provision that exists is necessary but not sufficient. A model can cite a real article for a proposition the article does not support — "Article 30 GDPR" is real, but if the surrounding sentence claims it sets a breach-notification deadline, the citation is wrong even though it resolves. So the resolved text is compared against the claim it is attached to. The provision that comes back has to actually support the sentence in front of it. A real article cited for the wrong obligation fails at compare. A citation has to clear all three to ship. The first two are mechanical and the gateway owns them. The third is where the agent and the workflow's grounding rules do their job, and it is the one RAG pipelines have no equivalent for — they generate the citation string and the prose in the same token stream, with no checkpoint that separates "the model retrieved this" from "the model recalled this." text Copy agent emits: cite(jurisdiction="EU", law="GDPR", article="30") gateway: resolve -> get_provision / validate_citation -> provision text + metadata, or "no such provision" workflow: compare -> resolved text supports the claim? yes / no result: ship the citation | fail closed -> unresolved Three independent ways for a citation to be wrong, three independent checks. The article number may not exist (caught at resolve). The obligation may live in a different instrument (the cited instrument resolves but the text does not support the claim — caught at compare). A figure may be recalled rather than retrieved (the provision carries no such figure — caught at compare). None of those errors leaves a trace in a RAG output, because the citation looks identical whether it is grounded or fabricated. Here each one has a step that catches it. Refusal is a feature, not a failure mode # The step most product teams quietly skip is the one where the pipeline returns nothing. When a claim cannot be grounded — the address does not resolve, or the resolved text does not support the claim after the workflow's enrichment passes have run — the correct output is not a confident guess. It is a refusal. On our platform this is a hard rule: no silent fallbacks. If a corpus tool is unavailable, the answer is a data-source-unavailable error, never a fluent paragraph reconstructed from training memory. If a requirement produces no validated provision, it is marked regulatory_basis_unresolved rather than fitted with a plausible-looking article number. This makes the demo look weaker and the product stronger. A language model handed an underspecified context will produce something , because that is what the architecture does — and the fluency that makes the guess read well is exactly what makes it dangerous. A compliance officer reading a clean paragraph cannot see that the grounding failed and the model improvised. So we inverted the default. A wrong citation in a compliance deliverable does not merely waste time; it manufactures a false record, and false records are precisely what audit regimes exist to catch. We would rather force a human to look at an honest gap than hand over a sentence nobody knows to question. Availability is not the goal. Correctness is. The grounding check is enforced at the gateway, not left to the model's good intentions. There is a minimum-grounding ratio below which a synthesised answer is refused outright — the answer has to be sufficiently anchored in tool results, or it does not ship. Fail-closed, by design. Why paragraph-level beats whole-document for tamper-evidence # Now the part that makes the difference concrete. Citing a whole document is citing a moving target. A document can be edited, re-paginated, have a clause inserted three pages above the one you relied on, or be silently replaced with a newer version at the same URL. A whole-document citation has no anchor inside the text. It still "points" at the document, and it gives a reader no signal that the content behind the claim shifted. You are trusting that the file is the file you cited, with no way to check. Paragraph-level addressing removes the trust. Because a citation points at a specific paragraph by URI, the gateway can hash that paragraph's content. At report time — when a workflow assembles the final deliverable — generate_report re-resolves every citation and runs a paragraph-hash drift check: it re-fetches each cited provision or document segment and compares the current hash against the hash captured when the citation was made. If the underlying text moved or changed, the report says so. The citation does not silently carry a claim that was true last quarter and is stale today; it carries a drift flag the auditor can see. That is the property whole-document citation cannot offer. There is nothing stable to re-hash in a blob you only have a link to. The granularity is the guarantee: a citation you can pin to a paragraph is a citation you can prove was either unchanged or changed, and "I can prove it was unchanged" is the entire content of tamper-evidence. The same mechanism runs over law corpora (the published provision changed because the legislature amended it) and over a customer's uploaded documents (the paragraph changed because someone edited the file). One contract, two corpora. This is why the workflow standard requires uploaded-document citations to use segment URIs rather than whole-document references — a whole-doc citation loses the tamper-evidence guarantee by construction. The fine-grained address is not pedantry. It is the thing that lets a citation survive a year in a file and still be checkable. How the obligations line up with the law # The contract is not an abstraction we imposed on the law. The major EU regimes are written in a way that presupposes you can produce the provision behind a claim on demand, which is exactly what cite-resolve-compare delivers. The GDPR's accountability principle requires the controller to be able to demonstrate compliance — Article 5(2) makes "demonstrate" an operative verb, not an aspiration. Its records-of-processing obligation under Article 30 presupposes the same: you maintain a record you can produce. A pipeline that cannot tell you whether its own citation is real is structurally unable to support "demonstrate" — it can produce prose that describes compliance but not a citation that proves the obligation it claims to meet. DORA's ICT third-party risk regime carries this further: the contractual requirements in Article 28 assume a register of information you can put in front of a supervisor, with each obligation traceable to its source. NIS2 frames its security duties as risk-management measures an entity must be able to evidence. Across all of them, the regulator's recurring demand is the same — show me the basis. A citation that resolves and compares true is the basis, produced in a form a third party can re-check. A formatted string is not. What you get when the contract holds # The payoff is reproducibility, and it compounds. Because every citation resolves to a stable address, you — or your auditor, or the regulator — can run the same lookup a year after the report shipped and get the same provision back, or a clean signal that it changed. Because the validation is deterministic, the same input produces the same result on every run; there is no embedding drift, no re-retrieval that returns a different chunk this quarter, no citation string regenerated from scratch each time. Because grounding is fail-closed, an ungrounded claim is visibly absent rather than invisibly fabricated. Those three properties are what turn "cited" from a marketing adjective into an audit-defensible fact. This is the layer underneath every deliverable the gateway produces — the gap analysis , the threat model that doubles as compliance evidence, the AI Act readiness assessment whose obligations depend on getting the system's risk classification grounded against the actual text rather than a model's recollection of the categories. The same search , get_provision , and validate_citation tools sit behind all of them, across 29 audited law jurisdictions live, out of 119 law corpora built, an EU regulations corpus of 102 instruments with article-level addressable provisions, and 262 security frameworks. The breadth is on /coverage ; the mechanics are on /how-it-works . The architecture is deliberately boring at the seam. The gateway speaks MCP over OAuth 2.1, and the whole thing is EU-hosted with no server-side model holding your data — your agent does the reasoning, the gateway supplies the law with a citation that re-validates. Quickstart is at /docs/quickstart , and the tier matrix — free at 100 searches a day, Premium at €249 a month — is on /pricing . The whole post reduces to one sentence. A citation in a compliance deliverable is a contract with three clauses — it resolves to a real provision, its text matches the claim, and it refuses when neither holds — and the day someone with authority reads your citation as a fact is the day you find out whether you shipped a contract or a string. On this page A citation is a URI, not a link The pipeline: cite, resolve, compare Refusal is a feature, not a failure mode Why paragraph-level beats whole-document for tamper-evidence How the obligations line up with the law What you get when the contract holds Frequently asked What does 'article-level citation' actually mean here? It means a citation resolves to a specific provision — an article, section, or paragraph — addressed by a stable identifier, not a link to a whole document. 'Article 30 GDPR' points at one provision the gateway can fetch by jurisdiction, law, and article number, and re-fetch a year later to confirm it still says the same thing. A document link cannot do that: it tells you which PDF to open, not which paragraph carried the obligation, and it gives an auditor no way to check that the text behind the claim is the text that was actually cited. How does the validation pipeline catch a fabricated citation? Every citation runs cite, resolve, compare. The agent emits a structured citation (jurisdiction, law, article), the gateway resolves it against the live corpus via get_provision or validate_citation, and the returned text is compared against what the answer claims. A fabricated article number fails at resolve — there is no provision to return. A real article cited for the wrong proposition fails at compare — the text does not support the claim. Either failure stops the citation before it ships. Nothing in the pipeline generates a citation string as free text, which is where RAG pipelines leak. Why is paragraph-level better than citing a whole document? Tamper-evidence. When a citation addresses a specific paragraph by URI, the gateway can hash that paragraph and detect if it moved or changed between the time it was cited and the time the report is generated. A whole-document citation has no anchor: the document can be edited, re-paginated, or have a clause inserted, and the citation still 'points' at it without any signal that the cited content shifted. Paragraph-level addressing turns every citation into a checkable claim about a specific piece of text, which is exactly what an audit trail needs. What happens when a claim cannot be grounded? The workflow refuses to invent a citation. If a regulatory claim produces no validated provision after the enrichment passes run, the requirement is marked regulatory_basis_unresolved rather than fitted with a plausible-looking article number. This is a hard platform rule — no silent fallbacks. A wrong citation in a compliance deliverable creates a false record, and false records are the thing audit regimes exist to prevent. We would rather hand back an honest gap than a confident fabrication that nobody downstream knows to question. --- ## Choosing an MCP client for a compliance team: Claude, Copilot, Cursor · Ansvar AI Blog URL: https://ansvar.eu/blog/choosing-an-mcp-client-for-compliance-teams Claude Desktop, VS Code Copilot, Copilot Studio, and Cursor compared for compliance teams: OAuth MCP support, enterprise controls, data-training policies. A compliance officer evaluating AI tooling gets pitched the model. Claude is good at reasoning, Copilot is in everyone's IDE already, Cursor writes code fast. All true, and almost beside the point for the decision in front of you. If the plan is to put an AI client in front of a regulatory-intelligence gateway and have it run gap analyses, DPIAs, and threat models, the model is the part you change least often. The client — the app that holds the OAuth token, talks to your admin's identity provider, and ships your prompts somewhere — is the part that decides whether the arrangement survives your own data protection review. We work with all of them. The Ansvar gateway is a single OAuth 2.1 MCP endpoint, and Claude, Copilot, and Cursor all reach it and get the same cited answers, because the grounding happens on our side. So this is not a "buy our client" piece — we do not sell one. It is the comparison we would run if we were the compliance team doing the procurement, opinionated on the two requirements that actually matter and neutral on the rest. The two requirements, before the feature grid # Start with what is non-negotiable, because it collapses the choice faster than any feature matrix. OAuth-based MCP, not a token in a config file. The Model Context Protocol can authenticate two ways in practice: a proper OAuth flow, where the client redirects the user to log in, gets a scoped and revocable token tied to an identity, and refreshes it; or a static secret pasted into a JSON config. The second is the same anti-pattern as a long-lived API key, and it fails the same way — it ends up in a dotfile, a screenshot, a committed .mcp.json , a synced settings backup. For a tool that can read your regulatory posture and your uploaded documents, a static token is a standing finding waiting to be written up. Insist on OAuth. No training on your data. A compliance team's prompts are sensitive in a way that is easy to miss. The questions you ask — "does this vendor arrangement trigger a DPIA," "are we late on a breach notification," "which of these CVEs is exploitable on the payments path" — describe your weak points. If the client vendor trains on prompts, those questions become training signal. You want a contractual no-training guarantee on inputs and outputs, in the data-processing terms, not a blog promise. This is the same accountability logic the GDPR builds in: under Article 5 GDPR a controller has to be able to demonstrate compliance, and you cannot demonstrate control over data you have handed to a model trainer on default terms. Everything below is downstream of those two. A client that nails OAuth MCP and gives you a no-training enterprise tier is a candidate. One that wants a static token or trains on your prompts by default is not, however good the model is. Claude — Desktop and Code # Claude ships in two shapes a compliance team will care about: Claude Desktop, the chat app, and Claude Code, the terminal/agent client engineers live in. Both are first-class MCP clients with real OAuth support for remote servers. Connecting to the gateway is the canonical two-minute flow — add the remote server, complete the OAuth redirect, and the gateway's tools appear in the tool list. No static token, no manual header juggling. For enterprise controls, the relevant surface is the Anthropic enterprise/Team plans and the admin features around them: SSO, user management, and — the one that matters here — the data-handling commitment. Anthropic's commercial terms do not train on your inputs or outputs by default. That is the posture you want stated, and you should still read your own contract, but the default is the right way round. Where Claude fits: teams that want the strongest reasoning on the workflow itself — walking a STRIDE or LINDDUN threat model, reading a tender, drafting a gap analysis — and that are comfortable with a dedicated AI client rather than living inside an IDE. Claude Code in particular is a strong fit for the engineer who is also doing the compliance plumbing, because it can drive the gateway and edit the repo in the same session. The model's willingness to refuse rather than confabulate also pairs well with the gateway's refusal discipline — a question it cannot ground comes back as "unresolved," not invented. VS Code Copilot agent mode # GitHub Copilot's agent mode in VS Code is an MCP client, and for a lot of engineering-heavy compliance teams it is the path of least resistance — the editor is already open, the seats are already bought. It supports remote MCP servers, and recent versions handle the OAuth flow for them rather than forcing a static token, which clears the first requirement. The enterprise-controls story here is genuinely good, because it rides on the GitHub/Microsoft enterprise machinery your org may already run: organization policy over which features are enabled, audit surfaces, and — the control specific to MCP — the ability for an admin to govern which MCP servers users may connect, rather than leaving it to each developer's local config. That governance layer is the thing a CISO asks for and most consumer chat apps do not have. If you already manage GitHub at the org level, Copilot agent mode lets you treat MCP server access as one more thing policy decides. The data posture is the part to read carefully, because Copilot has consumer and business/enterprise tiers with different commitments. The business and enterprise tiers carry a no-training-on-your-content commitment; the free/consumer tier does not give you the same guarantee. For a compliance team, that means the requirement is not "use Copilot" but "use Copilot Business or Enterprise, with the no-training term confirmed in your agreement." On the right tier it qualifies; on the wrong tier it fails the second requirement. Where it fits: engineering orgs standardized on GitHub Enterprise who want compliance workflows to live where the code does, with MCP server access governed centrally. Copilot Studio # Microsoft Copilot Studio is a different animal — it is the low-code agent-builder, not a chat client. You use it to build an agent (a "copilot") that your non-technical colleagues then talk to, and that agent can call MCP servers as tools. For a compliance team this is the option that turns the gateway into something a procurement officer or a privacy analyst uses without ever seeing a tool call. Its MCP support has matured to where you can register a remote server and have the studio-built agent call it. OAuth is supported through the connector/authentication configuration, so you are not stuffing a static secret into the agent definition. The trade is that you are now operating inside the Power Platform governance model — environments, data-loss-prevention policies, connector governance — which is heavyweight but, for a regulated enterprise, often exactly the control surface you are required to have anyway. Admins can constrain which connectors and which MCP servers an agent may use, and that lines up with how a compliance function wants to deploy a shared tool. Data posture follows the Microsoft enterprise commitments for the tenant the agent runs in, which for business tenants includes the no-training-on-your-data stance. As with Copilot in VS Code, confirm it against your tenant's agreement rather than the marketing tier. Where it fits: a compliance function that wants to publish a governed, self-serve agent to colleagues — "ask the compliance copilot whether this needs a DPIA" — and is already inside the Microsoft 365 / Power Platform world. The build cost is higher; the distribution to non-technical users is the payoff. Cursor # Cursor is the AI-first code editor, and it is a capable MCP client with OAuth support for remote servers. For a compliance team it sits in the same slot as Copilot agent mode — engineer-facing, IDE-resident — with a more aggressive agentic posture out of the box. Two things to weigh. First, model choice: Cursor lets you route to several underlying models, which is flexible but means your no-training guarantee depends on which model and which Cursor plan you are on, not on "Cursor" as a monolith. You have to pin the data commitment to the specific configuration, and Cursor's business/enterprise plan with a zero-data-retention or no-training mode is the configuration that clears the bar. Second, enterprise governance over MCP servers is less mature than the GitHub/Microsoft org-policy machinery — it is improving, but if central control over which servers users connect is a hard requirement, verify it for your version rather than assuming it. Where it fits: engineering-led teams who want the most autonomous agent loop and are willing to do the configuration work to lock down the data posture explicitly. The capability is there; the governance is more on you. The part the client does not change # Here is the load-bearing point, and the reason we can be neutral on the client. The regulatory grounding does not live in any of these apps. It lives in the gateway. When the agent — whichever one — asks "what does DORA require of an ICT third-party contract," it calls search and get_provision against the corpora, and the answer comes back as a structured provision with a stable identifier and a validated citation. The DPIA trigger resolves to Article 35 GDPR because the gateway read it, not because the model recalled it. The 72-hour breach-notification clock in Article 33 GDPR, the records-of-processing duty in Article 30 GDPR, the ICT third-party contractual requirements in Article 28 DORA — each comes back from the corpus, deterministically validated, identical no matter which client window the question was typed into. That is the design property worth paying for: cited answers instead of a confident guess . The client you pick changes who sees your prompt and how your admin governs the connection. It does not change whether the citation is real. So you can choose the client on the two requirements and the fit notes above, and trust that the compliance substance — the coverage across 29 audited law jurisdictions, 262 security frameworks, and the EU regulations corpus — is constant. text Copy Your client (Claude / Copilot / Cursor) │ OAuth 2.1 (no static token) ▼ gateway.ansvar.eu ── EU-hosted, no server-side model │ search / get_provision / workflow engine ▼ 29 audited law jurisdictions · 262 frameworks · 102 EU-regulation instruments → structured provisions · validated citations · refusal on the ungroundable A short procurement checklist # If you are running the evaluation, these are the questions that decide it, in order: Does the client support remote MCP servers over OAuth? If it wants a static token in a config file, stop. Claude, Copilot agent mode, Copilot Studio, and Cursor all clear this on current versions. What does the data-processing agreement say about training on your inputs and outputs? Pin it to the specific plan and tier, not the brand. Several of these clients pass on business/enterprise tiers and fail on consumer tiers. Can your admin govern which MCP servers users connect? This separates the GitHub/Microsoft enterprise options from the consumer chat apps. If central control is a requirement, the org-policy clients win it. Where does each hop go? Model vendor sees the prompt; the gateway, EU-hosted with no server-side model, sees the regulatory lookups. Map both against your data-residency and sub-processor obligations. Does it actually run the workflow you need? Connect a free-tier gateway account (100 searches a day, no card) and run one real gap analysis or AI Act readiness check end to end before you commit a seat budget. How we would call it # For an engineering-led team already on GitHub Enterprise, VS Code Copilot agent mode on a business tier is the least-friction qualifying option — the governance is there and the editor is already open. For a compliance function that wants a governed self-serve agent for non-technical colleagues, Copilot Studio inside an existing Microsoft 365 tenant is the one that distributes. For the strongest reasoning on the workflow itself and the cleanest default data posture, Claude — Desktop for analysts, Code for the engineer-compliance hybrid. Cursor for teams who want the most autonomous loop and will do the configuration to lock the data commitment down. None of those is a wrong answer. All four speak OAuth MCP, all four can be put on a no-training tier, and all four reach the same cited corpora through the gateway. Pick on your two requirements and your org's existing rails, connect it to the gateway, and run one real workflow before you decide. The model is the part you will change least; the client is the part your data protection review will read most closely. Choose it like the compliance decision it is. On this page The two requirements, before the feature grid Claude — Desktop and Code VS Code Copilot agent mode Copilot Studio Cursor The part the client does not change A short procurement checklist How we would call it Frequently asked Does it matter which AI client a compliance team picks if they all speak MCP? Less than vendors imply, and more than the spec sheet shows. Any client that implements the Model Context Protocol with OAuth can connect to the Ansvar gateway and call the same tools — search, get_provision, the workflow engine — and get the same cited answers, because the grounding happens server-side. What differs is the surrounding posture: whether the client supports OAuth 2.1 cleanly or wants a static token in a config file, whether your admin can govern which servers a user connects, and whether the vendor trains on your prompts. The model answers; the client decides who else sees the question. Which clients does the Ansvar gateway work with today? Any MCP client that supports remote servers over OAuth. That includes Claude Desktop and Claude Code, VS Code's Copilot agent mode, Microsoft Copilot Studio, and Cursor. The gateway is a single OAuth 2.1 MCP endpoint at gateway.ansvar.eu, so connecting is a two-minute setup regardless of client — point it at the endpoint, complete the OAuth flow, and the tools appear. We are vendor-neutral on the client by design: the value is in the cited corpora and deterministic validation behind the gateway, not in any one app's chat window. What are the two non-negotiable requirements when picking a client? OAuth-based MCP and a no-training guarantee on your data. OAuth means access is scoped, revocable, and tied to an identity your admin controls — not a long-lived API key pasted into a JSON file that leaks the day someone commits it. A no-training guarantee means the vendor will not use your prompts or the regulatory questions you ask to improve a model that competes with you or exposes your posture. Everything else — UI polish, IDE integration, agent autonomy — is a preference. Those two are requirements, because a compliance team's questions are themselves sensitive. Where does the data actually go when we run a workflow? Your prompt goes to whichever model your chosen client runs — Anthropic for Claude, the model behind Copilot or Cursor for those. The regulatory grounding goes to the Ansvar gateway, hosted in the EU on Hetzner, which returns cited provisions from the law and framework corpora. The gateway holds no server-side model and stores no client documents beyond a workflow's lifetime. So the model vendor sees your question; Ansvar sees the regulatory lookups. Read your client vendor's data-processing terms for the first half — that is the half this article is about. --- ## Stop letting threat models die in a wiki: make STRIDE output double as compliance evidence · Ansvar AI Blog URL: https://ansvar.eu/blog/threat-model-to-compliance-evidence A threat model and a NIS2/DORA/ISO gap analysis describe the same system. Map each threat to the measure it satisfies, with article-level citations. A threat model is one of the most expensive documents an engineering team produces, and one of the most consistently wasted. A team spends two to four hours walking trust boundaries, scoring likelihood and consequence, writing mitigations. The output lands in a wiki page. Six weeks later the compliance team starts a NIS2 gap analysis from a blank template and re-documents the same system — the same data flows, the same controls, the same risks — because nobody told them the threat model already contained 80% of the answer. The two documents describe the same system. The engineer calls the entry "Tampering at the partner-agent boundary, mitigated by structural input isolation." The auditor calls it "a cybersecurity risk-management measure under NIS2." It is the same control. The only thing missing is the wiring that lets one artifact be read by both desks. We built that wiring into the threat-modeling workflow. This post is how it works and why the citation layer is the part that makes it hold up. The two documents are the same facts in different clothes # Start with what a STRIDE walk actually produces. For each trust boundary in your data-flow diagram, you record a threat, its likelihood and consequence, the controls already in place that reduce it, and the residual risk after those controls. That is the structure of our STRIDE workflow, described in detail in how we threat-model AI systems . Now look at what a risk-based security regime asks for. NIS2 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage the risks to the security of their network and information systems — risk identification, then proportionate controls, then evidence that you did both. DORA frames the same expectation as an ICT risk-management framework: identify ICT risks, apply controls, test, report. ISO/IEC 27001 frames it as Annex A controls selected against a documented risk assessment. Every one of those regimes is asking the question a threat model already answers: what can go wrong with this system, and what have you done about it? The threat model is the risk assessment. The mitigations column is the control set. The residual-risk column is the proportionality argument. The regimes differ in vocabulary and in which obligations they enumerate, but the underlying artifact is one risk-and-control register, not three. The waste comes from treating them as three. What the mapping looks like in practice # Here is a single STRIDE row, carried all the way through to the regulatory measure it satisfies. The system is a payments API exposing a delegated-payment endpoint to partner agents — the worked example from our STRIDE post. Field Value Boundary Free-text input from partner agent → payment-orchestration LLM STRIDE category Tampering (prompt injection) Threat Untrusted partner content hijacks the orchestrating model and rewrites a payment instruction Mitigation Structural isolation: tool results sandboxed as data; instructions never sourced from upstream content Residual risk Medium NIS2 measure Cybersecurity risk-management measures — security of operations and handling of untrusted input DORA measure ICT risk-management framework — protection and prevention controls ISO 27001 Annex A control family covering secure development and input handling The right-hand three rows are the difference between a wiki page and an audit artifact. They are not annotations a human types after the fact. They are produced by the same agent that ran the walk, by asking the gateway which regulatory measures does this control answer to and grounding the answer against the live legal corpus rather than the model's memory. The mapping is many-to-many on purpose. The prompt-injection mitigation above also helps satisfy GDPR's security-of-processing duty when the payment data is personal data. And the NIS2 risk-management obligation is satisfied not by this one threat but by the full set the walk produces. We record both directions: threat → measures, and measure → threats. The second direction is what an auditor reads — show me every control you have against this obligation — and it falls out of the first for free. Why the citation has to be grounded, not generated # This is the part that separates a defensible artifact from a liability. A model that maps threats to regulations by recall will produce something that looks perfect and is occasionally wrong in ways you cannot see. We have watched a retrieval pipeline state, with full formatting confidence, that "Article 47 of NIS2 requires a 48-hour breach notification." The article number was wrong, the obligation lived elsewhere, and the figure was recalled rather than retrieved — three independent errors in one clean-looking citation, none of which left a trace in the output. We covered that failure class in cited answers vs. RAG for regulated work . For a wiki page, a wrong article number is an annoyance. For an audit pack you hand to a regulator or an insurer, a fabricated citation destroys the credibility of the whole document. The breach-notification duty under GDPR Article 33 runs on a 72-hour clock — a report that mis-cites its own legal basis is not a defensible filing, and the same logic applies to every control-to-obligation claim in a threat model offered as evidence. So we ground every regulatory claim. When the workflow attaches a NIS2 or DORA or ISO citation to a mitigation, it comes from a gateway tool result that retrieved and validated the provision, not from the model's training data. The mechanism is the same one behind every cited answer the gateway produces: text Copy search(query="cybersecurity risk-management measures", frameworks=["NIS2"]) search(query="ICT risk-management framework", frameworks=["DORA"]) get_provision(jurisdiction="EU", law="GDPR", article="33") validate_citation(jurisdiction="EU", law="GDPR", article="33") If the gateway cannot confirm an article exists and says what the mapping claims, the citation does not ship. A threat with no defensible regulatory basis after that search is marked as exactly that — an honest gap — rather than dressed in a plausible-looking article number. The grounding ratio is a hard refusal, not a soft degradation: below the configured threshold the gateway refuses to synthesize rather than fill in from memory. A mis-cited control is worse than a declared unknown when the reader is an auditor. Running it: threat model and gap analysis as one walk # The two workflows already share a spine. STRIDE, LINDDUN, and the gap-analysis workflows in the gateway all follow the same shape — scope the system, generate a data-flow diagram, walk the elements, score, report — and they differ only in the question set and the control catalog plugged in. That shared structure is what makes the dual-output trick cheap. A team that wants both an engineering threat model and a regulatory gap analysis from one effort does it like this. Connect any MCP client — Claude, Copilot in VS Code or Studio, Cursor, anything that speaks OAuth 2.1 MCP — to the gateway, then run the STRIDE walk first: text Copy start_workflow( workflow_type="threat_model", entity_description="Payments API: delegated-payment endpoint exposed to partner agents; processes personal + financial data; EU-deployed; in scope for NIS2 and DORA." ) Walk scoping → DFD → per-boundary STRIDE → scoring, the loop described in the STRIDE post. Then point the same system scope at the regulatory catalog. The gap-analysis workflow loads a control catalog by framework — nis2 pulls the NIS2 risk-management measures, dora pulls the DORA ICT-risk controls, cra pulls the EU Cyber Resilience Act essential requirements — and walks the controls instead of the six STRIDE categories. Because both ran against the same data-flow diagram and the same asset list, the agent can join them: each gap-analysis control is matched to the threats whose mitigations already address it, and each unmatched control is a genuine open item rather than a paperwork miss. The report stage is where the dual output materializes. The same generate_report call that re-resolves citations for the threat model produces a control register keyed to article-level obligations — one export the engineers read as a threat table, the same export the auditor reads as a measure-by-measure coverage matrix. If you want the gap analysis as its own deliverable, the gap-analysis workflow produces it standalone; if you are working toward an EU AI Act conformity file, the AI Act readiness path overlays the same machinery on the Act's requirements. The mapping table is the load-bearing part # A threat-to-regulation map is only as good as the catalog behind it, and this is where most home-grown attempts quietly fall apart. Hand-maintaining a spreadsheet that says "control X satisfies NIS2 measure Y and ISO control Z" works until the regulation is amended, the control library is reorganized, or someone copies a stale row into next year's audit pack. The mapping rots and nobody notices until an auditor checks one cell. We keep the mapping live by deriving it from the corpus rather than storing it as prose. The control catalogs are versioned YAML in the workflow definitions, the regulatory text comes from the law and EU-regulation corpora behind the gateway — currently 29 audited law jurisdictions live, out of 119 law corpora built, plus an EU regulations corpus of 102 instruments with article-level addressable provisions and 262 security frameworks — and every citation in a generated report is re-resolved at report time with a paragraph-hash drift check. If the underlying provision moved or changed, the report says so instead of carrying a citation that was true last quarter. You can see the breadth of what is mappable on the coverage page , and the citation-validation mechanics on how it works . This is the difference between a mapping you maintain and a mapping that maintains itself. The threat model does not get stale relative to the regulation, because both are read from the same versioned source at the moment the report is generated. What this changes for the two desks # For the engineering team, nothing about the threat-modeling discipline changes. You still scope the system, draw the data-flow diagram, walk the boundaries, and argue residual risk. The only addition is that each mitigation now carries the regulatory measure it answers to — surfaced by the agent, not typed by you. For the compliance team, the change is larger. The NIS2 or DORA gap analysis no longer starts from a blank template and a series of interview requests. It starts from the threat model the engineers already produced, with the controls already identified and the obligations already cited. The compliance officer's job shifts from re-documenting the system to reviewing coverage: which obligations are fully met by existing mitigations, which are partially met, which are open. That review is the work that actually requires their judgment. The transcription that used to consume it does not. And when the auditor asks the question every audit comes down to — show me the control behind this obligation, and show me it is real — the answer is one artifact away, with a citation the regulator already accepts. Try it # Tier requirement. The start_workflow / submit_response / generate_report lifecycle is on every tier, but the workflow types are not. STRIDE threat models on a system you describe run from Free up, metered monthly — 1 run on Free, 2 on Solo, 5 on Premium , which adds LINDDUN and TARA. The gap_analysis workflow, and every workflow grounded in your own documents, stays on Team and Company . The full pairing this post describes therefore needs Team. See /pricing for the tier matrix. If your AI client speaks MCP and you are on Team or Company: Connect it to the gateway — https://gateway.ansvar.eu/mcp , OAuth 2.1, two-minute setup per the quickstart . Run a STRIDE walk on a system in scope for NIS2 or DORA via the threat-modeling workflow , then run the matching gap_analysis framework against the same scope. Ask your agent: "For each threat we identified, map the mitigation to the NIS2, DORA, and ISO 27001 measures it satisfies, ground every citation through the Ansvar gateway, and flag any control with no defensible regulatory basis as an open gap." The agent runs both walks, joins them on the shared data-flow diagram, and returns one report the engineers read as a threat table and the auditor reads as a cited coverage matrix. A threat model that dies in a wiki is a sunk cost. A threat model that doubles as cited compliance evidence is the cheapest audit preparation you will ever do — because you did the work the moment you decided to ship the system safely, and the citations were waiting in the corpus the whole time. On this page The two documents are the same facts in different clothes What the mapping looks like in practice Why the citation has to be grounded, not generated Running it: threat model and gap analysis as one walk The mapping table is the load-bearing part What this changes for the two desks Try it Frequently asked Why should a threat model count as compliance evidence at all? Because the two documents are derived from the same facts. A NIS2 cybersecurity risk-management measure and a STRIDE mitigation at a trust boundary are the same control viewed from different desks: the engineer sees a threat to close, the auditor sees an obligation to satisfy. When the threat model records which control mitigates each threat and cites the regulatory measure that control answers to, the auditor reads the model directly instead of asking you to re-document the same system in a compliance template. The work you already did to ship safely becomes the work that proves you complied. Which regimes can a single threat model produce evidence for? The ones whose obligations are framed as risk-based security measures rather than prescriptive checklists. NIS2's risk-management measures, DORA's ICT risk-management framework, and ISO/IEC 27001's Annex A controls all expect you to identify risks to your systems and apply proportionate controls — which is exactly what a STRIDE or LINDDUN walk produces. GDPR's security-of-processing duty and DPIA obligation overlap too. The mapping is many-to-many: one threat can satisfy a NIS2 measure and an ISO control at once, and one regulatory measure is usually answered by several threats. Doesn't mapping threats to regulations risk fabricated citations? That is the failure mode worth designing against. A model that generates a citation from training data produces something that looks identical to a grounded one — same format, same confidence, wrong article. We require every regulatory claim in a threat model to come from a tool result the gateway retrieved and validated, not from the model's memory. If the gateway cannot confirm an article exists and says what the model claims, the citation does not ship. A mis-cited control in an audit pack is worse than an honest gap. How is this different from a GRC tool that stores a control library? A GRC tool stores controls and asks you to attest to them. It does not know whether a control is justified by an actual threat to your system, and it does not carry the regulatory text behind each obligation. The threat-model-as-evidence approach runs the other direction: it starts from threats to your specific data flows, derives the controls that close them, and attaches the article-level citation that makes each control an obligation rather than a preference. The two are complementary — the threat model populates and justifies the control register the GRC tool tracks. --- ## EU AI Act: your obligations depend on your role, not your tech stack · Ansvar AI Blog URL: https://ansvar.eu/blog/eu-ai-act-obligations-by-role Provider, deployer, importer, distributor, GPAI provider — each EU AI Act role carries its own obligations. The role test, article references, and live dates. The first question a compliance team asks about the EU AI Act is usually "is our system high-risk?" That is the wrong first question. The Act does not hand you one obligation list keyed to risk. It hands you a different list depending on which economic role you occupy for a given system — and the same company can be a provider for one system, a deployer for another, and an importer for a third, all in the same week. Get the role wrong and you will either over-build controls you do not owe or, worse, miss the ones you do. The Regulation — (EU) 2024/1689, in force since 1 August 2024 — defines six operator roles and assigns each a distinct obligation set. This post walks the role test, then the obligations per role with article references, then the "we just use a vendor's model" trap that catches more organisations than any other, and ends with the application dates that are actually in force rather than the headline ones. The role test comes before the risk test # An "AI system" under the Act is, roughly, a machine-based system that infers from input how to generate outputs — predictions, content, recommendations, decisions — that influence environments. Once something is in scope, the Act asks who you are to it . The six roles: Provider — you develop an AI system or a general-purpose AI model, or have one developed, and place it on the market or put it into service under your own name or trademark, whether for payment or free. Deployer — you use an AI system under your own authority in the course of a professional activity. (Purely personal, non-professional use is excluded.) Importer — you are established in the EU and place on the market a system bearing the name or trademark of a party established outside the EU. Distributor — you are in the supply chain, other than provider or importer, and make a system available on the EU market. Product manufacturer — you place on the market or put into service an AI system together with your product and under your own name, where that product is already covered by EU sectoral product law. GPAI model provider — you place a general-purpose AI model on the market, the foundation-model case, which the Act treats under its own chapter. The test is functional, not contractual. A clause in a vendor agreement calling you "the customer" does not make you a deployer if what you actually do is rebrand the system and resell it — that makes you a provider. Run the role test per system, and re-run it whenever you change a system's branding, purpose, or substance. Provider: the heaviest set # If you are the provider of a high-risk AI system, you carry the core of the Regulation. The provider-obligations article — Article 16 — enumerates the duties and points to the substantive requirements that sit in the chapter on requirements for high-risk systems (roughly Articles 9 through 15). In practice a provider must: Establish, document, and maintain a risk-management system that runs across the whole lifecycle (Article 9). Meet data and data-governance requirements for training, validation, and testing data — relevance, representativeness, error examination, bias scrutiny (Article 10). Draw up and keep current the technical documentation before the system goes to market (Article 11) and design the system for automatic record-keeping / logging over its lifetime (Article 12). Build for transparency so deployers can interpret output and use it correctly, including instructions for use (Article 13), and for effective human oversight by the people running it (Article 14). Achieve appropriate accuracy, robustness, and cybersecurity and declare those levels (Article 15). Put a quality-management system in place, run the applicable conformity assessment , draw up the EU declaration of conformity , affix CE marking , and register the system in the EU database before placing it on the market. Operate a post-market monitoring system and report serious incidents to the relevant authority. That is the full weight, and it is why the provider/deployer line matters so much commercially: providers build a conformity dossier, deployers do not. For AI systems that are not high-risk but interact with people or generate content, the provider still owes the transparency duties in the Act's transparency article (Article 50): users must be told when they are dealing with an AI system unless it is obvious, and synthetic audio, image, video, or text content must be marked as artificially generated or manipulated in a machine-readable way. A chatbot or a generative tool that is nowhere near "high-risk" can still trip this one. If you want to test where a specific product or sector arrangement actually lands before you commit engineering, our sample AI Act readiness assessment shows how a system description maps to the article-level obligations that attach to it. Deployer: lighter, but it still bites # Here is the trap, stated plainly: "we just use a vendor's AI" does not put you out of scope. It puts you in the deployer column. And the deployer column has its own article — Article 26 — which lays obligations directly on you for high-risk systems. The headline duties: Use the system per the instructions for use. The provider's instructions are not advisory; deviating from them can shift liability and, in some cases, role. Assign human oversight to natural persons who have the competence, training, and authority to exercise it, and give them the support to do so (Article 26 read with the provider's human-oversight design under Article 14). Ensure input data is relevant and sufficiently representative for the system's intended purpose, to the extent you control the input. Monitor operation against the instructions and, where you have reason to believe use creates a risk or something has gone wrong, suspend use and inform the provider or distributor and the relevant authority. Keep the logs the system automatically generates, for an appropriate period, where those logs are under your control. Report serious incidents to the provider and then the importer/distributor and authority. Cooperate with competent authorities on any action concerning the system. Two deployer-specific duties deserve a flag because they catch organisations that assumed "we're only the user": Workplace information. Before putting a high-risk system into use at work, a deployer that is an employer must inform affected workers and their representatives that they will be subject to it. Fundamental-rights impact assessment (FRIA). Certain deployers — public bodies, and private operators providing public services, plus deployers of specified high-risk use cases such as creditworthiness and certain insurance scoring — must carry out a fundamental-rights impact assessment before deployment, under the Act's FRIA article (Article 27). This is a deployer obligation, not a provider one. If you are a bank deploying a vendor's credit-scoring model, the FRIA is yours to write, not your vendor's. The deployer set is genuinely lighter than the provider set — no conformity assessment, no CE marking, no quality-management system. But "lighter" is not "none," and the FRIA and the worker-information duty are concrete, dated obligations that land on the party that runs the system, regardless of who built it. If your AI governance programme treats vendor tools as somebody else's compliance problem, Article 26 is the article that will surprise you. When a deployer becomes a provider # The role is not frozen at the point of purchase. The Act re-classifies a deployer (or distributor, or importer, or any third party) as a provider — inheriting the full Article 16 set — in three situations: You put your name or trademark on a high-risk system already placed on the market (white-labelling). You make a substantial modification to a high-risk system that is already on the market, such that it still qualifies as high-risk. You modify the intended purpose of a system — including a general-purpose one — that was not high-risk, in a way that makes it high-risk. Fine-tuning a foundation model for a regulated decision, rebranding a vendor's tool as your own product, or pointing a general-purpose tool at a high-risk use it was never assessed for are the everyday triggers. The practical consequence is severe: you go from owing five or six deployer duties to owing the entire conformity dossier. This is the single most expensive role mistake in the Act, and it is made by accident — usually by a product team that "just fine-tuned" something without realising they had become its provider in the eyes of the Regulation. Importer and distributor: the gatekeeper checks # If you bring a non-EU provider's system into the EU market, you are an importer , and your duties (Article 23) are verification duties, not engineering ones. Before placing the system on the market you must check that the provider has carried out the conformity assessment, drawn up the technical documentation, affixed the CE marking, and provided the declaration of conformity and instructions. You must not place a non-conforming system on the market, you keep a copy of the documentation available to authorities, and you ensure storage and transport conditions do not compromise compliance. A distributor — anyone in the chain making the system available who is neither provider nor importer — owes a related set (Article 24): verify the CE marking, declaration, and instructions are present; not make available a system you know or should know is non-conforming; and act (corrective measures, withdrawal, recall, informing authorities) if you find a problem after the system is on the market. Importer and distributor duties are about checking the paperwork is real and stopping a bad system at the gate, not about building the system. Product manufacturer: where the AI Act meets product law # If you place an AI system on the market together with your product and under your own name — the system is a safety component of, or otherwise embedded in, a product already covered by EU sectoral product legislation (machinery, medical devices, and the rest of the Act's listed harmonisation legislation) — you are treated as the provider of that AI system and the AI Act's high-risk obligations are folded into your existing product-conformity route (Article 25). This is also the role tied to the later application date: high-risk systems that are safety components of such products get until 2 August 2028 rather than December 2027, because their conformity has to ride on top of an already-complex product regime. GPAI providers: the foundation-model chapter # General-purpose AI models — the large foundation models trained at scale that can be adapted to many downstream tasks — get their own chapter (Chapter V). A provider of a GPAI model must (Articles 53–55): Draw up and keep current technical documentation of the model, including its training and testing process. Provide information and documentation to downstream providers who integrate the model into their own AI systems, so those parties can meet their obligations. Put in place a policy to comply with EU copyright law , including respecting rights reservations expressed under the text-and-data-mining rules. Publish a sufficiently detailed summary of the content used to train the model, following the template from the AI Office. For models classed as carrying systemic risk (assessed against capability thresholds), the provider takes on additional duties: model evaluation including adversarial testing, assessment and mitigation of systemic risks, serious-incident tracking and reporting, and an adequate cybersecurity posture for the model and its physical infrastructure. The asymmetry to understand: if you build a product on top of someone else's general-purpose model, you are not the GPAI provider — you are a downstream provider or a deployer of the system you build. But the GPAI provider's documentation under Article 53 is precisely the input you need to discharge your own duties. When you procure a foundation model, the documentation package is part of what you are buying, and its absence is a compliance gap you inherit. The application dates that are actually in force # Correction, 11 July 2026. An earlier version of this post gave the pre-omnibus high-risk dates (2 August 2026 / 2 August 2027). The digital-omnibus amendment — adopted by Parliament on 16 June and by the Council on 29 June 2026 — postponed them to 2 December 2027 (stand-alone Annex III) and 2 August 2028 (Annex I embedded). The list below reflects the amended schedule. The Article 50 transparency duties were not moved. The headline "EU AI Act entered into force in 2024" is true and almost useless for planning. The staged dates in Article 113, as amended by the June 2026 omnibus, are what bind you: 1 August 2024 — entry into force. 2 February 2025 — the prohibitions on unacceptable-risk AI practices apply, and the AI-literacy duty (ensuring staff who deal with AI systems have a sufficient level of competence) applies. 2 August 2025 — the governance provisions and the general-purpose-AI model obligations (Chapter V) apply. 2 August 2026 — the Article 50 transparency duties: AI-interaction disclosure and machine-readable marking of synthetic content (with a grace period to 2 December 2026 for watermarking in systems already on the market). 2 December 2027 — the bulk of the high-risk regime for stand-alone Annex III systems (postponed from 2 August 2026). 2 August 2028 — high-risk systems that are safety components of products already covered by other EU harmonisation legislation (the product-manufacturer case above; postponed from 2 August 2027). Use the date that matches your role and classification. A deployer of a high-risk system in a non-product context plans against December 2027; a GPAI provider was already in scope from August 2025; a chatbot or generative-content provider owes Article 50 transparency from August 2026; a product manufacturer embedding AI in regulated hardware has until August 2028 for that specific path. Treating it all as one deadline either rushes work that has a longer runway or, far more dangerously, lets a GPAI, transparency, or prohibited-practice obligation that is already live sit unaddressed. How we ground this, and why it matters here # Every article reference in this post is the kind of claim that has to survive an auditor or a regulator, which is exactly the case where a confidently-worded but wrong citation is worse than no citation. The way we work compliance questions through the gateway is not "ask a model what Article 26 says" — it is to call typed corpus tools through the gateway against the EU regulations corpus (102 instruments, article-level) and validate each citation deterministically before it ships. A claim that cannot be grounded gets marked unresolved rather than dressed up with an invented number. That discipline is the difference between a readiness assessment you can hand to a board and a chat transcript you have to re-check by hand. If you want the article-level obligation map for a specific system rather than the general picture in this post, the AI Act readiness and gap analysis workflows take a system description and return the obligations that attach to your role, each with a validated citation. See /how-it-works for the split between your AI client doing the reasoning and the gateway supplying the grounded law, and /coverage for the corpora the EU AI Act analysis draws on. The single decision that determines most of your obligation set is the one most teams skip: which role are you, for this system, today. Get that right first. The risk classification, the article list, and the date you are working towards all fall out of it — and the "we just use a vendor's AI" answer, comfortable as it sounds, is itself a role answer with its own list of things you owe. On this page The role test comes before the risk test Provider: the heaviest set Deployer: lighter, but it still bites When a deployer becomes a provider Importer and distributor: the gatekeeper checks Product manufacturer: where the AI Act meets product law GPAI providers: the foundation-model chapter The application dates that are actually in force How we ground this, and why it matters here Frequently asked We only use a vendor's AI tool — does the EU AI Act apply to us? Almost certainly yes, as a deployer. The Act defines a deployer as any party using an AI system under its own authority in a professional context, and Article 26 places obligations directly on deployers of high-risk systems: follow the provider's instructions for use, assign competent human oversight, monitor operation, keep the logs the system generates, and inform the provider or authority of serious incidents or risks. 'We just bought it' moves you out of the provider column, not out of scope. The deployer duties are lighter than a provider's but they are real and they are yours. When can a deployer accidentally become a provider? When you change what the system is. The Act treats a deployer as a provider — inheriting the full provider obligation set — if it puts its name or trademark on a high-risk system already on the market, makes a substantial modification to one, or modifies the intended purpose of a non-high-risk system such that it becomes high-risk. Fine-tuning a model, white-labelling a vendor tool under your own brand, or repurposing a system for a use it was not assessed for are the common triggers. The role is not fixed at purchase; it follows what you actually do with the system. What is a GPAI provider and do GPAI rules apply to us? A general-purpose AI model is one trained at scale that can perform a wide range of distinct tasks and be integrated into many downstream systems — the large foundation models. The provider of such a model carries the Chapter V obligations: technical documentation, information for downstream integrators, a copyright policy, and a public summary of training content, with extra systemic-risk duties for the most capable models. If you build on top of someone else's general-purpose model rather than training and placing one on the market yourself, you are a downstream provider or a deployer — not the GPAI provider — but the model provider's documentation is exactly what you need to meet your own duties. Which EU AI Act dates are actually in force right now? The Regulation entered into force on 1 August 2024 and applies in staged phases under Article 113. The prohibitions on unacceptable-risk practices and the AI-literacy duty applied from 2 February 2025. The governance and general-purpose-AI provisions applied from 2 August 2025. The Article 50 transparency duties apply from 2 August 2026. The high-risk regime was postponed by the June 2026 digital-omnibus amendment: the bulk of it now applies from 2 December 2027, with 2 August 2028 for high-risk systems that are safety components of products already covered by other EU product legislation. Plan against the date that matches your role and your system's classification, not the headline 2024 entry-into-force. --- ## Why RAG over a document dump fails regulated work · Ansvar AI Blog URL: https://ansvar.eu/blog/cited-answers-vs-rag-for-regulated-work RAG citations are decorative — no provenance contract links chunk to answer. Regulated work needs typed corpus tools, deterministic validation, and refusal. A retrieval-augmented generation pipeline will happily tell you that "Article 47 of NIS2 requires a 48-hour breach notification." It will format the citation cleanly. It will sound certain. And it can be wrong in three independent ways at once: the article number may not exist, the obligation may live in a different instrument, and the 48-hour figure may be a number the model recalled rather than retrieved. None of those errors leave a trace in the output. The citation looks identical whether it is grounded or fabricated. For internal Q&A that a human double-checks, that is an acceptable failure mode. For a gap analysis you hand to an auditor, a DPIA that goes in the file, or a tender response that a public buyer scores, it is disqualifying. The problem is not that the model is bad at retrieval. The problem is that RAG over a document dump has no mechanism to tell a grounded citation from a decorative one — and regulated work is exactly the case where that distinction is the whole job. This post is about why that gap is structural, not a tuning problem, and what we built instead. What RAG actually guarantees, and what it doesn't # Strip a RAG pipeline to its mechanism. You embed a corpus into vectors, embed the query, return the k nearest chunks by cosine similarity, and paste them into the model's context with an instruction to answer using the provided passages. The model writes prose. Somewhere in that prose it produces citation strings. Three properties follow from that mechanism, and all three matter for compliance. Retrieval is probabilistic, not exhaustive. Nearest-neighbour search returns the chunks that are semantically closest to your query phrasing — not the provisions that govern the question. If the controlling article uses different vocabulary than your query, it can rank below a chunk that merely sounds relevant. There is no completeness guarantee: a RAG retriever cannot tell you "these are all the provisions that apply," only "these were the closest vectors." For a question like "which articles impose breach-notification timelines on us," missing one is the failure you most need to avoid, and the architecture cannot detect the miss. The citation is text, not a reference. When the generator writes "Article 30 GDPR," that string is generated the same way every other token is generated — by predicting what comes next. Nothing in a standard RAG pipeline checks that the cited article corresponds to a chunk that was actually retrieved, or that the article exists, or that it says what the surrounding sentence claims. The citation is decorative: it decorates the answer with the appearance of grounding without the fact of it. This is the mechanism behind the hallucinated-citation problem that has put more than one lawyer in front of a judge explaining a brief full of invented cases. There is no provenance contract. A provenance contract would let you answer, for any claim in the output: did this come from the corpus or from the model's training weights, and can I re-validate it against the live source today? RAG cannot answer either question. The retrieved chunks and the model's parametric memory are blended in the same context window, and the output is a single stream of tokens with no per-claim lineage. You cannot diff it, you cannot re-validate it, and you cannot prove to a third party that a given sentence is grounded. Where RAG is genuinely fine # We are not arguing that RAG is bad technology. It is the right tool for a large class of problems, and pretending otherwise would be dishonest. If you are searching your own contracts to find the three that mention a specific indemnity clause, RAG is excellent — a human reads the three hits and judges them. If you are building internal Q&A over your policy library, where the cost of a wrong answer is an employee asking a follow-up, RAG is fine. If you are drafting a first-pass memo and the model surfaces candidate passages for a lawyer to verify and rewrite, RAG earns its keep. In all three, a human stands between the retrieval and the consequence, and the citation is a starting point, not a fact on the record. The dividing line is simple: does anyone downstream treat the model's citation as true without checking it? If the answer is no — if a human verifies every reference before it carries weight — RAG's probabilistic retrieval is a productivity tool and its decorative citations are harmless scaffolding. If the answer is yes — if the output is the deliverable — you have moved into territory where the architecture has to change. Regulated compliance work lives almost entirely on the wrong side of that line. The point of a cited gap analysis is that the reader doesn't re-derive every article. The citation has to be load-bearing. The alternative: typed corpus tools instead of an embedded dump # We took a different architecture. There is no document dump and no embedding index standing in for the law. Instead, the customer's AI agent — Claude, Copilot in VS Code or Studio, Cursor, any MCP client — calls typed tools through the Ansvar gateway , and those tools return structured provisions with stable identifiers. The two that matter most are search and get_provision . search takes a scoped query — a jurisdiction, a framework, a sector — and returns provisions, not chunks. get_provision takes a law and an article number and returns the exact text of that provision with its citation metadata. Behind them sit the audited law corpora for 29 jurisdictions (119 built), an EU regulations corpus of 102 instruments served at article level, and 262 security frameworks — see /coverage for the live inventory. The difference from RAG is not "better retrieval." It is a different contract: A provision comes back as a structured object with a stable identifier, not a free-text chunk. The agent knows it is holding "GDPR Article 30," not "a passage that scored 0.83 on cosine similarity." The corpus is the law as published, segmented at the provision level, not your documents re-chunked by a splitter that knows nothing about legal structure. A sub-article does not get cut in half because it crossed a 512-token boundary. When the agent asks for an article that does not exist, the tool says so. It does not return the nearest neighbour and let the model narrate around it. The model still does the reasoning and the writing. What it no longer does is invent the source material . The law arrives as data, with an identifier, from a tool call that either succeeded or failed. Citation validation: the check RAG never runs # Returning structured provisions removes one class of error. It does not, by itself, stop a model from writing a citation that drifts from what it retrieved. So we run a second check that RAG pipelines have no equivalent for: every citation is validated against the live corpus before it ships. The gateway exposes this as validate_citation . Give it a jurisdiction, a law, and an article, and it confirms the provision exists and returns the current text — including whether the article has been amended since it was last cited. A citation that fails validation does not get downgraded to a warning footnote. It gets caught. For the workflows that produce citation-heavy deliverables — gap analysis, threat modelling, DPIA, tender review — this runs as discipline, not decoration. Every regulatory claim is grounded against a real provision, and the citation that lands in the report is one that re-validates. You, or your auditor, can run the same lookup a year later and get the same provision back, or a clear signal that it changed. That reproducibility is the property RAG cannot offer, because there is nothing stable to re-look-up: the next run embeds, retrieves, and generates afresh, and the citation string is regenerated from scratch each time. This is also why the foundational obligations in EU regulation map cleanly onto the model. The GDPR's accountability principle — the controller must be able to demonstrate compliance — and its records-of-processing obligation under Article 30 both presuppose that you can produce the provision behind a claim on demand. DORA's ICT third-party risk regime, including the register of information required under Article 28 and the key contractual provisions that govern ICT outsourcing, presupposes the same. A pipeline that cannot tell you whether its own citation is real is structurally unable to support "demonstrate." Refusal discipline: a wrong answer is worse than no answer # The last piece is the one most product teams resist, because it makes the demo look weaker. When a claim cannot be grounded, the right output is not a confident guess. It is a refusal. This is a hard rule on our platform: no silent fallbacks. If a corpus tool is unavailable, the answer is a data-source-unavailable error — never a fluent paragraph reconstructed from the model's training memory. If a requirement produces no grounded citation after the workflow has exhausted its enrichment passes, the requirement is marked regulatory_basis_unresolved rather than fitted with a plausible-looking article number. The model is not permitted to paper over a gap with prose. RAG's instinct is the opposite. Faced with weak retrieval, the generator's job is to produce something — and it will, because that is what a language model does with an underspecified context. The fluency that makes RAG demo well is exactly what makes it dangerous for regulated work: it never tells you when it is guessing. A compliance officer reading a clean paragraph cannot see that the retriever returned nothing useful and the model improvised. We chose the inverse default. A wrong answer in a compliance deliverable does not just waste time — it creates a false record, and false records are the thing audit regimes exist to prevent. So we would rather the tool say "I could not ground this" and force a human to look, than hand over a confident sentence that nobody knows to question. Availability is not the goal; correctness is. Concretely, what changes for your team # If you run regulatory work through a RAG-over-documents pipeline today, the honest move is not to rip it out. It is to split the work along the line that matters. Keep RAG for what it does well: searching your own corpus — contracts, policies, prior memos, internal guidance — where a human reviews the hits. That is the discovery and drafting layer, and a vector index is a fine engine for it. Route the regulatory grounding through the gateway. When the question is "what does the law actually require," the answer comes back as a validated, cited provision from search and get_provision , not a retrieved guess. Your agent assembles the gap analysis , the threat model , or the AI Act readiness assessment ; the gateway supplies the law with a citation that survives scrutiny. For the EU AI Act specifically, where the obligation that attaches to a system depends on which risk tier it falls in, getting the classification grounded against the actual text — rather than a model's recollection of the risk categories — is the difference between a defensible assessment and a confident one. The architecture is deliberately boring at the seam. The gateway speaks MCP over OAuth 2.1, and the whole thing is EU-hosted with no server-side model holding your data. You bring your own agent; we supply grounded law. Quickstart is at /docs/quickstart , and the tier matrix — free at 100 searches a day, Premium at €249 a month — is on /pricing . The summary is one sentence. RAG retrieves the nearest chunk and writes a citation as text; we return the governing provision and validate the citation before it ships — and when we cannot, we say so instead of guessing. For regulated work, that last clause is the product. On this page What RAG actually guarantees, and what it doesn't Where RAG is genuinely fine The alternative: typed corpus tools instead of an embedded dump Citation validation: the check RAG never runs Refusal discipline: a wrong answer is worse than no answer Concretely, what changes for your team Frequently asked Is RAG always the wrong choice for legal and compliance work? No. RAG is fine for retrieval that a human reviews before it carries weight — drafting a first-pass memo, surfacing candidate passages, internal Q&A over policy documents where a wrong answer costs an awkward correction, not a regulatory finding. It fails when the output is the deliverable and a citation has to survive an auditor, a regulator, or opposing counsel. The dividing line is whether someone downstream treats the model's citation as a fact. If they do, you need a provenance contract that RAG over a document dump does not give you. What is a provenance contract and why does RAG lack one? A provenance contract is a guarantee that every citation in an answer points to a real provision, that the provision text was actually retrieved (not recalled from training data), and that the citation can be re-validated against the live corpus. RAG over an embedded document dump breaks this in two places: the retriever returns the nearest vectors, not the governing provision, and the generator writes a citation string as text — there is no check that 'Article 30 GDPR' in the output corresponds to anything that was retrieved. Deterministic corpus tools close both gaps by returning structured provisions with stable identifiers and validating every citation before it ships. How does Ansvar avoid RAG's hallucinated citations? We do not retrieve chunks and ask a model to write prose with footnotes. The customer's AI agent calls typed corpus tools through the gateway — search and get_provision against 29 audited law jurisdictions, an EU regulations corpus of 102 instruments, and 262 security frameworks. Each tool returns structured provisions with stable identifiers. Citations are validated deterministically against the live corpus before they reach the answer, and if a claim cannot be grounded the workflow marks it unresolved rather than inventing a number. A wrong answer is worse than no answer. Can I keep my existing RAG stack and add Ansvar on top? Yes, and most teams should. Keep RAG for the discovery and drafting it is good at — searching your own contracts, policies, and prior memos. Route the regulatory grounding through the gateway so that any claim about what a statute or framework requires comes back as a validated, cited provision rather than a retrieved guess. Your agent does the writing; the gateway supplies the law with a citation that re-validates. The two are complementary, not competing — see /how-it-works for the split. --- ## Swedish law as an MCP server: how SFS statutes become a queryable corpus · Ansvar AI Blog URL: https://ansvar.eu/blog/swedish-law-as-an-mcp-server 6,041 Swedish statutes from Riksdagen, segmented to section level and served as an MCP — query by SFS number, chapter, and paragraf, every result cited. Sweden publishes its statutes through Riksdagen's open-data API at data.riksdagen.se. It is genuinely open — Swedish statutory text carries no copyright under Upphovsrättslagen (1960:729) 9 §, which excludes författningar from protection — but "open" and "queryable" are not the same thing. The API hands you whole documents with line-break artifacts, embedded amendment notes, and the occasional table-of-contents fragment masquerading as a provision. If you want to ask "what does Chapter 3, Section 12 of this act say," you have a parsing project, not an answer. We built the Swedish Law MCP to close that gap. It holds 6,041 consolidated statutes and 58,570 provisions, segmented to the section level, and exposes them through the Ansvar gateway as tools your own AI client can call. This post walks the whole path: source, consolidation, segmentation, citation format, and what the queries actually look like from Claude or Copilot. It is the worked example behind every jurisdiction on our coverage page — Sweden happens to be the one we know best, and its page lives at /coverage/sweden . The source: SFS via Riksdagen # Svensk författningssamling (SFS) is the official gazette where Swedish laws and ordinances are published. Riksdagen's open-data API is the authoritative channel for the consolidated text — the statute as currently amended, not the original 1962 print. Every statute carries an SFS number of the form year:number : Brottsbalken is 1962:700, Miljöbalken is 1998:808, Avtalslagen is 1915:218. The number is the primary key. It never changes, even as the act is amended hundreds of times across decades. We pull from Riksdagen on a daily check-for-drift schedule. The API documents statute full text, SFS metadata, issue and in-force dates, and the document's internal structure — chapters, sections, paragraphs. What it does not give you is editorial annotation or commentary; this is plain statutory text. That suits a compliance use case, where you want the law as enacted, not a secondary author's gloss. On licensing: the underlying statutory text is public-domain by statute, so we can redistribute it without a vendor agreement. We tag every Swedish item with the SE-Statutory-PD licence code and the riksdagen.se publisher, and the gateway enforces that the attribution triple — source URL, publisher, licence — is present on every result before it leaves the edge. An item missing any of the three is dropped, not silently passed through. Consolidation: the amended text, not the original # A Swedish statute from 1977 has typically been amended dozens of times. Each amendment is its own SFS publication (Arbetstidslagen is 1982:673, but the act has been changed by scores of later SFS numbers). The version you want to reason about is the consolidated text — every amendment folded in, the law as it reads today. Riksdagen publishes that consolidated form, which saves us from having to reconstruct it from a base act plus an amendment chain. What we keep is the relationship: each provision's text, and the trailing law-note that records which SFS amendment last touched it. Those notes look like Lag (1987:823). at the end of a section. They are useful provenance but they are not part of the operative text, so the parser strips them from the section body and preserves the SFS lineage separately. That keeps a search for the substance of a section from matching on a string of amendment numbers. There is a known lag: Riksdagen's consolidated text can trail an official publication by 24–48 hours, and our daily ingest adds its own small window. For compliance work the freshness check matters, which is why the corpus exposes its last-verified date rather than implying it is real-time. Segmentation: chapter and paragraf # This is the part that turns a document dump into a queryable corpus. Swedish statutes come in two structural shapes: Flat acts number sections sequentially: 1 §, 2 §, 3 §, sometimes with letter suffixes for inserted sections — 15 a §, 15 b §. Avtalslagen (1915:218) is flat; its first section is just 1 § . Chaptered acts — the balkar (Brottsbalken, Miljöbalken, Jordabalken) and many newer acts implementing EU regulations — number sections within chapters: 3 kap. 12 § is Chapter 3, Section 12. Our parser stores these as a chapter-qualified reference like 3:12 . The parser activates a chapter on a line matching N kap. , then attaches each following N § section to it, and enforces section monotonicity — section numbers must increase within a chapter — so a table-of-contents line that lists section numbers out of order does not get mislabelled as an actual provision. It is a conservative parser by design: it would rather skip an ambiguous candidate than invent a section that is not there. That bias matters for a compliance corpus, where a phantom provision is worse than a missing one. The result is that every one of the 58,570 provisions is addressable by its statute (SFS number) plus its in-statute reference (paragraf, or chapter-and-paragraf). That addressability is what makes citation deterministic, which is the next piece. Citation format: SFS number plus reference # A Swedish legal citation is two coordinates. First the statute, identified by SFS number — SFS 2024:1278 . Then the location inside it, formatted by structure: a flat statute renders as 34 § , a chaptered statute as 3 kap. 12 § . Put together, a full citation reads 3 kap. 12 § SFS 1998:808 — Chapter 3, Section 12 of Miljöbalken. The gateway builds that citation from the structured reference, not from prose. When a result comes back, it carries a citation block: the canonical SFS reference, the human display text, the official Riksdagen source URL for that statute, the publisher ( riksdagen.se ), and the public-domain licence tag. The source URL follows Riksdagen's own pattern — for SFS 2024:1278 it resolves to riksdagen.se/.../sfs-2024-1278 , so a reader can click straight to the official text. This is the difference between a model that says "I think Swedish data-protection law requires X" and a tool that returns the section text with a citation you can verify. The citation is validated deterministically : same reference in, same provision out, every time. That property is what makes the output usable in a regulator-facing or audit context, where "the model said so" is not an acceptable provenance. What the queries look like # You drive the corpus from your own AI client — Claude Desktop, Claude Code, Copilot in VS Code or Studio, Cursor, anything that speaks MCP. Connect once to gateway.ansvar.eu/mcp over OAuth 2.1 and the Swedish tools are available scoped to jurisdictions=['SE'] . Three patterns cover most of what compliance and engineering teams ask. Search by topic. Swedish search works in Swedish — the corpus is Swedish-language text, so a Swedish query term matches best. To find personal-data provisions you search the native term: code Copy search(query="behandling av personuppgifter", jurisdictions=["SE"]) That returns statute-level hits across the corpus — the acts implementing EU data-protection rules, the Skatteverket personal-data act (SFS 2001:182, which numbers its sections 1 kap. 1 § , 1 kap. 2 § ), and related provisions, each item carrying its SFS number and Riksdagen URL. Fetch an exact provision. When you already know the statute and section, get_provision returns the section text verbatim: code Copy get_provision(jurisdiction="SE", law="2024:1278", article="1:1") SFS 2024:1278 is the Swedish act that complements DORA — the EU Digital Operational Resilience Act, Regulation (EU) 2022/2554 — for the financial sector. Its first section ( 1 kap. 1 § ) states that the act complements that regulation; a later section records that, per Article 46 DORA, Finansinspektionen is the competent authority. That is a clean illustration of why national and EU layers both matter: DORA sets the obligation, the Swedish act names the supervisor and the fee regime. An AI Act readiness assessment or DORA gap analysis that stops at the EU regulation misses the member-state machinery that actually enforces it. Validate a citation you already hold. If a draft policy or a prior report cites 3 kap. 12 § SFS 1998:808 , validate_citation confirms whether the reference resolves and returns the current text — useful when a statute has been amended since the citation was written: code Copy validate_citation(jurisdiction="SE", law="1998:808", article="3:12") In every case the agent calls the tool, the gateway returns the cited section, and your client presents it. The model is how you ask ; the corpus is what answers . That split is deliberate — there is no server-side model inventing legal text in the loop, only a deterministic lookup against the segmented corpus. Free, premium, and what each covers # The full 6,041-statute consolidated corpus and section-level lookups are on the free tier : 100 searches a day, single-jurisdiction, no card. That is enough to wire the Swedish corpus into your agent and run real queries before deciding anything. Premium (€249/month) adds two things that matter for Swedish legal work specifically. It unlocks multi-jurisdiction fan-out, so a single search can reach Sweden alongside EU regulations and other member states in one call — the pattern you want for a cross-border compliance question. And it unlocks the Swedish premium corpora: 12,767 court-decision summaries from ten-plus courts including the Supreme Court, the Labour Court, and the Supreme Administrative Court, with Swedish originals reaching back to 1981; and 6,735 preparatory-works documents (the förarbeten that Swedish legal interpretation leans on heavily). Those are the sources a Swedish lawyer reaches for when statute text alone does not settle a question. Why we built it as 30-plus jurisdictions, not one # Sweden is one of 29 audited jurisdictions live behind the gateway, drawn from a wider set of 119 built law corpora. Each one follows the same recipe: official source, consolidated text, structural segmentation, deterministic citation, daily drift check. The shapes differ — Sweden's kap. § is not Germany's § Abs. is not France's article numbering — but the contract is identical: every provision addressable, every result cited, every citation verifiable against the official source. That uniformity is what makes a multi-jurisdiction gap analysis or threat model tractable. Your agent does not need to know that Riksdagen formats sections differently from Légifrance; it calls the same search and get_provision tools with a different jurisdictions scope and gets back the same cited result shape. The per-jurisdiction parsing work is done once, behind the tool, so the compliance team querying it never has to think about Riksdagen's line-break artifacts again. Try it against Swedish law # If your client speaks MCP, connecting takes about two minutes: Point it at https://gateway.ansvar.eu/mcp and complete the OAuth flow — the quickstart has the per-client config. Ask your agent something concrete: "Use the Ansvar gateway to find Swedish provisions on personal-data processing, scoped to Sweden, and show me the section text with citations." The agent calls search with jurisdictions=['SE'] , returns the cited hits, and you drill into any one with get_provision . The corpus is the same one behind /coverage/sweden , built from data.riksdagen.se, segmented to 58,570 cited provisions, and free to query up to 100 times a day. If you have ever wanted a Swedish law API that returns the section text and the SFS citation in one call, that is exactly what this is. On this page The source: SFS via Riksdagen Consolidation: the amended text, not the original Segmentation: chapter and paragraf Citation format: SFS number plus reference What the queries look like Free, premium, and what each covers Why we built it as 30-plus jurisdictions, not one Try it against Swedish law Frequently asked What source does the Swedish law corpus come from? All statutory text comes from data.riksdagen.se, the Swedish Parliament's official open-data API for Svensk författningssamling (SFS). It is the authoritative publication channel for consolidated statute text, SFS numbers, issue dates, and in-force dates. Swedish statutory text carries no copyright under Upphovsrättslagen (1960:729) 9 §, which excludes författningar — laws and regulations — from protection, so the underlying text is public-domain. Court-decision summaries in the premium corpus carry their own per-item source attribution. We re-check Riksdagen daily for drift; the corpus currently holds 6,041 statutes and 58,570 provisions. How do I cite a specific Swedish provision through the gateway? Swedish citations have two parts: the SFS number that identifies the statute (year:number, e.g. SFS 2024:1278) and the provision reference inside it. Flat statutes use a bare paragraf — '34 §'. Chaptered statutes (the balkar and many newer acts) use chapter-and-paragraf — '3 kap. 12 §'. The gateway's get_provision tool takes the jurisdiction (SE), the law, and the article reference and returns the exact section text plus a citation block carrying the SFS number, the Riksdagen source URL, and the public-domain licence tag. Every result is built from that structured reference, not a model's recollection. Is the Swedish corpus free to query? Yes, on the free tier — 100 searches a day, single-jurisdiction, no card. Connect any OAuth 2.1 MCP client to gateway.ansvar.eu and scope your search to jurisdictions=['SE']. The free tier covers the full 6,041-statute consolidated corpus and section-level lookups. Premium (€249/month) adds multi-jurisdiction fan-out and the Swedish premium corpora — 12,767 court-decision summaries and 6,735 preparatory-works documents for Sweden alone. Why an MCP instead of just scraping Riksdagen myself? Riksdagen's API gives you raw documents with line-break artifacts, table-of-contents fragments, and inconsistent chapter markers. Turning that into a corpus you can query by section means parsing the chapter and paragraf structure, stripping amendment notes, and validating that section numbers stay monotonic so a table-of-contents line does not get mislabelled as a provision. We did that segmentation once, validated it against the source, and exposed it as a tool that returns clean section text with a citation. The point of the MCP is that your AI client gets a queryable, cited corpus instead of a scraping project. --- ## What you can and can't automate in a DPIA · Ansvar AI Blog URL: https://ansvar.eu/blog/automating-the-dpia-evidence-trail A GDPR Article 35 DPIA has an automatable core and a judgment core. AI assembles the cited evidence trail; the DPO signs necessity and proportionality. A DPIA is two jobs wearing one name. One job is clerical: screen the processing, identify which legal triggers fire, write down what the system does, collect the evidence, attach the right article references. The other job is judgment: decide whether the processing is necessary and proportionate, decide whether the residual risk is acceptable, decide whether to consult the supervisory authority. The first job eats most of the hours. The second job is the one a regulator actually holds you accountable for. Most "AI DPIA" tooling gets this backwards. It tries to automate the judgment — generate a risk score, generate an acceptance, generate a sign-off — and leaves the clerical evidence work as a manual afterthought, which is exactly the part that falls apart under audit. We built the opposite. The cited-evidence trail is the automatable core. The judgment stays with a named human, and the machine's job is to put the right facts and the right article text in front of that human so the decision is defensible. This post draws the line in detail, against the actual text of Article 35 GDPR rather than a paraphrase of it. What Article 35 actually requires # Article 35(1) GDPR sets the obligation: where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons, the controller must carry out a DPIA before the processing starts. The word before is doing real work — a DPIA produced after a breach is not a DPIA, it is a post-mortem. Article 35(3) names three cases where the high-risk threshold is presumed met and a DPIA is mandatory: A systematic and extensive evaluation of personal aspects relating to natural persons based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the person. Large-scale processing of special categories of data (the Article 9 categories — health, biometrics, political opinions, and the rest) or of personal data relating to criminal convictions and offences (Article 10). Systematic monitoring of a publicly accessible area on a large scale. Article 35(4) then lets each national supervisory authority publish its own list of processing operations that always require a DPIA. The Dutch AP, the French CNIL, the Swedish IMY each maintain one. A processing activity legal in the abstract can land on a mandatory list in the jurisdiction where it runs, which is why DPIA screening has to be jurisdiction-aware, not just GDPR-aware. We cover this directly — the gateway routes a DPIA screening across the law and data-protection corpora for 29 audited jurisdictions , so the AP's national list is checked, not assumed. And Article 35(7) defines what the assessment must contain . Four parts, and the structure matters because it is where the automatable/judgment line falls almost perfectly: (a) a systematic description of the processing operations and purposes, including, where applicable, the legitimate interest pursued (b) an assessment of the necessity and proportionality of the processing in relation to the purposes (c) an assessment of the risks to the rights and freedoms of data subjects (d) the measures envisaged to address the risks, including safeguards, security measures, and mechanisms to ensure the protection of personal data Part (a) is clerical. Parts (b) and (c) are judgment. Part (d) is a mix — the menu of safeguards is clerical, the residual-risk acceptance is judgment. The WP248 screening — the most automatable step # Before you decide a DPIA is mandatory under Article 35(3), you usually run the screen the Article 29 Working Party set out in WP248. It lists nine high-risk indicators, and the working rule is that processing meeting two or more of them is likely high-risk and needs a DPIA: Evaluation or scoring, including profiling Automated decision-making with legal or similarly significant effect Systematic monitoring Sensitive data or data of a highly personal nature Data processed on a large scale Matching or combining datasets Data concerning vulnerable data subjects Innovative use or application of new technological solutions Processing that prevents data subjects from exercising a right or using a service This is the single most automatable step in the whole exercise, and it is the one teams most often do badly by hand — because doing it by hand means re-reading the WP248 definitions every time and arguing about whether 40,000 records counts as "large scale" for your sector. Hand an AI agent a system description and it can mark each of the nine indicators present or not-present with a one-line rationale, count them, and recommend a scope. We run exactly this in the DPIA workflow: for each indicator the agent states present or not-present with a rationale, and the count drives the recommendation — three or more indicators, or special-category data at scale, pushes the assessment to a comprehensive scope. The key discipline is that the agent verifies the EDPB-defined terms against the actual definitions before it decides — it does not get to invent what "large scale" means. When the description says "we monitor employee endpoints," the agent checks the systematic-monitoring definition and the vulnerable-data-subjects indicator (employees are vulnerable in the employment relationship, a point WP248 makes explicitly) rather than guessing. A screen is a classification task with a fixed rubric and verifiable inputs. That is the sweet spot for automation. The output is not a decision — it is a recommendation with its working shown, which a DPO confirms in seconds instead of assembling from scratch in an hour. The systematic description — assembly, not judgment # Article 35(7)(a) wants a systematic description of the processing operations and purposes. In practice this is the longest section of any real DPIA and almost none of it is judgment. It is data assembly: what personal data, in what categories, from what sources, for what purposes, on what legal basis, shared with which processors, retained for how long, transferred where. If your organisation has already produced a data flow diagram or a threat model of the system, most of these facts already exist as structured records. The agent's job is to pull them, lay them out against the Article 35(7)(a) headings, and flag what is missing. When a customer uploads an existing system description, the workflow extracts the data categories, data subjects, purposes, legal basis, and processors from the document before it asks a single question, and only asks follow-ups for what is genuinely not present in the upload. The one place judgment creeps into part (a) is the legal basis. If the description claims a legal basis — say Article 6(1)(f) legitimate interest for fraud prevention — the agent pulls the actual text of that article through the gateway and checks the stated basis against the processing purpose. If someone cites consent for a legally mandated KYC/AML process, that is inconsistent, and the agent flags it conversationally and suggests the more defensible basis. But it flags; it does not overwrite. The controller still owns the legal-basis decision. The agent's contribution is that it noticed, with the article text in hand, before the supervisory authority did. Necessity and proportionality — the hard human line # Article 35(7)(b) is where automation stops doing the deciding. Necessity and proportionality is a legal judgment about whether the same purpose could be achieved with less data or less intrusive means, and whether the intrusion is justified by the benefit. No model gets to make that call on a controller's behalf. What the engine can do is build the case file the judgment needs. It pulls the Article 5 principles — purpose limitation, data minimisation, storage limitation — and the relevant legal-basis article, and lays the processing against them. Where the basis is legitimate interest, it walks the three-part test structure: the purpose test (is the interest legitimate, not merely convenient), the necessity test (could the purpose be met with less data), and the balancing test (do the data subjects' rights override the controller's interest). It cross-checks the data minimisation claim against the data categories actually extracted in the description — if special-category data is collected but the stated purpose could be met without it, that contradiction surfaces as a flag. That is the boundary, stated plainly: the engine assembles the three-part test, populates it with cited article text and the system's own facts, and identifies the tensions. The DPO reads it and writes the conclusion. The machine prepares the argument; the human owns the verdict. Trying to automate the verdict is how you get a DPIA that reads fluently and falls over the first time a regulator asks why . Risk to rights and freedoms — structured, then judged # Article 35(7)(c) wants an assessment of risks to the rights and freedoms of data subjects — not business risk, not risk to the controller. This distinction trips up a lot of DPIAs, which quietly slide into assessing reputational and financial risk to the company instead of harm to the person . The WP248 harm categories give a structure the agent can work against: physical harm, material damage, non-material damage (discrimination, reputational harm to the individual, psychological distress), loss of control over personal data, limitation of rights, and the heightened impact on vulnerable groups. The agent identifies at least one risk per applicable category and names the specific GDPR right each risk threatens, so the assessment stays anchored to data-subject harm rather than drifting into enterprise risk. Scoring the risks — likelihood against severity on a matrix — is structured enough to automate the bookkeeping, but the severity judgment for harm to a person is not a number a model should assign unilaterally. We treat the scoring as something the analyst reviews at every step. The matrix is consistent; the inputs to it are reviewed by a human who understands the data subjects in question. This is the same principle behind our effective-risk engine for vulnerabilities: the machinery is deterministic, the judgment of what a score means for these people stays with a person, and every step carries its provenance so the reasoning is reproducible rather than vibes. Safeguards and the Article 36 trigger # Article 35(7)(d) asks for the measures that address the risks — the safeguards, the security measures, the mechanisms. The menu side of this is automatable: for each identified risk, propose technical and organisational measures, and map them to the relevant security requirements. Encryption, pseudonymisation, access controls, and the rest map cleanly to Article 32 (security of processing) and Article 25 (data protection by design and by default), and pulling the article text for each gives the safeguard a citation rather than a hand-wave. The judgment side is the residual risk. After the safeguards, is the remaining risk acceptable? That is an accountability decision the controller owns, and it cascades directly into Article 36: where a DPIA indicates the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk , the controller must consult the supervisory authority before processing. Deciding the residual risk is still high enough to trip Article 36 is a call with real regulatory consequence, and it is squarely a human one. The engine prepares the input — it surfaces the residual-risk picture and the Article 36 text — and a named person decides whether to file. No automation gets to decide on its own that you do or do not need to talk to your regulator. Why the cited-evidence trail is the part worth automating # Here is the asymmetry that drove the whole design. The judgment in a DPIA takes a skilled DPO maybe a few hours across all four parts of Article 35(7). The evidence assembly and citation work takes days , and it is the part that decays — references go stale, an article gets amended, a national list gets updated, and the DPIA on file now cites something that no longer says what it claimed. So we automate the durable, verifiable part. Every regulatory reference in a DPIA produced through the Ansvar gateway is resolved against a live corpus rather than a model's memory. The agent calls the gateway's search and get_provision tools to pull the actual current text of Article 35, the Article 5 principles, the legal-basis article, Article 32, and any supervisory-authority guidance that applies in the jurisdiction. A validate_citation call confirms a provision still says what the draft claims and flags it if the text has been amended. The citation check is deterministic — the same DPIA re-run next year resolves to the same provisions, and any drift since the last run shows up as a diff rather than a silent stale reference. This matters because a DPIA is an accountability document. When a supervisory authority opens an inquiry, the question is rarely "did you write a DPIA" — it is "show me the assessment and the basis for your conclusions." A DPIA whose every legal reference resolves to live, current provision text, whose screening shows its working against the WP248 indicators, and whose necessity argument is built from the actual Article 5 principles is a document that survives that conversation. A DPIA assembled from a model's recollection of GDPR, however fluent, is one amended-article away from being wrong on the record. The split is the product. The agent your team already uses — Claude, Copilot, Cursor, any MCP client — drives the workflow: it screens, it assembles the description, it pulls and validates every citation, it structures the necessity test and the risk register. The DPO does the three things only a DPO can do: judge necessity and proportionality, accept or reject the residual risk, decide on Article 36 consultation. Nobody automates the judgment. Everybody should automate the file. If you want to see the line in practice, the DPIA workflow runs through the gateway on Premium (€249/month per seat), grounded against 29 audited jurisdictions and 102 EU-regulation instruments . Connect your MCP client and walk a real assessment in an afternoon — the quickstart is two minutes of OAuth setup. The same gateway that grounds your DPIA also runs your AI Act readiness and gap-analysis work, against the same cited corpus, so the evidence trail is consistent across every assessment your team produces. On this page What Article 35 actually requires The WP248 screening — the most automatable step The systematic description — assembly, not judgment Necessity and proportionality — the hard human line Risk to rights and freedoms — structured, then judged Safeguards and the Article 36 trigger Why the cited-evidence trail is the part worth automating Frequently asked Can a DPIA be fully automated? No, and you should be wary of any tool that claims otherwise. Article 35(7) GDPR requires an assessment of the necessity and proportionality of the processing and an assessment of risks to the rights and freedoms of data subjects. Both are judgment calls a controller is accountable for. What automation does well is the work around the judgment: screening processing against the Article 35(3) triggers and the WP248 indicators, pulling the right article text and supervisory-authority guidance, drafting the systematic description, and assembling a cited evidence trail. The DPO reviews and signs; the machine prepares the file. What are the Article 35 GDPR triggers for a mandatory DPIA? Article 35(3) GDPR names three cases where a DPIA is required: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that produces legal or similarly significant effects; large-scale processing of special-category data (Article 9) or data on criminal convictions and offences (Article 10); and systematic monitoring of a publicly accessible area on a large scale. Article 35(4) lets each supervisory authority publish its own mandatory list. The WP248 guidance adds nine high-risk indicators — meeting two or more usually means a DPIA is required. Where does the human DPO have to make the call? Three places the engine can prepare but cannot decide. The necessity and proportionality assessment under Article 35(7)(b) — whether the same purpose could be met with less data — is a legal judgment. The residual-risk acceptance after safeguards is an accountability decision the controller owns. And the Article 36 prior-consultation trigger — deciding the residual risk is still high — is a call with regulatory consequences. Automation surfaces the evidence and the relevant article text for each; a named person decides. How does Ansvar ground DPIA citations? Every regulatory reference in a DPIA produced through the gateway is resolved against a live corpus, not a model's memory. The agent calls the gateway's search and get_provision tools to pull the actual text of Article 35, Article 5, Article 6, Article 32, and any supervisory-authority guidance, and validate_citation confirms a provision still says what the draft claims. Citations are checked deterministically, so the same DPIA re-run a year later resolves to the same provisions. That cited-evidence trail is the part of the DPIA we think is most worth automating. --- ## Working through DORA Article 28: third-party obligations, the contract checklist, and what the auditor asks for · Ansvar AI Blog URL: https://ansvar.eu/blog/dora-article-28-third-party-mapping DORA Article 28 sets the third-party obligations; the contract clauses live in Article 30. Each subsection mapped to ISO 27001 and SCF controls. If you are standing up a DORA third-party programme, the first thing to get right is which article says what. Article 28 is where most teams start, and it is the right place to start — but it is an obligations framework, not a contract template. The clause-by-clause list of what has to be written into the contract is in Article 30. Confuse the two and you will draft a register procedure where you needed contract language, or cite "Article 28" at an auditor who wants Article 30(3)(e)(i). We pulled the full text of both articles from the live DORA corpus through the gateway before writing this, so every subsection number below is the one the regulation actually uses. Here is how the two articles divide the work, what each obligation maps to in ISO 27001 and the Secure Controls Framework, and what evidence a competent authority will ask you to produce. What Article 28 actually obligates # Article 28 is titled "General principles", and the first subsection sets the tone: under Article 28(1), a financial entity that uses third-party ICT services "shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation". You cannot outsource accountability. The same subsection ties third-party risk into the broader ICT risk management framework of Article 6(1) and applies the proportionality principle. The substantive obligations follow: Article 28(2) requires a strategy on ICT third-party risk, including a policy on the use of ICT services supporting critical or important functions. Microenterprises and the simplified-framework entities of Article 16(1) are carved out. Article 28(3) requires the register of information — the document that has become the most visible DORA deliverable. More on it below. Article 28(4) lists the pre-contract assessment steps: decide whether the service supports a critical or important function, check supervisory conditions, identify all relevant risks including concentration risk, run due diligence on the prospective provider, and assess conflicts of interest. Article 28(5) restricts you to providers that meet appropriate information security standards, with a higher bar for critical or important functions. Article 28(6) covers access, inspection, and audit rights, on a risk-based, pre-determined frequency. Article 28(7) sets the grounds on which a contract must be terminable. Article 28(8) requires exit strategies for critical or important functions. Two more subsections delegate the detail: Article 28(9) tasked the European Supervisory Authorities with the implementing technical standards for the register templates, and Article 28(10) with the regulatory technical standards for the third-party policy. That delegation matters in practice — the register is not a free-form spreadsheet, it follows the ESA templates. The register of information (28(3)) is a reporting obligation, not a list # Teams treat the register as an inventory exercise. Article 28(3) is stricter than that. It requires you to maintain and update the register "at entity level, and at sub-consolidated and consolidated levels", and to distinguish arrangements that cover ICT services supporting critical or important functions from those that do not. That critical/important flag is the same flag that decides whether Article 30(3) applies to the contract — so the register and the contract review share a classification, and they had better agree. The register also carries hard reporting duties. Under Article 28(3) you report at least yearly to your competent authority on the number of new arrangements, the categories of providers, and the types of contractual arrangements and services. You must make the full register, or specified sections, available on request. And you have to inform the authority "in a timely manner" about any planned arrangement supporting a critical or important function, and when an existing function becomes critical or important. The control mapping here is governance and inventory. In the Secure Controls Framework, the gateway corpus surfaces TPM-01 — "mechanisms exist to facilitate the implementation of third-party management controls" — as the umbrella, with the inventory and review discipline supported by service-management governance such as OPS-03 . In ISO 27001:2022 terms, this is Annex A.5.19 (information security in supplier relationships) plus the supplier-monitoring control A.5.22. The evidence an auditor asks for is concrete: the register itself, the dated yearly submission to the authority, the procedure that updates it when a function is reclassified, and the access-control list showing who can edit it. Termination (28(7)) versus exit (28(8)) — they are different obligations # This is the pair that gets conflated most often. Article 28(7) and Article 28(8) sit next to each other and sound similar, but they are separate requirements with separate evidence. Article 28(7) is about the right to terminate. It requires that contracts be terminable in defined circumstances: a significant breach of law or contract by the provider; circumstances found during monitoring that could alter performance; evidenced weaknesses in the provider's ICT risk management — including how it ensures the availability, authenticity, integrity, and confidentiality of data; and the case where the competent authority can no longer effectively supervise you because of the arrangement. These are contract-drafting requirements: the termination clause has to enumerate grounds at least this broad. Article 28(8) is about what happens after you decide to leave. For ICT services supporting critical or important functions, you must have exit strategies that account for provider failure, quality deterioration, and business disruption — including disruption arising from a termination under Article 28(7). The exit must be achievable without disruption to business activities, without limiting regulatory compliance, and without harming service continuity to clients. Article 28(8) also requires alternative solutions, transition plans to move the service and data to another provider or back in-house, and contingency measures. The exit plan must be "comprehensive, documented" and, per the criteria in Article 4(2), "sufficiently tested and reviewed periodically". In control terms, 28(7) maps to contract clauses the gateway corpus expresses as TPM-05.7 ("break clauses within contracts for failure to meet contract criteria for security, compliance and/or resilience controls"). 28(8) maps to the resilience-testing side: TPM-11 ("response/recovery planning and testing are conducted with critical suppliers/providers"), backed by the contingency-planning family BCD-01 , plus asset-return controls such as AST-10 for getting your data and assets back when the arrangement ends. The ISO 27001:2022 anchors are A.5.30 (ICT readiness for business continuity) and A.5.22 for the ongoing review. The evidence split follows the obligation split. For 28(7), the auditor reads the termination clause and checks it covers all four grounds. For 28(8), the auditor wants the exit plan document, the date of the last exit test, and the test result — a plan that has never been exercised does not satisfy "sufficiently tested". Where the contract clauses actually live: Article 30 # Article 28 tells you what to assess and what rights to secure. Article 30, "Key contractual provisions", tells you what to write. This is the article to draft from. Article 30(1) requires the rights and obligations of both parties to be "clearly allocated and set out in writing", in one document, in a durable accessible format, with the service level agreements included. Article 30(2) lists the minimum elements for every ICT contract, including: a clear, complete description of all functions and services, stating whether subcontracting of a critical-or-important service is permitted and on what conditions (30(2)(a)); the locations — regions or countries — where services are provided and data is processed, with advance notice of any change (30(2)(b)); provisions on availability, authenticity, integrity, and confidentiality of data, including personal data (30(2)(c)); access, recovery, and return of data in an accessible format on insolvency, resolution, discontinuation, or termination (30(2)(d)); service level descriptions (30(2)(e)); incident assistance at no extra or pre-agreed cost (30(2)(f)); full cooperation with competent and resolution authorities (30(2)(g)); termination rights and minimum notice periods (30(2)(h)); and participation in your security awareness and resilience training (30(2)(i)). Article 30(3) adds the heavier set for services supporting critical or important functions: full quantitative and qualitative service-level targets (30(3)(a)); notice and reporting obligations on material impacts (30(3)(b)); a requirement for the provider to implement and test business contingency plans and maintain ICT security measures (30(3)(c)); participation in your threat-led penetration testing under Articles 26 and 27 (30(3)(d)); unrestricted access, inspection, and audit rights including for the competent authority (30(3)(e)); and exit strategies with a mandatory adequate transition period (30(3)(f)). That last point closes the loop with Article 28(8): the exit strategy is an obligation under 28 and a contract clause under 30(3)(f). The transition period must keep the provider delivering long enough for you to migrate to another provider or to in-house solutions. The control mapping for Article 30 is the contract-content side of third-party management. The gateway corpus carries TPM-05.2 ("applicable security, compliance and resilience requirements are included in contracts that flow-down to applicable sub-contractors and suppliers"), TPM-10 ("control changes to services by suppliers, taking into account criticality") for the location-change and service-change clauses of 30(2)(b), and the assurance controls TPM-05.6 and TPM-05.8 for first-party declarations and independent (3PAO) attestations that back the audit-right clauses. In ISO 27001:2022, the contract checklist is A.5.20 (addressing information security within supplier agreements) and A.5.21 (managing information security in the ICT supply chain). Concentration risk and proportionality are not optional context # Two cross-references in Article 28 carry weight. Article 28(4)(c) requires you to identify the risk that an arrangement reinforces "ICT concentration risk as referred to in Article 29". Article 29 then requires a preliminary assessment at entity level — whether a provider is "not easily substitutable", and whether you are stacking multiple critical arrangements with the same or closely connected providers. The control anchors are supply-chain risk assessment, which the corpus expresses as RSK-09.1 ("periodically assess supply chain risks associated with Technology Assets, Applications and/or Services") and the diversification control TDA-03.1 ("obtain technologies from different suppliers to minimize supply chain risk"). Proportionality runs through all of it. Article 4 lets you apply Chapter II rules in proportion to size and risk profile — but proportionality scales effort, it does not remove obligations. A small entity still needs a register and an exit plan for its critical providers; it gets to size the rigour to its risk. The control-to-article map, compactly # This is the crosswalk we use when an agent drafts a DORA third-party gap analysis. Every DORA reference is verified through the gateway; every SCF control ID is one the Security Controls corpus returns for the matching query. DORA obligation Subsection ISO 27001:2022 SCF control(s) Strategy + policy for critical functions 28(2) A.5.19 TPM-01 Register of information + yearly reporting 28(3), 28(9) A.5.19, A.5.22 TPM-01, OPS-03 Pre-contract risk assessment, due diligence 28(4) A.5.19 CPL-13.1, RSK-09.1 Concentration risk assessment 28(4)(c), Art. 29 A.5.21 RSK-09.1, TDA-03.1 Information security standards of provider 28(5) A.5.20 TPM-05.2 Access, inspection, audit rights 28(6), 30(3)(e) A.5.22 TPM-05.6, TPM-05.8 Termination grounds 28(7), 30(2)(h) A.5.20 TPM-05.7 Exit strategy, transition, testing 28(8), 30(3)(f) A.5.30 TPM-11, BCD-01, AST-10 Contract content (all services) 30(2) A.5.20, A.5.21 TPM-05.2, TPM-10 Address provider weaknesses monitoring under 28 A.5.22 TPM-01 The mapping is "supports", not "satisfies". An ISO 27001 control or an SCF mechanism is evidence that you have addressed a DORA obligation; it does not discharge the obligation by itself. The auditor reads the article, then asks for the control, then asks for the artefact the control produces. What an auditor or supervisor will ask for # Working backward from the obligations, the evidence requests cluster predictably. For Article 28(3): the register in the ESA template, the dated yearly submission, and the reclassification procedure. For 28(4): the due-diligence file and the concentration-risk assessment for each critical arrangement — CPL-13.1 frames this exactly as "evidence of due diligence activities capable of withstanding external audit or regulatory scrutiny". For 28(7) and 30(2)(h): the termination clause with all four grounds and the notice period. For 28(8) and 30(3)(f): the exit plan, the last exit-test date, the test result, and the named alternative provider or in-house path. For 30(3)(e): the audit-right clause and either a recent audit report or the 3PAO attestation that stands in for one. The pattern is the same one we built the gateway around: a citation is only useful if it points at the exact subsection and the exact control, and if both are real. When your agent runs a DORA gap analysis , it calls get_provision for the article text and pulls the matching control from the Security Controls corpus, so the output reads "Article 30(3)(f) DORA → A.5.30 → TPM-11, last exit test: missing" rather than a vague "third-party section". A wrong subsection number fails validate_citation instead of reaching the report. Run it against your own contracts # The fastest way to see the split between obligation and clause is to point an MCP client at the gateway and have it read both articles for you. Connect your client — https://gateway.ansvar.eu/mcp , OAuth 2.1. Works with Claude, Copilot in VS Code and Studio, Cursor, or any MCP client. The free tier gives you 100 searches a day, enough to read DORA end to end. Ask: "Use the Ansvar gateway to fetch DORA Article 28 and Article 30, and build a checklist of every clause our ICT contracts for critical functions must contain." The agent calls get_provision and returns the cited checklist. Hand it a contract and ask it to flag missing clauses against Article 30(2) and 30(3). The gaps come back article-anchored. The same surface drives the wider compliance work — see how the gateway routes and enriches , the jurisdiction and framework coverage , and the quickstart . For the adjacent regimes most DORA programmes touch, the sample AI Act readiness assessment and sample threat-model deliverable show the same citation discipline. DORA's third-party chapter is precise about which article carries which duty. Citing it precisely — Article 28 for the obligations, Article 30 for the clauses, the right subsection for the right control — is the difference between a register that passes review and one that invites a follow-up question you did not budget for. The gateway exists so that precision is the default, not the thing you check by hand at the end. On this page What Article 28 actually obligates The register of information (28(3)) is a reporting obligation, not a list Termination (28(7)) versus exit (28(8)) — they are different obligations Where the contract clauses actually live: Article 30 Concentration risk and proportionality are not optional context The control-to-article map, compactly What an auditor or supervisor will ask for Run it against your own contracts Frequently asked Are the contractual clauses in DORA Article 28 or Article 30? Both, but they do different jobs. Article 28 is the obligations framework — it requires a strategy, a register of information, pre-contract risk assessment, audit rights, termination grounds, and exit strategies. The actual clause-by-clause checklist of what must be written into the contract lives in Article 30, 'Key contractual provisions'. Article 30(2) lists the minimum elements for every ICT contract; Article 30(3) adds the extra elements for services supporting critical or important functions. If you are drafting contract language, work from Article 30 and use Article 28 to decide which contracts need the heavier set. What is the 'register of information' under DORA? Article 28(3) requires financial entities to maintain and update, at entity and consolidated levels, a register of all contractual arrangements for ICT services from third-party providers. It must distinguish arrangements that support critical or important functions from those that do not. You report at least yearly to your competent authority on new arrangements and provider categories, and you must hand over the full register, or specified sections, on request. Article 28(9) tasked the ESAs with developing the standard templates, so the register follows a prescribed structure rather than a free-form spreadsheet. Does DORA require an exit strategy for every supplier? No — Article 28(8) requires exit strategies specifically for ICT services supporting critical or important functions. The plan has to let you leave the arrangement without disrupting business activities, without breaching regulatory requirements, and without harming service continuity to clients. Article 28(8) also requires alternative solutions and transition plans to move the service and the data to another provider or back in-house, and the exit plan must be tested and reviewed periodically per the criteria in Article 4(2). For non-critical services the lighter Article 30(2) contractual elements still apply, but a tested exit plan is not mandatory. How does the gateway stop us citing the wrong subsection? Every article and subsection in this post was pulled from the live DORA corpus through the Ansvar gateway before it was written. We called get_provision for the full text of Article 28 and Article 30, and validate_citation to confirm Article 28 is in force. When your agent drafts a third-party policy or contract review against DORA, it calls the same tools — so a clause that claims 'required by Article 28(7)' is checked against the real text of 28(7), which is about termination grounds, not contract content. Article-level citations are validated deterministically; a wrong subsection number fails the check rather than shipping. --- ## NIS2 vs ISO 27001: a clause-by-clause working mapping (and where ISO stops short) · Ansvar AI Blog URL: https://ansvar.eu/blog/nis2-vs-iso-27001-clause-mapping Every NIS2 Article 21(2) measure mapped to ISO 27001:2022 Annex A — and the three real gaps: reporting clock, management liability, supply chain depth. Most NIS2-versus-ISO-27001 mapping tables you can find online share one weakness: they pair "Article 21" with "Annex A" at the headline level and stop. Article 21 has ten distinct measure categories in paragraph 2, points (a) through (j). Annex A of ISO 27001:2022 has 93 controls across four themes. A mapping that does not say which subpoint pairs with which control is a diagram, not a working document. You cannot hand it to an auditor, and you cannot use it to find your gaps. This is the version we use. Every pairing below resolves to the actual text of the NIS2 article it cites, grounded through the Ansvar gateway against the NIS2 corpus (Directive (EU) 2022/2555, CELEX 32022L2555). Where ISO genuinely covers a measure, we say so and name the control. Where ISO falls short — and there are three real gaps — we say that too, because pretending an ISO certificate closes them is how organisations walk into a NIS2 inspection unprepared. What NIS2 Article 21 actually requires # Article 21(1) sets the standard: essential and important entities must take "appropriate and proportionate technical, operational and organisational measures" to manage risk to their network and information systems, judged against the state of the art and the cost of implementation, scaled to the entity's exposure, size, and the likelihood and severity of incidents. That proportionality clause matters — it is why a small important entity and a large essential one can both be compliant with different control depth. Article 21(2) then makes it concrete. The measures must follow an all-hazards approach and include at least ten categories: (a) policies on risk analysis and information system security (b) incident handling (c) business continuity, including backup management, disaster recovery, and crisis management (d) supply chain security, including the security of relationships with direct suppliers and service providers (e) security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure (f) policies and procedures to assess the effectiveness of the risk-management measures (g) basic cyber hygiene practices and cybersecurity training (h) policies and procedures on the use of cryptography and, where appropriate, encryption (i) human resources security, access control policies, and asset management (j) the use of multi-factor authentication or continuous authentication, and secured voice, video, text, and emergency communications where appropriate That "at least" is load-bearing. The list is a floor, not a ceiling. An implementing act under Article 21(5) already adds technical and methodological detail for DNS providers, cloud and data-centre operators, managed service providers, and several other digital-infrastructure categories — so for those sectors the floor is higher and more specific than the ten bullets above. The clause-by-clause mapping # Here is the working table. Each row names the ISO 27001:2022 Annex A control, the NIS2 article subpoint it satisfies, and whether the coverage is full or partial. "Full" means an organisation implementing that control, evidenced, would satisfy the measure for audit. "Partial" means the control contributes but does not by itself discharge the obligation. ISO 27001:2022 Annex A NIS2 article Coverage Why A.5.1 Policies for information security Art. 21(2)(a) Full 21(2)(a) explicitly requires policies on risk analysis and information system security A.5.2 Information security roles and responsibilities Art. 20, Art. 21 Full Art. 20 requires management-body accountability; Art. 21 requires the governance framework A.5.23 Information security for use of cloud services Art. 21(2)(d) Partial 21(2)(d) supply chain security covers cloud as a service-provider relationship A.5.29 Information security during disruption Art. 21(2)(c) Full 21(2)(c) requires business continuity and crisis management A.5.30 ICT readiness for business continuity Art. 21(2)(c) Full 21(2)(c) explicitly names backup management, disaster recovery, crisis management A.6.8 Information security event reporting Art. 23 Full (process only) Art. 23 requires incident notification — see the gap section on the timeline A.8.2 Privileged access rights Art. 21(2)(i) Partial 21(2)(i) requires access control policies; privileged access is one slice A.8.5 Secure authentication Art. 21(2)(j) Full 21(2)(j) explicitly requires multi-factor or continuous authentication A.8.8 Management of technical vulnerabilities Art. 21(2)(e) Full 21(2)(e) requires vulnerability handling and disclosure A.8.16 Monitoring activities Art. 21(2) Partial Security monitoring is implied by the all-hazards risk-management duty A.8.24 Use of cryptography Art. 21(2)(h) Full 21(2)(h) explicitly requires cryptography and encryption policies A.8.25 Secure development life cycle Art. 21(2)(e) Partial 21(2)(e) covers security in acquisition and development A few observations that only fall out of mapping at the subpoint level. Article 21(2)(j) is the most specific technical requirement in the whole measure list — it names multi-factor authentication by name. ISO's A.8.5 (secure authentication) maps cleanly, but note the direction of the obligation: NIS2 tells you what (MFA), ISO tells you how well (the control objective). You need both. The control gives you the implementation practice; the article gives you the non-negotiable that it must exist "where appropriate." Article 21(2)(c) maps to two ISO controls, not one. A.5.29 (information security during disruption) and A.5.30 (ICT readiness for business continuity) together cover the backup, disaster-recovery, and crisis-management triad the article names. Mapping (c) to a single continuity control under-evidences it. Article 21(2)(f) — the requirement to have policies and procedures to assess the effectiveness of your own measures — has no crisp single Annex A partner. It is the meta-control. In practice you evidence it with your ISO management-system clauses (the Plan-Do-Check-Act machinery outside Annex A) plus A.5.35 and A.5.36 (independent review and compliance), which is exactly the kind of seam a headline-level table hides. If you want to run these pairings yourself rather than trust the table, point your MCP client at the gateway and ask it to fetch each provision. The lookup that grounds the (j) row is get_provision(jurisdiction='EU', law='NIS2', article='21') ; the corpus returns the verbatim text and you can read subpoint (j) directly. Our gap analysis workflow does this fan-out automatically — it walks each Article 21(2) subpoint, maps your declared controls, and flags the ones with no evidence. Gap one: the reporting clock (Article 23) # This is the gap that catches people. ISO 27001:2022 has A.6.8, "information security event reporting." It requires you to have a mechanism for reporting security events through appropriate channels in a timely manner. An auditor checks that the process exists. NIS2 Article 23 is a different animal. It sets a legal timetable to an external recipient. Under Article 23(4), for a significant incident an essential or important entity must submit: an early warning within 24 hours of becoming aware of the incident, flagging whether it looks malicious or could have cross-border impact (Article 23(4)(a)) a fuller incident notification within 72 hours , with an initial severity and impact assessment and any indicators of compromise (Article 23(4)(b)) a final report within one month of that notification, with a detailed description, the root cause, and the mitigations applied (Article 23(4)(d)) The recipient is your national CSIRT or competent authority — not your internal ticket queue. And a "significant incident" has a statutory definition in Article 23(3): one that has caused or could cause severe operational disruption or financial loss, or considerable material or non-material damage to others. A.6.8 gives you the reporting capability . It does not give you the clock, the threshold, or the external channel. You map the control to the article for the process, then build the 24h/72h/one-month workflow and the CSIRT notification path as separate, NIS2-specific machinery. An ISO certificate is silent on whether you can actually hit a 24-hour wall at 2 a.m. on a Sunday. We model exactly this timeline as a workflow so the clock and the notification draft are generated from the incident facts, with the Article 23 citation attached — see how the gateway turns an obligation into a cited workflow . Gap two: management liability and training (Article 20) # ISO 27001 assigns roles. A.5.2 (information security roles and responsibilities) makes sure someone owns each control. The management system requires leadership commitment. But ISO does not make a named director personally liable for a control failure, because a certification scheme cannot — liability is a matter of law. NIS2 Article 20 can. Article 20(1) requires member states to ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for the entity's infringements of Article 21. That is personal accountability at board level written into the directive. Article 20(2) adds a second duty that no Annex A control captures: members of the management body are required to follow training so they can identify risks and assess cybersecurity practices, and entities are encouraged to extend similar training to staff. ISO's A.6.3 covers security awareness, education, and training for personnel generally — but Article 20(2) puts a specific training obligation on the directors themselves. So A.5.2 maps to Article 20 for the roles dimension, and A.6.3 maps to the staff-training dimension. Neither closes the board-liability gap or the mandatory director-training gap. Those are obligations you discharge through governance and minuted board approval, not through a control implementation an auditor ticks. Gap three: supply chain depth (Article 21(2)(d) and 21(3)) # The mapping table pairs supply chain with A.5.23 and the supplier-relationship controls, and marks it partial. Here is why partial is the honest answer. ISO's supplier controls — A.5.19 through A.5.22, plus A.5.23 for cloud — establish that you manage information security in supplier relationships, agree it in contracts, and monitor it. Good practice, and it maps to the surface of Article 21(2)(d). But NIS2 goes deeper in Article 21(3). When deciding which supply chain measures are appropriate, entities must take into account the vulnerabilities specific to each direct supplier , the overall quality of each supplier's products and cybersecurity practices including their secure development procedures, and — this is the part with no ISO analogue — the results of the coordinated security risk assessments of critical supply chains carried out at Union level under Article 22(1). That Article 22(1) hook means your supply chain due diligence is not purely internal. It is supposed to ingest EU-level critical-supply-chain risk assessments and reflect them in your supplier decisions. No Annex A control points you at an external EU risk assessment, because that mechanism lives in the directive, not the standard. You can be fully conformant with A.5.19–A.5.23 and still under-deliver on Article 21(3) if you have not built the supplier-specific, assessment-aware diligence the article demands. Why "certified" is not "compliant" # An ISO 27001:2022 certificate is strong evidence. For most of Article 21(2) — points (a), (c), (e), (h), (i), (j) especially — a maintained Annex A control set, evidenced, is exactly what a NIS2 supervisor wants to see. We are not arguing the certificate is worthless. The opposite: it does most of the heavy lifting on the technical and organisational measures, and re-using it as evidence saves real work. The argument is narrower and it matters. Three NIS2 obligations sit outside the standard by construction: Article 23's reporting clock is a legal timetable to an external authority. A.6.8 gives you the process, not the 24h/72h/one-month obligation or the CSIRT channel. Article 20's management liability and director training are accountability and governance duties a certification scheme cannot impose. A.5.2 and A.6.3 cover roles and staff awareness, not board liability. Article 21(3)'s supplier-specific, assessment-aware diligence goes beyond the generic supplier-relationship controls and reaches into Article 22(1)'s EU-level assessments. If your NIS2 readiness plan is "we have ISO 27001, we're covered," those three are where an inspection finds daylight. The fix is not to throw out the certificate — it is to map it honestly, claim coverage only where the control genuinely discharges the measure, and build the three gaps as named, NIS2-specific work with the article citation attached to each. Running this yourself # Every article reference in this post resolves to live corpus text. If your AI client speaks MCP, you can reproduce the whole mapping: Connect your client to the gateway — https://gateway.ansvar.eu/mcp , OAuth 2.1, free tier gives you 100 searches a day. Ask it to fetch each NIS2 provision: Article 20, Article 21, Article 23. The corpus returns verbatim text with citation metadata, so you read the subpoints yourself rather than trusting a summary. For the cross-framework view, the gateway reaches the EU regulations corpus (102 instruments, article-level) alongside 262 security frameworks — so the same session that reads NIS2 Article 21 can pull the matching ISO Annex A control and you map them side by side. The pairings in this post are not a frozen spreadsheet. They are grounded against the corpus, which means when an implementing act under Article 21(5) lands new sectoral technical requirements, or the standard's controls shift, the mapping is re-grounded against the new text rather than hand-patched. That is the difference between a mapping table that was true the day someone wrote it and one you can trust on the day you need it. If you are scoping NIS2 readiness from an existing ISO 27001 programme, our gap-analysis engagement starts from your declared controls and walks each Article 21(2) subpoint, marking the ones with evidence, the ones partially covered, and the three structural gaps above — with the article citation on every finding. The certificate is your head start. The gaps are the work the certificate was never going to do for you. On this page What NIS2 Article 21 actually requires The clause-by-clause mapping Gap one: the reporting clock (Article 23) Gap two: management liability and training (Article 20) Gap three: supply chain depth (Article 21(2)(d) and 21(3)) Why "certified" is not "compliant" Running this yourself Frequently asked Does ISO 27001 certification make us NIS2 compliant? No. An ISO 27001:2022 certificate covers most of NIS2 Article 21(2)'s technical and organisational measures, and an auditor will accept your Annex A control set as evidence for them. But three NIS2 obligations sit outside the standard. Article 23 sets a legal incident-reporting clock — a 24-hour early warning, a 72-hour notification, a final report within one month — to a national CSIRT or competent authority; ISO's A.6.8 requires you to have a reporting process but not that timetable or that recipient. Article 20 makes the management body personally accountable and requires them to undergo training; ISO assigns roles but does not put directors on the hook. And Article 21(2)(d), read with Article 21(3), demands supplier-specific diligence that ISO treats more generically. Certification is strong evidence for the measures, not a substitute for the law. Which ISO 27001:2022 Annex A controls map to NIS2 Article 21? The cleanest pairings: A.5.1 (policies) to Article 21(2)(a); A.5.29 and A.5.30 (continuity and ICT readiness) to 21(2)(c); A.8.8 (technical vulnerabilities) to 21(2)(e); A.8.24 (cryptography) to 21(2)(h); A.8.2 and access control to 21(2)(i); A.8.5 (secure authentication) to 21(2)(j), which explicitly names multi-factor authentication. A.5.2 spans both Article 20 governance and Article 21. Supply chain — 21(2)(d) — is partially covered by A.5.23 and the supplier-relationship controls but needs the supplier-specific assessment NIS2 demands in 21(3). The full table is in the post; each row names the exact article subpoint, not just 'Article 21'. What does NIS2 require that no security framework covers? The incident-reporting timeline and recipient. NIS2 Article 23(4) requires an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month — sent to your national CSIRT or competent authority, not just logged internally. No framework control sets that clock for you, because it is a member-state legal obligation, not a security practice. You map A.6.8 (event reporting) to it for the process, then build the actual 24h/72h/one-month workflow and the notification channel separately. A significant incident under Article 23(3) is one that causes or could cause severe operational disruption, financial loss, or considerable damage to others. How do you keep an article-level mapping like this from going stale? We don't maintain it as a static spreadsheet. The pairings are grounded against the NIS2 corpus through the Ansvar gateway, so each one resolves to the live text of the article it claims — Article 21(2)(j), Article 23(4)(a), Article 20(1). When the corpus updates or an implementing act under Article 21(5) adds sectoral technical requirements, the mapping is re-grounded against the new text rather than hand-edited. Your own MCP client (Claude, Copilot, Cursor) can run the same lookups against the same corpus and reproduce every pairing in this post. --- ## What an MCP gateway is, and why compliance work needs one · Ansvar AI Blog URL: https://ansvar.eu/blog/what-is-an-mcp-gateway-for-compliance Chat and RAG hallucinate regulatory citations. An MCP gateway adds routing, fan-out, tier auth, and deterministic citation validation — and when you need one. A compliance officer asks an AI assistant whether a new vendor arrangement triggers a data protection impact assessment. The assistant answers in confident prose, cites "Article 35 GDPR," and moves on. The article is real. But the assistant did not read it — it produced the most probable next tokens given the prompt, and the citation happened to land. Ask a slightly different version of the question and you can get a different article, or a real article number attached to a claim the article does not make. That gap — between text that looks sourced and text that is sourced — is the entire problem with using generic chat and retrieval bots for regulatory work. This post explains the layer we built to close it: the MCP gateway. What MCP is, why compliance breaks generic AI, what a gateway adds over a single MCP server, and when you actually need one. What MCP is, in one section # MCP — the Model Context Protocol — is an open standard for connecting an AI client to external tools and data. Before MCP, every integration between a model and a data source was a one-off: custom glue code, a custom auth scheme, a custom response shape. MCP standardizes the handshake. A server declares the tools it offers and the shape of their inputs and outputs; a client discovers those tools at connection time and calls them in a uniform way. The important consequence for compliance is that the model stops being the source of truth and becomes the orchestrator . The model decides which tool to call and how to phrase the result; the tool returns real data from a real corpus. When you ask "what does the law say about X," a well-built MCP setup does not answer from the model's training memory. It calls a server that reads the actual provision and returns it. A single MCP server wraps one data source. One server for one country's legislation. One server for a CVE database. One for a security-framework catalog. That is the unit. It works well when your question lives entirely inside that one source. Why compliance breaks generic RAG and chat # Two failure modes, and both are disqualifying for audit-facing work. Hallucinated citations. A language model is a probability machine over text. It will write "Article 28(1)" or "C-311/18 Schrems II " because those tokens are statistically likely after your prompt, not because it checked. Retrieval-augmented generation helps — it puts real documents in the context window — but it does not eliminate the failure: the model can still mis-attribute a claim to the wrong chunk, cite a provision that was retrieved but does not support the point, or blend two sources into a citation that belongs to neither. We have watched models invent article numbers that are off by one from the correct provision, which is worse than a random number because it survives a casual sniff test. For most uses, a wrong citation is an annoyance. For a DPIA, a regulator-facing gap analysis, or an incident report under a breach-notification regime, a fabricated citation is the kind of error that destroys the credibility of the whole document. The breach-notification duty in GDPR Article 33, for instance, runs on a 72-hour clock — a report that mis-cites its own legal basis is not a defensible filing. No audit trail. The second failure is quieter and worse. Ask a generic assistant the same compliance question on Monday and on Thursday and you can get two different answers, two different sets of citations, two different risk conclusions. There is no record of which provision grounded which claim, no way to reproduce the answer a year later when an auditor asks why you concluded what you concluded. Compliance is not a one-shot question-answering task. It is a record you have to stand behind. "Our assistant said so" is not an answer a regulator accepts, and it is not an answer your own future self can reconstruct. These two problems are why we treat accuracy as strictly more important than availability. A compliance platform that sometimes guesses is worse than one that sometimes says "I can't ground that." We would rather return no answer than a wrong one. What a gateway adds over point MCP servers # A single MCP server solves the "read one corpus" problem. It does not solve the problems above, because real compliance questions almost never live in one corpus. A vendor-risk question touches data protection, network-and-information-security obligations, and often a sector regulator. A cross-border question spans several national legislations at once. Stitching together a dozen point servers by hand — handling auth for each, deciding which to call, merging and de-duplicating their answers, checking that the citations are real — is the work. The gateway is where we did that work once so you don't repeat it per question. Four layers sit on top of the downstream fleet. Routing. A single question rarely names its own sources. "Are we covered for this processing activity in Sweden?" has to be resolved into which corpora can answer it — Swedish law, EU regulation, the relevant sector regulator — before any server is called. The gateway reads the query, detects jurisdiction and framework and sector signals, and dispatches to the matching downstream MCPs. You ask one question; the gateway figures out the address book. Our fleet currently spans 57 routable law servers (from 119 built corpora, 29 audited live), a security-framework corpus with 262 frameworks, and an EU-regulations corpus of 102 instruments served at article level — far too many for a human to route by hand on every query. Fan-out. Coverage is the product. Most real obligations are not single-source. A gateway sends one logical question to many servers in parallel and merges the results into a single response, so a question that implicates GDPR, NIS2, and a national sector regulator returns all three in one answer rather than forcing you to ask three times and reconcile by hand. This is also where the multi-pass discipline lives: for any output that produces citations, the gateway evaluates the primary regime, then horizontal regimes, then the sector-specific routing, rather than answering from whichever corpus replied first. Tier auth. Not every caller should reach every tool or run unlimited queries. The Ansvar gateway authenticates via OAuth 2.1 and reads a tier claim from the token — free, solo, premium, team, company. The tier controls which tools appear in the tool list and how much quota each call draws. The free tier runs 100 searches a day against a single jurisdiction; Solo (€29/mo) opens multi-jurisdiction fan-out; Premium adds the premium corpora like case law and agency guidance plus the workflow and risk-scoring tools. Enforcement happens at the gateway, in one place, instead of being re-implemented per server. See /pricing for the tier matrix and /coverage for the full corpus inventory. Citation validation. This is the layer that makes the gateway a compliance tool rather than a convenience proxy. Every regulatory claim the gateway returns is anchored to a real provision in a real corpus, and the gateway validates citations deterministically: an article reference either resolves to a provision that exists and says what is claimed, or it does not. When it does not, the gateway refuses — it does not paper over the gap with model-generated text. A claim that cannot be grounded after all routing and fan-out passes is marked unresolved, not invented. That refusal discipline is the opposite of how a generic chatbot behaves, and it is the property an auditor cares about. How the layers fit together # mermaid Copy flowchart TB A[Your AI client
Claude / Copilot / Cursor] -->|OAuth 2.1 MCP| B[Gateway] B --> C{Routing:
detect jurisdiction,
framework, sector} C -->|tier check| D[Fan-out:
parallel calls to
matching MCPs] D --> E[Law MCP] D --> F[EU regulations] D --> G[Sector regulator] E & F & G --> H[Citation validation:
does this provision
exist and say this?] H -->|grounded| I[Cited answer
back to your agent] H -->|cannot ground| J[Marked unresolved
— no fabrication] Your client does the language work. The gateway does the routing, fan-out, auth, and validation. The downstream MCPs hold the data. The model never invents a citation, because the model never sources the citation — the corpus does. What stays on your side # A point worth making explicitly: there is no server-side model. The gateway does not run an LLM and does not forward your queries to a third-party model provider. Your own MCP client — Claude, Copilot in VS Code or Studio, Cursor, or any OAuth 2.1 MCP client — does the reasoning on your side and calls the gateway only for grounded data and workflow orchestration. The gateway and its corpora run on EU infrastructure (Hetzner). For a compliance team this matters for two reasons. Your prompts and documents are not handed to an outside model by us — your client controls that relationship. And the data residency story is simple: regulatory corpora and the routing layer stay in the EU. When you actually need a gateway # You do not always need one. The honest test: A single MCP server is enough when your question lives in exactly one corpus you already know — reading the text of one article in one country's legislation, or checking one CVE in one vulnerability database. One source, one server, no routing decision to make. You need a gateway the moment a question crosses corpora. Three patterns make this concrete: Cross-regime obligations. A vendor-management or incident-response question that touches data protection, NIS2, and a sector regulator at once. No single server holds the answer; routing and fan-out are the work. Cross-border questions. "How does this obligation differ across the four countries we operate in?" is a fan-out problem by definition — four corpora, one merged, cited answer. Citation-producing workflows. A gap analysis, a DPIA, a threat model, a tender review — anything whose output is a document that must carry validated citations from multiple sources. The validation layer is exactly what keeps that document audit-defensible. If you are running gap analysis , AI Act readiness , or STRIDE threat modeling against more than one framework, you are in gateway territory whether you build it yourself or use ours. Try it # If your AI client speaks MCP, connecting takes about two minutes. Point it at https://gateway.ansvar.eu/mcp , complete the OAuth 2.1 flow, and ask your agent a real compliance question — one that spans more than one regime, so the routing and fan-out earn their keep. The free tier gives you 100 searches a day against a single jurisdiction to feel out the citation behavior; Solo (€29 per month) opens multi-jurisdiction fan-out, and Premium (€249 per seat per month) adds the premium corpora. The quickstart walks through the client setup, and how it works covers the routing and citation layers in more depth. The thing to test first is the refusal behavior: ask a question the corpus genuinely cannot answer, and watch the gateway decline to fabricate a citation rather than oblige you with a confident wrong one. That refusal is the feature. It is the difference between a tool you can put in front of a regulator and a tool you cannot. On this page What MCP is, in one section Why compliance breaks generic RAG and chat What a gateway adds over point MCP servers How the layers fit together What stays on your side When you actually need a gateway Try it Frequently asked What is an MCP gateway? MCP (Model Context Protocol) is an open standard that lets an AI client call external tools and data sources in a uniform way. A single MCP server exposes one data source — say, one country's legislation. An MCP gateway sits in front of many MCP servers and presents them as one connection: it authenticates the caller, routes each query to the right downstream servers, fans a single question out to many sources in parallel, validates the citations that come back, and enforces per-tier quotas. Your AI client connects once and reaches the whole fleet instead of wiring up dozens of servers by hand. Why can't I just use ChatGPT or a RAG bot for compliance questions? Two reasons that matter for audit. First, a language model generates plausible text, including plausible-looking citations — article numbers and case references that do not exist or do not say what the model claims. For compliance work a fabricated citation is disqualifying. Second, neither a raw model nor a typical RAG pipeline gives you a reproducible, source-anchored trail: ask the same question twice and you can get two answers, with no record of which provision actually grounded each claim. A gateway forces every regulatory claim back to a real provision in a real corpus, and refuses the ones it cannot ground. When do I need a gateway instead of a single MCP server? Use a single MCP server when your question lives in exactly one corpus you already know — for example, reading the text of one article in one country's law. You need a gateway the moment a question crosses corpora: an obligation that touches GDPR, NIS2, and a sector regulator at once; a cross-border question spanning several jurisdictions; or any workflow whose output must carry validated citations from multiple sources. Routing, fan-out, and citation validation are exactly the parts you would otherwise rebuild by hand around every point server. Is the Ansvar gateway hosted in the EU? Yes. The gateway and its downstream corpora run on Hetzner infrastructure in the EU. There is no server-side model: the gateway does not run an LLM of its own and does not send your queries to a third-party model provider. Your own MCP client — Claude, Copilot, Cursor, or any OAuth 2.1 MCP client — does the language work on your side, and calls the gateway only for grounded regulatory data and workflow orchestration. --- ## Effective risk: turning the LLM-era CVE firehose into a triage queue you can actually work · Ansvar AI Blog URL: https://ansvar.eu/blog/effective-risk-cve-noise-llm-era AI tooling files more CVEs than any analyst can read. Effective-risk rescoring deterministically scores CVE × asset × controls, citing every score change. Vulnerability scanners used to emit a few dozen CVEs a week. Then the LLM-assisted reporters arrived — agentic pentesters, AI-assisted CVE triagers, supply-chain scanners that re-evaluate every dependency on every commit — and the weekly count went up an order of magnitude. The 2024 NVD backlog made it worse: thousands of CVEs sat unscored for months, then landed in one batch. The bottleneck is not finding vulnerabilities anymore. The bottleneck is deciding which of the ones you've already found actually matter for your systems. That is what effective-risk rescoring does. The one-paragraph mechanism # Take a CVE. Take a structured description of the asset it might affect — exposure, criticality, data classes, the controls actually in place. Run both through a deterministic rule engine that knows how to adjust the CVSS vector: a remote-code-execution CVE against an isolated, MFA-gated, WAF-fronted internal service is not the same risk as the same CVE against an internet-exposed unpatched edge box. The engine returns an effective score , every altered metric annotated with the rule that changed it, and a citation chain back to the framework or threat-intel source the rule encodes. Same input today and same input next quarter produce the same output. That is the property that makes it audit-defensible. Data flow # mermaid Copy flowchart LR A["Vulnerability scanners + AI reporters + NVD feed"] -->|CVE ID + base CVSS| B["Customer's MCP agent"] C["Asset description exposure / criticality data classes"] --> B D["Control evidence attested vs evidenced"] --> B B -->|effective_risk_inline_batch| E["Effective-risk engine"] E --> F{"Rule library evaluates CVE × asset × controls"} F -->|rule fires| G["Altered metric + citation"] F -->|no rule, gap detected| H["Context revision proposal ask analyst for X"] G --> I["Effective score + provenance chain"] H --> I I --> J["Ticket: suppress / escalate / request more info"] Every arrow is a contract, not a guess. The engine refuses to silently degrade — if a control claim cannot be evaluated, it says so and proposes the missing input. Why CVSS base scores alone do not work anymore # Four well-known problems, sharpened by the LLM-era volume: CVSS base is asset-agnostic. A 9.8 against an isolated lab box and a 9.8 against your customer-facing payments API are the same number. Your analyst has to write the difference in a comment, every time. CVSS temporal and environmental metrics are rarely populated. The vectors exist; the discipline of filling them in across thousands of vulnerabilities does not survive a real backlog. KEV listing changes the priority but not the base score. A medium that is actively exploited in the wild should outrank a non-KEV high. CVSS does not encode that ordering for you. Compensating controls are invisible. The fact that the affected service sits behind an authenticated reverse proxy with rate limits and request-body inspection is not in the CVE record. It is in your head, or your runbook, or nowhere. The engine encodes all four as rules. Each one fires deterministically against the inputs you give it, and each firing carries a citation to the framework or threat-intel record the rule derives from. What the numbers actually look like # A typical Patch-Tuesday dump lands ~120 new CVEs on a mid-sized engineering org. Run them through effective-risk rescoring against a realistic asset inventory — most services are not internet-exposed, most have at least two of the standard compensating controls in place, a chunk are not affected because the vulnerable component is not in the call path — and the queue collapses to ~12-15 that move the needle. Of those, two or three usually carry KEV-listed promotions that bump them above what their base CVSS would suggest. The ratio is the point. An analyst can work 12-15 well-scoped tickets with cited rationale in an afternoon. They cannot work 120 in a week. Why deterministic, not "just ask an LLM" # The temptation in 2026 is to feed the CVE plus a system description into a model and ask "is this exploitable here." That works for exploration. It fails for everything downstream: Audit. A regulator (DORA, NIS2, the insurer underwriting your cyber policy) will ask why you suppressed CVE-X against system-Y. "Our LLM said so on a Tuesday" is not a defensible answer. Reproducibility. The same input next quarter should produce the same score. LLMs do not guarantee that. Drift detection. When a rule changes — because a threat-intel source updated, because a control mapping moved — every score that depended on it can be re-run and the deltas reported. LLM outputs cannot be diffed cleanly. The customer-facing agent is the right place for the LLM. The scoring decision is the wrong place. Effective risk splits those concerns: your agent (Claude Desktop, Copilot Studio, Cursor, anything that speaks MCP) calls a deterministic engine, presents the cited result to the analyst, and helps them write the ticket. Two ways to invoke it # The engine is exposed through the Ansvar gateway as two tools, both gated to Team and Company tiers: effective_risk_inline — one CVE × one inline asset description × one set of controls. Use during a workflow when you already have the asset in the workflow frame. effective_risk_inline_batch — same shape, but up to 100 CVE IDs against the same asset. The Patch-Tuesday triage call. Both return the same result shape: effective_score , altered_metrics with rule provenance, applicable_controls showing which fired versus which did not, and — when the engine cannot decide without more input — a context_revision_proposed result class carrying specific proposals for what to ask the analyst next. No silent fallbacks. No fabricated reductions. For repeated scoring against the same asset over months (the audit-ledger use case), register the asset once via the persistent effective_risk tool. Each call then carries a stable scoring_context_id that anchors the audit trail. Where this lives in the gateway # Effective-risk rescoring is one of the gateway's first-class capabilities, alongside the workflow engine (threat modelling, gap analysis, DPIA), the architecture knowledge tools, and the document-citation surface. The same MCP agent that runs your STRIDE threat model can call the engine mid-walk to score the residual risk of each identified threat. The same agent that drafts your DORA gap analysis can re-score every open vulnerability against the article-level requirement it maps to. The product is not "another scoring tool." The product is deterministic risk reasoning, callable from the agent you already use, with citations every regulator already accepts. Try it # Tier requirement. The effective_risk_inline and effective_risk_inline_batch tools are gated to Team and Company subscriptions. Free and Premium tiers do not include them. See /pricing for the tier matrix. If your AI client speaks MCP and you are on Team or Company: Connect it to the gateway — https://gateway.ansvar.eu/mcp , OAuth 2.1, two-minute setup. Hand your agent a CVE list and an asset description and ask: "Use the Ansvar gateway to compute effective risk for each of these CVEs against this asset, and tell me which ones I can suppress." The agent calls effective_risk_inline_batch , returns the rescored list with rule citations, and you triage the short tail. The mechanism is deterministic by design: the rules are versioned, every score carries the rule citations it fired on, and the same inputs always produce the same score — so a reviewer can trace any score back to the exact rules and asset facts behind it. The asymmetry is on your side: an attacker can generate more CVEs against you than you can read. A deterministic engine that suppresses the inapplicable ones with cited reasoning is how you keep the queue workable without hiring a second triage team. On this page The one-paragraph mechanism Data flow Why CVSS base scores alone do not work anymore What the numbers actually look like Why deterministic, not "just ask an LLM" Two ways to invoke it Where this lives in the gateway Try it Frequently asked What does effective-risk rescoring replace in our existing stack? It doesn't replace your scanner — Tenable, Rapid7, Qualys, GitHub Dependabot, Snyk all still feed in the CVEs they find. It replaces the spreadsheet (or the analyst hour) where someone re-reads the CVSS vector against your asset's actual exposure, criticality, and compensating controls and writes 'not exploitable here, suppress' in the ticket. Every suppression decision becomes a deterministic, cited rule-firing instead of a tribal-knowledge note that leaves with the person who wrote it. How is this different from an LLM that just summarises CVEs? An LLM produces a different answer every time you ask. An effective-risk engine produces the same answer every time, traceable to a specific rule firing with a citation. For audit, insurance, and regulator-facing work, that determinism is the product — a customer can run the same CVE × asset × controls input through the engine a year later and reproduce the score. LLMs are how the customer's agent asks the question; the engine is what answers. What input do we need to provide? Per CVE, four required slots: asset name, asset exposure (internet / internal / isolated), asset criticality (low / medium / high / critical), plus a list of compensating controls (with whether each is attested-by-engineer or evidenced-by-tool). Components, data classes, and data sensitivity are optional but improve the score. Most workflows fill these from a system description in the workflow frame — no separate asset registry needed for one-shot scoring. For repeated scoring against the same asset, register the context once. --- ## How we threat-model AI systems: STRIDE meets MCP · Ansvar AI Blog URL: https://ansvar.eu/blog/how-we-threat-model-ai-with-mcp STRIDE was built for 1999 monoliths. How we adapted it for agentic systems and shipped it as a workflow your own AI client runs through the Ansvar gateway. We threat-model every change that crosses a trust boundary. That's a high bar when you operate an MCP gateway that fans out to 224 downstream servers spanning legal corpora built for 119 jurisdictions — but the alternative is shipping security-debt that compounds at the speed of LLM tool calls. This is how we actually do it. The same workflow your AI agent can drive end-to-end through the gateway. Why STRIDE needed adapting # STRIDE was Microsoft's 1999 framework for desktop and monolithic web apps. The six categories — S poofing, T ampering, R epudiation, I nformation Disclosure, D enial of Service, E levation of Privilege — were defined when a "data flow" was a function call across a process boundary, and an "external entity" was a human at a keyboard. For an MCP system, the data flow looks nothing like that: mermaid Copy flowchart TB A[Customer's AI client] -->|OAuth-authenticated MCP| B[Gateway] B --> C{Routing decision} C -->|1 of 176 MCPs| D[Fan-out: 5–50 parallel calls] D --> E[Upstream regulator] D --> F[Law database] D --> G[Sector MCP] E & F & G --> H[Gateway parses + cites] H --> I[LLM synthesizes] I --> J[Customer sees a cited answer] Every arrow is a potential threat boundary. Most of them weren't in scope when STRIDE was written. Our adapted category definitions # We rewrote the six categories to mean what they need to mean for an agent-based system: Category Classical meaning What it means for an MCP gateway S — Spoofing Pretending to be another user Pretending to be another tool in the tool list, or another agent in a multi-agent workflow T — Tampering Modifying data in transit Prompt injection in upstream content that hijacks the orchestrating LLM R — Repudiation "I didn't do that" An agent action with no audit trail back to the customer who triggered it I — Info Disclosure Leaking sensitive data Context-window leakage across tenants when the same LLM context is reused D — Denial of Service Service unavailable Quota exhaustion on a single tool causing cascade failure across the fan-out E — Elevation of Privilege Becoming admin A free tier customer reaching a company tier tool via tool-list pollution The mapping isn't 1:1 — and that's the point. Each row encodes a real incident class we've either had to fix or watch competitors get hit with. Running STRIDE through the gateway — step by step # This is the actionable bit. The same workflow runs whether you're using Claude Desktop, Copilot Studio, Cursor, or a custom MCP client. The shape below is captured from the live gateway, not from documentation. 0. Connect once # Point your MCP client at https://gateway.ansvar.eu/mcp . OAuth 2.1 with Dynamic Client Registration — paste the URL, sign in, your client sees the gateway's ~25 tools. Full setup walkthroughs for each client live at /setup . 1. Start the workflow # Ask your agent to run a STRIDE threat model. Under the hood it makes one tool call: text Copy start_workflow( workflow_type="threat_model", entity_description="Payments API: PCI-DSS scope, processes ~500k tx/day, deployed on AWS Fargate behind ALB. New SDK exposes a delegated-payment endpoint to partner agents." ) Three real prompt shapes that all hit this same tool — pick whichever fits your client: text Copy # Natural language — agent picks the workflow "Run a STRIDE threat model on our payments API. Here's the design doc." # Direct MCP tool call @ansvar-gateway start_workflow workflow_type=threat_model entity_description="..." # Slash-command form (Claude Desktop with the Ansvar prompt pack) /ansvar:threat_model The gateway returns a workflow_id (UUID). Save it — if your OAuth token expires mid-walk (the typical walk is 2–4 hours), you re-authenticate and call resume_workflow(workflow_id=...) to pick up exactly where you stopped. Server-side state persists. 2. Stage 1 — System scoping # The agent calls get_current_step(workflow_id) and gets back this prompt verbatim: Describe the system to be threat modeled: its purpose, main components, technologies used, and deployment environment. What are the key assets or data that need protection? The required-fields contract is just two slots: system_description and key_assets . The agent presents these to you as a form, fills them from your design doc, and submits with submit_response(workflow_id, step_id="scoping.system_description", responses={...}, user_acknowledged=true) . 3. Stage 2 — DFD generation # This is where the gateway earns its keep. Stage 2 prompt: Invoke /threat-modeler-dfd with the system description and any uploaded documents. Submit the returned artifact: components, data_flows, trust_boundaries, assets, plus the dfd_mermaid render and any structural_warnings. /threat-modeler-dfd is a dedicated MCP prompt that produces a structured DFD from your scope: a list of components, data flows between them, the trust boundaries those flows cross, the assets at each component, and a Mermaid diagram you can paste straight into a PR. Required fields for this stage: components, data_flows, trust_boundaries, assets, dfd_mermaid . The workflow's quality gate refuses to advance if any is missing — no half-built DFDs leak through to the STRIDE walk. 4. Stage 3 — Per-boundary STRIDE walk # For every trust boundary the DFD identified, the workflow walks through the six STRIDE categories. For each (boundary × category) pair the agent fills: Threat description — the specific attack that fits this category at this boundary Likelihood and consequence scores, on the bands the workflow is configured to use ( severity_levels is one of the overridable_configurable settings — defaults are low/medium/high/critical , but you can override per assessment) Existing mitigations — controls already in place that reduce likelihood or consequence Residual risk after those mitigations Citation evidence — gateway searches the security-frameworks MCP for STRIDE source + the threat-stripes corpus for similar incidents If the boundary is "free-text input from a partner agent crosses into the payment-orchestration LLM," the gateway will surface prompt-injection mitigations from OWASP's LLM Top 10, fold in any case-law on similar incident classes (premium tier), and rank by relevance. 5. Stage 4 — Scoring + refusal modes # Each threat with residual_risk >= severity_levels.high gets a refusal-mode entry: what does the system return when this threat fires? An exception with a clear error code? A degraded response? Silent success? Silent success is the worst answer and it's almost always the default if you don't think about it. The workflow forces you to think about it. 6. Stage 5 — Report # generate_report(workflow_id) re-resolves every citation (paragraph-hash drift check, per our citation contract ), assembles the threat table, scores aggregated risk, and outputs: A cited threat model in your tier's redaction schema The DFD Mermaid you can drop into the design doc A treatment_plan linking each high-residual threat to a planned mitigation A GRC-ready export (CSV + JSON) keyed for ISO 27001 A.5–A.18 mapping if you provided that framework Inspecting what came out # While the walk is in progress (or after generate_report completes), you can introspect: text Copy get_workflow_threats(workflow_id="e7d60b1f-...") …to get back the threats with severity ratings and recommended mitigations identified so far. Useful for filtering to high-residual threats only before a steering review. What's configurable # Pulled from the gateway's list_workflow_types response — the knobs that ship today for threat_model : Override What it controls Default threat_categories The mnemonic set walked per boundary STRIDE (6 categories) severity_levels Bands for likelihood / consequence scoring low / medium / high / critical You set overrides at start_workflow time. For more invasive change (different mnemonic, e.g. STRIDE-LM that adds Lateral Movement), the right path is to fork the workflow YAML in ansvar-workflow-mcp and submit a PR — the workflow definitions are public. LINDDUN — the privacy threat model # LINDDUN is a separate base workflow ( workflow_type="linddun" ), not a variant of STRIDE. Same stage shape, different question set: L inkability — can two pieces of data be associated to the same person? I dentifiability — can the data be tied to a specific individual? N on-repudiation — can the user deny an action they took? D etectability — can an outside observer infer that data exists at all? D isclosure of information — can data be exposed beyond the intended recipient? U nawareness — does the user know what data is being processed and why? N on-compliance — is the processing lawful, proportionate, documented? Stage 1's prompt asks for the system description plus any ROPA (Record of Processing Activities) you have — the privacy framing pulls in different upstream evidence than STRIDE's security framing. Configurable: linddun_categories and harm_bands — the privacy harm taxonomy used to score severity differs from STRIDE's severity_levels because privacy harm and security severity aren't the same dimension. Invoke it the same way as STRIDE — your agent calls start_workflow(workflow_type="linddun", entity_description=...) and walks the same get_current_step → submit_response loop. Recommended for DPIAs that go beyond Article 35 checkboxes — the ones an auditor will actually read. TARA — UNECE R155 / ISO 21434 automotive cyber # TARA (Threat Analysis and Risk Assessment) for automotive isn't a separate workflow type — it's the same threat_model workflow with the UNECE R155 control catalog plugged in via the framework parameter: text Copy start_workflow( workflow_type="threat_model", framework="unece_r155", entity_description="ECU + telematics gateway, type-approval target market: EU + UK" ) The gateway loads workflows/controls/unece_r155.yaml from the workflow MCP — 11 R155 controls covering CSMS requirements (7.2.1–7.2.5) and per-vehicle-type requirements (7.3.1–7.3.6). The per-control walk in stage 3 then iterates R155's controls instead of STRIDE's six, fetching ISO 21434 mappings, type-approval guidance from the relevant authority MCPs (KBA for German OEMs, RDW for Dutch, VCA for UK), and any case-law on similar incident classes. You can also combine — framework=unece_r155 plus a custom threat_categories override gets you STRIDE-LM-flavored questions per R155 control. For ISO 21434 Annex E feasibility scoring, override severity_levels to ["very_low", "low", "medium", "high", "very_high"] to match the standard's bands. Frameworks you can plug into threat_model and gap_analysis today # Pulled from workflows/controls/ in the workflow MCP: framework= Catalog Best paired with stride (default) 6 STRIDE categories threat_model unece_r155 11 R155 controls — automotive CSMS + vehicle type threat_model (TARA) nis2 NIS2 Annex I + II controls gap_analysis dora DORA Articles 5–24 ICT-risk controls gap_analysis cra EU Cyber Resilience Act essential requirements gap_analysis New catalogs land in workflows/controls/*.yaml — adding one is a YAML PR, not a code change. What AI adds that STRIDE didn't anticipate # Three threat classes that didn't exist when STRIDE was written. We treat them as first-class STRIDE categories in the workflow, not afterthoughts: Prompt injection as a first-class threat # Any upstream content the LLM reads is attacker-controlled if the publisher is untrusted. For an MCP that ingests EU regulator data, the publisher is trusted (vetted source-authority registry). For an MCP that scrapes random PDFs a customer uploads, the publisher is the customer's adversary , not the customer. Mitigation pattern: structural isolation between content the LLM reasons about and instructions the LLM follows . The gateway never passes raw upstream text into the system prompt. Tool results are sandboxed in a tool-result block the LLM treats as data. Citation fabrication # If your model generates citations from training data instead of tool results, you have a fabrication threat. We mitigate with a deterministic grounding ratio check ( GROUNDING_MIN_RATIO=0.4 ) that hard-refuses below threshold. This is a hard failure, not a soft degradation — see our no-silent-fallbacks rule. Fan-out blast radius # A single customer query can fan out to 50+ downstream MCPs. If one of those MCPs is compromised (or just buggy), the bad data lands in the answer the LLM synthesizes. We mitigate per-MCP envelope validation at the gateway, plus a contract test that asserts each MCP's _citation shape on every PR merge. How we publish what we find # Public threat models live at ansvar.eu/security . Per-feature models live in ADR-prefixed design docs in our architecture-documentation repo. Every customer-tier threat model is a workflow output in the gateway, not a PDF we email — so the next time the threat surface changes, the threat model regenerates with citations. That's the asymmetric advantage of building threat models inside the platform you're modeling: the model and the system stay in sync because they share the source. Try it yourself # Tier requirement. The start_workflow / submit_response / generate_report lifecycle is on every tier. What differs is the workflow type and the monthly run allowance: Free runs 1 STRIDE threat model a month and Solo 2, both on a system you describe with the report returned as JSON; Premium runs 5 and adds LINDDUN, TARA and the rendered exports; Team and Company run 20 per seat a month and add document grounding. See /pricing for the tier matrix. If you have an MCP-capable client and a run left this month: Connect it to the gateway — https://gateway.ansvar.eu/mcp , OAuth 2.1 + Dynamic Client Registration, two-minute setup Ask your agent: "Use the Ansvar gateway to run a STRIDE threat model on this data-flow diagram." The agent calls start_workflow(workflow_type="threat_model", entity_description=...) , captures the workflow_id, and walks you through scoping → DFD → per-boundary STRIDE → scoring → report. For LINDDUN , swap "STRIDE" for "LINDDUN privacy" in the prompt — the agent picks workflow_type="linddun" automatically. For TARA , ask for "TARA per UNECE R155" — the agent calls start_workflow(workflow_type="threat_model", framework="unece_r155", ...) . The Ansvar gateway exposes 12 workflow types today (8 base + 4 jurisdictional variants) plus 5 control-catalog frameworks you can plug in; your agent's list_workflow_types call shows the full menu. Want to read more? # Cluster topics on the slate: LINDDUN deep-dive: practical privacy threat modeling for agent systems DPIA-DE vs. DPIA-SE: what jurisdictional variant overlays actually change DORA digital-operational-resilience testing without breaking prod The audit-ledger pattern: cryptographic audit trails for AI tool calls How we map regulatory citations across 119 jurisdictions without duplicating work Subscribe to the RSS feed , or connect the Ansvar gateway to your AI client and ask it to summarize the latest post. On this page Why STRIDE needed adapting Our adapted category definitions Running STRIDE through the gateway — step by step 0. Connect once 1. Start the workflow 2. Stage 1 — System scoping 3. Stage 2 — DFD generation 4. Stage 3 — Per-boundary STRIDE walk 5. Stage 4 — Scoring + refusal modes 6. Stage 5 — Report Inspecting what came out What's configurable LINDDUN — the privacy threat model TARA — UNECE R155 / ISO 21434 automotive cyber Frameworks you can plug into threat_model and gap_analysis today What AI adds that STRIDE didn't anticipate Prompt injection as a first-class threat Citation fabrication Fan-out blast radius How we publish what we find Try it yourself Want to read more? Frequently asked How do I actually run a STRIDE threat model through Ansvar? Connect your MCP client (Claude Desktop, Copilot Studio, Cursor, or any OAuth 2.1 MCP client) to gateway.ansvar.eu, then ask your agent to start a STRIDE threat model. The agent invokes the gateway's start_workflow tool with workflow_type='threat_model', captures the returned workflow_id, and walks you through the stages — system scope, DFD generation, per-boundary STRIDE walk, severity scoring, mitigations — calling submit_response between each. A typical walk is 2-4 hours. Resume any time with the workflow_id. Does STRIDE still work for AI systems? Yes, but five of the six categories shift meaning when the data flow is agent → MCP → tool → upstream source. Tampering becomes prompt injection; Information Disclosure becomes context-window leakage; Elevation of Privilege becomes tool-permission escalation across the fan-out. What's the difference between threat_model, linddun, and TARA in the gateway? threat_model is STRIDE — security threats by element — and is also the workflow type for TARA: same workflow with framework='unece_r155' loads the UNECE R155 control catalog instead of STRIDE's six. linddun is a separate base workflow for privacy threats (Linkability/Identifiability/Non-repudiation/Detectability/Disclosure/Unawareness/Non-compliance). All three share the same scoping → DFD → per-element walk → scoring shape, but the question set and upstream enrichment differ per framework. What's different about modeling an MCP gateway versus a REST API? Three things: (1) the tool list is discovered dynamically per session, so the threat surface is enumerated at runtime, not at design time; (2) one logical user request can fan out to 50+ downstream tools, so blast radius is multiplicative; (3) the LLM is both the orchestrator and an untrusted parser of upstream content. Do you publish your threat models? The infrastructure threat model is public at ansvar.eu/security. Per-feature models live in ADR-prefixed design docs in the architecture-documentation repo. Customer-tier threat models are workflow outputs in the gateway, not PDFs — they regenerate from source when the threat surface changes. --- ## Denmark Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/denmark Audited, citable Danish legislation — 62,764 laws, 621,260 provisions. Via the Ansvar MCP gateway. Coverage Denmark Danish law, machine-readable and cited The audited Danish legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 62,764 Provisions 621,260 Source license DK-Statutory-PD Region Nordics About this corpus Ansvar's Danish coverage is a machine-readable corpus of 62,764 consolidated Danish laws and 621,260 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Denmark is part of Ansvar's Nordics coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Danish provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Databeskyttelsesloven § 1 Danish practice cites the act by its short name plus a flat § number. Behind the name sits a Lovtidende identifier — the official ELI path (eli/lta/2018/502) encodes year and number in Lovtidende A — and Retsinformation serves the act as published there, which the gateway links to. Denmark issues consolidations as separate lovbekendtgørelser with their own numbers. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Danish legal evidence: Court decisions — Danish case law from the Danish Court Administration (Domstolsstyrelsen), fanned into gateway search results on Premium and above. Official sources we ingest from Retsinformation — official Danish legal information system Statutory text is served under the DK-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Denmark corpus is served from EU infrastructure under the DK-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Finland Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/finland Audited, citable Finnish legislation — 8,586 laws, 161,785 provisions. Via the Ansvar MCP gateway. Coverage Finland Finnish law, machine-readable and cited The audited Finnish legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 8,586 Provisions 161,785 Source license FI-Statutory-PD Region Nordics About this corpus Ansvar's Finnish coverage is a machine-readable corpus of 8,586 consolidated Finnish laws and 161,785 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Finland is part of Ansvar's Nordics coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Finnish provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Tietosuojalaki (1050/2018) 3 § Finnish statutes are identified by a running number and year — 1050/2018 — and cite sections with the § AFTER the number (3 §), the reverse of German practice. The fetched provision opens exactly that way. Finlex serves the consolidated text the gateway links to. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Finnish legal evidence: Court decisions — Finnish case law from Finlex (Edita Publishing Oy / Ministry of Justice), fanned into gateway search results on Premium and above. Preparatory works — Government bills and committee reports from Finlex open data, on Premium and above — the drafting record Finnish interpretation reaches for when statute text alone does not settle a question. Official sources we ingest from Finlex — official legal databank of Finland Statutory text is served under the FI-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Finland corpus is served from EU infrastructure under the FI-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Sweden Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/sweden Audited, citable Swedish legislation — 6,045 laws, 59,064 provisions. Via the Ansvar MCP gateway. Coverage Sweden Swedish law, machine-readable and cited The audited Swedish legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 6,045 Provisions 59,064 Source license SE-Statutory-PD Region Nordics About this corpus Ansvar's Swedish coverage is a machine-readable corpus of 6,045 consolidated Swedish laws and 59,064 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Sweden is part of Ansvar's Nordics coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Swedish provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here 3 kap. 12 § SFS 1998:808 Chapter 3, Section 12 of Miljöbalken. The SFS number (year:number) identifies the statute and never changes; chaptered acts cite chapter and section (3 kap. 12 §), flat statutes a bare section (34 §). The gateway builds this citation from the structured reference and links it to the official Riksdagen page. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Swedish legal evidence: Court-decision summaries — 12,000+ summaries from ten-plus courts — including the Supreme Court, the Labour Court, and the Supreme Administrative Court — with Swedish originals reaching back to 1981. Preparatory works (förarbeten) — 6,735 documents. The drafting record Swedish legal interpretation leans on when the statute text alone does not settle a question. Official sources we ingest from Riksdagen open data — Svensk författningssamling (SFS), consolidated statute text Statutory text is served under the SE-Statutory-PD source licence, with per-item source attribution on every result. Where this shows up The Swedish corpus is part of the working coverage on these field pages: Public sector Privacy & data protection AI governance Healthcare & medical devices Energy & utilities EU-hosted, licensing-audited — the Sweden corpus is served from EU infrastructure under the SE-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Iceland Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/iceland Audited, citable Icelandic legislation — 1,710 laws, 19,033 provisions. Via the Ansvar MCP gateway. Coverage Iceland Icelandic law, machine-readable and cited The audited Icelandic legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 1,710 Provisions 19,033 Source license Icelandic-Statutory-PD Region Nordics About this corpus Ansvar's Icelandic coverage is a machine-readable corpus of 1,710 consolidated Icelandic laws and 19,033 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Iceland is part of Ansvar's Nordics coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Icelandic provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here 3. gr. laga nr. 90/2018 Icelandic statutes cite the grein (gr.) within an act numbered by year — lög nr. 90/2018 is act No. 90 of 2018. Alþingi's statute database serves the consolidated text, and the gateway's link anchors on the exact article. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Icelandic legal evidence: Court decisions — Icelandic case law from the courts' publication service (Dómstólar / Stafrænt Ísland), fanned into gateway search results on Premium and above. Official sources we ingest from Alþingi — Lagasafn, the Icelandic statute database Statutory text is served under the Icelandic-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Iceland corpus is served from EU infrastructure under the Icelandic-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Norway Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/norway Audited, citable Norway legislation — 739 laws, 29,222 provisions. Via the Ansvar MCP gateway. Coverage Norway Norway law, machine-readable and cited The audited Norway legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 739 Provisions 29,222 Source license NLOD-2.0 Region Nordics About this corpus Ansvar's Norway coverage is a machine-readable corpus of 739 consolidated Norway laws and 29,222 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Norway is part of Ansvar's Nordics coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Norway provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here LOV-2018-06-01-24 § 3-5 Norwegian acts carry a date-and-serial identifier — LOV-2018-06-01-24 is the act of 1 June 2018 No. 24 — and many number sections by chapter, so § 3-5 is chapter 3, section 5. Lovdata publishes the consolidated text under the Norwegian Licence for Open Government Data. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from Lovdata — official publisher of Norsk Lovtidend Statutory text is served under the NLOD-2.0 source licence, with per-item source attribution on every result. Where this shows up The Norway corpus is part of the working coverage on these field pages: Energy & utilities EU-hosted, licensing-audited — the Norway corpus is served from EU infrastructure under the NLOD-2.0 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Austria Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/austria Audited, citable Austrian legislation — 5,101 laws, 56,760 provisions. Via the Ansvar MCP gateway. Coverage Austria Austrian law, machine-readable and cited The audited Austrian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 5,101 Provisions 56,760 Source license AT-Statutory-PD Region DACH About this corpus Ansvar's Austrian coverage is a machine-readable corpus of 5,101 consolidated Austrian laws and 56,760 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Austria is part of Ansvar's DACH coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Austrian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here § 59 DSG Austrian federal statutes are typically cited by the section sign within the named act. The Datenschutzgesetz has a quirk the fetched reference makes visible: its constitutional-rank guarantee sits in Artikel 1, and the operative sections in Artikel 2 — so the gateway resolves § 59 as Artikel 2 § 59. Statutes resolve on RIS, the federal legal information system. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Austrian legal evidence: Court decisions — Austrian case law from RIS — the same federal system that publishes the statutes — fanned into gateway search results on Premium and above. Official sources we ingest from RIS — Rechtsinformationssystem des Bundes, consolidated federal law Statutory text is served under the AT-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Austria corpus is served from EU infrastructure under the AT-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Germany Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/germany Audited, citable German legislation — 4,753 laws, 92,295 provisions. Via the Ansvar MCP gateway. Coverage Germany German law, machine-readable and cited The audited German legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 4,753 Provisions 92,295 Source license German-UrhG-Section-5 Region DACH About this corpus Ansvar's German coverage is a machine-readable corpus of 4,753 consolidated German laws and 92,295 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Germany is part of Ansvar's DACH coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching German provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here § 26 BDSG German statutes put the section sign first and subdivide by Absatz (§ … Abs. …) — the mirror image of the Swedish chapter-first order. § 26 BDSG is the employee-data provision of the Bundesdatenschutzgesetz, the federal overlay on GDPR. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add German legal evidence: Court decisions — Federal case law from Rechtsprechung im Internet (Bundesministerium der Justiz), fanned into gateway search results on Premium and above. Official sources we ingest from gesetze-im-internet.de — federal statutes, Bundesministerium der Justiz Statutory text is served under the German-UrhG-Section-5 source licence, with per-item source attribution on every result. Where this shows up The German corpus is part of the working coverage on these field pages: AI governance Privacy & data protection Healthcare & medical devices Public sector Energy & utilities EU-hosted, licensing-audited — the Germany corpus is served from EU infrastructure under the German-UrhG-Section-5 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Belgium Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/belgium Audited, citable Belgian legislation — 5,778 laws, 143,390 provisions. Via the Ansvar MCP gateway. Coverage Belgium Belgian law, machine-readable and cited The audited Belgian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 5,778 Provisions 143,390 Source license BE-Federal-Statutory-PD Region Benelux About this corpus Ansvar's Belgian coverage is a machine-readable corpus of 5,778 consolidated Belgian laws and 143,390 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Belgium is part of Ansvar's Benelux coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Belgian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Loi du 30 juillet 2018, art. 202 Belgian federal acts are identified by their promulgation date rather than a running statute number. The federal ELI path encodes that date (loi/2018/07/30/…), so a citation resolves on the Justel database at ejustice.just.fgov.be — in French and Dutch parallel versions — down to the article anchor. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Belgian legal evidence: Court decisions — Belgian Constitutional Court case law (Cour constitutionnelle / Grondwettelijk Hof), fanned into gateway search results on Premium and above. Official sources we ingest from ejustice.just.fgov.be — Justel, consolidated federal legislation Statutory text is served under the BE-Federal-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Belgium corpus is served from EU infrastructure under the BE-Federal-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Luxembourg Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/luxembourg Audited, citable Luxembourg legislation — 4,554 laws, 36,098 provisions. Via the Ansvar MCP gateway. Coverage Luxembourg Luxembourg law, machine-readable and cited The audited Luxembourg legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 4,554 Provisions 36,098 Source license LO-OL-Luxembourg Region Benelux About this corpus Ansvar's Luxembourg coverage is a machine-readable corpus of 4,554 consolidated Luxembourg laws and 36,098 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Luxembourg is part of Ansvar's Benelux coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Luxembourg provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Loi du 19 décembre 2025 (JO A n° 620), art. 2 Luxembourg identifies acts by promulgation date plus their Journal officiel A-series number — the Legilux ELI path encodes both (loi/2025/12/19/a620). Articles are cited within the dated act, and the gateway links the official journal publication. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from Legilux — Journal officiel du Grand-Duché de Luxembourg Statutory text is served under the LO-OL-Luxembourg source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Luxembourg corpus is served from EU infrastructure under the LO-OL-Luxembourg source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Netherlands Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/netherlands Audited, citable Dutch legislation — 3,254 laws, 78,001 provisions. Via the Ansvar MCP gateway. Coverage Netherlands Dutch law, machine-readable and cited The audited Dutch legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 3,254 Provisions 78,001 Source license Dutch-Auteurswet-Art-11 Region Benelux About this corpus Ansvar's Dutch coverage is a machine-readable corpus of 3,254 consolidated Dutch laws and 78,001 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Netherlands is part of Ansvar's Benelux coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Dutch provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Artikel 27 WOR (BWBR0002747) Dutch statutes are cited by article. Every act carries a stable BWBR identifier on the official register, so a citation resolves straight to the consolidated text on wetten.overheid.nl — here, the works-council consent requirement in the Wet op de ondernemingsraden. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Dutch legal evidence: Court decisions — Dutch case law from De Rechtspraak — including the procurement judgments Dutch courts actually cite behind the Aanbestedingswet 2012 corpus — fanned into gateway search results on Premium and above. Preparatory works — Parliamentary papers via officielebekendmakingen.nl, on Premium and above. Official sources we ingest from wetten.overheid.nl — official consolidated statute register Statutory text is served under the Dutch-Auteurswet-Art-11 source licence, with per-item source attribution on every result. Where this shows up The Dutch corpus is part of the working coverage on these field pages: Public sector EU-hosted, licensing-audited — the Netherlands corpus is served from EU infrastructure under the Dutch-Auteurswet-Art-11 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Spain Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/spain Audited, citable Spanish legislation — 12,183 laws, 298,241 provisions. Via the Ansvar MCP gateway. Coverage Spain Spanish law, machine-readable and cited The audited Spanish legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 12,183 Provisions 298,241 Source license Spanish-TRLPI-Art-13 Region Iberia About this corpus Ansvar's Spanish coverage is a machine-readable corpus of 12,183 consolidated Spanish laws and 298,241 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Spain is part of Ansvar's Iberia coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Spanish provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here art. 37 LOPDGDD Spanish statutes are cited by artículo within an act known by rank, number and year — the LOPDGDD is Ley Orgánica 3/2018, and the BOE's ELI path encodes exactly that (lo/2018/12/05/3). The gateway links the consolidated BOE text with the article anchor. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from BOE — Boletín Oficial del Estado, consolidated legislation Statutory text is served under the Spanish-TRLPI-Art-13 source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Spain corpus is served from EU infrastructure under the Spanish-TRLPI-Art-13 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Portugal Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/portugal Audited, citable Portuguese legislation — 1,130 laws, 81,012 provisions. Via the Ansvar MCP gateway. Coverage Portugal Portuguese law, machine-readable and cited The audited Portuguese legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 1,130 Provisions 81,012 Source license Portuguese-CDADC-Art-7-and-8 Region Iberia About this corpus Ansvar's Portuguese coverage is a machine-readable corpus of 1,130 consolidated Portuguese laws and 81,012 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Portugal is part of Ansvar's Iberia coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Portuguese provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Artigo 9.º da Lei n.º 34/2009, de 14 de Julho Portuguese statutes are cited by artigo — written with the ordinal marker, 9.º — within an act identified by number, year and its Diário da República publication date. The Diário da República is the official journal the corpus ingests from. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from Diário da República — official journal of Portugal Statutory text is served under the Portuguese-CDADC-Art-7-and-8 source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Portugal corpus is served from EU infrastructure under the Portuguese-CDADC-Art-7-and-8 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## San Marino Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/san-marino Audited, citable Sammarinese legislation — 10,992 laws, 104,807 provisions. Via the Ansvar MCP gateway. Coverage San Marino Sammarinese law, machine-readable and cited The audited Sammarinese legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 10,992 Provisions 104,807 Source license SM-Statutory-PD-Art-98 Region Med + France About this corpus Ansvar's Sammarinese coverage is a machine-readable corpus of 10,992 consolidated Sammarinese laws and 104,807 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. San Marino is part of Ansvar's Med + France coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Sammarinese provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the San Marino corpus is served from EU infrastructure under the SM-Statutory-PD-Art-98 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Malta Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/malta Audited, citable Maltese legislation — 5,009 laws, 56,516 provisions. Via the Ansvar MCP gateway. Coverage Malta Maltese law, machine-readable and cited The audited Maltese legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 5,009 Provisions 56,516 Source license MT-CDSM-Art-4-TDM-PSI Region Med + France About this corpus Ansvar's Maltese coverage is a machine-readable corpus of 5,009 consolidated Maltese laws and 56,516 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Malta is part of Ansvar's Med + France coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Maltese provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here S.L. 545.42, reg. 10 Maltese law numbers principal acts as Chapters (Kap.) and subsidiary legislation as S.L. chapter-point-serial — S.L. 545.42 is the 42nd instrument under Chapter 545. Regulations instruments are cited by regulation (principal Acts by article), and Malta's official register serves both language versions under an ELI path the gateway resolves. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from legislation.mt — Laws of Malta, official register Statutory text is served under the MT-CDSM-Art-4-TDM-PSI source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Malta corpus is served from EU infrastructure under the MT-CDSM-Art-4-TDM-PSI source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## France Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/france Audited, citable French legislation — 3,958 laws, 193,793 provisions. Via the Ansvar MCP gateway. Coverage France French law, machine-readable and cited The audited French legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 3,958 Provisions 193,793 Source license FR-Etalab-2.0 Region Med + France About this corpus Ansvar's French coverage is a machine-readable corpus of 3,958 consolidated French laws and 193,793 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. France is part of Ansvar's Med + France coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching French provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here art. 106, loi n° 78-17 (Informatique et Libertés) French statutes are cited by article within an act numbered year-serial — loi n° 78-17 is the 17th law of 1978, the Informatique et Libertés act that still frames French data-protection law. On Légifrance every text carries a stable JORFTEXT or LEGITEXT identifier, which is what the gateway resolves. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add French legal evidence: Court decisions — French case law from DILA — the Direction de l'information légale et administrative behind Légifrance — fanned into gateway search results on Premium and above. Preparatory works — Legislative dossiers from DILA, on Premium and above. Official sources we ingest from Légifrance — official consolidated legislation Statutory text is served under the FR-Etalab-2.0 source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the France corpus is served from EU infrastructure under the FR-Etalab-2.0 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Czechia Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/czechia Audited, citable Czech legislation — 45,899 laws, 461,571 provisions. Via the Ansvar MCP gateway. Coverage Czechia Czech law, machine-readable and cited The audited Czech legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 45,899 Provisions 461,571 Source license Czech-Statutory-PD Region Central Europe + V4 About this corpus Ansvar's Czech coverage is a machine-readable corpus of 45,899 consolidated Czech laws and 461,571 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Czechia is part of Ansvar's Central Europe + V4 coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Czech provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here § 29 zákona č. 110/2019 Sb. Czech statutes are cited by section within an act identified by collection number and year — zákon č. 110/2019 Sb. is act No. 110 of 2019 in the Sbírka zákonů. The official e-Sbírka — the electronic Collection of Laws — encodes the same identifier as an ELI path (eli/cz/sb/2019/110), and the gateway's link jumps straight to the § anchor. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Czech legal evidence: Court decisions — Czech case law published by the Ministry of Justice, fanned into gateway search results on Premium and above. Official sources we ingest from e-Sbírka — official electronic collection of laws Statutory text is served under the Czech-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Czechia corpus is served from EU infrastructure under the Czech-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Croatia Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/croatia Audited, citable Croatian legislation — 4,511 laws, 161,423 provisions. Via the Ansvar MCP gateway. Coverage Croatia Croatian law, machine-readable and cited The audited Croatian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 4,511 Provisions 161,423 Source license HR-Statutory-PD-Conditional Region Central Europe + V4 About this corpus Ansvar's Croatian coverage is a machine-readable corpus of 4,511 consolidated Croatian laws and 161,423 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Croatia is part of Ansvar's Central Europe + V4 coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Croatian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here čl. 33. (NN 42/2018) Croatian provisions cite the članak (čl.), written as an ordinal with its trailing period, within an act published in Narodne novine — NN 42/2018 is gazette issue 42 of 2018, and the act is a numbered document within it. The gateway links the gazette publication with an anchor on the exact article. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from Narodne novine — official gazette of the Republic of Croatia Statutory text is served under the HR-Statutory-PD-Conditional source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Croatia corpus is served from EU infrastructure under the HR-Statutory-PD-Conditional source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Hungary Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/hungary Audited, citable Hungarian legislation — 4,316 laws, 130,568 provisions. Via the Ansvar MCP gateway. Coverage Hungary Hungarian law, machine-readable and cited The audited Hungarian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 4,316 Provisions 130,568 Source license Hungarian-Szjt-Section-1-4 Region Central Europe + V4 About this corpus Ansvar's Hungarian coverage is a machine-readable corpus of 4,316 consolidated Hungarian laws and 130,568 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Hungary is part of Ansvar's Central Europe + V4 coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Hungarian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Infotv. 25/G. § Hungarian acts are identified by year and Roman numeral — the Infotv. is 2011. évi CXII. törvény — and cite sections with the § after the number. Letter suffixes like 25/G mark provisions interpolated by later amendment. The Nemzeti Jogszabálytár (njt.hu) serves the consolidated text. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Hungarian legal evidence: Court decisions — Hungarian Constitutional Court decisions (Alkotmánybíróság), fanned into gateway search results on Premium and above. Official sources we ingest from Nemzeti Jogszabálytár — official Hungarian legislation register Statutory text is served under the Hungarian-Szjt-Section-1-4 source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Hungary corpus is served from EU infrastructure under the Hungarian-Szjt-Section-1-4 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Slovakia Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/slovakia Audited, citable Slovak legislation — 4,089 laws, 55,921 provisions. Via the Ansvar MCP gateway. Coverage Slovakia Slovak law, machine-readable and cited The audited Slovak legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 4,089 Provisions 55,921 Source license SK-Statutory-PD Region Central Europe + V4 About this corpus Ansvar's Slovak coverage is a machine-readable corpus of 4,089 consolidated Slovak laws and 55,921 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Slovakia is part of Ansvar's Central Europe + V4 coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Slovak provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here § 71 zákona č. 18/2018 Z. z. Slovak statutes cite the section sign within an act identified by collection number and year — zákon č. 18/2018 Z. z. is act No. 18 of 2018 in the Zbierka zákonov. Slov-Lex, the Ministry of Justice's register, encodes the same identifier in its URL and anchors on the paragraph. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Slovak legal evidence: Court decisions — Slovak case law from the Supreme Court (Najvyšší súd Slovenskej republiky), fanned into gateway search results on Premium and above. Official sources we ingest from Slov-Lex — official legal information portal of Slovakia Statutory text is served under the SK-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Slovakia corpus is served from EU infrastructure under the SK-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Poland Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/poland Audited, citable Polish legislation — 805 laws, 74,651 provisions. Via the Ansvar MCP gateway. Coverage Poland Polish law, machine-readable and cited The audited Polish legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 805 Provisions 74,651 Source license PL-Statutory-PD Region Central Europe + V4 About this corpus Ansvar's Polish coverage is a machine-readable corpus of 805 consolidated Polish laws and 74,651 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Poland is part of Ansvar's Central Europe + V4 coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Polish provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here art. 115, Dz.U. 2018 poz. 1000 Polish statutes cite the artykuł within an act identified by its Dziennik Ustaw year and position — Dz.U. 2018 poz. 1000. The Sejm's ISAP system encodes the same identifier (WDU20180001000) and serves the text the gateway links to. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Polish legal evidence: Court decisions — Polish case law from SAOS, the court-judgment analysis system, fanned into gateway search results on Premium and above. Official sources we ingest from ISAP — Internetowy System Aktów Prawnych (Sejm) Statutory text is served under the PL-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Poland corpus is served from EU infrastructure under the PL-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Slovenia Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/slovenia Audited, citable Slovenian legislation — 40 laws, 11,970 provisions. Via the Ansvar MCP gateway. Coverage Slovenia Slovenian law, machine-readable and cited The audited Slovenian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 40 Provisions 11,970 Source license SI-Statutory-PD Region Central Europe + V4 About this corpus Ansvar's Slovenian coverage is a machine-readable corpus of 40 consolidated Slovenian laws and 11,970 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Slovenia is part of Ansvar's Central Europe + V4 coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Slovenian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here 273. člen (PIS-RS ZAKO8249) Slovenian provisions cite the člen, written number-first — 273. člen. Acts carry stable identifiers in the state legal information system PIS-RS (ZAKO plus a serial), which the gateway resolves; the underlying gazette is the Uradni list. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Slovenian legal evidence: Court decisions — Slovenian case law from the Supreme Court's public service (sodnapraksa.si), fanned into gateway search results on Premium and above. Official sources we ingest from Uradni list RS — official gazette of the Republic of Slovenia Statutory text is served under the SI-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Slovenia corpus is served from EU infrastructure under the SI-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Lithuania Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/lithuania Audited, citable Lithuanian legislation — 12,047 laws, 89,810 provisions. Via the Ansvar MCP gateway. Coverage Lithuania Lithuanian law, machine-readable and cited The audited Lithuanian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 12,047 Provisions 89,810 Source license LT-Statutory-PD Region Baltics About this corpus Ansvar's Lithuanian coverage is a machine-readable corpus of 12,047 consolidated Lithuanian laws and 89,810 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Lithuania is part of Ansvar's Baltics coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Lithuanian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Įstatymo Nr. VIII-946 52 straipsnis Lithuanian statutes are numbered by legislature and serial — VIII-946 is the 946th law of the 1996–2000 term — and cite the straipsnis (article) within them. The Register of Legal Acts (e-TAR) holds the consolidated text under a stable TAR identifier the gateway resolves. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from e-TAR — Register of Legal Acts of the Republic of Lithuania Statutory text is served under the LT-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Lithuania corpus is served from EU infrastructure under the LT-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Latvia Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/latvia Audited, citable Latvian legislation — 2,250 laws, 58,063 provisions. Via the Ansvar MCP gateway. Coverage Latvia Latvian law, machine-readable and cited The audited Latvian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 2,250 Provisions 58,063 Source license LV-Statutory-PD Region Baltics About this corpus Ansvar's Latvian coverage is a machine-readable corpus of 2,250 consolidated Latvian laws and 58,063 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Latvia is part of Ansvar's Baltics coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Latvian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Fizisko personu datu apstrādes likuma 25. pants Latvian statutes cite the pants (article) with the number first — 25. pants — after the act's title, which the construction puts in the genitive case. Every act has a stable likumi.lv identifier, so the gateway's link opens the consolidated text at the exact article. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from likumi.lv — official consolidated legislation of Latvia Statutory text is served under the LV-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Latvia corpus is served from EU infrastructure under the LV-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Estonia Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/estonia Audited, citable Estonian legislation — 1,602 laws, 64,000 provisions. Via the Ansvar MCP gateway. Coverage Estonia Estonian law, machine-readable and cited The audited Estonian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 1,602 Provisions 64,000 Source license EE-Statutory-PD Region Baltics About this corpus Ansvar's Estonian coverage is a machine-readable corpus of 1,602 consolidated Estonian laws and 64,000 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Estonia is part of Ansvar's Baltics coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Estonian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here IKS § 38 Estonian acts are cited by an established abbreviation plus a flat § — IKS is the isikuandmete kaitse seadus, the national data-protection act. Every consolidated version carries a stable Riigi Teataja document number, so the gateway's link opens the exact paragraph on the state gazette. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Premium layers Beneath the statute corpus, Premium and above add Estonian legal evidence: Court decisions — Estonian case law published in Riigi Teataja, fanned into gateway search results on Premium and above. Official sources we ingest from Riigi Teataja — Estonian State Gazette, consolidated acts Statutory text is served under the EE-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Estonia corpus is served from EU infrastructure under the EE-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Romania Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/romania Audited, citable Romanian legislation — 12,001 laws, 112,545 provisions. Via the Ansvar MCP gateway. Coverage Romania Romanian law, machine-readable and cited The audited Romanian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 12,001 Provisions 112,545 Source license Romanian-Legea-8-1996-Art-9 Region SE Europe About this corpus Ansvar's Romanian coverage is a machine-readable corpus of 12,001 consolidated Romanian laws and 112,545 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Romania is part of Ansvar's SE Europe coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Romanian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here art. 34 din Legea nr. 284/2018 Romanian statutes cite the articol within an act identified by number and year — Legea nr. 284/2018. The Ministry of Justice's Portal Legislativ holds each act under a stable document ID, which is what the gateway resolves. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from Portal Legislativ — legislatie.just.ro (Ministry of Justice) Statutory text is served under the Romanian-Legea-8-1996-Art-9 source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Romania corpus is served from EU infrastructure under the Romanian-Legea-8-1996-Art-9 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Albania Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/albania Audited, citable Albania legislation — 8,749 laws, 113,037 provisions. Via the Ansvar MCP gateway. Coverage Albania Albania law, machine-readable and cited The audited Albania legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 8,749 Provisions 113,037 Source license AL-Statutory-PD Region SE Europe About this corpus Ansvar's Albania coverage is a machine-readable corpus of 8,749 consolidated Albania laws and 113,037 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Albania is part of Ansvar's SE Europe coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Albania provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Albania corpus is served from EU infrastructure under the AL-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Bulgaria Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/bulgaria Audited, citable Bulgarian legislation — 1,997 laws, 17,103 provisions. Via the Ansvar MCP gateway. Coverage Bulgaria Bulgarian law, machine-readable and cited The audited Bulgarian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 1,997 Provisions 17,103 Source license BG-Statutory-PD Region SE Europe About this corpus Ansvar's Bulgarian coverage is a machine-readable corpus of 1,997 consolidated Bulgarian laws and 17,103 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Bulgaria is part of Ansvar's SE Europe coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Bulgarian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here чл. 62, ал. 1 Bulgarian provisions cite the article (чл.) and, below it, the alinea (ал.) within an act — the fetched provision opens exactly that way. Acts resolve to the National Assembly's register at parliament.bg, which the gateway links as the source URL. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Bulgaria corpus is served from EU infrastructure under the BG-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Kosovo Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/kosovo Audited, citable Kosovar legislation — 1,039 laws, 31,409 provisions. Via the Ansvar MCP gateway. Coverage Kosovo Kosovar law, machine-readable and cited The audited Kosovar legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 1,039 Provisions 31,409 Source license XK-Statutory-PD Region SE Europe About this corpus Ansvar's Kosovar coverage is a machine-readable corpus of 1,039 consolidated Kosovar laws and 31,409 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Kosovo is part of Ansvar's SE Europe coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Kosovar provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Kosovo corpus is served from EU infrastructure under the XK-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Serbia Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/serbia Audited, citable Serbian legislation — 822 laws, 47,041 provisions. Via the Ansvar MCP gateway. Coverage Serbia Serbian law, machine-readable and cited The audited Serbian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 822 Provisions 47,041 Source license RS-Statutory-PD-Art-6 Region SE Europe About this corpus Ansvar's Serbian coverage is a machine-readable corpus of 822 consolidated Serbian laws and 47,041 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Serbia is part of Ansvar's SE Europe coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Serbian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Serbia corpus is served from EU infrastructure under the RS-Statutory-PD-Art-6 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Liechtenstein Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/liechtenstein Audited, citable Liechtenstein legislation — 3,614 laws, 73,213 provisions. Via the Ansvar MCP gateway. Coverage Liechtenstein Liechtenstein law, machine-readable and cited The audited Liechtenstein legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 3,614 Provisions 73,213 Source license LI-Statutory-PD Region EFTA + UK About this corpus Ansvar's Liechtenstein coverage is a machine-readable corpus of 3,614 consolidated Liechtenstein laws and 73,213 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Liechtenstein is part of Ansvar's EFTA + UK coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Liechtenstein provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Art. 6 DSG (LGBl. 2018 Nr. 272) Liechtenstein cites articles within a named act, identified by its Landesgesetzblatt year and number — the consolidated register at gesetze.li encodes LGBl. 2018 Nr. 272 directly in its URL, and the gateway's link anchors on the article. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from gesetze.li — Lilex, consolidated law of Liechtenstein Statutory text is served under the LI-Statutory-PD source licence, with per-item source attribution on every result. EU-hosted, licensing-audited — the Liechtenstein corpus is served from EU infrastructure under the LI-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## United Kingdom Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/united-kingdom Audited, citable UK legislation — 3,243 laws, 514,115 provisions. Via the Ansvar MCP gateway. Coverage United Kingdom UK law, machine-readable and cited The audited UK legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 3,243 Provisions 514,115 Source license OGL-3.0 Region EFTA + UK About this corpus Ansvar's UK coverage is a machine-readable corpus of 3,243 consolidated UK laws and 514,115 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. United Kingdom is part of Ansvar's EFTA + UK coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching UK provisions with article-level citations — and can cross-reference them against EU regulations in the same call. How citations work here Data Protection Act 2018, s 8 UK statutes are cited by short title, year and section — the Data Protection Act 2018 is chapter 12 of 2018, and legislation.gov.uk builds its URL from the act's type, year, chapter and section (ukpga/2018/12/section/8). Statute text is Crown copyright under the Open Government Licence. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. Official sources we ingest from legislation.gov.uk — the UK's official statute book Statutory text is served under the OGL-3.0 source licence, with per-item source attribution on every result. Where this shows up The UK corpus is part of the working coverage on these field pages: Energy & utilities EU-hosted, licensing-audited — the United Kingdom corpus is served from EU infrastructure under the OGL-3.0 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## United States Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/united-states Audited, citable US legislation — 10,244 laws, 380,164 provisions. Via the Ansvar MCP gateway. Coverage United States US law, machine-readable and cited The audited US legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 10,244 Provisions 380,164 Source license US-Federal-Government Region North America About this corpus Ansvar's US coverage is a machine-readable corpus of 10,244 consolidated US laws and 380,164 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. United States is part of Ansvar's North America coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching US provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the United States corpus is served from EU infrastructure under the US-Federal-Government source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Taiwan Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/taiwan Audited, citable Taiwanese legislation — 11,747 laws, 221,082 provisions. Via the Ansvar MCP gateway. Coverage Taiwan Taiwanese law, machine-readable and cited The audited Taiwanese legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 11,747 Provisions 221,082 Source license TW-Statutory-PD-Art-9 Region Asia-Pacific About this corpus Ansvar's Taiwanese coverage is a machine-readable corpus of 11,747 consolidated Taiwanese laws and 221,082 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Taiwan is part of Ansvar's Asia-Pacific coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Taiwanese provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Taiwan corpus is served from EU infrastructure under the TW-Statutory-PD-Art-9 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Japan Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/japan Audited, citable Japanese legislation — 8,953 laws, 252,261 provisions. Via the Ansvar MCP gateway. Coverage Japan Japanese law, machine-readable and cited The audited Japanese legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 8,953 Provisions 252,261 Source license JP-Statutory-PD-Art-13 Region Asia-Pacific About this corpus Ansvar's Japanese coverage is a machine-readable corpus of 8,953 consolidated Japanese laws and 252,261 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Japan is part of Ansvar's Asia-Pacific coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Japanese provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Japan corpus is served from EU infrastructure under the JP-Statutory-PD-Art-13 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## South Korea Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/south-korea Audited, citable South Korean legislation — 6,494 laws, 214,578 provisions. Via the Ansvar MCP gateway. Coverage South Korea South Korean law, machine-readable and cited The audited South Korean legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 6,494 Provisions 214,578 Source license KOGL-Type-1 Region Asia-Pacific About this corpus Ansvar's South Korean coverage is a machine-readable corpus of 6,494 consolidated South Korean laws and 214,578 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. South Korea is part of Ansvar's Asia-Pacific coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching South Korean provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the South Korea corpus is served from EU infrastructure under the KOGL-Type-1 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Qatar Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/qatar Audited, citable Qatari legislation — 9,428 laws, 71,155 provisions. Via the Ansvar MCP gateway. Coverage Qatar Qatari law, machine-readable and cited The audited Qatari legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 9,428 Provisions 71,155 Source license QA-Statutory-PD-Art-4 Region Middle East & Africa About this corpus Ansvar's Qatari coverage is a machine-readable corpus of 9,428 consolidated Qatari laws and 71,155 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Qatar is part of Ansvar's Middle East & Africa coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Qatari provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Qatar corpus is served from EU infrastructure under the QA-Statutory-PD-Art-4 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Djibouti Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/djibouti Audited, citable Djiboutian legislation — 2,747 laws, 27,027 provisions. Via the Ansvar MCP gateway. Coverage Djibouti Djiboutian law, machine-readable and cited The audited Djiboutian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 2,747 Provisions 27,027 Region Middle East & Africa About this corpus Ansvar's Djiboutian coverage is a machine-readable corpus of 2,747 consolidated Djiboutian laws and 27,027 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Djibouti is part of Ansvar's Middle East & Africa coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Djiboutian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Djibouti corpus is served from EU infrastructure . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Bahrain Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/bahrain Audited, citable Bahraini legislation — 1,622 laws, 14,506 provisions. Via the Ansvar MCP gateway. Coverage Bahrain Bahraini law, machine-readable and cited The audited Bahraini legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 1,622 Provisions 14,506 Source license BH-Statutory-PD-Art-4 Region Middle East & Africa About this corpus Ansvar's Bahraini coverage is a machine-readable corpus of 1,622 consolidated Bahraini laws and 14,506 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Bahrain is part of Ansvar's Middle East & Africa coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Bahraini provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Bahrain corpus is served from EU infrastructure under the BH-Statutory-PD-Art-4 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Costa Rica Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/costa-rica Audited, citable Costa Rican legislation — 16,724 laws, 120,455 provisions. Via the Ansvar MCP gateway. Coverage Costa Rica Costa Rican law, machine-readable and cited The audited Costa Rican legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 16,724 Provisions 120,455 Source license CR-Statutory-PD-Art-75 Region Latin America & Caribbean About this corpus Ansvar's Costa Rican coverage is a machine-readable corpus of 16,724 consolidated Costa Rican laws and 120,455 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Costa Rica is part of Ansvar's Latin America & Caribbean coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Costa Rican provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Costa Rica corpus is served from EU infrastructure under the CR-Statutory-PD-Art-75 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Paraguay Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/paraguay Audited, citable Paraguay legislation — 7,073 laws, 38,822 provisions. Via the Ansvar MCP gateway. Coverage Paraguay Paraguay law, machine-readable and cited The audited Paraguay legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 7,073 Provisions 38,822 Source license PY-Statutory-PD-Art-8 Region Latin America & Caribbean About this corpus Ansvar's Paraguay coverage is a machine-readable corpus of 7,073 consolidated Paraguay laws and 38,822 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Paraguay is part of Ansvar's Latin America & Caribbean coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Paraguay provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Paraguay corpus is served from EU infrastructure under the PY-Statutory-PD-Art-8 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Brazil Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/brazil Audited, citable Brazilian legislation — 4,805 laws, 54,934 provisions. Via the Ansvar MCP gateway. Coverage Brazil Brazilian law, machine-readable and cited The audited Brazilian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 4,805 Provisions 54,934 Source license BR-Statutory-PD Region Latin America & Caribbean About this corpus Ansvar's Brazilian coverage is a machine-readable corpus of 4,805 consolidated Brazilian laws and 54,934 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Brazil is part of Ansvar's Latin America & Caribbean coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Brazilian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Brazil corpus is served from EU infrastructure under the BR-Statutory-PD source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Uruguay Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/uruguay Audited, citable Uruguay legislation — 4,768 laws, 37,131 provisions. Via the Ansvar MCP gateway. Coverage Uruguay Uruguay law, machine-readable and cited The audited Uruguay legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 4,768 Provisions 37,131 Region Latin America & Caribbean About this corpus Ansvar's Uruguay coverage is a machine-readable corpus of 4,768 consolidated Uruguay laws and 37,131 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Uruguay is part of Ansvar's Latin America & Caribbean coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Uruguay provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Uruguay corpus is served from EU infrastructure . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Peru Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/peru Audited, citable Peru legislation — 2,131 laws, 13,857 provisions. Via the Ansvar MCP gateway. Coverage Peru Peru law, machine-readable and cited The audited Peru legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 2,131 Provisions 13,857 Region Latin America & Caribbean About this corpus Ansvar's Peru coverage is a machine-readable corpus of 2,131 consolidated Peru laws and 13,857 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Peru is part of Ansvar's Latin America & Caribbean coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Peru provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Peru corpus is served from EU infrastructure . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Trinidad & Tobago Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/trinidad-tobago Audited, citable Trinidadian legislation — 533 laws, 21,562 provisions. Via the Ansvar MCP gateway. Coverage Trinidad & Tobago Trinidadian law, machine-readable and cited The audited Trinidadian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 533 Provisions 21,562 Source license TT-Section-7-1-b Region Latin America & Caribbean About this corpus Ansvar's Trinidadian coverage is a machine-readable corpus of 533 consolidated Trinidadian laws and 21,562 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Trinidad & Tobago is part of Ansvar's Latin America & Caribbean coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Trinidadian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Trinidad & Tobago corpus is served from EU infrastructure under the TT-Section-7-1-b source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Haiti Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/haiti Audited, citable Haitian legislation — 11 laws, 3,811 provisions. Via the Ansvar MCP gateway. Coverage Haiti Haitian law, machine-readable and cited The audited Haitian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 11 Provisions 3,811 Region Latin America & Caribbean About this corpus Ansvar's Haitian coverage is a machine-readable corpus of 11 consolidated Haitian laws and 3,811 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Haiti is part of Ansvar's Latin America & Caribbean coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Haitian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Haiti corpus is served from EU infrastructure . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Guatemala Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/guatemala Audited, citable Guatemalan legislation — 8 laws, 5,539 provisions. Via the Ansvar MCP gateway. Coverage Guatemala Guatemalan law, machine-readable and cited The audited Guatemalan legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 8 Provisions 5,539 Source license GT-Statutory-PD-Art-68 Region Latin America & Caribbean About this corpus Ansvar's Guatemalan coverage is a machine-readable corpus of 8 consolidated Guatemalan laws and 5,539 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Guatemala is part of Ansvar's Latin America & Caribbean coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Guatemalan provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Guatemala corpus is served from EU infrastructure under the GT-Statutory-PD-Art-68 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Ukraine Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/ukraine Audited, citable Ukrainian legislation — 8,165 laws, 50,710 provisions. Via the Ansvar MCP gateway. Coverage Ukraine Ukrainian law, machine-readable and cited The audited Ukrainian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 8,165 Provisions 50,710 Source license UA-Statutory-PD-Art-8 Region Eastern Europe & Caucasus About this corpus Ansvar's Ukrainian coverage is a machine-readable corpus of 8,165 consolidated Ukrainian laws and 50,710 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Ukraine is part of Ansvar's Eastern Europe & Caucasus coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Ukrainian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Ukraine corpus is served from EU infrastructure under the UA-Statutory-PD-Art-8 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Armenia Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/armenia Audited, citable Armenian legislation — 6,416 laws, 223,942 provisions. Via the Ansvar MCP gateway. Coverage Armenia Armenian law, machine-readable and cited The audited Armenian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 6,416 Provisions 223,942 Source license AM-Statutory-PD-Art-4 Region Eastern Europe & Caucasus About this corpus Ansvar's Armenian coverage is a machine-readable corpus of 6,416 consolidated Armenian laws and 223,942 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Armenia is part of Ansvar's Eastern Europe & Caucasus coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Armenian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Armenia corpus is served from EU infrastructure under the AM-Statutory-PD-Art-4 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Georgia Law — machine-readable, cited · Ansvar AI URL: https://ansvar.eu/coverage/georgia Audited, citable Georgian legislation — 943 laws, 35,463 provisions. Via the Ansvar MCP gateway. Coverage Georgia Georgian law, machine-readable and cited The audited Georgian legislation corpus, served through the Ansvar MCP Gateway to your own AI client. Live — source-licensing audited Laws 943 Provisions 35,463 Source license GE-Statutory-PD-Art-8 Region Eastern Europe & Caucasus About this corpus Ansvar's Georgian coverage is a machine-readable corpus of 943 consolidated Georgian laws and 35,463 individually-citable provisions. Content freshness is reported live, per corpus, at the gateway — ask your AI client to run list_coverage or get_data_freshness for the current state. Georgia is part of Ansvar's Eastern Europe & Caucasus coverage. Your AI client reaches it over a single authenticated MCP connection to the gateway, which returns the matching Georgian provisions with article-level citations — and can cross-reference them against EU regulations in the same call. What you can do Search the legislation from your AI client and get back the matching provisions, not paraphrases. Retrieve exact provisions with article-level citations you and your auditor can open and check. Cross-reference national requirements with EU regulations over the same gateway connection. EU-hosted, licensing-audited — the Georgia corpus is served from EU infrastructure under the GE-Statutory-PD-Art-8 source licence . See the fields it serves on the solutions hub . Coverage on this page is the national legislation corpus listed above. Case law, preparatory works, and agency guidance vary by jurisdiction and tier — see pricing . The live set is the source-licensing-audited one; the full picture, including what's in development, is on the coverage page . Connect your AI client See pricing --- ## Changelog · Ansvar AI URL: https://ansvar.eu/changelog Dated product changes to the Ansvar Gateway: new corpora and jurisdictions, gateway capabilities, account, pricing, and security changes. Changelog New corpora, gateway capabilities, and product changes — dated as they ship. RSS feed August 2026 6 August 2026 gateway Ask what regulators actually published Your agent can now ask what has actually been published, and get an answer from records rather than from memory. Each one carries its title, a link to the original publisher page, the publication and observation dates, official identifiers where the source assigns them, and a full citation naming the licence and linking its terms. What is monitored is the EU Official Journal L series — regulations, directives, implementing and delegated acts as they appear — alongside announcements from the European Commission, the EDPB and ENISA, and the national gazettes of a growing set of European jurisdictions. Every source passes the same per-source licensing gate before a single fetch, and get_regulatory_intelligence_status reports the live enrolment: which sources are watched, how fresh each one is, and when its baseline ran. That tool is the authoritative list, and it works on every plan including Free. Coverage is bounded, and the tools say where the boundary is. Each source reports only from its own enrolment baseline onward, so an empty result means nothing matched inside that window — never that the regulators were quiet. When every selected source is stale or has never synced, the search fails and names the state of each one instead of returning an empty list that would read as silence. This is publication monitoring, not amendment tracking: it tells you an act was published, not how a law you already follow changed. For that diff, get_changes remains the tool. search_regulatory_updates and get_regulatory_update are available from the Premium plan. get_regulatory_intelligence_status is free on every plan. 4 August 2026 workflows docs Workflows and the control library, explained The site now has a Workflows section covering both ways you can run the same work: yourself, in the AI client you already use, or as an engagement we run and review as practitioners. The first workflow family has its own page — TARA , the threat-analysis-and-risk-assessment family for vehicles, OT, rail, robots and drones, sharing one enterprise risk spine. Services keep their URL and now live in the Workflows menu. The canonical control library also has a page for the first time. It explains what a canonical control is, why a flat framework tag cannot carry a coverage claim, the five relationships a mapping can record, and why the library stores citation pointers rather than licensed clause text. It is candid about where coverage stands: published crosswalks arrive untyped and claim nothing until a person reviews them, so the page shows what one control reaches today and names the frameworks that are registered but not yet mapped. A worked crosswalk from a real session walks ISO/IEC 27001 Annex A.5.26 through the spine to 24 NIST CSF 2.0 subcategories, with the provenance of every hop. The control library is available on Team and Company plans. 4 August 2026 gateway pricing Service credentials are full seats A service credential — the org-owned seat a Team or Company admin mints for headless clients such as n8n, CI, or a scheduled monitoring agent — now carries the same tool surface as a signed-in seat on its plan: search, workflow runs, document upload and report generation, under the same tier gates, drawing from the organization's pooled quota. This supersedes the read-only boundary the launch entry of 2026-07-26 described. Each credential keeps a monthly workflow-run ceiling, by default half of what one seat contributes to the pool, so one runaway agent cannot drain what the rest of the organization shares. A credential takes a seat of its own, next to yours; add seats as your agents grow. Setup guide: Service credentials . July 2026 31 July 2026 gateway account Sign up with email and password Free-tier signup is now identity-native two ways: sign in with Microsoft Entra ID or Google as before, or register directly with an email address and password at app.ansvar.eu . Registration asks for terms acceptance up front, verifies the address by email before the account is usable, and sits behind a fail-closed bot check. Nothing about the tier changed — a free account still connects your own MCP client to the gateway with the same limits, and paid plans still upgrade through checkout. If your organisation blocks third-party SSO, this removes the last reason you couldn't try the connector. 30 July 2026 docs gateway ISO Standards Expert: an agent skill for the standards add-on The iso-standards-expert skill teaches an AI assistant to answer standards questions from served clause text instead of model memory: it fetches the clauses a question needs through the ISO Standards add-on , quotes them verbatim with the SIS copyright notice on every excerpt, and reports an unevaluated-scope list whenever the licence coverage ceiling withholds a fetch — only selected parts of a standard are ever displayed, never the complete standard. Without an add-on the skill still runs, answering ISO 27001-shaped questions from the free Secure Controls Framework cross-reference with every such result labelled. The sequence: install the skill, connect the Ansvar Gateway connector, sign in (a free account is enough), and subscribe per standard. Also available bundled in the ansvar-compliance-skills Claude Code plugin. Try it: "Using Ansvar, what does ISO/IEC 27001 require for a risk treatment plan, and what should ours contain?" Details in the agent skills guide . 28 July 2026 gateway pricing Free tier: seven workflow types with rendered reports A free account runs one workflow a month, picked from seven types: STRIDE threat model, generic gap analysis, NIS2, DORA, CRA and EU AI Act gap analyses, and DPIA. Solo doubles that to two runs. The report arrives as JSON or as a watermarked HTML or PDF render with a visible banner marking the inputs as self-asserted. Premium runs the full interview-grounded catalog; Team adds your own documents as evidence. Plans on Pricing . 28 July 2026 coverage Data protection: Austrian DSB decisions and EDPB guidelines Scope a search to Austria and you now get the Datenschutzbehörde's enforcement practice: 1,642 DSB and DSK decisions harvested from the official RIS registry, each linking its ris.bka.gv.at page. The corpus also adds 330 EDPB guidelines, recommendations and opinions; on Premium and higher plans these arrive inside EU-scoped search results and through the guidance tool. Both join the French CNIL deliberations already served, and every row cites the official publisher page. 26 July 2026 account pricing Service credentials: give an agent its own seat A seat on Team and Company plans can now belong to an agent, not just a person. Org admins mint org-owned service credentials — OAuth2 client_credentials , read-only — for headless use: CI jobs, scheduled compliance checks, server-side agents. Each active credential takes a seat, the same way a person does. Manage them from the Service credentials section of Organization in the account area; plan details on Pricing . 25 July 2026 account Free tier signup no longer goes through checkout Signing up for the free tier is now a plain sign-in: pick Google, Microsoft, or email at app.ansvar.eu/account and the account is provisioned on the spot. The €0 checkout flow is retired; existing free subscriptions keep working unchanged. Paid plans still go through Stripe checkout. 25 July 2026 gateway docs Ansvar Gateway listed in the Claude connector directory The gateway is now listed in Anthropic's connector directory (Claude login required to view). claude.ai and Claude Desktop users connect in one click; the listing also carries the Claude Code and Claude API snippets. Other clients: see Setup . 23 July 2026 security Ansvar Gateway joins the CSA STAR Registry Ansvar Gateway is listed in the CSA STAR Registry : a Level 1 self-assessment, the full CAIQ v4.0.3, downloadable by anyone. We published all 261 answers, including the 67 No answers. Why we did it that way: the announcement post .