Inclusion doesn't survive being bolted on to AI

Talent advisory firm Seramount has published a framework for what it calls inclusive AI leadership, built around five directives: build AI fluency, embed inclusion at the point where AI decisions are made, equalize the learning curve, define human accountability before deployment, and apply AI where it has the most impact on individual workers. The HR Dive write-up presents this as guidance. We’d frame it differently: it is a checklist for avoiding a set of failures that are already in progress.

The framework is sound. The problem is that most organizations are not starting from the beginning. They are mid-deployment, and inclusion is being asked to catch up.

According to Randstad research, 71% of workers who self-report as AI-skilled are men, while just 29% of women say the same, a 42-point gap. That is not a pipeline problem in the traditional sense. It is a training and access problem, compounded at every layer of the organization. When a company rolls out an AI tool and assumes workers will self-direct their own upskilling, it is not running a neutral process. It is running a process that reproduces whatever access asymmetries already exist.

The system is not biased. The rollout is. And the rollout is a design choice.

Seramount’s directive to “make the learning curve more equitable” is the one that most organizations will skip, because it requires admitting that the curve is not currently equitable. Randstad’s research warns that AI inequities, if left unaddressed, could worsen labor shortages against a backdrop of structural talent scarcity. That framing, notably, is a business case, not a moral one. It is also more likely to move a budget.

The accountability question is where the framework gets technically interesting. Seramount’s call to “define human accountability early” is not a soft HR principle. It is an engineering constraint. When a classifier is making or informing a consequential decision, the question of who owns the output, and who is liable when it is wrong, has to be answered before the system goes live. Most deployments answer it after the first incident. That is not a governance gap. It is a governance choice, and it tends to protect the vendor.

The source article also notes the Workday age-discrimination lawsuit as a live example of where deferred accountability lands. A class-action alleging violations of the Age Discrimination in Employment Act against a hiring platform is not a hypothetical. It is what happens when the accountability question is left open long enough for a court to answer it instead.

None of this makes Seramount’s framework wrong. It makes it urgent in a way the framing of “baking in” inclusion does not quite capture. Inclusion is not an ingredient you add at the start of a recipe. It is a constraint you either design around or design out. Most current deployments have designed it out, not through malice but through the ordinary momentum of shipping fast and fixing later.

The fix-later option is closing.