SAPPHIRE 2026 — Drei Lesarten einer Keynote
Was die Ankündigungen aus Orlando wirklich bedeuten — und warum die spannendsten Fragen nicht auf der Bühne beantwortet wurden.
Einleitung: Eine Keynote ist kein Whitepaper
Eine SAPPHIRE-Keynote folgt einer eigenen Dramaturgie. Es geht nicht um vollständige Information, sondern um Inszenierung. Christian Klein steht auf der Bühne, hinter ihm ein Display in der Größe eines mittleren Industriegebäudes, und in 90 Minuten werden Botschaften gesetzt, die das nächste Jahr prägen sollen. Wer eine solche Keynote wie eine Produktdokumentation liest, missversteht das Genre.
Die Keynote 2026 in Orlando war in dieser Hinsicht ein Meisterstück. Drei große Botschaften wurden gesetzt: das „Autonomous Enterprise“ als Vision, der Agent-to-Agent-Pakt mit Microsoft als strategische Allianz, und „Sovereign AI by Design“ als Antwort auf die europäische Souveränitätsdebatte. Jede dieser Botschaften wurde mit Konfidenz vorgetragen, mit Kundenreferenzen unterfüttert und mit Roadmap-Folien plausibilisiert.
Und doch: Die wirklich interessanten Fragen wurden nicht beantwortet. Nicht, weil SAP sie verbergen wollte, sondern weil eine Keynote sie strukturell nicht beantworten kann. Eine Keynote setzt Narrative. Sie löst keine Architekturfragen. Sie löst keine Governance-Fragen. Sie löst keine ökonomischen Fragen.
Genau diese Fragen müssen aber in den nächsten Wochen in den Vorstandssitzungen, IT-Steering-Komitees und Strategie-Workshops gestellt werden. Wer das delegiert oder verschiebt, wird in zwölf Monaten von Realitäten eingeholt, die heute noch wie Marketing-Folien aussehen.
Dieser Artikel bietet drei Lesarten der Keynote — drei analytische Schnitte durch dasselbe Material. Jede Lesart beleuchtet einen anderen Aspekt, jede stellt andere Fragen, und alle drei zusammen ergeben ein Bild, das deutlich präziser ist als die Summe der Marketingbotschaften.
Erste Lesart — Reifegrad: Was ist heute real?
Beginnen wir mit der vordergründigsten Frage: Was funktioniert von dem, was angekündigt wurde, heute? Was ist Pilot, was ist Vision, was ist reine Folienprosa?
Wer SAP-Keynotes über mehrere Jahre verfolgt hat, kennt das Muster. Auf der Bühne werden Lösungen demonstriert, die in einer kontrollierten Demo-Umgebung beeindruckend funktionieren. Zwölf Monate später erscheint die General Availability. Weitere zwölf Monate später sind die ersten Kundenreferenzen produktiv. Und nochmals zwölf Monate später ist das Feature in der Breite einsatzfähig.
Diese Zeitspanne ist kein Vorwurf an SAP. Sie ist die Realität von Enterprise-Software. Aber sie hat Konsequenzen für die Frage, wie ein CIO oder CDO heute auf die Ankündigungen reagieren sollte.
Ich nutze für solche Bewertungen eine einfache Heuristik, die ich die 20/30/50-Regel nenne. In jeder großen Plattform-Keynote sind etwa 20 Prozent der angekündigten Funktionen heute tatsächlich produktiv einsetzbar — mit Referenzkunden, dokumentierten Ergebnissen, kalkulierbarem Aufwand. Weitere 30 Prozent sind in fortgeschrittener Pilotphase, oft mit ausgewählten Kunden in begrenztem Umfang. Und die verbleibenden 50 Prozent sind strategische Vision: Es gibt eine Roadmap, es gibt eine Architektur-Idee, es gibt vielleicht erste Prototypen — aber es gibt noch keinen Pfad zum produktiven Einsatz in den nächsten zwölf bis achtzehn Monaten.
Übertragen auf die Orlando-Keynote: Die „Joule-Agenten für die Beschaffung“ — Lieferantenanfragen automatisiert generieren, Angebote vergleichen, Vertragsabweichungen flaggen — gehören tendenziell in die ersten 20 Prozent. Diese Funktionalität existiert, sie ist getestet, und sie liefert in klar umrissenen Use Cases messbaren Mehrwert. Die angekündigten „autonomen Produktionsagenten“, die Schichtpläne, Maschinenbelegung und Materialdisposition koordinieren, gehören eher in die 30-Prozent-Pilotzone. Erste Kunden testen, aber von einer reifen, skalierbaren Lösung sind wir weit entfernt. Und das „Autonomous Enterprise“ als Gesamtbild — selbststeuernde Wertschöpfungsketten, die strategische Entscheidungen unter menschlicher Aufsicht autonom umsetzen — das ist die 50-Prozent-Vision. Richtige Richtung, aber kein operatives Programm für 2026.
Die strategische Konsequenz für CIOs und CDOs ist nicht, die Vision zu ignorieren. Sie ist, die Vision von der Realität zu trennen. Wer heute Budget allokiert, sollte die ersten 20 Prozent priorisieren: dort, wo die Technologie reif ist, der Use Case klar definierbar und der Business Case rechenbar. Die 30 Prozent verdienen Pilotbudgets — kontrolliert, mit klaren Abbruchkriterien. Die 50 Prozent gehören in die Strategie-Roadmap, aber nicht in den Investitionsplan.
Eine zweite Beobachtung ist wichtig. Reife ist nicht gleich Reife. Ein Joule-Agent, der in einem Tier-1-Konzern mit ausgereifter Datenbasis und dediziertem AI-Team funktioniert, ist nicht automatisch ein Joule-Agent, der im gehobenen Mittelstand funktioniert. Die Demo-Umgebungen, die in Orlando gezeigt wurden, basieren auf bereinigten Stammdaten, sauberen Prozessen und kuratierten Beispielszenarien. In der Realität der meisten Industrieunternehmen sieht die Datenbasis anders aus. Stücklisten sind unvollständig, Lieferantenstammdaten sind heterogen, Vertragsdokumente liegen als gescannte PDFs in Sharepoint-Ordnern. Auf dieser Basis arbeitet kein AI-Agent zuverlässig.
Das ist nicht das Problem von SAP. Es ist das Problem der Anwenderunternehmen. Aber es bestimmt, welcher Reifegrad in der eigenen Organisation überhaupt erreichbar ist. Die ehrliche Frage lautet daher nicht: Was kann Joule? Sondern: Was kann Joule mit unseren Daten und in unseren Prozessen?
Diese Frage lässt sich nur durch eine strukturierte Bewertungsmatrix beantworten. In meiner Beratungspraxis arbeite ich mit drei Dimensionen: Datenreife (sind die Stammdaten in einem Zustand, der AI-Anwendung erlaubt?), Prozessreife (sind die Geschäftsprozesse so dokumentiert und stabil, dass ein Agent darauf operieren kann?) und Governance-Reife (gibt es klare Regeln, was ein Agent darf, wer ihn überwacht, wer haftet?). Erst wenn alle drei Dimensionen mindestens auf Stufe drei von fünf sind, lohnt sich ein produktiver Einsatz. Darunter ist jeder Pilot ein teures Lernprojekt — was legitim sein kann, aber als solches behandelt werden muss.
Die erste Lesart der Keynote endet mit einer nüchternen Empfehlung: Lass dich von der Vision nicht davon abhalten, die Reife zu prüfen. Aber lass dich von der aktuellen Reife auch nicht davon abhalten, die Vision ernst zu nehmen.
Zweite Lesart — Architektur: Wer kontrolliert die Schicht?
Die zweite Lesart führt tiefer. Sie verschiebt den Blick von den einzelnen Funktionen auf die Architektur — und auf die strategische Frage, wer in den nächsten Jahren die Intelligenz-Schicht der Unternehmensanwendungen kontrolliert.
Die wichtigste Ankündigung der Keynote war in dieser Hinsicht nicht „Autonomous Enterprise“. Es war ein Satz, der in den meisten Zusammenfassungen unterging: Joule spricht jetzt nativ mit Microsoft 365 Copilot. Agent-to-Agent-Interoperabilität. Klingt nach Feature, ist aber ein strategischer Erdrutsch.
Um die Tragweite zu verstehen, muss man die Vorgeschichte kennen. Zwei Jahre lang hat SAP versucht, Joule als den Ort zu positionieren, an dem Wissensarbeiter ihren Tag verbringen. Joule sollte das Interface werden, durch das Einkäufer ihre Lieferanten anfragen, Disponenten ihre Bestände prüfen, Controller ihre Reports ziehen. Diese Strategie hatte eine klare Logik: Wer das Interface kontrolliert, kontrolliert die Wertschöpfung. Microsoft kennt diese Logik seit Jahrzehnten — sie ist der Grund, warum Office trotz aller Alternativen weiter den Markt dominiert.
Aber Microsoft hat in der Zwischenzeit Copilot ausgerollt. Auf 400 Millionen Microsoft-365-Nutzer. Mit nativer Integration in Outlook, Teams, Word, Excel. Wer einmal verstanden hat, wie Copilot eine Tabelle analysiert oder eine E-Mail-Antwort vorschlägt, wird nicht mehr in eine separate Anwendung wechseln, um eine ähnliche Aufgabe zu erledigen. Die Schlacht um den AI-Workspace ist entschieden, und SAP hat sie nicht gewonnen.
Die Entscheidung, Joule mit Copilot interoperabel zu machen, ist daher keine Kooperation unter Gleichen. Sie ist die nüchterne Anerkennung einer veränderten Machtlage. SAP gibt das Interface auf — und versucht stattdessen, das System of Record zu bleiben. Der Anwender arbeitet in Outlook und Teams, aber die Prozesse, die er auslöst, laufen in S/4HANA. Die Intelligenz, die Joule beisteuert, wird zur Service-Schicht zwischen Microsoft-Workspace und SAP-Backbone.
Architektonisch ist das die richtige Antwort. Ökonomisch wird es interessant.
Drei Konsequenzen verdienen Aufmerksamkeit auf Vorstandsebene.
Die erste Konsequenz betrifft die Lizenzökonomie. Wer Microsoft 365 Copilot lizenziert und parallel Joule-Konsumption über SAP bezieht, zahlt zweimal für die Intelligenz-Schicht. Einmal an Microsoft pro Nutzer und Monat, einmal an SAP nach Verbrauchsmodell. Die Frage ist nicht, ob sich das addiert — die Frage ist, wie hoch der Aufschlag in drei Jahren sein wird. Bei einem mittelständischen Industrieunternehmen mit 2.000 Wissensarbeitern und intensivem SAP-Einsatz reden wir über zusätzliche siebenstellige Jahresbudgets, die in keinem heutigen IT-Plan kalkuliert sind.
Die zweite Konsequenz betrifft die Governance. Wenn ein Copilot-Agent über die A2A-Schnittstelle einen Joule-Agent triggert, der eine Bestellung in S/4HANA auslöst — wer ist verantwortlich, wenn diese Bestellung nicht hätte ausgelöst werden dürfen? Die Microsoft-Compliance-Regeln, die definieren, was Copilot tun darf, sind nicht identisch mit den SAP-Berechtigungskonzepten, die definieren, welche Transaktionen ein Anwender ausführen darf. An der Schnittstelle entsteht ein Governance-Vakuum, das heute in den meisten Organisationen nicht adressiert ist. Wer für SOX-Compliance verantwortlich ist, sollte spätestens jetzt mit der internen Revision sprechen.
Die dritte Konsequenz betrifft den Lock-in. Lock-in auf einer Plattform ist eine bekannte Größe — die meisten Organisationen haben gelernt, ihn zu managen. Lock-in auf der Verbindung zwischen zwei Plattformen ist eine neue Kategorie. Wenn Geschäftsprozesse darauf basieren, dass Copilot und Joule miteinander kommunizieren, dann sind Organisationen nicht mehr von einem Anbieter abhängig, sondern von einer spezifischen Anbieter-Kombination. Eine Migration weg von Microsoft betrifft dann nicht nur den Workspace, sondern auch die SAP-Integration. Eine Migration weg von SAP betrifft nicht nur das ERP, sondern auch die Microsoft-Integration. Die Exit-Kosten verdoppeln sich, ohne dass das in heutigen TCO-Modellen abgebildet wird.
Architektonisch lässt sich das in einem Drei-Schichten-Modell denken. Die unterste Schicht ist das System of Record: SAP, das die Stammdaten, Transaktionen und Geschäftsprozesse hält. Die mittlere Schicht ist die Intelligenz: Joule auf SAP-Seite, Copilot auf Microsoft-Seite, mit der A2A-Brücke dazwischen. Die obere Schicht ist das Interface: dort, wo der Anwender tatsächlich arbeitet, also primär Microsoft-Umgebung. Die strategische Frage ist, wer in den nächsten Jahren die mittlere Schicht definiert. Wer die Routing-Logik kontrolliert, welcher Agent welche Aufgabe übernimmt, hat die Wertschöpfung in der Hand. Heute ist diese Frage offen. In drei Jahren wird sie entschieden sein — und wer sie nicht stellt, wird mit der Antwort leben müssen, ohne sie beeinflusst zu haben.
Die zweite Lesart endet mit einer Frage, die in keiner IT-Strategie der nächsten zwölf Monate fehlen darf: Welche Architektur-Entscheidungen treffen wir bewusst, und welche treffen die Anbieter für uns?
Dritte Lesart — Souveränität: Was steht wirklich im Maschinenraum?
Die dritte Lesart adressiert den Begriff, der in Orlando geboren wurde und mich seither nicht loslässt: „Sovereign AI by Design“.
Klingt gut. Klingt europäisch. Klingt nach Antwort auf eine berechtigte Sorge. Schauen wir genauer hin.
Was bedeutet „Sovereign AI by Design“ konkret? SAP verspricht: AI-Funktionen, die in souveränen Cloud-Umgebungen laufen. Datenresidenz in der EU. Konformität mit dem AI Act. Auf den Folien sieht das nach digitaler Selbstbestimmung aus. In der Realität sind drei Fragen relevant, die auf den Folien nicht beantwortet werden.
Die erste Frage betrifft die Foundation Models. Welche Modelle stehen im Maschinenraum von Joule? Die Antwort ist heute nicht vollständig transparent, aber die wesentlichen Komponenten sind bekannt: GPT-4 von OpenAI und Claude von Anthropic. Beides US-Unternehmen, beide unter US-Jurisdiktion, beide grundsätzlich dem CLOUD Act unterworfen. Ein Modell, das auf europäischen Servern läuft, ist nicht souverän, wenn die Modellgewichte, das Training und die Roadmap in San Francisco entschieden werden. Die Daten mögen die EU nicht verlassen — aber die Intelligenz, die auf den Daten operiert, ist US-amerikanisch.
Die zweite Frage betrifft die Infrastruktur. SAP betreibt seine Cloud nicht in eigenen Rechenzentren — die SAP-Cloud läuft auf AWS, Microsoft Azure und Google Cloud. Drei US-Hyperscaler. „Souverän“ wird das durch vertragliche Konstrukte: Datenresidenz-Garantien, Verschlüsselungsschlüssel unter Kundenkontrolle, juristisch definierte Zugriffsbeschränkungen. Diese Konstrukte sind nicht wertlos — aber sie sind vertraglich, nicht technisch. Im Ernstfall — und Ernstfälle definieren sich durch geopolitische Spannungen, die heute nicht absehbar sind — entscheidet die Jurisdiktion über das Vertragsrecht, nicht umgekehrt.
Die dritte Frage betrifft die Agenten-Logik. Joule entscheidet, welcher Prompt an welches Modell geht. Diese Routing-Logik ist proprietär. Der Kunde sieht das Ergebnis, aber nicht den Entscheidungsweg. Welches Modell hat eine Frage beantwortet? Welche Daten wurden in den Kontext geladen? Welche Sicherheitsfilter wurden angewendet? Diese Fragen sind heute nicht auditierbar — und das ist nicht ein temporärer Zustand, der sich durch Reife erledigt, sondern eine bewusste architektonische Entscheidung. SAP wird die Routing-Logik nicht offenlegen, weil sie zum Kern des Wertversprechens gehört.
Damit wir uns nicht missverstehen: Das ist kein Vorwurf an SAP. SAP macht das ökonomisch Richtige. Eigene Foundation Models zu trainieren, kostet zweistellige Milliardenbeträge und produziert Modelle, die hinter dem Stand der Technik zurückbleiben. Die Partnerschaft mit OpenAI und Anthropic ist die rationale Entscheidung — sie liefert dem Kunden Zugang zur besten verfügbaren Technologie ohne das Investitionsrisiko. Wäre ich Vorstand bei SAP, würde ich dieselbe Entscheidung treffen.
Aber: „Sovereign AI by Design“ ist Marketing, nicht Architektur. Echte Souveränität wäre etwas anderes. Sie wäre Foundation Models unter europäischer Kontrolle — was heute Mistral, perspektivisch vielleicht Aleph Alpha oder ein staatlich getragenes Konsortium bedeuten würde. Sie wäre Infrastruktur unter europäischer Jurisdiktion — nicht nur Datenresidenz, sondern Eigentum und Kontrolle der Rechenzentren. Sie wäre transparente, auditierbare Agenten-Logik — mit der Möglichkeit für Kunden und Aufsichtsbehörden, nachzuvollziehen, wie Entscheidungen zustande kommen.
Von all dem sind wir weit entfernt. Und das wird sich in den nächsten drei Jahren auch nicht ändern. Mistral ist technologisch beeindruckend, aber im Vergleich zu OpenAI und Anthropic eine Zwerg-Organisation. Aleph Alpha hat sich aus dem Foundation-Model-Geschäft weitgehend zurückgezogen. Ein staatlich getragenes europäisches AI-Konsortium existiert in Sonntagsreden, aber nicht in Industriepolitik. Wer auf europäische Souveränität wartet, wartet vergeblich.
Was heißt das für CIOs und CDOs? Es heißt nicht, dass Souveränität irrelevant ist — im Gegenteil. Es heißt, dass Souveränität nicht als Checkbox behandelt werden darf. Die ehrliche Auseinandersetzung verlangt drei Entscheidungen, die jede Organisation für sich treffen muss.
Die erste Entscheidung ist eine Daten-Klassifikation. Welche Daten dürfen unter keinen Umständen in ein US-Modell? Konstruktionsdaten? Verhandlungsstrategien mit chinesischen Lieferanten? Personalakten von Mitarbeitern in regulierten Funktionen? Diese Klassifikation muss schriftlich erfolgen, sie muss vom Vorstand getragen sein, und sie muss in technischen Kontrollen umgesetzt werden — nicht in Schulungen.
Die zweite Entscheidung ist eine Prozess-Zuordnung. Welche Geschäftsprozesse können bewusst dem US-Stack zugeordnet werden, weil das Risiko überschaubar ist? Marketing-Texterstellung, Code-Generierung, Übersetzungen, allgemeine Recherche — hier ist die Sensitivität gering und der Produktivitätsgewinn hoch. Diese pragmatische Trennung zwischen „kann US-Stack“ und „darf nicht US-Stack“ ist die operative Antwort auf eine strategische Frage, die idealerweise nie eindeutig beantwortbar sein wird.
Die dritte Entscheidung ist eine Exit-Architektur. Welche Komponenten müssen so gebaut sein, dass sie in zwölf Monaten gegen europäische Alternativen ausgetauscht werden können, falls die geopolitische Lage es erfordert? Diese Frage zwingt zur Modularität — und Modularität ist teurer als monolithische Integration. Aber sie ist die einzige technische Antwort auf eine strategische Unsicherheit, die sich nicht auflösen lässt.
Die dritte Lesart endet damit nicht mit Resignation, sondern mit einer präzisen Forderung. Souveränität ist kein Marketing-Begriff. Souveränität ist eine Architektur-Disziplin. Und sie gehört auf die Vorstandsagenda — nicht in das IT-Steering.
Synthese — Die eine Frage, die zählt
Wer die drei Lesarten zusammendenkt, erkennt ein Muster. Die Reifegrad-Frage führt zur Architektur-Frage, die Architektur-Frage führt zur Souveränitäts-Frage, und alle drei Fragen verbindet eine gemeinsame Bewegung: die Verschiebung der AI-Diskussion von der Feature-Ebene auf die Strategie-Ebene.
In den letzten drei Jahren wurde AI in den meisten Unternehmen als Feature-Thema behandelt. Welche Funktionen gibt es? Wie viele Use Cases können wir identifizieren? Wie hoch ist die Produktivitätssteigerung? Diese Fragen sind nicht falsch, aber sie sind unzureichend. Sie behandeln AI wie eine neue Software-Version — als etwas, das man einkauft, installiert und nutzt.
Die Orlando-Keynote macht deutlich, dass diese Sichtweise nicht mehr trägt. AI ist nicht mehr ein Feature. AI ist die Schicht, in der die Geschäftsprozesse der Zukunft definiert werden. Wer die Schicht kontrolliert, kontrolliert die Wertschöpfung. Wer sie nicht kontrolliert, wird kontrolliert.
Diese Verschiebung hat Konsequenzen für die Frage, wer in Unternehmen über AI entscheidet. Solange AI ein Feature war, war es ein IT-Thema. Der CIO hat Budget freigegeben, die IT-Abteilung hat Pilotprojekte aufgesetzt, einzelne Fachbereiche haben Use Cases identifiziert. Das funktioniert für Features. Es funktioniert nicht für eine Schicht, die in den nächsten fünf Jahren die operative Geschäftsarchitektur definiert.
Die Reifegrad-Frage ist eine Frage des Investitionsschwerpunkts — und gehört auf die Vorstandsagenda, nicht in das IT-Steering. Die Architektur-Frage ist eine Frage der Anbieter-Abhängigkeit und der Exit-Kosten — und gehört in den Aufsichtsrat, nicht in die Fachbereichsleitung. Die Souveränitäts-Frage ist eine Frage der geopolitischen Resilienz — und gehört auf Vorstandsebene, nicht in die Compliance-Abteilung.
Dass diese Verschiebung schwierig ist, weiß jeder, der ähnliche Bewegungen in den letzten zwanzig Jahren begleitet hat. Die Cloud-Migration war eine vergleichbare Verschiebung — von „neue Server“ zu „neue Geschäftsarchitektur“. Sie hat etwa zehn Jahre gebraucht, bis sie auf Vorstandsebene angekommen war. Bei AI haben wir diese Zeit nicht. Die strategischen Entscheidungen, die heute getroffen werden, definieren die Wettbewerbsposition für die nächsten fünf Jahre.
Das ist der Grund, warum ich seit zwei Jahren von „Adult Supervision“ spreche. Der Begriff ist absichtlich provokant. Er sagt: Diese Technologie ist zu wichtig, um sie ausschließlich Spezialisten zu überlassen, die in Tokens und Embeddings denken. Sie braucht erfahrene Menschen mit Prozesswissen, betriebswirtschaftlicher Erfahrung und strategischem Urteilsvermögen. Sie braucht Erwachsenenaufsicht — nicht im Sinne von Misstrauen gegenüber Technologen, sondern im Sinne von Verantwortung gegenüber der Organisation.
Die SAPPHIRE-Keynote 2026 hat das Spielfeld nicht verändert. Sie hat sichtbar gemacht, was sich bereits seit Monaten anbahnt. Die Frage ist nicht mehr, ob AI in die operative Wertschöpfung integriert wird. Die Frage ist, wer die Integration steuert — die Anbieter, die Berater oder die Unternehmen selbst.
Schluss: Drei Fragen für die nächste Vorstandssitzung
Wenn dieser Artikel einen Zweck hat, dann den, drei Fragen in Vorstandssitzungen zu bringen, die dort heute oft nicht gestellt werden.
Erstens: Welcher Reifegrad ist in unserer Organisation realistisch erreichbar — angesichts unserer Datenbasis, unserer Prozesse und unserer Governance-Strukturen? Die Antwort wird unangenehm sein, weil sie meist niedriger ausfällt als die Folien der Anbieter suggerieren. Aber sie ist die einzig belastbare Grundlage für Investitionsentscheidungen.
Zweitens: Welche Architektur-Entscheidungen treffen wir bewusst, und welche treffen die Anbieter für uns? Wenn die Antwort lautet, dass wir die Entscheidungen heute den Anbietern überlassen, ist das eine bewusste Entscheidung mit absehbaren Konsequenzen. Wenn die Antwort lautet, dass wir die Entscheidungen selbst treffen wollen, braucht das eine Architektur-Kompetenz, die in den meisten Organisationen heute nicht ausreichend aufgebaut ist.
Drittens: Wie operationalisieren wir Souveränität, ohne sie zur Floskel verkommen zu lassen? Eine Daten-Klassifikation, eine Prozess-Zuordnung, eine Exit-Architektur — das sind die Bausteine. Sie kosten Geld, sie kosten Zeit, und sie produzieren keine schnellen Erfolge. Aber sie produzieren strategische Handlungsfähigkeit.
Drei Lesarten einer Keynote. Drei Fragen für die nächste Vorstandssitzung. Eine Erkenntnis: AI in der Industrie ist keine IT-Aufgabe mehr. Sie ist eine Führungsaufgabe. Und sie verlangt erwachsene Aufsicht — nicht morgen, sondern heute.
E-Mail: sven.vollmer@business-quotient.com
Sven Vollmer ist „The Industrial Translator“. Er baut Brücken zwischen der operativen Realität der Industrie (SAP, Supply Chain) und den Möglichkeiten generativer KI. Sein Fokus liegt auf wertschöpfenden Anwendungen abseits des Hypes.
Transparenz-Hinweis: Dieser Artikel entstand mit redaktioneller Unterstützung von KI (Gemini/Claude). Die Ideen, fachliche Prüfung, die Auswahl der Use Cases und die Bewertung (‚Adult Supervision‘) oblagen zu 100% dem Autor.
LinkedIn: www.linkedin.com/in/sven-vollmer-bq
