Produktbeschreibung — Vertraulich

sovaia Workplace

Enterprise-KI-Plattform für wissensintensive Arbeit — sicherer, datensouveräner AI-Chat mit integriertem Retrieval, Dokumenten-Workbench und Prozessautomatisierung.

Produkt-Überblick

sovaia Workplace ist der KI-Arbeitsplatz für Unternehmen, die ihre internen Wissensquellen, Dokumente und Prozesse über eine sichere, branding-fähige Chat-Oberfläche zugänglich machen wollen — ohne Daten an externe Cloud-Dienste zu übergeben. Der Betrieb erfolgt auf von KIINNO AG betriebener Schweizer Infrastruktur (Datacenter CH) oder optional als Sovereign Deployment beim Kunden.

Wichtig: Alle Large Language Models laufen on-premise auf DGX-/vLLM-Infrastruktur. Öffentliche Modelle (Claude, GPT-4o) sind optional und nur mit explizit gesetzter Scope-Freigabe durch den Admin erreichbar — standardmässig fliessen keine Daten ins Internet.

Kernfunktionen

💬

Konversationeller KI-Chat

ChatGPT-ähnliche Oberfläche mit Session-Persistenz, parallelen Threads und konfigurierbarem Reasoning-Modus (Deepseek-r1).

🔍

RAG / Retrieval-Governance

Semantische Suche über interne Dokumente (pgvector). Sensitivity-Filter je Nutzer-Clearance — Antworten stets aus freigegebenen Quellen.

📄

Dokumenten-Workbench

Upload per Drag&Drop, Zusammenfassung, Analyse, formatgenaue Übersetzung (docling + DeepL). Bibliothek-Store mit RBAC pro Nutzer/Brand.

🎯

Adaptive Oberfläche

Progressive Disclosure: einfacher Modus für Endnutzer, Experten-Modus für Power-User. Konfigurierbar per Admin ohne Code-Änderung.

🤖

Agent-Palette

/-Aktionspalette mit rollen-basierter Sichtbarkeit. Unternehmens-Prozesse als zuschaltbare Agenten (Vertragsanalyse, Übersetzung, Recherche).

🎨

White-Label / Multi-Brand

Per-Tenant Logo, Farben, Theme. Jede Organisation erhält eine eigene, gebrandete Instanz. Brand/Abteilungs-Isolation über Filter innerhalb des Tenants.

📊

Admin-Analytics

Cross-User-Auswertungen (anonymisiert) für Tenant-Admins: Nutzungsmetriken, häufige Anfragen, Agenten-Performance.

🔗

Integrationen

LiteLLM-Router (modellunabhängig), SharePoint/Teams (Roadmap), SMTP-Bridge, MinIO-Storage, PostgreSQL/pgvector.

KI-Pipeline Scopes

Sicherheitsarchitektur

Tenant-Modelle im Vergleich

Standard / Intern

Shared Infrastructure

Storage: Gemeinsame MinIO- & Postgres-Instanzen; Isolation via Namespace + Bucket-Prefix / DB-Schema
Identity: Gemeinsamer Keycloak-Realm mit Gruppen-Isolation pro Tenant
Datenverschlüss.: Keine Datei-/Disk-Encryption; TLS in Transit
Betrieb: Geringer Ops-Overhead; KIINNO managed
Geeignet für: Interne EFEXCON/KIINNO-Services, Piloten, Entwicklung

Produktiv / Enterprise

Dedicated Infrastructure

Storage: Eigene MinIO-Instanz + eigene Postgres-Instanz pro Tenant; Brand/Abt. via Filter innerhalb des Tenants
Identity: Dedizierter Keycloak-Realm pro Tenant; eigene IdP-Federation, MFA-Policy, Realm-Admin
Datenverschlüss.: Datei-Encryption (MinIO SSE-C / SSE-S3) + Disk-Encryption (LUKS PVCs) mit Tenant-Keys
Betrieb: Höherer Ops-Overhead; eigene ArgoCD-App-of-Apps pro Tenant
Geeignet für: Produktive Kundenmandanten, regulierte Branchen, Compliance-Anforderungen

Storage-Isolation

Schicht	Niveau	Beschreibung
PostgreSQL (Instanz)	Dediziert	Eigene Postgres-Instanz pro Tenant (eigenes PVC, eigene Credentials). Separate Datenbanken pro Service (`workplace_rag`, `litellm`, `chatbot`). Brand/Abteilung über Spalten-Filter (`WHERE brand = $b AND dept = $d`). Live: Shared Geplant: Dedicated
MinIO (Instanz)	Dediziert	Eigene MinIO-Instanz pro Tenant (eigenes PVC). Buckets: `content/`, `wp-library/`, `documents/`. Brand/Abteilungs-Hierarchie via Bucket-Prefix und MinIO-Access-Policies (`content/{brand}/{dept}/`). Server-Side Encryption mit Tenant-eigenem Key (SSE-C oder KMS). Live: Shared Geplant: Dedicated + SSE
pgvector (Embeddings)	Gefiltert	Tenant-eigene Postgres-Instanz enthält nur tenant-eigene Embeddings — kein shared vector space. Innerhalb: `WHERE brand = $b AND sensitivity <= $clearance AND lang = $lang`. Keine Vektoren aus anderen Tenants abrufbar. Geplant
Backup & Retention	Konfigurierbar	Velero-Backup-Schedules pro Tenant (eigene BSL-Konfiguration). Session-Retention konfigurierbar (Standard: 90 Tage). Backup-Target: tenant-eigener Bucket auf Backup-MinIO-Instanz oder S3-kompatibler Endpoint beim Kunden.

Identity — Realm-per-Tenant

Dimension	Niveau	Beschreibung
Realm-Isolation	Dediziert	Eigener Keycloak-Realm pro produktivem Tenant. Vollständige Isolation: Nutzer, Clients, Rollen, Sessions, Policies, Brute-Force-Einstellungen. Kein Cross-Realm-Datenaustausch ohne explizite Token-Exchange-Konfiguration. Geplant: Produktiv-Tenants
IdP-Federation	Tenant-eigen	Jeder Tenant konfiguriert seinen eigenen Identity Provider (Microsoft Entra, Google Workspace, ADFS, LDAP). Kein Zugriff auf andere Tenant-Realms. Entra-Client-ID/Secret pro Tenant isoliert.
Realm-Admin	Self-Service	Tenant-Admin erhält eigenständige Keycloak-Admin-Rolle nur für seinen Realm. Kann Nutzer, Gruppen, Rollen und Clients selbst verwalten — ohne KIINNO-Intervention.
MFA & Policies	Tenant-konfiguriert	MFA-Policies, Passwort-Policies, Session-Timeouts, Brute-Force-Protection unabhängig pro Realm konfigurierbar. Produktiv-Tenants können MFA-Required für alle Nutzer erzwingen.
Brand-Isolation (Realm-intern)	Gruppen-basiert	Innerhalb eines Tenant-Realms: Keycloak-Gruppen pro Brand/Abteilung. `workplace:scope`-Rollen steuern, welche Dokument-Klassen der Nutzer retrieven darf. Brand-Filter wird als Claim in den JWT eingebettet und vom RAG-Service validiert.
Keycloak-Architektur	Dual-Server	keycloak.int — Mitarbeitende (EFEXCON/KIINNO-interne Services). identity-kc.int — Externe Kunden-Identitäten. Produktive Tenant-Realms auf identity-kc.int oder optional eigenem Keycloak-Deployment (Sovereign).

Verschlüsselung

Geplant

Disk-Encryption (At-Rest)

LUKS-verschlüsselte Kubernetes PVCs für alle Tenant-Datenbankvolumes (Postgres, MinIO). Encryption-Key pro Tenant — kein geteilter Volume-Key zwischen Tenants.

K8S StorageClass mit Encryption-Annotation
Key-Derivation via KMS oder tenant-eigener Secret
Longhorn Encrypted Volumes als Basis
Key-Rotation: manuell via Re-Encrypt-Job oder KMS-automatisiert

Geplant

File-Encryption (MinIO SSE)

Server-Side Encryption auf Objekt-Ebene in MinIO. Jedes Dokument/Embedding-Artefakt verschlüsselt gespeichert.

SSE-C: Tenant managed Key (Client übergibt Key bei PUT/GET). Maximale Kontrolle, kein KMS-Overhead.
SSE-S3 + KMS: MinIO KES mit Vault / AWS KMS / eigener HSM. Empfohlen für regulierte Branchen.
Scope: content/, wp-library/, documents/ Buckets

Live

Transport-Encryption

TLS an allen Ingress-Endpunkten (cert-manager / Let's Encrypt). Cluster-API ausschliesslich über Tailscale VPN (WireGuard). Intra-Cluster-Kommunikation über ClusterIP (optional: mTLS via Linkerd/Istio auf Roadmap).

Entschieden

HashiCorp Vault — KMS & PKI

Vault als zentrales Secret- und Key-Management-System.

K8S Service-Account Auth: Pods authentifizieren sich via K8S-ServiceAccount-Token-Review — kein statisches Passwort
Auto Token-Rotation: Vault Agent Sidecar erneuert Tokens automatisch vor Ablauf
PKI Engine: Alle TLS-Zertifikate über Vault ausgestellt und rotiert
Transit Engine: MinIO KES verwendet Vault Transit als Root-KMS für SSE-Key-Wrapping
KV-v2: Tenant-Secrets versioniert, Audit-Log für alle Zugriffe

Teilweise live

Pseudonymisierung

Redact-by-Default-Prinzip (ADR-067). Salt-Rotation alle 90 Tage (konfigurierbar). Message-Classification-Gate vor Public-LLM (Stage 2).

Live

Audit & Monitoring

Prometheus + Loki + Grafana. Keycloak-Audit-Events (Login, Token-Issue, Admin-Änderungen). ArgoCD Sync-Events. MinIO Audit-Log. Retention konfigurierbar per Tenant.

Architektur-Entscheidungen

1. Entschieden

Key-Management — HashiCorp Vault

HashiCorp Vault als zentrales Secret-Backend für alle Tenant-Encryption-Keys (MinIO SSE-C / KES + LUKS-Key-Derivation). Authentifizierung über K8S-Service-Accounts (kein statisches Passwort). Automatische Token-Rotation via Vault Agent Sidecar. Audit-Log für alle Key-Zugriffe. TLS-Zertifikate ebenfalls Vault-gesichert (PKI Secrets Engine). Compliance-fähig (ISO 27001, BSI).

Setup: Vault PKI Engine für Zertifikate · Vault KV-v2 für Tenant-Secrets · K8S Auth Method (ServiceAccount-Token-Review) · Vault Agent Auto-Token-Renewal · MinIO KES → Vault Transit Engine als Root-KMS

2. Entschieden

Keycloak-Realm-Hosting — Realm per Tenant

Dedizierter Realm pro Tenant auf shared identity-kc.int. Geringer Ops-Overhead; vollständige Realm-Isolation (Nutzer, Clients, MFA-Policies, IdP-Federation). Upgrade auf Dedicated Keycloak-Instanz für regulierte Branchen (Banking, Gesundheit) bei Bedarf möglich.

3. Entschieden

Disk-Encryption — Longhorn Encrypted Volumes

Longhorn StorageClass mit LUKS-Passphrase-Secret, Key aus Vault (Transit Engine). Native K3S-Integration, Key pro PVC — pro Tenant-Volume. Kein Node-Level-Eingriff nötig.

4. Entschieden

Tenant-Onboarding — Manuelles Helm-Chart → ApplicationSet

Tenant-Values-File in gitops/tenants/{tenant}/, ArgoCD App-of-Apps. Simpel und transparent. Migration zu ArgoCD ApplicationSet + Git-Generator ab Tenant >3.

Hardening-Strategie: Eigener Betrieb zuerst

EFEXCON/KIINNO betreiben ihre eigenen Intern- und Prod-Tenants als erste Produktiv-Tenants auf dieser Architektur. Issues, die im eigenen Betrieb entdeckt werden, fliessen direkt in die Kundenhardening-Checkliste ein. Der erste Kundenmandant wird erst ongeboardet, wenn der eigene Betrieb stabil läuft.

Sicherheits-Matrix

Dimension	Status	Massnahme
Tenant-Isolation (Storage)	Geplant	Dedizierte MinIO + Postgres-Instanz pro Produktiv-Tenant. Intra-Tenant: Brand/Abteilungs-Filter via Bucket-Prefix + SQL-WHERE-Klausel.
Tenant-Isolation (Identity)	Geplant	Eigener Keycloak-Realm pro Tenant. Unabhängige IdP-Federation, MFA-Policies, Session-Settings, Realm-Admin-Self-Service.
Disk-Encryption	Geplant	LUKS-verschlüsselte K8S Volumes (Longhorn Encrypted StorageClass) für alle Tenant-PVCs. Tenant-eigener Encryption-Key.
File-Encryption (MinIO)	Geplant	MinIO SSE-C oder SSE-S3 + KMS (MinIO KES) für alle Objekte in Tenant-Buckets. Tenant-Key unabhängig von anderen Tenants.
Retrieval-Governance	Live	pgvector WHERE `sensitivity <= clearance`. Fail-closed Upload, fail-open Retrieval. Brand+Lang-Filter. ABAC-Erweiterung in Roadmap.
Transport-Encryption	Live	TLS überall (cert-manager), Cluster-API nur Tailscale, Public-Ingress Cloudflare Tunnel. Intra-Cluster mTLS auf Roadmap.
Secret-Management & KMS	Vault	HashiCorp Vault als zentrales KMS. Authentifizierung über K8S-Service-Accounts. Automatische Token-Rotation via Vault Agent Sidecar. Vault PKI Engine für TLS-Zertifikate. Audit-Log für alle Key-Zugriffe. Kein Hardcoding in Git/Helm.
Datensouveränität	Live	Alle Daten und LLM-Inferenz in CH-Datacenter (KIINNO). Public-Scope optional, ohne interne RAG-Quellen, explizite Admin-Freigabe erforderlich.
Pseudonymisierung	Teilweise	Redact-by-Default (ADR-067). Salt-Rotation 90d. Message-Classification-Gate vor Public-LLM (Stage 2).
Netzwerk-Isolation	Live	Namespace-basierte K8S NetworkPolicies. Admin-UIs ausschliesslich Tailscale. K8S-API nicht öffentlich. Tenant-Services kommunizieren nicht cross-namespace.
Audit & Logging	Live	Prometheus + Loki + Grafana. Keycloak Audit-Events. ArgoCD Sync-Events. MinIO Audit-Log. Retention konfigurierbar per Tenant.
Backup & Recovery	Live (Shared)	Velero täglich, mc mirror 2h. Produktiv-Tenants: eigene Backup-Schedule + eigener BSL-Endpoint geplant.
Orchestrator-Exklusivität	Live	Agents niemals direkt. Nur via Orchestrator-Layer mit Scope-Validierung. Keine direkten DB-Zugriffe von L5 auf L3/L1.

Betriebsvoraussetzungen

Identity & Verzeichnis

Microsoft Entra ID oder OIDC-kompatibler IdP — für Employee-SSO-Federation mit dem dedizierten Tenant-Realm. Ohne SSO kein Zugang (keine lokalen User).
App-Registrierung in Entra ID — Client-ID/Secret für Keycloak-OIDC-Provider. Einmalig durch KIINNO eingerichtet.
E-Mail-Domain klar definiert — Domain-Mapping (z.B. @kunden-ag.ch) wird bei Onboarding konfiguriert.
Benutzergruppen im IdP — mindestens eine Gruppe für Workplace-Nutzer. Empfohlen: Trennung Basic-User / Expert / Admin.

Netzwerk & Konnektivität

HTTPS Port 443 des Workplace-Endpunkts erreichbar — Firewall-Freigabe bei restriktiven Enterprise-Firewalls erforderlich.
SSO-Redirect ungehindert — Keycloak-Authorizations-Endpunkt muss aus dem Browser erreichbar sein (kein MITM-Proxy, der OIDC-Flows bricht).
Kein VPN für Endnutzer — Zugang über Cloudflare Tunnel (öffentliches HTTPS). Admin-Zugänge erfordern Tailscale (optional, bei Bedarf eingerichtet).

Endgeräte & Browser

Moderner Browser — Chrome 120+, Firefox 120+, Edge 120+, Safari 17+. Vollständig Responsive.
First-Party Cookies erlaubt — für Keycloak-SSO-Sessions auf der Workplace-Domain.
Kein MDM-Zertifikat-Pinning auf Cloudflare/Let's Encrypt — kann OIDC-Flows bei manchen Enterprise-MDM-Konfigurationen brechen.

Datenvorbereitung (für RAG)

Dokumente in unterstützten Formaten: PDF, DOCX, PPTX, XLSX, HTML, Markdown, CSV, JSON, XML, TXT. OCR für gescannte PDFs inklusive.
Sensitivitäts-Klassifizierung empfohlen — ermöglicht feingranulare Retrieval-Governance. Ohne Klassifizierung: alle Dokumente als "intern" behandelt.
Brand/Abteilungs-Tags — für intra-tenant Filter (relevant bei Multi-Brand- oder Abteilungs-Deployments).

Lizenz & Onboarding

sovaia Workplace Lizenz — pro Nutzer oder pro Tenant (je nach Vereinbarung).
Onboarding durch KIINNO — Tenant-Setup (Namespace, Storage-Instanzen, Keycloak-Realm, Encryption-Keys, Branding). Typischer Zeitaufwand: 2–5 Tage.
Tenant-Admin benennen — mindestens 1 Admin (erhält workplace:admin + Keycloak-Realm-Admin). Verwaltet Nutzer, Scopes, Modelle, Governance-Einstellungen selbstständig.

sovaia Workplace

Produkt-Überblick

Kernfunktionen

KI-Pipeline Scopes

Tenant-Modelle im Vergleich

Storage-Isolation

Identity — Realm-per-Tenant

Verschlüsselung

Architektur-Entscheidungen

Sicherheits-Matrix

Betriebsvoraussetzungen

Betriebsvoraussetzungen

Deployment-Modelle