Choose one repeated decision
Avoid starting with a department-sized goal such as automate lead operations. Choose one repeated decision or transformation: classify an intake, extract fields from one document family, draft a response from approved sources, or route a request under known rules.
Record who performs it now, how often, what information they use, where errors appear, and who owns the consequence. That is the baseline the pilot must be compared with.
Separate deterministic rules from model judgment
Use ordinary code for exact validation, thresholds, state transitions, permissions, and required fields. Use a model only where language or unstructured input requires interpretation. The boundary should be visible in the architecture and test suite.
- Schema and required-field validation stays deterministic.
- Permission and side-effect rules stay deterministic.
- Model output is parsed into a closed structure.
- Unsupported or low-confidence output has an explicit fallback.
Define approved data and retention
Inventory every input, retrieved source, prompt component, model output, log, and destination. For each, record whether personal or confidential data may appear, which provider processes it, how long it is retained, and who can inspect it.
Public demo data and production data require different controls. A convincing reference build is not permission to connect a real customer system.
Put the human gate before the side effect
A review screen should show the proposed action, source inputs, relevant evidence, uncertainty, and what will happen after approval. Approve, edit, reject, and retry behavior should be explicit.
Build an evaluation set before tuning
Collect representative normal cases, incomplete inputs, ambiguous cases, duplicates, malicious or irrelevant text, and examples where the correct behavior is to abstain. Write expected behavior before choosing prompts based on a few attractive examples.
- Task correctness and structured-output validity.
- Unsupported claims or missing evidence.
- False positive and false negative patterns.
- Human correction effort.
- Latency and provider cost per completed case.
Design retries and observability as product behavior
Log enough context to explain a decision without exposing unnecessary sensitive data. Give every job a stable identifier. Make external actions idempotent so a retry does not create duplicate records, messages, or charges.
Track model, prompt or rules version; validation result; review decision; side effect; latency; cost; and failure category at a level the operating team can use.
Set expand, revise, and stop conditions
Before the pilot, agree which evidence would justify expansion, another controlled iteration, or stopping. Compare the total operating path—not just model accuracy—with the baseline. Include review time, correction work, provider cost, maintenance, and the cost of errors.
Do not turn a pilot estimate into a promised ROI figure. The pilot exists to replace an assumption with operating evidence.