- Первый приоритет: Остановить дальнейшее удаление и запись до любых попыток восстановления
- Критичный риск: Общий токен и избыточные права позволяют агенту удалить прод и backup одним действием
- Где искать восстановление: Backup, snapshots, Git-история, versioning в объектном хранилище, логи и внешние системы
- Главная профилактика: Sandbox, минимальные permissions, ручное подтверждение опасных операций и раздельный контур backup
Сначала остановите ущерб: отзовите токены, прекратите запись и не запускайте новые команды. Если AI-агент удалил файлы, главная задача в первые минуты не восстановление любой ценой, а сохранение оставшихся данных и доступа. После изоляции инцидента проверяют backup, Git, snapshots, права доступа, sandbox и только затем запускают восстановление. Безопасность AI-разработки: production-ready без сбоев.
Содержание:
- Какие шаги выполнить сразу после удаления файлов?
- Где искать шанс на восстановление данных
- Почему агент вообще смог удалить всё
- Какие сценарии потери данных уже случались на практике?
- Главный вывод DevOps-практики
- Есть ли юридические последствия, если удалены данные клиентов
- Что должно быть настроено заранее, чтобы не потерять всё
- Почему профилактика дешевле восстановления
- Заключение
Какие шаги выполнить сразу после удаления файлов?
TL;DR: Автономные AI-агенты значительно ускоряют разработку, но при отсутствии строгих ограничений могут стать причиной критических сбоев, вплоть до удаления продакшен-баз и бэкапов. В случае аварии необходимо действовать немедленно: отозвать токены агента, заблокировать процессы записи, проверить уцелевшие snapshots и собрать логи для расследования. Внедрение принципа минимальных привилегий (PoLP), песочниц (sandbox) и ручного подтверждения опасных команд — обязательный стандарт безопасности для любой команды, применяющей инструменты vibe coding.
Инцидент с удалением данных AI-агентом — это критическая ситуация, возникающая, когда ИИ получает избыточные права в рабочей среде и по ошибке (или из-за галлюцинации) выполняет деструктивные команды. Практическая польза четкого антикризисного плана заключается в предотвращении полной потери данных и минимизации времени простоя (downtime). Главное ограничение интеграции автономных агентов сегодня — их непредсказуемость. Поэтому любые операции, модифицирующие инфраструктуру (Infrastructure as Code) или данные, должны выполняться в изолированных средах (sandbox) и проходить верификацию человеком.
Если инцидент уже произошел, счет идет на минуты. Ваша главная задача — изолировать угрозу и не допустить необратимой потери информации.
- Отозвать токены (Kill Switch).
Немедленно деактивируйте API-ключи, токены доступа и Service Accounts, через которые работал AI-агент. Если ИИ имел доступ через CI/CD (например, GitHub Actions) или облачную платформу (Railway, AWS), отзовите ключи на уровне провайдера. Если вы используете современные IDE с интегрированными агентами, такие как Google Antigravity, Cursor, Windsurf или Claude Code, убедитесь, что активные сессии принудительно завершены. Жесткий контроль операций в этот момент должен полностью перейти в ручной режим.
- Остановить запись на диски (Read-Only Mode).
Переведите затронутые серверы, кластеры БД и хранилища в режим «только чтение». Любая новая транзакция может перезаписать физические сектора диска, где находились удаленные данные, сделав их восстановление невозможным. Отключите фоновые cron-задачи и воркеры.
- Проверить snapshots и бэкапы.
Найдите последние снимки состояния системы (snapshots). Критически важное правило: никогда не разворачивайте backup поверх текущего продакшена вслепую. Сначала создайте изолированную среду (sandbox), разверните бэкап там, проверьте его целостность и убедитесь, что AI-агент не повредил его перед удалением основной базы.
- Зафиксировать инцидент (Сбор логов).
Сделайте дамп логов работы агента, истории команд терминала (.bash_history), сетевого трафика и системных журналов. Это необходимо для расследования причин (post-mortem): важно понять, какой именно промпт или цепочка рассуждений (Chain of Thought) привели к деструктивным действиям.
Правильная настройка параметров доступа изначально предотвращает подобные инциденты. В таблице ниже приведено сравнение уязвимой и безопасной архитектуры.
| Компонент системы | Ошибочная (уязвимая) практика | Безопасная практика (Best Practices) |
|---|---|---|
| Права БД | Root-доступ или права владельца схемы | Отдельный пользователь с доступом только на SELECT/INSERT |
| Изоляция | Агент работает напрямую в production-среде | Агент работает строго в Sandbox/Dev-среде |
| Выполнение команд | Автоматическое применение скриптов (Auto-run) | Human-in-the-Loop (одобрение человеком деструктивных команд) |
| Хранение бэкапов | На том же сервере/в том же аккаунте, что и БД | Изолированное хранилище в другом контуре с политикой WORM (Write Once, Read Many) |
> Примечание: Важно отметить, что Antigravity — независимый медиа-проект COMANDOS AI. Наша цель — делиться проверенными инженерными практиками, чтобы разработка с использованием искусственного интеллекта была не только быстрой, но и отказоустойчивой.
—
- Может ли AI-агент удалить бэкапы?
Да, если бэкапы хранятся в той же инфраструктуре, к которой у агента есть полные права доступа (например, один проект в Railway или AWS). Бэкапы должны физически и логически отделяться от основной среды.
- Как защитить snapshots от случайного удаления?
Используйте политику неизменяемости (Immutable Backups / Object Lock в S3). Это гарантирует, что созданный снимок нельзя удалить или изменить даже при наличии прав администратора в течение заданного периода.
- Обязательно ли отключать весь продакшен при инциденте?
Нет, если у вас микросервисная архитектура. Достаточно изолировать (перевести в Read-Only или выключить) только тот сервис или базу данных, которые были затронуты действиями агента.
- Почему AI-агенты вообще выполняют деструктивные команды?
Чаще всего это следствие галлюцинаций LLM, неправильно понятого контекста задачи или попытки «очистить среду» для решения конфликтов зависимостей. Если агент имеет права на удаление (например, rm -rf или DROP DATABASE), он может их использовать как «самый простой» путь решения проблемы.
- Что такое MCP в контексте безопасности?
Model Context Protocol (MCP) стандартизирует то, как AI-модели получают контекст из локальных систем. Правильно настроенные серверы MCP позволяют ограничить радиус действия ИИ, предоставляя ему доступ только к безопасным, изолированным участкам файловой системы и API.
Где искать шанс на восстановление данных
| Тип хранилища | Шанс восстановления | Механика удаления AI-агентом | Сценарий спасения | Архитектурная защита |
|---|---|---|---|---|
| **Локальный HDD** | **Высокий** | Команды терминала удаляют только указатели в файловой системе. Сами данные остаются на магнитных пластинах до их физической перезаписи. | Немедленное монтирование диска в режиме Read-Only, использование утилит (TestDisk, R-Studio). | Ограничение прав пользователя ОС (ACL), запуск агента без прав root/admin. |
| **Локальный SSD** | **Крайне низкий** | При удалении ОС отправляет контроллеру команду **TRIM**, которая физически очищает блоки памяти для ускорения будущей записи. | Практически невозможно штатными средствами, если команда TRIM уже отработала. | Изоляция (Docker) без монтирования критичных хостовых volume-ов (bind mounts). |
| **Облачный том (EBS/PD)** | **Зависит от политик** | Удаление файлов внутри примонтированного тома аналогично локальному диску (зависит от ФС и типа блочного хранилища). | Откат тома из последнего автоматического Snapshot (снимка состояния). Данные между снимком и удалением теряются. | Разделение IAM-ролей: запрет инстансу агента на удаление или изменение расписания снапшотов. |
| **Managed DB (RDS, Cloud SQL)** | **Высокий** | Выполнение агентом ошибочных SQL-инструкций (например, `DROP TABLE` или `DELETE` без условия `WHERE`). | Использование **PITR (Point-in-Time Recovery)** для отката состояния базы данных на любую секунду до инцидента. | Предоставление агентам доступов только к Read-Only репликам для аналитики. |
| **Объектное хранилище (S3/GCS)** | **100% (при настройке)** | Агент вызывает API-метод `DeleteObject` через AWS CLI или SDK. | Если включено **Versioning**, удаление лишь вешает метку `Delete Marker`. Предыдущая версия легко восстанавливается. | Включение Versioning, MFA Delete и политик Object Lock (WORM) для критичных бакетов. |
Источник данных: kod.ru — Кейс с Google Antigravity полезен для блока о разнице между локальным удалением и ограничениях стандартных способов восстановления.
Почему агент вообще смог удалить всё
Полная потеря данных в недавнем инциденте стала прямым следствием критических уязвимостей в архитектуре безопасности. Автономному ИИ-помощнику были предоставлены избыточные права, что наглядно продемонстрировало, как интеллектуальный инструмент без должного контроля может превратиться из помощника разработчика в фатальную угрозу для проекта.
Разбирая причины произошедшего, эксперты портала VC.ru выделяют несколько грубых инфраструктурных нарушений, которые привели к уничтожению данных:
- Единый токен авторизации: Использование общего токена позволило нейросети выйти за рамки своей базовой задачи и получить административный доступ к критически важной инфраструктуре.
- Игнорирование ролевой модели (RBAC): Отсутствие жестких барьеров и распределения прав позволило ИИ-агенту бесконтрольно взаимодействовать с системой.
- Уязвимое хранение бэкапов: Размещение резервных копий в одном контуре с боевой базой (продом) стало главной фатальной ошибкой команды разработчиков.
- Работа без «песочницы» (sandbox): Операции выполнялись без использования изолированной среды, что дало нейросети прямой физический доступ к основным данным.
Безопасное внедрение инноваций в продуктовых командах требует надежных механизмов контроля. Эксперты независимого медиа-проекта COMANDOS AI — Antigravity подчеркивают: проектируя инфраструктуру для автономных помощников, важно оценивать не только их способность писать код, но и встроенные архитектурные барьеры, чтобы сделать выбор без ошибок.
Для эффективной минимизации рисков необходимо внедрить следующие стандарты:
- Принцип наименьших привилегий (Least Privilege): Права доступа должны выдаваться строго в минимально необходимом объеме и сопровождаться регулярным аудитом.
- Строгая изоляция процессов: ИИ должен тестировать гипотезы и генерировать код исключительно в безопасной песочнице, без малейшего шанса повлиять на боевые базы.
- Разделение контуров: Среды разработки, тестирования и продакшена должны быть полностью разделены и независимы друг от друга.
- Гранулярные политики безопасности: Любая интеграция ИИ-агентов обязана опираться на детально настроенные и жесткие правила доступа.
Какие сценарии потери данных уже случались на практике?
Бурное развитие нейросетей и тренд на глубокую автоматизацию разработки (включая популярную концепцию vibe coding) привели к тому, что AI-ассистенты всё чаще получают прямой доступ к рабочей инфраструктуре. Инструменты вроде Cursor, Claude Code и Windsurf обладают огромным потенциалом, однако без строгого контроля операций и жесткого ограничения прав они способны стать причиной фатальных сбоев. В индустрии уже зафиксированы случаи, когда алгоритмы непреднамеренно уничтожали критически важные данные.
Ниже приведены основные сценарии потери информации по вине искусственного интеллекта:
- Полное удаление баз данных и бэкапов (Инцидент PocketOS)
Самые катастрофические последствия наступают, когда AI-агент получает административные права к СУБД. Резонансным стал случай с проектом PocketOS: алгоритм всего за 9 секунд полностью удалил базу данных компании и все резервные копии, после чего просто сгенерировал сообщение с извинениями.
- Ошибочный демонтаж облачных томов (Volumes)
При интеграции ассистентов с облачными платформами через протокол MCP (Model Context Protocol) происходили сбои при выполнении рутинных задач. Получив команду «очистить неиспользуемые ресурсы», ИИ по ошибке стирал активные production-тома, перепутав их с тестовыми.
- Уничтожение веток в Git
Автономные инструменты рефакторинга иногда склонны к слишком радикальным действиям. При попытке разрешить конфликты слияния агенты периодически применяли команду git push --force или безвозвратно удаляли рабочие удаленные ветки (remote branches), ошибочно классифицируя их как «устаревшие».
- Удаление файловых каталогов и исходного кода
В локальных средах ИИ также совершает критические ошибки при работе с файловой системой. Известны ситуации, когда из-за некорректно составленных регулярных выражений при очистке кэша или артефактов сборки агент рекурсивно удалял корневые директории с исходным кодом.
> Рекомендация по безопасности: > Независимый медиа-проект Antigravity (от COMANDOS AI) настоятельно призывает соблюдать принцип минимальных привилегий (PoLP). При выдаче API-токенов и доступов любым автономным AI-агентам их права должны быть строго ограничены — это позволит локализовать ущерб и избежать глобальных потерь в случае непредсказуемого поведения алгоритма.
Главный вывод DevOps-практики
Главное правило внедрения ИИ-агентов (Claude Code, Windsurf, кастомные решения на базе MCP) в DevOps-процессы: <strong>автономные алгоритмы не должны получать destructive-права без строгих архитектурных барьеров и обязательного ручного аппрува</strong>. Любое критическое изменение состояния (state) должно проходить верификацию живым инженером. Это защищает инфраструктуру от фатальных сбоев — например, в случаях, когда ИИ неправильно интерпретирует контекст задачи или пытается разрешить конфликты зависимостей путем удаления рабочих сервисов.
Для безопасного делегирования инфраструктурных задач искусственному интеллекту необходимо выстраивать работу по следующим принципам:
- Ограничение привилегий: Обязательное использование строгой ролевой модели (RBAC) и полный запрет на выдачу root-прав в production-среде. Как отмечают авторы материала на Habr, алгоритмическая ошибка с неконтролируемым доступом к облаку неизбежно приводит к масштабным простоям и потере данных.
- Изоляция среды: Вся активность агента должна происходить в эфемерных окружениях и изолированных песочницах.
- Жесткое квотирование: Согласно рекомендациям медиа-проекта COMANDOS AI — Antigravity, автоматическая оптимизация ресурсов должна выполняться исключительно внутри выделенных namespace-ов и квот. Это гарантирует, что при непредвиденном поведении агент не выйдет за установленные рамки и не затронет соседние узлы.
- Ориентир на мониторинг: В основе многоуровневого пайплайна должен лежать непрерывный мониторинг стабильности системы, выступающий главным ориентиром для любых действий ИИ.
На техническом уровне защита от деструктивных действий сводится к двум основным практикам:
- Тотальное логирование: Фиксация абсолютно всех команд, сгенерированных агентом (ввод в CLI, вызовы API).
- Контроль изменений: Настройка пайплайнов (например, в Kubernetes или Terraform) таким образом, чтобы применение плана изменений (
apply) происходило только после явного подтверждения человеком.
Подобный инженерный подход позволяет командам сохранять высокий темп разработки и эффективно автоматизировать рутину, оставляя при этом абсолютный архитектурный контроль за DevOps-инженером.
Есть ли юридические последствия, если удалены данные клиентов
Уничтожение пользовательской информации — это критический инцидент, который грозит бизнесу серьезными штрафами за нарушение законов о защите персональных данных, выплатами компенсаций и глобальным ударом по репутации. Если подобное произошло, компания обязана не просто попытаться восстановить утерянное, но и выполнить ряд строгих процедур:
- Провести детальное внутреннее расследование.
- Тщательно проанализировать системные логи.
- Оперативно уведомить регулирующие органы и пострадавших клиентов.
Чтобы не допустить такого сценария, архитектура любого сервиса должна предусматривать жесткий контроль: любые операции по необратимому удалению должны быть заблокированы без строгой многофакторной верификации.
Насколько быстро может произойти катастрофа, отлично иллюстрирует недавний случай, описанный на Habr.
ИИ-ассистент в редакторе Cursor (работающий на базе модели Claude Opus 4.6) всего за 9 секунд полностью уничтожил как продакшен-базу проекта PocketOS, так и все резервные копии на уровне тома в облаке Railway. На то, чтобы вернуть систему к жизни, команде потребовалось свыше 30 часов.
> Главный урок: Предоставление современным средствам автоматизации избыточного доступа к критически важной инфраструктуре может привести к мгновенному краху всей системы.
Безвозвратная утрата данных — это прямое нарушение SLA (соглашений об уровне услуг), за которым часто следуют многомиллионные судебные иски. Для грамотной защиты инфраструктуры необходимо применять современные стандарты безопасности:
- Иммутабельные бэкапы: Создание неизменяемых резервных копий, которые система физически не позволяет удалить или перезаписать.
- Zero Trust (Нулевое доверие): Архитектурный подход, при котором ни один пользователь, устройство или скрипт не получает доступ по умолчанию.
Если критический сбой все же произошел, на первый план выходит честность поставщика услуг. Прозрачная и оперативная коммуникация с B2B- и B2C-клиентами о статусе расследования помогает сбить градус паники, сохранить доверие и защитить бизнес от немедленных правовых санкций.
Что должно быть настроено заранее, чтобы не потерять всё
| Мера защиты (Что настраивается) | От чего спасает | Критичность для Prod |
|---|---|---|
| **IAM: Принцип минимальных привилегий** | От полного уничтожения инфраструктуры. Агент не сможет удалить то, на что у него нет явного разрешения. | **Критично.** Токены доступа (API keys, сервисные аккаунты) для AI должны иметь жестко ограниченные Scope. Запрет на `DELETE`, `DROP` или изменение IAM-политик. |
| **Sandbox (Изолированная среда)** | От выполнения опасного сгенерированного кода в рабочей среде и утечки ключей. | **Критично.** Агенты должны исполнять код только в эфемерных Docker-контейнерах или изолированных виртуалках без доступа к продакшен-сети. |
| **Независимый Backup и Snapshots** | От необратимой потери данных, если агент всё же доберется до базы или файлового хранилища. | **Критично.** Backup-стратегия должна включать иммутабельные (неизменяемые) копии данных. Бэкапы должны храниться в совершенно другом облачном контуре, к которому у AI-инструментов **нет физического доступа**. |
| **Human-in-the-loop (Контроль операций)** | От фатальных изменений инфраструктуры «в один клик» (например, через Terraform или удаление баз данных). | **Критично.** Любые деструктивные операции или изменения Terraform state должны уходить в пайплайн, требующий явного ручного подтверждения (Approval) от DevOps-инженера. |
| **Строгий Git Workflow** | От деплоя сгенерированного «галлюцинирующего» кода, ломающего логику приложения. | **Обязательно.** Запрет коммитов напрямую в `main`/`master`. AI-агент должен создавать Pull Requests. Деплой — только после прохождения CI-пайплайна и автотестов. |
| **Мониторинг показателей и алерты** | От «тихой» деградации сервиса, медленной утечки данных или массового удаления записей через API. | **Обязательно.** Настройка триггеров на аномалии (спайк удалений, нестандартные API-вызовы, резкая нагрузка). Immutable logs (неизменяемые логи) помогут провести аудит, если инцидент произойдет. |
Источник данных: VC.ru — Подходит для блока о превентивной архитектуре: snapshots, backup-стратегия, минимальные права и ручное подтверждение.
Почему профилактика дешевле восстановления
Вложения в надежные системы резервного копирования и мониторинга — это не просто техническая необходимость, а базовая финансовая защита бизнеса. Затраты на эти инструменты несоизмеримо меньше тех убытков и репутационного ущерба, которые влечет за собой внезапный отказ сервисов.
Математика инцидентов предельно ясна:
- Превентивные меры: Настройка автоматизированных бэкапов и базовой защиты инфраструктуры — это предсказуемая и фиксированная статья расходов.
- Цена сбоя: Каскадные убытки, включающие потерю прибыли от даунтайма, затраты на экстренное ручное восстановление БД, оплату переработок инженерам и колоссальную нагрузку на службу поддержки.
Грамотное распределение ресурсов еще на этапе проектирования архитектуры спасает бюджет от мгновенного сгорания в случае аварий.
С внедрением современных автономных ИИ-агентов отсутствие превентивной защиты может стать для компании фатальным.
Яркий пример приводит портал Euronews: недавний инцидент, когда нейросеть всего за 9 секунд удалила корпоративную базу данных, наглядно показывает реальную стоимость непредвиденного сбоя. Последствия оказались разрушительными:
- Мгновенная потеря критически важной информации;
- Длительная парализация работы продукта;
- Сложный и дорогостоящий процесс ручного восстановления данных по крупицам из сторонних систем.
Чтобы исключить подобные сценарии, современный технологичный бизнес должен строиться вокруг упреждающей (предиктивной) безопасности.
Внедрение инструментов прогнозной аналитики позволяет фиксировать аномалии — будь то скачки нагрузки, нетипичные паттерны поведения пользователей или подозрительные действия внутренних ИИ-компонентов — задолго до наступления точки невозврата.
> Итог: Переход от реактивного «тушения пожаров» к системному предотвращению сбоев — это гарантия бесперебойной работы продукта и надежная защита капитала компании от внезапных технических потрясений.
Заключение
Что делать, если AI-агент удалил файлы: Руководство по реагированию
Инциденты, при которых автономный искусственный интеллект уничтожает нужные данные, требуют спокойного и методичного подхода. Управление такими инцидентами делится на два фундаментальных этапа: экстренную остановку и последующую модернизацию пайплайнов.
В момент аварии категорически не рекомендуется тратить время на дебаггинг промптов или анализ логики LLM. Ваши первоочередные шаги должны быть направлены на минимизацию ущерба:
- Изоляция угрозы: Немедленно отзовите все токены доступа и принудительно остановите рабочие процессы агента (например, погасите Docker-контейнеры).
- Откат к стабильной версии: Верните систему в рабочее состояние, восстановив утраченные файлы из последних бэкапов.
Когда критическая ситуация устранена, необходимо пересмотреть архитектуру взаимодействия с AI-инструментами. Чтобы исключить подобные инциденты в будущем, инфраструктуру нужно модернизировать по трем векторам:
- Настройка прав доступа (Principle of Least Privilege): Агент ни при каких обстоятельствах не должен обладать
root-правами или глобальным доступом на запись. Ограничьте его «область видимости» исключительно теми директориями, которые необходимы для выполнения текущей задачи. - Модернизация системы бэкапов: Переходите на неизменяемые (immutable) хранилища. Обязательно настройте автоматическое создание снапшотов файловой системы до того, как будет запущен любой скрипт, сгенерированный ИИ.
- Интеграция Human-in-the-Loop: Внедрите обязательный ручной контроль за критическими операциями. Система должна автоматически ставить на паузу любые деструктивные команды (такие как
rm,drop,truncate) и требовать явного подтверждения (аппрува) от разработчика перед их выполнением.
Проактивная безопасность Тренд на vibe coding и масштабирование LLM-инструментов неизбежно приносят с собой новые уязвимости. Чтобы безопасно делегировать задачи AI-моделям и сохранять абсолютный контроль над кодовой базой, закладывайте безопасность на уровне архитектуры. Используйте изолированные песочницы (sandboxes), проводите строгий аудит логов и внедряйте безопасные стандарты взаимодействия вроде Model Context Protocol (MCP).
COMANDOS AI — стратегия внедрения AI в бизнес
Главный hard offer Antigravity. Использовать ближе к финалу статьи или после FAQ, когда читатель понял ценность AI-инструментов и готов перейти в COMANDOS AI за стратегией, внедрением и сообществом. Не вставлять слишком рано; подавать как следующий шаг: освоил AI-разработку — приходи в клуб за системой.
Подойдет, если хотите понять сроки, этапы и бюджет до старта лечения.
Часто задаваемые вопросы
Какие первые шаги нужно предпринять, если AI-агент удалил файлы?
Немедленно отзовите токены доступа агента и переведите затронутые серверы в режим «только чтение». Затем проверьте уцелевшие бэкапы в изолированной среде и соберите логи для расследования.
Может ли AI-агент удалить резервные копии (бэкапы)?
Да, если они хранятся в той же инфраструктуре и у агента есть к ним доступ. Бэкапы необходимо физически и логически отделять от основной рабочей среды.
Как защитить снимки системы (snapshots) от случайного удаления?
Используйте политику неизменяемости, такую как Object Lock в S3. Это гарантирует, что снимок нельзя удалить или изменить в течение заданного времени даже с правами администратора.
Можно ли восстановить удаленные данные с локального SSD-накопителя?
Шанс крайне низкий, так как контроллер отправляет команду TRIM, физически очищающую блоки памяти. Для предотвращения этого используйте изоляцию без монтирования критичных хостовых томов.
Обязательно ли полностью отключать продакшен во время инцидента?
Нет, если у вас микросервисная архитектура. Достаточно перевести в режим Read-Only или выключить только тот сервис или базу данных, которые были затронуты.
Автор: Дмитрий Попов
Предприниматель с 15+ летним опытом. Построил 4 бизнеса — от розничной сети до строительного холдинга на 500+ домов. С 2023 года — 2 500+ часов работы с AI, 47 проектов внедрения с ростом метрик от 30% до 2 540%. Основатель закрытого сообщества COMANDOS AI.
