Методичка · Библиотека ДИС
Продажа и внедрение цифровых решений
Методичка: история продаж за 200 лет, современные подходы, автоматизация на n8n, сайты и порталы. Вопросы клиенту, расчёт эффекта, приёмка и 13 источников.
Продажа и внедрение цифровых решений
Автоматизация на n8n и создание сайтов и порталов
Авторская методичка ДИС • Степанов Д.А. • Методичка • Версия 1 от 07.10.2026
Назначение
Методичка помогает специалисту или небольшой команде перевести запрос клиента в понятное предложение, согласовать границы работ и проверить результат внедрения. Основные примеры — обработка заявок на n8n и сайт или портал с формами, материалами и административной панелью.
Главный принцип: сначала установить, что должно измениться в работе клиента, затем выбрать решение, объяснить его стоимость и подтвердить результат. История продаж показывает устойчивость доверия и доказательства пользы; современные исследования уточняют роль самостоятельного выбора, цифровых каналов и снижения неопределённости.
Как пользоваться
Читайте общие главы, затем выбранный пример. Заполняйте рабочие формы по реальному проекту. Учебные цифры, сроки и пороги в примерах не являются тарифами, обязательствами автора или подтверждёнными результатами действующих проектов.
Содержание
1 История продаж за 200 лет
2 Современные подходы и их применение
3 От запроса к согласованной задаче
4 Пример автоматизации на n8n
5 Проверка и эксплуатация автоматизации
6 Расчёт эффекта и решение о пилоте
7 Пример сайта и портала
8 Приёмка сайта и портала
9 Коммерческое предложение и возражения
10 Рабочие формы и управление проектом
11 Литература и источники
Обзор опирается на 13 источников. Ссылки [1–13] относятся к списку литературы. Исторические выводы преимущественно описывают западную традицию продаж; современные опросы не следует автоматически переносить на российский малый бизнес.
1 История продаж за 200 лет
За последние два столетия сохранялись потребность в доверии, объяснении пользы и выполнении обещаний. Менялись масштаб компаний, доступ покупателя к информации и способы управления продажами. Периодизация ниже — рабочая схема для обучения, а не общепринятая история всех рынков.
| Период | Развитие практики | Урок для цифровых услуг |
|---|---|---|
| 1820–1870 | Личная торговля и разъездные продавцы; большое значение репутации | Покупатель оценивает исполнителя и надёжность обещания |
| 1870–1920 | Организованные отделы продаж, обучение, территории, планы и отчёты | Нужны этапы, ответственные и понятный учёт |
| 1920–1950 | Тестирование рекламы и отслеживание отклика | Предложения проверяют на результате |
| 1950–1980 | Развитие управления, ориентированного на клиента | Предложение связывают с задачей покупателя |
| 1980–2000 | Диагностический разговор в сложных продажах | Изучают последствия проблемы и ценность изменения |
| 2000–2020 | Расширение самостоятельного цифрового изучения поставщиков | Объяснение услуги должно быть доступно до встречи |
| 2021–2026 | ИИ и сочетание самостоятельного выбора с помощью эксперта | Эксперт проверяет применимость, риски и ожидания |
Что подтверждает литература
Фридман описывает, как крупные компании рубежа XIX–XX веков стандартизировали работу продавцов, вводили территории, квоты и отчёты [1]. Хопкинс в 1923 году рассматривал тестовые кампании и отслеживание отклика [2]. Друкер связывал управление бизнесом с клиентом и результатом деятельности [3]. Рэкхем систематизировал вопросы о ситуации, проблеме, последствиях и ценности решения [4].
Что не следует переносить автоматически
Приёмы завершения небольшой покупки не обязательно подходят сложному внедрению. Давление может ускорить согласие, но оставить несогласованные ожидания. Исторический возраст приёма сам по себе не доказывает его эффективность. Для цифровой услуги качество продажи проверяется также качеством последующей передачи результата.
2 Современные подходы и их применение
Современная часть охватывает октябрь 2021 — октябрь 2026 года. Книги представляют авторские методики; опросы показывают связи и предпочтения в конкретных выборках; исследование производительности изучает определённое внедрение. Ни один источник не гарантирует результат вашего проекта.
Помощь в осмыслении информации
Адамсон предлагает отбирать полезные сведения, объяснять противоречия и помогать клиенту разобраться в выборе [5]. Практическая адаптация: вместо длинного списка инструментов подготовить короткую карту задачи, варианты решения и демонстрацию на примере клиента.
Работа с нерешительностью
Dixon и McKenna рассматривают страх ошибиться у уже заинтересованного покупателя [6]. Для внедрения полезны ограниченный пилот, понятная цена первого этапа, критерии приёмки и условия решения о продолжении. Пилот не должен маскировать неизвестную полную стоимость.
Сравнение с альтернативами
Данфорд связывает презентацию с позиционированием и отличием от альтернатив, включая сохранение текущего порядка [7]. Покупатель автоматизации может выбрать готовый сервис, найм сотрудника или простую форму. Сравнение должно включать расходы, ограничения и ответственность за эксплуатацию.
Самостоятельный выбор и разные участники
McKinsey B2B Pulse 2024 сообщает о среднем использовании десяти каналов взаимодействия [9]. Gartner в марте 2026 года сообщил, что 67% опрошенных B2B-покупателей предпочитают опыт покупки без продавца [10]. Эти значения описывают выборки, а не вашу воронку. На сайте заранее нужны понятные услуги, примеры, ограничения и способ обращения.
Edelman–LinkedIn 2025 рассматривает влияние экспертного контента на участников покупки, в том числе не присутствующих на первой встрече [11]. Практическая адаптация: руководителю показать эффект, сотруднику — рабочий сценарий, техническому специалисту — интеграции и поддержку.
Проверяемый эффект и отношения после запуска
The Activator Advantage выделяет регулярное развитие контактов, информирование клиентов и сотрудничество специалистов [8]. Исследование Generative AI at Work в первоначальной версии 2023 года сообщало о среднем росте производительности поддержки примерно на 14%, с различиями по опыту работников [12]. Это не обещание для любого AI-продукта. NIST предлагает системно управлять рисками ИИ [13].
Рекомендация для ДИС: опираться на подтверждённые кейсы, обозначать ограничения и измерять результат каждого внедрения. В примерах ниже ИИ не является обязательным компонентом.
3 От запроса к согласованной задаче
Фраза клиента «нужен бот», «нужен сайт» или «хочу автоматизацию» описывает предполагаемый инструмент. Первая задача исполнителя — установить рабочую ситуацию, ожидаемое изменение и ограничения.
Начало разговора
«Чтобы предложить подходящий вариант и заранее определить объём работ, уточню несколько вопросов о процессе и результате. После этого покажу возможные решения и то, что входит в оценку».
| Что выяснить | Вопрос | Что зафиксировать |
|---|---|---|
| Текущий процесс | Как проходит одна заявка от обращения до ответа? | Шаги, системы, участники |
| Проблема | Где теряются заявки или возникает ручная работа? | Конкретный сбой или затрата |
| Последствия | Как часто это происходит и на что влияет? | Частота, время, ошибки |
| Результат | Что должно измениться после внедрения? | Наблюдаемое изменение |
| Решение о покупке | Кто согласует бюджет и кто будет пользоваться? | Участники и полномочия |
| Ограничения | Какие системы, доступы, данные и сроки обязательны? | Зависимости и границы |
Проверка понимания
Завершите разговор коротким пересказом: «Сейчас заявки поступают через форму и почту, сотрудник переносит их вручную. Нужно сохранять обращения в одном месте, назначать ответственного и видеть статус. Первый этап ограничим одной формой и одной системой учёта. Верно?»
Когда не стоит продавать внедрение
- Проблема не подтверждена и клиенту пока достаточно инструкции или настройки существующего сервиса.
- Нет владельца процесса, который согласует правила и проверит результат.
- Недоступны необходимые интеграции или данные; сначала требуется отдельная проверка.
- Ожидаемый эффект не оправдывает стоимость и сложность выбранного варианта.
Результат этапа
Согласованная карточка задачи: кто обращается; что происходит сейчас; что должно измениться; как это проверить; кто принимает результат; что пока неизвестно. Существенные неизвестные указываются в предложении до обещания фиксированной цены и срока.
4 Пример автоматизации на n8n
Учебный сценарий: небольшой центр получает заявки с сайта. Координатор вручную переносит данные в систему учёта, назначает сотрудника и отправляет подтверждение. Это модель для методички, а не описание выполненного заказа.
Предложение на языке клиента
«Настроим регистрацию заявок из формы в едином реестре, уведомление ответственного и подтверждение заявителю. По каждой заявке будет виден статус обработки. Проверим повторы и недоступность внешней системы».
Границы первого этапа
- Одна форма, один реестр заявок и один канал уведомления ответственного.
- Заранее согласованные поля: идентификатор обращения, дата, контакт, тема, источник, статус.
- Проверка обязательных полей и формата данных.
- Разграничение доступа и технический журнал без лишних персональных сведений.
- Сценарии повторного обращения, ошибки интеграции и ручного восстановления.
Вне первого этапа: несколько CRM, платежи, голосовые сообщения, автоматические медицинские ответы и анализ свободного текста ИИ. Расширение оценивается отдельно.
Логика обработки
Система получает обращение и проверяет его. Некорректные данные возвращаются на исправление. Для корректного обращения проверяется идентификатор: повтор связывается с существующей записью; новое обращение сохраняется в реестр. Затем запускаются уведомления и фиксируется их результат.
Если запись сохранена, но уведомление не отправлено, повторять нужно уведомление, сохраняя связь с исходной заявкой. Если система учёта недоступна, обращение следует надёжно поставить в очередь либо сообщить о невозможности приёма. Подтверждение успеха допустимо только после согласованной точки надёжного сохранения.
Зачем здесь n8n
n8n связывает входное событие, обработку данных, условия и обращения к внешним сервисам. Конкретные узлы выбираются по доступным API и версии платформы. Учебник n8n объясняет триггеры, credentials и ветвление: https://docs.n8n.io/build-your-first-workflow.md
Отдельно определить: где размещается сервис, кто оплачивает инфраструктуру и доступы, кто наблюдает за ошибками. Непрерывная работа требует постоянно доступной инфраструктуры; закрытый ноутбук не должен быть условием работы производственного контура.
5 Проверка и эксплуатация автоматизации
Зелёный статус выполнения означает только то, что сценарий завершился по своим правилам. Ветка обработки ошибки тоже может завершиться успешно. Приёмка проверяет запись в реестре, уведомления и состояние данных.
| Проверка | Ожидаемый результат | Доказательство |
|---|---|---|
| Обычная заявка | Одна запись с верными полями, уведомления по правилам | ID записи, статус доставки |
| Нет обязательного поля | Понятная ошибка; неполная заявка не выдается за принятую | Ответ формы и журнал |
| Один запрос повторён | Не возникает вторая запись или повторное действие | Проверка реестра и ID |
| Два одновременных повтора | Одна запись благодаря атомарной защите уникальности | Журнал и ограничение хранилища |
| Внешний API недоступен | Согласованная очередь или отказ; сообщение ответственному | Статус ошибки и запись очереди |
| Уведомление не отправлено | Заявка сохранена; повтор не создаёт новую заявку | Статус уведомления |
| Недействительные credentials | Ошибка видна; секрет не попадает в сообщение | Обезличенный журнал |
| Перезапуск сервиса | Принятые заявки сохраняются; ожидающие обрабатываются | Сравнение до и после |
Что согласовать до запуска
- Ответственного за процесс и отдельного ответственного за технические ошибки.
- Срок хранения заявок и журналов, перечень доступов и порядок их отзыва.
- Правила повторных попыток, лимиты и действия при окончательной ошибке.
- Резервное копирование и практическую проверку восстановления.
- Способ ручной обработки во время простоя и порядок возвращения к автоматическому режиму.
Приёмка пилота
Учебный набор: 30 корректных обращений, 10 повторов и все негативные сценарии из таблицы. Условие технической приёмки — отсутствие необъяснимых потерь и дублей в этом наборе. Небольшая выборка проверяет логику, но не доказывает надёжность под любой нагрузкой.
Производительность проверяется отдельно на согласованной пиковой нагрузке. Период наблюдения, допустимые задержки и доступность определяются по требованиям клиента. Результат фиксируется протоколом с входными данными, ожидаемым и фактическим поведением.
6 Расчёт эффекта и решение о пилоте
Расчёт ниже полностью учебный. Он показывает способ оценки, а не цену услуги ДИС. Перед предложением значения заменяются замерами клиента.
| Показатель | Учебное значение | Расчёт |
|---|---|---|
| Заявок в месяц | 300 | По журналу обращений |
| Ручное время на заявку | 6 минут | 30 часов в месяц |
| Время контроля после внедрения | 2 минуты | 10 часов в месяц |
| Высвобожденное время | 20 часов | 30 − 10 |
| Стоимость часа для расчёта | 600 рублей | Внутренняя оценка клиента |
| Оценка ресурса времени | 12 000 рублей в месяц | 20 × 600 |
| Эксплуатационные расходы | 3 000 рублей в месяц | Сервер, сервисы, поддержка |
| Расчётный чистый эффект | 9 000 рублей в месяц | 12 000 − 3 000 |
| Разовые затраты | 36 000 рублей | Учебное допущение |
| Простой срок окупаемости | 4 месяца | 36 000 ÷ 9 000 |
Как читать результат
Высвобожденные часы не равны денежной экономии. Если зарплата не меняется и освободившееся время не используется продуктивно, 12 000 рублей остаются оценкой ресурса, а не сокращением платежей. Дополнительную выручку можно учитывать только с обоснованием; нельзя повторно считать один эффект как экономию и доход.
Проверка чувствительности
При 150 заявках высвобождаются 10 часов: оценка времени составляет 6 000 рублей, после расходов остаётся 3 000 рублей; учебная окупаемость увеличивается до 12 месяцев. Если на практике экономится одна минута на заявку, оценка времени равна расходам эксплуатации и положительного эффекта по этой модели нет.
Решение после пилота
Сравнить фактическое время, ошибки и расходы с исходным процессом. Продолжить, если результат отвечает согласованной цели; скорректировать решение, если проблема в конкретном шаге; остановить, если эффект не подтверждается. Качество и снижение ошибок учитывать отдельно, если денежная оценка недостоверна.
7 Пример сайта и портала
Учебный сценарий основан на типичном запросе центра поддержки: рассказать об участии в проекте, показывать кейсы и документы, принимать заявки и регистрации на мероприятия. Сотрудники должны самостоятельно обновлять материалы. Требование «нужен сайт» раскрывается через пользовательские действия.
Три основных пользователя
- Посетитель понимает назначение центра, находит условия участия и отправляет заявку.
- Сотрудник публикует новость, документ, кейс или мероприятие без вмешательства разработчика.
- Руководитель видит обращения, статусы и согласованные показатели работы.
Минимальный состав
Главная; о центре; предприятиям; кейсы; обучение и мероприятия; документы и формы; новости и медиа; контакты. Состав и объём стартового наполнения фиксируются: число шаблонов страниц, кейсов, документов и мероприятий нельзя оставлять неопределённым.
| Сайт | Портал | Что влияет на оценку |
|---|---|---|
| Публичная информация и формы | Публичная информация и рабочие функции | Количество пользовательских сценариев |
| Новости и документы | Библиотека, источники, поиск, статусы | Модель материалов и фильтры |
| Редактор контента | Несколько ролей и согласование публикаций | Права и процедура публикации |
| Отправка заявки | Учёт, маршрутизация, история обработки | Интеграции и ответственность |
Выбор платформы
WordPress рассматривать для сайта с типовыми страницами, новостями, кейсами и документами. Встроенные роли позволяют разделять возможности пользователей; формы, события и интеграции требуют отдельного подбора и проверки. Документация: https://wordpress.org/documentation/article/roles-and-capabilities/
1С Битрикс рассматривать при обязательном требовании заказчика, согласованной инфраструктуре или нужных возможностях конкретной редакции. Редакцию, лицензию и интеграции проверяют до оценки. Заказную разработку рассматривать, когда существенные рабочие функции неудобно реализовать на CMS.
Для st8dom не следует автоматически предлагать перенос на CMS: сначала оценивается существующий проект и возможность расширить его. Эта методичка не меняет действующий портал и не подтверждает реализацию новых функций.
8 Приёмка сайта и портала
Приёмка должна проверять пользовательские действия и обязанности сотрудников. Скриншот красивой главной страницы не подтверждает работу форм, поиска, прав доступа или резервного восстановления.
| Область | Критерий | Проверка |
|---|---|---|
| Навигация | Нужный раздел доступен по понятному маршруту | Типовые задания посетителю |
| Форма заявки | Валидация, сохранение, доставка и защита повторов | Корректные и ошибочные заявки |
| Мероприятия | Регистрация и ограничения мест по ТЗ | Свободное и последнее место |
| Поиск и фильтры | Результаты соответствуют запросу и категории | Набор заранее заданных запросов |
| Административная панель | Редактор выполняет задачи в пределах роли | Создание и правка материала |
| Доступность | Клавиатура, контраст, масштабирование, метки форм | Ручная проверка сценариев |
| Адаптивность | Нет потери содержимого и недоступных кнопок | Согласованные устройства |
| Аналитика | Цели срабатывают по согласованным событиям | Проверка без дублей |
| Восстановление | Сайт и база возвращаются из копии | Практическое восстановление |
Скорость и версия для слабовидящих
Для LCP web.dev определяет хороший уровень как не более 2,5 секунды на 75-м процентиле посещений. На новом сайте может не хватать полевых данных: тогда лабораторная проверка — предварительная оценка, которую позже дополняют измерением реальных посещений. В договоре указываются страницы, устройство, сеть и метод проверки. Источник: https://web.dev/articles/lcp
Версия для слабовидящих не заменяет доступность основного интерфейса. Требуется проверить навигацию клавиатурой, видимость фокуса, подписи полей, контраст и масштабирование. Дополнительный режим реализуется и принимается по конкретному ТЗ.
Границы ответственности
Исполнитель отвечает за согласованные функции и исправление дефектов. Клиент предоставляет достоверные материалы, доступы и согласования. Хостинг, лицензии, поддержка и новые функции указываются отдельно. Гарантийный срок и условия определяются договором; изменения сторонних сервисов и материалов требуют понятного порядка обработки.
9 Коммерческое предложение и возражения
Пример предложения по автоматизации
«Задача — исключить ручное копирование заявок из одной формы в реестр и сделать видимым статус обработки. Первый этап включает настройку сценария, проверку повторов и ошибок, инструкцию и передачу доступов. Результат принимается по согласованным тестам и пилотному наблюдению. Расширения и регулярные расходы указаны отдельно».
Пример предложения по сайту
«Разработаем сайт центра с согласованными разделами и шаблонами материалов. Посетитель сможет найти условия участия и отправить заявку, сотрудник — публиковать материалы в пределах своей роли. В оценку входят прототип, дизайн, разработка, определённый объём наполнения, формы, проверка и обучение. Срок начинается после получения перечисленных материалов и доступов».
Что обязательно указать
- Задача, состав результата и критерии приёмки.
- Объём страниц, материалов, форм, интеграций и пользовательских ролей.
- Стоимость работ и отдельные регулярные расходы.
- Этапы, сроки согласования и зависимости от клиента.
- Исключения, порядок изменений и цена дополнительных работ.
- Передаваемые файлы, доступы, инструкции, обучение и условия поддержки.
| Возражение | Что уточнить | Следующий шаг |
|---|---|---|
| Дорого | С чем сравнивают и какой бюджет допустим? | Уменьшить объём или сравнить альтернативы |
| Нужно подумать | Неясна польза, цена или риск ошибки? | Уточнить конкретный открытый вопрос |
| И так работает | Есть ли подтверждённая проблема? | Замерить процесс или отказаться от внедрения |
| Боюсь зависимости | Какие доступы и знания останутся у клиента? | Показать состав передачи и поддержки |
| Нужно всё сразу | Что обязательно для первого запуска? | Разделить обязательное и последующие этапы |
Возражение может быть обоснованным отказом. Корректная цель разговора — установить причину и дать возможность принять информированное решение. Цена, бюджет и риск влияют на выбор; обещание пользы не отменяет этих ограничений.
10 Рабочие формы и управление проектом
Карточка задачи
Клиент и владелец процесса: ______________________________
Текущий порядок работы и подтверждённая проблема: __________
Объём обращений и исходные показатели: ____________________
Желаемый результат и способ проверки: _____________________
Участники решения и будущие пользователи: _________________
Системы, доступы и ограничения: ___________________________
Открытые вопросы и необходимые проверки: __________________
Паспорт пилота
Сценарий и границы первого этапа: _________________________
Исходный замер и период наблюдения: _______________________
Критерии успеха и основания для остановки: _________________
Ответственный от клиента и исполнитель: ___________________
Расходы, срок, зависимости и резервный порядок работы: ______
Дата решения о продолжении: ______________________________
Управление этапами
| Этап | Условие перехода | Запись в учёте |
|---|---|---|
| Первичный запрос | Установлены клиент и предмет обращения | Источник и контакт |
| Диагностика | Подтверждены задача и ограничения | Карточка задачи |
| Предложение | Определены объём, цена и приёмка | Версия предложения |
| Согласование | Зафиксированы обязательства сторон | Решение и открытые вопросы |
| Реализация | Пройдены согласованные проверки | Протокол испытаний |
| Передача | Клиент получил результат и инструкции | Акт или протокол передачи |
Показатели и упражнения
Учитывать число подходящих обращений, переходы между этапами, длительность согласования, причины отказа, плановые и фактические затраты, долю исправлений и результат клиента. Конверсия считается для сопоставимой группы за одинаковый период; малые выборки требуют осторожной интерпретации.
Упражнение 1: выбрать одну ручную операцию, описать исходный процесс и критерий успеха автоматизации. Упражнение 2: взять запрос на сайт, указать количество шаблонов, материалов и форм. Упражнение 3: для каждого примера составить предложение и негативные тесты. Следующая версия методички дополняется реальными замерами и подтверждёнными кейсами ДИС.
11 Литература и источники
Основной список содержит 13 позиций: исторические работы и публикации 2022–2026 годов. Дата проверки ссылок — 07.10.2026. Обзор подготовлен по доступным материалам авторов, издателей, организаций и исследовательским аннотациям; не заявляется полный постраничный разбор всех книг. Практические формы и учебные сценарии — авторская адаптация.
[1] Friedman W. A. Birth of a Salesman The Transformation of Selling in America. Harvard University Press, 2004.
https://www.library.hbs.edu/working-knowledge/birth-of-the-american-salesman
[2] Hopkins C. C. Scientific Advertising. 1923. Каталожная запись оригинального издания.
https://www.loc.gov/item/23009362/
[3] Drucker P. F. The Practice of Management. Harper & Brothers, 1954. Сведения издателя о переиздании.
https://shop.elsevier.com/books/practice-of-management/drucker/978-0-08-093907-0
[4] Rackham N. SPIN Selling. McGraw-Hill, 1988.
https://www.mheducation.com/highered/mhp/product/spin-selling.html
[5] Adamson B. Sensemaking for Sales. Harvard Business Review, январь–февраль 2022.
https://store.hbr.org/product/sensemaking-for-sales/R2201J
[6] Dixon M., McKenna T. The JOLT Effect How High Performers Overcome Customer Indecision. 2022.
https://www.penguin.com.au/books/the-jolt-effect-9780593538111
[7] Dunford A. Sales Pitch How to Craft a Story to Stand Out and Win. Page Two, 2023.
https://pagetwo.com/book/sales-pitch/
[8] Dixon M., Channer R., Freeman K., McKenna T. The Activator Advantage What Today’s Rainmakers Do Differently. Harvard Business Review Press, 2025.
https://www.dcminsights.com/activator-advantage
[9] McKinsey & Company. Five Fundamental Truths How B2B Winners Keep Growing. 12.09.2024.
https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/five-fundamental-truths-how-b2b-winners-keep-growing
[10] Gartner. Gartner Sales Survey Finds 67% of B2B Buyers Prefer a Rep-Free Experience. 09.03.2026.
https://www.gartner.com/en/newsroom/press-releases/2026-03-09-gartner-sales-survey-finds-67-percent-of-b2b-buyers-prefer-a-rep-free-experience
[11] Edelman, LinkedIn. 2025 B2B Thought Leadership Impact Report. 2025.
https://www.edelman.com/expertise/Business-Marketing/2025-b2b-thought-leadership-report
[12] Brynjolfsson E., Li D., Raymond L. R. Generative AI at Work. NBER Working Paper 31161, 2023. В расчёте обзора использована первоначальная версия.
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4426942
[13] NIST. Artificial Intelligence Risk Management Framework AI RMF 1.0. 26.01.2023. DOI 10.6028/NIST.AI.100-1.
https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
