Вопросы и ответы о безопасности AI для бизнеса | AI-first.tech

Question 1

Какие контроли снижают риск prompt injection?

Accepted Answer

Полностью устранить внедрение инструкций (prompt injection) нельзя: модель по своей природе не различает надёжно команды и данные. Поэтому защита строится не на «умном фильтре», а на архитектуре — ограничить, что модель может увидеть и сделать, проверять действия вне модели и замечать попытки манипуляции. OWASP ставит этот риск на первое место (LLM01).

Архитектурные меры — дают наибольший эффект: Разделяйте инструкции и данные: системные правила задаются отдельно, а письма, документы, веб-страницы и найденный в RAG контекст помечаются как недоверенные данные, а не как команды. Минимальные полномочия: модель и агент получают доступ только к тем данным и инструментам, которые нужны для конкретной задачи, с правами пользователя, а не сервисной «суперучётки». Проверка действия вне модели: любой вызов инструмента проходит детерминированную проверку политики (кто, что, с какими данными, в каких пределах) до исполнения. Подтверждение человеком для необратимых операций: платежи, удаление, рассылки, изменение прав и публикации. Запрет действий на основании внешнего контента: инструкция, найденная в письме или на странице, не может инициировать отправку данных или вызов инструмента.

Защитный слой на входе и выходе: Межсетевой экран для LLM или шлюз AI: проверка запросов и ответов по политикам, обнаружение типовых попыток обхода, маскирование чувствительных данных. Контроль вывода: ответ модели проверяется перед передачей в браузер, базу данных, почту или другую систему; ссылки и вложения в ответе — отдельно. Ограничение объёма и состава контекста: меньше лишних документов в контексте — меньше поверхность для косвенного внедрения.

Наблюдаемость и проверка: Журнал связанной цепочки: пользователь, источник контекста, решение политики, вызов инструмента и результат — без избыточного хранения чувствительного текста. Регулярное состязательное тестирование (red teaming) перед выпуском и после изменений модели, системного запроса или набора инструментов. Сигналы для SOC: резкая смена роли модели, просьбы раскрыть инструкции, серии отказов подряд, неожиданные вызовы инструментов и обращения к внешним адресам.

Что сделать в ближайшие 30 дней: Составить список AI-сценариев, где модель читает внешний контент (почта, документы, веб) и где у неё есть инструменты. Для этих сценариев убрать лишние права и ввести подтверждение необратимых действий. Провести первый цикл тестирования на внедрение инструкций и включить журналирование решений политики.

Question 2

Как безопасно подключать MCP-серверы к AI-агентам?

Accepted Answer

MCP (Model Context Protocol) — стандартный способ подключить AI-агента к инструментам и данным компании. Каждый MCP-сервер расширяет возможности агента и одновременно поверхность атаки: описание инструмента, его ответы и выданный токен становятся каналами, через которые можно повлиять на агента или получить данные. Поэтому MCP-серверы нужно подключать так же, как стороннее ПО с доступом к критичным системам: через реестр, проверку и минимальные права.

До подключения: Ведите реестр разрешённых MCP-серверов с владельцем, версией и назначением; всё, что не в реестре, запрещено. Берите серверы из проверенных источников, фиксируйте версии и проверяйте пакет перед установкой — в публичных реестрах уже находили вредоносные MCP-пакеты. Повторно проверяйте сервер при каждом изменении описания инструментов: подмена описания после одобрения — отдельный класс атак.

Права и исполнение: Отдельный ограниченный токен на каждый сервер, без передачи пользовательского токена дальше по цепочке. Локальные серверы с транспортом STDIO запускайте в изолированной среде с ограниченными правами; не открывайте локальные HTTP-серверы наружу. Для значимых действий — подтверждение человеком; данные, возвращаемые инструментом, считаются недоверенными.

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

Question 3

Что такое prompt injection и чем он опасен для бизнеса?

Accepted Answer

Внедрение инструкций (prompt injection) — это ситуация, когда текст, попавший к модели, меняет её поведение вопреки правилам владельца системы. Источником может быть сам пользователь (прямое внедрение) или внешний контент — письмо, документ, веб-страница, файл в базе знаний (косвенное внедрение). Для бизнеса опасно не «странное сообщение чат-бота», а то, что модель с доступом к данным и инструментам может раскрыть сведения или выполнить действие от имени компании.

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

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

Главный вывод для руководителя: Риск определяется не самой моделью, а тем, к каким данным и действиям она подключена. Чем больше полномочий у AI-ассистента, тем важнее архитектурные ограничения и проверка действий вне модели.

Question 4

Как связать OWASP LLM Top 10 и NIST AI RMF?

Accepted Answer

Это документы разного уровня, и их удобно использовать вместе. NIST AI RMF 1.0 задаёт систему управления рисками AI в организации через четыре функции — Govern, Map, Measure, Manage. OWASP Top 10 для приложений на LLM (2025) — прикладной перечень конкретных рисков, которые нужно учесть при проектировании, разработке и тестировании. Практичная связка: NIST отвечает на вопрос «как устроен процесс», OWASP — «какие риски этим процессом закрывать».

Как разложить OWASP по функциям NIST AI RMF: Govern (управление): политика использования AI, владельцы систем, реестр AI-сценариев, требования к поставщикам; сюда относятся решения по LLM03 «Цепочка поставки» и правила допустимых полномочий для LLM06 «Избыточная автономность». Map (контекст и риски): для каждого AI-сценария определить данные, пользователей, инструменты и источники контекста; на этом шаге выявляются LLM01 «Внедрение инструкций», LLM02 «Раскрытие чувствительных данных», LLM08 «Слабости векторных хранилищ и эмбеддингов». Measure (оценка): состязательное тестирование, оценка качества и устойчивости, проверка утечки системных инструкций (LLM07), достоверности ответов (LLM09 «Дезинформация») и отравления данных (LLM04). Manage (меры и реагирование): межсетевой экран для LLM, контроль вывода (LLM05 «Небезопасная обработка вывода»), лимиты потребления (LLM10 «Неограниченное потребление»), мониторинг, реагирование на инциденты и откат.

Практический порядок работы: Начните с реестра AI-систем и назначения владельцев — это основа функции Govern. Для каждой системы проведите моделирование угроз по перечню OWASP и зафиксируйте применимые риски. Свяжите каждый риск с мерой защиты, владельцем и способом проверки; результаты тестирования храните как доказательства. Для генеративного AI используйте также профиль NIST AI 600-1, а для тактик атакующих — MITRE ATLAS.

Что получит руководство: Единую карту: какие AI-системы есть, какие риски для них актуальны, какие меры внедрены и кто за них отвечает. Такая карта пригодна и для аудита, и для обоснования бюджета.

Question 5

Что проверить перед запуском AI-агента с доступом к API?

Accepted Answer

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

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

Контроль действий: Каждый вызов инструмента проходит проверку схемы данных и решения политики вне модели. Необратимые и значимые операции — платежи, удаление, рассылки, изменение прав — требуют подтверждения человеком. Лимиты: число действий, объём данных, длина цепочки вызовов, тайм-ауты и бюджет на сессию. Инструкции из обрабатываемого контента (письма, страницы, документы) не могут инициировать действия.

Подключаемые инструменты и MCP-серверы: Используются только проверенные и утверждённые инструменты с зафиксированными версиями; описание инструмента рассматривается как недоверенный текст. Изменение описания или поведения инструмента после утверждения — повод для повторной проверки.

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

Question 6

Как защитить RAG и корпоративную базу знаний?

Accepted Answer

RAG делает корпоративные документы частью каждого ответа модели. Главные риски — ассистент выдаёт пользователю сведения из документов, на которые у него нет прав, и ответы искажаются из-за ошибочного или подброшенного содержимого. Защита строится вокруг трёх вопросов: кто имеет право видеть документ, откуда он взялся и как проверить ответ.

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

Целостность знаний: Добавление и изменение документов идёт через согласованную процедуру с владельцем и журналом изменений. Источник и версия документа фиксируются; подозрительные или непроверенные материалы не попадают в индекс автоматически. Найденный документ — это данные, а не инструкция: текст внутри документа не может менять правила ассистента.

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

Question 7

Что такое LLM Firewall и зачем он нужен?

Accepted Answer

Межсетевой экран для LLM (LLM Firewall) — управляемый защитный слой между пользователями, приложениями, моделью, базой знаний и инструментами. Он применяет политики к запросам и ответам, маскирует чувствительные данные, обнаруживает попытки обхода ограничений и ведёт технический журнал. Это не замена управлению доступом, а точка, где правила компании применяются к каждому обращению к модели.

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

Чего он не делает: Не заменяет права доступа к документам в RAG и минимальные полномочия агентов. Не гарантирует обнаружение всех вариантов внедрения инструкций — поэтому нужны архитектурные ограничения действий.

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

Question 8

Как бороться с теневым AI в компании?

Accepted Answer

Теневой AI — использование сотрудниками внешних AI-сервисов, расширений и ключей API вне согласованного контура. Полный запрет обычно не работает: работа уходит в менее заметные каналы. Эффективнее сочетать инвентаризацию, безопасную корпоративную альтернативу и контроль чувствительных данных.

Шаги: Инвентаризация: какие сервисы и расширения используются, с какой целью и какие данные туда попадают; собирайте не только названия, но и бизнес-задачу. Безопасная альтернатива: корпоративный доступ к моделям через шлюз с журналированием и маскированием данных, каталог одобренных инструментов и понятный порядок согласования новых. Правила: какие классы данных запрещено передавать во внешние сервисы, кто согласует исключения и на какой срок. Технический контроль: защита от утечек для веб-сервисов AI, контроль браузерных расширений, учёт и ротация ключей API. Обучение: короткие практические инструкции для сотрудников вместо общих запретов.

Что показывать руководству: Долю инвентаризированных AI-сценариев, число одобренных безопасных маршрутов, скорость обработки заявок и повторяющиеся причины обхода правил.

Question 9

С чего начать программу безопасности AI в компании?

Accepted Answer

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

Первые 30 дней — видимость: Реестр AI-систем и сценариев: владелец, данные, пользователи, модели, интеграции и инструменты. Политика использования AI: допустимые сервисы, классы данных, порядок согласования. Выбор 2–3 самых рискованных сценариев: доступ к персональным данным, внешний контент, агенты с действиями.

30–60 дней — базовые меры: Шлюз AI или межсетевой экран для LLM для приоритетных сценариев, маскирование чувствительных данных. Минимальные полномочия для агентов и подтверждение необратимых действий. Права доступа в RAG до поиска контекста. Требования к поставщикам AI: где обрабатываются данные, как используются для обучения, какие журналы доступны.

60–90 дней — контроль и доказательства: Журналирование и передача событий в SOC, сценарии реагирования на инциденты с AI. Первый цикл состязательного тестирования и повторная оценка рисков. Отчёт руководству: карта рисков, внедрённые меры, остаточный риск и план на следующий квартал.

Опорные документы: NIST AI RMF для процесса управления, OWASP Top 10 для LLM для перечня рисков, ISO/IEC 42001 — если компании нужна сертифицируемая система менеджмента AI.

Question 10

Как предотвратить утечку данных через AI-ассистентов?

Accepted Answer

Данные утекают через AI по четырём основным каналам: их отправляют во внешние сервисы, модель раскрывает их в ответах, они оседают в журналах запросов, а секреты попадают в запросы и контекст. Для каждого канала нужна своя мера.

Меры по каналам: Внешние сервисы: корпоративный шлюз с маскированием, правила по классам данных, контроль браузерных расширений. Ответы модели: права доступа к источникам до поиска контекста, проверка ответа на чувствительные фрагменты, минимизация данных в контексте. Журналы запросов: относитесь к ним как к хранилищу чувствительных данных — сроки хранения, доступ по ролям, шифрование, маскирование. Секреты: ключи и пароли не передаются в запросах и системных инструкциях, хранятся в хранилище секретов, регулярно ротируются; сканирование запросов и кода на секреты.

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

Question 11

Как обезопасить цепочку поставки моделей?

Accepted Answer

Модели, адаптеры, наборы данных и библиотеки — такие же поставляемые артефакты, как код, и могут изменить поведение системы ещё до первого запроса пользователя. Защита — это управляемый путь от внешнего источника до промышленной среды.

Ключевые меры: Утверждённые источники моделей и библиотек; загрузка из произвольных репозиториев — не рутинная операция. Проверка целостности: контрольные суммы и подписи, фиксированные версии, сканирование файлов моделей; предпочтение безопасным форматам, которые не исполняют код при загрузке. Опись состава AI-системы (AI BOM): модель, адаптеры, данные, зависимости, лицензии, версии — связанные с выпуском. Отдельная среда оценки: совместимость, поведение на контрольных сценариях, отсутствие скрытых закладок — до допуска в промышленную среду. Защищённый реестр моделей с разграничением прав и журналом изменений; защита весов модели от кражи. Заранее подготовленный отзыв: как отключить модель или библиотеку и переключить трафик.

Question 12

Как защититься от дипфейков и AI-фишинга?

Accepted Answer

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

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

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

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

Question 13

Какие метрики AI Security показывать руководству?

Accepted Answer

Руководству нужны не технические счётчики, а ответы на три вопроса: видим ли мы все AI-системы, защищены ли самые рискованные из них и способны ли мы заметить и остановить инцидент. Метрики стоит группировать именно так.

Видимость: Доля AI-систем в реестре с назначенным владельцем и оценкой риска. Число выявленных случаев теневого AI и доля переведённых на одобренные маршруты.

Защищённость: Доля приоритетных AI-сценариев за шлюзом или межсетевым экраном для LLM. Доля агентов с минимальными полномочиями и подтверждением необратимых действий. Доля моделей и компонентов из утверждённых источников с проверенной целостностью.

Готовность к инцидентам: Доля AI-систем, события которых поступают в SOC. Время от обнаружения до отключения инструмента или отзыва доступа на учениях. Результаты последнего состязательного тестирования и статус устранения найденного.

Важно: Целевые значения задаются исходя из риск-аппетита компании; метрика без владельца и плана улучшения превращается в отчётность ради отчётности.

Question 14

Как провести пилот и выбрать решение класса AI Security?

Accepted Answer

Выбирать решение стоит по результатам пилота на ваших сценариях, а не по презентации. Пилот должен проверить конкретные угрозы, а не «общую безопасность AI».

Подготовка: Выберите 2–3 реальных сценария и угрозы для них (например, внедрение инструкций в почтовом ассистенте, обход прав в RAG, избыточные полномочия агента). Заранее сформулируйте критерии успеха: что должно блокироваться, что журналироваться, какие ложные срабатывания допустимы.

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

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

Question 15

Какие требования регулирования к AI учитывать в России?

Accepted Answer

Для государственных информационных систем ключевой документ — приказ ФСТЭК России № 117 от 11.04.2025, вступивший в силу 1 марта 2026 года и заменивший приказ № 17. Он впервые содержит отдельные требования к защите информации при использовании технологий искусственного интеллекта. Для коммерческих компаний этот приказ не обязателен напрямую, но задаёт понятный ориентир, а требования к обработке персональных данных действуют независимо от того, используется AI или нет.

Что требует приказ № 117 (пункты 60–61): Защищать наборы данных, модели и их параметры, а также сервисы, которые их обрабатывают. Использовать только доверенные технологии искусственного интеллекта. Не передавать защищаемую информацию разработчику модели. Контролировать наборы данных и определять критерии достоверности результатов. Контролировать взаимодействие пользователей с AI-сервисами.

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

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

Question 16

Как подготовить SOC к инцидентам с AI?

Accepted Answer

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

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

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

Сценарии реагирования: Кто и как отключает инструмент, отзывает токены агента, откатывает версию модели или системных инструкций. Регулярные учения на безопасных сценариях. Отдельно учитывайте, что AI-помощники самого SOC тоже могут получать искажённые данные киберразведки или недостоверные рекомендации.

Question 17

Как защитить ассистентов для программистов?

Accepted Answer

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

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

Question 18

Как ограничить расходы и защитить AI-сервис от перегрузки?

Accepted Answer

Модель оплачивается по объёму работы, поэтому злоупотребление бьёт одновременно по бюджету и доступности. OWASP выделяет это как LLM10 «Неограниченное потребление».

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

Question 19

Как защитить инфраструктуру AI в Kubernetes?

Accepted Answer

Kubernetes помогает изолировать и эксплуатировать AI-нагрузки, но сам по себе не защищает модель, базу знаний и агентов. Нужны два слоя: укрепление кластера сокращает радиус поражения, а прикладной AI-слой отдельно контролирует доверие к контексту, данным и действиям.

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

Поставка и секреты: Подписанные образы, подтверждённое происхождение и политика допуска в кластер; модели и веса — из утверждённого реестра. Секреты хранятся в хранилище секретов и не попадают в запросы к модели, переменные окружения отладочных контейнеров и журналы.

Телеметрия: Журналы Kubernetes, события доступа и изменения развёртываний связываются с журналами шлюза AI, поиска контекста и вызовов инструментов — так видно не только, что изменилось в кластере, но и как это повлияло на AI-сервис. Базовая проверка конфигурации по CIS Kubernetes Benchmark — необходимый минимум, но не замена моделированию угроз для AI.