Алгоритмический риск сделки: дрейф ценообразования, зависимость и риск смены контроля

1. Определить алгоритмический риск сделки в терминах денежного потока

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

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

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

2. Зафиксируйте операционную базовую линию на дату подписания

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

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

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

3. Составьте карту полной цепочки алгоритмических зависимостей

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

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

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

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

Таблица 1. Доказательства зависимостей и меры реагирования по сделке

Существенность объединяет влияние на денежный поток, время замены и контроль.

4. Разграничивайте дрейф модели и отказ модели

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

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

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

5. Стройте сценарии дрейфа на основе наблюдаемых данных

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

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

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

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

Таблица 2. Иллюстративная запись сценария дрейфа

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

6. Проверить стабильность бенчмарка и релевантность для принятия решений

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

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

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

7. Определить права вышестоящего поставщика на внесение изменений

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

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

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

8. Оценить API и концентрацию вычислительных ресурсов

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

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

Защита сделки может сочетать сценарий цены покупки с операционными контролями. Они могут включать промежуточный ковенант, ограничивающий существенные изменения поставщика, тест на закрытие для подтверждения непрерывного доступа, профинансированный резерв на миграцию или показатель earn-out на основе маржинальной прибыли, а не только выручки. Специалисты по договорам должны подготовить и истолковать все положения.

9. Построить водопад прав и лицензий

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

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

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

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

Таблица 3. Запись дью-дилидженса по водопаду лицензий

Квалифицированные специалисты должны толковать действующие права и ограничения.

10. Изучите риски, связанные с обучающими данными и выходными данными

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

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

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

11. Распределить обязанности поставщика и развёртывающей стороны

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

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

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

12. Проанализировать обязанности UAE в сфере финансовых услуг, связанные с AI

Центральный банк UAE выпустил в феврале 2026 года руководство по ответственному AI для лицензированных финансовых учреждений. Руководство посвящено защите потребителей, прозрачности, предвзятости, подотчётности, объяснимости, конфиденциальности данных и ответственному использованию. Сделка с участием регулируемого финансового учреждения или его существенного поставщика технологий должна проверять, как эти принципы применяются к конкретному продукту и договорной цепочке.

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

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

13. Анализируйте триггеры изменения контроля по каждому договору

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

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

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

14. Проверяйте передачу клиентов и доверие

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

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

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

15. Оценивайте зависимость от критически важных лиц

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

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

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

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

Таблица 4. Доказательства и план защиты по критически важным лицам

Удержание следует сочетать с контролируемой передачей знаний и операционной приёмкой.

16. Сверьте доступы, учётные данные и операционные полномочия

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

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

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

17. Изучите историю инцидентов как доказательство для оценки

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

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

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

18. Оцените мониторинг и наблюдаемость

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

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

Ковенанты после закрытия или выплаты по earn-out, зависящие от технических метрик, требуют стабильных определений и контроля против манипуляций. Если на метрики могут влиять маршрутизация, выборка или изменение порогов, стороны нуждаются в согласованных процедурах измерения и доступе к доказательствам. Более простые коммерческие показатели могут быть легче обеспечены исполнением, когда технический инструментарий незрел.

19. Проверьте безопасность по всей цепочке поставок AI

Риск цепочки поставок AI включает артефакты моделей, конвейеры обучения, код, данные, API, плагины, облачную инфраструктуру и сторонние инструменты. Покупатель должен изучить управление доступом, секреты, происхождение, управление уязвимостями, журналирование, разделение сред, реагирование на инциденты и проверку поставщиков. Ему также следует проверить риски, специфичные для продукта, включая инъекции промптов, утечку данных, небезопасное использование инструментов и извлечение моделей.

Руководство Национального центра кибербезопасности Великобритании по безопасности AI организует безопасность на этапах проектирования, разработки, развертывания и эксплуатации. Такой взгляд на жизненный цикл полезен в сделках, поскольку покупатель приобретает как текущую систему, так и процесс её изменения. Безопасный снимок состояния не может компенсировать неконтролируемый конвейер выпуска.

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

20. Проверьте устойчивость и работу резервных механизмов

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

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

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

21. Оцените количественно инвестиции в устранение недостатков

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

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

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

22. Переведите риск в сценарии оценки

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

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

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

23. Выбор между ценой и условным возмещением

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

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

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

24. Структурируйте эскроу и удержание с привязкой к проверяемым событиям высвобождения

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

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

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

25. Формулируйте заверения на основе доказательств, а не прилагательных

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

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

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

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

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

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

Покупатель должен действовать через согласованное управление и соблюдать применимые правила конкуренции до закрытия. Могут потребоваться механизмы clean team и информационные контроли. Юридические консультанты должны определить допустимый процесс и формулировки.

27. Установите условия закрытия для критически важных зависимостей

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

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

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

28. Составьте term sheet защиты сделки

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

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

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

Защитные механизмы выбираются в зависимости от сроков, контроля, измеримости и серьёзности.

Таблица 5. Иллюстративный term sheet алгоритмической защиты сделки

Условия требуют согласования применительно к конкретной сделке и квалифицированной юридической консультации.

29. Соотнесите меры защиты с контролем после закрытия сделки

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

Мера защиты должна определять допустимые и обязательные действия, доступ к доказательствам, взаимодействие, процедуры изменений и разрешение споров. Если покупателю нужна свобода интеграции, фиксированная цена или эскроу могут быть предпочтительнее длительного технического earn-out. Если продавец продолжает управлять бизнесом, тщательно определенные показатели результативности могут оставаться полезными.

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

30. Интегрируйте, не уничтожая доказательства

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

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

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

31. Управляйте изменениями моделей и поставщиков после приобретения

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

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

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

32. Свяжите операционные показатели с инвестиционным кейсом

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

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

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

33. Применяйте дисциплину бухгалтерского учёта и обесценения

Приобретённые технологии, отношения с клиентами, гудвил и другие активы требуют учёта по применимым стандартам. МСФО (IFRS) 3 регулирует признание и оценку при объединениях бизнесов, а МСФО (IAS) 36 рассматривает обесценение соответствующих активов. Алгоритмическая зависимость, ограничения прав, потеря клиентов или более слабые прогнозы могут учитываться при формировании допущений о денежных потоках и признаков обесценения с учётом профессионального суждения в бухгалтерском учёте.

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

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

34. Предоставьте кредиторам алгоритмический негативный сценарий

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

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

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

35. Используйте проработанный пример сделки

Рассмотрим гипотетического покупателя, оценивающего компанию AI в сфере рабочих процессов с годовой повторяющейся выручкой USD 30 million и заявленной маржинальной прибылью в 58 процентов. Продукт зависит от одного семейства внешних моделей для 72 процентов запросов в продуктивной среде, проприетарного набора данных, лицензированного из трёх источников, и шести старших сотрудников, владеющих знаниями о релизах или особенностях конкретных клиентов. Эти цифры являются иллюстративными допущениями.

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

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

36. Пройти контрольную точку принятия решения инвестиционным комитетом

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

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

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

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

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

37. Реализовать план первых 100 дней

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

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

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

38. Поддерживать комнату доказательств для приобретённой системы

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

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

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

39. Завершить дисциплинированным распределением неопределённости

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

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

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

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

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

Источники

1. Национальный институт стандартов и технологий, Рамки управления рисками искусственного интеллекта (AI RMF 1.0), 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
2. Национальный институт стандартов и технологий, Система управления рисками в области искусственного интеллекта: профиль генеративного искусственного интеллекта, 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
3. Национальный институт стандартов и технологий, Практическое руководство RMF AI. https://airc.nist.gov/airmf-resources/playbook/
4. Европейская комиссия, Руководящие указания об обязательствах для поставщиков AI общего назначения, 2025 г. https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
5. Европейская комиссия, Руководящие указания по сфере действия обязательств для поставщиков моделей AI общего назначения, 2025 г. https://digital-strategy.ec.europa.eu/en/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act
6. Европейская комиссия, Модели AI общего назначения в Законе об AI: вопросы и ответы. https://digital-strategy.ec.europa.eu/en/faqs/general-purpose-ai-models-ai-act-questions-answers
7. Европейская комиссия, Нормативно-правовая база Закона об AI. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
8. Европейская комиссия, Кодекс практики для AI общего назначения. https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
9. Центральный банк UAE, Руководящая записка по защите потребителей и ответственному внедрению и использованию искусственного интеллекта и машинного обучения, 2026. https://rulebook.centralbank.ae/en/rulebook/guidance-note-consumer-protection-and-responsible-adoption-and-use-artificial-intelligence
10. Национальный центр кибербезопасности Великобритании, Руководство по безопасной разработке систем AI, 2023. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
11. Управление по конкуренции и рынкам Великобритании, Фундаментальные модели AI: обновлённый документ, 2024 г. https://www.gov.uk/government/publications/ai-foundation-models-update-paper
12. Управление по конкуренции и рынкам Великобритании, Руководящие указания по оценке слияний, 2021 г. https://www.gov.uk/government/publications/merger-assessment-guidelines
13. Министерство юстиции США и Федеральная торговая комиссия, Руководящие указания по слияниям, 2023 г. https://www.justice.gov/atr/2023-merger-guidelines
14. Управление комиссара по информации Великобритании, Руководство по AI и защите данных. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
15. Организация экономического сотрудничества и развития, Принципы ОЭСР по AI. https://oecd.ai/en/ai-principles
16. Международная организация по стандартизации, ISO/IEC 42001 Система менеджмента искусственного интеллекта. https://www.iso.org/standard/81230.html
17. Международная организация по стандартизации, ISO/IEC 23894 «Управление рисками искусственного интеллекта». https://www.iso.org/standard/77304.html
18. Фонд МСФО, МСФО (IFRS) 3 «Объединения бизнесов». https://www.ifrs.org/issued-standards/list-of-standards/ifrs-3-business-combinations/
19. Фонд МСФО, МСФО (IAS) 36 «Обесценение активов». https://www.ifrs.org/issued-standards/list-of-standards/ias-36-impairment-of-assets/
20. Комитет по поглощениям Великобритании, Кодекс о поглощениях. https://www.thetakeoverpanel.org.uk/the-code/download-code
21. Агентство Европейского союза по кибербезопасности, Многоуровневая структура передовых практик кибербезопасности для AI, 2023. https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai
22. Агентство США по кибербезопасности и защите инфраструктуры, Дорожная карта по искусственному интеллекту, 2023. https://www.cisa.gov/resources-tools/resources/roadmap-artificial-intelligence
23. Комиссия по ценным бумагам и биржам США, Управление рисками кибербезопасности, стратегия, корпоративное управление и раскрытие информации об инцидентах, 2023. https://www.sec.gov/files/rules/final/2023/33-11216.pdf
24. Совет по финансовой стабильности, Влияние искусственного интеллекта на финансовую стабильность, 2024. https://www.fsb.org/2024/11/the-financial-stability-implications-of-artificial-intelligence/
25. Банк международных расчётов, Институт финансовой стабильности, Регулирование AI в финансовом секторе: последние изменения и основные проблемы, 2024. https://www.bis.org/fsi/fsipapers24.htm