Несмотря на очевидную выгоду, процесс внедрения ИИ в российских компаниях нередко требует дополнительных усилий и ресурсов. Главная проблема — разрыв между бизнес-целями и технологическими возможностями. Без единого диалога бизнес формулирует задачи в отрыве от технической реализации, а разработчики создают решения, не видя полной стратегической картины.
Айканыш Орозбаева, Директор по развитию бизнеса Embedika, рассказала, почему запуск ИИ-проекта — это только начало, какую роль в этом играют разработчики и как компании выстроить процессы так, чтобы избежать лишних затрат времени и средств.
Ниже приводим текст оригинальной публикации.
ИИ-продукт как живая система
Чтобы преодолеть этот разрыв:
- со стороны заказчика требуется системный подход — вовлечение в процесс продуктовых аналитиков и менеджеров, чья задача — выявлять не только очевидные, но и скрытые потребности бизнеса и трансформировать их в структурированные требования;
- разработчики и вендоры выступают не просто исполнителями, а активными участниками диалога. Они погружаются в бизнес-процессы заказчика, чтобы предложить не просто технологию, а максимально интегрированное решение, учитывающее отраслевую специфику и долгосрочные цели.
Такой партнерский формат взаимодействия, где обе стороны действуют согласованно, позволяет бизнесу извлечь максимальную пользу из ИИ и избежать лишних затрат.
Классическая ошибка, с которой мы в том числе сталкивались, — когда заказчик, стремясь сэкономить, формирует техническое задание в отрыве от консультаций с исполнителем. В результате разработчик вынужден создавать решение под узкий, заранее определенный функционал и бюджет. На практике это часто приводит к ситуации, когда после пилотного запуска выясняется необходимость масштабирования на другие бизнес-процессы или категории документов.
Архитектура, изначально не рассчитанная на рост, не выдерживает. Ключевые компоненты системы приходится заменять на более гибкие, что ведет к многократному пересмотру бюджета и сроков, а иногда и к полной остановке проекта.
Бизнес, а не только про технологии
Если в традиционном продукте разработчик реализует заранее заданную бизнес-логику, то в ИИ-системах он не только работает над техническим воплощением, но и помогает бизнесу переосмыслить и оптимизировать процессы, внедряя новую логику.
Разработчик не просто исполнитель технического задания, а медиатор между задачами бизнеса и технологическими возможностями.
Он анализирует предоставленные заказчиком данные, оценивает структуру и процессы, а также применяет продуктовый подход: помогает выявлять скрытые проблемы, которые бизнес может не осознавать, и предлагает эффективные решения.
Яркий пример такого партнерского подхода — сфера LegalTech, в которой автоматизируются юридические процессы и работа с документами. Здесь наиболее успешные решения часто рождаются именно в коллаборации:
- юристы как носители предметной экспертизы формулируют боли и задачи;
- разработчики, глубоко погрузившиеся в отраслевую специфику, предлагают технологические решения и выявляют даже те потребности, которые бизнес не всегда осознает.
Например, мы столкнулись с ситуацией, когда крупная компания на рынке климатической техники изначально обратилась с запросом на ускорение проверки договоров. Юристы жаловались на высокую нагрузку — ручной анализ одного документа занимал до полутора часов. Однако в ходе совместного изучения вопроса стала очевидна более глубокая проблема: существующие процессы создавали «бутылочное горлышко», ограничивающее рост компании.
Вместе мы разработали решение на базе платформы Contract, которое не просто автоматизировало проверку, но и выявило системные риски в типовых формулировках. В результате время проверки сократилось на 65%, а компания смогла обрабатывать на 30% больше договоров без расширения штата.
Причина тому — частые ограничения в доступе к специализированным данным и требования локального регулирования, которые делают универсальные решения неэффективными или невозможными для применения. Локальность и специфика отраслей требуют, чтобы ИИ-решения создавались «изнутри», с глубоким пониманием контекста и ограничений, что открывает пространство для экспертов-разработчиков, знакомых с отраслевой практикой.
При этом стандартные системы поиска не могли работать с отраслевой терминологией и находить документы по смыслу.
Вместо простого «ускорения поиска документов» мы внедрили в работу команд интеллектуальную платформу Cursor, которая не только сократила время поиска до секунд, но и выстроила связи между документами двадцати различных организаций холдинга, создав единое информационное пространство.
Тандем с разработчиками
Приведу в пример другой наш проект для инжиниринговой компании, сопровождающей строительство нефтегазовых объектов. Изначально стояла задача создать «инструмент для управления технической документацией», но в ходе совместной работы мы выявили ключевую проблему — 47% сложностей возникало на этапе строительства из-за несоответствий между проектной и эксплуатационной документацией.
В ситуациях, когда требуется погружение в новую предметную область, наша команда использует итеративный формат работы. Вместо того чтобы месяцами изучать специфику нефтегазовой отрасли до начала разработки, мы параллельно создавали прототипы и тестировали их на реальных данных заказчика. Этот процесс позволяет не изучать бизнес заказчика с нуля, а быстро выявлять и верифицировать критически важные элементы для успеха ИИ-решения.
Роль бизнеса на этом этапе также критически важна — его глубинное понимание процессов и проблем позволяет совместно с разработчиком сформулировать те самые задачи, достижение которых принесет реальную ценность.
В таких случаях продукт создается поэтапно:
- сначала мы разработали MVP платформы для структурной разметки инженерной модели, которая позволила проектировщикам оперативно находить связанные документы;
- на следующей итерации добавили семантический поиск и инструменты для выявления противоречий между обновленными и устаревшими версиями документов. В результате заказчик получил инструмент проактивного управления рисками, сокращающий влияние неизбежных проблем на сроки и бюджет проекта.
Так формируется новый тип взаимодействия: разработчик не просто создает инструмент, а помогает бизнесу сформулировать саму проблему. Это требует высокой вовлеченности и доверия от обеих сторон.
Другие нюансы
Стоит помнить о том, что ИИ работает не только с живыми данными, которые меняются, бывают неполными или искаженными, но и с бизнес-логикой, которая тоже может эволюционировать. Данные, использовавшиеся ранее для одних целей, могут приобрести новое значение, а с добавлением новых функций или изменений в процессах модель требует доработки. Если не обновлять модель и не учитывать эти изменения, качество результата может резко упасть.
Например, в наших проектах по анализу юридических документов система, показывающая отличную точность на чистых образцах, может ошибаться при работе с реальными историческими архивами, содержащими сканы низкого качества или устаревшие формулировки.
Без регулярного дообучения моделей на новых данных и тонкой настройки под изменяющиеся типы документов и правовые нормы, система постепенно теряет свою точность и перестает предоставлять корректные выводы.
Рассмотрим данную ситуацию на примере нашего опыта внедрения систем для анализа и экспертизы документов на базе технологий ИИ — в частности, решения Contract для автоматизированной проверки юридических документов.
Основной сложностью на старте проекта была работа с крайне разрозненной информацией: до 90% корпоративного контента было не структурировано, сотрудники искали материалы в четырех различных системах, а 43% документов застревали на этапах согласования. Работа велась поэтапно.
- После запуска MVP с базовым поиском мы непрерывно собирали аналитику по использованию системы и обратную связь от пользователей.
- Критически важным оказался этап гармонизации и структурирования базы нормативно-методических д окументов, где нам пришлось объединить документы из всех источников в единое пространство, автоматически выявляя дубликаты и противоречия.
- Это позволило нам в последующих итерациях:
— внедрить семантический поиск;
— построить граф связей между документами для выявления дублирующихся требований;
— запустить систему актуализации документов и аналитические дашборды для руководства
