What Dubai actually announced

On 16 September 2026, the opening day of GISEC Global in Dubai, the Dubai Electronic Security Center announced Saraab, an AI model intended to detect deepfake video. The announcement matters because this is not another anonymous browser tool or a short-lived product page. It comes from the government body responsible for protecting Dubai’s cyberspace, speaking at one of the region’s largest cybersecurity events.

The National reported, based on comments from DESC executive Amer Sharaf, that Saraab examines video frame by frame and uses a facial heat map to point to possible manipulation. Sharaf also said the tool would be made available as open source for people to download and use.

That is the public announcement. It is not yet a technical evaluation. As of 19 September, we could not find an official public repository, model card, benchmark, licence, model weights or API documentation for Saraab. Those materials may follow. Until they do, the sensible response is neither automatic applause nor dismissal. It is a list of questions.

A heat map gives the eye somewhere to look

Heat maps are appealing for a good reason. A fraud analyst faced with a long video needs more than a red or green badge. A marked region can help the reviewer return to a blink, mouth movement or boundary around a face and compare it with the surrounding frames.

But a coloured patch is not a finding by itself. Depending on the explanation method, it may show which pixels influenced the model rather than where an edit definitely occurred. A map can also move when the same clip is cropped, resized or compressed. If the interface does not explain what the colours mean, a vivid graphic can create more confidence than the underlying model earned.

The practical question is not whether Saraab has a heat map. It is whether the map stays useful across ordinary file damage and whether a second reviewer can reach the same interpretation without being led by the colour.

Open source is good news. It is not a quality badge

Opening a detector can make serious scrutiny possible. Researchers can inspect preprocessing, look for fragile assumptions, test unfamiliar generators and see whether a result can be reproduced. Security teams may also be able to run sensitive files inside their own environment instead of sending them to an unknown public service.

Source code alone, however, is not a complete release. A usable package also needs the model weights, exact preprocessing steps, supported formats, threshold logic, licence and a versioned model card. A benchmark is far more informative when it names the datasets, separates held-out material from training data and reports missed detections alongside false alarms.

None of this is a reason to doubt Saraab in advance. It is the normal evidence required before any detector—open or commercial—moves from an interesting demonstration into a business process.

The real test is an ugly file

Deepfake demonstrations tend to begin with a clean face filling the frame. Fraud teams rarely receive that file. They receive a clip downloaded from a social network, forwarded through a messaging app, recorded from another screen, trimmed in a mobile editor and uploaded with the wrong extension. The face may be small, poorly lit or visible for three seconds.

That journey can erase useful traces and introduce new ones. Compression blocks may resemble manipulation. Frame interpolation can smooth motion. A platform may change the frame rate or audio track. A detector that performs well on original benchmark footage can behave very differently after those transformations.

A fair pilot should therefore follow the media paths the organisation actually sees. Keep a clean reference, create documented platform and messaging copies, include authentic edited video, and reserve generators or manipulation methods that were not used to tune the threshold. Report results separately instead of folding every condition into one flattering accuracy number.

A business needs more than a classifier

A model can produce a score. A claims handler, trust-and-safety analyst or KYC reviewer needs a record. Which file was checked? Was it decoded successfully? Which model and threshold were used? Did the service analyse every frame or sample the clip? Can the result be exported later, after the model has changed?

For production use, the surrounding system matters as much as the prediction: stable job identifiers, file hashes, model versions, failure states, access controls, retention rules and an audit trail. A report should distinguish a completed negative result from a check that never ran. It should also preserve uncertainty instead of rounding every borderline case into a verdict.

This is where many promising models become difficult to use. The detector may be technically capable while the evidence around its output is too thin for a customer dispute, internal escalation or regulator review.

Five questions to put into the pilot plan

Before connecting Saraab—or any new deepfake detector—to live decisions, write the acceptance test first. Otherwise the team will be tempted to treat a few convincing examples as validation.

  • What authentic and manipulated data was used for training, tuning and final testing, and were people or generators shared across those sets?
  • At the threshold you intend to use, how many manipulations are missed and how many authentic files are falsely flagged?
  • What happens after recompression, resizing, cropping, screen recording, low light and short clips?
  • Are outputs reproducible and tied to a specific code, model-weight and configuration version?
  • Can sensitive media remain in an approved environment, and what files, thumbnails, logs or reports are retained?

Build the review around the file, not the model

The review should start before the upload. Preserve the best available original, record where it came from, calculate a hash and make a working copy for analysis. Keep the detector result with that record, including the model version, date, settings, warnings and complete output.

Treat the result as an observation. A strong signal can justify a closer review; a weak signal cannot prove that the person, event or caption is genuine. For decisions involving a claim, account, payment, employment or public accusation, compare the source trail, provenance and surrounding evidence, then record the human decision separately.

Where Saraab could be genuinely useful

If the public release matches the announcement, Saraab could give researchers, public-sector teams and smaller organisations a useful starting point for video triage. An inspectable model can be tested on local material, compared with other detectors and adapted to an environment where files cannot leave the organisation.

It could also make procurement conversations better. A team with a transparent baseline is in a stronger position to test paid services instead of judging them by marketing screenshots. Open and commercial systems solve overlapping but not identical problems: one may offer more control, while another supplies maintained infrastructure, support, reporting and service guarantees.

There is no rule that a serious workflow must choose only one. Independent signals can be valuable when their limits are understood and disagreements are sent to review rather than averaged into false certainty.

The honest conclusion

Saraab deserves attention. A government cybersecurity centre choosing to build and open a deepfake detector is another sign that media verification is becoming operational infrastructure rather than a novelty.

It does not yet deserve automatic trust, and it does not deserve automatic scepticism. The meaningful question is not simply whether the tool can be downloaded. It is whether a team can measure its errors, reproduce its output and explain a decision six months later.

When the repository and technical material appear, the next step is straightforward: inspect them, freeze a version, test representative files and publish the inconvenient results alongside the successful ones. Until then, Saraab is a promising announcement—not a validated verdict machine.

FAQ

Frequently asked questions

Is the Saraab deepfake detector available to download?

DESC said Saraab would be made available as an open-source tool. As of 19 September 2026, we could not locate an official public repository or download page, so teams should verify the publisher and licence before installing anything using the name.

Does a facial heat map prove that a video was manipulated?

No. A heat map may help show which regions influenced a model’s result, but it does not by itself establish that an edit occurred. Its meaning depends on the explanation method, preprocessing, threshold and submitted copy.

Can a business use an open-source deepfake detector?

Yes, but it should be validated on representative files and wrapped in appropriate security, versioning, logging and human review. Open source makes inspection possible; it does not remove deployment and governance work.

Does open source automatically mean private processing?

No. Privacy depends on how the tool is deployed, whether it calls external services, what it logs and who can access the host environment. A self-hosted installation can offer more control, but the implementation still needs review.

Should Saraab replace an existing detection API?

Not on the strength of an announcement alone. Compare it against a frozen test set, measure false alarms and missed detections, review operational requirements and decide whether it works best as a primary signal, a second opinion or a research baseline.

Automated results require source and context review.

Continue with independent verification.

Review the evidence API
Sources

Primary reading

We use original standards, regulators, public institutions and research papers wherever possible. Sources were last checked on 19 September 2026.