Chaitali Bag
India is entering a new phase of military modernization in which unmanned systems will do more than follow pre-programmed routes or respond to remote commands. They will increasingly sense, classify, prioritise, coordinate and recommend action. The central question is therefore not only whether India can acquire capable autonomous platforms. It is a question of whether the Indian Armed Forces will retain complete control over the software, data, simulation environment, and decision logic that determine how those platforms behave in war.
This issue deserves urgent attention because autonomy is often presented as a platform capability. In reality, it is an ecosystem capability. The aircraft, drone, vehicle or robotic system is only one component. The more consequential elements may remain hidden inside the simulator, mission-management software, artificial-intelligence model, data architecture and decision layer.
India has already demonstrated its interest in autonomous military technologies. In January 2021, the Indian Army publicly demonstrated a swarm of 75 indigenously designed and developed drones conducting simulated missions using artificial intelligence and autonomous coordination. The demonstration reflected the Army’s wider interest in robotics, cloud computing, algorithmic warfare and autonomous systems.
A clear principle must guide the next stage of this development: India should not outsource the mind of its autonomous force.
Autonomy is more than the platform.
A modern autonomous system normally consists of several connected layers. The first is the physical platform, including the airframe, propulsion, sensors, communications equipment and onboard computer. The second is the control and mission layer, which translates operational objectives into tasks. The third is the autonomy layer, which supports navigation, perception, target recognition, formation management, re-tasking and responses to changing conditions.
Above these sits the decision-support or decision-management layer. This layer may combine information from several platforms, assign priorities, manage a swarm, recommend courses of action and support commanders during a rapidly changing engagement. It may also determine what the system does when communications are interrupted, navigation signals are degraded, a platform is lost, or the battlefield differs from the training environment.
This layer is not a minor software accessory. It represents a portion of military judgment translated into code.
A foreign supplier may provide a highly effective autonomous system. Its simulator may be sophisticated, its user interface may be attractive and its demonstration may show impressive performance. However, the critical question is: who owns and controls the logic that converts sensor inputs into mission recommendations or autonomous actions?
If the answer is an overseas entity, India may be purchasing not merely equipment, but a foreign-defined operational philosophy.
What does sovereignty mean in software?
In defence technology, sovereignty does not simply mean that a drone, computer or ground station is manufactured in India. It means that India retains the authority to understand, govern, modify, validate, operate, suspend and replace the software that influences military decisions.
For an autonomous system, sovereignty must be examined at the decision layer. This is the software architecture that receives information from sensors and external networks, assesses the situation, assigns priorities, recommends actions and, within authorised limits, directs the behaviour of one or more platforms.
In practical terms, sovereign software means that Indian institutions—not an overseas vendor—control the answers to six questions:
- What may the system decide?
- How does the system decide?
- Which data does it trust?
- Who can change the software or model?
- Who can stop or override it?
- Can India verify what happened?
The mission boundaries, permitted tasks, prohibited actions and conditions requiring human approval must be defined by Indian authorities. The rules, thresholds, confidence levels, fallback logic and task-allocation mechanisms must be inspectable, testable and approved through an Indian process.
The training data, operational data, maps, threat libraries and sensor information must remain under Indian control and reflect Indian geography, doctrine and threat conditions. India must also control software updates, model replacement and configuration changes. A foreign supplier should not be able to alter mission behaviour through an opaque update or even a transparent OTA patch.
Authorised Indian commanders must be able to interrupt, constrain, re-task, or terminate the system, including during a communication loss, a cyberattack, a navigation failure, or unexpected behaviour. The system must record what data it received, which model version it used, what rules it applied, what recommendation it generated and what human decision followed.
This can be expressed in a simple definition:
Software sovereignty in autonomous defence systems is the assured ability of the Indian state and its authorised military institutions to control, inspect, validate, modify, update, override, audit and, when necessary, replace the code, data, models and decision rules that influence or direct military action.
This definition is broader than data sovereignty. Keeping data inside India is important, but data localisation alone does not create sovereign autonomy. If the data is stored domestically while a foreign supplier controls the model, simulator, decision rules and software updates, India may still lack meaningful control over the system’s behaviour. Sovereign AI is generally associated with maintaining control over technology, infrastructure, data and operational rules so that systems reflect national requirements and legal conditions.
Simulation can create dependency.
Simulation is indispensable for training autonomous systems. It allows developers and operators to test thousands of scenarios without risking personnel or equipment. It supports mission rehearsal, operator training, swarm coordination, sensor fusion and evaluation under degraded conditions.
However, a simulator can also become a gateway through which a foreign supplier defines the system’s behaviour.
The training environment determines what the system considers normal, abnormal, threatening, or permissible. The datasets influence how objects are classified. The scenarios determine which responses are rewarded. The scoring system defines what is considered mission success. The software architecture determines which parameters can be changed by the Indian user and which remain inaccessible.
A system that performs well inside a foreign-designed simulator may not necessarily perform reliably in India’s operational environment. India’s geography, weather, electromagnetic conditions, communication constraints, adversary tactics, and rules of engagement may differ significantly from those in the original training ecosystem.
There is also a danger of simulation lock-in. Once operators, instructors and acquisition authorities become dependent on a particular simulation framework, replacing it becomes expensive and disruptive. Over time, the simulator begins to shape doctrine, tactics and procurement decisions. The training tool quietly becomes an operational authority.
India must therefore distinguish between a simulator that supports Indian-controlled autonomy and a simulator that trains Indian personnel to operate within a foreign-controlled autonomy framework.
The decision layer is the strategic asset.
A platform can be replaced. A decision architecture is much more difficult to replace once it has been integrated into doctrine, training, communications and command structures.
The decision layer determines how information is fused and how priorities are established. It can influence whether a system continues a mission, returns to base, searches for an alternative target, transfers responsibility to another platform or requests human intervention.
Even when a system is described as “human-in-the-loop”, the human may be presented with only a limited set of recommendations generated by software. The commander may retain formal authority, but the speed and complexity of the engagement may make the machine’s recommendation the practical default.
This creates a distinction between legal control and meaningful control. Legal control means that an authorised human remains responsible for the decision. Meaningful control means that the human understands the recommendation, can challenge it, modify its parameters, and stop the system in time.
A foreign-controlled decision layer could create several strategic vulnerabilities:
- India may not have full visibility of the model, rules, thresholds or priority logic.
- Software updates could alter system behaviour without an independent Indian revalidation process.
- Foreign technical personnel may remain necessary for configuration, troubleshooting or mission changes.
- Operational data could be exposed during maintenance, training, cloud synchronisation or software support.
- The system may contain assumptions about geography, escalation, target behaviour or acceptable risk that do not reflect Indian doctrine.
- In a crisis, external political, legal or commercial pressures could affect the availability of support, updates or critical components.
These risks do not require a deliberate backdoor. Dependence itself can become the vulnerability.
Why procurement language matters
Concerns have emerged regarding the language and conceptual structure of a recent Indian military request for information on autonomous and AI-enabled capabilities. Some observers have noted that portions of the wording appear closely aligned with concepts used in foreign autonomous-system playbooks.
Similarity in language alone is not proof of misconduct, improper influence or a predetermined procurement outcome. Defence requirements often draw upon common technical vocabulary, international research and established concepts. Nevertheless, unusually specific wording should prompt an independent examination of how the requirement was generated.
Was the requirement developed from an Indian operational problem, or was it adapted from a foreign product architecture? Did Indian users define the mission and then seek technology, or did an existing technology model shape the requirement? Were alternative indigenous architectures considered? Can the proposed system operate with Indian simulators, datasets, command networks, and rules of engagement?
These questions are important when an RFI appears to prescribe not only the required operational effect but also a particular technical method for achieving it. A military requirement should ideally state the mission outcome and allow multiple technical solutions to compete. If its language unintentionally mirrors one supplier’s architecture, the procurement process may favour a pre-existing ecosystem before a genuine competition has begun.
This is not an argument against foreign technology. It is an argument against allowing foreign technology to define the requirement.
What India should demand
India should adopt a sovereignty-by-design approach for autonomous military systems. This does not mean rejecting all foreign collaboration. It means ensuring that collaboration does not transfer control of mission logic, data or operational authority.
Every future acquisition involving autonomy should address the following requirements:
- Full access to system architecture, interfaces, data formats and software documentation.
- Indian ownership or sovereign control of mission data, training data and operational logs.
- The ability to operate in an air-gapped, GPS-denied and communications-degraded environment.
- Independent Indian control over software updates, configuration and cybersecurity certification.
- Government-controlled simulators capable of reproducing Indian terrain, weather, communications and threat conditions.
- Transparent testing of deception, spoofing, platform loss, cyberattack and communication failure.
- Integration across platforms supplied by different Indian and foreign vendors.
- Clearly defined human-authority mechanisms for mission approval, abort, escalation and termination.
- Source-code access or an equivalent escrow and verification mechanism for mission-critical functions.
- Independent red-team testing by Indian military, academic and industrial institutions.
- A transition plan that allows the Services to sustain, modify and upgrade the system without permanent foreign dependence.
The decision layer should function as a sovereign interface between foreign or domestic components and Indian military authority. A foreign sensor may identify an object. A foreign algorithm may generate a classification. A foreign platform may provide navigation or flight-control functions. But an Indian-controlled orchestration layer should determine how those outputs are combined, what confidence level is required, when a human must intervene and which actions are permitted.
That layer should also provide model and software version control, Indian-defined mission constraints, confidence gates, independent logging, post-mission audit, rapid rollback and the ability to operate without a foreign cloud, remote server or external network.
From acquisition to strategic autonomy
The Indian Army’s current interest in artificial intelligence includes sensor fusion, decision support, wargaming, surveillance and operational planning. Recent reporting has described efforts to accelerate AI adoption across these areas by 2026–27. This makes the sovereignty debate even more important because AI will increasingly influence decisions beyond individual platforms.
India must avoid treating autonomy as a procurement category limited to drones. The same issue will arise in air defence, electronic warfare, intelligence fusion, logistics, combat vehicles, maritime systems and battlefield management.
The country should build sovereign test ranges, classified datasets, common simulation standards and indigenous evaluation frameworks. Indian universities, start-ups, established defence manufacturers, the Services and government laboratories should jointly develop reference architectures that allow different platforms to operate under an Indian-controlled command framework.
The decisive capability in future conflict may not be the number of autonomous platforms a military possesses. It may be the ability to update their behaviour rapidly, securely and independently as the battlefield changes.
India should welcome international cooperation, technology transfer and selective imports. But no foreign supplier should become the permanent owner of the cognitive layer of Indian military operations.
The machine may be foreign-built. The sensor may be imported. The processor may come from an international supply chain. Yet the mission logic, data, authority and final decision architecture must remain Indian, not a foreign-controlled Indian guise.
That is the difference between acquiring autonomous systems and possessing sovereign autonomy.
