/trust · data boundary

รู้ว่าข้อมูลไปที่ไหน และใครดูแลระบบของคุณ

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

ขอทบทวนขอบเขตสถาปัตยกรรม ดูขอบเขตการดูแลระบบ

Data boundary — ระบุเส้นทางให้ชัด

ค่าเริ่มต้นที่เสนอคือเก็บ business payload ไว้ในสภาพแวดล้อมของลูกค้า ข้อยกเว้นทุกอย่างต้องระบุ ขออนุมัติ และบันทึกตาม deployment นั้น

Data boundary — ระบุเส้นทางให้ชัด
ข้อมูลหรือกิจกรรม	ตำแหน่งเริ่มต้นที่เสนอ	เงื่อนไขที่ต้องตกลง
ภาพ เอกสาร prompt และคำตอบ	ภายในระบบของลูกค้า	Connector ภายนอกหรือ cloud ต้องระบุเป็นข้อยกเว้น
Application log และ audit log	ภายในขอบเขต logging ของลูกค้า	กำหนด redaction, retention และผู้มีสิทธิ์อ่าน
Health metrics และ telemetry	ภายในขอบเขต monitoring ของลูกค้า	ส่งออกได้เฉพาะ field ที่อนุมัติ
Package และ model update	ช่องทางที่อนุมัติหรือ offline import	กำหนด connected update, checksum และทาง rollback
Support session และ remote access	ปิดไว้จนกว่าลูกค้าจะอนุมัติ	ผู้อนุมัติ, least privilege, วันหมดอายุ และ audit record
Backup และ restore artefact	ตำแหน่งที่ระบุในขอบเขตส่งมอบ	กำหนด encryption, retention, restore test และผู้รับผิดชอบค่าใช้จ่าย

ตัวอย่างสาธารณะจะไม่ใส่ IP, hostname, credential, รายละเอียดช่องโหว่ หรือแผนผังลูกค้าที่ไม่ได้รับอนุญาตจริง

Deployment แต่ละแบบมี outbound path ต่างกัน

Offline, connected on-premise และ hybrid เป็นทางเลือกคนละแบบ สถานะของแต่ละแบบจะแยกเป็น proposed, tested หรือ supported; หลักฐานของแบบหนึ่งไม่ครอบคลุมอีกแบบโดยอัตโนมัติ

Offline inference

proposed

Inference ทำงานได้โดยไม่เรียก external API ระหว่าง workflow เมื่อ model, runtime และ dependency ติดตั้งไว้ในระบบแล้ว

ยังต้องวางแผน installation, offline update, backup และ support ที่อนุมัติแยกกัน

Connected on-premise

tested

ประมวลผลในองค์กร โดยอาจมี connection แบบควบคุมเพื่อ package update, health signal ที่อนุมัติ หรือ remote assistance

ต้องทดสอบและบันทึกปลายทาง field ผู้อนุมัติ retention และพฤติกรรมเมื่อเชื่อมต่อไม่ได้

Hybrid

supported

ผสาน component ในเครื่องกับภายนอกสำหรับ integration ที่ระบุ โดยบันทึก payload และความรับผิดชอบแยกตาม flow

Hybrid ไม่ใช่ fully local: payload เหตุผล dependency และ fallback ภายนอกต้องมี owner ที่ตกลง

Access, operations และ component controls

สิ่งเหล่านี้เป็นการตัดสินใจด้าน configuration และสัญญาที่ต้องตรวจใน deployment ไม่ใช่คำกล่าวว่าทุกโครงการมี control เหมือนกัน

ผู้อนุมัติและสิทธิ์เข้าถึง

ระบุผู้อนุมัติฝั่งลูกค้า role สิทธิ์แบบ least privilege และเหตุผลทางธุรกิจก่อน operator หรือทีม support เข้าระบบ

Access configuration และ approval record

อายุ session และการเพิกถอน

กำหนดเวลาของ support session บันทึกเวลาเริ่ม/จบ และเพิกถอนสิทธิ์เมื่อหมดช่วงอนุมัติหรืองานจบ

Session log, expiry และ revocation check

Backup, restore และ rollback

กำหนดสิ่งที่ backup ผู้มีสิทธิ์ restore วิธีเลือก rollback trigger และ RTO/RPO หรือข้อยกเว้นที่ตกลง

Restore test และ rollback runbook

Ownership และ handover

แยก business data, custom code, model artefact, configuration, operations และ acceptance แล้วบันทึก handover ไม่ถือว่าเป็นของใครโดยอัตโนมัติ

Delivery inventory และ receiving owner

Component และ model licence

บันทึก source, version, licence, ข้อจำกัดการใช้งาน และทางเปลี่ยนของ third-party code, runtime, model และ weight

Component/model inventory และ licence notices

Limitations และ dependency

เปิดเผย mode ที่ยังไม่ทดสอบ คุณภาพ label, hardware, network, safety และ third-party dependency จนกว่าจะมีหลักฐานหรือมติในสัญญา

Risk register พร้อม owner และ review date

Shared responsibility เป็นส่วนหนึ่งของ design

ลูกค้ารับผิดชอบวัตถุประสงค์ทางธุรกิจ การใช้ข้อมูลอย่างถูกต้องตามกฎหมาย การอนุมัติ access การรับรองการใช้งาน และการตัดสินใจหยุดหรือเปลี่ยน workflow
ทีมส่งมอบบันทึก architecture ที่ตกลง redact ตัวอย่าง ทำตาม boundary ที่อนุมัติ และรายงานหลักฐานกับข้อจำกัด
เจ้าของ cloud, network, hardware และ component ภายนอกยังรับผิดชอบส่วนที่ระบุในเงื่อนไขของตน ไม่ได้โอนมาให้เราโดยปริยาย
Remote support เป็นทางเลือกและมีเวลา ลูกค้าเพิกถอนได้ และ session record เก็บตามนโยบายที่ตกลง
การ sign-off ด้าน security, privacy และ safety ต้องทำโดย owner ที่องค์กรแต่งตั้ง เราช่วยเตรียม input และหลักฐานการพัฒนา

Assumptions ที่ต้องปิดก่อน sign-off

Architecture และ network test ต้องเฉพาะ deployment นั้น diagram หรือ test จากหน้างานอื่นไม่ใช่หลักฐานแทน
Telemetry อาจมีบริบทอ่อนไหวแม้ไม่ใช่ business payload จึงต้องมี owner ของ field และ retention
Local inference อาจลด dependency ต่อ API แต่ยังมีต้นทุนเครื่อง ไฟฟ้า maintenance licence update และการเปลี่ยนอุปกรณ์
หน้านี้ไม่กล่าวว่า certified, compliant, invulnerable, zero egress หรือ zero lock-in หากไม่มี control และหลักฐานที่ระบุชัด

คำถามเรื่อง Trust ที่เราตอบก่อนเริ่ม workshop

Local AI แปลว่าข้อมูลไม่มีทางออกนอกองค์กรเลยหรือไม่

ขึ้นกับการติดตั้งและ integration เราจะทำแผน business payload, log, telemetry, update และ support ก่อนยืนยันขอบเขต

ลูกค้าได้ source code และ model artefact ทั้งหมดหรือไม่

Delivery inventory จะแยก custom code, third-party component, model artefact และ configuration สิทธิ์กับ licence ต้องตกลงเป็นรายการ

รัน model ในเครื่องแล้วไม่มีค่าใช้จ่ายต่อการใช้เลยหรือไม่

อาจไม่เสียค่า API token สำหรับ inference แต่ยังมีค่าเครื่อง ไฟฟ้า maintenance licence update และ replacement ที่ต้องมี owner กับงบ

ข้อมูลลูกค้าจะถูกนำไปฝึก model กลางหรือไม่

ค่าเริ่มต้นที่เสนอคือไม่ใช้ หากต้องการวัตถุประสงค์อื่นต้องกำหนด purpose, permission และ contract boundary แยก ไม่ถือว่าอนุญาตโดยปริยาย

ทบทวนขอบเขตข้อมูลก่อนเลือกวิธีพัฒนา

เตรียม workflow, ประเภทข้อมูล, ระบบเดิม, ผู้อนุมัติ access และ decision owner เราจะเริ่มจากการคุยด้าน architecture หรือ operations ตามขอบเขต และเชื่อมเอกสารกฎหมายที่ใช้กำกับงาน

ขอ workshop ด้าน SA ดูขอบเขต MA operations อ่านข้อกำหนดความปลอดภัย อ่านนโยบายความเป็นส่วนตัว

Review metadata: โครงสร้างเนื้อหา proposed; control, owner และ review date ของ deployment จริงต้องยืนยันใน architecture pack หรือสัญญา