Produktbeschreibung — Vertraulich

sovaia Workplace

Enterprise AI platform for knowledge-intensive work—secure, data-sovereign AI chat with integrated retrieval, a document workbench, and process automation.

Produkt-Überblick

sovaia Workplace is the AI-powered workspace for companies that want to make their internal knowledge sources, documents, and processes accessible via a secure, brandable chat interface—without transferring data to external cloud services. It runs on Swiss infrastructure operated by AIINNO AG (Datacenter CH) or, optionally, as a sovereign deployment at the customer’s site.

Important: All Large Language Models run on-premises on DGX/vLLM infrastructure. Public models (Claude, GPT-4o) are optional and accessible only with explicit scope authorization set by the admin—by default, no data flows to the 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

Layer	Level	Description
PostgreSQL (Instance)	Dedicated	Separate Postgres instance per tenant (separate PVC, separate credentials). Separate databases per service (`workplace_rag`, `litellm`, `chatbot`). Brand/department via column filter (`WHERE brand = $b AND dept = $d`). Live: Shared Planned: Dedicated
MinIO (Instance)	Dedicated	Dedicated MinIO instance per tenant (own PVC). Buckets: `content/`, `wp-library/`, `documents/`. Brand/department hierarchy via bucket prefix and MinIO access policies (`content/{brand}/{dept}/`). Server-side encryption with tenant-specific key (SSE-C or KMS). Live: Shared Planned: Dedicated + SSE
pgvector (Embeddings)	Filtered	Tenant-specific Postgres instance contains only tenant-specific embeddings — no shared vector space. Within: `WHERE brand = $b AND sensitivity <= $clearance AND lang = $lang`. No vectors from other tenants can be retrieved. Planned
Backup & Retention	Configurable	Velero backup schedules per tenant (custom BSL configuration). Session retention is configurable (default: 90 days). Backup target: tenant-specific bucket on a Backup MinIO instance or an S3-compatible endpoint at the customer’s site.

Identity — Realm-per-Tenant

Dimension	Level	Description
Realm Isolation	Dedicated	Separate Keycloak realm per production tenant. Complete isolation: Users, clients, roles, sessions, policies, brute-force settings. No cross-realm data exchange without explicit token exchange configuration. Planned: Production tenants
IdP Federation	Tenant-specific	Each tenant configures its own identity provider (Microsoft Entra, Google Workspace, ADFS, LDAP). No access to other tenant realms. Entra client ID/secret isolated per tenant.
Realm Admin	Self-Service	The tenant admin receives a standalone Keycloak admin role only for their realm. Can manage users, groups, roles, and clients independently—without AIINNO intervention.
MFA & Policies	Tenant-configured	MFA policies, password policies, session timeouts, and brute-force protection can be configured independently per realm. Production tenants can enforce MFA-Required for all users.
Brand Isolation (Intra-Realm)	Group-based	Within a tenant realm: Keycloak groups per brand/department. `workplace:scope` roles control which document classes the user is allowed to retrieve. The brand filter is embedded as a claim in the JWT and validated by the RAG service.
Keycloak Architecture	Dual-server	keycloak.int — Employees (EFEXCON/KIINNO internal services). identity-kc.int — External customer identities. Production tenant realms on identity-kc.int or, optionally, on a separate 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	Action
Tenant Isolation (Storage)	Planned	Dedicated MinIO + Postgres instance per production tenant. Intra-tenant: Brand/department filters via bucket prefix + SQL WHERE clause.
Tenant Isolation (Identity)	Planned	Separate Keycloak realm per tenant. Independent IdP federation, MFA policies, session settings, realm admin self-service.
Disk Encryption	Planned	LUKS-encrypted K8S volumes (Longhorn Encrypted StorageClass) for all tenant PVCs. Tenant-specific encryption key.
File Encryption (MinIO)	Planned	MinIO SSE-C or SSE-S3 + KMS (MinIO KES) for all objects in tenant buckets. Tenant key independent of other tenants.
Retrieval Governance	Live	pgvector WHERE `sensitivity <= clearance`. Fail-closed upload, fail-open retrieval. Brand+Lang filter. ABAC extension in roadmap.
Transport Encryption	Live	TLS everywhere (cert-manager), Cluster API only on Tailscale, public ingress via Cloudflare Tunnel. Intra-cluster mTLS on the roadmap.
Secret Management & KMS	Vault	HashiCorp Vault as the central KMS. Authentication via K8S service accounts. Automatic token rotation via the Vault Agent sidecar. Vault PKI Engine for TLS certificates. Audit log for all key accesses. No hard-coding in Git/Helm.
Data Sovereignty	Live	All data and LLM inference in a Swiss data center (KIINNO). Public scope optional, without internal RAG sources; explicit admin approval required.
Pseudonymization	Partial	Redact-by-default (ADR-067). Salt rotation every 90 days. Message classification gate before public LLM (Stage 2).
Network Isolation	Live	Namespace-based K8S NetworkPolicies. Admin UIs exclusively via Tailscale. K8S API not public. Tenant services do not communicate across namespaces.
Audit & Logging	Live	Prometheus + Loki + Grafana. Keycloak audit events. ArgoCD sync events. MinIO audit log. Retention configurable per tenant.
Backup & Recovery	Live (Shared)	Velero daily, mc mirror every 2 hours. Production tenants: own backup schedules + own BSL endpoint planned.
Orchestrator Exclusivity	Live	Agents never directly. Only via the Orchestrator layer with scope validation. No direct DB access from L5 to L3/L1.

Betriebsvoraussetzungen

System Requirements

Identity & Directory

Microsoft Entra ID or OIDC-compatible IdP — for employee SSO federation with the dedicated tenant realm. No access without SSO (no local users).
App registration in Entra ID — Client ID/Secret for the Keycloak OIDC provider. Set up once by KIINNO.
Clearly defined email domain — Domain mapping (e.g., @customer-inc.ch) is configured during onboarding.
User groups in the IdP — At least one group for Workplace users. Recommended: Separation of Basic Users, Experts, and Admins.

Network & Connectivity

HTTPS Port 443 of the Workplace endpoint must be accessible — firewall rules must be configured for restrictive enterprise firewalls.
Unrestricted SSO redirect — The Keycloak Authorizations endpoint must be accessible from the browser (no MITM proxy that breaks OIDC flows).
No VPN for end users — Access via Cloudflare Tunnel (public HTTPS). Admin access requires Tailscale (optional; can be set up if needed).

Devices & Browsers

Modern browser — Chrome 120+, Firefox 120+, Edge 120+, Safari 17+. Fully responsive.
First-party cookies allowed — for Keycloak SSO sessions on the Workplace domain.
No MDM certificate pinning on Cloudflare/Let’s Encrypt — may break OIDC flows in some enterprise MDM configurations.

Data Preparation (for RAG)

Documents in supported formats: PDF, DOCX, PPTX, XLSX, HTML, Markdown, CSV, JSON, XML, TXT. OCR for scanned PDFs included.
Sensitivity classification recommended — enables fine-grained retrieval governance. Without classification: all documents are treated as “internal.”
Brand/Department Tags — for intra-tenant filters (relevant for multi-brand or multi-department deployments).

Licensing & Onboarding

sovaia Workplace License — per user or per tenant (depending on the agreement).
Onboarding by KIINNO — tenant setup (namespace, storage instances, Keycloak realm, encryption keys, branding). Typical time required: 2–5 days.
Appoint a tenant admin — at least 1 admin (granted workplace:admin + Keycloak realm admin). Independently manages users, scopes, models, and governance settings.