In den vergangenen zwei Jahren habe ich gemeinsam mit Fachexperten aus der Ingenieurwelt – Prozessingenieuren, Zuverlässigkeitsingenieuren, Cybersicherheitsanalysten und anderen – LLM-gestützte Tools entwickelt, die in der täglichen Arbeit mit Logs, Spezifikationen, Schaltplänen und Berichten tief verwurzelt sind. Die Versprechen klingen verlockend: LLMs, mit ihrer umfassenden vortrainierten Wissensbasis, könnten wie Fachexperten denken, die langwierigen, musterbasierten Aufgaben in der Ingenieurarbeit beschleunigen und Experten für strategischere Entscheidungen freimachen. Doch die Praxis ist komplexer. „Einfach ein Chat-Fenster hinzufügen“ führt selten zu nützlichen, alltäglich genutzten Tools. Der Abstand zwischen einer beeindruckenden Demo und einem System, das Ingenieure vertrauen und tatsächlich nutzen, ist groß – und hängt entscheidend von der Problemstellung, der Workflow-Struktur und der Integration in die reale Arbeitsumgebung ab. Aus dieser Erfahrung habe ich zehn zentrale Lektionen für Ingenieure und Entwickler abgeleitet, die LLM-Anwendungen für fachliche Domänen bauen wollen. Zunächst: Nicht jedes Problem eignet sich für LLMs. Bevor man eine Sprachmodell-basierte Lösung wählt, sollte man prüfen, ob es nicht einfache, transparente Alternativen gibt – wie Regeln, analytische Modelle oder klassische ML-Methoden. LLMs sind besonders wertvoll, wenn es um die Verarbeitung unstrukturierter Texte, die Synthese von Berichten oder die Generierung von Kontext geht, aber sie sind teuer, langsam und unbeständig. Wenn präzise, reproduzierbare Ergebnisse nötig sind, sind klassische Modelle meist besser geeignet. Zudem: LLMs sind nur sinnvoll, wenn ein menschlicher Experte die Ausgabe überprüft. Ein zentrales Prinzip ist die Einstellung: LLMs sollen Ergänzung, nicht Automatisierung sein. Die Positionierung als „Co-Pilot“ statt „Auto-Pilot“ stärkt das Vertrauen, da Ingenieure sich nicht bedroht fühlen. Fehler werden nicht als Versagen, sondern als Anregung gesehen. Dies fördert die Akzeptanz. Gleichzeitig ist es entscheidend, mit den Experten gemeinsam zu definieren, was „besser“ bedeutet – sei es weniger Triage-Zeit, weniger Fehlalarme oder weniger manuelle Schritte. Diese Kriterien bilden die Grundlage für die Evaluation. Während der Entwicklung sollte man auf Frameworks wie LangGraph oder AutoGen nicht vorschnell setzen. In der Prototypenphase reicht oft der direkte Aufruf der LLM-APIs mit normaler Kontrollfluss-Logik. Wichtiger ist, die Workflows, Rollen und Datenflüsse zu strukturieren. Statt agenter Systeme, die sich selbst „durchkämpfen“, lohnt sich ein deterministischer, explizit mit Domänenwissen ausgestatteter Workflow. Er ist vorhersehbar, erklärbar und einfacher zu validieren. Struktur ist zentral: Eingaben und Ausgaben sollten in strukturiertem Format (z. B. JSON) verarbeitet werden. So kann der LLM zitieren, und die Ausgabe lässt sich leicht in andere Systeme integrieren. Ein weiterer Schlüssel ist die hybride Nutzung von klassischer analytischer KI und generativer KI. Anomalieerkennung, Zeitreihenanalyse oder Clustering sollten nicht durch LLMs ersetzt, sondern als Vorverarbeitungsschritte genutzt werden. Der LLM übernimmt dann die Interpretation, Erklärung und Empfehlung. So kombiniert man die Stärken beider Ansätze: Präzision und Skalierbarkeit der klassischen KI, Kreativität und Kontextverarbeitung der LLMs. Nach der Entwicklung beginnt der eigentliche Erfolg: Integration in die reale Arbeitsumgebung. Ein eigenständiger Web-App-Chatbox ist wenig wirksam. Besser: LLM-Funktionen direkt in bestehende Tools einbetten – z. B. in einen Log-Viewer mit Buttons wie „Zusammenfassung“ oder „Nächste Schritte vorschlagen“. So wird der Einsatz nahtlos. Zudem sollte der LLM seine Arbeit zeigen: welche Daten er genutzt hat, welche Schritte er gegangen ist, und mit welcher Sicherheit. Dies fördert Transparenz und Vertrauen. Die letzte Lektion: Evaluation mit echten Fällen. Nach dem Release sollten Experten realistische Szenarien gemeinsam durchlaufen, wobei sie laut denken und Feedback geben. Solche Sitzungen liefern wertvolle Erkenntnisse, die über formale Metriken hinausgehen. Zusammenfassend: Respekt vor dem Fachwissen, strukturierte Systementwicklung, und die Anerkennung, dass Deployment der Beginn, nicht das Ende, ist. LLMs sind ein Werkzeug – nicht die Lösung. Die wahre Herausforderung liegt in der Integration, dem Vertrauensaufbau und dem kontinuierlichen Lernen mit den Nutzern.