{"id":52554,"date":"2026-05-04T18:51:13","date_gmt":"2026-05-04T16:51:13","guid":{"rendered":"https:\/\/www.eh.at\/?p=52554"},"modified":"2026-05-04T19:29:42","modified_gmt":"2026-05-04T17:29:42","slug":"ai-and-data-protection-input-data-the-moment-of-truth","status":"publish","type":"post","link":"https:\/\/www.eh.at\/en\/ai-and-data-protection-input-data-the-moment-of-truth\/","title":{"rendered":"AI and Data Protection: Input Data \u2013 The Moment of Truth"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

04.05. 2026
Gernot Fritz<\/a>, Tanja Pfleger<\/a><\/em><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t

Alongside training data, which we discussed in our previous article<\/a>, one of the key data protection risks of AI systems lies in what users enter into them. Input data is the blind spot of practice.<\/p>

A prompt is written in seconds. A file is uploaded just as quickly. A use case is tested almost casually. But what may look like a trivial technical step is, from a legal perspective, a separate act of data processing \u2013 with its own requirements, risks and consequences.<\/p>

While training data shapes the past of a model, input data defines its present.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t

Input as a separate act of data processing<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

Input data is the data that users enter into an AI system. This may be simple text, but also complex documents, personal data, confidential materials or entire datasets. What these data have in common is not their format, but their context: they arise situationally, are often current and are frequently much more sensitive than training data.<\/p>

It is precisely this context-specific nature that makes them legally challenging. Unlike training, which often takes place in an abstract and upstream setting, the input of data is directly connected to specific individuals, specific business processes and specific expectations. What is entered is rarely neutral. It is usually embedded in existing legal relationships \u2013 with customers, employees or business partners.<\/p>

This requires a shift in perspective: input is not merely a technical intermediate step, but a separate data protection-relevant processing operation that must be justified in its own right.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t

Who is actually processing what?<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

When data is entered into an AI system, the traditional allocation of roles starts to shift. The user enters the data, the provider supplies the infrastructure, the model processes the content and generates an output. But that description is too simplistic.<\/p>

In practice, it is often assumed that the AI provider acts as a processor. That may be correct \u2013 but it is not automatic. As soon as the service provider uses prompts, uploads or telemetry data \u2013 that is, automatically collected and transmitted usage data \u2013 for its own purposes, such as product improvement, security analysis or model training, the classification as mere processing on behalf of another party often becomes difficult to maintain.<\/p>

A good example is AI-based voice transcription tools. Many of these systems do not limit themselves to pure transcription, for instance for meeting minutes, but also use voice data to improve the underlying models, for example through fine-tuning or training. From a data protection perspective, such use cannot simply be classified as processing on behalf of the customer. A provider that uses voice data for its own development or training purposes may itself become a controller or joint controller.<\/p>

The decisive questions remain the same: Who determines the purposes? Who determines the essential means? And who uses the data for its own interests? This is where the line is drawn between processor status and separate or joint controllership. For companies, this means that the classification of the provider is not a formality, but a central part of the risk assessment.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t

Purpose limitation under real-time conditions<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

The data protection principle of purpose limitation faces a particular challenge when it comes to input data. Data is typically collected for a specific purpose \u2013 for example, contract performance or internal analysis. If an AI system is then used, the question is whether that use is still covered by the original purpose.<\/p>

The answer is rarely straightforward. The integration of an AI system can quickly change the context of processing. Data is no longer merely stored or transmitted. It is analysed, transformed and placed into new contexts. At the same time, there is often limited transparency as to what actually happens inside the system.<\/p>

The result is a gradual functional shift. What began as a supporting use may develop into an independent form of processing. The relevant boundary is not the user interface, but the actual use of the data.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t

Legal bases in the context of use<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

Compared with training, the legal basis for processing input data is often more closely connected to existing business relationships. Contractual necessity may play a role, for example where an AI system is used to perform a specific service. But here too, the same principle applies: this legal basis only fits if the processing is objectively necessary to enter into or perform a contract. Merely being practical, useful or convenient is not enough.<\/p>

Legitimate interests remain an important legal basis, particularly for internal applications. However, the balancing test becomes more demanding. Input data is often directly personal and relates to specific real-life situations. This increases the requirements regarding transparency, reasonable expectations and protective measures.<\/p>

Consent may be relevant in certain constellations, but it also quickly reaches practical limits. In dynamic usage scenarios, it is often difficult to obtain informed, freely given and valid consent.<\/p>

The overall picture therefore remains ambivalent: the legal instruments exist, but their application in the specific context of use is complex and highly case-specific.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t

Shadow AI \u2013 the real risk<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

A significant share of the risks surrounding input data does not arise from deliberately controlled processes, but from informal use. Employees turn to freely available tools to work faster, achieve better results or automate routine tasks. In doing so, they enter data that was never intended for those systems.<\/p>

Customer data, draft contracts, internal analyses or strategic considerations \u2013 in practice, all of this can end up in prompts. What is intended as an efficiency gain can quickly become a loss of control. Once entered, this information often leaves the company\u2019s immediate sphere of influence and may be used as training data.<\/p>

The challenge is less about the individual violation than about the structure behind it. Shadow AI is not an exceptional case, but a systemic phenomenon. It emerges where governance is missing or not actually lived in practice. And it shows that the real weak point of many AI systems is not technical, but organisational.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t

Confidentiality and commercial sensitivity<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

In addition to data protection, another issue comes to the fore with input data: confidentiality. Much of the information entered into AI systems is not only personal data, but also commercially sensitive. It may be subject to contractual confidentiality obligations or qualify as trade secrets.<\/p>

The use of external AI systems may therefore lead to unintended disclosure. Even where there is no active onward transfer, the question arises whether processing by the provider already amounts to disclosure. This is not merely a theoretical issue. It determines whether existing confidentiality obligations are being complied with.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t

Technical reality and legal assumptions<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

A central problem in dealing with input data lies in the opacity of the systems. Users often do not know whether their inputs are stored, how long they are retained and whether they are used for other purposes. At the same time, legal assessments frequently rely on assumptions about precisely these processes.<\/p>

This discrepancy creates a structural risk. Decisions are made on the basis of incomplete information. Contracts are concluded without a full understanding of the actual data processing. Compliance is assumed without having been verified.<\/p>

That is why a sober look at the technical reality is essential. Anyone seeking to assess input data from a legal perspective must understand what actually happens to it \u2013 and must secure that understanding through robust contractual arrangements.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t

Conclusion and outlook<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

Input data is the point at which the abstract questions of AI regulation turn into concrete risks. This is where data protection, confidentiality and business practice intersect most directly. And this is where it becomes clear whether the use of AI is genuinely controlled \u2013 or merely appears to be.<\/p>

The greatest vulnerability of many AI systems does not lie in their training, but in what is entered into them every day.<\/p>

While input data shapes the use of AI systems, output raises legal questions of its own. The next part will therefore focus on output data \u2013 and on the legal consequences that arise from the results generated by AI systems, as well as the question of who is responsible for them.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t

AI governance, training, policies and contracts are essential to minimise the legal risks associated with the use of artificial intelligence. We support you in this process.<\/em><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

04.05. 2026Gernot Fritz, Tanja Pfleger Alongside training data, which we discussed in our previous article, one of the key data protection risks of AI systems lies in what users enter into them. Input data is the blind spot of practice. A prompt is written in seconds. A file is uploaded just as quickly. A use […]<\/p>\n","protected":false},"author":20,"featured_media":51841,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"rank_math_lock_modified_date":false,"inline_featured_image":false,"footnotes":""},"categories":[235],"tags":[805,898,973,361],"group":[],"area":[],"location":[],"systype":[],"class_list":["post-52554","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-legal-update-en","tag-ai-2","tag-data-protection","tag-input-data","tag-ki-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/posts\/52554"}],"collection":[{"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/comments?post=52554"}],"version-history":[{"count":7,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/posts\/52554\/revisions"}],"predecessor-version":[{"id":52565,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/posts\/52554\/revisions\/52565"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/media\/51841"}],"wp:attachment":[{"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/media?parent=52554"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/categories?post=52554"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/tags?post=52554"},{"taxonomy":"group","embeddable":true,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/group?post=52554"},{"taxonomy":"area","embeddable":true,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/area?post=52554"},{"taxonomy":"location","embeddable":true,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/location?post=52554"},{"taxonomy":"systype","embeddable":true,"href":"https:\/\/www.eh.at\/en\/wp-json\/wp\/v2\/systype?post=52554"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}