Direct answer
Judge on three conditions. (1) Material sensitivity — if a large share of the material you want the AI to use is restricted (customer data, cost floors, contracts), lean towards local or private deployment. (2) Session volume — below a few hundred sessions a day, usage-priced SaaS is usually better value. (3) Integration depth — if it has to read your own order or ticket systems, or the escalation rules need fine-grained customisation, self-hosting or private deployment fits better. For most small businesses the workable answer is a privately deployed open-source Q&A framework plus a cloud LLM API: the material stays controllable, the cost stays below full in-house development, and you are not bounded by a SaaS product's feature limits.
Don't start by comparing feature lists
Answer three questions first and the route mostly decides itself.
1. Material sensitivity. Does the material you want to feed the AI include restricted content — customer lists, contracts, cost floors, personal data? If there is a lot of it, lean towards local deployment or a clearly controlled private space. If not, cloud SaaS is less work.
2. Session volume. For a small business handling tens to a few hundred sessions a day, the fixed cost of running your own server does not amortise. Usage-priced SaaS is usually better value at that level. The marginal-cost advantage of self-hosting only shows up once you are into the thousands.
3. Integration depth. If it is pure Q&A — policies, processes, store information — SaaS is enough. If it has to read your own order database or ticketing system, or the escalation rules have to be written very finely (matching the five automatic transfer scenarios in the national standard), private or self-hosted deployment leaves far more room.
The three options as they actually look
| Option | Fits | Trade-off |
|---|---|---|
| Public SaaS | Insensitive material, low volume, Q&A only | Little room to customise; material sits under a third-party account |
| Private framework + cloud model API | Sensitive material, custom rules, cost control | Requires a one-off build and integration |
| Fully in-house | A technical team and complex business | Highest labour and timeline cost; rarely worth it for most small businesses |
The third route — a privately deployed framework plus a cloud model API — is the shape most small businesses land on today: the knowledge base and configuration live on the company's own server or under its own account, while model calls go out to a cloud API. The material stays controllable, the cost is below fully in-house development, and you are not bounded by a SaaS product's feature limits.
Three follow-up questions for the decision
1. Can the material be withdrawn at any time? Stopping the intake from a given source — is that something you can do immediately?
2. Can you get the configuration and the logs? Later self-checks (the 53 mandatory items in the standard) and ongoing tuning both depend on them. A supplier who refuses is a serious risk.
3. Whose account is it? Model account, cloud space and domain under the company's own name, so that material and configuration can move with you if you switch suppliers.
If all three have clear answers, either route can work. If one of them is vague, the cheaper option may only be cheaper for now.
One honest point
The difference between tool routes is usually smaller than the difference in how well the material was prepared. Settle the question list and the authoritative wording first, then choose the route — get that order wrong and even the most expensive option will answer inaccurately.
Key facts
| Three decision conditions | Material sensitivity / session volume / integration depth |
| Common deployment shape | Privately deployed Q&A framework + cloud LLM API |
| SaaS sweet spot (reference) | Tens to a few hundred sessions a day |
| Three questions always worth asking | Can material be withdrawn at any time / can configuration and logs be exported / whose account is it |
Sources
- Selection and isolation practice from enterprise knowledge base and AI customer service delivery
- Three-tier material classification (public / internal / restricted)
- GB/T 47746—2026, clause 5.2.2.6 (transfer rules must be configurable and auditable)
Follow-up questions
Does SaaS put our material at risk?
That depends on account ownership, what is in scope and what the contract says. Keep restricted material out of scope and open the account under the company's own name, and the risk is manageable. The real problem is handing an entire library to any tool without thinking about it.
Is self-hosting always more expensive?
Higher fixed cost, lower marginal cost. At low session volumes self-hosting does not amortise; as volume grows it becomes cheaper. The crossover is usually around a thousand sessions a day.
Do we need to keep technical staff for an open-source framework?
Not on a day-to-day basis, but you need someone who can edit configuration and read logs — part of an existing role is enough. With nobody able to touch the configuration, you can only wait for the supplier when something breaks.
Can we try SaaS first and switch later?
Yes, but protect the migration path in advance: keep the material under the company's own account, make sure Q&A pairs can be exported, and hold the wording documents yourself. Otherwise switching means rebuilding from scratch.