Where the ticket gets read: the only difference that survives a compliance questionnaire

A post on dev.to from Bynevo Labs lays out the two ways an e-commerce team can put an AI in front of its support queue: switch on a hosted feature inside the tool you already pay for, or run your own agent on an open model on infrastructure you control ^[1]. The author says plainly that he builds the second kind for French shops and is not neutral ^[2], which is the right disclosure to have on the table, because the load-bearing claim is not about answer quality. Both setups answer the same tickets; the difference is almost entirely architectural ^[5].

Mechanically, a hosted support AI reads the ticket by sending the customer's message, and usually a slice of your order and profile data, to the vendor's model ^[4]. Intercom's Fin is the example given, sitting on top of Intercom ^[3]. Nothing about that is deviant. It is how the product works, and for many teams the post concedes it is fine ^[4].

The consequence shows up when someone asks where customer data is processed. The post frames that, for a shop selling in the EU, as the first question rather than a detail, and specifically as a question you want a short and defensible answer to ^[6]. A self-hosted agent inverts the default: the model runs on an instance rented in your own name, in a region you choose ^[7]. In the author's own configuration, an open French model on French hosting, he argues the residency answer is one sentence and does not depend on a sub-processor list that can change with a product update ^[8]. That last clause is the substantive part. A hosted answer is accurate on the day you write it and is maintained by someone else.

On money, the post is deliberately unquantified. It says hosted support AI is often billed per resolution ^[9], that this couples support cost to ticket volume and gives the vendor an incentive to count a resolution generously ^[10], and that dated pricing was kept out on purpose because it changes ^[11]. So there is no cost comparison to run here, only a shape: a monthly instance you pay for regardless of volume, plus inference that scales with usage but can be measured and capped, neither of which is per-resolution ^[12][13].

The reversibility argument is the one operators tend to discover late. When the agent, the knowledge base, the conversation logs and the automations all sit inside one SaaS, leaving means rebuilding all of it, because the support logic has no existence outside the vendor's schema ^[14]. Self-hosting forces retrieval to point at your content, tools to be your own API endpoints, and logs into your database, so the system survives the departure of whoever built it ^[15].

The bill for that is honest in the post. You own the instance, the model updates, the monitoring, and the on-call when a tool call starts failing at 9pm ^[16], and a hosted product absorbs all of it ^[17]. You also inherit the guardrails: answering only from your data and refusing otherwise, typed tool-use with hard limits, a refund ceiling the agent cannot exceed, and escalation that hands a human full context ^[18]. His own recommendation is that teams with no one to operate infrastructure and no hard residency requirement should start hosted ^[19].