24 Eki 2025·8 dk
AI Prototiplerini Üretime Hazır Sistemlere Taşımanın Yolu
AI prototiplerini üretime taşıma konusunda pratik rehber: hedef belirleme, veri, değerlendirme, mimari, güvenlik, izleme ve kademeli dağıtım adımları.
AI prototiplerini üretime taşıma konusunda pratik rehber: hedef belirleme, veri, değerlendirme, mimari, güvenlik, izleme ve kademeli dağıtım adımları.
Bir prototip tek bir soruyu yanıtlamak için yapılır: “Bu işe yarar mı?” Üretim sistemi ise farklı bir dizi soruyu yanıtlamalıdır: “Bu her gün, çok sayıda kullanıcı için, kabul edilebilir bir maliyetle ve net sorumlulukla çalışır mı?” İşte bu fark, AI prototiplerinin demo sırasında parlamasına ama lansmandan sonra tökezlemesine neden olur.
Prototipler genellikle ideal koşullar altında çalışır: küçük, elle seçilmiş bir veri seti, tek bir ortam ve sorunları sessizce düzelten bir kişi. Bir demoda gecikme sıçramaları, eksik alanlar veya ara sıra yanlış bir yanıt mazur görülebilir. Üretimde bu sorunlar destek biletleri, müşteri kaybı ve risk olur.
Üretime hazır AI daha iyi bir modelden çok, öngörülebilir operasyonlarla ilgilidir:
Ekipler genellikle şu konularda şaşırır:
Tekrarlanabilir bir geçiş planı ile ayrılacaksınız: başarıyı nasıl tanımlayacağınız, veriyi nasıl hazırlayacağınız, ölçeklemeden önce nasıl değerlendireceğiniz, üretim mimarisini nasıl seçeceğiniz, maliyet/gecikmeyi nasıl planlayacağınız, güvenlik beklentilerini nasıl karşılayacağınız, insan denetimini nasıl tasarlayacağınız, performansı nasıl izleyeceğiniz ve güvenli bir şekilde nasıl dağıtım yapacağınız—böylece bir sonraki prototipiniz tek seferlik bir demo olarak kalmaz.
Bir prototip “yeterince iyi” hissi verebilir çünkü demo iyi görünür. Üretim farklıdır: AI’nın ne için olduğu, ne olmadığı ve başarıyı nasıl ölçeceğiniz konusunda paylaşılmış, test edilebilir bir anlaşmaya ihtiyacınız var.
AI’nın tam olarak hangi anda kullanıldığını ve öncesinde/sonrasında ne olduğunu tanımlayın. Kim isteği tetikliyor, çıktıyı kim tüketiyor ve hangi karar(lar)ı/davranışı destekliyor?
Somut tutun:
Beş dakikada iş akışını çizemiyorsanız, kapsam hazır değildir.
AI’yı işin zaten önem verdiği bir sonuca bağlayın: daha az destek süreleri, daha hızlı belge incelemesi, daha yüksek lead kalifikasyonu, azaltılmış kaçak defektler vb. “AI kullanarak modernize et” gibi ölçülemeyen hedeflerden kaçının.
Kullanışlılığı gerçek dünya kısıtlarıyla dengede tutan küçük bir metrik seti seçin:
İhlal edilemeyecek kısıtları yazın: çalışma süresi hedefi, kabul edilebilir hata modları, gizlilik limitleri (hangi verilerin gönderilip gönderilemeyeceği) ve yükseltme gereksinimleri.
Sonra basit bir v1 kontrol listesi oluşturun: hangi kullanım durumları dahil, hangileri açıkça kapsama girmez, minimum metrik eşikleri neler ve hangi kanıtları kabul edeceksiniz (panolar, test sonuçları, onay). Bu, sonraki her karar için dayanak noktanız olur.
Bir prototip küçük, elle seçilmiş bir veri setiyle etkileyici görünebilir. Üretim farklıdır: veri sürekli akar, birden fazla sistemden gelir ve “dağınık” vakalar norm olur. Her şeyi ölçeklemeden önce hangi veriyi kullanacağınızı, nereden geldiğini ve çıktıdan kimin etkilendiğini açıkça belirtin.
Başlarken tam zinciri listeleyin:
Bu harita sahipliği, gerekli izinleri ve her tüketici için “iyi” çıktının ne anlama geldiğini netleştirir.
Ne saklayabileceğinizi, ne kadar süreyle ve neden saklayacağınızı yazın. Örneğin: hata ayıklama için istek/yanıt çiftlerini saklayın, ancak sınırlı bir saklama süresiyle; trend analizi için toplanmış metrikleri daha uzun saklayın. Depolama planınızın gizlilik beklentileri ve iç politika ile eşleştiğinden emin olun ve ham veriye kimlerin erişebileceği ile anonim örneklere kimlerin erişeceğini tanımlayın.
Otomatize edilebilen hafif bir kontrol listesi kullanın:
Sonuçlar değişirse neyin değiştiğini bilmeniz gerekir. Veri setlerinizi (anlık görüntüler veya hashler), etiketleme kurallarını ve prompt/şablonları versiyonlayın. Her model sürümünü, kullanılan tam veri ve prompt sürümüyle ilişkilendirin ki değerlendirmeler ve olay incelemeleri tekrarlanabilir olsun.
Prototip demoları genellikle “iyi hissettirir” çünkü mutlu yollar test edilir. Gerçek kullanıcıya ölçeklemeden önce kaliteyi ölçmenin tekrarlanabilir bir yoluna ihtiyacınız var ki kararlar hislere dayanmasın.
Önce istediğiniz zaman çalıştırabileceğiniz offline testler ile başlayın (her sürümden önce), sonra sistem canlıyken çevrimiçi sinyalleri ekleyin.
Offline testler şu soruyu yanıtlar: Bu değişiklik modelimizi ilgilendiğimiz görevlerde daha iyi mi yoksa daha kötü mü yaptı? Çevrimiçi sinyaller ise: Kullanıcılar başarılı oluyor mu ve sistem gerçek trafikte güvenli davranıyor mu?
Gerçek kullanımı yansıtan, tipik istekleri, en sık kullanılan iş akışlarını ve beklenen formatta çıktıları içeren küratörlü bir set oluşturun. İlk başta kasıtlı olarak küçük tutun (ör. 50–200 öğe) ki bakım kolay olsun.
Her öğe için “iyi”nin ne olduğunu tanımlayın: referans cevap, puanlama rubriği veya kontrol listesi (doğruluk, bütünlük, ton, atıf vb.). Amaç tutarlılıktır—iki kişi aynı çıktıyı benzer şekilde puanlamalıdır.
Üretimi bozma olasılığı yüksek testleri dahil edin:
Önceden neyin kabul edilebilir olduğunu kararlaştırın: minimum doğruluk, maksimum uydurma (hallucination) oranı, güvenlik geçiş oranı, gecikme bütçesi ve istek başı maliyet. Ayrıca anında geri alma tetiklerini tanımlayın (ör. güvenlik hatası X% üzerine çıkarsa, kullanıcı şikayetlerinde ani artış veya görev başarısında düşüş).
Bunlarla birlikte her sürüm kontrollü bir deney olur—şans işi değil.
Prototip genellikle her şeyi tek bir yerde karıştırır: prompt düzeltmeleri, veri yükleme, UI ve değerlendirme tek bir notebokte. Üretim mimarisi sorumlulukları ayırır ki bir parçayı değiştirmek tüm sistemi bozmasın ve hatalar izole edilsin.
Sistemin nasıl çalışacağını belirleyin:
Bu seçim altyapınızı, önbellekleme stratejinizi, SLA’ları ve maliyet kontrollerinizi belirler.
Güvenilir bir AI sistemi genellikle net sınırları olan küçük parçalardan oluşur:
İlk dağıtıma birlikte yapsanız bile, tasarım her bir bileşenin değiştirilebileceği varsayımıyla olsun.
Ağlar zaman aşımına uğrar, sağlayıcılar rate-limit uygular ve modeller bazen kullanışsız çıktı döndürür. Öngörülebilir davranışlar kurun:
İyi bir kural: sistem “güvenli” bir şekilde hata versin ve ne olduğunu açıklasın, sessizce tahmin yürütmesin.
Mimarini bir ürün gibi ele alın, bir script gibi değil. Basit bir bileşen haritası tutun: neye bağımlı, kim sahip ve nasıl geri alınır. Bu, “herkes noteboku sahipleniyor” ama kimsenin sistemi sahiplenmediği yaygın tuzağı önler.
Ana darboğazınız çalışan bir demoyu sürdürülebilir bir uygulamaya dönüştürmekse, yapı platformları “plumbing” işini hızlandırabilir: bir web UI, API katmanı, veritabanı, kimlik doğrulama ve dağıtım için iskelet sağlar.
Örneğin, Koder.ai sohbet arayüzüyle web, sunucu ve mobil uygulamalar oluşturmaya izin veren bir vibe-coding platformudur. Hızlı prototipten üretime, planlama modu, dağıtım/barındırma, özel domainler, kaynak kodu dışa aktarımı ve anlık görüntülerle geri alma gibi pratik özelliklerle ilerleyebilirsiniz—promptlar, yönlendirme veya retrieval mantığı üzerinde iterasyon yaparken temiz sürümler ve geri dönüş imkanı gerektiğinde kullanışlıdır.
Sadece birkaç kişinin kullandığı bir prototip “yeterince ucuz” görünebilir. Üretimde maliyet ve hız ürün özellikleri haline gelir—çünkü yavaş yanıtlar bozukmuş hissi verir ve sürpriz faturalar dağıtımı öldürebilir.
Mühendis olmayan birine açıklayabileceğiniz basit bir tabloyla başlayın:
Bundan 1.000 istek başı maliyet ve beklenen trafik için aylık maliyet tahmini çıkarın. “Kötü günleri” de hesaba katın: daha fazla token kullanımı, daha fazla yeniden deneme veya daha ağır dokümanlar.
Promptları veya modelleri yeniden tasarlamadan önce çıktı davranışını değiştirmeyen iyileştirmelere bakın:
Bunlar genellikle harcamayı azaltır ve aynı anda gecikmeyi iyileştirir.
Neyin “kabul edilebilir” olduğunu önceden belirleyin (örn. istek başı maksimum maliyet, günlük harcama sınırı). Sonra şunlar için alarmlar ekleyin:
Ortalama değil, tepe yükü modelleyin. Rate limitler tanımlayın, patlama iş yükleri için kuyruğa alma düşünün ve net zaman aşımı seviyeleri belirleyin. Bazı işler kullanıcı arayüzüne yönelik değilse (özetler, indeksleme), bunları arka plan işlerine taşıyın ki ana deneyim hızlı ve öngörülebilir kalsın.
Güvenlik ve gizlilik demo’dan gerçek sisteme geçerken “sonra” konusu değildir—bu, neyi güvenli bir şekilde gönderebileceğinizi şekillendirir. Kullanımı ölçeklemeden önce sistemin neye erişebileceğini (veri, araçlar, iç API’ler), kimlerin bu eylemleri tetikleyebileceğini ve başarısızlığın neye benzeyeceğini dokümante edin.
AI özelliğinizin kötüye kullanılabileceği veya başarısız olabileceği gerçekçi yolları listeleyin:
Bu tehdit modeli tasarım incelemelerinizi ve kabul kriterlerinizi bilgilendirir.
Girdiler, çıktılar ve araç çağrıları etrafında guardrail’lara odaklanın:
API anahtarları ve tokenları kodda veya noteboklerde değil, bir secrets manager’da tutun. En az ayrıcalık prensibini uygulayın: her servis hesabı yalnızca gerekli en az veri ve işlemlere erişmeli.
Uyumluluk için PII nasıl ele alındığını tanımlayın (ne saklanır, ne kırpılır), hassas işlemler için denetim logları tutun ve prompt, çıktı ve izler için saklama kuralları belirleyin. Başlamak için politikanızı iç standartlarla hizalayın ve /privacy kontrol listenize referans verin.
Bir prototip genellikle modelin “yeterince doğru” olduğunu varsayar. Üretimde, özellikle çıktılar müşterileri, parayı, güvenliği veya itibarını etkiliyorsa, insanların ne zaman devreye gireceğine dair net bir plana ihtiyacınız var. İnsan-in-the-loop (HITL) otomasyonun bir başarısızlığı değil; kaliteyi yüksek tutan ve öğrenirken kontrol sağlayan bir sistemdir.
Kararları risk bazında haritalayın. Düşük etkili görevler (iç özetler) sadece rastgele kontroller gerektirebilir. Yüksek etkili görevler (politika kararları, tıbbi rehberlik, finansal öneriler) gönderilmeden veya işlem yapılmadan önce inceleme, düzenleme veya açık onay gerektirmelidir.
İnceleme tetiklerini tanımlayın:
“Beğen/Beğenme” başlangıçtır ama sistemi geliştirmek için nadiren yeterlidir. İnceleyiciler ve son kullanıcılar için düzeltme ve yapılandırılmış sebep kodları ekleyin (örn. “yanlış gerçekler”, “güvenli değil”, “ton”, “eksik bağlam”). Geri bildirim çıktının hemen yanından tek tıkla kaydedilebilmeli.
Mümkün olduğunda saklayın:
Zararlı, yüksek etkili veya politika ihlali olabilecek çıktılar için yükseltme yolu oluşturun. Bu basitçe bir “Rapor Et” butonu olabilir; öğeleri on-call sahipliğe, açık SLA’lara ve containment (özelliği devre dışı bırakma, engelleme kuralı ekleme, prompt sıkılaştırma) playbook’una yönlendirir.
Güven, ürünün dürüst olmasıyla artar. Açık işaretler kullanın: sınırlamaları gösterin, kesinlik abartısından kaçının ve mümkünse atıflar veya kaynaklar sağlayın. Sistem taslak üretiyorsa, bunu belirtin ve düzenlemeyi kolaylaştırın.
Bir AI prototipi bozulduğunda anında fark edersiniz çünkü ona bakıyorsunuzdur. Üretimde sorunlar kenar vakalarda, trafik sıçramalarında ve yavaş hatalarda gizlenir. Gözlemlenebilirlik sorunları erken görünür kılar—müşteri vakasına dönüşmeden önce.
Olayı daha sonra yeniden oluşturmak için neye ihtiyacınız olduğunu belirleyin. AI sistemleri için “bir hata oldu” yeterli değildir. Loglayın:
Logları yapılandırılmış (JSON) tutun ki tenant, endpoint, model sürümü ve hata türüne göre filtreleyebilesiniz. Bir kural: loglardan “ne değişti?” sorusuna cevap veremiyorsanız, eksik alanlarınız var demektir.
Geleneksel izleme çökmeleri yakalar. AI ise “çalışıyor ama daha kötü” durumlarını yakalayabilecek izlemeye ihtiyaç duyar. İzleyin:
Bunları açık eşiklerle ve sahiplerle birinci sınıf metrikler olarak ele alın.
Panolar şu soruları cevaplamalı: “Sağlıklı mı?” ve “En hızlı düzeltme ne?” Her alarmı bir on-call çalışma kitabı (ne kontrol edilecek, nasıl geri alınılır, kim bilgilendirilir) ile eşleştirin. Gürültülü bir alarm, alarm olmamasından kötüdür—uyarıları yalnızca kullanıcı etkisinde sayılacak şekilde ayarlayın.
Gerçek kullanımı taklit eden planlı “kanarya” istekleri ekleyin ve beklenen davranışı doğrulayın (format, gecikme, temel doğruluk). Her sürüme karşı küçük bir sabit prompt seti çalıştırın ve regresyonlarda uyarın. Bu, gerçek kullanıcı izlemesini tamamlayan ucuz bir erken uyarı sistemidir.
Bir prototip bilgisayarınızda bir kez çalıştığı için “bitti” hissi verebilir. Üretim işi esas olarak güvenilir şekilde çalışmasını sağlamak, doğru girdilerle ve tekrarlanabilir sürümlerle yapmaktır. İşte MLOps iş akışı sağlar: otomasyon, izlenebilirlik ve güvenli yollar.
AI servisini diğer ürünler gibi ele alın: her değişiklik otomatik bir pipeline tetiklemeli.
Minimum olarak CI’nız şunları yapmalı:
CD sonra bu artefakti hedef ortama (dev/staging/prod) tutarlı adımlarla dağıtmalı. Bu "bende çalışıyor" sürprizlerini azaltır ve geri alma işlemlerini gerçekçi kılar.
AI sistemleri geleneksel uygulamalardan daha fazla şekilde değişir. Bunları versiyonlayın ve incelenebilir yapın:
Bir olay olduğunda şu soruya cevap vermek istersiniz: “Hangi prompt + model + config bu çıktıyı üretti?” tahmin yürütmeden.
En az üç ortam kullanın:
Aynı artefaktı ortamlarda terfi ettirin. Production için "tekrar derleme" yapmaktan kaçının.
CI/CD kapıları, versiyonlama konvansiyonları ve ortam terfi kontrolleri için hazır kullanıma uygun kontrol listeleri istiyorsanız, /blog içinde şablonlar ve örnekler, /pricing içinde paketlenmiş rollout desteği bulunur.
Eğer Koder.ai kullanarak çevre uygulamayı (ör. bir React web UI artı Go API ve PostgreSQL veya bir Flutter mobil istemci) inşa ediyorsanız, onun snapshot/geri alma ve ortam kurulumunu aynı sürüm disiplininin parçası olarak düşünün: staging’de test edin, kontrollü bir rollout yapın ve bilinen son iyi sürüme temiz bir geri dönüş yolu bırakın.
Bir AI prototipini göndermek tek bir “deploy” butonu değildir—bu, guardrail’larla kontrollü bir deneydir. Amacınız kullanıcı güvenini, bütçeleri veya operasyonları bozmadan hızlı öğrenmektir.
Shadow modu yeni model/promptu paralel çalıştırır fakat kullanıcıları etkilemez. Gerçek trafikle çıktı, gecikme ve maliyeti doğrulamak için idealdir.
Canary sürümler canlı isteklerin küçük bir yüzdesini yeni sürüme gönderir. Metrikler sağlıklı kaldıkça kademeli olarak artırın.
A/B testleri iki varyantı (model, prompt, retrieval stratejisi veya UI) önceden tanımlanmış başarı metriklerine göre karşılaştırır. İlerlemenin kanıtına ihtiyaç duyduğunuzda bunu kullanın.
Feature flag'ler, AI özelliğini kullanıcı segmentine göre açıp kapamanızı sağlar (iç kullanıcılar, power userlar, belirli bir bölge) ve davranışı anında değiştirme imkanı verir.
İlk yayından önce “go/no-go” eşiklerini yazın: kalite puanları, hata oranları, uydurma oranı (LLM’ler için), gecikme ve istek başı maliyet. Ayrıca otomatik duraklama tetiklerini tanımlayın—örn. güvensiz çıktılarda ani artış, destek ticketlarında sıçrama veya p95 gecikme artışı.
Geri alma tek adımlık olmalı: önceki model/prompt ve konfigürasyona dönün. Kullanıcı akışları için bir fallback ekleyin: daha basit kural tabanlı cevap, “insan incelemesi” yolu veya tahmin yürütmek yerine kibar bir “cevap veremiyorum” yanıtı.
Destek ve ilgili taraflara neyin değiştiğini, kimlerin etkilendiğini ve sorunları nasıl tanımlayacaklarını söyleyin. Kısa bir çalışma kitabı ve dahili SSS sağlayın ki ekip, kullanıcı “Bugün AI neden farklı cevap veriyor?” diye sorduğunda tutarlı yanıt versin.
Yayınlamak yeni bir aşamanın başlangıcıdır: AI sisteminiz şimdi gerçek kullanıcılarla, gerçek verilerle ve gerçek kenar vakalarla etkileşime giriyor. İlk haftaları öğrenme penceresi olarak değerlendirin ve “iyileştirme işi”ni operasyonların planlı bir parçası haline getirin—panik tepkisi değil.
Production sonuçlarını ön lansman kıyaslarıyla takip edin. Anahtar, değerlendirme setlerinizi düzenli olarak güncelleyip kullanıcıların gerçekte ne sorduğunu, hangi formatları kullandıklarını ve en çok hangi hataların önemli olduğunu yansıtmasını sağlamaktır.
Aylık bir ritim belirleyin:
Modeli yeniden eğitmek veya prompt/araçları ayarlamak fark etmez, değişiklikleri ürün sürümü ile aynı kontrollerden geçirin. Ne değiştiğini, neden değiştiğini ve neyin iyileşmesi beklendiğini açıkça kaydedin. Aşamalı rollouts kullanın ve tüm kullanıcıları değiştirmeden önce versiyonları yan yana karşılaştırın ki etkisini kanıtlayabilesiniz.
Yeniyseniz hafif bir iş akışı belirleyin: teklif → offline değerlendirme → sınırlı rollout → tam rollout.
Düzenli yayın sonrası incelemeler yapın ve üç sinyali birleştirin: olaylar (kalite veya kesinti), maliyetler (API harcaması, compute, insan inceleme zamanı) ve kullanıcı geri bildirimi (ticketlar, puanlar, churn riski). "Sezgiyle düzeltme" yapmaktan kaçının—her bulguyu ölçülebilir bir takip işine dönüştürün.
v2 planınız pratik yükseltmelere odaklansın: daha fazla otomasyon, daha geniş test kapsamı, daha net yönetişim ve daha iyi izleme/uyarılar. Tekrar eden olayları azaltan ve zaman içinde daha güvenli, daha hızlı iyileştirmeler yapmanızı sağlayan işleri önceliklendirin.
Eğer rollout öğrenimlerinizi yayımlıyorsanız, kontrol listelerinizi ve postmortem’lerinizi dahili dokümanlar veya halka açık notlar haline getirmeyi düşünün—bazı platformlar (Koder.ai dahil) ekiplerin içerik oluşturup başkalarını yönlendirmesi karşılığında kredi kazanabileceği programlar sunar; bu, iterasyon yaparken denemelerin maliyetini dengelemeye yardımcı olabilir.
Bir prototip “Bu işe yarar mı?” sorusunu ideal koşullar altında yanıtlar (küçük veri seti, sorunları sessizce düzelten bir insan, hoşgörülü gecikme). Üretim ise “Her gün güvenilir şekilde çalışır mı?” sorusunu, gerçek girdiler, gerçek kullanıcılar ve net sorumluluklarla yanıtlamalıdır.
Pratikte üretime hazır olmayı belirleyen şey operasyonlardır: güvenilirlik hedefleri, güvenli hata modları, izleme, maliyet kontrolleri ve sahiplik—sadece daha iyi bir model değil.
Tam olarak hangi kullanıcı akışı etkilenecek ve işin hangi sonucu iyileştireceğiyle başlayın.
Ardından şu küçük metrik setini seçin:
Son olarak, herkesin neyin “gönderilebilecek kadar iyi” olduğunu kabul etmesi için bir v1 “yapım tanımı” yazın.
Uçtan uca veri akışını haritalayın: girdiler, etiketler/geri bildirim ve aşağıdaki tüketiciler.
Sonra yönetişim koyun:
Bu, “demoda çalıştı” sorunlarını gerçek dünya girdilerinin karışıklığı ve izlenmeyen değişikliklerle önler.
Küçük, temsilî bir golden set (genellikle 50–200 örnek) ile başlayın ve her bir örnek için tutarlı bir rubrik veya referans çıktı belirleyin.
Erken dönemde kenar durumlarını ekleyin:
Eşikleri ve önceden belirleyin, böylece sürümler kontrol edilen deneyler haline gelir.
Gizli manuel adımlar, bir demoyu sabit gösteren “insan yapıştırıcısıdır”—o kişi müsait olmadığında veya ayrıldığında sistem bozulur.
Yaygın örnekler:
Bunu, her adımı mimaride açık hale getirerek (doğrulama, yeniden deneme, geri dönüş mekanizmaları) ve bir hizmetin sahibi yaparak düzeltin; bireyin değil.
Sorumlulukları ayırın ki her parça değiştirildiğinde tüm sistem bozulmasın:
API, batch veya gerçek zamanlı gibi bir işletim modu seçin, sonra zaman aşımı, yeniden deneme, geri dönüş ve kademeli bozulma ile hataya göre tasarlayın.
Basit bir maliyet modeli oluşturun:
Davranışı değiştirmeden optimizasyon yapın:
Basit bir tehdit modeliyle başlayın:
Yüksek riskli yerlere guardrail ekleyin:
İnsanları bir kontrol sistemi olarak kullanın, yama olarak değil.
İnceleme gereken yerleri risk bazlı haritalayın ve tetikleyiciler belirleyin:
Kullanıcı geri bildirimi tek tıkla alınabilecek şekilde toplayın: sebep kodları, düzenlenen çıktı, orijinal girdi.
Zararlı veya politika ihlali olabilecek çıktılar için bir yükseltme yolu (kuyruk + on-call + playbook) oluşturun.
Riskle uyumlu aşamalı bir yayın kullanın:
Geri alma tek adımlık olmalı (önceki model/prompt/config) ve kullanıcı akışları için güvenli fallback sağlayın (gerektiğinde insan incelemesi veya kural tabanlı yanıt).
Ayrıca harcama cap'leri ve anomali alarmları ekleyin.
Ayrıca gizli anahtarları secrets manager'da tutun, en az ayrıcalık prensibini uygulayın, saklama kuralları ve denetim logları oluşturun. Politikanızı /privacy ile hizalayın.