I once saw a USD 40 million account shut down over a single image.
Someone sent an SOP to a friend at a competitor, to use as a template for building their own. They had carefully scrubbed every customer reference from the text, but missed one screenshot with the customer's name on it.
The intent wasn't malicious. It was a favour between peers, the kind that happens on every delivery floor. But the controls were built to catch bad actors, not helpful ones, and the only safeguard was one person's manual check.
I have spent 30 years in BPO operations, GCC setups and transitions. That story has stayed with me because the pattern behind it hasn't changed. If anything, AI has made it more expensive.
Contracts live at the top. Data lives on the floor.
Outsourcing contracts are negotiated at the relationship level, between procurement, legal and the vendor's leadership. Data doesn't move at that level. It moves at the floor level: across shifts, through team leads, into subcontracted overflow capacity, through a "temporary" tool somebody approved during ramp-up and never retired.
Every hand-off between your organisation and the person actually touching the data loses a little visibility. By the time work reaches the floor, the contract describes an operation that only partly exists.
For years this gap was mostly a commercial risk. Under India's Digital Personal Data Protection (DPDP) Act, it becomes a regulatory one.
What DPDP changes
DPDP is clear on one point that matters more than any other for outsourced work: the data fiduciary remains responsible for what its processors do. Outsourcing the work does not outsource the accountability.
The stakes are material. The Act's Schedule sets penalties of up to ₹250 crore for failing to take reasonable security safeguards to prevent a personal data breach, and those safeguards extend to your vendors. Core obligations become enforceable in May 2027.
AI work sharpens the problem. Annotation, review and quality teams often need the raw, unmasked record (names, faces, voices, financial detail), because good labels need full context. Standard masking controls often can't be applied. And this work is usually bought as a service, not reviewed as data processing.
Why tooling alone won't close the gap
The default response to DPDP is a tooling programme: data loss prevention, masking, access management. All useful. None of it would have saved that USD 40 million account.
Tools enforce rules at the points where someone designed them in. Floor-level failures happen in the spaces nobody designed for: a favour, a workaround, an overflow team added in a hurry, a deletion that was promised at exit but never checked. Those are not technology gaps. They are operating-model gaps, in how work is contracted, transitioned, staffed and governed.
Four questions for leadership
These are the questions I would ask any organisation running AI or data operations through third parties. None of them can be answered by buying a platform.
- Does your vendor contract name the subcontractors, or just permit them? A clause that allows subcontracting "with notice" is not visibility. You need a named, current map of every entity that touches your data.
- When the vendor added capacity during ramp-up, who approved where that capacity sat? Ramp-ups and transitions are where the operation drifts furthest from the contract. If nobody on your side signed off on locations and teams, nobody on your side knows them.
- Is deletion on exit a clause, or a process someone actually verifies? Most contracts promise deletion. Very few organisations ever confirm it happened, across every copy, export and backup.
- Does anyone own the vendor chain end to end? In most organisations it falls between Procurement, Security and the AI or business team. Each owns a piece; nobody owns the chain. That gap is where incidents live.
What fixing it looks like
Closing these gaps is operating-model work, not a compliance project:
- Map the chain as it actually runs. Every entity, location and team that touches the data, verified at floor level, not taken from the contract.
- Design transitions with a data boundary. Ramp-ups, vendor changes and capacity moves get an explicit check on where data goes and who approves it.
- Make deletion a verified process. A defined owner, a defined evidence standard, and a sign-off at exit.
- Give the chain a single owner with the authority to act across Procurement, Security and the business.
- Build it into the governance cadence. Vendor reviews should cover data-chain evidence, not just SLAs and cost.
Start before it becomes incident response
May 2027 is roughly one vendor-contract renewal cycle away. Renewals are the natural moment to fix contract terms, subcontractor visibility and exit obligations, but only if you know what to ask for.
If your AI or data operations run through third parties, now is the time to map the chain, while fixing it is still a design choice and not an incident response.
Valiarch runs a short, fixed-scope diagnostic that maps your third-party data chain against DPDP obligations and gives you a prioritised fix list before enforcement begins.
This article is a perspective on operating models and is not legal advice.