Engineering-Wissen mit KI sichern vor dem Renteneintritt

Wissenssicherung vor dem Renteneintritt: Engineering-Wissen mit KI erfassen

Das Wissen von Ingenieuren, die in Rente gehen, lässt sich systematisch erfassen: über strukturierte Debriefing-Interviews entlang der Arbeitsprodukte, kommentierte Code- und Doku-Reviews mit dem Wissensträger und dokumentierte Entscheidungsfälle. Künstliche Intelligenz (KI) trägt dabei die Aufbereitung, also Transkription, Strukturierung, Verschlagwortung und die Überführung in ein durchsuchbares System mit Quellenangabe. Priorisiert wird entlang von zwei Achsen: Wie kritisch ist ein Wissensgebiet für das laufende Geschäft, und wie hoch ist das Risiko, dass es mit einer Person das Haus verlässt. Das Debriefing selbst bleibt eine menschliche Aufgabe; KI macht es skalierbar. sensified beschreibt den Erfassungs- und Aufbereitungspfad und ordnet jeden KI-Baustein in einen Freigabepfad ein, der die Ergebnisse belegbar hält.

Die Situation ist in vielen Entwicklungsabteilungen dieselbe. Der Kollege, der die Basissoftware-Integration einer Plattform seit fünfzehn Jahren betreut, geht in achtzehn Monaten in Rente. Die Kollegin, die als Einzige weiß, warum der Diagnose-Stack eines Altstands von der Serienlinie abweicht, hat ein Abfindungsangebot angenommen. Die Nachfolge ist bestenfalls teilweise geregelt, und ein erheblicher Teil des Wissens über Architektur-Entscheidungen, Toolchain-Eigenheiten und Kunden-Spezifika existiert ausschließlich in den Köpfen dieser Personen. Dieser Beitrag beschreibt, wie eine Entwicklungsleitung dieses Wissen in den verbleibenden Monaten systematisch erfasst und mit KI-Unterstützung aufbereitet. Er gehört zur Werkzeug-Ebene, die der Überblick über KI in der Automotive-Softwareentwicklung aufspannt. Eine Einordnung vorweg: Die Eignungs- und Aufwandsaussagen sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Das Zeitfenster: zwei Auslöser treffen zusammen

Wissenssicherung wird selten aus Prinzip gestartet. Sie wird gestartet, wenn ein Datum feststeht. Derzeit treffen zwei Auslöser zusammen: die Renteneintritte der geburtenstarken Jahrgänge und ein Stellenabbau, der die Zulieferindustrie deutlich härter trifft als die Fahrzeughersteller.

Was die Beschäftigungszahlen zeigen

Zum Ende des 3. Quartals 2025 arbeiteten in der deutschen Automobilindustrie 48.700 Beschäftigte weniger als ein Jahr zuvor, ein Rückgang um 6,3 % auf 721.400 Personen und der niedrigste Stand seit dem 2. Quartal 2011. Im Zulieferbereich der Herstellung von Teilen und Zubehör für Kraftwagen fiel der Rückgang mit 11,1 % auf knapp 235.400 Beschäftigte noch einmal deutlich höher aus (Quelle: Statistisches Bundesamt, Destatis, 2025). Hinter diesen Zahlen stehen keine anonymen Kapazitäten. Es sind Entwicklerinnen und Entwickler mit zehn, zwanzig oder dreißig Jahren Projektgeschichte, und mit jedem Austritt verlässt ein Stück dieser Geschichte das Haus.

Was das für die Wissensbasis bedeutet

Der Renteneintritt ist planbar; das Austrittsdatum steht Jahre vorher fest. Der Stellenabbau ist es oft nicht, denn zwischen Angebot und Austritt liegen manchmal nur Monate. Für die Entwicklungsleitung heißt das: Wer heute weiß, dass in den nächsten 24 Monaten Schlüssel-Wissensträger ausscheiden, hat noch die Wahl zwischen einem geordneten Programm und einer hektischen Übergabewoche kurz vor dem letzten Arbeitstag. Die Erfahrung aus gewachsenen Serienprojekten spricht klar für das Programm, denn das kritischste Wissen ist genau das, das sich in einer Woche nicht übergeben lässt.

Welches Engineering-Wissen kritisch ist

Nicht jedes Wissen muss gesichert werden. Prozessbeschreibungen, Arbeitsanweisungen und aktuelle Anforderungsstände liegen in den führenden Systemen und überleben jeden Personalwechsel. Kritisch ist das Wissen, das dort nicht steht. In Engineering-Organisationen sind es typischerweise vier Kategorien.

Architektur-Entscheidungen und ihre Gründe

Arbeitsprodukte nach Automotive SPICE (ASPICE) dokumentieren zuverlässig, was entschieden wurde: die Architektur, die Schnittstellen, die Zuordnung von Anforderungen. Deutlich seltener dokumentieren sie, warum. Warum wurde die Kommunikationsmatrix so geschnitten, welche Alternative wurde 2019 verworfen und aus welchem Grund, welche Randbedingung des Kunden hat eine scheinbar unelegante Lösung erzwungen. Dieses Warum-Wissen entscheidet darüber, ob ein Nachfolger eine gewachsene Struktur weiterentwickeln kann oder sie bei der ersten Änderung versehentlich bricht. Es ist fast immer an wenige Personen gebunden.

Toolchain-Eigenheiten, Altstände und Kunden-Spezifika

Die zweite Kategorie ist das Ausnahme-Wissen: die Build-Umgebung, die nur mit einer bestimmten Compiler-Version reproduzierbare Ergebnisse liefert; der Plattform-Altstand, dessen Diagnose-Implementierung von der Serienlinie abweicht und bei dem drei Workarounds dokumentationslos aufeinander aufbauen; die Kunden-Spezifika je Plattform, also welcher Auftraggeber welche Abweichung akzeptiert hat und welche Zusagen mündlich gemacht wurden. Solches Wissen taucht in keinem Anforderungsdokument auf und wird meist erst dann vermisst, wenn ein Fehler im Feld genau den Altstand betrifft, den niemand mehr kennt. Wie KI beim Verständnis gewachsener Codebasen unterstützt, beschreibt der Beitrag zum KI-gestützten Codeverständnis in AUTOSAR- und Legacy-Beständen; die Wissenssicherung ergänzt diese Werkzeug-Sicht um das, was im Code selbst nicht steht.

Priorisieren mit der Matrix aus Kritikalität und Ausscheide-Risiko

Vollständige Wissenssicherung über alle Personen und Themen ist weder bezahlbar noch nötig. Tragfähig ist eine Priorisierung entlang von zwei Achsen: der Kritikalität eines Wissensgebiets für laufende und kommende Projekte und dem Ausscheide-Risiko, also der Wahrscheinlichkeit, dass die tragenden Personen das Gebiet in absehbarer Zeit verlassen.

Zwei Hinweise zur Anwendung. Erstens wird je Wissensgebiet eingestuft, nicht je Person; eine Person trägt oft mehrere Gebiete mit unterschiedlicher Kritikalität. Zweitens gehört auch der bewusste Verzicht in die Matrix: Wer entscheidet, das Wissen zu einem auslaufenden Randthema nicht zu sichern, sollte diese Entscheidung festhalten, damit sie später als Entscheidung erkennbar ist und nicht als Versäumnis. Die Einstufung selbst gelingt erfahrungsgemäß in einem halbtägigen Termin mit den Team- und Gruppenleitungen; sie ist der billigste Schritt des ganzen Programms und der mit der größten Hebelwirkung.

Erfassungs-Workflows, die tragen

Für die eigentliche Erfassung haben sich drei Workflows bewährt, die sich ergänzen und alle am selben Prinzip ausrichten: Der Leitfaden folgt den Arbeitsprodukten des Wissensträgers, nicht seiner Biografie.

Debriefing-Interviews entlang der Arbeitsprodukte

Das strukturierte Debriefing-Interview ist das Rückgrat. Statt allgemein nach Erfahrungen zu fragen, geht der Interviewer die konkreten Arbeitsprodukte durch: das Architekturdokument, die Schnittstellenbeschreibung, die Testumgebung, den Release-Prozess der Plattform. Zu jedem Artefakt gehören dieselben Fragen: Was steht hier nicht drin, was man wissen muss? Was würde ein Nachfolger hier falsch verstehen? Welche Entscheidung dahinter würde heute anders ausfallen? Sitzungen von 60 bis 90 Minuten haben sich bewährt, aufgezeichnet mit ausdrücklicher Zustimmung des Wissensträgers, verteilt über mehrere Wochen. Der Wissensträger bleibt dabei Fachexperte, kein Prüfling; das Format lebt davon, dass es als Wertschätzung der geleisteten Ingenieursarbeit aufgesetzt ist.

Kommentierte Reviews und dokumentierte Entscheidungsfälle

Der zweite Workflow ist das kommentierte Review: Der Wissensträger führt einen oder zwei Nachfolger durch ausgewählte Code-Stellen und Dokumente und kommentiert laut, was er sieht, während die Sitzung aufgezeichnet wird. Gerade das Ausnahme-Wissen zu Altständen kommt fast nur auf diesem Weg an die Oberfläche, weil es an konkreten Stellen im Code hängt. Der dritte Workflow sind dokumentierte Entscheidungsfälle: Für die wichtigsten Architektur- und Prozessentscheidungen wird nachträglich ein kurzer Steckbrief erstellt, mit Kontext, geprüften Optionen, getroffener Entscheidung und beobachteten Konsequenzen. Zwanzig solcher Fälle sagen über eine Plattform oft mehr aus als zweihundert Seiten Regeldokumentation.

Was KI in der Aufbereitung leistet

Ohne Unterstützung erzeugen die drei Workflows ein neues Problem: Dutzende Stunden Audio- und Videomaterial, die niemand nachbearbeitet. Genau hier trägt KI, und zwar entlang einer klar geordneten Kette.

Von der Rohaufnahme zum durchsuchbaren System

Der erste Schritt ist die Transkription der Aufnahmen, einschließlich Sprecherzuordnung. Der zweite ist die Strukturierung: Das Sprachmodell gliedert das Transkript nach Themen, ordnet Passagen den besprochenen Arbeitsprodukten zu und markiert Aussagen, die wie Entscheidungsbegründungen, Warnungen oder Workaround-Beschreibungen klingen. Der dritte Schritt ist die Verschlagwortung nach einem projektspezifischen Schema, etwa nach Steuergerät, Plattform, Kunde, Modul und Themenart. Der vierte Schritt ist die Überführung in eine durchsuchbare, quellenbelegte Ablage: Jede Aussage bleibt mit der Fundstelle in der Aufnahme, dem Datum und dem Namen des Wissensträgers verknüpft. Wie eine solche abfragbare Wissens-Sicht technisch an die führenden Systeme angebunden wird, beschreibt der Beitrag zur RAG-Architektur für Entwicklungsdokumentation mit DOORS und Polarion. Für die Wissenssicherung gilt dieselbe Regel wie dort: Eine Antwort ohne Fundstelle ist im Serienkontext keine Auskunft.

Triage-Einordnung und Freigabepfad

Auch die Wissenssicherung folgt der Triage-Logik, die sensified über alle KI-Bausteine legt. Die Aufbereitungskette aus Transkription, Strukturierung und Verschlagwortung ist Klasse A2, vorbereitende Automatisierung mit Prüfpunkt beim Menschen: Der Wissensträger oder ein benannter Nachfolger prüft die aufbereitete Fassung und gibt sie frei, bevor sie in die Ablage geht. Dieser Prüfpunkt ist fachlich zwingend, denn Transkriptions- und Zuordnungsfehler bei Fachbegriffen, Signalnamen und Modulbezeichnungen sind häufig und in einer Wissensbasis besonders langlebig. Die spätere abfragbare Sicht auf das gesicherte Wissen ist Klasse B, rein lesende Augmentation mit Quellenangabe. Eine autonome Fallabwicklung, bei der ein System Wissenslücken selbstständig schließt oder Inhalte ungefragt fortschreibt, ist Klasse C und startet als nicht zulässig. Der rote Faden bleibt derselbe wie überall in der Werkzeug-Ebene: KI assistiert, der Mensch verantwortet.

Die Grenze: das Debriefing bleibt Menschenarbeit

So weit die Aufbereitung trägt, so klar liegt die Grenze davor. Das Debriefing selbst kann ein Sprachmodell nicht führen. Implizites Wissen kommt im Gespräch an die Oberfläche, wenn ein erfahrener Interviewer nachhakt, Widersprüche bemerkt, eine beiläufige Bemerkung ernst nimmt und dem Wissensträger das Gefühl gibt, dass seine Arbeit gewürdigt wird. Ein Ingenieur, der dreißig Jahre Verantwortung getragen hat, erzählt die entscheidenden Dinge einem Menschen, der zuhört; einem Formular oder einem Chatfenster erzählt er sie nicht. Was KI verändert, ist die Rechnung dahinter: Wo früher aus vierzig Stunden Interviewmaterial in wochenlanger Handarbeit ein lückenhaftes Protokoll wurde, entsteht heute in Tagen eine geprüfte, verschlagwortete und durchsuchbare Wissensbasis. Als typisierte Hypothese aus Projekterfahrung formuliert: Die Erfassung bleibt im Aufwand ungefähr konstant, die Aufbereitung schrumpft um eine Größenordnung, und erst diese Verschiebung macht Wissenssicherung in der Breite bezahlbar. KI ersetzt das Debriefing also nicht; sie macht es skalierbar.

Nächste Schritte

Wissenssicherung ist kein Werkzeugkauf, und sie beginnt nicht mit der Frage nach dem besten Transkriptionsmodell. Sie beginnt mit der Matrix aus Kritikalität und Ausscheide-Risiko und mit einer ehrlichen Liste der Austritte der nächsten 24 Monate. Der geordnete Einstieg sieht so aus:

1. Grundlagen lesen: Das Wertbeitrags-Prinzip im Automotive Software Engineering erklärt Tätigkeitsklassen, Wertströme und Triage, in die sich auch die Wissenssicherung einordnet.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus einzelnen Bausteinen ein geführtes Transformationsvorhaben wird, zu dem die Wissenssicherung als eigener Wertstrom gehört.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, welche Wissensgebiete in Ihrer Organisation in das obere linke Feld der Matrix fallen und ob das Zeitfenster für ein geordnetes Programm reicht.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zur Wissenssicherung im Engineering zusammen. Sie beschreiben typisierte Workflows und Einordnungen; wie das Programm in einer konkreten Organisation aussieht, wird je Kunde, Toolchain und Personalsituation geprüft.

Wie erfassen wir das Wissen von Ingenieuren, die in Rente gehen?

Über drei sich ergänzende Workflows: strukturierte Debriefing-Interviews entlang der konkreten Arbeitsprodukte, kommentierte Code- und Doku-Reviews mit dem Wissensträger und dokumentierte Entscheidungsfälle zu den wichtigsten Architektur-Entscheidungen. KI übernimmt anschließend Transkription, Strukturierung und Verschlagwortung und überführt die Inhalte in ein durchsuchbares System mit Quellenangabe. Priorisiert wird vorher über eine Matrix aus Kritikalität und Ausscheide-Risiko.

Welches Engineering-Wissen ist am kritischsten?

Das Wissen, das in keinem führenden System steht: die Gründe hinter Architektur-Entscheidungen, Toolchain-Eigenheiten wie reproduzierbare Build-Umgebungen, Ausnahme-Wissen zu Altständen mit undokumentierten Workarounds und Kunden-Spezifika je Plattform. Prozessbeschreibungen und aktuelle Anforderungsstände sind dagegen meist gut dokumentiert und überleben Personalwechsel ohne Sonderprogramm.

Kann KI das Debriefing-Interview ersetzen?

Nein. Implizites Wissen kommt im Gespräch mit einem erfahrenen Interviewer an die Oberfläche, der nachhakt, Widersprüche bemerkt und Vertrauen aufbaut. KI trägt die nachgelagerte Kette aus Transkription, Strukturierung, Verschlagwortung und Überführung in eine durchsuchbare Ablage und senkt dort den Aufwand um eine Größenordnung. Das macht das Debriefing skalierbar, ersetzt es aber nicht.

Wann sollte die Wissenssicherung beginnen?

Sobald ein Austritt absehbar ist, idealerweise 12 bis 24 Monate vorher. Debriefing-Interviews und kommentierte Reviews brauchen mehrere Sitzungen über Wochen, und die Prüfung der aufbereiteten Inhalte durch den Wissensträger muss vor dessen letztem Arbeitstag abgeschlossen sein. Eine Übergabewoche kurz vor dem Austritt reicht für das kritische Warum-Wissen erfahrungsgemäß nicht.

Wie bleibt das erfasste Wissen später auffindbar und belegbar?

Jede Aussage wird verschlagwortet, etwa nach Steuergerät, Plattform, Kunde und Modul, und bleibt mit Fundstelle in der Aufnahme, Datum und Wissensträger verknüpft. Die abfragbare Sicht darauf arbeitet rein lesend und zeigt zu jeder Antwort die Quelle an. Antworten ohne Fundstelle sind im Serienkontext nicht verwertbar.

Wer prüft die KI-aufbereiteten Inhalte, bevor sie in die Wissensbasis gehen?

Der Wissensträger selbst oder ein benannter Nachfolger. Die Aufbereitung ist vorbereitende Automatisierung mit Prüfpunkt beim Menschen, weil Transkriptions- und Zuordnungsfehler bei Fachbegriffen, Signalnamen und Modulbezeichnungen häufig sind und in einer Wissensbasis lange unentdeckt bleiben. Erst nach dieser Freigabe wird ein Inhalt Teil des durchsuchbaren Bestands.

Lohnt die Wissenssicherung auch bei Stellenabbau, wenn das Austrittsdatum kurzfristig feststeht?

Ja, dann in verdichteter Form: Die Matrix aus Kritikalität und Ausscheide-Risiko wird in einem halbtägigen Termin erstellt, danach konzentriert sich das Programm auf Kompakt-Debriefings zu den zwei bis drei kritischsten Arbeitsprodukten je Wissensträger. Der Beschäftigungsrückgang von 11,1 % im Zulieferbereich der Herstellung von Teilen und Zubehör für Kraftwagen binnen eines Jahres (Statistisches Bundesamt, 2025) zeigt, dass viele Organisationen genau in dieser verdichteten Lage sind.