GDPR and AI for SMEs: the questions you actually have

It depends on which data, which tool, and which legal basis. Pasting personal data (names, emails, contract content, health or financial data) into an AI tool means disclosing it to a third-party provider: that provider effectively becomes an entity processing that data, and you remain accountable for it to the data subjects.

With free consumer plans your inputs may be used to train the models and you have no adequate contractual guarantees: there, the practical rule is not to enter personal or confidential data. With business/enterprise plans that exclude training and offer a data processing agreement, things become manageable — but it still needs to be assessed case by case.

GiBSeS — Distinguishing 'which data, which tool, which contractual protection' is exactly the first filter we apply when helping an SME use AI without exposing itself.

The GDPR (Regulation (EU) 2016/679, in force since 25 May 2018) essentially asks you three things: know what personal data you process and why, process it only for clear purposes and with a valid legal basis, and protect it in a way proportionate to the risks. It isn't a one-off exercise: it's a way of working that you must be able to demonstrate (the accountability principle).

For an SME this translates into a handful of living documents: a record of processing activities, privacy notices, agreements with suppliers, security measures. It doesn't take endless bureaucracy — it takes consistency between what you declare and what you actually do.

GiBSeS — If you're not sure what already exists and what's missing, mapping the real state of things is the starting point we work from.

The legal basis is the lawful reason you're allowed to process a piece of personal data: without at least one, the processing is unlawful. Article 6 of the GDPR sets out six of them, including consent, performance of a contract, legal obligation, and legitimate interest. For an SME, most day-to-day processing (handling an order, issuing an invoice, replying to a customer) rests on contract or legal obligation, not consent.

Consent is mainly needed for things like unsolicited marketing or profiling, and it must be freely given, specific, and revocable. Be careful: you can't switch legal basis at will once your original choice becomes inconvenient.

GiBSeS — Assigning the correct legal basis to each processing activity is one of the first things we sort out in a GDPR diagnosis.

Yes. The principle of data minimisation says you may only collect data that is adequate, relevant, and limited to what's necessary for the stated purpose. If you collect data 'just in case', you're already breaching the principle. Purpose limitation applies too: data collected for one purpose can't be reused for an incompatible purpose without a new legal basis.

For an SME, minimisation is also a convenience: the less data you collect and keep, the less risk you carry in the event of a breach and the lower your management costs. Keeping everything forever is almost always a liability, not an asset.

GiBSeS — Reducing the data you process and setting sensible retention periods is the kind of simplification we bring even outside of compliance work.

A DPIA (data protection impact assessment, Article 35) is mandatory whenever processing is likely to result in a high risk to people's rights and freedoms. The Regulation explicitly names three cases: systematic evaluation based on profiling with significant effects, large-scale processing of special categories of data (e.g. health data), and systematic monitoring of public areas.

National authorities publish additional lists of processing operations that require a DPIA, so also check the list issued by your reference authority. When AI comes into play with profiling, scoring, or decisions about people, a DPIA very often becomes necessary.

GiBSeS — Working out whether an AI project triggers the DPIA requirement, before you start, is exactly the risk/benefit analysis we never skip.

Yes, quite a lot changes. Automated profiling and scoring are among the most sensitive types of processing: they increase the likelihood that a DPIA is needed and require enhanced transparency towards data subjects, who have the right to know they are being profiled and the general logic involved. If the score produces significant effects (e.g. refusal of a service), Article 22 on automated decision-making also comes into play.

On top of that, an AI system of this kind may also fall under the AI Act as a high-risk system, with additional obligations. GDPR and the AI Act overlap here and need to be read together.

GiBSeS — Making the GDPR obligation and the AI Act obligation talk to each other on the same system is the kind of integrated reading we do to avoid duplication or gaps.

Not automatically, but you need a valid basis for the transfer. Transferring personal data outside the European Economic Area is allowed only with adequate safeguards: a European Commission adequacy decision, the Standard Contractual Clauses (SCCs), Binding Corporate Rules, or a handful of other exceptions. For the US, the Data Privacy Framework has existed since 2023: if your provider has joined it, the transfer to that entity is covered.

If the provider isn't certified, you need SCCs accompanied by an assessment of the actual risks (a legacy of the Schrems II ruling). The practical point is: it's not enough to 'use a US tool' — you need to know which safeguard covers it.

GiBSeS — Checking which transfer safeguard each cloud/AI provider relies on is a control we build into tool selection by default.

SCCs are contractual templates approved by the European Commission that a data exporter and a data importer sign to guarantee an adequate level of protection when data leaves the EU for countries without an adequacy decision. They're one of the tools most used by SMEs precisely because they're standardised.

After the Schrems II ruling, they're no longer sufficient on their own: they must be accompanied by an assessment (a transfer impact assessment) checking whether the destination country's laws could still allow access to the data that would undermine the safeguards. Many providers already include them in their contracts, but the responsibility to check them remains yours.

GiBSeS — Actually reading the transfer clauses in supplier contracts, instead of taking them on faith, is part of how we reduce lock-in and risk.

Almost always, you are the controller (you decide the purposes and means) and the provider is the processor (it processes data on your behalf). This means the main responsibility towards customers and authorities remains yours, even though the provider physically handles the data. You can't 'offload' compliance by saying the tool was in charge of it.

That's why Article 28 requires a specific contract, the data processing agreement (DPA), which sets out what the provider can and cannot do with the data. Without a DPA, entrusting data to a provider is itself a breach.

GiBSeS — Checking that every provider has a signed, sensible DPA is one of the concrete checks we carry out before adopting any tool.

The DPA (Data Processing Agreement) is the contract required by Article 28 that you must have with every supplier that processes personal data on your behalf: cloud services, business software, email marketing, AI tools, even your accountant in certain cases. It sets out the subject matter, duration, purpose, types of data, security obligations, use of sub-processors, and what happens at the end of the relationship.

Most serious providers make a standard DPA available for you to accept online. Your job is to check it exists and is consistent, and to keep it on file: in the event of an audit or a breach, it's one of the first documents you'll be asked for.

GiBSeS — Keeping an inventory of suppliers with their corresponding DPAs is one of those tidy foundations that makes every future audit much faster.

Data subjects have a set of rights you must be able to satisfy: access to their own data, rectification, erasure (the so-called right to be forgotten), restriction, portability, and objection. As a rule you must respond within one month of the request, free of charge except in excessive or repetitive cases.

For an SME, the practical problem isn't so much the right itself as being organised enough to respond: knowing where a person's data lives and being able to extract or delete it quickly. If the data is scattered across ten different tools with no map, every request turns into a small nightmare.

GiBSeS — Knowing at any moment where a customer's data lives is also a matter of operational order, not just law: it's one of the positive side effects of good data mapping.

Article 22 establishes that a person has the right not to be subject to a decision based solely on automated processing when it produces legal effects concerning them or significantly affects them (e.g. granting credit, hiring, refusing a service). There are exceptions, for instance when the decision is necessary for a contract or based on explicit consent.

Even within the exceptions, you still have to guarantee safeguards: clear information, the possibility of obtaining human intervention, of expressing one's point of view, and of contesting the decision. In practice: AI can support the decision, but a human must be able to intervene in a real, not symbolic, way.

GiBSeS — Designing the points where a human intervenes on the AI's output, so that it's meaningful rather than a formality, is part of how we integrate AI in a defensible way.

If you suffer a breach that poses a risk to people's rights, you must notify the supervisory authority without undue delay and in any case within 72 hours of becoming aware of it. If the risk to data subjects is high, you must also inform them directly. Not every breach needs to be notified, but every breach needs to be assessed and logged internally.

The 72 hours go by fast: that's why it pays to have a minimal procedure ready in advance (who assesses, who decides, what gets communicated) instead of improvising in a panic. A well-handled breach weighs far less than one that's hidden or mishandled.

GiBSeS — Preparing an incident-response procedure before you need it is one of the highest-return interventions we recommend to SMEs.

The GDPR sets out two tiers of administrative fines. For less serious violations (e.g. missing records or DPAs), fines go up to 10 million euros or 2% of worldwide annual turnover, whichever is higher. For more serious violations (basic principles, legal bases, data subjects' rights, unlawful transfers), fines go up to 20 million euros or 4% of turnover.

In practice, for an SME, fines are calibrated to the severity, the cooperation shown, and the measures taken: authorities rarely start at the maximum. But beyond the fine itself, reputational damage and civil compensation claims matter too, and they often weigh more than the penalty.

GiBSeS — The goal isn't fear of the fine but the peace of mind of being able to show you did things properly: that's the discipline we bring to projects.

Yes, they're two different regulations that can apply at the same time. The GDPR protects personal data: it applies whenever you process information relating to identifiable people. The AI Act regulates AI systems based on their risk level, regardless of whether they process personal data or not. An AI system that profiles customers falls under both.

Where they overlap, the obligations add up but shouldn't be duplicated: a good DPIA and the documentation required by the AI Act can partly feed into each other. The risk, for an SME, is treating them as two separate worlds and doing the same work twice, uncoordinated.

GiBSeS — Reading the GDPR and the AI Act as a single framework, avoiding duplication, is exactly the kind of simplification we work on with the AI Act Academy.

On-premise — or more broadly, AI and systems hosted on infrastructure you control — removes several problems at the root: no extra-EU transfers, no input fed into third-party models, direct control over who has access. It's a strong data sovereignty strategy, especially for sensitive or strategic data. It doesn't, however, exempt you from the rest of the GDPR: legal bases, minimisation, data subjects' rights, and security remain your obligations.

It's also worth saying that on-premise means more operational responsibility (updates, backups, physical security). It isn't the answer to everything: it's the right choice when the data justifies it, weighed with a cost/benefit analysis.

GiBSeS — Deciding case by case between cloud and on-premise based on the real value of the data, not fashion, is at the heart of our vendor-independent approach.

The GDPR rests on the accountability principle: being compliant isn't enough, you must be able to prove it. In practice that means having tidy, up-to-date documentation: a record of processing activities, privacy notices, DPAs with suppliers, any DPIAs, a log of breaches, and a trace of data subjects' requests. A clear audit trail turns an inspection from a nightmare into a formality.

When AI tools come into the picture, traceability becomes even more useful: knowing which data was used, with which tool, for which decision. It's the difference between 'trust us' and 'here, see for yourself'.

GiBSeS — Building the audit trail while adopting AI, rather than after the fact, is how we integrate tools: traceable by design.

Yes, but it's one of the most sensitive areas. Employee and candidate data is personal data in every sense, and the employment relationship makes it hard to rely on consent (which must be freely given — complicated when there's a subordination relationship). Automated CV screening, evaluations, or AI-based monitoring often touch on Article 22 and may require a DPIA.

Several countries also have national employment laws layered on top of the GDPR (for instance on remote monitoring of staff). Before automating recruitment or evaluation, it's worth checking both the privacy angle and the employment-law angle.

GiBSeS — Assessing the privacy angle and the employment-law angle together before automating HR is the kind of 360-degree analysis we do before greenlighting a project.

If your website uses cookies or similar technologies that aren't strictly necessary (analytics, advertising tracking, social media pixels), you need the user's prior consent, collected through a banner that lets them accept, refuse, and choose in an equally easy way. Technical cookies necessary for the site to function don't require consent. For email marketing to non-customers you generally need consent; for existing customers, the so-called soft opt-in can apply, within limits.

Watch out for tools like Google Analytics or services with servers outside the EU: here the privacy issue and the transfer issue become intertwined. An 'accept all' banner with no real option to refuse is not compliant.

GiBSeS — Putting order back into cookies, consents, and tracking tools is often the first visible quick win of a GDPR diagnosis.

Not every SME is required to. A DPO is mandatory in three cases: if you're a public authority, if your core activity consists of regular and systematic monitoring on a large scale, or if you process special categories of data (health, opinions, etc.) on a large scale. Many small businesses fall outside these cases and have no obligation.

Even without an obligation, though, someone needs to handle this competently: you can appoint an internal point of contact or rely on external support. No obligation doesn't mean no responsibility.

GiBSeS — Working out whether you actually need a DPO or just a lighter arrangement is one of the first questions we clarify, without selling you structure you don't need.

The GDPR doesn't set a single number: the storage limitation principle applies, meaning you keep data only for as long as needed for the purpose, then delete or anonymise it. Some retention periods are set by law (for instance, accounting and tax records have mandatory retention periods that vary by country), others you set yourself, with justification.

Good practice is to define a retention period and a mechanism to enforce it for each category of data. 'We keep it forever' isn't a policy — it's accumulated risk that will come back to bite you sooner or later.

GiBSeS — Setting realistic retention periods per data category is one of those simple rules that cuts both risk and clutter at the same time.

The first step isn't buying software or writing pages of policy: it's taking an honest snapshot of what you process today. What personal data you collect, where it ends up, which tools and suppliers touch it, and on what legal basis. That map immediately reveals the real priorities (often just 3-4 concrete things), and you stop worrying about problems you don't actually have.

From there, you build the rest proportionately: high risks first, then documentation, then continuous improvement. Perfect compliance on the first try doesn't exist; a correct, demonstrable direction does.

GiBSeS — That initial snapshot, with the real priorities, is exactly the diagnosis we start with for every SME: half an hour to understand where you stand before moving anything.

Yes, it can apply even if you have no establishment in the Union. Article 3(2) of the GDPR extends the Regulation to non-EU companies in two cases: when you offer goods or services to people located in the EU (even for free), or when you monitor their behaviour (e.g. online tracking, profiling, analytics).

Your nationality doesn't matter, nor does where your servers are: what matters is that you deliberately target data subjects located in the Union's territory. The mere fact that a European reaches your website isn't enough, but if you price in euros, ship to the EU, have a version in a European language, or run targeted campaigns, then you fall within scope.

GiBSeS — GiBSeS helps you work out, before you launch in Europe, whether and to what extent the GDPR really concerns you.

The test isn't the mere accessibility of the website, but a clear intention to target the EU market. The clues authorities look at: prices in euros or in the currencies of member states, shipping or delivery to EU countries, one or more European languages other than your own country's, references to European customers, an EU national domain, geo-targeted advertising aimed at Europe.

If, on the other hand, your site is only in English, prices in dollars, and you don't deliver to Europe, an occasional EU customer who buys on their own initiative doesn't automatically bring you into scope. It's a case-by-case assessment, and it's worth documenting.

GiBSeS — GiBSeS analyses your sales model to establish, in a defensible way, whether you're 'targeting' the European market.

If you fall under Article 3(2) — that is, you offer goods/services or monitor the behaviour of people in the EU — then generally yes: Article 27 of the GDPR requires you to designate a representative in the Union in writing. It's not just a mailing address: it's an entity (a natural or legal person) established in one of the member states where your data subjects are located, acting as a point of contact for supervisory authorities and users.

The representative must be named in your privacy notice and must keep (or make available) the record of processing activities. Be careful: appointing a representative doesn't relieve you of your responsibilities as controller, but not having one is itself a sanctionable breach.

GiBSeS — GiBSeS can guide you in choosing and setting up your EU representative, so a formal requirement doesn't turn into a risk.

The exemption under Article 27 doesn't depend on your size, but on the nature of the processing. You're exempt from appointing a representative if the processing is occasional, doesn't include large-scale processing of special categories of data (health, biometric data, opinions, etc.) or data relating to criminal convictions, and is unlikely to result in a risk to data subjects' rights. Public authorities are also exempt.

In practice, many non-EU SMEs that sell into Europe on an ongoing basis do NOT fall within the exemption, precisely because the processing isn't 'occasional'. Misjudging this point is one of the most common mistakes.

GiBSeS — GiBSeS helps you properly document whether you can rely on the exemption or whether it's still worth designating a representative.

Yes, but transferring it to a country outside the European Economic Area requires a legal basis under Article 44 and following. The three main routes: (1) a European Commission adequacy decision, if your country is recognised as 'adequate'; (2) the Standard Contractual Clauses (SCCs), the most widely used solution for countries without adequacy; (3) specific safeguards such as Binding Corporate Rules (BCRs) for corporate groups.

With SCCs you may also need a transfer impact assessment and additional technical measures, such as encryption. It's not enough to 'move' the data: you need to be able to show a level of protection substantially equivalent to the EU's.

GiBSeS — GiBSeS sets up, together with you, the transfer mechanism best suited to your country, without unnecessarily weighing down your data flows.

Partly. Since July 2023 there's an adequacy decision for the United States based on the EU-US Data Privacy Framework: US companies that self-certify and appear on the relevant list can receive personal data from the EU without needing SCCs for those flows.

Two caveats. First: adequacy only holds if you actually certify and comply with the Framework's commitments; if you're not certified, you still need another mechanism (typically SCCs). Second: like the earlier agreements, the Framework could be challenged in court, so many companies keep SCCs in place as a safety net.

GiBSeS — GiBSeS helps you decide whether to rely on the Framework, on SCCs, or on a combined approach, factoring in stability over time.

Under the GDPR, accountability follows the roles around the data, not the product's commercial chain. Whoever decides the purposes and means of processing is the 'controller' and answers first; whoever processes data on a controller's behalf is the 'processor'. If you collect European users' data yourself directly (accounts, orders, tracking), you are the controller, regardless of where you're based.

An EU distributor or partner is responsible for its own processing, not for yours. If, instead, a supplier processes data for you, you'll need an Article 28 agreement (DPA) that allocates the obligations. Be careful not to confuse the GDPR role with the 'importer' role under other EU product regulations.

GiBSeS — GiBSeS maps the data flows of your European operation and clarifies who's controller, who's processor, and which contracts you need to be covered.

If your European customers entrust you with personal data belonging to their users or employees, you're generally a 'processor' on their behalf. This requires signing an Article 28 agreement (Data Processing Agreement) that imposes security, confidentiality, authorised sub-processors, assistance to the controller, and return/deletion of data at the end of the relationship.

Moreover, since you receive the data outside the EU, you're also an 'importer' for international transfer purposes and will need to sign SCCs in the appropriate module (controller-to-processor). Many deals and negotiations with EU customers stall precisely because the non-EU supplier doesn't have a DPA and SCCs ready.

GiBSeS — GiBSeS prepares the DPA + SCC package with you that European customers will ask for, so you don't lose contracts over a formal technicality.

GDPR fines are among the highest in EU law: up to 20 million euros or, if higher, 4% of the group's worldwide annual turnover for the most serious violations (up to 10 million or 2% for others). Supervisory authorities can also impose limitations or the suspension of processing and data transfers, which can effectively shut down your European operations.

On top of that come reputational damage, user complaints, and the risk that European B2B customers exclude you because you can't provide compliance guarantees. The GDPR doesn't 'stop goods' at customs the way a product regulation does, but it can turn off the data tap that your business runs on.

GiBSeS — GiBSeS helps you size the real risk for your case and secure your data assets before they become a problem.

Yes, 'monitoring the behaviour' of data subjects located in the EU is one of the two gateways under Article 3(2), entirely independent of any sales activity. This covers profiling cookies, advertising pixels, retargeting, analytics that reconstruct habits or preferences, and fingerprinting.

If you track European users, the 'ePrivacy' rules on cookies apply as well as the GDPR, and they generally require prior consent before installing tools that aren't strictly necessary. So you need a compliant banner, a privacy notice, and, where applicable, an EU representative and a basis for any transfers of the data collected.

GiBSeS — GiBSeS reviews your tracking stack and shows you where to act to stay in the EU market without giving up the data you actually need.

An orderly path cuts costs and surprises. In short: (1) check whether and how Article 3 involves you; (2) map the personal data you collect on EU users and its flows to your country; (3) define the legal bases and prepare a privacy notice and record of processing activities; (4) assess the Article 27 EU representative requirement; (5) sort out international transfers (adequacy, DPF, or SCCs); (6) align contracts with suppliers and customers (DPAs) and your security measures.

There's no need to do it all at once: it's worth starting with the points that block market access (representative, transfers, B2B contracts) and then consolidating the rest.

GiBSeS — GiBSeS, as an independent advisor, builds a compliance roadmap tailored to entering the EU without tying you to a single supplier or oversized solutions.

Unfortunately, no. Being in order with regulations like California's CCPA/CPRA, Canada's PIPEDA, Brazil's LGPD, or various Asian laws isn't equivalent to being GDPR-compliant: definitions, legal bases, data subjects' rights, documentation obligations, and transfer rules all differ. Some principles are similar, but the gaps are often exactly where the GDPR is stricter (consent, EU representative, international transfers).

The good news is that most of the work already done — data inventory, security measures, procedures for handling user requests — can be reused and needs to be 'adapted' to the GDPR, not rebuilt from scratch.

GiBSeS — GiBSeS starts from the compliance you already have and closes only the gap you need to operate in Europe, avoiding duplicated effort.