Article 26(6) deployer log retention answer
Deployers of high-risk AI systems must retain the logs the system automatically generates for at least six months, to the extent the deployer controls those logs, and longer where Union or national law requires it. Article 12 is the design-time obligation on the provider to make the system technically capable of automatic logging. Article 26(6) is the runtime obligation on the deployer to keep the logs that result.
The minimum is the floor, not a ceiling. Sector law often sets longer retention windows, and Union data protection law can override the six-month floor in specific cases. Financial institutions subject to internal-governance rules under Union financial services law keep these logs as part of the documentation maintained under that law.
Article 12 vs Article 26(6)
Article 12 is the provider-side record-keeping design duty: a high-risk AI system must be technically capable of automatic event logging. Article 26(6) is the deployer-side retention duty: the deployer keeps the logs under its control for at least six months, unless another applicable law requires a longer or different period.
Pipelock generates runtime evidence for those duties. The deployer still owns retention policy, review workflow, incident sign-off, and legal sufficiency.
| Duty | Who owns it | Minimum retention | Where Pipelock fits |
|---|---|---|---|
| Article 12: automatic event logging | Provider (design-time) | Capability must exist | Pipelock emits structured JSON event logs for every request, decision, and scanner verdict; capability is built in. |
| Article 26(6): keep the logs | Deployer (runtime) | At least 6 months | Pipelock’s flight recorder writes to disk; signed receipts add hash chaining and Ed25519 signatures when receipt signing is enabled. Ship logs to S3, GCS, SIEM, or any retention-controlled store. |
| Article 19: provider log retention | Provider (post-market) | At least 6 months where logs are under provider control | Same pipeline; the provider’s retention store is separate from the deployer’s. |
| Article 26(5): monitoring + reporting risks and incidents | Deployer (runtime) | Continuous | Pipelock health endpoint, kill switch, structured logs surface incident triggers in real time. |
| Sector law and data protection overrides | Deployer (runtime) | Longer or otherwise adjusted when applicable | Same pipeline; configure retention to match the longest applicable rule. |
Below: how each runtime article (9, 12, 14, 15, 26) maps to specific Pipelock controls, with audit-log shapes, configuration examples, and the August 2, 2026 enforcement timeline as it stands under the current text. A 7 May 2026 provisional Omnibus agreement, if formally adopted, would extend the stand-alone high-risk date to 2 December 2027 and the safety-component date to 2 August 2028. Track the formal adoption at the Council press release.
Background
Under the current text of Regulation (EU) 2024/1689, the EU AI Act’s high-risk requirements take effect August 2, 2026 with penalties up to EUR 15 million or 3% of global annual turnover, whichever is higher. A 7 May 2026 provisional Omnibus VII agreement between the Council presidency and European Parliament negotiators would, if formally adopted, extend the high-risk dates to 2 December 2027 for stand-alone systems and 2 August 2028 for systems embedded in products. The provisional agreement awaits Council and Parliament endorsement and legal-linguistic revision. Industry estimates put conformity assessment at 8 to 14 months as of April 2026. Article 26 sets twelve paragraphs of deployer duty. This page covers the runtime-facing ones (paragraphs 1, 2, 4, 5, 6) and links them to specific Pipelock controls.
Most compliance tools focus on model governance (training data, bias, documentation). None of them cover what happens when your AI agent makes HTTP requests, calls MCP tools, or tries to exfiltrate secrets at runtime.
Pipelock fills that gap. It sits between your AI agent and the network. MCP proxy mode scans tool arguments and responses bidirectionally. Fetch proxy mode scans fetched response content and URL parameters. Forward proxy mode (CONNECT) filters by hostname, with optional TLS interception for full body inspection. The controls it enforces map directly to EU AI Act articles.
What Gets Enforced (current text)
| Article | Requirement | Penalty |
|---|---|---|
| Art. 9 | Risk management system (continuous, iterative) | Up to EUR 15M or 3% turnover |
| Art. 12 | Automatic event logging for traceability | Up to EUR 15M or 3% turnover |
| Art. 14 | Human oversight with override and stop capability | Up to EUR 15M or 3% turnover |
| Art. 15 | Cybersecurity, resilience, fail-safe mechanisms | Up to EUR 15M or 3% turnover |
| Art. 26 | Deployer monitoring and 6-month log retention | Up to EUR 15M or 3% turnover |
Industry estimates put conformity assessment at 8-14 months. If you haven’t started planning, now is the time.
How Pipelock Maps to Each Article
Article 9: Risk Management
Article 9 requires identifying, analyzing, and mitigating risks through design and continuous monitoring.
Pipelock’s architecture is the mitigation: capability separation. The agent holds secrets but has no network access. The proxy has network access but no secrets. This eliminates network-based credential exfiltration by design, not by policy.
On top of that, the 11-layer scanner pipeline classifies risks at runtime:
| Scanner Layer | Risk Category |
|---|---|
| Domain blocklist | Known malicious destinations |
| DLP (65 credential patterns) | Secret exfiltration |
| SSRF protection | Internal infrastructure probing |
| Rate limiting | Abuse and resource exhaustion |
| Entropy analysis | Encoded or obfuscated data exfiltration |
| MCP scanning | Tool poisoning and injection |
Every scan decision is logged. Every threshold is configurable. Hot-reload (fsnotify + SIGHUP) lets you update policies without restarting.
Article 12: Record-Keeping
Article 12 requires automatic event logging that identifies risk situations and supports post-market monitoring.
Pipelock logs every request as structured JSON. Event shapes vary by type:
{
"event": "blocked",
"method": "GET",
"url": "https://api.example.com/data",
"scanner": "dlp",
"reason": "dlp_aws_access_key",
"client_ip": "127.0.0.1",
"request_id": "abc123"
}
Blocked events include scanner and reason. Allowed events add status code, size, and duration. Forward logs to your SIEM via webhook or syslog (both built in). Prometheus metrics (/metrics) and a ready-to-import Grafana dashboard provide real-time monitoring.
In multi-agent deployments, run separate pipelock instances per agent with distinct log files for per-agent traceability.
Article 14: Human Oversight
Article 14 requires the ability to understand system operation, detect anomalies, override outputs, and intervene with a “stop button.”
Pipelock provides four mechanisms:
HITL approval (
action: ask): flagged requests pause the agent and present a terminal prompt. The operator approves, denies, or strips sensitive content. Timeout defaults to deny (fail-closed).Kill switch: six independent activation sources. Any one active blocks all traffic. The API runs on a dedicated port so agents cannot self-deactivate.
Config modes:
audit(log only),balanced(default),strict(aggressive blocking). Map directly to different risk tolerances per Art. 14(3).Prometheus + Grafana: real-time visibility into what agents are doing, which requests are blocked, and why.
Article 15: Cybersecurity and Resilience
Article 15 requires protection against unauthorized alteration, adversarial attacks, confidentiality breaches, and fail-safe behavior.
| Art. 15 Requirement | Pipelock Control |
|---|---|
| Adversarial examples (Art. 15(5)) | Content scanning with NFKC normalization, zero-width stripping, case-insensitive matching |
| Confidentiality attacks (Art. 15(5)) | DLP scanning (65 credential patterns), env leak detection (raw + base64 + hex), entropy analysis |
| Data poisoning (Art. 15(5)) | File integrity monitoring (SHA256 manifests), Ed25519 signing, response injection scanning |
| Unauthorized alteration (Art. 15(5)) | Capability separation prevents agent manipulation into exfiltrating data |
| Fail-safe mechanisms (Art. 15(4)) | Fail-closed architecture: scan error, HITL timeout, parse failure, DNS error all default to block |
| Resilience to faults (Art. 15(4)) | DNS rebinding protection, IPv4-mapped IPv6 normalization, TLS interception with cert cache |
Article 26: Deployer Obligations and 6-Month Log Retention
Article 26 sets out the deployer’s runtime duties for high-risk AI systems. This section focuses on the duties most relevant to AI agents in production. It is not a complete legal summary. Additional duties in Article 26 apply conditionally (workplace notice, public-authority registration, GDPR DPIA linkage, law-enforcement biometric ID rules, notice to natural persons, authority cooperation), and other articles cover provider-side and lifecycle obligations. Read the official OJ text and get qualified legal advice before treating any single page as a compliance checklist.
Runtime-facing deployer duties under Article 26:
- Art. 26(1). Take appropriate technical and organisational measures to use the system in accordance with the provider’s instructions for use.
- Art. 26(2). Assign human oversight to natural persons with the necessary competence, training, authority, and support.
- Art. 26(4). Ensure input data is relevant and sufficiently representative of the intended purpose, to the extent the deployer controls the input.
- Art. 26(5). Monitor the system’s operation based on the instructions for use. Inform the provider (and, for serious incidents or identified risks, the market surveillance authority) without undue delay. Financial institutions subject to internal-governance rules under Union financial services law can satisfy this monitoring duty by complying with those rules.
- Art. 26(6). Keep the logs automatically generated by the system for at least 6 months, to the extent those logs are under the deployer’s control. Longer retention applies where other Union or national law requires it, in particular data protection law. Financial institutions maintain logs under their applicable financial services law documentation rules.
Provider-side design obligation (Article 12). Article 12 requires high-risk AI systems to be designed with the technical capability to automatically record events (logs) throughout their lifecycle. Article 12 is about the system being capable of logging; the deployer’s duty to actually keep those logs for 6 months is Article 26(6). Keeping the two articles straight matters because they sit on different parties (provider vs. deployer).
What runtime tooling often misses: Article 26(5) operation monitoring and Article 26(6) log retention. Many AI governance tools focus on training-time concerns (data governance, bias assessment, model documentation). They don’t see what the agent does at 2am when it calls an MCP tool or hits an API.
What Pipelock provides toward these duties:
Pipelock provides the evidence source, not the compliance program. It records runtime decisions, emits metrics, and can sign receipt chains when a signing key is configured. The deployer decides where logs live, how long they stay, who reviews them, and who signs off.
| Deployer duty | Pipelock contribution | Deployer still owns |
|---|---|---|
| Art. 26(5) monitoring | Prometheus metrics at /metrics, /health and /ready endpoints, structured JSON audit log for every request, hardcoded event severity taxonomy, configurable min_severity emission threshold, webhook + syslog sinks to SIEM | Choosing which events meet “serious incident” threshold for provider/authority notification, defining escalation runbooks, operating the SIEM |
| Art. 26(6) log content | Structured JSON lines with stable field names (URL, method, scanner, reason, client IP, session ID, timestamp), queryable with standard tools, exportable in any direction, no vendor-locked binary format | The 6-month retention period itself. Pipelock emits logs to the sinks you configure; it does not enforce storage duration. Ship logs to S3 with Object Lock, Loki with retention policy, Splunk, or an equivalent long-term store set to at least 6 months. |
| Art. 26(1) instruction-compliant use | Deployment guidance in docs/deployment.md, posture-verify CLI with score model and CI gate, configuration validation at startup | Operating within the documented deployment profile, training staff on approved configurations |
A minimal emit configuration:
emit:
sinks:
- type: webhook
url: https://logs.example.invalid/ingest
min_severity: info
- type: syslog
address: syslog.example.invalid:514
protocol: udp
min_severity: info
Pair with S3 Object Lock, Loki retention policy, or SIEM lifecycle rules set to at least 6 months. The logs are a product output; the retention period is your deployment decision.
Download the 2-page Article 26 matrix (PDF): obligations, Pipelock evidence, deployer-owned gaps, sample retention setup, and a caveat on the 7 May 2026 provisional Omnibus agreement that would extend the high-risk dates if formally adopted. Procurement, audit, and legal-friendly.
What Pipelock Does NOT Cover
Pipelock is a runtime network security layer. It does not cover:
- Training data governance (Art. 10): Pipelock operates at runtime, not training time
- Conformity assessment (Art. 43): organizational process, not a tool feature
- Bias and fairness evaluation (Art. 10(2)): Pipelock applies rules uniformly but doesn’t evaluate model fairness
- Full system documentation (Art. 11): Pipelock documents itself; full system docs are the deployer’s responsibility
- Fundamental rights impact assessment (Art. 27): requires organizational assessment
Pipelock is one component of a compliance stack. Use it alongside model governance tools (Credo AI, Holistic AI) and organizational processes.
NIST AI RMF Crosswalk
Pipelock’s controls also map to the NIST AI Risk Management Framework 1.0:
| NIST Function | Pipelock Features | EU AI Act Cross-Reference |
|---|---|---|
| GOVERN | Capability separation, fail-closed design, per-instance isolation | Art. 9, 14 |
| MAP | 11-layer risk classification, config presets for risk tolerance | Art. 9 |
| MEASURE | Prometheus metrics, structured audit logs, alerting | Art. 12, 15 |
| MANAGE | HITL override, kill switch, hot-reload, MCP scanning | Art. 14, 15 |
The full mapping with subcategory-level detail is in the EU AI Act Compliance Mapping document.
Enforcement Timeline
| Date | Milestone | Status |
|---|---|---|
| August 1, 2024 | EU AI Act enters into force | In force |
| February 2, 2025 | Prohibited AI practices (Art. 5) take effect | In force |
| August 2, 2025 | General-purpose AI model obligations (Art. 51-55) take effect | In force |
| August 2, 2026 | High-risk AI system requirements take effect (Art. 9, 12-15, 26) | Current text |
| August 2, 2027 | Extended transition for safety-component AI (Art. 6(1)) | Current text |
| 2 December 2027 | Stand-alone high-risk dates under provisional Omnibus VII | Provisional (7 May 2026) |
| 2 August 2028 | Embedded-in-products high-risk dates under provisional Omnibus VII | Provisional (7 May 2026) |
The 7 May 2026 provisional Omnibus VII agreement between the Council presidency and European Parliament negotiators awaits formal endorsement and legal-linguistic revision before adoption. Plan to the earlier (current-text) dates and re-plan once the formal text lands.
Penalties: up to EUR 35M or 7% global turnover (prohibited practices), EUR 15M or 3% (high-risk violations), EUR 7.5M or 1% (misleading information). SME and startup fines are capped at the lower of percentage or absolute amount.
Get Started
# Install
go install github.com/luckyPipewrench/pipelock/cmd/pipelock@latest
# Homebrew alternative on macOS/Linux: brew install luckyPipewrench/tap/pipelock
# Generate a config
pipelock generate config --preset balanced > pipelock.yaml
# Enable audit logging + run
pipelock run --config pipelock.yaml
Set HTTPS_PROXY=http://127.0.0.1:8888 on your agent. Every connection is now logged and filtered. Enable TLS interception for full HTTPS body scanning.
For the full compliance mapping with NIST crosswalk, see the source document on GitHub.
Generate signed compliance evidence for your deployment with pipelock assess.
Further reading
- AI Agent Regulatory Controls Hub: framework-by-framework cross-reference across EU AI Act, DORA, NIS2, NIST AI RMF, ISO 42001, the Colorado AI Act (June 30, 2026 effective date per SB25B-004), SOC 2, and OWASP.
- What did my agent do?: single-decision walkthrough with a real signed Article 12 - shaped receipt and a verifier you can run offline.
- EU AI Act Runtime Security: A Field Guide: the runtime control mapping in narrative form, with prEN 18282 context.
- Compliance Evidence: signed assessment bundles for audit.
- Compliance Evidence Substrate: procurement, audit, and legal framing of Pipelock as evidence substrate inside an existing program.
- AI Agent Compliance: the broader compliance landscape across SOC 2, ISO 27001, and NIST AI RMF.
- OWASP MCP Top 10 Coverage: runtime defenses mapped to the community threat list.
- Agent Firewall: the architecture pattern Articles 9 and 15 lean on.