AI bootcamp for EU affairs, day 3: how AI reasons, and which model to pick
Day 2 explained prediction. Day 3 turns that into a practical decision: which model should you use, how much reasoning should the task get, and how much verification does the answer require?
Sebastián Rodríguez Pérez is a European campaign strategist with direct experience running and advising campaigns for some of Europe's largest pro-European organisations. He founded the European Campaign Playbook to codify practitioner knowledge across the EU's 27 political environments and make it accessible to campaign professionals, advocacy teams, and civic organisations working at the European level. His work spans electoral strategy, EU public affairs, digital campaigning, and the integration of AI tools into political communication workflows.
Disclosure
Sebastián Rodríguez Pérez is the founder of the European Campaign Playbook and Campaign Intelligence Library. He has worked with pro-European organisations across multiple EU member states. He maintains editorial non-partisanship in all published content; where articles relate to campaigns or organisations he has directly worked with, this is disclosed within the article. He holds no current positions in active electoral campaigns.
What it covers
How to choose the right AI model and reasoning effort for a task, when deeper reasoning is worth the additional time and cost, and how the stakes of the work should determine the level of human verification.
Who it is for
EU affairs, public affairs, policy and communications professionals who use AI regularly but still choose models or reasoning settings by habit, guesswork or whatever the interface defaults to.
When to use it
Use this whenever you need to decide whether a task deserves a fast answer, deeper analysis or a more capable model, especially before briefing colleagues, interpreting policy, recommending action or producing something that may leave your organisation.
Key takeaway
Model is which kind of colleague you ask. Effort is how much work you ask that colleague to put into the task. Verification is how carefully you check what comes back. Increase all three as the complexity and stakes rise. More reasoning can improve analysis. It cannot turn an unverified answer into a verified fact.
In brief
- Model choice and reasoning effort are different decisions: one determines the capability you are using; the other affects how much work the model puts into the task.
- Simple wording tasks rarely need the most capable model or the highest reasoning setting.
- Multi-step policy analysis, comparison and strategic work benefit more from deeper reasoning.
- Higher reasoning usually means greater latency and, in API settings, higher token usage and cost.
- Verification is a separate decision. A more capable model can still produce an incorrect or unsupported answer.
- Use a simple rule: low-stakes wording → fast; multi-step judgement → deeper; strategic or public-facing work → deeper plus source verification.
- Learn the pattern, because model line-ups and product interfaces change quickly.
Framework
Task → Stakes → Model → Check
Four decisions before you choose a model. As complexity rises, increase reasoning. As consequences rise, increase verification.
| Layer | Label | Description |
|---|---|---|
| Decision 1 | Task | What am I actually asking the model to do? This tells you whether the problem is simple, analytical or multi-step. |
| Decision 2 | Stakes | What happens if the answer is wrong? This sets how much care and human oversight the task deserves. |
| Decision 3 | Model and effort | How much capability and reasoning does the task justify? This drives speed, depth, latency and cost. |
| Decision 4 | Check | What must be verified before I use the answer? This sets the level of source checking and human judgement. |
Day three starts with a decision
By the end of this article
You will be able to:
- distinguish model capability from reasoning effort;
- decide when a fast model is enough and when deeper reasoning is worth the time;
- match model and effort to common EU affairs tasks;
- recognise when additional reasoning is unlikely to improve the result;
- decide how much source verification a task requires;
- create a simple model-and-effort rule for your own team’s recurring work.
The problem: most teams use one AI setting for everything
A team may use the same model to fix a typo, summarise a 40-page proposal, analyse stakeholder incentives and draft an advocacy strategy.
Those tasks differ in difficulty, cost and risk.
Using the most capable model for every task wastes time and resources. Using the fastest model for every task can produce shallow analysis exactly where judgement matters most.
The practical skill is matching the level of AI capability, reasoning and human checking to the task in front of you.
Who will benefit most
This is especially useful for:
- policy officers summarising and analysing EU files;
- communications teams using AI for drafting and editing;
- public affairs professionals preparing briefings, Q&A and stakeholder analysis;
- managers deciding which tasks deserve more capable models;
- teams trying to balance quality, speed and cost.
What reasoning changes
On day 2, we saw how large language models generate language: they predict the most likely next word, one word at a time. Day 3 adds what happens when a model is given more working time.
Some current models can allocate additional internal computation to harder tasks before producing the final answer. The exact mechanism differs by model and product, but the practical effect is straightforward: the model can spend more effort on problems that require several steps, comparisons or tool calls, and take longer to answer.
Treat its internal reasoning as working. What matters to you is the quality of the final answer, the assumptions it states, the evidence it uses and whether its claims survive verification.

Think of it as giving the model more working time. For the practitioner, the useful distinction is simply: some tasks get an immediate response; harder tasks can receive more internal computational effort before the final response.
This article uses Claude as the worked example, but the decision framework applies across AI products even when model names and controls differ.
Every prompt from this bootcamp is collected in the AI prompt library.