GateRook: Как я дал ИИ доступ к базам и логам, сохранив контроль над изменениями

В предыдущей статье (https://habr.com/ru/articles/1075720/) я рассказывала, как начала внедрять цифровых сотрудников в подразделение поддержки (компания занимается разработкой, внедрением и поддержкой ПО для автоматизации дистрибуции). Сначала сделали помощника инженера, потом стали передавать агентам часть клиентских обращений. Тогда я привела первые результаты: около 45% переданных диалогов завершались без участия инженера. После публикации я решила глубже разобраться, что на самом деле изменилось для пользователей. Процент автоматически решённых обращений удобен для презентации, но сам по себе мало что говорит о качестве поддержки. Агент может быстро закрыть простое обращение. Может передать сложное человеку, предварительно собрав все данные. А может уверенно дать неправильный ответ и тоже поставить статус «решено».

Оценка story points с помощью нейросети кажется быстрым способом ускорить планирование спринта. Но достаточно одной фразы о том, сколько, по мнению тимлида, должна стоить задача, чтобы оценки двух LLM изменились примерно на 20%. В эксперименте на исторических задачах Jira разбираемся, как работает эффект якоря при покер‑планировании и почему близкая к командной сумма ещё не означает точной оценки. Узнать результаты

Типовая ситуация 2026 года: компания подключила ИИ-агента к CRM, чтобы тот автоматически чистил дубликаты контактов. Агент ошибся в классификации, посчитал половину клиентской базы «дублями» и удалил её. Без хакерской атаки, без злого умысла со стороны разработчика — просто автономное исполнение ошибочного вывода модели. Кто виноват? Разработчик модели, интегратор, который собрал агента, или сама компания, которая его запустила? И главное — есть ли у кого-то из них страховой полис, который это покроет? Я изучила российскую законодательную базу по ИИ в части страхования и сравнила её с тем, как страхование ИИ-рисков устроено за рубежом.