Poland’s Act of 3 July 2026 on artificial intelligence systems has a staggered start. The Polish Electronic Legal Information System lists 11 August 2026 as the general entry into force. It separately records 28 July for Article 125(4), and 28 October for Articles 8–18 and Chapters 3–5, 8 and 9. Businesses checking what changed in October should begin with the provision relevant to their activity and read the published text. A date on the statute’s landing page is only one part of that check. Polish Electronic Legal Information System: Act on artificial intelligence systems
Keep the national law and EU rules in separate rows
Start a register with one row for each provision that may matter. Record whether the provision belongs to the Polish act, an implementing instrument or the EU AI Act. Then write down the role it applies to and the date it takes effect. Where one provision refers to another instrument, follow that reference before writing an internal instruction. This avoids treating a change to an oversight process as if it automatically moved a deadline under EU law.
There is a practical reason to use the official register rather than working from a saved announcement. The Polish entry links to both the act and related instruments. If a colleague quotes an article number, check which document they mean before carrying it into a supplier questionnaire. Keep the date on which you reviewed the source and a copy of the passage you relied on. That gives a future reviewer a way to see whether a change reflects new law, corrected interpretation or a different use of the system.
Inventory uses instead of collecting product names
An inventory should explain what people actually do with a tool. A marketing team drafting text for human review and a team using the same vendor to rank job candidates have different objectives and potential consequences. A single row marked “AI platform” hides that difference. For each use, identify the business owner, intended purpose, users, data supplied, output recipients and who can act on the result. Where a tool can call another service or write to a record, note those permissions separately.
Include tools bought by individual departments, built internally or bundled into a larger service. Ask what the tool does when the reviewer is absent. A system that queues a recommendation for review behaves differently from one that applies it unless a person intervenes. Capture the current process as it operates, including fallback steps when the service fails. An accurate inventory can help a legal adviser assess obligations and help the business decide what can be changed if a use turns out to need tighter controls.
Ask vendors for evidence you can act on
Give suppliers a description of the use you are assessing. Ask for the current product documentation, the intended purpose and known limitations, how version changes are communicated, and what records can be exported if something goes wrong. Check which party can pause the system or reverse a result. If a supplier says a feature is appropriate for a regulated task, ask for the document that supports that claim and make sure it applies to the version and configuration you will use.
Compare answers against what your organisation can do in practice. A promise of human review is weak if staff cannot inspect the source of a recommendation or if they have no time to challenge it. An incident contact is useful only if the team can find it and reach someone who can act. Keep a named internal owner for the follow-up. A procurement note should identify outstanding questions, the person responsible for them and the condition that must be met before deployment.
Work through a hypothetical SME example
Imagine a small service business in Poland considering an assistant that reads customer enquiries, identifies the issue and drafts a reply. In the pilot, the assistant only sees records the assigned employee can access. It does not send messages. The employee checks whether the draft cites the right customer and account, then decides whether to use it. Those choices are part of the system description a reviewer needs. If the business later connects the assistant to a billing tool, the relevant workflow changes even if the product name stays the same.
The company can record that change as a separate approval. It could begin by documenting which bills the system may read, whether it can change an amount and how it handles a disagreement between the customer record and the payment log. Then it can test an incorrect account number, a duplicate charge and an unavailable billing service. A person reviewing the pilot should be able to see both what the assistant proposed and what the application allowed. That distinction makes it easier to diagnose problems and update the controls.
Turn the October date into a review checklist
- List the AI uses currently operating and the changes already scheduled.
- Map each use to its legal role and relevant provisions with qualified advice where needed.
- Check the entry-into-force date for those specific provisions and record the official source.
- Collect vendor documentation and test whether employees can review or override outputs.
- Set a review trigger for new purposes, more sensitive data, broader access or a new model version.
This is an organisational checklist. A determination about a specific product or deployment requires the current legal text, details of the use and an assessment of the organisation’s role. Start with the official Polish record and the EU text, then confirm interpretations before using them to make a compliance decision. EUR-Lex: Regulation (EU) 2024/1689
