PROBLEM & REQUIREMENTS
AI intrusion detection for existing CCTV
Intrusion alerts from the cameras you already own: a snapshot, camera name and timestamp on your phone when someone crosses a boundary you set. Pilot-tested on your own cameras before anything is quoted.
Who this evaluation is for
A security supervisor defines a perimeter zone and schedule. The pilot distinguishes authorised deliveries and staff movement from entry that needs review. The response owner decides what to do; a detector does not establish criminal intent.
Define an observable event
A person enters a defined restricted zone during agreed hours — a rear loading bay after shift end, an electrical room, a chemical or scrap store, a perimeter line.
Limitations to test
The camera detects that a person entered the zone; it does not know whether that person was allowed to. Separating authorised from unauthorised entry needs a schedule, an access-control or permit record, or a person reviewing the alert. Occlusion, headlights, rain, vegetation and small or distant targets can create false alerts or missed events, and a working daytime test does not establish night-time performance.
Technical requirements
- Stable authorised stream and appropriate target detail at the far edge of the zone.
- Representative night lighting, camera angle and unobstructed approaches.
- Processing capacity, verified alert destination and an accountable response owner.
A scoped deployment example
Illustration: a warehouse tests a rear loading bay after shift end, alongside authorised cleaning and a scheduled collection. The outcome is a test log, not a claimed reduction in theft.
Acceptance-test approach
Agree ground truth, zones and eligible events first. Stage permitted crossings and legitimate exceptions. Count true alerts, false alerts, missed events and event-to-recipient delay. Repeat across agreed conditions and test stream loss.
Use the evaluation worksheet →Available evidence
PGAK has published recorded demonstrations of its own (listed on the evidence page), each with its conditions and limits. No customer result or measured accuracy report is published yet, and the deployment scenarios are illustrations, not verified deployments.
No PGAK recording is published for this use case yet, so it is not listed as an available capability. Ask for evidence of the exact workflow you need.
Inspect evidence status →Cost drivers and responsibilities
Camera count is only one input. Include processing, site preparation, configuration, integration, support, taxes and contract terms. Agree who maintains the feeds, reviews events and responds during an outage.
Understand project pricing →Privacy and safety boundaries
Use footage only for an authorised purpose. Restrict access and retention, preserve human review and keep analytics separate from safety-critical protective systems.
What a project here involves
Compatible cameras and recorders you already own are reused wherever they are suitable. Detection runs on an on-site processing unit, and camera suitability, stream access, processing hardware and network are all confirmed at the assessment — with anything extra itemised in the quote before you commit.
What the quote is made of
| Component | What decides it | Price |
|---|---|---|
| Cameras reused | Which existing cameras give a usable view for each use case — confirmed on a still image of each view. | Quoted per site |
| Cameras moved or added | Only where a use case needs a view no camera has (plates and faces usually do). Each one named in the quote. | Quoted per site |
| On-site processing unit | Detection runs here, next to the recorder. Model, quantity and warranty depend on camera count and analytics. | Quoted per site |
| Software / licences | Which analytics on which cameras, the term, and the basis for renewal. | Quoted per site |
| Installation and configuration | Stream setup, zones, schedules, alert routing and commissioning. | Quoted per site |
| Pilot | Agreed scenes, acceptance criteria and duration before rollout. | Quoted per site |
| Support | Hours, response versus fix time, and who replaces failed hardware. | Quoted per site |
| Taxes | Stated separately on the quote. | Quoted per site |
How it is evaluated
- 1. Self-check — Two minutes, nothing sent — find likely blockers.
- 2. Scope on paper — Cameras, use cases and acceptance tests, written down.
- 3. Site assessment — PGAK checks streams, views and network on your cameras.
- 4. Pilot against criteria — Precision, recall, false alerts and delay, agreed in advance.
- 5. Written proposal — Itemised as above; you decide whether to roll out.
Evidence for this page
No PGAK recording is published for this page yet. The capability register shows what has been demonstrated and under what conditions.
Discuss this use case
Send a callback request with this page’s context. Camera count is optional; do not include credentials or footage.