AI Ready คืออะไร? เงื่อนไขของข้อมูลที่พร้อมใช้งานสำหรับ AI และโมเดล 3 ชั้น

AI Ready なデータ基盤とは、AI が業務の文脈を理解し、信頼できるデータに基づいて、与えられた権限の範囲内で、根拠を示しながら判断し、人間の次の行動につなげられる状態にまで整えられたデータ基盤のことである。

ここで強調したいのは、データウェアハウス（DWH）を作ることでも、BIダッシュボードを整えることでも、社内ドキュメントをRAGに取り込むことでもない、という点だ。それらは AI Ready の一部ではあっても、全部ではない。

この記事は、社内で AI エージェントや生成 AI の業務活用を進めようとしているデータ・IT・DX 担当者、そして「データはあるのに AI がうまく使えない」という壁に直面している実務者に向けている。読み終えたとき、自社のデータ基盤に何が足りないのかを、3 つの層と 5 つの要件という具体的な物差しで点検できるようになることをゴールとする。

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

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

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

สภาวะที่เรียกว่า AI Ready ไม่ได้หมายถึงเพียงแค่การที่ข้อมูลสามารถเข้าถึงได้ในเชิงกายภาพเท่านั้น แต่ยังต้องประกอบด้วยเงื่อนไขที่ว่า (1) ข้อมูลนั้นต้องเชื่อถือได้ (2) มีการนิยามความหมายไว้อย่างชัดเจน (3) มีการควบคุมสิทธิ์ว่าใครสามารถเข้าถึงข้อมูลส่วนใดได้บ้าง และ (4) สามารถตรวจสอบย้อนกลับได้ว่าคำตอบนั้นมีที่มาจากอะไร การเข้าถึงข้อมูลได้เป็นเพียงแค่จุดเริ่มต้นเท่านั้น

ด้วยวิวัฒนาการของ Generative AI งานเขียน SQL จากภาษาธรรมชาติได้ถูกทำให้เป็นอัตโนมัติไปมากแล้ว แต่การที่ AI สามารถเขียน SQL ได้ กับการที่ AI สามารถตอบคำถามทางธุรกิจได้อย่างถูกต้องนั้น เป็นความสามารถที่แตกต่างกันโดยสิ้นเชิง

ตัวอย่างเช่น หากเราส่งเพียงแค่คำจำกัดความของตาราง (Table Definition) ให้กับ AI บริบททางธุรกิจต่อไปนี้จะไม่สามารถอ่านได้จาก Schema:

• "ยอดขาย" เป็นราคาก่อนภาษีหรือรวมภาษีแล้ว และรวมการคืนสินค้าหรือการยกเลิกหรือไม่
• ควรยึด Customer ID และ Contract ID ชุดใดเป็นหลัก
• ในบรรดาคำจำกัดความของ KPI ที่แตกต่างกันในแต่ละแผนก อันไหนคือคำจำกัดความที่เป็นทางการ
• ฝ่ายขาย ฝ่ายสนับสนุนลูกค้า และฝ่ายบริหาร ใช้คำเดียวกันในความหมายที่ต่างกันหรือไม่

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

ในความเป็นจริง บริษัทที่ให้บริการแพลตฟอร์มวิเคราะห์ข้อมูลต่างก็สรุปตรงกันว่า เนื่องจาก Schema ของฐานข้อมูลเพียงอย่างเดียวไม่เพียงพอต่อการระบุตรรกะการคำนวณตัวชี้วัดหรือคำจำกัดความของกระบวนการทางธุรกิจ จึงจำเป็นต้องมีการกำหนด "คำจำกัดความเชิงความหมาย" (Semantic Definition) แยกต่างหาก เพราะ Schema เป็นเพียงโครงสร้าง ไม่ใช่ความหมาย

คำว่า AI Ready เริ่มมีความสำคัญมากขึ้นอย่างกะทันหัน เพราะผู้ใช้งานข้อมูลกำลังขยายตัวจากมนุษย์ไปสู่ AI Agent

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

ทว่าเมื่อพยายามนำ AI Agent เข้ามาใช้ในงานขาย, ฝ่ายสนับสนุนลูกค้า, การบริหารจัดการองค์กร และงานสนับสนุนส่วนหลัง (Back office) ความรู้โดยนัยเหล่านี้จะไม่สามารถนำมาใช้ได้อีกต่อไป AI ไม่มีหน่วยความจำเหมือนมนุษย์ และมีจำนวนครั้งในการเข้าถึงข้อมูลมากกว่ามนุษย์หลายเท่า ยิ่งเป็นบริษัทสตาร์ทอัพหรือบริษัทขนาดกลาง ยิ่งมักประสบปัญหาการจัดระเบียบข้อมูลไม่ทันต่อความเร็วในการเพิ่มขึ้นของเครื่องมือต่างๆ ไม่ว่าจะเป็น Product DB, CRM, สเปรดชีต, เครื่องมือแชท, เอกสาร หรือระบบจัดการข้อสอบถาม ทำให้ข้อมูลถูกปล่อยให้กระจัดกระจายอยู่อย่างนั้น ดังนั้น AI Ready จึงเป็นความพยายามในการสร้าง "กาวที่มนุษย์เคยใช้เชื่อมประสาน" เข้าไปไว้ในฝั่งของโครงสร้างพื้นฐานข้อมูลแทน

โครงสร้างพื้นฐานข้อมูลที่พร้อมสำหรับ AI (AI Ready) สามารถจัดระเบียบให้เข้าใจได้ง่ายโดยแบ่งออกเป็น 3 ชั้นหลัก สรุปคือ AI Ready ไม่ใช่ปัญหาเรื่องเทคโนโลยีสแต็ก (Technology Stack) แต่เป็นปัญหาของการสะสมใน 3 ชั้น ได้แก่ การจัดเตรียมข้อมูล (Data Preparation), การให้ความหมาย (Semantics), และธรรมาภิบาล (Governance)

สิ่งแรกที่จำเป็นต้องทำคือการสร้างข้อมูลที่เชื่อถือได้ โดยการรวบรวมข้อมูลที่กระจัดกระจายอยู่ใน Product DB, CRM, ระบบจัดการการเรียกเก็บเงิน, ประวัติการสอบถามข้อมูล, บันทึกการใช้งาน (Usage Log), สเปรดชีต และแหล่งอื่นๆ มาไว้รวมกัน แล้วปรับแต่งให้อยู่ในรูปแบบที่พร้อมสำหรับการวิเคราะห์หรือการใช้งาน AI

ในขั้นตอนนี้ แนวทางที่ได้ผลดีคือ "Medallion Architecture" ซึ่ง Databricks เป็นผู้ริเริ่มและแพร่หลายไปอย่างกว้างขวาง โดยเป็นแนวคิดในการกลั่นกรองข้อมูลเป็นลำดับขั้น ได้แก่ Bronze ซึ่งเก็บข้อมูลดิบไว้ในรูปแบบเดิม, Silver ซึ่งทำหน้าที่ทำความสะอาด (Cleansing), ขจัดข้อมูลซ้ำซ้อน, แปลงประเภทข้อมูล, เชื่อมโยงข้อมูล และตรวจสอบความถูกต้อง และ Gold ซึ่งปรับแต่งข้อมูลให้อยู่ในรูปแบบที่ใช้งานได้จริงในทางธุรกิจ เช่น KPI, รายงานแยกตามแผนก หรือดัชนีชี้วัดการบริหารจัดการ

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

สิ่งที่จำเป็นในลำดับถัดมาคือการทำให้ข้อมูลอยู่ในรูปแบบที่ AI สามารถตีความหมายได้ กลไกที่เป็นตัวแทนสำคัญ ได้แก่ Semantic Model, Metrics Layer, Data Catalog และ Ontology

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

สำหรับ AI สิ่งที่สำคัญจริงๆ ไม่ใช่ปริมาณข้อมูล แต่คือความหมาย ความสัมพันธ์ ข้อจำกัด และกฎทางธุรกิจของข้อมูล หากขาดเลเยอร์นี้ไป AI ก็ทำได้เพียงคาดเดาความหมายจากชื่อตารางหรือชื่อคอลัมน์เท่านั้น ในทางกลับกัน หากมีการรวมศูนย์นิยามของตัวชี้วัดไว้ที่จุดเดียวเพื่อให้เครื่องมือ BI หรือ AI ที่อยู่ปลายทางสามารถอ้างอิงได้อย่างสอดคล้องกัน AI ก็จะสามารถตีความข้อมูลในรูปแบบที่ใกล้เคียงกับภาษาทางธุรกิจของมนุษย์ได้ การที่บริษัทต่างๆ ต่างพากันนำเสนอ "การกำหนดนิยามตัวชี้วัดจากส่วนกลาง" หรือ "Semantic Model + Ontology" เป็นเพราะเล็งเห็นว่าเลเยอร์นี้คือปัจจัยสำคัญที่ตัดสินความแม่นยำในการใช้งาน AI นั่นเอง

ในโครงสร้างพื้นฐานข้อมูลที่พร้อมสำหรับ AI (AI Ready) การที่ข้อมูล "ใช้งานได้" นั้นยังไม่เพียงพอ แต่จำเป็นต้อง "ใช้งานได้อย่างปลอดภัย" ด้วย

สิ่งที่สำคัญเป็นพิเศษคือ สิทธิ์การเข้าถึงข้อมูลของผู้ใช้แต่ละคน, การปกปิดข้อมูลส่วนบุคคลและข้อมูลที่เป็นความลับ (Masking), ความถี่และความสดใหม่ของข้อมูล, การตรวจสอบคุณภาพของข้อมูล, การติดตามที่มาของคำตอบ, บันทึก (Log) ว่า AI อ้างอิงข้อมูลใดบ้าง, การตรวจจับความผิดพลาดหรือความล่าช้าของไปป์ไลน์ รวมถึงการตรวจสอบโดยมนุษย์และวงจรการตอบกลับ (Feedback Loop)

เมื่อ AI Agent เข้ามามีบทบาทในการทำงาน จำนวนครั้งและเส้นทางการเข้าถึงข้อมูลจะเพิ่มขึ้นมากกว่าการทำ BI แบบเดิมอย่างมหาศาล ดังนั้น การควบคุมสิทธิ์และบันทึกการตรวจสอบ (Audit Log) จึงต้องทำที่ระดับโครงสร้างพื้นฐานข้อมูลอย่างสม่ำเสมอ แทนที่จะไปกำหนดไว้ที่ตัวแอปพลิเคชันเพียงอย่างเดียว เพราะหากสร้างระบบสิทธิ์แยกตามแอปพลิเคชัน ย่อมเกิดช่องโหว่ขึ้นอย่างแน่นอน

ในจุดนี้ แนวคิดเรื่องความสามารถในการสังเกตการณ์ (Observability) จึงเข้ามามีบทบาทสำคัญ OpenTelemetry ได้นิยามความสามารถในการสังเกตการณ์ไว้ว่าคือ "ความสามารถในการเข้าใจสถานะภายในของระบบจากผลลัพธ์ที่ส่งออกมา" การเตรียมระบบให้สามารถตรวจสอบความล่าช้าของไปป์ไลน์ คุณภาพข้อมูลที่ลดลง และที่มาของคำตอบของ AI จากผลลัพธ์ที่ได้นั้น ถือเป็นเงื่อนไขเบื้องต้นในการนำ AI มาใช้ในการทำงานจริง สำหรับรายละเอียดเพิ่มเติม โปรดดูที่ AI Governance และการปฏิบัติตาม EU AI Act

ในยุค AI ข้อมูลโครงสร้าง (Structured Data) เช่น ยอดขายหรือสัญญาเพียงอย่างเดียวไม่เพียงพออีกต่อไป เพราะ "เหตุผล" เบื้องหลังการตัดสินใจทางธุรกิจมักซ่อนอยู่ในข้อมูลไร้โครงสร้าง (Unstructured Data) การเชื่อมโยงข้อมูลทั้งสองประเภทเข้าด้วยกันจึงเป็นจุดตัดสินว่าองค์กรจะพร้อมสำหรับ AI (AI Ready) หรือไม่

ข้อมูลที่มีโครงสร้าง (Structured data) เช่น ยอดขาย, สัญญา, บันทึกการใช้งาน และจำนวนการสอบถามนั้นมีความสำคัญ แต่ข้อมูลที่อธิบายว่า "ทำไมถึงเป็นเช่นนั้น" มักจะอยู่ในฝั่งของข้อมูลที่ไม่มีโครงสร้าง (Unstructured data) ไม่ว่าจะเป็น บันทึกการเจรจาธุรกิจ, การสนทนาผ่านแชท, เอกสารข้อกำหนด, รายงานการประชุม, ประวัติการสนับสนุนลูกค้า, เหตุผลที่ปิดการขายไม่ได้, บทสัมภาษณ์ลูกค้า, เอกสารข้อเสนอ, สัญญา หรือกรณีศึกษาการใช้งาน ซึ่งมีมากมายนับไม่ถ้วน

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

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

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

เพื่อให้ได้ความแม่นยำที่สูงขึ้น การปรับแต่งระบบการสืบค้นจึงเป็นสิ่งที่ขาดไม่ได้ วิธีการอย่างการใช้ Hybrid Search ซึ่งเป็นการผสมผสานระหว่าง Vector Search และ Full-text Search หรือ Agentic RAG ที่มีการสืบค้นและอนุมานซ้ำไปมานั้นถือว่ามีประสิทธิภาพ แต่รากฐานสำคัญของสิ่งเหล่านี้คือ "การที่ข้อมูลที่ไม่มีโครงสร้างถูกเชื่อมโยงเข้ากับเอนทิตีทางธุรกิจ" ปัญหาด้านความแม่นยำของ RAG ส่วนใหญ่มักไม่ได้เกิดจากเทคโนโลยีการสืบค้น แต่เกิดจากการขาดการเชื่อมโยงนี้ โดยได้รวบรวมข้อผิดพลาดที่พบบ่อยไว้ใน รูปแบบความล้มเหลวในการสร้าง RAG แล้ว

เราจะสรุป 3 ชั้นที่กล่าวมาข้างต้นให้เป็น 5 ข้อกำหนดที่สามารถตรวจสอบได้ในการปฏิบัติงานจริง หากจะสรุปให้เข้าใจง่ายตั้งแต่ต้น ความพร้อมสำหรับ AI (AI Ready) สามารถตัดสินได้จาก 5 ปัจจัย ได้แก่ "ความน่าเชื่อถือ (Trust)・ความหมาย (Meaning)・การเชื่อมต่อ (Connectivity)・สิทธิ์การเข้าถึง (Authorization)・หลักฐานอ้างอิง (Evidence)"

หากขาดข้อใดข้อหนึ่งใน 5 ข้อนี้ไป ทั้งระบบจะทำงานได้ยาก ตัวอย่างเช่น แม้จะมีข้อมูลที่เชื่อถือได้ (ข้อกำหนดที่ 1) แต่หากไม่มีการนิยามความหมาย (ข้อกำหนดที่ 2) AI ก็อาจตีความผิดพลาดได้ หรือแม้จะมีการนิยามความหมายแล้ว แต่หากไม่มีการจัดการสิทธิ์ (ข้อกำหนดที่ 4) ก็ไม่สามารถเปิดใช้งานได้อย่างปลอดภัย การนำสถานะปัจจุบันของบริษัทมาเทียบกับตารางนี้เพื่อดูว่าข้อกำหนดใดที่ยังขาดแคลน ถือเป็นก้าวแรกสู่การเป็น AI Ready

เมื่อสถานะ AI Ready พร้อมใช้งาน รูปแบบของ BI จะเปลี่ยนไปโดยสิ้นเชิง จุดเน้นจะเปลี่ยนจาก BI แบบรับ (Passive BI) ที่มนุษย์ต้องเข้าไปดูแดชบอร์ดเอง ไปสู่ BI แบบรุก (Active BI) ที่ AI จะเป็นผู้ตรวจพบการเปลี่ยนแปลงและแจ้งเตือนให้ทราบ

従来のBIは、人間がダッシュボードを開き、異変を見つけ、原因を調べ、次の行動を考えるものだった。すべての起点が「人が見に行くこと」にあった。

AI Readyな基盤の上では、AIの側から動けるようになる。KPIの変化を検知し、その変化の大きさや異常性を説明し、関連する要因を調べ、根拠となるデータや資料を提示し、次のアクションを提案し、必要に応じて担当者に通知する——こうした一連の流れだ。データ可視化ツールの新しい世代が「プロアクティブなインサイト」や「アクション型のBI」を掲げているのは、この方向への移行を見据えてのことだ。BIは「見るもの」から「動くもの」へと性格を変えつつある。

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

บนพื้นฐานที่พร้อมสำหรับ AI (AI Ready) AI จะสามารถเป็นฝ่ายเคลื่อนไหวได้เอง โดยเริ่มจากการตรวจจับการเปลี่ยนแปลงของ KPI อธิบายขนาดและความผิดปกติของการเปลี่ยนแปลงนั้น ตรวจสอบปัจจัยที่เกี่ยวข้อง นำเสนอข้อมูลและเอกสารที่เป็นหลักฐาน เสนอการดำเนินการต่อไป และแจ้งเตือนผู้รับผิดชอบตามความจำเป็น ซึ่งเป็นกระบวนการที่ต่อเนื่องกัน การที่เครื่องมือแสดงผลข้อมูล (Data Visualization) ยุคใหม่ชูแนวคิด "Proactive Insights" หรือ "Actionable BI" นั้น ก็เพื่อมุ่งไปสู่ทิศทางนี้ BI กำลังเปลี่ยนลักษณะจาก "สิ่งที่ต้องเข้าไปดู" ไปสู่ "สิ่งที่ขับเคลื่อนการทำงาน"

อย่างไรก็ตาม มีข้อควรระวังประการหนึ่ง หากเพียงแค่แจ้งเตือนในแชทว่า "ยอดขายลดลง" นั่นก็เป็นเพียงแค่ Alert bot เท่านั้น สิ่งที่มีคุณค่าอย่างแท้จริงคือสิ่งที่ตามมาหลังจากนั้น

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

ตัวอย่างเช่น หากพิจารณา AI Agent สำหรับสนับสนุนการบริหารจัดการ สิ่งที่ต้องการคือกระบวนการที่ตรวจจับการเปลี่ยนแปลงของ KPI, ตัดสินใจได้ว่าเป็นความผันผวนปกติหรือค่าที่ผิดปกติ, ดูว่าเกิดขึ้นในเซกเมนต์ใด, ตรวจสอบเหตุการณ์ที่เกี่ยวข้องในด้านการขาย การสนับสนุน และผลิตภัณฑ์, สรุปสมมติฐานของสาเหตุ, เสนอแนวทางปฏิบัติถัดไป, ส่งต่องานให้ผู้รับผิดชอบ และสะสมผลลัพธ์เพื่อเป็นข้อมูลป้อนกลับ (Feedback) การจะทำให้สิ่งนี้เกิดขึ้นได้นั้น เพียงแค่ DWH (Data Warehouse) อย่างเดียวนั้นไม่เพียงพอ แต่จำเป็นต้องมีโครงสร้างพื้นฐานที่ครอบคลุม ทั้งการกำหนดความหมาย (Semantic definition), Data Catalog, ความรู้ทางธุรกิจ (Business knowledge), RAG, การจัดการสิทธิ์, Audit log และวงจรป้อนกลับ (Feedback loop) นี่คือสิ่งที่หมายถึงเมื่อกล่าวว่าโครงสร้างพื้นฐานข้อมูลที่ "AI Ready" กำลังเปลี่ยนจาก "โครงสร้างพื้นฐานสำหรับแดชบอร์ด" ไปสู่ "โครงสร้างพื้นฐานทางธุรกิจที่สนับสนุนการตัดสินใจและการปฏิบัติงาน"

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

เมื่อได้รับคำปรึกษาเรื่องการนำ AI Agent มาใช้งาน ความคาดหวังแรกที่มักจะได้ยินคือ "อยากเชื่อมต่อข้อมูลเข้ากับ AI ให้ได้ก่อน" ซึ่งก็เข้าใจได้ แต่สิ่งแรกที่เราจะตรวจสอบไม่ใช่ปริมาณข้อมูลหรือจุดเชื่อมต่อ แต่คือการดูว่าคำศัพท์พื้นฐานอย่าง "ยอดขาย" (Sales) หรือ "ลูกค้า" (Customer) มีการนิยามความหมายภายในองค์กรให้เป็นมาตรฐานเดียวกันแล้วหรือไม่

หากเชื่อมต่อ AI โดยที่ส่วนนี้ยังไม่ชัดเจน AI อาจนำตัวเลขที่แตกต่างกันของแต่ละแผนกมาปะปนกันจนเกิดเป็นคำตอบที่สร้างความสับสนมากกว่าเดิม ด้วยเหตุนี้ เราจึงแนะนำว่าต่อให้เป็นการเริ่มต้นแบบ Small Start ก็ห้ามละเลยการกำหนดความหมายในชั้นที่ 2 (การนิยามคำศัพท์และ KPI) เป็นอันขาด ในช่วงแรกอาจจำกัดขอบเขตไว้เพียงแค่ 1 ส่วนงานก็ได้ แต่สำหรับส่วนงานนั้น ต้องออกแบบการนิยามคำศัพท์ การเชื่อมต่อข้อมูล และสิทธิ์การเข้าถึงให้ครบถ้วนตั้งแต่ต้น แม้จะจำกัดขอบเขตให้แคบลง แต่ต้องทำให้ครบทุกชั้น — นี่คือลำดับขั้นตอนที่สมเหตุสมผลที่สุดในการลดการทำงานซ้ำซ้อน (Rework) ให้เหลือน้อยที่สุด

AI により、การสร้าง SQL, การทำ ETL และการสร้างแดชบอร์ด งานบางส่วนเหล่านี้มีแนวโน้มที่จะถูกทำให้เป็นอัตโนมัติมากขึ้น แต่ไม่ได้หมายความว่าบุคลากรด้านข้อมูล (Data Talent) จะไม่จำเป็นอีกต่อไป ในทางกลับกัน จุดเน้นของบทบาทจะเปลี่ยนจากการลงมือทำ (Implementation) ไปสู่การออกแบบ การควบคุม และการประเมินผลแทน

โดยเฉพาะอย่างยิ่ง งานเหล่านี้ได้แก่ การออกแบบ KPI ที่ถูกต้อง, การกำหนดคำศัพท์ทางธุรกิจ, การรับรองคุณภาพของข้อมูล, การออกแบบขอบเขตของข้อมูลที่ AI สามารถเข้าถึงได้, การจัดเตรียม Semantic Model และ Ontology, การตรวจสอบความถูกต้องของแหล่งที่มาของคำตอบจาก AI, การติดตามการทำงานของ Pipeline และ AI Agent รวมถึงการเป็นตัวกลางระหว่างฝ่ายธุรกิจกับระบบ AI เพื่อปรับปรุงการทำงาน กล่าวอีกนัยหนึ่งคือ บุคลากรด้านข้อมูลในอนาคตจะไม่ได้เป็นเพียงแค่ผู้ลงมือทำเท่านั้น แต่จะกลายเป็นผู้ออกแบบข้อมูล (Data Architect), ผู้กำหนดทิศทางการใช้ AI และผู้ออกแบบระบบธรรมาภิบาล (Governance) ยิ่งงานที่มอบหมายให้ AI ทำมีมากขึ้นเท่าใด ความสามารถในการตัดสินใจว่า "สิ่งใดควรให้ AI ทำ และสิ่งใดที่มนุษย์ควรเป็นผู้ควบคุม" ก็จะยิ่งมีมูลค่าสูงขึ้นเท่านั้น

ได้รวบรวมคำถามที่พบบ่อยจากการให้คำปรึกษาเกี่ยวกับโครงสร้างพื้นฐานข้อมูลที่พร้อมสำหรับ AI (AI Ready) มาไว้ ณ ที่นี้

ไม่ครับ DWH เป็นเพียงส่วนหนึ่งของรากฐานสำหรับ AI Ready เท่านั้น แม้จะมี DWH แต่หากขาดคำศัพท์ทางธุรกิจหรือการกำหนดนิยาม (ความหมาย) ของ KPI รวมถึงสิทธิ์ในการเข้าถึงข้อมูลและข้อมูลสายสัมพันธ์ (Data Lineage) หรือธรรมาภิบาลข้อมูล (Governance) AI ก็จะไม่สามารถนำมาใช้งานทางธุรกิจได้อย่างถูกต้อง จึงควรพิจารณาว่า DWH เป็นเงื่อนไขที่จำเป็น แต่ไม่ใช่เงื่อนไขที่เพียงพอครับ

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

ขอแนะนำให้จำกัดขอบเขตไว้ที่งานเพียงด้านเดียว (เช่น ฝ่ายขาย หรือฝ่ายบริการลูกค้า) และออกแบบ "คำจำกัดความของคำศัพท์/KPI", "การเชื่อมต่อข้อมูล" และ "สิทธิ์ในการเข้าถึง" ให้เป็นชุดเดียวกันตั้งแต่เริ่มต้น โดยเคล็ดลับคือการทำให้ครบทั้ง 3 ส่วนในขอบเขตที่แคบก่อน หากละเลยเรื่องการกำหนดความหมายหรือการจัดการสิทธิ์ไว้ทีหลัง มักจะทำให้ต้องรื้อระบบใหม่ทั้งหมดในภายหลัง

AI Ready なデータ基盤とは、単に AI にデータを渡せる状態を指すのではない。AI が業務の文脈を理解し、信頼できるデータに基づいて、権限の範囲内で、根拠を持って判断し、人間の次の行動につなげられる状態のことである。

その実現には、データを整える第1層、意味を与える第2層、安全に使う第3層という3つの層と、信頼・意味・接続・権限・根拠という5つの要件が必要になる。DWH・BI・RAG はそのどれか1つではなく、これらを組み合わせた全体として初めて AI Ready になる。

これからのデータ基盤は、単なる「見える化」のための基盤から、AI エージェントが判断・提案・実行を支援するための業務基盤へと近づいていく。自社の現状を3層と5要件に照らし、どこが手薄かを見極めることから始めてほしい。当社でも、AI 活用を見据えたデータ基盤の設計・整備を支援している。