AI Regulation for Polish Companies: A Practical Compliance Guide

Artificial intelligence is already part of normal business in Poland. A sales team drafts messages with a generative assistant. A shared service centre classifies invoices. A bank screens transactions. A manufacturer predicts maintenance needs. A recruiter searches and ranks applications. A customer service team uses an assistant that recommends replies. Each use can create value, but each also raises a practical question: can the company explain what the system does, what data it uses, who is affected, who is responsible, and what evidence supports the decision?

This guide is written for Polish company directors, legal and privacy teams, HR leaders, procurement managers, security teams, product owners, and operations managers. It describes the legal and operational position as of September 2026. It is practical information, not legal advice. The answer for a particular company depends on its role in the AI supply chain, the people and countries affected, the system, the data, the sector, and the contracts involved. Confirm a high impact deployment with qualified Polish and EU counsel.

The short answer for Polish companies

The EU AI Act is a directly applicable EU regulation. A Polish company does not wait for a Polish act to make the core regulation applicable. The Polish national act supplies the institutions, procedures, sanctions, accreditation arrangements, and market supervision needed to apply the EU regulation in Poland. On 3 July 2026 Poland adopted the Act on Artificial Intelligence Systems, published in the Journal of Laws as item 1003. It establishes the Commission for the Development and Security of Artificial Intelligence, commonly abbreviated as KRiBSI, as the market surveillance authority and single point of contact for the AI Act. The Ministry of Digital Affairs describes the commission as the body that will supervise application of the AI rules and receive complaints.

That national machinery does not replace the GDPR, the Polish Act on the Protection of Personal Data, employment law, consumer protection, competition law, cybersecurity requirements, financial supervision, medical rules, or product safety law. It also does not make every AI use high risk. The correct starting point is a documented assessment of the system, its purpose, its provider or deployer role, its data, its effect on people, and the applicable rules.

Keep a legal register that separates binding rules from interpretation and planning material. Binding rules include the AI Act, the Polish act, GDPR, Polish statutes, valid administrative decisions, court orders, and contractual commitments. Guidance from the European Commission, UODO, the European Data Protection Board, or a sector regulator can be influential and useful, but guidance is not automatically a new legal duty. A bill, consultation, strategy, press statement, standard, code of practice, or proposed amendment is not current binding law unless it has acquired that status through the proper legal process. This label should appear in the register, not only in a footnote.

What changed in the EU AI Act timeline

The AI Act uses a risk based model. It prohibits a limited set of unacceptable practices, imposes transparency duties for certain systems, places extensive requirements on high risk systems, and creates duties for providers of general purpose AI models. The regulation entered into force in 2024 and applies in stages. Prohibited practices and the AI literacy obligation have applied since 2 February 2025. Governance rules and obligations for general purpose AI models began on 2 August 2025. The general application date is 2 August 2026, subject to the specific transitional provisions and the later amendment described below.

As of this guide's September 2026 position, Regulation (EU) 2026/1744 has amended Article 113 of the AI Act. The amendment delays the application of the main high risk obligations in Chapter III, Sections 1, 2, and 3. High risk systems classified under Article 6(2) and Annex III move to 2 December 2027. High risk systems under Article 6(1) and Annex I move to 2 August 2028. This does not mean companies should pause preparation. Existing GDPR and sector obligations still apply, and the AI Act already contains binding duties outside those delayed provisions. Record the amended dates and verify later consolidated text before relying on them for a launch decision.

The AI Act's application dates are legal dates, not project dates. A responsible company may implement controls earlier because a customer contract, a risk assessment, a group policy, an insurer, a board decision, or a procurement requirement demands them. Early adoption is a business or governance choice. It should not be described as proof that a future obligation already applies, and delayed enforcement should not be treated as permission to ignore a foreseeable risk.

Poland's national implementation and KRiBSI

The Polish Act on Artificial Intelligence Systems is an implementation and enforcement framework around the EU regulation. It addresses market surveillance, proceedings for infringements, conformity assessment and notification, measures supporting AI development, and administrative fines. The act establishes KRiBSI as the market surveillance authority within the meaning of Article 70 of the AI Act and as the single point of contact. Its planned composition includes representatives of important public authorities, while its chair is appointed by the Sejm with the consent of the Senate for a five year term. The official Polish act and the Ministry of Digital Affairs should be the primary sources for scope, procedure, appointments, and sanctions.

The implementation calendar matters. The Ministry of Digital Affairs has said that the chair should be appointed within two months of the act entering into force and the full commission within three months. News about an appointment, a draft organisational regulation, or a public consultation should not be confused with the legal text itself. Maintain the official act, its entry into force, amendments, implementing measures, and regulator contact details in the legal register. Assign a person to monitor the Journal of Laws, gov.pl, and the authority's published materials.

A Polish company should identify its role before contacting or responding to the authority. It may be a provider, deployer, importer, distributor, product manufacturer, authorised representative, or provider of a general purpose AI model. It can hold different roles for different systems. The role affects documentation, cooperation, quality management, instructions, monitoring, incident reporting, and responsibility for downstream changes. Buying software does not automatically make the buyer a provider, but materially modifying a system, placing it under a company brand, or combining it with a product can change the analysis.

UODO, the President of the Personal Data Protection Office, remains central when an AI system processes personal data. UODO has publicly argued that the national framework must respect its independent GDPR mandate and its role in fundamental rights protection. The Polish act and EU framework require cooperation among authorities, but KRiBSI does not turn GDPR supervision into a function of an ordinary company compliance team. A business should be able to explain which matter concerns AI Act supervision, which concerns personal data processing, and how the two workstreams coordinate without assuming that one regulation takes automatic priority over the other.

GDPR and UODO: the rules still apply to the data

The GDPR applies to personal data used in training, fine tuning, evaluation, retrieval, prompts, outputs, monitoring, and human review. Personal data includes more than names and identification numbers. A combination of job title, location, dates, account history, health information, language, or a distinctive event can identify a person. Removing a name does not automatically anonymise the record. Embeddings, vector indexes, conversation histories, telemetry, and support tickets can also contain or reveal personal data.

For every use case, document the controller and processor roles, purpose, lawful basis, categories of data, data subjects, recipients, retention, international transfers, security measures, rights handling, and deletion route. The provider's statement that it does not train on prompts is useful evidence but does not answer whether the processing is lawful, proportionate, secure, or transparent. Check the actual plan, tenant settings, support access, subprocessors, logs, backups, and model improvement settings in the contract and technical configuration.

A data protection impact assessment is likely to be needed where processing is likely to result in a high risk to individuals, including systematic and extensive evaluation, large scale sensitive data, or systematic monitoring. UODO has stated that development and implementation of high risk AI systems will often be likely to result in a high risk for GDPR purposes. That is a risk indicator, not a rule that every system with an AI Act label automatically has an identical DPIA outcome. Assess the actual processing and document the reasoning.

Do not create one large AI DPIA that hides different activities. Separate a recruitment ranking system from an internal writing assistant, and separate a customer support retrieval system from model training. For each activity describe alternatives, necessity, proportionality, risks, mitigations, residual risk, and the decision maker. If a fundamental rights impact assessment is required under the AI Act, coordinate it with the DPIA, but preserve the questions and approvals that belong to each legal instrument.

UODO's published initial questions for AI tools are a useful starting point and explicitly do not replace a risk analysis or DPIA. Use them to force early questions about purpose, data, provider, rights, security, and the effect on individuals. Treat that material as guidance, not binding legal interpretation. UODO can still investigate a processing activity under the GDPR. A company that completes a checklist but cannot show lawful basis, minimisation, security, or a workable rights process has not achieved compliance.

Automated decisions, profiling, and Polish employment

Start with the effect on a person, not the vendor's label. A tool called a recommendation engine can determine which candidate gets an interview, which customer receives a fraud hold, which employee receives a performance warning, which claim is escalated, or which debtor receives a particular communication. Ranking, triage, scoring, prioritisation, and risk flags can influence a decision even when a manager signs the final document.

GDPR Article 22 restricts decisions based solely on automated processing, including profiling, when they produce legal effects or similarly significantly affect a person, subject to its conditions and exceptions. The precise application depends on the facts. A nominal approval is not necessarily meaningful human involvement. The reviewer needs authority, time, relevant context, training, and a real ability to disagree. Record overrides, reasons, corrections, and the final outcome. If every recommendation is accepted, the process may be effectively automated even if a person clicks the button.

Polish employers should also assess the Labour Code, equal treatment rules, occupational safety duties, collective arrangements, works council or employee representative expectations, and any sector requirements. The use of an AI tool in recruitment, scheduling, performance evaluation, promotion, discipline, dismissal, absence management, or workplace monitoring can affect rights and trust. A vendor's bias audit does not replace the employer's obligations. The employer controls the job description, input data, configuration, reviewer practice, accommodation route, and ultimate employment decision.

Before deployment, define job related criteria and prohibited proxies. Test selection rates, error patterns, language performance, accessibility, and disparate effects where lawful and statistically meaningful. Give candidates or workers the notices required by applicable law and explain how to raise a correction or accommodation request. Keep an escalation path outside the model. Never make a person prove that the system is wrong before a human will look at the underlying records.

AI literacy is a current obligation

Article 4 of the AI Act requires providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with AI systems on their behalf. This obligation has applied since 2 February 2025. It is broader than sending a generic e learning link. The level needed by a model engineer differs from the level needed by a buyer, recruiter, contact centre agent, manager, or executive approving a consequential use.

A practical Polish programme covers the limits of the system, hallucinations, automation bias, confidential and personal data, prompt injection, security, prohibited uses, escalation, human oversight, accessibility, and incident reporting. Provide role based training in a language staff understand, test comprehension, refresh it when the system changes, and retain attendance and assessment evidence. Contractors and suppliers who operate the system may need the same baseline. Training completion is a coverage metric, not proof that people can safely supervise a decision.

Prohibited practices and transparency duties

Screen every use against the AI Act's prohibited practices before considering efficiency or return on investment. The list includes practices such as certain manipulative or deceptive techniques, exploitation of vulnerabilities, social scoring, and specific biometric or emotion recognition uses, with detailed statutory conditions and exceptions. A business should not rely on a supplier's marketing description. Ask what data, inference, target group, and action the system actually uses. If the answer is uncertain, pause the use and obtain a legal review.

The Act also contains transparency duties for particular interactions and generated or manipulated content. Depending on the system and context, people may need to know that they are interacting with AI, that content was artificially generated or manipulated, or that biometric categorisation or emotion recognition is taking place. The notice should be timely, accessible, understandable, and connected to a route for human help. A disclosure buried in general terms is not automatically an effective notice.

Providers and deployers need to track the applicable date and role. A customer using a vendor's chatbot may be a deployer with a transparency duty, while the vendor may be the provider with technical documentation and instructions duties. A company that publishes a generated image, sends an AI drafted legal explanation, or operates a customer assistant should decide who approves content and what records prove that the notice was given.

Sector rules do not disappear behind AI

A Polish bank or payment institution should coordinate AI governance with the expectations of the Polish Financial Supervision Authority, outsourcing controls, operational resilience, consumer protection, anti money laundering requirements, credit assessment rules, and the EU Digital Operational Resilience Act where it applies. A scoring model used for credit or fraud can raise accuracy, explainability, discrimination, data quality, and contestability issues under more than one regime.

Healthcare companies should map medical device rules, clinical safety, professional accountability, health data protections, patient information, and any software qualification before treating an AI feature as an ordinary productivity tool. Manufacturers should consider product safety, machinery, transport, workplace safety, and conformity assessment. Telecommunications, energy, transport, education, insurance, and public procurement each have their own regulated context. The AI Act is horizontal. It adds a layer and does not repeal sector law.

Consumer facing uses also need a review under Polish consumer protection and unfair commercial practice rules. Do not claim that an assistant is accurate, autonomous, unbiased, secure, or compliant without evidence that matches the claim. A recommendation system that hides material commercial incentives, a chatbot that invents cancellation terms, or a dynamic price system that treats people unfairly can create exposure even if the model is not high risk under the AI Act.

Build an inventory before writing a policy

A policy written before discovery describes an imaginary company. Ask every function to list purchased applications, embedded AI features, public chat tools, APIs, browser extensions, open source models, pilots, agents, spreadsheet add ons, and supplier operated systems. Compare the answers with procurement records, cloud bills, identity groups, expense claims, software asset data, product roadmaps, HR processes, security logs, and customer contracts. Shadow AI is a finding to govern, not a reason to leave a use out of the inventory.

• System, feature, model or provider, version, owner, users, purpose, lifecycle stage, and connected actions.
• Input data, output recipients, personal or sensitive information, confidential material, retention, hosting, and international transfers.
• Affected people, countries, sector, decision effect, autonomy, human review, override authority, and ability to stop.
• Provider, deployer, importer or distributor role, contract, subprocessors, training settings, security evidence, incident contact, and exit plan.
• AI Act classification, GDPR analysis, sector rules, known limitations, test results, open questions, residual risk, and next review date.

Use internal risk tiers to make decisions, while stating clearly that the internal tier is not an EU legal classification. Low risk may include drafting or summarising with no personal or confidential input and no effect on a person. Medium risk may include internal retrieval, customer interaction, or workflow recommendations that require verification. High impact may include employment, credit, insurance, health, access to essential services, safety, biometric data, legal rights, or autonomous action. Reclassify when the data, model, user group, geography, purpose, or connected action changes.

Vendor controls and procurement questions

Procurement is where many AI risks become difficult to reverse. Do not approve a tool because it has a familiar brand or a responsible AI webpage. Ask what role the supplier has, which model and version are used, where processing occurs, which subprocessors have access, whether prompts and outputs train a shared service, how retention works, how changes are communicated, and which logs can be exported. Ask whether the supplier supports EU and Polish language use, accessibility, human review, correction, incident cooperation, and an orderly exit.

• Purpose limitation, tenant separation, input and output ownership, training restrictions, retention, deletion, backups, and derived data.
• GDPR Article 28 terms where relevant, subprocessors, transfers, security measures, access controls, vulnerability handling, and breach notification.
• Model documentation, evaluation scope, limitations, known failure modes, bias and language testing, version changes, and rollback.
• Service levels, outage handling, incident cooperation, regulator cooperation, audit evidence, customer notice, and material change approval.
• Human review features, permissions for tools and agents, transaction limits, export formats, portability, transition assistance, and termination.

A contract cannot transfer every legal responsibility to the vendor. The supplier may control the base model, but the Polish company controls its purpose, data, prompts, user permissions, integrations, downstream decision, and customer communication. Include an approval gate for material model changes. A model update can change accuracy, bias, output style, data exposure, and the evidence supporting a prior assessment. Revalidate a high impact use after a material change instead of assuming the old approval remains valid.

Human oversight must work in practice

Article 14 oversight is a design problem, not a sentence in a procedure. The people assigned to oversee a system should understand its capabilities and limitations, have enough competence and authority, be able to interpret the output, and be able to disregard, reverse, interrupt, or stop it where appropriate. Design the interface to show source information, confidence limits where meaningful, uncertainty, known exclusions, and a clear escalation action.

Test oversight under realistic workload. Sample accepted and rejected recommendations. Measure whether reviewers notice errors, how often they override, whether overrides are concentrated in a particular language or group, and how long correction takes. Watch for queues that make a reviewer approve everything. If the business cannot afford a genuine review, reduce the system's authority or do not use it for that decision. Human presence is not a cure for an automated process that nobody can challenge.

Evidence, monitoring, and incident response

A defensible programme can reconstruct a material decision without collecting more personal data than necessary. Keep the use case approval, legal basis, risk classification, system and model version, prompt or input reference, retrieval source, output, action, reviewer, affected record, notice version, and corrective action. Protect logs with access controls and retention limits. Do not paste full sensitive conversations into an unrestricted ticket merely to prove that an incident happened.

Define an AI incident broadly. It can include a personal data breach, discriminatory result, fabricated customer advice, unsafe recommendation, prompt injection, data exfiltration, poisoned source, secret exposure, unauthorised agent action, misleading synthetic content, loss of audit records, model outage, or failed human escalation. Connect the AI process to the existing privacy, security, business continuity, and regulatory incident processes. Identify when UODO, KRiBSI, a sector authority, a customer, or a data subject may need to be involved.

Monitoring should cover both the model and the business process. Track accuracy, refusal and escalation patterns, drift, harmful output, privacy leakage, access anomalies, supplier availability, reviewer overrides, complaints, and changes in affected populations. Set thresholds before launch. A dashboard full of green availability figures does not show that an employment model is fair or that a customer can correct an error. Escalation thresholds should lead to a named person, a containment action, and a decision about whether the use can continue.

A practical Polish implementation roadmap

In the first 30 days, appoint an executive sponsor, AI governance lead, privacy contact, security contact, procurement owner, and business owners. Issue an interim rule for sensitive data, unapproved tools, prohibited practices, high impact decisions, and autonomous actions. Inventory uses across employees, products, suppliers, and customers. Identify the role of the company for each system. Create the legal register with binding rules, guidance, proposals, and effective dates. Escalate every unknown rather than giving it an optimistic low tier.

In days 31 to 60, approve the risk taxonomy and decision rights. Create a standard intake form, DPIA and AI impact review workflow, vendor questionnaire, acceptable use standard, AI literacy curriculum, and incident route. Prioritise employment, credit, health, safety, biometric, customer eligibility, and agent uses. Configure data minimisation, access, retention, logging, notices, human review, and rollback for the highest exposure systems. Update procurement templates and identify contracts that need renegotiation.

In days 61 to 90, test the operating model. Run accuracy, fairness, privacy, security, accessibility, Polish language, and edge case tests suited to each system. Sample human review and overrides. Run a supplier outage and prompt injection exercise. Test deletion and rights handling. Confirm that the business can stop an agent and restore a record. Report open high risks, overdue evidence, training coverage, incidents, correction time, and upcoming AI Act dates to leadership. Set quarterly reviews and a change gate for new models, data, prompts, integrations, and geographies.

KPIs that show more than activity

Measure coverage and effectiveness together. Coverage measures include the percentage of known uses inventoried, the percentage with an owner and risk tier, completed reviews for high impact uses, approved tool adoption, training by role, vendor evidence coverage, and material changes assessed before release. Effectiveness measures include error rates by relevant population and language, human review completion, meaningful override rate, correction time, complaints, privacy incidents, time to contain, rollback success, supplier response time, and unresolved high risks by age.

Common failure modes

• Waiting for a Polish regulator to publish every detail before controlling personal data, employment decisions, vendor access, and misleading outputs.
• Calling the AI Act a Polish law, or assuming that the Polish national act replaces the directly applicable EU regulation.
• Treating UODO guidance, a Commission FAQ, a voluntary standard, a code of practice, or a proposal as binding law without checking its status.
• Assuming that a delayed high risk date removes current GDPR, employment, consumer, security, contract, or sector obligations.
• Using consent or a disclaimer to cure excessive collection, an unfair purpose, weak security, an unlawful automated decision, or a discriminatory outcome.
• Calling a person human in the loop when that person lacks context, time, authority, training, or the ability to stop the result.
• Testing only average cases in English and ignoring Polish language quality, accessibility, protected groups, edge cases, and source data errors.
• Keeping unlimited prompts, outputs, embeddings, and telemetry, or forgetting that support logs and evaluation sets can contain personal data.
• Allowing an agent to send messages, change records, approve payments, or make account decisions with broad credentials and no transaction limits.
• Buying a governance platform that creates a second inventory instead of connecting with identity, procurement, privacy, security, HR, product, and incident systems.

Build versus buy

Buy mature commodity capabilities such as identity and access management, secure model gateways, asset discovery, training delivery, ticketing, evidence storage, vendor questionnaires, monitoring, and controlled logging. Configure those products to your retention, access, and incident requirements. Build or own the judgement heavy parts: the Polish and EU legal register, use case taxonomy, risk appetite, approval gate, DPIA and fundamental rights workflow, human oversight design, test thresholds, escalation rules, and executive reporting.

What can we do for you?

Magna Products helps Polish companies turn scattered AI experiments into controlled, useful operations. We can inventory your AI use cases, map EU AI Act, Polish, GDPR, employment, sector, and supplier considerations, design practical intake and approval workflows, review human oversight, strengthen procurement controls, build evidence and KPI reporting, and connect governance to the tools your teams already use. Talk with Magna Products to schedule a focused discovery workshop and leave with a prioritised 30, 60, and 90 day implementation backlog.