ความไว้วางใจ: รากฐานสำคัญของการนำเอไอไปใช้ — วิธีวัดผล ปรับปรุง และออกแบบเพื่อความไว้วางใจ

เพื่อเพิ่มความไว้วางใจในเอไอ อย่ามองหาระบบที่สมบูรณ์แบบเพียงระบบเดียว แต่จงผสานระบบที่ล้มเหลวในรูปแบบที่แตกต่างกัน

แนวคิดหลักของบทความนี้ได้นำเสนอครั้งแรกในการบรรยายเรื่อง “Beyond Quality: Measuring Trust in AI Outcomes” ในงาน Software Quality Days 2026 ณ กรุงเวียนนา

ดาวน์โหลด Trust Architecture Canvas เป็น แม่แบบ PDF

เราสามารถไว้วางใจเอไอได้หรือไม่? — คำถามพื้นฐานของการนำเอไอไปใช้ทั้งหมด

การอภิปรายทั้งหมดเกี่ยวกับเอไอท้ายที่สุดแล้วมักลงเอยด้วยคำถามเดียวกัน:

เราสามารถไว้วางใจเอไอได้หรือไม่?

ในบางกรณี ผู้คนกล่าวว่าพวกเขาไม่สามารถใช้งานได้อย่างเป็นทางการ เนื่องจากอยู่ในอุตสาหกรรมที่อยู่ภายใต้การกำกับดูแล ขณะที่บางคนกล่าวว่าพวกเขาได้ลองใช้เครื่องมือเอไอ เช่น Cursor หรือ GitHub Copilot และมันทำงานได้ดีมาก แต่ไม่ทางใดก็ทางหนึ่ง การอภิปรายทั้งหมดเหล่านั้นลงท้ายด้วยคำถามเดียว: “เราสามารถไว้วางใจเอไอได้หรือไม่?”

ความไว้วางใจมีอยู่ทุกหนแห่ง แต่ความไว้วางใจคืออะไร?

ลองนึกถึงรถเข็นช้อปปิ้ง 2 แบบ:

• แบบหนึ่ง มีโซ่คล้องเหรียญ ดังนั้นคุณต้องใส่เหรียญก่อนจึงจะใช้ได้
• อีกแบบหนึ่ง ไม่ต้องใช้อะไรเลย

ในกรณีแรก ดูเหมือนว่าซูเปอร์มาร์เก็ต ไม่ไว้วางใจ ว่าฉันจะนำรถเข็นไปคืนโดยไม่มีเงินมัดจำ

ในกรณีที่สอง ซูเปอร์มาร์เก็ต ไว้วางใจฉันมากพอ ว่าฉันจะนำรถเข็นไปคืนไว้ในที่ที่ถูกต้อง และจะไม่สร้างความไม่สะดวกให้กับผู้ขับขี่รายอื่น

นี่เป็นตัวอย่างเล็กๆ แต่แสดงให้เห็นว่าระบบต่างๆ ถ่ายทอดความไว้วางใจไปยังผู้มีส่วนได้ส่วนเสียของตนอย่างไร — เช่น ฉันไปซื้อของประจำสัปดาห์ที่ซูเปอร์มาร์เก็ตแห่งหนึ่งหรืออีกแห่งหนึ่ง

ความไว้วางใจเป็นแบบค่อยเป็นค่อยไป เป็นเรื่องเชิงอัตวิสัย และขึ้นอยู่กับบริบท

สิ่งเหล่านี้คือคุณสมบัติพื้นฐานของความไว้วางใจ

• ความไว้วางใจไม่ใช่แบบมีหรือไม่มี แต่เป็น ระดับของบางสิ่ง
• ความไว้วางใจไม่ใช่คุณสมบัติที่มีอยู่โดยเนื้อแท้ของระบบ แต่เป็นเรื่องที่ใครบางคนไว้วางใจบางสิ่ง เพื่อวัตถุประสงค์เฉพาะ ภายใต้ บริบทเฉพาะ

เหตุใดเราจึงใช้ความไว้วางใจเพื่อเสริมคุณภาพ

เราใช้ความไว้วางใจเนื่องจากข้อจำกัดตามธรรมชาติในโดเมนการดำเนินงาน; เราใช้ความไว้วางใจเพื่อการตัดสินใจที่รวดเร็วยิ่งขึ้นเมื่อมีข้อมูลจำกัด.

ตัวชี้วัดคุณภาพเริ่มใช้ไม่ได้เมื่อโดเมนมีความซับซ้อนมากเกินไป

สำหรับโดเมนธุรกิจที่มีความซับซ้อนไม่มาก ต้นทุนของการวัดผลอยู่ในระดับที่ยอมรับได้ ดังนั้นเราจึงสามารถใช้ ตัวชี้วัดคุณภาพแบบคลาสสิก ได้ เมื่อความซับซ้อนของโดเมนเพิ่มขึ้น การวัดผลแบบคลาสสิกจะมีต้นทุนสูงเกินไป

ณ จุดนี้ เรามีทางเลือก เราสามารถพยายามต่อไปเพื่อยึดการตัดสินใจไว้กับตัวชี้วัดเชิงปริมาณที่เป็นรูปธรรมเท่านั้น หรือเราสามารถใช้สิ่งที่เราจัดกลุ่มไว้ภายใต้ กรอบความไว้วางใจ: การรับรู้ หลักฐานทางสังคม ความน่าจะเป็น และตัวแทนอื่นๆ

ความมั่นคงปลอดภัยไซเบอร์แสดงให้เห็นว่าคุณภาพเปลี่ยนเป็นความไว้วางใจได้อย่างไร

เมื่อทศวรรษก่อน ความมั่นคงปลอดภัยไซเบอร์ ค่อนข้างง่ายต่อการกำหนดเชิงปริมาณและการวัดผล: เวลาในการโจมตีแบบบรูตฟอร์ซ การควบคุมภายในพื้นฐาน…

ตั้งแต่ปี 2024 เป็นต้นมา เวกเตอร์การโจมตีได้เปลี่ยนไป และเราเริ่มกล่าวถึงความจำเป็นในการวิเคราะห์บุคคลที่สามในห่วงโซ่อุปทานมากขึ้นอย่างมาก

เรายังคงวัดคุณภาพของการควบคุมความมั่นคงปลอดภัยไซเบอร์อยู่หรือไม่ หรือเรากำลังวัดความไว้วางใจมากขึ้นเรื่อย ๆ?

การประเมินช่องโหว่ของบุคคลที่สามโดยทั่วไปมุ่งเน้นไปที่การพึ่งพา ตัวชี้วัดความไว้วางใจ ที่คู่ค้าแสดงให้เห็น มากกว่าตัวชี้วัดคุณภาพและความปลอดภัยที่เป็นรูปธรรม

มนุษย์และเอไอต่างก็เปราะบางได้

ที่นี่คุณจะเห็นภาพลวงตา Munker–White

ภาพลวงตานี้แสดงให้เห็นว่าสี 2 สีสามารถเหมือนกันอย่างเป็นรูปธรรม แต่เรายังคงมองเห็นว่าแตกต่างกัน นี่เป็นเพียงตัวอย่างหนึ่งของวิธีที่ในฐานะมนุษย์ เราสามารถถูกหลอกได้

มนุษย์ไม่ใช่มาตรฐานอ้างอิงที่สมบูรณ์แบบ เราก็ผิดพลาดได้เช่นกัน และเราก็ต้องมีการควบคุมกำกับการตัดสินของเราเช่นกัน

เอไอก็สามารถถูกหลอกได้เช่นกัน

สำหรับเอไอ ตัวอย่างคลาสสิกคือการถามเกี่ยวกับวิธีการไปที่คาร์วอช

เอไออาจตอบคำถามตามตัวอักษรและแนะนำให้เดินไป

คำถามที่เป็นจริงไม่ใช่ “เชื่อถือหรือไม่เชื่อถือ” แต่คือ ระบบนี้พังตรงไหน?

เราวัดความไว้วางใจอย่างไร?

ตัวเลขความไว้วางใจแบบสัมบูรณ์อาจไม่ค่อยมีความหมายมากนัก (เนื่องจากเราไม่มีหน่วยวัดความไว้วางใจที่แท้จริง) แต่ตัวเลขแบบสัมพัทธ์มีประโยชน์มากกว่า

การทำความเข้าใจว่าความไว้วางใจสูงหรือต่ำกว่าในการตั้งค่าหนึ่งเมื่อเทียบกับอีกการตั้งค่าหนึ่งเป็นสิ่งที่มีประโยชน์ ซึ่งช่วยให้เราเปรียบเทียบระบบและอธิบายการตัดสินใจได้

ตัวชี้วัดความไว้วางใจช่วยให้เราสื่อสารกับผู้มีส่วนได้ส่วนเสียได้ แทนที่จะกล่าวว่า “ฉันรู้สึกว่ามันใช้งานได้” เราสามารถอธิบายได้ว่าทำไมการตั้งค่า AI บางแบบจึงเป็นที่ยอมรับ หรือเหตุใดจึงจำเป็นต้องมีการควบคุมเพิ่มเติม

เราจะปรับปรุงความไว้วางใจได้อย่างไร?

กรอบแนวทางเชิงปฏิบัติของฉันประกอบด้วย 3 ระดับ:

• ระดับที่ 1: ความไว้วางใจส่วนบุคคล
• ระดับที่ 2: ความไว้วางใจเชิงระบบ
• ระดับที่ 3: ความไว้วางใจเชิงสถาปัตยกรรม

ระดับที่ 1: ความไว้วางใจส่วนบุคคล

ความไว้วางใจส่วนบุคคลเป็นเรื่องที่เกิดขึ้นโดยสัญชาตญาณ คุณจะมีความเข้าใจของตนเองว่าคุณสามารถไว้วางใจระบบได้หรือไม่

สำหรับเอไอ หมายถึงการลงมือใช้งานจริง คุณทดสอบมัน มอบหมายงานให้มัน ดูว่ามันล้มเหลวตรงไหน

การทำให้ความไว้วางใจเป็นตัวเลขและการวัดผล

• ตัวชี้วัดหนึ่งคือ เวลาที่คุณใช้ในการเขียนพรอมป์ต์
• อีกตัวหนึ่งคือ เวลาที่คุณใช้ในการแก้ไข ผลลัพธ์

หากคุณใช้เวลาเป็นจำนวนมากในการเขียนพรอมป์ต์หรือซ่อมแซมผลลัพธ์ นั่นบอกบางอย่างเกี่ยวกับระดับความไว้วางใจที่แท้จริงของคุณ

แผนปฏิบัติการ

• ทดสอบเอไอในงานของคุณเอง
• สังเกตว่ามันช่วยตรงไหน ล้มเหลวตรงไหน และคุณต้องใช้ความพยายามมากเพียงใดเพื่อทำให้ผลลัพธ์ใช้งานได้

ระดับ 2: ความไว้วางใจเชิงระบบ

ในระดับเชิงระบบ เราจะก้าวจากประสบการณ์ส่วนบุคคลไปสู่การขยายผลในวงกว้าง ไม่ใช่เพียง “ฉันรู้ว่าเอไอพังตรงไหน” แต่คือ: มาทำให้สิ่งนี้ขยายผลได้และทดสอบสำหรับโดเมนเฉพาะหรือกลุ่มงานเฉพาะ

โดยพื้นฐานแล้ว เราทำสิ่งเดียวกันกับในระดับ 1 แต่ตอนนี้มีกรณีมากขึ้น มีโครงสร้างมากขึ้น และมีสถิติมากขึ้น

วิธีการทำให้ความไว้วางใจเป็นเชิงปริมาณและวัดผล

• ตัวแทนของความไว้วางใจจะกลายเป็น ความน่าจะเป็นของผลลัพธ์ที่ถูกต้อง

คุณคำนวณโดยนำจำนวนผลลัพธ์ที่ถูกต้องหารด้วยจำนวนกรณีทั้งหมด และเพิ่มช่วงความเชื่อมั่นตามจำนวนกรณีทดสอบ

แผนปฏิบัติการ

• ใช้เกณฑ์มาตรฐานสาธารณะเมื่อเหมาะสม
• ใช้ชุดข้อมูลของคุณเองสำหรับโดเมนเฉพาะ

เพิ่มการสุ่มตัวอย่างและการทบทวนโดยมนุษย์เพื่อทำความเข้าใจว่าผลลัพธ์เชิงสถิติสอดคล้องกับความต้องการจริงของโดเมนของคุณหรือไม่

ระดับที่สาม: ความไว้วางใจเชิงสถาปัตยกรรม

ในระดับสถาปัตยกรรม คำถามเปลี่ยนไปอีกครั้ง เราไม่ได้ไว้วางใจเอไอ 100% และน่าจะไม่มีวันเป็นเช่นนั้น แต่:

เราสามารถสร้างสิ่งที่น่าเชื่อถือได้หรือไม่ โดยใช้ระบบที่เราไม่ได้ไว้วางใจ 100%?

คำตอบคือ “ได้” อินเทอร์เน็ตเป็นตัวอย่างหนึ่ง: เครือข่ายทางกายภาพไม่ใช่สิ่งที่เราสามารถไว้วางใจได้ 100% แต่ไม่ทางใดก็ทางหนึ่ง เราก็สามารถสร้างอินเทอร์เน็ตขึ้นบนเครือข่ายเหล่านั้นได้

การกำหนดปริมาณและการวัดความไว้วางใจ

แรกเริ่ม คุณวัดว่าระบบแต่ละระบบทำงานได้ดีเพียงใดแยกจากกัน จากนั้นคุณวัดว่าพวกมันทำงานร่วมกันได้ดีเพียงใด

• ตัวชี้วัดสำคัญคืออัตราความล้มเหลวร่วมกัน: กรณีที่ทุกระบบล้มเหลวพร้อมกัน

แผนปฏิบัติการ

• ระบุระบบหลักในกระบวนการ: เอไอ มนุษย์ นโยบาย การตรวจสอบความถูกต้อง การควบคุม
• วัดระดับความไว้วางใจของแต่ละระบบเป็นรายบุคคล
• ทดสอบสถาปัตยกรรมทั้งหมดเพื่อดูว่าระบบที่รวมกันให้ระดับความไว้วางใจสูงกว่าส่วนประกอบแต่ละส่วนเพียงลำพังหรือไม่

เพิ่มความไว้วางใจด้วยการผสานระบบที่ล้มเหลวในรูปแบบที่แตกต่างกัน

ความไว้วางใจโดยรวมขึ้นอยู่กับวิธีที่ระบบล้มเหลวร่วมกัน

หากเรามีระบบ A และระบบ B ซึ่งแต่ละระบบมีระดับความไว้วางใจของตนเอง จะเกิดอะไรขึ้นเมื่อเรานำมารวมกัน?

• เราไม่สามารถเพียงแค่นำระดับความไว้วางใจมารวมกันได้ เพราะเช่นนั้นอาจทำให้เกิน 100%
• เราไม่สามารถเพียงแค่ใช้ค่าต่ำสุดหรือค่าสูงสุดได้เช่นกัน

คำตอบขึ้นอยู่กับวิธีการออกแบบระบบและวิธีที่ระบบล้มเหลวร่วมกัน

การวิเคราะห์ร่วมแสดงระดับความเชื่อถือที่ผสานรวมกัน

เพื่อทำความเข้าใจความเชื่อถือที่ผสานรวมกัน เราจำเป็นต้องใช้การวิเคราะห์ร่วม เราทดสอบระบบ A และระบบ B แยกกัน จากนั้นเรายังพิจารณาด้วยว่าระบบทั้งสองมีพฤติกรรมอย่างไรในกรณีเดียวกัน

ตัวอย่างเช่น ระบบ A มีความเชื่อถือ 84% และระบบ B มีความเชื่อถือ 91% แต่เมื่อเราผสานรวมทั้งสองเข้าด้วยกัน ความเชื่อถือโดยรวมจะเป็น 95% เนื่องจากอัตราความล้มเหลวร่วมมีเพียง 5% ระบบทั้งสองไม่ได้ล้มเหลวในกรณีเดียวกันเสมอไป และนี่คือส่วนที่สำคัญ

สถาปัตยกรรมที่น่าเชื่อถือใช้ตาข่ายความปลอดภัยที่ซ้อนทับกัน

ในวิศวกรรมซอฟต์แวร์ การทบทวนโดยเพื่อนร่วมงานทำงานในลักษณะเดียวกัน บุคคลอื่นอาจตรวจพบสิ่งที่คุณยังไม่ได้จับประเด็นไว้

ในอุตสาหกรรมการบิน เราก็เห็นการมีระบบสำรองในส่วนของการควบคุมและขั้นตอนปฏิบัติด้วยเช่นกัน

การทำซ้ำการควบคุมเพียงอย่างเดียวจะไม่เพิ่มความไว้วางใจได้มากนัก สิ่งที่เรามองหาคือ ความซ้ำซ้อนที่หลากหลาย: การประสานระบบที่ล้มเหลวในรูปแบบที่แตกต่างกัน

ไม่ใช่ว่าความซ้ำซ้อนทุกอย่างจะเป็นไปได้จริง

ความซ้ำซ้อนบางอย่างมีประโยชน์ในทางทฤษฎี แต่ไม่เป็นไปได้จริง ตัวอย่างเช่น ในบริการแท็กซี่ เราอาจเพิ่มคนขับคนที่ 2 และมีความเป็นไปได้ว่าบริการจะปลอดภัยยิ่งขึ้น แต่สิ่งนี้ไม่เป็นไปได้จริง

ดังนั้น แทนที่จะทำเช่นนั้น เราจึงสร้างเครือข่ายของระบบที่แตกต่างกัน ได้แก่ กฎระเบียบ นโยบาย การให้คะแนนคนขับ การควบคุมผ่านแอป และกลไกการรายงาน ระบบทั้งหมดนี้ผสานรวมกันและมีส่วนช่วยต่อระดับความไว้วางใจโดยรวม

มนุษย์ในวงจรเป็นระบบความน่าเชื่อถืออีกระบบหนึ่ง

เราสามารถมองว่า มนุษย์ในวงจรเป็นระบบความน่าเชื่อถืออีกระบบหนึ่ง มนุษย์นำสัญชาตญาณและสามัญสำนึกมาใช้ และหลักการของมนุษย์แตกต่างจากระบบเอไอ ซึ่งทำให้มนุษย์เป็นปัจจัยด้านความน่าเชื่อถือที่เหมาะสมอย่างยิ่ง

สถาปัตยกรรมสำคัญกว่าคะแนนความน่าเชื่อถือรายบุคคล

ระบบที่แข็งแกร่ง 2 ระบบยังคงอาจล้มเหลวร่วมกันได้ หากล้มเหลวในลักษณะเดียวกัน

ในขณะเดียวกัน ระบบที่ไม่สมบูรณ์ 2 ระบบสามารถสร้างระบบรวมที่แข็งแกร่งกว่าได้ หากชดเชยข้อบกพร่องซึ่งกันและกัน ดังนั้นคำถามหลักในการออกแบบคือ: ระบบเหล่านี้พังในลักษณะที่แตกต่างกันหรือไม่?

เราเพิ่งคิดค้นความน่าเชื่อถือขึ้นมาใหม่หรือไม่?

ไม่เชิง

ความน่าเชื่อถือเป็นส่วนหนึ่งของความไว้วางใจ แต่ความไว้วางใจครอบคลุมแนวคิดที่กว้างกว่า เราไม่ได้เพียงถามว่าส่วนประกอบหนึ่งทำงานได้หรือไม่ — เรากำลังพิจารณาทั้งกระบวนการตัดสินใจทั้งหมด: เอไอ มนุษย์ นโยบาย การควบคุม และบริบททางธุรกิจ

ความไว้วางใจยังเกี่ยวข้องกับผู้มีส่วนได้ส่วนเสียมากขึ้น: ผู้ใช้ ผู้จัดการ หน่วยงานกำกับดูแล เจ้าของธุรกิจ มนุษย์ที่อยู่ในกระบวนการ และผู้ที่ได้รับผลกระทบจากการตัดสินใจ

ประเด็นสำคัญ

เอไอที่น่าเชื่อถือไม่ใช่การค้นหาโมเดลเอไอที่สมบูรณ์แบบเพียงหนึ่งเดียว ทุกระบบสามารถถูกทำให้เสียหายได้ รวมถึงระบบเอไอ ระบบมนุษย์ ระบบธุรกิจ นโยบาย และการควบคุม

แนวคิดคือ:

1. ทำความเข้าใจว่าระบบล้มเหลวได้อย่างไร แล้ว
2. ผสานระบบที่ล้มเหลวในรูปแบบที่แตกต่างกัน

นี่คือวิธีที่จะไปสู่สิ่งที่น่าเชื่อถือได้

Alexis Savkín

Alexis Savkin เป็นสถาปนิกด้านยุทธศาสตร์และผู้ก่อตั้ง BSC Designer ซึ่งเป็นแพลตฟอร์มซอฟต์แวร์สำหรับการดำเนินการตามยุทธศาสตร์ โดยมี บาลานซ์ สกอร์การ์ด เป็นแกนหลัก เขาช่วยให้องค์กรต่าง ๆ แปลงยุทธศาสตร์ให้เป็นวัตถุประสงค์ที่วัดผลได้ KPI และโครงการ Alexis เป็นผู้สร้าง Strategy Execution Canvas เป็นผู้เขียนบทความมากกว่า 100 บทความเกี่ยวกับยุทธศาสตร์และการวัดผลการดำเนินงาน และเป็น วิทยากรประจำ