Image created with AI tools

I want to start with something I noticed, not something I believe.

In rooms with executives, I have watched the same thing happen more than once. These are people who measure with real discipline. They can tell you their cost per transaction, their productivity per team, their adoption curve, their uptime to the decimal. Measurement is not foreign to them. It is the native language of how they run things.

Then I ask one question. How do you measure whether your organization actually trusts its AI?

And the room goes quiet.

Not a guilty quiet. Not an accusation landing. Just a pause, the particular silence of a question that has never been asked in that form before. Someone will eventually offer that they run model accuracy reports, or that they have a governance committee, or that there is an audit somewhere. All true. None of it an answer to the question I asked. The question was about trust, and there was no number to reach for.

I am not going to pretend that silence proves anything. One observation is not a finding. But it made me curious, and curiosity is a better place to begin than conviction.

The thing that made me curious

Here is what puzzled me about that silence.

We spend enormous effort measuring what our AI systems do. Their accuracy, their latency, their throughput, their cost. Whole dashboards exist for it. But we spend almost nothing measuring the thing that actually determines whether any of that effort matters: the confidence with which human beings decide to rely on the system. Whether they lean on it, or quietly work around it. Whether they trust it.

That struck me as odd. Because trust is not a soft afterthought in these systems. It is the hinge everything turns on. A model can be brilliant and go unused because no one believes it. A model can be mediocre and be over-trusted into a disaster. The performance of the model and the trust placed in it are two different quantities, and only one of them shows up on the dashboard.

So the question I could not put down was simply: why? Why do we measure the machine so carefully and the reliance on it not at all? Not because anyone decided trust was unimportant. Everyone says the opposite. So why the gap between what we say matters and what we actually measure?

A lens, from an unlikely place

I found a useful way to think about that gap in a book most people read for other reasons.

John Doerr popularized a deceptively simple idea in Measure What Matters. On the surface it is a book about OKRs, about goals and key results. But the deeper idea underneath the framework is this: OKRs were never really about metrics. They were a mechanism for making invisible priorities visible. The act of measuring something is the act of declaring, publicly and to yourself, that it matters. And the reverse is quietly true as well. What you never measure, you have treated as if it does not matter, whatever you say about it in your principles.

That reframed my question with some force. If trust is what decides whether an AI system gets adopted, questioned, overridden, or abandoned, then by any reasonable account it matters as much as anything on the dashboard. So why is it still handled as an intuition, a feeling in the room, rather than as something observable? Not because it is unimportant. Perhaps because we have not known how to see it.

Trust behaves like a latent variable

Here is the shift that, for me, changed the whole problem. And it is a small shift in language that turns out to be a large shift in method.

The instinct is to say trust should be measurable and go looking for the meter. But that is the wrong sentence. The right one is this: trust behaves like a latent variable.

That phrase comes from the sciences that have spent the longest wrestling with exactly this difficulty, the difficulty of studying something real that you cannot observe directly. And once you say it that way, the problem stops being strange and becomes familiar, because it is a problem those fields solved long ago.

Think about what we already measure this way, without blinking. Intelligence is never observed directly; it is inferred from performance across many tasks. Depression is never observed directly; it is inferred from a pattern of signs. The same is true of economic confidence, of quality of life, of customer satisfaction. Not one of these is read off an instrument. Every one of them is real, consequential, and studied rigorously. And every one of them is inferred from things you can see, rather than measured head-on.

Trust belongs in that family. You will never point a sensor at trust and get a reading. But that has never been how latent things are measured. They are measured through their traces.

What would trust leave behind?

So I stopped asking how to measure trust, and started asking the question a researcher would ask instead: if trust cannot be seen directly, what visible evidence would it leave behind?

This is the move that turns a slogan into science. You do not measure the hidden thing. You ask what the hidden thing causes, and you measure that.

So suppose trust in an AI system rises. What should we expect to see? People should override the system less often when it is right, and appropriately when it is wrong. Escalations should shift in character. The rate at which recommendations are accepted should change. The time spent re-verifying the system’s output should fall. Appeals, interventions, audit exceptions, all of these should move in patterns consistent with a change in reliance. And if trust falls, the same signals should move the other way.

Notice what has happened. Without ever claiming to measure trust directly, I now have a list of things I can observe: override rate, escalation frequency, recommendation acceptance, time to verification, human intervention, appeal rate, audit exceptions. These are not trust. They are the behavioral exhaust of trust, the visible residue a hidden quantity leaves in the operational record. And measuring the consequences of a latent variable is precisely how latent variables have always been studied.

I want to be careful here, because this is where rigor matters and where it is easy to overreach. Any single one of these signals can move for reasons that have nothing to do with trust. That is exactly why you do not lean on any single one. You look at the pattern across many, the way a diagnostician reads a panel of markers rather than a single number, and you reason from the pattern to the hidden state underneath. The mathematics for doing this well, for inferring a hidden quantity from noisy signals and for tracking how it moves over time, is mature and unglamorous and mostly borrowed from fields that have done it for decades. It does not need to be on the surface of this essay. It only needs to exist, and it does.

One more thing about trust: it does not hold still

There is a wrinkle that makes this harder than the classic textbook version, and it is worth naming because it changes what “measuring” even means.

Intelligence, once measured in an adult, is fairly stable. Trust is not. Trust in an AI system moves, and it moves because the world the system operates in moves. The data shifts. The users adapt. The conditions the system was validated under quietly stop holding. So trust is not only a hidden quantity; it is a hidden quantity in motion.

And that has a consequence I find genuinely important. If trust moves, then measuring it once tells you almost nothing about where it will be next quarter. A single reading is a photograph of a moving thing. The same measured value can mean opposite realities depending on the direction it arrived from: a system whose trust is recovering and one whose trust is collapsing can pass through the identical number on the way to very different fates. Only a sequence of readings, a trajectory, can tell them apart. Which suggests that if trust is worth measuring at all, it is worth measuring continuously, not certified once and filed away.

Why this matters to the person accountable

Let me connect this back to the executive in the quiet room, because this is not an academic puzzle for them. It is a future liability.

When an AI system fails, and eventually one will, the questions that arrive are all retrospective. Was this system trustworthy? Were you watching? What state was it in, and when did you know? These are questions about a quantity over time. And they can only be answered if that quantity was being observed as it moved, because a trajectory cannot be reconstructed after the fact. You cannot go back and take a measurement you never took. The evidence either exists because someone was collecting it all along, or it does not exist at all.

That reframes the quiet in the room. The silence was not a small gap in reporting. It was the absence of the one record that, on the hardest day, everyone will reach for and no one will find.

Where this is taking me

I will be honest that this line of thinking is a question I am still inside of, not a conclusion I am handing over. But it has led me somewhere specific, and I will name the direction even though I am not claiming the destination.

The question I keep returning to is whether executive trust in AI can be treated as a measurable construct, operationalized not through surveys and self-report alone, but through the behavioral, operational, governance, and outcome signals that a system generates as it runs, tracked over time as they evolve. Not to reduce trust to a single tidy number, but to make a hidden and consequential thing visible enough to reason about, argue over, and act on before a failure rather than after.

I do not think the next real advance in AI governance will come from larger models. I think it may come from better measurement. Not measurement of what the machine can do, we are already good at that, but measurement of the thing we keep saying matters most and keep leaving off the dashboard.

So I will end where a researcher should end, with the question rather than the answer.

Share

If trust is what matters most, what evidence should organizations be collecting, starting now, to know whether they actually have it?

I do not think we have a good answer yet. I think it is the right question. And I would rather leave you holding a better question than a borrowed conviction.

Until next Tuesday….



Suneeta Modekurty
Founder & CEO | SANJEEVANI AI

Image created by AI tools

I was invited recently to speak with a room of product leaders and senior professionals as part of AI in Motion, an initiative built to bring practitioners face to face with the harder questions AI is forcing on all of us. I had prepared to talk about something I have been circling f…

Read more

Image created using AI tools

There is a moment in every AI deployment that nobody schedules and nobody sees coming. It is the moment the system does something no one asked it to do, in a place no one realized it could reach, and the organization discovers, all at once, that it never actually knew what it had …

Read more

Image created using AI tools

On a Monday in June, Anthropic released the most capable model it had ever built. By Friday evening, it was gone. Not slowed, not limited to certain regions. Gone, for everyone, everywhere.

I have been sitting with that all weekend, and I want to share where my thinking landed, because I don’t think the lesson is the one the headlines are reaching for.

Here is what happened, told simply. Anthropic released Fable 5, and the model beneath it, Mythos 5. Teams across the industry spent the week building it into real work. Then the U.S. Commerce Department issued an export control directive: these models could not be used by any foreign national, anywhere, including foreign-born employees working inside U.S. offices (and you can imagine why it matters to me, and to you, if you are foreign-born). There was no clean way to honor that order in real time, so the only path to compliance was to switch the models off for everyone. And so they did. The most capable thing on the market went dark on a Friday night, because of a decision no customer was part of.

I want to be careful with the facts, because this story is being told in several versions, and some carry more confidence than the record supports. The verified spine is narrow. A government directive, citing national security, tied to the model’s cyber capabilities and a jailbreak technique. The company disagrees, calls it a misunderstanding, and says it is working to restore access. The more dramatic threads, who called whom, who set it in motion, are still unsettled. I would rather build on what is solid than on what is satisfying.

What is solid is enough to learn from.

This fits in an arc

Every infrastructure we now take for granted went through the same passage. There was a season when it was new and astonishing, and we built on it before we fully understood what we were leaning on.

Be it Electricity, the early eb or the Cloud.

Each one moved from “remarkable capability” to “thing we assume is simply there.” And each one, somewhere along that path, had a moment that reminded everyone it was not as solid as it felt.

Frontier models are early in that arc. They are astonishing, they are everywhere, and we have started to treat them the way we treat electricity. Something that is just on. Friday was a reminder that we are not there yet. The most capable models are still the newest part of the stack, and the newest part is always the part most exposed to forces that have nothing to do with engineering.

That is not a criticism of any one company. The same structure would hold for any frontier model from any provider. It is simply where we are in the arc.

A layer above

When a company adopts a model, it negotiates the things it knows how to negotiate, namely, uptime, latency, committed spend, data handling, support etc. Those terms feel like the boundaries of the relationship, and most of the time they are.

What this week showed is that there is a layer sitting above all of that and that is regulatory, geopolitical, national. And that layer does not read your service agreement. When it moves, the terms you negotiated still hold, they just stop being the thing that decides the outcome. The capability can be withdrawn by a force you have no seat across from.

This is worth naming plainly as something the field is now ready to see clearly.

We have understood model risk mostly as “will it perform.” This week added a second dimension: “will it remain available to me, and who decides that.” Both are real. We have simply been measuring one and assuming the other.

Why “it will come back” is not the lesson

It is tempting to wait this out. Access may well be restored. The disagreement may resolve, and the model may return as if the week never happened. And then the easy move is to file it under “strange few days” and carry on.

It’s worth gently resisting that. The specific outcome is not the lesson. The lesson is that the event was possible at all. A capability that hundreds of millions of people were using could go to zero overnight, lawfully, with no warning. Whether it stays gone for three days or three months does not change what it taught us about the shape of the risk. A thing that can happen once on a Friday can happen again on a Tuesday.

The narrow lesson is “this model carried risk.” The useful lesson is “leaning on any single model this completely carries risk.” One sends you shopping for a different vendor. The other invites you to look honestly at how you have built.

A question worth pondering over

So here is the question I have been thinking over, and I offer it as a genuine prompt rather than a rhetorical one.

If your primary model went dark this Friday, not slower, dark, what happens on Monday?

Picture it concretely. Which workflows stop. Which customers notice. How long before something else carries the load, and how much harder is it carrying. Do you know the answer already, or is it something you would discover in real time, under pressure, the way teams often discover their backups only when they finally reach for them.

Most organizations cannot answer this cleanly yet, and I don’t think that reflects poorly on anyone. The question simply was not urgent until this week. The capability was too good and too available to imagine it absent. That is exactly the condition under which dependence gathers quietly, when the thing we depend on feels too solid to question.

What I think resilience actually asks of us

I don’t believe the answer is fear, or stepping back from frontier models, or treating capability as a liability. Fear and stepping back is never a solution to any problem. The capability is real and the value is real. The answer is quieter than that, and frankly harder. It is knowing your own exposure well enough to act on it before the moment forces your hand.

That means being able to say, with specifics, where you are concentrated. It means having a fallback you have actually tested, not one you assume will be there. It means treating “what is our dependency profile” as a question you can answer at any time, rather than one you reconstruct in a hurry. None of this is dramatic. It is the difference between an organization that has a plan and one that becomes the plan, improvised live, while the screens turn red.

In its own backhanded way, Friday was a gift. It took a quiet, structural risk and made it loud, and dated, and undeniable, at a cost that for most of us belonged to someone else. That is the least expensive way to learn an expensive lesson. The expensive way is to learn it when the model that goes dark is the one your own business is standing on.

The model came back, or it will. The question it asked is going to stay with us a while longer.

What is your fallback plan if your primary model goes dark on a Friday? I would truly like to know how you are thinking about it. Reply and tell me.

Until next week…

Founder and CEO | SANJEEVANI AI

Image created using AI tools

One of the most dangerous AI failures inside companies today does not start as a failure. It starts as efficiency.

You put a predictive model next to a decision. It is fast. It is cheap. It is right often enough. So you lean on it a little more each week.

Then something quiet happens. The…

Read more

Image created with AI tools

In September 2025, Starbucks released a short promotional video to celebrate the launch of an AI-powered inventory system that the company had built in partnership with the computer vision startup NomadGo. The tool was positioned as a centerpiece of CEO Brian Niccol’s “Back to Starbucks” turnaround, a strategy designed to address the persistent product shortages that had been quietly eroding customer experience and same-store sales for years. The video showed a barista walking through a back room with a handheld tablet, sweeping the camera across shelves of milks and syrups while the system tagged and counted each item in real time. In one of the frames of that very video, the system failed to register a bottle of peppermint syrup that was sitting on the shelf in plain view, surrounded by other bottles that the system did correctly identify. Nobody at Starbucks caught the error before the video shipped, the blog post went live, and the rollout began across more than eleven thousand North American stores.

Eight months later, in May 2026, Starbucks quietly retired the system across the entire fleet, the original blog post was deleted from the corporate site, and the promotional video was pulled from circulation. The story made the trade press as a tidy AI failure narrative, with most coverage focusing on the technical embarrassment of a system that could not reliably distinguish oat milk from regular milk. What almost none of the coverage took seriously was the workforce story sitting underneath the technical one, and I want to tell that part here because I think it is the part that actually matters for every leader trying to navigate this moment.

The Starbucks partners, the workers on the floor who interact with these systems every day, did not trust the AI from very early in the rollout. They scanned the shelves with the tablet because they were required to, they watched the system return its counts, and then they quietly recounted by hand and entered the corrected numbers into the inventory log. They protected the stores from the AI’s errors for nine months by absorbing the extra workload onto themselves, working a second shift of verification on top of the work they were already doing. They are the reason the failures stayed mostly invisible to customers and to corporate leadership until the system was finally pulled, and they are also, in the same breath, the people the broader industry narrative is currently lining up to lay off in the name of AI productivity. That contradiction sits at the center of the AI adoption wave, and I want to name it as clearly as I can in what follows.

The Wrong Frame

The dominant story in the current AI moment is that humans and machines are competing for the same jobs, with the AI either taking the job from the human or the human keeping the job until the AI is good enough to take it. Either way, the relationship is framed as a contest with one winner and one loser, and the entire vocabulary of “AI productivity” has been built on top of that framing. This frame is wrong both technically and organizationally, and the Starbucks case shows you exactly why with a level of clarity that few cases offer.

The AI inventory tool did not do the partners’ job, even on the days when it worked. It did one slice of the partners’ job, which was the visual identification of products on a shelf, and it did that slice badly under the operational conditions of a real back room. The other slices of the job, including knowing yesterday’s shipment patterns, knowing which products burned through fastest during the morning rush, knowing which carton was tucked behind another because the closing shift had restocked in a hurry, and owning final accountability for the count when the day’s numbers were reconciled, were never part of what the AI could do and were never part of what the system was designed to do. Those slices remained with the human partner, who now held less authority over the visible counting work and the same responsibility for the eventual outcome, which is the worst possible position to put a worker in if you actually want the system to succeed.

This is not automation in any meaningful sense of the word. This is cognitive load transfer dressed up in the vocabulary of cost reduction, where the easy and legible part of a job gets handed to a machine while the hard and illegible parts get concentrated onto fewer remaining people who now have less context, less authority, and less protection from the consequences of the machine’s mistakes. The conversation we should be having is not whether to lay off the inventory counters because the AI can count, but rather what the expanded human role looks like around a partially automated process, and how many people we need in that expanded role for the system as a whole to actually work. That question is almost never asked in the rooms where AI procurement decisions get made, and so I want to ask it here with as much specificity as I can.

What If: A Manual Monte Carlo

Before I lay out the scenarios, let me say what I mean by a manual Monte Carlo. In quantitative finance and in operations research, a Monte Carlo simulation is a method of exploring possible futures by running the same model thousands of times with different inputs and watching the distribution of outcomes that emerges from the variability. You cannot do this on paper at scale, but you can do a slower and more deliberate version of the same thinking by hand, by asking what-if questions one at a time and walking each scenario out to its consequences before deciding which path to actually take. This is the kind of exercise that every leadership team should be running before they sign an AI contract, and the absence of this exercise is one of the most consistent features of the AI failures we have seen so far.

Image generated using python code by the author

Let me run five of these scenarios for the Starbucks case, not as predictions and not as numbers I could defend inside a formal model, but as the kind of structured thinking that the rollout itself appears to have skipped. I have begun to refer to this approach as a manual Monte Carlo for AI governance decisions, and the five scenarios that follow are the practical instrument I use when thinking about whether a given AI deployment is genuinely ready to ship into the operational world it will actually have to survive in.

The first scenario asks what would have happened if Starbucks had kept every partner on the floor and added a dedicated AI oversight team alongside the rollout. Imagine a team of perhaps fifty to one hundred people whose only job is to audit AI output against ground truth across the eleven thousand store fleet, sampling stores on a rotating schedule, reviewing confidence score distributions, identifying model drift before it becomes catastrophic, and feeding human corrections back into a retraining pipeline that updates the model on a regular cadence. The annual cost of such a team would be real, perhaps in the range of five to ten million dollars when fully loaded with engineering support and infrastructure, and it would be dwarfed by the cost of a failed nine-month rollout across eleven thousand locations, even before you begin to count the brand damage, the deleted blog post, the loss of internal credibility for the next AI initiative, and the harder-to-measure erosion of trust between partners and the corporate technology function. The deeper point, the one that matters more than the headcount or the budget, is that an oversight team of this kind functions as a forcing function for everything else the deployment should have included from the start, because the very existence of a paid oversight function makes engineering hygiene mandatory rather than optional. Without a budget line for oversight, the engineering team naturally optimizes for the demo and the ship date, since nobody inside the company is being paid to demand the audit trail, the retraining cadence, the rollback authority, or the operational testing protocol. With a budget line for oversight, the team’s first ninety days of work would surface exactly those missing pieces and would force the rest of the organization to build them, because the oversight function cannot do its own job without them. My own view, which I hold with some confidence after watching enough of these rollouts up close, is that this first scenario is the single highest-leverage intervention of the five I am about to walk through, because it creates the institutional pressure that pulls the other four into place behind it almost automatically. If Starbucks had committed to this one structural choice alone and had held the rest of the rollout to whatever pace the oversight team could actually validate, I believe the system would still be running today in a meaningfully better form than it ever achieved during its actual nine-month life.

The second scenario asks what would have happened if the partners themselves had been trained to interpret the AI’s confidence scores rather than being shown only the final classification. A two-day training program could have taught every partner in every store what a confidence score is, what it means when the tablet reports that an item was identified with 0.62 confidence versus 0.94 confidence, and how to decide whether to trust the AI’s count or recount manually based on that signal. The system would stop pretending to be certain when it was not, the partner would have a clear and defensible rule for when to intervene, the second shift of silent verification would become a deliberate and trained workflow rather than a hidden burden, and the partner would emerge from the deployment more skilled and more valuable to the company than they had been before it began. The analysis that needs to be done honestly here, however, is the one that asks whether the training alone would have changed actual behavior in the morning rush of a real store, and my view is that it would not have, at least not by itself, because reading a confidence score does no good if the worker has no operational permission to act on it. If the partner is still being measured on completing back-of-house tasks within a fixed time window, if the manager is still scheduling the shift around an assumption that inventory takes thirty minutes rather than the forty-five minutes it would take with proper verification, and if the performance review structure still rewards speed over accuracy, then the partner will see the 0.62 confidence score and will accept the count anyway, because slowing down to recount is a behavior the organization has not actually made room for. The training has to be paired with management metrics that explicitly reward verification over speed, and with shift scheduling that accommodates the time verification requires, otherwise the training becomes a polite fiction layered on top of an unchanged operational system. My opinion on this scenario is that it is useful as a complement to the first one but dangerous as a standalone fix, because it places the cognitive burden of catching AI errors back onto the worker without giving them the time, the authority, or the metric structure to discharge it well, and the worker is left in essentially the same position they were already in during the actual rollout, except now they are also responsible for understanding a confidence score on top of everything else they were already doing silently.

The third scenario asks what would have happened if every AI rollout in the company had been paired with a human oversight structure scaled to the size of the deployment, in the way that every other safety-critical system in the modern economy is paired with its corresponding human oversight function. Airplanes have pilots in the cockpit and air traffic controllers in the tower, power grids have local operators and regional supervisors who coordinate across the network, hospitals have clinicians at the bedside and quality review boards in the institutional governance layer, and each of these structures exists because we have learned over decades that complex technical systems do not stay safe or accurate without continuous human attention to their behavior. AI deployment, with stakes that increasingly rival these other systems, currently ships without any analogous oversight function in the vast majority of cases, not because the need is unknown but because nobody put a line item for it in the original procurement proposal and no buyer thought to ask why it was missing. The historical analysis that needs to be done honestly here is that each of these oversight structures came into existence reactively rather than proactively, after the industry had paid in lives or in losses for not having the structure already in place, with the Tenerife runway collision shaping the modern shape of air traffic control, the Three Mile Island incident shaping the modern shape of nuclear plant operations, and the Institute of Medicine reports of the late 1990s shaping the modern shape of hospital quality and safety. AI as a category of technology is currently in what I would describe as the pre-Tenerife phase of its lifecycle, by which I mean that the catastrophic failure which will eventually mandate the oversight structure has not yet happened in a form severe enough to force regulatory action across the entire industry, and the rollouts of the next two to three years are quietly building toward the kind of incident that will produce that mandate. My opinion on this scenario, and the one I would most want a board of directors to sit with for the longest time, is that the oversight structure is historically inevitable and that the only meaningful executive choice available right now is whether to build it voluntarily and proactively with room to design it thoughtfully and capture its benefits, or to be forced into building it reactively later under regulatory pressure and after the company has already become the cautionary tale that other companies study. The executives who choose voluntarily now will be the ones cited in five years as the responsible early operators of this technology, and the ones who skip it will be in the case study deck that the next generation of business school students will be required to read.

The fourth scenario asks what would have happened if the workforce story had been told to the partners and to the public in honest terms from the start. Imagine the announcement reading something like this: we are deploying AI in our back rooms, we are not reducing headcount in connection with this rollout, we are expanding the role of every partner to include AI verification and feedback, and we are hiring a new class of AI quality engineers to support that expanded role. This is the story that most companies are unwilling to tell because it does not fit the cost-cutting deck the CFO needs for the next earnings call, but it is also the story that would have given the partners a reason to be invested in the system’s success rather than skeptical of its motives, and it would have surfaced the operational realities of the back room into the design process months before the system shipped. The harder analysis that has to be done honestly here is the one that asks why no executive is currently telling this story even when they privately believe it, and my view is that the answer is not a personal failing on the part of the executives but rather a coordination problem at the level of the market itself. The current investor narrative around AI rewards companies that signal headcount reduction in connection with AI deployment, regardless of whether the AI is actually replacing the underlying work, which means the chief executive who tells the honest story takes a real stock price hit from the same investors who are funding the AI deployment in the first place. This is the trap that most public company executives are sitting inside right now, and the trap will not release until enough boards begin to realize that the dishonest story is what is producing the Starbucks pattern at the operational layer, and that the operational pattern is what is eventually destroying the value the AI rollout was supposed to create in the first place. My opinion on this scenario is that it is the hardest of the five to execute even when leadership privately wants to do it, because it requires bucking the entire current investor mood at the same moment that the investor mood is funding the AI strategy, and that this scenario will become executable at scale only when enough articles like the one you are reading right now help to seed the realization that is currently missing from the boardroom conversation. The piece in your hands is, in that limited sense, a small contribution to making this fourth scenario eventually possible.

The fifth scenario asks what would have happened if executives had drawn the line at the contract stage rather than after the failure was already visible. No AI deployment should be approved without explicit answers to a small number of governance questions, including who is accountable when the AI is wrong, what the confidence threshold is for autonomous action, what the rollback trigger looks like and who has the authority to pull it, who owns the human oversight team and where they sit in the org chart, what the retraining cadence will be and what the feedback loop is from worker corrections back into the model, and what the operational testing protocol is for the conditions under which the system will actually be used. Most AI contracts today are signed without any of these answers on the table, with the procurement process treating AI as if it were ordering office furniture, and the predictable result is that the answers get discovered the hard way, in production, after the system has already been deployed at scale. The structural analysis that has to be done honestly here is that the reason these questions almost never get asked in procurement is not because the buyer does not care, but because the buyer does not yet have the framework to know which questions are the important ones, the vendor does not volunteer the questions because they extend the sales cycle, and the legal team is checking standard contractual boilerplate rather than AI-specific governance language. Until procurement teams across industries have a shared rubric for AI contract due diligence, every individual deployment will reinvent these questions on its own and most will reinvent them badly or incompletely, which is the pattern we are watching play out in real time across the early enterprise rollouts of this technology. My opinion on this scenario is that it is the place where regulation will eventually arrive, because the market is not going to solve the problem on its own at anything close to the speed at which the technology is being deployed, and we are already seeing the early shape of that regulatory move in places like the recent FDA guidance for the use of AI in pharmaceutical quality systems, where the agency has now stated on the record that the company holds the liability regardless of whether the failure originated in an AI tool or in a human consultant. The executive who treats AI procurement today with the same diligence they would apply to the hiring of a senior consultant or to the qualification of a critical supplier is doing voluntarily what they will very soon be required to do anyway by their regulators, by their auditors, and by their insurers, and the gap between the voluntary adopters and the forced adopters is going to be one of the defining competitive lines of the next three years.

These five scenarios are not equally easy to execute, as the analysis I have walked through tries to make plain, and I want to be honest about the fact that the first one is the structural lever that pulls the others into place, the second one is dangerous in isolation though valuable as a complement, the third one is historically inevitable and the only real question is voluntary or forced, the fourth one is the hardest cultural lift because it requires bucking the investor narrative at the moment that narrative is funding the deployment, and the fifth one is where regulation will eventually arrive whether the industry is ready for it or not. What is shared across all five, and what makes them worth thinking about together rather than choosing among in isolation, is that each of them costs more in the short term than the path Starbucks actually took, and each of them, when you sit with the math honestly, costs far less in the long term and produces an AI deployment that actually achieves the operational outcome the technology was bought for, without quietly transferring the failure modes onto the workforce the company is simultaneously planning to lay off. The math is not the obstacle here. The thinking is.

The Roles, Properly Defined

The framing I want to argue for, and the framing that should sit at the center of every AI deployment decision going forward, is that humans and machines do not compete for the same role in a well-designed system because they are structurally suited to different roles. Machines are extremely good at pattern recognition across very large numbers of inputs, at repetition without fatigue across long time horizons, at computation that exceeds human speed by many orders of magnitude, at consistency on inputs that resemble the data they were trained on, and at operating across all twenty-four hours of the day without the breaks that human bodies require. These are real and valuable capabilities and there is no honest case for ignoring them in modern operations. Humans, in turn, are extremely good at integrating context that the machine never saw and could not have seen, at exercising judgment on novel situations that fall outside the training distribution, at maintaining calibrated awareness of their own uncertainty and communicating that uncertainty honestly to others, at making ethical decisions where the stakes are not encodable in a loss function, at holding accountability when the system errs in ways that affect real customers and real outcomes, at remembering past failures and the causes that produced them so that the same failure does not happen again, and at the deeply skilled work of training and supervising and correcting the machines themselves.

Notice what happens to the human role in a system that takes both lists seriously. As the machines do more of the work they are well suited for, the human role does not shrink, it changes shape and in most cases becomes more demanding rather than less. The human becomes the ringmaster who coordinates the system, the watchman who monitors its behavior, the trainer who feeds it new data and corrects its drift, the verifier who checks its outputs against ground truth, the loop-closer who turns every failure into an institutional learning, and the accountable party who answers for the system when something goes wrong in front of a customer or a regulator. These roles are not less skilled than the work the AI displaced, they are more skilled and more cognitively demanding, and they require deliberate investment in training programs and in headcount budgets and in career paths that did not exist in the pre-AI version of the organization.

If you are deploying AI seriously, you should expect your workforce composition to shift in shape rather than to shrink in size. You will have fewer people doing the specific task the AI now performs, and you will have more people doing the work the AI cannot do, which includes the supervision of the AI itself and the integration of its output into the broader context of the organization’s actual operations. A board of directors that approves an AI deployment with simultaneous layoffs in the same department is not making a productivity decision, regardless of how the decision is dressed for the earnings call. They are telling you plainly that they do not understand what they have just bought, and the cost of that misunderstanding will land somewhere in the organization eventually, usually on the customers and the workers who remain.

Human-Machine Synergy

In October 2024, I published a book titled The AI-Human Synergy: A Data Scientist’s Vision for the Future, in which I argued that the future of work is not a story of humans being replaced by machines but a story of humans and machines entering deliberate and complementary partnership, with each side doing what each is genuinely good at, each side compensating for the other’s blind spots, and each side accountable for the part of the work that only that side can do. The argument was meant to be a corrective to a public conversation that had already begun to slide into a binary framing of replacement versus survival, and it was rooted in the observation, from my own twenty-five years across education and research and applied data science, that the systems which actually work in the real world are almost always the ones designed around this kind of partnership rather than around the fantasy of full automation.

We are not yet living in the world that book describes. We are living instead in a transitional moment where companies are buying AI as if it were a workforce replacement, deploying it as if it were proven, laying off workers as if the deployments had succeeded, and then quietly retiring the systems eighteen months later when the failures become impossible to hide any longer. The Starbucks case is one example of this pattern, and it will not be the last one. There are several more in motion right now that will reach the trade press over the next twelve months, and the underlying dynamics will be recognizable in every one of them once you know what to look for. In the broader work I am leading at SANJEEVANI AI to build quantitative trust measurement infrastructure for enterprise AI deployments, this five-scenario lens is one of the components that feeds into a larger architecture for evaluating whether an organization is genuinely ready for the AI it is in the process of buying.

What I am calling for in this article, and what I think every executive in a position to draw this line should be calling for in their own organizations, is a different posture toward AI deployment that is neither anti-AI nor pro-layoff but rather pro-design, in the sense of designing the human-machine system on purpose rather than allowing it to emerge by accident from the collision of vendor sales decks and CFO spreadsheets. Defining the roles deliberately, building the oversight structure to match the deployment size, training the humans for the new and more demanding roles they are being asked to occupy, and hiring more of them in different roles to do the work the AI cannot do, all of this is the actual work of what I have been calling human-machine amity, and it is harder than firing people because it requires the organization to think clearly about what its own jobs actually are. It is also, and this is the part that should matter to the people who hold the budgets, the only path that delivers the productivity gains the technology is genuinely capable of producing.

The Starbucks partners knew what their job actually was, the AI did not know what the job was because it had never been told and could not have been told within the structure of the deployment as it was designed, and the executives somewhere in the middle of those two ends of the system mistook the visible surface of the work for its actual substance. That is the mistake that is being made at scale, in industry after industry, in the rollouts happening right now in 2026, and it is a mistake that we have every technical and organizational capability to correct if we are willing to do the harder thinking it requires. The next phase of this conversation, and the one I believe the field has to move into over the next two to three years, is not just better thinking about these tradeoffs but the construction of measurable infrastructure that quantifies them before deployment rather than discovering them after, and that direction of work is exactly where I am committing my own time. We can do this differently, and given what is now on the line for workers and for customers and for the credibility of AI as a category of technology, I would argue that we have to.

Read this, ponder it, sit with it, and bring it into the next AI conversation you find yourself in this week, whether that is a board meeting, a procurement call, a hallway conversation with a worker on your team, or a quiet moment of your own thinking. I am writing this as a businesswoman who is building toward a future where AI and humans work in deliberate partnership, not as a critic standing outside the field throwing stones. The companies that get this right over the next three years will be the ones still standing in 2030, and the work of getting it right starts with the kind of structured thinking we have just walked through together. Until next week.

Suneeta Modekurty
Founder, SANJEEVANI AI

Image created using AI tools

When a company lays off nearly a quarter of its staff, the narrative is usually one of retreat. But ClickUp’s recent 22 percent headcount cut was different. It was an aggressive, forward-leaning restructuring designed to answer a single, brutal question: Who deserves to survive in the age of AI?

The people who stayed, the survivors, were not kept because they knew how to write basic prompts or use chat interfaces. They were kept because they possessed a capability that most organizations cannot even define, let alone measure: the ability to direct, audit, and take absolute operational accountability for machine output.

This represents a massive, necessary transition from AI Literacy to AI Readiness.

Most executives treat AI adoption as a soft skill, rolling out licenses and calling “basic prompting” a success metric. But this approach creates a black box. When you cannot measure what your AI tools are actually producing, you cannot enforce accountability. You end up with an unmanageable explosion of automated noise. ClickUp’s restructure is the first industrial-scale proof that AI adoption without structural measurability is a dead end. It is a loud wake-up call for how we define the work of the future.

The Myth of Universal Productivity

In May 2026, ClickUp, a software company valued at $4 billion, announced a 22 percent headcount reduction. But unlike the standard tech layoffs of the past few years, which were framed as defensive, cost-cutting measures, ClickUp’s CEO, Zeb Evans, framed this cut as a proactive, structural bet.

Evans wrote on X that “the business is the strongest it’s ever been” and that “this wasn’t about cutting costs.” The goal was to completely rebuild the company around what he calls a “100x organization.”

To incentivize the transition, ClickUp threw traditional compensation structures out the window, introducing $1 million cash salary bands for the employees who remained, provided they could demonstrate “100x impact” by building and managing AI systems.

The mainstream headline was the layoff. The real story is the structural thesis underneath.

Evans challenged one of the most sacred assumptions of the generative AI era: the idea that AI tools automatically make everyone more productive. He argued the exact opposite.

In a traditional workflow, giving AI tools to junior or untrained staff does not speed up an organization. It creates an explosion of raw volume. Evans pointed specifically to companies celebrating 500 percent increases in pull request volume without matching customer outcomes, calling this “the great reckoning of AI coding.”

But someone has to review that output. Someone has to fix the subtle, confident errors the AI made. When that mass of automated volume collides with senior staff, it creates a massive review bottleneck. The senior people end up spending all their time auditing, rewriting, and debugging AI-generated noise.

As Evans bluntly wrote: “AI makes the best engineers wildly more productive, and everyone else using AI slows these engineers down... More code is just another bottleneck.”

This is the great paradox of the agentic era. When the cost of generating work drops to zero, the cost of evaluating that work becomes the most expensive line item in your business.

And that is where the line between AI literacy and AI readiness is drawn.

AI Literacy vs. AI Readiness

Most corporate training programs are designed to build AI Literacy. They teach employees what a Large Language Model is, how to open a chat interface, and how to write basic prompts. It is cognitive, basic, and tool-centric.

AI Readiness, however, is operational. It is the human capability to direct, judge, and take absolute accountability for automated systems.

When a company runs thousands of AI agents internally, it doesn’t need people who can write. It needs people who can manage. It needs what ClickUp calls Agent Managers: workers who can automate their own manual tasks, build systems around those automations, and act as the rigorous human filter for the machine’s output.

To build an organization of Agent Managers, companies must cultivate three distinct human capabilities.

1. Direction: From Prompting to Orchestration

An AI tool does exactly what you tell it to do. Therefore, the harder and more nuanced the work, the more critical the telling becomes.

The AI-Literate worker prompts: “Write a marketing email for our consulting services.” The result is a generic, instantly deleted block of corporate jargon.

The AI-Ready worker orchestrates: “Write a 200-word email to a small business owner who has heard of AI but fundamentally distrusts it. Open by directly validating that trust barrier, and close with a single, low-friction question they can answer in 30 seconds.”

The core skill here is not writing. The skill is system design. It is the ability to deconstruct a highly complex, intuitive human process, isolate its underlying variables, and translate them into a structured instruction set that an agent can execute flawlessly.

For decades, corporate structures have rewarded people for doing the work. Suddenly, we need people who can describe the work in such vivid, mechanical detail that a machine can replicate it. That is a rare, highly strategic skill. Traditional prompt-engineering workshops do not teach it because it requires deep domain expertise, not just software knowledge.

2. Judgment: The Review Bottleneck

Because AI tools produce highly confident, plausible-sounding answers that are frequently wrong, the ultimate bottleneck is no longer production. It is review.

The readiness skill here is knowing when to trust the output and when to interrogate it. This skill cannot be installed via a corporate slide deck. It is the slow, painful result of having done the manual work yourself, badly, for years.

It is what a senior software architect brings to reviewing AI-generated code, or what a veteran forensic accountant brings to an AI-run reconciliation. They do not look at the 99% that is right. They have the instinct to find the 1% that is catastrophically wrong.

Companies that lay off their expensive, senior experts while keeping only their cheap, “AI-fluent” juniors are going to discover their lack of judgment the hard way.

They will find themselves drowning in flawless-looking, broken work.

AI literacy lets you generate the code. AI readiness gives you the wisdom to realize that code should never go to production.

3. Ownership: The Air Canada Rule

An AI agent does not get fired when a calculation is wrong, and it does not get sued when a client is misled. The human in the chair does.

This is the psychological side of AI readiness that never makes it into vendor product demos. It is the willingness to sign your name to output you did not write, defend it to a client when it is challenged, and accept the professional and legal consequences when it fails.

This isn’t theoretical. In February 2024, the British Columbia Civil Resolution Tribunal ruled in Moffatt v. Air Canada that the airline was liable when its customer-facing chatbot promised a passenger an unauthorized bereavement refund. In its defense, the airline argued that the chatbot was a “separate legal entity” responsible for its own misinformation. The tribunal rejected the argument outright, ruling that the company was entirely accountable for the systems it chose to deploy.

Somebody at Air Canada owned that mistake, whether they wanted to or not.

Most companies have still not defined who legally and operationally owns their AI’s output. They will figure it out the first time a customer pushes back, and the lesson will be incredibly expensive.

The New Architecture of Work

If ClickUp’s thesis is correct, the transition to AI readiness will force a radical redesign of traditional corporate roles. Evans has outlined three distinct classes of ready workers:

The Builders. These are the 10x engineers and product designers. They are no longer typing lines of code or drawing static mockups. They are acting as system architects, directing fleets of agents to build, test, and iterate. They spend their time on system design and validation.

The Agent Managers (Systems Managers). These are operational workers who have successfully automated their own manual tasks. Instead of being displaced, they are kept because they possess the institutional knowledge required to run, monitor, and troubleshoot the automated systems they created. As Evans put it: “The people that automate their jobs with AI will always have a job.”

The Front-liners. These are the human-to-human connection points. In an era where AI can generate infinite digital noise, authentic human contact becomes a premium bottleneck. Under ClickUp’s model, customer-facing humans are explicitly protected from automation. They do not use AI to replace meetings. They use AI to automate everything around the meetings, so they can spend 100% of their time focused on real human relationship-building.

Image created with AI tools

Why Readiness Cannot Be Bought

The pattern repeating across the corporate world is a fundamental confusion of terms.

AI Adoption is technical. It is the work of installing software, integrating APIs, and provisioning licenses. Adoption can be bought. You sign a contract, run a launch event, and the software lands on every laptop in the company.

AI Literacy is cognitive. It is the basic understanding of how these tools work. Literacy can be taught via quick workshops and video modules.

AI Readiness is operational. It is the human capability to establish direction, exercise judgment, and accept ownership over automated workflows. Readiness cannot be bought, and it cannot be taught in a 45-minute webinar. It must be built through deliberate, supervised practice on real-world work over months.

This is why so many pilot programs yield zero measurable ROI. They successfully bought adoption, achieved basic literacy, and completely skipped readiness.

What to Do This Week

If you want to know where your company actually stands on the spectrum of AI readiness, run this simple test on Monday morning.

Pick one AI tool your team currently uses. Select one piece of work that tool produced this week.

Then ask these three questions.

Direction. Who wrote the operational instructions that produced this output, and could a different colleague reproduce this exact quality using those instructions alone?

Judgment. Who audited this specific output, and exactly how do they know it is correct?

Ownership. If this output goes to a client and severely backfires, whose name is on the line?

If you cannot confidently answer all three questions for a single piece of work, your company has adopted a tool, but it has not built readiness. You have active software, but you do not have an active system.

Closing that gap is the defining corporate challenge of the next two years. The organizations that build true AI readiness will look unrecognizable from the inside by the end of the decade. The ones that do not will still be running prompt-writing workshops, staring at empty dashboards, wondering where their ROI went.

Sources

1. Zeb Evans, post on X (May 21, 2026). primary source for the 22% layoff, the “100x organization” framing, and Evans’s direct quotes.

2. Fortune, “Outnumbered: At $4 billion ClickUp, a 3:1 agent-to-human ratio is rewiring work itself” (May 18, 2026). source for the 3,000 internal AI agents and the 3:1 agent-to-employee ratio.

3. StartupHub.ai, “ClickUp’s 22% cut comes with $1M salary bands. Evans calls it the 100x org.”. source for Evans’s “great reckoning of AI coding” critique and the 500% pull request volume reference.

4. The Next Web, “ClickUp cuts 22% of staff, offers $1M salaries in AI restructuring”. source for the Builders / Agent Managers / Front-liners taxonomy.

5. Business Today, “’People who automate jobs with AI will always have a job’: ClickUp cuts 22% of its workforce”. source for the Agent Manager quote.

6. Moffatt v. Air Canada, British Columbia Civil Resolution Tribunal (February 14, 2024). source for the Air Canada chatbot liability ruling.

Suneeta Modekurty | Founder, SANJEEVANI AI | Quantifying AI Readiness

Image created using AI tools

We are AI First, We are using AI, We are leveraging AI across the enterprise. ….

These kind of phrases have been around for a while. They show up in headlines and slide decks and strategy documents. But saying “AI ready” and actually being ready are two very different things.

In this series, I want to stay with a single, uncomfortable question:

Are we simply using AI, or are we genuinely ready for what it does to our decisions, our people, and the communities we serve?

To get there, I am going to stay close to real stories. Some come from the patterns I have heard across more than five hundred conversations I had over past months, with practitioners, leaders, and operators working through AI questions inside their organizations, with details abstracted to protect the people and the work. Others, like the one in this article, are already public. All of them sit at the intersection of three things: a human being in a real situation, an AI system that sounds confident, and an organization that is about to discover what “not ready” really means.

Let us begin with an incident that happened in November 2022.

A traveler in British Columbia named Jake Moffatt opened the Air Canada website to book a last-minute flight from Vancouver to Toronto. He was a private individual; his name only later entered the public record because of the complaint he eventually brought. His grandmother had just died. He needed to be at the funeral. Before he booked the ticket, he asked the airline’s chatbot whether Air Canada offered bereavement fares, and if so, how to claim one.

The chatbot told him that the airline did offer a reduced bereavement rate, and that if he needed to travel immediately, he could book at the standard fare and then apply for the discount by submitting a ticket refund application within ninety days of the date the ticket was issued. Moffatt took a screenshot of the exchange. He booked the flight. He attended the funeral. When he returned home, he submitted his refund application with the required documentation, including his grandmother's death certificate. Air Canada denied the request.

The actual bereavement policy on the airline’s website, on a separate page titled “Bereavement travel,” stated clearly that the discount could not be applied after travel had been completed. The chatbot had been wrong. An Air Canada representative later acknowledged, in correspondence with Moffatt, that the chatbot had provided misleading words and said the airline would update it. They did not offer him the discount.

Moffatt took the matter to the British Columbia Civil Resolution Tribunal, a small-claims body designed for low-value consumer disputes. The amount in question was a few hundred Canadian dollars. Air Canada, defending itself, made an argument that would later draw international attention. The airline argued that it could not be held liable for what the chatbot had said, because the chatbot was, in the airline’s framing, a separate legal entity responsible for its own actions. The tribunal’s response, written by Member Christopher C. Rivers, has been quoted in legal commentary in nearly every jurisdiction that watches AI law. The tribunal called the submission remarkable. It then explained, plainly, that while a chatbot has an interactive component, it is still just a part of Air Canada’s website, and it should be obvious to Air Canada that it is responsible for all the information on its website. It makes no difference, the tribunal continued, whether the information comes from a static page or a chatbot. Air Canada was ordered to pay Moffatt eight hundred and twelve dollars and two cents in total damages and fees. The decision, Moffatt v Air Canada, 2024 BCCRT 149, is not binding on any other court. It has nevertheless been treated, in nearly every serious analysis published since, as the first clear judicial statement of a principle the industry had been quietly avoiding. An organization that deploys an AI system is the author of what that system says.

It is tempting to read this as a chatbot story. A vendor sold an airline a customer service tool, the tool gave a wrong answer, the airline paid for the mistake, and the technology will get better.

That reading misses what is actually instructive about the case. The technology is not the failure mode. The failure mode is upstream of the technology, inside the organization that put the system in front of customers.

Air Canada deployed a customer-facing AI without, by all available indications, the apparatus needed to know what the system was saying day to day, the mechanism needed to correct it when it was wrong, or the internal framing needed to take responsibility for it when it caused harm. The remarkable submission the tribunal rebuked was not a clever legal maneuver by outside counsel. It was the logical end of an organization that had deployed a system it did not feel it owned.

This is what we mean by AI readiness, and this is where literacy enters the picture. The question almost every executive team is now asking is some version of are we using AI.

The honest answer in most organizations is yes, in some workflows, with varying degrees of intention. The more important question is the one Air Canada was, in effect, forced to answer in front of a tribunal. Are we ready for the fact that we are using it. Use is everywhere.

Readiness is the thing your board, your regulators, your customers, and increasingly your courts will ask you to demonstrate.

The Moffatt case, in a few pages of tribunal decision, demonstrated that Air Canada was using AI and was not ready for it.

Readiness sits on top of literacy, and the literacy that failed at Air Canada is the literacy of deployment. The literacy of deployment is what an organization’s leaders, owners, and senior decision-makers need so that the choices about where AI enters the organization are deliberate rather than reactive. It is not about coding skill or model intuition. It is the capacity to ask, before a system goes live, three questions that look simple and almost never get clear answers in unprepared organizations. The first is what this system will say to the people it interacts with, and whether that aligns with what the rest of the organization is saying on the same topics. The second is who, inside the building, owns the answer if the system gets it wrong. The third is what the organization will do, operationally and legally, when the system gets it wrong in a way that produces harm. Air Canada had a chatbot that said one thing, a policy page that said another, and no apparent reconciliation between the two. The deployment decision had been made without the deployment literacy needed to carry it.

This is also where shadow AI enters the conversation, and it is worth naming, because shadow AI is the version of this gap that most organizations are quietly living inside today. Shadow AI is the AI use that happens inside an organization without the knowledge, sanction, or oversight of the people who would be accountable if something went wrong. A marketing manager who pastes draft customer messaging into a public AI tool to tighten it up before sending. A finance analyst who runs a board memo through a generative system to make it sound sharper. A field engineer who asks an open chatbot how to handle a regulated chemical because the internal documentation is too slow to navigate.

None of these people are acting in bad faith. They are doing what their workload asks them to do, with the tools that are most accessible at the moment of pressure. The cumulative effect is that the organization is using AI in places its leadership does not know about, with data its policies have not classified, producing outputs that influence decisions that will later need to be defended. The Air Canada chatbot was a sanctioned deployment that did not have the literacy behind it. Shadow AI is the unsanctioned deployment that does not even have the visibility behind it. Both produce the same outcome, which is decisions the organization cannot defend.

The reason the Moffatt case has been quoted so widely is not that the airline paid a few hundred dollars. The reason is that the tribunal, in plain language, removed the option that many organizations had been quietly relying on. The option to argue, when an AI system causes harm, that the system was somehow separate from the organization that ran it. That option no longer exists in any jurisdiction that takes the Moffatt reasoning seriously, and the reasoning is too straightforward to confine to one tribunal in one province. If your AI is part of your website, your customer service, your hiring funnel, your underwriting workflow, your clinical pathway, your procurement chain, then your AI is part of your organization. What it says, you said.

The shift this forces is not legal. It is organizational, and it is what AI readiness is actually about. An organization that is ready for AI has built the apparatus to stand behind every AI-mediated decision its name is attached to. That apparatus does not begin with the technology. It begins with deployment literacy at the top of the house, and it cascades from there. The frontline staff need the literacy of use so they can interpret AI outputs with calibrated suspicion. The builders need the literacy of development so the systems they ship can be reasoned about and not just deployed. The leaders need the literacy of deployment so the choices about where AI enters the organization are deliberate. Without all three, readiness is a claim the organization makes about itself without the means to defend it.

The European Union, the National Institute of Standards and Technology, and the International Organization for Standardization have each written the requirement for AI literacy into their respective frameworks in the last three years. Article 4 of the EU AI Act, in force since February 2025, requires both providers and deployers to ensure sufficient AI literacy among the staff who use these systems. The NIST AI Risk Management Framework places workforce competency inside its GOVERN function. ISO/IEC 42001 requires organizations to determine and ensure the competence of personnel whose work affects AI performance. The instinct across all three is the same. The frameworks know that literacy is the missing piece.

None of the frameworks tells you what good looks like in operational detail, and none of them gives you a score. The frameworks name the requirement and pass the burden of measurement back to you. That is the gap we will keep returning to in this series.

Put differently: they can tell you that your people need AI literacy; they cannot tell you whether they have it.

If your organization had been Air Canada in November 2022, the operational questions worth sitting with are these.

• Would you have known what the chatbot was telling customers about bereavement fares that week.

• Would the chatbot’s answer have matched the page on your own website that bore the same title.

• Would anyone inside the building, before the refund was denied, have been able to flag that the two were saying different things.

• Would your first response, when the customer complained, have been to honor what your system had said, or to argue that the system was not yours.

These are not technology questions. They are readiness questions, and the answers are the difference between an organization using AI and an organization ready for it.

Sit with one question this week. If a customer, a regulator, or a court asked you tomorrow to defend one AI‑mediated decision your organization has already made, who in the building would you ask first, and could they answer.

Suneeta Modekurty | Founder, SANJEEVANI AI | Quantifying AI Readiness

Image created using AI tools

Dear Friends,

A school superintendent I worked with last year sat across from me at a kitchen table and asked a question she had been carrying for months.

“My teachers are using AI. My students are using AI. The plagiarism vendor wants a contract. The school board wants a policy. The parents want answers. And I do not know what good looks like. How do I tell if we are ready?”

I have heard that question, in different costumes, from a state CIO, a hospital chief of staff, a community organizer, a board chair, a founder, and a parent in a Costco parking lot.

The question sounds like it is about AI. It is not. It is about a chain that runs underneath AI, in a direction most current conversations do not name.

AI Readiness depends on AI Adoption. Adoption depends on Awareness. Awareness depends on Literacy. Literacy is the foundation, and most organizations skip straight past it.

The next letter arrives Tuesday, and from there every other Tuesday at nine in the morning Central time.

Suneeta Modekurty
Founder, SANJEEVANI AI