How to start using AI at work

A useful first AI task ends with something you can check: an action list, a research brief, a draft response or a proposed code change.

That makes the starting decision concrete. Which task repeats often enough to matter? What information can be shared? What would a correct result look like? Who will review it?

Answer those questions before opening several tools. The goal of a first pilot is to learn whether AI improves a specific piece of work under conditions your team can sustain.

Choose a task with a checkable output

List a few tasks from the previous week. Look for work where gathering, restructuring or drafting information takes time and where someone already knows how to judge the result.

Examples include turning approved meeting notes into actions, organizing product questions, preparing a brief from supplied documents or suggesting tests for a small code change.

A first task should have three useful properties:

• Available information: the necessary source material exists and can be used in the chosen tool.
• Visible correctness: a reviewer can identify missing details, unsupported statements or incorrect calculations.
• A contained outcome: the output can remain a draft until someone accepts it.

“Improve our marketing” is too broad to evaluate. “Prepare a comparison of three competitors' documented export options” gives the investigation a boundary.

AI Chronicle

Prefer a small complete task

A bounded task should still produce something useful. Asking AI to summarize a single sentence may teach little about a real workflow. Asking it to overhaul an entire sales process combines too many decisions.

A better starting unit might be one meeting's action list or one comparison brief. It is large enough to expose practical problems and small enough to inspect completely.

Delay tasks whose errors are hard to detect

A task is a weak pilot if the team cannot tell whether the answer is right. Unfamiliar legal analysis, unsupported financial forecasts or a production-system change can leave a beginner evaluating confidence instead of correctness.

Choose work where the reviewer has relevant knowledge and access to the underlying evidence. If those are unavailable, change the task or involve someone who can assess it.

Check what information can be used

Before uploading a document, identify the approved account, permitted information and person responsible for the output.

NIST's generative-AI risk profile includes privacy risks and confidently incorrect content. Its guidance makes the surrounding use of a system important, rather than treating an answer in isolation.[1]

A practical pilot needs answers to questions like these:

An organization’s approval matters even when a tool is available to an individual employee.

Check the account and plan, not just the brand

A provider can offer different terms across products and accounts. For example, OpenAI states that business data from its covered business products and API is not used for model training by default, while describing opt-in exceptions.[2]

That documented commitment answers a particular training-use question. It does not, by itself, establish that a specific file may be uploaded under an employer's rules, that nothing is retained or that every connected service has the same terms.

Check the relevant settings and agreement for the actual deployment. Removing a customer name also may not remove every confidential detail in a document.

For an initial exercise, synthetic material or approved public information can let the team test the workflow without using restricted records.

Choose a tool for the task

Choose the required capability before comparing product names.

This table describes selection criteria, not a guarantee about any particular tool.

For a simple writing or organization pilot, begin with one permitted assistant. A comparison of Claude, ChatGPT and Gemini can help frame the choice, but the deciding evidence should come from the team's own task and review criteria.

Avoid judging a tool only by how fluent its first answer sounds. An output that looks professional may still omit a qualification or invent a detail.

Keep permissions proportionate to the pilot

If the goal is to prepare a response, generating a draft is sufficient. Sending messages, changing customer records or publishing content are additional responsibilities.

Introduce those operations separately, with their own authorization and checks. A successful drafting exercise does not automatically establish readiness for execution.

Give a brief with enough context

A useful prompt specifies the deliverable, information to use, constraints and what should happen when something is missing.

Anthropic's prompting documentation states:

“Claude responds well to clear, explicit instructions.”

— Anthropic, Prompting best practices.[3]

That is provider guidance, rather than an independent performance guarantee. Its practical value is a reminder to describe what the reviewer will actually check.

Use this reusable brief:

Task:
Create [specific deliverable] for [reader or business purpose].

Source material:
Use the approved material below. Distinguish source facts
from any suggestions you add.

Output:
Return [required fields or format].

Constraints:
Preserve [important details].
Do not invent [owners, dates, claims or other missing facts].

Missing information:
Mark unknown items clearly and list questions for review.

Before finishing:
Check the output against the requirements and identify
anything that still needs human verification.

The final instruction is an additional check, not a substitute for independent review.

Include an example of the expected output

If the team expects a particular structure, supply one small example. An action list, for instance, might use the columns action, owner, due date and supporting note.

Keep the example compatible with the real task. If it contains a date for every row, make clear that the model should preserve unknown dates rather than filling every cell to imitate the example.

Change one important variable at a time

When a result is poor, inspect the problem before rewriting the entire prompt.

Was the information missing? Was the required format unclear? Did the model infer a decision that the notes never established?

Change the relevant part of the brief and repeat a comparable task. That makes it easier to understand whether the revision helped.

A worked example: meeting notes into an action list

The following is a synthetic example of a proposed workflow. The table is an illustrative intended output, not a response captured from a tested product.

Suppose these approved notes need organizing:

Monday project check-in:
Maya will draft the onboarding email by Thursday.
Omar will check why activation declined; no deadline agreed.
The team discussed changing the pricing page but did not decide.
A revised launch date needs confirmation.

A useful prompt would be:

Turn these notes into an action list for internal review.

Use the columns: action, owner, due date, supporting note.
Include agreed actions only.
Do not turn discussion into a decision.
Keep relative dates as written unless a calendar date is supplied.
Write "not specified" for missing owners or deadlines.
Put unresolved questions after the table.
Do not send messages or change a project system.

What an acceptable draft would contain

The unresolved questions should include who will confirm the launch date and whether a pricing-page change will be approved.

The notes do not justify creating an assigned pricing-page task. They also do not establish a calendar date for “Thursday.”

Where the review adds value

Compare every action against the notes. Check that discussion did not become an instruction, an unknown owner did not become a named person and a missing deadline did not become a plausible date.

If a manager confirms an unresolved point, record that new information before revising the action list. The accepted output should preserve the difference between what the notes said and what was decided afterward.

This exercise teaches a repeatable habit: define the boundary, preserve uncertainty and inspect the deliverable.

Review the output before it is used

Choose review checks that match the task. A writing draft needs checks of meaning and claims; a spreadsheet analysis needs checks of calculations and definitions.

NIST's generative-AI profile recommends reviewing and verifying sources and citations in outputs during testing and ongoing monitoring.[1]

For research, open the cited material and inspect the passage supporting the claim. A valid URL alone does not establish that the source says what the answer claims. A fuller method for verifying AI-generated research can help make this check repeatable.

Check omissions as well as errors

A summary can contain only true statements and still leave out the condition that changes the conclusion.

Check whether the output preserves important limitations, disagreements and unanswered questions. In the meeting example, the absence of a launch decision is itself useful information.

Keep judgment with someone who understands the task

“Human reviewed” is meaningful only when the reviewer has time, context and a clear standard.

Define what that person should check. For the action list, inspect the source-to-action mapping. For code, examine intended behavior and relevant checks. For an analysis, reproduce important calculations and inspect alternative explanations.

If verifying the answer requires rebuilding the task from scratch every time, that is part of the pilot's result.

Measure the complete workflow

The time until an answer appears is only one part of the work.

Record preparation, generation or waiting, verification, correction and any final transfer into the system where the output is used.

NIST's AI Risk Management Framework states:

“AI systems should be tested before their deployment and regularly while in operation.”

— NIST, AI Risk Management Framework 1.0, Measure function.[4]

This article's pilot framework is AI Chronicle's proposed approach, not a formal NIST checklist or certification.

Count active work and elapsed time separately

Suppose a manual task takes 30 minutes of active work. An assisted attempt takes 4 minutes to prepare, 2 minutes of unattended generation, 8 minutes to review, 6 minutes to correct and 2 minutes to transfer.

That is 20 minutes of active human work and 22 minutes of elapsed time, assuming the generation needs no supervision and the steps occur in sequence.

These are invented figures to explain the calculation. They do not predict the savings from using AI.

Compare quality too. A faster output that fails an essential requirement should not count as an acceptable completion.

Use several representative inputs

Record ordinary cases alongside difficult ones. Include missing information, conflicting notes and a task that should be escalated.

A small first pilot can reveal obvious problems, but it cannot establish a universal success rate. Keep the model, account, prompt and input conditions recorded so the observations are interpretable.

For a more detailed measurement framework, measuring AI productivity should include review work and unsuccessful attempts.

Read research within its scope

A 2023 Harvard/BCG field experiment involved 758 consultants. Harvard's summary reported performance gains on tasks within the model's capability frontier, while emphasizing uneven capability across tasks.[5]

A different randomized study examined 16 experienced open-source developers completing 246 tasks with early-2025 tools. It reported that allowing those tools increased completion time by 19% in that setting.[6]

These studies involved different populations, tasks, tools and periods. They do not establish that AI makes all work faster or that current tools make all developers slower. Their useful implication for a pilot is to measure the actual workflow instead of importing an average from another setting.

Run a first-week pilot

Treat the first week as a learning period, not a deadline for proving a return on investment.

AI Chronicle

Day 1: choose the task and baseline

Identify the output, approved information and reviewer. Record how the manual version is completed and what makes it acceptable.

Day 2: write the brief

Prepare the prompt, example structure and missing-information rules. Decide how you will record results and failures.

Days 3–4: run and review

Use representative inputs. Inspect every draft against its source material and note where prompting, review or correction is needed.

Day 5: compare the complete effort

Compare active human work, elapsed time and acceptable outputs. Include failures and any setup effort relevant to continued use.

Days 6–7: decide what happens next

• Keep: the task produces useful reviewed outputs under repeatable conditions.
• Revise: a specific fix to inputs, instructions or review appears worthwhile.
• Stop or defer: the output cannot be trusted within the review capacity available, or the effort is not justified.

A completed pilot may reasonably end with a decision not to continue that task.

Adapt the starting task to the business

The same pilot method can support different functions. These are proposed starting tasks, not measured case studies.

For AI in marketing, keep the first task close to a specific brief or research question. For AI in ecommerce, distinguish preparing an answer from changing an order or issuing a refund.

Automate after the task is understood

Once a task has a useful brief, evidence sources and review criteria, consider whether connecting tools would reduce additional work.

A tool-using AI agent introduces further decisions about access, execution and stopping rules. Evaluate those responsibilities separately from the quality of a draft response.

The starting workflow should be understandable before more actions are attached to it.

Questions readers commonly ask

Do I need coding skills to start?

A first pilot can use a permitted assistant with approved input and a clear output brief. Coding becomes relevant when integrations or custom controls are needed; it is not the first requirement for a drafting exercise.

Should I begin with a free or paid account?

Begin with the account the organization permits and the capabilities the task requires. Do not use price alone to decide whether business information can be shared. Check the actual product terms and settings.

Is a detailed prompt enough to make the result accurate?

No. A better brief can clarify the task, but it does not establish that every fact, calculation or citation is correct. Keep independent checks for the parts that matter.

How much time should AI save?

Set a task-specific expectation after recording the baseline and review requirements. Some workflows may be valuable for quality or consistency rather than speed. State which outcome justifies continued use.

The next step

Choose one recurring task, write its output requirements and decide how the first result will be checked. Run the pilot before expanding the responsibility.

If research and writing are the selected tasks, the Claude review is the next reading step: use its task evidence and limitations alongside the requirements of your own pilot.

Sources and evidence note

Sources checked on 14 October 2026. This is a sourced explainer with AI Chronicle's proposed framework. The meeting notes, intended output and time calculation are synthetic illustrations. No hands-on product test or observed business savings are claimed.