Digital Public Infrastructure and Its Limits
DPI can shape AI adoption. It cannot supply the compute, energy, institutional judgment, or industrial depth AI requires.
Two Claims About India’s AI Future
At the 2026 India AI Impact Summit, the government launched the Global AI Impact Commons, a voluntary initiative for sharing, replicating, and scaling AI use cases across countries. The launch drew on a tempting idea from India’s digital public infrastructure success: perhaps AI, too, can be governed through public rails. If shared digital infrastructure helped identity, payments, documents, and data flows operate at population scale, perhaps a similar public architecture could help AI diffuse more widely.
The frontier-capability argument begins from a different concern. AI capability does not depend only on applications or use cases. It depends on frontier models, compute clusters, and advanced chips. It also depends on data centers, energy systems, cloud capacity, and global developer ecosystems. Unless India builds deeper technological capability, it will remain dependent on external infrastructure while celebrating application-layer adoption.
The DPI argument and the frontier-capability argument are both partly right.
The DPI argument sees something real: India has demonstrated a distinctive institutional capability. Aadhaar made identity machine-verifiable. UPI made payments interoperable. DigiLocker, account aggregators, and related data-exchange systems extended the same logic into documents and consent-based flows. These systems created rails that reduce transaction costs, expand participation, and let other actors build services on top.
The frontier-capability argument also sees something real: AI is not only a coordination problem. It is also an industrial, infrastructural, and operational problem. Some bottlenecks sit in compute, chips, energy, and model ecosystems. Others sit in the institutional capacity to evaluate AI-mediated decisions.
The mistake is to make either claim total. DPI is not a template that can simply be copied into AI. But DPI is not irrelevant because it does not solve the hardest infrastructure bottlenecks. It is a specific kind of statecraft: infrastructure as a steering instrument. That makes DPI powerful, and it defines its limits.
What DPI Actually Solved
Digital public infrastructure is now a global policy term. The World Bank describes DPI as foundational digital systems such as identity, payments, and secure data exchange that support digital services across the public and private sectors.
The term is newer than the problem it names. Information-infrastructure scholars have long studied how shared technical systems become background conditions for social and economic life. Susan Leigh Star and Karen Ruhleder’s canonical work on the ecology of infrastructure is one older anchor for this way of thinking: infrastructure is not just equipment, but a relational system that works only when it is embedded in practices, users, standards, maintenance, and organizational routines. DPI is a newer policy name for a related institutional problem.
India made this problem visible at a scale few countries had attempted. Aadhaar created a digital identity layer. UPI created interoperable instant payments. In May 2026 alone, UPI processed 23.2 billion transactions. Other systems built around document exchange, consent, and service delivery extended the logic. Their strategic significance lies in the kind of problem they solved: coordination.
Before UPI, digital payments were fragmented across banks, wallets, cards, and settlement systems. UPI created a common protocol that let different banks and payment apps interoperate above that fragmentation.
The BIS study of India’s digital financial infrastructure is useful because it does not treat this as only a payments story. It frames India’s approach as digital financial infrastructure provided as a public good: identity, payments, and data-sharing architecture layered so that innovation can happen above shared rails. The achievement was not just a popular app or a transaction volume milestone. It was a design architecture that changed who could connect, transact, verify, and build.
DPI’s coordination logic explains why it became attractive in development circles. If identity, payments, and data exchange become interoperable, then other services can be layered on top: welfare payments, financial inclusion, health and education credentials, agricultural support, and private innovation. The IMF’s working paper on India’s digital journey makes this argument in developmental terms: India Stack supported inclusion, competition, market expansion, and public-expenditure efficiency by providing foundational digital infrastructure. The mechanism is institutional coordination through digital rails. DPI worked because the binding constraint was coordination, not silicon.
India did not need to own frontier semiconductor fabrication to scale UPI. It did not need globally dominant cloud companies to make QR-code payments interoperable. The deeper layers needed for digital coordination, including mobile devices, telecom networks, basic cloud capacity, and consumer internet adoption, were becoming accessible enough for the coordination layer to matter. DPI did not eliminate dependence on global technology systems. It used available technology layers to build a domestic coordination architecture on top.
DPI also operated in a favorable cost regime. Once the rail existed, each additional payment message or identity check could move through a standardized digital process at very low marginal cost. The hard part was getting banks, agencies, standards, users, and service providers to coordinate around the same rails.
AI is different because the stack and the cost structure change together. Training large models is expensive, and inference is not costless either. Each query must be served through compute, memory, electricity, cooling, networking, and cloud infrastructure. The IEA’s analysis of energy and AI emphasizes the data-center electricity constraint, while Microsoft Research’s work on AI inference energy shows how workload design shapes energy demand at inference time.
DPI made digital coordination cheaper over infrastructure that had become broadly accessible. AI, by contrast, makes repeated claims on scarce physical infrastructure every time a model is trained, hosted, queried, cooled, and updated.
Steering Without Owning
The most interesting thing about DPI is not digitization by itself. E-governance initiatives can digitize forms, portals, and service delivery. DPI does something more structural: it lays public rails and changes the terms on which other actors operate.
When a government builds an identity rail, it changes how banks verify customers, how welfare agencies authenticate beneficiaries, how telecom firms onboard users, and how private services establish trust. When it builds a payment rail, it changes market entry for payment providers, merchants, banks, and app developers. When it builds a data-exchange layer, it changes who can access which records, under what consent conditions, and through which interfaces.
DPI belongs in the broader family of infrastructure-as-governance moves. States do not only fix market failures after the fact. They also shape markets through investment, standards, procurement, information architecture, legal authority, and organizational coordination. DPI combines several of these tools at once.
DPI lets the state steer without owning every service built above the rail. That is its strategic importance for middle powers. A country may not control the deepest global technology stack. It may not own the devices, chips, operating systems, cloud platforms, or software ecosystems on which digital life depends. But it can still shape domestic participation by building shared protocols, registries, standards, and service interfaces. This is not full technological sovereignty. It is not passive dependence either. It is steering.
India’s DPI experience matters because it shows steering at population scale. The state did not build every fintech product or own every consumer-facing payment app. It built a common rail around which banks, fintech firms, merchants, and users could coordinate. The rail changed the market without replacing the market.
Coordination also redistributed leverage. UPI altered the bargaining position of banks, payment apps, merchants, regulators, and users by moving competition away from bilateral relationships and proprietary payment rails toward interfaces, data, customer acquisition, and compliance with a shared protocol. AI-DPI systems will create similar leverage questions. Public workflows, registries, audit interfaces, and procurement channels will not merely connect actors; they will shape where bargaining power accumulates.
Public rails therefore create politics as well as efficiency. They do not automatically produce public value. They create an institutional terrain on which public value has to be produced, defended, measured, and corrected.
Public Rails Need Public Governance
The DPI debate often gets pulled into two familiar stories. One story presents DPI as democratic infrastructure: open, interoperable, inclusive, participatory, and developmental. It gives countries a way to avoid dependence on closed private platforms, lets small firms build on shared rails, and gives the state leverage over service delivery without monopolizing every service itself. The other story presents DPI as digital control: identity systems become surveillance systems, consent becomes coercive, authentication failures become exclusion, and public infrastructure becomes a channel through which private firms harvest public value.
The democratic-infrastructure story can become too flat. DPI is not inherently democratic because it is digital, interoperable, or state-backed. A payment rail can expand access while still concentrating consumer-facing power in a few private apps. A digital identity system can reduce duplication while also creating exclusion when authentication fails. A data-exchange layer can support user control while becoming opaque if consent is reduced to a checkbox.
DPI is not inherently authoritarian either. Shared infrastructure can reduce dependence on proprietary platforms, lower entry barriers, improve portability, and make some services more accountable. The political question is not whether DPI is good or bad in general. It is what constraint DPI is being asked to solve, and what safeguards make the infrastructure genuinely public in practice.
The safeguards literature matters because public rails need public obligations. The Universal DPI Safeguards Framework, developed through a UNDP and UN technology-envoy process, treats DPI as an evolving category that requires safety, inclusion, accountability, redress, governance standards, and lifecycle assessment. That framing is useful because it refuses both hype and rejection. It asks what must be true for public infrastructure to remain public.
India’s own experience shows why those obligations matter. Reetika Khera’s work on Aadhaar and welfare programmes argued that digital identity could produce exclusion when beneficiaries were denied entitlements because of authentication failures, linking problems, or administrative rigidity. The State of Aadhaar 2019 report found broad coverage and frequent use, but also documented errors, service denial, and unresolved problems for a minority of users. Aadhaar should not define the entire DPI category, but it shows the governance problem clearly: public infrastructure becomes public through the quality of its recourse, correction, and accountability.
DPI’s public-private boundary sharpens the problem. DPI is often described as “public rails for private innovation.” But public rails can still enable private concentration above them. The Bennett School’s review of DPI promises and realities points to the governance, market-structure, and state-capacity questions that follow from this model. DPI is neither simply public provision nor ordinary privatization. It is a hybrid institutional architecture.
Hybrid infrastructure can support inclusion or produce exclusion. It can enable competition or concentration. It can strengthen public capacity or outsource public functions into systems that few people can contest.
DPI politics is not the old left-right fight in new vocabulary. It is a question of institutional design and maintenance. Standards need revision, authentication failures need correction, grievance channels need staffing, and users need recourse. A rail becomes politically visible not when it works, but when it denies a benefit, misroutes a record, fails to authenticate a person, or leaves no one clearly responsible for repair. Public value has to be maintained after the infrastructure scales.
What DPI Can Do For AI
The new temptation is to treat AI as the next DPI frontier, and it is understandable. If AI systems are going to enter public services, they will need identity, consent, registries, audit logs, escalation pathways, and service workflows. These are precisely the kinds of things DPI can help coordinate.
Several global AI-DPI proposals are now trying to define this space. The Global AI Impact Commons frames AI diffusion around shared use cases and reusable public-service deployments. The CDPI DPI-AI framework offers one more explicit version of the argument through AI Blocks, DPI Workflows, and Public Agents: modular capabilities and auditable service recipes that connect AI systems to safeguards and human oversight. The point is not that this is the definitive model. It is that the AI-DPI conversation is becoming a live policy category.
The useful part of that turn is fragmentation control. AI in public services should not become a pile of disconnected pilots: a chatbot here, a recommender system there, an eligibility tool elsewhere, each with its own data pipeline, vendor contract, consent flow, and error-handling process. That is how public institutions accumulate automation without governance.
DPI can help prevent that fragmentation. Common registries can stop AI systems from inventing their own versions of institutional truth. Consent and data-exchange rails can prevent every project from improvising data access separately. Reusable workflow templates can specify human review, confidence thresholds, appeals, and logs. Local-language services can connect models to public-service workflows instead of leaving translation and assistance to private apps alone. These are DPI moves at the AI layer: not new technical capability, but shared scaffolding around it.
DPI becomes strategically important for AI adoption at this layer: not as a substitute for frontier models or compute infrastructure, but as a way to shape the conditions under which AI touches society.
The essay on operational capacity argued that procurement, evaluation, audit, contestability, escalation, and responsibility are scarce capacities in AI deployment. DPI can support those capacities if it is designed as accountable service infrastructure. A welfare agency using an AI eligibility recommender should not merely receive a score. The agency should know which registry was queried, whether the decision was automated or reviewed, how the citizen can contest it, and how repeated errors will be detected.
AI changes the character of the workflow. Classic DPI systems route bounded transactions: verify an identity, move a payment, exchange a document, authenticate a request. These systems can fail badly, but the operation itself is usually defined in clear terms. AI systems introduce probabilistic judgment into those rails. They classify, recommend, rank, and predict. Probabilistic judgment is not a faster version of a bounded transaction. It is a different kind of operation, and a DPI rail carrying it is doing something the rail was not originally designed for.
Samagra Vedika shows the risk in compressed form. The AIAAIC repository includes the Samagra Vedika incident, where database consolidation and algorithmic decision processes in Telangana were reported to have denied food rations to eligible citizens. The operational capacity essay treats the case as a failure of evaluation, audit, and recourse. Here the lesson is narrower: once algorithmic matching enters a public workflow, a flawed record can become difficult for the affected person to contest.
The public-facing service may be digital, standardized, and formally rule-bound, while the matching logic inside the workflow remains difficult to inspect. If a system associates the wrong person, household, asset, or entitlement record, the person affected does not experience a technical classification. They experience a benefit denial.
The AI-DPI risk is this: public rails can make services interoperable while probabilistic systems make the judgment inside those services harder to see. The risk does not cancel the diffusion value. In a country like India, AI adoption will not happen only through frontier labs. It will happen through banks, schools, hospitals, municipal offices, and state portals. Shared rails can reduce adoption costs and give the state a way to set participation rules without building every application itself.
The DPI category travels better than the India Stack template. The transferable lesson is not “build India Stack for AI.” It is that shared infrastructure can become a steering instrument where a technology ecosystem is fragmented and public coordination can reduce participation costs.
Where DPI Reaches Its Limits
DPI reaches its limit when the binding constraint is no longer coordination. AI has coordination problems, but it is not only a coordination problem. The essay on the stack beneath the interface looked at GPUs, fabs, CUDA, cloud infrastructure, energy, data centers, and model ecosystems. Better public digital rails do not make those constraints disappear.
Coordination and substrate are two different AI problems. Where the immediate constraint is fragmented public-service adoption, improvised workflows, weak contestability, or disconnected data exchange, DPI can do real strategic work. Where the constraint is access to compute, advanced chips, cloud infrastructure, energy, model ecosystems, or institutional evaluation capacity, the instrument has changed. A coordination strategy becomes a category error when it is mistaken for a capability strategy.
DPI-for-AI optimism can make that category error. It assumes that because DPI helped India leapfrog in digital payments and service delivery, the same public-infrastructure strategy can overcome AI’s deeper dependencies. But UPI and Aadhaar scaled in a technological environment where the relevant substrate was much more accessible. AI’s hardest bottlenecks sit deeper in the stack — in the layers the earlier sections named — and a coordination strategy cannot reach them.
DPI can help with the top and middle of this system. It can make public-service AI more interoperable, auditable, contestable, and inclusive. It can help create local language interfaces, sectoral data flows, consent mechanisms, and workflow standards. It cannot substitute for capability formation deeper in the stack.
The Global AI Impact Commons is a clean example of the distinction. A repository of reusable AI deployments can reduce duplication. A public workflow layer can help agencies discover tools, compare use cases, and adopt common safeguards. A shared AI block can make a translation, eligibility, or advisory service easier to plug into public systems.
Scale brings the deeper questions back. The model still has to be hosted. Someone has to pay the inference bill. A cloud provider serves the workload. Chips, power contracts, model updates, and failure responsibility all sit beneath the public workflow layer.
The coordination layer can make adoption smoother. It cannot remove the material and institutional dependencies underneath. A public API can localize access without localizing control. A sovereign interface built around an externally governed model may improve distribution, audit trails, and user experience, but it does not by itself control the model’s weights, update behavior, inference pipeline, pricing, cloud exposure, or export-control vulnerability.
The IndiaAI compute-access effort and DPI therefore belong to different strategic categories. Compute access lowers the near-term cost of using scarce infrastructure whose deepest layers remain externally controlled. DPI builds coordination infrastructure where the state can shape the rules of participation. Both can be useful. They are not the same move.
Treating them as the same move encourages a country to confuse adoption with capability, orchestration with control, and interface access with sovereignty. If a public AI system fails because the model performs poorly in local conditions, because the agency cannot audit vendor claims, because power costs make inference expensive, or because the cloud provider changes access terms, a DPI workflow alone will not solve the problem.
The strategic principle is simple: instruments work when they match the constraint. Fragmented systems need coordination. Exclusionary markets may need public rails that lower entry barriers. Accountability problems may need logs, redress pathways, and standardized workflows. Compute concentration, chip fabrication, and energy availability require other instruments. DPI may organize access, aggregate demand, and improve bargaining terms. It does not produce the substrate.
Democratic governance follows the same principle. DPI can support consent, transparency, and public accountability, but participation is not produced by infrastructure alone. A consent layer is not democratic if refusing consent means losing access to essential services. An audit log is not accountability if no institution has the power or capacity to act on it. That is slow institutional work.
The Category, Not The Template
DPI’s most important contribution is not that it gives India a universal model for AI. It gives us a sharper way to think about technological statecraft. States do not only regulate technologies after markets form. They also shape the conditions under which markets, public agencies, firms, and citizens interact, including through shared digital infrastructure.
DPI will matter for AI and other emerging technologies where public coordination is the missing layer: common rails, data-exchange rules, consent architecture, reusable workflows, access for smaller firms, and contestable public services. It will matter less where the binding constraint is deeper: compute, chips, energy, industrial capability, cloud concentration, institutional judgment, or the slow formation of operational capacity.
The right lesson from DPI is therefore not confidence or cynicism. It is constraint diagnosis. Before copying the DPI template into AI, a country has to ask what problem it is actually solving: fragmentation, market concentration, data access, institutional legitimacy, evaluation capacity, or physical infrastructure. Each answer requires a different instrument.
DPI is powerful because infrastructure can govern. Its strategic value lies in showing that states can shape technological systems without owning every layer beneath them. Coordination was DPI’s binding constraint, and the rail solved it. Capability formation is AI’s, and the rail cannot.
The limit of DPI is where the harder work of capability formation begins.