What the AI Act and GDPR ask of an agent that processes orders.

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 defense.

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.

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.

Row three carries the one obligation most likely to apply in practice. Where an agent interacts directly with a person, that person should be able to tell they are dealing with an automated system. In a B2B operations context this is usually satisfied by how replies are identified and signed, but it is a decision to make deliberately rather than by omission.

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. A vendor cannot absorb all of them by contract.

• Using the system for its intended purpose, as documented, rather than repurposing it for something it was not assessed for.
• 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.
• Maintaining AI literacy among the staff involved, which is a general duty rather than a formality.

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.

1. 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.

2. 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.

3. 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.

4. 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 artifacts 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.

1. 01A purpose record: what the agent does, in which workflow, and what it is not used for.
2. 02A data map: what it reads, what it writes, what is retained and for how long.
3. 03The deployment boundary in writing: where the agent runs, and where model inference happens, with the data terms that apply.
4. 04The approval policy: what the agent may commit, what routes to a person, and who owns those thresholds.
5. 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

GDPR and the EU AI Act are design inputs for how we build and deploy, not attestations. oktogonAI does not currently hold SOC 2, ISO 27001 or HIPAA 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 design input tells you how a system was built; a certificate tells you an independent party verified something. They are not substitutes, and a vendor blurring them is telling you something.