Practical AI Act Advice

Why it matters. The Act is a horizontal law - it does not sit inside one industry, it sits underneath all of them. That surprises two kinds of organizations: the ones who assume "AI regulation" means something for foundation-model labs and not for the internal tool their ops team built, and the ones outside the EU who assume a law with "EU" in the name can't reach them. Both assumptions are wrong often enough to be worth checking explicitly, up front, before any deeper compliance work.

What the law requires.

• What counts as AI. The Act's definition is broad on purpose: a machine-based system that operates with some degree of autonomy, may keep adapting after it's deployed, and infers from the input it receives how to generate outputs - predictions, generated content, recommendations, or decisions - that can influence physical or virtual environments. Adaptiveness is optional; inference is the defining element, which is what keeps ordinary rule-based automation outside the definition. It's built to track the OECD's definition, and it is intentionally technology-neutral rather than tied to a specific technique like machine learning.
• Who has obligations. Four roles carry different duties: a provider builds an AI system or model (or has it built) and puts it into service or on the market under its own name; a deployer uses a system under its own authority (personal, non-professional use doesn't count); importers and distributors move other providers' systems into or through the EU market. Two further roles appear where relevant: an authorized representative, which a provider established outside the EU must appoint before placing a high-risk system on the EU market, and a product manufacturer, which counts as the provider when a high-risk system ships inside its own product. Most of the Act's weight sits on providers, but that doesn't make the other roles optional reading. Role is not fixed either: under Article 25 a deployer, distributor or importer becomes the provider of a high-risk system, with the full provider obligation set, in three situations: it puts its own name or trademark on a high-risk system already on the market; it makes a substantial modification to a high-risk system that stays high-risk; or it changes the intended purpose of a system so that it becomes high-risk. Rebranding a low-risk tool does not by itself make you the provider of a high-risk one; changing what a tool is for can, with no code change. Fine-tuning a general-purpose model is a separate question, covered in Section 6.
• Territorial reach. Three separate triggers each independently pull an organization into scope: being a provider placing a system or model on the EU market regardless of where you're headquartered; being a deployer established in the EU; or being a provider or deployer located anywhere else in the world whose AI output is used within the EU. That third trigger is the one non-EU organizations most often miss.
• What's carved out. The Act does not reach AI used solely for military, defense, or national security purposes; AI developed and put into service solely for scientific research and development; research, testing, or development work done before a system is placed on the market or put into service (testing in real-world conditions is not covered by that exclusion); non-EU public authorities and international organizations using AI for law-enforcement or judicial cooperation with the EU, provided adequate safeguards for fundamental rights are in place; individuals using AI for purely personal, non-professional reasons; or AI systems released under free and open-source licenses - but that last exemption stops the moment the system is placed on the market or put into service as a prohibited, high-risk, or transparency-triggering system. Open-source general-purpose AI models have their own, narrower relief, described in Section 6.
• Terms worth actually knowing cold, because they gate everything downstream: a serious incident is a malfunction or incident that leads (directly or indirectly) to death, serious harm to health, serious disruption of critical infrastructure, breach of an EU fundamental right, or serious harm to property or the environment; a deep fake is AI-generated or manipulated image, audio, or video content resembling a real person, object, place, entity, or event, in a way that would falsely read as authentic; a general-purpose AI model is a model trained on large amounts of data (often via large-scale self-supervision) that shows broad general competence across many distinct tasks and can be plugged into many different downstream systems - research/prototyping models not yet on the market are excluded; and biometric identification is automated recognition of physical, physiological, behavioral, or psychological traits used to establish who someone is by matching their biometric data against a stored database.

Practical steps.

• Map every internal and customer-facing AI activity against the four roles - don't assume "we're just a user of someone else's tool" settles the question; check whether you modify, rebrand, or repurpose what you buy.
• Run the territorial test even with zero EU headcount: if your output lands in the EU, you may be in scope.
• Treat "it's open source" as a question, not an answer - check whether the specific use crosses into prohibited, high-risk, transparency-triggering, or systemic-risk territory.
• Keep a one-page scope memo per major AI initiative recording which role(s) apply and why; you'll need that reasoning again at every later compliance stage.

Worked example. A software company headquartered outside the EU embeds a generative chatbot into a SaaS product sold to EU-based customers. It has no EU office and no EU staff. It is still a provider under the Act: selling the product to EU customers places the system on the EU market, and even if it did not, the third trigger (output used within the EU) would catch it regardless of where the company sits.

Why it matters. This is the one tier of the Act with no proportionality dial - no risk-based mitigation gets a prohibited practice back to "acceptable." It's also the tier with the harshest financial exposure (up to 7% of global annual turnover), which is the Act's way of signaling that these uses are considered incompatible with EU values outright, not merely risky. Every new AI use case should be screened against this list before any other compliance work starts, because nothing downstream fixes a practice that's banned at the root.

What the law requires. Ten categories of practice are prohibited, eight from the original Act and two added by Regulation (EU) 2026/1744 with effect from 2 December 2026:

1. Manipulation through subliminal or deceptive design - systems built to distort behavior below someone's conscious awareness or through deception, where that distortion causes or is likely to cause significant harm.
2. Exploiting vulnerability - targeting people because of age, disability, or socioeconomic situation to distort their behavior in a way that causes or is likely to cause significant harm.
3. Social scoring - evaluating or ranking people by social behavior or personal traits in a way that leads to detrimental treatment disconnected from, or disproportionate to, the context the data came from.
4. Individual predictive policing based purely on profiling - assessing or predicting someone's likelihood of committing a crime based solely on automated profiling of traits and characteristics, with no other basis. Systems that support a human assessment already grounded in objective, verifiable facts directly linked to a criminal activity are outside the ban.
5. Emotion inference in the workplace and in education - banned outright, with a narrow carve-out where the purpose is medical or safety-related.
6. Untargeted scraping to build facial recognition databases - harvesting facial images in bulk from the internet or CCTV footage to create or expand such a database.
7. Biometric categorization used to infer protected traits - using biometric data to sort people by race, political opinion, trade union membership, religious belief, sex life, or sexual orientation. Labelling or filtering lawfully acquired biometric datasets, and categorization in the area of law enforcement, are outside the ban.
8. Real-time remote biometric identification in public by law enforcement - banned as a default rule, with three narrow, pre-defined exceptions: a targeted search for victims of abduction, trafficking or sexual exploitation, or for missing persons; preventing a specific and imminent threat to life or physical safety, or a genuine and present or foreseeable terrorist attack; or locating a suspect of one of the serious offences listed in Annex II, punishable by at least four years. Even within those exceptions, prior authorization from an independent judicial or administrative body is required (in a duly justified urgency the use may start first, with authorization requested without undue delay and within 24 hours), national law must have opened the exception, and law enforcement must apply appropriate safeguards, including a fundamental rights impact assessment.
9. Generating non-consensual sexually explicit or intimate imagery - added as Article 5(1)(ba) by the Digital Omnibus on AI, applicable from 2 December 2026. For providers the test is the system's intended purpose, or a reasonably foreseeable and reproducible outcome without adequate safeguards; for deployers it is intent (new Article 5(1a)).
10. Generating child sexual abuse material - added as Article 5(1)(bb) on the same basis and from the same date. The Commission's February 2025 guidelines on prohibited practices predate both additions and have not yet been revised to cover them.

Practical steps.

• Build a short screening questionnaire into project intake: does this system score or rank people by behavior or characteristics? Does it use biometric data to infer something the person didn't choose to disclose? Does it read emotion in a workplace or classroom setting? Can it generate sexual or intimate imagery of real people, and what stops it?
• Route anything touching biometrics, profiling, or emotion inference to legal sign-off before development starts, not after a prototype exists.
• For any real-time biometric use by or for law enforcement, confirm the authorization pathway exists and is documented before deployment, not retroactively.
• Don't rely on "we'd never do that on purpose" - the risk is usually a well-intentioned feature (engagement scoring, wellness monitoring) drifting into a banned category without anyone naming it that way.

Worked example. An employer wants to add webcam-based emotion analysis to video meetings to gauge team engagement. There's no medical or safety purpose behind it - it's a productivity feature. That puts it squarely inside the workplace emotion-recognition prohibition; no mitigation plan brings it back into bounds. The only fix is not building it.

Why it matters. "High-risk" is the tier that carries the Act's heaviest ongoing obligation set, so getting the classification right - including correctly concluding a system is not high-risk - is foundational. Two different routes get a system there, and they're evaluated independently.

What the law requires.

• Route one: the Annex III use-case list. A system is high-risk if it falls into one of the listed use-case categories:

• Route two: regulated products and safety components. A system is also high-risk if two conditions are both met: it is a product, or a safety component of a product, covered by one of the EU product laws listed in Annex I, and that product has to go through a third-party conformity assessment under that law. Coverage by a listed law is not enough on its own. Annex I Section A holds the laws where the AI requirements are checked inside the product's own conformity assessment: toys (Directive 2009/48/EC), recreational craft, lifts (Directive 2014/33/EU), equipment for explosive atmospheres, radio equipment (Directive 2014/53/EU), pressure equipment (Directive 2014/68/EU), cableway installations (Regulation (EU) 2016/424), personal protective equipment (Regulation (EU) 2016/425), gas-burning appliances (Regulation (EU) 2016/426), and medical devices (Regulation (EU) 2017/745 and 2017/746). Section B holds motor vehicles (Regulation (EU) 2019/2144 and No 168/2013), aviation (Regulation (EU) 2018/1139 and (EC) 300/2008), marine equipment (Directive 2014/90/EU), rail (Directive (EU) 2016/797) and, since the Omnibus, machinery (Regulation (EU) 2023/1230, which replaced Directive 2006/42/EC in the Annex); for Section B products only Article 6(1), the new Article 60a and the final provisions apply, and the sectoral law carries the substance. The Omnibus also added that a system used only for non-safety functions such as user assistance, performance optimization, convenience or quality control is not a safety component unless its failure endangers health or safety, and that a conformity assessment required solely for non-safety risks does not satisfy the second condition (Article 6(1a) to (1c)).
• The carve-out. A system that falls into an Annex III use case is not treated as high-risk if it doesn't pose a significant risk of harm to health, safety, or fundamental rights, and Article 6(3) allows that conclusion in four situations only: the system performs a narrow procedural task; it improves the result of a previously completed human activity; it detects decision-making patterns or deviations from them without replacing or influencing the human assessment; or it performs a preparatory task for an assessment. One override: an Annex III system that profiles natural persons is always high-risk, whatever else it does. The Act doesn't hand out a blanket pass here; it's a narrow, fact-specific exception, so don't lean on it without the documented assessment the Act requires before the system is placed on the market, which authorities can ask to see.
• Registration. Providers of Annex III high-risk systems register themselves and the system in the EU database before placing it on the market or putting it into service, and the Omnibus kept the simplified registration for Annex III systems a provider has assessed as not high-risk under the carve-out. Three limits: critical infrastructure systems (Annex III point 2) are registered nationally, not in the EU database; law enforcement, migration, asylum and border control entries go into a secure section that is not public; and Annex I product-embedded systems are not registered in the EU database at all, since they are tracked through their own product legislation. Deployers that are public authorities register their use as well. The obligation applies from 2 December 2027; as of September 2026 the database itself was reported as not yet operational, so build the step into the launch checklist and watch for the opening date.

Practical steps.

• Run every AI use case through both routes independently - a system can clear the product-safety route and still land in Annex III, or vice versa.
• When you conclude a system escapes high-risk status via the "no significant risk" carve-out, write down why, not just that it does - that record is what you'll need to defend the conclusion later.
• Build registration into your launch checklist for any Annex III system that clears the high-risk bar, and for any Annex III system you have exempted under the carve-out, rather than treating it as a late-stage afterthought.
• Revisit classification when a system's use case changes - a tool built for one purpose that gets repurposed into, say, a hiring decision can cross the line without any code changing.

Why it matters. If you provide a high-risk AI system, the Act expects you to have engineered compliance into the system itself, not bolted it on afterward. The requirement set below is meant to be threaded through the whole development lifecycle - risk management and data governance start at design time, not at ship time.

What the law requires - provider checklist for high-risk systems.

• Risk management system. Identify, evaluate, mitigate, and monitor risks continuously and iteratively - this is a running process, not a one-time assessment filed away after launch.
• Data and data governance. Training, validation, and test datasets must be relevant, representative, and of sufficient quality to keep bias risk down; be ready to explain your data sourcing and curation choices. Where bias detection or correction needs special-category personal data, Article 4a (added by the Omnibus) allows it under six cumulative conditions: no other data, including synthetic or anonymized data, can do the job; technical limits on re-use and state-of-the-art security; strictly controlled and documented access; no transfer to other parties; deletion once the bias is corrected or the retention period ends; and a processing record that explains why it was necessary. It is a permission with safeguards, not a duty to collect sensitive attributes, and it now also covers deployers of high-risk systems and providers and deployers of other systems where strictly necessary.
• Technical documentation. Maintain a record covering the system's description, its performance metrics, test results, data lineage, and its conformity declaration - this is the file a regulator or auditor will ask to see first.
• Automatic logging. The system must record events automatically over its lifetime, at a level that lets risks, substantial modifications and post-market monitoring be traced (for remote biometric identification the Act specifies the content: each use, the reference database, the input that produced a match, the people who verified it), and the provider keeps the logs under its control for at least six months, longer where the purpose or other law requires.
• Instructions for use. Provide deployers with documentation that actually lets them operate the system safely - this is the artifact deployers are legally entitled to rely on.
• Human oversight by design. Build the system so a human can meaningfully interpret and explain what it's doing, not just switch it off in an emergency.
• Accuracy, robustness, and cybersecurity. Demonstrate - through testing and documentation, not assertion - that the system holds up to an appropriate standard on all three.
• Quality management system. Document your organization's strategy for regulatory compliance, quality control, and risk management as a coherent whole, not scattered across teams.
• Accessibility. High-risk systems must meet EU accessibility requirements under Directives 2016/2102 and 2019/882.
• Conformity assessment. Complete the required conformity assessment and produce a Declaration of Conformity before the system goes to market.
• Registration. Register Annex III systems in the EU database for high-risk AI before placing them on the market (Annex I systems follow their product legislation instead).
• Regulatory cooperation. Be prepared to share information about the system with regulatory authorities on request.

The twelve items are the core of Article 16, not the whole of it. A provider also owes corrective action and withdrawal when a system turns out non-compliant (Article 20), the CE marking (Article 48), ten-year retention of the technical file and declaration (Article 18), a post-market monitoring system and plan (Article 72), and serious-incident reporting to the market surveillance authority within 15 days of awareness, faster for deaths or widespread harm (Article 73); a provider established outside the EU also appoints an authorized representative before placing a high-risk system on the EU market (Article 22).

Practical steps. Turn the twelve items above into a stage-gated internal checklist - some belong at design (data governance, oversight design), some at pre-launch (conformity assessment, registration), and some are ongoing (logging, cooperation, risk monitoring). Assign an owner to each item rather than treating "compliance" as one team's job; documentation and quality-management obligations in particular tend to fall through cracks between engineering and legal.

Why it matters. Most organizations touched by the Act are deployers, not providers - they're buying and using AI built by someone else, not building it themselves. That makes vendor selection a compliance decision, not just a procurement one: a deployer can be exposed by a provider's shortcomings even when the deployer did nothing wrong on its own systems. Choosing providers carefully, and doing real due diligence on them, is not optional risk hygiene here - it's load-bearing.

What the law requires - deployer obligations for high-risk systems.

• Follow the instructions for use. Obtain the provider's instructions and operate the system within them - deviating from documented use is the quickest way to take on provider-level exposure, but the duties below are the deployer's own whether or not the instructions were followed, and a provider's breach is not automatically the deployer's.
• Human oversight. Assign oversight of the system to people who actually have the competence, training, and authority to exercise it - a formal sign-off from someone who doesn't understand the system doesn't satisfy this.
• Input data quality, where you control it. If the deployer feeds the system its own input data, that data has to be relevant and sufficiently representative for the system's actual use.
• Ongoing monitoring. Watch how the system operates in practice. Where use in line with the instructions may present a risk to health, safety or fundamental rights, inform the provider or distributor and the market surveillance authority without undue delay and suspend use; where you identify a serious incident, inform the provider first, then the importer or distributor and the authority (Article 26(5)).
• Record-keeping. Retain the logs the system generates, to the extent they are under your control, for a period appropriate to the system's purpose and at least six months, unless Union or national law, in particular data protection law, sets a different period (Article 26(6)).
• Transparency to affected people. Inform workers' representatives and affected employees when a high-risk system is used in the workplace, and inform individuals when a system is making or materially assisting decisions about their lives.
• Regulatory cooperation. Cooperate with authorities, including during investigations or enforcement actions.
• Data protection impact assessment. Complete a DPIA where one applies, drawing on the documentation the provider supplied.

Fundamental rights impact assessment (FRIA). This is not a blanket requirement across all high-risk deployments - it applies to a specific subset: deployers that are bodies governed by public law, private entities providing public services, and deployers of two Annex III use cases: evaluating the creditworthiness of natural persons or establishing their credit score (excluding systems used to detect financial fraud), and risk assessment and pricing of natural persons for life and health insurance. Motor, property and other insurance lines are not in the list. It applies only to Annex III high-risk systems, and not to critical-infrastructure systems under Annex III point 2; a public body deploying a product-embedded (Annex I) system owes no FRIA. The assessment records the deployer's processes and intended use, the period and frequency of use, the categories of people affected, the specific risks of harm, the human oversight measures, and what happens if a risk materializes, including governance and complaint arrangements; it is done before first use, updated when any of those elements change, and its results are notified to the market surveillance authority on the AI Office template. The Omnibus lets the FRIA cross-reference an existing DPIA rather than repeat it (Article 27(4)); the AI Office already owed a template questionnaire and an automated tool under the 2024 text (Article 27(5)). The obligation applies from 2 December 2027.

Importers and distributors. Their duty is narrower but non-negotiable: verify that the high-risk system is actually in conformity with the Act's requirements before passing it along, typically by checking the Declaration of Conformity and the CE marking rather than taking the provider's word for it.

Practical steps. Build a standing vendor-vetting process specifically for AI providers, distinct from general procurement due diligence - request the instructions for use and technical documentation before signing, not after. Pre-identify which of your deployments fall into the FRIA-triggering categories (public-law body, public service, credit scoring, life and health insurance) so the assessment isn't discovered as a last-minute gap during an audit.

Worked example. A bank deploys a third-party AI system that evaluates the creditworthiness of consumer credit applicants and sets their credit score. As deployer, the bank needs the provider's instructions for use, must assign competent human oversight of the credit decisions, must complete a fundamental rights impact assessment (creditworthiness evaluation is one of the two triggering Annex III use cases; a tool that only priced an already approved loan would need the use case tested first), must tell applicants that a high-risk system is used in decisions about them, and must be ready to show its logs if a serious incident or a regulator's inquiry arises. None of that is satisfied by the vendor's own compliance work - it's the bank's obligation as deployer.

Why it matters. GPAI models are a separate regulatory lane from high-risk systems - a foundation model can sit underneath a high-risk system, a limited-risk system, or nothing classified as high-risk at all, and it has its own obligations regardless of where it ends up being used. If your organization builds or fine-tunes large general-purpose models, this lane applies to you even before you know exactly how customers will deploy them downstream: fine-tuning or otherwise modifying someone else's model makes you the provider of the modified model, with the obligations limited to the modification (Recital 109).

What the law requires.

• Definition. A GPAI model is one trained on large amounts of data - often through large-scale self-supervision - that shows broad, general competence across many distinct tasks and can be integrated into a wide range of downstream systems. Models still in research, development, or prototyping, not yet placed on the market, don't count yet.
• Baseline obligations for GPAI providers. Publish a detailed summary of the content and data used to train the model; maintain a policy for complying with EU copyright and intellectual-property law; keep technical documentation current; and produce documentation that lets downstream providers integrating the model understand its capabilities and limitations.
• The open-source carve-out. A model released under a free and open-source license that makes its parameters, architecture and usage information publicly available is relieved of the two documentation duties only (the technical documentation for authorities and the documentation for downstream providers). The copyright policy and the public training-content summary apply to every GPAI provider, open source included. The relief disappears if the model is classified as posing systemic risk, in which case the full obligation set (below) applies regardless of license.
• Systemic-risk classification. A model is treated as posing systemic risk if it has high-impact capabilities - measured primarily by the cumulative compute used to train it - or if the European Commission designates it as such by decision.
• The 10^25 floating-point operations threshold, in plain terms. Floating-point operations (FLOP; the common "FLOPS" with an S means operations per second, which is not the measure here) are just a way of counting how much raw computation went into training a model. The Act uses cumulative training compute above 10^25 floating-point operations as its main proxy for "this model is powerful enough that its capabilities could be hard to fully predict or control" - the underlying logic being that more training compute tends to track with more general capability, and more general capability is where systemic risk tends to concentrate. This is explicitly a moving target: the threshold is designed to be reviewed and adjusted as the technology develops, not fixed forever. Crossing it creates a presumption, not a verdict: the provider must notify the Commission within two weeks of meeting the threshold or learning it will be met, may argue that the model exceptionally presents no systemic risk, and the Commission can designate a model below the line on its own initiative or after an alert from the scientific panel.
• Extra obligations once a model crosses into systemic risk. On top of the baseline four: notify the European Commission; run model evaluation and adversarial testing; maintain adequate cybersecurity protections; report serious incidents; and actively assess and mitigate the model's key systemic risks.
• Timing and compliance tools. GPAI obligations became applicable on 2 August 2025, twelve months after the Act's entry into force; the Commission's own enforcement powers over GPAI providers apply from 2 August 2026, and models already on the market before 2 August 2025 have until 2 August 2027 to comply. Providers can point to Codes of Practice and standardized templates - issued by the AI Office - as a recognized way of demonstrating compliance, and are expected to cooperate with regulators and share relevant documentation on request.

Practical steps. If you train or substantially fine-tune large models, track your cumulative training compute against the 10^25 floating-point operations marker proactively - don't wait for a Commission designation to find out you're already over it. Treat the training-data summary and copyright-compliance policy as standing deliverables that need to be kept current across model versions, not one-off documents. If you rely on the open-source carve-out, re-check that classification every time you retrain, since crossing into systemic risk cancels the exemption.

Why it matters. The Act doesn't hand you one compliance checklist - it hands you several, layered at the level of the use case, the model, the system, and the organization, and which ones apply depends on your role and on which risk tiers are actually in play. Treating this as a single linear project ("get compliant, then done") misses that the requirement set shifts as your AI portfolio and your roles shift.

What the law requires - a working compliance sequence.

1. Screen out prohibited practices first. Nothing else matters if a use case is banned outright - this has to be the first gate, not a later one.
2. Inventory and track high-risk AI. Identify every system you develop or use that clears either high-risk route (Annex III use case, or regulated product/safety component), and keep that inventory current as use cases evolve.
3. Run a gap analysis. For everything you've flagged as high-risk, measure current practice against the full requirement set and identify what needs to be built or fixed.
4. Register what needs registering. Get high-risk systems into the EU's public database once it opens - this is a discrete, trackable action item due before the 2 December 2027 application date, not a vague aspiration.
5. Roll out AI literacy training. Employees actually working with or governing these systems need to understand them and their risks - this is itself a legal requirement (see Section 12), not just good practice.

Conformity assessment, in brief. High-risk systems must go through a conformity assessment before they're placed on the market or put into service - the process exists to test, demonstrate, and formally declare that the system meets the Act's requirements. Which specific assessment procedure applies varies by system type, so this isn't a single universal form.

Limited-risk transparency obligations. A separate, lighter tier applies to systems that interact with people or generate content, independent of whether they're also high-risk. Article 50 has four parts:

• Providers must design systems that interact directly with people so that those people know they are dealing with AI, unless that is obvious to a reasonably informed person.
• Providers of systems that generate synthetic audio, image, video or text must mark the output as artificially generated in a machine-readable, detectable way, with exceptions for assistive and standard editing functions.
• Deployers of emotion-recognition or biometric-categorization systems must inform the people exposed to them.
• Deployers must disclose deep fakes, and AI-generated text published to inform the public on matters of public interest unless it went through human review and someone holds editorial responsibility; artistic and satirical works get a lighter disclosure.

The overlap point that trips people up. These categories are not mutually exclusive boxes - a system can be high-risk and separately subject to the limited-risk transparency rules (say, a high-risk recruitment tool with a chatbot front end: the hiring decisions are high-risk, and the chatbot owes the interaction notice). A GPAI model can be embedded inside a high-risk system, exist as a standalone product, or sit inside a system that isn't high-risk at all - and, in principle, a GPAI model embedded in a high-risk system can also be used in a way that triggers the transparency rules on top. The practical consequence: never answer "what do we have to comply with" for an AI initiative in the abstract - the honest answer always depends on the specific combination of role, risk tier, and use case in front of you.

Why it matters. Enforcement isn't centralized in one Brussels office - it's distributed across every member state plus two EU-level bodies, and different obligations came online on different dates rather than all at once. Knowing the actual calendar and the actual regulator map matters for anyone trying to sequence a compliance program realistically.

The regulatory landscape.

• Member state regulators. Each member state must appoint at least one market surveillance authority and at least one notifying authority (together, the "national competent authorities"), meaning multiple regulators typically operate within a single country, each responsible for a different slice of enforcement. One market surveillance authority is designated as the primary point of contact for the Act within that jurisdiction.
• The European AI Office. Sits inside the European Commission and is responsible for enforcing the rules on general-purpose AI models specifically - developing Codes of Practice and guidance, and working to keep enforcement of the Act coherent and coordinated across the EU.
• The European AI Board. Made up of one representative per member state, it works to harmonize how the Act is implemented across the bloc, issuing opinions and guidance, and is supported by an Advisory Forum and a Scientific Panel of experts.

Where things stand in September 2026. The Commission's AI Act Service Desk and Single Information Platform, launched 8 October 2025, are the official help desk, with an article explorer and a compliance checker (whose text has not yet been updated for the Omnibus). The Scientific Panel of independent experts and the Advisory Forum were appointed on 1 June 2026. Most member states have designated their market surveillance authorities; the EDPB has asked them (Statement 3/2024) to give that role to the data protection authorities for the Annex III use cases in law enforcement, migration, justice and democratic processes, and more broadly for high-risk systems that process personal data. The Commission's guidelines on high-risk classification are still a draft (19 May 2026); its Code of Practice on transparency of AI-generated content and the Article 50 guidelines were published in July 2026. No harmonized standard has yet been cited in the Official Journal, so the presumption of conformity under Article 40 is not yet available and providers work from the draft CEN-CENELEC JTC 21 standards.

Enforcement timeline.

The original Act set 2 August 2026 for most provisions and 2 August 2027 for Annex I systems. Regulation (EU) 2026/1744, adopted 8 July 2026 and in force from 27 July 2026, replaced those with the fixed dates above rather than a standards-linked trigger, softened the Article 4 literacy wording, added two prohibited practices, gave the AI Office direct competence over systems built on a general-purpose model from the same provider and over systems embedded in very large online platforms, and extended the SME simplifications to small mid-caps. Governance and penalties had already applied since 2 August 2025; what came in on 2 August 2026 is transparency, national market surveillance and the Commission's fines on general-purpose AI providers. The Annex III high-risk obligations now start on 2 December 2027 and the Annex I ones on 2 August 2028, and systems already on the market before those dates are caught only if their design changes significantly afterwards, with a backstop of 2 August 2030 for systems used by public authorities (Article 111).

Penalty tiers.

Each member state sets up its own penalty regime within these EU-wide ceilings. For SMEs and startups the ceiling is whichever of the two amounts is lower, not higher (Article 99(6)), and the Omnibus extended the same rule to small mid-caps for the 3% and 1% tiers (Article 99(6a)).

Practical steps. Build your compliance roadmap against the actual dated timeline above rather than treating "the AI Act" as one deadline - prohibited-practice screening and GPAI provider obligations were live well before the 2026 date most people associate with the law, and the high-risk regime now starts on 2 December 2027 rather than 2 August 2026. Identify which national competent authority is your primary point of contact in each member state where you operate, before you need to find that out under time pressure.

Why it matters. Point compliance with the Act - one gap analysis, one registration, one training module - doesn't hold up over time as your AI portfolio grows. A governance program needs standing structure so that new use cases get evaluated the same way every time, without reinventing the process per project.

What a program actually needs - 10 foundations.

1. A policy and standards framework. Written rules covering how AI gets developed, procured, deployed, and used - not a single AI policy document, but a coherent set that different teams can actually apply to their own decisions.
2. A risk management framework. A defined method for classifying and assessing AI risk, with clear ownership of each risk, oversight of the framework itself, and a reporting line that surfaces issues to people who can act on them.
3. A live AI inventory. Discover and catalogue every AI system, model, project, vendor relationship, and use case across the organization - you cannot govern what you haven't found, and shadow AI adoption is usually larger than leadership assumes.
4. A governance board with a real operating model. Defined roles and decision rights, not an advisory committee that meets quarterly with no authority to block a launch.
5. Third-party risk management specific to AI. Due diligence and ongoing risk assessment for every vendor and partner engagement that touches AI - general vendor security review isn't a substitute for this.
6. Regulatory horizon-scanning. Active monitoring of the regulatory landscape across every jurisdiction you operate in, feeding back into policy updates - the AI regulatory environment is moving faster than most compliance calendars are built for.
7. Metrics, assurance, and audit. A way to actually measure whether the governance program is working - not just whether it exists - and to periodically test that on the ground.
8. Education and training. Structured upskilling on AI ethics, governance, risk, and compliance across the workforce (see Section 12 for how to layer this).
9. Technical tooling and guardrails. Evaluate whether you need dedicated technology for testing, ongoing monitoring, and MLOps - governance that lives only in policy documents, with no technical enforcement, tends to erode under delivery pressure.
10. Alignment with existing digital governance functions. Privacy, cybersecurity, and data governance teams are already doing adjacent work - build AI governance to collaborate with them, not duplicate or compete with what already exists.

Practical steps. Stand up the inventory (foundation 3) early - most of the rest depends on knowing what you actually have. Resist building governance as a standalone silo; the fastest path to a workable program usually runs through extending structures (risk committees, vendor review, data governance) that already exist rather than creating parallel ones.

Why it matters. Before a new AI initiative gets built or deployed, someone needs to ask a consistent set of questions - not as a bureaucratic gate, but because the answers are what determine which of the Act's obligations actually apply, and what the real-world blast radius looks like if the system gets something wrong.

A practical internal risk-assessment framework - ten questions to put in front of every new AI initiative:

1. Purpose. What problem is this actually solving, and why does it need AI specifically rather than a simpler method?
2. Value. How much value does this generate, and how important is it to the business - worth understanding before you calibrate how much rigor the risk process gets.
3. Data rights. What data is used for development and for live input, and do you actually have the right to use it?
4. Geography. Which jurisdictions is the system being developed in, made available in, and used in?
5. Model choice. What type of model is being used, and why that type specifically, rather than a simpler or more explainable alternative?
6. Third-party dependencies. Does the system rely on any third-party models, tools, or services - and if so, whose obligations apply where?
7. Output. What does the system actually produce, and how is that output used downstream?
8. Human oversight. Is there human oversight, and - critically - can the person doing the overseeing actually verify and act on what the AI produced, or are they rubber-stamping it?
9. Impact of failure. What happens if the output is wrong, biased, or incomplete - who is affected, and how badly?
10. Ongoing monitoring. How will performance and usage be tracked over time, so that drift or failure gets caught rather than discovered after the fact?

Practical steps. Make this a standard intake form, not a one-off interview - the value is in asking every initiative the same ten questions, so risk levels are comparable across the portfolio rather than assessed inconsistently project by project. Route answers that reveal high-risk classification, prohibited-practice overlap, or weak human oversight to a mandatory second review before build work proceeds. For the data protection side of the same assessment, EDPB Opinion 28/2024 on AI models sets out how supervisory authorities decide whether a model trained on personal data is anonymous, when legitimate interests can support training and deployment, and what an unlawfully trained model means for the organizations that deploy it; the EDPB's harmonized DPIA template (14 April 2026) and its 2026 guidelines on anonymization and web scraping for generative AI supply the method.

Why it matters. As established in Section 5, a provider's shortcomings become the deployer's problem in practice: the deployer's own duties (oversight, monitoring, logs, transparency, the FRIA) cannot be met on a system the provider has not documented, even though a provider's breach is not automatically the deployer's infringement - so the procurement conversation with an AI vendor needs to go well beyond price and functionality. Treat this as the point where most of your actual downstream risk gets decided.

A practical due-diligence framework - ask every AI vendor:

1. Governance. What is your organization's own approach to AI governance and risk management - do they have one, or are they answering for the first time?
2. Training data. What data was used to train the system, and under what legal basis was it collected and used?
3. Use of your data. Will they use your organization's data to train, retrain, or otherwise improve their models and services - and did you actually agree to that?
4. Litigation exposure. Are they currently facing legal challenges or enforcement action related to the product?
5. IP indemnity. Will they provide copyright and intellectual-property indemnity protection if their system's output infringes someone else's rights?
6. Sub-dependencies. Are they themselves relying on third-party models, tools, or services to deliver this product - and do you know who those parties are?
7. Output ownership. What type of output does the system generate, and who actually owns it - you, or them?
8. Documentation. What guidance and instructions for use will they actually provide, in enough detail for you to meet your own deployer obligations?
9. Regulatory compliance. Can they demonstrate compliance with the AI Act and other applicable AI regulation - with evidence, not just assurance?
10. Support. What professional services and support will they provide for implementation and ongoing use?

Practical steps. Get answers to all ten in writing before contract signature, not as a post-signature follow-up - several of them (IP indemnity, data-use rights, output ownership) are things you want negotiated into the contract itself, not just disclosed informally. Treat a vendor who can't answer the compliance and documentation questions with specifics as a risk signal in itself, regardless of how good the product demo was.

Why it matters. AI literacy isn't a nice-to-have training slide - Article 4 of the Act has required providers and deployers to act on it since 2 February 2025. The original text asked for a "sufficient level" of AI literacy; Regulation (EU) 2026/1744 rewrote it so that providers and deployers must "take measures to support the development of AI literacy" of their staff and of others operating AI systems on their behalf, and Article 4(1) now says expressly that no specific level of AI literacy need be guaranteed for any individual. Enforcement sits with national market surveillance authorities from 2 August 2026. The obligation still underpins another one directly: human oversight of high-risk systems has to be assigned to people with the necessary competence and training, and that duty was not softened, so a literacy program remains the practical foundation for it.

A structure that actually differentiates by audience - four layers.

• Layer one: governance fundamentals for everyone. Mandatory, organization-wide, and deliberately simple - the goal is that every employee understands the basic pillars of responsible AI and the organization's own policies, not that they become experts.
• Layer two: generative AI enablement. Aimed at building comfort and skill using AI tools day to day - this layer works best when it's inspirational and interactive rather than compliance-flavored, and incentives like internal accreditation can help drive voluntary uptake.
• Layer three: role-based training. Tailored content for the specific people who build, buy, use, or govern AI as part of their actual job - governance staff, privacy staff, procurement staff, data scientists, IT partners - each needs different depth on different topics, and generic training tends to under-serve all of them at once.
• Layer four: system-specific operational training. The layer that matters most for anyone actually operating a high-risk system, or otherwise responsible for it, because Article 26(2) requires oversight staff with the competence, training and authority to do the job - bespoke instructions on exercising human oversight and other risk-mitigation duties for that specific system, precise enough that end users can actually interpret the system's outputs and recognize a serious incident when one happens.

Practical steps. Article 4 prescribes no curriculum, number of layers or certificate, so the four layers above are a recommended design, not a legal structure. What the amended text requires is evidence of measures that fit the audience and the risk exposure: a single generic module may be enough for an organization with low-risk tools and no oversight roles, and will rarely be enough where people are assigned to human oversight of a high-risk system, because that competence requirement is unchanged and specific. Tie layer four specifically to your high-risk system inventory (Section 3) so operational training rolls out to exactly the people who need it, not organization-wide by default.

Why it matters. Copyright protects original creative and intellectual work - books, articles, images, music, software - to encourage people to keep making it. Generative AI creates friction with that system at both ends: models are trained on enormous amounts of copyrighted material, and they can reproduce or closely resemble that material in their outputs. A second, separate question sits alongside the infringement risk: whether the organization's own AI-generated output is protectable at all. Both questions are now being answered by courts rather than commentators, and the answers so far point in one direction: how the training data was obtained, and what the model reproduces, matter more than the fact of training itself.

Where copyright exposure shows up across the AI lifecycle.

• Training. Base models are trained on large datasets that incorporate copyrighted material, often without individualized permission from each rightsholder. The first US merits rulings turned on how that material was acquired, not only on how it was used.
• Fine-tuning. Adjusting a pre-trained model on a narrower dataset can draw on copyrighted material just as the original training run did.
• Retrieval-augmented generation. RAG systems pull from a retrieval corpus at query time - if that corpus contains copyrighted material, it can be reproduced in the augmented output.
• Prompts and inputs. Users routinely upload or paste copyrighted material - images, documents, text excerpts - directly into prompts, sometimes without thinking of it as a copyright-relevant act.
• Inference and outputs. Generated content can reproduce, or come close enough to resemble, existing copyrighted work. This is now the live battleground: lyrics, characters and verbatim article text are what the 2025 and 2026 cases are about.

Whether AI output itself is copyrightable. Across most jurisdictions, some degree of human authorship is required for copyright to attach - content that is purely AI-generated, with no meaningful human creative input, generally isn't protectable, while "AI-assisted" work often is. The dividing line is the nature and degree of human creative contribution: in the US, typing a prompt isn't enough on its own, but the analysis changes once a human's own creative choices are perceptible in the resulting output. The Supreme Court declined on 2 March 2026 to review Thaler v Perlmutter, which leaves the D.C. Circuit's human-authorship holding standing without endorsing it; where the line falls for prompted or AI-assisted work remains fact-specific and is being worked out by the Copyright Office and the lower courts.

A comparative regulatory snapshot - the applicable rules are generally determined by where the copying itself took place, and the landscape still diverges sharply by jurisdiction:

Litigation and the fair-use test. The most cited US tracker counted 142 copyright suits against AI companies on 15 September 2026, up from the high thirties two years earlier, and the milestones to watch are the Third Circuit in Ross, the Court of Justice in Like Company, the Munich appeal court in GEMA v OpenAI and the Court of Appeal in Getty. US courts assess fair use through four factors: the purpose and character of the use, the nature of the copyrighted work, the amount and substantiality of the portion used, and the effect on the market for the original work. The rulings so far treat training on lawfully obtained material as strongly transformative and treat piracy, memorization and output reproduction as the exposure.

Practical steps to mitigate risk.

• License deliberately, and prove provenance. Prefer data and content that's explicitly licensed for use in AI training or generation. The distinction between lawfully acquired and pirated material was decisive in Bartz, and the settlement priced the difference at about USD 3,000 per work.
• Negotiate contractual protection. Push for IP indemnity clauses in vendor and licensing agreements rather than assuming the risk sits with the AI provider by default, and cover outputs as well as training, since the largest settlement so far excluded outputs.
• Test for memorization and output reproduction. Lyrics, characters and verbatim article text are what the live cases turn on. Build output filtering and reproduction testing into deployment, not only into training due diligence.
• Track data lineage. Make copyright provenance a standing part of your AI risk assessments, not a one-time diligence exercise done at the start of a project.
• Train employees on prompting and uploads. A large share of practical exposure comes from ordinary employees pasting copyrighted documents, images, or text into prompts without thinking about it - this is a literacy-program topic (see Section 12), not just a legal one.
• Meet the GPAI training-data transparency obligation. If you provide general-purpose AI models, the training-data summary from Section 6 and the Code of Practice copyright measures directly overlap with copyright risk management - a legal obligation and a genuine risk-reduction step, now backed by Commission fining powers.