A practical guide · AI at work
How to get started with AI in your business
Do not begin by choosing a model. Start with a workflow that costs time or creates friction today. This guide shows how to shape it into a useful first AI pilot, with the right data, clear limits, and a measurable decision at the end.
The path to a first AI pilot
Six decisions, from workflow to test
You do not need to solve everything at once. Each step clarifies one requirement and makes the next decision easier.
01STEP
Start with a real workflow
A useful starting point is not an abstract AI ambition. It is a task people already perform.
Look for repeated searching, waiting, or manual checks in day-to-day work. Examples include finding details across documents, sorting incoming requests, or checking files for missing information.
Map the work from trigger to result: what comes in, what decisions people make, which systems they open, and where a person takes over. That reveals whether AI could help. A clearer process may solve the problem first.
Questions to answer at the outset
- How often does this happen, and how much time does it take?
- Where do people search, copy, check, or wait for an answer?
- What would a useful result look like to the person doing the work?
The outcome is one observable workflow bottleneck, not a wish list for AI.
02STEP
Choose the right first use case
A good pilot is frequent enough to matter, narrow enough to manage, and tied to a result you can measure.
Choose one task rather than an entire department. State what should improve, such as less time sorting requests or less rework checking documents. Identify who will use the result and record how the current process works.
Limit the cost of mistakes. A summary may be checked by sampling; an approval, payment, or customer decision usually needs a defined human review. Start where errors are visible and can be corrected.
Questions to answer at the outset
- Can you compare the goal before and after the pilot?
- How often does the task occur, and who will actually use the result?
- Which mistakes are inconvenient, and which could cause real harm?
The outcome is a pilot with a goal, users, scope, and an explicit error boundary.
03STEP
Check the data and knowledge for this use case
The question is not whether every company dataset is perfect. It is whether the sources this workflow needs are suitable and accessible.
List the actual sources: emails, manuals, CRM records, spreadsheets, or documents in a business system. Check whether they are current, findable, and understandable, and whether duplicates, old versions, or missing labels could confuse the result.
Clarify ownership and permissions too. Who maintains each source? Which users may see it? Does the solution only need to find documents, or does it need structured fields and reliable metadata? These answers show what data preparation is genuinely necessary.
Questions to answer at the outset
- Which sources does the pilot need, and what is out of scope?
- Who owns the quality, updates, and access rights for each source?
- Which gaps or outdated records could distort the result?
Prepare only the data issues that materially affect the chosen use case.
04STEP
Set requirements and human guardrails
Before choosing a solution, decide what it may do, what it must not do, and how people will review its output.
Clarify privacy, information security, access rights, logging, and traceability. Decide which data must not leave a trusted environment and whether answers need to cite their sources.
Set the quality you need and define what happens when an answer is uncertain or incomplete. Decide when the system should say so, stop, or escalate. Name the people responsible for day-to-day operation, access changes, and keeping the knowledge current.
Questions to answer at the outset
- Which information is sensitive in this specific workflow?
- Must answers show their sources or be approved before use?
- Who owns subject-matter review, operations, and ongoing maintenance?
Guardrails belong in the design from the start, not in a review after the build.
05STEP
Choose the capability and deployment
The model question comes later. First decide what work the solution should do and how it will fit into the process.
Finding knowledge often calls for search that returns relevant sources. Summaries may benefit from a language model. Repetitive rule-based steps may be handled by conventional automation; classification can help sort items. Many solutions combine these building blocks.
Then compare how the solution will run: an existing product, an API integrated with your systems, or a more controlled environment. Consider integrations, permissions, costs, logging, and maintenance. Model names or benchmark scores alone are not enough.
Questions to answer at the outset
- Do you need search, summaries, classification, automation, or a combination?
- Which sources and systems must the solution reach, and with what permissions?
- Which setup meets security, integration, and operating needs?
The right choice follows from the task, data access, integration, and control. The model alone does not determine it.
06STEP
Test small, measure, and decide
A pilot is a bounded learning step, not a miniature rollout without success criteria.
Set the scope, period, user group, and owner before starting. Record a baseline for the current workflow, including time, quality, errors, or follow-up questions. Then choose a few measures that indicate real value.
Do not measure only whether the system produces an answer. Track corrections, failure cases, actual use, and whether the work improves. Keep examples of good and poor results so the team can make focused changes.
Questions to answer at the outset
- Which measure would show real value in this workflow?
- How many results still need human correction or review?
- What threshold will lead you to adapt, expand, or stop?
Finish with an evidence-based decision: adapt, expand carefully, or stop.
Contact
Tell us about a process you want to improve. We will map its data and systems, then discuss a secure first step for AI.
