Risk Classification for Departmental AI Use

The steering committee of a state transport department spent forty minutes arguing whether their licence-renewal chatbot was 'high-risk' under 'the new MeitY AI Act'. There is no such Act. Someone had pasted an EU blog into the noting sheet. The chatbot could not issue a licence. It could retrieve a FAQ. It could also, if a helpful intern wired the payment API, collect a fee. Those are different objects. The committee had no language except an imported adjective.

India can write a risk law later. Until it does, you still need a scheme, because an unscoped agent will wander from circulars into money. Build the scheme as a departmental instrument. Say on the face of it that it is yours, not MeitY's. Bind refusals, escalation, logging and human gates to the class. Then put the class on the AI register.

This is a framework for DPOs and programme owners. 16 August 2026. Not legal advice. MeitY's 5 November 2025 guidelines are worth reading; they are not a classification statute.

Do not fake the mandate

The EU AI Act is a European instrument. It is not in force as Indian law. Copying its annexes into a state circular without saying you are borrowing a foreign scheme will confuse the next officer and irritate the next auditor. If you want to borrow ideas — extra care for biometrics, for credit, for access to benefits — say 'we chose this because of our function', not 'MeitY requires high-risk treatment'.

The India AI Governance Guidelines released on 5 November 2025 describe principles, institutional ideas and a preference for enabling innovation. They ask sectoral bodies to think. They do not hand you a mandatory four-colour grid. Honesty here is a control. Fiction here is a future para.

Four classes that fit a department

A departmental scheme. Adopt it, adapt it, date it. Do not pretend it is a Gazette.

Class	What sits here	Minimum controls
Internal	Circular search, noting drafts, meeting summaries on non-personal files	Register row, card, action log, no unofficial public models
Citizen-facing	Any output a resident can see or that drafts their case	Plus reconstructable packet, RTI pack, grievance path, language tests
Identity	Aadhaar, biometrics, credentials, KYC, eligibility identity matching	Plus refusal unless a named statute and a named officer; extra retention lock
Money	Sanctions, bills, refunds, scholarships as payment, procurement recommendations that become POs	Plus DFPR-competent human; agent cannot spend; dual control on tools

A scholarship agent that only drafts an FAQ is citizen-facing. The moment it can recommend a rupee figure into a bill, it is also money. Take the stricter column. Do not average.

Children's data is not a fifth marketing class. It is a hard refusal plus, if a statute forces a workflow, the identity-class locks and a shorter purpose. Write that as a rule, not as a colour.

How class changes the machine, not only the memo

If class is only a spreadsheet colour, it will be ignored on the Saturday an intern wires a tool. Put class into the runtime. Money-class workflows cannot register a payment tool. Identity-class workflows cannot retrieve a biometric template unless the standing order names the section. Citizen-facing workflows cannot go live without a grievance URL on the card. Internal workflows still cannot paste into a public model.

Review class when the use changes, not once a year as a ritual. The card companion piece said clone the card when the use clones. Clone the class at the same moment.

Two classifications

Objections

Counsel says we should wait for MeitY. Answer: CAG, RTI and angry citizens will not wait. Write a departmental scheme and a sunset to revisit when a statute arrives.

A vendor offers an 'EU-aligned high-risk module' as a SKU. Answer: buy controls (refusal, logs, gates). Do not buy a foreign legal costume.

A unit says their copilot is only internal so class does not apply. Answer: internal is a class. It still cannot see identity numbers or spend.

Leadership wants five more classes for optics. Answer: every extra class is a meeting. Four will do until you have a real statute.

A four-week playbook

• Week 1: issue a one-page scheme that says it is departmental, not a MeitY mandate. Define the four classes.
• Week 2: classify every register row. Record dual classes. Apply the stricter column.
• Week 3: bind one technical control per class (tool allow-list, packet, language test, DFPR gate).
• Week 4: tabletop a class upgrade (FAQ bot asked to collect fees). Confirm the runtime refuses until a new row exists.

File note you can paste

Subject: Departmental risk classification for software agents — internal scheme.

India has not, as of this note, enacted a mandatory AI-system risk statute on the pattern of the EU AI Act. MeitY's 5 November 2025 guidelines are not such a statute. This department therefore adopts its own classes — internal, citizen-facing, identity, money — for the sole purpose of rationing controls. A workflow takes the strictest class it touches.

These classes will be written on the AI register and enforced in the runtime (tool allow-lists and human gates). They will be revisited if a competent legislature or MeitY issues a binding instrument. This note is not legal advice and shall not be cited as a Government of India classification.

Scoring a new row without a two-day workshop

Ask four yes/no questions in order. Can a resident see the output or is their case drafted? Can money move or be announced? Can identity, biometric or credential data be read or written? If all three are no, it is internal. Stop. If any is yes, take that class, or the combination, and apply the strictest column. You do not need a consultant to average colours.

Dual class is normal. A pension SMS is citizen-facing and money. A hostel allocation that matches identity documents is citizen-facing and identity. Write both. Controls add; they do not dilute. The Board folio should show the count of dual-class rows, because that is where Saturday accidents live.

Sector overlays sit on top, not instead. A payments system still has RBI storage expectations. A hospital still has its ethics and health-data rules. Your four classes do not repeal those. They ration departmental attention so those overlays have a hook.

When a statute finally arrives — if it arrives — map it once. Do not maintain two grids forever. Until then, date your scheme, name the owner, and refuse to let a vendor restamp your rows as 'EU high-risk' in a quarterly QBR. Their taxonomy is their problem. Your file is yours.

• A pilot inherits the class of the intended production use, not a courtesy 'internal' because only twenty officers can see it.
• A model swap does not change class. A tool add might. Re-score when the allow-list grows.
• If you cannot name a control that the class uniquely requires, you do not need that class.

Informational field guidance. Do not invent a MeitY risk law. Confirm live Gazette notifications before you describe any scheme as mandatory.

How this survives CAG, RTI or the Board

“Risk Classification for Departmental AI Use” is not a workshop slide. A P6 Compliance/DPO will have to reconstruct a decision after the officer who clicked approve has been transferred. Write the artefact that lets a stranger replay the case: the log fields, the approval, the override, the register row.

Do not stamp 'high-risk' on a file as if MeitY had issued EU Annex III. Write a departmental scheme you can defend: citizen-facing, money, identity, internal. Then bind controls to the class, not to the adjective. India AI Governance Guidelines (November 2025) are guidelines, not a statute. DPDP still allocates fiduciary duty. Delegation of Financial Powers still allocates who may spend. Do not hide those instruments behind the word governance.

If you cannot show who acted, on which purpose, with which data class, and who could have refused, you do not have accountability. You have a chatbot with a charter PDF.

• Name the owner of “AI risk classification government” inside the department, not the vendor.
• Keep CERT-In-relevant logs in India for the required period.
• Store overrides with a reason an auditor can read.
• Put the workflow on the AI register before it touches a citizen.

Close this loop before the next CAB

Put “Risk Classification for Departmental AI Use” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P6 Compliance/DPO, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “AI risk classification government” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.