Skip to content

Compliance EU AI Act

Jump to bottom
LoopGlitch26 edited this page Oct 20, 2026 · 1 revision

EU AI Act

Not legal advice, and not a statement that Tracekit meets any article (about these pages).

Scope

The AI Act, Regulation (EU) 2024/1689, sets rules for AI systems placed on the market, put into service or used in the EU. What it asks of you depends on your role and on the system. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name; a deployer uses an AI system under its authority (Art. 3(3) and 3(4)). Every article mapped below applies only to high-risk AI systems: products, or safety components of products, under the Union law listed in Annex I that need a third-party conformity assessment, and systems used in the areas listed in Annex III, with the exceptions in Art. 6(3) (Art. 6). An agent isn't high-risk because it is an agent: that depends on its intended purpose. The Act entered into force on 1 August 2024 and applies from 2 August 2026, with exceptions. Regulation (EU) 2026/1744 (the Digital Omnibus on AI, in force since 27 July 2026) changed when the high-risk rules of Chapter III, Sections 1 to 3 (Articles 6 to 27) apply: with the exception of Article 6(5), from 2 December 2027 to Annex III systems, and from 2 August 2028 to Annex I systems (Art. 113, third paragraph, point (c), as amended). Articles 50, 72 and 73 are outside those sections; when they apply to your system is a question for your counsel. Each row says whether the duty falls on the provider or the deployer. A provider can build Tracekit into an agent as part of its logging; a deployer that runs the signer holds the logs.

Mapping

Requirement What Tracekit provides Evidence to show Your responsibility / limits
Art. 9(2)(c)–(d), 9(5) (provider). The risk management system evaluates risks using post-market monitoring data and adopts targeted measures, so that residual risk is acceptable; risks that can't be eliminated get mitigation and control measures. A control for one kind of risk: what an agent does with its tools. The signer decides each tool call against a policy before it runs: deny, hold for a person (ask), flag or allow (policy). Detection rules look across calls (experimental, policy). The records are data for evaluating risks. The policy file and its policy_hash, carried by every policy.decision; denied, held and flagged calls by rule id; tracekit policy backtest (experimental), which replays a policy's detection rules over recorded runs, not its deny and ask rules. Identifying and evaluating risks, choosing measures, judging residual risk, and testing (Art. 9(6)–(8)). Rules match text: they are tripwires a determined agent can reword around (limits). Only calls routed through Tracekit are decided.
Art. 12(1) (provider, by design). The high-risk system technically allows the automatic recording of events (logs) over its lifetime. Automatic records of the agent's tool calls, decisions, approvals and results, and, through the LLM gateway (experimental), its model exchanges. The signer writes them as the calls happen, signs each one and chains it to the one before; the agent writes no part of the log (format v2). A run's bundle: run.registered (agent, caller identity, isolation), the run's records, run.final with its coverage; the verify report. Logging for the system as a whole. Tracekit records what crosses its capture path, tool and model calls: not the model's internals, the system's other components, or actions outside the capture path (guarantees). In dev mode the agent could rewrite the log.
Art. 12(2)(a)–(c) (provider). Logging records events relevant for identifying situations that may lead to the system presenting a risk or to a substantial modification, for post-market monitoring (Art. 72) and for monitoring its operation (Art. 26(5)). Each decision names the rules that matched and the policy that decided (policy_hash), so held, denied and flagged calls and policy changes are records. So are signed gaps: an outage, a call that ran against its decision, a call one capture layer saw and another didn't (verdicts). Report lines policy, gaps, coverage, coverage matrix and fail-open classes; decisions by rule id. Deciding which events matter for your system's risks, and writing rules for them. Tracekit doesn't detect a substantial modification of the model or the system.
Art. 13(3)(f) (provider). The instructions for use describe, where relevant, the mechanisms that let deployers collect, store and interpret the logs. Public specifications to cite: the evidence format, reading a verify report and the auditor guide. Your instructions for use, referring to them. Writing the instructions for use.
Art. 14(1), 14(4)(a) (provider designs; deployer assigns, Art. 26(2)). Natural persons can oversee the system effectively, monitor its operation, and detect anomalies, dysfunctions and unexpected performance. tracekit view shows each run verified, with its blocked and held calls, approvals and gaps (stable, viewer). Detection sequences and limits open signed incidents and can notify a webhook (experimental, incidents). incident.opened records; OCSF webhook deliveries (webhooks). The viewer is an operator-side view, not evidence. Who oversees, with what competence and authority (Art. 26(2)), and acting on what they see. Detection catches the patterns it describes, nothing else (limits).
Art. 14(4)(d) (provider, by design; the deployer's people use it). The people overseeing can decide not to use the system, or disregard, override or reverse its output. An ask rule holds a tool call until a person answers. The approval is bound to the call's exact arguments and consumed once; edited arguments, a replayed approval or another run's approval are refused, and the refusal is signed (approvals). A signer started from signer.yaml refuses the requester's own answer unless configured to allow it (approvals). Command-line approvals are stable. approval.request; approval with the approver's identity, channel, reason, self_approved and break_glass; approval.consumed; signed refusals. Report lines break-glass approvals and approvals: self; when a bundle also holds an agent approver's answer, the report counts approvals on separate approvals by people and approvals by agents lines. Choosing which calls need a person, and the people. Only calls that pass through Tracekit and match an ask rule are held. A T1 approval binds the arguments the agent reported, and the agent's process runs the call; the tool executor (experimental) runs exactly the approved arguments outside the agent. The dev signer lets the requester approve its own call (approvals: self, assurance capped at dev). Undoing an action already taken is outside Tracekit.
Art. 14(4)(e) (provider, by design; the deployer's people use it). The people overseeing can intervene in the system's operation or interrupt it through a "stop" button or a similar procedure that brings it to a halt in a safe state. Containment (experimental): an operator holds or quarantines a run, or suspends an identity, with tracekit signer incidents. A quarantine denies every further call for good, and a gateway forwards no further model request; respond rules do the same on a trigger (incidents). With the signer unreachable, tool classes fail closed by default: calls are blocked (stable, FAQ). incident.opened with trigger operator, run.held, run.quarantined, identity.suspension; the verifier's incidents line checks that each response was honoured. The stop procedure, and what a safe state is for your system. A hold or quarantine is enforced only where the signer decides each step (a gateway's model loop, an executor's tools); a T1 adapter that ignores a decision can still run the call (limits). Tracekit doesn't stop the agent's process.
Art. 15(4) (provider). The system is as resilient as possible to errors, faults and inconsistencies; backup or fail-safe plans may provide robustness. For recording and gating: fail closed by default when the signer is unreachable; an outage the client recovers from becomes a signed gap; every class set to fail open is listed in the report (FAQ). The fail-open classes line; client_counter_gap and signer_unavailable gaps. The robustness of the AI system itself. Tracekit's fail modes decide whether calls are recorded and gated, not whether the system's outputs are right.
Art. 15(5) (provider). The system resists attempts by unauthorised third parties to alter its use, outputs or performance by exploiting vulnerabilities; AI-specific measures address data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws. Against injected instructions that become tool calls: the packs deny or hold risky calls, such as the cloud metadata service, secrets in arguments, destructive SQL, internal addresses and IAM changes (packs). Provenance rules (experimental) hold an email, payment or upload whose target only untrusted content brought into the run (policy). An edited record fails verification. Denied and held calls by rule id (TK-S001, TK-P001, ...); the provenance field of decisions; the verify report. Securing the model and the system. Tracekit doesn't address data or model poisoning, adversarial examples or model flaws. Rules are tripwires; provenance matches values verbatim, so a paraphrased value gets past it (limits).
Art. 16(e), 19(1) (provider) and Art. 26(6) (deployer). Keep the automatically generated logs, to the extent they are under your control, for a period appropriate to the intended purpose and at least six months, unless other Union or national law provides otherwise. Financial institutions keep them as part of their financial services documentation (Art. 19(2), 26(6)). An append-only log: the signer never deletes records. Only the optional content vault deletes content: on its retention setting, or on request with tracekit signer content erase, each erasure a signed content.erased; records and commitments stay, and bundles still verify (privacy). Old bundles keep verifying: formats only grow and each format's verifier is frozen (FAQ). A run-set bundle shows that no run of a tenant was left out. Run and run-set bundles; run-set: COMPLETE in the report. Keeping the store and the bundles for the period the law sets, backups, disposal, and data protection law: records name approvers and principals, and show when people and agents acted. Tamper evidence isn't retention: a deleted store is gone. Whose control the logs are under follows from who runs the signer.
Art. 17(1)(d), (h), (i), (k) (provider). The quality management system covers test and validation procedures, post-market monitoring, serious incident reporting, and record-keeping of documentation. Records, bundles and verify reports those procedures can use and keep. Your procedures, referring to the bundles and reports they keep. The quality management system itself. Tracekit isn't one. A provider that is a financial institution subject to Union financial services law meets the QMS obligation, except points (g), (h) and (i), by complying with its internal governance rules under that law (Art. 17(4)).
Art. 26(1)–(2) (deployer). Use the system according to its instructions for use; assign human oversight to natural persons with the necessary competence, training, authority and support. signer.yaml names who may answer approvals (approvers), who may answer any approval with a reason (break_glass), and which identities are one person across channels (persons); the signer enforces them. System mode refuses to install without an approver, or with the agent's own user as one (approvals). The approvals section of signer.yaml; approver identities on approval records; the break-glass approvals line. Choosing and training the people, and giving them authority. An approver who answers through the web viewer or Slack (experimental) is vouched for by that bridge, recorded attested: false (limits).
Art. 26(5) (deployer). Monitor the system's operation on the basis of the instructions for use. On reason to consider it presents a risk, inform the provider or distributor and the market surveillance authority, and suspend use; on a serious incident, inform the provider first, then the importer or distributor and the authorities. Monitoring data: the viewer, the records, detection (experimental). Suspension: quarantine runs and suspend identities (experimental). Incident webhooks deliver at least once to a SIEM (experimental, webhooks). Bundles to hand to the provider or an authority. incident.*, run.quarantined and identity.suspension records; bundles of the affected runs. The monitoring procedure; deciding whether there is a risk or a serious incident; informing the provider and the authorities on time. Tracekit notifies no one outside your own systems. A deployer that is a financial institution subject to Union financial services law meets the monitoring obligation by complying with its internal governance rules under that law (Art. 26(5), second subparagraph).
Art. 72(1)–(2) (provider). A post-market monitoring system collects, documents and analyses data on the system's performance, including data deployers provide, and, where relevant, its interaction with other AI systems. Bundles and verify reports that a deployer can hand to a provider, and that the provider can check without trusting the deployer. Per run: denied, held and flagged calls, gaps and unreconciled calls. A run started by another run (a sub-agent's) is linked to it (parent_run, format v2). Bundles; verify reports (--json). The post-market monitoring plan and its analysis; agreements with deployers to share evidence.
Art. 73(1)–(4), 73(6) (provider; a deployer that can't reach the provider, by Art. 26(5)). Report a serious incident to the market surveillance authorities immediately once a causal link (or its reasonable likelihood) is established, and no later than 15 days after becoming aware of it; 2 days for a widespread infringement or an Art. 3(49)(b) incident, 10 days for a death (Art. 73(2)–(4)); investigate without altering the system in a way that may affect evaluating the causes, before informing the authorities. A fixed record of what the agent did before and during the incident, which you export and verify offline without touching the running system. With the content vault on (experimental), the content for the investigation, each read recorded as content.accessed. tracekit why (experimental) finds which input caused an action by replaying the run without it (why). Bundles of the affected runs, exported soon after; verify reports; content.accessed and why.finding records. Deciding what is a serious incident, reporting it on time, and the investigation. A bundle doesn't prove intent, or that every action was captured (FAQ).

Not covered by Tracekit

  • Data and data governance (Art. 10). Training, validation and test data are out of scope.
  • Technical documentation and its keeping (Art. 11, 18), conformity assessment, the EU declaration of conformity, CE marking and registration (Art. 43, 47, 48, 49).
  • Accuracy and robustness levels (Art. 15(1)–(3)). Tracekit doesn't measure a model.
  • The minimum logs for remote biometric identification (Art. 12(3)) and the two-person check (Art. 14(5)). Each approval has one approver; Tracekit has no two-person rule.
  • Transparency obligations (Art. 50). Telling people they are interacting with an AI system, and marking generated content.
  • General-purpose AI model obligations (Art. 53, 55). They fall on model providers.
  • Prohibited practices (Art. 5), AI literacy (Art. 4) and the fundamental rights impact assessment (Art. 27).

Sources

Checked on 2026-10-18.

Generated from docs/ at v1.4.1. Edit the docs in the repository, not here.

Home

Get started

How it works

Integrations

Policy and approvals

Deploy and operate

Verify the evidence

Security and privacy

Compliance

Evaluation

Demos

Help

Clone this wiki locally