The fastest way to waste an AI project is to start with a grand plan and no clean source of truth. The second fastest way is to call the demo a success and hope the mess sorts itself out later. It usually does not.

I keep coming back to a simple pattern. Start with the data. Then test the smallest useful version of the idea. That order is boring, which is exactly why it works.

Most AI work fails for a familiar reason. The team jumps to the model, the chat UI, or the agent. But the real problem is often upstream. The documents are stale. The answers live in five places. The labels are uneven. The process is fuzzy. AI can still produce text in that setting, but it cannot invent trust.

Data prep is where the work becomes real. It means finding the right source material, checking who owns it, cleaning what is broken, and deciding what the system is allowed to use. For a knowledge-based workflow, that also means making the content searchable and readable in a consistent way. If the system cannot tell where a fact came from, the rest gets shaky fast.

This is where small pilot projects earn their keep. A pilot is not a tiny version of a dream. It is a narrow test of one useful workflow, with real inputs and a human backstop. The goal is to learn whether the idea holds up under the pressure of actual work.

A good pilot has tight boundaries. One process. One team or one channel. One source of truth, or as close to one as the organization can manage. That keeps the problem visible. It also keeps the blame small when the first version behaves like software, which is to say, with occasional poor judgment.

The temptation is to add more scope because the pilot feels underpowered. That is a trap. More sources create more edge cases. More edge cases create more confusion. Confusion then gets mistaken for AI being “not ready,” when the real issue is that the pilot was asked to prove too much.

The useful move is to separate foundation work from product behavior.

Foundation work includes:

• collecting a representative set of documents or records
• checking for missing, duplicate, or outdated content
• defining ownership for each source
• deciding which material is authoritative
• setting a simple rule for what the system may and may not use

Product behavior includes:

• how the output is written
• when the system should refuse to answer
• how uncertain cases are handed to a person
• how the team reviews mistakes
• how results are logged for later inspection

That split matters because the same model can look brilliant in one setup and clumsy in another. Often the model did not change. The surrounding work did.

A small pilot also gives a team something better than opinions. It gives them evidence from real cases. Not a grand benchmark. Not a slide deck with a heroic chart. Real examples. That is where the gaps show up. Maybe the data is good but the instructions are vague. Maybe the instructions are fine but the source docs are a mess. Maybe the workflow is useful, but only after a person checks the edge cases. These are not failures of principle. They are normal findings. Useful ones, too.

Here is a simple hypothetical example. A support team wants AI help drafting replies to common customer questions. The first instinct is to connect the model to every internal folder and let it figure things out. That sounds efficient for about six minutes.

A narrower pilot starts differently. The team picks a small set of approved product documents, a short list of common questions, and a clear review step. They define the tone, the length, and what the AI must never guess. Then they test the workflow on a few dozen real cases. Some answers work well. Some need better source material. Some need human review every time. That is useful information. It shows where the process is strong and where the organization still depends on people, which is usually the honest state of things.

The point of data prep is not perfection. It is fitness for use. The point of a pilot is not applause. It is to learn whether the workflow can survive contact with reality.

That survival depends on a few plain habits. Keep the source set small enough to inspect. Keep the scope narrow enough to explain. Keep the review path visible. Keep notes on what the system got wrong. Those notes are not paperwork for its own sake. They become the fix list for the next version.

I also think teams underestimate how much AI work is operational work. Once the pilot starts, someone has to watch failures, update the source set, and decide when a change is safe to release. If nobody owns that, the system slowly turns into an old cabinet full of unlabeled cables. Technically present. Socially abandoned.

This is why start-small thinking is not timid. It is disciplined. A small pilot makes the hidden work visible before the organization bets its patience on the wrong shape of solution. It gives delivery teams a way to prove value without pretending the hard parts do not exist.

In practice, that means the first question is not “What can the model do?” It is “What data can we trust, and what narrow task can we test with it?” Once that is clear, the project can move from speculation to evidence.

That is the kind of progress I trust. It is plain, testable, and easier to hand over when the original team moves on. That is also the kind of work The Practical Signal is meant to notice: one grounded observation about AI, technology, and the work required to make it useful.