A guide to Web3/AI pilot projects for local governments

The steps and checkpoints from concept through pilot (PoC), evaluation, and procurement/full adoption.

Available in Japanese only: this guide is currently published in Japanese only. The overview below is in English, but the full 40-point checklist has not yet been translated.

This practical guide organizes, in four steps, what local governments and the public sector should work through and check at each phase as they advance a Web3/AI pilot project — from clarifying the problem at the concept stage, through designing and running the PoC, evaluating it, and moving to procurement and full adoption.

It avoids language tied to a specific technology or product, and organizes the general points worth keeping in mind from a procurement, regulatory, and internal-consensus perspective.

How this resource is organized

• Section 2: Step 1 — Concept structuring (10 items)
• Section 3: Step 2 — Designing and running the pilot (PoC) (10 items)
• Section 4: Step 3 — Evaluation (10 items)
• Section 5: Step 4 — Procurement and full adoption (10 items)

Step 1: Concept structuring

Purpose: clarify the pilot's objective and target problem, and lay the groundwork for internal consensus. Put into words which business problem you are addressing and why Web3/AI is the right fit — getting the shape of the problem right, before selecting a technology, is what determines how well the pilot design and procurement go later.

• The business problem to solve can be explained in 1–2 sentences
• You can explain why it cannot be solved without Web3/AI (the gap versus existing systems)
• The responsible department and stakeholders for the target business are identified
• The scope of impact on external stakeholders (residents, businesses) is organized
• Someone is assigned to confirm alignment with laws, ordinances, and personal-data-protection regulation
• The reporting flow and accountability to the head of the government body and the assembly are confirmed
• Candidate budget categories (subsidy, general funds, joint procurement) have been identified
• One department lead and one technical point of contact are each decided
• The possibility of partnering with outside experts, research institutions, or other local governments has been checked
• Judgment criteria are shared in advance, including the option of "not running a pilot"

Step 2: Designing and running the pilot (PoC)

Purpose: verify technical and operational feasibility within a limited scope. A pilot is designed as a place to test a business hypothesis, not to showcase technology. Narrowing scope and setting the verification period, KPIs, and exit conditions in advance smooths the decision-making that follows.

• The hypotheses being tested are narrowed to 3 or fewer
• The pilot's scope (target business, target data, number of participants) is documented
• KPIs and how they will be measured are defined (e.g. processing time, manual-task volume)
• The pilot period (start and end dates) and the mid-point review schedule are decided
• Exit/scale-down criteria are agreed in advance
• Data handling (anonymization, storage location, disposal procedure) is organized
• Roles and responsibilities with the system provider are confirmed in writing
• An incident-response flow for the pilot (outage, data breach) is ready
• Explanation to, and consent from, pilot participants (staff, residents) is complete
• The frequency and format for progress reports to the assembly and higher bodies is decided

Step 3: Evaluation

Purpose: organize the pilot's results and decide whether to move to full adoption, revise, or discontinue. Evaluate against the KPIs set in advance, judging not "did the technology work" but "is there a credible path to improving the business problem." The record can also be used for future procurement, assembly briefings, and information-sharing with other local governments.

• Results were compared against the KPIs set before the pilot started
• Feedback was collected from pilot participants (staff, residents)
• No security or privacy issues were confirmed
• The operational outlook for full adoption (staffing, budget, maintenance) is clear
• If not moving to full adoption, the reasons and lessons are documented
• Cost estimates (initial and ongoing) have been updated
• A comparison with similar cases at other local governments has been carried out
• Confidentiality and IP handling with the pilot vendor were honored as contracted
• The scope for publicly sharing the evaluation results (with the head of government, the assembly, residents) is decided
• Agreement has been reached among stakeholders on whether to move to the next phase (procurement / full adoption)

Step 4: Procurement and full adoption

Purpose: use the knowledge gained from the pilot to adopt the production system through an appropriate procurement process. Local-government procurement can follow several routes — competitive bidding, a proposal-based competition, or a negotiated contract — and care is needed so that the specifications gained from the pilot do not lock you into a specific vendor.

• The procurement method (general competitive bidding, proposal-based public competition, negotiated contract, etc.) is settled
• The procurement specification is written in a vendor-neutral way (not tied to a specific product name)
• The evaluation criteria (weighting of technical and price scores) are published in advance
• Fairness safeguards are in place if the pilot vendor also participates in the full procurement
• The system- and data-migration plan is included in the specification
• The operational-phase SLA (availability, incident-response time) is documented
• Data-return and system-handover conditions on contract end or vendor change are documented
• Explanation and outreach plans for residents and businesses are prepared
• A structure for ongoing KPI measurement and periodic evaluation after full adoption is in place
• Change-management procedures for future feature expansion or integration with other systems are organized

How to use the scoring sheet

7+ items confirmed per step

Ready to move to the next phase — proceed while recording any unconfirmed items as a known risk.

4–6 items confirmed per step

The main issues are covered — recommend organizing the remaining items before moving to the next phase.

3 or fewer items confirmed per step

Concept and structural organization is still incomplete — recommend building internal consensus and confirming staffing first.

Talk to Netsujo

This guide can be used entirely within your organization, or with outside support. If you are unsure which step to start from, or many items remain unconfirmed, a free 30-minute first consultation can help work through the issues together. Our standard scope of support includes:

• Concept structuring (putting the problem into words, mapping stakeholders)
• PoC design (documenting hypothesis, KPIs, scope, exit criteria)
• Reviewing procurement specifications and confirming vendor neutrality
• Support drafting the evaluation report