โมเดลที่ดีที่สุดของคุณอยู่บน Cloud แต่ข้อมูลที่ดีที่สุดของคุณไปที่นั่นไม่ได้

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

มีสองทาง คือ แพลตฟอร์ม AI ของคุณเรียกใช้โมเดลภายนอกได้ หรือเรียกไม่ได้

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

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

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

ประเภทข้อมูลของคุณไม่ได้เหมือนกันทั้งหมด แต่กติกาที่คุณเขียนกลับเหมือนกันทั้งหมด

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

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

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

กรณีที่น่าสนใจคือกรณีสุดท้าย และเป็นจุดที่ระบบส่วนใหญ่ล้มเหลวอย่างเงียบ ๆ

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

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

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

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

นี่ไม่ใช่โมเดลที่คุณต้องเทรน และไม่ใช่ Rule Engine ที่คุณต้องเขียน Infozense Knowledge Engineering ส่งมอบเลเยอร์ข้อมูลที่มี Governance พร้อม Egress Gate ติดตั้งไว้แล้ว คุณกำหนด Classification ให้ความรู้ของคุณ แล้วจับคู่ระดับความอ่อนไหวแต่ละระดับเข้ากับปลายทางเพียงครั้งเดียว จากนั้นทุกคำขอจะถูก Route ไปยังปลายทางที่ Classification ของคำขอนั้นกำหนดไว้ สิ่งที่เข้มที่สุดในคำขอเป็นตัวตัดสิน เนื้อหาที่ไม่ได้ติด Classification ถูกถือว่าจำกัดที่สุด และปลายทางจะปฏิเสธทุกอย่างที่เกินเพดานของมัน ไม่ว่าการจับคู่ที่ตั้งไว้จะบอกว่าอย่างไร

โมเดลที่ดีที่สุดของคุณยังใช้ได้อยู่ ข้อมูลที่ออกไปไม่ได้ก็ไม่ออกไปไหน และไม่มีใครต้องเลือกอีก