Support Tickets Are a Bad Place for a Public Chatbot
Tickets are full of customer PII. Classify, summarise and draft on infrastructure you control, keep a human in the loop, and never auto-send a model reply.
A support ticket is not a blank page for a writing assistant. It is a bundle of customer identity, product state, sometimes payment hints, sometimes health or employment detail, always a tone that will be read as the company’s voice. Pasting that bundle into a public chatbot is a disclosure. Automating a reply from that chatbot into the customer’s inbox is a different, worse disclosure: now the model is speaking as you, to them, with their data in the context window.
Private AI for support tickets means the model that classifies, summarises or drafts can see ticket text on infrastructure you control, or at least on a processor you have actually contracted for that data class. It does not mean a local model that writes perfect replies. It does not mean the queue becomes unattended. The useful version is boring: structured help for an agent who still clicks send.
I will not invent a contact-centre transformation story. The failure modes below are from how tickets, PII and language models actually interact.
Why tickets are a bad public-chatbot workload
Ticketing systems already concentrate personal data. Name, email, phone, account id, device identifiers, screenshots of dashboards, pasted logs that include access tokens, the angry paragraph that mentions a child’s school, the invoice number that should have been in a different tool. Support software is a processor you chose. A public chatbot is usually not.
Three properties make this worse than “an employee summarised a blog post”:
The payload is other people’s data. GDPR does not care that the agent was trying to be faster. The customer did not appoint ChatGPT. Your DPA with the helpdesk vendor does not automatically cover an extra AI vendor the agent opened in another tab.
Volume is high and repetitive. That is exactly why people want a model, and exactly why a leak is not a one-off paste. If fifty agents each summarise ten tickets a day in a consumer UI, you have built an unofficial export pipeline.
The output can leave again. A draft that still contains an address, a medical aside, or an internal root-cause paragraph can be sent to the customer, posted in a public status page, or copied to a partner Slack. Generation is not the end of the data path. Send is.
A contracted support-vendor “AI feature” inside the helpdesk can be acceptable if you have read the DPA, the subprocessors, the training policy, and the retention. A personal ChatGPT session is not that feature. Neither is a random Chrome extension that “improves replies”.
If the honest comparison is vendor API versus local inference, use the local versus cloud decision tree. Tickets usually fail the “this text may leave” test earlier than marketing copy does.
What the model is allowed to do
Keep the jobs small enough to check.
Classify. Queue, language, product area, severity, “this looks like a security report”, “this looks like a deletion request”. Classification belongs in structured output (a label, a confidence, a short reason). An agent or a rule confirms before routing changes. Do not let a model silently move GDPR deletion tickets into a junk pile.
Summarise. Long threads, three products, twelve attachments: a summary that an agent reads before opening the lot can be real time saved. The summary must not invent a promise (“we already refunded”) that is not in the thread. Require citations back to ticket comments or internal notes. If the model cannot point at a comment id, the sentence does not go in the summary.
Draft a reply. A draft is a starting text in the agent workspace. It is not a send. Tone, policy, and the actual decision (refund or not, workaround or not) stay with the human who owns the queue. The model may propose a structure: acknowledgement, what you understood, what you will do, what you need from the customer. It must not invent a policy exception.
What the model should not do, as a default:
- close tickets;
- issue refunds or credits;
- change account state;
- tell the customer that a vulnerability is “probably fine”;
- translate a legal position;
- answer from “general knowledge” when the answer is in your runbook.
If you need answers from internal runbooks, that is retrieval over documents you control, not a chatbot with a ticket pasted in. The mechanics are in private AI document search. Retrieval still needs permissions: an agent must not see a runbook, or another customer’s ticket, because the index was greedy.
PII is the payload, not a side effect
Ticket PII is not only a name field. It is:
- identifiers in the subject line and in screenshots;
- free text (“my wife’s account”, “our daughter’s school login”);
- logs and HAR files;
- payment last-four, IBAN fragments, tax numbers;
- health, union, religious, or children’s data that should never have been in a helpdesk, and now is;
- other customers mentioned in a CC thread.
A private model does not make PII disappear. It makes the processing location a decision. You still need a retention period for prompts, summaries, embeddings and drafts. You still need access control so that embeddings from ticket A cannot be retrieved while answering ticket B if those customers must not be mixed. Tenant isolation in a multi-product helpdesk is a backend problem. The model will not invent it for you.
Redaction before inference is useful and incomplete. Regexes catch emails and card-shaped numbers. They miss the screenshot, the unusual identifier, the story that is identifying without being a named entity. If you redact and then send the remainder to a public API, you must be honest about what you still sent. If the remainder is enough to do the job, maybe the original paste was never required.
Minimisation still wins. Do not put the whole company ticket history into a context window because a demo looked clever. Put this ticket, the last N comments, and the specific runbook passages retrieval returned. Less text in is less text stored, logged, and wrongly sent.
Store derived artefacts with the same access rules as the ticket. A “handy” summary table in a data warehouse that is readable by marketing is a second helpdesk with worse hygiene.
Human in the loop, never auto-send
This is the non-negotiable control.
The model may write into a draft field. The agent sends. Shortcuts that auto-send on “looks good” will eventually send a fluent wrong refund, a fluent internal comment, or a fluent leak of another customer’s data that retrieval mixed in. Fluency is not a verifier.
Practical loop:
- Ticket arrives or is updated.
- Classifier suggests labels; rules or an agent accept.
- Summariser writes an internal-only summary, tagged as generated.
- If the agent requests a draft, the model sees the allowed context and a policy snippet (“never promise X”, “never mention Y vendor”).
- Agent edits. Send goes through the helpdesk’s normal permissions, macros, and audit.
Measure the loop like a backend system. Track:
- fraction of drafts sent with zero edits (if that number is high, you are not reviewing);
- fraction of drafts discarded (if that number is high, the model is wasting time);
- incidents where a generated sentence reached a customer with a factual error;
- incidents where PII that was not in the customer-visible thread appeared in a draft (that is retrieval or prompt leakage).
Do not hide the generated origin from internal viewers. Agents should see that a paragraph was suggested. Customers do not need a manifesto in the footer; they need a correct answer from a human who took responsibility.
Staffing is part of the design. If you cut headcount because “AI will send the replies”, you will auto-send. If you keep the headcount and remove the worst typing, you might have a system.
Architecture that keeps tickets inside
A workable contour looks like any other internal service.
Helpdesk (source of truth)
↓
Connector (pull comments, attachments metadata)
↓
Application (permissions, redaction policy, prompt assembly)
↓
Inference (local or contracted API)
↓
Draft / summary / labels written back as internal notes
↓
Agent UI (edit, send)Keep the helpdesk as the system of record. Do not fork ticket state into a chat app. The connector should use the official API, a least-privilege token, and an allow-list of fields. Pulling “everything including other companies on the same shared inbox” is how you train a model on the wrong tenant.
Inference placement:
- Local or private GPU / CPU: when ticket text must not go to a public AI vendor. Quality will be capped by what you can run. Fine for classification, extractive summaries, and drafts against retrieved runbooks. Weak at open-ended “just be a brilliant agent”.
- Vendor API under a DPA: when legal accepts that processor for support data, and you still do not auto-send. Often stronger drafts. Still a transfer. Still log metadata only.
- Helpdesk-native AI: when you are willing to treat that vendor as the AI processor and you have read the settings. Confirm whether they use your tickets to train a shared model. If the answer is vague, it is not a setting; it is a risk.
Network: the inference host should not need a default route to the internet if it is local. The connector needs to reach the helpdesk, not the other way around if you can avoid inbound holes. Identity: the application uses the agent’s identity to decide what the model may see. A shared “support bot” service account that can read all tickets, including VIP and legal holds, is a privilege escalation with a friendly name.
For the business question of whether any of this is worth operating, start with when a local LLM makes sense. Tickets are a strong candidate on privacy and repetition, and a weak candidate if you expected unattended magic.
When not to put a model on the queue
Skip the model, or delay it, when:
- you cannot state which fields may be processed;
- you cannot keep a human on send;
- your runbooks are oral tradition, so retrieval will invent;
- the queue is mostly unique legal or safety cases;
- you have not fixed search inside the helpdesk, and the real pain is finding the last ticket from the same customer;
- the proposed design stores all embeddings forever “in case we need them”;
- nobody owns GPU drivers, prompt changes, or the connector when it breaks on Monday.
A better first week than model shopping: field inventory, retention, a macro library, and a rule that consumer chatbots are not a tool. Then a pilot on one queue, one job (summaries or drafts, not both on day one), measured against a week of real tickets.
Commercial shape if you want that designed rather than demoed: a Private AI Readiness Audit from €1,500 for one workflow and a written public / private / hybrid call; a single-workflow pilot at €300/day; implementation at the same rate. The overview is private AI on infrastructure you control. A legitimate audit result is “do not put a model on this queue yet”.
Support tickets are a bad place for a public chatbot because the data is not yours to donate and the send button is a legal act. Private AI can classify, summarise and draft if you treat PII as the payload, keep the human on the loop, and refuse auto-send. Anything that promises to “replace the team” is selling you the incident.