EU AI Act: What Startup Founders Need to Know in 2026

The AI Act is no longer a "later" problem. For many startups, the transparency rules already apply. The first step is not hiring a legal team: it is finding out where AI is actually being used, which decisions it influences, and what evidence the company can produce.

Note: information verified up to 9 September 2026. This article is informational and does not replace legal advice.

There are two common mistakes when founders talk about the EU AI Act.

The first is thinking it only applies to companies that develop AI models.

The second is assuming every obligation was postponed.

Neither is correct.

The European AI Regulation, Regulation (EU) 2024/1689, entered into force in August 2024. Some provisions started applying in 2025. The transparency rules in Article 50, particularly relevant for chatbots and synthetic content, became applicable on 2 August 2026.

It is true that Regulation (EU) 2026/1744, known as the Digital Omnibus on AI, delayed important parts of the regime for high-risk systems. But it did not delay the whole AI Act.

For a startup, the right question is no longer:

"Are we an AI company?"

The right question is:

"Where do we use AI, what role do we play in each use, and what impact can that use have on customers, workers or other people?"

A startup that runs a chatbot, generates ad campaigns, screens candidates, personalises prices or builds a product on a third-party model may have different obligations in each of those activities.

The AI Act can apply even if the startup is not based in the EU

The territorial scope of the AI Act does not stop at the EU border.

Broadly, the regulation can cover:

providers placing AI systems or models on the European market;
companies using AI systems inside the Union;
providers or users established outside the Union when the system's output is used in the EU;
importers and distributors of AI systems.

That means a US, UK or African startup can fall within scope if it offers an AI product to European customers, or if the system's output is used in the Union.

Where the company is registered does not, by itself, settle the question.

Before assessing risk, identify your role

The AI Act allocates responsibilities according to the role you play in the value chain.

Provider

A company is generally a provider when it develops an AI system, or has one developed, and places it on the market or into service under its own name or brand.

A startup can also take on provider responsibilities when it:

puts its brand on a third-party system;
substantially modifies a system;
changes the system's intended purpose;
integrates a model into its own product and defines how that product works.

Using an external API does not automatically remove responsibility for the final product.

Deployer

A deployer is an organisation using an AI system under its own authority, outside a purely personal activity.

A startup can be a deployer when it uses AI to:

support customer service;
generate content;
screen candidates;
recommend products;
monitor fraud;
analyse behaviour;
support internal decisions.

Importer or distributor

A company can also act as an importer or distributor when it introduces or makes a third-party system available on the European market.

The important point is that a single startup can hold several roles at once.

It can be the deployer of a tool used internally and the provider of the AI product it sells to customers.

The AI Act does not treat all uses of AI the same way

The regulation takes a risk-based approach. In practice, a founder should sort AI uses into four groups.

1. Prohibited practices

Certain uses are considered incompatible with the rights and values protected by the Union.

Article 5 covers, among other cases and within the conditions defined in the regulation:

manipulative or deceptive techniques capable of materially distorting behaviour and causing significant harm;
exploitation of vulnerabilities linked to age, disability or social or economic situation;
certain forms of social scoring;
creating or expanding facial recognition databases through untargeted scraping of images;
some forms of biometric categorisation based on sensitive characteristics;
emotion recognition at work and in educational institutions, save for limited health or safety exceptions;
certain uses of real-time remote biometric identification.

The 2026 Digital Omnibus on AI also introduced new prohibitions related to non-consensual AI-generated intimate images and child sexual abuse material.

For a startup, these practices should not sit in a "future compliance" queue. They need immediate analysis.

2. High-risk systems

High-risk classification does not depend only on the technology. It depends mainly on the purpose and the context of use.

Among the examples most relevant to startups are systems used for:

recruitment, application screening and worker evaluation;
decisions on promotion, termination or task allocation;
assessing people's creditworthiness;
access to certain essential services;
education and admission;
biometrics;
law enforcement, migration or administration of justice.

A product description generator does not automatically become a high-risk system.

A tool that scores candidates and decides who moves forward in a hiring process may well fall into the high-risk regime.

The current timeline, after the 2026 amendments, is:

2 December 2027: the main obligations apply to standalone high-risk systems listed in Annex III;
2 August 2028: application to high-risk systems embedded in certain regulated products in Annex I.

The delay is not a reason to ignore these systems. Implementing risk management, documentation, human oversight, logging and post-market monitoring close to the deadline will cost more than designing them in from the start.

3. Systems subject to transparency

This is probably the category with immediate impact on the largest number of startups.

The Article 50 rules apply from 2 August 2026.

4. Limited-risk uses

Many everyday uses, such as productivity, internal search, drafts or low-impact recommendations, may be neither prohibited, nor high-risk, nor directly covered by the specific transparency obligations.

That does not mean there is no responsibility.

The following can still apply:

GDPR;
consumer protection rules;
copyright;
employment law;
rules on misleading advertising;
contracts with providers and customers;
security and confidentiality duties.

The AI Act does not replace those rules.

What the transparency rules mean in practice

There is a lot of oversimplified information about "labelling all AI-created content". The actual obligation is more specific.

Chatbots and other interactive systems

When a person interacts directly with an AI system, the provider must ensure they are informed they are interacting with AI, unless this is obvious to a reasonably well informed and observant person.

In practice, a support chatbot should not pretend to be a human employee.

A simple, visible indication can be enough:

"You are chatting with an AI assistant."

The information must appear at the latest during the first interaction or exposure. It should not be buried in a legal document nobody reads.

AI-generated content and machine-readable marking

Providers of systems that generate or manipulate text, audio, image or video must ensure the outputs are marked in a machine-readable format and detectable as artificially generated or manipulated, to the extent this is technically feasible.

For a startup using external tools, this raises an important question for the provider:

Does the tool apply a technical marking, and does our process preserve it when content is edited, exported or published?

Stripping metadata, provenance or other markings during the production flow can destroy a mechanism the provider built to comply with the law.

Deepfakes

Anyone publishing an artificially generated or manipulated image, audio recording or video resembling a real person, object, place or event, and appearing authentic, must disclose that the content was generated or manipulated.

Relevant examples:

a video where the founder appears to say words they never recorded;
a synthetic testimonial that seems to come from a real customer;
a fabricated demo presented as a real experience;
a product image altered in a way that could pass as a faithful photograph of the product sold.

For artistic, satirical or fictional work, disclosure can be made in a way appropriate to the context, without unduly hampering the presentation of the work.

Text on matters of public interest

There is also a rule for text generated or manipulated by AI and published for the purpose of informing the public on matters of public interest.

Such content must be disclosed as artificially generated or manipulated.

The rule includes an exception where:

there was human review or editorial control;
a person or organisation takes editorial responsibility for the publication.

This does not mean any superficial review removes the problem. There must be a real editorial process and an identifiable entity taking responsibility.

Not every product description needs a public label

Article 50 does not create a universal duty to stamp "made by AI" on all marketing copy.

A commercial product description, for instance, is not necessarily a publication on a matter of public interest.

Even so:

it cannot mislead the consumer;
images and demos must represent the product correctly;
testimonials cannot be invented;
deepfakes remain subject to disclosure;
the company must preserve the applicable technical markings.

The analysis depends on the content and how it is presented, not only on the tool used.

Common situations in a startup

Use	Main question
Support chatbot	Does the person know they are talking to AI?
Product descriptions	Is the content accurate and free of misleading claims?
Generated product images	Do they look like authentic photographs? Is there a risk of misleading representation or deepfake?
Synthetic founder video	Is it clearly identified as generated or manipulated?
Product recommendations	Is there profiling or personal data processing subject to GDPR?
Personalised pricing	Can the system discriminate, exploit vulnerabilities or breach consumer rules?
Candidate screening	It may be a high-risk system under Annex III.
Credit assessment	It may fall into high-risk categories tied to essential services.
Emotion analysis of workers	It may be a prohibited practice, save for very narrow exceptions.
Internal writing assistant	Which confidential data is being sent to the provider?
Product built on an AI API	Is the startup only a user, or has it become the provider of the final system?

What if the startup uses a general-purpose model?

General-purpose models, or GPAI, have their own regime.

If a startup only uses an external model's API, it does not normally become the provider of that general-purpose model. But it can still be:

the provider of the final system it built;
the deployer of AI in its operations;
responsible for the promises and decisions presented to customers.

If it develops and places its own general-purpose model on the market, obligations become broader, including technical documentation, information for downstream providers, copyright-related policies and a summary of the content used for training.

Models with systemic risk are subject to additional requirements.

For a founder integrating an API, the practical questions for the provider include:

What documentation do you provide?
What are the intended and prohibited uses?
How do you protect the data we submit?
Is our data used for training?
How do you mark synthetic content?
How do you communicate incidents and model changes?
What information do you provide to support the assessment of the final product?

AI literacy is not a generic certificate you buy

Article 4 requires providers and deployers to take measures supporting the AI literacy of the people operating or using those systems on their behalf.

After the 2026 amendments, the obligation does not require guaranteeing a standardised individual level. It still requires measures appropriate to the context.

A generic one-hour training does not cover every case.

A marketing team needs to understand:

disclosure and labelling;
misleading content;
intellectual property;
data protection;
editorial review.

An HR team needs to understand:

discrimination;
data quality;
human oversight;
the limits of automated recommendations;
how decisions can be challenged.

A technical team needs to understand:

model limitations;
logs;
security;
testing;
monitoring;
documentation and incident management.

Training should match the role and the real risk.

The value of documentation before there is a problem

For startups, compliance should not mean producing documents just to satisfy an audit.

Documentation exists to answer operational questions:

What is the purpose of the system?
What problem should it solve?
Who can be affected?
What data does it use?
Which decisions does it influence?
When is human intervention required?
What are the known limitations?
How do we measure errors?
Who can suspend the system?
How do we report an incident?
Which provider or model sits underneath the product?
What changed since the last version?

Without those answers, the startup will struggle to explain the product to customers, investors, partners or regulators.

Where Painstack fits in

The best way to reduce risk is not to start from a legal table. It is to start by validating whether there is a real problem that justifies building the system.

This is where a tool like Painstack can be particularly useful.

In the discovery phase, the team can use it to:

structure the problem hypothesis;
gather market signals and sources;
confront assumptions with evidence;
identify alternatives users already adopt;
separate real needs from imagined features;
record why a given solution is being considered.

That work can feed important parts of the later process:

the intended purpose of the system;
potentially affected groups;
product decisions;
identified risks;
less intrusive alternatives;
justification for using AI;
a history of evidence and changes of direction.

But there is an important boundary:

Painstack can support validation, research and the record of decisions. It does not replace a legal assessment, a dedicated compliance tool, or the technical documentation required by the AI Act.

It should also not be used to upload personal or sensitive data without a legal basis and appropriate controls.

Painstack's role sits at the start of the process: helping the team decide what is worth building and on what evidence.

After that come engineering, security, data protection, risk assessment and legal review.

A 30-day plan for founders

Week 1 — Inventory

Create a record of every AI system used in the company.

For each system, identify:

tool name;
provider and model;
internal owner;
purpose;
users;
affected people;
data submitted;
outputs produced;
decisions it influences;
country of use;
contract and retention policy;
date of the last review.

Include tools teams use informally. The biggest risk can sit in a free account that never went through procurement.

Week 2 — Classify

For each use, ask:

Are we provider, deployer, importer or distributor?
Is there any prohibited practice?
Could it be a high-risk system?
Is there direct interaction with people?
Does it generate or manipulate content?
Does it produce deepfakes?
Does it publish text on matters of public interest?
Does it process personal, biometric or sensitive data?
Does it influence decisions on employment, credit or access to services?

Doubtful systems should be flagged for legal review.

Week 3 — Fix transparency and providers

Implement the measures that are already relevant:

visible identification of chatbots;
labels on deepfakes;
disclosure on covered publications;
preservation of machine-readable markings;
documented human review;
rules against fabricated testimonials and demos;
contacting providers for documentation;
updating internal usage terms.

Week 4 — Set up minimum governance

Define:

an internal owner for AI;
an acceptable use policy;
an approval process for new tools;
role-based training;
an incident response plan;
a review cadence;
criteria for human oversight;
a log of provider or model changes;
situations that require a lawyer, DPO or security specialist.

The goal is not to produce bureaucracy. It is to make sure someone can answer, with evidence, for how AI is used in the company.

Fines should not be the only reason to act

The most serious infringements, including certain prohibited practices, can reach caps of 35 million euros or 7% of total worldwide annual turnover, depending on the applicable rules.

Other breaches can reach 15 million euros or 3%, and supplying incorrect or misleading information to authorities can reach 7.5 million euros or 1%.

Article 99 provides for treatment of these caps for SMEs, including startups, whereby the fine should not exceed the lower of the relevant percentage or fixed caps.

These are maximums, not automatic amounts. The assessment considers factors such as severity, duration, cooperation and company size.

Even so, the biggest early risk for many startups may be commercial:

losing an enterprise contract;
failing investment due diligence;
being unable to answer a security questionnaire;
discovering late that the product was built for a high-risk purpose;
having to rebuild the data flow or human oversight.

Compliance done well is not only a defence against a fine. It is part of preparing the product for more demanding customers.

Conclusion

The EU AI Act does not require every startup to create a legal department overnight.

It requires something more basic: knowing where you use AI, what your role is, what risks you are introducing, and what information you owe the people affected.

For many founders, the priorities are clear:

Identify the AI uses;
Remove prohibited practices;
Meet the transparency rules that already apply;
Prepare the systems that could be classified as high risk;
Train teams according to their role;
Require documentation from providers;
Record decisions and evidence from the start.

Painstack can help answer the first product question:

Is there enough evidence to build this?

The AI Act forces you to answer the ones that follow:

How will it be used, who can be affected, and how do we show we acted responsibly?

No single tool guarantees compliance.

But a startup that validates the problem, documents decisions, knows its providers and designs transparency from the start is better prepared than a company trying to rebuild everything after launch.

EU AI Act: What Startup Founders Need to Know and Do Now

The AI Act is no longer a "later" problem. For many startups, the transparency rules already apply. The first step is not hiring a legal team: it is finding out where AI is actually being used, which decisions it influences, and what evidence the company can produce.

The AI Act can apply even if the startup is not based in the EU