Why Cloud Regions, Infrastructure Providers and Sub-processors Matter in Enterprise ERP

Connecting a new service to an enterprise platform has never been easier.

An administrator can enter an API key, approve a connector and give an artificial intelligence model access to information in an ERP system within minutes. The AI can then summarise customer interactions, classify support tickets, extract information from invoices, draft emails, analyse transactions or recommend the next action.

Technically, the connection may be simple.

From a data-governance perspective, however, that single click can create an entirely new international data-processing chain.

A routine cloud notice raises a bigger question

Odoo recently notified customers that, from 24 September 2026, Amazon Web Services may also be used as infrastructure for Odoo Cloud databases hosted outside the European Union.

Odoo explained that existing customers would ordinarily remain on their current infrastructure, although a database could move to AWS as part of certain lifecycle, restoration or infrastructure operations. Customers can select an available hosting region, but not necessarily the individual infrastructure provider operating within that region.

This is not inherently negative. Using multiple infrastructure providers can strengthen capacity, resilience and disaster recovery.

However, the notice highlights something many organisations overlook:

Where an application is hosted, who provides the infrastructure and which organisations process its data are three different questions.

The introduction of AI makes understanding those distinctions even more important.

The modern ERP no longer has one data location

Consider a South African business using an ERP database hosted in Europe.

At first glance, its data journey may appear straightforward:

• The business operates in South Africa and is subject to the Protection of Personal Information Act, commonly known as POPIA.
• Its ERP database is hosted in a European cloud region.
• The ERP provider and its infrastructure providers process and store the database under their respective contractual obligations.
• European data-protection requirements may also become relevant, depending on the organisation, affected individuals and processing activities.

Now the business connects an AI service to the ERP using an API.

When an employee asks the ERP to summarise a customer complaint, assess an invoice or analyse a transaction, selected information may leave the ERP environment and be transmitted to the AI provider. Depending on the architecture and configuration, the AI request could include:

• names and contact details;
• invoice or payment information;
• customer correspondence;
• employee information;
• contractual terms;
• transaction histories;
• support tickets;
• commercially confidential information; or
• special personal information.

The AI provider processes that information and returns an answer. The request, response or related metadata may also be recorded by the ERP, connector, integration platform, monitoring tools or AI provider.

The data is therefore no longer simply “in the ERP in Europe”. It may now be processed or temporarily retained across several systems and jurisdictions.

An API key does not determine where the data is processed. It authenticates the system making the request. The provider, product, contract, selected region and technical configuration determine the actual processing chain.

Who can actually see the data?

The honest answer is: it depends on the configuration, contracts and providers involved.

Potential parties include:

• authorised employees and administrators within the customer organisation;
• the ERP provider;
• the underlying cloud infrastructure provider;
• the developer or integration partner;
• the company operating the connector or integration platform;
• logging, monitoring, backup and security providers;
• the AI model provider;
• approved sub-processors used by any of these organisations; and
• authorised personnel who may access information for support, security, abuse investigation or legal compliance.

This does not mean employees at every provider freely read customer data. Reputable enterprise providers generally implement access restrictions, contractual controls, audit processes and technical safeguards.

It does mean businesses should understand who is contractually and technically capable of processing the information—and under which circumstances.

Encryption is essential, but it does not answer every question

Encryption in transit protects information while it moves between systems, commonly through Transport Layer Security, or TLS.

Encryption at rest protects information while it is stored on databases, disks or backups.

Both are essential. Neither means the receiving service can never access the data.

An AI model must process the content of a request to generate a response. The authorised receiving system therefore needs to decrypt the information during processing. Similarly, an application must be able to decrypt stored information when an authorised user or service retrieves it.

The important questions are consequently broader:

• Who controls the encryption keys?
• Where is the information decrypted?
• Which systems and people can access the decrypted content?
• Is access logged and monitored?
• How long are prompts, responses and logs retained?
• Can the information be deleted?
• Is it used for model training or service improvement?
• What happens when security systems flag a request for review?

Encryption protects data from unauthorised access. It does not replace governance over authorised processing.

POPIA does not simply prohibit overseas hosting

POPIA does not require every South African organisation to keep all personal information physically inside South Africa.

Section 72 permits transfers outside South Africa under specified conditions. These include situations where the recipient is subject to a law, binding corporate rules or binding agreement that provides an adequate level of protection. Other permitted grounds can include consent and certain transfers necessary for the performance or conclusion of a contract.

The South African organisation nevertheless remains responsible for ensuring its processing and international transfers satisfy POPIA. Moving data into a respected cloud region does not transfer that accountability to the cloud provider. See the Information Regulator guidance on POPIA Chapter 9 and transborder information flows.

Similarly, hosting an ERP database in Europe does not automatically mean every subsequent use of the data remains inside Europe or that “GDPR compliance” automatically covers the entire solution. If personal data governed by the GDPR is transferred outside the European Economic Area, the GDPR’s international-transfer requirements may apply. See the official text of the GDPR.

A business must evaluate the complete processing chain, not only the original database location.

Are OpenAI and Anthropic using enterprise API data to train their models?

The answer depends on the specific product and agreement. Consumer AI accounts and commercial API services should not be treated as though they have identical terms.

OpenAI states that data submitted through its API and business products is not used to train its models by default. Its published API arrangements describe retention controls that can vary according to the service, endpoint and customer eligibility. OpenAI also publishes security and encryption commitments for business data. These protections must be checked against the actual product and agreement being used. See OpenAI’s enterprise privacy commitments.

Anthropic similarly states that inputs and outputs from its commercial products, including the Anthropic API, are not used for model training by default. Its published retention terms also depend on the service, features, legal requirements, safety enforcement and any separately agreed controls. See Anthropic’s guidance on commercial model training and commercial data retention.

These are meaningful protections—but they must be verified against the actual product, account type, endpoint, configuration and contract being used.

A third-party connector that sends data to an AI provider may also have its own retention practices. Even if the AI provider offers reduced or zero data retention, the connector could still log the request and response.

“They say they are not listening—but how do we really know?”

Many people have spoken about a product and then seen a remarkably relevant advertisement. This often creates the feeling that a phone or social platform must have been listening.

That suspicion should not be presented as fact without evidence. Modern platforms can infer a surprising amount from browsing activity, location, app interactions, search behaviour, purchases, social connections and information received from advertising partners. Highly accurate inference can feel like surveillance even when a microphone was not involved.

The enterprise lesson is not that every provider is secretly misusing data.

The lesson is that trust alone is not a control.

Organisations need contracts, technical settings, audit evidence, access logs, retention controls, independent certifications and a clear record of what data was shared.

The question is not only: Do we trust this provider?

The organisation should also be able to answer: Can we demonstrate what information was transferred, why it was transferred, where it went, who could access it, how long it was retained and how it will be deleted?

Before connecting AI to an ERP, ask these questions

• The purpose. What specific business outcome requires the AI connection?
• The data fields. Exactly which fields, records, documents or messages will be transmitted?
• Data minimisation. Can names, identity numbers, account details or other sensitive fields be removed, masked or replaced before transmission?
• The complete data route. Does the information travel directly to the AI provider, or through a connector, integration platform or development partner?
• Processing locations. Where will information be stored, processed, backed up and logged?
• Responsible parties and operators. Who determines the purpose of the processing, and which providers process information on that organisation’s behalf?
• Sub-processors. Which other organisations may support hosting, monitoring, security, content review or service delivery?
• Retention and deletion. How long are inputs, outputs, metadata and logs retained, and can retention be reduced or disabled?
• Model training. Is customer data excluded from training by default, or does the organisation need to opt out?
• Human access. Under which support, security, safety or legal circumstances could authorised personnel review the content?
• Security controls. Is data encrypted in transit and at rest, who controls the keys, and are access and administrative actions logged?
• International-transfer safeguards. Are the necessary data-processing agreements and cross-border transfer mechanisms in place?
• Incident management. Who must notify the customer if a breach occurs, and within what period?
• Termination. What happens to retained data, logs, API credentials and backups when the integration is disconnected?

Connect deliberately, not fearfully

AI can create significant value inside enterprise platforms. It can reduce administrative work, improve access to information and help teams make faster, better-informed decisions.

The objective should not be to prevent connection or innovation. It should be to make every connection deliberately.

The ease of adding an API key should not determine the level of governance applied to the decision. Before allowing information to move between an ERP, a connector and an AI model, organisations should be able to explain the full journey in plain language.

If the business cannot answer where its information goes, who processes it, how long it remains there and whether it is used for another purpose, it is not yet ready to click “Connect”.

Disclaimer: This article provides general technology and data-governance information and does not constitute legal advice. Organisations should assess their specific processing activities, contracts and regulatory obligations.