LIVOI verarbeitet Nachrichten, Dokumente und weitere Inhalte, um Wissen bereitzustellen, Anfragen zu beantworten und angebundene Funktionen auszuführen. Dabei greifen die Anwendung, ihre Speicher und die für den jeweiligen Zweck konfigurierten Dienste ineinander.
Speicherung und Verarbeitung sind unterschiedliche Datenwege. Eine Datei kann im Dateispeicher der LIVOI-Umgebung liegen und zugleich für eine KI-Funktion an einen angebundenen Dienst übermittelt werden. Welche Inhalte diesen Weg nehmen, hängt von der Funktion, dem Dateiformat und der Konfiguration ab.
LIVOI verbindet deine Daten und Anwendungen mit den konfigurierten KI-Diensten. Die vereinfachte Grafik zeigt die wichtigsten Datenwege mit beispielhaften Anbietern und Kanälen.
Inhalte aufbereiten, Wissen suchen und Tools ausführen.
Speicherung
Dateien, Chats, Textabschnitte und Vektoren (Embeddings).
Auch Self-Hosted
LIVOI in deiner Infrastruktur. Du bestimmst den Standort.
Modelle & Dienste
Modellagnostisch
Zum Beispiel OpenAI, Azure oder Anthropic. Modelle und Anbieter nach Konfiguration.
Embedding-Modell Inhalte → Vektoren zurück an LIVOI
Antwortmodell Anfrage & Kontext → Antwort
Integrationen & MCP
Angebundene Systeme, MCP-Server und Custom Tools für eigene APIs.
DSGVOkonform
EU AI ActKI-Governance
AES-256Verschlüsselung
DeutschlandEntwicklung & Hosting
Die Pfeile zeigen Hin- und Rückwege. Logos stehen für Beispiele. Der Standort der KI-Dienste und Integrationen hängt von der gewählten Anbindung ab – auch bei Self-Hosting.
Modellagnostisch: LIVOI ist nicht an einen einzelnen KI-Anbieter gebunden. Antwort- und Embedding-Modelle lassen sich getrennt konfigurieren. Entscheidend sind die unterstützten Modelle, der gewählte Endpunkt und dessen Verarbeitungsstandort. Das Betriebsmodell von LIVOI und die Wahl des KI-Dienstes sind unabhängig voneinander.
Public API: Über die LIVOI API können eigene Anwendungen auf LIVOI zugreifen. Die Authentifizierung und Berechtigungen legen fest, welche Daten und Funktionen verfügbar sind. Die Public API ist der Zugang zu LIVOI; Custom Tools und MCP verbinden LIVOI mit weiteren Systemen.
Wähle einen Ablauf und das Betriebsmodell. Klicke auf eine Komponente, um Ein- und Ausgänge, Speicherung und Verarbeitungsort zu sehen. Der grüne LIVOI-Bereich zeigt bei Managed Hosting den Serverstandort Deutschland, bei Self-Hosting deine eigene Infrastruktur. Die Standorte angebundener Dienste richten sich nach der jeweiligen Anbindung.
Anwendung und Speicherung: deutsches Rechenzentrum. Angebundene Dienste haben eigene Verarbeitungsstandorte.
Anwendung und Speicherung: deutsches Rechenzentrum. Angebundene Dienste haben eigene Verarbeitungsstandorte.
Anwendung und Speicherung: deutsches Rechenzentrum. Angebundene Dienste haben eigene Verarbeitungsstandorte.
Die LIVOI-Umgebung umfasst die Anwendung, Hintergrundverarbeitung, Dateispeicher, Datenbank und technische Zwischenspeicher. KI-Dienste und Integrationen werden über konfigurierte Schnittstellen angesprochen. Ein solcher Dienst kann außerhalb der LIVOI-Umgebung betrieben werden; sein Verarbeitungsort ist deshalb gesondert zu betrachten.
Die folgenden Standortangaben beziehen sich auf unsere in Deutschland betriebene Umgebung. Bei Self-Hosting gelten stattdessen die von dir gewählten Standorte und Betriebseinstellungen.
Die folgenden LIVOI-Datenbestände werden in unserer Umgebung im deutschen Rechenzentrum gespeichert.
Datenart
Verwendung und Speicherung in LIVOI
Originaldateien und Anhänge
Liegen im konfigurierten Dateispeicher. Zugehörige Datensätze halten unter anderem Dateiname, Typ und Zuordnung fest.
Nachrichten und Gesprächsverläufe
Werden mit ihren Texten, Anhängen und weiteren Gesprächsbestandteilen gespeichert. Für das Modell freigegebene Teile können als Kontext verwendet werden.
Aufbereitetes Wissen
Textabschnitte, Quellenbezüge und Metadaten werden für die spätere Suche in der Datenbank hinterlegt.
Embeddings
Zahlenvektoren werden zusammen mit der Zuordnung zum Inhalt und dem verwendeten Embedding-Profil im Suchbestand gespeichert.
Agenten- und Zugriffskonfiguration
Beschreibt unter anderem Aufgaben, Modelle, verfügbare Funktionen und Zugriffsrechte.
Technische Verarbeitungsdaten
Auftragsstatus, Ereignisse und Zwischenspeicher unterstützen Hintergrundaufgaben und die Aktualisierung der Oberfläche. Ihre Lebensdauer richtet sich nach dem jeweiligen Zweck und der Konfiguration.
Ein Chunk ist ein Abschnitt eines Inhalts, beispielsweise ein Textausschnitt. Ein Embedding ist eine numerische Repräsentation, mit der sich ähnliche Inhalte finden lassen. Textabschnitte und Embeddings sind getrennte Bestandteile des Suchbestands: Die Vektoren ersetzen die gespeicherten Texte und Quelldateien nicht.
Wenn eine Datei als Wissensquelle aufgenommen wird, verarbeitet LIVOI sie im Hintergrund. Der Ablauf richtet sich nach dem Dateiformat und dem konfigurierten Embedding-Modell.
Datei aufnehmen: Die Datei wird im Dateispeicher abgelegt und einer Wissensquelle zugeordnet.
Inhalt aufbereiten: Bei textbasierter Verarbeitung werden Inhalte extrahiert und in Abschnitte zerlegt. Bei unterstützter multimodaler Verarbeitung können stattdessen PDF-Seiten oder die Datei selbst als Eingabe dienen.
Embeddings erstellen: Die aufbereiteten Eingaben werden an den konfigurierten Embedding-Dienst übermittelt. Dieser liefert die zugehörigen Zahlenvektoren zurück.
Suchbestand speichern: LIVOI speichert die Embeddings, die zugehörigen Texte oder Inhaltsbeschreibungen sowie Quellen- und gegebenenfalls Seitenangaben.
Auch die Aufteilung in Abschnitte ist keine automatische Anonymisierung. Ein Abschnitt kann weiterhin Namen, Geschäftsinformationen oder andere vertrauliche Angaben enthalten.
Bei einer Anfrage stellt LIVOI den für den Agenten vorgesehenen Kontext zusammen. Dazu können die aktuelle Nachricht, Agentenanweisungen, freigegebene Gesprächsinhalte, Anhänge und Ergebnisse aufgerufener Funktionen gehören.
Wenn der Agent die Wissenssuche nutzt, kommen weitere Schritte hinzu:
Suchanfrage vorbereiten: Für die semantische Suche wird die Suchanfrage an den konfigurierten Embedding-Dienst übermittelt und in einen Vektor umgewandelt.
Wissen finden: LIVOI durchsucht den im jeweiligen Zugriffskontext verfügbaren Wissensbestand. Dabei können Vektorsuche und textbasierte Suche zusammenspielen.
Treffer bereitstellen: Passende Textabschnitte und Quelleninformationen werden zurückgegeben. Je nach Verarbeitung können auch Dokumentzugriffe oder ausgewählte PDF-Seiten bereitgestellt werden. Eine zusätzlich konfigurierte KI-Bewertung kann Treffer vorab neu ordnen.
Antwort erzeugen: Das Antwortmodell verarbeitet die Anfrage und den bereitgestellten Kontext. LIVOI gibt das Ergebnis an den verwendeten Kanal zurück und speichert die zugehörigen Gesprächseinträge.
Dieses Zusammenspiel aus Suche und Antworterzeugung wird als Retrieval-Augmented Generation (RAG) bezeichnet. Embedding-Modell und Antwortmodell erfüllen dabei verschiedene Aufgaben. Ihre Datenwege und Verarbeitungsorte müssen unabhängig voneinander betrachtet werden.
Chat-Anhänge können dem Modell abhängig von der vorgesehenen Verarbeitung direkt zugänglich gemacht werden, etwa über zeitlich begrenzte Dateilinks. Bei der Dokumentensuche können ausgewählte PDF-Seiten als Dateiinhalt übergeben werden. Für unterstützte Audioeingaben kann ein Transkriptionsdienst die Aufnahme in Text umwandeln, bevor der Agent sie weiterverarbeitet.
Ein ursprüngliches Dokument oder Medium bleibt deshalb nicht allein dadurch innerhalb der LIVOI-Umgebung, dass es dort gespeichert wurde.
Ein Tool ist eine Funktion, die ein Agent während der Bearbeitung aufrufen kann. Das Modell erhält die verfügbaren Toolbeschreibungen und Eingabeschemata. Es kann einen Aufruf mit konkreten Argumenten erzeugen; der Ausführungsweg hängt vom Tooltyp ab.
Tooltyp
Wo wird ausgeführt?
Welche Daten fließen?
LIVOI-Tools
In der LIVOI-Anwendung, gegebenenfalls mit weiteren Dienstaufrufen. Beispiele sind Wissenssuche, Kalender- oder interne Agentenfunktionen.
Aufrufargumente werden verarbeitet; interne Daten oder Ergebnisse angebundener Dienste können an das Modell zurückgegeben werden.
Custom Tools
LIVOI erstellt einen HTTP-Aufruf an die konfigurierte API.
Die nach Eingabeschema geprüften Argumente werden als Pfadparameter, Query-Parameter oder Anfrageinhalt übertragen. Die API-Antwort fließt als Toolergebnis zurück.
MCP-Clients
Der Client läuft in LIVOI und verbindet den Agenten mit einem konfigurierten MCP-Server. Dieser führt die angebotenen Tools aus.
Tooldefinitionen gelangen vom Server zu LIVOI und zum Modell. Bei einem Aufruf gehen Toolname und Argumente an den Server; dessen Ergebnisse fließen zurück.
Modellseitige Tools
Beim KI-Dienst, beispielsweise bei einer dort bereitgestellten Websuche.
Die für die Funktion verwendeten Eingaben und Ergebnisse werden innerhalb dieses Dienstes und gegebenenfalls seiner angebundenen Quellen verarbeitet.
Bei einem Custom Tool legt die Konfiguration fest, welche API angesprochen wird, welche HTTP-Methode verwendet wird und welche Eingaben erwartet werden. LIVOI prüft die vom Modell gelieferten Argumente anhand dieses Schemas und setzt daraus die Anfrage zusammen. Hinterlegte Zugangsdaten und zusätzliche Header werden für die Verbindung zum Zielsystem verwendet.
Übertragen werden die für den Aufruf zusammengestellten Parameter und Inhalte. Das ist nicht automatisch der gesamte Chatverlauf; einzelne Argumente können aber Informationen aus der Nachricht oder dem bisherigen Kontext enthalten. Auch die zurückgelieferte API-Antwort kann Geschäftsdaten oder personenbezogene Angaben enthalten und wird als Toolergebnis für die weitere Verarbeitung bereitgestellt.
MCP (Model Context Protocol) verbindet den Agenten mit Tools eines Servers. Der MCP-Client in LIVOI und der MCP-Server sind getrennte Komponenten. Der Server kann selbst wiederum auf weitere Systeme zugreifen, etwa eine Wissensquelle oder eine Fachanwendung.
Der Datenweg lautet: Modellaufruf → LIVOI → MCP-Client → MCP-Server → gegebenenfalls Zielsystem. Ergebnisse nehmen den Rückweg und können in die Antwort des Modells einfließen. Der MCP-Client wird in der LIVOI-Umgebung im deutschen Rechenzentrum betrieben. Für den MCP-Server und seine Zielsysteme gilt der jeweils konfigurierte Standort; dieser kann außerhalb Deutschlands liegen.
LIVOI bindet aktivierte MCP-Clients an den jeweiligen Agenten. Die Verbindung kann konfigurierte Header oder eine verknüpfte persönliche Autorisierung verwenden. Welche Aktionen tatsächlich möglich sind, hängt auch von den Berechtigungen am Server und am Zielsystem ab. Je nach Konfiguration können neben Toolbeschreibungen und Schemata auch vom MCP-Server bereitgestellte Anweisungen in den Agentenkontext aufgenommen werden.
Ein Toolergebnis kann die Grundlage für die endgültige Antwort oder einen weiteren Toolaufruf bilden. Eine Anfrage kann deshalb mehrere Runden zwischen Modell, LIVOI und angebundenen Systemen auslösen.
Aufrufe und Ergebnisse können auch im Gesprächsverlauf gespeichert werden. Welche Teile später dem Modell oder in der Oberfläche angezeigt werden, ist von der Übermittlung während des ursprünglichen Aufrufs zu unterscheiden. Eine ausgeblendete Anzeige bedeutet nicht, dass keine Daten verarbeitet wurden.
Ein verbundener Kommunikationskanal transportiert Nachrichten und gegebenenfalls Anhänge zwischen LIVOI und dem jeweiligen Kanal. Eine Integration kann außerdem über Tools oder eigenständige Abläufe Informationen abrufen und Aktionen ausführen. Umfang und Ziel der Übermittlung richten sich nach der aktivierten Funktion, ihrer Konfiguration und dem konkreten Aufruf.
Wo liegen die Daten und wohin werden sie übermittelt?
Bei unserem Managed Hosting erfolgen die zentrale Speicherung und der Betrieb von LIVOI in einem deutschen Rechenzentrum. Bei Self-Hosting legst du diese Standorte selbst fest. Für die Ausführung einer Funktion können Inhalte zusätzlich an einen konfigurierten Dienst übertragen werden. Die folgende Übersicht zeigt die jeweiligen Empfänger:
Ziel
Welche Daten gehen dorthin?
Standort
LIVOI-Dateispeicher
Originaldateien und Anhänge.
Deutsches Rechenzentrum.
LIVOI-Datenbank und Suchbestand
Gesprächsverläufe, aufbereitete Texte, Metadaten, Embeddings sowie Agenten- und Zugriffskonfiguration.
Deutsches Rechenzentrum.
Embedding-Dienst
Suchtexte, Textabschnitte oder je nach Modell PDF-Seiten und unterstützte Medien. Die erzeugten Vektoren fließen zu LIVOI zurück.
Verarbeitungsregion des konfigurierten Dienstes.
Antwortmodell und weitere KI-Dienste
Nachrichten, Agentenanweisungen, freigegebene Gesprächsinhalte, Tooldefinitionen und -ergebnisse, Suchtreffer sowie gegebenenfalls Anhänge oder Audio für Transkription.
Verarbeitungsregion des jeweiligen KI-Dienstes.
Custom-Tool-API
Die für den konkreten Aufruf zusammengestellten Parameter und Inhalte sowie die für die Verbindung konfigurierte Authentifizierung.
Standort der angebundenen API beziehungsweise des Zielsystems.
MCP-Server und seine Zielsysteme
Toolname und Aufrufargumente sowie Verbindungsdaten zur Authentifizierung. Der Server liefert Tooldefinitionen und Ergebnisse zurück und kann weitere Systeme ansprechen.
Standort des konfigurierten MCP-Servers und gegebenenfalls nachgelagerter Systeme. Der Client selbst läuft in LIVOI in Deutschland.
Kommunikationskanal
Nachrichten, Antworten und gegebenenfalls Anhänge, die über diesen Kanal ausgetauscht werden.
Verarbeitungsorte des jeweiligen Kanaldienstes.
Die Verarbeitung bei angebundenen Diensten ist nicht automatisch auf Deutschland beschränkt. Maßgeblich sind die jeweils eingerichteten Dienstendpunkte, Verarbeitungsregionen und vereinbarten Betriebsbedingungen. Das gilt auch für modellseitige Tools und deren Datenquellen.
Die erzeugten Antworten, Suchvektoren und Toolergebnisse fließen zur weiteren Verarbeitung an LIVOI zurück. Eine Rückgabe an LIVOI bedeutet nicht, dass beim empfangenden Dienst keine Daten mehr vorhanden sind; dessen Speicherung und Aufbewahrung richtet sich nach den dort geltenden Bedingungen. Für Sicherungen und Betriebsprotokolle sind die gesonderten Betriebs- und Aufbewahrungsregeln maßgeblich.
Die Wahl eines anderen Embedding-Dienstes verändert nur diesen Verarbeitungsschritt. Antwortmodelle, Medienverarbeitung, Custom Tools und MCP-Anbindungen können weiterhin eigene Datenwege haben.
LIVOI ordnet Daten einem Mandanten und den jeweiligen Ressourcen zu. Benutzerkontext, Rollen, Berechtigungen und Freigaben bestimmen den Zugriff auf diese Ressourcen. Diese Zugriffskontrolle ist von der Frage zu unterscheiden, an welchem Standort die Daten gespeichert oder verarbeitet werden.
Dateien und daraus abgeleitete Suchinhalte sind miteinander verknüpft. Beim Entfernen einer Wissensquelle werden ihre zugehörigen Suchabschnitte entfernt; ein gemeinsam verwendetes Speicherobjekt kann bestehen bleiben, solange es noch an anderer Stelle referenziert wird. Gesprächsverläufe, Sicherungen und bereits an andere Dienste übermittelte Inhalte haben jeweils einen eigenen Lebenszyklus.
Für die Einordnung einer konkreten Umgebung sind damit vier Angaben entscheidend: die eingesetzten Speicher, die konfigurierten KI-Dienste, die aktivierten Integrationen und die geltenden Aufbewahrungsregeln.
