Свободный специалист: Как зарабатывать больше с ИИ и не выгорать

Внешний ИИ-сервис нужно оценивать не по рекламному обещанию, а по условиям обработки данных. Как минимум следует проверить срок хранения, использование данных для улучшения сервиса, доступ сотрудников провайдера, возможность отключить сохранение истории, место хранения и порядок удаления. Если эти условия непонятны, исходные чувствительные материалы туда не отправляют.

Конфиденциальность начинается до загрузки

В рабочем проекте полезно разделить данные на три уровня.

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

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

Третий уровень — ограниченные сведения. К нему относятся персональные данные, сведения о здоровье, паспортные данные, реквизиты банковских карт, пароли, ключи доступа, токены, адреса, необезличенные CRM-выгрузки, коммерчески критичные условия и материалы, переданные под специальным режимом защиты. Их нельзя загружать в обычный внешний инструмент только потому, что это быстрее.

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

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

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

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

Безопасная подготовка выдержки проходит в несколько этапов.

1. Сначала определяется цель. Если нужно написать текст о типовых обращениях, имя, телефон и номер заказа не нужны.

2. Затем удаляются прямые идентификаторы: ФИО, телефон, электронная почта, точный адрес, паспортные данные, реквизиты, логины и ссылки на персональные кабинеты.

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

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

5. Проверяется постоянство замен. Если один и тот же клиент встречается в нескольких строках, внутри обезличенного набора ему присваивается один код. Этот код не должен совпадать с настоящим номером договора или заказа.

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

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

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

Возвращение к проекту

После первой ошибки материалы не стали загружать в ИИ повторно целиком. Сначала исходники получили коды и статусы. Актуальный документ с условиями услуги обозначили как С17-И05, отчёт по обращениям — как С17-И07. Старое предложение отправили в архив и оставили доступным только как источник стиля, а не как источник фактов. Выгрузку обращений сохранили в оригинальной папке и не передавали в ИИ. Для анализа создали отдельную обезличенную выборку с категориями обращений, периодами, укрупнёнными регионами и результатами обработки. Ей присвоили код С17-И09.

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

В банк решений добавили структуру предложения:

1. Описать проблему клиента без внутренней терминологии.

2. Показать результат, который входит в услугу.

3. Указать способ работы.

4. Назвать ограничения и условия.

5. Привести подтверждение из разрешённого источника.

6. Завершить следующим шагом, который клиент действительно может выполнить.

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

Затем подготовили задачу для ИИ на ограниченном наборе данных. В ней были не только цель и формат, но и правила поведения при нехватке информации:

Используй только материалы с кодами С17-И05, С17-И07 и С17-И09.

Не переноси сведения из архивных документов в раздел фактов.

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

Для каждого фактического утверждения укажи код источника.

Если подтверждения нет, пометь фрагмент как «предложение для проверки».

Если источники противоречат друг другу, вынеси противоречие отдельным списком.

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

Если клиент требует загрузить исходник

Иногда клиент передаёт необезличенный файл и ожидает немедленной обработки. В такой ситуации есть три пути.

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

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

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

Срочность меняет объём результата, но не правила доступа.

Если документы противоречат друг другу

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

Для каждого спорного пункта фиксируются:

1. Формулировка из первого источника.

2. Формулировка из второго источника.

3. Даты и авторы документов.

4. Статус каждого материала.

5. Лицо или роль, которые последними утвердили условие.

6. Решение: использовать, исключить или запросить подтверждение.

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

Если срок истекает, а данных мало

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

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

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

Факт, гипотеза и авторское решение

Контроль качества начинается с разделения разных типов высказываний. Для этого каждому фрагменту присваивается одна из четырёх меток.

Подтверждённый факт — утверждение, которое прямо следует из разрешённого источника. У него есть ссылка, дата и понятный контекст.

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

Предложение для проверки — готовая формулировка или идея, которую можно показать клиенту как вариант, но нельзя выдавать за установленное обстоятельство.

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

Эти метки можно использовать прямо в рабочем документе:

ФАКТ: Срок указан в действующей редакции условий.

ГИПОТЕЗА: Основная причина отказа может быть связана с длительным ожиданием ответа.

ПРОВЕРИТЬ: Уточнить, распространяется ли срок на удалённые регионы.

РЕШЕНИЕ АВТОРА: Вынести условия обслуживания после описания результата.

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