Операционная система компании (Company OS) — это восемь связанных управленческих систем. Они описывают, как организация выбирает ценность, даёт полномочия, исполняет работу, проверяет результат и учится.
Это не восемь технических слоёв. Безопасность, наблюдение и управление проходят через всю модель. Одна система может быть реализована несколькими продуктами, а один продукт может обслуживать несколько систем.
Первая версия руководства предлагала шесть слоёв. Аудит показал, что такая схема смешивала технические компоненты и управленческие обязанности. V2 заменяет её восемью системами, у каждой из которых есть решение, владелец и доказательство. [V1-ch3]
1. Ценность и портфель #
Эта система отвечает на вопрос: какие результаты достойны инвестиций?
В её состав входят результаты для клиента, потоки создания ценности, исходные показатели, портфель сценариев и правила прекращения работ. Владелец портфеля сравнивает не эффектные демонстрации, а подтверждённую пользу, полную стоимость и риск.
Минимальный артефакт — карточка сценария. В ней есть получатель, результат, частота, исходный уровень, цена ошибки и ближайшее решение. Карточка без исходных показателей остаётся идеей.
Проверка системы: можно ли объяснить, почему этот процесс выбран раньше другого и какое наблюдение заставит остановить инвестиции?
2. Люди и полномочия #
Эта система отвечает на вопрос: кто принимает решение, кто исполняет и кто отвечает за итог?
Для каждого значимого действия команда обозначает:
- владельца результата;
- инициатора;
- исполнителя;
- согласующего;
- проверяющего;
- роль, которая может остановить процесс.
ИИ может быть исполнителем. Владельцем результата остаётся человек, а юридическую ответственность несёт организация. В высокорисковом процессе выдачу прав, выполнение действия и проверку по возможности разделяют.
Материалы OECD связывают ответственность и прослеживаемость со всем жизненным циклом ИИ. NIST отдельно рассматривает учётные записи и полномочия программных агентов.
Это поддерживает разделение ролей, но конкретная схема остаётся решением организации. [OECD-AI-accountability] [NIST-2026-agent-id]
Минимальный артефакт — карта полномочий человека и ИИ.
Проверка системы: можно ли по одному действию назвать человека, выдавшего право, служебную учётную запись исполнителя и человека, ответственного за результат?
3. Контекст и память #
Эта система отвечает на вопрос: на каких данных, правилах и прошлых результатах основано решение?
Контекст включает источники, инструкции, действующие правила, историю текущей задачи и результаты инструментов. Для каждого источника записывают владельца, происхождение, разрешённое использование, свежесть и способ отзыва.
Память хранит только то, что понадобится следующему решению. Необработанная история разговоров редко является хорошей памятью: она содержит устаревшие правила, личные данные и случайные предположения.
Минимальный артефакт — реестр источников контекста.
Проверка системы: можно ли для значимого вывода показать использованный источник, его версию и право доступа?
4. Среда исполнения #
Среда исполнения (execution harness) соединяет модель с инструкциями, навыками, инструментами, состоянием, порядком шагов, изоляцией и наблюдением.
Агентом в производственном смысле является вся эта составная система. Свойство модели нельзя переносить на систему без испытания. [G1-D1-p27], The New SDLC With Vibe Coding_Day_1.pdf, с. 27.
Минимальная среда содержит:
- закреплённую модель или правило выбора модели;
- версию основной инструкции;
- список разрешённых навыков;
- ограниченный набор инструментов;
- изолированное место выполнения;
- пределы времени, числа действий и расходов;
- обработку ошибок;
- запись существенных событий.
Рост числа инструментов может ухудшить выбор действия. Из этого не следует, что нужен второй агент. Сначала сузьте инструменты и контекст. [G1-D2-p18], Agent Tools & Interoperability_Day_2.pdf, с. 18.
Минимальный артефакт — версия состава среды с зависимостями.
Проверка системы: может ли другой участник воспроизвести тот же состав без личной сессии разработчика?
5. Контур управления #
Контур управления (control plane) задаёт служебные учётные записи, права, согласования, политики, секреты, пределы расходов и журнал действий.
Критический запрет реализуют программным правилом или механизмом прав, если это возможно. Текст «никогда не делай» внутри инструкции не является достаточным барьером для необратимого действия.
Детерминированное ограничение следует закреплять программой. [G1-D3-p42], Agent Skills_Day_3.pdf, с. 42; [G1-D5-p27], Day_5_v3.pdf, с. 27.
Подключение по стандартному протоколу не создаёт доверия автоматически. Публичный сервер протокола контекста модели нужно проверить как кодовую зависимость и границу доверия до доступа к файлам или учётным данным. [G1-D2-p15] [G1-D2-p16]
Минимальный артефакт — договор о самостоятельности с матрицей прав.
Проверка системы: может ли система физически выполнить запрещённое действие, даже если инструкция просит этого не делать?
6. Проверка и наблюдаемость #
Эта система отвечает на вопросы: допустим ли результат, допустим ли путь и не ухудшается ли поведение?
Она объединяет обычные тесты, наборы оценочных проверок, проверку хода действий, трассировку вызовов инструментов, производственные показатели и разбор отклонений.
Журнал не обязан и не должен обещать доступ к скрытым рассуждениям модели. Достаточно записывать намерение, версии компонентов, входы в допустимом объёме, вызовы инструментов, согласования, состояния и результат.
Для расследования фиксируйте путь от намерения к вызовам инструментов и результату. [G1-D4-p24], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 24.
Минимальный артефакт — план проверок качества и схема наблюдения.
Проверка системы: можно ли воспроизвести существенный сбой и понять, какое действие, право или источник к нему привели?
7. Поставка и эксплуатация #
Эта система отвечает на вопрос: как изменение безопасно проходит от намерения до рабочей среды и как организация восстанавливается после сбоя?
Она включает небольшие изменения, изолированную разработку, рецензирование, условия выпуска по риску, наблюдение после выпуска, откат, дежурство и разбор инцидентов.
ИИ может подготовить описание запроса на слияние. Автор изменения проверяет точность сводки, доказательств и риска. Успешные тесты не дают универсального разрешения на автоматический выпуск.
Минимальный артефакт — маршрут выпуска с условиями для классов риска.
Проверка системы: кто и по какому сигналу остановит выпуск, откатит изменение и сообщит владельцу результата?
8. Управление и экономика #
Эта система отвечает на вопрос: остаётся ли процесс приемлемым по пользе, расходам, риску и требованиям?
В неё входят реестр рисков, применимые требования, полная стоимость результата, бюджеты, решения о переносе механизмов и организационное обучение.
ISO/IEC 42001 задаёт требования к системе управления ИИ, ответственности, целям, контролю и улучшению. NIST AI RMF предлагает функции управления, описания контекста, измерения и работы с риском.
Эти источники не предписывают архитектуру из восьми систем, но поддерживают управляемый жизненный цикл. [ISO-IEC-42001-2023] [NIST-AI-RMF-1-0]
Минимальный артефакт — совместный обзор результата, полной стоимости и риска.
Проверка системы: может ли руководитель показать, какую пользу купили расходы и какой остаточный риск принят?
Как системы образуют один цикл #
Представьте процесс подготовки предложения клиенту.
Ценность и портфель задают ожидаемое сокращение времени и уровень качества. Люди и полномочия оставляют цену и юридические условия за человеком. Контекст предоставляет актуальный каталог и правила.
Среда исполнения формирует черновик и вызывает расчёт. Контур управления запрещает менять скидку выше порога. Проверки сверяют расчёт и источники.
Поставка выпускает новую версию инструкции. Управление и экономика решают, окупается ли механизм.
Если убрать любую систему, проблема проявится в другом месте. Без контекста ответ устареет. Без полномочий система применит лишнюю скидку. Без экономики команда будет ускорять черновик, не зная стоимости его проверки.
Минимальная конфигурация первого цикла #
Первому процессу не нужны восемь платформ. Ему нужны восемь ответов.
| Система | Минимум для пилота |
|---|---|
| Ценность | Один результат и исходный уровень |
| Люди | Один владелец и карта решений |
| Контекст | Несколько разрешённых источников с владельцами |
| Исполнение | Закреплённый состав модели, инструкции и инструментов |
| Управление | Ограниченная учётная запись и явные запреты |
| Проверка | Набор случаев, пороги и журнал |
| Поставка | Версия, откат и ответственный за выпуск |
| Экономика | Расход на принятый результат и предел потерь |
Общий компонент появляется после повторения. Если три процесса одинаково решают выдачу краткоживущих прав, имеет смысл общий сервис. Если сходство существует только на слайде, локальные решения пока безопаснее и дешевле.
Рабочая карточка главы #
Решение. Определить минимальную конфигурацию восьми систем для выбранного процесса и назвать два опаснейших разрыва.
Минимальный механизм. По одному владельцу, артефакту и проверке на каждую систему. Общие компоненты добавляются после подтверждённого повторения.
Ответственный. Владелец потока отвечает за целое. Владельцы данных, технологий, безопасности, эксплуатации и финансов отвечают за свои механизмы и доказательства.
Артефакт. Карта восьми систем с текущим состоянием, ссылками, разрывами и зависимостями.
Критерий готовности. Для каждого шага цикла видно, какая система задаёт результат, право, данные, исполнение, проверку, выпуск и экономическое решение.
Показатели результата.
- доля цикла, покрытая воспроизводимыми механизмами;
- время от решения об изменении до проверенного выпуска;
- число повторно использованных компонентов с повторной приёмкой;
- результат и полная стоимость процесса.
Показатели риска.
- число систем без владельца;
- число личных учётных записей в производственном пути;
- доля правил без версии;
- число общих компонентов без подтверждённого потребителя;
- время восстановления после отказа зависимости.
Типичные ошибки.
- покупать восемь продуктов вместо ответа на восемь вопросов;
- превращать системы в жёсткие слои;
- централизовать до повторяемой потребности;
- назначать техническую команду владельцем бизнес-результата;
- считать стандартный протокол доказательством доверия.
Различия маршрутов. Стартап собирает минимальные механизмы вокруг одного цикла и избегает платформенной команды.
Зрелая компания наносит восемь систем на один сквозной поток, выявляет дублирование и согласует общие правила. Она не обязана немедленно заменять локальные компоненты.
Чек-лист.