KI-Research-Tools bewerten: Ein beständiges Framework

Die KI-Tool-Landschaft verändert sich wöchentlich. Spezifische Prompts, Modellbezeichnungen und Anbieter-Funktionen werden bis zum Ende dieses Artikels schon wieder anders aussehen. Stand: Mai 2026.

Eine Liste aktueller Tools wäre obsolet, bevor die Tinte trocknet. Was folgt, ist ein beständiges Framework zur Bewertung jeder Plattform: was zu fragen ist, was zu fordern ist, wann man Abstand nimmt.

Foundational Models vs. Wrapper Tools

Die KI-Landschaft lässt sich grob in zwei Kategorien unterteilen.

Foundational Services: die zugrundeliegenden LLMs. Eine Handvoll Anbieter baut sie, alles andere läuft darauf auf.

Wrapper Tools: SaaS-Plattformen, die auf diesen Engines aufbauen. Komfort, schöne Oberflächen, vorgefertigte Workflows. Sie verbergen meist ihre System-Prompts und die konkrete Modellversion und tauschen Ihre Kontrolle gegen Bequemlichkeit ein.

Das Vier-Prinzipien-Bewertungsraster

Prüfen Sie jedes KI-Research-Tool gegen vier Kriterien. Fällt es bei einem durch, nutzen Sie es nicht.

1. Datenschutz

Dieses Kriterium ist nicht verhandelbar, denn eine einzige schlechte Antwort hier kann Ihre Studie in einen DSGVO-Vorfall verwandeln.

Ich weiß, dass das Lesen des AVV mühsam ist, aber lesen Sie ihn trotzdem, denn dort stehen die tatsächlichen Pflichten.

2. Transparenz

Verraten sie Ihnen die konkrete Modellversion, die das Tool antreibt? Und welche Version einen bestimmten Output erzeugt hat?

Wenn die Antwort „unsere proprietäre KI-Technologie" lautet, können Sie nicht:

• Bekannte Verzerrungen oder Einschränkungen des verwendeten Modells einschätzen.
• Die Leistung mit Alternativen vergleichen.
• Erklären, warum sich Outputs von einer Woche zur nächsten verändern.
• Ein Ergebnis sechs Monate später reproduzieren.

Pinnen Sie die Version, wo möglich. Loggen Sie die Version, wo nicht.

3. Export

Können Sie Ihre Rohdaten in einem sauberen Tidy-Data-Format exportieren?

• Ein gutes Zeichen ist ein vollständiger Export nach CSV, JSON oder in ein anderes Standardformat.
• Ein schlechtes Zeichen ist, wenn der einzige Weg zu Ihren Daten darin besteht, den Support zu kontaktieren und sie anzufordern.
• Die Falle ist, wenn nur KI-generierte Zusammenfassungen exportiert werden und nicht die Originaltranskripte.

Sind Ihre Daten in einem proprietären Format eingesperrt, gehören sie Ihnen nicht wirklich, und das ist Grund genug, das Tool nicht weiter zu nutzen.

4. Reproduzierbarkeit

Führen Sie dieselbe Analyse zweimal durch. Ist das Ergebnis identisch?

Inkonsistente Tools sind fürs Brainstorming in Ordnung. Für verteidigbare Forschung sind sie nicht akzeptabel.

Was „Seed setzen" bedeutet

Ein Seed ist eine Zahl, die die zufälligen Teile davon initialisiert wie ein Modell sein nächstes Wort wählt. Selber Seed plus selber Input plus selbe Modellversion plus Temperature 0 ergibt denselben Output. Meistens.

Das „meistens" arbeitet hier. Anbieter beschreiben ihre Seed-Parameter als Best-Effort, nicht als Determinismus-Garantie. Drei Gründe warum Outputs driften können, selbst wenn alles fixiert aussieht:

• Stiller Modell-Tausch. Cloud-Anbieter aktualisieren Modellversionen auf ihrer Seite. Dein Seed ist fixiert, aber das Modell darunter hat gewechselt. OpenAI's API liefert ein system_fingerprint-Feld zurück, das diesen Wechsel signalisiert, sodass du ihn zumindest erkennen kannst. Die meisten anderen Anbieter zeigen nichts vergleichbares.
• Floating-Point-Nicht-Determinismus auf GPUs. Dieselbe Berechnung in unterschiedlicher Reihenfolge auf einer GPU kann leicht abweichende Zahlen liefern, was die Wahl des Modells an einer Stelle kippen kann.
• Batching-Effekte. Mixture-of-Experts-Architekturen routen Anfragen über unterschiedliche interne Pfade, abhängig davon was sonst gerade im Batch ist.

API-Endpunkte exponieren typischerweise einen Seed-Parameter (OpenAI und Google tun das; Anthropic Stand heute nicht). Die meisten Consumer-Chat-Oberflächen exponieren keine solche Kontrolle.

Praktische Schlussfolgerung: Reproduzierbarkeit kommt in Abstufungen, nicht absolut. Seed und Temperature fixieren. Modellversion protokollieren. Self-Hosting eines Open-Weight-Modells beseitigt das Problem des stillen Modell-Tauschs komplett. Nichts davon liefert bit-genau identische Outputs bei jedem Lauf, aber es kommt nahe genug, um einen Befund verteidigen zu können.

Für die Techniken, die bestimmen, worauf bei Tool-Fähigkeiten zu achten ist, siehe Fortgeschrittene KI-Techniken für Research.

EU AI Act und DSGVO

Der EU AI Act ist seit August 2024 in Kraft. Pflichten greifen schrittweise bis 2026 und 2027. UX Research ist nicht ausgenommen.

Drei Punkte sind für die Tool-Bewertung relevant:

• Transparenzpflichten für KI-generierte Inhalte. Outputs, die wie menschlich erzeugt wirken (Text, Bild, Audio), müssen als KI-generiert gekennzeichnet werden, wenn Adressat:innen sie sonst verwechseln könnten.
• Dokumentations- und Logging-Pflichten gelten für Hochrisiko-Anwendungen. „Hochrisiko" ist rechtlich definiert; klassische Marktforschung ist meist nicht hochrisikorelevant. Forschung, die in HR-, Kredit- oder biometrische Entscheidungen einfließt, kann es sein.
• Die DSGVO gilt unverändert weiter. AI-Act-Pflichten kommen oben drauf, sie ersetzen nichts.

Wo es sich kumuliert: Forschung mit Teilnehmendendaten ist DSGVO-relevant per Default. Sobald ein LLM in der Analyse-Pipeline steckt, können AI-Act-Pflichten zu Transparenz und Logging hinzukommen. Die Kriterien Transparenz und Reproduzierbarkeit aus dem Raster oben sind damit nicht mehr nur Best Practice, sie entsprechen direkt Dokumentations- und Logging-Pflichten unter dem AI Act für viele Research-Anwendungen.

Praktische Konsequenz für die Anbieterbewertung: Die Dokumentation muss auf DSGVO und AI Act gleichzeitig eingehen, nicht auf eines von beiden. Ein Anbieter, der über DSGVO spricht und zum AI Act schweigt, hat seine Hausaufgaben nicht gemacht. Andersherum genauso.

Kann ein Anbieter das nicht in einem Satz beantworten, kann er es nicht beantworten.

API-first und MCP

Die wahre Stärke von KI in der Forschung liegt nicht in einem einzelnen Tool, sondern darin, Tools zu einem Workflow zu verbinden, den Sie kontrollieren.

Behandle deine Tools als Bausteine, die über APIs verbunden sind. Eine API (Application Programming Interface) ist die standardisierte Art wie ein Dienst mit einem anderen spricht: schick eine Anfrage, bekomm eine strukturierte Antwort zurück. Statt durch das UI eines Anbieters zu klicken, schreibst du die Anfrage einmal und lässt sie laufen.

[Datenerhebung] → [Transkriptions-API] → [Analyse-LLM] → [Visualisierung]

Jeder Baustein ist austauschbar: tausche den Transkriptions-Dienst ohne den Rest neu zu bauen. Prompts werden versioniert, so wie Entwickler Code versionieren. Inputs und Outputs werden protokolliert und liefern einen Audit-Trail. Die Rolle verschiebt sich vom Bedienen einzelner Tools zum Orchestrieren einer Pipeline, die du kontrollierst.

Model Context Protocol (MCP)

Vor MCP war jede Integration zwischen einem LLM und einem externen System maßgeschneidert. Eine Transkriptions-Pipeline, die für das Modell eines Anbieters gebaut wurde, musste für den nächsten neu gebaut werden. Das Model Context Protocol definiert eine geteilte Schnittstelle, die beide Seiten implementieren, sodass dieselben Tool-Definitionen modellübergreifend funktionieren. Mehrere Anbieter unterstützen es.

Für Research die praktischen Vorteile:

• Portabilität zwischen Anbietern. Dieselben Tool-Definitionen funktionieren mit unterschiedlichen LLMs.
• Sauberere Reproduzierbarkeit. Tool-Aufrufe und ihre Ergebnisse sind explizit, strukturiert und loggbar.
• Einfacherer Anbieterwechsel. Wenn sich Pricing oder Funktionen verschieben, und das tun sie, bleibt die Integrationsfläche stabil.

Vorteile von API-first

Wann Wrapper Tools sinnvoll sind

Trotz der Argumente für direkten API-Zugang passen Wrapper Tools, wenn:

• Ihnen die Engineering-Kapazität für eigene Workflows fehlt.
• Der Anwendungsfall klar definiert ist und das Tool genau dafür gebaut.
• Geschwindigkeit bis zum Insight wichtiger ist als Anpassbarkeit.
• Das Tool alle vier Kriterien des Rasters besteht.

Für ein praktisches Beispiel der Anwendung dieser Kriterien auf einen realen Analyse-Workflow, siehe KI-gestützte thematische Analyse: Ein praktischer Workflow.

Lokale Modelle und On-Prem

Bis hierher hat dieser Artikel angenommen, dass du KI über Cloud-APIs von Anbietern wie OpenAI, Anthropic oder Google nutzt. Es gibt eine andere Option: die Modelle selbst auf eigener Hardware laufen lassen. Der Begriff dafür ist „Self-Hosting" oder „On-Prem".

Die Cloud-LLM-Ökonomie wird 2026 schräg. Token-Preise für Frontier-Modelle bleiben hoch, Rate Limits eng, Throttling unter Last ist real, und Kosten sind bei Batch-Jobs jeder Größe schwer planbar.

Open-Weight-Modellfamilien haben den Qualitätsabstand für typische Research-Aufgaben weitgehend geschlossen: Zusammenfassungen, strukturierte Extraktion, thematisches Clustering, Code-Generierung. Der Abstand ist nicht für jede Aufgabe und nicht an der absoluten Spitze geschlossen, aber er hat sich weit genug verringert, dass Self-Hosting für einige Workloads jetzt eine vernünftige Option ist.

Was Sie bekommen:

• Datenschutz. Daten verlassen Ihre Infrastruktur nie. Ihre Sub-Processor-Liste schrumpft. Self-Hosting vereinfacht außerdem die AI-Act-Dokumentation: volle Kontrolle über den Datenfluss macht Logging und Audit-Trails geradlinig.
• Reproduzierbarkeit. Sie kontrollieren die Modellversion. Keine stillen Updates, die Ergebnisse vom letzten Quartal brechen.
• Kostenplanbarkeit. Hardware amortisiert sich über Jahre der Nutzung, während Token für die Lebensdauer des Workloads ein Aufwand pro Anfrage bleiben.

Was es kostet:

• Hardware. GPUs sind teuer, und sie laufen leer, wenn Sie sie nicht nutzen.
• Ops-Aufwand. Jemand muss das System am Laufen halten.
• Langsamere Iteration am vordersten Rand der Modelle. Sie werden nicht die Ersten sein, die das Nächste ausprobieren.
• Sie müssen es tatsächlich betreiben. Es gibt keine Hotline, und alles, was bricht, müssen Sie selbst diagnostizieren und beheben.

Der Sweet Spot sind sensible Teilnehmendendaten, wiederholbare Batch-Pipelines und Arbeit, die nicht die absolute Spitze braucht.

Das ist kein Argument dafür, alles auf lokal umzustellen. Self-Hosting ist für manche Use Cases machbar, aber nicht für alle.

Anwendung des Frameworks

Bei der Bewertung eines neuen KI-Research-Tools arbeiten Sie diese Checkliste durch.

Datenschutz

• Zero Data Retention vertraglich dokumentiert?
• EU/EWR-Verarbeitung für Teilnehmendendaten?
• Sub-Processor-Liste verfügbar?
• Einwilligung deckt KI-Verarbeitung ab?

Transparenz

• Konkrete Modellversion offengelegt?
• Modellversionsänderungen vorab kommuniziert?
• System-Prompts zugänglich oder dokumentiert?
• Anbieterdokumentation referenziert DSGVO und EU AI Act?

Export

• Daten in Standardformaten exportierbar?
• Vollständiger Export, nicht nur Zusammenfassungen?
• Kein Lock-in in proprietäre Formate?

Reproduzierbarkeit

• Konsistente Outputs bei gleichen Inputs?
• Seed- und Temperatur-Kontrollen verfügbar?
• Workflow-Versionierung möglich?

Für die breitere Research-Technologielandschaft, siehe Research Tools und die ResTech-Landschaft.

Was das für die Praxis bedeutet

Die konkreten Tools werden sich quartalsweise ändern, aber die Prinzipien, anhand derer Sie sie bewerten, nicht.

Bewerten Sie jede KI-Plattform anhand von Datenschutz, Transparenz, Export und Reproduzierbarkeit. Dazu kommt die Regulierung: zuerst DSGVO, dann AI Act. Bauen Sie Workflows, die Sie kontrollieren, mit Komponenten, die Sie inspizieren können.

Für das grundlegende Verständnis, was KI in Research leisten kann und was nicht, siehe Was KI für UX Research leisten kann und was nicht.

Um zu quantifizieren, ob sich eine KI-Tool-Investition lohnt, nutzen Sie den Research Value Calculator (Lohnt sich Ihre Studie?).