Viele konnten Deep Research zwar bereits individuell nutzen, um Informationen online zu suchen und zusammenzuführen. Im Unternehmenskontext haben bislang jedoch nur wenige davon profitiert. Das liegt nicht an mangelndem Nutzen, ganz im Gegenteil. Gründe sind vielmehr allgemeine Bedenken hinsichtlich der Zuverlässigkeit, verteilter Datenquellen und der Fähigkeit eines Modells, große Kontextmengen zu verarbeiten, etwa sehr viele unterschiedliche Dateitypen.
Unsere Erfahrungen aus der Entwicklung unternehmenstauglicher Deep-Research-Werkzeuge in den vergangenen zwölf Monaten zeigen, dass sich diese Bedenken durch durchdachtes Engineering zunehmend ausräumen lassen. In diesem Beitrag erläutern wir die größten Hindernisse für wirksame Deep-Research-Anwendungen in Unternehmen, wie wir sie überwinden würden und wie sich dieser Bereich unseres Erachtens 2026 entwickeln wird.
Die Grenzen des Machbaren haben sich deutlich verschoben. Die Einführung von gpt-5 im August 2025 markierte einen Wendepunkt für KI in Unternehmen. In unseren Produktivsystemen, darunter eine Plattform zur Identifizierung therapeutischer Zielstrukturen für eines der weltweit größten Pharmaunternehmen, sank der Anteil erfundener Quellen von 3–4 % auf praktisch null. gpt-5.2 erweiterte im Dezember dann die effektive Kontextlänge nochmals. Das praktische Ergebnis: Wir können inzwischen von Hunderten auf Tausende Quellen pro Recherchelauf skalieren, ohne die Zuverlässigkeit zu beeinträchtigen. Der Engpass liegt nicht mehr in der Leistungsfähigkeit der Modelle, sondern wieder dort, wo er hingehört: bei deinen Daten, deinen Evaluationen und deiner Programmgestaltung.
Datenstrategie: Erreichbarkeit ist wichtiger als Vereinheitlichung. Der Impuls, KI in Unternehmen als Problem der Datenintegration zu behandeln, ist nachvollziehbar, aber oft kontraproduktiv. Eine vollständige Vereinheitlichung ist langsam, politisch und zwingt zu früh zu Festlegungen, bevor klar ist, welche Fragen wirklich wichtig sind. Der pragmatische Ansatz für 2026 ist eine punktuelle Vernetzung. Mach Daten über aussagekräftige Ankerpunkte wie Spezifikationen, Richtlinien, SKUs und Vertragsklauseln erreichbar, statt jahrelang auf eine vollständige Vereinheitlichung zu warten. Frontier-Modelle können Systeme inzwischen während der Inferenz flexibel verknüpfen und zusammengehörige Begriffe ohne formale Zuordnungen verbinden. So kannst du weiterhin schnell bereitstellen und später flexibel weitere Quellen ergänzen.
Navigation verhindert zielloses Suchen. Unternehmensdaten sind nicht wie das Web. Sie sind lückenhaft, von lokalen Konventionen geprägt und enthalten für eine bestimmte Tatsache oft genau eine richtige Quelle. Ohne Orientierung neigen Modelle dazu, zahllose Suchanfragen abzuarbeiten, um noch eine weitere Quelle zu finden. Das kostet Zeit und strapaziert die Geduld der Nutzenden. Eine schlanke semantische Ebene aus Hashmaps, Entitätssuchen und einfachen Beziehungsgraphen bietet dem System schnelle, kostengünstige Wege zum richtigen Kontext. Das ist vergleichbar mit dem Rat einer erfahrenen Person an ein neues Teammitglied: „Setz dir Lesezeichen für diese Seiten und sprich bei AWS-Problemen mit Ross.“ Es muss nicht kompliziert sein. Es muss dem System lediglich helfen, schnell das Richtige zu finden.
Mechanisch (bei jeder Anfrage): Qualität der Quellenangaben, sauberer Werkzeugeinsatz, Latenz und Kosten. Das sind deine Leitplanken: unspektakulär, aber unverzichtbar.
Analytisch (regelmäßig): Wählt das System die richtigen Werkzeuge, verfolgt es sinnvolle Recherchewege, nutzt es maßgebliche Quellen und weiß es, wann es aufhören sollte? Die Bewertung erfolgt üblicherweise anhand gekennzeichneter Beispiele nach dem Prinzip „LLM-as-a-Judge“.
Nutzungsbezogen (fortlaufend): Abschlussquoten von Aufgaben, qualitatives Feedback erfahrener Nutzender und Nutzungsanalysen. Der entscheidende Test. Haben wir etwas entwickelt, das Menschen nützlich finden?
ROI entsteht durch schwierige, nicht durch sichere Aufgaben. Seit Berichte behaupten, die meisten KI-Projekte in Unternehmen erzielten keinen ROI, ist die Toleranz für eindrucksvolle Demos ohne anschließende Einführung verschwunden. Führungskräfte wollen Belege, und zwar schnell. Paradoxerweise kann dieser Druck Teams zu den falschen Entscheidungen bewegen. Es liegt nahe, mit unkritischen Aufgaben zu beginnen, weil sie einfach bereitzustellen sind und kaum Widerstand hervorrufen. Doch solche Anwendungsfälle bewirken selten genug, um weitere Investitionen zu rechtfertigen. Deep-Research-Systeme für Unternehmen eignen sich gut, um ihren Nutzen zu belegen, weil sie bereits kostenintensive Arbeit übernehmen: komplexe, kritische Abläufe, bei denen die Kosten des Status quo sichtbar sind. Die überzeugendsten Anwendungsfälle sehen wir bei der Erstellung von Ausschreibungen und Angeboten, bei wissenschaftlichen Umfeldanalysen und in der Investmentanalyse. Hier wird die Wirkung an Erfolgsquoten, kürzeren Wegen bis zur klinischen Prüfung und schnelleren fundierten Entscheidungen gemessen, nicht nur an eingesparten Stunden.
Der UX-Wandel: vom Chatten zum Delegieren, von Antworten zu Arbeitsergebnissen. Wir halten dies für einen der prägenden UX-Wandel des Jahres 2026. Bei den zuletzt besonders gut angenommenen Lösungen fallen vor allem zwei Dinge auf. Mit zunehmender Zuverlässigkeit behandeln Nutzende diese Systeme immer weniger wie einen Chatbot, dem sie Fragen stellen, und mehr wie eine analytische Fachkraft, der sie Aufgaben übertragen. Zwei Dinge machen das möglich: Teams können Vorlagen und Abbruchkriterien an ihre Abläufe anpassen und Ergebnisse direkt im tatsächlich benötigten Format exportieren, etwa als Memo, Präsentation oder Briefing. Sie müssen nicht länger aus einem Chatverlauf selbst ein fertiges Ergebnis zusammenstellen. Sind beide Voraussetzungen erfüllt, ist das System kein Nachschlagewerk mehr, sondern wird zum Arbeitsmittel.
Im vergangenen Jahr schrieben wir darüber, wie wir Deep Research in Unternehmen bringen. Dafür erweiterten wir das ursprünglich von OpenAI etablierte, weborientierte Deep-Research-Paradigma auf geschützte Unternehmensdaten, ohne Herkunftsnachweise oder Kontrolle einzubüßen. Wir betonten außerdem, dass Deep-Research-Systeme keine Abkehr von klassischen RAG-Systemen darstellen, sondern deren Weiterentwicklung.
Mit Blick auf 2026 hat sich weniger die Idee von Deep Research verändert als vielmehr die Grenze dessen, was sich damit umsetzen lässt.
Als wir Anfang 2025 mit der Entwicklung dieser Systeme begannen, gehörten o1, gpt-4o und claude-3.5-sonnet zu den Frontier-Modellen. In nur zwölf Monaten hat sich viel getan. Bereits in den ersten Monaten des Jahres folgten große Fortschritte durch Modelle wie o3 und gemini-2.5-pro. Für ihre Zeit waren diese Modelle hervorragend, und bis zu einem gewissen Punkt ließen sich mit ihnen durchaus robuste Deep-Research-Anwendungen entwickeln. Diese Grenze lag üblicherweise bei einigen Hundert Quellen. Danach musste der Kontext stark gekürzt werden, sonst drohten Informationsverluste in der Antwort, eine schlechtere Befolgung von Anweisungen oder offene Halluzinationen.
Wenn du solche Systeme entwickelt hast, wirst du einige dieser Fehlerbilder kennen.
Ein konkretes Beispiel: Mitte 2025 begannen wir gemeinsam mit einem der weltweit größten Pharmaunternehmen, eine Deep-Research-Lösung für Unternehmen zu entwickeln. Das System soll die Identifizierung therapeutischer Zielstrukturen beschleunigen. Dabei suchen Forschende nach Genen, Hormonen oder anderen Bestandteilen des menschlichen Körpers, auf die eine Behandlung einer Erkrankung ausgerichtet werden kann. Das damals leistungsfähigste verfügbare Modell war o3. Obwohl dieses Modell eine hohe Leistung erzielte, enthielten 3–4 % seiner Antworten Quellen, die ihm nicht über Werkzeugaufrufe aus den geschützten Datenquellen des Kunden bereitgestellt worden waren. Wir begegneten dem mit nachträglichen Quellenprüfungen, die nicht durch den bereitgestellten Kontext gestützte Antwortabschnitte kennzeichneten. In der frühen PoC-Phase stärkte dies das Vertrauen der Beteiligten in das Werkzeug und half uns, schnell Fortschritte zu erzielen. Wir arbeiteten dennoch weiter daran, diese Fehler zu reduzieren. Dabei mussten wir die Grenzen der Modelle abmildern und zugleich den Wunsch der Beteiligten erfüllen, weitere Quellen in das System aufzunehmen.
Ein entscheidender Wendepunkt für Frontier-Deep-Research-Lösungen und allgemein für agentische Lösungen war die Einführung von gpt-5 im August. Nach dem Wechsel von o3 zu gpt-5 zeigten unsere Evaluationen, dass der Anteil erfundener Quellen sofort auf 0 % sank.
Genauer gesagt erfasst diese Kennzahl ausschließlich, ob das Modell eine Dokument-ID oder URL angibt, die nicht im abgerufenen Kontext enthalten war. Zu Zeiten von o3 und davor erfanden Modelle gelegentlich plausibel klingende Dateinamen oder Fachartikel, um Wissenslücken zu füllen. Mit gpt-5 konnten wir dieses konkrete Fehlerbild praktisch beseitigen.
Davon zu unterscheiden sind inhaltliche Treuefehler, bei denen das richtige Dokument zitiert, der Text aber falsch interpretiert wird. Diese Herausforderung behandeln wir weiterhin mit den zuvor erwähnten nachträglichen Prüfungen.
Das erschloss enorme neue Möglichkeiten. Daraufhin testeten wir, wie weit wir das System mit der neuen Modellgeneration ausreizen konnten. Wir konnten in einem Deep-Research-Lauf etwa zehnmal so viele Quellen berücksichtigen, rund 3.000 bis 5.000. Die letztliche Grenze lag nicht in einer schlechteren Befolgung von Anweisungen, sondern in der Verarbeitung langer Kontexte. Die effektive Kontextlänge von Modellen ist oft deutlich geringer als angegeben, insbesondere bei dichten Daten wie in der Pharmaforschung.
Mit der Veröffentlichung von gpt-5.2 Mitte Dezember wurde diese Einschränkung teilweise gemindert. Unsere internen Benchmarks für lange Kontexte zeigten eine deutliche Verbesserung der effektiven Leistung. Dadurch konnten wir unsere Frontier-Systeme für Deep Research noch weiter ausbauen. So konnten wir letztlich mehr Token direkt an das Modell übergeben, das die Ausgabe für die nutzende Person erstellt, und dadurch eine gehaltvollere Antwort liefern. Dennoch wünschen wir uns, dass die effektiven Kontextlängen von Frontier-Modellen im Jahr 2026 weiter steigen.
Angesichts dieser Fortschritte bei der reinen Modellleistung haben sich die Engpässe für leistungsfähige Deep-Research-Systeme in vielerlei Hinsicht dorthin zurückverlagert, wo sie von Anfang an liegen sollten: zu deinen Daten, deinen Evaluationen und der Gestaltung deines Deep-Research-Programms im Unternehmen. Bei jedem dieser Schritte musst du pragmatisch entscheiden, was eine Deep-Research-Lösung wirklich voranbringt.
Im restlichen Artikel erläutern wir, wie wir über diese Entscheidungen nachdenken.
Es kann verlockend sein, Rechercheprojekte in Unternehmen als Problem der Datenintegration zu behandeln. Quellen vereinheitlichen, das Schema normalisieren und die Modelle darauf loslassen.
Und um das klarzustellen: Manchmal ist genau das der richtige Ansatz. Wenn du in einem Bereich mit stabilen Kernentitäten und wiederkehrenden Abfragen arbeitest und den Ablauf letztlich industrialisieren möchtest, kann sich eine Vereinheitlichung deutlich auszahlen. Klassische Beispiele sind die Verknüpfung von Kunden- und Umsatzdaten, Marktpreisdaten sowie alle Fälle, die eine zuverlässige systemübergreifende Berichterstattung erfordern.
In der Praxis erwarten innovative Führungskräfte heute jedoch etwas anderes von Deep-Research-Systemen für Unternehmen.
Da der ROI von KI-Ausgaben immer stärker im Mittelpunkt steht, wollen Verantwortliche den Nutzen schnell unter den unübersichtlichen realen Bedingungen des Unternehmens belegen. Eine vollständige Vereinheitlichung der Datenquellen ist jedoch einer der langsamsten Wege zu diesem ersten Beleg. Sie ist aufwendig. Sie wird zum Politikum. Und häufig zwingt sie dich zu einer Festlegung, bevor du weißt, welche Fragen wirklich wichtig sind.
Der pragmatische Ausgangspunkt für Frontier-Systeme für Deep Research im Jahr 2026 lautet daher meist: Mach deine Daten zuerst erreichbar und erst später perfekt.
Wenn du voraussichtlich später weitere Quellen ergänzen wirst, wie die meisten Unternehmen, werden punktuelle Verbindungen häufig unterschätzt. Du kannst Dutzende Quellen über eine einheitliche Abrufschnittstelle zugänglich machen. Das System bleibt arbeitsfähig, und vor allem kannst du weiterhin schnell Ergebnisse liefern. Wenn du weitere Quellen hinzufügst, musst du nicht alles umgestalten. Du kannst einfach einen neuen Konnektor anschließen, dem Kernsystem erklären, was er ist und wie es ihn verwendet, und den Modellen den Rest überlassen. Das funktioniert, weil heutige Frontier-Modelle während der Inferenz zwei oder mehr Datenquellen flexibel verknüpfen können. Sie verbinden etwa „Customer ID“ in einem System mit „Client Reference“ in einem anderen, ohne dass jemand eine formale Zuordnung erstellt. Wir sind nicht das einzige Team, das diesen Ansatz verfolgt. Wir sind nicht das einzige Team, das diesen Ansatz verfolgt: Der interne Daten-Agent von OpenAI ermöglicht Modellen, über 70.000 heterogene Datensätze hinweg Schlussfolgerungen zu ziehen. Dafür werden Kontext und Verbindungen bei der Abfrage erreichbar gemacht, statt vorab eine vollständige Vereinheitlichung zu erzwingen.
Eine wichtige Nuance sollte ausdrücklich erwähnt werden: Punktuell muss nicht oberflächlich bedeuten.
Punktuelle Integration funktioniert am besten, wenn die vorhandenen Verbindungen aussagekräftig und für das System leicht nutzbar sind. Hilfreich ist es, bestimmte Informationen als Ankerpunkte zu betrachten, etwa Spezifikationen, Richtlinien, Produktdefinitionen, SKUs und Vertragsklauseln. Du musst nicht alle Datensätze vereinheitlichen, damit diese Ankerpunkte wirkungsvoll sind. Es genügen eine stabile Kennung und wenige aussagekräftige Kanten.
Stell dir beispielsweise vor, dass ein Modell oder eine Person eine Spezifikation sucht. In einem einfachen System endet die Interaktion an diesem Punkt. Du rufst die Spezifikation ab, fasst sie zusammen und gibst sie vielleicht als Quelle an. Bei nützlichen Datenstrukturen soll diese Suche jedoch den Ausgangspunkt für eine kontrollierte Erweiterung bilden. Beispielsweise könnten wir den Datensatz dieser Spezifikation optional mit historisch relevanten Materialien verknüpfen. „Relevant“ kann hier Verschiedenes bedeuten und hängt normalerweise von der jeweiligen Aufgabe des Systems ab. Dazu könnten Ausschreibungen gehören, die sich auf die Spezifikation beziehen, frühere erfolgreiche Angebote dazu oder Änderungen, bei denen die Rechtsabteilung Einwände gegen die Spezifikation erhoben hat. Dieser Ansatz kann Antwortqualität und Latenz deutlich verbessern, weil dem Deep-Research-System die wichtigsten Erkenntnisse bei der Abfrage schnell bereitgestellt werden.
Daraus ergibt sich die nächste Frage: Wie verhinderst du bei einer Vielzahl punktuell verbundener Datenquellen mit wenigen aussagekräftigen Kanten, dass das Deep-Research-System wie ein Kind im Süßwarenladen umherirrt? Wie sorgst du stattdessen dafür, dass es wie eine erfahrene analytische Fachkraft navigiert?
Unternehmensdatenquellen verhalten sich nicht wie das Web. Sie sind lückenhaft, von lokalen Konventionen geprägt und enthalten für eine bestimmte Tatsache oft genau eine „richtige“ Quelle, sofern man sie findet. Zudem versuchen heutige Modelle bei Suchanfragen oft, den Recall zu maximieren. Sie arbeiten immer weitere Anfragen ab, um nur noch eine weitere Quelle zu finden, und verbrauchen dabei Zeit und die Geduld der Nutzenden. Sorgfältiges Prompting kann dies teilweise abmildern.
Die wirksamste Lösung ist ein schlankes Werkzeug, mit dem sich das Modell in der unübersichtlichen Unternehmensdatenlandschaft orientieren kann. Manche Teams nennen dies eine Ontologie. Andere sprechen von einer semantischen Ebene, einem Suchdienst, einem Graphen oder einem Konzeptverzeichnis. Die Bezeichnung ist nicht entscheidend.
Entscheidend ist, dass das System schnelle, kostengünstige Wege erhält, über die das Modell effizient zwischen den richtigen Kontextteilen wechseln kann, statt scheinbar endlos umherzuirren.
Ein einfacher Vergleich: Du bist gerade neu in einem Unternehmen oder Projekt, und deine neuen Teammitglieder sagen dir: „Setz dir unbedingt Lesezeichen für diese Seiten, du wirst sie ständig brauchen“, oder: „Wenn du ein Problem mit AWS hast, sprich einfach mit Ross. Er besorgt dir die nötigen Informationen“, und so weiter. Auch hier wollen wir dem Deep-Research-System lediglich helfen, schnell das Richtige zu finden.
In der Praxis muss dieses System weder kompliziert sein noch manuell gepflegt werden. Die besten uns bekannten Implementierungen werden entweder während der Datenaufnahme von LLMs erzeugt, die Entitäten extrahieren und den Graphen automatisch füllen, oder leiten Anfragen einfach an bestehende führende Systeme weiter, etwa über eine Suche in der Salesforce API. Typische Beispiele sind:
Hashmap-Suchen, etwa: Abfrage mit Produktname, Rückgabe der Produktbeschreibung
Eine schlanke Suche nach „häufigen“ Beziehungen, etwa: In unserem Graphen kausaler Genbeziehungen ist dieses Gen am häufigsten mit diesen Krankheiten verbunden
Modelle zur Erkennung benannter Entitäten, vor allem in Bereichen mit komplexer Entitätsabgrenzung wie der Pharmaforschung
Bei besonders komplexen Datenbeziehungen können schlanke RDF-Graphen die am besten erweiterbare Ontologielösung bieten
… und weitere
Damit kann sich das System effizient durch deine Datenquellen bewegen. Die nächste Frage ist einfach: Woher weißt du, dass es unter realen Nutzungsbedingungen dauerhaft das Richtige tut?
Deine Daten sind nun erreichbar, und die Navigationsebene liefert die Karte. Damit kann dein System die Arbeit erledigen. Im Unternehmenskontext ist Leistungsfähigkeit ohne Zuverlässigkeit jedoch wertlos.
Hier befindet sich der größte Friedhof gescheiterter KI-Projekte. Viele Teams sind in die Falle von Bewertungen nach Bauchgefühl geraten. Sie führten eine Anfrage aus, lasen das Ergebnis, nickten zufrieden und stellten es bereit. Dieser Ansatz funktioniert nicht bei einem Deep-Research-System, das möglicherweise selbstständig 5.000 Dokumente durchsucht, um eine Empfehlung für eine Lieferkettenentscheidung im Millionenwert abzugeben.
Der entscheidende Wandel besteht darin, dass du nicht mehr ein Modell, sondern ein System bewertest. Frageverständnis, Planung, Werkzeugaufrufe, Interpretation, Kontextbereinigung, Neusortierung und selbst scheinbar langweilige Verbindungsdetails wie Zeitstempel wirken sich auf die Nutzung aus.
Strukturierte, wiederholbare Evaluationen helfen uns, diese Probleme zu lösen.
Beim Aufbau von Evaluationen lassen sich grob drei Kategorien unterscheiden, die von mechanischen bis zu subjektiven Bewertungen reichen.
Dieser Bereich ähnelt am stärksten Unit-Tests, und hier können Teams zu Beginn oft am schnellsten Fortschritte erzielen. Diese Evaluationen sind meist auch langfristig am stabilsten. Einmal eingerichtet, bringen sie über die gesamte Projektlaufzeit Nutzen.
„Mechanische Evaluationen“ sind im Allgemeinen Prüfungen, die sich bei jeder Anfrage ohne menschliches Eingreifen ausführen lassen. Sie stärken unser Vertrauen, dass sich das System unter realer Nutzung vorhersehbar und sicher verhält.
Einige Beispiele:
Qualität der Quellenangaben: Verweisen alle Quellenangaben auf tatsächlich abgerufene Textstellen? Gibt es Aussagen ohne Quellenangabe? Gibt es Aussagen, die nicht durch das Quellenmaterial gestützt werden? Sind die Quellenangaben zu allgemein, etwa wenn für eine einzelne Aussage ein ganzes Dokument zitiert wird?
Sauberer Werkzeugeinsatz: Hat das System alle Werkzeuge verwendet, die es nach eigener Angabe verwendet hat? Hat es die Navigationswerkzeuge richtig eingesetzt? Hat es Werkzeugaufrufe falsch formatiert? Hat es nach Fehlermeldungen sinnvolle neue Versuche unternommen?
Latenz- und Kostenbudgets: Hat es die Zielzeit bis zum ersten Token eingehalten? Hat es die erwartete Zahl an Werkzeugaufrufen oder das Budget überschritten? Hat es für einen geringfügigen Gewinn unverhältnismäßig viel Zeit und Rechenleistung verbraucht?
Das klingt banal, doch genau solche Tests verhindern, dass ein Unternehmenssystem mit der Zeit verfällt.
In unserem Deep-Research-Projekt zur Identifizierung therapeutischer Zielstrukturen nutzten wir beispielsweise zwei Ebenen von Quellenprüfungen, die bei jeder Anfrage ausgeführt werden. Zunächst weisen wir das Modell an, beim Erstellen einer Antwort regelmäßig Quellen direkt im Text anzugeben. Dass LLMs dies zuverlässig können, ist ebenfalls eine relativ neue Entwicklung aus der ersten Hälfte des Jahres 2025. Wer dies zuvor mit relevanten Datenmengen versucht hat, kennt die damaligen Schwierigkeiten. Anschließend können wir mit einfachen Regex-Prüfungen beispielsweise feststellen, ob ein Link zu einem Artikel genannt wird, der nicht in den bereitgestellten Quellen enthalten war.
Die zweite Prüfebene folgt nach der gestreamten Ausgabe der Antwort. Zunächst wird die Antwort in Abschnitte unterteilt. Danach bewertet das System jeden Abschnitt und sucht in den abgerufenen Daten nach Quellen, welche die darin enthaltenen Aussagen stützen. Findet es keine stützenden Belege, wird dies als mögliche Halluzination gekennzeichnet.
Wenn die mechanischen Evaluationen deine Unit-Tests sind, entsprechen die analytischen Evaluationen dem Code-Review.
Hier geht es darum, zu verstehen, ob das System seine Arbeit gut erledigt. Uns interessiert unter anderem, ob es die richtigen Werkzeuge verwendet, geeignete Recherchewege verfolgt, die maßgeblichsten Quellen auswählt und weiß, wann es aufhören sollte.
In der Praxis bestehen diese Evaluationen meist aus Frage-Antwort-Paaren, für die beispielsweise sinnvolle Reihenfolgen von Werkzeugaufrufen bekannt sind oder feststeht, welche Entscheidung auf Grundlage der vom ersten Werkzeug gefundenen Rechercheergebnisse richtig ist. Die Paare müssen Ein- und Ausgabe des vollständigen Deep-Research-Systems nicht eins zu eins abbilden. Mit diesen Methoden lassen sich auch Teilprozesse testen. Mit diesen Kennzeichnungen, die von Menschen oder einem leistungsfähigen Kennzeichnungsmodell stammen können, lassen sich Rechercheläufe nach dem Prinzip „LLM-as-a-Judge“ bewerten. Indem wir diese Bewertungen im Zeitverlauf beobachten, erkennen wir, ob unsere Änderungen das System verbessern oder Leistungseinbußen verursacht haben.
Da diese Läufe mehr Geld und Zeit kosten, sollten sie üblicherweise regelmäßig nach einem festen Zeitplan oder vor Versionsaktualisierungen ausgeführt werden.
Hinzu kommt ein nützlicher indirekter Vorteil: Solche analytischen Evaluationen können unmittelbar zeigen, wie sich die zuvor beschriebenen punktuellen Verbindungen verbessern lassen. Wenn das Modell wiederholt denselben hochwertigen Zusammenhang herstellt, etwa „Spezifikation → historisch relevante Ausschreibungsbeispiele“, obwohl Menschen diese Materialien bislang nicht ausdrücklich verknüpfen, ist das wertvoll. Du kannst daraus eine feste Kante oder Abkürzung machen, sodass künftige Läufe bei geringerer Latenz und höherer Konsistenz davon profitieren.
Hier zeigt sich auch eine der teuersten Fehlentwicklungen bei Deep-Research-Systemen: die Neigung, standardmäßig den Recall zu maximieren. Ein Modell kann immer noch eine weitere Quelle finden. Die Frage ist, ob es das sollte. Wir können das Modell so anpassen, dass es an sinnvollen Stellen aufhört: Das System erkennt, wenn weitere Suchvorgänge die Schlussfolgerung wahrscheinlich nicht verändern würden, und liefert eine gut belegte Antwort auf die Frage der nutzenden Person.
Die mechanischen Evaluationen zeigen dir, dass das System sicher ist. Die analytischen Evaluationen zeigen dir, dass es kompetent ist. Nutzungsevaluationen zeigen dir, ob es tatsächlich nützlich ist.
Auch in diesem Bereich scheitern viele Teams. Sie entwickeln etwas technisch Beeindruckendes, das niemand ein zweites Mal verwenden möchte. Im Unternehmenskontext ist das der Unterschied zwischen einer erfolgreichen Einführung und einem kostspieligen Forschungsprojekt.
Bei Nutzungsevaluationen geht es grundsätzlich darum, zu verstehen, ob das System das richtige Problem auf die richtige Weise löst. Das bedeutet, nicht nur zu fragen: „War die Antwort richtig?“, sondern auch: „Kann ich mit dem Ergebnis konkret handeln?“
In der Praxis gibt es meist mehrere Formen von Nutzungsevaluationen:
Studien zum Aufgabenabschluss: Können Nutzende ihre tatsächliche Arbeit mit dem System schneller oder besser erledigen? Es geht nicht darum, ob das Modell eine Frage beantworten könnte, sondern ob eine reale Person im tatsächlichen Arbeitsablauf das benötigte Ergebnis erhalten hat.
Qualitative Feedbackschleifen: Regelmäßige strukturierte Gespräche mit besonders erfahrenen Nutzenden. Welche Anfragen führen sie wiederholt aus? An welchen Stellen verlieren sie das Vertrauen? Wann geben sie auf und kehren zur alten Arbeitsweise zurück? Solche Gespräche offenbaren häufig Fehlerbilder, die in Testdatensätzen nie auftreten. Nutzende formulieren Fragen anders als erwartet oder haben unausgesprochene Qualitätsanforderungen, von denen du nichts wusstest.
Nutzungsanalysen: Welche Anfragen werden erneut ausgeführt? Welche Antworten werden kopiert und an anderer Stelle verwendet? An welchen Stellen klicken Nutzende auf den nach unten zeigenden Daumen? Eine abnehmende Nutzung bedeutet nicht immer einen Misserfolg. Manchmal erhalten Menschen ihre Antwort und gehen weiter. Muster darin, wann und wie sie Anfragen abbrechen, zeigen jedoch deutlich, wo das System ihre Erwartungen nicht erfüllt.
Zusammen ermöglichen diese Ansätze, den Nutzen ohne Spekulation zu messen und Probleme zu erkennen, bevor sie das Vertrauen der Nutzenden beeinträchtigen.
Doch selbst ein System mit perfekten mechanischen Bewertungen und begeisterten frühen Nutzenden kann am entscheidenden Test scheitern: den Unternehmensumsatz zu steigern. Zuverlässigkeit und Zufriedenheit der Nutzenden sind dafür lediglich Voraussetzungen. Für den Sprung vom erfolgreichen Pilotprojekt zu einem Unternehmensträger mit grundlegender Wirkung musst du über die Funktionsweise des Systems hinausblicken und dich darauf konzentrieren, wo es eingesetzt wird.
Wir haben erläutert, wie deine Daten für dein System und anschließend dein System für die Nutzenden arbeiten kann. Nun müssen wir darüber sprechen, wie dieses System für dein Unternehmen arbeitet.
Führungskräfte haben sich zuletzt intensiv und zu Recht mit diesem Thema beschäftigt. Seit Berichten wie der Behauptung des MIT, dass 95 % der KI-Projekte in Unternehmen keinen ROI erzielen, ist die Toleranz für eindrucksvolle Demos ohne anschließende Einführung verschwunden. Die Modelle sind bereit. Die Architekturen haben sich bewährt. Die Frage lautet nun: Kannst du das System so einführen, dass es einen konkreten Nutzen für dein Unternehmen schafft?
Die gute Nachricht: Frontier-Systeme für Deep Research, die auf den genannten Grundsätzen beruhen, erfüllen diese Anforderungen voraussichtlich gut. Sie versuchen nicht, alles zu automatisieren oder ganze Tätigkeitsfelder zu ersetzen. Sie sollen deine besten Fachkräfte bei der wertvollen Arbeit, die diese bereits leisten, deutlich wirksamer machen.
Der Weg von „technisch funktionsfähig“ zu „erzielt ROI“ erfordert jedoch zusätzliche Voraussetzungen: Entscheidungen zu Organisation, Nutzungserlebnis und Messung bestimmen, ob daraus ein alltägliches Werkzeug oder ein vergessener Browsertab wird.
Unserer Erfahrung nach sind es zwei.
Oft liegt es nahe, mit unkritischen internen Aufgaben wie „Fass diese Besprechung zusammen“ zu beginnen. Solche Anwendungsfälle sind zwar sicher, belegen aber selten einen Nutzen, der ihre Kosten rechtfertigt.
Deep-Research-Systeme erzielen die besten Ergebnisse bei großen, schwierigen Aufgaben: kostspieligen Problemen, bei denen höhere Qualität oder Geschwindigkeit nachweisbar mehr Umsatz oder einen strategischen Vorteil bringt.
Den höchsten ROI beobachten wir, wenn Unternehmen Einstiegspunkte wie diese wählen:
Komplexe Angebots- und Ausschreibungserstellung: Deep-Research-Systeme können automatisch die ähnlichsten früheren Erfolge und Misserfolge heranziehen, Klauseln erkennen, die stets Änderungen auslösen, die überzeugendsten Belege für eine Anforderung finden und daraus eine klare, stimmige Positionierung für die Ausschreibung entwickeln. Entscheidend sind hier nicht die eingesparte Zeit, sondern die Erfolgsquote, gesicherte Margen und weniger rechtliche oder wirtschaftliche Überraschungen in späten Phasen.
Wissenschaftliche Umfeldanalyse: In forschungsintensiven Organisationen aus Pharma, Biotechnologie oder Halbleitertechnik geht es darum, wochenlange Literaturrecherchen und internes Wissen zu einer brauchbaren Forschungsrichtung zu verdichten. Ein Deep-Research-System kann Tausende Fachartikel, Patente, interne Berichte, Labornotizen und frühere Programmbewertungen auswerten. So kann es gesicherte und umstrittene Erkenntnisse erfassen und eine beleggestützte Übersicht erstellen. Das ermöglicht schnellere Iterationszyklen, weniger aussichtslose Vorhaben und vor allem einen kürzeren Weg bis zur ersten klinischen Studie am Menschen.
Marktanalysen: Für Banken und Hedgefonds liegt der Nutzen darin, fragmentierte interne Analysen wie Notizen, Modelle, Transkripte und Kommentare von Brokerhäusern mit externen Signalen wie Pflichtveröffentlichungen, Geschäftszahlen, Konjunkturdaten und Nachrichten zu einer entscheidungsreifen Handelsgrundlage zu verbinden. Ein Deep-Research-System kann die Einschätzung eines Unternehmens, Themas oder einer makroökonomischen Frage fortlaufend erstellen und aktualisieren. Es hebt wichtige Veränderungen seit der Vorwoche hervor, gleicht widersprüchliche Quellen ab und erstellt ein Investmentmemo oder Handelspaket mit vollständigen Herkunftsangaben.
All diesen Beispielen ist gemeinsam, dass es sich nicht um Chats handelt. Es sind komplexe Abläufe, die normalerweise kostspielige externe Beratungsleistungen oder wochenlange Arbeit erfahrener Fachkräfte erfordern. Wenn ein Deep-Research-System diese Probleme bearbeitet, ist der Nutzen eindeutig.
Dies ist einer der UX-Wandel, die das Jahr 2026 prägen werden.
Ist dein Deep-Research-System lediglich ein Chatbot, dem Nutzende Suchfragen stellen, wird es schnell nur noch sporadisch verwendet. Es bleibt ein Nachschlagewerk, dessen Ergebnisse die Nutzenden letztlich selbst zum gewünschten Endergebnis zusammenstellen müssen. Wirkt es dagegen wie eine jederzeit verfügbare analytische Fachkraft, der du Aufgaben übertragen kannst, kann es das Arbeitsmodell des Teams grundlegend verändern.
Wir beobachten einen Wandel vom „Chatten“, also kurzen Dialogen, zum Delegieren: Umfang, Vorlage und Ziel werden festgelegt, dann arbeitet das System selbstständig.
Drei konkrete Veränderungen ermöglichen dies:
Ergebnisse als Arbeitsprodukte: Wertvolle Arbeit findet selten in einem Chatfenster statt, sondern in Dokumenten, Memos und Präsentationen. Moderne Deep-Research-Systeme sollten die Chatphase überspringen und direkt das endgültige Geschäftsdokument erstellen. Wenn eine Person ein „dreiseitiges Investmentmemo in unserem Unternehmensformat“ anfordern und statt eines Textstroms eine herunterladbare Datei erhalten kann, verkürzt sich die Zeit bis zum Nutzen drastisch. Häufig wird dies um geplante Erstellungen erweitert: Nutzende können E-Mails oder Berichte automatisch mit neuen Erkenntnissen erstellen und bei Eingang neuer Daten an die relevanten Personen verteilen lassen.
Lokale Optimierung durch eigene Vorlagen: Modelle sind inzwischen robust genug, dass Geschäftsbereiche oder einzelne Nutzende ihre Prompts und Verhaltensweisen selbst anpassen können, ohne das System zu beschädigen. Ein Risikobericht sieht in London anders aus als in New York. Wenn Teams eigene Strukturvorlagen hochladen oder gestalten sowie eigene Abbruchkriterien, etwa „Prüfe immer diese drei internen Datenbanken“, und Ausgabeformate festlegen können, profitieren die Nutzenden deutlich stärker vom System. So entsteht eine Lösung, die sie immer häufiger einsetzen möchten.
Vertrauen als Schnittstelle: Wenn eine delegierte Aufgabe mehr als 20 Minuten dauert, wird Vertrauen zu einer zentralen Herausforderung. Du darfst keine Blackbox präsentieren. Die Benutzeroberfläche muss die Überlegungen und Entscheidungen des Systems nachvollziehbar machen, etwa durch die Anzeige verwendeter Werkzeuge und die Erstellung von Quellenangaben. Die beste UX für solche Systeme zeigt unserer Erfahrung nach standardmäßig einen Überblick über den Recherchefortschritt. Bei Bedarf können Nutzende in einer Seitenleiste oder einem ähnlichen Element Details einblenden.
Wir stellen uns eine Zukunft vor, in der jedes führende Unternehmen ein maßgeschneidertes Deep-Research-System für seine wichtigsten Abläufe einsetzt. Daraus werden jederzeit verfügbare analytische Fachkräfte, die zuverlässig Tausende interne Materialien durchsuchen und Entscheidungen sowie Arbeitsergebnisse erstellen, auf deren Grundlage Menschen handeln können. Während Frontier-Modelle die Grenzen des Machbaren verschieben, werden die Grundlagen zum Unterscheidungsmerkmal: Daten erreichbar machen, dem System eine Karte geben und Zuverlässigkeit durch Evaluationen im Betrieb verankern.
Die Fortschritte bei der Modellleistung im vergangenen Jahr zeigen am deutlichsten, wohin die Entwicklung führt. Für Führungskräfte bietet sich 2026 die Chance, früh zu handeln. Wähle einen Einstiegspunkt mit klar erkennbarem Nutzen, schaffe Vertrauen durch Herkunftsnachweise und Leitplanken und entwickle deine Deep-Research-Lösung vom Pilotprojekt zu einer stetig wachsenden Fähigkeit, die das Unternehmen täglich nutzt.