Коротко

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

Первая ошибка — подключить “все документы” и надеяться, что модель разберётся. Не разберётся. Корпоративному ассистенту нужны владельцы источников, актуальность, metadata, права доступа и поиск, который умеет находить и смысл, и точные термины. То есть нужен RAG, но вместе с полнотекстовым поиском, фильтрами, reranking, ссылками на источники и честными отказами.

Карта источников для внутреннего ChatGPT: политики, CRM, HR, юридические документы, поддержка, продукт и владельцы
Начинать стоит не с выбора модели, а с карты источников.

Безопасность нельзя прикрутить в конце. В документации Microsoft про Copilot Search отдельно сказано, что корпоративный поиск должен уважать существующие права доступа. OpenAI в материалах для бизнеса тоже отделяет данные клиентов от обучения моделей по умолчанию. Это полезные обещания поставщиков, но они не заменяют собственную архитектуру: в приложении всё равно нужны identity, authorization, audit logs, retention и проверка того, что попадает в prompt.

Вопрос не в том, “можно ли сделать свой ChatGPT”. Можно. Вопрос лучше поставить иначе: какую работу сотрудники смогут ему доверить? Искать регламенты — один уровень. Готовить черновик ответа — другой. Создавать заявку, менять CRM или отправлять сообщение — уже зона подтверждений, журналов и evals.

Начните с задачи, а не с чата

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

Например:

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

У каждого процесса свой риск. HR требует аккуратных ролей доступа и осторожных формулировок. Продажам нужны свежие цены и ограничения на обещания клиенту. Поддержке нужны источники и эскалация. Юристам важно, чтобы ассистент отличал “объясни пункт” от “одобри договор”.

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

Качество начинается с владельцев источников

До retrieval нужна инвентаризация источников. Не красивая enterprise-схема. Обычной таблицы хватит:

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

Так ловится типовая проблема: ассистент отвечает по старому PDF, потому что никто не сказал системе, что свежий Google Doc его заменил. Или цитирует черновик, потому что черновики и утверждённые политики лежат в одной папке. Или смешивает публичный sales deck с внутренними правилами маржи.

Цикл управления источниками: владельцы, даты проверки, изменения политик, загрузка в индекс и обратная связь по качеству
Управление источниками — это цикл: владельцы, даты проверки, ingestion, feedback и исправления.

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

Роли доступа должны сработать до модели

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

Не стоит рассчитывать, что модель “сохранит тайну”, если секретный текст уже попал в prompt. Если данные по зарплатам, юридические заключения, материалы совета директоров или PII клиента оказались в context window не того сотрудника, система уже ошиблась, даже если финальный ответ звучит безобидно.

Граница доступа: identity пользователя фильтрует источники до retrieval и генерации ответа
Права должны фильтровать источники до retrieval, а не после того, как модель уже увидела текст.

Практичная модель ролей обычно включает:

  • identity сотрудника из SSO;
  • отдел и команду;
  • права на документ в исходной системе;
  • отдельные метки чувствительности для legal, HR, finance и leadership;
  • временный доступ для проектов;
  • отказ, который объясняет проблему, но не раскрывает скрытое содержимое.

Microsoft для Copilot Search описывает тот же принцип: возвращать только то, к чему у пользователя уже есть доступ. Если вы строите свой ассистент, эта ответственность переходит к вам.

RAG нужен, но одного RAG мало

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

Но RAG — это не один компонент. В production это цепочка:

  1. забрать источники;
  2. нормализовать текст, таблицы и metadata;
  3. сохранить версии и даты;
  4. нарезать документы вокруг реальных вопросов;
  5. найти кандидатов;
  6. переупорядочить их;
  7. собрать контекст;
  8. ответить со ссылками;
  9. отказаться, если данных не хватает.
Retrieval stack внутреннего ChatGPT: ingestion, metadata, BM25, vector search, reranking, контекст, цитаты и отказы
RAG становится надёжным, когда ingestion, metadata, search, reranking и отказы работают вместе.

Подробно это разобрано в статье Как построить хороший RAG. Для внутреннего ассистента вывод простой: vector database сама по себе не превращает документы в систему знаний.

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

Сотрудники не задают аккуратные benchmark-вопросы. Они вставляют куски переписки, используют сокращения, смешивают языки, спрашивают “где та форма, которую мы брали в прошлом квартале?” или ищут по номеру договора.

Vector search помогает со смыслом. Full-text search помогает с точными словами. Metadata-фильтры сужают выдачу по отделу, дате, типу документа, продукту, клиенту, региону или роли. Reranking помогает выбрать лучшие доказательства после того, как несколько поисковых дорожек вернули кандидатов.

Hybrid search почти всегда нужен, если в базе есть:

  • номера счетов, SKU, VIN, contract IDs, ticket IDs;
  • названия продуктов, кампаний, филиалов и клиентов;
  • таблицы и исключения из правил;
  • двуязычные или многоязычные материалы;
  • старые и новые версии похожих документов;
  • внутренние сокращения.
Hybrid search по корпоративным знаниям: exact search, semantic search, фильтры и reranking
Hybrid search честнее, чем делать вид, будто все вопросы сводятся к семантической похожести.

Здесь полезны исследования по оценке RAG, например Ragas: они разделяют качество retrieval и качество финального ответа. Если источник найден неверно, правка тона ответа систему не спасёт.

Ответу нужны источники, отказы и границы уверенности

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

Для внутреннего применения хороший формат ответа обычно такой:

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

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

Отказ должен помогать: “Я не нашёл утверждённую travel policy для подрядчиков. Есть политика для сотрудников от марта 2026 года, но подрядчики там не упомянуты. Уточните у Finance или добавьте правило для подрядчиков в базу источников.” Это лучше, чем пустое “я не могу ответить”.

Логи превращают чат в систему, которая учится

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

Audit log внутреннего ChatGPT: вопросы, найденные источники, статус ответа, feedback и review владельца
В логах должны быть вопрос, найденные источники, путь ответа, feedback и статус разбора.

Полезные логи сохраняют:

  • роль пользователя, не обязательно все персональные детали;
  • запрос и язык;
  • ID и версии найденных источников;
  • финальный ответ;
  • причину отказа;
  • вызванные tools;
  • задержку и модель;
  • feedback и оспаривание ответа;
  • была ли эскалация.

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

OWASP Top 10 for LLM Applications 2025 отдельно выделяет prompt injection и sensitive information disclosure. Для внутреннего ассистента логи входят в эту поверхность риска, а не просто помогают наблюдать систему.

Безопасность и governance — часть продукта

Модель безопасности должна быть видна в плане продукта. NIST AI Risk Management Framework полезен тем, что описывает риск AI как постоянную работу: govern, map, measure, manage. NIST Generative AI Profile добавляет более конкретные риски для генеративных систем.

Для внутреннего ChatGPT governance означает:

  • зафиксированных владельцев источников;
  • утверждённые use cases;
  • классификацию данных;
  • ревизию доступов;
  • историю изменений prompt и модели;
  • процесс инцидентов;
  • правила хранения логов;
  • review поставщика и deployment;
  • release gates для рискованных изменений.

Это не значит, что каждой компании нужен огромный AI-комитет. Но кто-то должен уметь ответить на скучный вопрос: кто имеет право менять ассистента и как мы узнаём, что изменение не сломало ответы по зарплатам, юристам, продажам или поддержке?

Если ассистент касается клиентов, регулируемых данных или решений по сотрудникам, governance становится строже. EU AI Act тоже двигает рынок к более понятной документации и классификации рисков, особенно для high-risk use cases. Даже вне ЕС направление видно: недокументированный AI внутри бизнес-процессов будет плохо стареть.

Evals показывают, становится ли ассистент лучше

Внутреннему ассистенту нужны evals до широкого запуска.

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

Eval board для внутреннего ChatGPT: source recall, access control, faithfulness, refusals и tool-use checks
Хороший eval-набор отдельно проверяет retrieval, верность ответа источникам, доступы, отказы и tools.

Для RAG проверяйте:

  • нашёл ли retrieval правильный источник;
  • не достал ли источник, закрытый для пользователя;
  • остался ли ответ внутри доказательств;
  • подтверждают ли ссылки конкретные тезисы;
  • отказался ли ассистент, когда данных не хватает.

Для действий проверяйте:

  • выбрал ли он правильный tool;
  • передал ли безопасные аргументы;
  • попросил ли подтверждение;
  • оставил ли понятный audit trail;
  • остановился ли, когда обязательных данных нет.

Вот где evals для AI-проектов становятся практикой, а не украшением. Они позволяют менять prompts, модели, retrieval и tools без гадания на ощущениях.

Границы действий нужно назвать вслух

Внутренний ассистент может двигаться по уровням полномочий:

  1. ответить по утверждённым источникам;
  2. кратко пересказать документ;
  3. подготовить черновик сообщения или заявки;
  4. подготовить изменение в CRM или HRIS;
  5. создать задачу после подтверждения;
  6. действовать автоматически в низкорисковых случаях.
Лестница полномочий внутреннего ассистента: ответ, черновик, подтверждение и ограниченная автоматизация
Автономность должна расти от доказательств, а не от энтузиазма.

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

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

Разницу между chat, workflow и agent подробнее разбирает статья AI-агент, chatbot или workflow: в чём разница.

Эксплуатация после запуска

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

В эксплуатации нужны:

  • еженедельный разбор плохих и оспоренных ответов;
  • проверка свежести источников;
  • ревизия access drift;
  • журнал изменений prompt и retrieval;
  • мониторинг стоимости и задержки;
  • routing моделей для простых и сложных запросов;
  • порядок обработки инцидентов;
  • процесс добавления новых отделов и источников.

У ассистента должен быть понятный feedback. Например: “не тот источник”, “устаревший ответ”, “проблема доступа”, “полезно”. Начать можно очень просто. Главное, чтобы feedback кто-то читал, а владельцы источников могли действовать.

Хороший внутренний ChatGPT — это не модель, которая притворяется коллегой. Это управляемая retrieval-and-action система с интерфейсом чата.

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

Это звучит менее магически, чем “ChatGPT для всей компании”. Зато именно такой версией сотрудники смогут пользоваться каждый день.