Key takeaways
- Your role decides your duties. A company using a tool it bought is normally a deployer, and commissioning a custom system for your own use can change that picture.
- Since 2 February 2025, deployers must take measures to ensure sufficient AI literacy among the staff who operate or use AI systems on their behalf.
- Most internal workflow automation is not high-risk. Employment uses are the exception that matters for services firms.
- GDPR Article 22 separately limits decisions based solely on automated processing, and a human approval step with real authority is the simplest way to stay outside that category.
- Keep decisions about people out of the first project, log inputs, outputs, approvals and overrides, and record that the people who use the system were trained. This article is general information, not legal advice.
Are you a deployer or a provider?
The EU AI Act (Regulation (EU) 2024/1689) sets different obligations for providers, who develop an AI system or have one developed and put it into service under their own name, and deployers, who use an AI system under their authority. A company using a tool it bought is normally a deployer.
Commissioning a custom system for your own use can change that picture, because putting a system into service under your own name is part of the provider definition. If your first project touches a high-risk area, confirm your role with counsel before the build starts.
What applies to almost every company?
Article 4 requires providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy among staff and other people operating or using AI systems on their behalf. It has applied since 2 February 2025.
The people who approve, correct or rely on an automated workflow should understand what it does, where it can be wrong and how to escalate. A short written guide and a walkthrough during review mode cover most internal workflows. Keep a record that the training happened.
When does internal automation become high-risk?
Annex III lists the uses treated as high-risk. For a services firm, the relevant entry is employment and workers' management. It covers AI used for recruitment or selection, and AI used to make decisions affecting terms of work, promotion or termination, to allocate tasks based on individual behaviour or personal traits, or to monitor and evaluate the performance and behaviour of workers. According to the implementation timeline published by the Future of Life Institute at artificialintelligenceact.eu, the high-risk requirements for Annex III systems apply from 2 December 2027. Check the current dates on EUR-Lex before planning around them, because the EU has already changed this timetable once.
| Workflow | Likely category | Why |
|---|---|---|
| Collecting and checking client onboarding documents | Not listed in Annex III | Concerns client paperwork, not decisions about people's employment |
| Drafting proposals or client reports for review | Not listed in Annex III | A person reviews the output before it is used |
| Routing incoming requests to the right team | Not listed in Annex III, if routing is by request type | Becomes relevant if routing depends on individual staff performance or traits |
| Screening CVs or ranking candidates | High-risk (Annex III, point 4(a)) | Recruitment and selection of people |
| Assigning work based on individual performance data | High-risk (Annex III, point 4(b)) | Task allocation based on individual behaviour or traits |
| Scoring staff productivity | High-risk (Annex III, point 4(b)) | Monitoring and evaluating the performance of workers |
Does GDPR still apply to automated decisions?
Separately from the AI Act, GDPR Article 22 gives people the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them, subject to specific exceptions. A human approval step with real authority to change the outcome is the simplest way to keep internal workflows outside that category.
Which design choices keep you on the safe side?
None of these replace legal advice, but they make any later review much easier.
- Keep decisions about people, such as hiring, allocation and evaluation, out of the first project.
- Put a person with real authority in front of any action that affects a client or an employee.
- Log inputs, outputs, approvals and overrides so decisions can be explained later.
- Write down the system's purpose, the data it uses and its known limits.
- Train the people who use the system and record that you did.
- Check your data processing agreements for every tool and model provider the workflow uses.
How should human oversight be designed?
For high-risk systems, Article 14 requires that the system can be effectively overseen by natural persons while it is in use. Most internal workflows are not high-risk, but the same principle is good engineering: review mode before autonomy, narrow permissions, visible escalation and an audit trail. Our article on human approval as infrastructure covers how this works in practice.
Frequently asked questions
Does the AI Act apply to a company outside the EU?
It can. The Act applies to providers placing AI systems on the EU market and to deployers located in the EU, and in some cases where the output of a system is used in the EU. Companies with EU operations or EU clients should check.
Is using ChatGPT or Copilot at work covered?
Using a general-purpose assistant makes your company a deployer of that system, so the AI literacy duty in Article 4 applies. It becomes high-risk only when it is used for one of the purposes listed in Annex III, such as evaluating staff.
Is this legal advice?
No. It summarises the public text of the regulation and the published implementation timeline as of the date shown. Confirm your obligations with qualified counsel.
Who owns the system after launch?
Someone has to watch errors, renew credentials, adapt to tool changes and handle new exception types. The handover plan names who operates the system, and managed operation and documented handover are both valid outcomes.
What happens when the system gets something wrong?
When a consequential action is uncertain the system creates a visible exception instead of guessing. A queue that waits is cheaper than an automated mistake nobody sees until a customer does.
What if we want to hand the system to our own team?
Ownership, credentials, code, data, documentation, hosting and support responsibility are written into the engagement, so the system keeps running in accounts you own if the relationship ends.
What do we keep on record once the system is live?
Log inputs, outputs, approvals and overrides so decisions can be explained later, and keep a record that the people who use the system were trained.
Sources
This article describes operating principles and public sources. It is not a client result. Build Records carry the basis for every Outproduce system claim.