7-warstwowa architektura referencyjna
Korporacyjne AI Agents potrzebuja wiecej niz LLM. Ta architektura rozdziela interfejs uzytkownika, orkiestracje, agentow, logike decyzyjna, modele, integracje i infrastrukture na siedem niezaleznych warstw. Governance przenika wszystkie warstwy jako komponent przekrojowy.
Dlaczego siedem warstw
Monolityczny system AI nie jest audytowalny, nie skaluje sie i nie jest mozliwy do utrzymania. Architektura 7-warstwowa rozdziela odpowiedzialnosci: kazda warstwa ma zdefiniowane zadanie i czyste interfejsy. Zmiana modelu nie wplywa na logike biznesowa. Nowy system docelowy nie zmienia agenta. Nowe wymaganie zgodnosci z RODO czy EU AI Act nie zmienia infrastruktury.
Architektura wynika z wymagan korporacyjnych: izolacja tenantow, Audit Trail, transparentnosc dla Rady Zakladowej (prawo do informacji i konsultacji zgodnie z Ustawa o radach pracownikow), zgodnosc z EU AI Act, agnostyczne wobec modeli wdrozenie. Standardowe API LLM nie zapewniaja zadnego z tych elementow.
1. Presentation Layer
Interfejs miedzy systemem a uzytkownikiem. Bez logiki biznesowej, bez decyzji - tylko wyswietlanie i wprowadzanie danych.
- Chat UI: Interfejs webowy dla uzytkownikow koncowych (kadry, ksiegowi). Gotowy na PWA, responsywny.
- Dashboard: Przeglad statusu agentow, biezacych workflow, otwartych eskalacji. Oparty na rolach: pracownicy widza swoje sprawy, menedzerowie widza wskazniki.
- Portal Audytora: Dostep audytora do Audit Trail, kontroli, dowodow. Tylko odczyt. Dla bieglych rewidentow, Rady Zakladowej, rewizji wewnetrznej.
- REST API: Interfejs maszynowy do integracji z istniejacymi systemami. Wersjonowany, udokumentowany, z uwierzytelnianiem.
2. Orchestration Layer
Koordynuje przeplyw danych miedzy agentami, systemami i uzytkownikami. Zarzadza workflow, kolejkami i routingiem API.
- Silnik workflow: Silniki open source (Trigger.dev, Camunda) do zlozonych, wieloetapowych procesow. Wizualne workflow, integracja API, webhooki.
- API Gateway: Jednolity punkt wejscia z rate limiting, uwierzytelnianiem, logowaniem, monitoringiem.
- System kolejek: Asynchroniczne przetwarzanie dla operacji wsadowych (zamkniecie miesiaca, masowy import).
- System zdarzen: Reakcja w czasie rzeczywistym na przychodzace dokumenty, zmiany statusu, eskalacje.
3. Agent Layer
Wyspecjalizowane AI Agents wykonujace zadania fachowe. Kazdy agent ma zdefiniowany zakres i dziala w granicach wyznaczonych przez Decision Layer.
Document Agents
Czytaja, rozumieja i przetwarzaja dokumenty z rzeczywistym rozumieniem jezykowym. Faktury, zwolnienia lekarskie, umowy, zaswiadczenia, paragony. Nie rozpoznawanie szablonow, nie sztywne reguly - lecz kontekstowe rozumienie.
Workflow Agents
Orkiestruja procesy miedzy systemami. Gdy dokument musi byc odczytany, decyzja podjeta i akcja wywolana w systemie docelowym - Workflow Agent koordynuje sekwencje.
Knowledge Agents
Dostarczaja kontekstowe odpowiedzi z wiedzy korporacyjnej. Regulaminy, polityki, uklady zbiorowe pracy, reguly compliance. Odpowiedz zawiera zrodlo i wersje reguly.
4. Decision Layer
Rozklada kazdy proces biznesowy na pojedyncze kroki decyzyjne i definiuje dla kazdego kroku: czlowiek, zestaw regul lub AI. Kazda decyzja jest dokumentowana - do audytu przez bieglych rewidentow, Rade Zakladowa i rewizje wewnetrzna.
Rules Engine: Fachowe zestawy regul, wersjonowane i identyfikowalne. Uklady zbiorowe pracy, porozumienia zakladowe, logika ksiegowa, reguly compliance. Kazda regula ma wersje, date obowiazywania i zakres.
Confidence Routing: Automatyczna ocena pewnosci decyzji. Wysoka pewnosc i niskie ryzyko: autonomiczna decyzja. Niska pewnosc lub wysokie ryzyko: eskalacja do czlowieka.
Human-in-the-Loop: Architektonicznie wymuszona kontrola czlowieka przy zdefiniowanych typach decyzji. Ryzyko uprzedzen, potencjal dyskryminacji, tematy wymagajace konsultacji z Rada Zakladowa.
Audit Trail: Kompletna, niezmienna dokumentacja kazdej decyzji. Wejscie, model, ocena, regula, wynik, znacznik czasu. Append-only.
Wiecej: Decision Layer w szczegolach · Trzy rodzaje decyzji AI
5. Model Layer
Warstwa LLM. Wymienna, agnostyczna wobec modeli, oddzielona od logiki biznesowej.
Cloud LLM
Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google) - przez regiony UE poszczegolnych dostawcow chmurowych.
Open-Source / Open-Weight LLM
Llama (Meta), Mistral, DeepSeek, gpt-oss (OpenAI, Apache 2.0) - w pelni self-hostowalne na wlasnym hardware. gpt-oss-120B dziala na pojedynczym H100, gpt-oss-20B na 16 GB hardware konsumenckim.
Hybryda
Cloud LLM dla standardowych zadan, Self-Hosted LLM dla danych wrazliwych. Automatyczny routing wedlug klasyfikacji danych.
Wybor modelu to kompromis miedzy wydajnoscia, kosztami, ochrona danych i latencja. Warstwa modelu jest wymienna - zmiana modelu nie wplywa na logike biznesowa powyzej.
Konkretne opcje hostingu, wymagania sprzetowe i stos technologiczny: AI Infrastructure w szczegolach
6. Integration Layer
Polaczenie z istniejacymi systemami korporacyjnymi. Agent nie zastepuje systemow - rozszerza je.
| Kategoria systemu | Integracja |
|---|---|
| ERP / Finanse | SAP FI/CO, SAP S/4HANA, Comarch, Oracle Financials |
| HR / Payroll | SAP SuccessFactors, Workday, Comarch HR |
| Collaboration | SharePoint, Microsoft Teams (via Microsoft Graph) |
| DMS / ECM | SharePoint, d.velop, ELO, nscale |
| Pozostale | Kazdy system z interfejsem REST lub SOAP |
Logika agenta jest oddzielona od systemu docelowego. Logika ksiegowa jest oddzielona od eksportu. Gdy system docelowy sie zmienia (np. z Comarch na SAP), zmienia sie warstwa eksportu - nie agent.
7. Infrastructure Layer
Fundament wdrozeniowy. Cala architektura dziala w infrastrukturze klienta - nie u Gosign, nie u zewnetrznego dostawcy.
- Cloud (UE): Azure, AWS lub GCP - wylacznie regiony UE. Managed Kubernetes, Managed Databases, LLM Hosting.
- Managed EU: Vercel EU + Supabase EU. Lekka opcja UE bez wlasnej infrastruktury Kubernetes.
- Self-Hosted: Wlasne serwery, wlasne centrum danych. Docker/Kubernetes, open-source LLM na wlasnych GPU. Pelna niezaleznosc od Cloud Act.
- Hybryda: Kombinacja wedlug klasyfikacji danych. Wrazliwe obciazenia self-hosted, standardowe obciazenia w chmurze.
Wszystkie warstwy powyzej infrastruktury pozostaja identyczne - niezaleznie od modelu wdrozenia.
Regiony chmurowe, wymiarowanie hardware, stos technologiczny: AI Infrastructure w szczegolach
Governance jako warstwa przekrojowa
Governance nie jest pojedyncza warstwa, lecz przenika cala architekture. Kazda warstwa generuje dane governance, kazda warstwa jest kontrolowana przez reguly governance.
- Presentation: Dostep oparty na rolach, Portal Audytora
- Orchestration: Logowanie workflow, dokumentacja eskalacji
- Agent: Decyzje agentow generuja wpisy Audit Trail
- Decision Layer: Rules Engine, Confidence Routing, Human-in-the-Loop
- Model: Sledzenie wersji modelu, haszowanie danych wejsciowych, odtwarzalnosc
- Integration: Logowanie interfejsow, dokumentacja przeplywu danych
- Infrastructure: Szyfrowanie, Row-Level Security, izolacja tenantow
EU AI Act · Cert-Ready by Design · Wspolzarzadzanie · Data Residency
Runtime i skalowanie
Eksploatacja produkcyjna nie jest dodatkowa praca, lecz czescia architektury. Architektura 7-warstwowa jest zaprojektowana do pracy pod obciazeniem.
- Orkiestracja kontenerow: Wdrozenie oparte na Kubernetes. Kazda warstwa dziala we wlasnych kontenerach, niezaleznie skalowalna.
- Skalowanie horyzontalne: Agent Layer i Model Layer skaluja sie horyzontalnie wedlug obciazenia. Nowy agent to wiecej podow, nie wiecej architektury.
- Health Checks i Self-Healing: Liveness i Readiness Probes na wszystkich kontenerach. Automatyczny restart przy awarii, automatyczne przekierowanie przy przeciazeniu.
- Monitoring i alerting: Metryki Prometheus na wszystkich warstwach. Dashboardy Grafana dla latencji, throughput, error rates, queue depth. Alerty przy przekroczeniu progow.
- CI/CD: Wdrozenia oparte na GitOps. Infrastructure as Code (Terraform/Pulumi). Automatyczne testy, wdrozenia Blue-Green lub Canary.
Architektura danych
Dane przeplywaja przez wszystkie siedem warstw. Architektura definiuje, gdzie dane powstaja, jak sa przechowywane i kto ma dostep.
- Przeplyw danych: Input (dokument, zapytanie) -> Agent (analiza) -> Decision Layer (decyzja) -> Integration (eksport do systemu docelowego). Kazdy krok generuje wpis Audit Trail.
- Vector Store: PostgreSQL z pgvector do wyszukiwania semantycznego (RAG). Wiedza korporacyjna przechowywana jako embeddingi, nie przesylana do zewnetrznych uslug.
- Izolacja tenantow: Row-Level Security (RLS) na poziomie bazy danych. Wymuszona architektonicznie, nie na poziomie logiki aplikacji. Kazdy tenant jest w pelni izolowany.
- Szyfrowanie: At rest (AES-256) i in transit (TLS 1.3). Zarzadzanie kluczami przez dostawce tozsamosci klienta lub Hardware Security Modules (HSM).
- Retencja danych: Konfigurowana wedlug wymagan. Zgodnosc z RODO Art. 17 (prawo do usuni ecia) realizowana poprzez anonimizacje zamiast usuwania.
- Backup i recovery: Automatyczne kopie zapasowe, Point-in-Time Recovery. Recovery Point Objective (RPO) i Recovery Time Objective (RTO) konfigurowane per tenant.
Architektura interfejsow
Architektura komunikuje sie poprzez zdefiniowane interfejsy - wewnetrznie miedzy warstwami i zewnetrznie z systemami zrodlowymi i docelowymi.
- REST API: Wersjonowane API (v1, v2) z dokumentacja OpenAPI. Breaking changes tylko w nowych wersjach, stare wersje utrzymywane rownolegle.
- Event-Driven: Przetwarzanie zdarzen oparte na webhookach dla reakcji w czasie rzeczywistym. Przychodzacy dokument -> zdarzenie -> agent przetwarza. Bez pollingu, bez opoznienia batch.
- MCP (Model Context Protocol): Standaryzowany protokol do integracji narzedzi w agentach LLM. Agenci korzystaja z zewnetrznych narzedzi przez MCP - typizowane, udokumentowane, audytowalne.
- Przetwarzanie wsadowe: Dla operacji masowych (zamkniecie miesiaca, rozliczenie roczne, masowy import). Oparte na kolejkach ze sledzeniem postepu i obsluga bledow.
- API Gateway: Centralny punkt wejscia. Uwierzytelnianie (SSO/OIDC), rate limiting, logowanie zadan, monitoring. Oddziela wewnetrzna architekture od zewnetrznych konsumentow.
Zasady projektowe
Agnostyczna wobec modeli: Brak vendor lock-in na pojedynczego LLM. Modele sa wymienne. Dzis Claude, jutro gpt-oss, pojutrze model, ktory dzis jeszcze nie istnieje.
Agnostyczna wobec infrastruktury: Ta sama architektura na Azure, AWS, GCP, Self-Hosted lub Hybryda. Wybor infrastruktury jest decyzja klienta, nie architektury.
Agnostyczna wobec systemow: Logika agenta jest oddzielona od systemu docelowego. Logika ksiegowa oddzielona od eksportu. Zmiana systemu zmienia Integration Layer, nie agenta.
Governance by Design: Audit Trail, RBAC, Decision Layer i Human-in-the-Loop to komponenty architektoniczne - nie opcjonalne funkcje dodawane pozniej.
Cert-Ready by Design: Kontrole jako obiekty danych pierwszej klasy z automatycznym generowaniem dowodow. ISO 27001, PS 951, SOC 2 - architektura dostarcza dowody.
Dostep do kodu: Pelny dostep do kodu zrodlowego, wszystkich promptow i zestawow regul. Konfiguracje i zestawy regul pozostaja u klienta. Stos open source tam, gdzie to mozliwe. Po 12-18 miesiacach klient operuje agentami samodzielnie.
Decision Layer - przeplyw decyzji
┌──────────┐ ┌──────────────┐ ┌────────────────┐
│ Input │───>│ AI Agent │───>│ Decision Layer │
│(dokument,│ │ analizuje, │ │ │
│ zapytanie)│ │ rozumie, │ │ Sprawdz │
└──────────┘ │ ocenia │ │ reguly │
└──────────────┘ │ │
│ Ocen │
│ pewnosc │
│ │
│ Routing │
│ zdecyduj │
└───────┬────────┘
│
┌─────────────┴──────────────┐
│ │
┌────────▼────────┐ ┌──────────▼──────────┐
│ Autonomicznie │ │ Human-in-the-Loop │
│ │ │ │
│ Wysoka pewnosc │ │ Ryzyko uprzedzen │
│ Niskie ryzyko │ │ Niska pewnosc │
│ Brak │ │ Ograniczenie │
│ ograniczen │ │ Konsultacja RZ │
└────────┬────────┘ └──────────┬──────────┘
│ │
│ ┌──────────────┐ │
│ │ Czlowiek │ │
│ │ decyduje │◄──┘
│ └──────┬───────┘
│ │
┌────────▼────────────────▼────────┐
│ Audit Trail │
│ Input · Model · Regula · │
│ Ocena · Wynik · │
│ Znacznik czasu │
└──────────────────────────────────┘
│
┌────────▼────────┐
│ System docelowy│
│ (ERP, HR, │
│ Payroll) │
└─────────────────┘Poglebienie
Implementacja
AI Infrastructure
Konkretne technologie, regiony chmurowe, wymiarowanie hardware, tabela stosu technologicznego.
Infrastruktura w szczegolach ->Wiedza
Blueprint 2026
Jedenascie artykulow o decyzjach infrastrukturalnych, ktore maja znaczenie w 2026.
Do serii artykulow ->Agenci
AI Agents
Document Agents, Workflow Agents, Knowledge Agents - trzy typy agentow dla procesow enterprise.
Do AI Agents ->Governance
Framework Governance
EU AI Act, Cert-Ready, Wspolzarzadzanie, Data Residency - wszystkie tematy governance w jednym miejscu.
Przeglad Governance ->Pogłębienie w Agent Briefing
Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.
Czesto zadawane pytania o architekture referencyjna
Dlaczego osobna architektura zamiast standardowych API LLM?
Standardowe API LLM dostarczaja rozumienie jezyka, ale nie governance, nie Audit Trail, nie izolacje tenantow, nie model uprawnien. Architektura 7-warstwowa to warstwa miedzy LLM a systemem korporacyjnym, ktora dokladnie to uzupelnia. Bez tej warstwy kazdy LLM pozostaje eksperymentem.
Czy architektura jest agnostyczna wobec modeli?
Tak. Warstwa modelu jest wymienna. Aktualnie wspierane: Claude, ChatGPT, Gemini, Llama, Mistral, DeepSeek, gpt-oss. Nowe modele sa integrowane bez zmian w warstwach powyzej. Brak vendor lock-in na pojedynczego dostawce LLM.
Jak architektura skaluje sie przy rosnacym obciazeniu?
Kazda warstwa skaluje sie niezaleznie. Agent Layer i Model Layer moga byc skalowane horyzontalnie bez zmian w Decision Layer ani integracji. Wdrozenie oparte na Kubernetes umozliwia auto-scaling wedlug obciazenia.
Jak zapewniana jest izolacja tenantow?
Na poziomie bazy danych poprzez Row-Level Security (RLS). Kazdy tenant widzi wylacznie wlasne dane, reguly i Audit Trail. Izolacja jest wymuszona architektonicznie, nie tylko na poziomie logiki aplikacji.
Czy architekture mozna wdrazac etapowo?
Tak. Warstwy sa niezalezne. Typowe wejscie: jeden agent (np. Document Agent) z Decision Layer, podlaczony do istniejacego systemu. Kolejni agenci, integracje i funkcje governance sa dodawane etapowo.
Czym ta strona rozni sie od strony infrastruktury?
Ta strona opisuje wzorzec architektoniczny - jakie warstwy istnieja i dlaczego. Strona infrastruktury opisuje konkretna realizacje - jakie technologie, jakie regiony chmurowe, jaki hardware. Architektura to co, infrastruktura to jak.
Ocena architektury dla Twojej organizacji
Analizujemy Twoj istniejacy krajobraz systemowy i pokazujemy, jak architektura 7-warstwowa pasuje do Twojej infrastruktury.
Umow spotkanie