DPIA for AI tools: when you need one and what it must contain

A DPIA for AI tools is a legal document with a statutory trigger, not a governance nicety, and the distinction is where most firms get into difficulty. Under GDPR you must carry one out before processing that is likely to result in a high risk to people's rights and a good deal of ordinary AI deployment meets that description whether or not anyone intended it to.

The practical problem in construction and engineering is rarely the assessment itself. It is that nobody realised personal data was involved at all.

^{When a DPIA for AI tools is legally required}

The test is risk to individuals, not sensitivity of the project. Three triggers do most of the work in practice.‍

• ‍Systematic and extensive evaluation of people. CV screening, competency matching, performance analysis, automated sifting of subcontractor submissions.‍
• Processing on a large scale. Deploying an assistant across a tenancy so that it can reach every document, every mailbox and every meeting transcript in the practice is processing at scale, even though no one made a decision that felt like one.‍
• Systematic monitoring of a publicly accessible area. Site cameras, access control, anything analysing footage. This one is squarely in scope for construction and is routinely missed.

Both regulators publish screening material worth using rather than paraphrasing: the Information Commissioner's Office for the UK and the Data Protection Commission for Ireland, which also maintains a list of operations that always require an assessment.

If a firm operates in both jurisdictions, run to the stricter reading. The divergence is not currently large enough to justify two processes.

^{What a DPIA for AI tools must actually contain}

Four elements are mandatory, and a fifth is what makes the document useful.

• ‍A description of the processing. What data, whose, from where, to where, for how long, and who can reach it. For an AI deployment this must include the model provider, the hosting region, and whether inputs are retained or used for training.‍
• An assessment of necessity and proportionality. Why this processing, at this scale, rather than something narrower. "The licence includes it" is not a lawful basis, and this is the section regulators read first.‍
• An identification of risks to individuals. Not risks to the firm. The distinction matters and firms consistently write the wrong one.‍
• Measures to address those risks. Technical and organisational, with owners.‍
• A sign-off and a review date. Where a data protection officer exists, their advice must be sought and recorded — including where it was not followed, which is the entry nobody wants to write and precisely the one that demonstrates the process is real.

^{The personal data a DPIA for AI tools keeps finding in AEC firms}

This is the section worth taking to a project team, because the answers surprise people.

• ‍Site photographs. Faces, vehicle registrations, identifiable workers. Fed into an image or document tool without a second thought.‍
• Bid material. CVs, qualifications, professional registrations, sometimes health and right-to-work information.‍
• Correspondence. Every grievance, every performance discussion, every reference to a named individual's competence, all sitting in the mailboxes an assistant can now search.‍
• Site safety records. Incident reports, drug and alcohol testing, occupational health. Special category data, in a folder a tool was pointed at.‍
• Access and biometric systems. Increasingly common on larger sites, and among the most sensitive processing a contractor operates.

^{The tenancy question a DPIA for AI tools must answer}

For Microsoft 365 deployments specifically, one question determines most of the assessment: what can the account the assistant runs as actually see?

Permissions are inherited, not granted. An assistant surfaces what the user could already have found — but "could have found by searching for twenty minutes" and "is surfaced unprompted in a summary" are different exposures in practice, and over-permissive SharePoint inheritance is extremely common. A practice that has never audited its permissions will discover, during the DPIA, that half the business can reach the HR folder.

That discovery is the single most valuable output of the exercise, and it is a reason to do it before deployment rather than after.

^{What a DPIA for AI tools will not settle}

It will not determine whether the tool is accurate. That is the separate risk assessment, with a different method and a different owner.

It will not transfer responsibility to the vendor. The firm is the controller. A processing agreement allocates obligations; it does not move accountability, and no contractual term with a model provider changes who a regulator contacts.

It will not remain valid through a change of use. A DPIA covering document summarisation does not cover the same tool later used to screen applicants. New purpose, new assessment.

And it will not work as a one-off. Retention periods, sub-processors and model behaviour all change, so the review date is the part of the document that keeps it alive.

^{Getting a DPIA for AI tools done without stalling the rollout}

Start it in parallel with procurement, not after. Firms that treat it as a final gate discover the permissions problem a week before go-live and then either delay or, worse, proceed anyway.

Use one assessment per deployment, not per feature. Ten thin documents describing the same tenancy are harder to defend than one thorough one.

Get the information security and IT people in the room. Most of the answers about retention, region and access live with them, and a data protection lead writing alone will guess.

^{Where a DPIA for AI tools fits with everything else}

The data protection assessment is one of three documents a serious deployment produces. The others are the accuracy and failure-mode work, and the professional liability position which is where the question of who is answerable for an AI-assisted output gets decided, set out in AI and professional indemnity insurance. The governance structure that holds all three is covered in AI governance for construction and engineering firms, and the staff-side obligation that runs alongside it in AI literacy training.

AI Institute's own position on data handling is published in the AI policy, and the practical side of teaching teams what may and may not go into a tool runs through the capability programme.