The Foundations for AI Adoption: Start with the Work, Not the Tool
- 3 days ago
- 6 min read

By Paul Shotton, Advocacy Strategy
A growing number of public affairs teams are now trying to write an AI strategy. That is a healthy development. A year ago the conversation was about whether AI had any real place in serious policy work; today it is about how to adopt it well. But sit in enough of these conversations and a pattern becomes hard to ignore. The discussion almost always begins with tools. Which platform should we buy? Should we be on the enterprise version? Has anyone tried the new model? These are not unreasonable questions, but they are the wrong place to start.
The more useful question is quieter and harder: what are we actually trying to improve? An AI strategy that starts with a tool tends to produce a procurement decision in search of a purpose. An AI strategy that starts with the work produces something far more durable — a clear view of where the technology can genuinely help, and where it cannot.
The argument of this piece is simple. AI adoption in public affairs should begin with four things, none of which involves a product: a clear vision of what you want AI to help your team do better, a map of the workflows where it might add value, an honest audit of how your team already works and how mature that practice is, and a realistic, evolving set of use cases. The tool comes last, because the tool is the easiest thing to change.
Start with vision, not features
Every credible strategy needs a sense of direction, and an AI strategy is no different. Before evaluating any platform, a team should be able to answer a deceptively basic question: what should AI help us do better? The answers are usually more specific, and more grounded, than the marketing language around AI would suggest. A team might want to sharpen its policy analysis, reduce the volume of repetitive drafting and formatting that consumes junior time, strengthen the consistency of its monitoring, capture institutional knowledge that currently lives in a few people's heads, improve consistency across a dispersed team, or simply give less experienced colleagues a way to produce a competent first draft without waiting for a senior review.
None of these is a technology goal. They are public affairs goals — about analysis, capacity, consistency, knowledge, and people. The vision matters because it becomes the test that every later decision is measured against. If a feature does not serve the vision, it is a distraction, however impressive the demonstration.
Map the workflows where AI could add value
Public affairs is unusually well suited to this kind of thinking, because so much of the work is structured around repeatable knowledge workflows. Monitoring, research, policy analysis, stakeholder mapping, message development, reporting to management, campaign planning, internal coordination, and knowledge capture are all multi-step processes with inputs, intermediate steps, and outputs. Each is a candidate for AI support, but not equally, and not in the same way.
Mapping these workflows does two things. It surfaces where AI could realistically add value — summarising and structuring a monitoring intake, drafting a first-pass analysis, comparing positions across stakeholders, turning a long consultation into a structured brief. It also surfaces where the value is thin or the risk is high, which is just as important. A workflow map is not a wish list; it is a way of seeing the work clearly enough to decide where help is genuinely worth having.
Audit current practice and maturity
Most teams are further into AI than their leaders realise, and less consistent than they would like. Before designing a roadmap, it is worth taking an honest inventory of what is already happening. Who is using AI today? For which tasks, and with which tools? What is working well enough to be shared? What is being done in ways that carry risk — confidential material pasted into consumer tools, outputs used without review, prompts that no one else could reproduce? Where is practice inconsistent, and where do people simply lack the confidence to start?
This is where a maturity lens helps. Teams tend to move through recognisable stages — from informal personal productivity, to AI applied to specific tasks, to AI integrated across structured workflows, and eventually toward more automated or agentic approaches. The point of placing yourself on that curve is not to award a grade. It is to be realistic. A team experimenting informally has very different needs from one already building structured workflows, and a strategy that ignores this will either overwhelm the first team or underwhelm the second.
Use cases that fit your maturity — and will change
Use cases are where strategy meets reality, and they should be chosen to match where the team actually is. For a team at the early stages, the right use cases are narrow, low-risk, and easy to verify: summarising a clean document, drafting a routine email, reformatting notes into a structured brief. For a more mature team, the use cases can extend into multi-step workflows with clearer governance and shared standard operating procedures. Matching use cases to maturity is what keeps a strategy credible rather than aspirational.
It also helps to accept from the outset that use cases will evolve. Teams discover what AI can and cannot do by using it. A use case that looked promising turns out to be fragile; one that seemed marginal turns out to save real time. The tools themselves change quickly — capabilities that required careful workflows a year ago are now built into the models. A strategy that is fixed in fine detail will be out of date within months. The more useful strategy is flexible: firm on vision and direction, light and revisable on the specifics.
Adoption is a change process, not a rollout
It is tempting to treat AI adoption as a technical rollout — choose the tool, run the training, declare it done. In practice it is a change management process, and people do not change at the same speed. Everett Rogers' work on the diffusion of innovations, now more than sixty years old, still describes the pattern well: a small group of early adopters who are eager to experiment, a larger majority who will follow once the path is clear, and a more cautious group who need to be persuaded rather than pushed.
Each group needs something different. Early adopters benefit from space to experiment — pilots, hackathons, permission to try things that might not work. The majority need something more practical: clear examples, approved use cases, and training that shows the work being done rather than the technology being admired. The sceptics, who are often experienced and not wrong to be cautious, need a listening ear more than a mandate. Their concerns about judgement, confidentiality, and quality are usually the concerns the whole team should be taking seriously. Treating resistance as a problem to be overcome, rather than information to be used, is a common and costly mistake.
A good AI policy is part of the foundation
A practical AI policy belongs in this foundation, rather than being bolted on at the end. The best policies do more than warn people to be careful. They set out a vision and a mindset, give explicit permission to experiment, make clear that adoption is for everyone and not just the technically confident, and draw boundaries that people can actually understand — what kinds of data must never be entered, which uses require review, and where to go when something is uncertain. A policy that only says “be careful” tells people nothing they can act on. A policy that combines permission with clear guardrails gives a team the confidence to move.
Where the strategy really begins
None of this requires a purchasing decision. The foundation of an AI strategy is not a platform; it is a clear view of the work, the people who do it, and how the team actually operates today. The tool will change — probably several times — and the team that has done this groundwork will absorb each change easily, because it knows what it is trying to improve and why. The team that started with the tool will be left asking a harder question every time the technology moves on: what was this for in the first place?
So before the next demonstration or trial, it is worth asking a simpler question of your own team: do we actually know what we want AI to help us do better — and how we work today? If the answer is not yet clear, that, rather than the choice of tool, is where the strategy really begins.




Comments