เม็ดเงินระดมทุนและผู้สนับสนุน

เงินลงทุนรอบ Pre-Seed 5.7 ล้านยูโร (ประมาณ 6 ล้านดอลลาร์สหรัฐ) นำร่วมโดย Cherry Ventures และ Redstone โดยมี Angel Invest, Linden Capital และนักลงทุน Angel รายอื่นๆ เข้าร่วมด้วย นี่คือการระดมทุนจากภายนอกครั้งแรกที่ INXM เปิดเผย บริษัทวางแผนที่จะใช้เงินทุนนี้เพื่อขยายทีม เร่งการพัฒนาผลิตภัณฑ์ในส่วนของ Engine ที่ชื่อ Orchestrator และขยายฐานลูกค้าในกลุ่มบริษัทอุตสาหกรรมในยุโรป

ทีมผู้ก่อตั้ง: จากจรวดสู่วงจรการทำงานที่น่าเชื่อถือ

INXM ก่อตั้งในปี 2025 โดยคนสี่คนที่ใช้ชีวิตการทำงานที่ผ่านมากับการทำให้ระบบซับซ้อนที่วิกฤตต่อความปลอดภัยทำงานได้อย่างคาดการณ์ได้:

• Alexander (Alex) Oelling, CEO — อดีต Chief Digital Officer ที่ Isar Aerospace และ Volocopter
• Matthias Kainer — ผู้สร้างระบบประสานการปล่อยจรวด (Launch Orchestration Systems) ที่ Isar Aerospace
• Jesper Bylund — ผู้ออกแบบ Flight Control Interfaces และเคยทำงานที่แพลตฟอร์ม Automation อย่าง n8n
• Kamil Klüber — ทหารผ่านศึกจากบริษัทที่ปรึกษาด้านซอฟต์แวร์ Thoughtworks

DNA ด้านอวกาศนี้ไม่ใช่แค่ประวัติย่อ—แต่มันอธิบายปรัชญาทางเทคนิคทั้งหมดของบริษัท ซอฟต์แวร์ปล่อยจรวดต้องปฏิบัติตามลำดับคำสั่งแบบตายตัวภายใต้การตรวจสอบความถูกต้องที่เข้มงวด มันไม่สามารถด้นสดได้ ทีมงานได้นำกรอบคิดแบบเดียวกันนี้มาใช้กับ AI สำหรับองค์กร

เหตุใดเครื่องมือ AI องค์กรมาตรฐานจึงล้มเหลว

เครื่องมืออัตโนมัติที่ใช้ LLM ส่วนใหญ่จะเรียกใช้ LLM ในทุกขั้นตอนของ Workflow นั่นสร้างปัญหาหนักสามประการสำหรับธุรกิจที่ต้องอยู่ภายใต้กฎระเบียบ:

• ความไม่แน่นอน (Non-determinism) คำสั่ง (Prompt) เดียวกันสามารถสร้างการกระทำหรือผลลัพธ์ที่แตกต่างกันในแต่ละครั้งที่ทำงาน ทำให้การปฏิบัติตามกฎระเบียบและเส้นทางการตรวจสอบ (Audit Trails) แทบจะเป็นไปไม่ได้
• ความเสี่ยงจากการมโน (Hallucination Risk) โมเดลที่สร้างขั้นตอนการอนุมัติขึ้นมาเองหรือข้ามขั้นตอนการตรวจสอบความปลอดภัยก่อให้เกิดภาระรับผิดชอบที่ยอมรับไม่ได้ในการผลิตหรือการเงิน
• อธิปไตยของข้อมูล (Data Sovereignty) การส่งข้อมูลการผลิตที่อ่อนไหวไปยัง LLM API ของบุคคลที่สามขัดแย้งกับ GDPR, พ.ร.บ. AI ของสหภาพยุโรป (EU AI Act) และนโยบายความปลอดภัยภายใน

ผลลัพธ์ก็คือบริษัทอุตสาหกรรมหลายแห่งประเมิน AI Agent แต่ไม่เคยปรับใช้ในระบบจริง (Production) เลย เทคโนโลยีดูมีพลังในเดโม แต่ไม่สามารถผ่านเกณฑ์ความน่าเชื่อถือที่ซอฟต์แวร์ในโรงงานบังคับใช้มานานหลายทศวรรษได้

Compiled AI ทำงานแตกต่างอย่างไร

Orchestrator Engine ของ INXM ยืมสถาปัตยกรรมของคอมไพเลอร์ซอฟต์แวร์แบบดั้งเดิมมากกว่าวงจรแชทบอท กระบวนการแบ่งออกเป็นสองช่วงที่แตกต่างกัน:

1. ช่วงการคอมไพล์ (Compilation Phase) ผู้ใช้บรรยายกระบวนการทางธุรกิจด้วยภาษาธรรมชาติ (Natural Language) จากนั้น LLM จะสร้าง "แผน" (Plan) ที่มีโครงสร้าง สมบูรณ์ และพร้อมปฏิบัติการ—โดยพื้นฐานแล้วคือโค้ดที่ตายตัว—และแผนนั้นจะถูกตรวจสอบความถูกต้องก่อนที่จะได้รับอนุญาตให้ทำงาน โมเดลจะถูกใช้เพียงครั้งเดียว ระหว่างการสร้างขั้นตอน ไม่ใช่ตอนประมวลผลจริง (Transaction Time)

2. ช่วงปฏิบัติการ (Execution Phase) แผนที่ผ่านการตรวจสอบแล้วจะทำงานบน Orchestrator Engine ของ INXM โดยไม่มีการเรียก LLM อีกต่อไป Engine จะประสานงานกับระบบที่มีอยู่ขององค์กร—ไม่ว่าจะเป็น ERP, PLM, MES, อีเมล, และเครื่องมือขออนุมัติ—โดยทำงานตามลำดับขั้นตอนเดิมในลำดับเดิมทุกครั้ง

ความแตกต่างทางเทคนิคชัดเจนมาก: Agent มาตรฐานเรียกใช้ LLM ทุกขั้นตอน (ไม่แน่นอน, สิ้นเปลือง Token, ตรวจสอบยาก) ส่วน INXM คอมไพล์ครั้งเดียว แล้วรันโปรแกรมที่ตายตัว ผลลัพธ์จึงสามารถทำซ้ำได้ (Reproducible) ทดสอบได้ และปราศจากการมโนระหว่างการทำงาน (Runtime Hallucinations) บริษัทเรียกสิ่งนี้ว่าความยืดหยุ่นของภาษาธรรมชาติรวมกับความน่าเชื่อถือของโค้ดแบบดั้งเดิม

เพื่อให้แนวคิดนี้เป็นรูปธรรม ลองนึกถึง Workflow การตรวจสอบคุณภาพในโรงงาน: วิศวกรบรรยายขั้นตอนการอนุมัติและการตรวจสอบข้อมูลที่จำเป็นด้วยภาษาทั่วไป Orchestrator จะคอมไพล์สิ่งนั้นเป็นลำดับขั้นตอนที่ตายตัว, ผู้จัดการอนุมัติครั้งเดียว, แล้ว Workflow ก็จะทำงานเหมือนกันทุกประการทุกครั้งที่มีเหตุการณ์ที่เกี่ยวข้องเกิดขึ้น—โดยไม่มีข้อมูลใดถูกส่งออกไปภายนอกอาคารหรือเสี่ยงต่อการที่โมเดลจะต้นสด

โครงสร้างพื้นฐาน, การปฏิบัติตามกฎระเบียบ, และกลุ่มเป้าหมายภาคอุตสาหกรรม

เนื่องจาก Orchestrator ทำงานบนโครงสร้างพื้นฐานขององค์กรเอง—ไม่ว่าจะเป็นบนเครื่องเซิร์ฟเวอร์ภายในองค์กร (On-Premises) หรือในคลาวด์ส่วนตัว (Private Cloud)—ข้อมูลการผลิตจึงไม่มีวันออกจากอาคาร สถาปัตยกรรมนี้ทำให้ระบบเป็นไปตามข้อกำหนดของ GDPR และ พ.ร.บ. AI ของสหภาพยุโรป โดยการออกแบบ และยังช่วยให้ INXM เข้าถึงซอฟต์แวร์ในโรงงานที่เครื่องมืออัตโนมัติแบบคลาวด์เท่านั้นไม่สามารถเข้าถึงได้ทางกายภาพ

บริษัทระบุกลุ่มเป้าหมายอย่างชัดเจนคือผู้ผลิตในภาคอุตสาหกรรมและ Mittelstand ของเยอรมนี ซึ่งก็คือบริษัทที่มีระบบแบบ On-Premises รุ่นเก่า มีภาระผูกพันด้านกฎระเบียบ และมีข้อกำหนดที่เข้มงวดในเรื่องการทำซ้ำได้ นี่ไม่ใช่กลยุทธ์การตลาดแบบแนวกว้าง (Horizontal Automation) แต่มันถูกสร้างขึ้นมาเพื่อองค์กรที่ปฏิเสธ AI Agent แบบทั่วไปไปแล้วเพราะไม่สามารถไว้ใจได้ในระบบจริง

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

เม็ดเงินระดมทุนและผู้สนับสนุน

เงินลงทุนรอบ Pre-Seed 5.7 ล้านยูโร (ประมาณ 6 ล้านดอลลาร์สหรัฐ) นำร่วมโดย Cherry Ventures และ Redstone โดยมี Angel Invest, Linden Capital และนักลงทุน Angel รายอื่นๆ เข้าร่วมด้วย นี่คือการระดมทุนจากภายนอกครั้งแรกที่ INXM เปิดเผย บริษัทวางแผนที่จะใช้เงินทุนนี้เพื่อขยายทีม เร่งการพัฒนาผลิตภัณฑ์ในส่วนของ Engine ที่ชื่อ Orchestrator และขยายฐานลูกค้าในกลุ่มบริษัทอุตสาหกรรมในยุโรป

ทีมผู้ก่อตั้ง: จากจรวดสู่วงจรการทำงานที่น่าเชื่อถือ

INXM ก่อตั้งในปี 2025 โดยคนสี่คนที่ใช้ชีวิตการทำงานที่ผ่านมากับการทำให้ระบบซับซ้อนที่วิกฤตต่อความปลอดภัยทำงานได้อย่างคาดการณ์ได้:

• Alexander (Alex) Oelling, CEO — อดีต Chief Digital Officer ที่ Isar Aerospace และ Volocopter
• Matthias Kainer — ผู้สร้างระบบประสานการปล่อยจรวด (Launch Orchestration Systems) ที่ Isar Aerospace
• Jesper Bylund — ผู้ออกแบบ Flight Control Interfaces และเคยทำงานที่แพลตฟอร์ม Automation อย่าง n8n
• Kamil Klüber — ทหารผ่านศึกจากบริษัทที่ปรึกษาด้านซอฟต์แวร์ Thoughtworks

DNA ด้านอวกาศนี้ไม่ใช่แค่ประวัติย่อ—แต่มันอธิบายปรัชญาทางเทคนิคทั้งหมดของบริษัท ซอฟต์แวร์ปล่อยจรวดต้องปฏิบัติตามลำดับคำสั่งแบบตายตัวภายใต้การตรวจสอบความถูกต้องที่เข้มงวด มันไม่สามารถด้นสดได้ ทีมงานได้นำกรอบคิดแบบเดียวกันนี้มาใช้กับ AI สำหรับองค์กร

เหตุใดเครื่องมือ AI องค์กรมาตรฐานจึงล้มเหลว

เครื่องมืออัตโนมัติที่ใช้ LLM ส่วนใหญ่จะเรียกใช้ LLM ในทุกขั้นตอนของ Workflow นั่นสร้างปัญหาหนักสามประการสำหรับธุรกิจที่ต้องอยู่ภายใต้กฎระเบียบ:

• ความไม่แน่นอน (Non-determinism) คำสั่ง (Prompt) เดียวกันสามารถสร้างการกระทำหรือผลลัพธ์ที่แตกต่างกันในแต่ละครั้งที่ทำงาน ทำให้การปฏิบัติตามกฎระเบียบและเส้นทางการตรวจสอบ (Audit Trails) แทบจะเป็นไปไม่ได้
• ความเสี่ยงจากการมโน (Hallucination Risk) โมเดลที่สร้างขั้นตอนการอนุมัติขึ้นมาเองหรือข้ามขั้นตอนการตรวจสอบความปลอดภัยก่อให้เกิดภาระรับผิดชอบที่ยอมรับไม่ได้ในการผลิตหรือการเงิน
• อธิปไตยของข้อมูล (Data Sovereignty) การส่งข้อมูลการผลิตที่อ่อนไหวไปยัง LLM API ของบุคคลที่สามขัดแย้งกับ GDPR, พ.ร.บ. AI ของสหภาพยุโรป (EU AI Act) และนโยบายความปลอดภัยภายใน

ผลลัพธ์ก็คือบริษัทอุตสาหกรรมหลายแห่งประเมิน AI Agent แต่ไม่เคยปรับใช้ในระบบจริง (Production) เลย เทคโนโลยีดูมีพลังในเดโม แต่ไม่สามารถผ่านเกณฑ์ความน่าเชื่อถือที่ซอฟต์แวร์ในโรงงานบังคับใช้มานานหลายทศวรรษได้

Compiled AI ทำงานแตกต่างอย่างไร

Orchestrator Engine ของ INXM ยืมสถาปัตยกรรมของคอมไพเลอร์ซอฟต์แวร์แบบดั้งเดิมมากกว่าวงจรแชทบอท กระบวนการแบ่งออกเป็นสองช่วงที่แตกต่างกัน:

1. ช่วงการคอมไพล์ (Compilation Phase) ผู้ใช้บรรยายกระบวนการทางธุรกิจด้วยภาษาธรรมชาติ (Natural Language) จากนั้น LLM จะสร้าง "แผน" (Plan) ที่มีโครงสร้าง สมบูรณ์ และพร้อมปฏิบัติการ—โดยพื้นฐานแล้วคือโค้ดที่ตายตัว—และแผนนั้นจะถูกตรวจสอบความถูกต้องก่อนที่จะได้รับอนุญาตให้ทำงาน โมเดลจะถูกใช้เพียงครั้งเดียว ระหว่างการสร้างขั้นตอน ไม่ใช่ตอนประมวลผลจริง (Transaction Time)

2. ช่วงปฏิบัติการ (Execution Phase) แผนที่ผ่านการตรวจสอบแล้วจะทำงานบน Orchestrator Engine ของ INXM โดยไม่มีการเรียก LLM อีกต่อไป Engine จะประสานงานกับระบบที่มีอยู่ขององค์กร—ไม่ว่าจะเป็น ERP, PLM, MES, อีเมล, และเครื่องมือขออนุมัติ—โดยทำงานตามลำดับขั้นตอนเดิมในลำดับเดิมทุกครั้ง

ความแตกต่างทางเทคนิคชัดเจนมาก: Agent มาตรฐานเรียกใช้ LLM ทุกขั้นตอน (ไม่แน่นอน, สิ้นเปลือง Token, ตรวจสอบยาก) ส่วน INXM คอมไพล์ครั้งเดียว แล้วรันโปรแกรมที่ตายตัว ผลลัพธ์จึงสามารถทำซ้ำได้ (Reproducible) ทดสอบได้ และปราศจากการมโนระหว่างการทำงาน (Runtime Hallucinations) บริษัทเรียกสิ่งนี้ว่าความยืดหยุ่นของภาษาธรรมชาติรวมกับความน่าเชื่อถือของโค้ดแบบดั้งเดิม

เพื่อให้แนวคิดนี้เป็นรูปธรรม ลองนึกถึง Workflow การตรวจสอบคุณภาพในโรงงาน: วิศวกรบรรยายขั้นตอนการอนุมัติและการตรวจสอบข้อมูลที่จำเป็นด้วยภาษาทั่วไป Orchestrator จะคอมไพล์สิ่งนั้นเป็นลำดับขั้นตอนที่ตายตัว, ผู้จัดการอนุมัติครั้งเดียว, แล้ว Workflow ก็จะทำงานเหมือนกันทุกประการทุกครั้งที่มีเหตุการณ์ที่เกี่ยวข้องเกิดขึ้น—โดยไม่มีข้อมูลใดถูกส่งออกไปภายนอกอาคารหรือเสี่ยงต่อการที่โมเดลจะต้นสด

โครงสร้างพื้นฐาน, การปฏิบัติตามกฎระเบียบ, และกลุ่มเป้าหมายภาคอุตสาหกรรม

เนื่องจาก Orchestrator ทำงานบนโครงสร้างพื้นฐานขององค์กรเอง—ไม่ว่าจะเป็นบนเครื่องเซิร์ฟเวอร์ภายในองค์กร (On-Premises) หรือในคลาวด์ส่วนตัว (Private Cloud)—ข้อมูลการผลิตจึงไม่มีวันออกจากอาคาร สถาปัตยกรรมนี้ทำให้ระบบเป็นไปตามข้อกำหนดของ GDPR และ พ.ร.บ. AI ของสหภาพยุโรป โดยการออกแบบ และยังช่วยให้ INXM เข้าถึงซอฟต์แวร์ในโรงงานที่เครื่องมืออัตโนมัติแบบคลาวด์เท่านั้นไม่สามารถเข้าถึงได้ทางกายภาพ

บริษัทระบุกลุ่มเป้าหมายอย่างชัดเจนคือผู้ผลิตในภาคอุตสาหกรรมและ Mittelstand ของเยอรมนี ซึ่งก็คือบริษัทที่มีระบบแบบ On-Premises รุ่นเก่า มีภาระผูกพันด้านกฎระเบียบ และมีข้อกำหนดที่เข้มงวดในเรื่องการทำซ้ำได้ นี่ไม่ใช่กลยุทธ์การตลาดแบบแนวกว้าง (Horizontal Automation) แต่มันถูกสร้างขึ้นมาเพื่อองค์กรที่ปฏิเสธ AI Agent แบบทั่วไปไปแล้วเพราะไม่สามารถไว้ใจได้ในระบบจริง

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