1. Pick one narrow task
The projects that work start with a task a person currently does by reading or typing: extracting fields from documents, classifying incoming tickets, drafting a first reply, summarising a long thread. Pick one, define what a good result looks like and who checks it. A feature called AI assistant with no defined job is the most reliable way to burn budget.
2. Ground the model in your data
A general model does not know your prices, policies or contracts. The common approach is retrieval-augmented generation: find the relevant passages from your own content first, then give them to the model with the question and instruct it to answer only from them. Ask it to cite the source passage. That makes errors traceable, since a wrong answer usually points to a wrong or missing source document.
3. Keep a human where mistakes are costly
Decide per action what the model may do alone and what needs approval. Reading and summarising can usually run unattended. Sending an email to a customer, changing a record or spending money should have a person approve at first, and move to automatic only after the error rate on real cases is known and acceptable.
4. Put the provider behind an interface
Models, prices and terms change quickly. Call the provider through one small module in your code, and keep prompts and settings in configuration rather than scattered through the app. Then switching from one provider to another, or to a cheaper model for simple tasks, is a contained change.
5. Handle data and privacy deliberately
Before the first prompt is sent, write down the answers to these.
- Which personal or confidential fields can enter a prompt, and can they be masked first?
- What does the provider's agreement say about retention and training on your data?
- What do you log, for how long, and who can read it?
- Do local data-protection rules in your market restrict where data may be processed?
6. Control cost and failure
Set per-user and per-day limits, cap output length, cache repeated requests and use a smaller model for simple steps. Handle the provider being slow or down with timeouts, retries and a graceful fallback in the interface. An integration with no limits is a bill waiting to happen.
7. Measure quality before and after launch
Collect fifty to a hundred real examples with the answers you expect, run them through the system, and score the results. Repeat that after every prompt or model change so you can see whether it got better or worse. Without this you are judging by the last demo. Once live, log the cases people correct, since those are your next test examples.