Практика внедрения
Паспорт ИИ-функции: что зафиксировать до корпоративного пилота
Шаблон паспорта корпоративной ИИ-функции: цель, роли, источники, ограничения, формат результата и критерии приёмки до начала пилота.
До настройки корпоративного ИИ опишите одну функцию на одной странице: кто её запускает, какие данные она использует, что выдаёт, где останавливается и как команда принимает результат. Такой паспорт превращает пожелание «добавить ИИ» в проверяемое задание для владельца процесса, ИТ, ИБ и команды внедрения.
Что такое паспорт ИИ-функции
Паспорт ИИ-функции — это краткая спецификация одного рабочего сценария. Он не заменяет архитектурную документацию, модель угроз или регламент обработки данных. Его задача — до пилота согласовать границы функции и критерии пригодного результата.
Подход согласуется с логикой NIST AI Risk Management Framework: контекст и риски нужно определить, измерять и управлять ими на протяжении жизненного цикла системы. Практические действия NIST группирует вокруг функций Govern, Map, Measure и Manage. Страницы NIST проверены 18 сентября 2026 года.
Семь полей, которые нужно заполнить
1. Рабочая задача и владелец
Опишите не технологию, а результат процесса: например, «подготовить проект протокола встречи в течение 15 минут после получения расшифровки». Назначьте владельца, который определяет пригодность результата и принимает изменения функции.
2. Пользователи и роли
Перечислите роли, которым функция доступна, и тех, кто проверяет результат. Если сотруднику не нужен свободный запрос к модели, это следует указать прямо. В Тау Хаб рабочее место можно настроить с фиксированным согласованным набором ИИ-функций без свободного чата.
3. Разрешённые входы и источники
Зафиксируйте документы, системы и типы данных, которые функция может использовать. Для каждого источника укажите владельца, порядок обновления и действие при конфликте версий. Формулировка «использовать корпоративные данные» слишком широка для приёмки.
4. Формат результата
Определите обязательные разделы, допустимую длину и способ передачи результата. Для протокола это могут быть решения, ответственные, сроки и открытые вопросы. Структурированный результат проще сравнивать на одинаковых задачах, чем свободный ответ.
5. Ограничения и остановка
Перечислите действия, которые функция не выполняет: не отправляет сообщение без подтверждения, не использует источник вне списка, не заполняет отсутствующий факт догадкой. Укажите, когда она должна остановиться и передать вопрос человеку.
6. Проверка человеком
Запишите, кто подтверждает результат, что считается существенной ошибкой и какие действия запрещены до подтверждения. Человек должен видеть достаточно контекста, чтобы проверить вывод, а не только готовый текст.
7. Метрики пилота
Снимите исходную линию до запуска и сравнивайте одинаковые типы задач. Минимальный набор: время до пригодного результата, доля результатов с существенными правками, число завершённых операций и расход на LLM. Нулевое число ошибок на маленькой выборке не следует превращать в обещание для всего процесса.
Пример паспорта для протокола встречи
| Поле | Пример записи |
|---|---|
| Задача | Подготовить проект протокола после встречи |
| Пользователь | Руководитель проекта |
| Вход | Разрешённая расшифровка и карточка проекта |
| Результат | Решения, ответственные, сроки, открытые вопросы |
| Ограничения | Не назначать ответственного, если он не назван; не отправлять протокол автоматически |
| Проверка | Руководитель подтверждает факты и формулировки до публикации |
| Метрики | Время обработки, доля существенных правок, полнота решений и поручений |
Это пример структуры, а не описание доказанного клиентского результата. Для каждой организации список данных, ролей и критериев будет своим.
Как провести приёмку
- Подготовьте типичные, пограничные и заведомо недостаточные входные данные.
- Запустите функцию под каждой разрешённой ролью и под ролью без доступа.
- Проверьте состав источников, формат результата и срабатывание ограничений.
- Убедитесь, что недостаток данных приводит к остановке или запросу уточнения, а не к выдуманному факту.
- Сохраните вход, результат, правки проверяющего и расход на модель.
- Исправьте паспорт или конфигурацию и повторите тот же набор тестов.
Приёмка заканчивается не демонстрацией удачного ответа, а воспроизводимым прохождением согласованных сценариев.
Что отдельно решить для Тау Хаб
Размещение платформы и подключение модели — разные решения. Тау Хаб может размещаться в облаке или в контуре заказчика; LLM подключается ключом заказчика либо через прокси Тау. Использование LLM всегда оплачивается отдельно от платформы и внедрения. Выбранную комбинацию, маршрут данных и ответственных внесите в паспорт или связанную архитектурную схему.
Практическое руководство по этим вариантам и бюджету опубликовано в статье «Как подготовить управляемые ИИ-рабочие места для команды».
Следующий шаг
Выберите одну частую операцию и заполните семь полей паспорта до начала настройки. Если владельцы процесса, ИТ и ИБ не могут одинаково прочитать будущий результат и условия остановки, функция ещё не готова к пилоту. Когда договорённость зафиксирована, Тау Хаб можно настроить под ограниченный сценарий и проверить на одинаковом наборе задач.