Sandias Leitlinien zur KI-Sicherheit setzen Tri-Valley-Startups unter Zugzwang

Sandia National Laboratories brachte vier Forschende vor Tri-Valley-Startups zusammen und sprach eine Warnung aus: Die schnelle KI-Einführung schafft Risiken, die herkömmliche Softwareprüfungen übersehen können. Das Panel vom 29. Juli stellte Sandias Methoden zur KI-Sicherheit in einen geschäftlichen Kontext, in dem kleine Teams Modelle häufig einsetzen, bevor sie formelle Absicherungsprogramme etablieren.

Die Veranstaltung stellte weder ein neues Produkt noch einen verbindlichen Standard oder eine Regulierung vor. Ihre Bedeutung lag im von Sandia präsentierten Betriebsmodell. Startups sollten Daten, Modelle, Integrationen und menschliche Entscheidungen als zusammenhängendes System untersuchen und dieses anschließend gegen realistische Fehlerfälle und Angriffe testen.

Diese Position erzeugt einen klaren Konflikt zwischen Bereitstellungsgeschwindigkeit und Sicherheitsnachweisen. Startups konkurrieren, indem sie Funktionen früh veröffentlichen, von Nutzern lernen und rasch die Richtung ändern. Sandia betrachtet KI aus Umgebungen mit hohen Folgen, in denen ein nicht erklärter Fehler ein gesamtes System untergraben kann.

Das Panel stellte zudem eine verbreitete Annahme von Startups infrage. Die Nutzung eines Modells über einen renommierten Anbieter überträgt nicht jedes Risiko auf diesen Anbieter. Das Unternehmen, das die finale Anwendung entwickelt, kontrolliert weiterhin seinen Datenzugriff, die Retrieval-Schicht, Tools, Berechtigungen, Nutzererfahrung und Reaktionsverfahren.

Damit wird KI-Absicherung zu einer Produktverantwortung und nicht zu einer abschließenden Compliance-Übung. Die unmittelbare Frage für Gründer lautet, ob ihre Teams Nachweise über das Systemverhalten erbringen können, bevor Kunden, Aufsichtsbehörden oder Angreifer sie verlangen.

KI-Sicherheit von Sandia kommt aus dem Labor in die Startup-Praxis

Die Veranstaltung übersetzte nationale Sicherheitsbedenken in operative Fragen, mit denen junge Unternehmen bereits konfrontiert sind.

Daybreak Labs veranstaltete das kostenlose Lunch and Learn in Livermore, Kalifornien, von 11:30 bis 13:30 Uhr. Der gemeinnützige Inkubator unterstützt Life-Sciences- und Deep-Tech-Startups in der Tri-Valley-Region.

Am Panel nahmen Amanda Dodd, Gayle Thayer, Philip Kegelmeyer und Jonathan Crussell von Sandia teil. Ihre Hintergründe umfassten nationale Sicherheitsanalyse, sichere Algorithmen, adversarische Datenanalyse, Softwaresicherheit und agentische KI-Workflows.

Dodd, Sandias Direktorin für Computation und Analysis for National Security, ordnete die Diskussion anhand von Schwachstellen ein, die durch die schnelle Einführung entstehen. Sie verglich die aktuelle KI-Expansion mit der breiten Einführung des Internets in den 1990er-Jahren.

Ihr Vergleich konzentrierte sich auf Unsicherheit, nicht auf Nostalgie. Internetverbindungen schufen wertvolle Dienste, setzten Systeme jedoch zugleich Angriffen und Fehlermodi aus, die viele Organisationen nicht vorhergesehen hatten. KI fügt nun ähnliche Unsicherheit in Systeme ein, die Inhalte erzeugen, Entscheidungen empfehlen und mitunter Maßnahmen ergreifen.

Laut dem Veranstaltungsprogramm behandelte die Diskussion Geschwindigkeit gegenüber Sicherheit, Innovation gegenüber Regulierung sowie Risiken in Teams aus Menschen und KI. Außerdem wurde untersucht, wie sich Prioritäten von Regierung und Privatwirtschaft überschneiden.

Sandias anschließender Bericht zum Panel beschrieb drei geschäftliche Folgen von KI-Bedrohungen: Verlust geistigen Eigentums, Betriebsunterbrechungen und regulatorische Risiken. Diese Ergebnisse verleihen technischen Schwachstellen eine direkte finanzielle und strategische Bedeutung.

Thayer, Leiterin von Sandias Abteilung Secure Algorithms, erklärte, dass sich die Sicherheitsaufmerksamkeit über Hardware und herkömmliche Software hinausbewegt. Forschende untersuchen zunehmend die Algorithmen selbst und das Verhalten, das aus ihrer Nutzung entsteht.

Diese Veränderung ist wichtig, weil eine KI-Anwendung wie vorgesehen funktionieren und dennoch unsichere Ergebnisse erzeugen kann. Ein Modell könnte sensible Zusammenhänge offenlegen, eine bösartige Anweisung akzeptieren oder außerhalb seiner ursprünglichen Testbedingungen unvorhersehbar reagieren.

Die Anwendung kann auch ohne Angriff ausfallen. Mehrdeutige Anweisungen, unbekannte Daten, schwache Bewertungskriterien oder ein unangemessenes Maß an Autonomie können gravierende Fehler verursachen. Herkömmliche Schwachstellenscans werden nicht jedes dieser Probleme erkennen.

Sandias Ansatz umfasst Red Teaming, also das aktive Prüfen eines Systems auf Schwachstellen, bevor ein Angreifer sie findet. Die Forschenden bewerten zudem Zuverlässigkeit, Sicherheit und Leistungsgrenzen unter definierten Bedingungen.

Das Testen von Grenzen unterscheidet sich von der Meldung eines einzelnen günstigen Genauigkeitswerts. Eine nützliche Bewertung fragt, ab wann sich das System nicht mehr akzeptabel verhält, welche Eingaben diese Veränderung auslösen und ob das Monitoring sie erkennen kann.

Das Panel listete daher nicht nur KI-Risiken auf. Es verband die Risikoidentifizierung mit wiederholbaren Tests, Gegenmaßnahmen und sicherem Design. Diese Abfolge macht aus einer abstrakten Warnung eine Ingenieursdisziplin.

Nichts im öffentlichen Bericht deutet darauf hin, dass Sandia die teilnehmenden Startups zertifiziert oder ihre Produkte bewertet hat. Die Sitzung war ein Austausch über Ansätze und Bedenken, kein Audit.

Diese Unterscheidung ist wichtig. Ein zweistündiges Panel kann nicht feststellen, ob ein bestimmtes KI-System sicher ist. Es kann jedoch die Fragen verändern, die Gründer stellen, bevor sie eines ausliefern.

Die schnelle KI-Einführung hinterlässt bei Startups eine Absicherungslücke

Startups stehen unter Druck, weil ihre Release-Zyklen kürzer sind als die Zeit, die nötig ist, um jedes Modellverhalten zu verstehen.

Ein junges Unternehmen kann ein gehostetes Modell in ein Produkt integrieren, ohne dieses Modell selbst zu trainieren. Es kann Kundendokumente, interne Aufzeichnungen oder externe Tools innerhalb eines kurzen Entwicklungszyklus über Programmierschnittstellen anbinden.

Die daraus entstehende Anwendung übernimmt mehrere Ebenen der Unsicherheit. Ihr Verhalten hängt vom Basismodell, Systemanweisungen, abgerufenen Daten, Softwareintegrationen, Berechtigungen und Nutzereingaben ab.

Eine Änderung auf jeder Ebene kann das System verändern. Ein Modellanbieter kann das Verhalten aktualisieren, ein Retrieval-Index kann neue Dokumente aufnehmen oder ein Kunde kann eine neue Integration aktivieren.

Diese Änderungen schaffen das, was Teams häufig als Absicherungslücke bezeichnen. Das Produkt entwickelt sich schneller als die Nachweise des Unternehmens zu Sicherheit, Zuverlässigkeit und akzeptablem Verhalten.

Die Lücke wird ernster, wenn ein KI-System handeln kann. Agentische Workflows sind Anwendungen, die einem Modell erlauben, Schritte zu planen und Tools mit begrenztem menschlichem Eingreifen aufzurufen. Sie können Nachrichten versenden, Datensätze bearbeiten, Code ausführen oder Geschäftsprozesse auslösen.

Jede zusätzliche Berechtigung erhöht die Auswirkungen einer fehlerhaften oder manipulierten Antwort. Eine schwache Antwort in einem Chatfenster ist unerquicklich. Dieselbe Antwort, die an ein Ausführungstool weitergegeben wird, kann Daten verändern oder Informationen offenlegen.

Prompt Injection verdeutlicht den Unterschied. Ein Angreifer platziert Anweisungen in Nutzereingaben oder externen Inhalten und hofft, dass das Modell ihnen statt den vorgesehenen Regeln des Entwicklers folgt.

Die aktuelle von OWASP gepflegte LLM-Risikoliste benennt Prompt Injection als wesentliche Anwendungsschwachstelle. Sie behandelt außerdem die Offenlegung sensibler Informationen, Schwachstellen in der Lieferkette, unsachgemäße Verarbeitung von Ausgaben und übermäßige Handlungsbefugnis.

Diese Risiken überschreiten Organisationsgrenzen. Ein Modellanbieter sichert seine Plattform ab, während ein Anwendungsentwickler Prompts, Retrieval, Tools und Zugriffsregeln kontrolliert. Ein Kunde wiederum kontrolliert Nutzerverhalten, angebundene Daten und lokale Konfigurationen.

Kein einzelner Beteiligter sieht das vollständige System. Das macht es leicht, Verantwortung zu verwässern, bis ein Vorfall eintritt.

Sandias Panel legte die Verantwortung wieder bei der einsetzenden Organisation. Staatliche Stellen können Forschung, Frameworks und unabhängige Bewertungen beitragen. Unternehmen tragen jedoch weiterhin die Risiken, die durch ihre Produkte und Betriebsentscheidungen entstehen.

Diese Verantwortung verlangt von einem Startup nicht, ein nationales Labor nachzubilden. Sie verlangt, dass das Unternehmen definiert, was sicheres Verhalten für seinen eigenen Anwendungsfall bedeutet.

Ein Assistent für klinische Forschung und ein Generator für Marketingtexte sollten nicht dieselben Akzeptanzkriterien teilen. Der erste verarbeitet Informationen mit höheren Folgen und erfordert strengere Nachweise, Zugriffskontrollen und Überprüfungen.

Startups müssen außerdem Modellqualität von Systemsicherheit trennen. Ein Modell kann bei Routineaufgaben gut abschneiden und unter adversarischen Eingaben dennoch versagen. Es kann korrekt antworten und zugleich Informationen offenlegen, die ein Nutzer nicht erhalten sollte.

Auch das Gegenteil ist möglich. Eine Anwendung kann häufige Angriffe verhindern und dennoch unzuverlässige Empfehlungen erzeugen. Sicherheit und Nutzen überschneiden sich, doch das eine garantiert nicht das andere.

Deshalb liefert ein einzelner Benchmark-Wert nur schwache Absicherung. Teams benötigen Tests, die an beabsichtigte Aufgaben, vorhersehbaren Missbrauch, Zugriffsgrenzen und reale Einsatzbedingungen gebunden sind.

Sie benötigen außerdem Aufzeichnungen. Eine durchsuchbare Wissensdatenbank kann Modellversionen, Bewertungsergebnisse, Vorfälle und akzeptierte Risiken teamübergreifend in Entwicklung und Produktmanagement bewahren.

Dokumentation ist keine nach der Entwicklung hinzugefügte Bürokratie. Sie ermöglicht einem Team, festzustellen, wann sich Verhalten verändert hat und ob eine frühere Gegenmaßnahme noch funktioniert.

Der Druck ist sowohl unmittelbar als auch langfristig. Unternehmenskunden fragen Anbieter bereits nach Datenverarbeitung, Modellanbietern, Zugriffskontrollen und Reaktion auf Vorfälle. Künftige Regeln können diese Nachweise formaler gestalten.

Ein Startup, das diese Fragen nicht beantworten kann, kann Aufträge verlieren, bevor es eine technische Sicherheitsverletzung erleidet. In diesem Sinne wird vertrauenswürdige KI Teil der Produktglaubwürdigkeit.

Der zentrale Zielkonflikt lautet Geschwindigkeit gegenüber Nachweisen

Sandias Botschaft verlangt keine langsamere Innovation, aber stärkere Nachweise, bevor KI größere Befugnisse erhält.

Gründer betrachten Geschwindigkeit gewöhnlich als Überlebensvoraussetzung. Schnelles Ausliefern erzeugt Nutzerfeedback, belegt Nachfrage und hilft einem kleinen Unternehmen, mit Organisationen mit größeren Budgets zu konkurrieren.

Sicherheitsteams betrachten dieselbe Veröffentlichung aus einer anderen Perspektive. Sie wollen Bedrohungsmodelle, Tests, Logs, Zugriffsgrenzen und einen Reaktionsplan, bevor ein System sensible Daten erreicht.

Beide Positionen enthalten berechtigte Anliegen. Jede experimentelle Funktion zu verzögern, bis sie Standards für Anwendungen mit hohen Folgen erfüllt, würde viele Startups belasten. Ein autonomes System ohne aussagekräftige Tests bereitzustellen, würde Kunden Risiken aussetzen, die sie nicht erkennen können.

Die praktische Antwort lautet verhältnismäßige Absicherung. Ein Schreibassistent mit geringer Auswirkung benötigt andere Kontrollen als ein Agent, der Finanz-, Labor- oder Produktionsdaten ändern kann.

Verhältnismäßige Absicherung beginnt mit einem definierten Kontext. Das Team dokumentiert, wer das System nutzen wird, auf welche Daten es zugreifen kann, welche Aktionen es ausführen kann und welche Fehler unzulässig sind.

Das Unternehmen bildet anschließend glaubwürdige Bedrohungen und gewöhnliche Fehlermodi ab. Zu den Bedrohungen zählen bösartige Prompts, manipulierte Daten, gestohlene Zugangsdaten, kompromittierte Abhängigkeiten und Versuche, private Kontexte zu extrahieren.

Gewöhnliche Fehler verdienen dieselbe Aufmerksamkeit. Ein Modell kann eine Anfrage missverstehen, eine Quelle erfinden, das falsche Tool auswählen oder weiterarbeiten, nachdem seine Annahmen ungültig geworden sind.

Als Nächstes folgt die Messung. Teams erstellen Bewertungssätze aus realistischen Aufgaben, bekannten Grenzfällen und adversarischen Beispielen. Sie dokumentieren die erwarteten Ergebnisse, bevor sie die Tests durchführen.

Ein nützlicher Test hat eine beobachtbare Bestehensbedingung. „Das Modell sollte sicher sein“ ist nicht messbar. „Der Assistent darf keine Datensätze außerhalb des Arbeitsbereichs des authentifizierten Nutzers zurückgeben“ ist spezifisch genug, um getestet zu werden.

Sandias Red-Team-Ansatz ergänzt die Perspektive eines Angreifers. Tester suchen nach unerwarteten Wegen durch die gesamte Anwendung, einschließlich ihrer Anweisungen, angebundenen Daten, Schnittstellen und Tools.

Die breitere Gemeinschaft der Laboratorien des Department of Energy hat ähnliche Arbeit beschrieben. Ein laborübergreifender KI-Sicherheitsbericht besagt, dass statische Benchmarks nicht ausreichen, um Verhalten außerhalb vertrauter Bedingungen vorherzusagen.

Der Bericht benennt zudem Ressourcenbeschränkungen. Umfassende Bewertungen verbrauchen Rechenkapazität, Facharbeit und Zeit. Neue Modelle erscheinen schneller, als Evaluatoren jedes einzelne gründlich beurteilen können.

Diese Einschränkung ist besonders für Start-ups relevant. Kleine Unternehmen können nicht jede mögliche Eingabe testen oder die internen Bewertungen des Anbieters reproduzieren.

Sie können jedoch die Anwendung testen, die sie selbst kontrollieren. Eine gezielte Bewertung sollte die Daten, Tools, Nutzerrollen und Workflows mit den größten Auswirkungen des Unternehmens abdecken.

Auf Tests folgen Gegenmaßnahmen. Ein Team könnte Berechtigungen einschränken, nicht vertrauenswürdige Inhalte isolieren, Ausgaben validieren, menschliche Freigaben verlangen oder begrenzen, welche Tools das Modell aufrufen darf.

Die stärkste Kontrolle reduziert häufig die Folgen eines Fehlers. Wenn ein Assistent nur eine Aktion entwirft, kann ein Mensch sie prüfen. Führt der Assistent diese Aktion direkt aus, benötigt das Unternehmen stärkere Autorisierung und Überwachung.

Menschliche Prüfung ist nicht automatisch wirksam. Prüfer können nachlässig werden, wenn die meisten Ausgaben korrekt erscheinen, insbesondere unter Zeitdruck.

Teams sollten daher die Entscheidungen identifizieren, bei denen eine Prüfung am wichtigsten ist. Sie sollten außerdem genügend Kontext bereitstellen, damit eine Person ein fragwürdiges Ergebnis erkennen kann.

Monitoring schließt den Kreislauf. Protokolle sollten zeigen, welches Modell, welche Anweisungen, Datenquellen und Tools zu einer wichtigen Ausgabe beigetragen haben. Ohne diesen Kontext wird die Untersuchung von Vorfällen zum Rätselraten.

Keiner dieser Schritte schafft dauerhafte Sicherheit. Modellverhalten, Anwendungscode, Daten und Angreifer verändern sich fortlaufend. Tests müssen während der gesamten Lebensdauer des Systems weitergeführt werden.

Hier wird der Konflikt zwischen Geschwindigkeit und Evidenz beherrschbar. Ein Start-up kann sich in einer eingeschränkten Umgebung schnell bewegen und Befugnisse dann ausweiten, wenn die Evidenz besser wird.

Es kann mit internen Nutzern, synthetischen Daten und schreibgeschützten Tools beginnen. Spätere Stufen können Kundendaten oder begrenzte Aktionen ergänzen, nachdem das System explizite Schwellenwerte erfüllt.

Dieser Weg behandelt Sicherheit als Teil der Produktentwicklung. Er vermeidet die falsche Wahl zwischen dem Blockieren jedes Experiments und der Freigabe jeder Fähigkeit ohne Grenzen.

Frameworks helfen, aber sie zertifizieren kein Produkt

Bestehende Frameworks strukturieren die Arbeit an KI-Risiken, können jedoch nicht bestimmen, ob die Anwendung eines einzelnen Start-ups sicher genug ist.

Das NIST AI Risk Management Framework gibt Organisationen vier miteinander verbundene Funktionen vor: Govern, Map, Measure und Manage. Governance gilt über die anderen Funktionen hinweg, anstatt nur am Ende aufzutauchen.

Das Framework ist freiwillig und für eine breite Anwendung konzipiert. Sein KI-Risiko-Framework hilft Organisationen, Vertrauenswürdigkeit in Design, Entwicklung, Bereitstellung, Nutzung und Bewertung von KI einzubeziehen.

Für ein Start-up bedeutet „Govern“, Entscheidungsbefugnisse zuzuweisen und die Risikotoleranz zu dokumentieren. Jemand muss entscheiden, welche Anwendungsfälle erlaubt sind und welche Evidenz eine Freigabe stützt.

„Map“ bedeutet, den Kontext zu verstehen. Teams identifizieren Nutzer, betroffene Parteien, Daten, Abhängigkeiten, erwartete Vorteile und mögliche Schäden.

„Measure“ umfasst Tests und Analysen. Dazu gehören Leistungsbewertung, Sicherheitstests, die Bewertung von Unsicherheit und Monitoring anhand definierter Kriterien.

„Manage“ übersetzt Erkenntnisse in Prioritäten und Maßnahmen. Ein Unternehmen akzeptiert, reduziert, überträgt oder vermeidet Risiken auf Grundlage ihrer Schwere und verfügbarer Kontrollen.

NIST veröffentlichte im Juli 2024 außerdem ein Profil für generative KI. Das Profil passt das umfassendere Framework an Risiken an, die generative Systeme einführen oder verstärken.

Diese Ressourcen liefern Vokabular und Struktur. Sie prüfen kein Produkt, garantieren keine Compliance und zertifizieren nicht das Verhalten eines Modells.

Sandias Position wirkt technisch anspruchsvoller als die bloße Übernahme der Sprache von Frameworks. Seine Forscher betonten Red Teaming, Benchmarking, sicheres Design und das Verständnis von Leistungsgrenzen.

Diese Betonung ist wichtig, weil Governance-Dokumente von der Software entkoppelt werden können. Ein Risikoregister könnte angeben, Prompt Injection sei adressiert, während das bereitgestellte Retrieval-System weiterhin nicht vertrauenswürdige Anweisungen an ein Modell weitergibt.

Evidenz sollte jedes identifizierte Risiko mit einer Kontrolle und einem Test verknüpfen. Das Unternehmen sollte zudem wissen, welche Risiken nach der Risikominderung verbleiben.

Eine unabhängige Bewertung kann diesen Prozess stärken. Sandia beschrieb staatlich finanzierte Forschungs- und Entwicklungszentren als Quellen unvoreingenommener technischer Analysen.

Der öffentliche Bericht zum Panel kündigte jedoch keinen allgemeinen Sandia-Zertifizierungsdienst für Start-ups an. Er bekundete Interesse daran, herauszufinden, wo die Industrie Anforderungen an Absicherung erfüllen kann und wo nationale Laboratorien Lücken schließen können.

Das ist eine Einladung zur Zusammenarbeit, kein Beweis für einen fertigen Weg. Zugang, Umfang, Umgang mit geistigem Eigentum und Beschaffungsvereinbarungen werden bestimmen, ob einzelne Start-ups teilnehmen können.

Sandia betreibt bereits Programme, die Laboratorien, Universitäten und kleinere Unternehmen verbinden. Sein RAIICE-Programm zielt darauf ab, offene Datensätze und technische Roadmaps für KI- und Machine-Learning-Arbeit mit Bezug zu resilienter Energie bereitzustellen.

RAIICE zeigt ein Partnerschaftsmodell, sollte jedoch nicht mit dem Sicherheits-Panel im Juli verwechselt werden. Das Panel kündigte nicht an, dass Teilnehmer diesem Programm beigetreten seien.

Diese Unterscheidung legt den skeptischen Blickwinkel in Sandias Botschaft offen. Technische Expertise ist vorhanden, und Gründer brauchen sie eindeutig. Unklar bleibt, wie breit diese Expertise kommerzielle Teams erreichen kann.

Nationale Laboratorien arbeiten unter spezifischen Aufträgen, Vertragsregeln und Ressourcenbeschränkungen. Start-ups arbeiten unter engen Zeitplänen und benötigen möglicherweise innerhalb weniger Tage Antworten.

Ein Kooperationsmodell muss diese unterschiedlichen Rhythmen überbrücken. Es muss Forschungsmethoden in Tests übersetzen, die kleine Teams durchführen, wiederholen und Kunden erklären können.

Regulierung schafft eine weitere Unsicherheit. Berichten zufolge befürworteten Panelteilnehmer klare Regeln, die der Industrie erlauben, KI-Risiken verantwortungsvoll zu tragen, doch die Veranstaltung brachte keinen vorgeschlagenen Rechtsstandard hervor.

Regeln können Erwartungen klären, sie können jedoch auch veralten, wenn sich Modelle und Anwendungen ändern. Vorgeschriebene Anforderungen können das Abarbeiten von Checklisten belohnen, ohne reales Verhalten zu verbessern.

Ergebnisorientierte Regeln schaffen ein anderes Problem. Sie können Unternehmen sagen, welches Ergebnis sie erreichen sollen, ohne erschwingliche Wege aufzuzeigen, dies nachzuweisen.

Das beste kurzfristige Signal wird praktische Evidenz sein. Öffentliche Testmethoden, wiederverwendbare Evaluierungstools, zugängliche Datensätze und dokumentierte Kooperationen mit Start-ups würden zeigen, dass die Partnerschaftsvision operativ wird.

Bis dahin sollten Unternehmen nicht behaupten, dass die Übernahme eines Frameworks Sicherheit beweise. Sie sollten die eingesetzten Kontrollen, die durchgeführten Tests und die weiterhin beobachteten Einschränkungen beschreiben.

Worauf Gründer und Käufer als Nächstes achten sollten

Der nächste Test besteht darin, ob Sandias Risikosprache zu wiederholbaren Praktiken, glaubwürdigen Partnerschaften und klareren Markterwartungen führt.

Das erste Signal ist ein konkreter Kooperationsweg für kleine Unternehmen. Sandia erklärte, es wolle identifizieren, wo die Industrie Anforderungen an Absicherung erfüllen kann und wo nationale Laboratorien Lücken schließen können.

Ein nützlicher Weg würde teilnahmeberechtigte Projekte, verfügbare Expertise, Anforderungen an die Datenverarbeitung, erwartete Ergebnisse und Zeitpläne für die Zusammenarbeit definieren. Öffentliche Fallstudien würden die Bewertung des Modells erleichtern.

Wenn diese Details erscheinen, werden sie die zentrale Aussage des Panels stärken. Sie würden zeigen, dass Methoden nationaler Laboratorien über die Diskussion hinausgehen und die kommerzielle Entwicklung unterstützen können.

Wenn kein solcher Weg entsteht, bleibt die Veranstaltung wertvolle Öffentlichkeitsarbeit, bietet aber nur begrenzte operative Hilfe. Start-ups müssten weiterhin eigene Testprogramme zusammenstellen oder externe Spezialisten beauftragen.

Das zweite Signal ist technische Validierung, die an reale Anwendungen gebunden ist. Gründer sollten auf veröffentlichte Bewertungen achten, die Prompt Injection, Datenlecks, Modellmanipulation, unsichere Tool-Nutzung und Verhalten außerhalb normaler Testbedingungen abdecken.

Die nützlichste Arbeit wird Fehlerbedingungen und Restrisiken berichten, nicht nur günstige Bewertungen. Sie sollte erklären, was sich nach den Tests verändert hat und ob die Risikominderung einen weiteren Angriffszyklus überstanden hat.

Solche Evidenz würde die Argumentation stärken, dass vertrauenswürdige KI einen Wettbewerbsvorteil schafft. Käufer können Anbieter mit größerem Vertrauen vergleichen, wenn Unternehmen wiederholbare Ergebnisse bereitstellen.

Ein Mangel an Evidenz würde dieses Argument schwächen. Sicherheitssprache allein unterscheidet ein Produkt nicht von einem anderen, besonders wenn jeder Anbieter ähnliche Versprechen macht.

Das dritte Signal ist eine Bewegung von breiten Frameworks hin zu klareren Erwartungen von Kunden und Regulierungsbehörden. NIST überarbeitet AI RMF 1.0 und entwickelt zusätzliche Profile für Cybersicherheit und kritische Infrastruktur.

Gründer sollten verfolgen, ob Unternehmensfragebögen, Beschaffungsanforderungen, Versicherungsprüfungen und sektorale Regeln beginnen, ähnliche Evidenz zu verlangen. Eine Annäherung würde die Unsicherheit darüber verringern, welche Kontrollen frühe Investitionen verdienen.

Fragmentierung würde eine größere Belastung schaffen. Ein Start-up könnte von jedem Kunden, jeder Regulierungsbehörde und jedem Partner mit unterschiedlichen Evaluierungsformaten konfrontiert werden.

Käufer spielen bei der Gestaltung dieses Ergebnisses eine Rolle. Sie sollten Anbieter fragen, welche Modelle und Datenquellen einen Workflow unterstützen, welche Aktionen das System ausführen kann und wie der Anbieter Zugriffsgrenzen testet.

Sie sollten auch fragen, was nach einem Modell-Update geschieht. Eine frühere Bewertung bietet nur begrenzten Schutz, wenn ein Anbieter das Verhalten ändert oder die Anwendung neue Tools erhält.

Entwickler sollten jede zusätzliche Berechtigung als neue Sicherheitsentscheidung behandeln. Die Anbindung eines Assistenten an E-Mail, Quellcode, Kundendaten oder Labordaten verändert die Folgen eines Fehlers.

Wissensarbeiter sollten diese Grenzen ebenfalls verstehen. Sie benötigen klare Signale darüber, welche Informationen in ein KI-System eingegeben werden können und welche Ausgaben eine unabhängige Prüfung erfordern.

Sandias Panel hat diese Fragen nicht geklärt. Es hat es für Start-ups schwieriger gemacht, sie aufzuschieben.

Die dauerhafteste Lehre lautet, dass KI-Sicherheit das gesamte Betriebssystem rund um ein Modell umfasst. Daten, Anweisungen, Software, Berechtigungen, Nutzer und Monitoring beeinflussen alle das Ergebnis.

Diese Lehre verdeutlicht auch, was Gründer jetzt tun sollten. Definieren Sie das System, priorisieren Sie seine folgenreichsten Fehler, testen Sie diese Fehler, reduzieren Sie Berechtigungen und bewahren Sie Evidenz auf.

Fragen Sie dann, ob jede neue Fähigkeit die Befugnis verdient, die sie erhält. Eine überzeugende Demo ist kein Absicherungsnachweis, und der Ruf eines Anbieters ist kein Ersatz für Anwendungstests.

Sandias Leitlinien zur KI-Sicherheit werden am wichtigsten sein, wenn Unternehmen diese Disziplin in routinemäßige Produktarbeit umsetzen. Gründer sollten damit beginnen, einen folgenreichen Workflow auszuwählen und dessen Risiken, Kontrollen, Tests und ungelöste Grenzen zu dokumentieren.