PRISM — EU AI Act Compliance Record-Keeping Ontology

Overview

PRISM models EU AI Act compliance obligations using a rule-based applicability model: each obligation declares the conditions under which it applies — actor role, risk level, AI lifecycle stage, Annex III sector, system type, or any combination.

It extends AIRO, the W3C Data Privacy Vocabulary (DPV) 2.3, and the EU AI Act extension with structured mappings from legal obligations to compliance record types, industry-specific interpretations, and attestation workflows.

Lifecycle stages are aligned with ISO/IEC 22989 via DPV 2.3's ai:LifecycleStage. Approximately twenty compliance record types map to specific EU AI Act obligation areas, each declaring when they are required through prism:ApplicabilityCondition.

Problem

The EU AI Act creates compliance obligations that differ significantly by actor role, risk level, AI lifecycle stage, Annex III sector, and system type. Existing vocabularies — DPV, eu-aiact, AIRO — define the terms (risk levels, actor roles, AI system types) but do not model the obligation structure itself: which records must be produced, by whom, at which stage, and what they must evidence.

Rule-Based Obligation Applicability

PRISM uses a declarative model where each obligation states its own applicability conditions. Rather than a fixed set of variables, obligations declare whichever conditions are relevant:

• Actor role — using eu-aiact actor concepts
• Risk level — using the eu-aiact:RiskLevel taxonomy
• AI lifecycle stage — using ai:LifecycleStage from DPV 2.3 (ISO/IEC 22989)
• Annex III sector — for obligations triggered by specific regulatory sectors (e.g., eu-aiact:EmploymentSector). See Economic Sector Coverage for the distinction between Annex III sector and industry sector.
• System type — for obligations triggered by system classification. Uses eu-aiact concepts where available (e.g., eu-aiact:BiometricCategorisationSystem, eu-aiact:EmotionRecognitionSystem), or prism-local classes where eu-aiact has not yet modelled the concept (e.g., prism:ChatBot, prism:AIContentGenerator)
• Entity type — for obligations specific to entity types (e.g., public sector deployers)

Not all conditions are needed for every obligation. Some require only actor + risk level (e.g., quality management). Others add lifecycle stage (e.g., risk management applies at design and operation). FRIA adds sector (only specific Annex III areas) and entity type (public sector deployers have broader FRIA obligations).

Attestation Workflow

Compliance records follow a two-stage attestation workflow:

1. Candidate — extracted by an AI connector (e.g. from existing documentation or system logs). Assigned a prism:extractionConfidence score. Does not count as evidential coverage.
2. Attested — reviewed and signed off by a named individual (prism:attestedBy) at a specific time (prism:attestedAt). The named graph is hashed at write time (prism:sha256Hash) for immutability verification. Only attested records count as evidential coverage in gap analysis.

Each record also stores prism:ontologyVersion — the PRISM version under which it was attested — so that records can be flagged for re-review when the ontology updates.