Workflow First, Not Tool First: How to Classify AI Use Cases in Public Affairs

By Paul Shotton, Advocacy Strategy

This is not the first time I have written about workflows and use cases in this series, and it will not be the last. The topic keeps coming back because it is foundational: nothing else in AI adoption — tool choice, governance, scaling, agents — pays off if this layer is wrong. And it keeps being wrong in the same way. A new tool lands on the agenda, the discussion turns into a comparison of platforms, and the harder question quietly slips off the table: what is the actual piece of work we are trying to improve?

If you start with the tool, you end up looking for problems that fit it. If you start with the workflow, you end up looking for tools that fit the work. The two routes feel similar but they produce very different operating models, very different risk profiles, and very different returns. In public affairs, the right unit of analysis is not the model and not the platform. It is the workflow, the step inside it, and the use case that sits in that step.

What is a workflow / Use case

It is worth slowing down on the word “workflow” because it gets used very loosely. In the discipline from which the term comes, a workflow is the operational sequence of activities, decisions, hand-offs, and review points through which part of a business process is executed. It is not the high-level process. It is not the policy. It is the concrete chain of steps, with named owners and defined inputs and outputs, that turns intent into a deliverable.

A use case is something narrower. It is a bounded sequence of system behaviour that achieves a specific goal for a user. In an AI context, that distinction matters more than it sounds. An AI use case is almost never a whole workflow. It is a bounded intervention inside one — a step, or a tightly linked cluster of steps, where a model can plausibly help.

This is exactly where most public affairs teams skip a level of resolution. They talk about “using AI for monitoring” as if monitoring were one task, when in practice it is a workflow with at least five discrete steps: source discovery, ingestion, classification, summarisation, and escalation. AI may belong in three of those steps, may be unnecessary in two, and may be actively risky in the sixth. Until you see the steps, you cannot place the use case.

Start with the work, not the tool

The strongest enterprise evidence on AI value capture points in the same direction. McKinsey’s most recent State of AI work finds that the organisations capturing the most value are those redesigning workflows around AI, not those layering AI on top of unchanged processes. Deloitte’s analysis of agentic adoption reaches the same conclusion: legacy workflows are themselves the bottleneck, and tool selection without process redesign tends to produce expensive disappointment.

For public affairs, that translates into a practical sequence.

Map the workflow first. Write down the actual chain of steps as it runs today — not as the SOP says, but as the team actually does it. Who collects the source material? Who triages it? Who writes the first draft? Who signs off? Where does the work currently slow down, and why?

Identify the step, or cluster of steps, where the friction sits. It is almost always a step that is repetitive, text-heavy, retrieval-dependent, or all three. Translating a German parliamentary debate into a usable summary is one of those steps. Reading thirty consultation responses and clustering the arguments is another. Writing the eighth iteration of a stakeholder brief from materials already in your CRM is another.

Only at that point should the conversation turn to the tool.

Choosing the right AI for the right step

Once the step is isolated, the choice of AI type becomes a much narrower decision.

Generative models are best for drafting, summarising, and transforming text. Retrieval-augmented generation is best where the answer must be grounded in current policy documents or internal positions. Classical machine learning is best for scoring and pattern detection where you actually have labelled historical data. Agents become appropriate when several tools or systems must be coordinated, but only with tight permissions and observability.

A worked example helps. A trade association running EU policy monitoring might map a workflow that begins with daily ingestion of parliamentary agendas, Commission consultations, and member-state gazettes, runs through multilingual extraction and classification against the association’s issue taxonomy, generates a first-draft alert, and ends with a human decision on whether to escalate to members. Inside that workflow, retrieval-augmented generation is the right fit for grounded summarisation against the existing dossier; a classifier handles relevance scoring; a generative model produces the alert draft. The escalation decision stays with the policy lead. None of those choices makes sense until the workflow is on paper.

Where organisational constraints come in

The third step in the sequence is the one most teams underestimate: fitting the tool to the constraints the organisation has already imposed on itself. Most public affairs teams do not have a free hand. They sit inside corporate structures that have already made decisions about which licences are available, which data can leave the tenant, and which categories of information cannot be exposed to external models at all.

This is where promising pilots die. A team identifies a strong workflow candidate, picks an appropriate AI type, and then discovers that the data the use case depends on cannot leave the Microsoft 365 tenant, or that the only approved licence is a generic copilot without retrieval, or that legal will not authorise the use of personal data on external stakeholders without a deeper review.

The practical implication is that constraints belong in the use-case definition from the start, not at the end. Before approving a pilot, three questions are worth answering on a single page. What is the data sensitivity of the inputs and outputs? What licences and access rights does the team actually have, in this jurisdiction, today? And what level of human oversight is required for this output to be defensible — internally, externally, and under the EU AI Act’s intended-purpose logic, which assesses risk against operational use rather than against the abstract model?

The NIST AI Risk Management Framework’s govern–map–measure–manage discipline is useful here, not as a compliance exercise but as a structuring device. It forces the team to define the intended purpose, log the decisions, and decide upfront where the human review gate sits. In public affairs, the default should almost always be human-before-release for anything externally facing, and human-in-the-loop for anything that touches stakeholder data.

From copilots to orchestrated workflows

The honest picture of where the field is today is partial automation, not autonomy. Most public affairs teams will get more value, more quickly, from AI-assisted workflow execution than from agentic systems running end-to-end. The reasons are not primarily technical. They are about data quality, taxonomy discipline, and the reputational cost of a wrong external output. Agents will expand the frontier, but mostly by turning previously manual coordination into orchestrated sub-workflows — meeting prep packs, note-to-CRM conversion, structured follow-ups — rather than by replacing the senior judgement that defines the work.

That is not a reason to wait. It is a reason to build the foundations now: clean retrieval corpora, a versioned issue taxonomy, structured engagement records, and documented review gates. The teams that do this work in 2026 are the ones that will be able to plug in agentic capabilities in 2027 without rebuilding from scratch.

The change we need to make

The shift the profession needs is small in description and large in practice. It is the move from asking “which tool should we buy?” to asking “which step in which workflow are we trying to change, and what does that change require from our data, our licences, and our people?”

So the question to sit with is not whether your team is using AI. Many teams are. The question is whether you can name the workflow, the step, and the constraint that your next AI use case is built around — and whether anyone outside your team would recognise that description as the actual work.