Банкке LLM-шлюз немесе тікелей келісімшарт қалай таңдалады

Белгілі бір модель немесе бұлттық функция стратегиялық тәуелділік ретінде қажет болып, банк оның тәуекелін бөлек басқаруға дайын болса ғана әр жеткізушімен тікелей келісімшарт жасасқан жөн. Командаларға бірнеше модель тобы, бірыңғай қолжетімділік ережелері, деректерді жергілікті сақтау және іркіліс кезінде жылдам ауысу қажет болса, шлюз әдетте басқаруға ыңғайлы жүйе береді.

Бұл «салмақты келісімшарт» пен ыңғайлы API арасындағы таңдау емес. Екі нұсқаға да заңдық тексеру, қауіпсіздікті бағалау және тәуекелге жауапты нақты адам қажет. Айырмашылық мынада: банк осы бақылау рәсімін әр провайдер үшін қайталай ма, әлде кейін жеткізушілермен байланысты өзі басқаратын бір қабатты тексере ме. Код жазылғаннан кейін ғана осы мәселені шешкендіктен, бір апталық пилот сатып алу, қауіпсіздік және әзірлеу командалары арасындағы алты айлық дауға айналған жобаларды көрдім.

Банк шын мәнінде нені таңдайды

Банк модельді емес, басқару шекарасын таңдайды. Тікелей келісімшарт бұл шекараны банк қолданбасы мен әр сыртқы API арасына қояды. Шлюз олардың арасына бірыңғай бақылау қабатын енгізеді: қолданба бір API-ға жүгінеді, ал қабат саясатты қолданып, рұқсат етілген сұрауды таңдалған провайдерге немесе жергілікті орналастырылған модельге жібереді.

Мұнда үш бөлек ұғымды жиі араластырады. «Жергілікті модель» дегеніміз модель салмағы мен есептеу ресурстары бақыланатын инфрақұрылымда орналасқанын білдіреді. «Жергілікті шлюз» сұрауды қабылдау нүктесі, журналдар мен маршрутизация ережелері қажетті юрисдикцияда орналасатынын білдіреді, бірақ кейбір сұраулар сыртқы API-ға кетуі мүмкін. «Модельдер агрегаторы» ортақ каталог ұсына алады, алайда банкке қажет журналдарды, кілттерді бөлуді немесе жергілікті сақтауды қамтамасыз етуге міндетті емес. Егер сатып алу бөлімі осы сөздерді синоним ретінде қолданса, жеткізушілер үш түрлі сұраққа жауап береді, ал комиссия салыстыруға келмейтін ұсыныстарды салыстырады.

Алдымен төрт шекараны бекітіңіз: банк желісі қай жерде аяқталады, сұрау дербес деректерден қай жерде тазартылады, модельді кім таңдайды және бұл шешімнің техникалық ізі қайда қалады. Осыдан кейін архитектуралық сызба келісімшарттың бір бөлігіне айналады. Мұндай шекараларсыз «деректер сақталмайды» деген сөйлемнің пайдасы шамалы, себебі қай дерек, қай компонент және қай кезең туралы айтылғаны түсініксіз.

Жеткізушіні тексеру келісімшарт санына көбейеді

Үш провайдерге тікелей қосылу бір кеңейтілген тексеруді емес, үш бөлек циклді білдіреді. Әрқайсысының деректерді өңдеу шарттары, қауіпсіздік сауалнамасы, қосалқы өңдеушілер тізімі, оқиға туралы хабарлау тәртібі, қаржылық тексеруі, салық құжаттары және трансшекаралық беруді келісу рәсімі бар. Сұрақтар бірдей болғанның өзінде жауаптар мен келісімшарт тұжырымдары сәйкес келмейді.

Шлюз банктің тікелей контрагенттер санын азайтады, бірақ жеткізу тізбегін тексеру талабын жоймайды. Банк шлюздің кейін қандай провайдерлерді тартатынын, әрқайсысына қандай сұрауларды жібере алатынын, тізімдегі өзгеріс туралы қалай хабарлайтынын және келісімсіз жаңа провайдер қоса алатынын білуге тиіс. Бір келісімшарт бүкіл тізбек бойынша міндеттемелерді қамтыса ғана пайдалы. Серіктестер туралы жалпы сөйлемнің артына тізбекті жасыру жеткіліксіз.

Тексеру мерзімін заңгерлердің жұмыс жылдамдығы емес, шешілмеген ең баяу сұрақ анықтайды. Әдетте бұл өңдеу орны, аудит құқығы, журнал құрамы немесе жою тәртібі болады. Сондықтан нұсқаларды «бірнеше күнде қосамыз» деген уәдемен салыстыруға болмайды. Екі тарапқа да бір дәлелдер тізілімін толтыртыңыз: құжат, иесі, жарамдылық мерзімі, қолданылатын сервис және ерекшеліктер. Бір бақылау бірнеше модельді қамтыса, шлюз ұтады. Провайдер делдал банкке бере алмайтын бірегей дәлел немесе міндеттеме ұсынса, тікелей келісімшарт ұтады.

Дұрыс құрылған сатып алу рәсімінде қайта тексеру ережесі бар. Деректің жаңа түрі, жаңа өңдеу аймағы, құралдары бар жаңа модель немесе қосалқы өңдеушінің ауысуы сұрақтардың бір бөлігін қайта қарауға тиіс. Әйтпесе, бір кезде мақұлданған мәтіндік API файлдары, веб-іздеуі және ұзақ сақталатын күйі бар сервиске білдіртпей айналады, ал бастапқы бағалау мұның ешқайсысын қамтымаған болады.

Бір келісімшарт бір жауапкершілік жасамайды

Шлюз арқылы банк бір коммерциялық байланыс нүктесін алады, бірақ техникалық жауапкершілік бөлінген күйде қалады. Модель қате жауап беруі, сыртқы провайдер баяулауы, шлюз маршрутты дұрыс қолданбауы, ал банк қолданбасы артық дерек жіберуі мүмкін. Келісімшарт осы жағдайлардың иесін, әрекет ету мерзімін және қажетті дәлелдерді көрсетуге тиіс.

«Жеткізуші сервистің қолжетімділігіне жауап береді» деген тұжырым тым жалпылама. Талдау үшін кемінде төрт оқиғаны бөлу керек: сұрау шлюзге жетпеді, шлюз оны саясат бойынша қабылдамады, таңдалған провайдер қате қайтарды немесе жауап уақытында келді, бірақ банктің сапа тексеруінен өтпеді. Бірінші жағдайға қолданба не желі командасы, екіншісіне саясат иесі, үшіншісіне маршрут операторы, төртіншісіне бизнес-сценарий иесі жауап береді. Қолжетімділік үшін ақшалай өтемақы клиентке қызмет көрсетуді алдағы он минутта кім қалпына келтіретінін айтпайды.

Тікелей келісімшартта бір сұраудың тізбегі қысқа: банк нақты API жауабын көреді де, сол провайдердің қолдау қызметіне өтінім ашады. Бірақ қолданба үш API арасынан өзі таңдайтын болса, банк іс жүзінде өз шлюзін жасап қойған. Енді үйлесімділік кестесі, қателерді бір қалыпқа келтіру, қайталама сұраулар, лимиттер, журналдар және кезекшілік банкке жүктеледі. Бұл жұмыс әр репозиторий мен командаға бөлініп кеткендіктен, оны есепке жиі қоспайды.

Келісімшарттың пайдалы қосымшасы қарапайым сұраққа жауап беруі керек: сұраудың мазмұнын қажеттен артық ашпай, тексеру жүргізу үшін банк қандай өрістер алады? Сұрау идентификаторы, уақыт, маршрут, таңдалған модель мен нұсқа, саясат шешімі, талпыныс саны, нәтиже коды және қате көзі қажет. Жеткізуші осы жиынды бере алмаса, қол қоюға дейін «толық бақылау» деген уәдені алып тастаған дұрыс.

Орталықтандырылған қолжетімділік қате аумағын азайтады

Шлюз банкке кілттерді, лимиттерді және рұқсаттарды бір жерден басқаруға мүмкіндік береді. Соның арқасында қауіпсіздік командасы API-ды шақыру құқығын кез келген модельді таңдау құқығынан бөледі. Бұл екеуінің айырмасы маңызды. Техникалық тұрғыда жұмыс істейтін кілт иесіне белгілі бір дерек класын жіберуге немесе модель құралдарын қосуға рұқсат берілгенін білдірмейді.

Тікелей интеграцияда әр консольдің өз рөлдері, жобалары, кілт форматтары мен журналдары бар. Банк оларды корпоративтік сәйкестендіру жүйесіне қоса алады, бірақ үш ортада да бірдей ереже орындалатынын дәлелдеуі керек. Айырмашылық білдіртпей пайда болады: сынақ жобасы өндірістік кілт алады, пилот жабылғаннан кейін ескі сервистік аккаунт қалады, ал бір провайдер журналға модельді басқа атаумен жазады.

Бақылауды провайдер консоліндегі адам аттарымен емес, банк қолданбасы деңгейіндегі саясатпен белгілеңіз. Қолжетімділіктің ең кіші бірлігі қолданбаны, ортаны, дерек класын, рұқсат етілген модельдерді, бюджетті, сұрау жылдамдығын және жарамдылық мерзімін қамтиды. Төменде нақты өнімнің конфигурациясы емес, ішкі саясат келісімінің үлгісі берілген:

{
  "client": "contact-center-prod",
  "data_class": "internal-masked",
  "allowed_models": ["model-a-stable", "model-b-stable"],
  "tools": [],
  "requests_per_minute": 120,
  "monthly_budget_kzt": 900000,
  "expires_at": "2026-12-31"
}

Мұндай жазба жиі кездесетін екі ақаудың алдын алады. Қолданба осы дерек класы үшін тексерілмеген модельге өздігінен өте алмайды, ал сыртқа кеткен кілт мерзімсіз және шексіз қолжетімділік бермейді. Тікелей келісімшарттармен де осы нәтижеге жетуге болады, бірақ банк бір саясатты әр провайдердің тетігіне аударып, айырмашылықтарды автоматты түрде тексеріп отыруы керек.

Сақтау орны өңдеу орнына тең емес

Қазақстандық банк үшін резиденттік мәселесін коммерциялық ұсыныстағы аймақ атауымен жабуға болмайды. Қазақстан Республикасының дербес деректерді жинау және өңдеу қағидалары дербес деректерді ел аумағындағы базада сақтауды талап етеді. Заң трансшекаралық беруді де бөлек реттейді. Архитектор мен заңгер сұрау жолын операцияларға бөліп қарауы керек: бастапқы жинау, сақтау, уақытша кэштеу, өңдеу, журналға жазу, резервтік көшіру және қолдау қызметінің қолжетімділігі.

OpenAI ресми құжаттамасы аймақ параметрінің өзі неліктен жеткіліксіз екенін жақсы көрсетеді. Онда customer content пен system data бөлек қаралады, теріс пайдалануды бақылау журналдары сипатталады және кейбір функциялардың қолданба күйін жасайтыны айтылады. Anthropic компаниясының Zero Data Retention материалдары да бұл режимнің API-ға қатысты екенін және кейбір сақтау функцияларына бөлек ереже қолданылуы мүмкін екенін ескертеді. Google Vertex AI үшін деректерді сақтау жағдайлары мен нөлдік сақтауға қажет баптауларды тізіп көрсетеді. Әр endpoint пен қосылған функция бойынша кестесіз «zero retention» деген сөйлемді қабылдамас едім.

Жергілікті шлюз сұрауды Қазақстан ішінде қабылдап, PII деректерін бүркемелеп, аудитті ел ішінде жазып, сыртқа тек рұқсат етілген бөлігін жібере алады. Бірақ ол сыртқы шақыруды жергілікті өңдеуге айналдырмайды. Сүзілген мәтінде дербес деректер, банк құпиясы немесе клиентті қайта анықтауға болатын мәлімет қалса, трансшекаралық тәуекел сақталады. Бүркемелеуді де нақты форматтарда сынау қажет: аты-жөн, ЖСН, келісімшарт нөмірлері, операторлардың еркін мәтіні және тіркемелер әртүрлі өңделеді.

Дерек елден шықпауға тиіс сценарийге ел ішінде орналастырылған модельге маршрут және сыртқы fallback-қа тыйым қажет. Сезімталдығы төмен сценарийлерде банк деректерді барынша азайтқаннан кейін сыртқы модельдерге рұқсат бере алады. Дұрыс саясат бұл шешімді сұрауды жібермей тұрып қабылдайды. Нашар саясат әзірлеуші әр шақыруда тиісті параметрді есіне алады деп үміттенеді.

Төзімділік жауаптың мағынасынан басталады

Провайдерлер арасында автоматты ауысу басқа модель қолайлы нәтиже бере алатын тапсырмаларда ғана пайдалы. Қосалқы модельден келген HTTP 200 қызмет қалпына келді деген сөз емес. Құрылымдалған жауап форматы, контекст ұзындығы, қауіпсіздік саясаты, құралдарды қолдану тәсілі және банк терминологиясындағы сапасы өзгеше болуы мүмкін.

Шлюз бірыңғай тайм-аутты, шектеулі қайталауды және fallback маршрутын қолдануды жеңілдетеді. Тікелей API командаға толық бақылау береді, бірақ дәл осы тетікті қолданба ішінде жасап, сүйемелдеу керек. Екі жағдайда да нәтиже белгісіз болғанда идемпотенттіліксіз сұрауды қайталамаңыз: жауап жоғалса да, бірінші талпыныс әрекетті орындап қоюы мүмкін. Мәтін жобасын жасау үшін бұл аса қауіпті емес. Өтінім ашатын немесе өтінім мәртебесін өзгертетін агент үшін бұл операциялық тәуекел.

Іске қосар алдында қайталанатын бір іркіліс сынағын өткізіңіз:

1. Он эталон сұрауды, рұқсат етілген жауаптарды және тыйым салынған әрекеттерді бекітіңіз.
2. Сұрау жіберілгеннен кейін негізгі провайдердің тайм-аут қайтаруын жасанды түрде іске қосыңыз.
3. Қолжетімділік қабаты қай маршрутты таңдағанын және қанша талпыныс жасағанын тексеріңіз.
4. Қосалқы жауаптың құрылымы мен сапасын белгіленген шектермен салыстырыңыз.
5. Журнал екі талпынысты бір идентификатормен байланыстырып, қате көзін атағанына көз жеткізіңіз.

Команда бұл сынақты үш консольге қолмен кірмей өткізе алмаса, автоматты fallback-қа уәде беруге дайын емес. Маңызды процесс үшін аз тексерілген модельге білдіртпей өткеннен гөрі, функцияны тоқтатып, басқарылатын қате көрсеткен дұрыс болуы мүмкін.

Токен бағасы шығынның көбін жасырады

Прайс-парақтарды салыстыру шақырудың айнымалы бағасы туралы ғана жауап береді. Банк жеткізушіні тексеруге, келісімшартқа, сәйкестендіруді интеграциялауға, журналдарға, бюджет бақылауына, SDK қолдауына, жаңа нұсқаларды сынауға, кезекшілікке және шоттарды салыстыруға да төлейді. Бірнеше тікелей келісімшартта осы шығындардың бір бөлігі қайталанады, бірақ жоба бюджетінде олар штаттағы қызметкерлердің уақыты болып көрінеді.

Шлюздің өз экономикасы бар: сервис үшін ықтимал төлем, қосымша кідіріс, жергілікті инфрақұрылым құны және делдалға тәуелділік тәуекелі. Оны токен үстемесімен ғана емес, ішкі бақылау қабатының құнымен салыстыру керек. Шлюз модельдерді провайдер бағасымен API үстемесінсіз есептесе, бір сұрақ шешіледі, бірақ пайдалану тегін болмайды. Бизнестің неден табыс табатынын, қай қызметке бөлек ақы алынатынын және банк шотты маршрут журналдарымен қалай салыстыратынын сұраңыз.

Есепті бір жылдық сценариймен жасаған дұрыс. Өндірістік қолданбалар санын, күтілетін модельдерді, сатып алу жұмысының айларын, қауіпсіздік мамандары мен заңгерлер уақытын, адаптерлер әзірлеуді, жаңартуларды сынауды және оқиға құнын банкке түсінікті өлшеммен алыңыз. Апаттың дәл бағасын ойдан шығарудың қажеті жоқ. Шығынның бірнеше түсінікті деңгейінде нұсқаларды салыстырып, шешімнің өзгеретінін не өзгермейтінін көріңіз.

Бір провайдердегі үлкен әрі тұрақты көлем, ерекше коммерциялық шарттар немесе шлюз жоғалтпай жеткізе алмайтын функция болса, тікелей келісімшарт жиі орынды. Модельдер жиыны өзгеріп, ішкі тұтынушылар саны көп болса, шлюз басымырақ болады. Аралас схема екі шектің екеуінен де арзан болуы мүмкін: бір стратегиялық сервиске тікелей маршрут, эксперименттер мен қалыпты тапсырмаларға ортақ қабат, жабық деректерге жергілікті модель.

Шлюз шоғырланудың өз тәуекелін қосады

Бір бақылау нүктесі бір тәуелділік нүктесіне де айналады. Саясат қатесі барлық қолданбаны бұғаттауы, әкімшілік қолжетімділіктің бұзылуы бірнеше маршрутты ашуы, ал адаптердің қате шығарылымы әртүрлі модель жауаптарын бұрмалауы мүмкін. Бұл шлюзден бас тартуға себеп емес. Оны банктің маңызды компоненті ретінде тексеру қажет екенін білдіреді.

Клиенттер мен кілттерді оқшаулау сызбасын, өзгерістерді шығару рәсімін, саясат нұсқаларының тарихын, қолдау инженерлерінің қолжетімділік тәртібін және қалпына келтіру жоспарын сұраңыз. Банк конфигурацияны, журналдарды және модельдердің сәйкестік кестесін экспорттай ала ма, соны бөлек тексеріңіз. Көшірілетін күй болмаса, шлюзді ауыстыру апат қысымымен орындалатын жаңа сатып алу жобасына айналады.

Каталогқа қатысты тағы бір ыңғайсыз сұрақ бар. Жүздеген қолжетімді модель таңдау аясын кеңейтеді, бірақ банк саясаты жүздеген модельге рұқсат бермеуі керек. Каталог пен рұқсат етілген тізілім екі бөлек міндет атқарады. Біріншісі техникалық мүмкіндікті көрсетеді. Екіншісінде иесі, дерек кластары, evaluation нәтижелері және қайта қарау күні бар бірнеше тексерілген нұсқа ғана тұрады.

«Делдал қоспаңыз, тікелей байланыс әрқашан сенімдірек» деген кеңеспен келіспеймін. Ол бір өзгермейтін API үшін дұрыс, ал модельдер жиыны үшін қате. Әр қолданба қайталама сұрауын өзі жазып, кілтін өзі сақтап, қатені өзі түсіндірсе, делдалдар бәрібір бар. Олар тек банк кодының ішінде көбейіп кеткен және ешкім оларды бір сервис ретінде басқармайды.

Шешім матрицасы тәуекел иесін көрсетуі керек

Таңдауды брендке дауыс беру арқылы емес, әр өлшемнің дәлелі мен иесі бар матрица арқылы рәсімдеу керек. Өлшем салмағы нақты сценарийге тәуелді: қызметкерлер чаты, операторға кеңес, құжаттарды талдау және әрекет жасауға құқығы бар агент бір жолмен бағаланбайды. Әуелі банк қатенің салдарын сипаттап, содан кейін жеткізу тәсілдерін салыстырады. Кері рет талаптарды командаға ұнаған сервиске бейімдеуге әкеледі.

Жеткізушіні тексеру бойынша тікелей нұсқа әр контрагентке бөлек цикл жасайды. Сауалнамалар, сертификаттар, өңдеу шарттары, қосалқы өңдеушілер және функция ерекшеліктері толтырылған тізілім дәлел болады. Шлюз үшін негізгі цикл біреу, бірақ тізілім жеткізу тізбегін ашуы керек. Бұл өлшемге vendor management немесе сатып алу бөлімі жауап береді, ал қауіпсіздік техникалық бөлігін растайды. Шлюз қосалқы өңдеушінің ауысуын хабарламаса, тексеруден үнемделген уақыт көрінбейтін тәуекелге айналады.

Келісімшарттар мен шоттар бойынша тікелей нұсқада бірнеше шарт, валюта, тұтыну шегі және дауды шешу тәртібі болады. Шлюз оларды бір коммерциялық терезеге жинайды, бірақ банк қолданба, модель және маршрут бойынша шығын детализациясын алуы керек. Қаржы бөлімі шот сомасын журналдардан қайта шығаруға болатынын тексереді, ал заңгерлер шлюз келісімі мен бастапқы провайдердің шектеуі қайшы келсе, қай шарт қолданылатынын анықтайды. Дөңгелектеу, кэштеу және қайталама сұрау ережелерінсіз «модель тарифі бойынша» деген сөйлем бақылауға жетпейді.

Қолжетімділік бойынша тікелей келісімшарттар әр консольде рөлдер мен кілттер береді. Дәлел экран суреті емес, пайдаланушылар, сервистік аккаунттар, рұқсаттар және соңғы белсенділік туралы тұрақты машиналық экспорт. Шлюз бірыңғай саясат пен өзгерістер тарихының сондай экспортын ұсынуға тиіс. Жеткізуші кілт бергеннің өзінде банктің IAM қызметі жауапты болып қалады. Операцияны сыртқа беру банк ішінде кім қолжетімділік алғанына жауапкершілікті бермейді.

Резиденттік бойынша тікелей нұсқа әр сервистің аймағына, endpoint-ына және қосылған функциясына тәуелді. Шлюзде жергілікті қабылдауды, жергілікті журналдарды, сыртқы маршрутты және жергілікті маршрутты бөлек бағалау керек. Дәлел географиялық белгілері бар сурет емес, операциялар бойынша құрылған деректер картасы. Онда сұрау мен жауап мазмұны, метадеректер, кэш, журнал, резервтік көшірме, өңдеу орны және жою мерзімі көрсетіледі. Заңгер қолданылатын шектеуді анықтайды, дерек иесі рұқсат етілген құрамды растайды, ал архитектор нақты конфигурация картаға сай екенін дәлелдейді.

Іркіліс бойынша тікелей келісімшарт банкке нақты провайдермен байланыс арнасын және аз аралық компонент береді. Шлюз бірыңғай диагностика жасап, маршрутты ауыстыра алады, бірақ өзі қосымша ақау нүктесін қосады. Талпыныс идентификаторлары, қате кодтары, ауысу уақыты және қосалқы жауапты тексеру нәтижесі бар сынақ хаттамасы дәлел болады. SRE немесе өндірістік қолдау бұл өлшемді сынақтан кейін ғана қабылдайды. Қайталанатын сценарийсіз сервис деңгейі туралы келісім нақты банк функциясының қалпына келуі жайында ештеңе айтпайды.

Шешімнен шығу бойынша тікелей келісімшарттар әр адаптерді көшіруді және модель әрекетін қайта салыстыруды талап етеді. Шлюзде API өзгермеуі мүмкін, бірақ саясат, журнал және каталог форматына тәуелділік туады. Келісімшартқа дейін банк конфигурацияны, журналдарды, модельдер тізілімін және жиналған evaluation нәтижелерін оқылатын форматта экспорттауды сұрауы керек. Архитектура иесі бір қолданбаны балама endpoint-қа сынақ ретінде көшіреді. Мұндай көшіру қазіргі жеткізушінің көмегінсіз мүмкін болмаса, шығу жоспары әзірге қағазда ғана бар.

Матрицаға өзгеріс жылдамдығын да қосыңыз. Провайдерлер модель нұсқаларын, сақтау ережелерін және қолжетімді функцияларды банк күнтізбесіне қарамай жаңартады. Тікелей келісімшартта әр команда өз сервисін бақылайды немесе орталық топ ортақ тізілім жасайды. Шлюз өзгерістерді бір қалыпқа келтіре алады, бірақ банк жаңа нұсқа туралы автоматты ауысудан бұрын білуі тиіс. Хабарлама, тексеру кезеңі, нұсқаны бекіту мүмкіндігі және түсінікті кері қайтару дәлел болады. Бұл жұмысқа жауапты адам жауаптағы айырманы алғаш байқап қалған әзірлеуші емес, model governance иесі болуы керек.

Сапаны бөлек бағалаңыз, себебі модельдің каталогта болуы оның жарамдылығын дәлелдемейді. Банк сұраулар, тілдер, форматтар, тыйым салынған әрекеттер мен шектер жиынын өзі белгілейді. Провайдер немесе шлюз evaluation өткізуге көмектесе алады, бірақ рұқсатты банк сценарийінің иесі береді. Орташа балл өткізу рұқсаты болмауы керек: модель жалпы жақсы жауап беріп, салдары ауыр сирек жағдайда қателесуі мүмкін. Нәтижелерді модель мен маршрутизация саясатының нақты нұсқасына байланыстырыңыз.

Әр өлшемге төрт мәртебенің бірін беріңіз: дәлелденді, шектеумен дәлелденді, қалдық тәуекел ретінде қабылданды, дәлелденбеді. Бұл жасыл белгілер тізімі емес. «Шектеумен дәлелденді» мәртебесі рұқсат етілген дерек класын немесе функцияны атауы керек, ал қалдық тәуекелдің қайта қарау мерзімі мен оны қабылдауға өкілетті адамның қолы болуы тиіс. Дәлелденбеген өлшем міндетті түрде бүкіл пилотты емес, тиісті маршрутты ғана бұғаттайды. Осылайша банк экспериментке барлық дерекке рұқсат бермей, қауіпсіз сценарийді сынай алады.

Матрица толтырылғаннан кейін әр даулы ұяшықта қалдық тәуекелді қабылдайтын адам пайда болады. Сыртта сақтауға ешкім қол қоюға дайын болмаса, маршрутты ашуға болмайды. Бизнес іркіліс кезінде тоқтауды қабылдаса, күрделі fallback үшін төлеудің қажеті жоқ. Матрица «қауіпсіздеу» деген дерексіз сөзді тексерілетін шешімге айналдырады және ортақ талқылауда жауапкершіліктің жоғалуына жол бермейді.

NIST AI Risk Management Framework жұмысты govern, map, measure және manage функцияларына бөледі әрі әрекеттердің әмбебап чек-лист емес екенін тікелей ескертеді. Сатып алу үшін бұл дұрыс бағыт: келісімшарт govern функциясына, деректер ағынының картасы map функциясына, сапа мен іркіліс сынақтары measure функциясына, ал ауысу мен оқиғаны талдау manage функциясына жатады. API сатып алу бірінші функцияның бір бөлігін ғана жабады. Толық матрица келісімшартқа қол қойылғаннан кейін жұмысты кім жалғастыратынын көрсетеді, себебі модель тәуекелі сценариймен, дерекпен және нұсқамен бірге өзгереді.

Аралас схема екі нұсқаның бірін таңдаудан шынайырақ

Банкке барлық тапсырма үшін бір жолды мәңгі таңдау сирек қажет. Маршруттарды қате салдары мен дерек сезімталдығына қарай бөліңіз. Жабық құжаттар мен идентификаторлар жергілікті орналастырылған модельде қалады. Бүркемеленгеннен кейінгі қалыпты мәтін шлюз арқылы тексерілген сыртқы провайдерге жіберілуі мүмкін. Стратегиялық провайдердің бірегей функциясы делдал оның қасиетін немесе келісімшарт кепілдігін сақтай алмаса, тікелей келісімшарт алады.

AI Router бір OpenAI-үйлесімді endpoint арқылы сұрауларды сыртқы және жергілікті орналастырылған open-weight модельдерге бағыттай алады, PII бүркемелеуді, аудит журналдарын және кілт деңгейіндегі лимиттерді қолданады. Банк үшін бұл бірыңғай бақылау қабатына үміткер, бірақ жеткізу тізбегін, дерек режимін және қалпына келуді өз бетімен бағаламауға себеп емес.

Пилотты ең әдемі жауап берген модельден емес, екі маршрут пен алдын ала белгіленген іркілістен бастаған жөн. Бір маршрут деректің елден шығуына тыйым салуға тиіс, екіншісі бүркемелеуден кейін сыртқы провайдерді пайдалана алады. Екеуіне бір қолжетімділік саясатын, журнал жүргізуді, лимитті және іркіліс сынағын қолданып, кейін дәлелдерді қауіпсіздікке, заңгерлерге және процесс иесіне беріңіз.

Банк жеткізушінің таныстырылымынсыз бір сұраудың тағдырын түсіндіре алғанда, шешім сатып алуға дайын болады: оны кім жіберуге құқылы еді, қандай дерек алынып тасталды, қайда өңделді, бұл модель неге таңдалды, журналға не жазылды және қате кезінде кім әрекет етеді. Әр сұраққа әр команда жауап беріп, жауаптары қайшы келсе, тікелей келісімшарт туралы дау әлі ерте. Алдымен банк шын мәнінде пайдалана алатын басқару шекарасын анықтаңыз.