LLM applications that survive production.
In short: I design, build, and operate LLM applications for Swiss companies. Focus areas: RAG over internal knowledge bases, document intelligence pipelines, LLM integrations into ERP, CRM, and helpdesks. Stack picked per project: Azure OpenAI (Switzerland region), Claude (Anthropic), OpenAI, or open-source models (Qwen, Llama) — depending on data, budget, and compliance constraints. Public proof point: the hackathon project JiVS Migration Visual Companion (3rd place, DMI Hackathon Davos 2026), an LLM-backed visualisation layer for SAP migration objects.
AI engineering means building LLM applications so they run reliably in production — for months, with real users, under load, and through audits. That is a different discipline from a clever prompt in a notebook demo. It is about retrieval quality, latency budgets, token costs, eval pipelines, guardrails, drift monitoring, and clean deployment.
Concretely: data preparation and chunking strategies, vector indexes with reproducible evaluation, structured output schemas, deterministic fallbacks, cost caps per request, logging in a Swiss-FADP-compliant form. Where a research demo stops at "it works sometimes", engineering begins.
Retrieval-augmented generation over internal documents, wikis, and databases. Includes chunking strategy, hybrid search (BM25 + vector), reranking, and source citations.
Extracting structured data from PDFs, invoices, contracts, and forms. Using Azure Document Intelligence, LLM-based post-processing, and schema validation.
LLM features inside existing systems: Microsoft 365, Salesforce, SAP, Zendesk, JIRA. Structured tool use, safe auth, clear failure modes.
Eval datasets, retrieval metrics (precision/recall@k), faithfulness and relevance checks, regression tests before every deployment. Observability with trace logs and drift monitoring.
Input/output filters, PII redaction, output schema validation, cost caps per request and per user. Clear limits before the LLM goes to production.
Which vendor fits your requirements — Azure OpenAI Switzerland, Anthropic via AWS Bedrock EU, or open-source on your own infrastructure via vLLM/Ollama? Written decision record.
3rd place, DMI Hackathon Davos 2026.
In February 2026 I co-built the JiVS Migration Visual Companion at the DMI Hackathon in Davos — an LLM-backed visualisation layer that displays SAP migration objects and their dependencies interactively. Stack: Claude for the reasoning layer, structured tool calls for JiVS data access, a lightweight vector index for schema lookups. The project placed 3rd among the submitted teams.
That hackathon project sparked my ongoing work with DMI — AI integrations directly on their JiVS IMP platform: agentic migration prep, LLM-backed data access, and structured analysis in place of manual Excel work.
Why it matters as a proof point: the patterns from this hackathon — structured output schemas, source citations at schema level, deterministic fallbacks under LLM uncertainty — transfer directly to production RAG and document intelligence projects at Swiss SMBs. AI engineering is transferable, not just domain-specific.
Claude (Anthropic). First choice when long reasoning chains, precise instruction following, or agentic workflows with tool use are in play. Hosting via AWS Bedrock EU or the direct API. Tradeoff: no official Switzerland-region endpoint, but a strong compliance story via EU Bedrock.
Azure OpenAI (Switzerland region). First choice when data residency is strict (banks, insurers, public sector), when Microsoft tenant infrastructure already exists, and for document intelligence with native Azure integration. Tradeoff: model rollout lags OpenAI by some weeks, throughput quotas need planning.
OpenAI direct. Good for fast prototypes, the newest models, and image generation. Not first choice for Swiss production workloads with sensitive data — no CH-region hosting, US contracting party.
Open source (Qwen, Llama via vLLM/Ollama). First choice under strict data residency (on-prem), at high token volume where unit cost dominates, or for specialised tasks (embeddings, classification) where large frontier models are overkill. Tradeoff: lower reasoning quality than frontier models, requires an ops team.
In most real projects two models are used together: a strong frontier model for complex reasoning, and a smaller model for embeddings, classification, or helper tasks. That keeps cost and latency under control.
RAG (retrieval-augmented generation) retrieves relevant documents from an external knowledge base at answer time and passes them to the LLM as context. The model itself stays unchanged. Fine-tuning trains a model on your own data and changes its weights. In practice RAG is almost always the right choice for Swiss SMBs: faster to ship, easier to update, more transparent (source citations), cheaper. Fine-tuning is worth considering when a specific style or output format must be enforced consistently — or at very high volume, where a smaller fine-tuned model runs cheaper than a large generic one.
FADP compliance depends less on the model and more on hosting and contract. Practical compliant paths: Azure OpenAI in the Switzerland region (Switzerland North) with Microsoft's DPA and data residency guarantee; Anthropic Claude via AWS Bedrock in an EU region with the AWS DPA; open-source models (Qwen, Llama) self-hosted via vLLM or Ollama, on-prem or in a Swiss cloud. Direct API access to OpenAI or Anthropic without EU/CH hosting needs careful review — possible, but riskier depending on the data class. For regulated industries (banks, pharma, public sector) Azure Switzerland region or open-source on-prem is usually the clean choice.
On two layers. Retrieval metrics: precision@k and recall@k on a curated eval dataset — at k=5 the right sources should land in the top results with high probability. Generation metrics: faithfulness (does the answer say anything not in the sources?), answer relevancy (does it actually answer the question?), context precision (are the retrieved sources truly relevant?). In practice I use an eval set of 50–200 questions with gold answers, run the system through each variant (new chunking, new reranker, new model), and compare the numbers. Without that eval set, every "improvement" is speculation.
A typical PoC sprint costs between CHF 15,000 and CHF 35,000 (two weeks, one clearly scoped use case, one data type, one source set, end-to-end delivery including eval setup). A production implementation with auth, monitoring, several data sources, and stakeholder reviews starts at CHF 50,000 for tightly scoped use cases and can sit well above that depending on data complexity and integration requirements. Ongoing operating cost (LLM API calls, vector store, hosting) depends on volume and for most SMB projects sits in the low four-digit range per month. Precise quotes after a non-binding discovery call.
Yes. Microsoft operates Azure OpenAI in the Switzerland North region (Zurich) with the common GPT models and embeddings. Data stays in Switzerland, Microsoft provides a DPA and data residency guarantees, which makes the FADP story clean for most SMBs. Practical notes: not every model is immediately available in the Switzerland region (new models land first in US regions, Switzerland follows with a delay); throughput quotas (PTUs / tokens-per-minute) need planning; Document Intelligence and other Azure AI services in the Switzerland region compose natively. We check the current status and the concrete model together in the discovery call.
Employees chat with HR handbook, IT policies, contract templates. Answers with source citations.
Invoices, contracts, forms automatically into the ERP — with review queue for low-confidence cases.
Contracts checked against rulesets — traffic-light output with per-clause reasoning.
Book a non-binding 30-minute discovery call. We figure out whether RAG, document intelligence, or an LLM integration makes sense for your use case — and which stack fits.
Book a discovery call