Bring Your Own Model. Keep Your Own Control.

A provider may lead on reasoning this quarter, another on cost next quarter, and a third may ship a version tuned for your work. If your platform is tied to one model, each shift requires a migration instead of a routing change.

Keep the freedom to adopt a stronger model, route sensitive work to a provider that meets your requirements, and leave one provider without rebuilding controls. Treat the model as a replaceable component and keep governance consistent around it.

Model choice can affect both quality and the location of processing. IBM distinguishes data residency, where data is stored or processed, from data sovereignty, the legal authority governing that data. Applicable laws and contracts may also depend on the organization, data subjects, processing purpose, and transfer destination.

Some jurisdictions impose localization requirements for particular data or sectors. Check the model provider's processing regions against the laws, contracts, and internal policies that apply to the workload.

GDPR Article 3 defines its territorial scope. It can cover processing outside the EU when, for example, a non-EU controller or processor offers goods or services to people in the EU or monitors their behaviour there. Chapter V governs transfers of personal data to third countries or international organisations.

Record which model processed the data, where processing occurred, the roles of the parties, and which Chapter V condition applied to any transfer.

Start model selection with controls that survive a provider change. Ask which region processes data, whether prompts are retained, whether customer data trains the model, who owns keys, what logs are available, how failures route, and whether workspace permissions still apply at retrieval time.

NIST AI RMF addresses third-party AI directly. Organizations should set policies for risks from third-party software, data, and supply-chain issues; document internal controls for third-party AI components; and monitor those risks. If changing the model forces you to rebuild permissions, audit logs, residency rules, or source grounding, the provider has locked in more than the model.

When the sanctioned platform offers only one model and people do not trust it for the work, some teams will use tools, accounts, or browser tabs you cannot govern. That is shadow AI.

Approved model choice inside a governed platform reduces the reason to route around it. Restricting choice can reduce some risks, but it can also move work somewhere you have no visibility. We examine that dynamic in blocking AI does not stop the leak.

Separate the model from the controls around it. Choose the model on capability, cost, and processing region. Keep access rules, permitted data locations, and logging in the governance layer when the model changes.

Sorena Integrations supports connecting an approved AI provider and changing it without rebuilding workspace permissions or audit records.

Keep provider-independent controls in the platform so they do not disappear when a model changes.

Sorena SSOT, our Single Source of Truth, scopes access, logs activity, and limits retrieval to data available to the active workspace. Changing the provider should not require rebuilding those permissions or the audit record. Processing-region and retention requirements still need to be checked for each provider.

Every provider should meet the same accountability standard. Whichever model is connected, each response must use governed sources and trace back to the relevant record.

Across model changes, keep answers grounded in your data, scoped to the right people, logged, and traceable. Humans still make the decisions.

The model market will keep moving, and residency and transfer rules will keep changing. Make the model a choice and keep permissions, residency rules, source grounding, and audit trails consistent when that choice changes.