Building an AI tool without considering the EU AI Act exposes your organisation to significant legal, financial, and operational risks. If your tool falls into a high-risk category and you have not implemented the required governance controls, you face potential fines, market exclusion, and mandatory product withdrawal. These risks apply to any organisation developing or deploying AI systems that interact with EU users or markets. The sections below unpack the most pressing questions developers and product teams are asking in 2026. If you want to talk through your specific situation, feel free to get in touch with us and we will help you find the right direction.

What happens if your AI tool is classified as high-risk?

If your AI tool is classified as high-risk under the EU AI Act, you are legally required to meet a demanding set of obligations before placing it on the market or putting it into service. These include mandatory conformity assessments, comprehensive technical documentation, human oversight mechanisms, data governance protocols, and registration in the EU database for high-risk AI systems. Operating without meeting these requirements is not a grey area — it is a regulatory violation.

The EU AI Act defines high-risk AI systems through two primary routes. The first covers AI systems that are safety components of products already regulated under existing EU product safety legislation, such as medical devices or machinery. The second covers AI systems listed in Annex III of the Act, which includes tools used in employment decisions, credit scoring, education and vocational training, law enforcement, and the administration of justice, among others.

What makes the high-risk classification particularly significant for product teams is that it is determined by the intended purpose and context of deployment, not just the technical architecture. A recruitment screening tool and a content recommendation engine might share similar underlying models, but only one triggers high-risk obligations. This means classification analysis needs to happen before development reaches an advanced stage, not after launch.

Beyond compliance obligations, a high-risk classification also affects your commercial relationships. Enterprise buyers, regulated industries, and public sector clients increasingly require evidence of AI Act conformity as a procurement condition. Failing to address classification early can block market access entirely.

What are the fines and penalties for non-compliance with the AI Act?

Non-compliance with the EU AI Act can result in fines of up to 35 million euros or 7% of global annual turnover, whichever is higher, for the most serious violations. Lower tiers apply to other breaches, with fines reaching 15 million euros or 3% of turnover for failures to meet obligations for high-risk systems, and 7.5 million euros or 1.5% of turnover for supplying incorrect information to authorities.

The penalty structure mirrors the approach taken by GDPR, where fines are tiered based on the severity and nature of the infringement. The highest tier applies to prohibited AI practices — such as deploying social scoring systems or certain real-time biometric surveillance tools. The mid-tier applies to high-risk system providers who fail to meet their conformity, documentation, or oversight obligations. Even smaller infractions, such as inadequate transparency disclosures, carry meaningful financial exposure.

For scale-ups and mid-market companies, the percentage-of-turnover calculation is often the more painful measure. A company with 20 million euros in global revenue facing a 7% fine is looking at a 1.4 million euro penalty — significant enough to affect investment rounds, operational continuity, and stakeholder confidence. Private equity portfolio companies should treat AI Act compliance as a material risk factor during due diligence and portfolio management.

It is also worth noting that national market surveillance authorities across EU member states are responsible for enforcement, and their capacity and appetite for action will vary. However, the direction of travel is clear: regulators are building enforcement capability, and the window for informal tolerance is narrowing through 2026 and beyond.

Which AI Act requirements apply during the development phase?

Several AI Act obligations attach to the development phase itself, not only to the point of deployment. For high-risk AI systems, providers must establish quality management systems, maintain technical documentation throughout development, apply data governance practices to training datasets, and design systems with transparency and human oversight as structural features rather than afterthoughts.

Data governance requirements

Training data used in high-risk AI systems must meet specific standards under the AI Act. Providers are required to implement practices that ensure training, validation, and testing datasets are relevant, sufficiently representative, and free from errors that could produce discriminatory or unsafe outputs. This is not simply a documentation exercise — it requires active governance of data pipelines during development, including bias assessments and dataset provenance tracking.

Technical documentation obligations

Providers of high-risk AI systems must maintain technical documentation that is detailed enough to allow authorities to assess compliance. This documentation must be prepared before the system is placed on the market and kept up to date throughout the system’s lifecycle. In practice, this means development teams need structured documentation processes running in parallel with engineering work, not assembled retrospectively before a launch deadline.

For general-purpose AI models with systemic risk — a category introduced under the Act for the most capable foundation models — additional obligations apply, including adversarial testing and incident reporting. If your AI tool is built on or constitutes such a model, these requirements add another layer of governance that must be addressed during development.

How does the AI Act interact with GDPR and other EU regulations?

The EU AI Act and GDPR operate in parallel and are explicitly designed to be complementary, not contradictory. Where an AI system processes personal data, both frameworks apply simultaneously. GDPR governs the lawfulness, fairness, and transparency of personal data processing, while the AI Act governs the safety, transparency, and accountability of the AI system itself. Compliance with one does not substitute for compliance with the other.

In practical terms, this means a high-risk AI system that processes personal data must satisfy obligations under both regimes. A recruitment AI, for example, must have a lawful basis for processing candidate data under GDPR, conduct a Data Protection Impact Assessment where required, and simultaneously meet the AI Act’s requirements for human oversight, transparency, and conformity assessment. These are additive obligations, and organisations that treat them as separate workstreams often discover gaps at the intersection.

Beyond GDPR, the AI Act also intersects with sector-specific regulation. Organisations subject to NIS2 — which governs cybersecurity for essential and important entities — need to consider how AI systems interact with their security obligations. Firms under DORA, the Digital Operational Resilience Act for financial services, face additional requirements around ICT risk management that extend to AI tools used in financial operations. Organisations developing AI systems in healthcare, aviation, or other safety-regulated sectors must navigate product safety legislation alongside the AI Act’s own requirements.

The practical implication is that continuous governance across all applicable frameworks is not optional for regulated organisations. Treating each regulation as a standalone compliance project creates blind spots at the intersections where the most significant risks tend to live.

When should AI governance be built into product development?

AI governance should be integrated from the earliest stages of product development, ideally from the initial scoping and design phase. Retrofitting governance controls onto a system that has already been architected, trained, and tested is significantly more costly, disruptive, and often technically inferior to embedding governance by design. The AI Act’s own structure reinforces this — many of its requirements are only practically achievable if governance is built in from the start.

The concept of governance by design mirrors the data protection by design principle established under GDPR. It means that decisions about system architecture, data sourcing, model selection, and deployment context are made with regulatory and ethical considerations as active inputs, not constraints applied after the fact. For development teams, this requires governance expertise to be present in product conversations, not siloed in a compliance function that reviews finished work.

From a business perspective, early integration of AI governance also reduces commercial risk. Investors, enterprise clients, and regulators are increasingly scrutinising how organisations have approached AI development, not just what they have built. A product with documented governance processes, clear risk classification analysis, and traceable compliance decisions is a more defensible and commercially attractive asset than one where governance was treated as an afterthought.

This is precisely where continuous governance as an operating model becomes valuable. Rather than treating AI Act compliance as a project with a start and end date, organisations that embed ongoing governance into their development and operational cycles are better positioned to adapt as regulations evolve, as their AI systems change, and as new use cases emerge. Our governance services are built around exactly this model — keeping governance active and aligned with your organisation’s development pace, not just activated at audit time.

The cost of building governance in early is a fraction of the cost of remediation, regulatory enforcement, or market withdrawal later. In 2026, with AI Act obligations progressively coming into force, the question is no longer whether to build governance into AI development — it is how quickly you can make it a structural capability rather than a periodic exercise. If you are ready to take that step, contact us to plan a conversation about what continuous AI governance looks like for your organisation.

Frequently Asked Questions

How do I determine whether my AI tool falls into the high-risk category under the EU AI Act?

Start by mapping your tool's intended purpose and deployment context against the two classification routes in the Act: safety components of regulated products, and the use cases listed in Annex III. The key question is not what your system does technically, but where and how it is used — a model used for content recommendations is treated very differently from the same model used to screen job applicants. If there is any ambiguity, a formal risk classification analysis conducted before development progresses too far is the most cost-effective way to get clarity.

What should we do first if we have already built an AI tool without considering the EU AI Act?

The immediate priority is a risk classification assessment to determine whether your system falls into a prohibited, high-risk, or lower-risk category — because your obligations and urgency differ significantly depending on the answer. If high-risk classification applies, you will need to conduct a gap analysis against the Act's requirements, including technical documentation, data governance, and conformity assessment readiness. Acting now rather than waiting for an enforcement trigger gives you the most options and the most time to remediate without operational disruption.

Does the EU AI Act apply to our company if we are based outside the EU?

Yes — the EU AI Act has extraterritorial reach similar to GDPR. If your AI system is placed on the EU market, used by EU-based users, or produces outputs that affect people in the EU, the Act applies to you regardless of where your organisation is incorporated or headquartered. Non-EU providers placing high-risk AI systems on the EU market are required to appoint an authorised representative established in the EU. Ignoring the Act on the basis of being outside the EU is not a defensible compliance position.

How does the EU AI Act define 'human oversight,' and what does it actually require in practice?

Human oversight under the AI Act means that high-risk AI systems must be designed and developed in a way that allows natural persons to effectively monitor, understand, and where necessary override or halt the system's outputs. In practice, this means building interfaces and workflows that give human operators genuine visibility into how the system is functioning — not just a nominal review step that rubber-stamps automated decisions. It also means ensuring that the people responsible for oversight have the competence and authority to act on what they observe, which has implications for training, role design, and organisational process.

What is the difference between a provider and a deployer under the EU AI Act, and why does it matter?

A provider is the entity that develops an AI system and places it on the market or puts it into service — they carry the heaviest obligations under the Act, including conformity assessments and technical documentation. A deployer is an organisation that uses a high-risk AI system in a professional context, and while their obligations are lighter, they are still significant: deployers must implement human oversight, monitor system performance, and ensure the system is used only for its intended purpose. If you are building on top of a third-party model or platform and customising it for a specific use case, you may be acting as a provider even if you did not train the underlying model — a distinction that catches many development teams off guard.

How often does AI Act compliance need to be reviewed or updated once it is in place?

AI Act compliance is not a one-time certification — it is an ongoing obligation that must be maintained throughout the lifecycle of the system. Significant changes to a high-risk AI system, including retraining on new data, changes to intended purpose, or deployment in new contexts, can trigger the need for updated technical documentation and potentially a new conformity assessment. Beyond system changes, the regulatory landscape itself is still evolving, with implementing acts, standards, and guidance being issued progressively through 2026 and beyond. This is precisely why continuous governance, rather than periodic compliance projects, is the more resilient and cost-effective operating model.

Can smaller startups or early-stage companies get a reduced compliance burden under the EU AI Act?

The Act does include provisions acknowledging the position of SMEs and startups, such as priority access to regulatory sandboxes — controlled environments where AI systems can be developed and tested under regulatory supervision with lighter-touch oversight. However, these provisions reduce friction around testing and market entry; they do not exempt smaller companies from substantive obligations if their system is classified as high-risk. A startup deploying a high-risk AI system must meet the same core requirements as a large enterprise, which makes early-stage governance investment even more strategically important — building compliance capability from the ground up is far cheaper than retrofitting it under time pressure before a funding round or enterprise sales process.

Related Articles

Share

  • August 5, 2026