AI governance & EU AI Act compliance management

Most organisations cannot yet answer "which AI systems do we run, in which role, and at what risk class?" AI governance platforms keep a living register of systems, models and agents, use LLMs to pre-classify them under Regulation (EU) 2024/1689, and draft the paperwork (technical documentation, FRIA, literacy records, monitoring evidence) mapped to ISO/IEC 42001. Humans decide the classification; AI removes the form-filling.

Problem & value

• Today: AI enters through many doors: bought SaaS with embedded AI, cloud APIs, in-house ML, employee-adopted tools, agents. Inventory lives in spreadsheets; classification is ad hoc; documentation is written once for an audit and goes stale.
• AI value: automatic intake and pre-classification of use cases, extraction of facts from vendor documents, draft documents for review, continuous control evidence instead of annual scrambles, a single view for legal, security, data protection and business owners.
• Regulatory driver: the AI Act applies in stages. Prohibitions (Art. 5) and AI literacy (Art. 4) apply since 2 Feb 2025; GPAI obligations since 2 Aug 2025. The Digital Omnibus on AI (Reg. (EU) 2026/1744, in force since 27 Jul 2026) postpones the Annex III high-risk obligations to 2 Dec 2027 and Annex I product-embedded systems to 2 Aug 2028 [1][2]. The delay moves deadlines, not the need for an inventory: you cannot classify what you cannot find, and Art. 5 is already enforceable.

Variants

• EU AI Act compliance management (core): role determination (provider, deployer, importer, distributor), risk class, obligations checklist, conformity documentation, Art. 50 transparency, GPAI downstream-provider information.
• ISO/IEC 42001 management system: AI policy, risk assessment, controls (Annex A), internal audit and certification evidence [3].
• Model risk management in banking and insurance (industries: banking, insurance): model inventory with tiering, independent validation reports, challenger models, drift and fairness monitoring, per US Fed SR 26-2 (17 April 2026, which superseded SR 11-7, is most relevant to banks above USD 30 billion in assets and explicitly places generative and agentic AI models outside its scope), the ECB guide to internal models and BaFin MaRisk AT 4.3.5 [5][6]. Same register/documentation/monitoring core; validation depth and independence requirements are stricter, and credit scoring and life/health insurance pricing are Annex III high-risk.

How it works

1. discovery & intake (SEC-013 feeds, procurement, MLOps registry, intake form)
2. register entry (system, model, owner, vendor, purpose, data, users affected)
3. role + risk classification (LLM pre-classifier with Art. 5 / Annex III / Art. 50 checks, cited reasoning)
4. human review: legal/compliance owner confirms or overrides
5. obligations mapping (AI Act articles, ISO 42001 controls, GDPR, sector rules)
6. document drafting (Annex IV, FRIA, DPIA, model cards, vendor questionnaires)
7. evidence collection (tests, bias metrics, logs, literacy training, incidents)
8. continuous monitoring (drift, change triggers re-assessment)
9. audit pack / dashboards

• Pre-classification: an LLM with retrieval over the Act, Commission guidelines (prohibited practices, AI system definition) and your policies reads the use-case description and proposes a class with article citations. It must flag uncertainty; borderline cases (e.g. Annex III "employment" or "essential services") go to counsel.
• Document extraction: LLM reads vendor model cards, DPAs and security reports and fills questionnaires; gaps are listed as open tasks.
• Drafting: structured generation into templates (Annex IV headings, FRIA questions), with source links per claim.
• Human-in-the-loop: classification sign-off, any statement submitted to regulators or customers, FRIA conclusions, risk acceptance.

Data preparation

The "data" here is mostly an inventory of AI systems and their paperwork, not training data. It is scattered: purchase orders and SaaS contracts in ERP or procurement, vendor documents and DPAs in the DMS or file shares, cloud AI services in admin consoles, model artefacts in MLOps registries, and shadow AI in employees' browsers and mail. Typical gaps are missing owners, undocumented intended purposes, outdated or scanned contracts, duplicate entries and no record of who uses what.

Preparation steps: - Pull a first list from procurement, SSO app catalogue, cloud consoles and expense reports; run SEC-013 for shadow AI. - Digitise paper contracts and attach vendor documents to each entry (see PREP-006, PREP-007). - Define a minimal register schema and category scheme first (PREP-019) and name an owner per entry (PREP-004). - Reuse data-sensitivity labels where they exist (PREP-024, SEC-017). - Check which entries contain personal data (PREP-025).

Expect roughly a third of the effort in building and cleaning the first inventory; the rest is classification and documentation. Recurring discovery keeps the register from decaying.

Implementation paths

Which path for whom

• SMB: Path A, because mature EU-hosted governance platforms (e.g. trail, Saidot) bring register, templates and workflow at subscription prices for a standard process.
• Enterprise: Path B, because the register should sit inside the existing GRC/CMDB stack with custom taxonomies and connectors to cloud and MLOps inventories.
• Public sector: Path C, because open-source GRC (e.g. CISO Assistant) on sovereign infrastructure avoids procurement and hosting hurdles for a low-volume workload.
• Developer: Path C, because model cards, registries and drift tooling (MLflow, Evidently) are open source and fit into existing pipelines.

Path A — Buy (recommended for SMBs)

• Governance platforms: trail (DE, EU), Saidot (FI, EU), Modulos (CH), Credo AI, Holistic AI, IBM watsonx.governance, OneTrust AI governance, ServiceNow AI Control Tower, Microsoft Purview/Azure AI Foundry governance features, Collibra and Fairly AI.
• Model risk (banking/insurance): ValidMind, SAS Model Risk Management, Moody's and Bloomberg-class MRM suites, Fiddler/Arize for monitoring.
• Choose A when: you need an auditable register, workflow and templates within weeks. Check EU hosting, role-based review workflow, template currency (Omnibus changes), connectors (cloud, MLOps, SaaS discovery) and export formats.

Path B — Build on cloud APIs

• Intake form + register in an existing GRC/CMDB (ServiceNow, Jira, SharePoint/Dataverse, Notion-like database), an LLM API in an EU region (Mistral, Azure OpenAI EU Data Zone, Anthropic or Google via EU regions) with structured outputs for classification and document drafting, RAG over the Act and your policies.
• Orchestration with n8n, Power Automate or a small service; connectors to cloud inventories (AWS Bedrock/SageMaker, Azure AI, Vertex AI) via their APIs.
• Choose B when: governance must sit inside an existing GRC stack with custom taxonomies.

Path C — Self-host (open source)

• Open-weight models (Mistral Small/Large, Qwen3, Llama, gpt-oss) behind vLLM or Ollama; embeddings (BGE-M3, multilingual-e5) with pgvector or Qdrant; registry in Postgres or Eramba/CISO Assistant (open-source GRC) [7]; MLflow model registry; model cards via Hugging Face tooling; drift/fairness via Evidently, Fairlearn, AI Fairness 360.
• Hardware: HW2 is sufficient (low volume, document-sized prompts). Ops effort is small; the hard part is content curation.

Path D — Custom training

Rarely justified. A fine-tuned classifier on your past classification decisions could speed triage in very large estates (thousands of systems), but a prompted LLM with human review is usually enough.

State of the art (2026)

• Governance platforms have converged on: automated inventory (cloud, SaaS, code, agents), LLM-assisted risk questionnaires, ISO 42001 and AI Act control libraries, and agent registries (see AGENT-025). Analysts group this as "AI TRiSM"/AI governance platforms.
• Standards: ISO/IEC 42001 (management system) is the de facto certification route; CEN-CENELEC JTC 21 harmonised standards for the Act are delayed, which is a main reason for the Omnibus postponement [2][3]. Commission guidelines on prohibited practices and the AI system definition are the key interpretive texts.
• Limits and failure modes: LLM classification can miss Annex III edge cases or over-classify; documentation generated from vendor claims can be unverified; inventories decay without discovery and ownership; check-box compliance without real testing (see SEC-014) gives false assurance; the legal landscape (Omnibus, guidelines, national authorities) changes, so templates need version control.

Shared resources & combinations

• Discovery: SEC-013 (shadow AI, AI-SPM) feeds the register; SEC-017 (data classification) supplies data-sensitivity facts.
• Controls and testing: SEC-009 (ISO 27001, NIS2, DORA evidence), SEC-010 (runtime guardrails), SEC-012 (AI threat modelling), SEC-014 (red teaming) deliver evidence for risk-management obligations.
• Privacy: SEC-018 (RoPA, DPIA) shares data-mapping and FRIA/DPIA content.
• Agents and content: AGENT-025 (agent fleet governance), ANOM-015 (Art. 50 marking).

Effort, cost & KPIs

• Path A: 2-8 weeks to a populated register for an SMB; enterprise rollouts take quarters, mostly for connector work and organisational ownership. Pricing is typically per system, per user or platform subscription (vendor quotes needed).
• Path B/C: 2-4 months; costs are content curation, legal review time and integration, not compute.
• KPIs: share of AI systems registered with named owner; share classified and reviewed; time from intake to classification; documentation completeness per high-risk system; AI-literacy completion rate; overdue re-assessments; incidents reported on time; for MRM, validation backlog and model-tier coverage.

People & change

• Involve early: management (mandate, AI policy), legal/compliance (classification owner), IT and IT security (discovery, connectors), DPO (DPIA/FRIA alignment), department leads (system owners) and HR (literacy records).
• Works council: depends. The register holds staff names and literacy records, and any usage logging can be suited to monitor behaviour (§87(1) no. 6 BetrVG, objective suitability suffices per the BAG). The council must in any case be informed in good time when AI-supported work processes are planned (§90(1) no. 3) and may call an AI expert (§80(3)). Public bodies involve the Personalrat. Only relevant where a council exists.
• Data protection: limit personal data to owner names, involve the DPO, conclude an AVV with platform vendors and with LLM providers used for drafting.
• AI literacy: Art. 4 requires measures that support staff AI literacy; this use case logs them, so start the training programme alongside the register (GUIDE-006).
• Communication and pilot: present the register as a safe harbour for useful tools, not a ban list; pilot with 10-20 systems and one willing department.
• Concerns: "more bureaucracy" is met with a short intake form; fear of blame with a no-sanction first inventory. Humans sign off every classification.
• See GUIDE-014, GUIDE-007 and GUIDE-004.

Risks, regulation & compliance

• EU AI Act: the governance tool itself is minimal risk, since it does not fall under Annex III. Art. 4 literacy duty applies to staff. Art. 5 prohibitions (social scoring, workplace/school emotion recognition, untargeted facial-image scraping, certain biometric categorisation and manipulative AI) must be screened first and any hit stops the project; they apply already, with fines up to EUR 35m or 7% of turnover [1].
• Role confusion: deployers who substantially modify a system or put their name on it can become providers (Art. 25); the tool should test for this.
• GDPR: registers hold staff names and may link to systems processing personal data; FRIA and DPIA should be aligned; vendor DPAs and EU hosting for LLM drafting.
• Sector rules: SR 26-2 (replaced SR 11-7 in April 2026), ECB guide, MaRisk AT 4.3.5, EIOPA opinion on AI governance, DORA third-party register (ICT providers of AI).
• Risks and mitigations: over-reliance on AI classification (mandatory human sign-off, citations); stale documents (change triggers, review dates); false assurance (link to tests); not legal advice.

Getting started

1. Build a first inventory: procurement lists, SSO app catalogue, cloud AI services, MLOps registries; run SEC-013 discovery.
2. Screen every entry for Art. 5 first, then Annex III, GPAI and Art. 50, and record role (provider/deployer).
3. Define owners, a simple risk-tier policy and an intake form for new AI use cases.
4. Pilot a platform (Path A) or an LLM-assisted classifier (Path B) on 10-20 systems, measuring reviewer time and correction rate.
5. Roll out AI-literacy training with logged completion and set quarterly re-review plus change triggers.

Sources

1. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. Gibson Dunn — EU AI Act Omnibus Agreement: postponed high-risk deadlines — https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
3. European Parliament Legislative Train — Digital Omnibus on AI — https://www.europarl.europa.eu/legislative-train/package-digital-package/file-digital-omnibus-on-ai
4. ISO/IEC 42001:2023 AI management systems — https://www.iso.org/standard/81230.html
5. Federal Reserve SR 26-2 Revised Guidance on Model Risk Management (17 Apr 2026, supersedes SR 11-7) — https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
6. European Commission — AI Act regulatory framework and guidelines — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
7. CISO Assistant (open-source GRC) — https://github.com/intuitem/ciso-assistant-community
8. trail (DE) — https://www.trail-ml.com ; Saidot (FI) — https://www.saidot.ai ; ValidMind — https://validmind.com