# PowerOn Plattform – Features, Setup & Roadmap

**Stand:** Februar 2026  
**Zielgruppe:** Intern, Präsentation, Roadmap-Planung

---

## 1. Überblick

Dieses Dokument beschreibt die vorhandenen Features der PowerOn-Plattform, das allgemeine Plattform-Setup (Security, Mandanten, Nutzerverwaltung) sowie die Einordnung in die Roadmap März–Mai 2026.

---

## 2. Allgemeines Plattform-Setup

### 2.1 Mandanten-/User-Management

PowerOn ist eine **Multi-Mandanten-Plattform**:

- **Mandantenmodell:** Jede Organisation/Kunde wird als Mandant abgebildet.
- **Datenisolation:** Daten eines Mandanten sind strikt von anderen Mandanten getrennt.
- **Zugehörigkeitsprüfung:** Bei jedem Zugriff wird geprüft, ob der Nutzer dem Mandanten angehört (via `UserMandate`).
- **Request-Kontext:** `mandateId` und `featureInstanceId` werden über Header (`X-Mandate-Id`, `X-Feature-Instance-Id`) übergeben.
- **Mehrfachmandanten:** Nutzer können in mehreren Mandanten tätig sein; der Kontext wird pro Anfrage festgelegt.

**Zentrale Entitäten:**

| Entität | Beschreibung |
|---------|--------------|
| Mandate | Mandant (Organisation, Abteilung, Kunde) |
| UserInDB | Nutzer (Benutzername, Profil) |
| UserMandate | Zuordnung Nutzer ↔ Mandant (mit enabled) |
| UserMandateRole | Rollenzuweisung auf Mandanten-Ebene |
| FeatureInstance | Instanz eines Features innerhalb eines Mandanten |
| FeatureAccess | Zugriff Nutzer auf Feature-Instanz |
| FeatureAccessRole | Rollen pro Feature-Instanz |

### 2.2 Rollenbasierte Zugriffskontrolle (RBAC)

- **AccessRule-Kontext:** System, API, DATA
- **AccessLevel:** NONE, MY, GROUP, ALL
- **Template-Rollen:** Pro Feature können globale Rollenvorlagen definiert werden; bei Erstellung einer Feature-Instanz werden diese kopiert.
- **Namespaces:**  
  - `data.uam.*` → Mandanten-UAM  
  - `data.chat.*`, `data.files.*`, `data.automation.*` → nutzer-eigen (MY)  
  - `data.feature.{code}.*` → Mandanten-/Feature-spezifisch

### 2.3 Authentifizierung

- **Lokal:** Benutzername + Passwort, JWT
- **Microsoft (Azure AD / Entra ID):** SSO
- **Google:** SSO
- **Token:** HTTP-only Cookies, automatische Erneuerung, Widerruf möglich

### 2.4 Security-Baseline (Compliance)

- **Verschlüsselung:** AES (Fernet), PBKDF2-HMAC-SHA256 für Konfiguration
- **DSGVO:** Auskunft, Löschung, Datenübertragbarkeit, Berichtigung als Self-Service
- **Audit-Trail:** Zugriffe, Sicherheitsereignisse, DSGVO-Aktionen, Berechtigungsänderungen
- **OWASP:** CSRF, Rate Limiting, parametrisierte Queries, CORS
- **Neutralisierung:** Optionales Modul zur Maskierung/Pseudonymisierung von PII vor KI-Versand

---

## 3. Feature-Übersicht (`platform-core/modules/features`)

### 3.1 Chatbot

| Aspekt | Inhalt |
|--------|--------|
| **Code** | `chatbot` |
| **Zweck** | KI-gestützter Chat mit Workflows, Tools, Memory |
| **DB** | `poweron_chatbot` |
| **Besonderheiten** | RBAC pro `featureInstanceId`, streaming, Multi-Round, Tools (z. B. Websuche), Event-Manager |

### 3.2 Chatplayground

| Aspekt | Inhalt |
|--------|--------|
| **Code** | `chatplayground` |
| **Zweck** | Sichere Testumgebung für KI-Chat |
| **Besonderheiten** | Wrapper um `interfaceDbChat` mit Feature-Instanz-Kontext; isolierte Umgebung pro Mandant |

### 3.3 TeamsBot

| Aspekt | Inhalt |
|--------|--------|
| **Code** | `teamsbot` |
| **Zweck** | Microsoft Teams Bot mit authentifiziertem Nutzer, Protokollierung |
| **DB** | `poweron_teamsbot` |
| **Besonderheiten** | Sessions, Transcripts, Bot-Antworten; System-Bots (mandantenbezogen); Browser-Connector für Interaktionen |

### 3.4 Trustee (BuHa-Integration)

| Aspekt | Inhalt |
|--------|--------|
| **Code** | `trustee` |
| **Zweck** | Treuhand/Buchhaltung: Organisationen, Verträge, Dokumente, Positionen, Buchungssynchronisation |
| **DB** | `poweron_trustee` |
| **Accounting-Connectors** | Bexio, Abacus, RMA |
| **Besonderheiten** | Feature-eigene Rollen (admin, operate, userreport), RBAC + feature-spezifische Zugriffslogik |

### 3.5 Neutralization (Dokumentbearbeitung mit KI)

| Aspekt | Inhalt |
|--------|--------|
| **Code** | `neutralization` |
| **Zweck** | Maskierung/Pseudonymisierung sensibler Daten in Dokumenten (PII) vor KI-Verarbeitung |
| **DB** | `poweron_neutralization` |
| **Besonderheiten** | PDF in-place (PyMuPDF), Platzhalter (z. B. `[name.uuid]`), konfigurierbare Muster; Neutralize Playground |

### 3.6 Automation

| Aspekt | Inhalt |
|--------|--------|
| **Code** | `automation` |
| **Zweck** | Zeitgesteuerte / Event-getriggerte Workflows |
| **DB** | `poweron_automation` |
| **Besonderheiten** | AutomationDefinition, AutomationTemplate (System + Instanz), Event-Management, Callback-Registry |

### 3.7 RealEstate

| Aspekt | Inhalt |
|--------|--------|
| **Code** | `realestate` |
| **Zweck** | Immobilienverwaltung: Projekte, Parzellen, Dokumente, Kanton/Gemeinde, Geo-Daten |
| **DB** | `poweron_realestate` |
| **Besonderheiten** | BZO-Extraktion, Swiss Topo Scraping, LangGraph |

---

## 4. Einordnung der strategischen Features (Roadmap-relevant)

| Feature | Status | Beschreibung |
|---------|--------|--------------|
| **Chatbot / Playground** | Live | Sichere Umgebung für Nutzer; Chatplayground als abgegrenzte Testinstanz |
| **Private LLM** | Live | Ollama-basierter Connector (`privatellm`); lokal/on-premise; kein Datenabfluss |
| **BuHa-Integration** | Live | Trustee mit Connectors Bexio, Abacus, RMA; Sync zu Buchhaltungssystemen |
| **TeamsChatbot** | Live | Bot in Teams mit identifiziertem Nutzer; voll protokolliert |
| **Dokumentbearbeitung mit KI** | In Arbeit | Neutralization (Masking) + Referenzprozess ERP/Dokument-Extraktion; strukturierter Output |

---

## 5. Roadmap März–Mai 2026: Maßnahmenplan

*Ziel bis Ende Mai: erste produktive Deployments live, Standard-Onboarding v1, Paid Usage gestartet, Security & Compliance als Default.*

### März 2026 – Foundations + Pilot→Prod

| Maßnahme | Verantwortlich |
|----------|----------------|
| Go-Live Readiness Checklist v1 (Monitoring, Logging, Backup/Restore, Incident-Flow, Release-Prozess) | Platform/Engineering |
| Mandanten-/User-Setup „v1“ (Roles, Zugriff, Audit-Logs minimum viable) | Security/Compliance |
| Security-Baseline aktivieren: Masking/Neutralisierung als Standard pro Workflow + Definition „Datenklasse A/B/C“ | Security/Compliance |
| 1 Referenzprozess auswählen & finalisieren (z. B. ERP/Dokument-Extraktion mit strukturiertem Output) | Platform/Engineering |
| Erste produktive Installation vorbereiten (Kunde A) | Customer Success |

**Output Ende März:** 1 produktiver Kunde „go-live ready“, Onboarding-Runbook v1, Security Default aktiv

---

### April 2026 – Erste produktive Deployments + Reproduzierbarkeit

| Maßnahme | Verantwortlich |
|----------|----------------|
| Produktivsetzung Kunde A inkl. Abnahme (SLA-light, Supportkanal) | Customer Success |
| Onboarding v1 standardisieren: Templates (Config, Policies, Integrationsmodule), Setup in < 6 Wochen | Platform/Engineering |
| Workflow Engine hardening: Fehlerbehandlung, Retries, Idempotenz, Kontextgrenzen (wichtigste 20 %) | Platform/Engineering |
| Kunde B starten (zweites Setup als Wiederholbarkeitstest) | Go-To-Market |
| Kosten-/Usage-Metering einführen (Nutzer, Runs, Tokens, Zeitersparnis-Indikator) | Platform/Engineering |

**Output Ende April:** 1 Kunde produktiv, 2. Kunde im Setup, Onboarding v1 wiederholbar, Usage-Metriken sichtbar

---

### Mai 2026 – Paid Usage + Skalierbarer Betrieb

| Maßnahme | Verantwortlich |
|----------|----------------|
| Paid Usage aktivieren (Pricing/Package v1, Billing-Prozess) | Go-To-Market |
| Support & Betrieb v1: Monitoring-Dashboards, Alerting, Incident-Routinen, Release-Kadenz (z. B. 2-wöchentlich) | Platform/Engineering |
| Security & Compliance ausbauen: Policy-Sets pro Workflow, Auditierbarkeit (wer/wann/was), Fallback lokales LLM | Security/Compliance |
| Kunde B go-live + Kunde C als Pipeline-Test | Customer Success |
| „First Value Moment“ messbar: pro Kunde 1–2 Kennzahlen | Customer Success |

**Output Ende Mai:** mindestens 2 produktive Deployments, erste zahlende Nutzung, Betrieb stabil, First Value messbar

---

## 6. Zuordnung Features ↔ Roadmap

| Feature | März | April | Mai | Anmerkung |
|---------|------|-------|-----|-----------|
| Neutralisierung | Security Default aktiv | — | Policy-Sets pro Workflow | Datenklasse A/B/C definieren |
| Trustee/BuHa | Referenzprozess ERP/Dok-Extraktion | Wiederholbarkeit Onboarding | — | strukturierter Output |
| Chatbot/Playground | — | — | — | bereits produktiv nutzbar |
| TeamsBot | — | — | — | authentifizierter User, protokolliert |
| Private LLM | — | — | Fallback-Strategie dokumentieren | für höchste Datenschutzanforderungen |

---

## 7. Verantwortlichkeiten (Slide-Footer)

| Rolle | Verantwortungsbereich |
|-------|------------------------|
| **Platform/Engineering** | Stabilität, Deployment, Monitoring, Workflow-Hardening |
| **Security/Compliance** | Policies, Masking, Audit, Datenklassifikation |
| **Go-To-Market** | Kundenpipeline, Packaging/Pricing v1, Paid Activation |
| **Customer Success** | Onboarding-Runbook, Abnahme, Adoption/Value Tracking |

---

*Dokument basiert auf der Gateway-Codebasis (Stand Februar 2026) und dem Compliance-Dokument `poweron_sicherheit_und_compliance.md`.*