Доверяй, но проверяй: Как распознавать убедительные ошибки ИИ

В понедельник в 9:17 Ирина Соколова открыла рабочий чат и написала:

«Проверь материалы по поставщику и подготовь краткую справку: можно ли заключать договор и какие есть риски».

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

Через несколько секунд Ирина получила аккуратный текст:

«Поставщик выглядит приемлемым для сотрудничества. Существенных препятствий для заключения договора не выявлено. Перед подписанием рекомендуется проверить актуальность регистрационных данных, полномочия подписанта, условия поставки и ответственность за просрочку».

Текст был коротким, деловым и напоминал результат работы специалиста. Ирина уже собиралась переслать его директору, когда юрист Дмитрий Орлов спросил:

«На какую дату вы проверяли актуальность регистрационных данных?»

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

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

Один запрос, несколько версий реальности

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

Запуск первый

«Проверь материалы по поставщику и подготовь краткую справку: можно ли заключать договор и какие есть риски».

Ответ снова оказался гладким:

«Поставщик имеет приемлемый профиль и может рассматриваться как контрагент. Основные риски связаны с соблюдением сроков, качеством продукции и условиями ответственности. Рекомендуется перейти к согласованию договора после дополнительной проверки».

За этими фразами скрыто сразу несколько решений, принятых за пользователя.

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

В ответе нет ни одного явно указанного источника. Зато есть язык, имитирующий завершённую экспертную работу.

Запуск второй: дата и регион

Ирина добавила:

«Оцени ситуацию по состоянию на 12 марта 2025 года. Применяй российский правовой и деловой контекст. Поставщик работает с нашей компанией в Московской области».

Ответ стал конкретнее:

«По состоянию на 12 марта 2025 года поставщик может быть допущен к дальнейшему согласованию договора. Для российской коммерческой закупки целесообразно дополнительно проверить сведения о юридическом лице, полномочия подписанта, условия поставки и ответственность сторон».

Дата и регион действительно сузили задачу. Теперь понятно, что нельзя автоматически переносить правила другой страны или другой правовой системы. Но появление даты в запросе не означает, что ИИ получил свежие сведения. Дата задаёт временной срез, а не создаёт источник.

Если в приложенной выписке нет сведений на 12 марта, система не может честно утверждать, что знает статус поставщика на эту дату. Она может сказать: «В доступном документе указана дата 20 февраля; актуальность на 12 марта не подтверждена». Если вместо этого появляется фраза «по состоянию на 12 марта поставщик действует», нужно спросить: откуда взялся этот факт?

Контрольный вопрос остаётся прежним: какой факт модель сейчас знает, а какой только предполагает?

Запуск третий: отрасль и предмет закупки

Следующая версия запроса звучала так:

«Оцени поставщика по состоянию на 12 марта 2025 года в российском контексте. Мы — производственная компания в Московской области. Закупаем комплектующие для промышленной линии. От поставки зависит непрерывность производства. Нужна оценка рисков перед заключением коммерческого договора».

Форма ответа изменилась заметнее:

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

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

Однако отраслевой контекст не подтверждает ни производственные мощности, ни способность выполнить заказ. Он лишь помогает понять, какие вопросы нужно поставить. Если в ответе появится утверждение «у поставщика есть достаточный запас комплектующих» без подтверждающего документа, это будет уже не полезное уточнение, а додуманная деталь.

Запуск четвёртый: версия документа

Теперь Ирина явно зафиксировала документы:

«Используй только следующие материалы: выписку из ЕГРЮЛ от 10 марта 2025 года, проект договора версии 3 от 11 марта 2025 года, спецификацию комплектующих от 11 марта 2025 года и внутренний регламент закупок версии 5 от 1 февраля 2025 года. Старые проекты договора и письма не используй. Если нужного факта в этих материалах нет, укажи, что он неизвестен».

Ответ стал более дисциплинированным:

«По выписке из ЕГРЮЛ от 10 марта 2025 года можно проверить сведения, содержащиеся в этом документе. По проекту договора версии 3 можно оценить указанные в нём сроки, порядок оплаты, гарантии и ответственность. Способность поставщика обеспечить объём поставки, наличие резервных мощностей и фактическая готовность продукции этими материалами не подтверждены».

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

Три роли Ирины

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

Руководитель

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

ИИ, скорее всего, построит ответ вокруг решения:

«Переход к подписанию возможен после выполнения двух условий: подтверждения полномочий подписанта и согласования ответственности за просрочку поставки. Критическим остаётся риск зависимости от одного поставщика».

По форме такой ответ подходит руководителю: он быстро показывает, что делать дальше. Но краткость может скрыть основание вывода. Почему именно эти два условия названы ключевыми? Кто определил, что риск зависимости от одного поставщика критический? Есть ли альтернативный поставщик? Содержит ли договор неустойку, достаточную для компании? Если эти факты не были переданы, ответ лишь упорядочивает предположения.

Закупщик

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

Теперь ответ будет операционным:

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

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

Аналитик

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

Ответ может выглядеть так:

«Риск задержки поставки: подтверждённые данные отсутствуют; в договоре указан срок 30 календарных дней; фактическая производственная мощность не представлена; количественная оценка вероятности невозможна. Для расчёта нужны сведения о прошлых поставках, мощности и резервном запасе».

Если убрать последнюю фразу о запрете процентов, ИИ может написать: «Вероятность задержки оценивается в 20–30 процентов». Внешне это будет выглядеть аналитично, но число не возникнет из воздуха только потому, что запрос составлен от имени аналитика.

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

Если после смены роли меняется регистрационный статус поставщика, дата документа или факт наличия судебного спора, а новые источники не появились, один из ответов ошибочен либо оба не имеют достаточного основания.

Что считать отсутствующим, а что — додуманным

Эти две категории легко смешать.

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

Додуманный факт — это утверждение, которое появляется в ответе, хотя в доступных данных его нет. Например: «Договор будет подписан генеральным директором», «у поставщика есть резервный склад», «проверка реестра проведена 12 марта». Последняя формулировка особенно опасна: она не просто сообщает содержание, а утверждает, что некое действие было выполнено.

Полезно разделять четыре слоя.

Первый слой — факт из указанного источника. Например: «В проекте договора версии 3 срок поставки указан как 30 календарных дней». Такой факт можно проверить по документу.

Второй слой — вывод из фактов. Например: «Условие о сроке поставки следует дополнительно согласовать, поскольку в спецификации нет даты первой отгрузки». Вывод может быть разумным, но это уже не цитата из документа.

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

Четвёртый слой — неизвестное. Например: «Фактическая мощность поставщика по выпуску комплектующих не подтверждена». Такой ответ может казаться менее впечатляющим, зато он защищает от ложной определённости.

Сигналы достроенного контекста

Сигнал первый: в ответе появилась точная дата, которой не было в запросе.

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

Фраза «на текущую дату» тоже недостаточна. Нужно назвать конкретный день и правило: использовать только сведения, действительные на эту дату, или учитывать документы, полученные не позднее неё.

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

Такие выражения маскируют временную неопределённость. У внутреннего регламента может быть версия 4, 5 или 6; у договора — несколько проектов; у правового документа — редакция на другую дату.

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

Сигнал третий: ответ сообщает о проверке, которой никто не поручал и не видел.

«Проверка ЕГРЮЛ показала», «анализ судебной практики выявил», «ссылка подтверждена», «данные сверены» — это заявления о выполненном действии. Если у сервиса не было разрешённого доступа к источнику и в ответе нет проверяемой ссылки или цитаты, такие заявления нужно считать неподтверждёнными.

Попросите указать источник, дату обращения к нему и конкретный фрагмент, на котором основан вывод. Если источник не предъявлен, замените «проверено» на «рекомендуется проверить».

Сигнал четвёртый: точное число появляется без расчёта.

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

Попросите перечислить входные данные, формулу, допущения и диапазон неопределённости. Если данных нет, используйте качественное описание или условную модель: «Если средний срок поставки составляет X, а запас — Y, то...».

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

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

Общий вывод лучше заменить условным: «Можно переходить к согласованию, если подтверждены полномочия подписанта и срок первой поставки». Или: «Подписывать нельзя до получения документа X». Граница решения должна быть наблюдаемой.

Сигнал шестой: при смене роли меняется не только структура ответа, но и набор фактов.

Если руководителю сообщают, что поставщик уже работал с компанией, а аналитику — что это новый контрагент, роль не объясняет расхождение. Нужно сравнить три версии и выделить утверждения, которые появились без новых данных.

Сигнал седьмой: ответ заполняет все поля и не оставляет неизвестного.

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

Контекст компании: что передавать, а что удержать

У Ирины была ещё одна причина торопиться. В приложенных материалах находились фамилии сотрудников, телефоны, банковские реквизиты, коммерческие условия и переписка с поставщиком. Для анализа контекста ей действительно нужно было описать предмет закупки, сроки, регион и критерии риска. Но для этого не требовались все исходные документы целиком.

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

Туда же можно добавить дату и версию документа, обобщённые сроки, объёмы и диапазоны сумм, если точные значения не нужны, фрагменты договора без лишних идентификаторов и перечень вопросов, которые требуется проверить.

Без разрешённого корпоративного сценария нельзя отправлять во внешний сервис паспортные данные, номера телефонов, адреса, электронную почту и другие персональные данные сотрудников или клиентов.

Не следует передавать сведения о здоровье, зарплате, дисциплинарных обстоятельствах и семейном положении, банковские реквизиты, пароли, ключи доступа, коды подтверждения и токены.

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

Договоры целиком тоже не стоит передавать, если в них есть персональные данные или условия, которые нельзя выносить за пределы разрешённого контура.

Требования российского законодательства о персональных данных, включая ФЗ-152, не отменяются тем, что данные отправляются в диалог с ИИ. Нужны законное основание обработки, понятная цель, контроль доступа и соблюдение внутренних правил компании. Если компания не утвердила конкретный сервис и порядок работы с ним, безопаснее не загружать туда исходный документ.

Обезличивание нельзя сводить к механической замене фамилии на слово «сотрудник». Сочетание должности, редкой даты, суммы и названия проекта иногда позволяет восстановить личность. Поэтому сначала нужно решить, действительно ли идентификатор нужен для задачи. Если нет, его следует удалить, а не только замаскировать.

Та же комната в других задачах

Тот же механизм проявляется далеко не только в закупках.

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

Для короткого текста достаточно написать: «Составь нейтральное сообщение классному руководителю о том, что ученик не будет на занятиях 18 марта по причине, которую я не хочу раскрывать. Не добавляй объяснений от себя».

В работе с клиентом запрос часто выглядит так: «Подготовь ответ, почему заказ задерживается». Если в данных нет подтверждённой причины, ИИ может назвать логистический сбой, нехватку сырья или задержку на складе. Ни одну из этих причин нельзя отправлять заказчику как факт без внутреннего подтверждения.

Безопаснее сформулировать задачу так: «Причина задержки пока уточняется. Подготовь письмо без предположений и укажи, что точный срок будет сообщён до 16:00 20 марта». Здесь граница задачи прямо запрещает системе заполнять неизвестное.

Контекстный паспорт запроса

Чтобы не вспоминать все условия в последний момент, Ирина ввела для себя контекстный паспорт. Это короткая карточка, которая сопровождает задачу до самого запуска ИИ.

Цель. Какое решение или действие должен поддержать ответ? Не «проанализировать поставщика», а «понять, можно ли передавать договор на юридическое согласование».

Дата актуальности. На какую дату должны быть действительны сведения? Какие документы можно использовать, если они старше этой даты?

Регион и правовой режим. В какой стране и регионе работает компания? Это коммерческая закупка, внутренняя процедура или регулируемая закупка? Если применимы специальные требования, их нужно назвать.

Отрасль и объект. Что закупается и чем опасен сбой? Комплектующая для промышленной линии и офисные принадлежности требуют разных критериев проверки.

Версия документов. Какие файлы являются основными? Каковы их даты и редакции? Какие материалы нужно игнорировать?

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

Разрешённые данные. Какие сведения можно передавать в сервис? Какие документы уже приложены? Какие данные обезличены?

Запрещённые данные. Что нельзя использовать даже при наличии в исходных файлах?

Формат результата. Нужна одна страница, карта рисков, список вопросов, проект письма или расчёт с формулой?

Критерий остановки. В какой момент ИИ обязан прекратить вывод и сообщить о нехватке данных? Например, если нет актуальной выписки, непонятна версия договора, отсутствует срок первой поставки или неизвестен полномочный подписант.

Последний пункт защищает лучше всего. Он превращает неизвестность из помехи в правило поведения.

Алгоритм перед запуском

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

Затем зафиксируйте дату, регион и правовой режим. Если они неизвестны, попросите ИИ не выбирать их самостоятельно, а задать уточняющий вопрос.

После этого назовите отрасль, объект и цену ошибки. Это помогает определить, какие риски важны, но не создаёт отсутствующих доказательств.

Дальше перечислите источники и версии. Отделите документы, которые можно цитировать, от сведений, которые нужно только проверить.

Затем укажите адресата и формат. Если нужен вывод для директора, это не повод скрывать основания. В хорошем кратком отчёте должны остаться хотя бы источники, неизвестные параметры и условия решения.

В конце установите правило остановки: «Если факт отсутствует в перечисленных материалах, пометь его как неизвестный. Не подставляй дату, значение, источник или причину. Если отсутствует любой из критических параметров, сначала задай уточняющие вопросы и не давай итоговой рекомендации».

Переписывание запроса Ирины

После эксперимента Ирина заменила исходную фразу контекстным контрактом. Ниже — его рабочая версия.

«Задача: подготовить для директора краткую справку о том, можно ли передавать на юридическое согласование договор с поставщиком комплектующих.

Дата актуальности: 12 марта 2025 года. Используй только сведения, действительные на эту дату или содержащиеся в перечисленных документах.

Регион и режим: Российская Федерация, Московская область, коммерческая закупка производственной компании, не являющаяся государственной закупкой. Предмет: комплектующие для промышленной линии; задержка первой поставки может привести к остановке производства.

Источники: выписка из ЕГРЮЛ от 10 марта 2025 года, проект договора версии 3 от 11 марта 2025 года, спецификация от 11 марта 2025 года, внутренний регламент закупок версии 5 от 1 февраля 2025 года. Старые проекты договора и письма не используй. Не утверждай, что проверял реестр, судебные дела, ссылки или производственные мощности, если результаты такой проверки не представлены в источниках.

Для каждого существенного утверждения укажи источник. Раздели результат на четыре части: подтверждённые факты; выводы; неизвестные параметры; действия до юридического согласования. Не используй проценты и числовые оценки риска без исходных данных и описания расчёта.

Разрешённые данные: обезличенные сведения о поставщике, даты и версии документов, условия поставки, сроки, объёмы и положения проекта договора, необходимые для анализа. Не используй персональные данные сотрудников, телефоны, электронные адреса, банковские реквизиты, пароли, непубличные клиентские данные и сведения, передача которых не разрешена внутренними правилами.

Если в материалах нет актуальной информации о полномочиях подписанта, сроке первой поставки, порядке замены брака или ответственности за простой, укажи эти параметры как неизвестные. Не отвечай “можно подписывать” или “нельзя подписывать”, пока не отделишь юридические замечания от операционных рисков. Если обнаружишь противоречие между версиями документов, остановись и вынеси его в отдельный блок для проверки юристом».

Этот запрос не делает ИИ экспертом и не заменяет проверку ЕГРЮЛ, договора или производственных возможностей. Он делает другое: уменьшает число решений, которые система принимает молча. Теперь она не должна самостоятельно выбирать дату, считать старый документ действующим, объявлять проверку выполненной или превращать общий риск в точный процент.