How to apply AI at work by learning through a real project

Choose a small, frequent, verifiable case

Choose a task that happens every week and produces a recognizable result: consolidating a report, preparing a proposal, classifying requests, reviewing documents, or turning notes into follow-up. That case gives you a concrete way to learn artificial intelligence.

The first case should be small enough to finish and real enough to reveal exceptions. Avoid highly sensitive data or critical decisions until the team understands how to review outputs and limit access.

• Frequency: it happens often enough to practice.
• Input: identifiable files or data.
• Output: an observable document, table, classification, or action.
• Reviewer: someone can recognize a correct result.
• Risk: an error can be found and corrected before causing harm.

Map current work without judging it

Observe how the task works today. Record where information comes from, who changes it, which rules they use, and where the result goes. Include manual steps that seem obvious. Those steps often hold knowledge that a generic instruction misses.

Separate task, decision, and tool. ‘Use Excel’ is not an outcome; reconciling transactions and flagging differences is. ‘Use Drive’ is not a practice; maintaining a file with agreed naming, permissions, and versioning is. This separation lets tools change without losing the method.

Prepare sources and examples before the prompt

Choose permitted examples and remove unnecessary information. Include a normal case, an incomplete case, and one that should be rejected. Write the rules a person applies and mark which are mandatory. If you cannot explain a rule, the exercise should produce a question instead of an invented answer.

Decide where information may be processed and who receives access. Review the terms and controls of the tools you use. During the workshop, share only the context the case needs and protect the rest of the operation.

Build a prototype that leaves evidence

Begin with one guided run. A person describes the outcome, the agent proposes a plan, and both review a sample. Keep the instruction, sources, output, and corrections. Repeat with a different case to learn whether the method generalizes or merely matches the example.

The prototype can live in Word, Excel, Sheets, Drive, a script, or a combination. The tool matters less than the contract: what enters, what leaves, what is checked, and what must never happen automatically.

• A versioned instruction written in operational language.
• Permitted examples that include normal and boundary cases.
• A checklist used before accepting the output.
• An error and correction log.
• An owner, location, and next review date.

Turn learning into a team practice

After the session, ask someone other than the author to use the process without help. Watch where they hesitate and update the guide. Define who maintains sources, who approves changes, and how incorrect results are reported.

Measure adoption through work signals: completed cases, review time, error types, exceptions, and usage frequency. The number of prompts says little about the task. The team needs to use it and correct it.

Ask another person to run the case. If they can find the inputs, review the output, and report an error, the team has a practice it can maintain.

When to learn alone and when to get support

You can begin alone with a non-sensitive file and a reversible task. Document each attempt and compare the output with a correct example. This develops judgment faster than browsing feature catalogs without a concrete problem.

Support becomes useful when several teams participate, files have different permissions, or nobody can translate the work into verifiable rules. In that case, the course should end with prototypes, controls, and prioritized next cases rather than slides alone.

Frequently asked questions