AI and the GDPR in Austria: what companies need to consider with company data

The General Data Protection Regulation (GDPR) always applies to the use of artificial intelligence (AI) when personal data is processed – that is, information about identifiable people such as customers, employees or suppliers. For Austrian companies this means: anyone who has company documents searched or analysed by an AI must first clarify where the data is processed, whether it is used to train the AI model and whether there is a data processing agreement (DPA) with the provider. With these three questions, a large part of the data protection risks can be ruled out in advance. This article shows which data is contained in typical company documents, which roles and obligations the GDPR assigns, what the EU AI Act additionally requires and how a privacy-compliant rollout works step by step.

In brief

• The GDPR applies to AI use as soon as personal data is involved – and in business documents that is almost always the case.
• Almost every document type in a company contains personal data: from the contact person in a quote to salary data in HR records – with different consequences for AI use.
• The key questions for every AI provider: where is the data processed? Is it used for training? Is there a data processing agreement (DPA)? Who has access?
• Your company remains responsible as the “controller”, even if an external provider supplies the technology.
• The EU AI Act supplements the GDPR step by step; internal document AI typically does not fall into the high-risk category, but measures to promote AI literacy (Art. 4) are required of SMEs too.
• Retention obligations (basic rule: seven years under the UGB and BAO) and GDPR deletion obligations must be considered together – the AI system must be able to handle both technically.
• A structured rollout in eight steps and a checklist before choosing a provider save later problems with data subject rights and the data protection authority.

When does the GDPR apply to the use of AI at all?

The GDPR – the European General Data Protection Regulation, in force since 2018 – is not tied to the technology but to the data. What matters is not whether a tool is called “AI” but whether personal data is processed. Personal data is any information that can be attributed to an identified or identifiable person: names, email addresses, telephone numbers, customer numbers, salary data, but also photos or location data.

In practice this point is reached quickly. A quote contains the name of the contact person at the customer. Meeting minutes name employees. An incoming invoice contains the supplier’s contact details. Anyone who loads such documents into an AI system or copies content from them into an AI input is processing personal data – and so the GDPR applies, with all its obligations.

The distinction is important: purely technical data without any link to individuals (such as machine parameters or anonymised statistics) is not covered by the GDPR. In mixed document collections, however, such as exist in every company, a clean separation is hardly possible. The safe route is therefore to set up the entire use of AI in a GDPR-compliant way from the outset, rather than sorting out individual documents. What such an internal document AI is in concrete terms and how it works is explained in the guide What is an AI knowledge base?

Which personal data is contained in typical company documents?

Many companies underestimate how much personal data is contained in perfectly ordinary business documents. The following overview shows typical document types, the personal data they usually contain and the consequence for AI use:

Document type	Typical personal data	Consequence for AI use
Quotes, order confirmations	Names and contact details of the contact persons at the customer	GDPR applies; easily manageable with a data processing agreement (DPA), EU processing and training exclusion
Invoices (incoming and outgoing)	Names of sole traders, contact persons, bank details	GDPR applies; also observe the seven-year retention obligation under tax law
Email correspondence	Names, signatures, sometimes private remarks	Very heterogeneous content; clear internal rules needed on which emails may go into the system
Contracts	Contracting parties, signatories, terms	Maintain confidentiality; restrict access to authorised persons via role permissions
Meeting minutes, internal notes	Employee names, statements and assessments by individuals	Access control important; avoid judgemental statements about people where possible
HR records	Salary data, sick leave, applications – partly special categories of data	Highest level of protection; only with strictly limited access, or not in the AI system at all
Technical documentation, manuals, instructions	Usually only author names	Largely uncritical – ideal as the starting collection for the rollout

Two conclusions can be drawn from this. First: “data-protection-free” AI use with company documents is an illusion – GDPR compliance must be planned in from the start. Second: not every document is equally sensitive. If you start with technical instructions, manuals and process descriptions and deliberately exclude or strictly restrict sensitive areas such as HR records, you reduce the risk considerably without giving up the benefits. How existing filing systems and systems can be connected to a document AI in an orderly way is described in the guide Connecting documents and systems.

Which four questions should companies ask every AI provider?

Before an AI tool is introduced in a company, four questions should be clarified in a binding way. They cover the most common problem areas under data protection law:

Question	Why it matters	What to look out for
Where is the data processed?	Data processing outside the EU (in a “third country”) requires additional safeguards.	Prefer a server location in the EU or the European Economic Area (EEA).
Is the data used for AI training?	Use for training means your content can flow into the model – often irreversibly.	Contractual exclusion of use for training; often not the case with free services.
Is there a data processing agreement (DPA)?	Art. 28 GDPR requires a data processing agreement if the provider processes data on your behalf.	The data processing agreement should be part of the offer, not only available on request.
Who has access to the data?	Access by the provider’s staff or sub-contractors must be regulated and restricted.	User and role management in the tool itself, documented sub-processors.

A provider that cannot answer these four questions clearly and in writing is unsuitable for use with company documents. This applies regardless of how powerful the AI is. The difference becomes particularly clear in comparison with public chat services: why freely copying company data into general AI chats is problematic and what alternatives exist is explained in the article Using ChatGPT with your own data.

Who is the controller and who is the processor?

The GDPR distinguishes between two central roles. The controller is whoever decides on the purposes and means of data processing. The processor is whoever processes personal data on behalf of and on the instructions of the controller.

Applied to the use of AI, this means:

• Your company is the controller. You decide which documents go into the AI system, what the AI is used for and who in the team is given access. You therefore bear the main responsibility towards data subjects and the data protection authority.
• The AI provider is generally the processor. It provides the technology and processes the data only to deliver the agreed service – not for its own purposes.

This division of roles has a practical consequence that is often underestimated: responsibility cannot be outsourced. Even if the provider makes a mistake, the company as controller remains the first point of contact for data subjects and the supervisory authority. That makes it all the more important to choose the provider carefully and to regulate the cooperation properly in the data processing agreement (DPA; in German AV-Vertrag or AVV). Among other things, the data processing agreement specifies which data is processed, which security measures apply, whether and which sub-processors are used and what happens to the data after the contract ends.

If, on the other hand, a provider processes the data for its own purposes – for example to train its models beyond the scope of the assignment – it leaves the role of processor. This is precisely why the contractual exclusion of use for training is so significant.

On what legal basis may companies process documents with AI?

Under the GDPR, every processing of personal data requires a legal basis. For internal AI use, three are mainly relevant:

• Performance of a contract: Data of customers and suppliers may be processed insofar as this is necessary for performing the contract – for example if the AI helps to find order documents more quickly.
• Legal obligation: Where laws require documents to be retained (more on this below), the associated storage is also covered.
• Legitimate interest: Efficient internal organisation, document management and knowledge retention are a recognised business interest. Here the GDPR requires a balancing test: the company’s interest must be weighed against the interests and fundamental rights of the people concerned. For an internal search across ordinary business documents with a limited group of users, this balancing often comes out in the company’s favour – provided access rights, EU processing and training exclusion are guaranteed.

It is important to briefly record the chosen legal basis in writing – usually in the record of processing activities, the internal register the GDPR provides for processing operations. In the event of enquiries from data subjects or the data protection authority, a documented balancing test is worth its weight in gold. Key terms from “data processing agreement” to “record of processing activities” are explained concisely in the glossary.

What does the EU AI Act change in addition to the GDPR?

The EU AI Act – the European AI Regulation, in force since 2024 – supplements the GDPR but does not replace it. While the GDPR protects the data, the AI Act regulates the AI system itself. The obligations apply in stages: certain practices have been prohibited since February 2025, rules for general-purpose AI models have applied since August 2025, and transparency obligations since August 2026; Regulation (EU) 2026/1744 has postponed the extensive obligations for high-risk systems to 2 December 2027 (Annex III) and 2 August 2028 (Annex I).

For most Austrian SMEs, three points are relevant:

1. Risk classes: The AI Act classifies AI systems by risk – from prohibited practices through high-risk applications to systems with limited or minimal risk. An internal document search with AI answers typically falls into the lowest category and does not trigger any high-risk obligations. High-risk obligations concern other fields – for example AI that has a say in the hiring or promotion of people.
2. AI literacy (Art. 4 AI Act): Since 27 July 2026, companies that use AI must take measures to promote the AI literacy of their staff; a particular level does not have to be guaranteed. This expressly applies to small companies too and can be met pragmatically with internal training and clear rules of use: the team should know what the tool can do, where its limits lie and which data may go into it.
3. Transparency: Where people interact with an AI, this must be recognisable. With an internal tool that the team knowingly uses as AI, this requirement is easy to meet.

The topics overlap considerably: if you set up data protection and training properly, you are also working on the points the AI Act provides for users. Whether this fulfils the obligations in your own case is a matter for a legal review.

What applies to employee knowledge and internal notes?

A common reason for introducing a document AI is to secure the company’s know-how: the experience of long-serving employees, project notes, proven procedures, internal instructions. If an experienced member of staff retires or leaves the company, this knowledge otherwise disappears with them – and those who remain are left searching. What unproductive search time actually costs a company is shown in the analysis Time lost searching for documents.

Under data protection law, two levels of internal knowledge need to be distinguished:

• Specialist knowledge – how a machine is maintained, how a quote is calculated, which steps a process has – is not personal data as such. It can be included in a knowledge base without concern. If the documents contain the name of the author or notes such as “for queries contact Mr X”, this is a weak link to an individual that is covered by the measures taken anyway (EU processing, data processing agreement, access control).
• Statements about people – assessments of colleagues, notes on the behaviour of individual customers, evaluations of applicants – are, by contrast, fully personal and sometimes sensitive. Such content either does not belong in a widely accessible AI system at all or only in areas with strictly restricted access.

This leads to a simple editorial rule for securing knowledge: keep knowledge documents factual. Instead of “Mr Huber always does it this way”, better “proven procedure for type B maintenance”. As a side effect, this improves the quality of the AI answers, because the content is worded in a generally applicable way.

The perspective of your own workforce must also be considered: employee data in minutes and notes is personal data too, and the introduction of a system that makes internal documents searchable should be communicated transparently. Disclose which document areas are covered, who has access and that the system serves to search for knowledge – not to monitor behaviour. In companies with a works council, early involvement is recommended, as systems relating to employee data can touch on participation rights under Austrian labour constitution law. Practical experience with introducing the system in the team is described in the guide AI knowledge base in the company.

How do retention obligations and deletion obligations fit together?

At first glance, two requirements contradict each other: the GDPR requires personal data to be deleted once the purpose no longer applies – Austrian company and tax law requires documents to be retained. The solution is simpler than it sounds: a statutory retention obligation is itself a legal basis for continued storage. As long as it is running, it takes precedence over a request for deletion; only afterwards does the deletion obligation apply.

The key points for Austrian companies:

• Basic rule of seven years: § 212 of the Austrian Commercial Code (UGB) and § 132 of the Federal Fiscal Code (BAO) require books, records, vouchers and business papers to be retained for seven years from the end of the calendar year for which the entry was made (or of the financial year where it differs from the calendar year).
• Longer periods in individual cases: Longer retention periods apply to certain documents – for example in connection with real estate or pending proceedings. When in doubt: check first, then delete.
• Once the period has expired, the deletion obligation applies: Documents containing personal data with no continuing purpose may not remain in the system “forever”. A simple deletion concept – for example an annual review of expired material – is sufficient in many SMEs.

For choosing an AI system, this results in a twofold technical requirement: the system must be able to keep documents reliably and securely for years and allow individual documents to be deleted in a targeted way as soon as periods have expired or a justified deletion request has been made. Tools that “bake” uploaded content inseparably into a model fail the second requirement.

Which data subject rights apply to internal documents?

The GDPR gives every person whose data is processed enforceable rights – and these also apply when the data is contained in internal documents searched by an AI. Data subjects can be customers, suppliers, applicants or your own employees. The overview shows the four rights most relevant in practice and what your AI system must be able to do for them:

Data subject right	What data subjects can demand	What the AI system must be able to do
Access (Art. 15 GDPR)	Information on which data about them is processed, for what purpose and for how long	Targeted search for a person across all documents contained
Rectification (Art. 16 GDPR)	Correction of inaccurate data	Update documents or replace them with corrected versions
Erasure (Art. 17 GDPR)	Erasure if the purpose no longer applies and no retention obligation stands in the way	Remove individual documents completely and verifiably
Objection (Art. 21 GDPR)	Objection to processing based on legitimate interest	Be able to identify affected content and remove it from processing

Two points deserve particular attention. First, the deadline: requests from data subjects must in principle be answered without undue delay, and at the latest within one month. If you do not know in which systems a person’s data is held, you quickly come under time pressure. A searchable document store can even make it easier to fulfil the right of access: a search for the name of the person making the request delivers in minutes what would otherwise require combing through folders and drives.

Second, technical deletability: an AI system for company documents must be built so that you know at all times which documents it contains and can remove individual content in a targeted way. With systems that store documents as a searchable knowledge base and draw on them for answers, this is technically easy to solve – the document is removed, and the AI can no longer access it.

The competent supervisory authority in Austria is the Data Protection Authority (dsb.gv.at). The legal texts – GDPR, the Austrian Data Protection Act, UGB and BAO – are freely available in the Federal Legal Information System (RIS, ris.bka.gv.at); practical overviews for businesses are provided by the Austrian Economic Chamber (WKO, wko.at).

Which questions should you ask every AI provider? (Extended checklist)

The following checklist summarises what should be clarified before introducing an AI tool with company documents – from the key data protection points to organisational questions that make the difference in everyday work:

• Server location: Is the data processed exclusively in the EU or EEA? If not: what safeguards exist for the third-country transfer?
• Training exclusion: Is it contractually guaranteed that your data will not be used to train AI models?
• Data processing agreement (DPA): Is there a data processing agreement under Art. 28 GDPR? Is it part of the contract package?
• Sub-processors: Are all sub-contractors used disclosed, and will you be informed of changes?
• Access control: Does the tool offer user and role management so that sensitive documents (such as HR records) are only accessible to authorised persons?
• Encryption: Is the data encrypted in transit and at rest?
• Data backup and deletion: Are there automatic backups, and is it regulated how data is completely deleted on request – including individual documents?
• Traceability: Does the AI back up its answers with sources from your documents? This makes checking easier and reduces the risk of made-up statements.
• Logging: Is it possible to trace who uploaded or deleted which documents and when?
• End of contract: Is it regulated that you get all your documents back at the end of the contract and that the provider deletes all copies?
• Contact person: Is there reachable support, ideally German-speaking, that can answer data protection questions?
• Internal rules: Have you specified which documents may go into the system and who may upload them?

Providers geared towards European SMEs usually meet these points as standard. The AI knowledge base, for example, processes documents on EU servers, excludes the use of customer data for AI training, delivers answers from your own company documents with sources and comes with a data processing agreement (DPA) as well as user and role management.

What does a GDPR-compliant rollout look like step by step?

A structured start prevents data protection questions from only coming up after the rollout. In practice, the following eight-step procedure has proven its worth:

1. Initial assessment: Clarify which document types the AI is to process and which personal data they contain (customer data, employee data, supplier data). The table above serves as a grid; mark the sensitive areas straight away.
2. Define purpose and legal basis: Record in writing what the system is used for (for example internal knowledge search) and on which legal basis you base the processing – usually the legitimate interest in efficient document management, together with a brief balancing test.
3. Check providers: Work through the checklist in the previous section and get all commitments in writing. Verbal information in a sales conversation is not enough.
4. Conclude the data processing agreement (DPA): Before the first live document, not afterwards.
5. Update the record of processing activities and check the DPIA: Enter the new processing in the record of processing activities. Briefly check and document whether a data protection impact assessment (DPIA) – the in-depth risk analysis the GDPR requires for processing likely to result in a high risk – is necessary; for an internal document search this is typically not the case.
6. Define access rights and internal rules: Define who may use the system, which documents may be uploaded and which expressly may not (for example health data or application documents, unless necessary). Set up the roles in the system accordingly.
7. Inform and train the team: Explain openly to the team what the system can do, which documents are covered and how to deal with AI answers (check sources, do not adopt them blindly). A short, documented training session is at the same time a measure to promote AI literacy under Art. 4 AI Act. In companies with a works council: involve it early.
8. Start with uncritical documents, then expand: Begin with manuals, instructions and process documentation. Only once the process and access control have proven themselves do more sensitive areas follow – or they are deliberately left out. Afterwards, review the rules at fixed intervals, for example once a year.

How such a rollout works organisationally and how long the individual phases typically take is shown on the Process page.

If you go through these eight steps, you have done the organisational groundwork on which a legal review can build – without project bureaucracy, but with solid documentation in case of queries. Most of the effort is one-off; in ongoing operation, what remains is maintaining access rights and occasionally reviewing the material. This article provides general guidance and does not replace legal advice in an individual case; for specific questions, consultation with a law firm specialising in data protection law or the company’s data protection officer is recommended.