Pilot

EU-compatible model options for Pilot

EU-compatible model options for PilotWhen Pilot drafts a reply or summarises a conversation, it sends the content of that conversation to a model endpoint. For most customer support contexts, those messages contain personal data — names, email addresses, account details, descriptions of problems. Where that data goes depends entirely on which model provider you have configured.This article covers your options if you need to keep that data under European control.Why model choice matters for data sovereigntyEvery inference request Pilot makes is a data transfer. If you are using OpenAI or Anthropic's hosted APIs, customer data is being processed on US infrastructure, by a US company, under US legal jurisdiction. That is not automatically a problem — both companies offer DPA agreements and maintain privacy programs — but it does mean you are relying on contractual protections and trans-Atlantic data transfer mechanisms that have a history of legal instability.For organisations that want stronger guarantees — public sector, healthcare, legal, financial services, or anyone with specific regulatory requirements — the practical answer is to use a model provider subject to EU law, or to run inference on your own infrastructure entirely.EU-compatible optionsMistral (French company, EU-hosted API)Mistral AI is a French company headquartered in Paris. Their API infrastructure is hosted in Europe, and they operate under French and EU legal frameworks. Mistral Large and Mistral Small both perform well on support drafting tasks.To use Mistral: get an API key at console.mistral.ai, enter it in Settings > Integrations > Pilot, and select your preferred Mistral model. If you need to confirm EU data residency, check Mistral's current DPA and infrastructure documentation — this is their explicit selling point and they publish it clearly.Gemma 4 (Google open weights, self-hostable)Gemma 4 is an open-weights model released by Google. "Open weights" means the model parameters are publicly available and you can run it on your own hardware. When you self-host, inference happens entirely on your infrastructure — no data leaves your environment.Gemma 4 runs well on modern consumer and server GPUs. For support drafting workloads, the smaller variants (Gemma 4 4B, 12B) are fast and resource-efficient.Qwen (Alibaba open weights, self-hostable)Qwen is an open-weights model family from Alibaba. Like Gemma, the weights are publicly available for self-hosted deployment. Qwen models are particularly strong on multilingual tasks, which is useful if your support team handles multiple languages.Whisper (OpenAI open weights, voice and transcription)If you are using Pilot for voice channel transcription, Whisper is the relevant model. OpenAI released Whisper as open weights, meaning it can be self-hosted. For EU deployments, running Whisper locally means voice data (which is often more sensitive than text) never leaves your infrastructure.Deployment pathsScalewayScaleway is a French cloud provider offering GPU compute in Paris and Amsterdam. Both Konversio's Docker Compose deployment and Ollama (for model serving) work on Scaleway. This gives you a complete stack — app, database, and model inference — on EU infrastructure under French law.NebiusNebius is a European AI cloud provider with GPU-optimised infrastructure. Konversio has been tested on Nebius as a deployment target. Nebius also offers managed model serving, so you can run Gemma, Qwen, or other open-weight models without managing the inference server yourself.Pointing Pilot at a self-hosted Ollama instanceOllama is the simplest way to run open-weight models locally or on your own server. Once Ollama is running and you have pulled a model (e.g. ollama pull gemma3:12b), configure Pilot as follows:Go to Settings > Integrations > PilotSelect Ollama as the providerEnter the base URL of your Ollama instance — for example http://localhost:11434 if it is on the same machine, or http://your-server-ip:11434 for a remote instanceEnter the model name exactly as it appears in your Ollama model listSave and test the connectionNo API key is required for Ollama. The test will confirm Konversio can reach your instance and get a valid response. If the test fails, check that Ollama is running, the port is accessible from your Konversio instance, and the model name is correct.

Drafting replies with Pilot

Drafting replies with PilotPilot's most-used feature is reply drafting. When you are looking at an open conversation, Pilot can read the thread and write a suggested response for you to review, edit, and send.Opening the draft panelIn any conversation, open the reply editor as you normally would. You will see a Pilot button — it looks like a small sparkle or AI icon — in the editor toolbar. Clicking it opens the Pilot panel alongside the reply editor.If you do not see the button, Pilot is either not configured yet (check Settings > Integrations > Pilot) or your account administrator has not enabled it for your inbox.Generating a draftClick Draft reply in the Pilot panel. Pilot reads the full conversation history — customer messages, agent replies, any internal notes — and writes a suggested response.The draft appears in the Pilot panel, not directly in the reply box. This is intentional: you read and evaluate it before deciding whether to use it.To use the draft, click Insert or Copy to editor. The text lands in your reply box where you can edit it normally.Editing before sendingAlways read the draft before sending. Pilot does a good job on straightforward queries but it does not know things your organisation knows — internal policies, account-specific context, things that happened outside the ticket. Treat the draft as a first pass, not a final product.Common edits:Add specific details the customer asked for (order numbers, dates, names)Remove anything that sounds off-brand or legally impreciseAdjust the opening or closing to match how your team writesTone adjustmentPilot can adjust the tone of a draft. After generating an initial draft, you can ask Pilot to make it more formal, more casual, shorter, or more empathetic. These are quick follow-up prompts in the Pilot panel — you do not need to re-generate from scratch.Tone adjustment is useful when the customer's message has a particular emotional register (frustrated, confused, angry) and you want the response to match appropriately.Using help center articles as contextIf you have published articles in Konversio's Help Center portal, Pilot can use them when drafting. When the customer's question matches something covered in your documentation, Pilot will pull the relevant content and base the reply on it rather than generating from general knowledge.This produces more accurate, on-brand answers for product-specific questions. It also reduces hallucination risk — Pilot is working from what you have actually written, not guessing.For this to work, your Help Center articles need to be published (not in draft). Pilot indexes published articles only. If you recently added an article and Pilot is not using it yet, give it a few minutes to index.When Pilot drafts are most usefulHigh-volume inboxes where agents handle similar queries repeatedlyHandoffs where an agent needs to respond to a thread they did not startMultilingual inboxes — Pilot can draft in the language the customer wrote inAfter-hours queues where draft quality still matters but speed is the priority

Setting up Pilot: bring your own key

Setting up Pilot: bring your own keyBefore your team can use Pilot's drafting and summarisation features, you need to connect a model provider. This takes about five minutes.Where to find the settingsNavigate to Settings > Integrations > Pilot (sometimes listed as "AI" depending on your version). This is where you configure which model provider Konversio should use when Pilot makes inference requests.You need to be an account administrator to access this screen.Supported providersPilot supports the following out of the box:OpenAI — GPT-4o and GPT-4o-mini are the most commonly used models. Requires an OpenAI API key.Anthropic — Claude models (Sonnet, Haiku). Requires an Anthropic API key.Mistral — Mistral Large and Mistral Small. Requires a Mistral API key. Mistral is a French company with EU-hosted API infrastructure, making it a strong default for European teams.Local models via Ollama — Any model you are running locally or on your own server through Ollama (Gemma, Qwen, Llama, etc.). No external API key required.Entering your API keySelect your provider from the dropdown.Paste your API key into the key field. The key is stored encrypted in your database and is never displayed again after saving.Select your default model from the list that populates after the key is validated.Click Save.For Ollama, instead of an API key you provide a base URL — typically something like http://localhost:11434 or the address of your self-hosted inference server.Testing the connectionAfter saving, use the Test connection button. Konversio will send a minimal request to your configured endpoint and confirm it gets a valid response. If the test fails, the most common causes are:An incorrect or expired API keyA model name mismatch (especially with Ollama, where model names must match exactly what is installed)A firewall or network rule blocking outbound requests from your Konversio instance to the provider endpointChoosing a default modelThe default model is used across all Pilot features unless overridden. Faster, cheaper models (GPT-4o-mini, Mistral Small, Gemma 3 2B) are usually fine for drafting and summarisation. Larger models produce better output on complex or nuanced tickets but cost more per request.A note for EU teamsIf your organisation has requirements around where customer data is processed, the model provider choice matters. Every time Pilot drafts a reply or summarises a conversation, the content of those messages is sent to your configured provider.OpenAI and Anthropic are US companies. Their APIs process data on US infrastructure by default, though enterprise agreements with DPA addenda exist. Mistral offers EU-hosted API endpoints and is subject to French and EU law. Running Ollama on your own infrastructure means the data never leaves your environment at all. The setup for Ollama is covered in the EU model options article.

Conversation summaries and the Pilot Logbook

Conversation summaries and the Pilot LogbookTwo of Pilot's more practical features for team workflows are conversation summaries and the Logbook. Both exist to solve the same underlying problem: context loss when agents switch, conversations go quiet, or tickets span multiple sessions.Conversation summariesA conversation summary is exactly what it sounds like — Pilot reads the full thread and produces a compact, readable summary of what happened, what was resolved, and what (if anything) is still open.How to generate a summaryOpen any conversation and go to the Pilot panel. Click Summarise conversation. Pilot will produce a summary in a few seconds covering:What the customer contacted aboutKey information exchanged (errors reported, account details mentioned, steps taken)Current status — whether the issue is resolved or still in progressThe summary appears in the Pilot panel. You can copy it into an internal note to make it permanently visible on the conversation, or use it as a reference during a handoff.When summaries are usefulHandoffs between agents or shifts: Instead of reading 40 messages, the incoming agent reads the summary and is up to speed in 30 seconds.Closing complex tickets: A summary in the internal notes creates a useful audit trail.Escalations: When passing a ticket to a senior agent or a different team, a summary gives them immediate context without requiring them to read the history.The Pilot LogbookThe Logbook is a structured record that agents build up about a customer across multiple conversations. Where a conversation summary covers a single thread, the Logbook covers the customer relationship over time.Think of it as a persistent notes layer for a contact — but one that Pilot can read and use when drafting replies.What the Logbook containsThe Logbook is not auto-generated. Agents add entries manually when they learn something meaningful about a customer that is worth preserving:Technical environment ("running on Ubuntu 22.04, self-hosted, Docker Compose")Communication preferences ("prefers short replies, wants to be CC'd on everything")Account context ("upgraded to paid plan in March, previously had billing issues")Recurring issues ("has reported the same sync problem three times")How to add Logbook entriesOpen the contact record (not just the conversation). In the contact panel you will find a Logbook tab. Click Add entry, write the note, and save. Entries are timestamped and attributed to the agent who wrote them.Any agent who handles that customer's conversations can see and add to the Logbook.How Pilot uses the LogbookWhen you generate a draft reply on a conversation, Pilot automatically pulls the contact's Logbook entries as additional context. This means:Pilot will not suggest a reply that contradicts known account detailsTechnical drafts will reflect the customer's actual environment if it is loggedPilot can reference past issues when they are clearly relevantThe Logbook does not override the conversation content — it supplements it. If there is a conflict between what the Logbook says and what the customer just wrote, Pilot will use the current message as the primary signal.Logbook versus internal notesInternal notes are per-conversation. The Logbook is per-contact and persistent across all conversations. Use internal notes for context that matters only for the current ticket; use the Logbook for facts about the customer that will stay relevant indefinitely.

What is Pilot?

What is Pilot?Pilot is Konversio's built-in AI support agent. It helps your team handle conversations faster by drafting replies, summarising threads, routing incoming issues, and pulling answers from your help center articles — all without leaving the inbox.What Pilot actually doesPilot is woven into the day-to-day workflow of a support agent:Draft replies: Pilot reads the conversation and writes a suggested response. You review it, edit it, and send. You stay in control.Summarise conversations: Long threads get condensed into a readable summary — useful when picking up someone else's ticket or closing out a case.Route and classify: Pilot can suggest labels, teams, or priorities based on message content, which you can wire into automation rules.Answer from your help center: Pilot uses your published help articles as a knowledge base. When a customer asks a question you've already documented, Pilot can surface the relevant answer.Automate responses: Combined with Konversio's automation engine, Pilot can handle routine inbound queries without agent involvement.Open source, no paywallPilot is fully MIT-licensed and ships as part of Konversio's core codebase. There is no AI tier, no enterprise plan, and no feature flag you need to unlock. Every team using Konversio gets Pilot.This is a deliberate departure from how Chatwoot handles AI. Chatwoot's equivalent feature is called Captain — it is enterprise-only, closed source, and not available to self-hosters on the community edition. If you have ever run Chatwoot CE and wondered why the AI features were missing, that is why. Konversio was built specifically to close that gap.Bring your own key (BYOK)Pilot does not route your data through any Konversio-managed AI service. Instead, you connect your own model provider — OpenAI, Anthropic, Mistral, or a locally hosted model via Ollama.This matters for a few reasons:Your data stays in your hands. Customer messages are sent directly from your Konversio instance to whatever model endpoint you configure. There is no intermediary.No AI sub-processor you did not choose. For teams operating under GDPR or similar frameworks, the model provider becomes a data processor. BYOK means you choose who that is — or you run a model yourself and it is nobody but you.Cost is yours to control. You pay your model provider directly at their published rates. Konversio does not take a margin on inference.What Pilot is notPilot is not a fully autonomous agent that handles customer conversations without human review by default. It is designed as an assistant to human agents — it drafts, suggests, and summarises, but a person decides what gets sent. You can build more autonomous flows using automations, but that is a deliberate configuration choice, not the default behaviour.