Sureva: building AI that survives contact with reality

The slide deck is not the product

Swiss municipalities, associations, and SMEs are told to "adopt AI" every week. Most vendors stop at workshops and slide decks. Sureva started from a simpler frustration: if we cannot deploy what we recommend inside the client's network, we are not solving anything.

The positioning and roadmap live on sureva.ch and in our work case study. This post is different: one real failure from our lab, how we think about context under Swiss governance, and why sovereignty without an ops plan is a trap. No stack tour. That stays on the work page.

What broke first (lab, not a client)

Early in our gateway work, a misconfiguration routed internal test traffic to a model with the wrong context window. Nothing left the network. The responses still looked authoritative and wrong, the failure mode that destroys trust in a municipal clerk workflow or an SME service desk.

We fixed routing, added request-level audit tags, and made gateway checks part of the checklist before any client-facing pilot. That incident is the tone for this series: contact with reality, not a roadmap slide.

If you take one thing from chapter one, take this: the model name on the box matters less than whether the right context arrives, logged and reviewable.

Context is the product (and it can betray you)

The hardest part of LLM implementations is rarely picking a model. It is context: what the system knows, what it may retain, and how faithfully that context reaches inference.

For Swiss public-sector and SME buyers, that usually means:

Auditability: who asked what, which sources were used, what left the boundary (if anything)
Multilingual reality: German, French, and English documents in the same organization, not a single clean corpus
Retention rules: Swiss data protection and internal policy, not "keep everything in the vector store"

Bad context produces confident nonsense. We track context quality as a success metric: signal in the prompt, structured sources, and knowing when not to embed. Tokens can work for you or against you. Scaling is about how you spend attention, not only GPU count.

Fail fast, stay persistent, own the metal (when it makes sense)

We run experiments on our own hardware so we can fail quickly without billing a client for every dead end. That rhythm (try, measure, discard, keep what survives) is how a consultancy becomes an implementer.

We also know not everyone wants to live on the ops side. Running inference inside your network gives you control over context, retention, and audit trails. It also adds maintenance, offline-capable monitoring, metrics you can trust, and issue mitigation when gateways or adapters fail under load.

Sureva does not hand over metal with a PDF. For clients who want sovereignty without a full platform team, we carry runbooks, monitoring, escalation paths, and benchmarks we can reproduce in the lab before anyone signs a purchase order. For others, we co-design a lighter footprint. Choose control with eyes open, not control as a surprise invoice in headcount.

Privacy and control: default posture, not absolutes

Our default for client work is a stack we can deploy and operate on-premise or in a sovereign private cloud: gateways, inference, and logs under boundaries the client defines.

We avoid vendors that own the context pipeline with no meaningful control over retention, routing, or audit trails. When controlled burst capacity (for example GPU burst outside the primary site) is the right tradeoff, we document it explicitly and get client sign-off. No silent routing of sensitive prompts to opaque third parties.

The goal is not to hoard customer data. It is to help them use it strategically inside Swiss data protection expectations, sector rules, and internal governance. Consulting that cannot deploy under those constraints is consulting we do not want to sell.

One consultancy, several internal capabilities

Clients buy outcomes: workshops, pilots, and systems that run in their network. Behind that, we operate internal hosting, shared AI capacity, and engineering tooling so we do not reinvent the platform on every engagement. Those pieces are not separate products we pitch on day one; they exist so delivery stays fast and repeatable.

When multichannel support is in scope, we can extend the same philosophy through Ayentic (human-in-the-loop channels, not a generic bot wall). The work page describes the umbrella; this blog describes scars and decisions as we build.

Open source as a deployment accelerator

We ship local and on-prem with tools we can reproduce:

LiteLLM for routing, keys, and usage accounting
Open WebUI for operator-facing surfaces where teams need visibility
vLLM with multi-LoRA when one base model serves several adapters
PostgreSQL and modest databases so environments stay portable

Structured Markdown as a source of truth reduces unnecessary embeddings: when knowledge is already organized and versioned, you spend fewer tokens and fewer GPU cycles on retrieval that should have been editorial work. That matters for audit and handover in public-sector workflows, not only for cost. (Same idea on this site: PublicBrain.)

Not another SaaS tab

Project managers and business owners need demonstrations and measurable pilots, not another subscription they forget. We are not selling a license and walking away. We want to grow with clients, understand their problem scopes, and put our own stack on the line.

First municipal pilots are ahead of us, not behind us. This chapter is honest about that. The work case study lists roadmap items; here we will log what breaks when pilots start.

Where this story continues

Next installments: gateway hardening after the routing incident, adapter libraries, cost routing (notes on this site), and what public-sector inboxes teach us about context.

Put Sureva to the test with a concrete scope:

30-minute scope call: [email protected]
Or email with your constraint (on-prem AI, sovereign hosting, pilot size) and we reply with a short checklist we use before greenlighting work