EU AI Act and GDPR checks with sources: classify an AI system, trace each duty, find the supervisor.
Scored across 9 tools
Most tools target clearly distinct outputs: general Q&A (answer_question), a coded case check (check_case), a Word DPIA export (export_dpia_intake), enforcement data, provenance, and human referral. The main overlap is the assessment trio (check_case, classify_system, get_applicable_obligations), which all take a concrete system; descriptions mitigate this by stating a sequence and explicitly saying what each does NOT return, but an agent could still hesitate over which assessment to run.
Every tool is snake_case verb_noun (answer_question, check_case, classify_system, get_source_provenance, request_expert_review). The pattern is predictable throughout, with no mixed conventions or vague verbs.
Nine tools is well within the sweet spot and each maps to a distinct capability of a legal compliance assistant (Q&A, assessment, explanation, export, enforcement, provenance, referral). Nothing feels padded or missing at the count level.
The lifecycle is largely covered: ask, assess, explain, export, cite, and escalate. A minor gap is discoverability — identifiers for explain_applicability and get_source_provenance must come from earlier tool output, and get_applicable_obligations is explicitly not a catalogue, so there is no way to browse or search obligations/articles directly.
Use this for a short, general question about the EU AI Act or the GDPR (AVG), such as whether a customer service chatbot has to say that it is AI or when a DPIA is required. It looks the question up in the published Praxikon answers: deterministic, no language model, and with the articles and sources. Before you call it, rewrite the question in general terms in at most 200 characters: no names of people or organisations, no contact details, no numbers that identify a person or a case. A question that looks like it contains personal data is refused. The question never goes into a URL, a server log or an analytics service. Praxikon may keep it, after a filter for personal data, to improve its answers, unless store_for_improvement is false (privacy statement, section 2.7). An unrecognised question returns no answer rather than a constructed one, and so does a question about law outside the EU: Praxikon covers only the EU AI Act and the GDPR. For one concrete system or case, the coded assessment tools give a fuller answer.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the answer. Dutch is the default. | nl |
| question | Yes | The question in general terms, without names, contact details or identifying numbers. | |
| store_for_improvement | No | Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7. |
| Name | Required | Description |
|---|---|---|
| lang | Yes | |
| mode | No | scenario, semantic, gdpr, koppeling, out_of_scope (law outside the EU) or none. |
| view | Yes | |
| answer | No | The compact answer, as the published answer endpoint returns it, without the question. |
| stored | No | |
| message | No | |
| answered | Yes | |
| provenance | Yes | |
| alternatives | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the readOnlyHint/openWorldHint annotations, it discloses that the lookup is deterministic with no language model, that unrecognised or out-of-scope questions return nothing rather than a constructed answer, that personal-data-looking questions are refused, and that the question is never put into a URL, server log or analytics service. The retention behaviour and the store_for_improvement opt-out are spelled out with a policy reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and the two examples are front-loaded, and almost every sentence carries decision-relevant information. It is on the long side, with privacy and retention detail clustered later, but nothing is redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the description still covers everything an agent must know to call it correctly: scope, input sanitisation, refusal behaviour, and data handling. Nothing material is missing for a three-parameter read-only lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real operational meaning: it tells the caller to rewrite the question in general terms, caps it at 200 characters, forbids names, contact details and identifying numbers, and warns that violations cause outright refusal. The retention opt-out parameter is also explained in prose, not just in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (looks the question up in published Praxikon answers) and a tightly bounded resource: short, general questions on the EU AI Act or the GDPR, with two concrete examples. It also explicitly bounds the domain (EU-only, no concrete cases), so an agent can separate it from the coded assessment siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use it (short general questions, e.g. chatbot disclosure, DPIA triggers) and, crucially, when not to: 'For one concrete system or case, the coded assessment tools give a fuller answer,' which routes to classify_system, check_case or explain_applicability. Out-of-scope law outside the EU is also named as a refusal case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user describes a concrete, intended use of AI or of personal data (a system, a project, a supplier) and wants to know whether a DPIA, a FRIA or duties under the GDPR (AVG) and the EU AI Act come into play. It runs the Praxikon case check: fixed rules over fixed answers, the same rules as the case check on the site. It returns per law (GDPR, AI Act, and where the two meet) each test with its outcome, the article and a source link, the DPIA and FRIA signal, the next steps and the facts that are still open. Fill in the answers yourself from what the user said, and ask the user for a fact that decides a test rather than guessing it. Leave out what is not known: it counts as unknown, never as no. Send only these coded answers and never the case text, names or other personal data; there is no field for them. Show the notice with the result. It does not build the implementation graph or the obligation list of one AI system.
| Name | Required | Description | Default |
|---|---|---|---|
| org | No | What kind of organisation uses the system? Values: public = Government or public-law legal person (municipality, implementing agency, GGD, public university, public-authority school); public_service = Private organisation providing a public service (e.g. privately run school or college, care foundation, housing association); company = Company or other private organisation. | unknown |
| lang | No | Language of the result. Dutch is the default. | nl |
| role | No | What is the role of that organisation with regard to the AI system? Values: deployer = Uses a system from a supplier (deployer); provider = Develops it itself and places it on the market under its own name (provider); both = Develops it itself and also uses it itself (provider and deployer); gpai = Makes a general-purpose AI model, such as a language model, for others. | unknown |
| scale | No | Does it involve many people, or are people systematically monitored or observed? For example thousands of data subjects, all residents or customers, or continuous monitoring with cameras, location or software. | unknown |
| domain | No | What is the system used for? Areas of Annex III or Annex I of the AI Act. For other insurance than life or health, or for fraud detection, choose none. Values: public_benefits = Granting, reducing or recovering benefits, allowances or other public services; credit = Creditworthiness or credit score of natural persons; life_health_insurance = Risk assessment and pricing in life or health insurance only; emergency = Classifying emergency calls or emergency healthcare; employment = Recruitment, selection, evaluation or task allocation of staff; education = Admission, evaluation or monitoring of tests in education; biometrics = Biometric identification or categorisation of people; law_enforcement = Police and criminal investigation; migration = Migration, asylum or border control; justice = Administration of justice or elections; critical_infra = Safety component of critical infrastructure (energy, water, traffic); product = Part of a product with CE marking, such as a medical device; none = None of these. | unknown |
| effect | No | Does the outcome have legal effects or affect people significantly (benefit, job, loan, investigation, exam)? | unknown |
| special | No | Does it involve special categories of personal data (health, genetic, biometric, racial or ethnic origin, religion or belief, political opinion, trade union membership, sex life or sexual orientation)? | unknown |
| aiSystem | No | Is it an AI system: does it infer the outcome from data itself (machine learning, language model), rather than only applying fixed rules written by a human? Fixed rules drawn up by people, such as a calculation rule or a written-out decision tree, are not. A model trained on examples is, even if it stops learning once in use. An expert system that draws its own conclusions from encoded knowledge can be too. | unknown |
| criminal | No | Does it involve personal data relating to criminal convictions or offences, including a suspicion? Art. 10 GDPR: for example a criminal record, a criminal case, or a suspicion or report of an offence. | unknown |
| transfer | No | Do the data go to a country outside the European Economic Area, including via the supplier or a cloud? | unknown |
| automated | No | Is the decision about a person taken without a human assessing the case on its merits? Also yes if a human only sees part of it, such as the top ten, and the rest get a decision, such as a rejection, without human review. Merely not being selected for closer checks is no decision. | unknown |
| frequency | No | For how long and how often is the system used? Values: continuous = Continuously, with no end date: for every application or case, or every day; periodic = Periodically, with no end date: in fixed rounds, for example monthly or yearly; limited = For a limited period, such as a pilot or a one-off project. | unknown |
| inService | No | Was the system put into service or placed on the market before 2 December 2027? Also yes if it is in use now or goes into use before that date, or if the same type and model was on the EU market or in use before then (Recital 39 of Regulation (EU) 2026/1744). A significant change in its design or intended purpose afterwards makes it count as new. | unknown |
| profiling | No | Does the system produce a score, ranking or prediction about persons (profiling)? Scoring businesses (establishments, declarants, licence holders): yes only if sole traders or other natural persons are among them; only legal persons: no. | unknown |
| interaction | No | Does the system do one or more of these things? Values: chatbot = People talk or chat with it directly; generated = It creates text, images, audio or video; deepfake = It creates images, audio or video that look real (deepfake); emotion = It recognises the emotions or mood of people. | |
| apCategories | No | Categories of the Dutch Data Protection Authority list of processing that requires a DPIA (Stcrt. 2019, 64418) that the facts confirm; leave out any the facts do not show. | |
| personalData | No | Are personal data processed (data about identifiable people)? | unknown |
| interactionKnown | No | Whether interaction is settled, so that an empty list means none of these. Defaults to true when interaction is sent, false when left out; never false when interaction lists items. | |
| store_for_improvement | No | Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7. |
| Name | Required | Description |
|---|---|---|
| dpia | Yes | |
| fria | Yes | |
| lang | No | |
| laws | Yes | |
| view | Yes | |
| notice | Yes | |
| sources | No | |
| headline | Yes | |
| law_date | No | |
| left_out | No | |
| provenance | Yes | |
| answers_used | No | |
| outcome_note | No | |
| full_check_url | Yes | |
| open_questions | Yes | |
| outcome_labels | No | |
| recommendations | No | |
| transition_note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it is a safe read, but the description adds that results come from fixed rules over fixed answers, matching the website's check. It discloses the return contents (per-law tests with outcomes, article, source link, DPIA/FRIA signal, next steps, open facts) and an important privacy constraint: send only coded answers, never case text or personal data, and show the notice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger and purpose come first, then behavior, then the data-handling rule and the exclusion. It is dense and a couple of sentences are long, but nearly every sentence carries information an agent needs to call it correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 19 parameters, an output schema and rich annotations, the description covers trigger, exclusions, how to derive answers, unknown-handling, data minimization and the notice requirement. An agent has everything needed to call it without opening the schema, and return values are covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the enum definitions are already detailed, so the schema does most of the work. The description still adds real meaning by saying the agent must fill answers itself, must ask rather than guess when a fact decides a test, and must treat omitted facts as unknown rather than no.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it runs the Praxikon case check over GDPR, AVG and the EU AI Act for a described intended use. It also names what it is not — it does not build the implementation graph or the obligation list of one AI system — which separates it from get_applicable_obligations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening clause gives the exact trigger (user describes a concrete intended use and wants to know whether DPIA, FRIA or GDPR/AI Act duties apply), and the closing sentence excludes the obligation-list use case. It also gives operational guidance to ask the user for a deciding fact rather than guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this as the first step when you hold a concrete AI system and need to know which routes of the EU AI Act come into view: prohibited practice screening, Annex III high risk, transparency, FRIA and the general purpose model route, and with a version 2 profile the wider set of duties, such as Article 26 for a deployer. It runs the deterministic decision engine over coded answers and returns one applicability status per assessed obligation, with the timing and what is still open. It is not meant for a general question about the law. An obligation the engine did not assess is listed in assessment_scope.not_assessed with the reason; it was not found inapplicable. It does not return a single coded classification label.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the labels and explanations. Dutch is the default. | nl |
| detail | No | Amount of data to return. brief keeps the outcome, the dates, the reasons, the open questions and the source with its locator; full adds the complete objects, every statement text and every hash, for re-computation or archiving. | brief |
| profile | Yes | The coded answers about one system. The fifteen version 1 fields are required. A field that does not bear on this case takes not_relevant, and unsure is a real answer that leads to insufficient_context rather than to a guess. A version 1 profile has five obligations assessed. To have the wider set assessed, including Article 26 for a deployer of a high risk system, also send profile_version 2.0.0, chain_roles (consistent with actor_role) and the twelve other version 2 scope facts: ai_system_scope, jurisdiction_established_in_eu, jurisdiction_market_in_eu, jurisdiction_output_in_eu, scope_exclusion, annex_i_product, annex_i_third_party_conformity, article_25_role_change, provider_outside_eu, sandbox_participation, real_world_testing and adverse_significant_decision. The remaining version 2 facts are optional: an unanswered fact is unknown and leads to insufficient_context, never to a silent no. The backend rejects a profile whose answers contradict each other. | |
| store_for_improvement | No | Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7. |
| Name | Required | Description |
|---|---|---|
| view | No | |
| notes | No | |
| dataset | Yes | |
| privacy | No | |
| profile | No | |
| sources | No | |
| summary | Yes | |
| disclaimer | No | |
| provenance | Yes | Which published endpoints produced this result. Every call is listed with its full URL, so a reader can re-issue it and check the answer rather than trust it. |
| obligations | Yes | |
| snapshot_id | No | |
| blocking_flags | No | |
| deadline_notes | No | |
| open_questions | No | |
| assessment_scope | No | What this assessment did and did not assess, from the engine itself. not_assessed groups the obligations that were not assessed by reason (for example profile_version_below_2), with the facts that would have them assessed. Not assessed is not the same as not applying. |
| evaluation_scope | No | |
| payload_hash_sha256 | No | |
| decision_engine_version | No | |
| snapshot_schema_version | No | |
| evaluated_obligation_ids | No | |
| not_indicated_obligation_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and non-destructive annotations, the description explains that a deterministic decision engine runs over coded answers, returns one applicability status per assessed obligation with timing and open points, and does not return a single classification label. It also clarifies that obligations missing from assessment_scope.not_assessed were not found inapplicable, which is important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary use case and then adds only necessary scope, return behavior, and caveats. Despite covering a complex classification tool, every sentence contributes to correct selection or interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested input schema, the output schema, and the read-only annotations, the description is complete enough for an agent to decide when and how to call it. It covers scope, versioned behavior, return shape at a high level, and the meaning of unassessed obligations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the nested profile schema fully documents the coded facts, enums, version 1 versus version 2 requirements, and not_relevant handling. The description adds little parameter-level detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: classify a concrete AI system against the routes of the EU AI Act. It lists the routes it covers and explicitly distinguishes its purpose from a general legal question, which also routes the agent away from a sibling like answer_question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage guidance: use it as the first step when holding a concrete AI system, and it is not meant for a general question about the law. The when-not is explicit, though it does not name sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this whenever you have to justify why an obligation does or does not bear on a case, and an outcome on its own is not enough. It returns the legal path: the conditions under which the rule is about a situation, the exceptions under which it is not despite those conditions, and the statements of the obligation split by kind, each with the primary source, the locator inside that source and the source record behind it. Supply a profile as well and the deterministic rule trace is added: which rule was met, not met or unknown for this case, plus the assumptions and the questions the engine could not settle. Use this rather than paraphrasing an obligation yourself: the conditions, the exceptions and the citations are published data and are not to be reconstructed from prose. Take the identifier from earlier tool output; a short form such as art. 26 resolves when it points at one obligation, else error_code and suggestions come back. A question without an identifier belongs with the short question tool or the case check.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the labels and explanations. Dutch is the default. | nl |
| detail | No | Amount of data to return. brief keeps the outcome, the dates, the reasons, the open questions and the source with its locator; full adds the complete objects, every statement text and every hash, for re-computation or archiving. | brief |
| profile | No | The same coded profile that classify_system takes, with the same fields and codes: see the profile schema of classify_system. Send a version 2 profile to have the wider set assessed, including Article 26 for a deployer. The server validates the profile against that full schema. | |
| known_at | No | Knowledge time pin, a date or an ISO instant. Defaults to the release default. | |
| effective_at | No | Legal time pin, a date or an ISO instant. Defaults to the release default. | |
| obligation_id | Yes | The stable identifier, for example praxikon:eu:ai-act:obligation:article-50-transparency. | |
| store_for_improvement | No | Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7. |
| Name | Required | Description |
|---|---|---|
| pin | No | The release and the two time axes this answer resolved against. Store it next to anything you keep: an unpinned query is not reproducible, because the defaults move with each release. |
| view | No | |
| caveats | No | |
| message | No | |
| sources | Yes | |
| assessment | Yes | Present only when a profile was supplied and the decision engine assessed this obligation for it. Null otherwise, with the reason in assessment_absent_reason and, when the engine said why, the detail in not_assessed. |
| error_code | No | |
| legal_path | Yes | |
| obligation | Yes | |
| provenance | Yes | Which published endpoints produced this result. Every call is listed with its full URL, so a reader can re-issue it and check the answer rather than trust it. |
| suggestions | No | |
| not_assessed | No | Why the engine did not assess this obligation for this profile, as the engine reported it, with the facts that would have it assessed. For example profile_version_below_2: send a version 2 profile. |
| requested_id | No | |
| identifier_resolution | No | |
| assessment_absent_reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, closed-world, so the bar is lower, but the description still adds real behavior: ambiguous short-form identifiers return error_code plus suggestions, and the profile path adds assumptions and unsettled questions from the engine. It also asserts the returned citations are published data rather than prose. It stops short of describing pagination or latency, hence not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but every sentence carries distinct information — when to use, what is returned, profile effects, identifier sourcing, and fallback routing. The opening sentence leads with usage rather than the operation itself, which slightly delays the core statement, but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema, annotated safety profile, and fully described parameters, the description covers the remaining agent-critical gaps: eligibility, identifier provenance, ambiguity/error handling, privacy-relevant retention, and which sibling to use instead. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description still adds meaning by explaining what supplying 'profile' actually changes (deterministic rule trace of met/not-met/unknown with assumptions) and that obligation_id accepts a short form like 'art. 26' with a defined resolution/error path. That is effect-level semantics the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and output: the legal path behind one obligation — its conditions, exceptions, and source-split statements — plus an optional deterministic rule trace when a profile is supplied. It is clearly separable from siblings like get_applicable_obligations or answer_question, and the title reinforces the 'path, not just outcome' framing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the trigger explicitly ('whenever you have to justify why an obligation does or does not bear on a case'), names an exclusion ('use this rather than paraphrasing an obligation yourself'), gives the prerequisite (take the identifier from earlier tool output), and routes identifier-less questions to 'the short question tool or the case check'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants the DPIA intake of a concrete, intended use of AI or of personal data as a Word file to work on, and, where the FRIA comes into play, the FRIA draft too. It takes the same fixed fact answers as the case check of Praxikon, as coded choices, and gives the same documents as the download on the site: the four parts of Article 35(7) GDPR with the seventeen points of the Dutch government model DPIA, each point filled from the facts given, partly filled, or left as an open question, with articles and source links. Leave out what is not known: it counts as unknown and becomes an open question, never a no. Send only the coded answers and never the case text, names or other personal data; there is no field for them. The answer gives a download_url: the case check on the site with the answers in the part after #, which the browser never sends to the server; opening it shows the outcome and builds the Word file in the user's browser. Give the user that link, the explanation and the summary, and show the notice. Praxikon keeps no copy of the file.
| Name | Required | Description | Default |
|---|---|---|---|
| org | No | ||
| lang | No | Language of the document. Dutch is the default. | nl |
| role | No | ||
| scale | No | ||
| domain | No | ||
| effect | No | ||
| special | No | ||
| aiSystem | No | ||
| criminal | No | ||
| transfer | No | ||
| automated | No | ||
| frequency | No | ||
| inService | No | ||
| profiling | No | ||
| interaction | No | ||
| apCategories | No | ||
| personalData | No | ||
| interactionKnown | No | ||
| store_for_improvement | No | Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7. |
| Name | Required | Description |
|---|---|---|
| date | No | |
| dpia | Yes | |
| fria | Yes | |
| lang | No | |
| view | Yes | |
| title | Yes | |
| notice | Yes | |
| stored | Yes | |
| summary | Yes | What the intake holds, point by point, as plain text to show in the chat. |
| documents | Yes | |
| provenance | Yes | |
| explanation | Yes | |
| fria_reason | No | |
| download_url | Yes | The case check with the answers in the URL fragment; the browser builds the Word file. |
| fria_included | Yes | |
| rules_version | No | |
| full_check_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint/destructiveHint annotations, the description discloses that no copy of the file is kept, that the download_url carries answers in the fragment which the browser never sends to the server, and that the Word file is built client-side. It also states an important semantic behavior: unknown facts are treated as unknown and become open questions, "never a no."
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The usage trigger is front-loaded, which is good, but the middle section is a dense run-on chain of clauses and the closing "Praxikon keeps no copy of the file" partly restates the earlier browser-side explanation. It is informative yet longer and less scannable than needed for a 19-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, privacy-sensitive export tool with an output schema, the description covers the essential operational facts: what is produced, the download_url handoff, how the agent should present the link/explanation/summary/notice, and the personal-data prohibition. Remaining gaps are the individual code meanings and the language/store_for_improvement options, the latter partly covered by the schema itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11% across 19 parameters, so the description must carry the load. It adds real semantic rules — send only coded answers, omit unknowns, no field exists for case text or personal data, and codes/meanings match check_case's input — but it never explains what individual codes such as scale, effect, special, domain, or interactionKnown mean, deferring that to the sibling tool's schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete outcome: producing the DPIA intake of a specific intended AI/data use as a Word file, plus the FRIA draft where applicable, with the four Article 35(7) parts and seventeen model-DPIA points. It relates itself to the sibling check_case ("the same fixed fact answers as the case check"), so an agent can tell the two apart by output. It stops short of a crisp one-line distinction ("check_case gives the outcome, this gives the downloadable document").
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when the user wants ... as a Word file to work on" is an explicit selection trigger, and the FRIA condition is spelled out. However, no explicit when-not or "use check_case instead if the user only needs the assessment" routing is given, leaving the agent to infer the boundary with the sibling that shares the same inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need the obligations themselves for one assessed system rather than the classification picture: which obligations apply, which possibly apply, from when, why, and on which source and locator. Returns one entry per assessed obligation, filtered by applicability. A version 2 profile has the wider set assessed, including Article 26 for a deployer of a high risk system, with one sub result per paragraph. This is the assessed route, not a catalogue of all obligations in the dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the labels and explanations. Dutch is the default. | nl |
| detail | No | Amount of data to return. brief keeps the outcome, the dates, the reasons, the open questions and the source with its locator; full adds the complete objects, every statement text and every hash, for re-computation or archiving. | brief |
| profile | Yes | The same coded profile that classify_system takes, with the same fields and codes: see the profile schema of classify_system. Send a version 2 profile to have the wider set assessed, including Article 26 for a deployer. The server validates the profile against that full schema. | |
| applicability | No | Which applicability statuses to return. Defaults to applies and possibly_applies. The counters and evaluated_obligation_ids stay complete whatever you filter on, so a filtered list can never be read as the whole assessment. | |
| store_for_improvement | No | Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7. |
| Name | Required | Description |
|---|---|---|
| view | No | |
| dataset | No | |
| sources | No | |
| summary | Yes | |
| disclaimer | No | |
| provenance | Yes | Which published endpoints produced this result. Every call is listed with its full URL, so a reader can re-issue it and check the answer rather than trust it. |
| filtered_on | No | |
| obligations | Yes | |
| snapshot_id | No | |
| deadline_notes | No | |
| assessment_scope | No | What this assessment did and did not assess, from the engine itself. not_assessed groups the obligations that were not assessed by reason (for example profile_version_below_2), with the facts that would have them assessed. Not assessed is not the same as not applying. |
| evaluation_scope | No | |
| decision_engine_version | No | |
| evaluated_obligation_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and non-destructive, so the safety bar is low; the description still adds real behavioural context: one entry per assessed obligation, applicability filtering, and the version-2 profile producing a wider assessed set with one sub result per paragraph. It doesn't cover error or validation failure behaviour, which is the remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the selection condition and the scope distinction, and no sentence is filler. The version-2/Article 26 sentence is somewhat dense and duplicates the profile parameter description, which costs a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema, nested profile object, and full schema coverage, the description supplies everything left: which route this is, what the filter does, and how profile version changes the assessed set. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter descriptions are unusually rich (lang, detail, applicability, store_for_improvement all documented, including the counters-stay-complete caveat). The description adds little beyond that, restating the version-2 profile behaviour already present in the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('returns one entry per assessed obligation, filtered by applicability') for one assessed system. It explicitly contrasts itself with 'the classification picture' and with 'a catalogue of all obligations in the dataset', which separates it from classify_system and from catalogue-style siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear when-to-use framing ('Use this when you need the obligations themselves... rather than the classification picture') plus an explicit exclusion ('not a catalogue'). It stops short of naming explain_applicability or answer_question as the alternatives an agent should weigh, so routing against the closest sibling still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this for the national layer: which authority is designated in a member state, how far the implementing law has come, and which dated enforcement signals are recorded, each with a primary source. The authority is recorded as free text per member state and is deliberately not a graph identifier, because which national body fills the market surveillance role differs per member state. The same call returns the ruling register: judgments and supervisory decisions with the relation they bear to a provision (interprets, narrows, broadens, confirms, contradicts, or illustrates for context). An event says what happened, a ruling says what we know a provision means. Never present a related_gdpr ruling as AI Act case law: it rests on the GDPR and carries the illustrates relation only. This tool takes no lang: the tracker carries both languages on every record, in the fields that end in _nl and _en.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Narrow to one event type, for example implementing_law. | |
| detail | No | Amount of data to return. brief keeps the outcome, the dates, the reasons, the open questions and the source with its locator; full adds the complete objects, every statement text and every hash, for re-computation or archiving. | brief |
| country | No | ISO 3166-1 alpha-2 country code, for example NL. Omit for all member states. | |
| known_at | No | Knowledge axis of the ruling register, as YYYY-MM-DD: returns the rulings we had recorded on that date and nothing that arrived afterwards. A provision keeps its own effective_at; only the reading moves. | |
| obligation | No | Slug of an obligation, for example article-50-transparency. Returns the rulings that bear on it. An empty result on an existing obligation means no ruling is recorded, not that the slug is wrong. | |
| store_for_improvement | No | Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7. |
| Name | Required | Description |
|---|---|---|
| view | No | |
| stats | No | |
| events | Yes | |
| filters | No | |
| rulings | Yes | |
| version | No | |
| countries | Yes | |
| provenance | Yes | Which published endpoints produced this result. Every call is listed with its full URL, so a reader can re-issue it and check the answer rather than trust it. |
| verified_at | No | |
| events_total | No | |
| ruling_register | No | |
| empty_result_note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read, but the description adds substantial behavior: the authority is free text deliberately not a graph identifier, the call also returns the ruling register, and the lang parameter is absent because both _nl and _en fields ship on every record. It also warns that related_gdpr rulings rest on the GDPR and carry only the illustrates relation, which prevents a real misinterpretation of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a usage directive and no wasted preamble; every sentence carries content. It is dense overall, and the event-versus-ruling aphorism could be trimmed given an output schema exists, but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile, full schema coverage and an output schema, the remaining burden is domain framing, which the description supplies: what the national layer contains, how rulings relate to provisions, source citation, and the bilingual field convention. An agent could call this correctly and interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description earns credit above it by explaining why no lang parameter exists and how records carry both languages, and by framing the ruling register that known_at and obligation filter against. It does not add syntax detail for type, country or detail, but the schema already does that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource concretely: designated national authority, implementing-law progress and dated enforcement signals, plus a ruling register, each with a primary source. That is specific enough to separate it from answer_question or check_case, though it never names a sibling and the purpose is buried in a long first sentence rather than stated as a crisp verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this for the national layer' clearly sets the selection context and the register semantics tell the agent what it is getting back. There are no explicit exclusions or named alternatives among the siblings, so an agent must infer when to prefer this over check_case or get_applicable_obligations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this before you quote, cite or hand on anything from this graph, and whenever a reader asks on what authority a statement rests. It returns, for one object, every statement with its kind, its primary source, the locator inside that source and the review metadata, plus the source records behind those citations and a ready made citation block with the identifier, the object version, the payload hash and the release. Works for any object type, not only obligations, and for a GDPR object under praxikon:eu:gdpr as well, which is read from the GDPR obligations graph. Take the identifier from earlier tool output; a short form such as art. 26 resolves when it points at one obligation, else error_code and suggestions come back.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the labels and explanations. Dutch is the default. | nl |
| detail | No | Amount of data to return. brief keeps the outcome, the dates, the reasons, the open questions and the source with its locator; full adds the complete objects, every statement text and every hash, for re-computation or archiving. | brief |
| known_at | No | Knowledge time pin. | |
| entity_id | Yes | The stable identifier of any object, for example praxikon:eu:ai-act:guidance:..., praxikon:eu:ai-act:obligation:... or praxikon:eu:gdpr:obligation:... . An identifier in the flat raip:<type>:<slug> form published up to dataset 1.1.0 resolves to the same object. | |
| effective_at | No | Legal time pin. | |
| store_for_improvement | No | Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7. |
| Name | Required | Description |
|---|---|---|
| pin | No | The release and the two time axes this answer resolved against. Store it next to anything you keep: an unpinned query is not reproducible, because the defaults move with each release. |
| view | No | |
| found | Yes | |
| entity | No | |
| review | No | |
| caveats | No | |
| message | No | |
| sources | Yes | |
| citation | No | |
| error_code | No | |
| provenance | Yes | Which published endpoints produced this result. Every call is listed with its full URL, so a reader can re-issue it and check the answer rather than trust it. |
| statements | Yes | |
| suggestions | No | |
| requested_id | No | |
| source_review | No | |
| statement_counts | No | |
| identifier_resolution | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, closed-world behavior, and the description adds substantial context: the exact response components, the brief/full distinction, the identifier-resolution behavior, and the error_code/suggestions fallback. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences lead with the use case, then explain outputs and scope, then the identifier rule. Despite its length, each sentence carries actionable information and nothing is repeated from schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a provenance tool with six parameters and an output schema, the description covers when to call it, what it returns, scope across object types, and identifier resolution. The safety profile is already in annotations, so no required context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents lang, detail, known_at, effective_at, and store_for_improvement. The description adds meaningful guidance for entity_id (take it from earlier output; short forms resolve only when unambiguous), which goes beyond the schema, but it does not discuss the remaining parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a provenance lookup for one object: it returns statements, sources, locators, review metadata, source records, and a citation block. It also states the scope (any object type and GDPR objects), but it does not explicitly name sibling tools or contrast itself with them, so it is clear but not fully sibling-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger ('before you quote, cite or hand on anything' and 'whenever a reader asks on what authority') and notes the object-type and GDPR scope. It does not state when not to use it or name an alternative sibling, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this only when the user asks for it in their own words: they want to talk to a person, ask for a human expert, or ask how to get in touch about their situation. Never call it on your own initiative, never as a closing suggestion, and never because an answer seems uncertain. It returns a link to book a 30 minute introductory call with Zahed Ashkara, an independent AI and privacy consultant behind Praxikon. Send no part of the conversation: the tool takes only a language and, optionally, a topic from a fixed list, and nothing about the user. Show the title, the sentence and the link to the user as they are, and let the user decide whether to book.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the text and of the booking page. Dutch is the default. | nl |
| topic | No | Optional subject of the question, from this fixed list only. It travels in the link as a campaign label (utm_content) to the booking page, so the booking can be traced to this tool. It is the only thing from the conversation that does; it names no person. | |
| store_for_improvement | No | Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| lang | Yes | |
| note | No | |
| text | Yes | |
| title | Yes | |
| topic | No | |
| provenance | Yes | |
| duration_minutes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it discloses the return value (a booking link), the human on the other end, and a privacy contract — no conversation content is sent, only a language and an optional fixed-list topic, with an opt-out via store_for_improvement. It also instructs that the title/sentence/link be shown verbatim rather than paraphrased. No contradiction with readOnlyHint=true or openWorldHint=false; producing a URL is not an external interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the gating condition before any mechanics, and each sentence carries a distinct duty (trigger, prohibitions, return value, data handling, presentation). Slightly dense in the final sentence about showing title/sentence/link, but nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description supplies the non-obvious essentials an agent needs: who the call is with, that contact data is never transmitted, and how to present the result. Nothing required for correct, safe invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents lang, topic and store_for_improvement in detail, and the baseline would be 3. The description adds the framing that matters for correct invocation — 'the tool takes only a language and, optionally, a topic from a fixed list, and nothing about the user' — which reinforces the enum constraint and the data-minimisation rule rather than duplicating field text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (request a call with a human expert) and immediately specifies what the tool actually produces: a booking link for a 30-minute introductory call with a named consultant. The action is unmistakably distinct from analytical siblings like answer_question or classify_system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the positive trigger (only when the user asks in their own words to talk to a person / get in touch) and three explicit prohibitions: never on own initiative, never as a closing suggestion, never because an answer seems uncertain. It also hands the final decision to the user, which resolves the follow-up ambiguity an agent would otherwise have.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_case5 fields changedInput schema / properties / aiSystem / descriptionPrevious value: -"Is it an AI system: does it infer the outcome from data itself (machine learning, language model), rather than only applying fixed rules written by a human? A system that only applies fixed rules drawn up by people, such as a calculation rule or a written-out decision tree, is not an AI system. A model trained on examples is, even if it does not keep learning after it is put into use. An expert system that draws conclusions by itself from encoded knowledge can be an AI system too."New value: +"Is it an AI system: does it infer the outcome from data itself (machine learning, language model), rather than only applying fixed rules written by a human? Fixed rules drawn up by people, such as a calculation rule or a written-out decision tree, are not. A model trained on examples is, even if it stops learning once in use. An expert system that draws its own conclusions from encoded knowledge can be too."Input schema / properties / apCategories / descriptionPrevious value: -"Categories of the Dutch Data Protection Authority list of processing that requires a DPIA (Stcrt. 2019, 64418) that the facts of the case confirm. Leave out any category the facts do not show."New value: +"Categories of the Dutch Data Protection Authority list of processing that requires a DPIA (Stcrt. 2019, 64418) that the facts confirm; leave out any the facts do not show."Input schema / properties / domain / descriptionPrevious value: -"What is the system used for? These areas are listed in Annex III or Annex I of the AI Act. For other insurance than life or health, or for fraud detection, choose none. Values: public_benefits = Granting, reducing or recovering benefits, allowances or other public services; credit = Creditworthiness or credit score of natural persons; life_health_insurance = Risk assessment and pricing in life or health insurance only; emergency = Classifying emergency calls or emergency healthcare; employment = Recruitment, selection, evaluation or task allocation of staff; education = Admission, evaluation or monitoring of tests in education; biometrics = Biometric identification or categorisation of people; law_enforcement = Police and criminal investigation; migration = Migration, asylum or border control; justice = Administration of justice or elections; critical_infra = Safety component of critical infrastructure (energy, water, traffic); product = Part of a product with CE marking, such as a medical device; none = None of these."New value: +"What is the system used for? Areas of Annex III or Annex I of the AI Act. For other insurance than life or health, or for fraud detection, choose none. Values: public_benefits = Granting, reducing or recovering benefits, allowances or other public services; credit = Creditworthiness or credit score of natural persons; life_health_insurance = Risk assessment and pricing in life or health insurance only; emergency = Classifying emergency calls or emergency healthcare; employment = Recruitment, selection, evaluation or task allocation of staff; education = Admission, evaluation or monitoring of tests in education; biometrics = Biometric identification or categorisation of people; law_enforcement = Police and criminal investigation; migration = Migration, asylum or border control; justice = Administration of justice or elections; critical_infra = Safety component of critical infrastructure (energy, water, traffic); product = Part of a product with CE marking, such as a medical device; none = None of these."Input schema / properties / interactionKnown / descriptionPrevious value: -"Whether the answer to interaction is settled, so that an empty list means none of these. Defaults to true when interaction is sent and to false when it is left out; never false when interaction lists items."New value: +"Whether interaction is settled, so that an empty list means none of these. Defaults to true when interaction is sent, false when left out; never false when interaction lists items."Input schema / properties / profiling / descriptionPrevious value: -"Does the system produce a score, ranking or prediction about persons (profiling)?"New value: +"Does the system produce a score, ranking or prediction about persons (profiling)? Scoring businesses (establishments, declarants, licence holders): yes only if sole traders or other natural persons are among them; only legal persons: no."check_case2 fields changedInput schema / properties / inService / descriptionPrevious value: -"Was the system put into service or placed on the market before 2 December 2027? Also yes if it is in use now, or goes into use before that date. This concerns this system in its current form: if its design changes significantly afterwards, it counts as new."New value: +"Was the system put into service or placed on the market before 2 December 2027? Also yes if it is in use now or goes into use before that date, or if the same type and model was on the EU market or in use before then (Recital 39 of Regulation (EU) 2026/1744). A significant change in its design or intended purpose afterwards makes it count as new."Input schema / properties / org / descriptionPrevious value: -"What kind of organisation uses the system? Values: public = Government or public body (municipality, implementing agency); public_service = Private organisation providing a public service (e.g. education, healthcare, housing association); company = Company or other private organisation."New value: +"What kind of organisation uses the system? Values: public = Government or public-law legal person (municipality, implementing agency, GGD, public university, public-authority school); public_service = Private organisation providing a public service (e.g. privately run school or college, care foundation, housing association); company = Company or other private organisation."get_source_provenance1 field changedInput schema / properties / entity_id / descriptionPrevious value: -"The stable identifier of any object, for example praxikon:eu:ai-act:guidance:... or praxikon:eu:ai-act:obligation:... . An identifier in the flat raip:<type>:<slug> form published up to dataset 1.1.0 resolves to the same object."New value: +"The stable identifier of any object, for example praxikon:eu:ai-act:guidance:..., praxikon:eu:ai-act:obligation:... or praxikon:eu:gdpr:obligation:... . An identifier in the flat raip:<type>:<slug> form published up to dataset 1.1.0 resolves to the same object."answer_question1 field changedInput schema / properties / store_for_improvementAdded value: +{
+ "default": true,
+ "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+ "type": "boolean"
+}check_case1 field changedInput schema / properties / store_for_improvementAdded value: +{
+ "default": true,
+ "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+ "type": "boolean"
+}classify_system1 field changedInput schema / properties / store_for_improvementAdded value: +{
+ "default": true,
+ "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+ "type": "boolean"
+}explain_applicability1 field changedInput schema / properties / store_for_improvementAdded value: +{
+ "default": true,
+ "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+ "type": "boolean"
+}export_dpia_intake1 field changedInput schema / properties / store_for_improvementAdded value: +{
+ "default": true,
+ "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+ "type": "boolean"
+}get_applicable_obligations1 field changedInput schema / properties / store_for_improvementAdded value: +{
+ "default": true,
+ "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+ "type": "boolean"
+}get_national_enforcement1 field changedInput schema / properties / store_for_improvementAdded value: +{
+ "default": true,
+ "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+ "type": "boolean"
+}get_source_provenance1 field changedInput schema / properties / store_for_improvementAdded value: +{
+ "default": true,
+ "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+ "type": "boolean"
+}request_expert_review1 field changedInput schema / properties / store_for_improvementAdded value: +{
+ "default": true,
+ "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+ "type": "boolean"
+}answer_question1 field changedOutput schema / properties / mode / descriptionPrevious value: -"scenario, semantic, gdpr, koppeling or none."New value: +"scenario, semantic, gdpr, koppeling, out_of_scope (law outside the EU) or none."check_case4 fields changedOutput schema / properties / expert_reviewRemoved value: -{
- "required": [
- "tool",
- "text"
- ],
- "type": "object"
-}Output schema / properties / outcome_labelsAdded value: +{
+ "type": "object"
+}Output schema / properties / outcome_noteAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "view",
- "headline",
- "dpia",
- "fria",
- "laws",
- "open_questions",
- "notice",
- "full_check_url",
- "expert_review",
- "provenance"
-]New value: +[
+ "view",
+ "headline",
+ "dpia",
+ "fria",
+ "laws",
+ "open_questions",
+ "notice",
+ "full_check_url",
+ "provenance"
+]explain_applicability5 fields changedOutput schema / properties / error_codeAdded value: +{
+ "enum": [
+ "unknown_identifier",
+ "ambiguous_identifier"
+ ],
+ "type": "string"
+}Output schema / properties / identifier_resolutionAdded value: +{
+ "type": "object"
+}Output schema / properties / messageAdded value: +{
+ "type": "string"
+}Output schema / properties / requested_idAdded value: +{
+ "type": "string"
+}Output schema / properties / suggestionsAdded value: +{
+ "type": "array"
+}get_source_provenance5 fields changedOutput schema / properties / error_codeAdded value: +{
+ "enum": [
+ "unknown_identifier",
+ "ambiguous_identifier"
+ ],
+ "type": "string"
+}Output schema / properties / identifier_resolutionAdded value: +{
+ "type": "object"
+}Output schema / properties / messageAdded value: +{
+ "type": "string"
+}Output schema / properties / requested_idAdded value: +{
+ "type": "string"
+}Output schema / properties / suggestionsAdded value: +{
+ "type": "array"
+}answer_questioncheck_caseclassify_systemexplain_applicabilityexport_dpia_intakeget_applicable_obligationsget_national_enforcementget_source_provenancerequest_expert_reviewAI inventory and EU AI Act compliance. Find AI tools and use cases, check new AI uses before launch.
Deterministic, sourced EU compliance checks: NIS2, DORA, GDPR and the Cyber Resilience Act.
Classify any AI system under the EU AI Act: risk tier + binding Articles, verbatim from the law.
Classify AI systems by EU AI Act risk tier, estimate fines, write Art. 50 notices, list deadlines.
Add one secure layer between your agents and this server.