EU AI Act — Article 14
Human oversight you can demonstrate, not merely assert.
Article 14 requires high-risk AI systems to be designed so that natural persons can effectively oversee them — including the ability to intervene in or halt an operation. In practice that becomes an evidence problem: the question is not whether a person was in the loop, but whether you can show it to someone who does not trust you.
First, the correction
What Article 14 asks for, and what the control leaves behind
The tool call blocks at requireApproval until a human approves it, denies it, or it times out. That is a circuit breaker in the execution path, not an alert raised after the fact — and the distinction is the one Article 14 is about, since oversight that arrives after the transfer has settled is not oversight.
The approval is a signature over the exact parameters the agent proposed. Verification re-derives those bytes from what is about to execute, so the record shows the approver saw this instruction and not a summary of it. One byte of drift fails verification.
The approving human's identity is bound into the signature and kept distinct from the machine that requested the action. requesterType: AI_AGENT with approverType: HUMAN is explicit in the record, and so is the case where policy auto-approved and no person was involved.
Enforcement sits in the gateway the agent connects through, not in a prompt asking the model to behave. Policy is controlled by your organization and encrypted such that INTYGA cannot read it.
Why a log is the weaker answer
Most oversight evidence today is an application log written by the system under review. The party that signed the evidence is the party you would be auditing, which is exactly the position an assessor is trained to distrust.
A client-signed receipt moves the trust anchor. The approver's authenticator produces the signature, the relying party verifies it against parameters it derived itself, and neither step requires an INTYGA secret or an INTYGA API call.
const action = {
target: BILLING_TARGET, // this service — so the approval can't be replayed against another
actionType: "issue_refund",
params: { customerId, amountCents: 480000 }
};
const approval = await intyga.requireApproval("Refund — 4,800.00 EUR", action);
if (approval.status !== "APPROVED") throw new Error("not approved");
// nonce and approvers come from YOUR side — a receipt cannot vouch for its own signer.
const anchor = parseTrustAnchorFile(readFileSync(process.env.INTYGA_APPROVERS_FILE!, "utf8"));
const TRUSTED_APPROVERS = trustAnchorApprovers(anchor); // quorum counts PEOPLE, not keys
const check = verifyApprovalReceipt(approval.receipt!, {
...action, nonce: approval.nonce!, approvers: TRUSTED_APPROVERS,
}, {
expectedOrigin: anchor.webauthn?.origin,
expectedRpId: anchor.webauthn?.rpId,
});
if (!check.ok) throw new Error("receipt mismatch: " + check.reason);
await issueRefund(customerId, 480000);ISO/IEC 42001 A.9.2 — the standard that operationalizes it
Article 14 states an obligation; ISO/IEC 42001 is the AI management system standard an auditor will actually work from, and its Annex A.9.2 governs human oversight directly. The same three controls carry both.
High-risk tool calls hold at require_approval until a human signs or the challenge expires.
Canonical parameter rendering puts the exact JSON the agent proposed in front of the approver, on their own device.
Requester and approver are separate identities by construction; four-eyes policy forbids self-approval.
Start with the agent that worries you most.
You do not need a governance programme to begin. Gate one destructive tool call, verify the receipt yourself, and decide from there whether the evidence is worth having on the rest.
See the other framework mappings →