Внутренние AI-системы vs ChatGPT: что безопаснее для корпоративных данных

Почти каждая крупная компания в Москве в 2026 году уже сталкивалась с этим вопросом — даже если не обсуждала его публично:

«Можем ли мы использовать ChatGPT и другие публичные AI-сервисы в работе — и насколько это безопасно?»

С одной стороны — удобство, скорость, доступность. С другой — данные, ответственность, требования регуляторов и собственная служба ИБ.

Для банков, финтеха, медицинских и юридических компаний это не философский вопрос. Это вопрос рисков, compliance и формальной ответственности. И в 2026 году большинство компаний приходят к одному выводу: публичный AI и корпоративные данные — несовместимы по умолчанию. Не потому что публичный AI «плох», а потому что он не проектировался как корпоративная инфраструктура.

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

Контекст: AI в B2B-бизнесе: где он экономит деньги, где заменяет сотрудников, а где остаётся хайпом — где AI экономит бизнесу деньги; ФЗ-152 для SaaS-продуктов в 2026: что реально требует архитектура (а не только бумажки) — что 152-ФЗ требует от архитектуры.

01 · Почему ChatGPT так быстро проник в корпоративную среду

ChatGPT и аналогичные публичные сервисы стали популярны по понятным причинам:

• не требуют внедрения — открыл вкладку и работаешь;
• не требуют инфраструктуры — всё работает на стороне провайдера;
• дают быстрый результат «здесь и сейчас»;
• не требуют согласований с IT;
• доступны через личные аккаунты без участия компании.

Сотрудники используют их для написания текстов, анализа информации, помощи в разработке, подготовки документов, перевода переписки, суммаризации длинных писем и контрактов. Часто — без согласования с IT и службой безопасности.

Именно здесь начинается проблема. Не в технологии, а в неконтролируемом потоке корпоративных данных наружу. Менеджер копирует контракт клиента в ChatGPT, чтобы тот сделал резюме. Разработчик копирует фрагмент проприетарного кода, чтобы получить помощь с багом. Аналитик загружает Excel с финансовой информацией. С точки зрения сотрудника — это «помощь в работе». С точки зрения безопасности — это утечка.

К 2026 году большинство IT-директоров в российских компаниях прошли через одну и ту же стадию: открыли логи сетевого трафика, увидели, какие данные сотрудники отправляли в публичные AI за последние 6 месяцев, и приняли решение что-то менять. Часто — с большой задержкой, и не всегда правильно.

02 · Главный риск публичных AI-сервисов

Риск не в том, что «AI украдёт данные» или что модель «запомнит и выдаст». Это публичные страшилки, к технологии прямо относящиеся не всегда. Реальный риск — в потере контроля над данными.

Когда сотрудник использует внешний AI-сервис, происходит следующее:

• Данные уходят за пределы инфраструктуры компании — в облако провайдера, в чужую юрисдикцию, под чужие политики хранения.
• Невозможно полностью контролировать, где и как они обрабатываются — в каких регионах серверов, кем, с какими политиками удаления.
• Невозможно встроить это в существующую модель безопасности — KMS, SIEM, DLP, аудит-логи остаются за бортом.
• Невозможно ответить на запрос об обработке ПДн — какие данные были переданы, в каком объёме, для какой цели.
• Невозможно выполнить «право быть забытым» — даже если внутри компании данные удалены, копия запроса осталась у провайдера.

Даже если сервис декларирует:

• анонимность запросов;
• отказ от обучения на ваших данных (opt-out);
• соответствие SOC2, ISO 27001;
• enterprise-tier с дополнительными гарантиями;

для российского B2B этого недостаточно. Потому что:

1. 152-ФЗ требует обработки ПДн физлиц-резидентов РФ в инфраструктуре на территории РФ. Передача данных в OpenAI или Anthropic — это трансграничная передача, требующая отдельных оснований.
2. Декларации провайдера — не доказательство в случае инцидента. Если данные утекли через цепочку «сотрудник → ChatGPT → утечка модели → раскрытие» — провайдер скажет «мы выполнили обязательства», и виноватым останется ваш сотрудник, а ответственность — на компании.
3. Аудит и compliance требуют контроля. SOC2-сертификация провайдера не входит в ваш контур аудита. Регулятор не примет «у них же есть сертификация».

Это не про «провайдер плохой». Это про границы ответственности.

03 · Почему для банков, финтеха и регулируемых отраслей это особенно критично

В корпоративных системах банка, финтеха, медицинского сервиса обрабатываются категории данных, требующие специальной защиты:

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

Для этих отраслей добавляются:

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

Использование внешнего AI без контроля в этом контексте:

• Сложно объяснить на проверке регулятора. «Менеджер использовал ChatGPT для подготовки клиентского письма» — это нарушение политики обработки ПДн.
• Невозможно формализовать. Нельзя написать процедуру «как правильно использовать ChatGPT с банковскими данными» — таких правильных способов нет.
• Опасно с точки зрения compliance. Один задокументированный случай утечки через публичный AI = разговор с регулятором, штраф, репутационные потери.
• Создаёт прецедент для других сотрудников. Если правила нечёткие, использование расширяется лавинообразно.

Для банков, финтеха и медицинских компаний в 2026 году это уже не «опция, которую можно отложить». Это обязательное архитектурное решение, которое принимается до того, как AI начнёт использоваться в продакшен-процессах.

04 · Что такое внутренняя AI-система на самом деле

Здесь возникает первое распространённое заблуждение. Многие компании, услышав про «внутренний AI», представляют себе «ChatGPT, развёрнутый на своём сервере». Это не то, что нужно.

Внутренний AI — это архитектурное решение, а не «private deployment одной модели». Это означает несколько одновременных свойств:

• AI встроен в backend — он не отдельный сервис, в который копируют данные. Он часть продукта, в котором уже есть данные.
• Доступ к данным строго ограничен — модель видит только то, что разрешено политикой доступа для конкретного пользователя и конкретного сценария.
• Контекст контролируется системой — что попадает в промпт, какие правила применяются, какие ответы допустимы.
• Все действия логируются — каждый запрос, каждый ответ, каждое решение модели имеет аудит-trail.
• Сама модель может быть как локально развёрнутой (open-source LLM в собственной инфраструктуре), так и приватной у российского провайдера (YandexGPT через изолированный endpoint, GigaChat через корпоративный контракт).

Принципиально важно: внутренний AI ≠ собственная LLM. Можно использовать внешнюю модель через изолированный endpoint и при этом иметь внутренний AI с точки зрения архитектуры — потому что данные не уходят в публичный сервис, контекст контролируется, аудит ведётся, политика доступа применяется.

И обратное тоже верно: можно развернуть Llama-3 на собственном сервере, но если каждый сотрудник имеет к ней прямой доступ без контроля контекста и аудита — это всё равно «ChatGPT внутри», только хуже, потому что нет даже базовой защиты публичного сервиса.

Внутренний AI работает:

• внутри инфраструктуры компании или у доверенного провайдера, согласованного с ИБ;
• по правилам безопасности бизнеса, формализованным как код;
• как часть цифровой системы, не как отдельный сервис, к которому копируют данные.

Узнайте о backend и архитектуре корпоративного уровня: backend development.

05 · Ключевые отличия: публичный AI vs внутренняя AI-система

Сравним по семи параметрам, важным для корпоративной безопасности.

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

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

Логирование и аудит. Публичный AI: ограниченная прозрачность. Вы видите счёт за использование, но не цепочку «кто, что, когда, зачем». Внутренний AI: полная трассируемость каждого действия — кто запросил, какой контекст подгрузился, какой ответ получил, что сделал с ответом.

Интеграция с бизнес-логикой. Публичный AI: изолированный инструмент. Сотрудник копирует данные туда, оттуда, возвращается в основной workflow. Внутренний AI: часть бизнес-процесса. AI получает контекст из CRM, базы знаний, истории операций — без копирования данных через буфер обмена.

Соответствие корпоративным требованиям. Публичный AI: сложно формализовать. Невозможно гарантированно соответствовать политикам безопасности, потому что вы не контролируете провайдера. Внутренний AI: проектируется под требования компании. Можно явно зафиксировать в архитектуре, что соответствие 152-ФЗ выполняется.

Compliance с 152-ФЗ. Публичный AI: трансграничная передача ПДн физлиц-резидентов РФ без явного основания. Не соответствует требованию локализации обработки. Внутренний AI: ПДн остаются в РФ-контуре или передаются в согласованный с регулятором сценарий.

Стоимость инцидента. Публичный AI: утечка через ChatGPT — это нарушение политики ИБ + потенциальный compliance-инцидент + репутационный риск. Внутренний AI: инцидент локализуется в собственной инфраструктуре, разбирается по runbook, минимизируется ущерб.

06 · Почему «запретить ChatGPT» — плохая стратегия

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

На практике это редко работает по нескольким причинам:

• Сотрудники продолжают использовать AI неофициально. Через личные устройства, через смартфоны на 4G, через VPN. Доступ заблокировать на сетевом уровне сложно, особенно для удалённых сотрудников.
• Копируют данные вручную. Менеджер делает скриншот контракта, отправляет себе на личную почту, открывает ChatGPT с домашнего ноутбука. Утечка та же, контроль ещё меньше.
• Обходят запреты через инструменты, которые сложнее заметить. Использование AI-плагинов в браузере, локальных моделей в IDE, AI-функций в Microsoft Office — всё это проскакивает мимо корпоративных фильтров.
• Снижается продуктивность. Сотрудник, лишённый доступа к AI, не возвращается к работе «как раньше». Он работает медленнее, неохотнее, и быстрее уходит к конкуренту, где запретов нет.
• Возникает иллюзия безопасности. Менеджмент считает, что «мы запретили — значит, проблема решена». На деле проблема ушла в тень.

Гораздо эффективнее работает стратегия безопасной альтернативы:

• дать сотрудникам корпоративный AI-инструмент, удобный в работе;
• встроить AI в официальные процессы — там, где он действительно нужен;
• снять необходимость использовать внешние сервисы — потому что внутренний справляется лучше для рабочих задач;
• формализовать политику — что можно делать с внутренним AI, что — нельзя ни с каким;
• провести обучение, объяснив риски и альтернативы.

Запреты работают только если есть альтернатива. Без альтернативы — это политика, которую все обходят.

07 · Как компании в России решают этот вопрос на практике

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

Шаг 1: классификация задач по уровню чувствительности.

• Зелёная зона — задачи, не связанные с корпоративными данными. Перевод общедоступных текстов, помощь в написании личных писем, обучающие материалы. Можно использовать публичные AI.
• Жёлтая зона — задачи с внутренней, но не критичной информацией. Подготовка типовых документов по шаблону, суммаризация общих презентаций. Используется корпоративный AI-инструмент с базовым контролем.
• Красная зона — задачи с критичными данными (ПДн клиентов, финансовая информация, коммерческая тайна). Только внутренний AI с полным контролем, аудитом и ограничением доступа.

Шаг 2: технический контроль.

• DLP-решение, которое детектирует попытки отправки чувствительных данных в публичные AI-сервисы.
• Корпоративный AI-портал с SSO, привязанный к ролям и отделам.
• Логирование всех AI-запросов с привязкой к пользователю.
• Политики автоматической классификации данных при обработке.

Шаг 3: политика и обучение.

• Документированная политика использования AI (что можно, что нельзя, как принимается решение).
• Обучение сотрудников на конкретных примерах: «вот это можно сделать публично, вот это — только через корпоративный».
• Назначение ответственного за AI-практики в каждом крупном отделе.
• Регулярная ревизия логов и кейсов.

Шаг 4: безопасная альтернатива.

• Корпоративный AI-портал, в котором решены 90% типовых задач, для которых сотрудники иначе шли бы в ChatGPT.
• Интеграция AI в основные рабочие инструменты (CRM, документооборот, аналитика) — чтобы сотруднику не приходилось искать AI отдельно.
• Удобный UX, сопоставимый с публичными сервисами, — иначе сотрудники продолжат предпочитать привычное.

Такой подход:

• снижает риски утечки;
• сохраняет эффективность сотрудников;
• соответствует требованиям регуляторов и собственной службы ИБ;
• работает на горизонте 2–3 лет без полного пересмотра.

Подробнее об AI-системах и интеграциях для бизнеса: ai ml.

08 · Когда внутренний AI обязателен

Внутренние AI-системы становятся обязательными, если выполняется хотя бы одно из условий:

• Обрабатываются ПДн физлиц-резидентов РФ — 152-ФЗ требует локализации первичной обработки. Публичный AI с серверами вне РФ не подходит.
• Обрабатывается финансовая информация — банки и финтех имеют обязательства перед регуляторами по защите этой информации.
• Работа с биометрией или специальными категориями ПДн — здоровье, политические взгляды. Требуется отдельный контур обработки.
• Продукт — core-система бизнеса — где утечка через AI означает потерю конкурентного преимущества или клиентов.
• Есть требования регуляторов — ФСТЭК, ФСБ, Банк России, Минздрав. Использование незаконтролируемого AI несовместимо с их требованиями.
• Заказчики компании требуют гарантий — крупные клиенты часто включают в договор пункт «исполнитель не передаёт информацию третьим лицам без согласия». Использование публичного AI этот пункт нарушает.
• Высокая стоимость одного инцидента — для крупных компаний один задокументированный случай утечки стоит больше, чем годовая стоимость внедрения внутреннего AI.

В этих случаях внутренний AI — не опция, а архитектурный стандарт. Альтернатива — это либо полный запрет AI (с понятными последствиями для продуктивности), либо документированный риск, за который кто-то должен отвечать.

09 · Локальная LLM или приватный endpoint — что выбирать

Внутри «внутреннего AI» есть отдельная инженерная развилка: где именно работает модель.

Локальная LLM в собственной инфраструктуре (Llama, Qwen, Mistral, Gemma):

• Полный контроль над данными — ничего не уходит за пределы дата-центра.
• Высокая стоимость инфраструктуры — GPU-кластер, MLOps-команда.
• Качество ответов обычно ниже, чем у топовых проприетарных моделей.
• Требует регулярного обновления моделей и инфраструктуры.
• Оправдано при больших объёмах запросов или жёстких требованиях к локальности.

Приватный endpoint у российского провайдера (YandexGPT через изолированный endpoint, GigaChat через корпоративный контракт):

• Данные обрабатываются в российском контуре, что закрывает 152-ФЗ.
• Качество ответов сопоставимо с топовыми моделями для русского языка.
• Тарификация по запросам — низкая стоимость для малого/среднего объёма.
• Зависимость от провайдера в SLA и доступности.
• Оправдано как стартовая конфигурация для большинства B2B-кейсов.

Гибридный сценарий:

• Локальная LLM для самых критичных задач (внутренний поиск по конфиденциальной базе).
• Приватный российский endpoint для типовых рабочих задач.
• Публичные AI (с DLP-контролем) для зелёной зоны.

Выбор зависит от профиля компании, объёма запросов и приоритетов между «контроль ↔ качество ↔ стоимость».

10 · Архитектура корпоративного AI-портала

В большинстве зрелых внедрений конечный пользовательский продукт — это корпоративный AI-портал или AI-функциональность, встроенная в существующие продукты. Что он включает:

• SSO и ролевая модель — пользователь входит через корпоративный аккаунт, доступные сценарии зависят от роли.
• Каталог сценариев — типовые задачи, обёрнутые в простые формы: «суммаризировать документ», «найти в базе знаний», «подготовить черновик ответа клиенту». Сотрудник не пишет промпт с нуля.
• Контекстный слой — для каждого сценария определено, какой контекст подгружается (например, для работы с клиентом — карточка из CRM, история обращений).
• RAG-доступ к внутренним документам — векторная база с эмбеддингами корпоративной базы знаний, политик, регламентов.
• Бизнес-правила и guardrails — какие данные нельзя обсуждать, какие ответы нужно эскалировать.
• Аудит-лог — каждый запрос/ответ фиксируется, доступен для ревизии.
• Обратная связь — пользователь может оценить ответ, эти оценки используются для улучшения промптов и базы знаний.
• Интеграция с DLP — попытки скопировать чувствительную информацию из внутреннего AI наружу детектируются и блокируются.

Такая система — это 6–14 недель разработки для среднего B2B-продукта, в зависимости от глубины интеграции с существующими системами. Это сравнимо со стоимостью одного крупного инцидента с публичным AI.

11 · Compliance: что закрывает внутренний AI и что — нет

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

Что закрывает архитектурой внутреннего AI:

• Локализация обработки ПДн физлиц-резидентов РФ (если модель в российской инфраструктуре).
• Контроль над тем, какие данные обрабатываются.
• Аудит-trail для расследования инцидентов.
• Ограничение доступа по ролям и сценариям.
• Возможность удалить данные субъекта (erasure-процедура).
• Соблюдение SLA и политик retention.

Что требует параллельной работы:

• Документированная политика обработки ПДн с упоминанием AI-сценариев.
• Договор поручения на обработку ПДн с провайдером AI-инфраструктуры (если используется приватный endpoint).
• Регистрация AI-системы как информационной системы обработки ПДн (если применимо).
• Согласия субъектов на обработку, если эта обработка теперь включает AI-анализ.
• Обучение сотрудников и формализация процедур.
• Регулярная ревизия и обновление политик.

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

Подробнее про compliance: ФЗ-152 для SaaS-продуктов в 2026: что реально требует архитектура (а не только бумажки).

12 · Чек-лист: 10 вопросов до выбора AI-стратегии

Если в вашей компании ещё нет внятной политики AI или вы только формируете подход, имеет смысл начать с этих 10 вопросов:

• Какие данные сотрудники уже отправляют в публичные AI? Логи сети, опрос команды.
• Какие сценарии создают основной поток обращений к AI? Перевод, документы, ответы клиентам, кодинг.
• Какие из этих сценариев требуют корпоративных данных? Что в зелёной, жёлтой, красной зоне.
• Что у нас за регуляторные требования? 152-ФЗ, отраслевые нормативы, договорные обязательства.
• Какой у нас бюджет на внедрение внутреннего AI? На 12 и 24 месяца.
• Какой объём запросов в день мы ожидаем? Это определяет выбор между локальной LLM и endpoint-провайдером.
• Кто внутри компании отвечает за AI-стратегию? Имя, должность, полномочия.
• Какая существующая инфраструктура? SSO, DLP, корпоративная база знаний, CRM, документооборот.
• Какие интеграции нужны в первую очередь? Где AI создаст максимальную экономию.
• Как мы будем измерять результат внедрения? Метрики безопасности, метрики продуктивности, метрики окупаемости.

Компания, которая отвечает на эти вопросы внятно, обычно за 2–3 недели формирует пилот, а за 6–9 месяцев приходит к зрелой архитектуре. Компания, которая отвечает «давайте сначала запретим, потом разберёмся», обычно через год возвращается к этим же вопросам в условиях случившегося инцидента.

Источники и что читать дальше

• AI в B2B-бизнесе: где он экономит деньги, где заменяет сотрудников, а где остаётся хайпом — где AI экономит бизнесу деньги и как считать ROI.
• Как внедрить AI в существующую систему без переписывания backend — как внедрить AI в существующую систему без переписывания backend.
• ФЗ-152 для SaaS-продуктов в 2026: что реально требует архитектура (а не только бумажки) — 152-ФЗ и архитектура работы с ПДн.
• Корпоративный MVP в 2026 году: почему «быстро и дёшево» больше не работает — корпоративный MVP и место AI в нём.
• Почему системы без мониторинга и логирования обречены ломаться — наблюдаемость и аудит-лог.
• ai ml — наш подход к корпоративным AI-системам.
• backend development — backend-фундамент для корпоративного AI.
• devops infrastructure — инфраструктура для приватных AI-сервисов.

---

Безопасность AI — это инженерная и организационная задача одновременно. Архитектура закрывает технические риски, но без политики, обучения и владельца внутри компании внедрение через 6 месяцев деградирует. Эта статья — рамка для решения, не пошаговое руководство по внедрению.