If your company touches AI and serves users in the European Union, the EU AI Act is now the most consequential piece of legislation on your roadmap. The first big enforcement window opens on 2 August 2026 — that is 53 days from publication — and the fines for getting it wrong reach €35 million or 7% of global annual turnover, whichever is greater.
This guide is for the SaaS practitioner — founder, CTO, head of compliance, security lead — who needs to ship a defensible compliance position fast, not read 144 pages of legislation. It covers what the Act actually regulates, where your AI systems sit on the risk tiers, the nine obligations that hit most SaaS companies, and a 90-day plan you can execute starting on Monday.
TL;DR: the Act is in force in stages between 2025 and 2027. Most SaaS companies should classify each AI system, build an obligation register, write a Fundamental Rights Impact Assessment for the high-risk ones, add Article 50 transparency notices where they apply, and ship an evidence vault before 2 August. GreyScape.ai gives you that working stack at $3/user/month.
What the EU AI Act actually regulates
The EU AI Act is Regulation (EU) 2024/1689. It is a horizontal regulation — it applies across every sector — and its scope is broader than most people realise.
It regulates AI systems (software with autonomy that processes inputs and generates outputs influencing the physical or virtual environment), AI models (the underlying ML models), and a special category of general-purpose AI models (the foundation models from OpenAI, Anthropic, Mistral and others, whether closed or open).
The Act applies to four roles in the AI supply chain:
- Providers — anyone who develops an AI system or places it on the EU market under their name.
- Deployers — anyone using an AI system in the EU under their authority (the equivalent of the GDPR concept of "controller").
- Importers — anyone bringing a non-EU AI system into the EU market.
- Distributors — anyone making an AI system available in the EU after the provider.
The most common surprise for SaaS founders outside Europe: the Act has extraterritorial reach. If the output of your AI system is used in the EU, you're caught — even if your company has no EU office, no EU employees, and no EU billing entity. The test is where the output goes, not where you sit.
If you operate a B2B SaaS with even a handful of EU customers, you are almost certainly a "provider" under the Act for the AI features in your product, and probably a "deployer" for any AI tools you use internally (ChatGPT, Cursor, image-gen, etc.) where the output affects EU employees or contractors.
The risk-tier framework — where you fit
The Act sorts AI systems into four risk tiers. The obligations attached to each tier are wildly different, so getting the classification right is the single most important step in your compliance programme.
Unacceptable risk (Article 5) — banned
Eight categories of AI use are flat-out banned in the EU regardless of context. The list includes social-scoring systems run by public authorities, real-time remote biometric identification in public spaces by law enforcement (with narrow exceptions), emotion recognition in workplaces and schools, and AI systems that exploit vulnerabilities of specific groups (children, the elderly, the disabled).
For most SaaS companies this tier is irrelevant — you're not building social-scoring systems. But check: any product feature that scores users on character traits, manipulates behaviour using subliminal techniques, or infers emotions from biometric data in an employment context is now legally prohibited inside the EU.
High-risk (Annex III) — 80% of the Act applies here
Annex III lists eight categories of AI system that are considered high-risk:
- Biometric identification and categorisation of natural persons
- Critical infrastructure management (transport, water, gas, electricity, digital infrastructure)
- Education and vocational training — AI used to determine access, evaluate learning, or monitor student behaviour
- Employment, workers' management, and access to self-employment — AI used in recruitment, candidate filtering, performance evaluation, task allocation, or termination decisions
- Access to essential private and public services and benefits — credit scoring, insurance pricing, emergency dispatch, public welfare evaluation
- Law enforcement — risk assessment, polygraph functionality, evidence reliability assessment
- Migration, asylum, and border control management — security risk evaluation, document verification, asylum processing
- Administration of justice and democratic processes — judicial decision support, electoral influence detection
If your SaaS does any of the following, you are likely operating a high-risk AI system: recruitment scoring (Workable, Greenhouse, Lever-style features), credit decisions (any fintech), insurance pricing, biometric authentication features used by EU users, employee performance scoring, AI proctoring for exams, or AI-driven moderation that affects access to essential services. Roughly 80% of the Act's substance applies to systems in this tier.
We unpack Annex III in detail in Annex III explained: which AI systems are high-risk under the EU AI Act.
Limited risk (Article 50) — transparency duties
Systems that interact directly with people, generate synthetic content, or perform emotion recognition or biometric categorisation (outside the high-risk list) sit in the limited-risk tier. They escape the heavy obligations but pick up transparency duties: users must know they are interacting with an AI, deepfakes must be labelled, synthetic media must be machine-readably marked.
This catches a lot of common SaaS surfaces — every chatbot, every AI-drafted email feature, every image-generation function, every voice-clone product. We cover the details in Article 50 transparency rules: what to disclose to your users.
Minimal risk — voluntary code
Spam filters, AI-enabled video games, inventory-management ML. No mandatory obligations under the Act — vendors are encouraged to adopt voluntary codes of conduct, but there is no legal requirement.
The nine obligations that hit most SaaS
If any of your AI systems land in Annex III (high-risk), nine obligations apply. The summary below is what you actually need to ship — not a restatement of the legal text.
Article 9 — Risk management system
You must run a documented risk management system across the lifecycle of each high-risk AI system. Identify foreseeable risks, evaluate them, mitigate the ones that can be mitigated, and document residual risks the deployer needs to know about. This is a continuous process, not a one-time document.
Article 10 — Data governance
Training, validation, and testing datasets must be relevant, representative, free of errors to the extent feasible, and complete. You must document the provenance of the data, the choices behind the labels, and the steps taken to detect and mitigate bias.
Article 11 — Technical documentation
A comprehensive technical document describing the AI system's purpose, architecture, training data, performance metrics, and known limitations. This is the artefact your notified body (and the market surveillance authority) will ask for.
Article 12 — Record-keeping
Automatic logging of events while the system is in use. The logs need to be tamper-evident — you can't just have a "logs" folder you could quietly edit. We ship this as a cryptographically chained audit log via Postgres SHA-256 triggers; rolling your own is doable but harder than it sounds.
Article 13 — Transparency and provision of information to deployers
Provide the deployer with instructions for use that describe the system's intended purpose, characteristics, performance, and limitations. The deployer needs enough information to use the system safely.
Article 14 — Human oversight
Design the system so humans can effectively supervise it — pause it, override it, correct its outputs. This includes UI affordances (the operator can see what the model is doing) and organisational measures (someone is actually watching).
Article 15 — Accuracy, robustness, and cybersecurity
The system must achieve appropriate levels of accuracy and robustness throughout its lifecycle, and be resilient against errors, faults, and attempts at unauthorised use (including adversarial examples and data poisoning).
Article 17 — Quality management system
A quality management system covering strategy for regulatory compliance, design and development procedures, examination and verification techniques, post-market monitoring, incident reporting, and record-keeping. For most SaaS this folds into your existing SDLC + SOC 2 controls — but it has to be documented as covering AI specifically.
Article 72 — Post-market monitoring
Continuous monitoring of the AI system in real-world use, including capture of incidents, near-misses, and drift. Must feed back into the risk management system.
Fundamental Rights Impact Assessment — when you need one
Article 27 introduces a new artefact: the Fundamental Rights Impact Assessment, or FRIA. Public-sector deployers of high-risk AI systems must complete one. Private-sector deployers must complete one when the system is used in employment, banking, insurance, essential public services, or law enforcement.
A FRIA must describe the intended purpose of the system, the categories of natural persons likely to be affected, the specific risks of harm to fundamental rights, the human oversight measures, and the steps to be taken if the risks materialise.
There is no required template in the legislation — but the European AI Office is expected to publish one. In the meantime, the FRIA template guide walks through what a defensible FRIA looks like, with a free template you can adapt.
Article 50 — the transparency duties you can't skip
Article 50 applies to limited-risk systems and adds three transparency duties:
- AI interaction disclosure. Anyone interacting with an AI system must be informed that they are interacting with AI, unless that is obvious from context. Translation: every chatbot, AI-powered support tool, AI tutor, or AI scheduling assistant needs disclosure.
- Synthetic content marking. AI-generated audio, image, video, or text must be machine-readably marked as artificial. This includes provenance metadata (typically C2PA) so downstream platforms can detect and label it.
- Deepfake and impersonation labels. Content that could plausibly be mistaken for a real person, event, or place must be visibly labelled as artificially generated or manipulated.
The detection logic to catch which of your AI systems trigger these duties is non-trivial. We ship Article 50 transparency triggers as a feature of the compliance register (category + keyword fallbacks for chat, image, voice, video, and deepfake). The Article 50 deep-dive walks through every trigger pattern.
Incident reporting under Article 73
Article 73 requires providers of high-risk AI systems to report serious incidents to the market surveillance authority of the affected member state. Serious incidents are defined in Article 3(49) and include:
- Death or serious harm to a person's health
- Serious and irreversible disruption of critical infrastructure
- Infringement of fundamental rights protected under EU law
- Serious harm to property or the environment
Reporting windows are tight: 15 days for most serious incidents, 2 days for incidents affecting critical infrastructure, 72 hours where there is widespread infringement of fundamental rights. The clock starts when you become aware of the incident — not when you confirm it.
Each member state designates a competent authority and a reporting portal. The Commission publishes a list. There is no central EU portal; you report to the affected member state's authority. We ship an incident workflow that captures the data structure and records when you confirmed the report was filed externally, since reporting is operator-driven.
A 90-day compliance plan you can actually execute
Here is the plan we'd run if we were starting from zero with 90 days to enforcement. Each phase has a concrete deliverable; nothing is theatre.
Days 1-15: Inventory and risk classification
Find every AI system in your product surface and your internal operations. This is the step everyone skips and pays for later. You probably have more AI than you think — that ChatGPT Plus your engineer is using is an AI system; the deepfake-detection model your moderation team licenses is an AI system; the recommender baked into your product is an AI system.
Classify each one against the four risk tiers. The hard part is Annex III mapping — high-risk vs limited-risk is a judgement call on edge cases (an AI assistant in HR that suggests interview questions vs an AI assistant in HR that scores candidates is the same product surface with very different risk classes).
By day 15 you should have a register listing every AI system, its role (provider or deployer), its risk class, and the responsible owner.
Days 16-45: Obligation mapping and evidence collection
For each high-risk system, walk the nine Annex III obligations and identify what evidence you have, what you need, and who's accountable. Start collecting the artefacts: data sheets, model cards, test logs, risk assessments, oversight design documents.
For each limited-risk system, identify which Article 50 disclosures apply and ship the UI text. This is fast — most SaaS already has a privacy notice or terms of service that can be amended.
By day 45 you should have, for every high-risk system, a populated obligation register with status and evidence.
Days 46-75: FRIA and Article 50
For each high-risk system that needs a FRIA (deployments in employment, banking, insurance, essential services, law enforcement), write one. Use the template linked above. A FRIA is typically 8-12 pages including appendices.
Audit every customer-facing AI interaction and confirm transparency disclosures are live. For synthetic content, ship the C2PA or comparable provenance metadata in your output pipeline.
By day 75 you should have a complete compliance picture — risk register, obligations, FRIA where required, Article 50 disclosures live.
Days 76-90: Audit pack and ongoing monitoring
Generate the audit pack — a single PDF or ZIP per high-risk system containing the register entry, the obligations, the evidence, the FRIA, the technical documentation reference, and the post-market monitoring plan. This is the artefact you hand to a market surveillance authority if asked.
Set up the post-market monitoring loop. Track incidents, near-misses, drift. Feed back into the risk register quarterly. Make sure incident reporting is wired (Article 73 — the timelines are unforgiving).
By day 90 you have a defensible position. Not a perfect one — nobody has that yet — but one where you can show a regulator the work, point at the controls, and explain the gaps with a plan to close them. That is what compliance looks like in practice.
FAQ
Does the EU AI Act apply if my company is outside the EU?
Yes, if the output of your AI system is used in the EU. The Act is extraterritorial in the same way GDPR is. You don't need an EU office, EU employees, or EU billing to be caught — you need EU users or EU output recipients.
What's the fine?
Up to €35 million or 7% of global annual turnover, whichever is higher, for prohibited-AI violations. Up to €15 million or 3% of turnover for other significant breaches. Up to €7.5 million or 1% of turnover for incorrect information supplied to authorities. Member states can apply higher fines under national law. These are global turnover caps — not EU turnover.
Is GDPR enough?
No. GDPR governs personal-data processing; the EU AI Act governs AI systems regardless of personal-data involvement. They overlap (a high-risk AI system processing personal data is governed by both), but the AI Act adds risk management, technical documentation, human oversight, post-market monitoring, and the FRIA. GDPR controls help, but they don't satisfy the AI Act.
Do I need a Data Protection Officer for AI?
The Act does not mandate a dedicated AI Officer role. Many organisations are designating one — either standalone or folded into the DPO function — to coordinate compliance across the Act's nine articles. We recommend the latter for mid-market: one person who owns AI compliance as a 20% slice of their existing role.
What about open-source models?
Open-source general-purpose AI models (foundation models released under permissive licences) get a partial carve-out from the GPAI obligations in Articles 53-55 unless they are placed on the market or used in a high-risk system. If you fine-tune an open-source model and ship it in a high-risk deployment, the AI Act applies — the licence of the base model doesn't change your obligations.
When are the deadlines?
The main enforcement dates are: 2 February 2025 — prohibited AI practices and AI literacy obligations come into effect. 2 August 2025 — governance rules and obligations for general-purpose AI models. 2 August 2026 — most other provisions, including the Annex III high-risk regime. 2 August 2027 — high-risk AI in regulated products (toys, medical devices, etc.) under harmonised legislation. The 2 August 2026 date is the one most SaaS companies need to ship for.
Is ChatGPT Enterprise compliant?
ChatGPT Enterprise as a tool can be used in compliant ways, but using it doesn't automatically make your deployment compliant. You are the deployer; your obligations include knowing what's running, who can use it, what data goes into it, and what oversight is in place. OpenAI provides documentation that helps you satisfy provider-side obligations on their end, but the deployer-side obligations are yours to satisfy.
What to do this week
If you read one section, read this one. The single most leveraged thing you can do this week:
- Inventory the AI in your company. Not a polished register — a list. Every model, every product feature, every tool an employee uses. Two hours with a spreadsheet beats two months of planning for the perfect register.
- Classify each one against Annex III. Most will land in minimal or limited risk. The ones that land in high-risk are where you spend your next 60 days.
- Identify your single owner for AI compliance. It can be the CISO, the DPO, the head of engineering, or you. It cannot be "the legal team in general."
That gets you on the field. Everything above is what plays out over the next 80 days.
The hard truth: 53 days isn't enough to build the compliance stack from scratch if you've not started. GreyScape.ai ships the working operational layer — register, obligations, evidence vault, FRIA template, Article 50 triggers, tamper-evident audit log, one-click audit pack — at $3/user/month, self-serve, with a 14-day refund. You can be live on your real data in 15 minutes and ship a defensible position by August. If that lines up with where you are, we should talk.