The AI in your ticketing system should be yours
Every help desk now ships AI triage. In almost all of them the model is the vendor's, hosted in the vendor's cloud, running on the body of your tickets, at a price the vendor sets. When they swap the model, your routing quality moves and nobody tells you first.
Latch Workflow inverts that. You bring the model. It plugs into the ticketing system the same way any other integration does, so the model that reads your tickets is one you chose, running where you decided, and swapping it is a configuration change rather than a migration.
Claude, GPT, or Gemini, billed to your account under your contract and your data processing terms. You hold the key, you set the retention flags, and you can revoke it without filing a support ticket with us.
Llama, Qwen, Mistral, or whatever your platform team already serves. Inference runs on your GPUs inside your network, so no ticket text crosses the boundary at all.
If you have already trained something on your domain, expose it over HTTP and point the plugin at it. The platform does not care what is behind the URL as long as the contract is met.
A small cheap model for classification, a stronger one for extraction, a local one for anything touching regulated content. Routing is per action, not per install.
The approval gates, the permission checks, and the audit trail behave identically whichever model you point at.
What a vendor-chosen model actually costs you
None of this shows up in the trial. It shows up in year two, when the model changes, the invoice changes, or a security review asks where the ticket text went.
A cloud help desk ships one model, chosen by the vendor, versioned by the vendor. When it changes underneath you, your triage quality changes with it and you find out from the release notes.
Classification and summarisation mean the body of every ticket is sent to an endpoint the vendor controls, in a jurisdiction the vendor chose. For a regulated function that is the end of the evaluation.
AI features are increasingly a per-seat uplift or a credit pack. When the rate changes, there is no second supplier to move to, because the model is welded to the product.
Corrections your operators make are the most valuable data your queue produces. If they improve a shared vendor model, you have paid to train something your competitors also use.
A model is a plugin, and plugins are governed
The model does not get special status inside the product. It goes through the same plugin interface as a Stripe refund or an ERP lookup, which means the same controls already wrap it.
A model plugin declares what it can do: classify a ticket, extract fields from an attachment, propose a next step, draft a reply. The declaration is a contract, not a hard-coded branch in the product.
Role checks, approval gates, and rate limits sit around the call. A model that can propose a refund does not thereby get to issue one. The gate is held by the platform, not by the prompt.
Which model ran, which version, what it proposed, what the operator did with it, and what the downstream system returned. All of it lands on the ticket as it happens.
Writing one is a discover function and an execute function against the TypeScript or Go SDK. The permission checks, the approval workflow, and the immutable log are supplied by the platform, so a model plugin stays focused on the inference itself. The same contract covers every other integration you attach to a ticket.
The model proposes. The workflow decides.
A model that can read a ticket and suggest a refund is useful. A model that can issue the refund is a control failure waiting for an incident report. The separation between the two is enforced outside the model, where a prompt cannot argue with it.
So a suggestion above a threshold still stops for approval, a sensitive action still requires two-person review, and the attempt that was blocked is recorded alongside the ones that ran. Swapping in a stronger model does not quietly widen what the system is allowed to do.
This is also what makes the model choice safe to revisit. Because the controls live in the platform rather than in the model configuration, moving from a hosted API to a local open-weights model changes where inference happens and nothing about who may approve what. The audit trail keeps recording which model proposed which action throughout.
What it learns stays on your side of the boundary
Every time an operator re-routes a ticket the system placed wrong, rejects a proposed next step, or corrects an extracted field, that is signal. It is written to your database, and the suggestions fitted on it are fitted inside your environment.
The practical consequence is that the queue reflects the calls your operators actually make, rather than the average of every tenant on a shared platform. Run the whole thing on your own infrastructure and the corrections never leave at all. Most systems that learn from your data need you to hand over the data and use their model to do it. This one asks for neither.
When bringing your own model is not worth it
If no rule forces the boundary and nobody on the team wants to own an inference stack, model choice is a feature you will not use. Point a plugin at a hosted API, take the default, and spend the attention on your routing rules instead. That is a reasonable answer and it is the one most teams should take on day one.
It becomes worth it when one of three things is true: a residency or sector rule says ticket content cannot reach a third-party model, the AI line on the invoice has grown enough to want a second supplier, or the corrections your team produces have become valuable enough that you do not want them improving somebody else's model. The platform team path covers what owning it involves.
Follow the control path from intake to evidence
These pages work together: intake shapes the ticket, approvals gate sensitive actions, maker-checker enforces independence, security controls the deployment boundary, and auditability preserves the proof.
Enforce separation between the person preparing an action and the person approving it.
Route sensitive actions through role checks and approval gates before they run.
Keep decisions, blocked attempts, approvals, and action results on the same record.
Deploy where ticket data, identity, and the AI models you choose stay inside your environment.
Bring email, forms, alerts, and system events into one ticket queue before actions begin.
Questions teams ask before committing to a model
What security reviewers, platform leads, and finance ask when the AI in the ticketing system is a choice rather than a default.
Which models can we actually use?
Any model reachable over HTTP that a plugin can be written against. In practice that means a commercial API on your own key, an open-weights model served on your own hardware, or an in-house fine-tune behind your own endpoint. Teams commonly run more than one and route per task.
Does our ticket data go to a model we do not control?
Only if you configure a plugin that points at one. If you serve an open-weights model inside your network, ticket text never leaves the boundary. In an air-gapped install there is no outbound path for it to take.
How hard is it to swap models later?
It is a configuration change, not a migration. The plugin contract stays the same, so pointing an action at a different model does not touch your queues, routing rules, approval policies, or history. Teams typically run the new model alongside the old one on a slice of traffic before switching.
What stops the model from taking an action on its own?
The permission and approval layer, which sits outside the model. A model proposes; the governed workflow decides whether the proposal may execute. A suggestion that would trigger a refund above a threshold still stops at the approval gate, and the denied attempt is recorded like any other.
Can we tell which model was responsible for a decision?
Yes. The audit trail records the plugin, the model identifier and version, the proposal, and the operator decision that followed it. When a regulator or an internal reviewer asks why a ticket was routed or paid the way it was, the model that suggested it is part of the record.
Do we need an ML team to run this?
No, if you use a commercial API on your own key. Yes, in the sense that serving an open-weights model on your own GPUs is real infrastructure work, with capacity planning and upgrades attached. Teams with no residency rule and no ML capacity are usually better served by starting on a hosted API and moving later.
See a ticket triaged by a model you chose
Walk through intake, a model-proposed next step, the approval gate that held it, and the audit record naming which model suggested what. Bring the model your team already runs.