The Conditions That Make Intelligence Useful

Artificial intelligence is often discussed through the capabilities of the systems themselves. Models can interpret language, generate content, analyse information, and support increasingly complex tasks. These advances matter, but they do not fully explain why an AI application becomes useful in one setting and struggles in another.

The World Bank’s World Development Report 2026: The Promise of Artificial Intelligence offers a useful way to examine that gap. Its analysis moves beyond the technology to consider the conditions that shape adoption and adaptation. The central implication is important: access to AI creates an opportunity to use it, but access alone does not establish that useful capability exists.

This distinction changes how AI progress should be understood. A system can be technically capable and still be poorly suited to the people, institutions, infrastructure, and work processes around it. The question is not only what a model can do. It is what a particular setting enables people to do with it.

Access creates possibility, not capability

Making an AI application available is an important step. Yet availability does not guarantee that people can use it effectively, that it addresses a meaningful need, or that its outputs can be acted upon. Access is one part of a larger chain between technical possibility and practical use.

The chain can be constrained by basic conditions. Electricity and connectivity affect whether a service can be reached reliably. Devices and interfaces affect who can use it. Skills influence whether users can interpret outputs and recognise when they should question them. Relevant information and workable processes determine whether the application can contribute to the task it is meant to support.

These conditions are not identical everywhere, and they do not carry equal weight in every application. A voice-based service designed for people with limited internet access has different requirements from an AI system integrated into a large organisation’s data infrastructure. Useful design begins by understanding the setting rather than assuming one deployment model fits all.

Intelligence has to fit the world in which it operates

AI systems are developed using particular data, assumptions, and environments. When they are used elsewhere, differences in language, population, working conditions, available information, or user behaviour can affect performance. A system that works well under one set of conditions may not transfer cleanly to another.

This is why adaptation is more than a final technical adjustment. It can require local knowledge, relevant data, changes to the interface, integration with existing processes, and evaluation under the conditions in which the system will actually be used. Context is part of the design problem.

The report’s discussion of AI development and adoption points toward different pathways for countries and institutions. Many settings can benefit by adopting and adapting existing systems without attempting to advance the global AI frontier themselves. The appropriate path depends on needs, resources, and the conditions already in place.

The complements that rarely appear in the model demo

Demonstrations tend to make the model visible and the surrounding system less visible. In practice, AI may depend on reliable infrastructure, usable data, people with the right skills, organisational readiness, and institutions able to set expectations and respond when systems fail.

These complements influence whether a system can be introduced, maintained, and improved. In an organisation, they may include process ownership, staff training, integration with existing tools, quality checks, and a clear way to measure whether the application is helping. In public services, they may also include administrative data, procurement capacity, testing and evaluation, accountability, and the ability to protect people affected by decisions.

This does not mean every application needs the same infrastructure or the most sophisticated implementation. It means the requirements should be identified rather than treated as incidental. A technically impressive system can remain peripheral if no one is responsible for its outputs, if the data is unsuitable, or if the workflow cannot accommodate it.

Why capability does not automatically become productivity

Productivity is an outcome, not a feature that can be read directly from a model specification. An AI tool may complete a task quickly, but the wider process can still be slow, error-prone, or expensive. Staff may need to verify outputs, correct mistakes, move information between systems, or redesign the work around the new tool.

The value of an application therefore depends on the work around it. It matters whether the system improves a decision, reduces a meaningful source of friction, expands access to a service, or enables work that could not previously be done. It also matters whether those improvements persist once the system is used at scale.

Measurement should follow the problem being addressed. Activity metrics, such as the number of users or generated outputs, can describe adoption, but they do not by themselves establish improved performance. The relevant question is whether the intended outcome has changed, for whom, and at what cost.

Small AI can be a design choice, not a compromise

If the objective is useful capability, scale is not the only design variable that matters. Some settings need a large, general-purpose system. Others may be better served by a narrower application that fits a specific task, works within available infrastructure, and reflects local needs.

The report’s discussion of small AI draws attention to this possibility. Applications designed around concrete problems and resource constraints can open pathways that would be harder to support through a uniform model of deployment. The point is not that small systems are always better. It is that the application should fit the problem and the setting.

This makes design discipline important. Before choosing the system, it is worth establishing the user need, the environment in which it will operate, the resources available, and the consequences of incorrect or incomplete outputs. Technical ambition should be connected to a credible path to use.

Deployment is a beginning, not the development outcome

Introducing a tool is a visible milestone. Building the capability to use it well is a longer process. Systems need to be tested in context, monitored as conditions change, and improved when evidence shows that they are not working as intended. People need ways to raise problems, and organisations need the authority and capacity to respond.

Evaluation and safeguards belong within this process. They help identify performance gaps, unintended consequences, and uneven effects across groups. They also create feedback that can guide adaptation. Without these mechanisms, deployment numbers can grow while the quality and distribution of benefits remain unclear.

Development therefore involves more than the presence of AI applications. It concerns whether people and institutions can use them to address meaningful needs, sustain that use, and manage the risks that accompany it. Those outcomes depend on choices about infrastructure, design, skills, governance, and the allocation of resources.