Four myths about what you need
- “We need masses of data.” For most integrations you need a hundred good examples, not a million rows.
- “We need to hire a data scientist.” The work is engineering and evaluation, not statistics.
- “Our data must be clean first.” It must be understood, not perfect.
- “We need to train a model.” Almost never. Retrieval over your content does the job.
Three myths about how it behaves
- “It will keep getting better on its own.” Without corrections feeding back, it stays exactly as it is — or drifts worse.
- “Accuracy is a single number.” It varies by category, by document type and by language, and the average hides the problem.
- “It works or it does not.” It produces confident wrong answers, which is a different and more dangerous failure.
The third is the one that catches businesses used to conventional software, where broken things announce themselves.
Two myths about the project
- “The AI is the expensive part.” Integration and interface usually cost more.
- “Once it is built, it is done.” Maintenance is 20–30% of build annually and it is not optional.
What is actually required
- A definition of correct, agreed by someone who knows
- A review path for what the system is unsure about
- A named owner who watches quality after launch
- A measurement agreed before anything is built
None of those is technical, which is why projects that focus entirely on the technology so often disappoint.
Where the myths come from
Mostly from enterprise machine learning, where training models on large datasets genuinely was the work. Retrieval-based business integration is a different discipline with different requirements.
Applying the old assumptions adds a year and a large budget to something that should take six weeks.