INXM 獲得 570 萬歐元，要用「編譯式 AI」讓企業級人工智慧不再胡言亂語

創辦團隊：從發射火箭到打造可靠的作業流程

INXM 由四位在職業生涯中讓極度複雜、事關人命安全的關鍵系統穩定運作的人共同創立於 2025 年：

• Alexander (Alex) Oelling，執行長——曾任 Isar Aerospace（德國火箭製造商）與 Volocopter（空中計程車先驅）的數位長。
• Matthias Kainer——曾在 Isar Aerospace 建構火箭發射的協調系統。
• Jesper Bylund——設計過飛行控制介面，也曾任職於自動化平台 n8n。
• Kamil Klüber——軟體顧問公司 Thoughtworks 的資深成員。

這群人的航太背景並不是履歷上的裝飾——它解釋了整家公司的技術哲學。火箭發射軟體必須在嚴格的驗證下，執行完全命中註定的步驟，沒有即興發揮的空間。團隊就是把這套心智模型，原封不動地應用到企業 AI 上。

為什麼標準的企業級 AI 代理人會失敗

目前多數以 LLM 為基礎的自動化工具，在作業流程的每一個步驟都去呼叫語言模型。這為受監管的企業帶來了三個難題：

• 非確定性。 同樣的提示詞，可能在不同次執行中產生不同的行動或輸出，讓合規與審計軌跡幾乎無法建立。
• 幻覺風險。 模型若憑空捏造一個審核步驟，或跳過某項安全檢查，將為製造業或金融業帶來無法承受的責任。
• 數據主權。 將敏感的生產數據傳送給第三方 LLM 的 API，直接抵觸《一般資料保護規則》（GDPR）、《歐盟人工智慧法案》（EU AI Act）與內部資安政策。

結果就是，許多工業公司在評估 AI 代理人後，始終不敢在正式產線上部署。這種技術在展示中看起來很強大，但達不到工廠現場軟體數十年來堅守的可靠性門檻。

「編譯式 AI」如何以不同方式運作

INXM 的 Orchestrator 引擎，借用了傳統軟體編譯器的架構，而不是聊天機器人的迴圈。整個流程拆分為兩個截然不同的階段：

1. 編譯階段。 使用者用自然語言描述一個商業流程。LLM 生成一份完整、結構化、可執行的「計畫」（Plan）——本質上就是命中註定的程式碼——並在獲准執行之前就完成驗證。模型只會在編寫階段使用一次，並非在每次交易時都呼叫。

2. 執行階段。 經過驗證的計畫在 INXM 的 Orchestrator 引擎上運行，不再呼叫任何 LLM。引擎會協調公司內既有的系統——ERP、PLM、MES、電子郵件與審核工具——每次都按照相同的順序執行相同的步驟。

技術上的差異非常明顯：標準 AI 代理人在每一個步驟都呼叫 LLM（非確定性、消耗大量 Token、難以稽核）。INXM 則是編譯一次，然後執行一個固定的程式。輸出變得可重現、可測試，且完全沒有執行階段的幻覺。該公司稱之為「自然語言的靈活性」與「傳統程式碼的可靠性」兩者兼得。

把概念具體化，試想一座工廠的品質檢驗流程：工程師用白話文描述所需的審核步驟與數據檢查。Orchestrator 將這段描述編譯成一個固定的執行順序，主管核准一次後，這條流程就會在每次相關事件觸發時，以完全相同的方式執行——從頭到尾，數據不踏出廠房半步，也沒有讓模型隨性發揮的風險。

基礎架構、合規與目標產業

由於 Orchestrator 運行在企業自己的基礎架構上——無論是就地部署還是私有雲——生產數據永遠不會離開廠區。這種架構讓系統從設計面就符合 GDPR 與歐盟 AI Act 的規範，也讓 INXM 得以接觸到純雲端自動化工具根本無法觸及的工廠現場軟體。

該公司明確將目標鎖定在工業製造商與德國的 Mittelstand：這些公司擁有老舊的就地部署系統、背負監管義務，且對可重複性有著嚴格要求。這不是一個橫向通用的自動化方案，而是專為那些已經因為無法信任 AI 代理人而將其拒於產線門外的企業所打造。

有了 570 萬歐元的新資金、一支交出過安全關鍵軟體的創辦團隊，以及將企業 AI 重新定義為「編譯器問題」而非「對話問題」的技術路徑，INXM 正在下注：阻礙工業界採用 AI 的瓶頸，不是能力——而是可靠性。