Skip to main content
Glama

Classify AI System Under EU AI Act

euaiact_classify_system
Read-onlyIdempotent

Classify an AI system's risk level under the EU AI Act. Provide system details and set structured signals to get the risk class, applicable Annex III category, articles, and next questions.

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). A decisive signal you could not set comes back in missing_signals with the question to ask the user; ask, then call again. 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
lexbeam_urlNo
next_questionsYes
matched_signalsYes
missing_signalsYes
relevant_articlesYes
annex_iii_categoryYes
role_determinationYes
obligations_summaryYes
risk_classificationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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."
  2. 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"
      +}
  3. 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"
      +}
  4. First observedv1.1.5

TDQS

A5/5.0
Behavior5/5

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

Annotations already indicate readOnlyHint and idempotentHint, and the description adds important behavioral context beyond those: classification is deterministic on signals, free text alone often returns insufficient_information, missing decisive signals are returned as missing_signals with questions to relay, and Art. 6(3) exceptions cannot be auto-applied. This gives the agent an accurate model of how the tool behaves.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, calling convention, signal-setting rules, failure behavior, return contents, and an exception routing note. The critical HOW TO CALL guidance is front-loaded, and no filler or redundant restatement is present.

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

Completeness5/5

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

Given the complex nested signals schema, the annotations, and the presence of an output schema, the description is complete enough for an agent to call the tool correctly. It covers the workflow, the main error case (insufficient_information), what to do about missing signals, and what the response contains, while the schema covers the individual parameter details.

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

Parameters5/5

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

With schema description coverage at 50%, the description compensates strongly. It explains how to construct the central signals object, warns against guessing, clarifies that signals.domain must not be inferred from sector, and directs the agent to read the field description. It also explains the role of description as insufficient on its own, which is not obvious from the schema alone.

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

Purpose5/5

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 an AI system's risk level under the EU AI Act (Regulation 2024/1689). It also clarifies the deterministic signal-based behavior and the exact outputs returned, making it clear what this tool does and distinguishing it from a generic assessment tool.

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

Usage Guidelines5/5

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

The description gives explicit how-to-call instructions: derive structured signals from the user's description, pass them with description, set signals only when supported, never guess, and ask follow-up questions before calling again. It also names a specific sibling (euaiact_assess_art6_3_exception) for the Art. 6(3) case, which is a clear alternative-selection rule.

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