In meinen Kundenprojekten nimmt die KI immer mehr Raum ein – auch im SAP Umfeld. Dabei zeigt sich, dass alle Parteien (inkl. SAP selber) noch am Lernen sind – insbesondere was sicherheitsrelevante und regulatorische Aspekte angeht (die Technik eilt da eher voraus).

Ein Kollege hat in einer Übersicht die Use Cases in Pattern/Muster geclustert und unterscheidet:

• Knowledge-Based Use Cases – Dem Anwender wird gezielt mittels KI Wissen angeboten und aufbereitet, z.B. aus der SAP Hilfe, Prozessdokumentationen, etc.
• Navigational Use Cases – Dem Anwender wird geholfen Funktionalitäten und Menüpunkte zu finden ohne dass die AI aktiv in die Geschäftsprozesse eingreift. Das geht schon stark in die Richtung KI als User Interface.
• Analytical Use Cases – KI gestützt werden Informationen aufbereitet und ausgegeben. Auch wenn die KI nicht direkt in die Geschäftsprozesse eingreift, kann dies außerhalb des Systems in Entscheidungen zum Tragen kommen. Eine Bewertung kann daher nur fallweise erfolgen.
• Transactional Use Cases – Die KI führt aktiv Transaktionen durch. Theoretisch könnte die KI damit auch gravierende Entscheidungen treffen. Dass ein Bot Menschen entlässt oder einstellt, halte ich allerdings eher für eine theoretische Variante. Viel mehr kommt hier das Thema Automatisierung zum Tragen: Wie ein Mensch kann die KI Käufe/Verkäufe/Zahlungen/etc. veranlassen, dummerweise halt nicht nur eine einzelne, sondern unzählige, bis der Vorgang überhaupt erst transparent wird und ggf. jemand eingreifen könnte. Eigentlich ist das Automatisierungsrisiko auch keine KI-Thematik, sondern ein Effizienz-Thema und die KI ist uns in Sachen Effizienz bei der Massenverarbeitung hoffnungslos überlegen.

Die ersten beiden Use Cases sind hingegen vergleichsweise trivial: Ihre Inhalte sind weitgehend öffentlich oder maximal für einen internen Gebrauch bestimmt und es gibt keine direkten Konsequenzen, die zu verfolgen wären.

Auf der Lösungsseite sind mir im SAP Umfeld bislang 3 technologische Ansätze untergekommen:

• SAP Joule – die SAP eigene KI, wobei man etwas aufpassen muss, weil SAP den Namen Joule marketingtechnisch etwas inflationär benutzt und schnell alles, was mit KI zu tun hat, auch mal als Joule betitelt
• Specific Capabilities – Während Joule weitgehend produktübergreifend konzipiert ist, entwickelt SAP auch spezifische KI-Lösungen für Ihre Produkte, z.B. für SAP Signavio oder andere. Dabei wird mitunter, wie auch bei Joule, die Business AI Foundation genutzt, sprich auch für spezifischere Anwendungsfälle kommen die gleichen LLMs zum Einsatz, die dann auch spezifische Modelle und Lösungen unterstützen.
• Individual AI Solutions – Mit SAP BTP hat die SAP entwicklungsseitig Tür und Tor geöffnet und findige Entwickler können im eigenen Programmcode natürlich auch beliebige KI Lösungen ansprechen. Der Tragweite kann durchaus immens sein und der SW-Entwicklung kommt plötzlich auch die Verantwortung für Auswahl, Konfiguration und Nutzung der KI-Modells zu. In diese Kategorie würden auch KI-Lösungen von 3rd-Party Anbietern fallen, auch wenn mir solche bislang noch nicht untergekommen sind, was aber sicher nur eine Frage der Zeit ist.

Unabhängig von der KI-Thematik gilt es zu berücksichtigen, dass Daten mitunter über Schnittstellen bis hin zu 3rd Parties, wie z.B. einem LLM-Anbieter gegeben werden. Wie weit dies in Abhängigkeit von der Kritikalität der Daten sinnvoll oder sogar zulässig ist, ist zu berücksichtigen.

Wie verteilen sich nun die Use Cases auf die Lösungsszenarien? Hier meine Interpretation (es mag Ausnahmen geben, aber die Tendenz scheint naheliegend):

SAP Joule dürfte die Knowledge-Based und Navigational Use Cases weitestgehend abdecken. Bei Analytical Use Cases bin ich mir noch nicht sicher , wie weit hier SAP Joule zum Einsatz kommen wird, auch wenn generisch die Ansätze vorhanden sein werden. Im analytischen und auch im transaktionalen Bereich werden aber produktspezifische Capabilities wie sie auch bei der SAP auf der Roadmap stehen eine gewichtige Rolle spielen. Individuelle Lösungen können als „Schweizer Taschenmesser“ oder für noch spezifischere Anwendungsfälle fungieren. Die Hemdsärmligkeit, wie wir sie auch aus der Entwicklung von KI-Tools in anderen Bereichen kennen steht hier im Widerspruch zu den gestiegenen Anforderungen und der Verantwortung bei Entwicklung und Einsatz.

Das bringt uns noch zu einem weiteren Aspekt: den Compliance-Anforderungen, z.B. aus dem EU AI Act (eine Zusammenfassung gibt es übrigens auch im schlossBlog) und unternehmenseigenen Anforderungen, z.B. aus dem Risikomanagement.

Jetzt stehen das Enterprise Risk Management und der EU AI Act zwar nicht im Widerspruch, aber die EU-Bürokraten haben bei ihrer Arbeit leider übersehen, dass der Risiko-Begriff längst auch anderweitig besetzt war und ist. Ihr Fokus auf Menschenrechte und hoheitliche Themen ist Ausdruck des Elfenbeinturms in dem sie sich bewegen. Nicht dass die Anforderungen per se falsch wären, aber es gibt eben auch noch andere Anforderungen und ich persönlich halte es nicht für zielführend für jede Technologie eigene Regelwerke zu erlassen, anstatt allgemeine Regelwerke auf ihre Tauglichkeit hin für neue Technologien zu prüfen, das hat schon zur EU-Leuchtmittelverordnung und zu EU-Staubsaugerverodnung geführt.

Auch wenn Unternehmensrisiken durchaus die Themen des AI Act aufgreifen sollten, ist der Schwerpunkt der Betrachtung doch ein anderer. Ich sehe hier vor allem zwei Themenfelder:

(1) KI-gestützte Entscheidungen (und nicht nur Personalentscheidungen wie im AI Act, sondern grundsätzlich auch die strategische Entscheidungsfindung, die im worst case existenzbedrohend für ein Unternehmen werden kann.)

(2) Das Automatisierungsdilemma. Die KI kann, wie wir Menschen, Fehler machen, nur kann sie diese auch exponentiell machen. Ich habe ja auch an anderer Stelle schon darauf hingewiesen, dass wir vielleicht eine eigene Fehlerkultur für die KI entwickeln müssen.

Spannend wird es, wenn wir nun die Enden dieses Beitrags zusammenführen:

Die meisten SAP Joule Anwendungsfälle (weil Knowledge-based und Navigational) sind aus Risikosicht (sowohl des AI Acts als auch des Enterprise Risk Managements) trivial. Die Tücke liegt aber im Detail und analytische und transaktionale Anwendungsfälle benötigen dann doch eine genauere Betrachtung. In einer Diskussion mit Vertretern der SAP habe ich den Kollegen die Frage gestellt, ob SAP Joule maximal low-risk Use Cases im Sinne des AI Acts abdeckt und high-risk Use Cases out of scope sind. Soweit wollte allerdings niemand gehen, auch wenn sich alle Fälle die wir aktuell diskutieren in diesem Bereich bewegen. Die Fragen, wie die Anforderungen für high-risk Use Cases (im Sinnes des AI Acts) seitens SAP abgedeckt werden, wurden aber eher mit einem Commitment als mit konkreten Aussagen beantwortet.

Bei den Specific Capabilities liegt eine fallweise Betrachtung auf der Hand. Zur Herausforderung könnten aber insbesondere Individual AI solutions werden. Anforderungen, wie Logging Capabilities, technische Dokumentation und Robustheit, wie sie der AI Act für high-risk Use Cases fordert machen auch aus Unternehmenssicht darüber hinaus Sinn, wenn man an das Thema Automatisierung denkt. Die Verantwortung der Entwickler steigt hier, mitunter ohne dass sie sich dessen bewusst sind.

Der AI Act der Europäischen Union ist der Inbegriff europäischer Bürokratie. Er steht in der glorreichen Tradition der Staubsauger-Verordnung und der Leuchtmittel-Verordnung. Also nicht dass der Inhalt der Verordnung Blödsinn wäre, nein, da haben sich Experten wirklich Mühe gegeben und viel Gehirnschmalz reingesteckt.

„Sie waren stets bemüht…“

Aber dahinter steckt ein grundlegend falsches Verständnis:

Statt bestehende Regelungen zu prüfen und auf neue technologische Herausforderungen, wie die künstliche Intelligenz, anzupassen, werden neue Regelungen und neue Bürokratie geschaffen. Im aktuellen AI Hype geht es noch unter, aber der AI Act wird uns noch einholen, wie damals die DSGVO.

Meine erste Annäherung

Windholz, Natascha, et al. Praxishandbuch KI-VO: Künstliche Intelligenz rechtskonform im privaten und öffentlichen Bereich einsetzen, München 2024

Leider keine Empfehlung. Extreme Detailtiefe, aber den Blick auf das Wesentliche habe ich nicht gefunden. Sicher alles da, aber ist nicht bei mir angekommen. Obwohl ich mich durchgekämpft habe.

Zweiter Versuch beim Kunden: Deutscher Tech-Konzern hat eine interne Guideline zum Einsatz von AI

Wieder viel Gutes und Richtiges. 80+ Empfehlungen mit Referenzen auf Cybersecurity Policies, aber die Umsetzung stellt noch nicht einmal die Compliance zum AI Act sicher. (Soviel ist dann doch beim Praxishandbuch hängengeblieben.)

Dritter Versuch: Diskussion mit der AI Governance in einem Konzern

Auch wieder etwas Deutsches: Wir brauchen neue Polices und eine Governance für das Thema AI.

Den Fehler des EU AI Act auf Unternehmensebene nachziehen und fortschreiben.
Auch hier wieder vieles Gutes und Richtiges. Aber irgendwie ein Greenfield Approach. Für neue AI Anwendungen. Die gibt es zwar sicher, aber durch die Hintertür, durch die Einbindung von AI-basierten Webservices, wird plötzlich alles zu einer AI-Applikation. Viele Fragen, gute Fragen – aber auf der falschen Ebene. Ein Deep Dive in die genutzten LLM-Modelle, die aber in den meisten Anwendungsszenarien durch SaaS-Lösungen vorgegeben sind und morgen möglicherweise schon wieder durch neue Modelle ausgetauscht werden. Fragen die kein normaler Applikations-Verantwortlich beantworten kann, sondern die einen Cybersecurity-AI -Architekten erfordern. Es fehlt die Sensibilisierung für das Wesentliche:

• Wenn wir AI-Webservices einbinden, geben wir Daten nach draußen – das hat noch nicht einmal mit AI zu tun.
• Und wenn wir die Daten nach draußen geben, dann ist die Frage, ob nur zur Verarbeitung oder ob die Modelle, die womöglich auch von anderen genutzt werden, daraus lernen. In Nischenbereichen kann dann auch schnell die direkte Konkurrenz von uns lernen.
• Ja, es gibt da noch typische AI Risiken, wie Halluzinationen und Biases über die wir die Anwender zumindest aufklären müssen.

Selbsthilfe

Ok, noch einmal zurück auf Start. Warum nicht ChatGPT fragen nach dem AI Act?
Nein ganz so einfach habe ich es mir dann doch nicht gemacht. ChatGPT war nur der Startschuss und dann habe ich aus den gewonnen Erkenntnissen (siehe oben) nachgearbeitet. Ich bin auch kein Jurist – entsprechend unverbindlich sind meine eigenen 5 Cent, auch wenn ich sie hier teile.

Zentral im AI Act ist eine Risikoklassifizierung.

Typisch für die europäische Bürokratie eine neue Risikobetrachtung einzuführen, als gäbe es nicht längst Risikomanagement in Unternehmen. Eine Betrachtung auf Applikationsebene kann schnell überfordern, aber auf Ebene von Use Cases lässt sich die Klassifizierung nach AI Act beantworten und dann bedarf es eben einer Aggregation: der Worst Case greift auf Applikationsebene.

Der AI Act unterscheidet die folgenden Risikokategorien:

Verbotene Anwendungen brauchen keine weitere Betrachtung.

Interessant wird es bei den Hochrisiko-Anwendungsfällen. Was fordert der AI Act hier?

Nun, wieder ChatGPT:

Auch hier gibt es Überschneidungen mit generellen Cybersecurity-Anforderungen, aber immerhin ein komprimierter Ansatz.

Bei „limited risks“ verbleibt nach dieser Logik nur mehr Transparency and Information.

Und bei „minimal risk“, naja, das können wir vernachlässigen.

Was ich trotzdem mitgenommen habe:

• Natürlich müssen wir uns mit der Kritikalität der Daten – Input wie Output beschäftigen (auch wenn das eigentlich gar keine AI-Frage ist).
• Werden die verarbeiteten Daten als Trainingsmaterial verwendet? Dann könnten ja auch andere Nutzer des LLM darauf zurückgreifen.
• Sind wir „nur“ Nutzer oder Betreiber eines Modells? Bei der aktuellen Dynamik werden die Modelle schneller ausgetauscht als wir schauen können. Sind wir selbst Betreiber kommt eine besondere Verantwortung hinzu,

Aus regulatorischer Sicht halte ich das Thema AI weitgehend für überbewertet. Grundsätzliche Anforderungen und Weisheiten, wie Garbage in – Garbage out, gelten weiter. Wirklich neu sind Halluzinationen und Biases. Für die war früher noch der Mensch zuständig…

Aber schauen wir mal, wo die Reise hingeht.