Before anyone asks you about compliance, you need an answer to two questions: which of our tools are AI systems, and are we the provider or the deployer of each. A register answers both, and it decides how much work everything after it will cost.
dfzoo AI Institute builds AI system registers and risk classifications for organizations operating in Poland, including foreign groups with a Polish entity. The national instrument is the Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003), in force since 11 August 2026 except for Articles 8-18 and Chapters 3-5, 8 and 9, which apply from 28 October 2026 and carry the inspection regime and the penalties. Market surveillance and the single point of contact sit with the Commission for the Development and Security of Artificial Intelligence. We do the engineering half of this work: we find AI systems including the ones embedded in software you bought, describe each one in a register with a written classification rationale, and wire the register into the processes that keep it current. The legal qualification and the signature on it stay with counsel.
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 are the exception: they apply from 28 October 2026. The split matters in practice, because the second 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 is to be appointed in October 2026 and the Commission is to start work in November 2026.
The Act also provides for regulatory sandboxes, free of charge for small and medium-sized enterprises.
| Date | What changes | What it means in practice |
|---|---|---|
| 27 July 2026 | Publication in the Journal of Laws (item 1003) | The text is public and can be worked from |
| 11 August 2026 | The Act enters into force, except the listed provisions | The national framework applies, the authority exists |
| October 2026 | Chair of the Commission appointed | There is an addressee for filings and questions |
| 28 October 2026 | Articles 8-18 and Chapters 3-5, 8 and 9 enter into force | The inspection regime and the penalty provisions start to operate |
| November 2026 | The Commission starts work | Market surveillance becomes operational |
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, how much autonomy it has, whether it adapts after deployment, and whether its outputs influence the environment, including decisions about people.
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.
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.
| Register field | Why it is there |
|---|---|
| Name and business owner | Someone is accountable for the entry and for keeping it current |
| Intended purpose | Risk class follows the purpose, not the technology |
| Input data and its source | The basis for assessing impact on people and data requirements |
| Model and vendor, with version | Without the version the assessment cannot be reproduced |
| Your role: provider or deployer | The duty set follows the role |
| Risk class and rationale | A class without a rationale cannot be defended |
| Human oversight: who, and at which point | Separates a stated control from a working one |
| Entry date, review date, person | Shows the register is alive rather than written once for an audit |
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
Every system is described across the full field set, with a role and a risk class assigned together with a rationale grounded in facts.
We separate what the facts settle from what needs interpretation, draft the questions and work through them with your counsel or our legal partner.
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.
We diff the register against reality: new applications in SSO, vendor updates, model changes. Differences are explained and added.
Article 4 has applied since 2 February 2025 and was not postponed. Role-to-competence mapping, a programme per role, and the records that let you evidence the obligation on demand.
High-risk deadlines moved, the Article 50 transparency duties did not. What has to be disclosed, where in the interface, and how to verify the marking survived publication.
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.
Tell us where you are with your AI system register and classification. We respond within one business day.