Sicherheit

Was dieser Abschnitt behandelt

Dieser Abschnitt ist die ausführliche Version der kurzen Übersicht unter ai.artfical.com/security. Diese Seite ist absichtlich kurz gehalten. Die Arbeit dahinter ist es nicht. Alles, was dort in ein, zwei Sätzen zusammengefasst wird, hat hier eine vollständige Seite. Es gibt sieben Bewertungskategorien, gegen die wir jedes Modell vor dem Release testen. Es gibt eine Seite darüber, wie Red-Teaming und die Release-Checkliste in der Praxis tatsächlich funktionieren. Es gibt eine Seite darüber, wie das Produkt selbst gebaut ist, sodass ein Versagen einer Schutzmaßnahme im Modell nicht das Einzige ist, was zwischen einer schlechten Anfrage und einem schlechten Ergebnis steht. Und es gibt eine modellweise Aufschlüsselung dessen, was sich zwischen tAI 4.1 und tAI 4.2 geändert hat und warum. Wenn Sie nur eine Seite aus diesem Abschnitt lesen, ist diese Übersichtsseite so gestaltet, dass sie ausreicht, um zu wissen, wo Sie für alles Speziellere weiterlesen sollten.

Nichts von dem, was folgt, ist geschrieben, um für sich genommen beruhigend zu wirken. Das ist eine bewusste redaktionelle Entscheidung, kein Versehen. Wo etwas ungelöst ist, sagen wir das auf der betreffenden Seite. Wo eine Bewertungskategorie eine bekannte Lücke hat, beschreiben wir die Lücke, statt sie zu beschönigen. Wo ein Stück Methodik von außen tatsächlich schwerer zu überprüfen ist als andere, sagen wir auch das. Ein Sicherheitsabschnitt, der nur je gute Nachrichten meldet, ist leicht zu schreiben und schwer zu vertrauen. Uns ist es lieber, dass diesem Abschnitt vertraut wird, als dass er schmeichelt. Mehrere Seiten in diesem Abschnitt beschreiben einen Prüfpunkt, der gebaut, evaluiert, für unzureichend befunden und verworfen wurde, bevor er je einen echten Nutzer erreichte, und wir halten diese Art von Detail für aussagekräftiger als eine polierte Zusammenfassung, die nur die letztlich ausgelieferte Version zeigt.

Die Struktur mit den sieben Kategorien, die sich durch diesen gesamten Abschnitt zieht, ist nicht auf einen Schlag entstanden. Frühere Versionen von tAI wurden gegen ein kleineres, weniger formales Set an Anliegen bewertet. Die heutige Struktur ist das Ergebnis davon, echte Lücken in diesem früheren, einfacheren Ansatz gefunden zu haben. Sicherheit bei der Tool-Nutzung war früher Teil der allgemeinen Gesprächssicherheit, heute ist sie es nicht mehr. Missbrauch in türkischer Sprache war früher eine Stichprobenprüfung, heute ist es ein vollständiger paralleler Bereich. Beide Änderungen beruhen auf Erkenntnissen, nicht auf einer Neugestaltung um ihrer selbst willen. Wir erwarten, dass sich diese Struktur weiter entwickelt, während wir weitere Lücken finden. Wenn das passiert, wird die Änderung und der Grund dafür hier dokumentiert, nicht stillschweigend in eine bestehende Kategorie eingegliedert.

Wie er aufgebaut ist

Die Seiten in diesem Abschnitt sind in fünf Teile gegliedert. Die Gliederung soll dem entsprechen, wie jemand ihn tatsächlich lesen möchte, nicht wie die Arbeit intern zufällig organisiert ist. Die erste Gruppe sind die Bewertungskategorien, und sie kommt einer festen Referenz in diesem Abschnitt am nächsten. Es gibt sieben Seiten, eine pro Kategorie, jede behandelt, was die Kategorie bedeutet, wie sie getestet wird und wie die aktuellen Ergebnisse aussehen. Die zweite Gruppe ist, wie wir evaluieren, und sie tritt einen Schritt zurück von jeder einzelnen Kategorie. Sie behandelt die Red-Teaming-Methodik, die Release-Checkliste, die eine Version durchlaufen muss, bevor sie ausgeliefert wird, was passiert, wenn im Nachhinein etwas gefunden wird, und das laufende Produktions-Monitoring, das nicht einfach aufhört, nur weil eine Version die Tests vor dem Release bereits bestanden hat.

Die dritte Gruppe wechselt vom Modell selbst zum Produkt, das darum herum gebaut ist. Das eigene gute Urteilsvermögen eines Modells ist eine Schicht der Sicherheit. Bewusst ist es nicht die einzige. Die vier Seiten in dieser Gruppe, Sandboxing, Connector-Schutzmaßnahmen, Datenverarbeitung und Infrastruktur, beschreiben Schutzmaßnahmen, die unabhängig davon greifen, ob das Modell in einem bestimmten Moment richtig urteilt. Die vierte Gruppe sind modellspezifische Details. Sie behandelt, was für tAI 4.2 und was für tAI 4.1 spezifisch ist, da eine nur abstrakt beschriebene Sicherheitslage weniger nützlich ist als eine, die an eine konkrete, aktuell laufende Version gebunden ist. Die fünfte Gruppe ist Referenzmaterial, gedacht zum Nachschlagen statt zum Durchlesen von vorn bis hinten: wie man ein Problem meldet, Antworten auf die am häufigsten gestellten Fragen zu diesem Abschnitt und ein Glossar der darin verwendeten Begriffe.

Für wen dieser Abschnitt gedacht ist

Dieser Abschnitt ist gleichzeitig für mehrere verschiedene Leser geschrieben. Es lohnt sich, das explizit zu machen, wer sie sind. Ein Sicherheitsteam, das bewertet, ob tAI Zugriff auf interne Systeme erhalten soll, möchte ein bestimmtes Detailniveau. Ein Forscher, der eine konkrete Behauptung überprüft, möchte ein anderes Niveau. Ein neugieriger Nutzer, der einfach wissen möchte, was tatsächlich passiert, wenn tAI in seinem Namen eine Aktion ausführt, möchte wieder etwas anderes. Wer eine formale Sicherheitsprüfung als Lieferant durchführt, wird wahrscheinlich die Seite zum Release-Prozess, die Infrastrukturseite und die modellspezifischen System Cards wollen, ungefähr in dieser Reihenfolge. Wem eine schlichte Antwort auf „Kann tAI eine E-Mail versenden, ohne dass ich das genehmige“ reicht, ist mit der FAQ-Seite besser bedient als damit, zuerst die Methodik des Release-Prozesses zu lesen.

Wir haben versucht, jede Seite so zu schreiben, dass sie für sich allein steht. Ein Leser, der über ein Suchergebnis oder einen direkten Link hereinkommt, sollte nicht zuerst den Rest des Abschnitts gelesen haben müssen. Das bedeutet, manche Ideen werden über verschiedene Seiten hinweg mehr als einmal wiederholt. Die Trennung zwischen Gesprächssicherheit und Sicherheit bei der Tool-Nutzung ist ein Beispiel dafür. Die Vorstellung, dass eine Schutzmaßnahme auf Modellebene und eine auf Produktebene unabhängige Schichten sind, ist ein weiteres. Beides wird auf mehr als einer Seite erneut erklärt, statt nur beiläufig referenziert und unerklärt gelassen zu werden. Wenn sich diese Wiederholung schwerer anfühlt, als sie sein müsste, während Sie den Abschnitt von vorn bis hinten lesen, ist das ein bewusster Kompromiss zugunsten des häufigeren Falls: eines Lesers, der über einen Link von woanders auf einer einzelnen Seite landet und braucht, dass sie für sich allein verständlich ist.

Was dieser Abschnitt nicht behandelt

Dieser Abschnitt behandelt die technische Sicherheitslage: was bewertet wird, wie es getestet wird und welche Schutzmaßnahmen sie tragen. Er ist bewusst nicht der Ort für rechtliche und richtlinienbezogene Dokumente, selbst dort, wo sich die beiden Themen in der Vorstellung eines Lesers überschneiden. Die Datenschutzerklärung, die Nutzungsbedingungen, die Nutzungsrichtlinie und die Cookie-Richtlinie befinden sich unter ai.artfical.com/legal, und sie sind die maßgebliche Quelle für alles zur Rechtsgrundlage, zu Betroffenenrechten oder zu vertraglichen Verpflichtungen. Wo dieser Abschnitt auf etwas wie Datenaufbewahrung oder -löschung verweist, gibt er die allgemeinverständliche, praktische Version wieder. Die rechtlichen Seiten sind der Ort, an dem der verbindliche Wortlaut tatsächlich steht, und wo die beiden sich scheinbar widersprechen, gilt die rechtliche Seite. Wir verlinken direkt auf die jeweilige rechtliche Seite, wo immer dieser Abschnitt etwas mit einer rechtlichen Dimension berührt, statt es dem Leser zu überlassen, sie selbst zu suchen.

Dieser Abschnitt ist außerdem nicht die vollständige, Tool-für-Tool-Referenz für einen einzelnen Connector. Gmail, Notion, GitHub und Linear haben jeweils eigene Dokumentation, die jedes verfügbare Tool und dessen genauen Berechtigungsumfang behandelt. Die Seite Connector-Schutzmaßnahmen in diesem Abschnitt behandelt das allen vier gemeinsame Sicherheitsmuster, nicht die Tool-für-Tool-Details eines einzelnen davon. Ebenso ist dieser Abschnitt kein allgemeines Produkthandbuch. Fragen dazu, wie man ein Feature tatsächlich benutzt, statt wie es sicher gehalten wird, werden besser von der Haupt-tAI-Dokumentation beantwortet als von irgendetwas hier. Diese Grenze klar zu halten ist es, was diesen drei Arten von Dokumentation, Sicherheit, Recht und Produkt, erlaubt, fokussiert und präzise zu bleiben, statt zu versuchen, für alle alles zu sein.