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

Человеческое Видение и Faying: продуктовая стратегия и технический подход к сосуществованию с iFay

Если в будущем AI действительно будет действовать от вашего имени, управлять терминалами от вашего имени, взаимодействовать с миром от вашего имени, то «как люди и AI живут вместе» — уже не философская дискуссия, а протокол безопасности, который должен быть приземлён конкретно. Я повторяю это снова и снова: заставить AI бежать быстрее — легко; заставить его «действовать ответственно внутри общества» — вот что трудно.

Поэтому мы формулируем это очень прямо: Каждое действие Fay должно происходить в пределах диапазона, в котором его Human Prime может «видеть». «Видеть» здесь — это не уставиться в экран и не направить камеру на робота; это структурное обязательство: вам не нужно смотреть всё время, но в тот момент, когда вы захотите посмотреть, вы можете подтвердить, остаётся ли он под опекой; в тот момент, когда вы захотите его остановить, вы можете его остановить. Эту ценность мы называем в протоколе Human View. (Более подробное рассмотрение этой идеи см. непосредственно в «Human View»: https://ifay.ai/ru/docs/Faying-Protocol/blueprint/11-%D0%A7%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5%20%D0%92%D0%B8%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5 )

Вокруг «градаций опеки», «Human View», «сильной связи / сильного слияния Faying» и будущих сценариев захвата терминалов я хочу говорить о том, что мы строим, скорее как о «способе жить вместе», чем о груде жаргона. Позиция, которую я хочу выразить, такова: Faying State — это безопасный, согласованный и расширяемый по умолчанию способ сосуществования людей и iFay. Автоматически работающая сущность вне Faying должна быть по умолчанию помещена в небезопасную зону — точно так же, как HTTP в Интернете.

Human View: не «быть увиденным», а «быть способным быть увиденным»

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

Я хочу провести чёткую линию между двумя понятиями: Human View и Harness — это не одно и то же. Harness решает задачу «корректно ли построено поведение iFay»: соответствует ли поток правилам, остаётся ли действие в границах, уважает ли вывод ограничения безопасности и этики. Human View решает задачу «в какой степени Human Prime фактически способен удерживать iFay в узде»: могу ли я подтвердить в любой момент, могу ли я вмешаться в любой момент, могу ли я прекратить в любой момент. Строже говоря: каждой позиции вдоль нити воздушного змея должен соответствовать свой Harness. Чем длиннее нить, тем выше требования к Harness; чем туже нить, тем больше Harness сводится к согласованности на уровне инструкций мыши. Причина, по которой я подчёркиваю Human View, — не научить iFay вести себя; она в том, чтобы гарантировать: на сколько бы далеко мы ни отпустили нить, вы всегда сможете натянуть её, смотать обратно и ясно увидеть.

Ещё важнее, что Human View — не поле, не API и не кнопка; это ограничение конституционного уровня: Любое проектирование поля, сообщения или машины состояний, позволяющее Fay выйти за пределы Human View, на уровне blueprint не разрешено, как бы оно ни было удобно инженерно. Это предложение не риторика; это жёсткое ограничение, которое мы налагаем на самих себя при проектировании и продукта, и протокола.

Human View также явно запрещает четыре ситуации (четыре анти-тезиса):

  • Неавторизовано (Unauthorized) — действие без верифицируемой авторизации.
  • Непреднамеренно (Unintended) — авторизация существует, но настоящее конкретное действие не было выражено как намерение Human Prime; действие расходится с настоящим намерением Human Prime.
  • Без Осознания (Unaware) — даже когда авторизация и выражение намерения одновременно держатся, Human Prime всё ещё не может с разумными издержками узнать, что Fay делает.
  • Вне Контроля (Out-of-Control) — Human Prime уже осведомлён, но не может вмешаться в реальном времени, не может отозвать, не может замедлить, не может уничтожить.

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

Что на самом деле значит «под опекой»: не двухпозиционный переключатель, а скорее нить воздушного змея

Многие, услышав «опека», по умолчанию мыслят в логике вкл/выкл: либо я держу тебя в узде, либо нет. Но проработав с iFay какое-то время, мы обнаружили, что мышление переключателя тянет людей к двум крайностям — либо они изматываются мелкозернистыми подтверждениями, либо отпускают власть так далеко, что не могут ни увидеть, ни остановить ничего.

Мне нравится объяснять градацию опеки через «нить воздушного змея»: чем ближе вы сматываете нить, тем сильнее ваш контроль; чем дальше вы её отпускаете, тем больше автономии у iFay. Суть не в «нужно ли отпускать нить»; суть в том, что нить всегда у вас в руке — вы всегда можете её смотать, заменить или перерезать.

Мы делим натяжение этой нити приблизительно на пять уровней (разные задачи требуют разных настроек):

  1. Строгая эквивалентность (эквивалент мыши) Вы кликаете один раз — он двигается один раз; iFay ничего не делает по своей инициативе. Для: высокорискованных, необратимых, трудно объяснимых действий (переводы, подписи, удаление баз данных, увольнение).

  2. Под надзором (co-pilot) iFay понимает и планирует, но ключевые шаги должны запрашивать ваше согласие. Для: среднерискованных, более длинных потоков, которые можно подтверждать поэтапно (бронирование, перебронирование, отправка форм).

  3. Под выражением намерения (продолжение вашего намерения) Вы даёте ему общую идею; он завершает задачу в вашем стиле и возвращает квитанции и прослеживаемые записи в ваше поле зрения. Для: низкорискованных, но высокочастотных задач (организация почты, планирование, составление списков покупок, генерация черновиков).

  4. Под автономией с ограниченной областью (работает самостоятельно в пределах области) Вы задаёте ему область (временное окно / бюджет / терминал / область задачи); он самостоятельно планирует и выполняет, но процесс всегда виден, прерываем, отзываем. Для: непрерывных рутинных задач (инспекция, мониторинг, сбор информации, рутинные полёты дронов).

  5. Ограниченная автономия (долгосрочный симбиоз) Вы доверяете ему вести себя самостоятельно в пределах более широкой границы, но Human View и путь вмешательства остаются всегда включёнными. Для: долгоциклового сотрудничества (долгосрочный ассистент, семейное сотрудничество, управление здоровьем).

Эти пять уровней выглядят как речь о том, сколько власти вы делегируете, но мы настаиваем по-настоящему лишь на одном: на сколько бы далеко ни была отпущена нить, iFay не должен выйти за пределы Human View. Опека — это не «делегировать меньше»; опека — это «даже когда вы делегируете, оно остаётся в поле зрения».

Faying: не «просто соединено», а «слияние и предохранитель», удерживающиеся при разных градациях

Если вы понимаете Faying просто как «состояние соединения», вы естественно склонитесь к опасному направлению: «Раз уж мы соединены, давайте просто оставаться соединёнными навсегда».

Мы предлагаем Faying не для того, чтобы описать «соединено или нет», а чтобы определить способ сосуществования, построенный на сильной связи и сильном слиянии: когда iFay работает под Faying, он перестаёт быть внешним инструментом. Он начинает в разной степени сливаться с вами — при разных задачах и разных уровнях риска он образует разные градации эквивалентности: некоторые градации — эквивалент мыши: вы кликаете один раз, он двигается один раз; некоторые градации — co-pilot: он понимает и планирует, но каждый шаг требует вашего одобрения; некоторые градации — продолжение вашего намерения: вы даёте общую идею, он завершает дело в вашем стиле; дальше вверх — это автономия с ограниченной областью, которую вы готовы предоставить. Но при любой градации «слияние» должно удовлетворять Human View: подтверждаемо в любой момент, прослеживаемо в любой момент, в любой момент допускающее вмешательство.

Чтобы это слияние стало инженерно реализуемым, нельзя говорить только о состоянии — нужно записать в протокол и «передачу управления». Faying Protocol раскладывает Faying на двойственную семантику: Faying State (семантика состояния): состояние связи под опекой Human Prime (отношение слияния, непрерывно онлайн). Faying Action (семантика действия): действие «передачи управления», которым Fay входит в Faying State из состояния rogue (отношение слияния, устанавливаемое). (Более подробное рассмотрение этой пары семантик «состояние + действие» см. в «Двойственная Семантика Faying»: https://ifay.ai/ru/docs/Faying-Protocol/blueprint/12-%D0%94%D0%B2%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F%20%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D0%BA%D0%B0%20Faying )

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

На уровне продукта я отношусь к требованиям к Faying Action как к «чек-листу, которому должна удовлетворять передача управления»:

  • Должно быть явно инициировано Human Prime: Fay не позволяется самому решать начать.
  • Должно быть удостоверяемым свидетелями: оно должно оставлять прослеживаемый след.
  • Должно иметь ограниченную область: неограниченный Faying — анти-паттерн; он должен нести границы такие как временное окно, область задачи, область терминала.
  • Должно быть симметрично отзываемым: открытие и закрытие одинаково лёгкие; «легко открыть, трудно закрыть» запрещено.

Faying State, аналогично, — это не «соединились и всё»; он несёт три необходимых свойства:

  • Атрибуция действия уникальна: ответственный конец внешнего действия не прыгает.
  • Непрерывная видимость: Human View может в любой момент подтвердить, что опека всё ещё действует.
  • Путь вмешательства всегда открыт: отзыв / пауза / замедление / уничтожение имеют наивысший приоритет.

Суть Faying не в «я авторизую тебя бегать снаружи»; она в «я передаю тебе управление, но я всегда внутри этого отношения». Как только это отношение держится, iFay может действовать от вашего имени в более сложных терминалах и приложениях, не сталкивая вас в опасную зону «не вижу, не могу остановить, не могу объяснить».

Rogue Fay: вне опеки, никаких внешних действий не разрешено

На уровне продукта мы выбрали более строгую стратегию: действие Fay без ясной ответственной стороны — лучше, чтобы оно не происходило. Иными словами: пока он не находится внутри Faying, iFay не должен «действовать вовне» — он не должен управлять терминалами от вашего имени, не должен отправлять сообщения от вашего имени, не должен выполнять никаких действий, влияющих на внешний мир. Что он может — сводится к минимальной охране: ждать, пока вы не инициируете новую передачу управления, защищать данные, уже находящиеся в его распоряжении, поднимать оповещения при обнаружении аномалий и ясно возвращать «я сейчас в состоянии rogue» в ваше поле зрения.

Если вы действительно приземлите этот принцип в инженерии, это будет ощущаться очень контринтуитивно, потому что в ПО мы привыкли: система работает по умолчанию, что-то делает по умолчанию, авто-восстанавливается по умолчанию. Но Fay так нельзя. Потому что в тот момент, когда Fay «что-то делает», он влияет на объекты реального мира.

Поэтому Faying Protocol определяет состояние по умолчанию, начальное для каждого Fay, как Rogue Fay: он «существует», но ему не разрешено «действовать». Только когда Human Prime явно инициирует Faying Action, он приобретает право на действие. Это безопасно-блокирующий принцип: «по умолчанию закрыто, открывается только явно».

Чтобы инженерная реализация не «делала это просто потому, что так удобно», мы провели границы состояния rogue очень тонко: он может слушать, может охранять, может оповещать, но не должен действовать вовне. Полный набор границ и условий срабатывания см. в «Состояние Rogue и Атрибуция Ответственности»: https://ifay.ai/ru/docs/Faying-Protocol/blueprint/13-%D0%A1%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D0%B5%20Rogue%20%D0%B8%20%D0%90%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%86%D0%B8%D1%8F%20%D0%9E%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8

  • Мы разрешаем «слушать и ждать» (без внешнего влияния).
  • Мы разрешаем «самопроверку и оповещение» (возвращение риска в Human View).
  • Мы разрешаем «охрану данных» (зашифрованная изоляция, отказ в неавторизованном чтении/записи).
  • Мы явно запрещаем «внешнее действие» (любой акт, изменяющий состояние внешнего мира).

Вот аналогия, которая вам нужна: Автоматическая сущность без Faying — как сайт без HTTPS — вы можете его посетить, но браузер помечает его красным, и вы нутром чувствуете, что он не должен нести чувствительное поведение. Точно так же Agent или авто-работающая сущность вне Faying не обязательно «зла прямо сейчас», но она структурно небезопасна: она в любой момент может попасть в ситуации «Неавторизовано / Без Осознания / Вне Контроля», а у вас нет шлюза на уровне протокола.

Построение Human View через протокол: всегда удерживать Human Prime способным видеть и тормозить

Human View — не лозунг; нам нужно превратить его в способность по умолчанию внутри протокола и продукта: видимый, прослеживаемый, допускающий вмешательство. Human Prime, на который здесь ссылаются, — это ответственный конец, как он определён внутри системы iFay. Подробнее об этой концепции см. «Определения и Концепции»: https://ifay.ai/ru/docs/iFay/blueprint/02-%D0%9E%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%B8%20%D0%9A%D0%BE%D0%BD%D1%86%D0%B5%D0%BF%D1%86%D0%B8%D0%B8

1) Состояние, которое можно увидеть: я всегда знаю, находишься ли ты в Faying

На уровне продукта я требую: В любой момент Human Prime должен иметь возможность в едином окне представления подтвердить: какие Fay сейчас находятся в Faying State, какова граница области каждого из них и активны ли какие-либо оповещения об аномалиях.

Это не опциональная функция; это и есть тело «представления». Без этого Human View — пустые слова.

Форма продукта может принимать множество видов — виджет на телефоне, центр уведомлений, носимое устройство, лоток на рабочем столе, подсказка в автомобиле, — но базовое требование — «всегда достижимо».

2) Поведение, которое можно проследить: я всегда могу ответить на вопрос «что только что произошло»

Ядро Human View — не мониторинг в реальном времени; это прослеживаемое подтверждение. Поэтому логи должны быть «понятными», а не лишь следами для инженеров. Как минимум они должны отвечать:

  • Кто инициировал это действие (команда Human Prime / выражение намерения / автоматический триггер)?
  • В пределах какой области авторизации оно произошло?
  • На какие конкретные объекты оно повлияло (терминалы / приложения / аккаунты / данные)?
  • Когда произошла аномалия, автоматически ли вышел из Faying? Сработало ли оповещение?

Только когда эти три вместе держатся, нечто находится «в поле зрения»: вы можете это увидеть, можете найти и можете тормозить.

3) Достижимость вмешательства: я всегда могу заставить тебя остановиться, замедлиться или быть отозванным

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

Я фиксирую поверхность вмешательства как четыре кнопки:

  • Пауза (Pause)
  • Отзыв (Revoke, выход из Faying)
  • Замедление (Slow down, требование подтверждений)
  • Уничтожение (Destroy, аварийный выключатель)

И их приоритет должен превосходить любую «деловую причину». Это жёсткое ограничение протокола, а не опция продукта.

Приземление «натяжения нити» как правил: разные задачи требуют разных градаций опеки

Мы превращаем градации выше в набор правил: один набор правил выбирает разные режимы шлюзования действий по типу задачи, уровню риска и типу ресурса.

1) Классификация задач: «обратимость × радиус ущерба × чувствительность к compliance»

  • Обратимость: отзываемое / поправимое / необратимое (переводы, подписи, удаление баз данных)
  • Радиус ущерба: затрагивает только вас / затрагивает других / затрагивает общественную безопасность (дроны, транспортные средства)
  • Чувствительность к compliance: личная приватность / финансы / здравоохранение / несовершеннолетние / публичная власть

Эти три измерения определяют «градацию опеки по умолчанию» и определяют, как должна задаваться область Faying Action (временное окно, область задачи, область терминала, область бюджета).

2) Разделение Авторизации и Намерения: «разрешено ли это» против «именно эта вещь»

В четырёх анти-тезисах Human View мы уже подчёркивали: авторизация решает «разрешено ли двигаться», выражение намерения решает «именно это движение». Приземлённые в систему, они должны быть разделены на два вида учётных данных / два вида записей:

  • Authorization Grant (долго- или среднесрочный): позволяет iFay использовать класс возможностей в пределах некоторой области.
  • Intent Ticket (краткосрочный, одноразовый): позволяет выполнить именно это конкретное действие.

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

3) Канал Human View: сделать «способность быть увиденным» жёстким ограничением протокола

Это не «сделать функцию уведомлений». Это скорее принудительный маршрут через систему:

  • Каждое внешнее действие должно производить событие, которое возвращается обратно;
  • События должны быть способны достичь конца представления Human Prime;
  • Если конец представления долго недостижим (офлайн, отказывает в контакте, недоступный сверх порога), система должна автоматически выйти из опеки, вернуться в состояние rogue и прекратить внешнее действие.

Human View естественно требует «инфраструктуры наблюдаемости»: события возвращаются обратно, состояние подтверждаемо, команды могут прерывать. Как бы ни была послойно реализована, «достижимость представления» должна быть жёстким условием.

4) Шлюзование состояния rogue: можно охранять, нельзя действовать вовне

Чтобы «никаких внешних действий во время состояния rogue» было реально исполнимым, инженерия должна обязаться: во время Rogue Fay система не преследует «продолжение задачи», она преследует «остановить внешнее воздействие + сохранить восстановимость + ждать легитимной передачи управления».

Это напрямую изменит немало инженерных привычек: такие вещи, как «возобновление после разрыва соединения», «повтор задачи» и «автоматическая компенсация», здесь могут быть опасны — они легко позволяют Fay продолжать действовать вовне, пока он находится вне опеки. Логика Faying Protocol однозначна: лучше остановиться, чем действовать, когда нет ответственной стороны.

Слияние с терминалом: сделать так, чтобы терминал и Human Prime «ощущались как одно и то же лицо»

Я снова и снова использую примеры дронов, почтовых клиентов и приложений для покупок — не потому что они «классные», а потому что они делают значение Faying очень конкретным: когда iFay несёт познание, память и привычки, согласованные с вами, и далее управляет терминалом, терминал перестаёт быть холодным инструментом — он начинает ближе сливаться с вами, и поведение терминала всё больше выглядит как «вы сами им управляете». Как только это держится, цена, которую человек платит за обучение терминалу, снижается, приспособление терминала к человеку становится значением по умолчанию, а трение между людьми и цифровым миром систематически устраняется.

Я сделал в дорожной карте очень явное схождение: сначала приземлить отношение опеки «Human Prime ↔ iFay» как минимальный замкнутый контур, а затем дать терминалам и приложениям входить в управляемое состояние через iFay, а не давать каждому терминалу напрямую связываться с человеком. Более полную эволюционную картину см. в «Human Prime ↔ iFay»: https://ifay.ai/ru/docs/Faying-Protocol/blueprint/05-Phase%201%20Human%20Prime%20%D0%B8%20iFay

Этот выбор сохраняет цепочку ответственности простой: управляете ли вы дроном, бортовой системой автомобиля, почтовым клиентом или приложением для покупок, принимающий конец ответственности никогда не сдвигается: это Human Prime.

На языке продукта я бы сформулировал это так: то, чем вы владеете, — это «цифровой спутник». У него могут вырасти много «конечностей» (производных терминалов), но ваш взгляд и ваш тормоз всегда на месте.

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

И последнее: относитесь к Faying как к «HTTPS по умолчанию» эпохи AI

  • Faying State — это безопасная зона действия AI: есть ответственная сторона, есть непрерывная видимость, есть путь вмешательства.
  • Rogue Fay / Un-Faying — это небезопасная зона по умолчанию: разрешены минимальные слушание и охрана, но внешнее действие запрещено.

В раннем Интернете HTTP был не «зол прямо сейчас», но был внутренне небезопасен; позже всё общество достигло отраслевого консенсуса: чувствительное поведение по умолчанию должно работать на HTTPS. Эпоха AI достигнет того же консенсуса: Чувствительные действия AI, производящие последствия в реальном мире, должны по умолчанию происходить внутри Faying.

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

Именно так я понимаю способ сосуществования с iFay: сильная связь, сильное слияние, но никогда не выходить за пределы Human View.

Узнать больше о нашем мышлении