If you are deciding whether Bharat should follow an American, European or Chinese approach to artificial intelligence, begin one step earlier. Ask who will control the data, computing capacity, model updates, safety tests and remedies when an AI system affects someone in Bharat. A foreign rulebook can offer useful standards, but it cannot answer those questions on Bharat’s behalf.
A sovereign framework should let Bharat cooperate internationally without surrendering domestic accountability. It should also turn Dharmic ideas about truth, restraint, duty, plurality and human dignity into obligations that a ministry, court, company, university or citizen can actually enforce.
Key takeaways
- AI sovereignty is control over consequential decisions, not a demand that every model, chip or dataset originate inside Bharat.
- Bharat should classify AI by its use and possible consequences. A writing assistant and a system influencing medical care, policing or public benefits should not face the same obligations.
- Dharmic values become meaningful in governance only when translated into audit trails, truthful disclosure, human appeal, proportionality and duties assigned to named people.
- Cultural and community data need terms for model training and synthetic reuse, not merely permission to digitise or display the original material.
- Public procurement can create immediate leverage through audit, portability, update control, data-use and service-continuity clauses.
- Bharat should align internationally through compatible technical standards while retaining its own red lines for rights, strategic systems, cultural data and domestic redress.
Sovereignty begins with control, not slogans
Digital isolation is neither necessary nor sufficient for sovereignty. A system hosted in Bharat can still depend on a foreign vendor for weights, updates, security fixes and evaluation. Conversely, an imported component can serve a sovereign system if Bharat retains contractual control, technical visibility, operational continuity and legal jurisdiction over its domestic use.
Test five control points
For every consequential AI deployment, the responsible authority should be able to answer five questions in writing:
- Data: Who collected the training and operational data? Under what permission can it be reused, transferred, retained or used to improve another model?
- Compute: Where can the system run, and what happens if access to foreign chips, cloud capacity, accounts or technical support is interrupted?
- Model: Who can inspect its documented limitations, change its behaviour, withdraw a version or verify which version produced a disputed output?
- Deployment: Which Indian entity decides how the output is used, and which named officer remains responsible when a human follows an automated recommendation?
- Standards and remedy: Who defines acceptable performance, investigates incidents and provides a practical route to correction, appeal or compensation?
If an authority cannot answer one of these questions, it has found a dependency. The proper response is not automatically to reject the technology. It is to classify the dependency, measure the consequence of failure and create an alternative before the system becomes indispensable.
This test also exposes token localisation. Keeping a copy of data inside Bharat does little if the provider can reuse that data abroad, alter the model without notice or make an essential public service unusable by closing an account. Sovereignty must cover decision rights and continuity, not just server location.
Translate Dharmic values into duties
A Dharmic orientation should not mean programming one religious doctrine into state systems. Hindu, Buddhist, Jain and Sikh traditions are not interchangeable, and a plural republic should not pretend otherwise. Their moral vocabularies can nevertheless sharpen the questions that a purely commercial framework tends to neglect.
- Ahimsa becomes prevention and proportionality. A deployer must identify foreseeable harm, use the least intrusive method adequate to the purpose and stop a system when the remaining risk outweighs its benefit.
- Satya becomes truthful representation. People must know when they are dealing with an automated system, what role its output plays, what evidence supports a consequential result and where uncertainty remains.
- Dharma becomes assigned duty. Responsibility cannot disappear into a chain of developer, vendor, integrator and public official. Each party needs a defined obligation, while one Indian entity remains answerable to the affected person.
- Anekantavada becomes contestability. No statistical output should be treated as a complete view of a person. High-consequence decisions need room for contrary evidence, contextual explanation and review by someone authorised to change the result.
- Seva and lokasangraha become public purpose. Public adoption should be judged by whether it improves a real service without making the citizen less visible, less autonomous or less able to seek redress.
These duties are measurable. An audit can check whether an appeal channel works, whether a risk assessment preceded deployment, whether a person was told that automation was involved and whether the operator can reconstruct the version and data path behind a disputed decision. Ethical language without such tests is ceremonial.
Regulate the use, the data and the full lifecycle
Model size alone is a poor proxy for social risk. The same general-purpose model may be used to polish a private note or to recommend which citizen receives an essential service. Bharat therefore needs obligations tied primarily to intended use, affected rights, scale, reversibility and the operator’s ability to detect and correct failure.
Use a consequence-based risk ladder
| Proposed tier | Typical uses | Minimum governance response |
|---|---|---|
| Routine | Spelling assistance, formatting, low-consequence internal brainstorming and similar optional tools | Basic security, data-use disclosure, user control and a clear way to report failure |
| Elevated | Systems that guide students, screen applicants, moderate access to a platform or help people navigate public services | Documented purpose, impact assessment, representative evaluation, human review, usable notice and an appeal route |
| Critical | Systems materially influencing medical care, policing, liberty, essential benefits, critical infrastructure, military functions or large-scale biometric identification | Pre-deployment authorisation, independent testing, continuous monitoring, version control, incident reporting, named executive accountability and a tested non-AI fallback |
| Prohibited | Uses whose design requires an unacceptable violation of dignity, lawful process or political freedom | A narrow statutory ban with penalties and no sandbox exemption |
The boundaries should depend on function, not marketing labels. Calling a system advisory does not make it low-risk if officials routinely accept its recommendation. Regulators and courts should examine how people actually use the output, whether refusal is realistic and whether a human reviewer has the information and authority needed to disagree.
Prohibitions should also be specific. Candidates include indiscriminate state scoring of an entire population, covert state automation designed to manipulate political choice, and fully automated deprivation of liberty without meaningful human adjudication. Vague bans on harmful AI invite selective enforcement; narrow definitions make red lines legible to both citizens and builders.
Treat cultural data as governed inheritance
Ordinary consent forms are not enough for digitised scriptures, temple archives, manuscript collections, sacred images, recorded chants and community oral histories. Permission to preserve or display an item does not automatically establish permission to train a commercial model, generate imitations or strip the material of attribution.
Before transferring a cultural collection, its custodian should record separate decisions for five activities: preservation, public access, research, model training and commercial synthetic reuse. The agreement should identify who may grant each permission, what attribution must accompany an output, whether sensitive material is excluded and how permission can be withdrawn for future training runs.
That structure protects both access and stewardship. A blanket ban can prevent scholarship and language preservation; unrestricted extraction can turn a living inheritance into unaccountable training material. Purpose-specific permission gives institutions a more precise choice.
Every elevated or critical system should also carry a concise data record containing:
- the origin and collection purpose of each important dataset;
- the legal or institutional basis for its use;
- the languages, scripts, regions and communities represented or missing;
- known restrictions, contested labels and material quality limitations;
- retention, deletion and cross-border transfer terms; and
- whether inputs and user interactions may be used for later model training.
A single accuracy score cannot establish fitness for Bharat. Evaluation should be separated by the language, script, dialect, domain and affected group relevant to the deployment. Strong performance in English or Hindi does not answer whether the system works for a person using another Bharatiya language, mixed-language speech or a regional administrative vocabulary.
Place gates across the lifecycle
Governance that begins at launch begins too late. A practical approval path should place a decision gate at each stage:
- Before development or purchase: define the problem, consider a non-AI option, classify the proposed use and name the accountable Indian entity.
- Before collecting or licensing data: document provenance, permissions, exclusions, cultural conditions, retention and cross-border movement.
- Before deployment: evaluate ordinary performance, local-language performance, foreseeable misuse, security, discrimination, human-review quality and failure recovery.
- At the point of use: disclose automation, state what the output will influence, identify the responsible operator and provide the route to correction or appeal.
- After deployment: monitor real outcomes, preserve versioned logs, investigate incidents, reassess after major updates and retain the power to suspend or recall the system.
Major updates need renewed scrutiny when they change capability, data practice or decision logic. Otherwise an approved system can become a materially different one while retaining an outdated seal of approval. The deployer should maintain a change register and specify in advance which changes trigger fresh testing or authorisation.
Build domestic capacity while keeping diplomatic room
Bharat does not need technological autarky. It does need enough domestic capability, supplier diversity and contractual leverage to refuse unsafe terms. That means treating compute, models, evaluation, talent, public datasets and standards participation as connected parts of sovereignty.
Use procurement as an immediate sovereignty tool
Public buyers do not have to wait for a complete AI statute to set defensible conditions. Before issuing a tender for an elevated or critical system, they can require bidders to answer the five control-point questions and accept clauses covering:
- ownership and permitted reuse of prompts, records, feedback and other operational data;
- the countries and subcontractors through which protected data may pass;
- advance notice, testing and rejection rights for material model updates;
- access to documentation, relevant logs and independent evaluation;
- export of data and records in a usable format when the contract ends;
- deletion verification for copies that the provider is no longer entitled to hold;
- continuity arrangements if the service, account, supplier or cross-border connection becomes unavailable; and
- cooperation with Indian investigations, courts and authorised regulators.
These terms must be settled before dependency forms. Once a public workflow, staff training and citizen access channel all rely on one provider, portability becomes more expensive and negotiating power weakens. A buyer should test the exit plan during procurement, not discover it during a dispute.
Open-weight and closed systems should both face consequence-based review. Open weights can support domestic adaptation, inspection and continuity, but can also make some capabilities easier to redistribute. Closed services may allow a provider to monitor abuse centrally, but they can conceal internals and concentrate update power. Neither licence model is a substitute for testing the actual deployment.
Negotiate abroad from a written domestic position
The geopolitical choice is no longer hypothetical. On 16 July 2026, twenty-nine countries signed a founding agreement for the World Artificial Intelligence Cooperation Organization, an intergovernmental body headquartered in Shanghai. Russia, Pakistan, Indonesia, Brazil, South Africa, Malaysia and other Asian, African and Latin American states were among the signatories. Four of the five founding members of BRICS signed; India did not.
India’s absence preserves room to choose, but absence is not a strategy. If Bharat does not state its own principles, foreign blocs will still shape the technical vocabulary, compliance expectations and diplomatic bargains confronting Indian companies and institutions.
The strongest course is interoperable sovereignty: write domestic non-negotiables, then cooperate on technical elements that do not displace them. Bharat can recognise compatible testing methods, documentation formats and incident categories without accepting that a foreign institution has final authority over an Indian citizen’s rights or an Indian strategic system.
Before joining any international arrangement, negotiators should divide its provisions into three columns:
- Domestic red lines: Indian jurisdiction over local high-risk uses; effective constitutional redress; audit authority; control over strategic deployments and their updates; and explicit conditions for training on Indian personal, public or cultural data.
- Interoperable commitments: common documentation fields, shared incident terminology, benchmark methods, researcher cooperation, security coordination and reciprocal recognition where protections are genuinely comparable.
- Strategic dependencies: provisions affecting compute access, cloud continuity, model updates, technical standards or cross-border data flows that could give another state or supplier coercive leverage.
This separation prevents two common mistakes. One is rejecting useful cooperation merely because it originated abroad. The other is accepting a broad governance package because several technical clauses appear sensible. Each commitment should be judged by what authority it transfers, what dependency it creates and how Bharat can exit.
Move from framework to decisions you can test
Assign institutions by function
Bharat does not need one enormous body to make every AI decision. It needs a clear allocation of functions. Parliament should establish rights, prohibited uses, liability principles and investigatory powers. A technically capable authority should maintain risk-classification criteria, testing requirements and a registry for critical deployments. Sector regulators should apply those rules to medicine, finance, education, communications, infrastructure and other specialised fields. Courts must remain available for enforceable remedy.
Public procurement should supply the common contractual baseline, while independent evaluators perform technically demanding tests. Civil society, language specialists, disability advocates and representatives of affected communities should have defined routes to challenge evaluation methods and report harms. Participation should occur before deployment standards harden, not only after a failure.
A regulatory sandbox may relax a procedural requirement so that a limited experiment can be observed. It should not waive basic data security, truthful disclosure, human safety or the right to complain. Every sandbox entry needs a bounded purpose, limited users, a named supervisor, an end condition and rules for deleting or transferring data when the experiment closes.
Use the framework in your own role
If you build an AI product, prepare a one-page sovereignty statement before seeking deployment. Name the use tier, accountable entity, important datasets, model and compute dependencies, affected languages, human-review process, update policy, appeal channel and shutdown method. Missing answers show where product work remains.
If you buy AI for a public institution, school, university, business or Dharmic organisation, do not begin with a generic demonstration. Give the vendor a realistic failure case and ask who can reconstruct, correct and remedy it. Then test data export and service continuity before signing. A polished output does not establish governability.
If you steward manuscripts, recordings, sacred images or community archives, inventory existing permissions before allowing bulk access. Make digitisation, public display, research, training and synthetic reuse separate choices. If the collection lacks clear custodial authority, resolve that question before transfer; a contract cannot supply legitimacy that the institution itself has not established.
If you are a citizen, researcher or civil-society advocate, ask four questions whenever an AI system is proposed for a consequential public function: What decision will it influence? What evidence proves fitness for the people and languages affected? Who can reverse a wrong result? What happens when the vendor, model or connection fails? Those questions reveal more than a broad promise of innovation or responsible AI.
Bharat’s next AI agreement, procurement or public deployment should be judged against a simple standard: does it preserve the country’s capacity to know, decide, correct and continue? If any one of those powers sits beyond Indian reach, identify the dependency and build the remedy before scaling the system.




References


Leave a Reply
You must be logged in to post a comment.