Your data science team just showed a model trained on millions of customer records. The accuracy numbers are good. The room is happy.
Then legal asks one question.
“Can we document consent for all the training data?”
I’ve watched a version of this moment more than once, and the tell is always the same. Nobody says no. Somebody says they’ll look into it.
The question may be consent, another documented lawful basis, contractual permission, a retention obligation, a sector restriction, or simply whether the data was ever authorized for this use. The underlying problem doesn’t change: can you show why each material input belongs in the workflow?
The Answer Determines Your Timeline
At Drumline, I worked with a financial services organization that restarted a fraud detection initiative from the beginning. The model worked. What ended it was discovering sensitive data in the training set that nobody could account for.
The second part is what cost them. Removing the data would have been a week. Being unable to reconstruct the lineage meant they couldn’t demonstrate the remaining data was clean either, which made the whole set suspect. Deployment slipped roughly eight months.
The model was never the problem. The inability to answer a provenance question was the problem, and it surfaced at the worst possible moment, which is the only moment it ever surfaces.
What “Privacy-Safe” Means in Practice
Privacy-safe data is a set of properties, not a volume reduction. Five of them, each a question you can either answer or you can’t.
Intentional. You can say why each element is there. Not “it was available.” A reason tied to the question the model answers.
Permissioned. Every individual whose data is in there provided consent or falls under a documented lawful basis, and you can produce the documentation.
Clean. Validated, deduplicated, and checked for the biases that matter to your use case. This one pays for itself independent of regulation, because it’s the difference between a model that behaves in production and one that behaved in testing.
Auditable. You can trace which data trained which model, who accessed it, and when. Reconstructible after the fact, rather than remembered by the person who built it.
Removable. When someone requests deletion, you can find their data across systems and remove it, including from anything derived from it.
The last one is where most organizations discover the gap. Deletion from a warehouse is straightforward. Deletion from a model trained on that warehouse is a different problem with no clean answer, which is why the intentional and permissioned properties matter so much upstream.
Before production use, define what deletion means for your architecture specifically. It may involve removal from the operational source system, an analytics table, a retrieval or vector index, suppression from future use, deletion from vendor logs where contractually available, retention limits, retraining, or a documented exception where complete removal from a trained model isn’t technically feasible.
The standard isn’t a universal delete button. It’s that you can explain accurately what you can remove, what you can’t, how fast you can act, who’s responsible, and how that reality appears in contracts, notices, and internal process.
Make the Use Case Legible First
Before a workflow reaches production, write a one page record for it: purpose, named owner, intended users, model or vendor, source systems, material data categories, data that must be excluded, expected output, decision impact, retention expectation, review method, escalation contact, and the conditions requiring a pause.
The document isn’t the control. It’s the fastest way to discover whether the control, the decision, and the owner exist.
If the team can’t fill in a field, don’t paper over the blank with a policy statement. Treat it as a design question. The missing answer may mean narrower inputs, a different architecture, a different owner, a legal review, or a decision not to proceed yet.
The Vendor Doesn’t Own Your Data Decision
A vendor contract allocates obligations. It can’t replace your understanding of the data flow.
Before connecting customer, employee, or otherwise sensitive information to an AI vendor, ask:
- Will our data train a shared model or improve the service for other customers?
- Where is it processed and stored, and which subprocessors receive it?
- What controls exist for access, retention, deletion, and export?
- What logs, audit records, security documentation, and incident-notification commitments can they provide?
- What happens if the model, product terms, data-processing terms, or subprocessor list changes?
- Can we prevent specific data classes from entering the workflow at all?
If nobody on your side can explain what leaves your systems and where it goes next, the integration isn’t ready just because the authorization screen was easy to complete.
The Regulatory Picture Keeps Moving, and Not Only Forward
Here’s where I’d push back on the usual framing. The standard version says regulation is tightening on a known schedule, so build now or pay later. The schedule part isn’t holding up.
The EU AI Act’s high-risk obligations were postponed. Under the Digital Omnibus agreed in May 2026, standalone Annex III systems moved from August 2026 to December 2, 2027. Embedded Annex I systems moved to August 2028. What didn’t move: the Article 5 prohibitions, in force since February 2025, and the Article 50 transparency obligations on AI-generated content, which still landed August 2, 2026.
Colorado repealed its AI Act before it took effect. In June 2026 the state replaced the CAIA with the narrower Automated Decision-Making Technology Act, dropping the algorithmic discrimination obligations for transparency and documentation requirements. It takes effect January 1, 2027, contingent on rulemaking. The new law avoids the term “AI” entirely.
California’s disclosure rules landed late but landed. SB 942 became the California AI Transparency Act as amended by AB 853, operative August 2, 2026 rather than January 1, with a phased rollout through 2028.
State privacy law kept expanding regardless. Roughly twenty comprehensive laws are in effect, and California’s automated decision-making rules now require opt-outs when those technologies replace human judgment in significant consumer decisions.
Whether any particular requirement applies depends on jurisdiction, organization, system design, data, and decision. This isn’t legal advice. The operational lesson is broader: a team that can trace data, explain its use, document decisions, and stop a problematic workflow adapts better than one building only to the date circled on a compliance calendar.
Direction is consistent. Timing is unreliable in both directions. Build to the obligation rather than the deadline.
Techniques Are Architecture Choices, Not a Program
Before choosing a privacy-enhancing technology, ask a simpler question: should this data enter the workflow at all?
The answer may be to minimize the input set, exclude a sensitive category, use aggregated or de-identified information, narrow the purpose, constrain the outputs, or decide the use case isn’t justified. Privacy engineering is an architecture choice rather than a substitute for purpose limitation.
When it is the right move, several methods are now practical without a research team. Federated learning trains across distributed sources without centralizing data, which is how multi-entity organizations build a shared model without any party seeing another’s records. Differential privacy adds calibrated noise so models learn patterns without exposing individuals. Secure multi-party computation lets organizations contribute to a shared model without revealing inputs to each other. Edge processing keeps data where it originated.
Each creates tradeoffs in accuracy, cost, latency, operational complexity, and governance. Don’t pick one because it sounds privacy-preserving in the abstract. Start with the exposure problem, define the system and the people affected, then decide whether the control is proportionate.
Which also means matching controls to risk generally. A low-risk internal drafting aid using approved reference material doesn’t need the process appropriate for a system influencing eligibility, pricing, credit, employment, or access to services. Raise the controls when the data is more sensitive, the decision carries more consequence, a vendor receives the information, an action is hard to reverse, or an error would be hard to catch before it causes harm.
And know which system you’re governing. “AI system” can mean a trained model, a retrieval-augmented assistant, a classification workflow, an agent that calls other tools, or a vendor feature with customer data attached. A retrieval index creates one deletion problem. A fine-tuned model creates another. An agent that takes actions introduces permissions and logging questions a read-only assistant doesn’t. Don’t borrow a control list from one architecture and assume it answers another.
Three Things Worth Doing
1. Map the data behind one consequential AI system. Pick one workflow reaching customers, employees, material decisions, or sensitive information. Identify what it uses, where every material source came from, the collection or authorization basis, what the data means, where it flows, and whether you can produce documentation. Stop at the first gap you can’t close. That gap is the honest initial scope.
2. Run a deletion request against yourself. Pick one record and trace it through source systems, warehouses, analytics tables, exports, retrieval indexes, vendor tools, audience lists, backups, and known derived uses. Record what can be deleted, what can only be suppressed, who owns each location, and what needs remediation.
3. Decide who can stop a deployment. Define the pause conditions: unsupported provenance, unauthorized data, a harmful output, a security incident, a quality failure, an unresolved complaint. Name the person who can halt it, specify the escalation path, and make sure that authority is real rather than ceremonial.
What I’d Say to the Room
The moment legal asks the question, the answer already exists. You’re either the organization that can produce documentation or the one spending eight months reconstructing it.
Nothing about the model changes that. It was settled upstream, by decisions nobody was in the room for.
If You Couldn’t Answer Legal’s Question
Most teams discover the provenance gap mid-build, which is the expensive moment to find it. The cheap version is finding it before anyone writes code.
An AI Foundation Diagnostic reviews the data behind your active AI work and names the one thing blocking it, with the evidence attached. Three weeks, fixed scope and fee.
