EU AI Act
EU AI Act Regulation (EU) 2024/1689 control mapping — LinuxGuard host-layer telemetry for Art 12 record-keeping and Art 15 cybersecurity of high-risk AI.
Note: This page maps LinuxGuard against the EU Artificial Intelligence Act (Regulation (EU) 2024/1689) (entered into force 2024-08-01 per Article 113). Last verified against the framework on 2026-05-31. Canonical framework document: EUR-Lex — Regulation (EU) 2024/1689. For the vocabulary contract used here, see Audit & Comply.
Important: The
effective_daterecorded in front-matter is the entry-into-force date (Article 113) — operational deadlines are staggered. Prohibited AI practices under Chapters I and II apply from 2025-02-02. General-purpose AI (GPAI) obligations under Chapter V (together with Chapter III Section 4, Chapter VII, and Chapter XII) apply from 2025-08-02. General application — including high-risk AI systems under Annex III via Article 6(2) — applies from 2026-08-02. The obligations for high-risk AI systems embedded in regulated products under Annex I via Article 6(1) apply from 2027-08-02. Customers in scope must determine which staggered deadline binds their AI system before relying on this mapping for evidence preparation.
Scope
This page maps LinuxGuard's agent and console capabilities against the EU AI Act (Regulation (EU) 2024/1689). The mapping is scoped to Chapter III Section 2 (Articles 8-15 — high-risk AI system technical and operational requirements) on Linux systems on which customers operate high-risk AI systems, with concentration on Article 12 (record-keeping / automatic logging of events at the host layer) and Article 15 (accuracy, robustness and cybersecurity of the runtime environment). Controls in Article 9 (AI risk management system), Article 10 (data and data governance), Article 11 (Annex IV technical documentation), Article 13 (transparency and information to deployers), Article 14 (human oversight), the AI-specific cybersecurity controls of Article 15(4-5), GPAI obligations under Chapter V, the conformity assessment under Article 43, the EU declaration of conformity under Article 47, registration in the EU database under Article 49, post-market monitoring under Article 72, and deployer-specific obligations under Article 26 are out of scope for this product and are listed in the mapping table as Out of scope or Supports rather than omitted. This mapping is informational and not a substitute for an independent audit by a qualified assessor.
Customers remain responsible for confirming their role under Article 3 (provider vs deployer vs importer vs distributor), classifying the AI system (Annex III high-risk via Article 6(2), Annex I embedded high-risk via Article 6(1), limited-risk with transparency obligations under Article 50, minimal risk, or general-purpose AI model), establishing the AI risk management system under Article 9, operating the data governance programme under Article 10, drawing up the Annex IV technical documentation under Article 11, providing transparency and instructions for use to deployers under Article 13, designing and implementing human oversight under Article 14, conducting the conformity assessment under Article 43, drawing up the EU declaration of conformity under Article 47, registering the AI system in the EU database under Article 49, operating the post-market monitoring plan under Article 72, and the broader provider obligations under Articles 16-22 (or deployer obligations under Article 26) that the technical and operational measures support. LinuxGuard does not perform any of these AI-system-internal responsibilities — the agent operates at the Linux host layer beneath the AI system.
Shared responsibility
LinuxGuard is a security monitoring agent and console. Compliance with any framework requires customer-side controls in addition to LinuxGuard's capabilities. This mapping is informational and not a substitute for an independent audit by a qualified assessor.
The shared-responsibility framing for EU AI Act Regulation (EU) 2024/1689:
LinuxGuard responsibility. Produce host-layer telemetry (authentication events, file integrity events, configuration baselines and drift, behavioural signals, SUDO execution audit) on the Linux infrastructure where the customer operates a high-risk AI system, supporting the Article 12 record-keeping inputs and Article 15 cybersecurity inputs the customer presents to an auditor or competent authority. Maintain the framework version pin and per-control evidence pointers. Surface the technical timeline (timestamped events, signal records, drift events, support-bundle archive) that contributes to the post-market monitoring evidence surface and to the technical incident timeline for any serious incident reportable under Article 73.
Customer responsibility. Confirm provider vs deployer status under Article 3(3) and Article 3(4); classify the AI system (Annex III high-risk vs Annex I embedded high-risk vs limited-risk subject to Article 50 transparency vs minimal risk vs GPAI under Chapter V); establish and operate the AI-system-internal risk management system under Article 9; administer the data and data governance programme under Article 10; draw up and maintain the Annex IV technical documentation under Article 11; design the AI system for transparency and provide instructions for use under Article 13; design and implement effective human oversight under Article 14; design and operate the AI-specific cybersecurity controls under Article 15(4-5) (model resilience against adversarial input, data poisoning, model poisoning, model evasion, confidentiality attacks); conduct the conformity assessment under Article 43; draw up the EU declaration of conformity under Article 47; register the high-risk AI system in the EU database under Article 49; operate the post-market monitoring plan under Article 72; and engage with the supervisory regime applicable to the system.
Out-of-scope domains for this framework. AI model risk management, training and validation and testing data governance, Annex IV technical documentation administration, deployer transparency and instructions for use, human oversight UI design, conformity assessment workflow, EU declaration of conformity drafting, EU database registration, post-market monitoring administration, GPAI provider obligations under Chapter V, sectoral integration for Annex I embedded high-risk systems, and the broader supervisory and penalty regime under Chapters VII-XII.
Control mapping
The Tier column uses one of three labels and only those three: Satisfies, Supports, Out of scope. The Evidence column points to a row of the canonical Evidence Location table or to a specific console page. See Audit & Comply for the three-tier vocabulary contract.
Art 8(1)
High-risk AI systems comply with the requirements laid down in this Section (Arts 9-15), taking into account the intended purpose, the state of the art, and the risk management system under Art 9
Supports
Console Compliance Expansion → Reports; Console Compliance Expansion → control detail
LinuxGuard provides host-layer evidence for the Art 12 (record-keeping) and Art 15 (cybersecurity) requirements that contribute to the provider's overall Art 8 compliance demonstration. Provider responsible for orchestrating compliance across all of Arts 9-15 at the AI system layer, the conformity assessment under Art 43, and the EU declaration of conformity under Art 47.
Art 8(2)
Where the high-risk AI system relates to a product covered by Union harmonisation legislation listed in Annex I Section A, the provider's obligations under this Regulation are integrated with the obligations under the relevant sectoral legislation
Out of scope
n/a
Integration with sectoral Union harmonisation legislation (machinery, medical devices, in-vitro diagnostics, civil aviation, motor vehicles, others) is a provider responsibility not addressed by LinuxGuard.
Art 9
Risk management system — establish, implement, document, and maintain a continuous iterative risk management process throughout the entire lifecycle of the high-risk AI system
Out of scope
n/a
The AI-system-internal risk management process (risk identification, estimation, evaluation, mitigation across the AI lifecycle) is a provider responsibility addressed at the AI system layer, not the Linux host layer. Not addressed by LinuxGuard.
Art 10
Data and data governance — training, validation, and testing data sets meet the quality criteria of Art 10(2-5), including relevance, representativeness, accuracy, statistical properties, and bias examination
Out of scope
n/a
Training and dataset governance (data collection processes, data preparation, examination for biases, identification of data gaps, data minimisation) is an AI-provider responsibility not addressed by LinuxGuard.
Art 11
Technical documentation — draw up and keep up to date the technical documentation of the high-risk AI system as set out in Annex IV before placing on the market or putting into service
Out of scope
n/a
Annex IV technical documentation (general description of the AI system, detailed description of the elements and development process, monitoring, functioning, control, risk management system, lifecycle changes) is a provider responsibility not addressed by LinuxGuard.
Art 12(1)
Record-keeping — high-risk AI systems technically allow for the automatic recording of events (logs) over the lifetime of the system
Supports
Agent log (raw events); Console Audit pillar → SUDO execution audit; Console Zero Trust Enforcement → Signals
LinuxGuard captures host-layer events (authentication events, file integrity events, configuration drift events, SUDO execution audit, behavioural signals) with timestamps for the Linux environment in which the high-risk AI system runs. Provider responsible for the AI system's own application-layer automatic logging required by Art 12(1-3), including events identifying situations under Art 79(1), the period of each use, the reference database, and the natural persons involved in verification.
Art 12(2)
Logging capabilities enable monitoring of operation, identification of situations resulting in risk under Art 79(1), and facilitate post-market monitoring under Art 72
Supports
Console Zero Trust Enforcement → Signals; Console Compliance Expansion → History; Support bundle
Host-layer signal categorisation, drift events, and the support-bundle archive provide one input to the post-market monitoring evidence surface. Provider responsible for the AI-system-internal log content satisfying Art 12(2)(a-c) and for the Art 72 post-market monitoring plan.
Art 12(3)
Logging capabilities of high-risk AI systems referred to in Annex III(1)(a) (biometric identification) record specific data — period of each use, reference database, input data, identity of natural persons involved in result verification
Out of scope
n/a
The Annex III(1)(a) biometric-identification-specific log fields are AI-system-internal record-keeping that LinuxGuard's host-layer telemetry does not produce.
Art 13
Transparency and provision of information to deployers — design and develop high-risk AI systems so deployers can interpret the system's output and use it appropriately; provide instructions for use
Out of scope
n/a
Transparency design choices, output interpretability, and deployer instructions for use are AI-system properties and provider responsibilities not addressed by LinuxGuard.
Art 14
Human oversight — high-risk AI systems designed and developed so that they can be effectively overseen by natural persons during the period in which they are in use
Out of scope
n/a
Human oversight measures (oversight interface design, ability to intervene, ability to interrupt, stop button) are AI-system properties and provider responsibilities not addressed by LinuxGuard.
Art 15(1)
Accuracy, robustness and cybersecurity — high-risk AI systems designed and developed so that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and perform consistently throughout their lifecycle
Supports
Console Zero Trust Enforcement → Config Drift; Console Zero Trust Enforcement → Signals; Agent log (raw events)
LinuxGuard provides host-layer cybersecurity telemetry (authentication events, file integrity events, configuration baselines and drift, behavioural signals) protecting the runtime environment in which the high-risk AI system operates. Provider responsible for the AI-system-internal accuracy and robustness metrics, the AI-specific cybersecurity controls under Art 15(4-5) (resilience against attempts to alter use, output, or performance through exploiting system vulnerabilities), and the lifetime declared accuracy levels and metrics in instructions for use.
Art 15(2)
Levels of accuracy and relevant accuracy metrics declared in the instructions of use
Out of scope
n/a
AI-system-level accuracy declaration is a provider responsibility not addressed by LinuxGuard.
Art 15(3)
Robustness — resilient against errors, faults, or inconsistencies; technical redundancy solutions, including backup or fail-safe plans, may be appropriate
Supports
Agent log (raw events); Console Zero Trust Enforcement → Signals
Host-layer agent health telemetry, authentication event capture, and file-integrity events surface degradations of the runtime environment that may affect AI system robustness. Provider responsible for the AI-system-internal redundancy, backup, fail-safe design, and the architecture-layer resilience choices.
Art 15(4)
High-risk AI systems are resilient against attempts by unauthorised third parties to alter their use, outputs, or performance by exploiting system vulnerabilities
Supports
Console Audit pillar → Authorizations audit; Agent log (raw events) with loginUID attribute; Console Zero Trust Enforcement → Signals; Console Zero Trust Enforcement → Config Drift
LinuxGuard observes OS-layer unauthorised access attempts (authentication events, signals, drift events) and provides loginUID capture that survives sudo/su escalation for non-repudiation of administrator actions on the AI system's host. Provider responsible for the AI-system-internal cybersecurity controls (model robustness against adversarial input, data poisoning, model evasion, model inversion, confidentiality of model artefacts) at the application layer.
Art 15(5)
Technical solutions to address AI-specific vulnerabilities — measures to prevent, detect, respond to, resolve, and control for attacks attempting to manipulate the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws
Out of scope
n/a
AI-specific attack mitigations (data poisoning, model poisoning, adversarial examples, model evasion, confidentiality attacks, model flaws) are AI-system-internal cybersecurity controls not addressed by LinuxGuard at the Linux host layer.
Important: Every Satisfies claim cites a specific agent feature and a specific evidence pointer. Every Supports claim states what the customer must implement to achieve full satisfaction. Every Out-of-scope row carries a one-line note explaining why — silence is interpreted as an implicit Satisfies claim.
How to share with auditor
Three export paths are available, depending on the auditor's, notified body's, or competent authority's evidence preference:
Console Compliance Expansion reports. Console pillar → Compliance Expansion → Reports produces dated, signed, auditor-shareable evidence packages (PDF / CSV / JSON) per Compliance Expansion. Each report includes the framework version (EU AI Act Regulation (EU) 2024/1689), last-verified date, per-control coverage, per-server pass / fail breakdown, suppressions in effect, and a manifest with SHA-256 verification. Reports support the Article 12 record-keeping and Article 15 cybersecurity evidence inputs the customer presents to a notified body during the Article 43 conformity assessment or to a competent authority during post-market supervision.
Support bundles for host-level evidence.
support-bundle collecton each host produces a tar.zst archive with agent logs, redacted configuration, and a bundle manifest — see Support Bundles. Bundles are useful when the auditor or competent authority wants raw host-level telemetry rather than a console-rendered report, particularly when reconstructing the technical timeline supporting an Article 73 serious-incident notification or the Article 72 post-market monitoring evidence record.Console CSV / JSON export per control. Compliance Expansion → EU AI Act → control detail → Evidence tab exports per-control evidence in machine-readable form for auditors who want to ingest evidence into their own GRC tooling.
Security Note: Support bundles include the raw
agent.logand rotated segments. Attribute-key redaction (api_key / *_token / *_secret) is applied; PII (hostnames, IPs, usernames, paths, command args) is NOT additionally redacted. Review every evidence package before sharing externally — particularly relevant when the recipient is a notified body, a national competent authority, or the AI Office, and when the entity also processes EU personal data under GDPR. See Support Bundles for the per-file redaction status table and GDPR for the IP-as-PII consideration relevant to log-shipping decisions.
Cross-references
Audit & Comply — vocabulary contract, framework version pin reference, forbidden-words list, scope statement template.
Compliance Expansion — console pillar; canonical Evidence Location pointer set.
Audit — authorizations and SUDO execution audit feeding compliance evidence.
Support Bundles — per-file redaction status table; pre-share PII warning.
Log Management — log retention and rotation relevant to Art 12 record-keeping evidence retention.
GDPR — IP-as-PII consideration relevant to log-shipping decisions for EU AI Act customers also in scope of GDPR (high overlap, since EU AI Act customers commonly process personal data).
NIS2 — cybersecurity risk-management measures for essential and important entities in the EU; many EU AI Act customers (especially in finance, health, digital infrastructure) are also in NIS2 scope.
Glossary — framework acronyms and compliance vocabulary definitions.
Last reviewed: 2026-05-31 against EU AI Act Regulation (EU) 2024/1689 published 2024-07-12, entered into force 2024-08-01, general application 2026-08-02.
Last updated
Was this helpful?