Pre-trained · cloud SaaS · no local GPU
- Onboarding in hours, not weeks
- No new hardware required
- Alerts without development work
- Predictable monthly cost
- Support included in the plan
- Suits perimeter, access control, and HSEC
MTCVision AI · a company of MTC Group SpA
MTCVision AI puts AI detection on the IP cameras you already have. Unsafe conditions become alarms with the frame that proves them — while there is still time to act, not during the incident review.
No cost and no commitment. You keep the technical report either way.
Demonstration sequence. Synthetic data, not a live site.
The problem
Most sites already have the cameras. What they do not have is anyone able to watch every frame of every stream, every shift.
Footage gets reviewed after the incident, when the cost has already been paid. The camera did its job. The system around it did not.
An operator in front of a video wall misses most of what crosses it. Attention is the constraint, and adding cameras makes it worse.
Without event data, a recurring hazard stays invisible until it repeats. You cannot reduce what you never counted.
Why this is different
A generic product cannot make this claim, for a simple reason: it does not have your footage.
Base modules
Each module is a named condition that trips an alarm. Every alert carries the frame, the timestamp, the camera, and the criticality.
Entry, presence, line crossing, and person-down detection.
Helmet, vest, glasses, and any other item you define as required.
Detection, flow, presence, and coexistence with pedestrians.
Early signs of combustion, before a detector would register it.
Bags, boxes, pallets, and anything that is not standard for the area.
People counting, area occupancy, and corridor blockage.
Up to 26 modules are possible in full-scope projects, given the infrastructure, time, and team.
Two engines
They are sold together because they solve different halves of the same problem.
Pre-trained · cloud SaaS · no local GPU
Trained on your data · edge deployment
The platform
Alerts, evidence, zones, and reporting in one console — so an event has an owner, a timestamp, and a record that it was handled.
Product interface in development. The screens below are the design, rendered live in this page — not a running deployment.
Each camera reports its own state: model in use, frame rate, and whether a condition is currently tripped. Critical events surface first.
Modules are enabled per site and per camera. Each one reports its processing load and the number of streams assigned to it.
Operations defines the zone; detections are crossed against it. A zone is a shape on a floor plan, editable by the people who own the floor.
Events by zone and camera, real cases against false positives, response times, and what MTC recommends changing next month.
Reference footage
MTC has not published its own demonstration reel yet. Until it does, the clip below is third-party reference footage showing the class of detection the base modules perform.
Placeholder. Replace with MTC footage from a client site once permission is in hand.
Governed AI
You cannot read our source code. You can read every change we made to your model, and approve it.
The system flags events in production, including the ones it gets wrong.
MTC reviews false positives and false negatives against what actually happened.
Real cases from your site are labelled and added to the training set.
A validated version ships — versioned, documented, and authorized before it runs.
Nothing is retrained silently. Every model version is a record you can audit, which is what makes this an operational service rather than software you were sold.
Security and IT/OT
Connecting analytics to plant cameras means touching the operational network. These are the controls that make that defensible.
Physical and logical isolation between IT and OT on the Purdue model, with dedicated VLANs for cameras.
AES-256 end to end. RTSP streams are encrypted in transit, never carried in the clear.
VPN with MFA and hardware token requirement. No standing access, no shared credentials.
System actions, access, and configuration changes are recorded and cannot be edited after the fact.
Incident clips stored segregated, with SHA-256 integrity verification and RAID redundancy.
Admin, operator, and auditor roles. Retention windows are a policy you set, not a default we chose.
Worker privacy
Cameras that watch people are regulated, and your works council will ask about this before your security team does. We would rather answer it on this page than in the third meeting.
Detection is configured around zones and conditions, not individuals. The system reports that a condition occurred, at a place, at a time, with the frame that proves it. It is not built to follow a named person through a shift, and we will not configure it to.
What is stored, for how long, and who is allowed to open it are settings you own. We put them in writing before the first camera is connected.
Chilean rules on workplace video surveillance should be confirmed with your own counsel. We build to the policy you set, and we will help you write it down.
How it works
Camera inventory, NVR, network, RTSP access, and the zones that actually matter.
Architecture, KPIs, alert rules, and the technical plan you sign off on.
Server, models, zones, integration, and acceptance testing.
Support, tuning, event review, model releases, and the performance report.
What each side brings
Projects like this fail on access and ownership, not on models. Here is exactly what we need and exactly what we do.
Before you ask
Usually not. If your cameras are ONVIF, at least 2MP at 15 FPS, and we can reach the RTSP stream, they work as they are. The assessment tells you which of your existing cameras qualify and which do not.
Only if you choose it to. Edge deployment keeps processing and storage on your own network. Cloud and hybrid are options, not requirements, and the decision is recorded in the design phase.
Through an encoder, generally yes. Analog coverage is confirmed camera by camera during the assessment rather than promised in advance.
That is the reason models are trained on your footage and reviewed monthly. Shadows, glare, dust, and seasonal light are the conditions that break generic models, and they are what the review loop exists to absorb.
Base modules can be running within hours of getting stream access. Custom models follow the training cycle, which depends on how much usable footage of the real environment exists.
It depends on camera count, modules, and whether you deploy at the edge or in the cloud. We do not publish a price because we have not seen your site. The assessment produces the number, and the assessment is free.
Start here
One to two weeks, no cost, no commitment. You get a camera inventory, a network and RTSP readiness check, a zone and alert matrix, and a technical architecture — whether or not you go ahead with us.