# 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 · Evidence and validation infrastructure for your AI agents URL: https://ansvar.eu/ Keep your models, your orchestration and your interface. Ansvar supplies the sources, checks the citations an answer rests on, and returns reviewable work. Evidence infrastructure for regulated work Evidence and validation infrastructure for your AI agents. Your models, your orchestration, your interface stay yours. Ansvar supplies the sources, re-fetches and checks the citations an answer rests on, and hands back compliance work your people can review. Start free Run a free assessment Building on it? One endpoint, published contracts, agents on seats Works in Claude , ChatGPT , Copilot , Cursor and your own agents. gap analysis · NIS2 · Baltika Freight Systems OÜ · finding 4 of 10 Art. 21(2)(d) supply chain security GAP “ supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers ” Current state: Roughly 30 cloud and data suppliers, no register; contracts on supplier paper with no security clauses; customs-data integrations rely on provider defaults. NIS2 art. 21(2)(d) Directive (EU) 2022/2555 · Publications Office of the EU · EUR-Lex-Decision-2011-833 4 mapped controls remediation R2 From the sample gap analysis for a fictional client; the NIS2 rows are served citations. Listed in OWASP GenAI Security Solutions Landscape ↗ Used by Regenold, in a W&B Weave life-science workflow ↗ Published assurance CSA STAR Level 1 self-assessment ↗ In regulated work MedTech teams, on a DPIA and a threat model Partners Reseller and infrastructure partner Security services partner Cooperation partner About our partners How it fits together Your agents, the evidence, your systems and your obligations, joined by one connection. One MCP connection between them. It fetches and cites, or refuses. YOUR AI CLIENTS Claude ChatGPT Copilot · Cursor Your own agents ANSVAR GATEWAY One MCP connection gateway.ansvar.eu/mcp cited, or refused receipt on every report tier · products · add-ons OAuth 2.1 · EU-hosted FOUR PRODUCTS Legal and regulatory evidence Living security architecture Compliance assessments Security risk and threat intelligence Your AI clients Claude · ChatGPT · Copilot · Cursor · your own agents One MCP connection gateway.ansvar.eu/mcp · cited, or refused · receipt on every report · OAuth 2.1, EU-hosted Four products Legal and regulatory evidence · Living security architecture · Compliance assessments · Security risk and threat intelligence Four products, one connection Each answers one question. What does the law say. What is our system. What must we do. What are we exposed to, and what do we fix first. Buy one or all four; they share the same evidence. Compare plans Legal and regulatory evidence Law, regulation, standards, case law and guidance across Europe, the UK, the US and Canada, every row traced to its publisher. Claude · connected to Ansvar Illustrative example You Using Ansvar, what does the GDPR say about the right to erasure? Claude A controller must erase personal data without undue delay when one of the Article 17(1) grounds applies. Paragraph 3 lists the exceptions, including legal obligations and the establishment of legal claims. Regulation (EU) 2016/679, Article 17 publisher Publications Office of the EU licence EUR-Lex-Decision-2011-833 source data.europa.eu/eli/reg/2016/679/oj Estonian implementing act: not served in this scope. Refused rather than guessed. receipt 0000-2f6a-91c3 row verified 2026-09-20 See the full example Free · every jurisdiction from €29 a month Explore Living security architecture A model of components, data flows and trust zones that your agents keep current and your people approve. customer-portal · data flow · proposal 14 awaiting approval Illustrative example External Browser Application zone Portal API → Event queue (proposed, owner unknown) Restricted data Records store, written by Portal API External Application zone Restricted data Browser Portal API Records store Event queue proposed See the full example 30-day evaluation · licence from €149 a month Explore Compliance assessments Gap analyses, DPIAs and conformity runs your own agent walks end to end on a system you describe, or on your documents from Team. Every finding cited, every report with a receipt. gap analysis · NIS2 · finding 7 of 31 Illustrative example Supply-chain security policy is not documented GAP The information-security policy names supplier risk but sets no requirements for contracts, monitoring or offboarding. Article 21(2)(d) expects the measures to cover supply-chain security. NIS2 art. 21(2)(d) Directive (EU) 2022/2555 · Publications Office doc://policy/§4.3 Information-security policy, paragraph 4.3 · your document report receipt 0000-19ac-7e21 reviewer decision pending See the full example From €249 a month · on your documents from €490 Explore Security risk and threat intelligence CVE, KEV, EPSS and ICS advisory lookups on every plan. Threat models and TARAs your agent runs. A vulnerability assessment scores each finding against the system you described. effective_risk · portal-api · 1 of 14 findings Illustrative example CVE-2021-44228 Apache Log4j2 remote code execution, CVSS 10.0 KEV: listed EPSS 0.99999, top 1% most likely to be exploited in the next 30 days FIRST.org context Portal API, internet-facing, restricted data your model verdict Fix first: reachable from the internet and in the ransomware catalogue critical export Review decision recorded, exported as OpenVEX openvex CISA KEV, added 2021-12-10 EPSS read 2026-09-21 Effective risk for portal-api, finding 1 of 14. Illustrative example; the CVE and KEV rows are served records. See the full example Free lookups and one teaser run · from €249 a month Explore The frames show illustrative sessions. The cited rows in them are served citations. Build on it Built for the agents you already run. One MCP endpoint under your existing stack. Nothing here asks you to move it. Build on Ansvar One endpoint An MCP connection with OAuth 2.1 and dynamic client registration. Your client, your model, your prompts — the evidence comes from us. Agents on seats Service credentials from Premium for n8n, CI and scheduled monitors. Published quotas, and refusals that name your usage, the reset time and the next step. Citations you can check Every row carries publisher, source URL and licence — and the gateway will re-fetch the citations a draft already relies on and say which held. On every plan. How the check works Where this is going Agents investigate. Experts decide. Agents prepare decisions from how a system was designed, how it runs and which obligations apply; your experts inspect and decide. How the connected company works The connected company Working vision Documentation and company systems feed read-only MCP connectors into a living architecture. Specialist agents combine it with Ansvar knowledge MCPs and prepare decisions for human experts, who decide and authorize. Documentation Policies · architecture · decisions Responsibilities · trust boundaries Company systems Configs · identities · SBOMs Vulnerabilities · logs · alerts MCP connectors Scoped, read-only access No write operations Living architecture Assets · identities · data flows Controls · suppliers · owners POWERED BY ANSVAR Knowledge MCPs Law · controls · MITRE · sector rules Reg intel · cited, with freshness Specialist agents Investigate · simulate · assess Threat models · DPIAs Micro threat models · options Human experts Challenge · decide · authorize Through your existing processes COMPANY CONTEXT READ-ONLY CAPABILITIES SOURCES + FRESHNESS + UNKNOWNS DECISION AUTHORITY Company context, two inputs in parallel Documentation Policies · architecture · decisions · Responsibilities · trust boundaries Company systems Configs · identities · SBOMs · Vulnerabilities · logs · alerts MCP connectors Scoped, read-only access · No write operations Two inputs to the agents, in parallel Living architecture Assets · identities · data flows · Controls · suppliers · owners Knowledge MCPs Law · controls · MITRE · sector rules · Reg intel · cited, with freshness Specialist agents Investigate · simulate · assess · Threat models · DPIAs · Micro threat models · options Human experts Challenge · decide · authorize · Through your existing processes Each source keeps its observation time. Missing evidence, and conflicts between documented intent and observed state, stay visible. Add-ons and contracts Three things that sit beside the products. Buy them with any plan, or on their own contract. Each one keeps the same evidence and the same connection. ISMS as Code The management system as a repository your agent operates and your people approve. Annual contract, with a paid pilot credited on conversion. How it works Licensed ISO standards (SIS) Official distributor Any ISO, EN or SS standard SIS publishes can be licensed into your workspace and read clause by clause, cited. Per seat, reported to SIS, served from the gateway. The standards module Expert delivery Our team runs or reviews the assessment, with the scope agreed before work starts. What we deliver Choose where it runs Hosted by us, or inside your perimeter. Hosted is available today and free to start. Your Kubernetes and on-prem run as design-partner pilots, with the production scope agreed before either side calls it available. Compare deployments Hosted Available EU infrastructure, operated by Ansvar. Start free, no card. Details Your Kubernetes Pilot phase · design-partner pilots Ansvar runs in your own cluster; law and regulation are still answered from the central gateway. Details On-prem and air-gapped Pilot phase · design-partner pilots Signed content packs, no call home. Updates delivered offline on an annual contract. Details Product updates Recently shipped. Dated changes to the corpora, the gateway, the workflows and the account. All changes 21 Oct 2026 gateway A stable endpoint for clients that snapshot tool definitions https://gateway.ansvar.eu/stable/mcp serves the same tools, plans and login as /mcp, but its tool definitions change only when we refresh them on purpose and tell you in advance. Use it from platforms that save a copy of each tool when you register a server. 21 Oct 2026 gateway Microsoft 365 Copilot shows Ansvar sources as clickable citations Evidence rows now carry url, title and subtitle fields where the source provides them, and the tool result is one valid JSON document. Microsoft 365 Copilot reads those fields and shows a source with a web address as a clickable citation. 21 Oct 2026 coverage EU case law: judgments of the Court of Justice and the General Court Your agent can now search and cite judgments, orders and Advocate General opinions of the Court of Justice and the General Court of the European Union, in English, from the Publications Office's Cellar. Start with one cited answer, or one free assessment. Free for businesses, no card. The free assessment runs on a system you describe; your own documents come with Team. Start free Evaluate on your own question --- ## Legal and regulatory evidence · Ansvar AI URL: https://ansvar.eu/evidence Law, regulation, standards, case law and guidance across Europe, the UK, the US and Canada, every row cited to the publisher that issued it. Legal and regulatory evidence · Ansvar Evidence Find the provision and read the source. Law, regulation, standards, case law and agency guidance across Europe, the UK, the US and Canada. Every row is traced to the publisher that issued it, with a licence you can rely on, or the answer says the source is not served. Start free See what is covered Claude · connected to Ansvar You Using Ansvar, what does the GDPR say about the right to erasure? Claude A controller must erase personal data without undue delay when one of the Article 17(1) grounds applies. Paragraph 3 lists the exceptions, including legal obligations and the establishment of legal claims. Regulation (EU) 2016/679, Article 17 publisher Publications Office of the EU licence EUR-Lex-Decision-2011-833 source data.europa.eu/eli/reg/2016/679/oj Estonian implementing act: not served in this scope. Refused rather than guessed. receipt 0000-2f6a-91c3 row verified 2026-09-20 Illustrative session; the GDPR row is a served citation What you get A search that fans out, and a lookup that lands on the article. Ask in your own words and in the corpus language. Search returns the rows that matched across every served jurisdiction you asked for; a lookup returns the exact article, recital or decision by reference. One question, every jurisdiction A question about incident reporting reaches the directive, the Dutch act and the German act in one call. Each row names its publisher, so your agent can quote the right national wording. Coverage by jurisdiction search · "incident reporting deadline" · NIS2 EU Directive (EU) 2022/2555, Article 23(4) early warning 24 h · notification 72 h Publications Office NL Cyberbeveiligingswet, artikel 24 melding · 24 uur · 72 uur Overheid.nl DE BSIG § 32 Meldepflichten Frühwarnung · 24 Stunden Bundesamt für Justiz Case law, preparatory works and guidance From Premium — or from Evidence Pro, the one-person plan at €99 — the same question also returns the decisions that interpreted the provision, the preparatory works behind it and the regulator's guidance on it, each cited the same way. What each plan reaches get_decision · CJEU C-311/18 · Schrems II CJEU Judgment of 16 July 2020, C-311/18 ECLI:EU:C:2020:559 · Grand Chamber Court of Justice EU Regulation (EU) 2016/679, Article 46 transfers subject to appropriate safeguards Publications Office EDPB Recommendations 01/2020 on supplementary measures adopted 18 June 2021 · version 2.0 EDPB How a citation works Cited, or refused. A row is served only with its source URL, publisher and licence. When the corpus has no served source for the question, the gateway says so and names the gap. Nothing is filled in from the model's memory. 01 Your agent asks, leading with Using Ansvar That phrase tells the agent to use the connector. The gateway returns only what it served; how the agent phrases its answer is the agent's. 02 The gateway fetches from the served corpora One call, whatever it fans out to. Rows come back with publisher, licence and the original URL. 03 The answer cites, or refuses A served row is quoted with its citation. A missing source is reported as unresolved, with the reason. 04 A query receipt records what was served On Company, a signed record of what was asked and what came back, so you can verify later what the answer rested on without asking us. Regulatory intelligence is included: search publications and deadlines from the regulators we watch, with the same citation rules. How the watch works Checking, not just citing Hand back what your agent wrote. We re-fetch every citation. Collecting citations is the easy half. The gateway takes the references a draft relies on, retrieves each one again under your own scope through the source-pinned exact lookup, checks the producer-declared identity of the row that came back, and only then compares your quotation with the body. A verdict per citation, in words that do not hedge Every subject comes back with one verdict. A quotation found in the retrieved body is quote_checked ; a subject submitted without one, and resolved, is reference_resolved . A quotation that is not in the body is quote_mismatch , and one too short to be evidence is no_quotation_submitted — a refusal, not a pass. A reference whose row turns out to name a different provision is identity_mismatch . Where no producer identity exists to establish, the reference cannot be read, the corpus is not served to you, or the lookup itself fails, the answer is identity_absent , reference_unparseable , not_served , withheld or unavailable — never a quiet pass. A displayed reference never decides which row answers a subject: an envelope that prints “Article 99” over an Article 1 body fails here rather than passing on its label. The contracts behind it verify_citations · three subjects s1 GDPR art. 17, quotation from the draft quote_checked s2 Same article, a paraphrase the text presents as a quote quote_mismatch s3 A reference with no source pin behind it identity_absent What this establishes is what the source says, and whether your text quoted it. It is not a legal opinion, and it does not certify a conclusion — the reviewer still decides. That boundary is the point: the machine checks what a machine can check, and names the rest. Plans Free to start. Every jurisdiction from €29 a month. Free answers one jurisdiction or framework per question. Solo reaches every served jurisdiction. Case law, preparatory works and guidance come with Premium, and with Evidence Pro at €99 for one person. Every plan and limit Start with one cited answer. Free for businesses. No card. Connected in two minutes. Start free Read the quickstart --- ## Examples · Ansvar AI URL: https://ansvar.eu/examples Complete sample deliverables and captured runs with real output: gap analyses, DPIAs, threat models and cited research, as an agent produced them. Examples Read the output before you take the call. Five complete deliverables and the captured runs behind them, exactly as an agent produced them through Ansvar. Every citation on these pages was fetched, not recalled. Sample deliverables Complete reports, start to finish. Each one is a full report with its findings, citations and receipt. Read it the way a reviewer would. NIS2 gap analysis Article 21, full deliverable with the policy attached Read the sample STRIDE threat model Full deliverable on a described system Read the sample GDPR Article 35 DPIA Full deliverable, jurisdiction-aware Read the sample EU AI Act readiness Full example assessment Read the sample Vulnerability deferral dossier CRA-era example Read the sample Captured runs Assessments as an agent ran them. Workflow runs captured with the questions the agent asked, the sources it fetched and the report it delivered. NIS2 gap analysis with the policy attached A real NIS2 Article 21 gap analysis with the policy uploaded — verdicts pinned to hash-anchored paragraphs and ISO 27001 clauses licensed from SIS. Open the run Gap analysis from a security policy 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. Open the run DPIA for a new 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. Open the run STRIDE threat model for an authentication flow 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. Open the run EU AI Act high-risk classification for credit scoring 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. Open the run LINDDUN privacy threat model for a customer-data store 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. Open the run Captured research Cited answers to hard questions. Multi-jurisdiction questions answered from served sources, with every row cited and every gap named. Paragraph-cited review of a data-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. Open the answer ISO 27001 to NIST CSF 2.0 through a canonical control library 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. Open the answer Employee-monitoring rules in NL, DE and FR One question, three jurisdictions: the works-council and labour-code overlays on GDPR for staff monitoring in the Netherlands, Germany and France, each cited. Open the answer Captured runs are real sessions with client details removed. Values that were illustrative at the time are marked so on the page. Run one on your own system. A threat model, a gap analysis or a DPIA, free, on a system you describe. Start free Have our team run it --- ## Living security architecture · Ansvar AI URL: https://ansvar.eu/architecture A model of your systems, data flows and trust zones your agents keep current and your people approve. Threats and controls attach to the parts they concern. Living security architecture · Ansvar Architecture A model of your system that stays true. Components, data flows and trust zones your agents keep current and your people approve. Threats, controls and obligations attach to the parts they concern, so the diagram is still true next quarter. Start a 30-day evaluation Licence from €149 a month customer-portal · data flow · proposal 14 awaiting approval External Browser Application zone Portal API → Event queue (proposed, owner unknown) Restricted data Records store, written by Portal API External Application zone Restricted data Browser Portal API Records store Event queue proposed How it stays true Agents propose, people approve, and every fact cites where it was seen. Nothing changes the model without a person's assent. A proposal carries the change, the evidence it rests on and the open questions, and it waits. Proposals, not edits An agent that reads your repositories, manifests or tickets proposes a component, a flow or a control. The proposal cites the commit or document it was seen in. The accepted model does not move until the owner assents. How agents connect proposal 14 · add event queue · awaiting approval change Add component Event queue in Application zone; flow Portal API → Event queue (events) proposed evidence Observed in deploy/values-portal.yaml at commit 8f21c0e, 2026-09-18 cited owner Unknown. Assessment blocked until named. open assent System owner review, required before the model changes waiting Threats and obligations attach to parts A threat model, a TARA or a gap finding is scoped to the components it concerns. When a component changes, the assessments that depend on it are marked stale and a review is proposed. Nothing is silently re-reasoned. The threat models and TARAs that read the model The gap analyses that read the model customer-portal · threats · 3 attach to Portal API External Browser Application zone Portal API → Event queue (proposed, owner unknown) Restricted data Records store, written by Portal API External Application zone Restricted data Browser Portal API Records store Event queue proposed Start standalone Thirty days on your machine, then a licence. The evaluation licence runs the whole workspace on your own machine for thirty days: the same model, the same proposals, the same UI. No card. On day thirty-one the workspace turns read-only and nothing is deleted; a licence key opens it again. Ansvar never hosts your architecture model: it runs on your machine or inside your plane, and a signed licence file works air-gapped with no call home. Two commands Create the workspace, pair your MCP client with the code the first command prints, and open the UI. The published image tag is on the docs page. Standalone setup in the docs # create a workspace and print a pairing code mkdir -m 777 ./acme docker run -e ARCH_PROFILE=standalone -v ./acme:/workspace \ -p 127.0.0.1:8080:8080 ghcr.io/ansvar-systems/arch-mcp: init acme # serve it, then open http://127.0.0.1:8080/ui and pair docker run -e ARCH_PROFILE=standalone -v ./acme:/workspace \ -p 127.0.0.1:8080:8080 ghcr.io/ansvar-systems/arch-mcp: serve acme 01 Evaluation, 30 days One workspace, every feature, no card. It turns read-only when the thirty days end, and nothing is deleted. 02 Workspace licence, €149 a month Self-hosted: one workspace, three contributors, unlimited components, agents on the pool. On request while we measure demand. 03 Included in Team and Company One licence with Team, five plus the plane with Company, next to your documents and assessments. 04 In your plane The same model inside a customer-operated plane, on-prem or air-gapped, under the plane subscription. Design-partner pilots today. Evidence attestation for the model, a signed chain that a third party can verify without us, is built and not yet switched on for customers. Start with your own system. Thirty days on your own machine. A licence key when you keep it. Start a 30-day evaluation See plans --- ## Compliance assessments · Ansvar AI URL: https://ansvar.eu/assessments Gap analyses, DPIAs, FRIAs and conformity runs your own agent runs end to end. Every finding links to its provision; every report carries a receipt. Compliance assessments · Ansvar Assurance Assessments with the evidence attached. Gap analyses, DPIAs and FRIAs, conformity and authorisation. Your own agent runs them end to end, interviewing you where the method needs it. Every finding links to the provision it rests on, and the report carries a receipt a reviewer can verify. Run a free assessment Read a full sample The free run is a gap analysis or a DPIA on a system you describe, watermarked. Your own policies and evidence come with Team. gap analysis · NIS2 · finding 7 of 31 Supply-chain security policy is not documented GAP The information-security policy names supplier risk but sets no requirements for contracts, monitoring or offboarding. Article 21(2)(d) expects the measures to cover supply-chain security. NIS2 art. 21(2)(d) Directive (EU) 2022/2555 · Publications Office doc://policy/§4.3 Information-security policy, paragraph 4.3 · your document report receipt 0000-19ac-7e21 reviewer decision pending Illustrative example; the NIS2 citation is a served row The catalogue One method per question, with variants per regime. Each family is a fixed method your agent walks through with you. Variants carry the regime-specific requirements, so a DORA gap analysis and a NIS2 gap analysis ask different questions and cite different articles. Family Variants Input From Gap analysis NIS2 (EU, NL, PL), DORA and its ICT-contract and register variants, CRA, EU AI Act, MDR, IVDR, MDCG cyber, HIPAA, NIST CSF, R155, MiCA CASP, AMLR, US A described system; your policies and evidence on Team Free teaser · Premium · Team DPIA and FRIA GDPR DPIA with DE and SE variants, AI Act FRIA with SE variant, drone DPIA A described processing; your documents on Team Free teaser · Premium · Team Risk and incident notification Risk assessment, incident notification A described system Premium Conformity and authorisation Machinery gap, drone operator compliance, drone product conformity, SORA operational authorisation, C-UAS A described product or operation Premium The served catalogue is what your agent lists when it calls the gateway; this table follows it. Workflow directory · Threat models and TARAs moved to security risk How a run works Interview, fetch, decide, deliver. 01 Scope Your agent asks what the method needs: the system, the processing, the framework, the documents on Team. 02 Fetch Every requirement is looked up in the served corpora. Nothing is asserted from memory; a missing source is marked unresolved. 03 Decide Findings are stated against the provision and the evidence. On Team, a reviewer records a decision on each. 04 Deliver A rendered report plus a receipt that names what it rests on. Verify it later, without asking us. delivery receipt · ansvar.workflow.delivery.v1 { "receipt_id": "0000-19ac-7e21", "workflow": "gap_analysis_nis2", "findings": 31, "cited_rows": 94, "unresolved": 2, "reviewer": "decision pending", "artifacts": ["report.pdf", "report.json"], "integrity": "sha256:6f0c…a19d" } Illustrative receipt On your own documents, from Team: register a policy or a contract, and findings cite it by paragraph next to the law. Documents live in tenant-isolated EU storage under your retention policy. Beyond the run Controls, risk and the ledger. Control library One spine, mapped NIST 800-53 under CSF 2.0 with reviewed mappings to ISO 27001, C5, NIS2, DORA and CRA. Findings land on controls you already run. Security risk Its own product now Threat models, TARAs and CVE findings scored against the system you described. Security risk and threat intelligence Expert review A person signs the receipt Our team reviews a run or runs it for you, scope agreed before work starts. Expert delivery Audit ledger Signed, per tenant On Company, every run and decision is recorded in a signed ledger you can export as an audit package. Run the whole management system this way: ISMS as Code Run one assessment free. A gap analysis or a DPIA on a system you describe. Watermarked, cited, yours. Run a free assessment See plans --- ## Security risk and threat intelligence · Ansvar AI URL: https://ansvar.eu/cyber-security CVE, KEV, EPSS and CISA ICS advisory lookups on every plan, threat models and TARAs your agent runs, and a vulnerability assessment that scores each finding. Security risk and threat intelligence · Ansvar Security Know what you are exposed to, and what to fix first. Vulnerability lookups on every plan. Threat models and TARAs your own agent runs end to end. From Premium, a vulnerability assessment, an ICS advisory run or a deferral dossier scores each finding against the system you described, so the queue is ordered by exposure. Run a free threat model Read a sample threat model The free run is a threat model on a system you describe, watermarked. CVE, KEV, EPSS, exploit and CISA ICS advisory lookups come with every plan, Free included. effective_risk · portal-api · 1 of 14 findings CVE-2021-44228 Apache Log4j2 remote code execution, CVSS 10.0 KEV: listed EPSS 0.99999, top 1% most likely to be exploited in the next 30 days FIRST.org context Portal API, internet-facing, restricted data your model verdict Fix first: reachable from the internet and in the ransomware catalogue critical export Review decision recorded, exported as OpenVEX openvex CISA KEV, added 2021-12-10 EPSS read 2026-09-21 Effective risk for portal-api, finding 1 of 14. Illustrative example; the CVE and KEV rows are served records. What you get The lookup, the method, and the score that orders the queue. Your agent reads the vulnerability record, the threat knowledge behind it and the system you described, then says which finding to take first. Vulnerability lookups, on every plan CVE records, CISA KEV status, EPSS probability, known exploits, and the CISA ICS and OT advisories for the plant. Free tier included, each row cited to CISA, NVD or FIRST.org. Connect and ask search_ics_advisories · vendor: Siemens · min_cvss 9 ICSA ICSA-26-237-03 · Siemens SIMATIC IoT2050 Advanced max CVSS 10.0 · released 2026-08-25 CISA ICSA ICSA-26-258-05 · Siemens Reyrolle 7SR5 max CVSS 9.8 · 14 CVEs CISA KEV CVE-2021-44228 · Apache Log4j2 remote code execution added to the catalogue 2021-12-10 · known ransomware use CISA Served rows, read on 21 September 2026 Threat knowledge behind the finding MITRE ATT&CK and ATLAS are served on every plan, and so are CAPEC attack patterns, CWE weaknesses and D3FEND countermeasures, so a threat model cites the technique rather than recalling it. What each plan reaches search · "public-facing application" · threat-frameworks ATT&CK T0819 · Exploit Public-Facing Application ICS technique · attack.mitre.org MITRE ATLAS AML.T0049 · Exploit Public-Facing Application adversarial machine learning · atlas.mitre.org MITRE ATLAS AML.T0093 · Prompt Infiltration via Public-Facing Application adversarial machine learning · atlas.mitre.org MITRE Served rows, read on 21 September 2026 The catalogue One method per question, with variants per system. Each family is a fixed method your agent walks through with you. The variants carry what the domain expects, so an automotive TARA and a drone threat model ask different questions and cite different sources. Family Variants Input From Threat model STRIDE, LINDDUN, AI systems, OT, drones A described system, or your architecture workspace brought by your agent Free teaser · Premium TARA Automotive (ISO/SAE 21434, R155), UAS, rail, robot, OT A described system, or your architecture workspace brought by your agent Premium Adversary tabletop and vulnerability assessment Vulnerability assessment and deferral dossier (Premium), adversary tabletop (Team) A described system; findings and scoring context inside the run Premium · Team ICS advisory to risk A CISA ICS or OT advisory turned into scored findings for your plant An advisory reference and the system it touches Premium The served catalogue is what your agent lists when it calls the gateway; this table follows it. Workflow directory · Gap analyses, DPIAs and conformity runs How a scored decision works Look it up, place it in your system, score it, decide, export. 01 Look up Your agent fetches the CVE record, its KEV status, its EPSS probability and any ICS advisory that names it. Nothing is answered from model memory. 02 Place it The finding is placed in the system you described: which component runs it, whether it faces the internet, what data sits behind it. 03 Score From Premium, inside a vulnerability assessment, an ICS advisory run or a deferral dossier, each finding is scored in that context. The vulnerability assessment and the deferral dossier also compare the candidate fixes. 04 Decide From Team, a reviewer records the disposition against the finding, with the reason kept as written. 05 Export From Team, the dispositions leave as an OpenVEX document your build and your customers can read. effective_risk · portal-api · 1 of 14 findings CVE-2021-44228 Apache Log4j2 remote code execution, CVSS 10.0 KEV: listed EPSS 0.99999, top 1% most likely to be exploited in the next 30 days FIRST.org context Portal API, internet-facing, restricted data your model verdict Fix first: reachable from the internet and in the ransomware catalogue critical export Review decision recorded, exported as OpenVEX openvex CISA KEV, added 2021-12-10 EPSS read 2026-09-21 Effective risk for portal-api, finding 1 of 14. Illustrative example; the CVE and KEV rows are served records. The living threat model lives in the architecture workspace, which you host yourself. Threats attach to components, and when a component changes the assessments that rest on it are marked stale and a review is proposed. Living security architecture Beyond the run The model, the controls and the people. Living threat model Your architecture workspace holds the components and the threats that attach to them. It runs on your own machine or in your cluster, never hosted by us. The workspace Control library From Team: one NIST 800-53 spine under CSF 2.0, with reviewed mappings to ISO 27001, C5, NIS2, DORA and CRA. A finding lands on a control you already run. The spine and its mappings Expert review Our team reviews a threat model or a TARA, or runs it for you. Scope agreed before work starts. Expert delivery Plans Lookups and a teaser run on every plan. The catalogue from Premium. Free and Solo read the vulnerability record and the ATT&CK technique. Premium runs the threat model, the TARA and the vulnerability assessment; scoring happens inside a vulnerability assessment, an ICS advisory run or a deferral dossier, not in every run. Team adds your own scoring contexts, recorded review decisions and OpenVEX export. Every plan and limit Run a free threat model. On a system you describe. Watermarked, cited, yours. Run a free threat model For product security teams --- ## ISMS as Code · Ansvar AI URL: https://ansvar.eu/isms-as-code The management system as a repository your agent operates: interviews for state and evidence, second-model review, enforced approval, ISO 27001 or NIST-keyed. ISMS as Code · annual contract The management system as a repository. Your agent interviews for state and evidence and keeps the bookkeeping. Your people approve every change. The merge history is the audit trail. ISO 27001 or NIST-keyed, in the git you already run. Ask about a pilot Pricing isms · pull request #142 · A.5.26 incident response evidence controls/ A.5.26 response to incidents: evidence added, owner named passes gaps/ GAP-018 closed, linked to the incident drill of 2026-09-04 passes review Second-model review: no standard text in the diff passes approval Responsible person: CISO, required waiting Illustrative example Why a repository Engineering-led companies keep everything else in git. Now the management system too. Document kits are a commodity and SaaS GRC keeps your evidence in its database. A repository gives you review, history and ownership for free, and lets your own agent do the interviewing. What is in it Controls, gaps, decisions and the interview plan, one file each, with the responsible person named on every control. No standard text is ever stored: the standard is read through the licensed add-on, never copied. isms-as-code · repository docs/controls/ One file per control: statement, owner, evidence plan, status reviewed docs/gaps/ GAP register, each gap linked to its control and its plan reviewed docs/decisions/ Management decision records, dated, with the evidence cited reviewed plan/ The agent's interview plan: what to ask whom, and when running CODEOWNERS The responsible person approves every change on the exact commit enforced How a change lands The agent proposes in a pull request. A second model reviews it for standard text and consistency. The responsible person approves on the exact commit, enforced by the repository, and the merge is the record. isms · pull request #142 · A.5.26 incident response evidence controls/ A.5.26 response to incidents: evidence added, owner named passes gaps/ GAP-018 closed, linked to the incident drill of 2026-09-04 passes review Second-model review: no standard text in the diff passes approval Responsible person: CISO, required waiting Illustrative example The proof We run our own on it. Ansvar's ISO 27001 management system is this repository, operated by our own agent sessions. BSI assessed it at Stage 1 on 31 August 2026 and recorded one minor finding. Stage 2 is scheduled for October 2026. Stage 1 is an assessment, not a certificate. We will say so plainly until the certificate is issued. How the pilot runs Ten weeks, €6,000, credited when you convert. 01 Install The template repository lands in your GitHub with the approval rules on. You buy the standard through the add-on for the people who read it. 02 First interview wave Your agent asks the owners for state and evidence, control by control, and records what it learns as pull requests. 03 First gap register Gaps land with owners and plans. The register is a merge, not a spreadsheet. 04 Decide Convert to the annual contract and the pilot fee is credited in full. Up to four delivery days from us are inside the pilot. ISO 27001 or NIST-keyed €9,000 a year, workspace included. Content pack, agent plan, quarterly pack updates, second-model review recipe, statement-of-applicability importer. With maintained mappings €12,000 a year. The reviewed ISO to 800-53 edge set and operation across both keys, maintained as the standards move. Put the management system where the work is. A paid pilot, fixed in scope, credited on conversion. Ask about a pilot See the four products --- ## Deploy · Ansvar AI URL: https://ansvar.eu/deploy Hosted by Ansvar in the EU, in your own Kubernetes, or on-prem and air-gapped with signed content packs. The same gateway, the same contracts. Deploy Hosted by us, or inside your perimeter. The same gateway and the same contracts wherever it runs. Hosted is available today. Customer-managed deployment, in your Kubernetes or fully air-gapped, runs as design-partner pilots until the production scope is agreed. Three ways to run Ansvar Hosted EU infrastructure, operated by Ansvar. Available; start free. available Your Kubernetes Ansvar runs in your own cluster; law and regulation are still answered from the central gateway. design-partner pilots On-prem and air-gapped No call home. Content packs, licence file and updates delivered offline on an annual contract. design-partner pilots Side by side What changes when it moves. Hosted Your Kubernetes On-prem and air-gapped Where it runs EU infrastructure, Hetzner Your cluster Your perimeter, no call home Operator Ansvar You, with our runbooks You, with our runbooks Corpus delivery Served from the central gateway Corpus queries served from the central gateway Signed content packs, delivered offline Updates Continuous Signed release train, quarterly Signed release train, imported by you Licensed standards Add-on per seat Add-on per seat, served centrally Add-on per seat, served centrally; never in a pack Support Plan terms Business hours, agreed in the pilot Business hours, agreed in the pilot Status Available Design-partner pilots Design-partner pilots Price Published plans Annual contract Annual contract Availability boundary. Ansvar publishes no general customer-managed price, SLA or installation package today. The design partner and Ansvar agree the production scope before either treats the deployment as available. A deployable build exists and runs in our CI; it is not self-serve. Shared responsibility Who does what in a customer-managed plane. The plane is a package you operate. We sign what ships; you run where it runs. The full responsibility matrix is part of the pilot agreement. Responsibility Hosted Customer-managed Model inference Your AI provider Your model environment Evidence storage Ansvar, tenant-isolated You: storage, keys, retention Audit evidence Operational records; Company signed receipts In-plane ledger; keys and verification agreed Egress Not applicable Default-deny, exact allowlist, fail-closed at boot Recovery Ansvar operates You operate; procedures agreed Licensed standards Served centrally Served centrally; never shipped in a pack The pilot Eight to twelve weeks, €15,000, credited when you convert. Fixed scope, explicit prerequisites and acceptance tests, up to 5 delivery days from us. The pilot licence expires at the pilot end: serving continues, imports and upgrades refuse. Design-partner status is a named discount on the fee, recorded per deal. Edge The plane in your cluster with corpus queries served from the central gateway. Your documents and ledger stay inside. Full Corpora delivered as signed content packs; no call home. Content-pack refreshes at the cadence the contract states. Second plane Disaster recovery or a second site is a second line item on the same contract. Annual contract, design-partner pilots open. Tell us the cluster, the perimeter and the date you need it by. Discuss a pilot Pricing --- ## Trust · Ansvar AI URL: https://ansvar.eu/trust How Ansvar handles your data, where it runs, what it publishes about its own quality, and where its certifications stand. Trust Built to be checked, not believed. Every answer cites or refuses. Every report carries a receipt. Limits and prices are published. And once a month we will publish how the service performed, with the denominators. Security details Subprocessors quality report · monthly · first publication pending coverage Jurisdictions served, last successful upstream check, last incorporated change, known gaps pending reliability Availability, error rate, p50 and p95 latency by call class: lookup, search, workflow pending benchmark Frozen questions each month: retrieved, wrong, refused correctly, refused wrongly, with denominators pending incidents Customer-impacting incidents: impact, duration, correction, recurrence prevention pending Quality report Four things, measured, monthly. Coverage and freshness, reliability by call class, a frozen-question benchmark, and incidents. Values appear on first publication; until then each block says pending rather than showing a number we have not published. A benchmark measures performance on those questions. It does not establish legal completeness or the right application to your case. Refusal rate on its own is not a quality measure; the benchmark reports right and wrong refusals separately. Data handling Your questions are not stored by the corpora. Corpora Never store client data Corpus servers answer from law, regulation and standards. Your question is not stored there. Documents Tenant-isolated, EU Documents you register on Team and Company live in tenant-isolated EU storage under your retention policy. Hosting EU core Hetzner, EU. Edge and backups are disclosed on the subprocessors page. No tracking cookies on this site. Inference Your model, your provider Ansvar serves evidence to the AI client you already run. The model and its provider are yours. Certifications and audits Where we stand, in plain words. ISO 27001 Stage 1 assessed by BSI on 31 August 2026, one minor finding. Stage 2 scheduled for October 2026. Status as of September 2026; Stage 1 is an assessment, not a certificate. SOC 2 Not planned. We say so rather than list it as coming. Cybersecurity Made in Europe Labelled by ECSO. Ansvar Systems AB, registered in Sweden, org.nr 559547-2225. Independent listings and reviews: Recognition . How we will measure ourselves: Assurance scorecard methodology . Notice mechanisms for content claims: notice and complaints and DMCA . Requests from courts, police and other authorities: government requests . Security questionnaires, DPAs, subprocessors. Answered, not deflected. Contact Read the DPA --- ## Build on Ansvar · Ansvar AI URL: https://ansvar.eu/developers One MCP endpoint, published contracts, receipts you can verify, service credentials for headless agents, and an export guarantee. For products and partners. Build on Ansvar · evidence infrastructure One endpoint that cites every row. Point your agent or your product at the gateway. Results carry source URL, publisher and licence; reports carry a receipt you can verify later. The contracts are published and versioned, and your data leaves with you. Quickstart Partner enquiry # any MCP client url https://gateway.ansvar.eu/mcp auth OAuth 2.1, dynamic client registration ask "Using Ansvar, which DORA articles apply to ICT third-party risk?" returns rows · source_url · publisher · license · receipt The contracts What a row promises, and what a report promises. Two published contracts, both versioned. Break either and the gateway fails closed rather than serving a thinner answer. Serving contract Every served row carries a citation triple: the original publisher's URL, the publisher, and a licence code from the published catalogue. A lookup hint on a search row re-fetches the same row with the same triple. Rows that cannot carry the triple are withheld with a visible reason. Read the contract in the docs search row · _citation "_citation": { "source_url": "https://data.europa.eu/eli/reg/2016/679/oj", "publisher": "Publications Office of the European Union", "license": "EUR-Lex-Decision-2011-833", "lookup": { "tool": "get_provision", "args": { "source_id": "eu-regulations", "canonical_ref": "GDPR:art_17" } } } Delivery receipt Every report response carries a server-authored receipt: the executive summary verbatim, integrity metrics computed or marked unsupported, every attention item uncapped, artifact links. Your agent relays it unchanged, so what the reader sees is what the server produced. See it on an assessment delivery receipt · ansvar.workflow.delivery.v1 summary Verbatim executive summary server-authored metrics Computed, or marked unsupported. Never zero for a metric the report does not carry. typed attention Every item, uncapped, verbatim complete artifacts Report links with content hashes hashed Verification contract Send back the references a draft relies on and verify_citations re-retrieves each one under your own scope, checks the producer-declared identity of the row it got, and compares your quotation with the body. One verdict per subject — quote_checked and reference_resolved for the two ways a subject can hold, then quote_mismatch , no_quotation_submitted , identity_mismatch , identity_absent , reference_unparseable , not_served , withheld and unavailable — and coverage is advertised rather than assumed, so a subject the identity seam does not cover refuses instead of passing. Available on every plan. Signed evidence attestations are not issued yet: a call with attest=true returns the ordinary verdicts marked attestation_refused . See a verified set verify_citations(subjects=[ { "subject_id": "s1", "source_id": "eu-regulations", "reference": "GDPR:art_17", "quotation": "The data subject shall have the right to obtain ..." } ]) -> { "subject_id": "s1", "verdict": "quote_checked" } Query receipt What was served. On Company: a signed, tamper-evident record of what was asked, what came back and when — read it with get_receipt , list with list_receipts , check it with verify_receipt . Delivery receipt What the reader was handed. The block above: server-authored, relayed unchanged with a report, so the summary, the metrics and the attention items cannot be trimmed on the way to a person. Audit ledger What an auditor can verify without us. On Company: per-tenant receipts in a cryptographic ledger, exported as an offline-verifiable package and decrypted client-side with your own key. Running headless Agents on seats, credentials you rotate. 01 Service credentials From Premium, create org-owned credentials for n8n, CI jobs and scheduled monitors. Each gets the same tool surface as a signed-in person. On Premium each takes a seat; Team includes five per workspace that take none. Rotate and revoke any time; revoking works on every plan. 02 Published limits Calls per day, concurrency and requests per minute are published per plan. A refusal returns your usage, the reset time and the upgrade path in a shape your agent can act on. 03 Skills and connectors Compiled, checksummed workflow skills for Claude, Copilot and Cursor; the Microsoft 365 agent; the Gemini CLI extension. Every example question leads with Using Ansvar. 04 Export guarantee Audit packages, OpenVEX, git-native ISMS, a local architecture workspace. What you built on Ansvar leaves with you. Which route applies to you Automate internally, deliver to clients, or embed in what you sell. Three different permissions, and the difference matters before you plan a dependency. The terms are the authority; this is the short read. Internal automation Included in your plan. Your own agents, CI jobs and monitors call the gateway for your own business. Seats and credentials are the only thing to size. Client work Included, within section 8a. You may produce deliverables for your clients on your own responsibility. What you may not do is hand a client the content itself — a feed, an extract series or a recurring compilation. Embedding and reselling By written agreement. Putting Ansvar inside a product you sell, or giving third parties outputs on demand, needs a partner agreement first. Ask before you build the dependency, not after. The binding text is sections 8a, 12 and 13 of the terms . For an embedding or reseller route, start with a partner enquiry . One integration, measured What it looks like under someone else’s agent. A European legal-expenses insurer is evaluating Ansvar underneath its own copilot. The shape below is measured from the gateway’s own telemetry over thirty days, not from a questionnaire. They kept their stack. We are the layer underneath. Two channels, both on service credentials: an agent built in Microsoft Copilot Studio on the insurer’s own Power Platform identity, and the team’s own Python harness. Neither runs on our interface, and neither sends us a model. The workload is national law and case law — court decisions, disciplinary rulings, statutes and the preparatory works behind them. About half the calls are exact-reference lookups of a named article or decision; the other half are searches that fan out across the jurisdiction. Legislative history arrives inside those searches rather than through a lookup of its own. In thirty days neither channel hit a quota, a rate limit or a licence refusal, including one unattended run of roughly a thousand calls inside an hour. Where a decision corpus was withdrawn pending a privacy assessment, the questions that needed it came back empty and said so, rather than being filled in from somewhere else — visible in their logs as it happened. The limits that run underneath it thirty days · one evaluating organisation clients Copilot Studio agent · the team’s own Python harness their stack auth Two service credentials, each on its own seat headless calls Roughly half exact lookups, half fan-out searches measured refusals No quota, rate-limit or licence refusal in the window none gaps A withdrawn corpus answered empty, not approximately visible Why not build it yourself The part that never stops: keeping the sources true. Retrieval is a weekend. What follows is the standing cost, and it is the work Ansvar takes off your roadmap. 01 Source integrations Every publisher has its own site, its own bulk feed, its own quirks — and changes them without telling you. We hold the fetchers and the parsers. 02 Licensing and provenance Each source is cleared for commercial reuse before a single fetch, and every served row carries its publisher, URL and licence code. 03 Coverage and freshness What is in force, what changed, when each corpus was last refreshed — tracked per source, with the age published rather than assumed. 04 Verification machinery Citation round-trips, content hashes, withheld-row reasons, refusals that say why. The plumbing that makes an answer checkable. What a production month costs Seats, credentials, runs. Nothing metered in the dark. An agent is a seat like a person is a seat, and every limit that shapes the bill is published. Premium, per seat Each holder is a seat, person or agent, with the same tools and concurrency. Runs past the monthly allowance are never billed — the ceiling refuses instead. Team, per seat Each seat is a person or an agent credential, on one pooled quota. Five service credentials come with the workspace without taking a seat; a sixth takes one. The runs Team's pooled assessment allowance is the only metered line: past it a run is priced, and the hard stop refuses rather than billing on. Worked totals for a busy workspace, and every quota the gateway enforces, are on pricing and limits . Connect in two minutes. Free for businesses. OAuth in the client you already run. Read the quickstart Published limits --- ## What Ansvar does · Ansvar AI docs URL: https://ansvar.eu/docs/overview Every capability Ansvar serves through one MCP connection: what each does, what you get back, which plan includes it, and the guide to read next. What Ansvar does Ansvar gives your AI assistant cited access to EU and national law, standards and security data, so its compliance answers come with a source you can check instead of a guess. You connect it once to Claude, Copilot, ChatGPT, Cursor or any assistant that supports MCP (the open connector standard). Your assistant then calls Ansvar's tools for law, vulnerability data, structured assessments and audit evidence. When a source fails or holds nothing, Ansvar returns an explicit error or gap instead of an empty answer, and tells your assistant not to fill the gap from memory. Find out what your account can do Paste this into your connected assistant: Copy Using Ansvar, run get_my_capabilities and describe_capabilities, then tell me which capability areas my plan includes and which tools each one gives me. Not connected yet? Quickstart takes you from sign-up to a first cited answer. What you can do Law and regulation research Search EU and national law, regulations and standards by country, framework, sector or source, and fetch one article word for word. You get: The article text with a link to the official publisher, the publisher's name and the licence, so you can check the source yourself. Plans: Every plan. Free searches one source or one country at a time; Solo and above search many sources and countries in one call, within what your plan and add-ons include. Guide: Quickstart Try: Copy Using Ansvar, retrieve GDPR Article 17 and show its official source link. Tools behind it search , get_provision , list_coverage , describe_capabilities Case law, legislative history and regulator guidance Adds court decisions, preparatory works and guidance from regulators to the same search, and fetches one decision or document by reference. You get: Decisions and documents with their court or publisher, date and citation. Plans: Premium, Team and Company. Guide: Case law and legislative history Try: Copy Using Ansvar, find recent Dutch court decisions on dismissal for an urgent reason and cite each one. Tools behind it search , get_decision , get_preparatory_work , search_guidance Claim and citation checking Fetches the articles your assistant cited again and compares its quotes and conclusions with the source text. You get: One verdict per citation, or how strong each conclusion is given its sources. Never a legal verdict. Plans: Every plan. Guide: Validate a claim Try: Copy Using Ansvar, check the GDPR citations in your last answer against the source text before I rely on them. Tools behind it validate_claim , verify_citations , validate_citation Structured assessments (workflows) Step-by-step assessments your assistant runs with you: threat models, gap analyses, DPIA and FRIA, TARA, risk assessments, tender reviews and more. You get: A report whose findings cite their sources or are marked unresolved, plus a short summary your assistant shows you word for word. Plans: Every plan, with more assessment types and runs on higher plans. See the plan table and the workflow list below. Guide: Workflows Try: Copy Using Ansvar, run a NIS2 gap analysis for our managed IT services company and deliver the report. Tools behind it scope_workflow , list_workflow_types , start_workflow , generate_report Your documents Upload policies, contracts and evidence, then cite them next to the law. You get: Citations that point at one paragraph of your own document and record a fingerprint of its text, so a later edit shows up. Plans: Team and Company. Guide: Cite your documents Try: Copy Using Ansvar, review our uploaded supplier contract against GDPR Article 28 and cite the paragraphs you rely on. Tools behind it register_document_init , get_document_segments , resolve_document_segment Your organisation's standards Search and quote security standards from your own library the same way you query law. You get: Clause text with its reference and page, and a citation that points at that clause. Plans: The search tools are on Premium, Team and Company. Uploading a standard is not open to customers yet. Guide: Org standards library Try: Copy Using Ansvar, search my org standards library for access review requirements and quote the clauses. Tools behind it list_org_standards , search_org_standards , get_org_standard_clause Regulatory intelligence Tracks what regulators and the EU Official Journal newly published and which dated obligations are coming, and finds EU acts by number or title. You get: Publication records linked to the publisher, deadline rows cited to the act that sets the date, and a report of what the monitor watches. Plans: Monitor status, the EU act finder and change records on every plan. New publications and deadlines on Premium and above. Guide: Regulatory intelligence Try: Copy Using Ansvar, list the EU regulatory deadlines coming in the next six months for a company in Germany. Tools behind it get_regulatory_intelligence_status , search_regulatory_updates , get_regulatory_deadlines , discover_eu_legislation Vulnerability intelligence Looks up CVEs, CISA's known-exploited list, exploit likelihood scores, public exploits and CISA advisories for industrial systems. You get: CVE and advisory records with scores, dates and source links, and when each data feed last updated. Plans: Every plan, with the CAPEC, CWE and D3FEND attack-pattern catalogues. Guide: Vulnerability intelligence Try: Copy Using Ansvar, is CVE-2024-3400 in CISA KEV, and what is its EPSS score? Tools behind it search_cve , get_cve_details , check_kev_status , search_ics_advisories Effective risk (experimental) Rescores a CVE for one of your assets and its controls, ranks which control investment removes the most risk, and records reviewed exploitability decisions as OpenVEX. You get: An adjusted score with the rule behind each change, a ranked investment list, and OpenVEX documents. Plans: Team and Company can use effective risk directly. On Premium you cannot call it yourself: the vulnerability assessment, deferral dossier and ICS advisory-to-risk workflows use parts of it for you during a run. Guide: Effective risk Try: Copy Using Ansvar, score CVE-2024-3400 against our internet-facing firewall with management access limited to a jump host. Tools behind it effective_risk_inline , simulate_control_investment , export_vex Control library and crosswalks One control set, based on NIST SP 800-53 rev. 5, mapped to ISO 27001, NIS2, DORA, CRA and other frameworks. You get: Controls, the framework requirements each one maps to with how closely and whether a person has reviewed the link, and crosswalks from one framework to another. Plans: Team and Company. Guide: Control library Try: Copy Using Ansvar, crosswalk NIS2 Article 21 to ISO 27001 through the control library. Tools behind it list_controls , get_control , crosswalk , coverage EU regulation engines Decides which EU regulations apply to a product or company, compares how regulations treat one topic, and lists the evidence an auditor expects. You get: A cited verdict per regulation, side-by-side requirements, and evidence checklists. Plans: Team and Company. On Premium, a deferral dossier workflow uses the applicability check for you. Guide: EU regulation engines Try: Copy Using Ansvar, check which EU regulations apply to a connected home camera sold in the EU. Tools behind it check_applicability , compare_requirements , get_evidence_requirements , map_controls Audit ledger and receipts Keeps a tamper-evident record of your organisation's Ansvar calls, sealed each day with an independent timestamp. You get: Receipts you can list, verify and decrypt, and an audit package your auditor can verify without access to Ansvar. Plans: Company. Guide: Audit ledger Try: Copy Using Ansvar, export our audit package for last month so our auditor can verify it offline. Tools behind it list_receipts , get_receipt , verify_receipt , export_audit_package Plans and capabilities Swipe sideways to see every plan. Capability Free Solo Premium Team Company Search and fetch law, regulations and standards Partial ¹ Yes Yes Yes Yes Check citations and claims Yes Yes Yes Yes Yes Vulnerability data (CVE, KEV, EPSS, ICS advisories) Yes Yes Yes Yes Yes Monitor status, EU act finder, change records Yes Yes Yes Yes Yes New regulatory publications and upcoming deadlines No No Yes Yes Yes Case law, legislative history, regulator guidance No No Yes Yes Yes MITRE ATT&CK, ATLAS, CAPEC, CWE, D3FEND Yes Yes Yes Yes Yes IETF RFCs No No Yes Yes Yes Assessment runs (workflows) 1 run/month, 7 types 2 runs/month, 7 types 5 runs/month, most types ² 20 runs per seat/month, all types All types ³ Assessment report formats Watermarked HTML or PDF, or JSON Watermarked HTML or PDF, or JSON JSON, HTML, PDF, Word JSON, HTML, PDF, Word JSON, HTML, PDF, Word Upload and cite your own documents No No No Yes Yes Search your organisation's standards No No Partial ⁴ Partial ⁴ Partial ⁴ Effective risk No No Partial ⁵ Yes Yes Control library and crosswalks No No No Yes Yes EU regulation engines No No Partial ⁶ Yes Yes Audit ledger and receipts No No No No Yes Free searches one source or one country at a time. Solo and above search many sources and countries in one call, within what your plan and add-ons include. Premium runs every assessment that works from your description of a system. Assessments that read your uploaded documents, and a few specialist types, need Team. Company runs are counted but have no fixed monthly limit; use falls under the fair-use terms of your contract. The search tools are on these plans, but uploading a standard is not open to customers yet, so the library starts empty. On Premium you cannot call effective risk yourself: the vulnerability assessment, deferral dossier and ICS advisory-to-risk workflows use parts of it for you during a run. On Premium, a deferral dossier workflow uses the applicability check for you. The other engines need Team. Quotas and prices are on pricing . A tool outside your plan does not appear in your assistant's tool list; if your assistant calls it anyway, the error names the plan that includes it. Add-ons on any plan ISO standards. SIS-licensed ISO standards (27001, 27002, 27005, 42001, 21434), bought one standard at a time on any plan and searched like any other source. See ISO standards add-on . Sources served on instruction. Some court-decision sources are not searchable on any plan by default. Ansvar serves them only to an organisation that instructs it in writing, and grants start after our legal review. See Sources served on instruction . Which assessments each plan can run Free and Solo (1 and 2 runs a month), on a system you describe: STRIDE threat model Gap analysis: general, NIS2, DORA, CRA and the EU AI Act DPIA Premium (5 runs a month) adds: LINDDUN privacy threat model, and threat models for AI/ML systems, operational technology (industrial control systems) and drones Threat analysis and risk assessment (TARA) for vehicles, robots, rail, operational technology and drones, and a counter-drone resilience assessment Fundamental rights impact assessment (FRIA) under the EU AI Act, the German and Swedish DPIA, and a DPIA for drone data capture Gap analyses for Dutch NIS2, medical devices (MDR, IVDR, medical-device cybersecurity), machinery, UNECE R155, AMLR and MiCA, and drone operator and product rules SORA, the risk assessment behind a drone operating authorisation in the EU specific category Enterprise risk assessment Vulnerability assessment, vulnerability deferral dossier and ICS advisory-to-risk Team and Company (every type) add: Document review with paragraph citations Public tender review and tender audit (general, Sweden, Netherlands) DORA ICT contracts and DORA register of information Polish NIS2 gap analysis Adversary tabletop exercise Scoped threat update for an existing threat model Defensibility Assessment (experimental): tests a proposed legal or compliance decision against supporting and contrary authority Supplier Assurance Review (experimental): checks a supplier's certificates and assurance reports against law, standards and your own policy Your assistant can list the live set with list_workflow_types . The Workflows guide covers how a run works and how the report is delivered. Why Ansvar refuses instead of guessing A wrong compliance answer costs more than no answer. Each capability on this page reports a gap or names the unavailable source rather than filling the hole with a guess. Tell your assistant to pass those messages on to you; see Instruct your agent for the wording. Also available self-hosted The architecture workspace keeps a reviewed model of your security architecture (services, data flows, trust zones, controls, threats and the obligations they meet). You run it yourself, on your own machine or inside your own Ansvar deployment; the hosted service at ansvar.eu does not run it. See the tool reference . Next Quickstart --- ## Vulnerability intelligence · Ansvar AI docs URL: https://ansvar.eu/docs/guides/vulnerability-intelligence Look up CVEs, CISA KEV status, EPSS scores, public exploits and CISA ICS advisories through Ansvar, with the sync time of every feed. Every plan. Vulnerability intelligence Look up a CVE, check whether attackers are exploiting it, and find the CISA advisories for industrial products, from data feeds Ansvar keeps in sync. Plan Every plan, Free included. Try it Copy Using Ansvar, look up CVE-2024-3400: give me the CVSS score, whether it is in CISA KEV and its due date, the EPSS score, and any public exploits. Tell me when each feed last synced. More examples: Copy Using Ansvar, list critical CVEs for OpenSSL 3.0.7 and mark which ones are in CISA KEV. Copy Using Ansvar, find CISA ICS advisories for Siemens published since 2026-01-01 with CVSS 9 or higher, then open the most recent one and list the affected product versions. Copy Using Ansvar, check this list of CVE ids in one batch and sort them by EPSS score: CVE-2023-4966, CVE-2023-34362, CVE-2024-21762. What comes back Your assistant gets structured records, not prose: the CVE, its severity score, whether it is on CISA's list of known exploited vulnerabilities, how likely exploitation is, and links to the source. It also learns when each data feed last updated, so it can tell you how current the answer is. For developers, the fields to read: CVE id, CVSS vector and score, CPE mappings and references KEV membership with the required action and due date EPSS probability of exploitation in the next 30 days and its percentile Exploit references (Metasploit, ExploitDB, GitHub proofs of concept) ICS advisory id, affected vendors and product version ranges, referenced CVEs and the CSAF source URL Per-feed last sync time, data age, record count and health state (current, stale, critical) Which plan Every plan, Free included, along with the CAPEC, CWE and D3FEND catalogues as searchable sources, for attack-pattern and weakness context. Rescoring a CVE for your own asset is effective risk : Team and Company can use effective risk directly. On Premium you cannot call it yourself: the vulnerability assessment, deferral dossier and ICS advisory-to-risk workflows use parts of it for you during a run. Tools search_cve finds CVEs by keyword, severity and score. get_cve_details returns one CVE in full, with any ICS advisories that reference it. search_by_product lists CVEs for a product and version. batch_search fetches up to 100 CVEs in one call. check_kev_status says whether a CVE is on CISA's known-exploited list. get_epss_score gives the chance of exploitation in the next 30 days. get_exploits lists public exploit code for a CVE. search_ics_advisories finds CISA advisories for industrial and medical products. get_ics_advisory returns one advisory with affected product versions. get_data_freshness reports when each feed last updated. Limits The data is as fresh as the last sync. Before a decision that depends on today's KEV or EPSS state, have your assistant check feed freshness; a stale or critical feed is reported as such. An empty search means no record matched your terms. It does not prove a product has no vulnerabilities. CVSS, KEV and EPSS describe a vulnerability in general, not its risk in your environment. Inside assessments The vulnerability assessment, deferral dossier and ICS advisory-to-risk workflows (Premium and above) run these lookups for you. See Workflows . Previous Service credentials Next Regulatory intelligence --- ## Effective risk · Ansvar AI docs URL: https://ansvar.eu/docs/guides/effective-risk Rescore a CVE against your asset and controls, simulate which control investment removes the most risk, and export reviewed VEX statements. Experimental. Effective risk Adjust a CVE's severity for one of your assets, rank which control investment removes the most risk when you cannot patch, and record reviewed exploitability decisions as OpenVEX. Plan Team and Company can use effective risk directly. On Premium you cannot call it yourself: the vulnerability assessment, deferral dossier and ICS advisory-to-risk workflows use parts of it for you during a run. Experimental Every effective-risk tool labels its output experimental. A qualified security and safety expert must verify a result before anyone acts on it. Try it Copy Using Ansvar, score CVE-2024-3400 against our edge firewall: it is internet-facing, management access is restricted to a jump host, and GlobalProtect is disabled. Show which rules changed the score and why. More examples: Copy Using Ansvar, for these five CVEs on our PLC network that we cannot patch this year, simulate which control investment removes the most effective risk and list the findings no control can move. Copy Using Ansvar, record my acceptance of the not_affected disposition for that last result, then export it as an OpenVEX document. What comes back A score adjusted for your asset, with the rule behind each change, so you can see why the number moved. Ansvar stores none of it: your assistant gets a signed token with each result, and you keep the tokens you want to review or export later. For developers, the fields to read: Adjusted score, the provenance of each changed metric, and the policy rules that fired ( verbose=true adds the rules that did not fire and why) review_token , or review_token_unavailable saying why a result could not be signed Simulation per investment: findings whose score moves (with before and after vectors), findings that gain a compensating-control marker, reductions the policy vetoes, and findings no control can move Review: a signed review event and a new token; export: an OpenVEX document Which plan Team and Company can use effective risk directly. On Premium you cannot call it yourself: the vulnerability assessment, deferral dossier and ICS advisory-to-risk workflows use parts of it for you during a run. Vulnerability assessment runs use the batch scorer and the investment simulation. Deferral dossier runs use the batch scorer, the investment simulation and the applicability check. ICS advisory-to-risk runs use the single and batch scorers. Free and Solo do not include effective risk. Tools effective_risk_inline scores one CVE against an asset you describe in the call. effective_risk_inline_batch scores several CVEs the same way. effective_risk scores against a full asset configuration you send. list_scoring_policies lists the rule sets the scorer can apply. simulate_control_investment ranks control investments across a set of findings. record_review_decision records a person's accept or reject decision. export_vex turns reviewed decisions into an OpenVEX document. Limits A simulation is hypothetical and unsigned, never a served score. The policy refuses some reductions outright, for example on a CVE on CISA's known-exploited list or a malicious-code weakness; the result shows them as vetoed. A control counts as evidenced only when its evidence points at a paragraph of a document you uploaded. You cannot declare it evidenced yourself. Only a person signed in to their own session can record a review decision; agent and service credentials are refused. Ansvar keeps no asset configurations and no results. Send the configuration with each call. An OpenVEX export refuses a statement that is not valid OpenVEX, such as one with no product identifier. Start from the public facts CVE, KEV, EPSS and exploit data are on every plan; see vulnerability intelligence . Previous EU regulation engines Next Audit ledger --- ## Regulatory intelligence · Ansvar AI docs URL: https://ansvar.eu/docs/guides/regulatory-intelligence Track new regulatory publications, upcoming obligation dates and EU acts through Ansvar, and check what the monitor watches before you rely on it. Regulatory intelligence Find out what regulators and the EU Official Journal just published, which dated obligations take effect soon, and which EU act a news item refers to. Plan Monitor status, the EU act finder and change records: every plan. New publications and deadlines: Premium, Team and Company. Try it Copy Using Ansvar, check the regulatory monitor status first, then search for new EDPB publications on data transfers from the last 30 days and give me each one with its publisher link. More examples: Copy Using Ansvar, list the regulatory deadlines for the Netherlands between today and the end of next year, including the EU-level rows. For each curated row, fetch the provision named in its basis. Copy Using Ansvar, find the EU act with CELEX 32024R1689, tell me its currency state, and give me the search and lookup calls to read its provisions. What comes back Each publication and each deadline comes with a link to the official publisher, so your assistant can point you at the source instead of paraphrasing it. A deadline links to the act that sets the date, and the act's text is one more lookup away. For developers, the fields to read: Publication rows: title, publisher, URL, publication and observation dates, official identifiers such as CELEX, and matched_on (a match on the publisher's own terms is not a title match) Deadline rows: date_source . Only curated rows carry the obligation statement and its basis (the provision that states the date); publisher-metadata rows carry the date, instrument, event kind and citation only Deadline responses: completeness , and a separate pending array for bills when you ask for it Monitor status: enrolled sources, last successful sync and freshness state per source EU act finder: per-edition currency, any hold reason, and the next search and lookup calls Which plan Every plan: what the monitor watches, the EU act finder, and change records from the sources that publish them. Premium, Team and Company: searching new publications, fetching one publication record, and the deadlines calendar. Tools get_regulatory_intelligence_status reports which sources the monitor watches and how current each is. search_regulatory_updates searches recent official publications. get_regulatory_update fetches one publication record. get_regulatory_deadlines lists dated obligations that are coming, soonest first. discover_eu_legislation finds an EU act by CELEX or ELI number, title or topic. get_changes returns change records from sources that publish them. Limits The deadlines calendar is curated, not complete. Every response says so, and a missing row does not mean a missing obligation. A date enters the calendar only when the law itself states it. Bills and unsigned acts appear only on request, with their stage in the legislative process and never a date. The monitor covers the sources it has enrolled. A source it does not watch, or whose feed is failing, is not covered, and the status tool says so. Check it before you read anything into an empty search. The EU act finder matches words, not meaning. Try the act's official title or number when a topic search misses. A change record shows that a text changed. It is not by itself a legally identified amendment. Where the text comes from These tools tell you what changed and when. Your assistant reads the act's articles with the normal search and article lookup, which cite the official source. Previous Vulnerability intelligence Next Case law and legislative history --- ## Case law and legislative history · Ansvar AI docs URL: https://ansvar.eu/docs/guides/case-law Court decisions, preparatory works and regulator guidance in the same Ansvar search as the law, with exact lookups by reference. Premium, Team and Company. Case law and legislative history See how courts applied a provision, what the legislator intended, and what the regulator says about it, in the same search that finds the law. Plan Premium, Team and Company. Try it Copy Using Ansvar, find Dutch court decisions from 2025 onwards on dismissal for an urgent reason under Book 7 of the Dutch Civil Code, and give the court, decision date and citation for each. More examples: Copy Using Ansvar, fetch the full text of the most relevant decision from that list and quote the passage that decides the case. Copy Using Ansvar, search for data protection authority guidance on employee monitoring in Germany and cite each guidance document. What comes back On these plans a normal search also returns court decisions, preparatory works and regulator guidance next to the law, each with its court or publisher, its date and a citation. Your assistant can then fetch one decision or one preparatory document by its reference; a very long document comes back as an excerpt with a link to the complete original. For developers, the fields to read: Each evidence row's citation and its lookup hint, which names get_decision or get_preparatory_work with the arguments that fetch that exact row The court field on case-law rows, and the decision or issue date Search filters: court (exact match on the corpus's own value), date_from and date_to (full ISO dates, inclusive) Which plan Premium, Team and Company. On Free and Solo, search returns the law only, and the court and date filters are refused with a note naming the plan that includes them. Tools search returns case law, preparatory works and guidance alongside the law on these plans. get_decision fetches one court decision by reference. get_preparatory_work fetches one preparatory document, such as a bill or committee report. search_guidance searches regulator guidance on its own. Limits Coverage differs by country. Ask your assistant to check which countries have court decisions before you rely on an empty result. Some court-decision sources are not searchable on any plan by default; see Sources served on instruction . A search query is limited to 500 characters. Search one legal issue at a time rather than pasting a whole case description. The law still comes first in a result list. To see only decisions, ask your assistant to search the court-decision source on its own. More on reading results The tool reference covers the court and date filters and how to read a search response. Previous Regulatory intelligence Next Org standards library --- ## Control library · Ansvar AI docs URL: https://ansvar.eu/docs/guides/control-library Query Ansvar's control set, based on NIST SP 800-53 rev. 5, its reviewed mappings to ISO 27001, NIS2, DORA and CRA, and crosswalks between frameworks. Control library and crosswalks One control set, based on NIST SP 800-53 rev. 5 and organised by the NIST CSF 2.0 functions, with Ansvar-added controls where a framework needs one. Each control maps to requirements in ISO 27001 and 27002, NIS2, DORA, CRA, C5, NIST SP 800-171 and other frameworks. Each mapping says how closely the control and the requirement match, from equivalent to only related, and a person reviews it before it counts. Plan Team and Company. Try it Copy Using Ansvar, crosswalk NIS2 Article 21 to ISO 27001: show the canonical controls in between and which ISO requirements those controls map to, with the review status of each mapping. More examples: Copy Using Ansvar, get control AC-2 from the control library and list the framework requirements it maps to. Copy Using Ansvar, give me a coverage summary for DORA in the control library, then list the requirements that are only partially covered. What comes back Your assistant gets control and requirement references with how they relate and whether a person has reviewed the link. The library does not reproduce requirement text; it tells your assistant where to fetch it, under your own plan and add-ons. For developers, the fields to read: Relationship type per mapping: equivalent, subset-of, superset-of, intersects-with, related-to Review status per mapping; only approved mappings count by default Citation descriptors (source, edition, reference, lookup parameters). For NIS2, DORA and CRA the text comes from the EU regulations corpus; for ISO, from your org standards library or the ISO standards add-on , whichever holds the standard Coverage per framework: covered, partially covered with the remaining gap, and unmapped Which plan Team and Company. The control library page explains the model behind it. Tools list_controls lists controls, filtered by family, function, framework or baseline. get_control returns one control and the requirements it maps to. get_requirements lists the framework requirements one control maps to. crosswalk goes from one framework's requirement to another framework's, through the shared controls. coverage reports how much of a framework the reviewed mappings cover. list_obligations lists the obligations recorded under a framework edition. resolve tells your assistant where to fetch a requirement's text. changes reports each framework's pinned version. Limits Only reviewed mappings count unless you ask for the proposed ones too; coverage then shows them separately. A mapping is not proof that a control satisfies a requirement. Subset-of and intersects-with links cover only part of it, and a related-to link states a relationship without claiming any coverage. A crosswalk shows the stored links along each path and labels the path as a related link or as needing review. It never derives a cross-framework coverage claim from an indirect path. The obligation list includes proposed, approved and declined rows unless you filter for approved ones; proposed rows are marked provisional. Mapping coverage describes the library, not your organisation. It does not say you comply. An unknown framework, edition or reference returns an error naming the known ones, and an empty crosswalk says why it is empty. Change detection between catalogue versions is not built yet; the tool says so rather than returning an empty change list. Keep scope decisions in your own repository The control scope repository guide shows how an assistant reads this library and proposes your scope changes as pull requests that people approve. Previous Org standards library Next EU regulation engines --- ## EU regulation engines · Ansvar AI docs URL: https://ansvar.eu/docs/guides/regulation-engines Decide which EU regulations apply, compare how they treat one topic, list the evidence auditors expect, and map ISO 27001 or NIST CSF controls to articles. EU regulation engines Ask whether an EU regulation applies to you, how DORA and NIS2 differ on one topic, what evidence an auditor will want, and which articles an ISO 27001 control helps with. Plan Team and Company. Try it Copy Using Ansvar, check which EU regulations apply to a Swedish company that sells a connected home camera with a companion app in the EU, and list what you still need from me to settle anything unresolved. More examples: Copy Using Ansvar, compare how DORA, NIS2 and GDPR treat incident reporting, with the article and deadline for each. Copy Using Ansvar, list the audit evidence DORA expects for ICT risk management and the questions an auditor will ask. Copy Using Ansvar, map ISO 27001 control A.5.24 to the NIS2 articles it helps with and mark full or partial coverage. What comes back An applicability check returns a verdict per regulation with the articles it rests on, and tells you which facts would settle anything it could not decide. The other engines return article numbers and short extracts your assistant can open in full. For developers, the fields to read: Applicability, profile input: per instrument a verdict (applies, may_apply, does_not_apply, exempt, unresolved, conflict), temporal state, confidence, basis and exclusion articles, and the fields that would settle an unresolved verdict Applicability, sector input: one cited row per applicable regulation with confidence and basis article Comparison: per regulation, requirement extracts, article numbers and timelines Evidence: artefact names, examples, retention periods, auditor questions and maturity expectations Control mapping: control by control, full, partial or related coverage with the articles Which plan Team and Company. On Premium, a deferral dossier workflow uses the applicability check for you during the run; the other engines need Team. Tools check_applicability decides which EU regulations apply to a product, service or company. compare_requirements compares how two or more regulations treat one topic. get_evidence_requirements lists the evidence an auditor expects for a regulation or article. map_controls maps ISO 27001 or NIST CSF controls to EU regulation articles. get_regulation_guide gives an orientation guide to one regulation. Limits A fact you leave out counts as unknown, never as false. Expect unresolved verdicts until you supply it. A regulation with no verdict was not assessed. That is not a negative answer. The engines cover EU-level law. National law and transpositions come through the normal search. An engine result helps your analysis. Have a qualified person review an applicability conclusion before you rely on it. Mapping one control set to many frameworks map_controls maps a control framework straight to regulation articles. For one control set mapped to many frameworks with reviewed links, use the control library . Previous Control library Next Effective risk --- ## Org standards library · Ansvar AI docs URL: https://ansvar.eu/docs/guides/org-standards Search and cite the security standards in your own library with Ansvar, clause by clause. Premium, Team and Company; uploads are not open to customers yet. Org standards library Search and quote the security standards in your own library, such as your copy of a control framework, the same way you query law, so an assessment can cite your requirements next to the regulation. Plan Premium, Team and Company. Today each user's library is private to them, and uploading a standard is not open to customers yet. Uploads are not open yet The standards upload in the Ansvar account area is switched off, and no Ansvar tool uploads a standard. Until uploads open, these tools work but your library is empty. To license ISO text that Ansvar serves itself, use the ISO standards add-on instead. Try it Copy Using Ansvar, list the standards in my org standards library and their status. More examples: Copy Using Ansvar, search my uploaded standards for supplier access reviews and quote each matching clause with its citation. Copy Using Ansvar, get clause A.5.15 from my uploaded iso_27001_2022 standard and compare it with NIS2 Article 21(2)(i). What comes back Clause text with its title, section and page, and a citation that points at that clause in your document. The list shows each standard's status, so you can see whether it is ready to cite. For developers, the fields to read: Library listing: standard id (such as iso_27001_2022 ), status (ready, processing, failed), clause count and any error Clause: title, full text, parent section, page number and a doc:// URI for paragraph-level citation Search: up to 50 ranked clause excerpts, each with its doc:// URI Which plan The three tools are on Premium, Team and Company. When uploads open, the upload itself will be a Team and Company feature: the account-area upload Ansvar has built admits only those plans. Each library is private to the user who owns it; an organisation-wide library is not available yet. Tools list_org_standards lists the standards in your library and their status. search_org_standards searches the clauses of your standards. get_org_standard_clause returns one clause by standard and clause reference. Limits Asking for an organisation-wide scope returns an empty list or a reason, not someone else's clauses. A standard still processing has no clauses to cite yet. If the document service is down, the tools say so with a reason rather than returning an empty success. Previous Case law and legislative history Next Control library --- ## Audit ledger · Ansvar AI docs URL: https://ansvar.eu/docs/guides/audit-ledger Company plan: every gateway call your organisation makes leaves a signed, timestamped receipt you can list, verify, decrypt and export for offline audit. Audit ledger and receipts A tamper-evident record of what your organisation asked Ansvar and what came back, which an auditor can verify without access to Ansvar. Plan Company. Recording starts on its own. Try it Copy Using Ansvar, list my audit receipts from 2026-10-01 to 2026-10-07 and verify the receipt for the most recent search. More examples: Copy Using Ansvar, export the full audit package for our organisation for September 2026 so our auditor can verify it offline. Copy Using Ansvar, list my audit receipts from the last seven days, then decrypt the most recent one and show me what the gateway returned. What comes back Ansvar writes an encrypted receipt for your organisation's calls and links the receipts so that changing one would break the chain. Each day the chain is co-signed and stamped by an independent timestamp authority, and an export carries everything an auditor needs to check it offline. For developers, the fields to read: Listing: receipt metadata (timestamps, tool names, query ids), paged with next_cursor One receipt: its encrypted envelope Verification: the chain-hash result and the timestamp authority's signature check (RFC 3161) Decryption: the query, the response and metadata Export: the full bundle (every encrypted envelope plus anchors, timestamps and signatures; verifies offline) or the summary bundle (metadata and anchors only; does not verify offline). With include_plaintext=true an org-admin's full export also carries the decrypted content Which plan Company. A member reads their own receipts; an org-admin reads the whole organisation's, decrypts receipts and exports the organisation-wide package. Tools list_receipts lists receipts for a date range. get_receipt returns one receipt's encrypted envelope. verify_receipt checks that a receipt has not been altered. decrypt_receipt decrypts one receipt (org-admin). export_audit_package exports receipts for a date range as an audit bundle. Limits Not every tool's full request and response lands in the ledger. Effective-risk results are not stored at Ansvar, and a signed review decision is recorded as metadata only, so keep the results and tokens you need yourself. A listing needs a date range. Ansvar never picks the window for you. The summary bundle is a view of the record, not evidence. Give an auditor the full bundle. An export larger than the response limit is refused with its size, never cut short. Narrow the dates or the scope. Decryption and the organisation-wide export are refused for anyone who is not an org-admin, and each decryption is itself recorded. For org-admins Seats, roles and what an org-admin can do with the audit ledger from the account page are on Manage your organization . Previous Effective risk Next Workflows --- ## 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. For a map of every capability and the plan that includes it, read What Ansvar does . 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 the corpus's own term for the concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. If meta.recommended_scopes names scope ids you did not search, search those next. 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 232 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: "Using Ansvar, 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, and reports render unwatermarked as HTML, PDF and DOCX. Workflows on your own documents (gap analysis, DPIA, tender review) 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 law, regulation and licensed-standards row it serves carries three fields (clauses from standards your organisation uploaded cite by their doc:// URI instead): _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 Checks a citation against the served corpus before you rely on it — a deterministic, non-model check: the cited provision resolves, and you get its current served text to compare with the quote. It does not assert in-force status. 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 . If your agent calls one anyway, the gateway answers with a tool result ( isError: true ) that names the plan including the tool and links to the plan comparison. 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. Find a task or refresh stale tool definitions Ask describe_capabilities(section="use_cases") for compact task entry points. If a tool or new argument is missing in your client, compare its definitions with the live account's tool_surface from get_my_capabilities . Follow the stale-tool troubleshooting steps before assuming a plan limit. Previous What Ansvar does Next What is the gateway --- ## 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, a recipe per client. 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 Cursor Settings → MCP (labelled Tools & MCP in newer builds) → 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 . Get your first cited answer Paste one of these tasks exactly as written. Each reads one source, so it runs on every plan, Free included, and you get the law's text with a link you can open. Once your client shows Ansvar as connected, skip asking which tools it has. Paste one of these instead. An EU regulation article . You should get the text of Article 17 (right to erasure), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve GDPR Article 17 and show its official source link. A national law provision . You should get the German text of § 26 BDSG (employee data), linked to gesetze-im-internet.de . text Copy Using Ansvar, retrieve section 26 of the German Federal Data Protection Act (BDSG) and show its official source link. NIS2 obligations for a sector . You should get the ten measures in Article 21(2), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve NIS2 Article 21 and list the cybersecurity measures an energy company must take. Show the official source link. DORA incident reporting for a bank . You should get the initial notification, intermediate report and final report of Article 19(4), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve DORA Article 19 and list the reports a bank must file after a major ICT-related incident. Show the official source link. What a good answer looks like: the text of the provision, its article or section number, and a link to the official publisher. Your client should also show a call to an Ansvar tool, usually get_provision . An answer with no tool call and no source link came from the model's memory: lead the message with "Using Ansvar" and add the routing instructions . 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 Service credentials for the org-owned headless option (n8n, CI jobs, standing agents). 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. Org-owned service credentials are self-serve from the account page : creating and rotating them is Premium and up, while listing and revoking stay available to an org admin on any plan. To force-revoke an interactive client's OAuth grant, contact support via the address on the contact page — self-service revocation for those is not in the account area 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 , Lovable has its own (a custom MCP chat connector), 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 . Microsoft 365 Copilot Install the Ansvar agent from the Microsoft Teams and M365 Copilot store, then sign in with your Ansvar account. Your tenant admin may need to allow the app first. Follow the Microsoft 365 setup guide . For an agent you configure and publish yourself, use 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 the law's own term for the concept first, still in the law's language, then one search per concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. Relaxed matches 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 39 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: what has the Rechtbank Amsterdam decided on this since January 2026? (pass court and date_from on search ; the court code is the one an unfiltered row carries — RBAMS, GHAMS, HR) search with court / date_from 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 plus unwatermarked renders), which adds LINDDUN and TARA; document-grounded runs 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 , 3 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 starts at Evidence Pro or 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 plus unwatermarked HTML, PDF and DOCX. 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 ; a call to one anyway returns a refusal naming the plan that includes it (unknown tool names still return JSON-RPC -32601 ); 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. Read the search match label A bridged result matched a controlled-vocabulary term and can serve by default. A broadened result matched an OR-style relaxed query; on search , those rows require the user's consent to a re-run. Keep the labels in the answer. See the search response contract . Financial regulation with your agent These prompts cover source discovery, cited research and a DORA assessment. Change the jurisdiction to your market before pasting. The financial services guide explains the served material and plan boundaries; coverage and pricing carry the current scope and allowances. Check jurisdiction coverage (Solo and above) text Copy Using Ansvar, check the available financial-regulation sources for Ireland and the EU. List the served scope and any gaps before researching a payment institution's question. Keep national and EU sources separate. Prepare a DORA contract review (Free and above) text Copy Using Ansvar, retrieve DORA Article 30 and relevant served technical standards for an ICT contract review. Cite each source and distinguish retrieved text from your interpretation. Leave unsupported conclusions unresolved. Research MiCA authorisation (Solo and above) text Copy Using Ansvar, research MiCA CASP authorisation for a firm in France. Find the EU provisions and available French sources, cite them, and identify questions the served material cannot answer. Find supervisory guidance (Premium and above) text Copy Using Ansvar, find ECB and EIOPA guidance available for ICT risk in banks and insurers. Keep the authority, publication type and source link with each finding. Report missing sources or access restrictions before drawing conclusions. Assess uploaded evidence (Team and Company) text Copy Using Ansvar, check whether gap_analysis_dora and document upload are available to my account. If available, run a DORA gap analysis using the policies and ICT contracts I choose to upload. Cite the supporting document paragraphs and regulatory sources, and leave missing evidence unresolved. If access or sources are unavailable, report that and stop. 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 lists every source by country, and "Suggest a source" takes requests for anything missing. Previous MCP basics 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. Below the task skills, one skill per workflow family carries the method the gateway's workflow engine itself runs. On Claude, Cowork, or Claude Code, you can also install skills from this page as one plugin from Anthropic's plugin directory, with the gateway connector included — the plugin install below lists which skills it carries. 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, when the gateway reports withheld relaxed matches, offers the user a broadened re-run 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) . Workflow family skills A workflow is a run the gateway drives stage by stage — it asks for what it needs, fetches the law behind every requirement, and hands back a finished report. These skills are the agent's half of that run, one per family: how to open a run and scope it, what each stage expects, the evidence and citation rules the output has to meet, how to relay the delivery receipt the server returns, and starter questions to paste. Install the family you work in — they sit alongside the routing skill above rather than replacing it. Regulatory Gap Analysis — Assess an organisation against a regulatory framework control by control, with article-level citations and a coverage score. Get it: SKILL.md · ready-made ZIP · version 1.4.0 . Threat Modelling — STRIDE security threat models and LINDDUN privacy threat models over a described system, with scored threats and mapped controls. Get it: SKILL.md · ready-made ZIP · version 1.6.0 . Impact Assessments — DPIA and FRIA — GDPR Article 35 data protection impact assessments and EU AI Act Article 27 fundamental rights impact assessments, with the national Article 35(4) lists and the Charter rights in scope. Get it: SKILL.md · ready-made ZIP · version 1.2.0 . Threat Analysis and Risk Assessment — Structured risk assessments with likelihood and consequence bands, scored against declared thresholds and closed with treatments — including automotive, rail, robotics and OT TARA. Get it: SKILL.md · ready-made ZIP · version 1.2.0 . Tender Review and Audit — Bidder-side completeness review of a public tender, and buyer-side lawfulness audit of the tender itself, each requirement cited to its legal basis. Get it: SKILL.md · ready-made ZIP · version 1.2.0 . Vulnerability Decisions — Contextual scoring of an already-scanned finding set with KEV and EPSS, a costed control-investment plan, deferral records for what stays open, and a merged CycloneDX VEX. Get it: SKILL.md · ready-made ZIP · version 1.2.0 . Adversary Tabletop — A crisis simulation run turn by turn against a scripted adversary, scored from the decisions the team actually made, with an after-action report. Get it: SKILL.md · ready-made ZIP · version 1.2.0 . Document Review — Review an uploaded document against a regulatory baseline, with every finding anchored to a paragraph-level citation and a content hash. Get it: SKILL.md · ready-made ZIP · version 1.2.0 . Drone Operations — SORA — A SORA determination chain for a specific-category UAS operation: ground and air risk, SAIL, the applicable operational safety objectives with robustness levels, and containment. Get it: SKILL.md · ready-made ZIP · version 1.2.0 . Regulatory Applicability Register — Which EU and national acts apply to one product, service or entity on the markets you name, and why: the applicability engine's verdict per act with its cited basis, the facts still open, the national layer behind each EU act, and the dated obligations ahead. Get it: SKILL.md · ready-made ZIP · version 1.0.0 . These files are not written for the website. They are generated from the workflow engine's own instruction library and imported here by checksum: the published file, the release manifest that hashes it, and the pinned build are checked against each other in CI, so a skill on this page cannot drift from the workflow it describes. The set above was built against regulatory content bundle 1.29.0 . 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 One step: the Ansvar Compliance Skills plugin The ansvar-compliance-skills plugin is listed in Anthropic's plugin directory. It bundles these skills and declares the Ansvar gateway as its connector, so one install gives you both: Regulatory Threat Model — /ansvar-compliance-skills:regulatory-threat-model Incident Reporting Navigator (EU) — /ansvar-compliance-skills:incident-reporting-navigator CRA Vulnerability & Reporting Obligations — /ansvar-compliance-skills:cra-vulnerability-obligations ISO Standards Expert — /ansvar-compliance-skills:iso-standards-expert Claude (claude.ai and the desktop app) and Cowork: open Customize → Plugins, find Ansvar Compliance Skills under Discover, and select Add. Directory plugins appear on the Pro, Max, Team, and Enterprise plans; on Team and Enterprise, an Owner decides whether the directory is shown. The plugin is saved to your account, so Cowork loads it in your next task, and Claude Code signed in to the same account picks it up at its next start (or run /reload-plugins ). Then open the plugin's Connectors tab and connect the Ansvar gateway with your Ansvar account — the skills load without it, but cannot fetch any law until it shows Connected. Claude Code, from the plugin's own marketplace: the plugin repository is also a marketplace, so you can install it in a Claude Code session without a claude.ai account sync: text Copy /plugin marketplace add Ansvar-Systems/ansvar-compliance-skills /plugin install ansvar-compliance-skills@ansvar-compliance-skills Enabling the plugin connects Claude Code to the gateway, after the usual server approval and sign-in prompts. Source, license and the per-skill plan notes are in the plugin repository . Not in the plugin yet: Using Ansvar — the routing skill, Regulatory Gap Analysis, Threat Modelling, Impact Assessments — DPIA and FRIA, Threat Analysis and Risk Assessment, Tender Review and Audit, Vulnerability Decisions, Adversary Tabletop, Document Review, Drone Operations — SORA, Regulatory Applicability Register . Install those one by one as described next. One skill at a time 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 and every workflow family skill have a ready-made ZIP above — download it and upload it as-is; for the remaining 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: for a skill the plugin does not carry, or to pin one file yourself, 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 under Available skills went through a two-round adversarial legal-accuracy review with live EUR-Lex cross-checking before release. The workflow family skills carry the same instructions the workflow engine runs, and reach this page only through the checksummed import described above. 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 same page also carries one skill per workflow family — gap analysis, threat modelling, impact assessments and the rest — which add that family's run loop, evidence rules and report expectations on top of the baseline below. Those are generated from the instructions the workflow engine itself runs, so they stay in step with the served workflows rather than restating them here. 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 the corpus's own term for the concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. If meta.recommended_scopes names scope ids you did not search, search those next. 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 offer to 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 the corpus's own term for the concept; whenever a response reports withheld relaxed matches ( meta.broadening_available is true, or meta.message says so), the agent tells the user and offers a re-run with allow_broadening=true , and runs it only if they accept. Broadened rows come back marked match_mode: "broadened" — an agent labels them as relaxed matches in its answer, not as exact law. The corpus already relaxes the query in rungs and reports which rung it used, so do not rebuild broadening in your own instructions; the fields to read are listed under Reading a search response . Controlled-vocabulary matches are a separate case: match_mode: "bridged" means the corpus matched its own term for your concept. These rows can serve with broadening off. Preserve that label; only the withheld broadly matched rows need the consent re-run described above. 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 de term die de wet zelf gebruikt. Als een antwoord achtergehouden ruimere treffers meldt (meta.broadening_available is true, of als meta.message dat vermeldt), zeg dat tegen de gebruiker en bied aan de zoekopdracht te herhalen met allow_broadening=true; doe dat alleen als de gebruiker akkoord gaat, en markeer ze als zodanig. Zet allow_broadening nooit op eigen initiatief aan. Als meta.recommended_scopes scope-id's noemt die je niet hebt doorzocht, doorzoek die dan hierna. 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 refusal that names a plan ("available on the Premium plan and above") is the plan gate, not an outage; the agent tells you and does not retry. Cite uploaded documents at paragraph level. On Team and above (uploading starts at Team; the citation readers themselves unlock at Premium), 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. The run predates the current model generation (the Claude 5 family — Opus 5, Sonnet 5 — shipped after it; the Opus 4.8 row below records a superseded model): treat the table as evidence the task is achievable and how models differ, not as a live leaderboard. A re-run on the current generation is queued with the GPT and Gemini rows. 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 232 specialist MCP servers (as of 2026-09-06 ). 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 curated tool surface to whichever client you connect — curated meaning every tool is deliberately promoted, not that there are few: the families run from research ( search , get_provision , validate_citation ) and claim checking ( validate_claim , verify_citations ) through workflows ( start_workflow and its siblings), vulnerability intelligence ( search_cve , KEV/EPSS), the control library, regulatory-update monitoring, document citation, effective risk, and the audit ledger. The architecture workspace tools run in a workspace you host yourself, not on the hosted gateway. The surface is tier-scoped — the authoritative list is what tools/list returns for your tier, and the tool reference documents it family by family. Your client sees a stable interface that doesn't change when we add a new jurisdiction behind the gateway. For what each family does, what you get back and which plan includes it, read What Ansvar does . What's behind the gateway The fleet is split by purpose (counts as of 2026-09-06 , read from the routing data — never typed into this page): 59 law servers routable today, serving the 39 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. 96 sector services — consolidated chassis services carrying per-country sector-regulator corpora (cybersecurity, data protection, financial supervision, competition) across the EU/EFTA states. 77 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. Corpora are not the whole story: the same gateway fronts the workflow engine (staged assessments), the document service (paragraph-cited uploads), the control library (canonical controls with framework crosswalks), the regulatory-update monitor, and the live CVE / effective-risk engines. One connection reaches all of them, tier permitting; the plan and capability table says which plan reaches which. 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 Quickstart 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 starts at Evidence Pro, on request, and is included from Premium; 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, and unwatermarked HTML, PDF and DOCX start at Premium. 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 a call to one anyway returns a refusal naming the plan that includes it; 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, Gemini, Le Chat and Copilot Studio are MCP clients (each has a setup recipe ). 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, and each workflow prompt drives its workflow through the same tool calls underneath. Two prompts are not workflow drivers and are served from the free tier up: the guided tour ( ansvar-tour ) and the document-citation prompt. 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 232 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 232 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 Quick tips --- ## 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; the product overview of the framework variants is on the gap-analysis family page . 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 Premium, 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 a call to one anyway returns a refusal naming the plan that includes it; 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. Unwatermarked rendered exports start at Premium (Free and Solo get watermarked renders). What Team adds is the document plane — uploads, evidence binding. 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": [ { "...": "..." } ] } Optional system diagram and report delivery Gap analysis can include an optional system data-flow diagram. Review its systems, stores, interfaces and trust boundaries when the workflow asks, or take the explicit skip path. Keep the diagram consistent with the scope and evidence you supplied. Ask your agent to display the server-authored delivery_receipt.display_markdown unchanged and provide the complete report. The receipt carries integrity and unresolved-basis information that a rewritten summary could omit. See report delivery . 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 Premium. 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 Sources served on instruction 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. The product overview, including the German/Swedish and drone variants, is on the DPIA family page . 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, with unwatermarked HTML, PDF and DOCX renders on request. 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. Confirm the jurisdictions and screening sources Confirm the jurisdictions with your DPO or responsible reviewer before screening. The workflow retrieves the national trigger material available for that scope and keeps its status: a published list, indicative guidance, a draft and a statutory test are not interchangeable. The DPIA coverage register names the source, status and known limitations by jurisdiction. If a required source cannot be fetched, the assessment records an unresolved basis. An empty search does not establish that no DPIA is required. Review the unavailable evidence and the reasons for the screening outcome before proceeding to the prior-consultation determination. Ask scope_workflow or list_workflow_types for the suitable variant; do not infer a variant id from a country code. 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. Review the diagram and delivery receipt The workflow can include an optional system data-flow diagram. Review the people, systems, data stores, transfers and trust boundaries against your processing description. Accept the diagram or follow the step's explicit skip path; the assessment must not fill missing system details from guesses. Alongside the report, generate_report returns a delivery_receipt . Ask your agent to display delivery_receipt.display_markdown unchanged so the integrity state and unresolved screening or consultation evidence stay visible. Receive the full report as well; a chat summary is not the deliverable. See report delivery for artifact formats and hashes. 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 MITRE ATT&CK, ATLAS, CAPEC, CWE and D3FEND on every plan. 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. The product overview, including the OT and drone STRIDE variants, is on the threat-model family page . 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 plus unwatermarked HTML, PDF and DOCX renders. Team raises the quota to 20 runs per seat a month and adds document grounding — evidence from your own uploaded architecture docs. The threat-pattern lookups ( search with sources=['threat-frameworks'] ) and the CVE tools ( search_cve and friends) are available for briefs without the workflow. Public CVE details, KEV status, EPSS scores, known exploits, product search, and feed freshness remain on Free, as do the CAPEC, CWE, and D3FEND catalogues. Team adds effective-risk rescoring against customer asset context, review decisions, and OpenVEX export. 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, ATLAS, CAPEC, CWE and D3FEND on every plan), 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, and mitigation. Each factual finding carries a served evidence reference or an unresolved marker. 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 Run a TARA --- ## 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 or newer — use a currently supported LTS (18 itself is past end-of-life). 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. Get your first cited answer Paste one of these tasks exactly as written. Each reads one source, so it runs on every plan, Free included, and you get the law's text with a link you can open. In AnythingLLM, start the message with @agent : MCP tools only run inside an agent session. Then paste the task. An EU regulation article . You should get the text of Article 17 (right to erasure), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve GDPR Article 17 and show its official source link. A national law provision . You should get the German text of § 26 BDSG (employee data), linked to gesetze-im-internet.de . text Copy Using Ansvar, retrieve section 26 of the German Federal Data Protection Act (BDSG) and show its official source link. NIS2 obligations for a sector . You should get the ten measures in Article 21(2), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve NIS2 Article 21 and list the cybersecurity measures an energy company must take. Show the official source link. DORA incident reporting for a bank . You should get the initial notification, intermediate report and final report of Article 19(4), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve DORA Article 19 and list the reports a bank must file after a major ICT-related incident. Show the official source link. What a good answer looks like: the text of the provision, its article or section number, and a link to the official publisher. Your client should also show a call to an Ansvar tool, usually get_provision . An answer with no tool call and no source link came from the model's memory: lead the message with "Using Ansvar" and add the routing instructions . 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. On Premium it takes a seat of its own, like a team member does (your sign-in holds a seat too); Team and Company include five per workspace that take no seat, and each further credential takes one. It carries a signed-in seat's tool surface on your plan — search, provision lookup, citation validation, workflow runs, document upload and report generation — with two carve-outs: the audit-ledger decrypt and architecture-proposal assent surfaces are human-only and refused to credentials, and each credential's monthly workflow-run ceiling defaults to half a seat's (see Service credentials ). 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 Premium , 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 Free and Solo, 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 --- ## Sources served on instruction · Ansvar AI docs URL: https://ansvar.eu/docs/restricted-sources Why some court-decision sources are off the default surface, who can instruct Ansvar to serve them, and how the grant, logging and deletion work. Sources served on instruction Some official sources identify people: a court may publish a party's full name in a judgment. When our privacy assessment of such a source finds that Ansvar has no basis of its own to serve it, we mark it restricted. A restricted source is never on the default surface, on any plan: a search or a lookup does not reach it. We serve a restricted source only to an organization that has instructed us in writing to do so. For that source your organization is the controller and Ansvar is your processor: we process it for the purpose, scope and period your instruction names, and for nothing else. Status: grants start after our legal review This model depends on a data-protection reading of the processor role by our DPO or counsel. Until that reading is signed we issue no grants and this page lists no sources. You can start a request now; the list of sources available on instruction appears here once the first one can be granted. Records we are withholding We are taking three kinds of court decision out of our general service: decisions in criminal proceedings, decisions in administrative-offence proceedings such as traffic fines, and constitutional or supreme-court cases that arose from criminal proceedings. Some collections we serve today contain them, and we are removing them in one planned update. Even with names removed, a published decision about an offence can point to the person it concerns, and Article 10 GDPR gives data about criminal convictions and offences special protection. We apply the same rule to administrative offences, whether or not a given offence falls under Article 10. We will not serve a general index of these records on our own account. We plan to serve some other collections only to a customer that instructs us in writing, as the rest of this page describes, once our legal review is signed. If your organization has a documented need for withheld records, for example a law firm acting in a specific matter, write to claims@ansvar.eu and we will discuss with you how we could set that up. What "served on instruction" means Off the default surface. A restricted source is absent from every search and lookup for every organization without a grant, on every plan. Your basis, your instruction. You decide the purpose, the scope, the service level and the retention period. We process the source on your legal basis, never on our own. Two service levels. Lookup fetches one decision by its publisher identifier from the publisher at request time and relays it; we keep no copy, no cache and no content in our logs, only identifiers and timing. Search is an index we hold for your organization alone, separate from any other customer's copy. A grant names one or both. From the original publisher only. We acquire the source from the court or official publisher, never from a mirror or aggregator, and apply the minimization rules recorded for it: classes of decisions that a metadata rule can exclude are excluded before we fetch them, and we serve the decision text without editorial additions. Who can request access An organization with a documented basis of its own for processing these records. In practice that means legal-expenses insurers and law firms that process published judgments to establish, exercise or defend legal claims, or organizations that national law gives a specific basis. You bring: your legal basis under Article 6 GDPR; any Article 9 condition, where the records contain special-category data, and any Article 10 authorization, where they contain criminal-law data; your own assessment of the processing, such as a DPIA or a legitimate-interest assessment, covering the scope you instruct. Scope matters. Searching a whole corpus is wider processing than looking up the decisions that concern your own matters, and your assessment has to cover the scope you ask for. Being an insurer or a law firm does not supply a basis on its own, and neither does signing the instruction. The process Request. Tell us which source you need, the service level (lookup or search) and the purpose. Instruction and assessment. You sign an instruction annex (the form below) to our Data Processing Agreement for that source. It names the purpose, the scope, the service level, the retention period, the start and end dates, and your legal basis. You attach your assessment and we file it. Our review. We check that the annex is complete and signed, that your assessment is filed and covers the scope you instructed, and that your basis statement names the Article 6 basis and any Article 9 condition or Article 10 authorization the source calls for. We record what we checked in our due-diligence register before any grant. We do not judge your commercial need. If we consider an instruction to infringe data-protection law, we tell you, as Article 28(3) GDPR requires of a processor, and may decline it. The grant. One grant per source, per organization, per instruction. It names the service level, the start date and the expiry date. A review date in the instruction is a reminder, never an expiry. Provisioning. We add the grant to your organization's user identities. Only identities in your organization carry it. Revocation and deletion. Your authorization ends on the end date or on your written notice, effective at the next request. Within the deadline the annex sets, we remove the grant from your identities and, for search, delete your copy: the index, its image versions and replicas, and the raw publisher responses behind it. You receive a deletion receipt that lists each store as deleted, pending backup expiry under the DPA's backup schedule, or retained under a legal obligation we name. What a grant does technically Your users' tokens carry a reference to the grant. On every request the gateway checks that reference against the grant record and refuses when the record is missing, expired, revoked, for another service level or for another organization. If the grant state cannot be read, the request is refused. Every path that can reach the source applies the same check: search, decision and provision lookups, citation validation and source aliases. Without a valid grant the source is absent. Ansvar's own staff accounts, service accounts and monitoring probes are denied the content, even if a grant were attached to one of them by mistake. Grant creation, revocation, every served record and every refused request are logged with your organization and the grant identifier. Expiry and revocation take effect at the next request, not when a token expires. The source is reachable only through the gated gateway path: there is no downloadable data image and no direct endpoint for it. Plan limits stay in force. A grant does not add case law to a plan that excludes it. Example prompts These work only for users in an organization with a grant for the source; for everyone else the source is not reachable. Ask your agent, for a lookup by decision identifier: text Copy Using Ansvar, fetch the decision with publisher identifier [identifier] from our granted court-decision source and quote the operative part with its citation. Ask your agent, for a search on a search grant: text Copy Using Ansvar, search our granted court-decision source for decisions on termination of an insurance contract for late payment, and cite each decision you rely on. Request access Fill in and sign the instruction form, then send it with your assessment, or a summary of it, to claims@ansvar.eu with "Restricted source" in the subject. The form is a short annex to our Data Processing Agreement, which stays unchanged. It names the sources, the service level, your purpose and legal basis, the retention period and the end date. Its first page explains what happens after you send it. Download the instruction form English : PDF · Word (fillable) Nederlands : PDF · Word (fillable) Questions before you start? Write to the same address and name the kind of source you need, the service level and your purpose. Previous ISO standards add-on Next Your first gap analysis --- ## 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 Premium , Team or Company . 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 one of those plans. On Team and Company , the first five credentials come with the workspace and take no seat ; each further credential takes a seat of its own, so you buy seats to run more agents. On Premium , every credential takes a seat of its own, counted together with people: your own sign-in holds one, so a single-seat organization adds a second before it can mint a credential. The account page shows how many seats are used and how many of the included credentials are in use. 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. Where its budget comes from follows your plan. On Team and Company , seats pool: the credential draws on the organization's shared daily and monthly allowance alongside your people. On Premium , each seat carries its own allowance, so a credential spends its own and never your people's. Run ceiling — each credential carries a monthly workflow-run ceiling of its own, on top of whichever allowance above applies. The default is half of what one Team seat contributes to a pool, so on Team one runaway agent cannot drain what the rest of the organization shares, and on Premium it stops a loop well before the plan's own overage band ends. 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. Each has its own floor. A standard seat does not require an organization seat — a person can hold a standard on any plan. A credential requires Premium, Team or Company . And assigning a standard seat to a credential requires Team or Company : that assignment is an organization-management action, which Premium does not include. So a Premium organization cannot make that assignment itself — an assignment made while on Team survives a later move to Premium. Write to team@ansvar.eu if you need an ISO-expert agent on Premium. 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 past the included five on Team and Company, or any credential on Premium, 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 starts at Premium. 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 Vulnerability intelligence --- ## 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. Get your first cited answer Paste one of these tasks exactly as written. Each reads one source, so it runs on every plan, Free included, and you get the law's text with a link you can open. Whichever surface you connected, /mcp list or the connected status only proves the login worked. Paste the task into the Gemini CLI prompt, the Code Assist or Antigravity agent panel, or a chat with your Gemini Enterprise agent. An EU regulation article . You should get the text of Article 17 (right to erasure), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve GDPR Article 17 and show its official source link. A national law provision . You should get the German text of § 26 BDSG (employee data), linked to gesetze-im-internet.de . text Copy Using Ansvar, retrieve section 26 of the German Federal Data Protection Act (BDSG) and show its official source link. NIS2 obligations for a sector . You should get the ten measures in Article 21(2), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve NIS2 Article 21 and list the cybersecurity measures an energy company must take. Show the official source link. DORA incident reporting for a bank . You should get the initial notification, intermediate report and final report of Article 19(4), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve DORA Article 19 and list the reports a bank must file after a major ICT-related incident. Show the official source link. What a good answer looks like: the text of the provision, its article or section number, and a link to the official publisher. Your client should also show a call to an Ansvar tool, usually get_provision . An answer with no tool call and no source link came from the model's memory: lead the message with "Using Ansvar" and add the routing instructions . 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 the corpus's own term for the concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. If meta.recommended_scopes names scope ids you did not search, search those next. 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 (as of 2026-07-02 it did not support Gemini 3 models — check Google's current docs before building on it). 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 — install the Ansvar Gateway app from the Apps directory, or add a custom connector in Developer mode. Connect ChatGPT The gateway is a listed ChatGPT app : OpenAI reviewed it and published it in the Apps directory as Ansvar Gateway (August 2026). Installing from the directory is the short path — no Developer mode, no URL to paste. The custom-connector recipe further down connects the same gateway by hand, with one difference: the directory app lists the Free plan's tools for every user, while a custom connector lists the tools of your own Ansvar plan. Use the custom connector on a paid Ansvar plan, or when the directory app is not available in your workspace or region. One naming note so the menus match what you read here: OpenAI renamed "Connectors" to Apps in late 2025, and both labels still appear in the product. The short path — install from the Apps directory Open the Ansvar Gateway listing directly (ChatGPT login may be asked before installing), or in ChatGPT open the Apps directory and search for Ansvar Gateway (category: Security), or type @Ansvar Gateway in a chat and pick it from the suggestions. Press Connect ; the browser opens the OAuth login at auth.ansvar.eu — sign in with any Ansvar account (Free is enough to evaluate) and approve. From then on, call it by mentioning @Ansvar Gateway in any conversation, or let ChatGPT bring it in when a question matches what it does. Connection check: Ansvar Gateway shows as connected under Settings → Apps . Then get your first cited answer . Two availability notes. OpenAI gates apps by plan and region — apps reached Free, Go, Plus, and Pro users outside the EEA, Switzerland, and the UK first, with the European rollout following (the Ansvar Gateway listing is confirmed rendering from an EEA account as of August 2026). And on Business, Enterprise, and Edu workspaces, apps are admin-governed. In either case, if the directory app is not offered to you, the custom-connector path below is the way in. On a paid Ansvar plan The directory app lists the tools of the Free plan, whatever plan you are on. The gateway still applies your plan to every call it receives (on Premium and above, search still returns case-law results), but ChatGPT cannot call a tool the app does not list. To use every tool your plan includes, connect the custom connector below. It needs ChatGPT Plus, Pro, Business, Enterprise, or Edu. We are building Ansvar Gateway Pro, a ChatGPT app for paid plans, and expect it to be available soon. Until then, the custom connector is how you use your full plan in ChatGPT. The manual path — a custom connector in Developer mode The custom connector works on every paid ChatGPT plan — Plus, Pro, Business (the plan formerly called Team), Enterprise, and Edu; ChatGPT Free cannot add custom connectors (there, the directory app above is the way in where OpenAI has rolled apps out). It lists the tools of the Ansvar plan you sign in with, so it is also the path to every tool a paid Ansvar plan includes. 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 plan 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 Ansvar plan includes. A connector added on the web is available in the ChatGPT mobile apps automatically. Connection check: the connector shows as connected and lists its tools in Settings. Then get your first cited answer . Get your first cited answer Paste one of these tasks exactly as written. Each reads one source, so it runs on every plan, Free included, and you get the law's text with a link you can open. Bring the app into the chat first. ChatGPT does not always call a connected app on its own, and a bare legal question usually gets an answer from its training data, with no source. Per OpenAI's help pages, you mention the app with @ or select + in the message box and choose it (some layouts put apps under More ): Directory app: start the message with @Ansvar Gateway , or select + and choose Ansvar Gateway . Custom connector: select + → Developer mode and turn on Ansvar for the conversation. Then paste the task. Naming Ansvar in the task as well keeps ChatGPT from answering from memory when the app is selected but not called. An EU regulation article . You should get the text of Article 17 (right to erasure), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve GDPR Article 17 and show its official source link. A national law provision . You should get the German text of § 26 BDSG (employee data), linked to gesetze-im-internet.de . text Copy Using Ansvar, retrieve section 26 of the German Federal Data Protection Act (BDSG) and show its official source link. NIS2 obligations for a sector . You should get the ten measures in Article 21(2), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve NIS2 Article 21 and list the cybersecurity measures an energy company must take. Show the official source link. DORA incident reporting for a bank . You should get the initial notification, intermediate report and final report of Article 19(4), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve DORA Article 19 and list the reports a bank must file after a major ICT-related incident. Show the official source link. What a good answer looks like: the text of the provision, its article or section number, and a link to the official publisher. Your client should also show a call to an Ansvar tool, usually get_provision . An answer with no tool call and no source link came from the model's memory: lead the message with "Using Ansvar" and add the routing instructions . 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.6", 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 the corpus's own term for the concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. If meta.recommended_scopes names scope ids you did not search, search those next. 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. The directory app lists the Free plan's tools for every user; on a paid Ansvar plan, add the custom connector to reach the rest. With the custom connector, check Developer mode is on (without it you'll see at most a crippled two-tool view), then check your Ansvar plan — 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 — check the connection Open the MCP settings panel and confirm ansvar shows a connected status with a tool count. Get your first cited answer Paste one of these tasks exactly as written. Each reads one source, so it runs on every plan, Free included, and you get the law's text with a link you can open. Paste the task into the Agent panel. Cursor's agent picks MCP tools itself, so leading with "Using Ansvar" is what makes it call the gateway instead of answering from the model. An EU regulation article . You should get the text of Article 17 (right to erasure), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve GDPR Article 17 and show its official source link. A national law provision . You should get the German text of § 26 BDSG (employee data), linked to gesetze-im-internet.de . text Copy Using Ansvar, retrieve section 26 of the German Federal Data Protection Act (BDSG) and show its official source link. NIS2 obligations for a sector . You should get the ten measures in Article 21(2), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve NIS2 Article 21 and list the cybersecurity measures an energy company must take. Show the official source link. DORA incident reporting for a bank . You should get the initial notification, intermediate report and final report of Article 19(4), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve DORA Article 19 and list the reports a bank must file after a major ICT-related incident. Show the official source link. What a good answer looks like: the text of the provision, its article or section number, and a link to the official publisher. Your client should also show a call to an Ansvar tool, usually get_provision . An answer with no tool call and no source link came from the model's memory: lead the message with "Using Ansvar" and add the routing instructions . 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 the corpus's own term for the concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. If meta.recommended_scopes names scope ids you did not search, search those next. 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. Get your first cited answer Paste one of these tasks exactly as written. Each reads one source, so it runs on every plan, Free included, and you get the law's text with a link you can open. Enable the Ansvar connector under Tools in the chat first (step 3), then paste the task. An EU regulation article . You should get the text of Article 17 (right to erasure), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve GDPR Article 17 and show its official source link. A national law provision . You should get the German text of § 26 BDSG (employee data), linked to gesetze-im-internet.de . text Copy Using Ansvar, retrieve section 26 of the German Federal Data Protection Act (BDSG) and show its official source link. NIS2 obligations for a sector . You should get the ten measures in Article 21(2), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve NIS2 Article 21 and list the cybersecurity measures an energy company must take. Show the official source link. DORA incident reporting for a bank . You should get the initial notification, intermediate report and final report of Article 19(4), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve DORA Article 19 and list the reports a bank must file after a major ICT-related incident. Show the official source link. What a good answer looks like: the text of the provision, its article or section number, and a link to the official publisher. Your client should also show a call to an Ansvar tool, usually get_provision . An answer with no tool call and no source link came from the model's memory: lead the message with "Using Ansvar" and add the routing instructions . 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 the corpus's own term for the concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. If meta.recommended_scopes names scope ids you did not search, search those next. 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 Lovable --- ## Connect Lovable · Ansvar AI docs URL: https://ansvar.eu/docs/setup/lovable Connect Lovable to the Ansvar gateway as a custom MCP chat connector — the Connectors dashboard, OAuth, admin controls, and what the connection reaches. Connect Lovable Lovable's build chat takes chat connectors : MCP servers the Lovable agent can call while it builds your app. Its prebuilt list (Notion, Linear, Jira and the like) has no regulatory source, and Lovable runs no submission process for third-party servers to join it, so you add the gateway yourself as a custom MCP server entry. The form takes a minute and works on every Lovable plan. Once connected, the agent can threat-model the app it is building from the tables, auth and connectors in the project, and read the cited article while it writes your consent flow, retention job, or access-control model. What the connection reaches — and what it does not A Lovable chat connector is personal and build-time only : you sign in with your own account, only you can use it, and it does not become part of the app you publish. Ansvar informs the agent that writes the code; it does not ship inside the finished app. If the app you are building needs live regulatory lookups of its own, that is a separate integration against the gateway — see What is the gateway . Step 1 — add the gateway as an MCP server Open Connectors from the Lovable dashboard (it is also reachable from inside a project), click + , and choose MCP server . Fill in the four fields: Copy Server name: Ansvar Connection type: Direct connection Server URL: https://gateway.ansvar.eu/mcp Authentication method: OAuth Keep Direct connection . The alternative, Lovable static IPs, is an Enterprise-only option for servers behind an IP allowlist; the gateway needs none, and Lovable fixes the choice when the server is added. Click Add & authorize . Step 2 — authorize Lovable's default authentication method for a custom server is OAuth: after Add & authorize you are prompted to authorize. The gateway advertises OAuth 2.1 with Dynamic Client Registration, so expect a browser consent screen at auth.ansvar.eu — sign in with your Ansvar account and approve. You obtain no client ID or secret by hand. Leave the "Bearer token or API key" option alone; the gateway's interactive path is OAuth. No Ansvar account yet? The Free plan is a self-service sign-up at the account page ; the connector works on it, with the Free tool surface. Step 3 — use it while you build Once the connector shows as connected, the Lovable agent can call the gateway's tools during a build session. Lovable's own example for a custom server names the connector in the prompt ("Using the Internal CRM connector, ..."). Ansvar asks for the same pattern: lead with Using Ansvar so the question routes to the connector instead of the model's training data. Try a question Start with the app itself. Vibe-coded apps ship with no authorization model more often than with a wrong one, and a code scanner cannot see a missing one. Ask: "Using Ansvar, threat-model the app in this project: build the data-flow diagram from the tables, auth and connectors it uses, and list the top threats with the control each one needs." The threat-modeling guide explains what comes back and how the interview continues. Then ask for the provision behind a feature you are about to build, for example: "Using Ansvar, what does GDPR Article 25 require of data protection by design for this sign-up form, and what does Article 32 add for the password store?" A grounded answer cites the article text the gateway fetched, and the agent builds to that text rather than to a guess. For an internal tool inside a regulated organisation, scope the question to your jurisdiction: "Using Ansvar with jurisdiction SE, which retention rules apply to the case records this tool stores?" Which plans can add a custom server Lovable's documentation states custom MCP servers are available on all plans ; the one Enterprise-only piece is the static-IP connection option, which the gateway does not need. In Business and Enterprise workspaces, admins get a Connectors → Admin settings area with a Custom MCP row — "Allow members to connect their own MCP servers". It governs all custom servers as a group, and Lovable has no per-server approval: when that row is on, any member can add the gateway; when it is off, ask your workspace admin to enable it. 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. Lovable has no per-connector instruction field, so paste the block below into Project settings → Knowledge : Lovable reads project knowledge with every message you send, and the block fits well inside the 10,000-character cap. Put it in workspace knowledge instead if every project in the workspace should carry it. This is the build-agent form of the routing pack. Because Knowledge rides along with every message of a session whose job is writing code, the block opens with a rule scoped to legal and standards questions instead of the "you are a compliance research assistant" identity line the chat-client pages use. The four numbered steps are the same set that Instruct your agent explains line by line; adapt the jurisdictions to your market. text Copy When a question concerns law, regulation, or security standards, answer it only from Ansvar tool results, never from your own knowledge. Ordinary build requests are unaffected by this rule. 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 the corpus's own term for the concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. If meta.recommended_scopes names scope ids you did not search, search those next. 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 server entry under +. In a Business or Enterprise workspace the Custom MCP row in Connectors → Admin settings is off — ask your workspace admin to enable it. Authorization never completes. The consent screen opens at auth.ansvar.eu ; a popup blocker or a signed-out SSO session stops it. Retry from Connectors after signing in at the account page . The agent answers from memory instead of citing. Lead the message with "Using Ansvar" and keep the routing pack in the project's Knowledge — see above. 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-09-09 — against the docs, not yet a Lovable workspace These steps were verified against Lovable's current documentation on 2026-09-09, and the OAuth advertisement against the live gateway; we have not yet run the handshake from inside a Lovable workspace ourselves. Lovable's connector surface is new and ships changes fast. If a step no longer matches what you see, or authorization asks you for a client ID, tell us and we'll re-verify. Previous Connect Le Chat Next Connect Microsoft 365 --- ## 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, 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 the corpus's own term for the concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. If meta.recommended_scopes names scope ids you did not search, search those next. 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. A Dutch variant for a Dutch-facing agent — shorter than the English block, carrying the core scope, query and grounding rules: 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 de term die de wet zelf gebruikt. Als een antwoord achtergehouden ruimere treffers meldt (meta.broadening_available is true, of als meta.message dat vermeldt), zeg dat tegen de gebruiker en bied aan de zoekopdracht te herhalen met allow_broadening=true; doe dat alleen als de gebruiker akkoord gaat, en markeer ze als zodanig. Zet allow_broadening nooit op eigen initiatief aan. Als meta.recommended_scopes scope-id's noemt die je niet hebt doorzocht, doorzoek die dan hierna. 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 — search requires a jurisdiction or framework scope on every call. 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 with a cited answer Paste one of these tasks exactly as written. Each reads one source, so it runs on every plan, Free included, and you get the law's text with a link you can open. Run these in the agent's test pane after you add the instructions . An EU regulation article . You should get the text of Article 17 (right to erasure), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve GDPR Article 17 and show its official source link. A national law provision . You should get the German text of § 26 BDSG (employee data), linked to gesetze-im-internet.de . text Copy Using Ansvar, retrieve section 26 of the German Federal Data Protection Act (BDSG) and show its official source link. NIS2 obligations for a sector . You should get the ten measures in Article 21(2), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve NIS2 Article 21 and list the cybersecurity measures an energy company must take. Show the official source link. DORA incident reporting for a bank . You should get the initial notification, intermediate report and final report of Article 19(4), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve DORA Article 19 and list the reports a bank must file after a major ICT-related incident. Show the official source link. What a good answer looks like: the text of the provision, its article or section number, and a link to the official publisher. Your client should also show a call to an Ansvar tool, usually get_provision . An answer with no tool call and no source link came from the model's memory: lead the message with "Using Ansvar" and add the routing instructions . A harder test, once the first answer comes back cited: "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, unwatermarked HTML, PDF and DOCX reports, 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 Microsoft 365 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. Get your first cited answer Paste one of these tasks exactly as written. Each reads one source, so it runs on every plan, Free included, and you get the law's text with a link you can open. After the consent step, run the agent in the Foundry playground with one of these tasks. With require_approval on, approve the tool call when Foundry asks. An EU regulation article . You should get the text of Article 17 (right to erasure), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve GDPR Article 17 and show its official source link. A national law provision . You should get the German text of § 26 BDSG (employee data), linked to gesetze-im-internet.de . text Copy Using Ansvar, retrieve section 26 of the German Federal Data Protection Act (BDSG) and show its official source link. NIS2 obligations for a sector . You should get the ten measures in Article 21(2), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve NIS2 Article 21 and list the cybersecurity measures an energy company must take. Show the official source link. DORA incident reporting for a bank . You should get the initial notification, intermediate report and final report of Article 19(4), linked to eur-lex.europa.eu . text Copy Using Ansvar, retrieve DORA Article 19 and list the reports a bank must file after a major ICT-related incident. Show the official source link. What a good answer looks like: the text of the provision, its article or section number, and a link to the official publisher. Your client should also show a call to an Ansvar tool, usually get_provision . An answer with no tool call and no source link came from the model's memory: lead the message with "Using Ansvar" and add the routing instructions . 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 the corpus's own term for the concept. Whenever a response reports withheld relaxed matches (meta.broadening_available is true, or meta.message says so), tell the user and offer a re-run with allow_broadening=true; re-run only if they accept, and label any relaxed matches as such. Never set allow_broadening on your own. If meta.recommended_scopes names scope ids you did not search, search those next. 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 report whose factual findings cite served evidence or remain unresolved. The concept is covered in Tools vs workflows ; this page is the catalogue and the lifecycle; several families also have product pages under ansvar.eu/workflows . 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 with the report as structured JSON and unwatermarked rendered exports; workflows grounded in your own documents are Team (20 runs per seat a month) and Company (custom allowance). Vulnerability facts stay on Free CVE details, CISA KEV status, EPSS scores, known exploits, product search, feed freshness and the CAPEC, CWE, and D3FEND catalogues remain available from Free. Premium adds the LINDDUN and TARA workflow families. Team adds customer-document grounding, asset-context rescoring, review decisions, and OpenVEX export. 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 . Receive the report and its delivery receipt generate_report returns the typed report and a server-authored delivery_receipt . Your agent displays delivery_receipt.display_markdown unchanged: it includes the report's summary, integrity state, items requiring attention and artifact information. A receipt preview is not the full findings set. For a JSON run, receive the complete structured report; for a rendered run, use the artifact link and retain its hash and expiry information. Free and Solo teaser runs can produce a watermarked render or JSON. Premium, Team and Company receive JSON and can request unwatermarked HTML, PDF and DOCX exports. Check the returned artifacts rather than assuming that a requested render succeeded. When present, depends_on records the declared obligation and library dependencies used by the report. This workflow delivery receipt is separate from the Company audit ledger's signed query receipts. Risk assessments and TARA, DPIA/FRIA and gap analyses can include an optional system data-flow diagram. Follow the current step's instructions to review it or explicitly skip it. Keep any unresolved evidence visible in the final report; adding a diagram does not resolve missing legal or customer evidence. The catalogue Every served type, grouped by family — a variant reuses its base type's machinery with a jurisdiction- or domain-specific stage set. The table derives from a snapshot of the served registry ( 2026-10-10 ); list_workflow_types is the live contract and also carries each type's required parameters. "Free + (metered)" marks the seven included types Free and Solo may spend their monthly runs on; the same types run interview-grounded from Premium. workflow_type Tier What it produces adversary_tabletop Adversary Tabletop Exercise Team + A tabletop exercise record: attacker goals, scenario walkthrough, decision points, identified gaps and follow-ups. dpia Data Protection Impact Assessment (GDPR Article 35) Free + (metered) A GDPR Art. 35 DPIA report: processing description, necessity and proportionality assessment, risk register against thresholds, prior-consultation recommendation, and planned measures. ↳ dpia_de DPIA — Germany (BDSG-aware) Premium + A GDPR Art. 35 DPIA report: processing description, necessity and proportionality assessment, risk register against thresholds, prior-consultation recommendation, and planned measures. ↳ dpia_se DPIA — Sweden (GDPR Art. 35 + IMY supervisory practice) Premium + A GDPR Art. 35 DPIA report: processing description, necessity and proportionality assessment, risk register against thresholds, prior-consultation recommendation, and planned measures. ↳ drone_dpia DPIA — Drone / UAS Aerial Data Capture (GDPR Art. 35 + Reg (EU) 2019/947) Premium + A GDPR Art. 35 DPIA report: processing description, necessity and proportionality assessment, risk register against thresholds, prior-consultation recommendation, and planned measures. decision_review Defensibility Assessment (experimental) Team + A Defensibility Assessment (experimental) of a proposed legal or compliance decision: the claims it depends on as an AND/OR map, each claim's supporting and contrary authority with engine-assigned evidence classes, every attack dispositioned under a fixed taxonomy, published challenges by their served summaries, a status per claim and for the position computed by a fixed rule from the recorded judgments, the engine-run validate_claim evidence check kept apart from it, the strongest counter-argument, the restatement scored beside the original, a search completeness grade, the decision the person recorded, and a dependency record with source editions and content hashes. review Document Review (Paragraph-Cited) Team + A paragraph-cited document review: findings each anchored to doc:// segment citations with content hashes (drift-detectable). risk_assessment Enterprise Risk Assessment (ISO 31000 / 31010 / NIST 800-30G) Premium + A risk register aligned to ISO 31000/31010/NIST 800-30G: risks with likelihood/consequence bands, scores against thresholds, and treatments. ↳ automotive_tara Automotive TARA — ISO/SAE 21434 & UNECE R155 Threat Analysis & Risk Assessment Premium + A risk register aligned to ISO 31000/31010/NIST 800-30G: risks with likelihood/consequence bands, scores against thresholds, and treatments. ↳ c_uas_assessment Counter-UAS & Hostile-Takeover Resilience Assessment Premium + A risk register aligned to ISO 31000/31010/NIST 800-30G: risks with likelihood/consequence bands, scores against thresholds, and treatments. ↳ ics_advisory_to_risk ICS Advisory-to-Risk — current advisory exposure for an OT asset inventory Premium + A risk register aligned to ISO 31000/31010/NIST 800-30G: risks with likelihood/consequence bands, scores against thresholds, and treatments. ↳ ot_tara OT / ICS / Machinery TARA — Threat Analysis & Risk Assessment Premium + A risk register aligned to ISO 31000/31010/NIST 800-30G: risks with likelihood/consequence bands, scores against thresholds, and treatments. ↳ rail_tara Rail / Railway TARA — Threat Analysis & Risk Assessment (CLC/TS 50701, IEC 62443) Premium + A risk register aligned to ISO 31000/31010/NIST 800-30G: risks with likelihood/consequence bands, scores against thresholds, and treatments. ↳ robot_tara Robotics / Cobot TARA — Threat Analysis & Risk Assessment for industrial and collaborative robots Premium + A risk register aligned to ISO 31000/31010/NIST 800-30G: risks with likelihood/consequence bands, scores against thresholds, and treatments. ↳ uas_tara UAS Threat Analysis & Risk Assessment (TARA) Premium + A risk register aligned to ISO 31000/31010/NIST 800-30G: risks with likelihood/consequence bands, scores against thresholds, and treatments. fria Fundamental Rights Impact Assessment (EU AI Act Article 27) Premium + An EU AI Act Art. 27 FRIA report: affected-rights analysis against the Charter articles in scope, risk scoring, notification recommendation, and measures. ↳ fria_se FRIA — Sweden (AI Act Art. 27, svensk myndighetsutpekning) Premium + An EU AI Act Art. 27 FRIA report: affected-rights analysis against the Charter articles in scope, risk scoring, notification recommendation, and measures. linddun LINDDUN Privacy Threat Model Premium + A LINDDUN privacy threat register: per-flow privacy threats with category, harm assessment, and mitigations. tender_audit Public Tender Audit (Buyer-Side Lawfulness Review) Team + A buyer-side lawfulness review of the tender itself: procurement-law defect findings with citations and severity. ↳ tender_audit_nl Public Tender Audit — Netherlands (Classical, Aw 2012) Team + A buyer-side lawfulness review of the tender itself: procurement-law defect findings with citations and severity. ↳ tender_audit_se Public Tender Audit — Sweden (Classical, LOU) Team + A buyer-side lawfulness review of the tender itself: procurement-law defect findings with citations and severity. tender_review Public Tender Review Team + A bid completeness review: requirement-by-requirement findings with citations and a coverage score against the tender's regulatory baseline. ↳ tender_review_nl Public Tender Review — Netherlands (Classical, Aw 2012) Team + A bid completeness review: requirement-by-requirement findings with citations and a coverage score against the tender's regulatory baseline. ↳ tender_review_se Public Tender Review — Sweden (Classical, LOU) Team + A bid completeness review: requirement-by-requirement findings with citations and a coverage score against the tender's regulatory baseline. gap_analysis Regulatory Gap Analysis Free + (metered) Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ drone_operator_compliance Drone Operator Compliance — UAS Operations (Reg (EU) 2019/947) Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ drone_product_security_conformity Drone Product Security Conformity — UAS Products (Reg (EU) 2019/945 + CRA + RED) Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_ai_act Gap Analysis — EU AI Act (Regulation (EU) 2024/1689) high-risk provider conformity Free + (metered) Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_amlr_readiness Gap Analysis — AMLR readiness — Regulation (EU) 2024/1624 Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_cra Gap Analysis — Cyber Resilience Act (Regulation (EU) 2024/2847) Free + (metered) Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_dora Gap Analysis — DORA (Regulation (EU) 2022/2554) Free + (metered) Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_dora_ict_contracts Gap Analysis — DORA ICT contracts and subcontracting Team + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_dora_register_of_information Gap Analysis — DORA register of information Team + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_ivdr Gap Analysis — In Vitro Diagnostic Regulation (Regulation (EU) 2017/746) Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_mdcg_cyber Gap Analysis — Medical Device Cybersecurity (MDCG 2019-16 rev.1) Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_mdr Gap Analysis — Medical Device Regulation (Regulation (EU) 2017/745) Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_mica_casp_readiness Gap Analysis — MiCA CASP readiness — Regulation (EU) 2023/1114 Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_nis2 Gap Analysis — NIS2 (Directive (EU) 2022/2555 Art. 21) Free + (metered) Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_nis2_nl Gap Analysis — NIS2 Netherlands (Cyberbeveiligingswet, Stb. 2026, 187) Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_nis2_pl Gap Analysis — NIS2 Poland (ustawa o KSC, Dz.U. 2018 poz. 1560; t.j. Dz.U. 2026 poz. 20, zm. Dz.U. 2026 poz. 252) Team + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ gap_analysis_r155 Gap Analysis — UNECE R155 Cyber Security Management System (CSMS) Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. ↳ ot_machinery_gap Machinery Regulation Gap Analysis — EHSRs (EU) 2023/1230 Premium + Gap findings mapped to the target framework at article level, each with regulatory citations, plus a coverage percentage. micro_threat_model Scoped threat delta Team + A scoped threat delta: changed input pins, affected baseline conclusions, proposed additions, changes and retirements, unresolved bases and observed usage. sora_operational_authorisation SORA — Specific-Category Operational Authorisation (Drone) Premium + A SORA determination record — iGRC/final GRC, ARC, SAIL, the applicable OSO set with robustness levels, and containment requirements — structured to support a specific-category authorisation application. threat_model STRIDE Threat Model Free + (metered) A STRIDE threat register: per-component threats with category, severity, affected assets, mitigations, and regulatory citations. ↳ ai_threat_model AI / ML System Threat Model (STRIDE + ATLAS) Premium + A STRIDE threat register: per-component threats with category, severity, affected assets, mitigations, and regulatory citations. ↳ drone_threat_model UAS / Drone Threat Model (STRIDE, UAS-scoped) Premium + A STRIDE threat register: per-component threats with category, severity, affected assets, mitigations, and regulatory citations. ↳ ot_threat_model OT / ICS Threat Model (STRIDE, zones-and-conduits) Premium + A STRIDE threat register: per-component threats with category, severity, affected assets, mitigations, and regulatory citations. supplier_assurance_review Supplier Assurance Review (experimental) Team + A Supplier Assurance Review (experimental) of one supplier service: the scope, an evidence matrix with each document's sha256 and each cited paragraph's content hash, typed artifacts (certificates, assurance reports, test reports, supplier answers, bridge letters) with engine-computed certificate validity, a criterion register over law, standards and the customer's policy, each criterion on separate axes (evidence support, result, control state, the verifier's source check and entailment), findings with risk severity and evidence confidence kept apart, supplier dependencies and customer actions as separate lists, evidence gaps, and the decision a named person recorded with conditions before access kept apart from follow-up actions. vulnerability_assessment Vulnerability Assessment & Control-Investment Plan Premium + 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. deferral_dossier Vulnerability Deferral Dossier & Control-Investment Plan Premium + A vulnerability deferral dossier over findings the customer proposes to defer: per-finding deferral records (contextual score, credited controls, verbatim disposition status, deterministic CRA Art. 14 reporting flags), adjudicated regulatory anchors with pin-cites, the greedy-set control-investment plan with the immovable floor, and a merged CycloneDX VEX. What Ansvar does summarises the catalogue by plan. Walkthroughs and family pages Your first gap analysis — the full tutorial, including the search-driven Premium alternative. Family page: gap analysis . DPIA — stages and the report you get back. Family page: DPIA . Threat modeling — the STRIDE workflow, DFD-first. Family page: threat model . Run a TARA — scope, risk criteria, attack paths, treatments and report delivery. Family page: TARA . Product guides for vulnerability decisions . Slash-commands Several workflow families ship MCP Prompts your client surfaces as slash-commands (tender review, threat modeling, gap analysis, FRIA, SCA scoring, the tabletop exercise; the free ansvar-tour prompt is a guided tour, not a workflow driver). The workflow prompts 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 Audit ledger Next Cite your documents --- ## 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 "Using Ansvar, 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 and never visible outside your tenant — it is shared with your organization's seats when your session carries your organization's identity; sign-ins without it see a personal library. 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 — "Using Ansvar, 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 tenant'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 Workflows Next Validate a claim --- ## Validate a claim · Ansvar AI docs URL: https://ansvar.eu/docs/guides/validate-claim Hand the gateway your agent's reasoning as a claim graph. It refetches every cited provision, compares the quotes, and reports what each conclusion rests on. Validate a claim An agent can cite a real article and still misquote it, or declare a conclusion settled when it rests on a fact only you can confirm. validate_claim catches both before the conclusion reaches your report. Your agent hands the gateway its reasoning as a graph: the provisions it cites, the quotes it took from them, the facts you told it, the assumptions it recorded, and the conclusions it draws. The gateway refetches every cited provision under your own access, compares each quote with the served text, and reports the strength each conclusion can carry. It never answers "passed". The check reads only what the graph declares. A fact or assumption the agent leaves out of the graph is invisible to it, so the value of the tool depends on the agent naming its inputs honestly. The claim graph The graph is a JSON object with a schema ( ansvar.claim-graph.v2 ; v1 is still accepted but has no evidence nodes), the question being answered, and a list of nodes . Two keys are optional: the variables the reasoning turns on and any gaps the agent knows it left. Every node has an id and a kind : clause — a provision the reasoning rests on: canonical_ref , the quote the agent took, its quote_language , the binding it reads (mandate, prohibition, permission, designation or definition), and a lookup address. In v2 the address is exact: lookup.source_id is the served row's citation.source_id and lookup.canonical_ref must equal the node's canonical_ref ; law and article overrides are refused. Add jurisdiction when the source is registered under more than one jurisdiction code. evidence (v2 only) — a served row that is not a statutory provision: a regulatory update ( source_id: reg-intel ), a CVE ( cve-intel ), a decision. Carries the routed source_id , the exact reference it was served under, an optional quotation , and jurisdiction under the same rule as clauses. fact — a statement you gave the agent about your organisation, provenance: customer . assumption — a statement the agent assumed, provenance: assumed . interpretation and conclusion — a statement , a typing of DET (the text settles it) or INT (a reading), and depends_on , the ids of the nodes it rests on. A minimal graph, one provision and one customer fact: json Copy { "schema": "ansvar.claim-graph.v2", "question": "Must we report a major ICT incident to our competent authority?", "nodes": [ { "id": "C1", "kind": "clause", "canonical_ref": "DORA:art_19", "lookup": { "source_id": "eu-regulations", "canonical_ref": "DORA:art_19" }, "quote": "Financial entities shall report major ICT-related incidents to the relevant competent authority as referred to in Article 46 in accordance with paragraph 4 of this Article.", "quote_language": "en", "binding": "mandate" }, { "id": "F1", "kind": "fact", "statement": "We are a licensed credit institution in Germany.", "provenance": "customer" }, { "id": "K1", "kind": "conclusion", "typing": "DET", "statement": "We must report major ICT-related incidents to BaFin.", "depends_on": ["C1", "F1"] } ] } Pass that object as the graph argument as it stands. A JSON-encoded string of the same object is still accepted. Send the prose answer alongside it as answer and the gateway compares its quotations too; leave it out and the response lists that check under not_checked . What the gateway checks Refetch. Every clause and evidence node is fetched again under your tier and add-ons. A source your access does not cover comes back withheld , never as content; a reference the corpus does not serve comes back not_served ; a transport failure or timeout comes back unavailable . Nothing is taken from the graph on trust. Bind. The clause quote is compared with the served text. A match marks the clause bound ; a quote that stops short of the served sentence without marking the omission binds with an unmarked-omitted-tail warning (an omission elsewhere in the quote is not detected). A quote in a different language from the served text counts as a reading at best; a row served without language metadata stays unverified rather than assumed to match. Evidence nodes resolve separately: a resolved row reports resolved_evidence with a resolution verdict, but resolution is not claim support, so the node stays UNVERIFIED and so does every conclusion that depends on it. Propagate. Strength flows through depends_on and a node carries the weakest strength among its inputs. DET needs bound text in the declared language with nothing capping it. INT is the ceiling for a declared reading, a translation, a bound clause whose edition the corpus tracks but has not verified, and every fact and assumption, which the gateway records as unconfirmed rather than adjudicates. UNVERIFIED is anything that could not be checked, plus a node in a dependency cycle or a derived node that reaches no clause at all. Every fact or assumption a node rests on is listed under its conditional_on . Report. A summary block states, in plain words, what each conclusion rests on, the errors and warnings that need attention, and every limit; the typed result underneath lists every check it ran ( checked ) and did not run ( not_checked ) with a reason for each. Reading the response The response opens with a summary block written by the gateway, not by the agent: a headline, one entry per conclusion, an attention list, the limits, and a display_markdown text the agent is asked to relay unchanged. It describes what was matched and what each conclusion rests on. It never says a claim holds. For a four-conclusion graph (one provision matched, one withheld, one regulatory update resolved, one customer fact, one wrong paragraph pinpoint) the relay text reads: text Copy **Claim check** — 4 conclusions checked; 2 declared settled by the provision came back weaker. Not a verdict: what was matched and what each conclusion rests on. A matched quotation does not show that a conclusion is supported; claim support was not checked. **K1** "We must report major ICT-related incidents to BaFin." — rests on your input (declared settled, came back weaker). Claim support: not checked; agent declared: settled by the provision. Because: F1 — your input, not checked by the gateway: "We are a licensed credit institution in Germany." Matched provisions: DORA:art_19 (EU, served in en). Next: Confirm the input, or state the conclusion as conditional on it. **K2** "BaFin's guidance sets the reporting template." — rests on resolved evidence; claim support not assessed. Claim support: not checked; agent declared: a reading. Because: E1 (reg-intel REG-2026-0912) — reference resolved, quotation matched; claim support not assessed. Level 1 does not assess whether evidence supports a claim. Matched provisions: DORA:art_19 (EU, served in en). Next: Treat the conclusion as sourced, not checked: level 1 does not assess whether evidence supports a claim. **K3** "Financial entities must report major ICT incidents." — quotations matched; whether they support the conclusion was not checked. Claim support: not checked; agent declared: settled by the provision. Matched provisions: DORA:art_19 (EU, served in en). Next: The quoted provisions are real and match; whether they support this conclusion is your judgment. **K4** "BaFin is the competent authority." — support not established by this check (declared settled, came back weaker). Claim support: not checked; agent declared: settled by the provision. Because: C2 (DORA:art_46) — source withheld: edition_held; The requested edition is withheld. Read the withheld reason (licensing, edition, scope or plan) before citing this source. Next: Resolve the source problem the reason names, then run the check again. Attention: error: paragraph_pinpoint C1 — pinpoint '(2)' differs from located ['1'] | error: G5 C2 — withheld | some sources were withheld under your plan or licence Not checked here: whether the cited evidence supports each conclusion (claim support); whether a provision is in force today; whether the reasoning translates the provision correctly; whether these rows were served to you in an earlier call; whether the conclusion follows from its premises (logic and entailment); whether the declared gaps are answerable from the served corpus; quotations in a prose answer (no answer supplied). Each conclusion gets one outcome, chosen by what you must do first: support not established by this check (a cited item failed: withheld, not served, not reached, quotation not found), rests on resolved evidence; claim support not assessed (a regulatory update, CVE or decision resolved, but level 1 does not judge whether it supports the claim), rests on an assumption , rests on your input , a reading of matched provisions (a translation, an unverified edition, or a conclusion the agent itself declared a reading), or quotations matched; whether they support the conclusion was not checked . "Declared settled, came back weaker" is added whenever a conclusion the agent declared settled computed lower. The machine findings list keeps every finding. The summary shows errors and warnings in three places: the attention list, the "came back weaker" flag for an overclaimed conclusion, and a Because note on a conclusion whose stated quantity is not in the cited text. Informational findings stay in the machine layer. A wrong pinpoint or an unmatched quotation in a prose answer is never hidden by a strong conclusion. The response keeps what the gateway checked apart from what your agent judged. On every node, evidence_checks records the checks themselves: whether the source resolved, whether the quotation matched, the served language, and the dependencies. On interpretations and conclusions, agent_assessment holds declared_typing (the DET or INT the agent declared) and attribution: "agent_judgment" . evidence_ceiling is the highest typing the checked evidence allows, and claim_support is always not_checked . A matched quotation shows the text is real and quoted correctly; it does not show that the text supports the conclusion. That part stays your review. One evidence check looks at numbers. On interpretations and conclusions, evidence_checks.stated_quantities says whether each plain deadline, duration, percentage or euro amount in the statement appears in the cited text: all_in_cited_text , not_in_cited_text , not_checked (including any text not declared English; the check reads English only) or not_applicable (no plain quantity). With not_in_cited_text , stated_quantities_detail gives missing , cited , cited_from and suggested_correction , and the findings carry a quantity_consistency warning. For a conclusion, the summary adds a Because note asking where the value comes from. For an interpretation, the warning appears in the attention list, and dependent nodes receive a reason naming the interpretation. This is a fact about the text, not a finding that the conclusion is false: "36 hours" can be derived from "half of 72 hours". It changes neither the evidence ceiling nor the outcome. For integrators: the machine layer Below the summary the response keeps the typed result the summary is derived from. nodes carries each node's status ( bound , withheld , not_served , unavailable , resolved_evidence , unconfirmed , analysed , and the quotation-mismatch states), its evidence_ceiling ( DET , INT , UNVERIFIED ; the legacy field strength carries the same value), evidence_checks , agent_assessment , claim_support , reasons and conditional_on . The summary's conclusions carry evidence_ceiling , declared_by_agent and claim_support , and, since summary schema ansvar.claim-check.summary.v2 , the stable codes outcome_code ( not_established , evidence , assumption , fact , reading , matched ) and declared_code ( DET , INT ). Match on the codes; the outcome and declared phrases are display text; conclusions in the typed result adds declared and a reason_chain per dependency. findings lists structural and quotation problems by check id; the G6 error is the overclaim the summary renders as "came back weaker". checked and not_checked list every check by id with a reason. Strength ranks UNVERIFIED below INT below DET and a node carries the weakest strength among its inputs; facts and assumptions are INT and unconfirmed ; UNVERIFIED means the checked evidence or dependencies did not permit a verified evidence ceiling, never that the claim is false. Whether the claim is supported stays not_checked at every ceiling. bounded and unreached_clauses sit at the top level (see Limits). Limits At most 100 nodes and 60 refetches (clause and evidence nodes together) per graph; 128 KiB of graph JSON and 64 KiB of answer prose. Larger inputs are refused before any refetch, with the offending field named. The refetch phase has a 25-second budget. A large graph citing one corpus takes tens of seconds. When the budget runs out the response is marked bounded: true , states how many clause and evidence refetches it did not finish in unreached_clauses , and leaves those nodes and the conclusions that depend on them UNVERIFIED . Finished nodes keep their real status. Pan-European preparatory works are not resolvable through this tool yet and refuse explicitly. What it does not do Read the output as evidence for your review, not as a verdict. The check does not prove that a row was served to you in an earlier call; it proves the row is served now. It does not judge whether the reasoning translates the law correctly, since a wrong reading can bind to real text. It does not verify that a provision is in force today. It does not evaluate the logical constraints or entailments a graph may carry; they are validated and kept, not solved. And it does not confirm your facts: a conclusion conditional on a customer fact can be no stronger than that fact, and may be weaker for other reasons. Asking for it The tool is available on every tier. The useful moment is after the agent has fetched the statute text and before it states a conclusion: text Copy Using Ansvar, build a claim graph for that conclusion and run validate_claim on it before you state it. Show me every conclusion whose strength came back lower than declared, and what it is conditional on. Where the refetch goes The gateway refetches through the same routes your session uses, with the same tier, add-on entitlements and jurisdiction scope. A premium source you have not licensed comes back withheld in the check exactly as it would in a search. The check adds no access. Previous Cite your documents 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:2023, 27002:2022, 27005:2024, 42001:2026, and ISO/SAE 21434:2021 (the SIS editions) — and any standard SIS publishes can be requested. The add-on is a per-seat subscription from € 99 per standard per month. A named individual can hold a standards seat on any plan, Free included. A machine holder uses a service credential, which requires Premium, Team or Company. Subscribe from your account area (Licensed standards); the standards page lists what is covered and the worked configurations. Buying and entitlement Purchase is self-serve from your account area — 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 Validate a claim Next Sources served on instruction --- ## Control scope repository · Ansvar AI docs URL: https://ansvar.eu/docs/guides/control-scope-repository A private GitHub repository as your compliance decision plane — your agent reads the Control Library and proposes scope changes as pull requests people approve. Your control scope repository The Control Library gives your agent one NIST 800-53 control spine with framework catalogs — ISO 27001, NIS2, DORA, CRA, BSI C5 and more — and reviewed mapping links growing from that spine (ISO 27001 and other editions returned by coverage ), served through the gateway at Team tier and above. The control scope repository is the other half: a private GitHub repository, provisioned by Ansvar for your organization, that records which controls apply to you , the decision context behind each choice, and every approval — as reviewable git history your auditor can read end to end. The split is deliberate. Ansvar's library holds the control corpus and the reviewed mapping graph; your repository holds only your decisions about them. Your agent reads one and proposes to the other — and people, never agents, approve. The operating model Reads go through the gateway. Your agent asks the Control Library tools — crosswalk , get_control , coverage and the rest — over the same OAuth connection it already uses for legislation. Every answer names the exact library commit that produced it, so work against a locked scope is verifiable. Writes are pull requests, never gateway calls. There is no gateway write tool, by design: an unreviewed agent write can never become ground truth. The agent drafts profile changes, mapping requests, and review verdicts as files in your repository and opens a pull request with your own GitHub access. Two approvals merge. A repository ruleset requires one approval from your scope-owner team and one from Ansvar's mapping owners, plus a green validation check. The validator is what proves the detail: the two declared reviewers approved the exact commit, and identifiers and locks match the exact library release your scope is pinned to. Merged main is your approved scope history. How it fills You export your ISO 27001 Statement of Applicability from your ISMS tool (CSV or XLSX). Ansvar imports it against a released library version, and a pull request comes back with your scope as data: one profile per certification scope with your applicability decisions and implementation statements, a lock file pinning the exact library release, and generated reports. Nothing becomes your approved scope until your people have reviewed and approved it. From a scope to an implementation assessment Start with START-HERE.md in the repository Ansvar provisions for you. Confirm your locked library release and named reviewers, then open the scope portal with python .github/scripts/scope_portal.py . Visit http://127.0.0.1:8790 on the same machine. The portal is a read-only workbench; changes still go through files and pull requests. Each pull request also includes a generated HTML portal artifact for reviewers. Register your organisational scopes and the frameworks that apply to each. Record requirement-level exceptions with their basis and decision owner; a parent scope does not imply inheritance. Record implementation activities, their planned or implemented status, and the canonical controls they address. Reference evidence and internal policy catalogues by pointer. Assess implementation per control, keeping design evidence and operating evidence separate. Record gaps with an owner, target date and treatment. The portal joins these records so reviewers can see what work remains. Ask your agent to draft the next change using the portal's task prompts. Run the repository's preflight, inspect the pull request and obtain the required approvals on the exact commit. The pinned reference index lets the preflight check control, framework, requirement and policy identifiers without a library credential. When neither the index nor its lock pin is present, the preflight reports that it checked structure only. A missing or mismatched pinned index fails the preflight. A structural pass is not approval of the scope or proof of implementation. The repository's docs/portal-guide.md and docs/activity-guide.md describe the file contracts. Reviewing the mappings with your own agent Staged with your import The mapping-review lane described here is not active yet: today's repository checks and imports ignore it, and Ansvar tells you when it opens for your scope — together with your SoA import. The read side — crosswalk, control lookups, coverage — serves at Team tier today. Once the lane opens, your agent will walk the ISO → NIST candidate mappings requirement by requirement, and your team will record one verdict per requirement: accept — the candidate set fits your scope, recorded as a fingerprint of the exact set at your locked release; accept-gap — no candidates exist and you accept that, on the record; change — you propose a correction, which Ansvar triages: accepted corrections land through a reviewed library release and you re-accept the refreshed set; declined ones can close as an accepted gap; defer — parked with a reason, visibly blocking completion until you decide. The queue drains to zero: every applicable requirement decided, at a pinned release, with the approval trail attached. A verdict is your scope decision — it never edits the shared mapping graph and never becomes a coverage claim; those change only through Ansvar's reviewed releases. Your repository ships with its own guides, including the paste-ready batch prompt and the full verdict rules — they are the contract; this page is the overview. What stays out of your repository Licensed standard text (identifiers and references only), Ansvar's mapping graph, evidence files and raw SoA exports, credentials, secrets, and personal data beyond GitHub handles — implementation statements record decision context, not attached evidence. The repository's checks validate file shapes and identifiers; they do not scan free text, so this rule is yours to keep in statements, reasons, and notes. Getting one Scope repositories are provisioned per customer as part of a Team or Company engagement — Ansvar sets up the repository from the library's template, imports your SoA, and configures the approval gate with your named scope owners. Talk to us to start, or see the ISO standards add-on if you also want licensed clause text cited alongside your scope. Previous Run a TARA 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 have applied since 2 August 2026 — the 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. For the risks named in practices 4 and 5, the gateway also runs the assessments themselves: the gap-analysis workflow has EU AI Act and NIS2 variants (both in the Free/Solo allowance), and when review turns up a drafted DPIA answer, the DPIA workflow is the structured way to finish it. Previous Control scope repository 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, and the same call can narrow those evidence rows with court, date_from, and date_to (see Narrowing case-law evidence below). The query takes at most 500 characters: a longer one, such as a pasted case description, is refused before any source is searched, with error validation_error and code query_too_long (see Errors below). Search one legal issue per call, 2 to 5 terms, and merge the results. get_provision — One article, verbatim, by (jurisdiction, law, article) or canonical_ref — with source URL, publisher, license. Where a corpus keys its acts by identifier, pass the identifier as law and the article in the corpus's own shape: Book 7 of the Dutch Civil Code is law='BWBR0005290', article='7:677' (each book carries its own BWBR identifier). A U.S. federal regulation is addressed by its CFR citation: jurisdiction='US', law='45 CFR', article='164.410' reaches the one corpus that serves that CFR part (law='45 CFR Part 46', article='Part 46' for a whole part). A statute name resolves only where the corpus carries an alias for it; a miss names the search to run and the row whose lookup hint to replay. validate_citation — Check a citation resolves against the served corpus and get its current text for comparison — a deterministic, non-model check. validate_claim — Hand over the agent's reasoning as a claim graph (cited provisions with quotes, customer facts, assumptions, conclusions); the gateway refetches every provision under your access, binds the quotes, and reports the strength each conclusion can carry. Never a verdict. Guide: Validate a claim, under Guides. verify_attestation — Verifies an evidence attestation's signature, key lifecycle and time proof, then replays the source-pinned provision under your current access and compares its body hash (current_match, current_differs, not_served, withheld or unavailable). It checks integrity and provenance, not legal validity. The hosted gateway withholds this tool from customer accounts today, so it is not in your tool list. verify_citations — Send back the references a report relies on, each with its source_id and the quotation your text uses. For a provision, take source_id from the row's lookup hint; for a court decision or preparatory work, pass the routed corpus id the row came from (such as dutch-court-decisions), because those hints carry no corpus id, and never the citation's mcp_server display name. The gateway re-retrieves each one under your own access, checks the returned row's producer-declared identity against the reference, and only then compares your quotation with the body. One verdict per subject: quote_checked, reference_resolved, quote_mismatch, identity_mismatch, identity_absent, not_served, withheld, unavailable, plus no_quotation_submitted (an empty or too-short quotation) and reference_unparseable. A subject with no source_id, or on a corpus the identity check does not cover yet, returns identity_absent rather than passing; the response lists which corpora each lane covers. Lookups count against your normal lookup quota. All plans. list_coverage — What's live: by jurisdiction, by domain ("Using Ansvar: which jurisdictions for NIS2?"), by region, or by kind of legal text with content_kind: statute, court-decisions, preparatory-works or disciplinary-decisions ("Using Ansvar: which countries have court decisions?"). The telecom domain is telecommunications-media; domain='telecom' is accepted for it. discover_eu_legislation — Find EU legal acts by CELEX or ELI identifier, official title, reviewed alias, or a lexical (not semantic) match on title and EuroVoc labels, filtered by EuroVoc topic, sector, document type, or availability. Each candidate states its per-edition currency and any hold reason, names the eu-regulations framework key where the same act is keyed there, and carries the exact search and lookup hints to call next. All plans. get_changes — Change records from supported corpus feeds, including observed text changes in Dutch law. Read supported_scopes and each row's change_event: a text change is not automatically a legally identified amendment, and a baseline is not a change event. Availability depends on the routed source and your account; unsupported scopes return a refusal. 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. get_regulatory_update — One regulatory publication record by record_id — the lookup every search_regulatory_updates row names in its _citation.lookup. Premium and above. get_regulatory_deadlines — Dated obligation events that are coming — entry into force, application and phased application dates, transposition deadlines, compliance deadlines, repeals — soonest first. A curated row names the provision that states the date in its basis field; a publisher-metadata row carries only the date, instrument, event kind and citation, so read date_source on each row. Provision text is not included; fetch it with get_provision. A request for an EU-27 member state also returns the EU-level rows that bind there; include_eu_level=false turns that off. The calendar is curated, not exhaustive: every response says so in its completeness field, and the absence of a row is not the absence of an obligation. Bills and unsigned instruments appear only behind include_pending, in a separate array, carrying their procedural stage and never a date. Premium and above. get_regulatory_intelligence_status — What the regulatory monitor actually watches and how current each source is: enrolled sources, publisher, channel, jurisdictions, last successful sync, freshness state. Free — check the watch surface before relying on it. diff — Version comparison of one provision needs a corpus that declares a gateway diff route. At this review (23 September 2026) no routed corpus declares one, so diff returns no results and an explicit unsupported-scope reason rather than a comparison; corpus-local version history does not make a gateway diff callable. Check live discovery before attempting a comparison. describe_capabilities / get_my_capabilities — Your tier's live tool list, sources, quotas, and limits. Use describe_capabilities(section='use_cases') for compact task entry points, describe_capabilities(section='sources') with query, domain, jurisdiction or content_kind to page through the sources, and get_my_capabilities for the live tool_surface fingerprints and refresh_hint. Reading a search response search starts with strict full-text matching across the sources in scope. A corpus can also match a controlled vocabulary term for your concept. These vocabulary-bridge rows serve by default as match_mode: "bridged" ; they are assisted matches, not literal matches to your original terms. Strict rows keep their place before the assisted rows. OR-style relaxation can match only some of your terms. The gateway withholds those rows; offer a re-run with allow_broadening=true and re-run only if they accept. Accepted rows carry match_mode: "broadened" . A bare uppercase OR between alternative terms is an explicit either-or query. Do not rebuild this ladder in your own instructions: widening the query yourself changes what counts as a strict match. The fields to read on a search response: results[].match_mode — absent on a strict match; "bridged" on a controlled-vocabulary match that can serve without consent; "broadened" on an OR-style relaxed match. On search , only the last requires allow_broadening=true . Preserve these labels when explaining what the source matched. meta.outcome — "NO_STRICT_MATCH" when at least one source was searched, every source answered, no access gate (licensing, entitlement, attribution) withheld a strict row, and no served row matched strictly. It means "these terms did not match", not "this law does not exist", and it is never a cue to answer from model memory. meta.recommended_action — "RETRY_ONE_CONCEPT_PER_CALL" : the query carried three or more tokens after the gateway's sanitisation (stop words count) and asked for one row holding all of them; split it into one search per concept. The gateway never splits a query or adds terms to it; it does strip unsupported operators and punctuation before dispatch. "OFFER_BROADENING_TO_USER" : the query already had one or two tokens (or an honoured OR), so splitting is not a recovery, and relaxed candidates exist; tell the user, offer a re-run with allow_broadening=true , and re-run only if they accept. It says nothing about whether your terms were the corpus's own vocabulary. meta.recommended_queries — optional short retry candidates drawn from your own terms, with the original scope. They accompany a clean multi-concept strict miss. Your agent chooses which to run; the gateway has not executed them. meta.recovery_guidance can also explain a refused or empty request. For a short query without relaxed candidates, REFORMULATE_OR_USE_EXACT_REFERENCE asks you to try the source's terminology or an exact provision reference. meta.broadening_available — set only on a strict miss (no served strict row, no access-gate withholding, at least one source searched): true when relaxed rows were withheld for this call, including on a partial fan-out where a source that did answer withheld them; false when none were on a clean fan-out; null when the answer is unknowable (a partial fan-out with nothing withheld) or when the field does not apply. When strict rows serve beside withheld relaxed rows, the offer is in meta.message and the count in query_broadened_sources[].withheld_results , which is always populated. meta.query_broadened_sources[] — one entry per source and relaxation rung (a source can appear twice under two modes): the source, the query as the corpus received it ( requested_query , normalised after the gateway's sanitisation), the rung ( mode : term_bridge , or_rank , strict+or_rank_merge , drop_trailing ; empty on older corpus versions), and the rows withheld ( withheld_results ). meta.recommended_scopes — registered scope ids this call did not search, for example the delegated and implementing acts of a framework you scoped to. Absent when there is nothing to name; on a strict miss with nothing withheld, this is the recovery when it is present. meta.strict_row_provenance — on a jurisdiction-scoped search, how many served strict rows are national, EU-framework, or unclassified, so you can see when an NL-scoped answer is carried entirely by EU-level texts. meta.coverage_context — on a jurisdiction-scoped search with no strict row, the domains that jurisdiction's coverage spans, so an empty result is not read as "no such law". meta.off_topic_withheld_rows — rows removed by the relevance checks. Accepting broadening does not bypass those checks or guarantee that the candidate rows will serve. meta.message explains any withholding. meta.message — the prose form of the disclosures; the offer wording appears when relaxed rows were withheld. Read the typed fields; the prose is not a substitute for them. allow_broadening defaults to false . Pass true only after the user accepted the offer or asked for relaxed matches. The flag does not gate vocabulary-bridge rows. Served OR-style relaxed rows arrive stamped match_mode: "broadened" and pass the same relevance floor as strict rows. search_guidance has no such flag today: its relaxed rows serve by default and carry the same stamp, so read match_mode there too; the strict-miss fields above ( outcome , recommended_action , recommended_scopes , broadening_available ) and the bare-OR disjunction are search only. The instruction wording that puts this into an agent's system prompt is on Instruct your agent . Narrowing case-law evidence: court, date_from, date_to Since 2026-09-03 search takes three optional filters. They apply to the evidence rows the Premium fan-out adds: the court filter to case-law rows, the date bounds to case-law rows and to preparatory-work and agency-guidance rows. Primary-law provisions carry no court, and the date bounds do not filter them: statute rows stay in the window whatever bounds you pass. Free and Solo searches carry no evidence rows, so all three are refused there with the upgrade note. court — an exact match on the corpus's own court value. Dutch courts are codes (HR, RVS, CRVB, CBB, GHAMS, RBAMS, RBDHA and the rest); other corpora may carry a court name. Read the value from the court field of a row returned without the filter before you filter. A value that matches no row is disclosed in meta.message , never served as a silent empty. date_from / date_to — inclusive bounds as full ISO dates ( 2026-01-01 ; a bare year is refused), on the decision date of case-law rows and the issue date of preparatory-work and guidance rows. date_to must not precede date_from . Example: search(query='huurovereenkomst', jurisdictions=['NL'], court='RBAMS', date_from='2026-01-01') . The result window still places primary-law rows first, so when only decisions are wanted scope the call with sources=['dutch-court-decisions'] or raise limit . An argument the tool does not declare, a misspelt filter name for instance, is refused with JSON-RPC -32602 rather than ignored; see Errors below. 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. batch_search — Details for up to 100 CVE ids in one call. search_by_product — CVEs affecting a product/vendor. search_ics_advisories / get_ics_advisory — CISA ICS/OT advisories — ICSA (general industrial), ICSMA (medical), ICSV (vendor). Search by keyword, vendor, advisory family, minimum CVSS, or publication date and get affected vendors, CVE counts, and severity; the lookup takes an advisory_id (ICSA-24-001-01) and returns the affected products with version ranges, the referenced CVEs with CVSS, the summary, and the CSAF source URL. Public-domain CISA CSAF data. get_data_freshness — Per-feed last-sync timestamps for the live data — how fresh the answer is. The CVE intelligence engine serves these public facts from Free and includes feed-sync timestamps; the CAPEC, CWE, and D3FEND catalogues are on every plan too. Team adds effective-risk rescoring against customer asset context, review decisions, and OpenVEX export. Guide: Vulnerability intelligence, under Guides. Legal evidence layer — Premium + search_guidance — Agency guidance from regulators, standalone (the guidance slice of the premium fan-out). The same 500-character query limit and query_too_long refusal as search. get_decision — One court decision plus its cross-references — the case-law analog of get_provision. get_preparatory_work — One preparatory-work record — bills, propositions, committee reports, legislative history — by jurisdiction and canonical reference; search surfaces the hits inside the premium fan-out. Case law and preparatory works have no standalone search tool — they arrive inside search's automatic premium fan-out. Document citation tools — Premium + get_document_segments / resolve_document_segment — Read uploaded documents at paragraph level and round-trip doc:// citations with content hashes. These read-only citation tools do not include listing, uploading, deleting, or binding documents. Document library & upload tools — Team + list_my_documents / register_document_init / register_document_finalize / register_document_text / delete_my_document — List, upload (presigned PUT, or register_document_text for pasted text), and delete documents in your document library (shared across your organization when your session carries your organization's identity; sign-ins without it see a personal library). See the Cite your documents guide for the full loop. Your standards — Premium + list_org_standards / get_org_standard_clause / search_org_standards — Query the standards in your own library the same way you query law. list_org_standards returns each standard's id (such as iso_27001_2022), status (ready, processing, failed), clause count and any error; get_org_standard_clause takes standard_id and clause_id (A.5.15, 6.1.2, CC6.1) plus document_id when a standard was uploaded twice, and returns title, text, parent section, page and a doc:// URI; search_org_standards returns up to 50 ranked clause excerpts. Each library is private to its user today: scope='company' is not implemented. Uploading a standard is not open to customers yet. Different surface from the SIS ISO standards add-on (licensed ISO text served by Ansvar) — see the ISO standards add-on guide under Guides. Guide for this family: Org standards library. Control library — Team + list_controls / get_control — Canonical controls on the NIST SP 800-53r5 spine plus ANSV-* extensions — filterable by control family, CSF 2.0 function, or applicability profile; one control returns its statement and the framework requirements it maps to. get_requirements — The framework requirements a canonical control maps to (ISO 27001/27002, NIS2, DORA, CRA, C5, 800-171, …), each with its relationship type and review status — review-approved mappings only by default. list_obligations — The standing obligations recorded under one framework edition — the reviewed obligation layer beneath the requirement nodes — without provision text. Filter by an exact requirement id or by review state (proposed, approved, declined); proposed rows are marked provisional. Every row carries its requirement's get_provision pointer, so the normative text resolves through the gateway at your corpus tier instead of being reproduced here. An unknown id or a framework with no obligation catalog is reported as such, never as an empty success. crosswalk — Framework A requirement → the canonical controls that satisfy it → framework B's requirements on those controls. Crosswalks route through the spine; only human-reviewed mapping claims count. resolve — A requirement id to its citation descriptor (source, edition, ref, and the gateway resolution parameters) — the clause text itself is then fetched through the gateway at your corpus tier. coverage — Mapping coverage against reviewed edges and composite assertions, optionally scoped to an applicability profile. Start with detail='summary'; use detail='requirements' with a framework and edition to page through requirement rows, filtered by status and paginated with limit/offset and page.next_offset. detail='full' returns the complete report. Omitted detail still means full in v0.3.5; pass it explicitly. Mapping coverage does not assert customer compliance. changes — Each framework's pinned version and source artifact hash, plus migration maps between major framework versions. Change-detection reports and mapping-edge drift are not produced yet: the tool returns an explicit no-change-detection-report status rather than an empty drift list. Distinct from the corpus-side get_changes. The library behind the /control-library page — one canonical spine, pointer mappings to the frameworks, coverage counted over reviewed claims only. Guide: Control library, under Guides. Workflows — Free + (metered teaser types) · interview-grounded catalog Premium + · complete catalog and document plane Team + scope_workflow — Answer a few scoping questions and get the right workflow_type for what you need produced — ambiguity comes back as the next question, never a list of maybes; pass the returned id to start_workflow. 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 across seven types (threat model, gap analysis incl. NIS2/DORA/CRA/AI Act, DPIA) on a system you describe, with a watermarked render or JSON and no overage. Premium includes 5 across the full interview-grounded catalog with structured JSON reports and unwatermarked HTML, PDF, and DOCX exports. Team runs 20/seat/month and adds document grounding. 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 — Premium + inside workflow runs · Team + standalone effective_risk_inline / effective_risk_inline_batch — Context-supplied CVSS rescoring of a CVE, single or batch. Premium can call them only inside an admitted run: the batch scorer in vulnerability assessment, deferral dossier and ICS advisory-to-risk runs, the single scorer in ICS advisory-to-risk runs. Team can call them standalone. 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. Premium run-scoped (vulnerability assessment and deferral dossier runs); Team standalone. effective_risk — Rescoring against a full asset configuration (a scoring context) you send in the call; Ansvar stores no contexts or results. A result carries a signed review_token, or review_token_unavailable saying why it could not be signed. Team +. list_scoring_policies — The rule sets the scorer can apply: policy_v1_engineering accepts attested control evidence, policy_v1_audit only evidenced controls. A control counts as evidenced only when its evidence_refs resolve to doc:// segments of documents you registered. Team +. record_review_decision / export_vex — A person accepts or rejects a disposition by passing its review_token (agent and service credentials are refused), and review tokens serialize as an OpenVEX document. Team +. Every effective-risk tool labels its output experimental. Guide: Effective risk, under Guides. Architecture workspace — Your own workspace (standalone or customer plane), not the hosted gateway arch_overview — Per-kind resource counts, trust zones with exposure, unclassified and uncontrolled asset counts, unmitigated threats, pending proposals and waiting import batches, when each kind last changed, bootstrap state, scoring readiness, and how well each kind's fields are cited and proven. The recommended first call. arch_search / arch_get / arch_list — Substring search across every resource kind; one resource by kind and id with its fields, resolved links, provenance, citations, and a proof level per field (optionally as it stood at an earlier revision); one kind listed with equality filters, where an unknown filter key is rejected rather than ignored. arch_list_components / arch_get_component — The immutable component version rows of one service, and one component by id. arch_list_assessments / arch_get_assessment — The assessments recorded against the model, filterable by kind and currentness (computed at read time), and one assessment with its dependencies and the causes that made it stale. arch_locate — Which services a repository location realises: pass a repository and optionally a path and an environment, and get the services whose mapping covers it, ordered by path specificity, plus the custom applications they realise. When more than one service could own the path, all of them come back flagged ambiguous; with nothing mapped, the answer says whether the repository is known to the workspace at all. Stores nothing. arch_traverse — Breadth-first walk from a start node across the edge families, optionally restricted to a subset. Depth capped at 3; direction out, in, or both. arch_coverage — Compliance-obligation rollup by regime and assessment status, the obligations with no ADR or control evidence linked, unclassified and uncontrolled assets, plus findings such as zone crossings with no protocol or authentication and rows nobody has confirmed recently. Scope it to one regime when that's all you need ("Using Ansvar: which NIS2 obligations have no evidence linked?"). arch_dfd / arch_export — Render a deterministic Mermaid data-flow diagram (the whole org, a zone, a list of services, or a C4 context or container view), or export the accepted graph as a lossless JSON bundle that imports into an empty workspace, or as Mermaid diagrams. Both read; neither writes. arch_questions — The open questions about your architecture, highest consequence first, each with the arch_propose or arch_confirm call its answer turns into. A question closes when its answer is approved. arch_verify_citations / arch_currency — Re-check a resource's field and edge citations (unchanged, moved, or unreachable) without changing the model; read one node's accepted revision, last confirmation, and what each enrolled source last saw of it. arch_sources / arch_observe — Enrol a local git repository as a source and observe it at its current commit. An observation returns one reviewable import batch with every field cited to commit and line; nothing applies on its own, and a node missing from a scan is never retired automatically. arch_propose / arch_propose_component / arch_propose_retire — Propose a create or update of one resource, a new immutable component version, or a soft retirement, each with the evidence behind it. Unknown fields, bad enum values, and links to ids that don't exist in your org are rejected. Each records a proposal; nothing changes until a reviewer approves, except inside a bootstrap window for the one machine principal it admits. Proposing a reference for an unkeyed row (kind re-key) always waits for a reviewer. arch_propose_re_review — Present a resource's full current state for a different reviewer to approve. This is how a self-approved row becomes reviewed. The reviewer must differ from both the proposer and the principal already recorded on the row. It changes no field and never auto-applies inside a bootstrap window. arch_list_proposals / arch_get_proposal — Your organization's proposals newest first, filtered by status, kind, or proposer; one proposal with its full diff, evidence, and the reviewer's comment. arch_review_proposal — Approve or reject a pending proposal. Org-admin only, agent seats refused, and the reviewer is never the proposer. Your comment goes on the record verbatim. A standalone workspace takes approvals in its browser review page; approving over MCP works only after the Owner enables it there. arch_import_batch — Stage a CSV or JSON file of nodes and edges as one reviewable batch, read it, and review it item by item. An org-admin approves; the server applies the dependency closure in one transaction, and no item ever retires a row. Inside a bootstrap window, a batch from the admitted principal with no conflicts applies on staging. arch_confirm — Record that a row is still true as of now. Org-admin only; a person asserts it, never an agent seat. arch_bootstrap — Read or control the seeding window. Any caller can read the status; start and stop are org-admin only. A window admits the proposals of one named machine principal, never a person and never the admin who opened it, for the kinds in scope, and expires within 24 hours. arch_grants — What each machine principal may do, on independent axes: read or read-and-propose, recording assessments, and observing one enrolled source. Review is never grantable. Org-admin only, reads included; agent seats refused. arch_workspace — The workspace's status: versions, profile, row counts, currency, and any open bootstrap window. On a standalone workspace file an org-admin can also back it up or clone it to a new machine, and the Owner can require citations on proposals; a plane workspace refuses backup and clone, since the operator backs up its database. 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. These tools are served by the architecture workspace you run yourself, on your machine under an evaluation or workspace licence or inside your customer plane; Ansvar never hosts your model, and the hosted gateway does not serve this family. A standalone workspace also advertises arch_record_assessment for its assessment producer, and standalone and plane workspaces add arch_list_stale_assessments and arch_scoped_read. Your workspace's own tools/list is the authoritative roster for the version you run. Audit ledger — Company get_receipt / list_receipts / verify_receipt — Tamper-evident receipts of what was asked, what was returned, and when. list_receipts requires date_from and date_to (no default window), filters by conversation, message, tier or entry kind, and pages with next_cursor (limit clamped at 500); a member sees only their own receipts. get_receipt returns one encrypted envelope by query_id. verify_receipt checks the chain hash and the RFC 3161 timestamp-authority signature. export_audit_package / decrypt_receipt — Audit bundle export for a date range: the full bundle (envelopes, anchors, timestamps, signatures) verifies offline, the summary bundle (include_envelopes=false) does not; scope is range (whole organisation, org-admin), mine, chat or message; include_plaintext=true adds decrypted content for an org-admin; an oversize bundle is refused with its size, never truncated. decrypt_receipt decrypts one receipt server-side with your tenant's KMS key, by query_id or receipt_id, org-admin only, and records the decryption on the chain. Guide: Audit ledger, under Guides. 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. Guide: EU regulation engines . Architecture writes are proposals In steady state, arch_propose , arch_propose_component 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. A source observation never applies on its own; it returns an import batch for review. The one exception is a bootstrap window: while an org-admin holds one open, proposals from the single machine principal it names, for the kinds in scope, apply on the spot under that standing assent, stamped bootstrap in their provenance, and so does a conflict-free import batch from that principal. Re-reviews and re-keying still wait for an ordinary reviewer. Every change carries who proposed it, on what evidence, and who approved it, so you can let an agent write to your architecture model and still audit each change. Keep the lookup tools enabled in your client Every _citation.lookup hint on a result row names a gateway lookup tool — get_provision , get_decision , or get_preparatory_work — with the arguments that re-fetch that exact row. If your MCP client lets you enable a subset of the tools it discovers, keep those enabled alongside search . A lookup tool your tier includes but your client never listed is a tool the agent does not have, so the refusal reads as a plan limit when it is a local tool-list gap. Errors are structured Calling a tool your plan does not include returns a tool result with isError: true whose text names the plan that includes it; a tool name the gateway does not know returns JSON-RPC -32601 (method not found). Exceeding a quota returns -32000 with data.cause = "cap_exceeded" . A call that carries an argument the tool's schema does not declare returns -32602 (invalid params) naming the accepted arguments: since 2026-09-03 the gateway refuses such a call instead of dropping the argument silently, so a misspelt filter is a visible error, not an unfiltered result. A search or search_guidance query over 500 characters returns a tool result with isError: true and a typed body: error: "validation_error" , code: "query_too_long" , max_chars , query_chars and a message. Nothing was searched, so split the query into separate issue queries instead of retrying or shortening it. 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. "Available on the … plan" refusals The tool exists but not for your plan. Tier-gated tools are absent from tools/list ; if your agent calls one anyway, the gateway returns a tool result with isError: true and a text such as " register_document is available on the Team plan and above; your plan is Premium, so the tool is not in your tools list. Tell the user; do not retry this call." followed by a link to compare plans. That example is the classic case: a document-plane tool called on Premium (the document plane is Team+). Two variants: the arch_* tools belong to the Ansvar architecture workspace, which runs on your own machine or plane and is not served by the hosted gateway on any plan (the refusal links to the workspace evaluation ); a few tools are not open to customer accounts at present on any plan, and their refusal links to contact . JSON-RPC -32601 ("Method not found") now means the gateway does not offer that name to you at all: usually a misspelt or invented tool name, or a stale tool list in your client. Refresh the client's tool list and use a name from tools/list . 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 . A tool can also lack a supported source for the scope you requested. get_changes now has a Dutch-law feed; that does not make history available for every jurisdiction. Read the refusal's supported_scopes and the live capability response. A corpus-local history API does not imply a gateway diff route: no gateway diff scope is available at this review (7 September 2026). For newly published acts, use search_regulatory_updates (Premium and above); to re-fetch a citation's current text, use validate_citation . A third shape is client-side and never reaches the gateway: if your MCP client lets you enable a subset of the tools it discovers and the lookup tools were left off, an agent following a row's _citation.lookup hint has no get_provision , get_decision or get_preparatory_work to call, and says so in words that sound like a plan limit — see the tool reference . "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; if the response still reports withheld relaxed matches ( meta.broadening_available is true, or meta.message says so), the agent tells the user and offers a re-run with allow_broadening=true , and runs it only if they accept — returned rows are stamped match_mode: "broadened" , so label them as relaxed matches. The full recovery ladder is in Instruct your agent . Vocabulary matches already served. Rows labelled match_mode: "bridged" use the corpus's controlled vocabulary and can appear with broadening off. Keep the label; they do not require a consent re-run. The separate "broadened" rows keep the consent rule above. 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. A new tool or argument is missing Call get_my_capabilities and inspect tool_surface . Its fingerprint identifies the tool roster; contract_fingerprint also covers descriptions, schemas and annotations. Read refresh_hint . Compare a fresh tools/list with the definitions your client exposes, using the same identity and client policy. A difference can come from cached metadata, a packaged integration, or deliberate tool filtering. If the metadata is stale, use your client's connector refresh or reconnection flow. The gateway cannot push a tool-list change notification over its stateless HTTP connection. To discover task entry points without loading the full catalogue, call describe_capabilities(section="use_cases") and read available_to_caller before choosing a tool. "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: "Using Ansvar, 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 the seats your subscription pays for: people, plus service credentials past the five that Team and Company include without a seat (on Premium every credential takes a seat). Admins can: Invite a member by email — they get a seat and an activation email. Someone who already has an Ansvar account in your organization gets the seat at once, with no email; adding a current member changes nothing. 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 --- ## Solutions · Legal research, enterprise assurance and product security · Ansvar AI URL: https://ansvar.eu/solutions Run legal research, enterprise compliance and product-security work from authoritative sources, standards, security intelligence, and customer evidence. solutions Start with the decision due next. Ansvar supports three entry points for regulated work. Each works from authoritative sources with citations you can open. The assessment workflows add structured execution, labelled judgments, review gates, and explicit unresolved gaps. Check live source coverage See the assessment path three places to start One evidence contract across regulated decisions. Begin with the work that has an owner and a deadline. The source classes and customer-document controls carry across all three entry points, and the review rules apply wherever an assessment workflow runs. legal research and casework Put cited legal research inside your AI. Search served legislation and — from Evidence Pro, and included from Premium — available case law, preparatory works, and agency guidance. Keep publisher links, interpretive steps, and unresolved gaps visible for review. Legislation Case law Preparatory works Guidance Explore legal research Check legal coverage enterprise security and compliance Turn policies and system evidence into a cited assessment. Run DORA and NIS2 assessments, ISO 27001 reviews, DPIAs, and third-party reviews with the source classes and documents selected for the job. The result identifies evidence, findings, actions, judgments, and open gaps. DORA NIS2 ISO 27001 DPIA Explore enterprise assurance Explore gap analysis Explore DPIA product security and engineering Turn an architecture into a cited threat model or TARA. Assess software, vehicles, machinery, robotics, medical devices, and OT with product law, licensed standards, security intelligence, and architecture evidence selected for the run. STRIDE TARA CRA ISO 21434 Explore product security Explore threat models Explore TARA Team and Company can ground runs in registered customer documents. Company adds signed receipts, and can add dedicated infrastructure by agreement. Customer-managed deployment is a design-partner path. See plan details . sector context Choose the field around the assessment. Sector pages narrow the relevant regimes, evidence sources, and workflow examples. The evidence contract remains consistent across them. 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 example evidence lines from the result 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 → Use the sector pages to select the relevant context. Use the workflow directory to inspect the available assessment methods and plan requirements. --- ## Financial regulation research and DORA assessments · Ansvar AI URL: https://ansvar.eu/solutions/financial-services Research served EU and national financial regulation, ECB and EIOPA material, and run DORA assessments with source citations in your own AI client. Financial services Research financial regulation with sources you can check. Use Ansvar in your own AI client to research EU and national financial regulation, retrieve supervisory material, and assess DORA gaps. Legal, compliance and ICT risk teams can inspect the source behind a finding and keep missing evidence open for review. Check financial coverage Compare plans Who it is for For the team preparing the research or assessment. Banks, insurers, payment and e-money institutions, investment firms, crypto-asset service providers (CASPs), and their ICT providers can use the gateway with their existing agent. Set the research scope around your institution, jurisdiction and activity. A bank's ICT team can prepare a contract review; an insurer's compliance team can retrieve prudential sources; an ICT provider can assemble evidence for a financial customer's assessment. Served coverage EU instruments, national text and supervisory material. The coverage index identifies jurisdictions and source scope. A jurisdiction listing does not promise a complete national supervisor library. National financial regulation Search financial statute and regulation rows attributed to their jurisdiction. National depth varies. Keep the country scope and the issuing source attached to the finding. EU legislation and technical standards Research the served EU instrument text for DORA and MiCA, including their regulatory and implementing technical standards (RTS/ITS), alongside CRR/CRD, MiFID II/MiFIR, PSD2, EMIR, SFDR, AMLR, Solvency II and IRRD. Check the retrieved instrument's status and dates when researching PSD3 material or amendments. A search result alone does not establish that a provision applies to your institution. ECB and EIOPA Retrieve ECB legal acts and supervisory material, and EIOPA insurance material. Premium adds guidance search. Keep the publication type visible when comparing legislation, opinions and guidance; check the served source's scope and freshness for the topic. ESMA sanctions register rows Search the served sanctions register rows with their source references. This coverage is limited to register entries; it does not establish access to full enforcement decisions or ESMA's guidance library. For the article-cited DORA explanation, see the DORA guide . If retrieval fails or evidence is missing, the agent should report the gap and leave the conclusion unresolved. Plans Choose the evidence your work needs. The pricing page carries current allowances and availability. Research access, interpretive tools and document upload have separate plan boundaries. Free Research the statute text Search served EU legislation and national financial rows within the plan's jurisdiction or framework scope limit. Try the DORA workflow on a system you describe, within the included allowance, with a watermarked report or JSON. See Free details Solo Research across jurisdictions Compare supported national and EU sources in the same question, with the statute and regulation access of Free and more research capacity. The DORA workflow uses a system you describe within the Solo allowance. See Solo details Premium Add interpretive research Search available guidance, case law and preparatory works, then run an interview-grounded DORA assessment with a structured JSON report and an unwatermarked HTML, PDF or DOCX export. Source availability depends on the jurisdiction and corpus. See Premium details Team Assess your own evidence Upload policies and ICT contracts for a DORA gap analysis grounded in your documents. Use applicability checks and regulation guides, and review findings with regulatory references and paragraph-level document citations. See Team details Company Keep signed audit receipts Use the document and research capabilities of Team with signed audit receipts. Agree retention, support and dedicated EU infrastructure through your contract. See Company details Example prompts Start a sourced research task in your agent. These prompts request research. Check plan access before pasting: cross-jurisdiction questions need Solo or above; guidance and interpretive research need Premium or above. DORA register of information Using Ansvar, find the served DORA provisions and technical standards for a register of information. Cite the sources and identify any missing material before drafting a preparation checklist. DORA Article 30 contract clauses Using Ansvar, retrieve DORA Article 30 and the served technical standards relevant to ICT contract clauses. Build a source-cited review checklist and leave unsupported requirements unresolved. MiCA CASP authorisation Using Ansvar, research MiCA CASP authorisation for a firm planning to operate in the Netherlands. Separate EU provisions from Dutch sources, cite the served text, and identify coverage gaps. AMLR readiness for 2027 Using Ansvar, help a Belgian payment institution plan AMLR readiness for 2027. Retrieve the served provisions, verify application dates and scope from those sources, and flag anything you cannot establish. PSD2 strong customer authentication Using Ansvar, research PSD2 strong customer authentication for a payment service in Sweden. Retrieve EU and Swedish sources, distinguish statute text from guidance, and cite the basis for each finding. Solvency II ORSA Using Ansvar, find the served Solvency II provisions and EIOPA guidance relevant to an insurer's own risk and solvency assessment (ORSA). Cite the sources, distinguish guidance from law, and name missing evidence. Setup and paste-ready workflow instructions: agent docs . More examples: financial regulation with your agent . Coverage and evidence questions Which sources can I research on Free? Free includes served statute and regulation text, including national financial rows, within its jurisdiction or framework scope limit. Coverage differs by source and jurisdiction. The coverage page identifies the published source scope; pricing lists the current plan limits. Can I use my own policies and contracts in an assessment? Team and Company add document upload and DORA gap analysis grounded in your evidence, with paragraph-level document citations. Free and Solo include a DORA run based on a system you describe within their workflow allowance. Premium adds interpretive research and interview-grounded assessment with a structured JSON report and unwatermarked HTML, PDF and DOCX exports. How much supervisory material does Ansvar cover? Ansvar serves ECB legal acts and supervisory material, EIOPA insurance material, and ESMA sanctions register rows. Coverage depends on the publication and source. The sanctions register rows do not establish coverage of ESMA's guidance library or full enforcement decisions. Check coverage before relying on a particular publication. Check the sources for your next review. Choose a jurisdiction and research topic, inspect coverage, then connect your agent. View coverage Open agent docs --- ## Legal research and casework in your AI · Ansvar AI URL: https://ansvar.eu/solutions/legal-research Search legislation, court decisions, preparatory works and authority guidance from your AI client, with publisher and source links carried through. Legal research and casework Put cited legal research inside your AI. Ask a legal question from Claude, ChatGPT, Copilot Studio, Cursor, or your own agent. Ansvar searches served legislation and — on Evidence Pro, Premium and above — available case law, preparatory works and agency guidance. Results arrive with their publisher and source URL, and your request tells the agent to leave unsupported conclusions unresolved. Check legal coverage Connect your AI Single-scope public law search on Free Legal evidence layer from Evidence Pro EU-hosted gateway Fictional research request NL · employment Using Ansvar, which Dutch statutory rules and published court decisions govern dismissal during illness? Cite each source, separate law from interpretation, and leave unsupported conclusions unresolved. Legislation Court decisions Source links Expected result: source-linked findings or a named evidence gap. The research path Move from question to sources without hiding the gaps. The agent can draft and compare. Working from served sources keeps the legal basis checkable, and the last step is where a reviewer decides what the sources do not support. Set the scope Name the jurisdiction, issue, date, parties, and facts that shape the research question. Find primary law Search served national and EU legislation, then open the cited provision at its publisher. Add legal context Premium searches available decisions, preparatory works, and authority guidance for the issue. Review the position Check each source and leave any unsupported interpretation open for qualified counsel. Served legal evidence See what supports the answer. Source availability differs by jurisdiction and corpus. The live coverage checker is the authority for what the gateway serves. Legislation National and EU law Search served law, with the provision, publisher, and source link on the row. Premium Court decisions Search published decisions where a court corpus is served for the selected jurisdiction. Court sources we mark restricted because their decisions identify people are served only on an organization's written instruction: how that works . Premium Preparatory works Search available bills, parliamentary papers, committee reports, and drafting records. Premium Authority guidance Search served regulator and public-authority publications, with the publisher carried on the row. Where it fits Use the same evidence layer across research and casework. Start with a question, not a new research interface. The legal team stays in its chosen AI environment and opens the original sources before relying on the result. Legal teams Research, compare, and prepare Find the governing provisions, compare national rules, collect decisions, and prepare a sourced first pass for counsel review. See a multi-jurisdiction research run → Claims and legal protection Check a matter against the law Give a reviewing agent the matter facts, jurisdiction, and issue. Require it to support the legal steps with served sources or name what it could not establish. See a statutory document review → Research support, not legal advice Ansvar supplies source-linked research and decision support. It does not provide legal advice or decide legal applicability. Qualified counsel reviews the sources and takes the legal position. A separate job Keep question-led research distinct from publication monitoring. Legal research answers a scoped question with the sources available now. Regulatory intelligence watches enrolled publishers for new records and can start a later impact review. Legal research Start with an issue and jurisdiction Search the served legal record, review the sources, and preserve unresolved points. Check research coverage → Regulatory intelligence Start with a publisher and watch Track official publication records and prepare a cited impact review when something changes. See publication monitoring → Check the sources for your next legal question. Choose a jurisdiction and topic in the live coverage checker, then connect the AI your team already uses. Check legal coverage Compare plans --- ## Enterprise cyber and compliance assurance · Ansvar AI URL: https://ansvar.eu/solutions/enterprise-assurance Turn policies and system evidence into cited DORA, NIS2, GDPR and ISO assessments, with gaps, actions and unresolved evidence shown. Enterprise cyber and compliance assurance Turn policies and system evidence into a reviewable assessment. Run DORA and NIS2 gap analyses, GDPR DPIAs, and standards-grounded reviews in the AI environment your team uses. Ansvar cites the law and customer evidence behind each factual finding. The workflow marks unsupported conclusions unresolved. See a sample gap analysis Discuss your assessment EU-hosted gateway Bring your own model Document grounding on Team and Company The run A governed path from evidence to finding. The workflow enforces its required stages. Your team supplies the system facts, checks the evidence and owns the resulting decision. Scope the decision Name the system, jurisdictions, roles and requirement set that the review must cover. Register the evidence Team and Company can bind policies, architecture records and prior reports to the run. Run the assessment The server holds each required stage open until the response satisfies its field contract. Review the findings Inspect each citation, judgment and unresolved gap before your organization approves the result. Evidence Bring the sources behind the decision into one run. Ansvar serves source records through one citation contract. Public law, entitled standards and customer documents retain their own licence and trust boundaries. Law Primary and national requirements DORA, NIS2 and GDPR provisions arrive with publisher, source URL and lookup data. Your records Paragraph-cited customer evidence Registered documents support findings at paragraph level and keep their content hashes. Standards SIS-licensed clause evidence Selected ISO clause text enters the run only for a person or machine identity entitled to that standard. Read the licence model → Human judgment Named review decisions The report separates sourced facts from ratings, applicability calls and approvals. Work available now Start with the deliverable due next. The same gateway supports regulatory gap analysis and privacy assessment. Each workflow keeps its own stage contract and completed report. Shipped DORA and NIS2 gap analysis Assess the configured requirement set against a described system. Team and Company can ground the findings in uploaded policies and records. Review the workflow → Shipped GDPR DPIA Screen Article 35, describe the processing, assess necessity, score risks and record the Article 36 determination. Review the workflow → Shipped Gap analysis with entitled standards evidence Run a generic gap analysis against a configured requirement set. Licensed ISO text requires the matching SIS entitlement. See licensed standards → Decision boundary Ansvar supplies decision support. Your organization decides legal applicability, accepts risk and signs the final assessment. Ansvar issues no certificate or conformity declaration. Reuse today Register the same evidence for the next assessment. Completed workflows are immutable. A new run can use registered documents and a prior report as evidence, while keeping a separate history. One document library Team and Company keep policies, architecture records and reports available for registration in later workflows. Each run records the evidence it used. One new decision record Start a fresh run when the system or evidence changes. The new report does not overwrite the completed assessment that came before it. Put your next assessment on the evidence it needs. Bring the policies, system context and requirement set. Ansvar will show where the evidence supports a finding and where review remains open. Discuss your assessment Compare plans --- ## Product cybersecurity and regulated engineering · Ansvar AI URL: https://ansvar.eu/solutions/product-security Turn architecture evidence into a cited threat model or TARA, grounded in served security sources, product law and entitled standards. Product cybersecurity and regulated engineering Turn the architecture into a threat model or TARA your team can review. Describe the system in a guided run. Team and Company can also register architecture records as private evidence. Ansvar runs the structured workflow available on your plan, then grounds the report in served security sources, product law and standards evidence you hold a licence to use. See the threat-model workflow Discuss your product Public CVE, KEV and EPSS research on Free Structured STRIDE runs start on Free TARA starts on Premium Architecture documents on Team and Company The run Keep the architecture and the decision in the same review. The workflow asks for a system boundary before it scores a threat or risk. Your engineers confirm the model and challenge the proposed findings. Describe the system Provide components, assets, data flows, trust boundaries and operating context. Confirm the model Review the data-flow diagram or TARA scope before the server advances the run. Analyse and enrich The workflow applies its method and fetches the served sources needed for each mapping. Approve the register Engineers review threats, risk bands, treatments, citations and unresolved mappings. Served evidence Public security facts stay available for research. Free and Solo include structured runs from the starter workflow set. Premium adds the wider interview-grounded catalog and run-scoped effective-risk analysis in applicable workflows. Public vulnerability facts remain available on Free. Vulnerabilities CVE, KEV and EPSS Look up vulnerability details, known exploitation and exploit probability from the served feeds. Threat behavior ATT&CK and ATLAS Ground threat behavior in served technique records instead of model recollection. Enrichment CWE, CAPEC and D3FEND The source families used for weakness, attack-pattern and countermeasure enrichment, on every plan. Law and standards CRA, UN R155 and ISO/SAE 21434 Product-law provisions remain distinct from standards evidence. Selected ISO/SAE 21434 text requires a SIS entitlement for the person or machine identity. UN R156 IEC 62443 references NIST SP 800-30 Current ICS advisories Work available now Choose the decision the engineering review needs. Free and Solo return complete structured reports for the workflows included with those plans. Premium adds the wider interview-grounded catalog and unwatermarked exports. Team and Company add registered document evidence. Shipped STRIDE threat model Confirm the data-flow diagram, review the threat list, score the accepted threats and map mitigations to served controls and regimes. Review STRIDE → Shipped Threat Analysis and Risk Assessment Run the shared risk spine for automotive, OT, rail, robotics or UAS, with sector-specific anchors fetched from served sources. Review TARA → Shipped Vulnerability assessment and deferral Supply a scanner export. The workflow rescores the findings with KEV, EPSS and your context, then prepares a ranked plan or deferral record. Review vulnerability decisions → Engineering boundary Use Ansvar beside your engineering lifecycle and CSMS systems. Ansvar does not manage source code, product releases, SBOM generation, testing or type approval. Evidence contract Check each mapping or leave it open. A plausible security label does not establish a requirement. The report needs the served record behind the claim. Resolved evidence A reviewer can open the CVE, threat record, legal provision or entitled clause used by the workflow and compare it with the finding. Unresolved evidence If no served source supports a factual mapping, the workflow records the gap for engineering or legal review. It does not fill the citation from model memory. Bring one architecture and one decision to review. Start with a STRIDE threat model, a TARA or a vulnerability decision. Keep your model and engineering tools; add the evidence and workflow contract. Discuss your product Explore all workflows --- ## Canonical control library with reviewed mapping provenance · Ansvar AI URL: https://ansvar.eu/control-library Inspect a NIST 800-53 control spine, sourced framework links, typed relationship semantics, and the boundary between navigable links and reviewed coverage. Capability · Control library Reuse one control spine. State where the mappings stop. Ansvar uses NIST SP 800-53 Rev 5 as a canonical spine. Framework requirements attach as sourced links with provenance, and a link becomes a coverage claim only after its relationship has been reviewed and approved. Where an authored mapping does not exist, the library returns no result. The current coverage boundary is documented below. 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 in this August capture NIS2 · DORA · Cyber Resilience Act Already registered as resolvable, citable requirements — the same door every framework comes through. This was the state of the captured IR-4 example on 4 August 2026. It is not the current library inventory; use coverage or crosswalk for the reviewed mappings in the released library. 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 Inspect the reviewed mapping claims, their residual gaps, and the library release behind them. 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. Reviewed mappings are available. The current ISO 27001 Annex A layer includes approved individual mappings and composite assertions. A composite assertion records a reviewed claim about a set of controls together; inspect its basis and residual gaps rather than assuming any member control covers the requirement alone. Proposed mappings remain separate from the authoritative result. Ask coverage(detail="summary") for the released framework results and the library identity. For individual requirements, use detail="requirements" , choose a framework and edition, and follow page.next_offset . Read covered , covered_composite , partially_covered and unmapped as distinct categories. The coverage response is the current counting authority; the August example above remains a record of that session. Mapping coverage is not customer compliance. Your organisation must still decide applicability, implement controls and assess its evidence. Use a control scope repository to record those decisions. The library stores requirement pointers and reviewed mapping claims; licensed clause text remains subject to your source entitlements. 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? A zero means the selected framework or profile has no approved mapping claim that satisfies the coverage rule. Informative links and proposed edges do not count. Read covered, covered_composite, partially_covered and unmapped separately, with their residual gaps. Ask the coverage tool for the current released result; it does not assess your implementation. Which plan includes the control library? Team and Company. For authenticated Team and Company workspaces, the 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 --- ## Regulatory intelligence as a continuous-assurance trigger · Ansvar AI URL: https://ansvar.eu/regulatory-intelligence Monitor enrolled publications with cited records and source health, then prepare an evidence-backed impact review. Provision comparison remains planned. Regulatory intelligence Use each publication as a trigger for assurance work. Ansvar gives your agent typed publication records from enrolled official channels. Each response carries publisher facts, original URLs, dates, identifiers, licences, and the selected sources’ health state. Your agent can combine a candidate record with served law and company context to prepare a cited impact-review queue for a human decision. Connect your AI free Read the tool contract See the product direction Current capability Official-publication monitoring Ansvar reports newly published material from enrolled sources. It does not yet provide comprehensive, provision-level amendment comparison. Read the release note → Current product and product direction The trigger is live. Automated impact propagation is not. Today, the monitor supplies publisher records and coverage state; an agent can use other served evidence and the context you provide to prepare a review. Provision comparison, dossier-level impact location, and targeted reruns remain planned work. 01 Observe Available Read records from enrolled official publication channels. 02 Verify Available Retain publisher facts, licence, source URL, and source health. 03 Review Available Combine a candidate record with served law and company context in an agent-led review. 04 Compare Planned Identify provision-level changes against the previous legal text. 05 Locate Planned Find affected systems, controls, owners, and prior assessments in a persistent dossier. 06 Rerun Planned Start the relevant assessment work and present the cited delta for human approval. Watched sources Check the enrolled surface before you rely on silence. get_regulatory_intelligence_status is the authority for the current source list. It reports each publisher, channel, jurisdiction, enrolment baseline, last successful sync, and freshness state. The status tool is available on every plan. EU legislation Official Journal publication records New regulations, directives, decisions, delegated acts, implementing acts, and corrigenda. National legislation Licensing-cleared national gazettes The enrolled set changes only after source, rights, and acquisition checks pass. Regulators and agencies Commission, ENISA, EDPB, and enrolled channels Announcements and publisher metadata from the channels named in the live status response. Live gateway tool get_regulatory_intelligence_status() Field Why it matters publisher + channel Defines the official surface being watched. jurisdiction + baseline Bounds the claim an empty result can support. last successful sync Shows when the source last produced a valid ingest. freshness state Qualifies current, stale, critical, or never-synced sources. The public page does not copy a status snapshot into marketing prose. Ask the gateway for the current response when the conclusion matters. Publication record The source record comes first. Ansvar stores publisher facts and returns them without model-written summaries. Search finds a record; lookup by id returns that same record and citation. Fixture-backed example · Swedish Code of Statutes Serving source Elsystemförordning (2026:1522) Official identifier SFS 2026:1522 Publication date 23 July 2026 Publisher Riksdagen open data / Svensk författningssamling Licence SE-Statutory-PD Open the original publisher record ↗ This example comes from the parser fixture used to validate the enrolled Swedish source. Live responses also carry observation time, record id, lookup metadata, and the full citation envelope. Standing agent Let a standing agent prepare the morning review queue. Give the agent a service credential owned by your organization. It can check new official publications, shortlist records against the jurisdictions and regimes you provide, retrieve the available source material, and prepare candidate impact reviews with evidence attached. A human approves changes to controls, assessments, policies, or architecture. Read the service-credential guide 06:30 CET Regulatory publication review 1 Read live source status and stop on unavailable scope. 2 Search newly observed records inside the enrolled window. 3 Retrieve candidate records from the original publisher. 4 Compare candidates with supplied company regimes and ownership context. 5 Prepare a cited queue for human approval. Audit boundary An empty result needs a coverage statement. Ansvar reports whether the selected source was enrolled, inside its baseline window, and fresh enough to support the search. If every selected source is unavailable, the call fails instead of returning a clean empty list. Licence before ingest A signed source verdict clears the reuse terms before the monitor fetches the source. No model in the collection path The monitor stores publisher facts. It does not write a summary of the publication. Round-trip citation A search record can be fetched again by id with the same publisher, source URL, and licence. Explicit source health Freshness and baseline state travel with the response that supports the conclusion. Scope limit Publication monitoring tells you that a publisher released a record. It does not state how an existing provision changed, whether the instrument applies to your organization, or what control you should adopt. Your agent must retrieve the legal text and use company context before making those judgments. Put official publications in your review loop. Connect free to inspect live source status. Publication-record search starts on Premium. Connect your AI free Compare plans --- ## Regulated workflows for cited assessments · Ansvar AI URL: https://ansvar.eu/workflows Run gap analyses, DPIAs, threat models, TARAs, and other regulated assessments in your own AI client, with cited evidence and explicit unresolved points. Governed workflow execution Turn evidence into a reviewable decision. Ansvar workflows carry law, standards, security intelligence, and the context you provide through a defined assessment process. The result is a gap analysis, DPIA, threat model, TARA, or other finished artifact with cited facts, labelled judgments, and unresolved gaps. Connect your AI free Read a sample assessment Have us run and review it 51 workflow types in the served registry Cited factual anchors resolved from served evidence or left unresolved Your client run through a supported MCP client or standing agent one evidence contract Different assessments. The same chain of custody. Each run records the source material, selected customer evidence, structured stages, findings, judgments, and missing support behind the deliverable. Team and Company can bind documents from a tenant library to supported workflows. Completed reports remain immutable; a changed system or source starts a new run. 01 Bring the evidence Retrieve served law, licensed standards where entitled, threat sources, and the documents relevant to the run. 02 Run the method Server-enforced stages gather scope, evidence, analysis, review, and completion state in a defined order. 03 Keep the decision record Export a finished artifact with its citations, labelled judgments, unresolved points, and run metadata. choose the deliverable Run a supported workflow in your own client 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 DPIA — Data Protection Impact Assessment Ansvar screens one processing activity against GDPR Article 35 and the national trigger evidence available across 29 European jurisdictional source paths. 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. Catalog The full served catalog The families above have dedicated product pages. Other served workflows include LINDDUN privacy threat models, FRIA, SORA operational authorisation, document review, and adversary tabletops. Ask your client for list_workflow_types for the authoritative live list. evidence used inside and between runs Retrieve the record before making the judgment Capability Canonical control library A typed relationship model with provenance on each reviewed edge. The current coverage page states which mappings have actually been authored. Capability CVE intelligence & effective risk Retrieve public CVE, CISA KEV, and EPSS records on Free, which also includes one described-system workflow run a month. Premium adds the interview-grounded workflow catalog, and run-scoped effective-risk analysis in applicable workflows. Team adds standalone tools with persistent asset contexts, review decisions, and OpenVEX export. Capability Regulatory intelligence See what official publishers released, where, and when. Every record carries its source and the monitor reports the coverage window behind an empty result. 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. The same evidence discipline, with the assessment run and reviewed by practitioners under a scoped engagement. The services page has deliverables, process and samples; contact us to scope one. --- ## Gap analysis workflows — NIS2, DORA, CRA, AI Act, MDR/IVDR, machinery, drones · Ansvar AI URL: https://ansvar.eu/workflows/gap-analysis Assess NIS2, DORA, CRA, AI Act, MDR/IVDR, machinery or drone compliance requirement by requirement, 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 with its contract and register duties, AML Regulation and MiCA readiness, 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. NIS2 Poland (ustawa o KSC, Dz.U. 2018 poz. 1560; t.j. Dz.U. 2026 poz. 20, zm. Dz.U. 2026 poz. 252) Polish national NIS2 assessment; currently admitted on Team and Company. DORA (Regulation (EU) 2022/2554) ICT risk-management duties for financial entities. DORA ICT contracts and subcontracting ICT contracts and subcontracting under DORA Articles 28–30; currently admitted on Team and Company. DORA register of information The register of information under DORA Article 28(3); currently admitted on Team and Company. AMLR readiness — Regulation (EU) 2024/1624 Readiness for the AML Regulation, whose selected requirements apply from 10 July 2027. MiCA CASP readiness — Regulation (EU) 2023/1114 Readiness for crypto-asset service providers under MiCA Title V. 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 Obligations by role — provider, deployer, importer or distributor. Medical Device Regulation (Regulation (EU) 2017/745) General safety and performance requirements for medical devices. In Vitro Diagnostic Regulation (Regulation (EU) 2017/746) The same discipline for in-vitro diagnostic devices. 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) Operational rules for UAS operators under 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? install the skill A prompt starts one run. The skill is the same guidance installed once — the run loop, the evidence and citation rules, and the starters — so your agent works this way in every conversation, not only the ones you remember to paste into. Install it as a skill in Claude or Claude Code, or paste the same file into Microsoft Copilot or a custom GPT's instructions. Regulatory Gap Analysis · version 1.4.0 · SKILL.md · ZIP · how to install it 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 Dutch NIS2, medical-device, R155, machinery and drone variants on five runs a month, with unwatermarked HTML, PDF and DOCX exports. The Polish NIS2 variant currently starts at Team. Team and Company run them against your own uploaded documents. 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. The Polish NIS2 variant starts at Team. 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: Premium, 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 --- ## Jurisdiction-aware DPIA software for Europe · Ansvar AI URL: https://ansvar.eu/workflows/dpia Screen one processing activity against GDPR Article 35 and 29 European jurisdictional evidence paths. Official citations and human DPO review. Workflow · DPIA Your DPIA should know which country it is in. Ansvar screens one processing activity against GDPR Article 35 and the national trigger evidence available across 29 European jurisdictional source paths. Each surfaced trigger carries its official publisher, source status, citation, and verification context. The agent prepares the evidence record. Your DPO reviews applicability, necessity, proportionality, residual risk, and sign-off. Screen a processing activity Explore jurisdiction coverage 29 jurisdictions queried by name · 3 sources recorded unavailable · no model-memory citations Jurisdiction source receipt source status Germany · authority-published trigger list ✓ Published list Estonia · authority guidance ✓ Indicative Cyprus · authority material ✓ Advisory draft Switzerland · Articles 22–23 screen ✓ No national-list mechanism 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. 29 jurisdictions whose own national source the run queries by name Article 36 a prior-consultation determination, with its basis recorded Human controller and DPO judgment retained 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 — the Article 35(3) cases plus the supervisory authority's own mandatory list, fetched in the authority's own language for each jurisdiction confirmed in scoping. A source is cited, or the screen records it as unretrieved and marks the basis unresolved; it is never reproduced from model memory. Then the run 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 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, screening against the national trigger sources for the jurisdictions confirmed in scoping. 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. Having a source and querying it are separate states, and the coverage receipt publishes both. Today they coincide: all 29 operational jurisdictional source paths are named with their own native-language query in the deployed screening prompt. 3 further sources are identified but not reproduced — the run records them unavailable and never rebuilds them from model memory. GDPR Article 35 is shared. National trigger material is not. The same processing activity can meet a published criterion in one jurisdiction, appear in indicative authority guidance in another, and require a statutory high-risk screen where no national-list mechanism exists. national routing National evidence routed from the jurisdictions you confirm. 01 Confirm scope The user or DPO names the jurisdictions to assess. Ansvar does not make an unqualified territorial-applicability decision. 02 Apply Article 35 The general high-risk threshold and the express Article 35(3) cases form the common baseline. 03 Route national evidence The screen retrieves the available list, guidance, draft, or statutory regime and records which source was checked. 04 Keep the source state A source is cited, classified as unavailable, or left unresolved. Generic guidance is not substituted without disclosure. Read the public DPIA trigger-source receipt for the authority, source status, verification date, workflow state, and known limitation in each jurisdiction. how a run works Five stages the server enforces 1 Screening & scope whether Article 35 bites — the Article 35(3) cases plus the authority's own mandatory list, fetched per confirmed jurisdiction — then 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. Confirm the relevant jurisdictions with me, screen the applicable national trigger sources, then continue to the prior-consultation determination. Using Ansvar, show the DPIA trigger-source coverage for Germany, Estonia, Cyprus, Switzerland, and the United Kingdom. Preserve each source's status and do not decide territorial applicability for me. install the skill A prompt starts one run. The skill is the same guidance installed once — the run loop, the evidence and citation rules, and the starters — so your agent works this way in every conversation, not only the ones you remember to paste into. Install it as a skill in Claude or Claude Code, or paste the same file into Microsoft Copilot or a custom GPT's instructions. Impact Assessments — DPIA and FRIA · version 1.2.0 · SKILL.md · ZIP · how to install it 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, with unwatermarked HTML, PDF and DOCX exports. Team and Company run them against records you upload. Run allowances and what each tier adds live on the pricing page . jurisdiction receipt The screen produces a reviewable source record. Every jurisdiction checked keeps the facts used, the criterion tested, the source status, and the reviewer decision. That turns national-list coverage into a record another person can inspect. Receipt field Example record shape Jurisdiction Estonia Supervisory authority Andmekaitse Inspektsioon Source type National DPIA trigger material Legal status indicative authority material Source version Publication or retrieved version Matched criterion Exact criterion identifier, or none Supporting facts Supplied facts or customer-document evidence Citation aki.ee Verification date 2026-08-15 Result Match, no match, or unresolved Reviewer decision Pending, accepted, or overridden with rationale human boundary The machine assembles the file. A human owns the judgment. Ansvar can identify relevant source material, test documented processing facts against recorded criteria, assemble the risk register, and validate citations. It does not decide whether the processing is necessary or proportionate, accept residual risk for the controller, replace the DPO, or issue a compliance approval. 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. Which national lists does a run actually query today? All 29 operational jurisdictions across the EU, the EEA, Switzerland and the United Kingdom — each named in the deployed screening prompt with a query in the authority's own language, because an English meta-query misses lists published in Greek, Lithuanian or Icelandic. Luxembourg, Malta and Slovakia are identified but not reproduced. The coverage receipt records the state of every jurisdiction against the deployed workflow bundle, so any gap is published rather than implied. 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 memory. A negative screening outcome is never grounded on a list that was not actually retrieved. 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 · DPIA trigger coverage · 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. AI / ML System Threat Model (STRIDE + ATLAS) AI/ML systems, with STRIDE threats and MITRE ATLAS enrichment. 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, ATLAS, CWE, CAPEC and D3FEND are served on every plan. 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. install the skill A prompt starts one run. The skill is the same guidance installed once — the run loop, the evidence and citation rules, and the starters — so your agent works this way in every conversation, not only the ones you remember to paste into. Install it as a skill in Claude or Claude Code, or paste the same file into Microsoft Copilot or a custom GPT's instructions. Threat Modelling · version 1.6.0 · SKILL.md · ZIP · how to install it 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 AI/ML, OT/ICS and drone variants on five runs a month, along with unwatermarked HTML, PDF and DOCX exports. Team and Company run them against your own architecture documents 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 AI/ML, OT/ICS and drone variants start at Premium. 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: Premium, 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 --- ## 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. Financial regulation research, plan access and agent prompts 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 EU regimes, article-level 11 DORA technical standards EU · US national rulebooks · 12 & 17 CFR 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. Under the EU layer sit the national regulators' rulebooks for every EU-27 member state plus EFTA and the UK, and the ECB's own legal acts and Banking Supervision material; across the Atlantic, US federal banking (12 CFR) and securities (17 CFR) regulation is served from the eCFR. 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 Law National financial rulebooks — EU-27, EFTA and the UK the national regulators' rulebooks under the EU layer, attributed per provision to the state that issued them (Sweden's Finansinspektionen FFFS among them) Regulation European Central Bank — legal acts, opinions and Banking Supervision material ECB legal acts in force and opinions on draft EU and national legislation, plus the English-language ECB and Banking Supervision guides, consultations, supervisory sanctions and cyber-resilience and payments-oversight material Guidance EIOPA insurance and Solvency II material published by the European Insurance and Occupational Pensions Authority under its reuse notice Regulation US federal financial regulation — 12 CFR banking · 17 CFR SEC served verbatim from the eCFR, incl. the Regulation S-K cyber-disclosure rules Guidance Premium US agency guidance — SEC cyber-disclosure interpretations · FTC data-security guidance the SEC staff C&DIs on Form 8-K Item 1.05 and Regulation S-K Item 106, and the FTC business guidance on GLBA Safeguards, the Red Flags Rule and breach notification Regulation Horizontal: GDPR · NIS2 · EU AI Act · eIDAS2 Standard NIST SP 800-53r5 — served as full text the US federal control catalog itself, cited per control; US public domain Standard Control mapping: ISO 27001 Annex A requirement mapping + cross-references — the ISO 27001 text itself is available only 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, unwatermarked HTML, PDF and DOCX 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. Is this EU-only? No. Under the EU layer, the national regulators' rulebooks for every EU-27 member state plus EFTA and the UK are served with each provision attributed to the state that issued it, and the ECB's legal acts and Banking Supervision material sit beside them. For the US, federal banking regulation (12 CFR) and securities regulation (17 CFR, including the Regulation S-K cyber-disclosure rules) come verbatim from the eCFR, with the SEC staff cyber-disclosure interpretations and the FTC data-security guidance on Premium and above. 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) Germany · authority-published trigger list ✓ DSK Muss-Liste v1.1 Residual high risk — consult the regulator ✓ GDPR Art. 36(1) See a real run: DPIA for a new HR vendor Read the full sample deliverable: Sample DPIA 29 DPIA jurisdiction evidence paths 99 GDPR articles, addressable 18 US state privacy statutes Privacy work starts with the GDPR article and keeps the national source in view. The DPIA screen routes from confirmed jurisdiction scope to the available authority trigger material, then carries the assessment through necessity, proportionality, risks, safeguards, and Article 36. Reach goes past the EU: the comprehensive consumer-privacy statutes of 18 US states are served verbatim from each legislature's own portal, US federal privacy and data-security regulation sits alongside them, and Ontario's FIPPA and PHIPA come with the Canadian provincial corpora. Every factual finding is cited or left unresolved. 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 Law US state comprehensive privacy statutes — 18 states verbatim statutory text from each state legislature's own portal, incl. CCPA/CPRA, VCDPA, UCPA, TDPSA, MCDPA and the Colorado Privacy Act Regulation US federal privacy and data-security regulation the federal code as published by govinfo Law Canadian provincial law — Ontario and British Columbia Ontario's FIPPA and PHIPA sit inside the consolidated Ontario statutes and regulations from the King's Printer, in both official languages, with British Columbia beside it; Canadian federal law is a separate corpus on Premium and above Guidance LINDDUN privacy threat & design-pattern library 35 privacy threats, 30 design patterns and 16 privacy-enhancing technologies, linked by mitigation relationships and cross-referenced to the GDPR 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 Article 35 with jurisdiction-aware national screening screen the GDPR baseline and the national trigger evidence available across 29 operational jurisdictional source paths, 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 across the EU national statutes and the 18 US state privacy laws, 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, unwatermarked HTML, PDF and DOCX 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. Outside the EU, the comprehensive consumer-privacy statutes of 18 US states are served verbatim — California, Virginia, Utah, Texas, Montana, Colorado, Connecticut, Delaware, Iowa, New Hampshire, Kentucky, Maryland, Minnesota, New Jersey, Rhode Island, Nebraska, Tennessee and Oregon — alongside US federal privacy and data-security regulation. 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). For teams governing AI against a framework rather than a statute, the NIST AI Risk Management Framework and its Generative AI Profile are served as full text beside the Act. 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 NIST AI Risk Management Framework (AI 100-1) + Generative AI Profile — served as full text the Govern / Map / Measure / Manage Core and the GenAI profile themselves, not a mapping; US public domain 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, unwatermarked HTML, PDF and DOCX 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 FAR · 2 CFR US procurement + Uniform Guidance 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. The US federal layer is served too: the Federal Acquisition Regulation and the OMB Uniform Guidance that governs every federal grant recipient, plus the education, housing, emergency-management and immigration codes. For Dutch public bodies the BIO2 government security baseline is served verbatim from its Staatscourant publication. 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 US federal procurement — the Federal Acquisition Regulation (48 CFR) served verbatim from the eCFR, with the OMB Uniform Guidance (2 CFR Part 200) that governs cost principles, audit and administration for every federal grant recipient Regulation US federal public-administration regulation education (34 CFR — FERPA, Title IX, Section 504, IDEA), housing (24 CFR — HUD), emergency management (44 CFR — FEMA) and immigration (8 CFR — incl. I-9 / E-Verify), each served verbatim from the eCFR Standard Dutch government security baseline — BIO2 v1.3 served verbatim from its Staatscourant publication: the BIO2-kader and every Deel 2 measure, keyed to its ISO/IEC 27002:2022 control number and marked Cbw-verplicht or outside Cbw scope Law Dutch public-body statute — building code, civil protection and law enforcement the national building-code rules, the emergency-preparedness stack (IJenV, NCTV) and the police layer (Politiewet, Wpg, BOA, OM aanwijzingen) 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 and, for Dutch bodies, the BIO2 measures at their ISO/IEC 27002 control numbers 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, unwatermarked HTML, PDF and DOCX 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? For the tender review and audit workflows, yes — that depth, with case law and preparatory works, is built for Sweden and the Netherlands today. The corpus itself reaches further: procurement statute is searchable across the audited jurisdictions, the US Federal Acquisition Regulation and the OMB Uniform Guidance are served from the eCFR, and Dutch public bodies also get the BIO2 security baseline, the building code, the civil-protection stack and the police layer at provision level. 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 FDA · CMS US federal health regulation 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. Beyond the EU, US federal health regulation from the FDA and CMS comes verbatim from the eCFR, and device regulation for seven more jurisdictions — Great Britain, Canada, Switzerland, South Korea, Japan, Australia and Colombia — is attributed per provision. The device software, safety-risk and security standards are a clause map on top. 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 US federal health regulation — FDA (21 CFR) and CMS (42 CFR) served verbatim from the eCFR Regulation National medical-device regulation outside the EU — GB, CA, CH, KR, JP, AU, CO device-regulation text attributed per provision to the jurisdiction that issued it Standard Control mapping: medical-device software, safety and security standards 97 clauses across IEC 62304, IEC 81001-5-1, ANSI/AAMI SW96 and AAMI TIR57, ISO 14971, IEC 60601-1 (incl. clause 14 PEMS), IEC 82304-1 and the surgical- and rehabilitation-robot parts IEC 80601-2-77/-78 — clause map + Ansvar cross-refs, not the standard text Regulation Horizontal: NIS2 · EU AI Act (software as a medical device) · CRA Guidance Premium MDCG medical-device guidance Guidance Premium US FDA guidance documents 48 final guidances on medical-device, drug and biologics regulation, served verbatim Guidance Premium Dutch statutory disciplinary-tribunal rulings 48,205 full-text decisions from 2001 onward — the regional healthcare colleges and the Centraal Tuchtcollege alongside the advocatuur, notariaat, accountancy, veterinary and maritime tribunals 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 assembled Premium Device software & security standards research as cited answers the IEC 62304 / 81001-5-1 / ISO 14971 clause map and the FDA guidance layer, every answer cited to its source 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, unwatermarked HTML, PDF and DOCX 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, US federal health regulation from the FDA (21 CFR) and CMS (42 CFR) is served verbatim, with the FDA final guidances on Premium and above, and dedicated device-regulation text covers Great Britain, Canada, Switzerland, South Korea, Japan, Australia and Colombia. 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. 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 ENISA · ANSSI · NCSC OT guidance, served verbatim 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. What the agencies publish, we serve as text: the ENISA ICS-SCADA good practices, the ANSSI industrial-system guides, the UK NCSC operational-technology guidance, the NIST SP 800-82r3 OT overlay and the DOE C2M2 maturity model. 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 Standard NIST SP 800-82r3 — the OT overlay the Appendix F control-tailoring layer served verbatim: per-control OT applicability, compensating controls and parameter tailoring; the prose guide chapters are not in the corpus Standard DOE C2M2 v2.1 356 maturity practices across ten domains, each tagged MIL1-MIL3, served verbatim Regulation EU Machinery Regulation (EU) 2023/1230 article-level (applies 2027-01-20) Regulation Cyber Resilience Act · NIS2 Guidance ENISA OT / ICS-SCADA good practices served verbatim under the ENISA reuse notice — smart-manufacturing IoT security, ICS/SCADA communication dependencies, maturity levels in critical sectors and the secure IoT supply chain Guidance ANSSI industrial-system security guides served verbatim under Etalab v2.0 — the classification method (PA-107), the detailed measures (PA-108), the detection doctrine (PA-084) and the industrial-IoT approach (PG-109) Guidance UK NCSC operational-technology guidance served verbatim under OGL v3.0 — secure connectivity principles, the definitive OT architecture view, cloud-hosted SCADA, secure RF communications and privileged access workstations 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 assembled Team C2M2 maturity-scored OT gap analysis the DOE C2M2 practices at MIL1-MIL3 over your OT programme — assembled from the served practice text and the gap-analysis workflow Premium 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, unwatermarked HTML, PDF and DOCX 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 EU · US national statute + FERC / NRC C2M2 356 maturity practices, MIL1-MIL3 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 and the national regulators' decisions, grid codes and network regulations for seven of them. US federal energy regulation is served too: FERC (18 CFR) and the NRC nuclear rules (10 CFR). The DOE C2M2 maturity model and the CISA cross-sector performance goals give the programme a scored spine. 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 National energy-regulator decisions, grid codes and network regulations GB, DE, NO, SE, FI, DK and NL, attributed per row to the regulator that issued them Regulation US federal energy regulation — FERC (18 CFR) and the NRC nuclear rules (10 CFR) served verbatim from the eCFR Law Dutch radiation-protection and nuclear-safety regulation (ANVS) 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 Standard DOE C2M2 v2.1 356 maturity practices across ten domains, each tagged MIL1-MIL3, served verbatim — the de-facto energy-sector maturity model Standard CISA Cross-Sector Cybersecurity Performance Goals v2.0 the baseline critical-infrastructure control spine, water and wastewater included, crosswalked to NIST CSF 2.0 / 800-53 / 800-82r3 — served verbatim 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 assembled Team C2M2 maturity-scored gap analysis the DOE C2M2 practices at MIL1-MIL3 over your OT programme, with the CISA performance goals as the cross-sector baseline — assembled from the served practice text and the gap-analysis workflow 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, unwatermarked HTML, PDF and DOCX 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. Since 2026 the regulators' own decisions, grid codes and network regulations are served as a second layer for GB, DE, NO, SE, FI, DK and NL, and US federal energy regulation covers FERC (18 CFR) and the NRC nuclear rules (10 CFR). 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 11 automotive scopes, type-approval to circularity TARA ISO 21434 clause map + threat analysis Vehicle law and vehicle cybersecurity in one lane. UN R155 and R156 are addressable provision by provision, and the EU type-approval estate sits beside them: the type-approval and vehicle-safety acts, emissions and environment, L-category vehicles, agricultural and forestry tractors, in-service and road use, circularity and materials, in-vehicle data access, repair and maintenance information, and the UN ECE regulations as published in the Official Journal. ISO/SAE 21434 and the diagnostic standards are clause maps with Ansvar cross-references rather than the standard text; 21434 is one of the standards you can licence in through the SIS module when you want it cited verbatim. 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 Regulation EU vehicle type-approval & safety the type-approval framework and the vehicle-safety acts, article-level from EUR-Lex Regulation EU automotive emissions & environment article-level from EUR-Lex Regulation EU L-category and agricultural / forestry tractor type-approval the two type-approval regimes outside the M/N vehicle classes Regulation EU automotive in-service & road use · circularity & materials roadworthiness and in-use duties, and the end-of-life, recyclability and materials rules Regulation UN ECE vehicle regulations the UN regulations as published in the EU Official Journal, alongside R155 and R156 Regulation In-vehicle data access for connected vehicles the EU rules on access to vehicle-generated data Regulation Repair & maintenance information access — RMI / SERMI Reg (EU) 2018/858 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: automotive engineering & diagnostics stack 33 standards and 703 clause entries — UDS (ISO 14229), DoIP, SOVD, AUTOSAR diagnostics, ISO 15765-2, LIN (ISO 17987), ISO 22737 low-speed automated driving and ISO 27145 WWH-OBD — clause mapping, not the standard text Law Chinese national law national laws of the NPC and its Standing Committee, legislative decisions and State Council administrative regulations from flk.npc.gov.cn, in Chinese original with Ansvar-authored English metadata. Local regulations, judicial interpretations and departmental rules are not yet served. GB/GB-T standard body text is excluded; this listing does not establish Chinese market approval or equivalence with ISO standards. 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 assembled Premium Vehicle-law research as cited answers type-approval, emissions, in-service, circularity, data access and the UN regulations, every answer cited to the provision 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, unwatermarked HTML, PDF and DOCX 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, eleven national UAS rulebooks and the US federal aviation code beside it, an Ansvar-authored UAS threat library and SORA determination chain, 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 Guidance SORA determination chain — Reg (EU) 2019/947 Art. 11 Ansvar-authored: the intrinsic ground-risk class with its M1/M2 mitigations, the air-risk class and TMPR, the SAIL matrix, the SORA 2.5 operational safety objectives and the tiered containment requirements Standard Control mapping: UAS standards stack clause map across product conformity (EN 4709-x direct Remote ID and geo-awareness), Remote ID & UTM (ASTM F3411/F3548, ED-269/270/318), operations (ISO 21384-3, ISO 23629-x) and airworthiness security (DO-326A/356A/355 and the ED-202A/203A/204A equivalents) + Ansvar cross-refs — not the standard text; standards can be licensed in via the SIS add-on (/standards) Law National UAS rulebooks — BE, DE, ES, GB, HU, IS, LT, LU, LV, NL and SE provision-level, alongside the EU regulations Regulation US federal aviation regulation (FAA) + 14 CFR Part 107 the FAA code served verbatim from the eCFR, with the US small-UAS rules addressable beside it 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) Premium 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, unwatermarked HTML, PDF and DOCX 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 800-53r5 NIST catalogs served as full text 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, with US federal cybersecurity regulation from the eCFR beside them; the NIST publications served as full text — 800-53r5, CSF 2.0, SSDF 800-218 and the AI RMF — while ISO 27001 Annex A, CIS and the German BSI landscape stay control mappings; 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 Regulation US federal cybersecurity regulation the federal cyber code, served verbatim from the eCFR Standard NIST SP 800-53r5 · CSF 2.0 · SSDF 800-218 · AI RMF — served as full text the control catalog, the CSF Core, the secure-development framework and the AI risk framework themselves, not a mapping; US public domain Standard Control mapping: OWASP ASVS · ISO 27001 Annex A · CIS requirement mapping + cross-references, not the standard text — the ISO 27001 text itself is the SIS-licensed add-on (/standards) Standard Control mapping: BSI IT-Grundschutz · C5 · Technische Richtlinien · KRITIS · Mindeststandards the German control landscape as a clause map with cross-references into ISO/IEC 27001 — not the standard text Standard MITRE ATT&CK · CAPEC · CWE · D3FEND threat & weakness catalogs, cited per technique, on every plan Guidance ENISA Threat Landscape the EU annual threat report plus the transport and finance-sector landscapes, served verbatim (CC-BY-4.0) Guidance Software supply-chain security · cryptographic algorithm guidance supply-chain attack patterns, SBOM field references (SPDX, CycloneDX) and Sigstore signing; algorithm status per NIST, ENISA, BSI TR-02102-1 and SOG-IS, with the post-quantum replacements 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, MITRE catalogs included; premium adds 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, unwatermarked HTML, PDF and DOCX 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. Are the NIST publications mapped, or served? Served. NIST SP 800-53r5, the CSF 2.0 Core, SSDF 800-218 and the AI RMF are US federal public-domain publications, so the text is in the corpus and an answer cites the control, practice or subcategory itself. ISO 27001 is the other case: the Annex A mapping cross-references it without reproducing it, and the standard text arrives only through the SIS-licensed add-on. 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 EU · US Machinery Reg + USDA federal rules 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 rather than the standard text, which any ISO, EN or SS standard SIS publishes can be licensed in for through the standards module. Farm-data governance under the Data Act and deforestation-free supply-chain duties under the EUDR complete the EU picture, and US federal agriculture and food regulation from the USDA is served verbatim from the eCFR. 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 US federal agriculture & food regulation (USDA) served verbatim from the eCFR Standard EU machinery harmonised-standards index which standard confers presumption of conformity for a machine, by OJ citation, Type-A/B/C role and cessation date — an index over the standards, not their text Regulation Horizontal: Cyber Resilience Act · GDPR connected-machinery product security and operator data what you can do Workflows that turn it into evidence Premium 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, unwatermarked HTML, PDF and DOCX 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 EU · US Machinery Reg + OSHA / NIOSH 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. Mobile and service robots have their own clause map (ISO 3691-4, ANSI/A3 R15.08, ISO 13482), and the harmonised-standards index tells you which standard confers presumption of conformity and until when. 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, with the US occupational layer — OSHA and NIOSH robot-safety material — served verbatim beside it. 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 140 robot and robot-system safety requirements as a clause map + Ansvar cross-refs — not the standard text Standard Control mapping: mobile & service robot safety (ISO 3691-4 · ANSI/A3 R15.08 · ISO 13482) driverless industrial trucks, industrial mobile robots and personal-care robots — personnel detection, operating zones, speed and stopping distance, manipulator-while-moving — clause map, not the standard text Standard Control mapping: functional safety (ISO 12100 · ISO 13849 · IEC 61508 · IEC 62061) + IEC 62443 industrial cyber requirement mapping incl. the SIL determination route and the safety-security bridge (IEC TS 63074 · IEC TR 63069 · ISO/TR 22100-4) — not the standard text Standard EU machinery harmonised-standards index which standard confers presumption of conformity, by OJ citation, Type-A/B/C role and cessation date — an index over the standards, not their text Guidance ROS 2 / DDS security + robot exploitation chains served full-text (Apache-2.0) — robot-stack hardening and attack techniques, cited per item Guidance US robot-safety authority material — OSHA and NIOSH served verbatim, US public domain — the OSHA Technical Manual chapter on industrial robot systems and the robotics topic pages, plus NIOSH occupational-robotics material and its in-house robot fatality investigations Law Chinese national law national laws of the NPC and its Standing Committee, legislative decisions and State Council administrative regulations from flk.npc.gov.cn, in Chinese original with Ansvar-authored English metadata. Local regulations, judicial interpretations and departmental rules are not yet served. GB/GB-T standard body text is excluded; this listing does not establish Chinese market approval or equivalence with ISO standards. 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, mobile-robot and safety-security-bridge clause maps — an available analysis, not a legally-assured verdict Premium EU Machinery Regulation gap analysis Annex III essential-H&S coverage incl. the conformity route and the harmonised standards that carry presumption of conformity — 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, unwatermarked HTML, PDF and DOCX 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 EU · US NIS2 / CER + the US federal rail rules 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; US federal transportation regulation, which carries the rail and dangerous-goods rules, is served verbatim from the eCFR. 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 US federal transportation regulation the road-transport, rail and dangerous-goods rules, served verbatim from the eCFR 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, unwatermarked HTML, PDF and DOCX 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. --- ## SIS-licensed ISO evidence for AI-assisted assessments · Ansvar AI URL: https://ansvar.eu/standards Bring selected SIS-licensed clauses from ISO/IEC 27001, 27002, 27005, 42001 and ISO/SAE 21434 into supported AI-assisted assessments with source attribution. ISO security standards · Licensed from SIS Put SIS-licensed ISO clauses inside the assessment. Ansvar is an official SIS distributor, so any ISO, European or Swedish standard SIS publishes can be licensed onto your seats and read clause by clause — the text delivered to your entitled AI client and attributed to the source standard, so it can support a cited finding. Live today: the 27001/27002/27005 information-security family, 42001 for AI management and ISO/SAE 21434 for road vehicles. Ask for any other and it is added once licensing and verification clear. 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. Those clauses can become traceable evidence inside a supported assessment. Selected parts only — the complete standards are not reproduced here. Buy the full text from SIS at sis.se . The entitlement applies to the person or machine identity using the service. The selected text is delivered to the third-party AI client your team already uses and remains subject to the add-on terms. How it works Put licensed clauses inside the evidence chain A supported assessment can retrieve the selected clause it needs, attribute it to SIS, and cite it beside law and customer evidence. The complete standard remains a separate SIS product. 01 Resolve the relevant clause Each licensed standard is held as addressable clause- and control-level segments. A supported workflow can request the specific segment needed for an assessment. 02 Use the licensed text as evidence The gateway returns selected source text in the same citation shape used for law and other served evidence. The assessment can reason from the clause instead of relying on model memory. 03 Carry attribution into the result Every response carries the SIS attribution and exact product designation. A cited finding can be traced to the source standard, with a link to buy the complete text from SIS. The citation envelope delivered to your connected AI client. Licensed control text is 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 Licensed standards available now The current set covers information security, AI management systems, and road-vehicle cybersecurity. Ask about another SIS-published standard; it must clear licensing and verification before it is served. 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. The standards listed above are live today. You can request another ISO, European, or Swedish standard SIS publishes. Each request must clear licensing and verification before Ansvar exposes it. Tell us which standard → Worked examples What a workspace costs, worked out Four ways a team combines a plan with the standards its work cites. Team is priced per seat, and a seat is a person or an agent; the standards sit on one named seat and are priced on the ladder, so a second standard costs less than the first. Totals are list prices a month, billed monthly. Information security assurance workspace Team seat €490 SS-EN ISO/IEC 27001:2023 SS-EN ISO/IEC 27002:2022 SS-EN ISO/IEC 27005:2024 3 standards on one named seat, ladder price €219 €709 a month Gap analysis and audit-readiness reviews on your own policies, with the clause and control text behind each finding. AI governance workspace Team seat €490 SS-EN ISO/IEC 42001:2026 SS-EN ISO/IEC 27001:2023 2 standards on one named seat, ladder price €179 €669 a month AI Act readiness and AI management system work, grounded on your own documents and cited to the clause. Automotive cybersecurity workspace Team seat €490 SS-ISO/SAE 21434:2021 on one named standards seat €99 €589 a month TARA and type-approval work on your own system documentation, citing the engineering requirements directly. Complete security standards set Team seat €490 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 5 standards on one named seat, ladder price €249 €739 a month Every listed standard on one seat: security management, controls, risk, AI management and road-vehicle cybersecurity. A standards seat can sit on any plan, Free included. A Premium seat with SS-EN ISO/IEC 27001:2023 comes to €348 a month; a Free seat holding one standard pays only the €99 add-on. There is no set-up fee: every standards seat, the first one included, is the monthly ladder alone. What's served, and what isn't The entitlement has a clear boundary The licence permits Ansvar to serve selected parts used in the work. It does not transfer the complete standard or redistribution rights. 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 Available as cited evidence inside supported assessments 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 Give your agent rules for using licensed standards The open agent skill instructs a compatible assistant to fetch entitled clauses, include the SIS notice, disclose unevaluated scope, and avoid answering 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. Subscribe per seat from your account area , or 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. --- ## 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 full sample DPIA for a fictional workplace-wellness app: Article 35 screening, risk register, Article 36 decision, and a five-jurisdiction source receipt. 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 1A Jurisdiction screening receipt One processing operation. Five jurisdictional evidence paths. This source-routing addendum shows how the same fictional activity reaches different national material. It does not decide that all five jurisdictions apply, and it does not claim that the original July sample run fetched them. A controller or DPO must confirm territorial scope before criterion matching begins. Jurisdiction National source retrieved by the current evidence layer Legal status preserved Result in this published sample Germany DSK Muss-Liste under Article 35(4), version 1.1 Datenschutzkonferenz · verified 2026-08-13 published national material Source path verified; criterion match not rerun for this sample Estonia Isikuandmete töötleja üldjuhend, chapter 5 Andmekaitse Inspektsioon · verified 2026-08-15 indicative authority material Source path verified; criterion match not rerun for this sample Cyprus Indicative DPIA list submitted under Article 35(4) Commissioner for Personal Data Protection · verified 2026-08-15 advisory draft Source path verified; criterion match not rerun for this sample Switzerland Federal Act on Data Protection, Articles 22 and 23 Federal Data Protection and Information Commissioner · verified 2026-08-16 statutory no-list determination Source path verified; criterion match not rerun for this sample United Kingdom Examples of processing likely to result in high risk Information Commissioner's Office · verified 2026-08-14 published national material Source path verified; criterion match not rerun for this sample No legal outcome is inferred from source availability. See the DPIA trigger coverage receipt for the workflow state and known limitation recorded for every jurisdiction in the program. 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 July run, so the historical assessment left that check open. IMY's DI-2018-13200 list entered the served evidence layer on 13 August 2026. The addendum in §1A records that change without rewriting the original run history. 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; a fresh screen against the confirmed national trigger sources; 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. Want a completed assessment? Run the cited NIS2 gap analysis workflow in your AI client, or have a practitioner run and review it . 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, entered 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. The NIS2 gap analysis workflow runs the cited assessment in your AI client, 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, entered 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 --- ## GDPR explained: scope, lawful bases, rights, breaches, fines — with citations · Ansvar AI URL: https://ansvar.eu/regulations/gdpr What the GDPR requires — scope, lawful bases, data subject rights, the risk-gated 72-hour breach duty, DPIAs, transfers and fines — each claim cited. GDPR The GDPR, explained for the teams who build with personal data . The GDPR — Regulation (EU) 2016/679 — is the EU's data protection law, applicable since 25 May 2018 and binding in its entirety in every Member State. It decides when you may process personal data at all, what the people in the data can demand from you, what you must have in place before something goes wrong, and what it costs when it does. Run a GDPR gap analysis — free Read the regulation Applicability Who is in scope Two scope dimensions — what the processing is, and where you or the people are — and the controller and processor roles that carry the duties. The material test first. Article 2(1) applies the Regulation to processing of personal data wholly or partly by automated means, and to manual processing which forms part of a filing system or is intended to. The named exclusions are short: activities outside the scope of Union law, activities within the scope of Chapter 2 of Title V of the TEU, processing by a natural person in the course of a purely personal or household activity, and processing by competent authorities for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security. Then the territorial test. Article 3(1) covers processing in the context of the activities of an establishment of a controller or processor in the Union — wherever the processing itself takes place. Article 3(2) reaches controllers and processors with no Union establishment at all, where the processing relates to offering goods or services to data subjects who are in the Union, whether or not payment is required, or to monitoring their behaviour as far as it takes place within the Union. The wording matters: the trigger is people in the Union, not citizenship or residence paperwork. Article 3(3) adds a third route — a controller not established in the Union but in a place where Member State law applies by virtue of public international law. Either scope dimension alone is not enough: the processing must sit inside Article 2 and reach through one of the Article 3 routes. The duties attach to roles that Article 4 defines. Personal data is any information relating to an identified or identifiable natural person — identifiable directly or indirectly, including by reference to an identifier such as a name, an identification number, location data or an online identifier. Processing is any operation performed on personal data, from collection and storage through disclosure to erasure. The controller determines the purposes and means of the processing, alone or jointly with others; the processor processes personal data on the controller's behalf. Which one you are is a question of fact about who decides — and Article 28(10) converts a processor that starts determining purposes and means into a controller for that processing. Principles & lawful bases Seven principles, six bases, one prohibition Article 5 sets what all processing must look like. Article 6 decides whether it may happen at all. Article 9 closes a category of data behind stricter doors. Article 5(1) names six principles every processing operation must satisfy: lawfulness, fairness and transparency; purpose limitation — collected for specified, explicit and legitimate purposes and not further processed incompatibly; data minimisation — adequate, relevant and limited to what is necessary; accuracy, with inaccurate data erased or rectified without delay; storage limitation — kept in identifiable form no longer than necessary; and integrity and confidentiality, processed with appropriate security. Article 5(2) adds the seventh, and it is the one audits turn on: accountability — the controller is responsible for, and must be able to demonstrate compliance with, all of the above. Lawfulness is a closed list. Article 6(1) makes processing lawful only if at least one basis applies: consent; necessity for a contract with the data subject or pre-contractual steps at their request; necessity for compliance with a legal obligation on the controller; necessity to protect vital interests; necessity for a task in the public interest or official authority; or necessity for the legitimate interests of the controller or a third party, except where the interests or fundamental rights of the data subject override them — a basis public authorities cannot use in the performance of their tasks. Where the basis is consent, Article 7 sets the conditions: demonstrable, clearly distinguishable when bundled into a wider declaration, withdrawable at any time, and as easy to withdraw as it was to give. Article 7(4) makes conditioning a contract on unnecessary consent count against consent being freely given at all. Article 9(1) then prohibits processing of the special categories outright: data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, genetic data, biometric data for the purpose of uniquely identifying a person, data concerning health, and data concerning sex life or sexual orientation. Article 9(2) reopens the door only through named exceptions — explicit consent, employment and social-security law, vital interests where consent is impossible, data manifestly made public by the data subject, legal claims, substantial public interest on a legal basis, health care and public health, and archiving and research under Article 89(1) safeguards among them — each exception carrying the legal-basis, necessity, proportionality and safeguard conditions its own Article 9(2) limb attaches. Article 9(4) lets Member States add further conditions for genetic, biometric and health data. Data subject rights What the people in your data can demand Chapter III gives data subjects enforceable rights against you — on a one-month information clock, free of charge in the ordinary case. The procedure wraps every right. Article 12 requires the information and communications to be concise, transparent, intelligible and in clear and plain language; obliges the controller to “facilitate the exercise of data subject rights”; and starts a clock — information on action taken, without undue delay and in any event within one month of receipt, extendable by two further months where necessary for the complexity and number of the requests, if you explain the extension within the first month. Handling is free of charge unless a request is manifestly unfounded or excessive, and the controller carries the burden of demonstrating that. Article 13 front-loads transparency: at collection — except to the extent the data subject already has it — the data subject receives the controller's identity, the purposes and legal basis, the legitimate interests where that is the basis, recipients, any third-country transfer and its safeguards where applicable, the storage period, the list of rights, and more. Right What it obliges you to do Access — Art. 15 Confirm whether you process data about the person and give access to it plus the purposes, categories, recipients, storage period, source where not collected from them, and the existence of automated decision-making with meaningful information about the logic. Provide a copy — electronically, if asked electronically. Rectification — Art. 16 Correct inaccurate data without undue delay and complete incomplete data, including by a supplementary statement. Erasure — Art. 17 Erase without undue delay on the listed grounds — data no longer necessary, consent withdrawn with no other basis, a successful objection, unlawful processing among them. Article 17(3) lists the exceptions — freedom of expression, legal obligations, public health, archiving and research, legal claims — each in the circumstances and on the conditions that paragraph attaches. If you made the data public, take reasonable steps to tell other controllers the person asked for links and copies to go. Restriction — Art. 18 Freeze processing while accuracy is contested, where processing is unlawful but the person prefers restriction to erasure, where they need the data for legal claims, or while an objection is being verified. Restricted data may still be stored — and otherwise processed only with the person's consent, for legal claims, to protect another person's rights, or for important public interests of the Union or a Member State. Portability — Art. 20 Hand over the data the person provided to you in a structured, commonly used and machine-readable format — and transmit it directly to another controller where technically feasible. Applies where the basis is consent or contract and the processing is automated; it does not apply to public-interest or official-authority processing, and it must not adversely affect the rights and freedoms of others. Objection — Art. 21 When the person objects on grounds relating to their particular situation, stop processing based on public-interest or legitimate-interest grounds unless you demonstrate compelling legitimate grounds that override the person's, or the processing serves legal claims. For direct marketing the objection is absolute: once made, the data are no longer processed for that purpose. The right must be brought to the person's attention explicitly, at the latest at first communication, separately from other information. Automated decisions — Art. 22 Respect the person's right not to be subject to a decision based solely on automated processing, profiling included, that produces legal effects or similarly significantly affects them — a right that does not apply where the decision is necessary for a contract, authorised by law with safeguards, or based on explicit consent. In the contract and consent cases, guarantee at least human intervention, the right to express a view and the right to contest. Obligations What you must have in place The accountability duties run before, during and after the processing — and two of them come with clocks. Build it in — Article 25 Article 25 obliges the controller to implement appropriate technical and organisational measures — pseudonymisation is the named example — both when determining the means of processing and during the processing itself, designed to implement the data-protection principles effectively. By default, only the personal data necessary for each specific purpose may be processed, and that default governs the amount collected, the extent of processing, the storage period and the accessibility — including that data are not made accessible to an indefinite number of people without the individual's intervention. Contract your processors — Article 28 Article 28 allows only processors providing sufficient guarantees, bound by a contract that stipulates, among the listed terms: processing only on documented controller instructions, transfers included; confidentiality commitments; the Article 32 security measures; no sub-processor without prior written authorisation, with the same obligations flowing down and the initial processor remaining fully liable to the controller for the sub-processor's performance; assistance with data subject requests and with the controller's security, breach, impact-assessment and consultation duties; deletion or return of the data at the end of the engagement; and audits, inspections included. The processor must immediately flag an instruction it considers infringing. Write it down — Article 30 Article 30 requires the controller to keep a record of its processing activities — purposes, categories of data subjects and data, recipients, transfers, envisaged erasure time limits, a general description of the security measures — and the processor to keep a record of the categories of processing it carries out on behalf of each controller. Both are kept in writing and made available to the supervisory authority on request. The Article 30(5) derogation for organisations under 250 persons applies only where the processing is unlikely to pose a risk, is occasional, and touches no special categories and no criminal-convictions data — three conditions that must all hold at once. Secure it — Article 32 Article 32 requires the controller and the processor to implement measures appropriate to the risk, naming as candidates: pseudonymisation and encryption; the ability to ensure ongoing confidentiality, integrity, availability and resilience of processing systems; the ability to restore availability and access in a timely manner after an incident; and a process for regularly testing, assessing and evaluating the effectiveness of the measures. The risk assessment behind the choice looks in particular at accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access. Report the breach — Articles 33 and 34 Supervisory authority — Art. 33 Data subjects — Art. 34 Trigger Every personal data breach, unless it is unlikely to result in a risk to the rights and freedoms of natural persons. A breach likely to result in a high risk to the rights and freedoms of natural persons. Clock Without undue delay and, where feasible, within 72 hours of becoming aware; later notification carries reasons for the delay. Information may follow in phases, without undue further delay. The processor notifies the controller without undue delay. Without undue delay, in clear and plain language, with at least the contact point, likely consequences and measures taken or proposed. Way out None for notifiable breaches — and Article 33(5) requires documenting every breach, notifiable or not, so the authority can verify compliance. Not required where the affected data were made unintelligible to unauthorised persons — encryption is the named example — where later measures removed the high risk, or where individual notice takes disproportionate effort and a public communication informs people equally effectively. Assess it first, and appoint where required — Articles 35 and 37 Article 35 requires a data protection impact assessment before processing likely to result in a high risk — in particular systematic and extensive evaluation of personal aspects, based on automated processing, feeding decisions with legal or similar effects; large-scale processing of special categories or criminal-convictions data; and large-scale systematic monitoring of publicly accessible areas — with the DPO's advice sought where one is designated. Article 37 makes a data protection officer mandatory for public authorities and bodies (courts acting in their judicial capacity excepted) and for organisations whose core activities involve regular and systematic monitoring of data subjects on a large scale, or large-scale processing of special categories and criminal-convictions data. International transfers The Chapter V ladder Adequacy first, safeguards second, derogations last — and the rule at the top governs onward transfers too. Article 44 states the general principle: transfers to third countries or international organisations happen only under Chapter V's conditions — onward transfers from the destination included — so that the level of protection the Regulation guarantees is not undermined. The first rung is an Article 45 adequacy decision: the Commission has decided the third country, a territory or sector within it, or the organisation ensures an adequate level of protection, the transfer needs no specific authorisation, the Commission publishes the list in the Official Journal and reviews each decision at least every four years. Absent adequacy, Article 46 requires appropriate safeguards plus enforceable data subject rights and effective remedies. The instruments that work without a supervisory authority's specific authorisation include the Commission's standard data protection clauses, binding corporate rules under Article 47 , approved codes of conduct and approved certification mechanisms with binding commitments from the receiving side. Ad-hoc contractual clauses are possible with the competent authority's authorisation. The last rung is Article 49 : derogations for specific situations — explicit consent given after being informed of the risks, contract necessity, important reasons of public interest, legal claims, vital interests, and transfers from public registers on that limb's own conditions. Failing all of those, a transfer may still happen only if it is not repetitive, concerns a limited number of data subjects, is necessary for compelling legitimate interests not overridden by the data subject's, and rests on a documented assessment with suitable safeguards — with the supervisory authority and the data subject both informed, and the assessment kept in the Article 30 records. Enforcement Two fine tiers, plus the claims you owe individuals Article 83 prices infringements by what was infringed. Articles 77 and 82 give individuals their own routes. Ceiling What falls under it EUR 10 000 000 or 2% — Art. 83(4) The controller and processor obligations Article 83(4) enumerates — data protection by design and by default, processor contracts, records, security, breach notification, impact assessments and the DPO among them. For an undertaking, the ceiling is the higher of the euro figure and 2% of total worldwide annual turnover of the preceding financial year. EUR 20 000 000 or 4% — Art. 83(5) The provisions Article 83(5) enumerates — the basic principles including conditions for consent, the data subjects' rights, third-country transfers, obligations under Member State law adopted under Chapter IX, and non-compliance with a supervisory authority's order or limitation. Same higher-of construction for undertakings. The factors — Art. 83(2) Nature, gravity and duration; intentional or negligent character; mitigation; the degree of responsibility given the Article 25 and 32 measures; previous infringements; cooperation; the data categories affected; the manner in which the infringement became known — in particular whether, and to what extent, you notified it yourself; adherence to codes and certifications; and financial benefits gained or losses avoided. For linked infringements, the total stays within the ceiling for the gravest one. The fine is not the only exposure. Article 77 gives every data subject who considers that processing of their data infringes the Regulation the right to lodge a complaint with a supervisory authority — in the Member State of their habitual residence, place of work or the place of the alleged infringement, without prejudice to any other remedy. Article 82 gives any person who suffered material or non-material damage from an infringement the right to compensation from the controller or processor, with joint and several liability where several actors share responsibility, so each can be held liable for the entire damage. GDPR, NIS2, DORA and the CRA Data law, next to the cyber laws The GDPR protects the people in the data. The EU's cyber laws regulate entities and products. Treat overlapping duties as parallel, not interchangeable. Article 1 states the subject-matter: rules relating to the protection of natural persons with regard to the processing of personal data, and to the free movement of personal data — a fundamental-rights law with no company-size threshold anywhere in its scope rules, which turn on the Article 2 and 3 tests, not on sector or size. Our NIS2 , DORA and CRA explainers cover the laws whose triggers are being a regulated entity or placing a product on the market — each cited to its own text. Treat the overlap as parallel duties, not substitutes. The Article 32 security duty stands on its own terms, and so does the breach duty: a personal data breach — unless it is unlikely to result in a risk to people's rights and freedoms — starts the Article 33 notification to the data protection authority, without undue delay and, where feasible, within 72 hours. The Article 33 text carries no carve-out for notifications made under other regimes, so the safe operating assumption is to map each duty to its own regime, addressee and threshold rather than assuming one notification covers all. The date question that dominates the other pages barely exists here: Article 99 put the Regulation into application on 25 May 2018, binding in its entirety and directly applicable in all Member States. For GDPR work the moving parts are not commencement dates but the things that keep changing around a stable text — adequacy decisions under Article 45 with their four-yearly reviews, supervisory authority DPIA lists under Article 35(4) , and Member State law in the areas the Regulation leaves open. How Ansvar helps From article text to a cited gap analysis or DPIA Every answer grounded in the regulation, in the AI client your team already uses. The fastest way to see where you stand: a GDPR gap analysis and a DPIA are both 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 it comes from. The sample gap analysis shows the deliverable shape end to end, and the sample DPIA shows the Article 35 deliverable specifically. Two duties reward starting early: Article 30 records and Article 32 security measures are both lists you can start writing today, and both feed breach readiness — an Article 33 notification describes, where possible, the categories and approximate numbers of data subjects and records concerned, and the Article 30 record is where the categories already live. 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 GDPR If your question is not here, email us — every message gets a human answer. Does the GDPR apply to my company? Two questions decide it: is the processing within the material scope of Article 2 — personal data processed wholly or partly by automated means, plus manual processing that forms or is intended to form part of a filing system — and is there a territorial hook under Article 3. Any one territorial route is enough: an establishment in the Union whose activities the processing relates to (Article 3(1)); with no Union establishment at all, offering goods or services to people who are in the Union, paid or not, or monitoring their behaviour there (Article 3(2)); or a place where Member State law applies by virtue of public international law (Article 3(3)). The trigger is people in the Union, not citizenship. Processing by a natural person in the course of a purely personal or household activity is excluded. What are the GDPR fines? Article 83 sets two ceilings. The lower tier, Article 83(4): up to EUR 10 000 000 or, for an undertaking, up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher — for the controller and processor obligations (records, security, breach notification, impact assessments and the DPO among them). The upper tier, Article 83(5): up to EUR 20 000 000 or 4% of total worldwide annual turnover of the preceding financial year, whichever is higher — for the basic principles including consent, the data subjects' rights and third-country transfers. Article 82 adds private compensation claims, including for non-material damage. What is the deadline for reporting a data breach? The controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware — unless the breach is unlikely to result in a risk to people's rights and freedoms (Article 33). A later notification carries reasons for the delay, and information may follow in phases without undue further delay. A processor notifies the controller without undue delay. When the breach is likely to result in a high risk, Article 34 adds a second duty: tell the affected people without undue delay — not required where the data were made unintelligible to unauthorised persons (encryption is the named example), where the risk has since been removed, or where individual notice would involve disproportionate effort, in which case a public communication that informs people in an equally effective manner takes its place. What counts as valid consent? Freely given, specific, informed and unambiguous, given by a statement or a clear affirmative action (Article 4(11)). Article 7 adds the operating conditions: you must be able to demonstrate it; a consent request bundled into a wider declaration must be clearly distinguishable and in plain language; withdrawal must be possible at any time and as easy as giving consent was; and making a contract conditional on consent to unnecessary processing counts against the consent being freely given. Where special-category data under Article 9 rely on consent, it must be explicit. When is a data protection impact assessment required? Before any processing likely to result in a high risk to people's rights and freedoms, in particular with new technologies — the assessment comes prior to the processing (Article 35(1)). Article 35(3) names three cases in particular: systematic and extensive automated evaluation of personal aspects feeding decisions with legal or similarly significant effects; large-scale processing of special categories or criminal-convictions data; and large-scale systematic monitoring of publicly accessible areas. Your supervisory authority also publishes its own list of processing kinds that trigger the duty. Do we need a data protection officer? Article 37(1) makes designation mandatory in three cases: you are a public authority or body (courts acting in their judicial capacity excepted); your core activities require regular and systematic monitoring of data subjects on a large scale; or your core activities consist of large-scale processing of the Article 9 special categories and of criminal-convictions data. Otherwise designation is voluntary unless Union or Member State law requires it. A group of undertakings may appoint a single DPO, provided the DPO is easily accessible from each establishment. Do small companies have to keep records of processing? Often yes. Article 30(5) lifts the record-keeping duty below 250 employees only where the processing is not likely to pose a risk, is only occasional, and includes no special categories and no criminal-convictions data — all three at once. As a practical reading (the Regulation does not define occasional), processing that is a regular part of how the business runs is unlikely to qualify. For a controller the record is the Article 30(1) list — purposes, categories, recipients, transfers, erasure time limits, security measures; a processor keeps the narrower Article 30(2) record of the categories of processing it runs for each controller. Both are kept in writing and shown to the supervisory authority on request. How do we transfer personal data outside the EU? Chapter V is a ladder, and Article 44 makes it govern onward transfers too. First rung: an Article 45 adequacy decision — the Commission has decided the destination ensures adequate protection, and the transfer needs no specific authorisation. Second, absent adequacy: Article 46 appropriate safeguards with enforceable rights and remedies — the Commission's standard data protection clauses, binding corporate rules, or approved codes of conduct and certification mechanisms together with binding and enforceable commitments from the receiving side. Last rung: the Article 49 derogations for specific situations, explicit consent after being informed of the risks and contract necessity among them, with a tightly conditioned, documented one-off route at the very bottom. See where you stand on the GDPR A free-tier run produces a cited GDPR gap analysis or DPIA of a system you describe — one row per requirement, each anchored to its article. Start there, then bring your own documents on a paid plan. Start free See a sample deliverable --- ## EU Machinery Regulation explained: scope, EHSRs, conformity, 2027 — with citations · Ansvar AI URL: https://ansvar.eu/regulations/machinery What Regulation (EU) 2023/1230 requires — scope, the Annex III safety and cybersecurity rules, conformity routes, the AI Act coupling, the 2027 dates — cited. Machinery Regulation The EU Machinery Regulation, explained for the teams who build the machines . Regulation (EU) 2023/1230 replaces the Machinery Directive from 20 January 2027 — and it brings the machine into the connected age: intervention evidence, protected safety software, control systems hardened against malicious interference, and a dedicated conformity route for machine-learning safety components. If you build machinery or related products for the EU market, this is the law your CE marking will stand on — and partly completed machinery travels on its own parallel track. Run a gap analysis — free Read the regulation Applicability Who is in scope Machinery, five related product groups and partly completed machinery — with named exclusions, not general ones. Article 2(1) applies the Regulation to machinery and to five related product groups — interchangeable equipment, safety components, lifting accessories, chains, ropes and webbing, and removable mechanical transmission devices — and to partly completed machinery, which travels through the whole text with its own duties. Article 3 carries the definitions, and Article 1 states the purpose: health and safety requirements for design and construction, so products can move on the market while protecting people — consumers and professional users alike. The exclusions in Article 2(2) are a named list, each with its own limiting conditions — among them: safety components intended to be used as spare parts to replace identical components, supplied by the original manufacturer; fairground and amusement-park equipment; machinery for nuclear installations where conformity could undermine nuclear safety; weapons; most transport (air, water, rail, type-approved road vehicles — except machinery mounted on them); seagoing vessels and mobile offshore units; machinery specially designed and constructed for military or police purposes, or for research purposes for temporary use in laboratories; mine winding gear; performer-moving stage machinery; and — insofar as the low-voltage Directive 2014/35/EU or the radio equipment Directive 2014/53/EU covers them — household appliances intended for domestic use that are not electrically operated furniture, audio and video equipment, IT equipment, ordinary office machinery (except additive printing machinery for producing three-dimensional products, which that entry does not exclude), low-voltage switchgear and control gear, electric motors, and high-voltage switchgear, control gear and transformers. Article 9 adds a lex-specialis rule: where Union harmonisation legislation more specific than this Regulation wholly or partly covers a risk addressed by the Annex III requirements, this Regulation does not apply to the product to the extent of that risk. The duty-holders form the standard economic-operator chain. Manufacturers carry the core duties ( Article 10 ); importers verify before placing on the market ( Article 13 ); distributors act with due care ( Article 15 ); partly completed machinery has its own parallel chain ( Articles 11 , 14 and 16 ). Two manufacturer-status rules close the loop: an importer or distributor that places a product on the market under its own name or trademark, or modifies a product already placed on the market in a way that might affect compliance, takes on the manufacturer's obligations ( Article 17 ), and a person who carries out a substantial modification of machinery is treated as its manufacturer — except a non-professional user substantially modifying their own machinery for their own use ( Article 18 ). Obligations What the manufacturer must do Design to Annex III, prove it, mark it — and keep the evidence for a decade. Article 8 is the gate: machinery and related products may be made available or put into service only if, properly installed, maintained and used for their intended purpose or under reasonably foreseeable conditions, they meet the essential health and safety requirements of Annex III. Article 10 turns that into the manufacturer's programme: design and construct to Annex III; draw up the Annex IV technical documentation; run the Article 25 conformity assessment; issue the EU declaration of conformity ( Article 21 ) and affix the CE marking ( Article 24 ); keep the documentation for at least 10 years; ensure series production stays conformant; and take corrective action — informing the national authorities where the product presents a risk. Two duties are new-generation. The technical documentation now reaches into code: where necessary for checking compliance with Annex III, the source code or programming logic included in the technical documentation must be made available to competent national authorities on a reasoned request (Article 10(3)). And instructions may go digital — but the manufacturer must mark how to access them, keep them printable, downloadable and available online during the product's expected lifetime and for at least 10 years after placing on the market, provide a paper copy free of charge within one month where the user requests it at the time of purchase, and — where the product is intended for non-professional users or can foreseeably be used by them — provide the safety information essential for safe putting into service and use on paper (Article 10(7)). Conformity leans on standards: products conforming to harmonised standards published in the Official Journal are presumed to conform to the Annex III requirements those standards cover ( Article 20(1) ), and where standards are missing or inadequate the Commission can adopt common specifications as a fallback (Article 20(3)). Security as safety The Annex III requirements a security team will recognise The Regulation writes intervention evidence, software integrity and attack resilience into machine SAFETY law. Protection against corruption — Annex III, point 1.1.9 Connecting another device — directly or through a remote device that communicates with the machine — must not lead to a hazardous situation. A hardware component transmitting signal or data that is relevant for connection or access to software critical for the product's compliance with the essential requirements must be protected against accidental or intentional corruption, and the product must collect evidence of legitimate and illegitimate interventions in that hardware component, where relevant for that connection or access. Software and data critical for compliance must be identified as such and protected against corruption; the product must be able to identify, at all times and in an easily accessible form, the software installed on it that is necessary for safe operation, and must collect evidence of interventions in — or modifications of — that software or its configuration ( Annex III ). Safety and reliability of control systems — Annex III, point 1.2.1 Control systems must be designed to prevent hazardous situations: they must withstand, where appropriate to the circumstances and the risks, the intended operating stresses and external influences — including reasonably foreseeable malicious attempts from third parties leading to a hazardous situation; hardware faults and logic errors must not lead to hazardous situations. The limits of the safety functions must be established in the manufacturer's risk assessment, and no modifications to the settings or rules generated by the machine or by operators — including during a learning phase — are allowed where the modification could lead to a hazardous situation. A tracing log of the intervention data and of uploaded safety-software versions must stay enabled for five years after upload, exclusively to demonstrate conformity with the Annex on a reasoned request from a competent national authority. Control systems with fully or partially self-evolving behaviour carry three extra rails: the machine must not act beyond its defined task and movement space; safety-related decision data must be recorded and kept for one year after collection, under the same exclusive purpose limitation; and it must be possible at all times to correct the machine to maintain its inherent safety. Conformity Which assessment route applies Annex I decides — and machine-learning safety functions sit on the strictest list. Article 25 assigns the procedure by list membership in Annex I ; Article 6 governs the lists themselves, including the Commission's power to amend them by delegated act as risk knowledge evolves. Category Route Annex I, Part A Six entries: removable mechanical transmission devices including their guards; guards for removable mechanical transmission devices; vehicle servicing lifts; portable cartridge-operated fixing and other impact machinery; safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions; and machinery with such embedded safety systems that have not been placed independently on the market — in respect only of those systems. No self-assessment: EU type-examination plus conformity to type (modules B + C), full quality assurance (module H), or unit verification (module G) — Article 25(2). Annex I, Part B The classic high-risk catalogue, defined by specified types and conditions — among them particular configurations of woodworking saws and planers, qualifying metal presses, injection or compression plastics- and rubber-moulding machinery with manual loading or unloading, and two underground machinery types. Internal production control (module A) survives only where the product was designed and constructed in accordance with harmonised standards or common specifications specific to that category , covering all the relevant requirements; otherwise modules B + C, H or G — Article 25(3). Not listed Internal production control (module A) — the manufacturer's own assessment, Article 25(4). For machinery and related products the paperwork converges: the EU declaration of conformity ( Article 21 ) and the CE marking affixed visibly, legibly and indelibly ( Article 24 , under the general principles of Article 23 ). Partly completed machinery carries no CE marking under this Regulation — it gets the EU declaration of incorporation ( Article 22 ) instead. Market surveillance then runs on the standard Union model: the Article 43 national procedure for products presenting a risk, and Article 45 for the uncomfortable case of a compliant product that still presents one. Penalties are national: Article 50 requires effective, proportionate and dissuasive rules and allows criminal penalties for serious infringements — the Regulation itself sets no fine ceilings. The AI Act coupling Where machine safety meets AI regulation A 2026 amendment wires the two regimes together — requirements, standards and timelines. Regulation (EU) 2026/1744 amended the Machinery Regulation in three places ( its Article 3 ). First, Article 8 gains new paragraphs instructing the Commission to adopt delegated acts adding health and safety requirements to Annex III for AI systems classified as high-risk under Article 6(1) of the AI Act because they are a safety component in a product covered by this Regulation, or are themselves such a product. The requirements must reflect the AI Act provisions the amendment names, the Commission must take the AI Act's objectives into account and ensure a level of protection consistent with it, and the delegated acts are to apply by 2 August 2028 . Second, a new Article 20(10) bridges the standards gap: until machinery-side harmonised standards are referenced or common specifications adopted pursuant to Article 20 for high-risk AI systems, conformity with the relevant harmonised standards referenced under Article 40 of the AI Act — or common specifications adopted under its Article 41 , respectively — gives a presumption of conformity with the Annex III requirements as regards those systems. Third, the Article 47 delegation mechanics were extended to carry the new power. The direction of travel is explicit: AI safety in machines is machine-safety law, assessed in the machinery conformity file — and Annex I Part A routes machine-learning safety components through notified-body conformity assessment from 20 January 2027. Dates One headline date, four staged ones The Regulation applies from 20 January 2027 — but parts of it have been live since 2023. Article 54 : the Regulation applies from 20 January 2027 . The staged exceptions it lists: Articles 26 to 42 from 20 January 2024; the Article 50(1) penalties duty from 20 October 2026; Article 6(7), Article 48 and the Article 52 transitional rules from 19 July 2023; and Article 6(2) to (6), (8) and (11), Article 47 and Article 53(3) from 20 July 2024. Article 51 repeals the Machinery Directive 2006/42/EC with effect from 20 January 2027, with references to the Directive construed as references to the Regulation, read in accordance with the correlation table in Annex XII . Check which version your own copy is. A corrigendum moved several of these dates after the Regulation was first published, and the original Official Journal text was not reissued — so a copy taken from it still shows the earlier ones. The dates above are the consolidated text of 27 July 2026, and every citation on this page links to that consolidation rather than to the original. Article 52 settles the shelf question: products placed on the market in conformity with the Directive before 20 January 2027 may continue to be made available — with this Regulation's Chapter VI market-surveillance procedure applying to them, mutatis mutandis, since 19 July 2023 in place of the Directive's Article 11, pending procedures included — and EC type-examination certificates and approval decisions issued under the Directive remain valid until they expire. The practical consequence runs the other way: from 20 January 2027, new placings on the market stand on this Regulation — including the Annex III requirements above — not on the Directive your current file may be built against. Machinery, CRA and the AI Act Safety law, next to the neighbouring regimes The Regulation's own boundary rule is Article 9 — and the AI coupling is written into the text. The Machinery Regulation is product safety law: its Annex III requirements — intervention evidence, software integrity, attack-resilient control systems — exist to prevent hazardous situations, and they are assessed in the CE conformity file. The boundary rule the Regulation itself states is Article 9 : where Union harmonisation legislation more specific than this Regulation wholly or partly covers a risk addressed by the Annex III requirements, this Regulation does not apply to the product to the extent of that risk. For AI, the coupling is explicit and cited above. For the neighbouring regimes we keep separately cited explainers — the Cyber Resilience Act , the NIS2 Directive , the DORA Regulation and the GDPR — each grounded in its own text rather than summarised here. For a connected machine, the practical reading is one product with more than one file to keep straight: the machinery conformity assessment for safety, and whatever the other regimes attach to the same product or to your organisation. How Ansvar helps From annex point 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 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 Machinery Regulation lands hardest on engineering teams with connected or ML-assisted products — the Annex III corruption-protection and control-system points read like a security backlog. Our sector pages for robotics , agriculture and industrial OT show how the served corpora cover the machine-adjacent regimes side by side. FAQ Questions teams ask about the Machinery Regulation If your question is not here, email us — every message gets a human answer. Does the Machinery Regulation apply to my product? Article 2 applies the Regulation to machinery and five related product groups — interchangeable equipment, safety components, lifting accessories, chains, ropes and webbing, and removable mechanical transmission devices — plus partly completed machinery. The exclusions are named and each carries its own conditions — among them: safety components intended as spare parts to replace identical components, supplied by the original manufacturer; fairground and amusement-park equipment; weapons; most vehicles regulated under their own type-approval regimes (except machinery mounted on them); machinery specially designed and constructed for military or police purposes; and — insofar as the low-voltage or radio equipment rules cover them — household appliances intended for domestic use that are not electrically operated furniture, audio, video and IT equipment and ordinary office machinery, an entry that does not exclude additive printing machinery for producing three-dimensional products. When does the Machinery Regulation apply? Article 54: the Regulation applies from 20 January 2027, with earlier dates for specific blocks — Articles 26 to 42 from 20 January 2024, the penalties duty of Article 50(1) from 20 October 2026, and the delegated-act machinery of Article 6 and Article 47 largely from 20 July 2024. Article 52 keeps the transition orderly: products placed on the market in conformity with the Machinery Directive 2006/42/EC before 20 January 2027 may continue to be made available — with this Regulation's Chapter VI applying to such legacy products, mutatis mutandis, since 19 July 2023 — and EC type-examination certificates and approval decisions issued under that Directive remain valid until they expire. What happens to the Machinery Directive? Article 51 repeals Directive 2006/42/EC with effect from 20 January 2027, and references to the repealed Directive are construed as references to the Regulation, read in accordance with the correlation table in Annex XII. The practical difference in legal form: a regulation is binding in its entirety and directly applicable in all Member States — the closing formula of Article 54 — so the per-country transposition layer of the Directive era falls away. Do we need a notified body, or can we self-assess? It depends on which Annex I list your product is on. Article 25(2): categories in Annex I Part A — among them safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions, and machinery with such embedded safety systems not placed independently on the market, in respect only of those systems — take EU type-examination plus conformity to type (modules B + C), full quality assurance (module H), or unit verification (module G). Article 25(3): Part B categories may use internal production control (module A) only where the product was designed and constructed in accordance with harmonised standards or common specifications specific to that category, covering all the relevant requirements; otherwise a Part A-style route applies. Products on neither list self-assess under module A. What cybersecurity does the Machinery Regulation require? Annex III carries it as safety. Point 1.1.9, protection against corruption: connecting another device must not lead to a hazardous situation; hardware components transmitting signal or data relevant for connection or access to compliance-critical software — and the critical software and data themselves — must be protected against accidental or intentional corruption; the product must collect evidence of interventions and be able to identify, at all times and in an easily accessible form, the software installed on it that is necessary for safe operation. Point 1.2.1: control systems must withstand, where appropriate to the circumstances and the risks, reasonably foreseeable malicious attempts from third parties leading to a hazardous situation, and must keep a tracing log of interventions and safety-software versions for five years after upload — exclusively to demonstrate conformity on a reasoned request from a competent national authority. Self-evolving control systems carry extra rails, including that it must be possible at all times to correct the machine to maintain its inherent safety. How does the Machinery Regulation interact with the AI Act? Two hooks, both added by amendment in 2026. Article 8 now instructs the Commission to adopt delegated acts adding health and safety requirements to Annex III for AI systems classified as high-risk under Article 6(1) of the AI Act because they are a safety component in — or are themselves — a product covered by the Regulation; those requirements must reflect the named AI Act provisions, the Commission must take the AI Act's objectives into account and ensure a consistent level of protection, and the delegated acts are to apply by 2 August 2028. Article 20(10) bridges the standards gap: until machinery-side harmonised standards are referenced or common specifications adopted for high-risk AI systems, conformity with the relevant harmonised standards referenced — or common specifications adopted — under the AI Act's own standards articles gives a presumption of conformity with the Annex III requirements as regards those systems. Separately, Annex I Part A routes machine-learning safety components through notified-body conformity assessment from 20 January 2027. What about partly completed machinery? It is in scope with its own track. Article 11 requires the manufacturer to design and construct it in accordance with the relevant Annex III requirements — relevant, because the assembly is not yet complete — and to draw up the Annex IV Part B technical documentation, assembly instructions and, per Article 22, an EU declaration of incorporation rather than a declaration of conformity. The duties then travel down the chain: importers and distributors of partly completed machinery carry their own verification obligations under Articles 14 and 16. What are the penalties? The Regulation sets no EU-level fine ceilings. Article 50 requires Member States to lay down the penalty rules for infringements, to take all measures necessary to ensure they are implemented, and to make them effective, proportionate and dissuasive — and it expressly allows criminal penalties for serious infringements. The timing is nearer than the headline date suggests: Article 54(b) applies Article 50(1) from 20 October 2026, and Article 50(2) requires Member States to notify the Commission of those rules and measures by that same date — three months before the Regulation applies in general. Enforcement runs through market surveillance: under Article 43, authorities with sufficient reason to believe a product presents a risk carry out an evaluation, and corrective obligations follow a finding of non-compliance; under Article 45 even a compliant product that still presents a risk can be pulled back. See where you stand before January 2027 A free-tier run produces a cited 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. Examples 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 Plans, limits and terms for Ansvar. Start free, grow by scope. Team is priced per seat, a person or an agent; on-prem and ISMS as Code on annual contracts. Pricing Start free. Grow by scope, not by surprise. Every plan is a connection to the same evidence. What changes is how far a question reaches, what your agent may run, and who shares the workspace. A seat is a seat, whether a person or an agent holds it. Monthly Annual Annual is ten months on self-serve plans; Company is billed annually at twelve. Prices in euro, VAT added at checkout. Free €0 for businesses, no card Try a cited answer in one jurisdiction. One jurisdiction or framework per question 100 searches a day CVE, KEV and EPSS lookups One assessment a month, watermarked, from a shared pool Start free Solo €29 / month one person or one agent Every supported jurisdiction in one question. Every jurisdiction in one question 750 searches a day Two assessments a month, watermarked, from a shared pool The seat may be an agent Choose Solo Premium €249 / month per seat Case law, guidance and the assessment catalogue on a described system. Case law, preparatory works, agency guidance The assessment catalogue on a described system, five runs a month (a few variants start at Team) 5,000 searches a day Service credentials for standing agents, each on a seat Choose Premium Team Workspace €490 / month per seat Assessments on your own documents, the living architecture model, your agents on the same pool. Each seat is a person or an agent credential Five service credentials included per workspace Your documents, cited by paragraph One architecture workspace licence included Twenty runs a month per seat, pooled, then €35 a run 50,000 searches a day, pooled Seats − + € 490 /mo · 1 seat × € 490 /mo Choose Team Company €2,000 / month from, billed annually on contract Contractual capacity, single tenancy and the signed audit ledger. Signed audit ledger per tenant Five architecture workspace licences and the plane 100 assessments a month included 500,000 searches a day, pooled Named contact, response schedule Talk to us The Free and Solo assessment allowance is served from one monthly pool shared across all accounts. When the pool is spent, a run is refused with the reset date rather than served thinner. From Premium, the runs are your own. Every limit, published Evidence Pro NEW €99 / month For one person: case law, preparatory works and agency guidance on every served jurisdiction, two assessments a month on a described system with a JSON report, and 1,500 searches a day. No security risk scoring; that stays with Premium. Request access Architecture workspace licence NEW €149 / month Living security architecture on its own, self-hosted: one workspace, three contributors, unlimited components, agents on the pool. It runs on your machine or inside your plane; we never host your model. Start with the 30-day evaluation licence, no card. Request access Provisioned on request while we measure demand; the seat carries these limits as written. Worked totals What a workspace costs at volume Twenty runs a month come with each seat, pooled across the workspace, and the rest are €35 each, so a busy month is arithmetic rather than a phone call. Seats and runs in the month Past the allowance What the workspace pays 1 seat , 20 runs none €490 1 seat , 40 runs 20 × €35 €1,190 3 seats , 60 runs none €1,470 3 seats , 100 runs 40 × €35 €2,870 3 seats , 180 runs , the hard stop 120 × €35 €5,670 Each seat is a person or an agent credential, and five service credentials come with the workspace without taking a seat. Each seat adds twenty runs to the pool, and the hard stop is three times the pooled allowance. Monthly, before the standards add-on and VAT. Products and plans How the four products fit the plans A plan is a seat or a workspace on the same connection; a product is what that connection may do. Evidence and security lookups come with every plan, Free included. The rest arrives with the plan that carries it, or on its own contract. Product Free Solo Premium Team Company On its own Legal and regulatory evidence one jurisdiction every jurisdiction + case law and guidance included included Evidence Pro €99 Compliance assessments 1 teaser 2 teasers described system your documents 100 a month no Security risk and threat intelligence lookups · 1 teaser lookups · 2 teasers scoring in eligible runs your contexts, decisions, VEX included no Living security architecture 30-day evaluation 30-day evaluation 30-day evaluation 1 licence 5 licences + plane Licence €149 Add-ons and contracts ISMS as Code no no no with the contract with the contract €9,000 a year, workspace included Licensed ISO standards (SIS) add-on add-on add-on add-on add-on €99 a seat a month A teaser run is one monthly allowance shared across the eligible compliance and security families, not one allowance per product. Premium scoring happens inside a vulnerability assessment, an ICS advisory run or a deferral dossier, not in every run. Limits Every quota, rate and ceiling, on one page. Searches and reads per day, concurrency, runs per month, documents and the refusal you get past a limit. Read the limits Add-ons Licensed standards, per seat Any ISO, EN or SS standard SIS publishes can be licensed onto a seat: the ones named on the standards page are live today, and another is added once its licensing and verification clear. A seat may be held by a person or a service credential, and the text never ships in a content pack. ISO standards Any plan, including Free. Billed per seat, per month. One standard €99 / seat / month Two standards €179 Three standards €219 Four standards €239 Five standards €249 How a standards seat is billed The monthly ladder, from the first seat. No set-up fee. First standard seat €99 a seat a month Further seats and standards monthly ladder Existing contracts unchanged Each licence is reported to the standards body per named seat. Cancel and the access ends with the billing period. Annual contracts ISMS as Code, on-prem, expert delivery Three offers sold on a contract rather than a card. Pilots are paid, fixed in scope, and credited in full when you convert. ISMS as Code The management system as a repository your agent operates. ISO 27001 or NIST-keyed, workspace included €9,000 / year With maintained multi-framework mappings €12,000 / year Pilot, 10 weeks, up to 4 delivery days €6,000, credited Standard text via the add-on How the pilot runs On-prem and air-gapped Ansvar running in your own cluster, or fully inside your perimeter. Plane subscription annual contract Pilot, 8 to 12 weeks, up to 5 delivery days €15,000, credited Second plane, DR or second site second line item Status design-partner pilots Discuss a pilot Expert delivery Our team runs or reviews the assessment. Scope agreed before work starts. Review of your run from €1,900 one report, up to 50 citations, one revision Gap analysis from €4,500 one framework, one entity, up to three interviews DPIA or FRIA from €3,900 one processing activity, one jurisdiction Threat model from €6,500 one bounded system, up to 20 components, three months of Team Automotive or rail TARA quoted scoped together Book a scoping call Good to know Terms in plain words Annual is ten months on self-serve plans Solo, Premium and Team. Company is €2,000 a month billed annually, twelve months, on contract; the contract products are invoiced annually up front. First month back on request Any self-serve paid plan. Ask within the first month and we refund it. Delivered services and licensed standards excluded. Academic and non-profit Half price on Solo and Premium on request. Public sector buys at list, on invoice. Your AI provider is separate Ansvar bills the connection; your model provider bills the tokens. Nothing on this page includes inference. Where your data is handled depends on how you run Ansvar. Compare deployments Business use Ansvar is a B2B service. Free is for businesses, consultants and public-sector practitioners evaluating it. VAT is validated at paid checkout. Refusals are readable Past a limit you get your plan, your usage, the reset time and the next step. Never a thinner answer dressed up as a full one. Limits are published Every quota and rate on one page, kept in step with what the gateway enforces. Read the limits Start with one cited answer. Free for businesses. No card. Connected in two minutes. Start free Talk to us about Company or on-prem --- ## Security & sovereignty · Ansvar AI URL: https://ansvar.eu/security Compare Ansvar's EU-hosted, dedicated Company, and customer-managed design-partner deployments, with clear logging and signed-receipt boundaries. Security & sovereignty EU-hosted. No server-side model. Evidence you can inspect. Your model traffic stays between your AI client and provider. Ansvar serves evidence with item-level provenance; workflow findings cite that evidence or remain unresolved. Operational security logs and the Company cryptographic ledger serve different purposes. 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 Each served evidence row carries its source URL, publisher, and licence, pointing to the original publisher. Ansvar audits source licences before ingestion and fails closed: we do not build a corpus that fails its licensing gate, and we keep a connector repository public only while its audit remains GREEN. The gateway, its hosting chassis, and licensed data remain private. We use digest-pinned builds from version-controlled sources for new and updated corpora; we migrate older corpora as we update them. Source, publisher, and licence cited on every served row Licensing verified before ingestion — fail-closed Deterministic citation resolution Corpus MCP servers store no client data Architecture posture Defense in depth Gateway requests cross three control planes. The hosted service records operational security events; Company adds per-tenant signed receipts for requests and served results. Request From your AI client S1 Network perimeter TLS 1.2+ · 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 Operational security logging Customer data EU-hosted · corpus servers store none · documents tenant-isolated Signed audit receipts Per-tenant cryptographic records that customers can verify. 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 · AI Pact signatory, Aug 2026 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 Operational security logging for gateway requests Corpus MCP servers store no client data; registered documents live in tenant-isolated EU storage 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 Deployment choices Choose where the evidence services run Ansvar operates the hosted EU service today and offers a dedicated Company environment by agreement. Customer-managed deployment is in the design-partner stage. Your model remains in your chosen AI environment in all three designs. EU-hosted service Available now · every plan Ansvar operates the gateway and evidence services on Hetzner in the EU Cloudflare provides edge and TLS termination under the disclosed transfer safeguards Ansvar manages source updates, backups, and operational security logging Dedicated Company environment Available by agreement Tenant-exclusive Hetzner Kubernetes cluster managed by Ansvar Custom retention and service levels set in the Company contract Per-tenant cryptographic ledger with signed, verifiable receipts First dedicated environment is delivered through a Company-tier design partnership Customer-managed deployment Design-partner stage A deployable platform build runs in CI on each merge Ansvar has not released this mode as a self-serve product Ansvar and the first production partner must agree on updates, freshness reporting, support, and licensed-content entitlements Security FAQ Questions we answer before the DPA is signed If yours isn't here, request the security questionnaire — available 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? Corpus MCP servers store no client data. The gateway holds account records, entitlement records, and operational security logs on EU-hosted Kubernetes infrastructure with NetworkPolicy isolation between services and envelope-encrypted secrets (OpenBao KMS). Document grounding on Team and Company stores registered documents and workflow evidence in tenant-isolated EU storage under your retention policy, and the same tools that register a document can remove it. Company adds a separate per-tenant cryptographic ledger with signed receipts. What's your incident response? We notify affected customer admins without undue delay, per our DPA — early enough to support your own clocks, including your GDPR Art. 33 notification to your authority (72 hours, controller to authority) and a NIS2 24-hour early warning where it applies to you. 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? Customer-managed deployment is at the design-partner stage. A deployable platform build exists and runs in CI on each merge. Ansvar has not released it as a self-serve product. Ansvar and the first production partner must agree on corpus updates, freshness reporting, support, and licensed-content entitlements. The gateway runtime and base images remain private; Ansvar publishes a small set of connector repositories where licensing allows. What about penetration testing? We performed a white-box penetration test of our platform in August 2026, covering the MCP gateway, authentication, and web applications. Our first independent third-party penetration test is planned for 2026 ahead of ISO 27001 certification — and until that report exists, we will not claim it. 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 and commit to three. 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 commit to three, and we 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 · Defensible assessments for regulated work · Ansvar AI URL: https://ansvar.eu/about Ansvar Systems AB builds governed evidence and workflow infrastructure for legal, compliance, security, and product-assurance decisions. About We build the evidence layer, and we run on it. Ansvar Systems AB is a Swedish company, org.nr 559547-2225. We build the connection that gives AI agents cited law, a living model of a system, assessments with receipts and a management system they can operate. Our own security programme, architecture and audits run on the same products we sell. At a glance Company Ansvar Systems AB, Sweden Org.nr 559547-2225 · VAT SE559547222501. EU-hosted on Hetzner. Cybersecurity Made in Europe. Founder Jeffrey von Rotz Security architect. Writes the publisher letters, signs the contracts, answers the hard questionnaires. How we work Reviewed writes, always Nothing an agent produces becomes truth without a person's assent. That rule shapes the product and the company alike. Audits ISO 27001 in progress Stage 1 assessed on 31 August 2026. Stage 2 in October. Trust What we believe A wrong answer is worse than no answer. That sentence is a rule in our engineering standards, not a slogan. The gateway refuses rather than guesses, receipts record what was served, and limits and prices are published. If a number on this site and a refusal disagree, the refusal is right and we fix the site. Reach us Contact Sales, security questionnaires, publisher and content claims, partnerships. Contact See it on your own question. Free for businesses. Connected in two minutes. Start free Read the blog --- ## Partners · Ansvar AI URL: https://ansvar.eu/partners The companies and associations Ansvar works with: Aetheria Partners, Netsecurity and the Cloud Security Alliance Romania Chapter. Partners The companies we deliver with. Some customers buy Ansvar from us. Others get it through a company they already work with: one that runs their infrastructure or tests their security. These are those companies. Resale and delivery Reseller and infrastructure partner Aetheria Partners Aetheria Partners builds and runs on-premises AI infrastructure for organisations that keep their data and agents inside their own perimeter. Aetheria resells Ansvar and delivers it as part of those installations. aetheriapartners.com : Aetheria Partners website, opens in a new tab ↗ Security services partner Netsecurity Netsecurity is a security company with offices in Norway and Sweden: security monitoring, penetration testing, incident response and advisory. Netsecurity delivers threat modelling to its customers with Ansvar. netsecurity.no : Netsecurity website, opens in a new tab ↗ Associations Cooperation partner Cloud Security Alliance Romania Chapter The Cloud Security Alliance Romania Chapter is run by the non-profit Cyber Security Association for Cloud. Ansvar cooperates with the chapter under a memorandum of understanding. cloudsecurityalliance.ro : Cloud Security Alliance Romania Chapter website, opens in a new tab ↗ Work with us If you run infrastructure or deliver security and compliance work for regulated organisations, write to us. Contact us --- ## 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, our EU AI Pact pledge, 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. Signatory of European Commission · AI Office ↗ EU AI Pact — Pillar II pledge Three core commitments: an AI governance strategy, a mapping of any AI systems we provide or deploy in areas the AI Act treats as high-risk, and AI literacy for everyone working with AI on our behalf Aug 2026 · A voluntary pledge, not a certification — no one audits it. 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 sources your agent can cite | Ansvar AI URL: https://ansvar.eu/coverage Law, case law, preparatory works, regulator guidance and standards that Ansvar serves, country by country, from the original publishers. Coverage What your agent can cite Law, case law, preparatory works, regulator guidance and standards, from the original publishers, for your country. / Europe Country by country. The collections that span Europe are listed under the European Union and on each country's page. European Union Legislation · Regulation · Case law · Guidance · Standards · Across member states → Albania Legislation → Austria Legislation · Case law → Belgium Legislation · Regulation → Bulgaria Legislation · Case law · Guidance → Croatia Legislation → Cyprus Guidance → Czechia Legislation → Denmark Legislation · Preparatory works → Estonia Legislation → Finland Legislation · Preparatory works → France Legislation · Preparatory works · Standards → Germany Legislation · Regulation · Standards → Greece Legislation → Hungary Legislation · Regulation → Iceland Legislation · Regulation → Ireland Legislation → Italy Legislation → Kosovo Legislation → Latvia Legislation · Regulation → Liechtenstein Legislation → Lithuania Legislation · Regulation · Guidance → Luxembourg Legislation · Regulation → Malta Legislation · Guidance → Netherlands Legislation · Regulation · Case law · Preparatory works · Standards → Norway Legislation · Guidance → Poland Legislation · Preparatory works → Portugal Legislation · Guidance → Romania Legislation → San Marino Legislation → Serbia Legislation → Slovakia Legislation → Slovenia Legislation → Spain Legislation · Regulation → Sweden Legislation · Regulation · Preparatory works → Switzerland Legislation → Ukraine Legislation → United Kingdom Legislation · Regulation · Standards → North America Canada Legislation → United States Legislation · Regulation · Preparatory works · Guidance · Standards → Asia-Pacific China Legislation → Japan Legislation → South Korea Legislation · Regulation → Everywhere Standards and security Public frameworks and guidance · Ansvar libraries · Live feeds → Connect your agent Add Ansvar to Claude, Copilot or ChatGPT and ask in plain words. Every answer cites its source. Start free Plans Using Ansvar, which EU rules apply to … Copy Every source is licence-checked before it is served. Premium marks sources on the Premium plan and above. Screening a DPIA? The European register lists each country's Article 35(4) source. Open the DPIA register Missing a source you need? Name it and the workflow it would unlock. Suggest a source Country pages, each with a topic check Albania Austria Belgium Bulgaria Canada China Croatia Czechia Denmark Estonia Finland France Germany Hungary Iceland Ireland Italy Japan Kosovo Latvia Liechtenstein Lithuania Luxembourg Malta Netherlands Norway Poland Portugal Romania San Marino Serbia Slovakia Slovenia South Korea Spain Sweden Ukraine United Kingdom United States Some court decisions name people. We serve those collections only to a company that instructs us as its processor, and they stay out of search and this page until then. Ask about access Check your jurisdiction from your own client. One connection to gateway.ansvar.eu from Claude, Cursor, VS Code Copilot or your own agent. Free for businesses, no card. Start free Ask about coverage --- ## European DPIA trigger coverage · Ansvar AI URL: https://ansvar.eu/coverage/dpia European DPIA trigger sources by jurisdiction: official publisher, preserved legal status, verification date, and whether the deployed workflow queries it. DPIA trigger coverage The source receipt behind a jurisdiction-aware DPIA. This register shows which national DPIA trigger source Ansvar can retrieve, how the source is characterised, when it was verified, and whether its dedicated query is named in the deployed DPIA workflow. See the DPIA workflow Screen a processing activity 29 jurisdiction evidence paths operational 29 named national-source queries deployed 3 authority permissions or reuse bases pending Program snapshot verified through 16 August 2026. Workflow integration is counted against the deployed workflow bundle v1.5.0 , not against unreleased work. Coverage available The source can be retrieved with its publisher, status, and citation intact. Workflow-integrated The deployed DPIA prompt names the national source query for that jurisdiction. Document-grounded Customer evidence is pinned to the resulting finding on Team and Company. Public source register Every jurisdiction keeps its own evidence state. Operational does not mean identical. Published lists, indicative material, an advisory draft, and a statutory no-list determination stay distinct. Jurisdiction National evidence path Source status Workflow state Known limitation AT Austria Datenschutzbehörde DSFA-V, BGBl. II 278/2018, and DSFA-AV, BGBl. II 108/2018 ris.bka.gv.at · verified 2026-08-14 Operational · published national material Named source query deployed Austria serves two instruments: the DSFA-V blacklist and the DSFA-AV exceptions list; an activity matching only the DSFA-AV is exempted. BE Belgium Gegevensbeschermingsautoriteit / Autorité de protection des données Decision 01/2019, Belgian Official Gazette numac 2019011184 ejustice.just.fgov.be · verified 2026-08-14 Operational · published national material Named source query deployed The source is served in Dutch and French; applicability remains a controller and DPO decision. BG Bulgaria Commission for Personal Data Protection List of processing operations under Article 35(4), adopted 13 February 2019 cpdp.bg · verified 2026-08-15 Operational · published national material Named source query deployed The list carries no gazette number; the authority's published page is the instrument. Rows serve bilingually in Bulgarian and English. HR Croatia Agencija za zaštitu osobnih podataka Decision on the published list, KLASA 004-04/18-01/01 azop.hr · verified 2026-08-15 Operational · published national material Named source query deployed The authority's published decision page is itself the instrument; no Narodne novine form exists. CY Cyprus Commissioner for Personal Data Protection Indicative DPIA list submitted under Article 35(4) gov.cy · verified 2026-08-15 Operational · advisory draft Named source query deployed The published English document predates the EDPB opinion and is not presented as a final adopted list. CZ Czechia Úřad pro ochranu osobních údajů Article 35(4) and 35(5) processing lists, version 1.0 uoou.gov.cz · verified 2026-08-15 Operational · published national material Named source query deployed The positive list uses parametric criteria rather than a simple enumeration. DK Denmark Datatilsynet List of processing activities always subject to a DPIA datatilsynet.dk · verified 2026-08-14 Operational · published national material Named source query deployed Criterion matching depends on the processing facts supplied and confirmed in the run. EE Estonia Andmekaitse Inspektsioon Isikuandmete töötleja üldjuhend, chapter 5 aki.ee · verified 2026-08-15 Operational · indicative authority material Named source query deployed The authority characterises the cross-border list as indicative; Ansvar preserves that status. FI Finland Office of the Data Protection Ombudsman Decision listing processing operations that require an impact assessment tietosuoja.fi · verified 2026-08-14 Operational · published national material Named source query deployed Criterion matching depends on the processing facts supplied and confirmed in the run. FR France Commission nationale de l'informatique et des libertés Délibération 2018-327, amended by Délibération 2019-011 legifrance.gouv.fr · verified 2026-08-13 Operational · published national material Named source query deployed The list is served; the national implementation-act check remains open in the program record. DE Germany Datenschutzkonferenz DSK Muss-Liste under Article 35(4), version 1.1 datenschutzkonferenz-online.de · verified 2026-08-13 Operational · published national material Named source query deployed The competent German authority still depends on the controller's establishment and processing context. GR Greece Hellenic Data Protection Authority Decision 65/2018, Government Gazette B 1622/10.05.2019 Εθνικό Τυπογραφείο · verified 2026-08-15 Operational · published national material Named source query deployed The official gazette issue contains unrelated acts; the served source is isolated to the DPIA decision. HU Hungary Nemzeti Adatvédelmi és Információszabadság Hatóság NAIH Article 35(4) list, revised published form naih.hu · verified 2026-08-15 Operational · published national material Named source query deployed Two published forms differ in the wording of the first two items; the revised PDF is served as canonical. IS Iceland Persónuvernd Auglýsing nr. 828/2019 Stjórnartíðindi · verified 2026-08-14 Operational · published national material Named source query deployed Criterion matching depends on the processing facts supplied and confirmed in the run. IE Ireland Data Protection Commission List of processing operations requiring a DPIA, 15 November 2018 dataprotection.ie · verified 2026-08-14 Operational · published national material Named source query deployed The published list carries ten operation types; an earlier sixteen-type version was a draft. IT Italy Garante per la protezione dei dati personali Provvedimento 467/2018 and Annex 1 gazzettaufficiale.it · verified 2026-08-15 Operational · published national material Named source query deployed The official-gazette version is the served source of record. LV Latvia Datu valsts inspekcija Order 1-2.1/125 of 18 December 2018 dvi.gov.lv · verified 2026-08-15 Operational · published national material Named source query deployed The Article 35(5) not-required list is a separate document and is not substituted for this source. LI Liechtenstein Datenschutzstelle List under Article 35(4), version 6 August 2020 datenschutzstelle.li · verified 2026-08-16 Operational · published national material Named source query deployed The 2020 authority version supersedes the 2019 EDPB register mirror. LT Lithuania Valstybinė duomenų apsaugos inspekcija Order 1T-35 (1.12.E), TAR code 2019-04104 Teisės aktų registras · verified 2026-08-15 Operational · published national material Named source query deployed Sub-triggers serve inside their parent categories, so the list counts ten categories rather than sixteen. LU Luxembourg Commission nationale pour la protection des données Délibération 34/2019 cnpd.public.lu · verified 2026-08-15 Authority reuse permission pending Recorded unavailable · no model-memory substitute The source has been identified and reviewed; reuse permission is required before reproduction through the gateway. MT Malta Information and Data Protection Commissioner Published eight-item Article 35(4) list idpc.org.mt · verified 2026-08-15 Authority reuse permission pending Recorded unavailable · no model-memory substitute The publisher's terms require permission for commercial reproduction; no model-memory substitute is used. NL Netherlands Autoriteit Persoonsgegevens Decision published as Staatscourant 2019, 64418 officielebekendmakingen.nl · verified 2026-08-13 Operational · published national material Named source query deployed Criterion matching depends on the processing facts supplied and confirmed in the run. NO Norway Datatilsynet List of processing activities that always require a DPIA datatilsynet.no · verified 2026-08-14 Operational · published national material Named source query deployed Criterion matching depends on the processing facts supplied and confirmed in the run. PL Poland Prezes Urzędu Ochrony Danych Osobowych Communication published as M.P. 2019 item 666 api.sejm.gov.pl · verified 2026-08-14 Operational · published national material Named source query deployed The 2019 communication repeals the earlier list published as M.P. 2018 item 827. PT Portugal Comissão Nacional de Proteção de Dados Regulamento 1/2018, published as Regulamento 798/2018 Diário da República · verified 2026-08-15 Operational · published national material Named source query deployed The official portal exposes no verifiable item permalink; citations point to the pinned published PDF. RO Romania Autoritatea Naţională de Supraveghere a Prelucrării Datelor cu Caracter Personal Decision 174/2018, Official Gazette I 919/31.10.2018 dataprotection.ro · verified 2026-08-15 Operational · published national material Named source query deployed Decision 174/2018 lists seven processing types, lettered a) to g) in the Official Gazette form. SK Slovakia Úrad na ochranu osobných údajov Slovenskej republiky Demonstrative list of 13 processing operations dataprotection.gov.sk · verified 2026-08-15 Authority reuse permission pending Recorded unavailable · no model-memory substitute The source has been identified and reviewed; the legal basis for commercial reuse remains unconfirmed. SI Slovenia Informacijski pooblaščenec Smernice o ocenah učinkov, version 1.2, annexes 3 and 4 ip-rs.si · verified 2026-08-15 Operational · published national material Named source query deployed Only the Slovenian authority text is served; the standalone English form is provenance only. ES Spain Agencia Española de Protección de Datos Listas DPIA, Article 35(4), 11 criteria aepd.es · verified 2026-08-14 Operational · published national material Named source query deployed The authority describes the list as orientative while publishing it under Article 35(4). SE Sweden Integritetsskyddsmyndigheten Förteckning under Article 35(4), DI-2018-13200 imy.se · verified 2026-08-13 Operational · published national material Named source query deployed The list requires a DPIA when at least two of its criteria are met, subject to its stated conditions. CH Switzerland Federal Data Protection and Information Commissioner Federal Act on Data Protection, Articles 22 and 23 fedlex.admin.ch · verified 2026-08-16 Operational · statutory no-list determination Named source query deployed Swiss law creates no national-list mechanism; screening uses the statutory high-risk and consultation provisions. GB United Kingdom Information Commissioner's Office Examples of processing likely to result in high risk ico.org.uk · verified 2026-08-14 Operational · published national material Named source query deployed The UK GDPR and Data Protection Act context must be assessed separately from EU territorial scope. Source governance Unavailable stays unavailable. For Luxembourg, Malta, Slovakia , Ansvar has identified and reviewed the source but does not reproduce it through the gateway. The workflow records the jurisdictional source as unavailable instead of rebuilding it from model memory. Luxembourg The source has been identified and reviewed; reuse permission is required before reproduction through the gateway. Malta The publisher's terms require permission for commercial reproduction; no model-memory substitute is used. Slovakia The source has been identified and reviewed; the legal basis for commercial reuse remains unconfirmed. Questions buyers ask What the coverage claim means. Can a DPIA be fully automated? No. Ansvar can retrieve the relevant source material, test documented processing facts against recorded criteria, and assemble the assessment file. The controller and DPO retain the decisions on territorial scope, necessity, proportionality, residual risk, and sign-off. How does Ansvar check national Article 35 DPIA lists? The workflow starts with the GDPR baseline, then queries the official national source named for each confirmed jurisdiction. A result records the publisher, source status, citation, verification context, and whether the supplied facts match a documented criterion. Which European jurisdictions are operational? 29 of the 32 jurisdictions in this program have an operational evidence path. Luxembourg, Malta, and Slovakia remain unavailable for reproduction while authority reuse permission or its legal basis is pending. What happens when authority material is advisory or draft? The result keeps that status. Indicative guidance and an advisory draft are not presented as adopted mandatory lists, and a reviewer sees the qualification beside any surfaced criterion. What happens when Ansvar cannot legally reproduce a source? The workflow records the national source as unavailable. It does not reconstruct the source from model memory or substitute generic GDPR guidance without saying so. Does Ansvar replace the controller or DPO? No. Ansvar assembles cited evidence and applies the documented workflow gates. The controller and DPO own applicability, professional judgment, risk acceptance, and approval. Can the same processing activity be screened across multiple countries? Yes, once the user or DPO confirms the jurisdictions to assess. The output keeps a separate evidence receipt for each jurisdiction instead of collapsing national sources into one generic result. Can the DPIA be grounded in our RoPA, contracts, and policies? Team and Company can bind supported workflow findings to customer documents with paragraph-level citations. The pricing page states the document and audit-receipt boundaries for each plan. --- ## 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. Limits Every limit, published. These are the quotas and rates the gateway enforces, per plan. Past a limit you get a readable refusal: your plan, your usage, the reset time and the next step. Never a thinner answer dressed up as a full one. Free Solo Premium Team Company Calls Searches a day search-class tools; one question is one call, whatever it fans out to; per seat, or pooled per organisation from Team 100 per seat 750 per seat 5,000 per seat 50,000 pooled 500,000+ pooled, by contract Provision, recital and citation reads a day lookup-class tools; five times the search budget, except Free where these three read tools share 200 200 3,750 25,000 250,000 2,500,000 Change feeds a day 25 3,750 25,000 250,000 2,500,000 Concurrent calls current implementation; the decided target for paid plans is eight, with machine-readable retry guidance 3 4 5 16 64 Requests a minute, with burst abuse protection, set so legitimate use never hits it 60 · 100 120 · 200 600 · 1,000 1,200 · 2,000 2,400 · 4,000 Assessments Runs a month calendar month, UTC; notices at 50% and 80%; a failed create is refunded 1, shared pool, watermarked 2, shared pool, watermarked 5 on a described system 20 per seat, pooled, then €35 a run 100 included, more by contract Hard ceiling runs past the allowance the allowance the allowance 3× the allowance, never billed 3× the allowance, overage billed contractual Shared pool the Free and Solo assessment allowance is served from one monthly pool across all accounts; when the pool is spent a run is refused with its reset date, never served thinner. From Premium the runs are your own. shared shared your own your own your own Documents and workspace Documents 50 MB per upload; cited by paragraph; the per-workspace count is a policy limit until the counter ships in the next gateway release no no no yes, 500 documents yes, 5,000 documents Architecture components self-hosted; the workspace licence sets no component ceiling; the 30-day evaluation turns read-only on expiry evaluation, self-hosted evaluation, self-hosted evaluation, self-hosted 1 licence, unlimited 5 licences, unlimited Service credentials minting starts at Premium; on Premium each credential takes a seat, counted with people; on Team five per workspace take no seat and each further one takes a seat; listing and revoking work on every plan no no; the seat may be an agent yes, each on a seat 5 included, then on a seat by contract This page follows the gateway's served configuration. If you find a number here that a refusal contradicts, the refusal is right and this page is wrong; tell us and we fix the page. Report a mismatch Worked totals What a workspace costs at volume The runs row above is an allowance, not a ceiling. Each seat adds twenty runs to the pool; past the pooled allowance a run is €35, and the hard stop refuses rather than bills. Seats and runs in the month Past the allowance What the workspace pays 1 seat , 20 runs none €490 1 seat , 40 runs 20 × €35 €1,190 3 seats , 60 runs none €1,470 3 seats , 100 runs 40 × €35 €2,870 3 seats , 180 runs , the hard stop 120 × €35 €5,670 Each seat is a person or an agent credential, and five service credentials come with the workspace without taking a seat. Each seat adds twenty runs to the pool, and the hard stop is three times the pooled allowance. Monthly, before the standards add-on and VAT. What a refusal looks like Readable, actionable, never silent. { "error": "quota_exceeded", "tool": "search", "tier": "free", "used": 100, "allowance": 100, "resets_at": "2026-09-21T00:00:00Z", "next": "Solo reaches every jurisdiction with 750 searches a day: https://ansvar.eu/pricing#solo" } Pick the plan that fits the workload. A seat is a seat, whether a person or an agent holds it. See plans Quickstart --- ## 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 "Using Ansvar, 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 39 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. Der Anbieter-Vergleich für DSGVO und KI-VO stellt die vier Lösungskategorien gegenüber. 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 "Using Ansvar, 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 39 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 39 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. --- ## 面向欧洲市场的产品安全与合规评估 · Ansvar AI URL: https://ansvar.eu/zh-cn Ansvar 帮助中国机器人、汽车及联网产品团队评估欧洲市场要求，在同一次评审中引用欧盟法规与中国国家法律原文，开展风险评估与合规差距分析。 中国企业 · 欧洲市场 面向欧洲市场的 产品安全与合规评估 为机器人、汽车及联网产品团队评估欧洲市场要求、分析安全风险。在同一次评审中引用欧盟法规与中国国家法律原文，逐条核查依据，标明待核实事项。 本页为简体中文介绍。标注“英文”的链接将打开英文页面；您可以使用浏览器的翻译功能辅助阅读。套餐、服务条款及法律引用请核对原文，如有疑问请联系我们。 预约演示 了解评估服务 瑞典团队 · 来源可核查 · 由您的团队评审确认 从您的产品出发 把要求、风险和证据放进同一次评审 先确认产品用途、目标市场和系统边界，再确定评估方法与资料范围。 产品安全评估 从架构、数据流和信任边界开始，开展威胁建模，记录风险、缓解措施和需要工程师确认的问题。 查看威胁建模工作流（英文） 汽车与机器人风险分析 通过威胁分析与风险评估（TARA），梳理资产、攻击路径和风险处置，并关联服务范围内的行业资料。 查看 TARA 工作流（英文） 合规差距分析 结合欧盟法规、中国国家法律，以及机器人和机械安全的标准条款索引，逐项整理现有证据、缺口和整改建议。ISO 条款正文取决于具体标准的授权与订阅。 查看差距分析工作流（英文） 欧盟法规 产品进入欧盟，先看这几部法规 以下法规的正式文本可在评审中逐条检索并引用，来源为欧盟出版局 EUR-Lex。是否适用，取决于产品类型、预期用途和上市时间，需要按产品单独判断。 机械法规 (EU) 2023/1230 机械及相关产品的基本健康与安全要求，包括附件三第 1.1.9 条（Protection against corruption，防止对安全功能的篡改）和控制系统安全条款。自 2027 年 1 月 20 日起适用。 机械法规说明（英文） 网络韧性法案 (EU) 2024/2847 含数字元素产品的网络安全要求与漏洞处理义务，包括软件物料清单、支持期和两个报告时限。第 14 条的报告义务自 2026 年 9 月 11 日起适用，法案整体自 2027 年 12 月 11 日起适用。 网络韧性法案说明（英文） 人工智能法案与 GDPR 产品含 AI 组件或处理个人数据时，这两部法规与产品安全法规并行适用，各自的义务需要分别评估，不能相互替代。 GDPR 说明（英文） 机器人与机械安全标准（ISO 10218、ISO 3691-4、ISO 13849、IEC 62061 等）在服务中以条款索引和 Ansvar 编写的说明呈现，用于定位相关条款并连接到对应的欧盟法规要求；标准正文不包含在内，须向标准组织另行获取授权。协调标准可推定符合基本要求，但采用与否由制造商自行决定。 评审有据可查 欧盟法规与中国国家法律，同一次评审，分别核查 将 Ansvar 接入您使用的 AI 客户端，让评审从原文出发。例如，机器人团队可以分别核查欧洲和中国业务中的个人信息安全要求，再整理需要工程师提供的证据。 核查来源发布者及原文链接 区分事实依据与分析判断 保留缺失证据和待核实事项 阅读完整报告示例（英文） 机器人操作员日志 资料对照示例 欧盟 / GDPR 第 32 条 根据风险确定适当的技术和组织措施，并考虑加密、系统韧性及措施有效性测试等事项。 查看 EUR-Lex 原文（欧盟出版局） 中国 /《个人信息保护法》第五十一条 结合处理活动和安全风险，落实内部制度、分类管理、安全技术措施、操作权限、人员培训及应急预案等要求。 查看国家法律法规数据库原文（全国人大常委会） 需要团队提供的证据 例如访问权限记录、加密方案、培训记录和安全测试结果。分别确认每项要求的适用条件与证据缺口。 以上为 Ansvar 编写的条文摘要，来源于已核查的原文；不是官方译文或完整要求清单。示例假设两地业务分别处理日志，不判断数据跨境传输，也不表示两部法律的要求相同。 中国法律条文为非官方复制件，请以颁布机关的记录为准；数据库文本与相应纸质文本不一致的，以纸质文本为准。 连接后，试着这样问您的 AI 复制下面的请求，在已连接 Ansvar 的 AI 客户端中使用。每条都以 “Using Ansvar” 开头：不加这一句，AI 客户端会直接凭训练数据作答，不会检索来源，也不会给出可核查的引用。 Using Ansvar, 我们的机器人业务分别在欧盟和中国处理操作员日志。请分别检索 GDPR 第 32 条和《中华人民共和国个人信息保护法》第五十一条，保留来源原文、发布者和原文链接；逐项整理安全措施要求、需要我们提供的证据和待核实事项。先询问适用性判断所需的业务信息，不预设两部法律的要求等同。 Using Ansvar, 我们的协作机器人计划在欧盟上市。请检索机械法规 (EU) 2023/1230 附件三中与控制系统安全和防篡改相关的基本要求，以及网络韧性法案 (EU) 2024/2847 的漏洞处理义务，保留每条的来源原文、发布者和链接；分别列出适用条件、需要我们准备的证据，以及你无法从来源确认的事项。 查看中国资料范围（英文） 评估 Ansvar 是否适合您的团队（英文） 查看上线记录（英文） 合作方式 从一个具体项目开始 01 告诉我们您的目标 介绍产品、目标市场和当前需要完成的评审。初次联系只需提供项目概况。 02 确认范围与交付方式 一起确认资料覆盖、接入方式、工作语言和交付内容。您可使用支持的 AI 客户端，也可讨论由 Ansvar 团队执行评估。 03 评审结果并安排后续工作 核查报告中的证据、差距和建议，由您的团队确认结论并安排整改。 常见问题 开始前，先了解这些 Ansvar 适合哪些团队？ 我们面向需要准备欧洲市场合规材料的产品、安全、工程和法务团队。您可以从一个具体项目开始，例如汽车零部件的威胁分析、联网产品的安全评估，或机器人系统的风险评审。我们会先确认所需的工作流和资料是否在服务范围内。 可以在中国大陆使用吗？ 使用前需要确认您所在地区的网络访问情况、所选 AI 客户端的服务地区及其条款。请先联系我们，说明团队所在地和计划使用的工具；我们会与您确认接入方式，也可以讨论由 Ansvar 团队执行评估的交付方式。 页面是中文，产品和交付也都是中文吗？ 此页面提供简体中文介绍。产品界面、文档和本站其他页面目前主要使用英语。演示、沟通和报告的语言安排需要在项目开始前确认。引用保留来源原文；译文不作为官方法律文本。 目前包含哪些中国法律和标准？ 目前提供国家法律法规数据库中的全国人大及其常委会法律、法规性决定和国务院行政法规，保留中文原文。地方性法规、司法解释和部门规章尚未提供。中国 GB 和 GB/T 标准全文不在服务范围内，也不将中国标准与 ISO 标准视为自动等同。机器人及机械安全的标准条款索引与专家分析会分别标明；ISO 条款正文须按具体标准另行确认授权和订阅。 欧盟法规原文和中国法律都包含在同一个套餐里吗？ 不是。中国国家法律可在免费套餐中检索。欧盟法规原文（GDPR、机械法规、网络韧性法案、人工智能法案等）属于付费套餐，文档上传等功能需要更高套餐。具体范围请查看本站的套餐与价格页面（英文，见页脚链接），或在联系我们时说明需要检索的资料。 欧洲企业想了解在中国的要求，也适用吗？ 可以检索同一批中国国家法律原文，判断逻辑相同。需要注意范围上限：地方性法规、司法解释和部门规章尚未提供，因此涉及地方执行口径或司法适用的问题，不能仅凭本服务得出结论。本站英文页面面向这一方向的团队提供更完整的说明。 Ansvar 的报告可以替代认证吗？ Ansvar 帮助团队准备评估和评审材料，不颁发认证，也不保证产品获准上市。您的团队及相关专业人员仍需确认适用要求、完成必要的测试，并作出最终决定。 联系 Ansvar 聊聊您的产品和评审目标 请在邮件中介绍产品类型、目标市场和希望完成的评估。我们会与您确认范围和下一步安排。 发送演示咨询 也可直接发送邮件至 team@ansvar.eu --- ## 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 "Using Ansvar, 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 39 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. --- ## Let your AI evaluate Ansvar · Ansvar AI URL: https://ansvar.eu/evaluate Copy one evaluation pack into your AI client. It interviews you, checks your needs against Ansvar's audited coverage, and gives an honest fit verdict. Evaluate Let your AI decide whether Ansvar fits . Copy one evaluation pack into the AI client your team already uses — Claude, ChatGPT, Copilot, Gemini, or any other. Your agent asks you four questions, checks your jurisdictions and frameworks against our audited coverage snapshot, and gives you a verdict. No account, no browsing required, and nothing you answer is sent to us. Fair warning, stated in the pack itself: we wrote it, so it is vendor-authored evidence, not an independent assessment. The pack binds your agent to claims from the embedded snapshot only — and requires it to say no current fit , and to recommend against signing up, when your non-negotiables are not covered. Copy evaluation pack Download as Markdown Also served at /agent-evaluation.md for agents that can fetch URLs. Pack format v 1 , coverage snapshot 2026-10-23 ; each pack carries a content fingerprint identifying its exact text. The pack, in full What you copy is exactly what you see here — no hidden instructions. Using Ansvar, assess whether Ansvar is a current fit for my organisation, using only the vendor-authored evidence in this pack. ## About this pack - Authored by Ansvar Systems AB (https://ansvar.eu). This is vendor-authored evidence, not an independent assessment — weigh it accordingly. - Pack format version 1. Coverage snapshot generated 2026-10-23. The content fingerprint on the last line identifies the exact text you are evaluating — quote both in the report. - Canonical copies: https://ansvar.eu/agent-evaluation.md and https://ansvar.eu/agent-evaluation-v1.md (format v1; both regenerate as coverage moves). - The interview below stays in this conversation. Nothing is sent to Ansvar unless the user later chooses to connect. ## What Ansvar is Ansvar is an MCP gateway (gateway.ansvar.eu, OAuth 2.1) that connects the AI client an organisation already uses — Claude, ChatGPT, Copilot, Gemini, Cursor, or any MCP-capable agent — to audited legal, regulatory, and security sources. Answers cite the served official text; where no verified source exists, the gateway reports the gap instead of guessing. EU-hosted, no server-side model, no training on customer data. ## Step 1 — interview Ask the user these four questions, then continue. Collect categories and constraints only — do not ask for confidential architecture, incident details, customer names, or internal documents. 1. In which markets or jurisdictions must your organisation comply? Name the countries, and whether EU-level law applies. 2. Which regulations, frameworks, or standards are in play — for example GDPR, NIS2, DORA, CRA, the EU AI Act, ISO/IEC 27001? 3. Which AI clients does your team use, on which plans, and with which enterprise restrictions (browsing disabled, connector allowlists, MCP support)? 4. What should your agents do with a source layer — answer compliance questions, run threat models, DPIAs, or gap analyses, review documents, triage vulnerabilities? ## Step 2 — evidence rules - Coverage claims in your report may come ONLY from the snapshot below. Do not supplement from your own knowledge of Ansvar or from anywhere else. - If something the user needs is not in the snapshot, treat it as "not listed in this snapshot" — not as absent from the product, and not as present. - Plan and price claims may come only from the plan facts below. ## Evidence snapshot (generated 2026-10-23) Live jurisdictions (39): DK Denmark · SE Sweden · FI Finland · NO Norway · IS Iceland · AT Austria · DE Germany · BE Belgium · LU Luxembourg · NL Netherlands · ES Spain · PT Portugal · FR France · IT Italy · SM San Marino · MT Malta · CZ Czechia · SK Slovakia · HR Croatia · HU Hungary · PL Poland · SI Slovenia · LT Lithuania · LV Latvia · EE Estonia · RO Romania · AL Albania · BG Bulgaria · XK Kosovo · RS Serbia · IE Ireland · LI Liechtenstein · GB United Kingdom · CA Canada · US United States · JP Japan · KR South Korea · CN China · UA Ukraine Jurisdiction scope limits (apply these before judging fit): - CN China: Chinese national law from flk.npc.gov.cn and reviewed CAC/MIIT automotive, data, IT and AI original publications, with Chinese source text and Ansvar-authored English discovery metadata. Ministry current validity and consolidation are unasserted. Wider NPC departmental, local-regulation and judicial-interpretation layers remain held. GB/GB-T standard body text is excluded; catalogue metadata does not establish Chinese market approval or equivalence with ISO standards. In development — NOT yet live (3): CH Switzerland · CY Cyprus · GR Greece Frameworks with dedicated coverage (40): GDPR · NIS2 · DORA · MiCA · PSD2 · EU AI Act · CRA · MDR · IVDR · Machinery Regulation · RMI — Repair & Maintenance Information · UN R155 · UN R156 · CSRD · EUDR · EAA · AMLR · AMLD6 · IRRD · Solvency II · RED · GPSR · PLD · UAS Product Rules — 2019/945 · UAS Operations — 2019/947 · HIPAA · CCPA/CPRA + state privacy · NYDFS Part 500 · GLBA Safeguards Rule · SEC cybersecurity disclosure · COPPA · CMMC · NIST CSF 2.0 · NIST SP 800-53 Rev 5 · NIST AI RMF · NIST SSDF (SP 800-218) · NIST SP 800-82r3 (OT) · FAR · ITAR · EAR EU-level coverage: 19 corpora across eu-regulations, statute-law, case-law, cybersecurity, sector-regulators. Vulnerability intelligence: CVE lookup, CISA KEV status, EPSS scores, public exploit references — live feeds; OpenVEX export from the Team plan. Workflows: STRIDE threat model, gap analysis (generic plus NIS2, DORA, CRA, and EU AI Act variants), and DPIA are startable on every plan within its monthly run allowance; the interview-grounded catalog (LINDDUN, TARA variants, FRIA, and more) starts at Premium; running workflows on the organisation's own documents starts at Team. The authoritative live list is the `list_workflow_types` tool after connecting. Plans: - Free — €0/month: 100 search calls / day; One scope per search — a single jurisdiction, framework, or source; National legislation in any live jurisdiction; 1 workflow run / month (watermarked report); Self-serve sign-up — Google, Microsoft, or email. - Solo — €29/month: Full-fleet fan-out — every live jurisdiction in one question; 750 searches / day; 2 workflow runs / month (watermarked report); No legal evidence layer (case law and guidance stay Premium+). - Premium — €249/month: Multi-jurisdiction fan-out; Case law (where premium tools available); Preparatory works; Authority guidance; 5,000 searches / seat / day — 50× the free quota; Full interview-grounded workflow catalog, 5 runs / month; Self-serve signup. - Team — €490/seat/month: Everything in Premium; Workflows on your own uploaded documents; 20 workflow runs / seat / month; Org-owned service credentials for headless agents. - Company — custom: Team surface plus per-tenant audit ledger; Org-scale quota; Via talk-to-sales. Client integration: any MCP-capable client connects over OAuth 2.1 with dynamic client registration. Per-client setup guides: https://ansvar.eu/setup. ## Step 3 — report Produce a report with exactly one verdict: **documented fit**, **conditional fit**, **no current fit**, or **insufficient evidence**. No numeric scores. Assess four areas, each in its own short section: - Content fit — the user's jurisdictions and frameworks against the snapshot. One missing non-negotiable jurisdiction or framework outweighs any number of adjacent matches. - Task fit — what their agents should do, against the searches and workflows above. - Integration fit — their clients, plans, and restrictions, against the MCP requirement. - Operating fit — hosting, data handling, and procurement constraints the user named. The snapshot answers EU hosting, no server-side model, and no training on customer data; anything else goes to unknowns. Close with an **Unknowns** list, and label the whole report: "Pre-auth assessment from vendor documentation dated 2026-10-23; live tool availability not verified." Binding rules for the verdict: - On **no current fit**: name the unmet requirement and its disposition per the snapshot — listed as in development (not yet live), or not listed at all (the snapshot does not claim to be exhaustive). Give the snapshot date, recommend against signing up for this use case, and do not offer adjacent coverage as a substitute. An in-development listing may be worth a re-check later; say so without softening the verdict. - On **insufficient evidence**: name what is missing and stop. Do not guess. - Never state a coverage, plan, tool, or price claim that is not in this pack. ## Step 4 — next step Only on documented fit or conditional fit: the free verification path is to connect the gateway on the Free plan (https://ansvar.eu/setup, self-serve sign-up), run the guided tour by calling `describe_capabilities` with section='tour', and re-check the specific coverage this report leaned on with live calls. One free workflow run per month produces a watermarked sample deliverable. On no current fit: no next step. Reassess only if Ansvar's coverage changes. Content fingerprint: 30b0fe0da45f1448 If the verdict is a fit The report ends with the free verification path: connect the gateway on the Free plan and re-check the coverage it leaned on with live calls — the pack is documentation, the connection is proof. Connect a client See plans --- ## 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 Commission a senior-reviewed threat model, DPIA, gap analysis, or AI Act assessment with cited evidence, explicit limits, and a fixed scope agreed up front. Services Get the assessment your decision requires. Commission a threat model, DPIA, gap analysis, or AI Act assessment. We retrieve the evidence through the same governed gateway used by the product, and a senior practitioner reviews the material findings, judgments, and limits before delivery. Book a scoping call Read a full sample assessment Fixed scope · quote and date after a 30-minute call. Why teams call us Start with the decision that is due. An audit is scheduled, a rule starts applying, or a customer asks for evidence. Choose the situation closest to yours and inspect the deliverable we produce. The auditor asked for a threat model ISO 27001 surveillance, SOC 2, or a customer audit expects a documented analysis of threats, trust boundaries, and mitigations. Threat model → The review must cover the design The scope covers trust boundaries, data flows, exposed components, attacker paths, and design mitigations. Threat model → DORA or NIS2 landed on you ICT-risk duties require evidence against the applicable provisions and technical standards. 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 Different deliverables. One evidence discipline. Each engagement links factual findings to the provision, technique, control, or customer evidence that supports them. Missing support remains visible in the delivered assessment. 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 → — a fictional AI Act assessment worked through the full method; senior review is pending. 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 → — a fictional worked sample in the report format; senior review is pending. 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 fictional Article 35 DPIA worked through the full method; senior review is pending. 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 fictional NIS2 gap analysis worked through the full method; senior review is pending. Scope a gap analysis How an engagement runs Fixed scope, priced per engagement. A one-framework check and an estate-wide assessment require different scopes. The scoping call ends with a fixed price and delivery date in writing. 1 Scoping call 30 minutes. We define the decision, evidence, review standard, price, and delivery date. 2 Intake Under your NDA, through EU-hosted upload. You provide the architecture, processing records, policies, and other agreed evidence. 3 Assessment We retrieve served sources through the Ansvar gateway and record the evidence used for each material factual finding. 4 Senior review A practitioner checks citations, judgments, missing support, and the result before approving the deliverable. 5 Readout A walkthrough of the findings, then the deliverable and its evidence pack are yours to keep. The quality contract The reviewer can inspect the evidence behind each finding. Every engagement follows the same review contract, regardless of the assessment method. 01 Evidence-linked Factual findings link to evidence retrieved through the Ansvar gateway or to the customer material supplied for the engagement. A citation identifier is checked before it is used. 02 Expert-validated A senior practitioner checks the material findings, citations, judgments, and stated limits before approving the deliverable. 03 Refusal discipline When a required source is unavailable or the evidence does not establish a conclusion, the report records the limitation instead of presenting the claim as established. Evidence metadata included. The delivery package identifies the sources, validation state, and provenance behind the findings for your 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 another scoped assessment. We reply within two working days with an initial view on fit. Book a scoping call Prefer self-serve? See Team --- ## 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. Legal Privacy Notice Last updated: 7 October 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. The Services also retrieve official publications of public bodies, and some of them name people; section 4 explains how we handle that. 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. When you choose English or Simplified Chinese using our language controls, we save that choice in your browser's local storage under ansvar-site-language . The value is only en or zh-CN ; we do not send it to our servers or third parties. We use it to show or dismiss the Chinese-page suggestion on the homepage. You can change it using the language controls or remove it by clearing this site's browser storage. Without a saved choice, the homepage checks your preferred browser language locally to decide whether to offer the Chinese introduction. If we introduce other cookies or similar technologies, we will obtain 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. When your name appears in an official publication we serve The Services retrieve official publications of public bodies: legislation, regulations, court decisions, regulator and agency decisions, official gazettes and public procurement notices. Some of these publications name people, for example officials acting in their role, parties named by the publisher, or sole traders named in a tender award. We obtain these publications from the public body that publishes them, not from you. We base this processing on our legitimate interest in providing legal, compliance and procurement research from official sources (Article 6(1)(f) GDPR). We screen these sources for personal data under a written procedure. We do not serve the personal data of a private person once we have confirmed it; we withhold or redact it and report the finding to the publisher. We do not profile individuals or rank results by a person's name. We keep the publisher's original files in a closed archive so that we can show what we received, and when we withhold personal data, or you ask us to delete it, we delete it from every copy, the archive included. Because these publications can name very many people, we do not contact each person individually (Article 14(5)(b) GDPR); this section is how we inform you. You can exercise your rights under section 8, including the right to object, by writing to privacy@ansvar.eu . 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. Legal Terms of Service Last updated: 30 August 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. The Service serves publicly available official publications of public bodies — legislation, regulations, court decisions, and regulator guidance — and each output cites the publisher and links to the source. Such publications, including material published by the European Central Bank and the parliamentary documents of the German Bundestag and Bundesrat, may be obtained free of charge from the publisher’s own website (for the European Central Bank: www.ecb.europa.eu and www.bankingsupervision.europa.eu ; for the German parliamentary documents: DIP, https://dip.bundestag.de ). The Fees are consideration for the Service, not for the underlying publications. 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. Switching, Portability, and Consequences of Termination The Customer may instruct Ansvar in writing to switch the Customer to another provider of data processing services, move the Customer's exportable data and digital assets to infrastructure controlled by the Customer, erase them, or use the Service in parallel with another provider. The Customer may authorise a destination or additional provider to use the export interfaces for switching or parallel use despite the third-party access restrictions elsewhere in the Agreement, after that provider completes Ansvar's reasonable identity and security checks. Ansvar will cooperate in good faith with the Customer and each authorised destination or additional provider to make the switching process effective, enable timely data transfer, and maintain service continuity. Parallel use does not terminate the Agreement. The mutual notice period in Section 5 is the notice period for initiating a terminating switching process and does not exceed two months. Ansvar will complete the switching process within a maximum transitional period of 30 calendar days after the notice period ends. During that period Ansvar will provide reasonable assistance, maintain continuity of the functions and services under the Agreement, maintain a high level of security, and give the Customer available information about known continuity risks. Ansvar will support the Customer's exit strategy and will notify the Customer when the switch has completed. Unless the Customer selected parallel use, the Agreement is considered terminated on successful completion of a switch to another provider or to Customer-controlled infrastructure. If the Customer selects erasure without a switch, Ansvar will fully erase the exportable data and digital assets when the notice period ends; the Agreement is considered terminated at that point, and Ansvar will notify the Customer of the erasure and termination. The Customer may extend the transitional period once for a period that the Customer considers appropriate for its own purposes. If Ansvar determines that the 30-day transitional period is technically unfeasible, Ansvar will notify the Customer within 14 working days after receiving the switching instruction, explain the technical reason, and state an alternative period that does not exceed seven months. Ansvar will maintain service continuity during the alternative period. For parallel use, Ansvar acts with due care to maintain business continuity, continues all functions and services under the Agreement, and maintains a high level of security throughout each export and data transfer. Parallel use does not require the termination notice or transitional period. The following list is the complete specification of Customer data and digital assets available for switching, to the extent Ansvar holds them for the Customer at completion of the switching process: organisation, account, seat, role, entitlement, subscription, billing, and retained usage records uploaded files and inline text, document-library metadata, customer-specific extracted text and segments, and customer-specific citation metadata workflow records, including scope inputs, responses, evidence bindings, state, findings, and generated reports or other deliverables stored gateway interaction and audit-ledger records, receipts, anchors, and verification data where the Customer's Tier includes those records, and tenant-specific settings, access-control assignments, and connector or source configuration created for the Customer, excluding authentication secrets and cryptographic key material The following list is the complete specification of provider-internal data categories excluded from export because they contain Ansvar or third-party intellectual property or trade secrets, their export would compromise service security or integrity, or they do not relate to the Customer: Ansvar source code, binaries, build and deployment configuration, credentials, cryptographic keys, and security or anti-abuse rules cross-tenant operational logs, fraud and threat detections, and incident-investigation material whose export would expose security controls, except for Customer-specific records included in the exportable categories above proprietary routing, scoring, evaluation, and risk models, internal annotations, and source-ingestion methods shared legal and regulatory corpora, standards, indexes, caches, and other Ansvar or third-party licensed content, except for Customer-specific outputs retained in a workflow, deliverable, or audit record aggregated or anonymised service metrics that do not relate to an identified Customer, and data belonging to another customer or third party Ansvar will not apply these exclusions in a way that impedes or delays the Customer's switching process. Ansvar provides the switching process, data egress, export interfaces, and assistance required by this Section without a switching charge. Ansvar has no standard early-termination penalty. The standard service fees appear on the pricing page and in the Customer's order. A fixed-term or committed order may require payment of committed fees only where the order identifies that obligation before signature. The Parties may agree a fee in advance for migration, transformation, or professional services that the Customer requests beyond the switching assistance required by this Section. After a successful switch, Ansvar will keep the exportable data and digital assets available for retrieval for at least 30 calendar days after the transitional period and maintain a high level of security throughout that retrieval period. At the end of that period, Ansvar will fully erase them from systems under its control, including active systems, retrieval storage, and tenant copies in backups. Ansvar stops creating backup copies containing the terminated Customer's data when live processing ends; current backup protection expires within the retrieval period, allowing the remaining copies to be erased when that period ends. Ansvar may retain a record only where Union or Member State law requires retention, and will isolate that record from further use except for the required purpose. The DPA governs the return and erasure of Personal Data and prevails if it gives the Customer a stronger right. Ansvar publishes the current switching procedures, interfaces, formats, restrictions, infrastructure jurisdictions, and safeguards against conflicting third-country governmental access in the Service Portability Register . That URL forms part of the Agreement. When the Agreement terminates, the Customer's right to use the Service ends after any applicable transitional period. The Customer may retain Customer Deliverables created during the Term for its records. A Permitted Recipient may retain a Customer Deliverable supplied before termination for record-keeping and archival purposes, subject to the surviving restrictions in Sections 8a, 12, and 14. The Customer remains liable for fees accrued through termination and receives no refund unless the Agreement states otherwise. 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, or delayed support. It does not extend a mandatory switching or retrieval deadline where applicable law bars that extension. 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 --- ## Service Portability Register · Ansvar AI URL: https://ansvar.eu/service-portability Ansvar service switching procedures, exportable data, interfaces, formats, fees, infrastructure jurisdictions, and safeguards for non-personal data. Legal Service Portability Register Last reviewed: 30 August 2026 This page is the online register referenced by Section 16 of the Terms of Service . It describes the current switching and portability surface for the Ansvar Service under Chapter VI of Regulation (EU) 2023/2854 . Contact legal@ansvar.eu to start a switch, request an export bundle, nominate a destination provider, move to Customer-controlled infrastructure, or request erasure. 1. Switching procedure The Customer sends a written instruction that selects another provider, Customer-controlled infrastructure, erasure, or parallel use and identifies any authorised destination or additional provider. Ansvar confirms the Customer's authority, the requested scope, the available self-service exports, and any security steps for a destination provider. For a terminating switch or erasure request, the 30-day notice period under Section 5 of the Terms runs. For parallel use, no termination notice or transitional period applies; Ansvar confirms the requested scope and export channel. Ansvar supplies the exportable data and digital assets. During a terminating switch or parallel-use transfer, Ansvar continues all contracted functions and services and maintains a high level of security. For a terminating switch, the Customer or destination provider confirms retrieval and Ansvar reports successful switching and termination; Ansvar erases the data after the retrieval period. For erasure without a switch, Ansvar fully erases the exportable data and digital assets when the notice period ends and reports erasure and termination then. Parallel use leaves the Agreement in force. Ansvar will provide the information needed to plan the exit before the Customer gives notice. A Customer may test the documented export interfaces during the Term without starting a switch. The Customer may also request repeat exports for parallel use without terminating the Agreement. 2. Data structures, formats, and interfaces Data or digital asset Current interface or method Export format Organisation, seats, roles, entitlements, subscription, billing, and usage Account area plus a provider-assisted switching bundle delivered through an authenticated, time-limited HTTPS download JSON; CSV for tabular records; PDF for issued invoices Uploaded documents and document metadata Document-library list; provider-assisted original-file and segment export in the switching bundle Original file format; JSON metadata; UTF-8 text and JSON for extracted segments Workflow state, inputs, responses, findings, and evidence bindings MCP workflow tools and provider-assisted switching bundle over HTTPS JSON Generated workflow reports generate_report through the MCP interface JSON; HTML, PDF, and DOCX where the Customer's Tier includes rendered reports Audit-ledger receipts, anchors, signatures, timestamps, and retained interaction content list_receipts and export_audit_package through MCP, or account-area export; available where the Customer's Tier includes the audit ledger JSON, with encrypted receipt envelopes by default and optional authorised plaintext Tenant settings, access assignments, and Customer-created connector or source configuration Provider-assisted switching bundle over HTTPS JSON; secrets and private cryptographic keys are omitted and must be replaced at the destination Provider-assisted records are delivered as a ZIP bundle containing export.json and the binary files named by its manifest. The complete field-level JSON Schema is published as switch-export-v1.schema.json . The schema covers the organisation, users, seats, entitlements, subscriptions, billing and usage records, documents and segments, workflows, reports, audit records, tenant settings, access assignments, connectors, sources, and the file manifest. A conforming non-production specimen is published as switch-export-v1.example.json . Fields absent from a Customer's Tier or history are represented by empty arrays or null values, not undocumented structures. The Customer-facing machine interface uses the Model Context Protocol over HTTPS with OAuth 2.1 or a managed service credential. Tool inputs and outputs use JSON-compatible structures. Ansvar makes the same export interfaces and documentation available to the Customer and its authorised destination or additional provider on equal terms. The switching-bundle interface uses standard HTTPS GET with a time-limited bearer URL after Customer and destination-provider identity checks; it requires no proprietary client. During switching or parallel use, Ansvar reissues the bundle after Customer-authenticated requests without charge. The connection guide and the tool schemas exposed by the MCP endpoint describe the current interface. Ansvar does not charge the Customer or its authorised destination or additional provider to use these interfaces for switching or parallel use. The relevant open interface specifications for the current Service are the Model Context Protocol specification , OAuth 2.1, HTTPS, and JSON. Ansvar will add an applicable harmonised standard or open interoperability specification published under the Data Act to this register and implement the required compatibility within the period set by law. 3. Restrictions and limits The Customer or destination provider must authenticate, protect export links and credentials, and provide a destination that can receive the selected formats. Short-lived document and report download links expire and can be reissued during the retrieval period. Ansvar exports data that it holds through completion of the switch, including input, output, and metadata generated during the notice and transitional periods. The Gateway does not retain ordinary query results unless a workflow, document record, or the Customer's audit-ledger Tier stores them. Ansvar does not promise functional equivalence between the Service and a destination service. The export omits the provider-internal categories listed in Section 16 of the Terms. Mandatory switching assistance is free. A separate written agreement may cover Customer-requested transformation or professional services outside that assistance. Ansvar has identified no switching process for the current Service that is highly complex or costly. Ansvar charges no switching or data-egress fee and has no standard early-termination penalty. Standard service fees appear on the pricing page ; an order identifies any fixed-term commitment before signature. 4. Infrastructure jurisdictions Function Jurisdiction or routing posture Primary Gateway, account, workflow, document, and audit-ledger processing Finland, in Hetzner's Helsinki region Off-site object storage and backups Germany (Hetzner Falkenstein), France (Scaleway fr-par), and Ireland (Microsoft Azure North Europe); limited Microsoft support or telemetry access may occur from the United States Edge TLS and traffic protection Cloudflare EU edge with routing or processing that may occur in the United States 5. Safeguards against conflicting third-country governmental access Ansvar applies the following measures to non-personal data held in the Union: EEA primary hosting, encryption in transit and at rest, tenant isolation, least-privilege access, and access logging contracts and transfer terms with infrastructure providers, a reviewed sub-processor register, and data minimisation across providers legal review of each third-country request for authority, specificity, proportionality, and conflict with Union or applicable Member State law recognition or enforcement of a third-country court or authority decision only where an applicable international agreement provides the basis where no such agreement exists, separate review under Article 32(3) of Regulation (EU) 2023/2854: the third-country system must require stated reasons, proportionality, and a specific request; Ansvar must be able to raise a reasoned objection that a competent court or tribunal can review; and that court or tribunal must be empowered to consider the interests of the data provider protected by Union or applicable Member State law consultation with the competent national body where required, a reasoned objection or challenge where grounds exist, and disclosure limited to the minimum data permitted, and notice to the Customer before access or transfer unless law bars notice for the time needed to protect a law-enforcement activity Ansvar reviews this page when an interface, format, fee, infrastructure jurisdiction, or relevant legal measure changes. Send corrections or portability questions to 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. 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. 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), Microsoft Ireland Operations Limited (off-site backup storage, EEA), and Scaleway S.A.S. (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), Microsoft Ireland Operations Limited (off-site backup storage, EEA), and Scaleway S.A.S. (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). Legal Sub-processors Last updated: 3 September 2026 · This page is the authoritative current list of sub-processors engaged by Ansvar. Change log: 3 September 2026: Ansvar added Microsoft Power Platform for the workflow endpoint that delivers SRE Watch and log-review Teams cards. The service operated by 19 August within the existing Microsoft relationship; Ansvar published the per-service disclosure after a supplier review found the omission. 2 September 2026 — the Hetzner Online GmbH entry now itemises the expert-run engagement workspace document store (Helsinki, EEA): customer-uploaded engagement documents, deleted within 30 days of report delivery. The store has operated inside the disclosed Hetzner hosting engagement since 9 June 2026; Ansvar published the per-service disclosure late, on 2 September 2026, after an internal audit finding. 12 August 2026 — added Scaleway S.A.S. (Object Storage) as off-site backup storage: a daily add-only, write-once mirror of infrastructure backups in France (EEA), running alongside the existing Azure Blob mirror while backup storage migrates to Scaleway. The mirror has been in operation since 12 July 2026; this roster entry was published late, on 12 August 2026. 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 compute, private networking, load balancing, and volumes for prod-ansvar in hel1; Object storage for corpus delivery, database and recovery backups, security archives, and source mirrors; Object storage for expert-run engagement documents (bucket ansvar-engagements, hel1 — customer-uploaded architecture material and delivered reports; asset A-078; retention per ANSVAR-008 DP-P9); Storage Box retaining encrypted historical Borg archives from the retired compose plane; Cloud compute for the development/agent host, SIEM host, and ephemeral build runner 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); Finland (Helsinki) — engagement workspace object storage (bucket ansvar-engagements, hel1; deleted within 30 days of report delivery, 90-day lifecycle backstop); Finland (Helsinki) — development/agent host, SIEM host (security-log processing), and the ephemeral build runner None required — processing within the EEA Cloudflare, Inc. CDN and edge proxy for registered proxied hostnames; WAF controls available under the registered Free plan; DDoS protection; TLS termination; Rate limiting 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. Microsoft Ireland Operations Limited (Azure Blob Storage) Off-site backup storage (Azure Blob) — daily add-only write-once mirror of infrastructure backups incl. database backups 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) Microsoft 365 Productivity, email, and support tooling (Microsoft 365) 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 Microsoft Power Platform Power Platform workflow endpoint for SRE Watch and log-review Teams cards 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 Scaleway S.A.S. (TEM) Transactional email (platform + marketing website notifications) 8 rue de la Ville l'Évêque, 75008 Paris, France France (fr-par region) None required — processing within the EEA Scaleway S.A.S. (Object Storage) Off-site backup storage (Object Storage) — daily add-only write-once mirror of infrastructure backups incl. database backups (object lock) 8 rue de la Ville l'Évêque, 75008 Paris, France France (fr-par region, EEA) None required — processing within the EEA Stripe Gateway billing (Stripe Checkout); Subscription webhook -> Keycloak user provisioning 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) 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 Why it is not a sub-processor DigiCert, Inc. RFC-3161 trusted timestamping of the daily aggregate Merkle root imprint (audit-ledger integrity) 2801 North Thanksgiving Way, Suite 500, Lehi, UT 84043, United States Processes no Personal Data on Ansvar's behalf — receives the daily aggregate Merkle root imprint + RFC-3161 protocol metadata only, not reversible (DPA Annex 4 A4.8); reclassified from the roster 2026-07-27 with the reasoning on the page changelog 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 28 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 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. 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. 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 . --- ## Government and Law-Enforcement Requests · Ansvar AI URL: https://ansvar.eu/government-requests How Ansvar handles requests from courts, police, regulators and other authorities for customer data: verification, legal review, minimum scope, customer notice. Legal Government and Law-Enforcement Requests Last updated: 23 September 2026 This page summarises how Ansvar Systems AB ("Ansvar") handles a request from a court, a law-enforcement body, a regulator or another government authority for data we hold or control about our customers and their users. It covers requests from Sweden, from other EU countries and from countries outside the EU, including emergency requests. It describes the policy our CEO approved in August 2026. Our contractual commitments to you are in the Data Processing Addendum and the Terms of Service . Separate procedures handle content and copyright notices ( Notice & Complaints Procedure ), requests that individuals make in a private capacity about their own personal data ( Privacy Notice ) and our own incident notifications to authorities. If a government demand for data comes with a content notice, this page covers that demand. 1. Receiving and verifying a request Anyone at Ansvar who receives a request passes it to our CEO and security team at once, without answering on substance. Our staff do not acknowledge the substance of a request, confirm or deny that we hold data, search for responsive data, promise notice or disclose anything outside this process. Our security team keeps the original request and its delivery details, and verifies the requester's identity through an independent official channel. Contact details the requester supplies are not enough to verify identity. A verified identity does not by itself give a request legal force. 2. Legal review of each request Before we disclose anything, external legal counsel reviews the specific request: the instrument and the authority that issued it, jurisdiction, how it was served, whether it is enforceable, its scope, the applicable Swedish and EU law, the lawful basis under the GDPR, and any rules on transfers outside the EU. We do not treat a foreign court or authority decision as sufficient because it was served on us directly. Counsel considers Article 48 GDPR and any international agreement or EU mechanism that applies. We do not disclose data in response to a phone call, a voluntary questionnaire, an unsupported email or any other informal or unverified request. Our CEO, advised by counsel, decides whether to refuse such a request in writing, ask for clarification, or put it on hold. 3. Narrowing and challenging requests If a request appears unlawful, unauthenticated, outside the authority's jurisdiction, overbroad, disproportionate, or in conflict with privacy law or our duties to customers, our CEO and external counsel consider asking for clarification, narrowing the request, or challenging it. For third-country requests for non-personal data held in the EU, our Service Portability Register (section 5) also commits us to consult the competent national body where required and to raise a reasoned objection or challenge where grounds exist. Urgency does not make an invalid request valid. A request that claims an imminent risk to life or safety gets faster preservation, identity verification, counsel review and decision. It still goes through legal review, minimum scope, a recorded decision, secure transfer and our request records. If the law allows an emergency disclosure without the usual order, counsel identifies and records that specific legal authority before we release anything. 4. Who decides Our CEO decides whether to disclose, narrow, challenge or refuse, and whether to notify the customer, and records that decision before any data leaves Ansvar. If the CEO is unavailable, has a conflict of interest or is the subject of the request, our board appoints an independent decision-maker and records the appointment. 5. Disclosing the minimum If we disclose, we first establish which data we actually hold. We prepare only the named accounts, data categories and time range the request requires, and our CEO approves that final list. We send it to a verified recipient over a secure channel and keep evidence of what we sent, its integrity and its delivery. 6. Telling the affected customer If counsel confirms that notice is permitted and appropriate, we notify the affected customer before we disclose, with time to seek a remedy. If a binding legal prohibition prevents notice, we record its exact legal basis, scope, start, and its expiry or review trigger, and we review it at each management review and when that trigger occurs. Once counsel confirms the restriction no longer applies, we notify the customer promptly, unless another binding obligation prevents it. Two published commitments go further for specific data. For personal data we process on your behalf, the DPA (section "Assistance to the Controller") commits us to notify you promptly of any request, inquiry, audit, investigation or other regulatory action, including notice of intent, by a supervisory authority or governmental body relating to that processing, and to give you the relevant information reasonably available to us, unless applicable law prohibits it. For third-country governmental access to non-personal data held in the EU, the Service Portability Register commits us to notify you before access or transfer unless law bars notice for the time needed to protect a law-enforcement activity. 7. Records We record every request and its outcome, whether we disclosed, narrowed, challenged or refused, the authority withdrew it, or it is still pending. The record lists the categories and volumes of data disclosed. It does not copy the disclosed content. We keep each record for at least seven years after the request is closed, unless a legal or retention requirement sets a different period. 8. Transparency reporting At least once a year our CEO records a dated decision on whether we will publish an aggregate summary of requests, where the law permits one, based on reconciled records and current legal advice. Any summary will reconcile its counts to our records up to a stated date and will not reveal a request we are prohibited from disclosing. --- ## Connect Microsoft 365 · Ansvar AI docs URL: https://ansvar.eu/docs/setup/microsoft-365 Install the Ansvar agent in Microsoft Teams and M365 Copilot, sign in, and verify a cited answer. Connect Microsoft 365 Add the published Ansvar agent to Microsoft Teams or M365 Copilot and sign in with your Ansvar account. The agent uses the gateway to retrieve sources and return cited answers. You do not need to build an agent in Copilot Studio to use this listing. Before you start You need an Ansvar account and a Microsoft work account with access to the relevant Teams or M365 Copilot surface. Microsoft licensing and your tenant's app policies determine whether you can add and use the agent. Ansvar plan and add-on entitlements determine which Ansvar sources and tools your sign-in can reach. Install and sign in Open the Ansvar listing in the Microsoft Teams and M365 Copilot store with your work account. Follow the store's installation flow. If your organisation blocks the app or requires approval, give your tenant admin the listing link and ask them to allow it. Open the Ansvar agent in your available Microsoft chat surface. When prompted, sign in to Ansvar and complete the consent flow. Ask a question whose cited source you can inspect. Keep the conversation in the Ansvar agent when testing the connection. Verify the connection text Copy Using Ansvar, retrieve GDPR Article 5(1)(c). Cite the official source URL and identify the Ansvar source you queried. If retrieval fails, report the failure instead of answering from memory. Check the source link and article against the answer. An answer from model memory does not verify the connection. For ongoing research habits, see Instruct your agent . App access and Ansvar access are separate If the app is unavailable in your tenant, your Microsoft admin controls that installation decision. If the agent opens but an Ansvar tool refuses a request, read the refusal: it may concern your sign-in, plan, source coverage or quota. See Troubleshooting . Configure your own Microsoft agent Use Copilot Studio when you need your own instructions, publishing choices and connection configuration. VS Code Copilot agent mode has its own MCP setup . These are separate entry points from the published Teams and M365 Copilot agent. Previous Connect Lovable Next Connect Copilot Studio --- ## Run a TARA · Ansvar AI docs URL: https://ansvar.eu/docs/guides/tara Run a threat analysis and risk assessment: choose a variant, confirm the system and risk criteria, review attack paths, and receive the report. Run a TARA A threat analysis and risk assessment turns threat scenarios into a risk register with assessed impacts, treatments and recorded decisions. Ansvar's TARA variants share the enterprise risk_assessment lifecycle, with sector-specific questions, criteria and sources. Start from Premium with a system you describe, with unwatermarked rendered exports included; customer-document grounding requires Team or Company. Choose the assessment Ask your agent to call list_workflow_types and choose the variant for your system: automotive, OT, rail, robotics or UAS. Use scope_workflow if the objective is unclear, then confirm the returned choice before spending a workflow run. The workflow catalogue lists the current variants and their plan requirements. text Copy Using Ansvar, help me run an automotive TARA for a telematics ECU. Confirm the workflow type, system boundary and risk criteria with me first. Ask about the vehicle interfaces, remote services, assets and existing controls. Take me through each review gate, preserve unresolved evidence, and deliver the server's report and delivery receipt when the assessment is complete. This is a starter instruction for your own assessment. For the full run loop, install the TARA agent skill and keep the gateway connected. Describe the system and agree the criteria Identify the system boundary, assets, external connections, dependencies, operating environment and existing safeguards. Confirm the scoring bands and acceptance thresholds the selected workflow presents. A different sector can use different consequence categories and assessment criteria; carry the selected definitions into the report. Where the workflow offers a system data-flow diagram, review its components, flows and trust boundaries before accepting it. It is optional: follow the step's explicit skip path if you do not want to include one. Do not approve a diagram that invents missing interfaces or controls. Review scenarios, attack paths and treatments Confirm the risk list. Each scenario needs an affected asset, a threat and an outcome you can assess; add missing scenarios before the per-risk analysis starts. For each risk, review the impact and likelihood or feasibility criteria requested by the variant. Read the cited evidence and keep missing evidence visible. Where the variant requests attack paths, check the steps, entry points, preconditions and techniques. The report retains the path's provenance alongside its diagram; an unsupported technique must not acquire an invented citation. Record the treatment, owner and supporting safeguards. Keep existing protection separate from planned protection and a projected after-treatment position. A planned safeguard does not establish that today's risk has already fallen. Review the evaluation and compliance findings, including any risk that remains outside the agreed appetite. Complete the review gate before requesting the report. Receive and check the report Call generate_report after the required stages pass. Premium, Team and Company receive the structured JSON report and can also request unwatermarked HTML, PDF or DOCX exports. Your agent should display delivery_receipt.display_markdown unchanged and hand over the complete artifact. Check the criteria, current risk position, treatments, attack-path evidence and unresolved items. See report delivery for artifact hashes and the distinction from audit-ledger receipts. Your review owns the decision The report supports your engineering and risk review. It does not grant type approval, certify the system or replace the responsible person's risk-acceptance decision. Use resume_workflow to continue an active run in a later session. When the system changes after completion, start a new assessment and identify which earlier evidence still applies. For component-level threat enumeration, see Threat modeling . Previous Threat modeling Next Control scope repository --- ## Blog · Ansvar AI URL: https://ansvar.eu/blog Field notes on turning law, standards, security intelligence, and customer evidence into assessments and decisions a reviewer can inspect. Blog Field notes on defensible decisions . How we turn authoritative sources and customer evidence into structured assessments, review gates, cited findings, and explicit gaps. Written for the people who approve the result. RSS feed Browse by topic Topics ai-agents ai-governance ai-security citations claude code-review compliance compliance-automation copilot csa-star cvss cyber-resilience-act 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 Open-source steward readiness before the CRA reporting date A public-source review can help an open-source organisation assess CRA steward status, conditional reporting duties, and the evidence it still needs. JR Jeffrey von Rotz 11 August 2026 6 min read cyber-resilience-act open-source compliance threat-modeling 23 July 2026 · 4 min read 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. 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 · 11 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 --- ## Open-source steward readiness before the CRA reporting date · Ansvar AI Blog URL: https://ansvar.eu/blog/open-source-steward-readiness-cra A public-source review can help an open-source organisation assess CRA steward status, conditional reporting duties, and the evidence it still needs. Method note. Ansvar produced this article with AI assistance under human direction and editorial review. We removed the assessed project's name, sector, organisation type, release identifiers, governance roles, technical architecture, and assessment counts. This article explains a compliance review method. It is not legal advice or a vulnerability assessment. The Cyber Resilience Act's Article 14 reporting rules apply from 11 September 2026. For some open-source projects, Article 24 carries parts of that reporting regime to a legal person acting as an open-source software steward. Open-source organisations now have an immediate governance task. A project needs to identify the legal person, understand the support it provides, and assign the people who will make and document a reporting decision. A security policy alone cannot answer those questions. We tested a public-source review method against a mature open-source project supported by a legal entity. We use the de-identified case study to explain the review method without turning the project into an unwilling public example. Start with the legal role # Article 3(14) of the CRA defines an open-source software steward as a legal person, other than a manufacturer, that supports the development of specific free and open-source software on a sustained basis, where the software is intended for commercial activities, and ensures its viability. That definition requires project facts. A repository owner or funding page does not settle the role on its own. Reviewers need to establish: which legal person supports the project; whether the support concerns this project or a wider community; whether the support includes governance, infrastructure, release work, or engineering; and how use intended for commercial activities fits the project's circumstances. The Commission's open-source CRA overview describes the steward regime as tailored to legal persons that support open-source products intended for commercial activities and play a main role in keeping them viable. The Commission provided practical examples in its July 2026 guidance, but the guidance remains non-binding. A project still needs its own factual and legal analysis. Our review recorded a plausible role hypothesis. It did not declare that the legal person was a steward. Freeze the evidence before assessing it # We chose one tagged release and pinned it to an exact commit. The evidence set contained the release tree, the current security policy, public governance documents, current role records, and official EU legal texts. Freezing the target kept us from making a common error. A project can improve its policy on its main branch while users of the stable source archive still receive an older copy. Comparing an old release against today's repository without naming both states would blur that difference. Our team confirmed such a mismatch. The stable source archive carried outdated support information, while the current branch described a newer policy and reporting process. We treated this as a release-documentation issue. We did not present it as evidence of poor vulnerability handling. Maintainers can address this class of problem by pointing each release page to one maintained policy and stating which copy governs. Separate evidence gaps from missing processes # Public repositories may omit the full operating procedure for a legal or regulatory response. A reviewer who finds no public Article 14 runbook cannot conclude that the project has no internal runbook. We used three evidence states: State Meaning Example Confirmed The reviewed artifact supports the statement The stable release contains a security policy Open fact Public evidence cannot settle the answer Which legal person performs release work, and in what capacity Public-evidence gap The reviewed public set does not show the procedure No public record identifies the Article 14 decision owner Reviewers who use these terms avoid overstating the case. Maintainers can close an open fact with evidence. Counsel can disagree with the role analysis without first correcting an accusation that the project never made. Map Article 24 before building a reporting process # Article 24 gives qualifying open-source software stewards a tailored set of duties. It requires a cybersecurity policy and documentation that a reviewer can verify, along with cooperation with market-surveillance authorities. Paragraph 3 connects stewards to parts of Article 14 under two conditions: The actively exploited vulnerability reporting duty applies to the extent that the steward participates in development. The severe-incident and user-notice duties apply to the extent that the incident affects network and information systems the steward provides for development. Those conditions make the support model part of the compliance record. A legal person that supplies administrative support may face a different Article 24(3) analysis from one that manages release engineering or project development systems. The CRA applies Article 14 from 11 September 2026. Its main obligations apply from 11 December 2027. The Commission confirmed those dates in its July 2026 implementation guidance notice . Build the decision path before an incident # A project can prepare without publishing sensitive incident procedures. The minimum internal record should answer these questions: Who decides whether the legal person qualifies as the steward for this project? Who determines whether the steward's support triggers an Article 24(3) reporting branch? Who records awareness, starts the applicable clock, and submits through the required reporting route? Which development systems does the steward provide, and who classifies a severe incident affecting them? Who can assemble the cybersecurity-policy evidence requested by a market-surveillance authority? The answers can stay private. The organisation should record them in a form it can test, approve, and retrieve under time pressure. Make the assessment refuse unsupported conclusions # We used an AI agent to collect evidence, map clauses, and construct a technical threat model. Human reviewers approved the scope and challenged the output against the frozen evidence. The reviewers enforced four boundaries: no project identity or legal status inferred from a repository label; no vulnerability claim without technical validation; no CVE attached without evidence that it affected the frozen target; and no claim that an internal process was absent because it was not public. The independent reviewer found public evidence that narrowed two open questions and a scoring rule applied in some rows but not others. We corrected the evidence map and the affected distribution. The correction record matters more than a polished first draft because it identifies the errors and their effects. The useful output is an evidence packet # The final internal packet joined the legal role analysis to operational evidence. It contained a clause map, an evidence manifest, an Article 14 tabletop, and a record of project facts that required confirmation. That packet gives a supporting organisation a manageable review task. Counsel can decide the legal role. Maintainers can correct project facts. Security staff can test the reporting path. Each person reviews the part that requires their judgment. Ansvar supports this kind of work by retrieving the current legal provisions, preserving their citations, and keeping unsupported conclusions out of the report. Your own agent remains the working interface. Try this prompt with an agent connected to Ansvar: Using Ansvar, assess whether our organisation could qualify as an open-source software steward under CRA Article 3(14). Cite the primary legal sources, separate confirmed facts from missing facts, and map the conditional duties in Article 24. Start with the Ansvar quickstart , or read the official Cyber Resilience Act before you build the review. On this page Start with the legal role Freeze the evidence before assessing it Separate evidence gaps from missing processes Map Article 24 before building a reporting process Build the decision path before an incident Make the assessment refuse unsupported conclusions The useful output is an evidence packet Frequently asked What is an open-source software steward under the CRA? Article 3(14) defines an open-source software steward as a legal person, other than a manufacturer, that supports the development of specific free and open-source software on a sustained basis, where the software is intended for commercial activities, and ensures its viability. Each project needs its own factual and legal analysis. When do the CRA reporting rules start to apply? Article 71 applies Article 14 from 11 September 2026. The CRA's main obligations apply from 11 December 2027. Article 24 connects qualifying open-source software stewards to parts of Article 14 under stated development and infrastructure conditions. Does a missing public Article 14 runbook prove that no process exists? No. A public-source review can state that the reviewed artifacts do not show a process. It cannot conclude that the organisation has no internal process. Maintainers or counsel may close that evidence gap with private records. Is this a legal or vulnerability assessment? No. This article explains a compliance review method. The underlying work used public evidence, made no vulnerability claim without technical validation, and left the final legal role decision to the project and its counsel. --- ## 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 changes that cross a trust boundary. The gateway can route one request across many eligible legal and security sources, so each boundary needs an explicit failure mode. The same workflow is available to your AI agent 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 -->|Eligible sources| D[Parallel source 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 reviews cited findings and unresolved gaps] 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 . Paste the URL, sign in through OAuth 2.1 with Dynamic Client Registration, and the gateway returns the tools available to that account. 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 "Using Ansvar, 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 threat model with cited findings and explicit unresolved evidence gaps The DFD Mermaid you can drop into the design doc A treatment_plan linking each high-residual threat to a planned mitigation Structured JSON for downstream systems, with rendered HTML, PDF and DOCX formats where the account plan permits them 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 # Automotive TARA is a separate workflow type built on Ansvar's risk-assessment spine. Start it with its served workflow ID: text Copy start_workflow( workflow_type="automotive_tara", entity_description="ECU + telematics gateway, type-approval target market: EU + UK" ) The run scopes the vehicle system, records the assessment criteria, asks you to confirm the risks, and then evaluates likelihood, consequence, thresholds, and treatments. It produces a risk register rather than a STRIDE threat table. Standards references are clause maps unless the signed-in person or machine identity has the matching SIS standards entitlement. Other regulated-engineering TARAs have their own served workflow IDs. Call list_workflow_types before starting a run instead of relying on a copied catalogue; it is the authority for the signed-in account. 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. The gateway validates served citation identifiers without a language model. The workflow requires factual findings to carry served evidence or remain unresolved; it does not accept a plausible-looking reference as evidence. Fan-out blast radius # A customer query can reach many downstream MCPs. A compromised or malformed source could place bad data in the model's synthesis. The gateway validates each MCP envelope, and CI asserts the required _citation shape before release. 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. Customer-tier threat models come from gateway workflows. A completed run stays immutable; when the threat surface changes, you start a new run and keep both cited records. Running the assessment through the gateway lets the new run reuse registered documents and resolve current source evidence. A reviewer can compare it with the prior report. Try it yourself # Tier requirement. The start_workflow / submit_response / generate_report lifecycle is on every tier. Free runs 1 STRIDE threat model a month and Solo 2, both on a system you describe, with a watermarked render or structured JSON. Premium runs 5 and adds LINDDUN and TARA, with structured JSON reports plus unwatermarked HTML, PDF and DOCX exports. Team runs 20 per seat a month and adds document grounding. Company uses a custom allowance. Raw CVE details, KEV status and EPSS scores remain available from Free. 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: "Using Ansvar, 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 selects workflow_type="linddun" . For automotive TARA , ask for "automotive TARA per UNECE R155"; the agent selects workflow_type="automotive_tara" . Your agent's list_workflow_types call returns the menu available to the signed-in account. 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 the live coverage inventory 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 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 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 the STRIDE workflow for security threats by component and boundary. linddun is a separate privacy-threat workflow. Automotive TARA is a separate automotive_tara workflow built on the risk-assessment spine: it produces a risk register with likelihood, consequence, thresholds, and treatments. Use list_workflow_types to inspect the workflow IDs available to the signed-in account. What's different about modeling an MCP gateway versus a REST API? The client discovers its tier-scoped tool list during the session, so the runtime tool surface can differ from the design-time assumption. One user request can reach many downstream sources, and the model must orchestrate tools while treating upstream content as untrusted data. 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 immutable workflow outputs. When the threat surface changes, start a new run and compare its cited record with the prior one. --- ## Denmark legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/denmark Check the published Danish legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Denmark DK · Country coverage Danish legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Denmark , with a citation on every answer. Check a regulation or topic in Denmark Where Country page DK Denmark Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Denmark are searchable Statute law, data protection, cybersecurity and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Denmark case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Denmark. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Denmark implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Lov om foranstaltninger til sikring af et højt cybersikkerhedsniveau (NIS 2-loven) Art. 20, 21, 23 Yes Published record Evidence behind the Denmark answer What the public index lists for Denmark . Searchable nationally Statute law Data protection Cybersecurity Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation Databeskyttelsesloven § 1 Read this example 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. Verified publication channel Official source Retsinformation — official Danish legal information system (opens in a new tab) Ask your AI client about Denmark Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Sweden legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/sweden Check the published Swedish legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Sweden SE · Country coverage Swedish legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Sweden , with a citation on every answer. Check a regulation or topic in Sweden Where Country page SE Sweden Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Sweden are searchable Statute law, data protection, cybersecurity and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Sweden case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Sweden. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Sweden implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Cybersäkerhetslagen (SFS 2025:1506) Art. 20, 21, 23 Yes Published record Evidence behind the Sweden answer What the public index lists for Sweden . Searchable nationally Statute law Data protection Cybersecurity Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation 3 kap. 12 § SFS 1998:808 Read this example 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. Verified publication channel Official source Riksdagen open data — Svensk författningssamling (SFS), consolidated statute text (opens in a new tab) Sector pages Mentioned on these sector pages Sector pages that name Sweden in their own coverage notes. Public sector Privacy & data protection AI governance Healthcare & medical devices Energy & utilities Ask your AI client about Sweden Connect once, then search the published sources with citations attached. Connect your AI client Check another country Ansvar also publishes an introduction written for readers in Sweden : Svenska --- ## Finland legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/finland Check the published Finnish legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Finland FI · Country coverage Finnish legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Finland , with a citation on every answer. Check a regulation or topic in Finland Where Country page FI Finland Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Finland are searchable Statute law, data protection, cybersecurity and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Finland case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Finland. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Finland implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Kyberturvallisuuslaki (124/2025) Art. 20, 21, 23 Yes Published record Evidence behind the Finland answer What the public index lists for Finland . Searchable nationally Statute law Data protection Cybersecurity Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation Tietosuojalaki (1050/2018) 3 § Read this example 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. Verified publication channel Official source Finlex — official legal databank of Finland (opens in a new tab) Ask your AI client about Finland Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Norway legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/norway Check the published Norway legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Norway NO · Country coverage Norway legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Norway , with a citation on every answer. Check a regulation or topic in Norway Where Country page NO Norway Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for Norway are searchable Statute law, data protection and sector regulators are listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law Norway case law is not listed on this page Source terms Official statute text, reuse permitted under the Norwegian open data licence Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Norway. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Norway answer What the public index lists for Norway . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, reuse permitted under the Norwegian open data licence Reviewed evidence Sources and citation details Example citation LOV-2018-06-01-24 § 3-5 Read this example 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. Verified publication channel Official source Lovdata — official publisher of Norsk Lovtidend (opens in a new tab) Sector pages Mentioned on these sector pages Sector pages that name Norway in their own coverage notes. Energy & utilities Ask your AI client about Norway Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Iceland legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/iceland Check the published Icelandic legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Iceland IS · Country coverage Icelandic legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Iceland , with a citation on every answer. Check a regulation or topic in Iceland Where Country page IS Iceland Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for Iceland are searchable Statute law, data protection and sector regulators are listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law Iceland case law is not listed on this page Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Iceland. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Iceland answer What the public index lists for Iceland . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation 3. gr. laga nr. 90/2018 Read this example 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. Verified publication channel Official source Alþingi — Lagasafn, the Icelandic statute database (opens in a new tab) Ask your AI client about Iceland Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Austria legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/austria Check the published Austrian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Austria AT · Country coverage Austrian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Austria , with a citation on every answer. Check a regulation or topic in Austria Where Country page AT Austria Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Austria are searchable Statute law, case law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium Austria court decisions, on Premium and above Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Austria. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Austria implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Netz- und Informationssystemsicherheitsgesetz 2026 (NISG 2026, BGBl. I Nr. 94/2025) Art. 20, 21, 23 Yes Published record Evidence behind the Austria answer What the public index lists for Austria . Searchable nationally Statute law Case law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation § 59 DSG Read this example 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. Verified publication channel Official source RIS — Rechtsinformationssystem des Bundes, consolidated federal law (opens in a new tab) Ask your AI client about Austria Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Germany legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/germany Check the published German legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Germany DE · Country coverage German legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Germany , with a citation on every answer. Check a regulation or topic in Germany Where Country page DE Germany Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Germany are searchable Statute law, data protection, cybersecurity and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Germany case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Germany. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Germany implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 BSI-Gesetz (BSIG, as restated by the NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz) Art. 20, 21, 23 Yes Published record Evidence behind the Germany answer What the public index lists for Germany . Searchable nationally Statute law Data protection Cybersecurity Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation § 26 BDSG Read this example 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. Verified publication channel Official source gesetze-im-internet.de — federal statutes, Bundesministerium der Justiz (opens in a new tab) Sector pages Mentioned on these sector pages Sector pages that name Germany in their own coverage notes. AI governance Privacy & data protection Healthcare & medical devices Public sector Energy & utilities Ask your AI client about Germany Connect once, then search the published sources with citations attached. Connect your AI client Check another country Ansvar also publishes an introduction written for readers in Germany : Deutsch --- ## Belgium legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/belgium Check the published Belgian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Belgium BE · Country coverage Belgian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Belgium , with a citation on every answer. Check a regulation or topic in Belgium Where Country page BE Belgium Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Belgium are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Belgium case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Belgium. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Belgium implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Loi du 26 avril 2024 établissant un cadre pour la cybersécurité des réseaux et des systèmes d'information (loi NIS2) Art. 20, 21, 23 Yes Published record Evidence behind the Belgium answer What the public index lists for Belgium . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation Loi du 30 juillet 2018, art. 202 Read this example 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. Verified publication channel Official source ejustice.just.fgov.be — Justel, consolidated federal legislation (opens in a new tab) Ask your AI client about Belgium Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Luxembourg legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/luxembourg Check the published Luxembourg legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Luxembourg LU · Country coverage Luxembourg legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Luxembourg , with a citation on every answer. Check a regulation or topic in Luxembourg Where Country page LU Luxembourg Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Luxembourg are searchable Statute law and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Luxembourg case law listed Source terms Official statute text, reuse permitted under the Luxembourg open licence Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Luxembourg. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Luxembourg implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Loi du 5 mai 2026 concernant des mesures destinées à assurer un niveau élevé de cybersécurité Art. 20, 21, 23 Yes Published record Evidence behind the Luxembourg answer What the public index lists for Luxembourg . Searchable nationally Statute law Sector regulators Source terms Official statute text, reuse permitted under the Luxembourg open licence Reviewed evidence Sources and citation details Example citation Loi du 19 décembre 2025 (JO A n° 620), art. 2 Read this example 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. Verified publication channel Official source Legilux — Journal officiel du Grand-Duché de Luxembourg (opens in a new tab) Ask your AI client about Luxembourg Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Netherlands legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/netherlands Check the published Dutch legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Netherlands NL · Country coverage Dutch legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Netherlands , with a citation on every answer. Check a regulation or topic in Netherlands Where Country page NL Netherlands Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Netherlands are searchable Statute law, case law, data protection, cybersecurity and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium Netherlands court decisions, on Premium and above Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Netherlands. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Netherlands implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Cyberbeveiligingswet (Stb. 2026, 187) Art. 20, 21, 23 Yes Published record Evidence behind the Netherlands answer What the public index lists for Netherlands . Searchable nationally Statute law Case law Data protection Cybersecurity Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation Artikel 27 WOR (BWBR0002747) Read this example 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. Verified publication channel Official source wetten.overheid.nl — official consolidated statute register (opens in a new tab) Sector pages Mentioned on these sector pages Sector pages that name Netherlands in their own coverage notes. Public sector Ask your AI client about Netherlands Connect once, then search the published sources with citations attached. Connect your AI client Check another country Ansvar also publishes an introduction written for readers in Netherlands : Nederlands --- ## Spain legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/spain Check the published Spanish legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Spain ES · Country coverage Spanish legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Spain , with a citation on every answer. Check a regulation or topic in Spain Where Country page ES Spain Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Spain are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Spain case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Spain. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Spain answer What the public index lists for Spain . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation art. 37 LOPDGDD Read this example 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. Verified publication channel Official source BOE — Boletín Oficial del Estado, consolidated legislation (opens in a new tab) Ask your AI client about Spain Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Portugal legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/portugal Check the published Portuguese legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Portugal PT · Country coverage Portuguese legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Portugal , with a citation on every answer. Check a regulation or topic in Portugal Where Country page PT Portugal Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Portugal are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Portugal case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Portugal. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Portugal implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Regime Jurídico da Cibersegurança (anexo ao Decreto-Lei n.º 125/2025, de 4 de dezembro) Art. 20, 21, 23 Yes Published record Evidence behind the Portugal answer What the public index lists for Portugal . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation Artigo 9.º da Lei n.º 34/2009, de 14 de Julho Read this example 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. Verified publication channel Official source Diário da República — official journal of Portugal (opens in a new tab) Ask your AI client about Portugal Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## France legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/france Check the published French legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / France FR · Country coverage French legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for France , with a citation on every answer. Check a regulation or topic in France Where Country page FR France Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for France are searchable Statute law and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no France case law listed Source terms Official statute text, reuse permitted under the Etalab open licence Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for France. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the France answer What the public index lists for France . Searchable nationally Statute law Sector regulators Source terms Official statute text, reuse permitted under the Etalab open licence Reviewed evidence Sources and citation details Example citation art. 106, loi n° 78-17 (Informatique et Libertés) Read this example 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. Verified publication channel Official source Légifrance — official consolidated legislation (opens in a new tab) Ask your AI client about France Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Italy legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/italy Check the published Italian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Italy IT · Country coverage Italian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Italy , with a citation on every answer. Check a regulation or topic in Italy Where Country page IT Italy Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Italy are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Italy case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Italy. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Italy implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Decreto legislativo 4 settembre 2024, n. 138 Art. 20, 21, 23 Yes Published record Evidence behind the Italy answer What the public index lists for Italy . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Ask your AI client about Italy Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## San Marino legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/san-marino Check the published Sammarinese legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / San Marino SM · Country coverage Sammarinese legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for San Marino , with a citation on every answer. Check a regulation or topic in San Marino Where Country page SM San Marino Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for San Marino are searchable Statute law is listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law San Marino case law is not listed on this page Source terms Official statute text, reuse permitted under San Marino's copyright law (art. 98), with conditions Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for San Marino. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the San Marino answer What the public index lists for San Marino . Searchable nationally Statute law Source terms Official statute text, reuse permitted under San Marino's copyright law (art. 98), with conditions Ask your AI client about San Marino Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Malta legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/malta Check the published Maltese legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Malta MT · Country coverage Maltese legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Malta , with a citation on every answer. Check a regulation or topic in Malta Where Country page MT Malta Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Malta are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Malta case law listed Source terms Official statute text, reuse permitted under Malta's public-sector information reuse rules Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Malta. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Malta implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Ordni dwar Miżuri għal Livell Għoli Komuni taċ-Ċibersigurtà madwar l-Unjoni Ewropea (Malta) (S.L. 460.41) Art. 20, 21, 23 Yes Published record Evidence behind the Malta answer What the public index lists for Malta . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, reuse permitted under Malta's public-sector information reuse rules Reviewed evidence Sources and citation details Example citation S.L. 545.42, reg. 10 Read this example 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. Verified publication channel Official source legislation.mt — Laws of Malta, official register (opens in a new tab) Ask your AI client about Malta Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Czechia legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/czechia Check the published Czech legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Czechia CZ · Country coverage Czech legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Czechia , with a citation on every answer. Check a regulation or topic in Czechia Where Country page CZ Czechia Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Czechia are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Czechia case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Czechia. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Czechia implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Zákon č. 264/2025 Sb., o kybernetické bezpečnosti Art. 21, 23 Yes Published record Evidence behind the Czechia answer What the public index lists for Czechia . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation § 29 zákona č. 110/2019 Sb. Read this example 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. Verified publication channel Official source e-Sbírka — official electronic collection of laws (opens in a new tab) Ask your AI client about Czechia Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Slovakia legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/slovakia Check the published Slovak legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Slovakia SK · Country coverage Slovak legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Slovakia , with a citation on every answer. Check a regulation or topic in Slovakia Where Country page SK Slovakia Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Slovakia are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Slovakia case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Slovakia. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Slovakia implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 ZÁKON č. 69/2018 Z. z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov Art. 21, 23 Yes Published record Evidence behind the Slovakia answer What the public index lists for Slovakia . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation § 71 zákona č. 18/2018 Z. z. Read this example 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. Verified publication channel Official source Slov-Lex — official legal information portal of Slovakia (opens in a new tab) Ask your AI client about Slovakia Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Croatia legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/croatia Check the published Croatian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Croatia HR · Country coverage Croatian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Croatia , with a citation on every answer. Check a regulation or topic in Croatia Where Country page HR Croatia Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Croatia are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Croatia case law listed Source terms Official statute text, reuse permitted under the Croatian statutory exemption, with conditions Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Croatia. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Croatia implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Zakon o kibernetičkoj sigurnosti Art. 20, 21, 23 Yes Published record Evidence behind the Croatia answer What the public index lists for Croatia . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, reuse permitted under the Croatian statutory exemption, with conditions Reviewed evidence Sources and citation details Example citation čl. 33. (NN 42/2018) Read this example 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. Verified publication channel Official source Narodne novine — official gazette of the Republic of Croatia (opens in a new tab) Ask your AI client about Croatia Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Hungary legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/hungary Check the published Hungarian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Hungary HU · Country coverage Hungarian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Hungary , with a citation on every answer. Check a regulation or topic in Hungary Where Country page HU Hungary Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Hungary are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Hungary case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Hungary. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Hungary implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 2024. évi LXIX. törvény Magyarország kiberbiztonságáról Art. 20, 21, 23 Yes Published record Evidence behind the Hungary answer What the public index lists for Hungary . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation Infotv. 25/G. § Read this example 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. Verified publication channel Official source Nemzeti Jogszabálytár — official Hungarian legislation register (opens in a new tab) Ask your AI client about Hungary Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Poland legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/poland Check the published Polish legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Poland PL · Country coverage Polish legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Poland , with a citation on every answer. Check a regulation or topic in Poland Where Country page PL Poland Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Poland are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Poland case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Poland. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Poland implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. 2018 poz. 1560; t.j. Dz.U. z 2026 r. poz. 20, zm. Dz.U. z 2026 r. poz. 252) Art. 20, 21, 23 Yes Published record Evidence behind the Poland answer What the public index lists for Poland . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation art. 115, Dz.U. 2018 poz. 1000 Read this example 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. Verified publication channel Official source ISAP — Internetowy System Aktów Prawnych (Sejm) (opens in a new tab) Ask your AI client about Poland Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Slovenia legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/slovenia Check the published Slovenian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Slovenia SI · Country coverage Slovenian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Slovenia , with a citation on every answer. Check a regulation or topic in Slovenia Where Country page SI Slovenia Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Slovenia are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Slovenia case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Slovenia. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Slovenia implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Zakon o informacijski varnosti (ZInfV-1) Art. 20, 21, 23 Yes Published record Evidence behind the Slovenia answer What the public index lists for Slovenia . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation 273. člen (PIS-RS ZAKO8249) Read this example 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. Verified publication channel Official source Uradni list RS — official gazette of the Republic of Slovenia (opens in a new tab) Ask your AI client about Slovenia Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Lithuania legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/lithuania Check the published Lithuanian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Lithuania LT · Country coverage Lithuanian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Lithuania , with a citation on every answer. Check a regulation or topic in Lithuania Where Country page LT Lithuania Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Lithuania are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Lithuania case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Lithuania. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Lithuania implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Lietuvos Respublikos kibernetinio saugumo įstatymas (XII-1428) Art. 20, 21 Yes Published record Evidence behind the Lithuania answer What the public index lists for Lithuania . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation Įstatymo Nr. VIII-946 52 straipsnis Read this example 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. Verified publication channel Official source e-TAR — Register of Legal Acts of the Republic of Lithuania (opens in a new tab) Ask your AI client about Lithuania Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Latvia legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/latvia Check the published Latvian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Latvia LV · Country coverage Latvian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Latvia , with a citation on every answer. Check a regulation or topic in Latvia Where Country page LV Latvia Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Latvia are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Latvia case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Latvia. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Latvia implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Nacionālās kiberdrošības likums Art. 20, 21, 23 Yes Published record Evidence behind the Latvia answer What the public index lists for Latvia . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation Fizisko personu datu apstrādes likuma 25. pants Read this example 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. Verified publication channel Official source likumi.lv — official consolidated legislation of Latvia (opens in a new tab) Ask your AI client about Latvia Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Estonia legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/estonia Check the published Estonian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Estonia EE · Country coverage Estonian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Estonia , with a citation on every answer. Check a regulation or topic in Estonia Where Country page EE Estonia Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Estonia are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Estonia case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Estonia. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Estonia implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Küberturvalisuse seadus Art. 21, 23 Yes Published record Evidence behind the Estonia answer What the public index lists for Estonia . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation IKS § 38 Read this example 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. Verified publication channel Official source Riigi Teataja — Estonian State Gazette, consolidated acts (opens in a new tab) Ask your AI client about Estonia Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Romania legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/romania Check the published Romanian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Romania RO · Country coverage Romanian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Romania , with a citation on every answer. Check a regulation or topic in Romania Where Country page RO Romania Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Romania are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Romania case law listed Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Romania. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Romania answer What the public index lists for Romania . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation art. 34 din Legea nr. 284/2018 Read this example 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. Verified publication channel Official source Portal Legislativ — legislatie.just.ro (Ministry of Justice) (opens in a new tab) Ask your AI client about Romania Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Albania legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/albania Check the published Albania legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Albania AL · Country coverage Albania legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Albania , with a citation on every answer. Check a regulation or topic in Albania Where Country page AL Albania Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for Albania are searchable Statute law is listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law Albania case law is not listed on this page Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Albania. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Albania answer What the public index lists for Albania . Searchable nationally Statute law Source terms Official statute text, public domain Ask your AI client about Albania Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Bulgaria legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/bulgaria Check the published Bulgarian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Bulgaria BG · Country coverage Bulgarian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Bulgaria , with a citation on every answer. Check a regulation or topic in Bulgaria Where Country page BG Bulgaria Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Bulgaria are searchable Statute law, case law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium Bulgaria court decisions, on Premium and above Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Bulgaria. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. National implementations EU rules as Bulgaria implements them The national statute mapped to each EU framework, with the EU articles it covers. Searchable by name through the gateway. EU framework National instrument EU articles mapped Reviewed NIS2 Закон за изменение и допълнение на Закона за киберсигурност (2026): заместващ текст Art. 20, 21, 23 Yes Published record Evidence behind the Bulgaria answer What the public index lists for Bulgaria . Searchable nationally Statute law Case law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation чл. 62, ал. 1 Read this example 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. Ask your AI client about Bulgaria Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Kosovo legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/kosovo Check the published Kosovar legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Kosovo XK · Country coverage Kosovar legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Kosovo , with a citation on every answer. Check a regulation or topic in Kosovo Where Country page XK Kosovo Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for Kosovo are searchable Statute law is listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law Kosovo case law is not listed on this page Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Kosovo. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Kosovo answer What the public index lists for Kosovo . Searchable nationally Statute law Source terms Official statute text, public domain Ask your AI client about Kosovo Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Serbia legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/serbia Check the published Serbian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Serbia RS · Country coverage Serbian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Serbia , with a citation on every answer. Check a regulation or topic in Serbia Where Country page RS Serbia Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for Serbia are searchable Statute law is listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law Serbia case law is not listed on this page Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Serbia. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Serbia answer What the public index lists for Serbia . Searchable nationally Statute law Source terms Official statute text, public domain Ask your AI client about Serbia Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Ireland legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/ireland Check the published Irish legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Ireland IE · Country coverage Irish legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Ireland , with a citation on every answer. Check a regulation or topic in Ireland Where Country page IE Ireland Change + What Regulation, standard, sector or source type Try GDPR NIS2 Statute law Searchable Legal sources for Ireland are searchable Statute law, data protection and sector regulators are listed nationally, with the EU layer on top. Every answer carries a citation to the official source. EU text EU regulations and directives, searchable National law National statutes, searchable Case law Premium EU court decisions on Premium and above; no Ireland case law listed Source terms Official statute text, reuse permitted under the Oireachtas open data licence Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Ireland. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Ireland answer What the public index lists for Ireland . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, reuse permitted under the Oireachtas open data licence Ask your AI client about Ireland Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Liechtenstein legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/liechtenstein Check the published Liechtenstein legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Liechtenstein LI · Country coverage Liechtenstein legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Liechtenstein , with a citation on every answer. Check a regulation or topic in Liechtenstein Where Country page LI Liechtenstein Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for Liechtenstein are searchable Statute law, data protection and sector regulators are listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law Liechtenstein case law is not listed on this page Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Liechtenstein. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Liechtenstein answer What the public index lists for Liechtenstein . Searchable nationally Statute law Data protection Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation Art. 6 DSG (LGBl. 2018 Nr. 272) Read this example 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. Verified publication channel Official source gesetze.li — Lilex, consolidated law of Liechtenstein (opens in a new tab) Ask your AI client about Liechtenstein Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## United Kingdom legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/united-kingdom Check the published UK legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / United Kingdom GB · Country coverage UK legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for United Kingdom , with a citation on every answer. Check a regulation or topic in United Kingdom Where Country page GB United Kingdom Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for United Kingdom are searchable Statute law, data protection, cybersecurity and sector regulators are listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law United Kingdom case law is not listed on this page Source terms Official statute text, reuse permitted under the Open Government Licence Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for United Kingdom. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the United Kingdom answer What the public index lists for United Kingdom . Searchable nationally Statute law Data protection Cybersecurity Sector regulators Source terms Official statute text, reuse permitted under the Open Government Licence Reviewed evidence Sources and citation details Example citation Data Protection Act 2018, s 8 Read this example 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. Verified publication channel Official source legislation.gov.uk — the UK's official statute book (opens in a new tab) Sector pages Mentioned on these sector pages Sector pages that name United Kingdom in their own coverage notes. Energy & utilities Ask your AI client about United Kingdom Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Canada legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/canada Check the published Canada legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Canada CA · Country coverage Canada legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Canada , with a citation on every answer. Check a regulation or topic in Canada Where Country page CA Canada Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for Canada are searchable Statute law and sector regulators are listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law Canada case law is not listed on this page Source terms Official statute text, reuse permitted under the Reproduction of Federal Law Order Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Canada. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Canada answer What the public index lists for Canada . Searchable nationally Statute law Sector regulators Source terms Official statute text, reuse permitted under the Reproduction of Federal Law Order Reviewed evidence Sources and citation details Example citation PIPEDA, s. 10.1 (Justice Laws P-8.6) Read this example Canadian federal Acts sit in the Justice Laws consolidation under a letter-number code — P-8.6 is the Personal Information Protection and Electronic Documents Act — and sections are cited bare, s. 10.1 here for the duty to report a breach of security safeguards to the Privacy Commissioner. Registered regulations keep their registration number instead: the Breach of Security Safeguards Regulations are SOR/2018-64. The gateway resolves the two separately, and the provinces number their statutes their own way on Ontario e-Laws and BC Laws. Verified publication channel Official source Justice Laws Website — consolidated federal Acts and regulations, Department of Justice Canada (opens in a new tab) Ontario e-Laws — King's Printer for Ontario (opens in a new tab) BC Laws — King's Printer for British Columbia (opens in a new tab) Ask your AI client about Canada Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## United States legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/united-states Check the published US legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / United States US · Country coverage US legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for United States , with a citation on every answer. Check a regulation or topic in United States Where Country page US United States Change + What Regulation, standard, sector or source type Try HIPAA CCPA/CPRA + state privacy Statute law Searchable Legal sources for United States are searchable Statute law, data protection, cybersecurity and sector regulators are listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law United States case law is not listed on this page Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for United States. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the United States answer What the public index lists for United States . Searchable nationally Statute law Data protection Cybersecurity Sector regulators Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation 44 U.S.C. § 3556 Read this example United States federal law is cited out of two registers, and Ansvar serves both. A statute puts the title number before the code and the section after it — 44 U.S.C. § 3556 is section 3556 of Title 44, the FISMA provision behind the central Federal information security incident center — and resolves on govinfo. Agency rules are numbered the same way against the Code of Federal Regulations: 32 CFR § 236.4, on defense-contractor cyber incident reporting, resolves on the eCFR down to the part. Verified publication channel Official source govinfo.gov — United States Code, U.S. Government Publishing Office (opens in a new tab) eCFR — Electronic Code of Federal Regulations, Office of the Federal Register (opens in a new tab) Sector pages Mentioned on these sector pages Sector pages that name United States in their own coverage notes. Drone & UAS Ask your AI client about United States Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## Japan legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/japan Check the published Japanese legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Japan JP · Country coverage Japanese legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Japan , with a citation on every answer. Check a regulation or topic in Japan Where Country page JP Japan Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for Japan are searchable Statute law is listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law Japan case law is not listed on this page Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Japan. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Japan answer What the public index lists for Japan . Searchable nationally Statute law Source terms Official statute text, public domain Ask your AI client about Japan Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## South Korea legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/south-korea Check the published South Korean legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / South Korea KR · Country coverage South Korean legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for South Korea , with a citation on every answer. Check a regulation or topic in South Korea Where Country page KR South Korea Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for South Korea are searchable Statute law is listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law South Korea case law is not listed on this page Source terms Official statute text, reuse permitted under the Korean open government licence Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for South Korea. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the South Korea answer What the public index lists for South Korea . Searchable nationally Statute law Source terms Official statute text, reuse permitted under the Korean open government licence Ask your AI client about South Korea Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## China legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/china Check the published Chinese legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / China CN · Country coverage Chinese legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for China , with a citation on every answer. Check a regulation or topic in China Where Country page CN China Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for China are searchable Statute law is listed nationally. Every answer carries a citation to the official source. Coverage scope Chinese national law from flk.npc.gov.cn and reviewed CAC/MIIT automotive, data, IT and AI original publications, with Chinese source text and Ansvar-authored English discovery metadata. Ministry current validity and consolidation are unasserted. Wider NPC departmental, local-regulation and judicial-interpretation layers remain held. GB/GB-T standard body text is excluded; catalogue metadata does not establish Chinese market approval or equivalence with ISO standards. National law National statutes, searchable Case law China case law is not listed on this page Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for China. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the China answer What the public index lists for China . Coverage scope Chinese national law from flk.npc.gov.cn and reviewed CAC/MIIT automotive, data, IT and AI original publications, with Chinese source text and Ansvar-authored English discovery metadata. Ministry current validity and consolidation are unasserted. Wider NPC departmental, local-regulation and judicial-interpretation layers remain held. GB/GB-T standard body text is excluded; catalogue metadata does not establish Chinese market approval or equivalence with ISO standards. Searchable nationally Statute law Source terms Official statute text, public domain Reviewed evidence Sources and citation details Example citation 《中华人民共和国个人信息保护法》第四条 Read this example Chinese statutes are cited by article — 第四条 is Article 4, here the Personal Information Protection Law's definition of personal information — inside the act's full formal name. The National People's Congress database keys each act by a record id rather than a gazette number, so the citation resolves through that id on flk.npc.gov.cn. Ansvar serves the Chinese original text with Ansvar-authored English metadata, and the served row carries an unofficial-reproduction notice: consult the promulgating organ's record, and where the portal text differs from the paper text, the paper text prevails. Verified publication channel Official source flk.npc.gov.cn — 国家法律法规数据库, the National People's Congress database of national laws and administrative regulations (opens in a new tab) Ask your AI client about China Connect once, then search the published sources with citations attached. Connect your AI client Check another country Ansvar also publishes an introduction written for readers in China : 简体中文 --- ## Ukraine legal sources and coverage · Ansvar AI URL: https://ansvar.eu/coverage/ukraine Check the published Ukrainian legal source record in Ansvar: declared source layers, licence terms, and stated gaps. Coverage / Ukraine UA · Country coverage Ukrainian legal sources in Ansvar Check a regulation, standard, sector or source type against what is searchable for Ukraine , with a citation on every answer. Check a regulation or topic in Ukraine Where Country page UA Ukraine Change + What Regulation, standard, sector or source type Try Statute law Searchable Legal sources for Ukraine are searchable Statute law is listed nationally. Every answer carries a citation to the official source. National law National statutes, searchable Case law Ukraine case law is not listed on this page Source terms Official statute text, public domain Try this in your connected AI Copy prompt Using Ansvar, show the legal and regulatory sources available for Ukraine. Separate national sources from EU-level sources and cite each source. The check says what is searchable in Ansvar today, with a citation on every answer. It does not say whether a rule applies to your organisation. Published record Evidence behind the Ukraine answer What the public index lists for Ukraine . Searchable nationally Statute law Source terms Official statute text, public domain Ask your AI client about Ukraine Connect once, then search the published sources with citations attached. Connect your AI client Check another country --- ## 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 What shipped, and when. New sources, gateway capabilities and product changes, dated as they ship. Subscribe via RSS Latest The 5 most recent changes, in full. 21 October 2026 gateway A stable endpoint for clients that snapshot tool definitions Some agent platforms, Salesforce Agentforce among them, save a copy of every tool definition when you register an MCP server. When we improve a tool description on our side, the platform marks the server out of sync and blocks your agent until you register it again, and registering again can clear your agent's configuration. For those platforms, connect to https://gateway.ansvar.eu/stable/mcp . It runs on the same servers as https://gateway.ansvar.eu/mcp , with the same sign-in, credentials, plans and tool behaviour. The difference is the tool list. On the stable endpoint, tool names, descriptions and input schemas are frozen. We change them only in a deliberate refresh, announced to you before it happens. A tool we add after a freeze does not appear on the stable endpoint until the next refresh. The stable endpoint checks each call against the frozen schema, the one your platform saved. Plan limits and the usual argument checks still apply. If your client reloads the tool list on its own, keep using /mcp : it gets every improvement the day we ship it. 21 October 2026 gateway Microsoft 365 Copilot shows Ansvar sources as clickable citations Microsoft 365 Copilot builds its citations from fields it recognises on each result row: a url , a title and a subtitle . Our rows carried the link only inside citation.source_url , and the tool result ended with a Markdown table after the JSON, so Copilot could not parse it. Answers from Ansvar showed in Copilot without clickable sources. Rows from search and get_provision now carry up to three more fields: url : the row's citation.source_url , when it is a web address. A row without one gets no url ; we never make one up. title : the source and article reference, followed by the provision's title when the row has one. subtitle : the publisher, when the row names one. The tool result is now one JSON document. The "Sources used" table your agent renders sits inside it as evidence_summary , with the same text as before. The citation object is unchanged, so clients that read it keep working. Other MCP clients see the same shape. 21 October 2026 coverage EU case law: judgments of the Court of Justice and the General Court The gateway served EU legislation, but not the court that interprets it. An agent asked how the Court of Justice reads an unfair-terms clause or the GDPR's legitimate-interest test could quote the article and none of the case law behind it. Your agent can now search the judgments, orders and Advocate General opinions of the Court of Justice and the General Court, full text in English, and fetch a decision back by its ECLI with get_decision . The text comes from Cellar, the Publications Office's repository, and every row cites the Court of Justice of the European Union as publisher. We screened the collection for personal data before serving it. We serve decisions that name no private person or in which the Court anonymised the parties. We left out criminal matters, the European arrest warrant, asylum, sanctions cases brought by individuals and cases about special categories of personal data, and where our read found a private person's details we either removed the passage or withheld the decision. Try it: Using Ansvar, find Court of Justice judgments on unfair terms in consumer contracts under Directive 93/13 and cite each one by ECLI. EU case law is available from Premium. Scope with sources=['eu-court-judgments'] . 19 October 2026 gateway coverage Which laws apply to your product: the law map and new EU product acts Ask an agent which laws apply to EV chargers sold in Germany and it tends to answer from memory. When we tested that question across product types, agents left out many of the acts they should have found and cited. describe_capabilities(section='law_map', query=, jurisdiction=) now hands your agent the map. For a product type it lists the EU acts to check, each with its frameworks= key and a scope note, and for the country it lists the national instruments with their legal state and, for each one we serve, the exact get_provision call. Where we do not serve a text, the map says so and tells your agent not to answer from memory. The law map is free on every plan. The EU legislation corpus also grew to carry the product rules those maps point at: REACH, Regulation (EC) No 1907/2006, in its current consolidated version; the Packaging and Packaging Waste Regulation, (EU) 2025/40; the F-gas Regulation, (EU) 2024/573, with its English corrigendum; the ecodesign rules for electric motors, (EU) 2019/1781, and for transformers, (EU) No 548/2014; delegated and implementing acts under AFIR, the Radio Equipment Directive (including the cyber security application date), the Energy Performance of Buildings Directive and the Measuring Instruments Directive, and Directive (EU) 2026/470, the first CSRD Omnibus. Try it: Using Ansvar, which EU and Dutch laws apply to switchgear we place on the Dutch market? Use the law map and cite each act. 16 October 2026 pricing coverage CAPEC, CWE and D3FEND on every plan A free threat-model run could cite MITRE ATT&CK and ATLAS, but CAPEC, CWE and D3FEND sat on Premium and above. A free threat model named the attack and stopped short of the weakness behind it and the defence against it. The catalogues are now on every plan. Search them with sources=['capec'] , sources=['cwe'] or sources=['d3fend'] , and fetch an entry by its id, for example get_provision(law='capec', article='CAPEC-94') . Each row cites The MITRE Corporation under that catalogue's terms of use. The threat-model workflow searches them on every plan. Try it: Using Ansvar, what is CAPEC-94, which CWE weaknesses does it exploit, and which D3FEND techniques counter it? Earlier changes All 50 Coverage 26 Gateway 25 Docs 8 Workflows 6 Pricing 5 Account 3 Platform 1 Security 1 50 changes RSS for all changes 15 October 2026 coverage Austrian case law is back, without criminal matters Austrian court decisions from the RIS serve again: the Rechtssätze of the Supreme Court, the Supreme Administrative Court, the Constitutional Court and the courts of appeal. We removed criminal and administrative-offence decisions before the return. Read the full entry We took Austrian case law offline on 1 October while we removed criminal decisions from the general service. It is back. Your agent can search the Rechtssätze, the courts' own condensed statements of the legal principle each decision settled, from the Oberster Gerichtshof, the Verwaltungsgerichtshof, the Verfassungsgerichtshof and the ordinary courts of appeal. The text comes from the Rechtsinformationssystem of the Bundeskanzleramt. We removed criminal, administrative-offence and criminal-derived decisions using the RIS's own metadata, and screened the rest for personal data before serving it. Try it: Using Ansvar, what has the Oberster Gerichtshof held on the duty to warn under Austrian contract law? Austrian case law is available from Premium. Scope with sources=['austrian-court-decisions'] , or let an Austrian search reach it. 14 October 2026 coverage Bulgaria: Supreme Court of Cassation case law, civil and commercial Bulgarian case law joins the gateway: civil and commercial decisions of the Върховен касационен съд, from vks.bg. We read every decision for personal data before serving it and mark each removal in the text. Read the full entry Bulgarian searches reached the statutes only. A litigator asking how the Supreme Court of Cassation reads unjust enrichment or a contract term got the act and no court. Your agent can now search the civil and commercial decisions of the Върховен касационен съд as the court publishes them on vks.bg, and fetch any decision back by its reference. Criminal decisions are excluded. We read each decision for personal data before we serve it. The court names its judges, prosecutors and secretaries, and we keep them, as the court's own publication rules do. Where a decision names a private person, we remove that passage and leave the marker "[заличено]" in its place, so you can see that text was taken out. A decision we cannot clear that way we do not serve. verify_citations refuses a quotation that runs across a removed passage, so a quote never stitches the text on both sides together. Try it: Using Ansvar, how has the Bulgarian Supreme Court of Cassation ruled on неоснователно обогатяване between companies? Bulgarian case law is available from Premium. Scope with sources=['bulgarian-court-decisions'] . 13 October 2026 gateway coverage EU legislation in Dutch, German and Bulgarian, side by side with English get_provision takes a list of up to three languages for EU legislation and returns each language version with its own citation. Dutch, German and Bulgarian editions sit beside English. Read the full entry Your agent could read EU legislation in English only. A Dutch lawyer quoting the AVG, or a German team checking the wording of the NIS2 Richtlinie, had to translate back from English or leave the gateway to find the official language version. get_provision now accepts language for EU legislation, as one code or a list of up to three: en , nl , de or bg . A list returns the versions side by side under editions[] . Each version has its own rows, its own citation and its own language_served , so your agent can quote the German text and cite the German edition. Where an instrument has no edition in the language you asked for, the answer falls back to English and says so in language_fallback . Search stays in English: search in English, then fetch the hits in the language you need. In verify_citations , each citation subject takes a language code, so a quote checks against the edition it came from. Try it: Using Ansvar, show me Article 17 of the GDPR in English and Dutch side by side. describe_capabilities(section='sources') lists which editions each corpus holds. 9 October 2026 coverage Luxembourg: CSSF regulations and the core financial statutes The financial regulation layer now serves CSSF regulations from the CSSF's own published files, and the CSSF's coordinated texts of Luxembourg's core financial statutes in French and English, each statute labelled as the CSSF's unofficial consolidation. Read the full entry A Luxembourg search reached the CSSF's circulars, but the circulars point at CSSF regulations and at statutes we served only as their amending acts. Your agent could read a circular on fund delegation and not the law it applies. Your agent can now search and cite CSSF regulations, taken from the CSSF's own published files, and the CSSF's coordinated versions of these statutes in French and English: the Law of 5 April 1993 on the financial sector; the Law of 12 November 2004 on the fight against money laundering and terrorist financing; the Law of 17 December 2010 relating to undertakings for collective investment; the Law of 13 February 2007 relating to specialised investment funds; the Law of 12 July 2013 on alternative investment fund managers; the Law of 23 July 2016 on reserved alternative investment funds. The CSSF drew up these consolidations for information. Every statute row says so: "CSSF coordinated text (unofficial); official text: Mémorial A / Legilux". Cite the Mémorial A for a filing; use these texts to find and read the rule. Try it: Using Ansvar, what does the Luxembourg Law of 17 December 2010 require of a UCITS management company on delegation? Scope with jurisdictions=['LU'] . 8 October 2026 pricing workflows Premium workflow reports come as HTML, PDF and Word generate_report on the Premium plan now renders a workflow report as HTML, PDF or DOCX, without a watermark. Before, Premium received the report as JSON only. Read the full entry A Premium run of a threat model or a DPIA ended in a JSON report. The free trial run got a watermarked HTML or PDF. That put a paying Premium customer behind a free one, and we fixed it. On Premium, generate_report now takes format html , pdf , docx or all and returns the rendered report without a watermark, the same report Team receives. Nothing else on Premium changes: document upload stays on Team and above, and the monthly run allowance is unchanged. Ask your agent at the end of a run: Using Ansvar, generate the report for this DPIA as a Word document. 7 October 2026 coverage Canada: OSFI's technology, third-party and operational resilience guidelines The financial regulation layer now carries guidelines B-13, B-10 and E-21 from Canada's Office of the Superintendent of Financial Institutions, on technology and cyber risk, third-party risk, and operational risk and resilience. OSFI gave us written permission to reproduce them. Read the full entry Federally regulated banks and insurers in Canada work to these OSFI guidelines when they assess technology and supplier risk: B-13, Technology and Cyber Risk Management; B-10, Third-Party Risk Management; and E-21, Operational Risk Management and Resilience. Your agent can now search and cite them through the same financial regulation layer that serves the European regulators. OSFI's guidelines are Crown copyright, so we asked before we fetched. OSFI granted written permission to reproduce the guidelines as published on the date of the grant. Every row carries OSFI's credit line, and we serve the text as OSFI published it. When OSFI issues a new edition of a guideline, we withdraw that guideline and ask again before we serve the new text. Try it: Using Ansvar, what does OSFI Guideline B-10 expect a bank to do before it outsources a critical service? Scope a search to Canada with jurisdictions=['CA'] . The guidelines are available on every plan. 2 October 2026 gateway Search refuses an over-long query and tells your agent how to split it search and search_guidance now refuse a query longer than 500 characters before any source is searched. The refusal is a typed error that tells the agent to split the matter into short issue queries. Before, a pasted case description failed inside the corpus and read as a source outage. Read the full entry Agents sometimes paste a whole case description into search : the parties, the facts, the dispute, a paragraph or more. The corpora behind search refuse a query longer than 500 characters. Until today that refusal came back from inside the corpus as an untyped error, and the gateway counted it as a source failure. The agent saw "all resolved MCP endpoints failed", or a case-law leg reported as unavailable, and had every reason to read it as an outage. Repeated refusals could also hold that corpus back from other searches for a short while. The gateway now checks the length itself. A search or search_guidance query over 500 characters is refused before any source is searched, so no corpus is called and none is marked as failing. The tool result has isError: true and carries this body: { "error": "validation_error", "code": "query_too_long", "max_chars": 500, "query_chars": 712, "message": "query is 712 characters; search accepts at most 500, so nothing was searched. Split the matter into separate issue queries of 2-5 legal terms, one call per issue, and merge the results. Do not send a truncated copy of the text: a cut-down description does not search better.", "dispatched": false, "automatic_retry": false } The query parameter of both tools now states the limit, so an agent that reads tools/list knows it before the first call. If your client caches tool definitions, refresh the connector to pick up the new wording. What your agent should do with a case description: list the legal issues it raises and search each one in its own call, with 2 to 5 legal terms in the language of the corpus, then merge the answers. Do not send a shortened copy of the description. We tested that on Dutch case law: the opening of an intake text names the parties and the setting, the search ranks on those words, and the decisions that matter rarely come back. Short issue queries were the only approach we tested that found them in useful numbers. Hand your agent the pattern with the case: Using Ansvar, list the legal issues this case description raises and search Dutch case law for each one separately with a few legal terms, such as "ontslag op staande voet" or "dringende reden". Merge the results and cite each decision. The limit and the error are on the tool reference . 28 September 2026 docs gateway Ansvar Compliance Skills is in Anthropic's plugin directory The ansvar-compliance-skills plugin is listed in Anthropic's plugin directory. One install adds our task skills and the Ansvar gateway connector to Claude, Cowork and Claude Code. Read the full entry The ansvar-compliance-skills plugin passed Anthropic's directory review and is now listed there. Until now you installed our agent skills one file at a time. Now one step adds the task skills listed below, together with the connector they need. In claude.ai or the Claude desktop app, open Customize, then Plugins, find Ansvar Compliance Skills under Discover and select Add. The plugin is saved to your account, so Cowork loads it in your next task and Claude Code picks it up when you sign in with the same account. Directory plugins show on the Pro, Max, Team and Enterprise plans. In Claude Code you can also install it straight from its own repository, which doubles as a marketplace: /plugin marketplace add Ansvar-Systems/ansvar-compliance-skills , then /plugin install ansvar-compliance-skills@ansvar-compliance-skills . The plugin bundles the Regulatory Threat Model, Incident Reporting Navigator, CRA Vulnerability Obligations and ISO Standards Expert skills, each vendored unchanged from its own published repository. A new release that also carries the workflow family skills is in preparation. The skills do not answer from model memory. Each one calls the Ansvar gateway for the law it cites, so the plugin needs the connector signed in to your Ansvar account: open the plugin's Connectors tab and connect it. The incident and CRA skills run fully on a free account. The threat-model and ISO skills have plan notes, listed per skill in the guide. Try it after connecting: "Using Ansvar, we have an incident. Who must we notify, in which member state, and by when?" Install steps for every client are in the agent skills guide . 25 September 2026 coverage gateway Slovenian law: the core statutes, consolidated and in force The Slovenian statutes corpus now carries the acts a company, its lawyers and its compliance team work with every week: the civil and commercial codes, labour, tax, procurement, procedure, data protection and cyber security, each in its current consolidated text from PISRS, the state's legal information system. Read the full entry The Slovenian statutes corpus grew from a small starter set into the core of the country's in-force legislation. You can now query the Obligations Code (OZ), the Companies Act (ZGD-1), the Employment Relationships Act (ZDR-1), the Public Procurement Act (ZJN-3), the income tax and VAT acts, civil, criminal, enforcement and administrative procedure, the insolvency act, the Personal Data Protection Act (ZVOP-2), the Information Security Act (ZInfV-1), consumer protection and electronic communications, alongside the Constitution. Each act comes from PISRS, the legal information system run by the Government Legislation Office, in its current consolidated version. We read the licence first. Slovenian copyright law excludes official legislative texts from protection, and the Government Legislation Office publishes the consolidated collection on the national open-data portal under CC BY 4.0. Every row names the office as licensor, carries the licence notice and records that we split each act into provisions. We serve the Slovenian original only. We fetch act by act from a fixed, reviewed list, and we have asked the office for a key to its developer API. Try it: "Using Ansvar, what does the Slovenian Employment Relationships Act say about the notice period for dismissal?" or in Slovenian: "Using Ansvar, kaj Zakon o gospodarskih družbah določa o odgovornosti članov uprave?" You can also look up an article directly, for example Article 131 of the Obligations Code, the general rule on liability for damage. Consolidated texts in PISRS are unofficial; the Official Gazette (Uradni list) remains the authentic source, and each answer links back to the act's PISRS page. Two new judiciary acts, the Courts Act (ZS-1) and the Judges Act (ZSod), apply from 1 January 2027. We serve the acts they replace until then and add the new ones before that date. 22 September 2026 gateway Claim check: validate_claim tests a legal conclusion against the text it cites Your agent hands the gateway its reasoning as a graph: the provisions it cites, the quotes it took, the facts and assumptions it relies on, and the conclusions it draws. The gateway refetches each provision under your own access, compares the quotes with the served text, and reports what each conclusion rests on. It never answers "passed". Read the full entry An agent can cite a real article and still misquote it, or draw a firm conclusion from an assumption it never named. validate_claim catches both before the conclusion reaches your report. Your agent sends its reasoning as a claim graph. A clause node carries the article it rests on and the quote taken from it. A fact node records something you told the agent about your organisation. An assumption node records something the agent assumed. Interpretations and conclusions point at the nodes they depend on and say whether the text settles them or whether they are a reading. The gateway refetches every cited provision under your own tier and add-ons, so a source you cannot reach comes back as withheld, never as content. It compares each quote with the served text and marks the clause bound or not. Strength then flows through the graph: a conclusion carries the strength its weakest input allows, and a conclusion that rests on a fact or an assumption names that dependency. Every response lists what it checked and what it did not. A quote in a different language from the served text counts as a reading at best, and a row served without language metadata stays unverified rather than assumed to match. Send the prose answer alongside the graph and the gateway compares its quotations too. Leave it out and the response says so under not_checked . The response opens with a summary the gateway writes itself: one line per conclusion saying what it rests on (your input, an assumption, matched provisions, resolved evidence whose support is not assessed, or nothing this check could establish), a flag when a conclusion declared settled came back weaker, an attention list carrying every finding whether or not it changed a conclusion, and a relay text your agent is asked to pass on unchanged. The word "unverified" does not appear in it: the summary names the operation performed, never a verdict on the claim. Every response also states what the check cannot do. It does not prove a row was served to you in an earlier call. It does not judge whether the logic translates the law correctly, since a wrong reading can bind to real text. It does not verify that a provision is in force today. Read the output as evidence for your review, not as a verdict. The tool is available on every tier. A large graph citing one corpus takes tens of seconds. When the refetch budget runs out, the response is marked bounded, names how many clauses it did not reach, and leaves them unverified. Try it once your agent has fetched the statute text: "Using Ansvar, build a claim graph for that conclusion and run validate_claim on it before you state it." 22 September 2026 platform pricing A new ansvar.eu: four products, one connection The site now explains Ansvar as four products on one connection: legal and regulatory evidence, living security architecture, compliance assessments, and ISMS as Code. Deploy is a first-class choice, hosted or inside your perimeter. Pricing shows how products and plans fit, and every limit is published. Read the full entry Ansvar has grown into more than a search over law, and the old site had stopped explaining it. The new one names four products and the one question each answers: what the law says (legal and regulatory evidence), what your system is (living security architecture), what you must do and what your risk is (compliance assessments), and how you run the management system (ISMS as Code). All four reach you through the same MCP connection, in the AI client you already use. Deploy is now a page of its own, with hosted, your own Kubernetes, and on-prem or air-gapped side by side, a shared-responsibility table, and the pilot terms. Customer-managed deployment stays at the design-partner stage until the production scope is agreed, and the page says so. Pricing keeps the plans you know and adds a table that shows which product each plan carries, so nothing has to be bought twice. Team is priced per workspace. Two offers are new and provisioned on request while we measure demand: Evidence Pro for one person who needs the interpretive layer, and an architecture workspace licence, self-hosted. Every quota, rate and ceiling the gateway enforces is on the limits page, with the exceptions written out. Licensed ISO standards from SIS are named where they belong: an official distributor licence, per seat, on any plan. The proof we had let slip off the page is back: the OWASP GenAI landscape listing, the Regenold and W&B workflow, the CSA STAR self-assessment, the worked examples and the full sample deliverables. The site carries far less text than before. Where a paragraph used to describe the product, a real artefact now shows it: a cited answer as Claude returns it, a data-flow model with a proposal awaiting assent, a gap finding with its evidence links, a pull request in an ISMS repository. Try the first one yourself: "Using Ansvar, what does the GDPR say about the right to erasure?" 17 September 2026 coverage gateway Canadian Centre for Cyber Security guidance, now served Canada's national cyber security guidance answers through the gateway in English and French: the ITSP, ITSM and ITSAP series, the ransomware playbook and the threat bulletins, each row licensed under the Open Government Licence – Canada and cited to the Cyber Centre's own page. Read the full entry The Canadian Centre for Cyber Security publishes the guidance Canadian organisations are asked to follow: the practitioner series (ITSP), the management series (ITSM), the awareness series (ITSAP), the ransomware playbook, and the threat bulletins and assessments. You can now query them through the gateway, in either official language, and every answer cites the Cyber Centre's page it came from. We read the licence before we ingested a single page. The Cyber Centre's website terms permit non-commercial reproduction only, so on those terms alone the guidance stays out. The Government of Canada's Open Government Portal catalogues the same publications and declares each one under the Open Government Licence – Canada , which permits commercial use with attribution. We serve exactly the publications the portal catalogues, carry the portal record on every row, and have asked the Communications Security Establishment to confirm the reading in writing. A written objection withdraws the corpus. Try it: "Using Ansvar, what does the Cyber Centre's ransomware playbook say about backups?" or in French: "Using Ansvar, que recommande le Centre pour la cybersécurité pour sauvegarder et récupérer les données?" You can also look a publication up by its number, for example ITSP.10.033, the security and privacy controls catalogue. Two publications the portal lists point at pages the Cyber Centre has taken down, so they are absent until the publisher restores them. The Harmonized Threat and Risk Assessment methodology sits in the Cyber Centre's tools section rather than its guidance, and stays out for now. Canada's privacy regulators, federal and provincial, publish under terms that require written permission for commercial reuse; we have written to each of them, and their guidance joins when they answer. 13 September 2026 gateway Inflected-form search on national law Search a national law corpus in its own language and a plural, a definite form or a case ending now finds the provision that carries the base word. The legal text, the citations and the content dates did not change; only the search index was rebuilt. Read the full entry You type Beurteilungen ; the German section is headed Beurteilung der Arbeitsbedingungen . You type firmas electrónicas cualificadas ; the Spanish article says firma electrónica ... cualificada . Those plurals missed the provision. We now index every word in these corpora by its stem as well as by its spelling. A plural, a definite form or a case ending finds the provision that carries the base word. A query that matched before still returns the same rows. We shipped this in waves over the past week, one corpus at a time: German, Austrian, Liechtenstein and German state (Landesrecht) legislation, then Dutch, Spanish, Italian, French, Portuguese, Luxembourg, Belgian, Czech, Polish, Finnish, Estonian, Romanian, Hungarian and Lithuanian law, together with the national drone-rules corpora for Germany, Spain, Belgium, Luxembourg, Hungary and Lithuania. Swedish, Danish and Norwegian law joined them on 13 September. The law itself did not move. We rebuilt the search index over the same text, so the provisions, their citations, the publisher links and the content dates are the ones served the day before. Ask in the language of the corpus, in whichever form fits your sentence: Using Ansvar, was sagen die deutschen Vorschriften über Beurteilungen der Arbeitsbedingungen? Using Ansvar, ¿qué exige la ley española sobre firmas electrónicas cualificadas? Using Ansvar, vad säger svensk lag om behandlingar av personuppgifterna? Stemmers differ by language. German, Dutch, Spanish, Italian, French and Czech fold most of the inflection you would type. Finnish, Estonian, Polish, Hungarian, Romanian and Portuguese run on lighter stemmers: inflected forms are matched, and some endings still need the dictionary form. When a query in one of those languages comes back thin, try the base word. The coverage page lists the jurisdictions behind these corpora. 12 September 2026 coverage EIOPA statements, technical-standards reports and joint ESA products join the guidance source The EIOPA lane of the supervisory-guidance source now serves EIOPA statements, technical-standards reports, the older opinions the publisher's listing left untyped, and the Joint ESA products EIOPA hosts. The standalone eiopa-insurance source is retired; its id keeps working as an alias. Read the full entry The EIOPA lane added on 11 September served four document families. It now serves six: EIOPA statements and technical-standards reports (draft and amended implementing and regulatory technical standards) join the guidelines, opinions, supervisory statements and final reports. The lane also picks up EIOPA opinions the publisher's listing never typed, back to 2012, and the Joint ESA products EIOPA hosts, such as the supervisory statements on the Sustainable Finance Disclosure Regulation, the PRIIPs key information document and the DORA technical standards. A joint product that the EBA or ESMA publications already carry is served once. Letters, research papers, impact assessments, consumer-testing reports, consultation papers and stakeholder-group documents are not part of the set. Documents from before EIOPA's founding in 2011 and statements written for the UK withdrawal or the COVID-19 period are left out by design. The standalone eiopa-insurance source is retired. Its documents are served by this lane with full text and a link to each publication page; the old source id keeps working as an alias, so a saved query that names it still resolves. Using Ansvar, find EIOPA's implementing technical standards on the insurance product information document and any joint ESA supervisory statement on the PRIIPs key information document. Retrieve the relevant publications, distinguish technical standards from guidance, cite each source with its publication date, and name any gaps in coverage or access. The coverage page shows the publications available on your topic; pricing lists plan access to guidance search. The financial services guide explains the research and assessment paths. 11 September 2026 coverage Preparatory works from six more European parliaments, and the closed terms kept whole Bills, government drafts and explanatory reports from the Spanish Congreso, the UK Parliament, the Italian Senato, the Czech Poslanecká sněmovna, the Slovak Národná rada and the Lithuanian Seimas join the German, Austrian and Norwegian material, with the closed legislatures served from their own archive. Read the full entry The European preparatory-works source now carries the current legislature of nine parliaments. New this release: the Spanish Congreso de los Diputados (Boletín Oficial de las Cortes Generales, government and parliamentary bills of the fifteenth legislature), the UK Parliament (bill publications of the current session), the Italian Senato della Repubblica (the Akoma Ntoso archive of the nineteenth legislature), the Czech Poslanecká sněmovna (parliamentary prints of the tenth period), the Slovak Národná rada (bills and explanatory reports of the ninth term) and the Lithuanian Seimas (the drafts registered this year). The Bundestag and Bundesrat, the Austrian Nationalrat and the Storting were already served and continue. Each row cites the parliament's own publication with its licence: the Spanish and Czech material under their statutory exemptions, the UK bills under the Open Parliament Licence, the Italian archive under the Senate's Creative Commons terms, the Slovak and Lithuanian material under their statutory public-domain rules. Nothing is taken from a mirror. Closed legislatures moved to a companion archive source: the German Wahlperioden before the current one, the Bundesrat history, the Italian thirteenth to eighteenth legislatures and the Austrian twenty-sixth and twenty-seventh Gesetzgebungsperioden. The live source stays small and refreshes with each parliament; the archive is rebuilt only when a term closes. A search for a historical Drucksache reaches the archive the same way it reached the live source before. Ask your agent: "Using Ansvar, what did the Spanish government's bill say about the scope of the new customer-service obligations?" The answer cites the BOCG publication, to the document, and the lookup returns the same row. Preparatory works are available from Premium. Scope with sources=['europe-preparatory-works'] for the current terms or sources=['europe-preparatory-works-archive'] for closed ones, or let a jurisdiction search reach them. The coverage page shows the current set. 11 September 2026 coverage EIOPA guidance joins the financial supervisory sources EIOPA guidelines, opinions, supervisory statements and technical-standard final reports are now searchable beside the EBA and ESMA publications, each with its publisher reference and source link. Read the full entry Ansvar now serves EIOPA's final supervisory guidance — guidelines, opinions, supervisory statements and technical-standard final reports — in the same source as the EBA and ESMA publications added on 10 September. Each result names the publisher, the document type and a link to the publication on eiopa.europa.eu. Consultation papers, stakeholder-group documents and joint-ESA products are not part of this set; the joint products belong with the EBA publications. Using Ansvar, find EIOPA's guidance on the supervision of reinsurance placed with third-country reinsurers. Retrieve the relevant publications, distinguish guidance from legislation, cite each source with its publication date, and name any gaps in coverage or access. The coverage page shows the publications available on your topic; pricing lists plan access to guidance search. The financial services guide explains the research and assessment paths. 10 September 2026 workflows Financial assessment workflows for contracts and readiness Prepare DORA ICT contract and register reviews, MiCA CASP readiness assessments, and AMLR readiness assessments with cited evidence and unresolved findings visible. Read the full entry Ansvar adds assessment workflows for DORA ICT contracts, the DORA register of information, MiCA CASP readiness and AMLR readiness. Your agent checks the workflow types available to your account, confirms the evidence needed for the selected assessment, and returns findings with supporting sources and missing evidence identified. Unsupported findings stay unresolved. DORA ICT contracts and register of information assessments are available from Team. MiCA CASP readiness and AMLR readiness assessments are available from Premium. Using Ansvar, list the financial assessment workflows available to my account. Help me select the workflow for a DORA ICT contract review, confirm the evidence it needs, and leave unsupported findings unresolved. If the workflow is unavailable, report that and stop. The financial services guide explains the research sources and assessment paths. Pricing lists plan access, and the agent docs explain how to run workflows through your connected agent. 10 September 2026 coverage Financial supervisory guidance in your agent Search available EBA, ESMA and joint-ESA financial supervisory publications through Ansvar, with source references and publication types visible in the results. Read the full entry Ansvar now serves financial supervisory publications from EBA, ESMA and the joint ESAs. You can retrieve the available guidance and Q&A material through your connected agent, with a reference to the publisher's source. The coverage page shows the publications available on your topic; pricing lists plan access to guidance search. Using Ansvar, check the available ESA guidance sources for DORA ICT risk. Retrieve the relevant publications, distinguish guidance from legislation, cite each source, and name any gaps in coverage or access. The financial services guide explains the research and assessment paths. The existing ESMA sanctions register rows have a separate publication scope; a register entry does not establish access to the full enforcement decision. 9 September 2026 coverage North Rhine-Westphalia's court decisions join the German case law German court decisions grow from a federal-only corpus to 281,813 decisions across two publishers, with the NRWE database of North Rhine-Westphalia's courts served beside the federal benches. Read the full entry German case law on the gateway was federal: the Bundesgerichtshof, the Bundesverwaltungsgericht, the Bundesfinanzhof, the Bundesarbeitsgericht, the Bundessozialgericht and the Bundesverfassungsgericht, as Rechtsprechung im Internet publishes them. Most German litigation never reaches those benches. Ask about a dismissal dispute or a tenancy case and your agent found the federal court's last word on the question, or nothing. The corpus now serves 281,813 decisions from two publishers. Beside the 84,156 federal decisions sit 197,657 from NRWE, the Rechtsprechungsdatenbank of Justiz NRW: the Oberlandesgerichte, Landgerichte and Amtsgerichte of North Rhine-Westphalia, and the state's administrative, labour, social and finance courts. Each row names the publisher that issued it, and your agent can fetch any decision it finds back from that publisher by its reference. Ask your agent: "Using Ansvar, how have the North Rhine-Westphalia courts decided on Kündigungsschutz for employees on parental leave?" It answers from the Landesarbeitsgericht and the Arbeitsgerichte, cited to the decision. Both publishers place their decisions outside copyright as amtliche Werke under UrhG §5, and both anonymise before publication. German court decisions are available from Premium. Scope with sources=['german-court-decisions'] , or let a German or EU-wide search reach them. The coverage page shows the current set. 9 September 2026 coverage The FCA Handbook, now served Every sourcebook of the UK Financial Conduct Authority's Handbook is searchable through the gateway at provision level, with a citation to the section on the FCA's own site. Read the full entry The gateway now serves the FCA Handbook: the rules, guidance and evidential provisions the Financial Conduct Authority publishes for UK financial services firms, from the Principles for Businesses and the Senior Management Arrangements, Systems and Controls sourcebook through the conduct, prudential and specialist sourcebooks. Each provision is served as the FCA's Handbook API publishes it, under the Open Government Licence v3.0, and every row cites the section on handbook.fca.org.uk. The Handbook joins the European financial-regulation corpus, so a question about a UK firm's obligations can be answered beside the EU acts the same firm meets abroad, and a gap analysis or threat model for a regulated firm can cite the Handbook provision by its number. Ask your agent: "Using Ansvar, what does SYSC 4.1 require of a firm's governance arrangements?" The answer comes from the Handbook, cited to the section. The FCA's technical standards and the Handbook glossary are not yet served; they follow when the FCA's endpoints for them answer. The PRA Rulebook is a separate publication under its own licence and is not part of this release. 7 September 2026 coverage NIS2 answered from the national law, across the EU Ask about NIS2 in a member state and the gateway now serves that state's transposing statute for governance, risk-management and incident-reporting duties, with the EU text one call away. Read the full entry A NIS2 question about a member state used to come back as the directive. From today, a jurisdiction-scoped lookup of Article 20, 21 or 23 serves the national transposing provision where one is verified: the Cyberbeveiligingswet for the Netherlands, the loi NIS2 for Belgium, the BSI-Gesetz for Germany, the cybersäkerhetslagen for Sweden, the NISG 2026 for Austria and their counterparts across the Union, each cited to the article of the national gazette text. The mapping is deliberately narrow. A whole article is served only where the national statute carries every paragraph the directive does; otherwise the paragraph that is verified is served and the response says so. The reporting stages of Article 23(4), early warning, notification, intermediate report, final report and progress report, resolve to the national provision for each stage where the statute splits them. Where a state has mapped only part of an article, the gateway serves the EU text and names the mapped paragraphs instead of claiming there is no mapping. Ask your agent: "Using Ansvar, what does Belgian law require for the 72-hour incident notification under NIS2?" The answer is Article 35 of the loi du 26 avril 2024, cited to Justel, with the directive available by asking for the EU text. Portugal joins the same day. The Regime Jurídico da Cibersegurança annexed to Decreto-Lei n.º 125/2025 is served whole again, article by article, after a parser repair, and its governance, risk-management and reporting articles are mapped like the rest. National transposition serving is available on every tier. The coverage page shows the jurisdictions with a served statute; remaining gaps stay visible there rather than being papered over. 6 September 2026 coverage gateway Chinese national law alongside EU regulatory sources Chinese national laws, legislative decisions and State Council administrative regulations are available with Chinese original text and source citations. A new Simplified Chinese page explains how product teams can use them in an EU market-entry review. Read the full entry Chinese product teams preparing for European markets can now find Ansvar's introduction in Simplified Chinese . The page shows how to bring EU regulatory sources and Chinese national-law evidence into the same review, with each jurisdiction's requirements assessed separately. The China coverage record lists the served national layer from the National Database of Laws and Regulations (flk.npc.gov.cn): laws of the National People's Congress and its Standing Committee, legislative decisions, and State Council administrative regulations. Text remains in Chinese, with Ansvar-authored English discovery metadata and citations to the original source. This is an unofficial reproduction; consult the promulgating organ's record. Where portal and corresponding paper text differ, the paper text prevails. For example: "Using Ansvar, retrieve GDPR Article 32 and Article 51 of China's Personal Information Protection Law. Keep each source's original text, publisher and URL. Ask what you need to know about our processing activities before assessing applicability, and list the evidence we should gather for each requirement separately." Local regulations, judicial interpretations and departmental rules are not yet served. GB/GB-T standard body text is excluded, and a reference to a Chinese standard does not establish equivalence with an ISO standard. Licensed ISO clause text requires the relevant entitlement. The evaluation pack carries these national-layer limits too. Mainland connectivity, AI-client availability and working language are confirmed with each prospective customer; the Chinese introduction does not change those arrangements. 5 September 2026 coverage gateway UK cyber security guidance from the NCSC, now served The National Cyber Security Centre's guidance collections and security advisories join the gateway's cyber security corpus for the United Kingdom, crawled from ncsc.gov.uk under the Open Government Licence and cited page by page, so a UK organisation's NIS, Cyber Essentials or board-level questions answer from the regulator's own text. Read the full entry UK cyber security obligations are written in two registers. The statutes (the Network and Information Systems Regulations, the Computer Misuse Act, the Data Protection Act) set the duty; the National Cyber Security Centre explains how to meet it, in guidance collections that regulators, insurers and procurement teams treat as the reference. That second register is now searchable through the gateway beside the UK statutes already served. Every page comes from ncsc.gov.uk itself, under the Open Government Licence v3.0, with the source URL, publisher and licence on each row. The crawl ran against the NCSC's own sitemap at a declared pace with an identifying user agent, and a page is only in the corpus when the full text was retrieved and retained; holding pages, navigation indexes and forms are excluded and recorded, never served as content. Try it: "Using Ansvar, what does the NCSC say a board should ask about ransomware readiness, and which Cyber Assessment Framework outcomes does that map to?" Or scope a search to the United Kingdom with the cyber security sector and a plain term such as supply chain . The UK cyber corpus sits in the same consolidated European cyber security service as the Finnish, Dutch and Swedish authorities, so a NIS2 gap analysis for a group with a UK subsidiary can cite the NCSC guidance beside the national regulators' text in one pass. 4 September 2026 coverage gateway Swedish financial rulebook: Finansinspektionen's FFFS now served Finansinspektionen's föreskrifter and allmänna råd (FFFS) are searchable through the gateway beside the Swedish financial statutes, instrument by instrument from FI's own register, so a Swedish bank's compliance question reaches the binding rulebook and not only the acts that delegate to it. Read the full entry Swedish financial regulation lives on two levels. Riksdagen's acts (lagen om bank- och finansieringsrörelse, värdepappersmarknadslagen, betaltjänstlagen and the rest) set the frame and delegate the detail; Finansinspektionen's författningssamling (FFFS) fills it in — the föreskrifter a bank, fund manager or payment institution is examined against, and the allmänna råd that say how FI reads them. Until today the gateway served the acts only. Every FFFS in force now serves from FI's published register: the consolidated text where FI publishes one, the amending instrument where it does not, each provision keyed by chapter and paragraph and cited to the exact PDF on fi.se with the retrieval date FI's terms ask for. Repealed instruments are left out rather than served as if still binding. Try it: "Using Ansvar, what does FFFS 2014:1 require of a credit institution's internal control function, and which allmänna råd apply?" — or look a provision up directly, for example FFFS 2014:1 chapter 6. The statutes and the rulebook answer together in one search, so a gap analysis or DPIA for a Swedish financial firm can cite the act, the FFFS provision under it, and FI's guidance in one pass. 4 September 2026 coverage gateway Dutch disciplinary tribunal rulings, now served Decisions of the Dutch statutory disciplinary tribunals for the medical, legal, notarial, accountancy, bailiff, veterinary and maritime professions join the gateway as full-text, cited rulings. Read the full entry The gateway now serves the Netherlands' wettelijk tuchtrecht: the rulings of the statutory tribunals that judge the regulated professions. Decisions of the medical colleges and the Centraal Tuchtcollege voor de Gezondheidszorg sit beside those of the tribunals for advocaten, notaries, accountants, gerechtsdeurwaarders, veterinarians and the maritime disciplinary court. All come from the KOOP Open Data Tuchtrecht collection, refreshed from the index the government publishes each day. The gateway serves each ruling in full text, cited to its source and anonymised as the tribunal publishes it. These sit next to the Dutch statute law, court decisions and parliamentary history already on the gateway, so you can follow how a profession's own tribunal has reasoned, not only what the statute says. Ask your agent: "Using Ansvar, how has the medical disciplinary tribunal ruled on informed consent when a patient later disputed the procedure?" The answer comes from the tuchtcollege's own decisions, cited case by case. The rulings are available from Premium. Scope a search with sources=['dutch-tuchtrecht'] , or let a Netherlands search reach them. The coverage page shows the current set. 4 September 2026 coverage gateway Dutch rechtbanken and gerechtshoven join the case-law corpus, with court and date filters The Dutch court-decisions corpus now carries the district courts and courts of appeal beside the Hoge Raad, the Raad van State, the Centrale Raad van Beroep and the College van Beroep voor het bedrijfsleven, and search can narrow decisions by court and by date. Read the full entry Until this week the gateway served Dutch case law from the Hoge Raad alone. It now serves the decisions that rechtspraak.nl publishes as open data from every court in the roster: the highest courts, the gerechtshoven and the rechtbanken, with new decisions following the publisher's own releases. search gained filters for case-law evidence. court takes the corpus's own court code (HR, RVS, CRVB, CBB, GHAMS, RBAMS and the rest), date_from and date_to bound the decision date as full ISO dates. Statute rows are unaffected; the filters are available from Premium, and a filter name the tool does not declare is refused with a structured error rather than ignored. Ask your agent: "Using Ansvar, what has the Rechtbank Amsterdam decided on ontruimingsbescherming since January 2026?" The answer comes from the court's own decisions, each cited by ECLI with a deeplink to rechtspraak.nl. Decisions are available from Premium. Scope a search with sources=['dutch-court-decisions'] or let a Netherlands search reach them, and fetch a decision by ECLI with get_decision . The coverage page shows the current set. 3 September 2026 coverage European Central Bank law and supervisory guidance, now served ECB regulations, decisions, guidelines and opinions join the gateway, with Banking Supervision guides, consultations, the supervisory sanctions register and the TIBER-EU material beside them. Read the full entry The gateway now serves the European Central Bank's legal acts in force: the regulations, decisions and guidelines the ECB adopts for the Eurosystem and for banking supervision, cited to the article as the Publications Office publishes them. The ECB's opinions on draft national and Union legislation sit beside them, back to the first years of the Bank, together with its memoranda and agreements. Banking Supervision material joins in the same source. The ECB guides on capital and liquidity assessment, materiality and assessment methodology, the supervision newsletter articles, the public consultations, the supervisory sanctions register with each decision, the cyber resilience oversight expectations and the TIBER-EU framework are served from the ECB's own pages under the Bank's reuse terms, with the source notice on every row. Ask your agent: "Using Ansvar, what does the ECB expect for DORA threat-led penetration testing?" The answer comes from the TIBER-EU guide and the ECB's own opinion on the regulation, cited to the section. Legal acts and the sanctions register are on the free tier; the supervisory guidance is available from Premium. Scope with sources=['ecb'] , or let an EU-wide search reach it. The coverage page shows the current set. 26 August 2026 gateway docs Ansvar is in the Microsoft Teams and M365 Copilot store Microsoft 365 Copilot users can add the Ansvar agent from the Teams store; it answers from the same cited gateway as every other client. Read the full entry The Ansvar agent for Microsoft 365 Copilot passed Microsoft's store validation and is now listed in the Microsoft Teams and M365 Copilot store . Add it from the store (your tenant admin may need to allow it first), sign in with your Ansvar account, and the agent answers from the gateway with a citation to the official source on every answer. Copilot Studio and every other MCP client keep working as before: see Setup . 26 August 2026 coverage gateway Italian law — Normattiva statutes and the Codice Privacy, now served Italy joins the live jurisdictions on the coverage page: consolidated national legislation from Normattiva plus Italy's data-protection corpus, after a first-hand review of the Italian source licence. Read the full entry Italian national legislation now answers through the gateway, and Italy sits with the live jurisdictions on our coverage page. The corpus is the consolidated text published on Normattiva — the official legislation portal the Istituto Poligrafico e Zecca dello Stato runs for the Presidenza del Consiglio dei Ministri — and every row cites back to its Normattiva URN. Italy's data-protection shelf goes live alongside it: the Codice Privacy (D.Lgs. 196/2003 as amended by D.Lgs. 101/2018) and the Garante's provvedimento n. 467 of 11 October 2018, the list of processing that requires a DPIA under GDPR Article 35(4). A jurisdiction reaches the coverage page only after we have read its licence ourselves, on the publisher's own pages. Italy rested on two findings, both re-verified against primary sources this week. Legge 633/1941 Article 5 places the texts of official acts of the Italian State and its public administrations outside copyright. And Normattiva's open-data terms moved to Creative Commons BY 4.0 on 1 January 2026, commercial use included — before that they were non-commercial. Normattiva's Avviso legale permits reproduction on three conditions our rows meet: name the source, and state that the text is not the authentic version and is available free of charge. Try it: "Using Ansvar, which types of processing does the Garante's provvedimento 467/2018 make subject to a DPIA?" — or ask in Italian: "Using Ansvar, cosa prevede il Codice Privacy sul trattamento dei dati nel rapporto di lavoro?" Court decisions are the known gap. Article 5 covers statutes and administrative acts; it does not reach judgments of the Corte di cassazione, the Consiglio di Stato or the Corte costituzionale, which need a separate basis. Italian case law stays out of the corpus until we have one. 26 August 2026 coverage National consumer protection law, now served National consumer statutes for Austria, Germany, Estonia, Finland, Latvia, the Netherlands, Norway and Sweden join the gateway, next to the EU consumer directives. Read the full entry The gateway now serves national consumer protection statutes for Austria, Germany, Estonia, Finland, Latvia, the Netherlands, Norway and Sweden: consumer sales and contract codes, unfair commercial practice acts, distance and off-premises contract rules, unfair contract terms, product safety law, and the consumer ADR and enforcement acts behind them. Every provision carries a citation to its national publisher. The EU layer sits beside it. The Consumer Rights Directive, the Unfair Commercial Practices Directive, the Unfair Contract Terms Directive, the General Product Safety Regulation and the price indication rules are served at EU level, so your agent can read a directive and the national statute that transposes it in one conversation. Ask your agent: "Using Ansvar, what does Swedish law require before a consumer can cancel a distance purchase?" The answer comes from the statutes as the Riksdag published them, cited to the provision. Search in each statute's own language and scope by country. Coverage grows country by country; the coverage page shows the current set. 25 August 2026 coverage gateway Ontario law — provincial statutes and regulations, now served Ontario joins the gateway as Canada's first provincial corpus: consolidated statutes and regulations from e-Laws, in English and French, each answer cited to the official King's Printer source. Federal and British Columbia coverage refreshed in the same release. Read the full entry Ontario is Canada's largest provincial jurisdiction, and its law now answers through the gateway: the consolidated statutes and regulations published on e-Laws , served in both English and French, with every citation linking back to ontario.ca. The King's Printer for Ontario permits reproduction of statutes, regulations and judicial decisions without charge; our rows carry that attribution and the required not-an-official-version notice. The same release refreshed the rest of the Canadian shelf. The federal corpus and British Columbia are current again, and the corpus data now records each Act's commencement status — groundwork for showing you, in a future release, when a provision you found is not yet in force. Canadian medical-device coverage (SOR/98-282) was refreshed to its 2026 amendments, and its sections now carry their published headings instead of bare section numbers. Try it: "Using Ansvar, what does Ontario's PHIPA require before a hospital discloses personal health information?" — or ask in French: "Using Ansvar, que prévoit la Loi de 2010 sur la responsabilisation du secteur parapublic?" Case law is the known gap: Supreme Court of Canada decisions are licence-cleared for reproduction but the publisher's access controls block automated retrieval, so we are pursuing the official route rather than working around it. Coverage lands when that conversation does. 24 August 2026 coverage gateway BIO2 — the Dutch government security baseline, now served The Baseline Informatiebeveiliging Overheid 2 (BIO2 v1.3) is searchable through the gateway, each government measure keyed to its ISO 27002:2022 control and to the regulation that makes it binding under the Cyberbeveiligingswet. Read the full entry Dutch public-sector bodies — Rijk, provincies, gemeenten, waterschappen — measure their information security against the Baseline Informatiebeveiliging Overheid 2 (BIO2) . Version 1.3, as published in the Staatscourant, is now a corpus on the gateway: Deel 1 (the framework — obligations, ISMS, risk management, the statement of applicability, governance, suppliers, the Cbw relationship) and every Deel 2 overheidsmaatregel , served verbatim from the official publication. Each measure carries its NEN-EN-ISO/IEC 27002:2022 control number and whether it falls under the Cyberbeveiligingsregeling sector overheid — the ministerial regulation, in force with the Cyberbeveiligingswet since 15 August 2026, that turns the BIO2 measures into the statutory minimum for the sector overheid. So a DPIA, gap analysis or threat model for a Dutch public body can cite the measure, the ISO control behind it, and the legal duty that binds it, in one pass. Try it: "Using Ansvar, which BIO2 measures apply to logging and monitoring, and are they mandatory under the Cyberbeveiligingswet?" — or look a measure up directly by its number (for example 5.01.01). The ISO 27002 controls themselves are not reproduced — the BIO2 references them by number, and so do we; the norm text stays with NEN. 17 August 2026 gateway docs Ansvar Gateway listed in the ChatGPT Apps directory ChatGPT users can add the gateway from OpenAI's Apps directory and call it in any chat with @Ansvar Gateway. Read the full entry The gateway passed OpenAI's app review and is now in the ChatGPT Apps directory (page renders logged-out; installing asks for a ChatGPT login). Add it from the directory, sign in with your Ansvar account, and call it with @Ansvar Gateway in any chat. Other clients: see Setup . 17 August 2026 gateway Ansvar Gateway publicly listed on AWS Marketplace AWS customers can find the gateway in AWS Marketplace under Legal & Compliance and AI Security — a free listing that links an AWS account to a free Ansvar account. Read the full entry The gateway passed AWS Marketplace review and is publicly listed as Ansvar Gateway under Legal & Compliance and AI Security in the AI Agents & Tools catalog. The listing is free with no end date: subscribe, set up a free account at app.ansvar.eu , and connect any MCP client via OAuth — the same gateway, found through AWS procurement. 16 August 2026 workflows coverage A DPIA that knows which country it is in The Article 35 screen now queries the national DPIA trigger source for 29 European jurisdictions, each in the authority's own language, and keeps whatever legal status that authority gave it. Read the full entry GDPR Article 35 is shared; the national lists that sit on top of it are not. A DPIA run now screens against the supervisory authority's own Article 35(4) material for 29 jurisdictions — the EU, Iceland, Liechtenstein, Norway, Switzerland and the United Kingdom — querying each in the authority's own language, because an English meta-query misses a list published in Greek, Lithuanian or Icelandic. What comes back keeps the status the authority gave it: Germany's published DSK list and Estonia's expressly indicative guidance are not the same thing, Cyprus's material is a pre-opinion advisory draft and is labelled as one, and Switzerland has no list mechanism at all — its screen runs on the statutory high-risk test in DSG Articles 22 and 23. Luxembourg, Malta and Slovakia are identified but not reproduced: the run records the source as unavailable rather than rebuilding it from model memory, and a negative screening outcome is never grounded on a list that was not actually fetched. The DPIA coverage register publishes the state of every jurisdiction — authority, source, legal status, verification date, known limitation. Try it: "Using Ansvar, run a GDPR Article 35 DPIA for our new HR analytics platform. Confirm the relevant jurisdictions with me, screen the applicable national trigger sources, then continue to the prior-consultation determination." 15 August 2026 docs workflows An agent skill for every workflow family Nine installable skills — one per workflow family — teach an agent how a run works before it starts one: the stage loop, the evidence and citation rules, the family's own method, and paste-ready starters. Generated from the workflow engine's instruction library and imported by checksum. Read the full entry Every workflow family now has an installable agent skill: gap analysis, threat modelling, impact assessments (DPIA and FRIA), TARA, tender review, vulnerability decisions, adversary tabletop, document review, and SORA drone operations — nine in all. A skill is one markdown file the agent reads once and then applies in every conversation, and each of these carries the run loop (how to open a run, what each stage asks for, how to resume one), the delivery rules that govern what a finished report must contain and how the agent relays the receipt the server hands back, the family's own method, and starter questions to paste. They are not copy written for the website: each is generated from the same instruction library the workflow engine runs, then imported here by checksum — the published file, the release manifest that hashes it, and the pinned build are checked against each other in CI, so a skill cannot describe a workflow the engine no longer implements. Install from agent skills : take the SKILL.md or the ready-made ZIP, and connect the gateway. Try it: "Using Ansvar, run a DPIA for our new HR analytics platform and take it through to the prior-consultation determination." 11 August 2026 workflows Medical-device gap analysis, proven end to end The three medical-device workflows (MDR GSPRs, IVDR GSPRs, MDCG 2019-16 cybersecurity) each completed a real production run, accepted on correctness: every citation fetched and re-verifiable, every evidence gap flagged instead of papered over. Read the full entry "Using Ansvar, run a gap_analysis_mdr workflow for our device and assess the Annex I GSPRs against our current technical documentation." Your agent can now run that against a workflow we have proven in production, not just published. On 2026-08-11 each of the three medical-device workflows completed a full run on the live platform, from scoping interview to rendered report, and the runs were accepted on correctness: citations round-trip through the platform's lookup tools with their source, publisher and licence intact, and requirements without supporting evidence carry an explicit flag rather than a decorative citation. gap_analysis_mdr assesses all General Safety and Performance Requirements of MDR Annex I, surfaces the Annex VIII device class because it sets the conformity route, and maps each requirement to the harmonised-standard clauses that demonstrate conformity: IEC 62304, IEC 81001-5-1, ISO 14971, IEC 62366-1 and their siblings. gap_analysis_ivdr does the same for IVDR Annex I, with analytical and clinical performance under Annex XIII treated as the load-bearing requirement. gap_analysis_mdcg_cyber assesses device cybersecurity against MDCG 2019-16 rev. 1 across secure design, technical documentation and post-market obligations, with MITRE ATT&CK available for adversary context. The proof runs assessed fictional manufacturers built with deliberate weaknesses, and the point is what happened to those weaknesses: every planted gap surfaced as a finding, and the assessments found gaps beyond the planted ones, including one requirement the fixture had misclassified as inapplicable. Where the case-law layer returned nothing on point, the finding says case_law_unconfirmed: true instead of citing something adjacent. An assessment you would hand a notified body has to behave that way. The guidance layer behind these workflows is current: the served corpus is reconciled against the Commission's MDCG guidance register including the 2026 series and revisions, and the MDR and IVDR harmonised-standards lists follow the June 2026 implementing decisions. All three workflows are available from the Premium plan. Ask list_workflow_types for the catalog, or start with the prompt above. 9 August 2026 gateway Ask which regulatory deadlines are ahead The gateway now answers the planning question: dated obligation events from EU and national instruments, soonest first, each row citing the provision that states the date. Read the full entry "Using Ansvar, what regulatory deadlines hit us in the next 18 months?" Your agent can now answer that from a curated calendar rather than a client alert's prose. get_regulatory_deadlines returns dated obligation events, soonest first: application dates, commencement dates, transposition deadlines. Each row cites the provision that states the date, so you can read the source yourself. The calendar tracks instruments as amended. Where an omnibus regulation moved a date, or a corrigendum corrected one, the row carries the corrected date and cites the document that states it. Rows name their date precision, record when a curator last verified them, and carry a day count computed at request time. Ask for a jurisdiction and the answer includes the EU-level instruments that bind there. A query for Germany returns the AI Act's staged application dates alongside German national instruments, because an EU regulation binds in every member state. A request parameter turns that off. Coverage at launch is curated and leans European. Every response names what was in scope, and states on every call that absence of a row is not absence of an obligation. The tool serves only from a signature-verified dataset: if a newer dataset fails verification, the previous one keeps serving and every response says so, and if none has ever loaded, the tool refuses with a typed error. get_regulatory_deadlines is available from the Premium plan. Dataset state and freshness report through get_regulatory_intelligence_status , free on every plan. 8 August 2026 docs Let your AI decide whether Ansvar fits One copy-paste evaluation pack at ansvar.eu/evaluate: your own agent interviews you, checks your jurisdictions and frameworks against the audited coverage snapshot, and gives a verdict bound to four honest outcomes — including no current fit. Read the full entry Before you connect anything, your own AI can now tell you whether Ansvar is worth connecting. The new /evaluate page carries a single evaluation pack — copy it into Claude, ChatGPT, Copilot, Gemini, or any client your team already uses. No account, and no browsing capability needed: the pack is self-contained, with the audited coverage snapshot embedded. Your agent asks four questions — jurisdictions, frameworks in play, which AI clients you run, what your agents should do — and then writes a fit report bound to the evidence in the pack. The verdict is one of four: documented fit, conditional fit, no current fit, or insufficient evidence. The rules are explicit and visible on the page: coverage claims may come only from the embedded snapshot, one missing non-negotiable jurisdiction outweighs any number of adjacent matches, and on a negative verdict the report must recommend against signing up rather than steer you to adjacent coverage. We wrote the pack, and it says so — vendor-authored evidence, weighed accordingly. Agents that can fetch URLs find the same pack at /agent-evaluation.md , versioned copies alongside. On a fit, the report ends with the free verification path: connect on the Free plan and re-check the coverage it leaned on with live calls. 6 August 2026 gateway Ask what regulators actually published The gateway monitors official publication channels — the EU Official Journal, Commission and agency announcements, and national gazettes across Europe — and answers from typed records with a citation on every one. Read the full entry 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. Provision-level amendment feeds are not available today, so the gateway withholds get_changes until a supported feed can answer it. 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 A Workflows section on the site with expert-run services folded in, a page for the TARA family, and a page for the canonical control library with a worked crosswalk from a real session. Read the full entry 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 An org-minted service credential matches a signed-in seat of its plan: same tools including workflow runs and document upload, same concurrency, pooled quota, with a per-credential monthly run ceiling. Read the full entry 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 . 31 July 2026 gateway account Sign up with email and password Free accounts no longer need a Microsoft or Google identity: create one directly with an email address and password — verified by email, protected by Cloudflare Turnstile, live on the account area now. Read the full entry 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 A free, open agent skill turns your MCP-connected assistant into a cited ISO standards assistant — licensed clause text from SS-EN ISO/IEC 27001:2023, 27002:2022, 27005:2024, 42001:2026 and SS-ISO/SAE 21434:2021, quoted verbatim with SIS attribution, selected parts only. Read the full entry 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 The free workflow allowance grows from one STRIDE threat model to a pick of seven types (gap analysis for NIS2, DORA, CRA and the EU AI Act, DPIA, generic gap analysis, threat model), reported as a watermarked rendered document. Read the full entry 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 The data-protection corpus adds 1,642 Austrian DSB enforcement decisions and 330 EDPB guidelines and opinions, every row citing its official source page. Read the full entry 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 Team and Company org admins can mint org-owned, read-only OAuth2 service credentials for headless agents — each credential occupies a seat. Read the full entry 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 Creating a free account is now a direct sign-in — Google, Microsoft, or email — with no €0 checkout step. Read the full entry 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 claude.ai and Claude Desktop users can connect the gateway in one click from Anthropic's connector directory. Read the full entry 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 A Level 1 CAIQ v4.0.3 self-assessment with all 261 answers published — including the No answers. Read the full entry 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 . Showing 10 of 50 Show 10 more