Über den Pilotbetrieb hinaus: Was es wirklich braucht, um KI mit Beth Williams von Dell in die Produktion zu bringen

Corey Noles: Willkommen bei eSpeaks von eWeek. Ich bin Corey Noles.

An diesem Punkt brauchen die meisten Unternehmen keine weitere Demonstration, dass KI etwas Interessantes leisten kann. Die schwierigere Frage lautet: Was passiert nach der Demo?

Der Übergang von einem erfolgreichen Pilotprojekt zu einer KI, die zuverlässig im gesamten Unternehmen betrieben werden kann, bringt Herausforderungen bei Daten, Infrastruktur, Sicherheit, Governance, Kosten und sogar bei der Frage mit sich, wer letztlich verantwortlich ist, wenn diese Systeme Entscheidungen treffen oder Aktionen ausführen.

Um diesen Übergang mit mir zu erörtern, ist heute Beth Williams von Dell Technologies zu Gast. Beth, vielen Dank, dass du hier bist.

Beth Williams: Hallo, Corey. Vielen Dank für die Einladung.

Corey:Ausgezeichnet. Schön, dass du da bist.

Wir sind inzwischen an einem Punkt angelangt, an dem es überall KI-Pilotprojekte gibt. Aber warum ist der Übergang von einem vielversprechenden Pilotprojekt zu einer echten Produktionsumgebung für so viele Unternehmen weiterhin so schwierig?

Beth:Ja, das sehen wir bei unseren Kunden häufig: Viele Pilotprojekte kommen ins Stocken, und die Beteiligten bleiben einfach in dieser Phase. Ich denke, dafür gibt es viele verschiedene Gründe.

Einer der Hauptgründe ist aus unserer Sicht, dass die Menschen bei Pilotprojekten oder Demos eigentlich nur versuchen, die Technologie zum Laufen zu bringen, richtig? Sie haben also möglicherweise irgendwo ihre eigene kleine Umgebung. Vielleicht verfügen sie über eine schöne kleine GB10 oder etwas Ähnliches. Das ist keine skalierbare Umgebung.

Wahrscheinlich haben sie auch die Daten sorgfältig ausgewählt. Sie haben die Daten kuratiert, alles gefunden und zusammengetragen, damit das Ganze technisch funktioniert. Und vermutlich haben sie auch die Nutzer gezielt ausgewählt, wenn sie das System für eine begrenzte Zahl von Nutzern öffnen. Tatsächlich befinden wir uns gerade bei einem unserer Pilotprojekte in genau diesem Zustand: Wir haben buchstäblich nur eine Teilmenge von Nutzern ausgewählt, die damit experimentieren soll.

Für ein Pilotprojekt ist das alles großartig, aber sobald man in die Produktion wechselt, ist es ein völlig anderes Spiel, richtig?

Zunächst einmal braucht man wahrscheinlich mehr als einen Laptop, auf dem das Ganze läuft. Die Plattform, auf der diese Systeme betrieben werden, ist also ein wesentlicher Teil davon. Viele unserer Kunden haben eine solche Plattform bisher noch gar nicht eingerichtet und nutzen dafür höchstens eine Public Cloud.

Ein weiterer Teil dieser Gleichung sind die Daten. Ich habe bereits erwähnt, dass man in vielen Pilotprojekten die Daten gezielt auswählt, kuratiert und technisch funktionsfähig macht. Beim Übergang in die Produktion braucht man jedoch häufig wirklich automatisierte Daten, richtig? Die Daten sollen verfügbar sein, wenn man sie benötigt, und man muss ihnen vertrauen können. Viele Daten, die wir bei unseren Kunden sehen, sind dafür einfach noch nicht bereit.

Es ist also eine Kombination vieler verschiedener Dinge. Wenn dann noch agentische KI hinzukommt, beobachten wir derzeit, dass viele Menschen agentische Workflows pilotieren, weil sie so leistungsfähig und die Autonomie so attraktiv ist. Sobald man in diesen Bereich vordringt, führt das zu einer wirklich spannenden Sicherheitsdebatte. Du hast wahrscheinlich in letzter Zeit einiges in den Medien darüber gesehen, dass sich Agenten ein wenig verselbstständigen.

Corey:Das haben sie. Sie werden ein wenig verrückt.

Beth:Sie landen in kleinen Foren und unterhalten sich darüber, wie sie aus Sandboxes ausbrechen können, und allerlei andere lustige Dinge. Man muss also wirklich anfangen, darüber nachzudenken, richtig? Das darf nichts sein, worüber man erst nach dem Übergang in die Produktion nachdenkt. Man muss es von Anfang an einbauen. Es geht um Dinge wie Richtlinien, Berechtigungen und Sicherheit.

Und dann stellt sich auch die Frage, wer das Ganze später unterstützen wird. Viele Menschen konzentrieren sich ebenfalls sehr darauf, die Technologie zum Laufen zu bringen. Wenn man dann über den Übergang in die Produktion nachdenkt: Wer wird dafür zuständig sein? Wer ist dafür verantwortlich, ob sich das System korrekt verhält? Wie wird es überwacht? Wie kann man ein Rollback durchführen und so weiter?

All diese Fragen lassen sich nur schwer lösen, wenn man es nicht schon einmal gemacht hat. Wir haben es natürlich bereits getan und können deshalb helfen. Oder man verfügt bereits über eine Plattform, auf die man das System aufsetzen kann, etwa die AI Factory mit NVIDIA. Das ist beispielsweise eine sofort einsatzbereite Plattform, auf der man es betreiben kann. Wie gesagt: Es ist ein Zusammenspiel vieler Faktoren.

Corey:Das leuchtet ein. Auf diesen Unternehmen lastet außerdem großer Druck, weitere KI-Anwendungsfälle zu finden. Aber vielleicht muss nicht jedes Experiment zu einem Produktionssystem werden.

Wie sollten Führungskräfte deiner Meinung nach entscheiden, welche Pilotprojekte tatsächlich eine Skalierung wert sind?

Beth:Ja, ich glaube, viele verfallen in die Denkweise: „Wenn ich ein Pilotprojekt habe, das technisch funktioniert, sollte es immer in die Produktion gehen“, richtig? Beim Pilotieren geht es aber ums Lernen. Im Wesentlichen versucht man herauszufinden, ob etwas für die Nutzer funktionieren wird und ob es technisch funktioniert. Bei KI ist das besonders interessant, zumal man Modelle einsetzt, die möglicherweise halluzinieren.

Was ich Kunden und auch internen Teams vermitteln möchte, ist, dass man bei einem Pilotprojekt emotional nicht daran hängen darf, wohin es als Nächstes geht. Man muss sagen: „Okay, was haben wir gelernt? Können wir das jetzt in die Produktion überführen? Oder sollten wir vielleicht die Ausrichtung dieses Projekts ändern?“

Oder vielleicht sagen wir – das ist das Fail-fast-Modell – einfach: „Das ist für KI nicht geeignet. Wir brauchen etwas, dem wir zu 100 % vertrauen können, und das liefert uns dieses System nicht.“ Dann stoppen wir vielleicht einfach und denken neu darüber nach. Vieles hängt davon ab, ganz nüchtern zu betrachten, wie weit man mit den Pilotprojekten gekommen ist.

Es geht aber auch darum, welche KPIs man während des Pilotprojekts betrachtet. Eine Sache, die wir intern tun und bei der wir auch unsere Kunden unterstützen, ist die sogenannte Nutzennachweis-Phase für ein Pilotprojekt. Wir legen fest, welche KPIs wichtig sind. Diese Dinge weisen wir während des Pilotprojekts nach – nicht nur die technische Funktion, sondern auch, ob das System das gewünschte Geschäftsergebnis liefert. Geht es um Umsatz? Um Kosteneinsparungen? Um eine höhere Leistung? Was genau soll erreicht werden? Diese Werte messen wir während des Pilotprojekts.

Man sollte außerdem berücksichtigen, dass man diese Werte auch nach dem Übergang in die Produktion weiter messen möchte. Das sind keine einmaligen Messungen. Liefert das System all diese Ergebnisse weiterhin?

Eine weitere Sache, die wir bei Dell getan haben – denn übrigens sind Anwendungsfälle nicht das Problem. Ganz sicher nicht. Es gibt Hunderte und Aberhunderte potenzieller Anwendungsfälle. Als wir vor einigen Jahren unsere Reise begannen, hatten wir tatsächlich mehr als 800 Anwendungsfälle, und alle führten kleine Pilotprojekte durch. Da sagten wir: „Leute, wir müssen das wirklich eingrenzen. Wir müssen uns ansehen, was für uns den entscheidenden Unterschied macht.“ Was sind die wirklich wichtigen Anwendungsfälle?

Wir haben uns unser Geschäft angesehen. Was tun wir bei Dell? Am Ende entschieden wir uns für drei oder vier Anwendungsfälle. Das war alles. Drei oder vier Anwendungsfälle, von denen wir wussten, dass sie Dell ausmachen. Wir einigten uns auf alle KPIs und durchliefen anschließend auch den gesamten Prozess zur Herstellung der Datenbereitschaft.

Denn es ist schön und gut zu sagen: „Diese Anwendungsfälle werden etwas bewegen.“ Wenn es aber ewig dauert, die Daten für diese Anwendungsfälle vorzubereiten, ist das erneut einer dieser Entscheidungspunkte, an denen man sagt: „Vielleicht eignet sich das nicht besonders gut für die ersten Pilotprojekte.“

Das haben wir also auch intern getan. Wir priorisierten die Anwendungsfälle, die wir in die Produktion bringen wollten, stellten sicher, dass wir verstanden, welche Daten wir dafür vorbereiten mussten, und machten uns für die Produktionsbereitstellung bereit. Anschließend überwachten wir diese KPIs kontinuierlich weiter.

Corey:Das leuchtet ein. Ich bin froh, dass du die Daten erwähnt hast. Wir hören immer wieder, dass eine KI-Strategie letztlich eine Datenstrategie ist. Was bedeutet Datenbereitschaft in der Praxis, wenn ein Unternehmen KI in der Produktion ernsthaft einsetzen will?

Beth:Ja, darüber möchte eigentlich niemand sprechen, richtig? Denn es ist nicht der spannende Teil. Es heißt nicht: „Ich habe hier diesen riesigen Workload, ich mache dies und jenes, schaut euch das an, es ist fantastisch.“ Es macht nicht besonders viel Spaß, es sei denn, man arbeitet im Datenbereich.

Wir führen im Rahmen unserer eigenen Arbeit eine Bewertung der Datenbereitschaft durch und tun das auch für Kunden. Zunächst betrachten wir verschiedene Aspekte und sagen: Schaut euch nicht alle eure Daten an. Das ist einfach überwältigend.

Wenn wir über Datenbereitschaft sprechen, sollten wir von den priorisierten Anwendungsfällen ausgehen. Dann stellt man wahrscheinlich fest, dass man nur eine begrenzte Zahl von Datenquellen einbinden muss. Konzentriert euch also auf die Bereitschaft in diesem Bereich. Wo befinden sich diese Daten? Kann man sie finden? Sind sie auffindbar?

Zweitens – und das ist besonders wichtig, sobald man in den Bereich der agentischen KI vordringt – verfügen die Daten über die richtigen Berechtigungen? Denn man muss sehr vorsichtig sein, wenn autonome Agenten auf Daten zugreifen, auf die sie nicht zugreifen sollten.

Und können wir die Daten zurückverfolgen? Können wir feststellen, woher sie stammen? Ist die Herkunft der Daten eindeutig? Haben wir etwas wie ein Datenprodukt geschaffen? Wir sprechen viel darüber: über Datenprodukte und darüber, Daten wie Produkte zu behandeln.

Im Wesentlichen ist es das. Verfügen wir über die richtigen Berechtigungen? Können wir die Herkunft zurückverfolgen? Eignen sich die Daten für den richtigen Anwendungsfall? Gibt es eine klare Zuständigkeit? Unterliegen sie einer Governance? 

Ebenfalls sehr wichtig: Gibt es ein Lebenszyklusmanagement? Wenn man sich in eine Welt der Daten als Produkt begibt, überträgt man den Datenproduktmanagern tatsächlich die Verantwortung dafür, dass sie Daten nicht nur rechtzeitig bereitstellen, sondern auch sicherstellen, dass diese Daten richtig, korrekt, kontrolliert, mit den nötigen Berechtigungen versehen und richtlinienkonform sind. Solange man dieses Modell nicht eingeführt hat, ist eine Skalierung sehr schwierig, weil man wieder bei manuell kuratierten Datensätzen und Datenpipelines landet, die diese Arbeit nicht erledigen. Der Übergang zu einer solchen Welt der Datenprodukte ist daher ein echter Gamechanger. Wir haben das bei Dell relativ früh getan, um uns bei vielen Anwendungsfällen zu unterstützen, die wir jetzt ausrollen.

Corey:Das ist großartig. Ich sehe, dass viele Organisationen beginnen, mit KI zu experimentieren, indem sie einfach die Infrastruktur verwenden, auf die sie am leichtesten zugreifen können – im Grunde also das, was bereits vorhanden ist. Aber wie muss sich die Diskussion über die Infrastruktur verändern, wenn die Nutzung dauerhaft wird und im gesamten Unternehmen zu skalieren beginnt?

Beth:Ja, da hast du recht. Viele Pilotprojekte laufen auf dem, was gerade verfügbar ist. Es kann die eigene Infrastruktur sein – ich bin selbst schuldig, ich habe es auf meinem Laptop gemacht. Es kann alles Mögliche sein. Vielleicht ist es eine geliehene Ressource. Es kann alles sein. Das Ziel besteht zunächst darin, das System zum Laufen zu bringen.

Sobald man an den Punkt kommt, an dem man sagt: „Okay, jetzt muss ich das in die Produktion bringen“, ist die Infrastruktur, auf der das Pilotprojekt läuft, sehr wahrscheinlich nicht ausreichend. Sie lässt sich sehr wahrscheinlich nicht skalieren. Man muss also anfangen, darüber nachzudenken: „Wie stelle ich die Skalierbarkeit aus Sicht der Infrastruktur sicher?“ Dafür gibt es mehrere Möglichkeiten.

Anfangs sagten wir: „Okay, jeder muss eine große AI Factory kaufen.“ Das war für Kunden jedoch eine sehr, sehr große Investition, insbesondere wenn sie nur einen Anwendungsfall hatten. Bei mehreren Anwendungsfällen wird deutlich, dass diese Infrastrukturstrategie und das AI-Factory-Konzept in großem Maßstab absolut sinnvoll sind.

Was wir bei Dell getan haben, war, das Ganze etwas zu verkleinern und zu sagen: „Sehen wir uns doch die Erkenntnisse an, die wir inzwischen aus der Branche gewonnen haben: Die Menschen beginnen in der Regel klein.“

Möglicherweise muss man nur sicherstellen, dass man beispielsweise über einen guten GPU-KI-Server mit dem richtigen Software-Stack verfügt. Das kann für den Anfang ausreichend sein. Vielleicht führt man zunächst nur Inferenz in kleinem Maßstab durch und skaliert dann. Man kann modulare Infrastrukturkomponenten hinzufügen und so zunächst zur Inferenz auf Unternehmensebene und anschließend sogar zur verteilten Inferenz übergehen, indem man immer weitere Ebenen beziehungsweise Module hinzufügt.

Klein anzufangen, bleibt also sehr wichtig. Die Lücke zwischen der Infrastruktur eines Pilotprojekts und einer großen, verteilten AI Factory ist groß. Eine Strategie mit Zwischenschritten für die jeweiligen Anwendungsfälle ist daher besonders wichtig.

Ein weiterer Punkt ist, dass nicht zwangsläufig alles On-Premises betrieben wird. Man wird eine Art hybriden Ansatz verfolgen. Das tun die meisten Kunden. Betrachtet man das aus Sicht eines KI-Workloads und insbesondere im Zusammenhang mit Agenten, werden bestimmte Teile dieser Workflows möglicherweise nicht On-Premises betrieben werden müssen. Sie könnten sich in der Cloud befinden. Vielleicht benötigen sie eine andere Art von Skalierbarkeit. Bestimmte Dinge möchte man jedoch möglicherweise aufgrund der Daten und der Sicherheit On-Premises behalten.

Wir entwickeln daher eine sogenannte Strategie zur Platzierung von Workloads, die auf den Anwendungsfällen basiert, die wir bei Kunden implementieren. Anschließend entscheiden wir anhand dieser Platzierung, welche Plattformen wir benötigen. 

„Dieser konkrete Anwendungsfall muss On-Premises bleiben. Okay, dann nehmen wir eine AI Factory.“ 

„Dieser konkrete Teil des Anwendungsfalls könnte möglicherweise auf einem Public-Cloud-Modell laufen. Das ist in Ordnung.“

Es geht also um eine solche Strategie. Wir sprechen zwar über hybride Modelle, letztlich handelt es sich aber um einen Entscheidungsprozess für KI-Workloads: Wie muss die Infrastruktur aussehen, was kann man in der Public Cloud nutzen, was muss On-Premises bleiben und womit erreicht man am schnellsten ein Ergebnis?

Corey: Das leuchtet ein. Und das führt uns sehr gut zu dem Elefanten im Raum, nämlich den Kosten. KI kann sehr günstig wirken, wenn man einen kleinen Proof of Concept durchführt. Aber im großen Maßstab summiert sich das schnell, wenn es um Rechenleistung, Speicher, Inferenz, Netzwerke und Datenbewegungen geht, und daraus werden schnell große Beträge.

Wie sollten Unternehmen die Wirtschaftlichkeit von KI anders betrachten, sobald sie zu einer operativen Workload wird?

Beth: Ja, ich glaube, wir haben alle schon den Begriff „Tokenomics“ gehört. Das ist wahrscheinlich derzeit einer der überstrapaziertesten Begriffe. Und wenn Menschen an Tokenomics denken, denken sie: „Okay, es geht um Tokenverbrauch oder Tokenkosten“ – also, wenn man so will, lediglich um die Modellkosten. Und das ist nur ein Teil der Gleichung.

Du hast es erwähnt. Das ist nur ein Teil der Gleichung rund um die Kosten, die entstehen, wenn man das Ganze in der Produktion betreibt. Wenn du ein tokenbasiertes Modell verwendest, ist die Frage, wie das konkret aussieht, ein Bestandteil – aber eben nur ein Teil davon.

Man muss eine Art Gesamtbetriebskostenrechnung durchführen, die diesen hybriden Ansatz einschließt. Vielleicht gibt es hier Tokenverbrauchskosten für eine bestimmte Workload, die in der Cloud läuft. Aber wir sollten auch betrachten, was der Betrieb von Dingen On-Premises kostet. Das muss Teil der Gleichung sein.

Wir betrachten also Dinge wie Rechenleistung, Speicher und Netzwerke. Wir schauen uns Datenbewegungen an. Wir berücksichtigen die Kosten für eingehenden und ausgehenden Datenverkehr. Aber wir betrachten auch Softwarekosten, Strom und Kühlung. Jedes Mal, wenn du eine Abfrage auf einem On-Premises-Modell ausführst, wird weiterhin Strom verbraucht. Auch das ist Teil der Gleichung.

Wir müssen also in Form von Stückkosten für die durchgängige Erledigung einer Aufgabe denken – einer wertschöpfenden Aufgabe. Wie sieht das tatsächlich aus, je nachdem, wo sie ausgeführt wird?

Das ist wirklich eine komplizierte Berechnung, und außerdem eine fortlaufende, weil sich diese Dinge tendenziell verändern. Nicht jedes Modell wird künftig dieselben Tokenkosten haben. Deshalb braucht man eine fortlaufende – ich würde sagen umfassendere – Diskussion über Tokenomics, nicht nur über den Tokenverbrauch, sondern über alles, was damit zusammenhängt.

Man muss das auch künftig überwachen, damit man sich anpassen, Veränderungen vornehmen und Dinge an den optimalen Ort verschieben kann – je nachdem, ob eine hohe Frequenz oder eine geringe Latenz erforderlich ist und wofür man den jeweiligen Anwendungsfall einsetzen möchte. Dazu gehört auch eine automatisierte Platzierung von Workloads auf Grundlage solcher Kostenindikatoren.

Corey: Ja. Das ist wirklich sinnvoll. Und ich glaube, was die Menschen manchmal vergessen: Die alten Kosten gibt es weiterhin. Es geht nicht nur um Token.

Beth: Genau. Private Cloud, Public Cloud – darüber sprechen wir schon seit vielen Jahren. Im Grunde ist es also eine KI-Cloud, richtig? Sehr ähnlich.

Die TCO-Berechnungen sind bis zu einem gewissen Punkt sehr ähnlich, und dann kommt noch die zusätzliche Nuance hinzu: „Okay, jetzt setze ich KI ein. Welche weiteren Kosten entstehen also? Was muss ich noch berücksichtigen, wenn ich die Frage nach meiner besten wirtschaftlichen Strategie für den Betrieb dieser KI-Workloads betrachte?“

Aber du hast recht. Zwischen dem, worüber wir früher bei Vergleichen zwischen Public und Private Cloud gesprochen haben, und KI gibt es keinen großen Unterschied. Es gibt lediglich einige feine Nuancen.

Corey: Genau. Sobald KI in der Produktion läuft, ist selbst das Modell nur ein Teil eines viel größeren Systems. Was muss über diesen gesamten Lebenszyklus hinweg überwacht und verwaltet werden, damit die Anwendung weiterhin so funktioniert, wie es das Unternehmen erwartet?

Beth: Ja. Wie gerade erwähnt, gibt es Teile dieser Lösung, einschließlich der Plattform, für die wir beim Monitoring bereits ziemlich gute Lösungen haben. Kunden im Unternehmensmaßstab verfügen schon über eine Ebene für Protokollierung und Monitoring.

Stellt also zunächst sicher, dass diese Dinge vorhanden sind. Das sind die Grundregeln, wenn man so will. Danach muss man sich fragen: Was sind die neuen Dinge, über die wir nachdenken müssen, sobald wir über KI sprechen – insbesondere über agentische KI?

Dann müssen wir anfangen, das Modell selbst zu betrachten. Vielleicht gibt es Drift beim Modell. Das müssen wir untersuchen und eine Möglichkeit finden, sie zu überwachen. Wir müssen uns auch die Daten ansehen. Das wird oft vergessen, aber Data Drift ist wirklich wichtig. Und wir sollten auch die Nutzung der bereitgestellten Lösung für den Anwendungsfall betrachten. So viele Menschen wollen Dinge schnell in die Produktion bringen, prüfen aber nicht wirklich, ob sie genutzt werden und ob dadurch tatsächlich die im Pilotprojekt erwarteten Kosteneinsparungen, Umsätze oder sonstigen KPIs erzielt werden.

Ich habe bereits erwähnt, dass man das auch künftig kontinuierlich überwachen muss. Es geht beim technischen Monitoring nicht nur um Fragen wie: „Verhält sich mein Stack korrekt? Funktioniert meine KI ordnungsgemäß? Arbeitet mein Agent wie vorgesehen? Stelle ich sicher, dass es keine Angriffsvektoren auf mein Modell gibt?“

Es geht auch um die Frage: „Erreiche ich tatsächlich die Ziele, die ich mir in Bezug auf KPIs gesetzt habe?“ Das ist ebenfalls ein sehr großer Teil der Monitoring-Gleichung, der oft übersehen wird. Man lässt die Dinge in der Produktion weiterlaufen, aber vielleicht schaffen sie in Wirklichkeit nicht den benötigten Mehrwert. Vielleicht entspricht der ROI nicht unseren Anforderungen.

Man muss also erneut die laufenden Kosten und den laufenden ROI ebenso im Blick behalten wie das technische Monitoring.

Corey: KI in der Produktion verändert meiner Meinung nach auch die Anforderungen an die Governance. Wenn diese Systeme beginnen, Entscheidungen zu beeinflussen, mit Unternehmensdaten zu interagieren oder über andere Agenten Aktionen auszuführen – wo liegt letztlich die Verantwortung?

Beth: Ja. Man kann nicht sagen: „Das Modell hat mir gesagt, ich soll es tun“, richtig?

Corey: Nein, das funktioniert nicht.

Beth: Nun, manche versuchen es. Aber das wird einfach nicht funktionieren.

Die Verantwortung liegt an mehreren unterschiedlichen Stellen. Wenn du KI nutzt, um bei der Arbeit eine Aktion auszuführen, und du der letzte Mensch in dieser Schleife bist, der diese Aktion in der Realität umsetzt, dann liegt die Verantwortung bei dir. Das schärfen wir uns ständig ein.

Wir haben intern viele großartige KI-Tools und sagen immer wieder: „Hört zu: Wenn ihr dieses Tool verwendet und damit etwas tut, seid ihr für diese letzte Aktion verantwortlich.“

Alles, was bis dahin passiert, liegt in deiner Entscheidung. Eine Person in dieser Schleife ist also der Nutzer. Die andere Person in dieser Schleife ist – insbesondere wenn es mit Agenten autonomer zugeht – meiner Meinung nach der Eigentümer des Geschäftsprozesses. Für den Geschäftsprozess, der automatisiert und mithilfe von KI und agentischer KI verbessert wird, sind diese Personen verantwortlich – einschließlich der gesamten KI, die dabei zum Einsatz kommt.

Unterhalb dieses Eigentümers des Geschäftsprozesses gibt es wiederum mehrere andere Verantwortliche. Wir haben über Datenprodukte gesprochen. Wenn du im Bereich der Datenprodukte tätig bist, ist der Eigentümer des Datenprodukts für die Daten verantwortlich, die einen Teil dieser Lösung bilden.

Es kann einen Plattformverantwortlichen geben, etwa einen Verantwortlichen für die AI Factory with NVIDIA. Diese Person ist dafür verantwortlich, dass sich die Plattform ordnungsgemäß verhält. Wenn du dein eigenes Modell trainierst, gibt es möglicherweise auch einen Modellverantwortlichen.

Unterhalb dieses übergeordneten Verantwortlichen für den Prozess stehen also all diese wichtigen Beteiligten, die sicherstellen müssen, dass ihre jeweiligen Komponenten die festgelegten Regeln einhalten und die SLAs erfüllen, die wir von ihnen benötigen.

Es gibt also viele verschiedene Beteiligte. Letztlich muss aber der Nutzer – wenn er die letzte Person in diesem Workflow ist – sicherstellen, dass alles korrekt ist, bevor er den Vorgang startet.

Und dann gibt es den Eigentümer des Geschäftsprozesses, dessen Geschäftsprozess tatsächlich mit KI automatisiert wird. Das sind meiner Meinung nach die beiden wichtigsten Verantwortungsebenen.

Corey: Das ist ein wirklich guter Ansatz. Man muss verstehen, dass es diese Menschen und zentralen Elemente gibt, die sagen: „Dieser Teil liegt bei dir. Dieser Teil liegt bei dir. Sorge einfach dafür, dass es funktioniert. Stelle sicher, dass es die vorgesehene Aufgabe erledigt. Achte darauf, dass es nicht durchdreht und anfängt, Websites anzugreifen oder Ähnliches.“ Genau diese Art von Fokus ist wichtig.

Wie viel davon, KI erfolgreich in die Produktion zu bringen, ist letztlich ein Technologieproblem, und wie viel davon ist deiner Meinung nach ein organisatorisches Problem? Und wer übernimmt die Verantwortung, sobald man über das isolierte Innovationsteam hinausgeht?

Beth: Ja, ich würde sagen: Die Technologie ist der einfache Teil. Das ist lustig, weil wir uns ständig auf diesen Teil konzentrieren. Wir sprechen die ganze Zeit darüber. Wir sprechen darüber, ob unsere Pilotprojekte technisch leistungsfähig sind und so weiter.

Ehrlich gesagt ist die organisatorische Veränderung wirklich der schwierigste Teil. Das war bei jeder Art von Transformationsprojekt schon immer so. Es geht nicht um die technologische Transformation, sondern um die Transformation der Menschen. Es geht um den organisatorischen Wandel, der stattfinden muss. Das ist die größte Hürde, die man bei diesen Anwendungsfällen überwinden muss.

Das haben wir schon immer gesehen, aber durch die Autonomie der KI wird es jetzt noch etwas verstärkt, weil sich die Dinge in diesem Bereich ziemlich dramatisch verändern. Organisationen verändern sich viel schneller als früher.

Was wir ansprechen – und worüber ich schon zuvor gesprochen habe – ist: Man braucht einen Verantwortlichen. Das ist das Erste. Wenn man Dinge in die Produktion überführen möchte, muss die organisatorische Bereitschaft Fragen berücksichtigen wie: Wer übernimmt die Verantwortung? Wer finanziert das, wenn es in der Produktion läuft? Woher kommt das Geld? Wer genehmigt Änderungen? Wenn ich etwas ändern muss, an wen wende ich mich? Wer genehmigt das? Wer misst fortlaufend den Wert, und wer entscheidet, ob etwas wertvoll ist oder nicht?

Im Grunde: Wer ist verantwortlich, wenn die Dinge aus dem Ruder laufen?

Alles, was wir über Software mit Sicherheit wissen, ist bei KI-Software jetzt noch wichtiger. Betriebsmodell, Business Sponsor, Product Owner sowie Verantwortung für Daten und Plattform – darüber haben wir bereits gesprochen.

Sicherheit und Risiko müssen dabei eine zentrale Rolle spielen. Man braucht eine angemessene Governance.

Man braucht einen Einführungsplan und muss beobachten, was bei der Nutzung tatsächlich passiert. Organisatorischer Wandel bedeutet nicht nur, festzulegen, wer die Lösung am Laufen hält. Es geht auch um die Frage: Wie bringe ich die Menschen dazu, diese Lösung zu nutzen? Das ist ein wichtiger Punkt.

Wenn man über KI und einige der damit verbundenen Ängste nachdenkt, sind die Menschen manchmal etwas vorsichtig: „Ich werde das für meine Arbeit einsetzen, und vielleicht erledigt es dann meine Arbeit für mich.“ Ein Teil des organisatorischen Wandels besteht also darin, den Menschen zu vermitteln, dass KI ihnen helfen soll, schneller, besser und effizienter zu arbeiten und all die langweiligen Aufgaben zu übernehmen.

Das mussten wir auch intern tun. Wir haben mehrere verschiedene Programme durchlaufen, um uns bei der internen Einführung von KI zu unterstützen. Es gibt also nicht nur Teams, die sicherstellen, dass die Lösung selbst ordnungsgemäß läuft und gute Leistung bringt. Es gibt auch ein ganzes Team, das dafür sorgt, dass die Menschen sie richtig einsetzen und tatsächlich nutzen, um ihre Arbeit zu erledigen. Es gibt also viele verschiedene Bereiche. Das ist der üblichen Transformation sehr ähnlich, aber bei KI gibt es erneut einige Besonderheiten, insbesondere bei der Einführung und Nutzung.

Corey: Ja. Wenn wir einige Jahre vorausblicken: Was wird deiner Meinung nach Unternehmen unterscheiden, die KI wirklich operationalisiert haben, von Unternehmen, die noch eine Sammlung voneinander getrennter Experimente betreiben?

Beth:Wie wird das aussehen? Wie kann ich erkennen, ob diese Unternehmen wirklich so weit sind oder nicht?

Wenn wir uns selbst betrachten, sind wir meiner Meinung nach ziemlich weit. Wir haben einige gute produktionsreife Anwendungsfälle und verfügen über einen guten Governance-Prozess dafür.

Eines der Dinge, die wir früh getan haben, war beispielsweise sicherzustellen, dass wir nicht nur eine Reihe von KI-Pilotprojekten, sondern ein KI-Portfolio hatten. Betrachten wir das Ganze also als eine Reihe von Services, die wir entweder intern anbieten können, um effizienter und produktiver zu sein, oder unseren Kunden anbieten können. Das sind alles Services. Das sind jetzt alles Produkte. Behandelt sie auch so: als Services und Produkte.

Ein weiteres Zeichen für Reife – neben der Tatsache, dass es sich um ein Portfolio und nicht um eine Vielzahl irgendwo laufender Pilotprojekte handelt – ist die Wiederverwendbarkeit. Man erkennt, dass jemand KI operationalisiert, wenn er ein Pilotprojekt, das alle seine KPIs nachgewiesen hat, nehmen und sagen kann: „Boop, jetzt ist es in der Produktion“, weil darunter all diese wiederverwendbaren Dinge vorhanden sind. Ich habe wiederverwendbare Datenprodukte. Vielleicht habe ich zuvor ein Datenprodukt erstellt, das von einem anderen Anwendungsfall genutzt wurde. Jetzt kann ich dieses Datenprodukt für diesen speziellen Anwendungsfall wiederverwenden.

Die zugrunde liegende Factory selbst – wir nennen sie AI Factory with NVIDIA, weil sie eine Factory ist. Sie soll nach dem Prinzip funktionieren: „Einfach einschalten, und das Ergebnis kommt heraus.“ Deshalb lässt sie sich sehr einfach auf einer bestehenden, bereits abgesicherten und gesteuerten Plattform bereitstellen.

Das ist ein weiterer wichtiger Bestandteil: die Wiederholbarkeit.

Und erneut geht es um die Idee, dass man nicht nur die Klicks bei der Bereitstellung misst. Man misst, ob diese Lösung künftig den erforderlichen ROI liefert. Die kontinuierliche Messung von KPIs, Leistungsmerkmalen und all diesen Dingen – das ist eine hochfunktionale, operationalisierte KI-Umgebung.

Corey: Das stimmt. Beth, vielen Dank, dass du heute bei uns warst.

Bevor wir dich verabschieden: Wo können sich Menschen über die Aktivitäten von Dell Technologies im Bereich Enterprise-KI informieren?

Beth:Auf Dell.com gibt es eine enorme Menge an Informationen. Ich kann nur dringend empfehlen, dort einmal nachzusehen. Von dort aus kann man zu vielen verschiedenen Bereichen weitergehen.

Man kann zu meinem Bereich weitergehen, also zum Services-Bereich. Dort findet man all die großartigen Services, die wir anbieten – etwa Governance-Services, AI-Factory-Services und Datenservices.

Beginnt also mit Dell.com. Dort gibt es eine fantastische Menge an Informationen über unsere Produkte, unsere Services, unseren Ansatz und unsere Vorgehensweise. Das führt euch zu allem, was euch interessiert.

Corey: Ausgezeichnet. Beth, vielen Dank, dass du dir heute die Zeit für dieses Gespräch mit uns genommen hast.

Beth: Vielen Dank.

Corey: Und für weitere Gespräche dieser Art besucht eWeek.com. Ihr könnt uns außerdem überall dort, wo ihr zuschaut, mit „Gefällt mir“ markieren und abonnieren sowie eWeek auf LinkedIn, Facebook und X folgen.

Ich bin Corey Noles. Danke fürs Zuschauen. Wir sehen uns beim nächsten Mal bei eSpeaks.