EU AI Act for Businesses: 12 Moves Before 2027

A single unrecorded model update can turn a routine automation into a regulatory event. i have seen the same weakness repeatedly in enterprise AI programmes: teams can explain what a system does, but cannot show who classified it, which version was approved, what evidence supports the decision, or how a supplier change would be detected. The EU AI Act for businesses converts those gaps into legal and operational risk. This article explains who is covered, how the risk tiers work, what changed in the May 2026 political agreement, and how to build a practical compliance system before the revised high-risk deadlines.

The Act applies through a tiered, risk-based framework. Some uses are prohibited. High-risk systems remain permitted but require extensive lifecycle controls. Chatbots and synthetic content carry transparency duties. General-purpose AI models sit under a separate framework, with additional obligations where a model presents systemic risk. The rules can reach a company outside the Union when it places an AI system or model on the EU market, puts it into service in the EU, or when the output is used in the EU.

The immediate business task is not to produce a giant policy. It is to establish an auditable chain from business purpose to legal role, risk category, technical controls, evidence, human accountability and supplier obligations. The analysis below is current to 20 June 2026 and distinguishes the enacted Regulation from the Commission’s 7 May 2026 political agreement on simplification. That distinction matters because many online checklists still present 2 August 2026 as the high-risk deadline, even though the agreed timetable now points to 2 December 2027 for Annex III systems and 2 August 2028 for high-risk systems embedded in regulated products.

1. EU AI Act for Businesses: What Applies in 2026

The Regulation is already partly operational. It entered into force on 1 August 2024. The prohibitions in Article 5 and the AI literacy duty in Article 4 began applying on 2 February 2025. Governance provisions and obligations for providers of general-purpose AI models began applying on 2 August 2025. Article 50 transparency obligations are scheduled to apply from 2 August 2026, while the high-risk calendar was revised by the political agreement reached on 7 May 2026.

For a business, the decisive question is not whether it calls a product “AI”. The legal analysis turns on the Act’s definition, the system’s intended purpose, the context in which it is used, and the company’s role in the value chain. A firm may be a provider because it develops a system, has one developed and markets it under its name, or makes a substantial modification. It may be a deployer when it uses a system under its authority. It may also be an importer, distributor, product manufacturer or authorised representative. One group company can occupy different roles for different systems.

The extraterritorial reach is commercially important. A US, UK, Pakistani or Singaporean supplier can fall within scope by offering an AI system or model in the EU. A non-EU deployer can also be caught where the output produced by the system is used in the Union. That means a London-based lender using a non-EU model to assess customers in Paris cannot treat the Act as a vendor-only issue. It needs its own operator analysis, deployment controls and contractual evidence.

Henna Virkkunen, the European Commission Executive Vice-President responsible for tech sovereignty, told The Economic Times in February 2026 that “Rules are necessary, but they must support innovation rather than stifle new ideas.” The operational implication is sensible: use proportional controls, but do not confuse proportionality with informality. The business still needs a documented basis for why a control is sufficient.

2. Classify the Risk Before Buying More Technology

Risk classification should precede procurement, deployment and budget approval. A central inventory without classification is merely a list. A classification without evidence is merely an opinion. The strongest operating model records the intended purpose, affected people, decision consequence, data types, automation level, model and version, geographic use, operator role, supplier, integrations, human review and the legal basis for the selected tier.

Unacceptable-risk practices are prohibited rather than licensed. Examples include certain manipulative or exploitative techniques, social scoring, some biometric categorisation based on sensitive characteristics, untargeted scraping of facial images, emotion recognition in workplaces and schools subject to narrow exceptions, and tightly restricted real-time remote biometric identification by law enforcement in public spaces. Businesses should treat a plausible Article 5 match as an immediate stop-and-escalate event.

Risk category	Typical business example	Core legal response	First control
Unacceptable	Prohibited social scoring or exploitative manipulation	Do not place, offer or use	Stop, preserve evidence, escalate to legal and compliance
High-risk	Recruitment ranking, credit scoring, essential-service eligibility	Lifecycle duties, conformity, registration and monitoring	Create a complete evidence file and accountable owner
Transparency risk	Chatbot, emotion or biometric categorisation disclosure, deepfake	Inform users and mark or disclose synthetic content	Design notice and provenance controls into the interface
Minimal risk	Low-impact productivity assistant	Voluntary governance plus other applicable law	Apply baseline security, privacy and human review
GPAI	Foundation model supplied for many downstream purposes	Model documentation, copyright policy and downstream information	Map whether the company is provider, modifier or downstream integrator

High-risk status can arise because an AI system is a safety component of a regulated product or because it falls within an Annex III use case. Common business exposures include recruitment and worker management, access to education, creditworthiness, certain insurance risk assessments, essential services, critical infrastructure and some biometric uses. In employment, a screening model that materially influences who is interviewed is more consequential than a tool that formats a job advert. Our related review of HR governance controls shows why workflow context matters more than a vendor’s generic product label.

Limited-risk duties focus on transparency. Users may need to know they are interacting with AI, and synthetic audio, image, video or text may need machine-readable marking or disclosure. Minimal-risk systems are not subject to the same prescriptive obligations, but other laws still apply, including data protection, consumer protection, employment, equality, product safety, intellectual property and sector rules.

3. The Revised Compliance Timeline and Its Traps

The original Regulation used staged application dates, but the 2026 simplification process changed the practical high-risk timetable. On 7 May 2026, the Council and European Parliament reached a political agreement that places the Annex III high-risk rules on 2 December 2027 and high-risk systems embedded in regulated products on 2 August 2028. Businesses should record that this is a political agreement and implementation position, not silently rewrite archived legal advice as though the original text never existed.

The delay is not a permission to pause. Article 5 prohibitions and AI literacy already apply. GPAI obligations already apply to models placed on the market after 2 August 2025, and the Commission’s enforcement powers for GPAI providers begin on 2 August 2026. Pre-existing GPAI models placed on the market before 2 August 2025 have until 2 August 2027. Article 50 transparency obligations remain a near-term delivery issue from 2 August 2026.

Date	What applies	Business action now
2 February 2025	Prohibited practices and AI literacy	Remove prohibited uses; train staff according to role and exposure
2 August 2025	Governance and GPAI provider duties	Classify models, prepare provider documentation and downstream disclosures
2 August 2026	Article 50 transparency; GPAI enforcement powers	Deploy notices, provenance controls and submission readiness
2 August 2027	Compliance for GPAI models placed before 2 August 2025	Complete legacy model remediation and evidence
2 December 2027	Annex III high-risk systems under the 2026 political agreement	Complete conformity, registration, controls and deployer procedures
2 August 2028	High-risk AI embedded in regulated products	Align product conformity and AI evidence in one assurance plan

The trap is to run compliance as a deadline project. A high-risk file requires technical documentation, data governance evidence, logs, human oversight design, accuracy and robustness testing, cybersecurity controls, quality management, registration, conformity activity and post-market monitoring. Most of those artefacts depend on months of engineering and procurement work. A company that waits until the final quarter will discover that its supplier cannot provide training-data summaries, its logging is not granular enough, and its business owner cannot explain what human oversight means in a live queue.

The European industrial debate is also shifting. In May 2026, seven CEOs from ASML, Airbus, Ericsson, Mistral AI, Nokia, SAP and Siemens wrote that “Europe is still debating regulation” while others are scaling physical AI and robotics. That pressure helps explain simplification, but it does not remove the need for operational proof.

4. Map Every Legal Role Across the AI Supply Chain

A single AI service can create a chain of providers, deployers, importers, distributors, integrators and product manufacturers. The most expensive classification error is assuming that a company remains a deployer when its conduct makes it a provider. Rebranding a third-party system under the company’s own name, changing the intended purpose, or making a substantial modification can transfer provider duties.

Start with a role map for each use case, not one role for the whole organisation. Record the base model provider, hosting provider, fine-tuning party, application developer, reseller, customer-facing entity, deployer and the legal entity that determines purpose. For agents, add tool providers and data sources because an agent’s effective capability depends on the permissions and systems it can invoke. This is central to agentic workflow governance, where responsibility can move as an agent gains authority to execute transactions rather than merely recommend them.

The value-chain map should connect to a responsibility matrix. Legal interprets scope and role. Product owns intended purpose and change control. Engineering owns implementation and testing. Data teams own provenance, quality and representativeness. Security owns threat modelling, access control and incident integration. Procurement owns supplier evidence and remedies. The business process owner defines human oversight and operational thresholds. Internal audit tests whether the stated controls actually operate.

Do not let the supplier’s compliance statement substitute for your own duties. Deployers of high-risk systems must use the system according to instructions, monitor operation, ensure relevant input data where they control it, assign competent human oversight, retain logs within their control, and act when risk or serious incidents appear. Employers may also need to inform workers or representatives before workplace deployment. In some decisions, affected people can have a right to an explanation of the role the high-risk system played.

A useful test is simple: if the regulator asked which legal entity changed the model, approved the use, monitored the output and could stop the system today, could the organisation answer in one page? If not, the role map is incomplete.

5. High-Risk Systems Need an Evidence-Producing Control System

EU AI Act for Businesses Conformity Workflow

High-risk compliance is not a certification sticker added at launch. It is a lifecycle system. The provider must establish risk management, data and data-governance controls, technical documentation, automatic record-keeping, instructions for deployers, human oversight, and appropriate accuracy, robustness and cybersecurity. It must operate a quality management system, keep required documentation, take corrective action, cooperate with authorities, complete the applicable conformity assessment, draw up an EU declaration of conformity, affix CE marking where required and register the system in the EU database.

A practical conformity workflow has eight gates. First, freeze the intended purpose and role analysis. Second, identify applicable essential requirements and harmonised standards or common specifications. Third, build the technical file, including architecture, model version, data lineage, metrics, limitations and foreseeable misuse. Fourth, run risk, bias, robustness, security and human-factors testing. Fifth, verify that logging supports traceability at the decision level. Sixth, test human oversight in realistic operating conditions. Seventh, complete conformity and registration activity. Eighth, activate post-market monitoring, serious-incident escalation and controlled change management.

In our hands-on review of the Commission’s AI Act Explorer and Compliance Checker, both were useful for legal navigation and initial triage. Neither replaces a system-specific technical file, and the Commission itself presents explanatory summaries as non-binding. Teams should save the questions, assumptions and answers used in the checker so the result remains reproducible when a purpose, model or integration changes.

The most overlooked bottleneck is operational data. A provider may have excellent laboratory metrics but no evidence that the live input population matches the validation population. Another is human oversight theatre, where a reviewer is nominally assigned but lacks time, information, authority or a realistic mechanism to override the output. The control should specify who reviews, what they see, when they intervene, how disagreements are recorded and what happens when the queue becomes too large.

For an example of compliance processes moving into enterprise workflow, the compliance automation partnership illustrates why legal evidence increasingly needs to be generated inside the system of work rather than assembled after the event.

1. Freeze intended purpose, scope, role and version.

2. Map legal requirements to technical and organisational controls.

3. Assemble data, architecture, testing and limitation evidence.

4. Validate accuracy, fairness, robustness, security and foreseeable misuse.

5. Prove logging, traceability and effective human oversight.

6. Complete conformity assessment, declaration, marking and registration.

7. Release through a controlled approval gate.

8. Monitor performance, incidents, drift and material changes after launch.

6. General-Purpose AI and the Systemic-Risk Threshold

General-purpose AI models are regulated at the model layer because they can support many downstream systems. The provider must maintain technical documentation, give downstream providers enough information to understand capabilities and limitations, implement a policy to comply with EU copyright law, publish a sufficiently detailed summary of training content, and appoint an authorised representative when established outside the EU unless an exception applies.

The Commission’s 2026 guidelines emphasise substance over labels. A model can qualify as general-purpose when it displays significant generality and can competently perform a wide range of distinct tasks. Minor modifications do not automatically make every downstream company a GPAI provider, but significant modification can. The guidance uses training compute as an important indicator and retains the Act’s presumption of systemic risk at 10^25 floating-point operations, while capability, reach and impact can also support designation.

Models with systemic risk carry additional obligations: model evaluations using standardised protocols, adversarial testing where appropriate, assessment and mitigation of systemic risks, serious-incident tracking and reporting, and an adequate level of cybersecurity protection for the model and physical infrastructure. Providers can use the voluntary GPAI Code of Practice as a route to demonstrating compliance, but signing a code does not eliminate statutory responsibility.

The business distinction is between model and system duties. A company integrating a commercial foundation model into a recruitment product may be a downstream provider of a high-risk system even if it is not the GPAI provider. It still needs the upstream documentation required to design, test and explain its own system. A contractual right to documentation must therefore be specific about model cards, evaluation results, version notices, safety limitations, training-content summaries, copyright policy information and incident communication.

Ursula von der Leyen described the goal at the G7 on 17 June 2026 as ensuring that citizens and companies can “safely use the best AI models”. That safety objective becomes a procurement requirement when a supplier controls the model but the customer carries deployment consequences.

7. Transparency Duties Must Be Designed Into the Interface

Article 50 moves transparency from policy wording into product design. People interacting directly with an AI system generally need to be informed that they are dealing with AI unless this is obvious to a reasonably well-informed, observant and circumspect person. Providers of systems that generate synthetic audio, image, video or text must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated, subject to technical feasibility and specified exceptions.

Deployers of deepfake systems generally need to disclose that content has been artificially generated or manipulated. Where AI generates or manipulates text published to inform the public on matters of public interest, disclosure may also be required unless human review or editorial control applies and a person holds editorial responsibility. The practical design problem is to make the disclosure timely, accessible and resistant to being stripped during export or reposting.

A transparency control should therefore have four layers. The user-interface notice tells the person they are interacting with AI. The output-level label travels with the content. The machine-readable signal supports technical detection. The audit record stores the model, prompt context, timestamp, policy version and any human editorial review. Treat accessibility as part of compliance: a notice hidden in terms and conditions will not perform the same function as an in-context message.

The August 2026 start date makes this a release-management issue now. Product teams should test notices across web, mobile, voice and API channels. They should also identify exceptions carefully rather than using one broad “human reviewed” label. Human review needs a defined standard. A reviewer who sees only a sample after publication may not amount to editorial control for every item.

Generative content controls also overlap with fraud, brand safety and cybersecurity. The European cybersecurity warning is a reminder that provenance and disclosure do not solve model misuse by themselves. Thomas Regnier, a European Commission spokesperson, said in June 2026 that highly capable models “raise serious cybersecurity concerns that need to be addressed.”

8. Liability Lives in the Contract, but Not Only in the Contract

The AI Act allocates obligations across operators, so a buyer does not become safe merely because a supplier promises compliance. A deployer remains responsible for its own use, input data, monitoring, human oversight and incident response. A provider that makes a substantial modification or changes intended purpose can assume provider obligations. Other regimes can create parallel exposure, including GDPR, equality law, employment law, consumer protection, product liability, contract and negligence.

Supply-chain contracts should translate legal dependencies into deliverables. The supplier should warrant its role and compliance status, but the agreement also needs an evidence schedule. That schedule should identify technical documentation, model and data information, evaluation results, security testing, logging capabilities, instructions for use, known limitations, incident history, conformity artefacts and registration details where relevant. Evidence should be updated, not delivered once at signature.

Version control is essential. Require advance notice of material model, dataset, safety-policy, hosting or subprocessor changes. Define what counts as a material change and what testing the customer may rerun. Include an emergency notice route for security or safety changes that cannot wait. Contracts should provide audit and regulator-cooperation rights, incident notification timeframes, record-retention duties, allocation of remediation costs, data return or deletion, and a right to suspend or switch models when evidence is missing.

Cross-border businesses should also consider regulatory fragmentation. The US state AI legislation shows why one global warranty may not cover all jurisdiction-specific duties. Build a common control baseline, then attach jurisdictional schedules for notices, impact assessments, worker rules, consumer rights and reporting.

The strongest clause is operational, not rhetorical. “Supplier will comply with all AI laws” is difficult to test. “Supplier will notify the customer within 24 hours of a serious model incident, provide the model version and affected services, preserve relevant logs, and support the customer’s regulatory report” can be tested. Liability allocation matters, but the ability to detect and contain a problem matters sooner.

9. Build a Governance Model That Can Make Decisions

An AI ethics committee can help, but committees often fail when they only discuss principles. The operating model needs decision rights. A central AI governance function should define policy, classification methodology, minimum controls, exceptions, evidence standards and reporting. Business units should own use-case outcomes. Technology and security functions should operate technical controls. Legal and compliance should interpret obligations and challenge decisions. Internal audit should independently test design and operation.

The six practical steps are: assess risk, raise awareness, design beyond the minimum, assign responsibility, monitor guidance and establish formal governance. Each step needs an output. Risk assessment produces a signed classification. Awareness produces role-based learning records. Ethical design produces measurable requirements for fairness, accessibility, privacy, safety and contestability. Responsibility produces named owners and deputies. Regulatory monitoring produces a change log. Formal governance produces approval gates, exceptions, metrics and evidence retention.

AI literacy is not generic cyber training. Executives need to understand risk appetite and accountability. Procurement teams need to identify AI in products and request evidence. Engineers need secure development, testing and logging practices. HR and operations staff need to understand automation bias, escalation and affected-person rights. Customer service staff need to know when a chatbot must disclose itself and when a case must move to a person.

Governance also needs consequences. The governance failure case demonstrates the reputational damage that follows when rules exist but incentives, supervision and verification fail. For AI, the equivalent failure is approving a system on a slide deck while evidence, access controls and operational review remain absent.

Track a small set of board metrics: percentage of AI systems inventoried, percentage classified, prohibited-use findings, high-risk systems with complete files, suppliers with evidence gaps, overdue model-change reviews, serious incidents, override rates, material drift and staff training coverage. Avoid a single “compliance score” that hides severe exceptions behind averages.

10. Governance Tools, Features, Pricing and Limits

Software can reduce manual work, especially where hundreds of models, agents and vendors must be inventoried and monitored. It cannot determine legal purpose without business input, guarantee conformity or replace accountable decisions. During our 2026 evaluation of public product documentation, the most important buying distinction was between a system of record, a testing platform and runtime enforcement. Some products combine them, but integration depth and pricing transparency vary.

The Commission’s Compliance Checker and AI Act Explorer are public tools with no published fee or usage cap. They are useful for orientation, article navigation and structured questions. OneTrust describes AI Governance capabilities including a central inventory for models, agents, datasets and vendors; risk tiering against EU AI Act, NIST and ISO 42001; approval gates; documentation; continuous monitoring; sensitive-data detection; runtime controls; and agent permissions across Model Context Protocol environments. Its official pricing page says pricing is based on admin users and AI inventory, but publishes no numerical tiers or caps.

Tool	Publicly documented scope	Pricing and caps	Public integrations or technical notes
EU Compliance Checker and Explorer	Legal navigation, structured applicability questions, article and recital exploration	Free public access; no usage caps published	Web tools; not a conformity assessment or technical evidence repository
OneTrust AI Governance	Inventory, tiering, approvals, evidence, reporting, monitoring, sensitive-data and runtime controls	Custom quote; based on admin users and AI inventory; numerical caps not public	Agent permissions and tool access across MCP environments; integration catalogue available separately
Credo AI	Registry, risk intelligence, red teaming, drift, policy engine, evidence, GAIA multi-layer governance	Custom enterprise sale; numerical plans, rate limits and retention caps not public	Snowflake, Databricks, AWS, Azure, ServiceNow, Jira, Confluence, Slack, GitHub, MLflow
Holistic AI	Discovery, 40+ tests, monitoring, risk mapping, gates, kill switches, audit evidence, Guardian Agents	Demo or custom sale; numerical plans and caps not public	AWS, Azure, GitHub, Databricks and 20+ integrations; read-only-by-default foundation

Credo AI publicly lists an AI Registry, shadow-AI detection, risk classification, stakeholder mapping, auto-discovery, continuous monitoring, automated red teaming, alerts, drift detection, policy packs, custom guardrails, compliance mapping, evidence generation and multi-layer GAIA governance for models, agents, applications and networks. Named integrations include Snowflake, Databricks, AWS, Azure, ServiceNow, Jira, Confluence, Slack, GitHub and MLflow. Public numerical pricing and plan limits were not available on the pages reviewed.

Holistic AI publicly lists automated discovery of models, agents, APIs, pipelines and workflows across AWS, Azure, GitHub, Databricks and more than 20 integrations; over 40 tests for bias, fairness, toxicity, hallucination, prompt injection, adversarial attacks, performance, robustness, explainability and safety; risk mapping; approval gates; kill switches; continuous evidence; and Guardian Agents for monitoring and intervention. It offers demos but did not publish numerical pricing or plan caps on the page reviewed.

The commercial limitation is material: without public prices, asset caps, API rate limits, retention limits, support terms and connector entitlements, a complete cost comparison is impossible. Buyers should demand a five-year total-cost model based on admin users, inventory size, test volume, runtime events, data retention, sandboxes, integrations and professional services.

11. Technical Implementation: From Inventory to Runtime Evidence

The technical programme should start with discovery but end with continuously updated evidence. Step one is to ingest procurement records, cloud resources, source repositories, API gateways, data platforms, browser extensions and expense data to find known and shadow AI. Step two is to create a canonical identifier for each use case and link it to models, versions, datasets, owners, suppliers, environments and legal entities. Step three is to classify purpose and role. Step four maps requirements to controls and tests. Step five integrates release gates into development and procurement. Step six collects runtime metrics, incidents and changes.

The core data model should separate the business use case from the technical component. One model may support many uses with different risk. One use may call several models and tools. Store intended purpose, prohibited-purpose exclusions, affected population, decision consequence, model endpoint, version, prompt or policy template, retrieval sources, tool permissions, data categories, location, owner, risk tier, approvals, evidence links and monitoring thresholds.

Known bottlenecks include incomplete discovery, vendor black boxes, rapidly changing hosted models, weak lineage for fine-tuning data, insufficient decision-level logs, testing that does not match live populations, and monitoring without response thresholds. Agentic systems add non-determinism and tool risk. The agentic AI market developments make it increasingly important to log not only model outputs but also tool calls, permissions, intermediate plans and actions.

A useful evidence architecture is an evidence graph. Each legal duty points to a control. Each control points to an owner, system configuration, test, result, exception and remediation ticket. Each artefact carries version, date and approval. This avoids the common audit failure where policies, screenshots and test reports exist but cannot be tied to the exact deployed model and purpose.

Performance testing should include accuracy and calibration by relevant subgroup, false-positive and false-negative costs, robustness to realistic perturbations, drift sensitivity, prompt-injection resistance, data leakage, jailbreak attempts, harmful-output testing and human-oversight effectiveness. Record the test environment, sample source, version and acceptance threshold. A passing result is only meaningful when the methodology is reproducible.

12. SMEs, Sandboxes, R&D Exceptions and Proportionality

The Act includes support measures for smaller organisations, including regulatory sandboxes, guidance, standardised templates and attention to SME economic viability when penalties are set. Under Article 99, SMEs and start-ups face the lower of the stated fixed maximum or turnover percentage, while other undertakings face the higher. That is important, but it does not make the core prohibitions or operator duties optional.

The research and development exception is narrower than many founders assume. The Act does not generally apply to AI systems or models specifically developed and put into service for the sole purpose of scientific research and development. It also excludes research, testing and development activity before a system is placed on the market or put into service, provided the activity respects applicable EU law. Real-world testing is not simply outside the Act, and a product labelled “beta” does not gain a blanket exemption when it is already used operationally.

A start-up should use proportional documentation, not absent documentation. Maintain one inventory, one risk method and one approval path. Reuse evidence across the AI Act, GDPR, information security and customer assurance. Use the Commission’s free tools for triage. Engage a regulatory sandbox when the use is novel or high-impact. Negotiate evidence rights early with upstream model providers, because a small company has less leverage after launch.

Talent remains a constraint. The European AI jobs evidence points to the wider need for technical and governance skills across Europe. A practical SME model assigns an executive accountable owner, a product or engineering control owner, a privacy or legal adviser, and an independent reviewer for higher-risk decisions. External support can fill gaps, but accountability should remain named internally.

Friedrich Merz, Germany’s Chancellor, argued in April 2026 that industrial AI can deliver “greater efficiency and productivity” and lower costs. Proportional compliance should preserve those gains. The best way to do that is to make governance part of product architecture and release management, rather than a manual legal review added at the end.

13. Twelve Board-Level Moves Before the High-Risk Deadlines

Boards do not need to classify every model, but they do need confidence that the organisation can find its AI, stop prohibited uses, evidence high-impact decisions and control suppliers. The following sequence creates that confidence without turning governance into a parallel bureaucracy.

First, approve a scope that covers purchased, embedded, employee-created and customer-facing AI. Second, require a canonical inventory and prohibit production use without registration. Third, assign legal roles and accountable owners by use case. Fourth, complete an Article 5 sweep and remediation. Fifth, implement role-based AI literacy. Sixth, prioritise Article 50 notices and provenance before August 2026. Seventh, identify GPAI-provider exposure, including significant model modifications. Eighth, establish high-risk evidence files and conformity workplans. Ninth, amend supplier contracts. Tenth, integrate approval gates and monitoring into engineering. Eleventh, define incident and regulator-response procedures. Twelfth, commission independent testing of the highest-impact systems.

Three less obvious insights should shape the programme. One, risk is attached to purpose and workflow, not the model alone. A low-risk assistant can become high-risk when repurposed to rank applicants. Two, a model-version change should trigger a compliance event, not wait for an annual review. Three, evidence architecture is a strategic asset. An evidence graph that ties duties to controls, versions and tests lowers the cost of customer assurance, audits and expansion into other jurisdictions.

The board should also challenge concentration risk. On 14 June 2026, the Commission said it was assessing the consequences of a US directive affecting access to Anthropic models. Sudden supplier restrictions, export controls, pricing changes or model retirement can break both operations and compliance assumptions. Require fallback models, portability of prompts and evaluation sets, preserved logs, and a tested suspension process.

A mature programme should be able to answer four questions quickly: What AI do we operate? Which uses could materially affect people or safety? What evidence proves the controls work for the deployed version? What happens when the supplier, model, purpose or law changes? The organisation that can answer those questions is better prepared for enforcement and for responsible scaling.

1. Approve enterprise-wide AI scope and risk appetite.

2. Register every production use in a canonical inventory.

3. Map operator roles and accountable owners.

4. Remove prohibited practices and document the sweep.

5. Deliver role-based AI literacy.

6. Implement Article 50 notices and provenance controls.

7. Identify GPAI provider or significant-modifier duties.

8. Build high-risk evidence files and conformity plans.

9. Re-paper supplier contracts with evidence and change rights.

10. Embed approval gates, tests and runtime monitoring.

11. Exercise incident, suspension and regulator-response procedures.

12. Independently assure the most consequential systems.

Takeaways

• Inventory AI by business use, model version, supplier, legal entity and affected population.
• Stop possible prohibited practices immediately and preserve the classification evidence.
• Treat 2 August 2026 transparency and GPAI enforcement as live delivery deadlines.
• Use 2 December 2027 and 2 August 2028 as high-risk endpoints, not project start dates.
• Contract for model evidence, version notices, incident support, audit rights and a workable exit.
• Tie every legal duty to an owner, control, test, artefact and remediation record.
• Trigger reassessment when purpose, model, data, tool permissions or deployment geography changes.
• Measure governance through severe exceptions and evidence gaps, not a reassuring average score.

Conclusion

The EU AI Act is becoming an operating discipline rather than a future legal concept. Its most important business effect is not the maximum fine, although the penalties are material. Article 99 permits up to €35 million or 7 per cent of worldwide annual turnover for prohibited practices, up to €15 million or 3 per cent for specified operator and transparency breaches, and up to €7.5 million or 1 per cent for incorrect, incomplete or misleading information. For SMEs, the lower maximum applies.

The more immediate risk is deploying consequential AI without a reproducible account of purpose, role, version, controls and supplier evidence. The revised high-risk dates provide more implementation time, but the transparency, literacy and GPAI work is already current. Organisations should use the interval to build evidence into procurement, engineering and operations, rather than expanding a spreadsheet-based approval process.

Open questions remain. Harmonised standards and sector practice will continue to develop. The final legal mechanics of the 2026 simplification agreement must be tracked. Technical methods for watermarking, agent oversight and systemic-risk evaluation will mature. Businesses should therefore design governance for change: a stable inventory and control framework, combined with version-aware evidence, contractual access and clear accountability. That architecture can support compliance without freezing innovation, which is the balance European policymakers now say they are seeking.

FAQs

Does the EU AI Act apply to businesses outside Europe?

Yes. It can apply to non-EU providers that place AI systems or GPAI models on the EU market, and to non-EU providers or deployers when system output is used in the EU. The exact result depends on the operator role, offering, intended purpose and where the output has effect.

What counts as a high-risk AI system for a business?

High-risk systems include certain safety components of regulated products and specified Annex III uses, such as employment, education, essential services, creditworthiness, some insurance assessments, critical infrastructure and certain biometric uses. Classification depends on intended purpose and workflow, not the product label alone.

When do high-risk EU AI Act rules apply?

Following the political agreement reached on 7 May 2026, Annex III high-risk rules are scheduled for 2 December 2027. High-risk systems embedded in regulated products are scheduled for 2 August 2028. Businesses should monitor formal adoption and implementing guidance while continuing preparation.

What is systemic risk for a general-purpose AI model?

The Act presumes systemic risk when cumulative training compute exceeds 10^25 floating-point operations, while the Commission can also designate a model based on capabilities and impact. Such providers face added evaluation, risk mitigation, incident reporting and cybersecurity duties.

Does using a compliant AI vendor make the customer compliant?

No. A deployer retains obligations for authorised use, relevant input data, human oversight, monitoring, logs and incident action. A customer may also become a provider after rebranding, changing intended purpose or making a substantial modification.

What should an AI supplier contract contain?

Include role and compliance warranties, a detailed evidence schedule, model and dataset change notices, security and incident duties, audit and regulator-cooperation rights, retention requirements, remediation allocation, suspension rights, exit support and fallback arrangements.

Are research and development activities exempt?

Some pre-market research, testing and development are outside the Act, and systems or models solely developed and used for scientific research can be excluded. The exception does not automatically cover real-world testing or an operational product merely described as a pilot or beta.

Is there a free EU AI Act compliance tool?

Yes. The European Commission provides a public Compliance Checker and AI Act Explorer through its Service Desk. They support triage and legal navigation, but they do not replace legal advice, system testing, conformity assessment or an auditable technical file.

References

European Commission. (2026, May 8). EU agrees to simplify AI rules to boost innovation and ban ‘nudification’ apps to protect citizens. https://digital-strategy.ec.europa.eu/en/news/eu-agrees-simplify-ai-rules-boost-innovation-and-ban-nudification-apps-protect-citizens

European Commission. (2026, April 28). Guidelines for providers of general-purpose AI models. https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers

European Commission. (2026, May 19). Guidelines for providers and deployers of AI high-risk systems. https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems

European Commission. (2025, October 8). Commission launches AI Act Service Desk and Single Information Platform to support AI Act implementation. https://digital-strategy.ec.europa.eu/en/news/commission-launches-ai-act-service-desk-and-single-information-platform-support-ai-act

European Parliament & Council of the European Union. (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence. Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng

National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1

Reuters. (2026, May 5). Top European tech CEOs call for easier AI rules. https://www.reuters.com/legal/litigation/top-european-tech-ceos-call-easier-ai-rules-2026-05-05/

Reuters. (2026, June 17). In US, EU mutual interest for Europe to use best AI models, von der Leyen says. https://www.reuters.com/world/us-eu-mutual-interest-europe-use-best-ai-models-von-der-leyen-says-2026-06-17/

OneTrust. (2026). Pricing and packaging: AI Governance. https://www.onetrust.com/pricing/