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