EU AI Act

The AI Act regulates AI systems according to what they are used for. An AI system is a machine-based system that infers from its input how to generate outputs such as predictions, content, recommendations or decisions (Article 3(1)). The same model can be minimal risk in one product and high-risk in another.

Duties follow roles. A provider develops an AI system or model, or has it developed, and places it on the market or puts it into service under its own name. A deployer uses an AI system under its authority in a professional activity (Article 3(3) and 3(4)). A company that builds its own scoring model and uses it is both.

A deployer can also become a provider. Article 25(1) names three cases: you put your name on a high-risk system, you make a substantial modification to one, or you change the purpose of another system so that it becomes high-risk. That last case covers general-purpose systems too. The original provider then has to hand over the documentation and technical access the new provider needs, unless it said that its system must not be turned into a high-risk one (Article 25(2)).

General-purpose AI models, such as the large language models behind chat assistants, have their own chapter. Their providers keep technical documentation, give information to the companies that build on the model, have a copyright policy and publish a summary of the training content (Article 53). Models with systemic risk carry extra duties (Article 55).

The Act entered into force on August 1, 2024 and applies in stages (Article 113). The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on July 27, 2026 and moved the high-risk dates. Many texts written before then still give August 2, 2026 for high-risk systems, which was the original date.

For a lender the line that matters is point 5(b) of Annex III. AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score are high-risk. Systems used to detect financial fraud are excluded. Point 5(c) adds risk assessment and pricing in life and health insurance. Under Article 6(3) an Annex III system is not high-risk if it poses no significant risk and, for example, only performs a narrow procedural task, improves the result of a completed human activity or performs a preparatory task for an assessment. A system that profiles natural persons is always high-risk.

The provider of a high-risk system carries most of the work. It needs a risk management system, governance of training, validation and test data, technical documentation, automatic event logs, instructions for use and human oversight (Articles 9 to 14). The system must also be accurate, resilient to errors and attacks, and secure (Article 15). Then come a conformity assessment (Article 43) and registration in the EU database (Article 49). A lender that uses a scoring tool built by someone else is a deployer and must (Article 26):

• use the system according to the provider's instructions and assign human oversight to people with the competence, training and authority for it,
• make sure that input data under its control is relevant and sufficiently representative,
• monitor the system and report risks and serious incidents,
• keep the logs under its control for at least six months; financial institutions keep them as part of the documentation that financial services law requires,
• tell applicants that a high-risk AI system is used in decisions about them.

Deployers of credit scoring systems also carry out a fundamental rights impact assessment before first use (Article 27). Where the GDPR data protection impact assessment already covers a point, the deployer can cross-reference it or reuse its parts (Article 27(4), as amended by the Omnibus). A person affected by a decision based on the system's output has the right to a clear explanation of the role the system played (Article 86). For consumer credit, CCD2 adds a right to human intervention after an automated creditworthiness assessment. Both sets of rules end up in the same places in the product: a way for the applicant to ask for human intervention, a queue for the people who review, and a record of how each decision was made.

If you build on someone else's general-purpose model, the model duties stay with the model provider. Your duties depend on the use. A chatbot must make clear to people that they are talking to an AI (Article 50(1)). A system that generates audio, images, video or text must mark its output in a machine-readable way (Article 50(2)). A deployer that publishes deepfakes must label them (Article 50(4)). If you point the same model at an Annex III use such as credit scoring, you become the provider of a high-risk system (Article 25(1)(c)).

Since February 2, 2025 providers and deployers have had to take measures for the AI literacy of their staff (Article 4). The Omnibus rewrote this as a duty to support AI literacy, without a duty to ensure any particular level of it.

• List every AI feature and model in your products and internal tools, with its purpose and the model behind it.
• Classify each one as prohibited, an Annex III use, a transparency case or minimal risk, and write down why. If you rely on Article 6(3), document the assessment before the system is placed on the market or put into service, and register the system in the EU database (Articles 6(4) and 49(2)). The Omnibus kept this registration and shortened the information it requires (Annex VIII, Section B).
• Decide your role for each system (provider, deployer or both) and check your contracts with model and tool vendors against it.
• For a high-risk use, design logging, human review and explanations into the product now. They are hard to add later.
• Test every model or prompt change on a fixed evaluation set with agreed acceptance criteria (LLM evaluation) and keep the results.
• Map what personal data reaches the model, where the model runs (a self-hosted LLM or an external API) and what is anonymized before reuse (data anonymization).

Article 99 sets maximum fines. Prohibited practices can cost up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher. Breaching most other obligations, including those of providers and deployers of high-risk systems and the transparency duties of Article 50, can cost up to EUR 15 million or 3%. Giving incorrect or misleading information to authorities can cost up to EUR 7.5 million or 1%. For SMEs, startups included, the lower of the two amounts applies (Article 99(6)). The Digital Omnibus extends that rule to small mid-cap enterprises (SMCs) for the two lower tiers, but not for prohibited practices (Article 99(6a)). The Commission can fine providers of general-purpose AI models up to EUR 15 million or 3% (Article 101).

National market surveillance authorities enforce the rules for AI systems, and the AI Office in the Commission supervises general-purpose models.

Other law still applies alongside the AI Act. Personal data in training sets and prompts stays under the GDPR, consumer credit decisions under CCD2, and identity checks under anti-money laundering rules (KYC). Harmonized standards, prepared by the European standardization bodies CEN and CENELEC, will give providers that follow them a presumption of conformity with the high-risk requirements (Article 40).

Poland supervises the AI Act under the Act on Artificial Intelligence Systems of July 3, 2026 (Journal of Laws 2026, item 1003), in force since August 11, 2026. It sets up the Commission for the Development and Safety of Artificial Intelligence (KRiBSI), the market surveillance authority for AI systems and the single point of contact for EU institutions. The KNF, the Polish financial supervisor, nominates one member of KRiBSI, and the two bodies work together on the matters covered by Article 74(6) of the AI Act, which concern high-risk AI systems used by financial institutions (Articles 5, 19 and 20 of the Polish act).

From October 28, 2026 KRiBSI can run inspections, conduct proceedings and impose fines (Chapters 3, 4 and 8 of the Polish act). From the same date a company can ask KRiBSI for an individual opinion on how the AI Act applies to its case (Articles 8 to 18 of the Polish act).

We build software around language models and add AI features to existing products, usually as a separate service the application calls. On the energy procurement advisory platform we built for Enerace, AI writes market news from current market data. For a product platform in the home renovation market we run an in-app AI chat and a product-search agent. For PSONI we are building Generator ETR, a web and mobile app that uses a self-hosted language model to turn documents such as official letters into easy-to-read text. In features like these, Article 50 decides what the user sees: a notice that they are talking to an AI and marking of generated content.

In lending we build the customer side for lenders supervised by the KNF: the loan app, KYC and the integrations with the lender's core system. The app is where the applicant sees the credit decision. If the lender's scoring falls under Annex III, the app is also where the applicant learns that a high-risk AI system was used and asks for human intervention and an explanation (Articles 26(11) and 86 of the AI Act, Article 18 of CCD2). Credit decisions, scoring and pricing stay in the lender's core system. The client's lawyer confirms the legal classification of each system.