AI system register and risk classification in Poland: the Act of 3 July 2026 and the supervision calendar

Who this guide is written for.

• Companies that bought or built tools with AI features and have no single list of them
• Product teams whose AI feature was just challenged in a customer questionnaire
• Software houses and integrators that have to tell a client which role they are in
• Public bodies where staff adopted generative AI faster than internal rules were written
• Compliance leads, CISOs and CTOs who need an artifact to sign, not a presentation

What is in force and from when

The Act of 3 July 2026 on artificial intelligence systems was published on 27 July 2026 (Journal of Laws 2026 item 1003) and entered into force on 11 August 2026. Articles 8-18 and Chapters 3-5, 8 and 9 enter into force later, on 28 October 2026. The split matters in practice, because the later group carries the inspection regime and the penalty provisions.

Article 5(1)-(2) makes the Commission for the Development and Security of Artificial Intelligence the market surveillance authority within the meaning of Article 70(1) of Regulation (EU) 2024/1689, and the single point of contact. Its chair was appointed by the Sejm with the consent of the Senate, given on 24 September 2026, and the Commission is to start work in November 2026.

The Act also provides for regulatory sandboxes, and micro, small and medium-sized enterprises take part in them free of charge.

Is your tool an AI system

Nobody will arrive and tell you that a given system falls in scope. Every organization assesses that for itself, and the assessment has to be reproducible, because it is the first thing an inspector, a customer questionnaire or a due diligence process asks about.

We run the assessment on technical characteristics, not on how a vendor markets the product. What counts is whether the system infers from its inputs and how much autonomy it has. It also matters whether its outputs, such as recommendations or decisions about people, can influence physical or virtual environments. The definition lists adaptiveness after deployment as a possible feature, not a required one.

Most disputes appear where it is easy to say "that is just automation": scoring and ranking, prediction used to select cases for review, document classification, generated replies in support, candidate sorting. Publicly reported disputes over exactly this qualification show it is settled on technical facts, so the facts need to be written down before anyone asks.

• Hand-written rules and a model trained on data give two different answers, so you need to know what is actually inside the product
• A purchased system where the vendor added an AI feature in an update is your system for the purposes of deployer duties
• The same technology in two use cases can land in two risk classes, because intended purpose decides, not the algorithm
• An edge case is recorded as an edge case and sent to counsel, rather than quietly resolved in favour of the cheaper answer

How to run an inventory that holds up

An inventory run by sending a survey to teams produces a list of what people remember. We collect from four sources at once and compare them, because it is the gaps between the sources that show what is missing.

Below are the fields an entry needs in order to stand on its own, without the person who wrote it in the room.

• What you built: repositories, model API calls, services with an embedded model integration
• What you bought deliberately as an AI tool: contracts, invoices, data processing annexes
• What arrived quietly: AI features added by vendors in updates to software you already ran
• What people picked up themselves: applications visible in SSO sign-ins and in card spend

Provider or deployer

The role decides the duty set and is a more frequent source of confusion than the risk class itself. A company deploying a purchased system is normally a deployer, but can become a provider if it puts its own name or trademark on the system, modifies it substantially, or changes its intended purpose to one the original provider did not foresee.

We check this for every register entry and record it together with the facts it rests on. The final legal qualification is confirmed by counsel, because the list of duties you then have to perform follows from it.

Where this goes wrong, and what we do about it.

1. 1
   The register is born in a spreadsheet and dies within a quarter

   An inventory produced once for an audit or a customer questionnaire lands in a spreadsheet with no owner and no moment where someone has to update it. Systems move faster than the sheet: a vendor switches an AI feature on in an update, a team swaps in a newer model, someone buys a tool on a company card. Two quarters later the register describes a state that no longer exists, which is worse than having none, because it produces confidence with nothing behind it.

   What we do about it

   We wire the register into processes that happen anyway: buying a tool, deploying it, changing vendor and changing model each get a mandatory field pointing at the entry. Every entry carries a named owner. On top of that we set a quarterly review that diffs the register against the SSO application list and spend, and the differences become a list to explain.

   What stays with you: register with named owners, an update procedure wired into procurement and deployment, and a quarterly difference list
2. 2
   Classification without a rationale

   The risk class column has a value in it, but nothing records what the value was based on. The person who decided it has changed roles or employers. At the first question from an inspector, a customer or a buyer in due diligence, nobody can reconstruct the reasoning, so the whole classification is redone, this time under time pressure.

   What we do about it

   Every entry gets a rationale citing the provision and the specific facts about the system: intended purpose, data, autonomy, impact on people. We record the date and the person. Rationales are walked through with your counsel and the outcome of that review is stored next to the entry, not in somebody's mailbox.

   What stays with you: classification rationale per system, in a form ready for legal review and signature
3. 3
   AI embedded in a purchased tool stays outside the register

   The inventory asks teams what they built and never asks vendors what they added. AI features enter recruitment platforms, ticketing systems and CRMs through routine updates, with no decision on your side at all. Those are precisely where deployer duties sit, and they are absent from the register because nobody counted an update as adopting AI.

   What we do about it

   We send vendors a specific question about AI features in the version you run and about what they plan to add; the question template stays with you for reuse. In parallel we read changelogs and processing annexes and diff the SSO application list against the register. Answers and check dates are stored on the entries, so next time it is visible what is fresh and what needs asking again.

   What stays with you: vendor list with answers and dates, plus a reusable question template
4. 4
   Qualification decided by preference

   Calling a system plain automation is cheaper and faster, so the product description starts drifting towards the preferred answer. The problem is that qualification is judged on technical facts, and those live in the code, in the vendor contract and in what the system actually does with data. The gap between the description and the facts surfaces exactly when it costs the most.

   What we do about it

   We qualify on facts: what is in the code and the configuration, what data goes in, how much autonomy there is, and what happens to the output. The facts are recorded on the entry together with their source. Where facts do not settle it, the case is marked as contested and handed to counsel with the question already written, instead of being decided in-house.

   What stays with you: list of edge cases with the underlying facts and a question drafted for counsel
5. 5
   The calendar read as a single date

   "The Act came into force on 11 August" reads like the end of the story, so the work plan is built around that one date. Meanwhile the inspection regime and the penalty provisions apply from 28 October, and the authority becomes operational later still. The hardest part of the schedule ends up last, when there is no room left to move it.

   What we do about it

   We plan against both dates and against the point where the authority starts operating, with a list of what has to be ready before each. The schedule carries owners and statuses, so it shows what is done rather than what is intended. We walk it with you monthly until the end of the year.

   What stays with you: schedule split across both entry-into-force dates, with owners and status

What stays with you.

• AI system register with owner, intended purpose, data, model, vendor and version
• Classification rationale per system, ready for legal review
• Role determination, provider or deployer, per entry, with the facts behind it
• Register update procedure wired into procurement, deployment and vendor changes
• Vendor list with answers on AI features, plus a reusable question template
• List of edge cases with questions drafted for counsel
• Schedule split across 11 August and 28 October 2026

How we work.

1. 1
   1. Collection from four sources

   Repositories and model API calls, contracts and invoices, vendor changelogs, SSO sign-ins and spend. We compare the results, and the gaps between them set the rest of the work.

   Week 1
2. 2
   2. Register and first classification

   Every system is described across the full field set, with a role and a risk class assigned together with a rationale grounded in facts.

   Week 1-2
3. 3
   3. Edge cases and legal review

   We separate what the facts settle from what needs interpretation, draft the questions and work through them with your counsel or our legal partner.

   Week 2-3
4. 4
   4. Wiring in and handover

   The register gets owners and an update procedure, the deadline schedule goes to the people accountable for it, and we walk the whole pack through with leadership.

   Week 3-4
5. 5
   5. Quarterly review

   We diff the register against reality: new applications in SSO, vendor updates, model changes. Differences are explained and added.

   Quarterly

The rest of this cluster.

Where this turns into a service.

What this page is, and what it is not.

We are an engineering team, not a law firm. We build the register, collect the facts and prepare rationales in a form ready for review, but the legal qualification of a system and the assessment of duties are signed by counsel: yours, or our legal partner. Cases the facts do not settle are marked as contested rather than quietly resolved.

Where the dates and numbers come from.

• Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003), full text
• Polish Ministry of Digital Affairs on the AI systems act
• Regulation (EU) 2024/1689 (AI Act), consolidated text on EUR-Lex
• prawo.pl: the AI Act enters into force and public bodies do not know whether they use AI
• Polish Senate: 65th sitting, 24 September 2026, consent to the appointment of the chair of the Commission for the Development and Security of Artificial Intelligence
• European Commission: guidelines on the definition of an AI system under Regulation (EU) 2024/1689, C(2025) 5053 final