Глава 9 · Часть III. Как покупать, принимать и масштабировать системы ИИ
Новая культура закупки систем на базе больших языковых моделей, систем ИИ и платформенных решений через жизненный цикл и метрики приемки.
AI-архитектура суверенной цифровой трансформации
ТЗ больше не спасает от ИТ-долгостроя
Почему государству и крупным организациям нужна новая культура закупки систем на базе больших языковых моделей, систем ИИ и платформенных решений.
Самый дорогой ИТ-долгострой начинается не с плохого подрядчика и не с «не того» стека. Часто он начинается с уверенности, что сложную цифровую систему можно заранее описать как закупку мебели: перечень функций, сроки, цена, акт приемки. Для классической автоматизации такой подход иногда работает. Для систем на базе больших языковых моделей — нет. Модель может давать разные ответы на похожие вопросы, качество зависит от данных заказчика, безопасность определяется не только кодом, но и контуром размещения, журналированием, доступами, источниками знаний и поведением пользователей. Проблема не в самом ТЗ. Проблема в попытке описать неопределенный проект ИИ как полностью известный заранее объект. Государству, госкорпорациям и крупному бизнесу нужна не отмена закупочной дисциплины, а более зрелая декомпозиция: обследование, прототип, пилот, архитектура, платформа, модули, интеграции, аудит, обучение, сопровождение и развитие.
Краткие выводы для ЛПР
- Фиксированное ТЗ не исчезает, но меняет роль. В проектах ИИ оно должно фиксировать этапы, ограничения, метрики, ответственность и критерии приемки, а не выдумывать «окончательный образ» системы до обследования данных.
- проект на базе больших языковых моделей нужно закупать как жизненный цикл. Сначала обследование процессов и данных, затем прототип, пилот на ограниченном контуре, архитектурное решение и только потом промышленное масштабирование.
- Приемка системы ИИ должна быть метрической. Нужны контрольные наборы задач, оценка точности, полноты, доли ошибок, уровня галлюцинаций, скорости ответа, стоимости запроса, журналирования, безопасности и эксплуатационной готовности.
- Закупку нужно декомпозировать по предметам ответственности. Платформа, прикладные модули, модели, данные, поиск по проверенным источникам перед ответом модели, шлюз доступа к большим языковым моделям, интеграции, аудит информационной безопасности, обучение и сопровождение — разные объекты управления.
- Для РФ критичны импортонезависимость, защищенные контуры и права на данные. Реестр российского ПО, национальный режим, требования к ГИС, КИИ и персональным данным должны учитываться до пилота, а не после промышленного запуска.
- Итерационность не означает непрозрачность. Гибкая поставка может быть прозрачной, если заранее определены этапы, артефакты, метрики, порядок изменения перечень задач развития и условия приемки.
- Главный риск — закупка «нереалистичных ожиданий от ИИ». Без владельца процесса, данных, сценариев и контрольного набора задач проект на базе больших языковых моделей становится демонстрацией, а не управленческим инструментом.
Почему классическое ТЗ трещит именно на проектах на базе больших языковых моделей
В закупке ИТ-систем исторически доминировала логика «описать — разработать — сдать». Заказчик формирует техническое задание, подрядчик разрабатывает, приемка сверяет результат с перечнем функций. Для понятных задач — сайт, реестр, учетная система, типовая интеграция — эта модель может быть достаточной.
проект на базе больших языковых моделей устроен иначе. Большая языковая модель — это не просто функция, которая каждый раз возвращает один и тот же результат. Она генерирует ответ на основе модели, запроса, контекста, системных инструкций, доступных источников и ограничений. Поэтому качество проекта определяется не только разработкой интерфейса, но и качеством данных, архитектурой доступа к знаниям, безопасностью запросов к модели, политиками обработки данных, интеграциями, обучением пользователей и механизмами контроля.
Российский закупочный контур при этом требует дисциплины описания объекта закупки. В 44-ФЗ описание объекта закупки связано с функциональными, техническими, качественными и эксплуатационными характеристиками, а контракт заключается на условиях закупочной документации и заявки участника.2, 3 В 223-ФЗ конкретная закупочная модель во многом опирается на положение о закупке заказчика, которое регламентирует порядок подготовки и проведения процедур.4
Вывод для руководителя простой: закон не запрещает думать архитектурно. Но закупочная документация должна описывать не фантазию о полностью известной системе, а проверяемый путь к результату.
Не юридическая консультация
Этот материал не является юридическим заключением и не предлагает обходить 44-ФЗ, 223-ФЗ, национальный режим или требования информационной безопасности. Речь идет об управленческой, архитектурной и методологической проблеме закупки сложных ИТ- и систем ИИ. Конкретную закупочную конструкцию нужно проверять с юристами, контрактной службой, ИБ, финансовым блоком и профильным регуляторным контуром.
Российский контекст: закупки, импортонезависимость, ГосТех, данные
Закупка ИТ и систем ИИ не может рассматриваться вне контекста импортонезависимости и суверенной цифровой архитектуры. По состоянию на 2026 год для заказчиков важны как базовые режимы 44-ФЗ и 223-ФЗ, так и национальный режим закупок, реестры российского и евразийского ПО, требования к защищенным контурам, персональным данным, ГИС и КИИ.
Постановление Правительства №1875 от 23 декабря 2024 года закрепило меры национального режима при закупках для государственных и муниципальных нужд и закупках отдельными видами юридических лиц; Минфин разъяснял применение новых единых правил с 1 января 2025 года.5, 6 Минцифры указывает, что реестры российского и евразийского ПО содержат перечни программ, происхождение которых подтверждено; постановление №1236 определяет правила формирования и ведения соответствующих реестров.7, 8
Для проектов ИИ это означает: еще до пилота нужно понимать, где будет размещаться система, какое ПО используется, какие права на данные и результаты сохраняются у заказчика, можно ли переносить знания и логи, есть ли зависимость от внешнего облака, допустима ли обработка конкретных категорий данных в выбранном контуре.
Параллельно формируется стратегический контур цифрового государства. Национальный проект «Экономика данных и цифровая трансформация государства» ориентирован на цифровую трансформацию государственного и муниципального управления, экономики и социальной сферы.10 Платформа «ГосТех» закреплена постановлением Правительства №2338 как единая цифровая платформа РФ.9 Национальная стратегия развития искусственного интеллекта утверждена Указом Президента №490 и обновлялась в 2024 году; в изменениях 2024 года отдельно отражалась увязка федерального проекта «Искусственный интеллект» с национальным проектом по формированию экономики данных.11
Это усиливает главный управленческий тезис: система ИИ для госсектора — не экспериментальная витрина. Это элемент цифровой инфраструктуры, который должен вписываться в архитектуру данных, безопасность, закупочную прозрачность и эксплуатационную модель.
Что это значит для руководителя
Не начинайте закупку системы на базе больших языковых моделей с формулировки «нужен корпоративный ChatGPT». Начинайте с вопроса: какой процесс меняется, какие данные участвуют, где контур обработки, кто владелец результата, как измеряется качество и кто несет эксплуатационную ответственность.
Почему проекты на базе больших языковых моделей имеют высокую неопределенность
У классической информационной системы неопределенность обычно связана с требованиями бизнеса и интеграциями. У систем на базе больших языковых моделей неопределенность шире.
Первая зона — данные. У заказчика могут быть регламенты, переписка, нормативные документы, базы знаний, обращения граждан, внутренние инструкции, протоколы, архивы решений. Но наличие документов еще не означает пригодность для больших языковых моделей. Нужны структура, актуальность, права доступа, классификация, очистка, разметка, контроль источников и механизм обновления.
Вторая зона — качество ответа. Для больших языковых моделей недостаточно проверить, что «ответ появился». Нужно оценить точность, полноту, обоснованность, ссылку на источник, устойчивость к неоднозначному запросу, способность отказывать там, где ответ запрещен политикой данных.
Третья зона — безопасность. Международные практики фиксируют специфические риски приложений на базе больших языковых моделей: внедрение вредоносных инструкций в запрос, раскрытие чувствительной информации, небезопасные плагины, риски цепочки поставки и другие классы угроз. перечень OWASP Top 10 2025 для приложений на базе больших языковых моделей выделяет такие риски, как внедрение вредоносных инструкций в запрос и раскрытие чувствительной информации.15 NIST в профиле рамка управления рисками ИИ для генеративного ИИ описывает необходимость учитывать уникальные риски генеративных систем и управлять ими на протяжении жизненного цикла.16
Четвертая зона — интеграции. система на базе больших языковых моделей редко живет отдельно. Она подключается к СЭД, система управления клиентскими отношениями, реестрам, порталам, хранилищам, шинам данных, сервисам авторизации, внутренним базам знаний, системам мониторинга. Поэтому проект быстро выходит за рамки «поставки модели».
Пятая зона — эксплуатация и стоимость. Важны скорость ответа, стоимость запроса, лимиты, отказоустойчивость, мониторинг, деградация качества, версия модели, журналирование запросов, механизм расследования инцидентов и порядок обновления базы знаний.
Классическая и новая модель закупки: сравнение
| Параметр | Классическая закупка ИТ | Новая модель закупки AI- и систем на базе больших языковых моделей |
|---|---|---|
| Старт проекта | Одно большое ТЗ | Обследование процессов, данных, рисков и контуров |
| Контрактная логика | Большой контракт на разработку | Этапная поставка: обследование, прототип, пилот, платформа, модули |
| Предмет приемки | Перечень функций | Функции + качество результата + безопасность + эксплуатационные метрики |
| Работа с требованиями | Требования фиксируются до проверки данных | Требования уточняются через прототип и пилот в заранее описанном порядке |
| Работа с данными | Данные часто считаются «имеющимися» | Данные становятся отдельным объектом обследования, подготовки и контроля |
| Модель ИБ | Проверка после разработки | ИБ-требования и контур размещения учитываются до пилота |
| Риск | Устаревание ТЗ и конфликт на приемке | Ошибка на раннем этапе выявляется до промышленного масштаба |
| Управление развитием | Допсоглашения и отдельные доработки | Перечень задач развития развития с приоритизацией, метриками и ответственностью |
Новая модель не означает «делать как получится». Наоборот, она требует более строгой управленческой дисциплины. Просто дисциплина переносится с формального списка функций на жизненный цикл: что проверяем, на каких данных, кто принимает, какие метрики считаем, где граница ответственности, как меняем требования, что будет считаться промышленной готовностью.
Ошибка, которую нельзя повторять
Нельзя закупать систему на базе больших языковых моделей как «коробку с интеллектом». Если в документации нет сценариев, данных, метрик, контура размещения, логов и порядка развития, заказчик покупает не результат, а неопределенность.
Матрица закупочной декомпозиции
| Этап / предмет закупки | Что покупается управленчески | Основной результат | Критерий приемки |
|---|---|---|---|
| 1. Обследование процессов и данных | Понимание реальных сценариев, источников, ограничений | Карта процессов, данных, пользователей, рисков | Отчет, согласованный владельцами процессов, ИБ и ИТ |
| 2. Архитектурная концепция | Целевая модель решения | Архитектура, контуры, роли, интеграции, модель данных | Архитектурный документ и решение архитектурного комитета |
| 3. Прототип / минимально рабочий релиз | Проверка гипотезы на ограниченных сценариях | Рабочий прототип без промышленного масштаба | Демонстрация на контрольном наборе задач |
| 4. Пилот на ограниченном контуре | Проверка пользы, качества и рисков | Пилот с реальными пользователями и данными | Метрики качества, замечания информационной безопасности, вывод о масштабировании |
| 5. Платформенное ядро | Базовая инфраструктура системы ИИ | Компоненты управления моделями, доступами, логами | Развернутая платформа в согласованном контуре |
| 6. Прикладные модули | Функциональные сценарии для подразделений | Модули: помощник оператора, анализ документов, поиск, резюме | Модульная приемка по сценариям и метрикам |
| 7. Интеграции | Связь с старым ИТ-контуром, ГИС, СЭД, хранилищами | программные интерфейсы, коннекторы, обмены, мониторинг | Тесты интеграции и регламент эксплуатации |
| 8. Миграция и подготовка данных | Приведение данных к пригодному состоянию | Очищенные, классифицированные, доступные данные | Акт качества данных и правила обновления |
| 9. шлюз доступа к большим языковым моделям | Управляемый шлюз доступа к моделям | Маршрутизация, лимиты, политики, логи, контроль стоимости | Проверка доступа, журналирования и переключения моделей |
| 10. Поиск по проверенным источникам перед ответом модели / база знаний | Поиск по источникам перед генерацией ответа | Индексы, база знаний, ссылки на источники | Метрики поиска, полноты и релевантности |
| 11. Тестирование качества | Доказательство пригодности ответов ИИ | Контрольный набор, отчеты оценки, дефекты | Пороговые значения точности, полноты, ошибок |
| 12. аудит информационной безопасности | Проверка защищенности | Модель угроз, замечания, план устранения | Заключение / отчет ИБ в применимом контуре |
| 13. Обучение пользователей | Управляемое внедрение | Материалы, инструкции, обучение ролей | Подтверждение прохождения и качество применения |
| 14. Эксплуатационное сопровождение | Поддержка промышленной работы | соглашение об уровне сервиса, мониторинг, инциденты, обновления | Отчеты соглашение об уровне сервиса, инциденты, доступность |
| 15. Развитие по перечень задач развития | Контролируемая эволюция системы | Приоритизированный перечень доработок | Регламент изменения, оценка эффекта, приемка итераций |
Критически важно: декомпозиция не должна превращаться в искусственное дробление закупки для обхода процедур. Она должна отражать объективно разные этапы жизненного цикла, разные результаты, разные риски и разные критерии приемки. Конкретную конструкцию нужно согласовывать с контрактной службой и юристами.
Как принимать систему на базе больших языковых моделей
Приемка системы на базе больших языковых моделей должна быть не только функциональной, но и поведенческой, качественной, эксплуатационной и безопасностной. В классической ИТ-системе заказчик проверяет: кнопка есть, отчет формируется, роль назначается, интеграция работает. В системе на базе больших языковых моделей этого недостаточно.
Нужно проверять, как система отвечает на реальные запросы, умеет ли ссылаться на источники, не выдает ли запрещенные сведения, как ведет себя при неоднозначном вопросе, как журналирует действия, сколько стоит один запрос, выдерживает ли нагрузку, можно ли расследовать ошибку.
| Метрика приемки | Что показывает | Как применять |
|---|---|---|
| Точность ответов | Доля корректных ответов на контрольном наборе | Заранее согласовать тестовый набор и пороги |
| Полнота ответа | Достаточность ответа для задачи пользователя | Оценивать экспертами предметной области |
| Доля ошибок | Частота неверных, неполных или опасных ответов | Вести классификацию ошибок |
| Уровень галлюцинаций | Склонность выдавать неподтвержденные утверждения | Проверять ссылки на источники и фактическую базу |
| Скорость ответа | Пригодность для рабочего процесса | Фиксировать норматив времени для разных сценариев |
| Стоимость запроса | Экономика эксплуатации | Считать по типам сценариев и нагрузке |
| Качество поиска источников | Релевантность слоя поиска по проверенным источникам перед ответом модели | Проверять наиболее релевантных источников и покрытие базы знаний |
| Соблюдение политик данных | Защита персональных, служебных и иных ограниченных данных | Тестировать роли, маскирование, запреты |
| Наличие логов | Возможность аудита и расследования | Проверять полноту журналов и доступ к ним |
| Отказоустойчивость | Способность работать при сбоях | Тестировать деградацию, резервирование, сценарии отказа |
| Безопасность | Устойчивость к атакующим и ошибочным запросам | Проводить ИБ-тесты, включая внедрение вредоносных инструкций в запрос |
| Документация | Передаваемость и сопровождаемость | Проверять администраторскую, пользовательскую и эксплуатационную документацию |
| Удовлетворенность пользователей | Реальная пригодность | Измерять после пилота, а не после презентации |
| Экономия времени | Практический эффект | Сравнивать время до и после внедрения |
| Снижение ручной нагрузки | Освобождение специалистов от рутинных операций | Считать по процессам и ролям |
NIST SP 800-218A отдельно расширяет практики безопасной разработки на разработку моделей ИИ в течение жизненного цикла, а ISO/IEC 42001 задает рамку системы управления ИИ, включая управление рисками, прозрачность и постоянное улучшение.17, 18 Для закупки это означает: приемка должна проверять не только продукт, но и управляемость жизненного цикла ИИ.
Для ИТ-директора и директора по цифровой трансформации
Включайте в закупку не только разработку, но и эксплуатационную модель: кто управляет версиями модели, кто обновляет базу знаний, кто анализирует логи, кто отвечает за стоимость запросов, кто принимает новые сценарии.
Риски и ограничения: зрелая позиция вместо технооптимизма вокруг ИИ
| Риск | Последствие | Как управлять |
|---|---|---|
| Зависимость от поставщика | Зависимость от одного поставщика, модели или облака | Требовать переносимость данных, открытые программные интерфейсы, exit plan, описание форматов |
| «Магический ИИ» без сценариев | Демонстрация есть, управленческого эффекта нет | Начинать с владельца процесса и контрольного набора задач |
| Низкое качество данных | Ответы неточны, пользователи теряют доверие | Закупать обследование и подготовку данных как отдельный этап |
| Слабая приемка | Формальная сдача непригодной системы | Вводить метрики качества, безопасности и эксплуатации |
| Невозможность объяснить результат | Сложность аудита и управленческой ответственности | Использовать поиск по проверенным источникам перед ответом модели, ссылки на источники, логи, классификацию ответов |
| Персональные данные | Регуляторные и репутационные риски | Проверять правовые основания, контур обработки, маскирование, доступы |
| Скрытая зависимость от внешнего облака | Риск утечки, недоступности, санкционной зависимости | Фиксировать контур размещения, обработку данных, права и логи |
| Нет компетенций у заказчика | Подрядчик фактически управляет архитектурой | Формировать внутренний офис управления ИИ, архитектурный комитет, владельцев процессов |
| Конфликт закупочной документации и итераций | Споры на приемке, затяжные доработки | Описывать этапы, артефакты, порядок изменения перечень задач развития и критерии перехода |
Для ГИС и КИИ риски безопасности должны рассматриваться не как «общая осторожность», а как обязательный архитектурный контур. ФСТЭК предъявляет требования по защите информации в государственных информационных системах и требования по обеспечению безопасности значимых объектов КИИ; 187-ФЗ регулирует безопасность критической информационной инфраструктуры РФ.12, 13 При обработке персональных данных нужно учитывать требования 152-ФЗ и практику Роскомнадзора, включая обязанность уведомления до начала обработки в применимых случаях.14
Для ИБ
система на базе больших языковых моделей — это не только модель. Это новый канал доступа к данным. Поэтому ИБ должна проверять не «чат», а весь контур: источники, роли, запросы к модели, плагины, программные интерфейсы, логи, хранение запросов, маскирование и расследование инцидентов.
Что делать руководителю в ближайшие 90 дней
- Назначить владельца процесса применения ИИ. Не ИТ вообще, а конкретного бизнес- или государственного владельца сценария: обращения, документы, закупки, поддержка, контроль, аналитика.
- Провести инвентаризацию данных. Какие источники есть, кто владелец, где хранятся, какие права доступа, есть ли персональные данные, устаревшие документы, дубли, закрытые сведения.
- Выбрать 3–5 приоритетных сценариев. Например: поиск по нормативной базе, подготовка резюме документов, поддержка оператора, анализ обращений, помощь в подготовке ответов.
- Сформировать контрольный набор задач. Не общие пожелания, а реальные запросы пользователей с эталонными ответами, источниками и критериями качества.
- Определить контур размещения. Внутренняя инфраструктура организации, защищенный частный контур, доверенное облако, ГосТех-совместимая архитектура — выбор должен зависеть от данных и рисков.
- Разработать модель закупочной декомпозиции. Отделить обследование, прототип, пилот, платформу, модули, интеграции, аудит информационной безопасности, обучение и сопровождение.
- Согласовать метрики приемки. Точность, полнота, ошибки, галлюцинации, скорость, стоимость запроса, логи, безопасность, удовлетворенность пользователей, экономия времени.
- Создать порядок развития после пилота. Перечень задач развития, владельцы, приоритеты, бюджет, процедура изменений, критерии промышленного масштабирования.
Чек-лист заказчика перед закупкой системы на базе больших языковых моделей
| Вопрос | Да / нет |
|---|---|
| Есть ли владелец процесса, а не только ИТ-заказчик? | □ |
| Описаны ли данные, источники, владельцы и права доступа? | □ |
| Определены ли классы риска и категории данных? | □ |
| Есть ли контрольный набор задач и эталонных ответов? | □ |
| Определены ли метрики качества ответов ИИ? | □ |
| Определен ли контур размещения и обработки данных? | □ |
| Предусмотрены ли логи запросов, ответов и действий пользователей? | □ |
| Описаны ли программные интерфейсы и интеграции с наследованными системами? | □ |
| Есть ли требования к переносимости данных и выходу от поставщика? | □ |
| Описан ли порядок развития после пилота? | □ |
| Есть ли роль ИБ в пилоте, а не только на финальной приемке? | □ |
| Зафиксированы ли требования к документации, обучению и сопровождению? | □ |
Метрики успеха после внедрения
| Направление | Метрика |
|---|---|
| Скорость изменений | Время от запроса на новый сценарий до выпуска в пилот / промышленную среду |
| Снижение ручного труда | Количество часов, снятых с операторов, аналитиков, специалистов поддержки |
| Качество данных | Доля актуальных, классифицированных, доступных и проверенных источников |
| Снижение рисков | Количество выявленных и устраненных замечаний информационной безопасности до промышленного запуска |
| Стоимость изменений | Стоимость доработки сценария или модуля по сравнению с разработкой и сопровождением наследованных систем |
| Скорость вывода модулей | Время разработки и приемки нового прикладного модуля |
| Качество приемки | Доля сценариев, прошедших контрольный набор без критических ошибок |
| Прозрачность процессов | Наличие логов, отчетов, владельцев и статусов по каждому сценарию применения ИИ |
| Управляемость AI | Доля сценариев с утвержденными политиками данных, метриками и ответственными |
Преимущества новой модели
Для государства новая модель снижает риск ИТ-долгостроев, потому что ошибка выявляется на этапе обследования или пилота, а не после многолетней разработки. Она повышает прозрачность, потому что каждый этап имеет свой результат и критерии приемки. Она улучшает контроль данных, потому что данные становятся самостоятельным предметом анализа, а не «входным фоном». Она снижает зависимость от конкретного поставщика, если заранее фиксируются программные интерфейсы, переносимость, права на данные, архитектурные интерфейсы и порядок выхода.
Для бизнеса и подрядчиков новая модель также выгодна. Предмет работ становится яснее. Конфликтов на приемке меньше, потому что качество измеряется не общими ожиданиями, а согласованными метриками. Пилоты проще запускать, потому что они не маскируются под промышленную систему. Эксплуатационная ответственность понятнее: кто отвечает за модель, кто за данные, кто за интеграции, кто за логи, кто за соглашение об уровне сервиса.
Заключение
Государству и крупным организациям нужна не отмена ТЗ, а новая культура закупки цифровых и систем ИИ. Техническое задание должно перестать быть попыткой угадать сложную систему до того, как изучены данные, сценарии, пользователи, контуры и риски. Его роль должна стать другой: фиксировать проверяемые этапы, управленческие решения, архитектурные ограничения, метрики качества, требования безопасности и порядок развития.
Проекты на базе больших языковых моделей особенно чувствительны к ошибке старта. Если заказчик сразу закупает «интеллектуальную платформу» без обследования, он переносит неопределенность внутрь большого контракта. Потом выясняется, что данные неполные, пользователи задают другие вопросы, интеграции сложнее, модель отвечает нестабильно, ИБ требует другой контур, стоимость запроса выше ожиданий, а формальная приемка не показывает реальной пользы. Так рождается ИТ-долгострой нового типа: система вроде бы создана, но не стала рабочим инструментом.
Зрелая модель начинается иначе. Сначала исследование процессов и данных. Затем прототип, который проверяет гипотезу. Затем пилот на ограниченном контуре, где появляются метрики качества, безопасности и пользы. После этого — архитектурная модель, платформенное ядро, прикладные модули, интеграции, поиск по проверенным источникам перед ответом модели, шлюз доступа к большим языковым моделям, аудит информационной безопасности, обучение, сопровождение и развитие по перечень задач развития. Это не ослабление закупочной дисциплины, а ее усиление: каждый этап имеет понятный результат, ответственного, ограничения и критерии приемки.
Для России эта логика особенно важна. AI-архитектура должна учитывать импортонезависимость, реестр российского ПО, защищенные контуры, требования к персональным данным, ГИС, КИИ, ГосТех и права на данные. Иначе организация может получить внешне современное решение, которое невозможно безопасно масштабировать, сопровождать или развивать.
Главный управленческий вывод: большие языковые модели не отменяют архитектуру, закупочную прозрачность, безопасность и ответственность. Они повышают цену ошибки в этих вопросах. Поэтому новая модель госзакупки ИТ и систем ИИ — это не «гибкость ради гибкости», а способ купить не обещание интеллекта, а управляемый цифровой результат.
Список источников
- Редакционный бриф и структура материала: загруженный файл задания.
- 44-ФЗ, статья 33: описание объекта закупки — функциональные, технические, качественные и эксплуатационные характеристики. consultant.ru
- 44-ФЗ, статья 34: контракт заключается на условиях закупочной документации и заявки участника. consultant.ru
- 223-ФЗ: закупки товаров, работ, услуг отдельными видами юридических лиц; роль положения о закупке. government.ru
- Постановление Правительства РФ №1875 о национальном режиме закупок. government.ru
- Разъяснение Минфина о новых единых правилах национального режима с 2025 года. minfin.gov.ru
- Минцифры: реестры российского и евразийского программного обеспечения. digital.gov.ru
- Минцифры: постановление №1236 о правилах формирования и ведения реестров ПО. digital.gov.ru
- Положение о платформе «ГосТех», постановление Правительства №2338. platform.gov.ru
- Национальный проект «Экономика данных и цифровая трансформация государства». government.ru
- Указ Президента №490 о развитии искусственного интеллекта и обновления 2024 года. kremlin.ru
- ФСТЭК: требования по защите информации в ГИС, приказ №17. fstec.ru
- ФСТЭК: требования по безопасности значимых объектов КИИ, приказ №239; 187-ФЗ о безопасности КИИ. fstec.ru
- Роскомнадзор: требования к уведомлению об обработке персональных данных и реестр операторов. 77.rkn.gov.ru
- OWASP Top 10 for Large Language Model Applications 2025. owasp.org
- NIST AI RMF: Generative AI Profile. nist.gov
- NIST SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models. csrc.nist.gov
- ISO/IEC 42001:2023 Artificial intelligence management systems. iso.org