Yapay zekâ bir proje kararını hızlandırabilir. Fakat yanlış çizimi, eksik veriyi veya uydurulmuş bir bilgiyi de aynı hızla dolaşıma sokabilir. İnşaatta güvenli AI kullanımı, araca ne sorduğumuzdan önce çıktının nerede, kim tarafından ve hangi sorumlulukla kullanılacağını belirlemekle başlar.
Beton dökümünden birkaç dakika öncesinde olduğumuzu düşünelim. Donatı kontrol edilmiş, tesisat rezervasyonları yerinde, kalıp teslim formu imzaya hazır. Proje müdürü, yapay zekânın hazırladığı son kontrol özetine bakıyor: “Uygun.”
Tam o sırada kalıp ustası soruyor: “Hangi revizyona göre?”
Masadaki sessizlik, yapay zekânın verebileceği en doğru cevap olabilir.
Çünkü inşaat projelerinde AI kullanımının en büyük riski, sistemin hata yapması değildir. İnsanlar da hata yapar. Asıl risk, hatanın düzgün cümleler, renkli bir gösterge paneli ve kendinden emin bir tonla “kontrol edilmiş bilgi” görünümüne kavuşmasıdır. Yapay zekâ bazen yanlışı icat etmez; projede zaten var olan bilgi dağınıklığını hızlandırır.
Bu nedenle aşağıdaki kontrol listesi bir yazılım satın alma listesi değildir. Bir kararı AI ile desteklemeden önce yönetimin sorması gereken sorulardır.
Listenin bütün maddeleri her kullanımda aynı ağırlıkta olmayacaktır. Bir toplantı özetindeki yanlış cümle ile kolon donatısı hakkında verilen yanlış önerinin sonucu aynı değildir. Kontrol düzeyi, kararın geri döndürülebilirliğine ve olası zararın büyüklüğüne göre artmalıdır. Düşük etkili işlerde hız öne çıkabilir; maliyet, sözleşme, kalite ve güvenliği etkileyen işlerde ise kaynak gösterme, uzman incelemesi ve kayıt zorunlu hâle gelir. Her AI uygulamasına aynı prosedürü dayatmak bürokrasi üretir. Hiç prosedür koymamak ise kumar oynamaktır.
1. Çözülen iş problemi açık mı?
“Projede AI kullanıyoruz” bir hedef değildir. Hangi işi iyileştiriyoruz? Günlük raporları özetlemek mi, gecikme sinyallerini yakalamak mı, sözleşme maddelerini bulmak mı, iş güvenliği görüntülerini değerlendirmek mi?
Kullanım alanı tanımlanmadan başarı da risk de ölçülemez. Toplantı notunu özetleyen sistemle kaldırma planı hakkında öneri veren sistem aynı risk sınıfında değildir. İlkinde kötü bir özet zaman kaybettirir. İkincisinde kötü bir öneri insan hayatına dokunabilir.
2. Çıktı hangi kararı etkiliyor?
AI çıktısının “bilgi”, “öneri”, “ön kontrol” veya “onay” olup olmadığı baştan yazılmalıdır. Bu dört kelime arasında ciddi bir sorumluluk farkı vardır.
Bir hakediş ön incelemesi, planlama sapması uyarısı ya da şartname araması karar hazırlayabilir. Fakat nihai teknik onay, ödeme kararı, iş güvenliği talimatı veya sözleşmesel bildirim yetkili kişide kalmalıdır. Ekranın altına “Hata yapabilir” yazmak, sorumluluk düzeni kurmak değildir.
3. Kaynağın güncelliği ve revizyonu doğrulanıyor mu?
Şantiyede doğru bilgi kadar güncel bilgi de önemlidir. Sistem hangi çizimi okudu? Onaylı iş programı hangisi? Son RFI cevabı modele ulaştı mı? Zeyilname, eski şartnameyi geçersiz kıldı mı?
AI çıktısı kaynak dosyanın adını, revizyonunu, tarihini ve mümkünse ilgili maddeyi göstermelidir. “Cevap doğru görünüyor” yeterli değildir; cevabın izi sürülebilmelidir. ISO 19650 yaklaşımının kayıt, sürüm ve bilgi organizasyonu disiplini, AI geldi diye ortadan kalkmaz. Tam tersine daha değerli hâle gelir.
4. Sistem bilmediğinde durabiliyor mu?
Üretken AI sistemleri eksik bilgi karşısında bazen boşluğu akıcı bir metinle doldurur. Sektörde buna yeni bir isim vermeye gerek yok; eski tabirle, emin olmadığı konuda emin konuşur.
Sistemin “Bu dokümanlarda yeterli bilgi yok”, “Çelişkili iki revizyon buldum” veya “Yetkili mühendis incelemesi gerekir” diyebilmesi tasarım şartı olmalıdır. Her soruya cevap veren bir sistem, güvenilir değil; konuşkandır.
5. İnsan kontrolü isim ve yetkiyle tanımlı mı?
“İnsan kontrol edecek” cümlesi rahatlatıcıdır ama eksiktir. Hangi insan? Planlama mühendisi mi, sözleşme yöneticisi mi, iş güvenliği uzmanı mı? Kontrol için zamanı, yetkisi ve gerekli belgeye erişimi var mı?
Her kritik kullanım için çıktı sahibi, teknik kontrolör ve nihai karar verici belirlenmelidir. AI’nın hazırladığı bir risk kaydını kim kapatabilir? Yanlış sonucu kim durdurur? Sorumluluk herkesin üzerindeyse, çoğu zaman hiç kimsenin üzerinde değildir.
6. Gerçek proje örnekleriyle sınandı mı?
Etkileyici bir demo, saha testi değildir. Sistem; eksik tutanak, bozuk PDF, Türkçe-İngilizce karışık şartname, çelişkili çizim, yanlış dosya adı ve güncellenmemiş programla denenmelidir. Çünkü gerçek proje verisi, satış sunumundaki veri kadar terbiyeli değildir.
Testte yalnızca doğru cevap oranına bakılmamalı. Kaç riski gözden kaçırdı? Kaç kez olmayan bir risk üretti? Hangi durumda kullanıcıyı gereksiz yere rahatlattı? Bilinen doğru sonuçlardan oluşan bir deneme seti olmadan “başarılı pilot” demek, temeli görmeden kat çıkmaya benzer.
7. Hassas veri nereye gidiyor?
Sözleşmeler, birim fiyatlar, teklif dosyaları, çalışan bilgileri, saha görüntüleri, tasarım detayları ve anlaşmazlık yazışmaları rastgele bir genel modele yüklenmemelidir. Verinin nerede işlendiği, ne kadar saklandığı, model eğitimi için kullanılıp kullanılmadığı ve kimlerin erişebildiği bilinmelidir.
Özellikle güvenlik kamerası, yüz, davranış veya çalışan performansı içeren uygulamalarda konu yalnızca verimlilik değildir; mahremiyet, ayrımcılık ve çalışma ilişkileri de devreye girer. “Programda bu özellik vardı” geçerli bir kullanım gerekçesi sayılmaz.
8. Yetki sınırı ve güvenli çıkış var mı?
AI bir risk görebilir, fakat vinci durdurmalı mı? Satın alma talebi açabilir, fakat siparişi göndermeli mi? Gecikme öngörebilir, fakat alt yükleniciye ihtar hazırlayıp otomatik yollamalı mı?
Kararın etkisi büyüdükçe otomasyon sınırı daralmalıdır. Kritik işlemlerde onay kapısı, geri alma imkânı ve gerektiğinde sistemi devre dışı bırakacak açık bir yol bulunmalıdır. Hız, fren sistemi olmayan bir araçta meziyet değildir.
9. Kayıt ve denetim izi tutuluyor mu?
Hangi model, hangi tarihte, hangi veriyle, hangi komutla ne üretti? Çıktıyı kim değiştirdi, kim onayladı ve karar ne oldu? Bu kayıtlar tutulmuyorsa sistem öğrenmez; kurum da yalnızca aynı hatayı daha modern biçimde tekrarlar.
Model veya tedarikçi güncellendiğinde yeniden test yapılmalıdır. Dün doğru çalışan bir iş akışının yarın aynı sonucu vereceği varsayılmamalıdır. AI yönetimi tek seferlik bir kurulum değil, düzenli kontrol döngüsüdür.
10. Fayda kadar hata maliyeti de ölçülüyor mu?
On saat kazandıran bir sistem, bir yanlış sözleşme yorumu yüzünden on gün kaybettirebilir. Bu nedenle pilotun performansı yalnızca hız, kullanıcı sayısı veya hazırlanan rapor adediyle ölçülmemelidir. Yakalanan risk, kaçırılan risk, yeniden iş yapma, yanlış alarm, karar süresi ve hata maliyeti birlikte izlenmelidir.
Yapay zekâya güvenmek ile yapay zekâ kullanmak aynı şey değildir. Güven; kaynağı görünür, sınırları tanımlı, çıktısı sınanmış ve sorumlusu belli bir çalışma düzeninin sonucudur.
Beton dökümünden önce sorulacak son soru da budur: “AI uygun dedi mi?” değil, “Biz neyi, hangi revizyona göre ve kimin sorumluluğunda uygun bulduk?”
Yapay zekâ imza atmayabilir. Fakat attığımız imzanın kalitesini mutlaka sınar.
Kaynak notları
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1): kendinden emin yanlış üretim, veri mahremiyeti, insan-AI etkileşimi ve doğrulama riskleri.
- ISO, ISO/IEC 42001:2023: AI yönetim sistemi, risk değerlendirmesi, hesap verebilirlik, izlenebilirlik ve sürekli iyileştirme.
- ISO, ISO 19650-1:2018: proje bilgilerinin kaydı, sürüm kontrolü ve organizasyonu.
- ISO, ISO 19650-5:2020: yapılı çevrede hassas bilgi için güvenlik odaklı bilgi yönetimi.
- Avrupa Komisyonu, AI Act uygulama çerçevesi: insan gözetimi, kayıt, veri kalitesi, şeffaflık ve risk yükümlülükleri.