Kodlama aracısı telemetrisi: Hangi veriler gönderiliyor?

Kodlama aracısı telemetrisinin gerçek kapsamı

Kodlama aracısı telemetrisi, tek bir terim altında toplanan ancak dört ayrı veri akışından oluşur ve her akışın kendi denetim mekanizması vardır. Model çıkarımı (inference), istemlerinizi ve kodunuzu modeli sunan tarafa iletir; hiçbir ayar bu süreci devre dışı bırakamaz. Ürün analitiği ve kilitlenme raporları satıcıya, genellikle de satıcının ödeme yaptığı bir günlükleme (logging) şirketine gönderilir. Eğitim için veri saklama (retention), ağ düzeyinde değil, sözleşme düzeyinde bir konudur. Dördüncü akış ise genellikle gözden kaçırılan kısımdır: eklediğiniz her entegrasyon, sizin seçmediğiniz bir ana bilgisayara bağlantı açabilir.

Mevcut satıcı varsayılanlarının listesi, bu konunun en hızlı eskimeye yüz tutan kısmıdır. Bir sürüm güncellemesi varsayılan ayarı değiştirebilir; yeni bir özellik ise mevcut hiçbir anahtarın kapsamadığı bir hedef adresi ekleyebilir. Bu nedenle kalıcı yetkinlik, herhangi bir aracı üzerinde tekrarlanabilir bir denetim yapabilmektir: satıcının belgelerini okuyun, bu makinede hangi yapılandırmanın uygulandığını kontrol edin, süreci makinenin kendisinden izleyin ve ardından ödemeye razı olduğunuz denetimleri seçin. Aşağıdaki her komut, kendi makinenizde ve kendi trafiğiniz üzerinde çalıştıracağınız komutlardır.

Dört kategori ve neden farklı kontrollere ihtiyaç duydukları

Model çıkarım trafiği kaçınılmazdır. Ajan; isteminizi, okuduğu dosyaları, çalıştırdığı komutların çıktılarını ve kendi ürettiği metni bir model uç noktasına gönderir. Bu, ürünün çalışma şeklidir. Verilecek tek gerçek karar, veriyi kimin aldığıdır: başkası tarafından işletilen bir API mi, yoksa kendi çalıştırdığınız bir model mi? Bir kurumsal bulut hesabı (Bedrock, Vertex, Foundry) alıcıyı değiştirir, ancak akışı ortadan kaldırmaz. Bu yazının geri kalanındaki hiçbir şey çıkarım trafiğini azaltmaz, bu yüzden bunu zihninizde diğer üçünden ayrı tutun.

Ürün analitiği ve hata raporlama, farklı ana bilgisayarlara giden farklı bir akıştır. Kullanım sayaçları, gecikme süreleri, özellik bayrağı (feature-flag) sorguları ve yığın izlemeleri (stack traces) genellikle model API'si ile ilgisi olmayan ana bilgisayar adlarına ve sıklıkla üçüncü taraf bir hata izleme servisine gider. Tedarikçiler bunları genellikle "metrikler" ve "hata raporları" olarak belgeler ve her kategori için genellikle bir ortam değişkeni sağlar. Hacim çok düşüktür, bu nedenle bayt sayıları ile bunları bulamazsınız. Bant genişliğini değil, ana bilgisayar adlarını arıyorsunuz.

Saklama ve eğitim, paketler değil politikalardır. Tedarikçinin istemlerinizi tutup tutmadığı, ne kadar süreyle tuttuğu ve gelecekteki bir modeli eğitmek için kullanıp kullanmadığı, planınıza ekli şartlarda yazılıdır. Bireysel planlar ve ticari planlar genellikle farklılık gösterir ve sıfır saklama düzenlemesi genellikle ayrı bir sözleşmedir. tcpdump ile bunların hiçbirini doğrulayamazsınız, çünkü paket her iki durumda da aynı görünür. Şartları okuyun ve işvereniniz için önemliyse, bunu yazılı olarak alın.

Entegrasyonlar sessizce yeni bir sekme ekler. Bir MCP (model context protocol) sunucusu, eklenti pazarı, otomatik güncelleme denetimi, web arama aracı veya bir URL'yi getirmeden önce çözümleyen güvenlik denetimi: her biri, model uç noktası olmayan bir ana bilgisayara yapılan bir istektir. Sürprizlerin yaşandığı yer burasıdır; çünkü bir araç, yerel olduğunu varsaydığınız işi kendi servisi üzerinden yönlendirebilir ve bir sürüm, yapılandırmanızda tek bir satır bile değiştirmeden bunu yapmaya başlayabilir. Eklediğiniz her aracı, ağ üzerinde izleyene kadar yeni bir hedef olarak kabul edin.

Adım 1: Üretici belgeleri neyi kapsıyor?

Ajanınızın ayarlar referansını ve veri kullanımı sayfasını açın; metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace gibi terimleri içeren bir liste ile inceleyin. Bu terimlerin her biri genellikle ayrı bir anahtardır. Tam değişken isimlerini not edin, çünkü 2. adımda bunlar için grep komutu çalıştırılacaktır.

Bir terim sizi yanıltabilir. Birçok ajanda, belgelerdeki "telemetry" ifadesi, verileri kendi çalıştırdığınız bir toplayıcıya (collector) göndermek üzere yapılandırdığınız bir OpenTelemetry dışa aktarımını ifade eder; bu, verilerin üreticiye gitmesinin tam tersidir. Claude Code bunlardan biridir: CLAUDE_CODE_ENABLE_TELEMETRY=1 ayarı, OTEL_EXPORTER_OTLP_ENDPOINT içinde belirttiğiniz uç noktaya bir dışa aktarım başlatır ve bu, farklı bir devre dışı bırakma mekanizmasına sahip olan üreticinin kendi analitik verilerinden bağımsızdır. Herhangi bir ayar yapmadan önce verinin hangi yöne aktığını belirleyin.

Bir ana anahtar bekleyin ve bu anahtarın eksiklikleri olabileceğini göz önünde bulundurun. Ağustos 2026 itibarıyla, Claude Code içindeki CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ayarı; metrikleri, hata raporlarını, geri bildirim komutunu ve oturum anketlerini birlikte kapatır. Ancak aynı belgeler, bu ayarın WebFetch alan adı güvenlik denetimini kapsamadığını belirtir; bu denetim, getirmek üzere olduğunuz ana bilgisayar adını (hostname) üretici API'sine gönderir ve kendine ait ayrı bir ayarı vardır. Bu, tek bir ürüne yönelik bir şikayet değildir. Bu, her yerde karşılaşılan sorunun doğasıdır: bir ana anahtar, yalnızca yazıldığı tarihte mevcut olan kategorileri kapsar.

Devre dışı bırakma işleminin size bir maliyeti olabileceğini de bekleyin. Aynı belgeler, telemetriyi devre dışı bırakmanın, bazı özelliklerin bağlı olduğu "feature-flag" değerlendirmesini de devre dışı bıraktığını belirtir. Dolayısıyla gizlilik için açılan bir anahtar, kullandığınız bir özelliği, ikisi arasında bağlantı kuran bir hata mesajı vermeden kapatabilir. Sadece bayrak ismini değil, bayrağın yanındaki cümleyi de okuyun.

Adım 2: Hangi yapılandırma gerçekten uygulandı?

Yazdığınız bir ayar, uygulanan ayar olmayabilir. Aracılar, yapılandırmayı birden fazla dosyadan birleştirir ve bunlardan biri, başka birinden kopyaladığınız deponun içinde yer alır. İşe kendi kabuğunuzun ortamından başlayın.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

Ardından, aracın okuduğu her yapılandırma dosyasını, belgelerde belirtilen sırayla yazdırın. Claude Code için, Ağustos 2026 itibarıyla bu dosyalar; kullanıcı dosyası, iki proje dosyası ve Linux üzerinde yönetilen bir ilke dizinidir.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

git clone ile gelen bir proje dosyası, bir başkası tarafından yazılmış yapılandırmadır ve kullanıcı dosyanızın devre dışı bıraktığı özellikleri yeniden etkinleştirebilir. Eğer aracın hangi kaynakları yüklediğini listeleyen bir durum komutu varsa, bu en hızlı kesin bilgiyi sağlar: Claude Code, yüklenen yapılandırma kaynaklarını /status içinde yazdırır.

En güçlü kontrol yöntemi, herhangi bir dosyayı değil, çalışan süreci okumaktır. Öncelikle araca kendi Linux kullanıcı hesabını atayın; bu, bu yazıdaki her komutu kısaltacaktır. Ardından, sürecin başlatıldığı ortamı okuyun.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ, sürecin yürütme anındaki değişkenlerini gösterir; bu sayede .bashrc dışa aktarma işleminizin systemd tarafından başlatılan bir servise ulaşmadığı durumları yakalar. Eğer ayarladığınız bir değişken burada görünmüyorsa, dotfile dosyalarınız ne derse desin, bu değişken hiçbir zaman yürürlükte olmamıştır.

Adım 3: Hangi ana bilgisayarlara bağlanıyor?

Ajanın çalıştığı hesap tarafından filtrelenmiş açık soketlerle başlayın.

sudo ss -tnpe state established

-e, her satıra bir uid: alanı ekler; böylece süreç isimlerini okumak zorunda kalmadan ajanın bağlantılarını tarayıcınızın bağlantılarından ayırabilirsiniz. Uzak adresleri not edin ve ardından arkalarındaki isimleri alın. İsimlerin en temiz kaynağı TLS (transport layer security) el sıkışmasıdır; çünkü her yeni bağlantı, istemcinin talep ettiği ana bilgisayar adını içeren bir SNI (server name indication) alanı taşıyan ClientHello ile başlar.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Her yeni bağlantı için bir satır alırsınız; bu tam olarak istediğiniz envanterdir: model API, güncelleme sunucusu, analiz sunucusu, hata izleyici ve bir entegrasyonun eklediği her şey. Boş bir isim sütunu, istemcinin ECH (encrypted client hello) kullandığı anlamına gelir; bu durumda ana bilgisayar adı ağ üzerinde görünmez ve hedef IP adresine, ters DNS sorgusuna veya 4. adımdaki proxy yöntemine geri dönersiniz.

DNS (domain name system) görünümü, ajanın tamamlamadığı bağlantılar için bile arattığı isimleri gösterdiğinden yararlı bir çapraz kontrol sağlar.

sudo tcpdump -ni any -l 'udp port 53'

Her sorgu satırı, A? host.example.net. (39) biçiminde kayıt türü ve isim ile biter. Dış arayüz yerine any üzerinde yakalama yapın; çünkü systemd-resolved ile uygulama 127.0.0.53 üzerindeki yerel bir stub dinleyicisi ile konuşur ve dışarıyla sadece bu stub iletişim kurar. Ajan açıkça çalışırken hiçbir DNS trafiği görmüyorsanız, o çalışma zamanı DNS over HTTPS kullanıyordur ve isimleri yalnızca 4. adımda elde edebilirsiniz.

Ajan gerçek işleri yaparken yakalama gerçekleştirin. Bir oturum başlatın, bir dosya okutun, bir komut çalıştırın, bir şeyde hata vermesini sağlayın. Başlangıçta bir kez tetiklenen veya yalnızca bir istisna fırlatıldığında oluşan trafik, boşta duran bir yakalamada asla görünmez; boşta duran bir yakalama, denetimin rahat ama yanlış bir sonuca ulaşmasının en yaygın yoludur.

Adım 4: İsteklerin içeriğinde ne var?

Ana makine adları (hostname) size kiminle iletişim kurulduğunu söyler. İçeriği görmek için kontrolünüz altındaki bir proxy'yi aracın önüne yerleştirin ve yalnızca o çalışma zamanı için proxy'nin sertifika yetkilisine (CA) güvenin. mitmproxy bu iş için kullanılan standart araçtır. Proje, mitmproxy.org adresinden sağlanan bağımsız ikili dosyaları önerir ve uv tool install mitmproxy yolunu Python paketi yöntemi olarak belgeler.

mitmdump -w /tmp/agent-flows.mitm

İlk çalıştırma, mitmproxy-ca-cert.pem dosyasının sertifikanın kendisi olduğu ~/.mitmproxy/ dizinine bir CA yazar. Aracı başlatacağınız kabuk (shell) üzerinde, istemciyi proxy'ye ve ilgili sertifikaya yönlendirin.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

Birçok araç CLI'ı Node programlarıdır ve Node, süreç başladığında NODE_EXTRA_CA_CERTS değişkenini okur; bu nedenle değişkeni aracı başlatmadan önce dışa aktarın (export), başka bir terminalde sonradan yapmayın. Python istemcileri REQUESTS_CA_BUNDLE veya SSL_CERT_FILE değişkenlerini okur; standart kütüphaneyi kullanan bir Go ikili dosyası ise Linux üzerinde SSL_CERT_FILE değişkenini okur. Aracı suçlamadan önce yolun çalıştığını curl ile doğrulayın.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Çalışan bir proxy 200 çıktısını verir ve istek mitmdump çıktısında görünür. Güvenilmeyen bir CA, curl: (60) SSL certificate problem: self-signed certificate in certificate chain hatasına neden olur; Node tabanlı bir araçtan gelen eşdeğer hata ise SELF_SIGNED_CERT_IN_CHAIN kodunu taşır. Kaydedilen akışları daha sonra konsol görüntüleyici ile okuyun; burada bir isteği açıp başlıklarını ve gövdesini inceleyebilirsiniz.

mitmproxy -r /tmp/agent-flows.mitm

Dört sonuç üzerinde durulmalıdır. İstekleri görüyorsanız, onları okuyun ve kararınızı verin. Araç bir sertifika hatasıyla başlamayı reddediyorsa, bu durum çalışma zamanındaki bir güven sorunudur ve satıcı hakkında bir bulgu değildir. Yalnızca model API'sini görüyorsanız, diğer kategoriler kapalıdır veya tetiklemediğiniz bir olay üzerinde çalışıyorlardır. Araç açıkça çalıştığı halde hiçbir şey görmüyorsanız, istemci proxy ortam değişkenlerini yok sayıyor veya sertifikalarını sabitliyordur (pinning); bu durumda hiçbir uygulama ayarının size doğruyu söylediğine güvenilemez. En önemli sonuç bu sonuncusudur ve sizi 3. adıma geri gönderir; çünkü bir paket yakalama (packet capture) işlemi, bir bağlantıyı görmezden gelmeye ikna edilemez.

Kontroller, en zayıftan en güçlüye

Opt-out ayarları. En ucuz ve en zayıf yöntemdir; çünkü satıcının bu ayarlara uymasına ve halihazırda var olan bir kategoriyi kapsamasına dayanır. Bu ayarları, yeniden başlatma ve yeni terminal oturumlarında kalıcı olacak şekilde kullanıcı ayarları dosyanıza veya shell profilinize ekleyin. Bunu yaparken DO_NOT_TRACK=1 eklemeyi unutmayın: Bu, bazı ajanlar dahil olmak üzere birçok komut satırı aracının saygı gösterdiği bir kuraldır ve hiçbir maliyeti yoktur. Güncelleme sonrasında kapsam değişebileceği için 3. adımı tekrar çalıştırın.

Egress kısıtlaması. Burada rica etmeyi bırakıp zorlamaya başlarsınız. Ajanı kendi kullanıcı hesabı altında çalıştırın, ardından bu kullanıcıya sadece loopback ve DNS erişimi verip geri kalanını engelleyin. Bu yöntem kendi tablosunu oluşturur, dolayısıyla mevcut güvenlik duvarı kurallarınıza dokunmaz.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

Kuralı sudo nft -f /etc/nftables.d/agent.nft ile uygulayın, sayacı sudo nft list table inet agentegress ile izleyin ve engellenen bağlantıları sudo journalctl -k -g agent-egress-drop ile okuyun. Beklemediğiniz bir ana bilgisayar adı (hostname) ile artan bir engelleme sayacı, bu çalışmanın temel amacıdır. İki dürüst sınır vardır. meta skuid, soketin sahibi olan kullanıcıyla eşleşir; bu nedenle kural, yalnızca ilgili hesap başka bir kullanıcıya dönüşemediği sürece geçerlidir: Ajan için parolasız sudo kullanımı, bu kuralı bir öneri seviyesine indirger. Ayrıca UDP 53 portunu herhangi bir sunucuya açık bırakmak, sorgu isimleri üzerinden veri sızdırılabilecek bir kanal oluşturur; bu nedenle tehdit modeliniz gerektiriyorsa, ajanın çözümleyicisini (resolver) kendi yönettiğiniz bir ana bilgisayara yönlendirerek bu kanalı da kapatın. Ana bilgisayar adı izin listeleri (allowlists), nftables yerine bir proxy içinde tutulmalıdır; çünkü API uç noktaları, IP adresleri sürekli değişen içerik dağıtım ağlarının (CDN) arkasında yer alır. Bu kontrolün maliyeti, sistemin bozulması ve bakım gereksinimidir: Paket kurulumları, SSH üzerinden git ve ajanın kendi güncelleme kontrolleri, siz izin verene kadar başarısız olur ve bu listeyi artık sizin yönetmeniz gerekir. Eğer bu kurulumu bir dizüstü bilgisayar yerine sunucuda yapıyorsanız, aynı hesap ve güvenlik duvarı düzeni Claude Code'u bir VPS üzerinde güvenli çalıştırma rehberinin temelini oluşturur.

Tek kullanımlık makine. Ajana, önemsediğiniz hiçbir kimlik bilgisini barındırmayan ve görev sonunda yok edilen bir sanal makine (VM) atayın. Bu yöntem ajanın gönderdiklerini azaltmaz, ajanın gönderme erişimine sahip olduğu veriyi azaltır; genellikle asıl önemsemeniz gereken risk budur. Bunu yukarıdaki egress kurallarıyla birleştirin; çünkü sınırsız internet erişimine sahip yeni bir sanal makine, yakalama alanınızdaki her ana bilgisayara ulaşabilir. Yöntem ve her seferinde yeniden oluşturmanız gereken durum, kodlama ajanlarını tek kullanımlık bir VM'de çalıştırma rehberinde, boyutlandırma sorusu ise bir kodlama ajanını VPS üzerinde çalıştırma rehberinde ele alınmıştır.

Modeli kendi sunucunuzda barındırma (Self-hosting). Çıkarım (inference) akışını ortadan kaldıran tek kontrol budur, çünkü istem (prompt) donanımınızdan asla dışarı çıkmaz. Bunun maliyeti gerçektir: Kapalı bir modeli kendi sunucunuzda barındıramazsınız, bu nedenle açık ağırlıklı modelleri seçmeli ve zorlu görevlerde bir yetenek farkını kabul etmelisiniz; ayrıca bunları çalıştırmak için gerekli donanımı sağlamalısınız. Bu takas, Claude'u kendi sunucunuzda barındırıp barındıramayacağınız ve Claude Code, Cursor, Codex ve Copilot arasındaki farklar konularında detaylandırılmıştır.

Bu dört kontrolün hiçbiri, ajanın diskte okumasına izin verilen verileri değiştirmez ve çıkarım trafiği, okuduğu her şeyi taşır. Eğer çalışma dizininde bir .env dosyası varsa, ajan bir değişken ismini aradığı (grep) anda bu dosya modele gönderilir. Bu materyali erişim dışında tutmak ayrı bir iştir ve gizli bilgileri bir yapay zeka ajanının bağlamından uzak tutma rehberinde ele alınmıştır.

Her güncellemeden sonra kontrol edilmesi gerekenler

1. Satıcının ayarlarını ve veri kullanım sayfalarını, yeni anahtarlar ve yeni adlandırılmış servisler açısından bir önceki kayıtlarınızla karşılaştırın.
2. Çalışan süreçte devre dışı bırakma tercihlerinizin hala geçerli olduğunu doğrulamak için /proc/<pid>/environ üzerinden süreç ortamını tekrar okuyun.
3. Proje ayar dosyalarını tekrar yazdırın; çünkü bir git pull, bir iş arkadaşınızın değiştirdiği bir yapılandırma dosyasını sisteme dahil etmiş olabilir.
4. Gerçek bir iş oturumu boyunca SNI yakalamasını çalıştırın ve ana bilgisayar adı listesini bir önceki listenizle karşılaştırın.
5. Güvenlik duvarı düşürme sayacını kontrol edin; yeni bir hedef genellikle başka herhangi bir yerde fark etmeden önce orada görünür.

Bu işlem yaklaşık on dakika sürer ve sürecin eskimeyen tek parçasıdır. Ağustos 2026'da doğruladığınız bir varsayılan ayar, Ağustos 2026'ya ait bir gerçektir. Yakalama ise bugüne ait bir gerçektir.

FAQ

Kodlama aracımın kodumu modele göndermesini engelleyebilir miyim?

Hayır; bunu yapabildiğini iddia eden her ayar, aslında başka bir işlevi tanımlamaktadır. İsteminizi, aracın okuduğu dosyaları ve çalıştırdığı komutların çıktılarını model uç noktasına göndermek, çıkarım (inference) sürecinin temelidir; bu nedenle tek değişken, veriyi kimin aldığıdır. Aracı bir şirket bulut hesabına veya kendi barındırdığınız bir modele yönlendirerek alıcıyı değiştirebilir, okunmasına izin verilen dosyaları kısıtlayarak gönderilen veri miktarını azaltabilirsiniz. Analitik ve hata raporlamayı kapatmak, bu veri akışını hiçbir şekilde etkilemez.

Kodlama aracımın hangi sunuculara bağlandığını nasıl görebilirim?

Aracı kendi Linux kullanıcısı altında çalıştırın ve ardından aracı kullanırken her yeni bağlantının TLS ClientHello paketini yakalayın: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. Her bağlantı için hedef adresi ve talep edilen ana bilgisayar adını içeren tek bir satır görünür. İsimleri sudo tcpdump -ni any 'udp port 53' ile çapraz kontrol edin; 127.0.0.53 üzerindeki yerel çözümleyici saplaması (resolver stub) sorguyu ilk önce ele aldığı için yakalama işlemini any üzerinde gerçekleştirin. Başlangıç pingleri ve kilitlenme raporları boşta duran bir yakalamada görünmeyeceğinden, yakalama işlemini araç gerçek bir iş yaparken gerçekleştirin.

Araç çalışırken proxy'mde hiçbir trafik görünmüyor. Sorun nedir?

İstemci ya HTTP_PROXY ve HTTPS_PROXY değişkenlerini yok sayıyordur ya da sertifikalarını sabitleyip (pinning) CA'nizi reddediyordur. Önce yolu curl ile test edin: Eğer curl proxy üzerinden internete erişebiliyor ancak araç akış listesinde görünmüyorsa, araç proxy ortam değişkenlerini kullanmıyordur. Bazı çalışma zamanları (runtime) CA'nın belirli bir şekilde sağlanmasını gerektirir; özellikle Node, NODE_EXTRA_CA_CERTS değişkenini yalnızca süreç başlangıcında okur, bu nedenle aracı başlattıktan sonra dışa aktarmanın (export) bir etkisi olmaz. Proxy trafiği göremiyorsa, hiçbir uygulama ayarının atlatamayacağı paket yakalama yöntemine geri dönün.

Telemetriyi kapatmak kodumun eğitim için kullanılmasını engeller mi?

Hayır. Analitik ve kilitlenme raporlama, çıkarım sürecinden farklı bir akıştır; bu nedenle bunları devre dışı bırakmak kullanım sayaçlarını ve yığın izlerini (stack trace) kaldırır, ancak her istemin modele gönderilmeye devam etmesini engellemez. Bu istemlerin saklanıp saklanmadığı ve gelecekteki bir modeli eğitip eğitmediği, planınızın şartları tarafından belirlenir; tüketici planları ile ticari planlar genellikle bu konuda farklılık gösterir. Bu, paket yakalayarak değil, sözleşme okuyarak anlaşılabilecek bir durumdur; bu nedenle planınızın veri kullanım sayfasını kontrol edin ve kritik durumlarda, ilk oturumdan önce ticari veya sıfır saklama (zero-retention) anlaşması yapın.