Nine things the MTA wants from an AI track intrusion system

A procurement document, read slowly

Most writing about AI on railways is written by vendors. This is written by a buyer.

In April 2026 the MTA published a solicitation for Design-Build Services for Track Intrusion Detection Systems at two stations. It asks for a prototype, not a rollout: one underground station and one elevated platform, a contract term of 730 calendar days, an estimated value of $10 million to $50 million, and funding that is 100 percent MTA. The purpose, in the document's own words, is "to demonstrate the feasibility, performance, and reliability of an artificial intelligence-supported approach to right-of-way intrusion detection and awareness."

The timing is a coincidence we will use. APTA's TRANSform Conference and EXPO is under way in Chicago from October 4 to 7, which is where a document like this gets argued about out loud.

For scale, Route Fifty and NY Weekly reported in June that there were 1,297 unauthorized entries onto the tracks in 2025, up 22 percent from 1,062 in 2019. There were 491 in the first four months of 2026, slightly below the 505 of the same stretch a year earlier. About 6 percent of subway delays in 2025 were attributed to a person or debris on the tracks.

What it has to see

The solicitation lists nine things the system must be capable of. The first two are about seeing.

The first is detecting when a person, object or animal enters, or is about to enter, the right-of-way, and recognizing the conditions of the entry: accidental falls, intentional track entry, dropped objects, unusual crowd movements near the platform edge.

The second is detecting pre-intrusion behaviors under low and high passenger density, such as a person leaning into the right-of-way, erratic movement, overcrowding or sudden displacement on the platform.

"About to" is the phrase that carries the weight. A person on the track is a detection problem. A lean at the platform edge, a second earlier, in a crowd, is a different and noisier problem, and the MTA has written it into the requirements anyway.

What it has to do with what it sees

Items three to six are about the work after the detection. The system has to respond according to how it classifies the event: send alerts with context to specified user groups, take verifications and acknowledgements, and escalate, downgrade or clear alerts. It has to produce stills and video of intrusion and pre-intrusion events, and send alerts to train operators, station staff and the control center. It has to be monitored and controlled remotely from workstations. And it has to assess its own performance and improve from the inputs users give on events it has already detected.

Read as a list, it describes a workflow more than a detector. The camera is the first step.

Where it has to keep working

The last three items are the ones we would read twice.

Item seven asks the system to maintain "detection, alert, and recording functionalities at the station level" if the equipment at the station is disconnected from the headend. The decision is made at the station. The headend is where it is reported. That is the line we would underline in the whole document, because it is an architecture requirement dressed as a reliability one.

Item eight asks for reliable operation in heat, humidity, dust, wind, vibration, water, electromagnetic interference and variable lighting. Item nine asks it to interface with the MTA's real-time train positioning information.

There is one more detail in the closing paragraphs. When the project ends, the design-builder removes the equipment from the right-of-way and hands over documentation "suitable for reuse by the MTA in future third-party solicitations for expansion." The MTA is buying a prototype, and it is also buying a specification it can compete for next time.

Where DHI's version of this starts and stops

DHI has a track-zone use case. A zone is drawn on a camera's view of the track, and a person inside it raises an event with a clip. The decision runs on a local node at the site and the footage stays there, which is the shape item seven describes.

It does not cover the first half of the list. The lean at the platform edge, crowd displacement and learning from operator feedback are outside what we claim. Our railway demo footage is test footage, not a live platform, and we have no deployment on a transit system to report. Everything here is mechanism.

As of Route Fifty's June report, the MTA was aiming to award a contract by the end of 2026. We have not checked where the procurement stands today.

If you were scoring this prototype, which of the nine would you test first: the lean at the platform edge, or the unplugged headend?

Sources

• MTA solicitation, Design-Build Services for Track Intrusion Detection Systems at Two Stations: mta.info/document/203521
• Route Fifty, "New York MTA seeks AI subway track intrusion tech," June 4, 2026
• NY Weekly, "MTA Seeks AI Track-Intrusion Detection for NYC Subway," June 12, 2026
• APTA TRANSform Conference and EXPO 2026: apta.com