Neue KI-Modelle erscheinen inzwischen fast im Wochentakt. In Unternehmen verschiebt sich die Diskussion deshalb weg von der Frage, welches Modell die besten Antworten liefert, hin zu einer nüchterneren: Wo werden die Daten eigentlich verarbeitet, und unter welchem rechtlichen und technischen Rahmen geschieht das? Für Organisationen mit personenbezogenen oder geschäftskritischen Daten wird genau das zum entscheidenden Auswahlkriterium.

Zwei aktuelle Fachbeiträge beleuchten dieselbe Entwicklung aus unterschiedlichen Richtungen. Der eine nimmt das rechtssichere Hosting von KI-Agenten in den Blick, also von Anwendungen, die Aufgaben eigenständig in mehreren Schritten abarbeiten. Der andere zeigt, dass sich kleinere Aufgaben heute bereits mit lokal installierten Modellen erledigen lassen – ganz ohne Cloud. Gemeinsam ergibt das ein Bild: Die US-Cloud ist längst nicht mehr die einzige Option.

Die Betriebsfrage entscheidet über das Projekt

In vielen Projekten wird die Betriebsfrage zu spät gestellt. Ein Prototyp entsteht mit einem beliebigen API-Zugang, funktioniert überzeugend – und scheitert anschließend an der internen Prüfung, weil unklar ist, welche Inhalte den Verantwortungsbereich des Unternehmens verlassen. Besonders heikel ist das bei Agenten, weil diese nicht nur einzelne Eingaben verarbeiten, sondern im Verlauf ihrer Arbeitsschritte auf Dokumente, Datenbanken oder E-Mails zugreifen können. Damit wächst die Menge der übermittelten Daten oft schneller, als es die ursprüngliche Freigabe vorgesehen hat.

Aus Sicht der DSGVO sind vor allem drei Punkte relevant: der Verarbeitungsort, die Rechtsgrundlage für eine Übermittlung in Drittländer und die Frage, ob und wie lange Eingaben gespeichert oder für Trainingszwecke weiterverwendet werden. Diese Punkte sind Vertrags- und Architekturfragen, keine Modellfragen. Sie lassen sich klären, bevor die erste Zeile Code entsteht.

Weg eins: Hosting in Europa

Der erste praktikable Weg ist der Betrieb von Modellen und Agenten bei Anbietern, die innerhalb der EU verarbeiten und dies vertraglich zusichern. Der Vorteil liegt in der Skalierbarkeit: Rechenleistung wird bei Bedarf zugekauft, Modelle werden gepflegt und aktualisiert, das eigene Team muss keine GPU-Infrastruktur betreiben. Für Anwendungen mit schwankender Last oder vielen gleichzeitigen Nutzern bleibt das die naheliegende Variante.

Entscheidend ist hier die Sorgfalt bei der Auswahl. Zu prüfen sind unter anderem der tatsächliche Standort der Rechenzentren, mögliche Unterauftragsverhältnisse, die Protokollierung von Anfragen sowie die Frage, ob Eingaben vom Training ausgeschlossen sind. Ein europäischer Firmensitz allein sagt noch nichts über die Verarbeitungskette aus. Ebenso wichtig ist die technische Seite: getrennte Umgebungen für Test und Produktion, ein durchdachtes Rechtekonzept und die Möglichkeit, Anfragen und Antworten nachvollziehbar zu protokollieren, ohne dabei mehr personenbezogene Daten zu speichern als nötig.

Weg zwei: Modelle lokal betreiben

Der zweite Weg verlässt die Cloud vollständig. Für lokal ausgeführte Modelle existiert inzwischen eine ausgereifte Werkzeuglandschaft: Genannt werden etwa Ollama, LM Studio, Jan und Osaurus – Anwendungen, die offene Modelle auf dem eigenen Rechner oder auf firmeneigener Hardware ausführen. Die Bandbreite reicht dabei von Einsteigerwerkzeugen mit grafischer Oberfläche bis zu Lösungen für Fortgeschrittene, die sich in eigene Abläufe einbinden lassen.

Der Reiz ist offensichtlich: Was den Rechner nicht verlässt, muss auch nicht datenschutzrechtlich in ein Drittland übermittelt werden. Für Aufgaben wie das Zusammenfassen interner Dokumente, das Umformulieren von Texten, einfache Klassifikationen oder erste Entwürfe reicht die Qualität kleinerer Modelle in vielen Fällen aus. Hinzu kommt die Unabhängigkeit von Preis- und Modellwechseln externer Anbieter.

Realistisch bleiben sollte man bei den Grenzen. Lokale Modelle sind in der Regel kleiner als die großen Cloud-Angebote und liefern bei komplexen Aufgaben schwächere Ergebnisse. Sie benötigen ausreichend Arbeitsspeicher und möglichst eine leistungsfähige Grafikeinheit, und sie erzeugen Aufwand für Aktualisierung und Wartung. Die zitierte Einschätzung, dass sich damit vor allem kleinere Aufgaben erledigen lassen, ist deshalb keine Einschränkung im Kleingedruckten, sondern der Kern der Sache.

Meist ist es eine Mischung

In der Praxis stehen sich die beiden Wege nicht als Alternativen gegenüber. Sinnvoll ist häufig eine Aufteilung nach Datenklassen: Was besonders schutzbedürftig ist, wird lokal oder in einer eigenen europäischen Umgebung verarbeitet; für unkritische Aufgaben mit hohem Qualitätsanspruch kommt ein gehostetes Modell zum Einsatz. Voraussetzung dafür ist eine Architektur, in der das Modell austauschbar bleibt – etwa über eine eigene Zwischenschicht, die Anfragen je nach Klassifizierung an das passende Ziel weiterleitet.

Für den Einstieg haben sich einige Schritte bewährt:

  • Datenarten inventarisieren und in Schutzklassen einteilen, bevor Werkzeuge ausgewählt werden.
  • Je Anwendungsfall festlegen, welche Antwortqualität wirklich nötig ist – nicht jede Aufgabe braucht das größte Modell.
  • Die Modellanbindung über eine eigene Schnittstelle kapseln, damit ein Wechsel keine Neuentwicklung auslöst.
  • Bei Agenten die Zugriffsrechte auf Datenquellen eng fassen und jeden Arbeitsschritt nachvollziehbar machen.
  • Lokale Varianten früh auf echter Hardware testen, um Antwortzeiten und Ressourcenbedarf zu kennen.

Was das für Projekte bedeutet

Für Web- und Softwareprojekte heißt das: Die Frage nach dem Betriebsort gehört in die Anforderungsphase, nicht in die Abnahme. Wer Modellanbindungen von Anfang an austauschbar gestaltet, kann zwischen europäischem Hosting und lokalem Betrieb wechseln, ohne die Anwendung neu zu bauen. Und weil sich die Werkzeuglandschaft weiterhin schnell bewegt, ist diese Flexibilität derzeit wertvoller als die Entscheidung für ein bestimmtes Modell.

Quellen