PODCAST
Data Security entscheidet über Erfolg oder Desaster der KI-Strategie

TRANSKRIPT

Warum Datensicherheit über Erfolg oder Desaster deiner KI-Strategie entscheidet

Andreas:
Hallo zusammen zu unserem Podcast AI or Die. Wer die letzte Folge mit Christian Bühler von Five1 gehört hat, weiß: Wir haben über Datensicherheit, Datensouveränität und darüber gesprochen, was das alles im KI-Zeitalter bedeutet.

Damals hattest du, Christian, auch ein Assessment vorgestellt und gesagt: Leute, füllt das aus, schaut euch an, wo ihr gerade steht und wie gut eure Grundlagen wirklich sind.

Jetzt haben wir vor der Aufnahme schon kurz gesprochen. Was ist seitdem passiert?

Christian:
Hi zusammen, Christian ist wieder hier. Ich freue mich, wieder dabei zu sein.

Was ist passiert? Wir haben in der letzten Folge das Thema Well-Architected-Framework mit den Zuhörerinnen und Zuhörern aufgegriffen und gesagt: Schaut vorbei, wir haben einen kleinen Check-up für euch vorbereitet.

Danach hatten wir einige Gespräche. Und tatsächlich, man mag es kaum glauben: Das Thema Security im Cloud-Umfeld und bei KI-Use-Cases war dabei sehr präsent.

Viele haben gefragt: Was passiert eigentlich, wenn wir mit Agenten oder Agentic AI starten? Was passiert mit unseren Daten? Wo liegen mögliche Risiken? Und was können wir dagegen tun?

Wie angekündigt habe ich deshalb heute Joshua mitgebracht. Er ist Kollege bei Five1 und hat schon viele KI-Use-Cases mit uns begleitet. Er kann dazu aus der Praxis einiges erzählen.

Andreas:
Moin Joshua. Schön, dass du da bist.

Ich steige direkt mit einer Frage ein. Früher war ich einer dieser Consultants, die Dashboards versprochen haben: Alles kein Problem, stellen wir hin, läuft.

Dann kam irgendwann die Frage: Was ist mit Security? Welche Sicherheitskonzepte habt ihr? Und dann musste ich sagen: Sorry, dafür hole ich jemanden dazu, der wirklich Ahnung hat.

Jetzt sind wir im Zeitalter der KI. Du bist heute genau die Person, die wir dazugeholt haben. Was erlebst du als KI-Berater beim Thema Datensicherheit?

 

Hype vs. Regulierung: Wo stehen Unternehmen?

Joshua:
Hallo auch von meiner Seite. Ich bin Joshua.

In der Praxis erleben wir häufig Unternehmen, die das Thema KI für sich entdeckt haben und sehr motiviert sind, loszulegen. Sie haben Ideen und wollen diese umsetzen.

Das Thema Sicherheit steht dann aber oft erst einmal hinten an, weil es nicht der Hauptfokus einer Person ist, die eine gute Idee hat und sie schnell realisieren möchte.

Dann gibt es natürlich auch Unternehmen, die schon deutlich genauer wissen, wohin sie wollen. Dort wurden erste Gedanken zu Security und regulatorischen Anforderungen bereits gemacht. Diese Kunden holen sich dann gerne zusätzliches Feedback und konkrete Ratschläge.

Andreas:
Das heißt, eure Kunden haben das Thema grundsätzlich auf dem Schirm.

Wie konkret sind die Fragen? Ist es eher allgemein: „Was ist mit Sicherheit?“ Oder kommen schon sehr detaillierte Fragen, etwa zu Regulierung, Cloud-Souveränität oder konkreten Sicherheitsmechanismen?

Wo stehen die Unternehmen aus deiner Sicht aktuell?

Joshua:
Das Umfeld ist sehr unterschiedlich.

Es gibt Unternehmen, die Security von Anfang an mitdenken. Häufig aus Sorge vor Datenschutzverstößen, dem Abfluss geistigen Eigentums oder dem Verlust von Firmengeheimnissen.

Diese Unternehmen haben das Thema auf dem Schirm, oft aus einer berechtigten Sorge heraus. Denn Mitarbeitende sind auch nur Menschen und können Fehler machen. Dadurch kann man schnell in einen regulatorischen Verstoß geraten.

Auf der anderen Seite gibt es Kunden, die vor allem Lust haben, KI einzusetzen. Sie haben eine gute Idee. Ihnen ist Sicherheit nicht egal, aber sie holen sich Expertinnen und Experten dazu, um zu verstehen: Wie können wir unsere Idee umsetzen, ohne an regulatorischen Anforderungen oder Sicherheitsrisiken zu scheitern?

Die Haltung ist dann eher: Wir wollen das richtig machen. Könnt ihr uns dabei helfen?

 

Was ist durch KI wirklich neu?

Andreas:
Christian, ist das Thema durch KI wirklich neu?

Wir haben ja schon öfter darüber gesprochen: Macht zuerst Datensicherheit, stellt das Fundament sauber auf, kümmert euch um eure Daten.

Kommt mit KI jetzt tatsächlich etwas Neues dazu? Oder sagst du: Das Thema gab es schon immer, jetzt muss man eben den Keller aufräumen, und dann kommt KI-Security fast automatisch mit?

Christian:
Das ist unterschiedlich und hängt stark vom Kunden ab.

Wir sind auch in regulierten Umfeldern unterwegs, zum Beispiel bei Kunden aus dem KRITIS-Bereich. Diese Unternehmen gehen ganz anders an das Thema heran.

Dann gibt es Unternehmen mit Pioniergeist. Sie sagen: Ich habe eine Idee, die mein Geschäft voranbringen kann. Gerade im Handel oder bei internen Prozessoptimierungen sehen wir das häufiger.

Wenn ein Unternehmen intern Prozesse verbessern möchte, kann man oft schneller starten. Dort bringen wir Security teilweise schon in einem ersten Termin unter, weil es grundlegende Spielregeln gibt. Wenn man sich daran hält, läuft man nicht direkt in große Risiken.

Ganz anders ist es bei medizinischen Daten, Patientendaten oder Pharmastudien, in denen KI zum Einsatz kommt. Dort gelten völlig andere Voraussetzungen.

 

Schatten-KI und der „imperfect user“

Andreas:
Joshua, was bedeutet das für mich als Amateur?

Du hast eben fast einen freudschen Versprecher gemacht: Leider gibt es ja auch Mitarbeiter. Das heißt, ein großes Sicherheitsrisiko ist natürlich auch der Mensch selbst.

Ich kenne oft folgende Situation: Wenn Unternehmen keine offiziellen KI-Agenten oder Chatbots bereitstellen, entsteht eine Schatten-KI. Mitarbeitende nutzen dann private oder öffentliche Tools und geben dort plötzlich sensible Daten ein, zum Beispiel um eine E-Mail zusammenfassen zu lassen.

Ist das ein Thema, bei dem man Mitarbeitende sensibilisieren muss? Oder muss man es eher systemseitig lösen?

Joshua:
Das ist eine gute Frage.

Ich finde es hilfreich, einen konkreten KI-Use-Case oder einen Chatbot wie eine Datenpipeline zu betrachten. Im Grunde passiert genau das: Wir geben Informationen hinein und bekommen hoffentlich bessere Informationen zurück.

Diese Pipeline besteht aus mehreren Ebenen.

Zuerst gibt es die Input-Ebene: Welche Daten werden eingegeben?

Dann folgt das Processing: Was passiert während der Verarbeitung? Das ist besonders relevant, wenn zum Beispiel interne Wissensdatenbanken angeschlossen sind.

Dann gibt es den Betrieb: Wie laufen Monitoring und Logging? Welche Informationen stehen in den Logs? Wie werden Kosten überwacht?

Und natürlich gibt es den Output: Was kommt am Ende heraus?

Mitarbeitende sind vor allem auf der Input-Ebene relevant. Oft wissen sie gar nicht, welche Datenschutzverstöße entstehen können, wenn sie sensible Daten in einen Chatbot oder eine Schatten-KI hochladen.

Hier können Guardrails helfen, etwa Input Filtering. Man kann KI-Modelle einsetzen, die sensitive Daten erkennen und verhindern, dass diese Daten weiterverarbeitet werden.

Als Mitarbeitender wäre es doch deutlich besser, wenn mir mein Arbeitgeber ein Tool bereitstellt, das mich dabei unterstützt, keine sensiblen Daten hochzuladen. Dann muss ich nicht auf irgendeine private KI ausweichen, die solche Schutzmechanismen nicht hat.

 

Enterprise-Lösungen vs. öffentliche KI

Andreas:
Christian, nehmen wir einmal an, ein Unternehmen sagt: Wir haben Microsoft im Einsatz. ChatGPT und andere öffentliche Tools nutzen wir nicht. Wir setzen auf Copilot, weil wir ohnehin Office, Outlook und die Microsoft-Welt nutzen.

Microsoft kommuniziert ja sehr offensiv, dass Daten souverän und sicher verarbeitet werden können. Gleichzeitig macht es mich fast nervös, wenn Anbieter das so stark betonen. Da scheint ja ein echter Druck im Markt zu sein.

Wie siehst du das strategisch?

Christian:
Man muss unterscheiden zwischen öffentlich verfügbarer KI und Enterprise-KI-Lösungen, die speziell für Unternehmen geschaffen werden.

Wenn wir mit Kunden arbeiten, nutzen wir natürlich bestehende Modelle. Aber wir bauen unternehmenseigene Lösungen darauf auf.

Wie so oft ist das auch ein Thema der Unternehmenskultur. Wie führe ich Menschen an diese Werkzeuge heran?

Die Nutzung einfach zu verbieten, funktioniert nicht mehr. Wir kennen alle Schatten-IT. Früher war es Excel, dann Power BI. Und natürlich werden Mitarbeitende eigene Tools nutzen, wenn das Unternehmen ihnen keine saubere Alternative bietet.

Deshalb muss man die Pipeline so aufbauen, dass die Daten sicher sind und die Mitarbeitenden trotzdem sinnvoll damit arbeiten können.

 

Wann sind Daten wirklich sicher?

Andreas:
Wann sind meine Daten denn sicher?

Stellen wir uns ein Maturity-Modell vor. Es gibt verschiedene Stufen. Was wäre Stage 1, was wäre Stage 10?

Nehmen wir ein Beispiel: Ich bin Leiter Controlling und höre gerade, dass ich mich ernsthaft mit Datensicherheit beschäftigen muss. Wo fange ich an?

Joshua:
Wenn wir bei einer GenAI-Anwendung bleiben, die einen Controller unterstützen soll, ist zuerst wichtig: Welches Expertise-Level habe ich im eigenen Haus?

Für fast jedes Problem kann man eine Lösung definieren und bauen. Aber man muss auch wissen, wie.

Wir haben gerade über Microsoft gesprochen. Das gilt aber auch für andere Large-Language-Model-Provider. Oft gibt es einen Deal: Ihr dürft unsere API nutzen. Wir halten Daten vielleicht für 30 Tage, schauen sie uns aber nicht an und nutzen sie nicht fürs Training.

Das kann ein guter erster Anlaufpunkt sein. Denn es ist unrealistisch, dass jeder deutsche Mittelständler oder jedes Unternehmen ein eigenes Large Language Model trainiert.

Man muss sich an bestimmten Stellen darauf verlassen, was die Provider zusichern. Diese Zusagen sollten natürlich rechtlich belastbar sein.

Wenn es aber um hochsensible Daten geht, zum Beispiel im medizinischen Bereich oder bei Pharmastudien, kann es sinnvoll sein, architektonisch und bei der Modellauswahl deutlich souveräner zu werden.

Dann geht es darum, vollständig zu kontrollieren, wo Daten hinfließen, was mit ihnen passiert und ob eine dritte Instanz sie für Training oder Fine-Tuning nutzen könnte.

Aber: Wenn man ein solches System komplett selbst aufsetzt, liegt auch die gesamte Verantwortung bei einem selbst.

Deshalb lässt sich nicht pauschal sagen, welche Architektur eine 10 von 10 auf der Sicherheits-Skala ist. Es kommt immer auf den Use Case an: Welche Daten haben wir? Welche Risiken bestehen? Wer nutzt welches Tool? Welche Tools werden miteinander verbunden?

 

On-Prem vs. Cloud: Realität im Mittelstand

Andreas:
Christian, ist es eine Strategie, sich dieser Situation einfach zu ergeben?

Man hört ja heraus: Wir sind ohnehin auf große Anbieter angewiesen. In Europa haben wir es bisher nicht geschafft, einen einheitlichen Standard oder ein großes europäisches KI-Modell als Unternehmensbasis zu etablieren.

Früher hieß es oft: Die Telekom hat ein Rechenzentrum, Siemens stellt etwas auf, dort sind unsere Daten sicher.

Muss ich als Unternehmen jetzt sagen: Bevor ich massiv investiere, lasse ich es einfach laufen und schaue, was passiert?

Christian:
Abwarten war nur selten die richtige Lösung.

Wenn du einen Nagel in die Wand schlagen willst, brauchst du einen Hammer. Du musst die Werkzeuge nutzen, die verfügbar sind.

Natürlich gibt es die Möglichkeit, viel selbst zu tun. Wir haben auch On-Prem-nahe Lösungen umgesetzt. Aber man muss sich darüber im Klaren sein, welcher Aufwand damit verbunden ist.

Der richtige Weg ist aus meiner Sicht: Nutze den vorhandenen Werkzeugkasten, aber kenne die Fallstricke. Rüste dich entsprechend und baue die Lösung so auf, dass sie zu deinem Risiko- und Sicherheitsprofil passt.

Eine Verweigerungshaltung wäre an dieser Stelle auch eine Zukunftsverweigerung.

 

Sicherheit ist mehr als Hackerabwehr

Andreas:
Ich war einmal in einem Datensicherheitsworkshop bei einem Kunden. Dort sagte der Trainer: Die größte Bedrohung kommt nicht unbedingt von Hackern im schwarzen Kapuzenpulli. Viel gefährlicher sei oft, dass sich Menschen physisch Zugang zum Office verschaffen, zum Beispiel als Paketbote, und sich kurz irgendwo anschließen.

Wenn das stimmt, ist Sicherheit noch einmal viel größer gedacht. Dann muss ich Mitarbeitende noch stärker sensibilisieren.

Für mich war Sicherheit lange etwas, wofür der Staat oder das Umfeld sorgt. Nicht unbedingt etwas, wofür ich persönlich aktiv Verantwortung trage.

Muss man bei KI-Security auch in diese Richtung denken?

Joshua:
Ja, ich denke schon. Es ist wichtig, Menschen kleinschrittig mitzunehmen.

Wir hatten vorhin den „imperfect user“, also jemanden, der unbeabsichtigt sensible Daten in einen Chatbot hochlädt.

Ein erster Schritt wäre, Mitarbeitende dafür zu sensibilisieren, was im jeweiligen Unternehmenskontext überhaupt sensible Daten sind. Welche Kategorien von Daten dürfen nicht in eine KI hochgeladen werden?

Zum Thema Regulierung finde ich noch einen anderen Punkt spannend.

Wenn über den EU AI Act gesprochen wird, wird er oft als etwas dargestellt, das Innovation ausbremst. Man sagt dann: Jetzt müssen die Europäer wieder erst prüfen, ob sie etwas dürfen.

Als junger Mensch in einer Welt, in der KI so schnell adaptiert wird, finde ich es aber beruhigend, dass sich Menschen Gedanken darüber gemacht haben.

Unsere Aufgabe als AI- und Sicherheitsexperten ist es, Regulierung nicht nur negativ darzustellen. Man kann auch sagen: Es gibt Menschen, die sich sehr intensiv überlegt haben, wie KI sicher genutzt werden kann.

Sicher bedeutet dabei nicht nur: Wie vermeiden wir Business-Risiken? Sondern auch: Wie können wir diese Werkzeuge gewinnbringend, verantwortungsvoll und für alle nutzbar einsetzen?

 

EU AI Act: Bremse oder Leitplanke?

Andreas:
Das finde ich spannend.

Die Bankenregulierung ist für mich ein gutes Beispiel. Nach 2008 wurden Banken stärker reguliert. Es ging um Datendurchgängigkeit, Nachvollziehbarkeit und klare Regeln.

Dadurch wurden Banken gezwungen, besser mit ihren Daten zu arbeiten. Plötzlich entstand ein echter Schub, und Banken entwickelten sich stärker zu datengetriebenen Unternehmen.

Auch in der Pharmaindustrie kennen wir das: Regulierung kann Vorteile haben, weil Governance dafür sorgt, dass Dinge besser und sauberer werden.

Deshalb finde ich den Gedanken gut, den EU AI Act nicht nur als Verhinderung zu sehen, sondern auch als Chance.

Joshua:
Genau.

Vorhin habe ich von der Pipeline mit verschiedenen Risikostufen gesprochen. Viele dieser Aspekte wurden im EU AI Act bereits mitgedacht, zum Beispiel bei Robustheit und Cybersicherheit.

Als Entwickler und Experte sehe ich das so: Schlaue Menschen haben sich hingesetzt und Guardrails definiert. Damit kann ich beginnen, KI-Use-Cases für Unternehmen sicher zu designen.

Der EU AI Act kann also auch ein Leitfaden sein. Er sagt im Grunde: Achte auf diese Punkte, denke jene Themen mit, und du bewegst dich deutlich sicherer.

 

Governance im KI-Zeitalter

Andreas:
Man kann aber nicht nur den EU AI Act herunterladen. Christian, du hast ja gesagt: Jedes Mal, wenn du in den Podcast kommst, bringst du etwas mit.

Diesmal gibt es ein Whitepaper. Worum geht es darin?

Christian:
Es geht um Datensicherheit.

Joshua nutzt gerne das Bild des KI-Use-Cases als Datenpipeline. Genau darum geht es im Whitepaper: Wie ist so ein KI-Use-Case technisch typischerweise aufgebaut? Welche Stadien gibt es? Und worauf müssen Unternehmen an welcher Stelle achten?

Wir behandeln außerdem fünf typische Probleme im Bereich Datensicherheit und haben dazu Selbstcheckfragen formuliert. Damit kann man prüfen, wie gut man an den jeweiligen Stellen aufgestellt ist.

Du hast vorhin die Bankenregulierung erwähnt. Klare Vorschriften helfen weiter.

Was wir oft feststellen: Unternehmen probieren Dinge aus und geben zum Beispiel einem Agenten viel zu viele Freiheiten. Das ist ein echtes Risiko.

Ein wichtiges Thema ist deshalb: Wie setzt man klare Grenzen? Wie erkennt man, ob ein Agent zu viele Rechte hat? Und wie kann man relativ schnell prüfen, ob die richtigen Leitplanken gesetzt wurden?

Joshua:
Genau. Im Whitepaper haben wir die Themen noch einmal ausführlicher auf den Kontext deutschsprachiger Unternehmen gemappt.

Die größten Gefahren bei AI-Use-Cases sind aus meiner Sicht der Abfluss von Firmengeheimnissen, sensitiven Daten und natürlich DSGVO-Verstöße.

Wir haben fünf Beispiele aufgenommen. Dazu gehören Agenten mit zu vielen Privilegien, aber auch Themen wie Indirect Prompt Injection oder Angriffe, bei denen jemand gezielt sehr lange und komplexe Anfragen an eine KI stellt, um die Kosten auf Kundenseite in die Höhe zu treiben.

Wichtig ist: Das Whitepaper ist kein Horrorszenario. Es soll sensibilisieren. Es zeigt Risiken, aber auch Stellschrauben und mögliche Lösungen.

 

Typische Sicherheitslücken bei KI-Use-Cases

Andreas:
Unser Gespräch ist heute sehr aufgeräumt und nüchtern. Vielleicht liegt das am Thema Datensicherheit.

Ich versuche es einmal auf den Mittelstand herunterzubrechen. Früher waren wir eher ein Konzern-Podcast, aber mittlerweile hören uns viele Mittelständler.

Stellen wir uns ein mittelständisches Unternehmen vor, das Schrauben produziert. Es hat zwei Use Cases. Vielleicht kann Ausschussware um 0,1 Prozent reduziert werden, wenn bestimmte Maschinendaten angebunden und ausgewertet werden.

Was kann ein Mittelständler relativ schnell tun? Sensibilisierung hatten wir schon. Aber gibt es Tools oder Standards, mit denen man sicherer werden kann?

Joshua:
Auch hier kommt es auf den Use Case an.

In der IT gibt es viele Überwachungstools, nicht nur europäische. Gerade im Cloud-Monitoring sind Anwendungen wie Splunk sehr verbreitet.

In deinem Beispiel hat ein mittelständisches Unternehmen wahrscheinlich viele Maschinendaten: Statusdaten, Durchsatz, Effizienz, Anzahl produzierter Teile pro Stunde und so weiter.

Das sind nicht automatisch Daten mit dem gleichen Schutzbedarf wie medizinische Diagnosen. Deshalb ist auch ein anderes Maß an Sicherheit erforderlich als bei Gesundheitsdaten.

Ein sehr beliebter Use Case in solchen Szenarien ist Predictive Maintenance. Über Maschinendaten lässt sich früh erkennen, ob eine Maschine bald ausfallen könnte. Dann kann rechtzeitig ein Techniker geschickt werden.

Ich kenne auch größere Use Cases, bei denen Techniker zusätzlich einen Chatbot mit angebundener Wissensdatenbank bekommen. Dort sind Informationen zu den jeweiligen Maschinen hinterlegt. Auch wenn der Techniker eine Maschine noch nie gesehen hat, kann er mithilfe von Fotos und Chatbot schnell die relevanten Informationen abrufen.

Dann wird ein Punkt entscheidend: In dieser Wissensdatenbank müssen korrekte Informationen stehen.

Es darf nicht passieren, dass ein Angreifer diese Wissensdatenbank manipuliert und die KI dann selbstbewusst eine falsche Anweisung gibt, etwa: Zieh diesen Stecker, obwohl genau das falsch ist.

Deshalb hilft es, konkrete Use Cases durchzusprechen. Daraus ergeben sich die Risiken, die passenden Tools und ein Gefühl dafür, wie sicher die Lösung wirklich ist.

 

Manipulation von KI-Daten als reales Risiko

Andreas:
Das löst bei mir gerade einen Gedanken aus, den ich so noch gar nicht hatte.

Ich habe bisher vor allem Risiken von außen gesehen: Überlastung, Erpressung, Angriffe. Aber mir war nicht klar genug, dass die Manipulation von Daten in KI-Systemen eine viel größere Auswirkung auf die Ergebnisse haben kann.

Gerade wenn wir der Technologie stark vertrauen, sind manipulierte Daten ein massives Risiko.

Christian, wie kann ein normaler User das überhaupt noch überblicken? Joshua kann tief in die Systeme schauen, Schwachstellen finden und Plausibilitätschecks machen. Aber wie sensibilisiert man Menschen, die einfach nur mit dem System arbeiten sollen?

Christian:
Auch hier braucht es neben gesundem Menschenverstand klare Regeln im Unternehmen.

Bei KI haben wir im Gegensatz zu früher das Thema, dass sich Fehler viel schneller potenzieren können.

Wenn ich in einem Dashboard Datenmüll habe, stimmt vielleicht eine Kennzahl nicht. Wenn ich aber in einen KI-Use-Case fehlerhafte Daten einspeise, kann sich das im Output deutlich stärker auswirken.

Deshalb braucht es interne Guidelines. Unternehmen müssen festlegen: Wie nutzen wir KI? Mit welchen Daten arbeiten wir? Welche Personen dürfen damit arbeiten? Und sind diese Personen in der Lage, die Ergebnisse richtig zu interpretieren?

Joshua:
Ich würde ergänzen: Wenn eine Wissensdatenbank an ein Modell angeschlossen wird, sollte es eine verantwortliche Person geben, die diese Wissensdatenbank prüft.

Wer kontrolliert, welche Quellen hineinkommen? Wann wurde die Wissensdatenbank zuletzt aktualisiert? Sind die Informationen noch korrekt?

Das muss man mitdenken, damit solche Fehler gar nicht erst entstehen.

Und natürlich gilt: Gerade in High-Stakes-Situationen muss man KI-Antworten kritisch hinterfragen.

Christian:
Genau. Am Ende sind wir wieder beim Thema Governance.

Governance ist kein rein technisches Thema. KI-Governance ist ein Feld, in dem wir inzwischen viel bei Kunden unterwegs sind.

In den letzten Jahren hat sich Governance stark verändert. Wir sind weg von monolithischen Systemen und stärker hin zu Data-Mesh-Ansätzen. Verantwortung für Daten liegt häufiger in Fachbereichen.

Gerade im KI-Bereich sind wir deshalb massiv auf saubere Governance-Regelungen angewiesen.

 

KI-Workflows und vererbte Berechtigungen

Andreas:
Ich möchte noch auf ein Thema eingehen, das gerade sehr präsent ist.

Ich bin ein großer Fan davon, Tools miteinander zu vernetzen. Wir nehmen hier den Podcast auf, dann geht es in ChatGPT, es entstehen Vorschläge für Beschreibung, Thumbnail und weitere Schritte. Vieles ist automatisiert.

Das funktioniert gut und nimmt Arbeit ab.

Aber solche Workflows verlangen Zugriff auf viele Tools. Schon bei einer vergleichsweise einfachen Podcast-Kette muss ich mir überlegen: Welche Daten liegen in diesen Tools? Welche Berechtigungen gebe ich weiter? Was passiert, wenn sich Rechte vererben?

Im großen Stil reden wir dann über KI-Workflows, KI-Agenten und ganze Pipelines. Wie betrachtet ihr dieses Thema?

Joshua:
Dazu gibt es ein generelles IT-Konzept, das wir alle schon lange kennen: Least Privilege.

Dein Beispiel ist sehr gut, weil der Prozess trotz Automatisierung klar definiert ist. Du willst eine Podcast-Folge transkribieren, daraus eine Beschreibung erstellen und vielleicht ein Thumbnail vorbereiten.

Dann kann man sich ansehen: Was ist der Input? Sind kritische Informationen dabei? Was passiert während des Processings? Welche Rechte braucht die Anwendung wirklich?

Die zentrale Frage lautet: Wie gebe ich meinem System nur die Rechte, die es tatsächlich braucht, um genau diese Aufgabe zu erfüllen?

Schon das Aufschreiben dieses Prozesses hilft. Man erkennt relativ schnell, wo Schwachstellen liegen könnten. Dabei können Checklisten und das Whitepaper unterstützen.

Und wenn man nicht weiß, wie man es besser machen kann, sollte man fragen. Das schadet nie.

 

Whitepaper: Die fünf häufigsten KI-Security-Risiken

Andreas:
Genau das ist der Punkt.

Ladet euch das Whitepaper herunter, stellt euch die Fragen und wenn ihr weitere Fragen habt, schreibt Christian oder Joshua. Kommt mit den beiden in Kontakt. Das ist keine Einbahnstraße.

Und jetzt kommen wir zur guten alten Tradition dieses Podcasts.

Joshua, du hast gleich die letzten Worte. Du kannst sagen, was du möchtest. Du darfst nur nicht sagen: Vielen Dank für die Einladung.

Christian, du bekommst vorher die vorletzten Worte. Wir sehen uns demnächst wieder, und ich freue mich, dass ihr beide da wart.

Joshua, Kompliment: Du hast das Thema so erklärt, dass selbst ich es verstanden habe. Zwei, drei Fremdwörter muss ich noch nachschlagen, aber das bekommen wir hin.

Christian, deine vorletzten Worte.

 

Fazit: Sicherheit als Enabler

Christian:
Ich freue mich schon auf das nächste Mal, Andreas. Dann wieder mit einem spannenden Thema. Wir setzen uns noch zusammen und schauen, was wir mitbringen.

Und jetzt bin ich gespannt, was Joshua uns zum Abschluss erzählt.

Joshua:
Ich freue mich, dass ich hier über Datensicherheit im Zusammenhang mit GenAI-Use-Cases sprechen konnte.

Wir leben in einer sehr spannenden Zeit. Bei vielen Unternehmen liegen enorme Chancen auf dem Tisch, mit ihren Daten etwas Sinnvolles und Wertschöpfendes zu tun.

Ich hoffe, dass wir das auch hier in Deutschland schaffen. Deutschland nutzt KI-APIs und KI-Technologien bereits intensiv. Wir haben vielleicht noch nicht unser großes eigenes Flagship-Modell, aber das heißt nicht, dass wir nicht handlungsfähig sind.

Ich möchte Menschen ermutigen, das Thema anzugehen.

Ich hoffe außerdem, dass Security heute Interesse geweckt hat und nicht abschreckt. Denn es gibt Lösungen. Es lohnt sich, Sicherheit mitzudenken. Man kann diese Use Cases trotzdem umsetzen.

Und man wird später dankbar sein, dass man einmal mehr über Sicherheit nachgedacht hat.

Mehr zum Thema AI-Data Security finden Sie in unserem Whitepaper