Guide · Regulation
Two of the AI Act's obligations are engineering, not paperwork
Most high-risk obligations under the EU AI Act started applying on 2 August 2026. Most agents are not high-risk and this page will say so plainly. But if yours is, two of the articles can't be satisfied by a document: Article 12 wants logs the system generates on its own, and Article 14 wants a person who can actually intervene. Those are properties of how the thing is built.
First: you are probably not high-risk
High-risk status comes from what the system is used for, not from how autonomous it is. The Annex III areas are things like employment decisions, creditworthiness, access to education and essential services, and law enforcement. A support assistant that looks up an order and issues a refund is not normally in that list.
What does reach almost every customer-facing agent is the limited-risk transparency duty: a person must know they are interacting with a machine. That is a label, and it is cheap.
So read this page the way you would read a fire code: mostly to know which parts don't apply to you. The vendors telling you every chatbot is now regulated are selling something.
When each part started
Dates from the implementation timeline; framework overview at the European Commission. Checked 11 August 2026.
Article 12 — logs the system generates itself
“Providers of high-risk AI systems shall keep automatically generated logs for a period of at least six months” — or longer where other law applies. Article 12
Retention is the easy half. The hard half is what is in the log, and this is where most agent deployments are quietly short. Teams record the conversation and the exceptions — which answers what the model said, and what failed. Neither is what the system did.
For an agent, the events worth six months are the tool calls: the one that ran, the arguments it ran with, the rule version in force at the time, and — equally — the ones that were stopped. An audit trail holding only refusals answers “what did we prevent”. An audit trail holding only successes answers “what worked”. The question anyone actually asks during an incident needs both halves.
One more thing the log stack usually can't hold: tool arguments carry customer data, so the detail an investigator most needs is exactly what your logging policy forbids you to write. That pushes the record into an encrypted column in your own database rather than into Datadog — which also happens to survive rotation, and six months is longer than most log retention.
Article 14 — oversight that actually oversees
High-risk systems “shall be designed and developed in such a way that they can be effectively overseen by natural persons”, with the ability to intervene or disengage. Article 14
The load-bearing word is effectively. A human-in-the-loop step that a reviewer clicks through is oversight in an org chart and not much else, and the failure is usually mechanical rather than cultural. Two versions of the same button:
- Theatre.The reviewer approves a summary — “issue a $200 refund”. Afterwards the workflow reloads data and rebuilds the request. What executed and what was shown are two different objects, and the log linking them proves nothing.
- Oversight.The exact call is frozen when it's held. The reviewer sees those arguments. Approving replays that stored call — the model is never asked to try again, because a second attempt could produce different values. The decision is spent once, and it expires.
There is a subtler failure worth naming, because it converts the oversight feature into a hole: if “approved” is a flag that skips your permission check rather than satisfying one condition inside it, then a human's click has become the authorization. Find something the agent was never allowed to do, get a person to say yes, and the yes is now the permission. The record will faithfully show that a human authorized it.
What CoreBase produces — and what it doesn't
Being precise here matters more than being impressive. CoreBase is not a compliance product and does not make anyone compliant. What it does is make some of the evidence exist as a by-product of running, so the record is a query rather than an archaeology project:
Every call that ran, and every one that was stopped
Both written as rows, each stamped with the version of your rules in force at the time — so a long run that crossed a policy edit can still be explained.
Arguments kept where they can be kept
Encrypted with your tenant key on the calls that changed something, so the detail a reviewer needs exists without it ever reaching a log line.
Approvals bound to the exact call
Held whole, replayed by the server, spent once, expiring. The reviewer's decision attaches to what runs, not to a description of it.
Which rule and which condition stopped it
Not just the rule's name — the test that actually fired, so the person deciding knows what to check.
What it does not do: your risk management system (Article 9), your data governance (Article 10), your technical documentation (Article 11), your conformity assessment, or the decision about whether you are high-risk at all. Those are organisational work, and no vendor can hand them to you.
Questions people ask
Is my AI agent a high-risk system?
Probably not. High-risk is defined by use, not by how clever the system is — Annex III lists areas like employment decisions, credit scoring, education access, essential services and law enforcement. A support assistant that looks up orders is normally not in that list. What almost certainly does apply to a customer-facing agent is the limited-risk transparency duty: people have to know they are talking to a machine. Read the classification before assuming either way, and take actual legal advice before deciding.
When did this start applying?
Prohibited practices and AI literacy from 2 February 2025. Obligations for general-purpose AI model providers from 2 August 2025. Most high-risk system obligations from 2 August 2026, with a longer path to 2 August 2030 for systems intended for public-authority use, and to 2 August 2027 for GPAI models already on the market before August 2025.
Does using CoreBase make me compliant?
No, and be suspicious of anyone selling that. Compliance is a property of your organisation, your use case and your documentation, not of a component you install. What a governance layer can do is make some of the required evidence exist as a by-product of running the system, so the record is a query rather than a reconstruction. Everything else — risk management, data governance, technical documentation, conformity assessment — is yours.
What does “automatically generated logs” mean for an agent?
Article 12 requires providers of high-risk systems to keep automatically generated logs for at least six months, or longer where other law applies. For an agent the hard part isn't retention, it's what the log contains: most teams record the conversation and the errors, which answers what the model said and not what the system did. The events that matter are the tool calls — which one ran, with what, under which version of your rules, and which ones were stopped.
What counts as effective human oversight?
Article 14 requires the system to be designed so that natural persons can effectively oversee it, with the ability to intervene or disengage. The wording that matters is “effectively”. A person clicking approve on a summary, while the system rebuilds the request afterwards, has not effectively overseen anything — they signed off on a description of an action rather than the action.
See what the record looks like
Connect a source, write one rule, and watch a held action produce its row. Free to start, no card.