Field Note from India: Nobody Asked What Your AI Can Do. They Asked Whether It Can Be Certified.

I went to India with the Team Canada Trade Mission expecting to talk about capability. Instead, in almost every meeting, the question was whether the system could be audited, certified and kept under the buyer's control. In the sectors where AI touches the physical world, accuracy and assurance are the product. The model is a component.

I was in Mumbai. My team was in Bengaluru. Between us we sat with business leaders, government officials, and people working in agriculture, aerospace and space research. AI came up in every one of those rooms, usually within the first ten minutes, whether or not it was on the agenda.

What did not come up was almost everything the AI industry spends its marketing budget on.

The surprise: nobody cared about the model

I walked in ready for the usual questions. Which model? How many parameters? Which GPUs, and how many? What does it score on the benchmarks?

Not one person in my meetings asked.

What they asked instead was harder and better. How accurate is it on our data, in our conditions? Can we see why it produced this answer? Can we show it to a certification authority and have it hold up? Can it run on infrastructure we control?

And in the aerospace conversations, one question kept coming back in a form I did not expect to hear in a trade mission meeting room: can this align with DO-254?

These buyers are not shopping for intelligence. They are shopping for something they can sign for.

Why the physical sectors think this way

It is easy to read this as conservatism. I think it is what experience looks like.

Any agriculture ministry that issues crop advisories to millions of farmers cannot treat "mostly right" as a finished product. A wrong recommendation on pest treatment or sowing windows does not produce a bad dashboard. It produces a bad harvest, and the farmer who bears the cost had no say in which model was used.

An aerospace engineer has spent a career inside a discipline where every piece of airborne software and hardware is traced to a requirement, verified against it, and frozen in a configuration that does not change without a formal process. To that person, "the model got better last week" is not good news. It is an uncontrolled change.

A space research team cannot send a technician. Whatever runs on the spacecraft has to behave predictably for years.

In all three settings, the consequences of a wrong answer are physical, and often irreversible. That changes what "good AI" means. Capability is necessary. It is nowhere near sufficient.

What DO-254 is really asking

For readers outside aviation: DO-254 is the design assurance guidance for airborne electronic hardware, and DO-178C is its counterpart for airborne software. Regulators such as the FAA and EASA accept them as a means of showing that the hardware and software in a system were developed with the rigour its safety level demands.

The DO-254 question makes sense once you remember that an onboard model does not run in the cloud. It runs as inference on an FPGA, an ASIC or a multicore processor inside a box on the aircraft, and that hardware falls squarely under DO-254 and the guidance built on it. The model and its software wrapper fall under DO-178C. Neither standard was written with machine learning in mind.

Both assume you can write down what the system is supposed to do, trace every element of the design back to that requirement, test against the requirements, and then analyse the coverage closely enough to show that nothing in the implementation is doing something no requirement asked for.

A trained model does not work that way. Its behaviour comes from data rather than from specified requirements, and you cannot trace an individual weight back to a line in a specification.

That is why the regulators are still building the path. EASA has published two issues of its AI Concept Paper, the second in March 2024, and put a third out for consultation in June 2026. The FAA published the first version of its Roadmap for Artificial Intelligence Safety Assurance in 2024. The joint EUROCAE and SAE process standard for AI in aeronautical products has been through open consultation but, as of this writing, is not yet published. And as of this writing, no machine learning component has been certified for a safety critical function in civil aviation. The first candidates are still working through the process.

So when a buyer asks "can this align with DO-254," they are rarely asking for a certificate tomorrow. They are asking whether your approach was built with assurance in mind from the start. I will come back to the specific questions at the end, because they turned out to be the same questions every sector asked.

Sovereign AI is about control, not location

The second theme ran through the government conversations. Almost everyone I met treated sovereign AI as the direction of travel. Fewer agreed on what it means.

The common reading is data residency. Keep the servers in the country and you are sovereign. That is a start, but it is not the whole point.

A model hosted in a local data centre, on a stack you cannot inspect, under terms of service set elsewhere, is local. It is not sovereign. Sovereignty, as I came to understand it in those rooms, is wider than residency. It includes compute, and it includes whether the model works in the country's own languages. But on the question of trusting a specific system, it came down to four questions:

1. Who can change it? If someone else can update the model without your approval, you do not control its behaviour, and you do not own the state it accumulates.
2. Who can inspect it? If you cannot examine the weights and the evaluation results, you cannot audit it.
3. Who can switch it off, or keep it on? If access depends on a licence, an export rule or a commercial relationship you do not control, your critical services depend on it too.
4. Whose rules apply in a dispute? If the answer is a jurisdiction you have no say in, the system is not yours, whatever server it runs on.

These are the aerospace engineers' questions in different words: you cannot trust what you cannot control, and you cannot control what you cannot see.

Open source is becoming the moat, with a catch

I have argued on this site that the model is not a moat. Open weights made capable models a commodity, and the lasting advantage sits in your data and your governance. I still think that is true for an enterprise using AI.

What I heard in India adds a second half. For a company selling AI into regulated, sovereign or safety critical markets, openness is becoming the price of entry, and the evidence built around an open model is becoming the moat.

The reason is mechanical. Certification needs a frozen baseline. A closed model behind an API can be pinned to a dated version, but only until the provider retires it, and the published notice periods run from a couple of months to about a year. That is shorter than the life of any certified system. An open model can be pinned to an exact version, inspected, tested as thoroughly as the assurance level requires, run inside the buyer's own walls, and kept unchanged for as long as the certification requires.

I argued in August that open weights are a decoy, because holding the file no longer means holding the capability at scale. These buyers are not trying to serve a million people. They are trying to run one frozen system on hardware they own, which is the one case where holding the file is the whole point.

Openness has a limit. Open weights give a regulator the artifact, but rarely the training data, so lineage still has to be evidenced by the vendor.

So the model is still a commodity, and being open will soon be one too. What is not a commodity is the assurance evidence built around an open artifact: the frozen configuration, the test record on the buyer's data, the documented limits. That takes years to accumulate, and nobody can download it.

Policy is being written everywhere, right now

The third thing I heard, from almost every official I met, is that policy is in motion. Ministries, regulators and sector bodies are drafting how AI may be used in their domain: what has to be disclosed, what has to be tested, what cannot be automated at all.

The rules for AI in agriculture, aviation, space and public services will be set sector by sector over the next few years. The organizations that show up with auditable systems will help shape those rules. The ones that show up with demos will have the rules written around them.

Space research is the sleeper

The role of AI in space research is going to be enormous, and the conversations in India reinforced that. Satellites generate far more data than can be sent to the ground, so deciding on board what matters is becoming essential. Earth observation already feeds agriculture, water management and disaster response.

Every one of those uses inherits the same requirements, in a harsher form. Every upload to a spacecraft is a formal, reviewed event, so the model you launch is the model you live with for a long time. And when it discards an image on board, the only record of why is whatever you decided in advance to log and send down. Space will force the industry to answer the assurance questions properly, and the answers will flow back to every other physical sector.

What this means for Canada and India

From what I heard on both sides, each country wants AI it can trust, run on its own terms and govern under its own laws, and neither is comfortable depending on a single foreign stack for critical services.

Canada brings research depth, experience building systems that have to meet demanding standards, and a regulatory culture that buyers in these sectors recognise. India brings scale, engineering talent, speed of deployment, policy that is moving faster than most Western governments, and some of the largest real world settings for AI anywhere, from agriculture to public digital infrastructure. The fit is obvious once you have sat in the rooms.

I want to thank the Trade Commissioner Service team for the preparation and introductions that made those conversations possible.

The Certification Test

If you are building or buying AI for a sector where mistakes are physical, run these five questions before anyone sees a demo. They are the questions I heard in India, in the order they tend to come up.

1. Can we freeze it? Can you pin the exact model version, configuration and supporting software, and prove later that nothing has changed? If the answer depends on a provider's retirement schedule, the answer is no.
2. Can we trace it? Can you show where the training and evaluation data came from, who touched it, and what it does and does not cover? An assurance case without data lineage is a story, not evidence, and most open weights do not come with one.
3. Can we measure it on our ground? Do you have accuracy numbers on the buyer's own data and operating conditions, including the hard cases? Benchmark scores answer a question nobody in these rooms was asking.
4. Can we contain it? Is there a deterministic layer around the model that checks its outputs against known limits before anything acts on them? In physical systems, the model proposes and the controls decide, which is the same doctrine SAP planted a flag on for finance. That works where the limit can be written down. For perception, where the model is the only thing that saw the input, the containment has to come from testing and from a human or a second sensor in the loop, and buyers in these sectors know it.
5. Can we run it ourselves? Can it run on infrastructure the buyer controls, under their jurisdiction, without depending on a connection or a licence someone else can withdraw? If not, it is not sovereign, whatever it says on the slide.

If you can answer all five, you can have the conversation these buyers actually want to have. If you cannot, more capability will not save the deal.

Where this lands

I went to India expecting to hear about ambition, and there was plenty of it. What I did not expect was how practical it had become. The leaders I met are past being impressed by what AI can do. They want to know whether they can trust it, prove it and keep it.

That is good news for the buyers. The next phase of AI in the physical world will not be won by the biggest model. It will be won by the system someone is willing to sign for.

Shubhendu Tripathi is an AI and ERP strategy consultant based in Toronto, and the host of The Integration Layer, a podcast on AI, enterprise systems, and the work of making them fit together. Connect on LinkedIn or reach out at tripathis@qubittron.com.