Picture a software company in Kuala Lumpur with a new contract: an employer in the Netherlands wants an AI agent that reads job applications, scores them against the role and drafts a shortlist. Recruiters in Rotterdam will review it. Nobody in the KL office has ever read EU law.
Then the client's procurement team sends a questionnaire. Question 14: "Describe how the system complies with Articles 12 and 14 of Regulation (EU) 2024/1689."
The story is illustrative. The question is not. The short answer: Article 12 of the EU AI Act says a high-risk AI system must automatically record events (logs) over its lifetime, so that risks, changes and its day-to-day operation can be traced. Article 14 says it must be built so that people can oversee it: understand its limits, resist over-trusting it, interpret its output, override or reverse it, and stop it safely. For high-risk uses listed in Annex III, such as screening job applicants, both apply from 2 December 2027.
Before going further: I am an engineer, not a lawyer, and this is not legal advice. This is how I read the text, and how we would build to it.
Key takeaways
- "High-risk" depends on what an agent is used for, not how it is built. Point a sales-email agent at CVs and it becomes high-risk.
- A company in Malaysia, Singapore or Bangladesh is caught if it puts a high-risk system on the EU market, or if the system's output is used in the EU.
- Article 12 is a list of purposes the logs must serve, which tells you which fields you need.
- Article 14 is the most concrete part of the Act for engineers. Point (e) literally asks for a "stop" button that brings the system to a safe halt.
- Log the human's decision next to the agent's proposal. Most teams log one or the other.
When do the rules actually apply after the Digital Omnibus?
The dates moved this year, and a lot of material online is now wrong.
The original Act applied the high-risk rules from 2 August 2026. The Commission proposed a "Digital Omnibus" in November 2025 to simplify it, and the result, Regulation (EU) 2026/1744, entered into force on 27 July 2026.
The amended Article 113 now says Chapter III, Sections 1 to 3 (which hold Articles 12, 14 and 26) apply from 2 December 2027 for systems that are high-risk under Annex III, and from 2 August 2028 for AI built into products covered by Annex I, such as machinery or toys.
Thirteen months sounds like a lot. It is not, if you are building now. Retrofitting a stop button into an agent that was never built to be interrupted is the kind of job that eats a quarter.
When does an AI agent become "high-risk"?
There is no category called "AI agent" in the Act. There is an AI system, and there is its intended purpose. Annex III, point 4(a), lists "AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates".
Our KL screener does exactly that. It is high-risk.
Article 6(3) offers an escape hatch for Annex III systems that don't materially influence decisions, but it also says an Annex III system "shall always be considered to be high-risk where the AI system performs profiling of natural persons". Scoring applicants on their CVs is about as close to profiling as it gets. I would not build a business on the exception.
This is the part most coverage misses: the agent framework is not the regulated thing. Point the same code at sales leads and it is not high-risk. Point it at job applicants, credit decisions or task allocation for workers, and it is.
Does the EU AI Act apply to a company in Malaysia, Singapore or Bangladesh?
Yes, if it touches the EU market. Article 2(1) applies the Act to providers placing AI systems on the EU market "irrespective of whether those providers are established or located within the Union or in a third country", and to providers and deployers in third countries "where the output produced by the AI system is used in the Union".
Which role does the KL company play?
- The provider develops the system and places it on the market or puts it into service under its own name or trademark (Article 3(3)). If the KL company sells its screener under its own name, it is the provider, and as a non-EU provider must appoint an authorised representative in the EU by written mandate (Article 22).
- The deployer uses the system under its authority. The Dutch employer is the deployer.
Custom builds are less tidy. If the employer runs a bespoke system under its own name, the employer may be the provider, and the KL company a supplier that must agree in writing to give it the information and technical access it needs (Article 25(4)). Either way, the engineering lands on whoever writes the code.
The provider has to build the capability. The deployer has to use it: under Article 26, assign oversight to "natural persons who have the necessary competence, training and authority", monitor the system, keep the logs under its control for at least six months, and tell applicants that a high-risk system is being used on them. The provider has a matching six-month minimum for logs it controls under Article 19. If your agent's logs live only in the provider's cloud, the deployer cannot meet its own duty without your help. Design the export on day one.
What must Article 12 logs make possible?
Article 12(1) is one sentence: high-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system". Automatic, so not a person typing notes. Lifetime, so not a 14-day rotation.
Article 12(2) is the useful part, because it says what the logs are for. They must record events relevant for:
- identifying situations where the system may present a risk, or where it has undergone a substantial modification;
- post-market monitoring by the provider (Article 72);
- the deployer monitoring the system's operation (Article 26(5)).
It does not list fields (Article 12(3) does, but only for remote biometric identification). A standard, ISO/IEC 24970 on AI system logging, is still a draft. Until it lands, work backwards: take one record and ask which purpose each field serves. If a purpose has no field, you have a gap.
A few things in that record are deliberate.
Versions on every record. You can only spot a substantial modification if you can see that last Tuesday's runs used a different model, prompt or policy from this Tuesday's. Agents change constantly. If versions aren't stamped on each event, you cannot answer "when did the behaviour change?"
Input by reference. A CV is personal data. Article 26(6) says log retention is subject to EU data protection law, so storing every CV inside every log line is a bad idea. Store a pointer and a hash, which proves which version the agent saw.
The human decision in the same record chain. This is the one most teams get wrong. They log the model call in their observability tool and the recruiter's click in the application database, with no shared key. When a rejected applicant complains, you need one trail: what the agent proposed, who looked, what they saw, what they decided, what ran. You can't monitor oversight you didn't record.
Integrity. The Act does not say "tamper-evident", but a log someone can quietly tidy up after an incident is not much use. We learned this on our own demo. In October 2026 we ran 12 tests against the governance in Ware, our simulated warehouse with a real AI recovery agent, and one of the three weaknesses we found was that audit records could be edited or deleted with nothing to notice. The fix was an append-only, hash-chained log. Here is the idea in a few lines of Python, which I ran as written:
import hashlib, json
def append(log, record):
prev = log[-1]["hash"] if log else "0" * 64
body = json.dumps({**record, "prev": prev}, sort_keys=True)
log.append({**record, "prev": prev, "hash": hashlib.sha256(body.encode()).hexdigest()})
def verify(log):
prev = "0" * 64
for i, r in enumerate(log):
rec = {k: v for k, v in r.items() if k not in ("prev", "hash")}
body = json.dumps({**rec, "prev": prev}, sort_keys=True)
if r["prev"] != prev or hashlib.sha256(body.encode()).hexdigest() != r["hash"]:
return f"broken at record {i}"
prev = r["hash"]
return "ok"
log = []
append(log, {"event": "agent.proposal", "candidate": "C-2291", "proposal": "reject"})
append(log, {"event": "human.decision", "candidate": "C-2291", "decision": "override:advance", "reviewer": "r.tan"})
print("before edit:", verify(log))
log[0]["proposal"] = "advance" # someone tidies up the record
print("after edit: ", verify(log))
before edit: ok
after edit: broken at record 0
In production the chain lives in an insert-only table, with the head anchored somewhere the application cannot write; see an audit trail for AI agents.
What does Article 14 human oversight require, in engineering terms?
Article 14 opens with a line engineers should like: systems must be designed "including with appropriate human-machine interface tools" so that people can effectively oversee them. Oversight is a feature of the product, not a paragraph in a policy.
The measures must be "commensurate with the risks, level of autonomy and context of use" (14(3)). Then Article 14(4) lists what the person assigned to oversight must be enabled to do. Each point translates into something you can build and test.
(a) Understand capacities and limitations, and monitor. The recruiter needs to know what the screener is bad at. Say the KL team never tested it on CVs written in Dutch, and it cannot judge portfolio links. Put that on the review screen, not in a PDF nobody opens. For monitoring, the simplest useful signal is the override rate. If it suddenly drops to almost nothing, either the model got better or people stopped looking.
(b) Automation bias. The Act names it explicitly: "the possible tendency of automatically relying or over-relying on the output". It is the hardest to build for, because the easiest UI, a list of scores with "Approve all", is precisely the problem. What helps: show the CV before the score, remove bulk accept for rejections, and occasionally seed a known case to see whether reviewers catch it. All of it costs reviewer time, and the client will push back. That conversation is the oversight design.
(c) Interpret the output. "Score 41" means nothing. "Score 41: two years with no listed employment, 2019 to 2021; no Python mentioned" can be checked in ten seconds, and the recruiter can see the agent has punished a career break. Reasons have to point at evidence in the input, otherwise they are just more output to trust.
(d) Decide not to use it, disregard, override or reverse. Three separate features. Override this decision now, with a reason that goes in the log. Reverse one already acted on, such as re-opening a rejected application. And a manual route through hiring that works with the agent off; without it, nobody can really decide not to use the system.
(e) Interrupt with a "stop" button "that allows the system to come to a halt in a safe state". This is the line I would print and stick on the wall. A Stop that hides the agent's UI while queued tool calls keep executing is not a stop. In Ware, Stop takes the same lock as an action, so the two are strictly ordered: an action either finished before Stop, or it is refused after. Pending approvals are voided in the same step, and our tests force Stop and an action in both orders. "Safe state" also needs defining per system. For a screener: no further emails to applicants, nothing half-written to the applicant tracking system.
One more trap from our own testing: in Ware, an approval was checked in one transaction and executed in another without a re-check, so a change in between went unseen. Translate that to hiring: the recruiter approves "advance C-2291 to interview", and between approval and execution the role is closed or the CV is replaced. The approval should bind to the exact action and the state it was planned against, and be checked again in the same transaction that executes it. Otherwise your oversight record says a human approved something they never saw. The LangGraph and Temporal post shows that in code.
How would we build this into the screening agent?
The architecture we would use follows our AI governance approach: the model proposes, deterministic code decides.
The agent reads a CV and produces a proposal: advance, hold or reject, with evidence-linked reasons. It cannot write to the applicant tracking system. A command service checks policy (deny by default; rejections always need a person) and puts the proposal in an approval queue with full context: the CV, the reasons, the limits card and the record versions it was planned against. A named recruiter accepts, overrides with a reason, or holds. Only then does the command service execute, re-checking the bound state in the same transaction. Every step, from proposal to decision to execution or refusal, goes into one append-only log with the model, prompt and policy versions stamped on it. A Stop control per client revokes authority and voids pending approvals atomically.
On our Autonomy Ladder, that is L2, Approve: a named person approves each write. For hiring decisions about people in the EU, I don't expect to recommend going higher. Removing the human from rejecting job applicants is a conversation with a regulator in it.
More on the patterns in human in the loop AI agents; this is the kind of work we do in AI agent development.
Frequently asked questions
When do Articles 12 and 14 of the EU AI Act apply?
For high-risk systems listed in Annex III, such as recruitment, education, credit scoring and worker management, from 2 December 2027. For AI built into products covered by Annex I, from 2 August 2028. These dates come from Article 113 as amended by the Digital Omnibus, Regulation (EU) 2026/1744.
Is every AI agent high-risk under the EU AI Act?
No. Risk follows the intended purpose. An agent drafting marketing copy is not high-risk; the same agent screening job applicants falls under Annex III point 4(a).
How long must high-risk AI logs be kept?
At least six months, under Article 19 for providers and Article 26(6) for deployers, unless other EU or national law, especially data protection law, says otherwise.
Does the EU AI Act apply to companies outside the EU?
Yes, when they place systems on the EU market or the output is used in the EU (Article 2). Non-EU providers of high-risk systems must appoint an EU authorised representative (Article 22).
What counts as a "stop" button under Article 14(4)(e)?
Any control or procedure that lets the person interrupt the system so it comes to a halt in a safe state. In an agent, that means pending actions are refused and no queued tool call runs after Stop, not just that the screen goes grey.