Was ein Framework eigentlich ist
Ein Framework ist ein vorbereiteter Rahmen für Arbeit, die sonst jedes Mal von vorn anfinge. Es bringt die immer gleichen Teile schon mit — wie Daten hineinkommen, wie ein Ablauf gesteuert wird, was passiert, wenn ein Schritt fehlschlägt — und überlässt Ihnen den Teil, der Ihr eigener ist. Das ist der ganze Zauber, und er ist weniger geheimnisvoll, als das Wort klingt.
Der Vergleich, der am besten trägt: ein Framework ist kein Werkzeugkasten, sondern eine Werkstatt. Im Werkzeugkasten suchen Sie sich zusammen, was Sie brauchen, und bauen die Werkbank selbst. In der Werkstatt steht sie schon da, die Steckdosen sind an der richtigen Stelle, und dafür müssen Sie sich an die Anordnung halten, die jemand anders sinnvoll fand.
Genau daraus folgt die wichtigste Eigenschaft: Ein Framework nimmt Ihnen Entscheidungen ab, die Sie sonst treffen müssten — und nimmt Ihnen damit auch Entscheidungen weg, die Sie vielleicht anders getroffen hätten. Deshalb lohnt es sich, zu wissen, welche Art Sie vor sich haben.
Drei Familien, die oft verwechselt werden
Wenn in einem Gespräch das Wort „KI-Framework“ fällt, meinen zwei Leute am Tisch oft zwei völlig verschiedene Dinge. Es hilft, drei Familien zu trennen, die wenig miteinander zu tun haben außer dem Namen.
Die drei Familien im Überblick:
- Klassisches maschinelles Lernen und Deep Learning: PyTorch, TensorFlow, Keras, Scikit-learn. Damit werden Modelle trainiert — ein Netz lernt aus Daten, Schicht für Schicht, Durchlauf für Durchlauf. Das ist die Welt, in der man von Epochen, Verlustfunktionen und Grafikkarten spricht.
- Sprachmodelle und Agenten: LangChain, LlamaIndex, CrewAI, AutoGen, das Claude Agent SDK. Hier wird nichts trainiert. Hier wird ein fertiges Modell angebunden, mit Ihren Daten versorgt, an Werkzeuge gehängt und in einen Ablauf eingespannt, der mehrere Schritte hat.
- Governance und Compliance: die EU-KI-Verordnung, das NIST AI Risk Management Framework, interne Richtlinien. Kein Code, sondern Regeln: welches Risiko eine Anwendung hat, was dokumentiert werden muss, wer am Ende verantwortlich ist.
Die meisten Unternehmen, die uns anrufen, brauchen aus der ersten Familie gar nichts. Sie trainieren kein Modell — sie benutzen eines. Das ist ein Unterschied wie zwischen einem Motorenwerk und einer Spedition.
Trainieren: PyTorch, TensorFlow und Co.
Diese Frameworks sind dafür gebaut, aus Daten ein Modell zu machen. Sie nehmen Ihnen die Mathematik ab, die dahintersteckt, verteilen die Rechenlast auf Grafikkarten und kümmern sich darum, dass ein Training, das achtzehn Stunden läuft, nach einem Absturz nicht bei null anfängt.
Gebraucht werden sie, wenn es für Ihre Aufgabe kein fertiges Modell gibt: eine Bildprüfung für ein Bauteil, das nur Sie herstellen; eine Vorhersage auf Messwerten aus Ihren eigenen Maschinen; eine Klassifikation auf Daten, die so sonst nirgends vorkommen. Für alles, was mit Sprache zu tun hat, ist diese Familie heute selten der erste Griff — da sind die großen Sprachmodelle schon da, und sie noch einmal nachzubauen wäre teuer und würde schlechter.
Bauen: Sprachmodelle, RAG und Agenten
Diese Familie ist die, um die es bei den meisten Projekten geht, über die wir sprechen. Das Modell existiert bereits; die Arbeit besteht darin, es an die Wirklichkeit eines Unternehmens anzuschließen.
Dafür lösen diese Frameworks drei wiederkehrende Probleme. Erstens: eigene Dokumente so aufbereiten und durchsuchbar machen, dass das Modell mit Beleg antwortet statt aus dem Gedächtnis — das ist Retrieval-Augmented Generation, kurz RAG. Zweitens: dem Modell Werkzeuge geben, damit es nicht nur redet, sondern etwas tut — eine Datenbank abfragen, eine Mail entwerfen, einen Eintrag anlegen. Drittens: mehrere Schritte zu einem Ablauf verbinden, der auch dann weiterweiß, wenn ein Schritt fehlschlägt.
Was diese Frameworks nicht lösen, ist ebenso wichtig. Sie entscheiden nicht, an welcher Stelle ein Mensch zustimmen muss. Sie sagen Ihnen nicht, ob sich der Bau überhaupt lohnt. Und sie verhindern nicht, dass ein Modell eine Zahl erfindet — das verhindern Regeln, die Sie selbst setzen, und eine Prüfung, die Sie selbst einbauen.
Regeln: Governance-Frameworks
Die dritte Familie wird am häufigsten übersehen und ist für Unternehmen oft die mit den unmittelbarsten Folgen. Die EU-KI-Verordnung ordnet Anwendungen nach Risiko: Was im Personalbereich über Bewerbungen entscheidet, steht in einer anderen Klasse als ein Werkzeug, das Produkttexte entwirft. Daraus folgen Pflichten — zur Dokumentation, zur menschlichen Aufsicht, zur Information der Betroffenen.
Das NIST AI Risk Management Framework ist der andere Pol: keine Vorschrift, sondern ein freiwilliger Rahmen aus den USA, der beschreibt, wie man Risiken einer KI-Anwendung systematisch erfasst, misst und im Betrieb im Blick behält. Viele Unternehmen nutzen es als Gerüst für ihre internen Richtlinien, weil es praktischer formuliert ist als ein Gesetzestext.
Der praktische Rat dazu ist unspektakulär: Klären Sie die Einordnung, bevor gebaut wird, nicht danach. Eine Anwendung, die fertig ist und dann durch die Risikoprüfung fällt, kostet doppelt.
Was ein Framework wirklich einspart
Die drei Vorteile, die überall genannt werden, stimmen — sie werden nur meistens zu groß erzählt.
- Zeit: Vorgefertigte Bausteine müssen nicht neu geschrieben werden. Das spart die ersten Wochen eines Projekts, nicht das Projekt.
- Einheitlichkeit: Wenn alle nach demselben Muster bauen, kann jemand anders die Arbeit übernehmen, wenn Sie im Urlaub sind. Das ist in Wahrheit der größte Gewinn, und er zeigt sich erst im zweiten Jahr.
- Wachstum: Was auf dem Laptop läuft, läuft auch auf einem Server — ohne den Code noch einmal zu schreiben. Vorausgesetzt, man hat sich beim Bauen an die Spielregeln des Frameworks gehalten.
Der ehrliche Gegenwert: Sie übernehmen die Entscheidungen von jemand anderem und binden sich an ein Projekt, das Sie nicht steuern. Deshalb achten wir bei jeder Auswahl darauf, dass der Kern der Lösung auch ohne das Framework verständlich bleibt.
Wonach Sie auswählen sollten
Die Frage lautet fast nie „Welches Framework ist das beste?“, sondern „Was ist in zwei Jahren noch wartbar?“. Vier Fragen bringen weiter als jeder Vergleich von Funktionslisten.
- Was muss gebaut werden — ein Modell trainieren oder ein vorhandenes anbinden? Die Antwort entscheidet die Familie und damit fast alles Weitere.
- Wer betreibt es später? Ein Framework, das Ihre IT kennt, schlägt ein moderneres, das niemand im Haus lesen kann.
- Wie fest bindet es? Prüfen Sie, wie viel Arbeit es wäre, das Modell oder den Anbieter zu wechseln. Wenn die Antwort „alles neu“ lautet, ist das ein Preis, der im Angebot nicht steht.
- Was verlangt die Einordnung nach der KI-Verordnung? Protokolle, Nachvollziehbarkeit und eine Stelle für die menschliche Freigabe sind leichter eingebaut als nachgerüstet.
Wie wir damit arbeiten
Wir bauen modellunabhängig und so, dass der Ablauf auch dann verständlich bleibt, wenn man das Framework wegdenkt. Jede Lösung bekommt ein Dashboard, auf dem steht, was die Agenten getan haben und was zur Entscheidung ansteht — eine Automatisierung, die man nicht beobachten kann, ist keine Lösung, sondern eine Blackbox.
Und vor dem Bau steht die Analyse. Fünfzehn Minuten über einen Ablauf, der Woche für Woche Zeit kostet, sagen mehr über die richtige Technik aus als jeder Vergleich von Frameworks — manchmal auch, dass sich der Bau nicht lohnt. Diese Antwort gehört dazu.
Häufige Fragen
Brauche ich überhaupt ein Framework?
Für einen einzelnen, klar umrissenen Schritt oft nicht — ein direkter Aufruf des Modells reicht und ist leichter zu verstehen. Sobald mehrere Schritte zusammenhängen, eigene Daten durchsucht werden oder etwas im Fehlerfall wiederholt werden muss, sparen Sie mit einem Framework mehr, als es Sie an Freiheit kostet.
Was ist der Unterschied zwischen LangChain und PyTorch?
PyTorch dient dem Training von Modellen: aus Daten wird ein Modell. LangChain setzt auf fertigen Modellen auf und verbindet sie mit Daten, Werkzeugen und Abläufen. Die beiden lösen verschiedene Aufgaben und stehen nicht in Konkurrenz zueinander.
Ist ein Open-Source-Framework sicher genug für ein Unternehmen?
Die Frage nach der Sicherheit entscheidet sich nicht am Lizenzmodell, sondern daran, wo die Daten verarbeitet werden, wer Zugriff hat und was protokolliert wird. Quelloffene Frameworks haben dabei einen Vorteil: Sie können nachsehen, was passiert, statt es zu glauben.
Was ändert die EU-KI-Verordnung für mein Projekt?
Das hängt an der Risikoklasse. Anwendungen mit geringem Risiko bringen vor allem Transparenzpflichten mit sich. Wo über Menschen entschieden wird — etwa im Personalbereich — gelten deutlich strengere Anforderungen an Dokumentation, Datenqualität und menschliche Aufsicht. Die Einordnung gehört an den Anfang eines Projekts, nicht ans Ende.
Lege ich mich mit einem Framework auf einen Modellanbieter fest?
Nicht zwangsläufig, und es ist eines der wichtigsten Auswahlkriterien. Gute Frameworks trennen den Ablauf vom Modell dahinter, sodass ein Wechsel eine Konfigurationsfrage bleibt und keine Neuentwicklung.