Governance, Datenschutz und Lizenzen

Governance, Datenschutz und Lizenzen

0:00 Willkommen zu Modul zwei. Im ersten Modul haben Sie einen Anwendungsfall für Lotsenhaus beschrieben, mit Nutzen, Risiken und Kriterien. Jetzt kommt die Frage, die in vielen Projekten zu spät gestellt wird: Wohin fließen die Daten eigentlich, wer darf was sehen, und unter welchen Bedingungen dürfen wir die Software überhaupt so einsetzen, wie wir es vorhaben?

0:21 Wir verfolgen Datenflüsse, verteilen Zuständigkeiten, schauen auf DSGVO und KI-Verordnung und werfen einen genauen Blick auf die Lizenz von Open WebUI. Die enthält nämlich eine Bedingung, die schon beim Pilot von Brandtner greift. Am Ende steht eine Governance-Matrix, an der jede Freigabe vorbeimuss.

Governance, Datenschutz und Lizenzen

0:39 Wir bleiben am ersten Tag, wechseln aber die Perspektive. Der Satz auf der Folie beschreibt die Kehrseite des Eigenbetriebs. Wer selbst betreibt, gewinnt Kontrolle, und genau damit übernimmt er auch die Verantwortung. Es gibt keinen Anbieter mehr, auf den man zeigen kann. Jede Anfrage geht dorthin, wohin Sie sie schicken. Dieses Modul sorgt dafür, dass Sie das bewusst entscheiden und nicht aus Versehen.

Datenklassen und Datenflüsse

1:03 Beginnen wir mit der Grundfrage jeder Governance. Welche Daten haben wir, und wohin gehen sie? Denn jede Anfrage verlässt das Chatfenster. Die Frage ist nur, wohin. Vier Datenklassen, von öffentlich bis streng vertraulich, und für jede eine klare Regel. Das Datenblatt einer Förderanlage darf überallhin, die Reisekostenrichtlinie ebenfalls.

1:26 Bei der Angebotskalkulation eines Kundenprojekts endet der Weg nach draußen, sie bleibt beim lokalen Modell. Personalakten und Gehaltsdaten erreichen gar kein Modell. Das wirkt streng, ist aber erstaunlich praktisch, denn jede Freigabe lässt sich auf eine einzige Frage zurückführen: Welche Klasse kann diesen Dienst erreichen?

1:45 Die Fußzeile ergänzt eine Regel, die oft übersehen wird. Ein Dienst erbt immer die höchste Klasse, die bei ihm ankommen kann. Das gilt auch für Dienste, die keiner als Modell wahrnimmt. Und genau diese unauffälligen Dienste zeigt die Tabelle. Wenn jemand im Chat eine Frage stellt, ist das Chatmodell nur der offensichtlichste Empfänger.

2:06 Der Embedding-Dienst bekommt Dokumenttext und Suchanfragen. Die Extraktion bekommt ganze Dateien. Die Websuche bekommt Suchbegriffe, Werkzeugserver bekommen die Parameter jedes Aufrufs. Und je nach Einstellung landen sogar Inhalte im Protokoll. Zu jedem dieser Wege gibt es in Open WebUI eine Stellschraube, meist eine Umgebungsvariable oder eine Berechtigung je Gruppe. Achten Sie besonders auf die Fußzeile.

2:30 Wer für die Texterkennung einen externen Dienst wählt, schickt komplette Dateien nach draußen, und das gehört vorher freigegeben. Hier geht es um den Lebenszyklus der Daten, und die Tabelle trennt sauber zwei Dinge: was die Software kann und was Brandtner selbst regeln muss. Open WebUI bietet temporäre Chats, Löschfunktionen und Exporte für Nutzer wie für Admins. Was die Software nicht weiß, sind Ihre Fristen, Ihre Pflichtfälle und Ihre Backups.

2:58 Bemerkenswert ist der Admin-Export, der ab Werk eingeschaltet ist. Den sollten Sie abschalten oder gut begründen. Und die Fußzeile räumt mit einem verbreiteten Missverständnis auf. Ein temporärer Chat wird nicht gespeichert, aber das Modell verarbeitet die Anfrage trotzdem. Temporär heißt also nicht unsichtbar. Der erste Stolperstein ist der Tunnelblick aufs Chatmodell. Wer nur dieses bewertet, übersieht Embedding, Extraktion und Websuche, und damit drei weitere Datenempfänger.

3:28 Der zweite betrifft temporäre Chats. Sie wirken wie ein sicherer Modus, doch aktive Werkzeuge können auch dort eigene Daten speichern. Drittens das Audit-Log: Es ist gut gemeint, aber auf der ausführlichsten Stufe kopiert es Chatinhalte ins Logsystem, und dort gelten oft ganz andere Fristen und Zugriffe. Und viertens die Backups. Löschfristen sind schnell beschlossen, doch in der Sicherung leben gelöschte Chats weiter, bis jemand auch dort aufräumt.

Zuständigkeiten und Transparenz

3:55 Daten fließen, und jemand muss diese Flüsse verantworten. Das zweite Kapitel fragt: Wer sieht was, wer entscheidet was, und wissen die Beschäftigten eigentlich davon? Im ersten Modul ging es um das Einführungsteam. Diese Tabelle schärft die Rollen für die Governance. Der Plattformbetrieb setzt technisch um, die Fachbereiche nehmen fachlich ab, die Gruppe lh-wissen pflegt die Wissensbasen.

4:18 Datenschutz und Informationssicherheit bewerten, und der Betriebsrat hat ein echtes Mitbestimmungsrecht, sobald technische Einrichtungen Verhalten oder Leistung überwachen können. Ganz unten steht die Geschäftsleitung, und das ist kein Zufall. Die Fußzeile erklärt, warum. Die Datenschutzbeauftragte berät und überwacht, sie entscheidet aber nicht.

4:38 Die Verantwortung im Sinne der DSGVO liegt bei der Geschäftsführung, auch wenn sie das gern delegieren würde. Diese vier Einstellungen sind ein kleines Stück Selbstbeschränkung. Sie sorgen dafür, dass Administratoren fremde Chats nicht über die Oberfläche öffnen, keinen Massenexport ziehen und die Rechte an Ressourcen nicht einfach umgehen.

4:59 Das Audit-Log schreibt nur Metadaten, keine Inhalte. Beachten Sie die Beschriftungen: Die Standardwerte sind offener, Sie müssen also aktiv zudrehen. Und diese Schalter wirken nur in der Oberfläche. Wer an Datenbank, Host oder Backups herankommt, sieht weiterhin alles. Das ist wie ein abgeschlossener Aktenschrank in einem Raum, zu dem der Hausmeister den Schlüssel hat. Deshalb ergänzen klare Rollen die Technik, sie ersetzen sie nicht.

5:25 Neue Modelle und Integrationen kommen ständig, und ohne festes Verfahren landen sie einfach so in der Produktion. Der Ablauf hier ist bewusst schlank. Alles beginnt mit einem Antrag, der Anwendungsfall, höchste Datenklasse, Anbieter und Datenfluss nennt. Dann bewerten Sicherheit und Datenschutz, und der Betriebsrat kommt dazu, sobald Auswertungen über Beschäftigte möglich werden.

5:47 Eingerichtet wird zuerst im Test und nur für eine Fachgruppe. Am Ende steht der Eintrag in der Governance-Matrix, mit Prüftermin. Die Fußzeile ist die eigentliche Regel: Ohne diesen Eintrag entsteht keine Verbindung in der Produktion. So wird aus einem Prozess eine echte Schranke. Vier Missverständnisse begegnen einem hier häufig.

6:07 Erstens hält man den abgeschalteten Admin-Zugriff auf Chats für vollständigen Schutz, dabei bleibt der Weg über die Datenbank offen. Zweitens eine Nutzungsrichtlinie, die verschweigt, was Administratoren technisch sehen können. Das untergräbt Vertrauen, sobald es jemand herausfindet. Drittens Direktverbindungen: Können Nutzer eigene externe Modelle anbinden, läuft alles am Freigabeverfahren vorbei. Deshalb gehört diese Möglichkeit abgeschaltet.

6:33 Und viertens Freigaben ohne Prüftermin. Anbieter ändern ihre Bedingungen, Modelle werden abgelöst, und eine Freigabe von gestern passt nicht automatisch zur Lage von morgen.

DSGVO und EU AI Act

6:44 Jetzt zum Rechtsrahmen. Ein wichtiger Gedanke vorweg: Der Eigenbetrieb verschiebt die Kontrolle zu Ihnen. Die Verantwortung verschiebt er nicht weg, sie war immer schon bei Ihnen. Die Tabelle übersetzt bekannte Grundsätze der DSGVO in konkrete Maßnahmen für Lotsenhaus. Und das Schöne ist: Vieles davon haben Sie schon in der Hand.

7:05 Zweckbindung heißt, je Anwendungsfall festzulegen, wofür die Daten da sind, und ausdrücklich keine Leistungsauswertung. Datenminimierung erreichen Sie über Datenklassen, temporäre Chats und Uploadrechte je Gruppe. Speicherbegrenzung betrifft Chats, Dateien, Protokolle und Backups gleichermaßen. Dazu kommen Informationspflichten, der Vertrag mit dem externen Anbieter, die Frage nach dem Standort seiner Rechenzentren und die Prüfung einer Folgenabschätzung.

7:31 Die Fußzeile meint es ernst: Die Rechtsgrundlage klären Datenschutz und Rechtsabteilung, nicht das Plattformteam. Die KI-Verordnung unterscheidet zwei Rollen, und für Brandtner ist die Zuordnung eindeutig. Anbieter ist, wer ein KI-System entwickelt oder unter eigenem Namen in Verkehr bringt, also Modellhersteller und externe KI-Dienste.

7:52 Betreiber ist, wer ein solches System in eigener Verantwortung einsetzt, und das ist Brandtner mit Lotsenhaus. Die Pflichten unterscheiden sich entsprechend. Anbieter müssen die Interaktion mit KI erkennbar machen, Betreiber müssen KI-Texte offenlegen, die sie veröffentlichen. Eine Pflicht teilen sich beide: Maßnahmen zur KI-Kompetenz des Personals. Die betrifft Sie also unabhängig davon, wie Sie die Rollenfrage im Detail beantworten.

8:18 Die Verordnung gilt nicht auf einen Schlag, sondern stufenweise, und die Tabelle sortiert das nach Datum. Verbotene Praktiken und die KI-Kompetenz gelten schon seit Februar 2025. Emotionserkennung am Arbeitsplatz scheidet also aus, und vor dem Zugang braucht es Schulung und Leitfaden. Die Transparenzpflichten kamen im August 2026 dazu.

8:40 Hochrisiko-Anwendungen, etwa bei Personalentscheidungen, folgen im Dezember 2027, und genau die sind im Pilot ohnehin ausgeschlossen. Lesen Sie die Fußzeile genau. Die Kompetenzpflicht verlangt passende Maßnahmen, aber kein garantiertes Niveau je Person. Das entlastet, ist aber kein Freibrief. Der verführerischste Satz in diesem Kapitel lautet: Läuft bei uns, also konform. Die Doku ist da deutlich.

9:07 Zertifizierungen betreffen die jeweilige Installation, nicht die Software an sich. Der zweite Stolperstein ist die Pilot-Ausrede. Nur ein Pilot rechtfertigt nicht, einen externen Anbieter ohne Auftragsverarbeitungsvertrag anzubinden, denn die Daten fließen trotzdem. Drittens die Folgenabschätzung, die gehört vor den Rollout, nicht dahinter. Und viertens die KI-Kompetenz.

9:30 Eine Rundmail mit drei Tipps ist schnell verschickt, passt aber selten zum tatsächlichen Einsatz. Gefragt sind Maßnahmen, die zu Ihren Anwendungsfällen passen.

Lizenzen und Support

9:40 Jetzt ein Thema, das viele bei Open-Source-Projekten gar nicht auf dem Zettel haben: die Lizenz. Bei Open WebUI lohnt der genaue Blick, denn das Logo bleibt sichtbar, außer eine Ausnahme greift. Open WebUI hat im April 2025 die Lizenz gewechselt, mit Version null Punkt sechs Punkt sechs. Seitdem gilt eine eigene Lizenz. Nutzen, ändern und weitergeben dürfen Sie weiterhin, auch kommerziell.

10:05 Neu ist eine Bedingung zum Branding: Name, Logo und Kennzeichen von Open WebUI dürfen nicht entfernt, verändert oder verdeckt werden. Ältere Versionen bis null Punkt sechs Punkt fünf bleiben unter der BSD-Lizenz. Und eine Folge sollten Sie kennen, gerade wenn in Ihrem Haus Open Source eine Einkaufsregel ist. Nach den Kriterien der OSI ist die neue Lizenz keine Open-Source-Lizenz mehr. Das ist keine Wertung, aber ein Punkt für Ihre Lizenzprüfung.

10:34 Von der Branding-Regel gibt es vier Ausnahmen, und für Brandtner ist die Tabelle ernüchternd. Die kleine Installation endet bei fünfzig Nutzern in einem Zeitraum von dreißig Tagen, der Pilot hat sechzig. Ein substanzieller Beitrag zum Projekt liegt nicht vor, eine Forschungsstudie auch nicht. Bleibt die Enterprise-Lizenz als Option für später.

10:54 Das heißt aber nicht, dass Lotsenhaus nicht Lotsenhaus heißen darf. Die Fußzeile zeigt den legalen Weg. Sie setzen den eigenen Namen über eine Einstellung, und Open WebUI hängt seinen eigenen in Klammern selbst an. So bekommen Sie Ihre Marke, und die Lizenz bleibt gewahrt. Wer hilft, wenn etwas klemmt? Die Tabelle ordnet fünf Wege nach dem, was sie leisten, und nach ihrer Grenze.

11:18 Die Community mit Doku, Issues und Discord ist wertvoll, macht aber keine Zusagen zu Reaktionszeiten. Die Enterprise-Lizenz bringt Prioritätssupport und Vereinbarungen zum Service-Level, richtet sich aber nur an Organisationen. Sprechstunden mit den Core-Entwicklern sind Beratung, keine Umsetzung. Ein Integrator setzt um, aber seine Qualität müssen Sie selbst prüfen.

11:41 Und das eigene Team braucht Wissen und Zeit. Die Fußzeile fasst es zusammen: Die Umsetzung bleibt bei Brandtner, egal welchen Weg Sie wählen. Die naheliegendste Abkürzung ist hier die riskanteste. Das Logo per CSS auszublenden, weil der Pilot ja nur intern läuft, ist ab einundfünfzig Nutzern ein Lizenzverstoß. Intern spielt dafür keine Rolle. Zweitens wird die Nutzerzahl gern einmal am Start gezählt. Die Lizenz spricht aber von jedem Zeitraum von dreißig Tagen, und Pilotgruppen wachsen.

12:11 Drittens deckt die Lizenz von Open WebUI keine Modelle ab. Jedes Modell bringt eigene Bedingungen mit. Und viertens enthält das Standardimage eingebaute Modelle für Embedding und Sprache. Die gehören genauso in die Lizenzprüfung, auch wenn sie niemand bewusst ausgewählt hat.

Übung

12:29 Jetzt bringen Sie alles zusammen. Die Übung baut auf Ihrem Steckbrief aus dem ersten Modul auf und macht daraus ein Werkzeug, an dem jede Freigabe vorbeimuss. Ihre Aufgabe ist eine Governance-Matrix für Lotsenhaus. Klingt nach Bürokratie, ist aber im Kern ein sehr praktisches Werkzeug. Es geht um die Fähigkeit, Datenklassen, Dienste und Zuständigkeiten so zu verknüpfen, dass jede Freigabe nachvollziehbar wird.

12:53 Wer später fragt, warum das externe Modell keine Angebotskalkulation sehen darf, findet die Antwort in einer Zeile. Gelungen ist die Matrix, wenn alle vier Datenklassen erlaubten Diensten zugeordnet sind, jeder Dienst eine verantwortliche Rolle hat und das Freigabeverfahren in höchstens fünf Schritten beschrieben ist. Kürze ist hier eine Tugend, denn ein Verfahren, das niemand liest, schützt auch niemanden.

13:17 Damit Sie nicht beim leeren Blatt beginnen, gibt es ein Gerüst. Zwei Zeilen sind schon ausgefüllt und zeigen das Muster. Das lokale Modell auf inferenz-01 darf bis vertraulich arbeiten und liegt beim Plattformbetrieb. Das externe Modell endet bei intern und braucht einen Vertrag. Die übrigen Zeilen sind offen, und das sind genau die Dienste aus dem Datenfluss, die man gern vergisst: Embedding, Extraktion, Websuche und das Werkzeug für den Störmelder.

13:43 Die Fußzeile nimmt eine Entscheidung vorweg, die nicht verhandelbar ist. Streng vertrauliche Daten erreichen keinen Dienst, und das steht sichtbar über der ganzen Matrix. Der Weg zur Matrix folgt einer Wissensfrage durch das System. Sie listen zuerst alle Dienste auf, die diese Frage berührt. Dann tragen Sie je Dienst die höchste zulässige Datenklasse ein, und zwar mit Begründung, denn die brauchen Sie bei der nächsten Diskussion.

14:09 Danach legen Sie Verantwortliche fest, notieren Admin-Einstellungen und Löschfristen als Vorgaben für die Konfiguration und beschreiben das Freigabeverfahren. Die Fußzeile zeigt, wohin die Reise geht. Im nächsten Modul übersetzen wir diese Matrix in Netzwerkzonen und erlaubte Verbindungen nach draußen. Aus Papier wird dann Architektur.