Model Cards for Government Deployments

A joint secretary in a line ministry was handed a twelve-page 'model card' printed on the vendor's letterhead. The first heading was Responsible AI. The second was a stock photograph of a server cage. Intended use said public service excellence. Training data said a diverse global corpus. Limitations said may occasionally be inaccurate. The JS asked, in the margin, whether the model had been tested on scanned Hindi noting sheets from this ministry. Nobody in the room knew.

Margaret Mitchell and co-authors proposed model cards in 2018–19 as a reporting practice: intended use, evaluation data, metrics, ethical considerations, caveats. The paper is worth reading. It is not an Indian Gazette. It will not extinguish a DPDP complaint, a CAG para, or an RTI. It will, if you write it as a departmental document rather than as a brochure, stop a committee from putting a next-token predictor on a desk that decides money.

This is a template for DPOs and programme owners. Dated 16 August 2026. Not legal advice. Prcept AI will give you a card for what we actually run on your rack. We will not sign a poem.

Say the quiet sentence first: it is not a safe harbour

India has no statute that says a filed model card limits damages, satisfies DPDP, or pre-empts CAG. The Data Protection Board has existed since 13 November 2025; operational DPDP duties largely apply from 13 May 2027. Neither instrument names model cards. MeitY's India AI Governance Guidelines of 5 November 2025 talk about accountability and voluntary practice. Useful. Voluntary. Not a harbour.

Write the card anyway. Auditors and successor officers need a short document that is not the 80-page architecture PDF. The card is that document. Keep it next to the AI register row. Version it when the intended use or the weights change.

A departmental template that fits four folios

Fields a DPO can insist on. Delete any row you cannot fill; do not fill it with adjectives.

Field	Write this	Refuse this
Identity	Family, version hash, date loaded, vendor or internal owner	Our flagship LLM
Location	Named SDC cage / air-gap / on-prem rack; no outbound or named egress	India region
Intended use	Draft replies to scheme FAQs already in corpus X, for officers of rank Y	Transform citizen experience
Out of scope	No payments, no child cases, no medical diagnosis, no new scheme invention	Use responsibly
Data classes in	Public circulars; optionally ticket text class personal, never identity numbers	Customer content
Languages tested	The languages this desk actually serves, with date and set size	100+ languages
Known failures	Hallucinates clause numbers; weak on stamped vernacular; confused by tables	May be inaccurate
Human gate	Officer must accept in eOffice; agent cannot send	Human in the loop
Training on our data	Contractual and technical no, with the test you ran	We respect privacy
Eval pointers	Link to the last [bias and quality pack](/blog/bias-testing-on-indian-demographic-data), including failures	State-of-the-art scores

Sign the card as a departmental document. The vendor may supply facts. The DPO or the programme owner signs the intended-use and out-of-scope lines. A vendor-signed card that the department never adopted is a brochure in your file.

One card per intended use, not per brand

The same weights can be a circular-search assistant on Monday and an unofficial benefit-screener on Tuesday. The risk lives in the use. Clone the card when the use changes. Put the new card's identity on the AI register. If you will not clone the card, you are not authorised to clone the use.

Foundation-model vendors publish cards for the base model. Those are inputs. They do not know your retrieval corpus, your DFPR limits, or that your district still files in two scripts. Write the deployment card on top. Cite the base card. Do not paste it and change the logo.

Two cards a committee actually read

Objections

The vendor says the base card is enough. Answer: the base card does not name your corpus or your forbidden tools. Write the deployment card.

The scientist says cards are obsolete once you have eval dashboards. Answer: dashboards die with the tenant. A signed folio survives a transfer.

Legal says do not write known failures because it creates liability. Answer: hiding failures creates worse liability. Write them. Bind the refusals to them.

Leadership says one card for the whole ministry. Answer: then one intended use for the whole ministry. If that sentence is false, split the cards.

A four-week playbook

• Week 1: list live models and live uses. If the numbers differ, you already need more cards than you have.
• Week 2: fill the template for the highest-risk use. Leave blanks blank. Blanks are findings you can fix.
• Week 3: run one language and one failure test that the card claims. If the claim dies, edit the card, not the press note.
• Week 4: put card IDs on the AI register and in the CAG packet header. Train the PIO on what the card is not — it is not a case file.

File note you can paste

Subject: Departmental model cards — documentation, not a statutory harbour.

Each model family deployed by this department, for each intended use, shall have a card stating identity and hash, location, intended use, out-of-scope uses, data classes, languages tested, known failures, human gate, and whether departmental data is used for training. The card is an internal control artefact. It is not a legal safe harbour and does not reduce DPDP, RTI or audit duties.

Vendor brochures will be filed as annexures, not as cards. Cards will be signed by the programme owner and noted by the DPO. A change of intended use requires a new card and a register update. This note is not legal advice.

How a DPO reads a card in twelve minutes

Minute one to three: intended use and out of scope. If either is an adjective, return the card. Minute four to six: data classes and location. If location is a sales region, return the card. Minute seven to nine: languages tested and known failures. If failures are missing, return the card — not because the model is perfect, because the author is hiding. Minute ten to twelve: human gate and training ban. If either is a slogan, return the card.

Then ask one oral question the card cannot answer by paste: show me the last eval item this model failed, on a document type we actually see. If the owner cannot name a failure, they have not used the machine. A card without a remembered failure is fiction.

Keep superseded cards. Tuesday's rejection may have used last month's intended use. A card file that only holds the live version is a prompt store that only holds Friday's paste. Same sin, nicer typography.

If a university or lab wants a research card that says 'explore', keep that card off the citizen desk. Research intended use is a real use. It is not a licence to point the same weights at a hostel allocation on Thursday because the GPU was free.

• Refuse a card that lists twenty intended uses. That is a ministry, not a workflow.
• Refuse a card whose known-failures paragraph is shorter than its marketing paragraph.
• Pin the card ID on the Board folio when a new money-class or identity-class use is proposed.

Informational field guidance. Model cards are a reporting practice, not an Indian statutory filing, unless a later instrument says otherwise. Check the live Gazette.

How this survives CAG, RTI or the Board

“Model Cards for Government Deployments” 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.

A model card will not save you in court. It will stop a committee from deploying a chat model as a benefit-decider without writing down intended use, data classes, languages, and the failures you already know about. 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 “model card government AI” 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 “Model Cards for Government Deployments” 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. “model card government AI” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.