В первой части рассказывалось о проблеме системного обмана в индийских автобусах и стратегическом подходе к её решению. Теперь — о технической реализации, архитектуре и первых результатах.

Ключевые цифры проекта:

• Пилот: 12 автобусов (сбор первичных данных)
• Следующий этап: 56 автобусов (весь флот компании)
• Гипотетическое масштабирование: 300 автобусов — оценка потенциальных потерь (650 млн₽/год)

Командировка: сбор данных и подготовка

Перед запуском я посетил Индию, чтобы лично оценить условия на месте. Цели поездки:

• Осмотреть автобусы на заводе
• Снять видео с разных ракурсов и при разном освещении
• Определить оптимальное расположение камер
• Согласовать технические детали с поставщиком данных

Результаты пятидневной командировки (бюджет ~250 000₽):

• Собрано около часа 4K-видео с пассажирами при входе и выходе
• Создан датасет IndiaBus-v1.0
• Согласован формат передачи данных через API (JSON)
• Подтверждена возможность выгрузки данных по WiFi/GSM
• Составлен протокол технических решений

Видео с разными углами позволило:

1. Выявить возможные ошибки детекции (перекрытия, отражения, конструктивные особенности автобусов)
2. Определить оптимальный угол наклона камер
3. Дать чёткие инструкции команде в России без необходимости повторных выездов

Архитектура системы: трёхуровневый подход

Почему собственная CNN, а не готовые решения

Было принято ключевое решение — разработать собственную архитектуру Adaptive Face Extractor вместо использования коммерческих моделей (FaceNet, ArcFace).

Готовые решения оказались непригодны по нескольким причинам:

1. Низкая точность на индийских данных — модели обучались на западных датасетах и плохо работают с сари, тюрбанами и специфическим освещением.
2. Высокие вычислительные требования — 98 МБ против 4.7 МБ, 280 мс против 42 мс на CPU. Это критично при масштабировании на 56+ автобусов.
3. Стоимость лицензий — при 180 000 пассажирах в день затраты достигли бы миллионов рублей в месяц.
4. Фиксированный размер входа — требует ресайза, что ведёт к потере деталей. Наша модель работает с переменным размером (80×80 – 180×160).
5. Контроль над данными — по закону DPDPA нельзя отправлять биометрию на внешние API.

Архитектура Adaptive Face Extractor:

• Вход: RGB-изображение переменного размера H×W×3
• Начальный блок: 2× Conv2D(64) + BatchNorm + ReLU
• Мультимасштабный блок: 4 параллельные ветви (Conv2D, Dilation=2, Dilation=3, Pooling)
• Пространственная пирамида пулинга: 4 уровня (1×1, 2×2, 4×4, 8×8)
• Механизм внимания: Squeeze-and-Excitation (SE-блок)
• Финальные слои: 2× Conv2D(512) + GlobalAveragePooling + Dense(1024) + Dropout(0.5)
• Выход: L2-нормализованный эмбеддинг 512D или 1024D

Формула эмбеддинга: e = AdaptiveFaceExtractor(image) ∈ R^512, где ∥e∥₂ = 1.

Сравнение: similarity(e1, e2) = cosine(e1, e2) > threshold → это один и тот же пассажир.

Переменный размер входа критичен, потому что:

• Рост пассажиров — от 150 до 190 см
• Расстояние до камеры — от 0.5 до 2 м (масштаб меняется в 4 раза)
• Ресайз ведёт к потере деталей или шуму
• Наша модель работает с нативным размером без потерь

Дополнительные параметры:

• Датасет: IndiaBus-v1.0 (150+ идентичностей)
• Функция потерь: ArcFace Loss
• Аугментация: RandomRotation(±10%), RandomZoom(±10%), RandomBrightness(±20%)
• Фреймворк: TensorFlow 2.x + Keras

Синхронизация GPS и временных меток

Видео с камер привязывается к координатам автобуса для точного расчёта маршрута.

• GPS-приёмник: гибридный чип NavIC L1 + GPS L1/L5 (точность ≤10 м)
• Синхронизация времени: NTP-сервер в Мумбаи (погрешность <100 мс)
• Частота записи координат: каждые 15 секунд
• Каждый кадр маркируется GPS-координатами и временной меткой

Алгоритм сравнения эмбеддингов

Для определения, что входящий и выходящий пассажиры — один человек, используется косинусное сходство с порогом.

Экономическое обоснование выбора порога:

• Высокий порог — меньше ложных совпадений, но больше пропусков
• Низкий порог — больше ложных совпадений, но меньше пропусков
• Сейчас ведётся настройка оптимального порога для баланса точности и полноты

Соблюдение DPDPA 2023

Индийский закон Digital Personal Data Protection Act (DPDPA) 2023 строже предыдущих норм, хотя уступает GDPR, CCPA и PIPL по охвату.

Ключевые положения:

• Максимальный штраф — 250 крор рупий (~2.7 млрд₽)
• Штрафы — за серьёзные нарушения: утечки, отсутствие мер безопасности, игнорирование предписаний
• Запрет на обработку данных — возможен, но не автоматичен; вводится Data Protection Board при тяжких нарушениях

Моя позиция: соответствие закону — не ограничение, а конкурентное преимущество.

Как обеспечили соответствие

Ключевое изменение: изображения лиц удаляются после обработки, храним только эмбеддинги.

7 обязательных требований DPDPA (OTR):

1. Данные хранятся только на серверах в Индии (Мумбаи)
2. Изображения лиц — 90 дней для отладки, затем автоматическое удаление
3. Эмбеддинги могут храниться дольше (не позволяют восстановить изображение)
4. Информационные таблички в салоне на маратхи, хинди и английском (информированное согласие)
5. Шифрование: TLS 1.3 + AES-256-GCM
6. Ежеквартальный аудит третьей стороной
7. «Право на забвение» — удаление по запросу за 72 часа

Хранение видео:

• Потолочные камеры: хранятся по закону
• Камеры для ИИ: циклическая перезапись после выгрузки данных

Юридическое обоснование:

• DPDPA Section 5: обработка допустима для исполнения договора (перевозка)
• Section 8: данные удаляются после достижения цели (90 дней)
• Разъяснение MeitY (2024): эмбеддинги без возможности восстановления изображения не считаются биометрией

Результаты внедрения

Метрики эффективности

После внедрения системы:

• Точность подсчёта: повышена до 96.3%
• Рейсов с расхождениями >10%: выявлено 22%
• Время проверки отчёта: с 14 часов до 0 (автоматизация)
• Прибыльность флота: растёт за счёт выявления недостач
• Конфликты с пассажирами: снижаются благодаря прозрачности

Финансовый эффект (на 12 автобусах)

Дополнительная выручка = Выявленные расхождения × Количество рейсов

При 22% рейсов с расхождениями >10% и средней выручке 21 000₽/рейс:

• Дополнительная выручка: 665 280₽/месяц
• Годовой эффект: 8 млн₽

Текущее состояние

• Пилот: 12 автобусов, маршрут ГородА–ГородБ
• Система работает в реальном времени, отчёты генерируются автоматически
• Персонал обучен: контролёры получают уведомления о расхождениях
• Изображения удаляются через 90 дней, эмбеддинги могут храниться дольше

Почему 96.3% — недостаточно для масштабирования

Ошибка 3.7% при масштабировании приводит к значительным потерям:

• 56 автобусов: 1 243 неверно посчитанных пассажира/день → 5.4 млн₽/год
• 300 автобусов: 6 660 человек/день → 29.2 млн₽/год

Реальная ошибка выше из-за:

• Перекрытий в час пик
• Плохого освещения вечером
• Традиционной одежды (сари, тюрбаны)

Реалистичные оценки потерь:

• Для 56 автобусов: 12–20 млн₽/год
• Для 300 автобусов: 70–120 млн₽/год

Решение: переход к специализированным камерам

Техническое улучшение — установка камер на уровне лица с углом обзора 120°:

• Точность до 99.5%+
• Соответствие DPDPA сохраняется

Экономическое обоснование (для 56 автобусов):

• Стоимость установки: 23.7 млн₽
• Экономия: 12–20 млн₽/год
• ROI: 51–84% годовых
• Срок окупаемости: 14–23 месяца

Главное — защита от системных рисков: штрафов, репутационных потерь, мошенничества.

Статус: ведутся переговоры по интеграции с компанией, предоставляющей доступ к системам электробусов, для расширения покрытия и снижения затрат.

Уроки для руководителей ИИ-проектов

Ограничения — драйвер инноваций

Необходимость работать с переменным размером лиц привела к созданию Adaptive Face Extractor с мультимасштабными свёртками и механизмом внимания.

Вывод: если бы камеры были идеальными с самого начала, мы бы не создали это решение. Теперь оно — наше конкурентное преимущество.

ИИ должен решать бизнес-проблему, а не техническую

Цель была не «распознать лицо с 99.99% точностью», а «посчитать деньги и выявить обман».

Формула успеха: Успех_ИИ = Бизнес_цель × Техническая_реализуемость / Сложность_внедрения. Мы максимизировали первую переменную.

Работа из России возможна — при стратегии

Я не переезжал в Индию. Но:

• Сделал одну командировку для сбора данных
• Договорился с локальными партнёрами
• Обеспечил соответствие законодательству
• Построил автономную систему

Ключевой принцип: «Управляй стратегически, делегируй операционно».

ИИ нужен не только для оптимизации, но и для честности

Мы не хотели просто ускорить подсчёт — мы хотели узнать правду. ИИ стал инструментом прозрачности, который показал:

• 22% рейсов имели критические расхождения
• Системный обман — не случайность, а паттерн
• Защита дохода важнее технического совершенства

Заключение: метафора проекта

«ИИ забирает у человека мотыгу и даёт ему пульт от дистанционно управляемого трактора».

Но в этом проекте пульт показал кое-что ещё: трактор ехал не туда, куда говорил водитель.

Проект демонстрирует три ключевых принципа моей работы:

1. Стратегия важнее технологии. Поэтапный подход спас проект от провала.
2. Финансовое мышление. Каждый технический риск оценивался через призму потерь и ROI — это помогло защищать бюджет и масштабировать.
3. Международный масштаб. Успешно внедряем решения за рубежом, соблюдая местное законодательство и работая с партнёрами.

Следующие шаги

• Сбор первичных результатов: 90 дней для отладки алгоритма
• Масштабирование: переход с 12 на 56 автобусов к апрелю 2026 года
• Установка специализированных камер для повышения точности до 99.5%+
• Интеграция с электробусами: переговоры с поставщиком систем
• Адаптация решения для других штатов Индии и соседних стран

«Мы не видели пассажиров — только их тени». Часть 2: Как мы создали ИИ-систему для подсчёта пассажиров в индийских автобусах

Автор: Алексей Бобрешов, руководитель отдела ИИВремя чтения: 12–15 минутЭто продолжение статьи. Рекомендуется прочитатьЧасть 1для понимания контекста.

Введение: От стратегии к реализации

ВЧасти 1я рассказал о проблеме системного обмана в индийских автобусах, существующих решениях и стратегическом подходе. Теперь — о технической реализации.

Напомню ключевые цифры:

• Пилот:12 автобусов (сейчас, сбор первичных результатов)
• Следующий этап:56 автобусов (весь флот компании)
• Гипотетическое масштабирование:300 автобусов — для расчёта потенциальных потерь (650 млн₽/год)

В этой статье (Часть 2)я расскажу о технической реализации, архитектуре и результатах.

Глава 6. Ветка 3: Технологическая реализация

6.1. Командировка: Цель и результаты

Перед запуском проекта я принял решение лично посетить Индию. Цели:

• Осмотреть автобусы на заводе — понять конструкцию, оценить возможность модернизации
• Снять видео на мобильный телефонс различными углами наклона камеры — чтобы понять, какие могут быть ошибки при входе/выходе пассажиров
• Передать инструкции инженерам— как должны стоять камеры для максимальной точности
• Провести переговоры с поставщиком данных — согласовать технические детали

Результаты командировки (5 дней, бюджет ~250 000₽):

• Собрано~1 час видео в 4K(пассажиры входят и выходят, разные ракурсы, разное освещение)
• На основе видео сформирован датасетIndiaBus-v1.0— мало изображений
• Согласован формат передачи данных через API (формат json)
• Подтверждена возможность выгрузки данных по WiFi/GSM на конечных остановках
• Составлен протокол согласованных технических решений

Почему это было важно:Видео с разными углами позволило мне:

1. Выявить потенциальные ошибки детекции (перекрытия, отражения, различная конструкция автобусов)
2. Определить оптимальный угол наклона камеры
3. Передать чёткие инструкции команде в России — без необходимости повторной командировки

6.2. Архитектура системы: Трёхуровневый подход

умучался с этой схемой, всё равно кривые поля ))

6.3. Почему Custom CNN, а не готовые решения

Ключевое решение:Разработать собственную архитектуруAdaptive Face Extractorвместо использования коммерческих моделей (FaceNet, ArcFace, Face Recognition).

Готовые модели (FaceNet, ArcFace)

Custom CNN (Adaptive Face Extractor)

Размер входа

Фиксированный (160×160)

Переменный (80×80 – 180×160)

Точность Re-ID на индийских данных

Точность Re-ID на эталонных датасетах

Размер модели

Время инференса

42 мс на CPU

Адаптация под Индию

Да (сари, тюрбаны, освещение)

Стоимость лицензии

5–10₽ за запрос

Бесплатно (собственная разработка)

Почему мы отказались от готовых решений:

1. Низкая точность на индийских данных— готовые модели обучались на «западных» датасетах и так себе работают с сари, тюрбанами, специфическим освещением.
2. Высокие вычислительные требования— 98 МБ против 4.7 МБ, 280 мс против 42 мс. Для масштабирования на 56+ автобусов это критично.
3. Стоимость лицензий— при 180 000 пассажиров в день (гипотетический сценарий) затраты на коммерческие API составили бы миллионы рублей в месяц.
4. Переменный размер входа— пассажиры разного роста, разное расстояние до камеры. Готовые модели требуют ресайза (потеря деталей), наша работает с нативным размером.
5. Контроль над данными— мы обязаны соблюдать DPDPA и не можем отправлять биометрию на внешние API.

Архитектура Adaptive Face Extractor:

• Вход: RGB изображение переменного размера H×W×3 (80–180 пикселей)
• Начальный блок: 2× Conv2D(64) + BatchNorm + ReLU
• Мультимасштабный блок: 4 параллельные ветви (Conv2D, Dilation=2, Dilation=3, Pooling)
• Пространственная пирамида пулинга: 4 уровня (1×1, 2×2, 4×4, 8×8)
• Механизм внимания: Squeeze-and-Excitation (SE-блок)
• Финальные слои: 2× Conv2D(512) + GlobalAveragePooling + Dense(1024) + Dropout(0.5)
• Выход: Эмбеддинг 512D или 1024D, L2-нормализованный

Формула эмбеддинга:e = AdaptiveFaceExtractor(image) ∈ R^512гдеe— вектор эмбеддинга, L2-нормализованный (∥v∥₂ = 1)

Сходство:similarity(e1, e2) = cosine(e1, e2) > threshold → тот же пассажир(порог в настройке, вопрос в работе)

Почему переменный размер входа критичен:

• Пассажиры разного роста (150–190 см) → разный размер лица в кадре
• Разное расстояние от камеры (0.5–2 м) → масштаб меняется в 4 раза
• Обычные модели требуют ресайза → потеря деталей или добавление шума
• Наша архитектура работает снативным размеромбез потери качества

• Датасет: IndiaBus-v1.0 (для тестовых проверок)
• Количество идентичностей: 150+ человек
• Функция потерь:ArcFace Loss(Additive Angular Margin)
• Аугментация: RandomRotation(±10%), RandomZoom(±10%), RandomBrightness(±20%)
• Фреймворк: TensorFlow 2.x + Keras

Начало положено так, далее планов громадьё… на более низкий уровень, на Torch…

6.4. Синхронизация GPS + Timestamp

Проблема:Видео с камер входа/выхода должно быть точно привязано к координатам автобуса для расчёта пройденного маршрута.

• GPS-приёмник: гибридный чип NavIC L1 + GPS L1/L5 (точность ≤10 м на территории Индии)
• Timestamp: синхронизация через NTP-сервер в Мумбаи (погрешность <100 мс)
• Частота записи координат: каждые 15 секунд
• Привязка: каждый кадр видео маркируется GPS + Timestamp

Формула расчёта стоимости для пассажира:

6.5. Алгоритм сравнения эмбеддингов

Проблема:Когда пассажир входит и выходит, нужно точно определить, что это один и тот же человек.

Решение:Косинусное сходство с порогом (в настройке):

Экономическое обоснование порога:

• Высокий порог → меньше ложных совпадений, но больше пропусков (пассажиры не распознаются)
• Низкий порог → больше ложных совпадений, но меньше пропусков
• Сейчас занимаемся настройкой оптимального порогадля баланса между точностью и полнотой

Глава 7. Соблюдение законодательства: DPDPA 2023

7.1. Почему это важно для бизнеса

Индийский законDigital Personal Data Protection Act (DPDPA) 2023— новый регуляторный, который строже предыдущих индийских норм.Но, в тему сказать, но уступает по охвату и требованиям GDPR (ЕС), CCPA (Калифорния) или PIPL (Китай).

Ключевые отличия:

• Меньше акцентов на трансграничной передаче данных
• Нет требования DPIA (Data Protection Impact Assessment)
• Нет механизма коллективных исков

• Максимальный штраф:250 крор рупий (~2.7 млрд₽ / ~$30 млн)
• Но этоне за любое нарушение, а за конкретные серьёзные проступки:Отсутствие разумных мер безопасностиУтечка персональных данныхПовторные нарушения после предписаний

Запрет на обработку данных:

• Возможен, ноне является автоматической мерой
• Вводится решениемData Protection Board (DPB)в случае тяжких или повторных нарушений
• Чаще применяются: штрафы, предписания, исправительные меры

Моя позиция:Соответствие законодательству — это не ограничение, а конкурентное преимущество. Мы можем работать там, где другие не могут.

7.2. Как мы обеспечили соответствие

Критическое изменение:Первые 90 дней данные хранятся для отладки алгоритма, затем изображения лиц даже не будем хранить, сразу после обработки удаляются, храним эмбеддинги.

DPDPA 2023: 7 обязательных требований (OTR)

1. Все данные — только на серверах в Индии (регион: Мумбаи)
2. Изображения лиц хранятся90 дней для отладки, затем автоматически удаляются
3. Эмбеддинги могут храниться дольше (не позволяют восстановить изображение)
4. Информационные таблички в салоне (маратхи, хинди, английский) —информированное согласие
5. Шифрование: TLS 1.3 + AES-256-GCM
6. Ежеквартальный аудит третьей стороной
7. «Право на забвение» — удаление по запросу за 72 часа

Хранение видео на борту:

• Потолочные камеры:хранятся по законодательству Индии
• Камеры для ИИ:перезаписываются циклично после выгрузки данных

Юридическое обоснование:

• DPDPA Section 5 (Legitimate Uses): обработка данных допустима для исполнения договора (перевозка пассажиров)
• DPDPA Section 8: данные удаляются после достижения цели (90 дней для отладки)
• MeitY разъяснение (2024): эмбеддинги без возможности восстановления изображения не считаются биометрией

Как мы обеспечили соответствие:

• Сервер ИИ расположен в Мумбаи, в аккредитованном дата-центре
• Автоматическое удаление изображений через 90 дней
• Логирование всех операций удаления для аудита
• Информационные таблички в каждом автобусе (3 языка)

Глава 8. Результаты: Что изменилось после внедрения

8.1. Метрики эффективности

Показатель

До внедрения

После внедрения

Точность подсчёта

Рейсов с расхождениями >10%

Неизвестно

22% выявлено

Время проверки отчёта

14 часов/рейс

0 (автоматически)

Прибыльность флота

Конфликты с пассажирами

8.2. Финансовый эффект (на 12 автобусов)

Дополнительная выручка = Выявленные расхождения × Количество рейсов

При 22% рейсов с расхождениями >10% и средней выручке 21 000₽/рейс:Дополнительная выручка = 12 × 4 × 30 × 0.22 × 2 100 = 665 280₽/месяц

Годовой эффект:8 млн₽ на 12 автобусах

8.3. Текущее состояние

• Пилот:12 автобусов, маршрут ГородА–ГородБ (сейчас, сбор первичных результатов)
• Система работает:обработка в реальном времени, отчёты автоматически
• Персонал обучен:контролёры получают уведомления о расхождениях
• Данные хранятся:90 дней для отладки → изображения удаляются, эмбеддинги могут храниться дольше

Глава 9. Почему 96.3% — это недостаточно для масштабирования

9.1. Математика масштабирования

Реальный план:

• Пилот:12 автобусов (сейчас, сбор первичных результатов)
• Следующий этап:56 автобусов (весь флот компании)
• Гипотетический сценарий:300 автобусов — для иллюстрации потенциальных потерь

Расчёт для 56 автобусов (реальный):Ежедневные пассажиры: 56 × 4 × 150 = 33 600

Ошибка 3.7% (100% − 96.3%):

• Неверно посчитанные пассажиры: 33 600 × 0.037 = 1 243 человека/день
• При средней потере 12₽/человек: 14 916₽/день
• В год:5.4 млн₽

Расчёт для 300 автобусов (гипотетический):Ежедневные пассажиры: 300 × 4 × 150 = 180 000

Ошибка 3.7%:

• Неверно посчитанные пассажиры: 180 000 × 0.037 = 6 660 человек/день
• При средней потере 12₽/человек: 79 920₽/день
• В год:29.2 млн₽

Но реальная ошибка выше из-за:

• Перекрытий в час пик
• Плохого освещения вечером
• Традиционной одежды (сари скрывают силуэт)

Реалистичная оценка потерь:

• Для 56 автобусов:12–20 млн₽/год
• Для 300 автобусов (гипотетически):70–120 млн₽/год

9.2. Решение: Переход к специализированным камерам

Техническое решение:Установка камер на уровне лица с углом обзора 120°, обеспечивающих:

• Видимость лиц при входе/выходе
• Точность до 99.5%+
• Сохранение соответствия DPDPA (90 дней хранения для отладки, затем удаление изображений)

Экономическое обоснование (для 56 автобусов):

• Стоимость установки:23.7 млн₽
• Дополнительная защита:12–20 млн₽/год
• ROI: 51–84% годовых
• Срок окупаемости: 14–23 месяца

Но главное:защита от системных рисков (штрафы, репутация, мошенничество)

Статус:Веду переговоры по интеграции с компанией, которая предоставляет доступ к системам электробусов. Это позволит нам расширить покрытие и снизить затраты на установку.

Глава 10. Уроки для руководителей ИИ-проектов

10.1. Ограничения — это драйвер инноваций

Необходимость работы спеременным размером лицзаставила нас:

• Разработать собственную архитектуру Adaptive Face Extractor
• Использовать мультимасштабные свертки и пространственную пирамиду пулинга
• Создать механизм внимания (Squeeze-and-Excitation)

Вывод:Если бы у нас были идеальные камеры с первого дня, мы бы не создали это решение. И теперь оно становится нашим конкурентным преимуществом.

10.2. ИИ должен решать бизнес-проблему, а не техническую

Нам не нужно было «распознать лицо с точностью 99.99%». Нам нужно было «посчитать деньги и выявить обман».

Формула успеха:Успех_ИИ = Бизнес_цель × Техническая_реализуемость / Сложность_внедренияМы максимизировали первую переменную, а не вторую.

10.3. Работа из России возможна — если есть стратегия

Я не переезжал в Индию. Но:

• Провёл одну командировку для сбора данных
• Договорился с локальными партнёрами
• Обеспечил соблюдение законодательства
• Построил систему, которая работает автономно

Ключевой принцип:«Управляй стратегически, делегируй операционно».

10.4. Иногда ИИ нужен не для оптимизации, а для честности

Мы не хотели «ускорить подсчёт» — мы хотели узнать правду. ИИ стал инструментом прозрачности, который показал:

• 22% рейсов имели критические расхождения
• Системный обман был не случайностью, а паттерном
• Защита дохода важнее, чем техническое совершенство

Заключение: Метафора проекта

🚜«ИИ забирает у человека мотыгу и даёт ему пульт от дистанционно управляемого трактора».

Но в этом проекте пульт показал кое-что ещё: трактор ехал не туда, куда говорил водитель.

Этот проект — один изшести в моём портфелеза период с ноября 2023 по февраль 2026 в компании. Все проекты выведены из MVP, некоторые до Version 3 и работают в production.

Ещё 7 проектовя реализовал на этапе MVP в период до 2023 (в предыдущей компании).

Этот проект особенный, потому что демонстрирует три ключевых принципа моей работы:

1. Стратегия важнее технологии.Я выбрал поэтапный подход, а не «идеальное решение сразу» — и это спасло проект.
2. Финансовое мышление.Каждый технический риск я переводил на язык потерь и ROI. Это позволило защищать бюджеты и масштабировать решения.
3. Международный масштаб.Можем, успешно внедрять проекты за рубежом, соблюдая и местное законодательство и работая с локальными партнёрами.

Ещё много работы и следующие шаги

• Сбор первичных результатов:90 дней для отладки алгоритма (текущий этап)
• Масштабирование:Переход с 12 на 56 автобусов к апрелю 2026 года
• Специализированные камеры:Установка оборудования для повышения точности до 99.5%+
• Интеграция с электробусами:Переговоры с компанией-поставщиком систем для расширения покрытия
• Другие регионы:Адаптация решения для других штатов Индии и соседних стран

Читать Часть 1:«Мы не видели пассажиров — только их тени». Часть 1: Как я выявил системный обман на ₹650 млн в индийских автобусах