The usual assumption is that AI video analytics means buying AI cameras. It generally does not. Analytics needs a readable stream, and most IP cameras installed in the last decade expose one through ONVIF or RTSP — the analysis then runs on a server, not in the camera. What actually decides whether a given camera is usable is where it points, what it can resolve at the distance that matters, and how the light behaves there. The way to find that out is to test your own recorded footage, not to read specifications.
A security estate gets installed once and then grows by accretion. By the time someone asks whether the cameras could count people, spot a blocked fire exit or flag a process problem, there are eighty of them from four vendors across three generations, and the instinct is to assume none of it is usable.
That instinct is usually wrong, and it is expensive. The question is not how old the cameras are. It is whether each one produces a stream something else can read, and whether it is looking at the thing you care about.
Why camera age matters less than you think
There are two places the analysis can happen. On the camera, which is what an "AI camera" means and which ties you to whatever models that particular chip supports and whether the vendor still updates it. Or on a server that reads the camera's stream, which leaves the camera as a camera and puts the intelligence somewhere you control and can upgrade.
For a retrofit, the second is nearly always the right answer. It means a 2017 camera and a 2025 camera are equally useful as long as both emit a standard stream — and it means improving the model later is a software change rather than a procurement cycle.
ONVIF is the interoperability standard for IP cameras and RTSP is the streaming protocol most expose. If a camera is ONVIF-conformant or gives you an RTSP URL, an analytics engine can usually consume it without a vendor-specific integration. That combination has been the industry norm for long enough that most of an existing estate qualifies.
Keeping the footage on site
Running the analysis on your own server rather than in a vendor cloud is not only a cost decision, though it is that too — continuously uploading eighty streams is a real bandwidth line item.
It is mostly a data decision. Video of people in a workplace is personal data, and the moment it leaves your network you have a transfer, a processor and a retention question to answer. Keeping the analysis local means the frames stay put and what leaves is metadata — a count, an event, a flagged clip. That is a much easier conversation with a works council, a DPO or a customer's security team, and it is why on-premise is the default we reach for. The cost side of that choice is worked through separately in on-prem vs cloud AI inference.
The part vendors are quiet about
You will see claims that some large proportion of existing cameras qualify as-is. Treat those as marketing: the real number depends entirely on what you are asking the system to detect and where the cameras happen to point.
A camera installed to deter theft is usually mounted high, wide and far — excellent for seeing that something happened, poor for reading a label, counting items on a line or determining whether someone is wearing eye protection. The compatibility question has a clean technical answer. The usefulness question is per-camera and depends on:
- Pixels on target. Not the sensor's resolution, but how many pixels land on the thing you need to classify, at the distance it actually sits.
- Lighting across the day. A loading bay at 11am and at 6pm in winter are different detection problems. Mixed artificial and daylight is harder than either.
- Frame rate. Fine for counting people walking; marginal for anything moving quickly or for tracking across a crowded scene.
- Occlusion. Racking, vehicles, other people. A camera with a clean line of sight at installation often does not have one two years later.
- Angle. Steep downward views compress everything and make some classifications close to impossible.
Sitting alongside what you already run
Most estates already have a video management system or a recorder, and most analytics layers are built to coexist with one rather than replace it — reading streams and surfacing detections either back into the VMS or in their own interface.
That is usually the right shape, with one caveat worth settling early: decide which system owns alerting. Two systems both able to raise an alarm, with different rules and different audiences, is how a control room ends up ignoring both. Pick one, and make the other feed it.
How to pilot it properly
The temptation is to pilot on the best cameras, which tells you very little. The purpose of a pilot is to find out how many of your cameras are unusable, because that number decides whether this is a software project or a camera-replacement programme.
- Pick representative cameras, not flattering ones. Include at least one awkward mount and one with difficult light.
- Test against your own recorded footage first. Before anything is installed, before anyone is on site. Historic video is the cheapest test data you will ever have.
- Include the hard hours. Shift change, dusk, the winter afternoon when half the lights are on.
- Measure false alerts, not just detections. A system that is right most of the time and cries wolf twice an hour will be switched off within a month, and the accuracy figure will not explain why.
- Write down what "good enough" means before you look at the results. Otherwise the pilot becomes a demo.
A pilot run this way answers the only question that matters at the start: which cameras work, which need moving, and which genuinely need replacing. That list is worth considerably more than a proof of concept on a camera chosen because it was easy.
Questions we get asked
Do we need new cameras for AI analytics?
Usually not. Analytics needs a readable stream, which most IP cameras from the last decade provide via ONVIF or RTSP, and the analysis runs on a server rather than in the camera. Age matters far less than whether it exposes a standard stream and points somewhere useful. Analogue cameras need an encoder first.
What are ONVIF and RTSP, and why do they matter?
ONVIF is the interoperability standard for IP cameras; RTSP is the streaming protocol most expose. Together they let an analytics engine read a feed without a vendor-specific integration — which is what makes retrofitting cheaper than replacing.
Where does the analysis run?
On the camera (limited to that chip's models), on a server in your own network (the usual retrofit answer, footage stays on site), or in the cloud (continuous upload, with bandwidth and data-residency consequences). For existing estates, an on-premise server reading existing streams is normally the practical choice.
What actually limits accuracy?
Rarely the model. Placement, pixels on target at the real distance, frame rate, lighting changes and occlusion do most of the damage. A camera mounted to deter theft is often pointed badly for counting or inspection. Test the real footage rather than the datasheet.
Can it work with our existing VMS or NVR?
Often yes — several analytics layers are built to sit alongside an existing system rather than replace it. The trade-off is another component to integrate and maintain, so decide which system owns alerting before anything is installed.
How should we scope a pilot?
Representative cameras rather than the best ones, including an awkward mount and difficult lighting, tested against your own recorded footage before any live deployment. The point is to learn how many cameras are unusable — that number decides the shape of the project.
We build computer vision that runs on a client's own cameras and network rather than in a vendor cloud. If you are weighing this up, the first useful step is sending us a few hours of your own footage from the awkward cameras — that tells us more in an afternoon than a specification review does in a week.