Compliance frameworks / EU AI Act Article 14
EU AI Act Article 14 — human oversight of high-risk AI systems
This page is generated from the requirement table the AiSSAY engine ships for this framework. When the engine produces an evidence pack, each row below gets a status computed from the operator's own records at that moment. This page shows the table, not anyone's results.
Read this first
Informational mapping prepared by the operator's own tooling. Not a legal opinion, not a certification, and not a substitute for advice of counsel. It organizes the operator's records against the cited requirements; whether those records satisfy the requirements is a determination for the operator, counsel, and the examiner.
The requirement table
9 rows: 9 mechanism
| Requirement | Mechanism, duty or gap | Type |
|---|---|---|
| Oversight measures built into the system, enabling a natural person to oversee its operation | irreversible calls are held mid-run, pattern-classified and scanned for injected instructions, and pend until a policy answer arrives; the hold is recorded in the trace as a decision step | mechanism |
| The person can decide not to use the output, or to disregard, override or reverse it | a held call is released only by an explicit token, and both the hold and the release are separate records; a released call and an overridden one are both in the chain | mechanism |
| The person can intervene or interrupt the system | the agent asks the broker for permission rather than reporting afterwards, so an unanswered request stops the run instead of completing it | mechanism |
| The person is enabled to remain aware of automation bias | the record states what the agent could not verify, what it assumed and where it proceeded through an ambiguity, and flags runs needing review; measured evidence that a model reviewing work presented as its own misses alterations is published | mechanism |
| The person can correctly interpret the system's output | the account is reconciled against the trace and disagreements are surfaced rather than resolved; the record declares which boundaries were instrumented, so a reader knows what it does not cover | mechanism |
| Oversight is exercised by a natural person, not another automated system | human countersigns are counted separately from agent runs throughout, and read attribution distinguishes a signed identity from a name someone typed | mechanism |
| Article 14(1) — oversight measures commensurate with the risks of the system | each run is sealed with the oversight settings it ran under — enforcement mode, what happens when the interlock cannot evaluate a call, whether the irreversible-action patterns loaded. Whether those measures are commensurate for a given deployment is the deployer's assessment, which no software supplies. | mechanism |
| Article 14(4) — the overseeing person has the necessary competence, training and authority | the operator enrols each overseeing person: name, role, the authority they hold, the training claimed for them, the key they sign with, and the name of whoever attested to it — sealed in the chain, revocable, and never self-attested. The pack then says whether the keys that signed reads belong to that roster. Competence itself remains the operator's claim. | mechanism |
| Hold and override counts per run | counted when each run is sealed and kept beside it as integers only: holds, overrides and passes from the in-process gate's decision steps, and holds made by the recording proxy. The reasons, the people and the times stay sealed in the record. A run sealed before counting existed reads "not counted", never zero; the proxy does not record the calls it lets through, so its passes read "not recorded". | mechanism |
How a status is earned
- Evidenced
- a deterministic check ran against your records and the counts support the row. A store holding no relevant records reads unevidenced — a true statement, not a passing one. Empty never counts as clean.
- Delegated
- the mechanism is enforced by a system you already trust — a store sealed by your own key manager delegates access control to it, and the pack says the enforcing log is your key manager's, not ours. The pack names the endpoint the key manager was reached at. An AWS endpoint other than AWS's own default for the region reads delegated to that endpoint, with a request that you confirm it is your key management service. One backend — AWS KMS — has run against the real AWS KMS service; no other backend has.
- Test seam
- sealed by an in-process test backend — a stub, or a stand-in for the AWS client — and the status names which. No key manager enforces access. The seam is built and tested, and the pack refuses to call that delegation.
- Partially evidenced
- the mechanism is built and some of your runs carry its evidence, but not all — usually because they were sealed before the mechanism existed. The pack says how many runs are in each group, and never counts the missing ones as passing.
- Organizational
- the requirement is a procedure only people can perform. The pack names it as yours instead of dressing a policy up as a mechanism.
- Named gap
- the pack cannot evidence it — either the mechanism is not built, or no software can supply it — and it says which. The gap is printed, because a reviewer should read it here rather than discover it.
No status is typed in by hand: every status is recomputed from the store each time a pack is produced, the requirement and mechanism text is written and reviewed as part of the engine, and the dependency evidence comes from our release scan. A failing mechanism can never be read as evidence that the control works.