Спойлер: не бойтесь модели — бойтесь препроцессора

25 февраля 2026 года Atlassian вывела в открытую бету «агентов в Jira». Теперь они практически наши коллеги: видны на доске как исполнители, на равных участвуют в рабочих процессах, а вызывать их можно прямо в комментариях через @mention. Параллельно Atlassian выпустила Rovo MCP Server GA — хостированный сервер, который дает совместимым AI-клиентам (Claude, Cursor, Gemini CLI и др.) защищенный доступ к Jira и Confluence.

Некоторые из этих сценариев были доступны и раньше, но в другом виде. Rovo Agents (платформа ИИ-агентов Atlassian) работали (с 2024) в основном через отдельный чат-интерфейс и не были встроены в Jira как полноценные участники. В февральском релизе это изменилось: теперь агенты — часть структуры Jira, работают в рамках проектных настроек, прав доступа, аудит-логов и согласований.

Что с безопасностью: общая архитектура

Типовая схема взаимодействия ИИ‑ассистента с Jira — это три слоя: препроцессор (middleware), модель (GPT/Claude/Gemini) и постпроцессинг.

Препроцессор забирает данные из Jira по API, нормализует их, фильтрует, обогащает контекстом, при необходимости строит векторный индекс, пишет логи и только потом формирует запрос для модели.
После этого модель в облаке провайдера (OpenAI, Anthropic, Google Cloud) получает уже готовый промпт и подготовленный контекст.
Ответ возвращается через постпроцессинг, где его можно дообезличить, залогировать и отдать обратно в Jira.

Это важная развилка: GPT, Claude или Gemini не «ходят» в Jira сами по себе. Они видят только то, что вы им отправили. И вот тут ответ на вопрос «что происходит с данными компании» зависит от двух вещей: что делает с запросом провайдер модели и что делает с исходными данными ваш препроцессор до того, как этот запрос вообще собран.

Что делают с данными провайдеры

Начнем с провайдеров и сразу хорошая новость: и OpenAI, и Anthropic, и Google — дают корпоративным клиентам договорные гарантии того, что данные через API не используются для обучения моделей. Это прописано в условиях сервиса, и применяется по умолчанию, необходимости что-то специально отключать нет.

Вот только детали у каждого провайдера свои, а искать их нужно не на маркетинговой странице, а в контракте, DPA (Data Processing Agreement, соглашение об обработке данных) и настройках конкретного продукта. Начать можете с этого: OpenAI DPA, Anthropic DPA, Google Cloud DPA.

Если очень кратко, различия в следующем:

У OpenAI для чувствительных кейсов доступен режим Zero Data Retention: там даже служебные логи не сохраняются, хотя запрос все равно проходит через защитные фильтры. Похожая логика у Anthropic: для коммерческих продуктов обучение на клиентских данных требует явного согласия клиента, а для enterprise-сценариев доступны договорные режимы изоляции и сниженной ретенции. У Google в Gemini for Workspace и Vertex AI данные клиента также отделяются от данных для обучения, а в корпоративных сценариях можно настраивать параметры региона, шифрования и частных соединений.

Это не значит, что риска нет. Это значит, что в enterprise-канале риск обычно не в провайдере, который внезапно начнет доучивать модель на ваших тикетах, давая доступ к внутренней кухне компании, а в том, какой именно контекст вы ему отправили и как этот контекст был собран.

Здесь есть важная оговорка про Anthropic. On-prem-развертывания базовых моделей Claude в исходном виде нет. Доступ идет либо через облако самого Anthropic, либо через партнерские каналы вроде AWS Bedrock и Google Vertex AI. Для security-команды это означает одно: рассчитывать на полностью локальный Claude не стоит, архитектуру в любом случае придется проектировать исходя из облачного сценария.

Почему личный аккаунт сотрудника — это другое

Все сказанное выше справедливо для корпоративных продуктов и API. Потребительские версии — Claude Free/Pro/Max в браузере, Gemini Apps на gemini.google.com, ChatGPT Free — живут по другим правилам.

Там режимы хранения, использования данных и отключения обучения отличаются от enterprise-сценариев и требуют отдельной настройки, если она вообще доступна.

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

Проблема здесь явно не в Anthropic, OpenAI или Google, а в том, что ваша компания не развела режимы использования и не закрыла этот сценарий организационно, объяснив сотруднику перспективы такого поведения. Проще говоря — забила на безопасность.

Для работы с Jira нужны либо корпоративные лицензии, либо корпоративный API-канал: OpenAI API или Enterprise, Anthropic API и Claude for Work, Gemini for Workspace или Google Cloud. Личный аккаунт сотрудника, прокинутый через сторонний клиент, — ни разу не замена этим продуктам и не «временное решение», а отдельный, прямой риск.

Где на самом деле прячется лиса

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

индексирует тикеты;
хранит векторные представления;
кэширует запросы и ответы;
пишет логи;
собирает метрики качества;
обогащает контекст данными из других систем.

Если этот слой развернут внутри вашего контура — on-prem или в собственном VPC, — риск, не исчезает полностью, но становится более управляемым. Все упирается в то, что именно вы храните, как долго, в каком виде, кто имеет доступ и куда разрешен исходящий трафик.

Однако еще опаснее сценарий, когда вместо собственной middleware-прокладки компания ставит готовый SaaS-коннектор из маркетплейса Jira или вообще подключает внешнюю AI-платформу, пусть и рекомендованную для Jira. Тогда появляется еще один обработчик данных со своей базой, своими логами, своей юрисдикцией хранения, своими условиями и своей моделью угроз. И этот риск уже никак не покрывается тем, что у вас подписан DPA с OpenAI, Anthropic или Google.

Проще говоря, классный плагин AI for Jira — это не продолжение политики безопасности провайдера модели. Это отдельный поставщик. И проверять его нужно отдельно.

Что делать, чтобы спать спокойно

Если смотреть на задачу по-взрослому, начинать нужно не с выбора модели, а с правил и архитектуры.

Во-первых, запретить использование личных consumer-аккаунтов для работы с корпоративными данными. Это базовая гигиена. Пока сотрудники безмятежно копируют тикеты в свой личный чат, вся остальная безопасность — фикция.

Во-вторых, использовать только корпоративные каналы доступа к модели. И это не формальность. У enterprise-продуктов и API другой технический режим: DPA, управляемая ретенция, отдельные настройки доступа, иногда — ZDR (Zero Data Retention, режим нулевого хранения данных) или его аналоги. Не факт, что поможет, но в целом жить можно.

В-третьих, держать препроцессор внутри собственного контура и относиться к нему как к критичному хранилищу, а не как к утилитарной прослойке для запросов. Минимальный набор мер для этого не требует участия специалистов из Кремниевой долины:

по возможности хранить не полный текст тикетов, а производные представления;
шифровать хранилища и логи;
ограничивать исходящий трафик только до нужного API;
минимизировать контекст до отправки в модель;
маскировать PII (Personally Identifiable Information, персональные данные);
заменять логины, Jira ID и другие идентификаторы псевдонимами;
фильтровать вложения и чувствительные поля до индексации.

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

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

Наконец, в-пятых. Не стоит доверять маркетплейс-коннекторам, пусть они очень вам нравятся и клянутся мамой. Если вы ставите внешний AI-плагин для Jira, у него должны быть свои DPA, желательно даже DPIA (Data Protection Impact Assessment, оценка воздействия на защиту данных), понятная модель хранения данных, прозрачная юрисдикция и внятный ответ на вопрос, где именно лежат тикеты, индексы, кэш и логи и как обеспечивается их защита.

Вывод

А вывод очевиден: безопасность любой ИИ-интеграции определяет не модель, а цепочка обработки данных между Jira и этой моделью. У провайдера LLM своя зона ответственности. У вас, как у владельца и администратора бизнес-процессов — своя. И если в этой цепочке есть слабое место, то чаще всего это не GPT, Claude или Gemini, а слой, который вы сами построили между ними.

При этом даже если речь идет о корпоративном API, договорных гарантиях, сниженной ретенции и настроенном с маниакальной аккуратностью доступе, риск остается, потому что данные все равно попадают в руки внешнего провайдера.

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

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

ИИ в корпоративной Jira или лиса в курятнике: новый вызов для DevSecOps-инженеров