Rakshak AI is a software layer for the CCTV already installed at border outposts and check posts. It analyses every feed, learns what ordinary movement looks like at each post, and brings forward only the events that need an officer's attention, each with its reasons and a record that holds up later.
of open India–Nepal and India–Bhutan border guarded by the SSB1
SSB Border Out Posts on these two frontiers2
of those posts without road connectivity2. Hardware-heavy systems are hard to deliver and maintain there.
people rescued from traffickers by the SSB on the India–Nepal border in 20233
Sources are listed at the end of the page.
Under the 1950 Treaty of Peace and Friendship, Indian and Nepali citizens cross without passport or visa, to work, to trade at weekly haat markets and to visit family4. Movement never stops, and it swells on market days and at festivals.
The SSB's task is to find the unlawful fraction inside that movement: smuggling, trafficking, contraband. In 2023 alone it seized over 11 lakh kg of contraband in 2,068 cases3. Almost every interception began with a person noticing something.
Conventional CCTV gives recording and a live view, and someone has to keep watching. Research on operator vigilance shows attention to multi-screen video drops within minutes. A widely cited industry figure puts missed activity at up to 95% after 22 minutes5.
Face recognition, number-plate reading and intrusion analytics usually arrive as dedicated appliances and proprietary smart cameras. They are expensive to buy and to maintain, and hard to take to 308 posts that have no road.
A rule that fires whenever someone crosses a line fires all day on this border. Operators learn to ignore it, and then it gets switched off. The detector isn't the weak point. Treating ordinary movement as the event is.
Suppose a busy post sees 10,000 crossings in a period and 10 of them are unlawful. A detector that is right 99% of the time on both kinds still raises about 110 alerts, and about 100 of them are false. Try the numbers yourself.
Every movement is a candidate, as with a virtual fence or tripwire.
The base rate works against even a good detector. The way out is to judge each movement against what is normal for this camera, at this hour, on this kind of day: its usual paths, its market days, its festival surges. Measured that way, 10,000 ordinary crossings shrink to a small set of genuinely unusual ones. Among those, a good detector becomes decisive. Radar engineers call the same idea CFAR, a constant false-alarm rate: the threshold follows local background levels, so the alert rate stays steady however busy the border gets.
The second scenario is illustrative arithmetic, not a measured result. It assumes unlawful movement is unusual in context. Someone who moves with the crowd, on the usual path at the usual hour, stays in the background, and we say so plainly below.
The cameras, cabling and control-room screens already exist. Rakshak AI adds one commodity computer at the post and software that turns those feeds into decisions and records. Nothing on the camera side changes.
One commodity box per post. No GPU, no cloud, no new cameras.
Existing IP cameras, USB cameras, phones and recorded footage.
Partly builtFrames decoded, normalised and buffered, so every frame shown is the one analysed.
WorkingObject and weapon detection on a CPU, with no special hardware.
WorkingTracks, cross-camera journeys and behavioural context, judged against the post's normal.
Partly builtOne incident per event, with severity, reasons, sound and operator actions.
WorkingReports, history and export, plus sealed evidence and drafted paperwork.
Partly builtDetection models are widely available and interchangeable. What makes a system usable at a real post is how it decides, what it hands over and how much work it saves. Each principle below is marked with where it stands today.
Each post learns its own pattern of lawful movement, and an alert fires only when the evidence against that pattern is strong enough.
The output of the system is a record that can be produced in court, not only a notification.
Surveillance becomes useful to an investigation when events connect across cameras, hours and days.
A system gets switched off when it adds work. This one is designed to take work away and to be directed like any other collection asset.
Illustration. Designed for posts with nobody at a screen: one image, one reason, one honest confidence and three buttons. "Not a threat" teaches the system.
| Conventional intrusion analytics | Rakshak AI | |
|---|---|---|
| What triggers an alert | Someone crosses a line or enters a zone | Evidence builds up against this post's learned normal until it is enough |
| Threshold | Tuned by hand, the same everywhere | Set per camera and hour from local history |
| Alert volume | Found out in the field, usually too late | A design parameter held within a stated budget, busy days included |
| Confidence shown | A score such as "87/100" | A calibrated frequency: "4 in 5 at this level were genuine" |
| When the world changes | A new road means weeks of false alarms | The shift is detected as drift and recalibration is recommended |
| When data is thin | Guesses silently | Reports "insufficient data" and uses conservative rules |
| What is handed over | An exported video clip | A sealed clip, a hash-chained log and a drafted Section 63 certificate |
The prototype is live software. Every screen below is a real capture, and every capability in this section can be tried in it. It is the perception and alerting base that the decision and evidence layers are being built on.
A YOLOv8n model running on ONNX Runtime detects people, cars, buses, trucks, motorcycles, animals and dozens of other everyday objects (80 classes) on every feed, all on a CPU.
A dedicated model detects guns, knives, grenades and explosions. A weapon counts only if it is seen on two passes and a hand-held one sits inside a detected person, which rules out one-frame errors.
Every person gets an ID. Across five synchronised cameras, appearance matching links a person only between cameras they could walk between, and a timing check rules out being in two places at once.
One incident per camera and threat type, with severity, a sound alert, "Working on it" and "Resolved" actions, notes and a complete history. Incidents survive restarts and export to CSV.
Recorded CCTV, laptop and USB webcams, and phone cameras over the local network (scan a QR code) or a USB cable. You can switch sources without restarting, and every source goes through the same detection and alerts.
Video is shown a few seconds behind live so boxes are drawn on the exact frames that were analysed. Each camera reports Online, Signal problem or Offline, and a stalled detector is flagged.
What the prototype is not yet. It reads recorded footage, webcams and phones. Direct RTSP/ONVIF ingestion from IP cameras is the first item in the next build stage. Its alerts come from fixed rules, not yet from a learned baseline. Footage is from public datasets and stock sources, not from a border post. Throughput figures are from a laptop that is also serving the dashboard.
Every capability the problem statement asks for, and its status in Rakshak AI today. Nothing here is rounded up.
| Requirement | Status | Detail |
|---|---|---|
| Human detection and tracking | Working | Detection on every feed; per-camera IDs; journeys across five synchronised cameras. |
| Vehicle detection and classification | Partly built | Cars, buses, trucks, motorcycles and bicycles are detected and labelled. Per-vehicle analytics such as counts, direction and dwell are next. |
| Night-time movement detection | Partly built | The unchanged pipeline is shown on night, thermal, fog and rain footage. Low-light enhancement (on an analysis copy only) and per-condition measurement are next. |
| Real-time alerts and event logging | Working | Incidents with severity, sound, operator actions, a history log, snapshots, reports and CSV export. |
| Suspicious activity detection | Partly built | Weapon detection works. Dwell, direction, group movement and the per-post baseline are in development. |
| Ingest from standard IP cameras | In development | The pipeline already takes any frame source (files, webcams, phones). RTSP/ONVIF with auto-reconnect and gap logging is the next item. |
| Virtual fence intrusion detection | In development | Zones and directional tripwires drawn on the live view, used as one input to the decision rather than a direct alarm, because on an open border crossing is normal. |
| Face detection | Designed | Detection on by default. Recognition is a separate module, off by default, and enabled only by an audited administrative action. |
| Automatic number plate recognition | Designed | Plate location and OCR for Indian formats, with accuracy on clean and degraded footage reported separately. |
| Integration with command and control | Partly built | The console already runs on REST and WebSocket APIs. A documented integration API for outside systems is designed. |
| No dedicated surveillance hardware | Working | Everything above runs on an ordinary laptop CPU with no GPU and no special cameras. |
The design assumes the hardest post, not the easiest: intermittent power, no reliable link and nobody trained in IT. Everything else is easier.
Existing cameras + one box
Runs fully offline
Syncs when the link returns
Cross-post view, journeys and recurring patterns, Watch Order management, access control and audit. Alerts go on to existing command-and-control systems through a documented API.
A mini-PC class machine per post. The prototype already runs 13 feeds on a 2016 laptop CPU. A real post needs 4–6 cameras per box.
All analysis happens at the post with a local store. Data is kept and forwarded when a link exists. It can run air-gapped with no cloud dependency.
IP cameras over RTSP/ONVIF, plus USB cameras, phones and recorded files. No camera replacement and no proprietary appliance.
A single-package install. Zones are drawn over the live view. Cameras report their own problems, such as a blocked lens, lost focus or signal loss.
to equip all 734 SSB Border Out Posts once with a Rakshak Edge Box (about ₹32,500 per post), on cameras the force already owns. No per-camera licence and no recurring cloud bill.
| Intel N100 mini-PC board (4-core, fanless) | ₹13,000 |
| 16 GB RAM + 512 GB NVMe SSD | ₹8,000 |
| 4-port PoE+ switch for the cameras | ₹3,500 |
| 12 V mini-UPS, IP65 enclosure, 4G modem, cables | ₹8,000 |
| Cameras · software licence · cloud | ₹0 |
| Edge Box per post, one time | ≈ ₹32,500 |
An indicative estimate at 2026 retail prices, excluding GST and installation; not a quotation. The box is a reference build from off-the-shelf parts that can be bought through standard government procurement.
Most people in frame on this border are crossing lawfully. The design treats that as a constraint on the architecture, not a policy footnote.
Rakshak AI detects, explains and records. An officer decides. Every action is attributable. Enabling recognition or changing retention needs a second person.
The baseline stores counts per time slot, never faces, images or names. Detection is on by default. Recognition is an exception: off unless enabled, audited and kept on a shorter retention schedule.
It reads footage the force already collects lawfully on its own cameras. Records use neutral language, for example "restricted area entry", never "confirmed infiltrator".
Someone who moves with the crowd, at market hour, on the usual path and carrying an ordinary bag, looks like the background. By design they will not be flagged. That is why Rakshak AI is one stream among several, alongside patrols and human sources. It is also why an officer with a tip-off can direct it with a Watch Order. The system shows its own blind spots through the shift digest, camera-health reports and the "insufficient data" state, so nobody mistakes it for an oracle.
A 30-day pilot at one Border Out Post, on existing cameras, scored by the unit, not by us. The criteria are fixed before the test runs.
| # | Criterion | Pass condition | If it fails |
|---|---|---|---|
| OAT-1 | Alert volume | ≤ 12 alerts per operator per 8-hour shift, sustained through a market day or festival surge | Reject |
| OAT-2 | Alert precision | ≥ 50% of alerts judged operationally meaningful by the duty commander | Reject |
| OAT-3 | Calibration | Stated confidence matches observed outcomes (expected calibration error ≤ 0.1) | Recalibrate, retest |
| OAT-4 | Missed events | Every event the unit independently knew of appears in the digest, even if it didn't interrupt the operator | Reject |
| OAT-5 | Evidence integrity | Every seal and the full log chain verify at month end | Reject |
| OAT-6 | Availability | ≥ 95% of camera-hours processed, with every gap logged | Investigate |
| OAT-7 | Adoption | Still switched on, unprompted, on day 30 | Reject |
A false-alarm rate is a property of ordinary traffic, so it can be checked on unlabelled footage from the post itself. No labelled dataset of border smuggling exists, so an approach whose central claim depends on one can't be verified.
How often real events are caught is measured on staged, logged events and reported as that, never mixed into field figures. Every number we publish comes with its sample size.
It runs live: 13 camera feeds, weapon alerts, journeys across cameras, and detection in night, thermal and fog footage. You can also connect your own phone camera.
We are building this for people who run, study and secure real surveillance systems. A candid view from you is worth more to us than praise.
How we use numbers. Every figure about Rakshak AI on this page is one of three things: measured on the prototype, labelled as a design target, or labelled as an estimate. External figures carry a source. The worked alert example is illustrative and says so.