Machine manufacturers face a key challenge: how can they use AI to make diagnostics and maintenance more efficient without losing control of sensitive service data? Data such as machine configurations, maintenance histories and error logs are not only business-critical, but also legally sensitive. The use of external platforms harbors risks such as access by third parties (e.g. US CLOUD Act) or restrictions due to the EU AI Act, which will impose strict requirements on many AI systems from August 2026.
The solution: By using a sovereign architecture such as Service Decision Intelligence (SDI), companies can make AI-supported decisions without giving up data sovereignty. SDI enables the operation of AI on a company’s own infrastructure, provides proof of source for recommendations and avoids risks such as vendor lock-in or external data replication. This not only ensures compliance, but also protects technical expertise and customer relationships.
The risk area: problems with external AI cloud platforms
Why service data is particularly sensitive
Service data is a delicate matter, as it combines three categories of data that are particularly worthy of protection: personal data (such as the contact details of technicians and contact persons), technical know-how of the manufacturer (such as information on error patterns, diagnostic paths or tolerance limits) and operational data (for example machine configurations, maintenance intervals or failure histories). This combination makes service data not only a valuable asset, but also a potential risk, especially if it is transferred to external platforms. Such data allows third parties to gain insights into a company’s knowledge accumulated over decades – a significant risk to competitive advantage.
Are you currently evaluating an AI solution for your service?
In a non-binding initial consultation, we will show you how AI-supported service decisions can be implemented without giving up control over your service data.
→ Arrange an initial consultation
Legal and compliance risks
A key aspect is the legal uncertainty when dealing with external platforms, especially those based in the USA. The US CLOUD Act allows US authorities to access data managed by US providers – regardless of whether the servers are located in Europe. For machine builders, this means that the protection of sensitive service data is already taken out of their hands to a certain extent when the contract is signed.
In addition, the Schrems II-ruling makes the transfer of data to the USA more difficult. Even the EU-US Data Privacy Framework does not offer long-term security for sensitive industrial data. Although protective measures such as standard contractual clauses or transfer impact assessments are possible, they are often complicated and costly to implement in practice.
The EU AI Act will apply to many high-risk AI systems from August 2, 2026 (full application for regulated products will follow in 2027). High-risk AI systems that support safety-relevant diagnoses or maintenance decisions, for example, will then be subject to strict requirements such as auditability, proof of source and risk assessment(EU Commission, Digital Strategy). External AI providers that rely on black box APIs are usually unable to meet these requirements, which creates additional risks for European companies.
Business risks beyond compliance
Apart from legal issues, external platforms also harbor strategic risks. Many US platforms work with proprietary APIs and specific function syntaxes. Once integrated, this creates a vendor lock-in that makes it difficult to switch to other providers and increases costs as data volumes rise.
Another problem is the loss of transparency. If an AI platform makes diagnoses or recommendations without disclosing which data sources they are based on, the use of such recommendations becomes problematic under the EU AI Act. There is a significant liability risk for service managers who have to justify these decisions to customers.
The legal situation itself shows just how real this risk is: Content uploaded to a cloud managed by a US provider is subject to US law – regardless of the physical location of the data processing. If an employee inadvertently uploads confidential technical documents to an external AI platform, this data can end up in the provider’s training or log data and be disclosed under official or court orders. This is a serious scenario for machine manufacturers whose service data contains technical know-how and intellectual property.
Solution architecture: Data sovereignty with Service Decision Intelligence
The use of external AI platforms harbors risks that speak less against the use of AI in the service and more in favor of a sovereign architecture. Service Decision Intelligence (SDI) enables companies to make AI-supported service decisions without service data leaving their own sphere of control. This architecture lays the foundation for transparent and legally compliant decisions – and strengthens data sovereignty as a strategic and compliance-relevant factor.
Operating AI on your own infrastructure
The SDI intelligence layer is operated on the customer’s own cloud infrastructure – such as Azure EU, AWS Frankfurt or in the company’s own data center. The Salesforce service data itself, such as the digital machine file, is stored on the Salesforce platform in the EU region(Hyperforce EU). This means that sensitive service data such as error histories, machine configurations or customer information – as well as their AI-supported processing – always remain within the company’s own sphere of influence. If a provider is chosen that processes service data on US infrastructures, the US CLOUD Act applies – regardless of where the servers are physically located. SDI closes this gap by guaranteeing data residency within the EU legal area. Data protection is not a brake on AI here, but an architectural decision.
Comprehensible recommendations with references
One of the main requirements of the EU AI Act for high-risk systems is auditability. SDI fulfills this requirement by providing an integrated proof of source: every diagnostic recommendation or service decision shows the data sources used, be it a technical manual, a maintenance log or a fault history. This proof offers clear advantages for service managers who have to justify recommendations to customers or internal auditors. It also fulfills the GDPR obligation to provide information – for example, if a customer wants to know on what basis a diagnosis was made. Transparency is not an option here, but an obligation.
Model freedom with MCP and BYOM
In addition to traceability, SDI also offers flexibility in model integration. With the Model Context Protocol (MCP), an open standard is used that enables structured access to company data without having to replicate it. The BYOM principle (Bring-Your-Own-Model) allows companies to integrate the language model of their choice – be it Agentforce, Claude or an EU-compliant model such as Mistral. This freedom ensures that companies remain flexible depending on the use case and compliance requirements. A change of model does not require any fundamental changes to the service architecture, and proprietary APIs that are tied to a single provider are no longer necessary.
GRAX: Complete service history without external data replication
A common problem with AI applications in service is not the intelligence of the model, but the inadequate database. Machines with long lifecycles require access to service histories that often go back decades. In Salesforce, however, this data can only be accessed to a limited extent due to API limits.
The GRAX-connection offers a solution here: it enables a complete evaluation of Salesforce service histories without API limits – and exclusively in the customer’s data room. There is no data replication in external clouds and no transfer to third parties. For manufacturers with large installed bases, this means that older error patterns, maintenance histories and spare parts histories can be incorporated into AI-supported diagnostics without jeopardizing data sovereignty.
logicline has completed the Salesforce integration of Empolis Service Express and TeamViewer co-developed. Both partner solutions work within the customer data room and do not act as data exporters. This emphasizes an architecture that plans data sovereignty not as an add-on but as a central component.
Scenario comparison: Two AI architecture options in direct comparison
Let’s imagine a typical scenario from the mechanical and plant engineering sector: A manufacturer with around 6,000 systems installed worldwide is evaluating an AI platform for service triage and diagnostics. The choice of architecture is not only a technical decision, but also a strategic and legal one. Below, two options are compared in terms of data sovereignty, compliance and practical implementation.
Option A: US cloud AI platform
In this scenario, the manufacturer opts for an AI platform based on a US infrastructure. Service data such as error histories, machine configurations and customer systems are transferred to a US cloud and processed there. The US CLOUD Act gives US authorities access to this data, regardless of where the servers are physically located. In addition, from August 2, 2026, the EU AI Act will require high-risk systems to be auditable and provide evidence of the source of AI decisions. These requirements are difficult to meet with external, often non-transparent black box platforms. In addition, proprietary APIs make it difficult to switch to other providers and can therefore cause a vendor lock-in. Anyone who feeds their own corporate DNA into a system that belongs to a third party is giving up more than just data – they are giving up part of their corporate sovereignty.
Option B: SDI architecture on own infrastructure
The SDI architecture offers an alternative that meets all essential requirements for data sovereignty and compliance. The intelligence layer runs on the customer’s own cloud infrastructure (such as Azure EU or AWS Frankfurt), while the Salesforce service data remains on the Salesforce platform in the EU region(Hyperforce EU). This means that data and processing remain in the EU legal area and are fully controlled by the company. Thanks to the GRAX connection, extensive service histories can also be included in the diagnosis without replicating data outside the company’s own infrastructure. Each AI recommendation is provided with a source reference, which ensures auditability in accordance with the GDPR and EU AI Act. Thanks to MCP and the BYOM principle (Bring Your Own Model), the choice of model remains flexible without having to adapt the existing service architecture.
Decision matrix: Option A vs. option B
The following table summarizes the differences between the two approaches:
| Criterion | Option A: US cloud AI | Option B: SDI architecture |
|---|---|---|
| Data sovereignty | Low – data leaves the EU control area | High – data remains on customer infrastructure |
| EU-AI-Act conformity | Dependent on provider transparency | Native – full control over logs and source tracking |
| Vendor lock-in risk | High – proprietary APIs and ecosystems | Low – open standards (MCP), BYOM |
| Access to service history | Restricted by API limits and cloud policies | Completely via GRAX in the customer data room |
| US CLOUD Act exposure | Yes – US providers are subject to US authority access | No – EU infrastructure, no US provider |
For machine manufacturers whose service data contains both customer context and technical know-how, option A is hardly suitable due to the low level of data sovereignty and the risks posed by the US CLOUD Act. Option B, on the other hand, offers a solution that takes data sovereignty and compliance into account from the outset and does not see them as an afterthought.
Implementation roadmap: Introducing SDI for the AI-supported service
After deciding on a sovereign AI architecture, the practical question arises: How do you start the implementation process? You start with high-quality data and the creation of a compliant architecture.
Step 1: Consolidate and structure service data
The basis for a successful AI implementation is the quality of the data. This is often the biggest challenge, especially for machine manufacturers with complex ERP systems, scattered service histories and unstructured maintenance logs. A central starting point is the digital machine filewhich, as a Salesforce-native solution, provides a complete overview of the installed base – including configuration history, IoT integration and life cycle information. This is supplemented by an Installed Base Assessmenthelps to analyze existing plant data, identify gaps and uncover initial opportunities for improvement.
Important: Data protection-compliant storage of service data is essential. GDPR-relevant information should remain exclusively in your own area of responsibility, without external replication or transfer to SaaS providers without appropriate contractual safeguards.
Step 2: Build a sovereign AI architecture
Once the data has been structured, the AI architecture is set up. The SDI intelligence layer is operated entirely on the customer’s own cloud, for example via Azure EU, AWS Frankfurt or in the customer’s own data center; the Salesforce service data remains on the Salesforce platform in the EU region (Hyperforce EU). All service data remains under the direct control of the company.
The GRAX connection makes it possible to analyze extensive service histories in Salesforce without having to replicate data externally. Thanks to MCP (Model Context Protocol) and the BYOM principle, the choice of model remains flexible: manufacturers can choose between different AI models, such as Agentforce, Claude or EU-compliant alternatives such as Mistral. In addition, the data sources used are documented for each AI recommendation, which ensures traceability and auditability.
Step 3: Anchoring compliance and auditability
A robust architecture alone is not enough – compliance with regulatory requirements must also be guaranteed. From August 2, 2026, the requirements of the EU AI Act for high-risk AI systems will come into force(European Commission, EU AI Act). For machine manufacturers whose AI-supported diagnostic and triage functions fall into this category, this means complete technical documentation, risk classification, proof of data sources for each decision and continuous monitoring after implementation.
Specifically, all LLM calls must be logged with a timestamp, hashed user ID and model version – sensitive text content must not be stored in plain text. For high-risk applications, a human-in-the-loop mechanism is also required to ensure that critical decisions are checked by humans. Companies that integrate these requirements into their architecture at an early stage avoid time-consuming and costly rework later on.
Conclusion: Data sovereignty as a business decision
The most important findings
The technical and regulatory challenges described above make it clear that the choice of AI architecture in the service represents a strategic decision. It not only influences compliance requirements, but also competitiveness and entrepreneurial autonomy. Storing service data in US clouds harbors considerable risks for GDPR compliance and the protection of technical expertise – both of which can hardly be restored later.
The SDI architecture offers clear advantages here, as explained in the previous sections: the intelligence remains on the company’s own infrastructure, which secures data sovereignty. Recommendations are fully auditable through source references, and the choice of model remains flexible – whether with Agentforce, Claude or Mistral, thanks to MCP and BYOM. In addition, the GRAX connection enables access to complete service histories without the need to replicate data externally. This combination of features makes SDI a solution that meets compliance requirements and strategic objectives in equal measure.
From August 2, 2026, key requirements of the EU AI Act will apply to high-risk systems. Violations of these obligations can be punished with fines of up to €15 million or 3% of annual global turnover; for prohibited AI practices, the framework increases to up to €35 million or 7%(Art. 99 EU AI Act). Companies that design their architecture to be future-proof today will avoid expensive subsequent improvements.
Next steps
A sensible first step is to take a comprehensive inventory: What service data is stored where? Which systems are already working with AI support? And which of these fall into the high-risk category of the EU AI Act?
- Analyzing the data landscape: An Installed Base Assessment provides precisely these answers – it uncovers gaps and shows where a superior AI architecture will deliver the greatest benefit.
- Discuss the architectural decision: In a non-binding initial meeting we will work together to determine which approach suits your installed base and your compliance requirements.
FAQs
When is our service AI considered "high risk" under the EU AI Act?
Your service AI falls under the “high-risk” classification according to the EU AI Act if it controls safety-relevant product components, makes autonomous quality control decisions or influences critical infrastructures (Annex III). Strict requirements apply in such cases, including transparency and documentation obligations. This becomes particularly important if the AI is used in auditable processes that become mandatory with the central application deadlines.
How do we prevent service data from entering LLM training or third-party systems?
Protecting service data from unauthorized access requires an architecture that is consistently geared towards data sovereignty. This means that data and its processing remain in the controlled area – the Salesforce service data on the Salesforce platform in the EU region(Hyperforce EU), the SDI intelligence layer on the customer’s own cloud(Azure EU, AWS Frankfurt) or in an on-premise solution. The use of RAG architectures (Retrieval Augmented Generation) ensures that data is only processed at query time and does not flow into the training of AI models. In addition, zero data retention clauses and Bring Your Own Model (BYOM) approaches offer additional security. These measures not only ensure complete control over the data, but also prevent dependencies on individual providers (vendor lock-ins).
How do we integrate SDI into Salesforce without vendor lock-in?
To integrate Service Decision Intelligence (SDI) into Salesforce while avoiding a vendor lock-in, an open architecture with clear data control is crucial. The intelligence layer remains in your own cloud infrastructure, for example on Azure EU or AWS Frankfurt, while the Salesforce service data remains on the Salesforce platform in the EU region(Hyperforce EU) – this ensures compliance with European data protection standards. Thanks to open standards such as the Model Context Protocol (MCP), you can use the Bring-Your-Own-Model (BYOM) principle. This means that you can switch flexibly between different large language models (LLMs) such as Mistral – without having to adapt your data or existing infrastructure.
