Ein Admin öffnet Copilot, beschreibt in fünf Sätzen, was er braucht, und hat am Nachmittag eine App. Sie legt Teams an, erzwingt ein Namensschema und hängt eine Genehmigung davor. Das ist keine Illusion, das funktioniert. Vibe Coding, also das Bauen von Software im Dialog mit einem KI-Modell, hat die Einstiegshürde wirklich verschoben. Deshalb kommt inzwischen in vielen Gesprächen die Frage: Warum sollen wir eine Software kaufen, wenn wir uns das selbst bauen können?
Die Antwort steckt nicht im Prototyp, sondern im TCO (Total Cost of Ownership), also in den Gesamtkosten über die Laufzeit. Eine Governance-App hält hohe Rechte im Tenant, läuft im Produktivbetrieb und muss jede Microsoft-Änderung überleben. Das Bauen ist der günstige Teil. Hier sind die Posten, die in der ersten Aufwandsschätzung fehlen, mit den Zahlen dahinter.
Governance-App in Microsoft 365 selbst bauen oder kaufen? Die kurze Antwort
Kaufen. Für alles, was jahrelang im Produktivbetrieb laufen muss, ist Kaufen günstiger und sicherer. Die Erst-Entwicklung ist nach unserer Erfahrung bei Solutions2Share rund 15 % des TCO. Rund 45 % des von KI erzeugten Codes enthält bekannte Sicherheitslücken (Veracode). Und erfahrene Entwickler waren mit KI-Werkzeugen 19 % langsamer, nicht schneller (METR)
Was ist Vibe Coding?
Vibe Coding bezeichnet das Entwickeln von Software im Dialog mit einem KI-Modell. Du beschreibst das gewünschte Verhalten in natürlicher Sprache, das Modell schreibt den Code, du prüfst das Ergebnis im Betrieb statt im Detail. Für Prototypen funktioniert das gut. Für Software, die Berechtigungen in einem Microsoft 365-Tenant verwaltet, gelten andere Anforderungen.
Die 15 %-Falle: wo die Kosten einer Eigenentwicklung wirklich liegen
Die Erst-Entwicklung ist der kleinste Posten. Bei unseren Apps macht sie etwa 15 % des gesamten Aufwands aus. Die anderen 85 % sind Arbeit, die in keinem Projektplan für ein internes Tool steht:
- Produktmanagement und Priorisierung
- UX und UI
- Funktionalität über den ersten Anwendungsfall hinaus
- QA und Testing
- Dokumentation
- Hosting und Betrieb
- Sicherheit und Security Reviews
- Wartung
- Weiterentwicklung
- laufende Anpassungen an Microsoft-Änderungen
Nichts davon verschwindet, wenn eine KI den Code schreibt. Es verschiebt sich von der Rechnung eines Anbieters in die Zeit deines Teams, und es kommt jedes Jahr wieder, solange die App im Einsatz ist.
Ein Posten überrascht regelmäßig: Die Tokens für Entwicklung und Bugfixing können am Ende mehr kosten als eine Lizenz. Dann hast du bezahlt und hast trotzdem keinen Support, kein Testing, kein Hosting und keine Zertifizierung.
Warum die letzten 5 % länger dauern als die ersten 95 %
Die alte 80/20-Regel hat sich verschoben. Mit Vibe Coding kommst du auf 95 %. Oberfläche, Login, die einfachen Funktionen, alles da, und es sieht gut aus. Die letzten 5 % sind Throttling-Limits der Microsoft Graph API, Berechtigungsvererbung und Fehlerbehandlung bei halb angelegten Teams. Genau diese 5 % entscheiden jedoch, ob das Tool überhaupt in den Produktivbetrieb darf.
Veracode hat im Frühjahr 2026 über 150 Sprachmodelle an 80 Programmieraufgaben getestet. Die syntaktische Korrektheit lag über 95 %. Die Sicherheit lag bei etwa 55 %, seit zwei Jahren unverändert. Veracodes eigene Formulierung: Die Modelle sind sehr gut darin geworden, Code zu schreiben, der kompiliert, und schlecht darin, Code zu schreiben, der sicher ist.
Entwickler berichten dasselbe. Im Stack Overflow Developer Survey 2025 nennen 66 % als Hauptproblem KI-Lösungen, die fast richtig sind, aber nicht ganz. 45 % sagen, das Debuggen von KI-generiertem Code dauert länger als erwartet.
Auch die Zeitrechnung stimmt oft nicht. Das Forschungsinstitut METR hat im Juli 2025 in einer randomisierten Studie 16 erfahrene Open-Source-Entwickler bei 246 Aufgaben beobachtet. Mit KI-Werkzeugen brauchten sie 19 % länger. Vorher hatten sie 24 % Beschleunigung erwartet. Hinterher glaubten sie weiterhin, 20 % schneller gewesen zu sein. Deine Schätzung wird also nicht falsch, weil dein Team schlecht schätzt. Sie wird falsch, weil sich der Zeitgewinn auch im Rückblick größer anfühlt, als er war.
Was passiert, wenn der Entwickler das Unternehmen verlässt?
Ein interner Kollege baut das Tool, versteht es und pflegt es. Dann wechselt er das Unternehmen. Zurück bleibt eine App, die produktiv im Einsatz ist, deren Logik niemand mehr kennt und deren Dokumentation aus Kommentaren im Code besteht. Beim nächsten Microsoft-Update funktioniert die Provisionierung nicht mehr, und niemand im Haus kann sagen, warum.
Dein Entwickler kennt sich gut aus. Aber das ist nicht der Punkt. Vielmehr ist bedenklich, dass das Wissen an ihn gebunden ist. Frage dich: Wenn diese App heute ausfällt, wer kann sie reparieren? Wenn die Antwort ein Name ist, hast du kein Tool, sondern eine Abhängigkeit.
Am Ende ist es weniger sicher, nicht sicherer
Eine Governance-App braucht hohe Rechte im Tenant: Teams anlegen, Mitgliedschaften ändern, Gäste einladen, Berechtigungen setzen. Ein Fehler in dieser App sitzt im Herz deiner Umgebung, und die Fehlerklassen, an denen KI-Code scheitert, sind die unsichtbaren. In Veracodes Tests lag die Bestehensquote bei Cross-Site-Scripting bei 15 %, bei Log Injection bei 13 %. Beides sieht man einer laufenden App nicht an.
Schlampige Arbeit ist selten die Ursache. Gravierende Fehler bleiben unentdeckt, weil niemand systematisch danach sucht. Kein Pentest-Budget, kein Security Review, kein externer Auditor.
Dazu die Fragen, die deine Compliance-Abteilung stellt:
- Wer ist verantwortlich, wenn über die App Daten abfließen?
- Läuft das Hosting sicher im eigenen VNet oder einfach irgendwo in Azure?
- Wer dokumentiert die Berechtigungen, die die App im Tenant hält?
- Wer weist die Sicherheit gegenüber einem Auditor nach?
Bei uns beantwortet das die Zertifizierung. Solutions2Share ist nach ISO/IEC 27001:2022 zertifiziert, unsere Apps sind Microsoft-zertifiziert und werden von Microsoft auf Herz und Nieren geprüft, bevor sie in den Marketplace kommen. Ein SOC-2-Audit läuft derzeit ebenfalls.
Für Banken, Versicherungen, Energieversorger und öffentliche Auftraggeber ist das nicht nur ein Nice-to-have. Ohne diese Nachweise kommt die Lösung nicht in den Betrieb. Wer sie für ein internes Tool selbst erbringen will, startet ein aufwendiges zweites Projekt neben dem ersten.
Wer geht ran, wenn es am Samstagabend brennt?
Bei einer Eigenentwicklung gibt es kein SLA, keine Rufbereitschaft und keinen Ansprechpartner. Bei Solutions2Share sitzen Teams, die notfalls auch am Wochenende einspringen. Wie würde eine solche Zusage bei euch aussehen, wer ist befugt sie zu geben?
Microsoft entwickelt weiter, ohne dich zu fragen
Microsoft veröffentlicht Änderungen an der Graph API laufend in einem öffentlichen Changelog. Manche sind harmlos, manche unterbrechen Funktionen. Die Anbindung und Provisionierung von OneNote hat Microsoft in den Jahren, in denen wir sie pflegen, bereits fünf Mal umgebaut. Jedes Mal mussten wir innerhalb weniger Tage nachziehen, und unsere Kunden haben davon nichts gemerkt. Genau dafür bezahlen sie.
Bei einer selbstgebauten App merkst du es, wenn Kollegen sich melden. Dann suchst du den Fehler, behebst ihn, testest alles durch. Und in vier Wochen wieder das gleiche. Ein Produktteam verfolgt diese Änderungen dauerhaft, weil es sein Job ist. Eine interne IT-Abteilung priorisiert das nach dem dritten Mal niedriger, weil es dringlichere Tickets gibt.
Warum Copilot dir sagt, dass du das selbst bauen kannst
Frag ein KI-Modell, ob du dir ein Governance-Tool selbst bauen kannst, und es sagt meistens Ja. Ein Modell schätzt Machbarkeit anhand von Code ein, nicht anhand von Betriebsjahren. Es sieht, dass die Graph-Aufrufe existieren. Es sieht nicht die Zertifizierung, die dein Auditor sehen will, nicht die Wartung nach dem nächsten Microsoft-Release und nicht den Support-Aufwand im laufenden Betrieb.
Die Empfehlung ist außerdem nicht neutral. KI-Anbieter verdienen an Tokens. Ein Vorschlag, der viele Entwicklungsstunden erzeugt, ist für sie das bessere Geschäft als der Hinweis auf eine fertige Lösung. So funktioniert das Geschäftsmodell. Bevor du die Empfehlung zur Selbstentwicklung in einen Business Case übernimmst, denke etwas weiter: nicht "kann ich das bauen", sondern "was kostet es mich, das die nächsten fünf Jahre zu betreiben, abzusichern und weiterzuentwickeln".
Governance ist Erfahrung, nicht Code
Unsere Apps sehen relativ einfach aus. Ein Admin legt in Teams Manager eine Vorlage an, klickt sie zusammen, fertig. Was im Hintergrund läuft, ist alles andere als einfach: Berechtigungslogik, Lebenszyklen, Genehmigungsprozesse, Throttling, Wiederherstellung nach halb abgebrochenen Vorgängen. Diese scheinbare Einfachheit ist das Ergebnis von 15 Jahren an genau diesem Thema, aus Hunderten Kundenumgebungen mit unterschiedlichen Tenants, Compliance-Anforderungen und Altlasten. Dein Entwickler macht heute Governance und morgen wieder etwas anderes. Das kann funktionieren. Es hat nur eine andere Fehlertoleranz.
Strategische IT-Ressourcen: Hör auf zu bauen, was du kaufen solltest
Die eigentliche Frage ist nicht, ob dein Team eine Governance-App bauen kann. Die Frage ist, was dein Team währenddessen nicht baut, und ob die TOC tatsächlich geringer sind als eine Software-Lizenz. Ein internes Microsoft 365-Governance-Tool ist kein Projekt mit Enddatum, sondern eine Dauerverpflichtung: Jemand verfolgt die Graph-API-Änderungen, macht die Security Reviews, beantwortet die Tickets und baut nach, was Microsoft verschiebt. Das gehört als laufende Kapazität ins Budget, nicht als einmaliger Sprint.
Rechne es mit euren eigenen Zahlen. Nimm die Vollkosten des Entwicklers, der das Tool übernehmen würde, multipliziere sie mit dem Anteil des Jahres, den es im Produktivbetrieb realistisch frisst, und addiere das Security Review und die Rufbereitschaft, die es bei euch heute nicht gibt. Vergleiche das Ergebnis mit der Lizenz. In kleinen und mittleren Unternehmen ist die interne Zahl meistens die größere.
Dann kommt die strategische Frage. Governance-Tooling für Microsoft 365 ist wahrscheinlich nicht das, womit dein Unternehmen sein Geld verdient. Kapazität, die dort liegt, fehlt bei den Systemen, die nur du bauen kannst: Produkt, Integrationen, Daten. Die Faustregel ist kurz. Wenn es kein Differenzierungsmerkmal ist und jemand es verkauft, kauf es. Eine Governance-App zu kaufen ist eine Entscheidung darüber, wo deine Entwickler Wert schaffen, den sonst niemand schaffen kann.
Die Kurzfassung: Make or Buy?
| Kriterium | Eigenentwicklung mit KI | Teams Manager / External User Manager |
| --- | --- | --- |
| Gesamtkosten (TCO) | laufend, schwer planbar, Tokens plus Personalzeit | Lizenz, kalkulierbar |
| Anteil Erst-Entwicklung am TCO | ca. 15 %, der Rest kommt später | im Preis enthalten |
| Zeit bis zur Nutzung | Monate, bei den letzten 5 % offen | sofort einsatzbereit |
| Codesicherheit | ca. 45 % des KI-Codes mit bekannten Lücken (Veracode 2026) | geprüft, zertifiziert, extern auditiert |
| Microsoft-Änderungen | ihr zieht jedes Mal selbst nach | wir ziehen nach, ihr merkt es nicht |
| Sicherheitsnachweis | selbst zu erbringen | ISO/IEC 27001:2022, Microsoft-Prüfung, SOC-2-Audit läuft |
| Support | intern, kein SLA | definierter Support, Notfallteam am Wochenende |
| Wissensrisiko | an einzelne Personen gebunden | Produktteam und Dokumentation |
| Verantwortung bei Ausfall | vollständig bei euch | bei uns |
Die selbstgebaute Lösung ist am Ende weniger sicher, teurer als geplant, und irgendwann sitzt niemand mehr da, der sie weiterführt.
Wenn du diese Entscheidung gerade vorbereitest, sprich mit uns, bevor du den Aufwand schätzt. Wir zeigen dir gerne im Detail, welche Fälle Teams Manager und External User Manager abdecken, und wo ein eigenes Skript reicht.
Quellen
- Veracode, Spring 2026 GenAI Code Security Update, 24. März 2026. Über 150 Sprachmodelle, 80 Programmieraufgaben, vier Sprachen. veracode.com
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10. Juli 2025. 16 Entwickler, 246 Aufgaben, randomisiert. metr.org
- Stack Overflow, Developer Survey 2025, Abschnitt AI, Dezember 2025. survey.stackoverflow.co
- Microsoft, Microsoft Graph Changelog, laufend aktualisiert. developer.microsoft.com
- Andrej Karpathy, Ursprung des Begriffs Vibe Coding, 2. Februar 2025. x.com/karpathy
- Solutions2Share, eigene Aufwandsverteilung aus 15 Jahren Produktentwicklung für Microsoft 365 Governanc
