Skip to content
Tech42 Software Solutions GmbH

Wie evaluiert man einen KI-Software-Partner 2026? Sechs Kriterien

Sechs Kriterien für die Auswahl eines Software-Partners 2026 — von KI-Kompetenz über Datenschutz bis Skalierbarkeit. Praxisleitfaden für Entscheider.

Jan Raddatz · 12 Min. Lesezeit · KI / Mittelstand / Senior-Engineering / Software-Partner
Sechs Kriterien zur Bewertung eines KI-Software-Partners 2026 — Expertise, KI-Kompetenz, Datenschutz, Integration, Skalierbarkeit, Kultur

Wer 2026 einen KI-Software-Partner evaluieren muss, hat es deutlich schwerer als noch vor drei Jahren. Die Standardfrage “Hat das Team Erfahrung mit Tech-Stack X?” reicht nicht mehr aus. Wer KI in der Entwicklungs-Toolkette einsetzt, unterliegt anderen Quality-Gates. Wer KI in das gelieferte Produkt integriert, hat den EU AI Act im Nacken. Wer mit kritischen Daten im Mittelstand arbeitet, braucht NIS-2- und DSGVO-Konformität, die nicht nur auf dem Papier steht.

Dieser Artikel sortiert sechs Kriterien, die 2026 bei der Partner-Auswahl wirklich tragen — und ergänzt sie um drei Fragen, mit denen Sie Pitch-Theater von echter Lieferfähigkeit unterscheiden.

Erst Ziel klären — dann Partner suchen

Der häufigste Fehler bei der Anbieter-Auswahl: Pitches vergleichen, bevor das eigene Vorhaben sauber definiert ist. Dann werden vor allem Slides bewertet, nicht Substanz.

Drei Vorabentscheidungen helfen, die richtigen Partner überhaupt erst einzuladen:

1. Vorhaben-Typ. Bauen Sie einen MVP, modernisieren Sie ein Bestandssystem, brauchen Sie Verstärkung für ein eigenes Team, oder integrieren Sie KI in eine bestehende Software? Jeder Typ braucht ein anderes Partner-Profil — und Anbieter, die alles können, können in der Regel keines davon richtig.

2. Vertragsmodell. Werkvertrag für eigenständige Lieferung oder Dienstleistungsvertrag für Augmentation? Festpreis oder Time & Material? Zur Einordnung haben wir die Preisrahmen 2026 im Detail aufgeschlüsselt.

3. Compliance-Footprint. Gilt für Ihr Vorhaben der AI Act (HR-Tool, Bonität, Scoring)? NIS-2? Branchenspezifische Auflagen (BAIT, KRITIS, MDR)? Die Anbieter-Auswahl hängt davon ab — wir haben das für den AI Act im Beitrag EU AI Act für KMU sortiert.

Erst wenn diese drei Achsen geklärt sind, ergeben Anbieter-Pitches überhaupt vergleichbare Antworten.

Die sechs Kriterien

1. Fachliche Expertise — und der Bait-and-Switch-Test

Tech-Stack-Kompetenz ist 2026 Tisch-Einsatz, kein Differenzierungs-Merkmal. Die schärferen Fragen:

  • Liefert der Partner ausschließlich mit Senior-Architekten — oder nur im Pitch? Das klassische Bait-and-Switch der Branche: im Pitch sitzen Senioren, im Projekt liefern Juniore. Lassen Sie sich konkrete Namen und CVs der vorgesehenen Engineers vor Vertragsabschluss geben — mit Verbleibs-Zusage für die ersten sechs Monate.
  • Echte Referenzen im Zielsegment. Mittelstand ist nicht Enterprise. Bitten Sie um zwei Referenz-Projekte ähnlicher Größe und Komplexität — und sprechen Sie mit den Kunden direkt, nicht nur mit dem Anbieter.
  • Pre-KI-Erfahrung als Stabilitätsanker. Wer Architekturen erst seit dem KI-Hype baut, hat keine Erfahrung damit, was Legacy-Systeme über Jahre wirklich brechen lässt. Fragen Sie nach Projekten, die ohne KI-Tooling durchgezogen wurden — die Antwort zeigt, ob Architektur- Denken im Haus ist oder ob KI nur die fehlende Disziplin überdeckt.

Wie wir das machen: Bei MOBEX liefert die technische Gesamtleitung dieselbe Person, die das Projekt verhandelt hat — kein Account-Manager dazwischen. Bei Omniga haben wir eine heterogene .NET-Framework-Landschaft auf .NET 8 migriert, ohne dass eine kundenseitige SaaS-Plattform Ausfallzeit gesehen hat. Beide Projekte sind Architektur-Arbeit aus jahrelanger Praxis, nicht aus dem KI-Boom.

2. KI-Kompetenz — und wie sie verifiziert wird

“Wir nutzen GitHub Copilot” ist 2026 keine Antwort. Das machen praktisch alle. Was Sie stattdessen fragen sollten:

  • Wie wird KI-Output verifiziert? Welche Test-Strategien fangen halluzinierte Logik ab? Wer reviewt was — Mensch oder zweites Modell? Welche Architektur-Entscheidungen treffen Menschen, welche dürfen KI-generiert sein?
  • Wo wird KI bewusst nicht eingesetzt? Wer KI ohne Disziplin überall einsetzt, produziert Spaghetti — in Engineering-Kreisen vibe coding genannt, funktioniert bis zur ersten Last-Spitze.
  • Wer schreibt die Spezifikation? Eine kontextreiche Spezifikation von einem Software-Architekt ist 2026 wertvoller als zehn perfekt getippte Zeilen. Diese Verschiebung haben wir in Senior-Engineering im KI-Zeitalter ausführlich beschrieben.

Wie wir das machen: Bei der KI-Ausschreibungsplattform ist die KI-Funktionalität — semantische Klassifikation, Matching-Score, generierte Anschreiben — Teil des Produkts, nicht nur des Build-Prozesses. Die Architektur wurde KI-first konzipiert: Microservices, event-getriebene Pipelines, klare Service-Grenzen — damit weitere KI-Modelle ohne Architektur-Umbau hinzukommen können.

3. Datenschutz & Sicherheit — gelebt, nicht nur dokumentiert

DSGVO ist Pflicht, AI Act zieht ab August 2026 voll nach, NIS-2 betrifft einen wachsenden Kreis. Worauf Sie achten:

  • Hosting-Regionen explizit. Wo liegen Produktivdaten, Backups, Logs? EU-Region als Standard, US-Region nur mit konkretem Grund.
  • Subprozessoren transparent. Welche Drittanbieter berühren die Daten? Eine aktuelle Liste mit Rollen und Standorten gehört zum Standard.
  • Secrets-Management konkret. “Best Practices” als Antwort ist kein Beweis. Konkrete Antwort wäre: Key-Vault, rotation-fähig, kein Secret im Repo. Wie das praktisch aussieht, haben wir am Beispiel Azure Key Vault beschrieben.
  • AI-Act-Rollenklärung im Vertrag. Wer ist Anbieter (Provider), wer Betreiber (Deployer)? Das gehört vertraglich geklärt, nicht impliziert.

Wie wir das machen: Bei MOBEX haben wir Security-by-Design als feste Säule etabliert — Token-basierte Kommunikation über Microsoft Entra External ID, On-Behalf-Of-Flow, striktes RBAC, Backend-Services nicht direkt vom Client erreichbar. Compliance war Architektur-Anforderung, nicht Anhang.

4. Integration & Kompatibilität — Bestandslandschaft im Blick

Ein neues System lebt nicht im Vakuum. Wie der Partner mit Bestandssystemen umgeht, ist 2026 oft entscheidender als die Greenfield-Erfahrung.

  • Schnittstellen-Disziplin. Versionierung der eigenen APIs vom ersten Endpoint an. Idempotenz und Retry-Verhalten bei Drittsystem-Calls.
  • Identity-, API- und Event-Integration. Welche Identity-Provider beherrscht der Partner aus echten Projekten (Microsoft Entra ID, Entra External ID, Auth0)? Wie sieht die Anbindung an Drittsysteme konkret aus — saubere API-Verträge, idempotente Calls, event-basierte Integration? Eine Integration in ein historisch gewachsenes Bestands- system ist nie ein “einfacher Endpunkt”. Wer das schon mit ähnlichen Systemen durchgezogen hat, kalkuliert anders als wer es zum ersten Mal probiert.
  • Legacy-Migration als eigene Disziplin. Modernisierung ist keine Greenfield-Arbeit. Strangler-Pattern, paralleler Betrieb, schrittweise Datenmigration — wer das schon durchgezogen hat, weiß, wo die Fallen liegen.

Wie wir das machen: Bei Omniga haben wir mehrere geschäftskritische .NET-Anwendungen — interne Prozesse und kundenseitige SaaS-Plattformen — inkrementell auf .NET 8 migriert. Kein Big-Bang. Keine Downtime auf kundenseitigen SaaS-Plattformen während der gesamten Migration.

5. Skalierbarkeit — System, Team, Wartung

Skalierbarkeit ist drei verschiedene Dinge — und gute Partner antworten auf alle drei.

  • System skaliert. Datenmodell-Entscheidungen mit Wachstums-Horizont, sinnvolle Architektur-Pattern (modularer Monolith, Microservices oder ein begründeter Mix). Dazu haben wir Modularer Monolith vs. Microservices im Detail aufgeschrieben.
  • Team skaliert. Was passiert, wenn Sie nach sechs Monaten doppelt so viel Geschwindigkeit brauchen? Kann der Partner aufstocken — und mit welcher Qualität?
  • Wartung skaliert über drei bis vier Jahre. Library-Updates, Security-Patches, Framework-Sprünge. 15 % bis 25 % der Initial-Entwicklung pro Jahr sind realistisch — wer drastisch darunter liegt, hat das nicht ehrlich kalkuliert (siehe Preisrahmen 2026).

Wie wir das machen: Bei MOBEX wurde das Backend von Anfang an auf zukünftige KI-Integrationen vorbereitet — klare Service-Grenzen, event-basierte Architektur, entkoppelte Fachlogik. Heute kann MOBEX KI-Services schrittweise einführen, ohne Kernsysteme umzubauen.

6. Kultur & Zusammenarbeit — die unterschätzte Härte

Der Faktor, der über Erfolg oder Scheitern oft mehr entscheidet als jede Tech-Wahl.

  • Discovery-Tiefe. Hört der Partner zu, oder verkauft er sofort? Stellt er die unangenehmen Fragen (Budget, Compliance, Edge Cases), oder umtanzt er sie?
  • Direkte Greifbarkeit. Wer ist Ihr direkter Ansprechpartner — und wie schnell antwortet er, wenn etwas brennt? Eine Account-Manager-Kette zwischen Ihnen und dem tatsächlichen Team ist 2026 ein Warnsignal, kein Komfort.
  • Wissens-Lock-in vermeiden. Gehört der Code Ihnen, gehört das Backlog Ihnen, gehört die Dokumentation Ihnen? Bindet der Partner Sie über ein Wissens-Monopol, hat er ein Geschäftsmodell — keine Partnerschaft. Besonders kritisch: kann das interne Team nach Live-Gang selbstständig weiterentwickeln?

Wie wir das machen: Bei MOBEX bestand der Auftrag explizit aus Plattform-Aufbau und Enablement des internen Teams. Das bestehende MOBEX-Team kam aus der PHP-Welt — wir haben den Übergang nach .NET / Azure / Microservices als Coaches mitgestaltet. Heute entwickelt das Team eigenständig in der neuen Architektur weiter.

“Wir verstehen Tech42 nicht als klassischen Dienstleister, sondern als strategischen Technologiepartner auf Augenhöhe.” — Heiko Raiber, Geschäftsführer MOBEX GmbH & Co. KG

Drei Fragen, die den Unterschied machen

Wenn Sie nur drei Fragen aus diesem Artikel mitnehmen, dann diese:

1. “Wer aus dem Pitch-Team arbeitet tatsächlich am Projekt — und für wie lange garantiert?” Lassen Sie sich konkrete Namen und CVs vor Vertragsabschluss geben — mit Verbleibs-Zusage für die ersten sechs Monate. Anbieter, die ausweichen, planen den Switch.

2. “Wo mussten Sie in den letzten zwei Jahren nachsteuern — und was war die Lehre daraus?” Ein Partner, der ehrlich antwortet, hat Reflexionsfähigkeit, die sich auch in Ihrem Projekt auszahlt. Ein Partner, der behauptet, alles sei immer glatt gelaufen, lernt nicht aus seinen Projekten — beides ist ein rotes Tuch.

3. “Was passiert vertraglich, wenn die ersten drei Monate zeigen, dass das Vorhaben kleiner, größer oder anders ist?” Discovery-Erkenntnisse machen Vorhaben fast immer anders. Wie der Partner mit Scope-Änderungen umgeht — vertraglich und in der Kommunikation — sagt mehr als jede Referenz. Bei uns ist die Discovery ein eigener Festpreis-Schritt vor dem Hauptvertrag, damit Sie nach drei Wochen wissen, woran Sie sind, bevor Sie das Hauptbudget zusagen.

Wie Sie systematisch vergleichen

Eine schlanke Checkliste, die sich in jedes Buying-Center einbringen lässt:

  1. Ziele definieren. Die drei Achsen (Vorhaben, Vertragsmodell, Compliance) auf einer Seite festhalten.
  2. Kriterien gewichten. Nicht jedes der sechs Kriterien ist für jedes Vorhaben gleich wichtig.
  3. Zwei bis drei Anbieter parallel sprechen. Gleiche Fragen, gleiche Reihenfolge, gleiche Zeitbudgets.
  4. Discovery als Probelauf. Vor dem Hauptvertrag eine bezahlte Discovery-Phase mit dem Favoriten. Wenn die Discovery hakt, hakt auch das Projekt.

Warum die Auswahl jetzt drückt

Wer ab August 2026 ein AI-Act-relevantes Vorhaben produktiv haben will, ist heute schon eng dran. Realistisch: drei bis vier Monate Implementation, zwei bis drei Monate Konformitätsbewertung und Abnahme. Wer jetzt erst die Anbieter-Auswahl startet, plant praktisch für Q1/2027 — nicht für Q3/2026. Mehr zum AI-Act-Timing im eigenen Beitrag.

Dazu kommt: der Markt füllt sich gerade mit KI-natives Software-Studios, die mit beeindruckenden Pitch-Folien und Demo-Apps anrücken — aber wenig Erfahrung mit dem, was Legacy-Systeme über Jahre wirklich brechen lässt. Diese Anbieter sind unter Schönwetter okay. Bei Compliance-Audits, Last-Spitzen und Legacy-Integration in Schwierigkeiten.

Wie Tech42 sich gegen diese sechs Kriterien aufstellt

Damit das keine reine Theorie bleibt — kurz, konkret, mit Verweis statt Wiederholung:

  • Senior-Architekten in jeder Lieferung. Der Software-Architekt, der pitched, ist der Software-Architekt, der liefert. Keine Account-Manager-Kette, kein Junior-Outsourcing.
  • KI als Plumbing in der Entwicklung — und als Produktbaustein im Lieferumfang. Wir nutzen KI-Tools intern; wo Kunden KI-Funktionalität ins Produkt wollen, bauen wir sie spezifikations-getrieben und mit Verifikation (siehe KI-Ausschreibungsplattform).
  • Discovery als Festpreis-Schritt, dessen Output Ihnen gehört. Ein bis drei Wochen, gemeinsam Anforderungen schärfen, Risiken identifizieren, Backlog aufbauen. Output bleibt bei Ihnen — auch wenn Sie sich für einen anderen Lieferanten entscheiden.
  • Pre-KI-Architektur-Erfahrung. Unsere Architektur-Prinzipien stammen aus Projekten vor dem KI-Boom — Legacy-Modernisierung, Cloud-native Plattformen, integrationsschwere Mittelstandsumgebungen. KI ist bei uns ein Hebel, kein Substitut für Erfahrung.
  • Compliance vorne in der Spezifikation, nicht im Anhang. AI Act, DSGVO, NIS-2 ändern Datenmodell und Architektur — wir mappen das in der Discovery.
  • Werkvertrag oder Augmentation. Für eigenständige Lieferung Werkvertrag auf Basis der Discovery. Für Teamverstärkung und hybride Modelle Dienstleistungsvertrag.

Mehr im Detail: individuelle Softwareentwicklung, Prozess, Referenzen.


Die Anbieter-Auswahl ist 2026 schwieriger geworden, weil mehr auf dem Spiel steht — und gleichzeitig die Unterscheidung schwerer fällt, weil alle dieselben Tools nennen. Sechs Kriterien, drei harte Fragen und eine bezahlte Discovery als Probelauf sind die robusteste Antwort.

Wenn Sie diese Checkliste ehrlich auf Ihre Shortlist anwenden und kein Anbieter überall stark ist — sprechen Sie mit uns. Drei Wochen Discovery zum Festpreis, Output gehört Ihnen, Klarheit über Scope, Risiken und Compliance- Footprint. Danach entscheiden Sie, wer baut.

Lust auf ein Gespräch?

Wenn Sie hier weitergelesen haben, lohnt sich vielleicht auch ein direktes Gespräch. Erstgespräch unverbindlich.