Рэгламент Еўрапейскага саюза аб штучным інтэлекце дасягае агульнай даты прымянення 2 жніўня 2026 года. Для распрацоўшчыка гэта не азначае, што трэба дадаць аднолькавы значок «створана AI» на кожны экран. Трэба апісаць кожную AI-сістэму, вызначыць provider і deployer, паказаць паведамленне Article 50 у шляху карыстальніка, захаваць сігналы прасочвальнасці і даць упаўнаважанаму чалавеку рэальны спосаб умяшацца. У артыкуле інжынерная праца супастаўляецца з кансалідаваным тэкстам Regulation (EU) 2024/1689 на EUR-Lex і кіраўніцтвам Камісіі па Article 50, праверанымі 28 жніўня 2026 года.
Гэта тэхнічнае кіраўніцтва, а не юрыдычная кансультацыя. AI Act змяшчае правілы, якія залежаць ад ролі, прызначэння, спосабу выкарыстання і галіны. Каманда павінна асобна праверыць факты, дастасавальнае нацыянальнае права, абавязкі па абароне даных і кампетэнтны орган. Далей прыведзены інжынерныя шаблоны, а не юрыдычная класіфікацыя вашага прадукту.
Даты, якія змяняюць план распрацоўкі
Абавязкі па празрыстасці Article 50 прымяняюцца з 2 жніўня 2026 года. Для provider генератыўнай AI-сістэмы, размешчанай на рынку да гэтай даты, існуе абмежаваны пераходны перыяд для абавязку Article 50(2) маркіраваць кантэнт і забяспечваць яго выяўленне, да 2 снежня 2026 года. Камісія адзначае, што кантэнт, створаны і ўжо даступны да 2 жніўня, не трэба маркіраваць заднім чыслом. Гэты пераход не скасоўвае астатнія абавязкі Article 50, якія з 2 жніўня дзейнічаюць для ахопленай сістэмы. Лічыце гэтыя даты двума рознымі варотамі рэлізу.
Іншыя даты лёгка пераблытаць. Забароны, азначэнні і палажэнні пра AI-дасведчанасць дзейнічаюць з 2 лютага 2025 года. Правілы кіравання і абавязкі для мадэляў агульнага прызначэння дзейнічаюць з 2 жніўня 2025 года. Паводле змененага Article 113, патрабаванні да высокарызыкоўных сістэм у Chapter III, Sections 1–3 прымяняюцца да сістэм Annex III паводле Article 6(2) з 2 снежня 2027 года, а да звязаных з прадуктамі сістэм паводле Article 6(1) і Annex I з 2 жніўня 2028 года. Provider і deployer высокарызыкоўных сістэм для дзяржаўных органаў павінны зрабіць неабходныя крокі да 2 жніўня 2030 года. Гэта не прычына адкладаць кантроль, але Article 12 не з’яўляецца агульным абавязкам весці журналы для кожнага чатбота ў жніўні 2026 года.
Правярайце каляндар у актуальным аглядзе AI Act ад Камісіі. Перад рэлізам зноў звяртайцеся да кансалідаванага тэксту EUR-Lex, бо наступныя акты або нацыянальныя меры могуць змяніць працу для пэўнай сістэмы.
Спачатку вызначце ролю і юрысдыкцыю
Article 2 ахоплівае provider, які размяшчае AI-сістэму або мадэль агульнага прызначэння на рынку Саюза альбо ўводзіць яе ў эксплуатацыю ў Саюзе, незалежна ад месца заснавання ў Саюзе ці трэцяй краіне. Ён ахоплівае deployer, заснаванага або размешчанага ў Саюзе, а таксама provider або deployer з трэцяй краіны, калі вынік сістэмы выкарыстоўваецца ў Саюзе. У сферу таксама ўваходзяць імпартэры, дыстрыб’ютары, вытворцы прадуктаў і ўпаўнаважаныя прадстаўнікі. Article 2 выключае сферы па-за правам Саюза і сістэмы, якія выкарыстоўваюцца выключна ў ваенных, абаронных мэтах або для нацыянальнай бяспекі.
Паводле Article 3 provider — гэта арганізацыя, якая распрацоўвае або замаўляе распрацоўку AI-сістэмы і размяшчае яе на рынку ці ўводзіць у эксплуатацыю пад сваім імем або таварнай маркай. Deployer выкарыстоўвае AI-сістэму пад сваім кантролем, акрамя асабістага непрафесійнага выкарыстання. Воблачны пастаўшчык можа быць provider мадэлі, а ваша кампанія — deployer агента, які яе выклікае. Калі кампанія ставіць сваё імя, істотна змяняе высокарызыкоўную сістэму або змяняе прызначэнне так, што невысокарызыкоўная сістэма становіцца высокарызыкоўнай, Article 25 можа зрабіць кампанію provider гэтай сістэмы. Зафіксуйце гэта рашэнне ў ланцужку стварэння.
Стварыце радок рэестра для кожнай сістэмы для карыстальнікаў і кожнай шматразовай мадэлі або службы. Запішыце provider, deployer, прызначэнне, рынкі, мадальнасці, непасрэднае ўзаемадзеянне з чалавекам, ацэнку рызыкі, версіі, інтэграцыі і таго, хто зацвердзіў запіс. Кароткая схема патоку даных карыснейшая за ярлык прадукту:
чалавек -> інтэрфейс -> паведамленне AI -> адаптар мадэлі -> палітыка вываду
-> метка паходжання -> ярлык або праверка -> публікацыя
-> сховішча падзей -> маніторынг і рэагаванне
Article 50 мае чатыры розныя інжынерныя паверхні
FAQ Камісіі пра Article 50 тлумачыць сферу і прыклады. Рэалізуйце гэтыя абавязкі асобна.
| Паверхня AI Act | Адказная роля | Мінімальнае наступства для прадукту |
|---|---|---|
| Непасрэднае ўзаемадзеянне | Provider | Паведаміць чалавеку, што ён узаемадзейнічае з AI, калі гэта не відавочна з кантэксту. |
| Сінтэтычны гук, выява, відэа або тэкст | Provider | Дадаць машыначытальную метку, якая дазваляе выявіць штучнае стварэнне або змяненне. |
| Уздзеянне распазнавання эмоцый або біяметрычнай катэгарызацыі | Deployer | Паведаміць асобам, на якіх уздзейнічае аперацыя, і апрацоўваць даныя паводле дастасавальных правілаў Саюза. |
| Deepfake або згенераваны тэкст пра грамадска важнае пытанне | Deployer | Даць яснае адрознае раскрыццё пры першым уздзеянні з улікам выключэнняў Article 50(4). |
Раскрыццё ў чатботе і агенте
Кіраўніцтва Камісіі апісвае чатыры сукупныя ўмовы абавязку Article 50(1): сістэма з’яўляецца AI-сістэмай, прызначана для сапраўднага двухбаковага абмену, AI размаўляе непасрэдна, а не праз чалавека-пасярэдніка, а другім бокам з’яўляецца фізічная асоба. Фонавая служба, якая размаўляе толькі з іншай службай, адрозніваецца ад агента падтрымкі, які перадае кліенту струменевы тэкст. Выключэнне «відавочна» трэба тлумачыць вузка, бо яно забірае ў чалавека інфармацыю.
Паказвайце паведамленне да першага токена мадэлі. Яно павінна быць бачным у транскрыпце, даступным для дапаможных тэхналогій і захоўвацца падчас выкліку інструмента або перадачы дыялогу чалавеку. Фраза «Вы ўзаемадзейнічаеце з AI-асістэнтам» яснейшая за назву брэнда або аватар, падобны да чалавека. Захоўвайце версію паведамлення і вынік адлюстравання ў аўдытарскай падзеі. У галасавым інтэрфейсе паведамляйце пра AI да пачатку абмену. Наступная праверка чалавекам не скасоўвае першапачатковы абавязак.
Сінтэтычны кантэнт і паходжанне
Article 50(2) ускладае абавязак маркіроўкі на provider, у тым ліку на provider сістэмы агульнага прызначэння, якая стварае сінтэтычны гук, выяву, відэа або тэкст. Метка павінна быць машыначытальнай і дазваляць выявіць штучнае стварэнне або змяненне. Тэхнічнае рашэнне павінна быць эфектыўным, сумяшчальным, устойлівым і надзейным настолькі, наколькі гэта тэхнічна магчыма, з улікам тыпу кантэнту, кошту і сучаснага ўзроўню тэхнікі. Бачны бейдж сам па сабе не з’яўляецца машыначытальнай меткай, а машыначытальная метка не замяняе бачнае раскрыццё deployer пра deepfake.
Выключэнні ахопліваюць дапаможную функцыю стандартнага рэдагавання, вынік без істотнай змены ўводу deployer або яго сэнсу і сістэмы, дазволеныя законам для выяўлення, прадухілення, расследавання або пераследу злачынстваў. Кіраўніцтва разглядае больш вузкія прыклады машыннай камунікацыі і замкнёнай вытворчасці. Не ператварайце іх у агульнае выключэнне для ўнутраных інструментаў. Захавайце рашэнне пра сферу і яго ўладальніка.
Deepfake і тэкст пра грамадскі інтарэс
Deployer павінен раскрываць выяву, аўдыё або відэа, створаныя ці змененыя AI і такія, што з’яўляюцца deepfake. Камісія апісвае яго праз падабенства да рэальнага або праўдападобна рэальнага чалавека, прадмета, месца, суб’екта або падзеі і праз ілжывае ўражанне сапраўднасці. Раскрыццё павінна ўспрымацца без спецыяльнага інструмента або дадатковага дзеяння. Змясціце «створана або зменена AI» побач з медыя, у яго даступнай назве або ў гукавым паведамленні пры першым уздзеянні. Для відавочна мастацкага, сатырычнага або выдуманага твора можна паведаміць толькі пра наяўнасць створанага кантэнту, не перашкаджаючы паказу.
Асобнае правіла для тэксту дзейнічае, калі згенераваны або зменены тэкст публікуецца, каб інфармаваць грамадскасць пра пытанне грамадскага інтарэсу. Прыклады ўключаюць палітыку, дзяржаўнае кіраванне, правасуддзе, асноўныя правы, грамадскую бяспеку, здароўе, навакольнае асяроддзе, бяспеку спажыўцоў і эканамічныя, фінансавыя, навуковыя або культурныя падзеі. Выключэнне Article 50(4) патрабуе чалавечай праверкі або рэдакцыйнага кантролю і фізічнай ці юрыдычнай асобы, адказнай за публікацыю. Праверкі арфаграфіі недастаткова. Калі каманда не можа даказаць змястоўную праверку і адказнасць, пакіньце ясную метку.
Лагіруйце патрэбнае, а не ўсё
Article 12 прымяняецца да высокарызыкоўных AI-сістэм, калі пачынаюць дзейнічаць іх патрабаванні Chapter III. Сістэма павінна тэхнічна падтрымліваць аўтаматычны запіс падзей на працягу жыццёвага цыкла. Журналы павінны забяспечваць прасочвальнасць, адпаведную прызначэнню, у тым ліку выяўленне сітуацый, здольных стварыць рызыку або істотную змену, постмаркетынгавы маніторынг паводле Article 72 і маніторынг працы паводле Article 26(5). Для высокарызыковай дыстанцыйнай біяметрычнай ідэнтыфікацыі з Annex III, point 1(a), Article 12 дадае мінімальныя палі: перыяд выкарыстання, эталонную базу, увод, які даў супадзенне, і асоб, што праверылі вынік.
Article 19 патрабуе ад provider захоўваць аўтаматычна створаныя журналы пад яго кантролем на працягу тэрміну, адпаведнага прызначэнню, але не менш за шэсць месяцаў, калі права Саюза або нацыянальнае права, асабліва заканадаўства пра даныя, не ўстанаўлівае іншае. Article 26(6) устанаўлівае такі самы мінімум для журналаў пад кантролем deployer. Гэта не дазваляе захоўваць сырыя размовы бясконца. Вызначце клас захоўвання, абмяжуйце доступ, шыфруйце сховішча падзей і аддзяліце аперацыйную тэлеметрыю ад кантэнту. Хэшыруйце або рэдагуйце ўводы і вывады, калі сырыя даныя не патрэбныя. Палі, што могуць ідэнтыфікаваць чалавека, павінен зацвердзіць адказны за даныя.
Абгортка падзеі можа выглядаць так:
{
"trace_id": "tr_7f3c",
"system_version": "agent-2026.08.28",
"model_id": "model-release",
"actor_role": "deployer",
"content_class": "text",
"mark_applied": true,
"label_shown": true,
"human_review": "not_required",
"override": false,
"created_at": "2026-08-28T12:00:00Z"
}
Гэта прыклад ідэнтыфікатараў, а не схема ЕС. Звяжыце паведамленне, версію мадэлі, апрацоўку вываду, рашэнне чалавека і публікацыю, не запісваючы сакрэты або поўныя транскрыпты ў кожны журнал. Для высокарызыковага выкарыстання дазвольце provider і deployer атрымліваць, тлумачыць і карэляваць падзеі. Кіраўніцтва па назіральнасці AI-агента апісвае трасы, метрыкі і рэдагаванне даных.
Чалавечы нагляд павінен працаваць
Article 14 датычыцца высокарызыковых AI-сістэм. Provider павінен праектаваць іх, у тым ліку з адпаведнымі інструментамі ўзаемадзеяння чалавека і машыны, так, каб фізічныя асобы маглі эфектыўна наглядаць за сістэмай падчас выкарыстання. Меры павінны адпавядаць рызыцы, узроўню аўтаноміі і кантэксту. Article 14 патрабуе, каб чалавек мог зразумець магчымасці і абмежаванні, выявіць анамаліі і нечаканую працу, заўважыць automation bias, правільна вытлумачыць вынік, праігнараваць або адмяніць яго і спыніць сістэму кнопкай ці падобнай працэдурай, якая пераводзіць яе ў бяспечны стан.
Article 26 патрабуе ад deployer даручыць нагляд людзям з неабходнымі кампетэнцыямі, навучаннем, паўнамоцтвамі і падтрымкай. «Хтосьці паглядзеў» не з’яўляецца кантролем, калі чалавек не бачыць доказаў, не можа адхіліць рэкамендацыю або спыніць дзеянне. Размясціце мяжу зацвярджэння да незваротнага пабочнага эфекту. Пакажыце вынік мадэлі, важныя ўводы, абмежаванні сістэмы, праверкі палітык і дакладнае наступнае дзеянне. Раздзяліце адхіленне, рэдагаванне, эскалацыю і спыненне. Запісвайце, хто ўмяшаўся і чаму, не ператвараючы правяральніка ў фармальную пячатку.
Для высокарызыковых сістэм Annex III, point 1(a), Article 14(5) патрабуе асобнай праверкі і пацвярджэння выніку як мінімум двума кампетэнтнымі, навучанымі і ўпаўнаважанымі фізічнымі асобамі да таго, як deployer будзе дзейнічаць на падставе ідэнтыфікацыі. Выключэнне пра непрапарцыйнасць прадугледжана правам Саюза або нацыянальным правам для праваахоўнай дзейнасці, міграцыі, пагранічнага кантролю і прытулку. Гэта спецыяльнае правіла, а не агульнае патрабаванне двух правяральнікаў для кожнага AI-выніку.
Паток даных, які можна разгарнуць
Пакіньце кантроль у дэтэрмінаваных службах вакол мадэлі. Шлюз узаемадзеяння адказвае за першапачатковае паведамленне і лакаль. Адаптар мадэлі запісвае версію і нармалізуе метаданыя provider. Сэрвіс вываду вызначае мадальнасць і прызначэнне, ужывае або правярае машыначытальную метку і вырашае, ці патрэбны бачны ярлык або змястоўная чалавечая праверка. Шлюз палітык блакуе публікацыю без неабходнага сігналу. Сэрвіс зацвярджэння захоўвае правяральніка, рашэнне, тэрмін дзеяння і шлях спынення. Сховішча падзей атрымлівае мінімальны звязаны запіс. Маніторынг шукае адсутныя паведамленні, памылкі метак, неправерены тэкст пра грамадскі інтарэс, нечаканыя выклікі інструментаў і няўдалыя спыненні.
Не хавайце гэтыя праверкі ў prompt. Толькі інтэрфейс гарантуе паведамленне да пачатку струменевага адказу, а толькі канвеер вываду захавае метку пасля экспарту. Для дазволаў агента і недавераных вынікаў інструментаў глядзіце кіраўніцтва па prompt injection і бяспецы MCP. Для асобных межаў аркестрацыі, палітыкі і пабочных эфектаў глядзіце кіраўніцтва па production-архітэктуры AI-агента.
Маніторынг і рытм абнаўленняў
Лічыце Article 50 інварыянтам рэлізу. Кожны build, які змяняе мадэль, сістэмны prompt, інтэрфейс, рэндэрынг, экспарт або лакалізацыю, павінен правяраць паведамленне падчас першага ўзаемадзеяння, захаванне машыначытальнай меткі пасля спампоўвання і пераўтварэння, бачнае раскрыццё deepfake і немагчымасць апублікаваць тэкст пра грамадскі інтарэс без праверкі або меткі. Тэстуйце клавіятуру, screen reader, мабільную версію, голас і API-кліенты, бо Article 50(5) патрабуе яснай і адрознай інфармацыі з улікам даступнасці.
У працы падымайце трывогу праз адсутнае паведамленне, памылку паходжання, метку, выдаленую пераўтварэннем, публікацыю без human_review, правяральніка без паўнамоцтваў або спыненне, якое не пераводзіць сістэму ў бяспечны стан. Штотыдзень праглядайце выбарку трас. Штомесяц правярайце захоўванне, доступ, навучанне і змены мадэлі або provider. Штоквартальна праводзьце дакументаваны агляд рызыкі і патоку даных. Неадкладна пераглядайце сістэму пасля сур’ёзнага інцыдэнту, рэлізу provider, новай мадальнасці, змены прызначэння, істотнай мадыфікацыі або новага кіраўніцтва Камісіі.
Гэта інжынерная практыка, а не ўстаноўлены законам інтэрвал. Для высокарызыковых сістэм узгадніце кіраванне рызыкамі і постмаркетынгавы працэс з Articles 9 і 72. Article 112 прадугледжвае ацэнку магчымых змяненняў спісу Article 50 да 2 жніўня 2028 года і кожныя чатыры гады пасля гэтага. Вядзіце рэестр крыніц з кансалідаваным тэкстам EUR-Lex, кіраўніцтвам Камісіі, статусам code of practice і адказным нацыянальным органам.
Чэкліст перад рэлізам
- Запішыце provider, deployer, прызначэнне, сувязь з Саюзам, мадальнасці, карыстальнікаў і кірункі вываду.
- Вызначце дастасавальны пункт Article 50 і захавайце доказы выключэнняў.
- Пакажыце паведамленне пра ўзаемадзеянне да першага токена і праверце даступнасць.
- Ужывіце машыначытальную метку на мяжы provider і праверце яе пасля экспарту.
- Дадайце раскрыццё пры першым уздзеянні для deepfake і тэксту пра грамадскі інтарэс.
- Вызначце змястоўную праверку, рэдакцыйную адказнасць, паўнамоцтвы, адмену і бяспечнае спыненне.
- Для высокарызыковай сферы рэалізуйце запіс падзей, уладальніка, доступ, захоўванне і эскалацыю.
- Звяжыце кожны рэліз з запісамі мадэлі, палітыкі, меткі, правяральніка і маніторынгу.
- Правярайце афіцыйныя крыніцы Камісіі і EUR-Lex перад важным рэлізам і пасля рэгуляторных змяненняў.
Афіцыйныя крыніцы гэтага кіраўніцтва: кансалідаваны Regulation (EU) 2024/1689, кіраўніцтва Камісіі па Article 50, FAQ Article 50, каляндар AI Act і кароткія факты пра празрыстасць. Вызначальнымі з’яўляюцца тэкст закона і кіраўніцтва Камісіі. Гэты артыкул не замяняе юрыдычную, privacy або галіновую кансультацыю.