Eigenes KI-Modell trainieren: warum du es fast nie brauchst — und welche der vier Stufen stattdessen reicht

Wenn du «eigenes KI-Modell trainieren» in eine Suchmaschine tippst, willst du in Wahrheit fast nie ein Modell trainieren. Du willst zwei Dinge: Die KI soll dein Firmenwissen kennen, und sie soll sich an deine Regeln halten. Das ist eine Beschaffungsfrage, keine Trainingsfrage. Und für diese Beschaffungsfrage gibt es vier Stufen, die sich in Aufwand und Kosten um Größenordnungen unterscheiden.

Ich schreibe diesen Ratgeber aus der Umsetzer-Perspektive: Wir bauen bei happycoding KI-Funktionen für den Mittelstand, unter anderem RAG-Systeme auf pgvector und PostgreSQL, betrieben auf EU-Infrastruktur. Die häufigste Anfrage, die uns erreicht, lautet sinngemäß: «Wir wollen eine KI mit unserem Wissen.» Die zweithäufigste: «Was kostet ein eigenes Modell?» Beide Fragen beantwortet derselbe Entscheidungsbaum, und genau den bekommst du hier.

Vorab die radikal ehrliche Kernaussage: Als Mittelständler brauchst du fast nie ein eigenes Modell. Das von Grund auf trainierte Modell ist die teuerste und langsamste der vier Stufen, und sie löst in den allermeisten Fällen nicht einmal dein Problem. Die gute Nachricht steckt im selben Satz: Die Stufe, die dein Problem tatsächlich löst, ist schneller und billiger, als du vermutlich denkst. Der Unterschied zwischen der richtigen und der falschen Stufe entscheidet darüber, ob dein Projekt in Wochen liefert oder in Monaten scheitert.

Dieser Artikel ist der Baum, nicht die Blätter: Je Stufe bekommst du die Einordnung, die Entscheidungskriterien und den Kostenrahmen mit Quelle. Die Tiefe der einzelnen Stufen, etwa den Detailvergleich RAG gegen Fine-Tuning oder die Betriebspraxis beim Selbst-Hosting, behandle ich in eigenen Folgeartikeln. Hier geht es um die eine Frage, die vor allen anderen kommt: Welche Stufe brauchst du überhaupt?

Geschrieben ist der Ratgeber für Geschäftsführer und IT-Leiter, die eine KI-Investition verantworten, ohne selbst Modelle zu bauen. Du brauchst kein technisches Vorwissen: Jeden Fachbegriff definiere ich, bevor ich ihn benutze. Und falls du es eilig hast: Der Abschnitt «Der Entscheidungsbaum» weiter unten fasst alles in vier Fragen zusammen. Die Abschnitte davor liefern die Begründungen und die Zahlen, mit denen du die Antworten intern vertreten kannst.

Zur Orientierung stelle ich dir die vier Stufen zuerst nebeneinander. Jede Stufe beantwortet eine andere Leitfrage, und jede Stufe spielt in einer anderen Kostenliga.

Stufe 1: Strukturiertes Prompting. Du nutzt ein bestehendes Modell besser: mit sauberem Kontext, Beispielen und erzwungenen Ausgabeformaten. Kostenrahmen: reine API-Nutzung, oft zweistellige bis niedrige dreistellige Eurobeträge pro Monat. Leitfrage: Reicht das Modell, wenn ich ihm alles Nötige mitgebe?

Stufe 2: RAG über deine Daten. Die KI schlägt vor jeder Antwort in deinen Dokumenten nach. Dein Wissen bleibt in deiner Datenbank, das Modell bleibt unverändert. Kostenrahmen: ein Softwareprojekt im üblichen Rahmen individueller Entwicklung, kein Trainingsbudget. Leitfrage: Scheitert die KI an fehlendem Wissen?

Stufe 3: Fine-Tuning. Du justierst ein offenes Modell mit eigenen Beispielen nach, heute praktisch immer per LoRA auf Open-Weight-Modellen. Kostenrahmen: die GPU-Kosten eines Trainingslaufs liegen bei 10 bis 20 USD, der eigentliche Aufwand steckt in Datenaufbereitung und Evaluation. Leitfrage: Scheitert die KI an Verhalten, Format oder Stil, obwohl das Wissen da ist?

Stufe 4: Eigenes Modell trainieren. Du baust ein Modell von Grund auf. Kostenrahmen: dreistellige Millionenbeträge allein für Compute, dazu Teams, die es im Mittelstand nicht gibt. Leitfrage: ehrlicherweise keine, die sich für einen Mittelständler stellt.

Quer zu diesen vier Stufen liegt eine Dimension, die oft mit ihnen verwechselt wird: der Betriebsort. Ob ein Modell bei einem US-Anbieter, bei einem EU-Anbieter oder auf deinem eigenen Server läuft, ist keine fünfte Stufe. Es ist eine Entscheidung, die du auf jeder der Stufen 1 bis 3 treffen kannst. Dazu später mehr, denn genau diese Querdimension fehlt in den meisten Ratgebern zum Thema.

Neben den Kosten unterscheiden sich die Stufen in einer zweiten Größe, die für Entscheider oft wichtiger ist: der Zeit bis zum ersten nutzbaren Ergebnis. Stufe 1 liefert in Tagen, oft an einem Nachmittag. Stufe 2 ist ein Projekt von Wochen bis wenigen Monaten, je nach Zustand deiner Dokumente. Stufe 3 hängt fast vollständig davon ab, wie schnell du saubere Beispieldaten zusammenbekommst. Stufe 4 misst sich in Jahren und Teams. Wer die Stufen von unten nach oben durchgeht, kauft sich also nicht nur den günstigeren Einstieg, sondern auch den früheren Praxistest.

Ein Hinweis zur Lesart der Zahlen in diesem Artikel: Jede Kostenangabe trägt Quelle und Jahr, volatile Preise zusätzlich das Abrufdatum. KI-Preise ändern sich schnell, und ein Ratgeber, der dir Zahlen ohne Herkunft nennt, ist keiner.

Zum Einstieg die Stufe, die kein Projekt braucht: die strukturierte Nutzung bestehender Modelle. Sie wird chronisch unterschätzt, weil sie unspektakulär klingt. Dabei erledigt sie einen erstaunlichen Teil der Aufgaben, für die Unternehmen zunächst nach «eigener KI» fragen.

Drei Techniken machen den Unterschied zwischen Spielerei und Werkzeug:

Kontext mitgeben. Moderne Modelle verarbeiten sehr lange Eingaben. Wenn deine Anfrage die relevanten Unterlagen gleich mitbringt, etwa die Produktliste, die Stilvorgaben oder den Vertragsentwurf, braucht das Modell kein «Training»: Es liest die Information einfach im Moment der Anfrage.

Few-Shot-Beispiele. Du zeigst dem Modell zwei bis fünf Beispiele für Eingabe und gewünschte Ausgabe, direkt im Prompt. Für viele Klassifikations- und Umformulierungsaufgaben reicht das: Das Modell übernimmt Muster aus Beispielen zuverlässiger als aus abstrakten Anweisungen.

Strukturierte Ausgaben. Du zwingst das Modell in ein festes Ausgabeformat, etwa ein JSON-Schema. Damit wird aus einem Chatbot ein Systembaustein, dessen Antworten deine Software direkt weiterverarbeiten kann.

Was kostet das? Zur Einordnung die Listenpreise der OpenAI-API, Abruf am 18.08.2026: GPT-5 kostet 1,25 USD je Million Eingabe-Token und 10,00 USD je Million Ausgabe-Token. Das kleinere gpt-5-mini liegt bei 0,25 und 2,00 USD, das nochmals kleinere gpt-5-nano bei 0,05 und 0,40 USD. Zwischen der größten und der kleinsten Modellklasse liegt beim Eingabepreis der Faktor 25: Die Modellwahl ist auf dieser Stufe dein größter Kostenhebel, nicht die Prompt-Länge.

Ein Beispiel macht die Stufe greifbar: Ein Unternehmen will eingehende E-Mails automatisch in die Kategorien Bestellung, Reklamation, Rechnungsfrage und Sonstiges sortieren. Der Prompt enthält die vier Kategorien mit je einer Definition, fünf Beispiel-E-Mails mit der jeweils richtigen Zuordnung und die Anweisung, ausschließlich ein JSON-Objekt mit Kategorie und Begründung zurückzugeben. Als Modell reicht dafür oft die kleinste Klasse: Bei den oben genannten nano-Preisen kostet die Klassifikation von tausend E-Mails Bruchteile eines Euros. Kein Training, keine Datenbank, kein Projektantrag: ein sorgfältig gebauter Prompt und ein API-Aufruf.

Wann reicht Stufe 1? Solange die Aufgabe kein privates Wissen braucht, das über den mitgelieferten Kontext hinausgeht. Und solange sich das Verhalten des Modells mit Anweisungen und Beispielen steuern lässt. Typische Fälle aus unserer Praxis: E-Mails nach Anliegen vorsortieren, Angebotstexte aus Stichpunkten erzeugen, Freitext in Datenbankfelder überführen.

Die Grenze erkennst du an zwei Signalen. Erstens: Du kopierst dieselben hundert Seiten Wissen in jeden Prompt, weil das Modell deine Inhalte sonst nicht kennt. Zweitens: Du feilst zum zwanzigsten Mal am Prompt, weil Form oder Tonfall der Antworten nicht sitzen wollen. Das erste Signal zeigt auf Stufe 2, das zweite auf Stufe 3.

Jetzt zur Stufe, bei der die meisten Projekte landen, die mit «eigenes Modell trainieren» starten: RAG, ausgeschrieben Retrieval-Augmented Generation. Das Prinzip in einem Satz: Bevor das Modell antwortet, sucht dein System die relevanten Passagen aus deinen Dokumenten heraus und legt sie dem Modell als Kontext vor. Die KI liest in deinem Wissen nach, statt es auswendig zu lernen.

Damit räumt RAG das häufigste Missverständnis dieser Debatte ab: Nein, das Modell lernt bei RAG nicht dauerhaft aus deinen Daten. Es wird mit keinem einzigen deiner Dokumente trainiert. Genau das ist der Vorteil, nicht der Mangel. Dein Wissen liegt in einer Datenbank, die du kontrollierst: Du kannst Dokumente aktualisieren, löschen und mit Zugriffsrechten versehen, und die nächste Antwort spiegelt den neuen Stand. Ein Modell, in das Wissen hineintrainiert wurde, kann nichts davon: Es vergisst nicht auf Kommando, es kennt keine Zugriffsrechte, und es veraltet mit jedem Tag.

So setzen wir das um: Deine Dokumente werden in Abschnitte zerlegt und als Embeddings gespeichert, also als Zahlenvektoren, die Bedeutung abbilden. Als Vektordatenbank nutzen wir pgvector, eine Erweiterung von PostgreSQL: Dein Wissen liegt damit in derselben Datenbank wie deine übrigen Anwendungsdaten, mit denselben Backups und denselben Zugriffsregeln. Betrieben wird das Ganze bei uns typischerweise auf Supabase oder direkt auf EU-Servern. Der Punkt dieser Details ist nicht Technikstolz: Er ist, dass RAG ein gewöhnliches Softwareprojekt ist. Datenbank, Pipeline, Suche, Anzeige: alles Handwerk, kein Forschungslabor.

Wann ist RAG die richtige Stufe? Wenn die KI an fehlendem Wissen scheitert: Sie kennt deine Produkte nicht, deine Verträge nicht, deine internen Abläufe nicht. Wenn sich dieses Wissen laufend ändert, ist RAG sogar die einzige vernünftige Wahl, denn eine Dokumentenänderung ist ein Datenbank-Update und kein neuer Trainingslauf.

Zwei Entscheidungskriterien solltest du vor dem Start ehrlich prüfen. Erstens die Datenlage: RAG kann nur finden, was auffindbar vorliegt. Ein Wissensbestand aus veralteten Ordnerkopien, gescannten Faxen und drei konkurrierenden Versionen derselben Preisliste liefert auch mit der besten Suche widersprüchliche Antworten. Die Aufräumarbeit vor dem Projekt ist deshalb Teil des Projekts. Zweitens die Nachvollziehbarkeit: Ein gutes RAG-System zeigt zu jeder Antwort die Fundstellen an. Für den Mittelstand ist das mehr als Komfort, denn eine Antwort mit Quellenangabe können deine Mitarbeiter prüfen, eine ohne müssen sie glauben.

Die Abgrenzung zum Fine-Tuning, also die Frage «Wissen nachschlagen oder Verhalten antrainieren», hat so viele Facetten, dass sie einen eigenen Artikel verdient: Der Vergleich RAG gegen Fine-Tuning folgt hier im Blog. Für den Entscheidungsbaum reicht die Kurzform:

Weiter zur Stufe, um die sich die meisten Mythen ranken: Fine-Tuning, das Nachtrainieren eines bestehenden Modells mit eigenen Beispielen. Vorab die Einordnung: Fine-Tuning ist deutlich seltener die Antwort, als der Begriff suggeriert. Es beantwortet nicht die Frage «Wie bekommt die KI mein Wissen?», sondern die Frage «Wie bekommt die KI mein Verhalten?». Wissen gehört in RAG. Fine-Tuning gewinnt in drei konkreten Fällen:

Format- und Stiltreue. Das Modell soll eine sehr spezifische Ausgabeform absolut zuverlässig treffen: die Gliederung deiner Gutachten, die Tonalität deiner Korrespondenz, eine hauseigene Auszeichnungssprache. Anweisungen im Prompt erreichen hier oft 95 Prozent, Fine-Tuning schließt die Lücke.

Klassifikation mit engem Ausgaberaum. Tausende Eingaben sollen in ein festes Schema sortiert werden, etwa Support-Tickets in dreißig Kategorien. Ein kleines, feinjustiertes Modell schlägt hier häufig ein großes Allzweckmodell: in Trefferquote, Geschwindigkeit und Preis.

Latenz- und Kostendruck bei hohem Volumen. Wenn ein kleines Open-Weight-Modell nach dem Fine-Tuning die Aufgabe eines großen API-Modells übernimmt, sinken Stückkosten und Antwortzeiten. Das rechnet sich erst ab erheblichem Anfragevolumen, dann aber dauerhaft.

Technisch heißt Fine-Tuning heute in aller Regel: LoRA beziehungsweise verwandte PEFT-Verfahren auf einem Open-Weight-Modell wie Llama, Mistral, Qwen oder Gemma. LoRA trainiert nicht das ganze Modell neu, sondern legt kleine Zusatzmatrizen über die bestehenden Gewichte: Der Rechenaufwand fällt dadurch um Größenordnungen. Wie viele Beispiele du brauchst, hängt vom Fall ab: Für Stil- und Formatanpassungen genügen nach verbreiteten Praxiswerten oft wenige hundert kuratierte Beispielpaare, für engere Fachaufgaben eher tausend bis fünftausend. Wichtiger als die Menge ist die Qualität: Ein widersprüchlicher Datensatz trainiert dir die Widersprüche zuverlässig mit an.

Genauso wichtig wie die Gewinn-Fälle sind die Verlust-Fälle. Fine-Tuning verliert, wenn du damit Wissen einlagern willst: Fakten, die sich ändern, gehören in RAG, denn ein einmal antrainierter Stand veraltet und lässt sich nicht selektiv korrigieren. Es verliert auch, wenn deine Beispieldaten dünn oder uneinheitlich sind: Dann verstärkt der Trainingslauf das Rauschen statt des Musters. Und es verliert immer dann, wenn ein besserer Prompt dasselbe Ergebnis gebracht hätte: Diese Prüfung ist unbequem, weil sie das kleinere Projekt zur richtigen Antwort macht, aber genau dafür steht Frage 1 im Entscheidungsbaum.

Nun die Rechnung, die viele überrascht. Eine H100-GPU mit 80 GB kostet in der Miete je nach Cloud-Variante 1,99 bis 2,89 USD pro Stunde, eine A100 mit 80 GB liegt bei 1,19 bis 1,59 USD (Runpod-Preisliste, Abruf 18.08.2026). Ein LoRA-Lauf auf einem Modell der 7-bis-8-Milliarden-Parameter-Klasse braucht auf einer einzelnen H100 typischerweise wenige Stunden. Rechne selbst: vier bis sechs Stunden mal rund zwei bis drei USD ergeben etwa 10 bis 20 USD reine GPU-Kosten pro Trainingsiteration.

Der Compute ist beim Fine-Tuning also der billigste Posten der ganzen Rechnung. Teuer sind die Personentage davor und danach: Beispieldaten sammeln, bereinigen, kuratieren, und anschließend sauber messen, ob das feinjustierte Modell wirklich besser ist als das Basismodell mit gutem Prompt. Wer diese Evaluation weglässt, betreibt kein Fine-Tuning, sondern Hoffnung.

An dieser Stelle ein Einschub, der für deine Planung wichtiger ist als jede Technikfrage: Falls du Fine-Tuning bisher als «ich lade meine Daten bei OpenAI hoch»-Dienstleistung kanntest, ist dieses Modell auf dem Weg nach draußen. OpenAI wickelt die eigene Self-Serve-Fine-Tuning-Plattform ab. Die Timeline steht in der offiziellen Deprecation-Übersicht (developers.openai.com, abgerufen am 18.08.2026) und liest sich so:

Seit dem 07.05.2026: Organisationen, die Fine-Tuning zuvor nicht genutzt haben, erhalten keinen Zugang mehr.

Seit dem 02.07.2026: Organisationen, die in den vorangegangenen 60 Tagen keine Inferenz auf einem ihrer feinjustierten Modelle ausgeführt haben, können keine neuen Trainingsjobs mehr anlegen.

Ab dem 06.01.2027: Auch aktive Bestandskunden können keine neuen Fine-Tuning-Jobs mehr starten. Bestehende feinjustierte Modelle laufen weiter, aber nur, bis das jeweilige Basismodell selbst abgekündigt wird.

Ein Nachfolgeprodukt nennt OpenAI nicht. Was folgt daraus? Wer heute eine Fine-Tuning-Strategie auf einer gehosteten Plattform aufbaut, baut auf einer Plattform, deren größter Anbieter gerade den Rückzug antritt. Das ist kein Randdetail, sondern ein Architekturargument: Fine-Tuning heißt heute Open-Weight-Modelle, deren Gewichte du besitzt und deren Trainingsstand dir niemand abschalten kann. Genau deshalb beschreibe ich Stufe 3 oben als LoRA auf offenen Modellen und nicht als Knopf in einem API-Dashboard.

Für dich als Entscheider ist das im Kern eine gute Nachricht: Die offene Variante ist nicht nur die zukunftssichere, sie ist mit gemieteter GPU-Stunde auch transparent kalkulierbar. Du tauschst die Bequemlichkeit einer Plattform gegen Eigentum an deinem wichtigsten Projektergebnis: dem trainierten Modellstand samt der kuratierten Trainingsdaten.

Daraus ergibt sich eine Prüffrage für jedes Angebot, das dir Fine-Tuning verspricht: Wem gehören hinterher die Gewichte, und auf welcher Plattform entsteht der Trainingsstand? Lautet die Antwort «auf der gehosteten Plattform eines Anbieters», frag nach, was mit deinem Investment geschieht, wenn dieser Anbieter das Produkt abkündigt. Die OpenAI-Timeline oben ist der Beleg, dass diese Frage keine Theorie ist: Sie hat ein Datum.

Kommen wir zur Stufe, nach der dieser Artikel benannt ist: ein Modell von Grund auf trainieren, im Fachjargon Pre-Training. Hier lasse ich einfach die Zahlen sprechen, und zwar belegte.

Der Stanford AI Index Report 2024 beziffert die Compute-Kosten großer Trainingsläufe auf Basis von Schätzungen des Forschungsinstituts Epoch AI. Drei Datenpunkte zeichnen die Kurve: Das Training des Original-Transformers von 2017, der Architektur hinter der heutigen Modellgeneration, kostete rund 930 USD. Das Training von GPT-4 kostete rund 78,4 Millionen USD. Das Training von Gemini Ultra kostete rund 191,4 Millionen USD. Von dreistellig zu neunstellig in sieben Jahren: Das ist die Preisentwicklung an der Spitze, allein für Rechenzeit, ohne Gehälter, ohne Daten, ohne die vielen Läufe, die scheitern.

Ein vierter Datenpunkt macht die Sache für den Mittelstand endgültig eindeutig. Der AI Index Report 2025 schätzt, abermals auf Basis von Epoch AI, die Trainingskosten von Llama 3.1 405B auf rund 170 Millionen USD. Das Bemerkenswerte daran: Llama 3.1 ist ein Open-Weight-Modell. Meta hat 170 Millionen USD in einen Trainingslauf investiert und stellt dir die fertigen Gewichte kostenlos zur Verfügung. Du kannst das Ergebnis eines neunstelligen Investments herunterladen, auf europäischen Servern betreiben und per LoRA an deinen Fall anpassen.

Dazu kommt, was in den Compute-Schätzungen noch gar nicht steckt. Ein Pre-Training-Vorhaben braucht ein Forschungsteam, das du gegen die Gehälter der KI-Labore rekrutieren müsstest. Es braucht Trainingsdaten in einem Umfang und einer Qualität, die kein Mittelständler besitzt. Und es braucht die Bereitschaft, gescheiterte Läufe abzuschreiben, denn der erste Versuch sitzt bei niemandem. Die publizierten Zahlen beziffern jeweils einen gelungenen Lauf: Die Gesamtrechnung eines Programms liegt darüber.

Damit beantwortet sich die Leitfrage der Stufe 4 von selbst. Welcher betriebswirtschaftliche Grund könnte einen Mittelständler rechtfertigen, neunstellig in einen eigenen Trainingslauf zu investieren, dessen Ergebnis hinter frei verfügbaren Modellen zurückbliebe? Mir ist in der Praxis keiner begegnet. Es gibt Nischen für spezialisiertes Pre-Training, etwa in der Pharmaforschung oder bei Staaten mit Souveränitätsprogrammen. Für ein mittelständisches Unternehmen mit dem Ziel «KI mit unserem Wissen und unseren Regeln» ist Stufe 4 keine Option, sondern eine Kategorienverwechslung.

Zum Thema, das in den vier Stufen bisher nur anklang: Wo läuft das alles? Diese Frage wird in vielen Ratgebern mit der Stufenfrage vermengt, dabei ist sie davon unabhängig. Ob du promptest, RAG betreibst oder feinjustierst: Jede dieser Stufen kannst du gegen eine US-API fahren, gegen einen EU-Anbieter, oder mit einem selbst gehosteten Open-Weight-Modell auf eigener Infrastruktur. Die Stufe bestimmt, was mit dem Modell geschieht. Die Querdimension bestimmt, wer dabei deine Daten sieht.

Für viele Mittelständler ist diese Dimension der eigentliche Auslöser der Suche nach dem «eigenen Modell»: Es geht gar nicht um Training, sondern um Datenhoheit. Patientendaten, Konstruktionsdaten, Mandanteninformationen: Es gibt Datenbestände, die ein Unternehmen keinem US-Dienst anvertrauen will oder darf. Die Antwort darauf ist aber nicht Stufe 4, sondern die Querdimension: ein offenes Modell auf europäischer Infrastruktur betreiben und darüber jede der Stufen 1 bis 3 fahren. Was dabei datenschutzrechtlich zu beachten ist, habe ich im Praxisleitfaden zu DSGVO-konformer KI beschrieben.

Die Querdimension hat dabei mehr als zwei Einstellungen. Zwischen «US-API» und «eigener Server» liegen Abstufungen: europäische Modellanbieter mit API-Zugang, EU-Rechenzonen großer Cloud-Anbieter mit vertraglichen Zusicherungen, gemanagte GPU-Instanzen bei europäischen Hostern. Welche Abstufung du brauchst, bestimmen deine Daten und deine Rechtsberatung, nicht die Technik. Wichtig für die Entscheidung ist nur: Du musst diese Frage getrennt von der Stufenfrage beantworten, denn jede Kombination ist baubar.

Was kostet Selbst-Hosting? Ein konkreter Anker: Hetzner bietet mit dem GEX131 einen dedizierten GPU-Server mit einer RTX PRO 6000 Blackwell Max-Q und 96 GB Grafikspeicher für 889 Euro im Monat an, ohne Einrichtungsgebühr (Hetzner-Pressemitteilung vom 11.12.2025). Auf so einer Karte laufen quantisierte Open-Weight-Modelle mittlerer Größe in produktiv nutzbarer Geschwindigkeit.

Ob sich das gegen die API rechnet, ist keine Glaubensfrage, sondern eine Formel: Selbst-Hosting lohnt sich, wenn deine monatlichen API-Kosten, also dein Token-Volumen mal Preis je Million Token, dauerhaft über Servermiete plus Betriebsaufwand liegen. Bei stark schwankender Last gewinnt meist die API, bei konstant hoher Last oder harten Datenhoheits-Anforderungen das eigene Hosting.

Rechne mit deinen Zahlen, nicht mit meinen: Beide Preisseiten ändern sich laufend, weshalb ich dir hier bewusst eine Formel statt einer Break-even-Zahl gebe.

Mehr dazu, von der Modellwahl bis zum Betrieb, gehört in einen eigenen Artikel: «LLM selbst hosten» folgt hier im Blog. Für den Entscheidungsbaum genügt: EU-Selbst-Hosting ist keine fünfte Stufe, sondern ein Schieberegler, den du auf jeder Stufe stellen kannst.

Ein Aspekt fehlt in praktisch jedem Ratgeber zum Modell-Training, und er kann teurer werden als jede GPU-Rechnung: die Frage, ab wann du rechtlich selbst zum Modell-Anbieter wirst. Die europäische KI-Verordnung kennt für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck, kurz GPAI, eigene Pflichten: technische Dokumentation, Transparenz zu Trainingsdaten, Urheberrechts-Vorkehrungen. Wer ein fertiges Modell nur nutzt, trägt diese Pflichten nicht. Aber wer ein Modell wesentlich verändert, kann in die Anbieterrolle hineinwachsen.

Wo die Grenze liegt, ist derzeit nur indikativ umrissen. Die EU-Kommission nennt in ihren GPAI-Leitlinien vom 18.07.2025 als Orientierung ein Compute-Kriterium: Wer für die Veränderung eines Modells mehr als ein Drittel des ursprünglichen Trainings-Computes aufwendet, soll demnach als Anbieter des veränderten Modells gelten.

Wichtig ist die exakte Etikettierung dieser Zahl: Es handelt sich um eine indikative Größe aus den unverbindlichen GPAI-Leitlinien der EU-Kommission vom 18.07.2025, nicht rechtsverbindlich. Ich reiße die Frage hier bewusst nur an und verzichte auf jede eigene Rechtsauslegung: Die Einordnung der KI-Verordnung für Auftraggeber findest du in meinem Artikel zum EU AI Act für Software-Auftraggeber, verbindliche Antworten für deinen Einzelfall gibt dir eine Kanzlei.

Warum erwähne ich die Frage dann überhaupt, wenn sie für dich kaum je greift? Aus zwei Gründen. Erstens gehört sie in jede seriöse Beratung zur Stufe 3, denn «kann ich dadurch Anbieterpflichten auslösen?» ist eine legitime Sorge, die du nicht erst vom Wettbewerber hören solltest. Zweitens zeigt sie ein Muster, das den ganzen Entscheidungsbaum bestätigt: Je höher die Stufe, desto mehr Verantwortung wandert zu dir herüber, technisch wie rechtlich.

Für den Entscheidungsbaum bleibt eine beruhigende Feststellung: Ein LoRA-Fine-Tuning verbraucht einen winzigen Bruchteil des ursprünglichen Trainings-Computes und liegt damit weit unterhalb dieser indikativen Schwelle. Die Rechtsfrage ist also kein Grund, auf Stufe 3 zu verzichten. Sie ist ein Grund, sie bewusst zu dokumentieren: Wer festhält, was er mit welchem Aufwand am Modell verändert hat, kann die Frage nach der Anbieterrolle später mit Fakten beantworten statt mit Achselzucken.

Bevor wir die Fragen des Entscheidungsbaums durchgehen, räume ich drei Missverständnisse aus, die uns in Erstgesprächen regelmäßig begegnen. Jedes davon schickt Projekte auf eine teurere Stufe, als sie brauchen, oder auf eine billigere, als sie vertragen.

«Die KI lernt doch aus unseren Daten mit.» Bei den Stufen 1 und 2: nein. Ein API-Aufruf und eine RAG-Abfrage verändern das Modell nicht, dein Wissen wird gelesen, nicht gelernt. Verwechselt wird das gern mit der Frage, ob ein Anbieter Eingaben zur Modellverbesserung verwenden darf: Das ist eine Vertragsfrage, die du in den Datenverarbeitungsbedingungen regelst, keine Eigenschaft der Technik. Wer aus Angst vor «Mitlernen» direkt zum eigenen Modell springt, löst ein Vertragsproblem mit einem Millionenbudget.

«Ein trainiertes Modell ist die sicherste Form der Datenhoheit.» Eher das Gegenteil ist richtig. In ein Modell hineintrainierte Information kennt keine Zugriffsrechte: Ein feinjustiertes Modell kann jedem Nutzer alles ausplaudern, was es je gelernt hat, dem Praktikanten die Gehaltsliste inklusive. Ein RAG-System dagegen prüft vor jeder Antwort, welche Dokumente der anfragende Nutzer sehen darf. Datenhoheit entsteht durch Betriebsort und Zugriffskontrolle, nicht durch Training.

«Fine-Tuning bringt dem Modell unser Firmenwissen bei.» Der Klassiker. Fine-Tuning prägt Verhalten: Form, Ton, Klassifikationsschärfe. Als Wissensspeicher ist es unzuverlässig und unwartbar, denn Fakten lassen sich weder gezielt aktualisieren noch gezielt löschen. Wissen gehört in die Datenbank der Stufe 2, Verhalten in die Beispieldaten der Stufe 3. Wer beides vermischt, bekommt ein Modell, das selbstbewusst veraltete Preise nennt: im richtigen Tonfall, mit falschem Inhalt.

Jetzt führe ich die Stufen zum eigentlichen Werkzeug zusammen: vier Leitfragen, die dich in der Reihenfolge der Kosten von unten nach oben durch die Stufen führen. Geh sie der Reihe nach durch, und bleib bei der ersten Stufe stehen, die dein Problem löst.

Ein Wort zur Anwendung, bevor die Fragen kommen: Stell sie pro Anwendungsfall, nicht pro Unternehmen. «Wir führen KI ein» ist keine beantwortbare Frage, «unser Support soll Antworten mit Quellenangabe aus den Handbüchern bekommen» ist eine. Wenn du drei Anwendungsfälle hast, läufst du den Baum dreimal, und es ist völlig normal, dabei auf verschiedenen Stufen zu landen.

Frage 1: Löst ein bestehendes Modell die Aufgabe, wenn du ihm alles Nötige mitgibst? Probier es ernsthaft aus: mit sauberem Kontext, Few-Shot-Beispielen und strukturierter Ausgabe. Wenn ja, bist du fertig, und zwar auf Stufe 1. Diese Frage wird erstaunlich oft übersprungen, weil ein API-Aufruf nach zu wenig Projekt aussieht.

Frage 2: Scheitert das Modell an fehlendem Wissen? Es kennt deine Produkte, Verträge oder Abläufe nicht, und dieses Wissen passt nicht dauerhaft in jeden Prompt? Dann ist RAG deine Stufe: Das Wissen kommt in eine durchsuchbare Datenbank, das Modell bleibt unangetastet. Das ist der Normalfall im Mittelstand.

Frage 3: Scheitert das Modell an Verhalten, Format oder Stil, obwohl das Wissen vorliegt? Die Antworten sind inhaltlich richtig, aber in Form, Tonalität oder Klassifikationsschärfe daneben, und Prompt-Beispiele schließen die Lücke nicht? Dann, und erst dann, ist Fine-Tuning dran: als LoRA auf einem Open-Weight-Modell, mit sauberer Evaluation gegen das Basismodell.

Frage 4: Muss die Verarbeitung zwingend unter deiner Datenhoheit stattfinden? Diese Frage stellst du nicht nach den anderen, sondern neben ihnen: Sie entscheidet nicht über die Stufe, sondern über den Betriebsort. Lautet die Antwort ja, betreibst du die gewählte Stufe mit einem offenen Modell auf EU-Infrastruktur.

Und Stufe 4, das Training von Grund auf? Sie taucht im Baum nicht als Frage auf, weil ihr im Mittelstand keine realistische Antwort entspricht: Die Zahlen aus dem vorletzten Abschnitt schließen sie praktisch aus, und die frei verfügbaren Open-Weight-Modelle nehmen ihr den letzten verbliebenen Grund.

Der Baum liefert dir eine Stufe pro Problem, aber reale Systeme kombinieren oft mehrere Stufen, weil sie mehrere Probleme lösen. Drei Muster kommen in der Praxis immer wieder vor, und alle drei bleiben deutlich unterhalb der Stufe 4.

RAG plus strukturiertes Prompting. Das Standardmuster: Die Suche der Stufe 2 liefert die Fundstellen, die Techniken der Stufe 1 formen daraus die Antwort, etwa als kurze Einschätzung mit Quellenliste im festen JSON-Format. Fast jedes Wissenssystem, das wir bauen, ist genau diese Kombination. Sie zeigt auch, warum Stufe 1 nie verschwendete Arbeit ist: deine Prompts leben im RAG-System weiter.

RAG plus feinjustiertes Kleinmodell. Wenn ein Wissenssystem sehr hohes Anfragevolumen erreicht, kann ein per LoRA feinjustiertes kleines Modell die Antwortformung vom großen API-Modell übernehmen: Das Wissen kommt weiter aus der Datenbank, das Verhalten aus dem Fine-Tuning, die Stückkosten sinken. Dieses Muster ist der häufigste seriöse Fine-Tuning-Fall, den wir sehen, und er entsteht als Ausbau eines laufenden RAG-Systems, nicht als Erstprojekt.

Jede Stufe plus EU-Betrieb. Die Querdimension legt sich über beide Muster: Dasselbe RAG-System läuft wahlweise gegen eine API oder gegen ein selbst gehostetes Open-Weight-Modell auf europäischen Servern. Sauber gebaut ist das ein Konfigurationswechsel, kein Umbau. Deshalb lohnt es sich, die Datenhoheitsfrage früh zu stellen: nicht weil sie die Architektur sprengt, sondern damit die Architektur den Wechsel von Anfang an vorsieht.

Die Muster zeigen das Prinzip des ganzen Artikels im Kleinen: Du baust aus günstigen, austauschbaren Bausteinen nach oben, statt mit dem teuersten Baustein zu beginnen.

Bevor du mit dem Entscheidungsbaum in die Budgetplanung gehst, will ich eine Verzerrung geraderücken, die fast alle Kostendiskussionen prägt: Die öffentliche Debatte redet über GPU-Preise, als wären sie der Kern der Rechnung. Für die Stufen 1 bis 3 sind sie es nicht. Die 10 bis 20 USD GPU-Kosten eines LoRA-Laufs habe ich oben vorgerechnet, und auch ein RAG-System verursacht an Rechenkosten monatlich eher Beträge in Serverbudget-Höhe als in Projektbudget-Höhe.

Rechne zum Vergleich die Relationen durch: Ein einziger Beratertag kostet mehr als fünfzig LoRA-Trainingsläufe zu je 20 USD. Wer über ein KI-Projekt verhandelt und dabei um GPU-Preise feilscht, verhandelt also über den kleinsten Posten der Rechnung. Die richtige Frage an jeden Anbieter lautet stattdessen: Wie viele Personentage stecken in Datenaufbereitung und Evaluation, und wer erbringt sie?

Der tatsächliche Kostenblock sind Personentage, und zwar an drei Stellen. Datenaufbereitung: Dokumente sichten, Dubletten und veraltete Stände aussortieren, Zugriffsrechte klären, bei Fine-Tuning zusätzlich Beispielpaare kuratieren. Aus unserer Projektpraxis ist das regelmäßig der größte Einzelposten, und er lässt sich nicht wegautomatisieren, weil hier Fachwissen gefragt ist, das nur deine Leute haben.

Evaluation: ein fester Satz an Testfragen mit Soll-Antworten, gegen den jede Änderung gemessen wird. Ohne diesen Maßstab kannst du nicht wissen, ob eine Änderung Verbesserung oder Verschlimmbesserung war.

Betrieb und Pflege: Wissensbestände altern, Modelle werden abgekündigt, Prompts müssen nachgeführt werden. KI-Funktionen sind Software, und Software lebt.

Diese ehrliche Rechnung hat eine erfreuliche Konsequenz für deine Verhandlungsposition: Da der Compute günstig ist, sind die Stufen nach oben durchlässig. Wer mit RAG startet und später einen echten Fine-Tuning-Fall entdeckt, hat nichts verloren: Die kuratierten Daten und die Evaluationsfragen aus dem RAG-Projekt sind exakt die Vorarbeit, die das Fine-Tuning braucht. Der Entscheidungsbaum ist deshalb keine Einbahnstraße, sondern eine Reihenfolge: Du beginnst auf der billigsten Stufe, die dein Problem lösen könnte, und steigst nur mit Messwerten in der Hand auf.

Zum Schluss der Einordnung ein Blick in die Praxis: Wie läuft das bei uns konkret ab, wenn ein Unternehmen mit dem Wunsch nach einem «eigenen Modell» anfragt? Ein typischer Fall: ein Mittelständler mit zwanzig Jahren an Angeboten, Handbüchern und Serviceberichten, der dieses Wissen für Vertrieb und Support nutzbar machen will.

Die Anfrage lautet «eigenes Modell», die Diagnose nach dem Entscheidungsbaum lautet fast immer Stufe 2: ein RAG-System über dem Dokumentenbestand, mit sauberen Zugriffsrechten und Quellenangabe je Antwort. Manchmal kommt später ein kleiner Fine-Tuning-Baustein dazu, etwa für ein hauseigenes Berichtsformat. Ein Trainingslauf von Grund auf kam in noch keinem einzigen Projekt heraus.

Wichtig ist mir dabei die Reihenfolge: erst der Anwendungsfall, dann die Stufe, dann die Technik. Ein KI-Projekt, das mit der Technikwahl beginnt, optimiert die falsche Größe. Wie wir KI-Funktionen in Individualsoftware einbetten, von der Anforderung bis zum Betrieb, beschreibt unsere Seite zur KI-Softwareentwicklung. Liegt dein Fall eher bei wiederkehrenden Abläufen, etwa Dokumenteneingang, Datenübernahme oder Berichtswesen, findest du den passenden Einstieg unter Prozessautomatisierung.

Und falls deine eigentliche Frage ist, wie viel Entscheidungsspielraum du einer KI überlassen willst: Das ist keine Modell-Beschaffungsfrage, sondern eine Governance-Frage, die ich in der Einordnung zu Agentic AI behandle.

Noch ein Hinweis fürs Budget: Für Digitalisierungsprojekte dieser Art gibt es je nach Bundesland Zuschüsse. Was etwa Brandenburg über die BIG-Digital-Förderung beisteuert, habe ich separat aufgeschrieben. Ein RAG-Projekt auf Stufe 2 ist genau die Größenordnung, in der solche Programme spürbar wirken: Die richtige Stufe macht dein Projekt nicht nur technisch, sondern auch förderfähig kalkulierbar.

Wenn du gerade vor dieser Entscheidung stehst, schlage ich dir einen einfachen Weg vor. Erstens: Formuliere den einen Anwendungsfall, der den größten Schmerz verursacht, in zwei Sätzen. Zweitens: Geh die vier Fragen des Entscheidungsbaums durch und notiere, an welcher Stufe du hängen bleibst und ob die Datenhoheitsfrage für dich zwingend ist. Drittens: Prüfe, welche Daten für diese Stufe schon vorliegen, denn dort entsteht der echte Aufwand.

Mit diesen drei Notizen bist du besser vorbereitet als die meisten Projektanfragen, die uns erreichen: Du weißt, was du willst, welche Stufe es braucht und wo die Arbeit steckt.

Wenn du dabei eine zweite Meinung willst, sprich mit uns: Wir gehen den Entscheidungsbaum gemeinsam mit deinem konkreten Fall durch, benennen die passende Stufe und sagen dir auch dann ehrlich, dass Stufe 1 reicht, wenn Stufe 1 reicht. Das ist keine Verkaufsrhetorik, sondern Eigennutz: Projekte auf der richtigen Stufe werden fertig, und fertige Projekte sind die einzige Referenz, die zählt. Buch dir dazu ein kostenloses Erstgespräch: 30 Minuten, ohne Verkaufsdruck, mit einer klaren Empfehlung am Ende.