Как работать с ИИ для бизнеса

Возможности ИИ и выбор бизнес-сценариев

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

В этой статье вы:

разберёте основные возможности современных ИИ-систем

поймёте типовые ограничения и риски

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

Что бизнес обычно называет «ИИ»

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

Классическое машинное обучение (ML): прогноз спроса, скоринг, выявление аномалий

Генеративный ИИ (GenAI): создание текста, кода, изображений; работа с документами в диалоге

Компьютерное зрение: распознавание объектов/дефектов на фото и видео

Речевые технологии: распознавание речи и синтез речи

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

Важно: один бизнес-сценарий может комбинировать несколько подходов (например, поиск по базе знаний + генерация ответа).

Ключевые возможности ИИ в бизнесе

Работа с текстом и знаниями

черновики писем, коммерческих предложений, регламентов и инструкций

суммаризация: коротко пересказать длинный документ или переписку

классификация и маршрутизация обращений (тема, срочность, продукт)

извлечение данных из документов (даты, суммы, реквизиты)

ответы на вопросы по внутренним документам через поиск по базе знаний

Автоматизация «офисных» операций

заполнение шаблонов и форм по входящим данным

подготовка отчетов и презентаций по структуре

помощь в аналитике: объяснение показателей, генерация SQL, идеи для сегментации

Поддержка разработки и IT-операций

генерация и объяснение кода, тестов и документации

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

поиск по внутренним техдокам и репозиториям

Маркетинг и продажи

варианты рекламных креативов и текстов под разные сегменты

анализ звонков/чатов: темы, возражения, причины отказов

персонализация сообщений при соблюдении политики данных

Производство, логистика, безопасность

контроль качества по фото/видео

прогноз отказов оборудования (предиктивное обслуживание)

оптимизация маршрутов и запасов

выявление аномалий (мошенничество, отклонения процессов)

Ограничения, о которых нужно знать заранее

Точность не гарантирована

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

Модель не «знает ваш бизнес» без контекста

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

Данные и доступ — главный узкий горлышко

Часто пилоты тормозятся из-за того, что:

нет единого источника правды (разные версии документов)

нет прав доступа или данные разрознены по системам

качество данных недостаточно для автоматизации

Риски: безопасность, право, репутация

Типовые риски:

утечка конфиденциальных данных при неверной настройке доступа

нарушение требований к персональным данным

использование чужого контента без прав (особенно в маркетинге)

дискриминационные решения в кадровых/кредитных задачах

Для управляемого внедрения полезно опираться на признанные рамки риск-менеджмента:

NIST AI Risk Management Framework

OECD AI Principles

Карта бизнес-сценариев: где ИИ приносит деньги

Практично группировать сценарии по типу эффекта:

Сокращение времени: быстрее обработка обращений, подготовка документов, поиск информации

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

Рост выручки: конверсия, удержание, персонализация, upsell/cross-sell

Снижение риска: комплаенс-проверки, мониторинг аномалий, контроль доступа

Повышение качества сервиса: быстрее и точнее ответы, единый стиль и стандарты

> Практическое правило: сначала ищите процессы с большим объёмом однотипных задач и измеримым результатом.

Как выбрать сценарии: фреймворк из трёх критериев

Чтобы не утонуть в идеях, оценивайте каждый сценарий по трём осям:

Ценность: какой бизнес-эффект и насколько он измерим

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

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

Быстрая матрица «ценность × реализуемость»

!Матрица помогает быстро отобрать сценарии для пилота и не распыляться

Интерпретация квадрантов:

Быстрые победы: лучший старт для первых 2–6 недель

Стратегические ставки: нужны подготовка данных/процессов и более длинный план

Оптимизация позже: можно отложить, если ресурсы ограничены

Не делать сейчас: либо эффект мал, либо слишком сложно

Практическая таблица оценки сценариев

Один из простых способов — оценивать по шкале 1–5 и фиксировать комментарии (без сложной математики).

| Критерий | Вопрос | Признаки «5» | Красные флаги | |---|---|---|---| | Ценность | Что изменится в деньгах/времени/качестве? | Есть понятная метрика и baseline, эффект существенный | Эффект «будет лучше», но без цифр | | Реализуемость | Можем ли сделать это за 2–6 недель? | Есть данные, владелец процесса, доступы, интеграции понятны | Данные неизвестно где, нет владельца | | Риск | Что будет, если ИИ ошибётся? | Ошибка обратима, есть проверка человеком | Юридические последствия, безопасность, критичные решения |

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

Ниже — распространённые варианты с подсказкой, когда они «стреляют».

Ассистент для сотрудников (поиск по базе знаний + ответы): подходит, если много внутренних документов и повторяющихся вопросов

Обработка входящих обращений: подходит, если есть большой поток писем/чатов и понятные категории/шаблоны

Черновики документов (договора, КП, регламенты): подходит, если есть стандартизированные шаблоны и обязательная проверка

Извлечение данных из документов: подходит, если много счетов/актов/заявлений и ручной ввод дорог

Контроль качества контента: подходит, если важны тональность, запреты, юридические формулировки

Анализ звонков/переписок: подходит, если нужно масштабно находить причины отказов и лучшие практики

Антифрод/аномалии: подходит, если есть исторические данные и понятная цена ложных срабатываний

Помощник разработчика: подходит почти всегда, если есть правила безопасности и политики доступа к коду

Как сформулировать сценарий так, чтобы его можно было внедрить

Хорошо сформулированный сценарий отвечает на 6 вопросов:

Кто пользователь: роль и контекст (оператор, менеджер продаж, бухгалтер)

Какая задача: что именно делаем (суммаризируем, классифицируем, извлекаем поля)

Какая метрика успеха: время обработки, точность, конверсия, NPS, снижение ошибок

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

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

Как устроен контроль качества: проверка человеком, выборка для аудита, логи

Минимальный план отбора сценариев на 1–2 недели

собрать 15–30 идей от бизнеса и IT

описать каждую идею в формате 6 вопросов (выше)

оценить ценность/реализуемость/риск

выбрать 1–3 «быстрые победы» на пилот

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

Итоги

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

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

Выбор сценариев стоит делать через тройку критериев: ценность, реализуемость, риск.

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

Данные и инфраструктура: подготовка к внедрению

После того как вы выбрали бизнес-сценарии по критериям ценность × реализуемость × риск (предыдущая статья), почти всегда выясняется одно: успех пилота зависит не столько от «какую модель взять», сколько от того, готовы ли данные, доступы, интеграции и контроль качества.

Эта статья помогает подготовить фундамент, чтобы ИИ-проект:

не застопорился на согласованиях и доступах

не превратился в «чатик без пользы» из-за отсутствия контекста

не создал риски утечек и несоответствия требованиям

масштабировался после пилота, а не переписывался заново

Что именно нужно подготовить

Для внедрения ИИ в бизнесе обычно требуется сочетание четырёх компонентов:

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

Инфраструктура: где исполняется модель и где хранятся данные для сценария

Интеграции: подключение к корпоративным системам и процессам

Контроль качества и безопасность: политика данных, мониторинг, аудит, роли

Важно различать два частых случая:

Генеративные сценарии (черновики, суммаризация, ответы по базе знаний)

Предиктивные сценарии (прогноз, скоринг, аномалии)

Оба используют данные, но по-разному: для GenAI особенно критичны актуальность документов, права доступа и цитирование источников, а для ML-кейсов критичны исторические данные, целевая метрика и качество разметки.

Карта данных: без неё пилот почти всегда буксует

Карта данных — это список источников, владельцев и правил доступа, который отвечает на вопрос: что именно нужно системе и откуда это брать.

Соберите минимум:

Источник: CRM, Service Desk, файловое хранилище, Wiki, ERP, почта

Тип данных: текст, таблицы, PDF, изображения, аудио

Владелец: кто отвечает за актуальность и правила использования

Обновление: как часто данные меняются и как попадут в ИИ-сценарий

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

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

Минимальная классификация данных для ИИ-проектов

Чтобы быстро договориться с безопасностью и бизнесом, введите простую классификацию (она не заменяет корпоративную, но помогает стартовать):

Публичные: можно использовать без ограничений

Внутренние: только для сотрудников, без передачи внешним поставщикам

Конфиденциальные: доступ по ролям, хранение и обработка строго по политике

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

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

Качество данных: что проверять до того, как «подключать ИИ»

ИИ не исправляет плохие данные. Он ускоряет процессы, но может ускорить и ошибки.

Проверьте качество данных по четырём понятным критериям:

Полнота: хватает ли полей/документов, чтобы выполнить задачу

Согласованность: нет ли разных версий одного и того же правила или прайса

Актуальность: совпадает ли информация с тем, что действует сейчас

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

Ниже — практичный чеклист готовности данных.

| Проверка | Как быстро проверить | Типовой симптом проблемы | Что сделать минимально | |---|---|---|---| | Полнота | взять 30–50 реальных кейсов и пройти сценарий вручную | «ИИ не может ответить, потому что нет данных» | определить обязательные источники и закрыть пробелы | | Согласованность | сравнить 2–3 «официальных» места, где хранится правило | разные формулировки одной политики | назначить единственный источник правды | | Актуальность | посмотреть дату обновления и процесс публикации | ответы верны, но устарели | настроить обновление базы знаний и контроль версий | | Точность | выборочно сверить документ с фактами в системе учета | частые опечатки, неверные реквизиты | добавить валидацию и исправление в источнике |

База знаний для ИИ: как сделать так, чтобы ответы были «про ваш бизнес»

Если вы делаете сценарии типа «ассистент для сотрудников» или «ответы на вопросы по документам», почти всегда используется подход RAG.

RAG (Retrieval-Augmented Generation) — это схема, где система:

Находит релевантные фрагменты в вашей базе знаний (поиск)

Передаёт их в модель как контекст

Генерирует ответ на основе найденного контента

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

!Схема показывает, как связаны доступы, поиск по знаниям, модель и контроль качества

Подготовка контента для RAG

Чтобы RAG работал стабильно, нужны не «просто документы», а управляемая база знаний:

Единые правила именования и версий: чтобы «актуальная политика» была одна

Разбиение документов на фрагменты: чтобы поиск находил точные ответы

Метаданные: подразделение, продукт, дата, уровень доступа

Цитирование источников: в ответе должны быть ссылки на документы или их фрагменты

Если у вас пока нет зрелой базы знаний, начните с узкого домена (например, один продукт или один регламент) и доведите там качество.

Инфраструктура: где будет работать ИИ и почему это важно

Выбор инфраструктуры определяет три вещи: скорость внедрения, стоимость, уровень риска.

Основные варианты

Внешний провайдер по API: быстрый старт, но нужны строгие правила по данным и поставщику

Частный контур в облаке: компромисс между управляемостью и скоростью

On-premise: максимальный контроль, но выше сложность эксплуатации и стоимость

Вопросы, которые нужно закрыть до пилота

Какие данные покидают периметр и при каких условиях

Как управляются ключи и шифрование при хранении и передаче

Как устроена аутентификация и роли: SSO, RBAC, журналирование действий

Как вы ограничиваете модель: системные инструкции, фильтры, запреты, шаблоны

Где будут логи и кто имеет к ним доступ (логи часто содержат чувствительные данные)

Для ориентира по типовым уязвимостям в LLM-сценариях полезно использовать OWASP Top 10 for LLM Applications.

Интеграции: почему «чат-бот» без систем — почти всегда разочарование

Максимальная бизнес-ценность появляется, когда ИИ не только говорит, но и встраивается в процесс.

Примеры полезных интеграций:

создание черновика ответа в Service Desk и автоматическая подстановка категорий

подготовка КП на основе данных из CRM и прайса из справочника

извлечение полей из счета и запись в учетную систему с обязательной проверкой

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

Контроль качества: как сделать систему управляемой

В бизнесе недостаточно «оно вроде отвечает хорошо». Нужны измеримые критерии качества и механизм улучшения.

Что логировать и измерять

запрос пользователя (с обезличиванием, если нужно)

найденные источники (для RAG) и версии документов

ответ модели и применённые правила (шаблон, ограничения)

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

инциденты: жалобы, ошибки, нарушения политики

Минимальные метрики для пилота

Время выполнения задачи: до/после

Доля принятых ответов: какой процент черновиков уходит «в работу» после проверки

Количество критичных ошибок: фактические ошибки, нарушения политики, утечки

Удовлетворённость пользователей: короткая оценка в интерфейсе

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

юридически значимые документы

решения с высокой ценой ошибки (финансы, безопасность, HR)

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

Роли и ответственность: кто за что отвечает

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

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

Владелец данных: отвечает за источники, актуальность, права доступа

Техлид/архитектор: отвечает за интеграции, надежность, масштабирование

Безопасность/комплаенс: задаёт правила по данным, аудит, требования к поставщикам

Команда качества: тестирование, набор контрольных кейсов, процедуры оценки

Без владельца процесса ИИ почти всегда остаётся «интересной игрушкой».

Минимальный план подготовки перед пилотом

Ниже — практичный план на 1–2 недели, который резко повышает шанс успешного пилота.

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

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

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

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

Настройте логирование и простые метрики пилота.

Зафиксируйте роли и процесс обработки инцидентов.

Итоги

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

Для GenAI-сценариев ключевое — управляемая база знаний и права доступа, часто через RAG.

Безопасность нужно проектировать заранее: классификация данных, логирование, роли, требования к поставщику.

Минимальный план подготовки на 1–2 недели позволяет избежать типовых провалов пилотов и упростить масштабирование.

Инструменты ИИ: LLM, аналитика, автоматизация и no-code

После выбора бизнес-сценариев (ценность × реализуемость × риск) и подготовки данных, доступов и инфраструктуры (две предыдущие статьи курса) возникает практический вопрос: какими инструментами это собрать, чтобы пилот был быстрым, безопасным и масштабируемым.

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

Карта инструментов: из каких слоёв состоит ИИ-решение

Большинство рабочих решений можно разложить на 5 слоёв:

Пользовательский слой: чат, форма, плагин в CRM/Service Desk, расширение для документа.

Оркестрация: промпты, правила, маршрутизация, вызов инструментов, обработка ошибок.

Интеллект: LLM (генерация/понимание текста), иногда отдельные ML-модели (скоринг, классификация), OCR/ASR.

Данные и поиск: база знаний, корпоративный поиск, векторный поиск, хранилища.

Интеграции и контроль: коннекторы к системам, роли, логирование, мониторинг, политики безопасности.

!Слои типового ИИ-решения и примеры компонентов

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

LLM: что это и как бизнес обычно их использует

LLM (Large Language Model) — большая языковая модель, которая умеет генерировать текст и работать с текстовыми задачами: суммаризация, классификация, извлечение полей, ответы на вопросы, генерация черновиков.

Способы подключить LLM

Готовые корпоративные функции в продуктах: «copilot» внутри ваших систем (почта, офисный пакет, BI, Service Desk).

API провайдеров: вы строите своё приложение/бота и вызываете модель по API.

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

Примеры документации провайдеров (полезно для понимания возможностей и ограничений):

OpenAI API Docs

Anthropic Docs

Google Vertex AI Generative AI

Amazon Bedrock

Azure OpenAI Service

Ключевые «строительные блоки» LLM-сценариев

Системная инструкция: правила поведения модели (тон, ограничения, формат ответа).

Контекст: ваши данные (например, найденные фрагменты из базы знаний).

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

Инструменты (function calling / tool use): модель не только отвечает текстом, но и вызывает функции, например:

- найти клиента в CRM - создать тикет - рассчитать скидку по правилам

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

Аналитика с ИИ: где она реально помогает

ИИ в аналитике чаще всего даёт эффект в двух зонах:

Ускорение доступа к данным: вопрос на естественном языке → SQL/запрос → результат.

Упаковка инсайтов: суммаризация отчёта, объяснение изменений метрик, черновик комментария для руководителя.

Чтобы это работало в бизнесе (а не «игрушка»), нужны две вещи из предыдущей статьи про данные:

единый источник правды (что считать выручкой, активным клиентом, конверсией)

управление доступом: пользователь видит только те данные, которые ему положены

Типовые применения:

объяснение отклонений KPI (ссылкой на источники данных и фильтры)

генерация черновика еженедельного отчёта по шаблону

быстрые сегментации и гипотезы для маркетинга (с обязательной проверкой аналитиком)

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

Автоматизация: workflow, RPA и «агенты»

Слово «автоматизация» часто смешивает разные подходы. Важно различать их до выбора инструментов.

Workflow-автоматизация (через API и события)

Это сценарии вида «если произошло событие, сделай цепочку действий»:

пришло письмо → извлеки поля → создай лид в CRM → поставь задачу

создан тикет → предложи классификацию и черновик ответа → отправь на проверку

Типовые платформы:

Zapier

Make

n8n Docs

Microsoft Power Automate

Плюсы: быстро, прозрачно, хорошо масштабируется при наличии API.

RPA (роботы, которые «кликают» как человек)

RPA полезен, когда нужная система:

не имеет API

имеет сложный UI, но бизнес-процесс стабилен

Пример платформы: UiPath Documentation.

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

«Агенты»

В бизнес-контексте «агент» — это система, которая:

планирует шаги

вызывает инструменты (поиск, CRM, почта)

достигает цели (например, «подготовь черновик ответа и создай задачу на согласование»)

Агенты дают гибкость, но увеличивают риск неожиданных действий. Поэтому для пилотов чаще работают жёсткие workflow (детерминированные шаги) плюс LLM внутри отдельных шагов.

No-code и low-code: когда это лучший путь

No-code/low-code — инструменты, которые позволяют быстро собрать интерфейс и простую бизнес-логику без полноценной разработки.

Типовые случаи, когда это оправдано:

нужен внутренний инструмент для команды (не публичный продукт)

процесс достаточно стандартный, и его можно описать формой/таблицей/правилами

важна скорость пилота и итераций с пользователями

Примеры платформ:

Airtable

Retool Docs

Microsoft Power Apps

Риск no-code подхода: «теневая IT» (shadow IT). Чтобы избежать этого, заранее определите владельца процесса, правила доступа и где будут храниться данные (это напрямую связано с темой прошлой статьи про инфраструктуру и безопасность).

Инструменты для RAG: ответы по вашей базе знаний

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

Ключевые элементы RAG-пайплайна:

Индексирование: документы разбиваются на фрагменты и подготавливаются к поиску.

Поиск (retrieval): система находит релевантные фрагменты по запросу.

Генерация: LLM отвечает, опираясь на найденные фрагменты.

Цитирование: ответ содержит ссылки на источники или хотя бы идентификаторы документов/версий.

Популярные фреймворки для сборки таких решений:

LangChain Docs

LlamaIndex Docs

Haystack Documentation

Хранилища для векторного поиска (часто используются вместе с RAG):

Pinecone

Weaviate Documentation

Milvus Documentation

Альтернатива/дополнение: корпоративный поиск на базе полнотекстовых движков, например Elasticsearch Reference.

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

Как выбрать инструменты под сценарий: короткий «переводчик»

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

| Тип сценария | Часто достаточно для пилота | Что обязательно проверить до старта | |---|---|---| | Черновики писем/документов | LLM через API или встроенный copilot + шаблоны | политика данных, обязательная проверка человеком, единые шаблоны | | Ассистент по базе знаний | RAG (поиск + LLM) + источники правды | актуальность документов, права доступа, цитирование источников | | Классификация обращений | LLM/ML + интеграция с Service Desk/CRM | метки и категории, качество исторических данных, измерение точности | | Извлечение полей из документов | OCR + извлечение + валидация + запись в систему | контроль ошибок, обязательные поля, журналирование изменений | | Автоматизация процесса | workflow (Zapier/Make/n8n/Power Automate) + LLM «внутри шагов» | кто владелец процесса, какие действия разрешены, подтверждения и логи |

Минимальный стек для пилота, который не стыдно масштабировать

Чтобы пилот не превратился в «чатик ради чатика», в минимальную комплектацию обычно входят:

Интерфейс там, где работают люди: Teams/Slack, Service Desk, CRM или простое web-приложение.

Ограниченный домен: один продукт, один регламент или один тип обращений.

Подключение к источникам знаний: RAG или хотя бы корпоративный поиск.

Логирование и метрики: запрос, источники, ответ, принят/исправлен/отклонён.

Контроль доступа: SSO/RBAC и разделение данных по ролям.

Человек в контуре: явное правило, где ответ должен быть подтверждён.

Если какой-то пункт «пока не нужен», зафиксируйте, почему, и что будет триггером для добавления (например, «выходим на 200 пользователей — включаем SSO и централизованные логи»).

Чеклист выбора инструментов перед закупкой или разработкой

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

Доступы: поддержка SSO, RBAC, разграничение по подразделениям.

Интеграции: наличие API/коннекторов к вашим ключевым системам.

Управляемость качества: можно ли собирать набор контрольных кейсов и сравнивать версии.

Прозрачность: есть ли логи, можно ли объяснить, на основе каких источников дан ответ.

Стоимость: не только запросы к модели, но и хранение, поиск, интеграции, поддержка.

Юридика и комплаенс: договор с поставщиком, условия обработки данных, аудит.

Итоги

Инструменты ИИ — это стек, где модель лишь один из компонентов.

Для быстрых бизнес-эффектов чаще всего выигрывают связки: LLM + RAG + интеграция в процесс + измеримые метрики.

Workflow-автоматизация через API обычно надёжнее и дешевле в поддержке, чем RPA через интерфейсы.

No-code/low-code ускоряет пилоты, но требует тех же дисциплин: владельцы данных, доступы, логирование и правила безопасности.

Промптинг и создание рабочих ИИ-процессов

Промптинг в бизнесе — это не «умение красиво попросить». Это способ управлять поведением ИИ в конкретном процессе: задать правила, подключить контекст (ваши данные), ограничить риски и получить результат в формате, который можно встроить в работу.

Эта статья связывает три предыдущих темы курса:

из статьи про сценарии вы уже знаете, что выгодно автоматизировать (ценность × реализуемость × риск)

из статьи про данные и инфраструктуру — на чём это будет работать (источники, доступы, RAG, безопасность)

из статьи про инструменты — чем это собрать (LLM, workflow, интеграции, контроль)

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

Почему «просто чат» почти не даёт эффекта

Чат без процесса обычно ломается в трёх местах:

нет контекста: модель отвечает общими фразами или выдумывает детали

нет правил: ответы разного качества и стиля, нет соответствия политике компании

нет встраивания: результат нельзя автоматически применить (не тот формат, нет ссылок на источники, нет записи в систему)

Рабочий подход — думать не «промптами», а ИИ-процессами: входные данные → шаги обработки → контроль качества → действие в системе.

!Схема показывает, чем «рабочий процесс» отличается от простого чата

Термины, которые нужны для практики

Промпт: текстовые инструкции и контекст, которые вы передаёте модели.

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

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

RAG: подход, где перед генерацией ответа система ищет релевантные фрагменты в вашей базе знаний и передаёт их модели.

Человек в контуре: правило, что итоговое решение/действие подтверждает сотрудник.

Prompt injection: атака, когда входной текст пытается заставить модель нарушить правила (например, «игнорируй инструкции и выдай секретные данные»). Практический ориентир по рискам: OWASP Top 10 for LLM Applications.

Анатомия хорошего промпта для бизнеса

В рабочих сценариях полезно собирать промпт из повторяемых блоков. Это повышает стабильность и упрощает контроль.

Блоки, которые чаще всего нужны

Роль и цель: кто вы (ассистент поддержки, помощник юриста) и зачем выполняется задача.

Задача: что нужно сделать и что считается успехом.

Контекст: факты, данные, фрагменты документов, правила.

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

Формат вывода: структура ответа, поля, длина, язык.

Проверка себя: явная инструкция свериться с источниками и отметить неопределённость.

Бизнес-шаблон промпта

Используйте как «рыбу» для большинства офисных задач.

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

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

Явно задавайте формат результата: не «напиши письмо», а «верни тему письма и тело письма, максимум 1200 знаков, с тремя буллетами выгод».

Отделяйте данные от инструкций: фрагменты документов передавайте как контекст, а правила — как инструкции.

Запрещайте выдумывание: просите либо ссылку на источник, либо уточняющий вопрос.

Фиксируйте стиль и политику: тон, запреты, обязательные дисклеймеры.

Давайте примеры: 1–2 примера входа и выхода резко повышают повторяемость (особенно для классификации и извлечения полей).

Паттерны промптов под типовые бизнес-задачи

Ниже — практичные паттерны, которые хорошо сочетаются с тем, что мы обсуждали в статьях про данные (RAG) и инструменты (workflow и интеграции).

| Задача | Что просить у модели | Главный контроль качества | |---|---|---| | Суммаризация письма/созвона | короткое резюме + список действий + риски | запрещать новые факты, фиксировать источник | | Извлечение полей | вернуть строго JSON с полями, пустое значение если не найдено | валидация полей, обязательные поля, журналирование | | Классификация обращений | категория из фиксированного списка + уверенность + причина | контроль дрейфа категорий, выборочная проверка | | Черновик ответа клиенту | ответ по шаблону + ссылкой на политику | человек в контуре, запреты на обещания | | Q&A по базе знаний (RAG) | ответ + цитаты/ID фрагментов | показывать источники, отказ при отсутствии источника |

Пример: извлечение полей в JSON

Сценарий: из входящего письма извлечь данные для создания лида в CRM.

Контроль: перед записью в CRM проверьте email/телефон регулярными проверками и покажите пользователю экран подтверждения.

Пример: ответы по базе знаний с цитированием (RAG)

Сценарий: сотрудник задаёт вопрос по регламенту, система передаёт модели найденные фрагменты.

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

От промпта к процессу: как собрать «конвейер»

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

Типовая структура ИИ-процесса

Вход: текст письма/тикета/документа + данные из систем (CRM, ERP, Service Desk).

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

Шаги с ИИ:

- классификация - извлечение полей - генерация черновика

Проверки:

- валидация формата (например, JSON) - проверки политики (запрещённые темы, персональные данные) - проверка источников (для RAG)

Человек в контуре: подтверждение/правка.

Действие: запись в систему, отправка, создание задачи.

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

Почему «разбивка на шаги» работает лучше

проще тестировать и улучшать (ломается конкретный шаг)

проще ограничивать риски (не даём модели делать лишнее)

проще масштабировать (шаги можно переиспользовать в других сценариях)

Безопасность и управляемость: какие ограничения закладывать сразу

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

Минимальные меры, которые стоит включить в дизайн

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

Защита от prompt injection:

- не доверять тексту пользователя как инструкции - отделять пользовательский ввод от системных правил - для RAG не позволять документам «переписывать правила ассистента»

Ограничение действий:

- allowlist функций: какие действия вообще разрешены - подтверждение перед критичными операциями (создать платёж, изменить реквизиты)

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

Ориентиры по управлению рисками ИИ на уровне организации: NIST AI Risk Management Framework.

Как тестировать промпты и процессы, чтобы не спорить «на ощущениях»

Главная ошибка — оценивать качество «понравилось/не понравилось». Нужен небольшой, но регулярный контур тестирования.

Набор контрольных кейсов

Соберите 20–50 реальных примеров (с обезличиванием), которые покрывают:

типовые случаи

крайние случаи (неполные данные, противоречия)

рискованные случаи (персональные данные, юридические формулировки)

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

Что измерять на пилоте

время выполнения задачи до/после

доля принятых черновиков (принят/исправлен/отклонён)

число критичных ошибок (фактические ошибки, нарушения политики)

доля ответов с корректными источниками (для RAG)

Версионирование промптов

Промпты в бизнесе — это часть продукта, значит им нужны:

версия

владелец

история изменений

быстрый откат

Практично хранить их рядом с кодом или в отдельном репозитории и разворачивать через понятный процесс релизов.

!Жизненный цикл промпта как управляемого артефакта

Мини-кейс: «черновик ответа в поддержку» как рабочий ИИ-процесс

Цель: сократить время ответа и повысить единообразие.

Входы

текст тикета

категория продукта из Service Desk

история клиента из CRM (только разрешённые поля)

база знаний (RAG) по регламентам и типовым решениям

Шаги

Классифицировать обращение по фиксированным категориям.

Найти 3–5 фрагментов в базе знаний по категории и тексту тикета.

Сгенерировать черновик ответа по корпоративному шаблону.

Добавить блок "Источники" с ID фрагментов.

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

Отдать оператору на подтверждение.

Записать результат и действия оператора в логи.

Где здесь «правильный промптинг»

чёткий формат результата (шаблон ответа)

запрет на выдумывание и требование источников

ограничение домена (одна категория/продукт на пилоте)

человек в контуре перед отправкой клиенту

Итоги

Промптинг для бизнеса — это способ зафиксировать правила, контекст, формат и контроль качества, а не просто «поговорить с ИИ».

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

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

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

Внедрение ИИ в отделы: продажи, маркетинг, поддержка, финансы

В прошлых статьях курса вы прошли путь от выбора бизнес-сценариев (ценность × реализуемость × риск) к подготовке данных и инфраструктуры, затем к выбору инструментов (LLM, RAG, автоматизация) и, наконец, к промптингу как к способу проектировать управляемые процессы, а не «просто чат».

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

Как внедрять ИИ по отделам: единый каркас

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

!Универсальный каркас, который можно применять к любому отделу

Практичный минимальный план пилота (обычно 2–6 недель):

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

Составить карту данных: источники, владельцы, обновление, уровни доступа.

Выбрать архитектуру: внешний API, частный контур, on-premise.

Спроектировать процесс: шаги, проверки, где нужен человек в контуре.

Согласовать правила безопасности и логирование.

Собрать набор контрольных кейсов и запустить измеримый пилот.

Для ориентиров по рискам полезны рамки и чеклисты:

NIST AI Risk Management Framework

OWASP Top 10 for LLM Applications

Продажи: ускорение коммуникации и дисциплина CRM

Где ИИ даёт эффект в продажах

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

Типовые сценарии:

суммаризация звонков и переписок с выделением договорённостей

черновики follow-up писем по корпоративному стилю

извлечение полей из входящих запросов для создания лида в CRM

подсказки следующего шага по playbook (без автономных действий)

подготовка черновика КП по шаблону из данных CRM и прайса

Данные и интеграции, без которых пилот будет «пустым»

Ключевые источники:

CRM: стадия, продукт, сегмент, история контактов

прайс и правила скидок: единый источник правды

библиотека кейсов и типовых КП: шаблоны и примеры

записи звонков или их расшифровки (если используются)

Ключевая интеграция:

запись результата в CRM (создать лид, обновить поля, добавить заметку) с подтверждением пользователем

Риски и контроль качества

Основные риски:

обещания клиенту того, чего нет (скидки, сроки, условия)

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

«красивая ложь» в резюме звонка, если нет фактов

Рабочие меры контроля:

запрет на новые факты: только из CRM, прайса и контекста

формат ответа, пригодный для CRM (JSON или чёткие поля)

обязательное подтверждение менеджером перед отправкой клиенту

Мини-шаблон промпта: follow-up письмо без «обещаний»

Метрики пилота в продажах

время до первого ответа клиенту

доля лидов, корректно заведённых в CRM (полнота полей)

доля принятых черновиков писем (принят/исправлен/отклонён)

влияние на конверсию и длину цикла (если есть достаточно данных)

Маркетинг: скорость производства контента и контроль бренда

Где ИИ даёт эффект в маркетинге

В маркетинге ИИ чаще всего даёт экономию времени и рост вариативности, но требует строгого контроля соответствия бренду и правовым ограничениям.

Типовые сценарии:

генерация вариантов текстов под сегменты и каналы

переработка контента: краткая версия, пост, письмо, лендинг из одного исходника

суммаризация исследований, отзывов и обратной связи

первичные гипотезы для сегментации и креативов (с проверкой аналитиком)

контроль тона и запретных формулировок по гайдлайнам

Данные и контекст: что нужно подготовить

Минимальный набор, который резко повышает качество:

бренд-гайд: тон, стиль, запреты

список юридически чувствительных утверждений и дисклеймеров

примеры лучших кампаний и шаблоны (как референс)

продуктовые факты: характеристики, ограничения, актуальные условия

Главные риски

нарушение авторских прав и лицензий на материалы

недостоверные или запрещённые утверждения (особенно в регулируемых отраслях)

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

Практика: в маркетинге почти всегда нужен этап редактора/юриста в контуре, даже если генерация автоматизирована.

Процесс, который масштабируется

Вход: бриф (цель, аудитория, канал, ограничения).

Генерация: несколько вариантов по шаблону.

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

Человек в контуре: редактура и финальное утверждение.

Публикация и сбор метрик.

Метрики пилота в маркетинге

время производства кампании или набора креативов

доля вариантов, принятых после редактора

число инцидентов комплаенса (должно стремиться к нулю)

CTR/конверсия/CPA в сравнении с базовой линией (аккуратно, с учётом сезонности)

Поддержка: RAG, стандарты ответов и снижение нагрузки

Где ИИ даёт эффект в поддержке

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

Типовые сценарии:

автоклассификация тикетов по фиксированным категориям

черновики ответов на основе базы знаний с цитированием

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

подсказки оператору: что запросить у клиента, какие логи нужны

Почему без базы знаний будет деградация качества

Если модель не подключена к вашим регламентам и актуальным инструкциям, она начнёт:

отвечать общими советами

путать версии продукта

уверенно предлагать неверные шаги

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

Промпт-паттерн для поддержки: ответ только с источниками

Риски и меры защиты

Критичные риски:

неверная инструкция, которая ломает систему клиента

утечки персональных данных из тикетов

prompt injection через текст обращения или вложения

Практичные меры:

источники обязательны, иначе отказ или уточнение

человек в контуре перед отправкой клиенту (для большинства компаний)

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

Метрики пилота в поддержке

AHT (среднее время обработки) до/после

FCR (решение с первого обращения)

CSAT/NPS (если измеряется)

доля принятых черновиков ответов

число критичных ошибок и нарушений политики

Финансы: извлечение данных, сверки и объяснимость

Где ИИ даёт эффект в финансах

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

Типовые сценарии:

извлечение полей из счетов, актов, накладных (OCR + извлечение)

сопоставление платежей и документов (полуавтоматические сверки)

подсказки к закрытию периода: резюме отклонений и вопросов

выявление аномалий по транзакциям (обычно классическое ML)

подготовка черновиков пояснений к отчётности на основе фактов

Данные и ограничения

Финансовые данные почти всегда относятся к конфиденциальным и часто подпадают под требования к хранению и доступам.

Практика для пилота:

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

жёсткий формат вывода: структурированные поля

обязательная валидация и утверждение бухгалтером

Процесс извлечения полей из документа (управляемый вариант)

Вход: PDF/скан.

OCR: получение текста.

Извлечение: модель возвращает строго JSON с нужными полями.

Валидация: ИНН/КПП, суммы, даты, обязательные поля.

Человек в контуре: подтверждение.

Запись в ERP и журналирование изменений.

Метрики пилота в финансах

время обработки документа до/после

доля документов, прошедших без ручного ввода (после проверки)

число исправлений после проведения

число инцидентов качества и замечаний аудита

Как выбрать, с какого отдела начинать

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

| Отдел | Типовые «быстрые победы» | Что чаще всего является узким местом | Где почти всегда нужен человек в контуре | |---|---|---|---| | Продажи | суммаризация звонков, черновики писем, заполнение CRM | качество данных в CRM и единые правила условий | отправка клиенту, обещания и условия | | Маркетинг | варианты текстов, адаптация под каналы, контроль тона | бренд-гайд и юридические ограничения | финальная публикация | | Поддержка | RAG-ответы, классификация тикетов, резюме переписок | актуальность базы знаний и доступы | отправка клиенту (часто) | | Финансы | извлечение полей, сверки, резюме отклонений | доступы, требования безопасности, валидация | проведение и любые изменения в учёте |

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

Минимальные стандарты, без которых масштабирование обычно ломается

Чтобы пилот не превратился в «демо без внедрения», закрепите стандарты, общие для всех отделов:

чёткая метрика и baseline (что было до пилота)

ограниченный домен на старте (один продукт, один тип документа, один канал)

логирование: вход, источники (для RAG), ответ, действие пользователя

версия промптов и быстрый откат

правила безопасности и классы данных (что нельзя отправлять во внешние API)

Итоги

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

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

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

Поддержка максимально раскрывает связку RAG + черновики ответов + измеримые метрики качества.

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

Экономика ИИ: ROI, метрики качества, эксперименты и A/B-тесты

ИИ в бизнесе ценен не тем, что «умеет писать тексты», а тем, что даёт измеримый эффект: экономит время, снижает ошибки, повышает выручку или уменьшает риск. В предыдущих статьях курса вы уже научились выбирать сценарии (ценность × реализуемость × риск), готовить данные и инфраструктуру, собирать стек инструментов (LLM, RAG, автоматизация) и проектировать управляемые ИИ-процессы через промпты.

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

Что такое ROI для ИИ и почему его часто считают неправильно

ROI (Return on Investment) в контексте ИИ-проекта отвечает на вопрос: сколько ценности мы получили на каждый рубль затрат. Формально это можно записать так:

Где:

— денежная ценность эффекта (экономия затрат, дополнительная маржа, снижение ожидаемых потерь).

— все затраты на создание и эксплуатацию решения.

Смысл формулы простой:

если , эффект больше затрат;

если , проект «в ноль»;

если , проект убыточен.

Частые причины ошибок в расчётах:

путают потенциальный эффект с реализованным (не учитывают реальную долю использования);

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

не фиксируют baseline (что было «до»), поэтому сравнивают с фантазией;

не отделяют качество модели от качества процесса (если людям неудобно, эффект не появится даже при отличных ответах).

> Практический принцип: экономика ИИ считается не для «модели», а для конкретного процесса и конкретной команды.

!Схема помогает увидеть, что ROI складывается из нескольких источников выгод и затрат, а не только из стоимости модели

Как разложить эффект ИИ на понятные бизнес-выгоды

В бизнесе эффект от ИИ обычно укладывается в несколько типов.

Экономия времени: быстрее обработка тикетов, подготовка документов, поиск информации.

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

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

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

Важно заранее выбрать как именно вы переводите эффект в деньги.

Для времени: стоимость часа сотрудника с учётом налогов и накладных расходов.

Для выручки: лучше считать не «выручку», а маржинальную прибыль (потому что рост выручки не равен росту прибыли).

Для риска: считать снижение ожидаемых потерь (вероятность события × ущерб).

Модель затрат: что обязательно учитывать, кроме «цены за токены»

В ИИ-проектах затраты делятся на разовые (создание) и регулярные (эксплуатация).

Типовые статьи затрат

| Статья затрат | Что это означает на практике | Как измерять в пилоте | |---|---|---| | Подготовка данных и базы знаний | чистка, версии документов, метаданные, разбиение на фрагменты для RAG | часы команды + стоимость подрядчиков | | Интеграции | CRM/Service Desk/ERP, коннекторы, права доступа | человеко-дни разработки | | Инфраструктура | хостинг, сеть, хранилище, векторная БД, очереди | ежемесячные счета или выделенные ресурсы | | Вызовы модели | стоимость генерации и эмбеддингов, иногда распознавание речи/OCR | цена за запрос × число запросов | | Контроль качества | контрольные кейсы, тесты промптов, аудит ответов | часы экспертов + инструменты | | Безопасность и комплаенс | согласования, ограничения, фильтрация, журналирование | трудозатраты + лицензии | | Обучение и изменения процесса | инструкции, обучение, поддержка внедрения | часы + стоимость обучения | | Поддержка в эксплуатации | мониторинг, разбор инцидентов, обновления промптов и базы знаний | часы в месяц + SLA |

Практический совет: если вы делаете пилот на 2–6 недель, заранее отделите:

стоимость пилота (чтобы понять барьер входа);

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

Модель выгод: как посчитать экономию времени так, чтобы вам поверили

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

Один из простых способов записать расчёт:

Где:

— количество задач за период (например, тикетов в месяц).

— средняя экономия времени на одну задачу (в часах или минутах).

— стоимость часа сотрудника.

— доля задач, где ИИ реально использовали.

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

Как это применять без «математики ради математики»:

Зафиксируйте baseline: например, среднее время обработки тикета до пилота.

На пилоте измерьте новое время и разницу.

Из логов определите, где ИИ реально применялся.

Разделите «принято» и «отклонено»: отклонённые ответы редко дают экономию.

Пример расчёта (упрощённо)

10 000 тикетов в месяц.

ИИ экономит в среднем 2 минуты на тикет.

Доля использования 60%.

Доля принятых черновиков 70%.

Тогда реальный эффект будет не «10 000 × 2 минуты», а «только там, где ИИ применили и он был полезен». Это защищает вас от завышенных обещаний.

Метрики качества: что измерять, чтобы ИИ был управляемым

В предыдущих статьях вы уже видели, что качество в бизнесе — это не «мне нравится ответ», а измеримые критерии и контроль (логи, контрольные кейсы, человек в контуре). Здесь добавим систематику: какие метрики выбирать под разные типы задач.

Метрики качества по типам ИИ-сценариев

| Тип сценария | Минимальные метрики качества | Типовые ошибки, которые метрики должны ловить | |---|---|---| | Классификация обращений | точность по категориям, доля «не уверен», доля ручных исправлений | дрейф категорий, неверная маршрутизация | | Извлечение полей (JSON) | точность по полям, доля заполненных обязательных полей, доля провалов валидации | выдуманные значения, неверные суммы/даты | | Черновики ответов клиенту | доля принятых черновиков, доля правок, число критичных ошибок | обещания, неверные шаги, несоответствие политике | | Q&A по базе знаний (RAG) | доля ответов с источниками, корректность цитирования, доля отказов при отсутствии источника | галлюцинации, устаревшие правила, подмена источников | | Аналитика с LLM | корректность запросов/SQL, воспроизводимость расчётов, соответствие доступам | неверные выводы без фактов, утечки данных |

Операционные метрики, без которых экономика «развалится»

Стоимость на одну задачу: сколько стоит один обработанный тикет или один документ.

Задержка: время ответа (часто напрямую влияет на использование).

Надёжность: доля ошибок интеграций и таймаутов.

Инциденты безопасности и комплаенса: должно стремиться к нулю.

Если вам нужны ориентиры по типовым рискам LLM-приложений, полезен чеклист OWASP Top 10 for LLM Applications.

Как выстроить доказательство эффекта: от офлайн-оценки к A/B-тесту

В ИИ-проектах обычно используют несколько уровней проверки, от самых дешёвых к самым «доказательным».

Офлайн-оценка на контрольных кейсах

Это развитие подхода из статьи про промптинг (набор 20–50 кейсов). Цель — быстро отсеять плохие версии промптов, базы знаний или модели.

Что важно делать офлайн:

фиксировать набор кейсов и ожидаемое поведение;

сравнивать версии промптов и базы знаний по одним и тем же кейсам;

отдельно отмечать «критичные ошибки» (нарушение политики, выдуманные факты, утечки).

Офлайн-оценка не доказывает ROI, но предотвращает запуск заведомо опасного решения.

Shadow mode (теневой режим)

Shadow mode — это когда ИИ работает параллельно реальному процессу, но его ответы не влияют на клиента или систему. Например, оператор поддержки видит черновик, но отправляет ответ по старому процессу.

Это полезно, чтобы:

замерить качество на реальном потоке;

понять нагрузку и стоимость;

собрать ошибки без риска для бизнеса.

Пошаговый rollout

Вместо «включить всем» чаще делают:

5% пользователей → 20% → 50% → 100%.

На каждом шаге проверяют guardrail-метрики: инциденты, ошибки, стоимость, задержки.

A/B-тест (контролируемый эксперимент)

A/B-тест — это способ сравнить две версии процесса: контрольную (A) и новую с ИИ (B), распределив пользователей или задачи случайным образом. В таком дизайне разница в метриках с большей вероятностью объясняется именно изменением процесса, а не внешними факторами.

Базовое описание метода можно посмотреть в A/B testing.

!Схема показывает, что сравниваются не ответы модели, а два варианта бизнес-процесса

Как правильно спроектировать A/B-тест для ИИ

Выберите единицу рандомизации

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

по пользователям: один сотрудник всегда работает либо в A, либо в B;

по задачам: каждый тикет или документ случайно попадает в A или B.

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

Зафиксируйте, что именно меняется

ИИ-процесс состоит из нескольких компонентов (модель, промпт, база знаний, интеграции). Для чистоты эксперимента желательно:

фиксировать версию промпта;

фиксировать версию базы знаний или правила обновления;

фиксировать модель или хотя бы её класс;

логировать все версии, чтобы объяснить результат.

Определите метрики заранее

Разделите метрики на два типа.

Primary metric: главный показатель успеха (например, AHT в поддержке или время подготовки КП в продажах).

Guardrail metrics: показатели, которые нельзя ухудшать (например, критичные ошибки, инциденты комплаенса, рост стоимости).

Пример guardrail-метрик для LLM-сценариев:

доля ответов без источников там, где они обязательны;

доля нарушений политики данных;

доля «опасных» рекомендаций;

стоимость на задачу;

задержка ответа.

Следите за качеством данных эксперимента

Типовые проблемы, которые делают A/B недостоверным:

разные типы задач попали в A и B (например, сложные тикеты случайно сконцентрировались в одной группе);

сотрудники «подсматривают» и копируют ответы из B в A;

параллельно изменили регламенты или базу знаний, и эффект неотделим.

Решите, что делать с человеком в контуре

Если у вас предусмотрено подтверждение оператором, то в A/B вы измеряете эффект системы вместе с этим этапом. Это нормально: бизнесу важен итоговый процесс.

Но тогда полезно логировать дополнительно:

сколько правок сделал человек;

сколько времени заняла проверка;

какие типы ошибок чаще всего исправляют.

Это превращает эксперимент в план улучшений.

Как связать качество и экономику: минимальные пороги

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

Примеры порогов:

в финансах: нулевая толерантность к неверным суммам и реквизитам без валидации;

в поддержке: обязательные источники для критичных инструкций;

в продажах: запрет на обещания условий вне прайса и правил;

в маркетинге: нулевая толерантность к запрещённым утверждениям.

Эти пороги напрямую связаны с темой рисков и контроля из предыдущих статей и хорошо ложатся на рамки управления рисками, например NIST AI Risk Management Framework.

Практический шаблон: как провести экономически корректный пилот за 2–6 недель

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

Зафиксировать baseline за прошлый период (время, ошибки, конверсия, стоимость).

Посчитать модель затрат пилота и прогноз затрат в проде.

Задать минимальные пороги качества и guardrail-метрики.

Сделать офлайн-оценку на контрольных кейсах и исправить критичные провалы.

Запустить shadow mode или rollout на небольшой группе.

Провести A/B-тест или квази-эксперимент, если A/B невозможен.

Принять решение: масштабировать, доработать, остановить.

Итоги

Экономика ИИ считается для процесса, а не для «модели»: нужны baseline, реальные данные об использовании и качество результата.

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

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

Самый надёжный способ доказать эффект — A/B-тест, но перед ним почти всегда нужны офлайн-оценка и безопасный rollout.

Риски, безопасность, право и управление изменениями

ИИ в бизнесе даёт эффект только тогда, когда его можно безопасно встроить в реальные процессы и управлять им как продуктом. В предыдущих статьях курса вы уже прошли путь от выбора сценариев (ценность × реализуемость × риск) к данным и инфраструктуре, инструментам, промптингу как проектированию процессов, внедрению по отделам и экономике (ROI, метрики, эксперименты).

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

Карта рисков ИИ: чем отличается от обычной автоматизации

У ИИ-систем (особенно GenAI/LLM) есть несколько особенностей:

они могут выдавать правдоподобный, но неверный результат

они чувствительны к контексту и формулировкам (промпт, данные, найденные источники)

они добавляют новый класс уязвимостей (prompt injection и связанные атаки)

они часто завязаны на внешних поставщиков (API, модели, облако), что усиливает риски цепочки поставок

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

| Класс риска | Что может пойти не так | Где проявляется | Типовые меры контроля | |---|---|---|---| | Качество и достоверность | «галлюцинации», неверные инструкции, неверные суммы/условия | поддержка, финансы, продажи | RAG с источниками, запрет на выдумывание, человек в контуре, контрольные кейсы | | Безопасность | утечки, компрометация ключей, prompt injection, вредоносные действия через инструменты | интеграции, агенты, боты | классификация данных, RBAC/SSO, allowlist действий, журналирование, фильтры | | Приватность | неправильная обработка персональных данных, лишнее хранение логов | HR, поддержка, продажи | минимизация данных, маскирование, сроки хранения, DPIA/оценка воздействия | | Право и IP | нарушения авторских прав, «чужие» тексты/изображения, спорные лицензии | маркетинг, контент, обучение | политика использования, проверка источников, права на датасеты, human review | | Репутация и этика | токсичные ответы, дискриминация, неприемлемый тон | внешние коммуникации, HR | бренд-гайды, контент-фильтры, аудит, ограничение домена | | Операционные риски | рост стоимости, деградация качества, нестабильность | любой отдел | мониторинг, лимиты, версионирование, rollback, SLO/SLA |

Для системного подхода к управлению рисками можно опираться на рамки:

NIST AI Risk Management Framework

OWASP Top 10 for LLM Applications

!Карта основных классов рисков, чтобы быстро назначать владельцев и контроль

Безопасность: минимальная архитектура, без которой масштабирование опасно

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

Классификация данных и правила передачи

Сценарий из первых статей курса всегда начинается с вопроса: какие данные где обрабатываются.

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

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

Конфиденциальные: строгий RBAC, шифрование, минимизация контекста.

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

Если вы используете внешние API, зафиксируйте в политике:

какие классы данных запрещено отправлять наружу

какие классы данных можно отправлять только после маскирования

какие данные можно передавать при наличии договора и технических мер защиты

Контроль доступа и сегментация

Минимальный набор, который резко снижает риск утечки:

SSO и RBAC для пользователей (и для сервисных аккаунтов)

принцип минимальных прав (least privilege) для коннекторов и инструментов

разделение сред (dev/test/prod) и отдельные ключи доступа

запрет на «общие ключи» в клиентских приложениях и на рабочих станциях

Логи: полезны для качества, опасны для приватности

Логи нужны для метрик, A/B-тестов и расследования инцидентов (это обсуждалось в статье про экономику), но они часто содержат чувствительные данные.

Практичные правила:

маскируйте персональные данные до записи в лог (там, где это возможно)

ограничьте доступ к логам тем же RBAC, что и к данным

установите сроки хранения и процедуру удаления

логируйте версии промптов, базы знаний и моделей, чтобы объяснять поведение системы

Типовые угрозы LLM-приложений и «защитные рельсы»

Ниже — перевод наиболее частых проблем в инженерные и процессные меры контроля (созвучно OWASP Top 10 for LLM Applications).

Prompt injection и утечка данных через контент

Суть: пользователь (или документ в базе знаний) пытается подменить инструкции, заставить систему раскрыть секреты или выполнить запрещённые действия.

Меры, которые работают в бизнесе:

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

запрещайте модели трактовать пользовательский ввод как инструкцию к политике безопасности

для RAG используйте правило: «контент источника не может менять правила ассистента»

добавьте фильтры на секреты и персональные данные перед отправкой во внешние модели

Небезопасные действия через инструменты (function calling, агенты)

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

Минимальные «рельсы»:

allowlist функций: разрешены только строго перечисленные действия

подтверждение пользователем перед критичными операциями

лимиты (частота, сумма, количество объектов)

журналирование: кто инициировал, что изменили, в какой системе

Подмена знаний и устаревшие источники

Суть: модель даёт верный по форме ответ, но на основе устаревшего регламента.

Что делать:

единый источник правды и версионирование документов (связанно со статьёй про данные)

метаданные: дата, продукт, подразделение, уровень доступа

обязательные «Источники» в ответах для сценариев поддержки/политик

Инъекции через вложения и форматы

Суть: вредоносный контент в PDF/HTML/скриптах, попытки «обмануть» OCR или парсер.

Меры:

изоляция обработки файлов (sandbox)

нормализация текста перед передачей в LLM

запрет на выполнение кода из контента

Право и комплаенс: как не превратить пилот в юридический риск

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

Персональные данные и приватность

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

Законность: должна быть понятная цель обработки и основание (контракт, закон, согласие или иной применимый механизм).

Минимизация: передавайте в модель только то, что нужно для конкретной задачи.

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

Для ориентиров по требованиям к персональным данным в ЕС см. текст регламента:

GDPR на EUR-Lex

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

Авторское право и интеллектуальная собственность

Риски в GenAI чаще всего появляются в маркетинге и контенте:

использование материалов без прав (датасеты, изображения, тексты)

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

нарушение лицензий при использовании моделей/инструментов

Практичная политика для компании:

что можно генерировать без проверки

что можно генерировать только с редактором/юристом в контуре

какие источники и ассеты разрешено использовать (стоковые библиотеки, внутренние материалы)

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

Для общего понимания тематики IP можно использовать материалы ВОИС:

WIPO: Artificial Intelligence

Регулирование ИИ и отраслевые требования

Во многих компаниях требования будут определяться не «законом об ИИ» как таковым, а отраслевыми нормами (финансы, медицина, критическая инфраструктура) и внутренним контролем.

Если вы работаете в ЕС или с клиентами из ЕС, полезно иметь представление о риск-ориентированном подходе:

EU AI Act на EUR-Lex

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

Управление ИИ как продукта: политика, роли, артефакты

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

Роли и ответственность (минимальный набор)

| Роль | За что отвечает | Что должно быть на выходе | |---|---|---| | Владелец процесса | эффект, внедрение в работу, метрики | baseline, KPI, план rollout | | Владелец данных | источники, качество, права доступа | карта данных, источник правды, правила обновления | | Техлид/архитектор | интеграции, надежность, контроль изменений | архитектура, SLO, план масштабирования | | Безопасность/комплаенс | политика данных, аудит, требования к поставщикам | классификация данных, требования к логам, чеклист угроз | | Юрист | договоры, IP, персональные данные | условия использования, DPIA/оценка рисков, оговорки | | Владелец качества | контрольные кейсы, тесты, пороги | набор кейсов, критерии критичных ошибок |

Документация, которая реально помогает

Нужны короткие, но обязательные документы:

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

политика данных для ИИ: что можно/нельзя отправлять, как маскировать

журнал версий: промпт, модель, база знаний, интеграции

набор контрольных кейсов и критерии «критичной ошибки»

план реагирования на инциденты (включая «кнопку выключения»)

Управление изменениями: как сделать так, чтобы ИИ начали использовать

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

Почему люди сопротивляются (и как это снять)

Частые причины:

страх контроля и сокращений

рост когнитивной нагрузки (нужно проверять ответы)

отсутствие времени учиться

непонятно, кто отвечает за ошибку ИИ

Что помогает:

правила ответственности: где человек обязан проверить и что считается «ошибкой системы»

обучение на реальных кейсах команды (а не общие лекции)

встроенность в рабочие инструменты (CRM, Service Desk), а не отдельный «чат»

метрики, отражающие пользу для сотрудника (время, рутина), а не только для руководства

Rollout без шока для бизнеса

Хороший стандарт внедрения:

офлайн-тестирование на контрольных кейсах (20–50 примеров)

shadow mode: ИИ считает, но не влияет на клиента/учёт

постепенный rollout: 5% → 20% → 50% → 100%

A/B-тест или квази-эксперимент, если возможно (см. статью про экономику)

На каждом шаге проверяйте guardrail-метрики:

критичные ошибки и инциденты безопасности

доля ответов без источников там, где источники обязательны

задержка ответа и стоимость на задачу

доля использования и доля принятых результатов

!Пошаговая схема внедрения с возможностью отката

Инциденты и непрерывное улучшение: как не потерять контроль

ИИ-система со временем меняет поведение даже без «дообучения»: обновляются документы, меняются процессы, меняется распределение запросов. Поэтому нужен цикл управления.

Минимальный цикл:

сбор обратной связи в интерфейсе (принял/исправил/отклонил + причина)

регулярный аудит выборки (например, 50–100 кейсов в неделю на команду качества)

анализ инцидентов и обновление контрольных кейсов

изменение промптов/базы знаний через версионирование и релизы

быстрый rollback, если guardrail-метрики ухудшились

Чеклист готовности: перед пилотом и перед масштабированием

Перед пилотом

описан сценарий, домен ограничен, есть метрика и baseline

составлена карта данных и уровни доступа

определено, какие данные могут уходить во внешние API

есть человек в контуре там, где цена ошибки высокая

подготовлены контрольные кейсы и критерии критичной ошибки

включено логирование версий (промпт/модель/база знаний)

Перед масштабированием

пройдены shadow mode и постепенный rollout без роста инцидентов

есть план реагирования на инциденты и ответственные

определены сроки хранения логов и политика маскирования

согласованы правовые вопросы: персональные данные, договор с поставщиком, IP-политика

подтверждён ROI или понятная экономика на реальных данных использования

Итоги

Риски ИИ лежат в шести зонах: качество, безопасность, приватность, право/IP, репутация, операционные риски.

Безопасность строится вокруг данных, доступов, интеграций и логов; для LLM добавляются специфические угрозы вроде prompt injection.

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

Управление изменениями определяет ROI не меньше, чем качество модели: rollout, обучение, ответственность и guardrail-метрики.