Gemini API zapisuje żądania w nowych projektach: co sprawdzić

Google zmienił domyślne ustawienie, które łatwo przeoczyć przy zakładaniu projektu. Od 26 października 2026 nowe płatne projekty Gemini API mają włączony zapis obsługiwanych żądań Generate Content API. Dla mnie to powód, żeby do przeglądu analizy dopisać jedno konkretne pytanie: gdzie zostaje kopia danych po otrzymaniu odpowiedzi? Stan dokumentacji w tym artykule: 30 października 2026.

Weźmy analizę komentarzy z ankiety. Wysyłasz teksty do modelu, odbierasz kategorie i zapisujesz tabelę do dalszej pracy w Power BI. Diagram z trzema strzałkami wygląda schludnie. Dodaję do niego miejsca przechowywania żądań, odpowiedzi i plików pomocniczych. Wtedy dopiero widać, co trzeba skonfigurować i kto ma później posprzątać materiały z eksperymentu.

Co zmieniło się 26 października

W oficjalnym changelogu Gemini API Google wskazuje trzy metody: generateContent, streamGenerateContent i batchGenerateContent. Nowe projekty na płatnym poziomie mają zapis domyślnie włączony, czyli store=true. Istniejące projekty zachowują dotychczasowe ustawienie. Zmiana dotyczy domyślnej konfiguracji Generate Content API; Interactions API już wcześniej domyślnie przechowywało żądania.

W praktyce zaczynam przegląd od identyfikatora projektu i daty jego utworzenia. Potem ustalam, który projekt obsługuje dany skrypt lub aplikację. Nie wyciągam wniosku z tego, że notebook nazywa się „testowy”. Do karty przeglądu wpisuję rzeczywisty projekt, używane API oraz wybrane ustawienie. Dzięki temu osoba przejmująca analizę dostaje stan konfiguracji, a nie opowieść o tym, jak kiedyś uruchomiono prototyp.

Porównuję oddzielnie środowisko do ćwiczeń i projekt obsługujący regularne analizy. Ta sama instrukcja dla modelu nie wystarcza mi do uznania ich za równoważne. Spisuję różnice w ustawieniach zapisu oraz w rodzaju wysyłanych danych. Przy przenoszeniu rozwiązania aktualizuję tę listę razem z dokumentacją projektu, zanim do nowego środowiska trafi pierwszy rzeczywisty komentarz klienta.

Ustawienie projektu i parametr żądania

Dokumentacja Logs and datasets opisuje panel Settings w widoku logów Google AI Studio. Wybierasz projekt i ustawiasz logowanie osobno dla Generate Content oraz Interactions. Parametr store w pojedynczym żądaniu ma pierwszeństwo przed ustawieniem projektu. Dla Generate Content obsługa tego parametru w Pythonie wymaga pakietu google-genai w wersji co najmniej 2.33.0.

W wariancie analizy, w którym rezygnujesz z logów Generate Content, otwórz Settings właściwego projektu i wyłącz logowanie tej rodziny API. Następnie przejrzyj konfigurację wywołań pod kątem jawnego store=true. Taki wpis nadpisuje wybór z panelu. To kolejność, którą polecam: najpierw ustalenie wartości domyślnej, później kontrola wyjątków w konkretnych miejscach wywołania.

Poniżej fragment konfiguracji dla argumentu config w pythonowym client.models.generate_content. Pokazuję ustawienie na podstawie dokumentacji, bez uruchamiania wywołania API.

config={"store": False}

Traktuję ten fragment jako element konfiguracji do przeglądu. W opisie zmiany zapisuję, w którym miejscu jest przekazywany i jakiej wersji pakietu dotyczy. Osoba sprawdzająca ma zobaczyć połączenie między decyzją zespołu a konkretnym wywołaniem, zamiast szukać go w całym notebooku. W dużym projekcie zaczynam od listy miejsc korzystających z API i dopiero potem przypisuję im ustawienia.

Przy Interactions zwracam uwagę na dodatkowy skutek: wyłączenie logowania w panelu wyłącza automatyczne przechowywanie i odtwarzanie historii rozmowy, chyba że żądanie jawnie to nadpisze. Dlatego nie zmieniam obu przełączników przy okazji porządkowania jednego skryptu. Najpierw ustalam, które rozwiązanie korzysta z historii po stronie usługi i jakie zachowanie ma zachować po zmianie.

W tym przykładzie analizuję tekst. Dokumentacja wyłącza z obsługi logowania między innymi wejścia zawierające PDF, wideo lub GIF. Brak wpisu w logach takiego wejścia nie jest więc dla mnie potwierdzeniem wyłączenia zapisu w projekcie. Przy przeglądzie dopasowuję rodzaj danych do zakresu opisanego dla konkretnej funkcji, zamiast uznawać pustą tabelę za dowód konfiguracji.

Oddziel logi, udostępnianie i monitoring nadużyć

Google w zasadach logowania i udostępniania rozdziela logi dostępne w projekcie od dobrowolnego przekazania danych do ulepszania modeli. Domyślnie logi płatnych projektów nie służą rozwojowi produktów. Udostępnienie Google zbioru danych otwiera możliwość wykorzystania jego zawartości do ulepszania i trenowania modeli. Te dwie decyzje zapisuję w osobnych polach dokumentacji.

Jest jeszcze odrębny monitoring nadużyć. Google opisuje przechowywanie promptów, kontekstu i odpowiedzi przez 55 dni w tym celu. Z tego powodu store=false odczytuję w jego konkretnym zakresie: steruje opisaną funkcją zapisu żądań. Sam ten parametr nie uzasadnia zdania „nigdzie nie zostaje żadna kopia”.

Dla swojej analizy rysuję więc trzy osobne pola: logi projektu, materiały udostępnione dostawcy i mechanizmy opisane przez dostawcę dla monitoringu nadużyć. Obok dopisuję własny plik wynikowy oraz ewentualne logi aplikacji. Każde pole ma właściciela przeglądu. Dzięki takiemu zapisowi rozmowa o danych dotyczy konkretnych miejsc, zamiast kończyć się ogólnym zapewnieniem, że „wyłączyliśmy historię”.

Retencja logów i osobne życie zbioru danych

Według zasad Google logi domyślnie zostają oznaczone do usunięcia po maksymalnie 55 dniach. W projekcie można wybrać 7, 14, 28 albo 55 dni. Logi zapisane w zbiorze danych, czyli dataset, nie mają ustawionego okresu wygaśnięcia. Przy przeglądzie sprawdzam więc zarówno ustawienie retencji logów, jak i listę utworzonych zbiorów.

Na potrzeby ankiety rozdzielam dwa cele. Diagnoza pojedynczego błędu wymaga obejrzenia konkretnego przypadku. Długotrwałe porównywanie jakości klasyfikacji wymaga utrzymywanego zestawu przykładów. Dla drugiego celu przygotowuję osobny zbiór z opisem, oczekiwaną kategorią i datą przeglądu. Wybieram przypadki celowo, zamiast zamieniać cały strumień komentarzy w archiwum na wszelki wypadek.

W takim zestawie zostawiam treść potrzebną do oceny kategorii. Do ćwiczenia „opóźnienie dostawy” zapisuję wymyślony komentarz o spóźnionej paczce. Pomijam nazwisko, adres i numer rzeczywistego zamówienia. Dla kategorii „brak informacji” dodaję pustą lub niejednoznaczną wypowiedź. Każdy przykład odpowiada na konkretne pytanie o jakość analizy, więc później łatwiej zdecydować, które materiały nadal warto utrzymywać.

Karta przeglądu do skopiowania

Poniższą kartę przygotowałam jako wzorzec dla analizy ankiet. Wypełnij ją razem z osobą utrzymującą wywołania API. Najwięcej uwagi poświęcam polu o wyjątkach: to tam zapisujesz różnicę między ogólną decyzją dla projektu a ustawieniem pojedynczego żądania. W polu dowodu podaj miejsce konfiguracji lub datę przeglądu, bez wklejania klucza API.

PRZEGLĄD ZAPISU DANYCH: KLASYFIKACJA ANKIET
Data i osoba przeglądająca: [...]
Projekt oraz data jego utworzenia: [...]
Używane API: [Generate Content / Interactions]
Poziom rozliczeń projektu: [...]
Logowanie w panelu projektu: [...]
Jawne ustawienia store w wywołaniach i ich uzasadnienie: [...]
Miejsce konfiguracji, wersja SDK: [...]
Dane wysyłane: [treść komentarza; lista pominiętych pól]
Retencja logów projektu: [...]
Zbiory danych: [nazwa, cel, właściciel, data przeglądu]
Udostępnianie zbiorów Google: [ustawienie, osoba odpowiedzialna]
Własne kopie: [wyniki, logi aplikacji, eksporty]
Otwarte zadania: [zmiana, właściciel, termin]

Do karty dołączam przykładowy rekord wejściowy i opis oczekiwanego wyjścia. Na przykład wymyślony tekst „Paczka przyszła po terminie” ma zostać przypisany do kategorii dotyczącej dostawy. Oczekiwany wynik ustala zespół, a potem osobno ocenia odpowiedź modelu. Ustawienia zapisu danych oraz trafność klasyfikacji sprawdzam jako dwa odrębne elementy odbioru.

Co sprawdzić przed kolejną analizą

Zacznij od najnowszego projektu Gemini API w swoim zespole. Ustal, czy obejmuje go zmiana domyślnej konfiguracji, sprawdź panel i przejrzyj jawne parametry wywołań. Następnie uzupełnij kartę o istniejące zbiory i własne kopie wyników. Otrzymasz krótki opis faktycznego przepływu danych, który przyda się przy następnym przenoszeniu analizy między środowiskami.

W szóstym tygodniu kursu łączymy takie decyzje z kontrolą całego procesu. Ustawienia przechowywania opisują jedną jego część; prompt injection w analizie danych dotyczy wpływu treści na zachowanie modelu, a sprawdzanie wyników AI dotyczy poprawności rezultatu. W mojej dokumentacji każdy z tych obszarów ma własny punkt odbioru. Zmiana Google jest dobrym momentem, żeby uzupełnić ten dotyczący zapisu danych.