GDPR and artificial intelligence in the company

When an Italian company introduces AI, the first regulatory problem it encounters It's not the AI Act: it's the GDPR. It has been in place for years, applies to everyone, and concerns whenever in the content you feed to a system there are data referring to people.

The underlying difference is this: the AI Act regulates the system as a product, the GDPR regulates data processing. An AI project that touches personal data must respect both, and in the practice of SMEs the second bites sooner and more often.

When the GDPR comes into play

That's all it takes. There's no need for a profiling system: as long as a document contains a name and an email.

• Summarize emails from customers with an assistant → personal data
• Have a contact list analyzed → personal data
• Transcribe a meeting with names and opinions → personal data
• Generating responses from a customer's history → personal data
• Have a standard or technical manual summarized → normally no personal data

Only the last case is outside the perimeter. All the others, which are also the most common in the company, fall in full.

The four questions to solve before leaving

1. On what legal basis do I process this data? Consensus is hardly ever the best choice in business: it is revocable and complicates management. In most cases, you work on contract execution or legitimate interest, and in the latter case you need a balance assessment put in writing.

2. Who is the provider with respect to the data? If an AI service processes data on your behalf, it is normally responsible for the processing and serves an agreement under Article 28. Many suppliers make it available: it must be searched, read and stored.

3. Where do the data end up? Many AI tools have infrastructure outside the Union. Transfer is possible but needs to be regulated with the tools provided and documented.

4. Are data used to train models? It is the question that changes everything and that is often not asked. Conditions vary between consumer plans and business plans of the same supplier.

Automated decisions: where GDPR and AI Act overlap

The GDPR places limits on decisions based solely on automated processing that produce legal effects on the person or affect them in a similar way. In those cases, the person has the right to human intervention, to express his or her position and to contest the decision.

It is exactly the territory that the AI Act classifies as high risk, explained in the four levels of risk. The two norms come to the same point from different directions.

Practical examples

Studio accountant summarizing client documents. Processing of personal data, often also of delicate categories. It is necessary to verify the legal basis, the agreement with the supplier, where the data resides and if they are used for training. It is not an obstacle: it is an hour of verification that must be done once.

E-commerce that uses AI to respond to customers. The assistant accesses the order history. The provider is responsible for the processing, the information must be updated with the new category of recipients, and it must be decided what the assistant can see: it rarely takes the entire history to respond on yesterday's shipment.

Company that evaluates employees with AI support. Here are added all the protections: decision that affects the person, worker data, labour law. It is the case that an opinion is needed, not a guide.

Workshop using an assistant for technical quotes. If there is no identifiable person data in the texts, the GDPR does not enter. It is the simplest case, and is more frequent than is believed.

Minimization: giving the system only what it takes

It is the principle of the GDPR that in AI projects is ignored most often, and it is also the one that solves the most problems at no cost.

The temptation, when building an assistant, is to give him access to everything: the entire order history, the complete registry, the documentary archive. Seems like the choice that produces better answers. Almost always it is not, and in addition it multiplies the risk.

The left column reduces risk, simplifies the legal basis, and in practice It also produces more precise answers, because the system works on a clean context instead of a sea of irrelevant data. It is the same principle that governs the quality of an AI document system, explained in RAG: what is it and in AI for the business knowledge base.

Questions to ask the supplier, in order

When evaluating an AI service from a GDPR perspective, the sequence counts:

1. Where is the data processed? If they stay in the Union, one less problem.
2. Are the contents used to train? It is the substantial difference between the plans.
3. Do you make the agreement available under Rule 28? If the answer is confusing, it is a signal.
4. How long do you keep the content? And what happens when the contract is terminated?
5. Who, on your side, can access the data? And with what controls?
6. How to handle requests from interested parties What do they get to us?

For cases where none of these answers are satisfactory there is an alternative way: keep the processing within the company perimeter, with Local AI Models or open source models. It costs more in infrastructure and expertise, but on particularly sensitive data it is often the only way forward — and should be assessed at first, not after building everything on an external service.

Mistakes to Avoid

• To think that "so much is corporate data". The name and email of a business contact person are personal data.
• Not signing the agreement with the supplier. It is a formal fulfillment but it is the first one that is asked in a verification.
• Ignoring the training issue. It is the substantial difference between one plan and the other.
• Not updating the privacy notice. New provider processing customer data = change to communicate.
• Leaving the use unadjusted. It's the number one risk: not the business system, but the collaborator who pastes a file into a personal tool — see Business Data and AI.

How to apply it in the company

1. Map what AI streams touch personal data. Often they are less than they seem.
2. For each one it identifies the Legal Basis and put it in writing.
3. Recover and store the Agreements with suppliers.
4. Verification where they reside data and whether transfer tools are needed.
5. Update information and record of treatments.
6. Write a internal policy that says what should never be glued elsewhere — see corporate policy on the use of AI.
7. Evaluate if you need one DPIA: rarely for internal assistants, almost always for systems that evaluate people.

The last point on the list is the one that protects the most with equal effort. Most accidents in SMEs do not arise from a poorly designed system, but from unregulated individual use.

Since this is a subject with guidelines from the evolving authorities, Always check official sources and be assisted when the processing concerns workers or special categories of data.

Conclusion

GDPR doesn't stop you from using AI: it asks you to know what you're doing with people's data. Legal basis, agreement with the supplier, place of conservation, use for training, updated information. Five things, once, and the project starts quiet.

The most expensive mistake is not technical but organizational: let everyone use the tool they prefer with the data that happens. A two-page policy is worth more than any certification.

AI becomes useful when it enters processes. Giallo Studio helps SMEs and teams build concrete, measurable and sustainable automations — including from a data point of view.