EU AI Act for startups: what founders actually need to know

The EU AI Act is the world's first comprehensive legal framework for artificial intelligence. It creates obligations based on the risk level of an AI system, not on the size of the company building it. A five-person startup deploying an AI hiring tool has the same classification as a large enterprise deploying the same kind of system. The scale of the compliance burden differs, but the substantive requirements do not.

This is worth stating clearly because a common misconception among early-stage founders is that regulation is a large-company problem. It is not. What is true is that the Act includes specific provisions to reduce administrative burden for SMEs, including access to regulatory sandboxes and reduced fees. But those provisions exist within the same framework that applies to everyone.

The good news is that the framework is risk-based and proportionate. Most AI products built by startups today do not fall into the categories that trigger the heaviest obligations. Understanding the structure is most of the work.

The four risk tiers

The Act organises AI systems into four categories. Where your product lands determines everything that follows.

The question that determines your obligations: provider or deployer?

Before classification, there is a prior question. Are you a provider or a deployer?

A provider is an organisation that develops an AI system and places it on the market or puts it into service, whether for sale or free of charge. You are a provider if you are building and distributing an AI system that other businesses or consumers use directly.

A deployer is an organisation that uses an AI system developed by a third party within its own products or operations. If you are building a product on top of the OpenAI API, Anthropic's Claude, Google's Gemini, or any other foundation model without substantially modifying the underlying model, you are a deployer for that model and a provider for your own application layer.

This distinction matters enormously. Providers carry the heaviest obligations for high-risk systems: conformity assessments before deployment, registration in the EU database of high-risk AI systems, technical documentation, incident reporting, and ongoing post-market monitoring. Deployers have a lighter set of obligations focused on appropriate use and ensuring human oversight.

High-risk in practice: the list founders need to check

Annex III of the Act lists the high-risk use cases. Reading the full legal text is necessary for compliance purposes, but the practical pattern recognition for founders is this: if your AI product makes decisions or meaningfully influences decisions about individual people in any of the following areas, assume high-risk until you have a specific legal rationale for otherwise.

• Hiring and employment: CV screening, candidate ranking, interview analysis, performance evaluation, promotion decisions, task allocation, monitoring of workers. This is the area where most HR-tech AI startups need careful analysis.
• Education: automated assessment of students, scoring of exams, proctoring systems that make or influence admission decisions.
• Credit and financial services: creditworthiness assessment, credit scoring, insurance risk classification.
• Access to essential services: AI used by public authorities or private entities providing essential services to determine eligibility or priority.
• Healthcare: AI used as a medical device or in clinical decision support that influences diagnosis or treatment choices.
• Biometric identification: systems that categorise people based on biometric data, remote biometric identification systems.

Notice that this list is defined by use case, not by technology. An LLM used to summarise internal documents is not high-risk. The same LLM deployed as a hiring screen that ranks candidates and feeds into employment decisions is high-risk. The technology is identical. The application context is what matters.

What "high-risk" compliance actually involves

If your product is high-risk, the obligations are substantial but structured. The main requirements are: a risk management system documented and maintained throughout the product lifecycle, appropriate training data governance with documented bias testing, technical documentation covering the system's purpose, design decisions, and performance characteristics, automatic logging of the system's operation, transparency information made available to deployers and users, human oversight mechanisms that allow intervention or shutdown, and accuracy and robustness standards appropriate to the use case.

For high-risk systems, you also need to register the system in the EU AI Act database before placing it on the market, and you need a conformity assessment. For most high-risk systems, self-assessment is permitted. For certain biometric and law enforcement systems, third-party assessment is required.

None of this is impossible for a startup. It is substantive work that requires dedicated time and likely some external expertise. The mistake is treating it as a late-stage concern. Founding teams building in high-risk categories who start this process at product launch rather than during development will find themselves redesigning features to accommodate requirements that were not considered during architecture decisions.

Transparency obligations: what almost everyone must do

Even if your system is not high-risk, transparency obligations apply whenever users interact directly with AI. The specific requirements are clear: users must be informed that they are interacting with an AI system unless this is obvious from context. If your product uses emotion recognition or biometric categorisation, users must be told. If you generate synthetic audio, video, images, or text that could be mistaken for real content, that content must be labelled as AI-generated.

This is not onerous. A visible disclosure in the interface ("This response was generated by an AI assistant"), appropriate labelling on synthetic content, and a clear policy statement in your terms of service cover the core obligation for most products in the limited-risk tier. The important thing is doing it deliberately and consistently, so there is a clear record of intent and implementation if a question ever arises.

GPAI models: what changes if you use or build one

The Act includes a specific chapter on General Purpose AI models, covering systems like GPT-4, Claude, Gemini, Llama, and similar foundation models trained on broad datasets to perform a wide range of tasks.

If you are a startup using a GPAI model via API to build your product, the model provider carries the primary GPAI obligations. Your obligations are as a deployer: use the model appropriately, maintain the transparency disclosures required for your application tier, and implement human oversight where relevant.

If you are fine-tuning a GPAI model and offering the fine-tuned version to third parties, the picture changes. You may take on GPAI provider obligations depending on the degree of modification and the downstream use cases. This requires specific analysis.

GPAI models with systemic risk, defined by the Act as models trained with more than ten to the twenty-fifth power floating point operations, face additional obligations including adversarial testing, incident reporting to the AI Office, and cybersecurity measures. This threshold currently captures only the largest frontier models and does not apply to the vast majority of startups.

The timeline: what applies now

The Act has a phased implementation schedule. Understanding what is already in force matters for both compliance and for how you present your product in investor conversations and EU funding applications.

The August 2027 deadline for Annex III systems is the most relevant one for most software startups. That does not mean waiting until 2027 to start. Products currently in development that will be in market by 2027 need to be designed for compliance from the architecture stage. Building in compliance requirements after the product is built is significantly more expensive than designing for them from the start.

What EU funding evaluators are already checking

This is the section that matters most if you are preparing an EIC Accelerator or Horizon Europe proposal involving AI.

Since 2025, evaluators for both programmes have been trained to assess AI-related proposals for evidence that the applicant understands the regulatory environment their product will operate in. A proposal that presents an AI hiring tool or an AI clinical decision support product without any reference to EU AI Act compliance is increasingly viewed as a signal of incomplete market readiness analysis, regardless of the technical quality of the underlying technology.

What evaluators want to see is not a legal compliance document. They want to see that the founding team has done the basic classification work, knows which tier their product sits in, understands what obligations apply at their target go-to-market date, and has a credible plan to address them. Two paragraphs that demonstrate this clearly are worth more than a lengthy appendix.

Conversely, a team that has proactively built transparency mechanisms, documented their risk classification rationale, and designed their data governance with Annex III in mind is presenting a product that is closer to market-ready than a technically equivalent product that has ignored this entirely. In a competitive evaluation, that distinction can matter.

What to do in the next 90 days

The practical starting point is a classification exercise, not a legal consultation. Before engaging external counsel, the founding team should be able to answer three questions clearly: which tier does our product sit in, are we a provider or a deployer for each component of our system, and what is the factual basis for our tier classification.

For most startups, that work takes one to two days and produces a one or two page document that becomes the foundation for everything else. If the classification is limited-risk or minimal-risk, the follow-on actions are straightforward: implement the transparency disclosures, document the classification rationale, and review the document annually as the product evolves.

If the classification is high-risk, the follow-on actions are more substantive but entirely manageable if started during development rather than after launch. The key architectural decisions to make early are: what does the logging system look like, where does human oversight sit in the product flow, what does the technical documentation cover, and how will you handle the conformity assessment. None of these require the product to be built before they are decided. They are design decisions that should happen alongside product decisions.

The regulatory sandbox programmes that the Act mandates member states to establish are also worth monitoring. Several EU countries are building structured environments where startups can develop and test AI products with regulatory guidance before full compliance requirements apply. These are genuinely useful for products in high-risk categories that are still in development.