Yapay zeka destekli bir yazılımı satın almadan önce, örnek kayıtları dışarı çıkarıp bağımsız bir test ortamında yeniden kullanmayı deneyin. Dosyanın inmesi yeterli değildir. Alanlar, ekler ve kayıtlar arasındaki bağlantılar korunuyor mu? Eksikler neler, hangi parçalar yeniden kurulmalı? Bu soruları denemeyle yanıtlamak satın alma kararını somutlaştırır.
Bir ürünün size uygunluğunu değerlendirirken günlük kullanım kadar ayrılma koşullarını da konuşmak gerekir. Birleşik Krallık’ın teknik bağımlılığı yönetme rehberi de taşınabilirlik ile üründen elde edilen fayda arasında denge kurulmasını, olası çıkışın zaman ve maliyetinin düşünülmesini önerir. Bu bir Türkiye mevzuatı kuralı değil, satın alma değerlendirmesinde yararlanılabilecek bir çerçevedir. Hazır yapay zeka aracı ile özel uygulama karşılaştırmasında yer alan taşınabilirlik sorusunu, aşağıdaki küçük denemeyle somutlaştırabilirsiniz.
Önce taşımak istediğiniz işi tarif edin
Kurgusal bir şirketin eğitim kayıtlarını yönettiğini düşünelim. Yazılım başvuruları özetliyor, katılımcıyı uygun oturumla eşleştiriyor ve ekibin kontrol edeceği bir liste hazırlıyor. Her başvuruda bir kayıt numarası, oturum bilgisi, durum, not ve ek dosya bulunuyor.
Satın alma görüşmesinde yalnızca “Veriyi dışarı alabiliyor muyuz?” diye sormayın. Şunu sorun: “Bu kayıtları başka bir araçta açtığımızda hangi kişinin hangi oturuma bağlı olduğunu ve hangi ekin hangi kayda ait olduğunu anlayabilecek miyiz?”
Denemeyi gerçek katılımcı bilgileri yerine uydurma kayıtlarla yapın. Normal bir başvurunun yanına iptal edilmiş bir kayıt, sonradan değiştirilmiş bir oturum ve ek dosyası bulunan bir başvuru koyun. Amaç çok veri toplamak değil, işiniz için önemli farklılıkları görmek.
Süreçleri yapay zeka açısından değerlendirirken bu örneklerin seçimini iş ekibiyle birlikte yapın. Bir dosyanın açılması, ekibin işini sürdürebileceğini tek başına göstermez.
Satıcıdan bir örnek çıktı paketi isteyin
CSV, satır ve sütunlardan oluşan bir metin dosyasıdır; JSON ise alanları ve iç içe bilgileri düzenli biçimde taşıyabilir. Bir biçimin adını duymak, ürünün sizin ihtiyaç duyduğunuz bütün bilgileri dışarı verdiğini kanıtlamaz. Desteklenen kapsamı ürünün belgelerinden ve örnek çıktıdan kontrol edin.
Örnek paketle birlikte şu açıklamaları isteyin:
- Hangi alanlar dışarı çıkıyor, hangileri çıkmıyor?
- Tarih, saat, boş değer ve durum bilgileri nasıl gösteriliyor?
- Ek dosyalar pakete dahil mi, yoksa yalnızca bağlantıları mı var?
- Kayıtları birbirine bağlayan kimlikler korunuyor mu?
- İşlem için hangi kullanıcı rolü gerekiyor?
- Dışarı alma sınırları, bekleme süresi veya ek ücret var mı?
Son soruların yanıtını varsaymayın. Teklifte, ürün belgesinde veya satıcının yazılı açıklamasında bulunmasını isteyin. Denemede gözlediğiniz sonucu da ayrı kaydedin.
Dosyayı açın, sonra bir örnek işi yeniden kurun
İlk kontrolde dosyanın okunabildiğini ve beklenen kayıtların bulunduğunu görün. Ardından yalnızca satır sayısına bakmak yerine bir başvuruyu baştan sona izleyin: katılımcı kaydı, bağlı oturum, durum ve ek dosya birbiriyle eşleşiyor mu?
| Kontrol | Eğitim kaydı örneğinde bakılacak şey |
|---|---|
| Alanlar | Durum ve oturum bilgisi anlamını koruyor mu? |
| Kimlikler | Aynı isimli iki uydurma katılımcı ayırt ediliyor mu? |
| İlişkiler | Başvuru doğru oturuma bağlı mı? |
| Ekler | Dosya açılıyor ve doğru başvuruya bağlanıyor mu? |
| Değişiklikler | İptal veya oturum değişikliği anlaşılabiliyor mu? |
| Yetkiler | Yeni ortamda erişim yeniden sınırlandırılabiliyor mu? |
Yeniden içeri alma denemesini canlı sisteme yapmayın. Gerçek bildirim göndermeyen, canlı kayıtları etkilemeyen ve sınırlı erişimli ayrı bir test ortamı kullanın. Örneğin yeni ortamda seçilen bir oturumun katılımcı listesini çıkarın; ardından iptal edilmiş kaydın listede yanlışlıkla etkin görünmediğini kontrol edin.
Kurumsal yapay zeka uygulamalarında veri ve erişim tasarımı bu noktada önem kazanır. Verinin taşınması, eski erişim kurallarının yeni sistemde kendiliğinden uygulanacağı anlamına gelmez. Hangi rolün hangi kaydı görebileceğini yeniden sınayın.
Taşınan veriyle yeniden kurulacak işi ayırın
Başvuruların ve eklerin elinizde olması; özetleme talimatlarının, otomatik yönlendirmelerin, onay adımlarının ve ekranların da taşındığını göstermez. Avustralya kamu mimarisinin taşınabilirlik ve çıkış planlama kontrol listesi de verinin yanında ayarları, talimatları ve diğer bağımlılıkları değerlendirmeye dahil eder. Bu parçaları ayrı bir listede tutun. Her birinin dışarı alınabilir, belgelenebilir veya yeniden geliştirilebilir olup olmadığını netleştirin.
Örnekte katılımcı listesi taşınabilirken, serbest metinden oturum öneren adım yeni araçta yeniden kurulabilir. Bu durumda satıcı değiştirme hazırlığına yalnızca dosya aktarımı değil, o adımın yeniden denenmesi de dahildir. Yeni yapay zeka modelinin aynı talimatla aynı sonucu vereceğini varsaymayın; örnek başvurular üzerinde çıktının işe uygunluğunu yeniden kontrol edin. Özel bir dönüşüm gerekiyorsa yazılım geliştirme kapsamına alan eşleştirmesini, eksik kayıt raporunu ve doğrulama testlerini açıkça yazın.
Satın alma kararına kısa bir sonuç notu ekleyin
Denemenin sonunda üç başlık yeterlidir: taşınabildi, ek çalışma gerekiyor, henüz doğrulanmadı. Her başlığın altında gözlenen sonucu, kanıt dosyasını ve sorumluyu belirtin. “Satıcı destekliyor” ile “örnek kaydı yeniden kullandık” aynı kanıt değildir. Küçük bir örneğin başarıyla taşınması da tüm kayıtların aynı şekilde taşınacağını kanıtlamaz; testin kapsamını ve doğrulanmayan durumları not edin.
Kritik kayıt ilişkisi kayboluyorsa veya ekler açılmıyorsa bunu satın alma öncesinde çözülmesi gereken bir koşul yapın. Eksik yalnızca yeniden kurulacak bir ekran ise bunun iş yükünü ve sorumlusunu görünür kılın. Böylece çıkış ihtimalini soyut bir kaygı olarak değil, satın alma kararının test edilmiş bir parçası olarak değerlendirebilirsiniz.


