The Deficit-First Framework

Where I am seeing AI thrive... do you see what I see?

I’ve been helping people get AI to work in their actual jobs. Not at the organisational level, not at scale. At the individual level: one person, one role, one set of tasks they’re trying to do better or faster or with less friction.

Some of that has been helping others. A lot of it has been my own work, building tools and workflows for the kinds of problems I deal with in consulting and reform delivery. I build my own GPTs, I code automation, and I spend a lot of time thinking about what makes AI stick versus what makes people try it once and stop.

Through that work, I’ve started to notice a pattern. When AI actually becomes part of how someone works (not just something they experiment with), there are usually four conditions present. And when it doesn’t stick, one of those four is usually missing.

I’ve started calling this the Deficit-First Framework. I think it holds at scale, and the research I’ve found so far supports that. But I haven’t led an organisational rollout built around it yet. So this article is partly a framework and partly a question: does this match what you’re seeing?

The pattern

The people I’ve helped get AI working share a set of conditions. They started with a genuine problem, not a technology. The solution was designed into how they actually work, not layered on top. The behaviour change was intentional, not hoped for. And the data feeding the AI was structured and ready.

Those four conditions form the pillars of the framework: Deficit, Design, Intent, and Data.

The way I think about it is as a constraint set. These aren’t a menu of nice-to-haves. All four must be present and strong enough for the task at hand. When they are, AI use tends to compound. When one is weak or missing, you can usually trace the problem back to the gap.

Deficit comes first for a reason. It’s the condition that gives everything else its energy.

Deficit: the reason anyone bothers

Most AI conversations start with “what can this tool do?”

That question has a predictable answer: a lot. Generative AI can draft, summarise, analyse, code, sort, triage, recommend. The capability list is long and growing. But capability isn’t adoption. And adoption is not value.

The better question is: where do you have a genuine deficit that matters enough to change how you work?

A deficit is a real friction point, a capability gap, or a task someone avoids because it’s not their natural strength. Every role has them. And they’re personal. Two people on the same team, doing the same job, will have different deficits.

Think about what a consultant does. They win work, they diagnose problems, they develop solutions, they write those solutions into recommendations or advice. Some consultants love winning work and find the writing painful. Others are brilliant writers who dread the pitch. The deficit is different for each person, even though the role is the same.

This matters because adoption is behaviour change. And behaviour change needs a driver strong enough to push someone through the friction of learning something new and doing their work differently. When the deficit is real and felt, people engage with AI because it helps them do their work better. That’s what I’ve seen sustain it.

A practical test I come back to: if the AI vanished tomorrow, would you fight to keep it? Would you notice it was gone because it had become genuinely necessary to how you get your work done?

When the answer is yes, you’ve found a real deficit. And you’ve got a foundation for everything that follows.

Why deficit-first changes the starting point

A lot of AI activity I see starts with “we want AI” or, worse, someone designs a solution around their own deficit and then wonders why others don’t engage with the same enthusiasm.

Both skip the same step. They don’t ask: why would this specific person, in this specific role, use it?

Starting with deficit forces that question. It changes the design problem from “how do we roll out AI?” to “why would this person bother?” That’s a better starting point. It forces you to understand the work, before you build the tool.

Research supports this direction. Work on GenAI adoption in organisations highlights that staff skills and organisational capacity to manage complexity are significant factors in whether adoption takes hold [1]. The Behavioural Insights Team’s AI adoption framework distinguishes between shallow and deep use, and finds that moving people from one to the other depends on whether the use case connects to a genuine need [2].

Augment the drudgery, protect the judgement

One more thing about deficit, because this is where it gets nuanced.

Take an auditing function. Auditors go through large volumes of data, and a reasonable instinct is to say: let AI do the scanning, the sorting, the summarising. Free up the auditor for interpretation and risk calls.

That’s often right. But not always.

Some auditors use that manual process as part of their sensemaking. The act of reading through data is how themes start to form in their head. If you automate that step away, you haven’t just removed drudgery. You’ve disrupted how they think.

The principle is: augment judgement, remove drudgery. But recognise that what counts as drudgery differs by person, even within the same team. The people I’ve helped get this right are the ones who understood their own deficits clearly enough to know what to hand to AI and what to keep.

Design: build it into the work, not onto it

The individual AI solutions I’ve seen work best aren’t just clever prompts. They’re designed into the way someone actually works.

At the individual level, this means thinking about the full task: what are the inputs, where does AI sit in the sequence, what does the person still need to do, and how does the output get used? When that’s designed well, the AI feels like part of the workflow. When it’s not, it feels like an extra step.

I think this scales. At the team or organisational level, design would mean applying co-design principles to understand how people currently work, where deficits sit across roles and user types, and then building a system that works at scale while flexing for different styles and use cases. You can’t build a bespoke AI for every person in a large organisation. But you can design a system that accommodates different entry points and different deficits, because you’ve mapped them.

Co-design also builds trust and uptake. When people see their input reflected in the system, they’re more inclined to use it. When something is imposed on them that doesn’t match how they work, they build desire paths around it.

Research on integrating AI into work systems consistently finds that success depends on considering the full work context, not just the model or the interface [3]. The design question isn’t “does the AI work?” It’s “does the AI work inside this person’s (or this team’s) actual workflow?”

Intent: the pillar that locks the value and drives the behaviour

Even a well-designed solution needs to be used consistently. In my own work and with the people I’ve helped, the difference between AI that sticks and AI that fades is almost always about intentional habit change.

Intent means making AI integration a conscious decision, not a passing experiment. At the individual level, that might look like building a project or GPT that you can reuse over time, or setting yourself the expectation that a particular process now includes an AI step.

At scale, I’d expect this to mean building habits, operating rhythms, role expectations, and measurement into workflows. Weekly reviews that include AI use. Shared patterns across a team. Measurement that tracks adoption depth, not just outputs. It may not happen over night, but it will [can] happen.

This is what locks the value. Without intent, you get a burst of enthusiasm. With it, you get compounding capability.

Research on organisational change capacity supports this. Studies on GenAI adoption find that the relationship between AI capability and sustained use is moderated by the capacity to actually change how work gets done [1]. In plainer terms: if the behaviour change happens, the value compounds. If it doesn’t, even good tools plateau.

Data: the foundation that makes it work on day one

This is the pillar that surprised me most in my own practice. Getting the data right makes a bigger difference than most people expect. Particularly, because we’re told that AI’s biggest strength is combing through huge reams of data; and that might be true for the first round. But the “I” stands for intelligence, and if it thinks it knows, why would it retread those grounds?

Data readiness for AI isn’t just “clean data.” It’s structure, format, metadata, provenance, and context. It’s thinking carefully about what information the AI needs to do the job you’ve designed for it, and packaging that information in formats AI can actually work with. And if you’re using different AI tools, their own personalities come into play here. What works for one, may not be easily transferred to another.

In practice, this often means tables and matrices over long documents. It means deliberate structuring, not dumping reams of files into a system and hoping for the best. It means understanding that how you format your inputs will shape the quality of your outputs, and that getting this wrong can train the AI into unhelpful patterns.

The Open Data Institute’s work on AI-ready data frames this well: data readiness is foundational to AI value, and it requires specific, intentional preparation [4]. Technical work on data readiness taxonomies reinforces the point across structured and unstructured datasets [5].

When the data is right, the AI delivers value from the first interaction. That early experience of competence is what builds trust and sustains engagement. When the data isn’t right, people try it once, get a poor result, and conclude it’s not for them. That’s a data problem masquerading as an AI problem. And if the deficit isn’t compelling enough, it’s not going to be worth the troubleshooting from the human.

The constraint-set logic: a diagnostic, not a prescription

These four pillars aren’t a menu. They’re a constraint set. All four need to be present and strong enough for the task at hand. When they are, AI use tends to compound. When one is weak, things stall in a predictable way.

That’s what makes this framing useful as a diagnostic. If AI isn’t gaining traction (for an individual or a team), you can usually trace the issue to a specific pillar.

Weak deficit: someone tries the tool because it’s new, not because they need it. Interest fades because there’s no compelling reason to push through the friction of changing how they work or building a strong foundation for it to work.

Weak design: AI use stays ad hoc. It doesn’t connect to the actual workflow, so it feels like an extra step rather than an improvement.

Weak intent: initial enthusiasm, but the habit doesn’t form. The person (or team) drifts back to how they worked before.

Weak data: outputs are unreliable from the start. People conclude the AI doesn’t work. Often it’s the inputs that don’t work.

The diagnostic value is practical. It gives you something to strengthen, not just a vague sense that it didn’t land.

Where to from here

Everything I’ve described so far comes from individual-level work. Helping people find their deficits, design their solutions, build the habit, and get the data right. That’s where I have direct experience, and that’s where I’ve seen the pattern hold.

I believe the same logic applies at the team and organisational level. The research I’ve found so far suggests it does: multi-factor AI readiness models emphasise people, process, data, and technology as joint requirements [7], and the sociotechnical and behavioural adoption literature aligns with the four pillars [1][2][3].

I haven’t led an organisational rollout built around this framework yet. That’s next. But I’ve spent fifteen years landing complex change in places where it’s hard to land, and I’ve seen enough patterns hold and break to trust this one.

What I’d like to do next is build a qualitative evidence base around these conditions. If you’re working on AI adoption (at any level, individual or organisational), I’m interested in whether this pattern matches your experience.

Some questions I’m thinking about:

For people leading AI rollouts: when it’s worked, were all four of these present? When it stalled, which was missing?

For individuals using AI in their own work: did you start with a specific deficit? Did you design it into your workflow, or bolt it on? Did it stick?

For anyone who’s watched an AI initiative quietly die: what was the gap?

I’m not looking for polished case studies. I’m looking for honest accounts of what worked and what didn’t. If you’re willing to share, I’d love to hear from you.

A note on sharing

I’m publishing this framework openly because I think it’s more useful shared than built behind closed doors. The concepts here draw on established research in technology adoption, sociotechnical systems design, behavioural science, and data readiness, and I’ve tried to be clear about those roots.

What I believe is distinctive is the integration: the specific combination of deficit as the adoption driver, design as the scaling mechanism, intentional behaviour change as the value lock, and data readiness as the operational foundation, treated as a constraint set.

If you use the Deficit-First Framework, teach it, adapt it, or build on it, I ask for attribution:

“Deficit-First Framework (Deficit, Design, Intent, Data), Siân Rinaldi, 2026.”

This work is licensed under Creative Commons Attribution 4.0 (CC BY 4.0). You’re free to share and adapt it, including commercially, with attribution and indication of changes [6].

References and further reading

[1] Benlian, A. et al. (2025). “Organisational adoption of generative AI: The role of AI capability, skills, complexity and change capacity.” Information & Management.

[2] Behavioural Insights Team (2025). “AI-ADOPT: A Framework for Responsible AI Adoption.” BIT Report.

[3] Bäumer et al. (2023). “Sociotechnical approaches to AI integration in work systems.” PMC / National Library of Medicine.

[4] Open Data Institute (n.d.). “A Framework for AI-Ready Data.” ODI Reports.

[5] Aziz, A. et al. (2024). “Data readiness for AI: A taxonomy and metrics survey.” arXiv.

[6] Creative Commons. “Attribution 4.0 International (CC BY 4.0).”

[7] Alsheibani, S. et al. (2022). “Towards an AI readiness framework: People, process, technology, and data dimensions.” Information & Managem