Home/Step 3
Step 3: Define the solution

Define the solution

You have a problem. Now match it to an approach. This step covers four decisions: which AI method, what data you need, what could go wrong, and whether to build or buy.

3.1 Match your problem to an approach

The AI menu lists twelve approaches with real government examples. Filter by problem type or data requirement to find candidates worth investigating.

AI menu

Open the AI menu

Twelve approaches with the kinds of problems each one is good at, the data each one needs, and a few examples of governments that have used them in practice.

Match your problem to an approach

For each priority problem, note one or two candidate approaches from the AI menu and any data gap you would need to close first. The menu is a guide, not a limit, so add your own approaches if you have them.

Priority problemCandidate approachData gap to close?

Your project can be smaller than the menu examples

Many of the case studies started small. Think about automating one repetitive task, building a single dashboard, or using an LLM to summarise one type of document. Starting smaller is best to produce something with real, immediate impact. Given the scale governments work at, even a tiny change can result in large gains.

3.2 What data will you need?

Different approaches need very different amounts and quality of data. Check this against your reality before committing.

ApproachData barWhat you needIf you don’t have it
Text analysis, search, chatbots Low Documents, policies, reports. Even paper records work after digitisation. Start with what you have. You may be able to create an impactful solution just by bringing together your documents and extracting insights.
Anomaly detection Medium A substantial sample of transaction or operational records, in consistent format, so that patterns and outliers can be identified. Sort out the data layer first. This may mean data centralisation, cleaning, or dashboards before applying AI.
Prediction & classification High Structured historical data with past decisions or outcomes (labels). Build a labelling process or pick a different approach.
Computer vision, remote sensing High Imagery (satellite, aerial, drone, ground). May require a specialist partner. Consider remote-sensing partners and subject matter experts.

3.3 Build vs. buy

This is a core decision governments have to make, and the answer depends on each given context. Choose the option that best fits your capacity and context.

Build

You have technical capacity and need something custom to your context.

Buy / adapt

A proven tool already exists for this use case. Verify it works in your context.

Hybrid

Buy a base solution and customise it with local expertise, or partner with shared ownership.

Internal

Advantages

  • Builds in-house capacity.
  • Cheaper over time.
  • Full ownership and control.

Watch out for

  • Slower to deliver.
  • Requires existing or hired technical skill.
  • Team may be stretched across other priorities.

External

Advantages

  • Faster to deliver.
  • Access to specialist capabilities.
  • Can be funded by donors.

Watch out for

  • More expensive.
  • Risk of dependency on the vendor.
  • Donor funding may come with conditions that reduce your control.
QuestionYour response
Is there a proven off-the-shelf solution already working in a comparable context?
If buying: What demonstration requirements and agency control requirements do you need?
If building: Do you have realistic in-house or partner capacity (engineers, PMs)?
How will you avoid vendor lock-in?
What are the invisible costs of each option? (local context gaps, training, dependency)
What are the visible costs of each option? (vendor prices, LLM use costs, engineer salaries)

3.4 Risk assessment

Check each risk before committing to an approach. Each of these risks has options for mitigation. Do not discard a project just because it may have some risks. Evaluating tradeoffs and being mindful of risks creates a strong and defensible approach when you build.

01

Ethics

Could this produce biased or unfair outcomes?
LowMediumHigh
  • Test outputs across different population groups before deploying.
  • Include affected communities in the design process.
  • Set a human review threshold: any decision above a certain impact level requires sign-off.
  • Document known limitations and make them visible to users of the system.
02

Privacy

Does it involve personal or sensitive data?
LowMediumHigh
  • Use anonymised or aggregated data where the use case allows it.
  • Get legal sign-off on data use before building anything.
  • Apply data minimisation: only collect and use what the system actually needs.
  • Define a data retention and deletion policy before launch.
03

Safety

What happens when it is wrong? Is there a human check?

LowMediumHigh
  • Build in a human review step for any high-stakes output.
  • Define what “wrong” looks like and integrate tests and alerts that flag it.
  • Start with the system as a recommendation, but a person makes the final decision.
  • Set a clear process for users to report errors.
  • Implement safeguards to prevent harmful outputs.
04

Political

Who could block this, and how will you address that?
LowMediumHigh
  • Involve the teams most affected in the design process from the start.
  • Identify a senior sponsor who can clear blockages.
  • Frame the project around a shared problem, not around the technology.
05

Dependency

Does this create reliance on a vendor we cannot exit?
LowMediumHigh
  • Require access to your own data and model outputs, in writing, before signing any contract.
  • Consider open-source or standard options.
  • Build internal capacity to maintain the system as part of the project scope.
  • Define exit criteria: what would need to happen for you to switch providers.
Take with you to Step 4

By the end of this step you should have written down the approach you intend to take, the data you plan to use, and how you intend to deliver it.

With those three decisions in place you are ready to scope the pilot.

Continue to Step 4