AI that actually lives in your processes — not as a demo, but as a tool.

A first production use case with RAG, integration into one or two systems, an eval setup, and a permission model typically sits in the mid- to upper five-figure euro range, plus ongoing model usage and hosting costs. Larger setups with several use cases, several data sources, workflow automation, and training reach six figures quickly. We make assumptions, model costs, and follow-up costs transparent — no “fixed price” on top of half-defined requirements.

We choose per use case: OpenAI / Azure OpenAI (with EU regions and without using your data for training), Anthropic, Mistral, or open-weight models (Llama, Qwen) self-hosted in the EU. For sensitive use cases we use Azure OpenAI in West Europe or self-hosted open source — your data does not leave the EU.

RAG (retrieval-augmented generation) grounds a language model in your real content: documents, databases, tickets. The model pulls relevant passages from your data on every request and answers based on them — with citations. Without RAG you get generalities and hallucinations; with RAG you get answers that match your reality and that you can verify.

Three levers together: first, RAG with solid source grounding so the model works from your content instead of guessing. Second, prompt design with strict “only answer when the information is in the sources” rules. Third, an eval setup that actively measures hallucinations and warns us when a model or prompt change makes things worse. Hallucinations cannot be eliminated entirely, but they become measurable and manageable.

Only if it is intentionally part of the use case and properly contracted — and even then only via providers and regions with a real DPA and no training use. We wire permission checks into the retrieval layer: whatever a user must not see in the source system does not surface in the AI answer either. For especially sensitive areas we use self-hosted open-source models in the EU.

For each use case we build an eval set from real examples in your business (positive, negative, tricky cases) and measure hit, hallucination, escalation, and response-time metrics. Before every rollout — and on every model or prompt change — this eval runs. “Good enough” is not a vibe, it is a number we agree on together.

Both — it varies per use case. For internal knowledge search, topic clustering, or data enrichment, AI usually runs autonomously. For customer email, quotes, legal text, financial decisions, or HR topics we design human-in-the-loop: AI prepares, a human confirms, edits, or rejects. Wherever true autopilot is acceptable, we define risk and reversibility explicitly.

CRM (HubSpot, Salesforce, Microsoft Dynamics, Pipedrive), ERP (SAP Business One, SAP S/4 interfaces, Microsoft Dynamics 365 Business Central, Odoo), helpdesk (Zendesk, Freshdesk, Intercom), Microsoft 365 (Outlook, Teams, SharePoint), databases (Postgres, MSSQL, MySQL), file stores (SharePoint, S3, Azure Blob, on-prem shares), and any JSON/REST API. If a system has an API, we can integrate it — and if it does not, we tell you up front.

Optionally us, your team, or a mix. We hand over architecture, data-flow diagrams, prompt library, eval guide, and runbooks so that your team can run the system alone. On request we keep operating it under a clear mode (monitoring, eval loop, model updates, extensions). You are never locked to us — that is part of the architecture, not just a promise.

That is exactly why we abstract the provider. Prompts, retrieval, workflow logic, and eval are provider-agnostic. Switching from OpenAI to Azure OpenAI, to Anthropic, to Mistral, or to a self-hosted open-weight model is a configuration and eval exercise, not a new project. Vendor lock-in is a design choice — we deliberately design against it.