On 6 and 7 August, NASSCOM Future Forge 2026 convenes in Bengaluru under the theme "Charting India's DeepTech Architecture."
Day 1 focuses on Leadership and Strategy, framed around three unapologetically direct questions: who owns the stack, how research reaches the market, and what it takes to lead globally. Most industry agendas soften questions like these; this one does not, and that deserves an equally direct response. So instead of waiting for the panel, here is our answer to the first question written down in advance, this time with AI in the foreground rather than the background.
Ownership is no longer a build-versus-buy argument about infrastructure alone. It is a set of control points over your data and your AI systems. If you hold them, you own your stack. If you do not, you are renting it and calling it strategy.
🧱 What "owning the stack" does not mean in an AI era
Three popular definitions still circulate, and all three mislead even more once AI enters the picture.
Owning the code. Many organizations write everything themselves and proudly run their own AI models, yet still cannot say where their training data and model outputs physically reside, or which individuals at which vendors can read them. Source code and model weights are not the same as data control.
Owning the hardware. A rack in your building or a GPU cluster with your logo does not give you real control if the management plane, the identity provider and the support contract live somewhere else. An AI stack with opaque MLOps run by a third party is just dependency with extra parameters.
Avoiding hyperscalers. Refusing cloud does not create sovereignty. It usually creates a smaller, less audited, more fragile version of the same dependency, with AI workloads hacked into it at the edges.
Each of these confuses the location of an asset with control over it. The useful question is not where something runs; it is what you can prove, what you can monitor, and what you can revoke, especially for data-hungry AI systems.
🔐 The four control points that now decide AI stack ownership
This is the framework we use with clients, whether a workload is a core banking system in Frankfurt, an AI recruitment engine in Bengaluru, or a model running in a factory basement.
Data location and perimeter. Can you state, precisely, where every category of data lives (raw data, features, embeddings, model logs), which jurisdictions can compel access to it, and what prevents both external access and insider exfiltration? A data perimeter is a design artefact, not a PDF in a policy folder, and AI pipelines must respect it from collection through inference.
Revocability. Can you cut a vendor, a partner or an internal AI service off from your data today, cryptographically or through identity controls, without a six-week project? If the answer is no, you do not own that relationship; it owns you. Access, human or machine, should be purpose-bound, time-limited and revocable by design, including API keys, service principals and fine-grained prompts.
Operability. When something breaks at 02:00 (an identity outage, a misbehaving AI agent, a data pipeline stuck on yesterday's run), who fixes it, and do they work for you? Ownership without operating capability is just a diagram. This is where most AI stack-ownership claims quietly fail, because the knowledge left with a contractor two years ago or a startup that was acquired.
Exit. Could you move this workload, and its AI models, training data and monitoring stack, to a different provider or region, and have you tested it? An untested exit plan is a hope. A tested one is leverage, and it changes how every renewal negotiation goes, from GPU contracts to LLM licensing.
Four questions. Most organizations can answer one or two with confidence. The gap is the honest state of AI stack ownership in 2026, in India and in Europe alike.
🌍 Why India and Europe are asking this together
It is not a coincidence that India is debating who owns its technology stack in the same year Europe operationalised its answer for cloud and AI workloads. The AWS European Sovereign Cloud became generally available in January 2026, with its first region in Brandenburg, as an independent cloud with its own accounts, billing and identity management, operated entirely within the EU. Same APIs, same architecture, but a different control boundary and a sovereignty model targeted at regulated sectors.
The pattern worth noticing is that Europe did not solve sovereignty by rejecting global technology or banning AI services. It solved it by insisting on a control boundary within that global ecosystem. That is far more achievable than attempting digital self-sufficiency, and it is directly transferable to the Indian conversation, where national AI missions and deep-tech programme are now scaling.
Four recurring design patterns emerge: a defined data perimeter, tokenization of sensitive data before processing, governed access that is purpose-bound and auditable, and a kill switch for workloads and identities. None of these requires you to build your own cloud; all of them are prerequisites for running AI at scale in a way you can actually own.
🔬 The second question: how AI-driven research reaches the market
Future Forge's second question is, in our view, the harder one. India does not have an invention problem. It has a commercialization gap, and that gap is rarely scientific; it is architectural and operational, especially for AI-driven systems.
What we repeatedly see when research, often AI research, tries to become product:
The prototype was never built to be operated. It works on a lab cluster or a notebook, but nobody can run it in production without the original researcher in the room.
There is no compliance path. In healthcare, finance and life sciences, a technically excellent AI system with no audit trail, no model-risk story and no data-governance narrative cannot be sold, only demonstrated.
Nobody owns the unit economics. Cost per transaction or per inference was irrelevant in the lab and decisive in the market.
The first customer is enterprise, and enterprise procurement asks questions about ownership, exit, liability and AI governance that the research team has never had to answer.
Commercialization is mostly an operability and governance problem wearing a funding costume. That is exactly the work our Advisory, Cloud Foundations and AI services practices exist to do.
🌉 Our answer: the Indo-German AI delivery model
MeJuvante is not a neutral observer of these questions. We are one working answer to them, built as an Indo-German consulting and AI services group.
MeJuvante GmbH sits in Linden, Germany. MeJuvante Private Limited sits in Bengaluru. This is not an offshore arrangement with a sales office attached. It is a deliberate split of two capabilities that rarely live in one company.
From the German side: regulatory discipline, decades of banking, audit and compliance work, data-protection practice, and the habit of designing for an auditor who will ask awkward questions later, including AI governance and model-risk oversight.
From the Indian side: engineering depth and delivery capacity, close to the deep-tech and AI talent pool that Future Forge exists to mobilize.
The combination matters because ownership is exactly where those two capabilities meet. A control boundary that no team can operate is theatre. An operating team with no governance model cannot sell AI systems into a regulated market. You need both, in the same delivery model, from the first architecture decision.
Practically, that shows up as: cloud foundations and operations across AWS, Azure, Google Cloud and IBM Cloud through our Cloud-as-a-Service and SaaS-as-a-Service offerings; AI services and agents that run on top of that governed cloud; advisory on regulatory and compliance requirements; managed services with a named operating owner; and an Academy that trains the certifications this work actually requires, from IREB and ISTQB to PRINCE2, SAFe and Data Protection Officer.
🧭 What we would tell a CTO before Day 1
If you are coming to Bengaluru on 6 August, take four questions with you and ask them of your own organisation before you ask them of any panel:
Where does every category of our data sit, and who, human or machine, can compel or request access to it?
What can we revoke today, without a project: accounts, tokens, agents, API keys?
Who fixes this at 02:00, and do they work for us, especially when the incident involves an AI system making decisions at scale?
Have we ever tested moving this somewhere else (infra, data, models, and monitoring), and what broke when we tried?
You own your AI stack to the extent that you can answer those four. Everything else is procurement.
📅 Talk to us