Agent and MCP guides · 2026-07-28

How to start a public sector AI project: a step-by-step plan from pilot to rollout

How to frame scope, data, model, human approval, measurement, and budget when starting a public sector AI project. A measurable pilot plan usable at municipal and ministry scale.

Narrowing scope is the most important decision

Most public sector AI project failures are not technical; they come from scope kept too wide. An assistant meant to cover every service an institution offers produces output that cannot be measured and whose accountability is unclear.

The right starting point is a single question set. In a municipality, not all services but only water outages and fault reports; in a ministry, not all legislation but the application questions of one regulation. Narrowing raises answer quality and makes the error rate measurable.

Scope should also state explicitly what the model must not answer. Questions needing legal interpretation, asking for case-specific file details, or reporting an emergency belong to a person.

Choose one service and one audience.
Write down expected question volume and the existing answer source.
List question types the model will not answer.
Tie the success criterion to a single number.

Content preparation matters more than the model

In public assistants the main driver of answer quality is not the model but the source given to it. Texts scattered across the institution and updated at different dates produce contradictory answers when connected directly.

So an approved source set must exist before the pilot. Each document gets a version, an effective date, and a content owner, and superseded content leaves the set. In most institutions this is the longest line item in the project and it is routinely underestimated.

Source attribution in answers should be mandatory. When a citizen can see which document an answer rests on, wrong answers surface earlier and the institution's position stays defensible.

Human approval and error reporting

Model output is not an administrative act. The way to reflect that in architecture is separating output classes: information that can be shown directly, drafts that need staff approval, and decision text that must never be generated.

An error reporting mechanism belongs in the first version. Letting a citizen or officer flag a wrong answer in one click produces the most valuable data of the pilot period. Reviewing those reports weekly and feeding them back into the source set should be defined as a process.

What the user sees during an outage or error should also be written in advance. When the model cannot answer, the interface routes to the existing channel rather than showing an empty screen.

Measurement: what decides whether the pilot continues

The pilot decision should not rest on impressions. Which metrics are collected and which thresholds must be met belong in the plan from the start. The five metrics below cover most public scenarios.

Collecting them needs no extra analytics stack. Token and cost come from the usage report; volume and handover rate come from the application audit record. Accuracy is measured manually against the institution's evaluation set.

Accuracy: share of correct answers on the internal evaluation set.
Source use: percentage of answers citing a valid source.
Handover rate: how many questions moved to staff, and whether that share falls over time.
Latency: average and 95th percentile response time.
Cost: average tokens and amount per question.

What to write on the budget and procurement side

Token-based consumption is not a classic licence line. Procurement documents should show unit price, expected volume, and a monthly ceiling separately so offers stay comparable and overruns stay preventable.

On LLMTR, model unit prices apply exactly as shown in the catalog and the platform margin is calculated only at credit top-up. Stating that split clearly simplifies unit cost comparison.

Do not conflate the pilot budget with the rollout budget. A pilot has low volume and high evaluation effort; rollout is the reverse. Defining separate ceilings for the two periods produces a realistic plan.

The rollout decision and what follows

At the end of the pilot the decision should be one of three: widen the scope, keep improving within the same scope, or stop. Having the third option on the table is the sign that the project runs on measurement.

If scope widens, the same preparation cycle repeats for the new service: source set, evaluation set, human approval classes, and budget ceiling. Because the technical surface stays the same, the integration work is much shorter the second time.

That is where keeping the technical surface fixed pays off. On LLMTR the model catalog, API key management, and usage reporting stay identical; only the content set and the chosen model change for a new service.

Which organisation types LLMTR fits

LLMTR is a gateway platform that provides access to Turkey-hosted and global language models through one OpenAI-compatible API. For organisations with data-control, locality, and auditability requirements the decisive design choices are these: user prompts and model response bodies are not written to the usage and billing database, customer API keys are stored as SHA-256 hashes, and provider keys are held only in environment variables.

The technical surface chosen during the pilot carries into rollout. When a new unit or service is added, what changes is the content set, the model identifier, and the API key rather than the integration itself. That noticeably shortens the time to launch the second and third service.

Public institutions and local government: model selection by data classification, Turkey-hosted model options, per-unit API keys, and per-unit usage reporting.
Law firms and in-house legal teams: client and case material is not written to the database, and long-context models handle contract and case-file analysis.
Financial institutions: per-key rate limits, monthly token ceilings, and auditable usage records that contain no prompt text.
Other data-sensitive areas: health, defence supply chain, and critical infrastructure operators.
Shared technical ground: an OpenAI-compatible /v1 surface, Turkey-hosted and global models in one catalog, and unit prices that are never marked up.

Steps for starting a public sector AI pilot

Six steps that carry a public institution AI pilot from an idea to a measurable rollout decision.

Narrow the scope. Define in writing one service, one audience, and the question types the model will not answer.
Build the approved source set. Assign a version, effective date, and content owner to every document, and remove superseded content.
Prepare the evaluation set. Create at least fifty real questions with expected answers and measure every candidate model on the same set.
Define human approval classes. Separate output shown directly, output requiring staff approval, and output that must never be generated.
Run the pilot with measurement. Track accuracy, source use, handover rate, latency, and cost per question on a weekly basis.
Make the rollout decision. Compare against thresholds and record the decision to widen, keep improving, or stop, together with its reasoning.

Frequently asked questions

How long should a public sector AI pilot run?

Long enough to collect data you can measure. Four to eight weeks is enough in most scenarios; what matters is not the calendar but reaching a meaningful accuracy measurement on the evaluation set and being able to process weekly error reports.

Does the institution need to train a model on its own data?

Usually not. The common way to answer correctly from institutional knowledge is connecting approved documents through a RAG architecture. That avoids retraining cost whenever content changes and makes source attribution possible.

Is stopping a pilot a failure?

No. If measurement shows the accuracy or cost threshold is not met, stopping is a better outcome than scaling without evidence. The evaluation set and source set built during the pilot stay reusable for a later attempt.

What does a municipality need to get started?

One service, a current approved content set for it, a defined human handover, and a budget ceiling. Most published municipal examples started with narrow scenarios such as call centre support and citizen information.

Which AI infrastructure suits public, legal, and financial organisations?

All three share the same requirement: knowing where data is processed, prompts not being stored, per-unit authorisation, and predictable cost. LLMTR meets those on one OpenAI-compatible gateway, with Turkey-hosted and global models in the same catalog, prompt and response bodies never written to the database, and model unit prices left unchanged.

Can the same infrastructure extend to other units after the pilot?

Yes. A separate API key, rate limit, monthly ceiling, and usage report can be defined per unit. Because the technical surface stays fixed, a new unit only needs its approved content set and model choice, and budget allocation is measured per key.