AI governance framework for Polish financial

A mid-sized Polish bank begins deploying a credit-scoring algorithm trained on customer transaction data. Six months later, the Polish Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) opens an inquiry. The bank cannot produce a governance trail – no risk classification, no human-oversight log, no DORA incident register. The window for voluntary remediation has closed. What began as a missed compliance step has become an enforcement matter with no easy exit.

Polish financial institutions using artificial intelligence must comply with the EU AI Act, the Digital Operational Resilience Act (DORA), and GDPR Poland requirements simultaneously. The AI Act classifies credit-scoring and fraud-detection tools as high-risk AI systems, triggering mandatory conformity assessments, transparency obligations, and human-oversight controls before deployment. DORA adds ICT risk-management and incident-reporting layers that overlap directly with AI governance. Institutions that deploy without a documented framework forfeit the ability to self-remediate before supervisory scrutiny begins.

This guide walks through the four-stage governance framework in sequence: risk classification, policy architecture, DORA alignment, and ongoing audit. It covers timelines, cost bands, three business scenarios, and the most common structural mistakes. Each section opens with a direct answer and at least one concrete figure so you can benchmark your current position immediately.

How does the EU AI Act classify AI systems used by Polish financial institutions?

Risk classification is the foundation of the entire governance framework. The AI Act divides AI systems into four tiers – unacceptable risk, high risk, limited risk, and minimal risk – and the tier determines every downstream obligation. For Polish financial institutions, the critical tier is high risk. Credit-scoring models, anti-money-laundering (AML) filters, fraud-detection engines, and insurance-underwriting tools all fall within Annex III of the AI Act as high-risk systems. High-risk classification triggers a conformity assessment that must be completed before the system goes live, not after.

The National Court Register (Krajowy Rejestr Sądowy, KRS) records the legal entity that deploys the system. That entity becomes the "provider" or "deployer" under the AI Act, depending on whether it developed the model in-house or procured it. The distinction matters. Providers carry the heavier burden – technical documentation, conformity assessment, CE marking (once the EU database is operational). Deployers must still conduct their own fundamental-rights impact assessment and maintain a human-oversight procedure. Banks that buy AI tools from vendors often mistakenly assume all obligations transfer to the vendor. They do not.

The Office for Personal Data Protection (Urząd Ochrony Danych Osobowych, UODO) enforces GDPR Poland obligations that run in parallel with AI Act classification. Any high-risk AI system processing personal data – which credit scoring invariably does – also requires a Data Protection Impact Assessment (DPIA) under GDPR Poland. The DPIA and the AI Act conformity assessment are separate documents, but they share inputs. Running them together reduces duplication and typically cuts the combined timeline from 16 weeks to around 10 weeks.

Confirm whether your institution is a provider or deployer for each AI tool.
Map every AI use case against Annex III categories before any deployment decision.
Trigger a DPIA alongside the conformity assessment for all personal-data processing.
Document the classification rationale – KNF expects to see it on request.

One practical point worth flagging: a model used internally for employee monitoring is also classified as high risk. Several Warsaw-based institutions discovered this only after HR tools were already live. Retroactive classification and documentation is possible but costly – typically 30–40% more expensive than pre-deployment work because it requires reconstructing training-data logs that may no longer be fully intact.

What does a compliant AI governance policy architecture look like?

Once risk classification is complete, the institution needs a written governance framework covering four policy layers: an AI Register, an Acceptable Use Policy (AUP), a Model Risk Management (MRM) policy, and a Human Oversight Procedure. All four must be in force before a high-risk system is deployed. The AI Register alone is not sufficient. KNF's supervisory guidance from late 2024 explicitly referenced multi-layer documentation as the baseline expectation for regulated entities.

The AI Register is the master inventory. It records every AI system in use, its risk tier, the responsible business owner, the date of last review, and the outcome of the conformity assessment or DPIA. The register should be updated at least quarterly. A static register that reflects the position at launch but not subsequent model retraining is one of the most common governance failures we see. Model retraining can change a system's risk profile – a fraud filter retrained on new data may behave materially differently from its predecessor.

We secured a full governance-framework sign-off for a payment institution in Mazowieckie (spring 2026). The institution had a register and an AUP but lacked a formal MRM policy. KNF's pre-examination questionnaire flagged the gap. We drafted the MRM policy and a retrospective conformity assessment within six weeks, closing the gap before the on-site visit.

The Human Oversight Procedure is the element most frequently underestimated. The AI Act requires that a natural person can intervene, override, or halt a high-risk AI system. The procedure must name the role (not just the department), specify the escalation path, and be tested at least once per year. Testing costs are modest – typically PLN 15,000–40,000 for an external facilitator – but the absence of any test record is treated by supervisors as a substantive deficiency, not a paperwork gap.

For a practical decision matrix: if your institution has fewer than 20 AI use cases, a single integrated governance document covering all four layers is workable. Above 20 use cases, separate policies per layer with a master governance charter reduce version-control risk and make supervisory responses faster to prepare.

How does DORA reshape AI governance obligations for financial institutions?

DORA has applied to Polish financial institutions since January 2025. Its ICT risk-management framework interacts with AI governance at three points: ICT asset classification, incident reporting, and third-party provider oversight. Every AI system is an ICT asset under DORA. That means it must appear in the institution's ICT asset register, be assigned a criticality rating, and be covered by a business-continuity scenario. Institutions that maintain separate AI and ICT registers without cross-referencing them create a structural gap that both KNF and the European Banking Authority (EBA) have flagged in supervisory communications.

DORA's incident-reporting timeline is tight. A major ICT incident – including an AI system producing systematically incorrect outputs that affect clients – must be reported to KNF within 4 hours of classification as major, with a full root-cause report within 72 hours. Institutions that lack a pre-drafted incident-response playbook for AI failures routinely miss the 4-hour notification window. Missing it does not just trigger a fine; it precludes the "good faith" mitigation that supervisors apply when assessing penalty levels.

Third-party AI providers are subject to DORA's vendor-oversight rules. Financial institutions must maintain a register of ICT third-party providers, assess their concentration risk, and include AI-specific clauses in contracts – covering audit rights, data-return obligations, and exit procedures. A standard SaaS agreement without these clauses does not satisfy DORA. Renegotiating vendor contracts post-deployment is possible but typically takes 3–6 months and sometimes requires parallel contingency arrangements.

For a cross-border perspective on data flows that underpin AI systems, see our analysis of data transfer from Poland to France – legal mechanisms, which covers the Standard Contractual Clauses and supplementary measures relevant to AI training-data pipelines routed through EU member states.

What are the three business scenarios and common implementation mistakes?

Understanding how the framework applies in practice requires looking at three distinct institutional profiles. Each faces a different starting point and a different set of risks.

Scenario 1 – Mid-sized domestic bank. A Warsaw-based bank with 400,000 retail clients deploys a credit-scoring model developed in-house. It is a provider under the AI Act. The full governance build – classification, conformity assessment, DPIA, four-layer policy architecture, DORA integration – typically takes 14–18 weeks and costs PLN 180,000–320,000 in external advisory and testing fees. The most common mistake: treating the conformity assessment as a one-time event. Model retraining above a defined materiality threshold restarts the assessment obligation.

Scenario 2 – Fintech deployer. A Kraków-based payment institution procures a fraud-detection engine from a German vendor. It is a deployer, not a provider. Its obligations are lighter on technical documentation but heavier on fundamental-rights impact assessment and human-oversight implementation. Timeline: 8–10 weeks. The most common mistake: relying entirely on the vendor's conformity documentation without conducting an independent deployer-level review. GDPR Poland and the AI Act impose deployer obligations that cannot be contracted away.

Scenario 3 – Foreign investor entering Poland. A Dutch asset manager establishes a Polish subsidiary and intends to use an AI-driven portfolio-management tool already cleared for use in the Netherlands. It cannot simply port that clearance to Poland. The Polish entity must complete its own KRS registration, conduct a Poland-specific conformity assessment referencing KNF's supervisory guidance, and register the system in Poland's national AI database once operational. We obtained a structured governance sign-off for a similar client in Lower Silesia (autumn 2025), completing the Poland-specific assessment in 11 weeks by reusing 60% of the existing Dutch documentation.

The three most common implementation mistakes across all scenarios: (1) deploying before the conformity assessment is finalised, (2) failing to update the AI Register after model retraining, and (3) omitting AI systems from DORA ICT asset registers. Each of these individually is sufficient to trigger a KNF deficiency finding. Together, they constitute a pattern that supervisors treat as systemic governance failure rather than isolated oversight.

For institutions managing IP considerations alongside AI deployment – particularly those using proprietary training data or AI-generated outputs – our guide on IP protection strategy for Switzerland tech companies in Poland addresses ownership and licensing structures relevant to cross-border AI asset management. Separately, institutions with real-estate-backed collateral portfolios assessed partly by AI valuation tools should be aware of the reclassification risks discussed in our briefing on real estate tax reclassification disputes – 2025 wave.

The governance framework is not a static deliverable. It is a living system that requires quarterly register updates, annual oversight-procedure testing, and a standing review trigger whenever a model is materially retrained. Institutions that treat initial compliance as the finish line typically find themselves rebuilding the framework from scratch within 18 months.

Frequently asked questions

Q: How long does it take to build an AI governance framework from scratch for a Polish bank?

A: For a mid-sized bank acting as provider of a high-risk AI system, the full build – classification, conformity assessment, DPIA, four-layer policy architecture, and DORA integration – typically takes 14–18 weeks. Running the DPIA and conformity assessment in parallel, rather than sequentially, is the most reliable way to compress the timeline. Institutions with existing ICT risk-management documentation can reduce the DORA integration phase to 3–4 weeks by mapping existing controls to AI-specific requirements rather than drafting from scratch.

Q: Is it a common misconception that procuring an AI tool from a certified EU vendor means no Polish compliance steps are needed?

A: Yes – this is one of the most frequent misunderstandings we encounter. A vendor's conformity assessment covers the provider's obligations. The deploying institution in Poland must still complete its own fundamental-rights impact assessment, implement a human-oversight procedure, register the system in its AI Register, and satisfy DORA's third-party oversight requirements. GDPR Poland obligations apply independently of what the vendor has documented. There is no "pass-through" of compliance status from vendor to deployer under Polish or EU law.

Q: What does AI governance cost for a smaller fintech acting as a deployer?

A: For a fintech deployer procuring a single high-risk AI tool, the external advisory and testing cost typically falls in the PLN 60,000–120,000 range, depending on the complexity of the tool and whether existing data-protection documentation can be reused. The human-oversight procedure test, if conducted by an external facilitator, adds PLN 15,000–40,000. Internal staff time – typically from legal, compliance, and IT teams – adds the equivalent of 4–8 weeks of one FTE. Costs rise significantly if the system is already live and documentation must be reconstructed retrospectively.

What to prepare before engaging external AI governance counsel

A list of all AI tools currently in use or under procurement, with the name of the business owner for each.
Copies of any existing ICT asset register, data-processing register, and DPIA documentation.
Vendor contracts for any procured AI tools, including any existing SLA or data-processing agreements.
KNF correspondence or supervisory questionnaires received in the past 12 months referencing AI or ICT risk.
Internal model-validation reports, if any, for credit-scoring or fraud-detection tools.

Your institution's specific position – provider or deployer, number of high-risk systems, existing DORA maturity – determines which governance components need to be built and which can be adapted from existing documentation. Attempting to build a generic framework without first mapping that position wastes resources and often produces documentation that does not survive supervisory scrutiny. Personal liability of senior management functions for governance failures is a real risk under Polish financial law, and it is not remediated by a framework that looks complete on paper but lacks operational substance.

To receive an expert assessment of your institution's AI governance position and a prioritised remediation roadmap, contact info@kordeckipartners.com.

KORDECKI & Partners is a law firm based in Warsaw and Krakow, advising business clients across 30 jurisdictions. Our team combines expertise in Polish and international law with a practical approach to AI regulation, DORA compliance, and technology governance. We work with Polish financial institutions, foreign investors, and in-house legal teams navigating the AI Act, GDPR Poland, and DORA simultaneously. To discuss your situation, contact info@kordeckipartners.com.