Legal usually is not blocking the feature. It is blocking the absence of a record it can rely on. The fix is a completed assessment, not a longer wait.
Legal usually is not blocking the feature — it is blocking the absence of a record it can rely on. What unblocks it is a completed assessment covering the use case, the personal data involved, the legal basis, and whether there is automated decision making or profiling with significant effects, along with a risk classification against the applicable regime.
Assembled properly, this takes weeks rather than months. The delays usually come from the vendor answering diligence questions rather than from the assessment itself.
The assessment starts with the use case itself: what personal data is involved, what legal basis applies, and whether the system involves automated decision making or profiling with significant effects. That is paired with a risk classification against the applicable regime — the same tool can carry very different risk depending on whether it is drafting marketing copy or screening job applicants.
Risk classification applied to the vendor rather than to the use case is one of the most common failure points. The assessment fixes that by anchoring classification to what the tool actually does in your context.
The assessment also covers what the contract actually permits regarding training on your data, retention, and sub-processing. Many organizations lean on vendor assurances without reading what the contract says. Those are not the same thing, and legal needs the contract position on record, not the sales deck.
The controls section documents human oversight, what the model can and cannot decide alone, testing evidence, and the fallback if it fails. These are the operational commitments that turn an assessment from a paper exercise into something the business can actually stand behind.
Finally, the disclosure position: what the privacy notice tells users and whether any consent or opt-out applies. Getting this right before launch means the notice reflects what the system actually does rather than being retrofitted after the fact.
Risk classification should be applied to the use case, not to the vendor. The same tool carries very different risk whether it is drafting marketing copy or screening job applicants — treating them identically because they share a vendor is where assessments go wrong.
Assembled properly, the assessment takes weeks rather than months. The delays usually come from the vendor answering diligence questions rather than from the assessment itself.
You need to read the contract. Many organizations rely on vendor assurances without reading what the contract actually permits regarding training on their data. Those are not the same thing, and the assessment documents the contract position specifically.
A register of where AI is actually in use across the business, including tools adopted by individual teams without central approval, with each entry recorded at the use-case level rather than the vendor level.
A single assessment template applied consistently across use cases, covering the personal data involved, the legal basis, whether automated decision making or profiling with significant effects is in scope, and the disclosure position, so two reviewers reach the same conclusion on the same facts.
Tiering criteria anchored to what the tool does in your context rather than to the vendor supplying it. The same model may be classified differently when it drafts marketing copy than when it screens job applicants, with defined thresholds for what each tier requires before launch.
Mapping each use case against the regimes that reach it, including the EU AI Act, GDPR and UK GDPR automated decision-making provisions, US state AI and profiling rules, and sector requirements, with the analysis documented rather than assumed.
Review of what the contract permits on training with your data, retention, sub-processing, and audit rights, separating the contractual position from sales assurances, with a diligence question set to run at procurement.
Documentation of what the system can decide alone, where a human sits in the loop, the testing evidence behind that decision, and the fallback if the model fails or degrades.
Alignment of privacy notices, in-product disclosures, and any consent or opt-out mechanism with what the system actually does, addressed before launch rather than retrofitted after.
The routing that decides which use cases need full assessment, who approves each risk tier, how exceptions are recorded, and when a use case returns for review.
Triggers for revisiting a completed assessment, including model changes, expanded use, new jurisdictions, and vendor terms updates, so the record stays current between formal reviews.
Onsite or remote training for legal, product, procurement, and business teams on when to route a use case for assessment and how the classification criteria apply.
A completed assessment covering the use case, data, legal basis, vendor position and controls is what legal needs. Assembled properly, this takes weeks rather than months.
A short note about your situation is plenty. Replies come from rasha.hisham@appliedprivacyconsulting.com.
We use Google Analytics 4 to understand how this site is used and to measure our advertising. These set cookies on your device. Nothing loads until you choose. How we handle your data.
Applied Privacy Consulting