What this covers
- Most operational back-office agents are not high-risk systems under the AI Act, but that conclusion has to be documented rather than assumed.
- Since 2 August 2026, an agent that writes to people directly has to tell them it is an AI system, and on whose behalf it acts.
- GDPR is usually the more immediate constraint, because business contacts are personal data.
- The artefacts that satisfy both are ones a good deployment produces anyway: a purpose record, a data map, an approval policy and a log.
Ask a compliance function about deploying AI in operations and the first reaction is usually caution proportionate to the headlines, which are largely about systems that score people: credit, hiring, policing, education. An agent that reads a purchase order and creates a sales order is a long way from that, and the regulatory position reflects it.
But the position has to be established and written down. A conclusion nobody documented is not a defence.
Where back-office agents sit under the AI Act
The Act is risk-tiered rather than blanket. A small set of practices is prohibited, a defined set of use cases is high-risk with substantial obligations attached, some systems carry transparency duties, and the rest carries minimal obligations.
It also applies in stages. The prohibitions and the AI literacy duty have applied since 2 February 2025, the rules for general-purpose models since 2 August 2025, and the transparency duties in Article 50 since 2 August 2026. The Digital Omnibus, in force since 27 July 2026, moved the high-risk obligations to 2 December 2027 for the listed uses and to 2 August 2028 for safety components in regulated products.
Agents doing quoting, order entry, purchasing, invoice matching and operational customer requests typically fall outside the high-risk categories, because those categories are built around specific listed uses: safety components in regulated products, and systems affecting individuals in areas like employment, essential services, credit scoring, law enforcement and migration. Processing a business-to-business transaction is none of those.
| Workflow | Typical position | What to check |
|---|---|---|
| Quoting and order entry between businesses | Outside the high-risk list | That no decision about an individual is being made |
| Supplier invoice matching | Outside the high-risk list | Same, plus who approves payment |
| Operational customer requests | Outside the high-risk list, with a transparency duty | Whether the person knows they are dealing with a machine |
| Anything scoring or ranking individuals | Assess carefully | Credit, employment and access to services are listed areas |
Row three carries the one obligation most likely to apply in practice, and since 2 August 2026 it is a legal duty rather than a courtesy. Under Article 50, a person an AI system interacts with directly has to be told so, and an agent acting for a business has to say on whose behalf. The Commission's guidelines of July 2026 count agents that send emails for a business among the systems covered, and a line buried in the terms and conditions does not satisfy the duty. In practice it is settled by how the agent's messages are identified and signed.
Article 50 carries a second duty, and it sits with the provider rather than with you: content a system generates has to be marked as AI-generated in a machine-readable way, with narrow exceptions such as standard editing. Systems already on the market before 2 August 2026 have until 2 December 2026 to comply.
Obligations that fall on you, not the vendor
This is the point most often misunderstood in procurement. The Act distinguishes the provider of a system from the deployer who uses it, and the deployer carries duties of their own. For a back-office agent outside the high-risk list the legal ones are few, the rest are what a later review will ask about, and a vendor cannot absorb all of them by contract.
- Taking measures to support AI literacy among the staff involved. Since the 2026 amendment the duty is proportionate to the systems in use and the risks, but it is still a duty.
- Using the system for its intended purpose, as documented. Repurposing it for a listed use, such as screening job applicants, can make you the provider of a high-risk system.
- Ensuring the people who oversee it are competent to do so, which is a training and staffing question.
- Keeping the logs the system generates, for a period appropriate to the use.
None of these are onerous for a back-office deployment. All of them are easier to satisfy if the system produces a complete activity log as a matter of course, which is one of several reasons the log matters.
GDPR is usually the nearer constraint
In a B2B operation the AI Act analysis often concludes quickly. GDPR does not, because the documents being processed are full of personal data even when nothing about the transaction is personal.
A purchase order is a business document containing the name, email address and phone number of a person. That is personal data, and the analysis follows from there.
Four questions cover most of what has to be established.
- 01What is processed, and why
Business contact details in documents and email, processed to perform a contract or under legitimate interests. Document which, and keep the reasoning.
- 02Where it goes
The deployment boundary matters here. An agent running inside your own infrastructure, acting on data already in your systems, is a narrower processing picture than one that copies documents to a third-party service.
- 03Who else is involved
Any third party in the processing chain, including model inference, is a processor or sub-processor relationship that needs to be named, contracted and disclosed.
- 04Automated decision-making
Article 22 concerns decisions producing legal or similarly significant effects on a person. B2B transaction processing with human approval on material decisions is generally outside it, and the approval design is what keeps it there.
Step four is worth noting because it connects directly to how the agent is built. Designed approval thresholds are not only an operational control, they are part of the argument that no significant decision about a person is being made solely by automated means. Where the agent stops covers that design.
The artefacts to have ready
A compliance review of an operational agent goes faster when five things already exist, and a well-run deployment produces all five for its own reasons.
- 01A purpose record: what the agent does, in which workflow, and what it is not used for.
- 02A data map: what it reads, what it writes, what is retained and for how long.
- 03The deployment boundary in writing: where the agent runs, and where model inference happens, with the data terms that apply.
- 04The approval policy: what the agent may commit, what routes to a person, and who owns those thresholds.
- 05The log specification: what is recorded per transaction, how long it is kept, and who can read it.
Item three is the one to insist on in writing. Where model inference happens is a separate question from where the agent runs, and a vendor who answers only the first has not answered.
What we claim, and what we do not
Our agents comply with the EU AI Act, as amended in July 2026, and with the GDPR. That is our own assessment rather than a certificate, so it is shown with documentation of the kind listed above, not with a badge. oktogonAI does not currently hold ISO 27001 or SOC 2 certification, and our security page says so in the same words rather than in a footnote.
That distinction matters when you are assembling your own compliance file. A compliance claim tells you what a vendor has assessed and documented; a certificate tells you an independent party verified something. They are not substitutes, and a vendor blurring them is telling you something.