FIM One Whitepaper

​

Zusammenfassung

Daten verlassen niemals Ihre Grenze. Dieser eine Satz ist die grundlegende Designvorgabe hinter jeder Entscheidung in FIM One und der Grund, warum eine neue Infrastrukturschicht erforderlich ist — nicht eine weitere iPaaS und nicht ein weiterer universeller Agent. Die meisten Unternehmen verfügen bereits über die Systeme, die sie benötigen — ERP, CRM, OA, benutzerdefinierte Datenbanken, interne APIs, branchenspezifische SaaS. Was ihnen fehlt, ist eine Möglichkeit für KI, diese Systeme zu erreichen, ohne Daten in eine Vendor-Cloud zu migrieren und ohne ein sechsmonatiges Integrationsprojekt für jeden Use Case. Der Markt ist groß, bewegt sich schnell und positioniert sich bereits neu: Die globalen Ausgaben für GenAI-Infrastruktur in Unternehmen werden 2025 auf 18 Mrd. USD geschätzt und wachsen um das 3,2-fache YoY (Menlo Ventures 2025). China bewegt sich noch schneller — die Ausgaben für Enterprise-AI-Agenten liegen bei 120% CAGR (2023–2027) und erreichen bis 2027 ¥65,5 Mrd. (iResearch · CAICT 2025). Zentral- und staatseigene Unternehmen machen 60%+ der Beschaffung großer Modelle aus, und Xinchuang (信创) Private-Deployment ist eine zwingende Anforderung. Gartner hat diese Kategorie offiziell in „AI Agent Platform” umbenannt (Dokument 6300015, 2025); CAICTs 2025 Agentic AI Technology Report nennt es „智能体平台”; MuleSoft, der historische iPaaS-Marktführer, wurde vom Leader zum Challenger im 2025 iPaaS Magic Quadrant herabgestuft. Die Kategorie, die die Unternehmensintegration ein Jahrzehnt lang dominierte, wird in Echtzeit ersetzt. FIM One ist für die neue Kategorie konzipiert. Es ist eine All-in-One-Agent-Plattform für Global × China Unternehmen — ein Provider-agnostisches Python-Framework, bei dem KI-Agenten dynamisch Aufgaben über Ihre bestehenden Systeme planen und ausführen, globale SaaS und den China Stack über einen Agent Core verbinden, in Ihrer eigenen Umgebung bereitgestellt, vollständig nachverfolgbar. Ein Agent Core, drei Bereitstellungsmodi: Dieses Dokument erklärt, warum sich die Kategorie bewegt, warum iPaaS die neue Workload nicht aufnehmen kann, wie FIM One unter der Haube aussieht und wie Sie es in die Produktion bringen.

​

1. Das Problem: Enterprise-KI ist ein Alignment-Problem

Die öffentliche KI-Diskussion in 2025–2026 wurde von Modellkapazität dominiert — längere Kontexte, besseres Reasoning, günstigere Token. In Unternehmen ist Kapazität selten der Engpass. Der Engpass ist, dass die KI keine Hände in Ihren Systemen hat. Ein Frontier-LLM, das eine zehntausendzeilige Codebasis lesen und einen korrekten Fix vorschlagen kann, kann von selbst nicht:

• Gestrige Bestandszahlen aus einer lokalen SAP-Instanz abrufen.
• Eine Urlaubsanfrage in einem SaaS-HR-Tool genehmigen, dessen einzige Integrationsoberfläche eine Legacy-SOAP-API ist.
• Eine Zeile in ein Xinchuang-konformes ERP schreiben, dessen Authentifizierung ein Login-Ticket-Service statt OAuth2 ist.
• Eine Benachrichtigung in eine Feishu-Gruppe senden und dabei die eigenen Genehmigungsregeln der Gruppe respektieren.

Jedes dieser Probleme ist einmal gelöst — eine gelöste Integrationsfrage. Die Schwierigkeit besteht darin, dass jedes Unternehmen Dutzende solcher Systeme hat, jedes mit seinem eigenen Authentifizierungsmodell, seiner eigenen Datenform und seinen eigenen Fehlermodi. Sie hardcodieren zu lassen, ergibt einen spröden Monolithen. Das LLM zur Laufzeit dazu zu bringen, sie zu entdecken, ergibt halluzinierte API-Aufrufe. Die fehlende Primitive ist eine ausgerichtete Oberfläche. Eine typisierte, authentifizierte, auffindbare Schnittstelle zwischen dem Modell und dem System — eine, die dem Modell genau sagt, was es tun kann, was jede Aktion kostet, wer sie genehmigen muss und wie das Ergebnis aussieht. Diese Primitive ist das, was FIM One einen Connector nennt.

​

2. Warum bestehende Ansätze nicht ausreichen

​

2.1 iPaaS und Workflow Builder — eine Kategorie im Niedergang

iPaaS (MuleSoft, Boomi, Workato) und die leichtere Workflow-Familie (n8n, Zapier, Dify, Coze) behandeln Integration als ein Design-Zeit-Problem: Ein Mensch zeichnet einen Graphen von Knoten und verbindet sie auf Feldebene, der Graph läuft zur Laufzeit deterministisch ab. Das Modell funktionierte, als Integrationen wenige und stabil waren. Es funktioniert nicht für KI-gesteuerte Enterprise-Automatisierung, aus drei sich verstärkenden Gründen:

1. Die Logik existiert bereits im Zielsystem. Jeder Knoten ist ein dünner Wrapper um einen API-Aufruf, den Sie jetzt an zwei Stellen pflegen.
2. Der Mensch muss den Plan im Voraus kennen. Enterprise-Fragen wie „Q1 für alle APAC-Entitäten abschließen” sind offen — der Plan muss zur Laufzeit generiert werden, nicht von einem Designer gezeichnet.
3. Feldebenen-Mapping kollabiert bei Skalierung. Ein Graph mit tausend Knoten über ein Dutzend Systeme ist nicht wartbar; KI-lesbare Action-Oberflächen ersetzen ihn vollständig.

Die Kategorie bewegt sich sichtbar. Gartner klassifizierte den Bereich 2025 als „AI Agent Platform” um (Dokument 6300015). CAICT übernahm denselben Rahmen in seinem 2025 Agentic AI Technology Report. Am aussagekräftigsten: MuleSoft — der Referenz-iPaaS-Anbieter für ein Jahrzehnt — wurde im Gartner 2025 iPaaS Magic Quadrant von Leader auf Challenger herabgestuft. Gleichzeitig wuchs das MCP-Protokoll von Anthropic, das im November 2024 veröffentlicht wurde, auf über 10.000 Server und 97 Millionen monatliche SDK-Downloads in 15 Monaten. Das Signal ist unmissverständlich: die Integrations-Schicht der Enterprise-Automatisierung wird neu aufgebaut.

​

2.2 Allzweck-Agenten (Manus, AutoGPT, OpenAI Assistants)

Allzweck-Agenten sind für Consumer- und Knowledge-Work-Aufgaben konzipiert — Web-Browsing, Dokumentenerstellung, Tabellenkalkulationen. Sie können nicht in Ihr VPN eindringen, sich bei Ihrem ERP authentifizieren oder Ihre Sicherheitsprüfung bestehen. Wenn sie um Unternehmensysteme herum eingesetzt werden, werden sie zu Demos, die in der Pilotphase scheitern.

​

2.3 Vendor-Embedded AI (Feishu AI, SAP Joule, Salesforce Einstein)

Vendors haben ihre eigene KI in ihre eigenen Produkte integriert. Das Problem ist strukturell: Kein vorgelagerter Anbieter hat einen Anreiz, seine eigene Datensilo zu durchbrechen. Feishu AI kennt Ihre ERP-Daten nicht; DingTalk AI kennt Ihren Vertragsstatus nicht. Die KI jedes Anbieters sieht nur das, was dieser Anbieter Ihnen verkauft hat. Für systemübergreifende Arbeiten sind sie keine Option.

​

2.4 Build-Your-Own und RPA

Eigenentwicklungen haben lange Entwicklungszyklen und konstante Anpassungskosten. RPA steuert die Benutzeroberfläche wie ein Mensch — der allgemeinste Ansatz und der zerbrechlichste: Jede UI-Änderung bricht ihn, jede Authentifizierungsaufforderung stoppt ihn. Es ist ein Pflaster über fehlenden APIs, keine Grundlage zum Aufbau von KI. FIM One besetzt die Lücke, die all diese hinterlassen: typisierte APIs über echte Systeme, vom Modell geplant, vom Unternehmen gesteuert, innerhalb der Unternehmensgrenze bereitgestellt.

​

3. Die FIM One These

Drei Überzeugungen prägen jede Designentscheidung. Überzeugung 1 — Die Systeme existieren bereits. Fordern Sie das Unternehmen nicht auf, alles neu aufzubauen; treffen Sie es dort, wo es ist. Jeder Connector ist eine Brücke, keine Ersetzung. Daten verlassen niemals die Quelle der Wahrheit und niemals die Unternehmensgrenze. Überzeugung 2 — Ausrichtung schlägt Leistung. Ein schwächeres Modell mit einem ausgerichteten Toolset übertrifft ein stärkeres Modell, das an rohen APIs herumfummelt. Der Burggraben ist die Connector-Bibliothek, sein Authentifizierungsmodell und die Governance-Schicht — nicht das reine Reasoning des Agenten. Überzeugung 3 — Dynamische Planung ist der richtige Mittelweg. Starre Workflows (iPaaS, BPM) sind zu spröde für echte Unternehmensaufgaben; vollständig autonome Agenten (AutoGPT, Manus) sind zu unvorhersehbar für die Produktion. FIM One plant zur Laufzeit, aber innerhalb eines typisierten Action Space — jeder Schritt ist ein Connector-Aufruf, kein offenes LLM-Monolog. Begrenzte Autonomie: re-plan ≤ 3 | token budget | confirmation gate.

​

Beyond iPaaS

FIM One ist bewusst keine iPaaS, und dieser Unterschied ist nicht kosmetisch. iPaaS ist feldebenenbasiert, designzeitlich, von Menschen modelliert und in der Vendor-Cloud gehostet. FIM One ist aktionsebenenbasiert, laufzeitlich, modellgeplant und unternehmensgehostet.

​

4. Architektur-Prinzipien

​

5. Drei Liefermodi — Ein Agent-Kern

Der gleiche Planner, die gleiche Memory und die gleiche Connector-Bibliothek unterstützen drei unterschiedliche Produktformen. Die Wahl ist eine Bereitstellungsentscheidung, keine Code-Abspaltung. Standalone — ein in sich geschlossenes Portal. Der Käufer möchte eine Chat-Schnittstelle über eine kuratierte Wissensdatenbank, einen Code-Sandbox oder einen allgemeinen Assistenten. Kein Host-System beteiligt. Passt zu internen IT-Helpdesks, Engineering-Produktivität, Customer-Support-KBs. Copilot — der Agent, eingebettet in ein vorhandenes Host-System über iframe, Widget oder direktes Embed. Der Host verwaltet die Authentifizierung; der Copilot erbt den Benutzerkontext. Passt zu Finance Copilot in SAP Fiori, Sales Copilot in Salesforce, DevOps Copilot in einem internen Developer Portal. Hub — die zentrale Orchestrierungsoberfläche. Jedes verbundene System endet hier. Benutzer stellen systemübergreifende Fragen; der Agent plant und führt systemübergreifend aus. Passt zu „Q1 für alle APAC-Entitäten abschließen”, „jeden Kunden finden, der eine Verlängerung verpasst hat, und Outreach-Entwürfe erstellen”, „gestrige Zahlungen zwischen Gateway und Ledger abstimmen”.

​

6. Connector Alignment Model

Ein Connector ist eine typisierte Action-Oberfläche, die durch eine Authentifizierungsstrategie unterstützt wird. FIM One definiert drei Authentifizierungsstufen, die die große Mehrheit der Unternehmenssysteme abdecken. Jeder Connector deklariert auch eine Channel/Integration-Dualität: dasselbe zugrunde liegende System kann sowohl als Channel (Benachrichtigungssenke, Genehmigungsoberfläche) als auch als Integration (Datenquelle, Action-Ziel) erscheinen. Feishu ist sowohl ein Benachrichtigungskanal als auch eine Gruppenchat-Datenquelle; DingTalk und WeCom folgen dem gleichen Muster.

​

7. Vertrauenswürdige Enterprise-KI — Drei Säulen

Enterprise-KI scheitert in der Produktion nicht, weil das Modell falsch ist, sondern weil die Organisation nicht nachweisen kann, dass es richtig ist. FIM One behandelt Vertrauen als Architektur, ausgedrückt in drei Säulen. Zur Unterstützung gibt jede Agent-Ausführung eine strukturierte Spur aus: Plan, Tool-Aufrufe, Argumente, Beobachtungen, Genehmigungen, endgültige Antwort. Spuren sind die Einheit der Prüfung. Anmeldedaten verwenden Fernet-Verschlüsselung (AES-128-CBC + HMAC-SHA256). Vollständige Audit-Protokolle werden gespeichert und exportierbar. Wenn ein Operator einen Tool-Aufruf ablehnt, stoppt der Agent — er paraphrasiert nicht und versucht es erneut. Ablehnung ist eine Richtlinienentscheidung, kein Fehler, von dem man sich erholen kann.

​

8. Deployment und Geschäftsmodell

FIM One wird mit öffentlichem Quellcode unter der FIM One Source Available License (FIM-SAL) bereitgestellt — source-available, nicht OSI-zertifizierte Open Source — mit drei Deployment-Varianten und drei Edition-Stufen. Die Codebasis umfasst ~170.000 Zeilen Python über 1.590+ Module, mit ~100 Testdateien und integrierter Unterstützung für 6 UI-Sprachen. Der Quellcode ist öffentlich unter FIM-SAL verfügbar — Unternehmen können die Sicherheit selbst überprüfen. Die dominanten Laufzeitkosten entstehen durch LLM-Token, nicht durch Infrastruktur; Provider-Unabhängigkeit bedeutet, dass Sie von sinkenden Preisen profitieren, wenn die Frontier voranschreitet, ohne Migration.

​

9. Lieferpfad

Die Produktionsbereitstellung folgt einem dreistufigen Pfad, der das Risiko begrenzt und die Time-to-Value kurz hält. Acht vordefinierte vertikale Lösungsvorlagen decken die häufigsten Szenarien ab: Finanzprüfung, Vertragsüberprüfung, Datenberichterstattung, Beschaffungsabstimmung, Kundenzahlungseinzug, Compliance-Screening, HR-Screening, Ops On-Call.

​

10. Where This Goes

Near-term — connector depth. More Tier-3 legacy connectors for the Chinese market, deeper Xinchuang certification, and an AI Builder that turns an OpenAPI spec or a database schema screenshot into a working connector in minutes. Near-term — governance depth. Richer RBAC, four-tier connector permissions, independent IdP, SSO by default, SOC 2 and ISO 27001 posture. Mid-term — ecosystem. Cloud SaaS, a Connector Marketplace, and industry Solution packs — the infrastructure layer that third parties build on top of. The longer-term bet is that the shape of enterprise AI will look far more like a cross-system agent platform than a CLI. Knowledge workers will not install ten AI assistants; they will ask their company’s agent platform, and the platform will know how to reach whatever system holds the answer — global SaaS, the China enterprise stack, or anything in between. FIM One is building that platform.

​

11. Appendix — Going Deeper

• System Overview — component-level architecture.
• Connector Architecture — the connector contract, lifecycle, and extension model.
• Design Philosophy — why we made each core tradeoff.
• Hook System — policy, approval, and audit in depth.
• Competitive Landscape — category positioning and head-to-head comparison.
• Quickstart — run FIM One on your laptop in under ten minutes.