Jogi szövegek — változásnapló

Mi változott a 2022-es, ügyvéd által írt alapszöveghez képest, mikor és miért.

A gépi, sor-szintű változat: git log -p docs/legal/. Ez a fájl a emberi olvasat —

és egyben az ügyvédi átnézés munkalapja: elég ezt végigmenni ahhoz, hogy tudni lehessen,

mihez kell hozzászólni.

Állapot: JAVASLAT — jogi jóváhagyás nélkül nem élesíthető.

[Nem élesített] — 2026-08-07 (2)

Retenció — a 30 napos ígéret mostantól tényleg végrehajtódik (SMU-786)

• Eddig SEMMI nem hajtotta végre. A tájékoztató azt írta, hogy a névtelen beszélgetéshez

kapcsolódó adatokat a Szolgáltató 30 nap után automatikusan törli — a rendszerben viszont

egyetlen retenciós takarító feladat sem futott. Mostantól naponta fut egy takarítás,

ami a 30 napnál régebbi névtelen nyomokat (tölcsér-telemetria, névtelen MI-használati

tételek) törli. A bejelentkezett felhasználók tételeihez nem nyúl: azok a fiók

fennállásáig élnek, és a fiók törlésekor mennek.

• A szöveg pontosítva: TÖBBET állított, mint a valóság. A tájékoztató úgy fogalmazott,

mintha a beszélgetés tartalmát a Szolgáltató tárolná és 30 nap után törölné. Valójában a

beszélgetés szövege a Felhasználó saját böngészőjében marad, és a szerverre el sem

jut; ott csak műszaki adat (azonosító, időbélyeg, felhasznált MI-kapacitás) keletkezik.

A táblázat sora ennek megfelelően átírva — a pontatlanság a Felhasználó javára szólt,

de akkor sem maradhat benne.

[Nem élesített] — 2026-08-07

Adathordozhatóság — a törlés párja megvan (GDPR 20. cikk)

• A felhasználó letöltheti a saját adatait, géppel olvasható formában, a Fiók oldalról.

Ez a fiók-törlés élesítésének feltétele volt: törlést kínálni export nélkül azt jelenti,

hogy az adat visszaszerezhetetlenül vész el. A letöltés a törlési szakasz FÖLÖTT áll, és a

törlési szakasz szövege külön felhívja rá a figyelmet.

• Amit a kivonat tartalmaz: a fiók alapadatai és szerepkörei, a munkaterületi tagságok,

a bejelentkezett eszközök (a bejelentkezéskor látott IP-címmel), a bevezető-folyamat

állapota, és az MI-funkciók használatának elszámolási nyoma.

• Amit tudatosan NEM tartalmaz: a munkaterületekben tárolt üzleti adat tartalmát.

Az az adat a munkaterületé, és MÁS tagok adatait is tartalmazhatja — ha bármelyik tag

letölthetné „a saját adataként", azzal mások adatait adnánk ki. Helyette a szerzőség

MÉRTÉKE szerepel (hány rekordot rögzített), magyarázattal együtt; a rekordok a

munkaterület felületéről exportálhatók.

⚠️ Ügyvédnek szóló kérdés: helyes-e ez a határhúzás? A 20. cikk az érintett által
„rendelkezésre bocsátott" adatokra vonatkozik — a munkaterületbe rögzített rekordok
részben ilyenek, de közös munkaterületen harmadik személyek adatait is hordozzák.

[Nem élesített] — 2026-08-06 (2)

Törléshez való jog — a kód utolérte a szöveget (SMU-629)

• A fiók törölhetővé vált (GDPR 17. cikk). A tájékoztató és az ÁSZF eddig is ígérte, hogy

a fiók törlésével a hozzá tartozó adatok törlődnek — a rendszerben viszont **semmilyen

fiók-törlési lehetőség nem létezett**. Mostantól a Fiók oldalon elérhető.

• Az üzleti adat nem vész el, a személy viszont nem azonosítható. Az űrlap-rekordok a

munkaterülethez tartoznak, nem a felhasználóhoz — ezeket a törlés nem semmisíti meg, csak a

szerzőség lesz névtelen. A használati napló felhasználó-azonosítója törlődik.

• Ha a felhasználó egy munkaterület utolsó tagja, az a munkaterület is megszűnik. Enélkül

gazdátlan, senki által el nem érhető adat maradna hátra, ami soha nem törlődne. A törlés előtt

a felhasználó tételesen látja, melyik munkaterület szűnik meg, és a művelethez egy

megerősítő szót kell begépelnie.

⚠️ Ügyvédnek szóló kérdés: helyes-e, hogy a munkaterület megszűnésével az abban tárolt,
esetleg HARMADIK személyekre vonatkozó adatok is törlődnek? A tájékoztató szerint ezen
adatok tekintetében a Felhasználó az adatkezelő, a Szolgáltató adatfeldolgozó — a törlés
tehát az adatkezelő utasítása. Kérjük ennek megerősítését.

• A hiányzó adathordozhatóság (GDPR 20. cikk) külön feladat. Élesítés előtt a törlés mellé

adat-exportot is kell adni, hogy a felhasználó a törlés előtt magával vihesse az adatait.

[Nem élesített] — 2026-08-06

Sütik — a tájékoztató és a kód összehangolva (SMU-112)

• A hirdetési célú süti-hozzájárulás megszűnt. A korábbi sáv az „Elfogadom" gombbal a

hirdetési célú adattárolást (ad_storage) is engedélyezte, holott a Szolgáltató hirdetési

célú adatkezelést nem végez. Ez célhoz kötöttségi probléma volt (GDPR 5. cikk (1) b):

hozzájárulást kértünk olyan célra, amilyen adatkezelés nem is folyt.

Mostantól az ad_storage, ad_user_data és ad_personalization állandóan letiltott —

nincs az a felhasználói választás, amely ezeket engedélyezné.

• A visszavonás ténylegesen elérhetővé vált (GDPR 7. cikk (3)). Korábban a tájékoztató

azt írta, hogy a hozzájárulás „bármikor, ugyanott visszavonható", de a felületen **semmilyen

visszavonási lehetőség nem létezett**. Mostantól minden oldal láblécében ott a

„Süti-beállítások" hivatkozás.

• Az elutasítás ugyanolyan könnyű lett, mint az elfogadás. A két gomb azonos méretű és

stílusú; a korábbi „Elutasítom" ág ráadásul egyirányú volt (utána a felhasználó soha

többé nem tudott hozzájárulni sem).

• A hozzájárulás a döntés idejét és verzióját is rögzíti (GDPR 7. cikk (1),

bizonyíthatóság). Ha a süti-kezelés érdemben változik, a verzió emelésével a korábbi

hozzájárulás érvényét veszti, és a rendszer újra megkérdezi a Felhasználót.

⚠️ Ügyvédnek szóló kérdés: a hozzájárulás nyoma a látogató böngészőjében marad
(időbélyeg + verzió + a választás), szerver-oldali hozzájárulás-nyilvántartást
szándékosan nem vezettünk be. Ehhez ugyanis a névtelen látogatót azonosítani
kellene — vagyis több személyes adatot kezelnénk, mint amennyit a mérés maga igényel.
Elfogadható-e ez a bizonyíthatóság szempontjából, vagy szükséges szerver-oldali napló?

• A Google mérőkódja hozzájárulás nélkül el sem indul. Korábban a mérőkód minden

oldalbetöltéssel betöltődött, és a tiltott tárolás ellenére is kapcsolatba lépett a

Google-lel (a látogató IP-címét továbbító „ping"). Tárolás valóban nem történt, de a

tájékoztatónk azt ígéri, hogy a mérés „csak az Ön hozzájárulásával indul el" — a

kapcsolatfelvétel maga ennek ellentmondott. Mérve: hozzájárulás előtt **309 hálózati

kérésből egy sem** ment a Google felé; a mérőkód a döntés után jelent meg.

• A visszavonás a már lerakott mérési sütiket is törli. A hozzájárulás visszavonása

önmagában csak a jövőbeli tárolást állítja meg — a korábban elhelyezett _ga azonosító

bent maradt a látogatónál. Mérve a teljes életciklus: hozzájárulás előtt 0 süti →

elfogadás után _ga → visszavonás után újra 0.

• A beágyazott bemutató-videók a „nocookie" tartományról töltődnek. A főoldal

hozzájárulás előtt kérést indított a doubleclick.net felé a YouTube-beágyazás miatt.

⚠️ Ügyvédnek szóló megjegyzés: ez mérséklés, nem teljes megoldás — a lejátszás
megkezdése után a YouTube így is tárol adatot. A teljes megoldás a „kattintásra
töltődő" beágyazás; külön feladatban.

• Két funkcionális hiba is javult, amely a tájékoztató ígéretét sértette:

a mérés a görgetés-követés esetében hozzájárulás nélkül is küldött eseményt; a

visszatérő látogatónál pedig a korábban megadott hozzájárulás soha nem állt vissza.

[Nem élesített] — 2026-08-05

Nullpont

• docs(legal): commit 0 — a 2022-es öt dokumentum markdownban, változtatás nélkül.

Nincs benne javítás; ez a mérce, amihez az alábbiak képest mérünk.

Szöveg-hűség igazolva: mind az 5 doksin 0 hiányzó / 0 többlet szó.

Jogalany

• Szolgáltató: Sas Csaba egyéni vállalkozó → SasWare Kft.

Adószám 68157731-1-39 → 32674565-2-19. A nyilvántartási szám helyére cégjegyzékszám

lép, a nyilvántartó szerv az egyéni vállalkozói nyilvántartás helyett a cégbíróság.

Érintett: mind az 5 doksi.

⚠️ Ügyvédnek szóló kérdés: ez nem szövegcsere, hanem **adatkezelő-váltás és
szerződő fél-váltás**. Kell-e (a) a meglévő felhasználók tájékoztatása a GDPR 13-14.
cikk szerint, (b) az e.v.-ként kötött szerződések átruházása, (c) az e.v. időszakban
keletkezett adatok jogutódlásának rendezése? A szöveg önmagában ezt nem oldja meg.

⚠️ Kitöltendő adatok (a foundertől): cégjegyzékszám · a cégbíróság megnevezése ·
hivatalos e-mail cím · a Portál URL-je. A szövegben [KITÖLTENDŐ: …] jelöléssel.

Cégadatok kitöltése (2026-08-05)

A [KITÖLTENDŐ] mezők közül az igazolhatók kitöltve:

A cégadatok a Windows-oldali OneDrive „Csabi/SasWare/Törzsadatok" mappából **nem
voltak olvashatók** — a OneDrive felhő-helykitöltő (reparse tag 0x9000701a), Linuxról
nem járható be. A cégjegyzékszám nyilvános cégadat, ezért két független nyilvános
forrásból igazoltuk; a sasware repo sablonjaiban [pótolni] jelöléssel áll.

Nyitva maradt, mert döntés, nem lekérdezés:

• hivatalos e-mail cím a jogi doksikba. Jelöltek: alfred06sas@gmail.com (személyes

jellegű), sasware.kft.dev@gmail.com (brand-postafiók). Adatvédelmi megkeresésre

jellemzően dedikált cím szokott állni (pl. adatvedelem@selfmadeup.com).

• hatálybalépés dátuma — az ügyvédi jóváhagyás után dől el.
• adatfeldolgozói táblázat — a következő commit tölti ki (F1).

Tartalom-frissítés 2026 — adatfeldolgozók, harmadik ország, retenció, sütik (2026-08-05)

Magyar adatkezelési tájékoztató. Mind [JAVASLAT], ügyvédi jóváhagyást igényel.

Adatfeldolgozói táblázat kitöltve (eddig *** volt). A kódbázisból igazolt, ténylegesen

használt szolgáltatók:

A székhelyek a szolgáltatók nyilvános EU-s jogalanyai alapján kerültek be — **a tényleges
adatfeldolgozói szerződések alapján ellenőrizni kell**, melyik jogalannyal áll fenn a szerződés.

Új szakasz: adattovábbítás harmadik országba. Eddig teljesen hiányzott. ⚠️ Az Azure és az

Azure OpenAI példány földrajzi régiója nincs igazolva — a config csak a végpontot mutatja.

Új szakasz: sütik és látogatottság-mérés. ⚠️ Ellentmondás a szöveg és a kód között: a

tájékoztató jogos érdeket mond a látogatottsági statisztikára, a kód viszont

hozzájárulás-alapú Google Analyticset futtat (consent mode, alapból letiltva). A süti-alapú

mérés jogalapja hozzájárulás, nem jogos érdek — a szöveg ehhez lett igazítva.

⚠️ Kód-hiba, amit ez felszínre hozott: a mai süti-sáv egyetlen gombbal a hirdetési célú

adattárolást (ad_storage) is engedélyezi, holott hirdetési adatkezelés nincs, és a

tájékoztató sem szól róla. Javítandó (F4, SMU-112).

Retenció egységesítve. A 2022-es táblázat önmagában ellentmondó volt: a név 5 évig, az

e-mail cím ugyanannál a felhasználónál 6 hónapig volt megőrizve — e-mail nélkül viszont az

azonosítás sem működik. Mostantól egységesen a szerződés megszűnésétől számított 5 év, a

számlázási adatok kivételével: 8 év (Számv. tv. 169. §; a 2022-es szöveg itt 5 évet írt,

ami rövidebb a jogszabályi kötelezettségnél).

Angol adatkezelési tájékoztató — teljes paritás (2026-08-05)

Az en/privacy-policy.md megkapta a magyar változat minden 2026-os kiegészítését:

MI-szakasz, süti-szakasz, harmadik országba továbbítás, adatfeldolgozói táblázat,

retenció-egységesítés, GDPR 22. cikk pontosítása.

Bizonyíték: 25 szakasz mindkét nyelven, és mind az öt új szakasz, valamint mind a négy

adatfeldolgozó megtalálható mindkét fájlban.

MI-szakasz — retenció és korpusz-megfogalmazás (2026-08-05)

• Retenció (founder-döntés): a bejelentkezett Felhasználó beszélgetése a **fiók

életciklusához** kötődik (a fiók törlésével törlődik), nem kap külön időzítőt. Be nem

jelentkezett Felhasználónál kemény 30 napos felső korlát.

• A fejlesztési célú felhasználás megfogalmazása élesebb lett. Az eredeti javaslat azt

ígérte, hogy a beszélgetésből „eltávolítjuk a személyazonosításra alkalmas adatokat" — ezt

szabad szövegű LLM-kimenetre nem tudjuk betartani, mert a személyes adat helye előre nem

ismert. Helyette: a szöveg egyáltalán nem kerül át, csak a belőle előállított szerkezeti

adat (lépések, szerepkör-típusok, mezőtípusok). Így az „anonimizált" nem ígéret, hanem

szerkezeti tulajdonság. Egyeztetve az AutoModel F4 sessionnel (SMU-471 komment).

EULA és ÁSZF — SaaS-nyelvezet, MI, fiók-törlés (2026-08-05)

EULA (HU+EN) — két új szakasz. A 2022-es szöveg on-prem szemléletű volt („a Szoftver

telepítése", „a Felhasználó eszközén futó programok mentése"), holott a SelfMadeUp

szolgáltatásként fut és a Felhasználó semmit nem telepít.

⚠️ Ügyvédnek: az 50.000 Ft-os kártérítési plafon fogyasztóval szemben támadható
lehet; a 6 hónapos igényérvényesítési határidő rövidebb az általános elévülésnél. Ezeket
nem módosítottuk.

ÁSZF (HU) — új MI-szakasz, és egy tartalmi javítás:

⚠️ A 2022-es szöveg kimondta: *„A Felhasználó nem jogosult a regisztrációját a Portálról
maga törölni."* Ez ütközik a fiók-törlés irányával (SMU-629) és nehezen fér össze az
elfeledtetéshez való joggal. Módosítva: a Felhasználó a fiókja beállításai között maga is
kezdeményezheti a törlést, vagy e-mailben kérheti. A jogszabályi megőrzési kötelezettség
(számviteli bizonylatok) kivételként nevesítve — a 2022-es szöveg itt „a korábbi
megrendelésekre vonatkozó adatokat" mondott, ami tágabb és pontatlanabb.
Figyelem: a szöveg most olyan funkciót ígér, ami a kódban MÉG NINCS MEG (SMU-629). A
kettőt együtt kell élesíteni.

Angol ÁSZF — tájékoztató fordítás (2026-08-05)

Az en/aszf.md elkészült. Nem kötelező erejű változat: maga az ÁSZF mondja ki, hogy

„A szerződéskötés nyelve kizárólag a magyar" — az angol szöveg tájékoztató jellegű, eltérés

esetén a magyar az irányadó. Ez a fejlécben ki is van mondva.

Bizonyíték: 15 szakasz, 14 fogalom-sor és azonos számú felsorolás-pont mindkét nyelven.

⚠️ Ügyvédnek: a fordítást nem szakfordító készítette. A magyar jogszabály-hivatkozások
(Ptk., Elkertv., 45/2014. Korm. rendelet, békéltető testület) angolul körülírással szerepelnek —
ezek pontossága külön ellenőrzést igényel.

Ezzel az ügyvédi átnézésre szánt csomag nyelvileg teljes: mind a három dokumentum megvan

magyarul és angolul.

⚠️ Harmadik ország — IGAZOLT TÉNY, nem feltételezés (2026-08-06)

Az Azure Resource Manager API-n lekérdezve (SMU-785):

southcentralus   Microsoft.Sql/servers/databases   selfmadeappserverdbserver/SelfMadeAppProd
southcentralus   Microsoft.Sql/servers/databases   selfmadeappserverdbserver/SelfMadeAppTest

A produkciós adatbázis az Egyesült Államokban (Texas) fut, nem az EU-ban. A harmadik

országba történő adattovábbítás tehát nem elméleti lehetőség, hanem a jelenlegi tényállapot —

és a 2022-es tájékoztató erről egyáltalán nem szólt.

A HU és EN szakasz ehhez lett igazítva: a régió néven nevezve, a jogalap (megfelelőségi

határozat vagy SCC) megjelölve.

Nem igazolt a többi erőforrás (App Service, Blob Storage, AI Search, Azure OpenAI)

régiója — a rendelkezésre álló hozzáférés csak az SQL-erőforrásokat látja. Az Azure OpenAI

régiója külön fontos, mert a beszélgetés-tartalom oda kerül.

Megfontolandó döntés a foundernek: az adatok EU-s régióba költöztetése egyszerűbb és
tartósabb megoldás lehet, mint a továbbítás jogi alátámasztása és folyamatos karbantartása.

Jelölések