Practical AI · 4-minute read
Somewhere, a committee is choosing the name of an AI initiative. The name needs to sound bold, fit on a slide and suggest that everyone will be working very differently by Q3.
Meanwhile, somebody is spending Friday afternoon turning six project updates into one project update.
I’d start with that person.
Your first AI project can be wonderfully unglamorous. Give it one recurring annoyance to work on, a clear finish line and a human who knows what good looks like. It may never get a launch video. Somehow, the business will survive.
Find the task people quietly resent
Look for work that happens often, follows a recognizable pattern and produces something a person can check. Reformatting approved project notes into the weekly status report is a reasonable candidate. Deciding which employees deserve a promotion is a very different proposition.
Ask the person doing the work where the time actually goes. If the delay comes from waiting for someone to approve a number, a faster paragraph generator will mostly help you wait in a more professional font.
For a first experiment, choose a task with these features:
One clear output. “Draft this week’s internal status report” gives you something to evaluate. “Transform operations” gives you something to put on a mug.
Known source material. Use information your organization permits in an approved tool. Start with non-sensitive material where possible.
A named reviewer. Someone checks the draft against the source before it goes anywhere.
A manageable failure. A bad draft can be caught and discarded without changing a customer’s account or somebody’s livelihood.
Time the whole job
Here’s an illustrative example, not a client result: the weekly report currently takes 45 minutes. With AI, preparing the notes takes 8 minutes, generating the draft takes 2, and reviewing and correcting it takes 15. That’s 25 minutes of work, with 20 minutes saved—if the final report meets the same quality standard.
The two-minute draft is the exciting bit. The other 23 minutes would also like to be included in the presentation.
Track the full process across several normal work cycles. Count missing facts, invented details, corrections and the time spent getting the result ready to use. Include setup and tool costs when deciding whether the experiment is worth keeping.
Ask the person receiving the report whether it is actually useful. A shorter production time is less impressive if three colleagues now need a meeting to decode it.
Give the experiment a small job description
For the status-report example, try this in your approved tool:
Using only the project notes below, draft an internal weekly update under three headings: Completed, Next steps and Blockers. Preserve names, dates and numbers exactly. Do not invent progress or resolve conflicting information. Put missing or conflicting details in a Questions for review section. Include a source-note reference for each item so I can check it.
Then do the checking. A source reference is useful only if it points to something the source actually says.
Before starting, agree on what would make you keep, change or stop the experiment. For example: less total handling time, the same or better final accuracy, and every draft reviewed before use. Pause if the tool needs information you aren’t permitted to share or keeps producing errors the reviewer cannot reliably catch.
A failed small experiment can still answer a useful question. There is no prize for keeping a bad process alive because it already has a logo.
Get one ordinary task working well. Document it. Teach someone else to use it. Then consider the next one.
Boring pays rent. The committee can put that on the mug.
One thing to try: Ask your team, “Which recurring task eats time without requiring much judgment?” Listen before suggesting a tool.
Further reading: NIST’s AI Risk Management Framework Playbook: Measure covers evaluating AI in its actual use context. The example and practical recommendations above are the author’s.
