Enterprise-Richtlinie

Pia wendet beim Start eine Enterprise-Richtlinie an. IT-Administratoren setzen damit Standardwerte oder sperren einzelne Einstellungen auf verwalteten Geräten. Eine Richtlinie kann aus zwei Quellen kommen: aus einer Datei policy.json auf dem Gerät oder aus einer Richtlinie, die die Administration auf einem Pia Server für die Gruppe des Benutzers veröffentlicht.

Dateispeicherort

Pia sucht policy.json an drei Stellen und verwendet die erste, die existiert. Die drei Dateien werden nie zusammengeführt.

%ProgramFiles%\Pia.Wpf\current\policy.json    (der Ordner, aus dem Pia.exe läuft)
%ProgramFiles%\Pia.Wpf\policy.json            (das Installationsverzeichnis)
C:\ProgramData\Pia.Wpf\policy.json

Lege die Datei ins Installationsverzeichnis, neben den Starter, mit dem die Benutzer Pia öffnen. Der Ordner, aus dem Pia.exe läuft, wird bei jeder Aktualisierung ersetzt — eine Richtlinie, die dort liegt, ist nach dem nächsten Update weg.

Standardbenutzer können diese Ordner lesen; nur Administratoren dürfen schreiben. Benutzer können die Datei nicht aus Pia heraus überschreiben.

Achtung

Pia lädt die Richtlinie nur einmal beim Start. Eine Änderung an policy.json — oder an einer auf dem Server veröffentlichten Richtlinie — greift erst, nachdem der Benutzer Pia neu startet.

Richtlinie vom Pia Server

Die Administration kann dasselbe Dokument in der Admin-Oberfläche des Pia Servers für eine ganze Gruppe veröffentlichen; es erreicht den Client über den normalen Sync. Eine vom Server veröffentlichte Richtlinie hat dieselben zwei Abschnitte, defaults und enforce, mit genau derselben Bedeutung wie in einer Datei. Alles Weitere in dieser Referenz gilt unverändert.

Drei Dinge solltest du über eine vom Server veröffentlichte Richtlinie wissen:

• Sie wird auf dem Gerät zwischengespeichert. Die Richtlinie gilt nach einem Neustart und ohne Netzverbindung weiter, und sie verfällt nicht — eine Richtlinie, die der Server zuletzt vor Tagen bestätigt hat, gilt immer noch.
• Sie greift beim nächsten Start. Veröffentlicht die Administration eine Richtlinie, während Pia läuft, holt der nächste Sync sie ab und Pia wendet sie beim nächsten Start an. Das ist so vorgesehen.
• Beim Abmelden wird sie verworfen. Pia löscht die zwischengespeicherte Server-Richtlinie beim Abmelden, damit die nächste Person, die sich auf diesem Gerät anmeldet, nicht die Richtlinie der Gruppe des vorherigen Benutzers erbt.

Hinweis

Die allererste Anmeldung lässt sich nicht einschränken: Eine auf dem Server veröffentlichte Liste erlaubter Anmeldeanbieter kann genau die Anmeldung, die sie abholt, noch nicht begrenzen. Ein serverseitiges allowedSyncProviders wirkt deshalb erst ab dem zweiten Start. Setze es in policy.json, wenn schon die erste Anmeldung eingeschränkt sein muss.

Eine Anmeldemethode, die in allowedSyncProviders fehlt, ist im Einrichtungsassistenten und in den Kontoeinstellungen ausgeblendet, und eine Anmeldung darüber wird mit „Diese Anmeldemethode ist durch die Richtlinie deiner Organisation deaktiviert.“ abgelehnt. Wer bereits mit einer Methode angemeldet ist, die die Richtlinie nicht mehr erlaubt, wird beim nächsten Start von Pia abgemeldet: Die Sitzung wird auch auf dem Server beendet, und Sync bleibt aus, bis zur nächsten Anmeldung. Die Abmeldung verwirft auch die zwischengespeicherte Server-Richtlinie, sodass die nächste Anmeldung wieder uneingeschränkt ist — setze allowedSyncProviders in policy.json, um eine Methode dauerhaft abzulehnen.

Welche Quelle gewinnt

Eine vom Server veröffentlichte Richtlinie hat bei jedem Schlüssel, den beide setzen, Vorrang vor der policy.json des Geräts. Innerhalb einer Quelle überschreibt enforce die Wahl des Benutzers, während defaults nur dort einspringt, wo der Benutzer nichts gewählt hat. Die vollständige Reihenfolge — der erste Treffer gewinnt:

1. enforce vom Server
2. enforce aus policy.json
3. der eigene Wert des Benutzers
4. defaults vom Server
5. defaults aus policy.json
6. der eingebaute Standard von Pia

Dateiformat

Eine Richtlinie hat zwei Abschnitte auf oberster Ebene, beide mit derselben Struktur wie Pias Benutzereinstellungen:

• defaults — ein Startwert. Er wird angewendet, solange der Wert des Benutzers noch dem Pia-Standard entspricht oder noch dem Wert, den die Richtlinie zuvor gesetzt hat.
• enforce — fest gesetzte Werte. Die zugehörigen Bedienelemente in Pias Einstellungs-UI werden deaktiviert, sodass der Benutzer sie nicht ändern kann. Erscheint eine Eigenschaft in beiden Abschnitten, gewinnt enforce.

Ein geänderter defaults-Wert wird erneut angewendet

Ändert die Administration einen Wert unter defaults, wendet Pia den neuen Wert beim nächsten Start erneut an — es sei denn, der Benutzer hat diese Einstellung inzwischen selbst geändert; dann bleibt seine Wahl bestehen. Diese Regel gilt für beide Quellen und ändert damit auch das Verhalten bestehender Installationen, die nur policy.json verwenden: Ein geänderter defaults-Wert in der Datei erreicht jetzt auch Geräte, die den alten Wert schon übernommen hatten.

Hinweis

Ein Schlüssel wirkt, weil er vorhanden ist, nicht weil sein Wert vom Pia-Standard abweicht. "theme": "System" unter enforce fixiert das Design auf System und graut das Bedienelement aus, obwohl System ohnehin der Standard ist. Nur die Schlüssel, die du weglässt, bleiben dem Benutzer überlassen.

Unterstützte Einstellungen

Alle Eigenschaftsnamen verwenden camelCase. Unbekannte Eigenschaften werden ignoriert. Ungültiges JSON wird als Warnung protokolliert und die Richtlinie wird nicht angewendet — schau ins Anwendungs-Log, falls eine Richtlinie nicht zu greifen scheint.

Eigenschaft	Typ	Standard	Beschreibung
theme	"System" | "Dark" | "Light"	"System"	UI-Design
uiLanguage	"EN" | "DE" | "FR"	"EN"	Sprache der Oberfläche
targetLanguage	"EN" | "DE" | "FR"	nicht gesetzt	Standard-Ausgabesprache für Optimieren
targetSpeechLanguage	"Auto" | "EN" | "DE" | "FR"	"Auto"	Spracherkennungs-Sprache
defaultOutputAction	"CopyToClipboard" | "AutoType" | "PasteToPreviousWindow"	"CopyToClipboard"	Was nach dem Optimieren passiert
autoTypeDelayMs	integer	10	Verzögerung beim Auto-Tippen in Millisekunden
defaultTemplateId	GUID	nicht gesetzt	Standard-Optimierungsvorlage
whisperModel	"Tiny" | "Base" | "Small" | "Medium" | "Large"	"Base"	Whisper-Modellgröße
ttsEnabled	bool	false	Sprachsynthese aktivieren
ttsVoiceModelKey	string	"en_US-lessac-medium"	TTS-Stimmen-ID
startMinimized	bool	false	Minimiert im Infobereich starten
launchAtStartup	bool	true	Pia mit Windows starten
showTodoPanelButton	bool	true	Todo-Panel-Schaltfläche im Hauptfenster anzeigen
autoUpdateEnabled	bool	true	Automatische Aktualisierung beim Start zulassen
syncEnabled	bool	false	Pia Cloud Sync aktivieren
serverUrl	string	nicht gesetzt	Pia-Cloud-Server-URL (für Self-Hosting)
trustSelfSignedCertificates	bool	false	Selbstsignierte TLS-Zertifikate vom konfigurierten Pia-Server (sein Host und Port) akzeptieren, niemals von anderen Hosts
allowedSyncProviders	string[]	nicht gesetzt (alle erlaubt)	Erlaubte Anmeldemethoden: "local", "google", "microsoft", "entraid". Siehe Richtlinie vom Pia Server
useSameProviderForAllModes	bool	true	Einen KI-Anbieter für Optimieren und Assistent verwenden
modeProviderDefaults	object	{}	Zuordnung von Gesprächsmodus zu KI-Anbieter-GUID
privacy	object	siehe unten	Datenschutzeinstellungen (verschachtelt)

privacy ist ein verschachteltes Objekt:

Eigenschaft	Typ	Standard	Beschreibung
tokenizationEnabled	bool	true	PII durch Tokens ersetzen, bevor Text an die KI gesendet wird

Den Assistenten steuern

Diese Einstellungen lohnt es sich auf verwalteten Geräten festzulegen, weil sie bestimmen, was Pia von sich aus tun darf. Siehe Tool-Berechtigungen und Agentenläufe.

Eigenschaft	Typ	Standard	Beschreibung
assistantFilesFolder	string	nicht gesetzt	Der einzige Ordner, auf den der Assistent zugreifen darf
assistantFileToolsEnabled	bool	true	Lesen und Schreiben von Dateien in diesem Ordner erlauben
assistantGitToolsEnabled	bool	true	Git-Befehle in diesem Ordner erlauben
agentRunAutoApproveBuiltInWrites	bool	false	Pias eigene Schreibwerkzeuge in Agentenläufen und im Sprachmodus ohne Freigabe ausführen
chatHistoryEnabled	bool	true	Assistenten-Chats auf dem Gerät speichern
chatHistoryRetentionDays	integer	30	Chats löschen, die so viele Tage nicht geöffnet wurden
enableMeetingDiarization	bool	true	Besprechungstranskripte nach Sprechern aufteilen
meetingSpeakerNaming	bool	true	Zustimmungssatz und Umbenennen geben einem Sprecher einen Namen, und die Teilnehmerliste kommt in Zusammenfassungen und gespeicherte Notizen

Ist meetingSpeakerNaming auf false gesetzt, behält jeder Sprecher eine Bezeichnung wie Sprecher 1. Umbenennen ist in beiden Transkriptfenstern abgeschaltet, Zusammenfassungen bekommen keine Teilnehmerliste, das Formular zum Speichern im Vault ist nicht mit Teilnehmenden vorbelegt, und die Notiz einer geplanten Besprechung nennt keine. Ein Zustimmungssatz zählt weiterhin, der Name darin steht aber nur im Zustimmungsnachweis, und der Satz selbst bleibt aus dem Transkript heraus. Benutzer sehen die Einstellung als Sprecher benennen unter Einstellungen → Assistent → Besprechung; unter enforce ist sie gesperrt.

Anbieter und Werkzeuge einschränken

Lege diese unter enforce fest, damit Benutzer sie nicht lockern können.

Eigenschaft	Typ	Standard	Beschreibung
allowedProviderTypes	string[]	nicht gesetzt (alle erlaubt)	Anbietertypen, die Benutzer verwenden dürfen: "OpenAI", "AzureOpenAI", "Ollama", "OpenRouter", "OpenAICompatible", "Mistral", "VLlm", "Anthropic". Groß- und Kleinschreibung spielt keine Rolle
allowedProviderEndpoints	string[]	nicht gesetzt (alle erlaubt)	Adressen, die Anbieter verwenden dürfen: ein exakter Host oder *.domain für dessen Subdomains
allowProviderWebSearch	bool	true	Die eigene Websuche der Anbieter erlauben
allowLocalMcpServers	bool	true	MCP-Server erlauben, die auf dem Gerät laufen

Lässt du allowedProviderTypes oder allowedProviderEndpoints weg oder setzt sie auf null oder [], ist alles erlaubt. Pia Cloud schränkt keine der beiden ein.

Ein Anbietertyp, der in allowedProviderTypes fehlt, wird im Anbieter-Dialog und im Einrichtungsassistenten nicht angeboten. Einen Anbieter dieses Typs, den ein Benutzer schon hat, kann er nicht speichern, und Pia lehnt jede Anfrage an ihn ab, bevor etwas gesendet wird: Im Chat erscheint eine Meldung, ein Hintergrundlauf endet mit einem Fehler. Als Grund nennt Pia „Die Richtlinie deiner Organisation erlaubt diesen Anbietertyp nicht.“

Ein Eintrag in allowedProviderEndpoints ist ein exakter Host wie llm.corp.example oder ein Muster wie *.example.com, das jede Subdomain von example.com abdeckt, aber nicht example.com selbst. Ein Eintrag in URL-Form zählt mit seinem Host. Eine Adresse, die die Liste nicht abdeckt, lässt sich nicht speichern, und der Dialog sagt „Die Richtlinie deiner Organisation erlaubt diese Adresse nicht.“ Pia ruft dort keine Modelle ab und lehnt Anfragen an diese Adresse ab.

Mit allowProviderWebSearch auf false bleibt die eigene Websuche der Anbieter aus: bei OpenAI, OpenRouter, Anthropic und den Mistral-Agenten. Die Wahl des Benutzers bleibt gespeichert, und Websuche aktivieren ist gesperrt. Pia Cloud ist nicht betroffen, weil die Suche dort auf dem Server läuft.

Mit allowLocalMcpServers auf false ist Server hinzufügen gesperrt, Speichern und Testen eines Servers werden abgelehnt, und laufende lokale Server werden gestoppt. Jeder sagt dann „Die Richtlinie deiner Organisation erlaubt auf diesem Gerät keine lokalen MCP-Server.“ Sind lokale Server wieder erlaubt, startet Pia die eingeschalteten von selbst. MCP-Server, die die Administration als Plugins verteilt, sind nicht betroffen.

Einstellungen, die der Server nicht verwalten kann

Zwei Gruppen von Schlüsseln sind ausgenommen: die erste nur in einer vom Server veröffentlichten Richtlinie, die zweite in beiden Quellen.

Die Verbindungseinstellungen — serverUrl, syncEnabled und trustSelfSignedCertificates. Mit ihnen erreicht Pia den Server überhaupt erst, und weil eine Server-Richtlinie Vorrang vor der Datei auf dem Gerät hat, könnte ein falscher Wert eine ganze Gruppe abschneiden, ohne dass sich das aus der Ferne noch korrigieren ließe. Alle drei lassen sich weiterhin in der policy.json des Geräts festschreiben — so schränkst du ein Gerät ein, bevor es überhaupt einen Server erreicht.

Pias eigene Buchführung — Anmeldedaten, Sync-Marker und ETags, Verschlüsselungszustand, Schema- und Migrationsstände, Fenstergeometrie und Entwurfstexte. Diese Schlüssel ignoriert Pia unabhängig von der Quelle, in der Datei genauso wie vom Server, und protokolliert eine Warnung mit dem Namen des Schlüssels.

Beispiel

{
  "defaults": {
    "uiLanguage": "DE",
    "targetLanguage": "DE",
    "whisperModel": "Small"
  },
  "enforce": {
    "theme": "Dark",
    "serverUrl": "https://pia.corp.example.com",
    "syncEnabled": true
  }
}

In diesem Beispiel ist Deutsch die Startsprache, Benutzer können aber auf Englisch oder Französisch wechseln. Das Design ist auf Dark fixiert, Sync ist verpflichtend, und die Pia-Cloud-URL ist auf den selbst gehosteten Firmen-Server festgelegt. serverUrl und syncEnabled funktionieren nur in einer policy.json auf dem Gerät — eine vom Server veröffentlichte Richtlinie kann sie nicht setzen.

Rollout

1. Lege oder bearbeite policy.json im Installationsverzeichnis von Pia auf jedem verwalteten Gerät an (z. B. über dein Endpoint-Management-System) — oder veröffentliche das Dokument in der Admin-Oberfläche des Pia Servers für eine ganze Gruppe.
2. Validiere das JSON.
3. Lass die Benutzer Pia schließen und erneut öffnen.

Einstellungen unter enforce erscheinen in Pias Einstellungs-UI ausgegraut; Defaults erscheinen normal.