p24-infra Docs

eu-ai-act-compliance

23 min read

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.

DateWhat applies
2025-02-02Chapter II — prohibited AI practices (already in force)
2025-08-02Chapter V — GPAI model obligations (general-purpose AI providers only; we are deployers, not providers)
2026-08-02Chapter III — Annex III high-risk systems + conformity assessments
2027-08-02Chapter 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

TierDefinitionObligations
ProhibitedSystems banned by Chapter II (e.g. social scoring, subliminal manipulation, real-time biometric surveillance in public)Never deploy
HighSystems listed in Annex III (see §3)Full compliance: risk mgmt, data governance, technical docs, logging, human oversight, transparency, accuracy
LimitedChatbots, AI-generated content, emotion recognition in some contextsTransparency: users must know they are interacting with AI (Art. 52)
MinimalEverything elseNo 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:

CategoryDescriptionApplies?
III.2(a)AI managing/operating critical road transport infrastructurePotentially if managing public road infrastructure — does NOT apply to private fleet management
III.3(a)AI for education/vocational trainingNot applicable
III.4(a)AI for recruitment or selection of natural persons, evaluating, promoting, terminating workers, allocating tasks, monitoring and evaluating performanceReview required if driver scoring, performance KPI tracking, or task allocation uses AI
III.4(b)AI for evaluating creditworthiness / credit scoringNot applicable
III.5(a)AI used by public authorities in essential private servicesNot applicable (private platform)
III.6(a)AI for law enforcementNot applicable
III.8(a)AI for administration of justiceNot 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

SystemServiceRiskStatusAnnex III
workbook-designeraudit-engineminimalcompliant—
report-generatoraudit-engineminimalcompliant—
resource-incident-triagegha/resource-incident-triagelimitedcompliant— (not Annex III — infra telemetry only, no people scoring/allocation)
queue-analystqueue-infra (bms-4)limitedcompliant— (not Annex III — internal job-queue telemetry only, no people scoring/allocation)
Daily Session Audit Summariserdaily-session-audit (bms-4)minimalcompliant— (not Annex III — internal session transcripts only, no people scoring/allocation)
nightly-devops-triagenightly-devops-triage (bms-4)limitedcompliant— (not Annex III — infra/GitHub-issue housekeeping only, no people scoring/allocation)
telegram-claude-interfacetelegram-claude-bot (bms-4)limitedcompliant— (not Annex III — human-controlled remote terminal UI, no people scoring/allocation)
telegram-claude-orchestratorclaude-session-manager (bms-4)limitedpartial— (not Annex III — user-initiated Claude session orchestration, no people scoring/allocation)
step-0b-planning-phasep24-worker-queue (bms-4)limitedcompliant— (not Annex III — internal worker capacity planning, no people scoring/allocation)
council-judge-reviewreview-council-judgelimitedcompliant— (not Annex III — reviews code/plan/PR-diff content only, no personal data, no people scoring/allocation)
ecodriving-per-route-anomalyatrax-ecodriving-anomaly-daily (bms-4)limitedcompliantIII.4(a) adjacent — evaluates a named driver’s driving style, but advisory-only guardrail keeps it out of high-risk (never an automated employment decision). #7153: triage moved to the escalation panel; still advisory/limited
route-consumption-anomalyatrax-route-anomaly-daily (bms-4)limitedcompliantIII.4(a) adjacent — driver_pattern attribution evaluates a named driver’s behaviour, but advisory-only (rule-based stats, not ML); never an automated employment decision. Registered #7153 (plan-7107 §4)
vehicle-health-voltageatrax-vehicle-health-daily (bms-4)minimalcompliant— (NOT Annex III — about the vehicle asset (battery/alternator), no driver, affects_people=false). Registered #7153
tachograph-complianceatrax-tachograph-compliance-daily (bms-4)limitedcompliantIII.4(a) adjacent — inherently per-driver (regulatory compliance), but advisory/investigatory only (rule-based on legal limits, requires_human_review=true on every escalation). Registered #7153 (reverses the #7045 deferral)
driver-pairwise-fuel-comparisonatrax-driver-pairwise-fuel-compute (bms-4)limitedcompliantIII.4(a) adjacent — ranks named drivers by fuel consumption on identical (vehicle, route) pairs, but advisory/informational only (rule-based median/MAD, not ML); deliberately not an escalation, never feeds p24_fleet_anomaly_escalations, never an automated employment decision. Registered #7277
dispo-document-classificationdispo-classify-backfill (bms-4)minimalcompliant— (not Annex III — one-off gpt-4o classification of freight business documents into kategoria/kontrahent; output advisory for a human reviewer in the Dispo UI, no decision about a natural person, no worker/driver scoring/allocation). Registered #7679

Atrax fleet-anomaly detectors — audit completed #7153 (plan-7107 §4). All four Atrax detectors now escalate into the shared p24_fleet_anomaly_escalations table (a human-triaged panel in et-operational-platform), and the dev_r_ai_systems audit that PR-1 completes registers the three that were previously missing. route-consumption-anomaly (#6194/#6710) and tachograph-compliance (#7045) are limited and advisory/investigatory only: both are adjacent to Annex III.4(a) (they concern named drivers) but neither uses AI to make/automate any employment decision — every finding is human-interpreted and every driver_pattern / tachograph escalation row carries requires_human_review=true, which the panel honours by blocking bulk/auto resolution. Both are rule-based (median/MAD + fixed thresholds; legal limits for tachograph), not ML. Wiring either into an automated employment decision requires a fresh conformity assessment first. vehicle-health-voltage (#7044) is minimal and affects_people=false: it monitors a vehicle asset (battery/alternator voltage), carries no driver attribution, and is explicitly assessed as out of Annex III scope. The ecodriving-per-route-anomaly classification is unchanged by the panel move (still limited/advisory); its dev_r_ai_systems row was revised only to record the new triage surface. Ops doc: docs/atrax-fleet-anomaly-escalation-operations.md.

ecodriving-per-route-anomaly (#6848; Etap 2 Branch A of design #6841): nightly rule-based statistics (scripts/nightly-etl/atrax_ecodriving_anomaly_daily.py) that reads p24_ride_events, derives harsh-accel / harsh-brake / high-RPM / speeding signals from consecutive-event telemetry deltas, and flags modified-Z / MAD deviations of a per-route harsh-events-per-km metric into p24_ecodriving_anomalies, with leave-one-driver-out driver_pattern attribution. This is the first p24-infra analytic that evaluates a named driver’s performance (Atrax entries carry driverNameAndSurname), so it sits adjacent to Annex III.4(a) (“monitoring and evaluating the performance of workers”). It is nonetheless classified limited (not high-risk, annex_iii_category NULL) because the Annex III trigger is using AI to make or automate an employment decision — discipline, ranking, task allocation — and this analytic does none of that: it is advisory/investigatory only, a human interprets every finding, and the output is never wired into any automated disciplinary/performance/allocation system. That advisory-only guardrail — the same one p24_route_consumption_anomalies’ driver_pattern attribution carries (docs/atrax-route-norm-control-operations.md §EU AI Act) — is exactly what keeps it out of the high-risk tier. Wiring this output into any automated employment decision requires a fresh conformity assessment first. It is rule-based statistics (median/MAD + fixed thresholds), not ML — ai_provider='none (rule-based statistics)'. Human oversight (Art. 14): findings are advisory GitHub/dashboard signals only. Logging (Art. 12): p24_ecodriving_anomalies rows + the nightly ETL logs + Discord/GH error notifications. Transparency (Art. 13): this entry + the ops doc EU AI Act section. Ops doc: docs/atrax-ecodriving-per-route-control-operations.md.

driver-pairwise-fuel-comparison (#7277): nightly rule-based statistics (scripts/nightly-etl/atrax_driver_pairwise_fuel_compute.py) that reads the driver-level median l/100km rows already computed by the route-consumption control into p24_route_consumption_norm (≥ DRIVER_SLICE_MIN=5 trips), groups them by (vehicle, route), keeps groups with ≥ 2 distinct drivers, and ranks the drivers by median fuel consumption — recording per driver the gap to the best driver (delta l/100km, percent, and a modified-Z of the median vs the best driver’s distribution, i.e. the other driver as baseline rather than the all-drivers aggregate) into p24_driver_pairwise_fuel_comparison. This is the most direct per-driver ranking in the fleet analytics — it evaluates a named driver’s relative fuel performance — so it sits adjacent to Annex III.4(a) (“monitoring and evaluating the performance of workers”). It is nonetheless classified limited (not high-risk, annex_iii_category NULL) because the Annex III trigger is using AI to make or automate an employment decision — discipline, ranking-for-action, task allocation — and this analytic does none of that: it is advisory/informational only (a pilot KPI), a human interprets the comparison, and — per issue #7277 point 2 — it is deliberately not an escalation and never feeds p24_fleet_anomaly_escalations. That advisory-only guardrail — the same one route-consumption-anomaly and ecodriving-per-route-anomaly carry — is exactly what keeps it out of the high-risk tier. Unlike the vehicle-level p24_ecodriving_vehicle_ranking (#7274, no dev_r_ai_systems row because it is not worker data), this analytic is registered in dev_r_ai_systems precisely because it ranks a named driver — honouring the #6848 note “do NOT ship driver-level ranking without the registration”. Scope is small by construction: only ~33 (vehicle, route) pairs today have ≥ 2 overlapping drivers — it is not a whole-fleet driver ranking, only a comparison where drivers physically share a vehicle+route. Wiring this output into any automated employment decision requires a fresh conformity assessment first. It is rule-based statistics (median/MAD + deterministic ranking), not ML — ai_provider='other', ai_model='n/a — median/MAD + deterministic ranking'. Human oversight (Art. 14): the comparison is an advisory GitHub/dashboard signal only. Logging (Art. 12): p24_driver_pairwise_fuel_comparison rows + the nightly ETL logs + Discord/GH error notifications. Transparency (Art. 13): this entry + the ops doc EU AI Act section. Ops doc: docs/atrax-driver-pairwise-fuel-comparison-operations.md.

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.

telegram-claude-orchestrator (service claude-session-manager, bms-4; registered 2026-08-06, #2776 / deployment #3793): the session-management layer behind the Telegram control surface — it holds each user’s tg_conversation_sessions/tg_conversation_messages context and turns an explicit user Telegram message into a dispatched Claude session (Phase 2 also dispatches infra-tasks). Distinct from telegram-claude-interface above: the interface row is the thin n8n bot UI (the command surface); this orchestrator row is the backend service that manages conversation state and drives the sessions. It is classified limited / human-in-loop: every action is initiated by an explicit user Telegram message — the agent executes but the user retains oversight and can review the full conversation history and audit trail (tg_conversation_sessions/tg_conversation_messages) — so no Annex III category applies (no personal data of third parties, no worker/driver scoring, no task allocation to people). Transparency (Art. 13): AI involvement is inherent (the user is directly operating Claude). compliance_status = partial (2026-08-17): held pending end-to-end verification of the Phase 2 deployment tracked in #3793 (still open) — it will move to compliant once that E2E verification lands. 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.

council-judge-review (#6212; design + dogfood review #6207, implementation PR #6211): the council+judge multi-agent review system implemented as Claude Code skill/prompt files — .claude/commands/review-plan.md, .claude/commands/review-pr.md, and the autonomous infra/agent-prompts/review-pr-worker.md. It reviews GitHub design-plans and PR diffs via 8–9 parallel Haiku “perspectives” (completeness, correctness/accuracy, risk, quality/tests, security, secrets, reuse, simplicity, value) synthesised by a judge into a single APPROVE/REQUEST_CHANGES verdict. It acts only on GitHub design-plan / issue / PR title, body and diff content — no personal data, no worker/driver/employee scoring, no task allocation to people — so no Annex III high-risk category applies (same basis as the other GitHub-metadata agents above). Interactive-vs-autonomous distinction (flagged explicitly per #6212): the interactive /review-plan and /review-pr skills are fully advisory — Haiku-only, they post a verdict and a human decides what to do with it. The autonomous review-pr-worker.md is the higher-risk component — its Sonnet judge auto-merges on APPROVE and auto-closes/labels on REQUEST_CHANGES with no human in the loop. Human oversight (Art. 14): the autonomous worker is bounded (open, non-draft PRs only; CI-gated; self-skips on failing CI), review-pr-worker.md is a protected: true production file requiring explicit human confirmation to change, and every auto-merge is still subject to main branch protection requiring an approving review from a separate identity; the whole pipeline is disableable at the dispatcher. Data governance (Art. 10): PR/issue/diff content is treated as external/untrusted input, with an explicit prompt-injection defense clause in the review prompts. Logging (Art. 12): the AI-authored review comments on each issue/PR, dev_r_worker_queue.result_summary, and the queue-dispatcher logs. Transparency (Art. 13/52): every review comment carries an AI-authored disclosure footer naming the model. No dev_r_services row — this is Claude Code skill prompt files, not a new container/service.

dispo-document-classification (#7679, Partially implements #7582; scripts/dispo_classify_backfill.py, run once on bms-4): a one-off gpt-4o backfill that classifies the ~476 unclassified non-footer dispatch-inbox attachments in p24_l_dispo_dokumenty (external freight e-mails + their PDF/image/Excel documents) into the 30-value kategoria business-purpose dictionary and, where the printed issuer matches a known contractor, sets kontrahent_id. Not Annex III high-risk — it classifies commercial freight documents and makes no decision about a natural person: no worker/driver recruitment, evaluation, monitoring or task allocation (III.4(a)), no critical-infrastructure management, no biometric/credit/law-enforcement function. Classified minimal, consistent with the registry’s other inbound-document classifiers (imap-inbox-ai-classifier, ai-documents-inbox-processing, vipo-offer-parser). Transparency (Art. 50) does not apply — output is internal operational metadata, not public-facing generated content and not a chatbot. Human oversight (Art. 14): every classification is advisory only and reviewed/editable by a zarzad/platform_admin operator in the et-op “Zarząd Dispo” UI; typ_dokumentu and jest_stopka are never touched, szablon_id is always left NULL, and low-confidence rows are surfaced for review. Data governance (Art. 10): the external e-mail headers/body and attachment content are treated as untrusted DATA, never instructions — the system prompt carries an explicit SECURITY/prompt-injection clause and lowers confidence on any embedded instruction. Logging (Art. 12): /var/log/p24-infra-workers/dispo_classify_backfill.log (ids/filenames/categories/confidences/token-counts only — no document content, no secret values), the per-row classification_model/classified_at/classification_confidence audit columns, and Discord + GH-issue error notification. Cost is hard-capped (25 USD). Source of truth for the prompt + 30-slug dictionary: infra-src/n8n-workflows/prompts/dispo-document-classification.md + dispo-document-categories.json. Ops doc: docs/logistics-order-extraction-pipeline-operations.md.

et-operational-platform

SystemServiceRiskStatusNotes
vipo-offer-parseret-operational-platformminimalcompliant— (not Annex III — freight-offer extraction from inbound email → internal transport-register rows; no decision about a natural person, no worker scoring/allocation)

vipo-offer-parser (vipoOfferParserService, VIPO epic et-operational-platform#1267; migrated to Vercel AI Gateway in et-op commit f2e85fb1; flagged unassessed during the VIPO Wave-2/coverage dispatch 1789; assessed per p24-infra#6591): AI parser that extracts freight-transport offers from inbound email and auto-creates rejestr-przewozow (transport register) rows in et-op. Not Annex III high-risk — it extracts commercial cargo/freight-offer data and makes no decision about a natural person: no worker recruitment/evaluation/monitoring or task allocation (III.4(a)), no critical road-infrastructure management (III.2(a)), and no biometric / credit-scoring / law-enforcement / education / justice function. Classified minimal risk, consistent with the registry’s other inbound-email extraction systems (imap-inbox-ai-classifier, ai-documents-inbox-processing, wa-ai-to-inbox). Transparency (Art. 50): does not apply — output is internal operational register data, not public-facing synthetic/generated content and not a chatbot interacting with natural persons; inbound offer emails may incidentally carry carrier/dispatcher contact PII, governed the same as the other inbound-email systems (docs/ai-risk-data-governance.md Part C). Human oversight (Art. 14): the auto-created rejestr-przewozow rows are reviewable and editable by operators in the et-op UI. Logging (Art. 12): created rows are persisted and auditable in et-op. Assessment + record-keeping only — no code change in et-op. Registered in dev_r_ai_systems.

whatsup-android-chat-puller

SystemServiceRiskStatusNotes
wa-thread-summarizationwa-thread-reviewminimalpartial— (not Annex III — summarizes already-captured WhatsApp chat content into reviewable threads; no decision about a natural person, no worker scoring/allocation)

wa-thread-summarization (scripts/whatsapp-extractor/thread_builder.py, scheduled via .github/workflows/generate-wa-threads.yml on the self-hosted bms4-android runner; implemented in whatsup-android-chat-puller PR #213 / issue #212, compliance follow-up p24-infra#6915): fetches a user’s p24_wap_messages for a WhatsApp thread, chunks them into 7-day windows, and sends each window to Claude (local CLI, OAuth subscription — no ANTHROPIC_API_KEY) to detect discussion-thread boundaries within a Polish fleet-messaging chat, writing title/summary/context rows into p24_wap_thread_reviews for human approve/reject review in et-operational-platform’s admin “Historia WA” tab (et-operational-platform PR #1973). Not Annex III high-risk — it does not recruit/evaluate/monitor any worker or driver, does not allocate tasks, and does not evaluate or score anyone’s performance (III.4(a) does not apply); it makes no decision about a natural person, only reorganizing already-existing chat content into a more reviewable shape (affects_people=false), same basis as vipo-offer-parser. Classified minimal, not limited: output is an internal admin-panel view, not public-facing generated content and not a chatbot interacting with natural persons, so Art. 50 transparency does not apply. Human oversight (Art. 14): every generated thread carries a review_status (pending/approved/rejected) that a platform_admin must act on — summaries are never auto-actioned. Logging (Art. 12): p24_wap_thread_reviews rows, this repo’s existing p24_wap_pipeline_events audit-trail pattern, and Discord/GH-issue error notification on the new scheduled workflow. Compliance status: partial, not compliant — input is WhatsApp message content from fleet drivers/dispatchers (personal communications, potentially containing PII) and docs/ai-risk-data-governance.md Part C has not yet been updated to cover this input source (has_data_governance=false); there is also no dedicated ops-doc EU AI Act section yet (has_technical_docs=false). Both are tracked as follow-up work, not blocking the feature. At registration time PR #213 was open (not yet merged) and the scheduled workflow had not yet run on the bms4-android runner.

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):

SystemServiceRiskStatusNotes
tronik-gps-kierowcyn8n-bms4limitedcompliantArt.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-mobilnyn8n-bms4limitedcompliantSame as above for technicians (footer was genuinely present since 2026-06-16; workflow W50qRbJs9xrGotaX)
wa-ai-to-inboxn8n-bms4minimalcompliantNo 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-classifiern8n-hstgrminimalcompliantNo mandatory obligation; email PII governance documented in Part C
ai-documents-inbox-processingn8n-cloudminimalcompliantNo mandatory obligation; document PII governance documented in Part C
gmail-tools-daily-inbox-agentn8n-bms4minimalcompliantAdded 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-botn8n-bms4minimalcompliantAdded 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-inspectiontelegram-inspection-botminimalcompliantTranscription only; risk + governance in Part C
et-chatbot-produkcjan8n-hstgrlimitedn/aWIP — 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:

FieldArticleRequirement
has_risk_managementArt. 9Documented risk management system: identify, analyse, evaluate risks; test before deployment
has_data_governanceArt. 10Data governance practices: training data quality, relevance, bias assessment
has_technical_docsArt. 11Technical documentation before market placement; includes architecture, capabilities, limitations
has_loggingArt. 12Automatic logging of events; retain logs for at least 6 months
has_transparencyArt. 13Clear information to deployers and affected persons about AI involvement
has_human_oversightArt. 14Designated 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

FieldArticleRequirement
has_transparencyArt. 52Disclose 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

MeasureStatusNotes
Human oversight✅ yesWorkbooks reviewed; /reoptimize endpoint allows manual override
Logging✅ yesEvery design attempt in audit.runs
Transparency✅ yesInternal team; documented in docs/audit-engine.md
Technical docs✅ yesdocs/audit-engine.md covers architecture, designer, WorkbookSpec
Risk management✅ yesdocs/ai-risk-data-governance.md Part A (A.1–A.5): risk register (R-01/R-02), residual-risk verdict, review schedule
Data governance✅ yesdocs/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
);

  1. 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.

  2. 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:

RuleSeverityCondition
Prohibited system activeFAILeu_ai_act_risk = 'prohibited' and status = 'active'
High-risk: missing oversightFAILeu_ai_act_risk = 'high' and has_human_oversight = false
High-risk: missing loggingFAILeu_ai_act_risk = 'high' and has_logging = false
High-risk: missing technical docsFAILeu_ai_act_risk = 'high' and has_technical_docs = false
High-risk: missing risk managementFAILeu_ai_act_risk = 'high' and has_risk_management = false
High-risk: missing data governanceWARNeu_ai_act_risk = 'high' and has_data_governance = false
Limited-risk: missing transparencyFAILeu_ai_act_risk = 'limited' and has_transparency = false
Annual review overdueFAILlast_reviewed < today - 365 days or last_reviewed IS NULL
High-risk: quarterly review overdueWARNeu_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

DocumentURL
EU AI Act full texthttps://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689
Annex III (high-risk categories)EU AI Act, Annex III
Art. 26 — deployer obligationsEU AI Act, Article 26
EU AI Act databasehttps://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'.

Graph View

Backlinks