The EU AI Act in Financial Services: How Data Products, Data Contracts, and Semantics Meet the Evidence Requirements

What changed in July 2026

The EU AI Act (Regulation (EU) 2024/1689) is the world's first comprehensive AI regulation. It follows a risk-based approach: some AI practices are prohibited outright, high-risk AI systems face strict requirements, and AI systems that interact with people carry transparency obligations.

In July 2026, Germany defined who enforces this in the financial sector: the German implementation act (KI-Marktüberwachungs- und Innovationsförderungsgesetz, KI-MIG) designates BaFin as the market surveillance authority for AI systems that are directly connected to a regulated financial activity. That covers banks, insurers, and other financial institutions supervised by BaFin or the ECB.

BaFin's supervision covers, among other things:

• Prohibited AI practices (Article 5), banned since February 2, 2025.
• Transparency obligations (Article 50) for AI systems that interact directly with people (think chatbots in customer communication), supervised from August 2, 2026.
• High-risk AI systems (Annex III), which explicitly include creditworthiness assessment by banks and risk assessment and pricing in life and health insurance, with full supervision phasing in through 2027.

BaFin can impose fines for violations, and it has stated clearly what it expects: institutions should maintain an inventory of the AI systems they use, understand which provisions of the AI Act apply to them, and embed the requirements into their existing governance, risk, and compliance structures, ideally building on the ICT asset inventory that DORA already requires.

AI compliance is mostly data compliance

Most of the obligations for high-risk AI systems concern the data feeding the AI system, not the model architecture.

Article 10: Data and data governance. Training, validation, and testing data for high-risk AI systems must be subject to appropriate data governance practices. That includes documented design choices, data collection processes and data origin, assessments of availability, quantity, and suitability, and examination for possible biases. Data must be relevant, sufficiently representative, and to the best extent possible free of errors and complete for the intended purpose.

Articles 12 and 13: Record-keeping and transparency. High-risk systems must be traceable, and deployers must be able to understand and interpret the system's output. In practice, you cannot explain an AI decision if you cannot explain what the input data means.

Article 14: Human oversight. Humans must be able to understand, monitor, and where necessary override AI decisions. Again: oversight of a credit scoring model is impossible without knowing exactly which data flows into it, from which source, under which quality guarantees, and with which business definition.

Article 4: AI literacy. Everyone operating or using AI systems needs sufficient competence, which includes understanding the data those systems consume.

So the practical question BaFin will ask is:

Which data does this AI system use? Where does it come from? Who is responsible for it? How is its quality assured and continuously monitored? What does it mean, in business terms? And is this use of the data actually permitted?

If your organization can answer these questions per AI system, from an authoritative inventory, with evidence, you are in a good position. If the answers live in individual heads, wiki pages, and outdated catalog entries, you have work to do before full supervision starts in 2027.

How Entropy Data helps you answer these questions

Entropy Data is a data product marketplace built on data contracts and semantics. It was built to make high-quality data available to people and AI agents. This is why it fits the AI Act's data obligations so well: the regulation demands, in legal language, what a well-run data product architecture already provides.

Ownership and inventory → Data Products

BaFin recommends orienting your AI inventory on the DORA ICT asset inventory. An AI inventory alone, however, is only half the picture: you also need to know which data each AI system consumes. Data products give you that other half. Each data product has a clearly assigned owner, a defined output port, and documented consumers. Connecting your AI use cases to the data products they consume turns "we have a list of our AI systems" into "for every AI system, we can show the complete data lineage, with a responsible owner for every source."

Data quality and origin (Article 10) → Data Contracts

A data contract specifies, in a machine-readable way (using the open ODCS standard): the schema, the semantics of every field, quality rules, service levels, terms of use, and the responsible owner. With the open-source Data Contract CLI, these guarantees are tested automatically in your CI/CD pipelines and monitored in production.

For Article 10, this changes the nature of your evidence. Instead of a data governance policy document, you have data governance in execution: documented origin, explicit quality criteria, and continuous automated verification that the data actually meets them. Quality checks and certification status are visible in the marketplace, so both your second line of defense and an auditor can see, at any time, whether the data feeding a high-risk system is within its contracted guarantees.

Meaning and human oversight (Articles 13 and 14) → Semantics

Explainability discussions usually focus on the model. In practice, they fail one step earlier: nobody can say precisely what the input data means. What counts as a "customer"? When is a payment "defaulted"? Which "revenue" is this, exactly?

The semantic layer answers this with a shared ontology of business concepts, metrics, and relationships, linked directly to data products, contracts, and individual fields. For regulated industries, you can build on established open ontologies, including FIBO for finance, and extend them with your own definitions. A human overseeing an AI decision, and an auditor reviewing it, can trace every input back to a well-defined business concept with a named authoritative definition.

Permitted use → Terms of use, enforced at access time

The AI Act, GDPR, and BaFin's supervisory expectations all require the same thing: data must be used only as intended and permitted, by humans and by AI.

In Entropy Data, terms of use are part of the data contract, and they are enforced. Access is requested and approved through the marketplace, so every usage relationship is documented with its purpose. And when AI clients access data through the MCP server, the requested use is checked automatically, at access time, against the data contract's terms of use and your global policies. This gives you an auditable answer to "how do you ensure your data is only used as permitted?", and the answer holds for autonomous AI agents, not just for trained employees.

Requirement to capability, at a glance

EU AI Act requirement	What BaFin will want to see	Entropy Data capability
AI system & data inventory	Which systems, which data, who is responsible	Data products with owners, consumers, lineage
Art. 10 data governance	Origin, quality criteria, continuous validation	Data contracts (ODCS) + Data Contract CLI testing, quality score, certification
Art. 13 transparency	What the inputs mean	Semantics: business ontology (incl. FIBO), authoritative definitions per field
Art. 14 human oversight	Ability to understand and override decisions	Semantic definitions + documented lineage per data product
Purpose limitation & permitted use	Data used only as intended, also by AI agents	Terms of use in contracts, self-service access workflow, MCP access checks, global policies
Ongoing compliance evidence	Continuous, not point-in-time	Automated contract tests, AI-powered policy checks, marketplace visibility

Use the time until 2027

The supervision timeline is staggered deliberately: transparency obligations are supervised now, full high-risk supervision phases in through 2027. That leaves time to prepare. Institutions that treat the AI Act as a documentation exercise will spend 2027 reverse-engineering their data flows under audit pressure. Institutions that build a data product foundation now get compliance as a by-product of good data architecture, plus everything else that foundation enables: trustworthy analytics, faster data access, and data that is actually usable by AI agents.

That last point matters beyond compliance. The same properties the regulator demands (clear ownership, guaranteed quality, explicit semantics, purpose-bound access) are what AI agents need to work with enterprise data safely. Preparing for the AI Act is therefore also groundwork for AI adoption in financial services. For more on this connection, read the BARC Spotlight A Data Marketplace Is What Your Agents Need.

See it in practice: try the 1-click demo (no registration required), or book a demo to talk through your AI Act readiness with us.

This article is for general information purposes and does not constitute legal advice. For an assessment of your specific obligations under the EU AI Act, please consult your legal and compliance functions.