AI automation: do you know where your data is processed?

Retrospective · week of 17 August 2026

A form arrives, an assistant summarises the request, and a record appears in the CRM. For the sales team, the journey looks simple. For the data, it may involve several services, temporary copies and technical logs. Before asking whether an automation uses “European AI”, it is more useful to understand the actual route that information takes.

On 21 August, OpenAI announced conditional per-request regional processing. Source: OpenAI's official changelog.

Start with information, not suppliers

Take a representative request and list its contents: business contact details, free text, an attachment and a case reference. For each item, ask a simple question: which step genuinely needs to read it? Categorising a request does not necessarily require the contact's full address.

This approach reduces the scope of the assessment. It also makes supplier conversations more precise. “We process sales enquiries” describes an activity; “we send this text, without attachments or contact details, to suggest a category” describes a flow that can be checked.

Draw the complete journey

On one page, map the form, CRM, orchestration tool, model and final destinations. Include notifications, logs and exports used for support. Connect each step with an arrow showing the fields being transmitted. An arrow with no description of its contents is still an unanswered question.

For every service, record the internal owner, required access, settings actually applied and matters still awaiting confirmation. Also distinguish processing a request from retaining a copy. Choosing how one works does not automatically answer the question about the other.

Illustrative example: qualifying a quote request

Imagine a business receiving a description of the customer's needs, an indicative budget and a phone number. The assistant only needs to suggest a service category and flag missing information. An initial version might transmit the entire form. A more carefully scoped version would send only the information needed for that analysis, while the CRM keeps the contact details required for a callback.

The orchestration logs still need checking to make sure they do not reproduce the complete form. The team notification also deserves attention: a link to the record may be preferable to copying its contents into several tools. This example illustrates a design approach, not a SWM customer deployment or result.

Questions to ask before connecting anything

• What data is transmitted, and for which specific operation?
• Which settings are available for our account and intended use?
• What copies appear in logs, exports and support tools?
• Who can view the information and change the configuration?
• How will we check the journey after a workflow changes?

Ask for answers tied to your configuration rather than general statements about the product. Keep unresolved questions in a visible list: information that has not been verified should remain clearly labelled as unverified.

A practical deliverable for decision-making

The first useful outcome is an annotated diagram with a data inventory and a list of decisions to make. It helps establish what can be tested, what should be reduced and what needs specialist review. This article offers an operational method, not legal advice.

SWM's AI consulting service provides a starting point for framing this discussion before integration. Let's review the data your automations transmit and the controls they need.