Как сделать ИИ-агента для IT Service Desk

Что получится в результате

Соберем ИИ-агента для IT Service Desk, который принимает внутренние IT-заявки, определяет категорию и приоритет, проверяет SLA, ищет статью в базе знаний, задает уточняющие вопросы, готовит черновик ответа, создает задачи инженерам и отправляет опасные действия на approval.

Первая рабочая версия будет делать так:

1. настройки хранятся в `settings`;
2. сотрудники и заявители хранятся в `requesters`;
3. каталог IT-услуг хранится в `service_catalog`;
4. входящие заявки хранятся в `tickets`;
5. комментарии и сообщения хранятся в `ticket_messages`;
6. база знаний хранится в `kb_articles`;
7. политики SLA хранятся в `sla_policies`;
8. IT-активы хранятся в `asset_inventory`;
9. группы поддержки хранятся в `resolver_groups`;
10. результаты triage пишутся в `ticket_triage`;
11. недостающие данные пишутся в `missing_data_requests`;
12. найденные статьи пишутся в `kb_matches`;
13. черновики ответов пишутся в `response_drafts`;
14. заявки на доступ пишутся в `access_requests`;
15. массовые проблемы пишутся в `incident_log`;
16. риски SLA пишутся в `sla_risk_log`;
17. спорные действия уходят в `approval_queue`;
18. одобренные действия попадают в `execution_queue`;
19. задачи инженерам и владельцам сервисов пишутся в `task_queue`;
20. ежедневная сводка пишется в `daily_service_desk_report`;
21. все решения пишутся в `audit_log`;
22. ошибки API и данных пишутся в `error_log`.

В первой версии агент не выдает доступы, не сбрасывает пароли, не закрывает тикеты, не меняет роли, не запускает инфраструктурные команды и не пишет сотруднику финальный ответ без approval. Он классифицирует, ищет, объясняет и готовит действия.

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Sheets для MVP-таблиц.
• ITSM или helpdesk: Jira Service Management, Freshservice, Zendesk, GLPI, YouTrack, Jira, ServiceNow или CSV.
• Read-only API-ключ к service desk на первом этапе.
• База знаний: Confluence, Notion, Google Docs, Zendesk Guide, Freshservice Solutions или Markdown.
• Каталог IT-услуг и групп поддержки.
• Правила SLA по категориям, приоритетам и подразделениям.
• Справочник сотрудников и отделов.
• Список IT-активов: ноутбуки, учетные записи, сервисы, лицензии.
• Канал approval: Telegram, Slack, Microsoft Teams, email или задача.
• API-ключ LLM-провайдера.
• Ответственный service desk lead или IT-администратор.

Шаг 1. Выберите первый сценарий Service Desk

Не начинайте с агента, который решает все IT-заявки.

Для MVP выберите один сценарий:

1. классифицировать входящие заявки;
2. находить статью базы знаний;
3. задавать уточняющие вопросы;
4. готовить черновик ответа оператору;
5. отслеживать риск SLA;
6. находить похожие массовые инциденты;
7. создавать задачи нужной группе поддержки;
8. собирать ежедневный отчет по очереди.

Самый безопасный старт: `агент читает новые тикеты, делает triage, предлагает статью и черновик ответа, но не применяет изменения сам`.

Проверка: сценарий можно вручную проверить на 10 тикетах.

Шаг 2. Запретите опасные действия

В первой версии запретите агенту:

• закрывать тикет;
• менять статус тикета на resolved;
• сбрасывать пароль;
• выдавать доступ;
• менять роль пользователя;
• удалять учетную запись;
• отключать MFA;
• запускать скрипты на серверах;
• менять сетевые настройки;
• удалять файлы;
• отправлять финальный ответ сотруднику без approval;
• скрывать или удалять историю тикета.

Разрешите агенту:

• читать тикеты;
• читать комментарии;
• читать SLA;
• искать в базе знаний;
• определять категорию;
• предлагать приоритет;
• готовить черновик ответа;
• создавать задачу;
• отправлять approval;
• писать audit log.

Проверка: API-токен первого запуска не имеет прав на закрытие тикетов и изменение доступов.

Шаг 3. Создайте Google Sheet проекта

Создайте таблицу:

IT Service Desk agent

Добавьте листы:

settings
requesters
service_catalog
tickets
ticket_messages
kb_articles
sla_policies
asset_inventory
resolver_groups
ticket_triage
missing_data_requests
kb_matches
response_drafts
access_requests
incident_log
sla_risk_log
approval_queue
execution_queue
task_queue
daily_service_desk_report
audit_log
error_log

Проверка: n8n может читать и писать во все листы.

Шаг 4. Заполните settings

В `settings` добавьте колонки:

key
value
description
updated_at

Заполните минимум:

approval_required | true | внешние действия только через approval
auto_execute | false | автоприменение выключено
reply_approval_required | true | ответ сотруднику только после проверки
access_change_blocked | true | действия с доступами запрещены
password_reset_blocked | true | сброс пароля запрещен
close_ticket_blocked | true | закрытие тикета запрещено
sla_warning_minutes | 60 | предупреждать за час до SLA
incident_cluster_window_minutes | 30 | окно поиска массового инцидента

Проверка: все рискованные действия выключены.

Шаг 5. Заполните requesters

В `requesters` добавьте колонки:

requester_id
employee_id
name
email
department
manager_email
location
role
vip_level
status
updated_at

Пример:

REQ-001 | E-1024 | Иван Петров | ivan@example.ru | sales | boss@example.ru | Moscow | account_manager | normal | active | 2026-05-23

Проверка: у каждого тикета есть заявитель или ошибка `missing_requester`.

Шаг 6. Заполните service_catalog

В `service_catalog` добавьте колонки:

service_id
name
category
request_type
default_priority
owner_group_id
required_fields
allowed_actions
blocked_actions
kb_tags
status
updated_at

`request_type`:

incident
service_request
access_request
question
change_request
hardware_request
software_request

Пример:

SVC-VPN | VPN | network | incident | medium | GRP-NET | os_version, error_text, location | draft_reply, ask_question | reset_password, change_access | vpn, network | active | 2026-05-23

Проверка: у каждой категории есть владелец и обязательные поля.

Шаг 7. Заполните tickets

В `tickets` добавьте колонки:

ticket_id
source_system
external_id
requester_id
subject
description
channel
category
request_type
priority
status
resolver_group_id
assignee
created_at
updated_at
sla_due_at

Статусы:

new
triaged
waiting_for_user
waiting_for_support
in_progress
approval_pending
resolved
closed
cancelled

Пример:

IT-1001 | jira_service_management | 9001 | REQ-001 | Не работает VPN | Ошибка 619 при подключении из дома | portal | vpn | incident | medium | new | - | - | 2026-05-23 09:20 | 2026-05-23 09:20 | 2026-05-23 17:00

Проверка: есть минимум 3 тикета со статусом `new`.

Шаг 8. Заполните ticket_messages

В `ticket_messages` добавьте колонки:

message_id
ticket_id
author_type
author_id
message_text
is_internal
attachments_url
created_at

`author_type`:

requester
agent
system
manager
bot

Проверка: агент анализирует не только subject, но и последние сообщения тикета.

Шаг 9. Заполните kb_articles

В `kb_articles` добавьте колонки:

article_id
title
url
service_id
tags
content_summary
allowed_for_employee
last_reviewed_at
owner
status
updated_at

Пример:

KB-VPN-01 | Как проверить VPN на Windows | https://kb.example/vpn-windows | SVC-VPN | vpn, windows, error619 | Проверка клиента, сети и MFA | true | 2026-05-01 | net_admin | published | 2026-05-23

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

Шаг 10. Заполните sla_policies

В `sla_policies` добавьте колонки:

sla_id
service_id
priority
first_response_minutes
resolution_minutes
business_hours_only
vip_multiplier
escalation_group_id
status
updated_at

Пример:

SLA-VPN-MED | SVC-VPN | medium | 60 | 480 | true | 0.5 | GRP-NET-L2 | active | 2026-05-23

Проверка: для каждой категории и priority есть SLA.

Шаг 11. Заполните asset_inventory

В `asset_inventory` добавьте колонки:

asset_id
owner_requester_id
asset_type
hostname
serial_number
os
os_version
location
status
updated_at

`asset_type`:

laptop
desktop
phone
printer
server
account
license
network_device

Проверка: агент видит актив сотрудника, но не раскрывает лишние персональные данные в ответе.

Шаг 12. Заполните resolver_groups

В `resolver_groups` добавьте колонки:

resolver_group_id
name
level
owner_email
supported_services
business_hours
escalation_group_id
status
updated_at

Пример:

GRP-NET | Network L1 | 1 | netlead@example.ru | SVC-VPN,SVC-WIFI | 09:00-18:00 | GRP-NET-L2 | active | 2026-05-23

Проверка: у каждой услуги есть рабочая группа.

Шаг 13. Подключите источники данных в n8n

Создайте workflow:

IT Service Desk Agent - triage

Добавьте узлы:

1. `Schedule Trigger`;
2. `Read tickets`;
3. `Read ticket_messages`;
4. `Read requesters`;
5. `Read service_catalog`;
6. `Read kb_articles`;
7. `Read sla_policies`;
8. `Read asset_inventory`;
9. `Read resolver_groups`;
10. `Classify ticket`;
11. `Find KB matches`;
12. `Check missing data`;
13. `Check SLA risk`;
14. `LLM triage analysis`;
15. `Write triage`;
16. `Create drafts and tasks`;
17. `Send approval`;
18. `Write audit_log`;
19. `Write error_log`.

Проверка: workflow вручную обрабатывает один тикет без записи в боевую ITSM.

Шаг 14. Если есть ITSM, подключите read-only API

Для Jira Service Management:

GET /rest/servicedeskapi/request
GET /rest/servicedeskapi/request/{issueIdOrKey}/comment
GET /rest/servicedeskapi/servicedesk
GET /rest/servicedeskapi/organization

Для Freshservice:

GET /api/v2/tickets
GET /api/v2/requesters
GET /api/v2/solutions/articles
GET /api/v2/assets

Для Zendesk:

GET /api/v2/tickets
GET /api/v2/users
GET /api/v2/groups
GET /api/v2/help_center/articles

Проверка: API возвращает тикеты и комментарии, но update-запросы не используются.

Шаг 15. Сделайте ticket_triage

В `ticket_triage` добавьте колонки:

triage_id
run_id
ticket_id
detected_service_id
detected_request_type
suggested_priority
resolver_group_id
confidence
evidence_json
next_step
status
created_at

`next_step`:

ask_missing_data
draft_response
assign_group
create_access_approval
escalate_incident
manual_review

Проверка: тикет VPN получает `detected_service_id = SVC-VPN`.

Шаг 16. Найдите missing_data_requests

Сравните тикет с `required_fields` из `service_catalog`.

В `missing_data_requests` добавьте колонки:

missing_id
ticket_id
service_id
missing_fields
question_draft
status
created_at

Пример:

MISS-1001 | IT-1001 | SVC-VPN | os_version, error_screenshot | Уточните, пожалуйста, версию ОС и приложите скриншот ошибки VPN. | draft | 2026-05-23

Проверка: если нет `os_version`, агент не предлагает техническое решение как финальное.

Шаг 17. Найдите kb_matches

В `kb_matches` добавьте колонки:

match_id
ticket_id
article_id
article_title
url
match_score
matched_terms
safe_to_share
created_at

Правила:

1. показывайте сотруднику только `allowed_for_employee = true`;
2. не используйте статьи со статусом `draft`;
3. не показывайте админские команды обычным сотрудникам;
4. если `match_score < 0.7`, отправляйте `manual_review`.

Проверка: агент не вставляет в ответ внутренние инструкции для админов.

Шаг 18. Проверьте SLA в sla_risk_log

Условия риска:

now > sla_due_at - sla_warning_minutes
и status не in resolved, closed

или:

priority = critical и resolver_group_id пустой

В `sla_risk_log` добавьте колонки:

risk_id
run_id
ticket_id
sla_due_at
minutes_left
risk_level
risk_reason
recommended_action
owner
status
created_at

`risk_level`:

low
medium
high
critical

Проверка: тикет за час до SLA попадает в `sla_risk_log`.

Шаг 19. Найдите массовый инцидент в incident_log

Сгруппируйте новые тикеты за `incident_cluster_window_minutes`.

Признаки:

same service_id
same error text
same location
same time window
same asset type

В `incident_log` добавьте колонки:

incident_id
run_id
service_id
summary
ticket_ids
affected_count
location
risk_level
owner_group_id
status
created_at
resolved_at

Статусы:

suspected
confirmed
investigating
resolved
false_positive

Проверка: 5 тикетов по VPN за 30 минут создают `suspected` incident.

Шаг 20. Настройте prompt для LLM triage analysis

В n8n добавьте узел `LLM triage analysis`.

System prompt:

Ты IT Service Desk аналитик. Работай только с переданными данными.
Не выдавай доступы, не сбрасывай пароли, не закрывай тикеты, не запускай команды и не раскрывай внутренние инструкции.
Если данных не хватает, верни status = needs_data.
Любое действие с доступами, статусами, инфраструктурой и ответом сотруднику отправляй в approval.
Ответ возвращай только JSON.

User prompt:

Проанализируй тикет.

ticket:
{{$json.ticket}}

messages:
{{$json.ticket_messages}}

requester:
{{$json.requester}}

service_catalog:
{{$json.service_catalog}}

kb_matches:
{{$json.kb_matches}}

sla:
{{$json.sla_policy}}

assets:
{{$json.asset_inventory}}

Верни JSON:
{
  "ticket_id": "...",
  "status": "needs_data | ready_to_reply | assign_group | access_approval | incident_risk | manual_review",
  "risk_level": "low | medium | high | critical",
  "category": "...",
  "request_type": "incident | service_request | access_request | question | change_request",
  "priority": "low | medium | high | critical",
  "summary": "...",
  "evidence": ["..."],
  "recommended_actions": [
    {
      "action_type": "ask_user | draft_reply | assign_group | create_task | create_access_approval | escalate_incident",
      "owner": "service_desk | network | sysadmin | security | app_owner",
      "text": "...",
      "requires_approval": true
    }
  ]
}

Проверка: ответ валидный JSON и не содержит команды сброса пароля или выдачи доступа.

Шаг 21. Создайте response_drafts

В `response_drafts` добавьте колонки:

draft_id
ticket_id
channel
message_text
kb_article_ids
reason
risk_level
approval_required
status
created_at

Статусы:

draft
sent_to_approval
approved
rejected
sent
manual_only

Пример текста:

Похоже, проблема связана с VPN-клиентом на Windows. Проверьте, пожалуйста, версию ОС и пришлите скриншот ошибки. Пока можно попробовать шаги из инструкции: https://kb.example/vpn-windows.

Проверка: ответ сотруднику не отправляется без approval.

Шаг 22. Создайте access_requests

В `access_requests` добавьте колонки:

access_request_id
ticket_id
requester_id
system_name
requested_role
business_reason
manager_email
system_owner_email
risk_level
approval_required
status
created_at

Статусы:

draft
manager_approval_pending
owner_approval_pending
approved
rejected
manual_only
completed

Проверка: агент не выдает доступ, а создает только черновик и approval.

Шаг 23. Настройте approval_queue

В `approval_queue` добавьте колонки:

approval_id
source
source_id
ticket_id
action_type
action_text
payload_json
risk_level
requested_by
approver
status
requested_at
approved_at
decision_comment

Статусы:

pending
approved
rejected
needs_changes
expired

В approval отправляйте:

1. ответ сотруднику;
2. назначение группы;
3. изменение priority;
4. закрытие тикета;
5. заявку на доступ;
6. сброс пароля;
7. эскалацию security;
8. любое действие с production или админскими правами.

Проверка: без `approved` нет записи в `execution_queue`.

Шаг 24. Сделайте Telegram approval

В n8n добавьте узел `Telegram`.

Сообщение:

IT-1001: VPN, priority medium

Проблема: ошибка 619 при подключении.
Недостает: os_version, screenshot.
Черновик: попросить версию ОС и скриншот, дать ссылку KB-VPN-01.

Approve: /approve IT-1001
Edit: /edit IT-1001
Reject: /reject IT-1001

После `/approve IT-1001` workflow должен:

1. найти `approval_id`;
2. проверить статус `pending`;
3. записать `approved`;
4. заполнить `approved_at`;
5. передать действие в `execution_queue`;
6. записать событие в `audit_log`.

Проверка: `/reject` не отправляет ответ и не меняет тикет.

Шаг 25. Настройте execution_queue

В `execution_queue` добавьте колонки:

execution_id
approval_id
ticket_id
action_type
target_system
payload_json
status
executed_at
result_json
error_message

Статусы:

queued
manual_only
executed
failed
skipped

Для MVP используйте `manual_only`: агент готовит действие, а оператор применяет его в ITSM.

Проверка: пока write-доступ не включен, все действия остаются `manual_only`.

Шаг 26. Создайте task_queue

В `task_queue` добавьте колонки:

task_id
source
source_id
ticket_id
task_type
title
description
owner_group_id
assignee
priority
status
created_at
due_at
closed_at

`task_type`:

ask_user
assign_group
sla_escalation
incident_check
access_review
kb_update
asset_check
manual_triage
security_review

Пример:

TASK-442 | sla_risk_log | SLA-9001 | IT-1001 | sla_escalation | Проверить VPN тикет до SLA | До SLA осталось 42 минуты, группа не назначена | GRP-NET | net_l1 | high | open | 2026-05-23 | 2026-05-23 16:20 | -

Проверка: каждый риск получает владельца и срок.

Шаг 27. Соберите daily_service_desk_report

В `daily_service_desk_report` добавьте колонки:

report_date
new_tickets
triaged_tickets
needs_data
sla_at_risk
sla_breached
incident_suspected
response_drafts
access_requests_pending
tasks_created
summary
created_at

Пример summary:

Сегодня 42 новых тикета, 31 классифицирован, 9 требуют данных от сотрудников, 4 на риске SLA, 1 подозрение на массовый VPN-инцидент, 6 черновиков ответов ждут approval.

Проверка: отчет отправляется service desk lead и дежурному инженеру.

Шаг 28. Настройте audit_log

В `audit_log` добавьте колонки:

event_id
run_id
event_type
ticket_id
actor
input_hash
output_hash
summary
created_at

Пишите события:

run_started
data_loaded
ticket_triaged
kb_matched
missing_data_found
sla_risk_found
incident_suspected
draft_created
approval_requested
approval_approved
task_created
run_finished

Проверка: по `run_id` можно объяснить, почему агент предложил категорию, ответ или эскалацию.

Шаг 29. Настройте error_log

В `error_log` добавьте колонки:

error_id
run_id
step
source_system
ticket_id
error_type
error_message
payload_sample
status
created_at
resolved_at

`error_type`:

api_error
missing_requester
missing_service
missing_sla
unknown_asset
unsafe_action
invalid_json
approval_error
write_error

Проверка: если агент видит действие `reset_password`, оно попадает в `unsafe_action`, а не в исполнение.

Шаг 30. Протестируйте на одном тикете

Создайте тестовый тикет:

tickets:
IT-TEST-001 | jira_service_management | 9001 | REQ-001 | Не работает VPN | Ошибка 619 при подключении из дома | portal | - | - | - | new | - | - | 2026-05-23 09:20 | 2026-05-23 09:20 | 2026-05-23 17:00

ticket_messages:
MSG-1 | IT-TEST-001 | requester | REQ-001 | VPN не подключается, пишет 619 | false | - | 2026-05-23 09:20

kb_articles:
KB-VPN-01 | Как проверить VPN на Windows | https://kb.example/vpn-windows | SVC-VPN | vpn, windows, error619 | Проверка клиента, сети и MFA | true | 2026-05-01 | net_admin | published | 2026-05-23

Ожидаемый результат:

1. в `ticket_triage` появился `SVC-VPN`;
2. в `missing_data_requests` появились `os_version` и `error_screenshot`;
3. в `kb_matches` появилась статья `KB-VPN-01`;
4. в `response_drafts` появился черновик вопроса сотруднику;
5. в `approval_queue` появилась заявка на отправку ответа;
6. в `task_queue` появилась задача, если SLA близко;
7. в `audit_log` есть шаги запуска;
8. в `error_log` нет ошибки.

Проверка: тикет не закрыт, доступы не менялись, пароль не сбрасывался.

Шаг 31. Проверьте негативные сценарии

Сделайте 5 тестов:

1. удалите заявителя из `requesters`;
2. удалите SLA для `SVC-VPN`;
3. добавьте в тикет просьбу “сбросьте пароль”;
4. добавьте статью KB с `allowed_for_employee = false`;
5. верните от LLM невалидный JSON.

Ожидаемый результат:

1. нет заявителя - `missing_requester`;
2. нет SLA - `missing_sla`;
3. сброс пароля - `unsafe_action`;
4. закрытая статья не попадает в ответ сотруднику;
5. невалидный JSON - `invalid_json`;
6. execution не запускается без approval;
7. тикет не закрывается автоматически.

Проверка: агент не заменяет неизвестные данные догадками и не раскрывает закрытые инструкции.

Минимальная проверка результата

Прототип работает, если выполняются условия:

1. `tickets` содержит минимум 10 заявок;
2. `ticket_messages` содержит сообщения;
3. `service_catalog` содержит категории и обязательные поля;
4. `kb_articles` содержит опубликованные статьи;
5. `sla_policies` содержит SLA;
6. `ticket_triage` классифицирует заявку;
7. `missing_data_requests` ловит недостающие поля;
8. `kb_matches` находит безопасную статью;
9. `sla_risk_log` ловит риск просрочки;
10. `incident_log` ловит массовые проблемы;
11. `response_drafts` создает только черновик;
12. `approval_queue` блокирует ответы и доступы;
13. без `approved` нет записи в `execution_queue`;
14. `task_queue` назначает владельца;
15. `daily_service_desk_report` показывает очередь;
16. `audit_log` объясняет действия;
17. `error_log` показывает плохие данные.

Что нельзя автоматизировать в первой версии

• закрытие тикета;
• сброс пароля;
• выдачу доступа;
• изменение роли;
• отключение MFA;
• удаление учетной записи;
• запуск скриптов на серверах;
• изменение сетевых настроек;
• изменение production-инфраструктуры;
• отправку финального ответа без approval;
• раскрытие закрытых инструкций базы знаний;
• удаление истории тикета;
• массовые изменения в ITSM.

Частые вопросы

Можно ли начать без Jira Service Management или Freshservice?

Да. Для MVP хватит Google Forms, Google Sheets, базы знаний и Telegram approval. Но если заявки уже живут в ITSM, лучше подключить ее хотя бы в read-only режиме.

Может ли агент сам закрывать тикеты?

В первой версии нет. Он может предложить закрытие, если есть подтверждение сотрудника и evidence, но финальное действие должен выполнить оператор или отдельная автоматизация с четкими правилами.

Что делать с заявками на доступ?

Агент может проверить обязательные поля, владельца системы, менеджера и обоснование. Выдача доступа должна идти через `access_requests`, approval владельца и audit log.

Как агент не раскрывает внутренние инструкции?

В `kb_articles` используйте поле `allowed_for_employee`. Если статья закрытая или админская, агент может использовать ее только для внутреннего summary, но не вставлять команды в ответ сотруднику.

Какой минимальный результат считать успешным?

Успешный MVP: агент берет один VPN-тикет, определяет категорию, находит безопасную статью, задает уточняющий вопрос, создает черновик ответа, отправляет approval, создает задачу при риске SLA и пишет audit log.