> For the complete documentation index, see [llms.txt](https://docs.linuxguard.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.linuxguard.io/audit-and-comply/audit-comply/eu-ai-act.md). # EU AI Act > **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](https://eur-lex.europa.eu/eli/reg/2024/1689/oj). For the vocabulary contract used here, see [Audit & Comply](/audit-and-comply/audit-comply.md). > **Important**: The `effective_date` recorded 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](/concepts/concepts/console/compliance-expansion.md#evidence-location) table or to a specific console page. See [Audit & Comply](/audit-and-comply/audit-comply.md) for the three-tier vocabulary contract. | Control ID | Description | Tier | Evidence | Notes | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `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](/concepts/concepts/console/compliance-expansion.md#reports). 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 collect` on each host produces a tar.zst archive with agent logs, redacted configuration, and a bundle manifest — see [Support Bundles](/operate/operate/support-bundles.md). 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.log` and 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](/operate/operate/support-bundles.md) for the per-file redaction status table and [GDPR](/audit-and-comply/audit-comply/gdpr.md) for the IP-as-PII consideration relevant to log-shipping decisions. ## Cross-references * [**Audit & Comply**](/audit-and-comply/audit-comply.md) — vocabulary contract, framework version pin reference, forbidden-words list, scope statement template. * [**Compliance Expansion**](/concepts/concepts/console/compliance-expansion.md) — console pillar; canonical Evidence Location pointer set. * [**Audit**](/concepts/concepts/console/audit.md) — authorizations and SUDO execution audit feeding compliance evidence. * [**Support Bundles**](/operate/operate/support-bundles.md) — per-file redaction status table; pre-share PII warning. * [**Log Management**](/operate/operate/log-management.md) — log retention and rotation relevant to Art 12 record-keeping evidence retention. * [**GDPR**](/audit-and-comply/audit-comply/gdpr.md) — 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**](/audit-and-comply/audit-comply/nis2.md) — 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**](/reference/reference/glossary.md) — 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.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.linuxguard.io/audit-and-comply/audit-comply/eu-ai-act.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.