„No Hype KI“ wird unterstützt von ACP, EY, ITSV, KEBA Group, Lenovo, Microsoft, ONTEC AI und der Universität Graz.

In vielen Unternehmen sah der Einstieg in KI oft erstaunlich ähnlich aus: Ein Tool wurde lizenziert, ein POC wurde gebaut, eine Demo funktionierte – und danach begann das eigentliche Problem. Plötzlich standen Fragen im Raum, die vor dem ersten Prompt niemand gestellt hatte: Welche Daten durften überhaupt hinein? Wer trug die Verantwortung, wenn ein System falsch lag? Und was passierte, wenn „Agenten“ nicht nur Antworten formulierten, sondern Handlungen auslösten?

Um diese Fragen drehte sich die Diskussion in der zweiten Folge der brutkasten-Serie „No Hype KI“. Mit dabei waren Andreas Thomasch, CTO von Lenovo für Deutschland und Österreich, Christian Casari von ONTEC AI, Leftshift.One-Co-Founder Patrick Ratheiser und Agentic-AI-Expertin Sarah Eschenbacher.

„Will ich einen Proof of Concept machen, um meinen Vorstand zu beeindrucken?“

Gleich zu Beginn appellierte Andreas Thomasch an Unternehmen, den Blick zuerst nach innen zu richten. „Es ist wichtig, als Unternehmen erstmal ein bisschen Nabelschau zu machen und selber zu gucken, was kann ich denn selber und wie ready bin ich denn für das Thema“, sagte er. Dazu zählte er Skills, Datenstrukturen und die Umgebung, in der KI später laufen sollte.

Thomasch unterschied in der Diskussion zwischen zwei Arten von POCs: „Will ich erst einen Proof of Concept machen, um Skills aufzubauen oder will ich einen Proof of Concept machen, um meinen Vorstand zu beeindrucken?“ Beide Ziele führten in seiner Erfahrung zu völlig unterschiedlichen Projekten und zu sehr verschiedenen Erwartungen.

Patrick Ratheiser rückte den Fokus noch weiter weg von Tools. In vielen Unternehmen sah er den Reflex, sich „mal ein Tool“ zu holen und dann zu schauen, was man damit tun konnte. „Ich würde im ersten Schritt mit Hausverstand rangehen und schauen, was habe ich überhaupt für Anwendungsfälle, was habe ich für Use Cases?“, sagte er. Erst danach lohnt sich für ihn die Tool-Frage.

Technische und organisatorische Fundamente „verheiraten“

Für Sarah Eschenbacher beginnt alles mit der Problemdefinition. „Grundsätzlich brauche ich einfach ein spezifisches Problem, das ich angehen will und lösen will“, sagte sie. Dazu gehörte für sie eine klare Erfolgsmessung: „Ich muss wissen, wie ich den Erfolg dann messen kann, ob das Projekt funktioniert, ob es mir KPIs steigert.“ Ohne Datenlage, die eine Evaluation erlaubte, sah sie keinen sinnvollen Startpunkt.

ONTEC-AI-Experte Christian Casari wiederum denkt in zwei Achsen, wenn er über die Grundlagen sprach. „Man kann prinzipiell unterteilen in technische Fundamente und in organisatorische Fundamente“, sagte er. Auf der technischen Seite sah er Skills, Infrastruktur und Daten, auf der organisatorischen Seite Use Cases, KPIs und eine Organisation, die KI-Projekte tatsächlich trug. „Die beiden muss man verheiraten“, betonte er, sonst entstand in seinen Augen eine typische Schieflage: Man kauft ein Tool, aber niemand weiß, was er damit sinnvoll tun sollte.

„Die meisten Probleme kann man tatsächlich ohne Agents lösen“

Beim Thema Agents herrschte in vielen Management-Teams erkennbar Erwartungsdruck. Sarah Eschenbacher nahm diesem Hype in der Diskussion bewusst Tempo. „Auch wenn ich eine sehr hohe Begeisterung für Agents habe, glaube ich, dass man die meisten Probleme tatsächlich ohne Agents lösen kann, teilweise sogar ohne AI-basierte Automatisierungstechniken“, sagte sie.

Dabei stellt sich auch die Frage, wie sich Agents überhaupt definieren lassen. Eschenbacher lieferte eine nüchterne Definition: „Ganz unromantisch gesagt, ist ein Agent eigentlich Software, die man um ein LLM herumbaut.“ Das Modell erhält Tools, etwa API-Zugänge oder Datenbank-Schnittstellen, plant nächste Schritte, prüft Zwischenergebnisse und korrigiert sie.

Besonders sinnvoll sind Agents für die Expertin dort, wo Daten und Systeme historisch gewachsen und verstreut liegen. Mitarbeiter:innen investieren in einem solchen Szenario viel Zeit, um die richtigen Informationen zu finden. Ein spezialisierter Agent kann Systemlandschaften verbinden und etwa SQL-Abfragen übernehmen – auch wenn im Team dafür die Expertise fehlte.

„Grenzen und Risiken von Agents“

Christian Casari erinnerte daran, dass viele Menschen dieses Prinzip bereits nutzten: „Jeder verwendet ChatGPT. Wenn ich ChatGPT zu aktuellen Themen befrage, recherchiert es im Internet. Das ist eigentlich schon ein Agent“, sagte er. In einem Projekt entwickelte sein Team einen digitalen Assistenten für einen Autovermieter, der Daten aus mehreren Datenbanken kombinierte und so Anfragen beantwortete, die ein reines Dokumenten-System nicht abdecken konnte.

Je mehr Freiheit ein Agent erhält, desto größer schätzt Casari das Risiko ein. Hat ein System viele Optionen, viele Tools, viele Wege – dann hat es auch viele Fehlerquellen. Entwickler:innen müssen damit rechnen und Fallbacks planen. Er verglich die Situation mit einer neuen Mitarbeiterin, von der niemand erwartete, dass sie auf Anhieb alles richtig machte.

Patrick Ratheiser warnte zusätzlich vor falschen Versprechen auf Social Media: „TikTok-Agentic-Boys“, die in kurzen Clips ankündigen, ganze Unternehmen in wenigen Klicks automatisieren zu können. In der Realität sollte man aber zuerst prüfen, ob sich ein Problem nicht ohne KI lösen ließ – durch Prozessänderungen oder einfache Digitalisierung.

Ratheiser berichtete dabei von einem Geschäftsführer, der ein Kommunikationsproblem zwischen Sales und Produktmanagement mit einem Chatbot lösen wollte: „Das ist zwar wunderbar, macht aber wenig Sinn“, sagte Ratheiser. Potenzial für Agents sieht er dort, wo Prozesse klar beschrieben, Daten sauber angebunden und Verantwortlichkeiten geklärt waren – nicht als Ersatz für Kultur- oder Organisationsarbeit.

Prozesse, Daten und Haftung

Genau an dieser Stelle setzte Andreas Thomasch nach. Wenn ein Unternehmen Prozesse nicht beschreiben konnte, wenn unklar blieb, woher Daten kamen und wer wofür verantwortlich war, lieferte ein Agent aus seiner Sicht keinen brauchbaren Output. Vor allem dort, wo bestehende Abläufe automatisiert oder beschleunigt werden sollten, standen zuerst Prozess- und Datenarbeit an.

Parallel dazu sah Thomasch eine zweite Linie. Wenn ein Unternehmen ein neues Produkt oder eine neue Dienstleistung entwickelte und dafür Prozesse und Datenzugänge ohnehin neu aufzog, konnte es KI von Anfang an mitdenken und dabei intern die Voraussetzungen schaffen. Als typisches Feld nannte er HR-Prozesse, die oft gut dokumentiert waren und damit eine solide Basis für KI-Unterstützung boten.

Beim Thema Haftung blieb er nüchtern. Besonders in Bereichen wie HR sah er „human in the loop“ als Standard. Ein Agent konnte Schritte vorbereiten, Daten bündeln und Manager:innen durch Masken führen. Die finale Entscheidung traf aber ein Mensch, vor allem dort, wo es um kritische Entscheidungen ging.

Warum POCs immer noch scheiterten

Trotz besserer Modelle und Tools blieb Patrick Ratheiser eine Zahl in den vergangenen Jahren unverändert. „81 Prozent scheitern mittlerweile wieder mal nach dem POC“, sagte er und ergänzte, dass diese Aussage grob gesagt seit zehn Jahren gültig sei. Eine aktuelle Studie bestätige diesen Wert.

Die Muster ähnelten einander. Unternehmen wählten falsche oder zu komplexe Anwendungsfälle, die Erwartungshaltung schoss nach oben, und Datenqualität blieb Nebensache. „Wir nehmen alle Daten vom Unternehmen, am besten alle Dokumente, jagen die in der GPT rein und dann wird schon alles gut. Das wird nicht funktionieren“, sagte Ratheiser.

Christian Casari steuerte dazu sein Lieblingsbild bei: „Garbage in, garbage out. Ich kann ja das beste Auto haben. Wenn ich glatte Reifen habe und draußen ist glattes Eis, werde ich wahrscheinlich die PS nicht auf die Straße bringen“, sagte er. Ohne Daten, die zum Problem passten, blieb jedes Modell ein teures Experiment.

Mehrwert über mehrere Use Cases

Lenovo-CTO Andreas Thomasch verwies auf die Notwendigkeit einer Struktur. Einen ROI nur über einen einzelnen Use Case zu rechnen, hielt er für schwierig. „Der Aufwand für meinen ersten Use Case ist vermutlich genauso hoch für die nächsten neun folgenden“, sagte er. Deswegen empfahl er, einen Datenbereich als Ganzes „KI-ready“ zu machen und von Beginn an mehrere Use Cases mitzudenken. Wenn einer scheiterte, blieben andere übrig, die den Invest stützten.

Beim Start-Setup setzte Thomasch auf einen klaren Schritt. Er plädierte dafür, eine eigene Umgebung zu schaffen, in der sich KI-Workloads innerhalb der bestehenden Security- und Governance-Prozesse ausprobieren ließen. Eine kleine Sandbox, die IT und Fachbereiche gemeinsam nutzten, half seiner Erfahrung nach, bevor jemand den produktiven Rollout verlangte.

Cloud, On-Prem und Energie

Die Frage, wo KI-Anwendungen laufen sollen, muss laut Thomasch schon zu Beginn eines Projekts geklärt werden. Fachabteilung und IT sollten früh festlegen, ob relevante Daten in der Cloud liegen, on-premise oder in einer hybriden Struktur. Viele Unternehmen landen ohnehin in einem Mischmodell, weil ihre Datenlandschaft bereits verteilt war, wie Thomasch ausführt.

Christian Casari brachte eine Dimension ein, die in Strategierunden häufig zu kurz kam. „Die aktuellen politischen Entwicklungen sollten uns zumindest ein bisschen zum Nachdenken geben“, sagte er. Für ihn zählt vor allem, wie kritisch Daten waren. „Wenn ich meinen Datenschatz, also das, was meine Firma ausmacht, in Daten habe, und das liegt on-premise, ich werde den Teufel tun und das in die Cloud geben und dann noch mit einem Large-Language-Model bearbeiten.“ Weniger kritische Daten sah er dagegen als gute Kandidaten für skalierbare Cloud-Lösungen.

Hybride Szenarien mit lokalen Systemen, Private-Cloud-Ansätzen und Cloud-Komponenten passten für beide gut zu einem weiteren Engpass: Energie. Thomasch erinnerte daran, dass Rechenzentren ihr Energiebudget nicht beliebig erhöhen konnten. Die Frage, welche Modelle auf welcher Infrastruktur liefen, entwickelte sich damit zu einer wirtschaftlichen Notwendigkeit.

Große Modelle, kleine Modelle

Im Alltag beobachtet Patrick Ratheiser einen deutlichen Gegensatz zwischen technischen Möglichkeiten und realem Einsatz. Er berichtete von einem Projekt an der Universität Graz. „Für 30.000 Studenten brauche ich kein GPT-5.1-Modell. Da reicht das Mini vollkommen“, sagte er. Dort ging es um einfache Fragen zu Urlaubstagen oder Abläufen, nicht um literarische Experimente.

Das eigentliche Problem sieht er in der Erwartungshaltung. Viele Mitarbeiterinnen und Mitarbeiter verglichen interne Systeme mit den großen, frei zugänglichen Modellen am Handy. „Das fühlt sich halt einfach nicht an wie ChatGPT“, höre er häufig. Mit solider Aufklärung über Funktionsweise und Trade-offs sieht er aber eine Chance, kleinere Modelle dort zu akzeptieren, wo sie ausreichten – und gleichzeitig Kosten und Energieverbrauch zu senken.

Christian Casari schärfte dieses Bild mit einer Analogie – einem LKW, der zehn Meter fährt, um eine Wurstsemmel zu holen. „Momentan erschlagen wir alles mit diesen großen LLMs“, sagte er. In vielen Fällen reichte aus seiner Sicht – um im Bild zu bleiben – „ein Rad oder vielleicht sogar zu Fuß“. Auch preislich sieht er starke Unterschiede. Zwischen einem großen Modell und der Mini-Variante lag nach seiner Einschätzung eher ein Hundertstel der Kosten als ein kleiner Aufschlag.

Agents-Expterin Sarah Eschenbacher warnte gleichzeitig vor falschen Hoffnungen: „Bessere Modelle machen Agents nicht unbedingt besser“, sagte sie. Für sie liegt das Potenzial eher in Kombinationen. Unternehmen konnten spezialisierte kleine Modelle als Tools nutzen, etwa für besonders kritische Daten, und größere Modelle dort einsetzen, wo sie den größten Mehrwert brachten. Energieeffizienz bleibt für sie ein Schlüsselbegriff.

Wenn Unternehmen loslegen

Insgesamt zeigte die Diskussion, dass es der Erfolg von KI-Projekten in vielerlei Hinsicht an den Organisationen selbst hängt. Christian Casari brachte das auf eine einfache Formel. Für ihn diente gesunder Menschenverstand als Kompass, nicht als Störfaktor. Teams sollten klären, wo sie standen, wohin sie wollten und was sie im Haus hatten – und erst danach über Tools und Modelle entscheiden.

Sarah Eschenbacher lenkte den Blick außerdem auf die Größe der Vorhaben. Sie rät Unternehmen, keine Monster-Use-Cases zu planen, sondern spezialisierte Agents für klar umrissene Aufgaben zu bauen. Kleine, fokussierte Projekte erzeugten in ihrer Sicht mehr Wirkung als ein „Alles-Könner“, der in der Praxis niemandem wirklich half.

Patrick Ratheiser plädierte in der Schlussrunde dafür, sich nicht von der Wunschliste der Chefetage treiben zu lassen, wenn dort sofort der komplexeste Use Case auftauchte. Er bevorzugte kleine, gut geschnittene Anwendungsfälle und verstand AI-Literacy als Pflichtprogramm. Unternehmen sollten ihre Leute fit machen, ihnen Tools geben und Experimente ermöglichen, damit eine lernende Organisation entstand.

Andreas Thomasch wiederum richtete seinen Appell an die IT-Seite. Sie sollte nicht warten, bis der Druck aus den Fachbereichen stieg, sondern sich vorbereiten, eine Umgebung für KI-Workloads aufbauen und eigenes Know-how sammeln. „Die Frage von der Fachabteilung wird kommen“, sagte er. Wer dann bereits eine Antwort hatte – technisch, organisatorisch und mit Blick auf die Daten –, holte KI aus der theoretischen Debatte in die tägliche Arbeit.