How to choose your first AI project
Start with a task that someone can describe from beginning to end. Who receives the request? What information do they consult? What do they deliver? Who checks it? A description such as preparing a draft of a sales response is more useful as a starting point than automating the entire sales operation.
Compare the current process with the proposed one before choosing a model. If the rule is stable and the data is already organized, a conventional integration may solve the problem. AI becomes an option when the task involves interpreting language, locating context, or producing a draft that someone will review.
My recommendation is to prioritize a task with available examples, a designated owner, and the option to return to the previous process. Without these three elements, the first task is to organize the operation. Automation comes afterward.
- Write the expected input and output in one sentence.
- Record the execution and review time for the current process.
- Define the error that would make the delivery unacceptable.
- Choose who can approve changes and stop the pilot.
Automation, RAG, or AI agents?
These approaches can coexist. An automation follows known steps. A RAG workflow looks for reference information to support the model's response. An agent chooses actions during execution, within the tools and permissions it has received.
Anthropic distinguishes predefined workflows from agents and recommends starting with the simplest solution that works. OpenAI's retrieval documentation describes semantic search over documents. This helps you choose the architecture, but it does not by itself resolve the quality of the source or permission to access it.
| Situation | Starting point | What to check |
|---|---|---|
| Predictable steps and rules | Conventional automation | Validation, exceptions, and integrations |
| Response depends on documents | Search or RAG | Permissions, freshness, and source evidence |
| Next action depends on context | Agent-based workflow | Permitted tools, approval, and execution limits |
Where AI can help a team
The examples below are hypothetical software designs, not results attributed to clients. They help separate what the system prepares from what a person needs to decide.
In sales, the application can organize meeting notes and suggest CRM fields. In legal work, it can locate documents and highlight passages for professional analysis. In compliance, it can gather evidence with its origin recorded. In HR, it can guide searches of internal policies without selecting candidates or making decisions about people.
The limit needs to be visible in the interface. A suggestion should be recognizable as a suggestion, with access to the material used. When information is missing, the workflow should allow someone to request context or forward the request. A plausible answer is not evidence that the task was solved.
What to measure before going into production
Define acceptance criteria before testing. Build a sample containing common situations, exceptions, and incomplete requests. Set aside some examples to check future changes. OpenAI's evaluation best practices reinforce task-specific testing and continuous evaluation rather than relying only on the impression created by a demonstration.
For document extraction, check correct fields, missing fields, and invented information. For an internal search, verify that the cited passage supports the answer and that the user could access the source. For a workflow that proposes an action, check the parameters and the approval point.
Also count the work that remains for the team. Time until approved delivery, rework, cost per task, and the frequency of human escalation are possible measures. There is no single target that works for every operation. The process owner needs to define what is acceptable and in which cases the pilot should stop.
What implementation involves
The model is one part of the application. There is also systems integration, access control, data validation, action logging, failure handling, and a way to correct the result. Whoever maintains the information source needs to know when a change affects the workflow.
When putting it into operation, explain what the tool does, where it typically needs help, and how to report a problem. A useful error report includes the input, the observed output, the expected result, and the context permitted for investigation. This record can become a test case.
Adopting AI also involves deciding what will remain manual. A review that catches important errors can be part of the product. If the team needs to redo almost every delivery, revisit the scope, data quality, or chosen approach before expanding usage.
A worksheet to make the project concrete
Answer these questions with the person who performs the task. The worksheet is a starting point for a discovery conversation, not an automatic feasibility score.
- Task and owner
- What deliverable do we want to improve, and who is responsible for it?
- Input and source
- What data comes in, who can access it, and who maintains it?
- Current reference process
- How is the task done today, how much review does it require, and what errors already occur?
- Acceptance criteria
- What does a deliverable need to meet, and which failures require stopping?
- Testing and review
- Which examples represent the routine, and who will compare the results?
- Usage and contingency
- How will the team use and correct it, and return to the previous process if necessary?
Technical references
The references support the technical distinctions. The selection criteria and worksheet are a practical synthesis for discussion and adaptation to your context.
Blog: editorial policy
