Thursday 11 June, the plenary chamber
On Thursday 11 June 2026, late in the afternoon, the Sejm passed the act on artificial intelligence systems — the Polish act implementing EU Regulation 2024/1689, commonly known as the AI Act. The result of the vote leaves no room for speculation: 421 members in favour, three against, eighteen abstentions. In a Polish parliament where an argument can turn on a comma in a preamble, such a majority tends to occur on budget-related legislation and resolutions of condolence. This time it concerned a regulation that within the next dozen or so months will change the way thousands of Polish companies and public authorities buy, deploy and account for technology.
The amendments adopted by the chamber — tabled by the Left — were legislative and tidying-up in nature. The deadline within which the Senate should adopt a resolution consenting to the appointment of the chair of the new supervisory authority was clarified, and the deadline for submitting a report on the implementation of the actions demanded by the authority in a warning issued to an entity before a sanction is imposed was extended from 14 to 21 days. The substance of the act remained untouched. The text now goes to the Senate — and there is nothing to suggest that the upper chamber intends to hold it up.
The road to that vote was longer than it should have been. The Council of Ministers adopted the bill on 31 March 2026 — almost two years after the AI Act entered into force and more than a year after the first prohibitions started to apply across the Union. Throughout that time Poland was a market on which the EU rules on artificial intelligence formally applied but there was nobody to enforce them. That convenient gap is now closing.
What was actually passed — and what this act does not do
Let us start with the thing least often understood in boardrooms: the Polish act on artificial intelligence systems does not create new substantive obligations for providers and users of AI. Those obligations already exist in Regulation 2024/1689, which — like any EU regulation — applies directly, without transposition. The prohibitions on unacceptable practices in Article 5 of the AI Act have applied since 2 February 2025. From the same date Article 4 applies — the requirement to ensure that staff working with AI systems have appropriate competence (so-called AI literacy). The obligations for high-risk systems under Annex III become applicable on 2 August 2026 — and that date does not stem from the Polish act, so no delay in the Senate will move it.
So what does the act do? Three things. First, it creates a market surveillance authority and equips it with procedures: proceedings, inspections, decisions, sanctions. Second, it builds a support infrastructure, headed by a regulatory sandbox. Third, it establishes the national contact point for relations with the European Commission and the European Artificial Intelligence Board. To put it graphically: the EU regulation wrote the highway code, and the Polish act has just set up the traffic police, installed the speed cameras and opened a driver training centre.
For a practitioner this means one thing: the argument "there is no Polish act yet, so we don't have to do anything", with which compliance departments were fobbed off for a year and a half, has just expired. The obligations have existed for a long time — from now on there is also somebody who will issue an administrative decision for failing to observe them.
KRiBSI — a regulator made up of four regulators
At the heart of the act is the Commission for the Development and Security of Artificial Intelligence — KRiBSI for short. It is the national market surveillance authority within the meaning of the AI Act and the single point of contact in relations with EU institutions. The chair is appointed by the Sejm with the Senate's consent for a five-year term, which is meant to ensure independence from the current political cycle. The Commission's leadership will include representatives of four existing regulators: the Office of Competition and Consumer Protection (UOKiK), the Polish Financial Supervision Authority (KNF), the National Broadcasting Council (KRRiT) and the Office of Electronic Communications (UKE).
That structure deserves a moment's attention, because it determines the character of the supervision to come. KRiBSI will not be learning the market from scratch — it enters the game with the know-how of four institutions that have spent years running inspections, imposing fines and both losing and winning disputes before the administrative courts. Anyone who has had occasion to watch UOKiK proceedings over infringements of collective consumer interests, or a KNF inspection at a financial institution, knows that these are not authorities intimidated by a large entity with a large law firm.
The Commission's remit will cover conducting administrative proceedings, issuing decisions, applying sanctions, coordinating supervision of AI systems and issuing authorisations for high-risk systems used in, among other areas, education, critical infrastructure, employment and migration management. The Commission will be able to examine solutions for compliance with the AI Act, demand that infringements be remedied and, in an extreme scenario, withdraw a system from the market. The warning-before-sanction mechanism, with the 21-day deadline for the remedial action report mentioned above, suggests that the legislature has opted for a "fix it first, pay later" model. That is good news for those who start work now, and no consolation whatsoever for those who ignore a warning.
Fines calculated as under GDPR — only higher
The architecture of the sanctions comes straight from the regulation and will be painfully familiar to anyone who remembers GDPR implementation. Using the prohibited practices in Article 5 — behavioural manipulation exploiting vulnerabilities, social scoring, mass scraping of facial images into facial recognition databases — carries a fine of up to EUR 35 million or 7% of worldwide annual turnover, whichever amount is higher (Article 99(3) of the AI Act). Infringements of the obligations relating to high-risk systems, general-purpose models and transparency requirements — up to EUR 15 million or 3% of turnover. Supplying the supervisory authority with information that is incorrect, incomplete or misleading — up to EUR 7.5 million or 1% of turnover.
By way of comparison: the upper ceiling for GDPR fines is EUR 20 million or 4% of turnover. The EU legislature has decided that the risks associated with artificial intelligence are priced higher than the risks associated with personal data — and from 2 August 2026 that pricing will have an enforcer in Poland. It is worth remembering here the lesson that the case law of Poland's data protection authority (UODO) and of the administrative courts has been repeating for years: the supervisory authority does not have to wait for harm to occur. Non-compliance in itself — no documentation, no oversight, no risk analysis — is enough to open proceedings. There is no reason to assume that KRiBSI will adopt a gentler philosophy than its four institutional parents.
The prohibitions have applied for a year — only impunity is ending
While we are at it, it is worth dispelling the myth that "the AI Act is only just arriving". The sharpest part of the regulation — the catalogue of prohibited practices in Article 5 — has applied since 2 February 2025, that is, for sixteen months. Prohibited practices include the use of subliminal and manipulative techniques that materially distort people's behaviour, exploiting vulnerabilities related to age or disability, social scoring leading to unjustified detrimental treatment, untargeted collection of facial images from the internet or CCTV to build recognition databases and — this concerns employers directly — emotion recognition in the workplace and in educational institutions, apart from narrow medical and safety exceptions. If someone in an organisation has been testing a tool that analyses employee "engagement" from facial expressions during video calls, they are not in a grey area. They are on the wrong side of Article 5 — and have been for over a year.
From the same date Article 4 applies, that is, the AI literacy requirement: providers and deployers must ensure that the people operating AI systems on their behalf have appropriate knowledge — proportionate to the context, their experience and the groups the systems affect. It is an obligation with a soft name and hard evidential consequences: in the event of an incident or an inspection, the organisation will have to demonstrate that the people taking AI-supported decisions understood what they were working with and where the tool's limitations lay. An attendance sheet from a "what is ChatGPT" session will not bear that weight; a competence programme tailored to roles will.
For sixteen months both provisions existed in Poland in a state of practical suspension: they applied, but there was no authority designated to enforce them. The act just passed puts an end to that. And that is the right frame in which to think about Thursday's vote — not "new obligations are coming", but "old obligations have just been given an address, a telephone number and inspection powers".
The most common classification error: "we only use it"
In the conversations we have with boards and IT departments, one sentence keeps coming back like a boomerang: "this doesn't apply to us, we don't produce anything — we only use it". It is a misunderstanding worth defusing before an inspection does it for you. The AI Act distinguishes the role of the provider and the deployer — and imposes obligations on both. A company that has bought a system for CV pre-screening, credit scoring, employee monitoring or leasing capacity assessment is the deployer of a high-risk system — obliged to use the system in accordance with the provider's instructions, to ensure human oversight by competent people, to monitor its operation, to keep logs and to report serious incidents.
There is a second threshold that a surprising number of organisations trip over: an employer using high-risk AI systems in relation to its employees is obliged to inform those employees and their representatives — including about the rules on which those systems operate. In practice this means having to inventory the HR tools that the personnel department has been buying on a SaaS model for the last three years, often without the knowledge of IT and without any legal assessment. Our experience from audits of shadow AI shows that a typical mid-sized organisation uses between a dozen and several dozen tools with an AI component, of which five have been formally deployed. The rest live in the shadows — on private accounts, on free plans, in browser plug-ins. We wrote about this at greater length in our analysis of shadow AI as the invisible employee — in the context of data leakage. From August that same shadow will also become a regulatory problem.
And finally, the subtlest trap of all: a deployer that substantially modifies a high-risk system or puts its own brand on it may be treated as a provider — with the full package of obligations: a quality management system, technical documentation, conformity assessment. The line between "we adapted the tool to our needs" and "we became a provider" can be thinner than the procurement department's intuition suggests.
Local government and public administration — the FRIA before August
For local government units and public bodies the act has a particular dimension. It is public administration that uses the systems Annex III to the AI Act classifies as high risk: tools supporting the award of benefits, the assessment of applications, traffic and critical infrastructure management, and systems used in education and in employment services. Public bodies deploying such systems are obliged to carry out a fundamental rights impact assessment — the FRIA (Article 27 of the AI Act) — before putting the system into use.
The EU legislature has provided a transitional period: high-risk systems put into use by public bodies before 2 August 2026 must achieve compliance by 2 August 2030 at the latest. That sounds comfortable — until you realise two things. First, the transitional period concerns systems already deployed, not the ones an authority plans to buy in the autumn; every new deployment after 2 August enters the full regime from day one. Second, in order to know which systems benefit from the transitional period, you first have to know which systems you have — and an inventory of AI tools in public authorities, from what we observe, barely exists. Chatbots on municipal websites, automatic transcriptions of council sessions, document anonymisation tools, AI modules in electronic document management systems — all of these are in operation, but they rarely appear in any register.
Local authorities also have two other waves of obligations fresh in their memory: registration in the list of essential and important entities following the amendment of the Polish NIS-2 implementing act (the KSC Act), and the unrelenting inspection activity of the President of UODO. The AI act does not replace either of those regimes — it adds a third, with its own authority, its own fines and its own documentation.
The regulatory sandbox — what Article 91 really offers
The act provides for the launch of a regulatory sandbox — a controlled environment in which a company can develop, test and evaluate an AI system under the regulator's eye before bringing it to market. Under the AI Act, at least one sandbox must be operating in every Member State by 2 August 2026, so the timetable here is exceptionally tight: only a few weeks will remain between the President's signature and the EU deadline.
It is worth understanding what a sandbox offers and what it does not. Under the proposed Article 91(3), participation exempts a company from three specific obligations: maintaining a quality management system, preparing conformity documentation and record-keeping (logs) — for the duration of the tests and within the scope covered by the sandbox plan. It does not, however, exempt anyone from liability for harm caused to test participants, or from observing the prohibitions in Article 5. This is not a lawless zone — it is a training ground with an instructor. For Polish start-ups building high-risk systems, especially in medtech, fintech and HR tech, it is nonetheless a serious offer: the chance to test a product against the regulator's expectations before it meets them in administrative proceedings.
Three regimes, one organisation — the AI Act, GDPR, NIS-2
The most expensive mistake an organisation can make now is to treat the AI act as a separate project, run by a separate officer, in a separate binder. An AI system processing personal data is subject to the AI Act and GDPR at the same time — with a DPIA on the data protection side and a FRIA on the fundamental rights side, which partly overlap and which a sensible practitioner prepares together. An organisation that is an essential entity or an important entity within the meaning of the amended KSC Act must in turn take AI systems into account in its risk analysis and incident management — because an incident in an AI system supporting a critical process is an incident within the meaning of NIS-2, whatever the model provider may think about it. We have already written about the points where the two regulations meet in our article on what links the AI Act with information security — today that convergence stops being academic.
The good news is that the toolkit is ready. Organisations with an information security management system (ISMS) compliant with ISO/IEC 27001 already have 70% of the infrastructure needed for the AI Act: an asset register, risk analysis, supplier oversight, incident management, management reviews. The ISO/IEC 42001 standard — an artificial intelligence management system — was designed to overlay that structure rather than compete with it. The path of "extending the existing ISMS with an AI domain" is cheaper, faster and more credible in the regulator's eyes than building a parallel silo. It should also be borne in mind that the legal environment is still moving: the Digital Omnibus package, which we wrote about in the context of changes to data protection, may yet adjust some of the AI Act's deadlines and obligations at EU level. An adjustment to the calendar will not change the direction, however — and the supervisory authorities are being created here and now.
The calendar for the coming months
Let us try to put the dates in order, because they set the pace of the work. The act now goes to the Senate; once it has been adopted and signed by the President, the bulk of its provisions are to apply from August 2026, in parallel with the AI Act requirements for high-risk systems becoming fully applicable on 2 August 2026. The first regulatory sandbox should start on the same date. All of the act's provisions will come fully into force in 2027. KRiBSI has to be staffed — with the Sejm and Senate procedure for appointing its chair — before supervision becomes operational, which gives organisations several, perhaps a dozen or so, months of genuine breathing space.
That breathing space is easy to waste. Experience with GDPR in 2016–2018 and with NIS-2 in 2024–2026 teaches that organisations divide into those that used the time between enactment and enforcement to implement, and those that used it to wait. The difference showed at the first inspection — and it was the difference between adjusting procedures and a fine calculated on turnover. From the board's perspective one thing is decisive: responsibility for AI Act compliance cannot be delegated to the technology vendor. Just as a data processing agreement did not relieve the controller of responsibility for its sub-processors, a licence for an AI system will not relieve the deployer of the duty to oversee what the system does to its customers and employees.
A separate word is due to SMEs, because they are the ones who most often conclude from texts like this that "this isn't our league". The EU legislature has provided simplifications for small and medium-sized entities — preferential access to regulatory sandboxes, simplified technical documentation, fines moderated by the size of the undertaking — but it has not provided an exemption. An accountancy firm using an AI tool for preliminary assessment of clients' creditworthiness, an employment agency using automatic pre-selection of candidates, a private medical practice with an AI module in its clinic system — all of these entities carry out activities that Annex III classifies as high risk, regardless of headcount. The scale of the business affects the depth of implementation and the size of any fine, but not the existence of the obligation itself. Indeed, the smaller the organisation, the more important it is to achieve compliance by the cheapest available route — that is, by putting the actual state of affairs in order now, rather than rescuing it under the pressure of proceedings.
Why Fib.Code — AI governance without compliance theatre
At Fib.Code we have spent years building information security management and regulatory compliance systems for private companies, local authorities and public sector bodies — from ISO/IEC 27001 and 22301, through GDPR and NIS-2, to National Interoperability Framework (KRI) audits. The AI domain is not a new market for us to occupy with marketing, but a natural extension of the same craft: an inventory of assets, risk classification, documentation that reflects reality, and oversight that works even when nobody is watching. In implementing AI governance and AI Act compliance we use ISO/IEC 42001 as the skeleton and map the AI Act requirements onto controls the organisation already has — instead of selling it a second, parallel system.
We work to three principles. First — the facts before the documents: we start with a proper inventory of AI systems, including those in the shadows, because a policy written for a register that does not exist is waste paper. Second — proportionality: an SME with two SaaS tools does not need the same machinery as a bank with its own models; we match the scope to the actual risk and to the role in the chain (provider, deployer, importer). Third — personal responsibility: every project ends by identifying who in the organisation is responsible for what, because KRiBSI — like any regulator — will talk to people, not to binders.
The end product is not a file of policies but working governance: a register of AI systems with risk classification, FRIAs and DPIAs carried out where they are required, updated vendor contracts, staff trained to meet the AI literacy requirement, and oversight and incident response procedures plugged into the existing ISMS. In other words — a state in which a warning from the regulator ends with a 21-day report rather than sanction proceedings.
What to do about the AI act this weekend
There is no need to convene a crisis team — one decision and one meeting will do. The decision: appoint someone responsible for preparing the organisation for the AI Act, with a mandate from the board and a deadline for the first report. The meeting: on Monday, one hour, IT, HR, a lawyer or the DPO and a representative of the business, with a single agenda item — the inventory. Four questions are asked at that meeting. First: which tools with an AI component do we use — formally and informally, including whatever employees run on their own accounts? Second: do any of them touch high-risk areas — recruitment, employee evaluation, scoring, benefits, education, critical infrastructure? Third: in what role do we act in relation to each of them — do we buy, do we modify, or do we perhaps put our own brand on it? Fourth: who here meets the AI literacy requirement, and what will we document it with?
The answers to those four questions — set down even in a spreadsheet — are the foundation of everything that follows: classification, the FRIA, contract updates, training. An organisation that does this in June enters August with a map. An organisation that puts it off until "after the holidays" will enter the inspection season with a blank space where KRiBSI will expect a register.
Get in touch: l.grabowski@fibcode.com | fibcode.com/en/contact. Directly related material: The AI Act and information security — how the new regulations intersect, Shadow AI — the invisible employee taking data out of the company, The Digital Omnibus and GDPR 2.0 — what is changing in data protection — three texts that complete the picture of the regulatory landscape in which the AI act is the newest, but not the last, element.
