Skip to main content
JOJonas Osman
· 4 min read

EU AI Act 2026: Transparency Duties

By , Actuary & Quantitative Risk Expert

For financial institutions, the AI Act is less a new compliance regime than a documentation and classification problem attached to existing model governance.

This article relates to my work on AI & Quantitative Risk Models, Geopolitical & War Risk and Model Validation & Model Risk.

By Jonas Osman Abdelghafour.

The EU AI Act applies horizontally, which is precisely why it is awkward for financial institutions: obligations attach to the role an organisation plays in relation to a system — provider, deployer, importer, distributor — rather than to the regulated activity it performs. A bank that buys a screening tool is a deployer; a bank that fine-tunes and markets one becomes something closer to a provider. Getting that classification wrong is the most expensive mistake available, because it determines the entire obligation set.

Classification is the first control

Two questions drive the work. First, is the system in scope as AI at all under the Act's definition? Second, what risk category applies? For financial services, the categories that bite are prohibited practices (narrow but absolute), high-risk uses — most relevantly creditworthiness assessment of natural persons and risk assessment and pricing in life and health insurance — and the transparency tier that applies to systems interacting with people or generating content.

Everything downstream depends on this mapping, so it belongs in the model inventory as a recorded attribute with an owner and a review date, not in a separate compliance spreadsheet.

Transparency in practice

The transparency obligations are usually described as "tell people they are talking to a machine". The operational reality is broader. Systems that interact directly with individuals must make that clear at the point of interaction, in the interface, not in a policy buried three clicks away. Synthetic or manipulated content needs machine-readable marking. Emotion-inference and biometric-categorisation uses carry their own disclosure duties and, in employment contexts, are heavily constrained.

For a retail bank the practical output is unglamorous: chat interfaces that identify themselves, contact-centre scripts that disclose automated handling, marketing content pipelines that label generated assets, and an evidence trail showing when each disclosure was implemented.

High-risk obligations map onto controls you already have

Where a use falls into the high-risk category — credit scoring for consumers, insurance pricing in the named lines — the requirements read like a well-run model risk framework with extra paperwork: a risk management system across the lifecycle, data governance covering representativeness and bias, technical documentation, automatic logging, human oversight designed into the workflow, and accuracy, robustness and cybersecurity commensurate with the use.

The efficient response is mapping rather than duplication. Data governance requirements map to existing data lineage and quality controls. Technical documentation maps to model development documentation, extended with the Act's specific fields. Human oversight maps to the override and escalation design that validation should already be testing. Logging maps to audit trail requirements. Institutions that build a parallel AI Act compliance stack end up maintaining two descriptions of the same model, which diverge within a year.

Deployers also carry duties in their own right — using the system in line with the provider's instructions, ensuring input data is relevant, assigning competent human oversight, monitoring operation, and in several cases informing affected individuals. A bank cannot outsource these to the vendor.

General-purpose models and the supply chain

Most institutions consume general-purpose models rather than build them. The provider carries documentation and, above the systemic-risk threshold, additional obligations; the deployer still needs enough information to discharge its own duties. That makes contractual access to technical documentation, notice of material model changes, and evidence supporting intended-use claims a procurement requirement, not a nice-to-have. Where a provider will not supply it, the institution should assume it will need compensating testing and should price that into the build-versus-buy decision.

What to do in the next two quarters

  • Tag every AI system in the inventory with role, risk category and legal basis, and have that classification reviewed independently.
  • Close transparency gaps in customer-facing channels first; they are visible, cheap to fix, and the easiest to be caught on.
  • Map high-risk requirements onto existing model risk artefacts and fill the deltas rather than writing new ones.
  • Fix procurement templates so documentation, change notice and audit rights are standard.
  • Build AI literacy obligations into training for staff who operate or oversee these systems.

The institutions that will find the AI Act manageable are those whose model governance already produces evidence on demand. For them it is a classification and disclosure exercise. For those whose AI estate is undocumented, it is a discovery exercise first — and discovery under a regulatory deadline is the most expensive way to learn what you own.

Primary sources: Regulation (EU) 2024/1689 (AI Act); European Commission AI Act Service Desk guidance on Article 50 transparency obligations.