Как конечные автоматы делают AI-автоматизацию безопасной

Почему AI-автоматизация требует явных ограничений

AI-агенты всё чаще берут на себя выполнение бизнес-процессов, но полагаться на то, что нейросеть сама «догадается» о правильной последовательности шагов, рискованно. Когда workflow живёт только в промптах, его невозможно толком протестировать, аудировать или верифицировать. Решение — сделать процесс явным с помощью конечного автомата (finite state machine, FSM).

Проблема: бизнес-правила не должны жить в промптах

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

Решение: конечный автомат как явная модель workflow

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

Состояния: Черновик → Отправлен → Согласован → Закуплен
Переходы: Отправить, Согласовать, Отклонить, Запросить информацию

Когда процесс находится в состоянии «Отправлен», AI видит только три допустимых действия: «Согласовать», «Отклонить», «Запросить информацию». Ему не нужно изобретать workflow — он лишь выбирает наиболее подходящий вариант из разрешённых.

Реализация на Python: простой конечный автомат

class PurchaseFSM:
    def __init__(self):
        self.state = 'draft'
        self.transitions = {
            'draft': ['submit'],
            'submitted': ['approve', 'reject', 'request_info'],
            'approved': ['purchase'],
            'rejected': [],
            'purchased': []
        }

    def transition(self, action):
        if action in self.transitions[self.state]:
            print(f'Переход из {self.state} по действию {action}')
            # логика перехода
            if action == 'submit':
                self.state = 'submitted'
            elif action == 'approve':
                self.state = 'approved'
            elif action == 'reject':
                self.state = 'rejected'
            elif action == 'request_info':
                # остаёмся в том же состоянии, но запрашиваем данные
                pass
            elif action == 'purchase':
                self.state = 'purchased'
        else:
            raise ValueError(f'Недопустимое действие {action} в состоянии {self.state}')

# Пример использования AI-агентом
fsm = PurchaseFSM()
fsm.transition('submit')  # OK
fsm.transition('approve')  # OK
fsm.transition('purchase') # OK
# fsm.transition('reject')  # Ошибка: reject недопустим в состоянии approved

Явные ограничения = явный контекст для AI

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

Верифицируемость: FSM — это не просто документация

В отличие от промпта, конечный автомат — формальная модель, которую можно верифицировать до того, как AI начнёт работу. Можно проверить:

• Может ли процесс попасть в невалидное состояние?
• Есть ли тупиковые состояния?
• Все ли согласования обязательны?
• Может ли действие выполниться дважды?
• Определены ли пути отката?
• Обработаны ли все сценарии сбоев?
• Может ли каждый процесс завершиться?

Эти свойства проверяются независимо от AI. Промпт описывает процесс, а FSM определяет и ограничивает его. FSM становится исполняемой границей безопасности вокруг AI.

AI работает внутри верифицированных границ

Цель — не сделать AI детерминированным (это невозможно), а сделать детерминированным окружение, в котором он работает. Без явного workflow AI постоянно спрашивает: «Что делать дальше?» С FSM разговор меняется: workflow говорит «Вот единственные допустимые действия», а AI отвечает «Какое из них наиболее подходящее?» Это тонкий, но важный архитектурный сдвиг: AI больше не владеет процессом, он навигирует по нему.

Интеграция с MCP

Если вы используете Model Context Protocol (MCP), FSM раскрывает своё текущее состояние и доступные переходы как инструменты. AI может динамически узнавать, какие действия разрешены, какие данные требуются, какие правила валидации действуют. Изменение бизнес-процесса сводится к обновлению модели FSM, а не к переписыванию промптов. AI автоматически получает новые ограничения как часть контекста.

Явные ограничения резко снижают операционные риски

Большие языковые модели вероятностны, а бизнес-процессы — нет. FSM не делает AI умнее, но делает систему безопаснее. Недопустимые переходы становятся невозможны, каждое изменение состояния верифицируемо, каждое решение аудируемо, откат — часть workflow, а compliance-правила явны. AI больше не решает, что возможно, а решает, как навигировать по процессу, чьи границы уже определены.

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

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