basenull
4 min readBasenull AI Ops

The AI Act's high-risk obligations land August 2. Your agents qualify more often than you think.

On 2 August 2026, the EU AI Act's obligations for high-risk AI systems start applying. Most of the coverage is legal analysis aimed at model providers. If you deploy AI inside hiring, credit, or essential-service workflows — including agents you assembled in-house — the operational checklist is yours, and it's shorter than the legal memos suggest.

AI ActComplianceAI Governance

The EU AI Act has been rolling out in stages since it entered into force in August 2024: prohibited practices first, then the general-purpose model obligations in 2025. On 2 August 2026, the stage that matters most to ordinary enterprises arrives — the obligations attached to high-risk AI systems, the Annex III categories that cover AI used in employment, education, credit, essential services, and similar domains.

Most of what has been written about this milestone is addressed to AI vendors, because the heaviest obligations fall on providers. That has left a comfortable impression in many IT organizations: our vendors will handle it. Two problems with that comfort.

First, the Act puts real obligations on deployers — the organizations using high-risk AI systems — and those obligations are operational, not contractual. You cannot outsource them to the vendor's compliance page. Second, the moment you wrap a general-purpose model into a workflow of your own — an agent that screens applications, ranks candidates, or triages credit exceptions — the question of who the provider even is gets uncomfortable. Build enough around a model and you may not be merely deploying anymore.

Agents change the math

The Annex III categories are defined by what the system is used for, not by how it was built or how sophisticated it is. AI used to filter job applications or evaluate candidates is the canonical example — it's high-risk because of the domain, full stop.

Here's the part that catches organizations off guard: nobody procures "a high-risk AI system." What actually happens is that a team takes the enterprise AI subscription everyone already has, adds some instructions and a connection to the applicant-tracking system, and now there's an agent shortlisting candidates. No procurement event, no legal review trigger, no line item. From the Act's perspective, the use case is what it is — the informality of how it came to exist is not a defense, and arguably makes things worse, because informal systems are precisely the ones missing the records the Act expects.

So the first honest step is not legal analysis. It's the same unglamorous move that underpins every other AI control: inventory. List the AI systems and agents actually in use — including the ones assembled inside business units — and map each against the Annex III categories. In most organizations, nobody has that list. That, not the legal interpretation, is the blocking task, and it's squarely an IT problem.

The deployer checklist is operational

Strip the deployer obligations to their operational core and they look like this:

  1. Know your systems and their classification. The inventory above, kept current — because teams will keep creating agents after August 2.
  2. Assign human oversight that actually exists. The Act expects natural persons with the competence and authority to oversee each high-risk system. "The business owns it" does not name a person. Someone must be able to intervene, and must know they hold that job.
  3. Keep the logs. Deployers must retain the logs their high-risk systems generate, on the order of months at minimum. For an agent, that raises an immediate question most teams can't answer: what logs? The model transcript alone doesn't show what the system did. If your agents' actions aren't producing a durable, reviewable trail today, you have a logging gap before you have a retention gap.
  4. Use systems as instructed, and monitor them. Deployers are expected to operate within the provider's instructions and monitor operation — with a duty to act, up to suspending use, when the system presents risk. Monitoring an agent means knowing when it deviates from its intended process, which is a capability, not a sentence in a policy.
  5. Be transparent with the people affected. Workers screened, applicants ranked, customers scored — affected people are owed disclosure in the relevant categories. This is more HR-and-legal than IT, but IT holds the list of where it applies.

None of this requires a compliance platform program. All of it requires the basics: an inventory, an audit trail, a named human, a monitoring signal, a retention policy.

Do it once, get the controls you needed anyway

Here is the reframe worth bringing to your steering committee: every artifact on that checklist is something a well-run AI operation produces regardless of the Act. An inventory of agents and their connections. Durable records of what agents did. A human who gets paged on deviation. Monitoring that notices when behavior drifts. You should want these even if Brussels had never legislated — they're the same items any incident review or board scorecard would demand.

Which means the AI Act deadline is best treated not as a compliance tax but as a forcing function for operational work that has been easy to defer. The organizations that scramble in late July will produce paperwork. The ones that build the underlying controls will produce paperwork as a byproduct — and keep the controls.

The usual caveat applies: this is an operator's reading, not legal advice, and your counsel should own the classification calls. But don't let the legal review become the excuse for operational delay. The lawyers cannot inventory your agents for you — and August 2 is not the day to discover how many you have.

From the operator

Basenull AI Ops ships purpose-built tools for the IT executive whose org is already running AI in production. Governance, supply-chain security, agent ops, observability — the operational layer that usually arrives after the first incident.

Explore products