Was Führungskräfte über GenKI wissen sollten

Willkommen zum Podcast von FS-ISAC, FinCyber Today. Ich bin Elizabeth Heathfield, Chief Corporate Affairs Officer bei FS-ISAC. Angesichts der Entwicklung generativer KI von einem coolen, innovativen Ansatz hin zu absoluter wirtschaftlicher Notwendigkeit müssen Unternehmen und Teams lernen, nicht nur über KI nachzudenken, sondern wie KI zu denken. Patrick Sullivan, Vizepräsident und CTO bei Akamai, hat sich intensiv mit mir darüber ausgetauscht, wie Sicherheitsteams lernen können, die nicht-deterministische Natur von KI-Tools zu nutzen. Vielen Dank, dass Sie hier sind. Ich weiß das sehr zu schätzen. Ich freue mich riesig darauf, mit Ihnen zu sprechen, weil ich weiß, dass wir beide KI-Geeks sind. Sprechen wir also über den Umgang mit nicht-deterministischen Risiken. Legen wir die Regeln fest und definieren die Grundlagen. Was versteht man unter Nichtdeterminismus in GenAI-Modellen? Perfekt. Ja, ich halte es für wichtig, zunächst den Hintergrund zu erläutern. Ich denke, wenn wir uns die generativen KI-Modelle ansehen, von denen wir alle so begeistert sind, dann führen sie im Grunde eine Vielzahl komplexer Matrixmultiplikationen durch und versuchen daraufhin, das nächste Wort mit den wahrscheinlichsten Ergebnissen zu vervollständigen. Und je nachdem, wie man das System konfiguriert, wird es sich um das wahrscheinlichste Ergebnis handeln, oder es wird eine weniger wahrscheinliche Alternative ausgewählt. Was das jedoch heißt und warum wir sagen, dass es nicht deterministisch ist: Wenn Sie das jetzt mit einer Reihe von Eingaben ausführen - mit diesem völlig statischen Modell und ohne Änderungen am System - erhalten Sie beim nächsten Durchlauf einen anderen Satz Ergebnisse, richtig? Und wenn Sie es erneut ausführen, erhalten Sie wieder andere Ergebnisse. So unterscheidet sich das System von vielen anderen Systemen, die wir traditionell ausgeführt haben. Es bedarf also einer anderen Denkweise, daran müssen sich die Leute erst einmal gewöhnen. Ein Beispiel sind Sicherheitstests. Wenn vielleicht eine latente Payload für einen Pumped-Injection-Angriff besteht, die nicht einmal ausgelöst wird, bedeutet das nicht, dass Sie sicher und nicht angreifbar sind. Denn wenn Sie das nächste Mal genau dieselbe Payload gegen genau dieselbe Anwendung ausführen, könnte sie erfolgreich sein, und Sie erhalten ein negatives Ergebnis. Ich denke also, es ist wichtig, dass die Leute das begreifen. Und ich habe festgestellt, dass es nicht ausreicht, das nur intellektuell zu verstehen. Das muss man wirklich in Aktion sehen. Man muss wirklich seine Finger auf der Tastatur und die Augen am Monitor haben und dieses Phänomen beobachten: Die latente Payload ist zunächst ruhig, dann führt man alles identisch aus und sieht deutliche Auswirkungen. So lässt sich verinnerlichen, was das bedeutet und welche Folgen es für die Sicherheit hat. Wie sollten die Menschen sich dies vor Augen führen, wie sollten sie das Ganze begreifen, insbesondere auf Unternehmensebene? Ich denke, es ist wichtig, dass die Leute wissen, dass wir nicht über Chatbots sprechen. Wir sprechen von komplexeren Abläufen, agentenbasierten Arbeitsabläufen und ähnlichem. Absolut. Die gute Nachricht ist, dass es in jedem Sicherheitsteam der Mitgliedsorganisationen heute sicher einige Spitzenkräfte gibt, die die zahlreichen verfügbaren Schulungsangebote aktiv nutzen. Und sie sind uns weit voraus. Führungskräfte sollten sich daher auf die Baseline konzentrieren. Wie kann man die Messlatte höher legen und sicherstellen, dass alle in der gesamten Sicherheits-Compliance-Organisation dieses Wissen erhalten? Das betrifft alles, von der Revision über Red Teams bis hin zu AppSec-Teams. Einige dieser Leute werden sich wahrscheinlich beim Basistraining langweilen. Ich denke aber, es ist wichtig, eine Baseline festzulegen. Vielleicht geht das mit einem Workshop, einem KI-Workshop oder einem KI-Hackathon. Da können die Leute einfach selbst probieren und dieses Phänomen direkt erleben. Das Motto "Sehen heißt Glauben" ist meiner Meinung nach wichtig. Und dann führt jemand eine Prüfung durch, während Sie sich fragen: "Hey, was bedeutet es wirklich, Gewissheit zu haben?" Nur weil ein Test "grün" angezeigt hat, wie sehen Sie das im weiteren Sinne? Könnte er beim nächsten Ausführen auf einem statischen System rot zeigen? -Ja. -Man will ja alle an Bord haben. Okay. Okay, wir haben also die Grundvoraussetzungen festgelegt. Okay, dann sprechen wir nun über einige der Möglichkeiten, die der Finanzsektor Ihrer Meinung nach nutzt. Welche Möglichkeiten bietet insbesondere diese neue Eigenschaft der GenAI? Perfekt. Ich denke also, dass Unternehmen die KI-Technologie in verschiedenen Organisationen in unterschiedlichem Tempo einführen. Einige Führungspersonen kommentierten: "Wir mögen zwar ein etabliertes Unternehmen sein, doch wir werden die Chancen, die die KI bietet, nicht den aufstrebenden Start-ups und Fintech-Unternehmen überlassen." Wir werden diese Chancen nutzen." Es ist also toll, diese Risikobereitschaft zu sehen. Doch im Zuge dessen setzen Unternehmen einige dieser KI-Tools möglicherweise zunächst als "Entwicklungs-Co-Piloten" ein, nicht wahr? Ich glaube also, dass wir hier allmählich erste Ergebnisse durch die gesteigerte Produktivität der Entwickler sehen. Ich habe letzte Woche eine aktuelle Studie von einem unserer Partner bei Apiiro gelesen. Darin heißt es, dass sich bei der Entwicklung von GenAI-Co-Piloten die Anzahl der Software-Updates gemessen an den aufgewendeten PRs vervierfacht. Und dann könnte es im Durchschnitt zu einer Verzehnfachung über alle verschiedenen AST-Tools hinweg kommen. Viele davon sind doppelt, doch im Allgemeinen beschleunigt sich alles, was großartig für das Geschäft ist. Aber wenn das Sicherheitsteam, insbesondere AppSec, keine Möglichkeit zur Automatisierung findet, überrollt Sie die Konkurrenz. Das ist also eine Chance. Ich denke, eine weitere Chance könnte einfach die Abdeckung sein, oder? Wir erhalten so viele Alarme von all unseren tollen Tools. Und beim Lesen der Berichte über Sicherheitsverstöße wird oft klar, dass sich ein schlimmer Vorfall ereignet hat. Und es war nicht so, als ob kein Tool einen Alarm ausgelöst hätte; oft gab es hier eine Warnmeldung, dort eine andere, doch sie erhielten einfach vom menschlichen Analysten keine Aufmerksamkeit. Wenn wir also eine bessere Abdeckung haben, vielleicht durch ein KI-System, das einige dieser Maßnahmen ergreifen und diese Schwelle senken kann, was genauer geprüft wird - - Ja. - ist das auch für uns eine Chance. Okay, wir haben also über einige der Möglichkeiten gesprochen. Sprechen wir über einige der Risiken. Welche Risiken sehen Sie, mit denen Unternehmen zu kämpfen haben, und durch die sie das Risikomanagement im Zusammenhang mit der Einführung von GenAI möglicherweise etwas anders betrachten als bisher? Welche Risiken sind damit verbunden? Ich denke, zum einen: Wenn wir uns den AppSec-Bereich ansehen, haben wir - ich persönlich habe - wahrscheinlich zwei Jahrzehnte damit verbracht, mich mit AppSec-Risiken zu befassen. Und eines der zentralen Anti-Muster, die wir bei AppSec-Problemen beobachtet haben, ist, wenn Code oder Anweisungen mit Daten vermischt werden, richtig? Die Daten gehören dahin, die Anweisungen dorthin, SQL-Anweisungen gehören in die Datenbank. Das ist eine Reihe von Problemen. Wenn Betriebssystemanweisungen interpretiert werden, gibt es weitere Risiken. Und ein Faktor, den wir beobachten, ist, dass bei diesen GenAI-Anwendungen Menschen einfach Anweisungen und Daten mischen - - Richtig. - Und einen Cocktail daraus machen. Das ist problematisch. Ich denke also, das Modell, um das es hier geht, ist die "toxische Dreierkombination", nicht wahr? Das heißt, wenn Sie externe Daten haben, sei es eine eingehende Abfrage oder Trainingsdaten, die in Ihr System eingegeben werden plus interne Daten mit einem RAG oder ein anderes System, das auf vertrauliche Daten zugreift, für die wir heute zahlreiche Regeln haben, wie diese Vertraulichkeit gewahrt wird und wer genau Zugriff darauf erhält. Und dazu kommt noch das dritte Glied, der Kommunikationskanal. API... Direct ist gewissermaßen der schlimmstmögliche Fall, wissen Sie? Aber auch der Zugriff auf Dinge wie E-Mail oder Software-Steuerungsmodule, ein öffentliches Repository oder Slack, eines dieser Tools. Wenn diese drei Dinge diese toxische Dreierkombination bilden, bedeutet das heutzutage wahrscheinlich, dass ein gewisses Risiko besteht? Und Sie werden extrem starke Gegenmaßnahmen benötigen, um dem entgegenzuwirken. Wenn Sie sich also auf zwei der drei beschränken können haben Sie damit wahrscheinlich viel bessere Chancen, als wenn alle drei vorhanden sind. Wenn wir konkret von Tools sprechen, die Unternehmen nutzen und die auf den Frontier-Modellen aufbauen, ist das sozusagen der Ort, an dem das Gemisch stattfindet? Das könnte definitiv sein. Ich denke, dass uns die Frontier-Modelle diese externen Daten liefern werden. Man hat also von Anfang an alle möglichen externen Daten, - - Ja. - die von einem Angreifer manipuliert werden könnten, nicht wahr? Wenn die wissen, was da drin ist, können sie es mit einer von ihnen erzeugten Eingabe herauskitzeln. Und wenn man das dann noch mit den anderen kombiniert, gerät man in eine schwierige Lage. Das ist also sicherlich ein Teil des Risikos, dem wir jetzt ausgesetzt sind. Wie geht man mit dem Risiko um, wenn alles zwar richtig erscheint, aber nicht richtig ist? Wie kann man das berücksichtigen? Denn, wissen Sie, früher lebten wir eher in einer "entweder-oder-Situation", es gab "schwarz oder weiß". Und jetzt haben wir: "Ok, das Modell gibt etwas zurück, es sieht alles gut aus und es scheint auch zu stimmen. Sollten wir mehr als ein Modell verwenden? Wie finden wir heraus, wie wir es überprüfen können? Ja, das ist eine schwierige Frage, denn ich denke, diese Systeme liegen oft richtig, manchmal falsch, aber sie sind immer selbstsicher. Ich denke also, dass es da eine Vielzahl von Techniken gibt. Eines davon wäre ein Modell, das das Modell überwacht, um Varianten aus früheren Anfragen zu prüfen. Bei anderen Systemen höre ich von Unternehmen oft – je nach Wichtigkeit: "Wir sind noch nicht bereit, die Menschen aus dem Prozess herauszunehmen. Wir haben eine menschliche Sicherheitsmaßnahme." Ganz ehrlich, in der Sicherheit sagt man oft: Der Mensch ist das schwächste Glied. Es ist also ein wenig ironisch, dass wir genau darauf zurückgreifen. Aber das sind mögliche Ausgleichsmaßnahmen. Das ist aber auch definitiv etwas, das wir im Auge behalten müssen, dass wir in dieser Phase der Reife sehr souveräne Antworten erhalten werden, die jedoch völlig falsch sind. Ich möchte also in diesem Zusammenhang darüber sprechen, wie wir überhaupt wissen, was ein Misserfolg ist. Und natürlich gibt es auch Bewertungen. Es gibt umfassende Versuche, im Grunde KI zu entwerfen, die KI überprüft. Und dann gibt es noch die Überprüfung durch Menschen, aber es könnte am Ende tatsächlich Menschen mehr Zeit kosten, das System zu überprüfen, als wenn sie es gleich selbst getan hätten, statt das ganze - - Genau. - neue, teure System einzuführen. Es gibt verschiedene Möglichkeiten, um zu bewerten und überprüfen, egal, ob das automatisiert, von einem Menschen oder auf andere Weise geschieht. Aber es gibt auch eine Menge regulatorischer Anforderungen. Und wie sollten wir Ihrer Meinung nach vorgehen, um unsere allgemeinen GRC-Anforderungen und Ähnliches einzuhalten, während wir das alles klären? Weil es offensichtlich nicht... es wird es eine Weile dauern. Ganz sicher. Wissen Sie, es besteht ein enormes Ungleichgewicht zwischen dem Innovationstempo in diesem Bereich, dessen Halbwertszeit kürzer ist als alles, was ich in meiner beruflichen Laufbahn bisher erlebt habe. Und dann dem Tempo, in dem die Regulierungsbehörden bekanntlich arbeiten. Wir möchten also auf jeden Fall verständnisvoll gegenüber unseren Kollegen im GRC sein, die mit dieser Diskrepanz zu kämpfen haben. Aber gleichzeitig basieren viele wirklich strenge Regulierungen auf Grundprinzipien. Und vieles davon wird in diesem Bereich auch beibehalten werden. Sie wissen schon, die Grundlagen: Gibt es eine genaue Bestandsaufnahme darüber, wo diese Technologien eingesetzt werden? Wir sprachen über deterministische versus nicht-deterministische Systeme. Sicherlich sollte darauf hingewiesen werden, dass, wenn Sie das Modell kennen, und wenn Sie die administrative Kontrolle über dieses System haben, Sie es manipulieren können. Und man kann diese Systeme konfigurieren, man stellt die Temperatur auf null und kann sie dazu zwingen, deterministisch zu sein. Und hier könnte es hilfreich sein, wenn Sicherheit und Compliance einen gewissen Druck auf das Unternehmen ausüben. Denn es gibt Systeme, die nicht unbedingt nicht-deterministisch sein müssen, richtig? Wenn es sich um eine vermeintlich langweilige Anwendung im Rechts- oder Rechnungswesen oder ähnlichen Bereichen handelt, braucht man keine extreme Kreativität. Und vielleicht bevorzugt man bei einem Agenten Vorhersagbarkeit. Es gibt noch andere Bereiche, in denen man argumentieren könnte, dass man eine breitere Auswahl weniger wahrscheinlicher Ergebnisse benötigt, um das zu erzeugen, was Menschen als Kreativität der Systeme wahrnehmen. - Ja. Ich bin jedoch der Meinung, dass man die kritische Frage stellen sollte: Braucht man wirklich dieses Maß an nicht-deterministischem Verhalten in einem System? Dies sollte hinterfragt und ein Case dafür angeführt werden. Ja, man möchte es also möglichst deterministisch gestalten. Ich habe auch schon gehört, dass Leute eine Aufgabe aufteilen: In Teile für den Agenten- und für den Subagenten-Workflow. Denn wenn der Subagent nur diese Aufgabe erledigt, ist genau nachvollziehbar, wann etwas schiefgeht. Wenn es hingegen nur einen einzigen Arbeitsablauf gibt, bei dem jeder unzählige Schritte ausführt, ist es sehr schwer zu erkennen, wo etwas schiefgelaufen ist. Wenn man das also in seine kleinsten Bestandteile zerlegen kann, macht man es deterministischer, auch wenn trotzdem alles automatisiert ist. Definitiv. Ich denke, das ist ein weiteres hervorragendes Beispiel. Und das ist ein Bereich, in dem wiederum die genauen Prüfungen durch die Sicherheits- und Compliance-Abteilungen bessere Ergebnisse liefern. Das ist fast schon wie Aufgabentrennung - -Ja, genau. - wo man einige dieser Dinge unterbringen kann. Wir haben den Vorteil, dass wir auf wirklich sehr soliden Grundprinzipien aufbauen, nach denen wir handeln. In einigen Fällen kann es hilfreich sein, diese Systeme so zu behandeln, als glichen sie allen anderen, und sie denselben traditionellen Prüfkriterien zu unterziehen. Andererseits nutzen die Angreifer jedoch die nicht-deterministische Natur aus, um äußerst opportunistisch vorzugehen. Sie können einfach drauflos probieren und darauf hoffen, dass dabei ein unerwartetes kreatives Ergebnis eintritt. Auf eine Art... wollen wir nicht... Wenn wir so deterministisch werden, dass wir die Macht begrenzen, verschaffen wir damit möglicherweise auch den Bedrohungsakteuren einen Vorteil. Sehen Sie das auch so? Ja, ich denke ... Wenn wir in die Zukunft blicken ... Ich komme noch einmal auf das AppSec-Beispiel zurück. Wissen Sie, traditionell entwickeln wir APIs und Anwendungen für Menschen - - damit sie auf die eine oder andere Weise produktiver werden - Ja. - geleitet von einer Suchfunktion. Wenn wir in die Zukunft blicken, sehen wir möglicherweise, dass wir APIs und Webanwendungen entwickeln, um einen Agenten oder einen Chatbot mit Daten zu füttern. Nicht wahr? Wenn Menschen unter bestimmten Voraussetzungen entscheiden müssen, welches Finanzinstitut für sie am besten geeignet ist, tun sie dies möglicherweise mit einem Agenten oder einem Chatbot. Und die Art und Weise, wie wir diese Bots pflegen, die zum Training beitragen, sowie die Art und Weise, wie wir auf diese Agents reagieren - dies erfordert möglicherweise eine andere Herangehensweise, um den jeweiligen Anwendungsfall zu optimieren, im Gegensatz zu dem, was wir heute für einen allgemeinen Web-Besucher tun. Das ist also der erfreuliche Fall, in dem hinter einem Teil dieser Technologie ein echter Kunde steht. Natürlich gibt es dann auch Nachahmer und Personen, die dieselben Tools für unlautere Zwecke nutzen. Und womit wir uns dort auseinandersetzen müssen, ist einfach mehr Automatisierung, mehr Bots, die unsere Website besuchen, und delegierte Identitäten aufweisen. Wenn ich der rechtmäßige Inhaber meiner Identität bin, aber möchte, dass ein Agent Sachen in meinem Namen erledigt - das ist etwas, was wir jetzt bereits beobachten. Aber wir befinden uns da noch ganz am Anfang. Das wird für die Teams im IAM-Bereich, bei der Autorisierung, Herausforderungen mit sich bringen. Dort gibt es noch viel zu tun. Ja. Das hatten wir vorhin schon in unserer Podiumsdiskussion besprochen. Dazu kommt die neue Dimension des Risikos durch Dritte und der Lieferkette, auch bekannt als "Nth-Party-Risiko". Denn wenn Agents mit Agents sprechen - Es gibt unsere Lieferanten, die Agenten haben, die wieder mit anderen Agenten sprechen. Und darin gibt es keinerlei Transparenz. Es sind also sozusagen Blackboxes über Blackboxes - Blackboxes bis ganz nach unten. Was sollten wir uns dazu überlegen? Wir stehen bereits vor der Herausforderung, Lieferkettenrisiken zu reduzieren. Jetzt fügen wir dem eine weitere Ebene hinzu, in die wir noch weniger Einblick haben. Verstehen Sie? Was sollten wir uns dazu überlegen? Ja, ich denke, die erste Herausforderung, vor der wir stehen, besteht darin, dass auf der Client-Seite - wenn jemand einen Agenten nutzt – dieser ordnungsgemäß identifiziert und entsprechend behandelt wird und überprüft wird, ob es sich tatsächlich um die delegierte Identität handelt, die wir autorisieren möchten. Das ist unser erster Schritt. Und dann nutzen wir im Backend vielleicht Drittanbieter, die weiter entfernte Parteien kontaktieren. Ich denke also, dass wir so unser Lieferkettenrisiko minimieren. Und ich denke, eine der Mitgliedsfirmen hat dies zu Beginn des Jahres mit Pat Opets offenem Brief an SaaS-Anbieter wohl treffend auf den Punkt gebracht, indem einige Lücken im heutigen Ökosystem wirklich deutlich aufgezeigt wurden. Und ich denke, ein Teil dieser Lösung wird von SaaS-Anbietern kommen, wodurch mehr Transparenz über die nachgelagerten Prozesse entsteht. Wir sehen, wie die Gegner das erzwingen. Das war sehr prophetisch. Wir haben viel über LLMs gesprochen, Und das ist sozusagen das, woran jeder bei GenAI sofort denkt. Aber es wird auch viel über das Potenzial kleiner Sprachmodelle geredet. Insbesondere bei sehr speziellen Anwendungsfällen. Vielleicht braucht man gar nicht das Meer, wenn es ein See vielleicht auch tut. Ist das ein möglicher Weg, um einen Teil dieses nicht-deterministischen Risikos zu bewältigen? Ich glaube schon. Ich denke, das ist ein weiterer Bereich, in dem Sicherheitsteams Druck auf Unternehmen ausüben und schwierige Fragen stellen sollte: "Brauchen Sie wirklich ein komplettes LLM mit all den damit verbundenen Risiken?" Bedrohungsmodellierung bei einem LLM ist doch total verrückt, oder? Denn man muss nun Folgendes überlegen: "Kann ich eine Finanz-App fragen, wie man Massenvernichtungswaffen baut?", richtig? Und das könnte je nach Training Teil Ihres Bedrohungsmodells sein. - Ja. - Wenn Sicherheitsteams Geschäftsprozesse infrage stellen ... Wir sprachen über: "Brauchen Sie wirklich ein nicht-deterministisches Modell, oder könnte in diesem Szenario ein deterministisches Modell funktionieren?". Und das liegt innerhalb der Konfigurationskontrolle. Ebenso halte ich es für sinnvoll, sich folgende Frage genauer anzusehen: "Brauchen Sie wirklich ein LLM, oder würde in diesem Anwendungsfall ein SLM reichen?" Das könnte ein weiteres Beispiel dafür sein, wie Sicherheitsteams Unternehmen zu einem für alle besseren Ergebnis führen könnten. Das ist eine Frage, die sich immer mehr Organisationen stellen. Und ich denke, das ist eine positive Entwicklung, die wir da beobachten. Ja, also es gibt das Modell - wir haben ja schon ein wenig über Temperatur gesprochen - - und dann geht es auch noch um die Kontrolle des Kontexts, richtig? Man kann den Kontext nicht einfach ewig weiterlaufen lassen, denn das mindert offensichtlich die Qualität des Ergebnisses. Außerdem gilt: Je mehr Ausgabe man erhält, je mehr Eingaben man macht - desto teurer wird es. Wenn man das also ein wenig einschränken kann. Und dann gibt es natürlich noch die Prompts, und vielleicht gibt es auch Möglichkeiten, diese vorhersehbarer zu machen. Es gibt da Wege, nicht wahr? Wir haben Prompt-Vorlagen, Prompt-Bibliotheken. Wenn man diese vorhersehbarer macht, sind dann zumindest die eingehenden Daten besser strukturiert. So kann man möglicherweise auch einen Teil des Nicht-Determinismus in all diesen verschiedenen Dimensionen bewältigen? Meine Beobachtung ist, dass wir unseren Leuten vermitteln müssen, welche verschiedenen Dimensionen existieren, damit sie wissen, welche Tools es gibt und dass es nicht alles ein Ding ist. Was denken Sie? Absolut. Wenn wir in die Vergangenheit zurückblicken, sehen wir, dass neue Trends aus Sicht der Sicherheit oft mit Nachteilen einhergehen. Als wir mit dem E-Commerce begannen, gab es eine ganze Welle von SQL-Injection-Angriffen, die einfach... Ganze Datenbanken überfluteten Webanwendungen. Wir haben daraus gelernt und die Eingaben in unserer Anwendung besser geprüft. Und als wir dann zur Cloud übergingen, sahen wir ein ähnliches Muster. Und ich nehme an, die Hoffnung hierbei ist, dass wir Lehren aus der Einführung dieser Webanwendungen ziehen können, die im Hintergrund mit sensiblen Daten verknüpft sind, wenn wir nun diesem neuen Trend folgen? Oder gibt es Lektionen, die wir durch die Cloud gelernt haben? Können wir diese Lehren aus früheren Erfahrungen ziehen, ohne dass erst Unternehmen wirklich darunter leiden müssen und alle anderen dann aus deren Leid lernen? Hoffentlich ist das hier der Fall, sodass wir einen Teil dieses Risikos verringern können, bevor es zu wirklich schweren Sicherheitsverstößen kommt. Okay, ich denke, wir haben viele Aspekte besprochen. Wenn Sie eine Erkenntnis aus diesem Gespräch hervorheben könnten, die die Zuseher mitnehmen sollten, welche wäre das? Ich glaube, es waren sehr viele interessante Punkte dabei. Ich würde sagen, der Schlüssel liegt darin, sicherzustellen, dass das Sicherheitsteam die Grundlagen beherrscht. Um zu diesen zurückzukommen, sollten wir ein grundlegendes Trainingsniveau für KI festlegen, hoffentlich praxisorientiert, sodass die Leute dabei im Rahmen eines Workshops oder Hackathons selbst Hand anlegen können. Denn ich glaube, dass wir viele der Grundprinzipien bereits beherrschen. Und wenn wir diese Dinge verstehen und sehen, wissen wir auch, wo wir sie anwenden können. Ja, meiner Meinung nach ist es wahrscheinlich das.