ChatGPT API w firmie: bezpieczeństwo, RODO i AI Act

OpenAI API można wdrożyć w środowisku korporacyjnym w sposób spełniający wysokie wymagania bezpieczeństwa, ale samo podłączenie API nie czyni aplikacji bezpieczną. Organizacja musi zaprojektować kontrolę dostępu, klasyfikację i minimalizację danych, zarządzanie kluczami, retencję, monitoring, ochronę przed prompt injection oraz zasady korzystania z narzędzi i zewnętrznych źródeł. Równie ważne jest dobranie właściwych ustawień OpenAI dotyczących przechowywania danych, ponieważ różnią się one między endpointami i funkcjami.

W praktyce określenie „API ChatGPT” jest często używane jako potoczna nazwa OpenAI API. Nie należy jednak utożsamiać OpenAI API z ChatGPT Enterprise. Są to różne produkty z odmiennym sposobem wdrażania, zarządzania dostępem i częścią mechanizmów administracyjnych. W tym przewodniku chodzi o budowanie firmowych aplikacji wykorzystujących OpenAI API.

Czy OpenAI API jest bezpieczne dla danych firmowych?

OpenAI deklaruje, że domyślnie nie wykorzystuje danych wejściowych ani wyjściowych klientów API do trenowania swoich modeli. Dotyczy to danych przesyłanych przez API, o ile organizacja nie zdecyduje się jawnie na ich udostępnianie w celu ulepszania modeli.

To jednak tylko jeden element bezpieczeństwa. Brak wykorzystania danych do treningu nie oznacza automatycznie braku jakiegokolwiek przechowywania. Dokumentacja OpenAI rozróżnia między innymi abuse monitoring logs, czyli danymi używanymi do wykrywania nadużyć, oraz application state, czyli stanem aplikacji zapisywanym przez niektóre funkcje API. Domyślnie logi monitorowania nadużyć mogą być przechowywane do 30 dni, natomiast sposób przechowywania application state zależy od konkretnego endpointu.

Dlatego ocena bezpieczeństwa powinna zaczynać się od pytania: jakie dane rzeczywiście wysyłamy, przez który endpoint, z jakimi parametrami i jak długo muszą one istnieć? Dopiero potem można dobrać właściwy model retencji i zabezpieczenia organizacyjne.

OpenAI API a ChatGPT Enterprise — dlaczego nie można ich traktować jako tego samego produktu?

ChatGPT Enterprise jest gotowym środowiskiem pracy dla użytkowników końcowych. OpenAI API służy natomiast do budowania własnych aplikacji, procesów i integracji. W przypadku API to przedsiębiorstwo projektuje między innymi backend, uwierzytelnianie użytkowników, sposób przechowywania danych, logowanie, połączenia z bazami danych, systemami RAG i narzędziami zewnętrznymi.

Nie należy więc zakładać, że funkcja opisana dla ChatGPT Enterprise jest automatycznie dostępna w identycznej postaci w API. Dotyczy to również mechanizmów administracyjnych, retencji i sposobu konfiguracji danych. Oficjalna dokumentacja OpenAI opisuje API Platform i produkty ChatGPT jako odrębne sposoby korzystania z technologii OpenAI.

Co dzieje się z danymi wysłanymi do OpenAI API?

Najważniejsze jest rozdzielenie trzech kwestii: wykorzystania danych do treningu, logów bezpieczeństwa oraz stanu aplikacji.

Obszar	Co oznacza w praktyce
Trening modeli	Dane klientów API nie są domyślnie wykorzystywane do trenowania lub ulepszania modeli.
Abuse monitoring logs	Przy standardowej konfiguracji mogą zawierać fragmenty treści klienta i są domyślnie przechowywane do 30 dni, z zastrzeżeniami opisanymi przez OpenAI.
Application state	Niektóre endpointy lub funkcje zapisują stan potrzebny do realizacji usługi. Retencja zależy od funkcji i sposobu jej użycia.

Przykładowo dokumentacja OpenAI wskazuje, że dla /v1/responses standardowe logi monitorowania nadużyć mają retencję do 30 dni. Jednocześnie Responses API może przechowywać application state przez co najmniej 30 dni, gdy używany jest standardowy sposób zapisu odpowiedzi. Przy włączonym Zero Data Retention parametr store dla obsługiwanych przypadków jest traktowany jako false.

Nie należy na tej podstawie tworzyć jednej uniwersalnej reguły dla całego API. Dokumentacja OpenAI zawiera tabelę retencji dla poszczególnych endpointów. Przykładowo część zasobów takich jak files, vector stores czy inne obiekty utrzymujące stan może mieć odmienny cykl życia niż pojedyncze żądanie tekstowe.

Standardowa retencja, Modified Abuse Monitoring i Zero Data Retention

Organizacje o podwyższonych wymaganiach prywatności powinny rozumieć różnicę między standardową konfiguracją, Modified Abuse Monitoring oraz Zero Data Retention.

Tryb	Co zmienia	Najważniejsze ograniczenie
Standardowa konfiguracja	Obowiązują standardowe zasady logów monitorowania nadużyć oraz retencji application state dla używanych endpointów.	Nie jest to model „zero retention”.
Modified Abuse Monitoring	Dla zatwierdzonych klientów treści klienta są wyłączane z logów monitorowania nadużyć, z wyjątkami opisanymi w dokumentacji.	Wymaga kwalifikacji i zatwierdzenia przez OpenAI.
Zero Data Retention	Wyłącza treści klienta z logów abuse monitoring oraz zmienia zachowanie przechowywania dla obsługiwanych endpointów.	Nie wszystkie endpointy i funkcje są zgodne z ZDR; obowiązują dodatkowe ograniczenia i wymagania.

Modified Abuse Monitoring i ZDR nie są po prostu przełącznikami dostępnymi automatycznie każdemu kontu. Według aktualnej dokumentacji są przeznaczone dla kwalifikujących się klientów i wymagają wcześniejszego zatwierdzenia oraz zaakceptowania dodatkowych wymagań.

W przypadku ZDR szczególnie ważne jest sprawdzenie tabeli obsługiwanych endpointów. OpenAI wyraźnie zaznacza, że funkcje oznaczone jako niekwalifikujące się do Zero Data Retention mogą nadal zapisywać application state nawet wtedy, gdy organizacja używa ZDR.

W 2026 roku OpenAI rozpoczęło również wdrażanie mechanizmu Private Safety Processing dla klientów API korzystających z ZDR. Nie zmienia to zasady, że należy sprawdzić zgodność konkretnego endpointu i spełnić wymagania techniczne właściwe dla wybranej konfiguracji.

Jak powinna wyglądać bezpieczna architektura firmowej aplikacji korzystającej z OpenAI API?

Najbezpieczniejszym wzorcem nie jest połączenie przeglądarki pracownika bezpośrednio z OpenAI API. Pomiędzy użytkownikiem a API powinien znajdować się kontrolowany przez organizację backend lub gateway, który egzekwuje polityki bezpieczeństwa.

Użytkownik uwierzytelnia się w systemie firmowym. Aplikacja zna jego rolę i zakres uprawnień.
Backend klasyfikuje żądanie. Może zablokować niedozwolone typy danych lub usunąć elementy niepotrzebne do wykonania zadania.
Warstwa DLP lub redakcji ogranicza dane wrażliwe. Do modelu trafia minimalny potrzebny zestaw informacji.
Backend wykonuje wywołanie OpenAI API. Poświadczenia znajdują się po stronie serwera, a nie w aplikacji użytkownika.
Odpowiedź jest walidowana. System sprawdza format, dopuszczalną treść i ewentualne instrukcje prowadzące do kolejnych działań.
Działania wysokiego ryzyka wymagają dodatkowej autoryzacji. Model nie powinien samodzielnie otrzymywać nieograniczonego prawa do modyfikowania systemów firmowych.
Logi zapisują to, co potrzebne do audytu. Nie powinny jednak bez potrzeby kopiować pełnych promptów zawierających poufne informacje.

Taki model ogranicza powierzchnię ataku i pozwala organizacji stosować własne mechanizmy IAM, DLP, SIEM, klasyfikację danych oraz procedury reagowania na incydenty.

Nie wysyłaj do modelu danych, których model nie potrzebuje

Jedną z najważniejszych kontroli bezpieczeństwa jest minimalizacja danych przed wywołaniem API. Jeśli model ma sklasyfikować reklamację, prawdopodobnie nie potrzebuje pełnego profilu klienta, numeru dokumentu tożsamości, danych płatniczych ani historii wszystkich transakcji.

W środowisku korporacyjnym warto zdefiniować co najmniej kilka klas informacji, na przykład: publiczne, wewnętrzne, poufne oraz szczególnie chronione. Następnie dla każdego scenariusza AI należy ustalić, które klasy mogą być wysyłane do zewnętrznego API i pod jakimi warunkami.

Jeżeli dane osobowe nie są potrzebne, usuń je lub zastąp identyfikatorem przed wysłaniem żądania. Pseudonimizacja nie zawsze powoduje, że dane przestają być danymi osobowymi, ale może ograniczać konsekwencje potencjalnego ujawnienia.

Takie podejście jest spójne z zasadą minimalizacji danych wynikającą z RODO: dane osobowe powinny być adekwatne, stosowne i ograniczone do tego, co niezbędne dla danego celu. RODO wymaga również uwzględniania ochrony danych już na etapie projektowania rozwiązania.

Klucze API: największy błąd to umieszczenie ich w aplikacji klienckiej

Klucz OpenAI API powinien być traktowany jak sekret infrastrukturalny. Nie powinien znajdować się w JavaScript uruchamianym w przeglądarce, aplikacji mobilnej, publicznym repozytorium ani pliku konfiguracyjnym dołączonym do obrazu kontenera.

OpenAI wprost zaleca, aby nie wdrażać kluczy API w środowiskach klienckich takich jak przeglądarki i aplikacje mobilne. Dla typowych wdrożeń klucz powinien znajdować się po stronie backendu i być pobierany z menedżera sekretów lub bezpiecznie skonfigurowanej zmiennej środowiskowej.

Rotacja i wygasanie kluczy

Klucz produkcyjny nie powinien pozostawać aktywny bezterminowo tylko dlatego, że aplikacja działa. Aktualne zalecenia OpenAI obejmują ustawianie daty wygaśnięcia dla kluczy projektowych oraz regularny proces rotacji: utworzenie nowego klucza, migrację aplikacji, sprawdzenie poprawności działania i dopiero potem unieważnienie starego.

Workload identity zamiast długowiecznego sekretu

Dla obsługiwanych środowisk OpenAI zaleca także workload identity federation. Zamiast stale przechowywanego klucza workload może wymienić tożsamość pochodzącą od zaufanego dostawcy na krótkotrwałe poświadczenie OpenAI. Ogranicza to ryzyko związane z wyciekiem sekretu o długim okresie ważności.

Oddziel development, test i produkcję

Jedna organizacja API nie musi oznaczać jednego wspólnego środowiska dla wszystkich aplikacji. Projekty pozwalają oddzielać workloads, konta usługowe, klucze, uprawnienia, limity i wybrane ustawienia.

Dla systemu korporacyjnego warto co najmniej rozdzielić środowiska developerskie i produkcyjne, a większe organizacje mogą tworzyć osobne projekty także dla aplikacji, jednostek biznesowych lub różnych poziomów wrażliwości danych.

OpenAI udostępnia projektowe konta usługowe oraz klucze API z możliwością określania zakresów i terminu wygaśnięcia. Dokumentacja administracyjna obejmuje również mechanizmy ról i uprawnień.

Zasada praktyczna jest prosta: każdy workload powinien otrzymywać tylko takie uprawnienia, których faktycznie potrzebuje. Nie należy używać jednego klucza o szerokich uprawnieniach we wszystkich aplikacjach przedsiębiorstwa.

Dodatkowe mechanizmy kontroli dostępu do API

W zależności od konfiguracji organizacji i dostępnych funkcji OpenAI Platform oferuje bardziej zaawansowane mechanizmy infrastrukturalne. Aktualna dokumentacja uprawnień obejmuje między innymi zarządzanie IP allowlist, mutual TLS, OIDC oraz zewnętrznymi kluczami EKM. Dokumentacja platformy opisuje również workload identity federation oraz Private Link.

Nie każda organizacja potrzebuje wszystkich tych mechanizmów. Ich dobór powinien wynikać z modelu zagrożeń. Przykładowo workload uruchamiany w kontrolowanej chmurze może korzystać z innego modelu uwierzytelniania niż lokalna aplikacja testowa wykorzystywana przez zespół badawczy.

Data residency: region trzeba zaprojektować, a nie tylko zaznaczyć w polityce

OpenAI udostępnia mechanizmy regionalizacji danych dla API, ale zakres wsparcia zależy od endpointu, modelu i sposobu przetwarzania. Data residency dla API jest konfigurowane na poziomie projektu.

W przypadku regionów innych niż Stany Zjednoczone aktualna dokumentacja wskazuje również dodatkowe wymagania, między innymi zatwierdzenie odpowiednich mechanizmów abuse monitoring oraz zawarcie odpowiedniego aneksu dotyczącego retencji. Dlatego nie wystarczy założyć, że samo utworzenie projektu „EU” rozwiązuje wszystkie kwestie prawne i techniczne.

Trzeba ponadto sprawdzić cały przepływ danych. Jeżeli aplikacja wysyła informacje z OpenAI do zewnętrznego serwera MCP, wyszukiwarki, systemu SaaS lub innej usługi, obowiązują również zasady przechowywania i lokalizacji danych tej usługi. OpenAI zaznacza w dokumentacji, że dane przekazane do zewnętrznego MCP podlegają politykom residency tego dostawcy.

Enterprise Key Management i BYOK

Dla organizacji wymagających większej kontroli nad szyfrowaniem OpenAI oferuje Enterprise Key Management. EKM umożliwia szyfrowanie customer content przy użyciu kluczy zarządzanych w zewnętrznym systemie KMS klienta. Po konfiguracji EKM obejmuje application state tworzony podczas korzystania z platformy.

Aktualna dokumentacja wymienia wsparcie BYOK z zewnętrznymi kontami AWS KMS, Google Cloud KMS oraz Azure Key Vault. Jednocześnie EKM ma ograniczenia produktowe — przykładowo dokumentacja wskazuje brak obsługi Assistants API i vision fine-tuning. Przed projektowaniem architektury należy więc sprawdzić zgodność wszystkich wykorzystywanych funkcji.

Szyfrowanie i certyfikacje — co rzeczywiście potwierdzają?

OpenAI informuje, że dane biznesowe są szyfrowane podczas przesyłania i przechowywania. W dokumentacji dotyczącej prywatności przedsiębiorstw wskazano AES-256 dla danych w spoczynku oraz TLS 1.2+ dla transmisji między klientem a OpenAI oraz między OpenAI a dostawcami usług.

OpenAI publikuje również informacje o audycie SOC 2 Type II i certyfikacjach obejmujących między innymi ISO/IEC 27001 i ISO/IEC 27701 dla odpowiednich systemów obsługujących OpenAI API.

Te informacje są istotne podczas oceny dostawcy, ale certyfikat dostawcy nie certyfikuje aplikacji zbudowanej przez klienta. Jeżeli organizacja przechowuje prompty w niezabezpieczonej bazie, udostępnia klucz API w frontendzie albo daje agentowi nieograniczony dostęp do systemów ERP, certyfikacja OpenAI nie usuwa tych ryzyk.

Prompt injection jest problemem bezpieczeństwa aplikacji, nie tylko modelu

Prompt injection polega na dostarczeniu modelowi instrukcji, które próbują zmienić jego zachowanie. Szczególnie poważne ryzyko pojawia się wtedy, gdy model ma dostęp do firmowych dokumentów, przeglądarki, systemów RAG, zewnętrznych konektorów lub narzędzi wykonujących działania.

OpenAI zaleca testowanie aplikacji wejściami adwersarialnymi i sprawdzanie, czy użytkownik może przekierować system niepożądaną instrukcją. W dokumentacji dotyczącej systemów korzystających z zewnętrznych danych OpenAI zaznacza również, że żadna automatyczna warstwa ochronna nie wychwyci wszystkich przypadków prompt injection.

Jak ograniczyć skutki prompt injection?

Traktuj dokumenty użytkownika, strony WWW i treści zewnętrznych systemów jako dane potencjalnie nieufne.
Nie przyznawaj modelowi szerszych uprawnień niż konieczne.
Oddziel generowanie odpowiedzi od wykonywania operacji na systemach firmowych.
Wymagaj zatwierdzenia człowieka przed operacjami wrażliwymi lub nieodwracalnymi.
Stosuj allowlisty narzędzi, domen i typów operacji.
Waliduj argumenty generowane przez model przed wykonaniem funkcji.
Nie umieszczaj sekretów w kontekście modelu, jeśli nie są absolutnie niezbędne.
Testuj próby eksfiltracji danych, zmiany instrukcji systemowych i obejścia kontroli dostępu.

Jeżeli aplikacja korzysta z MCP lub innych narzędzi mających dostęp do poufnych zasobów, poziom ryzyka rośnie. OpenAI zaleca ostrożność przy zewnętrznych serwerach MCP i dodatkowe zatwierdzanie działań wrażliwych.

Co logować w środowisku korporacyjnym?

Brak logów utrudnia wykrywanie incydentów, ale rejestrowanie każdego pełnego promptu może stworzyć nowy magazyn danych wrażliwych. Dlatego strategia logowania powinna być selektywna.

W typowym systemie warto rejestrować identyfikator użytkownika lub workloadu, czas żądania, użyty projekt i model, wynik kontroli bezpieczeństwa, kategorię operacji, zużycie, status odpowiedzi i identyfikator korelacyjny. Pełne treści wejść i wyjść powinny być rejestrowane tylko wtedy, gdy istnieje uzasadniona potrzeba oraz właściwa polityka retencji i kontroli dostępu.

Logi aplikacyjne warto przekazywać do istniejącego systemu monitorowania lub SIEM i definiować alerty dla nietypowych wzorców: nagłych skoków zużycia, dużej liczby błędów autoryzacji, prób używania zabronionych narzędzi czy nieoczekiwanego wzrostu kosztów.

Kontrola kosztów jest również elementem bezpieczeństwa

Przejęty klucz API może oznaczać nie tylko ryzyko dostępu, ale także generowanie kosztów. OpenAI udostępnia mechanizmy monitorowania wydatków na poziomie organizacji i projektu, a dokumentacja produkcyjna zaleca konfigurację alertów oraz limitów dopasowanych do zastosowania.

Limit wydatków nie zastępuje właściwego uwierzytelniania, ale może ograniczyć konsekwencje incydentu. Warto połączyć go z rate limitingiem aplikacji, limitami per użytkownik oraz alertami wykrywającymi nietypową aktywność.

OpenAI API a RODO — czy użycie API jest zgodne z RODO?

Nie ma poprawnej uniwersalnej odpowiedzi „tak, OpenAI API jest zgodne z RODO” dla każdej aplikacji. Zgodność zależy od tego, jak organizacja wykorzystuje usługę, jakie dane przetwarza, w jakim celu, na jakiej podstawie i jakie zabezpieczenia wdrożyła.

OpenAI oferuje klientom biznesowym i API Data Processing Addendum, a aktualna dokumentacja dotycząca prywatności wskazuje możliwość zawarcia DPA w celu wsparcia obowiązków związanych między innymi z RODO.

Nie zwalnia to klienta z własnych obowiązków. Przed produkcyjnym wdrożeniem organizacja powinna co najmniej ustalić:

cel przetwarzania danych osobowych;
właściwą podstawę prawną;
które dane są rzeczywiście niezbędne;
okres retencji po stronie własnego systemu i dostawców;
role stron w konkretnym procesie;
zasady dostępu użytkowników i administratorów;
czy wymagane są dodatkowe informacje dla osób, których dane dotyczą;
jak realizowane będą prawa osób, których dane dotyczą;
jakie podmioty dalsze uczestniczą w przetwarzaniu;
czy przepływy międzynarodowe wymagają dodatkowej analizy;
czy charakter procesu wymaga przeprowadzenia oceny skutków dla ochrony danych.

OpenAI publikuje aktualizowaną listę subprocessors wykorzystywanych w odniesieniu do danych klientów. Lista ta może zmieniać się w czasie, dlatego nie należy opierać dokumentacji compliance na jednorazowym zrzucie lub starej kopii.

Europejska Rada Ochrony Danych podkreśla również, że ocena przetwarzania danych w kontekście modeli AI wymaga analizy konkretnej sytuacji, w tym podstawy prawnej i charakteru danych, a nie prostego uznania całej technologii za zgodną lub niezgodną z RODO.

Checklist: przed uruchomieniem OpenAI API na produkcji

□ Zidentyfikowano wszystkie rodzaje danych wysyłanych do API.
□ Dane sklasyfikowano według poziomu poufności.
□ Usunięto informacje niepotrzebne do realizacji zadania.
□ Sprawdzono retencję dla konkretnych endpointów i funkcji.
□ Zweryfikowano, czy wymagany jest Modified Abuse Monitoring lub Zero Data Retention.
□ Sprawdzono zgodność używanych endpointów z ZDR, jeśli jest wymagane.
□ Wybrano właściwy region i zweryfikowano wymagania data residency.
□ Oddzielono development, test i production.
□ Każda aplikacja lub workload używa własnej tożsamości i minimalnych uprawnień.
□ Klucze nie znajdują się w frontendzie, aplikacji mobilnej ani repozytorium.
□ Skonfigurowano wygasanie i rotację poświadczeń.
□ Rozważono workload identity federation dla obsługiwanych workloads.
□ Ograniczono dostęp sieciowy tam, gdzie jest to uzasadnione.
□ Wdrożono monitoring kosztów, użycia i anomalii.
□ Logi nie gromadzą niepotrzebnych danych wrażliwych.
□ Przeprowadzono testy prompt injection i prób eksfiltracji.
□ Narzędzia i konektory działają zgodnie z zasadą najmniejszych uprawnień.
□ Operacje wysokiego ryzyka wymagają dodatkowej autoryzacji.
□ Sprawdzono dostawców zewnętrznych i subprocessors.
□ Zespół prawny lub DPO/IOD ocenił sposób przetwarzania danych osobowych, jeśli występują.
□ Powstała procedura rotacji kluczy i reakcji na incydent.

Najczęstsze błędy przy wdrażaniu API AI w firmie

Założenie, że „dane nie są używane do treningu” oznacza „dane nigdy nie są zapisywane”

To dwie różne kwestie. API domyślnie nie wykorzystuje danych klientów do treningu, ale standardowe logi monitorowania nadużyć i application state mogą podlegać określonej retencji.

Wspólny klucz dla wszystkich aplikacji

Taki model utrudnia ograniczanie uprawnień, rotację, audyt i izolowanie incydentów. Projekty, service accounts i osobne poświadczenia pozwalają zmniejszyć zakres potencjalnego naruszenia.

Logowanie całych promptów bez klasyfikacji

Firma może prawidłowo skonfigurować retencję po stronie OpenAI, a jednocześnie tworzyć własną niekontrolowaną kopię wszystkich danych w logach aplikacyjnych.

Zaufanie do modelu jako mechanizmu autoryzacji

Model nie powinien decydować, czy użytkownik ma prawo odczytać dokument, wykonać przelew, skasować rekord lub zmienić konfigurację infrastruktury. Autoryzacja musi być egzekwowana przez system aplikacyjny niezależnie od odpowiedzi modelu.

Traktowanie odpowiedzi modelu jako zaufanego kodu lub danych

Odpowiedź API powinna być traktowana jako dane wymagające walidacji. Jest to szczególnie ważne, gdy model generuje zapytania SQL, polecenia systemowe, parametry funkcji lub dane przekazywane dalej do innych usług.

Czy firma powinna wdrożyć Zero Data Retention?

ZDR ma największy sens tam, gdzie polityka organizacji wymaga maksymalnego ograniczenia przechowywania treści przez dostawcę i gdzie używane funkcje są zgodne z tym trybem. Nie należy jednak wybierać ZDR wyłącznie dlatego, że brzmi bezpieczniej.

Jeśli aplikacja wymaga funkcji, które zapisują application state lub nie kwalifikują się do ZDR, architektura może wymagać zmiany. Organizacja powinna więc najpierw rozpisać przepływ danych i wymagane endpointy, a dopiero potem zdecydować o mechanizmie retencji. Aktualna dokumentacja OpenAI powinna być sprawdzona ponownie przed wdrożeniem, ponieważ lista obsługiwanych funkcji może się zmieniać.

Czy można przesyłać dane poufne do OpenAI API?

Techniczna możliwość wysłania danych nie oznacza, że organizacja powinna to robić. Decyzja zależy od klasyfikacji informacji, wymagań prawnych, umownych, polityki bezpieczeństwa, konfiguracji retencji i całej architektury aplikacji.

Najbezpieczniejszą zasadą jest wysyłanie najmniejszej ilości danych potrzebnej do wykonania zadania. Jeżeli można uzyskać ten sam rezultat po usunięciu nazwiska klienta, numeru umowy lub tajemnicy handlowej, te informacje nie powinny trafiać do promptu.

Czy OpenAI API spełnia wymagania bezpieczeństwa przedsiębiorstwa?

OpenAI udostępnia mechanizmy, które pozwalają budować rozwiązania o wysokim poziomie kontroli: szyfrowanie, projekty i role, service accounts, retencję konfigurowaną dla kwalifikujących się klientów, regionalizację danych, EKM/BYOK oraz bardziej zaawansowane opcje infrastrukturalne.

Ostateczne bezpieczeństwo zależy jednak od całego systemu. Bezpieczne OpenAI API połączone z niezabezpieczonym frontendem, publiczną bazą wektorową lub agentem posiadającym uprawnienia administratora nadal tworzy niebezpieczną aplikację.

Dlatego wdrożenie korporacyjne powinno być traktowane jak każdy inny istotny system przetwarzający dane: z modelem zagrożeń, zasadą najmniejszych uprawnień, kontrolą cyklu życia danych, monitorowaniem, testami bezpieczeństwa, procesem incident response oraz regularnym przeglądem konfiguracji dostawcy.

Najważniejsze pytania o API ChatGPT w środowisku korporacyjnym

Czy OpenAI używa danych z API do trenowania modeli?

Domyślnie nie. OpenAI informuje, że dane wejściowe i wyjściowe klientów API nie są wykorzystywane do trenowania ani ulepszania modeli, chyba że klient jawnie zdecyduje się je udostępnić w tym celu.

Czy OpenAI przechowuje dane z API przez 30 dni?

Nie można stosować tej wartości jako uniwersalnej reguły dla wszystkich danych i endpointów. Domyślne abuse monitoring logs dla wielu endpointów są przechowywane do 30 dni, natomiast application state może mieć inny cykl życia zależny od funkcji. Dokumentacja OpenAI publikuje zasady per endpoint.

Czy Zero Data Retention oznacza absolutnie zero przechowywania we wszystkich funkcjach?

Nie należy tak tego interpretować. ZDR ma określone zasady i listę kwalifikujących się endpointów. Funkcje niezgodne z ZDR mogą przechowywać application state, nawet jeśli organizacja korzysta z tego mechanizmu.

Czy klucz OpenAI API może znajdować się w aplikacji mobilnej?

Nie. OpenAI zaleca, aby kluczy API nie umieszczać w przeglądarkach ani aplikacjach mobilnych. Wywołanie powinno przechodzić przez kontrolowany backend.

Czy OpenAI API jest automatycznie zgodne z RODO?

Nie istnieje automatyczna zgodność całej aplikacji wynikająca wyłącznie z wyboru dostawcy. Organizacja musi ocenić własny cel i sposób przetwarzania, podstawę prawną, zakres danych, retencję, dostęp, dostawców i inne obowiązki wynikające z RODO.

Czy certyfikaty OpenAI wystarczą do zatwierdzenia rozwiązania przez security?

Nie. Są ważnym elementem oceny dostawcy, ale zespół bezpieczeństwa powinien dodatkowo ocenić architekturę konkretnej aplikacji, klasy danych, poświadczenia, integracje, logowanie, narzędzia i możliwe ścieżki eksfiltracji.

Bezpieczne OpenAI API w firmie — wnioski

Bezpieczne wykorzystanie API ChatGPT w środowisku korporacyjnym wymaga połączenia zabezpieczeń oferowanych przez OpenAI z kontrolami działającymi po stronie przedsiębiorstwa. Najważniejsze decyzje dotyczą nie tylko wyboru modelu, ale przede wszystkim tego, jakie dane mogą opuszczać organizację, jak długo są przechowywane, kto ma dostęp do API i jakie działania może wykonywać system korzystający z modelu.

Przed produkcyjnym wdrożeniem należy zweryfikować aktualną tabelę retencji dla używanych endpointów, dostępność ZDR lub Modified Abuse Monitoring, wymagania data residency oraz ograniczenia funkcji takich jak EKM. Równolegle trzeba zastosować minimalizację danych, bezpieczne poświadczenia, zasadę najmniejszych uprawnień, walidację wyników, monitoring i ochronę przed prompt injection.

Warto również traktować konfigurację jako element podlegający regularnym przeglądom. OpenAI rozwija platformę i mechanizmy bezpieczeństwa, dlatego ustawienia zatwierdzone przy pierwszym wdrożeniu nie powinny pozostawać niezmienione przez cały cykl życia aplikacji.

Źródła i dokumentacja

OpenAI — Data controls in the OpenAI platform.
OpenAI — Business data privacy, security, and compliance.
OpenAI — Enterprise privacy.
OpenAI — Security and privacy.
OpenAI — Production best practices.
OpenAI — Safety best practices.
OpenAI — Best Practices for API Key Safety.
OpenAI — Sub-processor list.
Europejska Rada Ochrony Danych — Opinia 28/2024 dotycząca przetwarzania danych osobowych w kontekście modeli AI.
EUR-Lex — Rozporządzenie (UE) 2016/679 (RODO).

Informacje techniczne zweryfikowano 7 października 2026 r. Funkcje platformy, zakres endpointów kwalifikujących się do poszczególnych mechanizmów retencji oraz wymagania regionalne mogą się zmieniać, dlatego przed wdrożeniem należy ponownie sprawdzić aktualną dokumentację OpenAI.