The risk assessment nobody ran for the AI feature

A compliance manager at a company operating under real data protection rules told me about a step their AI feature had skipped without anyone deciding to skip it. The company had a solid process. Any new activity that processed personal data in a significant way triggered a formal risk assessment before it went live, the kind that examines what data is used, what could go wrong, and how the risks are mitigated. That process worked, for years, for the things that went through it. The AI feature did not go through it. It was built by a product team as a feature, shipped through the normal release process, and never got filed as a new data processing activity. So a feature that processed a lot of personal data in new ways, exactly the kind of thing the assessment existed for, went live without one.

A data protection impact assessment is a structured look, before launch, at how a new activity uses personal data and what the risks are. In many places it is legally required for higher-risk processing, and AI features are frequently exactly that. They often introduce new uses of personal data, new automated decisions, and new data flows to third parties. The assessment is meant to catch and mitigate those risks up front. AI features slip past it because they arrive as product work rather than as the data project they actually are.

The trigger is the process gap

The assessment process usually has a trigger. Someone starts a new data activity, recognizes it as one, and files for the assessment. That trigger works when the person building the thing knows the process exists and sees their work as data processing. It fails when a product team builds an AI feature, thinks of it as a feature like any other, and ships it through the normal path, never touching the process that would have caught it.

The failure is structural rather than negligent. The people who run the assessment process are not usually in the room when the AI feature is scoped. The people scoping the feature are focused on what it does for users, not on classifying it as a new processing activity. So the feature moves through product and engineering, where the assessment is not part of the workflow, and lands in production without the review that a data project of the same weight would have required.

The cost of the gap is that the risks the assessment would have surfaced go unexamined until something forces them into view. A regulator asking to see the assessment. A customer’s diligence. An incident that the assessment would have flagged as foreseeable. By then the feature is live and the review that should have shaped it is a retrospective scramble.

Make the assessment part of building the feature

The fix is to connect the AI feature’s build process to the risk assessment process, so a new AI feature triggers the review the same way any new data activity would.

What that involves:

Recognize AI features as data processing. A feature that uses personal data, makes automated decisions, or sends data to a provider is a new processing activity, and it should trip the same trigger.
Assess before launch. Run the assessment while the feature is being scoped, so its findings can shape the design rather than judge it after the fact.
Cover the AI-specific risks. Automated decisions, new data flows to model providers, and the derivatives AI creates all belong in the assessment, not just the obvious data inputs.
Route the build to the process owner. Make sure whoever owns the assessment process is involved when an AI feature is planned, so it does not ship around them.

The teams that get this right treat an AI feature as a data project from the start, which puts it on the path where the assessment lives. The review then does what it was designed to do, catching risks before launch, instead of being reconstructed under pressure once someone asks where it is.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we check whether the AI feature has had the risk assessment its data processing calls for, and whether one is even required for your context. When a feature shipped as product work and skipped the process, we flag it and fold the assessment into the scoping, because its whole value is in shaping the design before launch. Running it early is straightforward. Explaining its absence to a regulator is not.

An AI feature that processes personal data is a data project, and it probably needs the assessment your process requires. Fold that review into the build, so the feature does not ship around the step that exists to catch its risks.