What may employees enter into an AI tool at work?

In brief

At work, you should enter into an AI tool only information that is needed for the task, allowed for that tool, and safe for the organisation to process through that tool. Do not enter personal data, customer or employee details, confidential material, credentials, or unpublished decisions unless the organisation has separately approved that use and the data protection conditions are in place. The AI Act (EU) 2024/1689 Article 4 makes AI literacy a workplace issue, because staff need enough understanding for the context in which AI is used. The General Data Protection Regulation (EU) 2016/679 Article 5 adds the core rule for personal data: the controller must follow the data protection principles and be able to show that it has done so.

What makes an input a risk at work?

An AI tool does not only store words like a notebook. Under the AI Act Article 3, an AI system receives input and infers how to produce outputs, such as content, recommendations or decisions. In plain language, the prompt and the attached document can shape what the tool produces next.

That matters in daily work. A short prompt can contain a customer name, an employee dispute, a tender plan or a system detail. A file can contain much more than the employee intended to share. The risk is not only the visible question. The risk is also what the tool provider may process, what the output may reveal, and whether the output is then used in a real decision.

The AI Act Article 3 also defines risk through the likelihood and severity of harm. For work use, that means a harmless-looking input becomes risky when a mistake or disclosure could harm a person, the organisation or a process. A public marketing sentence is different from an employee warning letter. A generic policy question is different from a customer complaint with names and case history.

Three questions help classify the input before it goes into a tool:

• Is a person identifiable from the text, file or context?
• Is the information meant only for the organisation or a limited group?
• Would the organisation be able to explain the purpose, necessity and security of this processing later?

If the answer to any of these is uncertain, the input needs more care before it is used.

What information can usually be entered into AI?

The safest inputs are generic, public and stripped of details that identify people or reveal internal matters. The work task can still be real. The data does not need to be.

For example, an employee can ask for a clearer structure for a public web page text. A manager can ask for a meeting agenda template without naming the people or the dispute behind the meeting. A specialist can ask for a plain-language explanation of a public rule. A project team can ask for alternative wording for a generic paragraph, after removing customer names, employee names and case details.

A practical classification looks like this:

Input type	Usually safer use	Warning sign
Public information	Summarising a published instruction or drafting a public text	The prompt adds non-public background
Generic work text	Improving tone, structure or clarity	The text includes names, case numbers or internal decisions
Fictional examples	Testing a process with made-up data	The example is copied from a real case too closely
Aggregated points	Finding themes in non-identifying notes	A small group makes people easy to recognise
Internal confidential material	Not for general AI use without approval	Tender, strategy, source code, credentials or unpublished decisions

The AI Act Article 3 uses the idea of intended purpose. In everyday terms, a tool is not approved for every possible task just because it can answer a prompt. A tool used for drafting public text may not be approved for analysing employee cases or customer records. The input must match the approved use.

When is personal data a special warning sign?

Personal data deserves special care because the General Data Protection Regulation Article 5 sets principles for its processing. These principles include lawful, fair and transparent processing, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality. Article 5 also says the controller is responsible for compliance and must be able to demonstrate it.

In workplace terms, this means convenience is not enough. It is not enough that an AI tool would make a task faster. The organisation needs a permitted purpose for the processing. It must use only the personal data that is necessary for that purpose. It must protect the data. It must also be able to show afterwards why the processing was appropriate.

A name in a document is a warning sign. So are an email address, a phone number, a customer number, a personnel number, a detailed job role in a small team, or a combination of facts that points to one person. Even if the employee does not type a name, the context can identify someone.

The data minimisation principle is especially important. If the task is to improve the wording of a reply, the AI tool usually does not need the customer name. If the task is to create a meeting agenda, the tool usually does not need the employee’s case history. If the task is to explain a concept, the tool usually does not need any real personal data at all.

The accuracy principle also matters after the output is produced. If an AI-generated text states facts about a person, those facts need checking before use. A fluent answer is not the same as a verified answer.

For a broader staff training view on this topic, see What data protection skills does every employee need?.

When is the AI tool provider a processor of personal data?

If an AI tool provider processes personal data on behalf of the organisation, the General Data Protection Regulation Article 28 becomes central. The organisation may use only processors that provide sufficient guarantees for appropriate technical and organisational measures. The point is practical: the organisation remains accountable for choosing a suitable service when personal data is processed for it.

Article 28 also requires a contract or other legal act between the controller and the processor. That arrangement must set out matters such as the subject and duration of processing, the nature and purpose of processing, the type of personal data, the categories of data subjects, and the rights and duties of the controller.

For daily AI use, the most important processor questions are plain:

• Does the provider process personal data only on documented instructions from the organisation?
• Are people authorised to process the data bound by confidentiality or a legal confidentiality duty?
• Are the required security measures in place?
• Can the provider use sub-processors only under the conditions in Article 28?
• Will the provider delete or return the personal data when the service ends, unless law requires storage?
• Can the organisation obtain the information needed to show compliance?

If these questions have not been answered, employees should not treat the tool as a safe place for personal data. Approval of the tool is not the same thing as approval of every input.

Why AI literacy belongs to every user

The AI Act Article 4 requires providers and deployers of AI systems to take measures to support the development of AI literacy of their staff and of others who deal with AI system operation and use on their behalf. That is the wording of Regulation (EU) 2026/1744, in force since 27 July 2026; the 2024 text required ensuring, to their best extent, a sufficient level of AI literacy. The same article says the relevant technical knowledge, experience, education, use context, and the people or groups affected by the AI system must be taken into account.

This is why AI literacy is not only a topic for information technology teams. A payroll specialist, teacher, HR manager, customer adviser and municipal case handler can all create risk with a single prompt. They do not need to build the AI system to affect its use. They need to understand what can be entered, what must be left out, and what must be checked before an output is used.

AI literacy also connects the AI Act and the General Data Protection Regulation. The AI Act explains why the user needs competence in the use context. The General Data Protection Regulation explains why personal data cannot be treated as ordinary text. Together, they point to a simple workplace rule: the person using the tool must understand both the task and the data.

For more on the Article 4 duty, see Article 4 of the AI Act: what your staff must know about AI. For roles and ownership, see Who is responsible for AI use in an organisation?.

What should not be entered into AI without separate approval?

Some information needs a clear internal approval before it is entered into an AI tool. This is true even when the tool is useful and even when the employee has good intentions.

Do not treat these as ordinary prompts without approval:

• Personal data about customers, residents, patients, pupils, employees, applicants or partners.
• Documents that include names, contact details, identifiers, case numbers or detailed personal history.
• Employment matters, performance notes, disciplinary material or recruitment comparisons.
• Unpublished decisions, draft authority decisions or internal legal assessments.
• Tender material, pricing plans, strategy, source code, credentials or security details.
• Confidential customer material or partner material received for a limited purpose.
• Large document sets where hidden metadata or attachments may contain personal data.

The reason is not that AI use is forbidden as such. The reason is that the organisation must know what is being processed, why it is needed, which tool is used, which provider terms apply, and whether the General Data Protection Regulation Article 5 and Article 28 requirements are met where personal data is involved.

A safer method is to use a reduced version of the task. Names can be replaced with roles. Real case facts can be changed into a fictional example. A document can be shortened to the sentence that needs language improvement. The less the tool receives, the less the organisation must justify.

What this answer does not resolve

This answer does not approve any specific AI tool. It also does not decide whether a particular provider is a processor in a particular contract. Those questions depend on the tool, the provider terms, the organisation’s instructions and the actual processing.

The AI Act Article 4 does not list exact prompt categories that are always allowed or always forbidden. It sets an AI literacy duty for providers and deployers. The General Data Protection Regulation Article 5 does not ban all use of personal data in AI tools. It requires the controller to comply with the data protection principles and to be able to demonstrate compliance. Article 28 adds conditions when a processor processes personal data on the controller’s behalf.

This answer also does not resolve confidentiality outside personal data. Business secrets, procurement rules, professional secrecy and sector-specific duties may create stricter limits. Those limits need the organisation’s own policy and legal review.

The practical conclusion remains clear. Public and generic inputs are usually the safer starting point. Personal data and confidential material need a documented reason, an approved tool and suitable controls before they are entered.