In new written answers to Lets Data Science, Resemble AI CEO Zohaib Ahmed explains how a third-party estimate became the largest component of its deepfake file total. The company confirms that January dates in its database refer to public reports, not a contemporaneous warning, and that its records cannot establish whether overall generation fell after restrictions. LDS examined the supplied four-record extract and 52 source references.
A database row dated January 2 can look like evidence that a monitoring system spotted a problem that day. In Resemble AI's Grok incident records, it means something more specific: a public report carries that date. It does not establish when the company entered the record or alerted anyone.
That distinction emerged in a follow-up written interview with Zohaib Ahmed, CEO of deepfake detection company Resemble AI. Lets Data Science asked the company to explain the evidence behind its Grok analysis, including the dates, grouping rules and estimates that feed its headline statistics.
Resemble supplied seven answers, followed by a spreadsheet extract containing four records and a second file containing 52 source references. Together, they provide a useful case study for people building incident databases, safety dashboards or research reports: a number can be calculated correctly while still answering a narrower question than its headline suggests.
Three dates that should stay separate
Ahmed distinguishes the period when images were produced, the publication dates of reports about them and the time Resemble entered information into its database. Those dates are not interchangeable.
The January 2 dates in the extract come from the earliest public Grok reports included in its data, he says. The company ingests information in batches and cannot provide a contemporaneous log establishing when those rows first entered its system. It offered a February 17 snapshot and later change history, but those were not among the two files supplied for this article.
Ahmed told Lets Data Science: "Resemble issued no public warning before the January 23 lawsuit."
The January 23 date is supported by the filing stamp on Jane Doe v. xAI, case 5:26-cv-00772. It is the particular federal complaint discussed in the interview, not a claim that no other Grok-related lawsuit preceded it. A complaint contains allegations, not findings of liability.
Resemble says its analysis appeared in its August midyear report. The evidence therefore supports retrospective aggregation of public reporting. It does not establish that Resemble predicted a lawsuit or issued an alert before the press had identified the problem.
For a team evaluating an early-warning system, the practical question is when the system made information available to someone who could act. An old date copied from a source cannot answer that on its own.
What sits behind the 87% figure
Resemble's H1 2026 Deepfake Threat Report says Grok accounts for 87% of its recorded synthetic-file total. Ahmed's explanation identifies the numerator: a rounded estimate of 3 million from the Center for Countering Digital Hate, or CCDH.
CCDH's January study sampled 20,000 image-containing posts from a reported population of 4,621,335 posts by Grok's account on X, covering December 29 through January 8. It estimated approximately 3 million photorealistic sexualized images, including about 23,000 appearing to depict children. These were extrapolations, not an inspection of every image. The study did not determine consent for everyone depicted, and its sexualized-image category should not be treated as a legal classification of every item.
Ahmed says Resemble carries the rounded 3 million estimate on a separate study record. Dividing it by the company's stated total of 3,459,442 gives about 86.7%, rounded to 87%. LDS checked that arithmetic.
The denominator needs the same attention as the numerator. Ahmed says it sums file estimates across 821 attack incidents, combining published numerical figures with a one-file minimum where no number was reported. It is not a uniform set of individually counted files. Nor does 87% mean that Grok caused 87% of the incidents or 87% of all deepfakes online.
Ahmed wrote: "It is not a count of all attacks, not a tally of everything on the internet, and not files Resemble individually verified."
The four-record extract confirms that the 3 million entry is present. It does not contain the full dataset needed to independently reconstruct the 3,459,442 denominator. The overall total remains a company-reported figure.
Four records, with different jobs
The supplied extract makes a distinction that was not clear in the initial description of three Grok incidents. Resemble says it grouped reports by tool, platform and time window, then separated three harm categories: adult nonconsensual imagery, impersonation and reputational harm, and material appearing to depict minors. A fourth record carries the CCDH study estimate.
Grouping related news reports can help prevent multiple articles about the same event from becoming multiple incident counts. But grouping reports and avoiding overlap between image counts are separate tasks. Keeping an estimate on its own row does not, by itself, demonstrate that every smaller count refers to different material.
The extract also contains fields that need care. Its three harm-category records carry smaller file values, but their provenance fields use a default-count label. Victim-count notes describe a merged minimum without a published individual count. Those labels do not establish verified totals of distinct files or people. This article therefore does not present the smaller figures as independently confirmed counts or use them to construct a new Grok total.
For readers working with similar data, the lesson is practical: preserve the original source, the unit being counted, whether it is an estimate or observation, and the rule used to merge records. Calling a quantity documented is not a substitute for that explanation.
Media exposure is another unit entirely
The records also carry large potential-media-reach figures. Ahmed says these come from a fixed reference of outlet audiences associated with coverage. They are not measured impressions on the harmful images or a count of people who saw them.
Adding publisher audiences can also include the same reader more than once. It cannot establish a unique audience without information that resolves that overlap.
The distinctions can be kept visible in a dashboard:
| Measure | What it describes here | What it does not establish |
|---|---|---|
| Incident record | A grouping of public reports under the company's rules | One unique victim, image or warning |
| File estimate | A reported count, extrapolation or minimum assigned to a record | A census of everything generated |
| Report date | When a cited report was published | When Resemble ingested it or issued an alert |
| Potential media reach | Outlet-audience estimates associated with coverage | Unique viewers of the images |
These are useful measures for different purposes. Combining their labels can make a report seem to show more than the underlying observations establish.
Fewer visible examples do not settle the overall trend
Asked whether it had measured changes in generation before and after Grok's restrictions, Resemble said it had not. Its evidence is the continuation of publicly reported incidents, not a measurement of total output across the service.
Ahmed wrote: "So your framing is correct: reduced visibility does not establish whether overall generation went up or down."
That does not mean researchers cannot measure a particular public channel. In a January 20 update, AI Forensics reported that the share of images depicting people in minimal attire in its sample of @Grok output fell from around half to below 10% by January 13 and 14. It also reported continuing problems on the separate app and website. That study has its own category, sample and dates; it is not a measurement of current, service-wide generation or directly interchangeable with CCDH's estimate.
The distinction matters when evaluating a safeguard. A change in the share of a sampled category, fewer public reports and a reduction in total harmful output are three different claims. Each needs evidence that measures the relevant outcome.
What a useful incident record should preserve
For practitioners, this interview suggests a concrete review before turning incident data into a risk score or trend chart:
- •Keep event time, source-publication time, ingestion time and alert time in separate fields. Leave unavailable timestamps unknown.
- •Label observed counts, third-party estimates and default minimums separately, with the source and relevant time window.
- •Document both how reports are grouped and how potentially overlapping numerical estimates are handled.
- •Preserve dataset versions so a later reconstruction is not mistaken for information available at the time.
- •Describe the observable population. News coverage can help identify reported patterns, but it cannot reveal every unreported incident or all activity inside a service.
This is LDS's practical reading of the evidence, not a workflow the company demonstrated or a product benchmark. Resemble's records help assemble and inspect the public account of Grok-related harm. The new answers make clearer which further evidence would be needed to turn that account into a claim about early warning, unique victims or changes in overall generation.
Reporting note
This LDS Exclusive is based on seven written answers attributed to Zohaib Ahmed and supplied directly to Lets Data Science through Resemble AI's communications representative, the company's H1 report, and the two supplied CSV files. LDS examined the four-record extract and 52 source references, checked the stated percentage calculation, and reviewed the cited primary research and complaint filing date. LDS did not independently verify every underlying incident, receive the complete 821-incident dataset or reproduce the studies' image classification. No harmful imagery was requested or reproduced. The article assesses the supplied evidence, not Resemble's detection-product performance or the merits of litigation.
Key Points #
- 1Resemble says its January record dates refer to public reporting, not ingestion timestamps or a warning it issued at the time.
- 2The rounded 87% comes from a third-party estimate divided by a company-reported total. It is not a share of all incidents or all deepfakes online.
- 3The supplied records do not measure service-wide generation changes. Counts, estimates, reporting dates and potential media audiences answer different questions.
Scoring Rationale #
Original written answers and a supplied four-record extract distinguish public reporting from alerts, estimates from counts, and channel observations from service-wide trends.
Sources #
Original reporting, with the public references used alongside it.
LDS Exclusive
Reporting based on written answers given directly to Let's Data Science by Zohaib Ahmed, CEO of Resemble AI.
[resemble.aiResemble AI: H1 2026 Deepfake Threat Report](https://www.resemble.ai/resources/h1-2026-deepfake-threat-report)
[counterhate.comCCDH: Grok sampling study and methodology](https://counterhate.com/research/grok-floods-x-with-sexualized-images/)
[aiforensics.orgAI Forensics: updated Grok research](https://aiforensics.org/work/grok-unleashed-updated)
View 1 more source #
Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.