Сценариум

Электричество не стирает бельё

Что организации нужно уметь, чтобы AI начал регулярно выполнять работу.

Один и тот же вопрос

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

Ответы обычно сводятся к разным комбинациям трёх подходов.

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

Второй — организационный: пересмотреть процессы, роли и порядок работы.

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

Все три подхода описывают разные стороны одной задачи и на практике сочетаются. Их общий объект — сама работа, часть которой организация хочет передать новому исполнителю. Именно её устройство определяет, что нужно менять организационно, что реализовывать технологически и что искать и проверять через эксперименты.

Электричество работу не делает

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

Электричество само не стирает бельё. Оно позволило создать стиральную машину и изменить способ выполнения этой работы.

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

С AI логика та же: какую часть работы мы готовы передать новой технологии или новому исполнителю.

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

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

Отсюда возникает вопрос: что именно нужно определить и зафиксировать, чтобы часть работы можно было передать новому исполнителю и при этом сохранить требования к её результату?

Как на производстве разделяют требования, способ и реализацию

Посмотрим, как аналогичная задача уже решена на производстве. Там давно приходится передавать работу от человека машине и при этом сохранять требования к результату. Для этого отдельно существуют требования к результату, способ его получения и конкретная реализация на оборудовании.

Возьмём пример изготовления детали на станке с числовым программным управлением — ЧПУ.

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

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

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

Оператор выполняет те действия и принимает те решения, которые оставлены человеку. Результат проверяется по заранее установленным требованиям — например, службой ОТК или другим независимым контуром контроля.

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

При смене станка управляющая программа и настройки изменятся. Может измениться и техпроцесс. Требования к самой детали при этом остаются прежними.

Получается три разных объекта:

Такое разделение не уникально. Похожая логика используется и при разработке ИТ-систем. Что меняется в содержании этих трёх объектов, когда часть работы передаётся AI, способному интерпретировать ситуацию и выбирать следующее действие?

Что меняется в требованиях к результату

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

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

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

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

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

Часть таких требований раньше могла вообще не быть записана. Они существовали в профессиональном опыте сотрудников, внутренних нормах, понимании контекста и ответственности за результат.

При передаче работы AI эти требования нужно собрать и сделать явными.

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

Спецификация не описывает, как именно AI должен выполнять работу. Она задаёт требования, которым должен соответствовать любой выбранный способ выполнения.

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

Что меняется в проектировании способа выполнения работы

Спецификация задаёт требования к результату работы. Следующий шаг — спроектировать, как именно AI будет участвовать в её выполнении.

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

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

AI-сценарий проектируется по спецификации работы. Если спецификация определяет недопустимое последствие, AI-сценарий должен определить, каким способом оно будет предотвращено.

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

Например, AI обрабатывает обращения партнёров. В спецификации зафиксировано требование: данные одного партнёра не должны быть раскрыты другому. Из этого требования в AI-сценарии появляется граница: после независимого подтверждения партнёра AI-агент получает доступ только к его данным. Определение того, к каким данным открыть доступ, не должно зависеть от интерпретации самого агента.

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

Поэтому при проектировании AI-сценария организация определяет:

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

Эта работа требует постоянной функции внутри организации — проектирования и сопровождения AI-сценариев. Она управляет распределением работы между AI, кодом и человеком и пересматривает это распределение при изменении задач, требований и возможностей моделей.

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

Конфигурация исполнения

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

Чтобы этот сценарий начал работать, его нужно реализовать в конкретной технической среде.

Назовём такую реализацию конфигурацией исполнения. Она включает все технические элементы, через которые реализуется AI-сценарий: модель и её настройки, программный код, права доступа, интеграции, интерфейсы для участия человека, механизмы проверок, фиксации событий и мониторинга.

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

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

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

Работающая конфигурация принимается по спецификации работы. Проверяется, что собранная система фактически выполняет требования к результату, соответствует критериям приёмки и не приводит к недопустимым последствиям.

От отдельных сценариев к организационной способности

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

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

С AI-исполнителем эта задача становится сложнее: часть его поведения не задаётся заранее полной логикой системы. Поэтому нужно не только описывать требуемый результат, но и искать возможные нежелательные последствия по мере проектирования работы. Часть из них должна становиться требованиями спецификации, часть — закрываться устройством AI-сценария, часть выявляется уже при конкретной реализации и требует изменения конфигурации или возврата к сценарию.

Технологический, организационный и экспериментальный подходы остаются разными сторонами одной задачи. Платформа даёт средства реализации, организационные изменения позволяют встроить новую работу в процессы, эксперименты помогают находить рабочие решения. Общим объектом для всех трёх остаётся сама работа и способ её передачи новому исполнителю.

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

Проверить, появилась ли такая способность, можно несколькими вопросами: