150 компаний внедряли ИИ — и все спотыкались на одних и тех же пяти ошибках

Консультант Dylan Davis провёл больше 150 сессий по внедрению ИИ — с private equity фондами, юридическими фирмами, компаниями из HVAC-сектора и десятком других индустрий. Инструмент каждый раз разный: ChatGPT, Gemini, Claude. А вот ошибки при использовании ИИ — одни и те же, независимо от размера компании и выбранной модели. Это не проблема промптов, а системные пробелы в том, как люди настраивают и доверяют ИИ.

Дело не в промпте, а в настройках

Самая частая история: сотрудники жалуются, что ИИ плохо справляется с задачей — например, вытаскивает данные из счетов с ошибками — и списывают это на «глупость» модели. При этом почти никто не смотрит на выбор модели и на reasoning effort — уровень «усилия», с которым модель рассуждает. Для тяжёлых задач по извлечению данных нужна старшая модель с высоким эффортом (условно GPT-5.6 extra high или Opus 5 с high effort), а не дефолтная лёгкая конфигурация. Первый шаг к нормальному результату — не переписывать промпт десять раз, а проверить, тот ли «размер мозга» и ту ли степень усилия вы включили.

ИИ не звучит как вы — потому что вы его этому не учили

Вторая типичная жалоба — «ИИ пишет как ИИ», слишком гладко и безлично, особенно когда модель разбирает почту и готовит ответы. Проблема решается не капризным редактированием стиля в промпте, а тем, что можно назвать литературным отпечатком: даёте модели доступ к своей почте через коннектор, просите проанализировать последние 300–400 отправленных писем, выделить категории обращений и для каждой — тон, длину, характерные обороты. Дальше этот профиль зашивается в skill, и модель начинает писать не «как ИИ вообще», а как конкретный человек в конкретном типе переписки.

Context rot: больше контекста — не значит лучше

Третья ошибка встречается у самых дисциплинированных пользователей — тех, кто загружает модели 500–800 файлов «на всякий случай», чтобы у неё точно был весь контекст. Работает это в обратную сторону: у модели есть ограниченный объём рабочего пространства, и чем плотнее оно забито данными, тем меньше остаётся места на рассуждение над самой задачей. Как только заполнение переваливает за 50–60% доступного контекста, качество ответов заметно проседает — это называют context rot. Правильный ориентир — не «максимум контекста», а «минимально достаточный контекст»: часто это 10–20 релевантных страниц, а не сотни файлов.

Почему цифрам от ИИ нельзя доверять по умолчанию

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

Когда не нужно приложение — хватит skill

Последняя ошибка — разрешать ИИ строить полноценные приложения и дашборды там, где хватило бы skill или project. Модели любят предлагать красивые прототипы, и заказчики радуются результату — пока не понимают, что это невозможно просто передать коллегам: нужен хостинг, поддержка кода, работа с деплоем. Получается избыточно сложное решение там, где задачу закрыл бы skill в Claude или project в ChatGPT — то, что работает из коробки и легко расшаривается на всю команду.

Вывод

Ни одна из этих пяти ошибок не связана с качеством конкретной модели — все они воспроизводятся и в ChatGPT, и в Gemini, и в Claude. Это ошибки процесса: неправильные настройки, отсутствие обучения стилю, избыточный контекст, слепое доверие и склонность превращать простую задачу в инженерный проект. Для тех, кто работает с Claude Code и строит на нём рабочие процессы, это по сути чек-лист: проверить effort модели перед тем, как жаловаться на неё, зафиксировать стиль через skill, держать контекст компактным и требовать источники там, где на кону цифры.