Representative matters across litigation and corporate advisory practice. Details have been changed or composited to preserve client confidentiality, consistent with professional obligations.
A venture-backed AI startup came in three weeks before their Series A closed. Their pitch deck had a line about being "EU AI Act compliant" — nobody had actually classified which risk tier their hiring-screening product fell into. That's a materially different problem than "add a compliance slide."
The system touched employment decisions, which meant Article 6 high-risk classification was likely, not optional. Three days were spent tracing the model's actual decision logic against the Act's Annex III categories before we could say anything with confidence. It turned out to sit right on the boundary — defensible either way, but only if the reasoning was documented before an investor's counsel asked the question first.
What actually mattered: not the classification itself, but having the paper trail ready before due diligence started rather than reacting to it. The round closed on schedule. The compliance slide got rewritten to say something true.
A recruitment-technology company selling into the EU had a resume-screening product live with several enterprise clients, and roughly six months before the relevant EU AI Act high-risk provisions came into force, their general counsel asked a simple question: are we actually high-risk, or not? Nobody internally could answer it with confidence, because nobody had gone through Annex III line by line against what the product actually did, versus what the marketing described.
The honest answer, once the work was done, was yes — unambiguously. Annex III explicitly lists AI systems used for recruitment, including CV-sorting and candidate-ranking tools, as high-risk. That classification triggers a specific stack of obligations under the Act: a risk management system under Article 9, technical documentation under Article 11, human oversight design under Article 14, and post-market monitoring under Article 72. None of these existed yet in any documented form — the product had been built well from an engineering standpoint, but the governance paper trail was close to zero.
The work took three parts. First, mapping the actual model pipeline — what data trained it, what features it weighted, where a human recruiter could and couldn't override a ranking — against what Article 14's human oversight requirement actually demands, which is more specific than "a human looks at it sometimes." Second, building the technical documentation file from scratch, because retrofitting documentation after the fact is far harder than building it as you go, and this was already behind. Third, and hardest: convincing the product team that "explainability" wasn't a UX nice-to-have but a binding obligation under Article 13, which meant a scoping conversation with engineering about what could realistically be exposed to a candidate who requested an explanation of their score.
What actually mattered: the conformity assessment itself was almost the easy part once the underlying documentation existed. The hard part was translating "Article 14 human oversight" into a specific, testable interface requirement that engineering could actually build against, rather than a compliance abstraction sitting in a policy document nobody reads.
A payments processor had built a genuinely careful DPDPA compliance program — data fiduciary registration, consent flows, the works. What they hadn't accounted for was that a chunk of their processing had quietly started routing through a European sub-processor as they scaled, and nobody had checked whether their contracts covered that.
The DPDPA's cross-border transfer rules are more permissive than GDPR's — which meant the India-side program didn't automatically protect the EU-side exposure. It took going through actual data flow diagrams, not the privacy policy, to find where the gap was: one sub-processor agreement that had never been updated to include GDPR-standard SCCs.
What actually mattered: the fix was one contract amendment, but finding it required looking at what the infrastructure actually did rather than what the policy said it did.
A consumer health-and-wellness app with several million Indian users had a consent screen that looked, on its face, like good practice — separate toggles for marketing, analytics, and third-party sharing. The problem surfaced during a DPDPA Section 8 obligations review: those toggles were cosmetic. Underneath, a single consent flag in the database gated all processing, meaning a user who declined marketing consent was, in practice, still having their data processed for purposes they'd explicitly opted out of.
This is a specific, common failure mode: consent architecture designed by a product team without a data-flow map showing what each toggle actually controls downstream. Section 8's data fiduciary obligations require that processing actually be limited to the specified, consented purpose — a cosmetically granular consent screen sitting on top of an ungranular backend doesn't satisfy that, it just creates a false paper trail that makes the problem worse if a regulator or a user ever audits it.
Fixing it wasn't a policy rewrite; it required engineering to tag data flows by purpose at the point of collection, not just at the point of display. That took longer than the legal analysis did. Alongside it, the breach-notification workflow was tested for the first time — not reviewed on paper, actually tested, with a tabletop exercise simulating a leaked database. It revealed that the person named as the point of contact for a Data Protection Board notification had left the company eight months earlier, and nobody had updated the plan.
What actually mattered: the gap wasn't the legal framework being unclear — DPDPA's obligations here are fairly specific. The gap was that compliance had been designed as a UI layer rather than as something wired into the actual data architecture underneath it, which is where an audit, or a breach, would actually look.
A young IT professional in Hyderabad found himself named in a cybercrime complaint after a colleague's account was accessed without authorization from an IP address traced to his office network. He had, in fact, shared a workstation temporarily with three other employees during a system migration two weeks earlier — a fact that existed only in an internal ticketing log nobody had thought to preserve before the complaint escalated.
The first days after a Section 66 IT Act complaint is filed matter disproportionately. The immediate work was not arguing innocence in the abstract, but securing the ticketing system logs, the building's access-card records, and the workstation's login history before routine data retention policies quietly deleted them — evidence that existed only for a finite window and would have been gone within the month.
The matter proceeded to an anticipatory bail application while the factual record was still being assembled, since the accused's cooperation with the investigation needed to happen without custodial risk hanging over every interaction with investigators. The device forensics, once obtained, corroborated the shared-workstation account and materially changed how the investigating officer approached the matter.
What actually mattered: being accused in a cybercrime matter is a race against evidence retention as much as it is a legal argument. The single highest-value early decision was which records to preserve immediately, before anyone else in the chain had reason to.
A small business owner in Warangal lost a significant sum through a UPI-based fraud where the fraudster impersonated a payment gateway support agent. The bank's initial response treated the transaction as customer-authorized, since it had been completed using a legitimate one-time password — despite the OTP having been obtained through active deception, not a security failure of the bank's systems.
The distinction between "authorized" and "obtained through fraud" is where most victims lose ground procedurally, not on the merits. The work here involved filing promptly on the National Cyber Crime Reporting Portal to trigger the account-freeze mechanism before funds moved further downstream, then building a formal representation to the bank's grievance redressal officer that reframed the transaction correctly under RBI's customer liability circular for third-party fraud, rather than accepting the bank's initial "authorized transaction" characterization.
Parallel to the banking-side representation, a criminal complaint was pursued to create an official investigative record — not only for potential recovery, but because a documented FIR materially strengthens a civil recovery claim if the banking-channel remedy stalls.
What actually mattered: speed on the freeze request, and correctly characterizing the transaction under the applicable RBI framework rather than letting the bank's default "authorized" classification stand unchallenged.
CERT-In's six-hour reporting window is unforgiving by design. A mid-sized fintech had an incident at 11pm on a Friday — the kind of timing that tests whether an incident response plan is real or just a document. It was mostly real. The gap was that the plan named who should be notified but not who had the authority to actually make the call under pressure with incomplete information.
Two hours were spent on the phone that night, not drafting anything, just helping the team distinguish between what had to be reported now under the six-hour rule versus what could be supplemented in the follow-up filing. Getting that distinction right was the difference between a clean, defensible filing and a panicked overcorrection that admits more than the facts support.
A team building orbital data-center infrastructure had every terrestrial compliance box checked — data residency, encryption standards, the usual. What they hadn't considered was the layered liability question sitting above all of it: under the Outer Space Treaty, the launching state carries international responsibility for the satellite's activities, regardless of where the company is incorporated.
That meant a decision made by an onboard AI system for data routing could implicate state responsibility, operator liability, and AI governance obligations simultaneously — three different legal frameworks that don't share a common vocabulary. Most of the early work wasn't drafting anything; it was building a shared map of which questions belonged to which framework, because the team's engineers and their existing counsel were talking past each other.
Hyderabad's IT corridor hosts dozens of global capability centers, and disputes involving departing engineers and source-code repositories are becoming a recurring pattern rather than an exception. A mid-sized product company discovered that a former employee's credentials had been used to access a private repository nine days after his exit interview — access that should have been revoked immediately but wasn't, due to an offboarding gap between HR and IT.
The matter combined a Section 66 unauthorized-access complaint with a civil claim for breach of confidentiality obligations under the employment contract. The technical work was establishing, through access logs and git commit metadata, that the credentials were used post-termination rather than during a legitimately overlapping notice period — a distinction the company's own offboarding failure had made genuinely ambiguous on the surface.
What actually mattered: the offboarding gap was the company's own operational failure, and acknowledging that candidly in the pleadings, rather than overreaching on the unauthorized-access claim, kept the matter credible before the court and strengthened the confidentiality claim that actually had the stronger factual footing.
A regional ISP referred a matter involving a dispute with a telecom licensor over subscriber data-sharing obligations under license conditions — on its face a commercial billing disagreement, but substantively a question of how far a licensee's data-handling obligations extend under both the license agreement and DPDPA once subscriber data changes hands between commercial entities.
Matters before the Telecom Disputes Settlement and Appellate Tribunal (TDSAT) require a specific procedural posture distinct from ordinary civil litigation, and the substantive overlap between telecom licensing conditions and data protection obligations is not yet well-mapped in practice — which meant briefing the matter required building the connective argument between two regulatory frameworks that don't reference each other directly.
What actually mattered: recognizing early that a "billing dispute" was actually a data-governance dispute in disguise changed the entire briefing strategy, and avoided arguing the weaker commercial point while the stronger regulatory one sat unaddressed.
A digital lending NBFC using a machine-learning credit-scoring model was notified of an upcoming RBI compliance review, six weeks before the review date. Their model had never been formally documented against the Reserve Bank's Digital Lending Guidelines or assessed for algorithmic bias in a way that would satisfy a regulator asking pointed questions about disparate outcomes across applicant demographics.
The compressed timeline meant prioritization: documenting the model's decision logic and feature weights first, since that's what a reviewer asks for immediately, followed by a bias audit across the protected-characteristic-adjacent variables the model used as proxies (pin code, employment category) even though it didn't use protected characteristics directly — a distinction regulators are increasingly unwilling to accept at face value.
What actually mattered: the model itself didn't need to change on this timeline. What needed to exist was a defensible paper trail showing the company understood its own model's behavior, which is what actually satisfies a regulator under time pressure.
A health-tech company building an AI-assisted radiology screening tool was finalizing a partnership with a hospital chain for pilot deployment. The commercial terms were agreed; what hadn't been addressed was where liability sits when the AI tool's output influences a diagnosis that turns out to be wrong — a question that sits at the unresolved intersection of medical negligence law and product liability for AI systems.
The work involved structuring the partnership agreement to allocate this risk explicitly rather than leaving it to be litigated after an adverse outcome: defining the AI tool's role as decision-support rather than decision-making, documenting the required human-radiologist sign-off step as a contractual and not merely operational requirement, and ensuring the company's liability insurance actually covered AI-assisted diagnostic tools, which several standard policies do not.
What actually mattered: the legal work here was almost entirely preventive contract architecture, done before deployment, because the alternative — litigating an undefined liability allocation after a misdiagnosis — is a far worse position for every party involved, including the hospital.
Hyderabad's aerospace and satellite manufacturing base has grown quickly, and a small-satellite component manufacturer preparing for a foreign launch partnership needed to resolve an export-control and licensing question its existing corporate counsel, capable in general commercial matters, had not encountered before: which of its component technologies triggered dual-use export licensing requirements before they could legally leave the country for integration with a foreign launch vehicle.
The work required mapping the specific components against India's SCOMET (Special Chemicals, Organisms, Materials, Equipment and Technologies) export control list, since a launch delay to resolve a licensing question discovered late is far more costly than resolving it early — and coordinating the licensing application timeline against a launch window that could not realistically move.
What actually mattered: catching the export-control question during contract negotiation with the foreign launch partner, rather than at the point of shipment, kept the licensing process from becoming the constraint on an already fixed launch date.