A product advisor in the shop, a draft reply for the support inbox, an automatic classification of incoming returns: such AI features are built in a few days as long as a model is addressed through an external interface. Building them is the smaller question. The larger one is which order, account and message data leave the house, who processes them afterwards, and what of that has to appear in contracts, records and subject access responses. This article draws the data boundary: what a prompt actually contains, which operating models are available, what the European Data Protection Board and the German Federal Office for Information Security expect from the deploying company, what can still flow out even on your own hardware - and at what level of use running the model yourself pays off.
What an AI feature can carry out of the shop
A prompt looks like a search box and behaves like a data export. For a product advisor to give a usable answer, it usually receives more than the visitor's question: the basket, the last orders, the customer group, sometimes the name from the account. A drafting assistant for the support inbox receives the customer's complete message including signature, order number and reason for complaint. A returns classifier receives the free text someone wrote into the return form. Each of these fields is personal data as soon as it hangs on an identifier - and the application usually supplies that identifier along with it, so that the answer can be matched to the right case.
The difference from the rest of the interface landscape lies in the vagueness. A payment service receives defined fields in a fixed format; what it sees is written in the documentation. A language model receives running text, and running text carries along whatever happens to sit next to it: the address line from the signature, the account number in the complaint, the health-related note in the reason for return. Anyone who does not assemble and limit the prompt themselves does not know which categories of personal data they are transmitting. Yet that is exactly the detail every record, every impact assessment and every question from a supervisory authority asks for.
- Basket and order history: they are what make the answer usable in the first place, and at the same time they are the fields with the longest retention in the shop.
- Free text from forms: complaint, reason for return, comment on the delivery - experience shows that this is where the details nobody planned for end up.
- The signature of an email: name, postal address, phone number and job title travel along when the message goes into the prompt unchanged.
- Internal rules in the system prompt: discount limits, goodwill tiers, supplier conditions. The Federal Office for Information Security states that no sensitive data may be integrated into system prompts (BSI).
- The identifier itself: a customer number or session identifier turns arbitrary text into personal data, even when no name appears in it.
As soon as a prompt contains personal data, sending it to a model is a processing operation with a recipient - with a legal basis, purpose limitation, a retention period and an entry in the record of processing activities under Article 30 GDPR. That holds regardless of whether the recipient stores the input; the transmission itself is the operation, not only the storage. Skipping this classification produces a feature that runs technically and is empty in the documentation.
Three operating models, three data paths
Between an external interface and your own hardware sits an intermediate step that is chosen most often in practice: a model operated by a processor in a data centre inside the European Union. The models differ less in functionality than in contractual effort and in the number of places an input passes through. The Federal Office for Information Security describes local operation as running an AI model under your own responsibility on your own hardware (BSI). That description is the benchmark against which the other models can be measured - not the question of which model is used, but the question of where it computes.
| Operating model | What leaves the operation | Contractual basis | Typical effort |
|---|---|---|---|
| External interface, terms of use only | prompt and answer per request, often with an identifier | the provider's terms | low to build, high to document |
| Processing in an EU data centre | prompt and answer, but bound by instructions | contract under Article 28 GDPR | medium to build and document |
| Own operation on own hardware | nothing in regular operation; model versions come in | no additional processing arrangement | high to set up, low to document |
| Computation on the visitor's device | nothing; the computation runs in the browser | no additional processing arrangement | depends on the model size |
The third row is the subject of this article, the fourth a special case for small models that compute on the visitor's device. What matters in the table is the second column: it describes not what is stored but what is transmitted. An assurance not to use inputs for further training does not change the fact that the input reached the recipient. The Federal Office for Information Security names exactly this point as a risk: besides the unwanted outflow during transmission, there is the possibility that the operating company accesses the data and, where applicable, uses it for further training of the model (BSI).
What supervisory authorities expect from the deploying company
The European Data Protection Board adopted Opinion 28/2024 on 17 December 2024 (EDPB) and answered three questions in it that count directly for use in a shop: when a model can be regarded as anonymous, when legitimate interests carry as a legal basis, and what applies when a model was developed using unlawfully processed data. The first answer is strict. Anonymity is not a state a provider can declare, but the result of an assessment that looks at two likelihoods at the same time.
For an AI model to be considered anonymous, both (1) the likelihood of direct (including probabilistic) extraction of personal data regarding individuals whose personal data were used to develop the model and (2) the likelihood of obtaining, intentionally or not, such personal data from queries, should be insignificant, taking into account ‘all the means reasonably likely to be used’ by the controller or another person.
European Data Protection Board, Opinion 28/2024, executive summary
For the legal basis, the opinion requires a documented three-step assessment: a legitimate interest, the necessity of the processing for that interest, and a balancing test in which the interests and fundamental rights of the data subjects do not override it (EDPB). The three conditions have to be met cumulatively - and, this is the part that gets lost in everyday work, assessed and recorded beforehand. A balancing test that only comes into existence when a supervisory authority asks does not satisfy the accountability duty in Article 5(2) GDPR, because that provision requires the controller to be able to demonstrate compliance (GDPR).
The third answer hits the operator most directly. Anyone deploying an external model must have ascertained, in an appropriate manner, that no unlawfully processed personal data were used for its development (EDPB). This duty cannot be passed on to the provider; it belongs to your own accountability. In practice that means the origin of the training data, the model card and known procedures belong in the file before the feature goes live - and in a form that is still comprehensible a year later.
The statement that a model stores nothing is not an anonymity assessment. The benchmark set by the European Data Protection Board requires that both the direct extraction of training data and the obtaining of such data through queries be insignificant for any data subject - both at once, per person, not on average. For a purchased model this is hard to demonstrate from the outside. For your own application layer it is not: what does not enter the prompt in the first place cannot come back out of an answer.
The stack of paperwork an AI feature triggers
An AI feature is rarely a processing activity of its own. It hangs off an existing one - order handling, customer account, support - and changes it by one recipient and one purpose. Those are exactly the two details the record under Article 30(1) GDPR asks for, which among other things lists the purposes of the processing and the categories of recipients to whom the personal data have been disclosed (GDPR). An entry carrying the name of the feature but no recipient and no legal basis is not an entry, it is a note.
- Record of processing activities (Article 30 GDPR): purpose, data categories, recipients, retention periods - kept per feature, not per tool.
- Data processing agreement (Article 28 GDPR): it binds the processor to process personal data only on documented instructions from the controller (GDPR). For a model you run yourself, this contract falls away.
- Data protection impact assessment (Article 35 GDPR): due where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons (GDPR).
- Technical and organisational measures (Article 32 GDPR): the measures include, among other things, the pseudonymisation and encryption of personal data (GDPR); access separation and logging come on top - for the model layer as for any other application.
- Third country assessment (Article 44 GDPR): only needed when data leave the legal area - any transfer of personal data to a third country or an international organisation is permitted only where the controller and the processor comply with the conditions of that chapter (GDPR). In your own operation the question falls away instead of being answered.
So the effort shifts, it does not disappear. With external procurement it sits in contracts, assessments and recurring re-checks; with your own operation it sits in hardware, updates and operational security. Which side is more comfortable depends on what a company already runs. Anyone who already looks after their own servers for the shop has built half of the second path already: network separation, backups, monitoring and an access concept are in place and only need to be extended by one more service.
Running it yourself: what that means technically
Running a model yourself does not mean training it yourself. It means executing an existing, openly available model on your own hardware and building the application layer around it yourself. The Federal Office for Information Security separates the cases cleanly: local operation is operation under your own responsibility on your own hardware, externally provided means a model whose provider is someone else (BSI). Both cases can concern the same model. The difference lies not in the model but in the place of computation - and therefore in how many places an input passes through.
The hardware question can be calculated, but it is often asked too late. The Federal Office for Information Security lists it in its catalogue of measures as a selection criterion of its own and asks explicitly which computing and storage capacities may be necessary for in-house operation (BSI). For the features a shop typically needs - draft replies, classification, summarisation, product texts - experience shows that smaller models are enough, models that get by with a single accelerator card. For open advisory dialogues in several languages the demand rises considerably. This distinction decides the economics, not the question of principle.
# Limits of the application layer: what may leave the operation
service:
name: product_advisor
model:
location: own_data_centre # no outbound call
endpoint: http://10.20.0.14:8080/v1/completions
input:
fields_allowed: [article_number, category, question_text]
fields_blocked: [customer_number, email, address, payment_method]
max_characters: 4000
logging:
store: metadata # time, duration, model version, hit count
content: no # no prompt, no answer in the log
retention_days: 30
network:
outbound: deny # default rule of the service account
exceptions: [10.20.0.14]The configuration above is the actual data protection at this point. It is not the model that decides what it sees but the application layer in front of it: it assembles the prompt from permitted fields, rejects blocked fields, limits the length and logs metrics instead of content. A block list at this point can be demonstrated; a note in a manual cannot. The same separation also works against manipulated inputs - the route to that is described in detail in the article on prompt injection in shop features.
Model layer
A service on your own hardware, reachable only from the internal network, without any outbound connection. Model versions are installed on a plan, not fetched continuously.
Application layer
It builds the prompt from an allow list, strips identifiers and shortens free text. This is the only place where a data boundary can be enforced technically.
Logging
Time, duration, model version and hit count are enough for operations. Prompt and answer in the log create a second copy of the same personal data with its own retention period.
Deletion path
Access requests and deletions have to reach inputs, outputs and caches. Anyone who builds that path only when the first request arrives builds it against a deadline.
What can still flow out even in your own operation
Your own hardware is a boundary, not a lid. There are three routes by which data still leave the operation, and all three have occurred in projects that were otherwise carefully built. The first is the telemetry of a library that checks a version at start-up and sends identifiers along with it. The second is a tool call: as soon as a model is allowed to trigger a search, a translation or a lookup, the content of the request can sit inside that call. The third is the logging chain of application, upstream server and error service, in which a prompt ends up although the model service itself stores nothing.
- Deny outbound connections for the service account and name the exceptions individually. A rule that permits the model server alone is written in minutes and checked in one.
- Assess tool calls separately: every function the model is allowed to trigger is a recipient of its own in the record - even when it sits in the same house.
- Lower the log levels before the feature goes live. A debug log with complete requests is the most common unnoticed second copy.
- Check crash reports: such a report often contains the last input buffer. If it leaves the house, the prompt leaves with it.
- Think of backups: what sits in a backup is subject to the same retention period as the original - the method for that is described in the article on the deletion concept and retention periods.
Together these three measurements take less than a minute and replace an assumption with a finding: no route to the outside, only internal connections to the model service, no prompt content in the log. The order matters - first set the rule, then measure, then take the measurement into the acceptance checklist. A block that nobody re-measures after a system change has, in our experience, quietly disappeared a few months later. Anyone who attaches the check to the deployment notices its loss on the same day instead of at the next review.
Deleting and correcting: the part that hurts later
As long as inputs and outputs are only processed and not reused, deletion is an ordinary task: find the records, apply the periods, take the logs along. It becomes difficult as soon as inputs flow into further training. In its guidance on AI systems, the conference of independent German data protection supervisory authorities states that a deletion has to be technically complete and also covers the model where the model contains the information to be deleted (DSK). The usual way out - a filter that no longer outputs the information - expressly does not suffice for that.
However, such mitigating measures, in particular filters, do not in themselves constitute deletion.
Conference of the independent data protection supervisory authorities of the German federation and states, guidance on AI systems, version 1.0 (translated from the German original)
From this follows an unspectacular but effective design decision: do not use inputs from the shop for further training as long as no robust deletion path exists for it. The feature loses little by that, because the benefit of a model that knows your own product texts usually comes from retrieval at runtime and not from the weights in the model. Anyone who separates the two - knowledge in retrieval, model unchanged - keeps deletability without giving up answer quality. For any planned further training, the data protection conference gives preference to local processing on the device in use (DSK).
An AI feature is rarely developed on the live system. The data extract that moves into the test environment for that purpose contains the same orders, messages and addresses - and is subject to the same duties, but often to weaker access rules. How a test environment can be set up without real customer data is described in the article on Shopware staging without customer data. As long as this step is missing, even the most careful data boundary in production covers only half the distance.
When running it yourself pays off
The spread of AI in European companies is growing fast and unevenly. According to the Eurostat survey, in 2025 19.95 percent of EU enterprises with ten or more employees used at least one AI technology, an increase of 6.47 percentage points on the previous year (Eurostat). The spread by size is marked: 17 percent among small, 30.36 percent among medium and 55.03 percent among large enterprises (Eurostat). The figures come from a sample of around 157 000 out of roughly 1.53 million enterprises in the EU (Eurostat) and therefore describe the market in which a shop makes its decision, not the German market alone.
More revealing than the adoption rate are the reasons against it. Among EU enterprises that have ever considered using AI, 70.89 percent named a lack of expertise, 52.52 percent named unclear legal consequences and 48.83 percent named concerns about violation of data protection and privacy (Eurostat). Two of the three most frequent obstacles are therefore not technical but questions of responsibility and evidence. This is exactly where running the model yourself helps - not because it is easier, but because it reduces the number of parties involved and with it the scope of what has to be checked.
- Volume: at a few hundred requests a month, your own accelerator card does not carry its cost. From steady continuous load the ratio typically reverses; the calculation is set out in the article on AI costs, token budgets and caching.
- Data categories: as soon as health, financial or employee data can appear in free text, the balance shifts markedly towards running the model yourself.
- Existing infrastructure: anyone with their own servers and an operations team mainly bears the hardware. Anyone starting from zero also bears building up operations.
- Response time: a model in your own network saves the trip outside. For short classifications that is noticeable; for long texts it barely matters.
- Evidence needs: anyone who regularly answers access requests or has to show business customers where data sits saves recurring checking work by running it themselves.
The order in which to introduce it
The most common cause of a failed introduction is not the technology but the order. Anyone starting with the choice of model decides the data boundary before knowing it. The workable order starts with the use case and ends with the model - which is also how the Federal Office for Information Security structures it in its criteria catalogue, which lists planning, procurement, adaptation, integration, use and termination as separate phases with requirements of their own (BSI).
- Define and limit the use case. One feature, one purpose, one user group. An assistant for everything can neither be scoped nor documented.
- Fix the fields. Which data fields may the prompt contain, which are blocked? This list is the data boundary and belongs before the first line of code.
- Choose the operating model. Only now is it decided whether your own hardware, a processor or the visitor's device does the computing.
- Write the documents before the feature goes live. Record entry, legal basis including the balancing test, impact assessment where applicable, retention periods.
- Make the boundary measurable. Block outbound connections, set log levels, put both into the acceptance checklist.
- Schedule the re-check. Model versions, libraries and log levels change; an annual review of the permitted use cases is the smallest sensible interval.
Together these six steps cost less time than the first round of rework after an access request. They also have a side effect that is hard to measure and easy to explain: an operation that answers the question of where its data sits in two sentences wins business customers faster than one that has to go and look first. We accompany this route from recording the use case to running the service on your own hardware - the building blocks are set out under AI solutions and cloud and infrastructure.
The adoption figures in this article come from the Eurostat statistics on the use of artificial intelligence in enterprises (data extracted December 2025, 2024 EU survey on ICT usage and e-commerce in enterprises, conducted in the first months of 2025, enterprises with ten or more employees). The data protection benchmarks follow Opinion 28/2024 of the European Data Protection Board of 17 December 2024, the General Data Protection Regulation in the version published via EUR-Lex, and the guidance on AI systems, version 1.0, issued by the conference of the independent data protection supervisory authorities of the German federation and states. The technical statements follow the publications of the German Federal Office for Information Security on generative AI models, version 2.0, and its criteria catalogue on integrating externally provided generative AI models, version 1.0. Percentages refer to the population stated in the respective source.
As a rule yes, as soon as the model is addressed through an external interface; the prompt is then a transmission, regardless of whether the recipient stores it. It is not inevitable, though. If the model runs on your own hardware, the request stays inside your own network, and small models even compute on the visitor's device. Which route works typically depends on the volume of requests, the data categories involved and the infrastructure already in place. A short conversation is usually enough to classify your own case, see contact.
It is the contractual minimum where a provider processes data on your behalf, because Article 28 GDPR requires among other things that it process personal data only on documented instructions. It replaces neither the legal basis for the processing nor the step of ascertaining that the model was not developed using unlawfully processed data; under the opinion of the European Data Protection Board that assessment stays with the deploying controller. Experience shows that the contract is the fastest part of the project and the documentation the slowest.
That depends heavily on the task. For classification, summarisation and draft replies, smaller models are typically enough, models that get by with a single accelerator card and moderate memory. Open advisory dialogues in several languages need considerably more. The Federal Office for Information Security lists the question of the computing and storage capacities needed for in-house operation explicitly as a selection criterion. It makes sense to measure the demand against the actual request profile rather than derive it from the model size.
Technically yes, in terms of evidence only with considerable effort. The German data protection conference states that a deletion also has to cover the model where the model contains the information to be deleted, and that mitigating measures such as filters do not in themselves constitute deletion. As a rule it is cheaper to fetch the knowledge at runtime from a data source of your own and leave the model unchanged. Answer quality usually does not suffer from that, and deletability is preserved.
Through three measurements that belong in the acceptance checklist: a block on outbound connections for the service account together with a counter-test, a look at the open connections of the model service, and a count of prompt content in the log. Together they take under a minute. Repeating them after every system change matters, because a rule nobody re-measures has, in our experience, quietly disappeared a few months later. Automated access from outside is spotted a different way, described in the article on bot traffic in the online shop.
Often not straight away. At a few hundred requests a month the fixed cost of your own hardware exceeds the cost of using an interface. The calculation typically turns once the load becomes steady, sensitive free text is involved or business customers regularly ask for evidence about where the data sits. A sensible intermediate step is to build the application layer now so that it treats the location of the model as configuration; the switch is then a setting later on and not a rebuild. How we set such features up is described under AI assistant and chatbot and privacy.