Governance-plan. Das schriftliche artefakt, das mit jeder ai-umsetzung geliefert wird: ein policy-dokument, das beschreibt, was die AI entscheiden darf und was nicht, ein audit-log, das jede aktion und ihr ergebnis zeigt, und ein rollback-plan, der den betrieb 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, parallel zur implementierung geschrieben und getestet.
- 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-anleitung, um den workflow auf die manuelle oder vorherige fassung zurückzusetzen. Getestet, nicht theoretisch. Eine benannte person verantwortet den plan.
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 typischerweise mitten im projekt passiert
Bei vielen implementierungen kommt mittendrin ein stakeholder ins projekt — oft ein CFO, eine compliance-leitung oder ein ops-direktor, der im ersten briefing nicht dabei war. Die fragen sind vorhersehbar: was tut dieses modell, wenn es falsch liegt? Wer ist verantwortlich? Was ist der schlimmste ausfall und wie erholen wir uns?
Wenn diese fragen kommen und der governance-plan schon existiert, ist das meeting kurz. Wenn sie kommen und das team die antworten nachträglich erst bauen muss, verlangsamt sich das projekt, stoppt manchmal und wird gelegentlich abgebrochen. Der governance-plan ist das dokument, das verhindert, dass ein meeting mitten im projekt zu einer langen verzögerung wird.
We are
Liefere drei schriftliche artefakte — policy, audit-log-spec, rollback-plan — als teil des vereinbarten umfangs. Der governance-plan ist getestet, in klarer sprache verfasst und von anfang an im besitz eures teams.
We aren't
Firmen, die governance nach dem go-live als zusatzmodul anhängen, oder folien, die 'responsible-ai-prinzipien' beschreiben, ohne ein einziges rollback-verfahren zu nennen.
#Was in die erstellung einfließt
Der governance-plan ist zusätzliche arbeit zu einem standard-implementierungsengagement. Ein senior engineer und eine strategin verfassen ihn parallel zur letzten testphase, sodass er die auslieferung nicht aufhält. Er gehört zum umfang, der im discovery-call vereinbart wird.
Eigenständige governance-engagements — für organisationen, die schon AI im einsatz haben und die schriftlichen artefakte brauchen — werden im discovery-call schriftlich umrissen. Die form ist ein audit der laufenden AI plus die drei dokumente: das policy-dokument, die audit-log-spec und der rollback-plan — unabhängig davon, ob wir den build liefern. Ist die AI schon in produktion und der governance-plan fehlt, deckt das audit zuerst auf, was 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 im discovery-call schriftlich umrissen, bevor irgendeine arbeit beginnt. Geliefert werden dieselben drei dokumente (policy-dokument, audit-log-spec, rollback-plan), geschrieben nach einem audit der AI, die ihr im einsatz habt. Für organisationen, die schnell live gegangen sind und das schriftliche fundament brauchen, bevor das compliance-gespräch kommt.
