governance-plan. das schriftliche artefakt, das mit jeder ai-umsetzung ausgeliefert wird: ein policy-dokument, das beschreibt, was die ai entscheiden darf und was nicht, ein audit-log, das jede aktion und ihr ergebnis dokumentiert, und ein rollback-plan, der den betrieb innerhalb eines werktags in den zustand vor der ai zurückführt.
die meisten ai-consultancies liefern code. wir liefern code plus einen governance-plan. der governance-plan ist kein optionales add-on und kein nachgedanke in der letzten woche. er steht ab tag eins im vertrag und wird mit der umsetzung ausgeliefert.
#warum governance im scope ist, nicht außerhalb davon
das muster, das in frühen engagements immer wieder auftauchte, war dieses: ein team verbringt wochen damit, einen ai-workflow zu bauen und auszuliefern. er geht live. dann stellt jemand eine frage, die das team nicht sauber beantworten kann. wer hat diese entscheidung genehmigt? was passiert, wenn das modell im skalierten betrieb eine falsche antwort produziert? wie kehren wir zum vorherigen prozess zurück, wenn es nötig wird?
diese fragen sind keine randfälle. es sind die ersten fragen, die ein risk officer, ein legal team oder eine neue ops-leitung stellen wird. wenn die antworten nicht dokumentiert sind — nicht in der modell-config, nicht in einer readme, sondern in einem lesbaren schriftlichen artefakt — steht der ai-workflow auf weichem boden.
wir packen governance in den scope, weil eine lieferung ohne sie unvollständig ist. der workflow läuft, aber die organisation ist nicht bereit, ihn zu besitzen.
#was der governance-plan tatsächlich enthält
drei dokumente. sie zu schreiben und zu testen dauert eine woche, kein quartal.
- policy-dokument — was die ai entscheiden darf, was sie an einen menschen eskalieren muss und was sie niemals tun darf. geschrieben für das ops-team, nicht für engineers.
- audit-log-spec — das schema und die aufbewahrungsregeln für jede ai-aktion. wer hat gehandelt, mit welchem input, mit welchem output, zu welcher zeit. das ist das dokument, nach dem euer compliance-team irgendwann fragen wird.
- rollback-plan — schritt-für-schritt-anweisungen, um den workflow auf seine manuelle oder vorherige version zurückzusetzen. getestet, nicht theoretisch. eine benannte person besitzt den plan, mit einem zielfenster von einem werktag.
braucht das policy-dokument einen anwalt?
nicht für die erste version. das policy-dokument ist ein operatives dokument, kein juristisches. es beschreibt, was die ai tut und was menschen besitzen. wenn eure organisation später eine formelle ai-nutzungsrichtlinie für compliance oder regulierung braucht, ist das policy-dokument die evidenzbasis, die das schreiben einer solchen schneller macht. wir übergeben es eurem team in klarer sprache.
#das gespräch, das oft in woche drei stattfindet
bei etwa der hälfte der umsetzungen kommt ein stakeholder — oft ein cfo, eine compliance-leitung oder ein ops-director, die im ursprünglichen briefing nicht dabei waren — in woche drei ins projekt. die fragen, die sie stellen, sind vorhersehbar: was tut dieses modell, wenn es falsch liegt? wer ist verantwortlich? was ist der worst-case-fehler und wie erholen wir uns davon?
wenn diese fragen kommen und der governance-plan bereits existiert, dauert das meeting 20 minuten. wenn diese fragen kommen und das team die antworten rückwirkend bauen muss, verlangsamt sich das projekt, manchmal stoppt es, gelegentlich wird es eingestellt. der governance-plan ist das dokument, das aus dem meeting in woche drei keine verzögerung von woche acht macht.
we are
liefern drei schriftliche artefakte — policy, audit-log-spec, rollback-plan — als teil des festpreis-scopes. der governance-plan ist getestet, in klarer sprache verfasst und ab tag eins im besitz eures teams.
we aren't
consultancies, die governance als retainer-modul nach go-live hinzufügen, oder foliendecks, die „responsible ai principles" beschreiben, ohne eine einzige rollback-prozedur zu benennen.
#was governance in der herstellung kostet
der governance-plan fügt einem standard-umsetzungsengagement etwa eine woche arbeit hinzu. ein senior-engineer und ein stratege verfassen ihn gemeinsam parallel zur finalen testphase. er verlängert den liefertermin nicht. er ist im festpreis enthalten.
eigenständige governance-engagements — für organisationen, die bereits ai im betrieb haben und die schriftlichen artefakte brauchen — haben ihren eigenen scope und preis; spezifika im discovery-call. die form ist ein 2-wochen-audit plus die drei dokumente: das policy-dokument, die audit-log-spec und der rollback-plan — ob wir den build ausliefern oder nicht. wenn die ai bereits in produktion ist und der governance-plan fehlt, deckt das audit auf, was zuerst nötig ist.
#warum wir es nicht-optional gemacht haben
der einfachste grund: ein ai-workflow ohne governance-plan ist ein unvollständiges produkt. er läuft vielleicht heute. er wird probleme verursachen, sobald ein team-mitglied wechselt, ein regulator eine frage stellt oder sich die outputs des modells unerwartet verschieben.
der zweite grund: optionale add-ons sind die, die in scope-verhandlungen gestrichen werden. governance ist kein feature. sie ist der beleg dafür, dass die umsetzung ordentlich gemacht wurde.
wir sind neu. die konditionen auf dieser seite sind das, was wir mit dem ersten kunden, der unterschreibt, einhalten werden. wenn du eine ai-umsetzung scopest und sehen willst, wie ein governance-plan aussieht, bevor du dich verpflichtest, buche einen 30-min-discovery-call. wir gehen im call ein redigiertes beispiel durch.
verkauft ihr governance-pläne für ai, die ihr nicht gebaut habt?
ja. eigenständige governance-engagements werden schriftlich gescopet, bevor irgendeine arbeit beginnt — preis im discovery-call. das ergebnis sind die gleichen drei dokumente (policy-dokument, audit-log-spec, rollback-plan), geschrieben nach einem 2-wochen-audit der ai, die ihr betreibt. für organisationen, die schnell ausgeliefert haben und das schriftliche fundament brauchen, bevor das compliance-gespräch ansteht.