За последние три года я видел десятки проектов, где языковые модели встроили в рабочие процессы и получили прирост скорости в разы. И столько же случаев, где та же технология привела к штрафу, потере клиента или переписыванию всей работы заново. Разница почти никогда не в модели и не в качестве запроса. Разница в том, какую задачу человек решил передать машине.
Ниже разбор того, где граница проходит реально, а не по интуиции. Начнём с механики ошибок, потому что без понимания причин любой список запретов выглядит произвольным.
Почему ИИ ошибается в критичных задачах
Языковая модель не хранит факты так, как их хранит база данных. Она хранит статистические связи между словами и восстанавливает ответ как наиболее вероятную последовательность. В большинстве бытовых и рабочих запросов наиболее вероятный ответ совпадает с верным, поэтому модель кажется знающей. Но совпадение вероятного и верного не гарантировано архитектурой, и именно в этом зазоре живут все серьёзные провалы.
Для практики важно, что сбои распределены неравномерно. Модель почти не ошибается в задачах, где ответ проверяется за секунды, и ошибается чаще всего там, где проверка требует времени, доступа к первоисточнику или специальной квалификации. Это злая закономерность, потому что именно такие задачи люди охотнее всего делегируют.
Галлюцинации и уверенный тон
Галлюцинация — это правдоподобный ответ, не имеющий основания в реальности. Модель не умеет сообщать о пробеле в знаниях так, как это делает человек, потому что у неё нет внутреннего индикатора незнания. Вместо пустоты она генерирует наиболее вероятное заполнение. Номер статьи закона, название приказа, дозировка, формула, фамилия автора исследования, ссылка на страницу сайта — всё это синтезируется по образцу того, как выглядят подобные данные.
Опаснее всего, что стилистика ответа не меняется. Когда модель знает точный ответ и когда она его сочиняет, текст звучит одинаково ровно и компетентно. Человек бессознательно считывает уверенность как признак надёжности, и привычный сигнал тревоги не срабатывает.
- Выдуманные реквизиты документов встречаются чаще всего, потому что их структура легко имитируется.
- Несуществующие судебные решения с правильным форматом номера и даты выглядят убедительно даже для юриста без проверки по базе.
- Ссылки на исследования обычно собираются из реальных фамилий, реального журнала и неверного года или вовсе отсутствующей статьи.
- Цитаты известных людей достраиваются по смыслу запроса, а не извлекаются из источника.
- Цифры в расчётах могут быть правильно пересчитаны по неверно взятой ставке или коэффициенту.
Отдельная категория — вежливое согласие с ошибочной посылкой. Если в запросе содержится неверное утверждение, модель чаще достроит ответ на его основе, чем оспорит его. Специалист, который спрашивает, как оформить то, что оформлять нельзя, получит инструкцию, а не возражение.
Устаревшие данные и неполный контекст
Знания модели ограничены датой обучения, и это ограничение жёсткое. В российской практике оно бьёт особенно больно, потому что регулирование меняется быстро. Налоговые ставки, лимиты упрощённой системы налогообложения, правила маркировки, требования к обработке персональных данных, условия государственных программ поддержки — всё это переписывается чаще, чем обновляются модели.
Доступ к поиску ситуацию улучшает, но не снимает. Модель с поиском может найти свежий документ и всё равно смешать его с устаревшим фрагментом из собственной памяти. Проверка по дате публикации источника остаётся работой человека.
Вторая часть проблемы тоньше. Модель не знает вашего контекста, если вы его не передали, и не знает, что именно вы забыли передать. Она не видит договор, который вы подписали два года назад, не знает про неформальные договорённости с поставщиком, не в курсе, что один из участников сделки находится в предбанкротном состоянии. Ответ формируется по усреднённой ситуации, а решения принимаются в конкретной.
Модель отвечает не на вашу задачу, а на ту задачу, которую вы сумели описать словами. Разница между этими двумя задачами и есть зона риска.
Нет ответственности за последствия
Это не юридическая формальность, а системное свойство. Специалист, подписывающий заключение, несёт репутационные, финансовые и иногда уголовные риски, и этот факт меняет его поведение. Он перепроверит спорное место, откажется от задачи вне своей компетенции, поставит оговорку, позвонит коллеге. Модель не несёт ничего и поэтому не имеет причин осторожничать.
На практике это означает, что ответственность не исчезает, а полностью перекладывается на того, кто нажал кнопку. Если бухгалтер сдал отчёт с ошибкой, подсказанной моделью, штраф выпишут организации. Если врач назначил препарат по рекомендации чата, отвечать будет врач. Если подрядчик сдал заказчику текст с выдуманной статистикой, претензию получит подрядчик.
Как три причины складываются в одну проблему
По отдельности каждый фактор управляем. Галлюцинации ловятся проверкой, устаревшие данные — сверкой с первоисточником, отсутствие ответственности — участием человека в финальном решении. Беда в том, что они накладываются именно в критичных задачах и усиливают друг друга.
- Задача сложная, поэтому у человека нет компетенции проверить ответ самостоятельно.
- Ответ звучит компетентно, поэтому потребность в проверке не ощущается.
- Проверка требует времени и доступа к источникам, поэтому её откладывают.
- Ошибка проявляется не сразу, а через недели или месяцы, когда цепочка решений уже выстроена.
- К этому моменту исправление стоит в десятки раз дороже первоначальной задачи.
Отсюда главный рабочий критерий. Нельзя делегировать то, что вы не можете проверить, и то, цена ошибки в чём превышает выгоду от сэкономленного времени.
Какие задачи нельзя доверять ИИ
Список ниже собран из разборов реальных инцидентов в российских компаниях за последние два года. Это не запрет на использование технологии в этих областях, а запрет на передачу ей финального решения без квалифицированного человека в цепочке.
- Юридические документы и трактовка норм закона.
- Медицинские диагнозы, назначения и дозировки.
- Финансовые и инвестиционные решения.
- Обработка персональных данных и коммерческой тайны.
- Кадровые решения о найме, оценке и увольнении.
- Финальная проверка фактов, цифр, цитат и источников.
- Решения с этическим выбором и конфликтом интересов.
- Код, уходящий в рабочую среду без ревью.
- Расчёты, влияющие на безопасность людей.
- Публичные заявления и переписка от лица компании.
Первые три разберём подробно сейчас, остальные — в продолжении.
Юридические документы и трактовка норм закона
Право работает на точности формулировок и на иерархии источников. Модель воспроизводит юридический стиль блестяще и этим создаёт ложное ощущение надёжности. Договор, написанный языковой моделью, выглядит как договор, составленный юристом, но содержит риски, которые видны только профессионалу.
Типичные сбои в этой области выглядят так.
- Ссылки на статьи, которые утратили силу или были перенумерованы при изменении кодекса.
- Формулировки, скопированные из зарубежной практики и не имеющие силы в российской юрисдикции.
- Условия об ответственности, противоречащие императивным нормам и потому недействительные.
- Пропуск обязательных реквизитов, без которых документ не пройдёт регистрацию или проверку.
- Смешение норм для разных организационно-правовых форм в одном документе.
- Отсутствие оговорок, которые юрист добавляет именно под специфику сделки.
Особенно показателен случай с договором подряда у небольшой производственной компании. Текст собрали по образцу, предложенному моделью, подписали, через полгода пришёл спор по качеству. Пункт о порядке приёмки был написан так, что любая просрочка возражений заказчика автоматически означала приёмку без претензий. Формально грамотно. Фактически компания потеряла возможность предъявить требования по скрытым недостаткам. Правка одного абзаца юристом стоила бы несколько тысяч рублей, спор обошёлся в сумму с шестью нулями.
При этом модель полезна в правовой работе, если задачу сузить. Она хорошо делает первичную структуру документа, собирает перечень вопросов для юриста, переводит юридический текст на понятный язык для внутреннего обсуждения, находит несогласованности между пунктами длинного договора. Всё это подготовка, а не решение.
Медицинские диагнозы, назначения и дозировки
Здесь цена ошибки не измеряется деньгами, поэтому требование строже. Диагноз строится на совокупности данных, часть которых в принципе не передаётся текстом. Врач видит пациента, слышит интонацию, оценивает динамику, держит в голове историю наблюдения и результаты осмотра. Модель получает выжимку симптомов, уже отфильтрованную тревогой или, наоборот, недооценкой самого пациента.
Структурная проблема в том, что модель склонна к наиболее вероятному объяснению. В медицине наиболее вероятное объяснение верно в большинстве случаев, и ровно поэтому редкое и опасное состояние пропускается именно там, где пропускать нельзя.
Самая опасная медицинская консультация — та, после которой человек успокоился и не пошёл к врачу.
Что в этой области недопустимо передавать модели.
- Постановку диагноза по описанию симптомов.
- Выбор препарата, схемы приёма и дозировки.
- Трактовку результатов анализов и инструментальных исследований как основание для действий.
- Решение об отмене или замене назначенного лечения.
- Оценку совместимости препаратов, которую нужно сверять по актуальным инструкциям.
- Любые суждения о состоянии детей, беременных и людей с хроническими заболеваниями.
Допустимое применение существует и оно не бесполезно. Модель помогает разобраться в терминологии из выписки, подготовить список вопросов к приёму, понять общий принцип действия назначенного препарата, структурировать дневник наблюдений за симптомами. Это повышает качество разговора с врачом, а не заменяет его.
Финансовые и инвестиционные решения
Финансы кажутся идеальной областью для машины, потому что всё выражается числами. Иллюзия рассеивается на двух деталях. Во первых, арифметика внутри языковой модели не вычисляется, а предсказывается, если не подключён отдельный расчётный модуль. Во вторых, финансовое решение всегда привязано к горизонту, допустимому риску и личной ситуации, которых модель не знает.
К запретной зоне относится следующее.
- Выбор конкретных инструментов для вложения средств и момента входа.
- Оценка налоговых последствий сделки без сверки с действующими нормами и разъяснениями.
- Расчёт отчётности и налоговой базы как итоговый результат, а не как черновик.
- Решения о кредитной нагрузке и реструктуризации долга.
- Прогнозы, на которых строится бюджет или инвестиционный план.
- Оценка финансового состояния контрагента вместо проверки по реестрам и отчётности.
В одном проекте мы разбирали, как модель посчитала эффективность рекламного канала и выдала срок окупаемости, который убедил собственника увеличить бюджет втрое. Ошибка была в том, что в расчёт попала выручка, а не маржа, причём это нигде не было обозначено. Структура расчёта правильная, логика изложения безупречная, вывод противоположен реальности. Через два месяца компания сворачивала кампанию с убытком.
Рабочая модель применения здесь другая. Машина хорошо строит сам каркас расчёта, перечисляет факторы, которые нужно учесть, объясняет принцип работы финансового инструмента, помогает собрать сценарии для последующей проверки. Числа и выводы остаются за человеком, который понимает, откуда взялась каждая строка.
Обработка персональных данных и коммерческой тайны
Это единственный пункт списка, где риск возникает не от ошибки модели, а от самого факта обращения к ней. Данные, отправленные в публичный сервис, покидают контур компании. Дальше вступают в силу пользовательское соглашение провайдера, его политика хранения и его юрисдикция, а не внутренний регламент организации.
Для российских компаний здесь сходятся два отдельных риска. Первый связан с требованиями к обработке персональных данных, включая локализацию и необходимость законного основания для передачи сведений третьим лицам. Второй носит чисто коммерческий характер и не зависит от регулирования вовсе. Информация о себестоимости, условиях работы с поставщиками, нереализованных разработках и клиентской базе имеет ценность ровно до момента, пока она закрыта.
Типичные утечки происходят буднично и почти всегда без злого умысла.
- Сотрудник вставляет выгрузку из базы клиентов целиком, чтобы попросить разложить её по сегментам.
- Руководитель загружает подписанный договор с полными реквизитами и суммами, чтобы получить краткое изложение.
- Специалист по кадрам отправляет резюме кандидатов с паспортными данными и адресами для сравнения опыта.
- Бухгалтер пересылает фрагмент отчётности с оборотами, чтобы разобраться в несходящейся строке.
- Разработчик копирует кусок кода вместе с рабочим ключом доступа, забыв его вырезать.
- Врач или администратор клиники просит переформулировать текст, не удалив фамилию и диагноз пациента.
Отдельного внимания заслуживает история с медицинским центром, где через модель прогоняли расшифровки консультаций для составления протоколов. Технически удобно, экономия времени ощутимая. Проблема вскрылась при внутреннем аудите, когда выяснилось, что согласие пациентов на такую обработку не оформлялось вообще, а сам сервис хранил историю запросов на стороне провайдера. Исправление потребовало остановки процесса, пересмотра документов о согласии и объяснений с проверяющими.
Любой текст, отправленный в публичную модель, следует считать опубликованным. Решение принимать нужно исходя из этого допущения, а не из обещаний в пользовательском соглашении.
Безопасный режим работы здесь строится не на запрете, а на обезличивании и выборе контура. Персональные данные заменяются условными обозначениями, суммы округляются или заменяются пропорциями, названия контрагентов убираются. Если задача требует работы с реальными данными постоянно, вопрос переходит из плоскости аккуратности в плоскость инфраструктуры, и решается развёртыванием модели внутри собственного контура с подписанными внутренними регламентами.
Кадровые решения о найме, оценке и увольнении
Автоматический отбор кандидатов выглядит как идеальная задача для машины. Поток резюме большой, критерии вроде бы формализуемы, время дорогое. Проблема в том, что модель воспроизводит закономерности своих обучающих данных, а эти данные отражают прошлые решения людей вместе со всеми их перекосами.

На практике это проявляется в нескольких устойчивых эффектах.
- Предпочтение привычных формулировок в резюме вместо оценки реального опыта, из за чего сильные кандидаты с нестандартной биографией отсеиваются первыми.
- Скрытая корреляция между возрастом, полом, местом учёбы и итоговой оценкой, которую невозможно увидеть в самом ответе.
- Наказание за перерывы в стаже без разбора причины, включая отпуск по уходу за ребёнком и смену сферы деятельности.
- Переоценка кандидатов, умеющих писать резюме под алгоритм, относительно тех, кто умеет делать работу.
- Уверенные выводы о личных качествах человека по тексту, который он написал за пятнадцать минут.
Юридическая сторона тоже не декоративная. Отказ в приёме на работу по признакам, не связанным с деловыми качествами, оспорим, и объяснение о том, что так решила система, не является аргументом ни в споре с кандидатом, ни в разговоре с проверяющим органом. Решение принимает работодатель, инструмент лишь оформил формулировку.
Ещё болезненнее выглядят попытки передать модели оценку работающих сотрудников. Текст рабочей переписки, количество закрытых задач и формальные показатели описывают поведение человека очень частично. Специалист, который тянет на себе коммуникацию с проблемным клиентом или наставничество над новичками, в метриках выглядит слабее, чем тот, кто быстро закрывает простые задачи.
Польза в кадровой работе при этом вполне реальная. Модель хорошо пишет черновик описания вакансии, собирает список вопросов для собеседования под конкретную компетенцию, помогает структурировать систему оценки, приводит в читаемый вид обратную связь, которую руководитель сформулировал сам. Ни одно из этих действий не является решением о судьбе человека.
Финальная проверка фактов, цифр, цитат и источников
Тут возникает логическая петля, которую часто не замечают. Модель не может быть последней инстанцией проверки информации, потому что сама является источником того типа ошибок, которые требуется поймать. Просьба проверить текст на достоверность даёт ответ в формате проверки, а не результат проверки.
Наблюдаемое поведение в таких запросах довольно характерно.
- Модель подтверждает то, что звучит правдоподобно, независимо от фактической верности.
- При настойчивом сомнении со стороны человека она меняет позицию, даже если изначальный ответ был верным.
- Выдуманные источники получают пометку о достоверности, потому что их формат соответствует формату настоящих.
- Числа, пришедшие из запроса, принимаются за данность и не ставятся под сомнение.
- Отсутствие информации истолковывается как отсутствие противоречий.
Распространённый случай из редакционной практики. Автор сдал материал со статистикой по рынку, подтверждённой ссылками на исследования. Редактор прогнал текст через модель с запросом на проверку фактов и получил подтверждение. При ручной сверке выяснилось, что два исследования из пяти не существуют, а в третьем цифра относится к другому году и другой стране. Два этапа проверки прошли, а ошибка осталась, потому что оба этапа опирались на один и тот же механизм.
Проверка имеет смысл только тогда, когда она опирается на источник, независимый от того, кто дал первоначальный ответ.
Единственная корректная роль модели на этом участке состоит в поиске мест, требующих проверки. Она хорошо находит в тексте утверждения без подтверждения, несогласованные цифры, внутренние противоречия и места, где вывод не следует из приведённых данных. Дальше человек идёт к первоисточнику.
Решения с этическим выбором и конфликтом интересов
Этические развилки отличаются от остальных задач тем, что у них нет правильного ответа, вычисляемого из условий. Есть выбор между ценностями, за который кто то должен отвечать перед другими людьми. Модель даёт ответ, усреднённый по текстам, на которых обучалась, и подаёт его с той же ровной уверенностью, что и ответ о синтаксисе запроса к базе данных.
К этой категории относятся ситуации, которые в бизнесе встречаются постоянно.
- Выбор между сокращением штата и снижением выплат всей команде.
- Решение о том, раскрывать ли клиенту ошибку, которую он пока не заметил.
- Распределение ограниченного ресурса между подразделениями или проектами.
- Оценка того, где заканчивается законная оптимизация и начинается обход правил.
- Поведение в ситуации, где интересы заказчика расходятся с интересами конечного пользователя.
- Решение о продолжении работы с контрагентом, чья репутация вызывает вопросы.
Опасность не в том, что совет окажется плохим. Опасность в том, что внешне обоснованный ответ снимает с человека необходимость думать и создаёт ощущение, будто решение принято объективно. Этический выбор, переданный инструменту, не становится более правильным, он просто перестаёт быть осознанным.
Полезное применение сводится к расширению картины. Модель называет стороны, чьи интересы затронуты, формулирует возможные последствия каждого варианта, напоминает про аргументы, которые легко упустить в споре. Решение остаётся за тем, кто будет смотреть в глаза людям, которых оно коснётся.
Код, уходящий в рабочую среду без ревью
Генерация кода — одна из самых успешных областей применения языковых моделей, и именно поэтому здесь легче всего потерять осторожность. Код, который работает, и код, который безопасен, совпадают далеко не всегда. Запуск без проверки означает, что ошибка попадёт не в черновик, а в работающую систему с реальными пользователями и реальными данными.
Повторяющиеся категории проблем выглядят так.
- Сборка запросов к базе данных через подстановку строк вместо параметров, что открывает путь для внедрения кода.
- Отсутствие проверки прав доступа в обработчике, потому что в запросе про неё не спрашивали.
- Устаревшие или небезопасные библиотеки, популярные на момент обучения модели.
- Обработка ошибок, которая молча проглатывает сбой вместо того, чтобы его зафиксировать.
- Логика, корректная на малых объёмах и разваливающаяся при росте нагрузки.
- Секретные ключи и пароли, оставленные прямо в тексте примера.
- Названия пакетов, которых не существует, что создаёт отдельный риск подмены зависимости злоумышленником.
Характерный случай произошёл в сервисе бронирования, где обработчик отмены заказа был написан по сгенерированному образцу. Код работал, тесты проходили, проверку прав владельца заказа никто не добавил, потому что в исходной постановке задачи о ней не было ни слова. Через месяц выяснилось, что по прямому обращению можно отменить любой чужой заказ, зная только его номер.
Рабочее правило простое. Ответственность за код несёт тот, кто его принял, а не тот, кто его сгенерировал, поэтому ревью человеком остаётся обязательным этапом независимо от происхождения кода.
Расчёты, влияющие на безопасность людей
Конструкции, несущие нагрузку, электрические схемы, параметры оборудования, пищевые производства, перевозки опасных грузов. В этих областях существуют нормативные документы, методики расчёта и порядок согласования, причём обязательные к применению. Модель воспроизводит общую логику расчёта и при этом свободно подставляет не тот коэффициент, не ту редакцию норматива или не тот класс материала.
Дополнительная сложность в том, что ошибка часто не проявляется на границе нормы. Конструкция стоит, оборудование работает, запас прочности съеден. Проблема вскрывается при нештатной ситуации, то есть ровно тогда, когда запас и был нужен.
Здесь граница проходит жёстче, чем во всех остальных пунктах. Расчёт, от которого зависит жизнь человека, выполняет аттестованный специалист по действующей методике, и формат этого расчёта определяется нормативом, а не удобством.
Публичные заявления и переписка от лица компании
Текст, отправленный от имени организации, становится её позицией. Модель не чувствует историю отношений с конкретным клиентом, не знает, что эта тема в компании болезненная, не понимает, где формулировка юридически значима, а где просто вежлива. Ответ получается гладким и ровно поэтому иногда катастрофическим.
Наиболее рискованные типы сообщений перечислю отдельно.
- Ответы на претензии и жалобы, где любая фраза может быть истолкована как признание вины.
- Публичные комментарии в ситуации конфликта или негативной огласки.
- Сообщения о сбоях, задержках и изменениях условий обслуживания.
- Переписка с проверяющими органами и официальные обращения.
- Заявления, затрагивающие общественно значимые или политические темы.
- Коммуникация об изменениях, касающихся сотрудников.
Автоматические ответы в поддержке допустимы, но при одном условии. Сценарии, где модель отвечает самостоятельно, должны быть заранее ограничены простыми и однотипными обращениями, а всё, что выходит за границу сценария, должно передаваться человеку без попытки сымпровизировать.
Задачи, где ИИ допустим только как черновик
Эта категория устроена иначе, чем предыдущая. Запрета нет, выигрыш во времени реальный и часто значительный. Условие одно. Результат считается заготовкой, а не готовой работой, и между заготовкой и использованием стоит человек, который понимает предмет.
Разница ощутима в цифрах. Задача, которая целиком выполнялась четыре часа, в режиме черновик плюс доработка занимает примерно полтора, и качество при этом не падает. Та же задача в режиме принять как есть занимает двадцать минут и с заметной вероятностью возвращается на переделку целиком.
| Тип задачи | Что делает модель | Что обязан сделать человек |
|---|---|---|
| Тексты и структуры | Каркас, варианты формулировок, план | Факты, смысл, авторская позиция |
| Анализ данных | Первичная группировка, гипотезы, аномалии | Проверка расчёта и обоснованности выводов |
| Код для внутренних задач | Заготовка, разбор ошибки, рутинные правки | Чтение кода, тесты, оценка последствий |
| Перевод и адаптация | Черновой перевод, варианты тона | Терминология, точность, уместность |
| Идеи и гипотезы | Широкий перечень вариантов | Отбор, проверка реализуемости |
Тексты, структуры, план материала
Модель снимает самую утомительную часть работы с текстом, то есть сопротивление пустому листу и сборку скелета. Она быстро предложит структуру, развернёт тезис в абзац, перепишет громоздкую фразу, подготовит несколько вариантов заголовка. Всё это экономит часы.
Чего она не делает, тоже стоит перечислить прямо.
- Не приносит фактуру, которой нет в открытых источниках или в вашем опыте.
- Не отличает общеизвестное от неочевидного и потому размывает ценность материала.
- Не имеет позиции и подменяет её взвешенной формулировкой без выводов.
- Не знает контекст рынка, на котором работает ваша компания, если вы его не описали.
- Склонна к усреднённой гладкости, в которой исчезает всё узнаваемое.
Практический признак того, что текст сдали без доработки, виден сразу. В материале нет ни одной цифры, которую нельзя было бы получить без обращения к источникам, ни одного примера с конкретными обстоятельствами, ни одного утверждения, с которым можно поспорить. Читатель дочитывает и не может сказать, что узнал.
Предварительный анализ больших объёмов данных
Модель хорошо справляется с качественными данными, которые тяжело обрабатывать руками. Несколько сотен отзывов, расшифровки звонков, открытые ответы в опросе, обращения в поддержку за квартал. Она найдёт повторяющиеся темы, разложит их по частоте, вытащит формулировки, которыми пользуются сами клиенты, покажет нетипичные случаи.
Дальше начинается зона, где нужен человек.
- Проверить арифметику, если модель считала сама, а не через расчётный инструмент.
- Понять, насколько выборка вообще отражает реальность, и не попали ли в неё только самые громкие голоса.
- Отличить корреляцию от причины, потому что модель охотно объяснит любое совпадение.
- Сопоставить выводы с тем, что известно о бизнесе из других источников.
- Решить, что делать с результатом, поскольку это уже управленческое решение.
Частая ловушка выглядит безобидно. Модель группирует жалобы и выдаёт вывод о том, что главная проблема в сроках доставки. Вывод верный для тех, кто жалуется, и ничего не говорит о большинстве, которое не писало вообще. Решение, принятое по такому анализу, перераспределяет ресурсы в пользу громкого меньшинства.
Код и скрипты для внутренних задач
Внутренние инструменты, разовые выгрузки, скрипты для обработки файлов, прототипы для проверки идеи. Здесь цена ошибки ограничена, а скорость разработки вырастает заметно. Это самая комфортная зона применения из всех существующих.
Ограничения всё равно есть, и они касаются доступа. Скрипт, который читает данные, безопаснее того, который их меняет. Прототип на тестовой копии безопаснее того же прототипа на рабочей базе. Инструмент, запускаемый вручную, безопаснее того, что работает по расписанию без присмотра.
Отдельно стоит сказать о понимании кода. Скрипт, который вы не можете прочитать, превращается в чёрный ящик внутри процесса, и через полгода его правка обойдётся дороже, чем написание с нуля. Если код остаётся в работе, его нужно либо понимать, либо осознанно считать одноразовым.

Перевод и адаптация формулировок
Качество машинного перевода общих текстов сейчас сопоставимо с работой неспециализированного переводчика, и для внутренней переписки, изучения документации или первичного понимания этого достаточно. Проблемы начинаются там, где перевод имеет последствия.
- Договоры и юридические документы, где значение имеет каждое определение.
- Техническая документация, где термин закреплён отраслевым стандартом.
- Медицинские и фармацевтические тексты.
- Маркетинговые материалы, где требуется адаптация к культурному контексту, а не перевод.
- Тексты, уходящие в публичное пространство под именем компании.
Типичная ошибка модели в переводе состоит не в грубом искажении, а в выборе почти верного слова. Смысл сдвигается на несколько процентов, текст звучит естественно, и заметить подмену может только человек, знающий предмет и оба языка.
Генерация идей, гипотез, вариантов решений
В этой задаче слабость модели оборачивается достоинством. Ей не нужно быть правой, нужно быть разнообразной. Тридцать вариантов за пять минут, среди которых два или три окажутся рабочими, это честный результат, недостижимый для человека в одиночку за то же время.
Чтобы перечень был полезным, запрос должен содержать ограничения. Бюджет, сроки, доступные каналы, особенности аудитории, то, что уже пробовали и что не сработало. Без этого модель выдаёт универсальный список, который подошёл бы любой компании и потому не подходит ни одной.
Хорошая генерация идей заканчивается не выбором лучшего варианта, а решением, какую из гипотез вы готовы проверить на небольшом бюджете в ближайшие две недели.
Проверку реализуемости модель не выполняет. Она не знает, что предложенный канал в вашей нише перегрет, что у команды нет нужной компетенции, что похожая механика уже запускалась год назад и не дала результата. Отбор остаётся человеческой работой, и именно он определяет, превратится ли список в план.
Как оценить задачу перед передачей ИИ
Списки запретов полезны, но они всегда отстают от реальности. Появляются новые инструменты, меняются режимы работы, возникают задачи, которых в списке нет. Поэтому ценнее не перечень, а способ оценки, который работает для любой незнакомой задачи за минуту размышления.
Схема, которую я использую в консультациях и внедряю в компаниях, построена на трёх вопросах. Они дают не запрет и не разрешение, а формат участия человека.
Три критерия: цена ошибки, проверяемость, ответственность
Первый критерий касается последствий. Нужно честно ответить, что произойдёт, если ответ окажется неверным, и сколько будет стоить исправление. Важна не вероятность ошибки, а именно её цена, потому что редкое событие с тяжёлыми последствиями опаснее частого и дешёвого.
Второй критерий касается возможности проверки. Здесь два подвопроса, и оба обязательны. Существует ли независимый источник, по которому ответ можно сверить, и есть ли у вас квалификация, чтобы эту сверку выполнить осмысленно. Если проверка требует эксперта, которого нет в процессе, задача фактически непроверяема, каким бы доступным ни выглядел источник.
Третий критерий касается ответственности. Нужно назвать конкретного человека, который отвечает за результат, и понять, достаточно ли у него информации, чтобы отвечать осознанно. Если на этот вопрос нет ответа, ответственность размазана по процессу, а значит её нет вовсе.
| Цена ошибки | Проверяемость | Формат работы |
|---|---|---|
| Низкая | Высокая | Свободное использование, выборочная проверка |
| Низкая | Низкая | Черновик, результат не используется как основание для решений |
| Высокая | Высокая | Черновик с обязательной полной сверкой специалистом |
| Высокая | Низкая | Задача не передаётся, допустима только подготовка материалов |
Самая опасная строка здесь последняя, и она же наиболее соблазнительная. Именно в задачах с высокой ценой ошибки и низкой проверяемостью модель даёт максимальную экономию времени, потому что сама работа тяжёлая. Ровно поэтому соблазн делегировать прямо пропорционален риску, и это стоит держать в голове как встроенную поправку на собственное суждение.
Чек-лист вопросов перед запросом
Три критерия определяют, можно ли передавать задачу. Чек-лист ниже определяет, получите ли вы пригодный результат. Он занимает не больше минуты и окупается на первом же сложном запросе.
- Какую именно задачу я решаю и как выглядит пригодный результат.
- Какие данные нужны для ответа и передал ли я их все в запросе.
- Есть ли в тексте запроса конфиденциальные сведения, которые нужно обезличить до отправки.
- Какие ограничения действуют в моей ситуации и назвал ли я их прямо.
- Привязан ли ответ к действующим нормам или ценам, то есть требуется ли свежесть данных.
- Как я буду проверять ответ и по какому источнику.
- Что я сделаю с результатом и кто подпишется под итоговым решением.
Два пункта в этом списке люди пропускают чаще остальных. Первый касается описания пригодного результата, без которого модель выдаёт среднее по жанру. Последний касается подписи под решением, и его пропуск объясняет большинство разборов инцидентов, которые мне приходилось проводить.
Качество ответа почти всегда ограничено не возможностями модели, а полнотой условий, которые человек потрудился сформулировать.
Ошибки при работе с ИИ и их последствия
Инциденты, которые я разбирал в компаниях, сводятся к пяти повторяющимся сценариям. Они не связаны с технической грамотностью и встречаются у опытных специалистов так же часто, как у новичков. Причина в том, что все пять ошибок не выглядят ошибками в момент совершения.
Принятие ответа без сверки с источником
Механика проста. Ответ правдоподобен, проверка требует усилий, сроки давят. Первые десять раз ответ оказывается верным, доверие растёт, проверка из процесса выпадает. На одиннадцатый раз ошибка уходит дальше по цепочке и обнаруживается, когда на ней уже стоят другие решения.
Последствия зависят от области, но структура одинаковая. Цифра из черновика попадает в презентацию для совета директоров, оттуда в бюджет, оттуда в договор с подрядчиком. Исправить на первом шаге стоило пять минут, на четвёртом требуется пересогласование всей цепочки.
Защита строится не на силе воли, а на порядке работы. Проверяемые утверждения помечаются в момент получения ответа, а не перед сдачей, и сверяются до того, как результат уйдёт кому то ещё.
Загрузка конфиденциальных данных в публичные сервисы
Эта ошибка почти всегда коллективная. Один сотрудник начинает пользоваться удобным инструментом, показывает коллегам, через три месяца через публичный сервис проходит половина рабочей переписки компании. Никто не принимал решения, процесс сложился сам.
Последствия делятся на две группы. Регуляторные касаются обработки персональных данных без законного основания и могут вскрыться при проверке или по жалобе. Коммерческие проявляются тише, потому что утечка сведений о себестоимости или условиях работы с поставщиками обычно не имеет видимого момента обнаружения.
Рабочее решение состоит из трёх элементов. Внутреннее правило о том, что передавать нельзя, обезличивание как привычка, и собственный контур для задач, где работа с реальными данными нужна постоянно.
Запрос без контекста и критериев результата
Короткий запрос даёт усреднённый ответ, и это воспринимается как слабость инструмента. Человек делает вывод, что модель бесполезна в его задачах, и отказывается от неё там, где она дала бы реальный выигрыш. Обратный вариант хуже. Усреднённый ответ принимают за решение и применяют к ситуации, для которой он не предназначен.
Разница в наполнении запроса видна сразу. Просьба предложить способы увеличить продажи даёт универсальный перечень. Та же просьба с указанием отрасли, среднего чека, цикла сделки, доступного бюджета, уже испробованных каналов и причин их неудачи даёт материал, с которым можно работать.
- Опишите исходную ситуацию, включая то, что уже пробовали.
- Назовите ограничения по деньгам, срокам, людям и инструментам.
- Укажите аудиторию или адресата результата.
- Задайте формат и объём ответа.
- Приведите пример того, что считаете хорошим результатом.
Использование ИИ как единственного эксперта
Этот сценарий развивается постепенно и потому редко замечается вовремя. Сначала модель заменяет поиск, потом консультацию с коллегой, потом обращение к специалисту. Экономия выглядит разумной, пока задачи остаются простыми.
Проблема в том, что вместе с расходами исчезает обратная связь. Коллега возразит, эксперт задаст неудобный вопрос, подрядчик скажет, что задача поставлена неверно. Модель достроит ответ на любой посылке, включая ошибочную, и человек остаётся в замкнутом круге собственных предположений, подкреплённых уверенным текстом.
Отдельный эффект касается квалификации. Специалист, который перестал разбираться сам, через год теряет способность оценивать ответы, которые получает. Инструмент из усилителя превращается в подпорку, и зависимость обнаруживается в момент, когда задача выходит за пределы привычного.
Делегирование финального решения вместо подготовки
Это обобщение всех предыдущих ошибок и единственная из них, которая сама по себе определяет исход. Все разобранные выше случаи сводятся к одному сдвигу. Инструмент, пригодный для подготовки, ставят в точку принятия решения.
Признаки такого сдвига заметны в формулировках, которыми описывают работу внутри команды.
- Так посчитала система, вместо объяснения, откуда взялась цифра.
- Текст уже готов, осталось отправить, без чтения специалистом по теме.
- Модель подтвердила, что ошибок нет, как основание не проверять.
- Мы делаем так, потому что это рекомендованный вариант, без разбора почему.
- Никто не знает, как именно работает этот скрипт, но он работает.
Любая из этих фраз в рабочем разговоре означает, что ответственность выпала из процесса. Исправляется это не запретом инструмента, а возвращением решения человеку с явно названным именем.
Правила безопасного делегирования
Всё изложенное выше сводится к небольшому набору правил, которые можно внедрить в работу за одну неделю. Они не требуют ни новых инструментов, ни изменения структуры команды.
Что проверять в ответе обязательно
Проверка не означает перечитывание всего. Она означает выборочную сверку тех элементов, где ошибки концентрируются. Этот перечень устойчив и почти не зависит от области.
- Все числа, включая проценты, суммы, сроки и единицы измерения.
- Ссылки на нормативные документы, с проверкой действующей редакции и даты.
- Цитаты, имена, названия организаций и сведения об источниках.
- Арифметику в расчётах, выполненную заново хотя бы по одной строке.
- Логическую связь между данными и выводом, потому что вывод может не следовать из приведённого.
- Полноту, то есть отсутствие важного условия, о котором не спросили.
- Соответствие ответа вашей конкретной ситуации, а не усреднённой.
Последний пункт самый трудный, потому что требует знания предмета. Именно он объясняет, почему проверка работает только тогда, когда её выполняет человек с квалификацией в этой области.
Распределение ролей: ИИ готовит, человек решает
Устойчивая схема работы выглядит одинаково в любой задаче, независимо от отрасли. Модель берёт на себя объём и скорость, человек берёт на себя смысл и последствия.
- Постановку задачи и определение пригодного результата формулирует человек.
- Сбор, группировку, черновую структуру и варианты формулировок готовит модель.
- Проверку фактов, расчётов и соответствия ситуации выполняет специалист.
- Решение принимает и подписывает человек, который отвечает за последствия.
- Разбор результата и корректировку процесса делает команда, а не инструмент.
В компаниях, где эта схема закреплена письменно, инциденты практически исчезают, а выигрыш во времени сохраняется. Там, где она держится на здравом смысле отдельных сотрудников, она размывается в первый же авральный период, потому что под давлением сроков проверка отпадает первой.
Поэтому разумный минимум для организации состоит из трёх документов на одну страницу каждый. Перечень задач, которые не передаются модели. Правило об обезличивании данных перед отправкой. Обязательная подпись человека под результатом, который выходит за пределы черновика.

Технология не снимает с нас ответственность за решения, она лишь повышает скорость, с которой мы их принимаем. Значит, единственное, что стоит делегировать без сомнений, это работа, а не выбор.