7 российских AI-проектов для ML-задач — от кода до внедрения в работу | Марина Погодина, PROMAREN
Российские AI проекты уже не выглядят «догоняющими»: по состоянию на начало 2026 бизнес спокойно закрывает задачи машинного обучения open source-инструментами, не оглядываясь на импорт. Я вижу, как команды в РФ ставят модели рядом с 1С и Kubernetes и молча экономят часы — без хайпа, но с понятным эффектом по деньгам и времени.
Обновлено: 7 февраля 2026
Время чтения: 13-14 минут
- Почему российские разработчики так ценятся сейчас
- Что я называю российским AI-проектом
- Как аккуратно использовать open source AI
- Семь ML-проектов, которые уже работают в проде
- На чем чаще всего ломаются AI-проекты в РФ
В начале 2026 я поймала себя на мысли: когда заказчик говорит «нам нужен искусственный интеллект», он почти никогда не имеет в виду «купим ещё одну подписку на ChatGPT». Ему нужны российские AI проекты, которые живут в его контуре, дружат с 152-ФЗ и не падают при первом же обновлении VPN. И желательно — open source, чтобы юристы спали спокойно.
Пока я пью остывший кофе и смотрю на n8n, который снова не сработал с первой попытки, отечественные AI-разработчики выкатывают всё новые модели и библиотеки. В PROMAREN мы это ощущаем буквально руками: от генерации документации до автопроверки кода. Стоп, вернусь назад — без контекста легко потеряться в этом зоопарке.
Почему российские разработчики так ценятся сейчас
Три из пяти успешных внедрений ИИ в РФ в 2025-2026 делают не «кустарные стартапы», а команды, которые давно живут в нашей специфике — санкции, локальные облака, русскоязычные данные. Это означает, что российские AI проекты изначально проектируются под ограничения, а не адаптируются в панике в последний момент.
Российские разработчики ценятся за прагматизм: меньше слайдов, больше кода, который переживает ночной релиз. По данным исследования Минцифры и Сколково за 2024 год, крупные ИТ-игроки в РФ выпустили 176 научных публикаций по искусственному интеллекту, лидируют Сбер, Smart Engines и Яндекс — это не только статьи, но и живые библиотеки, которые команда может поставить сегодня и погонять на своих данных. В open source ушло уже больше сотни решений для ML и 45 моделей на Hugging Face, и это только то, что легло в отчеты.
Какую ценность приносят российские AI компании бизнесу
Когда я слушаю истории «мы внедрили ИИ и сэкономили миллиард», у меня автоматически включается внутренний аудитор. Но по опыту PROMAREN и данным отраслевых обзоров оказывается, что в промышленности это часто не маркетинг. Те же решения по предиктивному обслуживанию, которые ставят крупные отечественные компании, реально снижают аварийность оборудования и добавляют сотни миллиардов рублей прибыли в год — это звучит пафосно, но за цифрами стоят вполне приземленные ML-модели.
В сервисном бизнесе картина похожа. Сбер показывал кейсы, где аналитика на основе ML поднимала точность прогноза трафика в ресторанах до 89 %, а расходы на закупки проседали примерно на 17 %. В PROMAREN мы видим сходную динамику в меньшем масштабе: как только бизнесу дают не «магический ИИ», а конкретный предиктивный отчет в Telegram, уровень доверия к слову «алгоритм» перестает вызывать сарказм. И тут критично, что стек собирается вокруг отечественных open source-проектов — они нормально живут в Яндекс Облаке и on-prem-кластерах.
Что меняется в 2025-2026 для ML и open source
В начале 2026 стало видно то, что ещё пару лет назад казалось смелой гипотезой: компании массово уходят в сторону открытых решений. По оценке одного из обзоров рынка AI в РФ, до 90 % корпоративных команд уже либо используют, либо планируют использовать open source ML-проекты — не из любви к свободе, а потому что закрытые платформы не успевают подстраиваться под регуляторику и бюджеты. Национальные стандарты качества ИИ, которые готовит Росстандарт совместно с профильными ассоциациями, только подталкивают этот переход.
Это критично, потому что именно архитектура и прозрачность кода решают, доживет ли пилот ИИ до продакшена. Сейчас 80-90 % пилотов так и остаются красивыми прототипами на демо-стендах — и одна из причин в том, что бизнес боится зависеть от «черного ящика» где-то за границей. Когда стэк собран вокруг российских open source-проектов, у команды появляется возможность честно обсуждать риски с безопасниками, а не притворяться, что «это просто умный бот». И это аккурат мостик к следующему вопросу — что вообще считать российским AI-проектом, а что — просто модной оберткой.
Что я называю российским AI-проектом
Российский AI проект — это не только репозиторий на GitHub с русским README, а связка: команда в РФ, данные и инфраструктура в нашем контуре и модели, адаптированные под местные задачи. Такой проект живет на стыке исследований в AI и довольно приземленной разработки ПО под ограничения 152-ФЗ и локальных дата-центров.
Крупные игроки вроде Яндекса, VK и Т-Технологий держат сотни таких репозиториев — от библиотек для обработки текста до систем анализа кода и мониторинга. По открытым данным, только Яндекс ведет несколько сотен open source-проектов, а Т-Технологии активно выкладывают свои модели на Hugging Face: текстовые, речевые, мультимодальные. Для бизнеса это означает одно: уже не нужно «изобретать GPT», достаточно грамотно собрать стэк из готовых кирпичей.
Чем российский AI-проект отличается от «еще одной модели»
Тут я раньше думала, что достаточно «есть модель — значит, это проект». После 8 внедрений изменила мнение: без экосистемы вокруг модель так и останется игрушкой для технарей. Настоящий российский AI-проект про машинное обучение включает несколько слоев — от датасетов и пайплайнов подготовки данных до интеграции в CI/CD и мониторинга качества в продакшене.
Если упрощать, живой проект выглядит так: данные собираются и очищаются в локальных базах, модель обучается или дообучается (часто на основе Hugging Face), затем этот артефакт попадает в конвейер сборки и выката через Docker и Kubernetes. Сверху навешивается логгирование и мониторинг через Prometheus, Grafana или аналогичный стек. И только на самом верху — интерфейсы: боты, веб-приложения, интеграции с 1С. Без нижних слоёв все разговоры про «open source ML проекты» остаются на уровне презентаций.
Как российские ML-проекты решают прикладные задачи
Если спуститься из мира красивых терминов к задачам, список довольно приземленный: анализ баз данных, прогнозирование спроса, распознавание речи, генерация текста под русскоязычную аудиторию, поиск аномалий в логах. В PROMAREN мы это видим даже в небольших компаниях: сначала приходит запрос «сделайте нам как ChatGPT», а в итоге вырастает очень конкретный ML-сервис, который, например, чистит и размечает обращения клиентов.
Согласно отраслевым обзорам, те же T-one и T-Wix от Т-Банка закрывают огромный пласт задач по речи и тексту — от колл-центров до внутренних ассистентов разработчика. При этом разворачиваются они в локальном окружении, без жесткой привязки к внешнему API вроде ChatGPT или GigaChat. Это кажется мелочью ровно до того момента, пока юристы не приносят распечатку 152-ФЗ с пометками маркером. И вот тут как раз становится важным, можно ли использовать open source AI так, чтобы не поседеть после первой же проверки.
Как аккуратно использовать open source AI
Да, open source AI в РФ можно использовать безопасно, если не забывать про данные и лицензии, а не только про скорость прототипа. Это значит, что сначала мы проверяем, что и куда утекает, а уже потом подключаем модную модель к продакшн-базе.
По состоянию на 2026 год Роскомнадзор и Минцифры довольно ясно формулируют позицию: использовать ИИ никто не запрещает, но персональные данные — отдельная песня, и 152-ФЗ никуда не делся. Официальные разъяснения и рекомендации по обезличиванию доступны на сайтах регуляторов, и я настойчиво предлагаю сначала открыть эти документы, а уже потом Hugging Face. По данным Роскомнадзора (официальный сайт), количество проверок по теме ИИ и данных растет, и это не тот фон, на котором хочется объяснять аудиторам, почему модель тренировалась на «слегка анонимизированных» выгрузках.
Какие шаги я всегда проверяю перед внедрением
Когда мы в PROMAREN заводим разговор про open source ML-проекты с бизнесом, я сначала рисую не архитектуру, а риск-матрицу. Список проверок примерно такой: что за лицензия у проекта, какие данные планируется прогонять, где физически будут жить модели и логи, есть ли план обновления и патчей безопасности. Звучит скучно, но именно тут чаще всего и вылезают сюрпризы.
- Лицензия: допускает ли она коммерческое использование и модификацию кода.
- Данные: нет ли в датасете персональных данных, коммерческой тайны и «серых» источников.
- Инфраструктура: находятся ли сервера в РФ и кто имеет к ним доступ.
- Безопасность: есть ли политика обновлений и управление уязвимостями.
- Поддержка: живо ли сообщество или проект давно заброшен.
Получается, что технически развернуть модель — самая простая часть. Сложнее убедиться, что завтра к вам не придет служба безопасности с вопросом «а почему это все крутится в непонятном облаке». Здесь работает один простой принцип: если вы не можете объяснить архитектуру проекта юристу на одной странице, значит, нужно ее упростить. И как только это удается, открытые AI-инструменты начинают чувствовать себя в компании гораздо комфортнее.
Как сочетаются open source и коммерческие платформы
Я часто слышу крайние позиции: либо только GigaChat/YandexGPT как сервис, либо «мы все напишем на питоне сами». На практике в 2025-2026 лучше всего работают гибридные схемы, где коммерческие модели используются для генерации, черновой разметки и помощи разработчикам, а российские open source-проекты закрывают критичные по данным куски.
Представь ситуацию: команда использует YandexGPT для генерации тестовых данных и черновых подсказок в интерфейсе, но сама бизнес-логика и хранение истории пользователей живет в локальной ML-системе, собранной на открытых библиотеках. Ошибки новичков здесь три — сразу гонять реальные персональные данные через внешние API, не закладывать бюджет на дообучение моделей и забывать мониторить качество. В PROMAREN мы уже воспринимаем это как чек-лист «что пойдет не так», если не договориться заранее. Логичный шаг дальше — опустить лупу ближе к самим проектам и посмотреть на конкретные семь решений.
Семь ML-проектов, которые уже работают в проде
Семь open source-проектов от команд в РФ закрывают сейчас до 60-70 % типичных задач ML в компаниях — от ревью кода до мониторинга продакшн-сервисов. Это значит, что вместо «мы ищем уникальный AI-прорыв» можно честно собрать стек из проверенных инструментов.
Часть этих решений ты наверняка уже видел мельком в новостях, но там они обычно подаются как «очередной прорыв в ИИ». На практике это довольно приземленные, но очень полезные кирпичики инфраструктуры. Я собрала их в мини-таблицу, чтобы было видно, кто за что отвечает и куда это обычно прикручивают в реальных проектах.
Проект Задача Где используют SourceCraft Анализ и ревью кода DevOps, внутренние платформы T-Wix / T-one Текст и речь Чат-боты, колл-центры Kandinsky Генерация изображений Маркетинг, дизайн Runtime Radar Мониторинг ML-сервисов SRE, observability
На практике каждый из этих кирпичей встраивается в свою зону ответственности: что-то ближе к разработчикам, что-то — к SRE, что-то любит продуктовая команда. Ниже — коротко, без романтизации, как они живут в реальных стэках.
Код, безопасность и стабильно работающий прод
SourceCraft я впервые увидела в бою у команды, которая устала от ручного ревью огромных монореп. ИИ-прослойка поверх обычных инструментов разработки помогла подсвечивать подозрительные фрагменты, секреты и возможные уязвимости до того, как человек вообще успевал открыть diff. По данным Яндекс B2B Tech, такие инструменты сокращают время на ревью в несколько раз, и по ощущениям разработчиков это действительно так — хотя никто не признается, сколько багов поймали именно за счет модели.
Кодовая безопасность — вторая категория, которую часто недооценивают до первого инцидента. Open source-проекты уровня CyberCodeReview проверяют репозитории на паттерны из OWASP Top 10 и встроены в знакомые CI/CD-цепочки. В одной команде, с которой мы работали, такой инструмент стал «тихим фильтром» для очевидных дыр, не заменяя ручной анализ, но снимая рутину с безопасников. В связке с мониторингом на уровне ядра (eBPF-подобные решения вроде Runtime Radar) это превращается в вполне зрелую историю observability, а не «мы надеемся, что всё нормально».
Текст, речь и картинки под русский язык
Если вернуться к более заметной части айсберга, текстовые и речевые модели — то, что пользователи видят напрямую. Те же T-Wix и T-one от Т-Банка обкатывались на внутренних задачах, а теперь работают в open source-режиме: генерация и обработка текста, распознавание речи, поддержка диалоговых систем. За счет заточки под русский язык и локальные сценарии они в некоторых кейсах обходят универсальные решения вроде ChatGPT — просто потому, что им не нужно «угадывать» особенности лексики и контекста.
Кандинский, как бы к нему ни относились дизайнеры, занял свою нишу в маркетинге и прототипировании визуала. Генерация изображений под локальный культурный контекст, без странных зарубежных ассоциаций, неожиданно экономит часы правок. В одном проекте для внутреннего портала мы использовали его для черновых иллюстраций: команда продукта сначала скептически отнеслась, а через месяц уже закладывала это в план работ. Забавно, но сработало. И все это живет рядом с коммерческими моделями типа YandexGPT и GigaChat, которые остаются удобными как «универсальный швейцарский нож», пока open source-проекты закрывают штуки, где нужно больше контроля.
На чем чаще всего ломаются AI-проекты в РФ
Девять из десяти пилотов ИИ в компаниях РФ так и не доживают до продакшена — и причина редко в «плохой модели». Чаще всего все ломается на стыке процессов, данных и ожиданий бизнеса, а не в алгоритмах машинного обучения.
Я раньше грешила тем, что пыталась спасать такие проекты дополнительными фичами и дообучением. Сейчас, после серии внедрений с PROMAREN, начинаю разговор с вопроса «кто будет это поддерживать через год» и «что будет, если модель ошибется». Обычно в этот момент в комнату тихо заходят юристы и служба безопасности, и градус энтузиазма становится реальным.
Пять типичных граблей внедрения open source AI
Если собрать опыт разных команд, картина довольно повторяемая. На словах все за «отечественные AI разработки и open source», на деле — одни и те же ошибки, которые не спасают даже самые крутые российские AI проекты.
- Сразу идут в прод с сырым прототипом, без поэтапного пилота и A/B-тестов.
- Проверяют только качество модели, игнорируя логику обработки ошибок и откатов.
- До последнего не решают вопрос с владельцами данных и ответственными за модель.
- Не закладывают бюджет и время на дообучение и поддержку после запуска.
- Считают, что open source «бесплатен», и забывают про стоимость инфраструктуры.
Я поняла, что все эти грабли отлично лечатся одной практикой — честной архитектурной сессией до начала экспериментов. Как только на доске появляются стрелки данных, точки отказа и фамилии ответственных, половина «сверхамбициозных» идей смирно превращается в реалистичные MVP. Иногда это выглядит скучно, но именно так рождаются те самые успешные российские AI-проекты, о которых потом любят рассказывать на конференциях.
Как мерить эффект и не влюбляться в технологию
Самый трезвый вопрос, который можно задать себе перед запуском ML-проекта: «Если модель исчезнет завтра, что потеряет бизнес в цифрах». Ответ в стиле «будет жалко, но не критично» — тревожный сигнал. Хороший знак, когда команда может назвать конкретные метрики: сэкономленные человеко-часы, снижение ошибок, рост выручки на конкретном участке.
По данным McKinsey и локальных исследований рынка AI в РФ (отчеты McKinsey), проекты, у которых с самого начала есть понятный ownership и набор KPI, в 2-3 раза чаще доходят до устойчивой фазы. В PROMAREN мы для себя зафиксировали простое правило: пока нет одной-двух бизнес-метрик под проект, мы считаем его экспериментом, а не внедрением. И да, иногда полезно честно зачеркнуть в блокноте «делаем космический AI-ассистент» и переписать на что-то вроде «сокращаем время обработки заявки на 30 %». Звучит менее героично работает намного устойчивее.
Куда всё это движется дальше
Когда смотришь на российские AI проекты не из Telegram-ленты, а изнутри компаний, картинка получается менее драматичной и более рабочей. Во-первых, open source перестал быть «игрушкой энтузиастов» и превратился в нормальный строительный материал для ML-решений. Во-вторых, выигрыш получают не те, у кого модель «умнее», а те, у кого архитектура проще и честнее под ограничения РФ. И в-третьих, самый ценный ресурс тут даже не данные, а люди, которые готовы раз за разом приземлять красивые идеи к реальному процессу.
Это означает, что устойчивые отечественные AI разработки будут рождаться не из больших лозунгов, а из маленьких, но последовательных шагов — локальный пилот, аккуратная интеграция, понятные метрики, обучение команды. А когда всё это соберется, слово «искусственный интеллект» перестанет пугать юристов и бухгалтерию и станет чем-то вроде еще одного привычного сервиса в инфраструктуре.
Обо мне. Я — Марина Погодина, основательница PROMAREN и AI Governance & Automation Lead, раньше занималась внутренним аудитом и ИТ-рисками. С 2024 года помогаю командам в РФ строить white-data AI-системы и автоматизацию под 152-ФЗ. Больше практики — в статьях про AI-инструменты и практику с нейросетями и в канале PROMAREN.
Если хочется разложить свой AI-проект по полочкам, без магии и паники, заглядывай на сайт PROMAREN — там я собираю подходы, которые пережили проверки и продакшен. А протестировать простые сценарии генерации контента можно через тестовый доступ к нашему боту — он пригодится, чтобы почувствовать, как ИИ встраивается в рутину.
Что ещё важно знать про российские AI-проекты
А если у нас маленькая компания, нам вообще нужен свой AI-проект?
Небольшой компании не обязательно запускать «свой» AI-проект, но использовать готовые российские AI-инструменты уже почти must-have. Это может быть один сервис распознавания речи или аналитики, который экономит несколько часов в день. Начните с простой задачи с понятной выгодой, протестируйте на отделе или одном процессе и только потом думайте о масштабировании на весь бизнес.
Можно ли строить ML-решения только на зарубежных платформах?
Теоретически можно, но для компаний в РФ это почти всегда повышенный юридический и инфраструктурный риск. Используя только зарубежные сервисы, вы зависите от их доступности, изменений условий и вопросов по передаче данных. Чаще всего безопаснее и устойчивее комбинировать коммерческие зарубежные API с отечественными open source-модулями и локальной инфраструктурой.
Что делать, когда безопасники блокируют любой эксперимент с ИИ?
Если служба безопасности на автомате говорит «нет», значит, они видят только риск, а не модель управления им. Помогает совместная сессия, где раскладываете архитектуру, потоки данных и зоны ответственности. Покажите, какие части можно обезличить, какие модели будут крутиться локально, а где применяются проверенные российские AI-проекты. Часто после этого «нет» превращается в «да, но с такими-то условиями».
Можно без своих дата-сайентистов, только силами разработчиков и аналитиков?
Да, базовые ML-сценарии вполне подъемны для команды разработчиков и продуктовых аналитиков, если использовать зрелые open source-проекты. Готовые модели, туториалы и примеры кода сильно снижают порог входа. Но как только вы уходите в сложные прогнозы, работу с шумными данными и высокие риски ошибок, нужен хотя бы внешний эксперт, который проверит подход и поможет настроить пайплайны.
Как понять, что наш AI-проект пора выносить в продакшен?
Проект готов к продакшену, когда у вас стабильные метрики качества и понятный процесс поддержки. То есть модель показывает приемлемую точность не только на тестах, но и на боевых выборках, а команда знает, кто следит за логами, обновлениями и дообучением. Если на вопросы «кто отвечает за инциденты» и «что делаем при деградации качества» есть конкретные имена и регламенты, а не тишина в чате, можно аккуратно выкатываться.