Zwalczaj zatruwanie danych dzięki tym 5 krokom

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Zatruwanie danych zagraża modelom AI, ponieważ prowadzi do skażenia zbiorów danych, które je zasilają, i może potencjalnie zakłócić wszystko — od chatbotów obsługi klienta po automatyzację marketingu. Przeczytaj o 5 podstawowych zasadach, które pomogą dyrektorom ds. technologii powstrzymać ataki polegające na zatruwaniu danych, zanim się zakorzenią.

Jeśli chodzi o cyberataki, zatruwanie danych idealnie pasuje do swojej nazwy. Już samo to brzmi źle, zwłaszcza że świat biznesu coraz częściej traktuje dane jako cyfrowy odpowiednik metalu szlachetnego.

To trafne skojarzenie, ponieważ zatruwanie danych jest czymś złym. Termin ten odnosi się do nowego zagrożenia dla modeli AI, w ramach którego atakujący – zewnętrzny lub wewnętrzny – celowo uszkadza zbiory danych treningowych, aby wpłynąć na działanie modelu lub jego wyniki. Może to obejmować dodawanie nieprawidłowych danych, manipulowanie istniejącymi danymi lub usuwanie prawidłowych danych.

Jeśli tworzysz produkty SaaS oparte na AI – na przykład aplikację do automatyzacji marketingu zawierającą narzędzie LLM – musisz dokładniej przyjrzeć się temu, jak chronisz swoje modele.

W tym artykule przedstawię porady ekspertów dotyczące najważniejszych strategii ograniczania ryzyka zatruwania danych w zbiorach danych treningowych AI.

Czym jest zatruwanie danych?

Przykład zatruwania danych podany przez NIST, który podobnie jak wiele innych organizacji dbających o bezpieczeństwo wyraźnie zwraca uwagę na to zagrożenie: „[Atakujący mogą wprowadzić] liczne przykłady nieodpowiedniego języka do zapisów rozmów, aby chatbot uznał te przykłady za wystarczająco powszechny sposób wypowiadania się i używał go we własnych interakcjach z klientami”.

Nagle Twój niezawodny chatbot obsługi klienta zaczyna używać wulgaryzmów (lub jeszcze gorszego języka) w rozmowach z prawdziwymi klientami. Prawdopodobnie nie o to nikomu chodzi, gdy mówi o wykorzystywaniu AI do zwiększania produktywności, wydajności czy innowacyjności.

Niezależnie od przypadku użycia CTO wdrażający generatywną AI lub inne aplikacje oparte na AI do swoich produktów SaaS muszą podjąć kroki w celu ochrony danych treningowych przed złośliwym dodawaniem, usuwaniem lub innymi manipulacjami, które mogą wpływać na wszystko – od wydajności modelu, przez doświadczenia użytkownika, po reputację marki i wiele więcej.

Warto również zauważyć, że eksperci zasadniczo zgadzają się, iż w przypadku zatruwania danych najlepszym podejściem jest zapobieganie. Zwykle łatwiej jest nie dopuścić do wystąpienia problemu, niż ograniczać skutki incydentu.

Jak przeciwdziałać zatruwaniu danych – 5 zasad ograniczania ryzyka

1. Poznaj swoje dane.

Wzmacnianie zabezpieczeń przed zatruwaniem danych zaczyna się od zrozumienia, czego właściwie bronisz – nie można chronić czegoś, czego się nie zna.

„Pierwszym krokiem w przeciwdziałaniu zatruwaniu danych w produktach SaaS opartych na AI jest jasne zrozumienie, na jakich danych trenujesz swój model” – mówi Ian Ahl, starszy wiceprezes w P0 Labs, dziale badań nad zagrożeniami dostawcy zabezpieczeń tożsamości Permiso. „Kluczowe jest trenowanie modeli na danych, które można kontrolować”.

Jakiego rodzaju są to dane? Skąd pochodzą? Kto ma do nich dostęp? Jeśli nie masz jasnych odpowiedzi na takie pytania, prawdopodobnie jesteś bardziej narażony na atak polegający na zatruciu danych.

Dogłębne zrozumienie danych treningowych jest również warunkiem skutecznego zarządzania danymi, które omówimy poniżej. Na razie wystarczy powiedzieć, że należy wdrożyć mechanizmy kontroli sposobu, w jaki ludzie, zespoły i procesy wchodzą w interakcję z danymi treningowymi i wykorzystują je.

„Oceniając same dane, można wprowadzić bardziej rygorystyczne mechanizmy kontroli użytkowników, którzy je aktualizują, oraz ustanowić ścisłe zabezpieczenia dotyczące sposobu, w jaki klienci mogą wchodzić w interakcję z tymi danymi” – mówi Ahl . „To połączenie nadzoru nad ludźmi, procesami i danymi”.

2. Zweryfikuj ponownie strategię transformacji danych.

Musisz również rozważyć – i potencjalnie ponownie przemyśleć – sposób, w jaki dane trafiają z pierwotnych źródeł do modeli, określany również jako potok danych.

„Decyzje podejmowane przez CTO w sprawie strategii transformacji danych mają bezpośredni wpływ na bezpieczeństwo ich produktów SaaS opartych na AI, ponieważ wpływają na podatność potoków danych na zatruwanie” – mówi Dave Jenkins, wiceprezes ds. produktu i badań w Iterate.ai.

Jenkins twierdzi, że znajdujemy się w trakcie szerszego przejścia od architektury potoków danych ETL (Extract, Transform, Load) do ELT (Extract, Load, Transform). Istnieje wiele powodów tego trendu, ale jedną z zalet drugiej strategii jest to, że lepiej nadaje się do ograniczania ryzyka problemów takich jak zatruwanie danych.

„Powód jest taki, że gdy transformacje danych AI zachodzą wcześnie, a model jest słabo dostrojony lub zbiory danych są nadal niekompletne, co czasami ma miejsce w przypadku ETL, potencjalnie nieprawidłowe dane zostają utrwalone” – mówi Jenkins. „Błędy i halucynacje mogą się od tego momentu mnożyć, a znalezienie – i skorygowanie – źródła zatrutych danych może być niemal niemożliwe”.

Dlatego Jenkins dodaje, że należy unikać sytuacji, w której różne aplikacje wykonują własne transformacje, zanim dane zostaną przeniesione do jeziora danych. Model ELT odwraca kolejność operacji, że tak powiem, zapewniając większą kontrolę i bardziej ujednolicony proces transformacji.

„Przenosząc zamiast tego wszystkie transformacje do środowiska hurtowni danych, takiego jak Snowflake, dyrektorzy ds. technologii i ich zespoły zyskują większą widoczność i kontrolę podczas rozwijania swoich produktów” — mówi Jenkins.

3. Nadaj priorytet dobrej administracji danymi.

Widoczność i kontrola mają kluczowe znaczenie, ale bez solidnych zasad i administracji w całych potokach danych oraz procesach pozostają niepełne.

„Oczywiście właściwe rozwiązanie tego problemu wymaga również jasnych zasad administracji danymi” — mówi Jenkins. „Dyrektorzy ds. technologii muszą określić, gdzie mogą odbywać się transformacje danych AI. Będą potrzebować ścieżek audytu, struktur walidacji, referencyjnych zbiorów danych do testów porównawczych, a najlepiej także piaskownic transformacji, w których można testować i ponownie testować rozwiązania pod kątem błędów lub halucynacji przed wdrożeniem produkcyjnym”.

Ahl zauważa, że administracja danymi musi obejmować również ludzi, szczególnie w postaci jasnych zasad i zabezpieczeń określających, kto może korzystać z danych treningowych, jakich danych może używać i tak dalej: „Niezależnie od tego, czy jest to użytkownik, czy zespół, osoby mające możliwość dodawania plików do trenowania modelu muszą podlegać ograniczeniom dotyczącym danych, z których mogą korzystać”.

4. Wzmocnij ogólny poziom bezpieczeństwa.

Warto również pamiętać, że AI w ogólności po raz kolejny poszerza powierzchnię ataku wielu organizacji. Zatruwanie danych to tylko jedno z potencjalnych zagrożeń — choć istotne. Wszystkie powyższe działania powinny być prowadzone w ramach szerszej strategii bezpieczeństwa.

Jeśli już zaniedbujesz podstawy bezpieczeństwa, takie jak instalowanie poprawek, higiena haseł, zarządzanie tożsamością i zasada najmniejszych uprawnień, to logiczne jest, że również Twoje modele AI i dane treningowe będą jeszcze bardziej podatne na zagrożenia.

5. Rozważ trening modeli odporny na ataki.

Gdy pojawiają się nowsze zagrożenia, takie jak zatruwanie danych, zwykle opracowywane są nowe strategie i narzędzia służące do obrony przed nimi. Dzieje się tak obecnie w przypadku AI, która przyniosła cały zestaw nowych zagrożeń, nie tylko zatruwanie danych. Są one czasami określane zbiorczym terminem „wroga AI” — oznaczającym złośliwe wykorzystanie uczenia maszynowego i innych rodzajów AI do atakowania innych systemów AI. Zatruwanie danych jest jedną z form wrogiej AI.

Możesz odwrócić sytuację i zastosować trening konfrontacyjny, który zasadniczo uczy modele rozpoznawania potencjalnych wzorców i anomalii mogących wskazywać na zatruwanie danych lub inne formy wrogiej AI, a następnie podejmowania działań w celu ograniczenia ich skutków. 

Trening konfrontacyjny zyskuje na znaczeniu jako kluczowe podejście do bezpieczeństwa AI. Na przykład ten artykuł naukowy przedstawia strukturę ograniczania uprzedzeń, które mogły zostać przejęte podczas gromadzenia danych w środowiskach opieki zdrowotnej, gdzie potencjalne konsekwencje zatruwania danych i innych ataków są szczególnie poważne. Inny artykuł proponuje strukturę treningu konfrontacyjnego przeznaczoną konkretnie do obrony przed zatruwaniem danych.

Co dalej?

Jeśli rozwijasz generatywną AI i inne funkcje wykorzystujące AI w swoim portfolio produktów SaaS, musisz zadbać o to, aby dane treningowe były czyste, dokładne i bezpieczne.

W przeciwnym razie zwiększasz ryzyko zatruwania danych i wystąpienia innych problemów — a zwykle łatwiej jest zapobiegać tym problemom, niż rozwiązywać je po fakcie.

Zanim odejdziesz, zapisz się do naszego newslettera, aby otrzymywać najnowsze informacje!

Kevin Casey
Kevin Casey is an award-winning technology and business writer with deep expertise in digital media. He covers all things IT, with a particular interest in cloud computing, software development, security, careers, leadership, and culture. Kevin's stories have been mentioned in The New York Times, The Wall Street Journal, CIO Journal, and other publications. His InformationWeek.com on ageism in the tech industry, "Are You Too Old For IT?," won an Azbee Award from the American Society of Business Publication Editors (ASBPE), and he's a former Community Choice honoree in the Small Business Influencer Awards. In the corporate world, he's worked for startups and Fortune 500 firms – as well as with their partners and customers – to develop content driven by business goals and customer needs. He can turn almost any subject matter into stories that connect with their intended audience, and has done so for companies like Red Hat, Verizon, New Relic, Puppet Labs, Intuit, American Express, HPE, Dell, and others. Kevin teaches writing at Duke University, where he is a Lecturing Fellow in the nationally recognized Thompson Writing Program.
Follow the author:

You may also like