Barclays ตั้งเป้าให้ครึ่งหนึ่งของนักพัฒนาใช้ Claude Code—บทเรียน rollout AI ในองค์กรการเงินไม่ได้อยู่ที่ยอด adoption

วันที่ 1 ตุลาคม 2026 Anthropic ประกาศว่า Barclays จะขยายการใช้ Claude ในธนาคาร โดยตั้งเป้าให้ 50% ของนักพัฒนาใช้ Claude Code ภายในสิ้นปี 2026 และให้ “คนส่วนใหญ่” ใช้ภายในปี 2027 ตัวเลขนี้ฟังดูเหมือนการแข่งขันติดตั้งเครื่องมือให้เร็วที่สุด แต่สำหรับองค์กรการเงิน คำถามสำคัญกว่าไม่ใช่ “มีกี่คนเปิดใช้” ครับ คำถามคือ งานแบบไหนผ่านการควบคุมแล้ว คุณภาพดีขึ้นเท่าไร และเมื่อ AI ทำผิดใครหยุดมันได้ทัน

ผมตรวจประกาศของ Anthropic เทียบรายงานที่เผยแพร่ผ่าน Yahoo Finance/Bloomberg, บทสรุปของ Silicon Report และบริบท sandbox ของหน่วยงานกำกับการเงินอังกฤษ FCA ตัวเลขการใช้งานหลายรายการในข่าวมาจาก Barclays และ Anthropic เอง ยังไม่ใช่ audit อิสระของผลผลิตหรือผลตอบแทนครับ

สรุป 30 วินาที

• Barclays บอกว่ามีพนักงานประมาณ 16,000 คนใช้ Claude ในงานภายในแล้ว มีการค้นหาประมาณหนึ่งล้านครั้ง และช่วยงานอีเมลในระดับราว 120,000 ฉบับต่อวัน ตัวเลขเหล่านี้เป็นปริมาณการใช้ ไม่ใช่หลักฐานว่าทุกผลลัพธ์ถูกต้องหรือประหยัดเงินเท่าไร
• แผนใหม่เพิ่ม Claude Code ให้ทีมพัฒนาซอฟต์แวร์ ตั้งเป้า adoption 50% ภายในสิ้นปี 2026 และขยายไปยังคนส่วนใหญ่ในปี 2027 คำว่าเป้าหมายต่างจากผลสำเร็จ เพราะประกาศวันที่ 1 ตุลาคมเหลือเวลาราวสามเดือนให้พิสูจน์การใช้งานจริง
• Bloomberg รายงานบริบทว่า Barclays มีเป้าประสิทธิภาพมูลค่า 2 พันล้านปอนด์ซึ่งรวม AI แต่ไม่ควรตีความว่า Claude สร้างผลประหยัดทั้งหมดนั้น ตัวเลขบริษัทระดับนี้มาจากหลายโครงการและหลายปี
• Anthropic ระบุเรื่อง governance, human oversight และการขยายภายใต้ข้อกำหนดของธนาคาร แต่เอกสารสาธารณะไม่ได้เผยค่า defect, security incident, false positive, เวลาที่คนใช้ตรวจ หรือรายละเอียด data boundary ครบพอให้คนนอกประเมินระบบทั้งหมด
• บทเรียนสำหรับองค์กรอื่นคืออย่าใช้ seat activation เป็น North Star เพียงตัวเดียว ควรวัดงานที่ยอมรับได้, เวลารวมถึง review, defect ที่หลุด, สิทธิ์เครื่องมือ, การรั่วข้อมูล และความสามารถ rollback พร้อมกัน

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

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

นักพัฒนาได้รับผลตรงที่สุด Claude Code สามารถช่วยอ่านโค้ด เสนอ patch รันคำสั่ง หรือช่วยไล่ปัญหาได้ตามสิทธิ์ที่องค์กรเปิด แต่โค้ดในธนาคารไม่ได้จบที่ “compile ผ่าน” ยังมีข้อกำหนดเรื่อง segregation of duties, audit trail, change approval, dependency policy และข้อมูลที่ห้ามออกนอกขอบเขต เครื่องมือจึงต้องเข้ากับ SDLC เดิม ไม่ใช่ยกเว้นกฎเพราะคำตอบดูฉลาด

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

ทำงานยังไง: จากบัตรพนักงานสู่ระบบตรวจหลายด่าน

การ rollout เครื่องมือแบบนี้มีอย่างน้อยสี่ชั้น

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

ชั้นที่สองคือ context Claude ต้องได้รับข้อมูลพอทำงาน แต่ไม่ควรเห็นเกินสิทธิ์ วิธีที่ดีคือดึง context ตามคำขอและตามสิทธิ์ ณ เวลานั้น เหมือนพนักงานห้องเอกสารหยิบแฟ้มเฉพาะเคส ไม่ใช่ยกตู้เอกสารมาวางบนโต๊ะ context ยังรวม prompt จาก issue, README หรือเว็บภายนอก ซึ่งอาจมีคำสั่งแฝงพยายามหลอก agent ให้ทำเกินงานได้

ชั้นที่สามคือ action การอ่านโค้ดกับการแก้ไฟล์มีความเสี่ยงต่างกัน การแก้ไฟล์กับการรัน shell ต่างกันอีก การเปิด network, อ่าน secret หรือ deploy ควรอยู่คนละระดับอนุมัติ หลักสิทธิ์น้อยที่สุดทำให้เริ่มจาก read-only, จำกัด workspace, allowlist คำสั่ง และให้คนยืนยันเมื่อจะทำสิ่งที่ย้อนกลับยาก

ชั้นที่สี่คือ evidence ทุกคำแนะนำสำคัญต้องย้อนดูได้ว่าใช้ข้อมูลอะไร เปลี่ยนไฟล์ไหน รัน test อะไร และใครอนุมัติ เปรียบเหมือนใบเสร็จในร้านข้าว เราไม่ได้เก็บเพราะไม่ไว้ใจแม่ครัว แต่เก็บเพื่อรู้ว่าเมนูไหนสั่งอะไร ถ้าลูกค้าทักว่าผิดจะหาจุดได้ ระบบ AI ที่ไม่มี trace ทำให้ post-incident review กลายเป็นการเดา

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

FCA เคยประกาศ Supercharged Sandbox ร่วมกับ Anthropic เพื่อให้องค์กรการเงินทดลอง AI ภายใต้สภาพแวดล้อมกำกับ ประเด็นสำคัญของ sandbox ไม่ใช่ตราประทับว่าเครื่องมือปลอดภัย แต่คือพื้นที่จำกัดสำหรับพิสูจน์ข้อสมมติฐาน เก็บหลักฐาน และหยุดได้เมื่อผลไม่เป็นไปตามคาด องค์กรทั่วไปทำแนวคิดเดียวกันได้ด้วย canary team, ข้อมูลจำลอง, repository ความเสี่ยงต่ำ และ quota จำกัด

เงินและผลกระทบ: ตัวเลขการใช้ไม่ใช่ผลตอบแทน

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

metric ที่ควรจับคู่กับ adoption ได้แก่:

• time to accepted outcome ตั้งแต่เริ่มงานจน reviewer ยอมรับ ไม่ใช่เวลาที่ AI สร้าง draft
• first-pass acceptance rate งานผ่านรอบแรกกี่เปอร์เซ็นต์
• escaped defect ข้อผิดพลาดจากงานที่มี AI ช่วยแล้วหลุดสู่ขั้นถัดไป
• review burden เวลาที่คนใช้ตรวจและแก้
• security exception จำนวนครั้งที่ผู้ใช้ขอสิทธิ์เพิ่มหรือพยายามออกนอก workflow
• rollback rate patch หรือข้อความที่ต้องย้อนกลับ
• cost per accepted task รวม license, inference, support และเวลาคน

Bloomberg วางข่าวนี้ข้างเป้าประสิทธิภาพ 2 พันล้านปอนด์ของ Barclays แต่ความเชื่อมโยงไม่ได้แปลว่าตัวเลขทั้งหมดมาจาก Claude บริษัทอาจมีการปรับกระบวนการ ลดระบบเดิม หรือโครงการเทคโนโลยีอื่นร่วมด้วย การเขียน business case ที่ซื่อสัตย์ควรระบุ attribution ว่า AI มีส่วนตรงไหน และส่วนไหนยังเป็นสมมติฐาน

อีกต้นทุนที่มองไม่เห็นคือ concentration risk เมื่อ workflow จำนวนมากผูกกับผู้ให้บริการหนึ่งราย หาก API เปลี่ยน ราคาเปลี่ยน หรือเกิด outage ธนาคารต้องมีเส้นทางทำงานต่อได้ การออกแบบ abstraction, export log, model fallback และ manual procedure ไม่ได้ลดคุณค่าของเครื่องมือ แต่ช่วยไม่ให้ความสำเร็จกลายเป็นการล็อกตัวเองครับ

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

แหล่งข่าวเห็นตรงกันเรื่องเป้าหมาย 50% ภายในปี 2026 และการขยายต่อในปี 2027 แต่รายละเอียดคำว่า “adoption” ยังไม่ชัด มันอาจหมายถึงคนที่เปิดใช้ครั้งหนึ่ง คนที่ใช้งานรายสัปดาห์ หรือคนที่มีงาน production ผ่าน Claude Code หากนิยามต่างกัน ตัวเลขเดียวกันมีความหมายต่างกันมาก

ตัวเลข 16,000 คน หนึ่งล้านการค้นหา และอีเมล 120,000 ฉบับต่อวันมาจากประกาศคู่ค้าหรือคำให้ข้อมูลของบริษัท ยังไม่มีรายงานอิสระที่แสดง sampling, ช่วงเวลา, baseline และ error rate เราจึงใช้เพื่อเห็นขนาด ไม่ควรใช้ยืนยัน productivity uplift

รายงาน Bloomberg เชื่อมการขยาย AI กับเป้าประสิทธิภาพของธนาคาร ขณะที่ประกาศ Anthropic เน้นการใช้งานและ governance มากกว่า ไม่มีแหล่งใดเผยว่าค่าใช้จ่ายของ Claude เท่าไร ประหยัดชั่วโมงคนสุทธิเท่าไร หรือคืนทุนเมื่อไร ข้อมูลนี้อาจเป็นความลับทางการค้า แต่การไม่มีข้อมูลหมายความว่าคนนอกยังสรุป ROI ไม่ได้

เรายังไม่รู้รายละเอียดการเก็บข้อมูล, retention, region, redaction, model training policy, การเชื่อม MCP หรือเครื่องมือภายใน และระดับ network access ของ Claude Code ใน Barclays รวมทั้งไม่รู้ว่า security review จัดการ prompt injection จาก repository อย่างไร การไม่มีรายละเอียดไม่ใช่หลักฐานว่าทำไม่ดี แต่ก็ไม่ใช่หลักฐานว่าองค์กรอื่นทำตามแล้วจะปลอดภัย

FCA sandbox เป็นบริบทที่บอกว่าหน่วยงานกำกับต้องการให้ทดลองอย่างมีกรอบ ไม่ได้ยืนยันว่า rollout ของ Barclays ผ่านการรับรองเฉพาะจาก FCA หรือว่าเครื่องมือทุก use case ได้รับอนุมัติแล้ว ต้องระวังไม่เอาชื่อหน่วยงานกำกับไปต่อท้ายเป็นตราประทับที่แหล่งข่าวไม่ได้กล่าวครับ

ควรทำอะไร

สำหรับ CTO และหัวหน้าวิศวกรรม เริ่มจากงานที่ย้อนกลับได้และมี test ชัด เช่น อธิบายโค้ด สร้าง unit test หรือเสนอ refactor ใน branch จำกัด ตั้ง metric ก่อนแจก license และประกาศให้ชัดว่า adoption หมายถึงงานที่ผ่านเกณฑ์ ไม่ใช่จำนวนคน login

สำหรับ platform team ทำ policy-as-code สำหรับ filesystem, shell, network, MCP และ secret แยกตามกลุ่มงาน เริ่ม read-only และให้สิทธิ์แบบชั่วคราวเมื่อมีเหตุผล เก็บ tool trace กับ diff แต่ redaction ข้อมูลลับก่อนเข้าระบบวิเคราะห์ telemetry

สำหรับ security และ compliance ทำ threat model ที่รวม prompt injection, poisoned repository instruction, dependency confusion, data exfiltration และคำสั่งลบไฟล์ ทดสอบด้วย canary token และข้อมูลจำลอง จัด incident path ว่าใครหยุดการใช้งานองค์กรและเก็บหลักฐานอย่างไร

สำหรับทีมพัฒนา ถือ output เป็น code review candidate ไม่ใช่คำตอบสุดท้าย รัน test, lint, secret scan และ dependency policy ตามปกติ ห้ามให้ AI merge, deploy หรืออ่าน production credential เพียงเพราะ patch เล็ก และบันทึกส่วนที่คนตัดสินใจเอง

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

สำหรับพนักงานทั่วไป ใช้ช่องทางองค์กรเท่านั้น ไม่วางข้อมูลลูกค้าหรือ secret ลงใน prompt ถ้า policy ไม่อนุญาต และตรวจชื่อผู้รับ ตัวเลข เงื่อนไข กับไฟล์แนบทุกครั้งก่อนส่งข้อความที่ AI ช่วยร่าง

Recap

• แยก “เป้าหมาย 50%” ออกจากผล adoption ที่วัดได้จริง
• ถือ 16,000 ผู้ใช้ หนึ่งล้านการค้นหา และ 120,000 อีเมลเป็นตัวเลขจากคู่ประกาศ ไม่ใช่ audit ผลลัพธ์
• วัด time to accepted outcome, defect, review burden และ cost per accepted task ควบคู่กับจำนวนผู้ใช้
• ให้ Claude Code เริ่มจาก read-only, workspace จำกัด และไม่มี production secret
• แยกสิทธิ์อ่าน แก้ไฟล์ รัน shell เปิด network และ deploy ออกจากกัน
• เก็บ trace, diff, test และผู้อนุมัติให้ย้อนตรวจได้ โดย redaction ข้อมูลลับ
• ทำ fallback และ manual procedure เผื่อผู้ให้บริการล่มหรือ policy เปลี่ยน
• อย่าใช้ชื่อหน่วยงานกำกับเป็นตรารับรองเกินกว่าที่แหล่งทางการกล่าว

ข่าวนี้สำคัญเพราะแสดงว่า AI coding agent กำลังเข้าสู่องค์กรที่มีกฎเข้มในระดับหลายหมื่นคนครับ แต่สิ่งที่ควรเลียนแบบไม่ใช่ตัวเลข 50% สิ่งที่ควรเลียนแบบคือการตั้งกรอบทดลอง วัดผลที่ยอมรับได้ และทำให้ทุก action ย้อนตรวจได้ ถ้าทำสามอย่างนี้ adoption จะเป็นผลของคุณค่าจริง ไม่ใช่งานรณรงค์เปิดใช้เครื่องมือครับ