Vice President · TheGreyMatter.ai
In brief
The first month should produce a decision about one workflow, supported by observed work and clear limitations.
Key takeaways
- Choose one recurring task with a named user and a visible baseline.
- Run the pilot beside the existing process before granting consequential authority.
- End the month with an explicit expand, narrow, repair, or stop decision.
A founder's first AI pilot should answer a practical question: can this bounded workflow produce useful work under the conditions the business actually faces? Thirty days is a proposed planning window, not a promise of production readiness. The schedule below turns the month into a sequence of decisions. Move more slowly when data access, affected people, or the consequences of failure require additional preparation.
Days 1 to 5: choose a task worth measuring
Observe a recurring task that already consumes attention. Candidates might include preparing an internal meeting brief, extracting approved fields from documents, or organizing authorized customer feedback. Pick a task with a clear recipient and a visible completion standard. Avoid starting with an assistant expected to run the company. Broad ambition makes it difficult to separate a promising result from a demonstration assembled around favorable inputs.
Write a one-page task contract: current process, inputs, expected output, acceptance criteria, owner, exclusions, and manual fallback. Measure several ordinary examples, including preparation and review time. Record what happens when information is missing. Choose a decision the pilot will support at the end of the month. A hypothetical internal brief might need to save preparation effort without increasing factual errors or obscuring unresolved questions.
Days 6 to 10: establish evidence and boundaries
Collect a small, authorized set of representative cases. Include straightforward examples, ambiguous evidence, stale sources, and requests outside the intended scope. Write expected facts or behaviors before showing the cases to the model. Keep some cases separate for the final comparison. Do not connect every company system merely because a connector exists. Start with the minimum information needed to evaluate the chosen task.
NIST's AI RMF organizes risk work through govern, map, measure, and manage. A founder can use those categories as questions about ownership, context, evidence, and response. They do not certify a pilot. For this proposed schedule, identify who can pause the experiment, what information it may process, which actions require approval, and what observation would end the trial early.
Days 11 to 17: build the smallest working comparison
Create the simplest implementation that can satisfy the task contract. Start with explicit instructions and supplied evidence before adding retrieval, tools, or training. Run the same development cases through the manual baseline and assisted workflow. Record accepted outputs, important errors, review minutes, and unresolved cases. Keep the model and configuration identifiable so a change in results can be connected to a change in the system.
Fix one recurring failure category at a time. If the wrong source appears, improve evidence selection. If the answer format is inconsistent, improve instructions or validation. If the task itself is ambiguous, clarify its owner and standard. Maintain a short change log containing the problem, intervention, and observed effect. This prevents a week of adjustments from becoming an undocumented story about how the model seemed better by Friday.
Days 18 to 24: run beside the existing process
Let a small authorized group use the workflow on real work while the existing process remains available. Keep consequential outputs under the agreed review. For an internal brief, users could compare the assisted draft with their normal preparation before the meeting. Do not infer permission to send customer messages, alter records, or make commitments from permission to experiment. Grant additional authority only through the business's normal decision process.
Log the practical friction as well as technical failures. Did users understand the output? Could they find its evidence? Did reviewing it take longer than doing the task? Were the exceptions routed to someone who could resolve them? Ask what users stopped doing, what they added, and what remained unchanged. These observations help distinguish a useful workflow from an attractive extra step that quietly increases the team's workload.
Days 25 to 30: make the operating decision
Run the reserved evaluation cases and compare the result with the original baseline. Show the task mix, sample size, accepted output rate, important failures, review effort, and full operating cost. Identify what remains untested. A month with few difficult cases cannot establish reliability under conditions the pilot never encountered. Preserve this limitation in the decision record instead of projecting the most favorable result across the whole business.
Choose one outcome: expand within the tested boundary, narrow to the cases that work, repair a specific failure, or stop. Name the owner and next review date if the pilot continues. The handoff should include the task contract, evidence, configuration, limitations, and fallback. A stopped pilot can still produce useful knowledge about the workflow. The month succeeds when it leaves the founder with a defensible decision and a clear next action.
Common questions
Does a 30-day pilot need a custom model?
Usually the first question is whether an existing model and a bounded workflow can meet the task standard. Consider more complex architecture only after observing a failure that simpler changes do not address.
What should a founder have at the end of the pilot?
A documented expand, narrow, repair, or stop decision, supported by a task baseline, evaluation results, cost assumptions, known limitations, an accountable owner, and a usable fallback.
Sources and evidence
AI assisted editorial analysis. Primary sources checked October 10, 2026. The procedures are editorial recommendations, not vendor instructions, reported customer results, or claims of personal experience. Numerical examples are hypothetical.
One useful next step: Choose one idea from this note and test it at the smallest scale that could teach you something this week.
