ข้ามไปยังเนื้อหาหลัก
FromNine
เมนู

AI และข้อมูล

ข้อมูลที่ AI และการตัดสินใจพึ่งพาได้

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

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

ข้อมูลและการวิเคราะห์: ชั้นความสามารถสี่ชั้นเรียงซ้อนกัน จากบนลงล่าง ได้แก่ งานวิเคราะห์และ AI ที่ใช้ข้อมูล ผลิตภัณฑ์ข้อมูลที่มีเจ้าของและข้อตกลง ชั้นของ lakehouse ที่ทำความสะอาดและปรับข้อมูลให้เป็นมาตรฐาน และธรรมาภิบาลข้อมูลที่ครอบคลุมทุกชั้น01การวิเคราะห์และการใช้งาน AI02ผลิตภัณฑ์ข้อมูลและข้อตกลง03ชั้นของ lakehouse04ธรรมาภิบาลและที่มาของข้อมูล
  1. 01ผลิตภัณฑ์ข้อมูลที่มีเจ้าของระบุชื่อ ข้อตกลง และการตรวจคุณภาพ
  2. 02ธรรมาภิบาลที่บังคับใช้วัตถุประสงค์และระยะเวลาการเก็บรักษา ไม่ใช่เพียงแค็ตตาล็อก
  3. 03นิยาม KPI ชุดเดียวที่ทั้งฝ่ายธุรกิจและฝ่ายไอทีรับรอง

01 ปัญหา

ปัญหาข้อมูลที่คุ้นเคย

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

  1. 01

    รายงานสามฉบับ ตัวเลขสามชุด

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

  2. 02

    ไม่มีใครเป็นเจ้าของข้อมูล จึงไม่มีใครแก้

    ข้อผิดพลาดมักพบที่ปลายทาง แก้ไขในสเปรดชีต แล้วกลับมาอีกในเดือนถัดไป

  3. 03

    ทีม AI ใช้เวลาส่วนใหญ่ไปกับการหาข้อมูล

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

  4. 04

    เอกสารเก่าใช้กับ AI ไม่ได้

    เอกสารสแกนที่ OCR คุณภาพต่ำ มีฉบับซ้ำ และไม่มีเมทาดาทา การค้นคืนจากเอกสารเหล่านี้ให้ผลที่ไม่มีประโยชน์

02 สิ่งที่เราส่งมอบ

สิ่งที่เราส่งมอบ

  1. 01 รากฐานข้อมูลสำหรับ AI และการวิเคราะห์

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

    สิ่งที่เราทำ

    • สถาปัตยกรรมแพลตฟอร์มและการเลือกรูปแบบการจัดเก็บ
    • แนวทางการจัดโมเดลข้อมูลเป็นชั้น
    • ออกแบบผลิตภัณฑ์ข้อมูลพร้อมข้อตกลง
    • การนำเข้าแบบ batch และ change data capture

    สิ่งที่คุณได้รับ

    • แพลตฟอร์ม lakehouse ที่กำหนดด้วยโค้ด
    • ผลิตภัณฑ์ข้อมูลชุดแรกที่ใช้งานจริง
    • แม่แบบข้อตกลงข้อมูลและกระบวนการทบทวน
  2. 02 คุณภาพ ที่มาของข้อมูล และข้อมูลหลัก

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

    สิ่งที่เราทำ

    • กฎคุณภาพพร้อมเกณฑ์และการแจ้งเตือน
    • บันทึกที่มาของข้อมูลระดับคอลัมน์
    • กฎการจับคู่และการเลือกค่าที่ถูกต้องของข้อมูลหลัก
    • การจัดการข้อมูลอ้างอิง

    สิ่งที่คุณได้รับ

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

    แค็ตตาล็อก การจัดชั้นข้อมูล และนโยบายสิทธิ์การเข้าถึงที่แพลตฟอร์มบังคับใช้โดยอัตโนมัติ วัตถุประสงค์และระยะเวลาการเก็บรักษาที่แจ้งเจ้าของข้อมูลส่วนบุคคลตาม PDPA และหลักการจำกัดวัตถุประสงค์ของ GDPR ถูกเขียนเป็นกฎในแพลตฟอร์ม และการแบ่งปันข้อมูลเป็นไปตาม Data Governance Act ของสหภาพยุโรปในกรณีที่ใช้บังคับ

    สิ่งที่เราทำ

    • แผนการจัดชั้นข้อมูลและการติดแท็ก
    • นโยบายสิทธิ์การเข้าถึงตามคุณลักษณะ
    • การเก็บรักษาและการลบข้อมูลโดยอัตโนมัติ
    • ข้อตกลงการแบ่งปันข้อมูลและการควบคุมทางเทคนิค

    สิ่งที่คุณได้รับ

    • แค็ตตาล็อกที่ดึงข้อมูลจากแพลตฟอร์ม
    • นโยบายสิทธิ์การเข้าถึงที่เขียนเป็นโค้ด
    • ตารางระยะเวลาการเก็บรักษาที่ใช้งานจริง
  4. 04 เตรียมเนื้อหาที่ไม่มีโครงสร้างให้พร้อมสำหรับ AI

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

    สิ่งที่เราทำ

    • สำรวจเนื้อหาและสุ่มตรวจคุณภาพ
    • ปรับปรุง OCR และการดึงโครงร่างเอกสาร
    • ตรวจหาเอกสารที่เกือบซ้ำกัน
    • เพิ่มเมทาดาทาและจัดประเภทเนื้อหา

    สิ่งที่คุณได้รับ

    • ที่เก็บเนื้อหาที่ทำความสะอาดและเพิ่มข้อมูลแล้ว
    • รายงานคุณภาพเนื้อหา
    • กฎสำหรับเนื้อหาที่เพิ่มเข้ามานับจากนี้
  5. 05 การวิเคราะห์และ BI ที่ผู้ใช้งานใช้จริง

    ชั้นความหมาย (semantic layer) ที่มีนิยาม KPI ซึ่งฝ่ายธุรกิจและฝ่ายไอทีตกลงร่วมกัน การวิเคราะห์แบบบริการตนเองที่มีการกำกับ และการวิเคราะห์ที่ฝังอยู่ในผลิตภัณฑ์ SaaS และพอร์ทัล

    สิ่งที่เราทำ

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

    สิ่งที่คุณได้รับ

    • อภิธานศัพท์ KPI พร้อมเจ้าของ
    • โมเดลความหมายที่รับรองแล้ว
    • แดชบอร์ดที่ใช้แทนสเปรดชีต
  6. 06 ข้อมูลแบบสตรีมสำหรับงานปฏิบัติการ

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

    สิ่งที่เราทำ

    • ข้อกำหนดด้านความหน่วงของแต่ละกรณีการใช้งาน
    • CDC จากฐานข้อมูลของระบบงาน
    • การประมวลผลสตรีมและ materialised view
    • การออกแบบการเล่นซ้ำและการเติมข้อมูลย้อนหลัง

    สิ่งที่คุณได้รับ

    • ไปป์ไลน์สตรีมที่ใช้งานจริง
    • มุมมองข้อมูลสำหรับงานปฏิบัติการพร้อมเป้าหมายความสดใหม่
    • ขั้นตอนการเล่นซ้ำ

03 สถาปัตยกรรม

ตัวอย่างสถาปัตยกรรมอ้างอิง

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

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

ตัวอย่างประกอบ
  1. แหล่งข้อมูลและการนำเข้า

    • ระบบงาน
    • เอกสารหลัง OCR และเพิ่มข้อมูล
    • Batch และ change data capture
  2. พื้นที่ lakehouse

    • ชั้นข้อมูลดิบ
    • ชั้นข้อมูลมาตรฐาน
    • ตรวจคุณภาพและที่มาของข้อมูล
    • ข้อมูลหลักและข้อมูลอ้างอิง
    • ผลิตภัณฑ์ข้อมูลพร้อมข้อตกลง
  3. การใช้ข้อมูล

    • ชั้นความหมายและ BI
    • การค้นคืนและฟีเจอร์สำหรับ AI
    • API ข้อมูลและการแบ่งปัน
  4. ธรรมาภิบาล

    • ธรรมาภิบาล: แค็ตตาล็อก การจัดชั้นข้อมูล นโยบายสิทธิ์ การเก็บรักษา
ชั้นของ lakehouse สู่ผลิตภัณฑ์ข้อมูลที่มีเจ้าของ

ตัวอย่างสถาปัตยกรรม ไม่ใช่ระบบของลูกค้า

อ่านแผนภาพในรูปแบบข้อความ

เส้นทางหลักวิ่งจากระบบงาน ผ่านการนำเข้าแบบ batch และ change data capture ชั้นข้อมูลดิบ ชั้นข้อมูลมาตรฐาน และผลิตภัณฑ์ข้อมูล ไปสู่ชั้นความหมายที่มี BI แบบมีการกำกับ

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

แถบธรรมาภิบาลข้อมูลที่มีแค็ตตาล็อก การจัดชั้นข้อมูล นโยบายสิทธิ์การเข้าถึง และการเก็บรักษา ครอบคลุมทั้งแพลตฟอร์ม

04 ข้อพิจารณาและข้อจำกัด

ข้อพิจารณาทางวิศวกรรมและข้อจำกัด

  • ความเป็นเจ้าของมาก่อนเครื่องมือ

    วิธีที่เราจัดการ

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

    ข้อจำกัดและเงื่อนไข

    แพลตฟอร์มสร้างความเป็นเจ้าของขึ้นมาเองไม่ได้ หากองค์กรไม่แต่งตั้งเจ้าของ ปัญหาคุณภาพจะกลับมา ไม่ว่าจะใช้เครื่องมือใด

  • การใช้ข้อมูลตามวัตถุประสงค์ในทางปฏิบัติ

    วิธีที่เราจัดการ

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

    ข้อจำกัดและเงื่อนไข

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

  • ข้อมูลสำหรับ AI มีเกณฑ์คุณภาพของตนเอง

    วิธีที่เราจัดการ

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

    ข้อจำกัดและเงื่อนไข

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

05 วิธีการทำงาน

วิธีการทำงานของเรา

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

  1. 01

    เลือกการตัดสินใจ ไม่ใช่ชุดข้อมูล

    เริ่มจากการตัดสินใจหรือกรณีการใช้งาน AI สองถึงสามเรื่อง และข้อมูลที่ต้องใช้ พร้อมระบุเจ้าของ

    ผลลัพธ์รายการผลิตภัณฑ์ข้อมูลพร้อมเจ้าของ

  2. 02

    วางรากฐานให้รองรับผลิตภัณฑ์เหล่านั้น

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

    ผลลัพธ์ผลิตภัณฑ์ข้อมูลชุดแรกที่ใช้งานจริง

  3. 03

    เติบโตทีละผลิตภัณฑ์

    ผลิตภัณฑ์ใหม่แต่ละรายการใช้รากฐานเดิมซ้ำ และแค็ตตาล็อกกับอภิธานศัพท์ KPI เติบโตไปพร้อมกัน

    ผลลัพธ์แผนงานผลิตภัณฑ์และตัวชี้วัดการใช้งาน

06 การควบคุมโดยมนุษย์

จุดที่คนยังเป็นผู้ควบคุม

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

  • เจ้าของเป็นผู้อนุมัตินิยาม

    KPI หรือผลิตภัณฑ์ข้อมูลจะเปลี่ยนความหมายได้เมื่อเจ้าของฝ่ายธุรกิจอนุมัติเท่านั้น และการเปลี่ยนแปลงทุกครั้งมีการจัดการเวอร์ชัน

  • เจ้าของนโยบายเป็นผู้ให้สิทธิ์

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

  • คุณภาพไม่ผ่าน ระบบหยุด

    เมื่อการตรวจตามข้อตกลงไม่ผ่าน ผู้ใช้ข้อมูลจะได้รับแจ้ง และเจ้าของตัดสินว่าจะเผยแพร่ ระงับ หรือแก้ไข

07 เทคโนโลยี

เทคโนโลยีที่เราใช้

แพลตฟอร์ม
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Open lakehouse บน Apache Iceberg หรือ Delta Lake
ไปป์ไลน์
  • dbt
  • Apache Spark
  • Kafka และ Debezium
  • การจัดลำดับงานแบบ cloud-native
ธรรมาภิบาล
  • Unity Catalog และ Purview
  • แค็ตตาล็อกโอเพนซอร์ส
  • เฟรมเวิร์กคุณภาพข้อมูล
  • การควบคุมสิทธิ์ตามนโยบาย
การวิเคราะห์
  • Power BI
  • ชั้นความหมายและชั้นตัวชี้วัด
  • การวิเคราะห์แบบฝังในผลิตภัณฑ์
  • SAP analytics (สำหรับระบบที่มีอยู่)

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

08 ตัวอย่าง

ตัวอย่างประกอบ

ตัวอย่างประกอบ

KPI ชุดเดียวสำหรับผู้ผลิตที่มีบริษัทในไทยและยุโรป

01สถานการณ์
ตัวอย่าง: ผู้ผลิตที่เป็นธุรกิจครอบครัวมีโรงงานในประเทศไทยและบริษัทขายในยุโรป แต่ละบริษัทรายงานยอดผลิตและงานค้างจากระบบของตนด้วยนิยามของตน ผู้บริหารกลุ่มจึงเปรียบเทียบตัวเลขที่มีความหมายไม่ตรงกัน
02ระบบที่เราจะสร้าง
ผลิตภัณฑ์ข้อมูลมาตรฐานของแต่ละบริษัทที่ป้อนเข้าชั้นความหมายเดียว โดยใช้นิยาม KPI ที่ตกลงในระดับกลุ่มและยังเก็บรายละเอียดของแต่ละบริษัทไว้
03จุดที่คนเป็นผู้ตัดสินใจ
ผู้จัดการฝ่ายการเงินของแต่ละบริษัทอนุมัติการจับคู่ข้อมูลของตน และเจ้าของ KPI ระดับกลุ่มอนุมัตินิยามและการเปลี่ยนแปลง
04สิ่งที่เราจะวัดผล
เวลาที่ใช้จัดทำรายงานประจำเดือน จำนวนการแก้ไขจากการกระทบยอด และการใช้แดชบอร์ดที่รับรองแล้ว

09 มุมมองรายอุตสาหกรรม

ในอุตสาหกรรมของคุณ

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

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

  • แหล่งข้อมูลต้นฉบับ การใช้ข้อมูลตามหลักขอครั้งเดียว (once-only) และการรายงานที่ผู้กำหนดนโยบายและผู้ตรวจสอบติดตามย้อนกลับไปถึงระเบียนต้นทางได้

ประเทศไทย

ข้อมูลที่ข้ามพรมแดน

กลุ่มบริษัทที่มีบริษัทในประเทศไทยและในยุโรปแบ่งปันข้อมูลภายใต้กฎที่ดูคล้ายกันแต่ไม่เหมือนกัน PDPA กำหนดว่าการส่งหรือโอนข้อมูลส่วนบุคคลไปต่างประเทศต้องไปยังปลายทางที่มีมาตรฐานการคุ้มครองเพียงพอตามหลักเกณฑ์ของคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เว้นแต่เข้าข้อยกเว้น หรือใช้นโยบายภายในกลุ่มที่ได้รับการรับรองหรือมาตรการคุ้มครองที่เหมาะสม (มาตรา 28 และ 29) โดยประกาศที่เกี่ยวข้องมีผลใช้บังคับตั้งแต่ 24 มีนาคม 2567

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

คำถามเกี่ยวกับข้อมูลและการวิเคราะห์

จำเป็นต้องใช้ data mesh หรือไม่

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

ข้อมูลของเราพร้อมสำหรับ AI หรือยัง

การประเมินสั้น ๆ จากตัวอย่างของแหล่งข้อมูลที่กรณีการใช้งานต้องใช้จะบอกได้ ทั้งความครอบคลุม คุณภาพ สิทธิ์การเข้าถึง และฐานทางกฎหมายตาม PDPA หรือ GDPR คำตอบมักเป็น “พร้อมบางส่วน” พร้อมรายการชัดเจนว่าควรแก้อะไรก่อน ทีมวิศวกรรม AI และ Generative AIของเราใช้การประเมินแบบเดียวกัน

เรามีคลังข้อมูล (data warehouse) อยู่แล้ว ต้องเริ่มใหม่หรือไม่

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

การแบ่งปันข้อมูลกับคู่ค้าหรือหน่วยงานอื่นทำอย่างไร

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

บอกเราถึงการตัดสินใจที่ข้อมูลวันนี้ยังช่วยไม่ได้

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