What arrived on 2 August, and what it didn't cover
Four days ago the AI Act's Article 50 transparency obligations started to apply. The Digital Omnibus — Regulation (EU) 2026/1744, published in the Official Journal on 24 July and in force since 27 July — pushed the deadlines for high-risk systems out to December 2027 and August 2028, but left that date alone. In the week before it landed, the industry newsletters told you to go and check the chat widget on your website.
If the thing actually running in your company is an agent in the mailbox — it reads the mail, sorts it by case, drafts replies for someone to approve — then the honest answer is that Article 50 most likely doesn't cover it. Except that this isn't good news in the way it sounds.
This article is worth reading paragraph by paragraph rather than by headline. The duty everyone talks about — telling a person they are interacting with an AI system — sits in paragraph 1 and is written onto the provider: it is the provider that has to design the system so the human on the other side knows. Not onto you, if you buy a finished tool.
A deployer's own obligations under Article 50 are narrower than July's panic suggested. Paragraph 3 covers emotion recognition and biometric categorisation. Paragraph 4 covers deepfakes, and model-generated text published in order to inform the public on matters of public interest. Paragraph 5 adds a form requirement on top of all of them: the information reaches the person no later than the time of the first interaction, in a clear and distinguishable way, and it meets accessibility requirements. Mail triage where the reply goes out only after a human approves it is none of those things.
One exception is worth knowing, because it touches anyone who generates content with a model: the machine-readable marking of output in paragraph 2 got a transition period to 2 December 2026 — but only for systems placed on the market before 2 August.
What actually sits on you is somewhere else, and has been binding for a long time. Article 4 — AI literacy — binds providers and deployers, and has applied since 2 February 2025. Trade reporting says the Digital Omnibus softened its wording: from a duty to ensure a level of literacy to a duty to take measures supporting its development. We could not confirm that in the text of the regulation itself, so we treat it as a report, not a finding. The date of application has not changed.
Our thesis
Your agent's first auditor will not arrive from a regulator. In Poland, KRiBSI — the body meant to enforce these rules — only sits around November; we wrote about that gap when the law was signed. That post was about what your client sees on the contact surface. This one is about something else: what the agent touches inside, on your side.
Because the question arrives from procurement, not from supervision. A corporate client that has to demonstrate its own compliance fills in a vendor questionnaire and asks about things Article 50 never requires of you: what data your agent can reach, who approves what goes out, and whether you can reconstruct what it did last month. The same will come at you from an insurer and from your client's auditor. None of them care which paragraph doesn't cover you — they care what you can show.
And that's the heart of it: this is not a compliance program. The three things they will ask about have been in your tenant since the day you bought it. They are admin settings, not a project.
Three things you probably already have
First — classification of what the agent touches. In Microsoft 365 that job belongs to Purview sensitivity labels: an admin defines the data classes, and the label carries encryption and usage rights with it. The Google Workspace equivalent is classification labels created in the admin console, applied in Drive and Gmail and wired to DLP rules. You don't have to label the whole company. One answer is enough: which mailboxes and folders the agent sees, and which it is not meant to see.
It helps to know how the built-in assistants behave here. Microsoft's documentation states plainly that Microsoft 365 Copilot surfaces only data the user already has permission to see, honours the encryption carried by sensitivity labels, and does not use prompts or responses to train the foundation models. Google says the same about Gemini in Workspace. That's useful, but notice where that sentence stops: the user's permissions are the reference point. If your salesperson can reach the entire archive, so can their assistant.
Second — the approval boundary. In the automation playbook for mid-sized companies we described this automation from the value side: the first hour of the day stops being a pass through the inbox. From the compliance side, one sentence in that same description is what counts — recurring cases get a draft reply for a human to approve. Write down exactly where that boundary sits: what the agent does on its own (classifies, tags, summarizes) and what it never does without a click (sends, promises a date, confirms a price). One page. The point is to have that boundary on paper before the moment somebody asks about it.
Third — the log. This one is probably already collecting without your knowledge. The unified audit log in Purview records user and admin operations, mailbox activity included — the MailItemsAccessed event says that somebody (or something) read the contents of a mailbox — and you can search it from the portal, through the Graph API or with PowerShell. Google has the same in the audit and investigation tool in the admin console, with filtering and export. Your job is not to build the log; it is to check two things: whether retention on your plan reaches further back than the last few weeks, and whether anyone in the company knows how to pull that log when the question comes.
Why it matters
Private Equity
For a fund this is a cheap diligence item that says a lot. A portfolio company with an agent in the mailbox and no answer to "what can it reach" is not breaking the law — it is unprepared for the first big client's questionnaire, and that shows up in the sales cycle, not in a legal opinion. Ask for the three artifacts above, not for an AI policy. A policy can be written in a week; the agent's permission scope and the log's retention describe what actually happens.
Enterprise
A large organization already has labels, an audit log and AI governance. What's new here is a distinction that has just started to matter in contracts: where you are the provider and where you are the deployer. With an assistant bought off the shelf, the paragraph 1 duty sits with the maker, and your job is to verify they discharged it and to have that from them in writing. With an assistant built in-house and exposed to clients, you take the provider role on yourself, and the disclosure design with it. The same technology, two different rows in the systems register.
SMB / mid-market
This is where the takeaway is most practical, because the obligation you were worried about probably doesn't cover you, and the one that does is doable without a lawyer. Article 4 is about people: the team working with the agent has to understand what it does and where it gets things wrong. An hour of conversation with the conclusions written down sits closer to the point than a training course with a certificate. How we set up AI automation for SMBs together with its boundaries: one process and one permission scope first, then the extension — because the boundaries are part of the product, not an add-on after an incident.
One move for this week
Open your admin console and check one thing: which account your mail agent runs under, and what that account can see. If the answer is "the owner's account" or "an admin", you have your task for the next few days — because in a vendor questionnaire that is exactly the question that ends with "please explain". Then two sentences on the approval boundary and one check on log retention. None of this can be backfilled in the week the client asks. Describe your case: mailto:[email protected]?subject=Rozmowa%20z%20Aurora%20AI.