Neun Arten von KI
und wann Sie welche brauchen.
„Welches KI-Modell sollen wir einsetzen?" Die Frage hat schon eine Annahme eingebaut: dass es das eine KI-Modell gibt. Tatsächlich stecken in den gängigen Werkzeugen mehrere Modellklassen und Betriebsbausteine. Wer sie nicht unterscheidet, entscheidet über Kosten, Qualität und Datenschutz, ohne es zu merken.
Fast jedes Unternehmen, das mit KI ernst macht, landet früher oder später bei dieser Frage. Sie klingt nach einem sauberen Anfang und ist doch schon eine Weichenstellung. Welcher Modelltyp welche Aufgabe löst, hat an diesem Punkt kaum jemand außerhalb der Entwicklung vor Augen. Das ist kein Versäumnis. Es ist der Grund, warum die Wahl am Ende oft ohne Kriterium fällt.
Hinter dem Wort „KI” steht kein einzelnes Werkzeug, sondern ein ganzer Kasten. Die Griffe darin lösen sehr unterschiedliche Aufgaben. Wer alles mit demselben greift, zahlt drauf: mit Geld, mit Qualität oder mit einem Datenschutzrisiko, das niemand auf dem Schirm hatte.
Ein Wort, neun Aufgaben
In der Praxis lassen sich die heute relevanten Modelle und Bausteine in neun Klassen ordnen. Das ist keine amtliche Taxonomie, sondern eine Arbeitssicht, die in Projekten nützlich ist. Drei dieser Klassen sind Spezialisierungen großer Sprachmodelle. Eine weitere ist gar kein Wissensmodell, sondern eine Schutzschicht. Für Entscheidungen im Unternehmen ist diese Ordnung trotzdem hilfreicher als die akademische Frage, ob etwas „ein LLM” ist oder nicht.
Drei Gruppen helfen beim Sortieren: Modelle, die Sprache, Bilder und Probleme verstehen. Modelle, die Medien erzeugen oder umwandeln. Und Bausteine, die Wissen anbinden und den Betrieb kontrollieren.
Was die neun Klassen leisten
| Typ | Eingabe → Ausgabe | Wofür |
|---|---|---|
| Verstehen & lösen | ||
| Large Language Model | TextText | Schreiben, Zusammenfassen, Übersetzen, Fragen beantworten |
| Reasoning-Modell | AufgabeLösungsweg | Mehrstufige Planung, Optimierung, Fehlersuche |
| Code-Modell | AnforderungCode | Software von der Funktion bis zur SQL-Abfrage |
| Vision-Modell | BildVerständnis | Fotos, Screenshots, Diagramme, Scans lesen |
| Medien wandeln | ||
| Bildgenerierung | TextBild | Neue Bilder erzeugen oder bestehende verändern |
| Speech-to-Text | SpracheText | Transkription, etwa von Meetings |
| Text-to-Speech | TextSprache | Vorlesen mit natürlicher Stimme |
| Kontrolle & Wissen | ||
| Embeddings | Text/BildVektoren | Semantische Suche, passende Dokumente finden |
| LLM Guard | Ein-/AusgabePrüfung | Schutzschicht gegen PII, unerlaubte Inhalte, Prompt Injection |
Die erste Gruppe arbeitet mit Sprache, Logik und visueller Wahrnehmung. Das Large Language Model ist der allgemeine Sprachkern: Text rein, Text raus. Es schreibt, fasst zusammen, übersetzt und beantwortet Fragen. Ein Reasoning-Modell ist darauf optimiert, mehrstufige Aufgaben zu lösen, bei denen Zwischenschritte voneinander abhängen, etwa Planung, Optimierung oder technische Fehlersuche. Ein Code-Modell ist auf Software spezialisiert, von der einzelnen Funktion bis zur SQL-Abfrage. Ein Vision-Modell versteht Bilder: Fotos, Screenshots, Diagramme oder gescannte Dokumente.
Die zweite Gruppe wandelt Formate. Bildgenerierung erzeugt aus einer Beschreibung ein neues Bild oder verändert ein vorhandenes. Speech-to-Text macht aus gesprochener Sprache geschriebenen Text, die Grundlage jeder Meeting-Transkription. Text-to-Speech geht den umgekehrten Weg und spricht Text als natürliche Stimme aus.
Die dritte Gruppe steht selten im Rampenlicht, entscheidet aber über Verlässlichkeit. Embeddings übersetzen Text oder Bilder in Zahlenvektoren, sodass Software Bedeutung vergleichen kann. Sie sind der Motor hinter semantischer Suche und hinter dem Verfahren, mit dem ein KI-System passende interne Dokumente findet, bevor es antwortet. Der LLM Guard schließlich ist die Kontrollinstanz. Er prüft Ein- und Ausgaben auf personenbezogene Daten, unerlaubte Inhalte oder Manipulationsversuche wie Prompt Injection. Kein Wissensmodell, sondern eine Schutzschicht, die über ein kleines Modell laufen kann, aber genauso über klare Regeln.
Die teuren Verwechslungen
Der Wert dieser Unterscheidung zeigt sich dort, wo sie fehlt. Drei Verwechslungen sehe ich immer wieder.
Der typische Satz im Termin lautet: „Wir brauchen ein Modell, das unsere PDFs kennt.” Technisch ist das fast nie ein einzelnes Modell. Meist geht es um ein Sprachmodell, eine Suche über Embeddings, ein Zugriffskonzept und eine Schutzschicht. Wer das als eine Modellentscheidung behandelt, vergleicht am Ende Produkte, die gar nicht dieselbe Aufgabe lösen.
Die erste Verwechslung kostet Geld. Ein Reasoning-Modell für eine simple Zusammenfassung einzusetzen ist, als ließe man einen Statiker die Einkaufsliste schreiben. Reasoning-Modelle arbeiten mit zusätzlichen Reasoning-Tokens, und je höher der Reasoning-Aufwand, desto stärker steigen Latenz und Tokenverbrauch. Ein Blick auf aktuelle API-Preise zeigt außerdem, wie weit Mini-, Standard- und Pro-Modelle preislich auseinanderliegen können. Umgekehrt liefert ein einfaches Modell bei echter mehrstufiger Planung zu schwache Ergebnisse. Die Kunst liegt in der Zuordnung, nicht im teuersten Modell.
Die zweite Verwechslung kostet Wochen. Ein Modell, das Bilder versteht, ist nicht dasselbe wie eines, das Bilder erzeugt. Das eine analysiert ein Bedienpanel und liest das aktive Warnsymbol. Das andere malt ein Produktkonzept. Wer beide Aufgaben in einen Topf wirft, plant das falsche Projekt und merkt es spät.
Die dritte Verwechslung kostet im Ernstfall Reputation. Die Schutzschicht wird in vielen Konzepten schlicht vergessen. Dabei entscheidet sie, was an sensiblen Daten in das System hinein und wieder hinausgeht. Das ist zuerst eine Frage des Datenschutzes und damit der DSGVO. Der EU AI Act kommt gestaffelt dazu: Verbotene Praktiken und KI-Kompetenzpflichten gelten seit Februar 2025, GPAI-Pflichten seit August 2025, Transparenzregeln ab August 2026. Hochrisiko-Pflichten sind nach aktuellem Kommissionsstand teilweise später terminiert. Für Unternehmen heißt das nicht: warten. Es heißt: Datenflüsse, Rollen und Kontrollpunkte kennen.
Wie die Bausteine zusammenspielen
Im Alltag arbeitet selten ein Modell allein. Ein Assistent, der eine gesprochene Frage beantwortet, durchläuft mehrere Stationen. Speech-to-Text macht aus der Stimme Text. Der Guard prüft die Anfrage. Ein Embedding-Schritt holt die passenden Dokumente aus dem eigenen Wissensbestand. Ein Reasoning- oder Sprachmodell formuliert die Antwort. Der Guard prüft erneut. Text-to-Speech spricht das Ergebnis aus.
Nicht jedes System braucht alle Stationen. Aber wer die Kette kennt, erkennt schneller, an welcher Stelle ein Vorhaben hakt, statt pauschal „die KI” verantwortlich zu machen.
Die bessere erste Frage
Damit lässt sich die Ausgangsfrage neu stellen. Nicht „Welches KI-Modell nehmen wir?”, sondern: „Welche Aufgabe steht an, und welcher Modelltyp löst sie am günstigsten und verlässlichsten?” Aus einer Produktauswahl wird eine Aufgabenanalyse. Das klingt unspektakulär, spart aber genau die Kosten aus der ersten Verwechslung und verhindert die Risiken der dritten.
Für die meisten Häuser im Mittelstand ist das eine gute Nachricht. Es braucht keine vollständige Modell-Landkarte im Kopf der Geschäftsführung. Es braucht die Disziplin, vor jedem KI-Vorhaben zwei Fragen zu trennen: Welche Aufgabe lösen wir wirklich? Und welcher Modelltyp ist dafür gebaut? Wer beides sauber beantwortet, hat die eigentliche Arbeit schon halb erledigt.
Belege
Die neun Klassen sind eine pragmatische Arbeitssicht, keine offizielle Taxonomie. Für die einordnenden Aussagen:
- EU AI Act, Zeitplan und Pflichten: Europäische Kommission, AI Act.
- Reasoning-Modelle, Tokenverbrauch und Preislogik: OpenAI, Reasoning models; OpenAI API Pricing. Anbieterbeispiel, kein neutraler Marktbenchmark.
- LLM-Sicherheitsrisiken und Guardrail-Anforderungen: OWASP Top 10 for Large Language Model Applications.