When is on-premises deepfake detection required?
Four situations usually drive the decision. Evidence handling is the first: police, prosecutors and courts need chain of custody, and sending exhibits to an outside service can complicate it. Classified or sensitive government systems are the second, where networks are isolated by policy. Data residency and sovereignty are the third, where regulators or contracts require biometric data to stay in a country or a specific facility. The fourth is risk appetite, where a bank or telecom operator decides that faces and voices of millions of customers should not cross its perimeter at all.
If none of these apply, a managed API or private cloud is usually cheaper and gets model updates faster. The table compares the options Neural Defend offers.
| Option | Where media is processed | Who operates infrastructure | Model updates | Typical fit |
|---|---|---|---|---|
| Managed cloud API | Vendor cloud | Vendor | Continuous, vendor-managed | Fast integration, variable volume |
| Private cloud or VPC | Customer's cloud account or dedicated tenancy | Shared | Scheduled releases | Cloud-first firms with residency needs |
| Secure container | Customer infrastructure, packaged by vendor | Customer | Pulled from a registry on schedule | Teams with container platforms |
| On-premises | Customer data centre | Customer | Delivered packages, installed by customer | Regulated firms, evidence handling |
| Air-gapped | Isolated network with no internet route | Customer | Signed offline bundles carried in | Defence, intelligence, sensitive forensics |

What does running detection on-premises involve?
Detection models are compute-heavy, so capacity planning comes first. Size for peak request rates by modality, because video and audio analysis cost far more than a single image, and confirm the hardware profile the vendor has tested. Then integrate with your identity and access management for administrators and service accounts, your secrets store, your logging and monitoring stack and your backup system.
Network design follows zero trust principles. NIST SP 800-207 describes an architecture where no component is trusted because of its network location, and access is granted per request based on identity and policy. For a detection service that means authenticated calls from named applications only, no default outbound internet access, and administrative access through audited, privileged paths.
Plan observability before installation. A managed API gives the vendor visibility into errors and latency; a self-hosted install does not, unless you export metrics to your own monitoring. Agree which health and evidence metrics the service exposes, where they are stored, and how your team will share diagnostic information with the vendor during an incident without sending media out of the facility.
Can deepfake detection run fully air-gapped?
Yes, with a disciplined update process. In an air-gapped network the detector cannot call home for licences, telemetry or models. Everything it needs arrives as a package carried across the gap, and every package must be verified before installation. NIST's Secure Software Development Framework (SP 800-218) sets practices for protecting software integrity and verifying releases, which translate into signed bundles, published hashes and a documented chain of custody for the media used to transfer them.
The trade-off is freshness. New generators appear every few months, and a detector that is never updated slowly loses ground. Agree an update cadence with the vendor, keep a staging enclave inside the gap where new versions are tested against your sentinel set, and record which model version produced each result so older analyses can be reviewed after an update.
Which security controls matter most for a self-hosted detector?
Treat the detector as a system that holds sensitive personal data and produces evidence. NIST SP 800-53 Revision 5 provides the control families most teams map to.
- Access control and identification: separate roles for operators, reviewers and auditors, with multi-factor authentication for administrators.
- Audit and accountability: log administrative actions, model changes and access to media, and protect logs from tampering.
- Media protection: encrypt stored media and derived views and enforce retention dates automatically.
- System and information integrity: verify every installed package and monitor for unauthorised changes to model files.
- Contingency planning: test backup, restore and failover, and define how the service is decommissioned and its data destroyed.
What should be tested before an on-premises deployment goes live?
Run acceptance tests that prove the install behaves like the vendor's reference build and survives failure. Start with result parity: process the same labelled sentinel set on both and confirm scores and decisions match within an agreed tolerance. Then test latency and throughput at peak load per modality, failover when a node is lost, restore from backup, and the full update procedure, including rollback to the previous model version.
Finish with a documented responsibility matrix. Name who patches the operating system, who monitors capacity, who receives vendor security advisories, who approves model updates and who handles incidents. Gaps in that matrix are where self-hosted systems usually drift out of compliance.
Repeat the parity test after every model update, not only at go-live. Drift between the on-premises build and the reference build is easy to miss when nobody compares them.
How Neural Defend supports on-premises and air-gapped deployment
Neural Defend offers five deployment options: managed cloud API, private cloud or VPC, secure container, on-premises and air-gapped. The right one is scoped during evaluation against your data, network and update requirements. The company holds ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 42001 and SOC 2 Type II certifications.
NeuroDetect suits isolated forensic environments, where investigators upload authorised images, audio, video and documents into cases, each analysis keeps model and version context, and the forensic report records observations, uncertainty, provenance and analyst notes. NeuroVerify brings its six-signal check and unified risk score to onboarding systems that must stay inside a bank's or operator's perimeter. Both are built on ARCAS 1B, whose September 2026 paper reports pooled accuracy from 97.65% on OpenFake to 99.99% on GenImage.
Evidence boundary
Limitations
- Self-hosting shifts capacity, patching, monitoring and recovery duties to the customer, which adds cost and operational risk.
- Air-gapped installations receive model updates less often and may lag on newly released generators.
- Hardware sizing depends on modality mix and peak volume and must be confirmed with the vendor for each deployment.
- Certifications cover Neural Defend's own controls, not the customer's infrastructure where an on-premises install runs.
Source record
Sources and references
- National Institute of Standards and TechnologyZero Trust Architecture (SP 800-207)Verified August 7, 2026.
- National Institute of Standards and TechnologySecurity and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5)Verified August 7, 2026.
- National Institute of Standards and TechnologySecure Software Development Framework Version 1.1 (SP 800-218)Verified August 7, 2026.
- arXivBenchmarking Neural Defend ARCAS 1B: A Foundational Multimodal Deepfake Detection ModelPublished September 21, 2026. Verified October 19, 2026.







