Part 2 · หัวใจและปรัชญาของ Oracle

บทที่ 16: ไม่มีอะไรถูกลบ: ประวัติคือทุน ไม่ใช่ขยะ

บทสั้นสำหรับมือใหม่ใน Part 2: หัวใจและปรัชญาของ Oracle

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

สามเรื่องที่ควรจำ

  1. รักษาเหตุผลและประวัติรุ่น ไม่ใช่เก็บข้อมูลดิบทุกชิ้นตลอดไป

    ประเด็นจากหัวข้อ “สามเรื่องที่ควรจำ”

  2. กำหนดอายุ สิทธิ์เข้าถึง และวิธีลบตั้งแต่ก่อนเก็บ

    ประเด็นจากหัวข้อ “สามเรื่องที่ควรจำ”

  3. เมื่อความเป็นส่วนตัวกำหนดให้ลบ ต้องลบ; Framework ไม่ใช่ข้อยกเว้น

    ประเด็นจากหัวข้อ “สามเรื่องที่ควรจำ”

สรุปแก่นของบทที่ 16 เป็นจุดสังเกตที่กลับมาทบทวนได้รวดเร็ว

ผลลัพธ์ของบทนี้

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

สถานการณ์ใกล้ตัว

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

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

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

ศัพท์ใหม่ในบทนี้

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

ภาพเปรียบเทียบและขอบเขตของภาพ

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

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

แก่นของเรื่องแบบเป็นชั้น

ชั้นแรก เลือกสิ่งที่ต้องรักษาไว้เพื่อความต่อเนื่อง เช่น เหตุผลของการเปลี่ยนนโยบาย วันที่ ผู้อนุมัติ และผลที่ต้องทบทวน

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

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

ชั้นที่สี่ เมื่อข้อมูลเปลี่ยน ให้เพิ่มรุ่นใหม่พร้อมบันทึกว่า supersede หรือแทนที่รุ่นใด แต่อย่านำชื่อคำสั่งเก่าที่ไม่ยืนยันมาใช้เป็นบทเรียนปฏิบัติ หลักคิดสำคัญกว่าคำสั่งใน snapshot หนึ่ง

หยุดก่อน

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

กรณีศึกษาหรือตัวอย่างจำลองที่ปลอดภัย

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

เมื่อแก้แบบฟอร์ม ทีมไม่ลบเหตุผลเดิม แต่สร้างบันทึกการเปลี่ยน: รุ่นเก่า, ปัญหาที่พบ, รุ่นใหม่, ผู้อนุมัติ, วันทบทวน ผลคือทีมเรียนรู้ได้ต่อเนื่องโดยไม่ใช้ Nothing is Deleted เป็นข้ออ้างเก็บข้อมูลส่วนบุคคลไม่จำกัด

เส้นทาง V4 สำหรับการปรับนโยบายยังครบทั้งขาไปและกลับ มนุษย์ส่งเรื่องให้ Earth AI จากนั้น Jan เลือกบทบาทที่เหมาะ เมื่อทำงานเสร็จ รายงานจะกลับผ่าน Jan และ Earth AI จนถึงมนุษย์ การลบหรือเปลี่ยนนโยบายจริงหยุดที่ผู้มีอำนาจ ไม่ให้ House ตัดสินเอง

กิจกรรมทดลองอย่างปลอดภัย

ทำบัตรวงจรชีวิตข้อมูลจากชุดข้อมูลสมมติ:

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

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

ระวังความเข้าใจผิด

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

สามเรื่องที่ควรจำ

  1. รักษาเหตุผลและประวัติรุ่น ไม่ใช่เก็บข้อมูลดิบทุกชิ้นตลอดไป
  2. กำหนดอายุ สิทธิ์เข้าถึง และวิธีลบตั้งแต่ก่อนเก็บ
  3. เมื่อความเป็นส่วนตัวกำหนดให้ลบ ต้องลบ; Framework ไม่ใช่ข้อยกเว้น

คำถามชวนคิด

ในธุรกิจของคุณ มีข้อมูลใดที่เก็บไว้เพราะ “เคยเก็บ” มากกว่าเพราะยังมีวัตถุประสงค์ที่ชัด

สะพานไปบทถัดไป

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

ค้นทั้งเล่ม

อยากรู้เรื่องอะไร

พิมพ์อย่างน้อย 2 ตัวอักษร