Polish AI harness. How to use AI lawfully and be able to prove it

Series · part 3 of 3: law, as of 23 October 2026

Author: Andrzej Okoński, Head of Software Development

An organisation that uses AI should be able to explain what it uses the system for, what data it entrusts to it and who is responsible for its use. A well-designed harness helps to translate these arrangements into permissions, workflows and evidence that controls have been carried out. The scope of obligations depends on the specific application and on the company’s role.

In the first part of the series, a salesperson prepared a draft offer with the help of AI. In the second, we checked whether such work preserves their agency and skills. Now imagine that a similar assistant ends up in the HR department and starts assessing job candidates. The chat window may look the same, but the effects of the system and its legal classification will be different.

That is why we start the conversation about compliance with a description of the task: what counts is whether a specific process is properly designed and used. Only then do we choose the tools that help to demonstrate it.

Describe the application and establish the organisation’s role

A short use case card is useful: the business purpose, the users, the people affected by decisions, the data sources, the permitted actions and the process owner. It should also state what the system must not do and when it must hand a matter over to a human.

In the offer example, AI prepares a draft based on the company’s documents. It is not given independent authority to agree a price deviation or to conclude a contract. Changing this scope requires a new assessment of the process. Similarly, giving the assistant access to candidates’ files and asking it to compare them means a new application that has to be classified.

A company may be a deployer of AI, a provider of a system or play several roles. In certain situations, described in Article 25 of the AI Act, including after a substantial modification of a high-risk system or a change of its intended purpose leading to such a classification, the obligations of a provider may pass to the organisation. That is why the scope of integrations and changes is worth analysing before deployment.

Roles related to the protection of personal data are established separately. The name “AI provider” does not automatically settle who is the data controller and on whose behalf the individual entities process the data. Contracts and documentation must describe the real flow of information and the responsibilities of those involved.

Check the risk and the current AI Act deadlines

The AI Act differentiates requirements according to applications. A tool that helps draft a letter requires a different analysis than a system that screens candidates or supports decisions on employment. The area of employment and workers management is listed in Annex III, although the exact classification takes into account the rules and exceptions laid down in the regulation.

As of the date this article was prepared, the changes introduced by the AI Omnibus, which entered into force on 27 July 2026, must be taken into account. The obligations for high-risk systems in Annex III are to apply from 2 December 2027, and the relevant provisions for high-risk systems related to products in Annex I from 2 August 2028. The exact date also depends on the transitional provisions applicable to a given system.

At the same time, according to the current AI Act timeline, the earlier prohibitions set out in Article 5 have applied since 2 February 2025, and the transparency provisions of Article 50 have, as a rule, applied since 2 August 2026. Postponing the deadlines for high risk does not defer data protection or other obligations that already apply.

In practice, it is worth keeping a schedule assigned to applications, with an owner for each item and a review date. A note saying “AI Act from August 2026” is too general to plan the acceptance of a specific solution.

Take into account the Polish act and inspections from 28 October

In Poland, the Act of 3 July 2026 on Artificial Intelligence Systems has been in force since 11 August 2026. Its provisions on inspections, complaints and fines apply from 28 October 2026. Supervision is exercised by the Commission for the Development and Security of Artificial Intelligence (KRiBSI), which may inspect companies and institutions that use AI in their business, including off-the-shelf tools bought on subscription.

The act also provides tools that make it possible to prepare without haste. As a rule, an inspection may start no earlier than 7 days after the notice has been delivered, and in its post-inspection recommendations the Commission sets a deadline of no less than 30 days for remedying irregularities. In a doubtful matter, an individual opinion can be requested: the fee is PLN 150, and the Commission has 30 days to respond, or 60 days in particularly complex cases. We described how to prepare a company in three steps in the post AI inspections and fines in Poland from 28 October from our series “AI under control”, and we have collected the deadlines and obligations on our page about the act.

Look after skills and transparency

Following the 2026 amendments, Article 4 requires providers and deployers of AI to take measures to support the development of the AI literacy of their staff and of other persons operating the systems on their behalf. The measures should take into account knowledge, experience and the context of use. The provision does not require any specific level of literacy to be guaranteed for each person.

A good way to achieve this is training on real tasks. The salesperson practises checking the price list and the recipient; the administrator recognises an incorrect data flow; the manager knows when to stop a pilot. It is worth keeping the programme, the materials and a record of the activities carried out, and assessing their usefulness in practice. We run such sessions as part of our AI training. TWIN:DESK also helps: the administrator sees new users’ progress in the walkthrough in the system.

Article 50 covers, among other things, informing people about direct interaction with AI, with the exceptions provided for, and certain obligations concerning content generated or modified by AI. This does not mean an identical obligation to label every company document. For example, the provision on texts published in the public interest provides for an exception linked to human editorial control and responsibility for the publication.

For deployment, this means establishing what the user sees, how they recognise the system’s proposal and who checks the material before publication. Such rules should be part of the process in which the content is created.

Protect wellbeing while respecting privacy

In the second part, we proposed conversations with employees and an assessment of their experience of work. When tools for such activities are chosen, voluntary feedback must be distinguished from automated inference of emotions.

In Article 5, the AI Act as a rule prohibits the use of AI to infer emotions in the workplace on the basis of biometric data, with exceptions for medical or safety reasons. A simple statement that the aim is wellbeing does not create a separate exception. A system that analyses an employee’s face or voice features therefore requires a particularly careful assessment before it is bought and launched.

Tools outside this prohibition may also intrude on privacy. We recommend collecting only the information needed to improve the organisation of work and clearly separating conversations about difficulties from individual assessment of productivity.

In Poland, the employer has an obligation to assess and document occupational risk and to inform employees about it. When introducing AI, it is worth also reviewing changes in workload and in the way work is done. The National Labour Inspectorate (PIP) points to technostress, algorithmic pressure and excessive monitoring as possible psychosocial risks.

Design the data path in line with the GDPR

If a task involves personal data, the purpose and legal basis of processing, the scope of information, access and the retention period must be defined. The principles of data minimisation and purpose limitation also apply to the content passed to the model. The European Data Protection Board also stresses the need to set retention periods and the way data is deleted.

In our example, the full correspondence with the client is not needed to prepare the structure of an offer. On the other hand, access to the documentation of a specific case should follow from the person’s permissions and the needs of the task. These arrangements must also be checked for logs, backups and service tickets.

For processing that may result in a high risk to the rights or freedoms of individuals, the controller carries out a data protection impact assessment, or DPIA, before it begins. Not every use of AI automatically requires a DPIA; what matters are the features of the specific process.

For external services, the recipients of the data, subcontractors and access from outside the European Economic Area must also be established. Any transfers require the appropriate protection conditions to be met. A data centre in Poland is only the beginning, because the entire processing chain counts. That is why, in SAIE Pantera, models can run even on servers without internet access.

Our PROXY:AI controls communication with models, applies access policies and masks personal data before a query reaches the model. Its settings follow from the rules adopted. We check the access rules in a dry-run mode and test the effectiveness of masking on examples from the client’s documents before they start working every day.

Ensure genuine human involvement

The GDPR provides protection against decisions based solely on automated processing that produce legal effects or similarly significantly affect a person; it also provides for certain exceptions and safeguards. That is why the process of assessing a candidate requires a separate analysis, even if there is an approval button in the interface.

For high-risk systems, Article 26 of the AI Act provides for assigning oversight to people who have the competence, training, authority and support. It also provides, among other things, for monitoring operation and for informing workers’ representatives and the workers affected by the use of the system in the workplace. When planning a deployment, these requirements must be linked to the date from which they apply.

We recommend a practical test: the overseeing person receives a wrong proposal and has to recognise it, reject it and refer it for clarification. The process must give them access to the sources and time for assessment. If quantitative targets force automatic clicking of approvals, the organisation should improve the way it works.

Link accountability with evidence in SAIE

Our CDF methodology brings order to the assessment of the application, accountability, the preparation of people and decisions on moving to the next stages. CDF Platform supports running this process and collecting documentation: the methodological principles define the necessary actions, and the software helps to manage them.

TWIN:DESK is the place where the user works with knowledge and assistants, and PROXY:AI acts as the gateway to models. During deployment, we link the CDF documentation with the settings of these tools and with permissions in the target systems. As a result, a record saying that sending requires approval corresponds to a working block, and we confirm its effectiveness with a test.

A useful evidence package includes a description of the application, the justification for its classification, a risk assessment, arrangements concerning data, test results, the decision to launch and a review plan. Its content is chosen to fit the process and the organisation’s obligations. A large part of the evidence is collected by PROXY:AI: it records model calls, costs and decision context in a log that cannot be altered and prepares evidence packages for the AI Act, DORA and NIS2, among others.

Logs should make it possible to reconstruct a significant event while observing appropriate rules on access and retention. It is also worth designating the people responsible for stopping the system, handling an incident and assessing whether there is an obligation to report it. There is no single universal deadline for reporting every AI problem to every authority.

Adopt criteria for launching a specific process

Before the production launch, the management board should receive answers to a few questions: which application it is approving, who its owner is, which obligations apply and how the safeguards have been tested. It should also know which issues remain open and whether they block the launch.

Throughout the series, we arrive at one practical task: combining technical capabilities with working conditions and accountability. A Polish AI harness makes sense when an organisation can show, on a specific process, how it protects data, supports people and controls the effects of the system. This is the kind of process we propose to start a SAIE deployment with.

Sources

• AI Act Service Desk: Article 25
• EDPB: Data controller or data processor
• AI Act Service Desk: Annex III
• European Commission: AI Omnibus enters into force
• AI Act Service Desk: AI Act implementation timeline
• Act of 3 July 2026 on Artificial Intelligence Systems, Journal of Laws 2026, item 1003 (in Polish)
• AI Act Service Desk: Article 4
• AI Act Service Desk: Article 50
• AI Act Service Desk: Article 5
• National Labour Inspectorate (PIP): occupational risk assessment (in Polish)
• National Labour Inspectorate (PIP): AI as a tool for change in health and safety at work (in Polish)
• EDPB: Data protection basics
• EDPB: Be compliant (DPIA and data protection by design)
• EDPB: International data transfers
• European Commission: Automated decision-making and individuals’ rights
• AI Act Service Desk: Article 26