The EU AI Act for public bodies: what suppliers in India should prepare by December 2027

01The position in autumn 2026

Regulation (EU) 2024/1689, the EU AI Act (opens external site), has been in force since 1 August 2024 and takes effect in phases. In July 2026 the Union adopted the Digital Omnibus on AI, Regulation (EU) 2026/1744 (opens external site), which pushed back the high-risk obligations and amended several other provisions. The amending regulation took effect on 27 July 2026, just ahead of the date on which the high-risk rules would originally have applied.

So some obligations bind European public bodies already, some arrive at the end of 2026, and the heaviest deployer duties begin in December 2027. For an Indian company that builds or supplies AI for European administrations, those are also the dates by which its customers will ask for documentation.

The Omnibus also changed the wording of Article 4. The earlier text asked providers and deployers to ensure that their staff had a sufficient level of AI literacy; the amended text asks them to take measures that support it. A duty remains, but what an organisation has to evidence is different. Training matched to each role, with attendance on record, is still the sensible way to show it.

02How the Act reaches a provider in India

Being located outside the Union does not take a provider out of scope. The Act covers providers placing AI systems on the EU market or putting them into service there “irrespective of whether those providers are established or located within the Union or in a third country” (Article 2(1)(a)). It also covers providers and deployers in a third country “where the output produced by the AI system is used in the Union” (Article 2(1)(c)). An Indian IT services company that builds a case-assessment system for a European municipality, or an Indian product company whose eligibility scores are used by a European agency, falls within these provisions.

For high-risk systems there is a further step. A provider established in a third country must appoint an authorised representative established in the Union before it makes the system available on the Union market (Article 22(1)). The public body that deploys the system will also expect the provider to supply what its own duties depend on: instructions for use, technical documentation, access to logs and help with the fundamental rights impact assessment described below.

03Provider or deployer: settle the roles in the contract

Most public bodies are deployers, meaning they operate an AI system under their own authority. The provider is whoever develops a system, or commissions its development, and then markets it or puts it into service under its own name or trademark. When a contractor, Indian or European, builds a system to a public body’s own specification and the body runs it under its name, the public body itself can be the provider.

Roles can shift over a system’s life. Article 25 turns a deployer into a provider for legal purposes when it substantially modifies a high-risk system, or changes the purpose of a system so that it falls into the high-risk category. Suppliers in India should ask for the intended roles to be written into the tender documents and the contract, so that neither side learns of them during an audit.

04Which public-sector uses count as high-risk

Annex III lists the domains where an AI system counts as high-risk. For public bodies, these are the domains that matter most:

• Essential public services and benefits: deciding who is eligible, and awarding, cutting, withdrawing or recovering benefits and services.
• Policing, border management, migration and asylum, and courts and the administration of justice.
• Education and vocational training: who is admitted, how learning is assessed, and how candidates are watched during an examination.
• Work and the management of staff: hiring, promotion, task allocation and monitoring; a public body is an employer too.
• Critical infrastructure: AI acting as a safety component for digital infrastructure, road traffic, or water, gas, heating and electricity supply.

Sitting in an Annex III domain is a starting point, not a verdict. Under Article 6(3), such a system is not high-risk if it creates no significant risk of harm: when its task is narrow and procedural, when it only improves work a person has already finished, when it spots patterns in past decisions without taking over the human assessment, or when it only prepares an assessment. Profiling of natural persons keeps a system high-risk in every case. Put the reasoning on file whenever you rely on Article 6(3).

Many valuable tools never enter the high-risk regime: help with drafting, search across internal policy documents, translation, summaries. They remain subject to the transparency rules and the GDPR.

05Duties of a public deployer of a high-risk system

From 2 December 2027, a public body deploying an Annex III high-risk system carries the obligations in Article 26 (opens external site). The principal ones follow; each also tells a supplier what its customer will need from it.

• Run the system in the way the provider’s instructions for use describe, with technical and organisational measures to match.
• Give the oversight role to staff who are competent, trained and empowered to intervene, and back them up.
• Where the deployer controls the input data, make sure it suits the intended purpose and represents the relevant population well enough.
• Watch how the system performs, and alert the provider and the authorities promptly to risks and serious incidents.
• Keep the logs the system generates automatically for no less than six months, or longer where another Union or national rule demands it.
• Tell workers’ representatives and the employees concerned before a high-risk system is introduced at work.
• As a public authority, enter the use of the system in the EU database before putting it to use (Article 26(8) and Article 49); an unregistered system may not be used at all.
• Let people know when a high-risk system takes, or supports, a decision concerning them (Article 26(11)); Article 86 also gives them a right to an explanation of an individual decision.

The fundamental rights impact assessment

Article 27 (opens external site) obliges bodies governed by public law, and private entities that provide public services, to assess fundamental rights impacts before they first use most Annex III systems; critical infrastructure systems are the exception. The assessment records:

1. 01the deployer’s own processes into which the system will be built, consistent with its intended purpose;
2. 02for how long, and how frequently, it will run;
3. 03who is likely to be affected, by category of person and group;
4. 04the specific harms those people could suffer;
5. 05the way human oversight works in practice;
6. 06what the body will do if the harms occur, including governance arrangements and routes for complaints.

The result is notified to the market surveillance authority. Because it overlaps with a data protection impact assessment under Article 35 of the GDPR, the sensible course is to run the two as one exercise. Article 27(5) tasks the AI Office with a template questionnaire, so see whether it has been published before you build your own. Some Member States already have methods, for instance the Impact Assessment Mensenrechten en Algoritmes (IAMA) of the Dutch government.

For a supplier the practical point is simple: the deployer cannot complete this assessment without the provider’s material on intended purpose, known limitations, accuracy and oversight measures. An Indian provider that prepares that material once, in a form public bodies can reuse, removes a common cause of delay in European procurement.

06Transparency duties already in force

Since 2 August 2026, Article 50 has applied. On the provider side, a system that interacts with people must be designed to tell them they are dealing with AI, unless that is obvious from the context, and synthetic output must carry a machine-readable mark. On the deployer side, deepfakes must be labelled, and so must AI-generated or manipulated text published to inform the public on matters of public interest, unless a person has reviewed it and someone carries editorial responsibility.

In a public body this usually means a chat assistant on a citizen portal or a helpline. Say clearly that it is AI, describe its limits, and give people a route to a human.

07India’s approach, for comparison

India has chosen guidance over legislation for now. The India AI Governance Guidelines, released by the Ministry of Electronics and Information Technology (MeitY) in November 2025, set out seven principles and six pillars with an action plan; they are not binding, and India has no AI statute. The IndiaAI Mission, approved by the Union Cabinet in March 2024, includes a Safe and Trusted AI pillar, under which the IndiaAI Safety Institute operates.

An Indian provider therefore meets two different regimes with one product: binding, dated obligations for its European public-sector customers, and voluntary guidance at home, next to binding Indian laws such as the Digital Personal Data Protection Act, 2023 for personal data. Documentation prepared for the EU duties can often be reused when an Indian customer asks how a system reflects the Guidelines, but each regime should be checked on its own terms.

08A plan for 2026 and 2027, for deployers and their suppliers

1. 01Start the inventory now. Capture every AI system in use or being procured, AI features in licensed platforms included, with its owner, purpose, provider, data sources and affected groups.
2. 02Classify by early 2027. Place each system in one category: prohibited, high-risk (keeping the Article 6(3) analysis), transparency obligations only, or minimal risk, and note whether you are its provider or deployer.
3. 03Rework contracts during 2027. Ask for instructions for use, conformity documentation, log access and, where the provider is outside the EU, the name of its authorised representative. Write support for the impact assessment and for incident reporting into the contract.
4. 04Design the oversight. Appoint overseers, train them, give them the power to override and an escalation route, and guard against automation bias; our article on human approval for AI agents sets out the method.
5. 05Put logging and monitoring in place. Six months of log retention as a minimum, a definition of a serious incident and a named person who reports it.
6. 06Before go-live. Complete the fundamental rights impact assessment together with the DPIA, register in the EU database, and inform staff and the people affected.
7. 07Keep training going. Role-based sessions for users, reviewers and decision-makers, refreshed when a system changes, with attendance recorded.

09Fines and enforcement for public bodies

Penalty rules are a national matter. Article 99(8) lets each Member State decide whether administrative fines can be imposed on public authorities and bodies established there, and to what extent. Waiting is still unwise: market surveillance authorities can require corrective action, and a public decision that nobody can explain or challenge loses legitimacy.

10Developments to follow

• Commission guidelines on classifying high-risk systems (Article 6(5)), alongside its published guidelines on prohibited AI practices (opens external site).
• Harmonised standards for the high-risk requirements, which providers will rely on to show conformity.
• Which market surveillance authorities each Member State designates, and the first guidance they issue to public deployers.
• The AI Office template for the fundamental rights impact assessment.
• On the Indian side, further guidance from MeitY under the India AI Governance Guidelines.

The European Commission’s AI Act Service Desk (opens external site) maintains the official timeline and explanations per article. Keep it at hand and date every internal note on the Act, because the text is still changing.