Короткий ответ: ИИ в корпоративном портале лучше начинать не с «чата обо всём», а с одного процесса: поиска регламента, подготовки ответа, сводки заявки или подсказки сотруднику. Нужны источник истины, модель прав, фильтрация документов, понятный fallback и проверка ответов. Если подключить модель к общей папке без этих ограничений, портал получит не корпоративную память, а новый канал утечки и путаницы.
Корпоративный портал полезен ИИ только тогда, когда в нём уже можно определить пользователя, роль, объект и действие. Поэтому внедрение начинается с архитектуры доступа и качества данных, а не с выбора красивого интерфейса. Ниже — схема MVP, которую можно обсуждать с бизнесом и технической командой.
1. Выберите процесс, где ответ можно проверить
Первая задача должна иметь понятную пользу и ограниченный риск. Поиск ответа по утверждённым инструкциям обычно проще контролировать, чем автономное изменение кадровых или финансовых данных. На старте особенно важен маршрут эскалации: пользователь должен знать, когда ответ ИИ нужно проверить человеком.
| Сценарий | Польза | Ограничение для MVP |
|---|---|---|
| Поиск по регламентам | меньше времени на ручной поиск | ответ со ссылкой на источник, без действий |
| Сводка заявки | быстрее передача между отделами | только поля и документы заявки |
| Подсказка оператору | единый стиль и быстрый черновик | отправка после ручного подтверждения |
| Навигация по порталу | сотрудник быстрее находит раздел | без доступа к закрытым объектам |
| Извлечение реквизитов | меньше ручного ввода | проверка полей до записи в систему |
Практический шаг: выберите 20–50 обезличенных примеров и попросите владельца процесса оценить полезность ответа. Если невозможно договориться, что считается правильным результатом, рано строить production-функцию.
CTA: Paladin Engineering может помочь провести discovery для внутреннего портала: выделить один сценарий, роли, данные и границы MVP через разработку веб-систем.
2. Разделите портал, поиск и модель
Надёжная схема не даёт модели прямой доступ ко всем таблицам и файлам. Портал аутентифицирует пользователя, orchestration-слой проверяет права и формирует контекст, retrieval находит допустимые фрагменты, а модель формирует ответ по этому контексту. Результат возвращается с источниками и правилами отказа.
| Слой | Ответственность | Контрольный вопрос |
|---|---|---|
| Портал и identity | кто пользователь и какая у него роль | можно ли доказать права на объект? |
| API/orchestrator | какой сценарий запускаем и что разрешено | есть ли единая точка политики? |
| Retrieval | какие документы попадают в контекст | фильтруется ли доступ до поиска? |
| Модель | как сформировать ответ или предложение | может ли она выполнить запрещённую инструкцию? |
| Журнал и оценка | что произошло и насколько полезен ответ | можно ли расследовать и улучшить сценарий? |
Microsoft описывает RAG как связку поиска с языковой моделью и отдельно подчёркивает document-level access control. В другой рекомендации Microsoft извлечённый текст рассматривается как недоверенный ввод: документы могут содержать инструкции, которые нельзя исполнять. Для проекта это означает, что фильтрация прав и защита от indirect prompt injection должны быть частью дизайна.
3. Подготовьте документы до подключения ИИ
ИИ не исправляет хаос в регламентах. Если в папках лежат устаревшие версии, дубли и файлы без владельца, поиск будет возвращать правдоподобные, но неоднозначные ответы. Перед индексацией определите статус документа, дату актуальности, подразделение, уровень доступа и связь с заменяемой версией.
- назначить владельца каждого набора знаний;
- убрать дубли и явно пометить архив;
- добавить метаданные: тип документа, подразделение, дата, уровень доступа;
- описать, как быстро документ появляется в поиске после обновления;
- разделить публичное, внутреннее, конфиденциальное и персональное;
- подготовить эталонные вопросы для проверки поиска и ответа;
4. Спроектируйте права до промпта
Роль сотрудника в портале не всегда равна праву видеть каждый найденный фрагмент. Нужны правила на уровне пользователя, подразделения, объекта и документа. В многослойной системе лучше ограничить выборку до передачи контекста модели, а не надеяться, что модель сама «не процитирует» запрещённый файл.
| Риск | Пример | Защита |
|---|---|---|
| Слишком широкий поиск | менеджер видит HR-документ | security trimming до формирования контекста |
| Устаревший источник | ответ основан на старом регламенте | версия, дата и владелец документа |
| Prompt injection | документ содержит инструкцию для модели | контент трактуется как данные, не как команда |
| Запись без подтверждения | ИИ меняет статус заявки | отдельный tool, валидация и ручное подтверждение |
| Нет следа решения | непонятно, откуда взялся ответ | лог источников, версии и request ID |
NIST AI RMF предлагает учитывать trustworthy-характеристики на этапах до проектирования, разработки, внедрения и тестирования. В корпоративном портале это переводится в конкретные артефакты: матрицу доступа, список допустимых действий, тесты негативных сценариев и владельца инцидентов.
5. Соберите безопасный MVP
Первую версию разумно ограничить ответами по нескольким коллекциям документов, обязательными ссылками на источники и кнопкой «не уверен / передать специалисту». Не подключайте сразу все отделы, все форматы и автоматические изменения в системах. Узкий контур проще проверить и откатить.
| В MVP | Отложить до доказанной пользы |
|---|---|
| один процесс и одна роль | универсальный помощник для всей компании |
| ограниченный набор источников | автоматическая индексация любых файлов |
| ответ с цитатой и датой | ответ без объяснения происхождения |
| ручное подтверждение действий | автономная запись в критические системы |
| метрики качества и отказа | широкое обещание экономии без измерений |
Проверяйте не только долю полезных ответов. Смотрите на отказ, устаревшие источники, раскрытие лишних данных, задержку, стоимость запроса и долю ответов, которые сотрудник исправил. Эти метрики помогают решить, расширять ли сценарий или сначала улучшать данные.
6. Как принять работу и поддерживать систему
Приёмка ИИ-функции должна включать обычные, сложные и запрещённые вопросы. Проверьте разные роли, отсутствие доступа, пустой результат, конфликтующие документы, prompt injection в файле, недоступность поискового индекса и повтор запроса после сбоя.
- ответ содержит источник, который пользователь вправе открыть;
- закрытый документ не попадает ни в ответ, ни в подсказку;
- модель признаёт отсутствие достаточных данных;
- действие в портале требует отдельной проверки и права;
- обновление документа меняет результат предсказуемым образом;
- журнал не хранит лишние персональные данные и доступен для расследования;
- назначен владелец качества, данных и технической эксплуатации;
Как Paladin Engineering может помочь
Paladin Engineering может помочь спроектировать ИИ-функцию внутри корпоративного портала: от карты ролей и источников до retrieval, интерфейса, тестов и запуска. Состав первой версии определяется процессом и рисками компании, а не модным названием архитектуры.
CTA: соберите список ролей, 2–3 коллекции документов и один повторяющийся вопрос сотрудника. С этими вводными можно предметно обсудить discovery и реализацию через контакты Paladin Engineering.
FAQ: ИИ в корпоративном портале
Нужно ли сразу строить RAG?
Если ответы должны опираться на часто меняющиеся внутренние документы, retrieval может быть подходящим паттерном. Но сначала нужно проверить качество источников, права и сценарий.
Можно ли дать ИИ доступ ко всей базе?
Такой подход опасен. Доступ следует фильтровать по пользователю, роли, объекту и документу до передачи контекста модели.
Должен ли ИИ сам менять данные?
Для первой версии обычно безопаснее черновик и ручное подтверждение. Автоматическое действие требует отдельного права, валидации, журнала и сценария отката.
Как измерить пользу?
Сравните время поиска, долю полезных ответов, исправления человеком, отказы, задержку, стоимость и инциденты до и после пилота.
Что делать с устаревшими документами?
Назначить владельца, версию и дату актуальности, отделить архив и задать правило обновления индекса.
Комментарии