Skip to content
TechnoGuru — Think Technology, Think TechnoGuru

18 / 19

Case file

02 · ELV Systems

Facial Recognition System.

Recognised at the door. Logged, with consent.

AI face-recognition for access, attendance and surveillance — face-based entry, watchlist and VIP/denied-entry alerts — integrated with CCTV and access control on a consent-aware, privacy-respecting deployment.

Facial recognition: off-the-shelf vs engineered
Facial recognition: off-the-shelf vs engineered
AspectOff-the-shelfEngineered approach
AccuracyOne threshold out of the boxEnrolment and accept/reject tuned to the door's real lighting, angle and throughput
SecurityFace aloneFace paired with card or PIN on higher-security doors; every match logged for audit
PrivacyVendor defaultsConsent-based enrolment, client-controlled templates, scoped watchlists and written retention rules

Educational comparison of design rigour — not a statement about any specific installer.

/ The discipline, in detail

How we approach facial recognition system.

Face recognition only earns its place when it is accurate, fast and accountable. We design enrolment and matching against the real lighting, angle and throughput at the door rather than ideal lab conditions, so a genuine person is recognised quickly and a stranger is not waved through. Faces can release a door, mark attendance or flag a watchlist hit, and every match — accept, reject, alert — is logged for audit so the system can be reviewed after the fact rather than trusted blindly.

We treat face data as sensitive from the first design conversation. Enrolment is on a consent basis with a clear notice, templates are kept on the system the client controls, and VIP, staff and denied-entry watchlists are scoped to who genuinely needs them. The recognition layer is integrated with the existing CCTV and access-control systems so a match can open a barrier, raise an alert at the security desk or simply tag a recording — coordinated, commissioned and documented, with the matching thresholds and retention rules written into the project file rather than left to a default.

On record

Every facial recognition system engagement is documented end-to-end — design, programming, commissioning, calibration — and handed over with the files our successors would need if we were never to return.

/ Sister services

The rest of elv.

A serious brief usually crosses two or three of these. Read across the discipline — we deliver them as one contract.

/ Plan it right

Facial Recognition System — getting the brief right.

Common mistakes to avoid

  • Deploying face-based access before the consent and enrolment policy is agreed — governance comes before the technology.
  • Mounting readers with backlight behind the subject or at the wrong height, so matching degrades and doors get propped open.
  • Leaving matching thresholds at factory defaults instead of tuning false-accept versus false-reject to the site's risk profile.
  • No fallback credential (card or PIN) planned for visitors, non-enrolled staff and failed reads.
  • Leaving template storage undefined instead of on-premise, under client control, with an audit log.

What to share before a quotation

  • The use case — access, attendance, watchlist alerting — and the doors or points in scope.
  • The population — staff count, visitor policy, and the consent and enrolment process.
  • Lighting conditions at each reading point.
  • Integration scope — access control, CCTV, HR or attendance systems.
  • Data-handling expectations — retention, audit trail, on-premise storage.

/ Frequently asked

Facial Recognition System — what buyers ask first.

Is facial recognition reliable enough to control a door?

It is when the matching threshold is set for the door it guards. We tune enrolment and the accept/reject threshold to the actual lighting, angle and throughput, and pair face with a card or PIN on higher-security doors so a poor read never becomes a free entry — every match is logged for review.

How is privacy handled with face data?

Face data is treated as sensitive from the first design conversation. Enrolment is on a consent basis with a clear notice, face templates are stored on the system the client controls, watchlists are scoped to who genuinely needs them, and retention rules are written into the project file rather than left to a default.

What happens for visitors who are not enrolled in the system?

They follow a defined visitor path — a fallback credential such as a card or PIN, an intercom call to the desk, or a supervised entry — because face access is for the enrolled population, not everyone who arrives. Designing that fallback is part of the scope, and it is one reason we ask about the visitor policy before quoting.

Can the system run without sending face data to the cloud?

Yes — we design for on-premise template storage under the client's control, with enrolment, matching and the audit log kept on site. Remote access, where wanted, is a monitored administrative function, not a requirement of the matching itself. The data-handling posture is agreed in writing as part of the deployment.

Can face recognition work alongside our existing card-based access control?

Yes — the usual pattern is face as one credential class within the same access platform, so a door can accept face, card or both depending on its security level. That keeps one audit trail and one administration point, which is why we ask which access system you run today.

· Begin

Begin a
facial recognition system
brief.

Tell us about the building, the timeline, and what success looks like a year after handover. We will reply within two working days with a written response, not a sales pitch.