The gap between what AI surveillance deployments promise and what they deliver is almost never about detection capability. It is structural — in how the AI layer connects to the technology and organisational environment around it.
The gap between what AI surveillance deployments promise and what they deliver is almost never a gap in detection capability. The models, in most cases, work. The gap is almost always structural — in how the AI layer connects to, and operates within, the technology and organisational environment around it.
Edition #6 covered the pilot trap: the conditions that make proof-of-concepts succeed on criteria that bear no relationship to production reality. Edition #7 covered the first 90 days: the critical window in which compounding operational dynamics — alert fatigue, model drift, absent feedback loops — determine whether a deployment stabilises or quietly deteriorates.
This week we go a level deeper into the technical and organisational substrate that underlies both of those problems: the integration reality. What connecting AI surveillance to an existing enterprise security stack actually involves, where it breaks down, why those failures surface after the contract is signed rather than before, and what the organisations that navigate it well do differently.
There is a diagram that appears in almost every AI surveillance vendor's pre-sales material. Camera feeds flow into the AI engine. The AI engine generates events. Events flow into the VMS. Alerts route to the PSIM or SOC. Action is taken. The diagram is clean, linear, and accurate in the same way that a map of a city is accurate — it shows the right shapes in roughly the right places, and it omits everything that makes navigation difficult.
The integration reality in enterprise security environments is where that omission becomes consequential. The specific technical and organisational work required to make those connections function reliably, at scale, across a real camera estate, with real governance constraints and real operator workflows, is the work that determines deployment outcomes — and it is the work that is almost never scoped in the vendor proposal.
The first failure point that consistently surprises client teams is the gap between ONVIF compliance as a marketing claim and ONVIF compliance as a production guarantee. Every camera on the estate claims conformance. The AI platform claims conformance. The VMS claims conformance. And then, in a real multi-vendor deployment, the AI engine can pull video but not PTZ control, or receive motion events but not analytics metadata, or connect reliably to cameras from two manufacturers and intermittently to a third.
ONVIF conformance allows substantial variation in which features are implemented and how. Profile support across generations is uneven. Older Profile S cameras — which constitute a significant proportion of most enterprise estates — frequently lack the event models, codec support, and secure protocol implementations that modern AI platforms require. The result is that what was scoped as a software integration becomes a staged hardware refresh programme, with associated cost and timeline implications that were not visible before the contract was signed.
The VMS layer creates its own category of problems. Most VMS platforms were designed around a camera-centric data model: streams, channels, recordings, basic alarms. AI platforms operate on an entity-centric model: people, vehicles, zones, behavioural events with confidence scores and contextual metadata. Bridging those models consistently — so that AI events appear with full semantic richness in the VMS alarm pane and route correctly into PSIM and SOC workflows — typically requires custom integration work that vendor proposals describe as \"standard\" and integrators recognise as anything but.
The access control linkage is where the complexity becomes genuinely organisational. Most AI surveillance use cases that justify enterprise-level investment — tailgating detection, person-of-interest correlation, zone access validation — require the AI layer to map video events to cardholder identities and door objects in the PACS. In practice, that mapping requires clean, consistent data: standardised door naming, reliable camera-to-entrance associations, and a person-centric data model that many legacy access control schemas were never designed to support. What presents in the proposal as \"integration with existing access control\" translates on the ground into a data modelling and cleanup exercise that can take weeks before any AI correlation is possible.
The PSIM and alarm receiver layer adds a further dimension. PSIMs and central monitoring platforms are typically designed for low-rate, structured alarm inputs — a finite set of alarm types with fixed payload formats, routed from panels, intrusion systems, and fire equipment. AI platforms generate high-frequency, variable, semantically rich events. The integration between those two systems almost always requires normalisation: reducing AI events to a small number of alarm codes that the PSIM can ingest, losing the confidence scores, object attributes, and contextual metadata that make AI alerts operationally useful. The result is an AI layer that technically connects to the PSIM but delivers alerts that are indistinguishable from the legacy alarms the PSIM was already receiving.
Before any of these integration challenges are resolved, most enterprise security teams are working against a substrate of legacy CCTV infrastructure that compounds every one of them.
Estate audits in European enterprise environments routinely find multiple generations of camera firmware across a single site, with a material proportion of cameras on end-of-life hardware that cannot be updated to support secure protocols or the event models that AI platforms require. Networks were dimensioned for recording — enough bandwidth to push video to NVRs — with no headroom for the additional streams that AI inference requires, and no QoS policies designed for the latency requirements of real-time analytics. NVR and VMS servers running on unsupported operating systems and unmanaged hypervisors that cannot host GPU-accelerated workloads, and that introduce security and compliance risk under NIS2 and GDPR expectations.
The research on technical debt in enterprise IT is consistent on this point. Seventy percent of IT budgets in organisations carrying significant infrastructure debt go toward maintaining legacy systems rather than modernising them. That dynamic shows up in CCTV estates with particular force because physical security infrastructure has historically been managed on long replacement cycles, outside the IT governance frameworks that would have driven more systematic modernisation.
For AI deployments, this creates a specific and expensive dynamic: the value proposition of the AI layer depends on image quality, reliable event delivery, and consistent metadata — precisely the capabilities that legacy camera infrastructure cannot reliably provide. Teams that discover this after contract signature face a choice between accepting degraded AI performance or funding a camera refresh programme that was not in the original business case.
The integration work that vendor proposals do not scope falls into four categories, each requiring internal capability and coordination that most security teams are not structured to provide.
Network and infrastructure work. Re-validating VLAN design, WAN capacity, QoS policies, firewall rules, and storage architecture for the demands of live AI inference is IT infrastructure work, not security project work. It requires network engineers, infrastructure architects, and security operations to collaborate on requirements that span their domains. In most enterprise environments, that collaboration is not routine, and the coordination overhead is not trivial.
Data governance decisions. Defining what the AI layer can do with the data it generates — what derived data is retained, where it is stored, who can access it, for how long, and under what legal basis — requires DPO involvement, legal review, and decisions about purpose limitation and proportionality that most vendor proposals simply do not address. In European contexts, where GDPR and the EU AI Act's high-risk classification for surveillance applications create specific obligations around data minimisation, audit trails, and human oversight, these decisions cannot be deferred to post-deployment. They constrain architecture choices that must be made before deployment begins.
Identity and access management alignment. Getting consistent RBAC across the VMS, AI platform, PACS, and PSIM requires a coherent identity model that most organisations do not have for their physical security stack. SSO integration, role mapping, least-privilege enforcement, and audit trail consistency across these systems is an IAM project embedded inside a security deployment. Teams that attempt to handle it ad hoc — custom role mappings, shared credentials, informal access grants — create the compliance and operational risk that shows up in post-deployment reviews.
Workflow and process redesign. The most consistently underscoped element is not technical. It is the work of redesigning SOC and operator workflows to make AI alert outputs actionable rather than additive. Most deployments that reach production without this work become sophisticated alert pumps: the AI detects accurately, the alerts arrive in the right system, and the operator response is identical to what it was before the AI was deployed — because the workflow was never changed to accommodate a different kind of signal. The research on physical security AI operations is specific about this: most deployments are stuck generating detection alerts, while investigation, triage, and decision-making remain entirely manual, with SOC teams absorbing 800 to 1,500 alerts per day and spending 20 to 45 minutes of manual work per incident. Detection without workflow redesign is detection without value.
The organisations that navigate integration complexity without the delays and cost overruns that characterise most deployments share a single characteristic: they treat integration as the project, not as the final step of the project.
That starts with a rigorous estate and architecture review before any vendor conversation about AI capability. Camera inventory with firmware versions and ONVIF profile documentation. VMS API capability and event model assessment. NVR resource utilisation and headroom for additional workloads. Network diagrams with bandwidth measurements at representative sites. PACS data model review against the use cases AI is intended to support. The gaps identified in that review — and there will be gaps — determine the actual scope and cost of the deployment, not the vendor's pre-sales diagram.
They design and conduct interoperability testing before contract signature, not after. Not a curated PoC on the vendor's preferred cameras and a clean test network — a structured test on the real VMS, real PACS, real PSIM, and a representative sample of the actual camera estate, including the legacy hardware and the difficult sites. The test is designed with explicit failure criteria: if the AI platform cannot reliably ingest events from these camera models at production load, or cannot deliver semantically useful alerts into the existing PSIM without custom normalisation, the integration is not ready. That determination is worth making before the contract is signed.
They use a lighthouse site model for rollout. Rather than deploying across the estate simultaneously, they select one or two sites that represent the most complex integration patterns — mixed camera generations, constrained WAN, legacy PACS — and resolve the integration challenges there before codifying the solutions into a reference architecture for subsequent sites. The lighthouse site is not a simplified pilot. It is a full-complexity deployment, run slowly enough to build a replicable model from.
They assign explicit, cross-functional ownership to the integration programme. Not a vendor-led project with client sign-off at milestones — a client-owned programme with named internal owners for infrastructure, data governance, identity, and workflow redesign, each with defined deliverables and authority to make decisions in their domain. The vendor delivers the AI capability. The internal programme delivers everything the AI capability needs to function.
The evidence that integration — not model performance — is the primary failure driver for enterprise AI deployments has consolidated considerably in 2024 and 2025.
MIT research reported in 2025 found that approximately 95 percent of enterprise AI pilots fail to deliver measurable business impact, with integration, data, and governance gaps as the primary causes. The same reporting noted that around 42 percent of companies scrapped most of their AI initiatives in 2025, up from 17 percent the previous year, with escalating costs, data privacy concerns, and missing operational controls — all fundamentally integration and governance issues — as the dominant reasons.
Gartner analysis of 2024 AI deployments attributed the 60 percent POC abandonment rate primarily to data readiness failures and integration difficulties. BCG's October 2024 survey of AI adoption across industries found that 74 percent of companies struggled to achieve and scale AI value, with the primary drivers being missing data infrastructure and operating model changes — not algorithmic limitations.
For physical security specifically, research on AI-augmented security operations describes a field stuck at what it calls generation two: AI detection feeding dashboards, with investigation remaining manual, SOC teams absorbing hundreds of alerts per day, and no structural change to the workflow that determines whether those alerts translate into security outcomes. The integration that was supposed to change operations has instead added a new alert source to an already saturated environment.
The ONVIF data is pointed in its own way. ONVIF adoption at the checkbox level is near-universal across enterprise-grade cameras and VMS platforms. But analysis of production deployments consistently finds that conformance for advanced functions — analytics event semantics, access control integration, metadata richness — is uneven, with significant variation between vendors and across firmware generations. The standard provides interoperability at the basic video layer. It does not provide it for the features that make AI surveillance operationally meaningful.
European-specific dynamics add further complexity. Research on AI interoperability in EU contexts identifies siloed systems, incompatible data models, and absent cross-system governance as the core barriers to AI integration — not a lack of available technology. The EU AI Act's requirements for high-risk AI systems, including documentation, audit trails, and data governance, impose architecture constraints that most pre-sales integration proposals do not account for. Teams discovering those constraints post-signature face not just integration work but compliance-driven redesign.
Something that keeps coming up in conversations with security leaders who have been through a major AI surveillance integration.
The moment they most consistently describe as the turning point — the moment when they realised the project was different from what they had signed up for — is almost always the same: the first time they tried to route an AI alert into their existing PSIM or SOC workflow and make it actionable.
Not when the cameras failed to connect. Not when the VMS integration needed custom work. Those problems were visible and tractable. The harder moment was when everything was technically connected, the alerts were arriving, and the operators looked at them and did not know what to do differently than they had before the AI was there.
That is the integration problem that the pre-sales diagram does not show: not the protocol layer, not the API layer, but the workflow layer. How does an AI-generated alert, with a confidence score and an object attribute and a zone label, translate into a different operational decision than a legacy alarm with an alarm code and a camera number?
The organisations that answer that question before deployment — that redesign the workflow, define the triage logic, and train operators on what the new signal means and what they are expected to do with it — are the ones whose integrations deliver value. The ones that treat workflow as something to figure out after go-live are the ones whose AI layer quietly becomes a feature no one uses.
The integration is not done when the systems are connected. It is done when the operators know what to do.
The ONVIF Profile S deprecation timeline is a practical issue for any European enterprise currently planning an AI surveillance deployment.
ONVIF has indicated movement away from Profile S — the most widely deployed interoperability profile in enterprise CCTV estates — toward Profile T and subsequent profiles that better support analytics, event richness, and security requirements. Cameras and NVRs that are Profile S only, and cannot be updated to support newer profiles, are approaching a point where their compatibility with current-generation AI platforms will be limited to basic video ingestion, with no reliable support for the event and metadata capabilities that make AI analytics operationally useful.
For organisations with large proportions of legacy cameras in their estate — which describes most European enterprises with CCTV infrastructure more than five years old — this creates a practical planning issue that is separate from, and prior to, any AI capability decision. The camera refresh cycle that the estate requires is not a consequence of choosing an AI platform. It is a prerequisite for any AI platform to deliver consistent performance. Organisations that factor that refresh into their AI deployment business case and timeline before signing contracts are in a significantly different position from those that discover it during deployment.
The SafetyScope Knowledge Hub covers ONVIF profile compatibility, camera estate assessment frameworks, and integration guides for VMS and PSIM environments — reference material for teams in the early stages of scoping an AI surveillance deployment.
Published: 2026-04-15 · Updated: 2026-04-15