Когда мы начали предлагать наш ИИ-бот корпоративным клиентам, первый вопрос всегда был один и тот же: что будет, если он изменит наши данные? Это обоснованное опасение. У вас есть продакшен-инстанс Odoo, на котором работает весь бизнес — продажи, склад, бухгалтерия, HR. Предоставить ИИ-инструменту доступ к такой системе кажется рискованным. Поэтому мы спроектировали архитектуру так, чтобы боту было физически невозможно что-либо записать, обновить или удалить.
Основа проста: бот подключается к Odoo по XML-RPC через выделенную сервисную учётную запись с правами исключительно на чтение. Это не программный переключатель, который можно случайно сдвинуть. Пользователю Odoo, назначенному для бота, настроены специальные права доступа на уровне моделей — чтение только тех моделей, которые одобрил клиент, и нулевые права на запись, создание и удаление чего бы то ни было. Даже если в нашем коде появится ошибка, пытающаяся выполнить запись, собственный уровень контроля доступа Odoo отклонит её с AccessError.
Мы пошли дальше одних только прав Odoo. В интеграционном слое бота вообще не реализованы методы записи. Созданный нами XML-RPC-клиент предоставляет только операции search_read, fields_get и read. Во всём кодовой базе нет ни одного вызова execute_kw для create, write или unlink. Это эшелонированная защита: даже если кто-то скомпрометирует наш прикладной слой, инструментов для изменения данных в развёрнутом коде попросту не существует.
Хранение учётных данных было ещё одним критически важным решением. Все данные подключения клиента к Odoo — URL, название базы, API-ключ — шифруются в состоянии покоя алгоритмом AES-256-GCM. Ключи шифрования хранятся отдельно от зашифрованных данных по принципу envelope encryption. Для каждой операции шифрования используется уникальный вектор инициализации, поэтому даже идентичные учётные данные двух клиентов превращаются в совершенно разный шифротекст.
Сами API-ключи заслуживают отдельного внимания. Мы используем встроенную систему API-ключей Odoo вместо хранения паролей. API-ключ можно мгновенно отозвать из админ-панели Odoo клиента без какого-либо участия с нашей стороны. Если клиент захочет отключить доступ бота, он просто удаляет API-ключ, и бот сразу перестаёт работать. Без тикетов, без ожидания, без зависимости от нас.
Данные в процессе передачи защищены TLS 1.3 для всех соединений между сервером бота и инстансами Odoo клиентов. Мы принудительно проверяем сертификаты — никаких пропусков SSL-проверок даже в разработке. Сам сервер бота работает на изолированном VPS Hetzner с минимальной поверхностью атаки: никаких лишних открытых портов, аутентификация только по SSH-ключам, автоматические обновления безопасности.
Часто IT-команды спрашивают, используются ли данные клиентов для обучения ИИ-моделей. Ответ — нет, и архитектура это гарантирует. Когда пользователь задаёт боту вопрос, мы запрашиваем нужные данные из Odoo клиента, форматируем их в промпт, отправляем в API Claude и возвращаем ответ. Мы не сохраняем результаты запросов за пределами сессии диалога. Мы не агрегируем данные для обучения. Условия API Claude прямо указывают, что входные и выходные данные API не используются для обучения моделей.
Сама история диалога хранится в нашей базе с тем же шифрованием AES-256-GCM, что и учётные данные. Диалоги привязаны к конкретным пользователям Telegram и автоматически удаляются через 30 дней. Клиент может запросить немедленное удаление всех своих диалоговых данных, и мы выполним это в течение нескольких минут.
Ещё один уровень защиты, который многие упускают, — правила записей (record rules) в Odoo. Даже при правах на чтение record rules могут ограничивать, какие записи видит пользователь бота. Клиент может настроить свою Odoo так, чтобы бот видел только записи определённых компаний в мульти-компанийной структуре, или только одобренные / опубликованные товары, или только определённые категории сотрудников. Бот автоматически наследует все эти ограничения, потому что работает как обычный пользователь Odoo.
Мы также реализовали ограничение частоты запросов на нескольких уровнях. Бот ограничивает число запросов на пользователя в минуту, чтобы предотвратить злоупотребления. Ограничивает общее число запросов на организацию в час, чтобы избежать непредвиденных расходов. И имеет глобальный лимит для защиты нашей инфраструктуры. Если какой-либо лимит достигнут, бот вежливо сообщает об этом, и пользователь может повторить запрос чуть позже.
Для клиентов в регулируемых отраслях мы предоставляем подробный ответ на опросник по безопасности и можем организовать аудит нашего кода их командой безопасности. Такой аудит проводился уже три раза, и каждый раз подтверждал, что архитектура только на чтение — это реальность, а не маркетинг. Один из аудиторов особо отметил, что отсутствие методов записи в кодовой базе — редкость: большинство систем реализуют методы записи, а затем пытаются блокировать их на уровне разрешений, что по определению менее безопасно.
Практический результат всего этого: наш бот обработал более 10 000 запросов к инстансам Odoo клиентов без единого инцидента с данными. Никаких случайных записей, утечек или несанкционированного доступа. Архитектура только на чтение — это не просто функция безопасности, а ключевой принцип продукта, который делает возможным его внедрение в корпоративном сегменте.