eu-ai-act-compliance

EU AI Act Compliance — Ecotrans / p24-infra Platform

Last reviewed: 2026-06-28
Next review due: 2027-06-16
Owner: Radek Konarski (p24-infra admin)
Regulation: Regulation (EU) 2024/1689 — the EU Artificial Intelligence Act

---

1. Applicability & Timeline

The EU AI Act applies to any AI system placed on the market or put into service in the EU, including internal deployment.

Date	What applies
2025-02-02	Chapter II — prohibited AI practices (already in force)
2025-08-02	Chapter V — GPAI model obligations (general-purpose AI providers only; we are deployers, not providers)
2026-08-02	Chapter III — Annex III high-risk systems + conformity assessments
2027-08-02	Chapter IV — high-risk AI embedded in Annex I regulated products

2026-08-02 is 47 days away. Any system classified as high-risk must be fully compliant before that date.

As a deployer (not a provider) of general-purpose AI (Claude by Anthropic), our obligations under Article 26 are:

• Use AI systems in accordance with the provider’s instructions
• Ensure human oversight where required
• Monitor operation and report serious incidents to authorities

---

2. Risk Classification Framework

Tier	Definition	Obligations
Prohibited	Systems banned by Chapter II (e.g. social scoring, subliminal manipulation, real-time biometric surveillance in public)	Never deploy
High	Systems listed in Annex III (see §3)	Full compliance: risk mgmt, data governance, technical docs, logging, human oversight, transparency, accuracy
Limited	Chatbots, AI-generated content, emotion recognition in some contexts	Transparency: users must know they are interacting with AI (Art. 52)
Minimal	Everything else	No mandatory obligations; register for completeness

---

3. Annex III — High-Risk Categories Relevant to Our Platform

The following Annex III categories could apply to fleet/logistics and workforce management:

Category	Description	Applies?
III.2(a)	AI managing/operating critical road transport infrastructure	Potentially if managing public road infrastructure — does NOT apply to private fleet management
III.3(a)	AI for education/vocational training	Not applicable
III.4(a)	AI for recruitment or selection of natural persons, evaluating, promoting, terminating workers, allocating tasks, monitoring and evaluating performance	Review required if driver scoring, performance KPI tracking, or task allocation uses AI
III.4(b)	AI for evaluating creditworthiness / credit scoring	Not applicable
III.5(a)	AI used by public authorities in essential private services	Not applicable (private platform)
III.6(a)	AI for law enforcement	Not applicable
III.8(a)	AI for administration of justice	Not applicable

Current verdict: No deployed system is classified as high-risk. This must be re-evaluated if AI is introduced for driver performance scoring, automated task assignment to workers, or any HR decision support.

---

4. Current AI Systems Inventory

All systems are registered in public.dev_r_ai_systems. The table is the authoritative source; this section summarises the current assessment.

p24-infra

System	Service	Risk	Status	Annex III
workbook-designer	audit-engine	minimal	compliant	—
report-generator	audit-engine	minimal	compliant	—
resource-incident-triage	gha/resource-incident-triage	limited	compliant	— (not Annex III — infra telemetry only, no people scoring/allocation)
queue-analyst	queue-infra (bms-4)	limited	compliant	— (not Annex III — internal job-queue telemetry only, no people scoring/allocation)
Daily Session Audit Summariser	daily-session-audit (bms-4)	minimal	compliant	— (not Annex III — internal session transcripts only, no people scoring/allocation)
nightly-devops-triage	nightly-devops-triage (bms-4)	limited	compliant	— (not Annex III — infra/GitHub-issue housekeeping only, no people scoring/allocation)
telegram-claude-interface	telegram-claude-bot (bms-4)	limited	compliant	— (not Annex III — human-controlled remote terminal UI, no people scoring/allocation)
step-0b-planning-phase	p24-worker-queue (bms-4)	limited	compliant	— (not Annex III — internal worker capacity planning, no people scoring/allocation)

resource-incident-triage (#1191): Claude agent dispatched by the n8n resource-incident-analysis workflow on a CPU/RAM pressure alert. It correlates Mezmo logs + live SSH state and takes only documented-playbook-bounded remediation, escalating anything else via the human-action label (human-in-loop). Production-critical targets (WAHA, MongoDB, Pinbox24) are hard-excluded from autonomous action. Logging: GH Actions run logs + issue comments + dev_r_incidents. Activation gated on #1467. Plan/runbook: docs/playbooks/resource-incident-monitoring.md.

nightly-devops-triage (.claude/commands/nightly-devops-triage.md, bms-4 cron 20:00 UTC daily): Claude agent that triages the full open-issue backlog in seven bounded phases — milestone hygiene, merged-PR cleanup, SLA watchdog, infra alert queue (Tier 1/2/3), night-task dev queue, docs/priorities.md status sync, summary. It acts only on GitHub issue/PR metadata and repository infra-doc content — no personal data, no worker/driver scoring, no task allocation to people — so it is not Annex III. Phase 3.5 (#4559) is the first phase to write repository files: it auto-resolves docs/priorities.md rows only under a fail-safe, fixture-tested resolution rule (docs/playbooks/priorities-status-sync.md) and lands changes exclusively via a reviewable PR, never a direct push or auto-merge. Human oversight (Art. 14): every Tier-3/escalation path routes to a human via the human-action label + Telegram, and each phase is independently disableable (Phase 3.5 ships dry-run-only, flip is a one-line PR). Logging (Art. 12): /var/log/nightly-devops-triage.log, per-phase p24_nightly_triage_result Prometheus metric, Discord embeds, GH issue comments. Runbook: docs/playbooks/priorities-status-sync.md (Phase 3.5); other phases documented inline in the skill file.

queue-analyst (#2061): Claude agent on a 30-min systemd timer (bms-4) that diagnoses repeat failures in the developer worker queue (dev_r_worker_queue). It reads only internal job telemetry — queue row, the failing job’s GitHub issue + comments, the agent session summary, the worker log tail, and PR/CI state — and takes a bounded action: requeue, requeue-as-continue, ask for clarification, close-stale, or escalate. It operates exclusively on internal CI/automation metadata: no personal data, no worker/driver scoring, no task allocation to people, so it is not Annex III. Human oversight (Art. 14): every escalation routes to a human via the human-action label, and the timer/service can be disabled at any time without stalling the queue (the retry-worker has a 4-hour bypass). Logging (Art. 12): journalctl -u p24-queue-analyst, the analyst_notes JSONB column, GH issue comments, and Discord embeds. Transparency (Art. 13): AI involvement is disclosed by the ai-analysis-done label and the analyst’s signed issue comment. Runbook: docs/playbooks/queue-analyst-operations.md.

Daily Session Audit Summariser (DSA, #2654, plan #2637): Claude summariser on a daily bms-4 timer that reads finished Claude Code session transcripts (dev_r_agent_sessions where audited_at IS NULL AND ended_at IS NOT NULL), writes a short summary for internal knowledge retention, and stamps audited_at. It processes only internal CI/automation session metadata — no personal data, no worker/driver scoring, no task allocation to people — so it is classified minimal risk under Article 6 (no Annex III high-risk category applies). Human oversight (Art. 14): summaries are advisory only and reviewable, and the timer can be disabled at any time without operational impact. Logging (Art. 12): the audited_at marker column plus the generated summaries. Registered for completeness in dev_r_ai_systems.

telegram-claude-interface (docs/telegram-claude-bot-operations.md): a Telegram bot (n8n on bms-4) that lets the single authorized user (radieu) drive Claude CLI sessions on bms-4 via /status /start /stop /restart /send /log. It is purely a human-controlled remote terminal UI — the human sends every prompt explicitly; no automated decisions, no scoring of persons, no autonomous actions — so no Annex III category applies (human-in-loop). Transparency (Art. 13): AI involvement is inherent to the interface (the user is directly operating Claude). Risk justification recorded in dev_r_ai_systems.

step-0b-planning-phase (docs/queue-dispatcher-operations.md): the worker self-assessment step that reads an issue, generates a design if missing, classifies it SOLO/PARALLEL-N and calls max_subagents_for_weight() to pick a parallelism level. Its output is advisory only — a planning decision that never directly acts on code, and every resulting change lands via a human-reviewed PR — so no Annex III category applies (recommendation-only, no personal data, no people scoring/allocation). Registered in dev_r_ai_systems for completeness.

et-operational-platform

System	Service	Risk	Status	Notes
(none registered)				Register any AI features in the fleet web app — see §7

n8n AI workflows

Any n8n workflow that calls the Claude proxy, OpenAI, or any other AI provider must be registered. Use service_name = 'n8n-bms4' (or 'n8n-hstgr' for Hostinger) and system_name = workflow slug.

Registered as of 2026-06-16 (migration 021 + 023):

System	Service	Risk	Status	Notes
tronik-gps-kierowcy	n8n-bms4	limited	compliant	Art.52 disclosure footer in build_report node (#720 workflow Imgxpl5hYgjSaqd5); risk + GPS data governance in ai-risk-data-governance.md Part C. Not used for worker performance evaluation (#1976). 2026-06-29 (#1947): driver footer was claimed in 2026-06-16 but never actually applied — corrected on the live workflow and repo backup.
tronik-gps-serwisant-mobilny	n8n-bms4	limited	compliant	Same as above for technicians (footer was genuinely present since 2026-06-16; workflow W50qRbJs9xrGotaX)
wa-ai-to-inbox	n8n-bms4	minimal	compliant	No mandatory obligation; Art.52 N/A (no AI reply to users). Claude via SSH→vps-i1 (Haiku) since 2026-06-24 (#1214). Governance in Part C
imap-inbox-ai-classifier	n8n-hstgr	minimal	compliant	No mandatory obligation; email PII governance documented in Part C
ai-documents-inbox-processing	n8n-cloud	minimal	compliant	No mandatory obligation; document PII governance documented in Part C
gmail-tools-daily-inbox-agent	n8n-bms4	minimal	compliant	Added 2026-07-31 (#4724). Daily 07:00 Europe/Warsaw cron → claude -p on bms-4 over the owner’s own radieu@gmail.com inbox (label / archive / digest). Agentic — the model holds Gmail write tools and, via --dangerously-skip-permissions, unrestricted host tools on bms-4, so the prompt-injection control set is documented separately as C-R6 in Part C, whose (b) dimension is assessed elevated and gates activation; email PII governance in Part C. Art.52 N/A — the only recipient of AI-generated text is the inbox owner, who is also the operator. Ships deactivated (see docs/gmail-tools-daily-agent-operations.md §Activation checklist)
gmail-tools-telegram-bot	n8n-bms4	minimal	compliant	Added 2026-08-01 (#4819). On-demand Telegram bot (workflow google-worker-bot, id BBVD0cAN6uuIbcqr) → SSH → claude --allowedTools -p on bms-4 over the owner’s own radieu@gmail.com inbox, triggered by a message from the single authorized owner. Agentic, but ships with --allowedTools from the start (Option A) — the host dimension of C-R6(b) is mitigated at source (no bare Bash/Write), unlike the daily agent’s original --dangerously-skip-permissions; residual host-account exposure is Option B (#4815), out of scope. Input surface is narrower than the daily agent’s (only the authorized owner can trigger it). Art.52 N/A — the sole recipient of AI-generated text is the owner who sent the request. Ships deactivated (see docs/gmail-tools-telegram-bot-operations.md §Activation checklist)
voice-to-text-inspection	telegram-inspection-bot	minimal	compliant	Transcription only; risk + governance in Part C
et-chatbot-produkcja	n8n-hstgr	limited	n/a	WIP — disabled until Art.52 disclosure implemented. Needs an interactive-chat opening disclosure (not a report footer) + ops re-enable decision — tracked in #2100

2026-06-28 (#1976) — partial-status remediation: The seven systems previously at compliance_status = partial were reviewed and moved to compliant. None is high-risk, so no Annex III obligation is triggered; their has_risk_management and has_data_governance records are completed in ai-risk-data-governance.md Part C. A registry-wide review confirmed no system has drifted into high-risk classification (6 minimal / 6 limited / 0 high). The two GPS report systems were explicitly confirmed not used for worker performance evaluation, so they remain limited (not Annex III.4(a)).

---

5. Compliance Requirements by Risk Tier

High-Risk (Annex III) — checklist

Before deploying any high-risk system, all items must be true in dev_r_ai_systems:

Field	Article	Requirement
has_risk_management	Art. 9	Documented risk management system: identify, analyse, evaluate risks; test before deployment
has_data_governance	Art. 10	Data governance practices: training data quality, relevance, bias assessment
has_technical_docs	Art. 11	Technical documentation before market placement; includes architecture, capabilities, limitations
has_logging	Art. 12	Automatic logging of events; retain logs for at least 6 months
has_transparency	Art. 13	Clear information to deployers and affected persons about AI involvement
has_human_oversight	Art. 14	Designated human overseer who can interrupt, override, or shut down the system

Additionally:

• Accuracy, robustness, cybersecurity requirements (Art. 15)
• Register in EU AI Act database if deploying to third parties or in public-interest context (Art. 49)
• Post-market monitoring plan (Art. 72)
• Serious incident reporting to national authority (Art. 73)

Limited-Risk — checklist

Field	Article	Requirement
has_transparency	Art. 52	Disclose to users that they are interacting with an AI system

Minimal-Risk — best practices (not legally required)

• Register in dev_r_ai_systems for visibility
• Set has_logging = true (audit trail)
• Set has_human_oversight = true (ability to override)
• Annual review of classification

---

6. Compliance Status — audit-engine AI systems

Both current systems are minimal risk. No Annex III category applies.

workbook-designer — current gaps

Measure	Status	Notes
Human oversight	✅ yes	Workbooks reviewed; /reoptimize endpoint allows manual override
Logging	✅ yes	Every design attempt in audit.runs
Transparency	✅ yes	Internal team; documented in docs/audit-engine.md
Technical docs	✅ yes	docs/audit-engine.md covers architecture, designer, WorkbookSpec
Risk management	✅ yes	docs/ai-risk-data-governance.md Part A (A.1–A.5): risk register (R-01/R-02), residual-risk verdict, review schedule
Data governance	✅ yes	docs/ai-risk-data-governance.md Part B (B.1–B.8): data inventory, personal-data assessment, retention, access controls

Not legally required at minimal risk, but the habit is established — both docs existed already, this table just hadn’t been updated to reflect it (found 2026-08-01).

report-generator — current gaps

Same status as workbook-designer — covered by the same Part A/B entries in docs/ai-risk-data-governance.md (both systems share the same risk register).

---

7. Registering a New AI System

Before deploying any new AI-powered feature:

1. Classify the risk tier — use §3 Annex III table to check if the system falls into a high-risk category. When in doubt, consult the EU AI Act official text.

2. Insert a row in dev_r_ai_systems:

INSERT INTO public.dev_r_ai_systems (
  project_id, service_name, system_name, description,
  ai_provider, ai_model, purpose, decision_type, affects_people,
  eu_ai_act_risk, annex_iii_category, risk_justification,
  has_human_oversight, has_logging, has_transparency,
  has_technical_docs, has_risk_management, has_data_governance,
  compliance_status, compliance_notes, doc_url, status, last_reviewed
) VALUES (
  'p24-infra',           -- or 'et-operational-platform'
  'service-name',        -- matches dev_r_services.service_name
  'system-slug',         -- short identifier for this AI capability
  'What this AI does.',
  'anthropic',           -- ai_provider
  'claude-sonnet-4-6',   -- ai_model
  'Plain-English purpose.',
  'informational',       -- decision_type
  false,                 -- affects_people
  'minimal',             -- eu_ai_act_risk
  NULL,                  -- annex_iii_category (NULL unless high-risk)
  'Why this classification was chosen.',
  false, false, false, false, false, false,  -- compliance checklist (update to actual values)
  'partial',
  'Notes on what is done and what is missing.',
  'docs/eu-ai-act-compliance.md',
  'active',
  CURRENT_DATE
);

3. For high-risk systems, complete all six compliance checklist items before going live. Create a separate ops doc section covering the risk management system and data governance policy.

4. Update this document — add the system to §4 inventory table and document its compliance status in §6.

---

8. Automated Audit Check

The eu_ai_act_check action runs every Monday at 08:00 UTC via the audit engine.

What it checks:

Rule	Severity	Condition
Prohibited system active	FAIL	eu_ai_act_risk = 'prohibited' and status = 'active'
High-risk: missing oversight	FAIL	eu_ai_act_risk = 'high' and has_human_oversight = false
High-risk: missing logging	FAIL	eu_ai_act_risk = 'high' and has_logging = false
High-risk: missing technical docs	FAIL	eu_ai_act_risk = 'high' and has_technical_docs = false
High-risk: missing risk management	FAIL	eu_ai_act_risk = 'high' and has_risk_management = false
High-risk: missing data governance	WARN	eu_ai_act_risk = 'high' and has_data_governance = false
Limited-risk: missing transparency	FAIL	eu_ai_act_risk = 'limited' and has_transparency = false
Annual review overdue	FAIL	last_reviewed < today - 365 days or last_reviewed IS NULL
High-risk: quarterly review overdue	WARN	eu_ai_act_risk = 'high' and last_reviewed < today - 90 days

Results are recorded in audit.runs. A FAIL triggers the standard error notification (Discord + GitHub issue).

---

9. Annual Review Process

Who: Platform owner (Radek Konarski) or delegated technical lead.
Frequency: All systems annually; high-risk systems quarterly.

Review steps:

1. Query dev_r_ai_systems for all active systems
2. Re-evaluate EU AI Act risk classification — check if Annex III scope has changed, if system use has changed, or if new guidance has been issued
3. Verify each compliance checklist field reflects current state
4. Update last_reviewed = CURRENT_DATE for each reviewed system
5. Update this document’s “Last reviewed” date
6. If any system is newly classified as high-risk, complete the full compliance checklist before the next deployment

---

10. Regulatory References

Document	URL
EU AI Act full text	https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689
Annex III (high-risk categories)	EU AI Act, Annex III
Art. 26 — deployer obligations	EU AI Act, Article 26
EU AI Act database	https://database.euaiact.eu (from 2026-08-02)
National authority (Poland)	Urząd Komunikacji Elektronicznej (UKE) — pending designation

---

11. Incident Reporting

If an AI system causes or contributes to a serious incident (harm to health, safety, or fundamental rights of persons), report to the national supervisory authority within 15 days (Art. 73).

Record all incidents in dev_r_incidents and tag with source = 'eu-ai-act'.