Основатель
September 14, 2026
24 min read
Поставщик образовательных технологий не может подать декларацию YAZEK от имени учреждения. Но он может сделать возможным для учреждения правильную декларацию, фактическое применение этой декларации в продукте и проверку того, остаётся ли декларация верной при изменении продукта. Эта заключительная статья серии предлагает превратить выражение «продукт, готовый к YAZEK», из маркетингового слогана в модельную проектную спецификацию, пригодную для использования между поставщиком, продуктовой командой и образовательным учреждением.
Встретить в презентации EdTech-продукта фразу «Наш продукт соответствует YAZEK» уже не удивляет. Фраза выглядит обнадёживающе; но какой правовой итог она обозначает — неясно. Yapay Zekâ Uygulamaları Etik Beyan Sistemi (YAZEK) — Система этической декларации применения искусственного интеллекта Министерства национального образования (Millî Eğitim Bakanlığı, MEB) — не является механизмом выдачи сертификатов соответствия продуктам или предварительного одобрения инструментов. Согласно актуальному разъяснению министерства, «списка безопасных инструментов искусственного интеллекта» также не существует. Предмет декларации — не коммерческое название платформы; это характер и охват конкретного применения искусственного интеллекта, которое учитель будет осуществлять с этой платформой.[1]
Это различие не выводит поставщика за пределы дискуссии о YAZEK. Напротив, оно точнее определяет его роль. Если учреждение не знает, какие данные обрабатывает продукт, что он производит, с какой моделью или сторонним компонентом работает, что может изменить учитель и как новая версия влияет на прежнее использование, оно не может гарантировать точность ответов в этической декларации. Если интерфейс продукта облегчает поведение, противоречащее институциональной политике, не позволяет отключить важные функции или не создаёт записи, необходимые в момент инцидента, даже лучшая политика не находит отражения на экране.
Поэтому законное и сильное обещание, которое поставщик может дать, — не «мы гарантируем правовое соответствие». Более точное обещание таково:
Наш продукт предоставляет продуктовые возможности, необходимые образовательному учреждению для правильного определения конкретного использования, ограничения его по собственным правилам, эксплуатации под человеческим надзором, доказательства итогов и повторной оценки при изменении.
То, что в этой статье называется готовностью к YAZEK, — это качество. Это выражение — не официальный статус или сертификат MEB. Это модель проектирования и обеспечения, предлагаемая для перевода принципов YAZEK в жизненный цикл продукта.
Предыдущие статьи серии рассматривали разные пробелы: связь декларации YAZEK с живой институциональной системой соответствия; оценку воздействия до использования; гарантию открытого будущего против профилей, запирающих ученика в прошлых данных; превращение договора закупки искусственного интеллекта в инструмент видимости и вмешательства; установление обоснованного человеческого принятия на себя и эффективного обжалования при оценивании. На финальном этапе задача — не снова объяснять эти вопросы, а вывести из них продуктовые требования.
Каждый правовой результат, построенный в серии, ставит продукту вопрос последствия и даёт соответствие. Когда за основу берётся конкретный сценарий использования, продукт должен различать, какой модуль для какой цели и целевой группы используется; соответствие — идентичность сценария и отдельный профиль конфигурации. Когда оценка воздействия определяет границы использования и пороги остановки, решение учреждения должно быть реализуемо в продукте; соответствие — политические органы управления, функциональные ворота и полномочие остановки. Когда будущее ученика не должно закрываться одним выводом, срок жизни, вторичное использование и эффект вывода должны быть ограничиваемы; соответствие — разделение целей, истечение срока, повторная оценка и неалгоритмический путь. Когда договор обеспечивает права на изменение, аудит и выход, эти права должны быть технически применимы; соответствие — уведомление о версии, экспорт доказательств, откат и переносимость. Когда человеческий надзор требует обоснования, полномочия и обжалования, человек должен действительно принимать решение на продукте; соответствие — поверхность рассмотрения, оригинальное человеческое действие, исправление и поддержка второго взгляда.
Это соответствие — не простой «список правовых требований». Когда дорожная карта продукта, институциональная политика и договор закупки не привязаны к одному сценарию использования, возникают три отдельные реальности: учреждение декларирует одно, договор обещает другое, а программное обеспечение разрешает третье. Подлинная цель готовности к YAZEK — превратить эти три реальности в одну систему.
Один и тот же продукт не имеет одинакового уровня готовности, когда учитель использует его для подготовки материалов в закрытой среде, когда он применяется как учебный ассистент, говорящий напрямую с учеником, и когда оценивает работу ученика. Более того, один модуль может работать в двух учреждениях с разными полями данных, полномочиями, сроками хранения и правилами человеческого надзора. Продукт, дающий достаточные доказательства в сегодняшней версии модели, завтра может ослабить прежнюю гарантию молча добавленной новой функцией.
Готовность — поэтому качество этого отношения:
Готовность к YAZEK = продуктовая возможность × конкретный сценарий использования × институциональная конфигурация × актуальная версия × непрерывность доказательств
Если одного множителя нет, общая метка «соответствует», прикреплённая к названию продукта, не может закрыть оставшийся пробел. Продукт с безопасными значениями по умолчанию может использоваться не по назначению; институциональное решение, принятое для правильной цели, может утратить силу в новой версии; хорошо настроенная система может быть неподдающейся аудиту после инцидента, потому что не производит доказательств.
На этом этапе может быть предложено понятие пригодности для декларации. Продукт, пригодный для декларации, — не тот, что автоматически заполняет форму YAZEK. Это продукт, который ясно показывает факты, которые учреждение будет декларировать, устанавливает техническое соответствие данного в продукте ответа и делает видимым, нарушено ли это соответствие в течение жизненного цикла. Четыре способности должны существовать вместе:
Обеспечение правильной декларации: предоставление надёжной информации о цели, целевой группе, данных, функции модели, эффекте решения и ограничениях.
Исполнение декларации: реализация границ использования, которые устанавливает учреждение, через настройки, роль, разрешение, функциональные ворота и безопасные значения по умолчанию.
Доказательство декларации: показ пропорциональными записями, какая конфигурация, модель и человеческое действие были действительны в какой момент.
Поддержание декларации в актуальном состоянии: информирование учреждения при изменении продукта или использования о необходимости пересмотра прежней оценки и при необходимости безопасная заморозка использования.
Без первой способности декларация становится догадкой; без второй — декларацией намерений; без третьей — утверждением, которое нельзя доказать; без четвёртой — фотографией, быстро устаревающей.
Институциональные политики искусственного интеллекта часто используют правильные глаголы: ограничивается, контролируется, записывается, при необходимости останавливается. Задача продуктового проектирования — спросить, какое соответствие этим глаголам на экране и в архитектуре системы. Если написано, что данные ученика будут использоваться только для определённой цели, какое техническое разделение предотвратит использование не по назначению? Если указано, что окончательное решение за учителем, может ли учитель принять одним щелчком, не видя, не изменяя и не формируя собственное обоснование рекомендации? Если определённая функция запрещена, может ли администратор учреждения отключить её для всех пользователей?
Здесь необходим принцип, который можно назвать симметрией контроль–доказательство:
Каждое важное правило политики должно быть связано с реализуемым в продукте контролем; каждый важный контроль — с пропорциональным и доступным доказательством того, что он работает.
Если функцию нельзя отключить, институциональный запрет хрупок. Если настройка не записывается с информацией о версии и времени, её нельзя проверить позже. Если предупреждение создаётся без определения, кто его получает, это не вмешательство. Если запись нельзя экспортировать в понятной форме ни одной уполномоченной стороной, она становится кучей данных, а не подотчётностью.
Этот подход не означает «чем больше журналов, тем больше соответствия». Особенно детальная запись поведения детей может создать новый риск наблюдения. Проектирование должно учитывать различие между доказательством, необходимым для аудита события и решения, и ненужным поведенческим отслеживанием ученика. Архитектура доказательств также должна подчиняться минимизации данных, ролевому доступу, ограничениям хранения и безопасному удалению.
Высокоэффективную функцию искусственного интеллекта в образовании нельзя поручить одной гарантии. Предупреждение «выход должен проверяться учителем» недостаточно, если интерфейс подталкивает учителя к автоматическому принятию. Контент-фильтр не решает, кто будет уведомлён и как вмешаться при вредоносном выходе. Положение об уведомлении в договоре не защищает учреждение задним числом, если продукт уже перешёл на новую модель.
Проектирование, готовое к YAZEK, поэтому должно строить шесть слоёв вместе.
1. Определить: цель, целевая группа, данные, роль искусственного интеллекта и запрещённые использования определяются на уровне сценария. При сбое слоя функциональные ворота и предупреждение администратора перекрывают неопределённое или внеохватное использование. 2. Ограничить: применяются безопасное значение по умолчанию, роль/разрешение, область данных и ограничение функции. Противоречащие попытки делаются видимыми записью инцидента и уведомлением ответственного лица. 3. Наблюдать: полномочие уполномоченного человека на предпросмотр, изменение, отклонение и остановку делается реальным. Необычные паттерны принятия, кластеры ошибок и обжалования передаются на процессное рассмотрение.
4. Доказать: версия, конфигурация, выход и оригинальное человеческое действие записываются пропорционально цели. При отсутствии доказательств эффект решения ограничивается или высокоэффективная функция не запускается. 5. Исправить: ошибка, обжалование и исходы инцидента распространяются на связанные записи и производные выходы. При массовой ошибке становятся возможны приостановка и откат использования. 6. Обновить или выйти: изменение классифицируется, повторно тестируется, учреждение информируется; обеспечиваются непрерывность и выход данных. Если обеспечение нельзя поддержать, выполняется возврат к прежней версии, отключение функции или безопасный выход от поставщика.
Эта архитектура не обещает сделать ошибку невозможной. Она ставит более реалистичную и правово более ценную цель: затруднить прохождение ошибки через один контроль незамеченной к ученику как итогу; а когда она достигает — обеспечить способность к обнаружению, исправлению и обучению.
Приведённая ниже спецификация — не технический стандарт, опубликованный MEB. Это модель, разработанная для перевода ожиданий YAZEK, Руководства по этике применения искусственного интеллекта в образовании и рекомендаций MEB для разработчиков/поставщиков услуг в жизненный цикл продукта.[2] Поставщики могут использовать её в документе продуктовых требований и воротах релиза; образовательные учреждения — в предквалификации, пилоте и приёмочном тесте; политики — как отправную точку для будущей общей схемы обеспечения.
Единицей оценки спецификации является не компания или платформа целиком, а сочетание продукт + модуль + версия + сценарий использования + институциональная конфигурация. По каждому требованию ищется больше, чем ответ «да/нет»: владелец контроля, охват, метод теста, производимое доказательство, известное ограничение и дата пересмотра.
YH-01 — Идентичность сценария чётко определяет для каждой функции искусственного интеллекта предполагаемое использование, целевой возраст/группу, педагогическую функцию, категории данных, выход и эффект решения; указывает неподдерживаемые использования. Вопрос приёмки — может ли учреждение в одной записи показать, что декларирует независимо от названия продукта; производимое доказательство — привязанная к версии карта продукта/системы и паспорт сценария. YH-02 — Институциональное управление политикой позволяет учреждению устанавливать правила использования по модулю, роли пользователя, классу/подразделению, области данных, режиму производства и эффекту решения; рискованные функции могут быть по умолчанию выключены. Вопрос приёмки — переходит ли институциональное решение от рекомендации пользователю к поведению системы; доказательство — сводка конфигурации, матрица полномочий и история изменений. YH-03 — Граница данных и компонентов требует закрытия ненужных полей данных, разделения образовательных данных от вторичных использований вроде обучения модели/разработки продукта и видимости зависимостей от субпоставщика и модели. Вопрос приёмки — может ли учреждение проверить, какие данные к какому компоненту и с какой целью идут; доказательство — сводка потока данных, реестр компонентов и проверка хранения/удаления.
YH-04 — Безопасное значение по умолчанию для детей и педагогики встраивает в поведение продукта по умолчанию безопасность контента, доступность, когнитивную нагрузку и ограничения взаимодействия, пропорциональные возрасту и функции; связывает педагогическую пользу с проверяемой целью. Вопрос приёмки — блокирует ли продукт только вредный контент или также защищает качество учебных отношений; доказательство — тестовый отчёт по возрасту/группе, результат доступности и запись педагогической валидации. YH-05 — Поверхность человеческого контроля позволяет уполномоченному лицу видеть ввод и выход искусственного интеллекта, понимать неопределённость, изменять, отклонять, добавлять объяснение и останавливать систему; интерфейс не направляет к автоматическому принятию. Вопрос приёмки — принимает ли человек решение по существу или является лишь финальным щелчком, утверждающим результат модели; доказательство — след человеческого действия, тест отмены и проверка полномочий. YH-06 — Носитель уведомления, объяснения и исправления показывает роль искусственного интеллекта пользователю в соответствующей возрасту форме; производит понятную информацию, связанную с итогом; обеспечивает переход к каналу обращения/обжалования учреждения и распространение исправления на связанные выходы. Вопрос приёмки — понимает ли ученик или родитель не только «использовался искусственный интеллект», но и как это затронуло его собственный итог; доказательство — образцы уведомлений, сводка контекста решения и запись распространения исправления.
YH-07 — Пропорциональная наблюдаемость записывает модель/версию, активную конфигурацию, критическое событие, выход искусственного интеллекта и человеческое вмешательство пропорционально риску; учреждение может экспортировать это в понятном формате. Вопрос приёмки — возможно ли рассмотрение без смешения системы в момент события с сегодняшней системой; доказательство — пакет доказательств с временной меткой, экспорт для аудита и журналы доступа. YH-08 — Управление эффектом изменений классифицирует изменение модели, потока данных, функции, интерфейса или субпоставщика по влиянию на сценарий использования; рискованное изменение не активируется до завершения требуемого теста и уведомления учреждения. Вопрос приёмки — нарушает ли новая версия молча допущения старой оценки; доказательство — уведомление об эффекте изменения, сравнительный тест и решение учреждения. YH-09 — Инцидент, откат и выход позволяет учреждению приостановить использование, выявить и исправить ошибочные массовые выходы, вернуться к прежней безопасной версии/рабочему процессу и экспортировать данные/доказательства в пригодном формате. Вопрос приёмки — защищены ли образовательная деятельность и права ученика без привязки к поставщику, когда продукт не работает безопасно; доказательство — файл инцидента, тест отката, непрерывность и пакет выхода.
Не все девять требований применяются с одинаковой интенсивностью в каждом использовании. В инструменте учителя без прямого контакта с учеником, без обработки персональных данных и без влияния на решения слои записи и утверждения могут быть легче. Напротив, в функции, затрагивающей оценку, уровень, зачисление, дисциплину, консультирование или профиль ученика, базовые контроли нельзя убрать со ссылкой на то, что «продуктовый опыт усложняется». Пропорциональность — не устранение защиты, а настройка интенсивности контроля в зависимости от цены ошибки использования.
Частая ошибка проектирования EdTech-поставщиков — представлять продукт так, будто у него одна цель использования. Между тем генеративный контент, учебный ассистент, аналитика обучения и функции оценивания могут объединяться в одном интерфейсе. Цель столь широкая, как «искусственный интеллект для образования», не несёт ни декларации, ни теста, ни распределения ответственности.
Каждый модуль поэтому должен нести идентичность сценария: цель, целевой возраст и группу потребностей, учебную/обучающую функцию, входы, выходы, место выхода в человеческом решении, поддерживаемые и запрещённые использования. Учреждение должно иметь возможность связать эту идентичность со своим применением и создать профиль конфигурации. Так решение учреждения «этот инструмент только создаёт черновик обратной связи; не предлагает оценки» становится техническим состоянием, в котором функция предложения оценки выключена, а не фразой, оставленной в руководстве пользователя.
Эта плоскость управления также даёт поставщику стратегическое преимущество. Вместо разветвления кода для каждого клиента на одном продукте предлагаются проверяемые профили риска. Ограничения, написанные юридической командой, становятся критериями приёмки для продуктового менеджера; институциональная политика — настройкой администратора.
Классическая логика роста программного обеспечения может считать показателями успеха больше взаимодействия, более длительное использование и более богатый сбор данных. В образовательном продукте для детей эти показатели сами по себе не являются ценностью. Проектирование, увеличивающее экранное время, эмоциональную привязанность или степень, в которой ученик использует систему вместо собственного мышления, может повысить коммерческую вовлечённость, ослабляя образовательную цель.
Рекомендации MEB для разработчиков, производителей и поставщиков услуг объединяют минимизацию данных и конфиденциальность при проектировании с проектированием, соответствующим когнитивному, эмоциональному и социальному развитию детей, функциями экранного времени и перерывов, фильтрацией и модерацией контента, педагогическими/этическими тестами и доступностью в одной области ответственности.[3] Эта связность важна: безопасность детей — не только модерация контента; защита данных — не только текст о конфиденциальности. То, что продукт поощряет, какое поведение облегчает и какие данные вообще не собирает — решение проектирования.
В качестве сравнительного примера стандарты безопасности продуктов генеративного искусственного интеллекта Министерства образования Великобритании, обновлённые в январе 2026 года, требуют от поставщиков чётко указывать цель и целевую группу; подкреплять утверждения доказательствами; приоритизировать безопасность детей и прозрачность в проектировании; тестировать новые модели и версии до выпуска. Стандарты также рекомендуют прямые педагогические проектные решения: предлагать постепенные подсказки вместо прямой выдачи ученику полного решения, искать подлинное усилие ученика, создавать трение или одобрение учителя перед переходом к полному решению.[4] Это не обязательные правила по турецкому праву; но полезный политический пример, показывающий, что «безопасный EdTech-продукт» — не только кибербезопасность.
Когда человеческий надзор оставлен в организационной схеме, а право обжалования — в контактной форме, продукт может их не поддерживать. Экран, где уполномоченное лицо может изменить рекомендацию модели, но не видит фактическую работу ученика, не обеспечивает подлинного рассмотрения. Если кнопка «Отклонить» есть, но сотни выходов по умолчанию принимаются сразу из-за нагрузки, формальный контроль прикрывает де-факто определяющую роль.
Продукт, готовый к YAZEK, проектирует интерфейс в соответствии с важностью решения. При высокоэффективном использовании он может ограничить массовое автоматическое принятие; разделить рекомендацию искусственного интеллекта и добавленное человеком обоснование; направить решение на обязательное рассмотрение при неопределённости или недостатке данных. Объяснение, представленное ученику и родителю, должно давать понятный контекст об использованных в конкретном итоге входах, критериях, роли искусственного интеллекта и пути исправления — а не повторять исходный код модели или общую брошюру продукта.
Здесь продукт не заменяет орган обжалования. Кто в какой срок рассматривает обращение — правовое и административное устройство учреждения. Задача продукта — не блокировать учреждению эффективную работу этого пути; сохранить соответствующий момент решения, экспортировать необходимый файл, распространить исправление на производные итоги и не представлять первый автоматический ответ как «второе рассмотрение».
Отчёт о безопасности, который поставщик отправляет учреждению в начале года, сам по себе не показывает, какая модель и настройки использовались в конкретном классе три месяца спустя. Продукт поэтому должен иметь возможность производить пакет доказательств соответствия для каждого утверждённого профиля использования. Пакет — не новый пул наблюдения, открывающий все данные учеников поставщику; это структурированный экспорт пропорциональных записей, достаточных для проверки конкретных утверждений.
Минимальный пакет может состоять из:
идентичности продукта, модуля, модели/подмодели и версии;
сводки с временной меткой активного сценария использования и институциональной конфигурации;
действительных ролей и разрешений и состояния открыто/закрыто высокоэффективных функций;
охвата, даты, результата, известных ограничений и срока действия соответствующих тестов;
пропорциональной записи критического события, предупреждения и человеческого вмешательства;
эффекта недавних изменений на сценарий и ожидающих действий учреждения;
при необходимости ссылок, обеспечивающих связь с файлом решения, обжалования и исправления.
Этот пакет — не новая политика или приложение к договору; это выход времени выполнения, показывающий, что они работают. Разделение на три уровня доступа — публичная карта продукта, сводка конфигурации для конкретного клиента и подробный файл инцидента, открытый только уполномоченному аудитору — может обеспечить лучший баланс между коммерческой тайной и прозрачностью и конфиденциальностью ученика.
В продуктах искусственного интеллекта классический «номер версии» сам по себе недостаточен. Поставщик может изменить базовую модель, системную инструкцию, контент-фильтр, поведение хранения данных или субпоставщика без изменения интерфейса. Продукт может выглядеть для пользователя тем же, пока изменились паттерн ошибок, поток данных или влияние на решение.
Напротив, привязывать каждое исправление ошибки к новой декларации YAZEK тоже неверно. Актуальное разъяснение YAZEK указывает, что если новый модуль или функция не меняют охват, учебную цель или целевую аудиторию существующего применения, повторная декларация не требуется. Также разъясняется, что если для того же применения не меняются охват, образовательная цель, используемый инструмент искусственного интеллекта или целевая аудитория, повторная декларация не ищется.[5]
Задача поставщика — не объявлять правовое последствие от имени учреждения, а делать видимыми факты изменения, значимые для решения. Для этого можно использовать четырёхуровневую классификацию изменений.
D0 — Техническое обслуживание — исправление или патч, не влияющий на допущения сценария; достаточны запись на стороне продукта и рутинный тест, на стороне учреждения — информационная запись версии. D1 — Эффект на обеспечение — изменение, влияющее на фильтр, точность, доступность или человеческий контроль; требуются целевой регрессионный тест и обновление пакета доказательств; ожидается уведомление владельца риска и при необходимости приёмочный тест. D2 — Эффект на использование — существенное изменение потока данных, модели, типа выхода, веса решения или поддерживаемой группы пользователей; требуются анализ воздействия до активации, функциональные ворота и явное решение учреждения; EYZED/политика/договор и необходимость обновления YAZEK оцениваются учреждением. D3 — Превышение границы — открытие запрещённого использования, потеря обеспечения или неприемлемый высокий риск; требуется блокировка по умолчанию, заморозка версии или откат; учреждение переходит к пути незапуска/остановки использования и повторного решения.
В этой модели учреждение не засыпается уведомлениями; изменение тоже не заглушается. Время, содержание и требуемое действие уведомления привязаны к реальному эффекту изменения. «Существенное изменение» таким образом перестаёт быть только двусмысленным выражением в договоре и становится вопросом классификации, на который продуктовая команда должна ответить до выпуска.
Способность учреждения остановить продукт, прекратить отношения с поставщиком или вернуться к рабочему процессу без искусственного интеллекта — не исключительный кризисный сценарий, а инфраструктура человеческого надзора. «Утверждение» без полномочия отката на практике — зависимость от дорожной карты поставщика. Учреждение, которое при окончании использования не может получить записи решений в понятном формате или проверить удаление данных учеников и производных профилей, не может отчитаться за прошлые операции.
Выход поэтому должен охватывать образовательную непрерывность не меньше, чем переносимость данных. Когда продукт закрывается, как продолжится экзамен, обратная связь или процесс поддержки? Какая запись остаётся у учреждения, какой производный выход аннулируется, какой ключ интеграции отзывается, как будет доказано удаление? Эти вопросы должны решаться в первом архитектурном решении, а не после выхода продукта на рынок.
Проставление галочек в контрольном списке само по себе не показывает, что реальное использование безопасно. Более сильный метод — подход файла обеспечения. Для каждого профиля продукт–сценарий поставщик строит эту цепь:
Утверждение → допущение, на котором оно основано → применённый контроль → тестовое/операционное доказательство → известное ограничение → ответственное лицо → срок действия
Например, основа утверждения «учитель принимает окончательное решение» не может быть только фразой в условиях использования. К утверждению должны быть привязаны доказательства того, что учитель может отдельно видеть фактическую работу и рекомендацию модели, изменить итог, массовое автоматическое принятие ограничено, неуполномоченная роль не может окончательно утвердить решение, и эти поведения проверены в приёмочном тесте. Если известное ограничение — запись человеческого действия не передаётся во внешнюю систему в конкретной интеграции, это должно быть ясно написано, а профиль использования сужен до устранения.
Этот метод также дисциплинирует маркетинговый язык. Подход стандартов безопасности продуктов Великобритании к привязке утверждений об эффекте и возможностях продукта к прочным и прозрачным доказательствам поучителен здесь.[6] Для YAZEK также следует сохранить следующее языковое различие.
«Продукт искусственного интеллекта, одобренный MEB» может использоваться только при наличии действительно данного официального одобрения с определённым охватом и возможности использования в полном охвате. Вместо «сертифицирован/соответствует YAZEK» можно сказать, что указанные сценарии использования предлагают продуктовые возможности, поддерживающие процесс оценки и мониторинга YAZEK учреждения. Вместо «гарантирует соответствие KVKK» следует указать, что в указанном потоке данных и конфигурации поддерживаются меры защиты данных учреждения; роли сторон и правовые основания определяются отдельно. Фразу «человек всегда контролирует» следует заменить объяснением, в какой роли, в какой момент, с какой информацией и полномочием изменения/остановки существует человеческий контроль. Вместо утверждения «полностью безопасен и беспристрастен» следует публиковать охват теста, сравнительные группы, пределы ошибок, известный риск и дату повторного теста.
Рекомендация MEB поставщикам об этических сертификатах соответствия и открытости к независимому аудиту не противоречит этому различию.[3] Независимый аудит или сертификат могут быть ценным доказательством; но их нельзя представлять как одобрение продукта, выданное YAZEK, без указания охвата, стандарта, даты и проверенной версии.
Готовность к YAZEK также может отслеживаться по уровню зрелости, а не по единой оценке «сдал/не сдал».
Уровень 0 — Ориентированный на обещание продукт имеет общие этические/комплаенс-заявления; сценарий использования и доказательства неясны; учреждение не может связать утверждение с конкретным использованием. Уровень 1 — Документированный продукт имеет определённую карту продукта, поток данных, тесты и ограничения; но институциональная политика не меняет поведение продукта. Уровень 2 — Настраиваемый продукт позволяет учреждению устанавливать ограничения роли, данных и функций; главный пробел — настройки и человеческие действия недостаточно доказаны как работающие. Уровень 3 — Наблюдаемый и поддающийся вмешательству продукт имеет работающие пропорциональную запись, предупреждение, исправление, остановку и экспорт; но новая версия и инциденты не обновляют обеспечение сами по себе. Уровень 4 — Управляемый жизненным циклом продукт связывает эффект изменений, регрессионный тест, повторное решение учреждения, обучение на инциденте, откат и выход в одной системе; остаточный риск открыто управляется в контексте использования.
Уровень зрелости тоже не является постановлением о соответствии. Он показывает, сколько технической поддержки продукт может дать способности учреждения к соответствию. Сценарий с низким воздействием может быть принят с более лёгкими контролями; отсутствие возможностей третьего или четвёртого уровня для высокоэффективной функции решения может быть основанием для остановки.
YAZEK сегодня в основном делает видимой линию этического управления между держателем декларации и образовательным учреждением. Следующий политический вопрос — как информация о продукте, на которой основана декларация, будет представлена в общей и сопоставимой форме. Каждое учреждение, запрашивающее у одного поставщика информацию в разных форматах, и истощает школьные ресурсы, и создаёт непредсказуемые требования для малых EdTech-компаний.
Предлагаемая здесь спецификация со временем может составить ядро общей схемы обеспечения EdTech-продуктов. Такая схема может:
не нагружая YAZEK функцией сертификации продуктов, стандартизировать минимальные поля данных поставщика, необходимые держателю декларации;
установить идентичность продукт–модуль–версия–сценарий в машиночитаемом формате для сопоставления инвентаря учреждения с записью версии поставщика;
задать разные уровни доказательств для использований с низким и высоким воздействием;
привязать уведомление об эффекте изменения к общим классам;
обеспечить сопоставимое представление независимых тестов, результатов пилота и известных ограничений;
позволить контролируемое повторное использование однажды произведённых доказательств вместо принуждения малых поставщиков заполнять сотни разных форм.
Сравнительное регулирование также показывает, что направление — к жизненному циклу продукта. Профиль генеративного искусственного интеллекта NIST рекомендует, что риски могут различаться на уровне модели, приложения, конкретного использования и экосистемы; и что управление, происхождение контента, тест до внедрения и уведомление об инцидентах должны рассматриваться вместе в течение жизненного цикла.[7] Регламент Европейского союза об искусственном интеллекте предусматривает для поставщиков систем высокого риска в своём охвате управление качеством, техническую документацию, автоматические журналы, оценку соответствия и корректирующие действия; некоторые использования в доступе к образовательным учреждениям, оценке результатов обучения, уровневом размещении и мониторинге поведения на экзаменах относит к областям высокого риска.[8] Эти регламенты нельзя переносить, предполагая, что они создают прямые обязанности для каждого EdTech-продукта в Турции. Но они показывают регуляторное направление от «декларирования этических принципов» к «производству доказательств в течение жизненного цикла продукта».
Важнейшая польза общей схемы — дать юридическим и продуктовым командам работать над одним объектом. Юрист определяет абстрактный принцип и неприемлемый итог; педагог ограничивает образовательную пользу и эффект развития; команды безопасности/данных строят технические контроли; продуктовый менеджер превращает это в требования и ворота релиза; учреждение принимает конфигурацию конкретного использования и остаточный риск. Дисциплины вносят вклад в один файл обеспечения, не переходя в чужую область.
Проектирование, готовое к YAZEK, не передаёт ответственность образовательного учреждения поставщику. Учреждение определяет педагогическую цель, правовое основание, целевую группу, полномочия учителя и окончательное решение об использовании. Точность декларации YAZEK также — ответственность держателя декларации и институционального управления.
Но верно и обратное: окончательная ответственность учреждения не позволяет поставщику выносить информационную асимметрию внутри продукта как «настройку клиента». Выбор модели и субпоставщика, поведение данных по умолчанию, охват теста, интерфейс, создающий предвзятость автоматизации, время изменения и техническая способность отката — в зоне контроля поставщика.
Правильная линия устанавливает эти два предложения вместе:
Поставщик не может принять решение о соответствии от имени учреждения. Учреждение также не может осмысленно управлять риском, который поставщик не раскрыл или не сделал технически контролируемым.
Поэтому место правовой/комплаенс-проверки в разработке продукта — не день написания пользовательского соглашения. Ограничение использования при формировании гипотезы продукта; разделение целей при проектировании архитектуры данных; подлинные полномочия человека при проектировании интерфейса; эффект изменения при выпуске версии; будущее записей ученика и учреждения при прекращении продукта — всё должно решаться вместе.
YAZEK создал важный порог для управления искусственным интеллектом в образовании: до названия используемого инструмента спрашиваются цель, охват, целевая группа и влияние на ученика конкретного применения. Этот порог теперь должен быть завершён на стороне поставщика. Потому что этическая декларация учреждения не может быть точнее информационной и контрольной способности продукта.
EdTech-продукт, готовый к YAZEK, — не тот, что помогает заполнять поля формы, а тот, что производит внутри продукта соответствие ответу, данному в форме. Он может отключить то, что учреждение запрещает, запустить то, что разрешает, в пределах ограничений; обеспечить подлинное вмешательство человека; сохранить момент инцидента в пропорциональной форме; исправить ошибку через производные итоги; своевременно сделать видимым, когда новая версия затрагивает старую декларацию. Если обеспечение нельзя поддержать, он может остановиться, вернуться и позволить учреждению выйти.
В конце серии итогом должен быть не список документов, а единый принцип управления:
Соответствие — не файл, носимый рядом с продуктом; это архитектура того, что продукт разрешает, блокирует, записывает, исправляет и при необходимости отказывается делать.
Для EdTech-поставщиков следующий стратегический шаг — не подготовить общее заявление «мы соответствуем YAZEK», а провести анализ пробелов готовности к YAZEK для каждого профиля продукт–сценарий, привязать требования YH-01–YH-09 к дорожной карте продукта и собрать доказательства в файле обеспечения, живущем вместе с версией. Для образовательных учреждений вопрос должен сместиться с «Есть ли в этом продукте искусственный интеллект?» на «Делает ли этот продукт нашу декларацию технически правильной, поддающейся аудиту и обратимой?»
Ясный и доказанный ответ на этот вопрос не только облегчает процесс YAZEK. Он сводит в одной архитектуре продуктовую дисциплину поставщика, качество закупок учреждения и правовые гарантии ученика в цифровом образовании.
Источники и онлайн-разъяснения рассмотрены по состоянию на 10 сентября 2026 г. «Спецификация продукта готовности к YAZEK» — неофициальное модельное предложение, разработанное в этой статье. Работа содержит общую правовую и институциональную оценку; для конкретного продукта или использования статус учреждения, поток данных, цепочка договоров, целевая группа, техническая архитектура и действующее законодательство должны рассматриваться отдельно.
