Articles

AI providers under GDPR

AI providers under GDPR

IMY Clarifies When AI Providers Are Controllers or Processors

Sweden’s IMY clarifies GDPR responsibility roles for companies fine-tuning AI applications. Learn when AI providers act as controllers, processors or joint controllers.

Sweden’s data protection authority, the Swedish Authority for Privacy Protection (IMY), has published new guidance on how responsibility under the GDPR should be assessed when companies develop, fine-tune or use AI applications.

The report focuses on a key question many organisations are currently facing: when an AI provider processes personal data, is it acting as a data controller, a data processor or possibly a joint controller?

The answer depends on the provider’s actual influence over the processing of personal data.

Why GDPR roles matter in AI development

As more companies build, customise and deploy AI tools, the question of responsibility becomes increasingly important. AI systems may involve personal data during development, testing, fine-tuning, deployment or ongoing improvement.

Under the GDPR, organisations must clearly understand who decides the purposes and means of processing. This determines whether a company is acting as:

  • a controller, deciding why and how personal data is processed;
  • a processor, processing personal data on behalf of another organisation; or
  • a joint controller, where two or more parties jointly determine the purposes and means of processing.

Getting this wrong can create compliance gaps, unclear contractual obligations and uncertainty between AI vendors and their customers.

Important to know

GDPR roles and EU AI Act roles are not the same

It is also important to separate GDPR responsibility roles from roles under the EU AI Act. A company may be a provider or deployer under the EU AI Act, while also acting as a controller, processor or joint controller under the GDPR.

These role assessments answer different questions and should be documented separately. For more on AI Act role classification, see our guide on EU AI Act deployer vs provider .

IMY’s key conclusion: responsibility depends on influence

IMY’s report confirms that GDPR responsibility roles cannot be determined only by looking at contract labels or technical involvement. Instead, the role depends on the company’s actual influence over the personal data processing.

In practice, this means asking questions such as:

In practice, this means asking questions such as

Who decides why personal data is used?

Who determines what data is used for fine-tuning?

Who decides how the AI application will be developed or adapted?

Is the provider acting independently or only on the customer’s documented instructions?

Is the processing carried out for the provider’s own product development or for a specific customer’s purposes?

GDPR role assessment

Responsibility depends on influence

These questions help determine whether an AI provider is acting as a controller, processor or joint controller under the GDPR.

The key issue is not only what the contract says, but who actually decides the purpose, data use and practical setup of the AI processing.

When an AI provider is likely to be a controller

According to IMY, if an AI provider fine-tunes an AI model using personal data on its own initiative as part of its own product development, the starting point is that the provider is acting as a data controller.

This is because the provider determines the purpose of the processing: improving, developing or adapting its own AI product.

For example, if a company uses customer data, user data or other personal data to improve its general AI solution for future commercial use, it is likely making independent decisions about the purposes and means of processing. In that case, the provider must be able to demonstrate its own GDPR compliance, including a lawful basis, transparency, data minimisation, retention controls and appropriate risk assessments.

When an AI provider is likely to be a processor

If the fine-tuning takes place on behalf of a specific customer and strictly according to that customer’s instructions, the provider will normally be a data processor.

In this situation, the customer determines the purpose of the processing, while the provider carries out the technical processing activity for the customer.

This means the parties should have a proper data processing agreement in place. The agreement should clearly define the scope of processing, categories of personal data, security measures, subprocessors, deletion or return of data, and the provider’s obligations to assist the customer with GDPR compliance.

What about joint controllership?

AI projects can also involve more complex cooperation between providers and customers. If both parties jointly decide why and how personal data is processed, they may be considered joint controllers.

This may happen where an AI provider and customer collaborate on the development of a new AI solution and both have meaningful influence over the purpose, design, data selection or intended use of the application.

In such cases, the parties must clearly allocate their responsibilities under the GDPR, especially around transparency, data subject rights and compliance documentation.

Practical steps for companies using or providing AI tools

IMY’s guidance is a useful reminder that AI governance and GDPR compliance need to be assessed early, not after the AI application has already been deployed.

Organisations should:

Practical steps

What companies should do when using AI tools

IMY’s guidance is a useful reminder that AI governance and GDPR compliance should be assessed before AI applications are developed, fine-tuned or deployed.

01

Map AI-related processing activities

Identify where personal data is used in AI development, testing, fine-tuning, deployment or monitoring.

02

Define GDPR roles for each AI use case

Do not assume that the provider is always a processor. Assess who determines the purposes and means of processing.

03

Review vendor and customer contracts

Make sure data processing agreements, joint controller arrangements or controller-to-controller terms reflect the actual processing relationship.

04

Document AI systems in the RoPA

AI-related processing should be included in the organisation’s records of processing activities where personal data is involved.

05

Assess risks through DPIAs where needed

If AI processing is likely to create a high risk to individuals’ rights and freedoms, a Data Protection Impact Assessment should be carried out.

06

Clarify data use for product improvement

Vendors should be transparent about whether customer or user data is used to improve AI models or only processed for the customer’s own purposes.

07

Keep evidence of decision-making

Organisations should document why a particular role was chosen and how the parties’ responsibilities were assessed.

What this means for privacy teams

For privacy, legal and compliance teams, IMY’s report highlights an important point: AI compliance is not only about the technology. It is also about governance, accountability and documentation.

Before approving an AI vendor or launching an internal AI project, organisations should understand how personal data is used and who is responsible for that processing under the GDPR.

A simple “vendor equals processor” approach is no longer enough. In AI projects, the provider may be a controller, processor or joint controller depending on the facts.

How GDPR Register can help

GDPR Register helps organisations manage AI and GDPR compliance in one structured platform. Privacy teams can document AI-related processing activities, maintain vendor records, assess risks, manage DPIAs and keep accountability documentation up to date.

This makes it easier to understand where AI tools are used, what personal data is involved, who is responsible and what compliance steps are required.

As regulators continue to issue guidance on AI and data protection, organisations that already have clear records, vendor documentation and risk assessments will be better prepared to demonstrate GDPR accountability.

Tags:
case study
gdpr
gutenberg
interesting
PREVIOUS
EU–US data transfers under renewed scrutiny: what GDPR teams should review now
NEXT
EU Chat Control Vote: What Message Scanning Means for Privacy