AI dla CTO – 8 decyzji architektonicznych przy wdrożeniu AI w firmie B2B (2026)

Pierwsza i najważniejsza decyzja. Wpływa na koszty, time-to-value, compliance i ścieżkę długoterminowego rozwoju. W 2026 cloud-first jest domyślnym wyborem dla większości projektów — daje najszybszy start, najlepsze narzędzia (Azure OpenAI, AWS Bedrock, Google Vertex), niskie koszty inwestycyjne.

Hybrid (cloud + część on-prem) wygrywa, gdy macie wrażliwe dane regulowane (medyczne, finansowe, prawne), które nie mogą opuścić waszej infrastruktury, ale chcecie korzystać z mocy obliczeniowej cloud dla mniej wrażliwych workflow. To zwykle 30-40% wyższy TCO niż pure cloud, ale czasem nie ma alternatywy.

On-prem pure (własne GPU, własna infrastruktura, open-weight modele) wygrywa rzadko: gdy compliance branżowy zabrania cloudu (sektor obronny, niektóre fintech), gdy macie ekstremalnie wysoki wolumen (powyżej 10 mln zapytań/m-c i koszty cloud LLM stają się problemem), lub gdy macie unikalne dane domain'u, które chcecie ściśle chronić.

Wybór modelu LLM nie jest decyzją na całe życie — wymieniacie go zwykle co 12-18 miesięcy ze względu na tempo rozwoju. Ale architektura wokół niego musi przewidywać taką wymianę. To znaczy: abstrakcja przez router (LiteLLM, LangChain, własna warstwa) ZAMIAST bezpośredniego wywoływania OpenAI SDK w 30 miejscach kodu.

Praktyczna rekomendacja na 2026: GPT-4o lub GPT-5 jako primary dla skomplikowanych zadań, GPT-4o mini lub Haiku 4.5 dla prostszych (klasyfikacje, krótkie odpowiedzi). Claude 3.7 Sonnet dla zadań wymagających długiego kontekstu lub silnego reasoning. Open-source (Llama 3.3, Qwen 2.5) jako fallback i dla wrażliwych danych.

Antypattern: wybranie jednego modelu na cały stack. Większość organizacji w 2026 używa 3-5 różnych modeli równolegle, każdy do innego typu zadania. Multi-model architecture jest dziś standardem, nie wyjątkiem.

Jeśli wasz projekt używa RAG (a większość projektów AI w firmie używa), wybór vector DB ma fundamentalne znaczenie. Cztery główne opcje w 2026: Pinecone (managed SaaS, najszybszy start, drogi przy skali), Weaviate (open-source + cloud, dobry balance), pgvector (PostgreSQL extension, dla teamów które już mają PG i chcą minimalnej operational complexity), Azure AI Search (dla firm w ekosystemie Microsoft).

Najczęstszy błąd: wybór Pinecone dla wszystkiego. Świetny dla MVP, ale przy 10M+ embeddings koszty SaaS subscription szybko przekraczają TCO self-hosted Weaviate. Druga pułapka: niedoszacowanie kosztów embeddings — sama generacja embeddings przy 1M dokumentów to ~3-8 tys. zł, regeneracja przy zmianie modelu to ten sam koszt ponownie.

Praktyczny pattern: zacznijcie od pgvector (jeśli macie PostgreSQL) lub Pinecone (jeśli nie). Migrujcie do Weaviate self-hosted po przekroczeniu 5-10M embeddings lub przy budżecie >100k zł rocznie za SaaS subscription.

Najczęściej pomijana decyzja na wczesnym etapie. Bez observability AI w produkcji jest czarną skrzynką: nie wiecie kiedy model halucynował, jakie były koszty per request, dlaczego określone zapytania nie działały, gdzie są performance bottlenecks. Dodanie observability po roku produkcji wymaga przeprojektowania znacznej części systemu.

Stack 2026: LangSmith (od LangChain, dobry dla LangChain stacka), Helicone (open-source, model-agnostic), Datadog APM dla traditional metrics, Grafana + OpenTelemetry dla custom dashboards. Minimum viable observability: każde wywołanie LLM logowane z (input, output, latency, cost, model version, user_id, session_id).

Krytyczne metryki do trackowania od dnia 1: latency p50/p95/p99, cost per request, model accuracy (gdzie da się zmierzyć), hallucination rate (gdzie da się wykryć), token usage trend. Bez tych metryk nie zoptymalizujecie ani jakości, ani kosztów.

AI w produkcji dotyka 3 obszarów security: ochrona danych wejściowych (PII, dane wrażliwe), ochrona modeli (jeśli macie fine-tuned, IP), ochrona przed prompt injection i data exfiltration. Każdy wymaga osobnej decyzji architektonicznej.

Dane wejściowe: PII detection + redaction PRZED wysłaniem do LLM (Presidio, własne regex'y), opcjonalnie tokenizacja danych wrażliwych. Większość incydentów AI związanych z RODO to ujawnienie PII w prompt do publicznego LLM.

Prompt injection: zwłaszcza w agentach, którzy mają dostęp do narzędzi/danych. Standardowe defensywne wzorce: separacja system prompt od user input, output validation, sandbox dla tool execution, monitoring anomalous behavior. Bez tych zabezpieczeń agent z dostępem do bazy danych to ryzyko biznesowe.

Wybór dostawcy LLM, vector DB, cloud platformy — każdy tworzy lock-in. Pełna ucieczka od lock-in jest nierealistyczna (zawsze coś), ale można świadomie zarządzać jego poziomem.

Wzorzec niskiego lock-in: abstrakcja przez router LLM, vector DB w warstwie API (nie surowy SDK), własna infrastruktura observability. Wymiana dostawcy to wtedy 2-4 tygodnie pracy zespołu zamiast 6 miesięcy refactoringu.

Wzorzec wysokiego lock-in (akceptowalnego): głęboka integracja z jednym ekosystemem (Microsoft + Azure + Copilot), gdy daje to wymierne korzyści (jakość, koszty, support). To NIE jest błąd, jeśli zostaje świadomie wybrany.

Najsilniejszy predictor sukcesu projektów AI nie jest budżet ani technologia — jest kompetencja zespołu IT, który ma to utrzymywać. Wdrożenie AI bez 2-3 seniorów potrafiących utrzymywać AI w produkcji prawie zawsze kończy się porażką.

Wymagane kompetencje w 2026: AI Engineer (LLM-y, agenci, prompt engineering, evaluation), DevOps z AI flavorem (deploying, monitoring, cost optimization), Data Engineer (RAG, embeddings, vector DBs). Te role są drogie (200-350k zł rocznie w PL dla seniora) i trudne do znalezienia.

Trzy strategie: rekrutacja zewnętrzna (długa, droga), upskilling własnego zespołu (6-12 miesięcy, mniej pewne), partnership z konsultingiem (najszybsze, ale tworzy zewnętrzny lock-in). Większość organizacji korzysta z kombinacji wszystkich trzech.

Ostatnia decyzja: czy hostować modele open-source we własnej infrastrukturze, czy korzystać z managed APIs (OpenAI, Anthropic, Azure OpenAI). Większość organizacji wybiera managed APIs — daje to najszybszy start i przewidywalne koszty.

Self-hosting open-weight modeli (Llama 3.3 70B, Qwen 2.5, Mistral Large) wygrywa w 3 scenariuszach: bardzo wysoki wolumen (powyżej 50M tokens/m-c, gdzie koszty API stają się znaczące), wrażliwe dane wymagające data residency, lub strategia IP (chcecie być właścicielami modeli waszych use case'ów).

Realny koszt self-hostingu jednego Llama 70B w produkcji to 50-150 tys. zł rocznie (GPU compute, devops time, monitoring). Poniżej 30M tokens/m-c managed APIs prawie zawsze są tańsze. Powyżej 100M tokens/m-c self-hosting zaczyna być znacząco bardziej ekonomiczny.