Read-only Overlay statt ALM-Ersatz: AI, das Polarion und Jira respektiert

Read-only Overlay statt ALM-Ersatz: AI, das das System-of-Record respektiert

Die größte Sorge bei AI im Engineering ist einfach. Ein Modell könnte die Projekt-Wahrheit überschreiben. Wer sein ALM als System-of-Record ernst nimmt, kann kein Werkzeug gebrauchen, das unkontrolliert zurückschreibt.

Der Ausweg ist ein bewusst read-only aufgebautes Overlay. Das ALM bleibt System-of-Record. AI liefert nur nachvollziehbare Vorschläge. Datenhoheit und AI-Nutzen schließen sich nicht aus. Sie werden zugleich gesichert.

Das ALM bleibt die Wahrheit. AI schlägt vor.

Damit stehen für Sie als Verantwortliche im Engineering konkrete Fragen im Raum:

• Wie ergänzen wir Polarion oder Jira, ohne Datenhoheit abzugeben?
• Wie stellen wir sicher, dass AI nichts unkontrolliert zurückschreibt?
• Wie wird aus einem Vorschlag kontrolliert Projekt-Wahrheit?
• Wie bleibt die Mandanten- und Rollentrennung sauber?

Dieser Beitrag zeigt, wie ein Read-only-Overlay Polarion und Jira respektiert. Und warum genau das Vertrauen und ASPICE-Konformität zugleich schafft.

Die Angst vor der zweiten Wahrheit

Wer ein ALM wie Polarion oder Jira betreibt, kennt die Sorge. Sobald ein weiteres Werkzeug in dieselben Daten schreibt, entstehen zwei Wahrheiten. Und niemand weiß mehr, welche gilt. Bei AI verschärft sich das. Ein Modell produziert schnell, plausibel und in großer Menge. Ein unkontrollierter Write-back wäre das Ende der Datenhoheit.

Die Antwort ist keine Vertrauensfrage. Sie ist eine Architekturentscheidung. Das Overlay ist so gebaut, dass die zweite Wahrheit gar nicht entsteht. AI liest, spiegelt und schlägt vor. Das System-of-Record bleibt die einzige verbindliche Quelle. So wird die größte Sorge zur Nebensache. Sie ist technisch ausgeschlossen.

Das Overlay-Prinzip

Inbound und read-only

Ein Interface-Layer spiegelt Daten aus dem ALM. Inbound und read-only. Polarion über REST und einen VPN-Sync-Agent. Jira über einen Sync-Agent. ReqIF als Datei-Austausch. Ein Write-back findet in der Basisstufe bewusst nicht statt. Die Quelle bleibt unberührt. AI arbeitet auf einer Spiegelung, nicht auf dem Original.

Diese Richtung ist kein Detail. Sie ist die zentrale Design-Entscheidung. Sie stellt sicher, dass kein Modelloutput die bestehende Wahrheit still verändert.

Vom Vorschlag zur Wahrheit

Auf dieser Spiegelung erzeugt AI Derivate. Anforderungen, Testspezifikationen, Analysen. Der Übergang zur Projekt-Wahrheit ist ein bewusster, menschlicher Akt.

• AI erzeugt Vorschläge, klar als solche markiert.
• Erst nach Engineer-Freigabe werden diese Derivate übernommen.
• Row-Level-Security trennt Mandanten und Rollen. Im realen Programm sind das hunderte Policies.

Warum das Vertrauen schafft

Wer die Datenhoheit behält, kann AI ohne Angst vor stillen Änderungen einsetzen. Das Overlay macht jeden Beitrag sichtbar und freigabepflichtig. Es bleibt ASPICE-kompatibel, weil die Evidenzkette im System-of-Record intakt bleibt. Vertrauen entsteht nicht durch ein Versprechen. Es entsteht dadurch, dass unkontrollierter Zugriff unmöglich ist.

Für die Rollen bedeutet das viel. Requirements, Test, Functional Safety und Tool-Administration behalten ihre Werkzeuge. Die AI-Fähigkeit legt sich als Assistenz darüber. Niemand muss sein System aufgeben, um AI zu nutzen.

Die technische Basis

Das Overlay ist bewusst schlank und EU-gebunden.

• App-Stack. React und TypeScript im Frontend, serverlose Deno-Edge-Functions, PostgreSQL mit pgvector.
• EU-Hosting mit Row-Level-Security für die Trennung von Mandanten und Rollen.
• Wissen. Vektor-RAG für Audit-Unterstützung, GraphRAG für Exploration. Getrennt gehalten. Die formalen Trace-Links bleiben die Audit-Quelle.

Häufige Fehler bei der ALM-Integration

• ALM ersetzen wollen. Eine zweite Wahrheit neben dem System-of-Record aufbauen.
• Write-back zu früh. AI zurückschreiben lassen, bevor Freigabeprozesse stehen.
• Trace aus RAG. RAG-Ausgaben als Audit-Quelle behandeln statt formaler Trace-Links.

Ein späterer, kontrollierter Write-back ist als Ausbaustufe denkbar. Aber erst, wenn Freigabeprozesse, Rechte und Audit sauber stehen. Bis dahin ist read-only kein Kompromiss. Es ist die Garantie, dass Ihr System-of-Record die einzige verbindliche Quelle bleibt.

So gehen wir vor: Build, Operate, Transfer

Ein read-only AI-Overlay auf ALM-Tools bauen wir nicht als Folienkonzept. Wir bauen es als produktive Fähigkeit. Das folgt dem Prinzip Build, Operate, Transfer. Unsere Beteiligung nimmt über die Phasen ab. Ihre Capability wächst ins eigene Haus. Der Wissenstransfer ist vertragliches Erfolgskriterium, kein Zusatz. Sonst entsteht genau der Lock-in, den wir vermeiden wollen.

1. Build. Setup, Guardrails und erste Workflows entlang Ihres realen Prozesses.
2. Operate. Betrieb mit KPI-Verantwortung auf Wertstrom-Ebene. Nie auf Personen-Telemetrie.
3. Transfer. Dokumentierte Übergabe. Ihr Team übernimmt Tooling, Wissen und Betrieb.

Getragen wird das von drei Modulen. Erstens ein Strategic Engineering Lead. Das ist ein Senior-Embedded-Architekt zusammen mit einem Strategic AI Lead. Zweitens die auditierbare Tooling-Plane sensified AI-OS. Drittens die Automotive-Playbooks. Sie beschreiben die Methodik für AI in Embedded-, ASIL-, ASPICE- und AUTOSAR-Kontexten. Die Leitplanke, was AI nicht entscheidet, ist darin fest verankert.

Die vier Mandat-Typen sind kombinierbar. Sie passen sich Ihrem Reifegrad an. Es gibt den Strategic Engineering Lead für den breiten Aufbau. Es gibt die BOT Engineering-Capability als Programm-Paket je Domäne. Es gibt den ASPICE- oder ASIL-Workflow-Pilot zur Validierung vor dem Mandat. Und es gibt das Modul Tooling, MCP und AI-Governance mit Schlüssel-Isolation und Kosten-Transparenz. Der Einstieg ist bewusst risikoarm. Zuerst ein Qualifying-Call zum Fit-Check. Dann NDA und Discovery-Workshop. Danach der Workflow-Pilot. Erst dann das BOT-Mandat mit Governance-Plane. Kommerzielle Details klären wir im Discovery-Workshop, nicht über öffentliche Preislisten.

Gemessen wird auf Wertstrom-Ebene, nie an Personen. Wir messen Kosten je Wertstrom, den Produktivitäts-Zuwachs und die reale Nutzung. So bleibt jederzeit belegbar, ob sich die Fähigkeit rechnet. Das entscheidet über den nächsten Ausbauschritt. Der Betrieb erzeugt keine Chat-Historie als Ergebnis. Er erzeugt prüfbare Artefakte, die in Ihren Prozess passen. Dazu gehören Reports, Traceability-Matrizen und ausführbare Testsuiten.

Der Pilot ist bewusst klein gehalten. Er dauert wenige Wochen. Er nimmt sich einen realen Ausschnitt Ihres Prozesses vor, nicht ein Laborbeispiel. Am Ende steht ein belastbarer Beleg. Sie sehen, ob die Kette hält und ob sich der Aufwand lohnt. Erst auf dieser Basis entscheiden wir gemeinsam über das volle Mandat. So bleibt jedes Investment an ein sichtbares Ergebnis gebunden.

Was in diesen Sichten fachlich passiert, zeigen zwei Nachbarbeiträge: Requirements-Engineering mit AI in SWE.1 und die Abstraktionsschicht ohne Vendor-Lock-in als Plattform-Grundlage.

Fazit

Es gibt einen Unterschied zwischen zwei Sätzen. Der erste lautet: Wir nutzen AI-Tools. Der zweite lautet: Wir besitzen eine beherrschte, auditierbare AI-Engineering-Capability. Dieser Unterschied entscheidet, ob AI im Serienprogramm trägt oder im Pilot versandet. Genau diese Entscheidungen hat sensified für den eigenen Betrieb getroffen. Sie sind in einem realen ASPICE-Serienprogramm gebaut. Deshalb kommt sensified mit einer Position, nicht mit Fragen.

Drei Dinge unterscheiden diesen Ansatz. Es gibt einen klaren Plan, belegt durch eigenes, produktives IP. Wir bauen es mit, bis es ASPICE-konform in Produktion läuft. Und es gibt keinen Vendor-Lock-in, abgesichert durch modell-agnostische Architektur und Transfer als Erfolgskriterium. Zwei Tiefen treffen dabei in einem Partner zusammen. Das ist etabliertes Automotive- und SDV-Wissen. Und es ist AI-Engineering-Tiefe aus eigener Plattform.

Wie dieser Baustein in eine beherrschte Gesamt-Capability passt, zeigt unsere Seite zur AI-Transformation im Automotive-Engineering. Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema. Der nächste Schritt ist ein Discovery-Workshop. Dort ordnen wir Ihren Prozess, Ihre Compliance-Lage und den ersten sinnvollen Use-Case gemeinsam ein.

Das Wichtigste in Kürze

• Das ALM bleibt System-of-Record. AI spiegelt inbound und read-only.
• Aus Derivaten wird erst nach Engineer-Freigabe Projekt-Wahrheit.
• Row-Level-Security sichert die Trennung von Mandanten und Rollen.
• Formale Trace-Links bleiben die Audit-Quelle, nicht RAG-Ausgaben.