Digital Public Infrastructure and Its Limits
Public rails can shape AI adoption. They cannot supply the compute, energy, institutional judgment, or industrial depth AI requires.
Two Problems, Two Instruments
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 intuition is useful, but it can mislead. DPI can organize how AI adoption happens. It cannot by itself create the industrial depth, compute, or institutional capacity required for AI deployment and frontier competition. Coordination and capability are different problems.
Public rails are most useful when AI enters public services. They can coordinate identity, consent, records, audit, redress, and workflow across agencies and vendors. They cannot resolve the deeper constraints of models and the infrastructure beneath them: compute, cloud, chips, energy, and data centers. Nor can they replace the institutional judgment required to evaluate AI systems. Public rails can still support downstream learning, but they are not a substitute for the deeper stack.
India’s DPI experience shows what coordination infrastructure can do. 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.
AI, however, is not only a coordination problem. It is also an industrial, infrastructural, and operational problem. Its bottlenecks include the infrastructure beneath models, from compute and chips to energy and cloud capacity. Others sit in the institutional capacity to evaluate AI-mediated decisions.
DPI is not a template to copy into AI. It is a steering instrument: useful for organizing adoption and participation, but unable to remove deeper infrastructure bottlenecks. Its power lies in that specific role, and so do 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.
UPI did not appear from nowhere. It assembled and exposed underlying primitives, including bank payment rails such as IMPS, through a public platform layer that developers and applications could build around. That is the distinctive DPI move: not inventing every underlying technology, but turning available primitives into a coordination architecture.
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 journeymakes 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.
Silicon and global technology systems still mattered to UPI, but they were not the constraint the public rail had to solve.
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. Frontier training requires concentrated, capital-intensive compute. Individual inference requests are cheaper than frontier training, but serving models repeatedly at scale creates continuing demand for 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 or queried at scale, supporting compute has to be powered, networked, and cooled; hosting and updating the system add recurring costs.
Figure 1: DPI coordinates many actors through shared rails; AI repeatedly draws on concentrated infrastructure.
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 banks, agencies, firms, and service providers operate.
When a government establishes or commissions 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 establishes a payment rail, it changes market entry for payment providers, merchants, banks, and app developers. When it establishes 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. DPI applied to AI 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 enforceable obligations. The Universal DPI Safeguards Framework, developed through a UNDP and UN technology-envoy process, translates that principle into 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 programmesargued 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 realitiespoints 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 about institutional design and maintenance. Standards need revision, authentication failures need correction, grievance channels need staffing, and users need recourse. A public 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
AI in public services creates a new coordination problem. Common rules for identity, consent, records, audit, escalation, and service workflow have to work across agencies and vendors. These are the institutional components DPI can help coordinate.
Several proposals now describe DPI applied to AI. The Global AI Impact Commons frames AI diffusion around shared use cases and reusable public-service deployments. The CDPI DPI-AI framework offers one explicit version through AI Blocks, DPI Workflows, and Public Agents: modular capabilities and auditable service recipes that connect AI systems to safeguards and human oversight. Neither is a universal model. Together, they show that the policy category is becoming real.
Three claims need to be kept distinct. First, AI can be used inside public-service workflows. Second, public rails can make those technology use-cases more reusable, auditable, and substitutable across agencies and vendors. Third, neither achievement is the same as frontier AI capability.
Fragmented pilots are the immediate problem public rails can address. A chatbot, recommender system, and eligibility tool can each arrive with a separate data pipeline, vendor contract, consent flow, and error-handling process.
Shared 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 private or public models to accountable public-service workflows instead of leaving integration to vendor-specific apps alone. Together, these are public rails for AI: shared scaffolding around public use.
In public-service workflows, DPI shapes the conditions under which AI touches society.
Repeated use of shared rails can build limited but real capability. Shared infrastructure can aggregate demand, create common data standards, make providers easier to substitute, and give agencies repeated experience with evaluation and repair. This downstream effect strengthens adoption and institutional learning without changing where frontier models, compute, cloud systems, and energy infrastructure come from.
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.
A 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 risk in DPI applied to AI is that 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 the deeper AI stack are two different 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.
The Global AI Impact Commons is a clean stress test of the distinction. A repository of reusable deployments can reduce duplication, help agencies compare use cases, and spread common safeguards. But the model still has to be hosted, the inference bill paid, and updates supplied. A public API can localize access while leaving model behavior, pricing, cloud exposure, and export-control vulnerability governed elsewhere.
Figure 2: DPI can shape participation rules and deployment routines. It cannot by itself produce the deeper infrastructure.
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.
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 chips, compute, cloud, data centers, or energy capacity beneath the rail.
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.
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. These are not uniquely AI problems. What changes is which constraint becomes binding, how quickly systems scale, and how opacity or concentrated infrastructure alters the available instruments. 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.
The limit of DPI is where the harder work of capability formation begins: how institutions turn access and adoption into capability that compounds rather than disperses.
Visual note: The diagrams in this essay are original Yukti visuals, designed from the author’s briefs and produced with AI-assisted code generation, then reviewed before publication.