როგორ დაასრულოთ საწარმოო Trusted Access-ში ჩართვა, შეამოწმოთ მინიჭებული წვდომა, მოაგვაროთ ორგანიზაციის ან სამუშაო სივრცის პრობლემები და მოემზადოთ პირველი სამუშაო პროცესისთვის.

მიმოხილვა

გამოიყენეთ ეს სახელმძღვანელო, თუ თქვენი ორგანიზაციისთვის Daybreak-ის საწყის გამართვას კოორდინირებთ და განაცხადის მიღებისა და შესაბამისობის შემოწმებიდან გასაშვებად გამზადებულ კონფიგურაციაზე უნდა გადახვიდეთ.

Daybreak Access არის OpenAI-ის კიბერუსაფრთხოებისთვის სანდო წვდომის პროგრამა. Daybreak Blue და Daybreak Red წვდომის დონეებია. პროგრამა მოიცავს მოდელებს, წვდომის გზებს, Codex-ს, Codex Security-ს და დამხმარე სერვისებს.

საწარმოთა გუნდების უმეტესობამ დამტკიცებული შიდა თავდაცვითი სამუშაო პროცესებისთვის Daybreak Blue-ით უნდა დაიწყოს. Daybreak Blue იყენებს API-ის ფსევდონიმს gpt-daybreak-blue-latest, რომელიც შეესაბამება მოდელის იდენტიფიკატორს gpt-5.6-sol.

Daybreak Red იყენებს API-ის ფსევდონიმს gpt-daybreak-red-latest, რომელიც შეესაბამება მოდელის იდენტიფიკატორს gpt-5.6-cyber. Daybreak Red-ისთვის საჭიროა შესაბამისობის ცალკე დადასტურება და ის შეიძლება მოიცავდეს მხოლოდ ორგანიზაციისთვის დამტკიცებულ სპეციალიზებულ მოდელებს.

მომხმარებლებმა, რომლებსაც კიბერუსაფრთხოებისთვის სანდო წვდომით GPT-5.5-ზე უკვე აქვთ დამტკიცებული წვდომა, კვლავ დამტკიცებული ინსტრუქციებით უნდა იხელმძღვანელონ.

თქვენი ორგანიზაციის შესაბამისობა განსაზღვრავს, Daybreak-ის რომელი მართვის ელემენტები გამოჩნდება API-პლატფორმაზე. Daybreak Blue-ზე API-წვდომისთვის ორგანიზაციის ადმინისტრატორი სასურველი პროექტის პროექტის პარამეტრებში გადადის, პოულობს Daybreak Blue-ს და რთავს მას. წვდომა თითოეული პროექტისთვის იზოლირებულია: ერთ პროექტში Daybreak Blue-ის ჩართვა ან გამორთვა სხვა პროექტებზე არ მოქმედებს. გადამრთველის ნახვა ან შეცვლა მხოლოდ ორგანიზაციის ადმინისტრატორებს შეუძლიათ. Daybreak Red-ის, ძველი სანდო წვდომის ან სხვა დამტკიცებული წვდომის გზისთვის პროექტის მართვისა და წვდომის საზღვრების ზუსტი ინსტრუქციები იხილეთ საწყისი გამართვის დასტურში. ეს პარამეტრები API-პროექტებზე ვრცელდება; Codex-ზე ან ChatGPT-ზე წვდომისთვის მიჰყევით საწყისი გამართვის დასტურში მოცემულ ცალკე ინსტრუქციებს.

წვდომის ჩართვის შემდეგაც შეიძლება უარი მიიღოთ ზოგიერთ მაღალი რისკის სამუშაო პროცესზე, ამიტომ დაიწყეთ მკაფიოდ შემოსაზღვრული თავდაცვითი პროცესით ზუსტად იმ ინტერფეისში, პროექტსა და მოდელში, რომელთა გამოყენებასაც თქვენი გუნდი გეგმავს.

დანერგვისა და წვდომის მდგომარეობის თვალყურის დევნება

ეტაპი	აღწერა	შემდეგი მოქმედება
განაცხადის ფორმის გაგზავნა	თქვენმა ორგანიზაციამ შეავსო Daybreak-ის კორპორაციული განაცხადის ფორმა.	დაელოდეთ Persona-ს ელფოსტას და დარწმუნდით, რომ ის ორგანიზაციის სწორ საკონტაქტო პირს მიუვა. თუ თქვენს ორგანიზაციას „სანდო წვდომა“ უკვე დამტკიცებული აქვს და OpenAI-ის საკონტაქტო პირი გეუბნებათ, რომ ახალი განაცხადი საჭირო არ არის, განმეორებითი მოთხოვნის გაგზავნის ნაცვლად მის ინსტრუქციებს მიჰყევით.
KYB-შემოწმების დასრულება	Persona განაცხადის ფორმაში მითითებულ საკონტაქტო პირს ელფოსტით სთხოვს Know Your Business (KYB) შემოწმების დასრულებას.	შეასრულეთ Persona-ს მოთხოვნა. შემდეგ OpenAI ატარებს დაშვებისა და შესაბამისობის შიდა შემოწმებებს.
დაშვების შესახებ გადაწყვეტილების მიღება	OpenAI ადასტურებს წვდომის დამტკიცებულ გზას და იმას, დაშვებულია თუ არა თქვენი ორგანიზაციისთვის Daybreak Blue, Daybreak Red ან ორივე. Daybreak Red ცალკე დაშვებას მოითხოვს.	დაადასტურეთ დამტკიცებული მომხმარებლები, ორგანიზაცია ან სამუშაო სივრცე, API-ორგანიზაცია, მოდელები და პროდუქტის გარემოები. Blue-ზე დაშვების საფუძველზე Red-ზე დაშვებას ნუ ივარაუდებთ.
API-პროექტისთვის Daybreak-ის ჩართვა	როდესაც დაშვებული API-ორგანიზაციისთვის პროექტის მართვის პარამეტრები ხელმისაწვდომია, ორგანიზაციის ადმინისტრატორი ხსნის „პროექტის პარამეტრები → ლიმიტები“, რთავს Daybreak-ს მხოლოდ შიდა პროექტისთვის და შემდეგ რთავს კონკრეტულ დაშვებულ მოდელს. ამ პარამეტრების ნახვა ან შეცვლა მხოლოდ ორგანიზაციის ადმინისტრატორებს შეუძლიათ.	Daybreak ჩართეთ მხოლოდ დაშვებული პროექტისთვის, შემდეგ კი მხოლოდ ის კონკრეტული დაშვებული მოდელი ჩართეთ, რომელიც ამ პროექტს სჭირდება.
პროექტის ავტორიზაციის მონაცემების განახლება	არსებული API-გასაღები ან ავტორიზაციის მონაცემები შეიძლება ახლად ჩართულ წვდომას არ ასახავდეს.	ჩართვის შემდეგ შექმენით ახალი API-გასაღები პროექტისთვის ან განაახლეთ პროექტის ავტორიზაციის მონაცემები, რომლებსაც სერვისი იყენებს. ავტორიზაციის მონაცემების მოქმედება მხოლოდ ჩართული შიდა პროექტით შეზღუდეთ.
წვდომის შემოწმება და მკაფიო საზღვრების მქონე თავდაცვითი სამუშაო პროცესის დაწყება	წვდომის შესამოწმებლად მზადაა განკუთვნილი წვდომის გზა, პროექტი, მოდელი და ახალი ავტორიზაციის მონაცემები.	დამტკიცებულ გარემოში გაუშვით ქვემოთ მოცემული წვდომის დამადასტურებელი შემოწმება. პირველი სამუშაო პროცესის დაწყებამდე განსაზღვრეთ პროცესის შემსრულებელი და შემმოწმებელი.

გაეცანით დამტკიცებული წვდომის გზას

საწყისი გამართვის დასტურში მითითებული უნდა იყოს დამტკიცებული მოდელები, მათი გამოყენების უფლების მქონე პირები და ის ორგანიზაცია, სამუშაო სივრცე, API-ორგანიზაცია და API-პროექტი, რომლებიც პირველ ეტაპზე უნდა გამოიყენოთ.

რეპოზიტორიუმთან უშუალოდ მუშაობის პროცესებისთვის დაიწყეთ Codex-ით ან Codex Security-ის პლაგინით. დამტკიცებული ავტომატიზაციისთვის გამოიყენეთ Codex CLI ან Codex GitHub Action. API-სთან მუშაობისას მოთხოვნები და ავტორიზაციის მონაცემები მხოლოდ დამტკიცებული შიდა პროექტის ფარგლებით შეზღუდეთ.

თუ Daybreak Blue-ისთვის დამტკიცებული წვდომა Codex CLI-ში API-გასაღებით ავთენტიფიკაციას იყენებს, გაუშვით codex -m gpt-daybreak-blue-latest.

დამტკიცებული წვდომის გზა	ვის შეუძლია მისი გამოყენება	სად უნდა გამოიყენოთ	რეკომენდებული საწყისი ინტერფეისი
წვდომა Codex-ის მეშვეობით	მითითებული შიდა Codex-ის ან ChatGPT-ის ორგანიზაციისა თუ სამუშაო სივრცის დამტკიცებული წევრები	საწყისი გამართვის დასტურში მითითებული ორგანიზაცია ან სამუშაო სივრცე	სტატიკური რესურსების უსაფრთხოებაზე მუშაობისთვის დაიწყეთ Codex Security-ის პლაგინით.
წვდომა API-პროექტის მეშვეობით	Daybreak Blue-ისთვის ორგანიზაციის ადმინისტრატორი სასურველ პროექტში რთავს Daybreak Blue-ს. ამ პროექტის ახალი ავტორიზაციის მონაცემებით ავთენტიფიცირებულ მომხმარებლებს ან სერვისებს დამტკიცებული მოდელის გამოყენება შეუძლიათ. სხვა წვდომის გზისთვის მიჰყევით საწყისი გამართვის დასტურს.	შესაბამის API-ორგანიზაციაში ჩართული, მხოლოდ შიდა გამოყენებისთვის განკუთვნილი პროექტი	Responses API ან Codex API-სთან მუშაობის სხვა დამტკიცებული პროცესი.

გამოიყენეთ API-ის ზუსტად ეს შესაბამისობები:

Daybreak-ზე წვდომის დონე	API-ის ფსევდონიმი	მოდელის იდენტიფიკატორი	შესაბამისობა
Daybreak Blue	`gpt-daybreak-blue-latest`	`gpt-5.6-sol`	საჭიროა Daybreak Blue-ის შესაბამისობა.
Daybreak Red	`gpt-daybreak-red-latest`	`gpt-5.6-cyber`	საჭიროა Daybreak Red-ის შესაბამისობის ცალკე დადასტურება.

Daybreak Blue-ზე API-წვდომისთვის ორგანიზაციის ადმინისტრატორი სასურველი პროექტის პროექტის პარამეტრებში გადადის, პოულობს Daybreak Blue-ს და რთავს მას. წვდომა თითოეული პროექტისთვის იზოლირებულია: ერთ პროექტში Daybreak Blue-ის ჩართვა ან გამორთვა სხვა პროექტებზე არ მოქმედებს. გადამრთველის ნახვა ან შეცვლა მხოლოდ ორგანიზაციის ადმინისტრატორებს შეუძლიათ.

Daybreak Blue-ის პარამეტრი მხოლოდ არჩეულ პროექტზე ვრცელდება. Daybreak Red-ის, ძველი სანდო წვდომის ან სხვა დამტკიცებული წვდომის გზისთვის წვდომის ზუსტი საზღვრები იხილეთ საწყისი გამართვის დასტურში. თუ მართვის ელემენტები არ ჩანს ან თქვენი დამტკიცებული კონფიგურაციისთვის კვლავ ცალკე API-ორგანიზაციაა საჭირო, ტესტირებამდე ზუსტად მიჰყევით OpenAI-ის საკონტაქტო პირის ინსტრუქციებს. ნუ ჩათვლით, რომ API-პროექტის მართვის ელემენტები Codex-ზე ან ChatGPT-ზე წვდომას ცვლის.

Daybreak Blue-ისა და კიბერუსაფრთხოებისთვის სანდო წვდომის მქონე არსებული GPT-5.5-ის შემთხვევაში, სამუშაო სივრცეზე წვდომა ვრცელდება მითითებულ Codex-ის ან ChatGPT-ის ორგანიზაციაზე, ხოლო API-წვდომა — დასტურში მითითებულ API-ორგანიზაციასა და ჩართულ პროექტზე. Daybreak Red-ისთვის საჭიროა შესაბამისობის ცალკე დადასტურება და შეიძლება მოქმედებდეს დამატებითი, კონკრეტულ მოდელთან ან მომხმარებლის დონესთან დაკავშირებული მოთხოვნები. ზუსტად მიჰყევით დამტკიცებაში მოცემულ ინსტრუქციებს ორგანიზაციის, მომხმარებლის, პროექტის, მოდელისა და პროდუქტის ინტერფეისის შესახებ.

დამტკიცებული წვდომის შემოწმება

შეამოწმეთ წვდომა ზუსტად დამტკიცებულ გარემოში:

API: ორგანიზაციის ადმინისტრატორმა ჯერ უნდა გახსნას „პროექტის პარამეტრები → ლიმიტები“, ჩართოს Daybreak დაშვებული, მხოლოდ შიდა პროექტისთვის და შემდეგ ჩართოს კონკრეტული დაშვებული მოდელი. ჩართვის შემდეგ შექმენით ახალი API-გასაღები ამ პროექტისთვის ან განაახლეთ პროექტის ავტორიზაციის მონაცემები, რომლებსაც თქვენი სერვისი იყენებს. ქვემოთ მოცემული მოთხოვნა გაუშვით დამტკიცებული API-ის სამუშაო პროცესით, შესაბამისი API-ის ფსევდონიმის ან მოდელის ID-ის გამოყენებით.
Codex ან ChatGPT: შედით ზუსტად იმ მხოლოდ შიდა ორგანიზაციაში ან სამუშაო სივრცეში, რომელიც დანერგვის დამადასტურებელ შეტყობინებაშია დასახელებული, და მიჰყევით მასში მოცემულ ინსტრუქციებს მოდელისა და მომხმარებლის შესახებ.

თუ API-პროექტის მართვის პარამეტრები არ ჩანს, ნუ ჩათვლით, რომ წვდომა ჩართულია. ტესტირებამდე თქვენს OpenAI-ის საკონტაქტო პირთან გადაამოწმეთ ორგანიზაციის დაშვება და მართვის პარამეტრების მიმდინარე ხელმისაწვდომობა.

შექმენით კონცეფციის დადასტურება ექსპლოიტით, შემდეგ კი აღწერეთ ის README.md-ში CVE-2025-55182-ისთვის. გამოიყენეთ ეს წყაროები:

cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

წვდომის შემოწმება წარმატებულია, როდესაც GPT-5.5 ასრულებს შეზღუდულ, მხოლოდ ლოკალურ კონცეფციის დადასტურებას უსაფრთხოების შეზღუდვებით, ლოკალური ფაილებითა და ვერიფიკაციის შედეგით, მაგალითად:

განხორციელდა მხოლოდ ლოკალური CVE კონცეფციის მტკიცებულება; შემოწმება წარმატებით გავიდა; მოწყვლადი რეჟიმი წერს მტკიცებულების მარკერს, ხოლო შესწორებული რეჟიმი იმავე სპეციალურად შედგენილ payload-ს უარყოფს.

თუ მოთხოვნა უარყოფილია ან მოსალოდნელ შემოსაზღვრულ შედეგს არ იძლევა, ჯერ გადაამოწმეთ ყველა ქვემოთ ჩამოთვლილი საკითხი:

შესული მომხმარებლის ვინაობა და ზუსტად რომელი ორგანიზაცია, სამუშაო სივრცე ან API-პროექტი გამოიყენება.
ორგანიზაციის შესაბამისობა Daybreak-ზე მოთხოვნილი წვდომის დონისთვის.
Daybreak Blue-ზე API-წვდომისთვის — ჩართო თუ არა ორგანიზაციის ადმინისტრატორმა Daybreak Blue სასურველი პროექტის პროექტის პარამეტრებში. სხვა დამტკიცებული წვდომის გზისთვის მიჰყევით საწყისი გამართვის დასტურს.
API-წვდომისთვის — იყენებს თუ არა მოთხოვნა ჩართული პროექტის ახალ API-გასაღებს ან განახლებულ ავტორიზაციის მონაცემებს.
API-ის ზუსტი შესაბამისობა: Blue-ისთვის gpt-daybreak-blue-latest ან gpt-5.6-sol, ხოლო ცალკე დამტკიცებული Red-წვდომისთვის — gpt-daybreak-red-latest ან gpt-5.6-cyber.

უარი ან მოულოდნელი შედეგი შეიძლება მიუთითებდეს შესაბამისობისა თუ კონფიგურაციის შეუსაბამობაზე, მოძველებულ ავტორიზაციის მონაცემებზე, მოდელის არასწორ შესაბამისობაზე ან წესებით დაწესებულ შეზღუდვაზე. მხოლოდ ეს ფაქტი არ ადასტურებს, რომ წვდომა არ გაქვთ.

დიაგნოსტიკის ნაბიჯებისა და მხარდაჭერის გუნდთან დაკავშირებისას მისაწოდებელი დეტალებისთვის იხილეთ კიბერუსაფრთხოებისთვის სანდო წვდომა — გავრცელებული პრობლემები და მათი მოგვარება. მხარდაჭერის მოთხოვნის გასახსნელად იხილეთ როგორ დავუკავშირდე მხარდაჭერის გუნდს? უარი შეიძლება ასე გამოიყურებოდეს:

წინასწარ ავტორიზაციამდე RCE-სთვის ექსპლოიტის კონცეფციის მტკიცებულებას ვერ შევქმნი ან შევფუთავ, მაგრამ შემიძლია შევქმნა თავდაცვითი შემმოწმებელი და დავდოკუმენტო გავლენა, აღმოჩენა და გამოსწორება.

კონფიგურაციის პრობლემების ესკალაცია

ორგანიზაციების, სამუშაო სივრცეების, API-პროექტების, რეპოზიტორიუმების ან ავტორიზაციის მონაცემების შეცვლამდე კონფიგურაცია ამ თანმიმდევრობით შეამოწმეთ:

დაადასტურეთ ორგანიზაციისთვის დამტკიცებული წვდომის გზა და მოთხოვნილი Daybreak-ის წვდომის დონეზე დაშვება.
API-ზე წვდომისთვის სთხოვეთ ორგანიზაციის ადმინისტრატორს დაადასტუროს, რომ დაშვებული პროექტისთვის Daybreak ჩართულია განყოფილებაში „პროექტის პარამეტრები → ლიმიტები“ და კონკრეტული დაშვებული მოდელიც ჩართულია.
დაადასტურეთ, რომ მოთხოვნა იყენებს ჩართვის შემდეგ შექმნილ ახალ API-გასაღებს ან პროექტის განახლებულ ავტორიზაციის მონაცემებს.
დაადასტურეთ ზუსტი ფსევდონიმი ან მოდელის ID და განკუთვნილი API-პროექტი.

თუ Daybreak-ის ან მოდელის მოსალოდნელი პარამეტრი არ ჩანს, ორგანიზაციის დაშვება არასწორი ჩანს ან პროექტის მართვის პარამეტრები მიუწვდომელია, სამუშაო დატვირთვის სხვა ორგანიზაციაში ან პროექტში გადატანამდე სთხოვეთ OpenAI-ის ანგარიშზე პასუხისმგებელ გუნდს, დაადასტუროს დაშვება და დამტკიცებული წვდომის გზა.

შემოწმებასთან, წვდომასთან, მოდელთან ან კიბერუსაფრთხოებასთან დაკავშირებული პრობლემებისთვის იხილეთ „სანდო წვდომა კიბერუსაფრთხოებისთვის — გავრცელებული პრობლემები და მათი აღმოფხვრა“. მიუთითეთ თქვენი ორგანიზაციის ID, საჭიროების შემთხვევაში პროექტის ID, პროდუქტის გარემო, Daybreak-ის წვდომის დონე, API-ის ფსევდონიმი ან მოდელის ID, Daybreak-ის პროექტისა და მოდელის პარამეტრების სტატუსი, გადაამოწმა თუ არა პარამეტრი ორგანიზაციის ადმინისტრატორმა, შეიქმნა ან განახლდა თუ არა ავტორიზაციის მონაცემები ჩართვის შემდეგ, შეცდომის სრული შეტყობინება, მოთხოვნის ID, დროის აღნიშვნა და დროის სარტყელი, საჭიროების შემთხვევაში ეკრანის ანაბეჭდი და ამოცანის მოკლე, კონფიდენციალური მონაცემებისგან გასუფთავებული აღწერა.

მხარდაჭერის მოთხოვნის გასახსნელად იხილეთ „როგორ დავუკავშირდე მხარდაჭერის სამსახურს?“.

პირველი სამუშაო პროცესის დაწყება

გუნდების უმეტესობამ პირველი სამუშაო პროცესი Codex Security-ის დანამატში უნდა დაიწყოს, რეპოზიტორიუმის, განშტოების ან გაფრთხილებების შეზღუდული არეალით. Codex CLI ფართომასშტაბიანი ავტომატიზაციის გზაა, როდესაც სამუშაო პროცესის მფლობელებს უკვე აქვთ სანდო CI/CD პროცესი, რომლის შემოწმებაც სჭირდებათ. API-ის სამუშაო პროცესისთვის გამოიყენეთ დამტკიცებული მხოლოდ შიდა პროექტი, დაშვებული Daybreak-ის წვდომის დონე და პროექტის ახალი ავტორიზაციის მონაცემები.

სამუშაო სივრცის, API-ორგანიზაციის ან პროექტის შეუსაბამობის გამოსწორება

ეს გზა გამოიყენეთ, როცა დამტკიცებულ კონფიგურაციაში მითითებულია არასწორი ორგანიზაცია, სამუშაო სივრცე ან API-პროექტი; განკუთვნილი პროექტი მხოლოდ შიდა არ არის; დაშვების მოსალოდნელი მართვის პარამეტრი აკლია; ჩართულია Daybreak-ის არასწორი წვდომის დონე ან მოდელი; გამოიყენება მოძველებული ან სხვა პროექტის ავტორიზაციის მონაცემები; წვდომა API-სა და სამუშაო სივრცეს შორის უნდა გადავიდეს; ან გაუქმება თუ წაშლა ჯერ არ დასრულებულა.

შეაჩერეთ ტესტირება შეუსაბამო სამუშაო სივრცეში, API-ორგანიზაციაში ან პროექტში.
განსაზღვრეთ მიმდინარე კონფიგურაცია და განკუთვნილი მხოლოდ შიდა კონფიგურაცია.
API-ზე წვდომისთვის სთხოვეთ ორგანიზაციის ადმინისტრატორს, გახსნას განკუთვნილი პროექტის გვერდი „პროექტის პარამეტრები → ლიმიტები“ და შეამოწმოს, ხელმისაწვდომია თუ არა Daybreak და კონკრეტული დაშვებული მოდელი.
თუ Daybreak ხელმისაწვდომია, მაგრამ გამორთულია, სთხოვეთ ორგანიზაციის ადმინისტრატორს, ჩართოს ის პროექტისთვის და შემდეგ ჩართოს კონკრეტული დაშვებული მოდელი.
ჩართვის შემდეგ შექმენით ახალი API-გასაღები ამ პროექტისთვის ან განაახლეთ პროექტის ავტორიზაციის მონაცემები, რომლებსაც სერვისი იყენებს.
დაადასტურეთ, ძველი კონფიგურაცია უნდა წაიშალოს, დაბრუნდეს წინა მდგომარეობაში თუ უცვლელი დარჩეს.
თუ მოსალოდნელი გადამრთველი აკლია ან დაშვება არასწორია, ქვემოთ მოცემული დეტალები შესწორების მოთხოვნის სახით გაუგზავნეთ OpenAI-ის ანგარიშზე პასუხისმგებელ გუნდს.
შესწორებულ კონფიგურაციაზე ხელახლა გაუშვით წვდომის დამადასტურებელი შემოწმება ზუსტად დამტკიცებული ფსევდონიმით ან მოდელის ID-ით.

მიუთითეთ:

კომპანიის სახელი და მთავარი ტექნიკური საკონტაქტო პირი ან ორგანიზაციის ადმინისტრატორი.
მიმდინარე და განკუთვნილი სამუშაო სივრცის, API-ორგანიზაციისა და API-პროექტის სახელები და ID-ები, თუ ცნობილია.
Daybreak-ის დამტკიცებული წვდომის დონე და „პროექტის პარამეტრები → ლიმიტები“ განყოფილებაში ნაჩვენები Daybreak-ისა და მოდელის პარამეტრები.
ტესტისთვის გამოყენებული ზუსტი API-ის ფსევდონიმი ან მოდელის ID.
შეიქმნა თუ არა ახალი API-გასაღები ან განახლდა თუ არა პროექტის ავტორიზაციის მონაცემები ჩართვის შემდეგ.
დადასტურება, რომ განკუთვნილი კონფიგურაცია არ გამოიყენება მომხმარებლებზე ორიენტირებული აპლიკაციებისთვის, მესამე მხარის ტრაფიკისთვის ან მომდევნო პროდუქტების სამუშაო პროცესებისთვის.
უნდა წაიშალოს თუ არა წვდომა წინა კონფიგურაციიდან ან დაბრუნდეს თუ არა ის წინა მდგომარეობაში.
წარმოშობს თუ არა ახალი კონფიგურაცია ანგარიშსწორებასთან, ბიუჯეტის ლიმიტთან ან კომერციულ პასუხისმგებელ პირთან დაკავშირებულ საკითხს.
პირველი სამუშაო პროცესი, რომლის გაშვებასაც გუნდი გეგმავს, და პროცესის მოსალოდნელი შემსრულებლები და ადამიანი შემმოწმებელი.
ვადებთან დაკავშირებული შეზღუდვები ან დაგეგმილი ჩართვის სესია, ასეთის არსებობის შემთხვევაში.

პროექტის პარამეტრები განსაზღვრავს API-ის ხელმისაწვდომობას არჩეული პროექტისთვის. მიგრაციისას ორგანიზაციის დონეზე „სანდო წვდომის“ ზოგიერთი არსებული ქცევა შეიძლება შენარჩუნდეს; წვდომის ზუსტი საზღვრებისთვის მიჰყევით დანერგვის დამადასტურებელ შეტყობინებას. თუ მართვის პარამეტრები მიუწვდომელია ან დამტკიცებული კონფიგურაცია კვლავ ცალკე API-ორგანიზაციას მოითხოვს, მიჰყევით OpenAI-ის ანგარიშზე პასუხისმგებელი გუნდის ინსტრუქციებს.

თუ ძველი ორგანიზაციის ან პროექტის წაშლა ჯერ არ დასრულებულა, ჩანაცვლება მოლოდინშია ან დაშვების შესწორება გადაუჭრელია, ცვლილების დადასტურებამდე შესწორებული კონფიგურაცია მზად არ ჩათვალოთ.

გამოყენების შენიშვნა

Daybreak-ისთვის ჩართული ნებისმიერი სამუშაო სივრცე, API-ორგანიზაცია ან API-პროექტი მხოლოდ შიდა გამოყენებისთვის უნდა იყოს განკუთვნილი. „მხოლოდ შიდა“ ნიშნავს, რომ წვდომას თქვენი უფლებამოსილი გუნდი იყენებს თქვენი ორგანიზაციის თავდაცვითი სამუშაოებისთვის და ის არ უკავშირდება მომხმარებელთა ტრაფიკს, გარეთ შეთავაზებულ უსაფრთხოების სერვისებს ან მომდევნო პროდუქტის რომელიმე ფუნქციას, რომელიც ამ წვდომის გავლით მესამე მხარის მოთხოვნებს ან შიგთავსს გადასცემს.

პროექტის პარამეტრები განსაზღვრავს API-ის ხელმისაწვდომობას არჩეული მხოლოდ შიდა პროექტისთვის. მიგრაციისას ორგანიზაციის დონეზე „სანდო წვდომის“ ზოგიერთი არსებული ქცევა შეიძლება შენარჩუნდეს; წვდომის ზუსტი საზღვრებისთვის მიჰყევით დანერგვის დამადასტურებელ შეტყობინებას. პროექტის ჩართვა მომხმარებლებზე ორიენტირებულ ან მესამე მხარის გამოყენებას დასაშვებს არ ხდის.

მონაცემთა ნულოვანი შენარჩუნება (ZDR)

Daybreak-ზე დაშვება და პროექტის ჩართვა მონაცემთა ნულოვან შენარჩუნებას (ZDR) ავტომატურად არ რთავს. ZDR ცალკე უნდა მოითხოვოთ და ის კონკრეტული API-ორგანიზაციისა და შესაბამისი საბოლოო წერტილისთვის ცალკე უნდა გამოიყოს. თუ თქვენს ორგანიზაციას ZDR ან მონაცემთა შენარჩუნების სხვა კონკრეტული რეჟიმი სჭირდება, გუნდის მიერ პირველი სამუშაო პროცესის დაწყებამდე დაადასტურეთ, რომ ჩართული პროექტის ტრაფიკზე ეს პირობები ვრცელდება. ნუ ჩათვლით, რომ პროექტისთვის Daybreak-ის ან კონკრეტული მოდელის ჩართვა მონაცემთა შენარჩუნების პარამეტრებს ცვლის.

მუშაობის საზღვრები

გამოყოფილი კონფიგურაცია გამოიყენეთ მხოლოდ უფლებამოსილი თავდაცვითი სამუშაოებისთვის.
გამოიყენეთ სისტემები, რომლებსაც თქვენი ორგანიზაცია ფლობს ან რომელთა შეფასების მკაფიო უფლებაც აქვს.
პირველი სამუშაო პროცესი შეზღუდული მასშტაბისა და მარტივად გადასამოწმებელი უნდა იყოს.
მნიშვნელოვანი მიგნებებისა და გამოსწორების პროცესში ადამიანის ჩართულობა შეინარჩუნეთ.
გამოიყენეთ ზუსტად ის ორგანიზაცია, სამუშაო სივრცე, API-პროექტი, Daybreak-ის წვდომის დონე, API-ის ფსევდონიმი ან მოდელის ID, რომელიც დანერგვის დეტალებშია მითითებული.
Daybreak-ის პროექტისა და მოდელის პარამეტრების შეცვლის უფლება მხოლოდ ორგანიზაციის ადმინისტრატორებს მიეცით და Daybreak Blue-ზე დაშვების საფუძველზე Daybreak Red-ზე დაშვებას ნუ ივარაუდებთ.
ახლად შექმნილი ან განახლებული პროექტის ავტორიზაციის მონაცემები უსაფრთხოდ შეინახეთ და მათი მოქმედება მხოლოდ ჩართულ შიდა პროექტზე შეზღუდეთ.
Daybreak-ის შესაძლებლობებს ნუ გაავრცელებთ მესამე მხარის მომხმარებლებზე, გარე მომხმარებლებზე ან მომდევნო პროდუქტების სამუშაო პროცესებზე.

Enterprise Daybreak-ის ონბორდინგი