ซีน แบลนช์ฟิลด์ ผู้ร่วมก่อตั้งและซีอีโอของ Jentic – สัมภาษณ์ซีรีส์

ซีน แบลนช์ฟิลด์ ผู้ร่วมก่อตั้งและซีอีโอของ Jentic เป็นนักธุรกิจด้านเทคโนโลยีที่มีประสบการณ์หลายทศวรรษในการสร้างบริษัทซอฟต์แวร์และโครงสร้างพื้นฐานขนาดใหญ่ ซึ่งมีสำนักงานใหญ่อยู่ที่ดับลิน ปัจจุบันเขานำทีม Jentic และยังเป็นสมาชิกของสภาที่ปรึกษาด้านปัญญาประดิษฐ์ของไอร์แลนด์ โดยให้คำแนะนำรัฐบาลเกี่ยวกับนโยบายปัญญาประดิษฐ์ ในช่วงแรกของอาชีพการงาน เขาได้ร่วมก่อตั้ง DemonWare ซึ่งเป็นแพลตฟอร์มบริการออนไลน์ขนาดใหญ่สำหรับผู้จัดพิมพ์เกมวิดีโอชื่อดัง ซึ่งต่อมาได้ถูกซื้อกิจการโดย Activision Blizzard (ATVI ) และ PageFair ซึ่งเป็นสตาร์ทอัพที่ได้รับการสนับสนุนจากผู้ลงทุน ซึ่งมุ่งเน้นไปที่การวิเคราะห์ปัญหาการปิดโฆษณา ซึ่งต่อมาได้ถูกซื้อกิจการโดย Blockthrough เขายังเป็นผู้ร่วมก่อตั้งหรือเป็นผู้นำสตาร์ทอัพหลายแห่ง และยังคงสนับสนุนระบบนิเวศสตาร์ทอัพของไอร์แลนด์ผ่านโครงการต่างๆ เช่น Techpreneurs

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

คุณได้ก่อตั้งและนำทีมบริษัทเทคโนโลยีหลายแห่ง ตั้งแต่ DemonWare (ซึ่งถูกซื้อกิจการโดย Activision Blizzard) ไปจนถึง PageFair และ Jentic ในขณะเดียวกันคุณยังเป็นสมาชิกของสภาที่ปรึกษาด้านปัญญาประดิษฐ์ของไอร์แลนด์ อะไรที่ดึงดูดคุณให้กลับมาพัฒนาโครงสร้างพื้นฐานอีกครั้งกับ Jentic และคุณเห็นช่องว่างใดในระบบนิเวศตัวแทนปัญญาประดิษฐ์ที่คนอื่นๆ ไม่เห็น

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

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

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

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

จุดบกพร่องนั้นง่ายมาก ตัวแทน – ระบบที่ทำงานพรอมต์จาก LLM – ยังเป็นระบบที่ถือครองสิ่งอำนวยความสะดวกและทำการเรียก API การประนีประนอมตัวแทนและคุณจะได้ทุกสิ่งที่มันสามารถทำได้ มันเป็นข้อผิดพลาดเดียวกับที่เราทำในยุคแรกๆ ของเว็บ – เซิร์ฟเวอร์應 dụngที่มีการเข้าถึงฐานข้อมูลแบบซูเปอร์ยูสเซอร์เพราะมันสะดวก Jentic นั่งอยู่ระหว่างตัวแทนและ API ที่พวกมันเรียก ตัวแทนไม่เคยถือครองสิ่งอำนวยความสะดวก มันจะออกคำขอผ่านชั้นการดำเนินการแบบจัดการของเรา ซึ่งจะฉีดสิ่งอำนวยความสะดวกแบบเซิร์ฟเวอร์-ไซด์ บังคับใช้นโยบาย และบันทึกการเรียกทุกครั้ง และเมื่อมีบางสิ่งผิดปกติ มี kill switch เดียว – การกระทำเดียวที่หยุดการเข้าถึงของตัวแทนไปยังระบบที่เชื่อมต่อทั้งหมดพร้อมๆ กัน

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

ในแบบจำลองแบบแบน LLM ตัดสินว่าจะทำอะไรและเรียก API โดยตรงโดยใช้สิ่งอำนวยความสะดวกที่ถือครอง เมื่อประนีประนอมชั้นการให้เหตุผล คุณควบคุมชั้นการดำเนินการ ด้วยการแยก LLM จะส่งความตั้งใจ – “เรียก API บิลлинก์ของ Stripe ด้วยพารามิเตอร์เหล่านี้” – ชั้นการดำเนินการแบบจัดการจะตรวจสอบคำขอนั้นเทียบกับนโยบาย ฉีดสิ่งอำนวยความสะดวกแบบเซิร์ฟเวอร์-ไซด์ และทำการเรียก API LLM ไม่เคยสัมผัสกับสิ่งอำนวยความสะดวก ในทางปฏิบัติ: การเคลื่อนไหวข้างๆ มันจะยากขึ้น พื้นที่การระเบิดถูกจำกัดโดยสิ่งที่ชั้นการดำเนินการอนุญาตให้ทำกับอัตลักษณ์ตัวแทนเฉพาะ และคุณจะได้ kill switch หนึ่งการกระทำและหยุดการเข้าถึงของตัวแทนไปยังระบบที่เชื่อมต่อทั้งหมด ตัวแทนยังคงถูกจัดการ – แต่การควบคุมไม่ได้หมายความถึงการประนีประนอมสิ่งอำนวยความสะดวกโดยอัตโนมัติ

ในระบบการผลิตองค์กรจริง การจัดการสิ่งอำนวยความสะดวกแบบจัดการและการเพิกถอนแบบทันทีเป็นอย่างไร และมันแตกต่างจากวิธีที่ทีมส่วนใหญ่จัดการกับ API คีย์และโทเค็นสำหรับตัวแทนอย่างไร

วันนี้ ทีมส่วนใหญ่มีนักพัฒนาที่ให้สิ่งอำนวยความสะดวก API เก็บไว้ในไฟล์ .env และโหลดไว้ที่ตัวแทนเริ่มต้น – บ่อยครั้งโดยตรงเข้าไปในหน้าต่างบริบทของ LLM ไม่มีใครมีภาพรวมที่สมบูรณ์ของตัวแทนใดที่ถือครองสิ่งอำนวยความสะดวกใด เมื่อบางคนออกไป คีย์ที่พวกเขาให้สิ่งอำนวยความสะดวกจะไม่หมุน เมื่อตัวแทนแสดงพฤติกรรมแปลกๆ ไม่มีเส้นทางการตรวจสอบเพื่อสร้างสิ่งที่เกิดขึ้น ด้วย Jentic นักพัฒนาจะไม่จัดการสิ่งอำนวยความสะดวกดิบ พวกเขาจะประกาศว่าตัวแทนใดต้องการการเข้าถึงอะไร แพลตฟอร์มจะให้สิ่งอำนวยความสะดวกที่มีวงจร และตัวแทนจะเรียกผ่านชั้นการดำเนินการโดยไม่เคยเห็นคีย์ข้างใต้เลย ซึ่งหมายความว่าคุณจะได้รับการเพิกถอนแบบทันทีสำหรับตัวแทนแต่ละตัว ความสามารถในการหยุดการเข้าถึงในขณะที่คุณตรวจสอบ และเส้นทางการตรวจสอบแบบมีไทม์สแตมป์ของการเรียก API ทุกครั้ง ความแตกต่างระหว่างสิ่งนี้และ “API คีย์ใน .env” นั้นสำคัญ

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

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

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

แทนที่จะเชื่อมต่อตัวแทนเข้ากับ API 50 ตัว – แต่ละตัวมีกลไกการรับรองความถูกต้อง อัตราการจำกัด และความพิเศษเฉพาะตัว – นักพัฒนาจะเชื่อมต่อกับจุดสิ้นสุดเดียว จุดสิ้นสุดนั้นเปิดเผยเครื่องมือในการค้นหาความสามารถ API ทั้งหมดในแค็ตตาล็อกของเรา โหลดรายละเอียด และดำเนินการเรียกใดๆ สิ่งนี้จะเพิ่มความยืดหยุ่นผ่านอินเทอร์เฟซที่เป็นเอกภาพสำหรับ API ที่ไม่สิ้นสุด ในขณะเดียวกันก็ช่วยให้การกำกับดูแล – ซึ่งตัวแทนที่เข้าถึง API ใด ภายใต้เงื่อนไขใด และด้วยข้อจำกัดใด – ทั้งหมดนี้จัดการในแพลตฟอร์ม ไม่ใช่ในโค้ดไคลเอ็นต์ ชั้นการดำเนินการเป็นเพียงการผ่านต่อ ตัวแทนยังคงสามารถสร้างการทำงานแบบหลายขั้นตอนได้ เชื่อมโยงการเรียก และจัดการข้อผิดพลาดได้อย่าง动态 การกำกับดูแลโดยไม่มีการเสียดสีคือเรื่องที่ยาก การตัดทางลัดคือการผลักภาระไปยังนักพัฒนा โครงสร้างพื้นฐานควรทำสิ่งที่ตรงกันข้าม – ดูดซับความซับซ้อนเพื่อให้นักพัฒนไม่ต้องทำ

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

แน่นอน – และตรรกะนั้นชัดเจน ไฟล์การกำหนดค่าตัวแทนเป็นคีย์บริการหลายตัวโดยพื้นฐาน – สิ่งอำนวยความสะดวกสำหรับระบบอีเมล ระบบ CRM ระบบบิลлинง์ API ภายใน และบัญชี GitHub การวิ่ง infostealer ที่ประสบความสำเร็จเพียงครั้งเดียวจะได้รับอนุญาตให้เข้าถึงระบบภายนอกทั้งหมดของบริษัทเป็นเวลาหลายเดือน นั่นคือผลตอบแทนที่สูงกว่าการโจมตีบริการใดๆ อย่างโดดเดี่ยว มิติอื่นคือตัวแทนการทำงานอย่างต่อเนื่องในระบบการผลิตเป็นสถานะที่มีเครดิตเชลล์และมีอยู่ตลอดเวลา – ไม่ใช่ผู้ใช้ที่เข้าระบบและออกจากระบบ การประนีประนอมตัวแทนสามารถทำหน้าที่เป็นจุดยึดที่ยาวนานได้ โดยการทำงานต่ำกว่าขีดการตรวจจับ นักโจมตีจะใช้โครงสร้างพื้นฐาน AI เป็นจุดสนใจใหม่ของการโจมตี Jentic สามารถลดพื้นที่การโจมตีเครดิตเชลล์ได้อย่างมาก แต่ไม่สามารถป้องกันไม่ให้ตัวแทนใช้ขอบเขตที่ได้รับอนุญาตในทางที่ผิดได้ ปัญหาที่ยากกว่านั้นต้องได้รับการแก้ไขที่ระดับโมเดล โดยมีการป้องกันและตรวจจับการฉีดพรอมต์

นอกเหนือจากเฟรมเวิร์กใดๆ แล้ว หลักการรักษาความปลอดภัยที่กว้างขึ้นใดที่องค์กรควรนำมาใช้หากต้องการใช้ AI แบบตัวแทนอย่างปลอดภัย

องค์กรที่มีการจัดการส่วนใหญ่ไม่สามารถใช้ระบบที่ไม่แน่นอนในกระบวนการทางธุรกิจที่มีค่ามากที่สุดได้ ธนาคารหรือบริษัทประกันไม่สามารถชี้ตัวแทนให้ระบบบิลлинง์ได้และบอกว่า “ไปค้นหาสิ่งนั้น” ดังนั้น คุณจะสร้างนวัตกรรมโดยไม่ทำให้การรักษาความปลอดภัยของคุณกลายเป็นเบรกหรือไม่ คำตอบคือการสร้างแบบจำลองเสมือน ซึ่งเป็นแบบจำลองดิจิทัลของอสังหาริมทรัพย์ API ของคุณ โดยมีโครงสร้างและกระบวนการทำงานเหมือนกัน แต่ไม่มีเครดิตเชลล์หรือผลที่ตามมาในการผลิต นำตัวแทนไปที่นั่น ให้พวกมันสำรวจ ดูสิ่งที่เกิดขึ้น เส้นทางที่ประสบความสำเร็จจะถูกจับเป็นกระบวนการทำงานอัตโนมัติที่มีโครงสร้างโดยใช้ Arazzo ซึ่งเป็นมาตรฐานการทำงานแบบเปิดที่พัฒนาโดย OpenAPI Initiative – สามารถตรวจสอบได้ ทำซ้ำได้ และทบทวนได้โดยทีมการปฏิบัติตามกฎระเบียบใดๆ สิ่งนี้หมายความว่าคุณสามารถเคลื่อนที่ด้วยความเร็ว AI ในแบบจำลองและเคลื่อนที่ด้วยความเร็วองค์กรในการผลิต และโหมดนั้นสามารถอยู่ร่วมกันได้ หลักการอื่นๆ ยังคงมีผลบังคับใช้ – สิทธิ์ที่น้อยที่สุด การตรวจสอบเส้นทาง การแยกออร์เคสตราและชั้นการดำเนินการ แต่แบบจำลองเสมือนคือคำตอบเชิงโครงสร้างสำหรับคำถามที่ทีมองค์กรต้องเผชิญจริงๆ – วิธีการทดลองกับ AI ที่ไม่แน่นอนโดยไม่ต้องเดิมพันการรักษาความปลอดภัยของคุณไปกับมัน คุณไม่ได้นำการไม่แน่นอนไปใช้ คุณดึงคุณค่าออกจากมันภายใต้เงื่อนไขที่ควบคุมได้ และนำเอาออกผลลัพธ์ที่แน่นอนไปใช้เท่านั้น

ขอขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านสามารถเรียนรู้เพิ่มเติมได้ที่ Jentic.