If AI companies are serious about reducing bias and building technology that works across different cultures and communities, employing a resident sociologist is only the first step. Here, Dr Stephen Whitehead explains how he would embed sociology across product development to identify hidden assumptions before they become costly, embarrassing failures

In 2018, Amazon quietly shelved an AI recruiting tool it had spent years building. The system, trained on a decade of CVs submitted mostly by men, had taught itself that maleness was a proxy for competence. It downgraded CVs containing the word “women’s,” as in “women’s chess club captain.” It penalised graduates of two all-women’s colleges. Engineers tried to patch the bias out, yet found that there was no guarantee that the model would not find new proxies for the same pattern. Amazon ultimately abandoned the project rather than risk deploying it.

Nobody at Amazon set out to build a sexist hiring tool, which is why the story is still relevant years later. The structural bias was baked into a training dataset that reflected who had already been hired, and reproduced faithfully by a system with no instruction to do otherwise. Goodwill alone would not have caught it. Only a systematic, standpoint-aware audit conducted before launch would have surfaced it before the apology.

In my previous article, Why AI Companies need a resident sociologist, I made the case for why AI companies need someone whose job is to see the institution the way a trained outsider sees it, and to say the uncomfortable thing before a journalist, a regulator or a viral thread says it first. The obvious question follows: what does that person actually do? A job title is not a job. 

This is how I would build the function in practice.

My answer draws on the framework I have spent three decades developing under the banner of Total Inclusivity. It is worth being precise about what that phrase means, because it is routinely misread. Total Inclusivity begins from the fact that cultural neutrality is impossible: there is no neutral vantage point from which a product, a policy, or an algorithm can be built. Every default setting, every ‘typical user’ persona and every training dataset privileges somebody’s experience over somebody else’s. The discipline makes that privileging visible, explicit and accountable, so it can be examined and corrected before it hardens into outcome.

I would organise the work across six stages, deliberately sequenced so that each builds on the standpoint work done in the one before it.

It begins with scoping and standpoint mapping. Before a single line of code or a single policy clause is drafted, someone has to ask the question institutions almost never ask explicitly: whose experience are we treating as default here? Every development team carries assumptions about the typical user, usually unexamined and usually a reflection of the team itself. Amazon’s engineers were, disproportionately, the demographic their training data already favoured, and nobody had been tasked with naming that fact out loud before the build began.

Next comes the dataset and training data audit – the stage that would have caught Amazon’s problem outright. Data records past decisions, past exclusions and past power. A dataset built from a decade of hiring decisions records who a company already hired rather than merit. Auditing for skew and representation gaps at this stage costs a fraction of what it costs to unwind a shipped product.

The third stage examines user personas and journeys, testing whether a product works and reads correctly across cultures, genders and lived experience. A persona document that describes a typical user in terms that quietly assume a particular nationality, family structure or gender role will produce a product that serves that persona well but everyone else poorly. This is where cultural misreads get caught: the assumption, for instance, that directness in feedback lands the same way in Frankfurt as it does in Bangkok.

Fourth is design and algorithmic review, evaluating the interfaces and decision logic themselves for bias amplification: where bias enters a system and where the system’s own feedback loops make a small skew larger with every iteration. This is the stage most organisations skip entirely, because it requires technical and sociological literacy in the same room at the same time, which is rarer than it should be.

Fifth is the sign-off gate, the stage that gives the resident sociologist actual authority. The role reviews the accumulated findings and either approves the product for launch or requires changes, with genuine power to hold the gate rather than file a memo that gets read after the fact. A resident sociologist without the standing to say “not yet” is a compliance exercise, not an audit.

Finally, post-launch monitoring: ongoing metrics and periodic re-audits, because standpoint drift doesn’t stop at launch. User bases evolve, edge cases emerge in the wild that no pre-launch review could anticipate and yesterday’s inclusive default becomes tomorrow’s blind spot as a product scales into markets its designers never imagined.

This work goes far beyond a diversity statement bolted onto a launch plan. Inclusivity must be designed into architecture, data and governance from the outset. It requires an organisation to tolerate some uncomfortable self-examination about power, culture and incentive, which is precisely why so few do it voluntarily until the cost arrives in the form of a headline.

The AI dimension makes all of this more urgent. A biased hiring manager makes one bad decision at a time, at human speed, correctable by the next manager down the corridor. A biased algorithm makes millions of decisions at machine speed before anyone notices the pattern, and by the time it surfaces, it has already been baked into every downstream system that trusted its output. The asymmetry between the cost of auditing before launch and the cost of unwinding after launch has never been starker, and it is only going to widen as more institutional decision-making gets handed to systems trained on yesterday’s data.

What this requires, practically, is a dedicated resident sociologist with real organisational authority: a function empowered to hold the fifth-stage gate shut when the evidence says it should stay shut. 

The return on that investment is fewer toxic products reaching market, fewer belated CEO apologies and – the thing every board actually cares about – materially reduced exposure to the kind of reputational and legal risk that a shelved recruiting tool represents in its mildest form.

The resident sociologist, in other words, is hired to make an organisation see itself clearly, on a schedule, before the market does it for them.

Dr Stephen Whitehead is a gender sociologist and author recognised for his work on gender, leadership and organisational culture. Formerly at Keele University, he has lived in Asia since 2009 and has written 20 books translated into 17 languages. He is based in Thailand and is co-founder of Cerafyna Technologies. His forthcoming book, co-authored with Constanza Fernández Arce, is Where Have All the Good Men Gone?

READ MORE: ‘Why AI Companies need a resident sociologist‘. AI firms are recruiting philosophers to shape the values and behaviour of their systems but, according to Dr Stephen Whitehead, they are overlooking sociologists, the experts best placed to identify the assumptions that can leave technology biased, exclusionary and unsafe.

Do you have news to share or expertise to contribute? The European welcomes insights from business leaders and sector specialists. Get in touch with our editorial team to find out more.

_{Main Image: fauxels/Pexels}