EU AI Act Explained: What It Means for Your Business
The first question a founder in Bengaluru asked me about the EU AI Act was not about clauses or fines. It was: we do not have an office in Europe, we never signed anything with Brussels, so why should any of this touch us? Fair question. The uncomfortable answer is that the law does not follow your office address. It follows your output.
If a system you built lands on a screen in Frankfurt, Paris or Amsterdam, or its result is used by someone in the European Union, you are inside the perimeter. That single fact catches thousands of Indian SaaS firms, GCCs (global capability centres) and AI startups who assumed this was a European problem. It is not. It is a supply-chain problem, and you are the supply chain.
What the EU AI Act actually is (in one honest paragraph)
The EU AI Act is Regulation (EU) 2024/1689, the first horizontal law in the world that governs artificial intelligence by risk, not by industry. It came into force on 1 August 2024. It does not ask what your model is; it asks what your model does and to whom. A chatbot that suggests recipes and a model that scores loan applications are treated very differently, even if the underlying transformer is identical. The Act sorts every AI system into a risk tier and attaches obligations to that tier. That is the whole mental model. Get the tier right and everything else follows.
The four risk tiers, and where you probably sit
Most teams over-estimate their obligations because they hear artificial intelligence and assume the strictest rules apply. Wrong. The Act is deliberately proportionate. Here is the taxonomy, from the top down.
| Risk tier | What it covers | What you must do |
|---|---|---|
| Unacceptable risk (banned) | Social scoring by public authorities, manipulative subliminal techniques, untargeted facial-image scraping to build databases, real-time remote biometric identification in public (narrow exceptions), emotion recognition at work or school | Do not build, sell or deploy it. Prohibited outright since 2 February 2025. |
| High risk | AI in recruitment and worker management, credit scoring, insurance pricing, biometric identification, critical infrastructure, medical devices, education admissions, law enforcement, migration | Full compliance regime: risk management, data governance, technical documentation, logging, human oversight, accuracy and cybersecurity, conformity assessment, EU database registration. |
| Limited risk (transparency) | Chatbots, emotion or biometric categorisation, and generative or manipulated content (deepfakes) | Tell people they are dealing with AI. Label AI-generated or manipulated content in a machine-readable way. |
| Minimal risk | Spam filters, AI in video games, inventory optimisation, most everyday software features | No mandatory obligations. Voluntary codes of conduct encouraged. |
The one that sinks people is high risk. Not because the definition is vague, but because teams do not realise a mundane-looking feature qualifies. If your HR product ranks or filters CVs, that is high risk. If your fintech scores creditworthiness, that is high risk. If your platform sets insurance premiums using a model, high risk. The label does not care that you call it a helpful sorting feature.
General-purpose AI: a separate track
If you train or provide a foundation model, a general-purpose AI (GPAI) model such as an LLM, you sit in a dedicated regime that runs alongside the tiers. You owe technical documentation, a summary of training data, copyright-compliance measures, and for models posing systemic risk (roughly, trained above 10 to the 25 floating-point operations) additional model evaluations, adversarial testing and incident reporting. Most Indian companies are downstream deployers of GPAI, not providers of it. But if you fine-tune and redistribute, check whether you have inherited provider obligations. That reclassification catches people.
Provider or deployer: your role decides your paperwork
The Act assigns duties by role, and one company can wear several hats. Confuse them and you will either over-comply and burn budget, or under-comply and carry a liability you did not price in.
| Role | Who it is | Core duty |
|---|---|---|
| Provider | You develop the AI system or GPAI model, or have it developed, and place it on the market under your name | Heaviest obligations: build the compliance in, run conformity assessment, register, monitor post-market |
| Deployer | You use an AI system under your authority in the course of business | Use it as instructed, keep logs, ensure human oversight, run a fundamental-rights impact assessment where required |
| Importer / Distributor | You bring an AI system into the EU market or make it available | Verify the provider did the conformity work; do not ship non-compliant systems |
Watch the reclassification trap. If you buy a high-risk system and substantially modify it, or put your own brand on it, or repurpose it for a high-risk use the original vendor did not intend, you become the provider. Now the full high-risk regime is yours, not the vendor s. Indian GCCs that white-label and adapt third-party models for European parent companies routinely fall into this without noticing.
Who it applies to (yes, including you in India)
The extraterritorial reach is the part that surprises Indian boards. The Act binds you if any of the following is true.
- You place an AI system or GPAI model on the EU market, regardless of where you are established.
- You are a provider or deployer established outside the EU, but the output produced by the system is used in the EU.
- You are established in the EU (obvious case).
- You import, distribute, or act as an authorised representative for an EU-facing system.
Read the second bullet again. Output used in the EU. A Pune-based analytics firm that never touches European infrastructure, but whose model scores candidates for a client s German hiring pipeline, is squarely in scope. Providers outside the EU offering high-risk systems must appoint an authorised representative inside the Union, in writing, before the system goes to market. That is a real cost line and a real accountability anchor, not a formality.
The timeline: what is already live and what is coming
The Act does not switch on all at once. It phases in, and some of the hardest parts are furthest out, which is exactly why teams procrastinate and then panic. Here are the dates that matter.
| Date | What becomes binding |
|---|---|
| 1 August 2024 | Regulation entered into force; the clock starts |
| 2 February 2025 | Prohibited practices banned; AI-literacy duty on providers and deployers begins |
| 2 August 2025 | GPAI model obligations apply; governance bodies and national authorities stand up; penalty provisions live |
| 2 August 2026 | The bulk of obligations apply, including high-risk systems listed in Annex III (recruitment, credit, biometrics and so on) |
| 2 August 2027 | High-risk obligations for AI embedded in regulated products under Annex I (medical devices, machinery) apply |
The practical read: prohibited uses and AI literacy are already the law. GPAI duties are already the law. If you build recruitment, credit or biometric AI touching the EU, August 2026 is your hard wall, and a credible high-risk conformity programme takes nine to fifteen months to stand up honestly. Do the arithmetic. You are not early.
The penalties that make a CFO sit up
The fines were written to be felt by large firms, and they are tiered by how serious the breach is. They are calculated on worldwide annual turnover, not EU turnover, which changes the risk math for any global business.
| Breach | Maximum fine |
|---|---|
| Using a prohibited AI practice | Up to 35 million euro or 7 percent of global annual turnover, whichever is higher |
| Breaching high-risk, transparency or GPAI obligations | Up to 15 million euro or 3 percent of global annual turnover |
| Supplying incorrect, incomplete or misleading information to authorities | Up to 7.5 million euro or 1 percent of global annual turnover |
For small and medium enterprises and startups the caps apply as the lower of the two figures, a deliberate concession. But do not relax on the strength of that. The reputational and contractual damage arrives faster than any regulator. Your European enterprise customers will make AI Act compliance a procurement gate in their vendor questionnaires long before a fine ever lands. That is where most Indian firms will first feel this: not in a courtroom, in a security review.
What actually happens: a scene from the vendor review
A mid-sized Indian SaaS company, resume-screening product, closes a deal with a German logistics group. Six weeks in, the customer s procurement team sends a forty-page AI due-diligence questionnaire. It asks for the technical documentation set under Article 11, the data-governance evidence under Article 10, the log-retention design under Article 12, the human-oversight mechanism under Article 14, and the CE-marking conformity declaration.
The Indian team has none of it. Not because the product is bad, but because nobody classified the system as high risk when they built it. The deal freezes. Now they are reverse-engineering a compliance programme against a live contract clock, paying consultants premium rates, and explaining to their own board why a signed deal is stuck. I have watched this exact sequence three times. The fix in every case was the same, and it was cheap if done early and expensive if done late: classify first, then build the evidence trail as you go.
The core high-risk obligations, in plain terms
If you land in the high-risk tier, these are the pillars. None of them is optional, and each maps to an Article you will be asked to evidence.
- Risk management system (Article 9): a continuous, documented process across the lifecycle, not a one-time PDF.
- Data and data governance (Article 10): training, validation and test data that is relevant, representative and examined for bias.
- Technical documentation (Article 11): the full Annex IV dossier, kept current, that lets an assessor understand how the system works.
- Record-keeping and logging (Article 12): automatic logs so events are traceable after the fact.
- Transparency and instructions for use (Article 13): deployers must be told how to use the system correctly and what its limits are.
- Human oversight (Article 14): a real human able to understand, intervene and override, not a rubber-stamp.
- Accuracy, robustness and cybersecurity (Article 15): the system resists error, adversarial manipulation and data poisoning.
Notice how much of Article 15 is straight security engineering. Adversarial robustness, resistance to data poisoning, model integrity, secure logging. This is where an AI compliance programme and a security programme stop being separate projects. If your ISO 27001 controls and your DPDP (Digital Personal Data Protection Act, 2023) data-handling are already mature, you are not starting from zero. You are extending a spine you already have.
How this sits alongside Indian obligations
You are not compliant with the EU AI Act just because you follow Indian law, and you are not exempt from Indian law by following the EU AI Act. They overlap, they do not substitute. India s DPDP Act governs personal data. CERT-In directions govern incident reporting and log retention (180 days). Sector regulators (RBI, SEBI, IRDAI) impose their own model-risk and outsourcing rules. The smart move is to build one control set that satisfies the strictest requirement across all of them, then map that set to each framework. Duplicating programmes is how compliance budgets quietly triple.
| Control area | EU AI Act hook | Indian equivalent to reuse |
|---|---|---|
| Data governance and bias | Article 10 | DPDP purpose-limitation and data-minimisation duties |
| Logging and traceability | Article 12 | CERT-In 180-day log retention direction |
| Security and robustness | Article 15 | ISO 27001 controls; sectoral RBI or SEBI cyber norms |
| Human oversight and accountability | Article 14 | Board-level governance under sectoral regulators |
Your AI Act-ready checklist
Skip the theatre. This is the sequence that actually moves you from exposed to defensible, in order.
- Build an AI inventory: every system, its purpose, whether output touches the EU, and your role (provider or deployer) for each.
- Classify each system into a risk tier and write down the reasoning, so you can defend it later.
- Kill or redesign anything sitting in the prohibited tier immediately; that is already illegal in the EU.
- For high-risk systems, gap-assess against Articles 9 to 15 and produce a remediation plan with owners and dates.
- Stand up the Annex IV technical documentation as a living dossier, not a launch-day artefact.
- Implement automatic logging with retention that satisfies both Article 12 and CERT-In s 180 days.
- Design genuine human oversight into the workflow, with a named role able to override.
- Add AI-generated content labelling and chatbot disclosure wherever the transparency tier applies.
- Deliver the AI-literacy training the Act already requires of your staff; keep the attendance records.
- Appoint an EU authorised representative if you are a non-EU provider of a high-risk or GPAI system.
- Fold all of the above into your existing ISO 27001 and DPDP programme rather than running a parallel one.
The honest closing
Come back to that founder s question. The law does not follow your office, it follows your output. Which means the deciding factor is not where you are, it is what your model does and where its results land. Treat the EU AI Act as a border you cannot see and you will keep tripping over it in vendor reviews and stalled deals. Treat it as a design constraint you build for once, and it becomes a competitive edge every time a European buyer opens their questionnaire and you already have the answers.
At CyberSigma we do this work hands-on as senior CERT-In empanelled auditors and PCI QSAs, sitting in the same room as your engineers, classifying real systems and building evidence trails that hold up under a German procurement team s scrutiny, not just on paper. If that is the conversation you need to have, we are happy to have it plainly.
FAQs
We are an Indian company with no EU office. Does the EU AI Act really apply to us?
Yes, if you place an AI system on the EU market or if the output of your system is used in the EU. The Act is deliberately extraterritorial. A model built in India whose results are used by a European client is in scope, office or no office.
How do I know if my AI system is high risk?
Check the use, not the technology. High-risk uses include recruitment and worker management, credit scoring, insurance pricing, biometric identification, critical infrastructure, medical devices and education admissions, listed in Annex III and Annex I. If your system does one of these and touches the EU, treat it as high risk until proven otherwise.
What is the difference between a provider and a deployer, and why does it matter?
A provider develops the system and places it on the market under its name; a deployer uses it in business. Providers carry the heaviest obligations. Crucially, if you substantially modify a system or rebrand it, you can become the provider and inherit those duties, so the distinction is not academic.
When do the high-risk obligations actually bite?
The bulk, including Annex III high-risk systems such as recruitment and credit, apply from 2 August 2026. AI embedded in regulated products under Annex I follows on 2 August 2027. Prohibited practices and GPAI duties are already live. A credible high-risk programme takes nine to fifteen months, so 2026 is closer than it looks.
Does complying with India s DPDP Act mean we are covered for the EU AI Act?
No. They overlap on data governance but do not substitute for each other. DPDP governs personal data; the AI Act governs AI systems by risk and adds duties around documentation, human oversight, robustness and conformity. Build one control set that satisfies the strictest of both and map it to each.
What is the cheapest way to get started?
An AI inventory and a risk-tier classification. Both are largely internal effort and cost little, yet they tell you exactly where your real exposure is. Almost every expensive mistake we see comes from skipping classification and discovering a high-risk system mid-deal instead of before build.
Liked the post? Share on:
Leave A Comment