03 / SECURITY & DEPLOYMENT
EU AI Act: what Article 14 oversight and Article 26 logs ask of an agent deployment
For compliance, risk and platform teams in the EU working out what the high-risk obligations mean in practice for an AI agent that changes records in production systems.
GembaOS is a zero-trust governance runtime for enterprise AI agents: policy-decided access, single-use clearance tokens bound to exact parameters, and accountable human approvals, running on-premises or in a private VPC. This page maps two articles of the EU AI Act to mechanisms an agent deployment can actually show. It is not legal advice, and nothing here is a claim that a system using GembaOS is compliant.
What does Article 14 actually require?
Article 14 requires that a high-risk system be designed and developed so that it “can be effectively overseen by natural persons during the period in which it is in use”. The measures are to be commensurate with the risks, the level of autonomy and the context of use — which for an agent that writes to production systems is the demanding end of that scale.
Paragraph 4 lists what the assigned person must be enabled to do. Read as a specification for an approval screen, it is more exacting than most:
| Article 14(4) | What it asks | What an agent deployment has to show |
|---|---|---|
| (a) | Properly understand the system’s capacities and limitations and duly monitor its operation | The approver sees which checks were machine-verified and which were not, and what the action will do |
| (b) | Remain aware of the tendency to over-rely on the output (automation bias) | A screen that states the effect and its reversibility in business terms, not a recommendation to accept |
| (c) | Correctly interpret the output | The decision is put in the language of the work, with the amount, the target and the limit it was checked against |
| (d) | Decide not to use the system, or to disregard, override or reverse the output | Reject and return are first-class outcomes, each with a recorded reason |
| (e) | Intervene in the operation or interrupt it through a stop button or similar procedure | A stop that lands before the write, not after it |
Point (e) is the one that separates agent deployments from classic model deployments. A stop button that halts an agent after a refund has been paid has not interrupted anything. The stop has to sit between the decision and the write.
How do GembaOS mechanisms line up with that?
| Obligation | Mechanism | Where it is visible |
|---|---|---|
| The person can understand and interpret the output | The approval request opens with what approval sets in motion: effect, reversibility, target, amount, the limit checked, validity, uses and what is re-checked before the write. Technical identifiers are folded away for auditors | The console, and the architecture whitepaper |
| The person can override or reverse | Approve, reject and return are all recorded outcomes; rejecting and returning require a reason | The work item |
| The person can interrupt before the effect | The action does not execute without a single-use clearance, and the host re-reads the real state just before the write; if it changed, execution stops and the clearance is voided | The clearance token line and the execution record |
| Oversight is by a named natural person with authority | The route comes from your Delegation of Authority; the person signs with their own passkey, and standing in for someone is recorded as on-behalf-of rather than as a shared account | The signature chain |
| That person is available and competent for the case | Consult, transfer, escalate and take over over an org chart imported from your directory, with stand-in rules and authority offboarding | The Team Desk and the work item |
| Records are kept and can be examined | Every turn, decision, signature and execution is one hash-chained record that audit replay can re-run against the current policy | The work item and its export |
What does Article 26 add for a deployer?
Article 26 is the deployer’s side, and two paragraphs matter most for an agent deployment.
Paragraph 2 requires that human oversight be assigned to natural persons who have “the necessary competence, training and authority, as well as the necessary support”. That is an organizational sentence with a technical consequence: a queue that anyone with console access can clear does not satisfy it. Authority has to be attached to a person and checked at the moment of signing — which is the same thing an internal Delegation of Authority already says, and the reason GembaOS routes by role and limit rather than by inbox.
Paragraph 6 requires deployers to keep the logs the system automatically generates, where they control them, “for a period appropriate to the intended purpose … of at least six months, unless provided otherwise in applicable Union or national law”. The practical question is not retention length, which is easy, but whether the retained record answers what was decided, by whom, on what evidence, and what then happened. A hash-chained work item answers that; a sampled application log does not.
Paragraph 5 also requires monitoring and, where use may present a risk, informing the provider and suspending use. For an agent this argues for a record in which an unexpected outcome is visible as an event rather than inferred later from logs.
Where the line is
GembaOS is a component. It can show who decided, on what evidence, under which rule, and what the system then did — and it can stop an action before the effect. It cannot classify your system, run your risk management, write your technical documentation or assess your conformity, and no mechanism on this page should be read as a claim that it does. As of September 2026 GembaOS holds no certification, and the control mappings on this site are self-assessed rather than audited.
Questions this note answers
Does using GembaOS make our AI system EU AI Act compliant?
No, and no product can. Compliance depends on how your system is classified, your risk management, your documentation and your own assessment. GembaOS supplies mechanisms a deployer can point to for the oversight and record-keeping duties; whether they are sufficient for your system is a question for your own legal and compliance function.
Do these obligations apply to us at all?
Articles 14 and 26 apply to high-risk AI systems as the Act defines them. Many internal agent deployments are not high-risk, and the classification is not something a vendor can decide for you. Where a system is in scope, the deployer duties in Article 26 apply from 2 August 2026.
What counts as being able to interrupt an agent?
Article 14(4)(e) speaks of intervening or interrupting the system through a stop button or similar procedure. For an agent that writes to production systems, the meaningful equivalent is a hard stop before the write, not a request to stop afterwards, because an executed refund or a deleted account is not interrupted by stopping the agent.
Which logs are we expected to keep for six months?
Article 26(6) refers to the logs the high-risk system automatically generates, where they are under the deployer's control, kept for a period appropriate to the intended purpose and at least six months unless other Union or national law says otherwise. What matters in practice is that the retained record is the one that shows the decision, not a sampled application log.
Sources
As of September 2026 GembaOS holds no certification; the control mappings on this site are self-assessed, not audited. GembaOS is in its design partner stage. Read about the design partner program.
Last updated: · GembaOS v0.2