ТЗ на корпоративную ИИ-платформу: структура требований

Зачем нужно ТЗ и что оно должно зафиксировать

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

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

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

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

В ТЗ принимают решения о целях, метриках, ограничениях и приемке. Детали проектирования обычно оставляют команде реализации: конкретные модели и поставщики, архитектура развертывания, инструменты мониторинга и способы интеграции.

Цели, границы и пользователи

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

Примеры: «не менее 85% точности на тестовом наборе из N кейсов», «время ответа до 3 секунд для 95% запросов», «покрыть 2 подразделения и 5 типовых сценариев за 3 месяца». Так ТЗ становится проверяемым и снижает число споров.

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

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

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

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

Чтобы ТЗ не превратилось в набор пожеланий, заранее зафиксируйте, кто принимает решения и кто отвечает за результат. Начните со стейкхолдеров: бизнес-владелец (за эффект), ИТ (за интеграции и инфраструктуру), ИБ/комплаенс (за риски и доступы), владелец данных (за источники и качество), юридический блок (за договорные ограничения), служба поддержки (за эксплуатацию). Если участвует подрядчик или интегратор, его роль тоже должна быть описана.

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

RACI по ключевым задачам

Сделайте простую RACI-матрицу (Responsible, Accountable, Consulted, Informed) по темам, где чаще всего возникают провалы. Чаще всего это:

• Данные (подключение источников, качество, права): R - владелец данных, A - бизнес-владелец, C - ИТ/ИБ, I - пользователи
• Безопасность и доступы: R - ИБ, A - CISO/руководитель ИБ, C - ИТ/юристы, I - бизнес
• Эксплуатация и SLA: R - ИТ/поддержка, A - ИТ-директор, C - подрядчик, I - бизнес
• Качество модели и метрики: R - команда DS/ML, A - владелец продукта, C - бизнес-эксперты, I - ИТ
• Изменения и релизы: R - менеджер продукта, A - комитет по изменениям, C - ИТ/ИБ, I - все затронутые

Управление изменениями и версионирование

Опишите порядок правок ТЗ: как подается запрос на изменение, кто оценивает влияние (сроки, бюджет, риски), кто утверждает, и как ведется версия документа. Базовый минимум: номер версии, дата, автор, список изменений, статус (черновик/на согласовании/утверждено).

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

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

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

Качество описывайте измеримо. Для каждой задачи зафиксируйте метрики и минимальные пороги, а также цену ошибки. Для классификации это precision/recall и доля «неуверенных» ответов, для поиска - доля найденных релевантных материалов в топ-N, для ассистента - доля корректных ответов на контрольном наборе и частота галлюцинаций. Обязательно разделите ошибки на критичные (например, неверная рекомендация по регламенту) и допустимые при условии пометки «нужно уточнение».

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

Производительность и стоимость вычислений фиксируются так же жестко, как качество. Обычно в ТЗ закрепляют целевое время ответа (например, P95 не более X секунд) для чата и поиска, максимальную нагрузку в пиковые часы, ограничения по CPU/GPU и бюджету инференса, требования к стабильности (доля ошибок 5xx, поведение при пике), а также задержку обновления данных в поиске.

Нужна и политика обновлений: как часто переобучать, на каких условиях выпускать новую версию и кто подписывает релиз. Удобная практика - «ворота качества»: новая модель идет в прод только если проходит тестовый набор, не ухудшает ключевые метрики и имеет план отката. В чувствительных сценариях (банк, госорган) релиз обычно утверждают владелец процесса, служба безопасности и команда эксплуатации.

Данные: источники, качество, разметка и хранение

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

Сначала перечислите источники: CRM/ERP, документооборот, Service Desk, почта, базы знаний, файлы, датчики, колл-центр. Для каждого источника укажите владельца (кто разрешает доступ и подтверждает смысл полей), формат (таблицы, текст, PDF, аудио), объем и частоту обновления (онлайн, раз в час, раз в сутки). Отдельно зафиксируйте ограничения: что нельзя выгружать, какие поля «грязные», какие справочники эталонные.

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

Разметка почти всегда становится узким местом. Закрепите, кто размечает (эксперты, операторы, подрядчик), где хранится инструкция, как решаются спорные случаи и как проверяется качество (двойная разметка части данных, выборочная проверка, метрика согласия).

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

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

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

Интеграции: как ИИ встраивается в процессы

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

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

Как подключаться и когда запускать

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

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

Надежность, ошибки и наблюдаемость

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

Пропишите форматы обмена (JSON, XML, CSV), схемы полей, кодировки, версионирование и маскирование чувствительных данных. Для логов зафиксируйте, что именно пишем: идентификатор запроса, источник, время, статус, версия модели, код ошибки. Не сохраняйте лишнее содержимое (например, полный текст письма), если это запрещено политиками.

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

Безопасность и соответствие требованиям

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

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

Права доступа задавайте ролями, а не «всем сотрудникам». В ТЗ обычно закрепляют роли (пользователь, администратор, владелец данных, MLOps, аудитор), MFA для привилегированных операций, принцип наименьших привилегий и раздельные доступы к данным, моделям и журналам, а также сервисные аккаунты для интеграций без «общих паролей».

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

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

В конце добавьте требования по соответствию: внутренние политики ИБ, требования регуляторов, процедуры реагирования на инциденты и порядок регулярных проверок.

Эксплуатация: MLOps, мониторинг, поддержка и SLA

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

Среды и выпуск изменений

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

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

Мониторинг, инциденты и SLA

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

SLA и поддержку описывайте через понятные параметры: часы работы и уровни поддержки (1-я, 2-я, 3-я линия), время реакции и восстановления для критичных и некритичных сбоев, правила эскалации и владелец решения, база знаний и типовые инструкции.

Отдельно закрепите резервное копирование и восстановление: что бэкапится (данные, модели, конфигурации), как часто, где хранится, какой RPO/RTO и кто отвечает за план действий.

Если ИИ-сервис работает в контуре организации на собственных серверах (например, в стойках дата-центра), заранее определите, кто обеспечивает круглосуточное реагирование и как тестируется восстановление. Здесь полезны 24/7 процессы и сервисная сеть системных интеграторов уровня GSE.kz, но требования все равно должны быть прописаны в ТЗ.

Пошаговая структура ТЗ: как собрать требования без пробелов

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

Практичный порядок:

1. Соберите сценарии и примеры запросов. Попросите каждого типа пользователя принести 10-20 реальных формулировок (как они пишут в письмах, чатах, заявках). Укажите, что считается «правильным ответом» и какой формат нужен (текст, таблица, ссылка на документ, краткое резюме).

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

3. Выберите метрики и приемочные пороги. Метрики должны быть понятны бизнесу: точность, полнота, доля «неверных рекомендаций», время ответа, доля запросов, которые уходят на ручную проверку. Сразу договоритесь о порогах и о том, как измеряем (на каком наборе данных и в каком периоде).

4. Согласуйте интеграции и контуры безопасности. Зафиксируйте, где ИИ будет жить (внутренний контур, выделенный сегмент), как проходит аутентификация, что логируем, какие данные нельзя отправлять в модель, кто имеет доступ к админ-функциям.

5. Опишите эксплуатацию и обучение, затем сделайте финальную проверку. Нужны роли поддержки, мониторинг качества, процесс обновления модели, окна изменений, SLA и план обучения пользователей (короткие правила, примеры, типовые ошибки).

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

Обучение пользователей и правила работы с ИИ

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

Минимальный пакет обучения

Обычно хватает коротких сессий по 30-60 минут для каждой роли и материалов, которые можно открыть прямо во время работы. Минимум, который удобно закрепить в ТЗ: инструкция по типовым задачам (5-10 частых сценариев), шаблоны запросов и примеры хороших формулировок, памятка «что делать, если ответ сомнительный» и куда эскалировать, вводный курс для новых сотрудников (включая тест или контрольный кейс), календарь обновлений обучения после изменений модели или правил.

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

Правила использования и ответственность

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

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

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

Пример сценария: от пилота до промышленной работы

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

Для данных обычно нужны история тикетов за 6-24 месяца, база знаний, шаблоны ответов, справочники (услуги, подразделения, SLA). Доступ ограничивают по принципу минимально необходимого: ассистент видит только те поля тикета, которые нужны для ответа, а персональные данные (телефон, ИИН, адрес) скрываются или маскируются. Отдельно фиксируют, где данные хранятся и кто имеет право выгружать датасеты.

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

Метрики приемки разумно разделить на пилот и промышленный режим. Для пилота (4-8 недель) обычно смотрят долю предложенных ответов, принятых оператором, снижение среднего времени ответа и точность маршрутизации по категориям. Для промышленной работы важны стабильность качества по месяцам, соблюдение SLA, доля обращений без эскалации, контроль ошибок и инцидентов безопасности.

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

Приемка, частые ошибки, чек-лист и следующие шаги

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

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

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

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

Перед согласованием пробегитесь по короткому чек-листу: цели и границы (что входит и что точно не делаем), данные (источники, права, качество, разметка, хранение), интеграции (какие системы, какие API, что при сбоях), безопасность (доступы, аудит, соответствие требованиям), эксплуатация (мониторинг, обновления, SLA, план отката).

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