Skip to main content
Glama

Classify AI System Under EU AI Act

euaiact_classify_system
Read-onlyIdempotent

Determine an AI system's risk level under the EU AI Act using structured signals. Returns classification, Annex III category, relevant articles, and provider/deployer determination.

Instructions

Classify an AI system's risk level under the EU AI Act (Regulation 2024/1689). HOW TO CALL: derive the structured signals from the user's description yourself and pass them together with description. The result is decided deterministically on the signals; free text alone is only matched against keywords and often returns insufficient_information. Set a signal only when the description supports it and leave it out otherwise; never guess, and never infer signals.domain from the sector a system operates in (read that field's description). missing_signals lists unprovided fields, including optional context; it is not a checklist of facts required for the reported result. Relay next_questions where present, then call again with the answers. A matched route does not establish that every other route has been ruled out. Returns risk classification, applicable Annex III category, relevant articles, provider/deployer determination, matched signals, and follow-up questions the agent should relay. Note: Art. 6(3) exceptions require documented justification and cannot be auto-applied; use euaiact_assess_art6_3_exception.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleNounknown
signalsNo
use_caseNoSpecific context where the system is deployed
descriptionNoFree-text description of the AI system and its functionalities

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
basisYes
caveatYes
confidenceYes
next_questionsYesSuggested user questions for unresolved facts. May be empty when a route matches even though other signals were not supplied.
matched_signalsYes
missing_signalsYesUnprovided fields, including optional context. Not every entry is needed for the reported route; consult next_questions for follow-up guidance.
relevant_articlesYes
annex_iii_categoryYes
role_determinationYes
obligations_summaryYes
risk_classificationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.7.0
    • removedOutput schema / properties / lexbeam_url
      Removed value: -{
      -  "type": "string"
      -}
    • addedOutput schema / properties / missing_signals / description
      Added value: +"Unprovided fields, including optional context. Not every entry is needed for the reported route; consult next_questions for follow-up guidance."
    • addedOutput schema / properties / next_questions / description
      Added value: +"Suggested user questions for unresolved facts. May be empty when a route matches even though other signals were not supplied."
  2. Changed1 schema field changedv1.6.0
    • changedInput schema / properties / signals / properties / domain / description
      Previous value: -"Primary sector where the system operates"New value: +"The Annex III area whose LISTED use the system itself performs. Annex III regulates specific uses, never a sector: choose an area only when the system does one of the uses listed for it below, and choose `other` when it merely operates in that sector (a utility's billing chatbot, a school timetable, a payroll check, fleet maintenance for the police, appointment booking at an immigration office, a court-room scheduler, legal research for a law firm). Leave it out when the description does not let you tell. Listed uses: biometrics: for remote biometric identification, biometric categorisation according to sensitive or protected attributes, or emotion recognition of natural persons, in so far as their use is permitted under Union or national law. Sole-purpose biometric verification to confirm that a specific natural person is who they claim to be is excluded from Annex III(1)(a). | critical_infrastructure: as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating, and electricity. | education: to determine access to or admission to educational and vocational training institutions, to evaluate learning outcomes, to assess the appropriate level of education, or to monitor and detect prohibited behaviour during tests. | employment: for recruitment, selection, job advertising targeting, application filtering, candidate evaluation, promotion and termination decisions, task allocation, and monitoring or evaluation of work performance and behaviour. | essential_services: for the specific essential-service use cases listed in Annex III(5): public-authority eligibility decisions for essential public assistance benefits and services, creditworthiness or credit scoring of natural persons (with the exception of AI systems used for the purpose of detecting financial fraud, Annex III(5)(b)), risk assessment and pricing for life and health insurance, and emergency-call classification, dispatch, prioritisation, or emergency healthcare triage. | law_enforcement: by or on behalf of law enforcement authorities for victim risk assessment, polygraphs and similar tools, evaluation of evidence reliability, assessing the risk of a natural person offending or re-offending, assessment of personality traits or past criminal behaviour of natural persons or groups, or profiling natural persons in criminal detection, investigation, or prosecution. | migration: by competent public authorities in migration, asylum, and border control as polygraphs or similar tools, for assessing risks posed by natural persons entering a Member State, for examining applications for asylum, visa, and residence permits, and for detecting, recognising, or identifying natural persons in border control. Verification of travel documents is excluded from Annex III(7)(d). | justice: to assist judicial authorities in researching and interpreting facts and law and in applying the law to concrete facts, or to be used to influence the outcome of elections or referendums or the voting behaviour of natural persons. Campaign administration or logistics tools are excluded where natural persons are not directly exposed to the output. | health, gpai, product_safety: not Annex III areas; use them for a health context, a general-purpose AI model, or a safety component of a product under Annex I."
  3. Changed2 schema fields changedv1.5.0
    • addedInput schema / properties / signals / properties / social_scoring_unjustified_or_disproportionate
      Added value: +{
      +  "description": "Social scoring leads to detrimental or unfavourable treatment that is unjustified or disproportionate to the social behaviour or its gravity (Art. 5(1)(c)(ii))",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / signals / properties / social_scoring_unrelated_context
      Added value: +{
      +  "description": "Social scoring leads to detrimental or unfavourable treatment in social contexts unrelated to the contexts in which the data was originally generated or collected (Art. 5(1)(c)(i))",
      +  "type": "boolean"
      +}
  4. Changed6 schema fields changedv1.3.0
    • addedInput schema / properties / signals / properties / biometric_publicly_accessible_space
      Added value: +{
      +  "description": "Real-time remote biometric identification takes place in publicly accessible spaces (Art. 5(1)(h))",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / signals / properties / biometric_remote_identification
      Added value: +{
      +  "description": "System performs remote biometric identification, not merely one-to-one biometric verification",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / signals / properties / biometric_sole_purpose_verification
      Added value: +{
      +  "description": "Biometric use is solely to verify that a specific natural person is the person they claim to be, which is excluded from Annex III(1)(a)",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / signals / properties / performs_social_scoring
      Added value: +{
      +  "description": "System evaluates or classifies natural persons or groups over time based on social behaviour or personal/personality characteristics, leading to detrimental treatment (Art. 5(1)(c))",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / signals / properties / performs_social_scoring_by_public_authority / description
      Previous value: -"System is used by or on behalf of a public authority to score natural persons (Art. 5(1)(c))"New value: +"Legacy alias: public-authority social scoring. Art. 5(1)(c) is not limited to public authorities."
    • addedInput schema / properties / signals / properties / requires_third_party_conformity_assessment
      Added value: +{
      +  "description": "The product or AI system is required to undergo third-party conformity assessment under the applicable Annex I legislation",
      +  "type": "boolean"
      +}
  5. First observedv1.1.5

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, not open-world), but the description adds substantial non-obvious behavior: results are decided deterministically on signals, free text alone is keyword-matched and often yields 'insufficient_information', and a matched route does not rule out other routes. It also warns that Art. 6(3) exceptions cannot be auto-applied, which is exactly the kind of guardrail annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The paragraph is dense but front-loaded: purpose first, then a labeled 'HOW TO CALL' block, then return contents, then the related-tool note. Nearly every sentence earns its place (determinism, missing_signals semantics, next_questions loop). It is a single wall of text rather than segmented, which slightly hurts scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool with a nested signals object, 4 parameters, and an output schema, the description covers what an agent needs: how to populate signals, the iterative next_questions loop, and the Art. 6(3) handoff. Return values are described even though an output schema exists, so nothing critical is missing; only the overlap with euaiact_assess_system is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, so the description must compensate, and it does: it explains how `signals` should be derived, that unset signals should be omitted rather than guessed, and clarifies that `missing_signals` (returned) is not a checklist. The `domain` caution is reinforced by the schema's own long enum description rather than fully restated, which keeps it at a 4 rather than 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb, resource, and legal instrument ("Classify an AI system's risk level under the EU AI Act (Regulation 2024/1689)"), which is far more specific than a tautology. It also carves out the Art. 6(3) exception work to a named sibling. However, it never distinguishes itself from the closest sibling, 'euaiact_assess_system', leaving the agent to guess which of the two classification entry points to use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'HOW TO CALL' block gives explicit operational guidance: derive `signals` yourself and pass them with `description`, set a signal only when the description supports it, never guess, and never infer `signals.domain` from a sector. It routes Art. 6(3) work to euaiact_assess_art6_3_exception. It lacks an explicit when/when-not contrast against the similarly named euaiact_assess_system sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.