The EU AI Act's fines of up to €15 million or 3% of turnover apply to how you build and run software, not just to big AI labs, and small businesses need to act now.
Direct answer: Yes, the AI Act's fines can reach small businesses in Europe, not just large AI vendors — non-compliance now risks penalties of up to €15 million or 3% of global annual turnover, whichever is higher. If your website, app, or internal tools use AI features like chatbots, recommendation engines, or automated decision-making, you have compliance obligations regardless of your company size. The practical fix is mostly architectural: know what AI systems touch your product, document how they work, and build in the transparency and human-oversight controls the law requires.
Euronews reported on August 2, 2026 that non-compliance with the EU AI Act now risks fines up to €15 million or 3% of global turnover, a figure that has been circulating in headlines as a warning aimed at Big Tech. That framing misses something important for the owner of a smaller company: the AI Act's obligations attach to how an AI system is used and what risk category it falls into, not to the size of the company deploying it. A small e-commerce brand running an AI-driven pricing tool, a professional services firm using an AI chatbot to screen leads, or a local retailer using AI in hiring software can all fall under the same rules that produced that headline number. The specific percentage-of-turnover mechanism mirrors GDPR's enforcement structure, which many small businesses already learned the hard way applies to them too. What's different this time is that the AI Act layers new documentation, transparency, and risk-classification duties on top of the data-protection rules already in force. A precise count of how many small businesses have been fined under the AI Act specifically is not publicly available yet, since enforcement is still ramping up through 2026, but the pattern from GDPR enforcement is a reasonable guide: regulators tend to start with high-profile cases and then work down into mid-market and small business territory once the rules are established.
What the AI Act Fine Structure Actually Covers
The AI Act sorts AI systems into risk tiers — unacceptable risk (banned outright), high risk, limited risk, and minimal risk. The €15 million or 3% of turnover ceiling applies to the most serious violations, typically involving banned practices or failures around high-risk systems. But even businesses using "limited risk" AI, like a customer-facing chatbot, have transparency obligations: users need to know they're interacting with AI. Get that wrong at scale and you're exposed, even if your fine tier is lower than the headline number.
For a small business, the practical question is not "am I building a banned social-scoring system" — almost certainly you're not. The real exposure comes from three overlooked areas:
Where small businesses actually get caught
- Third-party AI embedded in your stack. If your website uses an AI chatbot vendor, an AI-powered recommendation widget, or an AI scheduling assistant, you are the deployer under the Act, and deployers carry real obligations even when they didn't build the underlying model.
- AI in HR and hiring tools. Applicant screening or interview-scoring tools are explicitly called out as higher-risk use cases, and plenty of small businesses use off-the-shelf HR software with AI features they never evaluated for compliance.
- Undocumented decision logic. If an AI system on your site makes or influences a decision that affects a customer — pricing, credit, eligibility, content moderation — and you can't explain how it works, that's a gap regulators are specifically trained to look for.
None of this requires you to have built a large language model. It requires you to know exactly what AI is running inside your product and to have documentation and oversight structures around it.
It's worth being specific about why the risk-tier structure matters rather than treating "AI Act" as a single monolithic rule. A minimal-risk system — say, an internal tool that auto-tags support tickets by topic for your own team's convenience — carries essentially no formal obligation beyond general good practice. A limited-risk system that a customer interacts with directly, like a chatbot or a content-generation tool that produces text a user reads, carries the transparency duty described above. A high-risk system — one that materially affects a person's access to employment, credit, insurance, or essential services — carries the heaviest documentation, testing, and oversight burden. Most small businesses have a mix: a customer-facing chatbot (limited risk), a backend automation tool (minimal risk), and possibly one HR or credit-adjacent tool they've never separately evaluated (potentially high risk). The fine exposure scales with which tier a given system sits in, which is exactly why the inventory step matters more than any other single action you can take.
Why This Matters Specifically for Small Business Owners in Europe
Small business owners across Europe are in a genuinely tighter spot than either large enterprises or the smallest single-person shops. Large enterprises have compliance and legal teams already tracking this; the smallest businesses often use so little AI that they fall under minimal-risk categories by default. It's the small business with a real website, a CRM, maybe a chatbot, and a handful of automated workflows — the profile Scult typically builds for — that sits squarely in scope without the internal resources to track it.
There's also a second-order effect worth naming plainly: even where your own risk of a fine is genuinely low, customers and partners are starting to ask AI-compliance questions during procurement, the same way they started asking GDPR questions a few years ago. A small business that can point to a documented AI inventory and clear user-facing disclosures has a real advantage in B2B sales conversations, quite apart from avoiding penalties.
The region matters here too. Because the AI Act applies to any product or service offered into the EU market, a small business owner in, say, Ireland, the Netherlands, or Poland selling into other EU countries doesn't get to treat this as someone else's problem based on where they happen to be headquartered. The extraterritorial reach that made GDPR famous is built into the AI Act's design from the start.
What Changes in Practice for Your Website or App
This is where the abstract compliance conversation becomes a concrete web development conversation. If your product uses AI in any customer-facing way, several things need to change at the code and product level, not just in a policy document sitting in a drawer.
Disclosure has to live in the interface, not just the terms of service. A chatbot needs a visible, unambiguous signal that the user is talking to AI — not buried in a footer link. This is a front-end and conversation-design change, not a legal one.
You need an audit trail for AI-influenced decisions. If your app recommends a product, scores a lead, or flags a support ticket, the system needs to log enough about the decision path that you can explain it later. That's a logging and data-architecture requirement that has to be designed in, not bolted on after the fact.
Human oversight needs a real interface, not a theoretical one. "A human can review this" only counts if there's an actual screen where a human reviews it, with the information they need to make a real judgment. For a small business, this often means a lightweight internal admin panel rather than a full enterprise workflow tool — but it does need to exist and be usable.
Third-party AI components need contractual and technical visibility. If you're relying on a vendor's AI feature, you need to understand its risk classification and get documentation from that vendor. This affects vendor selection going forward and may mean re-evaluating tools you already have live in production.
For most of the small businesses we work with, none of this means ripping out and replacing an app. It means an audit of the current codebase to map every point where AI logic touches a user or a decision, followed by targeted engineering work: clearer UI disclosures, structured logging around AI-driven features, and an internal review interface where none existed. This is squarely Web Development work — the compliance requirement gets satisfied through the same product engineering discipline you'd apply to any feature launch, just with a specific checklist attached.
There's a useful parallel in a highly regulated adjacent space: fintech apps have had to build this kind of auditability and human-oversight logic into their products for years because financial regulators require it. Our guide on investment app development, cost, and compliance walks through how that discipline gets built into a product from the ground up, and the same patterns — audit logging, explainability, human review gates — map directly onto AI Act compliance for a much wider range of businesses now.
Do You Even Have AI in Your Product? (The Question Most Owners Skip)
A surprising number of small business owners underestimate how much AI is already running through their stack. Voice assistants for customer calls, automated email routing, AI-based fraud checks on payments, dynamic content personalization — these often get added by a marketing platform or a plugin without anyone treating it as an "AI system" the business is now responsible for.
If your business has adopted voice AI for customer calls or automated outbound calling, that's exactly the kind of feature that now needs a compliance look. Our piece on voice AI and automated calling for small businesses covers what's actually possible with this technology today, and it's worth reading with an eye toward which of those capabilities you've already deployed without a formal review. If you have, that's your starting point for an AI Act inventory: list every automated calling flow, what decisions it makes or influences, and whether callers are clearly told they're talking to an automated system.
The same logic extends to infrastructure decisions that seem unrelated to compliance on the surface. As AI features get built into more products, the underlying infrastructure — where models run, how much energy that costs, and under what rules — is also getting new regulatory attention across the EU. Our overview of green data centers and the new EU and German rules reshaping AI infrastructure is a reminder that AI Act compliance doesn't exist in isolation; it's one strand of a broader regulatory tightening around how AI gets built and deployed in Europe, and businesses that get ahead of one strand are generally better positioned for the others.
What to Do About It: A Practical Sequence
Rather than treating this as a single large project, most small businesses handle AI Act exposure in a sequence that fits inside normal web development cycles:
- Inventory. List every feature in your website, app, and internal tools that uses AI, including third-party widgets and plugins. Be honest about what counts — a "smart" recommendation carousel counts. This step often takes longer than expected precisely because AI features get added incrementally by different tools over time, and nobody keeps a running list; walking through every page of your site and every internal workflow with fresh eyes is the only reliable way to catch everything.
- Classify. For each item, work out roughly which risk tier it falls into. Most small business use cases land in limited or minimal risk, but a few — anything touching hiring, credit, or eligibility — deserve a closer look.
- Disclose. Add clear, visible AI disclosure wherever a user interacts with an AI system directly.
- Log and document. Build or extend logging so AI-influenced decisions can be explained after the fact, and write down, in plain language, how each system works.
- Review. Put a real human review step in place for anything higher-risk, with an interface that makes review genuinely possible, not just theoretically available.
- Re-check vendors. Ask AI feature vendors for their own compliance documentation, and factor AI Act readiness into future vendor and platform choices.
Steps 3 through 5 are primarily engineering work, which is why this compliance requirement ends up on a web development team's desk rather than only a legal one.
It's also worth sequencing this sensibly against your normal product roadmap rather than treating it as an emergency bolt-on. Most small businesses fold the inventory and classification steps into a routine site or app audit, then schedule the disclosure and logging work alongside their next planned feature release, so it lands as part of ordinary development cadence rather than as a separate, disruptive project. That approach also tends to produce better engineering outcomes: disclosure UI designed alongside a feature reads more naturally than a banner retrofitted after the fact, and logging designed into a data model from the start is more reliable than logging patched on top of an existing one.
A Note on Vendors and Ongoing Maintenance
Compliance here isn't a single checkbox you tick once. AI vendors update their models and features regularly, sometimes changing what a tool does well after you first integrated it. A chatbot vendor might roll out a new capability that shifts what the tool actually does, or a recommendation engine might start using a different underlying model with different behavior. Building a habit of periodically re-checking your AI inventory — quarterly is reasonable for most small businesses — catches this kind of drift before it becomes a gap you discover during an audit or a customer's procurement questionnaire. The same discipline that keeps a website secure over time (dependency updates, periodic reviews) applies here: AI Act readiness is a maintenance practice, not a one-time deliverable.
Pricing Context: What This Kind of Work Typically Falls Under
AI Act readiness work varies a lot depending on how much AI is already embedded in your product and how much of the disclosure, logging, and review-interface work needs to be built from scratch. As a general guide for where this kind of engagement typically lands:
| Tier | Typical scope | Fits AI Act work when... |
|---|---|---|
| Essential — $1,000 | AI inventory review, UI disclosure updates, basic documentation | You have one or two AI touchpoints (e.g. a chatbot) needing clear disclosure and a written explanation of how it works |
| Growth — $2,000 | Inventory + disclosure + structured logging for AI-influenced decisions | Your product has several AI features across the customer journey and needs an audit trail, not just a disclosure banner |
| Enterprise — $4,000+ | Full audit, logging architecture, human-review interface, vendor documentation process | You operate higher-risk AI use cases (hiring, credit, eligibility scoring) or need an ongoing compliance-review process built into your engineering workflow |
These are the same service tiers Scult uses across web development engagements generally — AI Act compliance work slots into the tier that matches its actual scope rather than requiring a separate pricing model. What actually determines which tier a given business needs is less about company size and more about how many AI touchpoints exist and how consequential their decisions are — a five-person consultancy with an AI-driven eligibility screener can need Enterprise-tier depth, while a fifty-person retailer with a single disclosed chatbot may only need Essential-tier work.
Key Takeaways
- The AI Act's fines apply based on what an AI system does and its risk classification, not on company size — small businesses using third-party AI features are in scope.
- The most common exposure for small businesses is embedded third-party AI (chatbots, HR tools, recommendation engines), not custom-built models.
- Visible disclosure that a user is interacting with AI is a front-end requirement, not just a legal document.
- Audit logging for AI-influenced decisions needs to be designed into your product architecture, ideally before a regulator asks for it.
- A practical first step is a full inventory of every AI touchpoint in your website, app, and internal tools — most owners are surprised by what's already live.
- This work fits naturally into a normal web development engagement rather than requiring a separate compliance project.
Getting ahead of AI Act exposure is far cheaper than reacting to it after an inquiry, and most of the work is ordinary, well-scoped engineering rather than a legal overhaul. If you want help mapping what's actually running in your product and closing the gaps, book a meeting with our team.
Frequently Asked Questions
What is the EU AI Act in simple terms?
The EU AI Act is a regulation that classifies AI systems by risk level and sets rules for each level, covering everything from outright bans on certain uses to transparency and documentation requirements for lower-risk applications. It applies to any AI system offered into the EU market, regardless of where the company behind it is based.
Does the AI Act apply to small businesses, not just big tech companies?
Yes. The Act's obligations attach to the AI system's use case and risk classification, not the size of the company using it, so a small business running an AI chatbot or recommendation tool has real obligations under the law.
What exactly triggers the €15 million or 3% of turnover fine?
That maximum fine tier is reserved for the most serious violations, generally involving banned AI practices or serious breaches related to high-risk AI systems. Lower-tier violations, like inadequate transparency disclosures, carry lower penalty ranges, but they're still enforceable.
How would a small business even know if it's using a "high-risk" AI system?
You need to inventory every AI feature in your product and check it against the Act's listed high-risk categories, which include areas like employment screening, credit scoring, and eligibility decisions. Most small business AI use — chatbots, personalization, basic automation — falls into lower-risk tiers, but it's worth checking rather than assuming.
If I just use a third-party AI chatbot plugin, am I responsible for compliance?
Yes, as the deployer of that AI system on your website, you carry deployer-level obligations under the Act even though you didn't build the underlying model. That typically includes disclosure to users and understanding the vendor's own risk documentation.
What counts as "AI" under the Act — does basic automation count?
The Act's definition is broader than most people expect and generally covers systems that use machine learning or similar techniques to generate outputs like predictions, recommendations, or decisions. Simple rule-based automation (like an if-this-then-that email filter) generally does not count, but many "smart" features marketed as AI do.
Do I need to tell users when they're talking to a chatbot?
Yes, transparency obligations under the Act generally require that users be clearly informed when they are interacting with an AI system rather than a human, especially in customer-facing contexts like support chat.
What does "human oversight" actually mean in practice?
It means a real person has the ability, information, and interface needed to review and override an AI system's output before it causes harm, particularly for higher-risk uses. A theoretical ability to review without an actual usable interface generally doesn't satisfy this requirement.
How is this different from GDPR compliance?
GDPR governs how personal data is collected, stored, and processed; the AI Act governs how AI systems themselves are built, classified, and disclosed. They overlap significantly in practice — an AI system that processes personal data has obligations under both — but they're separate regulatory frameworks with separate documentation requirements.
My business is registered outside the EU — does the Act still apply to me?
If you offer your product or service into the EU market, the Act's extraterritorial reach generally applies to you, similar to how GDPR applies to non-EU companies serving EU customers. Where exactly your business is headquartered matters less than where your users are.
What's the first practical step I should take?
Start with a full inventory of every AI feature across your website, app, and internal tools, including anything embedded via a third-party plugin or platform. You can't assess your risk exposure until you know exactly where AI is actually running in your product.
How long does an AI inventory and compliance review typically take?
For a small business with a handful of AI touchpoints, an inventory and initial classification review typically takes a few weeks as part of a broader engineering engagement, though timelines depend heavily on how much documentation already exists and how many systems need investigation.
What does AI Act compliance cost for a small business?
Cost depends heavily on scope: a business with one or two AI touchpoints needing disclosure and documentation sits toward the lower end of typical engagement pricing, while a business with several AI features needing logging and a review interface sits higher. It's rarely a fixed, one-size-fits-all number.
Can I handle AI Act compliance myself without hiring anyone?
For very simple setups — a single disclosed chatbot with clear documentation — some owners can handle the basics themselves. Once logging, audit trails, or a review interface are needed, it typically requires engineering work best done by a team already familiar with your codebase.
What happens if I ignore this and do nothing?
Enforcement is still ramping up through 2026, so immediate consequences for a small business are unlikely today, but the risk grows over time as regulators move down from headline cases into broader enforcement, the same pattern seen with GDPR.
Is there a grace period for small businesses?
The Act includes phased implementation timelines by risk category rather than a blanket small-business exemption, so the practical safety comes from acting before your specific use case enters active enforcement scope, not from your company size.
Does the AI Act cover AI used only internally, not customer-facing?
Yes, internal AI systems — like AI-assisted hiring tools or internal decision support — can still fall under the Act's risk classifications, particularly employment-related tools, which are explicitly called out as higher-risk.
What documentation do I actually need to produce?
At minimum, a plain-language explanation of how each AI system works, what data it uses, what decisions it influences, and what human oversight exists. Higher-risk systems require more detailed technical documentation and logging.
How does this affect my website's chatbot specifically?
Your chatbot needs a visible disclosure that it's AI, documentation of how it works and what data it accesses, and ideally a clear path for users to reach a human when needed. This is largely a front-end and conversation-design task.
What about AI features in my email marketing or CRM tools?
If those tools use AI to score leads, personalize content, or make recommendations that affect customers, they fall under the same inventory-and-disclosure logic as any other AI feature, even though they're not directly customer-facing on your website.
Does using AI for content generation (blog posts, product descriptions) create AI Act exposure?
Generative AI used for content creation generally falls under lower-risk transparency rules, primarily around disclosing AI-generated content in certain contexts, rather than the stricter high-risk category rules.
What's the risk if I use AI in hiring or recruitment for my small business?
Hiring and employment-related AI is explicitly flagged as higher-risk under the Act, so tools that screen resumes, score candidates, or influence interview decisions deserve a closer compliance look than general customer-facing AI features.
Can my existing web developer handle this, or do I need a specialist?
Much of the practical work — disclosure UI, logging architecture, review interfaces — is standard web development work that an experienced team can handle, provided they understand the specific requirements to build toward. It's less about needing an entirely separate specialist and more about scoping the work correctly.
How does audit logging for AI decisions actually get built?
It typically means capturing, alongside each AI-influenced action, the inputs the system used, the output it produced, and enough context to reconstruct why that decision happened later. This is a data architecture and logging design task integrated into the relevant feature.
What if my AI vendor won't provide compliance documentation?
That's a signal to reconsider the vendor relationship, since as the deployer you still carry obligations even if your vendor is unresponsive. Building vendor AI-compliance documentation into your procurement process going forward reduces this risk.
Does this apply to mobile apps as well as websites?
Yes, the Act's obligations are based on the AI system's function and market reach, not the platform, so a mobile app with AI features carries the same obligations as a website with equivalent features.
How do I explain this to a non-technical business partner?
Frame it as: any AI feature in your product needs to be visible to users, explainable after the fact, and reviewable by a person for higher-stakes decisions — the same discipline responsible businesses already apply to security and privacy.
Is there a difference between AI Act rules for AI I built versus AI I bought?
Both AI providers (who build systems) and deployers (who use them) have obligations, though they differ in scope — providers carry more technical documentation duties, while deployers focus more on appropriate use, disclosure, and oversight.
What's a realistic worst case if a small business is found non-compliant?
Enforcement typically starts with corrective orders and lower-tier penalties before escalating, mirroring how GDPR enforcement against smaller businesses has generally unfolded, though the statutory ceiling is the headline figure.
How often should I re-review my AI inventory?
Whenever you add a new AI-powered feature, switch vendors for one, or launch a new product area, since new AI touchpoints can shift your risk classification without anyone deciding that on purpose.
Does personalization on my e-commerce site count as AI under the Act?
If the personalization engine uses machine learning to generate its recommendations, it likely counts and would generally fall into the lower-risk tier requiring basic transparency rather than the stricter high-risk rules.
What role does a privacy policy play versus AI Act disclosure?
They serve different purposes — a privacy policy covers data handling under GDPR, while AI Act disclosure specifically needs to make clear, in the interface itself, that a user is interacting with or affected by an AI system. One doesn't substitute for the other.
Should I be worried about AI I use for fraud detection on payments?
Fraud detection AI can influence outcomes that affect customers directly, so it's worth reviewing for documentation and human-review pathways, even though it typically isn't in the most restrictive risk category.
How does the AI Act interact with EU consumer protection law?
The two frameworks work in parallel — consumer protection law already restricts unfair or deceptive practices, and the AI Act adds specific transparency and risk-based requirements on top for AI-driven decisions and interactions.
What's the single biggest mistake small businesses make with this?
Assuming that because they didn't build the AI model themselves, they have no compliance responsibility. As a deployer of third-party AI features, that assumption is incorrect and is exactly where regulatory attention tends to land first for smaller companies.
Can I retrofit compliance onto an existing app, or do I need to rebuild?
Retrofitting is the normal path for almost every small business — disclosure banners, added logging, and a review interface can generally be layered onto an existing architecture without a full rebuild.
What's the relationship between AI Act compliance and good UX?
Well-designed AI disclosure and human-oversight interfaces tend to build user trust rather than undermine it, so compliance work here often improves the product experience rather than just adding regulatory overhead.
How do voice AI and automated calling tools fit into this?
If your business uses AI for automated outbound or inbound calls, those interactions need the same disclosure and documentation treatment as any other customer-facing AI system, and the compliance review should specifically cover call scripts and recording practices.
Is AI Act compliance a one-time project or an ongoing process?
It's ongoing — every new AI feature, vendor change, or product update potentially shifts your obligations, so most businesses fold it into their regular product review process rather than treating it as a single completed task.
What should I ask an AI feature vendor before signing a contract?
Ask for their own risk classification of the feature, what data it processes, what documentation they can provide about how it makes decisions, and whether they support the disclosure and logging requirements you need to meet on your end.
Does the size of my customer base affect my compliance risk?
A larger customer base generally means more instances of an AI system's decisions being made, which can increase both actual risk of harm and regulatory visibility, even though the underlying legal obligations don't scale with customer count directly.
What does "limited risk" actually require me to do?
Limited-risk AI systems primarily carry transparency obligations — telling users clearly that they're interacting with AI — rather than the more extensive technical documentation and oversight required for high-risk systems.
How does this affect a small business selling B2B versus B2C in the EU?
Both are in scope, but B2B buyers are increasingly asking AI-compliance questions during procurement, so B2B sellers may face commercial pressure to document compliance even before regulatory enforcement reaches them directly.
What's the difference between "AI Act compliant" and "GDPR compliant" in a sales conversation?
GDPR compliance addresses how you handle personal data; AI Act compliance addresses how your AI features are classified, disclosed, and overseen. Being able to speak to both separately signals a more mature, thorough approach to a prospective client or partner.
Can green infrastructure or data center choices affect my AI Act exposure?
Not directly for most small businesses, but the same regulatory tightening trend extends into AI infrastructure rules across the EU, and businesses building AI-heavy products should be aware that infrastructure-level rules are evolving alongside application-level ones.
What's a reasonable first-quarter action plan for a small business?
Complete an AI inventory, classify each system by risk tier, add clear disclosures for any customer-facing AI, and scope logging or review-interface work for anything higher-risk — spread across a normal development sprint cycle rather than a single crash project.
How do I know if my current website already meets basic transparency requirements?
Check every AI-driven touchpoint — chatbots, recommendation widgets, automated messaging — for a clear, visible statement that the user is interacting with AI. If that disclosure isn't immediately obvious to a user, it likely doesn't meet the bar.
Will AI Act enforcement get stricter over time?
Based on the pattern from GDPR and similar EU regulations, enforcement typically starts with prominent cases and expands in scope and frequency as regulators build capacity and precedent, so the safest assumption is that scrutiny increases rather than decreases.
What if I'm planning to add AI features to my app soon — should I build compliance in from the start?
Yes, designing disclosure, logging, and review interfaces into a new AI feature from the outset is significantly cheaper and cleaner than retrofitting them later, and it avoids launching a feature that's non-compliant on day one.
Who should actually own AI Act compliance inside a small business?
Ownership typically sits with whoever owns the product or website, working alongside development and, where available, legal counsel, since the practical fixes are largely engineering work guided by the legal requirements rather than a purely legal exercise.



