How to approve an AI assistant for work in an organisation?

Why this question arises at all

AI assistants rarely enter an organisation by a single route. Employees use private accounts, departments buy licences on their own and office software receives new features in updates.

On 6 August 2026 UODO (the Polish data protection authority) published initial question lists on data protection in AI systems. According to the authority, the compliance question usually arises when the tool is already running and the decisions on data and the provider were taken earlier. The authority stresses that the lists are not a binding interpretation of the law and do not determine compliance with the GDPR. Version 0 is completed by organisations outside the profile of the lists for SMEs and for the public sector. The Extended Version is completed, among other cases, where special categories of data are involved or data are transferred outside the EEA. An assistant from a provider outside the EEA usually requires it.

The second source of difficulty is three regimes at once — the AI Act, the GDPR and the Act on the National Cybersecurity System (the KSC Act). The approval procedure has to be assembled from obligations that each of them already imposes.

What has to be established before a decision

An AI assistant is approved for a use, not for a brand

The same brand runs on an employee’s private account, in a consumer plan paid for by the company and in a business plan with an agreement. These are three different legal situations. A plan without a data processing agreement with the organisation does not allow the provider to be treated as its processor (Article 28(3) GDPR). Disclosing personal data to the provider would then require a separate legal basis (Article 6(1)).

The unit of decision is the use, that is, the tool used in a specific process. According to Version 0 of the UODO lists the assessment is carried out separately for each process, because a general assessment of the tool is not sufficient. An AI use register is best kept at the same level. The AI Act does not require it, but it makes it easier to show who uses the tool and for what. An entry covers the use, the process owner, the plan with its settings and the dates of the decision and the review.

The request for approval is best entrusted to the process owner, and the assessment to IT, information security and the DPO. The decision is best entrusted to a person designated by the management board. In an essential or important entity, however, the head of the entity decides on the rules for approving tools covered by the information security management system (Article 8d(1) of the KSC Act). The approval conditions determine the cheapest plan, because the administrative features needed are sometimes available only in more expensive ones.

What role the organisation has under the AI Act

An organisation using an AI system under its authority is a deployer (Article 3(4)). The exception covers personal non-professional activity. A provider is whoever develops a system or a general-purpose model or has it developed and places it on the market or puts the system into service under its own name or trademark (Article 3(3)). Buying a licence does not meet these criteria. The situation is different when the organisation builds its own assistant on someone else’s model and puts it into service under its own name, including for own use (Article 3(3) and (11)). As a provider it then informs users that they are interacting with AI, unless this is obvious (Article 50(1)). It also marks generated content in a machine-readable format, with exceptions including standard editing (Article 50(2)).

The deployer role currently carries three obligations relevant to an assistant. The first is measures to support the AI literacy of staff and other persons dealing with the operation and use of AI systems on the organisation’s behalf (Article 4). The provision states expressly that it does not require the organisation to guarantee any specific level of AI literacy of any individual. The second is refraining from prohibited practices (Article 5). Both obligations apply from 2 February 2025 (Article 113, third paragraph, point (a)). The exceptions are the new prohibitions concerning intimate content without consent and child sexual abuse material, which apply from 2 December 2026.

The third obligation concerns publication and applies from 2 August 2026 (Article 113, second paragraph). When the organisation publishes text generated or manipulated by an AI system with the purpose of informing the public on matters of public interest, it discloses that fact (Article 50(4), second subparagraph). The obligation does not apply where the content has undergone human review or editorial control and where a natural or legal person holds editorial responsibility for the publication. The same paragraph covers deep fake content.

The obligations in Article 26 concern deployers of high-risk AI systems. An AI assistant for drafting, summarising or translating is not such a system. It may become one when the organisation intends it for a purpose in Annex III (Article 6(2)).

Where an AI assistant stops being an assistant

A change of the intended purpose of an AI system by a deployer, including a general-purpose AI system, is governed by Article 25(1)(c). If after that change the system becomes high-risk in accordance with Article 6, the organisation is considered its provider. It is then subject to the provider’s obligations under Article 16. A full analysis of the change of role is given in When does an organisation using AI become the provider of a system?.

The HR uses in Annex III, point 4, lie closest to that line. The first group covers the recruitment or selection of persons, in particular targeted job advertisements, analysing and filtering job applications and evaluating candidates (point (a)). The second covers decisions affecting terms of work-related relationships and decisions on the promotion or termination of work-related contractual relationships (point (b)). The same point lists allocating tasks based on individual behaviour or personal traits or characteristics. It also lists monitoring and evaluating the performance and behaviour of persons in such relationships. An organisation that intends the assistant for ranking candidates or evaluating a team’s annual performance enters these areas.

In certain cases a system in Annex III is not considered high-risk (Article 6(3)). However, a system in Annex III that performs profiling of natural persons is always high-risk (Article 6(3), third subparagraph). The obligations in Chapter III Sections 1–3 (including Articles 25 and 26) apply to Annex III systems from 2 December 2027 (Article 113, third paragraph, point (c)).

Regardless of that date, the GDPR applies and the AI Act in principle does not affect it (Article 2(7)). A data subject has the right not to be subject to a decision based solely on automated processing which produces legal effects concerning them or similarly significantly affects them (Article 22(1)). The exceptions require necessity for a contract, authorisation by law or explicit consent, together with measures to safeguard the data subject’s rights (Article 22(2) and (3)). A ranking checked by a recruiter might not be a decision based solely on automated processing. The condition is a genuine assessment of each application with the possibility of changing the result. According to the UODO lists the person checking should be able to change the result on the basis of their own assessment rather than merely approve it. Such a use still requires a legal basis for processing and information for candidates.

I therefore recommend writing into the rules a ban on using the assistant for Annex III purposes without a separate analysis. The rule limits the risk of a change of role and the risk under Article 22 GDPR. The prohibition in Article 5(1) (first subparagraph, point (f)) covers inferring the emotions of a natural person in the workplace, and recital 44 links it to biometric data. Outside medical or safety reasons, features inferring emotions from such data must therefore be switched off.

Legal basis and the provider’s own purposes

Entering personal data into an assistant is processing by the organisation. It needs a legal basis under Article 6(1) and, for special categories of data, also a condition under Article 9(2). Data are to be collected for specified purposes and limited to what is necessary (Article 5(1)(b) and (c)). According to Version 0 of the UODO lists the conditions of lawfulness are established before processing starts. The authority counts among them the legal basis, the processing agreement, the basis for transfers outside the EEA and the information obligation. According to the authority no decision to deploy is taken until they have been met.

When employees enter data of clients, employees or business partners into the assistant, the provider usually processes them on behalf of the organisation (Article 4(8)). The organisation may then use only processors providing sufficient guarantees (Article 28(1)). A contract or other legal act under Article 28(3) is needed in writing, including in electronic form (Article 28(9)). According to the UODO lists such an agreement is mandatory when the provider processes data on behalf of the organisation. It is worth keeping the version of the terms with the date of acceptance and the list of other processors.

However, the provider may reserve the use of data for its own purposes such as training models. According to the UODO lists the consequences under Article 28(10) and possible joint controllership (Article 26) must then be verified. To that extent the provider does not act on behalf of the organisation, and disclosing data to it requires a separate legal basis (Article 6(1)). For data entrusted to the organisation, disclosing them for the provider’s own purposes requires documented instructions from the controller (Article 28(3)(a) and Article 29) and a legal basis on the controller’s side (Article 6(1)). It is therefore worth switching off training on the organisation’s data and listing the provider’s other own purposes from the terms.

Transfers and information for data subjects

If data go to a third country, the transfer must meet the conditions of Chapter V (Article 44). The basis may be a Commission decision on an adequate level of protection (Article 45(1)). It may also be appropriate safeguards such as standard data protection clauses, on condition that enforceable data subject rights and effective legal remedies are available (Article 46). For transfers based on Article 46 the Extended Version of the UODO lists indicates that a transfer impact assessment is required.

Privacy notices list the recipients or categories of recipients and the intention to transfer data to a third country (Article 13(1)(e) and (f) and Article 14(1)(e) and (f)). The UODO lists also ask how data subjects will be informed about the use of AI. The provisions expressly require meaningful information about the logic involved in decisions under Article 22(1) and (4) (Article 13(2)(f) and Article 14(2)(g)).

Data protection impact assessment

An impact assessment is carried out before processing starts where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons (Article 35(1)). The provision requires this to be assessed taking into account the nature, scope, context and purposes of the processing. According to the UODO lists an impact assessment is required in cases including systematic evaluation of persons and innovative technology (with a reference to the list of the President of UODO). The case in Article 35(3)(a) arises where a systematic and extensive automated evaluation of employees or candidates is the basis for decisions with legal or similarly significant effects. I therefore recommend carrying out an impact assessment or recording why it is not required.

Client data and trade secrets

An organisation is sometimes a processor of its clients’ data. Entering those data into an assistant then means engaging another processor. That requires the prior specific or general written authorisation of the controller, that is, the client (Article 28(2)). With general authorisation the organisation informs the client of the intended addition of the provider and the client may object. A decision to approve the tool within the organisation does not replace that authorisation. The organisation imposes on the provider by contract the same data protection obligations it has towards the client. It remains fully liable to the client for the provider’s performance of those obligations (Article 28(4)). The same arrangement arises in a group of companies when the parent company buys the licence and manages the environment of its subsidiaries. It is then sometimes their processor and needs a data processing agreement and their authorisation for another processor.

The second limit does not follow from the GDPR. Calculations, source code or contract terms may be trade secrets even when they contain no personal data. The Polish Act on Combating Unfair Competition covers information of economic value that is not generally known to persons normally dealing with such information or not readily accessible to them. A further condition is that the entitled person has taken steps with due diligence to keep it confidential (Article 11(2)). Rules setting out what must not be entered into the assistant are among such steps.

Settings that determine the scope of data

The controller implements measures to ensure that by default only personal data necessary for each specific purpose are processed (Article 25(2)). The obligation applies to the amount of data, the extent of processing, the period of storage and accessibility. Security measures are to be appropriate to the risk (Article 32(1)). For an assistant this translates into six decisions recorded before a licence is issued.

1. Training models on the organisation’s content — switched off.
2. Retention of chat history and attached files — defined, and where the plan does not allow it, replaced by an in-house deletion procedure or a change of plan (Article 5(1)(e)).
3. Connectors, plug-ins, browser extensions and agent mode — switched off until a separate decision. This also covers permissions granted to applications to access the organisation’s data.
4. Memory across chats and public sharing of chats — switched off unless the use requires them.
5. Sign-in only through the company identity system with multi-factor authentication and, when an employee leaves, revocation of sessions and access keys and takeover or deletion of the history.
6. An event log for the administrator and the ability to search for and delete chats.

An AI assistant in an office suite usually works within the user’s permissions. Before switching it on, it is therefore worth cleaning up excessive file sharing, because the assistant may quote the content of shared files in its answers. Settings are worth checking periodically and after every change of features or terms, because new features are sometimes enabled by default. According to Version 0 of the UODO lists a model update by the provider, an extension of the scope of data or a new use requires a new assessment.

What the KSC Act adds

An essential or important entity implements an information security management system in the information system used in processes affecting the provision of its service (Article 8(1)). When the assistant touches such processes, the system covers it like any ICT service. The starting point is risk assessment (Article 8(1)(1)). The closest areas are security in the acquisition and operation of the system (point 2(b)), the ICT supply chain (point (e)) and asset management (point (m)). Access control policies (point (n)) and staff education (point (i)) are added to these. For the supply chain the entity takes into account, among other things, vulnerabilities specific to the supplier and the overall quality of its ICT services (Article 8(2)). The supplier assessment method is described in How to manage supplier risk under NIS2?.

Entities meeting the criteria on the date the amending act entered into force perform these obligations within 12 months (Article 33(1) of the amending act). The amending act was published on 2 March 2026 and entered into force one month after publication (Article 49), so by calculation the deadline expires on 3 April 2027. A former operator of essential services applies the existing system until the new one is implemented (Article 33(6) of the amending act). An entity that meets the criteria later has 12 months from the date of meeting them (Article 16). Important entities that are public entities and the entities of the higher education and science system indicated in Article 8(3) apply Annex 4 to the Act instead of Article 8(1). For them the system covers information systems controlled by the entity.

Rules and briefing before access is granted

A person acting under the authority of the controller processes data only on its instructions, unless required to do so by Union or Member State law (Article 29 GDPR). The controller takes steps to ensure this (Article 32(4)). When choosing measures under Article 4 of the AI Act the context of use of the system and the persons on whom it is used are taken into account. According to Version 0 of the UODO lists training and policies may be developed in parallel with deployment, provided that the risk remains under control in the meantime. A general-purpose AI assistant processes what the user enters, so the risk depends on that. I therefore recommend that the rules apply before the first sign-in. The rules settle five matters.

1. Permitted tools and uses, a ban on working on private accounts and the purposes excluded without a separate analysis, including those in Annex III.
2. Information excluded from input according to the information classification in force, with a separate point on data entrusted by clients and on trade secrets.
3. Checking the output before use, especially figures, legal provisions and quotations.
4. Disclosure under Article 50(4) for texts published on matters of public interest and for deep fake content.
5. Reporting events to the breach and incident procedure.

According to Version 0 of the UODO lists entering data into a tool not approved in the organisation may already be a breach. The controller documents any personal data breach (Article 33(5) GDPR). It notifies the breach to the supervisory authority without undue delay and where feasible within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons (Article 33(1)). For data entrusted to it the organisation notifies the breach to the controller (Article 33(2)). In an essential or important entity the same event may also be an incident requiring handling (Article 11(1)(1) of the KSC Act). Bans and obligations for users are best introduced by instruction, internal order or work regulations, and for contractors outside an employment relationship by contract. Reviewing employees’ chat history requires a separate assessment under employment law. I recommend linking the issue of a licence to confirmation of the briefing. The choice of measures for different roles is described in What does the AI literacy obligation require?.

Summary of approval conditions

The GDPR obligations apply from 25 May 2018 (Article 99(2)), and whether they must be performed depends on whether personal data go into the tool.

Condition — from when	Basis	Exceptions and limitations
Legal basis and purpose limitation	Article 5(1)(b) and (c), Article 6(1) and Article 9(2) GDPR	a condition under Article 9(2) only for special categories of data
Agreement with the provider in writing, including in electronic form	Article 28(1), (3) and (9) GDPR	where the provider processes data on behalf of the organisation; for data entrusted to the organisation also the controller’s authorisation (Article 28(2))
Provider’s own purposes listed and assessed	Article 6(1) and Article 28(10) GDPR; Article 26 for joint controllership	for data entrusted to the organisation — documented instructions from the controller (Article 28(3)(a) and Article 29) and a legal basis on the controller’s side; for own data — a legal basis
Basis for transfers outside the EEA	Articles 44–46 GDPR	only where data go to a third country
Information for data subjects	Article 13(1)(e) and (f) and Article 14(1)(e) and (f) GDPR	information about the logic involved — for decisions under Article 22 (Article 13(2)(f) and Article 14(2)(g))
Settings, sign-in, event log	Article 5(1)(e), Article 25(2) and Article 32(1) GDPR	the scope depends on the plan and the version of the tool
Impact assessment or a record of why it is not required	Article 35(1) and (3) GDPR	the impact assessment itself — where a high risk is likely
Update of the records of processing activities	Article 30(1) and (2) GDPR	record of categories of processing activities under Article 30(2) — for data entrusted to the organisation; the exemption in Article 30(5) concerns entities employing fewer than 250 persons and does not cover, among other cases, processing that is not occasional
Scope of use without prohibited practices — from 2 February 2025	Article 5 AI Act	paragraph 1, first subparagraph, points (ba) and (bb) and paragraphs 1a and 1b — from 2 December 2026; exceptions in individual points
Annex III purposes excluded without a separate analysis	Article 6(2) and Article 25(1)(c) AI Act; Article 22 GDPR	obligations of the provider of a high-risk system from 2 December 2027; Article 22 GDPR applies regardless of that date
Rules and briefing — Article 4 from 2 February 2025	Article 4 AI Act; Article 29 and Article 32(4) GDPR	Article 4 does not require guaranteeing a specific level of AI literacy
Disclosure of texts on matters of public interest and deep fakes — from 2 August 2026	Article 50(4) AI Act	does not apply to text after human review or editorial control where someone holds editorial responsibility
Tool in the information security management system — by calculation by 3 April 2027	Article 8(1)(1) and Article 8(1)(2)(b), (e), (i), (m) and (n) and Article 8(2) and (3) of the KSC Act	essential or important entity; scope under Article 8(1) or Annex 4; where the criteria are met later — 12 months (Article 16); former operator of essential services — the existing system until the new one is implemented

Common mistakes

• A brand ban instead of conditions. The rule “we do not use chat X” stops working on the day the first licence is bought. Nor does it cover AI features in software the organisation already uses.
• Removing names as an approval condition. Personal data also relate to an identifiable person (Article 4(1) GDPR). A document without names often makes it possible to establish who it is about. It does not lose its character as a trade secret either.

Conclusions and next steps

Fewer tools mean fewer conditions to maintain.

1. Make an inventory of the assistants already in use, including on private accounts and in office software. Set a deadline for moving to company accounts and assess with users whether a breach has occurred on private accounts.
2. Describe the uses and categories of data and involve the DPO in the assessment.
3. Assess the provider and choose a plan that meets the approval conditions.
4. Establish the legal basis for processing and the provider’s own purposes. Conclude a data processing agreement and, for data entrusted to the organisation, obtain the authorisation of their controller. Establish the basis for transfers, update privacy notices and assess the need for an impact assessment.
5. Configure the tool, clean up file permissions and switch on the event log. An essential or important entity covers the tool with its information security management system to the extent set by the KSC Act.
6. Adopt the rules, carry out the briefing and start with a pilot group without data entrusted by clients.
7. Update the record of processing activities and, for data entrusted to the organisation, also the record of categories of processing activities. Enter the use in the AI use register and set a review date.

Related materials

• What should an AI use register contain? — the fields of the entry that receives the approval decision.
• Is the AI tool we use a high-risk system? — classification when a use comes close to Annex III.
• Who is responsible for AI Act transparency obligations? — Article 50 in full.
• What must a personal data processing agreement contain? — the terms of the agreement with a provider that processes data on behalf of the organisation.

Sources

• Regulation (EU) 2024/1689 of the European Parliament and of the Council (Artificial Intelligence Act), consolidated version of 27 July 2026 — Article 2(7), Article 3(3), (4) and (11), Article 4, Article 5, Article 6(2) and (3), Article 16, Article 25(1), Article 26, Article 50(1), (2) and (4), Article 113 and Annex III, point 4, and recital 44 of the published text — consolidated text (eur-lex.europa.eu), text as published (eur-lex.europa.eu).
• Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR) — Article 4(1) and (8), Article 5(1)(b), (c) and (e), Article 6(1), Article 9(2), Article 13, Article 14, Article 22, Article 25(2), Article 26, Article 28, Article 29, Article 30, Article 32, Article 33(1), (2) and (5), Article 35(1) and (3), Articles 44–46 and Article 99(2) — eur-lex.europa.eu.
• Act of 5 July 2018 on the National Cybersecurity System, consolidated text as at 18 August 2026 — Article 8(1)–(3), Article 8d(1), Article 11(1)(1), Article 16 and Annex 4 (in Polish) — isap.sejm.gov.pl.
• Act of 23 January 2026 amending the Act on the National Cybersecurity System and certain other acts (Journal of Laws 2026, item 252) — Article 33(1) and (6) and Article 49 (in Polish) — isap.sejm.gov.pl.
• Act of 16 April 1993 on Combating Unfair Competition (consolidated text, Journal of Laws 2026, item 85) — Article 11(2) (in Polish) — isap.sejm.gov.pl.
• Personal Data Protection Office (UODO), Initial question lists. Personal data protection in the context of artificial intelligence systems, 6 August 2026 — announcement, Version 0, Version for the public sector, Version for SMEs and Extended Version (in Polish) — uodo.gov.pl.