Warum toolübergreifende Incident Response heute eine eigene Kategorie ist

Es ist 2:07 Uhr nachts. Eine Alarmierung wird ausgelöst. Sie öffnen Slack, und dort läuft bereits die erste Diskussion. Ein Engineer teilt einen Datadog-Graphen. Ein anderer arbeitet in der AWS-Konsole. Ein dritter prüft die letzten GitHub-Commits. Und jemand anderes schaut in Jira nach, welche Änderungen es diese Woche gab.

Der Incident wird irgendwann gelöst. Das Postmortem wird geschrieben. Die Maßnahmen landen in Jira. Und vier Wochen später tritt eine andere Version desselben Incidents erneut auf – weil der Koordinationsaufwand, der bereits die erste Incident Response ausgebremst hat, nie wirklich reduziert wurde.

‍

Der entscheidende Punkt: Nicht der Incident war das Problem, sondern die Koordination.

‍

Mit jeder einzelnen Entscheidung ist Ihr Tech-Stack im Lauf der letzten Jahre gewachsen: Datadog oder Grafana für Metriken und Dashboards. GitHub für Source Control und CI. Terraform für die Infrastruktur. LaunchDarkly für Feature Flags. AWS als Basis für alles. Jira für Tickets, Slack für die Koordination, PagerDuty oder Opsgenie für Alarmierung und Bereitschaftsmanagement. Einige Tools haben Sie selbst ausgewählt, andere vielleicht übernommen. Und jedes einzelne funktioniert gut.

‍

Aber um 2 Uhr nachts bedeutet jedes einzelne Tool auch einen eigenen Tab.

‍

Mit jedem Tool, das Ihr Team eingeführt hat, um Incidents besser zu verstehen, kam eine weitere Oberfläche hinzu, deren Informationen während eines Incidents manuell zusammengeführt werden müssen. Mehr Observability bedeutet damit auch mehr Koordinationsaufwand – und genau das ist die Ironie moderner Ops-Stacks.

Jetzt kommt KI ins Spiel: AI-SRE-Tools werden als Lösung positioniert, doch die meisten funktionieren vor allem innerhalb des Datenökosystems des jeweiligen Anbieters. Eine KI, die nur auf Basis der Daten schlussfolgern kann, auf die sie zugreifen kann, ist keine Cross-Stack-Plattform. Sie ist lediglich eine intelligentere Version desselben isolierten Tools, das Sie bereits nutzen.

In diesem Leitfaden zeigen wir Ihnen, wie Sie AI-SRE-Plattformen anhand dieser Anforderungen bewerten können. Außerdem geben wir Ihnen konkrete Fragen an die Hand, mit denen Sie erkennen, welche Anbieter diese Anforderungen tatsächlich erfüllen – und welche lediglich zusätzlichen KI-Noise in Ihre Alarmierungsprozesse bringen. 

Koordinationskosten: der Preis, den Sie bereits zahlen

Die Koordinationskosten sind der Preis, den Ihr Team jedes Mal zahlt, wenn bei einem P1-Incident zunächst ein Mensch Informationen aus verschiedenen Tools manuell zusammentragen muss, bevor überhaupt mit der Diagnose begonnen werden kann. Dabei handelt es sich nicht um eine Lücke in Ihrem Tooling, sondern um einen strukturellen Aufwand, der bei jedem Incident anfällt.

Schauen wir uns an, welche Kosten ein einzelner P1-Incident verursacht. Die folgenden Standardwerte sind bewusst konservativ gewählt. Im Rechner können Sie Ihre eigenen Zahlen einsetzen.

‍

Aufschlüsselung der Koordinationskosten

• Überblick verschaffen: 12–18 Minuten, um die Informationen aus Datadog, AWS, GitHub und Jira zu einem schlüssigen Gesamtbild zusammenzuführen.
• Ineffizienter Einsatz hochqualifizierter SREs: Ihre erfahrensten Engineers werden in Incidents eingebunden, die auch ein weniger erfahrener Engineer – oder eine KI – bearbeiten könnte, wenn der Kontext bereits vollständig vorliegen würde.
• Erhöhung der Mean Time to Recovery: Jede Minute Verzögerung durch Koordinationsaufwand bedeutet eine weitere Minute mit Beeinträchtigungen für die Nutzer.
• Opportunitätskosten nach dem Incident: Das Postmortem-Meeting dient unter anderem zur nachträglichen Rekonstruktion des Kontexts – obwohl eine automatische Zusammenstellung möglich gewesen wäre.

Diese Zahlen berücksichtigen noch nicht die persönlichen Auswirkungen auf das Team: zum Beispiel den Senior SRE, der nach einer weiteren anstrengenden Bereitschaftswoche darüber nachdenkt, das Team zu verlassen. Oder den frustrierten VP Engineering, der sieht, wie sich die Roadmap um ein Quartal verschiebt, weil seine besten Leute immer wieder in Incidents gebunden werden, die sie nicht verursacht haben.

Die Koordinationskosten tauchen in keinem Budget als eigener Posten auf. Ihre Auswirkungen sind trotzdem überall spürbar: in höherer Fluktuation, verzögerten Roadmaps und Postmortem-Maßnahmen, die nie umgesetzt werden, weil das Team längst mit dem nächsten Incident beschäftigt ist.

Warum „Einfach alles von einem Anbieter nehmen" nicht die richtige Lösung ist

‍

Alle großen Observability-Anbieter argumentieren ähnlich: „Unsere KI funktioniert am besten mit unseren eigenen Daten. Konsolidieren Sie Ihre Tools auf unserer Plattform, dann können wir Ihnen eine intelligente, automatisierte Incident Response bieten.“ In einer Demo klingt das überzeugend. In der Praxis funktioniert dieser Ansatz jedoch nicht.

Denn die Festlegung auf einen einzigen Anbieter scheitert gleich in drei Bereichen:

‍

Migrationsaufwand 

Eine echte Migration des Tech-Stacks – also die Überführung von Metriken, Logs, Traces und Alarmierungen verschiedener Anbieter auf eine einzige Plattform – ist ein Projekt, das in der Regel mehr als ein Jahr dauert und parallel zum laufenden Betrieb umgesetzt werden muss. Und das ist bereits das optimistische Szenario: für Teams mit eigenen Ressourcen, Rückhalt im Unternehmen und ausreichend technischen Kapazitäten, um die Migration neben dem Produktivbetrieb zu stemmen.

Die meisten Teams haben diese Voraussetzungen nicht – und Incidents nehmen keine Rücksicht darauf, dass Sie gerade zu einem anderen Anbieter migrieren.

‍

Begrenzungen durch Architektur

Selbst wenn die Migration abgeschlossen ist, bleibt ein grundlegendes Problem: Incidents entstehen nicht nur in Observability-Daten. Ein Deployment, das den Ausfall verursacht hat, wurde über GitHub ausgerollt, eine in Terraform vorgenommene Konfigurationsänderung hat zur Regression geführt oder der Feature Flag, der umgeschaltet wurde, liegt in LaunchDarkly. Kein einzelner Observability-Anbieter verfügt über all diese Daten – und das wird auch künftig nicht der Fall sein.

Sie brauchen nicht alle Daten. Entscheidend sind die richtigen Daten – korreliert über die Tools hinweg, in denen sie tatsächlich liegen. Die beste Root-Cause-Analyse entsteht nicht bei dem Anbieter, der die meisten Telemetriedaten erfasst. Sie entsteht auf der Plattform, die ein Deployment-Event in GitHub mit einem Anstieg der Fehlerrate in Datadog und einem Pod-Neustart in AWS verknüpfen kann – ohne dass dafür eine Migration erforderlich ist.

‍

Risiko durch Kostenkonzentration

Die gesamte Observability zu einem einzigen Anbieter zu migrieren, um KI-Funktionen nutzen zu können, ist nicht nur eine technische, sondern auch eine Governance-Entscheidung. Denn Sie bündeln Anbieter-, Datensouveränitäts- und Preisrisiken in einem einzigen Vertrag. Wenn die KI-Funktionen des Anbieters nicht die erwarteten Ergebnisse liefern, sind die Migrationskosten bereits angefallen. Erhöht der Anbieter seine Preise, verschlechtert sich Ihre Verhandlungsposition erheblich. Wird das Unternehmen übernommen, hängt Ihre Roadmap von den Prioritäten eines anderen Unternehmens ab.

Die richtige Strategie, um Koordinationskosten zu senken, besteht nicht darin, die Vielfalt des Stacks zu beseitigen, sondern den Aufwand zu reduzieren, der während eines Incidents durch die Koordination dieser verschiedenen Systeme entsteht. Das sind zwei verschiedene Probleme, die unterschiedliche Lösungen erfordern.

So sieht toolübergreifende Incident Response in der Praxis aus

Vertrauen vor Autonomie: das dreistufige Autonomiemodell

‍

Eine KI, die während eines Incidents eigenständig handeln kann, kann einen Incident auch verschlimmern. Anbieter, die diese Tatsache ausblenden, verkaufen Ihnen eine Demo. Anbieter, die sie von Anfang an berücksichtigen, entwickeln eine Plattform für den produktiven Einsatz.

Bevor Ihr Security-Team ein AI-SRE-Tool freigibt, sollte es genau wissen, was das System tatsächlich kann – und was nicht. Und bevor Ihr Engineering-Team der KI so weit vertraut, dass es ihre Empfehlungen umsetzt, muss sie sich dieses Vertrauen erst verdienen – und zwar in Ihrer Umgebung, anhand Ihrer Incidents und mit Ihren Daten.

Autonomie ist keine Funktion, die man einfach aktiviert. Sie ist ein Reifeprozess, den man schrittweise durchläuft.

‍

Stufe 1: Nur Lesezugriff

Der Agent führt die Analyse durch: Er sammelt Kontext, korreliert Signale, identifiziert die wahrscheinliche Ursache und schlägt Erkenntnisse sowie nächste Schritte vor. Jeder Schritt wird protokolliert und kann überprüft werden. Änderungen nimmt der Agent nicht vor. Die Entscheidung und Umsetzung liegen beim Menschen und erfolgen über die bestehenden Tools des Teams.

‍

Stufe 2: Beaufsichtigte Ausführung

Der Agent kann eine klar definierte Auswahl risikoarmer Aktionen ausführen, zum Beispiel Logs abrufen, Diagnosen durchführen oder Status-Updates zur Veröffentlichung durch einen Menschen vorbereiten. Für alle Maßnahmen mit weitreichenderen Folgen ist eine ausdrückliche Freigabe erforderlich. Der Mensch als Kontrollinstanz ist dabei bewusst in den Prozess eingebunden und nicht nur als Notlösung vorgesehen.

‍

Stufe 3: Autonomes Handeln innerhalb definierter Richtlinien

Für eine klar definierte Kategorie von Incidents – gut verstandene Routinefälle, die sich anhand von bereits erprobten Lösungen eindeutig zuordnen lassen – handelt der Agent innerhalb der konfigurierten Richtlinien autonom. Menschen werden nur dann benachrichtigt, wenn der erforderliche Vertrauensschwellenwert nicht erreicht wird oder der Incident-Typ außerhalb des festgelegten Anwendungsbereichs liegt.

Der einfachste Weg, um die tatsächlichen Fähigkeiten einer KI von reinen Marketingversprechen unterscheiden zu können: Fragen Sie den Anbieter, auf welcher Stufe sein Produkt bereits produktiv bei einem vergleichbaren Kunden eingesetzt wird. Ein Anbieter, der auf Vertrauen setzt, wird Ihnen diese Frage in einem Satz beantworten und Ihnen die entsprechende Kontrollfunktion direkt im Produkt zeigen. Ein Anbieter, der vor allem die Demo verkauft, verweist auf die Roadmap.

Bevor Ihr Security- und Compliance-Team ein AI-SRE-Tool für den produktiven Einsatz freigibt, sollte es sechs Punkte überprüfen.

Was Ihr Security-Team prüfen wird

‍

Sicherheits-Checkliste

• Audit Trails: Jeder Schritt des Agents wird protokolliert, ist nachvollziehbar und kann im Nachhinein von Menschen überprüft werden: welche Daten er analysiert hat, zu welchem Ergebnis er gekommen ist und welche Maßnahmen er vorgeschlagen hat.
• Datenresidenz: Regionale Endpunkte für die Datenverarbeitung sowie die Möglichkeit festzulegen, wo Incident-Daten – einschließlich AI-Workloads – verarbeitet und gespeichert werden.
• Anwendbares Recht: Welches Landesrecht für das Unternehmen gilt, mit dem Sie den Vertrag schließen – also für die Partei, die auf Anwendungsebene Zugriff auf Ihre Daten hat. Zusätzlich sollte eine veröffentlichte Liste der Subprozessoren für die Infrastruktur vorhanden sein.
• Opt-out für Modelltraining: Ihre Incident-Daten werden ohne Ihre ausdrückliche Zustimmung nicht zum Training von Modellen verwendet.
• Key Management (BYOK): Sie kontrollieren die Encryption Keys – sie sollten entweder bereits verfügbar oder verbindlich auf der Roadmap vorgesehen sein.
• Verbindlich begrenzte Autonomie: Was der Agent tun darf und was nicht, wird direkt im Produkt konfiguriert und technisch durchgesetzt – je nach Incident-Klasse. Diese Grenzen dürfen nicht nur in einem Richtlinien-PDF beschrieben sein.

Ein P1-Incident mit KI-Analyse – Minute für Minute

‍

Schauen wir uns dasselbe Szenario von um 2:07 Uhr noch einmal an – diesmal mit einer toolübergreifenden AI-SRE-Plattform.

‍

Incident-Timeline, P1 · Beeinträchtigung des Checkout-Service

Der Engineer wurde um 02:07 Uhr alarmiert – die Alarmierung wartet nie auf die KI. Drei Minuten später lagen bereits ein vollständiger Incident-Verlauf, eine wahrscheinliche Ursache mit nachvollziehbaren Belegen und ein konkreter Lösungsvorschlag vor. Kein Wechsel zwischen Tabs. Kein mühsames Durchsuchen alter Slack-Verläufe. Kein Rätselraten.

Und die KI hat zu keinem Zeitpunkt direkt in die Produktivumgebung eingegriffen: Der vorgeschlagene Schritt musste vom Engineer freigegeben werden, und das Rollback wurde über die eigene Deployment-Pipeline des Teams ausgeführt.

So sieht toolübergreifende Incident Response in der Praxis aus. Kein Chatbot. Keine priorisierte Liste von Alarmierungen. Sondern eine nachvollziehbare Analyse, eine Korrelations-Engine, die Telemetriesignale mit Änderungen und dem aktuellen Status der Infrastruktur verknüpft, und dem Engineer bereits in den ersten Minuten eines Incidents eine fundierte Hypothese liefert – statt erst nach 20 Minuten mühsamer Suche in verschiedenen Tools.

So entwickelt sich diese Fähigkeit im Laufe der Zeit weiter:

Der weitere Entwicklungspfad: Jetzt, als Nächstes, Zukunft

‍

Jetzt: Analyse auf Abruf

Der Engineer startet direkt aus einer Alarmierung oder einem Incident eine Analyse. Der Agent sammelt den relevanten Kontext, korreliert Deployment-Events, Telemetriedaten und den Status der Infrastruktur über die verschiedenen Tools hinweg und schlägt Erkenntnisse sowie nächste Schritte vor. Ausschließlich mit Lesezugriff. Der Engineer erhält den nötigen Kontext statt zusätzlichem Noise und trifft die Entscheidung.

‍

Als Nächstes: Schrittweise mehr Handlungsspielraum

Für definierte Alarmierungsklassen werden Analysen automatisch gestartet. Hinzu kommen überwachte Low-Risk-Aktionen, Diagnosen und Entwürfe für die Incident-Kommunikation – jeweils nur nach ausdrücklicher Freigabe.

‍

Die Zukunft: Autonome Lösung innerhalb eines fest definierten Rahmens

Für klar definierte Incident-Klassen mit bekannten Mustern löst der Agent Incidents innerhalb der vom Team festgelegten Richtlinien selbstständig. Menschen übernehmen neue, ungewöhnliche oder risikoreiche Fälle – mit Human-in-the-Loop-Kontrollen über den gesamten Stack hinweg.

Dieses Ziel erreichen Sie nicht, indem Sie einfach einen Schalter umlegen. Die Autonomie wird schrittweise erweitert – Incident-Klasse für Incident-Klasse, sobald die Plattform bewiesen hat, dass sie innerhalb des jeweiligen Rahmens zuverlässig handeln kann.

Fünf Kriterien, die toolübergreifende von Single-Stack-Lösungen unterscheiden

Wenn Sie sich für eine AI-SRE-Plattform interessieren, zeigen Ihnen die meisten Anbieter eine Demo mit einem Szenario, das ungefähr so aussieht: Eine Alarmierung wird ausgelöst, die KI identifiziert eine wahrscheinliche Ursache und jemand klickt auf „Resolve“. Die Demo ist so aufgebaut, dass sie der oben beschriebenen Timeline möglichst nahekommt.

Die entscheidende Frage ist jedoch, ob die Plattform dieses Szenario auch in Ihrer eigenen Umgebung abbilden kann – mit Ihrem Tech-Stack, Ihren Daten und Ihren typischen Incident-Mustern.

Diese fünf Kriterien helfen Ihnen dabei, die tatsächlichen Fähigkeiten der Plattform über die Demo hinaus zu bewerten.

Kriterium Nr. 1:  Signalabdeckung

Kann die Plattform Alarmierungen und Kontext aus Ihren bestehenden Tools verarbeiten, ohne dass dafür eine Migration erforderlich ist? Single-Stack-Lösungen beantworten diese Frage oft mit einer Einschränkung: „Wir unterstützen die Datenübernahme aus X und Y, aber die KI liefert die besten Ergebnisse mit Daten, die innerhalb unserer eigenen Plattform liegen.“

Hier sollten Sie hellhörig werden: Eine wirklich toolübergreifende Plattform arbeitet mit den bereits vorhandenen Signalen dort, wo sie entstehen.

Kriterium Nr. 2: Korrelation von Änderungen

Kann die Plattform Deployment-Events, Konfigurationsänderungen und Änderungen an Feature Flags automatisch mit der Incident-Timeline verknüpfen?

Fragen Sie jeden Anbieter ganz konkret: „Wie geht Ihre KI mit einem Incident um, der durch ein Deployment ausgelöst wurde, wenn dieses Deployment in einem Tool stattgefunden hat, das Sie nicht überwachen?“

An der Antwort erkennen Sie schnell, ob die Plattform für Ihren Tech-Stack entwickelt wurde – oder vor allem für das eigene Ökosystem des Anbieters.

Kriterium Nr. 3: Zusammenführung zu einem schlüssigen Incident-Verlauf

Kann die KI aus den verfügbaren Informationen einen schlüssigen Incident-Verlauf erstellen – statt lediglich eine priorisierte Liste von Alarmierungen auszugeben – auf dessen Basis ein Engineer sofort handeln kann?

Die Reduzierung der Alarmflut und eine schnellere Root-Cause-Analyse sind zwei unterschiedliche Dinge. Weniger Noise ist inzwischen eine Grundvoraussetzung. Toolübergreifende Plattformen zeichnen sich dadurch aus, dass sie Signale aus verschiedenen Tools zu einer Hypothese zusammenführen und diese als strukturierte, nachvollziehbare und mit Belegen versehene Darstellung präsentieren.

Kriterium Nr. 4: Kontrolle der Autonomie

Wie sieht das Human-in-the-Loop-Modell in der Praxis tatsächlich aus – direkt im Produkt und nicht nur im Marketing?

Fragen Sie den Anbieter konkret, auf welcher Stufe der Entwicklung von Read-only über überwachte Aktionen bis hin zu autonomem Handeln sich das Produkt heute befindet. Und prüfen Sie, ob die jeweiligen Grenzen direkt über die Konfiguration des Produkts festgelegt und technisch durchgesetzt werden – oder lediglich in einem Whitepaper beschrieben sind.

Kann ein Anbieter diese Frage nicht klar und eindeutig beantworten, lässt sich die Plattform nicht sicher einsetzen.

Kriterium Nr. 5: Roadmap – wie sieht die weitere Entwicklung aus?

Wohin entwickelt sich der Anbieter – und kann er einen glaubwürdigen Weg von der Analyse bis hin zu kontrollierter Autonomie aufzeigen, und zwar anhand konkreter Produktfunktionen statt mit Marketingversprechen?

Anbieter, die diese Frage nicht konkret beantworten können, entwickeln eher einzelne Features als eine echte Plattform. Noch problematischer sind Anbieter, die ihre Roadmap so darstellen, als wären geplante Funktionen bereits heute verfügbar: Sie zeigen damit, wie sie es mit der Wahrheit halten werden, sobald Sie sich für das Produkt entschieden haben.

Zehn Fragen, die Sie jedem AI-SRE-Anbieter stellen sollten

Diese Fragen helfen Ihnen dabei, die strukturellen Grenzen von Single-Stack-Ansätzen sichtbar zu machen – ohne einzelne Anbieter beim Namen zu nennen. Nutzen Sie sie in Gesprächen oder teilen Sie diesen Abschnitt vor einer Evaluierung mit Ihrem Team.

Denn nicht die Demo ist entscheidend, sondern die Antworten auf diese Fragen – und vor allem, wie konkret und aussagekräftig sie ausfallen.

‍

Frage Nr. 1: „Ist Ihre KI darauf angewiesen, dass Daten in Ihre Plattform übertragen werden, oder kann sie auch mit Signalen aus Tools außerhalb Ihres eigenen Ökosystems arbeiten?”

Frage Nr. 2: „Wie geht Ihre Plattform mit einem Incident um, der durch ein Deployment ausgelöst wurde, wenn dieses Deployment in einem Tool stattgefunden hat, das Sie nicht überwachen?“

Frage Nr. 3: „Wie viele Integrationen unterstützt Ihre Plattform standardmäßig und wie schnell können wir unseren bestehenden Tech-Stack anbinden?“

Frage Nr. 4: „Muss mein Team mit Ihrer Lösung ein weiteres Tool in den Incident-Response-Prozess integrieren, oder ist sie direkt in die Plattform eingebunden, die wir bereits für Alarmierung und Bereitschaftsmanagement nutzen?“

Frage Nr. 5: „Benötigen wir zusätzlich zu Ihrer AI SRE weiterhin eine separate Incident-Management-Plattform?“

Frage Nr. 6: „Auf welcher Autonomiestufe arbeitet Ihr Produkt heute und welche Möglichkeiten haben wir, den Handlungsspielraum zu begrenzen?“ 

Frage Nr. 7: „Wo werden meine Daten verarbeitet? Kann ich regionale Endpunkte auswählen? Kann ich der Nutzung meiner Daten für das Modelltraining widersprechen? Kann ich meinen eigenen API-Key verwenden?“ 

Frage Nr. 8: „Wie entwickelt sich Ihr Preismodell, wenn wir weitere Tools aus unserem Stack anbinden? Entstehen durch zusätzliche Integrationen höhere Kosten?“

Frage Nr. 9: „Wie läuft das Onboarding ab? Wie schnell sehen wir in unserer eigenen Umgebung einen korrelierten Incident-Verlauf?“

Frage Nr. 10: „Wie stark ist die Anbieterabhängigkeit, wenn wir uns in zwei Jahren für eine andere Plattform entscheiden?“

Auf die Fragen, für die eine Plattform tatsächlich ausgelegt ist, erhalten Sie in der Regel eine klare und konkrete Antwort. Weicht ein Anbieter dagegen aus, lenkt das Gespräch um oder antwortet mit „Gute Frage, das kläre ich und melde mich noch einmal“, deutet das häufig auf strukturelle Grenzen hin, die in einer Demo lieber nicht sichtbar werden sollen.

Kurzfassung

Die Koordinationskosten sind eine reale Größe: Bei jedem P1-Incident, für den zunächst ein Mensch Informationen aus mehreren Tools zusammentragen muss, bevor die Diagnose beginnen kann, entstehen zusätzliche Minuten mit Beeinträchtigungen für die Nutzer und gleichzeitig wertvolle Arbeitszeit hochqualifizierter Engineers.

Die Standardisierung auf einen einzigen Anbieter löst dieses Problem nicht. Das Deployment, das einen Ausfall verursacht hat, liegt möglicherweise in GitHub, die relevante Konfigurationsänderung in Terraform – und keine einzelne Telemetrieplattform wird jemals all diese Datenquellen vollständig abdecken. Entscheidend ist deshalb eine Korrelationsschicht, die über den bereits vorhandenen Tech-Stack hinweg arbeitet.

Bei der Bewertung einer AI-SRE-Plattform sollten Sie deshalb immer auf fünf Kriterien achten: toolübergreifende Signalabdeckung ohne Notwendigkeit einer Migration, Korrelation von Änderungen, Zusammenführung zu einem schlüssigen Incident-Verlauf, Kontrolle der Autonomie und die weitere Entwicklung der Roadmap. Für die Frage nach der Autonomie hilft das Stufenmodell Read-only → überwachte Aktionen → autonomes Handeln.

Eine Frage trennt dabei Marketingversprechen von tatsächlichen Produktfunktionen besonders zuverlässig: Auf welcher dieser Stufen arbeitet Ihr Produkt heute?

Nehmen Sie die zehn Fragen aus diesem Leitfaden mit in jedes Anbietergespräch. Konkrete Antworten zum aktuellen Funktionsumfang zeigen, was die Plattform tatsächlich kann. Ausweichende Antworten zeigen vor allem, was in der Demo gut aussieht.