EAM#31: AI Memory - Was passiert, wenn AI mehr weiß als das Unternehmen?

Shownotes

AI wird zunehmend Teil von Geschäftsprozessen, Entscheidungen und Wissensarbeit. Dabei entsteht nicht nur Output, sondern auch Kontext, Historie und neues Wissen.

In dieser Folge geht es um die Frage, was passiert, wenn dieses Wissen langfristig stärker an AI-Systeme, Agents oder Plattformen gebunden ist als an das Unternehmen selbst.

Themen der Folge:

  • AI Memory und Unternehmenskontext
  • Model Lock-in vs. Context Lock-in
  • Decision Lock-in
  • Knowledge Debt
  • AI Output vs. Enterprise Record
  • Warum AI Memory kein System of Record sein sollte
  • Persistence Gate als technischer und prozessualer Kontrollpunkt
  • Provenance, Ownership und Lifecycle von AI-generiertem Wissen
  • Rückgriff auf AI Demand und Decision Rights
  • Automation Bias und die Grenzen von Human-in-the-Loop

Passend dazu auch die vorherigen Folgen:

  • EAM#26: AI Demand – wie AI Use Cases strukturiert ins Unternehmen kommen
  • EAM#27 & #28: AI Architecture – wie AI von der Enterprise Architecture bis zur Solution Architecture - eingeordnet wird
  • EAM#29: AI Governance – wer über AI entscheidet
  • EAM#30: AI Decision Rights – wie viel AI tatsächlich entscheiden darf

Die zentrale Frage: Wie stellen Unternehmen sicher, dass Modelle austauschbar bleiben, ohne dabei Wissen, Kontext und Entscheidungsfähigkeit zu verlieren?

Denn am Ende gilt: Das Modell darf austauschbar sein. Das Wissen des Unternehmens nicht.

Der deutschsprachige EAM Podcast, überall wo es Podcast gibt. Freue mich auf Dein Feedback, gerne jederzeit direkt auf https://eam.podigee.io/ oder direkt www.linkedin.com/in/david-hohl

David Hohl

Möge die Enterprise Architecture mit dir sein.

Transkript anzeigen

00:00:04: Architektur entscheidet über Komplexität, über Kosten und Übersteuerbarkeit.

00:00:09: Ich bin David Hohl und heiße Dich herzlich willkommen.

00:00:12: bei Enterprise-Architektura wirkt der Podcast zu ERM.

00:00:20: Servus grüßt Dich und herzlich Willkommen zur neuen Folge.

00:00:24: Wir haben uns die letzte Zeit sehr stark um EI beschäftigt.

00:00:32: Wenn wir zurückdenken, wir haben über EITCO gesprochen.

00:00:37: Ich habe euch ein bisschen erzählt wie ich EITEM End-Management vollziehe, wie gewisse Architekturen Richtung EI aufgebaut werden können und sollten Und vor allem auch über Governance Regelwerke Letzten sind der Folge dreißig, haben wir über Entscheidungsrechte gesprochen also was EI eigentlich entscheidend davon ist es nicht ein Scheidenzahl Darf.

00:01:03: Ich habe mir mal ein bisschen überlegt, wie ich diese Folge diesmal schneide und ich denke mal, ich habe einen guten Mix gefunden denn heute wollen wir ja über etwas weiteres sprechen.

00:01:17: was mir tagtäglich auch immer wieder unter die Füße fällt ist einfach das Thema dass ihr Sachen weiß und ich auf die Kontrolle dann über die Zeit verliere weil halt immer mehr Informationen gefüttert werden.

00:01:33: Und das bringt uns natürlich in eine Situation, die nicht ganz angenehme ist für ein Unternehmen Denn EI wird halt irgendwann nicht nur antworten liefern sie sammelt halt einfach Kontext aus verschiedenen Daten und Interaktionen.

00:01:49: Du korrigierst das weiterhin, du triffst Entscheidungen.

00:01:52: Das Verhalten von dir aber vor allem halt eigentlich vom gesamten Unternehmen wird einfach festgehalten und irgendwann weiß vielleicht ein Agent wie man als Grunde behandelt wird oder welche Ausnahme normalerweise akzeptiert wird, welche Argumente funktionieren und vor allem auch welchen in den Entscheidungen früher getroffen wurden.

00:02:12: Das ist auf deiner Seite nicht ganz so schlimm wenn Jetzt der Newskills-Basis denkt, aber das Problem einfach aus der Architektur.

00:02:22: Dieses Wissen ist wohl möglich nirgends sauber dokumentiert.

00:02:26: und was passiert halt wenn die EI mehr über einen Teil unseres Unternehmens weiß als dass Unternehmen selbst sauber festgehalten wird oder halt was im Unternehmen selbst selber fest gehalten wird?

00:02:39: Also bevor wir Übergaben entsprechen sollten wir uns erst einmal anschauen was ein Gedächtnis für die EIs bedeutet Kapitel eins, das Gedächtnis rund um die EI.

00:02:54: Wenn wir uns mal ein Beispiel hernehmen von einem CM Umfeld Sales Agent, man kennt jeder und Das funktioniert ja in der Regel so, es wird halt CM Daten ausgelesen, welche Produktdaten Opportunities und für mehr Orders sein.

00:03:19: Die Tickets rumaromen, früher Kommunikation oder History, allgemein History Management im Form von Mit dem Kunden und nach kurzer Zeit schon wird einfach dieses Sales Agents zu einer operativen Unterstützung.

00:03:32: das heißt ich kann in die ganze Zeit Fragen triggern oder auch Aktionen setzen.

00:03:37: der soll aktiv werden bei verschiedenen Elementen.

00:03:42: Wenn man das über eine gewisse Zeit jetzt noch mal weiterzieht, also wenn wieder diesen Agent weiter diesen Freilauf geben dann nach ein zwei Jahren, dann weiß es im Endeffekt alle grundlegenden typischen Kundenprobleme und weiß allmöglichen Argumente wie sie funktionieren.

00:03:58: Wie wir agieren für den Kunden oder vielleicht auch gegen den Kunden versteht auch diese Sonderfälle und wendet sich vielleicht auch noch schlimmsterweise direkt für andere Kunden halt ran.

00:04:11: Natürlich kennt es auch verschiedene Abweichungen, die halt vom Standardprozess ablegen.

00:04:17: Und das beschreibt natürlich nicht nur das Verhalten.

00:04:22: aber wenn wir darüber nachdenken wo liegen diese Informationen?

00:04:26: Also ich habe alles aufgelöst und egal jetzt... Ich bewerte jetzt nicht was ob das jetzt ein Standard gutes Feature oder Feature Set ist.

00:04:33: soweit bin ich ja auch im CM-Umfeld gerade nicht aktiv.

00:04:38: Wo liegt das?

00:04:39: In der Regel natürlich in den Customer Relations Management oder NCM.

00:04:43: Ich habe gegebenenfalls auch eine Knowledge Base, wo alles zentralisiert liegt.

00:04:48: Das ist ideal Fall natürlich.

00:04:50: Ich hab ein Vector Store, da wo die Eier halt darauf zugreifen, wo der Moos halt.

00:04:55: ich habe den klassischen Agent Memory, ich habe gewisse Providerplattformen, die noch weitere Informationen zu verfügen stellen und vielleicht noch einen Data Lake, wo noch mehr steht.

00:05:08: Aber die wichtigste Botschaft für diese langen Liste von verschiedenen Deutschmöglichkeiten ist eigentlich, das ist halt verteilt über mehrere Stellen also dezentral.

00:05:19: Der Punkt was mir jetzt ankommt ist einfach diese Governets-Regel die ich halt prinzipiell immer aufstelle.

00:05:25: dass Modell soll eigentlich schnell verändert werden oder ersetzt werden.

00:05:28: Das kann ich auch noch mit dieser Datenarchitektur.

00:05:31: klar der Kontext vielleicht aber nicht weil im Endeffekt diese Informationen zu D-Zentral laufen.

00:05:37: Wirklich weiß es nicht das Modell, was eigentlich esse sondern eigentlich die Unternehmensdaten und Erfahrungen dahinter, die sich daraus ergeben.

00:05:45: Die Korrekturen, die damit einfließen und vor allem die eigenen Entscheidungen, die das Model für einem schließt.

00:05:51: also der Kontext.

00:05:53: Und genau deshalb sollten wir beim Thema Lock in vielleicht nicht nur auf das Modelle schauen so wie ich das letztens mal erzählt habe.

00:06:08: In ist vielleicht das kleinste Problem, was wir haben.

00:06:13: Wie komme ich da rauf?

00:06:16: Also meine Theorie oder nicht nur meine Theorie sondern einfach meine Sichtweise eigentlich ist darauf... Ich habe den Monoten davor halt letztes Monat speziell über diese Model-Login gesprochen und hab im Infekt auch diese Gawandernsregel bei mir selbst so etabliert wenn du ein Ususges implementierst oder ein wenn irgendwas implementiert mit die EI dann musst du einfach als Architekt gewährleisten, dass Du das Modell austauschen kannst.

00:06:43: Das ist aber alleine leider nicht das Problem weil einfach wir über verschiedene Lockins hier sehen oder reden und der bekannteste ist natürlich der Wendler.

00:06:55: Der zweite ist vor allem aber Cloud und Platform.

00:06:59: Und jetzt halt der Model-Lockin von dem wir jetzt sprechen.

00:07:03: Die üblichen Architektur-Fragen sind natürlich gar nicht, ob mir Eier oder Austausch und das mit Gemini ersetzen oder einsetzen.

00:07:13: Nutze ich vielleicht ein Multimodell?

00:07:14: Oder habe ich einen anderen Fallback?

00:07:16: Das ist alles berechtig!

00:07:17: Aber die zweite Ebene auf der ich eigentlich hinspielen möchte, ist viel wichtiger.

00:07:22: Was passiert eigentlich mit diesem aufgebauten Kontext, den ich mir erarbeitet habe durch das erste Modell?

00:07:29: Ich habe aber mal probiert es für mich im Kopf in drei Ebenen zu unterteilen Einmal dieser Model-Login, für den ich gesprochen habe.

00:07:35: Technisch ist es vielleicht schwer austauschbar, ist aber möglich.

00:07:43: und dann hab' ich die zweite Ebene dieser Context-Lokinen.

00:07:50: Also nehmen wir mal an das ist der Modell wird halt ausgetauscht und das Unternehmenscontext bleibt aber blöderweise in dem Provider also im Produkt hängen und damit verliere ich halt etwas ganz Wichtiges, und zwar die Historia.

00:08:02: Ich verliehe die ganzen Korrekturen, die ich dir mitgeben habe und warum wir sowieso die States, die Präferenzen je nach jeder Entscheidung und die abgeleitenden Informationen.

00:08:11: Aber jetzt zeige ich noch etwas obendrauf und zwar dieser Decision-Lock in der mitgeht.

00:08:17: Also vergangen Entscheidungen sind einfach nicht mehr nachvollziehbar Und das ist für mich gerade in der Enterprise Architektur ein No Go Denn es wird auf einmal unklar, welche Daten nicht genutzt wurden sind.

00:08:27: Auf welche Regeln angewandt worden sind und wie ist das Verhalten dann gewesen zwischen Mensch und oder EI?

00:08:38: Wenn wir das Ganze in unserem CM-Kontext nochmal im Sales Agent Beispiel laufen lassen – die ist ein Gedanke!

00:08:44: Wir haben den Sales Agent, der läuft jetzt drei Jahre.

00:08:46: Okay.

00:08:47: Auf einmal machen wir genau das.

00:08:48: Wir wechseln das Modell und bitte lasst uns jetzt nichts salesforce.net tief nutzen weil davon halt ich am wenigsten dass die vendor im Endeffekt die volle hoheit hat.

00:08:58: an allen informationen gehen wir davon aus wie haben trotzdem die hoheit?

00:09:01: das heißt wir setzen die information außerhalb so wie ich es angeteasert habe.

00:09:05: wie auch immer wir wechseln das trotzdem.

00:09:07: wenn du ein wechsel mag check.

00:09:09: aber jetzt gehen halt diese sachen verloren die historischen zusammenfassungen, die gesamten entscheidungen.

00:09:14: Das feedback der agent state und dieser für mich den entscheidendstift Faktor.

00:09:19: Das ist der Kontext, also in unserem Fall jetzt sehr kundenspezifische Kontext.

00:09:23: Somit sind wir eigentlich technisch flexibel.

00:09:26: Ja super!

00:09:27: Was?

00:09:27: strategisch haben wir einfach eine extreme Abhängigkeit die halt verloren geht und das führt zu einem Problem dass wir aus an den anderen Bereichen schon lange kennen und zwar diese Schulden.

00:09:38: nur diesmal reden wir nicht unbedingt über technische Schulden Denn wir reden heute im Kapitel drei über Nulled-Schulden Also Wissensschulden.

00:09:55: Nur jetzt Schulden entstehen, wenn Wissen genutzt wird aber die Herkunft Qualität und vor allem die Verantwortung zunehmend verloren geht.

00:10:02: Das kennst du eigentlich in ganz einem einfachen Fall mit Beitrag von Lesters Unternehmen.

00:10:07: Ist genau das gleiche!

00:10:09: Vielleicht wenn Du hier frisch eingestiegen bist bei Enterprise-Architektur wirkt?

00:10:14: Wir haben über Schulden schon in der Vergangenheit gesprochen.

00:10:19: Liste mal schauen, wir haben über technische Schulden gesprochen.

00:10:22: Wir haben über Data-Schulden, Integrationsschulden und auch über Entscheidungsschuld gesprochen.

00:10:27: Heute reißen wir einmal das Thema Nullutschulden oder Nullutstöpter ein bisschen an.

00:10:33: Menschen lagern ja kognitiv arbeitsständig aus.

00:10:36: also wir du und ich haben mir den Telefonnummer bekommen von jemandem, dann speichern wir das im Smartphone ab oder in der Handyhalt.

00:10:46: Wenn wir Termine haben, kommt ein Kalender im Einsatz.

00:10:48: jetzt wollen wir von A nach B kommen und dann haben wir Google Maps an oder irgendein andere Map Stool deiner Wahl.

00:10:53: Und wenn wir Fakten recherchieren wollen, dann werfen wir eine Suche an.

00:10:57: Das war früher.

00:10:59: es wird auch weiterhin so in diese Richtung bleiben.

00:11:01: da wird sich nichts viel ändern.

00:11:02: aber die EI wird halt das ganze bisschen erweitern und Interpretationen mit einfließen lassen und gibt uns einfach Bewertungen und Empfehlungen, was wir machen sollen.

00:11:12: Ich habe zum Beispiel heute meiner Frau meinen nächsten Urlaub geplant.

00:11:17: Soll nach Sri Lanka gehen?

00:11:18: Mal schauen!

00:11:19: Und was machen wir?

00:11:20: Wir haben nur EI-Lauf nicht viel uns das und jenes, jetzt haben uns ein Lone plennet nochmal gekauft als Buch und finden einfach raus dass der nicht aktuell ist und wie eigentlich aktuelle Informationen brauchen.

00:11:31: Das macht natürlich wieder der Punkt, dass diese Interpretationen ... wir uns schon so dran gewöhnt haben, dass die aktuell sein müssen.

00:11:41: Und dann sage ich natürlich schon einfach... ... frage einfach Chatty oder so was du schon wissen wirst geht!

00:11:46: Oder wo wir hinmüssen.

00:11:48: So und jetzt haben wir genau diese Herausforderungen.

00:11:51: Und da bin ich zu meinem Urlaubsthema.

00:11:53: Das Problem hat ist natürlich,... ...dass das EI hat oder mein EI Agent hat zwar das Wissen aber ich weiß halt.... oft gar nicht.

00:12:02: woher kommt das Wissen, wer verantwortet es?

00:12:05: wie ist es geprüft?

00:12:06: Ist es überhaupt geprüfed und wann wurde erzeugt.

00:12:09: Und ist es überhaupt noch valide?

00:12:12: Diese möglichen Herkunftsinformationen sind natürlich immer so ein System.

00:12:16: Das können natürlich Original-Daten sein, das könnte eine menschliche Eingabe sein.

00:12:20: Es könnten aber auch EI Zusammenfassungen sein aus anderen Informationen die jemand reingespielt hat oder auch in Furie Empfehlungen.

00:12:27: Das gleiche habe ich in einer Organisation Und das ist eine sehr gefährliche Kette.

00:12:31: Wenn ich einfach mir jetzt den EI Output anschaue, dann wird einfach durch meine ganzen Informationen die ich denn anreiche wieder neuer in... also mit meinen neuen Informationen kommt halt ein Input rein und daraus entsteht wie der neue Output wird wieder gespeichert, die herkommt verschwimmt.

00:12:49: Also ich hoffe es kommt ein bisschen rüber um was eigentlich danach der Kicker da hinter ist.

00:12:59: Ich überlege gerade, ob ich noch ein Beispiel dazu nennen soll oder ob das eigentlich klar ist.

00:13:04: Vielleicht nochmal ganz kurz zurück zu einem Wissenschulden.

00:13:07: also Wissen existiert natürlich in Unternehmen aber seine Herkunft und Qualität oder Verantwortung ist nicht immer ausreichend nachvollziehbar Und das bringt mich einfach in eine sehr unangenehmen Situation wenn ich so eine Technologie im Einsatz habe.

00:13:24: Genau an dieser Stelle kommen wir zu einem ziemlichen Halt die End-Thema wieder rum.

00:13:29: Und zwar geht es halt darum System of Record, Data Ownership und folgen auch Partner-Hoid.

00:13:35: Genau!

00:13:40: Kapitel vier AI.

00:13:42: Memory ist halt kein System of record.

00:13:46: Nur weil ein AI etwas erzeugt wird das daraus nicht automatisch unternehmen zu wissen.

00:13:51: Richtig?

00:13:55: Du gehst wahrscheinlich dieses klassische Modell nach Kundendaten.

00:13:59: Die speichern wir natürlich in einem ZM ab Produkte, die in einem PIM Bestellungen oder Orders halt in ein OMS oder einen ERP.

00:14:07: Das sind klare Führendesysteme und wir haben damit auch eine klare Ownership aus Daten eingeht.

00:14:11: Jetzt haben wir das Thema um EI Outputs das Ganze noch ein bisschen ergänzt.

00:14:17: Wenn man mal als Beispiel unsere EIs sagt auf einmal die Kunden haben eine hohe Abwandungsverschwendigkeit.

00:14:24: Das heißt, diese Information ist gespeichert in ein Jet, in eine Agent-Memory.

00:14:28: Vielleicht im CM sogar im Idealfall in irgendeinen Knowledge-Datenbank oder es ist vielleicht überhaupt nicht gespeicher worden, weil sie nur in kurzer Zeit Gehtechnis war.

00:14:38: Die wichtige Unterscheidung ist einfach dass der AI Output diese Vorschlagbewertungen, Klassifizierung und Zusammenfassung an einer Stelle steht.

00:14:49: Im Enterprise Rekord brauchen wir aber dauerhaft gültig und nehmen uns Informationen mit klaren Ohner, Quelle, Live-Circle.

00:14:57: Zielsysteme verantwortlichkeit zugespitzt.

00:15:00: auf das ganze mal einen Punkt zu bringen ist einfach.

00:15:03: EI ist halt kein System auf Record Das heißt die Informationen wenn sie in dem Chat herum eiern hilft mir nix.

00:15:09: Also EI erzeugt Wissen ja Aber nicht automatisch die Wahrheit weil es sich an der falschen Stelle vielleicht sogar liegt.

00:15:17: somit Wenn wir das drinnen wollen brauchen wir keine riesige neue Methodik.

00:15:24: Das denke ich mal, das ist nicht notwendig.

00:15:27: Aber wir brauchen etwas ganz was wichtiges, was uns eigentlich gar nicht gefällt.

00:15:30: Wir brauchen eine klare Barriere.

00:15:37: Kapitel V Meine Lösung aktuell Persistenz geht.

00:15:42: Es ist jetzt kein Rockerzahn, gibt es schon sehr lange nebenbei Aber AI darf bereits lesen aber nur kontrolliert schreiben.

00:15:51: Das ist die Konzent von unserem Persistence.

00:15:54: Was ist die Idee dahinter?

00:15:57: Wir haben drei Zustände, die wir uns betrachten müssen.

00:16:00: Der erste ist das der Session-Context, also was Tempo mehr ist.

00:16:03: Also nur aktuelle Aufgaben, nichts automatisch dauerhafter und natürlich diese Informationen gelöscht werden.

00:16:10: Dann hat man einen zweiten State dahinter, es ist dieser Proposed Knowledge, also eher erzeugte Empfehlungen Bewertung macht für unsere Klassifizierung oder auch Entscheidungsvorschläge Aber es ist noch immer kein Enterprise-Record.

00:16:26: Ein Enterprise-Record muss ja dann eigentlich dauerhaft sein, das muss kontrolliert sein ohne einen definierten Zielsystem.

00:16:37: Dazwischen ist aber etwas ganz Wichtiges und zwar dass es bis es denn geht.

00:16:43: Das ist jetzt kein neues Framework, was ich da verkaufen möchte oder eintrichten möchte eher eine technische und vor allem prozentuale Kontrollpunkt.

00:16:52: Ich habe über das bevor ich über diese Folge mehr Gedanken gemacht habe, mal Gedanken auch gemacht dazu wie kann ich diese Geschwindigkeit die wir gerade fahren reduzieren?

00:17:02: und da bin ich auf die Idee gekommen einfach wie die Polizei das immer macht sparen einbauen du fährst deswegen nicht schneller oder beziehungsweise geschwindigkeitskontrolle einzuführen.

00:17:14: Und das ist das Konzept dahinter.

00:17:18: Erster Kontrollpunkt wenn man das jetzt mal so definieren möchte ist die Destination.

00:17:23: Also wo gehörte Informationen hin?

00:17:26: Ich habe vorhin schon bis erzählt nach Grunddaten können, dorthin Produktdaten ins PIM etc.

00:17:31: Er wichtig ist aber nicht irgendwo im Agent-Memory liegen zu lassen sondern das Zielsystem wirklich bewusst festzulegen dass diese Data Entities der Output von diesen AI Agents auch das Ziel System erreichen.

00:17:44: Das heißt wenn ich eine Risikoabschätzung mache mit ein Agent.

00:17:47: Sollte es im Endeffekt nicht einfach nur in einen Memo rauskommen, okay Risiko xy sondern soll im Risk Management warten?

00:17:56: Dann der zweite Punkt wer herkommt woher stammt diese Information?

00:18:02: also kurz erfassen um welche Daten geht das und welche Systeme, um welche Dokumente, welches Modell hat er sich erstellt unter welche Version?

00:18:10: vielleicht auch welcher Agent Und vor allem wann wurde es erzeugt?

00:18:14: Das zusammen erhöht im Endeffekt diesen die Informationssicherheit.

00:18:22: Der dritte Kontrollpunkt.

00:18:24: On-Ship Wer übernimmt die Verantwortung?

00:18:29: Beispiel.

00:18:32: Custom Informationen habe ich natürlich ein Customer Owner, ein Produkt habe ich ein Product Owner bei Architekturentscheidungen verantwortlich das jeweilige Architekten und bei Risiko habe ich den Risk Owner.

00:18:44: Genau!

00:18:44: Wichtig!

00:18:45: Wenn halt EI etwas erzeuger ist, dann ist aber blöderweise kein fachlicher Ohner dazu.

00:18:52: Sondern dazu braucht es halt ein wirklich dediziertes Ownership.

00:18:57: Vierter Kontrollpunkt einfach decision-wide.

00:18:59: darüber haben wir in der letzten Folge ja viele schon gesprochen.

00:19:02: Darauf will ich jetzt nicht so in der Tiefe eingehen.

00:19:04: wie auch immer man muss halt wirklich klar nach case definieren was Was darf der AI informieren?

00:19:15: Darf er empfehlen, vorbereiten oder sogar schreiben.

00:19:21: Das war jetzt ein English.

00:19:24: Der fünfte Kontrollpunkt und auch eigentlich sehr wichtiger ist für mich einfach Lifecycler.

00:19:29: Wie lange darf dieses Wissen wirklich gültig sein?

00:19:32: Ist es jetzt dreißig Tage gültige, ist es für immer gültiger?

00:19:36: Wann wird das gelöscht?

00:19:37: Ist der Käse überhaupt relevant?

00:19:39: Zum Mitstellen stellt sich die Frage halt einfach... Wenn ich das aus dem Agent ziehe, dann ist das ganze am Schluss auch exportierbar.

00:19:47: Hat es eine Integration woanders hin?

00:19:49: Darf ich es löschen?

00:19:50: wie darf ich es lösen?

00:19:52: und vielleicht muss ich sogar mal wieder neu validieren.

00:19:55: aber wie mache ich das?

00:19:59: Gut wenn wir das Ganze nochmal in ein Beispiel verpacken.

00:20:04: Immer mal an die EI erkennt Das ist ein Beispiel von vorhin.

00:20:09: Unser Grund hat eine sehr hohe Wahrscheinlichkeit für eine Abwanderung.

00:20:15: Die schlechte Variante ist natürlich halt die Synformation in Memory und dann nächste EU nimmt es als Fakt.

00:20:24: Nächste Empfehlung passiert darauf, so egal ob dieser Wert stimmt oder nicht.

00:20:28: lassen wir das aus und vor.

00:20:30: Die bessere Variante wahrscheinlich wäre einfach dass AI Proposed das gesamte Knowledge Und jetzt kommt das Wichtigste.

00:20:38: dieses Persistence geht wird klar definiert und zwar die Destination.

00:20:43: In dem Fall haben wir hier auch Kunden Informationen ist das CM.

00:20:47: Die Herkunft sind, wo kriege ich die Informationen her?

00:20:51: Ich habe das aus Tickets auf Order History und CM und Tracking und bla bla bla.

00:20:56: Das klare Ownership wird definiert.

00:20:58: In dem Fall jetzt Customer Sales und Owner bla bla.

00:21:01: es wird klar definiert was diese Entscheidungsrechte dahinter sind.

00:21:05: EI darf nur empfehlen der Mensch bestätigt hier Und das ganze ist eine Gültigkeit von dreizig Tagen.

00:21:12: Dann wird das Ganze nämlich so ein Enterprise Record Und somit Governets heißt dann nicht nur einfach bitte speichere nichts Falsches, sondern du kannst technisch gar nicht ungeprüft in ein Führendesystem schreiben.

00:21:24: Wir haben etwas geschaffen mit dem wir uns eigentlich natürlich einen Hindernis schaffen und auf der anderen Seite Qualität.

00:21:36: Kapitel sechs die Governets.

00:21:38: haben wir eigentlich so mitscham.

00:21:40: Wir brauchen nicht noch ein neues AI Governets Wimberg!

00:21:44: Wir müssen bestehende Governets nur bis zu einem erzeugten Wissen verlängern.

00:21:51: Wir haben uns noch mal kurz Gedanken zurückholen aus den folgenden Folgen.

00:21:55: Da habe ich über AI-Dement gesprochen, warum brauchen wir ja auch welches Problem lösen oder welche Kippebilder wird damit erreicht?

00:22:03: Wir haben über Decision Records gesprochen und so ich erinnert es.

00:22:07: Wenn wir AI technisch wird eingebunden, dann haben wir welches Thema für die Angegriff, welche Daten oder Daten oder welches Modell bis zu der Mitte erzeugt.

00:22:17: In der letzten Folge, und das ist vielleicht auch sehr entscheidend für diese, jetzt ist einfach this decision rights.

00:22:24: Was darf die AI tun?

00:22:26: Darf sie empfehlen, darf sie zustimmen, darf Sie verneinen, darf sich einfach wirklich exekutieren.

00:22:32: Jetzt ergänzen wir das Ganze etwas.

00:22:34: was darf AI dauerhaft zurückschreiben?

00:22:37: Und mit zurückschreiben meine ich raus aus dem AI Service Agent bla bla bla wie die ganzen paar Sorte heißen hin zu unseren eigentlichen System of Record Daten.

00:22:47: und was bleibt eigentlich den Premiere in der IEI hängen?

00:22:50: Und was wird am Schluss ein Enterprise Record oder System of Record?

00:22:53: Somit habe ich eine sehr saubere Kette hier eigentlich hochgezogen.

00:22:58: Wir gehen halt wirklich von diesem, oder wir erweitern ein bisschen dieser IEi Demand.

00:23:07: Ich komme vor einer Architektur-Entscheidung definiere die IEirechte nicht die Laufzeit des Persistents Gate und definiere gleichzeitig, was wir am Schluss dann nachher zu einem Enterprise-Rekord.

00:23:22: Somit haben wir nicht noch eine Gawane, sondern einfach nur eine Erweiterte.

00:23:28: Was wir eigentlich immer kontrollieren glauben zu müssen ist der Eingang von Informationen.

00:23:33: also was kommt alles rein?

00:23:35: Wir sollten uns auch vor allem über den Ausgang Gedanken machen.

00:23:39: was kommt da alles raus selbst wenn wir Menschen dazwischen setzen?

00:23:44: das Problem ist damit leider nicht automatisch gelöst.

00:23:51: Kapitel sieben, human in the loop ist keine automatische Sicherheit blöderweise ich habe letztens einmal ein bericht gelesen dass human und in der lube über die zeit wahrscheinlich sterben wird.

00:24:05: also versetzt halt einen mensch im.

00:24:07: prozess bedeutet noch lange nicht das wir wirklich kontrolliert oder das wirklich kontrollieren wird.

00:24:18: es gibt dann begriff den nennt sich automation bias.

00:24:22: was heißt das?

00:24:24: Menschen vertrauen automatisierten Empfehlungen einfach zunehmend.

00:24:29: Und besonders wenn sie oft richtig sind.

00:24:32: Kontrolle nimmt damit über die Zeit ab, das heißt wenn ich jetzt meine EIFrage fünfmal wieviel ist zwei plus zwei und er mir immer wieder sagt es ist vier dann glaube ich ihm dass über die zeit Licht davon ausgingen dass ein matrimatisches Schini ist aber über die Kontrolle danach starke Motivikationen durchführen, von wie viel es hunderttausend mal... ...jahrhundertausend mal.

00:24:58: drei Komma neun Neun Neuen dividiert durch Hundert.

00:25:01: Keine Ahnung!

00:25:03: Dann überrüfe ich das natürlich nicht nochmal.

00:25:06: und dieses Verhalten ist natürlich nicht gut.

00:25:11: und das ist genau dass das Human in der Loop einfach absterben wird was das angeht.

00:25:17: Faktisch ist er einfach eher entscheidet und die Menschen bestätigen danach noch Wir werden nicht dann jede Entscheidung noch mal überprüfen, oder?

00:25:26: Dann haben wir vielleicht in unserer Prozesskette human indialoop aber eigentlich nur einen human indiat den loop anklickt.

00:25:34: Wenn wir die... und jetzt kommt das Wichtiger ist wie müssen?

00:25:37: ich glaube das habe ich schon bei Datenentitäten gesprochen dass wir gegen die kritische Masse definieren müssen.

00:25:45: Und wenn ich weiß es handelt sich um kritische Informationen muss ich damit auch ein bisschen anders umgehen Und zwar muss ich gerade da viele Faktoren mit einfließen lassen.

00:25:57: Ich muss die Quelle gegen Original-Daten prüfen, ich muss eher eine Ableitung klar Kennzeichen im Text oder in meinem Record Die fachlichen Verantwortung dahinter benennen und bei hohem Risiko ein Vier-Augen-Prinzip einführen.

00:26:12: Vielleicht zusätzlich noch eine Validierung aber auf gar keinen Fall eine automatische Persistenz.

00:26:18: Nehmen wir zurück Schauen wir zu den letzten Folgen, da habe ich auch gesagt, also operative Autonomie heißt nicht gleiche Entscheidungshoheit.

00:26:26: Menschliche Verantwortung Nicht bitte durch einen Approve-Button ersetzen Das hat damit nichts zu tun.

00:26:34: Also human in the loop Hat ein bisschen mehr und ich hab es vorhin kurz erwähnt Wie wichtig das eigentlich ist.

00:26:45: Und jetzt sind wir schon wieder am Ende der Folge angelangt.

00:26:48: Aktuelle Jai Diskussionen drehen sich einfach finde ich einfach extrem nur um irgendwelche Modelle, die sich aktuell gegenseitig immer handshakemäßig verabschieden.

00:26:59: Asians, die noch besser sind und schneller sind.

00:27:01: Und vor allem natürlich die Tokens.

00:27:03: Das geht auch dann viel bei Kostenmehrentschmands.

00:27:06: Es hat sehr viel in meinem Umfeld grad zu tun.

00:27:09: Und natürlich wie ist die Performance dahinter?

00:27:12: Was machen wir langfristig?

00:27:15: aber das... Da ist noch wirklich viel wertvollere Geschichten, die wir uns annehmen sollten und zwar genau das.

00:27:22: Und dass heute in dieser Folge gegangen ist was passiert mit den Unternehmensdaten?

00:27:27: Was ist mit dem Kontext dahinter?

00:27:29: also AI-Kontext bitte?

00:27:31: Die Erfahrungen, die Entscheidungen wie sind diese Korrekturen zustande gekommen?

00:27:35: Die gesamte Historie dahinter ist wichtig!

00:27:38: Eine Entscheidung alleine hilft uns nichts.

00:27:40: oder der Output von AI sondern diese ganze Umtransformierung des Kontexts Weil das steigert unser Wissen am Ende des Tages.

00:27:50: Wenn man das Ganze so ein bisschen runter bricht, was nehme ich jetzt eigentlich davon mit?

00:27:54: Das Modell darf natürlich austauschbar sein.

00:27:59: Das Wissen des Unternehmens aber nicht bedeutet einfach im zweiten, das zweite Takeaway ist einfach EI.

00:28:05: Memory is halt kein System of Record.

00:28:08: Ich denke mal wenn wir uns das mal aus dem Kopf einmal festnageln dann wird uns Viele Entscheidungen, auch gerade bei so EI Demands ein bisschen anders wahrgenommen.

00:28:19: Drittens EI darf Wissen erzeugen nur als auch.

00:28:24: Aber wir in der Enterprise-Heldung müssen am Schluss entscheiden wann daraus wirklich Unternehmensdaten oder Wissen wird.

00:28:32: Mal kurz zum Mitschreiben Persistenz geht was ist das nochmal?

00:28:37: Wir reden über wo das ganze gespeichert wird Wo es wirklich herkommt und wie es entstanden ist über das Ownership das Entscheidungsrecht und vor allem den Lifecycle.

00:28:48: Nicht mehr will ich dazu noch sagen, der Rest findet ihr ja über die Folgen hinweg.

00:28:54: also es setzt sich hier viele Sachen gerade zusammen und ich habe einfach jetzt für diese Folge das ganze nochmal ein bisschen schlüssiger gemacht grade was mit dem Output machen sollten und wieder mit umgegangen wird.

00:29:09: wenn wir morgen das Modell wechseln sollten Sollte unser Unternehmen danach nicht plötzlich wenige über sich selbst lösen, oder was?

00:29:17: Servus und Papa und bis auf bald!

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.