EU AI Act Art.60: EU AI Database — Public Registry, EUID Governance, Commission Management, and NCA Access (2026)

EU AI Act Article 60 closes the Chapter VI governance framework by establishing the institutional infrastructure that ties together national enforcement, AI Board coordination, and public accountability: the EU database for high-risk AI systems. Where Art.57 defines who supervises (NCAs), Art.58 defines what NCAs can do (enforcement powers), and Art.59 defines how national enforcement is coordinated (AI Board), Art.60 defines what is known about every high-risk AI system in the EU market — and who can access that knowledge.

The EU database is not merely a register of products. It is the central evidentiary backbone of the EU AI Act's governance architecture. NCAs use it to identify systems under their oversight jurisdiction. The AI Board uses database statistics to identify patterns of non-compliance across Member States. The AI Office uses it to correlate GPAI model registrations with high-risk AI system downstream deployments. And the public uses the accessible portion to verify that specific AI systems have completed the conformity pathway before being deployed against them.

For providers of high-risk AI systems, Art.60 makes explicit the pre-market gate function of the database: a system that has not been registered and assigned a EUID cannot legally be placed on the EU market. For infrastructure providers, Art.60 defines the data architecture that market surveillance authorities will query when investigating AI systems running on their platforms.

Art.60 became applicable on 2 August 2025 as part of the phased entry into force of Regulation (EU) 2024/1689.

Art.60 in the Chapter VI Governance Architecture

Art.60 occupies the information layer of the four-tier governance structure established by Chapter VI:

The database is unique among Chapter VI instruments: it is simultaneously a compliance gate (registration is legally required before market placement), an enforcement tool (NCAs query it during investigations), and a public accountability instrument (the publicly accessible layer enables external scrutiny of deployed high-risk AI systems).

Art.60(1): Commission Mandate to Establish and Maintain the Database

Art.60(1) places the database obligation on the European Commission: "The Commission shall establish and maintain at EU level an EU database for high-risk AI systems referred to in Annex III."

Institutional hosting: The database is operated by the Commission, not by a decentralised EU agency. This is a deliberate governance choice — centralisation at Commission level ensures uniformity of the database infrastructure across all Member States and prevents fragmentation into 27 national registries that might diverge in format, accessibility, or completeness.

Scope: The database initially covers high-risk AI systems listed in Annex III — the product category list that includes AI systems used in biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration management, administration of justice, and democratic processes. Annex III systems have the broadest societal impact and the strongest case for public transparency.

Commission accountability: The Commission bears direct legal responsibility for the database's accuracy, availability, and integrity. Providers who register information bear responsibility for the correctness of the data they submit; the Commission bears responsibility for the infrastructure that stores, makes accessible, and manages that data.

Art.60(2): EUID — EU Database Identification Number

Art.60(2) establishes the EU Database Identification Number (EUID) as the unique identifier assigned to each registered high-risk AI system.

Assignment: The EUID is assigned at the time of registration, before market placement. It is not assigned by the provider — the database system generates it upon successful submission of required information. This ensures uniqueness and prevents providers from selecting identifiers that could cause confusion with existing registrations.

EUID function: The EUID serves as the persistent regulatory identity of a high-risk AI system throughout its market lifecycle. It links:

• The provider's EU declaration of conformity (Art.46) to the registration record
• The notified body certificate (where third-party conformity assessment was performed under Art.43) to the system identity
• Post-market monitoring reports (Art.40) to the original registration entry
• Incident reports under Art.73 to the system that generated the incident

Portability: The EUID follows the system, not the provider. If a system is acquired by a new provider, or if an authorised representative changes, the EUID remains constant. This preserves the continuity of the compliance record across commercial transactions.

Practical format: The EUID takes a structured format that encodes the registration year, the Annex III category, and a sequential identifier. This allows NCAs to identify the category of a system from its EUID without requiring a database query, supporting rapid triage during market surveillance operations.

Art.60(3): Information Categories — Public and Restricted Access

Art.60(3) establishes a two-tier information architecture: a publicly accessible layer and a restricted layer accessible only to authorised authorities.

Publicly accessible information:

• Provider name and registered address
• System name and version
• General description of the AI system and its intended purpose
• Annex III category and subcategory under which the system was registered
• EUID
• Registration date
• Conformity assessment route (self-assessment under Art.43(2) or third-party assessment)
• Notified body name and certificate number (where applicable)
• URL of the provider's publicly accessible technical documentation summary

Restricted information (NCAs, AI Board, AI Office access):

• Full technical documentation (Art.11 documentation package)
• Detailed conformity assessment records
• Internal audit and monitoring reports
• Incident and near-miss reports submitted under Art.73
• Market surveillance authority correspondence
• Confidential business information marked as such by the provider

Access control principle: The public layer is calibrated to enable accountability and deployer due diligence without exposing commercially sensitive technical specifications. The restricted layer enables NCAs to conduct investigations without requiring providers to re-submit documentation that is already held in the database.

Art.60(4): Pre-Placement Registration Obligation

Art.60(4) establishes the pre-placement gate: "Providers of high-risk AI systems referred to in Annex III shall, before placing those systems on the market or putting them into service, register themselves and their systems in the EU database."

Timing: Registration must be completed before market placement or putting into service. A provider who completes conformity assessment under Art.43 but fails to register before their first commercial transaction is in breach of the Regulation — independently of whether the system itself meets the technical requirements.

Multi-market obligation: Registration in the EU database covers the entire EU market. A provider does not register separately in Germany, France, and Sweden — the single EU database entry constitutes registration for the entire Union. This is a deliberate design choice: it prevents the compliance cost of maintaining 27 national registration records while preserving the single market for AI systems.

Authorised representative registration: Third-country providers without EU establishment must register through their authorised representative designated under Art.22. The authorised representative registers on the provider's behalf, but the EUID is assigned to the AI system and linked to the third-country provider's identity alongside the representative's.

Registration maintenance: Providers must update registration records when significant changes are made to the AI system — changes that would affect the system's risk classification, intended purpose, or conformity assessment status. The EUID remains constant but the registration record reflects the current state of the system.

Art.60(5): NCA, AI Board, and AI Office Access Rights

Art.60(5) defines the access rights of supervisory and governance bodies to the restricted database layer.

NCA access: National Competent Authorities have access to the full database record for AI systems registered in their jurisdiction — meaning systems placed on the market or put into service within their Member State's territory. NCAs can query the database by:

• EUID (direct system lookup)
• Provider identity (to identify all systems registered by a given provider)
• Annex III category (to identify all high-risk systems in a regulated domain within their jurisdiction)
• Date range (for post-market monitoring sweep operations)

AI Board access: The AI Board has access to aggregated database statistics and anonymised registration data to support its coordination and reporting functions. This allows the Board to monitor patterns — for example, identifying Annex III categories where registration rates are low, or Member States where concentrated enforcement activity correlates with specific provider profiles.

AI Office access: The AI Office has full access to both the high-risk AI system registry and the GPAI model registry (see Art.60(7)), enabling it to correlate GPAI model providers with the downstream high-risk AI systems that incorporate those models. This cross-referencing capability supports the AI Office's enforcement jurisdiction over GPAI model providers under Arts.51–56.

Interoperability: The database provides machine-readable APIs for NCA market surveillance systems, enabling automated cross-referencing rather than manual portal queries. NCAs that have integrated the API can run automated compliance sweeps against the database as part of their routine market surveillance operations.

Art.60(6): Deployer Supplementary Registration

Art.60(6) establishes a supplementary registration obligation for deployers in specific contexts: public authorities and bodies deploying high-risk AI systems covered by Annex III, categories IV (employment and workers management), V (access to essential services), VI (law enforcement), VII (migration, asylum, and border control management), and VIII (administration of justice and democratic processes) must register their deployment in the database.

Rationale: The supplementary deployer registration addresses a transparency gap that provider registration alone cannot close. Knowing that a high-risk AI system exists on the market does not reveal where it is deployed or by whom — information that is critical for oversight of AI systems used by public authorities against individuals. Deployer registration completes the accountability picture: not just what exists, but who is using it and in what context.

What deployers register:

• Identity of the deploying authority or body
• AI system EUID (linking to the provider's registration)
• Intended purpose as deployed (which may be more specific than the provider's general intended purpose)
• Geographic scope of deployment
• Date of commencement of use

Deployer registration does not substitute for provider registration: Both registrations are required independently. A public authority deploying a high-risk AI system procured from a provider must verify that the provider registration exists (EUID assigned) before deploying, and then register the deployment separately.

Art.60(7): GPAI Model Entries

Art.60(7) extends the database to cover GPAI models with systemic risk designated under Art.51, creating a separate registry track within the EU database infrastructure.

Separate registry track: GPAI model registrations are maintained in a distinct section of the database from high-risk AI system registrations. The information architecture differs: GPAI model entries focus on model identity, capability profile, systemic risk designation, and AI Office evaluation history rather than on market placement conformity.

GPAI registry information:

• Model provider name and registration
• Model name and version identifier
• Systemic risk designation status under Art.51
• Training compute threshold documentation (Art.51(1) — ≥10²⁵ FLOPs)
• Summary of capabilities evaluation by AI Office under Art.55
• Codes of Practice participation status under Art.56
• Serious incident reports under Art.73(2)

AI Office jurisdiction: The AI Office, not NCAs, is the primary user of the GPAI registry. The registry enables the AI Office to maintain comprehensive visibility over the GPAI model market and correlate model registrations with Art.50 transparency compliance (the AI-generated content labelling obligation that applies to outputs of registered GPAI models).

Cross-reference with high-risk systems: The database architecture enables cross-referencing between GPAI model entries and high-risk AI system entries — identifying which high-risk AI systems incorporate which GPAI models. This supports the Art.25 supply chain responsibility analysis: if a GPAI model provider is found non-compliant, the AI Office can immediately identify the downstream high-risk AI systems that incorporate that model.

Art.60(8): Cross-Border Recognition and Third Country Providers

Art.60(8) establishes mutual recognition of EU database registrations across Member States and defines the obligations of third-country providers.

Mutual recognition: An AI system registered in the EU database under a EUID issued in the context of initial placement in, for example, Germany, is recognised as registered throughout the EU. NCAs in other Member States do not require separate national registration. This prevents the "27-country registration" burden that would undermine the single market for AI systems.

Third country provider obligations: Providers established outside the EU must:

1. Designate an authorised representative established in the EU (Art.22)
2. Have that representative register the AI system before first market placement
3. Ensure the registration identifies both the third-country provider and the EU authorised representative
4. Maintain registration currency as the system evolves

CLOUD Act intersection: For third-country providers subject to the US CLOUD Act — primarily providers incorporated under US law or their subsidiaries — the EU database registration creates a documented EU regulatory identity. EU NCAs querying the database for a US-origin AI system will see the EU authorised representative as the primary regulatory contact, not the US parent entity. This does not eliminate the CLOUD Act jurisdictional exposure of the underlying model or its training data, but it ensures that EU enforcement proceeds through EU-anchored entities rather than requiring direct engagement with US-law subjects.

EU-incorporated providers: Providers incorporated in EU Member States register directly, without an authorised representative, and their EU establishment creates a clear jurisdictional nexus for NCA oversight that is not subject to CLOUD Act conflicts. This structural advantage extends to all components of the AI system — including model weights, training pipelines, and inference infrastructure — held within EU-incorporated entities.

Art.60(9): Data Protection and Retention

Art.60(9) places the EU database within the EU data protection framework: "The processing of personal data included in the EU database shall be subject to Regulation (EU) 2018/1725."

Regulation (EU) 2018/1725: The database is operated by the Commission, and the Commission's data processing activities are governed by Regulation (EU) 2018/1725 (the "EU institutions GDPR" — the data protection framework for EU institutions, bodies, offices, and agencies) rather than GDPR. The practical effect is equivalent: data minimisation, purpose limitation, access controls, and data subject rights apply to personal data in the database.

Personal data in the database: Registration records may include personal data where the provider or authorised representative is a natural person (for example, a sole trader or individual researcher). The Commission acts as data controller for the database as a whole; providers act as data controllers for the personal data they submit.

Retention periods: Database records are retained for the duration of market availability of the AI system, plus a post-withdrawal period sufficient to support post-market monitoring and enforcement activities. The specific retention period is defined in the Commission's implementing acts establishing the database, but must be proportionate to the enforcement timeline — including the limitation periods for sanctions proceedings under Art.99.

Confidentiality of restricted data: Information marked as commercially sensitive by providers in the restricted layer is not disclosed to third parties by NCAs or the Commission except under the access conditions established in Art.62 (access to evidence and confidentiality). NCAs that access confidential database records during investigations must handle those records under the confidentiality obligations of Art.62.

Art.60(10): Commission Reporting to AI Board

Art.60(10) establishes the database's role in AI Board reporting: the Commission shall regularly provide the AI Board with aggregated statistics drawn from the EU database to support the Board's coordination and advisory functions.

Reporting content: The Commission's database reports to the AI Board cover:

• Registration rates by Annex III category across Member States
• Notified body certificate distribution (identifying concentration in specific notified bodies or Member States)
• GPAI model registry completeness and systemic risk designation coverage
• Incident report aggregation from Art.73 notifications
• Deployer registration rates for public-sector categories

AI Board use of database statistics: The AI Board uses Commission database reports to:

• Identify enforcement gaps (categories where low registration rates suggest non-compliance)
• Calibrate its opinions and guidelines to reflect actual market patterns
• Support Commission proposals for Annex III amendments based on observed market behaviour
• Prepare annual reports to the European Parliament and Council on the state of the EU AI market

Feedback loop: The database statistics create a feedback loop between market reality and governance: registration patterns reveal where the regulation is working and where it faces resistance, enabling the AI Board and Commission to adapt enforcement strategies and guidance without requiring legislative amendment.

Art.60(11): Database Review and Evolution

Art.60(11) requires the Commission to conduct periodic reviews of the database architecture: "The Commission shall review the functioning of the EU database every four years and report to the European Parliament and the Council."

Review scope: The four-year review covers:

• Registration completeness across Annex III categories
• Database accessibility for NCAs and the public
• Technical interoperability between the database and national market surveillance systems
• Adequacy of the GPAI model registry in light of market evolution
• Potential extension of the database to additional AI system categories beyond Annex III

Amendment pathway: Based on review findings, the Commission may propose amendments to the database architecture, information requirements, or access conditions through delegated acts under Art.85 or through legislative proposals if structural changes require co-legislative procedure.

Continuous improvement: The four-year cycle does not preclude continuous technical improvements to the database — updates to the API, improvements to search functionality, enhanced NCA interoperability — which the Commission may implement under its management mandate without awaiting the formal review.

Python Implementation: EU AI Database Manager

from dataclasses import dataclass, field
from datetime import date
from enum import Enum
from typing import Optional
import uuid


class AnnexIIICategory(str, Enum):
    BIOMETRIC_IDENTIFICATION = "annex_iii_1"  # Art.6(1) + Annex III(1)
    CRITICAL_INFRASTRUCTURE = "annex_iii_2"   # Annex III(2)
    EDUCATION = "annex_iii_3"                  # Annex III(3)
    EMPLOYMENT = "annex_iii_4"                 # Annex III(4)
    ESSENTIAL_SERVICES = "annex_iii_5"         # Annex III(5)
    LAW_ENFORCEMENT = "annex_iii_6"            # Annex III(6)
    MIGRATION = "annex_iii_7"                  # Annex III(7)
    JUSTICE = "annex_iii_8"                    # Annex III(8)


class ConformityRoute(str, Enum):
    SELF_ASSESSMENT = "art_43_2_self_assessment"
    THIRD_PARTY_NOTIFIED_BODY = "art_43_1_notified_body"


class RegistrationStatus(str, Enum):
    DRAFT = "draft"
    REGISTERED = "registered"  # EUID assigned
    UPDATED = "updated"
    SUSPENDED = "suspended"
    WITHDRAWN = "withdrawn"


def generate_euid(category: AnnexIIICategory, registration_year: int) -> str:
    """Generate EUID: year-category-uuid4 prefix format."""
    uid = str(uuid.uuid4()).split("-")[0].upper()
    cat_code = category.value.split("_")[-1]
    return f"EU-AI-{registration_year}-{cat_code}-{uid}"


@dataclass
class EUAIDatabaseEntry:
    # Provider information (always public)
    provider_name: str
    provider_address: str
    provider_eu_establishment: bool  # False = third-country, requires authorised rep

    # System information (public layer)
    system_name: str
    system_version: str
    annex_iii_category: AnnexIIICategory
    intended_purpose: str
    conformity_route: ConformityRoute

    # Confidential (restricted layer)
    technical_documentation_reference: str  # internal doc ID
    conformity_assessment_records: list[str] = field(default_factory=list)

    # EUID assigned at registration
    euid: Optional[str] = None
    registration_date: Optional[date] = None
    status: RegistrationStatus = RegistrationStatus.DRAFT

    # Third-country provider fields
    authorised_representative_name: Optional[str] = None
    authorised_representative_eu_establishment: Optional[str] = None

    # Notified body (if third-party conformity assessment)
    notified_body_name: Optional[str] = None
    notified_body_certificate_number: Optional[str] = None

    # Deployer supplementary registration (Art.60(6) categories)
    deployer_registrations: list[dict] = field(default_factory=list)

    def register(self) -> str:
        """Assign EUID and set registration date — simulates database registration."""
        if not self.provider_eu_establishment and not self.authorised_representative_name:
            raise ValueError(
                "Third-country providers must designate an authorised representative "
                "under Art.22 before registration (Art.60(4))."
            )
        if self.conformity_route == ConformityRoute.THIRD_PARTY_NOTIFIED_BODY:
            if not self.notified_body_certificate_number:
                raise ValueError(
                    "Third-party conformity assessment route requires notified body "
                    "certificate number before registration (Art.60(4))."
                )

        self.euid = generate_euid(self.annex_iii_category, date.today().year)
        self.registration_date = date.today()
        self.status = RegistrationStatus.REGISTERED
        return self.euid

    def add_deployer_registration(
        self,
        deployer_name: str,
        deployer_address: str,
        deployment_purpose: str,
        geographic_scope: str,
        commencement_date: date,
    ) -> None:
        """Add deployer supplementary registration (Art.60(6))."""
        if not self.euid:
            raise ValueError(
                "Provider registration (EUID) must exist before deployer "
                "supplementary registration under Art.60(6)."
            )
        deployer_categories_requiring_registration = [
            AnnexIIICategory.EMPLOYMENT,
            AnnexIIICategory.ESSENTIAL_SERVICES,
            AnnexIIICategory.LAW_ENFORCEMENT,
            AnnexIIICategory.MIGRATION,
            AnnexIIICategory.JUSTICE,
        ]
        if self.annex_iii_category not in deployer_categories_requiring_registration:
            raise ValueError(
                f"Deployer supplementary registration under Art.60(6) applies only to "
                f"Annex III categories IV-VIII. Category {self.annex_iii_category.value} "
                f"does not require deployer registration."
            )
        self.deployer_registrations.append({
            "deployer_name": deployer_name,
            "deployer_address": deployer_address,
            "euid_reference": self.euid,
            "deployment_purpose": deployment_purpose,
            "geographic_scope": geographic_scope,
            "commencement_date": commencement_date.isoformat(),
            "registration_timestamp": date.today().isoformat(),
        })

    def registration_summary(self) -> dict:
        return {
            "euid": self.euid,
            "status": self.status.value,
            "provider": self.provider_name,
            "system": f"{self.system_name} v{self.system_version}",
            "category": self.annex_iii_category.value,
            "conformity_route": self.conformity_route.value,
            "registration_date": self.registration_date.isoformat() if self.registration_date else None,
            "eu_establishment": self.provider_eu_establishment,
            "deployer_registrations": len(self.deployer_registrations),
        }


# Example: EU-incorporated PaaS infrastructure provider
entry = EUAIDatabaseEntry(
    provider_name="sota.io GmbH",
    provider_address="Frankfurt, Germany",
    provider_eu_establishment=True,  # EU-incorporated: no authorised rep needed
    system_name="sota-deploy-risk-classifier",
    system_version="1.0.0",
    annex_iii_category=AnnexIIICategory.EMPLOYMENT,  # Annex III(4): employment AI
    intended_purpose="Automated assessment of deployment risk levels for customer workloads",
    conformity_route=ConformityRoute.SELF_ASSESSMENT,
    technical_documentation_reference="TD-2025-001",
)

euid = entry.register()
print(f"EUID assigned: {euid}")
print(f"Registration summary: {entry.registration_summary()}")

What Art.60 Means for AI Infrastructure Providers

sota.io and other EU-incorporated PaaS operators face a structured set of implications from the Art.60 database framework:

Direct registration obligations:

• If sota.io operates AI features that qualify as high-risk AI systems under Annex III, those systems must be registered before deployment. EU-incorporated providers register directly; the EUID is assigned at registration.
• If customers deploy high-risk AI systems on sota.io infrastructure, they bear the registration obligation — but the infrastructure provider may be asked to provide documentation that supports the customer's registration (for example, infrastructure configuration records needed for Art.11 technical documentation).

NCA investigation support:

• When NCAs query the database and identify high-risk AI systems operating on sota.io infrastructure, they may initiate access requests under Art.58(1) to verify that the deployed systems match their registration records. The EUID enables NCAs to correlate market surveillance observations with registration data without requiring providers to re-identify their systems.

CLOUD Act structural advantage:

• The EU database registers AI systems against EU-incorporated entities. US-incorporated providers register through authorised representatives, creating a documented distance between the EU regulatory record and the US parent company. EU-incorporated providers like sota.io have direct, clean jurisdictional presence in the database — their EUID registration links to an EU legal entity without CLOUD Act conflict.
• For customers evaluating AI infrastructure options: EU-incorporated PaaS providers offer a registry anchor in EU jurisdiction. If an NCA investigation opens, the database trail leads to an EU legal entity subject to EU law, not to a US-law subject whose records are potentially accessible under CLOUD Act without EU court oversight.

Monitoring obligations for infrastructure providers:

• Infrastructure providers are not required to maintain copies of their customers' EUID registrations, but verifying that customers operating high-risk AI systems have valid EUID registrations is a commercial best practice — and increasingly a contractual requirement as deployers demand supply-chain compliance evidence.

Art.60 Compliance Checklist

Series Context: Chapter VI Governance Framework

Art.60 completes the Chapter VI governance series:

EU AI Act Art.60 analysis based on Regulation (EU) 2024/1689 as published in the Official Journal of the European Union. Applicable from 2 August 2025 per Art.113(3). This guide reflects the text of the Regulation; Commission implementing acts establishing the technical specifications of the EU database, EUID format, and API access protocols will provide additional implementation detail as published.