Офис программировал ещё до ИИ: чему учит кейс NATO C3

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

В ноябре 2010 года в Барселоне представитель NATO C3 Agency рассказывал о практических доработках Microsoft EPM: учёте времени, проектных сводках и связи с PeopleSoft. Сегодня, когда ИИ помогает создавать инструменты почти из описания задачи, этот старый кейс ставит актуальный вопрос: где заканчивается личная настройка и начинается общая архитектура компании?

Это третья статья серии. После навыков сотрудников и безопасности рассмотрим, как организовать общие сервисы для пользовательских приложений и ИИ-агентов. Исторические сведения и технические источники проверены 1 ноября 2026 года; современная архитектура ниже — наше предложение, а не описание нынешних систем НАТО.

Официальная страница Microsoft подтверждает Project Momentum 2010 EMEA в Барселоне 16–18 ноября 2010 года. Указанная на странице дата 2024 года относится к архиву загрузки, а не к самому событию. Microsoft: Project Momentum 2010 EMEA event presentation archive ↗

В заметке участника Michel Operto от 25 ноября 2010 года описан доклад Nick Hillman: небольшие доработки учёта времени, автоматические проектные сводки и двусторонняя интеграция Microsoft EPM с PeopleSoft. Автор назвал его Business Management Executive for Project Management. Это современное событию свидетельство участника, не официальный аудит внедрения. Michel Operto: a contemporary account of Nick Hillman’s NC3A presentation, November 25, 2010 ↗

NC3A расшифровывается как NATO Consultation, Command and Control Agency. Официальная история NCI Agency указывает её среди организаций, объединённых в 2012 году. Называть это просто группой генералов, лично написавших программы, оснований нет. NCI Agency: institutional history and the 2012 merger ↗

Источники не устанавливают, кто именно программировал доработки, принадлежали ли эти люди к ИТ и была ли причиной особая логистика проектов в Европе. Они также не подтверждают нынешнее использование Claude в описанном процессе.

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

Из исторического кейса нельзя вывести, что большинство обычных пользователей уже тогда программировало самостоятельно. Зато он помогает сформулировать устойчивую потребность: программное обеспечение должно учитывать конкретные рабочие правила. Генеративный ИИ делает создание вариантов доступнее, но не отменяет эту потребность и ответственность за результат.

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

Для компании сегодня полезно выяснить, какие изменения повторяются. Если сотрудники постоянно строят похожие выгрузки, формы и сводки, возможно, им не хватает общего сервиса или понятного способа его использовать.

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

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

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

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

Model Context Protocol описывает взаимодействие ИИ-приложений с предоставляемыми серверами возможностями: инструментами, ресурсами и промптами. Он может стать одним из способов подключить агент к разрешённым функциям компании. Сам протокол не является готовой системой управления бизнесом. Model Context Protocol: official architecture ↗

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

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

Поэтому совет «инвестировать в MCP» разумно разложить на несколько работ: описать бизнес-операции, привести данные в порядок, закрепить правила и лишь затем выбрать удобный адаптер для агентов. Иногда первым полезным результатом будет обычный API или исправление существующего сервиса.

Человек должен видеть, что согласовывает. Для сравнения договоров, проверки состава КП, просмотра источников и подтверждения действия полезен понятный экран. Свободный диалог не всегда удобен для сопоставления нескольких версий или поиска пропущенного поля.

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

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

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

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

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

Ошибки тоже становятся частью контракта: нет доступа, не хватает данных, устарела версия, требуется подтверждение. Убедительное объяснение агента не должно превращать один из этих исходов в разрешение продолжить.

Права проверяют для конкретного сотрудника и объекта. Общий ключ с доступом ко всей компании создаёт риск даже при аккуратном описании инструментов. В опубликованной спецификации MCP для HTTP-транспортов авторизация рассматривается отдельно, с требованиями к получателю токена и области доступа. Она не заменяет бизнес-проверки сервиса. MCP: HTTP authorization, specification version 2025-11-25 ↗

Рекомендации MCP по безопасности отдельно запрещают token passthrough — приём токенов, не выданных этому MCP-серверу, и их передачу дальше как пропуска к другому сервису. Подключение через протокол не должно превращать агента в обходной путь к полномочиям другой системы. MCP: security best practices, version 2025-11-25 ↗

У небольшого инструмента должен быть владелец: человек, который знает назначение, данные и критерии правильности. Для регулярного использования нужны также понятные правила сопровождения. Сотрудник может быть автором идеи и формы, а ИТ — владельцем среды и общего сервиса.

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

Жизненный цикл включает изменения и вывод из эксплуатации. Microsoft в рекомендациях ALM для Power Platform рассматривает разработку вместе с управлением, тестированием и сопровождением. Это полезный организационный ориентир и для инструментов, созданных с генеративным ИИ. Microsoft: Application lifecycle management with Power Platform ↗

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

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

Например, интерфейс и будущий агент могли бы использовать один расчёт КП и одно утверждение его версии. Агент помогает подготовить данные; приложение сохраняет правила и доказательства. Такой MCP-слой для пользовательских программ пока не реализован и требует отдельной интеграции.

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

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

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

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

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

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

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