Az OpenAI API-ban önkiszolgáló a HIPAA-szerződés – de nem mindenkinek

Az OpenAI 2026. október 5-én az API változásnaplójában rögzítette, hogy a jogosult szervezetek adminisztrátorai a szervezeti beállításokban fogadhatják el a szabványos Business Associate Agreementet (BAA), és engedélyezhetik a HIPAA-megfelelést támogató funkciót. Az amerikai egészségügyi piacra fejlesztő cégek számára ez közvetlen szerződéskötési út az API Platformon. Az „Active” állapot azonban a szervezet szerződéses beállítását jelzi, nem egy teljes alkalmazás megfelelőségét.

Az önkiszolgáló út korábbi API-használathoz kötött, és olyan adminisztrátor végezheti el, aki a szervezet nevében elfogadhatja a megállapodást; vállalati szerződés nem előfeltétel. Rohit Ramachandran október 5-i áttekintése külön kezeli a BAA elfogadását, a megfelelő szervezet és projekt adatmegőrzési beállítását, valamint a védett egészségügyi adatok útját. E különbség azért lényeges, mert a betegadatot feldolgozó API-kérésre további feltételek vonatkoznak.

Ki jut hozzá az önkiszolgáló BAA-hoz?

A lehetőség a jogosult, már API-t használó szervezeteknek szól. Az OpenAI nem ad meg nyilvános számszerű küszöböt a szükséges használati előzményhez. Ha a BAA szakaszban „Not eligible yet” látható, az adott szervezet jelenleg nem tudja ezen a felületen elfogadni a szabványos megállapodást. A jelzés az önkiszolgáló belépési feltételről szól; önmagában nem döntés egy konkrét egészségügyi alkalmazásról.

A szervezeti beállításokhoz való hozzáférés és a szerződés elfogadására szóló felhatalmazás két külön feltétel. Az adminisztrátor a kiválasztott szervezet nevét és Organization ID-ját erősíti meg, ezért több API-szervezetet működtető cégnél számít, melyikhez kerül a BAA. Egyedi szerződéses feltételekhez továbbra is külön, e-mailes kérelmi út tartozik; az önkiszolgáló folyamat a szabványos megállapodásra épül.

Hogyan lesz a megállapodásból „Active” állapot?

Az adminisztrátor az API Platformon először kiválasztja az érintett szervezetet, majd a Settings → Organization → General menüben megnyitja a HIPAA compliance support szakaszt. Az Enable művelet után letöltheti a Business Associate and Healthcare Addendumot, áttekintheti a lefedett szolgáltatásokat, és megerősítheti, hogy jogosult a megállapodás elfogadására. A szervezet neve és azonosítója ellenőrzése után az Agree and enable zárja le a folyamatot.

Sikeres elfogadáskor a beállítás „Active” állapotot mutat, a felületen kötött szabványos megállapodás pedig a View agreement lehetőséggel letölthető. A felületen egyszer engedélyezett HIPAA compliance support később ugyanott nem kapcsolható ki. Ezért a szervezet azonosítója és a megállapodás hatálya már az elfogadáskor érdemi adatkezelési kérdés, különösen akkor, ha a fejlesztés és az éles működés eltérő API-szervezetben zajlik.

A BAA után a projekt és a végpont is számít

Az API-val kezelt protected health information (PHI), vagyis védett egészségügyi adat esetében a megkötött BAA mellé Modified Retention szükséges, hacsak az OpenAI másként nem rendelkezik. A HIPAA-jogosult funkciók felsorolása meghatározott API-végpontokra terjeszti ki a lefedettséget: köztük van a Responses, a Chat Completions, az embeddings, a files és a vector stores. Attól, hogy egy másik funkció technikailag elérhető az API-ban, még nem válik automatikusan PHI feldolgozására jogosulttá.

A Modified Retention gyűjtőfogalom: több adatmegőrzési módot foglal magában, és nem azonos minden esetben a Zero Data Retentionnel. A HIPAA-hoz kapcsolódó beállításnak a PHI-t továbbító Organization ID és projekt esetében kell aktívnak lennie. A BAA elfogadásakor megjelenő „Active” feliratból ezért nem olvasható ki, melyik projekt milyen megőrzési móddal küldi a kéréseket. Az sem következik a végpont HIPAA-jogosultságából, hogy minden kapcsolódó fájl, tároló vagy eszköz azonos ideig őrzi meg az adatot.

Egy feltételes, betegadatot összefoglaló alkalmazásban külön állomás a bemeneti adat átvétele, az esetleges fájlfeltöltés, a modellhívás, a kereshető tároló és a válasz továbbítása. A BAA az OpenAI által nyújtott jogosult szolgáltatásokra vonatkozik; az alkalmazás saját naplói, hozzáférési szabályai és más szolgáltatói ettől külön vizsgálandók. A szerződés, a megfelelő projektbeállítás, a felsorolt végpont és az alkalmazás teljes adatútja tehát egymásra épülő feltétel, nem ugyanannak a kapcsolónak négy neve.

Mit változtat ez egy magyar healthtech cégnél?

Amerikai egészségügyi ügyfélnek fejlesztő magyar cég számára az újdonság a szabványos OpenAI BAA elfogadásának módja. A betegadatot fogadó alkalmazásban továbbra is az számít, melyik szervezet és projekt hitelesítő adatai küldik a PHI-t, milyen végpontot és adatmegőrzési módot használ a munkafolyamat, valamint hol maradnak meg a bemenetek és az eredmények. Ha a tesztkörnyezet más projekthez tartozik, annak beállítása nem írja le az éles adatáramlást.

Ha a munkafolyamat uniós érintettek személyes adatait is kezeli, a HIPAA-hoz kötődő BAA mellett a GDPR szerinti jogalapot, az egészségügyi adatok kezelésének feltételeit, az adatkezelői és adatfeldolgozói szerepeket, valamint az esetleges nemzetközi adattovábbítást is a konkrét adatáramlás alapján kell megítélni. A felületen megkötött szerződés így lerövidítheti az OpenAI-jal szükséges szabványos BAA elfogadásának útját, de a betegadatot ténylegesen fogadó projekt és alkalmazás megfelelősége külön döntés marad.

Olvassa el ezt is:

• OpenAI API vagy Anthropic API: a gyorsabb válasz nem mindig olcsóbb
• DMARC beállítása: a p=reject nem lehet az első lépés
• Asana vagy monday.com: az olcsóbb csomag nem ugyanazt automatizálja