Your photographs, messages, notes, and documents may be available every morning through one account. You feel in control—until the price changes, the account is locked, or moving years of material proves harder than opening it. Access is immediate. Capacity is what remains when the terms change.

Everything is there—until you need to move it

Your phone automatically stores photographs, backs up messages, synchronises notes, and helps an AI assistant find the document you meant. You do not maintain a server or think about file formats. The service is useful precisely because the machinery disappears.

Then storage becomes more expensive, an account problem interrupts access, or you decide to move. Downloading a photograph is easy. Recreating albums, dates, shared links, search, captions, permissions, and years of habits is not. An alternative may exist, but adopting it means losing parts of what made the old service valuable.

You had access to a capable service. Whether you also had control depends on what you could understand, preserve, move, and continue when the relationship changed.

Scale that problem to a university using an AI study assistant, a clinic organising records, or a public office answering questions. The visible tool is only the top layer. Beneath it sit computers, electricity, networks, software, data, skilled workers, contracts, security rules, and decisions about who may use what. Losing one essential layer can stop the whole project.

Carry this forward

Access describes what works today. Capacity describes what you can still understand and choose when tomorrow is different.

Using something is not the same as being able to manage it

A bus ticket gives you a journey. It does not give you a transport system. In the same way, an AI account gives an institution a service, not necessarily the ability to keep that service working or choose its direction.

Capacity grows when people can:

  • afford the service after a trial ends;
  • understand how it performs and where it fails;
  • protect the information placed inside it;
  • question a decision and obtain a meaningful answer;
  • keep skilled people who can maintain it; and
  • move records and work to a credible alternative.

No institution needs to own every computer or write every line of software. Partnerships can be valuable. The important question is whether the institution can still make meaningful choices, or whether it must accept whatever one provider decides.

Try the distinction

Could you leave without losing the life organised around the service?

A visible export button answers only one part of that question.

  1. Material: Can the files and records be retrieved completely and in usable form?
  2. Meaning: Do dates, links, labels, permissions, and relationships survive the move?
  3. Skill: Does someone understand the replacement well enough to keep important work going?
  4. Continuity: Is there a period in which both the old and new arrangements can be tested safely?
  5. Voice: Can users influence harmful changes before exit becomes the only remaining option?

A theoretical alternative becomes a meaningful choice only when people can adopt it without abandoning the function they were trying to protect.

The strongest case for sharing

There are good reasons to share AI infrastructure. Large providers can maintain specialised equipment, investigate failures, distribute updates, and support organisations that could never build the same system alone. One dependable service may sometimes be safer and cheaper than many weak ones.

So size is not automatically harmful, and dependence is not automatically unfair. We all rely on shared electricity, transport, and payment systems. Coordination becomes a problem when the organisation providing an essential service can change the rules, withdraw access, or block movement without being answerable to the people affected.

When does an AI service become infrastructure?

Not every popular app is infrastructure. The term is useful when four conditions come together:

  1. Many activities rely on it. The service supports several important kinds of work.
  2. Losing it would matter. Schools, hospitals, researchers, businesses, or public services would struggle to continue.
  3. Leaving is difficult. Alternatives exist on paper but switching would lose data, skills, money, or time.
  4. Someone controls a bottleneck. One organisation can decide who participates and on what terms.

A widely used writing app may still be easy to replace. A less famous scientific system may be essential to a small research community. The label depends on who relies on the system, for what purpose, in which place, and at what time.

Five brands do not always mean five choices

Imagine five AI assistants with different names. If they all depend on the same cloud, model, login system, or contract, one failure can affect every apparent option. The market looks varied, but the underlying choice is narrow.

Real choice means that alternatives differ in ways that matter: where they run, how they are governed, which languages they support, whether they can be evaluated, and whether people can move their records.

More providers are not always better. Duplication can waste money, and smaller systems can be less secure. The goal is not endless variety. It is enough meaningful difference that no single failure or controller determines every path.

Ask six questions before choosing a remedy

  1. What is essential? Name the service, layer, or skill people actually depend on.
  2. Who depends on it? A convenience for one group may be indispensable to another.
  3. Who can change the terms? Find the actor controlling price, access, standards, or continuity.
  4. Can people understand and challenge it? Access without evaluation leaves institutions unable to learn.
  5. Can they leave in practice? A right to switch is weak if records, skills, or essential functions cannot move.
  6. Who repairs failure? Responsibility must reach the organisation able to prevent harm and restore service.

Different problems need different answers. Unfair exclusion may call for clear access rules. A skills gap may need long-term training. Difficult switching may need portable records and tested migration. An essential public function may need a reliable fallback or public option.

Where this argument stops

Openness can create new security and privacy risks. Public ownership can still produce an underfunded or unaccountable service. Switching a complex system will never be cost-free. And ordinary procurement, competition, or safety rules may already solve some cases.

The framework should therefore be used as a test, not as a slogan. It helps only when it reveals a real dependency and points to a proportionate remedy.

From the longer research

The full framework behind this essay

This is a plain-language companion to my longer research paper. The paper defines public capacity more precisely, tests difficult cases, and explains where the framework should be revised or abandoned. This essay offers interpretation, not a report of an original empirical study.

Read the complete preprint on ZenodoAI Infrastructure as Public Capacity: Dependency, Pluralism, and Institutional Choicedoi:10.5281/zenodo.21757690

What to remember

Access lets an institution use a tool now. Capacity lets it understand the tool, question it, keep important work going, and choose another path later.

That difference matters because AI is rarely just an app. It is a chain of resources, people, rules, and organisations. Good policy should make that chain visible—and make sure institutions can do more than wait for someone else to decide.