A customer support assistant, a recruitment tool and a system that generates marketing images may all use AI. They do different jobs, affect different people and create different obligations. That is where a useful conversation about the EU AI Act starts: with what the system actually does.
For companies planning their next release, September 2026 brings a particular challenge. Some duties already apply, while the deadlines for the main high-risk requirements have moved. An old compliance slide can now be as misleading as having no plan at all.
Regulatory position checked: 24 September 2026. This is a practical business overview. Classification and legal duties depend on the system, your role and the applicable transitional provisions; review consequential deployments with qualified legal counsel.
The dates your team should be working with
The Commission confirms that the AI Omnibus entered into force on 27 July 2026. Its changes include later application dates for high-risk systems. They do not postpone the entire Act. Source: European Commission’s current AI Act overview.
- 2 February 2025: the original prohibited-practice rules and AI literacy obligations began applying.
- 2 August 2025: general-purpose AI model obligations began applying, with transitional treatment for older models.
- 2 August 2026: most remaining provisions, including Article 50 transparency duties, became applicable.
- 2 December 2027: the principal high-risk requirements for Article 6(2)/Annex III systems, including qualifying employment and education uses, apply.
- 2 August 2028: the corresponding requirements for Article 6(1)/Annex I product-related high-risk systems apply.
The later high-risk dates are confirmed by the Council’s final adoption announcement. Separately, providers of synthetic-content systems placed on the market before 2 August 2026 have until 2 December 2026 to meet Article 50(2)’s marking requirements. That targeted transition is not a general extension of chatbot disclosures or deployer labelling duties. Source: adopted legislative text, amendment to Article 111.
Start with scope and responsibility
Being based in Switzerland does not automatically put a company outside the Act. Article 2 covers providers supplying the EU market and can also cover providers or deployers outside the EU where their system’s output is used in the Union. The territorial connection needs assessment; a Swiss address alone does not settle it. Source: AI Act, Article 2.
Next, establish whether the company is a provider, a deployer, or plays more than one role. Broadly, a provider develops a system, or has it developed, and supplies or puts it into service under its own name. A deployer uses a system under its authority. Buying a tool does not remove the need to understand the company’s own obligations. Source: Commission guidance on providers and deployers.
A useful first deliverable is an AI inventory. For each use, record the business owner, purpose, supplier, affected people, data inputs, countries served and degree of autonomy. Include AI features inside existing software subscriptions. A procurement list will miss tools that teams have enabled themselves.
Check prohibited uses before discussing a roadmap
Some practices are already prohibited. One relevant example is AI emotion recognition in the workplace, subject to narrow medical or safety exceptions. Recruitment, worker management and creditworthiness assessment can also fall within high-risk categories, depending on the precise use. Classification follows intended purpose and operation, so review the workflow rather than relying on a vendor’s product category. Source: Commission AI Act questions and answers.
For example, generating a draft job description and ranking candidates for rejection are materially different activities. Put the second through a dedicated review. Ask what the system infers, which decisions it influences and whether a reviewer has the information and authority to challenge it.
Transparency belongs in the product experience
Article 50 separates several responsibilities. Providers of systems interacting directly with people must ensure people are informed that they are dealing with AI, unless this is already obvious in the circumstances. Generative-system providers have technical marking duties. Deployers have disclosure duties for deepfakes and certain AI-generated public-interest text, with specific exceptions and qualifications, including human editorial control and responsibility for text. Source: AI Act, Article 50.
The practical task is to inspect the actual customer journey. Where does the interaction begin? Is the disclosure understandable before a person relies on the answer? What happens when generated material is exported, republished or edited? Keep a record of the decisions and verify that labels survive the publishing workflow. The Commission’s transparency code guidance distinguishes technical marking from visible labelling and explains the code’s voluntary status.
Make AI literacy specific to the work
AI literacy remains an obligation after the Omnibus. The amended Article 4 requires measures supporting its development, without mandating a particular individual proficiency level. The Commission does not prescribe a universal certificate or a specific AI governance structure. Source: Commission AI literacy Q&A, including the 2026 amendments.
A sensible programme starts with real tasks. A support agent needs to recognise an invented answer and know when to escalate. A manager needs to understand the limits of AI-generated performance summaries. An engineer needs to test permissions and failure behaviour. Short, relevant exercises are more useful than treating attendance at a generic presentation as evidence that everyone can use every tool safely.
Use the high-risk transition to build evidence
The high-risk framework includes risk management, data governance, technical documentation, traceability, human oversight, accuracy, robustness and cybersecurity. Provider and deployer duties differ; the appropriate preparation depends on which role the company holds. Source: Commission overview of high-risk requirements.
In procurement, ask for usable evidence: intended and excluded uses, evaluation results relevant to your users, change notifications, monitoring capabilities and incident contacts. Agree who will act if performance deteriorates. A supplier’s broad promise of “responsible AI” is difficult to turn into a release decision.
Internally, give an owner the ability to pause a problematic deployment. Test how staff detect mistakes and recover from them. Revisit the assessment when the model, data, purpose or level of autonomy changes. Continue the existing privacy, employment and security reviews alongside the AI work; an AI assessment should not replace them.
A practical plan for the next 30 days
- Week one: establish visibility. Interview department leads and build the inventory. Name an accountable executive and an operational owner for each system.
- Week two: triage the exposure. Review prohibited uses, territorial scope and potential high-risk cases. Fix missing disclosures in active customer journeys.
- Week three: test the working process. Run role-specific training, request missing supplier evidence and rehearse an escalation using a realistic failure.
- Week four: approve a funded plan. Assign owners and dates to remaining gaps. Keep urgent applicable duties separate from longer-term high-risk preparation.
These are suggested operating steps, not statutory milestones. Their purpose is to make the next AI decision easier to explain: what is being released, why it is useful, which limits apply and who will intervene if the system fails.
Good preparation also supports growth. A team that understands the evidence needed for approval can plan releases and customer commitments more reliably. The management question becomes concrete: can we demonstrate that this AI system is ready for this particular use?
Related: CAIO, Head of AI and the Team Behind AI Growth explores how to assign that responsibility across the organisation.