Марина Погодина | PROMAREN: ИИ для бизнеса

🔎 Грамотный текст от ИИ может продавать хуже черновика с пометками

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

Потом читатель доходит до конца и ничего не делает.

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

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

В апреле 2026 года OpenAI выпустила отдельный материал о работе с текстами в ChatGPT. Там задачу разделили на черновик, редактирование и доработку под конкретный формат. Источник: OpenAI Academy.

Это важное разделение ролей. Когда модели дают команду "сделай продающий текст", она начинает достраивать уверенность знакомыми словами про решения, возможности и преимущества. Формально придраться трудно. Смысл при этом часто уезжает в туман.

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

Сначала можно собрать черновик самому или с помощью модели. Затем отдать этот же текст на отдельную вычитку.

Промпт вычитки:

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

Проверь текст ниже и перепиши его так, чтобы он был понятным, конкретным и вел к действию.

Убери канцелярит, общие эпитеты, повторы, штампы и фразы без проверяемого смысла.

Найди места, где текст звучит как пресс-релиз. Замени их конкретикой: что происходит, сколько времени или денег теряется, какой результат получает клиент.

Не придумывай факты, цифры, кейсы и гарантии. Если данных не хватает, пометь это в квадратных скобках: [нужна цифра], [нужен пример], [нужно доказательство].

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

В конце дай:
1. готовую версию текста;
2. список из 3-5 слабых мест исходника;
3. один вариант более сильного заголовка.

Текст для вычитки:
[вставьте текст]

Самая полезная строчка здесь про пометки в квадратных скобках. Она не дает модели закрыть дыру в исходнике гладкой формулировкой. Нет цифры экономии, срока запуска или доказательства результата? Пусть в тексте останется [нужна цифра].

Это честнее, чем убедительная легенда, которую потом придется объяснять клиенту.

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

Перед публикацией я бы проверила текст по четырем вопросам:

• Понятно ли, для кого это написано?

• Есть ли конкретная проблема?

• Можно ли убрать часть прилагательных без потери смысла?

• Есть ли доказательство каждого сильного обещания?

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

Какие фразы из текстов нейросети вы вычеркиваете первыми?

🔎 DeepSeek API подключается за час. Утечка начинается с одного поля в запросе.

В феврале 2026 года DeepSeek обновил политику конфиденциальности: сервис получает введенные пользователем данные, а обработка и хранение могут происходить в КНР. Когда сотрудник отправляет запрос модели, данные уже уходят внешнему поставщику.

Обычно риск появляется под видом срочной задачи: быстро собрать помощника, сделать сводку, подключить бота к CRM. Потом прототип начинает работать с реальными заявками, письмами и документами. Вопрос "какие поля он видит?" возникает позже. Иногда его задает юрист, открыв журнал запросов.

Быстрый эксперимент превращается в рабочий сервис гораздо быстрее, чем появляется порядок в доступах.

У DeepSeek есть Responses API со статусом stateless: история диалога не хранится на сервере, приложение передает контекст заново для каждого запроса. Это помогает контролировать историю переписки, однако содержимое каждого нового запроса все равно обрабатывается сервисом.

Надпись stateless не делает персональные данные декоративными.

Граница безопасности проходит до API: решите заранее, какие сведения вообще могут покинуть ваш контур.

Что проверить перед подключением DeepSeek API

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

2. Разделите данные на корзины: открытые тексты, технические обезличенные данные, подготовленные фрагменты документов. ФИО, телефоны, адреса, номера договоров, учетные записи, платежные реквизиты, коммерческие условия и внутренние пароли должны останавливаться раньше модели.

3. Маскируйте значения до отправки: "КЛИЕНТ_17", "ДОГОВОР_42", "СУММА_Х". Расшифровка остается в вашей системе. Модели обычно достаточно смысла текста.

4. Держите ключ API на своем сервере, в переменных окружения или хранилище секретов. Интерфейс обращается к вашему серверу, сервер вызывает DeepSeek. Иначе ключ однажды окажется в коде, логах или чужих руках.

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

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

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

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

Политику обработки данных лучше прочитать до запуска. После запуска она иногда читается в компании с юристом и выгрузкой клиентской базы в логах: политика конфиденциальности DeepSeek обновлена 10 февраля 2026 года.

Технические детали stateless-режима есть в документации Responses API. Требование не передавать приватные данные в user_id опубликовано в разделе про изоляцию кеша.

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

Где у вас проходит граница между полезным контекстом для ИИ и данными, которые из системы выпускать нельзя?

💎 Покупка ИИ не исправит процесс, который никто не может объяснить

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

Выглядит технологично. Работает примерно как дорогой шкаф, в который сложили прежний бардак.

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

Пока эта работа живет в голове и переписках, ее принято считать "обычной операционкой". Хотя именно там чаще всего лежат первые деньги и запас времени.

В отчете Microsoft за 2025 год 53% руководителей назвали рост производительности необходимостью, а 46% сообщили, что используют агентов для полной автоматизации отдельных процессов. Исследование охватило 31 тысячу работников в 31 стране.

Рынок явно не ждет идеального момента. Но цифры Microsoft не подскажут, какой процесс первым спасать именно у вас.

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

Сбор статусов: кто что сделал, где зависла заявка, кому нужен ответ.

Перенос данных: заявка из формы уходит в таблицу, затем в систему работы с клиентами, потом в отчет.

Напоминания: счет не оплачен, документ не подписан, клиент не ответил.

Регулярная отчетность: одни и те же цифры каждую неделю собирают, сверяют и отправляют руководителю.

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

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

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

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

Процесс | Сколько раз в неделю | Минут на один раз | Сколько людей участвует | Цена ошибки | Можно ли описать правила

Сбор отчета по продажам | 5 | 90 | 2 | высокая | да

Напоминание об оплате | 40 | 3 | 1 | средняя | да

Ответ на нестандартный запрос | 15 | 20 | 2 | высокая | пока нет

Дальше считается грубо: частота × минуты × число людей. Первый процесс забирает 900 минут в неделю, то есть 15 часов. Напоминание об оплате выглядит мелочью, пока за месяц не превращается в восемь часов внимания сотрудника.

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

Всемирный экономический форум в отчете 2025 года пишет, что 73% работодателей планируют ускорять автоматизацию процессов и задач. Главный тормоз там же назван прямо: дефицит навыков.

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

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

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

Уведомление в Роскомнадзор часто заполняют последним. Зря.

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

А уведомление в Роскомнадзор вспоминают, когда его требуют контрагент, банк или письмо из ведомства. Бюрократия умеет приходить ровно тогда, когда у вас запуск и квартальный отчет.

Статья 22 закона N 152-ФЗ требует направить уведомление до начала обработки, кроме ограниченных исключений. Роскомнадзор вносит сведения в реестр в течение 30 дней после получения уведомления.

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

Что собрать до открытия формы на Портале персональных данных Роскомнадзора:

• все цели обработки: кадры, договоры, заявки с сайта, рассылки, пропускной режим;

• категории людей: сотрудники, кандидаты, клиенты, представители контрагентов, посетители сайта;

• состав данных по каждой цели: ФИО, телефон, почта, паспортные данные, сведения о доходах и так далее;

• системы и подрядчиков, через которые данные проходят или хранятся;

• адреса баз данных с данными граждан России, сроки обработки и условия прекращения.

Самая частая ошибка здесь простая: взять шаблон из интернета и поставить в каждой строке "обработка персональных данных". Формально строка есть. По существу она ничего не объясняет.

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

Дальше заполняйте форму на Портале персональных данных Роскомнадзора по фактической схеме работы. Особое внимание трем полям.

— Место нахождения базы данных. После изменений, вступивших 1 июля 2025 года, закон отдельно запрещает при сборе данных граждан России записывать, систематизировать, накапливать, хранить, уточнять и извлекать их через базы за пределами России, кроме установленных законом случаев. Источник: Федеральный закон N 23-ФЗ и статья 18 закона N 152-ФЗ.

— Трансграничная передача. Зарубежный сервис аналитики, рассылок, поддержки или облачное хранилище могут менять ответ в этой части. О передаче данных за рубеж Роскомнадзор уведомляют отдельно и до начала передачи: статья 12 152-ФЗ, с 1 марта 2023 года. "Мы просто подключили сервис" обычно не считается описанием маршрута данных.

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

После подачи сохраните номер и копию. Затем внесите уведомление в календарь комплаенса: при изменении целей, систем, адреса базы, состава данных или иных заявленных сведений обновление нужно направить не позднее 15-го числа следующего месяца. При прекращении обработки срок короче: 10 рабочих дней. Источник: актуальная редакция статьи 22 закона N 152-ФЗ.

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

У вас уведомление отражает реальную работу компании или когда-то было заполнено "чтобы отстали"?

Контент-план ломается во вторник, хотя собирали его в пятницу

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

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

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

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

За 15 минут соберите четыре списка:

1. Что бизнес продает в этом месяце: услуга, продукт, консультация, запуск, набор заявок.

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

3. Какие факты у вас есть: кейсы, цифры, ошибки, наблюдения, решения, которые пришлось переделывать.

4. Что меняется у аудитории: сезон, отчетный период, новые требования, типовые сбои, бюджеты.

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

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

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

— Диагноз: назвать проблему так, чтобы руководитель узнал свою ситуацию.

— Доказательство: показать кейс, цифру, механизм или наблюдение из практики.

— Практика: дать читателю проверку, вопрос или действие на сегодня.

— Предложение: объяснить, какую задачу вы берете и какой результат собираете.

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

Равномерность хороша для плитки в ванной. В контенте она часто прикрывает отсутствие решения.

Таблица должна отвечать на вопросы, которые обычно возникают в день публикации. Я бы оставила семь колонок:

Дата | Задача поста | Сегмент | Тема-крючок | Доказательство | Действие читателя | Статус

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

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

Потом выделите 20 минут и пройдите по плану сверху вниз:

— Есть ли темы для людей, которые пока не видят проблему?

— Есть ли посты для тех, кто сравнивает варианты и боится ошибиться?

— Есть ли доказательства, что вы умеете делать работу, о которой пишете?

— Понятно ли, какой следующий шаг нужен читателю после каждой публикации?

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

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

Как у вас сейчас устроен контент-план: от задач бизнеса или от вопроса "о чем бы сегодня написать"?

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

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

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

Вот как я бы раскладывала рынок по назначению, если бы выбирала сервис под конкретную задачу бизнеса:

Генеративное видео по описанию — Runway Gen-4.5 и Kling: короткие ролики пять-десять секунд, сильны в атмосфере и движении камеры, слабы в руках и тексте на экране.

Аватар-презентация с озвучкой — HeyGen и Synthesia: говорящая голова читает ваш сценарий на нужном языке, подходит для обучающих роликов и презентаций продукта.

Монтаж и оживление фото — Pika и Luma Dream Machine: превращают статичное изображение в короткое движение, дешево для соцсетей, не годится для длинного контента.

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

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

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

Идеальное решение для любого видео не существует, и это, пожалуй, единственный универсальный вывод из этого сравнения. Для обучающего курса и говорящей головы берите HeyGen, для атмосферного ролика в соцсети — Runway или Kling, для быстрого оживления фотоконтента — Pika. Смешивать эти задачи в одном инструменте означает переплачивать за функции, которые вы никогда не используете, и получать посредственный результат там, где нужен был точный.

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

Какой из этих сервисов вы уже пробовали для бизнеса, и на чем он вас подвел?

Конверсия воронки 2%, и первым делом винят маркетинг.

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

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

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

Пять точек, где обычно течет:
• заявка → первый контакт: смотрите время реакции от заявки до звонка
• контакт → квалификация: смотрите, фиксируется ли причина отказа
• квалификация → встреча: смотрите долю переносов и неявок
• встреча → КП: смотрите, сколько дней КП лежит без отправки
• КП → оплата: смотрите, сколько раз клиент переспросил цену

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

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

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

На каком этапе вашей воронки теряется больше всего, и вы это измеряли, или пока только предполагаете?

40 слайдов за вечер. К защите годятся три

Знакомая картина? Я такое вижу в каждой второй презентации, которую приносят "уже готовой".

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

За 17 лет в ИТ и аудите я смотрю на любую презентацию одним взглядом: где здесь решение и где мусор, который его маскирует. Нейросеть этот взгляд не заменит. Зато черновую работу она делает отлично, если ей отдать структуру. А структуру вы собираете сами.

Сначала структура. Любая рабочая презентация, от питча до отчета совету директоров, держится на пяти блоках:

1. Контекст: что произошло и почему мы вообще здесь.
2. Проблема: что сломается, если ничего не делать. С цифрой.
3. Решение: что предлагаем. Один слайд, одна мысль.
4. Деньги и сроки: сколько стоит, когда окупится.
5. Риски: где мы можем ошибиться и что тогда.

Заметьте: "оглавление", "наша история с 2007 года" и слайд "спасибо за внимание" в списке отсутствуют. Они ничего не продают и ничего не защищают. Хотя без них, кажется, не обходится ни одна презентация на свете.

Теперь промпт. Подход простой: вы описываете нейросети каждый слайд отдельно, и каждый раз указываете роль слушателя. Никакого размытого "сделай презентацию". Работает примерно так:

Ты помогаешь готовить презентацию для [роль: инвестор / совет директоров / клиент]. Слайд N из 12, блок "Проблема". Вот данные: [вставьте сырые цифры]. Сделай: заголовок-утверждение до 8 слов, три буллета по одной строке, вывод одним предложением. Без общих фраз, каждое утверждение подкрепи цифрой из данных.

Ключевое слово здесь: заголовок-утверждение. "Проблемы отрасли" как заголовок мертв, потому что сообщает ровно ноль. "Каждый четвертый клиент уходит из-за очередей" работает: тезис стоит в заголовке, доказательства идут ниже. Слайд должен защищаться сам, без автора: если вас выгнали из зала на втором слайде, презентация расскажет все остальное сама. Заголовок это тезис, буллеты это доказательства, и менять их местами нельзя.

Что проверить перед выдачей, я бы назвала это приемкой:

• Каждый слайд отвечает на вопрос слушателя и ничего не рассказывает про вас.
• Цифры сходятся между слайдами (на 4-м 40%, на 9-м те же данные вдруг 47%).
• Есть слайд про риски. Его отсутствие читается как сокрытие.

Третий пункт почему-то самый непопулярный. Хотя именно слайд "где наша схема может сломаться" вызывает больше всего доверия, я проверяла это на защитах не один десяток раз. Презентация без рисков выглядит как презентация человека, который риски не считал. Есть разница, и зал ее чувствует кожей.

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

Какой слайд в ваших презентациях обычно вытягивает все на себе, и что вы про него рассказываете?

Дружелюбный помощник, который выдумывает вам цены

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

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

Файл этот я про себя называю инструкцией пожеланием, и разница между двумя словами меряется деньгами: клиент запомнит ту цену, которую ему назвали, а объясняться с ним будете вы.

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

Модель поступает ровно так же, только материал у нее другой: она достраивает пустоту всеми такими же дружелюбными помощниками, которых когда-либо видела, а те на вопрос про деньги отвечают бодро и уверенно.

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

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

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

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

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

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

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

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

Шесть блоков целиком и шаблон, в котором остается заменить скобки на свои факты, я собрала здесь: как писать инструкции для ИИ-ассистента.

У кого ассистент уже отвечает клиентам: напишите число прилагательных из его инструкции, и я скажу, что он достроит на месте каждого. Сколько их там набралось?

Пресс-релиз живет дольше проекта, который в нем описан

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

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

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

Месяц 1: доступы еще согласовывают, потому что для встречи с реальными данными модели нужны подписи службы безопасности, владельца учетной системы и человека, отвечающего за 152-ФЗ, а проект в этих очередях уже считается внедренным, для прессы. В каждой очереди задают один и тот же совершенно законный вопрос, письменного ответа на который в документах проекта обычно нет: зачем модели личные данные клиентов?

Месяц 3: в производстве данные устроены иначе, чем на демо, где пилот гоняли на горстке ровных документов, а в настоящем потоке встречаются сканы под углом, пустые поля и люди, которые пишут как пишут. Шаг подготовки данных в план не заложили по причине, которую неловко произносить вслух: слайд "мы приводим в порядок справочники" не срывает оваций, и качество проседает там, где его никто не измерял.

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

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

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

• чей рабочий результат ухудшится, если систему выключить сегодня вечером
• какой показатель он несет на совещание и существовал ли этот показатель до появления ИИ
• сколько обращений прошло через систему за прошлую неделю, в штуках
• кто последний раз готовил для нее данные руками и когда

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

• "пилот покажет" значит, что боевых данных модель не видела
• "мы на этапе интеграции" переводится как отсутствие доступов, и срок здесь держит очередь на подпись
• про "метрику посчитаем позже" достаточно знать, что считать пока нечего

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

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

Восемь фраз подрядчика, за перевод которых вы уже заплатили

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

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

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

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

"Нужно еще две недели" в первый раз означает четыре, во второй, что срок назвали на глаз, а в третий уже относится к следующему подрядчику, которому достанется этот проект вместе с вашим терпением.

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

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

"Клиент сам так захотел" в акте приемки означает, что клиента спросили в чате в 23:40 фразой из шести слов, он ответил "ок", и теперь этот "ок" защищает ту часть системы, которая не работает.

"Доступы мы вам передадим после оплаты" означает, что код, домен и база лежат на аккаунте подрядчика, и до оплаты вы арендуете собственную систему у человека, которому за нее платите.

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

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

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

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

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

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

Типичные проблемы веб-форм:

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

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

Читать разбор и забрать шаблон - ссылка в комментариях

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

Перенастраиваю кросспостинг: один и тот же пост должен уходить и в Telegram, и во ВКонтакте.

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

Во ВКонтакте своя особенность: картинку к такому посту там поставить нельзя вовсе.

Пока настройка идёт, один и тот же пост может выйти несколько раз подряд. Прошу терпения, это ненадолго ❤️

Панель горит зеленым, а заявки месяцами уходят в пустоту

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

Он с самого начала отвечал на другой вопрос.

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

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

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

Вот вопросы, ответов на которые у зеленого индикатора нет, хотя именно они говорят, жива ваша рутина или она давно мертва:

• дошло ли письмо до живого человека или оно до сих пор лежит в очереди отправки, где его никто никогда не увидит
• куда делась заявка, у которой получатель сменил адрес или переполнил ящик: ее еще можно достать и отправить заново или она потеряна совсем

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

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

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

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

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

Что можно проверить сегодня самим, не дожидаясь подрядчика:

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

У кого рутина работает дольше года: сколько времени прошло между тем днем, когда она сломалась, и тем, когда вы об этом узнали, и узнали вы это сами или вам сказал человек со стороны?

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

На тестах модель на восьмидесяти средах накручивала награду в 40% эпизодов, воровала учетные данные, гасила мониторинг и правила логи, доводя долю вредных ответов до 29% против 0,7% и пытаясь обойти защиту в 38% случаев, о чем подробно сообщает Отчет целиком.

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

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