In this article
- Choose your first AI at work experiment
- Day one: establish the information boundary
- Day two: give the tool a concrete assignment
- Day three: compare the complete effort
- Day four: turn one useful result into a repeatable practice
- Day five: decide what to continue
- If your first experiment disappoints you
- Make your next step proportionate
This guide is a first-week onboarding route. It is designed for a professional deciding where to begin, rather than a catalogue of every tool or possible use case.
Choose your first AI at work experiment
Pick a task that is frequent enough to matter and small enough to inspect. Preparing questions from a public document or restructuring fictional meeting notes is a more manageable beginning than automating a consequential decision.
Ethan Mollick's introductory AI guide provides historical orientation. Models and products change, so use current documentation and your workplace policy when choosing the actual tool.
Write down the outcome before beginning. “I want a clearer three-part agenda from these approved notes” is easier to judge than “I want AI to improve my job.”
If you cannot identify a useful first task, list the work you repeat and circle the parts that involve drafting, organising or generating questions. Keep final decisions and sensitive judgements outside the experiment.
Day one: establish the information boundary
Find out which tools your organisation permits and what information may be processed. Ask the appropriate administrator or manager when the policy is unclear.
Use synthetic material while learning. Replace more than names: a distinctive customer situation, a private contract detail or a combination of dates can still reveal sensitive information.
Check whether the tool can access files or connected systems. Do not assume that opening a chat provides access to your work documents, or that permission to read one source permits sharing it elsewhere.
Microsoft's Copilot overview explains that experiences differ by licensing and grounding. Confirm what your own account supports instead of copying a colleague's expectations.
Day two: give the tool a concrete assignment
State the task, audience, relevant material and limits. A useful brief for a hypothetical training coordinator could be:
Organise these fictional workshop notes into a draft agenda for new supervisors. Put the learning outcome first. Separate confirmed activities from suggested activities. Do not invent company policies, timings or trainer credentials. List missing information at the end.
Inspect the answer against the notes. Mark unsupported details before asking for stylistic improvements.
If the output is weak, identify the reason. Missing context needs better input. An unsuitable task needs a different approach. A fabricated detail needs correction and a stronger verification step.
Day three: compare the complete effort
Observe preparation, generation, checking and correction. These parts together determine whether the tool helps.
You do not need a formal productivity claim. A short record can say that the outline was useful, but checking invented timings took longer than expected. That is honest learning.
Compare with your normal method under similar conditions. A familiar task on an unusually quiet day is not a fair basis for predicting gains across your entire workload.
Day four: turn one useful result into a repeatable practice
Save the parts of the brief that improved the output. Add a short acceptance checklist and an example of a common failure.
For the workshop task, the checklist might ask whether the audience is clear, the source material is preserved, suggestions are labelled and unsupported policies are absent.
Try a second input. A prompt that works once may fail when notes are sparse or contradictory. Keep the task narrow until you understand those limits.
Day five: decide what to continue
Choose to keep, revise or abandon the experiment. Do not keep an unsuitable approach simply because you invested time learning it.
If it helps, explain the workflow to a colleague using approved examples. Include what you check and what the tool must not do. A useful demonstration shows a limitation as well as a success.
If it does not help, preserve the observation. You may have learned that the task requires context unavailable to the tool, that preparation is too burdensome or that your existing method is adequate.
If your first experiment disappoints you
Diagnose the problem before concluding that either you or the technology failed. A weak result can come from an unclear task, poor source material, a capability limitation or a review requirement that makes the approach impractical.
If the answer is generic, check whether the audience and purpose were specified. If it invents detail, compare the instructions with the input and strengthen the evidence boundary. If it cannot access a source, confirm approved access rather than assuming the file was read.
If checking takes longer than your normal method, record that result honestly. Try a narrower contribution, such as outlining rather than drafting the entire document, or stop using the tool for that task.
Also distinguish unfamiliarity from unsuitability. You may need a little practice to give a clear brief, but repeated errors in an important requirement are a reason to reconsider the workflow. Do not keep widening access or adding complexity simply to rescue the original idea.
The first week should leave you with better judgement about one task. It does not need to produce a transformation story, a public recommendation or a claim about productivity.
Make your next step proportionate
Begin with a private, bounded exercise rather than redesigning your job on day one. Expand only when the work, information and review requirements are clear.
Explore PiOfAI, the personal AI workflow guide and the AI procedure guide when your first experiment is ready to become a dependable routine.
AI-assisted researched guidance from PeakBelt. Hypothetical examples are labelled in the text. See our editorial approach.