Cloud oder eigener Server? Die erste Architekturentscheidung für KI im kirchlichen Kontext

Wer im kirchlichen oder sozialwirtschaftlichen Umfeld über KI nachdenkt, fragt meist zuerst nach dem Modell: GPT, Claude, ein offenes Modell? Das ist die falsche erste Frage. Die erste Entscheidung ist die Architektur: wo läuft das System, und wer sieht dabei die Daten?

Drei Wege, ehrlich gegenübergestellt.

1. EU-gehostete Managed-Plattform

Eine Oberfläche wie Open WebUI, betrieben in der EU, mit quelloffenen Modellen (etwa Mistral, Llama oder Qwen), Auftragsverarbeitungsvertrag, Mandanten-Trennung und Rollenrechten. Für einen großen Teil der Büro- und Wissensarbeit, Protokolle, Recherche, Entwürfe, Gemeindekommunikation, ist das ein tragfähiger, kosteneffizienter Standard. Kein US-Cloud-Zwang, keine Abhängigkeit von einem einzelnen Modellanbieter.

2. Selbst betrieben

Ein offenes Modell auf einem deutschen Server oder direkt im Haus (etwa mit Ollama oder vLLM). Kein externer Dienst sieht die Daten, keine laufenden Token-Kosten, volle Kontrolle. Der Preis dafür ist Betriebsaufwand: Hardware, Updates, Betrieb. Das ist der Weg für besonders schützenswerte Daten, Seelsorge, Gesundheit, alles unter § 203 StGB.

3. US-Cloud direkt

GPT oder Claude direkt beim US-Anbieter. Im kirchlichen Kontext meist die schwierigste Option: Drittlandtransfer, Risikoabwägung, und die vom kirchlichen Recht geforderte Exit-Strategie lassen sich hier am schwersten sauber begründen.

Woran man die Wahl festmacht, und woran nicht

Nicht am Hype und nicht am Bauchgefühl, sondern an der Schutzklasse der Daten. Deshalb steht am Anfang jedes seriösen Projekts die Klassifizierung. Wo nicht klassifiziert wurde, gilt im Zweifel die strengste Klasse, das ist kein Detail, sondern der Ausgangspunkt. Öffentliche und interne Verwaltungstexte? Eine EU-Plattform reicht oft. Seelsorge- oder Gesundheitsdaten? Eigener Server, im Zweifel ohne externe Datenverbindung.

Der häufigste Fehler ist, das zu vermischen. Einen Gemeindebrief über einen abgeschotteten Server laufen zu lassen, ist verschwendete Mühe. Seelsorgedaten über eine beliebige Cloud zu schicken, ist ein Datenschutzverstoß. Die eigentliche Architekturarbeit besteht darin, beides sauber zu trennen, und für unterschiedliche Datenklassen unterschiedliche Wege vorzusehen, statt einer Universallösung.

Warum offene Modelle hier wichtig sind

Wer auf quelloffene Modelle setzt, bleibt beweglich: dasselbe Modell kann in der EU-Cloud oder auf dem eigenen Server laufen. Man verwettet das Projekt nicht auf einen einzelnen US-Anbieter und dessen Preise, Verfügbarkeit und Rechtslage.

Das kirchliche Datenschutzrecht, die geforderte Risikoabwägung, die verbindliche Exit-Strategie, die Voreinstufung nicht klassifizierter Verarbeitungen in die strengste Klasse, drängt genau auf diese Disziplin. Das ist eine Randbedingung für die Architektur. Die juristische Bewertung selbst gehört in die Hände des Datenschutzbeauftragten oder einer Kanzlei. Auf der technischen Seite besteht die Aufgabe darin, das System so zu bauen, dass es diese Bedingungen von vornherein erfüllt, statt sie später nachzurüsten.