Build, Buy, Partner, oder Borrow: Sourcing-Strategii für AI Agents

Stell dir vor, du bisch en Chief Technology Officer oder en Head vo ere Business-Funktion. Dini Teams händ scho agfange, s'Potenzial vo agentic AI z'gsee. Vilicht lauft en Pilot-Chatbot im Customer Service, wo ganz vielversprächend isch, oder s'Finance-Team experimentiert mit eme Agent, wo bim monatliche Abschluss hilft. D'Frag, wo denn uftaucht, isch nümm "bruuche mer überhaupt en Agent?", sondern "wohär überchömer die Agent-Fähigkeit?"

Söll dini Mannschaft alles vo Null ufbaue? Einfach en fertigi Lösig vomene Vendor chaufe? Oder mit eme externe Partner zämeschaffe? Oder nume Open-Source-Komponente usleihe, zum schnäll vorwärts z'cho?

Das isch e Frag, wo usgseht wie en Technologie-Entschädig, aber eigentlich vil tüüfer goht. D'Wahl vo de Sourcing-Strategii bestimmt, wie schnäll de Business-Value cha realisiert werde, wie vil Kontrolle d'Firma über Date und Prozäss het, und wie eifach die Agents integriert und verwaltet werde chönd. Ohne en klare Rahme chönne sich Firme i Abhängigkeite vomene einzige Vendor verfange, oder umgekehrt en unordentliche und schwirig z'steuernde Agent-Ökosystem ha.

Wiso die Entschädig so kompliziert isch

D'Sourcing-Entschädig für AI Agents isch anders als bi normale Software-Entschädig. E agentic Fähigkeit cha i vilne Forme gliichzitig uftauche. Si cha es Feature si, wo scho i de SaaS integriert isch, woner bruuchsch, es Add-on vo ere bestimmte Platform, en Open-Source-Framework, wo s'interne Team zämmebaut, oder e custom Lösig, wo uf firmeneigene Modell und Date ufbaut isch.

Nimm zum Bischpil d'Customer Operations. E Firma cha en fertige Customer-Service-Agent vomene CRM-Vendor chaufe. Gliichzitig baut s'interne Team e Orchestrierigsschicht, wo s'CRM mit de Bestellsystem und de Firmepolicy verbindet. Si lehne au Open-Source-Komponente us, zum mit Memory und Date-Sueche z'experimentiere. Und si hole en Partner a Bord, zum de anfänglich Betrieb z'stemme, während si s'Wüsse langsam a s'interne Team übergeh.

All die Optione chönd Sinn mache. S'Problem isch: Ohne en klare Entscheidigsrahme falled Firme schnäll i drei hüüfigi Fallene.

Erstens, en z'früeje Vendor-Lock-In. Vil agentic Lösige büte en schnälle Time-to-Value, aber wenn d'Firma zviel vo de Prozäss-Logik, Kontext-Date und Überwachig a eine Vendor abgit, chönd d'Ustritts-Chöschte spöter enorm si. Das isch speziell gföhrlich für Workflows, wo spöter en zentrale Teil devo sind, wi d'Firma funktioniert.

Zweitens, en fragmentierte Agent-Ökosystem. Wenn jedes Business-Funktion sini eigene Agents chauft oder baut, landet d'Firma bi inkonsistente Agent-Identitäte, überlappende Tool-Integratione, verschidene Evaluations-Standards und ere uneinheitliche Governance. S'Resultat isch nid e Firma, wo einheitlich vo Agents betribe wird, sondern es Agent-Chaos, wo schwirig z'kontrolliere isch.

Drittens, en z'langsame Time-to-Value. Uf de andere Site füert d'Besessenheit, alles sälber z'baue, oft defür, dass d'Organisation z'lang i de Grundlage-Phase stecke blibt. D'Teams sind beschäftigt, Framework und generischi Platforme z'baue, aber d'Business-Use-Cases chömed nie würkli i d'Produktion. I eme schnälle Markt isch das genau so gföhrlich wi d'Abhängigkeit vomene Vendor.

Drum muess d'Sourcing vo Agents wie e Portfolio-Entschädig behandlet werde. D'Hauptfrag isch nümm "wel Option isch allgemein am beste?", sondern: Macht die Fähigkeit üses Gschäft würkli besser? Wie sensibel sind d'Date und d'Entschädig, wo aagfasst werde? Wie schnäll muess de Wert cho? Und wie vil Kontrolle bruuchemer langfristig?

Wänn sälber Baue di richtig Wahl isch

De Build-Ansatz macht am meischte Sinn, wenn de Agent e Fähigkeit betrifft, wo d'Firma vo de Konkurrenz abhebt, sehr no a proprietäre Date dran isch, oder volli Kontrolle über s'Verhalte und de Läbenszyklus bruucht. Das passiert normalerwiis i drei Bereich.

Erschtens, Fähigkeite, wo de Kern vom Wettbewerbsvorteil sind. Wenn de Agent Logik usfüert, wo entscheidend isch, wi d'Firma konkurriert, isches nid gschiid, das fertig vom Markt z'chaufe. Bischpil sind Underwriting-Logik bi de Versicherig, proprietäri Preisfindigsmachine im Distributions- oder B2B-Retail, oder domänspezifischi operationelli Intelligäz i de Lieferchetti. I sonige Fäll liit de Wert vom Agent nid nume im AI-Interface, sondern i de Kombination vo interne Date, Entscheidigsregle, Workflow-Usnahme und em betriebliche Lernä, wo typisch für d'Firma isch. Wenn das alles a de Vendor abgitt wird, riskiert d'Firma, ihre Wettbewerbsvorteil us de Hand z'gäh.

Zweitens, Fähigkeite, wo ganz no a sensitive Date oder kritische Kontrolle dran sind. Build isch besser, wenn de Agent Risikoentschädig, starch gschützti Kundedate, finanzielli Kontroll-Logik oder operationelli Intelligäz betrifft, wo nid us bestimmte Gränze use dörf. Im Finance, zum Bischpil, cha me en Agent für d'Analyse vom Abschluss vilicht chaufe. Aber en Agent, wo d'Handhabig vo materiale Usnahme orchestriert, interni Policy, Controller-Überlegige und Audit-History kombiniert, isch oft sicherer, wenn er uf de interne Platform und Governance ufbaut wird.

Drittens, Fähigkeite, wo tüüfi Observability und Policy-Kontrolle bruuche. Mangi Workflows verlange, dass d'Firma im Detail cha erkläre, wel Kontext de Agent bruucht het, weli Tool er gruefe het, welli Entscheidig er troffe het, und wiso er aaghalte, witergmacht oder eskaliert het. Wenn d'Aaforderige a Auditability und Runtime-Kontrolle sehr hoch sind, git Build meh Spiilruum, um en Policy Engine, Approval Workflow, Observability, Evaluation Harness und es Läbenszyklus-Management nach interne Standard iizbaue.

Aber Build isch nid automatisch di gschidisti oder strategischi Wahl. Build macht nur Sinn, wenn d'Firma au d'Reife het, das z'trage. Mindeschtens bruuchts starchi Engineering-Fähigkeite, en klari Agent-Platform oder zumindescht es klares Platform-Muster, gsundi API-Integratione i d'Kernsystem, reifi Data-Governance, en Review vo Modell-Risiko und Security, und es Betriebsmodell für Bsitz, Support und kontinuierlichi Verbesserig. Ohne das produziert Build nur Prototype, wo schwirig z'betribe sind.

Stell der en Versicherig vor, wo en Underwriting-Agent für en bestimmte Segmant wott baue. Wenn de Agent nume allgemeini Broker-Frage beantwortet, chönnt me d'Fähigkeit vomene Vendor chaufe. Aber wenn de Agent Submissione list, Claim-History abglichet, es internes Risikomodell rueft, proprietäri Appetite-Regle aawändet und Underwriting-Entscheidigs-Empfählige vorbereitet, denn isch Build vil sinnvoller. De Hauptwert liit i de Kombination vo interne Date und Logik, nid nume im generative Modell.

Build isch normalerwiis nid richtig, wenn d'Fähigkeit scho sehr verbreitet am Markt isch, de Bedarf a Differenzierig tüüf isch, d'Firma no kei adäquati Platform und Team het, oder s'Gschäft schnälli Resultat bruucht, zum de Wert z'bewiise. I sonige Situatione wird Build hüüfig zu eme tüüre und langsame Technologie-Projekt.

Wänn Chaufe meh Sinn macht

De Buy-Ansatz passt für Fähigkeite, wo relativ allgemein sind, scho usgreift am SaaS- oder Enterprise-Platform-Markt, und nid de Haupt-Unterscheidigsmerkmal sind. Das gilt oft für Bereich wi Service Desk Assistant, CRM Sales Agent, Employee Self-Service Agent, Knowledge Assistant, oder Workflow Agents, wo ganz no a bestimmti SaaS-Platforme bunde sind.

De Vorteil vom Chaufe isch klar: Time-to-Value isch schnäller. D'Firma muess nid alles vo Null ufbaue. Grundlegendi Integratione, Benutzeroberfläche und es paar Guardrails sind normalerwiis scho vorhande. Für Organisatione, wo schnäll vorwärts wönd, isch das sehr attraktiv.

Im IT-Betrieb isch en Agent, wo Incidents zämmefasst, Knowledge-Artikel vorschlaht oder bi de Ticket-Triage ufere ITSM-Platform hilft, oft effizienter, wenn er vomene Vendor chauft wird, wo scho i dem Stack integriert isch. Im CRM isch en Sales Agent, wo hilft, Follow-ups vorzbereite, Account-Aktivitäte z'zämmefasse oder Next-Best-Actions vorzschla, schneller adoptiert, wenn er als embedded Capability vo de Platform chauft wird, wo s'Sales-Team scho bruucht. Im HR-Bereich bruucht en Employee Service Agent für allgemeini Policy-Frage normalerwiis nid sälber baut werde, usser d'Firma het sehr spezifischi Aaforderige.

Aber d'Schnelligkeit chunt mit Kompromiss. D'Kontrolle, wo d'Firma het, isch beschränkter. D'Firma cha vilicht nid tüüf steuere, wi s'Reasoning ablouft, wi de Memory verwaltet wird, wi d'Observability dargstellt wird, oder wi d'Runtime-Policy usserhalb vo de Optione vomene Vendor aagwändet wird. Vili Vendor verspräche Konfiguration, aber nid alli unterstütze würkli komplexi, benutzerdefinierti Workflows. Für Enterprise-Prozäss mit vilne Usnahme spürt me die Gränze schnäll.

Auditability und Data Boundary müend vor em Chaufe ernsthaft prüeft werde. D'Firma muess beurteile, welli Date zum Vendor usegönd, wo de Kontext verarbeitet wird, wi Logs gspicheret werde, öb d'Entschädig vom Agent erklärbar isch, und wi d'Zuegriffskontrollen aagwändet werde. Für regulierti Domäne chönd die Froge nid bis nach de Vertragsunterschrift warte.

D'Exit-Strategy muess au klar si. Wenn de chaufti Agent en wichtige Teil vom Workflow wird, muess d'Firma wüsse, öb d'Interaktionsdate exportiert werde chönd, öb d'Konfiguration und d'Prompt übertrage werde chönd, öb d'Tool-Integratione vo proprietäre Format abhängig sind, und was passiert, wenn de Vendor d'Roadmap oder d'Prise ändert. Ohni Exit-Strategy cha Buy zu ere strukturelle Abhängigkeit werde.

Buy isch weniger geeignet, wenn de Workflow sehr einzigartig isch und voll vo proprietärer Logik, d'Firma tüüfi Kontrolle über Policy und Observability bruucht, oder de Agent e Orchestrierigsschicht über vili System wird, wo de Vendor nid beherrscht. I sonige Fäll sind Vendor-Lösige oft guet für en Start, aber schlächt als langfristigi Grundlag.

Wänn Partner oder Usleihe di gsund Wahl isch

Zwüsched Build und Buy gits zwei Aasätz, wo für grossi Firme oft am realistschste sind: Partner und Borrow. Bidi sind nützlich, aber für verschideni Zwäck.

De Partner-Ansatz passt, wenn d'Firma weiss, weli Value Pools si wott aagäh, aber no kei usgreifti Implementierigs-Muster het, oder no nid bereit isch, de agentic Service sälber z'betribe i de früeje Phase. En Partner cha i verschiedene Rolle helfe: Er cha en Blueprint und e Reference Architecture helfe baue, de erschti Agent zäme mit em interne Team entwickle, en Managed Service für en bestimmti Domäne betribe, oder d'Industrialisierung durch Accelerator und Delivery-Capability beschlünige.

Das isch oft relevant für Shared Services, Global Capability Center, oder Funktion, wo schnäll vom Pilot in Betrieb wönd. Es GCC, wo d'Finance-Operations i es agentics Modell wott umwandele, muess vilicht nid sofort alli Fähigkeite sälber baue. D'Partnerschaft mit eme Service Provider cha hälfe, s'Operating Model z'entwerfe, Agents für AP-Usnahme und Abschluss-Unterstützig z'baue, Governance und Observability vorzbereite, und d'Fähigkeit Schritt für Schritt a s'interne Team z'übergeh. De Ansatz macht Sinn, wenn s'Ziel vo de Firma nid nume isch, Software z'ha, sondern d'Art, wi d'Service schaffet, z'ändere.

Aber Partner heisst nid, dass me d'Verantwortig abgit. De Vertrag muess klar si über IP-Bsitz, Date-Nutzig, Operating Model, SLA, Audit-Recht und de Plan für d'Wüssensübergab. Wenn nid, verschiebt d'Firma d'Abhängigkeit eifach vomene Software-Vendor zunere Dienstleischtigsfirma.

De Borrow-Ansatz heisst normalerwiis, dass me Open-Source-Framework, Reference Architectures, Starter Kits, Accelerator oder Community-Komponente bruucht, zum schnäll z'leerne, bevor di offizielli Platform standardisiert wird. Borrow isch sehr nützlich i de früeje Phase, wenn d'Firma Orcheschtrierigs-Muster teste, d'Aaforderige a Tool Calling verstah, en Context Layer usprobiere, oder en Use Case bewiise will, ohni uf d'Entschädig vo de Enterprise-Platform z'warte.

Es Procurement-Team, zum Bischpil, will vilicht en Agent teste, wo Aafräge list, Policy prüeft, Vertragsdate rueft und de Approval-Weg vorbereitet. Zum das Muster z'bewiise, cha s'Team Open-Source-Komponente und interni Accelerator uslehne. Wenn s'Resultat vielversprächend isch, denn wird die Fähigkeit uf di offizielli Platform mit starchi Kontrolle verschobe.

Brucht git Schnelligkeit im Lernä, aber es het klari Gränze. D'Qualität und Security vo de Komponente chönne variiere, de langfristig Bsitz isch oft nid klar, d'Abhängigkeit vo Open-Source cha schwirig z'verwalte si, und d'Teams chönne a Prototype hangeblibe, wo nie gehärtet werde. Drum sött Borrow wie en Explorations-Pfad behandlet werde, nid als Grund, d'Standardisierig ufzschiebe.

Sowohl Partner als au Borrow wärde oft für d'Schnelligkeit gwehlt. Grad drum muess d'Governance disziplinierter si. D'Firma muess sicherstelle, dass d'Data-Boundary klar isch, d'Nutzigsrächt für Modell und Artefakt klar sind, de IP vo de Entwicklig nid verschwimmt, d'Verantwortig für d'Agent-Entschädig bi de Firma blibt, und es en Übergangspfad vom Experiment zum formelle Betrieb git. Wenn nid, wird d'Firma schnäll i die falschi Richtig unterwegs si.

D'Realität vom Hybrid: De Mix vo verschidene Agent-Quälle manage

I de Praxis wird e grossi Firma fast sicher mit eme hybride Agent-Lieferchetti lande. E paar Agents wärde sälber baut, e paar vo SaaS chauft, e paar zäme mit Partner entwicklet, und e paar für Experiment oder bestimmti Komponente usglehnt. Das isch nid s'Problem. Gföhrlich isch, wenn de Mix ohni gemeinsami Architektur und Governance wachst.

Für das hybride Modell z'manage, bruucht d'Firma es paar Sache. Erstens, es Agent Registry, en Katalog, wo zeigt, welli Agents es git, wer de Business- und Technical-Owner isch, vo wo si chömed, welli Date und Tool si bruuche, wel Risiko si händ, und wel Status im Läbenszyklus si sind. Ohni Registry gits kei gsunde Weg, s'Agent-Portfolio z'manage.

Zweitens, Interoperabilitäts-Standard. Agents vo verschidene Quelle müend im gliiche Ökosystem läbe chönne. Das bedüütet, dass me Standard bruucht für Identität, Tool Calling, Event, Logging, Observability und Handoff zwüsched Agents oder zum Mensch. Wenn nid, wird jede Agent en eigeni Insle.

Drittens, Risiko-Gruppierig. Nid alli Agents bruuche di gliichi Kontrolle. En Knowledge Assistant isch öppis anders als en Agent, wo Aktione im ERP uslöse cha. D'Firma muess d'Agents nach Risiko und Business-Impact gruppiere und denn proportionali Kontrolle aawände.

Viertens, gemeinsami Governance. Egal vo wo si chömed, alli Agents, wo i Betrieb gönd, müend de gliiche Governance unterliege: Security Review, Data Permissioning, Evaluation, Approval Threshold, Observability, Incident Management und Decommissioning-Prozäss. D'Sourcing darf verschide si, aber d'Enterprise-Standard nid.

En gsünderi Denkwiis: Sourcing pro Schicht

En Use Case muess nid ein einzigi Sourcing-Strategii ha. Oft isch di bescht Entschädig pro Schicht verschide. Zum Bischpil: Buy für d'embedded Capability im CRM, Build für d'Orchestrierigs- und Policy-Schicht, Partner für di anfänglich Implementierig, und Borrow für s'Experimentiere mit bestimmte Kontext-Komponente.

Di reiferi Sourcing-Frag isch: Welli Schicht isch d'Differenzierig? Welli Schicht isch scho en Commodity? Welli Schicht muess beschlünigt werde? Und welli Schicht isch no wert, explorieret z'werde? De Ansatz isch vil realistsicher, als dass me e einzigi Antwort für de ganz agentic Stack erzwingt.

Am Schluss isch e gueti Agent-Sourcing-Strategii nid über d'Wahl vo eim Lager. Es goht drum, Kontrolle, Schnelligkeit und Differenzierig a de richtige Stelle z'platziere. E reifi Firma wird nid alles sälber baue, aber au nid ihri Zuekunft blind chaufe. Si wird Agents wie es Portfolio vo Enterprise-Fähigkeite manage, mit ere Architektur-, Governance- und Verantwortigs-Disziplin, wo der wichtige Rolle vo de Agents im Betrieb entspricht.