AI Agent Kurulumu Nasıl Yapılır? Kendi Sunucunuzda Adım Adım

AI agent kurulumu nedir, kendi sunucunuzda nasıl yaparsınız?

AI agent kurulumu, bir dil modelini araçlara, hafızaya ve iş akışlarına bağlayan yazılımı kendi sunucunuzda çalışır hale getirme işidir. Pratikte bir VPS üzerine Docker kurarsınız, n8n gibi bir orkestratörü ve gerekiyorsa Ollama gibi yerel model sunucusunu başlatırsınız, ardından HTTPS, sır yönetimi ve yetki sınırlarıyla güvenceye alırsınız.

Biz Talha Aslan ve ekibi olarak dijital pazarlama ve web tarafında çalışıyoruz; hosting firması değiliz. Bu yüzden bu rehberdeki komutları ve ayar adlarını n8n, Ollama, Docker ve OWASP'ın resmi belgelerine dayandırıyoruz. Amacımız, kendi VPS'ini yöneten bir yazılımcının ya da teknik bilgisi olan bir site sahibinin kurulumu adım adım anlamasını sağlamak.

Ajanların pazarlamada nerede işe yaradığını, hangi senaryolarda zaman kazandırdığını ayrı yazımızda anlattık: pazarlamada AI agent nedir ve nasıl geliştirilir. Burada kullanım senaryolarını tekrar etmiyoruz. Bunun yerine sunucu tarafına, yani mimariye, kuruluma, güvenliğe ve bakıma odaklanıyoruz.

AI agent ile sohbet botu ve klasik otomasyon arasındaki fark ne?

Sohbet botu, kullanıcının sorusuna metinle cevap verir ve genellikle orada durur. Klasik otomasyon ise önceden çizilmiş bir yolu izler: bir form gelir, kayıt tabloya yazılır, e-posta gider. Her adımı siz belirlersiniz, sistem hiçbir karar vermez.

AI agent bu ikisinin arasında durur. Bir hedef alır, hangi aracı hangi sırayla kullanacağına dil modeliyle karar verir ve sonucu değerlendirip bir sonraki adımı seçer. Örneğin bir destek talebini okuyup sipariş sistemini sorgulayabilir, ardından taslak bir cevap hazırlayabilir.

Bu karar verme yeteneği aynı zamanda riskin kaynağıdır. Çünkü ajan, sizin tek tek onaylamadığınız araç çağrıları yapar. Dolayısıyla kendi sunucunuzda bir ajan çalıştırdığınızda yalnızca bir uygulama barındırmış olmazsınız; kararlarını sınırlamanız gereken bir yazılım işletmiş olursunuz. Dil modellerinin genel işleyişini merak ediyorsanız büyük dil modelleri (LLM) rehberimize göz atabilirsiniz.

Bir ajanı neden kendi sunucunuzda çalıştırmak istersiniz?

Kendi sunucunuzda çalıştırma fikri genellikle üç ihtiyaçtan doğar. Hazır bir bulut ajan platformu hızlı başlatır; ancak verinin nereden geçtiği, ne kadar ödediğiniz ve platform değişirse ne olacağı üzerinde kontrolünüz sınırlı kalır.

• Veri gizliliği: İş akışlarınız, müşteri kayıtlarınız ve kimlik bilgileriniz kendi sunucunuzdaki veritabanında durur. Yerel model kullanırsanız istem metni de sunucudan çıkmaz.
• Maliyet kontrolü: Sabit bir sunucu ücreti ödersiniz. Platformun iş akışı ya da çalıştırma başına fiyatlandırmasına bağlı kalmazsınız; model API'si kullanıyorsanız token tüketimini kendiniz izlersiniz.
• Bağımlılığı azaltma: Açık kaynak bir orkestratör kullandığınızda iş akışlarını dışa aktarabilir, model sağlayıcısını değiştirebilir, sunucuyu başka bir firmaya taşıyabilirsiniz.

Bununla birlikte bu avantajların hiçbiri kendiliğinden gelmez. Örneğin veri gizliliği, sunucuyu doğru güvenceye aldığınız sürece geçerlidir. Açık bırakılmış bir yönetim paneli, bulut platformundan çok daha büyük bir risk yaratır.

Hangi durumlarda kendi sunucunuz yanlış tercih olur?

Dürüst olmak gerekirse, birçok işletme için kendi sunucusunda ajan çalıştırmak gereksiz bir yüktür. n8n'in kendi kurulum belgesi bile kendi sunucunda barındırmayı deneyimli kullanıcılara önerir ve hataların veri kaybına, güvenlik sorunlarına ve kesintiye yol açabileceğini açıkça yazar.

Şu durumlarda yönetilen bir hizmeti tercih etmenizi öneririz:

• Bakım yükü: İşletim sistemi güncellemelerini, Docker imajlarını ve yedekleri düzenli takip edecek kimse yoksa sunucu zamanla güvenlik açığına dönüşür.
• Model kalitesi: Küçük bir VPS'te çalışan yerel modeller, büyük bulut modellerinin akıl yürütme kalitesine çoğu zaman yetişmez. Karmaşık görevlerde ajan daha sık hata yapar.
• Güvenlik sorumluluğu: Kendi sunucunuzda olan her olay sizin sorumluluğunuzdur. Saldırı tespiti, kayıt incelemesi ve olay müdahalesi de buna dahildir.
• Kritik süreçler: Ödeme, fatura ya da sağlık verisi gibi hassas işlemlerde hata payı düşük olmalı; burada deneyimli bir ekip şarttır.

Kısacası, kendi sunucunuz ancak onu yönetecek zamanınız ve bilginiz varsa avantajdır.

Kendi sunucunuzdaki bir ajanın mimarisi hangi parçalardan oluşur?

Kendi sunucunuzda çalışan bir ajanı dört katmanda düşünmek işi kolaylaştırır. Her katman ayrı bir konteynerde ya da harici bir serviste çalışabilir; böylece bir parçayı değiştirdiğinizde diğerlerini bozmazsınız.

1. Orkestratör: Ajanın beynini çalıştıran katmandır. n8n gibi açık kaynak bir iş akışı aracını görsel olarak kurabilir ya da Python veya JavaScript tabanlı bir ajan çatısıyla kod yazarak ilerleyebilirsiniz.
2. Model: Kararları veren dil modelidir. Bir bulut sağlayıcısının API'sine bağlanabilir ya da Ollama gibi yerel bir model sunucusu çalıştırabilirsiniz.
3. Araçlar ve entegrasyonlar: Ajanın dokunduğu sistemlerdir. CRM, e-posta, takvim, tablo, kendi API'leriniz ya da web araması bu katmandadır.
4. Hafıza ve veritabanı: İş akışı tanımlarını, çalıştırma geçmişini, kimlik bilgilerini ve gerekiyorsa konuşma hafızasını tutar. n8n varsayılan olarak SQLite kullanır, PostgreSQL desteği de vardır.

Bu yazıda örnek olarak n8n ve Ollama'yı kullanıyoruz, çünkü ikisi de açık kaynak ve resmi Docker belgeleri ayrıntılı. Yine de aynı mimari, kod tabanlı bir çatıyla da birebir geçerlidir. Önemli olan, her katmanın erişimini ayrı ayrı sınırlamaktır.

Bulut API mi, yerel model mi: hangisini seçmelisiniz?

Model katmanı, kurulumun donanım ihtiyacını ve gizlilik düzeyini en çok belirleyen karardır. Aşağıdaki tablo iki yaklaşımı genel hatlarıyla karşılaştırıyor; rakam vermiyoruz, çünkü fiyatlar ve donanım gereksinimi seçtiğiniz modele göre değişir.

Birçok projede karma bir yol mantıklıdır. Örneğin hassas metinleri yerel modelde özetler, karmaşık akıl yürütme gerektiren adımlarda bulut modeline başvurursunuz. Ancak bu durumda hangi verinin dışarı çıktığını belgelemeniz gerekir.

AI agent kurulumu için ne kadar donanım gerekir?

Donanım ihtiyacı, AI agent kurulumunda modeli nerede çalıştırdığınıza bağlıdır. Yalnızca bulut API'si kullanıyorsanız sunucu yalnızca orkestratörü, veritabanını ve ters vekili taşır. Bu durumda küçük bir VPS çoğu iş akışı için yeterli olur, çünkü ağır hesaplama sağlayıcının tarafında gerçekleşir.

Yerel model çalıştırmak ise tabloyu tamamen değiştirir. Model, çalışırken belleğe yüklenir; dolayısıyla seçtiğiniz modelin boyutu kadar boş RAM ya da GPU belleği gerekir. Ollama'nın resmi Docker belgesi, NVIDIA GPU ile çalıştırmak için önce NVIDIA Container Toolkit kurmanızı ister. GPU olmadan da çalışır, ama yanıt süresi belirgin biçimde uzar.

Somut rakam vermiyoruz, çünkü gereksinim modelden modele değişir. Bunun yerine şu sırayı öneririz: önce kullanacağınız modelin sayfasındaki boyut bilgisine bakın, sonra sunucunuzun boş belleğini kontrol edin, en son da gerçek bir iş akışıyla yük testi yapın.

VPS, VDS ve bulut sunucu arasındaki farkı VPS, VDS ve bulut sunucu karşılaştırmamızda anlattık. Bellek sınırına yakın çalışan küçük sunucularda bir takas alanı da hayat kurtarır; ancak takas alanı yerel model için gerçek RAM'in yerini tutmaz.

Kuruluma başlamadan önce neleri hazırlamalısınız?

Komutlara geçmeden önce altyapının hazır olması, sonradan yapacağınız düzeltmeleri azaltır. Aşağıdaki listeyi sırayla tamamlamanızı öneririz:

1. Sunucu: Güncel bir Linux dağıtımı çalışan, root yerine sudo yetkili bir kullanıcıyla eriştiğiniz bir VPS.
2. Docker ve Docker Compose: Docker'ın resmi kurulum belgesindeki paket deposu yöntemiyle kurun. Konteyner mantığına yabancıysanız önce Docker nedir rehberimizi okuyun.
3. Alan adı ve DNS: Ajan için ayrı bir alt alan adı açın ve A kaydını sunucunun IP adresine yönlendirin. Kaydın yayıldığını DNS sorgulama aracımızla kontrol edebilirsiniz.
4. SSH güvenliği: Parola girişini kapatıp anahtarla giriş yapın. Adımları swap oluşturma ve SSH güvenliği yazımızda bulabilirsiniz.
5. Model erişimi: Bulut modeli kullanacaksanız sağlayıcıdan bir API anahtarı alın ve harcama limiti tanımlayın.

Docker komutlarıyla uğraşmak istemiyorsanız, açık kaynak bir PaaS paneli de seçenektir. Coolify rehberimizde bu yaklaşımı anlattık. Yine de aşağıdaki güvenlik ilkeleri panel kullansanız da geçerlidir.

AI agent kurulumu için Docker Compose iskeleti nasıl görünür?

Aşağıdaki dosya, n8n ve Ollama'yı aynı Compose projesinde çalıştıran bir iskelettir. İmaj adlarını, portu ve veri yollarını n8n ve Ollama'nın resmi Docker belgelerinden aldık. Gerçek alan adı yerine example.com kullandık; kendi değerlerinizi koyun.

services:
  n8n:
    image: n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=agent.example.com
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://agent.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=Europe/Istanbul
      - TZ=Europe/Istanbul
    volumes:
      - n8n_data:/home/node/.n8n
  ollama:
    image: ollama/ollama
    restart: always
    volumes:
      - ollama:/root/.ollama
volumes:
  n8n_data:
  ollama:

Dikkat edin, n8n portunu yalnızca 127.0.0.1 adresine bağladık; n8n'in resmi Compose örneği de aynı yaklaşımı izler. Ollama için ise hiç port yayınlamadık. Çünkü n8n, aynı Compose ağı üzerinden Ollama'ya servis adıyla ulaşır. Üretimde imajları sabit bir sürüm etiketiyle çekmenizi öneririz; böylece güncellemeyi siz kontrol edersiniz. PostgreSQL kullanmak isterseniz n8n'in resmi barındırma deposundaki PostgreSQL örneğini temel alın.

Dosyayı kaydettikten sonra docker compose up -d komutuyla başlatır, docker compose logs -f n8n ile kayıtları izlersiniz.

Sırları ortam değişkenlerinde nasıl saklarsınız?

API anahtarı, şifreleme anahtarı ve veritabanı parolası gibi sırları Compose dosyasına doğrudan yazmayın. Bunun yerine aynı dizinde bir .env dosyası açar, Compose dosyasında değişken adıyla çağırırsınız. Böylece Compose dosyasını bir Git deposunda paylaşsanız bile sırlar dışarı çıkmaz.

# .env (örnek, gerçek değer yazmayın)
N8N_ENCRYPTION_KEY=buraya-uzun-rastgele-bir-deger

# rastgele değer üretmek için
openssl rand -hex 32

# dosya izinlerini daraltın
chmod 600 .env

n8n'in resmi belgesine göre n8n, ilk açılışta rastgele bir şifreleme anahtarı üretir ve bunu veri dizinine kaydeder. Kimlik bilgilerini veritabanına yazmadan önce bu anahtarla şifreler. Dolayısıyla bu anahtarı kaybederseniz, yedekten geri döndüğünüz veritabanındaki kimlik bilgilerini okuyamazsınız.

Bu yüzden şu üç kuralı uygulayın: .env dosyasını .gitignore listesine ekleyin, şifreleme anahtarını parola yöneticisinde ayrıca saklayın ve bulut model anahtarlarını n8n'in kimlik bilgisi ekranından girin. Ayrıca model sağlayıcısında her proje için ayrı anahtar açarsanız, sızıntı durumunda yalnızca o anahtarı iptal edersiniz.

Ters vekil ve HTTPS bağlantısını nasıl kurarsınız?

n8n'i doğrudan internete açmak yerine önüne bir ters vekil koyarsınız. Ters vekil 443 portunda HTTPS'i karşılar, trafiği yalnızca yerel adrese bağlı n8n konteynerine iletir. n8n'in resmi belgesi bu durumda N8N_PROXY_HOPS değerini 1 yapmanızı ve vekilin X-Forwarded başlıklarını iletmesini ister.

server {
    listen 443 ssl;
    server_name agent.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Sertifika satırlarını Certbot'un nginx eklentisi sizin için ekleyebilir; sudo certbot --nginx -d agent.example.com komutu bunu yapar. Upgrade başlıkları, editörün canlı bağlantısının kopmaması içindir. Nginx'i sıfırdan kurmak için nginx kurulum rehberimize, arayüzle yönetmek için nginx reverse proxy ve Nginx Proxy Manager yazımıza bakın. Kurulumdan sonra sertifikayı SSL sorgulama aracımızla doğrulayın.

Yerel modeli Ollama ile ajana nasıl bağlarsınız?

Ollama konteyneri ayağa kalktıktan sonra modeli indirmeniz gerekir. Model adını Ollama'nın model kütüphanesinden seçersiniz; aşağıdaki komutta yer tutucu kullandık.

docker compose exec ollama ollama pull MODEL_ADI
docker compose exec ollama ollama list

Ardından n8n arayüzünde Ollama kimlik bilgisini açar ve temel adres olarak http://ollama:11434 yazarsınız. Bu adres yalnızca Compose ağı içinde çalışır; dışarıdan erişilemez. Ollama'nın resmi SSS sayfası da sunucunun varsayılan olarak yalnızca 127.0.0.1 adresine bağlandığını, ağa açmak için OLLAMA_HOST değişkenini değiştirmeniz gerektiğini belirtir.

Bizim önerimiz, Ollama'yı internete hiç açmamaktır. Başka bir makineden erişmeniz gerekiyorsa, önüne kimlik doğrulaması yapan bir ters vekil koyun ya da VPN üzerinden bağlanın. Ayrıca modelin bellekte ne kadar kalacağını ayarlayan seçenekleri resmi belgeden kontrol edin. Böylece kullanılmayan model belleği gereksiz yere işgal etmez.

Son olarak, ajanın ilk iş akışını küçük bir testle başlatın. Örneğin yalnızca bir metni özetleyen, hiçbir araca dokunmayan bir akış kurun. Model yanıt veriyorsa araçları tek tek ekleyin.

SSH, güvenlik duvarı ve Docker portlarını nasıl korursunuz?

Sunucu güvenliğinin temeli, yalnızca gereken portları açık bırakmaktır. Bir ajan sunucusunda genellikle SSH, HTTP ve HTTPS yeterlidir. Ubuntu'da ufw ile bunu şöyle yaparsınız:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Ancak burada önemli bir tuzak var. Docker'ın resmi belgesi, Docker ile yayınladığınız konteyner portlarının trafiğinin ufw kurallarına ulaşmadan yönlendirildiğini açıkça yazar. Yani Compose dosyasında bir portu 0.0.0.0 üzerinden yayınlarsanız, ufw kapalı gösterse bile o port dışarıdan erişilebilir olabilir. Bu nedenle iskelette n8n portunu 127.0.0.1 adresine bağladık ve Ollama portunu hiç yayınlamadık.

Ayrıca SSH'ye yönelik kaba kuvvet denemelerine karşı Fail2ban kurmanızı öneririz; kurulumu Fail2ban rehberimizde anlattık. Kurulumdan sonra dışarıdan bir port taraması yaparak yalnızca beklediğiniz portların açık olduğunu doğrulayın.

Prompt injection ajanınız için neden en büyük risk?

Prompt injection, yani istem enjeksiyonu, modele verilen girdinin modelin davranışını istenmeyen biçimde değiştirmesidir. OWASP'ın büyük dil modeli uygulamaları için hazırladığı LLM01 Prompt Injection sayfası bu riski listenin ilk sırasına koyar ve iki türünü ayırır.

Doğrudan enjeksiyonda kullanıcı, sohbet kutusuna yazdığı metinle modeli yönlendirir. Dolaylı enjeksiyonda ise saldırı, ajanın okuduğu bir web sayfasında, e-postada ya da belgede gizlidir. Ajan bu içeriği işlerken içindeki talimatları kendi görevi sanabilir.

Bir ajanın sohbet botundan farkı da burada ortaya çıkar. Sohbet botu kandırılırsa yanlış bir cevap verir. Araç kullanan bir ajan kandırılırsa e-posta gönderebilir, kayıt silebilir ya da veriyi dışarı aktarabilir. Üstelik dolaylı enjeksiyonu tamamen engelleyen bir yöntem yoktur; OWASP da önerilerini riski azaltan katmanlar olarak sunar.

Kısacası, modelin talimatlara her zaman uyacağını varsaymayın. Güvenliği modelin iyi niyetine değil, ajanın yetkilerini sınırlayan sunucu ve iş akışı kurallarına dayandırın.

Ajana en az yetki ve insan onayını nasıl uygularsınız?

OWASP'ın önerileri arasında en az yetki ilkesi ve yüksek riskli işlemlerde insan onayı öne çıkar. Ayrıca aynı listede aşırı yetki, yani ajana görevinin gerektirdiğinden fazla işlev tanımak, ayrı bir risk olarak yer alır. Pratikte şu adımları uygulayabilirsiniz:

• Her entegrasyon için yalnızca okuma yetkili ayrı bir hesap ya da API anahtarı açın; yazma yetkisini gerçekten gereken akışa verin.
• Silme, ödeme, toplu e-posta ve dış paylaşım gibi geri alınamaz adımlardan önce iş akışına onay adımı ekleyin.
• Ajanın erişebileceği dosya dizinini daraltın; n8n'in resmi Compose örneği bunun için dosya erişimini tek bir dizinle sınırlayan bir değişken kullanır.
• Dışarıdan gelen içeriği, yani web sayfası, e-posta veya belge metnini, sistem talimatlarından ayrı ve açıkça etiketli tutun.
• Ajanın çıktısını bir sonraki araca vermeden önce beklenen biçime uyup uymadığını kontrol edin.

Bu kurallar ajanı yavaşlatır, bu doğru. Ancak ilk haftalarda onay adımlarının kayıtlarına bakarak hangi işlemlerin güvenle otomatikleşebileceğini görürsünüz. Böylece yetkiyi kanıta dayalı olarak genişletirsiniz.

Kayıt tutma, izleme ve yedekleme düzeni nasıl olmalı?

Bir ajan, sizin tek tek görmediğiniz kararlar verir. Dolayısıyla neyi, ne zaman, hangi girdiyle yaptığını sonradan okuyabilmeniz gerekir. n8n çalıştırma geçmişini kendi veritabanında tutar; ayrıca konteyner kayıtlarını docker compose logs ile görürsünüz. Kayıtların disk doldurmaması için saklama süresini ve Docker kayıt sürücüsü ayarlarını resmi belgelere göre sınırlayın.

Yedeklemede üç parçayı birlikte düşünün:

1. Veri dizini: n8n_data birimi; SQLite veritabanı ve şifreleme anahtarı buradadır.
2. Yapılandırma: Compose dosyası, ters vekil ayarları ve .env dosyası. Sonuncusunu şifreli bir konumda saklayın.
3. İş akışları: n8n'in komut satırı dışa aktarma komutlarıyla iş akışlarını ayrıca dışa aktarmak, sürüm kontrolü için faydalıdır.

Yedeği aynı sunucuda tutmayın, çünkü sunucu giderse yedek de gider. Yedekleme sıklığı ve saklama ilkeleri için web sitesi yedekleme stratejisi yazımıza bakabilirsiniz. Ayrıca geri yükleme testini düzenli yapın; hiç geri yüklenmemiş bir yedeğin çalıştığından emin olamazsınız.

Güncellemeleri nasıl güvenle yaparsınız?

n8n'in belgesi, sık aralıklarla yeni sürüm yayımladığını ve üretim için kararlı kanalı önerdiğini belirtir. Bu hız iyi bir haber, çünkü güvenlik düzeltmeleri çabuk gelir. Öte yandan sürüm notlarını okumadan güncellemek, çalışan bir iş akışını bozabilir.

Güvenli bir güncelleme sırası şöyledir: önce yedek alırsınız, ardından sürüm notlarında kırıcı değişiklik olup olmadığına bakarsınız. Sonra Compose dosyasındaki sürüm etiketini değiştirip şu komutları çalıştırırsınız:

docker compose pull
docker compose up -d
docker compose logs -f n8n

Güncellemeden sonra kritik iş akışlarını elle bir kez tetikleyin ve sonucu kontrol edin. Örneğin ortam değişkenlerinin adı değişebilir; n8n'in belgesi, webhook adresi için eski değişken adının kullanımdan kalktığını ve yerine yenisinin geldiğini not eder.

İşletim sistemi güncellemelerini de unutmayın. Ayrıca Ollama imajını ve indirdiğiniz modelleri de aynı disiplinle güncelleyin. Bir şey bozulursa eski sürüm etiketine dönerek geri alabilirsiniz; bu yüzden etiket kullanmak, "en son sürüm" etiketinden daha güvenlidir.

KVKK ve GDPR açısından nelere dikkat etmelisiniz?

Ajan kişisel veri işliyorsa, kendi sunucunuzda çalışması sizi veri koruma yükümlülüklerinden kurtarmaz; aksine veri sorumlusu olarak kontrol tamamen sizdedir. Bu bölüm genel bilgi niteliğindedir, hukuki danışmanlık değildir.

Genel olarak şu sorulara cevap verebilmeniz gerekir: Ajan hangi kişisel verileri okuyor? Bulut model kullanıyorsanız bu veriler hangi sağlayıcıya ve hangi ülkeye gidiyor? Çalıştırma geçmişinde kişisel veri ne kadar süre kalıyor? Bir kişi verisinin silinmesini isterse ajanın kayıtlarından da silebiliyor musunuz?

Yerel model kullanmak, istem metninin yurt dışına aktarılması sorusunu ortadan kaldırabilir. Ancak sunucunuzun hangi ülkede olduğu, yedeklerin nerede durduğu ve erişim kayıtları yine önemlidir. Ayrıca aydınlatma metninizde yapay zeka ile yaptığınız işlemeyi açıklamanız gerekebilir. Web tarafındaki genel uyum adımlarını KVKK ve GDPR uyumlu web sitesi rehberimizde anlattık; kişisel veri işleyen bir ajan için bir hukukçuya danışmanızı öneririz.

AI agent kurulumunun maliyet kalemleri nelerdir?

AI agent kurulumunda maliyet tek bir sunucu faturasından ibaret değildir. Rakam vermiyoruz, çünkü fiyatlar sağlayıcıya ve kullanıma göre değişir; güncel tutarları her sağlayıcının kendi fiyat sayfasından kontrol edin. Ancak bütçe yaparken şu kalemleri ayrı ayrı yazmanızı öneririz:

• Sunucu: VPS ya da GPU'lu sunucu kirası; yerel model kullanıyorsanız bu kalem belirgin biçimde büyür.
• Model kullanımı: Bulut API'si kullanıyorsanız token başına ücret. Sağlayıcı panelinde harcama sınırı tanımlayın.
• Depolama ve yedek: Yedeklerin tutulduğu harici depolama alanı.
• Alan adı ve sertifika: Alan adı yenileme ücreti; Let's Encrypt sertifikası ücretsizdir.
• Lisans: Orkestratörün kullandığınız özelliklerinin lisans koşullarını resmi sayfasından kontrol edin.
• İnsan zamanı: Kurulum, güncelleme, kayıt incelemesi ve olay müdahalesi için ayıracağınız saatler. Çoğu zaman en büyük kalem budur.

Örneğin aylık sunucu ücreti düşük görünse bile, her ay birkaç saatlik bakımı hesaba katmazsanız gerçek maliyeti eksik hesaplarsınız.

Ne zaman kendiniz kurmamalı, işi uzmana bırakmalısınız?

Her ajan kurulumu bir hobi projesi değildir. Şu durumlardan biri sizin için geçerliyse, işi deneyimli bir ekibe ya da yönetilen bir hizmete bırakmanızı öneririz:

• Sunucuda bir güvenlik olayı yaşandığında ne yapacağınızı bilmiyorsanız.
• Ajan müşteri verisine, ödeme sistemine ya da toplu iletişim kanalına dokunacaksa.
• Kurulumu yapan kişi ayrıldığında sistemi devralacak kimse yoksa.
• Haftalık güncelleme ve kayıt kontrolüne ayıracak zamanınız yoksa.

Bu durumlarda iki yol vardır. Birincisi, orkestratörün kendi bulut hizmetini kullanmaktır; bakım sağlayıcıda kalır. İkincisi, kurulumu ve bakımı bir ekibe devretmektir. Biz yapay zeka otomasyon hizmetimizde iş akışının tasarımına ve güvenli kurgusuna odaklanıyoruz; sunucu barındırma tarafında ise hosting sağlayıcınızla birlikte çalışıyoruz.

Hangi yolu seçerseniz seçin, ajanın neye erişebildiğini ve hangi işlemler için onay istediğini yazılı hale getirin. Böylece sistemi kim yönetirse yönetsin, sınırlar herkes için aynı kalır.

İlk hafta için kısa bir kontrol listesi

Kurulumu tamamladıktan sonra ilk hafta şu kontrolleri yapmanızı öneririz. Bu liste, yukarıdaki adımların özetidir:

1. Dışarıdan yalnızca SSH, HTTP ve HTTPS portlarının açık olduğunu doğrulayın.
2. n8n ve Ollama portlarının internetten erişilemediğini test edin.
3. Şifreleme anahtarının ve .env dosyasının sunucu dışında güvenli bir kopyası olsun.
4. İlk yedeği alın ve başka bir makinede geri yüklemeyi deneyin.
5. Her entegrasyonun yetkisini gözden geçirin; gereksiz yazma yetkisini kaldırın.
6. Geri alınamaz işlemlerin hepsinde onay adımı olduğundan emin olun.
7. Model sağlayıcısında harcama sınırını ve uyarıyı açın.

Kısacası, kendi sunucunuzda bir ajan çalıştırmak teknik olarak birkaç komutluk bir iştir. Asıl emek, o ajanın güvenli, yedekli ve sınırlı kalmasını sağlamaktır. n8n'in resmi Docker Compose kurulum belgesi, Ollama'nın resmi SSS sayfası ve Docker'ın güvenlik duvarı belgesi bu yolda başvuracağınız temel kaynaklardır.