.png)
Third-Party Embedded AI Under the EU AI Act
- Art Richards, Berlin
- 1 day ago
- 7 min read
The EU AI Act can apply even if your company has never bought or selected a standalone AI product. AI is now built into document tools, meeting platforms, HR systems, CRM software, and other business applications. And given the speed of software improvement and SaaS deployment models, changes to these systems are happening more like daily than quarterly or yearly as in the past.
When staff use one of these AI features for work under the company's authority, the company generally becomes the deployer of that AI system in accordance with the EU AI Act. The software vendor will usually remain the provider.
One single application may contain several AI features, and one feature may support several uses. This significantly increases the complexity of AI risk detection and analyses. A classical software list is therefore no longer enough. The company needs to know which AI feature is being used, by whom, for what purpose, with what data, and what kind of changes do apply.
AI Is Already Inside Business Software
AI features may be included when software is first bought, added as a paid option, switched on by an administrator, or introduced through a vendor update, especially in the case of SaaS usage, which is the most common deployment option these days.
76%
of products in an April 2026 review of our curated enterprise-software library contained detected AI features. A classical application-level inventory will therefore miss many of the AI systems people can use at work.
The library is curated toward enterprise business software. AI detection is based on source-linked vendor products, security, and data handling documentation. The percentage is not an estimate for all software.
A real-life example based on the experience of one of our customers: those numbers can become massive. As a family-owned large international SMB, they operate about 1,500 different software programs. 75% of which contained embedded AI. Each of those on average had (five months ago) five AI systems. That equals a total of 5,625 AI systems for the company to keep visibility on.
Five months into the project, the percentage of embedded AI increased to a total of 82%, and now, on average, there is a total of eight AI systems per software. That now sums up to a total of 9,840 AI systems – an increase of roughly 60% in only five months.
The EU AI Act's definition of a deployer focuses on who uses the AI system. It does not matter whether the AI is a standalone service, part of a larger application, built internally, or supplied by a third party.
When a software customer becomes a deployer
A company will generally be a deployer when:
The feature is an AI system. It meets the Act's definition of an AI system.
It is used for work. Staff or contractors use it under the company's authority.
The use is professional. The use is for business rather than a personal activity.
Buying a license or seeing a feature in an admin console is not enough on its own. The role follows actual use.
The Commission has also clarified that employees working under a company's instructions are not separate deployers. The company remains the deployer.
The vendor can be the provider and the customer the deployer of the same system, with different duties for each.
What Applies, and When
Being a deployer does not make every AI use high-risk. The rules and resulting duties depend on what the system does and how it is used. Here are some examples:
Use | Likely position |
Drafting, summarizing, transcribing, or formula help | Usually outside the high-risk categories, although AI literacy measures and other laws may still apply. |
Deepfakes, emotion recognition, biometric categorization, or certain public-interest content | Specific disclosure duties may apply. |
Candidate ranking, employee evaluation, personal credit scoring, or another Annex III use | The system may be high-risk, and the deployer duties in Article 26 may apply. |
Workplace emotion recognition or another prohibited practice | The use may be prohibited even when a vendor supplied the feature. |
AI performing a safety function in a regulated product | A separate high-risk route may apply under Article 6(1). |
AI-literacy measures and prohibited-practice rules have applied since 2 February 2025. Article 50 transparency rules apply from 2 August 2026.
The EU institutions approved new dates for the high-risk rules: 2 December 2027 for Annex III systems and 2 August 2028 for AI safety components in regulated products. See the Council's final approval notice.
But the combination drives the urgency here. Article 4 of EU AI Act requires:
Providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context the AI systems are to be used in, and considering the persons or groups of persons on whom the AI systems are to be used.
The challenge for an employer is to inform, train, and update its staff in accordance with those requirements based on keeping both visibility and track on the continuously changing landscape of embedded 3rd party AI.
Common high-risk uses inside business software
High-risk AI can and does appear inside software most companies already use.
Examples include:
Document or office assistants: comparing applicants and recommending an interview shortlist.
Meeting assistants: scoring employee performance or feeding promotion or dismissal decisions.
HR or recruiting platforms: targeting job ads, filtering or ranking applicants, or scoring candidates.
Workforce management tools: assigning tasks or shifts based on behaviour, personal traits, or performance.
Employee analytics: monitoring or scoring individuals for pay, promotion, or dismissal.
Learning platforms: producing official grades or placement decisions in education or vocational training.
These are ordinary tools, not specialist “high-risk software”. The Act's Annex III focuses on how the AI is used. Finding an AI feature is therefore only the start. The company must also record who uses it, for what purpose, and how its output affects people.
Discovery and governance must work together: find the software actually in use, identify its AI features from vendor evidence, and move relevant features into a managed inventory with owners, use records, risk decisions, and controls.
In other words, using the same tool, say Adobe Acrobat Reader, in two different use cases (one to generate menus/recipes in a cantina of a bank and two using the same tool in HR to evaluate CVs) may result in two different risk classifications in accordance with the act's requirements and duties.
What companies should do
Automate continuous software discovery actually in use. Start with the applications people access, not only procurement records.
Identify AI features. Use source-linked vendor product, privacy, security, and support information.
Map each use. Record the team, purpose, data, output, connected systems, and people affected.
Document and classify. Record approved uses, unclear cases, provider and deployer roles, and when staff must ask for review.
Train employees. Explain approved uses, data limits, human review, and when to stop and ask for help.
Apply controls and monitor change. Keep the vendor's instructions and reassess when the vendor or employee changes the use.
Establish an automated continuous process for those steps to keep up with the changes happening on a daily basis.
Procurement, IT, security, privacy, HR, legal, and business teams may each hold part of this information. A single shared AI inventory gives them one current record of the feature and its actual use.
Training does not turn a high-risk use into a low-risk one. It supports AI literacy and helps stop routine features from being repurposed without review.
What high-risk deployers must do
For high-risk AI, Article 26 gives deployers their own duties. They include:
following the provider's instructions
assigning trained people with enough authority to oversee the system
checking input data where the deployer controls it
monitoring the system, reporting risks and serious incidents, and keeping available logs
informing workers before high-risk workplace use
informing people when an Annex III system makes or supports decisions about them
Some public-service uses also require a review of how the AI could affect people's rights, called a fundamental-rights impact assessment. Privacy, employment, discrimination, and sector-specific laws may apply separately.
The deployer therefore needs useful information from the vendor. A statement that a product “uses AI” is not enough. The company may need the system's intended purpose, limitations, instructions, oversight measures, logs, incident process, version history, and classification.
Existing software is not automatically exempt
The date of the original software contract does not settle the issue. A long-standing application may contain a much newer AI feature.
The approved AI Omnibus text will amend Article 111. Under that transition rule, the high-risk rules apply to earlier systems if they undergo significant design changes after the relevant application date.
Product and version history should therefore form part of the AI inventory. AI-literacy measures, prohibited practices, transparency duties, and other laws have their own application rules and must be checked separately.
When a deployer becomes the provider
A software customer will usually remain the deployer. Under Article 25, however, it can become the provider of a high-risk system if it:
puts its own name or trademark on the system
makes a substantial modification, or
changes the system's purpose so that a use which was not high-risk becomes high-risk
This can happen when a company repurposes a general analysis tool to rank job candidates or evaluate employees. So the use case mainly drives the outcome of the risk classification. Internal approval and vendor contracts should limit uses that fall outside the provider's documented purpose.
How Validaitor supports third-party AI governance
Validaitor's third-party embedded AI discovery starts with automated continuous software detection actually in use. It automatically matches it to up-to-date source-linked software intelligence leveraging our own (currently extended and updated) vendor intelligence database. Furthermore, it identifies embedded AI features and brings relevant products into a centralised, corporate-wide managed inventory. Typically GRC teams can then review automatically detected use case-specific identified risks, apply controls and suggested risk mitigation strategies; and monitor and (immutably) document all risk relevant change.
For a review of your software estate, talk to us.
Author: Art Richards, Berlin
