You have probably read that the AI Act was delayed. That is half the story, and the missing half is the part that is live.
Regulation (EU) 2026/1744 — the "Digital Omnibus on AI" — was adopted on 8 July 2026 and came into force on 27 July 2026. It moved the high-risk obligations under Annex III from August 2026 to 2 December 2027, and the embedded-in-products tranche to 2 August 2028. The stated reason was that harmonised standards and national authorities were not ready.
It did not touch Article 50. The transparency obligations applied from 2 August 2026, exactly as originally scheduled. They are in force as you read this.
| AI Act obligation | Applies from | Status today |
|---|---|---|
| Prohibited practices · AI literacy | 2 February 2025 | In force |
| General-purpose AI models · governance · penalties | 2 August 2025 | In force |
| Transparency (Article 50) | 2 August 2026 | In force now |
| Machine-readable marking, for systems already on the market | 2 December 2026 | Grace period |
| High-risk — Annex III | 2 December 2027 | Delayed from Aug 2026 |
| High-risk — embedded in regulated products | 2 August 2028 | Delayed from Aug 2027 |
Three cases. Find yours.
A CRM, a booking system, a dashboard. It stores and displays records. It does not itself use AI.
The one residual item is Article 4 on AI literacy, which binds deployers — and which the July 2026 omnibus softened to a duty to "take measures to support the development of AI literacy" among staff. It is not among the obligations carrying a direct administrative fine.
A chatbot, a summariser, anything that generates content for your users. This is where most people building with AI actually sit.
In practice: a visible line saying your assistant is an AI, shown before the first message, usually discharges Article 50(1). It is close to the cheapest compliance step in EU digital law, and it is due now.
Do not skip this on the assumption that high-risk means big companies. It does not. Annex III catches things small SaaS companies build all the time:
An AI CV-screening feature in a 3-person HR SaaS is high-risk. The obligations bite from 2 December 2027, which is time to prepare, not time to ignore.
There is a filter. Article 6(3) exempts an Annex III system that poses no significant risk of harm and only performs a narrow procedural task, improves a prior human activity, detects decision patterns without replacing human review, or does preparatory work. But a system that profiles natural persons is always high-risk, with no exemption. If you rely on the filter, you must document the assessment.
The headline numbers — up to €35m or 7% of worldwide turnover for prohibited practices, €15m or 3% for most other breaches including Article 50 — are real but widely misread for small companies. Article 99(6) inverts the rule for SMEs and start-ups: the fine is capped at the lower of the fixed sum and the percentage, not the higher. For a company turning over €2m, Article 50 exposure is 3% of that, not €15m. Article 99(1) also requires penalties to take into account the interests of SMEs.
Before any of this matters, you need to know what your app currently exposes. Broid grades any live URL A–F in seconds, free, including a live test of whether your database is readable by strangers.
Scan my app free →If your app touches any personal data of anyone in the EU — an email address is enough — GDPR applies. There is no small-business exemption. A solo founder is subject to Article 32 in the same terms as a bank.
It requires "appropriate technical and organisational measures to ensure a level of security appropriate to the risk", judged against the state of the art, the cost of implementation, and the risk to people. It is deliberately relative: a two-person SaaS holding email addresses is judged differently from one holding health records.
But it does name four things, and the fourth is the one worth reading twice:
Read 32(1)(d) precisely: a process for regularly testing. Not a certificate, not a one-off audit before launch. A recurring practice of checking whether your measures actually work. That is the obligation most small companies have no answer to at all — and it is the cheapest one to fix.
Not the absence of exotic controls. The boring stuff:
| Case | Fine | What went wrong |
|---|---|---|
| Vastaamo (Finland, Dec 2021) | €608,000 | An unprotected MySQL port; a root account with no password, reachable from any IP address; the database server "open to the internet without the protection of a firewall" for over a year. Logging was inadequate, so they could not establish when the breach happened. The breach was also reported 18 months late. |
| Free and Free Mobile (CNIL, Jan 2026) | €42,000,000 | Breach of Article 32: VPN authentication "was not sufficiently robust", anomaly-detection measures "ineffective", confidentiality measures inadequate. ~24 million subscriber contracts, including IBANs. Also fined under Article 34 because the notification to users omitted required information. |
| Meta (Irish DPC, Dec 2024) | €251,000,000 | Includes €11m purely for notification and documentation failures — €8m for an incomplete breach notification and €3m for failing to document breaches. |
Every one of those is a variation on the same theme: something was reachable that should not have been, and nobody was checking. That is precisely what an external scan tests.
This is the part small builders most often get wrong, and the consequences are procedural rather than technical.
There is an honest counterweight worth knowing. In the EDPB's own worked examples, exfiltration of passwords hashed with a state-of-the-art algorithm, with no contact data taken, required no notification at all — because it presented no risk to the people concerned. Good security genuinely reduces your notification burden.
This is the most useful "no" on this page, because the CRA's first hard date is 11 September 2026 and a lot of coverage implies it catches everything.
The CRA regulates products with digital elements placed on the EU market. Recital 12 of the Regulation is unusually direct about hosted software:
So a hosted web app you sell as a subscription is out of CRA scope, and routed to NIS2 instead. You are pulled back in only if your cloud service is the backend that makes a physical or downloadable product work — the classic case being a companion service built by a connected device's manufacturer.
Look again if you ship anything downloadable — a desktop app, a CLI, a mobile app, a browser extension, a published library. That is software placed on the market, and the dates matter:
There is a genuine carve-out worth knowing: microenterprises and small enterprises may not be fined for missing the 24-hour reporting deadline, and conformity assessment must take due account of company size, including fees. The Commission published implementation guidance on 27 July 2026 with worked examples and flowcharts aimed specifically at SMEs — it is the right document for a borderline case.
NIS2 covers cloud computing services, and its recitals name Software as a Service explicitly. You are a covered sector. What keeps you out is the size cap: the obligations reach entities that are medium-sized or larger — broadly, 50 or more staff, or annual turnover and balance sheet total both above €10 million.
Two things follow. First, this is a threshold you can cross by growing, and you will cross it as an "important entity" with security-measure and incident-reporting duties attached. Second — and this is how most small SaaS actually meets NIS2 — your in-scope customers are responsible for supply-chain security, so they will push equivalent obligations onto you contractually long before you are regulated directly. A security questionnaire from an enterprise buyer is NIS2 arriving through the front door.
Article 5(3) of the ePrivacy Directive requires prior consent before storing information on, or reading information from, a user's device — unless it is strictly necessary to deliver a service the user explicitly requested. Three things people get wrong:
In force since 28 June 2025, it covers e-commerce services — services provided at a distance with a view to concluding a consumer contract. A pure B2B SaaS is outside it. And service providers that are microenterprises — fewer than 10 staff and turnover or balance sheet not above €2m — are exempt. A solo founder selling a consumer subscription is exempt; a 15-person consumer SaaS is not, and needs to meet the accessibility requirements.
We sell an automated external scanner, so here is the careful version rather than the flattering one.
| Obligation | What a scan does | What it does not do |
|---|---|---|
| GDPR Art. 32(1)(d) — process for regularly testing and evaluating measures | Provides a repeatable, dated external test of your live application, and a record that you ran it. Regular external testing is one form the "process" can take. | It is not the whole process. It does not cover your organisational measures, staff access, backups, or your suppliers. |
| GDPR Art. 32(1)(b) — confidentiality of processing | Tests whether your database is readable by anonymous strangers, whether secrets are exposed in your front end, and whether endpoints are unauthenticated — the exact failures regulators have fined. | It does not log in, so it cannot test whether one signed-in user can read another's data. |
| GDPR Art. 33 — 72-hour notification | Helps you find out, which is the precondition for everything else. You cannot notify a breach you never detected. | It does not tell you whether a breach is notifiable. That is a legal judgement about risk to individuals. |
| AI Act Art. 50 — transparency | Nothing. This is a disclosure duty, not a security control. | No scanner of any kind helps here. Put a line in your chat interface. |
| CRA Art. 14 — vulnerability reporting | Only relevant if you ship a product with digital elements, and then only as one input to knowing what is wrong. | It is not a vulnerability-handling process, and it is not conformity assessment. |
| NIS2 · SOC 2 · ISO 27001 | Nothing directly, though buyers' security questionnaires often ask whether you test regularly, and a dated report answers that question. | It is not a certification and cannot be presented as one. |
Not on that basis alone. The AI Act regulates AI systems, and an ordinary CRM or booking app is not one — it executes deterministic logic rather than inferring outputs. You are a deployer of the coding tool, and deployer obligations attach only to high-risk systems, which a coding assistant is not. If your app itself calls an AI model, that is a different question — then your app is an AI system and you are its provider.
Partly. Regulation (EU) 2026/1744, in force 27 July 2026, moved the high-risk obligations under Annex III to 2 December 2027 and the embedded-in-product tranche to 2 August 2028. It did not change Article 50 — the transparency obligations applied from 2 August 2026 and are in force now. Prohibited practices (Feb 2025) and general-purpose AI model rules (Aug 2025) were also unaffected.
Yes, if it interacts directly with people and that fact is not already obvious to a reasonably well-informed, observant person. Article 50(1) has applied since 2 August 2026. The disclosure must be clear and distinguishable, and given at the latest at the time of the first interaction. A visible line before the first message normally discharges it.
It does not mandate any specific control. Article 32(1)(d) requires "a process for regularly testing, assessing and evaluating the effectiveness" of your security measures — a recurring process, not a named product. A penetration test is one way; automated external scanning on a schedule is another and far cheaper. What regulators have actually fined is the absence of basic controls: exposed ports, unauthenticated accounts, weak authentication and inadequate logging.
Yes. Article 4(12) covers unauthorised disclosure as well as access, so exposure through misconfiguration qualifies. The EDPB has explicitly rejected the "no logs, therefore no breach" argument, stating that a controller "cannot state that the absence of a log entry proves the absence of exfiltration". The notification test is whether risk to individuals is unlikely, not whether access is proven — and uncertainty usually counts against you.
Almost certainly not. Recital 12 states that cloud services developed outside the responsibility of a manufacturer of a product with digital elements fall outside the CRA, and routes SaaS to NIS2 instead. You are caught if your cloud service is what makes a physical or downloadable product function, or if you ship anything downloadable yourself — a desktop app, CLI, mobile app, browser extension or published library.
SaaS is a covered sector — the directive's recitals name it explicitly. What keeps most small companies out is the size cap: broadly 50 or more staff, or turnover and balance sheet total both above €10 million. In practice, small vendors meet NIS2 through their customers: in-scope buyers are responsible for supply-chain security, so they impose equivalent requirements contractually.
No, and nobody should tell you it can. Compliance covers lawful basis, transparency, data subject rights, retention, contracts with processors, international transfers and much else that no scanner touches. What a scan contributes is a dated, repeatable external test of your live application — evidence toward the "regularly testing" limb of Article 32(1)(d), and the baseline you need before you can sensibly prioritise anything.
An A–F grade in seconds, no signup, including a live test of whether a stranger can read your database. Re-run it whenever you change something.
Scan my app freeA scan is evidence toward a testing process — not a compliance certificate. We would rather say so than sell you one.