ims integrated into e-compliance

e-compliance/ims/05_betrieb/neutralisierung-detail.md

@@ -0,0 +1,203 @@
+# Neutralisierung
+
+**Stand:** 2026-04-16
+
+---
+
+## 1. Grundidee
+
+Neutralisierung passiert dort, wo **Content entsteht oder ins System einfliesst** — nicht als nachgelagerter Filter vor dem Modell-Call. Wenn Content einmal neutralisiert ist (z. B. im RAG), bleibt er neutralisiert. Kein doppeltes Verarbeiten.
+
+---
+
+## 2. Wer fordert Neutralisierung?
+
+Drei Quellen, von breit nach spezifisch:
+
+| Quelle | Flag im Code | Bedeutung |
+|--------|-------------|-----------|
+| **Feature-Instanz** | `DataNeutraliserConfig.enabled` (hat `featureInstanceId` + `mandateId`) | Alle Daten in dieser Feature-Instanz werden neutralisiert. Betrifft jeden Content-Einstieg innerhalb dieser Instanz. |
+| **Chat-Workflow / Session** | `ServiceCenterContext.requireNeutralization` (gesetzt z. B. vom AI-Workspace oder Automation) | Dieser Workflow/Turn: jeder Content, der hier verarbeitet wird, wird neutralisiert. |
+| **Dokument oder Quelle** | `FileItem.neutralize`, `FileFolder.neutralize`, `DataSource.neutralize`, `FeatureDataSource.neutralize`, `FeatureDataSource.neutralizeFields` | Dieses konkrete Objekt: Content daraus wird neutralisiert, egal ob die Feature-Instanz oder der Workflow es sonst fordern würden. `FileFolder.neutralize` propagiert auf alle enthaltenen Dateien. `neutralizeFields` ermoeglicht Feld-Level-Maskierung bei DB-Queries. |
+
+**Auswertung:** Irgendeine Quelle sagt `True` → neutralisieren. Keine Quelle kann eine andere aufheben. Es gibt kein `False`-Override, das ein `True` von woanders aushebelt.
+
+---
+
+## 3. Wo passiert die Neutralisierung?
+
+Am **Punkt der Content-Einspeisung** — dort wo Rohdaten zu verarbeitbarem Content werden:
+
+| Content-Einstieg | Was passiert | Wer prüft das Flag |
+|------------------|-------------|---------------------|
+| **Datei-Indexierung** (RAG) | Text-Chunks werden über `processText` neutralisiert, bevor sie ins Embedding gehen. Medien: nur internes Modell oder nicht indexieren. Ergebnis: RAG enthält nur neutralisierten Content. | `mainServiceKnowledge.indexFile` liest `FileItem.neutralize` |
+| **Content-Extraktion** (Dokumente für KI-Verarbeitung) | Extrahierter Text/Tabellen werden neutralisiert. PDF, DOCX, XLSX, PPTX über `processFile` (Extract → neutralisieren → zurückschreiben). | Caller kennt die Quelle und deren Flag |
+| **User-Prompt** (Chat-Eingabe) | Prompt-Text wird durch `processText` neutralisiert, wenn Feature-Instanz oder Workflow es fordern. | `mainServiceAi` prüft Context-Flag / Config |
+| **DataSource-Download** | Flag wird auf erstellte `FileItem`s vererbt → bei Extraktion/Indexierung greift das File-Flag automatisch. | `mainServiceAgent._resolveDataSource` / `_downloadFromDataSource` |
+| **FeatureDataSource-Abfrage (Tabelle)** | Wenn eine `FeatureDataSource.neutralize=True` hat → Content aus diesem Sub-Agent-Call wird neutralisiert. | `mainServiceAgent._queryFeatureInstance` setzt `requireNeutralization=True` |
+| **FeatureDataSource-Abfrage (Feld/Typ, seit 2026-06)** | Typ- und vererbungsbewusst: **Strings** werden substring-neutralisiert sobald effektiv (explizit ODER geerbt, Feldname als Typ-Hint); **Binary** wird gedroppt; **andere Skalare** (number/date/bool) nur bei **explizitem** Feld-Flag als Ganzwert-Platzhalter `[NEUT.<field>.<hash>]`. Identifikatoren/System-Spalten ausgenommen, Engine-Ausfall = `[REDACTED]`. RAG-Bootstrap nutzt dieselbe Policy (Query- und Index-Pfad konsistent). | `featureDataProvider.finalizeRowsAsync` / `_neutralizeAndSerializeRows`; Policy aus `coreTools/_featureSubAgentTools` via `resolveEffectiveForFds` |
+| **De-Neutralisierung für Download (seit 2026-06)** | Read-only Agent-Tool `revealDocument` löst Platzhalter **nur** über das lokale Mapping (`resolveText`, kein externes LLM) auf und liefert Klartext als transienten Einmal-Download (SSE `revealDownload`) — kein Save/Index/Historie. | `coreTools/_mediaTools._revealDocument` |
+| **Ordner-Neutralisierung** | `FileFolder.neutralize=True` propagiert auf alle enthaltenen Dateien (rekursiv). Neue/verschobene Dateien erben das Flag. Index-Purge + Re-Index wie bei einzelnen Dateien. | `routeDataFiles.updateFolderNeutralize` |
+| **Workflow-Aktion `neutralizeData`** | Expliziter Neutralisierungs-Schritt auf bereits extrahierten ContentParts. | Workflow-Config + `NeutralizationConfig.enabled` |
+
+**Was NICHT nochmal neutralisiert werden muss:**
+- RAG-Chunks, die bereits neutralisiert indexiert sind — die sind schon sauber.
+- Web-Suchergebnisse — enthalten keine Mandantendaten, brauchen keine Neutralisierung.
+
+**Flag-Änderung:** Ändert sich `FileItem.neutralize` (Toggle) → Index löschen → Re-Indexierung triggern → neuer Index ist im richtigen Zustand.
+
+---
+
+## 4. Engine: `NeutralizationService`
+
+Eine Engine, drei Einstiege, aufgerufen an den Content-Einstiegspunkten aus Abschnitt 3.
+
+| API | Eingabe | Status |
+|-----|---------|--------|
+| `processText(text)` | Rohtext (Prompt, Message, Text-ContentPart, Text-Chunk) | **Ist** |
+| `processFile(fileId)` | Datei aus DB — wird nach MIME geroutet | **Ist** |
+| `processBinaryBytes` / `Async` | Bytes + Dateiname + MIME | **Ist** |
+| **`processImage(imageBytes, fileName)`** / `processImageAsync` | Bild-Datei oder Bild-ContentPart (image/png, image/jpeg, …) | **Ist** (seit ~2026 Q1) |
+
+**Ist-Zustand Bilder (aktualisiert 2026-04-05):** `processImageAsync` ist implementiert und nutzt `NEUTRALIZATION_IMAGE` (Private LLM Vision). `_processBinaryFile` verarbeitet jetzt Bild-Parts ueber `processImageAsync`. **Einschraenkung:** Eigenstaendige Bild-Dateien (`image/*` MIME direkt an `processFile`) werden in `_isBinaryMimeType` weiterhin als Skip behandelt.
+
+**Ist (aktualisiert):** `processImageAsync` existiert als Einstieg. Ruft internes Vision-Modell (`NEUTRALIZATION_IMAGE` → Private-LLM) auf, um sensible Inhalte in Bildern zu erkennen/entfernen. Kein externer Provider. Modell nicht verfügbar → Bild blockieren (nicht unbehandelt weiterreichen).
+
+**Ablauf nach MIME:**
+
+| MIME | Pfad |
+|------|------|
+| PDF, DOCX, XLSX, PPTX | `runExtraction` → Text/Table-Parts durch `_neutralizeText`, Bild-Parts durch `processImage` → PDF in-place oder Office-Renderer |
+| Text, JSON, CSV, XML | `_neutralizeText` direkt (TextProcessor, ListProcessor, BinaryProcessor je nach Inhalt) |
+| Bilder (image/*) | **`processImage`** → internes Vision-Modell (`NEUTRALIZATION_IMAGE`). Nicht verfügbar → blockieren. |
+| Video, Audio | Nur internes Modell oder blockieren (analog Bilder, aber niedrigere Priorität) |
+| Anderes Binary | Skip (nicht unterstützt) |
+
+**Mapping:** Platzhalter `[typ.uuid]` → Attribute in DB. `resolveText(text)` für Rückübersetzung.
+
+---
+
+## 5. Modellauswahl
+
+| Operation Type | Modelle | Zweck |
+|----------------|---------|-------|
+| `NEUTRALIZATION_TEXT` | `poweron-text-general` (Rating 9) | Falls Engine ein LLM für Text braucht |
+| `NEUTRALIZATION_IMAGE` | `poweron-vision-general` (9), `poweron-vision-deep` (9) | Medien bei Neutralisierungspflicht: nur intern |
+
+Registriert in `aicorePluginPrivateLlm.py`. Externe Provider haben keine `NEUTRALIZATION_*`-Ratings → werden nie für Neutralisierung gewählt.
+
+---
+
+## 6. Fail-safe
+
+| Situation | Verhalten |
+|-----------|-----------|
+| Neutralisierung gefordert, Engine nicht verfügbar | Content **nicht** weiterverarbeiten (blockieren) |
+| Neutralisierung eines Teils schlägt fehl | Teil entfernen, nicht im Rohzustand weiterleiten |
+| Kein internes Modell für Medien verfügbar | Medien-Part entfernen |
+
+---
+
+## 7. Code-Karte
+
+| Bereich | Pfad |
+|---------|------|
+| Engine | `features/neutralization/serviceNeutralization/mainServiceNeutralization.py` + `subProcess*.py` |
+| Config + Attribute DB | `features/neutralization/datamodelFeatureNeutralizer.py`, `interfaceFeatureNeutralizer.py` |
+| Index (Data-at-rest) | `serviceCenter/services/serviceKnowledge/mainServiceKnowledge.py` |
+| Prompt-Neutralisierung | `serviceCenter/services/serviceAi/mainServiceAi.py` (`_shouldNeutralize`, `_neutralizeRequest`) |
+| Agent / DataSource / Feature | `serviceCenter/services/serviceAgent/mainServiceAgent.py` |
+| Workflow-Aktion | `workflows/methods/methodContext/actions/neutralizeData.py` |
+| Modelle / Enums | `datamodels/datamodelAi.py`, `aicore/aicorePluginPrivateLlm.py` |
+| Flags | `datamodelFiles.py` (`FileItem.neutralize`), `datamodelDataSource.py`, `datamodelFeatureDataSource.py` |
+| Context | `serviceCenter/context.py` (`ServiceCenterContext.requireNeutralization`) |
+
+---
+
+## 8. Umsetzungsplan
+
+### Schritt 1: `processImage` in Engine bauen
+
+**Datei:** `mainServiceNeutralization.py`  
+**Was:** Neue Methode `processImage(imageBytes: bytes, fileName: str, mimeType: str) -> Dict` und `processImageAsync`.  
+**Wie:** Internes Vision-Modell aufrufen (`NEUTRALIZATION_IMAGE` via Model Selector / `aiObjects`). Prompt: sensible Inhalte im Bild erkennen und beschreiben, damit Caller entscheiden kann ob Bild blockiert wird. Kein internes Modell verfügbar → `{'status': 'blocked'}` zurückgeben.  
+**Abhängigkeit:** `OperationTypeEnum.NEUTRALIZATION_IMAGE` + Modell-Ratings in `aicorePluginPrivateLlm.py` — **bereits erledigt**.
+
+### Schritt 2: `_shouldNeutralize` vereinfachen
+
+**Datei:** `mainServiceAi.py` (Zeile ~560)  
+**Ist:** Prüft `request.requireNeutralization` → `context.requireNeutralization` → `NeutralizationConfig.enabled` (Mandant-Level Config). `request.requireNeutralization=False` bricht sofort ab.  
+**Soll:** Drei Quellen gemäss Abschnitt 2, kein `False`-Override:
+1. Feature-Instanz: `NeutralizationConfig.enabled` (hat `featureInstanceId`)
+2. Workflow/Session: `context.requireNeutralization`
+3. Request: `request.requireNeutralization`
+
+Irgendein `True` → neutralisieren. `False` in einer Quelle hebt `True` in einer anderen **nicht** auf.  
+**Änderung:** `if request.requireNeutralization is False: return False` **entfernen**. Stattdessen OR-Verknüpfung aller drei Quellen.
+
+### Schritt 3: `_neutralizeRequest` auf Prompt/Messages beschränken
+
+**Datei:** `mainServiceAi.py` (Zeile ~592)  
+**Ist:** Neutralisiert `prompt`, `context`, `messages` (String-Content).  
+**Soll:** Zusätzlich Text in `contentParts` und Text-Teile in multimodalen Messages (content-Liste mit `type==text`). Bild-Teile in Messages: bei Neutralisierungspflicht über `processImage` prüfen oder entfernen.  
+**Wichtig:** Hier geht es nur um Prompt-/Sessiondaten. File-Content aus RAG ist bereits neutralisiert (Schritt 5), muss hier nicht nochmal durch.
+
+### Schritt 4: `indexFile` — Bild-Chunks behandeln
+
+**Datei:** `mainServiceKnowledge.py` (Zeile ~146 ff.)  
+**Ist:** Nur `textObjects` (contentType == "text") werden bei `_shouldNeutralize` durch `processText` geschickt. Bild-Chunks (`contentType == "image"`) werden unverändert indexiert.  
+**Soll:** Bild-Chunks bei `_shouldNeutralize` über `processImage` (Schritt 1) prüfen. Ergebnis `blocked` → Bild-Chunk nicht indexieren. Ergebnis OK → Bild-Chunk indexieren (internes Modell hat es gesehen, kein externer Provider nötig).  
+**Abhängigkeit:** Schritt 1.
+
+### Schritt 5: Agent-Tool `readFile` — Content bei Extraktion neutralisieren
+
+**Datei:** `mainServiceAgent.py`, Tool `_readFile` (Zeile ~540 ff.)  
+**Ist:** Liest aus Knowledge Store (bereits indexiert) oder extrahiert on-demand. Kein Neutralisierungs-Check.  
+**Soll:**
+- **Knowledge Store Pfad (Zeile ~548):** RAG-Chunks sind bereits neutralisiert wenn `FileItem.neutralize=True` war (Schritt 4) → nichts zu tun.
+- **On-Demand Extraktion (Zeile ~630 ff.):** Nach `runExtraction` und vor Rückgabe der Text-Objekte: `FileItem.neutralize` laden. Wenn `True` → Text-Objekte durch `processText`, Bild-Objekte durch `processImage`.
+
+### Schritt 6: Agent-Tool `summarizeContent` — File-Flag prüfen
+
+**Datei:** `mainServiceAgent.py`, Tool `_summarizeContent` (Zeile ~1921 ff.)  
+**Ist:** Liest Content-Objects aus Knowledge Store, baut `combinedText` und ruft `callAi` auf. Kein Neutralisierungs-Check.  
+**Soll:** Content aus Knowledge Store ist bereits neutralisiert (Schritt 4) → nichts zu tun, **sofern** File indexiert war. Wenn nicht indexiert: File-Flag prüfen, Text vor `callAi` durch `processText`.  
+**Hinweis:** Durch Schritt 4 ist der Regelfall abgedeckt.
+
+### Schritt 7: Agent-Tool `describeImage` — File-Flag prüfen
+
+**Datei:** `mainServiceAgent.py`, Tool `_describeImage` (Zeile ~2015 ff.)  
+**Ist:** Lädt Bild-Chunk oder Rohdaten, sendet per `callAi` mit `IMAGE_ANALYSE` an **beliebigen** Provider (inkl. extern). Kein Neutralisierungs-Check.  
+**Soll:** `FileItem.neutralize` laden (fileId ist bekannt). Wenn `True`:
+- `operationType` auf `NEUTRALIZATION_IMAGE` statt `IMAGE_ANALYSE` → Model Selector wählt nur internes Modell.
+- Kein internes Modell → Tool gibt Fehler zurück statt Bild an externen Provider zu senden.
+
+### Schritt 8: `_processBinaryFile` — Bild-Parts nicht mehr überspringen
+
+**Datei:** `mainServiceNeutralization.py` (Zeile ~298)  
+**Ist:** `if type_group in ('binary', 'image'): neutralized_parts.append(part); continue` — Bild-Parts werden übersprungen.  
+**Soll:** `binary` weiterhin skip. `image` → durch `processImage` (Schritt 1). Ergebnis `blocked` → Part entfernen. Ergebnis OK → Part behalten.  
+**Abhängigkeit:** Schritt 1.
+
+### Schritt 9: Workflow-Aktion `neutralizeData` — Bild-Parts
+
+**Datei:** `neutralizeData.py` (Zeile ~130 ff.)  
+**Ist:** Iteriert über ContentParts, neutralisiert nur Parts mit `part.data` (Text). `typeGroup != text/table` → unverändert durchgereicht.  
+**Soll:** Bild-Parts durch `processImage`. Ergebnis `blocked` → Part entfernen.  
+**Abhängigkeit:** Schritt 1.
+
+### Schritt 10: Tests
+
+| Test | Was |
+|------|-----|
+| T1 | `FileItem.neutralize=True` → `indexFile` → Text-Chunks neutralisiert, Bild-Chunks geprüft/blockiert |
+| T2 | `readFile` on-demand auf File mit `neutralize=True` → Text neutralisiert |
+| T3 | `describeImage` auf File mit `neutralize=True` → nur internes Modell |
+| T4 | Feature-Instanz Config `enabled=True` → Prompt in `callAi` neutralisiert |
+| T5 | Workflow `requireNeutralization=True` → Prompt neutralisiert |
+| T6 | `processFile` auf PDF mit Bildern → Text neutralisiert, Bild-Parts durch `processImage` |
+| T7 | Flag-Toggle → Index gelöscht → Re-Index im richtigen Zustand |
+
+### Schritt 11: Logging
+
+**Alle Stellen (Schritte 2–9):** Bei Neutralisierung loggen: welche Quelle (Feature-Instanz / Workflow / File-Flag), welche `fileId` falls vorhanden, Ergebnis (OK / Part entfernt / blockiert). **Kein Klartext** in Logs.

e-compliance/ims/05_betrieb/security-overview.md

@@ -0,0 +1,369 @@
+# PowerOn Plattform -- Sicherheit und Compliance
+
+**Stand:** Februar 2026
+**Zielgruppe:** Entscheidungsträger, Einkauf, Rechtsabteilung, Datenschutzbeauftragte
+**Klassifizierung:** Kundeninformation
+
+---
+
+## 1. Management Summary
+
+PowerOn ist eine **Multi-Mandanten-KI-Plattform für Unternehmen**, die es Organisationen ermöglicht, KI-gestützte Geschäftsprozesse sicher, datenschutzkonform und mandantengetrennt zu betreiben. Die Plattform richtet sich an mittlere bis grosse Unternehmen in datenschutzsensiblen Branchen wie Finanzwesen, Treuhand, Immobilien und Beratung.
+
+Dieses Dokument beschreibt die in PowerOn implementierten Sicherheits- und Datenschutzmassnahmen, ordnet diese gängigen Standards zu und benennt transparent bestehende Einschränkungen.
+
+**Kernaussagen:**
+
+- **DSGVO-Betroffenenrechte** (Auskunft, Löschung, Datenübertragbarkeit, Berichtigung) sind als Self-Service-Funktionen direkt in der Plattform implementiert.
+- **Vollständige Mandantentrennung:** Daten eines Mandanten sind unter keinen Umständen für andere Mandanten einsehbar oder zugänglich.
+- **Rollenbasierte Zugriffskontrolle (RBAC):** Jeder Datenzugriff wird gegen ein mehrstufiges Berechtigungssystem geprüft -- konfigurierbar pro Mandant und Funktionsmodul.
+- **Verschlüsselung:** Sensible Konfigurationsdaten sind nach Industriestandard verschlüsselt, sämtliche Kommunikation erfolgt über verschlüsselte Verbindungen.
+- **Audit-Trail:** Alle sicherheitsrelevanten Aktionen werden lückenlos protokolliert und stehen für Compliance-Nachweise zur Verfügung.
+- **Transparenz bei KI-Nutzung:** Die Plattform dokumentiert offen, welche Daten an KI-Dienste übermittelt werden, und bietet Konfigurationsoptionen für höchste Datenschutzanforderungen.
+
+---
+
+## 2. DSGVO-Konformität
+
+PowerOn implementiert die zentralen Betroffenenrechte der Datenschutz-Grundverordnung (DSGVO/GDPR) direkt als Plattformfunktionen. Im Folgenden wird für jeden relevanten Artikel beschrieben, was implementiert ist und wo Einschränkungen bestehen.
+
+### 2.1 Auskunftsrecht (Art. 15 DSGVO)
+
+Nutzer können über eine Self-Service-Funktion sämtliche über sie gespeicherten Daten exportieren:
+
+- Persönliche Profildaten (Name, E-Mail, Spracheinstellungen)
+- Mandatszugehörigkeiten und zugewiesene Rollen
+- Zugriffsrechte auf Funktionsmodule
+- Erstellte und eingelöste Einladungen
+- Zeitpunkte der Kontoerstellung und letzten Anmeldung
+
+Der Export umfasst alle auf Plattformebene gespeicherten Daten. Feature-spezifische Daten (z.B. Chat-Verläufe, Treuhandpositionen) können über die jeweiligen Funktionsmodule eingesehen werden.
+
+**Status: Implementiert.**
+
+### 2.2 Recht auf Löschung (Art. 17 DSGVO)
+
+Nutzer können ihr Konto und alle zugehörigen Daten eigenständig und unwiderruflich löschen. Dabei gilt:
+
+- Das System durchsucht automatisch alle Datenbanken (Plattform, Verwaltung, Chat, alle Funktionsmodule) nach Einträgen, die dem Nutzer zugeordnet sind.
+- Nutzerbezogene Daten werden vollständig gelöscht.
+- Audit-Logs werden anonymisiert statt gelöscht -- dies gewährleistet die Einhaltung gesetzlicher Aufbewahrungspflichten bei gleichzeitiger Wahrung der Betroffenenrechte.
+- Die Löschung erfordert eine explizite Bestätigung durch den Nutzer.
+- Systemadministratoren sind von der Selbstlöschung ausgenommen (Vier-Augen-Prinzip).
+
+**Status: Implementiert.**
+
+### 2.3 Recht auf Datenübertragbarkeit (Art. 20 DSGVO)
+
+Nutzerdaten können in einem maschinenlesbaren, standardisierten Format (JSON-LD nach schema.org) exportiert werden. Dieses Format ermöglicht die Übertragung der Daten an einen anderen Dienstleister.
+
+**Status: Implementiert.**
+
+### 2.4 Berichtigungsrecht (Art. 16 DSGVO)
+
+Nutzer können ihre Profildaten (Name, E-Mail, Spracheinstellungen) jederzeit selbst korrigieren.
+
+**Status: Implementiert.**
+
+### 2.5 Transparenz und Informationspflicht
+
+Die Plattform stellt Nutzern aktiv Informationen über die Datenverarbeitung bereit:
+
+- Welche Daten erhoben werden
+- Zu welchem Zweck die Verarbeitung erfolgt
+- Auf welcher Rechtsgrundlage die Verarbeitung basiert
+- Welche Aufbewahrungsfristen gelten
+- Welche Betroffenenrechte bestehen und wie sie ausgeübt werden können
+
+**Status: Implementiert.**
+
+### 2.6 Bekannte Einschränkungen
+
+Die folgenden Punkte sind transparent zu benennen:
+
+- **Consent-Management:** Die Plattform verfügt derzeit über kein granulares Einwilligungsmanagement mit individuellen Zustimmungs-Toggles. Die Einwilligung zur Datenverarbeitung erfolgt über die Nutzungsbedingungen und, bei Drittanbieter-Authentifizierung (Microsoft, Google), über die jeweiligen OAuth-Einwilligungsflüsse.
+- **Datenschutz-Kontaktadresse:** Die Kontaktadresse für Datenschutzanfragen ist pro Deployment konfigurierbar und muss vom jeweiligen Betreiber hinterlegt werden.
+
+---
+
+## 3. Mandantenmodell und Datenisolation
+
+### 3.1 Grundprinzip
+
+PowerOn ist als Multi-Mandanten-Plattform konzipiert. Jede Organisation, Abteilung oder jeder Kunde wird als eigenständiger **Mandant** abgebildet. Das zentrale Sicherheitsversprechen:
+
+> **Daten eines Mandanten sind unter keinen Umständen für Nutzer anderer Mandanten sichtbar oder zugänglich.**
+
+### 3.2 Wie die Trennung funktioniert
+
+- **Zugehörigkeitsprüfung bei jedem Zugriff:** Bevor ein Nutzer auf Mandantendaten zugreifen kann, prüft die Plattform, ob eine aktive Mitgliedschaft des Nutzers in diesem Mandanten besteht. Ohne nachgewiesene Mitgliedschaft wird der Zugriff verweigert.
+- **Kein mandantenübergreifender Datenfluss:** Datenbankabfragen werden automatisch auf den Mandantenkontext gefiltert. Es gibt keinen Mechanismus, der Daten mandantenübergreifend zusammenführt oder exponiert.
+- **Feature-Isolation:** Innerhalb eines Mandanten werden Funktionsmodule (z.B. CommCoach, Treuhand, Immobilien) zusätzlich isoliert. Nutzer benötigen für jedes Funktionsmodul eine explizite Zugriffsberechtigung.
+
+### 3.3 Mehrfachmandanten
+
+Nutzer können gleichzeitig in mehreren Mandanten arbeiten -- ein häufiges Szenario bei Beratern, Treuhändern oder Dienstleistern mit mehreren Kunden. Die Plattform stellt sicher:
+
+- Der Mandantenkontext wird pro Anfrage bestimmt, nicht pro Sitzung. Ein Wechsel zwischen Mandanten ist jederzeit möglich, ohne dass Daten vermischt werden.
+- Es findet keine Übertragung von Daten, Berechtigungen oder Einstellungen zwischen Mandanten statt.
+
+### 3.4 Schutz vor Manipulation
+
+Auch bei technischem Wissen über die Plattformarchitektur ist ein unbefugter Zugriff auf fremde Mandantendaten nicht möglich: Die Zugehörigkeitsprüfung erfolgt serverseitig und kann nicht durch Manipulation von Anfrageparametern umgangen werden.
+
+---
+
+## 4. Rollenbasierte Zugriffskontrolle (RBAC)
+
+### 4.1 Berechtigungsmodell
+
+PowerOn verfügt über ein feingliedriges, rollenbasiertes Berechtigungssystem. Für jede Aktion (Lesen, Erstellen, Bearbeiten, Löschen) können individuelle Berechtigungsstufen vergeben werden:
+
+| Berechtigungsstufe | Beschreibung |
+|---|---|
+| Kein Zugriff | Funktion ist nicht verfügbar |
+| Eigene Daten | Zugriff nur auf selbst erstellte Einträge |
+| Mandantendaten | Zugriff auf alle Daten innerhalb des eigenen Mandanten |
+| Alle Daten | Vollzugriff (typischerweise für Administratoren) |
+
+### 4.2 Konfigurierbarkeit
+
+- Rollen können **pro Mandant** und **pro Funktionsmodul** definiert und zugewiesen werden.
+- Es gibt keine fest verdrahteten Berechtigungen -- jede Organisation kann das Rollenmodell an ihre Bedürfnisse anpassen.
+- Berechtigungsänderungen werden im Audit-Trail protokolliert.
+
+### 4.3 Administratoren
+
+Systemadministratoren verfügen über erweiterte Rechte, unterliegen jedoch ebenfalls dem RBAC-System. Alle Administratoraktionen werden gesondert im Audit-Log festgehalten. Es gibt kein unkontrolliertes "Superuser"-Konto ohne Nachvollziehbarkeit.
+
+---
+
+## 5. Verschlüsselung und Datensicherheit
+
+### 5.1 Verschlüsselung ruhender Daten
+
+Alle sensiblen Konfigurationsdaten werden verschlüsselt gespeichert:
+
+- **Verschlüsselungsverfahren:** AES-Verschlüsselung (Fernet)
+- **Schlüsselableitung:** PBKDF2-HMAC-SHA256 nach aktuellem Industriestandard
+- **Umfang:** Datenbankpasswörter, API-Schlüssel für KI-Dienste, OAuth-Geheimnisse, JWT-Schlüssel und alle weiteren als "SECRET" gekennzeichneten Konfigurationswerte
+
+Sensible Konfigurationsdaten liegen zu keinem Zeitpunkt im Klartext in der Konfiguration oder im Quellcode vor.
+
+### 5.2 Verschlüsselung in Übertragung
+
+- Sämtliche Kommunikation zwischen Client und Server erfolgt über HTTPS/TLS.
+- Verbindungen zu Drittdiensten (KI-Anbieter, Authentifizierungsdienste, E-Mail-Dienste) nutzen ebenfalls ausschliesslich verschlüsselte Verbindungen.
+- Die TLS-Konfiguration erfolgt auf Infrastruktur-Ebene (Azure / Reverse Proxy) -- dies entspricht dem Branchenstandard bei Cloud-Deployments und ermöglicht zentrale Verwaltung und Aktualisierung der Zertifikate.
+
+### 5.3 Zugriffskontrolle auf Verschlüsselungsschlüssel
+
+- Der Zugriff auf Verschlüsselungsschlüssel ist auf das Minimum beschränkt.
+- Jeder Zugriff auf Verschlüsselungsfunktionen (Entschlüsselung, Neuverschlüsselung) wird im Audit-Trail protokolliert.
+- Eine Ratenbegrenzung schützt vor automatisierten Entschlüsselungsversuchen.
+
+---
+
+## 6. Schutzmassnahmen gegen Angriffe
+
+PowerOn implementiert Schutzmassnahmen gegen die gängigsten Angriffsvektoren für Webanwendungen:
+
+### 6.1 Cross-Site Request Forgery (CSRF)
+
+Alle datenverändernden Operationen (POST, PUT, DELETE, PATCH) erfordern einen `X-CSRF-Token` Header. Die aktuelle Implementierung validiert das Tokenformat (16-64 Zeichen Hex-String); es gibt kein serverseitiges Session-Binding (kein klassisches Double-Submit oder Synchronizer Token). In Kombination mit `SameSite=Strict` Cookies und CORS bietet dies Basisschutz gegen CSRF.
+
+### 6.2 Ratenbegrenzung (Rate Limiting)
+
+Jede API-Funktion ist mit individuellen Zugriffslimits versehen, die automatisierte Angriffe und Missbrauch unterbinden:
+
+| Funktion | Limit |
+|---|---|
+| Anmeldung | 30 Versuche pro Minute |
+| Datenexport (DSGVO) | 5 Anfragen pro Minute |
+| Kontolöschung | 1 Anfrage pro Stunde |
+| KI-Anfragen | 120 Anfragen pro Minute |
+| Datei-Upload | 10 Uploads pro Minute |
+
+### 6.3 Eingabebereinigung
+
+Nutzereingaben werden bereinigt und validiert, bevor sie an KI-Modelle oder Datenbanken weitergeleitet werden. Dies schützt vor Prompt-Injection-Angriffen und anderen Manipulationsversuchen.
+
+### 6.4 SQL-Injection-Schutz
+
+- Alle Datenbankabfragen der Plattform verwenden parametrisierte Abfragen -- der Industriestandard zur Vermeidung von SQL-Injection.
+- Der KI-gestützte Datenbankzugriff ist zusätzlich auf reine Leseabfragen (SELECT) beschränkt. Schreibende, ändernde oder löschende Operationen sind auf Systemebene blockiert.
+
+### 6.5 Cross-Origin Resource Sharing (CORS)
+
+Nur definierte und verifizierte Quelldomains erhalten Zugriff auf die Plattform-API. Anfragen von nicht autorisierten Quellen werden automatisch abgelehnt.
+
+---
+
+## 7. KI-Dienste und Datenverarbeitung
+
+Transparenz im Umgang mit KI-Diensten ist für datenschutzbewusste Organisationen entscheidend. PowerOn legt offen, wie Daten im Kontext der KI-Nutzung verarbeitet werden.
+
+### 7.1 Welche Daten werden verarbeitet
+
+Im Rahmen der KI-gestützten Funktionen (KI-Assistent, Workflow-Verarbeitung, Dokumentenanalyse) können folgende Daten an KI-Dienste übermittelt werden:
+
+- Nutzeranfragen und -eingaben
+- Dokumentinhalte (bei Dokumentenanalyse)
+- Gesprächsverläufe (bei Chat-Funktionen)
+
+### 7.2 Welche KI-Anbieter werden genutzt
+
+PowerOn unterstützt mehrere KI-Anbieter, die je nach Bedarf und Konfiguration eingesetzt werden:
+
+- **OpenAI** (GPT-4o und weitere Modelle)
+- **Anthropic** (Claude-Modelle)
+- **Tavily** (Websuche)
+- **Private LLM** (lokale/eigene Modelle -- kein externer Datenabfluss)
+
+Die Auswahl des Anbieters ist konfigurierbar und kann an die Datenschutzanforderungen des Kunden angepasst werden.
+
+### 7.3 Mandantentrennung bei KI-Anfragen
+
+Jede KI-Anfrage erfolgt im Kontext des jeweiligen Mandanten. Es findet keine Vermischung von Daten verschiedener Mandanten in KI-Anfragen statt.
+
+### 7.4 Kein Training mit Kundendaten
+
+Bei Nutzung der Enterprise-API-Vereinbarungen der KI-Anbieter (OpenAI Enterprise API, Anthropic API) werden Kundendaten nicht für das Training der KI-Modelle verwendet. Dies ist vertraglich durch die Auftragsverarbeitungsvereinbarungen (AV-V / DPA) mit den jeweiligen Anbietern abgesichert.
+
+### 7.5 Optionen für höchste Datenschutzanforderungen
+
+Für Organisationen mit besonders hohen Datenschutzanforderungen bietet PowerOn:
+
+- **Datenschutz-Neutralisierer:** Optionales Modul, das personenbezogene Daten vor der Übermittlung an externe KI-Dienste entfernt oder pseudonymisiert.
+- **Private-LLM-Anbindung:** Möglichkeit, ein eigenes, lokal betriebenes Sprachmodell zu nutzen. In diesem Fall verlassen keine Daten die eigene Infrastruktur.
+
+### 7.6 Bekannte Einschränkung
+
+Die automatische Erkennung und Filterung personenbezogener Daten (PII) vor dem Versand an externe KI-Dienste ist **nicht standardmässig aktiviert**. Organisationen, die mit besonders sensiblen personenbezogenen Daten arbeiten, sollten den Datenschutz-Neutralisierer nutzen oder den Private-LLM-Connector einsetzen.
+
+---
+
+## 8. Audit-Trail und Nachvollziehbarkeit
+
+### 8.1 Was wird protokolliert
+
+Sämtliche sicherheitsrelevanten Aktionen werden automatisch und lückenlos in einem Audit-Log erfasst:
+
+| Kategorie | Beispiele |
+|---|---|
+| Zugriff | Anmeldungen, fehlgeschlagene Anmeldeversuche, Abmeldungen |
+| Sicherheit | Administratoraktionen, SysAdmin-Zugriffe, Sicherheitsereignisse |
+| Datenschutz (DSGVO) | Datenexporte, Kontolöschungen, Portabilitätsanfragen |
+| Berechtigungen | Rollenzuweisungen, Berechtigungsänderungen |
+| Verschlüsselung | Zugriffe auf Verschlüsselungsfunktionen |
+| Datenoperationen | Zugriffe auf sensible Geschäftsdaten |
+
+### 8.2 Aufbewahrung und Bereinigung
+
+- **Standard-Aufbewahrungsdauer:** 365 Tage (konfigurierbar)
+- **Automatische Bereinigung:** Veraltete Einträge werden durch einen täglichen Prozess entfernt -- dies stellt sicher, dass Audit-Daten nicht unbefristet aufbewahrt werden (DSGVO-Konformität).
+- **Anonymisierung:** Bei der Löschung eines Nutzerkontos werden zugehörige Audit-Einträge anonymisiert statt gelöscht. Die Nachvollziehbarkeit sicherheitsrelevanter Ereignisse bleibt gewahrt, ohne dass Rückschlüsse auf die gelöschte Person möglich sind.
+
+### 8.3 Nutzung für Compliance-Nachweise
+
+Die Audit-Daten können als Nachweis für interne und externe Audits herangezogen werden. Sie dokumentieren, wer wann welche sicherheitsrelevante Aktion durchgeführt hat, und unterstützen damit die Anforderungen an die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO.
+
+---
+
+## 9. Einordnung in gängige Standards
+
+PowerOn orientiert sich an anerkannten Standards und Rahmenwerken. Die folgende Einordnung beschreibt transparent, welche Anforderungen die Plattform bereits abdeckt und wo Ergänzungen erforderlich sind.
+
+### 9.1 DSGVO / GDPR
+
+| Anforderung | Status | Bemerkung |
+|---|---|---|
+| Betroffenenrechte (Art. 15--17, 20) | Implementiert | Auskunft, Löschung, Portabilität, Berichtigung als Self-Service |
+| Rechenschaftspflicht (Art. 5 Abs. 2) | Implementiert | Lückenloser Audit-Trail |
+| Verzeichnis der Verarbeitungstätigkeiten (Art. 30) | Unterstützt | Audit-Log liefert die Datenbasis; das formale Verzeichnis muss vom Betreiber geführt werden |
+| Technische und organisatorische Massnahmen (Art. 32) | Implementiert | Verschlüsselung, Zugriffskontrolle, Mandantentrennung, Eingabevalidierung |
+| Einwilligungsmanagement (Art. 7) | Teilweise | Über Nutzungsbedingungen und OAuth; kein granulares Consent-Tool |
+
+### 9.2 Schweizer Datenschutzgesetz (nDSG / revDSG)
+
+Die Anforderungen des revidierten Schweizer Datenschutzgesetzes sind mit den DSGVO-Massnahmen kompatibel. Insbesondere:
+
+- Informationspflicht bei Datenerhebung: Transparenzfunktion implementiert
+- Recht auf Datenherausgabe und -löschung: Self-Service-Funktionen vorhanden
+- Pflicht zu angemessenen technischen Massnahmen: Verschlüsselung, RBAC, Mandantentrennung
+
+### 9.3 OWASP Top 10
+
+Die Plattform adressiert die häufigsten Web-Sicherheitsrisiken gemäss OWASP:
+
+| OWASP-Risiko | Massnahme in PowerOn |
+|---|---|
+| Broken Access Control | Rollenbasierte Zugriffskontrolle, Mandantenprüfung bei jedem Zugriff |
+| Cryptographic Failures | AES-Verschlüsselung, PBKDF2-Schlüsselableitung, HTTPS/TLS |
+| Injection | Parametrisierte Datenbankabfragen, Eingabebereinigung, SQL-Leseeinschränkung |
+| Security Misconfiguration | CORS-Einschränkungen, Rate Limiting, CSRF-Schutz |
+| Identification and Authentication Failures | JWT-basierte Authentifizierung, Token-Widerruf, Ratenbegrenzung bei Anmeldung |
+
+Es besteht **keine formale OWASP-Zertifizierung**. Die Massnahmen basieren auf den OWASP-Empfehlungen und sind als präventive Sicherheitsmassnahmen implementiert.
+
+### 9.4 ISO 27001 / BSI IT-Grundschutz
+
+Die implementierten technischen und organisatorischen Massnahmen (Zugriffskontrolle, Verschlüsselung, Audit-Logging, Eingabevalidierung, Mandantentrennung) bilden eine **solide Grundlage** für ein Informationssicherheits-Managementsystem (ISMS) nach ISO 27001 oder BSI IT-Grundschutz.
+
+Es besteht **keine formale Zertifizierung**. Die vorhandene Infrastruktur ermöglicht es jedoch, eine Zertifizierung auf dieser Basis gezielt anzustreben.
+
+---
+
+## 10. Authentifizierung und Identitätsmanagement
+
+### 10.1 Anmeldemethoden
+
+PowerOn unterstützt mehrere Authentifizierungsverfahren:
+
+- **Lokale Anmeldung:** Benutzername und Passwort mit JWT-basierter Sitzungsverwaltung
+- **Microsoft-Anmeldung (Azure AD / Entra ID):** Single Sign-On über bestehende Microsoft-Konten
+- **Google-Anmeldung:** Single Sign-On über Google Workspace
+
+### 10.2 Sitzungssicherheit
+
+- Authentifizierungstoken werden in sicheren, HTTP-only Cookies gespeichert (nicht im Browser-Speicher zugänglich)
+- Tokens haben eine konfigurierbare Gültigkeitsdauer
+- Token-Widerruf ist jederzeit möglich (z.B. bei Verdacht auf Kompromittierung)
+- Bei lokaler Anmeldung wird die Gültigkeit des Tokens zusätzlich gegen die Datenbank geprüft
+
+### 10.3 Automatische Token-Erneuerung
+
+Authentifizierungstoken werden automatisch erneuert, bevor sie ablaufen. Dies gewährleistet eine unterbrechungsfreie Nutzung bei gleichzeitiger Begrenzung der Token-Gültigkeitsdauer.
+
+---
+
+## 11. Offene Punkte und Empfehlungen
+
+Transparenz schafft Vertrauen. Die folgenden Punkte sind offen benannt, damit Kunden und Betreiber informierte Entscheidungen treffen können.
+
+| Thema | Status | Empfehlung |
+|---|---|---|
+| Granulares Consent-Management | Nicht vorhanden | Falls regulatorisch erforderlich, als separates Modul ergänzen |
+| PII-Filterung vor KI-Versand | Nicht standardmässig aktiv | Datenschutz-Neutralisierer aktivieren oder Private LLM einsetzen |
+| Security-Header (CSP, HSTS) | Auf Infrastruktur-Ebene | Konfiguration auf Reverse-Proxy-Ebene dokumentieren und prüfen |
+| Datenschutz-Kontaktadresse | Platzhalter | Pro Deployment mit tatsächlicher DSB-Kontaktadresse konfigurieren |
+| Formale Zertifizierungen | Keine vorhanden | ISO 27001 / BSI auf Basis der vorhandenen Massnahmen anstrebbar |
+
+---
+
+## 12. Zusammenfassung
+
+PowerOn vereint Enterprise-KI-Funktionalität mit einem umfassenden Sicherheits- und Datenschutzkonzept. Die Plattform bietet:
+
+- **DSGVO-konforme Betroffenenrechte** als Self-Service-Funktionen
+- **Vollständige Mandantentrennung** mit serverseitiger Zugehörigkeitsprüfung
+- **Feingliedriges Berechtigungssystem** mit individuell konfigurierbaren Rollen
+- **Verschlüsselung nach Industriestandard** für ruhende und übertragene Daten
+- **Lückenlosen Audit-Trail** für Compliance-Nachweise
+- **Transparente KI-Datenverarbeitung** mit Optionen für höchste Datenschutzanforderungen
+
+Gleichzeitig werden bestehende Einschränkungen offen kommuniziert und Empfehlungen für ergänzende Massnahmen gegeben. Diese Kombination aus implementierter Sicherheit und transparenter Kommunikation bildet die Grundlage für eine vertrauensvolle Zusammenarbeit.
+
+---
+
+*Dieses Dokument basiert auf einer Analyse der PowerOn-Plattform (Stand Februar 2026). Alle beschriebenen Massnahmen sind in der Plattform implementiert und wurden anhand der Codebasis verifiziert. Angaben ohne Gewähr -- für verbindliche Zusicherungen gelten die jeweiligen Vertragsvereinbarungen.*