Zammad AI features with a self-hosted model

Zammad AI features with a self-hosted model: what stays in your infrastructure

Zammad AI features can be served from a model endpoint that your organization runs, so ticket text can stay inside your infrastructure. This section explains what that design keeps in-house, who should consider it, and what it costs to run the model yourself. The topic covers three features: AI agents, ticket summaries and the writing assistant. Teams whose customer data rules forbid sending ticket content to an outside AI service are the main audience, provided they have people who can operate a model server. Teams that already run GPU capacity or container platforms will find the operating work familiar. Others should price that effort in before committing.

Two self-hostable runtimes fit this pattern. Ollama is an MIT-licensed runtime that serves models through a REST API on port 11434 with OpenAI compatibility. By default it binds to 127.0.0.1, and its local API requires no authentication, so the bind address (set with the OLLAMA_HOST variable) and any proxy in front of it need deliberate design. vLLM is an Apache-2.0 serving engine that exposes OpenAI-compatible endpoints such as /v1/chat/completions, so applications written for the OpenAI API can point at it. Confirm with Zammad, for your exact version, which endpoint types it accepts and which AI features call the configured model. Do not assume every feature behaves the same way across endpoints.

The security work sits mainly in the endpoint and its network path. Ollama's local API has no authentication, so place it on a network segment that only the Zammad application servers can reach, and front it with a reverse proxy that enforces access if other clients need it. vLLM's --api-key option protects /v1 paths but not /metrics, /health or /invocations, and its security documentation recommends a reverse proxy that allowlists only the endpoints users need. Multi-node vLLM traffic is unauthenticated and unencrypted by default, so keep those nodes on an isolated network. Also set OLLAMA_NO_CLOUD=1 if you run Ollama, because direct cloud inference sends requests to ollama.com with an API key and would take ticket text outside your infrastructure.

Running the model yourself changes the cost pattern. Self-hosted Zammad has no license fee, and Ollama's pricing page states that running models on your own hardware is always unlimited. vLLM has no paid edition either, so its cost comes from accelerator capacity, the surrounding infrastructure, implementation and the staff who operate it. Summaries are the main cost lever to control. Zammad 7.2 added a Summary Selector that sets conditions such as state, priority, group or custom fields for when summaries run. Ask any quote to cover hardware sizing against expected ticket volume, concurrency settings (Ollama defaults to one parallel request per model and 512 queued requests), monitoring, model updates, and who responds when the endpoint fails.

How Ollama, vLLM and an OpenAI-compatible endpoint differ for Zammad

Ollama is an open-source runtime for running language models on hardware you operate. It is licensed under MIT, runs on macOS, Windows, Linux and Docker, and stores model files on local disk. Its REST API listens on port 11434 and offers OpenAI compatibility, so a client written for the OpenAI API shape can be pointed at it. It suits teams that want a single host, a simple setup and tight control over where ticket text goes.

Points to weigh:

Licence: Ollama is MIT-licensed, but each model you pull has its own license terms, so review them separately.
Port and bind address: the API binds to 127.0.0.1 on port 11434 by default, and the OLLAMA_HOST variable changes the bind address.
Authentication: the local API does not require authentication, so any exposure beyond the host needs a reverse proxy such as Nginx that enforces access control.
Model storage: models sit in a default directory for each operating system, and OLLAMA_MODELS moves them, which affects disk sizing and backup scope.
Concurrency: OLLAMA_NUM_PARALLEL defaults to one request per model and OLLAMA_MAX_QUEUE defaults to 512 queued requests, so test both against your expected agent and summary load.

Confirm in Zammad's documentation for your installed version that Ollama is a supported endpoint type, and check the Ollama version you deploy because its releases are frequent.

Which model serving option fits which support team

This table compares Ollama, vLLM and a self-managed OpenAI-compatible endpoint for serving the model behind Zammad AI features. Read each row against the skills and on-call capacity of the team that will run the service. The main takeaway is that the Zammad compatibility row must be confirmed for your Zammad version before you choose a serving option.

Consideration	Ollama	vLLM	Self-managed OpenAI-compatible endpoint
License	MIT licensed. Its pricing page lists running models on your own hardware as unlimited.	Apache-2.0 according to its GitHub repository. No paid edition; cost comes from hardware and operations.	Depends on the server software you deploy. Confirm the license of every component.
Hardware profile	Runs on macOS, Windows, Linux and Docker. Suits a single host with modest capacity.	Runs on NVIDIA CUDA, AMD ROCm and Intel XPU GPUs, and on several CPU architectures. Plan accelerator capacity early.	Set by the server behind the endpoint. Confirm model size, memory and accelerator needs with its vendor.
Concurrency controls	One parallel request per model by default, with a queue of 512 requests. Both are configurable.	Scales with tensor and pipeline parallelism across GPUs and nodes. Confirm queueing and limits for your build.	Controlled by your gateway or server. Confirm request limits and queueing before load testing.
Authentication model	Local API on port 11434 has no authentication. Bind to 127.0.0.1 or place a proxy in front.	The --api-key option covers /v1 only. The vLLM docs recommend a reverse proxy that allowlists user endpoints.	Defined by the gateway you place in front. Confirm how Zammad sends credentials to the endpoint.
Kubernetes options	No Kubernetes packaging is covered in the supplied material. Confirm options with Ollama before you plan a cluster.	Native manifests, Helm, the production-stack, KServe, KubeRay and other options are documented.	Runs wherever you deploy it, including your own cluster. Confirm the Zammad endpoint settings for that setup.
Metrics	Confirm the metrics endpoint and format for your Ollama release before you build dashboards.	Prometheus-format metrics at /metrics cover request counts, token throughput, latency and KV cache use.	Depends on the server. Confirm the metrics path and keep it off public routes.
Who operates it	A platform or IT team running one host. Suits pilots and small support teams.	A platform engineering team with GPU and cluster skills, on-call coverage and capacity planning.	A team that already runs an OpenAI-compatible gateway and owns its upgrades and security patches.
Zammad endpoint compatibility	Confirm per Zammad version which Ollama API routes and model names Zammad calls.	Confirm per Zammad version that the /v1 routes Zammad calls are supported by your vLLM release.	Confirm per Zammad version the exact route, request format and authentication header Zammad uses.

Controlling when Zammad summaries run to manage API cost

The Summary Selector in Zammad 7.2 lets administrators decide which tickets trigger an AI summary. Instead of generating a summary every time a ticket is viewed or updated, you define conditions based on state, priority, group or custom fields, and summaries run only when a ticket matches. Zammad 7.2 added this control so that organizations can cut unnecessary API calls. Before you turn on AI summaries for the whole helpdesk, confirm in your installed version which conditions the selector accepts and how it evaluates them.

Choosing conditions starts with your workflow, not with the feature list. A common starting point is to summarize only escalated tickets, high-priority tickets or tickets that have moved to a specialist group, because those are the cases where an agent most needs a quick picture of a long thread. Routine password resets or single-message questions rarely benefit. Write down, for each queue, the situation in which an agent actually asks for context, then translate that situation into one or two selector conditions. Keep rules simple enough that a team lead can read them and predict which tickets will be summarized.

Self-hosting changes where the cost sits, but it does not remove the reason for the selector. When Ollama or vLLM runs on your own hardware, you no longer pay a per-call fee to a model provider, but you pay for accelerator or CPU capacity, power, cooling, and the people who operate the endpoint. Every summary request still occupies the model, consumes queue slots and competes with the writing assistant and AI agents for the same capacity. Unfiltered summarization can therefore slow responses for everyone during a busy period, so the selector is also a capacity control. Ask your platform team what concurrency and queue limits the endpoint is configured for before you widen the rules.

Test the rules before enabling them broadly. Copy a representative sample of real workflows into a test instance or a staging group, using anonymized data where your policy requires it, and run the selector against tickets of each type. Check which tickets were summarized, which were skipped, and whether agents still get context where they need it. Measure request volume on the model endpoint during the test, and compare it with the expected load for your peak hours. Confirm the behavior in the exact Zammad version you run, because selector options and their evaluation can differ between releases, and record the rules you approve so that future changes go through the same review.

Setting up Zammad AI features with a self-hosted model

This sequence connects Zammad's AI features to a model server you run, so ticket text is processed inside your infrastructure. It ends with summaries generated only for the tickets you select, and with the latency, queue and metrics data you need to operate it.

Confirm the Zammad version and AI features
Record the Zammad version your instance runs and list the AI features you plan to enable: agents, ticket summaries or the writing assistant. The Summary Selector was added in Zammad 7.2, so confirm your instance is on 7.2 or later before planning the conditions. Identify which groups, channels and ticket types will send text to the model, because that determines where the model server must be reachable. Output: a written list of features, the Zammad version and the data flows in the change record, approved by the owner of the helpdesk.
Size and place the model server
Choose the network zone for the model server, either the same zone as Zammad or a controlled zone reachable from Zammad over a private path. Select hardware for the model you intend to run, since memory and accelerator capacity set both response time and the number of concurrent requests. Ask your platform team and the runtime documentation to confirm the requirements for that model. Restrict inbound access so only the Zammad application servers can reach the model port. Output: a documented host, zone and firewall rule set that the security team has reviewed.
Install the runtime and load a model
Install Ollama or vLLM on the model host using the vendor documentation for your operating system or container image. Ollama serves a REST API on port 11434, and vLLM started with the serve command exposes OpenAI-compatible endpoints, so either can answer requests from Zammad. Pull or load the chosen model and confirm that it starts without errors. Check that the hardware is supported by your chosen runtime, including NVIDIA CUDA, AMD ROCm, Intel XPU or CPU builds where applicable. Output: a local test request on the model host returns a generated response.
Set the bind address and proxy exposure
Keep the Ollama bind address at its default of 127.0.0.1 unless a proxy sits in front of it, and only then set OLLAMA_HOST to the interface the proxy uses. The local Ollama API does not require authentication, so direct exposure to the network is the main risk. Place Nginx or a similar reverse proxy in front, allowlist only the paths Zammad needs, and block administrative and metrics paths from users. For vLLM, the API key option does not protect every endpoint, so the proxy allowlist is required. Output: Zammad's host gets a successful response through the proxy, and other hosts are refused.
Set model storage and cloud behavior
If model files need more space than the system disk provides, set OLLAMA_MODELS to a directory on a dedicated disk, and confirm the service account can write to it. Set OLLAMA_NO_CLOUD=1 if your policy does not allow cloud features, either as an environment variable or in the server configuration file. Review OLLAMA_NUM_PARALLEL, which defaults to one parallel request per model, and OLLAMA_MAX_QUEUE, which defaults to 512 queued requests, and write down the values you choose. Output: the model files sit on the intended disk, and the settings are recorded in your configuration management.
Configure the endpoint in Zammad
In the Zammad administration interface, open the AI settings and enter the endpoint URL of the model server, along with the model name that the runtime exposes. Confirm the exact setting names against the Zammad 7.2 administrator documentation for your version. Save the configuration and run the connection test that Zammad provides, if your version includes one. Keep the endpoint URL in your configuration record so it can be audited later. Output: Zammad reports a successful connection, and a test request to the model returns text.
Define Summary Selector conditions
Use the Summary Selector to set conditions for when summaries run, such as ticket state, priority, group or custom fields. Start with a narrow set, for example one group or one priority, so that API load and model capacity stay predictable during the pilot. Write each condition in plain language in your runbook so an administrator can explain why a ticket was or was not summarized. Output: a saved condition set, with a short list of tickets that should match it and a list that should not.
Test with sample tickets and monitor
Create sample tickets that match and do not match the conditions, then confirm that summaries appear only for matching tickets. Measure response time for each summary, and watch queue length against the OLLAMA_MAX_QUEUE value or the equivalent vLLM setting. For vLLM, the Prometheus-format metrics at the metrics path provide request counts, token throughput and latency histograms, but that path must stay internal behind the proxy. Set alert thresholds with your operations team. Output: a test report showing matching behavior, latency and queue results, and an agreed alert threshold for each metric.

Protecting ticket text and the model endpoint

Ticket text sent to a model can include customer identities, account details and incident notes, so the model endpoint becomes part of your data perimeter. The cards below cover the access, network, cloud and logging decisions that determine whether ticket content stays inside your infrastructure. Check each one against the serving stack you choose before enabling Zammad AI features.

Ollama API has no authentication

Ollama listens on 127.0.0.1 port 11434 by default and its local API does not require authentication. If you change the bind address with OLLAMA_HOST so Zammad can reach it across the network, anyone who can reach that port can send prompts and read model output. Put a reverse proxy such as Nginx in front of it, enforce access control at the proxy, and allow only the Zammad server's address. Confirm this in your environment before go-live, because the default binding protects you only while the service stays local.

vLLM API key covers only some endpoints

The vLLM --api-key option protects the /v1, /v2, /inference and /cohere endpoints, but not /invocations, /pause, /resume, /abort_requests, /metrics or /health. The vLLM security documentation warns against relying on the key alone and recommends a reverse proxy that allowlists only the endpoints meant for users. For Zammad, that means exposing the OpenAI-compatible chat and completions routes and blocking administrative and monitoring paths from the Zammad network segment. Test the proxy by requesting each blocked path and confirming it fails.

Isolate vLLM multi-node traffic

The vLLM security documentation states that communication between nodes in a multi-node deployment is insecure by default, with no authorization or encryption. If your inference capacity spans several machines using pipeline parallelism or Ray, place those nodes on an isolated network that only the cluster members can reach. Keep the Zammad-facing API on a separate interface from the node-to-node traffic. Ask your platform team to document which network carries each traffic type, since a single flat network undermines the isolation.

Cloud inference requires a Bearer key

Direct cloud inference at ollama.com/api and ollama.com/v1 requires an API key sent as a Bearer token, so ticket text sent to those endpoints leaves your infrastructure. If ticket data must stay local, keep cloud features off by setting OLLAMA_NO_CLOUD=1 or the equivalent option in the server configuration file. Verify this on the running server, not only in the configuration file, and confirm that no Zammad AI setting points at a cloud URL or uses a cloud model name.

Restrict Prometheus metrics endpoints

vLLM exposes Prometheus-format metrics at /metrics, covering request counts, token throughput, latency histograms and KV cache use. These values reveal load patterns and usage volume, and the endpoint is not covered by the --api-key option. Allow only your Prometheus server to scrape it, either through network rules or proxy allowlisting, and keep it off the path that Zammad uses. Ask who owns the monitoring stack, since the scrape credentials and retention of those metrics become part of your audit scope.

Decide retention for prompts and logs

Model servers can write request logs, and the prompts they carry may include full ticket text, customer data and agent notes. Ollama states that when it runs locally it does not see your prompts, but your own logging, proxy access logs and application logs on the serving host may still record request bodies. Decide what each layer records, how long it is kept, who can read it and how it is purged. Also decide where downloaded model files and any cached data live, and include those locations in your backup and deletion procedures.

Running the model server after go-live

Once Zammad AI features are live, the model server becomes a production dependency that your support team will notice the moment it slows down or fails. Plan its day-two care before go-live, not after the first complaint. Confirm who owns the model runtime, who watches its metrics and who approves changes, because Zammad will keep working for agents even when summaries, agent suggestions or the writing assistant stop responding.

Start with metrics. If you run vLLM, it exposes Prometheus-format metrics at /metrics on its API server, covering request counts, token throughput, latency histograms and KV cache use. Scrape these into the same monitoring stack you use for Zammad and alert on sustained high KV cache use and rising latency during your busiest support hours. If you run Ollama, confirm which metrics or logs your installed version exposes, since its operational telemetry differs from vLLM's. Record a baseline during the pilot so you can tell normal peaks from a real fault.

Next, tune concurrency to your support peaks. Ollama's defaults are conservative: OLLAMA_NUM_PARALLEL allows one parallel request per model, OLLAMA_MAX_LOADED_MODELS defaults to 3 times the number of GPUs (or 3 on CPU) and OLLAMA_MAX_QUEUE holds up to 512 queued requests. Work backward from the number of agents who may trigger summaries or drafts at the same moment, then test that setting under load before raising it. Remember that higher parallelism uses more memory, so the right value depends on your hardware, not on the defaults alone.

Patching has two tracks. Ollama ships frequent releases; v0.40.5 arrived on 14 October 2026 and v0.40.6 was published as a pre-release two days later, so pin the version you tested and review each release deliberately. vLLM ships new minor releases about every two weeks. Track both runtimes separately from Zammad. Zammad itself published 7.2 on 23 September 2026, followed by security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026, and security release 6.5.5 on 15 October 2026 for the 6.5 line. Assign someone to watch the Zammad releases page and to apply security fixes for whichever line you run.

Back up the configuration that makes the integration work: the Zammad configuration, including the AI settings and the Summary Selector conditions introduced in 7.2, and the model server configuration, including model names, endpoint URLs, bind addresses, environment variables and any proxy allowlist. Model weights can usually be re-downloaded, but record exactly which model and version you approved. Before switching to a new model, run a test pass against a copy of recent tickets, compare summary quality and response time with the current model, and keep the previous configuration ready to restore. Confirm these steps and their owners with your own change process.

Limits to confirm in your environment before you commit

Zammad AI features with a self-hosted model depend on the Zammad version, the model server, the hardware and the rules your organization follows for data. Each card below is a limit you should test or confirm in your own environment before you commit to a design.

Custom endpoint support by version

Not every AI feature in Zammad may accept a custom endpoint in the version you run. Check which features (agents, ticket summaries and the writing assistant) can point at an Ollama or OpenAI-compatible endpoint you host, and confirm the behavior for the exact release you plan to install. Zammad 7.2 added the Summary Selector, so test that setting in a staging instance before relying on it in production.

Model quality in your languages

A model that writes acceptable summaries in English may produce weak summaries or drafts in other languages your agents use. Build a test set from real ticket types in each language, with anonymized content, and have agents review the output for accuracy, tone and missing facts. Record the model name and version you tested, since results change when the model changes.

Hardware for model and context length

Model size and context length determine how much memory and accelerator capacity you need, and long ticket threads use more context. Confirm the memory and accelerator requirements for your chosen model at the context length your longest threads reach. Ask the model provider or run a benchmark on hardware matching your planned production server, not on a developer laptop.

Concurrency under peak ticket volume

Summaries and drafts queue behind each other when many agents or automated triggers call the model at once. In Ollama, parallel requests per model, loaded models and queued requests are set by separate environment variables with defaults you should review. Load test your expected peak volume, measure queue wait time and decide whether agents accept delays or whether summary conditions must be narrowed.

Ollama local use versus cloud features

Ollama states that local runs do not expose your prompts to it, but some features and direct cloud inference send requests to ollama.com with an API key. Confirm which features in your setup would call the cloud, and disable cloud features with the documented setting if ticket text must stay in your infrastructure. Verify this with network egress tests, not only with the configuration file.

vLLM accelerator and model compatibility

vLLM supports a set of accelerator families and CPU architectures, and a given model may not run on every one of them. Confirm that your GPU or other accelerator, driver stack and chosen model are supported together, and test the exact vLLM release you plan to deploy because releases ship often. Also confirm the OpenAI-compatible routes Zammad calls are served by your chosen vLLM version.

Data residency for the model server

The model server receives ticket text, so its location and operator fall under the same data residency rules as the helpdesk. Confirm the data center or country where the model server runs, who can access its logs and metrics, and whether backups of prompts or responses exist. Involve your privacy and legal owners before you decide where the model runs.

Zammad support coverage for AI issues

Do not assume a Zammad support subscription covers problems that arise from a self-hosted model server or from an AI endpoint you operate. Ask Zammad in writing whether AI-related issues in your setup fall under your subscription tier, which response times apply, and what Zammad will not troubleshoot. Plan internal ownership for the model server regardless of the answer.

Common questions before hiring help with Zammad AI features

What does it cost to run Zammad AI features on a self-hosted model?

The cost has four parts: model hosting capacity, operations staff, a Zammad support subscription if you buy one, and implementation effort. Self-hosted Zammad has no license fee. Zammad lists self-hosted support subscriptions at 2,999 EUR per year (Business), 5,999 EUR per year (Enterprise) and 9,999 EUR per year (Corporation) on its pricing page. Ollama runs models on your own hardware without usage limits, so your model cost is the hardware or accelerator time you provision.

Recurring: hardware power or cloud instance fees, staff time to patch and monitor, and subscription renewals. One-time: planning, configuration, testing and hardening.

Ask any quote to itemize these parts and say which ones recur and who owns the hardware.

How long does an AI features implementation take in Zammad?

Duration depends on the decisions that have to be made before configuration starts, not on the Zammad settings themselves. The main drivers are whether suitable compute already exists, how quickly the network zone and security approvals are granted, whether the model host and reverse proxy are already in place, how many channels and summary conditions you want to test, and how much test volume the team can supply. Ask for the schedule to be written into the fixed scope with named milestones, and confirm which of these items the timeline assumes you have already completed.

What does our team need to provide before implementation starts?

Three inputs matter most. First, a test ticket set that represents your real mix of channels, languages and categories, approved for processing by the model you choose. Second, a network zone where the model endpoint runs and where Zammad can reach it, with firewall rules agreed by your network team. Third, a named Zammad administrator who can decide summary conditions, agent roles and who may change AI settings.

Also confirm who can grant access to the hosting account or data center, and who signs off on where ticket text is processed. Missing any of these usually delays testing more than the technical work does.

Can an internal team set up Zammad AI features without outside help?

Often yes, if the team already runs Zammad and a model server. Zammad's AI settings are administrator configuration, and Ollama exposes an API on port 11434. The work that tends to need experience is the surrounding setup: Ollama binds to 127.0.0.1 by default and its local API has no authentication, so any exposure needs a reverse proxy and access controls. Concurrency also needs planning, since OLLAMA_NUM_PARALLEL defaults to one request per model. Model storage, load testing, monitoring and backups of the model directory need owners. Decide whether your team has the time and skills for these items before you start.

Do Ollama paid plans apply when we run models on our own hardware?

No. Ollama's pricing page states that running models on your own hardware is always unlimited. The paid plans (Pro at $20 per month or $200 per year, Max at $100 per month, Team at $500 per month and Enterprise at custom pricing) are for cloud models. Enterprise adds model access controls, cost budgets per user or API key, a dedicated support channel and custom security options on top of the Team features. Those controls matter only if you call Ollama cloud inference. For a local-only deployment, you can set OLLAMA_NO_CLOUD=1 to turn cloud features off. Confirm current plan terms with Ollama before you budget.

What changes if we move from Ollama to vLLM later?

Zammad would keep pointing at an OpenAI-compatible endpoint, so the application side should be mostly a configuration change. Confirm the exact settings in your Zammad version before planning the switch. The larger changes are operational. vLLM has no paid edition, so its cost is accelerator capacity, surrounding infrastructure, implementation and operators. It runs on NVIDIA CUDA, AMD ROCm, Intel XPU and several CPU architectures, and scales across GPUs with tensor and pipeline parallelism.

Security also changes. The --api-key option does not cover /metrics or /health, and multi-node traffic is unauthenticated by default, so plan a reverse proxy that allows only the endpoints users need. Minor releases arrive about every two weeks, so pin a version and schedule upgrades.

How do summary conditions in Zammad affect AI usage?

Zammad 7.2 added a Summary Selector that lets administrators set conditions such as state, priority, group or custom fields for when AI summaries run. Fewer summary calls mean less load on the model and, if you use a metered endpoint, lower API cost. With a local model, the saving shows up as hardware time and queue pressure rather than an invoice. Choose conditions with the team that handles the tickets, then test them against the sample ticket set to confirm the summaries still appear where agents need them. Review the conditions after the first month of use, since ticket volume and queue structure often change after rollout.

How DeployOpen scopes and delivers Zammad AI with a self-hosted model

DeployOpen plans and builds Zammad AI features against a language model endpoint you host, whether that is Ollama or an OpenAI-compatible service such as vLLM. Most engagements are fixed-scope, with the features, endpoints and cost controls agreed in writing before work starts. Ongoing support is available as a retainer.

How we scope

The written scope names which AI features are enabled: agents, ticket summaries and the writing assistant.
We record the model runtime, hardware, and whether Ollama or an OpenAI-compatible endpoint like vLLM serves requests.
Summary triggers are defined up front, using Summary Selector conditions such as state, priority, group or custom fields.

How we build

Model endpoints are placed on your network, with access restricted so only the Zammad application reaches them.
Ollama is kept on loopback or behind a proxy, with cloud features disabled through OLLAMA_NO_CLOUD=1 where required.
Concurrency settings such as OLLAMA_NUM_PARALLEL and OLLAMA_MAX_QUEUE are sized against expected ticket volume and tested.

How we hand over

Documentation covers endpoint configuration, model storage locations, summary conditions and the proxy allowlist.
Your operators get a runbook for model updates, since Ollama and vLLM ship releases frequently.
Verification records show ticket text reaches only the endpoints you host, checked before go-live.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Model runtime and Zammad upgrades are planned against release notes, with changes to summary settings reviewed first.
Confirm response expectations for your deployment in writing, since they depend on the scope and retainer agreed.

Zammad AI features with a self-hosted model