Build versus Buy versus Partner bei KI in der Verwaltung

# Build versus Buy versus Partner bei KI in der Verwaltung

Das System zur Anspruchsprüfung einer bundesstaatlichen Medicaid-Behörde markiert einen Haushalt als nicht leistungsberechtigt. Der Haushalt legt Widerspruch ein. Die Klärung dauert elf Monate, weil das zugrunde liegende Modell von einem Anbieter gebaut wurde, der in dieser Form nicht mehr existiert, weil der Vertrag keine Source-Code-Escrow-Klausel enthält und weil niemand im Haus erklären kann, wie das Modell Einkommensschwankungen gewichtet hat. Das ist kein hypothetischer Fall. Es ist das strukturelle Risiko, das in der „Buy“-Entscheidung steckt, wenn sie getroffen wird, ohne zu bedenken, was im vierten Jahr eines Fünfjahresvertrags passiert.

Diese Lektion arbeitet die Entscheidung zwischen Build, Buy und Partner anhand dieses Medicaid-Szenarios als rotem Faden durch, denn Eligibility-Engines gehören zu den häufigsten realen KI-Einsätzen (oder KI-nahen Einsätzen) in US-Bundesstaatsverwaltungen.

Die drei Wege, definiert

Build: Das eigene Data-Science-Team der Behörde (oder eine zentrale IT-Einheit des Bundesstaats wie ein Department of Technology) entwickelt und besitzt das Modell intern.

Buy: Die Behörde beschafft ein kommerzielles Standard- oder konfigurierbares Produkt von einem GovTech-Anbieter (ein Unternehmen, das auf Software für die Verwaltung spezialisiert ist, z. B. der Public-Sector-Bereich von Deloitte, Maximus oder kleinere spezialisierte Firmen wie Nava PBC).

Partner: Die Behörde entwickelt gemeinsam mit einem Universitätslabor, einem bundesfinanzierten Forschungszentrum oder einer Civic-Tech-Nonprofit (z. B. Code for America), oft mit geteiltem IP und geteiltem operativem Risiko.

Keiner dieser Wege ist per se überlegen. Die richtige Wahl hängt von drei Variablen ab: wie schnell Sie es brauchen, wie viel Kontrolle Sie über die Logik brauchen und wie stark Sie Vendor Lock-in ausgesetzt sind (der Zustand, von den proprietären Systemen eines Anbieters abhängig zu sein, sodass die Wechselkosten prohibitiv werden).

Warum Beschaffungszyklen mehr zählen als das Modell selbst

Die meisten KI-Fehlschläge im öffentlichen Sektor sind Beschaffungsfehler, keine Algorithmenfehler.

Ein typischer Beschaffungszyklus eines US-Bundesstaats für ein System wie eine Medicaid-Eligibility-Engine läuft laut verbreiteten Schätzungen der GovTech-Branche 18 bis 36 Monate vom RFP (Request for Proposal, das formale Ausschreibungsdokument) bis zum Go-live. Bundesbeschaffung unter der FAR (Federal Acquisition Regulation) kann noch länger dauern. Allein dieser Zeitrahmen schließt „Buy“ für jede Behörde aus, die unter einem dringenden Mandat steht, etwa einer neuen bundesrechtlichen Berichtspflicht mit Sechsmonatsfrist.

Build umgeht den RFP-Zyklus, läuft aber in eine andere Uhr: Recruiting. Data-Science-Gehälter in der Verwaltung der Bundesstaaten liegen typischerweise 20 bis 40 % hinter der Privatwirtschaft (grobe Marktschätzung), also brauchen Behörden oft 6 bis 12 Monate, nur um ein kompetentes internes Team zu besetzen, bevor eine Zeile Modellcode geschrieben ist.

Partner-Modelle kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen beim technischen Bau schneller sein (ein Universitätslabor hat vielleicht schon einen funktionierenden Prototyp), sind aber bei Datenteilungsvereinbarungen oft langsamer, denn MOUs (Memoranda of Understanding) mit öffentlichen Universitäten gehen durch deren eigene Rechtsprüfung, und HIPAA (Health Insurance Portability and Accountability Act) oder Datenschutzgesetze der Bundesstaaten regeln, welche Medicaid-Daten die Server der Behörde überhaupt verlassen dürfen.

Daumenregel: Ist die Frist regulatorisch und fix, kaufen Sie oder partnern Sie mit einer Einheit, die bereits FedRAMP- oder StateRAMP-Autorisierung hat (die Cloud-Sicherheitszertifizierungsprogramme auf Bundes-/Staatsebene, die Anbieter für den Umgang mit Verwaltungsdaten vorab freigeben). Ist die Frist flexibel und die Logik zentral für Ihren Auftrag, bauen Sie selbst.

Vendor Lock-in: das Risiko, das nach Vertragsende auftaucht

Vendor Lock-in bei KI in der Verwaltung hat meist drei Formen:

1. Data Lock-in: Die Plattform des Anbieters speichert Eligibility-Daten in einem proprietären SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen →, das sich nicht einfach exportieren lässt.

2. Model Lock-in: Die Entscheidungslogik ist eine Black Box, und der Vertrag verlangt keine Dokumentation, keine Explainability-Artefakte und keinen Source-Code-Escrow.

3. Staff Lock-in: Nur die Mitarbeiter des Anbieters verstehen das System, die Behörde kann es also nicht unabhängig auditieren oder ändern, und ein Anbieterwechsel bedeutet, von vorn anzufangen.

Bei einer Medicaid-Eligibility-Engine ist Lock-in gefährlich, weil diese Systeme Entscheidungen mit Due-Process-Implikationen treffen. Nach dem Administrative Procedure Act und entsprechenden Regelungen der Bundesstaaten hat ein Leistungsberechtigter, dem die Deckung verweigert wird, das Recht, die Grundlage dieser Ablehnung zu verstehen und dagegen Widerspruch einzulegen. Ist Ihr Modell die undokumentierte Black Box eines Anbieters, kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen Sie diese Erklärung nicht auf Anfrage liefern. Das war schon Gegenstand von Verfahren: Arkansas' Einsatz eines automatisierten Tools zur KKThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ürzung von Pflegestunden für behinderte Medicaid-Berechtigte wurde Mitte der 2010er-Jahre erfolgreich vor Gericht angegriffen, unter anderem weil die Methodik nicht ausreichend offengelegt wurde. Das Electronic Privacy Information Center (EPIC) führt ein öffentliches Tracking von Fällen algorithmischer Accountability in staatlichen Leistungssystemen, ein Blick wert für jeden, der solche Einsätze bewertet.

Vertragsklauseln, die das Lock-in-Risiko senken, unabhängig vom Build/Buy/Partner-Weg:

• Escrow für Source Code und Modellartefakte (ein neutraler Dritter hält eine Kopie, die freigegeben wird, wenn der Anbieter ausfällt oder der Vertrag endet)
• Anforderungen zur Datenportabilität in offenen Formaten (CSV, JSON, keine proprietären Binärformate)
• Explainability-Anforderungen: Der Anbieter muss für jede belastende Entscheidung eine Begründung in einfacher Sprache liefern
• Right-to-Audit-Klauseln, die unabhängige technische Prüfung erlauben

Ein einfaches Entscheidungsframework

| Faktor | Spricht für Build | Spricht für Buy | Spricht für Partner |

|---|---|---|---|

| Time to Deploy | Langsam (12-24 Mon.) | Schnell, wenn vorzertifizierter Anbieter existiert | Mittel, hängt von MOU-Tempo ab |

| Kontrolle über Logik | Hoch | Gering, sofern der Vertrag keine Transparenz vorschreibt | Mittel bis hoch |

| Anfangskosten | Hoch (Personal, Infrastruktur) | Geringer anfangs, laufende Lizenzierung | Oft fördermittelfinanziert, geringere Cash-Kosten |

| Langfristige Flexibilität | Hoch | Gering ohne starke Vertragsbedingungen | Mittel, hängt von IP-Bedingungen ab |

| Am besten für | Kernlogik des Auftrags, hohes Klagerisiko | Commoditisierte Aufgaben (Dokumenteneingang, Terminplanung) | Neue Methoden, forschungsnahe Probleme |

Zum Medicaid-Fall: Die Anspruchsprüfung ist folgenschwer, klageexponiert und zentral für den Auftrag der Behörde. Das spricht für Build oder ein eng vertraglich geregeltes Partner-Modell, nicht für einen Black-Box-Kauf, auch wenn Buy schneller ist. Ein pragmatischer Mittelweg, den viele Bundesstaaten tatsächlich gehen: die Workflow- und Case-Management-Plattform eines Anbieters kaufen (geringes Rechtsrisiko, commoditisiert) und dabei die eigentliche Eligibility-Scoring-Logik intern oder mit einem Universitätslabor bauen bzw. co-entwickeln, damit die folgenschwerste Komponente auditierbar bleibt.

Wie „Partner“ in der Praxis tatsächlich aussieht

Eine Partnerschaft mit einem Universitätslabor ist keine kostenlose F&E. Sie bringt eigene Reibungen mit: Akademische Zeitpläne passen nicht zu staatlichen Haushaltsjahren, Publikationsanreize (Forscher wollen Ergebnisse veröffentlichen) kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen mit Anforderungen an Datenvertraulichkeit kollidieren, und die IP-Eigentumsfrage muss ausdrücklich vor Projektstart verhandelt werden, nicht danach.

Dennoch haben mehrere US-Bundesstaaten Universitätspartnerschaften erfolgreich für Probleme mit geringerem Risiko und höherem Innovationsgrad genutzt, etwa die Prognose von Medicaid-Anmeldespitzen oder das Erkennen von Betrugsmustern in Claims-Daten, wo der Preis einer falschen Prognose operative Ineffizienz ist und keine Due-Process-Verletzung. Das ist das richtige Risikoprofil für Partnerschaft: experimentell, nicht entscheidungsbefugt.

Ein einfacher Weg, den Tradeoff quantitativ einzuschätzen: Schätzen Sie die Total Cost of Ownership (TCO) über einen Fünfjahreshorizont, nicht nur die Lizenzierung in Jahr eins.

Buy scenario (illustrative, not a real quote):
Year 1 licensing + implementation: $2.0M
Years 2-5 licensing (annual):      $0.6M x 4 = $2.4M
Vendor switching cost (est. if locked in): $1.5M
5-year TCO: ~$5.9M

Build scenario (illustrative):
Team of 4 FTEs x $150K avg loaded cost x 5 years: $3.0M
Infrastructure (cloud, security review): $0.4M
5-year TCO: ~$3.4M, but with 12-18mo delay before go-live

Das ist illustrative Rechnung, kein Benchmark, die realen Zahlen variieren enorm je nach Bundesstaat und Anbieter. Der Zweck der Übung ist prozedural: Beschaffungsteams dazu zwingen, Wechselkosten und Verzögerungskosten einzupreisen, nicht nur den Listenpreis.

🎬 [VIDEO: „How Governments Buy Software (and Why It's So Hard)“ - youtube.com/@codeforamerica - Erklärstück von Code for America zu Beschaffungsreibung im öffentlichen Sektor und deren Wirkung auf Technologieadoption, nützlicher Kontext dafür, warum Buy-Zyklen lange laufen]

Wichtigste Erkenntnisse

• Passen Sie die Entscheidung an die Konsequenzen an: Build oder eng gesteuerte Partner-Modelle für klageexponierte Kernlogik des Auftrags (wie die Anspruchsprüfung); Buy für commoditisierte Workflow-Aufgaben mit geringerem Risiko.
• Beschaffungszeiträume (oft 18-36 Monate bei RFPs von US-Bundesstaaten) sind häufig der echte Engpass, nicht die Modellperformance, deshalb sollte der Zeitdruck die Build/Buy/Partner-Wahl genauso prägen wie die technische Leistungsfähigkeit.
• Vendor Lock-in hat drei Geschmacksrichtungen (Daten, Modell, Personal); entschärfen Sie alle drei vertraglich mit Source-Code-Escrow, Datenportabilitätsklauseln und verpflichtender Explainability, unabhängig vom gewählten Weg.
• Partnerschaft mit Universitäten funktioniert am besten bei explorativen, nicht entscheidungsbefugten Problemen (Prognosen, Erkennung von Betrugsmustern), nicht bei Entscheidungen mit direkten Due-Process-Folgen.
• Berechnen Sie immer die Total Cost of Ownership über einen Fünfjahreshorizont, inklusive geschätzter Wechselkosten, bevor Sie Buy-Angebote gegen Build-Schätzungen stellen; der Preis in Jahr eins allein führt in die Irre.