Is there such a thing as AI diversity?

Every business knows the case for a diverse team. Part of it is moral: nobody should be shut out of a career by where they were born or which school they went to. Part of it is practical: a room in which everyone thinks the same way misses the same things. The practical half has quietly acquired a new application, and it is sitting inside your software.

Does diversity apply to AI?

Not the moral half. There is no AI that grew up on a council estate and became the first in its family to go to university, and borrowing that language for a software supplier would be glib. The practical half applies more than most businesses have noticed. Every AI model is trained on a different diet by a different team, so each has its own blind spots. If every piece of AI your business depends on shares one training, it shares one set of blind spots. Researchers call the risk algorithmic monoculture.

Two pieces of academic work give it shape. Jon Kleinberg and Manish Raghavan showed in a 2021 paper in PNAS that when every decision-maker uses the same algorithm, the quality of their decisions as a group can fall, even when it is the most accurate choice for each of them alone. A Stanford team led by Rishi Bommasani asked a sharper question the following year: when systems share data or models, do the same people get rejected everywhere? On the fairness tests they ran, shared training data reliably made outcomes more uniform. The same person, picked on by every system. And the pull towards sameness is stronger than it looks: the models learn from much the same web, and every maker tunes to the same public benchmarks, which lead with coding and maths because those are the easiest things to mark.

What nine models told us about one football match

They agreed, and they were wrong. Since September we have run a public version of this question: Battle of the Bots gives nine AI models from three makers the same brief and the same evidence pack, and asks each to predict ten Premier League scorelines. In the first round all nine backed Chelsea to beat Hull, when the table in front of them showed Hull unbeaten and Chelsea leaking goals. A human reading the same two lines called the draw. In the third round all nine had Coventry losing 0-2 at home to Newcastle. Coventry won 4-1.

Three makers, one wrong answer. That is the uncomfortable finding for anyone who assumed that buying from several suppliers was diversity in itself. The models had read the same reputation, and the reputation was not the point. Every example in this post happened before we started thinking about it this way. The evidence came first; the idea arrived afterwards to explain it.

Where the models do differ

In how they take instruction, in what they are good at, in what they cost, and in when they are available. In that third round we gave every model two versions of the same brief, one asking for its reasoning first; it lifted one model by six points and cost another three. For design work we run a blind test, one written brief and two models, and choose without knowing which produced which. Over nine rounds this year both have won: one takes most of the expansive first drafts, the other the briefs that turn on judgement.

Price is the difference a finance director will care about. The model that won the third round cost three tenths of a cent. The three flagship models spent twenty of the round’s 35 cents between them for sixteen points; the two cheapest spent under half a cent for sixteen. On a handful of requests that is a rounding error; in a system making thousands a day it is a line on the accounts, and the dearest model is rarely the best one for the job. And in the fourth round one maker’s automated sign-in expired, the page that issues a new one had stopped working, and three of the nine entrants did not run. One supplier, one bad morning.

A concession, because we have argued the other side. For building our own software we stay with one maker, and we have explained why: the value is in the habits and tools around the model, and switching throws them away. Monoculture is a different decision. It is about which judgement your software depends on, and which AI it will work with, and the second is now partly out of your hands.

The AI using your software may not be one you chose

Cloudflare, which carries a large share of the world’s web traffic, said in June that automated requests had overtaken human ones on the sites it serves, earlier than its chief executive expected, and put the change down to AI agents, as The Decoder reported. It counts page requests, not people, and Cloudflare itself called the data rough, but the direction is enough. The AI on the other end of your website or your customer portal will increasingly be your customer’s assistant, and they chose it, not you. A system that only behaves with one maker’s assistant will turn away everyone who brought another.

What would make anyone fix it

Not principle. Money and embarrassment, arriving together. The case for diversity in software won budgets when its failures became simultaneous and visible. In 2020 a Vancouver academic found that video-call software kept removing his Black colleague’s head whenever a virtual background was on, and when he posted the evidence, the social network cropped the same colleague out of the preview, as TechCrunch reported. Every affected customer hit the same wall at the same time, some of them held budgets, and it looked awful.

Monoculture fails in the same shape. If every lender, recruiter and landlord screens with the same model, the person it misreads is turned down everywhere at once. That is the Bommasani finding with a name attached and a discrimination claim behind it. No moral duty is owed to an AI. The duty comes straight back the moment a monoculture is pointed at people, and that is where the headlines and the cost will arrive on the same day.

How we do it

The diversity that matters most in any system we build belongs to the client’s own people: the partner, the person on the front desk, the colleague who joins in year three. Understanding who will use the system, and how, is the work of the analysis stage before any code is written, and it is on us to get it right. Accessibility is then checked by machine: every change to our platform is tested against the standard public bodies are held to (WCAG 2.2 AA) before it ships, the result is printed in each client’s conformance report, and the test has already caught a real defect in our own work.

For the AI itself, one maker to build with, several to test against. An AI feature on our platform carries its maker and model as settings, so a client’s administrator can change either and try it on real input before keeping it. Every request is logged by model and cost, never by content, so “the best model for the job” is a reading from a log. And a system we generate can be driven by an outside agent under exactly the permissions a person would have, which we have tested on ourselves.

Two questions

The moral case for diversity belongs to people, and it still belongs to the people who will use what we build. The practical case has reached the machines. So ask two questions of any system you depend on. Who uses it? And which AI uses it? If the honest answer to the second is “only the one we picked”, you have a monoculture, and you found out before it cost you.