What happens to the company's data when you use AI?

"Is our data used to train the model?" is an important question, but it is not enough. The company also needs to know where the information is processed, how long it is stored, what logs are created, which subcontractors gain access, and how data is deleted or exported.

The answer varies between consumer services, enterprise subscriptions, API services, private cloud environments, and locally run models. It is therefore not possible to assess security based on the model's name. The actual service, contract, and configuration must be reviewed.

What data does the user leave?

When an employee uses a generative service, several types of data may be processed:

• the prompt, i.e., the instruction or question

• text that is pasted in

• uploaded documents, images, or audio

• metadata such as user, time, IP address, and device information

• conversation history and feedback

• results created by the model

• logs from integrations and security checks

Even a seemingly harmless question can contain names, customer details, or trade secrets. Therefore, both approved tools and clear rules of use are needed.

The difference between prompt, documents, logs, and training data

The concepts should be kept separate. Input data is what is sent for the service to perform the task. Stored user data is information saved for history, troubleshooting, or functionality. Log data is recorded for operation, security, and follow-up. Training data is used to change the model's parameters.

A provider may promise that the customer's data is not used for model training but still store it for a period for abuse monitoring or support. This can be a reasonable arrangement, but the organization must know that the storage takes place and assess it against the information's requirements.

It is not enough to ask if data is used for training. You need to know where it is processed, stored, logged, and by whom.

Is the company's data used for model training?

Many providers distinguish between consumer services and enterprise or API offerings. OpenAI, for example, states that data from their enterprise products and API is not used to train models by default.[1] Microsoft describes specific data handling terms for Azure-based OpenAI services.[2]

This does not mean that all products from the same provider have identical terms. Settings, add-on features, and support cases can affect the flow. Therefore, check the exact product, region, contract text, and current documentation. Terms change and should be reviewed periodically.

If an organization itself fine-tunes a model or builds an evaluation dataset, its own data becomes part of a separate training or testing process. Even then, rules for selection, storage, access, and deletion are needed.

Where is the information processed and stored?

Data can pass through several technical layers: the user's device, the application, the integration platform, the model provider, logging services, and security tools. Each layer may have its own storage location and retention period.

Ask about both data locality and legal control. Just because a primary database is located in Sweden or the EU does not always say where support, logs, or sub-processors are located. At the same time, a non-European provider does not automatically mean that all information is transferred outside the EU. The actual contract and system flow are crucial.

Document the following for each component:

• region for processing and storage

• encryption in transit and at rest

• key management

• standard retention and option for shorter retention

• backups and deletion processes

• access for support and operations staff

How to connect a secure chat to your organization's own data

Which subcontractors are involved?

An application may use a model from one provider, cloud infrastructure from another, and technical monitoring or logging services from a third. If personal data is processed, the organization needs to understand the personal data responsibility, processor relationships, and any sub-processors.

Request an up-to-date list of subcontractors and a process for how changes are notified. Assess whether new providers or regions require a renewed risk and data protection assessment.

Personal data and legal basis

GDPR applies when personal data is processed, regardless of whether the processing is called AI. The organization needs a clear purpose and legal basis, must minimize data, and must be able to handle data subject rights. In the case of high risk to individuals' rights and freedoms, a data protection impact assessment, DPIA, may be required.

IMY emphasizes data protection throughout the entire life cycle: from needs and data collection to use, follow-up, and decommissioning.[3] For generative services, you also need to assess the risk of personal data being reproduced in outputs, ending up in logs, or being used in a way other than the user understands.

AI Act, NIS2, DORA & GDPR – which requirements affect your company's AI solution?

What changes with local deployment?

A locally run model can make it possible to process information in an environment controlled by the organization or a Swedish hosting partner. This can be crucial for certain information classes and data locality requirements.

However, local deployment is not automatically secure. The organization is then to a higher degree responsible for patching, access, model files, monitoring, capacity, and incident response. Surrounding components – document indexes, logs, and backups – must also be covered by the security architecture.

A hybrid solution can route different tasks to different models. Non-sensitive information can be processed in an external API service, while more sensitive information goes to a local model. For this to work, reliable classification and an architecture where data does not unintentionally cross the boundary are required.

Local language models or cloud models – how to choose?

Consumer service, enterprise agreement, or API?

A consumer service is quick to start using but often provides less organizational control. An enterprise agreement can provide central administration, identity, contracted terms, and better control over data.

An API provides the opportunity to build your own interfaces, permissions, and logic, but shifts more responsibility to the organization and its development partner.

The assessment should cover the entire application, not just the call to the model. A secure model connection does not help if the user interface displays the wrong data or if the logs are open to too many people.

Buy a service, build it yourself, or use an AI platform?

Questions to ask the provider

• Are prompts, documents, outputs, or feedback used for model training?

• What data is saved, for what purpose, and for how long?

• In which regions are primary data, logs, and backups processed?

• Which subcontractors can gain access?

• Can retention be turned off or configured?

• How is data deleted, including backup copies?

• How is our data isolated from other customers' data?

• Which individuals at the provider can gain administrative access?

• How are security incidents logged and notified?

• Can we export our data, configuration, and logs?

• What terms apply if the provider changes model or subcontractor?

• Which controls do we need to configure ourselves?

Role-based AI with Microsoft Entra ID – how access works

Map the data flow before you approve use

Draw the flow from user to data source, application, model, and log. Label each step with information class, responsible party, region, retention, and permitted access. This makes the security discussion concrete and possible to verify.

Connect the map to an AI policy. Employees need to know which tool is approved for which information and what to do if sensitive details have been entered by mistake.

AI in the executive team: 10 questions that take you from idea to business value

Read more about security in the Violet AI Platform

Sources

1. OpenAI, Enterprise privacy:
   https://openai.com/enterprise-privacy/

2. Microsoft, Data, privacy, and security for Azure OpenAI Service:
   https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy

3. IMY, Guidance on GDPR and AI:
   https://www.imy.se/verksamhet/dataskydd/innovationsportalen/vagledning-om-gdpr-och-ai/

4. Google Cloud, Zero data retention:
   https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/zero-data-retention

5. AWS, Data protection in Amazon Bedrock:
   https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html