AI platform

What we do

1. 01

   Mapping and design

   We start with what already runs in the company. The output is a target architecture and a catalogue of approved services and data. We map:

   • the AI tools people already use, and their API keys
   • where company data goes and on what terms it is processed
   • who needs which models and features
   • which processes are worth automating first
   • AI costs per team and application
2. 02

   Company chat

   Employees get one approved interface for working with AI, for example LibreChat or Open WebUI. We put in place:

   • sign-in with the company account (Google Workspace, Microsoft Entra ID)
   • a choice of approved models and features by role
   • model keys stored on the server, not with users
   • rules for conversation history, files and shared links
   • controlled addition of tools and MCP servers
   • removal of access, including running sessions, within an agreed time
3. 03

   One LLM gateway

   The chat, applications and agents reach models through one gateway, for example LiteLLM or the AI gateway in Azure API Management. We put in place:

   • a catalogue of approved model deployments: provider, endpoint, permitted use and data terms
   • its own identity and limits for every application
   • request limits, token quotas and budgets per team
   • fallback routing during outages only to environments with the same data rules
   • tested limit behaviour, not a vague promise of a spending cap
4. 04

   Agent oversight with Langfuse

   Langfuse links model calls, tool use, timings, usage and the result into one record. We run it on our platform or on your infrastructure. We put in place:

   • a record of the whole agent run, including the application and prompt version
   • costs tied to a genuinely useful result
   • evaluation of results by people and by automated checks
   • test sets that check every change of model or prompt
   • masking of sensitive data in the records
   • alerts when costs rise or quality drops
5. 05

   Safe agents

   Agent permissions are enforced by the application and the tools it calls, not by instructions in a prompt. We put in place:

   • separate tools for reading and for writing
   • human approval of sensitive actions
   • limits on time, number of steps and retries
   • protection against duplicate writes when a task is retried
   • a separate environment and access for development agents
6. 06

   Where models run

   Network path, place of processing, data retention and no-training terms are four different things; none guarantees the others. Depending on your requirements, we set up:

   • managed models in Azure or Google Cloud with documented processing terms
   • private connectivity (private endpoint) where the service supports it
   • region and data residency for the chosen model and feature
   • your own model server (for example vLLM) for data that must not go to an external API
   • rules for agents’ outbound traffic
7. 07

   Handover and operations

   We hand the platform over with test results, not just a list of installed products. Then we run it: updates, monitoring, backups, access rotation and a regular usage report. We verify that:

   • a removed user loses access, even with a running session
   • the gateway rejects an unapproved model or direct access from an application
   • one team’s limit doesn’t use up another team’s capacity
   • for the pilot task, the user, model call, tool and result can be linked
   • sensitive data doesn’t appear where it should have been removed
   • region, data retention and backup settings match the documentation