Ein Unternehmen, das KI einsetzt, trifft zwei getrennte Entscheidungen: Wo läuft das Modell, und welche Daten dürfen es sehen. Die zweite Frage ist die wichtigere, und sie lässt sich unabhängig vom Anbieter beantworten. Erst wenn die Datenklassen sauber getrennt sind, wird die Infrastrukturfrage überhaupt entscheidbar.
Drei Datenklassen als Grundlage
- Öffentlich: Marketingtexte, allgemeine Recherche, Formulierungshilfen. Hier ist die Frage nach dem Ort weitgehend irrelevant.
- Intern: Angebote, Prozessbeschreibungen, interne Kommunikation. Vertraglich regelbar, aber prüfungsbedürftig.
- Sensibel: Personenbezogene Kundendaten, Gesundheits- und Finanzdaten, Vertragsinhalte Dritter, Betriebsgeheimnisse. Hier entscheidet nicht der Komfort, sondern die Rechtsgrundlage.
Wer diese Trennung nicht vornimmt, führt die Diskussion für alle Daten mit den Anforderungen der sensibelsten — und verzichtet dadurch auf Nutzen, den er risikolos hätte haben können.
Die häufigste unbemerkte Datenweitergabe ist kein Systemfehler, sondern das Kopieren in ein Chatfenster. Ohne klare Regel, welche Inhalte wohin dürfen, ist jede Architekturentscheidung wirkungslos.
Was lokal heute leistet
Offene Modelle mittlerer Größe laufen auf einer einzelnen leistungsfähigen Grafikkarte und liefern für viele betriebliche Aufgaben ausreichende Qualität: Zusammenfassen, Klassifizieren, Umformulieren, Extrahieren von Feldern aus Dokumenten, einfache Entwurfsarbeit. Für Aufgaben mit hoher Anforderung an Argumentation, Codequalität oder lange Kontexte sind die großen kommerziellen Modelle weiterhin spürbar überlegen.
Der Qualitätsabstand ist damit nicht pauschal, sondern aufgabenabhängig. Die belastbare Entscheidung entsteht nicht aus Datenblättern, sondern aus einem eigenen Test: dreißig echte Fälle aus dem Alltag, beide Wege, blind bewertet.
Die ehrliche Kostenrechnung
Cloud kostet pro Nutzung und skaliert mit dem Volumen. Lokal kostet einmalig Hardware und dauerhaft Betrieb. Der Kipppunkt liegt nicht bei einer bestimmten Nutzerzahl, sondern bei der Auslastung: Eine Karte, die nachts Dokumente verarbeitet und tagsüber Anfragen bedient, rechnet sich schnell. Eine Karte, die zu neunzig Prozent wartet, ist ein teures Statussymbol.
In die lokale Rechnung gehören Punkte, die gern fehlen: Strom und Kühlung, Ersatzteile, die Arbeitszeit für Updates und Modellwechsel, ein zweiter Rechner für Ausfallzeiten und die Person, die weiß, wie man den Dienst neu startet. Diese Betriebslast ist der eigentliche Preis der Souveränität.
Der hybride Aufbau als Normalfall
In der Praxis gewinnt selten eine reine Lösung. Bewährt hat sich eine Aufteilung entlang der Datenklassen, technisch über eine einzige interne Schnittstelle, hinter der die Zuordnung stattfindet:
- Sensible Verarbeitung, Dokumentensuche und alles mit Personenbezug läuft lokal.
- Anspruchsvolle, unkritische Aufgaben laufen über einen Cloud-Anbieter mit vertraglicher Grundlage.
- Die Anwendungen sprechen nur mit der eigenen Schnittstelle und wissen nicht, welches Modell antwortet.
Der Vorteil dieser Kapselung ist strategisch: Modelle wechseln schnell. Wer seine Anwendungen direkt an einen Anbieter bindet, baut jede Migration doppelt. Wer eine eigene Zwischenschicht hat, tauscht das Modell an einer Stelle.
Wo lokal fast immer gewinnt
Unabhängig von der Modellqualität gibt es Aufgaben, bei denen lokale Verarbeitung strukturell überlegen ist: die Indexierung großer interner Dokumentbestände, das Einbetten von Texten für die Suche, wiederkehrende Massenverarbeitung über Nacht und alles, was ohne Internetverbindung funktionieren muss. Hier zählt Durchsatz zu Fixkosten, nicht Spitzenqualität pro Anfrage.
Besonders die Suche über eigene Unterlagen ist der Fall mit dem besten Verhältnis von Aufwand und Nutzen — die Funktionsweise beschreibt der Beitrag zu Retrieval Augmented Generation.
Der Einstieg ohne Projektaufwand
Man braucht dafür kein Grundsatzpapier. Der erste Schritt ist eine Liste der zehn häufigsten KI-Anwendungsfälle im eigenen Betrieb, jeweils mit der Notiz, welche Datenklasse dabei tatsächlich im Spiel ist. Erfahrungsgemäß fällt dabei die Hälfte in die öffentliche oder interne Klasse und ist sofort umsetzbar, ohne dass irgendetwas beschafft werden muss.
Der zweite Schritt ist ein befristeter Test mit echten Fällen statt mit Demobeispielen. Zwei Wochen, feste Aufgaben, festgehaltene Ergebnisse. Erst danach steht fest, ob die Qualitätsanforderung überhaupt eine große Modellklasse verlangt oder ob ein lokal betriebenes Modell den Fall vollständig abdeckt. Diese Reihenfolge spart in der Praxis mehr Geld als jede Anbieterverhandlung.
Betrieb ist der unterschätzte Posten
Wer lokal betreibt, übernimmt Pflichten, die in der Cloud jemand anderes trägt: Aktualisierungen einspielen, Modelle austauschen, Speicher überwachen, Ausfälle bemerken und beheben. Das ist beherrschbar, muss aber jemandem gehören. Ohne benannte Zuständigkeit läuft ein lokaler Dienst so lange, bis er das erste Mal stehen bleibt — und wird danach nicht wieder gestartet.
Die Entscheidung in vier Fragen
- Welche Datenklassen sollen tatsächlich verarbeitet werden — und wie viel Anteil hat die sensible Klasse?
- Wie hoch ist das erwartete tägliche Volumen, und wie gleichmäßig verteilt es sich?
- Gibt es jemanden, der den Betrieb dauerhaft übernimmt, oder wird das nebenbei mitlaufen?
- Wie schnell muss das Ergebnis vorliegen, und was passiert bei einem Ausfall?
Wer diese vier Fragen schriftlich beantwortet, hat die Entscheidung meist schon getroffen. Was danach bleibt, ist Umsetzung — und die ist deutlich einfacher als die Grundsatzdiskussion davor.