The law requires the assessment before the processing starts, not after a complaint arrives.
Why it matters when the plan changes
Assessment of employees by any systematic method sits close to the trigger for a DPIA, and the introduction of a model into that assessment sits closer still, since Article 35 singles out processing that uses new technology and is likely to result in high risk to people. The document is where the purpose, the data, the access and the safeguards are written down at the point when they can still be changed, which is also the point at which nobody feels they have time.
The tension is that a DPIA is a controller's obligation, and the controller in an employment setting is the employer. A supplier can and should provide the material, including technical documentation prepared for the AI Act, but cannot sign the assessment on the employer's behalf. Procurement often assumes the reverse, and the gap is discovered when the works council asks who owns the document.
In practice
A group agrees a rollout across three countries and asks the supplier for its DPIA. The supplier sends a thorough document about its own platform. The employer's data protection officer reads it and points out that nothing in it addresses this employer's purposes, this population or this access model, which is what the law actually asks for. The rollout waits six weeks for a document that should have been started in the design phase.
Evidence
A DPIA is required where processing, particularly with new technology, is likely to result in a high risk to the rights and freedoms of natural persons.
Article 35, General Data Protection Regulation (2016)
What it cannot tell you
A DPIA records that risks were identified and mitigations chosen; it does not certify that the processing is lawful, fair or actually low risk once running. It is silent on whether the safeguards described are followed after deployment, and it says nothing about the accuracy or outcomes of any system it covers.
Questions
The controller, which in an employment setting is the employer. A supplier acting as processor contributes the description of its processing, its safeguards and its sub-processors, but cannot own the assessment, because the purposes and the population being assessed belong to the employer rather than to the supplier.
Article 35 of the GDPR (2016) sets the threshold: processing likely to result in high risk to people, particularly through new technology, systematic evaluation of personal aspects, or processing of employee data. Where it is unclear, supervisory authorities publish lists of processing types that require one, and those lists are the place to check.
A systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to the people affected, and the measures envisaged to address those risks. It is a working document rather than a certificate, and it is revisited when the processing changes.
No. It is a risk assessment, not a lawful basis. The processing still needs a basis under Article 6, the purpose still has to be specified, and where residual risk stays high the controller is expected to consult the supervisory authority before starting rather than to proceed on the strength of the document.
They are separate obligations that overlap in practice. The DPIA obligation comes from Article 35 of the GDPR (2016); the AI Act adds documentation, risk management and human oversight requirements for high-risk systems. A supplier's AI Act documentation is useful input to an employer's DPIA and does not replace it.