nexarch/SAAS-BETRIEBSMODELL.md

NEXARCH 2.0 – SaaS-/Multi-Tenant-Betriebsmodell (vertraglich-organisatorisch)

Stand: 2026-08-26. Kein Rechtsdokument, keine Rechtsberatung. Strukturiert die vertraglich-organisatorischen Fragen, die aus den bereits getroffenen TECHNISCHEN Entscheidungen entstehen (PRODUKTARCHITEKTUR.md Abschnitt 7, SKALIERUNGSKONZEPT.md, PROXMOX-DEPLOYMENT.md), und macht sie sichtbar, bevor sie in echte Verträge/AGB übersetzt werden — die eigentliche Formulierung braucht juristische Prüfung, hier geht es nur darum, was die Technik dem Vertrag vorgibt bzw. wo der Vertrag von der Technik abhängt.

1. Drei Betriebsmodelle, drei unterschiedliche Vertragslogiken

Modell	Wer betreibt	Wer ist DSGVO-"Verantwortlicher"	Wer ist "Auftragsverarbeiter"
SaaS (Stufe 1/2 beim Anbieter)	NEXARCH-Anbieter	Kunde	NEXARCH-Anbieter
On-Premise (Stufe 1 beim Kunden)	Kunde selbst	Kunde	— (kein Auftragsverarbeitungsverhältnis mit NEXARCH-Anbieter, ggf. Softwarelizenzvertrag statt AVV)
Private Cloud (Stufe 3, dediziert)	je nach Vereinbarung: Anbieter ODER Kunde	Kunde	Anbieter, falls Anbieter betreibt

Diese Zuordnung ist keine Neuigkeit, aber wichtig als Ausgangspunkt: nur beim SaaS- und beim betriebenen Private-Cloud-Modell braucht es einen Auftragsverarbeitungsvertrag (AVV nach Art. 28 DSGVO) zwischen NEXARCH-Anbieter und Kunde — beim reinen On-Premise-Modell (Kunde installiert selbst gemäß PROXMOX-DEPLOYMENT.md Abschnitt 2) fehlt die Auftragsverarbeitungsbeziehung, dafür braucht es einen klaren Software-Lizenzvertrag.

2. Mandantentrennung — was die Technik jetzt zusichern kann

Geändert: Core setzt Modell C um — eine eigene, physisch getrennte Datenbank je Mandant (Core TEN-01/TEN-06/TEN-07), keine gemeinsame Datenbank mit applikationsseitiger Filterung mehr. Das verschiebt, was der Vertrag ehrlich versprechen kann:

• Ein SaaS-Vertrag darf jetzt "physische Datentrennung" zusichern — die Isolation hängt nicht mehr davon ab, dass jede einzelne Datenbank-Query korrekt gefiltert ist, sondern davon, dass ein Mandant technisch gar keine Verbindung zur Datenbank eines anderen Mandanten hat. Das ist eine belastbarere Zusage als applikationsseitige Filterung.
• Die Formulierung sollte trotzdem präzise bleiben: physisch getrennt sind die Datenbanken, nicht zwingend die komplette Infrastruktur (mehrere Tenant-Datenbanken können auf demselben Postgres-Server/derselben Hardware laufen, siehe SKALIERUNGSKONZEPT.md Abschnitt 3/4) — das ist immer noch ein starkes, aber kein "dedizierter Server pro Kunde"-Versprechen. Für Letzteres bleibt Stufe 3 (dedizierte Instanz) die richtige Antwort, jetzt als zusätzliche Infrastruktur-Trennung obendrauf, nicht als einzige Isolationsebene.
• Praktischer Zusatznutzen für den Vertrag: eine Tenant-Datenbank lässt sich als Ganzes zwischen On-Premise- und SaaS-Betrieb verschieben (Dump/Restore) — das erleichtert vertraglich zugesicherte Wechsel des Betriebsmodells (z.B. Exit aus SaaS zurück zu On-Premise, siehe Abschnitt 6) technisch, nicht nur organisatorisch.

3. Verfügbarkeits-SLA je Stufe — Vertrag darf der Technik nicht vorauslaufen

SKALIERUNGSKONZEPT.md Abschnitt 10: Stufe 1 hat kein Live-Failover, nur Backup/Restore. Eine hohe Verfügbarkeits-SLA (z.B. "99,9 % Uptime") ist auf Stufe-1-Infrastruktur technisch nicht seriös zusicherbar — Ausfallzeit bei einem DB-Problem ist die Zeit bis zum Restore, nicht Sekunden/Minuten.

Vorschlag: SLA-Stufen an die technischen Betriebsstufen koppeln, nicht pauschal für alle SaaS-Kunden gleich versprechen:

• Stufe 1 (kleine SaaS-Tarife): Best-Effort, kein hartes Uptime-Versprechen, klar kommunizierte Restore-Zeit (RTO) statt Failover-Zeit.
• Stufe 2 (Primary/Replica-Failover vorhanden): belastbare Uptime-SLA möglich, da automatisches Failover technisch existiert.
• Stufe 3: vertraglich individuell, da Infrastruktur ohnehin verhandelt wird (siehe LIZENZMODELL.md).

4. Backup, RPO/RTO — technisch vorhanden, vertraglich noch nicht beziffert

Archive BAK-01/02/03 liefert die Mechanik (Backup-Strategie, Snapshots, Restore-Verfahren) — was fehlt, ist eine vertraglich zugesicherte Zahl: Recovery Point Objective (wie viel Datenverlust maximal) und Recovery Time Objective (wie lange Restore maximal dauert) sind bisher nirgends als konkreter Wert festgelegt, weder technisch noch vertraglich. Das ist eine Lücke, die vor dem ersten SaaS-Vertrag geschlossen werden sollte — vermutlich durch einen Test des tatsächlichen Backup/Restore-Zyklus (Archive BAK-06 Restore-Testverfahren liefert die Datengrundlage dafür).

5. Incident-Meldung — Core OPS-04 als vertragliche Grundlage

Core OPS-04 (Incident-Response-Plan, DSGVO-72-Stunden-Meldefrist, siehe SICHERHEITSKONZEPT.md) ist die technisch-organisatorische Seite. Der AVV muss diese Meldefrist gegenüber dem Kunden UND die Kette zur Aufsichtsbehörde vertraglich abbilden — technisch ist der Prozess vorbereitet, die vertragliche Formulierung (wer meldet wem in welcher Frist) ist eigenständig zu formulieren, nicht aus OPS-04 ableitbar.

5a. Auftragsverarbeitung bei externem KI-Anbieter — AI ENG-03

AI ENG-03 erlaubt optional einen externen, OpenAI-kompatiblen Cloud-Anbieter als Alternative zum lokalen Ollama-Standardbetrieb; GOV-03 steuert je Tenant, ob Inferenz lokal oder extern läuft, und schließt Training auf Kundendaten aus (siehe SICHERHEITSKONZEPT.md Abschnitt 18, Finding #6). Technisch ist die Trennung damit vorbereitet — vertraglich fehlt: ein Auftragsverarbeitungsvertrag (AVV) mit jedem für einen Tenant aktivierbaren externen KI-Anbieter, bevor dessen Aktivierung für diesen Tenant freigegeben wird. Kein technisches Ticket nötig (die Umschaltung selbst existiert bereits über GOV-03), aber ein organisatorischer Prozess: externe Anbieter dürfen für einen Tenant erst in GOV-03 aktivierbar sein, wenn ein AVV mit diesem Anbieter vorliegt — sonst bleibt die Tenant-Konfiguration auf "nur lokal" beschränkt.

6. Exit-Strategie & Datenrückgabe bei Vertragsende

Technisch bereits abgedeckt: DMS DOC-08 (Massenexport), Mail ARC-07 (Export/Portabilität), Connect DMS2-01 (offenes Austauschformat) — die ecoDMS-Lehre "kein Vendor-Lock" (STORAGE-KONZEPT.md Abschnitt 8) gilt technisch bereits.

Vertraglich fehlt: eine zugesicherte Frist, in der Kundendaten nach Kündigung exportierbar bleiben, bevor sie gelöscht werden — vergleichbar mit der Parallelbetriebsfrist im MIGRATIONSKONZEPT.md (dort 90 Tage für den Altsystem-Übergang vorgeschlagen, hier für den umgekehrten Fall: Kunde verlässt NEXARCH). Kein technisches Ticket dafür nötig (Export-Mechanik existiert), nur eine vertragliche Frist plus ggf. ein Ablaufprozess ("Datenlöschung nach Fristablauf" als Anwendung der Archive-Retention-Engine, aber in die andere Richtung: nicht Aufbewahrung erzwingen, sondern nach Frist tatsächlich löschen).

7. Modul-Deaktivierung während der Laufzeit — technische Lücke

Core LIC-02 schaltet Module per Feature-Flag ab, wenn eine Lizenz das vorsieht (Kunde bucht z.B. AI ab). Was mit den Daten des deaktivierten Moduls passiert, ist nirgends spezifiziert — bleiben sie erhalten (nur Zugriff gesperrt) oder werden sie gelöscht? Das ist sowohl eine technische als auch eine vertragliche Frage, die aktuell in keinem Ticket beantwortet ist. Vorschlag: Deaktivierung sperrt nur den Zugriff, löscht nichts automatisch (konsistent mit der generellen Linie "Löschung nur über die Archive-Retention-Engine", siehe STORAGE-KONZEPT.md Abschnitt 4) — sollte aber als explizites Akzeptanzkriterium in LIC-02 nachgezogen werden, falls das noch nicht der Fall ist.

8. Offene Punkte

• RPO/RTO-Werte fehlen (Abschnitt 4) — brauchen einen tatsächlichen Restore-Test, bevor sie vertraglich zugesichert werden können.
• Modul-Deaktivierung ohne Datenverlust ist als Verhalten plausibel, aber nicht als Akzeptanzkriterium in Core LIC-02 verankert — sollte geprüft/ergänzt werden.
• Exit-Frist (Abschnitt 6) ist ein reiner Vertragswert, keine Technik — muss vom Geschäft festgelegt werden, ähnlich wie die Preisgestaltung in LIZENZMODELL.md.
• Dieses Dokument ersetzt keine juristische Prüfung von AVV/AGB — es benennt nur, wo Vertrag und Technik zusammenpassen müssen.
• AVV mit externen KI-Anbietern (Abschnitt 5a) ist ein reiner Vertragsschritt, keine Technik — muss vor Freigabe eines externen Anbieters in GOV-03 je Tenant vorliegen.