--- authoritative: false representation: annotated-page publisher: AstroKube methodology: https://ai-act.astrokube.com/about/ source_verified_on: '2026-09-15' site_content_updated_on: '2026-09-15' title: The AI Act as infrastructure work | AstroKube description: 'What Regulation (EU) 2024/1689 asks an engineering team to run: logging and retention, post-market monitoring, robustness, access control, lineage, records and output marking. Every capability traced to the obligation that requires it.' language: en source: https://ai-act.astrokube.com/engineering/ --- 1. [Start](https://ai-act.astrokube.com/) 2. Engineering THE ENGINEERING VIEW # What the AI Act asks you to run Most of what this regulation demands day to day is platform work. Logs that outlive the request and are kept for a defined period. A feedback loop from production with a reporting clock on it. Reliability properties you declared and now have to hold. This page groups the obligations by the capability they require, so you can see what lands on your platform without reading the law first. ## If compliance or counsel sent you here Each capability names the obligations behind it, in the words of the people who have to build it, and every one links to the primary text. Where the legal argument matters more than the engineering one, follow the citation to the article itself. ## The capabilities, and where each one comes from Ordered by how much of the work usually lands on the platform team rather than on the people building the model. 01 ### Logging and retention Records that outlive the request. Event logs generated automatically across the system's lifetime, held for a defined period, in a store you can still query months later without opening a restore ticket. In most stacks this is a retention and cost decision before it is anything else. - [Art. 12](https://ai-act.astrokube.com/law/art-12/) [Automatic recording of events](https://ai-act.astrokube.com/law/art-12/) High-risk DevOps / SRE · In your terms You already have the pipeline. The gap is usually schema and retention: events rich enough to reconstruct one specific decision on one specific date, protected against tampering. - Inference event schema - Tamper-evident log storage - Replay runbook Failure smells like A regulator asks why one decision happened on one date, and the best answer available is a dashboard screenshot. Developer · In your terms Logging capability is a design-time decision, not a config you bolt on later: correlation IDs and event coverage live in the code. - Decision-correlation IDs across services [EU Art. 12](https://ai-act.astrokube.com/law/art-12/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 16(a)](https://ai-act.astrokube.com/law/art-16/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 19(1)](https://ai-act.astrokube.com/law/art-19/) [Keeping the automatically generated logs](https://ai-act.astrokube.com/law/art-19/) High-risk DevOps / SRE · In your terms Most platforms run days of retention and sampled events; this wants months, complete, and recoverable on request. - Retention policy meeting the six-month floor - Restore test on aged logs Failure smells like The logs covering the period under question were rotated out, on a retention default nobody set with this obligation in mind. Developer · In your terms Log formats you change casually today are formats someone must still parse months from now. [EU Art. 19(1)](https://ai-act.astrokube.com/law/art-19/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 18(1)](https://ai-act.astrokube.com/law/art-18/) [Keeping the documentation for ten years](https://ai-act.astrokube.com/law/art-18/) High-risk DevOps / SRE · In your terms Durable, restorable storage for the archive is an operations problem: test the restore, not just the backup. - Archive restore test on a schedule Developer · In your terms The technical file you generate today must still be producible a decade from now. [EU Art. 18(1)](https://ai-act.astrokube.com/law/art-18/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") 02 ### Post-market monitoring and incident response A loop that carries production behavior back into the system, and a reporting path with a clock running on it. In platform terms: telemetry you actually collect and read, an on-call path that can meet an external deadline rather than an internal one, and the ability to pull a version back. - [Art. 72](https://ai-act.astrokube.com/law/art-72/) [Post-market monitoring](https://ai-act.astrokube.com/law/art-72/) High-risk DevOps / SRE · In your terms This is telemetry with a legal purpose: field performance data that survives deployments and can be analyzed per system version. - Post-market monitoring plan - Versioned field telemetry Failure smells like Field performance is watched on the same dashboards as uptime, so a drift that matters looks like nothing until a user reports it. [EU Art. 72](https://ai-act.astrokube.com/law/art-72/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Regulation (EU) 2026/1744](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1744 "Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI)") - [Art. 73](https://ai-act.astrokube.com/law/art-73/) [Serious incident reporting](https://ai-act.astrokube.com/law/art-73/) High-risk DevOps / SRE · In your terms Your incident process gains a regulatory branch: classification that recognizes a reportable event, and a timeline you can reconstruct from logs inside the clock. - Incident classification with regulatory branch - Authority notification runbook Failure smells like The 15-day clock is discovered during the incident instead of before it. [EU Art. 73](https://ai-act.astrokube.com/law/art-73/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Draft Art. 73 reporting guidance DraftCommission interpretation](https://digital-strategy.ec.europa.eu/en/consultations/ai-act-commission-issues-draft-guidance-and-reporting-template-serious-ai-incidents-and-seeks "Draft guidance on Article 73 AI Act, serious incident reporting") - [Art. 20(1)](https://ai-act.astrokube.com/law/art-20/) [Corrective actions and duty of information](https://ai-act.astrokube.com/law/art-20/) High-risk DevOps / SRE · In your terms Withdraw, disable or recall are operational verbs: the paths to actually do them, per system, exist before the day you need them. - Withdraw-or-disable runbook per system - Downstream notification list Failure smells like A non-conformity is found and the only way to disable the system is a redeploy nobody dares to run. [EU Art. 20(1)](https://ai-act.astrokube.com/law/art-20/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 21](https://ai-act.astrokube.com/law/art-21/) [Cooperation with competent authorities](https://ai-act.astrokube.com/law/art-21/) High-risk DevOps / SRE · In your terms Producing months-old logs for one system on request is a retrieval procedure you can rehearse. - Evidence retrieval procedure [EU Art. 21](https://ai-act.astrokube.com/law/art-21/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") 03 ### Accuracy, robustness and cybersecurity Reliability properties that were declared once and have to hold from then on. Behavior under load, under failure and under adversarial input, plus evidence that the declared numbers were measured rather than asserted. This is SLOs, load and chaos testing, and the security posture of the serving path. - [Art. 15](https://ai-act.astrokube.com/law/art-15/) [Accuracy, robustness and cybersecurity](https://ai-act.astrokube.com/law/art-15/) High-risk DevOps / SRE · In your terms Declared once, held every day after: the accuracy and resilience levels in the documentation become production SLOs with monitoring behind them. - Model performance SLOs with alerts Failure smells like The accuracy declared in the technical file drifts from production metrics with nobody watching the gap. Developer · In your terms Adversarial input, prompt injection and poisoning resistance are test suites, not adjectives. - Adversarial and injection test suite [EU Art. 15](https://ai-act.astrokube.com/law/art-15/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 16(a)](https://ai-act.astrokube.com/law/art-16/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 9](https://ai-act.astrokube.com/law/art-9/) [Risk management system](https://ai-act.astrokube.com/law/art-9/) High-risk DevOps / SRE · In your terms Risk management is not a document you sign once. Article 9(2)(c) feeds it from the post-market monitoring system, which is your telemetry: the risks that only appear in the field reach the register through you or they do not reach it. - Field-risk signal feed into the register - Escalation path for emergent risk Developer · In your terms Risk treatments become design constraints and test cases; each identified risk should map to something you can point at in the codebase. - Risk-to-control mapping in the design docs [EU Art. 9](https://ai-act.astrokube.com/law/art-9/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 16(a)](https://ai-act.astrokube.com/law/art-16/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 55](https://ai-act.astrokube.com/law/art-55/) [Systemic-risk model obligations](https://ai-act.astrokube.com/law/art-55/) General-purpose AI DevOps / SRE · In your terms Evaluations, incident tracking and model-weight security are operational programs with schedules and evidence, not one-off exercises. - Evaluation program with adversarial testing - Model-weight security controls Failure smells like The evaluation that would have found the capability was a benchmark run once, and nothing adversarial has been pointed at the model since. Developer · In your terms Adversarial testing of the model is conducted and documented; the runs and their records are engineering work. - Documented adversarial test runs for the model [EU Art. 55](https://ai-act.astrokube.com/law/art-55/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 51(2)](https://ai-act.astrokube.com/law/art-51/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU GPAI Code of Practice](https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai "General-Purpose AI Code of Practice") 04 ### Access control and human oversight Oversight is only real if a named person can actually intervene in production. That means identity and roles that reach the serving path, a stop control that works under load, and enough retained context to reconstruct why one particular output came out the way it did. - [Art. 14](https://ai-act.astrokube.com/law/art-14/) [Human oversight](https://ai-act.astrokube.com/law/art-14/) High-risk DevOps / SRE · In your terms Oversight needs operational teeth: alerting a human can act on, and a runbook for actually stopping the system. - Oversight runbook Developer · In your terms The stop and override paths have to exist in the architecture, tested like any other critical path. - Kill switch and override, with tests [EU Art. 14](https://ai-act.astrokube.com/law/art-14/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [ES AEPD, guidance on agentic AI](https://www.aepd.es/guias "Orientaciones sobre IA agéntica desde la perspectiva de protección de datos (AEPD)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 16(a)](https://ai-act.astrokube.com/law/art-16/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 26](https://ai-act.astrokube.com/law/art-26/) [Deployer obligations](https://ai-act.astrokube.com/law/art-26/) High-risk DevOps / SRE · In your terms Deployer-side logs and monitoring are yours even when the model is someone else's. - Deployer-side log retention [EU Art. 26](https://ai-act.astrokube.com/law/art-26/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 86](https://ai-act.astrokube.com/law/art-86/) [Right to explanation of individual decisions](https://ai-act.astrokube.com/law/art-86/) High-risk Developer · In your terms Meaningful explanation is bounded by what the system exposes: factors, weights or at least the role the output played have to be reconstructable. - Decision factors captured per output [EU Art. 86](https://ai-act.astrokube.com/law/art-86/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU CJEU C-634/21 (SCHUFA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62021CJ0634 "Judgment C-634/21 (SCHUFA), OQ v Land Hessen, on automated decision-making under Article 22 GDPR") [EU CJEU C-203/22 (Dun & Bradstreet)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62022CJ0203 "Judgment C-203/22 (Dun & Bradstreet), CK v Magistrat der Stadt Wien, on the right to an explanation of automated decision-making") 05 ### Data and model lineage Which data produced which model version, and where that data came from. In pipeline terms: dataset versioning tied to training runs, training runs tied to deployed artifacts, and the chain still readable when someone asks about a version you shipped a year ago. - [Art. 10](https://ai-act.astrokube.com/law/art-10/) [Data and data governance](https://ai-act.astrokube.com/law/art-10/) High-risk DevOps / SRE · In your terms Lineage only holds if the pipeline records it: per-training-run records tying model versions to exact dataset versions. - Per-run lineage records Developer · In your terms Dataset lineage is yours: where each set came from, how it was prepared, what its gaps are, and the bias examination that was actually run. - Dataset cards with provenance - Bias examination report Failure smells like Someone asks which data the model was trained on and the answer is a bucket path, with no record of how the set was assembled or what it was assumed to represent. [EU Art. 10](https://ai-act.astrokube.com/law/art-10/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Regulation (EU) 2026/1744](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1744 "Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 16(a)](https://ai-act.astrokube.com/law/art-16/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 60](https://ai-act.astrokube.com/law/art-60/) [Real-world testing outside sandboxes](https://ai-act.astrokube.com/law/art-60/) High-risk DevOps / SRE · In your terms A live test can be ordered to stop. Article 60(7) requires immediate mitigation on a serious incident, suspension or termination failing that, and a procedure for prompt recall: the watch on the test and the paths to halt and pull it back are operational work that exists before recruitment starts. - Test monitoring with a halt path - Prompt-recall procedure Developer · In your terms Test cohorts and their consent state are data your system has to track. [EU Art. 60](https://ai-act.astrokube.com/law/art-60/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 61](https://ai-act.astrokube.com/law/art-61/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Regulation (EU) 2026/1744](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1744 "Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI)") [EU Art. 113](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") 06 ### Technical records and change management Documentation that tracks the running system instead of describing a version of it that shipped some time ago, and a controlled path for changes. Usually less a writing problem than a question of where the record lives and whether it updates when the system does. - [Art. 11](https://ai-act.astrokube.com/law/art-11/) [Technical documentation](https://ai-act.astrokube.com/law/art-11/) High-risk Developer · In your terms The Annex IV file describes your system, and drift makes it wrong. Generate what can be generated from the source of truth instead of hand-maintaining prose. - Annex IV technical file - Doc generation wired into CI Failure smells like The documentation describes the system as it was designed two releases ago, and nothing in the pipeline forces it to move with the code. [EU Art. 11](https://ai-act.astrokube.com/law/art-11/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Annex IV](https://ai-act.astrokube.com/law/annex-iv/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Regulation (EU) 2026/1744](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1744 "Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 16(a)](https://ai-act.astrokube.com/law/art-16/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 17](https://ai-act.astrokube.com/law/art-17/) [Quality management system](https://ai-act.astrokube.com/law/art-17/) High-risk DevOps / SRE · In your terms Your runbooks and change-management practice will be exhibits in it. Developer · In your terms The quality management system reaches into how you build. Article 17(1)(b) and (c) name design control, design verification and the testing procedures by name: if the written system is not how the team actually works, it is a document that will not survive being checked. - Design control and verification procedures - Test and validation records [EU Art. 17](https://ai-act.astrokube.com/law/art-17/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Regulation (EU) 2026/1744](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1744 "Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 13](https://ai-act.astrokube.com/law/art-13/) [Transparency and instructions for deployers](https://ai-act.astrokube.com/law/art-13/) High-risk DevOps / SRE · In your terms Part of the instructions is operational fact: Article 13(3)(e) wants the computational and hardware resources, the expected lifetime and the maintenance and update cadence. Those numbers come from you, and whatever gets printed becomes the commitment operations is held to. - Resource, lifetime and maintenance inputs for the instructions Developer · In your terms Interpretability of output is partly interface design: expose confidence, provenance and known failure modes where the deployer can see them. - Output metadata deployers can read [EU Art. 13](https://ai-act.astrokube.com/law/art-13/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Art. 16(a)](https://ai-act.astrokube.com/law/art-16/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 25(1)](https://ai-act.astrokube.com/law/art-25/) [Becoming the provider along the value chain](https://ai-act.astrokube.com/law/art-25/) High-risk Developer · In your terms Fine-tuning or wrapping a third-party system can quietly change who counts as its provider. [EU Art. 25(1)](https://ai-act.astrokube.com/law/art-25/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Regulation (EU) 2026/1744](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1744 "Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI)") [EU Art. 113(c)(i)](https://ai-act.astrokube.com/law/art-113/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") 07 ### Output marking and disclosure Machine-readable marking on generated output, and disclosure at the point of interaction. This one lands in the serving path and the output pipeline, not in a policy document, which is why it tends to surface late. - [Art. 50(2)](https://ai-act.astrokube.com/law/art-50/) [Machine-readable marking of synthetic content](https://ai-act.astrokube.com/law/art-50/) Transparency DevOps / SRE · In your terms Marking that silently breaks is marking that does not exist; test that it survives your delivery path. - Provenance-preservation test in CI Developer · In your terms Marking is an output-pipeline feature: provenance metadata or watermarking applied where content is produced, not patched on afterwards. - Content marking in the generation pipeline Failure smells like Output leaves the system unmarked, and the only way to tell it was generated is to already know. [EU Art. 50(2)](https://ai-act.astrokube.com/law/art-50/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Regulation (EU) 2026/1744](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1744 "Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI)") - [Art. 50(1)](https://ai-act.astrokube.com/law/art-50/) [Disclosing interaction with an AI system](https://ai-act.astrokube.com/law/art-50/) Transparency Developer · In your terms Ship it as a reusable component so every conversational surface gets it by default. - Reusable disclosure component [EU Art. 50(1)](https://ai-act.astrokube.com/law/art-50/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 50(3) and (4)](https://ai-act.astrokube.com/law/art-50/) [Deployer disclosure: emotion recognition and deep fakes](https://ai-act.astrokube.com/law/art-50/) Transparency Developer · In your terms Labels and notices belong in the rendering path of the content or the interaction, not in a policy document nobody sees. - Deep-fake disclosure label in the content pipeline [EU Art. 50(3) and (4)](https://ai-act.astrokube.com/law/art-50/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") - [Art. 53(1)](https://ai-act.astrokube.com/law/art-53/) [General-purpose AI provider duties](https://ai-act.astrokube.com/law/art-53/) General-purpose AI Developer · In your terms Model documentation and the downstream information pack describe training, evaluation and limitations at a level another engineering team can build on. - Model documentation - Downstream information pack - Public training-content summary Failure smells like A downstream provider asks what they need in order to comply, and what you have to send is a model card written for a launch post. [EU Art. 53(1)](https://ai-act.astrokube.com/law/art-53/ "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)") [EU Commission guidelines on GPAI obligations Commission interpretation](https://digital-strategy.ec.europa.eu/en/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act "Guidelines on the scope of the obligations for providers of general-purpose AI models under the AI Act") ## The same thing, two vocabularies Where an engineering word and a term of art look interchangeable, they are not, and the difference usually decides who owns the obligation. The left column is what gets said in a design review; the right column is what the Act defines. | You probably say | The Act says | | --- | --- | | end users, customers | affected persons The people a system is used on, rather than the people who run it. The Act does not define the term in Article 3; it brings affected persons located in the Union into scope in Article 2(1)(g), requires deployers of Annex III systems to tell people they are subject to one in Article 26(11), and gives a right to an explanation of individual decision-making in Article 86. | | training, onboarding | AI literacy The skills, knowledge and understanding that let providers, deployers and affected persons make an informed deployment of AI systems and be aware of the opportunities and risks. Article 4 turns it into a duty on providers and deployers, and it is the one obligation that applies at any risk level. | | staging, test environment | AI regulatory sandbox A controlled framework set up by a competent authority where providers can develop, train, validate and test an innovative system, in real-world conditions where appropriate, under supervision and for a limited time. | | agent, local rep | authorised representative A person or body in the Union holding a written mandate from a provider to carry out that provider's obligations under the Regulation on its behalf. Required of providers established outside the Union. | | spec, technical spec | common specification A set of technical specifications providing means to comply with certain requirements of this Regulation. The Commission may adopt them where harmonised standards are missing or insufficient, which is what makes them worth watching while the standards are still in drafting. | | certification, audit | conformity assessment The process of demonstrating that a high-risk system meets the requirements of Chapter III, Section 2. Depending on the case it runs on internal control or through a notified body. | | deepfake, face swap | deep fake AI-generated or manipulated image, audio or video content resembling real people, objects, places, entities or events, which would falsely appear authentic. The disclosure duty in Article 50(4) falls on the deployer who generates or manipulates the content, which is a different party from the provider who must mark synthetic outputs under Article 50(2). | | user, end user | deployer The party using an AI system under its own authority. Personal, non-professional use is excluded. Using a system does not make you a deployer only: Article 25 can turn you into a provider. | | reseller, channel partner | distributor A party in the supply chain other than the provider or the importer that makes an AI system available on the Union market. | | open source, OSS | free and open-source licence The licence that carries the Act's narrowest and most misread exemption. Article 2(12) puts AI systems released under free and open-source licences outside the Regulation, unless they are placed on the market or put into service as high-risk systems or as systems falling under Article 5 or Article 50. For general-purpose AI models, Article 53(2) lifts two specific obligations instead, and never for models with systemic risk. | | DPIA, privacy review | fundamental rights impact assessment The assessment some deployers of Annex III high-risk systems must carry out before putting one into use, covering the processes the system will be used in, the period and frequency of use, the categories of people affected, the specific risks of harm to them, the human oversight measures, and what happens if the risks materialize. It is not a data protection impact assessment, and one does not replace the other. | | foundation model, LLM | general-purpose AI model A model that displays significant generality and can competently perform a wide range of distinct tasks, whatever way it reaches the market, and that can be integrated into many downstream systems. Models used only for research, development or prototyping before market are excluded. | | app on top of the model, LLM wrapper | general-purpose AI system An AI system based on a general-purpose AI model that can serve a variety of purposes, both directly and integrated into other systems. The model and the system are different objects with different duties: Chapter V binds whoever provides the model, while the system you build on it is classified like any other system. | | ISO standard, the standard | harmonised standard A harmonised standard as defined in Regulation (EU) No 1025/2012: a European standard adopted on a Commission request. Conformity with one whose reference has been published in the Official Journal buys the presumption of conformity under Article 40. A standard that has not been cited in the Official Journal buys nothing yet. | | critical system, sensitive system, mission-critical AI | high-risk AI system Not a judgement about how important a system is. Article 6 makes a system high-risk on two routes: it is a safety component of a product covered by Annex I that needs third-party conformity assessment, or it is a use case listed in Annex III. An Annex III system escapes only through the Article 6(3) derogation, which the provider must document before placing the system on the market, and never where the system performs profiling of natural persons. | | reseller | importer A party in the Union that places on the market an AI system bearing the name or trademark of someone established outside the Union. | | use case | intended purpose The use the provider intends for a system, including the context and conditions of use, as set out in the instructions for use, the sales and promotional material, and the technical documentation. What you wrote down, not what you meant. | | regulator | market surveillance authority The national authority that carries out market surveillance under Regulation (EU) 2019/1020. This is who serious incidents are reported to, and who approves real-world testing. | | auditor, certifier | notified body A conformity assessment body notified under the Regulation. Where third-party assessment applies, this is who performs it. Not us, and not your auditor. | | launch, release | placing on the market The first time an AI system or general-purpose model is made available on the Union market. Many duties attach to this moment, so it matters when it happened. | | monitoring, observability | post-market monitoring system Everything a provider does to collect and review experience from systems it has placed on the market or put into service, so that corrective or preventive action can be taken immediately when needed. | | certified, compliant by default | presumption of conformity The legal effect of following a harmonised standard whose reference is published in the Official Journal: the system or model is presumed to meet the requirements that the standard covers. It is a presumption, not a certificate, it reaches only as far as the standard reaches, and it needs the reference to be published first. | | segmentation, scoring, personalization | profiling Profiling as the GDPR defines it: automated processing of personal data to evaluate personal aspects of a natural person. It carries a hard consequence here. An Annex III system that performs profiling of natural persons is always high-risk, with no route through the Article 6(3) derogation. | | vendor, supplier | provider The party that develops an AI system or model, or has one developed, and places it on the market or puts it into service under its own name or trademark. Paid or free makes no difference. Putting your brand on someone else's system makes you one. | | deployment, go live | putting into service Supplying an AI system for first use directly to the deployer, or using it yourself in the Union for its intended purpose. Internal systems you never sell are still put into service. | | abuse, edge case | reasonably foreseeable misuse Use of a system in a way that is not its intended purpose but may result from reasonably foreseeable human behaviour or interaction with other systems. It is the reason a risk management file cannot stop at the happy path: the Act asks about the uses you can foresee, not only the ones you designed for. | | guardrail, safety check | safety component A component of a product or of an AI system that fulfils a safety function, or whose failure endangers health, safety or property. It is one half of the Article 6(1) route into the high-risk tier. Systems used solely for user assistance, performance optimization, service efficiency, automation, convenience or quality control do not qualify; systems whose failure would endanger health and safety do. | | outage, sev1 | serious incident An incident or malfunction that directly or indirectly leads to a death or serious harm to health, a serious and irreversible disruption of critical infrastructure, a breach of Union law protecting fundamental rights, or serious harm to property or the environment. | | high impact, critical | significant risk of harm The test an Annex III system must fail to escape the high-risk tier: it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making. Article 6(3) then lists the four narrow conditions, and the provider documents the assessment before placing the system on the market. | | mid-market company, scale-up | SMC A small mid-cap enterprise as defined in Recommendation (EU) 2025/1099. Article 99(6a) gives it the lower-of-the-two cap as well, but only for the fines in Article 99(4) and (5), not for the prohibited-practice fines in Article 99(3). | | startup, small company | SME A micro, small or medium-sized enterprise as defined in the Annex to Recommendation 2003/361/EC. The definition matters for penalties: under Article 99(6) each fine for an SME, including a start-up, is capped at the lower of the percentage and the fixed amount, which is the reverse of the rule for everyone else. | | major change, breaking change | substantial modification A change made after a system is on the market that the original conformity assessment did not foresee, and that either affects compliance with the high-risk requirements or changes the intended purpose it was assessed for. This is the test that decides whether fine-tuning or repurposing makes you a provider. | | AI content, generated content | synthetic content Audio, image, video or text content generated by an AI system. Article 50(2) makes the provider mark the outputs in a machine-readable format and detectable as artificially generated or manipulated. The duty sits on whoever provides the generating system, before anyone decides whether a particular output is a deep fake. | [Full glossary →](https://ai-act.astrokube.com/glossary/) ## What this page does not decide - Whether the Act applies to your system at all, and in which role. That turns on facts about your product and how it reaches the market, not on your platform. The basics page explains the categories that decide it, without deciding it for you. - Your risk classification. The obligations shown here are grouped by the capability they demand, not by whether they apply to you. - Conformity assessment. That belongs to notified bodies and to your counsel, never to your infrastructure provider. - Anything resembling legal advice. AstroKube engineers maintain this reference against primary sources; we are engineers, not lawyers. ### Where AstroKube fits Every capability on this page is infrastructure we already run for customers as an operated service: retention, telemetry, incident paths, access control, reliability targets. The free assessment maps what your platform does today against what these obligations ask for, and names the gaps. It certifies nothing and it is not legal advice. [Request an assessment →](https://astrokube.com/ai-act-assesment) [Filter the obligations yourself](https://ai-act.astrokube.com/explorer/)