Summary

• SAP embeds more than 70 third-party AI models in its enterprise applications, according to its finance chief.
• Customers increasingly question provenance and data access, with requirements differing by jurisdiction and workload.
• Model origin, hosting location and operational control are separate procurement and governance considerations.

Customers of German enterprise software company SAP are increasingly questioning where embedded AI models were developed and how information processed by those systems is governed, according to the company’s finance chief, as geopolitical considerations enter technology procurement alongside price and performance.

Chief financial officer Dominik Asam told Reuters in an interview published on 22 October that clients raise concerns about model provenance and the possibility of data reaching places they did not intend. SAP uses more than 70 models from different suppliers across applications supporting activities such as accounting and supply chain management.

Maintaining a diverse model portfolio lets SAP use different systems for different tasks, but it also complicates the assurances customers expect from an enterprise vendor. The organisation buying the application may contract with SAP while indirectly relying on other companies for model development, hosting, updates or technical components.

Asam described variations in customer preferences. A US business might reject a component using a model developed in China, while another company could accept an internationally developed open-weight model for routine internal operations. Government and defence users may impose much more restrictive requirements.

These are examples of procurement choices rather than evidence that a new law forbids companies from using models developed in particular countries. They also reflect statements made in an interview, not a published survey measuring the prevalence of each preference among SAP customers.

Model origin differs from where it runs

The country in which a model was developed is not necessarily the location where an enterprise’s information is processed. Some open-weight models can run on infrastructure controlled by a customer, while a model created by a European supplier could still be served from a region governed by different legal and operational arrangements.

Customers therefore need to distinguish provenance, hosting location, ownership and access rights. A statement that an application uses a European model does not by itself establish who operates the computing environment or whether information is transferred to a separate service for monitoring or support.

The same distinctions apply to model components. A software provider may change the underlying model or use several models within one workflow, while customers encounter only a single branded assistant in the application interface. Understanding that chain becomes harder when an agent selects tools or models dynamically.

Open weights can offer greater deployment flexibility by allowing organisations to run certain models in their own environment. Yet access to weights is not the same as comprehensive knowledge of training data, licensing requirements, safety behaviour or every dependency needed for operation.

For enterprise procurement, useful documentation should identify the model and version involved, the purpose for which information is processed, the applicable retention rules and the conditions under which a provider can make material changes. The appropriate requirements will differ between ordinary administrative work and operations involving sensitive records.

Model flexibility has commercial value because organisations can select alternatives based on cost, language capabilities and performance. That value depends on how efficiently applications can switch between options and whether results remain consistent enough for the business processes being supported.

Sovereignty questions reach ordinary applications

European debate about digital sovereignty has often centred on cloud computing capacity, public infrastructure and reliance on a small number of foreign suppliers. Embedding third-party AI models in business software brings similar questions into purchasing decisions for systems that enterprises already use every day.

Software used for finance, human resources and procurement can process sensitive commercial material even when its AI functions appear routine. A summarisation feature may encounter supplier prices or employment information, while a more autonomous agent could read records across several business applications.

Those uses need appropriate permissions and auditable processing arrangements regardless of the model’s country of origin. A locally hosted system with excessive access rights can still expose information, while a cross-border service may be usable for other workloads where law, contracts and technical controls permit it.

Asam also referred to European discussion of possible ways in which access to US cloud services could be interrupted, sometimes described as a hypothetical kill switch. The interview does not provide evidence that such a mechanism has been activated against European SAP customers or establish that it exists in the form implied by the debate.

SAP wants a model portfolio spanning multiple regions, including Europe and Canada, and has been pursuing business with government and defence customers. A broader range of suppliers can reduce reliance on one region, but it may not eliminate concentration in common chips, networking infrastructure or underlying software components.

Customers operating in several jurisdictions may also need different approved configurations for different teams. A single group-wide instruction to use a named AI provider may be too crude when some data is ordinary business material and other records are subject to stronger contractual or statutory restrictions.

Governance continues after procurement

Initial due diligence cannot resolve every future issue. Model providers issue updates, applications add capabilities and organisations connect agents to more systems. The supplier and customer must determine which changes require testing, fresh approvals or revised security assessments.

Audit records can help investigators establish which model version processed a request and which information was available at the time. Such records are especially valuable where output contributes to financial reporting, contractual decisions or other activity that must later be explained.

There is also a cost to maintaining multiple approved models. Technical teams need to evaluate performance, monitor quality, maintain integrations and ensure that policies remain effective after updates. Flexibility may improve resilience while increasing the work of governance.

SAP’s own use of AI for security testing provides a separate example of the technology entering established software processes. Asam said the company uses advanced models to probe its products for vulnerabilities, while acknowledging that no supplier can credibly claim to be free of weaknesses. He did not disclose the results of those tests.

The interview offers no quantified measure of customer demand for sovereign models and does not demonstrate that provenance concerns are generating a particular amount of SAP revenue. Its significance is the explicit acknowledgement that customers are asking new questions about dependencies previously hidden inside ordinary software contracts.

As businesses use more AI through existing platforms, model selection may become a documented purchasing and governance decision rather than an invisible feature chosen entirely by the vendor. SAP’s portfolio creates options, but the control customers receive will depend on how those options are exposed, governed and maintained in actual deployments.