LotsAgent
On 2 August 2026, the bulk of the EU AI Act becomes enforceable. If you run an AI agent that takes consequential actions for or inside the European Union — sending email, updating a CRM, drafting contracts, moving money, screening candidates — the obligations in Articles 9, 10, 12, and 15 of the Act apply to you, and the penalties for non-compliance run up to €35 million or 7% of worldwide annual turnover under Article 99. Those numbers are not theoretical; they are the statutory ceiling. Even an SMB that never had a regulator on its phone can find itself inside the scope of the Act in under two months.
This is the article the operator who is suddenly reading about the Act needs. Not a law-firm memo. A practical read: which four articles actually touch agent operations, what each one asks of you, and what to do about it before the deadline — with a clear-eyed look at how a platform like LotsAgent maps (and where it doesn't) to those obligations.
One honest caveat up front. The European Commission has signalled adjustments to the high-risk timeline through the "AI Act Omnibus" process, and the precise deadlines for some categories of high-risk system may shift. As of writing, the 2 August 2026 date is still the binding enforcement moment for most provider obligations, and SMBs should plan against it — not gamble on a delay that may or may not arrive.
The 30-second EU AI Act primer
The Act distinguishes two main roles: providers (the entity that develops or has developed an AI system and places it on the EU market) and deployers (the entity that uses an AI system under its own authority). Both roles carry obligations, and most SMBs running agents are both — provider of the configured agent, deployer of the agent in their own operations.
The Act creates four risk tiers. Most of what an SMB will deploy falls into one of two: limited risk (chat assistants, content generators) and high-risk (agents used in employment, credit, education access, law enforcement, critical infrastructure, and other Annex III use cases). The high-risk tier is where Articles 9, 10, 12, and 15 actually bite. The bulk of the Act's obligations land on 2 August 2026 per the European Commission's AI Act page; some narrow categories in Annex I were extended to 2 August 2027.
For agents specifically, the threshold question is straightforward: can this agent take or substantially influence a decision that affects a person's rights, access, money, or safety? If yes, treat it as high-risk and plan accordingly. The Act does not give you the benefit of the doubt when an autonomous system has acted at scale without meaningful human review.
Article 9 — Risk management across the agent's life cycle
Article 9 requires a documented, continuously updated risk management process for high-risk AI systems. For an agent, that means writing down the risks that come with each tool the agent can call, each system it can touch, and each decision it can make — and revisiting the document every time the configuration changes.
Operationally, this looks like a risk register tied to the agent's configuration:
- Every tool the agent can invoke, with the specific risk class of that tool (read-only vs write, reversible vs irreversible, low-blast-radius vs high).
- Every external system the agent can touch, with the failure mode if the agent misuses it.
- Every decision boundary the agent can cross, with the mitigation currently in place (review step, approval, scope limit, human owner).
- A version history. When a new tool is added, when a skill is reassigned, when memory scope is widened — the register is updated and the change is dated.
A practical habit: tie the risk register to the agent's identity in the platform. When the agent is paused, the register goes with it. When the agent is restored, the review is gated on a fresh sign-off against the register. This is exactly the pattern the published 30-Minute AI Agent Audit walks through for non-EU teams — the EU version just adds a documentation layer auditors will actually ask for.
Article 12 — Logging and traceability
Article 12 requires automatic logging of events over the lifetime of a high-risk system. For agents, that means a record of every prompt, every tool call, every response, every state change, every memory write — timestamped and attributable to a specific agent identity.
This is not a nice-to-have. The audit trail is the proof that the system was operating within the boundaries you set. When something goes wrong — and the published silent AI failures research shows things go wrong often — the trail is what lets you answer three questions: what did the agent do, when, and why.
What auditors actually look for:
- Identity. Not "some agent" — a specific named agent, tied to a specific human owner. See the Agent Identity and Accountability posts for why this matters.
- Completeness. Logs that capture the full execution path, not just the final answer. A tool call without the response is half a record.
- Retention. Logs kept long enough to be useful in an investigation. The Act does not pin a specific retention period, but national regulators will expect a defensible policy.
- Tamper resistance. Logs that cannot be edited after the fact, or that have a clear chain of custody.
A platform that gives you this by default — every execution, every tool call, every state change, with the agent's identity attached — turns Article 12 from a build project into a configuration choice. A platform that doesn't, forces you to build it yourself, and you have less than two months.
Article 15 — Human oversight, in operational terms
Article 15 is the article that most generic "responsible AI" writing gets wrong. It does not ask for a human in the loop in spirit. It asks for human oversight in the live execution path — the ability for a person to intervene, override, redirect, or shut the agent down, in time to matter.
Operationally, that means a review step before any consequential action. Outbound email: a human reviews before send. CRM change: approval before commit. Money movement: explicit sign-off. Ambiguous case: escalation to a named human, with a deadline. A "we'll review the logs tomorrow" workflow does not satisfy Article 15.
It also means a single human owner per agent. Not a team, not a Slack channel — a person who is accountable for the agent's behaviour, who knows what the agent is configured to do, who has the authority to change that configuration, and who is named in the risk register. This is the HTTL (human-to-the-loop) model: capable agents, accountable to humans, with the human in the actual decision path — not standing in front of a dashboard after the fact.
The email-decision-followup workflow is a useful concrete example. The agent reads email, drafts a reply, and the human reviews before send. Same pattern as a customer-support agent: agent handles the routine, human owns the consequential.
Article 10 — Data governance for agent memory and inputs
Article 10 covers training, input, and output data quality. For most SMBs running agents, the live cut of this article is the memory question: what does the agent store, for how long, and how is it refreshed?
A defensible answer is a written policy that covers:
- What is stored. Customer records, conversation history, prior decisions, draft outputs. The categories and the rationale for each.
- What is forgotten. Deletion triggers, retention windows, and the process for honouring a data-subject request. The Act intersects with GDPR here; the published AI Agent Memory post covers the operating model for "what to forget" decisions.
- What can be overridden. The mechanism for a human to correct a stored fact, mark a memory as untrusted, or scope memory to a single user or session.
- Audit implications. Where memory is used in a consequential decision, the trail must show what the agent knew at the time and why that memory was trusted.
A platform that treats memory as a configurable, scoped, auditable resource — not a free-form blob — gives Article 10 somewhere to land. A platform that treats memory as a black box does not.
Where LotsAgent maps to each article — honestly
A platform does not make you compliant. It gives you the controls the Act requires, and configuration is the operator's responsibility. That caveat matters, so it's stated up front.
With that said, here is the honest map for LotsAgent:
- Article 9 (risk management). Every agent has a named identity, a defined role, a documented tool set, a scoped permission model, and a single human owner. Configuration changes are versioned, and the Agent Improver is a continuous signal source for new risks the operator may not have anticipated. The risk register is the operator's artefact; the platform provides the inputs.
- Article 10 (data governance). Memory is configurable — per-user, per-agent, vector or text. Retention is a user-controlled setting. "What to forget" is a documented operational decision, not an accident of the model. The published Memory post is the operating model.
- Article 12 (logging). Every execution is logged: prompt, tool call, response, state change, memory write, agent identity, timestamp. Logs are exportable and durable — powered by the same checkpointed execution model used for retries. No agent runs in a black box.
- Article 15 (human oversight). Review steps, approval gates, escalation paths, and a configurable kill switch are first-class configuration. HTTL is the platform's stated philosophy, not a marketing line. The Agent Identity post covers why this matters; the Accountability post covers what breaks without it.
What the platform does not do: certify you. No "compliant by default" claim, no regulatory seal, no guarantee that a specific configuration will satisfy a specific national regulator. Compliance is a posture you maintain; the platform is the tool you maintain it with.
The SMB checklist before 2 August 2026
Work through this list. Each item is something you can verify in a single sitting.
- Confirm whether you are in scope. Are you placing an agent on the EU market, or using one whose output is used in the EU? If yes, the Act applies. The Omnibus process may adjust some deadlines, but in-scope status is not in serious doubt.
- Classify each agent you run. For each, ask: can this agent take or substantially influence a decision that affects a person's rights, access, money, or safety? If yes, treat it as high-risk and apply Articles 9, 10, 12, 15. If no, document the reasoning and the controls that keep it in the limited-risk tier.
- Verify the audit trail. Confirm the platform captures prompt, tool, response, agent identity, and timestamp. Confirm the logs are exportable and retained for a defensible period. Confirm they cannot be silently edited.
- Confirm a human review step for every consequential action. Approval before send, before commit, before move. Not a "we'll check tomorrow" step — a step in the live execution path.
- Document retention and refresh policy for stored memory. What is stored, what is forgotten, how a data-subject request is honoured, how a wrong fact is corrected.
- Assign a single human owner per agent. One name, not a team. The owner is accountable for the agent's behaviour, the risk register, and the configuration.
- Test the kill switch. The ability to stop the agent mid-execution, or pause it entirely, must work — not in theory, in a live test, on a Friday afternoon, with a real workflow running.
- Check your role. Are you a provider, a deployer, or both? The obligations differ. Most SMBs running their own agents are both.
The Act is not asking you to do anything unreasonable. It is asking you to do what a careful operator would do anyway: know what your agent can do, know what it has done, know who is responsible, and keep a human close to the consequential decisions. The platform can give you the controls. The discipline is yours.
Build the agent that survives the deadline
LotsAgent gives SMBs the controls the EU AI Act requires: named identity, durable execution logs, configurable review steps, scoped memory and tools, and a human in the live decision path. It is not a compliance certification, and configuring the controls is your responsibility — but the platform makes the work of doing it concrete.
Create your first agent free and walk it through the checklist above. The deadline is fixed. The work is not optional. The platform is ready.
FAQ: EU AI Act and AI agents
Does the EU AI Act apply to my SMB if I am not based in the EU?
Yes, if your agent's output is used in the EU. The Act applies to providers and deployers that place AI systems on the EU market, regardless of where they are established. If you serve EU customers from the US, the UK, or anywhere else, and your agent's actions affect people in the EU, you are in scope.
What does "high-risk" mean for AI agents specifically?
Under Article 6 and Annex III, a system is high-risk if it is a safety component of, or intended to be used in, a regulated product (Annex I) or in one of eight use cases: biometric ID, critical infrastructure, education, employment, essential services, law enforcement, migration, and justice. Agents that take or substantially influence consequential decisions in any of those areas are high-risk. The European Commission's AI Act page is the source of truth for the classification rules.
What is the penalty for non-compliance with the EU AI Act?
Under Article 99, fines for prohibited practices reach €35 million or 7% of worldwide annual turnover, whichever is higher. Fines for non-compliance with high-risk obligations (Articles 9, 10, 12, 15) reach €15 million or 3% of worldwide annual turnover. Smaller violations carry €7.5 million or 1%. Member states set their own penalty regimes within those ceilings.
Do I need to certify my agent before 2 August 2026?
The Act requires conformity assessment before placing a high-risk system on the market, but the regime is risk-proportionate. Many SMB agent deployments will rely on internal controls plus the provider's existing documentation. The exact pathway depends on your agent's classification, the role you play (provider vs deployer), and any national rules in the EU member state where the agent is placed. Talk to a lawyer who has read the Act; this article is operating guidance, not legal advice.
How do I prove human oversight to an auditor under Article 15?
You prove it with a configuration artefact and a log. The configuration artefact shows where in the execution path a human review step exists, who is named as the reviewer, and what the agent is blocked from doing until the review completes. The log shows the review happened — with timestamp, reviewer identity, and outcome. A platform that treats review steps and escalation paths as first-class configuration gives you both artefacts by default.
What is the difference between a provider and a deployer under the Act?
A provider develops or has developed the AI system and places it on the EU market under its own name. A deployer uses the AI system under its own authority. If you build an agent on a platform and run it for your own business, you are usually both: the platform is the underlying provider, you are the provider of the configured agent, and you are the deployer of that agent in your operations. Each role has its own obligations under the Act. The EC AI Act page outlines the split.