เมื่อ AI เป็น Urban Operating System ของเมือง บทเรียนจาก ‘หางโจว’ สู่ ‘กรุงเทพฯ’ เพื่อรับมือน้ำท่วมให้เร็วขึ้น

มาหางโจวรอบนี้เพื่อดูงานด้าน AI สิ่งที่ผมสนใจมากไม่ได้มีแค่การแข่งขันของโมเดลหรือบริษัทเทคโนโลยี แต่คือสิ่งที่เมืองเรียกว่า City Brain

ผมได้รู้จักมันจากโซน Industry Application ในงาน Apsara Conference 2026 ที่เอา use case AI ในโลกจริงมาแสดง และได้ดูรายละเอียดอีกรอบในโซน Spatial Intelligence ของงาน Global Digital Trade Expo 2026 ซึ่งมีโซลูชันบริหารเมืองด้วย AI มาให้ดูหลายแบบ

ชื่อ City Brain อาจฟังดูเหมือนโปรเจกต์ AI ขนาดใหญ่ มีสมองกลางสักตัวคอยควบคุมเมือง แต่ของจริงไม่ใช่แบบนั้น และไม่ใช่แค่ chatbot ของภาครัฐ

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

ตามกฎหมายท้องถิ่นของหางโจว City Brain ถูกนิยามถึงขั้นว่าเป็นทั้ง “ระบบดิจิทัล” และ “โครงสร้างพื้นฐานสมัยใหม่ของเมือง” ประกอบด้วยศูนย์กลาง ระบบและแพลตฟอร์ม digital cockpit และ application scenarios โดยมีข้อมูล กำลังประมวลผล และ algorithm เป็นฐาน

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

City Brain เริ่มจากโจทย์บ้านๆ มาก คือรถติด

หางโจวเริ่มพัฒนาระบบในปี 2016 โดยนำข้อมูลจากกล้องและสภาพจราจรแบบ real time มาใช้ช่วยควบคุมสัญญาณไฟ ในเขต Xiaoshan มีการนำระบบไปใช้กับทางแยกมากกว่า 100 จุด และมีรายงานว่าความเร็วของรถดีขึ้นประมาณ 15%

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

พอเริ่มเห็นผล City Brain ก็ไม่ได้หยุดอยู่แค่เรื่องจราจร แต่ค่อย ๆ ขยายจาก traffic use case ไปสู่งานด้านโรงพยาบาล ประกันสุขภาพ การเฝ้าระวังความเสี่ยงของโครงสร้างพื้นฐาน การจัดการภัยพิบัติ และบริการภาครัฐ 

ในปี 2025 หางโจวเริ่มผลัก AI เข้าไปอยู่ในระบบลึกขึ้นกว่าเดิม

มี virtual police officer ที่ให้ข้อมูลเรื่องกฎหมายและงานภาครัฐตลอด 24 ชั่วโมง มี AI ด้านประกันสุขภาพที่ช่วยทั้งค้นข้อมูลและทำธุรกรรมบางอย่างระหว่างการสนทนา มี AI ด้านสุขภาพจิตและการนอน รวมถึงระบบ AI ที่ใช้เฝ้าระวังความเสี่ยงจากงานก่อสร้างและโครงสร้างพื้นฐาน

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

แต่มีอีกเรื่องที่ผมว่าสำคัญมาก และบางทีสำคัญกว่าเทคโนโลยีด้วยซ้ำ คือ ใครเป็นเจ้าภาพ City Brain ไม่ใช่โครงการของ Alibaba ที่สร้างเสร็จแล้วเอามาขายให้เมืองใช้

ฝั่งรัฐบาลมีเจ้าภาพหลักคือ Hangzhou Municipal Data Resources Management Bureau หรือ สำนักบริหารทรัพยากรข้อมูลนครหางโจว ซึ่งรับผิดชอบภาพรวมเรื่องข้อมูลของเมืองและโครงการสำคัญอย่าง City Brain

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

ภายใต้สำนักฯ ยังมี Hangzhou Big Data Management Service Center ซึ่งรับภารกิจด้านการรวบรวมและใช้ข้อมูลภาครัฐ โครงสร้างพื้นฐาน e-government รวมถึงการสร้างและ operation ของ City Brain ในระดับปฏิบัติการ

แต่ฝั่งข้อมูลไม่ได้ทำทุกอย่างเอง

รัฐบาลนครหางโจวเป็นเจ้าของนโยบายและกลไกการสั่งการระดับเมือง ส่วนหน่วยงานเจ้าของภารกิจ เช่น ตำรวจ ขนส่ง สาธารณสุข โยธา หรือหน่วยงานบริการประชาชน ยังคงเป็นเจ้าของงานและ workflow ของตัวเอง

กฎหมายยังระบุให้หน่วยงานที่มีภารกิจด้านบริการและบริหารสาธารณะเชื่อมระบบของตัวเองเข้ากับศูนย์กลาง เพื่อให้เกิดทั้ง business coordination และ data coordination ข้ามหน่วยงาน ขณะเดียวกันก็มีฝั่งเทคนิคและการเดินระบบ

ในปี 2021 มีการตั้ง Hangzhou City Brain Technology and Service หรือ Digital Hangzhou ขึ้นมา โดยหน้าองค์กรระบุว่าอยู่ภายใต้การนำร่วมของ Hangzhou Data Group และ Alibaba และทำงานด้าน smart city, digital transformation และการใช้ประโยชน์จากข้อมูล รวมถึง City Brain

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

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

ตรงนี้แหละที่ทำให้คำว่า Urban Operating System มีความหมายมากกว่าการมี dashboard กลางหนึ่งชุด

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

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

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

ข้อมูลถนนและการจราจรเห็นสถานการณ์เดียวกับฝ่ายระบายน้ำหรือไม่ และข้อมูลจาก Traffy Fondue ถูกนำไปประกอบกับข้อมูล real time อื่น ๆ เพื่อช่วยยืนยันสถานการณ์ จัด priority และสร้างงานให้คนที่ต้องลงมือทำได้เร็วแค่ไหน ตรงนี้ต่างหากที่ผมคิดว่าเป็นโจทย์ของ Urban Operating System

หางโจวเองมีตัวอย่างเรื่องน้ำจากเหตุการณ์น้ำท่วมที่ Jiande ในปี 2020 ตอนนั้น City Brain ถูกใช้รวบรวมข้อมูลระดับน้ำ อุตุนิยมวิทยา ถนน และสถานการณ์ภัยพิบัติแบบ real time โดยมีทั้งหน่วยงานด้านน้ำ อุตุนิยมวิทยา คมนาคม ตำรวจ และหน่วยงานอื่นเข้ามาทำงานร่วมกัน

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

สิ่งที่ผมสนใจจึงไม่ใช่เรื่องว่า AI พยากรณ์น้ำได้แม่นกี่เปอร์เซ็นต์ แต่คือสิ่งที่เกิดขึ้น หลังจากระบบเห็นว่ากำลังจะมีปัญหาแล้ว นี่คือ real-time coordination

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

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

และเมื่อแก้แล้ว ระบบก็ควรรู้ว่างานจบหรือยัง ไม่ใช่จบอยู่ที่กราฟสีแดงบนจอใหญ่ ถ้ามองแบบระบบ วงจรนี้ คือ Data → Decision → Action → Feedback นี่คือ closed loop ที่สำคัญมาก

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

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

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

ข้อมูลฝนอยู่ระบบหนึ่ง ระดับน้ำอยู่อีกระบบ สถานะประตูน้ำและเครื่องสูบน้ำอยู่อีกระบบ น้ำทะเลหนุนอยู่อีกแหล่ง ข้อมูลถนนและจุดก่อสร้างอยู่อีกระบบ ส่วนการแจ้งเหตุจากประชาชนผ่าน Traffy Fondue ก็เป็นอีก stream หนึ่ง

ถ้าหน่วยงานหนึ่งรู้ว่าฝนตก อีกหน่วยรู้ว่าระดับน้ำกำลังขึ้น แต่อีกหน่วยยังไม่รู้ว่าถนนเริ่มใช้ไม่ได้ เมืองก็ยังตอบสนองช้าเหมือนเดิม

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

เรื่องที่สองคือ Command Structure และ Cross-agency Workflow ตรงนี้ผมว่าสำคัญกว่า AI เสียอีก เมื่อระบบพบความเสี่ยง ต้องตอบให้ได้ว่าใครเป็น owner ใครมีอำนาจสั่งการ ใครส่งทีมลงพื้นที่ ใครดูแลเครื่องสูบน้ำ ใครประสานเรื่องถนนและการจราจร ใครสื่อสารกับประชาชน และถ้าไม่มีใครรับงานภายในเวลาที่กำหนดจะ escalate ไปหาใคร

นี่คืออีกบทเรียนหนึ่งจากหางโจวที่น่าสนใจ เพราะ City Brain ไม่ได้มีแค่ technology owner แต่มี governance structure รองรับด้วย

ถ้ากรุงเทพฯ จะสร้าง Urban Operating System สำหรับเรื่องน้ำจริง คำถามสำคัญจึงไม่ใช่แค่ “ใครทำระบบ”

แต่คือ ใครเป็นเจ้าภาพของระบบทั้งวงจร

เพราะเหตุการณ์น้ำท่วมหนึ่งจุดอาจเกี่ยวข้องกับหลายฝ่ายพร้อมกัน ทั้งสำนักการระบายน้ำ สำนักงานเขต หน่วยงานเจ้าของถนน ตำรวจจราจร หรือหน่วยงานระดับประเทศ ขึ้นอยู่กับพื้นที่และสาเหตุของปัญหา

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

เรื่องสุดท้ายคือ Citizen Interface ประชาชนไม่ควรเป็นแค่คนรอรับข้อความแจ้งเตือนจากรัฐ จริงๆ แล้วกรุงเทพฯ มีจุดเริ่มต้นที่ดีอย่าง Traffy Fondue อยู่แล้ว เพราะประชาชนสามารถส่งสิ่งที่เห็นในพื้นที่จริงเข้ามาในระบบได้

โจทย์ถัดไปคือทำอย่างไรให้ข้อมูลเหล่านี้ไม่ได้เป็นเพียง ticket รอเจ้าหน้าที่ปิดงาน แต่กลายเป็นอีก data layer หนึ่งของเมือง

ถ้ามีคนหลายคนแจ้งว่าน้ำกำลังขึ้นเร็วในพื้นที่เดียวกัน ข้อมูลนั้นควรถูกประกอบเข้ากับ radar ฝน ระดับคลอง สถานะเครื่องสูบน้ำ การจราจร และข้อมูลจาก sensor อื่น เพื่อช่วยประเมินว่านี่คือ incident ที่ควรเร่งจัดการหรือไม่

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

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

เพราะฉะนั้น สิ่งที่ผมได้จากหางโจวจึงไม่ใช่ความคิดว่า “จีนมี City Brain กรุงเทพก็ต้องมีบ้าง” และไม่ใช่ว่าเราต้องไปซื้อแพลตฟอร์มเดียวกัน หรือซื้อ dashboard ใหม่มาติดผนังศูนย์บัญชาการ

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

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

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

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

เพราะในวันที่ฝนตกหนัก ความแตกต่างระหว่างเมืองที่ “มีข้อมูล” กับเมืองที่ “ใช้ข้อมูลเป็น” บางทีอาจวัดกันแค่ไม่กี่นาทีนี้เอง 

ถ้ายังต่อวงจรนี้ไม่ได้ ต่อให้มี AI เก่งแค่ไหน มันก็อาจเป็นเพียงอีกหนึ่งหน้าจอสวย ๆ บนผนังศูนย์บัญชาการเท่านั้น