Why AI Arrives Late

Every few months a system is released that can do something genuinely new. It can hold a conversation, read a scan, transcribe a meeting, write working code. Within weeks it is available almost everywhere — as an app, an API, a feature inside software people already use.

Almost everywhere.

The gap between what a technology can do and where it actually arrives is not random, and it is not primarily about money. It follows a pattern, and the pattern is worth understanding if you are building here — because it tells you which problems are hard for good reasons and which are hard only because nobody has stood close enough to look.

Modern AI systems need three things. Where all three are present, they arrive immediately. Where any one is missing, they arrive late, arrive wrong, or do not arrive at all.

The first condition: data that already exists

A model learns from examples. That sounds obvious until you ask where the examples come from.

For most capabilities, they come from material that was already digital for some other reason. Language models learned from decades of text people wrote for the web. Speech systems learned from audiobooks, podcasts, broadcast archives, and transcription services built to serve courts and hospitals. Vision systems learned from photographs uploaded to platforms.

None of that material was created to train anything. It accumulated, and the technology arrived afterwards to harvest it.

This is why capability tracks so closely with which languages and contexts have been digital longest. It is not that English is easier to model. It is that English has been written down, recorded, transcribed, and uploaded at enormous scale for thirty years.

Hausa is spoken by tens of millions of people. It has a written tradition centuries old. It is not a small language, and it is not undocumented. But the volume of machine-readable Hausa — clean audio, aligned transcripts, structured text — is a fraction of what exists for languages with far fewer speakers in wealthier places.

The phrase for this in the research literature is “low-resource language.” It is a strange description. Nothing about the language is low-resource. What is scarce is not the language but the attention that would have made it legible to a machine.

That distinction matters, because one of those problems is permanent and the other is a decision.

The second condition: infrastructure that holds

The second requirement is dull and rarely discussed: the technology has to keep working.

Most AI systems are not software you install. They are services you call. A request leaves the device, travels to a data centre, gets processed, and comes back. That round trip assumes reliable connectivity, affordable bandwidth, and uninterrupted power at both ends.

Where those assumptions hold, the architecture is invisible. Where they do not, it is the whole problem.

A system that needs a stable connection to answer a question is not useful to a health worker in a rural clinic with intermittent signal. A system that consumes significant data per request is not useful to someone on a metered plan making careful decisions about what to load. A system that assumes the device stays powered is not useful where the grid does not.

These constraints do not make the problems unsolvable. They make them different. Smaller models that run on the device. Systems designed to degrade gracefully rather than fail. Work structured so that an outage costs hours instead of days.

That is not worse engineering. It is engineering for conditions that most of the field does not design for, and it produces different — sometimes better — architectures. Constraints have a way of forcing clarity.

The third condition: someone who pays

The third condition is the one people are least comfortable naming.

Building and running these systems costs money. Someone has to have a reason to spend it. In practice that reason is a market — enough users, paying enough, to justify the work.

This is where much of the gap comes from. It is not that anyone decided African languages did not matter. It is that when a team allocates limited engineering capacity, they go where the return is clearest. Repeat that decision across thousands of teams over a decade and you get the world as it currently is: enormous capability concentrated where it was commercially obvious, and thin coverage everywhere else.

The result is a self-reinforcing loop. No data, so no models. No models, so no products. No products, so no usage. No usage, so no data.

Loops like that do not open on their own. Something has to be built at a point where the immediate return does not justify it, on the expectation that it opens what comes after.

What this means if you are building

Three practical consequences.

Check what the data actually is. Dataset announcements quote impressive totals. Those totals frequently include material unusable for the task you have in mind — untranscribed audio counted alongside transcribed, many-speaker recordings counted as if they were suitable for single-voice synthesis. The usable portion is often a small fraction of the headline. Read the dataset card, not the press release.

Read the licence before the benchmark. A model can be public without being open. Terms that cap the number of users, prohibit commercial deployment, force derivatives to inherit the same restrictions, or mandate attribution branding all mean the same thing in practice: you cannot build a real business on it. That is worth discovering before you build, not after.

Design for the conditions you actually have. Not the conditions the reference implementation assumes. This will make some things harder and some things simpler, and it will occasionally produce a system that works better than the one you were copying — because it was built for somewhere real.

What this is not

It is not an argument that the technology is hostile, or that the gap is a conspiracy. Mostly it is the accumulated result of ordinary decisions, each locally reasonable, aggregating into something that looks deliberate but isn’t.

It is also not an argument that the gap closes itself. It won’t. The loop described above is stable, and the people best positioned to open it are the people standing inside it — who can see which problems are real, which constraints actually bind, and what would need to be true for something to work here.

That is not a disadvantage. It is the only vantage point from which some of these problems are visible at all.

Spectre Labs builds AI systems for the conditions the world’s technology routes around. Our current work is Turaco, a speech system for Nigerian languages.