Where an AI model comes from now matters to enterprise buyers—but “country of origin” is not a complete control. An operating business needs a usable provenance record: which model and version is active, who provides and hosts it, where requests are processed, what data crosses the boundary, what may change, and how the workflow stops or falls back.
That is the practical lesson from a fresh report about questions SAP customers are asking as AI becomes embedded in accounting, supply chain, and other operational software.
What changed
Documented reporting: On October 22, Reuters reported that SAP CFO Dominik Asam said customers are increasingly asking where AI inside their business software was built and whether data could be routed somewhere it should not go. Reuters also reported that SAP embeds more than 70 models from multiple providers and is expanding the regional range of models it can offer.
Primary-source context: SAP’s own documentation describes its generative AI hub as a governed runtime for accessing and orchestrating multiple models. SAP lists both models hosted in SAP AI Core and remote services reached through platforms including Azure OpenAI, Google Vertex AI, AWS Bedrock, Mistral AI, and IBM. The documentation also separates roles such as model management and experimentation.
What is a company statement, not an independent measurement: The reported increase in customer concern is based on the SAP executive’s account. SAP did not publish in that interview a customer count, survey methodology, affected-product inventory, or a product-by-product map of model and data routes.
Bridge Road’s inference: As multi-model AI becomes normal inside ERP, commerce, service, and operations software, procurement records that name only the application vendor will become inadequate. The operational dependency may include a model developer, cloud platform, regional endpoint, orchestration layer, subprocessors, and an embedded software vendor.
Origin is a signal. Provenance is the control.
A geographic label can point to legitimate questions about law, access, export restrictions, service continuity, data residency, or contractual enforcement. It does not answer those questions by itself.
Two deployments using the same model can have materially different risk because one is hosted in a controlled regional environment with private endpoints and no data retention, while another sends requests to a remote service under different terms. Conversely, models from different developers may operate under the same approved hosting, identity, logging, and data-handling controls.
The useful unit of governance is therefore not just which model? It is which model, delivered through which service path, for which workflow, with what authority and evidence?
The minimum provenance record
For every production AI capability—whether directly purchased or embedded in another platform—record these fields:
- Business use and owner: the workflow, accountable process owner, and approved purpose.
- Decision authority: whether AI may read, classify, draft, recommend, or execute.
- Model identity: developer, model family, exact version or deployment alias, and effective date.
- Delivery chain: application vendor, orchestrator, cloud or API provider, host, and material subprocessors.
- Processing path: deployment region, request-routing region, storage location, and administrative access boundaries.
- Data rules: allowed fields, prohibited data, retention, logging, training-use terms, and deletion expectations.
- Permissions: systems, records, credentials, tools, and actions available to the workflow.
- Change control: notice requirements for model, provider, version, region, terms, or subprocessor changes.
- Evidence: approvals, tests, outputs, exceptions, configuration changes, and incident history.
- Exit path: rollback target, replacement model or deterministic process, and manual fallback.
This record should live with the workflow inventory—not in a policy document that operations never sees.
Turn the record into operating controls
1. Discover embedded AI
Review the ERP, CRM, commerce platform, help desk, marketing stack, document tools, and integration layer. Ask vendors which features invoke AI, which models they use, whether the customer can select or restrict models, and whether those answers differ by feature or region.
2. Classify by consequence
A model drafting a product description does not need the same control set as one changing a purchase order, promising inventory, approving a discount, or writing to a customer record. Define consequence tiers before debating individual vendors.
3. Restrict authority
Use least-privilege permissions. Separate read, draft, approve, and execute rights. The model should not inherit the full authority of the person or application that connected it.
4. Validate before action
Apply deterministic checks to customer, SKU, price source, margin, availability, required fields, duplicate risk, and policy constraints. In an industrial workflow, model provenance does not replace transaction validation.
5. Put people at the right gates
Require human approval for commitments, sensitive-data access, unusual substitutions, pricing overrides, destructive writes, and other high-consequence exceptions. Give the reviewer the source record, model output, validation result, and reason for escalation.
6. Monitor for drift in the delivery chain
Alert on changes to the model alias, provider, endpoint, region, retention terms, subprocessor list, or application feature configuration. Re-run acceptance tests before approving a material change. A silent provider swap is a governance event even when the user interface looks the same.
7. Rehearse failure
Name the incident owner. Preserve logs that connect the input, model route, output, validation, approval, and final system action. Maintain a tested rollback and a manual path so quoting, order entry, customer service, or fulfillment can continue when an AI dependency is paused.
What an operating business should ask this week
- Can we produce a current list of the AI models embedded in our five most important systems?
- Do we know the full service path and processing region for each one?
- Can the vendor change a model or provider without notice?
- Which workflows can commit money, inventory, customer promises, or regulated data?
- Can we disable one AI feature without stopping the underlying business process?
- Who owns the exception queue and the decision to switch to manual operation?
If those answers are missing, the first step is not rejecting AI. It is making the deployment legible enough to govern.
The practical takeaway
Model choice is becoming more dynamic, not less. That makes a static approved-vendor list insufficient. Keep the benefits of multi-model systems—fit, cost, resilience, and choice—while attaching every production use to a provenance record, bounded permissions, deterministic validation, human approval where consequence warrants it, auditable evidence, monitoring, and a tested fallback.
Bridge Road helps manufacturers, distributors, and commerce teams map the systems and data paths behind a workflow, then place controls where the work actually happens. Start with the AI governance framework or discuss a governed automation plan.
Sources: Reuters, October 22, 2026; SAP Help Portal: Generative AI Hub; SAP Help Portal: Models and Scenarios.
