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

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

Делиться

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

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

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

Создание атмосферы

Бизнес: результат превыше всего

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

Они хотят:

• Анализ поведения клиентов
• Протестируйте новые функции
• Используйте ИИ для персонализации пользовательского опыта.
• Извлекайте больше пользы из данных

Правовые аспекты: риски, их минимизация и защита.

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

Они мыслят категориями:

• Правовое основание
• Пропорциональность
• Смягчение последствий
• Доказуемое намерение
• Обоснованность в случае расследования

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

ИТ: Детерминированное управление

ИТ-подразделениям необходима конкретика, они не могут работать в рамках повествования. «Разумные меры предосторожности» не могут быть реализованы. Когда юристы говорят: «Это зависит от обстоятельств», ИТ-специалисты думают: «Я не могу это построить».

ИТ-специалистам необходимо знать:

• Является ли это поле персональными данными?
• Можно ли использовать этот набор данных для обучения модели?
• Какой срок хранения следует установить?
• Следует ли скрыть или удалить этот атрибут?
• Что именно в данном случае представляет собой анонимизация?

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

Как ИИ увеличивает разрыв

Ранее это было управляемо, поскольку темпы использования данных были медленнее. Ручной контроль оставался осуществимым, и юридические отделы могли рассматривать крупные инициативы по отдельности. Эта эпоха закончится, когда объем и скорость использования данных, управляемых ИИ, превзойдут традиционные модели соблюдения нормативных требований. Данные больше не анализируются линейно, они непрерывно обрабатываются, объединяются, обогащаются, используются повторно и моделируются. Автономные агенты могут даже запускать рабочие процессы, генерировать аналитические данные и принимать решения без участия человека. В таком масштабе традиционный юридический надзор перестает работать. Юридический отдел не может вручную оценивать каждый новый случай использования данных или «обработку»¹, а ИТ-отдел не имеет возможности интерпретировать неоднозначные юридические положения каждый раз, когда инженер создает новый конвейер, но бизнес не будет замедлять инновации, ожидая дискуссий по поводу толкования.

От юридических текстов до соответствия требованиям с учетом архитектуры.

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

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

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

Предложение

Основная идея: Исключить человеческие ошибки при передаче информации между юридическим и ИТ-отделами.

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

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

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

Продукты обработки данных, выходные порты и контракты на передачу данных.

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

На практике цепочка может выглядеть так:

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

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

Как выглядит договор на передачу данных

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

Более подробный стандарт для договоров на предоставление данных о продуктах можно найти здесь².

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

Как это работает на практике

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

Для решения этих проблем я предлагаю рабочий процесс с использованием искусственного интеллекта, организованный в три этапа: ПОДГОТОВКА, ПЛАНИРОВАНИЕ и ВЫПОЛНЕНИЕ.

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

Этап 1 — ПОДГОТОВКА

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

Теперь, когда я это сказал, я могу с уверенностью заявить следующее: если я чему-то и научился, работая в крупных организациях и сотрудничая с ними, так это тому, что нет абсолютно никакого смысла ждать, пока все компоненты будут идеально подготовлены, прежде чем начинать. На практике этот момент никогда не наступает. У большинства организаций уже есть части головоломки, даже если они фрагментированы или еще незрелы. Крупное предприятие, уже использующее ту или иную форму Data Mesh, может неосознанно пройти 80% пути, в то время как небольшой стартап может все еще строить свои основы с нуля. Реальность такова, что эти преобразования почти всегда носят итеративный, хаотичный характер и происходят параллельно с развитием бизнеса.

Начните с того, что у вас уже есть, чтобы создать полноценный каталог данных, сосредоточившись на самых простых задачах: ценных наборах данных, которые часто запрашиваются. Что касается «продуктов данных» (в кавычках, потому что вы можете так не называть, и определение разрозненных таблиц может стать вашей первой серьезной проблемой), соберите только ту информацию, которая наиболее важна на данном этапе: название продукта данных, команда, которая им владеет, способ его распространения и краткое описание его содержимого. Все остальное — подробная разметка полей, показатели качества данных, графики происхождения — можно добавлять итеративно по мере развития каталога и повышения уверенности организации в этом процессе. Каталог с пятью хорошо изученными продуктами данных ценнее, чем каталог с двумястами частично документированными.

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

Сами интерфейсы LLM следуют тому же принципу инкрементального развития. Рабочей версией MVP может быть работающий Claude с коннектором к вашему каталогу данных, использующий предварительно настроенный сервер MCP (я использую Entropy Data, поскольку его очень легко настроить для исследовательских целей).

Результат: Не завершенная платформа, а рабочий минимально жизнеспособный продукт (MVP), ориентированный на один или несколько важных наборов данных.

Этап 2 — КАРТА

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

Шаг 1 — Компания инициирует изменение или новую операцию обработки.

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

LLM задает прямые вопросы, основываясь на структуре, созданной ИТ-отделом. В зависимости от ответов со стороны бизнеса, последующие вопросы корректируются с учетом существующих метаданных, корпоративных документов и всего, к чему LLM имеет доступ.

Если компания заявляет что-то расплывчатое, например: «Мы хотим использовать данные клиентов по-другому», специалист по управлению логистической сетью (LLM) направит обсуждение в правильное структурированное русло и проверит, соответствует ли запрос целям, уже указанным в соответствующем договоре с выходным портом, или же он представляет собой новую деятельность по обработке данных, требующую нового или измененного договора.

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

Технически, в основе этого могут лежать YAML-файлы с отслеживанием изменений в GIT, но в рамках магистерской программы по праву можно представить информацию в виде PDF-файла или документа на общей вики-платформе.

Выходные данные: Структурированное описание изменений или новой операции обработки. Указывается тип данных, выходной порт, заявленное назначение, объем изменений, а также любые нерешенные вопросы, отмеченные явным образом.

Шаг 2 — ИТ-отдел получает измененные контракты

ИТ-отдел получает структурированное описание с первого этапа — будь то предлагаемый новый контракт или поправка к существующему.

ИТ-отдел может принять поправки в том виде, в котором они есть (поскольку они уже были проверены на данном этапе), или же может провести их дальнейшее изучение.

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

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

Шаг 3 — Юрист рассматривает, принимает решение и утверждает документ.

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

Это критически важный момент проектирования: система LLM настроена таким образом, чтобы подталкивать юридический отдел к детерминированным ответам. Не «Зависит от обстоятельств» или «Нам нужно будет оценить», а «Да, эта цель совместима с заявленным законным основанием для этого выходного порта», «Нет, этот выходной порт не может использоваться для обучения модели без явного согласия» или «Разрешено при соблюдении этих конкретных условий, которые должны быть зафиксированы в договоре на передачу данных». Везде, где юридический отдел принимает решение, это решение фиксируется в виде структурированного документа, а не абзаца текста, который должен интерпретировать ИТ-специалист.

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

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

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

Этап 3 — БЕГ

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

В исследовании «Автоматизация управления данными с помощью генеративного ИИ»³ в рамках сценария использования в режиме реального времени проверялись 110 запросов на доступ к данным на соответствие политикам конфиденциальности. Были выявлены все проблемы, отмеченные экспертом, а также в 3,6 раза больше предупреждений — 80% из которых эксперты впоследствии подтвердили как обоснованные. Окончательное решение по каждому замечанию остается за человеком. Это не заменяет управление данными; это позволяет управлять данными со скоростью, необходимой для эффективного использования данных с помощью ИИ.

На практике фаза РАБОТЫ означает, что система непрерывно выполняет действия, которые ни одна команда людей не смогла бы выполнить вручную в больших масштабах:

• Автоматическая проверка каждого нового запроса на доступ к данным на соответствие существующим контрактам на выходных портах в момент отправки запроса, до его проверки человеком.
• Мониторинг данных в режиме реального времени на предмет выявления нарушений: при введении нового ограничения система определяет, какие уже утвержденные контракты могут быть затронуты, и отображает их для проверки.
• Ответы на вопросы по вопросам управления данными в режиме реального времени. Юридические отделы могут задавать вопросы в форме диалога: «Какие данные в настоящее время не имеют документально подтвержденного законного основания?» или «К каким выходным портам осуществляется доступ в целях, не указанных в договорах?» Система отвечает мгновенно — без аудита и без цепочки электронных писем.
• Выявление отклонений от политики — при изменении нормативного акта или введении новой внутренней политики система повторно запускает ее для всего комплекса контрактов, чтобы определить, что нуждается в пересмотре.

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

Давайте будем прагматичными: не стоит ожидать идеального старта. На начальном этапе проверки будет выявлен долг в области управления, который незаметно накапливался годами. Это нормально. Видимые проблемы решаемы.

Результат

Коммерческая ценность правильного подхода к этому вопросу

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

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

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

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

Моя единственная претензия к такому подходу

Есть один сценарий будущего, который меня беспокоит (помимо того, что мы все станем похожи на людей из мультфильма «ВАЛЛ-И»). Что если мой предложенный план окажется слишком удачным? Он настолько отлажен, что мы станем слишком самоуверенными.

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

Люди начинают оценивать форму результата, а не его содержание. Вместо «Да, запрос интерпретируется правильно» появляется фраза «Выглядит отлично». Со временем «человеческий фактор» ослабевает. Сначала мы проверяем, затем только одобряем, потом начинаем просить другого специалиста проверить, не упустил ли первый. В конце концов, организация перестает передавать знания между людьми; она начинает передавать правдоподобные резюме между системами . Опасность заключается не в том, что ИИ совершит одну очевидную ошибку. Опасность в том, что ответственность распределяется по цепочке прекрасно отформатированных результатов, которыми никто полностью не владеет, не понимает и на изучение которых у кого нет времени. Когда что-то идет не так, каждый может указать на передачу, проверку, резюме или этап утверждения. Но первоначальный контекст исчезает. Технически, в цикле по-прежнему присутствуют люди. Просто в нем больше нет человеческого суждения в той точке, где это имеет значение.

А что, если мы ничего не предпримем?

Как сказал Жан-Поль Сартр: «Как только мы узнаем и осознаем, мы несем ответственность за свои действия и бездействие». Неспособность к переменам — это не нейтральность, а регрессивный выбор. Поэтапное внедрение Закона об ИИ означает, что организации, которые к тому времени не внедрили грамотность в этой области на практике, уже нарушают требования. Окно возможностей для соблюдения требований сужается, в то время как скорость развития ИИ продолжает удваиваться.

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

Если бы у меня был хрустальный шар

Если бы я мог заглянуть в свой хрустальный шар, я бы предсказал какое-нибудь проявление ажиотажа вокруг концепции «плато продуктивности» по версии Gartner.

Я считаю, что примерно в 2027/2028 годах со стороны регулирующих органов будет оказано значительное сопротивление, если мы не сможем ограничить контроль. В ближайшие два года в новостях появится немало реальных историй ужасов о неудачных попытках внедрения агентного ИИ. Сопротивление будет встречено компаниями и консалтинговыми фирмами, которые обещают более управляемые внедрения (например, те, которые я предлагаю), и затем в течение многих лет будет происходить эта тонкая игра между регулирующими органами и компаниями, которые раздвигают границы возможного.

В конце концов мы выживем, и, скорее всего, всё будет не так драматично, как некоторые (например, я) себе представляют.

[1] «Обработка» как определено в статье 4(2) Общего регламента по защите данных (ЕС) 2016/679 (GDPR).
[2] Bitol. (2025). Open Data Contract Standard (ODCS) (v3.1.0). LF AI & Data Foundation. https://bitol-io.github.io/open-data-contract-standard
[3] Диц, Л. В., Видер, А., и Харрер, С. (2025). Автоматизация управления данными с помощью генеративного ИИ. Конференция AAAI/ACM по ИИ, этике и обществу. Доступно по адресу: Автоматизация управления данными с помощью генеративного ИИ
[4] Наннини Л., Смит А.Л., Магджини М.Дж., Панаи Э., Фелисиано С., Тьюлканов А., Маран Э., Джили Дж. и Бисконти П. (2026). Агенты ИИ в соответствии с законодательством ЕС: архитектура соответствия для поставщиков ИИ. arXiv. https://arxiv.org/abs/2604.04604

Corné POTGIETER Посмотреть все магазины Corné POTGIETER

Источник: towardsdatascience.com