Die komplette Administration auf eurer Hardware — und damit jede Entscheidung darüber, wer welches Modell nutzt, was geprüft und was protokolliert wird. So sieht der Betrieb von Pia im Alltag aus.
Die Community Edition ist der echte Server, keine Demo: lokale Authentifizierung integriert und eine dokumentierte Anleitung von null bis zum ersten Login. Wer einen normalen .NET-Dienst und eine Datenbank betreiben kann, kann Pia betreiben. Der Server ist source-available: Kunden können den vollständigen Quellcode zur Prüfung anfragen.
Jeder Pia-Server läuft mit einer signierten Lizenzdatei, auch dieser — die Community-Lizenz wird kostenlos sein, sobald die Edition da ist. Beim ersten Start schreibt der Server ein Setup-Token ins Log; damit und mit der Lizenzdatei aktiviert ihr den Server auf der Setup-Seite, ohne Neustart.
Anleitung lesenCommunity und Enterprise sind dasselbe Container-Image. Was offen ist, entscheidet die signierte Lizenz — ein Wechsel später heißt also: eine Datei austauschen. Gleicher Server, gleiche Daten.
| Funktion | Community | Enterprise |
|---|---|---|
| Lokale Anmeldung mit MFA und Passkeys | Enthalten | Enthalten |
| KI-Proxy mit euren eigenen Provider-Keys | Enthalten | Enthalten |
| Sync und Chat-Verlauf über alle Geräte | Enthalten | Enthalten |
| Admin-Dashboard, Token-Übersicht, Laufzeit-Policies | Enthalten | Enthalten |
| Audit-Log und Erkennung auffälliger Anmeldungen | Enthalten | Enthalten |
| Verschlüsselung im Ruhezustand | Enthalten | Enthalten |
| Ende-zu-Ende-Verschlüsselung, Wiederherstellung, Geräte-Sperrung | Enthalten | Enthalten |
| Plugins, MCP und die öffentliche REST-API | Enthalten | Enthalten |
| Gruppen als Einheit der Policy | Eine feste Gruppe | Eigene Gruppen |
| Guardrails mit Entscheidungsprotokoll | Nicht enthalten | Enthalten |
| Microsoft Entra ID Single Sign-on | Nicht enthalten | Enthalten |
| Verwaltete Personas und Client-Richtlinien | Nicht enthalten | Enthalten |
| Knowledge Bases mit belegten Antworten | Nicht enthalten | Enthalten |
| Nutzer / Admins | 5 / 1 | Laut Vertrag |
Guardrails, Kontingente, Provider-Routing und Plugin-Freigaben sind Einstellungen an einer Gruppe. Deshalb stehen sie auf der Enterprise-Seite — nicht weil die Funktion abgeschaltet wäre. Alles oberhalb der Gruppen-Zeile läuft mit einer Community-Lizenz.
Beide Editionen sind bald verfügbar und noch nicht bestellbar. Die Community-Lizenz wird kostenlos sein.
Was ihr für eine Gruppe festlegt, gilt automatisch für jedes Mitglied: Token-Budgets pro Stunde, Tag und Woche — harte Grenzen, keine Richtwerte —, Kontingente pro Nutzer und für die Wissensdatenbank, die Guardrail-Einstellungen und die Liste der erlaubten Plugins. Regeln stehen damit nicht mehr nur in den Köpfen einzelner Leute.
Welches Modell antwortet, legt ihr in Stufen fest: ein Standard für die Gruppe, ein eigenes pro Modus — Textoptimierung anders als der Assistent — und für Assistenten-Personas eines je Typ, etwa ein Code-Modell für Entwickler-Personas oder ein schnelles für Alltagsfragen. Was ihr nicht setzt, fällt auf die nächste Stufe zurück, bis hin zum Server-Standard.
Rollen, Identitätsquellen, Deaktivieren, Sitzungs-Widerruf, Soft-Delete mit Wiederherstellung. Offboarding ist eine Checkliste, die der Server schon kennt.
Verbrauch über die Zeit, aufgeschlüsselt nach Nutzer, Gruppe und Modell, dazu die schwersten Anfragen und ein Anfrage-Log pro Nutzer — ihr seht die Rechnung kommen, bevor sie da ist. Was in den Anfragen stand, steht dort nicht: Das Log kennt Zeitpunkt, Modell, Vorlage und Token-Zahl — keinen einzigen Satz aus dem Gespräch.
Die Konsole ist in Bereiche geteilt — Konten, Gruppen, Guardrails, Audit, Token, Lizenz und mehr. Rollen (in der Konsole: Bundles) vergeben pro Bereich Lese- oder Änderungsrechte; eine Auditor-Rolle liegt fertig bei: Audit-Log, Token-Übersicht, KI-Feedback. Rechte vergeben kann nur ein Owner. Sinnvoll ab dem zweiten Admin — die Community Edition hat einen.
Rate-Limits, Kontingente, Identitäts- und Sperr-Richtlinien, KI-Payload-Grenzen, Provider-Retry — alles im laufenden Betrieb über die Admin-UI änderbar. Keine Config-Datei-Archäologie, kein Wartungsfenster. Ein Klick in den Einstellungen sagt euch, ob die Verbindung zum Anbieter steht. Besser, ihr merkt es als eure Nutzer.
Registrierte Geräte mit Pairing-Status und Sync-Cursorn. Eine verlorene Maschine widerrufen und vom Sync trennen — oder ganz löschen. Der Unterschied ist beabsichtigt und dokumentiert.
Edition, Ablauf und Anzahl der Arbeitsplätze auf einen Blick; Lizenzereignisse auf einer Zeitleiste; Lizenz aus der UI installieren oder ersetzen — schlägt die neue Datei bei der Prüfung fehl, wird die alte automatisch zurückgeholt. Ein Ablauf ist ein harter Stopp, kein schleichendes Abschalten: Der Server geht zurück in den Setup-Modus und wartet auf eine gültige Lizenz. Eure Daten bleiben dabei vollständig erhalten — der Server nimmt nur so lange keine Anfragen mehr an. Damit euch das nicht überrascht, warnt die Konsole ab 30 Tagen vor Ablauf.
Plugins gibt es in drei Formen — vom Server ausgelieferte Tool-Pakete, eigene MCP-Server und REST-APIs, die als Tools eingebunden werden. Welche davon eine Gruppe nutzen darf, ist eine Enterprise-Einstellung; der Katalog selbst läuft in jeder Edition. Drittanbieter-Plugins sind über Signaturzertifikate abgesichert, deren Vertrauensliste ihr verwaltet.
Connectors bringen Pods auf die Werkzeug-Ebene: Pod registrieren, Token ausstellen, Transport wählen, einer Gruppe zuweisen, Präsenz beobachten. Operators bringen sie auf die Aufgaben-Ebene: Skills bereitstellen, laufende Aufträge beaufsichtigen, Aufbewahrung steuern. Nichts nimmt teil, bis ein Admin es aktiviert.
Auth, Sync, KI-Proxy, Aufträge und die E2EE-Endpunkte sind ein dokumentierter Vertrag — baut eigene Integrationen gegen dieselbe API, die der Client nutzt.