Privacy Policy, Terms, Support: məcburi hüquqi səhifələr

1. Ümumiyyətlə nə üçün Privacy Policy, Terms və Support lazımdır

Gəlin xoş olmayan həqiqətlə başlayaq: ChatGPT Store üçün məxfilik siyasətinin (Privacy Policy) və dəstək üçün əlaqə məlumatının açıq şəkildə mövcud olması — “yaxşı ton” deyil, sərt tələbdir. OpenAI təlimatlarında açıq yazılıb ki, hər bir App-in yayımlanmış Privacy Policy-si olmalıdır və burada hansı məlumatların toplanması və istifadəsi, həmçinin dəstək üçün əlaqə aydın izah edilməlidir.

Amma məsələ təkcə “moderator əl çəksin deyə” deyil. Bu sənədlər eyni anda bir neçə vəzifəni həll edir.

Birincisi, bu istifadəçi üçün baza səviyyəsində etibardır. O, görür ki, tətbiqin arxasında real insanlar və ya şirkət var, qaydalar mövcuddur və problem olduqda müraciət ediləcək ünvan var. “Növbəti İA-servis”in hər gün peyda olduğu bir dünyada bu artıq rəqabət üstünlüyüdür.

İkincisi, bu artıq arxitekturada etdiklərinizi formallaşdırır. Təhlükəsizlik, loglama, retention, məlumatların silinməsi və ödənişlərlə iş mövzularında verdiyiniz qərarlar sözlərlə də ifadə olunmalıdır. Əgər “yazışmanı saxlamırıq” deyirsinizsə, amma bütün tool‑input-u həmişəlik loglayırsınızsa, bu təkcə xoşagəlməz deyil — ciddi iddialar üçün səbəbdir.

Üçüncüsü, bu sizinlə OpenAI arasında daha bir səviyyə müqavilədir. Store faktiki olaraq deyir: “App-ini milyonlarla insana göstərməyə hazırıq, amma gərək onlarla nə etdiyini dürüst təsvir edəsən və nəsə səhv gedəndə əlaqədə olasan”.

Nəticə: hüquqi səhifələr “hüquqşünaslar məcbur etdi” barədə deyil. Bu, gözləntilərin sinxronizasiyasıdır: App nə edir, hansı məlumatlara toxunur, hansı məsuliyyəti daşımağa hazırsınız və istifadəçi sizinlə necə əlaqə saxlaya bilər.

2. Bu hüquqi URL-lər ChatGPT App-də harada yerləşir

Texniki olaraq ChatGPT App üçün hüquqi səhifələr — tətbiqin metadata-sında və Store listing-də göstərdiyiniz adi, açıq URL-lərdir. Təlimatlarda onlar adətən privacy_policy_url, terms_of_service_url və support-kontakt kimi adlandırılır.

Bu URL-lər bir neçə sadə, amma vacib şərtə cavab verməlidir:

1. Onlar məhsulunuzun və ya şirkətinizin sabit domenində yerləşməlidir. Müvəqqəti ngrok-linklər olmaz, əks halda bir həftə sonra Store istifadəçini heç yerə yönləndirəcək.
2. Onlar avtorizasiyasız əlçatan olmalıdır. İstifadəçi (və reviewer) onları brauzerdə login və mürəkkəb ritual olmadan aça bilməlidir.
3. Onlar aktual olmalı və reallıqla üst-üstə düşməlidir. Məlumatların emalı arxitekturasını dəyişsəniz, zamanla mətnləri də yeniləmək lazım gələcək.

Tədris layihəmiz GiftGenius-da artıq Next.js frontend var və onu, məsələn, Vercel-ə deploy edirik. Deməli, hüquqi səhifələr üçün məntiqli yer belə marşrutlardır:

• /legal/privacy
• /legal/terms
• /support

Əslində bunlar tətbiqdə daha üç səhifədir, lakin məhz onlara App-i review-a göndərmə formasında istinad edəcəksiniz.

3. Privacy Policy: məlumatlarla nə etdiyinizi dürüst təsvir etmək

Privacy Policy-nin rolu

Privacy Policy (məxfilik siyasəti, qısaca — Policy) əsas sualı cavablandırır: “Bu App mənim (istifadəçinin) məlumatlarımla nə edir?” O, hansı məlumat kateqoriyalarını emal etdiyinizi, onların haradan gəldiyini, nə üçün lazım olduğunu, harada və nə qədər saxlandığını, kimlərlə paylaşıldığını və istifadəçinin onları necə silməyi tələb edə biləcəyini təsvir etməlidir.

ChatGPT App-lərin özəlliyi ondadır ki, istifadəçi sizin məhz söhbətdən nə aldığınızı anlamaq istəyir. OpenAI ayrıca vurğulayır: App bütün dialoqu bərpa etməyə çalışmamalı, yalnız modelin və ya istifadəçinin alətlərə açıq göndərdiyi fraqmentlərlə işləməlidir. Bunu da Policy-də qeyd etmək lazımdır.

Mətnlə deyil, arxitektura ilə başlayaq

Hər hansı hüquqi sözü yazmazdan əvvəl App-inizə SRE/arxitektor gözü ilə baxmaq faydalıdır: sistemdən əslində hansı məlumatlar keçir.

Bizim nümunə — GiftGenius — üçün bu təxminən belə görünə bilər:

Belə bir cədvəli birbaşa layihə sənədlərində (məsələn, /docs içində) saxlamaq olar: bu həm inkişaf, həm Security modulunda, həm də Policy mətninin özündə yararlı olacaq.

Sonra bu strukturu “insan dilinə” çeviririk.

GiftGenius üçün Privacy Policy-nin strukturu

Tədris layihəsində 20 səhifəlik epopeya yazmağa ehtiyac yoxdur, kompakt, amma dürüst bir struktur kifayətdir. Adətən bir neçə bölmə ayrılır:

1. Giriş: siz kimsiniz və App nədir.
2. Hansıməlumatları toplayırsınız.
3. Onlardan necə istifadə edirsiniz.
4. Kimə ötürürsünüz.
5. Harada və nə qədər saxlayırsınız.
6. İstifadəçi hüquqları (silinmə tələbi daxil olmaqla).
7. Məxfilik sualları üzrə əlaqə.

Vacibdir ki, hətta tədris layihəsi üçün də bu sadəcə “şablon” deyil. Təhlükəsizlik modulunda artıq logların saxlanma müddətini, silmə siyasətini, backup-ları düşünmüşdünüz — indi bunları diqqətlə formalaşdırmaq lazımdır.

Next.js-də ən sadə səhifə reallaşdırması

Gəlin tətbiqimizdə /legal/privacy səhifəsini yaradaq. App Router-də bu, sözün əsl mənasında bir fayldır:

// app/legal/privacy/page.tsx
export default function PrivacyPage() {
  return (
    <main className="mx-auto max-w-3xl p-8 prose">
      <h1>Privacy Policy – GiftGenius</h1>
      <p>Last updated: {new Date().toLocaleDateString()}</p>
      {/* burada siyasətin bölmələri gəlir */}
    </main>
  );
}

Bu nümunə qəsdən sadədir: məqsəd — statik URL-i sabitləməkdir. Real layihədə siyasət mətni demək olar ki, həmişə ayrıca saxlanılır (məsələn, .md faylında) və yüklənir ki, tonlarla mətni JSX-ə yaymayasınız.

Məsələn, tipik loader qura bilərsiniz:

// app/legal/privacy/page.tsx
import policyHtml from "./policy.html"; // əvvəlcədən yığılmış HTML

export default function PrivacyPage() {
  return (
    <main
      className="mx-auto max-w-3xl p-8 prose"
      dangerouslySetInnerHTML={{ __html: policyHtml }}
    />
  );
}

“Anlamadan bunu təkrarlamayın” tipli qeydlər burada yerinə düşür: dangerouslySetInnerHTML yalnız HTML mənbəyinə nəzarət etdiyiniz halda təhlükəsizdir (məsələn, onu CI-da markdown-dan özünüz build edirsiniz).

Real proseslərlə əlaqə

Ən vacibi: Policy-də sizdə kodda olmayanı yazmaq olmaz. Əgər bəyan edirsinizsə ki:

• sorğu mətnlərini 7 gündən çox saxlamırsınız;
• istifadəçinin tələbi ilə onun profilini tam silirsiniz;
• bu məlumatlardan öz modellərinizi öyrətmək üçün istifadə etmirsiniz,

o zaman sizdə bunlar olmalıdır:

• loglarda retention quraşdırmaları;
• istifadəçini silmək üçün endpoint və ya admin prosesi;
• “Data Science” üçün logları kənar saxlama yerinə axıdan kodun olmaması.

Və əksinə: əgər istifadəyə dair metrikaları, A/B sınaqlarını və ya ölkələr üzrə analitikanı qoşmusunuzsa, bunu Policy-də dürüst demək lazımdır. Və istifadəçiyə ən azı əsas hüquqları vermək: nə saxlanılır, necə silmək olar.

Məlumatlar və Privacy Policy ilə iş aydındır. İndi artıq təkcə məlumatların emalını deyil, “oyunun qaydalarını” da sabitləmək qalır — bu, Terms-in vəzifəsidir.

4. Terms of Use / Service: oyun qaydaları və AI diskleymerləri

Policy varsa, nəyə görə Terms də lazımdır

Privacy Policy “məlumatlarla nə edirsiniz” sualını cavablayır. Terms Of Use/Service (bundan sonra — Terms) isə “ümumiyyətlə App-dən hansı şərtlərlə istifadə etmək olar” sualına cavab verir. Bu, sizinlə istifadəçi arasında hüquqi müqavilədir.

Burada təsvir olunur:

• GiftGenius nədir və hansı funksiyaları təqdim edir;
• istifadəçinin hansı hərəkətləri məqbul, hansıları məqbul deyil;
• İA-nın “sehr sərhədləri” haradadır (AI diskleymerləri);
• sizin məsuliyyət məhdudiyyətləriniz;
• mübahisələr necə həll olunur və hansı yurisdiksiyada.

AI tətbiqləri üçün xüsusilə iki məqam vacibdir: dəqiqlik diskleymeri və məsuliyyətin məhdudlaşdırılması.

AI spesifikası: “model səhv edə bilər”

Bizim GiftGenius hədiyyə tövsiyələri verir. Bu, xoş və nisbətən təhlükəsizdir, amma burada belə büdrəmək olar: istifadəçi “fındıq allergiyası olan şəxs üçün hədiyyə” istədi, model uyğun olmayan bir şey generasiya etdi, insan zərər gördü — hamı narazıdır.

Aydındır ki, Terms bütün risklərdən bronjelet deyil, amma o, aydın şəkildə təsbit edir:

• nəticələri İA generasiya edir və onlar qeyri-dəqiq, köhnəlmiş və ya sadəcə qəribə ola bilər;
• istifadəçi mühüm məlumatları, xüsusən sağlamlıq, maliyyə və digər həssas sahələrə aid olanları müstəqil yoxlamalıdır;
• siz “ideal” tövsiyələrə dair heç bir zəmanət vermirsiniz və nəticədən təyinatına uyğun olmayan istifadə üçün məsuliyyət daşımırsınız.

Formulyasiyalar sonradan hüquqşünas tərəfindən cilalanmalıdır, amma texniki developer üçün ideyanı anlamaq vacibdir.

Commerce nüansları

Əgər App hər hansı ödəniş əməliyyatları edirsə (ACP və commerce haqqında modulu daha dərindən ayrıca keçirəcəyik, kursda bu nəzərdə tutulub), Terms-də diqqətlə təsvir etmək lazımdır:

• ödənişlər kim vasitəsilə keçir (Stripe, ACP, başqa sistem);
• ödənişlər barədə hansı məlumatları ümumiyyətlə görürsünüz;
• geri qaytarma və sifarişin ləğvi şərtləri hansılardır;
• nə konkret uğurlu tranzaksiya sayılır.

Platformanın ümumi tövsiyəsi — kart məlumatlarının sizin server tərəfindən deyil, ödəniş provayderi tərəfindən emal olunduğunu açıq göstərmək və yalnız minimumu saxlamaqdır (məsələn, tranzaksiya ID-si).

Next.js-də /legal/terms reallaşdırması

Texniki cəhətdən hər şey Privacy Policy-yə çox oxşardır. Səhifə yaradırıq:

// app/legal/terms/page.tsx
export default function TermsPage() {
  return (
    <main className="mx-auto max-w-3xl p-8 prose">
      <h1>Terms of Use – GiftGenius</h1>
      <p>Last updated: {new Date().toLocaleDateString()}</p>
      {/* bölmələr: xidmətin təsviri, məhdudiyyətlər, AI diskleymeri, məsuliyyət */}
    </main>
  );
}

Və, Policy-də olduğu kimi, mətni ayrıca faylda və ya CMS-də saxlamaq, kodda isə minimum işarələmə (markup) saxlamaq daha yaxşıdır.

Hüquqi səhifələr üçün ümumi “wrapper” çıxarmaq olar:

// app/legal/LegalLayout.tsx
export function LegalLayout(props: { title: string; children: React.ReactNode }) {
  return (
    <main className="mx-auto max-w-3xl p-8 prose">
      <h1>{props.title}</h1>
      <p>Last updated: {new Date().toLocaleDateString()}</p>
      {props.children}
    </main>
  );
}

Sonra onu həm Policy, həm də Terms üçün istifadə edirsiniz. Bu, “kod gözəlliyi” barədə deyil, yenilənmə tarixini qoymağı və vahid üslubu saxlamağı unutmayasınız deyədir.

5. Support / Contact: istifadəçi problemi ilə hara müraciət etməlidir

Minimum və “yaxşı ton”

OpenAI təlimatlarında göstərilir ki, App-in inkişaf etdiricilərlə dəstək mövzularında əlaqə saxlamağın anlaşılan yolu olmalıdır. Sadə email ola bilər, amma o, mövcud olmalı, məktubları qəbul etməli və heç olmasa bəzən cavablar alınmalıdır.

Tədris layihəsi üçün minimal variant:

• qısa təsvirli ayrıca /support səhifəsi və mailto:support@yourdomain.com.

Daha yetkin variant:

• əlaqə forması;
• sənədləşməyə və ya Help Center-ə keçid;
• mümkün — məhsul ətrafında icma qurursunuzsa, Slack/Discord-a keçid.

Next.js-də /support səhifəsi

Ən sadə variantdan başlayaq:

// app/support/page.tsx
export default function SupportPage() {
  return (
    <main className="mx-auto max-w-xl p-8 prose">
      <h1>GiftGenius Support</h1>
      <p>
        If you have issues or questions, email us at{" "}
        <a href="mailto:support@giftgenius.app">support@giftgenius.app</a>.
      </p>
    </main>
  );
}

Bir qədər daha irəli səviyyə — sadə forma əlavə etmək:

// app/support/page.tsx
"use client";

export default function SupportPage() {
  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();
    // burada məktub/tiket göndərəcək API çağırışı olacaq
  };

  return (
    <main className="mx-auto max-w-xl p-8 prose">
      <h1>GiftGenius Support</h1>
      <form onSubmit={handleSubmit}>
        <input name="email" placeholder="Your email" className="border p-2 w-full" />
        <textarea name="message" placeholder="How can we help?" className="border p-2 w-full mt-2" />
        <button type="submit" className="mt-4 px-4 py-2 border rounded">
          Send
        </button>
      </form>
    </main>
  );
}

Hətta bu formanın real backend-ni tədris layihəsində reallaşdırmasanız belə, aydın URL və səhifə strukturu artıq sizi Store tələblərinə yaxınlaşdırır.

İnsident menecmenti ilə əlaqə

Support səhifəsi təkcə “hər şey çökəndə hara yazmalı” deyil, həm də sizin əməliyyat mənzərənizin bir hissəsidir. Daha sonrakı modullarda App-in insidentləri və əməliyyat həyatı barədə danışacağıq. Orada Support səhifəsi istifadəçilər üçün “giriş qapısı” olacaq: buradan bug reportlar, suallar, məlumatların silinməsi tələbləri gəlir. İndi ən azı belə bir qapının mövcud olduğunu və “404 Not Found”a aparmadığını sabitləmək vacibdir.

6. Hüquqi səhifələrin tətbiqə və listing-ə inteqrasiyası

Layihə daxilində URL-lərin vahid konfiqurasiyası

Kod boyunca URL “sehrli sətirlərini” yaymamaq üçün sadə bir konfiqurasiya saxlamaq rahatdır:

// lib/appConfig.ts
export const legalLinks = {
  privacy: "https://giftgenius.app/legal/privacy",
  terms: "https://giftgenius.app/legal/terms",
  support: "https://giftgenius.app/support",
} as const;

Bu URL-lərdən istifadə edəcəksiniz:

• ChatGPT App ayarlarında (metadata);
• məhsulun landing səhifəsində;
• email bildirişlərini reallaşdırırsınızsa, məktublarda.

Widget daxilində istifadəçiyə bu səhifələrə sürətli çıxış verə bilərsiniz openExternal vasitəsilə.

// GiftGenius-in React widget-i daxilində
import { legalLinks } from "../lib/appConfig";

function FooterLinks() {
  const handleOpen = (url: string) => {
    window.openai?.openExternal({ url }); // Apps SDK helper
  };

  return (
    <footer className="mt-4 text-xs text-gray-500">
      <button onClick={() => handleOpen(legalLinks.privacy)}>Privacy</button>
      <span> · </span>
      <button onClick={() => handleOpen(legalLinks.terms)}>Terms</button>
    </footer>
  );
}

Real widget kodunda Apps SDK-dan useOpenExternal hook-unu istifadə etmək daha yaxşıdır; burada qısalıq üçün window.openai vasitəsilə birbaşa çağırış göstərilib.

Beləliklə, şəffaflığı artırırsınız: istifadəçi widget-dən bir kliklə hüquqi sənədlərə keçə bilər, onları Store-da axtarmalı olmaz.

İstifadəçi və reviewer axını

İnteraksiya axınına kiçik bir sxem şəklində baxaq:

flowchart TD
  A[ChatGPT Store-da App siyahısı səhifəsi] --> B[İstifadəçi App təsvirini oxuyur]
  B --> C[Linkdən Privacy / Terms açır]
  B --> D[Tətbiqi quraşdırır / istifadə etməyə başlayır]
  D --> E[GiftGenius widget-ni işə salır]
  E --> F["Lazım olduqda 'Support' və ya 'Privacy' düyməsini sıxır"]

ChatGPT Store reviewer-i də təxminən eyni yolu keçir, sadəcə bir az daha şübhə ilə. O, baxır:

• listing-də nə yazılıb;
• Policy və Terms nə vəd edir;
• App real ssenaridə necə davranır;
• davranış yazdıqlarınızla üst-üstə düşürmü.

Hər şey dürüst və proqnozlaşdırılandırsa — review-dan keçmə şansı kəskin artır.

7. Sizin App üçün praktiki tapşırıq

Nəzəriyyədə qalmamaq üçün elə indi tətbiqiniz üçün sənədlərin qaralamalarını hazırlamaq faydalıdır.

Yanaşma belə ola bilər.

Əvvəlcə arxitektura səviyyəsində təsvir edin:

• hansı məlumat kateqoriyalarını emal edirsiniz (sorğu mətni, sifarişlər, email, metrikalar);
• mətn sorğularını saxlayırsınızmı, saxlayırsınızsa — nə qədər;
• hansı xarici servislər qoşulub (hosting, baza, ödəniş, analitika).

Bundan sonra:

1. Privacy Policy üçün struktur tərtib edin: “nələri toplayırıq”, “nə üçün”, “hara ötürürük”, “nə qədər saxlayırıq”, “məlumatları necə silmək olar”.
2. Terms üçün struktur tərtib edin: xidmətin təsviri, istifadə qaydaları, məhdudiyyətlər (qadağan olunmuş kontent və sui-istifadələr), AI diskleymer, məsuliyyətin məhdudlaşdırılması, Policy-yə linklər.
3. Qısa mətn və email ilə /support səhifəsi hazırlayın.
4. Layihəyə hüquqi səhifələrin URL-ləri ilə lib/appConfig.ts əlavə edin və onları widget-də və istənilən xarici linklərdə istifadə edin.

Hətta mətnlər hələ tam qaralama olsa və “sonra bunu hüquqşünasa göstərəcəyinizi” planlaşdırır olsanız belə, artıq vacib işi görmüş olacaqsınız: texniki reallaşdırmanı hüquqi təsvirlə əlaqələndirəcəksiniz.

8. Hüquqi səhifələrə hazırlaşarkən tipik səhvlər

Səhv №1: internetdən random məxfilik siyasətini kopyalamaq və dəyişməmək.
Bəzən ilk tapılan məxfilik siyasətini götürüb məhsul adını dəyişmək və məsələni bitmiş saymaq istəyirsən. Problem ondadır ki, belə mətn demək olar ki, sizin arxitektura ilə üst-üstə düşmür. Burada sizdə olmayan mobil tətbiq, push bildirişləri və ya konkret analitika servisleri barədə bölmələr ola, əksinə — sizdə olan MCP serveri, alət logları və ChatGPT vasitəsilə iş barədə heç nə deyilə bilməz. Reviewer uyğunsuzluqları görəcək, istifadəçilər isə mətnin “başqası üçün” olduğunu hiss edəcəklər.

Səhv №2: Policy-də kodda reallaşdırılmayanı vəd etmək.
Klassik nümunə — “bütün məlumatlarınızı ilk tələb üzrə silirik” cümləsi, halbuki kodda nə silmə endpoint-i var, nə də konkret istifadəçinin məlumatlarını axtarma mexanizmi. Eyni şey logların saxlanma müddətinə və “mesajlarınızın mətnini saxlamırıq” cümlələrinə aiddir — əgər əslində tool‑input-u retention olmadan log sistemində saxlayırsınızsa. Belə uyğunsuzluq həm review, həm də real istifadəçilər üçün təhlükəlidir.

Səhv №3: Terms-də AI spesifikasını görməzdən gəlmək.
Əgər Terms-də cavabların model tərəfindən generasiya olunduğu və qeyri-dəqiq ola biləcəyi barədə heç nə yoxdursa, istifadəçi App-dən “son instansiyada həqiqət” səviyyəsini gözləyə bilər. Tövsiyə xidmətləri (hədiyyələr, səyahətlər, məhsul seçimi) üçün bu hələ dözümlüdür, amma tibb, maliyyə və hüquqi məsləhətlər üçün belə boşluq çox pis nəticələnə bilər. Məhdudiyyətləri və məsuliyyəti açıq və dürüst şəkildə demək daha yaxşıdır.

Səhv №4: real kontaktı olmayan və ya “ölü” ünvanlı Support səhifəsi.
/support səhifəsi, hansı ki, mailto:hello@example.com ünvanına aparır və ora heç kim heç vaxt baxmır, formal olaraq mövcuddur, amma faktiki faydasızdır. İstifadəçi geri dönüş almır, bug reportlar itir, App-in reputasiyası düşür. Platforma da şikayətlərə və problemlərə cavab verəcəyinizi gözləyir. Kiçik komanda olsanız belə, ən azı bir neçə gündən bir gələnləri gözdən keçirmək və reaksiya vermək vacibdir.

Səhv №5: sənədlərin tarixini və versiyasını unutmaq.
Bəzən hüquqi səhifələrdə ümumiyyətlə nə zaman yeniləndiyi göstərilmir. Reviewer üçün bu, narahatlıq siqnalıdır: sənədlərin məhsulun cari vəziyyətinə uyğun olub-olmadığı aydın deyil. Sadə “Last updated: …” bloku problemi həm sizin, həm istifadəçilər üçün həll edir və zamanla arxitekturanı və Policy/Terms mətnini təkmilləşdirirsinizsə, dəyişiklik tarixçəsini aparmağa kömək edir.