High-Tech & Software
Continuous Technical Documentation Generation
Minimal RiskUnverifiedDiscuss / dispute
Codebase, telemetry and training metadata parsed continuously to auto-generate and maintain Annex IV technical documentation, model cards and change histories for deployed AI systems.
Classification rationale: The output is the evidence other systems are judged on, which inverts the risk: a fluent but unverified dossier is worse than none, because Art. 11 documentation is what the market-surveillance authority inspects. Lead-engineer verification of each Annex IV disclosure, plus lineage back to the artefact that produced each claim, is non-negotiable.
Indicative decision support, not legal advice. Risk classification depends on your concrete deployment context and can change with scope drift — validate the result with qualified counsel.
pricingPer generated technical compliance dossier
oversightLead AI engineer verifies every Annex IV disclosure before the dossier is released
Compliance brief
This use case is minimal-risk under the EU AI Act (Minimal Risk); no product-specific obligations beyond general AI literacy apply.
What is owed
- Art. 4. Providers and deployers must ensure sufficient AI literacy of staff dealing with AI systems.
- Art. 25. A deployer becomes the provider (full Art.
Dates that bind
- 2026-08-02 — General applicability + Art. 50. Transparency obligations for chatbots, deepfakes and synthetic content; EU-level enforcement begins.
- 2026-12-02 — Additional prohibitions. Additional bans (deepfake CSAM et al.) and transition period for synthetic content under Art. 50(2).
Maximum exposure
- EU AI Act: Tiered: €35m / 7% (prohibited practices); €15m / 3% (Art. 9–15 high-risk obligations incl. data governance, documentation, logging); €7.5m / 1% (Art. 99(5) — incorrect, incomplete or misleading information to notified bodies or national competent authorities)
- Cyber Resilience Act: Up to €15m or 2.5% of worldwide annual turnover
First five actions
- Confirm in writing whether this organisation builds/places the system on the market (provider) or only operates it (deployer), since the role is not yet established.
- Commission and confirm the Art. 4, Art. 25 obligations named above as active workstreams with an accountable owner.
- Stand up the named oversight design — Mode 1 — with a documented human-review procedure.
- Produce the technical documentation and evidence artefacts already mapped to this use case (Zero-Data-Retention Vendor Binding, SBOM & Dependency Management, Secure Boot & Hardened Runtime) before they are requested.
- Put 2026-08-02 — General applicability + Art. 50 — into the compliance calendar with an owner and lead time.
Terms used above: · · ·
Applicable Regulations (5)
EU AI Act (Regulation (EU) 2024/1689)
unverified · no verification date source EUR-Lex
Horizontal, risk-based product-safety law for AI systems and GPAI models. Extraterritorial market-place principle. Staged applicability 2025–2030 (Digital Omnibus: Annex III → 2 Dec 2027, Annex I → 2 Aug 2028).
Sanctions: Tiered: €35m / 7% (prohibited practices); €15m / 3% (Art. 9–15 high-risk obligations incl. data governance, documentation, logging); €7.5m / 1% (Art. 99(5) — incorrect, incomplete or misleading information to notified bodies or national competent authorities)
Cyber Resilience Act (Regulation (EU) 2024/2847)
unverified · no verification date source EUR-Lex
Security-by-design for products with digital elements over the full lifecycle: vulnerability management, patching, SBOM. Complements AI Act Art. 15 at product level.
Sanctions: Up to €15m or 2.5% of worldwide annual turnover
Art. 11 — Technical Documentation
unverified · no verification date source artificialintelligenceact.eu
Annex IV technical file before placing on market: system description, architecture, capabilities/limitations, risk measures — kept up to date.
Art. 17 — Quality Management System
unverified · no verification date source artificialintelligenceact.eu
Product-focused QMS for providers: strategy, design controls, data management, post-market monitoring — target of EN 18286:2026, the first AI Act harmonised-standard candidate to be published; presumption of conformity applies only once it is cited in the OJEU, which is still pending.
Art. 12 — Record-Keeping / Logging
unverified · no verification date source artificialintelligenceact.eu
Automatic, tamper-evident event logging over the system lifetime, serving three regulatory objectives: risk identification (Art. 79), post-market monitoring (Art. 72) and deployer oversight (Art. 26(5)). Deployers retain logs ≥ 6 months; financial institutions fold them into statutory internal audit documentation. A bolted-on logging wrapper does not satisfy the requirement — logging must be core architecture.
Legal Obligations (2)
Art. 4 — AI Literacy
Providers and deployers must ensure sufficient AI literacy of staff dealing with AI systems. In force since 2 Feb 2025.
unverified · no verification date read the article artificialintelligenceact.eu
Art. 25 — Value Chain / Role Flip
A deployer becomes the provider (full Art. 8–17 duties) by re-branding, changing intended purpose, or making a substantial modification — e.g. deep fine-tuning or wiring a model into autonomous agent toolchains.
unverified · no verification date read the article artificialintelligenceact.eu
Control Objectives (0)
obligation (article) → operationalized_by → control objective → satisfied_by → component/pattern; control objective → evidenced_by → evidence artifact
Art. 4
control layer: community mandate — propose objectives
Art. 25
control layer: community mandate — propose objectives
Take this into your GRC tooling
A control mapping your ISO/IEC 42001 or CSA AICM workbook can ingest, and an Annex IV skeleton to start the technical file from. Indicative mappings only — cells we are not confident about are exported empty rather than filled in.
Standards & Evidence
IEEE CertifAIEd™
Ethics certification (transparency, accountability, algorithmic bias, privacy) for products and professionals; interfaces with the EU ALTAI assessment list.
unverified · no verification date
evidence for: EU AI Act
ENISA Multilayer Framework & AI Threat Landscape
Three-layer good-practice model (cyber foundations → AI-specific → sectoral) and lifecycle threat landscape — the operational base for Art. 15 and CRA.
unverified · no verification date
evidence for: Cyber Resilience Act
NIST SP 800-218 (SSDF)
Secure Software Development Framework: practices for provenance, review and vulnerability handling of generated and third-party code; SSDF-AI companion covers AI-assisted development.
unverified · no verification date
evidence for: Cyber Resilience Act
ISO/IEC 27001:2022 + A.8.28
Information-security management; control A.8.28 (secure coding) is the natural anchor for AI code-generation and QA workflows alongside ISO 42001.
unverified · no verification date publisher ISO
evidence for: Cyber Resilience Act
EN ISO/IEC 22989 (AI Concepts)
Published terminology and concepts standard — the shared vocabulary layer for documentation and audits.
unverified · no verification date publisher ISO
evidence for: Art. 11 — Technical Documentation
EN 18286:2026 (QMS for AI Act)
Harmonised-norm candidate translating Art. 17 QMS into a product-focused governance framework; mappings to ISO 9001 and ISO/IEC 42001 Annex A (Annexes C & D); published as EN 18286:2026 in July 2026, OJEU citation (and with it the presumption of conformity) still pending.
published · verified 2026-08-04
evidence for: Art. 17 — Quality Management System
ISO/IEC 42001:2023 (AIMS)
ISO/IEC 42001:2023 — certifiable AI management system (Annex SL harmonized structure, PDCA logic, synergy discount when an ISO 27001 ISMS exists). Clauses 4–10 plus Annex A controls (control count 38 vs 39 is a live community dispute — counting method differs by edition/guide). Covers an estimated 40–50% of AI Act organizational duties; organizational certificate, no product presumption of conformity.
published · verified 2026-08-04 publisher ISO
evidence for: Art. 17 — Quality Management System
FprEN ISO/IEC 24970 (AI Logging)
Specifies event logging in AI systems — the concrete implementation target for Art. 12 record-keeping.
formal-vote · verified 2026-08-04 publisher ISO
evidence for: Art. 12 — Record-Keeping / Logging
TAGOF (Audit-as-Code)
Operationalizes governance as code in CI/CD: policy-as-code enforcement, continuous runtime telemetry and automatically generated audit evidence — the execution layer that replaces periodic audits with continuous assurance.
unverified · no verification date
evidence for: Art. 12 — Record-Keeping / Logging
Architecture Blueprint
Agentic RDA Stack (6 Layers)
Regulatory Design & Architecture framework for agentic systems: (1) isolated ephemeral execution (gVisor/Firecracker, read-only root, egress allowlists) → (2) agentic zero-trust identity (per-agent ID, short-lived OBO OAuth 2.1 tokens) → (3) MCP gateway with default-deny ACLs & credential vault → (4) reasoning + guardrail interception (prompt shields, sidecar alignment checks) → (5) human-oversight & durable state persistence (propose-action objects, checkpoint store) → (6) continuous observability & signed audit logs (≥ 6 months, SIEM).
Mode 1 — Assistant (HITL)
Agent proposes, human disposes: every consequential action reviewed before execution. Default for first deployments, irreversible or legally sensitive actions.
Required Technical Components (20)
Zero-Data-Retention Vendor Binding
Sensitive inference is contractually and technically restricted to endpoints under zero-data-retention and non-training terms, evidenced per vendor and re-validated annually.
from: Art. 25
SBOM & Dependency Management
Software bill of materials incl. model weights and datasets; automated vulnerability patching pipeline.
from: Cyber Resilience Act
Secure Boot & Hardened Runtime
Verified boot chain and hardened runtimes for edge/IoT deployments per CRA security-by-design.
from: Cyber Resilience Act
Ephemeral Execution Isolation
gVisor/Firecracker microVMs, read-only root, egress allowlists; container discarded after each task to prevent persistence of exploits.
from: Agentic RDA Stack (6 Layers)
Agentic Zero Trust
Unique cryptographic identity per agent; short-lived, finely-scoped tokens (OAuth 2.1 + PKCE); On-Behalf-Of flow so an agent can never see more than its triggering user.
from: Agentic RDA Stack (6 Layers)
MCP Gateway / Proxy
Central chokepoint for agent tool traffic: default-deny tool ACLs (tools/list vs tools/call), schema & argument inspection, credential injection from vault, rate limits, full audit mirror. Regulatory root cause: the base MCP protocol enforces no authentication or authorization at protocol level — Host/Client/Server topology with Tools/Resources/Prompts primitives ships without an identity layer, so a policy-enforcing gateway is not optional hardening but the only place Art. 12/15 duties can be enforced for tool calls.
from: Agentic RDA Stack (6 Layers)
Guardrail Sidecar / Interception
Rule-based (NeMo/Colang), model-based (alignment checkers) and structural validators deployed as sidecar or gateway plugin (<50 ms), decoupling safety scaling from inference scaling.
from: Agentic RDA Stack (6 Layers)
Propose-Action Objects
Agents never call target APIs directly: they emit typed proposal objects (endpoint, params, risk estimate, rationale) validated by the governance layer before execution; idempotent execution layer.
from: Agentic RDA Stack (6 Layers)
Durable Checkpointing (Pause & Resume)
At oversight gates the complete operational state — working memory, conversation history, tool arguments, intermediate artifacts — is serialized into a durable checkpoint (fast KV store for sub-ms lookups, transactional backend as recovery anchor, vector store for semantic caching of past human decisions). On approval the agent deserializes and resumes at the exact step; matched precedents can shortcut re-planning entirely.
from: Agentic RDA Stack (6 Layers)
Per-Action Autonomy Tiering
Tools tagged read-only / reversible-write / irreversible-write; controls layer routes each action to the matching oversight mode. Mode selection is per action type, never per agent.
from: Agentic RDA Stack (6 Layers)
Agent Identity & Access (IdP)
Per-agent identities, short-lived scoped tokens, OBO flow enforcement — the identity substrate of agentic zero trust.
from: Agentic RDA Stack (6 Layers)
Central Credential Vault
Agents never hold target-system keys; the gateway injects centrally managed credentials after policy checks.
from: Agentic RDA Stack (6 Layers)
OpenTelemetry / FCoT Tracing
Hierarchical trace spans for every sub-task, prompt, retrieved document and API call — the reconstructible decision path for Art. 12/14 and PLD disclosure.
from: Agentic RDA Stack (6 Layers)
WORM / Immutable Audit Vault
Append-only, hash-chained audit vault (WORM object-lock storage, AES-256 at rest, TLS 1.3 in transit). Guarantees tamper-evidence within the organization's trust domain — which stops your own team, but not an admin who can rebuild the vault. Pair with an external trust anchor and key ceremonies outside the operating team for evidence that holds against the insider scenario.
from: Agentic RDA Stack (6 Layers)
Watchdog Supervisor & Rate Limiting
Cost/iteration caps, loop detection, anomaly-triggered mandatory approval (CodeBuddy 'suspicious command override').
from: Agentic RDA Stack (6 Layers)
Trinity Defense (TCB + Command Gates + IFC)
Treats the LLM as an untrusted proposal engine behind a hardened non-LLM Trusted Computing Base. Three pillars: (1) command gates — actions only via a Finite Action Calculus, authorized by a deterministic policy checker before any execution; (2) information-flow control — lattice labels stop confidential data flowing to low-trust sinks without audited declassification; (3) privilege separation — sandboxed low-privilege planner ingests untrusted input, isolated high-privilege worker executes only gate-approved, TCB-normalized actions. Grounded in the impossibility result: token content alone can never unforgeably separate commands from data.
from: Agentic RDA Stack (6 Layers)
Guardian Agents (Runtime Policy Enforcement)
Autonomous supervisory agents outside the supervised agent's reasoning loop: stateful threat engines with graph-based cross-session history (catch multi-turn injection, gradual exfiltration, incremental privilege escalation), event-driven exposure visibility (permission drift, new connectors), and contextual risk correlation into unified issues — interception before execution, not post-hoc logging.
from: Agentic RDA Stack (6 Layers)
Deterministic Policy Engine (OPA / Cedar)
Policy-as-code decision point (PDP) with enforcement points (PEP) in front of every tool call: versioned policies in Git, microsecond evaluation, typed action schemas — authorization decided outside the model's reasoning space, never in the prompt.
from: Agentic RDA Stack (6 Layers)
Shadow-Mode Execution
Run governance controls in observe-and-score mode before enforcement: the policy engine and guardrails evaluate every agent action and log verdicts without blocking, yielding empirical false-positive/negative rates and calibrated thresholds. De-risks the enforcement cutover, produces baseline evidence for Art. 9 risk estimation, and is the standard migration path when retrofitting controls onto a live workflow.
from: Agentic RDA Stack (6 Layers)
Multi-Model Router & Fallback Abstraction
Abstraction layer decoupling application logic from model providers: dynamic routing on capability, cost, latency SLA and regulatory constraint (sensitive-data classes pinned to ZDR private/VPC endpoints or on-prem open-weight instances); real-time health monitoring with automatic fallback to secondary endpoints or local fine-tuned models on outage/latency spikes. Discharges resilience duties (DORA-class), prevents provider lock-in, and makes model deprecations a routing-table change instead of a re-architecture. Router decisions are logged into the decision trace — model version per event is an audit-packet field.
from: Agentic RDA Stack (6 Layers)
Delivery Stack & Pipeline Stage (8)
Service-as-a-Software delivery: the engines, patterns and artifacts this workflow needs on top of the generic obligations. See the full pipeline
Document Intelligence Engine
OCR, layout parsing and semantic clause extraction over filings, contracts and invoices, emitting structured records with span-level source references.
Data Lineage & Versioning
Provenance tracking of datasets, features and embeddings; write-time attribution (source, actor, timestamp, confidence).
AI Register & Model Registry / Factsheets
AI register & model registry: central inventory of every model, agent, RAG pipeline and embedded third-party SaaS AI across the estate, with factsheets per asset. v2.0 duty: every application — internal, open-source or procured — continuously publishes a machine-readable AI-BOM and Factsheet into the register; an asset without a current AI-BOM is an inventory gap, not a formality. Feeds Colorado AIA/ LL144 disclosure duties and the Art. 11 technical file; the enforcement backstop is Shadow-AI discovery on the risk register.
OpenTelemetry / FCoT Tracing
Hierarchical trace spans for every sub-task, prompt, retrieved document and API call — the reconstructible decision path for Art. 12/14 and PLD disclosure.
SBOM & Dependency Management
Software bill of materials incl. model weights and datasets; automated vulnerability patching pipeline.
Cognitive Orchestrator
The reasoning and control plane of an agentic workflow: goal decomposition, tool selection across enterprise APIs, confidence scoring per step, and a human-machine interface exposing progress, limitations and a global halt. It is the architectural home of AI Act Art. 14 oversight — oversight that lives only in a downstream UI cannot stop an executing agent.
Propose-Action Objects
Agents never call target APIs directly: they emit typed proposal objects (endpoint, params, risk estimate, rationale) validated by the governance layer before execution; idempotent execution layer.
Bitemporal Memory (GDPR×Art.12)
valid_from/valid_to + transaction time on every record: GDPR erasure removes data from the active retrieval path while the HMAC-chained immutable log survives for Art. 12 / PLD defence; tenant-scoped partitions allow physical scrub of PII.
Build or Buy — Vendor Layer (3)
The graph models vendor CATEGORIES as first-class nodes and keeps named vendors as community-maintained, disputable desc content with lastVerified dates. A category is stable; a vendor list is a currency-layer object like any standard node.
Runtime Security & Guardrail Vendors
First-line inline enforcement: single-pass parallel input/output evaluation proxies, injection & exfiltration defense, PII masking, grounding checks, SecOps routing. Exemplary (community-maintained): Prompt Security, HiddenLayer (MLSDR), Palo Alto AI Runtime Security, AWS Bedrock Guardrails, NVIDIA NeMo Guardrails, Guardrails AI, Robust Intelligence, LLM Guard / Llama Guard OSS class. Selection metrics: single-pass latency (<20 ms class), catch rates, policy-version telemetry into the AI-BOM.
unverified · verified 2026-08-06 community-maintained
selection metrics: single-pass parallel evaluation latency (<20 ms class), injection/hallucination catch rates, SecOps/SIEM routing, policy versioning surfaced into the AI-BOM
supplies: MCP Gateway / Proxy · Guardrail Sidecar / Interception
Agent Orchestration & SDLC Toolkits
Developer middleware for multi-agent networks, tool-use chains, RAG abstraction, state/memory persistence and model routing. Exemplary (community-maintained): LangChain, LlamaIndex, AutoGen, CrewAI; MCP-based tool ecosystems. Regulatory posture: orchestration code is where autonomy tiering, propose-action objects and fallback routing get implemented — the framework choice constrains which controls are cheap and which are retrofits.
unverified · verified 2026-08-06 community-maintained
selection metrics: broad model-API abstraction, state/memory management, error recovery, fallback routing hooks
supplies: Multi-Model Router & Fallback Abstraction · Cognitive Orchestrator
Regulated Foundation-Model Platforms
Frontier commercial APIs and open-weight models under enterprise controls: zero-data-retention tiers, data isolation, fine-tuning governance, safety alignment documentation, EU-sovereign options. Exemplary (community-maintained): Anthropic Claude (ZDR enterprise tier), OpenAI GPT enterprise, Google Gemini Enterprise, Cohere (private-cloud RAG), Mistral (EU/self-hosted), Meta Llama (open-weight sovereignty). GPAI-chapter duties and vendor due diligence attach at this layer.
unverified · verified 2026-08-06 community-maintained
selection metrics: ZDR enterprise tiers, data isolation, EU-sovereign options, fine-tuning controls, safety alignment documentation
supplies: Multi-Model Router & Fallback Abstraction
Procurement rule: Derived from three-lines-of-defense separation: the second-line GRC platform must be procured and deployed independently of any first-line runtime or model vendor — a governance tool that only sees its own vendor's models cannot govern a multi-model estate, and closed third-party SaaS AI can only be governed contractually (intake, attestation, AI-BOM disclosure), never by inline inspection.
Outsourced delivery BPO · SaaS · Service-as-a-Software caveats
Delivery Model — BPO · SaaS · Service-as-a-Software
Spectrum
BPO: input-priced (billable hours/FTEs), linear headcount scaling, human error & attrition as primary risk
SaaS: capability-priced (software access), client operates the workload, implementation/adoption failure as primary risk
Service-as-a-Software: outcome-priced (SLA on completed work), provider-managed AI executes 60–80% of cognitive tasks with specialist supervision, algorithmic bias & non-compliance as primary risk
Caveats in regulated markets
— Outcome SLAs move compliance risk onto the provider — but NOT the buyer's deployer duties: Art. 26 oversight, log retention and FRIA obligations stay with the enterprise even when execution is outsourced.
— Provider role analysis is the central legal question: a productized platform that fine-tunes, re-purposes or chains models can flip into the Art. 25 provider role with full high-risk obligations.
— Certified operations (ISO 42001) function as a procurement moat and shortcut third-party risk assessment — but organizational certificate ≠ product conformity (never conflate, see meta.assuranceEcosystem).
— The buyer's evidence chain must reach into the provider: contractually mandated AI-BOM disclosure, ZDR certificates, bias-audit reports and logging-ledger access are the artifacts that make an outsourced workflow auditable.
Threat Profile
LLM09 Misinformation
Hallucinated or wrong outputs create liability and decision risk.
mitigate with: Output Rails / Groundedness Check, Explainability API (SHAP/LIME/CoT)
Audit-Trail Manipulation (Insider)
Evidence tampering by parties with legitimate admin access: rebuilding the WORM vault, truncating hash chains before export, backdating records, selective deletion between audits. The sharper audit test: not whether logs are immutable in normal operation, but whether someone who administers the store can alter them unnoticed. Defeats every log-derived artifact at once (Art. 12, DORA, NIS2, PLD disclosure defence) if successful.
mitigate with: External Trust Anchor (Qualified Timestamp / Ledger), WORM / Immutable Audit Vault, Agentic Zero Trust
LLM06 Excessive Agency
Over-broad rights/functions of autonomous agents lead to uncontrolled actions.
mitigate with: MCP Gateway / Proxy, Agentic Zero Trust, Per-Action Autonomy Tiering, Trinity Defense (TCB + Command Gates + IFC), Deterministic Policy Engine (OPA / Cedar), Guardian Agents (Runtime Policy Enforcement)