Остановил собственный пилот, когда фундамент под ним оказался ненадёжным

Контекст

Производственная компания с двумя разными по возрасту и логике направлениями. Работает с производственными предприятиями, и данные к ней приходят от заказчиков в Excel — каждый в своём формате, то есть входной поток неструктурирован по определению.

Запрос от собственника прозвучал в форме, которая на этом уровне зрелости встречается редко. Ему нужно было не «внедрить нейросеть», а сделать так, чтобы весь контекст компании жил на её собственных ресурсах, а модели подключались к нему снаружи. Требование было выстраданным: однажды компания уже теряла доступ к ИИ-провайдеру из-за формальности с оплатой, и накопленное пришлось собирать заново.

Что болело

Самая точная формулировка боли пришла с той стороны стола: подход «скопировать результат из нейросети в документ» неэффективен, потому что теряются контекст, промпт и логика получения результата. Это названо системной проблемой, а не неудобством, — и это редкость, обычно на этом уровне говорят «нам бы чат-бота».

Вторая боль — хранение. Все наработки с ИИ должны были оставаться внутри организации, а фактическая практика — периодический бэкап переписок и общие почтовые аккаунты — задачу не решала. Полгода расшифровки совещаний вручную переносились в ИИ-сервис и раскладывались по папкам, но не были подключены ни к чему и оставались недоступны для быстрого просмотра. Полгода работы — и ноль возврата с этой работы.

Операционный фон: доступы заводились россыпью, рабочие устройства разбросаны по нескольким локациям, а задач в таск-трекере заведено больше, чем физически можно сделать. И реплика, которая объясняет запрос лучше любых метрик: «периодически сложно переключиться и вспомнить, что было, о чём договаривались».

Как подходил

Начал не с архитектуры, а с описания того, как поток устроен сейчас. Разобрали фактический путь: видеовстреча → расшифровка → почта → ручной перенос в ИИ-сервис. С прямыми репликами участников, без пересказа. Этот as-is оказался важнее любой схемы будущего состояния: он показал, что узкое место — не модель, а два ручных стыка подряд, и что автоматизировать надо стыки, а не мышление.

Второе решение — где живёт контекст. Вариант «папки в облачном диске» проиграл не по удобству, а по стоимости извлечения: чтобы модель ответила по такому хранилищу, ей приходится каждый раз перечитывать слишком много. Выбрали единое структурированное хранилище, из которого контекст достаётся адресно. Это решение принималось до всякой разработки, и оно определило всё остальное.

Третье — и я считаю его ключевым для этой работы — не пилотировать всё сразу. Сначала ограничили контур пятью внутренними и пятью внешними встречами: состав участников известен заранее, значит, ниже риск галлюцинаций на незнакомом контексте и есть с чем сверять результат. Потом сузили ещё раз — до точечного пилота на трёх-четырёх людях. Цель второго сужения была не технической: проверить гипотезу пользы до того, как строить полноценную архитектуру. Строить архитектуру под непроверенную пользу — самый дорогой способ ошибиться, и расплачивается за него обычно не тот, кто её проектировал.

Прототип цепочки «транскрипт → протокол → задачи в таск-трекере» собрали на low-code-платформе и показали в мае. Серьёзных возражений у команды не было. Параллельно готовился заход в команду: гайд интервью с семью базовыми вопросами по сорок пять минут на человека — чтобы собрать картину не со слов одного руководителя, а с рабочих мест.

Отдельным принципом в схему заложена верификация: протокол, собранный автоматически, попадает к людям только после того, как его посмотрел человек. Это не бюрократия и не недоверие к модели — это защита от того, что чувствительная формулировка из закрытого обсуждения окажется в общем таск-трекере на всеобщее обозрение.

Что мешало и что не получилось

Главное решение этого кейса — отрицательное, и принял его я, а не заказчик. В начале июня я остановил пилот автоматизации транскрипций и отложил двенадцать связанных задач. Причина — платформа видеовстреч, на которой всё держалось: задержки расшифровки доходили до суток, записи пропадали один-три раза в неделю, и это подтверждали те, кто работал с ней ежедневно. Строить цепочку «встреча → протокол → задачи» поверх источника, который теряет исходник несколько раз в неделю, — значит гарантированно получить претензию «ваша система не работает» в адрес того звена, которое как раз работает. На последний зафиксированный срез пилот не разморожен.

Останавливать собственную работу неприятно и выглядит как провал. Но альтернатива хуже: запустить контур, который будет ронять протоколы, и потратить оставшееся доверие на объяснения, что виноват не он.

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

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

Третье — заказчик буквально не понимал, что делать с инструментом. Повестку одного из июльских созвонов сформулировали с той стороны сами: «не совсем понимаем, что создавать». Это честный сигнал, и он говорит не о людях, а о том, что мы отдали инструмент раньше, чем сценарий его использования. Техника добавляла трения: коннектор к базе знаний не отображался в ИИ-клиенте сразу у нескольких человек, и формулировка команды была «мы пока плаваем».

Была и чисто инженерная засада: часть комментариев к задачам таск-трекера не отдаётся через его REST API — воспроизвели потом и в другом контуре. Не наша ошибка, но обходить пришлось нам.

Что стало

Измеренных бизнес-метрик у этого кейса нет — ни часов, ни денег, ни объёмов. Поэтому в карточке нет цифр, и придумывать их я не буду.

Что изменилось качественно и что я считаю реальным результатом:

Внутреннее сопротивление перестало быть блокирующим. Интервью с сотрудниками пошли, состав и тематику согласовали с той стороны, работа получила ритм. Для инициативы, которая до этого стояла, это дороже любого прототипа.

Компания начала пользоваться графом знаний самостоятельно и без нашего участия: внутри появился собственный проект — книга, структурированная как граф примерно из одиннадцати глав, — и в течение суток к нему подключились ещё два человека. Самостоятельное расширение без нашего участия — единственный надёжный признак того, что инструмент прошёл барьер «нам показали» и попал в разряд «нам нужно».

И честный минус: центральный сценарий, с которого всё начиналось, — автоматические протоколы и задачи из встреч — остаётся замороженным. Он ждёт не денег и не разработки, а замены ненадёжной платформы записи встреч.