Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Das Einbetten interner Wiki-Dokumente, um einen unternehmensinternen KI-Assistenten zum Laufen zu bringen, ist in einem halben Tag erledigt. Das echte Problem bricht am Montagmorgen darauf aus. Es ist der Moment, in dem ein Praktikant im KI-Chatfenster fragt: „Wie sehen die Kriterien für die Berechnung der Boni für Führungskräfte in diesem Jahr aus?“ und das System die vertraulichen Dokumente der Finanzabteilung akribisch zusammengefasst anzeigt.
Plattform-Ingenieure mit 3 bis 7 Jahren Erfahrung, die eine unternehmensinterne Wissensbasis aufbauen, ahnen dieses Problem bereits voraus. Die meisten RAG-Architekturen zerlegen Dokumente und wandeln sie in Einbettungsvektoren um, wodurch das Zugriffsberechtigungssystem der Originaldokumente komplett verworfen wird. Die in Okta oder Azure AD verankerten Zugriffssteuerungsregeln verschwinden in der Vektordatenbank vollständig. Wenn diese Berechtigungslücke nicht auf Ebene der Infrastrukturpipeline anstatt im Anwendungscode geschlossen wird, wird die private Wissensbasis faktisch zu einem Einfallstor für interne Datenlecks.
Die Berechtigungsdiskrepanz zwischen dem unternehmensinternen Authentifizierungssystem und dem Vektorspeicher sollte nicht über Echtzeitabfragen, sondern über eine periodische Metadaten-Synchronisierungspipeline gelöst werden. Ein Ansatz, bei dem bei jeder eingehenden Abfrage die interne IdP-API aufgerufen wird, um die Berechtigungen abzufragen, erhöht die Suchlatenz um über 200 Millisekunden und füllt schnell das Rate-Limit der IdP-API.
Es sollte ein Batch-Job mit Airflow oder Celery ausgeführt werden, der stündlich die Liste der Gruppen aktualisiert, die Eigentümer der Dokumente sind, und diese in ein Metadaten-Array-Feld des Vektordatensatzes schreibt. Am Beispiel von Qdrant wird im Payload jedes Chunks ein allowed_groups-Feld eingerichtet, in das die Okta-Gruppen-IDs direkt eingespeist werden.
json { "chunk_id": "doc_9281_chunk_04", "text": "Budgetplan für die Migration der Serverinfrastruktur im zweiten Halbjahr 2026...", "allowed_groups": ["group_devops_lead", "group_finance_managers"] }
Wenn sich die Dokumentenberechtigungen ändern, werden die Änderungsereignisse des Originaldokuments erkannt und ausschließlich die Metadaten der Vektordatenbank aktualisiert. Da die gesamten Einbettungen nicht neu berechnet werden müssen, fallen keine Rechenkosten an. Wenn ein Benutzer eine Frage stellt, wird der aus dem JWT extrahierte groups-Claim als Suchfilterparameter zwangsweise injiziert. Wird ein Open Policy Agent (OPA) Sidecar vor der Vektordatenbank platziert, kann die Anfrage selbst sofort mit einem HTTP 403 abgewiesen werden, wenn in der vom Client übermittelten Abfrage der Filter für die autorisierten Gruppen des Benutzers fehlt. Laut einem 2024 von der in San Francisco ansässigen Sicherheitsforschungsgruppe Bishop Fox veröffentlichten RAG-Berechtigungsprüfbericht traten 78 % der Sicherheitsvorfälle bei unternehmensinternen LLM-Penetrationstests durch fehlende Metadatenfilter auf. Durch das Erzwingen von Filtern am Infrastrukturtor lässt sich der Arbeitsaufwand für wöchentliche manuelle Berechtigungsprüfungen um mehr als 8 Stunden einsparen.
Wenn dem KI-Assistenten erlaubt wird, unternehmensinterne Dokumente automatisch zusammenzufassen oder den Kontext zu aktualisieren, läuft die Warteschlange für Genehmigungen schnell voll. Gehen Sicherheitsprüfungsanfragen im Posteingang oder Backlog-Ticket ein, dauert die Überprüfung durchschnittlich 72 Stunden. Wird diese Verzögerung vernachlässigt, müssen Ingenieure erleben, wie der interne Assistent veraltete API-Spezifikationen von vor mehreren Monaten beantwortet.
Die Wissensfreigabe sollte genauso wie das unternehmensinterne Code-Review-System über Pull Requests (PRs) in einem Git-Repository abgewickelt werden. Wenn der KI-Agent eine Änderung des Wissensstands vorschlägt, wird ein Branch im Markdown-Dateiformat erstellt, um einen PR zu generieren.
Die CODEOWNERS-Datei im Root-Verzeichnis des Repositories wird eingelesen, um automatisch das für den jeweiligen Dokumentenpfad verantwortliche Engineering-Team zuzuweisen.
`
/docs/architecture/payment/ @team-fintech-core
/docs/infrastructure/k8s/ @team-platform-infra
/docs/security/auth/ @team-infosec
`
Der vom Agenten generierte PR-Webhook wird mit dem dedizierten Slack-Kanal des zuständigen Teams verbunden und zeigt das Diff vor und nach der Änderung sowie eine Genehmigungsschaltfläche an. Wenn ein Teammitglied in Slack auf die Genehmigungsschaltfläche klickt, wird die GitHub-API ausgelöst, um den Branch zu merzen, woraufhin sofort die Bereitstellungspipeline anläuft und nur der entsprechende Dokumenten-Chunk neu in die Vektordatenbank eingebettet wird. Durch die Anpassung des Workflows zur Wissensbasenaktualisierung an den regulären Entwicklungszyklus kann der Engpass bei der Genehmigungszeit auf unter 4 Stunden reduziert werden.
Beim Sammeln von Infrastrukturdokumenten kommt es oft vor, dass von Ingenieuren aus Versehen AWS-Zugriffsschlüssel oder Verbindungszeichenfolgen für Staging-Datenbanken als Konfigurationsbeispiele hinterlassen wurden, die dann unbemerkt mitgescannt werden. Werden diese unverändert an das Einbettungsmodell übergeben, verbleiben unternehmensinterne Anmeldeinformationen in den Cache-Protokollen externer SaaS-LLM-Anbieter und sind anfällig für Prompt-Injection-Angriffe zum Abfangen des Retrieval-Augmented Context. Laut einer Untersuchung zum Cloud-Datenleck des Cybersicherheitsunternehmens Wiz aus dem Jahr 2023 wurden in etwa 12 % der internen Dokumente in Unternehmensumgebungen gültige Anmeldeinformations-Strings entdeckt.
Am ersten Tor der Einbettungspipeline muss unbedingt ein High-Speed-Proxy-Middleware zur Regex-basierten Maskierung platziert werden. Eine Architektur, bei der Text durch einen auf Rust basierenden Proxy-Container geleitet wird, bevor er an tiktoken oder das Chunking-Skript von Python übergeben wird, ist stabil.
`python
import re
PATTERNS = {
"AWS_KEY": r"(?<![A-Z0-9])[A-Z0-9]{20}(?![A-Z0-9])",
"BEARER_TOKEN": r"Bearer\s+[a-zA-Z0-9_-.=]+",
"SLACK_TOKEN": r"xox[baprs]-[0-9]{10,13}-[0-9]{10,13}-[a-zA-Z0-9]{24,32}",
"GENERIC_SECRET": r'(?i)(password|secret|api_key|access_token)\s*[:=]\s*["']?([^"'\s]+)["']?'
}
def scrub_sensitive_data(text: str) -> str:
cleaned = text
for name, pattern in PATTERNS.items():
cleaned = re.sub(pattern, f"[REDACTED_{name}]", cleaned)
return cleaned
`
Wenn diese Filterung fest vor das Einbettungsmodell geschaltet wird, landet selbst dann, wenn ein Infrastrukturingenieur versehentlich ein Produktionsserver-Token in das Original-Wiki schreibt, nur der String [REDACTED_SECRET] in der Vektordatenbank und im Sprachmodell-Kontext. Nur wenn der Zustand beibehalten wird, bei dem selbst autorisierte Benutzer direkt auf das GitHub-Original-Repository oder Vault zugreifen müssen, um Secrets einzusehen, lässt sich die Bedrohung durch die Offenlegung von Anmeldeinformationen auf Infrastrukturebene abwehren.
