Wer patcht den Server?

Ich habe in dieser Reihe für lokal und europäisch getrommelt, und dabei bleibe ich. Aber einen Satz habe ich zu oft rausgehauen und zu selten zu Ende gedacht: „Dann betreibt man das halt selbst.“ Wer das sagt, hat die Arbeit noch komplett vor sich – nicht den Kauf, das Danach. So ein KI-System ist kein Regal, das man einmal hinstellt. Es ist eine Kiste, die läuft und läuft und gepflegt werden will, jede Woche, auch Samstagnacht. „Patchen“ heißt bei mir eigentlich: Kabel am Steckfeld stecken, im Studio, an der Patchbay. Am Server meint es etwas anderes und trotzdem dasselbe – wenn’s keiner steckt, kommt hinten kein Signal. Davon handelt dieser Nachtrag, und er ist kürzer als die Hauptteile: keine neue Front, nur das Fundament unter den vier alten.

Zwei Achsen, die ständig verwechselt werden

Die Verwechslung, die mich am meisten nervt: Betriebssicherheit und Rechtsschutz in einen Topf werfen. Klingt ähnlich, meint das Gegenteil.

Betriebssicherheit ist der Schutz gegen die, die von außen reinwollen – die Bande, die den Server verschlüsselt, die Lücke im veralteten System, das geknackte Passwort. Dagegen helfen die üblichen Mittel: Monitoring, Zertifikate, ein striktes Patch-Regime. Die großen Clouds können das oft richtig gut, besser als eine NGO es je hinkriegt. Ehrlich, das gehört anerkannt.

Rechtsschutz ist ein anderer Film: der Schutz davor, dass eine Behörde den Anbieter zwingt, die Daten rauszurücken. Der Zugriff kommt nicht von außen durch die Wand, sondern von innen durch die Vordertür – und die schließt der Anbieter selbst auf, weil sein Heimatrecht es ihm befiehlt. Dagegen hilft kein Zertifikat, kein Monitoring, kein Patch. Ein tadellos betriebenes US-System ist gegen den Zwangszugriff so nackt wie ein mies betriebenes.

Zwei Belege, die ich in Teil 2 zu knapp gehalten habe. Der eigentliche Hebel hinter dem Schrems-II-Urteil ist ein US-Gesetz: Section 702 des Foreign Intelligence Surveillance Act, zusammen mit der Executive Order 12333. An dieser Überwachungsbefugnis – nicht an irgendeinem Vertragsdetail – ist das alte Privacy Shield zerbrochen, weil sie den Zugriff auf die Daten von Nicht-US-Bürger:innen ohne gleichwertigen Rechtsschutz erlaubt. Dagegen steht auf europäischer Seite ein Artikel, den kaum jemand auf dem Schirm hat: Artikel 48 DSGVO erklärt die Anordnung eines Drittstaats-Gerichts oder einer Drittstaats-Behörde für sich genommen nicht zu einer zulässigen Grundlage, Daten herauszugeben. Der Anbieter steckt damit nicht in einem Loyalitätskonflikt, den man mit gutem Willen löst, sondern in einer echten Normenkollision: Zwei Rechtsordnungen wollen von ihm das Gegenteil. Das mixt kein Betriebskonzept sauber.

Kernsatz dieses Nachtrags, auch an meine eigene Adresse: Wer Souveränität ohne Betriebskonzept baut, verschiebt das Risiko nur, statt es zu senken. Du tauschst das Rechtsrisiko der fremden Cloud gegen das Betriebsrisiko im eigenen Keller – und hast nichts gewonnen, wenn dein Keller schlechter gesichert ist als das Rechenzentrum, aus dem du gerade ausgezogen bist.

Die achte Stelle: Zugriffskontrolle

In Teil 1 habe ich sieben Stellen aufgezählt, an denen in so einem System personenbezogene Daten anfallen. Eine achte habe ich unterschlagen, und im Eigenbau ist sie die fieseste: die Zugriffskontrolle.

RAG hat die miese Eigenschaft, die Rechte des Quellsystems auszuhebeln. In der klassischen Akte darf die Fallgeschichte vielleicht nur die zuständige Beraterin und die Leitung sehen. Sobald das Dokument zerhäckselt in der Vektordatenbank liegt, ist sein Inhalt für jeden abrufbar, der die Suchmaske aufmacht – es sei denn, du baust aktiv einen Türsteher davor, der prüft, wer was sehen darf. Und genau den baut im schnell zusammengesteckten Eigenbau keiner, weil „Hauptsache es läuft“ das Ziel war. Kenne ich vom Livemischen: Hauptsache, es kommt Ton – und dann pfeift’s im ungünstigsten Moment.

Der Zug, der mich damit versöhnt: Es sind dieselben Metadaten. Die Zuordnung, welches Textstück zu welcher Person gehört – die ich in Teil 3 für Auskunft und Löschung verlangt habe –, ist exakt das, was einen Rollenfilter vor der Suche möglich macht. Einmal sauber verkabelt, bekommst du vier Sachen für eine Investition: Auskunft, Löschung, Berichtigung und Zugriffskontrolle. Kein Zusatzaufwand neben dem Datenschutz – derselbe Aufwand, einmal richtig gesteckt.

Was Betrieb wirklich verlangt

Jetzt die Zusage aus Teil 2, ehrlich eingelöst – und ehrlich heißt: mit den Zahlen, die belegbar sind, und ohne die, die es nicht sind. Halbe Zahlen sind schlechter als keine, das ist bei Server-Specs nicht anders als bei den Wattangaben auf einer Billig-Endstufe.

Hardware zuerst, weil am handfestesten und am meisten missverstanden. Ein Modell in NGO-tauglicher Größe – zusammenfassen, wiederfinden, formulieren – braucht keinen Serverschrank, wenn man es quantisiert, also in eine kompaktere Form bringt. Mistral schreibt in der Modellkarte zu seinem quelloffenen 24-Milliarden-Modell klipp und klar, es passe „in eine einzige RTX 4090 oder einen MacBook mit 32 GB RAM, sobald es quantisiert ist“ – eine fette Gamer-Grafikkarte, kein Rack. Aber: dieselbe Modellkarte nennt für die volle, unquantisierte Genauigkeit rund 55 GB Grafikspeicher, und da bist du dann bei Technik, die im Budget wehtut. Die Wahl zwischen „läuft auf einer Karte“ und „braucht einen Cluster“ ist eine bewusste Qualitätsentscheidung, keine Formalie.

Der eigentliche Preis steht aber nicht auf der Rechnung vom Hardware-Laden, sondern in der Zeit danach – und die kriegt man nicht seriös in eine einzelne Zahl, also lasse ich das. Was sich benennen lässt, sind die Pflichten, und die hat das Bundesamt für Sicherheit in der Informationstechnik längst durchbuchstabiert. Sein IT-Grundschutz-Kompendium führt sie als eigene Bausteine: Patch- und Änderungsmanagement (OPS.1.1.3) – Lücken zeitnah zu, und „zeitnah“ heißt eben auch Samstag, wenn die kritische Lücke am Freitagabend reinkommt. Datensicherungskonzept (CON.3) – ein Backup, das nie zurückgespielt wurde, ist kein Backup, sondern Aberglaube; der getestete Restore ist Pflicht, nicht Kür. Behandlung von Sicherheitsvorfällen (DER.2.1) – jemand muss wissen, was zu tun ist, bevor es kracht, nicht danach. Das sind keine Schikanen für Konzerne. Das ist der Soundcheck vor dem Gig: Wer ihn überspringt, hat sein Problem dann vor Publikum.

Und ich sage klar dazu, was ich nicht belegen kann: Wie viele Stunden im Monat das die eine konkrete NGO frisst, hängt von zu vielem ab, um es als Statistik zu verkaufen. Aber es ist mehr als „nebenbei“, und wer es als „nebenbei“ einplant, plant den ersten Ausfall gleich mit.

Sechs Fragen für die, die nicht selbst betreiben

Die meisten kleinen NGOs werden nicht selbst betreiben, und das ist oft goldrichtig – gleich mehr dazu. Wer einkauft, hängt für all das oben am Anbieter, und die einzige Macht, die man dann hat, ist die richtige Frage vor der Unterschrift. Diese sechs kann jede dreiköpfige Beratungsstelle ohne eigene IT stellen, und die Antworten trennen die Seriösen von den Lauten:

Wer bei diesen Fragen rumeiert, hat schon geantwortet.

Sechs Punkte für die, die selbst betreiben

Und wer es doch selbst macht – Respekt, das ist der DIY-Weg, und ich mag den –, dem hilft keine Frageliste, sondern eine Minimalliste. Jeder Punkt mit einem Namen dran, nicht mit „das machen wir dann schon“: ein Rechtekonzept, das festlegt, wer welche Inhalte sieht; kein offen aus dem Internet erreichbares Interface; ein Update-Fahrplan mit Verantwortlichem und fester Frequenz; ein Backup mit mindestens einmal getestetem Restore; ein Protokoll mit klarer Aufbewahrungsfrist; und ein Vorfallsplan, der die 72-Stunden-Meldefrist kennt.

Der letzte Punkt hat einen Haken, den man leicht übersieht: Wer keine Protokolle führt, kann einen Vorfall nach Artikel 33 gar nicht ordentlich melden, weil er nicht weiß, was abgeflossen ist. Damit ist sauberer Betrieb keine freiwillige IT-Kür, sondern die Voraussetzung, überhaupt rechtskonform zu sein. Das ist die gute Nachricht in dem ganzen Betriebskram: Er spielt in genau dem Rechtsrahmen, in dem die ganze Reihe zu Hause ist.

Was das für die Empfehlung aus Teil 4 heißt

In Teil 4 habe ich nach Größe sortiert: kleine NGO eher Managed, große eher selbst. Zu grob. Ich schärfe es nach, ohne es zurückzunehmen. Die Schwelle ist nicht die Kopfzahl, sondern ob die sechs Punkte von eben dauerhaft besetzt sind. Vierzig Leute und keiner fühlt sich zuständig – schlechter dran als eine Fünf-Personen-Bude mit verlässlichem Dienstleister und sauberem Vertrag. Zuständigkeit schlägt Größe.

Und einen Gedanken aus Teil 4 muss ich nachziehen, den ich dort zu leicht hingesagt habe: den geteilten Knoten, mehrere NGOs teilen sich einen Betrieb. Politisch die richtige Richtung – genossenschaftlich, geteilt, das ist mein Ding. Rechtlich aber kein Selbstläufer. Gemeinsam betrieben heißt entweder gemeinsame Verantwortlichkeit nach Artikel 26 DSGVO, mit einer klaren Ansage, wer wofür geradesteht, oder Auftragsverarbeitung mit ordentlichem Vertrag. Wer das nicht regelt, baut genau die diffuse Verantwortungslosigkeit nach, an der schon die großen europäischen Souveränitätsprojekte abgeraucht sind. Teilen entlastet – aber nur, wenn geklärt ist, wer am Ende haftet.

Zuständigkeit statt Anschaffung

Damit endet der Nachtrag da, wo die Reihe endet, nur eine Etage tiefer. Souveränität ist nichts, das man kauft und dann hat, und nichts, das man einmal installiert. Sie ist eine Zuständigkeit, die jemand dauerhaft trägt – Woche für Woche, Update für Update, auch Samstagnacht. Wer das ernst nimmt, versteht auch, warum die kollektive Lösung aus Teil 4 keine Träumerei ist, sondern die einzige, die sich rechnet: Ein geteilter Betrieb verteilt nicht nur die Kosten, sondern die Zuständigkeit auf mehr Schultern, als eine einzelne kleine Stelle je hätte.

Und ich schließe ehrlich, auch wo es der eigenen Vorliebe wehtut. Wenn man die Betriebslast realistisch ansetzt, wird der Eigenbetrieb für eine kleine NGO noch unattraktiver, als Teil 4 zugibt – und die pragmatische, sauber vertraglich abgesicherte europäische Lösung noch vernünftiger. Unbequem für jeden, der den Eigenbau aus Prinzip liebt, und ich zähle mich dazu. Aber schönreden hilft keinem. Die Souveränität, die trägt, fängt nicht beim Server an. Sie fängt bei der Frage an, wer ihn patcht – und wer um drei Uhr nachts rangeht, wenn er brummt.

Nachtrag zur Reihe „Wem gehört das Gedächtnis?“. Orientierung, kein Rechtsrat – bei der konkreten Umsetzung braucht es datenschutzrechtliche und, je nach Aufbau, IT-sicherheitstechnische Beratung. Zeitkritische Angaben auf dem Stand August 2026.