Проект_1956 | ИТ-модули для бизнеса

Почему одного доступа к данным мало, чтобы ИИ понял бизнес

Есть довольно понятная мечта руководителя.

Не открывать несколько систем, таблиц и отчётов, а просто спросить ИИ:

«Где сейчас проблема?»
«Что изменилось?»
«Что требует внимания?»
«Можешь сам проверить подробнее?»

На словах всё выглядит просто:

данные + доступ + хороший ИИ = готовый помощник.

Мы решили проверить этот принцип на небольшом масштабе — подключили ИИ к собственной рабочей машине и попробовали сделать так, чтобы он не только рассуждал по описанию, но и разбирался в её фактическом состоянии.

И оказалось, что самое интересное начинается как раз после слова «подключить».

· · ·

Документация и реальность — не одно и то же

В инструкции может быть написано одно, а система уже находится в другом состоянии.

Если ИИ видит только сохранённое описание, он способен дать вполне логичный ответ — просто на уже устаревшую картину.

Поэтому прежде чем делать вывод, ему нужно уметь проверить, что происходит сейчас.

Для бизнеса принцип тот же: странно принимать решение по старому отчёту, не посмотрев актуальные показатели.

· · ·

Доступ ещё не означает полномочия

В процессе стало особенно заметно различие между тремя вещами:

ИИ понимает, что нужно сделать.

ИИ технически может это сделать.

ИИ разрешено это сделать.

Это не одно и то же.

Самый простой технический вариант — дать ИИ полный доступ ко всему.

Но рабочая модель больше похожа на обычного сотрудника.

Посмотреть состояние — можно.

Проверить проблему — можно.

Работать в разрешённой области — можно.

Значимое изменение — уже отдельный уровень контроля.

Самостоятельно расширять свои полномочия — нельзя.

Задача не в том, чтобы дать ИИ максимум возможностей.

Задача — дать ему достаточно возможностей для работы и сохранить понятные границы.

· · ·

Контекст не должен исчезать вместе с чатом

Есть ещё одна проблема.

Сегодня ИИ разобрался в ситуации, что-то проверил и получил полезный контекст.

Завтра начинается новая сессия.

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

Поэтому полезные факты о рабочей среде нужно сохранять.

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

Его нужно сверять с текущим состоянием.

Получается, рабочая память системы должна одновременно сохранять прошлое и позволять перепроверять настоящее.

· · ·

Что это означает для бизнеса

Если однажды мы хотим просто спросить ИИ:

«Что сейчас происходит в моей компании?»

за этим простым вопросом должны находиться как минимум:

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

Хорошая модель и хороший промт здесь только часть решения.

Окно чата — это интерфейс.

Основная работа находится за ним.

· · ·

Красный флаг довольно простой

Если вопрос «что сейчас происходит?» всё ещё требует открыть несколько систем, позвонить сотрудникам и вручную свести данные, проблема начинается ещё до выбора нейросети.

И такой процесс уже имеет смысл разбирать отдельно:

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

· · ·

Проект_1956

ВКонтакте:
vk.com/project_1956

Почта:
info@project1956.ru

Нужен ли бизнес-процессу AI-агент?
⠀
Не всегда.
⠀
И сложность процесса здесь не главный критерий.
⠀
Представим обработку входящей заявки.
⠀
Система должна:
— принять обращение;
— извлечь данные;
— проверить обязательные поля;
— найти клиента;
— определить маршрут;
— подготовить ответ;
— обновить CRM.
⠀
Часть этих операций может выполнять AI.
⠀
Но это ещё не означает, что AI нужно отдавать управление всем процессом.
⠀
Есть три режима.
⠀
Workflow
Последовательность и правила задаются системой заранее.
Подходит там, где процесс повторяемый, маршруты известны и важна воспроизводимость.
⠀
Agent
AI сам определяет следующий шаг, выбирает инструменты и может менять план по результатам предыдущих действий.
Такой режим оправдан там, где маршрут действительно невозможно нормально определить заранее.
⠀
Hybrid
Основной процесс остаётся управляемым, а AI получает свободу только в отдельных участках, где действительно есть неопределённость.
⠀
Для бизнеса отсюда следует простой вопрос:
⠀
не «можем ли мы сделать здесь AI-агента?»,
⠀
а «где именно в процессе нужна автономность?»
⠀
Перед выбором стоит проверить четыре вещи:
- Можно ли определить основные маршруты заранее?
- В каком конкретно месте возникает неопределённость?
- Что произойдёт, если AI выберет неправильный следующий шаг?
⠀
Даёт ли автономность достаточно пользы, чтобы оправдать дополнительную сложность?
⠀
Красный флаг — когда агенту отдают весь процесс только потому, что AI нужен в одном его участке.
⠀
Часто нормальная архитектура выглядит проще:
- известные операции → workflow
- неструктурированные данные → LLM
- неоднозначный участок → agent
- критичные действия → отдельные правила контроля
⠀
Не каждый сложный процесс должен быть автономным.
⠀
Сначала найдите место, где автономность действительно создаёт ценность.

Если сотрудник нажимает «Подтвердить» сто раз в день — это уже не контроль

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

Перед тем как добавлять human approval, руководителю полезно проверить четыре вещи:
1. Можно ли действие отменить?
Если изменение легко откатывается и вся история сохраняется, постоянное подтверждение может быть лишним.
2. Можно ли ошибку поймать автоматически?
Лимиты, суммы, обязательные поля, допустимые статусы и многие другие условия лучше проверять системой.
3. Каков масштаб последствий?
Одна внутренняя запись и массовое изменение клиентских данных требуют разного уровня контроля.
4. Действительно ли человеку есть что оценивать?
Если сотруднику показывают один и тот же стандартный запрос десятки раз, approval быстро превращается в формальность.

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

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

Цель human-in-the-loop — не добавить человека в каждый шаг.
Цель — поставить человеческое решение именно туда, где автоматического контроля недостаточно.

У AI-агента есть инструкция. Но какие права у него на самом деле?

Anthropic недавно разобрала три инцидента во время тестирования своих AI-моделей.

Моделям сообщили, что они работают внутри изолированной симуляции без доступа в интернет.

Фактически интернет оказался доступен из-за ошибки конфигурации.

В результате тестовые агенты начали взаимодействовать уже с реальными системами.

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

Для руководителя здесь есть более полезный вопрос.
Если завтра AI получает доступ к почте, CRM, документам или базе данных — что он может сделать технически?
Не по инструкции.
По правам.

Перед подключением агента стоит проверить:
1. Какие данные он может читать?
2. Что может изменять?
3. Есть ли отдельный сервисный аккаунт?
4. Ограничен ли доступ только необходимыми API?
5. Может ли система обращаться во внешний интернет?
6. Где фиксируется история действий?
7. Каков максимальный ущерб от одной ошибки?

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

Промпт помогает направлять поведение.
Но безопасность начинается с архитектуры.

Проект_1956 | ИТ-модули для бизнеса

Автоматизация работает. Кто заметит, что она ошиблась?

На демонстрации всё выглядит убедительно:

документ поступил
→ данные распознаны
→ информация записана
→ сотрудник получил результат

Но для бизнеса важен не первый успешный запуск.

Важен следующий вопрос: что произойдёт завтра, если изменится документ, обновится внешний сервис или один из этапов молча пропустит данные?

В n8n это называют Day 2 Problem — проблемами, которые проявляются уже после запуска автоматизации.

Представим, что система обрабатывает десять заявок.

Девять прошли успешно. Одна потерялась между этапами.

Технически сценарий завершился. Ошибки на экране нет. Но менеджер не получил заявку, клиент не получил ответ, а руководитель даже не знает, что что-то произошло.

Поэтому перед внедрением полезно проверить не только «работает ли сценарий», но и «можно ли им управлять».

Проверка за 5 минут

1. Кто отвечает за процесс?

Не за разработку, а за результат после запуска.

Должен быть конкретный человек, который понимает, что система делает и когда нужно вмешаться.

2. Где видна история действий?

Можно ли узнать:

— какие данные поступили;
— какие этапы были выполнены;
— где произошёл сбой;
— какой результат получила система.

Если ответ только «надо спросить разработчика», процесс ещё не стал управляемым.

3. Что происходит при ошибке?

Система должна не просто остановиться.

Нужно заранее определить:

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

4. Можно ли отменить изменение?

После обновления сценарий начал работать хуже.

Есть ли предыдущая рабочая версия или придётся восстанавливать всё вручную?

5. Что произойдёт без автора системы?

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

Минимальная документация и понятные доступы нужны даже небольшому проекту.

Красные флаги

Автоматизация ещё не готова к эксплуатации, если:

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

При этом не каждому сценарию нужна сложная инфраструктура.

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

Главный принцип:

чем выше цена ошибки, тем серьёзнее должны быть контроль, откат и резервный процесс.

Вывод Проект_1956

Рабочая автоматизация — это не только алгоритм, который выполняет задачу.

Это управляемый процесс, в котором понятно:

— кто отвечает;
— что произошло;
— где возникла ошибка;
— как восстановить работу;
— что делать человеку при сбое.

Один успешный запуск подтверждает идею.

Способность стабильно работать и восстанавливаться подтверждает систему.

Источник: n8n, «Your AI project WILL break. Welcome to the Day 2 problem», 3 августа 2026 года.

Что будет в этом канале

Проект_1956 — небольшой ИТ-проект.

Здесь мы будем разбирать:

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

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

Поэтому у каждого материала должен быть практический вывод:

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

Параллельно мы разрабатываем небольшие ИТ-модули, ботов и ИИ-помощников. Иногда будем показывать, как подобные решения создаются и какие задачи могут закрывать.

Связь:

Тел.: +7 995 216-99-59
VK: vk.com/project_1956
Email: info@project1956.ru