PRISM — EU AI Act Compliance Record-Keeping Ontology
PRISM extends AIRO (AI Risk Ontology), the W3C Data Privacy Vocabulary (DPV) 2.3, and its EU AI Act extension (eu-aiact) with structured mappings from legal obligations to compliance record types, sector-specific interpretations, and attestation workflows. It is designed to underpin audit-grade AI governance record-keeping for providers and deployers of AI systems under the EU AI Act. Version 0.4.0 adds an agentic AI profile (agent components, action-space and autonomy classifications, controls, oversight design, agent identity and delegation records, agentic risks, and agent-specific testing and change management records) whose vocabulary is drawn from IMDA (Singapore)'s Model AI Governance Framework for Agentic AI v1.5; mappings from that voluntary framework to EU AI Act articles are interpretive.
Economic Sector
An economic sector classification based on NACE Rev. 2, identifying where an AI system operates. Distinct from eu-aiact Annex III sectors, which determine which obligations apply.
Financial and Insurance Activities
NACE Rev. 2 section K. For sector-specific purposes use sector-finance: terms with dpv:hasPurpose.
Human Health and Social Work Activities
NACE Rev. 2 section Q. For sector-specific purposes use sector-health: terms with dpv:hasPurpose.
Education
NACE Rev. 2 section P. For sector-specific purposes use sector-education: terms with dpv:hasPurpose.
Infrastructure
NACE Rev. 2 sections D (Energy), E (Water/waste), F (Construction), H (Transport). For sector-specific purposes use sector-infra: terms with dpv:hasPurpose.
Law Enforcement and Justice
NACE Rev. 2 section O (specifically O84.23 — Justice and judicial activities). For sector-specific purposes use sector-law: terms with dpv:hasPurpose.
Public Administration and Defence
NACE Rev. 2 section O (broad public administration). sector-publicservices is a draft DPV module — use the versioned URI. For sector-specific purposes use sector-pub: terms with dpv:hasPurpose when stable.
Regulatory Process
An AI Act-specific procedure that occurs at one or more AI lifecycle stages. Not a lifecycle stage itself.
Conformity Assessment
The AI Act procedure in which conformity is formally assessed, either through self-assessment (Module A) or third-party assessment for biometric and Annex I systems (Articles 43-44).
Supply Chain Verification
The AI Act procedure in which importers and distributors verify that an AI system complies before placing it on the market (Articles 43-44).
Market Entry
The AI Act procedure covering formal market placement: EU Declaration of Conformity, CE marking, and EU AI Database registration (Articles 47-49).
Governance Activity
An ongoing governance activity that spans multiple AI lifecycle stages. Not bound to a single stage.
Internal Processes
Ongoing internal governance and quality management obligations including the quality management system and corrective actions (Articles 16-17, 20).
Risk Assessment
Risk assessment activities including the Fundamental Rights Impact Assessment (FRIA) for Annex III high-risk use cases (Article 27).
Applicability Condition
A set of conditions that determine when an EU AI Act obligation applies. Conditions can include actor role, risk level, lifecycle stage, use case category, entity type, or any combination. An obligation may have multiple ApplicabilityConditions (disjunction — any one set of conditions is sufficient).
Chat Bot
An AI system designed to interact with natural persons via text or speech. Providers and deployers of chatbots must disclose to users that they are interacting with an AI system, as required by Article 50(1). Pending eu-aiact modelling of this system type.
AI Content Generator
An AI system that generates synthetic images, audio, video, or text. Providers must label AI-generated content (deepfakes) under Article 50(3), and AI-generated text on matters of public interest under Article 50(4). Pending eu-aiact modelling of this system type.
Compliance Record
A structured record that provides evidence of compliance with one or more EU AI Act obligations. Records must be attested by a named individual to be considered evidential. Subclass of airo:Documentation.
Risk Management Record
Documents the risk management system for a high-risk AI system, as required by Article 9. Must cover the full lifecycle and be updated continuously. Subclass of both prism:ComplianceRecord and airo:RiskControl.
Data Governance Record
Documents data governance and management practices for training, validation, and testing datasets, as required by Article 10. Covers relevance, representativeness, error-freeness, and bias mitigation. Article 10(5) specifically requires bias detection and mitigation measures using special-category data where strictly necessary, with appropriate safeguards.
Article 10
Article 10(1)–(4) — general data governance for high-risk AI systems.
Article 10(5) — bias detection and mitigation using special-category data, applicable in sectors where discriminatory outcomes are particularly harmful (employment, credit, insurance, education, essential services).
Technical Documentation Record
Documents the technical documentation demonstrating compliance, as required by Article 11 and specified in Annex IV.
Logging Record
Documents the automatic logging capabilities designed into a high-risk AI system and the retention of those logs, as required by Articles 12 and 19. Article 12 requires logging capabilities to be designed in; Article 19 requires retention of logs during operation.
Articles 12, 19
Transparency Record
Documents transparency obligations. For high-risk systems (Article 13): instructions for use provided to deployers. For Article 50 systems: disclosure that users are interacting with AI (chatbots), that content is AI-generated (deepfakes), or that emotion recognition/biometric categorisation is in use.
Article 50
Article 13 — providers of high-risk AI systems must supply instructions for use to deployers.
Article 50(1) — providers and deployers of chatbots must disclose to users that they are interacting with an AI system.
Article 50(2)/(3)/(4) — providers must label AI-generated content (deepfakes, synthetic audio/video/images, AI-generated text on matters of public interest) and disclose emotion recognition or biometric categorisation use.
Human Oversight Record
Documents the human oversight measures in place for a high-risk AI system. For providers (Article 14): design measures enabling effective human control. For deployers (Article 26): operational implementation of oversight. Must identify the named overseer, their authority, and any intervention events.
Oversight Intervention
A timestamped, append-only record of a named individual overriding or modifying an AI system's output. Cryptographically hashed at write time.
Accuracy, Robustness and Cybersecurity Record
Documents the measures ensuring accuracy, robustness, and cybersecurity of a high-risk AI system, as required by Article 15.
Article 15
Quality Management System Record
Documents the quality management system covering governance, testing, incident handling processes, and procedures for cooperation with competent authorities, as required by Article 17. Includes documented procedures for responding to authority requests per Art. 22(8), 23(8), 24(5), 26(4).
Corrective Action Record
Documents corrective actions taken to address non-compliance, including notifications to authorities, as required by Article 20.
Article 20
Post-Market Monitoring Record
Documents post-market monitoring activities for a high-risk AI system, including the monitoring plan and ongoing performance tracking, as required by Article 72.
Incident Reporting Record
Documents the reporting of serious incidents to authorities within the required 15-day window, as required by Article 73 (providers, importers, distributors) and Article 26 (deployers). Links to eu-aiact:SeriousIncident which models the incident event itself.
Article 26 — deployers must report serious incidents to provider and market surveillance authorities.
Article 73 — importers must report serious incidents to market surveillance authorities.
Incident Log
An append-only, cryptographically hashed log of serious incidents or malfunctions involving an AI system. Use airo:hasRisk on individual log entries to link to the airo:Risk being documented.
Conformity Assessment Record
Documents the conformity assessment process — either self-assessment (Module A) for most systems, or third-party assessment for biometric and Annex I systems — as required by Articles 43–44.
Self-assessment (Module A) — applies to most high-risk systems.
Third-party assessment required for biometric systems and Annex I safety components (Article 43(1)).
Third-party assessment required for biometric identification/categorisation systems (Article 43(1)).
Supply Chain Verification Record
Documents that an importer or distributor has verified the AI system's compliance with the AI Act before placing it on the market, as required by Articles 23(1)–(2) and 24(1)–(2).
Document Retention Record
Documents that the importer maintains a copy of the EU Declaration of Conformity and has access to technical documentation for 10 years after the AI system has been placed on the market, as required by Article 23(5).
Article 23(5)
Non-Conformity Register
Documents the register of non-conforming AI systems, complaints, and recalls maintained by the importer, including investigations conducted and notifications to distributors, as required by Articles 23(6)–(7).
Articles 23(6), 23(7)
EU Declaration of Conformity Record
Documents the formal EU Declaration of Conformity statement, as required by Article 47.
CE Marking Record
Documents that the CE conformity marking has been affixed to the AI system, as required by Article 48.
EU AI Database Registration Record
Documents registration in the EU AI Database, mandatory before placing a high-risk AI system on the market, as required by Articles 49 and 71. Authorised representatives may perform registration on behalf of the provider per Article 22(3)(a). Public sector deployers must also register before putting high-risk systems into service per Article 49(2).
Articles 49, 71
Article 22(3)(a) — authorised representative registers on behalf of provider.
Article 49(2) — public authorities and Union institutions must register before putting high-risk systems into service.
Use per Instructions Record
Documents that the deployer is using the AI system in accordance with the provider's Instructions for Use, as required by Article 26.
Article 26
Input Data Quality Record
Documents that the deployer ensures appropriate input data is fed to the AI system during operation, as required by Article 26.
Operational Monitoring Record
Documents the deployer's ongoing monitoring of AI system performance during use, as required by Article 26.
Worker Notification Record
Documents that employees and their representatives have been informed where AI systems are used in decisions affecting them, as required by Article 26.
Right to Explanation Record
Documents the deployer's mechanism for providing affected persons with a meaningful explanation of the role the AI system played in a decision, as required by Article 86. Evidenced by explanation templates, documented explanation procedures, or logs of explanations provided to individuals.
Article 86
GPAI Transparency Record
Documents the information and documentation made available to downstream AI system providers to allow them to understand the capabilities and limitations of the GPAI model, as required by Article 53(1)(a). Includes model capabilities, limitations, intended and foreseeable misuse, and integration guidance.
Article 53(1)(a)
GPAI Technical Documentation Record
Documents the technical documentation for a GPAI model, including training methodologies, data sources, computational resources, and evaluation results, as required by Article 53(1)(b). Must be kept up to date and made available to the AI Office and national authorities upon request.
Article 53(1)(b)
Copyright and Training Data Policy Record
Documents the policy for complying with Union copyright law, including the identification and respect of opt-out rights under Article 4(3) of Directive (EU) 2019/790, and a sufficiently detailed summary of training data content, as required by Article 53(1)(c).
Article 53(1)(c)
GPAI Registration Record
Documents registration of the GPAI model in the EU AI Database, as required by Article 53(1)(d).
Article 53(1)(d)
Adversarial Testing Record
Documents adversarial testing and model evaluation (red-teaming) conducted on a GPAI model with systemic risk, including testing methodologies, identified vulnerabilities, and mitigation measures, as required by Article 55(1)(a). Must include state-of-the-art evaluation tools and methodologies.
Article 55(1)(a)
GPAI Incident Reporting Record
Documents the reporting of serious incidents involving a GPAI model with systemic risk to the AI Office and relevant national authorities, as required by Article 55(1)(b). Includes incident description, corrective measures taken, and communication with downstream providers.
Article 55(1)(b)
AI Literacy Record
Documents that the organisation ensures sufficient AI literacy of staff and other persons dealing with the operation and use of AI systems on their behalf, as required by Article 4. Evidenced by training records, competency frameworks, assessment results, and awareness briefings. Scoped to the organisation, not individual AI systems.
Article 4
Authorised Representative Mandate Record
Documents the written mandate from a provider to an authorised representative, covering all obligations listed in Article 22(3). The mandate must be kept up to date and made available to market surveillance authorities upon request. Required by Article 22(1)–(2).
Article 22(1), 22(2)
Fundamental Rights Impact Assessment Record
Documents the FRIA conducted by a deployer, as required by Article 27. Mandatory for specific Annex III use case areas and for all Annex III systems deployed by public sector entities.
Article 27 — FRIA required for deployers of Annex III high-risk systems in specific sectors.
Article 27 — public sector deployers must conduct FRIA for all Annex III high-risk systems.
Attestation Status
The lifecycle status of a compliance record — Candidate (AI-extracted, unreviewed) or Attested (reviewed and signed off by a named individual).
Candidate
Extracted by the AI connector but not yet reviewed. Does not count as evidential coverage.
Attested
Reviewed and signed off by a named individual. Only attested records count as evidential coverage in gap analysis.
has compliance record
Links an AI system to a compliance record. Subproperty of airo:hasDocumentation.
has organisational record
Links an actor (provider, deployer, importer, distributor) to an organisation-level compliance record that is not specific to a single AI system. Used for cross-cutting obligations such as AI literacy (Art. 4).
evidences obligation
Links a compliance record type to the eu-aiact concept(s) it provides evidence for. Where no eu-aiact concept exists yet, this property is omitted and the applicable article is noted via prism:pendingArticle.
pending article
The EU AI Act article(s) this record type evidences, recorded as a string pending the availability of a machine-readable eu-aiact concept. Tooling can query for records with this property to identify gaps in eu-aiact coverage.
has applicability condition
Links a compliance record type or process obligation to the conditions under which it applies.
for actor
The actor role(s) for which this condition applies.
for risk level
The risk level(s) for which this condition applies.
at lifecycle stage
The AI lifecycle stage(s) at which this condition applies. Uses DPV ai:LifecycleStage (ISO/IEC 22989).
for sector
The Annex III sector for which this condition applies (e.g., eu-aiact:EmploymentSector). Uses eu-aiact sector concepts, which are subclasses of dpv:Sector. Distinct from dpv:hasSector on the AI system, which identifies the operational industry via NACE codes.
for system type
The AI system type classification for which this condition applies (e.g., eu-aiact:BiometricCategorisationSystem, eu-aiact:EmotionRecognitionSystem, prism:ChatBot, prism:AIContentGenerator). Only present when the obligation is triggered by a specific system type. May reference prism-local types where eu-aiact has not yet modelled the concept.
for entity type
The type of entity (e.g., public body) for which this condition applies. Only present when the obligation has entity-specific triggers.
occurs at stage
Links a regulatory process to the AI lifecycle stage(s) at which it occurs. Uses DPV ai:LifecycleStage (ISO/IEC 22989).
has attestation status
attested by
attested at
extraction confidence
Confidence score (0.0–1.0) assigned by the AI connector at extraction time.
SHA-256 hash
Hash of the named graph at write time, for immutability verification.
ontology version
The PRISM version under which this record was attested. Used to flag records for re-review when the ontology updates.
review cadence
Annual
Continuous
Process Obligation
An EU AI Act obligation that is behavioural or operational in nature and does not produce a standalone compliance record. Tracked for completeness and queryability. Evidence of compliance is typically subsumed by the Quality Management System or demonstrated through operational procedures.
Importer Contact Information
Importer must indicate their name, registered trade name or registered trade mark, and the address at which they can be contacted on the AI system or its packaging, as required by Article 23(3).
Article 23(3)
Importer Storage and Transport Conditions
Importer must ensure appropriate storage and transport conditions do not jeopardise the AI system's compliance, as required by Article 23(4).
Article 23(4)
Importer Cooperation with Authorities
Importer must cooperate with market surveillance authorities and provide all requested information and documentation to demonstrate conformity, as required by Article 23(8).
Article 23(8)
Distributor Storage and Transport Conditions
Distributor must ensure appropriate storage and transport conditions while the system is under their responsibility, as required by Article 24(3).
Article 24(3)
Distributor Non-Conformity Notification
Distributor must inform provider or importer and market surveillance authority if the AI system presents a serious risk or is non-conforming, as required by Article 24(4).
Article 24(4)
Distributor Cooperation with Authorities
Distributor must cooperate with market surveillance authorities and provide all requested information and documentation, as required by Article 24(5).
Article 24(5)
Deemed Provider Obligation
Where an importer, distributor, or authorised representative places an AI system on the market under their own name or trade mark, or makes a substantial modification, they assume full provider obligations under Chapter 3, as required by Article 25(1). This is a role transition trigger, not a standalone record.
Article 25(1)
Authorised Representative Cooperation with Authorities
Authorised representative must cooperate with competent authorities upon reasoned request and carry out tasks to ensure compliance, as required by Article 22(3)(c).
Article 22(3)(c)
Authorised Representative Documentation Provision
Authorised representative must provide market surveillance authority with all information and documentation necessary to demonstrate conformity of the high-risk AI system, as required by Article 22(3)(b).
Article 22(3)(b)
Authorised Representative Mandate Termination
Authorised representative must terminate the mandate and immediately inform market surveillance authority if the provider acts in non-compliance with its obligations, as required by Article 22(4).
Article 22(4)
Provider Obligations Compliance List
Article 16 lists the full set of provider obligations for high-risk AI systems (Arts. 9–49). Compliance is evidenced by having all required ComplianceRecords in place — this is a meta-obligation, not a standalone record. Gap analysis queries against this obligation should check for completeness of all provider record types.
Article 16
Appointment of Authorised Representative
Providers established outside the EU must appoint an authorised representative by written mandate before placing a high-risk AI system on the EU market, as required by Article 22. Evidence of compliance is the ARMandateRecord held by the appointed representative.
Article 22
Deployer Registration Verification
Private-sector deployers must verify, before putting a high-risk AI system into service, that the provider has registered it in the EU AI Database as required by Article 49(1). Where the deployer is a public authority, they bear their own registration obligation under Article 49(2) — this obligation covers the non-public-sector case only. Evidence of compliance is typically a dated screenshot or confirmation from the EU AI Database, held within the Quality Management System.
Articles 27(1), 49(1), 49(3)
Applies to all non-public-sector deployers of high-risk systems at the point of deployment.
Remote Biometric Identification Notification
Deployers using post-remote biometric identification systems must comply with additional notification and authorisation requirements, as required by Article 26(11). Includes notification to relevant authorities and compliance with national law restrictions.
Article 26(11)
Agentic AI System
An AI system consisting of one or more AI agents that possess some degree of independent planning, decision-making, and action-taking over multiple steps to achieve a user-defined goal (IMDA MGF for Agentic AI §1.1). Describe its bounds with prism:hasAutonomyLevel, prism:hasAgentComponent and prism:hasAgentControl.
Multi-Agent System
An agentic AI system in which multiple agents work together, whether sequentially, under a supervisor, or as a swarm (MGF §1.1.2). Member agents are linked with prism:comprisesAgent; the coordination pattern with prism:hasArchitecture. Multi-agent setups increase exposure to the systemic risks in Section 9e (miscoordination, conflict, collusion, emergent behaviour).
Agent Architecture
A coordination pattern for a multi-agent system (MGF §1.1.2).
Sequential Architecture
Agents work one after another in a linear or otherwise structured workflow; each agent's output becomes the next agent's input.
Supervisor Architecture
One supervising agent coordinates specialised agents under it, calling specific agents as tools when required.
Swarm Architecture
Agents work at the same time, handing off to another agent when needed.
Agent Component
A core component of an agentic AI system as taxonomised in MGF §1.1.1: model, instructions, memory, planning and reasoning, tools, protocols, controls, and logging and monitoring. Each component is a distinct source of risk (MGF §1.2.1) and a distinct locus for technical controls (MGF §2.3.1).
Model Component
The SLM, LLM or MLLM serving as the central reasoning and planning engine of the agent.
Instruction Component
Natural language commands defining the agent's role, capabilities and behavioural constraints, e.g. a system prompt. The level of instruction detail (detailed SOP vs own judgment) is a primary determinant of autonomy.
Memory Component
Short or long-term information storage accessible to the agent. Persistent memory that can store sensitive data across sessions increases the impact of data-related risks (MGF §2.1.1) and is the target of memory poisoning attacks.
Planning and Reasoning Component
The capability to output and follow a series of steps needed for a task. Plans can drift from user intent through hallucination or semantic misalignment (MGF §1.2.1).
Tool Component
A tool enabling the agent to take actions and interact with other systems (files, databases, devices, transactions). The tools an agent may call, and the permissions on those tools, determine its action-space. Declare prism:hasSystemAccess and prism:hasActionScope on each tool.
Protocol Component
A standardised way for the agent to communicate with tools or other agents, e.g. MCP or A2A. Poorly deployed or compromised protocol endpoints (such as untrusted MCP servers) are an agent-specific attack surface (MGF §1.2.1).
Logging and Monitoring Component
Records agent actions, decisions and interactions across all components to enable monitoring, debugging and accountability. For high-risk systems this component realises the Article 12 logging capability documented in a prism:LoggingRecord.
System Access Type
The kind of system a tool, or an agent through its tools, can reach (MGF §1.1.3, action-space). One axis of the action-space; the other is prism:ActionScope.
Sandboxed Access
Sandboxed tools (e.g. for code execution or data analysis) that cannot affect any other system.
Internal System Access
Tools internal to the organisation, such as searching and updating the organisation's databases.
External System Access
Tools that reach external services, e.g. third-party APIs or the open web. Raises both impact (data can leak to third parties) and likelihood (exposure to prompt injection from untrusted content) of risks (MGF §2.1.1).
Action Scope
Whether the agent can only read from, or can also modify, the systems it has access to (MGF §1.1.3).
Read-Only Scope
The agent may only read and retrieve information from the system.
Read-Write Scope
The agent may write to and modify data in the system. Consider the reversibility of those modifications when assessing impact (MGF §2.1.1).
Autonomy Level
The degree to which the agent decides how to act towards a goal, determined by its instructions and the level of human involvement (MGF §1.1.3, drawing on the Knight First Amendment Institute's Levels of Autonomy for AI Agents). The declared level is key evidence for how Article 14/26 human oversight is designed.
Agent Proposes, Human Operates
The human reviews and approves every agent action.
Agent and Human Collaborate
The agent requires human approval at significant steps (e.g. before writing to a database or making a payment); the human can intervene at any time by taking over or pausing the agent.
Agent Operates, Human Approves
The agent requires human approval only at critical steps or failures, such as deleting a database or making a payment above a predefined amount.
Agent Operates, Human Observes
The agent does not require human approval as it completes its task; its actions may be audited after the fact.
Agent Control
A control limiting an agent's action-space or autonomy (MGF §1.1.1). Declare the enforcement layer with prism:implementedAtLayer; prefer structural over prompt-layer enforcement for higher-risk actions (MGF §2.3.1).
Access Control
Limits what an agent is allowed to see, use or change, including restricting access to sensitive data, tools and systems.
Guardrail
Monitors and constrains an agent's behaviour before, during or after it acts; can detect unsafe instructions, policy violations, or actions inconsistent with user intent.
Human Approval Control
A requirement for a human to review or approve agent actions. Its placement is designed through prism:OversightCheckpoint definitions.
Control Layer
The layer at which a control is enforced (MGF §2.3.1). Structural controls are deterministic and cannot be bypassed by the model; prompt-layer controls are inconsistently defined across users and may be bypassed or forgotten.
Structural Layer
Deterministic, system-level enforcement through predefined logic, e.g. access controls at the tool layer that prevent a tool from being called at all.
Model-Based Layer
Enforcement via a model-based safeguard, most effective where risks are hard to define through fixed rules, e.g. harmful-content detection.
Prompt Layer
Enforcement via instructions in the agent's prompt. Weakest layer: may be bypassed or inconsistently applied; avoid as the sole control for higher-risk actions.
Runtime Layer
Enforcement that monitors and intervenes during execution, e.g. rate limits on tool use or input validation before responses are acted upon.
Oversight Checkpoint
A defined point or action boundary in an agentic workflow at which human approval is required before the agent proceeds (MGF §2.2.2). Attach to the system or to a prism:HumanOversightRecord via prism:hasOversightCheckpoint; classify the boundary with prism:hasCheckpointTrigger.
Checkpoint Trigger
The category of action boundary that makes a checkpoint significant (MGF §2.2.2).
High-Stakes Action
Actions such as editing sensitive data, final decisions in high-risk domains, or actions that may trigger liability.
Irreversible Action
Actions that cannot easily be undone, e.g. permanently deleting data, sending communications, making payments.
Outlier or Atypical Behaviour
The agent accessing a system outside its work scope or selecting an action far outside historical norms.
User-Defined Boundary
A boundary the end user defines beyond organisation-set limits, reflecting their own risk appetite, e.g. requiring approval for purchases above an amount.
Oversight Effectiveness Record
Documents measures ensuring that human oversight of an agentic system remains effective over time, notwithstanding automation bias and alert fatigue: measured human override rates, review response times, outlier-reviewer analysis, and overseer training (MGF §2.2.2). Evidences the Article 14(4) requirement that oversight measures enable persons to remain aware of automation bias, and its operational counterpart in Article 26(2).
Articles 14(4), 26(2)
Agent Identity Record
Documents the unique identity of a deployed agent, the party accountable for it, the capacity in which it acts, and its entry in a central agent registry (MGF §2.1.2). Supports Article 12 traceability and helps prevent agent sprawl. Best-practice record derived from the IMDA MGF; not itself an EU AI Act obligation.
Article 12 (traceability, agentic profile)
Delegation of Authority Record
Records a delegation of authority from a human user or organisational role to an agent: who delegated, to which agent, the permission scope granted, and its validity window (MGF §2.1.2). The agent's permissions should not exceed those of the authorising human. Supports Article 14/26 oversight evidence and Article 12 traceability.
Articles 12, 14, 26 (agentic profile)
Agentic Risk
A risk specific to, or significantly amplified by, agentic AI systems (IMDA MGF for Agentic AI §1.2). Use with airo:hasRisk.
Cascading Failure
A mistake in one step propagating and amplifying across later steps of a multi-step workflow, resulting in outsized impact.
Agent Sprawl
Uncontrolled proliferation of agents without centralised management, causing provenance, compatibility and manageability issues. Mitigated by central identity cataloguing (prism:AgentIdentityRecord).
Miscoordination
Agents working together failing through bad communication or diverging interpretations of user intent.
Agent Conflict
Agents optimising different goals coming into conflict, e.g. a support agent offering refunds a revenue-protection agent blocks.
Agent Collusion
Agents developing behaviours that appear coordinated without explicit instruction, e.g. pricing agents converging on higher prices rather than competing.
Emergent Behaviour
Unpredictable behaviour arising when multiple non-deterministic agents interact, which cannot be predicted from testing each agent individually.
Memory Poisoning
An attacker inserting content into an agent's persistent memory to influence later decisions (MGF §2.1.1 threat modelling).
Tool Misuse
The agent calling the wrong tools, the right tools with wrong inputs, hallucinated tools, or tools in a biased manner (MGF §1.2.1).
Prompt Injection
Adversarial instructions embedded in content the agent processes (documents, web pages, tool outputs) redirecting it towards harmful actions, including data exfiltration through its tool access.
Privilege Compromise
An attacker exploiting the agent's credentials or permissions to act beyond the intended authorisation (MGF §2.1.1 threat modelling).
Agentic Testing Record
Documents agent-specific pre-deployment testing across the MGF §2.3.2 dimensions (overall task execution, policy adherence, tool calling, robustness), including whole-workflow testing, multi-agent testing, testing in realistic environments, and repeated runs across varied datasets. Specialises the Article 15 evidence for agentic systems; declare covered dimensions with prism:coversTestingDimension.
Article 15 (agentic profile)
Testing Dimension
A dimension of agent-specific testing (MGF §2.3.2).
Overall Task Execution
Whether the agent can complete its task accurately.
Policy Adherence
Whether the agent follows defined SOPs and routes for human approval when required.
Tool Calling Accuracy
Whether the agent calls the right tools, with the right permissions, with the right inputs, in the right order.
Agent Robustness
The agent's response to errors and edge cases as it reacts and adapts to real-world situations.
Agent Change Management Record
Documents a change to an agentic system under a defined change review process: the trigger that initiated review and the risk category of the change (MGF §2.3.3). Material and critical changes inform the substantial-modification analysis under Articles 25(1)(b) and 43(4), and feed Article 72 post-market monitoring.
Articles 25(1)(b), 43(4), 72 (agentic profile)
Change Trigger
The kind of event that initiates a change review (MGF §2.3.3).
Technical Trigger
Model updates, tool modifications.
Environmental Trigger
Domain shifts, business context changes.
Performance Trigger
Anomalous behaviour, degraded performance.
Regulatory Trigger
Changes in compliance requirements.
Change Category
The risk categorisation of a reviewed change (MGF §2.3.3).
Minor Change
E.g. prompt refinements; follows a lighter review process.
Material Change
E.g. model updates or autonomy adjustments; may require a full governance review and a substantial-modification assessment under Articles 25(1)(b)/43(4).
Critical Change
Changes affecting high-stakes decisions; may mandate an immediate re-risk assessment.
Tooling Provider
An entity providing tools or protocol infrastructure that agents rely on, e.g. hosts of MCP servers or third-party APIs (MGF §2.2.1). Not an EU AI Act actor; obligations towards it are contractual and should be recorded per MGF §2.2.1 (distribution of obligations, third-party opacity).
Agent Platform Provider
An entity providing the platform on which agentic systems are built or operated (MGF §2.2.1). Distinct from the eu-aiact:AIProvider of the resulting system; the platform relationship affects visibility and control and belongs in the risk assessment (MGF §2.1.1, third-party solutions factor).
has agent component
Links an agentic AI system to one of its components (model, instructions, memory, planning, tools, protocols, controls, logging).
comprises agent
Links a multi-agent system to a member agent.
has architecture
The coordination pattern of a multi-agent system (sequential, supervisor, swarm).
has autonomy level
The declared level of human involvement in the agent's decision-making. Key evidence for Article 14/26 oversight design.
has system access
The kind of system reachable (sandboxed, internal, external). Declare on each tool component; may also summarise the widest access at system level.
has action scope
Read-only or read-write scope. Declare on each tool component; may also summarise the widest scope at system level.
has agent control
Links an agentic AI system to a control bounding its action-space or autonomy.
implemented at layer
The enforcement layer of a control (structural, model-based, prompt, runtime). Queryable proxy for control strength: prefer structural for higher-risk actions.
has oversight checkpoint
Links an agentic AI system, or the prism:HumanOversightRecord documenting its oversight design, to a defined human-approval checkpoint.
has checkpoint trigger
The category of action boundary the checkpoint guards (high-stakes, irreversible, outlier, user-defined).
human override rate
The measured frequency (0.0 to 1.0) at which humans reject or modify agent actions over the reporting period. A very low rate may signal rubber-stamping (automation bias); interpret alongside response times (MGF §2.2.2).
mean approval response time
The mean time humans spend reviewing agent actions before approving, over the reporting period. Very short times may signal automation bias or review fatigue (MGF §2.2.2).
agent identifier
The agent's unique identifier, ideally cryptographically verifiable (MGF §2.1.2).
accountable party
The supervising agent, human user, or organisational department to which this agent's identity is tied for accountability and tracking (MGF §2.1.2).
registered in
The centralised registry from which the agent's identity and permissions are issued and tracked, preventing agent sprawl (MGF §2.1.2).
delegated by
The human user or organisational role delegating authority to the agent. The agent's permissions should not exceed this party's own.
delegated to
The agentic AI system receiving the delegated authority.
permission scope
Human-readable statement of the scoped, least-privilege permissions granted, including any escalation paths.
valid from
Start of the delegation's validity window. Authorisations should be time- or session-bound (MGF §2.1.2).
valid until
End of the delegation's validity window.
covers testing dimension
A testing dimension covered by this agentic testing record.
has change trigger
The event category that initiated this change review.
has change category
The risk categorisation assigned to the reviewed change.