How do you prepare for the EU AI Act?
AI regulation: the EU AI Act
Prepare for the EU AI Act by following a practical sequence: identify which systems in your organisation are actually in scope, map your role for each one, screen out prohibited uses, classify likely high-risk use cases, organise proportionate AI literacy, get ready for Article 50 transparency duties, and keep simple records and review points. As at 21 July 2026, the core law is in force, but an adopted AI Omnibus was still awaiting Official Journal publication, so some future deadlines were still on a dual track.
What this means
The easiest way to prepare is not to start with legal theory. Start with a usable register of where AI is already being used, bought, piloted, or built. Then work system by system: what it does, who uses it, whose interests it affects, whether it generates synthetic content, whether it sits in a sensitive Annex III area, and whether your organisation is acting as a provider, deployer, importer, distributor, or something more than one of these at once.
That matters because the EU AI Act does not apply in one single way to "AI" as a whole. It applies by role, by risk category, and by the type of obligation involved. Some duties are already live, including AI literacy and the prohibited practices. Some transparency duties start on 2 August 2026. High-risk timing is more complicated, because the adopted Digital Omnibus on AI had not yet been published in the Official Journal on 21 July 2026, so the current-law dates formally still stood even though the adopted text would move some of them.
This page is therefore about operational readiness, not legal advice. It is the ordered path a non-specialist can follow before deciding whether a more complex system, contract structure, or borderline use case needs specialist advice.
Why it matters
If you wait until a regulator, customer, works council, buyer, or board member asks which AI systems you use and why they are lawful, you are already late. The AI Act matters operationally because it turns ordinary product, procurement, HR, customer service, publishing, and governance choices into traceable compliance questions.
For many organisations, the first real exposure will not come from a fine. It will come from poor internal visibility. Teams may already be using recruiting tools, decision support systems, chatbots, synthetic media tools, or embedded model features without anyone having a joined-up picture of role, risk, human oversight, disclosure, or record-keeping. That is exactly why the first readiness move is an inventory.
This also matters commercially. Buyers increasingly ask vendors to explain whether a system is high-risk, whether outputs are labelled, whether staff are trained, whether human oversight exists, and whether a supplier has thought through its provider versus deployer position. A lightweight but disciplined preparation programme helps you answer those questions without pretending every tool needs a full legal implementation project.
How it works
Start with an AI use inventory, not with abstract policy
Build one working list of the AI systems your organisation builds, configures, buys, pilots, embeds, or uses. Include internal tools, public-facing systems, third-party software with AI features, and systems that generate synthetic text, images, audio, or video. This is the practical foundation for every later judgement.
For each system, record at least: the business function, intended purpose, vendor or builder, model or product name, who uses it, whether it affects customers, employees, students, patients, voters, or members of the public, whether it generates or manipulates synthetic content, whether it is used in a sensitive Annex III area, whether special category data is involved, whether there is any human review, and the current operational status. If you need a template or a fuller method, that belongs on the separate AI use-case inventory page, not here.
Also check whether the thing really is an "AI system" for AI Act purposes. The Commission's AI-system-definition guidance is non-binding but useful, and it exists precisely because organisations need a practical way to distinguish in-scope systems from ordinary software. If your inventory is disciplined, later classification work becomes much easier.
Map your role for each system before you assess duties
Do not assume that buying a tool makes you "just a user". Under the Act, organisations can be deployers, providers, importers, distributors, or authorised representatives, and the same group may occupy more than one role across different systems. The Commission's FAQs use an accessible example: the developer of a CV-screening tool is a provider, while a bank using that tool is a deployer.
The role question must be asked system by system. If you use a vendor product exactly as supplied, you may be mainly a deployer. If you put your name on it, substantially modify it, or change its intended purpose so that it becomes high-risk, responsibilities can shift. That issue matters especially where teams fine-tune, repackage, chain models together, or build decision workflows around a third-party base system. For more detail on roles, see the separate pages on who the EU AI Act applies to and on deployer obligations.
A good practical test is this: who decides the intended purpose, who controls the system design or major modification, who puts it on the EU market or into service under their name, and who uses it in context? If the answer is split across vendor, integrator, and customer, the position is already complex enough to document carefully and may justify advice.
Screen first for prohibited practices
Before spending time on high-risk classification, check whether the use case should simply not exist. The Article 5 prohibitions have applied since 2 February 2025. Commission guidance published on 4 February 2025 gives practical explanations and examples, but it is non-binding and does not replace the law.
For a non-specialist readiness pass, ask a short set of red-flag questions. Are you using AI for manipulative or exploitative practices, social scoring, certain forms of biometric categorisation or emotion recognition, untargeted facial image scraping, or prohibited law-enforcement use cases? If yes, stop and escalate.
As at 21 July 2026, there is also an important timetable point. The adopted Digital Omnibus on AI had not yet been published in the Official Journal, so the current law in force still governed. However, the adopted text would add new Article 5 prohibitions aimed at AI systems that generate non-consensual intimate imagery and child sexual abuse material, with a future application date of 2 December 2026 once the amending regulation enters into force. Read that as a preparation signal now, not as a reason to wait.
Then classify against Annex III, but be honest about the guidance status
If the system is not prohibited, the next question is whether it looks high-risk. For most operators, the most practical first pass is Annex III. That annex covers sensitive use cases including biometrics, critical infrastructure, education, employment, essential services such as credit scoring and some insurance uses, law enforcement, migration and border management, and parts of justice and democratic processes.
This is where many organisations go wrong. They jump straight to "not high-risk" because the system is not making the final decision. That is not a safe shortcut. Many Annex III entries are drafted broadly around intended use, including scoring, ranking, evaluating, triaging, filtering, dispatching, or supporting consequential decisions.
Use the Commission's draft high-risk classification guidelines as a working aid, but state their status honestly. On 21 July 2026 they were still draft guidance, the consultation remained open until 23 July 2026, and the final guidelines had not yet been adopted. They are helpful, but they are not yet the settled interpretive baseline.
Also separate the two high-risk tracks. One track concerns stand-alone AI systems under Article 6(2) and Annex III. The other concerns AI that is a safety component of a regulated product, or the product itself, under Article 6(1) and Annex I. If your system touches medical devices, machinery, aviation, vehicles, lifts, toys, or other product-safety frameworks, assume you are in more technical territory and escalate earlier.
If you conclude a system is not high-risk, keep the dated rationale. The AI Act includes a procedure for authorities to revisit a provider's "non-high-risk" conclusion in Annex III cases. A light record is far better than a missing one.
Set up a proportionate AI literacy programme now
Article 4 has applied since 2 February 2025. The Commission's AI literacy Q and A makes clear that this is not a one-size-fits-all training mandate, and it does not require you to test every employee's knowledge. The same Q and A suggests a practical minimum approach: make sure the organisation has a basic understanding of what AI is, what AI is used internally, what role the organisation plays, and what risks matter for each system. Then tailor actions to staff knowledge, use context, and the people affected.
In practice, that means three layers are usually enough for a first pass. First, a short general briefing for all staff on approved use, escalation routes, common risks, and what is not allowed. Second, role-based material for teams who procure, configure, publish, or rely on AI outputs, such as HR, legal, procurement, communications, product, and security. Third, focused operational training for owners of high-risk or near-high-risk systems.
There is one more status point to handle carefully. As at 21 July 2026, Article 4 already applied under the law in force. The adopted Omnibus, still awaiting publication, would amend the wording so that providers and deployers must take measures to support AI literacy and would clarify that they need not guarantee any specific level for each individual. That is relevant context, but it was not yet the law on 21 July 2026. So the safe operational approach is still to run a proportionate, risk-based literacy programme now.
Get ready for Article 50 transparency duties before 2 August 2026
Article 50 does not regulate "all GenAI". It creates specific transparency duties for certain systems and uses. The Commission adopted Article 50 guidelines on 20 July 2026, one day before this article's verification date, and they are directly relevant to readiness.
Providers must design directly interactive AI systems so people are informed they are interacting with AI, unless that is obvious. Providers of systems that generate synthetic audio, image, video, or text must apply machine-readable marking and enable detection of AI-generated or AI-manipulated content, subject to the law's limits and the practical scope explained by the Commission guidance. Deployers must inform people when they are exposed to emotion recognition or biometric categorisation systems, and must clearly label deepfakes and certain AI-generated or manipulated text published on matters of public interest without human review or editorial control.
For readiness, you do not need a perfect technical architecture on day one. You do need a scoped list of where these disclosures and markings will be needed: chatbots, AI agents, public web interactions, avatars, customer support tools, content pipelines, creative systems, video tools, newsroom or public affairs publishing workflows, and synthetic media outputs. Tie this back to your inventory, and decide where the obligation sits with you, the vendor, or both.
There is also a dual-track timing issue here. Under the law in force on 21 July 2026, Article 50 applies from 2 August 2026. The adopted Omnibus does not move that general date. However, once published and in force, it would create a limited grace period for providers of systems that generate synthetic content and were already placed on the market before 2 August 2026, giving them until 2 December 2026 to comply with Article 50(2). That grace period is narrow. It does not postpone Article 50 as a whole.
Put lightweight governance in place
Most organisations preparing for the AI Act do not need an elaborate committee structure first. They need a small, working operating model. Name an accountable owner. Decide who approves new AI use cases. Create mandatory review points for procurement, deployment, substantial modification, and public-facing release. Keep dated records of role, classification, prohibited-practice screening, Article 50 relevance, training actions, incidents, and key vendor assurances.
One short policy is usually enough for a first version if it covers: approved and prohibited use, required human review, disclosure and labelling rules, data handling expectations, procurement checks, sign-off points, and escalation paths. A short quarterly review cycle is usually enough for ordinary systems. Higher-risk or customer-facing systems may need more frequent review.
If you use vendors, ask for the information you will later need anyway: intended purpose, instructions for use, output limitations, human oversight expectations, logging or traceability options, Article 50 support, and whether the supplier treats the tool as high-risk or out of scope, with reasons. For a fuller governance model, see the separate page on AI governance.
Keep a dated watchlist, because the timetable was still split on 21 July 2026
As at 21 July 2026, the AI Act in force was Regulation (EU) 2024/1689. It entered into force on 1 August 2024. The provisions already applicable were the Article 5 prohibitions and Article 4 AI literacy from 2 February 2025, and the GPAI, governance, penalties and related institutional provisions from 2 August 2025.
Under the law in force on 21 July 2026, the general application date for most remaining provisions was 2 August 2026, including Article 50 transparency. The pre-Omnibus current-law position also still mattered for high-risk timing until publication of the amending act. Current Commission material before publication still reflected 2 August 2027 for AI systems that are high-risk because they are embedded in regulated products.
But the adopted Digital Omnibus on AI changed the expected future path. OEIL showed procedure 2025/0359(COD) as completed and awaiting publication in the Official Journal; EUR-Lex did not yet show a final published regulation number or Official Journal citation on 21 July 2026. So the legally careful preparation stance on that date was: current-law dates still formally stand, but the adopted text is highly likely to alter the future timetable once published.
Operationally, keep these dates in your watchlist: 2 August 2026: Article 50 transparency duties start under the law in force, and the current-law general application date arrives. 2 December 2026: if the Omnibus enters into force, new Article 5 prohibitions on non-consensual intimate imagery and child sexual abuse material apply, and providers of pre-2 August 2026 synthetic-content systems get to this date for Article 50(2) marking compliance. 2 August 2027: under pre-Omnibus current law, this remained the date associated with certain embedded-product high-risk systems, while under the adopted Omnibus it becomes the national sandbox operational deadline. 2 December 2027: if the Omnibus enters into force, this becomes the outer-limit application date for stand-alone Annex III high-risk obligations. 2 August 2028: if the Omnibus enters into force, this becomes the application date for Annex I embedded-product high-risk obligations.
For the full dates picture, see the EU AI Act timeline page. For role detail, see the page on who the Act applies to. For deployer-specific obligations, see the deployer obligations page.
Examples
A company uses a third-party CV-screening tool in recruitment. The vendor is likely the provider and the employer is likely the deployer, but that should be checked against the actual configuration and branding. Employment and worker management are Annex III areas, so this is exactly the kind of use case that should be inventoried, role-mapped, screened for prohibition issues, and classified early. Even if the adopted Omnibus later shifts the Annex III obligation date to 2 December 2027, the employer should not wait to organise oversight, vendor documentation, and training.
A public-facing chatbot or AI agent is launched on a website or in customer support. If it directly interacts with natural persons, Article 50 readiness matters. Under the Commission's July 2026 guidance, the provider should ensure users are informed from the start of the interaction unless the AI nature of the interaction is obvious. If the same system also generates synthetic text, image, audio, or video outputs, the provider should also assess marking and detectability duties under Article 50(2).
A communications team publishes AI-manipulated video or AI-generated text on a matter of public interest. That raises deployer duties under Article 50 even where the underlying tool is purchased from a supplier. Deepfakes need clear labels, and certain public-interest text published without human review or editorial control also needs labelling. If the organisation built or supplied the system itself, provider-side marking duties may be relevant as well. This is why Article 50 preparation belongs in editorial, brand, and marketing workflows, not only in legal or procurement.
Common misunderstandings
"The Omnibus already changed the timetable." Not yet, as at 21 July 2026. The adopted Digital Omnibus on AI was still awaiting Official Journal publication, so the current-law dates formally still stood on that day.
"The Omnibus delays Article 50." No. The adopted text leaves the general Article 50 start date at 2 August 2026. What it adds is a limited grace period for providers of synthetic-content systems placed on the market before 2 August 2026, and even that concerns Article 50(2), not Article 50 as a whole.
"AI literacy means every employee must pass a formal AI test." No. The Commission's AI literacy Q and A says Article 4 does not require measuring employees' knowledge and does not impose a rigid programme. A proportionate, role-based approach is the practical route.
"If we buy the tool, the vendor carries all responsibility." Not necessarily. You may still be a deployer, and if you rebrand, substantially modify, or change intended purpose, responsibilities can move.
"If our vendor says the system is not high-risk, that ends the matter." No. Your organisation should keep its own dated rationale, because authorities can revisit a provider's non-high-risk classification in Annex III cases.
Risks and boundaries
This article is a readiness path, not legal advice, and not a substitute for system-specific analysis. It is designed for non-specialists who need to get organised before instructing counsel or commissioning a fuller governance project.
The biggest boundary is classification uncertainty. On 21 July 2026, the Commission's high-risk classification guidance was still only draft guidance, with the consultation open until 23 July 2026. You can use it to structure assessment, but not to claim settled interpretation.
The second boundary is status uncertainty around the adopted Omnibus. I checked both the OEIL procedure file and EUR-Lex procedure materials at run time. On 21 July 2026, I did not find Official Journal publication of the amending regulation, and OEIL showed the procedure as completed and awaiting publication. That means the law in force and the adopted post-publication timetable were still distinct on that date. Publication is the legal switch that turns the adopted timetable into operative law.
The third boundary is complexity. Take advice sooner if the system touches biometrics, emotion recognition, law enforcement, migration, democratic processes, regulated products, substantial modification, public authority use, or important rights decisions in employment, education, health, insurance, credit, or access to essential services. The same is true if your contract chain makes role allocation unclear, or if you are relying on a "not high-risk" conclusion in a borderline Annex III case.
What to do next
Name one accountable owner for AI Act readiness this quarter.
Build or refresh an AI use inventory that includes business function, role, risk signals, Article 50 relevance, and current status.
Run a first-pass red-flag review for prohibited practices and a second-pass screen against Annex III categories.
Stand up a proportionate AI literacy programme now, with a short general module and role-based material for teams that buy, configure, review, publish, or rely on AI outputs.
Prepare an Article 50 control list before 2 August 2026: direct interaction notices, machine-readable marking where relevant, deepfake labels, and public-interest text labelling where relevant.
Publish a lightweight internal policy with review points, minimum records, vendor-question sets, and an escalation route for substantial modification, high-risk classification, and public-facing synthetic content.
Keep a dated watchlist and re-check the Omnibus publication status before 2 August 2026, because publication changes which future high-risk dates you should plan against.
FAQs
Do we need a full legal implementation project before doing anything?
No. The practical first step is an inventory and triage exercise. Most organisations can make real progress before taking legal advice by identifying systems, mapping roles, screening for prohibitions, and preparing Article 50 and literacy measures.
What should be in our first AI inventory?
Enough to support role, risk, and transparency judgements: system name, purpose, owner, vendor or builder, who uses it, who is affected, whether it generates synthetic content, whether it sits in an Annex III area, whether there is human review, and whether the system is live, piloting, or planned.
How do we know whether we are a provider or a deployer?
Start with intended purpose, control over design or major modification, branding, and who uses the system under whose authority. A buyer often acts as a deployer, but rebranding, substantial modification, or changing intended purpose can move an organisation into provider territory.
Are all chatbots covered by Article 50?
Not all in the same way. The core question is whether the system directly interacts with natural persons and whether it is obvious they are using AI. Some chatbots will also raise separate obligations if they generate synthetic content.
Should we wait for the final high-risk classification guidelines before doing Annex III analysis?
No. You should use the draft guidance as a working aid, while being explicit that it is still draft. Waiting defeats the point of preparation, especially if your systems sit in employment, education, essential services, biometrics, or other sensitive areas.
Does the adopted Omnibus mean high-risk work can stop until late 2027?
No. As at 21 July 2026, publication was still pending, so the current-law timetable formally still mattered. More importantly, even if the Omnibus enters into force and moves certain deadlines, you still need the inventory, role mapping, governance, training, and vendor evidence in place well before those dates.
When should we take specialist advice?
Take advice when the role allocation is unclear, the system may be prohibited or high-risk, the use is rights-significant, the system is embedded in a regulated product, the organisation is making substantial modifications, or the operational consequences of getting the position wrong are material.