Datenhoheit im KI-gestützten Service: Warum Maschinenbauer ihre Servicedaten nicht aus der Hand geben sollten

Maschinenbauer stehen vor einer zentralen Herausforderung: Wie können sie KI nutzen, um Diagnosen und Wartung effizienter zu gestalten, ohne dabei die Kontrolle über sensible Servicedaten zu verlieren? Daten wie Maschinenkonfigurationen, Wartungshistorien und Fehlerprotokolle sind nicht nur geschäftskritisch, sondern auch rechtlich sensibel. Der Einsatz externer Plattformen birgt Risiken wie den Zugriff durch Dritte (z. B. US-CLOUD-Act) oder Einschränkungen durch den EU-AI-Act, der ab August 2026 strenge Anforderungen an viele KI-Systeme stellt.

Die Lösung: Durch den Einsatz einer souveränen Architektur wie der Service Decision Intelligence (SDI) können Unternehmen KI-gestützte Entscheidungen treffen, ohne die Datenhoheit aufzugeben. SDI ermöglicht den Betrieb von KI auf eigener Infrastruktur, bietet Quellennachweise für Empfehlungen und vermeidet Risiken wie Vendor-Lock-in oder externe Datenreplikation. Dies sichert nicht nur die Compliance, sondern auch den Schutz des technischen Know-hows und der Kundenbeziehungen.

Das Risikofeld: Probleme mit externen KI-Cloud-Plattformen

Warum Servicedaten besonders sensibel sind

Servicedaten sind eine heikle Angelegenheit, da sie drei besonders schützenswerte Datenkategorien vereinen: personenbezogene Daten (wie die Kontaktdaten von Technikern und Ansprechpartnern), technisches Know-how des Herstellers (etwa Informationen zu Fehlermustern, Diagnosepfaden oder Toleranzgrenzen) und operative Betriebsdaten (zum Beispiel Maschinenkonfigurationen, Wartungsintervalle oder Ausfallhistorien). Diese Kombination macht Servicedaten nicht nur zu einem wertvollen Gut, sondern auch zu einem potenziellen Risiko, insbesondere wenn sie an externe Plattformen übertragen werden. Solche Daten gewähren Dritten Einblicke in das über Jahrzehnte gesammelte Wissen eines Unternehmens – ein erhebliches Risiko für den Wettbewerbsvorteil.

Rechtliche und Compliance-Risiken

Ein zentraler Aspekt ist die rechtliche Unsicherheit im Umgang mit externen Plattformen, insbesondere solchen, die in den USA ansässig sind. Der US-CLOUD-Act erlaubt es US-Behörden, auf Daten zuzugreifen, die von US-amerikanischen Anbietern verwaltet werden – unabhängig davon, ob die Server in Europa stehen. Für Maschinenbauer bedeutet dies, dass der Schutz sensibler Servicedaten bereits mit der Vertragsunterzeichnung ein Stück weit aus der Hand gegeben wird.

Zusätzlich erschwert das Schrems-II-Urteil den Datentransfer in die USA. Selbst das EU-US Data Privacy Framework bietet keine langfristige Sicherheit für sensible Industriedaten. Schutzmaßnahmen wie Standardvertragsklauseln oder Transfer Impact Assessments sind zwar möglich, aber in der Praxis oft kompliziert und aufwendig umzusetzen.

Der EU-AI-Act greift ab dem 2. August 2026 für viele Hochrisiko-KI-Systeme (die vollständige Anwendung für regulierte Produkte folgt 2027). Hochrisiko-KI-Systeme, die etwa sicherheitsrelevante Diagnosen oder Wartungsentscheidungen unterstützen, unterliegen dann strengen Vorgaben wie Auditierbarkeit, Quellennachweis und Risikobewertung (EU-Kommission, Digital Strategy). Externe KI-Anbieter, die auf Black-Box-APIs setzen, können diese Anforderungen meist nicht erfüllen, was für europäische Unternehmen zusätzliche Risiken schafft.

Geschäftsrisiken jenseits der Compliance

Abgesehen von rechtlichen Fragen bergen externe Plattformen auch strategische Risiken. Viele US-Plattformen arbeiten mit proprietären APIs und spezifischen Funktionssyntaxen. Einmal integriert, entsteht ein Vendor-Lock-in, der den Wechsel zu anderen Anbietern erschwert und mit steigenden Datenmengen die Kosten erhöht.

Ein weiteres Problem ist der Verlust an Transparenz. Wenn eine KI-Plattform Diagnosen oder Empfehlungen abgibt, ohne offenzulegen, auf welchen Datenquellen diese basieren, wird die Nutzung solcher Empfehlungen im Rahmen des EU-AI-Acts problematisch. Für Serviceleiter, die diese Entscheidungen gegenüber Kunden rechtfertigen müssen, entsteht ein erhebliches Haftungsrisiko.

Wie real dieses Risiko ist, zeigt die Rechtslage selbst: Inhalte, die in eine von einem US-Anbieter verwaltete Cloud hochgeladen werden, unterliegen US-Recht – unabhängig vom physischen Standort der Datenverarbeitung. Lädt ein Mitarbeiter versehentlich vertrauliche technische Unterlagen in eine externe KI-Plattform, können diese Daten in die Trainings- oder Protokolldaten des Anbieters gelangen und im Rahmen behördlicher oder gerichtlicher Anordnungen offengelegt werden. Für Maschinenbauer, deren Servicedaten technisches Know-how und geistiges Eigentum enthalten, ist das ein ernstzunehmendes Szenario.

Lösungsarchitektur: Datenhoheit mit Service Decision Intelligence

Der Einsatz externer KI-Plattformen birgt Risiken, die weniger gegen den Einsatz von KI im Service sprechen, sondern vielmehr für eine souveräne Architektur. Service Decision Intelligence (SDI) ermöglicht es Unternehmen, KI-gestützte Serviceentscheidungen zu treffen, ohne dass Servicedaten den eigenen Kontrollbereich verlassen. Diese Architektur legt den Grundstein für transparente und rechtskonforme Entscheidungen – und stärkt die Datenhoheit als strategischen und compliance-relevanten Faktor.

KI auf eigener Infrastruktur betreiben

Die SDI-Intelligenzschicht wird auf der eigenen Cloud-Infrastruktur des Kunden betrieben – etwa Azure EU, AWS Frankfurt oder im firmeneigenen Rechenzentrum. Die Salesforce-Servicedaten selbst, etwa die digitale Maschinenakte, liegen auf der Salesforce-Plattform in der EU-Region (Hyperforce EU). Dadurch bleiben sensible Servicedaten wie Fehlerhistorien, Maschinenkonfigurationen oder Kundeninformationen – ebenso wie ihre KI-gestützte Verarbeitung – stets im eigenen Einflussbereich. Wird ein Anbieter gewählt, der Servicedaten auf US-Infrastrukturen verarbeitet, greift der US-CLOUD-Act – unabhängig davon, wo die Server physisch stehen. SDI schließt diese Lücke, indem es Datenresidenz innerhalb des EU-Rechtsraums garantiert. Datenschutz ist hier keine Bremse für KI, sondern eine Architekturentscheidung.

Nachvollziehbare Empfehlungen mit Quellennachweis

Eine der Hauptanforderungen des EU-AI-Acts für Hochrisiko-Systeme ist die Auditierbarkeit. SDI erfüllt diese Anforderung durch einen integrierten Quellennachweis: Jede Diagnoseempfehlung oder Serviceentscheidung weist die genutzten Datenquellen aus, sei es ein technisches Handbuch, ein Wartungsprotokoll oder eine Fehlerhistorie. Für Serviceleiter, die Empfehlungen gegenüber Kunden oder internen Prüfern rechtfertigen müssen, bietet dieser Nachweis klare Vorteile. Zudem wird die DSGVO-Auskunftspflicht erfüllt – etwa wenn ein Kunde wissen möchte, auf welcher Grundlage eine Diagnose erstellt wurde. Hier ist Transparenz keine Option, sondern eine Verpflichtung.

Modellfreiheit mit MCP und BYOM

Neben der Nachvollziehbarkeit bietet SDI auch Flexibilität bei der Modellintegration. Mit dem Model Context Protocol (MCP) wird ein offener Standard genutzt, der strukturierten Zugriff auf Unternehmensdaten ermöglicht, ohne dass diese repliziert werden müssen. Das BYOM-Prinzip (Bring-Your-Own-Model) erlaubt es Unternehmen, das Sprachmodell ihrer Wahl zu integrieren – sei es Agentforce, Claude oder ein EU-konformes Modell wie Mistral. Diese Freiheit gewährleistet, dass Unternehmen je nach Anwendungsfall und Compliance-Anforderung flexibel bleiben. Ein Modellwechsel erfordert keine grundlegenden Änderungen der Servicearchitektur, und proprietäre APIs, die an einen einzigen Anbieter binden, entfallen.

GRAX: Vollständige Servicehistorie ohne externe Datenreplikation

Ein häufiges Problem bei KI-Anwendungen im Service ist nicht die Intelligenz des Modells, sondern die unzureichende Datenbasis. Maschinen mit langen Lebenszyklen erfordern Zugriff auf Servicehistorien, die oft Jahrzehnte zurückreichen. In Salesforce können diese Daten jedoch durch API-Limits nur eingeschränkt abgerufen werden.

Die GRAX-Anbindung bietet hier eine Lösung: Sie ermöglicht eine vollständige Auswertung von Salesforce-Servicehistorien ohne API-Limits – und das ausschließlich im Datenraum des Kunden. Es gibt keine Datenreplikation in externe Clouds und keine Weitergabe an Dritte. Für Hersteller mit großen installierten Basen bedeutet dies, dass ältere Fehlerbilder, Wartungsverläufe und Ersatzteilhistorien in die KI-gestützte Diagnose einfließen können, ohne die Datenhoheit zu gefährden.

logicline hat die Salesforce-Integration von Empolis Service Express und TeamViewer mitentwickelt. Beide Partnerlösungen arbeiten innerhalb des Kunden-Datenraums und agieren nicht als Datenexporteure. Dies hebt eine Architektur hervor, die Datenhoheit nicht als nachträglichen Zusatz, sondern als zentralen Bestandteil einplant.

Szenariovergleich: Zwei KI-Architekturoptionen im direkten Gegenüber

Stellen wir uns ein typisches Szenario aus dem Maschinen- und Anlagenbau vor: Ein Hersteller mit rund 6.000 weltweit installierten Anlagen evaluiert eine KI-Plattform für Service-Triage und Diagnose. Die Wahl der Architektur ist dabei nicht nur eine technische, sondern auch eine strategische und rechtliche Entscheidung. Nachfolgend werden zwei Optionen hinsichtlich Datenhoheit, Compliance und praktischer Umsetzung gegenübergestellt.

Option A: US-Cloud-KI-Plattform

In diesem Szenario entscheidet sich der Hersteller für eine KI-Plattform, die auf einer US-Infrastruktur basiert. Dabei werden Servicedaten wie Fehlerhistorien, Maschinenkonfigurationen und Kundenanlagen in eine US-Cloud übertragen und dort verarbeitet. Der US-CLOUD-Act gibt US-Behörden Zugriff auf diese Daten, unabhängig davon, wo die Server physisch stehen. Zudem verlangt der EU-AI-Act ab dem 2. August 2026 für Hochrisiko-Systeme eine Auditierbarkeit sowie Quellennachweise für KI-Entscheidungen. Diese Anforderungen sind mit externen, oft intransparenten Black-Box-Plattformen nur schwer zu erfüllen. Hinzu kommt, dass proprietäre APIs einen Wechsel zu anderen Anbietern erschweren und so einen Vendor-Lock-in verursachen können. Wer die eigene Unternehmens-DNA in ein System einspeist, das einem Dritten gehört, gibt mehr auf als Daten – er gibt einen Teil der unternehmerischen Souveränität auf.

Option B: SDI-Architektur auf eigener Infrastruktur

Die SDI-Architektur bietet eine Alternative, die alle wesentlichen Anforderungen an Datenhoheit und Compliance erfüllt. Die Intelligenzschicht läuft auf der eigenen Cloud-Infrastruktur des Kunden (etwa Azure EU oder AWS Frankfurt), während die Salesforce-Servicedaten auf der Salesforce-Plattform in der EU-Region (Hyperforce EU) verbleiben. So bleiben Daten und Verarbeitung im EU-Rechtsraum und vollständig unternehmensseitig kontrolliert. Durch die GRAX-Anbindung können auch umfangreiche Servicehistorien in die Diagnose einbezogen werden, ohne dass Daten außerhalb der eigenen Infrastruktur repliziert werden. Jede KI-Empfehlung wird mit einem Quellennachweis versehen, was eine Auditierbarkeit gemäß DSGVO und EU-AI-Act sicherstellt. Dank MCP und dem BYOM-Prinzip (Bring Your Own Model) bleibt die Modellwahl flexibel, ohne dass die bestehende Servicearchitektur angepasst werden muss.

Entscheidungsmatrix: Option A vs. Option B

Die folgende Tabelle fasst die Unterschiede zwischen den beiden Ansätzen übersichtlich zusammen:

Für Maschinenbauer, deren Servicedaten sowohl Kundenkontext als auch technisches Know-how enthalten, ist Option A aufgrund der geringen Datenhoheit und der Risiken durch den US-CLOUD-Act kaum geeignet. Option B hingegen bietet eine Lösung, die Datenhoheit und Compliance von Anfang an berücksichtigt und nicht als nachträgliche Anpassung versteht.

Implementierungs-Roadmap: SDI für den KI-gestützten Service einführen

Nach der Entscheidung für eine souveräne KI-Architektur stellt sich die praktische Frage: Wie beginnt man den Umsetzungsprozess? Der Einstieg erfolgt mit hochwertigen Daten und der Schaffung einer konformen Architektur.

Schritt 1: Servicedaten konsolidieren und strukturieren

Die Basis für eine erfolgreiche KI-Implementierung ist die Qualität der Daten. Gerade für Maschinenbauer mit komplexen ERP-Systemen, verstreuten Servicehistorien und unstrukturierten Wartungsprotokollen ist dies oft die größte Herausforderung. Ein zentraler Ausgangspunkt ist die digitale Maschinenakte, die als Salesforce-native Lösung eine vollständige Übersicht über die installierte Basis bietet – inklusive Konfigurationshistorie, IoT-Integration und Informationen zum Lebenszyklus. Ergänzend dazu hilft ein Installed Base Assessment, um bestehende Anlagendaten zu analysieren, Lücken zu identifizieren und erste Verbesserungsmöglichkeiten aufzudecken.

Wichtig: Datenschutzkonforme Speicherung der Servicedaten ist essenziell. DSGVO-relevante Informationen sollten ausschließlich im eigenen Verantwortungsbereich bleiben, ohne externe Replikation oder Übertragung an SaaS-Anbieter ohne entsprechende vertragliche Absicherung.

Schritt 2: Souveräne KI-Architektur aufbauen

Nach der Datenstrukturierung folgt der Aufbau der KI-Architektur. Die SDI-Intelligenzschicht wird vollständig auf der eigenen Cloud des Kunden betrieben, etwa über Azure EU, AWS Frankfurt oder im eigenen Rechenzentrum; die Salesforce-Servicedaten bleiben auf der Salesforce-Plattform in der EU-Region (Hyperforce EU). Dabei verbleiben alle Servicedaten im direkten Kontrollbereich des Unternehmens.

Die GRAX-Anbindung ermöglicht es, umfangreiche Servicehistorien in Salesforce zu analysieren, ohne Daten extern zu replizieren. Durch MCP (Model Context Protocol) und das BYOM-Prinzip bleibt die Modellwahl flexibel: Hersteller können zwischen verschiedenen KI-Modellen wählen, wie Agentforce, Claude oder EU-konformen Alternativen wie Mistral. Zudem werden bei jeder KI-Empfehlung die genutzten Datenquellen dokumentiert, was die Nachvollziehbarkeit und Auditierbarkeit sicherstellt.

Schritt 3: Compliance und Auditierbarkeit verankern

Eine robuste Architektur allein reicht nicht – die Einhaltung regulatorischer Vorgaben muss ebenfalls gewährleistet sein. Ab dem 2. August 2026 treten die Anforderungen des EU-AI-Acts für Hochrisiko-KI-Systeme in Kraft (Europäische Kommission, EU AI Act). Für Maschinenbauer, deren KI-gestützte Diagnose- und Triage-Funktionen unter diese Kategorie fallen, bedeutet dies: vollständige technische Dokumentation, Risikoklassifizierung, Nachweis der Datenquellen für jede Entscheidung und ein kontinuierliches Monitoring nach der Einführung.

Konkret müssen alle LLM-Aufrufe mit Zeitstempel, gehashter Nutzer-ID und Modellversion protokolliert werden – sensible Textinhalte dürfen dabei nicht im Klartext gespeichert werden. Für Hochrisiko-Anwendungen ist außerdem ein Human-in-the-Loop-Mechanismus erforderlich, der sicherstellt, dass kritische Entscheidungen durch Menschen überprüft werden. Unternehmen, die diese Anforderungen frühzeitig in ihre Architektur integrieren, vermeiden später aufwendige und kostspielige Nachbesserungen.

Fazit: Datenhoheit als unternehmerische Entscheidung

Die wichtigsten Erkenntnisse

Die zuvor beschriebenen technischen und regulatorischen Herausforderungen verdeutlichen, dass die Wahl der KI-Architektur im Service eine strategische Weichenstellung darstellt. Sie beeinflusst nicht nur die Einhaltung von Compliance-Vorgaben, sondern auch die Wettbewerbsfähigkeit und die unternehmerische Autonomie. Die Speicherung von Servicedaten in US-Clouds birgt erhebliche Risiken für die DSGVO-Konformität und den Schutz des technischen Know-hows – beides kann später kaum wiederhergestellt werden.

Die SDI-Architektur bietet hier klare Vorteile, wie in den vorherigen Abschnitten erläutert: Die Intelligenz bleibt auf der eigenen Infrastruktur, was die Datenhoheit sichert. Empfehlungen sind durch Quellennachweise vollständig auditierbar, und die Wahl des Modells bleibt flexibel – ob mit Agentforce, Claude oder Mistral, dank MCP und BYOM. Zudem ermöglicht die GRAX-Anbindung den Zugriff auf vollständige Servicehistorien, ohne dass Daten extern repliziert werden müssen. Diese Kombination aus Eigenschaften macht SDI zu einer Lösung, die Compliance-Anforderungen und strategische Ziele gleichermaßen erfüllt.

Ab dem 2. August 2026 gelten zentrale Anforderungen des EU-AI-Acts für Hochrisiko-Systeme. Verstöße gegen diese Pflichten können mit Bußgeldern von bis zu 15 Mio. € oder 3 % des weltweiten Jahresumsatzes geahndet werden; für verbotene KI-Praktiken steigt der Rahmen auf bis zu 35 Mio. € oder 7 % (Art. 99 EU-AI-Act). Unternehmen, die ihre Architektur heute zukunftssicher gestalten, vermeiden später teure Nachbesserungen.

Nächste Schritte

Ein sinnvoller erster Schritt besteht in einer umfassenden Bestandsaufnahme: Welche Servicedaten sind wo gespeichert? Welche Systeme arbeiten bereits KI-gestützt? Und welche davon fallen in die Hochrisiko-Kategorie des EU-AI-Acts?

• Datenlandschaft analysieren: Ein Installed Base Assessment liefert genau diese Antworten – es deckt Lücken auf und zeigt, wo eine souveräne KI-Architektur den größten Nutzen entfaltet.
• Architektur-Entscheidung besprechen: In einem unverbindlichen Erstgespräch ordnen wir gemeinsam ein, welcher Weg zu Ihrer installierten Basis und Ihren Compliance-Anforderungen passt.