ดูแลระบบ AI ที่รับมอบแล้วให้สังเกตได้ กู้คืนได้ และพร้อมเปลี่ยนแปลง
Maintenance Agreement (MA) คือบริการดูแลหลังส่งมอบที่มีขอบเขต เราตกลงร่วมกันว่าจะ monitor อะไร ใครอนุมัติการเข้าถึงและการเปลี่ยนแปลง จัดการ incident อย่างไร และทบทวนหลักฐานแบบไหน โดยไม่ทำให้ maintenance กลายเป็นคำรับประกันความแม่นยำของ model
MA ดูแลอะไรบ้าง
ขอบเขตจริงขึ้นกับ inventory, ช่วงเวลาที่ดูแล, หน้างาน และสัญญา รายการนี้คือ workstream ที่ต้องยืนยันตอนประเมิน MA
System operations
ตรวจสุขภาพ service, container, runtime, device, storage, compute, อุณหภูมิ, network, queue และ integration
Inventory, health signal และ incident record
Model operations
จัดการ version, release note, สัญญาณ drift และ trigger retraining เมื่อมีข้อมูล label และ acceptance criteria
Model change note และผลประเมิน
Security และ continuity
ทบทวน patch/dependency, backup configuration, ตรวจ restore หรือ rollback และกำหนดทางกู้คืนตาม architecture
Approval, ผลตรวจ backup/restore และ recovery note
Customer enablement
จัดทำ runbook, escalation matrix, รอบทบทวน และการฝึกทีม owner กับผู้ตัดสินใจฝั่งลูกค้า
Health report, decision และ improvement backlog
MA operating lifecycle
- 01
Baseline
บันทึก version, device, model, metric, dependency และ owner ก่อนเริ่มดูแล
System inventory และ baseline report
- 02
Monitor
ติดตาม health, latency, queue, storage, integration และสัญญาณ drift ตาม data boundary
Dashboard/alert และ incident record
- 03
Review
ทบทวนรายเดือนหรือรายไตรมาสกับ owner แยกข้อเท็จจริงที่วัดได้ออกจากสมมติฐาน
Health report และ risk list
- 04
Change
Patch, ปรับจูน หรือ update ผ่าน change request ที่อนุมัติ พร้อม test และ rollback plan
Release note, ผลทดสอบ และ approval
- 05
Recover
ใช้เส้นทาง backup, rollback หรือ spare device ที่ตกลงไว้เมื่อเกิด incident
Recovery evidence และ post-incident note
- 06
Improve
จัดลำดับ improvement ที่ปลอดภัยจากหลักฐาน feedback และ owner ที่รับผิดชอบ
Backlog และวันทบทวนรอบถัดไป
Managed AI Operations เป็นขอบเขตเสริม
Managed AI Operations อาจเพิ่ม monitoring, การประสานงาน review และ operational report เมื่อทีม รูปแบบ access และข้อตกลงรองรับ ไม่ได้รวมโดยอัตโนมัติเพียงเพราะมี MA และไม่ได้โอนการตัดสินใจทางธุรกิจหรือความรับผิดชอบของ model มาให้เรา
- ดูแล monitoring และ triage alert ตามขอบเขต
- ประสาน health review และ risk/backlog ตามรอบ
- ประสาน release, dependency และ compatibility
- ช่วยสื่อสาร incident และซ้อม recovery ตามขอบเขต
Data boundary และ remote access
ค่าเริ่มต้นคือเก็บ business payload ไว้ใน environment ของลูกค้า ส่วน telemetry และทางเข้าถึงจริงต้องยืนยันใน architecture และสัญญา
| พื้นผิวข้อมูล | การจัดการเริ่มต้น | ผู้อนุมัติ / หลักฐาน |
|---|---|---|
| Business payload | ภาพ เอกสาร prompt และ payload ของ workflow อยู่ใน network ลูกค้า เว้นแต่สัญญาจะระบุเป็นอย่างอื่น | Architecture decision และ approval จาก data owner |
| Health telemetry | ส่งออกได้เฉพาะ health metric ที่ตกลง หรือวาง monitoring ไว้ใน environment ลูกค้า | Allow-list, retention และรอบทบทวน |
| Remote support session | ไม่มีสิทธิ์ค้าง แต่ละ session มีผู้อนุมัติ วัตถุประสงค์ วันหมดอายุ และ least-privilege path | Access approval และ audit log |
| Backup และ logs | ที่เก็บ ระยะเวลา การเข้ารหัส และทาง restore เป็นไปตาม architecture และสัญญา | Restore check และ handover inventory |
| Model training | MA ไม่ได้ให้สิทธิ์นำข้อมูลลูกค้าไปฝึก model ของ CerebraTech AI | ต้องมีข้อตกลงเป็นลายลักษณ์อักษรแยก หากเสนอใช้ข้อมูล |
ตัวอย่างโครงสร้าง support — ต้องยืนยันค่าในสัญญา
นี่คือ template สำหรับ workshop ไม่ใช่แพ็กเกจรับประกัน Response หมายถึงการรับเรื่องและเริ่ม triage ส่วน restore และ final resolution ขึ้นกับ access, hardware, data และ third party ของลูกค้า
| ระดับ | ตัวอย่างเหตุการณ์ | Response target | Restore / resolution |
|---|---|---|---|
| S1 | Workflow production หยุดหรือ integration ที่กระทบความปลอดภัยใช้งานไม่ได้ | ต้องตกลง | ต้องตกลง RTO/RPO หรือข้อยกเว้นตาม architecture |
| S2 | ระบบเสื่อมลงอย่างมีนัยสำคัญแต่ยังมีทางชั่วคราว | ต้องตกลง | ต้องตกลง target และรอบอัปเดต |
| S3 | ฟังก์ชันจำกัด รายงานปัญหา หรือ defect ที่ไม่เร่งด่วน | ต้องตกลง | วางแผน change หรือรอบ review ถัดไป |
| S4 | คำถาม คำขอ หรือรายการใน improvement backlog | ต้องตกลง | ทำ change request หากอนุมัติ |
- ช่วงเวลาให้บริการ
- เวลาทำการ, extended hours หรือ 24×7 — ต้องมีค่าที่อนุมัติในสัญญา
- Timezone
- Asia/Bangkok (ICT) เว้นแต่สัญญาจะระบุ clock อื่น
- ช่องทาง
- Ticket เป็นหลัก; phone, chat หรือ on-site ต้องระบุใน scope
- สิ่งที่ลูกค้าต้องเตรียม
- owner, ผู้อนุมัติ access, network, spare/device plan, data label และ support ของ third party
ตัวอย่าง Monthly AI Health Report
เป็น template เท่านั้น ไม่ใช่ผลของลูกค้าหรือ benchmark
Executive summary
สถานะ Green / Amber / Red การเปลี่ยนแปลงสำคัญ และ decision ที่ต้องการ
System health
Availability, latency, queue/failure, storage และ resource signal ที่วัดจริง
Model และ data signal
Drift proxy, human review และบริบทการประเมินเมื่อมี label และวิธีวัด
Incident และ change
Response, restore, root-cause note, patch, approval และความพร้อม rollback
Risk และ next step
สิ่งที่ลูกค้าต้องตัดสินใจ owner วันครบกำหนด และ improvement backlog
Handover และ offboarding เป็นส่วนหนึ่งของบริการ
สัญญาต้องบันทึกว่าแต่ละฝ่ายเป็นเจ้าของอะไร เมื่อส่งมอบหรือจบงานจะคืนหรือเพิกถอน access และส่งมอบเอกสารตามข้อตกลง ไม่ใช่คำรับรองว่าไม่มี lock-in
| พื้นที่ | เจ้าของฝั่งลูกค้า | ความรับผิดชอบของบริการ | หลักฐานส่งมอบ / ออกจากงาน |
|---|---|---|---|
| Business data และการตัดสินใจ | Data owner และผู้อนุมัติปฏิบัติการ | ประมวลผลภายใน data boundary ที่ตกลง | Data map และ decision record |
| Code, model และ configuration | รับรอง version และตัดสินใจ change | ดูแลเฉพาะ component/dependency ที่ระบุ | Version inventory และ release note |
| Access และ operations | อนุมัติ session และเตรียม dependency หน้างาน | ใช้ least privilege และเก็บ audit trail | Access log, revocation และ runbook |
| จบ MA | ยืนยัน acceptance และ owner ผู้รับต่อ | ส่ง inventory/log export ตามตกลงและลบ access ของเรา | Offboarding checklist และ outstanding-risk note |
สิ่งที่ MA ไม่ได้สัญญา
- ความแม่นยำของ model โดยไม่มี dataset, วิธีวัด และ acceptance criteria
- Feature ใหม่ retraining หรือเปลี่ยน hardware โดยไม่มี change request
- ความรับผิดชอบ network หรือ cloud ของ third party หากสัญญาไม่ได้ระบุ
- การรับประกัน hardware, zero downtime หรือ zero lock-in
- สิทธิ์นำ payload ของลูกค้าไปฝึก model ของ CerebraTech AI
เริ่มจาก support-scope workshop
เล่าว่าระบบใดอยู่ production แล้ว อะไรหยุดไม่ได้ มีหลักฐานอะไร และใครอนุมัติ access ขั้นต่อไปคือ MA assessment หรือ workshop เพื่อกำหนดขอบเขต ไม่ใช่ใบเสนอราคาอัตโนมัติ
ขอประเมิน MA