Son güncelleme: 17 Ekim 2026
Bir kullanıcı SAP’de yanlış işlem yaptığında genellikle izini bulabiliriz. Kullanıcının kim olduğu bellidir, hangi role sahip olduğu görülür, yaptığı işlem loglara düşer. Yetkisi fazlaysa rolü daraltılır; işten ayrılırsa hesabı kapatılır.
Peki aynı işlemi bir AI agent (yapay zekâ ajanı) yaptığında?
Üstelik ajan tek bir işlemle yetinmeyip başka araçları çağırabiliyor, farklı sistemlerden veri alabiliyor, bir başka ajana görev verebiliyor ve birkaç saniye içinde insan kullanıcısının çok daha uzun sürede gerçekleştireceği bir işlem zincirini tamamlayabiliyorsa?
SAP dünyasında yapay zekâ tartışmasının belki de en kritik aşamasına geliyoruz.
Bugüne kadar ağırlıklı olarak “AI bize ne kadar zaman kazandırır?” sorusunu konuştuk. Bundan sonraki soru biraz daha zor:
Bu dijital çalışanlara ne kadar yetki vereceğiz ve yaptıkları işleri nasıl kontrol edeceğiz?
Bu yalnızca teorik bir güvenlik tartışması değil. SAP, AI ajanlarının gerçek kurumsal sistemlerde görev yürütmesini; araç çağırmasını, iş süreçlerinde işlem yapmasını ve farklı uygulamalar arasında çalışmasını ürün mimarisinin önemli bir parçası hâline getiriyor.
SAP ile NVIDIA’nın yürüttüğü OpenShell çalışması bu ihtiyacın somut örneklerinden biri. NVIDIA’nın açık kaynak olarak geliştirdiği OpenShell, AI ajanlarının izole, yetkilendirilmiş ve denetlenebilir bir çalışma ortamında çalışmasını hedefliyor. SAP de OpenShell’i Joule Studio çalışma zamanına entegre ederek ajanların çalışma zamanı güvenliğini güçlendirmeyi amaçlıyor. Bu entegrasyon hâlen geliştirme aşamasında.
AI ajanı neden klasik bir SAP kullanıcısından farklı?
SAP güvenliği açısından bakıldığında ilk refleks doğal olarak şu oluyor:
“Ajan için de bir kullanıcı açarız, gerekli rolleri veririz.”
Fakat konu bundan daha karmaşık olacak. Çünkü klasik bir kullanıcı çoğunlukla belirli bir ekran veya uygulama üzerinden işlem yaparken AI ajanı bir amaç doğrultusunda hareket ediyor. Bir isteği anlayabilir, hangi araçların kullanılacağına karar verebilir, bir API çağırabilir, başka bir sistemden veri çekebilir ve çıkan sonuca göre sonraki adımı belirleyebilir.
Üstelik SAP’nin benimsediği MCP (Model Context Protocol) ve A2A (Agent2Agent) gibi açık standartlar, AI ajanlarının yalnızca SAP içinde değil, farklı ajanlar, uygulamalar ve araçlarla birlikte çalışabilmesini hedefliyor.
Ancak bu mimari henüz tamamen olgunlaşmış değil. SAP’nin 9 Ekim 2026 tarihli referans mimarisine göre, Agent Gateway üzerinden üçüncü taraf ve self-hosted agent’larla çift yönlü iletişim henüz desteklenmiyor. Bu da SAP’nin agent interoperability yaklaşımının halen gelişmeye devam ettiğini gösteriyor.
Tablo: AI Ajanları için 5 Katmanlı Güven Modeli
Katman | Temel soru |
Kimlik | Ajan kim ve kimin adına hareket ediyor? |
Yetki | Neye erişebilir ve hangi işlemleri yapabilir? |
Sınır | Hangi araçları, API’leri ve ajanları çağırabilir? |
İz | Yaptığı işlemler geriye dönük açıklanabiliyor mu? |
Fren | Hata durumunda ne kadar hızlı durdurulabilir? |
Sınır | Hangi veri kaynaklarına güvenebilir; hangi araçları, API’leri ve ajanları çağırabilir? |
Önce kimlik: Sistemde işlem yapan bu dijital aktör kim?
Kurumsal kimlik yönetimini insan çalışan üzerinden düşünmek kolaydır.
Bir çalışan işe başlar. Kullanıcı hesabı açılır. Organizasyondaki rolüne göre yetkiler atanır. Görevi değişirse yetkileri değiştirilir. Şirketten ayrıldığında hesabı kapatılır.
AI ajanlarının da benzer bir kimlik yaşam döngüsüne ihtiyaç duyduğu artık daha net görülüyor.
SAP Cloud Identity Services içinde geliştirilen Agent Identity yaklaşımı bunun somut örneklerinden biri. SAP’nin mevcut dokümantasyonunda ajanların ayrı kimlikler olarak kaydedilmesi, hangi kullanıcıların bu ajanları çağırabileceğinin belirlenmesi ve erişim politikalarının ayrı şekilde yönetilmesi öngörülüyor.
Burada önemli bir ayrıntı var.
SAP Cloud Identity Services’in Ekim 2026 itibarıyla Early Adopter Care kapsamında belgelediği modelde ajanlar bir kullanıcı bağlamında çağrılıyor. Kullanıcının ilgili ajanı çağırma yetkisine sahip olması gerekiyor ve ajan, arka uç sistemlerde çağıran kullanıcının mevcut yetkilerini aşamıyor. Ancak kullanıcının backend yetkileri güvenliğin yalnızca bir katmanı. Ajanın erişebildiği araçlar, API kapsamı, diğer ajanlarla ilişkisi ve çalışma zamanı politikaları da ayrıca yönetilmeli.
Buna karşılık SAP’nin AI-native hedef mimarisi, ajan kimliğinin ve yaşam döngüsünün daha bağımsız bir kurumsal varlık olarak yönetildiği daha ileri bir yapıya işaret ediyor. Bu nedenle bugünkü ürün davranışıyla SAP’nin uzun vadeli mimari yönünü birbirinden ayırmak gerekiyor. Bu ayrım önemli. Çünkü bugün için “ajanlara sınırsız teknik kullanıcı verilecek ve kendi başlarına sistemde dolaşacaklar” gibi bir tablo çizmek doğru olmaz.
Ama yön açık: AI ajanları artık yalnızca birer yazılım bileşeni değil; sahipliği, yetkileri, erişim politikaları ve yaşam döngüsü yönetilmesi gereken yeni bir dijital kimlik sınıfına dönüşüyor.
“Ajan yapabiliyor” ile “ajan yapmalı” aynı şey değil
Asıl güvenlik problemi burada başlıyor.
Bir satın alma ajanının tedarikçi tekliflerini karşılaştırması makul olabilir. Peki satın alma siparişi oluşturabilir mi? Belirli bir tutarın üzerindeki siparişi onaysız açabilir mi? Yeni tedarikçi oluşturabilir mi? Tedarikçinin banka hesabını değiştirebilir mi?
Bu işlemlerin teknik olarak yapılabiliyor olması, ajanın bunları yapmasına izin verilmesi gerektiği anlamına gelmez.
İnsan kullanıcılar için yıllardır uyguladığımız least privilege (en az ayrıcalık) prensibi ajanlar için daha da önemli olabilir. Çünkü otonom çalışan bir sistem, yanlış yetki verildiğinde hatayı insan kullanıcının yapabileceğinden çok daha hızlı ve ölçekli biçimde çoğaltabilir.
Bu sebeple ajan erişim yönetimi (agent access management) yalnızca klasik role dayalı yetkilendirme olmayacaktır. Yetkinin; ajanın amacı, işlem tipi, veri hassasiyeti, organizasyon birimi, parasal limit ve işlemin taşıdığı riskle birlikte değerlendirilmesi gerekiyor.
Görevlerin ayrılığı (Segregation of Duties), ajanlar dünyasında yeniden düşünülmeli mi?
SAP güvenliği ve GRC (Governance, Risk and Compliance – Yönetişim, Risk ve Uyum) ekiplerinin yıllardır çok iyi bildiği bir prensip var:
Segregation of Duties (SoD – görevlerin ayrılığı).
Aynı kullanıcının hem tedarikçi oluşturup hem ödeme yapması veya hem sipariş oluşturup hem onaylaması istenmez.
Peki iki farklı AI ajanı bunu yaparsa?
Birinci ajan tedarikçi oluşturuyor. İkinci ajan ödemeyi hazırlıyor.
İki ajanın teknik kimliği farklı olabilir. Fakat her ikisi de aynı iş hedefi doğrultusunda, aynı orkestrasyonun parçası olarak hareket ediyorsa klasik SoD kontrolü yeterli olacak mı?
Bu noktada henüz oturmuş bir SAP uygulama standardından söz etmek için erken. Ancak soru şimdiden önemli.
Gelecekte görev ayrılığı kontrollerinin yalnızca kullanıcı ve rol kombinasyonlarını değil, ajanların birlikte yürüttüğü işlem zincirlerini de değerlendirmesi gerekebilir.
GRC dünyası açısından yeni sınır tam burada ortaya çıkıyor.
İleri Okuma
SAP kullanıcı deneyiminin ekran bazlı adımlardan niyet odaklı yapay zeka ajanlarına nasıl evrildiğini incelemek için [SAP’te Ekrandan Niyete Geçiş: Joule Work, SAP ile Çalışma Biçimini Nasıl Değiştirecek?] başlıklı rehberimize göz atabilirsiniz.
MCP ve üçüncü taraf ajanlar güvenlik sınırını genişletiyor
AI ajanlarının değeri yalnızca SAP içinde işlem yapmalarından gelmiyor. Gerçek potansiyel, farklı sistemler arasında çalışabilmelerinde.
MCP (Model Context Protocol – Model Bağlam Protokolü) bu açıdan kritik.
Bir ajan MCP sunucusu üzerinden kurumsal bir araca veya veri kaynağına erişebilir. Başka bir ajanla A2A üzerinden görev paylaşabilir. SAP Integration Suite de mevcut API’lerin ajanların kullanabileceği yönetilen MCP servisleri olarak sunulmasına yönelik yetenekler geliştiriyor.
Ancak bağlantı sayısı arttıkça güven sınırı da genişliyor. Artık şu soruların cevaplanması gerekiyor:
Bu MCP sunucusuna kim güveniyor?
Hangi araçları kullanmasına izin verildi?
Hangi verileri okuyabilir?
Üçüncü taraf ajan SAP’de hangi işlemleri tetikleyebilir?
Güven seviyesi değişirse erişim ne kadar hızlı kesilebilir?
SAP AI Agent Hub’ın doğrulanmamış MCP sunucularının canlı iş akışlarında kullanılmasını engelleme ve doğrulama durumu değiştiğinde erişimi iptal etme yaklaşımı bu nedenle dikkat çekici.
Kurumsal güvenliğin sınırı artık yalnızca SAP sisteminin kapısında bitmiyor.
Yetki doğru olsa bile ajan kandırılabilir mi? Prompt injection riski
Kimlik ve yetkilendirme doğru kurulmuş olsa bile AI ajanları farklı bir güvenlik problemiyle karşı karşıya: prompt injection ve özellikle indirect prompt injection (dolaylı prompt enjeksiyonu). Bir ajan, e-posta, doküman, web içeriği veya harici veri kaynağında bulunan kötü niyetli bir talimatı güvenilir iş girdisi gibi yorumlayabilir.
Bu nedenle yalnızca “ajan neye erişebilir?” sorusu yeterli değildir. Ajanın hangi kaynağa güveneceği, dış içeriklerin nasıl sınırlandırılacağı ve kritik aksiyonların hangi politika katmanlarından geçeceği de tasarlanmalıdır.
Agentic güvenlikte yetki ile güven aynı şey değildir. Bir ajanın bir işlemi yapmaya yetkili olması, o işlemi tetikleyen girdinin güvenilir olduğu anlamına gelmez.
Görünmeyen risk: Gölge Ajanlar
Kurumsal yönetişim açısından bir başka risk de shadow agents, yani BT ve güvenlik ekiplerinin merkezi envanterinde bulunmayan ajanlardır. Kullanıcıların kendi AI araçlarını SAP API’lerine, MCP sunucularına veya üçüncü taraf entegrasyonlara bağlaması, kurumun kontrol alanı dışında yeni erişim yolları oluşturabilir.
Bu nedenle ajan envanteri (agent inventory) yalnızca “hangi ajanları resmi olarak kullanıyoruz?” sorusuna değil, SAP’ye hangi ajanların fiilen bağlandığı sorusuna da cevap vermelidir.
Denetim İzi (Audit Trail) artık “kim ne yaptı?” sorusundan daha fazlası
Bir denetimde en temel sorulardan biri şudur:
Kim, ne zaman, hangi işlemi yaptı?
AI ajanlarında buna birkaç soru daha ekleniyor:
Neden yaptı?
Hangi talep üzerine yaptı?
Hangi aracı kullandı?
Hangi veriye dayanarak karar verdi?
Başka bir ajana görev devretti mi?
İnsan onayı var mıydı?
Bir agentic AI ortamında yalnızca son işlemi (transaction) görmek yeterli olmayabilir. İşlemin hangi kullanıcı bağlamında başladığını, hangi ajan ve araçlardan geçtiğini ve hangi adımlar sonucunda gerçekleştiğini geriye doğru izleyebilmek gerekir.
SAP’nin AI Agent Hub referans mimarisine göre, SAP tarafından yönetilen ve desteklenen ajan ortamlarından toplanan telemetri (telemetry) verileri farklı amaçlarla değerlendiriliyor. Operasyonel izleme için bu veriler SAP Cloud ALM’e, ajanların hangi adımları izlediğini gösteren işlem izleri (agent execution traces) ise davranışsal süreç analizi için SAP Signavio Process Intelligence’a aktarılıyor.
SAP AI Agent Hub’ın SAP LeanIX üzerine kurulu merkezi yönetişim yaklaşımı da kurum içindeki ajanların, bağlantıların ve ilgili bileşenlerin ortak bir envanterde görünür hâle getirilmesini destekliyor.
Burada güvenlik ile gözlemlenebilirlik (observability) giderek birbirine yaklaşıyor.
Denetim artık yalnızca işlem kaydı (transaction log) tutmak değil; bir ajanın hangi adımlarla, hangi araçları kullanarak ve hangi işlem zinciri sonucunda aksiyon aldığını geriye dönük olarak anlayabilmek anlamına geliyor.
Ajanın freni nerede?
Kurumsal AI güvenliğinde yetkilendirme kadar önemli bir başka konu var:
Bir ajan yanlış davranmaya başladığında onu ne kadar hızlı durdurabiliriz?
İnsan kaynaklı bir hata çoğunlukla insan hızında yayılır; ajan kaynaklı bir hata ise otomasyon hızında çoğalabilir. Bu nedenle agentic sistemlerde yalnızca hatanın oluşma ihtimali değil, hatanın kaç işlem veya sisteme yayılabileceği de hesaba katılmalıdır.
Ajan birkaç saniye içinde onlarca işlem gerçekleştirebilir.
Sorun fark edildiğinde klasik anlamda “rollback yaparız” demek de her zaman mümkün değildir. SAP’de oluşturulan bir iş belgesi başka belgeleri veya entegrasyonları tetiklemiş, muhasebe kaydı oluşturmuş veya dış sisteme veri göndermiş olabilir.
Bu nedenle operasyonel kontrolün üç katmanı olmalı:
- Ajanı durdurmak,
- Etkinin yayılmasını sınırlamak ve
- Yapılan işlemleri güvenli biçimde telafi etmek.
Telafi bazen bir belgenin iptali, bazen ters kayıt, bazen yeni bir düzeltme işlemi olabilir.
Burada hız da yeni bir risk metriğine dönüşüyor.
Hatalı davranışın başlamasıyla tespit edilmesi ve ajanı durdurma arasında kaç dakika geçiyor?
Agentic sistemlerde güvenlik ekiplerinin önümüzdeki dönemde yalnızca erişim kontrolünü değil, çağrı/işlem hızı sınırı (rate limit), acil durdurma mekanizması (kill switch), eşik değerleri ve olağandışı işlem hacmi gibi operasyonel korumaları da daha fazla konuşacağını düşünüyoruz.
Human-in-the-loop (insan onaylı süreç) her problemi çözmez
İlk refleks şu olabilir:
“O zaman her işlemi insana onaylatalım.”
Bu güvenliği artırabilir fakat ajan kullanımının sağladığı verimliliği de büyük ölçüde ortadan kaldırır.
Agentic AI yönetişiminde insan gözetimini üç farklı seviyede düşünmek mümkün:
Human-in-the-loop: Kritik işlem gerçekleşmeden önce insan onayı gerekir.
Human-on-the-loop: Ajan belirlenen sınırlar içinde çalışır; insan süreci izler ve gerektiğinde müdahale eder.
Human-in-command: İnsan, sistem veya ajan üzerinde nihai durdurma yetkisine sahiptir.
Doğru model her süreç için aynı olmayacaktır.
Bir ajanın satış raporu hazırlamasıyla tedarikçi banka hesabı değiştirmesi aynı risk seviyesinde değerlendirilemez.
Bu yüzden doğru soru “insan onayı olacak mı?” değil: Hangi işlemde ne kadar insan kontrolü gerekli?
Basis, Security ve GRC ekiplerinin gündemine yeni işler geliyor
AI ajanlarını yalnızca uygulama veya yapay zekâ ekiplerinin konusu olarak görmek artık yeterli değil. Yeni ortamda Basis, IAM, Security, GRC, entegrasyon ve iş süreçleri ekiplerinin sorumlulukları birbirine daha fazla yaklaşacak.
Ajan envanteri tutulması, kimliklerinin yönetilmesi, erişim politikalarının belirlenmesi, MCP bağlantılarının kontrol edilmesi, telemetry verilerinin izlenmesi, anormal işlem hacminin tespit edilmesi ve kullanım dışı kalan ajanların yetkilerinin kaldırılması bu yapının doğal parçaları olacak.
Basis ekipleri açısından başka bir soru da var:
Ajan doğru çalışıyor olabilir; peki sistemi ne kadar yoruyor?
Yüzlerce paralel API çağrısı, sık çalışan backend işlemleri, entegrasyon trafiği veya kontrolsüz bir agent loop yalnızca güvenlik değil performans problemi de yaratabilir.
Dolayısıyla agent observability; CPU ve memory izlemekten daha geniş bir kavrama dönüşüyor. Oturum hacmi, araç çağrısı başarısı, işlem süresi, hata oranı ve kullanılan kaynakların birlikte izlenmesi gerekecek. SAP’nin Agent Hub ve Cloud ALM mimarisindeki yönelim de bunu destekliyor.
Ayrıca, ticari model de gözden kaçırılmamalı. SAP’nin kendi otonom ajanlarında 2026 için AI Units üzerinden tüketim bazlı fiyatlandırma uygulanıyor. Dolayısıyla gereksiz agent action üretimi zamanla yalnızca teknik ve performans açısından değil, maliyet gözlemlenebilirliği açısından da önem kazanacaktır.
Bu nedenle güvenlik ve performans kadar ajanların gereksiz işlem üretip üretmediğinin ekonomik olarak izlenmesi de zamanla operasyon yönetiminin bir parçası hâline gelecek.
Sonuç: Ajanları işe almadan önce kurallarını belirlemek gerekiyor
SAP’de AI ajanlarının yaygınlaşmasının önündeki asıl engel, büyük ihtimalle ajanların neler yapabildiği olmayacak. Asıl belirleyici, kurumların bu dijital aktörlere ne kadar güvenebildiği ve bu güveni hangi kontrollerle desteklediği olacak.
Bu nedenle canlıya alınacak her AI ajanını beş katmanda değerlendirmek gerekiyor: kimlik, yetki, sınır, iz ve fren. Bir kurum bu beş başlıkta net cevap veremiyorsa, ajan teknik olarak çalışıyor olsa bile yönetişim açısından üretime hazır sayılmamalı.
Kimliği belli olmayan bir ajanın sorumluluğu yönetilemez. Yetki sınırı tanımlanmayan bir ajan gereğinden fazla işlem yapabilir. Güvendiği veri kaynakları ve çağırabileceği araçlar sınırlandırılmamışsa doğru yetkilere sahip olsa bile yanlış yönlendirilebilir. İşlem izi tutulmuyorsa ne yaptığını açıklamak zorlaşır. Hata durumunda hızlı biçimde durdurulamıyorsa küçük bir problem kısa sürede operasyonel etkiye dönüşebilir.
Bize göre SAP’nin Agent Identity, AI Agent Hub, Agent Gateway, MCP yönetişimi ve OpenShell gibi alanlara aynı dönemde yatırım yapması, güvenlik ve yönetişimin artık agentic AI mimarisinin çevresinde duran yardımcı konular değil, doğrudan merkeze yerleşen bileşenler olduğunun güçlü bir işareti.
SAP dünyası yıllar içinde insan kullanıcılar için oldukça olgun bir kimlik, yetki, görev ayrılığı ve denetim kültürü geliştirdi. Şimdi sisteme yeni bir dijital aktör giriyor: insan kullanıcı değil, klasik teknik kullanıcı değil, yalnızca tavsiye veren bir chatbot da değil. Karar verebilen, araç kullanabilen ve işlem yapabilen bir aktör.
Bu yüzden AI ajanlarını üretim sistemlerine almak yalnızca yeni bir teknolojiyi devreye almak anlamına gelmiyor. SAP’nin yıllardır geliştirdiği kimlik, yetki, görev ayrılığı ve denetim modelini yeni bir dijital çalışan için yeniden düşünmek anlamına geliyor.
Bugün başlamak için 5 adım
- Kurumdaki mevcut ve planlanan AI ajanlarını envantere alın.
- Her ajan için iş sahibini, teknik sorumluyu, kullanıcı bağlamını ve erişim kapsamını tanımlayın.
- İlk pilotlarda mümkünse salt okunur veya düşük riskli senaryolarla başlayın.
- Acil durdurma mekanizmasını (kill switch), işlem limitlerini ve müdahaleden sorumlu ekibi canlıya geçmeden belirleyin.
- Log, audit trail ve telemetry gereksinimlerini canlıya almadan önce tanımlayın.
Sık Sorulan Sorular
Agent Identity yaklaşımı, ajanların SAP Cloud Identity Services içinde ayrı ve yönetilebilir varlıklar olarak kaydedilmesini; erişimlerinin, kullanıcı bağlamlarının ve yaşam döngülerinin yönetilmesini amaçlar. Böylece hangi kullanıcının hangi ajanı çağırabildiği ve ajanın hangi sınırlar içinde hareket ettiği daha kontrollü biçimde yönetilebilir. Mevcut yeteneklerin bir kısmının halen Early Adopter Care kapsamında olduğu dikkate alınmalıdır.
Tam olarak değil. Teknik kullanıcı veya servis hesabı benzeri mekanizmalar ajan mimarisinin parçası olabilir; ancak AI ajanlarında kimliğin yanı sıra amaç, araç erişimi, kullanıcı bağlamı, yaşam döngüsü ve çalışma politikalarının da yönetilmesi gerekir.
Kullanım senaryosuna ve ürün yeteneklerine göre değişir. Kritik işlemlerde human-in-the-loop (insanın karar döngüsünde olduğu model) yaklaşımıyla insan onayı zorunlu tutulabilir; daha düşük riskli süreçlerde ajan belirlenen sınırlar içinde çalışabilir. Ekim 2026 itibarıyla birçok senaryoda insan kullanıcı bağlamı ve yetkisi önemli olmaya devam etmektedir.
Klasik SoD kontrolleri kullanıcı ve rol kombinasyonlarına odaklanır. Ancak birden fazla ajan aynı iş hedefi doğrultusunda birlikte hareket ettiğinde, teknik olarak farklı kimliklere sahip olsalar bile süreç sonunda görev ayrılığı ihlali oluşabilir. Bu nedenle gelecekte kontrollerin ajanlar arası işlem zincirlerini de değerlendirmesi gerekebilir.
MCP, ajanların farklı araçlara ve veri kaynaklarına bağlanmasını kolaylaştırır. Ancak her yeni bağlantı güven sınırını genişletir. MCP sunucusunun güvenilirliği, hangi verilere eriştiği, hangi işlemleri çağırabildiği ve erişimin gerektiğinde ne kadar hızlı kesilebildiği önem kazanır.
Çünkü ajan, eriştiği bir e-posta, doküman, web içeriği veya başka bir harici veri kaynağındaki kötü niyetli talimatı güvenilir komut gibi yorumlayabilir. Bu nedenle yalnızca yetkilendirme değil; kaynak güveni, içerik kontrolleri ve kritik aksiyonlarda politika katmanları da önemlidir.
İlk adım ajanın durdurulması ve hatalı işlemlerin yayılmasının önlenmesidir. Bunun için acil durdurma mekanizması (kill switch), işlem limitleri, anomali tespiti ve müdahale sorumlulukları önceden tanımlanmalıdır. SAP’de oluşmuş iş belgelerini klasik veritabanı rollback mantığıyla geri almak her zaman mümkün olmadığı için, gerektiğinde iptal, ters kayıt veya düzeltme işlemleriyle telafi süreci yürütülür.