#dst — посты и обсуждения

​1. Проблема, которую не решают типы

Начну с боли, знакомой каждому, кто работал в крупной кодовой базе.

Идеальная типизация. 90% покрытия. Зелёный CI. Code review в два глаза. И всё равно раз в квартал — инцидент: заказ отменён после отгрузки, платёж возвращён дважды, скидка применена к товару, который в акции не участвует. Ни один тест не упал. Ни один тип не возмутился. Компилятор был счастлив.

Теперь добавьте вторую картину. Разработчик просит Copilot «написать метод refund для платежа», получает аккуратный, компилирующийся, покрытый тестами код — и через месяц выясняется, что он не учитывает правило «возврат невозможен после отгрузки». Copilot не ошибся синтаксически. Он ошибся семантически — потому что семантики в его контексте не было.

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

За тридцать лет мы построили мощную инфраструктуру для типов: компиляторы, IDE, линтеры, системы сборки. Для смысла мы построили комментарии, вики и надежду на дисциплину. Неудивительно, что именно смысл утекает первым.

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

Эта статья — о том, как пройти между крайностями. Не «нужна ли семантика», а где именно, в каком объёме и по какой цене. Ответ — пирамида семантической надёжности и матрица рисков, которая говорит, где остановиться.

2. Матрица рисков: не вся кодовая база одинакова

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

Разобьём кодовую базу на четыре зоны по двум осям: цена ошибки и частота изменения правил.

| Зона | Примеры | Цена ошибки | Частота изменения правил |

|---|---|---|---|

| Critical Path | Платежи, возвраты, доступ, compliance, налоги | Очень высокая (деньги, репутация, регуляторика) | Средняя (медленно, но с высокими последствиями) |

| Core Domain | Заказы, корзина, каталог, ценообразование | Высокая | Высокая |

| Supporting | Уведомления, отчёты, интеграции | Средняя | Средняя |

| Utility | Утилиты, скрипты, миграции, DTO | Низкая | Низкая |

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

Ключевой принцип: уровень строгости определяется ценой ошибки, а не эстетикой архитектора.

3. Пирамида семантической надёжности

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

Уровень 0 — Комментарии и документация

Дёшево, не проверяется, деградирует. Подходит для Utility и скриптов. Честная позиция: «мы не формализуем это, потому что цена ошибки ниже цены формализации». Это нормально — при условии, что решение принято осознанно, а не по умолчанию.

Уровень 1 — Типы и схемы

Строгая типизация, OpenAPI, JSON Schema, branded types. Ловит структурные ошибки: «передали строку вместо числа», «забыли поле в ответе». Это стандарт для всей кодовой базы — и он уже есть у большинства команд. Дальше начинается то, чего у большинства нет.

Уровень 2 — Контракты и property-based testing

Design by Contract (предусловия, постусловия, инварианты объекта) плюс property-based testing (Hypothesis, QuickCheck). Ловит нарушения поведения: «вызвали refund на незавершённом платеже», «сумма возврата превысила сумму платежа». Это дешёвый мост к семантике — и самая недооценённая часть пирамиды.

Ключевое преимущество: property-based testing не требует онтологии. Вы описываете свойство на языке предикатов, фреймворк генерирует сотни входов и ищет контрпримеры. Полдня работы — и вы ловите нарушения, о которых не знали. Для Core Domain это часто оптимум...

#DST #DSTGlobal #ДСТ #ДСТГлобал #LLM #искусственныйинтеллект #logosk #ООП #онтология #DbC #DTO #IDE #линтеры #системысборки #Copilot #семантика #semanticdb #OpenAPI #JSON #brandedtypes #AWS #Azure #MongoDB #Utility

Источник: https://dstglobal.ru/club/1264-ot-kontraktov-k-ontologijam-stroim-piramidu-semanticheskoi-nadyozhnosti.html

MCP, REST/HTTP API и Apache Kafka часто противопоставляют друг другу как конкурирующие способы интеграции агентного ИИ. Это ложная дихотомия. Перечисленные технологии решают разные задачи на разных уровнях архитектуры: MCP стандартизирует доступ агента к инструментам и контексту, REST/HTTP API задаёт синхронный контракт взаимодействия с системой, а Kafka обеспечивает событийную магистраль, разделение зависимостей и согласованное распространение операционных данных. Ошибка начинается там, где одну из технологий пытаются назначить универсальным интеграционным слоем. Надёжная архитектура агентного ИИ, наоборот, строится на явном разделении интерфейса, контракта и потока данных.

Ключевой тезис

MCP — это интерфейсный слой для инструментов и контекста агента.

REST/HTTP API — это синхронный контракт доступа к системе.

Apache Kafka — это событийная магистраль и основа для согласованного операционного состояния.

Эти уровни не заменяют друг друга. Они дополняют друг друга, а архитектурное решение заключается не в выборе «одного победителя», а в определении границ ответственности, компромиссов и точек интеграции.

1. Постановка проблемы: почему MCP не является заменой REST или Kafka

В ноябре 2024 года Anthropic представила Model Context Protocol, MCP, как открытый стандарт подключения ИИ-помощников к внешним инструментам и источникам данных. До MCP каждой модели требовался собственный коннектор к каждой внешней системе. Три модели и десять систем означали до тридцати пользовательских интеграций для разработки и поддержки. MCP сводит эту задачу к единому стандартному интерфейсу: совместимый клиент взаимодействует с совместимым сервером без предварительной координации.

В марте 2025 года о поддержке MCP объявила OpenAI, в апреле 2025 года — Google DeepMind. К декабрю 2025 года, по опубликованным данным экосистемы, количество ежемесячных загрузок SDK MCP превысило 97 миллионов для Python, TypeScript, Java, Kotlin, C# и Swift. Anthropic передала протокол фонду Agentic AI Foundation при поддержке Linux Foundation; AWS, Google, Microsoft, Bloomberg и OpenAI стали платиновыми членами. MCP перестал быть экспериментом для разработчиков.

При этом зрелость внедрения опережает зрелость безопасности и управления. Большинство инцидентов 2025 и начала 2026 года связано не с недостатками самого протокола, а с ошибками реализации. Анализ 2614 реализаций MCP, проведённый Endor Labs, показал, что 82% используют операции с файловой системой, подверженные обходу путей, а 67% — API, связанные с внедрением кода. Аутентификация корпоративного уровня на базе OAuth 2.1 и SAML/OIDC включена в дорожную карту на 2026 год, но работа над ней ещё не завершена.

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

2. Архитектурная рамка: три уровня, три ответственности

Для экспертного обсуждения полезно разделять три уровня.

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

Второй уровень — синхронный контракт доступа к системе. Здесь работают REST/HTTP API, OpenAPI, нативные SDK и OData. Этот уровень отвечает на вопрос: как система принимает запрос, какие у неё права доступа, версионирование, формат ошибок, идемпотентность и SLO.

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

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

#DST #DSTGlobal #ДСТ #ДСТГлобал #искусственныйинтеллект #MCP #REST #API #ApacheKafka #агентныйии #Anthropic #ModelContextProtocol #OpenAI #DeepMind #Python #TypeScript #Java #Kotlin #AWS #SOA #SAP #Salesforce #Oracle #ApacheIceberg #Claude #ChatGPT #AmazonBedrock #LlamaIndex

Источник: https://dstglobal.ru/club/1263-mcp-resthttp-api-i-apache-kafka-arhitekturnoe-rukovodstvo-po-integracii-agentnogo-ii.html

​16 октября 2026 года, Москва — Ижевск — Краснодар. Российская IT-компания DST Global (ООО «ДСТ Глобал»), аккредитованный разработчик программного обеспечения с восемнадцатилетней историей, официально объявляет о технологическом запуске регионального маркетплейса ​Rubay — торговой площадки для производителей, дистрибьюторов и покупателей Краснодарского края, построенной на базе флагманской CMF/CMS-системы DST Platform.

Проект реализован по заказу компании ООО «ЮГ-СИТИ» (ИНН 2309166830), владельца сайта rubay.ru. Запуск знаменует выход DST Global в сегмент региональных торговых экосистем и демонстрирует возможности DST Platform в создании высоконагруженных маркетплейсов с полным циклом электронной коммерции.

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

Технологический фундамент: почему Rubay построен на DST Platform

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

Стратегическое решение о создании собственной технологической платформы было принято руководством компании в 2020 году. В то время как большинство российских разработчиков продолжали использовать зарубежные фреймворки и CMS с закрытым кодом, DST Global инвестировала значительные ресурсы в построение ​DST Platform — гибридной системы, совмещающей возможности системы управления содержимым (CMS) и мощного Content Management Framework (CMF). Это серверное решение, разработанное на языке PHP с открытым исходным кодом, спроектировано для обеспечения максимальной гибкости, производительности и масштабируемости.

Ключевая особенность DST Platform — модульная архитектура с компактным ядром, обеспечивающим API для взаимодействия с модулями. Ядро системы отвечает за управление контентом, пользователями, правами доступа и базовыми бизнес-процессами, тогда как специализированные модули добавляют отраслевую функциональность. Такой подход позволяет не только быстро запускать типовые проекты, но и легко адаптировать платформу под уникальные требования заказчика, добавляя кастомные компоненты без необходимости переписывать всю систему с нуля.

За десять лет существования платформа прошла множество итераций. В 2024 году DST Platform заняла первое место в рейтинге профессиональных платформ, а профильные издания, включая РБК и портал «Российские Технологии», отметили её как первую в России CMS/CMF, где технологии искусственного интеллекта встроены прямо в ядро системы и автоматизируют рутинные задачи на уровне платформы, а не через внешние плагины.

Для проекта Rubay выбор DST Platform был обусловлен несколькими факторами. Во-первых, платформа изначально проектировалась с учётом высоких нагрузок, характерных для крупных маркетплейсов и e-commerce проектов, — а Rubay ориентирован на обслуживание сотен тысяч покупателей и продавцов Краснодарского края. Во-вторых, встроенная система таксономии позволяет создавать произвольное количество товарных категорий и ассоциировать их с модулями, что идеально подходит для детализированной структуры маркетплейса — от кормов для животных и мебели до электроники и детских товаров. В-третьих, наличие готовых компонентов для электронной коммерции (каталоги, корзина, заказы, платежи, доставка) и социальных функций (блоги, клубы, комментарии, отзывы, рейтинги) позволило реализовать сложную гибридную экосистему в сжатые сроки без потери качества.

«Запуск Rubay — это не просто создание очередного маркетплейса, а формирование региональной торговой экосистемы, которая объединяет производителей, дистрибьюторов и покупателей Кубани в едином цифровом пространстве, — комментирует представитель DST Global. — Мы построили платформу, которая выдерживает пиковые нагрузки, обеспечивает стабильную работу всех сервисов и готова к масштабированию на годы вперёд. Rubay демонстрирует, что DST Platform способна решать задачи любого уровня сложности — от корпоративных порталов до высоконагруженных маркетплейсов с полным циклом электронной коммерции».

Rubay: региональный маркетплейс с полным циклом электронной коммерции

Проект Rubay реализован компанией ООО «ЮГ-СИТИ» и позиционируется как интернет-воплощение исторической Генуэзской (Анапской) торговой дороги — части Великого шёлкового пути, проходившей через территорию Краснодарского края и соединявшей генуэзские торговые пункты с Ираном, Китаем и северным Туркестаном. Идеологическая основа проекта опирается на историческое наследие региона и стремление возродить торговую активность Кубани в цифровом формате...

#Rubay #Рубэй #Рубей #Новыймаркетплейс #МаркетплейсRubay #НовыймаркетплейсКраснодар #МаркетплейсКраснодар #НовыймаркетплейсКубани #МаркетплейсКубани #ЭкосистемаRubay #ЭкосистемаКубани #ЭкосистемаКраснодарскогокрая #ЭкосистемаКраснодар #DST #DSTGlobal #ДСТ #ДСТГлобал #DSTplatform #ДСТПлатформ

Читать далее: https://dstglobal.ru/club/1262-dst-global-zapustili-rubay-pervyi-regionalnyi-marketpleis-kubani-na-baze-sistemy-dst-platform.html

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

Ключевые слова: управление данными, Data Governance, AI Governance, агентный ИИ, мультиагентная оркестрация, AI TRiSM, MCP, A2A, Data Fabric, Data Mesh, Data Contracts, качество данных, происхождение данных, наблюдаемость, контекстная инженерия, Agent Identity, MLOps, DataOps, векторные базы данных, RAG, нулевое доверие, конфиденциальность, регуляторное соответствие.

1. Введение: почему управление данными становится ядром агентной эры

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

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

Низкое качество данных — это уже не только проблема отчётности. Это фундаментальная проблема искусственного интеллекта. Неточные, неполные, устаревшие или плохо управляемые данные приводят к предвзятым результатам, нарушениям нормативных требований, галлюцинациям LLM, ошибочным бизнес-решениям и подрыву доверия клиентов. По оценкам Gartner, плохое качество данных обходится организациям в среднем в 12,9 млн долларов в год, а для финансовых организаций медианный показатель достигает 49 млн долларов.

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

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

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

Основные цели управления данными:

- повышение гибкости принятия бизнес-решений на основе данных;

- обеспечение беспрепятственного обмена знаниями внутри предприятия;

- устранение двусмысленности и укрепление доверия к данным;

- повышение доверия к данным, улучшение процесса принятия решений и ускорение циклов инноваций;

- улучшение соответствия нормативным требованиям, сокращение дублирования данных и повышение гибкости бизнеса.

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

2. Терминологическая база

Для профессионального обсуждения важно различать несколько понятий.

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

Управление данными как governance (Data Governance) — система принятия решений и подотчётности: кто владеет данными, кто отвечает за качество, кто определяет политики, как обеспечивается соответствие и как измеряется ценность.

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

Агентный ИИ (Agentic AI) — системы, способные планировать, вызывать инструменты, использовать память, взаимодействовать с API и автономно выполнять задачи от имени пользователя или организации.

Мультиагентная оркестрация — архитектурный паттерн, при котором несколько специализированных агентов делегируют задачи друг другу, образуя цепочки и графы вызовов для решения сложных задач. Gartner прогнозирует, что к 2028 году 70% AI-приложений будут использовать мультиагентные системы.

Data Product — управляемый набор данных или сервис данных с владельцем, SLA, контрактом, документацией, метриками качества и измеримой бизнес-ценностью.

Data Contract — формальное соглашение между производителем и потребителем данных, описывающее схему, семантику, качество, SLA, права доступа, происхождение, версионирование и правила изменения...

#DST #DSTGlobal #ДСТ #ДСТГлобал #AITRiSM #MCP #A2A #DataFabric #DataMesh #оркестрация #Data Governance #AIGovernance #агентныйИИ #LLM #искусственныйинтеллект #GDPR #HIPAA #потоковыеданные #IoT #Iceberg #DeltaLake #Parquet #Airflow #HabeasWeights #auniversum #ауниверсум #Lambdauniversum #LOGOSk #SemanticDB #Efos #BlindSpots

Источник: https://dstglobal.ru/club/1261-upravlenie-dannymi-v-epohu-agentnyh-tehnologii

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

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

Резюме для руководителей

В любом корпоративном обсуждении искусственного интеллекта рано или поздно возникает один и тот же неудобный вопрос: что происходит с нашими данными после того, как они покидают нашу территорию? Внедряете ли вы большую языковую модель в конвейер обработки заявок, запускаете систему генерации с дополнением на основе извлечения (Retrieval-Augmented Generation, RAG) для внутреннего поиска знаний или позволяете агентному рабочему процессу выполнять автономные действия в отношении производственных систем, ответ на этот вопрос определяет, станет ли ваша инициатива в области ИИ конкурентным преимуществом или потенциальным источником проблем с соблюдением нормативных требований.

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

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

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

1. Почему ИИ меняет расчёты безопасности данных

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

1.1. Граница между запросами и данными изначально проницаема

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

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

1.2. Система может получать инструкции на основе входных данных

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

Экспертный вывод: промпт-инъекция — это не разновидность «неправильного вопроса», а класс атак, требующий архитектурных мер. Нельзя полагаться только на системную инструкцию «никогда не раскрывай секреты» или «не выполняй команды из документа». Такие инструкции полезны, но не являются механизмом безопасности.

1.3. Система способна действовать, а не просто отвечать

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

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

1.4. Объём хранимых данных увеличивается

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

#DST #DSTGlobal #ДСТ #ДСТГлобал #Защита #безопасность #искусственныйинтеллект #защитаданных #ZDR #DPA #RAG #логи #GDPR #ФСТЭК #ИИсистемы #аудит #HIPAA #ACL #контур #биометрия #NDA #инъекции

Источник: https://dstglobal.ru/club/1260-zaschita-korporativnyh-dannyh-shablony-i-praktiki-obespechenija-bezopasnosti-pri-integracii-s-i.html