Как «технически невозможно» обернулось одной настройкой
Реальный проект: строил помощника, который живёт в корпоративном мессенджере — делает сводки по чатам, расшифровывает совещания, читает документы. Самое ценное в нём оказалось не в функциях, а в двух открытиях.
Я отвечал за архитектуру помощника, разделение прав и интеграцию с мессенджером — от начала до конца. И первое важное решение родилось не из кода, а из проверки одного мифа.
Считалось, что сводки по зашифрованным чатам технически невозможны — а значит, нужно строить обход: выгружать переписку отдельно, парсить содержимое стороннего механизма. Прежде чем писать этот обход, мы потратили день на документацию платформы — и нашли штатный механизм получения содержимого для доверенных приложений. Обход не понадобился. «Нельзя» оказалось просто выключенной настройкой — и это сэкономило недели работы.
Второе решение — осознанное ограничение. Помощнику специально не дали доступа ни к одной внутренней системе компании, кроме самого мессенджера. Чем меньше прав у сервиса, тем меньше он может навредить, даже если что-то сломается.
И оно сломалось. Помощник замолчал, и внешне это выглядело как обычная блокировка политикой доступа — то есть штатный отказ, а не поломка. На разбор ушло шесть суток, прежде чем нашлась настоящая причина — устаревший номер версии ключа. Теперь такую проблему видно за минуту: достаточно посмотреть на номер версии.
• Сводки по зашифрованным чатам: считались невозможными → работают штатным механизмом • Доступ помощника к внутренним системам: отсутствует по замыслу, а не по забывчивости • Диагностика отказа: неотличим от штатной политики → определяется за минуту по номеру версии ключа • Поломка сервиса: 6 суток незаметно → видна за минуту • Стоимость дневной сводки: около двух центов
Самый дорогой этап проекта — не написание кода, а проверка, что «нельзя» действительно означает «нельзя», а не «не включено».
Полный разбор с деталями кейса →
Кейсы: как бизнес зарабатывает на ИИ-агентах
