EU AI Act Art.13: Transparency Disclosure Management — IFU Lifecycle Automation, Python TransparencyDisclosureManager, and Art.13 × Art.11 × Art.12 × Art.14 Integration (2026)
Article 13 of the EU AI Act is the transparency disclosure obligation of the high-risk AI compliance chain. Before a deployer can lawfully use your high-risk AI system, you must hand them written instructions for use (IFU) covering seven mandatory content elements. But Art.13 is not a documentation formality — it is an operational disclosure obligation that evolves with your system, triggers on every substantial modification, and must integrate with Art.11 (technical documentation), Art.12 (logging), and Art.14 (human oversight) to form a coherent compliance architecture.
The August 2, 2026 deadline: any high-risk AI system placed on the EU market or put into service on or after that date must have Art.13-compliant instructions delivered to deployers before deployment. For systems that receive substantial modifications under Art.11(4), the IFU must be updated and re-delivered.
This guide covers what Art.13 actually requires as a lifecycle obligation, how to build a Python TransparencyDisclosureManager that operationalises IFU production and versioning, how Art.13 connects to Art.11 modification triggers and Art.12 audit logging, the deployer handoff package generation system, and the Art.13 × Art.50 chatbot and emotion recognition intersection.
What Art.13 Actually Requires: The Three-Paragraph Architecture
Art.13 is three paragraphs, each creating a distinct layer of obligation:
Art.13(1) — Design-level transparency capability: High-risk AI systems shall be designed and developed in such a way that they are sufficiently transparent to allow deployers to interpret the system's output and use it appropriately. The "sufficiently transparent" standard is operationalised by Art.13(2) and (3) — but the critical word is "designed and developed." Transparency is a design requirement, not a documentation afterthought.
Art.13(2) — High-risk AI systems shall be accompanied by instructions for use: The IFU must be in an appropriate digital format and include "concise, complete, correct and clear information that is relevant, accessible and comprehensible to deployers." The "appropriate digital format" standard is flexible — PDF, structured JSON, API-delivered documentation — but the four content standards (concise, complete, correct, clear) are cumulative. A correct but incomplete IFU fails Art.13(2).
Art.13(3) — Seven mandatory IFU content elements: The IFU must contain at minimum seven categories of information. This is not a "where relevant" list — every category must appear, though the depth may be proportionate to the system's complexity and intended purpose.
The operational implication: Art.13 creates a provider obligation to the deployer (supply the IFU), not to the end user. End-user transparency is handled separately under Art.50. The IFU is the provider→deployer disclosure; Art.50 is the deployer→end-user disclosure.
The Seven IFU Content Requirements: A Validation Schema
Art.13(3) specifies seven content categories. Treating these as a validation schema — rather than a content outline — allows automated IFU completeness checking:
| IFU Element | Art.13(3) Reference | Minimum Content | Validation Rule |
|---|---|---|---|
| 1. Provider identity and contact | Art.13(3)(a) | Provider name, registered address, contact for complaints | Must include EU-accessible contact; third-country providers need EU representative (Art.25(1)) |
| 2. System characteristics, capabilities, limitations | Art.13(3)(b) | Intended purpose, accuracy metrics, known performance gaps | Must include accuracy across demographic groups where Art.10(5) bias testing was conducted |
| 3. Performance limitations by use context | Art.13(3)(c) | Use cases where performance may degrade, contra-indicated deployments | Must reference Art.9(2)(a) risk scope boundaries |
| 4. Human oversight measures | Art.13(3)(d) | Technical measures for Art.14 compliance, override procedures, minimum human competence requirements | Must specify which Art.14(1)(a)-(e) measures are implemented |
| 5. Input data requirements | Art.13(3)(e) | Data format requirements, pre-processing specifications, prohibited input types | Must cover Art.10(3) data quality standards |
| 6. Any changes to the system and performance | Art.13(3)(f) | Modification history since last IFU version, substantial vs. non-substantial change classification | Must list all Art.11(4) trigger events since last IFU |
| 7. Computational resource requirements | Art.13(3)(g) | Hardware specifications, latency requirements, integration prerequisites | Must cover requirements necessary for safe deployment |
The validation schema approach enables automated completeness checking. An IFU that passes all seven rules is structurally compliant — substance (accuracy, completeness of claims) is a separate audit dimension.
Art.13 Lifecycle Architecture: IFU Versions and Modification Triggers
Art.13 IFU obligations do not end at market placement. Three events trigger mandatory IFU updates:
Trigger 1 — Art.11(4) substantial modification: When a substantial modification occurs (compliance-affecting change or intended purpose change per Art.1(1)(67)), the technical documentation must be updated under Art.11(4) and the IFU must be updated and re-delivered under Art.13(3)(f). These obligations are linked — an Art.11(4) trigger always generates an Art.13 trigger.
Trigger 2 — New deployer onboarding: Every new deployer must receive the current IFU version before deployment. This is not version-conditional — even if a deployer already uses an older version, they must receive the current IFU before each new deployment contract.
Trigger 3 — Performance metric changes: When Art.15 accuracy metrics are updated based on post-market monitoring data (Art.9(8)-(9)), IFU Element 2 (characteristics and limitations) must be updated to reflect current validated performance. This creates a monitoring loop: post-market data → Art.9(8) monitoring report → IFU Element 2 update.
The practical system: IFU versions must be numbered, dated, and connected to the Art.11(4) modification record. IFU v1.0 corresponds to the initial Annex IV documentation; IFU v1.1 corresponds to the first substantial modification; IFU v2.0 corresponds to a new intended purpose scope.
Python TransparencyDisclosureManager: Full Implementation
The TransparencyDisclosureManager operationalises Art.13 as a structured workflow: IFU production, version management, deployer delivery tracking, and modification-triggered update automation.
from dataclasses import dataclass, field
from datetime import datetime
from typing import Optional
import hashlib
import json
import uuid
@dataclass
class IFUVersion:
version_id: str
version_number: str # "1.0", "1.1", "2.0"
created_at: datetime
modification_trigger: str # "initial", "substantial_modification", "performance_update"
art11_modification_id: Optional[str] # links to Art.11(4) record if triggered
elements_present: dict # art13_3_a through art13_3_g: bool
content_hash: str # SHA-256 of IFU content
ifu_content: dict # structured IFU per element
delivered_to: list[str] = field(default_factory=list) # deployer IDs
@dataclass
class DeployerDelivery:
delivery_id: str
deployer_id: str
ifu_version_id: str
delivered_at: datetime
delivery_method: str # "api", "email", "portal"
acknowledged: bool = False
acknowledged_at: Optional[datetime] = None
class TransparencyDisclosureManager:
"""
Operationalises Art.13 EU AI Act transparency obligations.
Manages IFU lifecycle: creation, versioning, delivery, audit trail.
"""
def __init__(self, system_id: str, provider_info: dict):
self.system_id = system_id
self.provider_info = provider_info
self.ifu_versions: list[IFUVersion] = []
self.deliveries: list[DeployerDelivery] = []
self.current_version: Optional[IFUVersion] = None
def create_initial_ifu(self, ifu_content: dict) -> IFUVersion:
"""Create IFU v1.0 before market placement (Art.13(2) pre-placement obligation)."""
validation_result = self._validate_ifu_elements(ifu_content)
if not validation_result["valid"]:
missing = [e for e, present in validation_result["elements"].items() if not present]
raise ValueError(f"Art.13(3) validation failed — missing elements: {missing}")
version = IFUVersion(
version_id=str(uuid.uuid4()),
version_number="1.0",
created_at=datetime.utcnow(),
modification_trigger="initial",
art11_modification_id=None,
elements_present=validation_result["elements"],
content_hash=self._hash_content(ifu_content),
ifu_content=ifu_content,
)
self.ifu_versions.append(version)
self.current_version = version
return version
def update_for_substantial_modification(
self,
art11_modification_id: str,
updated_elements: dict,
modification_summary: str,
) -> IFUVersion:
"""
Art.13(3)(f) update triggered by Art.11(4) substantial modification.
The Art.11 modification ID creates the audit link between documentation
and disclosure obligations.
"""
if self.current_version is None:
raise RuntimeError("Cannot update — no current IFU version exists")
# Merge updated elements with current IFU content
new_content = {**self.current_version.ifu_content}
new_content.update(updated_elements)
# Art.13(3)(f) requires the change history to appear in the IFU itself
if "changes_and_performance" not in new_content:
new_content["changes_and_performance"] = {"modifications": []}
new_content["changes_and_performance"]["modifications"].append({
"art11_modification_id": art11_modification_id,
"modification_summary": modification_summary,
"ifu_update_date": datetime.utcnow().isoformat(),
"modification_type": "substantial",
})
validation_result = self._validate_ifu_elements(new_content)
if not validation_result["valid"]:
raise ValueError(f"Updated IFU fails Art.13(3) validation: {validation_result}")
# Version bump: 1.0 → 1.1 → 1.2; new intended purpose scope → 2.0
current_major, current_minor = map(int, self.current_version.version_number.split("."))
new_version_number = f"{current_major}.{current_minor + 1}"
version = IFUVersion(
version_id=str(uuid.uuid4()),
version_number=new_version_number,
created_at=datetime.utcnow(),
modification_trigger="substantial_modification",
art11_modification_id=art11_modification_id,
elements_present=validation_result["elements"],
content_hash=self._hash_content(new_content),
ifu_content=new_content,
)
self.ifu_versions.append(version)
self.current_version = version
return version
def deliver_to_deployer(self, deployer_id: str, delivery_method: str = "api") -> DeployerDelivery:
"""
Record IFU delivery to a deployer. Art.13(2) requires delivery
before deployment. Delivery record feeds Art.12 audit trail.
"""
if self.current_version is None:
raise RuntimeError("Cannot deliver — no IFU version exists. Create IFU before deployer onboarding.")
delivery = DeployerDelivery(
delivery_id=str(uuid.uuid4()),
deployer_id=deployer_id,
ifu_version_id=self.current_version.version_id,
delivered_at=datetime.utcnow(),
delivery_method=delivery_method,
)
self.deliveries.append(delivery)
self.current_version.delivered_to.append(deployer_id)
return delivery
def get_deployers_requiring_update(self) -> list[str]:
"""
Returns deployer IDs that received an older IFU version and must
receive the current version before continued use.
Art.13 obligation: re-delivery required after substantial modification.
"""
if self.current_version is None:
return []
deployers_with_current = set(self.current_version.delivered_to)
all_deployers = {d.deployer_id for d in self.deliveries}
return list(all_deployers - deployers_with_current)
def generate_art12_log_event(self) -> dict:
"""
Generate Art.12(2)(d)-compatible log event for the current IFU version.
IFU version changes are 'major changes in system functionality' — they
must appear in the Art.12 audit trail.
"""
if self.current_version is None:
return {}
return {
"event_type": "ifu_version_active",
"art12_paragraph": "12(2)(d)",
"art12_mandatory_status": "mandatory",
"system_id": self.system_id,
"ifu_version_id": self.current_version.version_id,
"ifu_version_number": self.current_version.version_number,
"ifu_content_hash": self.current_version.content_hash,
"modification_trigger": self.current_version.modification_trigger,
"art11_modification_id": self.current_version.art11_modification_id,
"timestamp": datetime.utcnow().isoformat(),
}
def generate_deployer_handoff_package(self, deployer_id: str) -> dict:
"""
Generates a complete deployer onboarding package containing:
- Current IFU (Art.13 compliance)
- Art.14 human oversight requirements (for deployer implementation)
- Art.12 logging requirements (for deployer retention obligations)
- Deployer-specific Art.28 obligations checklist
"""
if self.current_version is None:
raise RuntimeError("No IFU available for handoff package")
return {
"package_id": str(uuid.uuid4()),
"system_id": self.system_id,
"deployer_id": deployer_id,
"generated_at": datetime.utcnow().isoformat(),
"ifu": {
"version_number": self.current_version.version_number,
"content": self.current_version.ifu_content,
"content_hash": self.current_version.content_hash,
"elements_validated": self.current_version.elements_present,
},
"art14_requirements": self._generate_art14_requirements(),
"art12_retention_obligations": self._generate_art12_deployer_obligations(),
"art28_deployer_checklist": self._generate_art28_checklist(),
}
def _validate_ifu_elements(self, content: dict) -> dict:
"""Validates IFU against Art.13(3)(a)-(g) seven-element schema."""
element_map = {
"art13_3_a": "provider_identity", # provider identity and contact
"art13_3_b": "characteristics_capabilities", # characteristics, capabilities, limitations
"art13_3_c": "performance_limitations", # performance limitations by context
"art13_3_d": "human_oversight_measures", # human oversight technical measures
"art13_3_e": "input_data_requirements", # input data specifications
"art13_3_f": "changes_and_performance", # modification history
"art13_3_g": "computational_requirements", # computational and hardware requirements
}
elements_present = {k: v in content for k, v in element_map.items()}
return {
"valid": all(elements_present.values()),
"elements": elements_present,
}
def _hash_content(self, content: dict) -> str:
serialized = json.dumps(content, sort_keys=True).encode()
return hashlib.sha256(serialized).hexdigest()
def _generate_art14_requirements(self) -> dict:
"""Extract Art.14 human oversight requirements from IFU Element 4."""
if self.current_version is None:
return {}
oversight = self.current_version.ifu_content.get("human_oversight_measures", {})
return {
"art14_1_a_understand_capabilities": oversight.get("capability_understanding", ""),
"art14_1_b_awareness_of_automation_bias": oversight.get("automation_bias_warning", ""),
"art14_1_c_correct_interpretation": oversight.get("output_interpretation_guide", ""),
"art14_1_d_disregard_override": oversight.get("override_procedure", ""),
"art14_1_e_intervene_halt": oversight.get("halt_procedure", ""),
"minimum_human_competence": oversight.get("competence_requirements", []),
}
def _generate_art12_deployer_obligations(self) -> dict:
"""
Art.12(3) assigns log retention to deployers for public authorities
and financial institutions. This section informs deployers of their
specific retention obligations.
"""
return {
"retention_minimum_months": 6,
"applies_to": ["public_authorities", "financial_institutions"],
"log_categories_to_retain": [
"session_start_end_timestamps", # Art.12(2)(a)
"input_data_references", # Art.12(2)(b)
"human_oversight_events", # Art.12(2)(c)
"major_functionality_changes", # Art.12(2)(d)
],
"note": "Other deployers should retain logs per applicable sector law.",
}
def _generate_art28_checklist(self) -> list[dict]:
"""Art.28 deployer obligations checklist for handoff package."""
return [
{"obligation": "Use system only within intended purpose (Art.28(1)(a))", "self_assessment": False},
{"obligation": "Implement human oversight measures per IFU Art.14 section (Art.28(1)(b))", "self_assessment": False},
{"obligation": "Monitor system operation and report incidents to provider (Art.28(1)(c))", "self_assessment": False},
{"obligation": "Inform natural persons where Art.50 disclosure applies (Art.28(1)(d))", "self_assessment": False},
{"obligation": "Register system in EU database if public authority (Art.28(1)(e))", "self_assessment": False},
{"obligation": "Store Art.12 logs for minimum 6 months (Art.28(1)(f))", "self_assessment": False},
]
Art.13 × Art.12 Integration: IFU Version in the Audit Trail
Art.12(2)(d) requires logging "major changes in the system functionality and version." An IFU version update — which is triggered by a substantial modification — is precisely a major change in system functionality. This creates a mandatory Art.12 log event every time the IFU is updated.
The integration pattern:
from logging_event_registry import LoggingEventRegistry
class IntegratedComplianceSystem:
"""Integrates Art.13 IFU management with Art.12 logging."""
def __init__(self, system_id: str, provider_info: dict):
self.disclosure_mgr = TransparencyDisclosureManager(system_id, provider_info)
self.log_registry = LoggingEventRegistry(system_id)
def perform_substantial_modification(
self,
art11_modification_id: str,
updated_ifu_elements: dict,
modification_summary: str,
) -> dict:
# Step 1: Update IFU (Art.13(3)(f) obligation)
new_ifu_version = self.disclosure_mgr.update_for_substantial_modification(
art11_modification_id=art11_modification_id,
updated_elements=updated_ifu_elements,
modification_summary=modification_summary,
)
# Step 2: Log the version change (Art.12(2)(d) obligation)
art12_event = self.disclosure_mgr.generate_art12_log_event()
self.log_registry.log_version_change(
change_type="substantial_modification",
art11_modification_id=art11_modification_id,
ifu_version=new_ifu_version.version_number,
ifu_content_hash=new_ifu_version.content_hash,
)
# Step 3: Identify deployers requiring re-delivery (Art.13(2) ongoing obligation)
deployers_to_update = self.disclosure_mgr.get_deployers_requiring_update()
return {
"new_ifu_version": new_ifu_version.version_number,
"art12_log_event": art12_event,
"deployers_requiring_update": deployers_to_update,
"compliance_actions_required": len(deployers_to_update) > 0,
}
The combined log record links Art.11 modification → Art.13 IFU update → Art.12 audit event in a single traceable chain. An MSA investigation can follow this chain: "What changed? When was the IFU updated? Which deployers received the update?"
Art.13 × Art.14 Human Oversight Disclosure Requirements
Art.13(3)(d) requires the IFU to specify "the human oversight measures referred to in Art.14, including the technical measures put in place to facilitate the interpretation of the outputs of AI systems by the deployers." This creates a direct Art.13 → Art.14 content dependency: your Art.14 implementation determines Art.13(3)(d) content.
The Art.14 human oversight framework specifies five required capabilities for high-risk AI deployers:
| Art.14(1) Sub-provision | Required Capability | IFU Art.13(3)(d) Content |
|---|---|---|
| Art.14(1)(a) | Understand AI system capabilities and limitations | IFU must explain what the system can and cannot do with sufficient precision for non-expert deployers |
| Art.14(1)(b) | Awareness of automation bias | IFU must identify circumstances where the system is particularly susceptible to automation bias |
| Art.14(1)(c) | Correct interpretation of outputs | IFU must provide output interpretation guidance: what high/low confidence scores mean, how to handle edge cases |
| Art.14(1)(d) | Decide not to use or disregard outputs | IFU must document override procedures: when deployers should disregard system recommendations |
| Art.14(1)(e) | Intervene in operation or interrupt | IFU must specify halt procedures and emergency stop mechanisms |
The practical implication: Art.14 implementation drives Art.13(3)(d) content. Design your human oversight system first, then document it in the IFU. A provider that builds override procedures without documenting them in the IFU satisfies Art.14 but fails Art.13.
Art.13 × Art.50: Chatbot and Emotion Recognition Disclosure
Art.13 creates provider→deployer transparency. Art.50 creates deployer→end-user transparency. The intersection matters for two high-risk AI categories:
Chatbot disclosure (Art.50(1)): Deployers using AI systems that interact with natural persons must inform those persons that they are interacting with an AI system. The Art.13 IFU for a chatbot-capable high-risk AI must therefore specify: (a) that the system is a chatbot, (b) the technical mechanism for Art.50(1) disclosure (typically a UI notice), and (c) the conditions under which disclosure may be omitted (Art.50(1) exception: obvious context).
Emotion recognition disclosure (Art.50(2)): Providers and deployers using emotion recognition systems must inform natural persons exposed to those systems. For a provider building an emotion recognition component into a high-risk AI system, the Art.13 IFU must include: (a) confirmation that emotion recognition is present, (b) the categories of emotions the system detects, (c) the disclosure mechanism the deployer must implement.
class ChatbotDisclosureSection:
"""
Art.13(3) IFU section for chatbot-capable systems (Art.50 intersection).
"""
def generate_art50_ifu_section(self, system_capabilities: dict) -> dict:
section = {
"art50_disclosure_required": system_capabilities.get("has_natural_language_interaction", False),
"emotion_recognition_present": system_capabilities.get("emotion_recognition", False),
}
if section["art50_disclosure_required"]:
section["disclosure_mechanism"] = {
"requirement": "Deployer must display Art.50(1) notice before or at interaction start",
"suggested_text": "You are interacting with an AI system.",
"exception": "No disclosure required when obvious from context (Art.50(1) proviso)",
}
if section["emotion_recognition_present"]:
detected_emotions = system_capabilities.get("emotion_categories", [])
section["emotion_recognition_disclosure"] = {
"requirement": "Art.50(2) — deployer must inform exposed persons",
"categories_detected": detected_emotions,
"suggested_notice": f"This system analyses emotional cues in the categories: {', '.join(detected_emotions)}.",
}
return section
Deployer Handoff Package: Automating Art.13 Compliance
The deployer handoff package bundles Art.13 IFU, Art.14 oversight requirements, Art.12 retention obligations, and Art.28 deployer checklist into a single structured artifact. This pattern reduces deployer onboarding risk: instead of deployers independently interpreting scattered obligations, the provider hands over a structured compliance starter kit.
class DeployerOnboardingOrchestrator:
"""
Generates and delivers Art.13-compliant deployer onboarding packages.
Tracks delivery for audit purposes.
"""
def __init__(self, compliance_system: IntegratedComplianceSystem):
self.compliance_system = compliance_system
def onboard_deployer(self, deployer_id: str, delivery_method: str = "api") -> dict:
disclosure_mgr = self.compliance_system.disclosure_mgr
# Generate handoff package (Art.13 + Art.14 + Art.12 + Art.28)
package = disclosure_mgr.generate_deployer_handoff_package(deployer_id)
# Record delivery (Art.13(2) compliance evidence)
delivery = disclosure_mgr.deliver_to_deployer(deployer_id, delivery_method)
# Log delivery as Art.12 event (creates provider audit trail)
self.compliance_system.log_registry.log_deployer_disclosure(
deployer_id=deployer_id,
ifu_version=disclosure_mgr.current_version.version_number,
delivery_id=delivery.delivery_id,
)
return {
"deployer_id": deployer_id,
"delivery_id": delivery.delivery_id,
"ifu_version_delivered": disclosure_mgr.current_version.version_number,
"handoff_package": package,
"compliance_status": "art13_delivered",
}
def notify_deployers_of_update(self) -> list[str]:
"""
After a substantial modification, identify and notify all deployers
that must receive the updated IFU. Returns list of deployer IDs notified.
"""
deployers_to_update = self.compliance_system.disclosure_mgr.get_deployers_requiring_update()
notified = []
for deployer_id in deployers_to_update:
result = self.onboard_deployer(deployer_id)
notified.append(deployer_id)
return notified
Art.13 × Art.86: Right to Explanation
Art.86 creates a right for natural persons affected by high-risk AI decisions to obtain an explanation of the decision from the deployer. The deployer's ability to provide this explanation depends entirely on what the provider disclosed in the Art.13 IFU — specifically Art.13(3)(b) (capabilities and limitations) and Art.13(3)(c) (performance by context).
The Art.13 → Art.86 chain:
- Provider documents decision logic, confidence thresholds, and performance limitations in IFU Art.13(3)(b)-(c)
- Deployer uses IFU to understand how to interpret outputs (Art.14(1)(c))
- Natural person exercises Art.86 right — deployer explains the decision using IFU-documented logic
- If IFU is incomplete (missing Art.13(3)(b)-(c) content), deployer cannot comply with Art.86 — liability traces back to provider
The practical implication for IFU Element 2 (characteristics and capabilities): the IFU must include sufficient explanation of the decision mechanism that a deployer can articulate to an affected person why the system reached its output. This requires more than accuracy metrics — it requires decision pathway description, key input factors, and confidence score interpretation.
IFU Validation: Pre-Market Compliance Checklist
Before market placement, run this 12-item Art.13 validation:
- IFU v1.0 created before system is placed on the market (Art.13(2) pre-placement)
- Art.13(3)(a) present: Provider identity, registered address, EU-accessible contact
- Art.13(3)(b) present: Capabilities, intended purpose, accuracy metrics with demographic breakdown where Art.10(5) applies
- Art.13(3)(c) present: Identified contra-indicated use cases and performance degradation contexts
- Art.13(3)(d) present: All five Art.14(1)(a)-(e) measures documented with deployer-implementable instructions
- Art.13(3)(e) present: Input data format, pre-processing requirements, prohibited inputs
- Art.13(3)(f) present: Modification history section (initially empty, structure must exist)
- Art.13(3)(g) present: Hardware, latency, and integration requirements
- Art.50 section present where chatbot interaction or emotion recognition is present
- IFU version linked to Art.11(4) documentation version in the modification record
- Deployer delivery mechanism established and delivery recorded before deployment
- Art.12 log event generated for IFU v1.0 activation
Common Art.13 Failure Modes
Failure Mode 1 — Static IFU: IFU written once and never updated after substantial modifications. Violates Art.13(3)(f) and disconnects Art.13 from Art.11(4) lifecycle.
Failure Mode 2 — Generic capabilities section: Art.13(3)(b) contains only marketing language ("state-of-the-art performance") without specific accuracy metrics or demographic breakdown. Fails the "correct and complete" standard of Art.13(2).
Failure Mode 3 — Missing Art.14 mapping: Art.13(3)(d) describes human oversight in abstract terms ("humans should review outputs") without specifying which Art.14(1)(a)-(e) measures are implemented and how deployers implement them. Fails Art.13(3)(d) and prevents Art.14 compliance downstream.
Failure Mode 4 — IFU not delivered before deployment: Deployer onboarded before receiving current IFU version. Violates Art.13(2) which requires the system to "be accompanied by" the IFU — not delivered at some later point.
Failure Mode 5 — Art.13 not re-delivered after modification: Substantial modification triggers IFU update under Art.13(3)(f), but existing deployers continue using the old version. Violates the ongoing delivery obligation implied by Art.13(2) and the modification disclosure requirement in Art.13(3)(f).
Cross-Reference Matrix
| Article | Connection to Art.13 | Practical Integration |
|---|---|---|
| Art.9 | Art.13(3)(c) must reference Art.9(2)(a) risk scope | IFU performance limitations section must mirror the risk management system boundaries |
| Art.10 | Art.13(3)(b) accuracy metrics must reflect Art.10(5) bias testing | IFU capabilities section must include demographic performance data |
| Art.11 | Art.11(4) substantial modification triggers Art.13(3)(f) update | Every Art.11(4) event generates a mandatory IFU version bump |
| Art.12 | IFU version changes are Art.12(2)(d) major changes | IFU version activation must generate Art.12 log event |
| Art.14 | Art.14(1)(a)-(e) determines Art.13(3)(d) content | Design Art.14 implementation first, then document in IFU |
| Art.50 | Art.13 IFU must specify Art.50(1)/(2) disclosure requirements for deployers | Chatbot + emotion recognition systems require Art.50 section in IFU |
| Art.86 | Art.13(3)(b)-(c) must enable deployer compliance with Art.86 explanation | IFU decision logic section must support natural language explanation to affected persons |
| Art.28 | Art.28 deployer obligations are enabled by Art.13 IFU | Art.28 checklist belongs in deployer handoff package |
See Also
- EU AI Act Art.11: Technical Documentation Lifecycle 2026 — Art.11(4) substantial modification triggers that drive Art.13 IFU updates
- EU AI Act Art.12: Logging Obligations as an Operational Compliance System 2026 — Art.12(2)(d) log events generated by Art.13 IFU version changes
- EU AI Act Art.13 Transparency Obligations: Developer Guide — What Art.13 requires: seven IFU elements, Art.13 × Art.50 intersection, Art.13 × Art.86 right to explanation
- EU AI Act Art.9: Risk Management System Developer Guide — Art.9 RMS that feeds Art.13(3)(c) performance limitation disclosure