РАЗМЫШЛЕНИЯ О БУДУЩЕМ

Среда исполнения — это управление: как FayGer делает ИИ контролируемым и проверяемым на любом терминале

Когда люди говорят о безопасности ИИ, первое, что приходит в голову, — «выравнивание модели».
Это важно, но это не вся картина.

Как только ИИ начинает перехватывать терминалы, оперировать программами вместо вас и оказывать публичные услуги от имени организации, в настоящую панику общество приводит не отдельная галлюцинация модели, а системная потеря контроля:
вы не знаете, где она работает; вы не знаете, какие права она получила; вы не знаете, что она только что сделала; и тем более не знаете, к кому идти за ответом, как её остановить, как разобрать инцидент и куда подавать жалобу.

Этот риск я называю «действием в свободном состоянии».
Стоит позволить ИИ действовать в свободном состоянии — и никакая продуктовая риторика, никакое «мы предусмотрели меры безопасности» не выдержит ближайшего инцидента.

Поэтому я настаиваю: ИИ нельзя оставлять без присмотра. Он должен действовать под опекой человека.
Звучит как декларация, но в инженерных терминах это требует конкретного: единого, не зависящего от терминала, языка и поставщика «фундамента исполнения», в котором опека, изоляция, аудит и отзыв прав встроены по умолчанию.
Именно ради этого существует FayGer.

1. Почему «среда исполнения» в эпоху ИИ становится инфраструктурой управления

В традиционную эпоху ПО «среда исполнения» воспринималась прежде всего как инженерное удобство:
JVM позволяла Java «один раз скомпилировать — запускать везде»; Docker заставлял образы стабильно разворачиваться на разных машинах; WASM/WASI запускал код в песочнице.

В эпоху Fay (iFay/coFay) среда исполнения перестаёт быть просто удобством — она становится инфраструктурой управления. Потому что Fay не просто «считает», а «действует наружу»:
отправляет сообщения, отсылает формы, управляет терминалом, обращается к железу, инициирует платежи, диспетчирует дроны — каждое действие имеет реальные последствия.

Если вы позволите Fay «жить своей жизнью» на разных терминалах, разных хостах и разных цепочках системных вызовов, вы получите самое страшное:
фрагментацию семантики опеки.
На одном устройстве тормоза работают, на другом — нет; в одной системе есть аудит, в другой — лишь обрывки логов; в одной версии права ограничены, в другой — тихо расширены.

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

2. Позиция FayGer: как JVM/Docker, но с прицелом на «управляемое исполнение»

FayGer одной фразой: виртуальная среда исполнения экосистемы Fay.
Она принимает распространяемый, загружаемый и проверяемый артефакт Fay (BuF) и единообразно исполняет его на разных терминалах.

Но мне важно не «работает ли», а как это работает.
Ключевое обещание FayGer сводится к четырём словам: согласованно, изолированно, доказуемо, наблюдаемо.

Аналогия:

  • Для Java-байткода JVM не вмешивается в вашу бизнес-логику, но определяет загрузку, верификацию, исполнение и изоляцию.
  • Для образов контейнеров Docker / OCI Runtime не интересуется тем, что делает ваше приложение, но определяет структуру образа, права, квоты ресурсов и границы исполнения.

FayGer работает так же. Он не предписывает, как описывать границы возможностей самой Fay (это дело протокола и скиллов). Он предписывает: в какой «управляемой позе» Fay обязана исполняться, когда выходит к обществу.

3. Почему важна трёхслойная структура: Loader / Runtime / Adapter

FayGer делится на три слоя, и это деление критично для управления:

  1. Слой загрузки (Loader)
    Граница между BuF и внешним миром. Отвечает за чтение, структурную проверку, согласование версий, проверку подписи и стратегию загрузки (Eager/Lazy).
    Я воспринимаю слой загрузки как «таможню»: не подходишь по структуре — не пройдёшь; нет подписи — не пройдёшь; версия не совпадает — не пройдёшь.

  2. Слой исполнения (Runtime)
    Исполнитель семантики BuF. Допускает разные языковые реализации (Rust / Go / TypeScript…), взаимозаменяемые через единый интерфейс.
    Это решает редко обсуждаемую проблему: если привязать среду исполнения к одной языковой экосистеме, вы привяжете и управление к одной компании или одному инструментарию — и в итоге получите де-факто монополию.

  3. Слой адаптации (Adapter)
    Граница между FayGer и хост-терминалом. Преобразует Universal Instruction в системные вызовы и в обратную сторону превращает отклик системы в проверяемые события.
    Я воспринимаю слой адаптации как «шлюз прав»: какие возможности терминал готов выдать, в каком объёме и с какой гранулярностью — всё это должно согласовываться и ограничиваться здесь.

Ценность трёх слоёв в том, что «семантика управления» помещается в стабильные слои, а не разбросана по инженерным деталям каждого терминала.
Управление не может полагаться на сознательность каждой команды. Оно должно навязываться архитектурой.

4. «Контролируемый» — это не кнопка, а набор значений по умолчанию

Когда я говорю «ИИ должен действовать под опекой», я не прошу UI-переключатель.
Я прошу набор значений по умолчанию, которые невозможно обойти. И FayGer — лучшее место, где их разместить.

Несколько вещей, которые, по моему мнению, должны быть зафиксированы как умолчания среды исполнения:

4.1 Согласование возможностей и минимум привилегий

Возможности терминала должны декларироваться, согласовываться и выдаваться, а не «может вызвать — значит, вызовет».
Если BuF не получил возможность писать в файловую систему, он не должен «попутно записаться», эксплуатируя какую-нибудь дыру в ОС.

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

4.2 Квоты ресурсов и радиус неконтролируемого воздействия

Квоты CPU / памяти / сети / хранилища у Fay — по сути её радиус неконтролируемого воздействия.
Нельзя надеяться, что «модель сама себя ограничит». Жёсткие пределы можно ставить только на уровне среды исполнения.

4.3 Наблюдаемость: аудит не должен быть постфактумной заплаткой

Во многих системах аудит достраивают уже после инцидента.
В случае Fay аудит должен быть способностью по умолчанию, иначе ответственность невозможно довести до конца.

Я предпочитаю такой подход: среда исполнения предоставляет единую модель ошибок с метками исходного слоя и цепочкой причин (cause chain), плюс структурированные ошибки. А ключевые события исполнения превращаются в поток аудита, на который можно подписаться, агрегировать и заморозить.
Тихо по умолчанию (никого не дёргает), но при необходимости вытаскивается целиком.

4.4 «Остановить внешнее воздействие» — приоритет

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

Если такая политика разбросана по бизнес-коду, KPI её рано или поздно сожрут. Когда она зашита в среде исполнения, у неё появляется шанс стать общественной нормой.

5. Связь FayGer с iFay/coFay: он не решает всего, но определяет, выдержит ли «нижний предел»

Я не считаю FayGer панацеей.
Идентичность, границы персон, семантика протокола, механизмы апелляции, консенсус по вкладу — для всего этого нужны свои слои.

Но FayGer решает более фундаментальный вопрос:
после того как мы записали эти идеи в документы, протоколы и манифесты, сохранятся ли они без искажений, когда дойдут до реального терминала?

В Phase 1 можно дать iFay имитировать UI-операции.
В Phase 2 — перехватывать терминал через CAP/DTP.
В Phase 3 — вызывать сетевые скиллы по удалённым протоколам.
В Phase 4 — заставлять iFay и coFay сотрудничать.
В Phase 5 — обсуждать даже распределение ценности в постмонетарную эпоху.

Но на любой стадии не должна меняться одна базовая фраза:
ИИ нельзя оставлять без присмотра. Он должен действовать под опекой человека.

Задача среды исполнения — превратить эту «человеческую фразу» в факт, который система не может обойти.

6. Заключение: страх будущего — не «ИИ силён», а «ИИ силён и неуправляем»

Сегодняшний страх перед ИИ во многом — страх безработицы, обнищания и крушения смысла.
Эти чувства я понимаю.

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

А первый шаг управления — сделать управляемым само исполнение ИИ.
На мой взгляд, FayGer — это тот фундамент, который обойти не получится.

Связанные документы