Self-hosted vs. SaaS: AI customer service compared
Last updated:
Why "GDPR-compliant" does not separate the two
Almost every AI tool for customer service now carries the "GDPR-compliant" label. Usually that claim holds up: a provider that offers a data processing agreement and runs its servers in the EU meets the formal requirements. As a way to choose between products, though, the phrase does little work, because both models claim it. The classic SaaS subscription says it about itself, and so does the self-hosted option.
The difference sits one level down. It comes down to four questions. Where does your customers' data live? Who can see it? How is the contract for the AI use structured, and who holds which role in it? And how is the price set? This page compares the two models as categories, not individual products. By "self-hosted" we mean the setup Corresa uses, and by "classic SaaS" the cloud subscription you book, where the provider runs the software for you.
What sets the two models apart, row by row
| Criterion | Self-hosted (like Corresa) | Classic SaaS / cloud solution |
|---|---|---|
| Where the data lives | On your own infrastructure, the server you control | On the provider's servers |
| Who can see the content | You. The software vendor has no access. To draft a reply, the request goes to exactly one AI provider that you hold your own contract with | The provider can, technically, because the communication runs through its system, along with any AI services it plugs in |
| AI contract and GDPR role | You are the controller; your EU AI provider is the processor under your DPA. The software vendor sits outside the processing chain | The software vendor is usually your processor, and all communication plus its AI processing flows through it |
| Pricing model | A fixed license, independent of request volume. The AI costs run directly through your own contract | Often per case, per resolved request, or per seat. The AI costs are priced into the subscription |
| Switching provider | The data sits with you. You can switch the AI provider without switching the software | The data sits in the provider's system. Switching requires export and migration |
| EU hosting vs. on-premise | On-premise: the data never leaves your server toward a software vendor in the first place | EU hosting is possible, but it does not change that the data sits with the provider |
Who is the controller under each model?
This sounds like a formality, but it is the core of the difference. Data protection law distinguishes the controller, who decides the purpose and means of processing, from the processor, who processes on the controller's behalf. For your customer data, you as the retailer are the controller either way. The question is which processors you bring in alongside you, and how many.
With a self-hosted setup and your own AI key, that chain stays short. Your only processor for the AI work is the AI provider you hold the contract with, ideally a European one with a DPA and no training on your data. The software vendor runs no cloud that your emails pass through, so it sits outside. For your privacy notice, that means a shorter processing chain, often without an extra sub-processor pulled in by the software vendor, and clearer lines of responsibility.
Under the classic SaaS model, the software vendor is typically your processor itself, because every customer email runs through its systems, is stored there, and is handed off to an AI model there. Whether that vendor runs the AI model itself or brings in a sub-processor of its own depends on the product. For you it means the same thing either way: one more contract partner with access to the content of your customer communication, and a processing chain whose links you only partly decide. None of this is inherently unlawful. It is simply a different distribution of control.
Is EU hosting the same as self-hosted?
This is the most common mix-up, and it costs you if you rely on it. "EU hosting" means a provider keeps its servers in the EU, say in Frankfurt rather than Virginia. That helps under data protection law, because it takes the sting out of the third-country transfer question. But it says nothing about who holds the data.
A SaaS provider with a data center in Germany still runs the systems your customer emails pass through. The data then sits in the EU, but it sits with the provider. Self-hosted turns that around: the data never leaves your server toward a software vendor in the first place. Where its servers stand no longer matters, because it does not appear on that path at all.
This needs an honest caveat. Self-hosted does not mean customer data never reaches an AI model. For a reply to be drafted, the text of the request has to go to a language model. The difference is that the request touches exactly one further system, namely your own AI provider under your own contract, rather than a software vendor's cloud on top of it. The pillar page on self-hosting describes this control across three layers in detail.
Why the price follows from the model
The pricing model is not a marketing choice. It follows from the architecture. A SaaS provider carries the running costs of operation and AI inference, because both run through its systems. It has to pass those variable costs on, which is why billing is often per case, per resolved request, or per seat. Handle more requests over the Christmas period, and its bill to you rises with them.
Under the self-hosted model, the software vendor does not carry those variable costs, because the AI inference runs through your own contract. So it can charge a fixed license, no matter how full your inbox gets. The only usage-based item is your contract with the AI provider, usually a few euros a month, paid directly to that provider with no markup. Which one is cheaper depends on volume. At low request numbers a usage-based subscription can come out cheaper; at high and uneven volumes the fixed license is easier to budget for.
How easily can you leave?
One point rarely considered when you sign up, and all the more weighty when you leave. Under the SaaS model, your historical cases, drafts, and reports sit in the provider's system. Switching means export, migration, and sorting out what happens to the data left behind with the old provider. It can be done, but it takes effort and ties you in for a while in practice.
Under the self-hosted model, that data sits with you anyway. On top of that, the two building blocks can be swapped separately. You can change the AI provider without changing the software, because the model connects through a key you can replace. That lowers your dependence on any single price list or contract change.
When is classic SaaS the better choice?
Self-hosted is not the right path in every case, and it would be dishonest to pretend otherwise. SaaS gets you running faster. You book a subscription, add a mailbox, and start, without provisioning a server or seeing an installation through. If you would rather not run your own infrastructure and your requests are mostly order status and standard FAQ, a cloud solution often serves you well. The lower barrier to entry also counts for something when the request volume is low and easy to predict.
The effort of self-hosting pays off where requests need real advice, carry real names and cases, and where data sovereignty weighs more than it does in anonymous mass communication. That is the profile of specialty retail. So this is not about one model being bad. It is a real trade-off between convenience and control.
How do you make the call?
The useful question is not "which tool is better" but "how much control over my customer data am I willing to hand over, and what do I get for it". If your requests are simple and you want the least setup, SaaS is a sensible choice. If your replies call for domain knowledge and you want to keep responsibility for sensitive data where it already sits, the self-hosted option fits better.
For how human sign-off fits into this picture, and why a person should have the final say on advice-heavy replies, see AI drafts, a human signs off. And for the full account of self-hosting, from architecture through data protection to cost, read our guide to self-hosting.