Znuny-LLM: A Practical Guide to Self-Hosted AI for Znuny

Znuny-LLM brings large language model (LLM) assistance directly into the Znuny agent and admin interfaces. The free, open-source add-on connects Znuny to Ollama or another OpenAI-compatible endpoint and adds classification, summaries, title rewriting, data extraction, writing assistance, and knowledge suggestions without requiring a shared AI SaaS platform.

That combination makes the release relevant to service desks that chose Znuny for control and now want practical generative AI features without abandoning their self-hosted architecture. This guide explains what Znuny-LLM does, how its deployment model works, which security controls deserve attention, and how to introduce it without treating an LLM as an infallible automation engine.

Already improving your Znuny workflows? Start with our broader guide to automation in the Znuny ticket system or explore the OTAI integration for Znuny.

What Is Znuny-LLM?

Znuny-LLM is an add-on for Znuny 7.3 or newer. Znuny announced it as a free, open-source package that runs against infrastructure selected by the operator. Ollama is supported out of the box, while OpenAI-compatible endpoints—including Azure OpenAI—can also be configured.

This distinction matters. “Self-hosted AI” can describe several different arrangements:

• Znuny and the model both run in the customer’s own environment.
• Znuny runs on-premises while an OpenAI-compatible model endpoint runs in a controlled private cloud.
• Znuny connects to a managed endpoint such as Azure OpenAI under the customer’s existing tenant and policies.

Znuny-LLM does not force one of these designs. The organization remains responsible for deciding where inference runs, which data crosses a network boundary, and how that endpoint is secured.

Znuny-LLM Features at a Glance

The add-on focuses on tasks that fit into an agent’s existing ticket workflow.

• Ticket classification: suggests queue, type, service, and SLA from values permitted for the ticket, reducing repetitive first-line triage.
• Multilingual summaries: creates short summaries in the agent’s preferred language, helping agents scan long or multilingual histories.
• Title rewriting: replaces weak incoming email subjects with descriptive titles, making queue views easier to understand.
• Dynamic field extraction: extracts values such as order IDs or serial numbers using plain-language rules, reducing custom regex and parser maintenance.
• Selection rewrite: improves selected text while an agent composes an answer.
• Template and FAQ suggestions: ranks semantically similar templates and FAQ entries to surface existing knowledge during handling.
• FAQ drafts: turns a resolved conversation into a draft knowledge article for editorial review.

These features cover three different types of work: understanding tickets, helping agents respond, and reusing knowledge. They should not all receive the same risk treatment. Rewriting a draft that an agent reviews is different from changing an SLA or routing a ticket automatically.

Automatic Classification and Agent Feedback

When the first customer message arrives, Znuny-LLM can propose a queue, type, service, and SLA. The suggestions are limited to values that are valid for the ticket and appear in a sidebar widget. Agents can rate each proposed field with thumbs-up or thumbs-down feedback.

Confirmed feedback is stored and can be used as few-shot examples in later requests. In other words, the prompt can include examples of earlier decisions to guide the model; the base model itself is not retrained.

This is a pragmatic way to adapt a general-purpose LLM to a service desk. It avoids a separate model-training pipeline and makes corrections immediately useful. It also creates operational questions that teams should answer before rollout:

• Who is allowed to confirm classification feedback?
• How are poor or contradictory examples removed?
• Does accuracy remain stable across queues, languages, and ticket types?
• Which fields are suggestions, and which may trigger downstream automation?
• How will the team measure false routing and SLA recommendations?

For critical fields, start with recommendations rather than unattended changes. A human-in-the-loop phase produces evidence about model quality before the output affects escalation paths or queue ownership.

Multilingual Summaries and Better Ticket Titles

Znuny-LLM generates short ticket summaries and regenerates them when articles or ticket data change. According to Znuny, summaries can be stored and displayed in English, German, French, Spanish, Italian, Dutch, and Portuguese based on the agent’s preferred language.

The add-on can also rewrite incoming email subjects into concise titles in the customer’s language. Phone and internal tickets are not changed by this function.

Both features address a familiar service-desk problem: the first message and its subject line are often poor representations of the actual issue. A useful summary can reduce the time needed to understand a long conversation, while a precise title makes ticket lists easier to scan.

The model output should still be treated as a generated interpretation. A summary may omit a constraint or overemphasize a recent message. Teams handling safety-critical, contractual, or security incidents should keep the full conversation readily available and avoid using the summary as the sole record.

Dynamic Field Extraction Without a Regex for Every Format

Administrators can describe, in natural language, what Znuny-LLM should extract from an article and store in a dynamic field. Examples include an invoice number, order ID, asset identifier, or serial number.

This can be easier to maintain than a collection of regular expressions, especially when customers use inconsistent wording. It is not automatically more deterministic. Before relying on extracted values in another workflow, validate:

1. whether the expected value exists in the source article;
2. whether the model returned exactly one value;
3. whether the format matches the destination field;
4. what happens when the result is missing or ambiguous; and
5. whether an agent can see and correct the extracted value.

For identifiers that trigger financial, provisioning, or access-control actions, use format validation and human review in addition to the LLM.

Writing Assistance and Knowledge Suggestions

The Compose Selection Rewrite feature lets an agent select text in the reply editor and ask the model to improve it. Znuny says the request uses the queue’s answer prompt, detected language, and ticket context. The agent remains in control of the final message.

Znuny-LLM also uses embeddings to rank templates and FAQ entries by semantic similarity. Existing templates and FAQs are embedded when created or changed, then suggested in the compose view. This is retrieval rather than free-form generation: the system helps agents find material the organization already maintains.

For resolved tickets, an administrator can generate an FAQ draft. Similar existing FAQs are included in the context to reduce duplication, and the resulting draft can be linked to the source ticket. This can shorten the path from a good resolution to a reusable knowledge article, but editorial review remains important. Ticket conversations may contain customer-specific details, temporary workarounds, or assumptions that do not belong in general documentation.

Deployment and Data Control

The add-on creates the required dynamic fields, database tables, and web services during installation. Individual features can be disabled, which supports a phased rollout.

The most important architecture decision sits outside the package: where the model endpoint runs.

Local Ollama

Ollama can keep model inference within infrastructure controlled by the organization. This offers the strongest direct control over ticket content, but the operator owns:

• GPU or CPU capacity;
• model selection and updates;
• availability and monitoring;
• network isolation;
• access control;
• backups for related configuration and vector data; and
• performance under concurrent requests.

Private OpenAI-Compatible Endpoint

An OpenAI-compatible API allows teams to use another self-hosted serving stack without changing the integration contract. This can be useful when a central platform team already operates approved models.

Managed Endpoint

A managed endpoint can reduce hardware and model-serving work. It also changes the data flow. Teams must verify tenant configuration, processing location, retention, logging, contractual terms, and the categories of ticket data allowed to leave the Znuny network.

“Compatible” describes the API shape, not the privacy posture. The deployment decision still belongs in the organization’s threat model and data-protection review.

Prompt Injection: Useful Controls, Not a Guarantee

Tickets contain untrusted text written by customers, email senders, and sometimes compromised systems. That makes prompt injection a real design concern: a message can include instructions intended to manipulate the LLM rather than describe a support request.

Znuny says Znuny-LLM scans incoming articles with a weighted multilingual pattern list before sending them to the model. Signals include model-control tokens, instruction-override phrases, role forcing, and known jailbreak patterns. When the configured threshold is exceeded, the ticket is flagged and LLM processing can be suspended until an agent reviews it.

The default prompts also separate trusted metadata from customer-written content with boundary markers, tell the model not to follow instructions inside the untrusted section, and limit article length.

These are sensible defense-in-depth measures, but no pattern list or prompt instruction makes prompt injection impossible. Administrators should also:

• give the model endpoint only the permissions it needs;
• keep generated output away from privileged tools unless separately validated;
• log decisions and model failures without exposing sensitive content unnecessarily;
• review detection thresholds and false positives;
• test multilingual and obfuscated injection attempts; and
• require approval before high-impact field changes.

The safest architecture assumes model output can be wrong or adversarially influenced and limits the consequences.

Znuny-LLM and OTAI Solve Different Layers

Znuny-LLM is a native assistant inside Znuny. Its strength is breadth: one package adds several LLM-supported workflows directly to the agent interface.

OTAI focuses on a separate automation layer for ticket classification and routing across supported ticket systems. Its privacy-first approach can train a customer-specific model from QueueSpec metadata—queue names, descriptions, and authored examples—while production ticket inference runs on-premises. Our guide to AI ticket classification without historical ticket data explains that model.

The two approaches are not mutually exclusive:

• Use Znuny-LLM when agents need summaries, writing support, knowledge suggestions, extraction, and fast LLM-based classification inside Znuny.
• Evaluate a dedicated classification layer when routing behavior needs its own model lifecycle, measurable acceptance criteria, or consistent integration beyond one ticket-system interface.
• Keep deterministic Znuny rules for cases that are already explicit, stable, and auditable.

The right architecture may combine all three. A mailbox rule can handle deterministic intake, Znuny-LLM can assist the agent, and a specialized classifier can handle a defined routing task. What matters is that ownership and evaluation remain clear.

A Safe Rollout Plan

1. Map Data Flows

Document which ticket fields and article content reach the model, where the endpoint runs, and what it logs. Include embeddings and generated FAQ drafts in the review.

2. Start With Reversible Assistance

Begin with selection rewriting, summaries, or suggestions that an agent explicitly reviews. These features create value without silently changing ticket ownership.

3. Establish a Baseline

Measure current handling time, reassignment rate, classification accuracy, and knowledge reuse before enabling automation. Without a baseline, “the AI feels useful” is difficult to turn into an operational decision.

4. Pilot Classification as Recommendations

Enable queue, service, type, and SLA proposals for a limited set of queues. Review errors by field and ticket category. Do not collapse every result into one overall accuracy number.

5. Add Guardrails Before Automation

Validate formats, define confidence or review rules, restrict permissions, and decide how to recover from a wrong result before any generated field triggers another workflow.

6. Expand Feature by Feature

Znuny-LLM allows individual functions to be disabled. Use that capability. A controlled rollout is easier to troubleshoot and gives agents time to develop appropriate trust.

Frequently Asked Questions

Is Znuny-LLM free?

Znuny announced Znuny-LLM as a free, open-source add-on. Operating the model endpoint can still create hardware, hosting, energy, monitoring, and administration costs.

Which Znuny version is required?

Znuny states that Znuny 7.3 or newer is required.

Does Znuny-LLM require Ollama?

No. Ollama is supported out of the box, but the add-on can also use OpenAI-compatible endpoints, including Azure OpenAI.

Is Znuny-LLM fully on-premises?

It can be. If Znuny and the configured model endpoint run inside your own environment, inference can remain on-premises. If you choose a managed endpoint, ticket data follows that endpoint’s configured data flow and policies.

Does agent feedback retrain the model?

Znuny describes the feedback as stored examples used in later prompts. This is few-shot prompting, not retraining the underlying model.

Does prompt-injection detection make LLM processing safe?

It reduces risk but does not eliminate it. Pattern scanning, prompt boundaries, limited permissions, output validation, logging, and human approval should work together.

Conclusion

Znuny-LLM is a substantial addition to the self-hosted service-desk landscape. It places useful LLM capabilities where Znuny agents already work and leaves organizations free to choose a local, private, or managed model endpoint.

Its value will depend less on switching on every feature than on disciplined implementation: map the data flow, start with reviewable assistance, measure classification quality, and limit the impact of incorrect output. Used that way, Znuny-LLM can extend a mature ticket system without discarding the control that made self-hosting attractive in the first place.

To evaluate the next layer, explore OTAI for Znuny and our approach to privacy-first ticket classification.

Source

• Znuny: “Znuny-LLM Add-on: Self-Hosted AI for Service Desks”