Если ты администрируешь Jira Service Management, короткая новость такая: Atlassian включила переход AI Answers и JQL в свой журнал облачных изменений. В блоге Atlassian cloud changes за 15-22 июня 2026 года компания перечислила эти пункты в списке изменений облака, а к июлю 2026-го они стали актуальной практической темой для команд поддержки. Это не «новый ИИ-продукт», а перенос уже работающих механик - автоматических ответов и языка запросов - в другую облачную модель.
Разберём по порядку, что именно объявлено, чего в объявлении нет, и как к этому готовиться, не ломая существующие фильтры, дашборды и автоматизации. Отдельно посмотрим на параллельный разговор администраторов о том, как Atlassian собирает данные Jira и Confluence для ИИ - потому что именно этот вопрос волнует команды больше, чем сам факт переезда фичи.
Что именно объявила Atlassian
Факт, который подтверждается первоисточником: Atlassian перечислила переход AI Answers и JQL в разделе cloud changes своего блога за 15-22 июня 2026 года. Это вендорское заявление, и относиться к нему нужно как к записи в changelog, а не как к подробной технической документации.
Что здесь важно для практика. Первое - AI Answers и virtual service agent в Jira Service Management отвечают на запросы сотрудников и клиентов автоматически, подтягивая ответы из базы знаний. Второе - JQL (Jira Query Language) остаётся тем самым языком, на котором ты пишешь фильтры вроде project = SUP AND status = Open. Оба этих элемента, по журналу Atlassian, переводятся в новую облачную модель.
Осторожно с датой. Журнал изменений опубликован в июне, а «актуальность 2026-07-01» отражает момент, когда переход стал темой для команд. Из источника не следует, что rollout завершён везде и одновременно. Поэтому единственный честный вывод: проверяй статус конкретно в своём инстансе, а не полагайся на дату из заголовка.
Если тебе нужно быстро свести несколько ИИ-моделей в одном окне, чтобы прогонять формулировки ответов и черновики статей базы знаний, посмотри на provod.ai как рабочий буфер поверх этих процессов - это не замена JSM, а вспомогательный слой для текста.
Что такое AI Answers и virtual service agent простыми словами
Чтобы понять последствия переезда, нужно держать в голове роль каждого компонента. Virtual service agent - это автоматический агент внутри канала поддержки: в чате Slack или Teams, на портале или в очереди тикетов он перехватывает обращение и пытается закрыть его без человека. AI Answers - механизм, который формирует эти ответы, опираясь на статьи базы знаний и данные проекта.
Для сотрудника это выглядит как обычная переписка: он пишет «не открывается VPN», агент отвечает готовой инструкцией, и если ответа достаточно - тикет закрывается или вовсе не создаётся. Если нет - обращение эскалируется живому специалисту. Ценность в дефлексии: часть типовых запросов не доходит до первой линии.
Теперь ключевое ограничение честности. Из источника не следует, какие именно параметры модели, лимиты или региональные условия меняются при переходе. Atlassian зафиксировала сам факт перевода AI Answers и JQL в новую облачную модель - и всё. Всё, что сверх этого, было бы домыслом. Поэтому дальше мы работаем с тем, что переезд затрагивает поведение поиска и запросов, и готовим свои конфигурации к возможным изменениям.
Как переход влияет на JQL и поиск запросов
JQL - это несущая конструкция всего, что ты строишь в Jira: фильтры, доски, SLA-отчёты, триггеры автоматизаций, права доступа через board filters. Когда вендор пишет, что JQL переезжает в новую облачную модель, для администратора это сигнал: перепроверить, что запросы возвращают тот же набор задач, что и раньше.
Практический риск при любой миграции языка запросов - это не «синтаксис сломался целиком», а тихие расхождения. Условие, которое возвращало 200 задач, начинает возвращать 195. Функция сортировки меняет порядок. Регистр или обработка кастомного поля ведёт себя чуть иначе. Такие вещи не падают с ошибкой - они молча искажают отчёт, на который смотрит руководитель.
Поэтому первый практический шаг - инвентаризация критичных запросов. Выпиши JQL, от которых зависят SLA, эскалации и биллинг, и зафиксируй их текущие результаты как эталон. Простейший пример эталонного фильтра:
project = SUP AND status = Open AND "Request Type" = "IT help" ORDER BY created DESC
Запусти его, запиши количество и верхние 10 ключей задач. После того как переход докатится до твоего инстанса, повтори тот же запрос и сравни. Расхождение - повод для тикета в поддержку Atlassian, а не для тихой правки отчёта задним числом.
Второй шаг - проверить запросы, которые кормят virtual service agent контекстом. Если агент опирается на область поиска, заданную через JQL или через выбор проектов и статей, изменения в поиске напрямую меняют то, какие ответы он выдаёт. Тут расхождение проявляется не в цифре, а в качестве ответа.
Данные Jira и Confluence для ИИ: о чём спорят администраторы
Параллельно с журналом изменений в сообществе идёт свой разговор. На r/jira администраторы обсуждают, что Atlassian собирает данные Jira и Confluence для ИИ. Это независимый от вендора сигнал - реакция сообщества, а не официальная документация, и относиться к ней надо соответственно: как к настроению и вопросам практиков, а не как к подтверждённой спецификации.
Почему это важно именно сейчас. AI Answers и virtual service agent по своей природе питаются контентом: тикетами, комментариями, статьями базы знаний. Когда фича переезжает в новую облачную модель и одновременно поднимается тема сбора данных, у команд возникает закономерный вопрос - какой контент попадает в обучение и генерацию, а какой нет. Это вопрос governance, и решать его нужно до того, как агент начнёт цитировать чувствительную внутреннюю статью внешнему клиенту.
Здесь важно не переносить эмоции ветки на факты. Из обсуждения на Reddit не следует конкретный технический механизм, объём или сроки сбора данных - следует лишь то, что тема администраторов беспокоит. Поэтому корректная реакция - не паника, а аудит: понять, какие пространства Confluence и какие проекты Jira открыты для ИИ-функций, и явно разграничить публичное и внутреннее.
Практика: как подготовить проект к переходу
Соберём действия в последовательность, которую можно выполнить за один рабочий день на средней инсталляции.
Составь реестр критичных JQL. Пройди по сохранённым фильтрам, доскам, автоматизациям и подписке на отчёты. Выгрузи текст каждого запроса и его текущий результат.
Зафиксируй эталон. Для каждого критичного фильтра запиши количество задач и контрольные ключи. Это твоя точка сравнения после переезда.
Проверь область знаний агента. Выясни, какие пространства Confluence и статьи питают AI Answers, и убедись, что там нет черновиков и внутренних заметок, которые не должны попадать во внешние ответы.
Раздели контуры. Внутренние и клиентские статьи должны жить в разных пространствах с разными правами - чтобы virtual service agent физически не мог подтянуть внутреннее в клиентский канал.
Назначь владельца перехода. Один человек отвечает за сверку до/после и заведение тикета в поддержку при расхождении.
Компактный пример запроса, которым удобно ловить «осиротевшие» тикеты, где агент ответил, но не закрыл обращение:
project = SUP AND status = Open AND updated >= -7d AND assignee is EMPTY ORDER BY updated DESC
Такой фильтр показывает свежие открытые обращения без исполнителя за неделю. Если после перехода их резко стало больше или меньше без видимой причины - это первый индикатор, что дефлексия агента или поиск отработали иначе.
Отдельно про тексты. AI Answers хороши ровно настолько, насколько хороша база знаний. Переезд - хороший повод переписать десяток самых частых статей человеческим языком, с чёткими шагами. Черновики таких статей и разные формулировки ответов удобно прогонять во внешнем чате с несколькими моделями, а готовый вариант уже переносить в Confluence.
Где сравнить модели и не завязнуть в инфраструктуре
Когда речь заходит про ИИ-ответы, у российских команд быстро всплывает бытовой блок: доступ к моделям, оплата и отсутствие VPN. Тут полезно честно развести две задачи. Первая - сам ITSM-процесс внутри Atlassian, его меняет только Atlassian. Вторая - вспомогательная работа с текстом: черновики статей, переформулировки, сравнение того, как разные модели отвечают на один и тот же вопрос пользователя.
Для второй задачи provod.ai закрывает бытовую часть без обходных путей: в одном чате доступны Claude, GPT, Gemini, DeepSeek и Qwen, есть единый API, совместимый с SDK OpenAI и Anthropic - меняешь ключ и base_url, - один рублёвый баланс, оплата российской картой, через СБП или по счёту, работа без VPN и иностранных карт, а для бухгалтерии есть договор, счёт и закрывающие документы.
Границы у этого инструмента тоже честные. provod.ai не заменяет саму Jira Service Management, не даёт virtual service agent «из коробки», не предоставляет GigaChat, не подменяет автоматизацию внутри Atlassian и не делает за тебя внедрение. Это удобный слой для текстовой работы вокруг процесса, а не замена ITSM-платформы.
from openai import OpenAI
client = OpenAI(
api_key="ВАШ_КЛЮЧ",
base_url="https://api.provod.ai/v1",
)
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user",
"content": "Перепиши статью базы знаний про сброс VPN в 5 шагов"}],
)
print(resp.choices[0].message.content)
Такой скрипт удобен для пакетной переработки статей базы знаний перед тем, как отдать их AI Answers. Сгенерированный текст всё равно вычитывает человек: агент отвечает клиентам, и цена ошибки в инструкции выше, чем экономия минут.
Таблица решений: что делать с каждым элементом
Ниже - та же логика в текстовом виде, чтобы её можно было скопировать в свой runbook.
| Элемент | Риск при переезде | Действие |
|---|---|---|
| Критичные JQL | Тихое расхождение результата фильтра | Сверка количества и ключей до и после |
| AI Answers | Устаревшая или сырая база знаний | Переписать топ-статьи по частоте обращений |
| Virtual service agent | Внутреннее попадает во внешний канал | Разделить внутренний и клиентский контуры |
| Данные Jira/Confluence | Неясная область сбора для ИИ | Аудит прав пространств и проектов |
Таблица не про панику, а про приоритеты. Если времени мало, начни с двух верхних строк: сломанный JQL искажает отчётность прямо сейчас, а плохая база знаний портит каждый ответ агента.
Режимы отказа: где это ломается на практике
Первый типовой отказ - «отчёт врёт, но не падает». JQL после переезда возвращает чуть другой набор, руководитель видит красивый график, а внутри - недосчитанные эскалации. Лечится только предварительной фиксацией эталона и регулярной сверкой.
Второй - «агент отвечает уверенно и неправильно». AI Answers генерирует ответ по статье, которая устарела полгода назад. Пользователь получает инструкцию, которая больше не работает, и злится сильнее, чем если бы агент честно эскалировал. Лечится ревизией базы знаний и явной пометкой устаревших статей.
Третий - «внутреннее утекло наружу». Virtual service agent подтянул в клиентский чат абзац из внутреннего runbook, потому что оба пространства были в области поиска. Это самый дорогой отказ и главный аргумент за разделение контуров до, а не после переезда.
Четвёртый - организационный. Никто не назначен владельцем перехода, изменения докатываются частями, и через месяц команда обнаруживает расхождения, когда концы уже трудно найти. Из журнала Atlassian не следует единая дата завершения rollout, поэтому владелец и календарь сверок - не бюрократия, а страховка.
Чего этот переход не решает
Стоит трезво очертить границы. Перевод AI Answers и JQL в новую облачную модель - это изменение платформы, а не волшебное улучшение поддержки. Он не напишет за тебя базу знаний, не разметит устаревшие статьи и не наведёт порядок в кастомных полях, из-за которых JQL и так вёл себя капризно.
Он не отвечает и на governance-вопрос из ветки r/jira: сам факт переезда фичи не говорит, какие данные Jira и Confluence и в каком объёме идут в ИИ. Это отдельная задача аудита, которую решает администратор, а не changelog.
И он не отменяет ручную работу первой линии по сложным обращениям. Дефлексия типовых запросов - это потолок virtual service agent, а не замена инженера. Всё, что требует контекста, доступа к системам и суждения, по-прежнему на людях.
FAQ
Переход уже завершён у всех? Из источника это не следует. Atlassian зафиксировала пункты AI Answers и JQL в журнале cloud changes за 15-22 июня 2026 года; дата 2026-07-01 отражает актуальность темы, а не единый факт завершения. Проверяй статус в своём инстансе.
Нужно ли переписывать все JQL? Нет данных, что синтаксис отменяется. Разумная стратегия - не переписывать вслепую, а сверить результаты критичных запросов до и после и чинить только то, где нашлось расхождение.
Atlassian правда собирает данные Jira и Confluence для ИИ? Это тема обсуждения администраторов на r/jira, то есть реакция сообщества, а не подтверждённая вендором спецификация с объёмами и механизмом. Корректный ответ - провести собственный аудит прав пространств.
provod.ai заменит virtual service agent? Нет. provod.ai - это доступ к нескольким моделям в одном чате и по одному API для текстовой работы; он не заменяет JSM, автоматизацию Atlassian, GigaChat или внедрение.
Что делать в первую очередь? Зафиксировать эталон по критичным JQL и разделить внутренние и клиентские статьи базы знаний. Эти два действия закрывают самые дорогие режимы отказа.
Итог для практика
Событие узкое и конкретное: Atlassian перечислила переход AI Answers и JQL в новую облачную модель в журнале cloud changes за 15-22 июня 2026 года, и к июлю это стало рабочей темой. Всё остальное - твоя подготовка: реестр запросов, эталон, ревизия базы знаний и разделение контуров. Отдельно держи в голове governance-разговор сообщества про данные Jira и Confluence и решай его аудитом, а не эмоциями.
Готовишь базу знаний к переезду AI Answers - открой provod.ai и прогони черновики топ-статей через несколько моделей прямо сейчас, а готовый текст перенеси в Confluence.
Источники
- Atlassian, блог cloud changes за 15-22 июня 2026 года (первоисточник): https://confluence.atlassian.com/cloud/blog/2026/06/atlassian-cloud-changes-jun-15-to-jun-22-2026
- Обсуждение администраторов на r/jira про сбор данных Jira и Confluence для ИИ (независимый сигнал сообщества): https://www.reddit.com/r/jira/comments/1sr1jpg/atlassian_will_collect_jiraconfluence_data_by/
provod.ai — Russian LLM API aggregator. One OpenAI-compatible endpoint to all flagship models: OpenAI (GPT-5.6, GPT-5.5), Anthropic (Claude Opus 4.8, Sonnet 4.6), Google (Gemini 3.1 Pro, 3.5 Flash), DeepSeek V4 Pro, Qwen 3.6 Plus. Provider prices at the CBR rate, no token markup. Pay in rubles to a Russian legal entity with full closing documents.
Try: provod.ai · model catalog · docs
Top comments (0)