DPIA for New Software and AI: When Companies Must Assess in Advance

A new software product or AI system should not be reviewed only after it has gone live. The key question is whether the planned processing is likely to result in a high risk to the rights and freedoms of natural persons. If it is, the organisation must carry out a Data Protection Impact Assessment (DPIA) before processing begins.

This article focuses on the threshold and the practical process. It explains which features matter when new technology is introduced, how to structure the assessment and why a product description or a general record of processing activities is not enough on its own.

Article 35(1) GDPR applies where processing, particularly when using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons because of its nature, scope, context and purposes. The assessment is a prior step. An organisation should not first transfer production data into a system and only then try to justify the decision.

A DPIA is not a product certificate or a general assessment of the provider. It concerns the specific use: which data are processed for which purpose, who may be affected, which recipients and systems are involved and what consequences may arise. The same software can require a different assessment depending on configuration and target group.

Procurement, IT, the business unit and the privacy function therefore need to work together early enough. A project gate should not approve production use until the threshold screening and, where required, the DPIA have been completed to the necessary depth.

Article 35(3) GDPR identifies, in particular, systematic and extensive evaluation of personal aspects including profiling, large-scale processing of special categories of personal data, and systematic monitoring of publicly accessible areas on a large scale. These are important anchors, not a substitute for an individual assessment.

Software and AI may combine further risk factors: many people affected, opaque criteria, continuous observation, combining different data sources, limited ability to influence the outcome or decisions with significant effects. No single factor necessarily decides the issue. Several factors together may substantially increase the risk.

Do not assess technical performance alone. Ask whether people can reasonably expect the processing, whether results can be checked, whether errors can be corrected and whether human review is real rather than merely formal. The assessment must focus on the people affected, not only on the system architecture.

A product presentation is not enough for a DPIA. The documentation should describe the actual use case: which inputs are used, what results the system produces, who sees them and what action follows. For AI, clarify whether the system creates, sorts, scores, predicts or evaluates content and whether its output feeds into a decision.

The distinction between assistance and decision-making is especially important. A tool that helps staff with research differs from a system that filters applications, assigns risk to customers or evaluates employees by behavioural data. The actual use matters, not the label “assistant”.

The article on AI at work and works agreements addresses employment-law co-determination. The DPIA question is separate: it concerns the data-protection risk analysis of the specific processing before use.

1. Clarify purpose and legal basis: Describe the business problem and why processing is necessary. An unclear purpose almost always produces an unclear risk assessment.

2. Record data and people: Map data categories, sources, recipients, retention and groups affected. Check special categories, criminal-offence data and children’s data.

3. Map data flows: Record modules, interfaces, hosting, support access, processors and possible transfers to third countries. The page on processors and service providers supports the role and chain review.

4. Test necessity and proportionality: Ask whether the purpose can be achieved with less data, shorter retention or less intrusive technology.

5. Assess impact on people: Consider confidentiality, integrity and availability as well as discrimination, loss of control, incorrect classification or exclusion from services.

6. Define safeguards: These may include access separation, logging, deletion periods, human review, testing, training and a process to correct wrong results.

7. Document and review: Record residual risks, responsibilities and triggers for a new assessment. A DPIA is not a document that can never be reopened.

Article 35(7) GDPR requires, among other things, a systematic description of the planned processing and its purposes, an assessment of necessity and proportionality, an assessment of risks to the rights and freedoms and the measures intended to address those risks. The depth must match the risk. A low-volume process does not need artificial paperwork; a complex scoring system cannot be cleared with two pages.

Where a data protection officer has been appointed, the controller must seek the officer’s advice under Article 35(2) GDPR. Responsibility for the decision remains with the controller. The advice should therefore be recorded and taken into account in the project decision. Where employee data are involved, the relevant employment-law bodies must also be included in the process.

The Austrian Data Protection Authority may require a DPIA or establish that certain processing operations are unlikely to result in high risk. For an individual new AI use, however, a general product statement or template assessment is not enough. The use in your organisation remains decisive.

A provider may be a processor where it processes data on documented instructions for the organisation’s purpose. It may have a different role for its own purposes, such as particular product analytics or billing. This role analysis is part of the project review but does not replace the DPIA.

The article on AI contracts, vendor liability and GDPR addresses the contractual side. For the DPIA, also examine which data the model actually receives, whether inputs are retained, which subcontractors are involved and how deletion, access and data-subject requests work.

A contract can reduce risk but cannot cure unlawful processing. Before signing and before production use, the organisation must know which technical and organisational safeguards can actually be implemented for the proposed sensitive use.

The risk assessment does not necessarily end at go-live. A new data source, model, group of people, recipient or purpose can undermine the original assessment. A security incident or new evidence about error rates can also trigger a review.

Define a change process in the project. The business unit should not activate new fields, analyses or automations without reviewing the data-protection consequences. For AI, this includes testing misclassification, impermissible outputs and whether human control actually works.

The privacy compliance and governance page should define who owns the DPIA, who approves changes and when the assessment must be reopened. The role check supports an initial allocation of controller and processor roles.

A DPIA must fit the actual use: purpose, data, people affected, providers and consequences. We help you assess the threshold, structure the process and allocate the necessary technical, organisational and contractual safeguards. Contact us with the project description, data flow, provider information and intended use so that the next steps can be defined before production starts.