Google-ийн SAIF: AI системийг хэрхэн аюулгүй хөгжүүлж, нэвтрүүлэх вэ?

Байгууллагууд хиймэл оюун ухаан (AI) болон өгөгдөл үүсгэгч хиймэл оюун (GenAI)-ийг туршилтын шатнаас бодит хэрэглээнд нэвтрүүлэхийн хэрээр аюулгүй байдлын цоо шинэ сорилтуудтай нүүр тулж байна. Уламжлалт програм хангамжийн аюулгүй байдлын аргууд (SAST, DAST, сүлжээний хамгаалалт) нь кодын түвшний цоорхойг илрүүлдэг ч, AI системийн хувьд эрсдэл нь кодонд биш, загварын төлөв байдал, өгөгдлийн хамаарал дотор оршдог.

Prompt injection, өгөгдөл хордуулах (data poisoning), эсвэл сургалтын өгөгдлийг хулгайлах зэрэг нь уламжлалт firewall болон хандалтын удирдлагаар зогсоох боломжгүй шинэ төрлийн халдлагууд юм.

Технологийн удирдагчид, CTO нар болон ахлах инженерүүдийн хувьд AI системийг аюулгүй байдлын өндөр эрсдэлгүйгээр хэрхэн хурдтай хөгжүүлэх вэ гэдэг нь стратегийн гол асуудал болоод байна.

Энэхүү хэрэгцээг хангах үүднээс Google компани Secure AI Framework (SAIF) буюу Аюулгүй AI Аргачлал танилцуулсан. SAIF нь шинэ арга зохиох бус, харин байгууллагын одоо байгаа аюулгүй байдлын туршлагыг AI-ийн экосистемд хэрхэн өргөжүүлэх, эрсдэлийг хэрхэн удирдах талаарх архитектур, үйл ажиллагааны цогц хэрэгсэл юм. Энэхүү нийтлэлээр бид SAIF-ийн үндсэн зарчмууд, түүнийг бодит орчинд хэрхэн хэрэгжүүлэх архитектурын шийдвэрүүд болон гаргаж болзошгүй түгээмэл алдаануудыг задлан шинжлэх болно.

SAIF хэрхэн ажилладаг вэ? Үндсэн 6 механик

SAIF нь AI системийг хамгаалах үйл явцыг 6 үндсэн тулгуур зарчимд хуваадаг. Эдгээр нь зөвхөн техникийн зааварчилгаа бус, байгууллагын түвшинд шийдвэр гаргах үйл явцыг чиглүүлэх зорилготой.

1. Аюулгүй байдлын хүчирхэг суурийг AI экосистемд өргөжүүлэх
   
   AI систем нь үүлэн дэд бүтэц, өгөгдлийн сан, сүлжээний орчинд ажилладаг. Тиймээс Zero Trust архитектур, Identity and Access Management (IAM) зэрэг одоо байгаа хамгаалалтын сууриа AI загварын сан (model registry), сургалтын өгөгдлийн сан, болон AI API-уудад хэрэгжүүлэх ёстой. AI загварын жин (model weights) болон сургалтын өгөгдөлд хэн хандах эрхтэйг уламжлалт кодын сангийн (source code) нэгэн адил хатуу хянах шаардлагатай.
2. Илрүүлэх болон хариу арга хэмжээ авах (Detection & Response) чадамжийг AI-д чиглүүлэх
   
   Танай байгууллагын SOC (Security Operations Center) баг SQL injection-ийг илрүүлж чаддаг шигээ Prompt injection эсвэл загварын гажуудлыг (model inversion) илрүүлж чадах уу? AI системийн лог болон телеметрийг SIEM/SOAR системүүдтэйгээ холбож, AI-д чиглэсэн шинэ төрлийн аюулын дохиог таних дүрмүүдийг үүсгэх шаардлагатай.
3. Хамгаалалтыг автоматжуулах
   
   AI-ийн эсрэг чиглэсэн халдлагууд нь маш хурдацтай хувьсан өөрчлөгддөг. Тиймээс хамгаалалтыг гар аргаар хийх боломжгүй. AI системийг хамгаалахын тулд өөр жижиг, тусгайлсан AI загваруудыг ашиглаж болно. Жишээлбэл, хэрэглэгчийн оруулсан мэдээллийг үндсэн том загвар (LLM) руу илгээхээс өмнө аюултай эсэхийг нь шалгадаг тусгайлсан шүүлтүүр загваруудыг автоматжуулах нь чухал.
4. Платформын түвшний хяналтыг жигдрүүлэх
   
   Байгууллага доторх багууд өөр өөрсдийн AI шийдлийг дураараа хөгжүүлэх нь эрсдэл дагуулдаг. Харин үүний оронд төвлөрсөн AI платформ (жишээ нь, Google Cloud Vertex AI) ашиглаж, бүх багууд нэгдсэн хяналт, аюулгүй байдлын бодлого, нийтлэг Guardrails (хамгаалалтын хашлага) дор ажиллах архитектурыг бүрдүүлэх ёстой.
5. Хяналтын механизмыг дасан зохицуулах (Feedback loops)
   
   AI загварууд цаг хугацааны явцад хувьсан өөрчлөгддөг. Өнөөдөр аюулгүй байгаа загвар маргааш шинэ төрлийн prompt-д хууртагдах магадлалтай. Тиймээс байнгын AI Red Teaming (зориуд халдлага хийж шалгах баг) ажиллуулж, олдсон цоорхойг буцааж сургалтын болон шүүлтүүрийн процесст оруулах тасралтгүй сайжруулалтын мөчлөгийг бий болгоно.
6. Эрсдэлийг бизнесийн процесстэй уялдуулах (Contextualize risks)
   
   AI системийн эрсдэлийг тухайн хэрэглээний нөхцөлөөс салгаж ойлгож болохгүй. Дотоод ажилчдын гарын авлага хайдаг AI чатбот болон харилцагчийн банкны гүйлгээг хийдэг AI агентын эрсдэлийн түвшин, тавигдах аюулгүй байдлын шаардлага тэс өөр байна. Хөрөнгө оруулалт болон хамгаалалтын хүчин чармайлтыг бизнесийн эрсдэлд тулгуурлан хуваарилах нь зүйтэй.

Архитектур ба үйл ажиллагааны загварууд

SAIF-ийг хэрэгжүүлэхийн тулд зөвхөн дүрэм журам гаргах биш, архитектурын түвшинд тодорхой шийдвэрүүдийг гаргах хэрэгтэй. AI системийг хөгжүүлэх болон нэвтрүүлэх үйл явцад дараах загваруудыг түгээмэл ашигладаг.

1. Guardrails ба API Gateway загвар

Шууд LLM рүү хэрэглэгчийн хүсэлтийг явуулах нь хамгийн том эрсдэл юм. Зөв архитектур нь AI API Gateway болон Guardrails-ийг давхарлаж ашигладаг.

• Оролтын хяналт (Input Validation): Хэрэглэгчийн хүсэлт орж ирэхэд хамгийн түрүүнд PII (хувь хүний мэдээлэл) байгаа эсэхийг шалгаж масклах (Data Loss Prevention API ашиглан), мөн prompt injection-ийн шинж тэмдэг байгаа эсэхийг тусгайлсан шүүлтүүрээр оруулна.
• Гаралтын хяналт (Output Moderation): LLM-ээс гарсан хариуг хэрэглэгчид шууд харуулахаас өмнө хариулт дотор нууц мэдээлэл, хортой код, эсвэл байгууллагын бодлогод харшилсан үг хэллэг байгаа эсэхийг дахин шалгана.

Энэхүү архитектур нь аюулгүй байдлыг хангадаг ч, системийн хариу өгөх хурдыг (latency) удаашруулах сул талтай гэдгийг тооцоолох хэрэгтэй.

2. RAG (Retrieval-Augmented Generation) дахь хандалтын удирдлага

Байгууллагууд өөрсдийн дотоод мэдээлэлд тулгуурласан AI агент үүсгэхийн тулд RAG архитектурыг өргөн ашигладаг. Энд гардаг хамгийн том аюулгүй байдлын алдаа бол өгөгдлийн сангийн түвшний хандалтын эрхийг үл тоомсорлох явдал юм. Хэрэв хэрэглэгч "A" нь байгууллагын санхүүгийн тайланг унших эрхгүй бол, тэр хэрэглэгчийн AI чатботоос асуусан асуултад RAG систем нь санхүүгийн тайлангаас хайлт хийж хариулах ёсгүй. Үүнийг шийдэхийн тулд Vector Database (вектор өгөгдлийн сан) доторх баримт бүрд мета-дата байдлаар хандалтын эрхийг (ACL) тохируулж, хайлтын илэрцийг тухайн хэрэглэгчийн IAM эрхтэй уялдуулан шүүх шаардлагатай.

3. MLSecOps буюу Нийлүүлэлтийн сүлжээний аюулгүй байдал

AI загварыг бүтээхэд маш олон гуравдагч талын сангууд (open-source libraries), гадны өгөгдлийн багцууд (datasets) болон урьдчилан сургасан загварууд (pre-trained models) ашиглагддаг. Hugging Face гэх мэт сангаас загвар татаж ашиглахдаа тухайн загварын дотор хортой код (malicious payload) нуугдсан эсэхийг баталгаажуулах шаардлагатай. Загварын гарал үүслийг баталгаажуулах (Model Provenance) болон дижитал гарын үсэг ашиглах нь MLSecOps дамжлагын салшгүй хэсэг байх ёстой.

Бодит хэрэглээ ба шийдвэр гаргах арга

AI шийдлийг нэвтрүүлэх хэрэглээний тохиолдлоос хамааран SAIF-ийг өөр өөр түвшинд хэрэгжүүлнэ.

1: Програм хөгжүүлэгчдийн код бичих туслах (Coding Assistant)

• Эрсдэл: Хөгжүүлэгчид компанийн нууц код эсвэл API түлхүүрүүдийг гуравдагч талын LLM рүү санамсаргүйгээр илгээх.
• Хэрэгжилт: SAIF-ийн платформын түвшний хяналтыг ашиглаж, хөгжүүлэгчдийн ашиглах AI хэрэгслийг төвлөрсөн байдлаар удирдана. Сүлжээний хувьд VPC Service Controls ашиглан AI үйлчилгээ рүү хандах хандалтыг зөвхөн дотоод сүлжээнээс зөвшөөрч, код дотор API түлхүүр байвал LLM рүү явахаас нь өмнө устгах (redact) локал шүүлтүүр байрлуулна.

2: Олон нийтэд нээлттэй хэрэглэгчийн үйлчилгээний AI Агент

• Эрсдэл: Гадны хэрэглэгчид зориуд хортой prompt бичиж (Prompt Injection), агентаар дамжуулан компанийн дотоод систем рүү нэвтрэх, эсвэл агентыг хуурч буруу мэдээлэл өгүүлэх.
• Хэрэгжилт: Энд SAIF-ийн хамгаалалтыг автоматжуулах болон байнгын Red Teaming хийх зарчмууд хамгийн чухал. Агентын хүлээн авах хүсэлтийг маш хатуу загварчилж, системтэй харилцах боломжийг зөвхөн урьдчилан тодорхойлсон үйлдлүүдээр (Function calling) хязгаарлана. Хэрэглэгчийн текстийг шууд гүйцэтгэх команд болгон хувиргахыг хатуу хориглоно.

Сул тал, эрсдэл болон хязгаарлалтууд (Trade-offs)

Аюулгүй байдлыг дээд зэргээр хангах нь үргэлж тодорхой хэмжээний золиос шаарддаг. CTO болон архитектуруудын хувьд дараах хүчин зүйлсийн тэнцвэрийг олох шаардлагатай:

• Хурд ба Аюулгүй байдлын зөрчил (Latency vs. Security): Оролт, гаралтыг хянах олон давхар шүүлтүүрүүд (Guardrails) нь API-ийн хариу өгөх хугацааг 500ms-аас хэдэн секунд хүртэл уртасгах эрсдэлтэй. Бодит цагийн чат хэрэглээнд энэ нь хэрэглэгчийн туршлагад сөргөөр нөлөөлнө.
• Хуурамч дохио (False Positives): Автоматжуулсан шүүлтүүрүүд хэт хатуу байвал хэрэглэгчийн энгийн, аюулгүй хүсэлтийг "хортой" гэж андуурч хаах тохиолдол гардаг. Үүнийг багасгахын тулд шүүлтүүрийн загварыг тогтмол тааруулах (tuning) шаардлагатай бөгөөд энэ нь нэмэлт үйл ажиллагааны зардал үүсгэнэ.
• Мэргэжилтний дутагдал: AI Red Teaming хийх, AI-ийн сул талыг (жишээ нь OWASP Top 10 for LLMs) сайн мэддэг аюулгүй байдлын мэргэжилтнүүд ховор бөгөөд үнэтэй байдаг. Үүнийг шийдэхийн тулд эхний ээлжинд автоматжуулсан тестлэх хэрэгслүүд (жишээ нь, нээлттэй эхийн гарааны хэрэгслүүд) ашиглахыг зөвлөдөг.

Шийдвэр гаргах шалгуурууд

Ямар төрлийн AI шийдэлд ямар түвшний аюулгүй байдал хэрэгжүүлэхээ шийдэхийн тулд дараах шалгууруудыг ашиглаж болно:

Ашиглах цар хүрээ:

• Дотоод, туршилтын орчин -> Үндсэн IAM, лог цуглуулах, эрх хязгаарлах.
• Дотоод, бүтээгдэхүүний орчин (Production) -> Дээрх дээр нэмээд RAG хандалтын хяналт, өгөгдөл масклах (DLP).
• Олон нийтэд нээлттэй агент -> Дээрх бүхнээс гадна хатуу Guardrails, API Rate limiting, байнгын Red Teaming, нарийвчилсан телеметри.

Өгөгдлийн мэдрэмтгий байдал:

• Хэрвээ систем PII, эрүүл мэндийн, эсвэл санхүүгийн өгөгдөлтэй харьцаж байвал LLM-ийг өөрийн байгууллагын виртуал сүлжээнд (VPC) дотоодод байрлуулах эсвэл гуравдагч тал руу өгөгдлөө сургалтад ашиглахгүй байх гэрээтэй (Zero Data Retention) Enterprise API ашиглах шийдвэр гаргана.

Түгээмэл алдаанууд ба тэдгээрээс сэргийлэх нь

AI системийг нэвтрүүлэх явцад багуудын хамгийн их гаргадаг алдаанууд:

• Зөвхөн Prompt-д найдах: "Та бол аюулгүй, ёс зүйтэй туслах бөгөөд хэзээ ч нууц мэдээлэл дэлгэж болохгүй" гэсэн системийг чиглүүлэх prompt-ийг (System prompt) аюулгүй байдлын хамгаалалт гэж андуурах. Ухаалаг халдагч (Attacker) үүнийг маш амархан давж гарна (Jailbreak). Аюулгүй байдал нь архитектурын түвшинд хэрэгжих ёстой.
• Хяналт, мониторингийг орхигдуулах (Blackbox хэлбэрээр орхих): Уламжлалт лог нь зөвхөн хэдэн удаа API дуудсан, хэдий хэр хугацаа зарцуулсан зэргийг бүртгэдэг. AI системд ямар асуулт орж, ямар хариулт гарсан, хариултын итгэлцүүр (confidence score) хэд байсан зэрэг AI-д зориулсан нарийвчилсан мониторинг хийхгүй байх нь алдаа илрүүлэх үйл явцыг боломжгүй болгодог.
• AI үйлчилгээний хандалтын эрхийг хэтрүүлэх: AI агентад шаардлагатайгаас илүү өргөн эрх (over-privileged) олгох. Жишээлбэл, мэдээлэл хайх зориулалттай агентад өгөгдлийн санд бичих (Write) эсвэл устгах (Delete) эрхтэй API түлхүүр өгөх нь маш аюултай.

Дүгнэлт

Байгууллагууд хиймэл оюуны бодит үнэ цэнийг хүртэхийн тулд аюулгүй байдлыг хөгжүүлэлтийн дараа бус, загварчлалын шатанд (Secure by Design) шингээх шаардлагатай. Google SAIF нь энэхүү шилжилтийг системтэйгээр хийхэд тусална. Танай инженерийн болон аюулгүй байдлын баг дараах алхмуудыг эхлүүлж болно:

• AI Хөрөнгийн бүртгэл үүсгэх: Яг одоо байгууллага дотор хаана, ямар AI загвар, API болон гуравдагч талын LLM ашиглагдаж байгааг тодорхойлж, бүртгэлжүүлэх.
• Архитектуртаа Guardrails нэвтрүүлэх үнэлгээ хийх: Одоо ажиллаж байгаа AI системүүдийнхээ оролт, гаралтын цэгүүдэд шүүлтүүр байгаа эсэхийг шалгах. Байхгүй бол API Gateway болон LLM хооронд хамгаалалтын давхарга нэмэх төлөвлөгөө гаргах.
• RAG системийн эрхийг шалгах: Хэрэв вектор өгөгдлийн сан ашиглаж байгаа бол, баримт бичгүүдийн хандалтын хяналт (ACL) нь хэрэглэгчийн үндсэн IAM-тай хэрхэн уялдаж байгааг архитектурын түвшинд дахин нягтлах.
• AI эрсдэлийн загварчлал (Threat modeling) хийх: Уламжлалт програмын загварчлал дээр нэмээд Prompt Injection, Data Poisoning зэрэг AI халдлагуудын хувилбаруудыг оруулж, системийн эмзэг байдлыг үнэлэх.