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-UAMdata.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 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.2 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.3 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.4 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.5 Automation
| Aspekt |
Inhalt |
| Code |
automation |
| Zweck |
Zeitgesteuerte / Event-getriggerte Workflows |
| DB |
poweron_automation |
| Besonderheiten |
AutomationDefinition, AutomationTemplate (System + Instanz), Event-Management, Callback-Registry |
3.6 RealEstate
| Aspekt |
Inhalt |
| Code |
realestate |
| Zweck |
Immobilienverwaltung: Projekte, Parzellen, Dokumente, Kanton/Gemeinde, Geo-Daten |
| DB |
poweron_realestate |
| Besonderheiten |
BZO-Extraktion, Swiss Topo Scraping |
4. Einordnung der strategischen Features (Roadmap-relevant)
| Feature |
Status |
Beschreibung |
| Chat / 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 |
| Chat/Playground |
— |
— |
— |
bereits produktiv nutzbar |
| TeamsBot |
— |
— |
— |
authentifizierter User, protokolliert |
| Private LLM |
— |
— |
Fallback-Strategie dokumentieren |
für höchste Datenschutzanforderungen |
| 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.
