Your first AI project should probably be boring

Introduction

A strong first project helps the agency learn how to choose, test, govern and improve AI while protecting clients and staff.

A first AI project attracts too much ambition. Someone proposes a public chatbot. Someone else wants to predict which clients will disengage. A vendor demonstrates an assistant that appears to understand case notes in seconds.

These ideas are interesting. That is precisely why they are poor places to learn.

An agency's first project should build organisational capability, not stage a technology demonstration. The useful outcome is not merely a working tool. It is a team that can define a problem, handle data properly, test outputs, spot failure, assign responsibility and decide whether to continue.

A boring workflow is a good classroom for that work.

Start with the work itself

NCSS's Social Services Digitalisation Playbook takes a mission-driven and user-centred approach. It points agencies towards digital strategy, journey mapping, workforce skills, data governance, cybersecurity and data protection, rather than treating technology procurement as the whole project.[1] The Digital Acceleration Index (DAI) similarly asks agencies to understand their digital maturity and use that assessment to shape a suitable strategy.[2]

That context matters. An AI pilot cannot compensate for a workflow nobody owns, inconsistent source documents or unclear data rules. It will usually expose those weaknesses faster.

Before discussing tools, write down one recurring job in plain language:

Define the recurring job

If the team cannot complete that sentence, it has not found an AI project. It has found a process-discovery exercise. Do that first. NCSS's Tech-and-GO! guides make a similar distinction by offering separate resources for digital strategy, solution evaluation and project implementation.[3]

Why the score is only a starting point

A candidate scoring 13 to 16 is promising. Nine to 12 needs redesign. Eight or below should wait.

Those thresholds are an editorial method from Social Tech Guild, not an NCSS, IMDA or PDPC requirement. The criteria are informed by a broader principle in Singapore's voluntary Model AI Governance Framework: the level of human involvement should reflect the probability and severity of harm, together with the nature and reversibility of harm and operational feasibility.[4] A project that could deny someone a service is not made safe because it happens frequently.

Build evidence through the pilot

Before launch, agree on a small test set, expected outputs and unacceptable failures. Keep the existing workflow running during the pilot. Record edits and rejected outputs, including cases where the tool was confidently wrong.

For generative AI applications, IMDA's voluntary LLM testing starter kit identifies five risk areas: hallucination and inaccuracy, bias in decision-making, undesirable content, data leakage and vulnerability to adversarial prompts. It recommends a context-specific sequence of identifying relevant risks and thresholds, testing, then assessing results and mitigations.[6] A small agency pilot will not need every technical test in the kit, but it does need examples drawn from its actual workflow and a threshold agreed before people see favourable results.

At the end, ask three questions:

1. Did the workflow improve under realistic conditions?
2. Did our controls catch the failures we expected and the ones we did not?
3. Can we run this responsibly without depending on one enthusiastic staff member or vendor?

“Not yet” is a valid result. So is choosing ordinary automation instead of AI. The first project's job is to improve the agency's judgement. If it does that while saving some time on an unglamorous task, it has succeeded.

About the author

Darren writes about practical technology choices for Singapore's social service sector through Social Tech Guild.