7-warstwowa architektura referencyjna
Korporacyjne AI Agents potrzebują więcej niż LLM. Ta architektura rozdziela interfejs użytkownika, orkiestrację, agentów, logikę decyzyjną, modele, integracje i infrastrukturę na siedem niezależnych warstw. Governance przenika wszystkie warstwy jako komponent przekrojowy.
Dlaczego siedem warstw
Monolityczny system AI nie jest audytowalny, nie skaluje się i nie jest możliwy do utrzymania. Architektura 7-warstwowa rozdziela odpowiedzialności: każda warstwa ma zdefiniowane zadanie i czyste interfejsy. Zmiana modelu nie wpływa na logikę biznesową. Nowy system docelowy nie zmienia agenta. Nowe wymaganie zgodności z RODO czy EU AI Act nie zmienia infrastruktury.
Architektura wynika z wymagań korporacyjnych: izolacja tenantów, Audit Trail, transparentność dla Rady Zakładowej (prawo do informacji i konsultacji zgodnie z Ustawą o radach pracowników), zgodność z EU AI Act, agnostyczne wobec modeli wdrożenie. Standardowe API LLM nie zapewniają żadnego z tych elementów.
1. Presentation Layer
Interfejs między systemem a użytkownikiem. Bez logiki biznesowej, bez decyzji - tylko wyświetlanie i wprowadzanie danych.
- Chat UI: Interfejs webowy dla użytkowników końcowych (kadry, księgowi). Gotowy na PWA, responsywny.
- Dashboard: Przegląd statusu agentów, bieżących workflow, otwartych eskalacji. Oparty na rolach: pracownicy widzą swoje sprawy, menedżerowie widzą wskaźniki.
- Portal Audytora: Dostęp audytora do Audit Trail, kontroli, dowodów. Tylko odczyt. Dla biegłych rewidentów, Rady Zakładowej, rewizji wewnętrznej.
- REST API: Interfejs maszynowy do integracji z istniejącymi systemami. Wersjonowany, udokumentowany, z uwierzytelnianiem.
2. Orchestration Layer
Koordynuje przepływ danych między agentami, systemami i użytkownikami. Zarządza workflow, kolejkami i routingiem API.
- Silnik workflow: Silniki open source (Trigger.dev, Camunda) do złożonych, wieloetapowych procesów. Wizualne workflow, integracja API, webhooki.
- API Gateway: Jednolity punkt wejścia z rate limiting, uwierzytelnianiem, logowaniem, monitoringiem.
- System kolejek: Asynchroniczne przetwarzanie dla operacji wsadowych (zamknięcie miesiąca, masowy import).
- System zdarzeń: Reakcja w czasie rzeczywistym na przychodzące dokumenty, zmiany statusu, eskalacje.
3. Agent Layer
Wyspecjalizowane AI Agents wykonujące zadania fachowe. Każdy agent ma zdefiniowany zakres i działa w granicach wyznaczonych przez Decision Layer.
Document Agents
Czytają, rozumieją i przetwarzają dokumenty z rzeczywistym rozumieniem językowym. Faktury, zwolnienia lekarskie, umowy, zaświadczenia, paragony. Nie rozpoznawanie szablonów, nie sztywne reguły - lecz kontekstowe rozumienie.
Workflow Agents
Orkiestrują procesy między systemami. Gdy dokument musi być odczytany, decyzja podjęta i akcja wywołana w systemie docelowym - Workflow Agent koordynuje sekwencję.
Knowledge Agents
Dostarczają kontekstowe odpowiedzi z wiedzy korporacyjnej. Regulaminy, polityki, układy zbiorowe pracy, reguły compliance. Odpowiedź zawiera źródło i wersję reguły.
4. Decision Layer
Rozkłada każdy proces biznesowy na pojedyncze kroki decyzyjne i definiuje dla każdego kroku: człowiek, zestaw reguł lub AI. Każda decyzja jest dokumentowana - do audytu przez biegłych rewidentów, Radę Zakładową i rewizję wewnętrzną.
Rules Engine: Fachowe zestawy reguł, wersjonowane i identyfikowalne. Układy zbiorowe pracy, porozumienia zakładowe, logika księgowa, reguły compliance. Każda reguła ma wersję, datę obowiązywania i zakres.
Confidence Routing: Automatyczna ocena pewności decyzji. Wysoka pewność i niskie ryzyko: autonomiczna decyzja. Niska pewność lub wysokie ryzyko: eskalacja do człowieka.
Human-in-the-Loop: Architektonicznie wymuszona kontrola człowieka przy zdefiniowanych typach decyzji. Ryzyko uprzedzeń, potencjał dyskryminacji, tematy wymagające konsultacji z Radą Zakładową.
Audit Trail: Kompletna, niezmienna dokumentacja każdej decyzji. Wejście, model, ocena, reguła, wynik, znacznik czasu. Append-only.
Więcej: Decision Layer w szczegółach · 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 poszczególnych dostawców chmurowych.
Open-Source / Open-Weight LLM
Llama (Meta), Mistral, DeepSeek, gpt-oss (OpenAI, Apache 2.0) - w pełni self-hostowalne na własnym hardware. gpt-oss-120B działa na pojedynczym H100, gpt-oss-20B na 16 GB hardware konsumenckim.
Hybryda
Cloud LLM dla standardowych zadań, Self-Hosted LLM dla danych wrażliwych. Automatyczny routing według klasyfikacji danych.
Wybór modelu to kompromis między wydajnością, kosztami, ochroną danych i latencją. Warstwa modelu jest wymienna - zmiana modelu nie wpływa na logikę biznesową powyżej.
Konkretne opcje hostingu, wymagania sprzętowe i stos technologiczny: AI Infrastructure w szczegółach
6. Integration Layer
Połączenie z istniejącymi systemami korporacyjnymi. Agent nie zastępuje systemów - 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 |
| Pozostałe | Każdy system z interfejsem REST lub SOAP |
Logika agenta jest oddzielona od systemu docelowego. Logika księgowa jest oddzielona od eksportu. Gdy system docelowy się zmienia (np. z Comarch na SAP), zmienia się warstwa eksportu - nie agent.
7. Infrastructure Layer
Fundament wdrożeniowy. Cała architektura działa w infrastrukturze klienta - nie u Gosign, nie u zewnętrznego dostawcy.
- Cloud (UE): Azure, AWS lub GCP - wyłącznie regiony UE. Managed Kubernetes, Managed Databases, LLM Hosting.
- Managed EU: Vercel EU + Supabase EU. Lekka opcja UE bez własnej infrastruktury Kubernetes.
- Self-Hosted: Własne serwery, własne centrum danych. Docker/Kubernetes, open-source LLM na własnych GPU. Pełna niezależność od Cloud Act.
- Hybryda: Kombinacja według klasyfikacji danych. Wrażliwe obciążenia self-hosted, standardowe obciążenia w chmurze.
Wszystkie warstwy powyżej infrastruktury pozostają identyczne - niezależnie od modelu wdrożenia.
Regiony chmurowe, wymiarowanie hardware, stos technologiczny: AI Infrastructure w szczegółach
Governance jako warstwa przekrojowa
Governance nie jest pojedynczą warstwą, lecz przenika całą architekturę. Każda warstwa generuje dane governance, każda warstwa jest kontrolowana przez reguły governance.
- Presentation: Dostęp oparty na rolach, Portal Audytora
- Orchestration: Logowanie workflow, dokumentacja eskalacji
- Agent: Decyzje agentów generują wpisy Audit Trail
- Decision Layer: Rules Engine, Confidence Routing, Human-in-the-Loop
- Model: Śledzenie wersji modelu, haszowanie danych wejściowych, odtwarzalność
- Integration: Logowanie interfejsów, dokumentacja przepływu danych
- Infrastructure: Szyfrowanie, Row-Level Security, izolacja tenantów
EU AI Act · Cert-Ready by Design · Współzarządzanie · Data Residency
Runtime i skalowanie
Eksploatacja produkcyjna nie jest dodatkową pracą, lecz częścią architektury. Architektura 7-warstwowa jest zaprojektowana do pracy pod obciążeniem.
- Orkiestracja kontenerów: Wdrożenie oparte na Kubernetes. Każda warstwa działa we własnych kontenerach, niezależnie skalowalna.
- Skalowanie horyzontalne: Agent Layer i Model Layer skalują się horyzontalnie według obciążenia. Nowy agent to więcej podów, nie więcej architektury.
- Health Checks i Self-Healing: Liveness i Readiness Probes na wszystkich kontenerach. Automatyczny restart przy awarii, automatyczne przekierowanie przy przeciążeniu.
- Monitoring i alerting: Metryki Prometheus na wszystkich warstwach. Dashboardy Grafana dla latencji, throughput, error rates, queue depth. Alerty przy przekroczeniu progów.
- CI/CD: Wdrożenia oparte na GitOps. Infrastructure as Code (Terraform/Pulumi). Automatyczne testy, wdrożenia Blue-Green lub Canary.
Architektura danych
Dane przepływają przez wszystkie siedem warstw. Architektura definiuje, gdzie dane powstają, jak są przechowywane i kto ma dostęp.
- Przepływ danych: Input (dokument, zapytanie) → Agent (analiza) → Decision Layer (decyzja) → Integration (eksport do systemu docelowego). Każdy krok generuje wpis Audit Trail.
- Vector Store: PostgreSQL z pgvector do wyszukiwania semantycznego (RAG). Wiedza korporacyjna przechowywana jako embeddingi, nie przesyłana do zewnętrznych usług.
- Izolacja tenantów: Row-Level Security (RLS) na poziomie bazy danych. Wymuszona architektonicznie, nie na poziomie logiki aplikacji. Każdy tenant jest w pełni izolowany.
- Szyfrowanie: At rest (AES-256) i in transit (TLS 1.3). Zarządzanie kluczami przez dostawcę tożsamości klienta lub Hardware Security Modules (HSM).
- Retencja danych: Konfigurowana według wymagań. Zgodność z RODO Art. 17 (prawo do usunięcia) realizowana poprzez anonimizację 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 interfejsów
Architektura komunikuje się poprzez zdefiniowane interfejsy - wewnętrznie między warstwami i zewnętrznie z systemami źródłowymi i docelowymi.
- REST API: Wersjonowane API (v1, v2) z dokumentacją OpenAPI. Breaking changes tylko w nowych wersjach, stare wersje utrzymywane równolegle.
- Event-Driven: Przetwarzanie zdarzeń oparte na webhookach dla reakcji w czasie rzeczywistym. Przychodzący dokument → zdarzenie → agent przetwarza. Bez pollingu, bez opóźnienia batch.
- MCP (Model Context Protocol): Standaryzowany protokół do integracji narzędzi w agentach LLM. Agenci korzystają z zewnętrznych narzędzi przez MCP - typizowane, udokumentowane, audytowalne.
- Przetwarzanie wsadowe: Dla operacji masowych (zamknięcie miesiąca, rozliczenie roczne, masowy import). Oparte na kolejkach ze śledzeniem postępu i obsługą błędów.
- API Gateway: Centralny punkt wejścia. Uwierzytelnianie (SSO/OIDC), rate limiting, logowanie żądań, monitoring. Oddziela wewnętrzną architekturę od zewnętrznych konsumentów.
Zasady projektowe
Agnostyczna wobec modeli: Brak vendor lock-in na pojedynczego LLM. Modele są wymienne. Dziś Claude, jutro gpt-oss, pojutrze model, który dziś jeszcze nie istnieje.
Agnostyczna wobec infrastruktury: Ta sama architektura na Azure, AWS, GCP, Self-Hosted lub Hybryda. Wybór infrastruktury jest decyzją klienta, nie architektury.
Agnostyczna wobec systemów: Logika agenta jest oddzielona od systemu docelowego. Logika księgowa 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 później.
Cert-Ready by Design: Kontrole jako obiekty danych pierwszej klasy z automatycznym generowaniem dowodów. ISO 27001, PS 951, SOC 2 - architektura dostarcza dowody.
Dostęp do kodu: Pełny dostęp do kodu źródłowego, wszystkich promptów i zestawów reguł. Konfiguracje i zestawy reguł pozostają u klienta. Stos open source tam, gdzie to możliwe. Po 12-18 miesiącach klient operuje agentami samodzielnie.
Decision Layer - przepływ decyzji
┌──────────┐ ┌──────────────┐ ┌────────────────┐
│ Input │───>│ AI Agent │───>│ Decision Layer │
│(dokument,│ │ analizuje, │ │ │
│ zapytanie)│ │ rozumie, │ │ Sprawdź │
└──────────┘ │ ocenia │ │ reguły │
└──────────────┘ │ │
│ Oceń │
│ pewność │
│ │
│ Routing │
│ zdecyduj │
└───────┬────────┘
│
┌─────────────┴──────────────┐
│ │
┌────────┴────────┐ ┌──────────┴──────────┐
│ Autonomicznie │ │ Human-in-the-Loop │
│ │ │ │
│ Wysoka pewność │ │ Ryzyko uprzedzeń │
│ Niskie ryzyko │ │ Niska pewność │
│ Brak │ │ Ograniczenie │
│ ograniczeń │ │ Konsultacja RZ │
└────────┬────────┘ └──────────┬──────────┘
│ │
│ ┌──────────────┐ │
│ │ Człowiek │ │
│ │ decyduje │◄──┘
│ └──────┬───────┘
│ │
┌────────┴────────────────┴────────┐
│ Audit Trail │
│ Input · Model · Reguła · │
│ Ocena · Wynik · │
│ Znacznik czasu │
└──────────────────────────────────┘
│
┌────────┴────────┐
│ System docelowy│
│ (ERP, HR, │
│ Payroll) │
└─────────────────┘Pogłębienie
Implementacja
AI Infrastructure
Konkretne technologie, regiony chmurowe, wymiarowanie hardware, tabela stosu technologicznego.
Infrastruktura w szczegółach →Wiedza
Blueprint 2026
Jedenaście artykułów o decyzjach infrastrukturalnych, które mają znaczenie w 2026.
Do serii artykułów →Agenci
AI Agents
Document Agents, Workflow Agents, Knowledge Agents - trzy typy agentów dla procesów enterprise.
Do AI Agents →Governance
Framework Governance
EU AI Act, Cert-Ready, Współzarządzanie, Data Residency - wszystkie tematy governance w jednym miejscu.
Przegląd Governance →Pogłębienie w Agent Briefing
Nasza seria artykułów fachowych dla decydentów wdrażających agentów AI.
Często zadawane pytania o architekturę referencyjną
Dlaczego osobna architektura zamiast standardowych API LLM?
Standardowe API LLM dostarczają rozumienie języka, ale nie governance, nie Audit Trail, nie izolację tenantów, nie model uprawnień. Architektura 7-warstwowa to warstwa między LLM a systemem korporacyjnym, która dokładnie to uzupełnia. Bez tej warstwy każdy 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 są integrowane bez zmian w warstwach powyżej. Brak vendor lock-in na pojedynczego dostawcę LLM.
Jak architektura skaluje się przy rosnącym obciążeniu?
Każda warstwa skaluje się niezależnie. Agent Layer i Model Layer mogą być skalowane horyzontalnie bez zmian w Decision Layer ani integracji. Wdrożenie oparte na Kubernetes umożliwia auto-scaling według obciążenia.
Jak zapewniana jest izolacja tenantów?
Na poziomie bazy danych poprzez Row-Level Security (RLS). Każdy tenant widzi wyłącznie własne dane, reguły i Audit Trail. Izolacja jest wymuszona architektonicznie, nie tylko na poziomie logiki aplikacji.
Czy architekturę można wdrażać etapowo?
Tak. Warstwy są niezależne. Typowe wejście: jeden agent (np. Document Agent) z Decision Layer, podłączony do istniejącego systemu. Kolejni agenci, integracje i funkcje governance są dodawane etapowo.
Czym ta strona różni się od strony infrastruktury?
Ta strona opisuje wzorzec architektoniczny - jakie warstwy istnieją i dlaczego. Strona infrastruktury opisuje konkretną realizację - jakie technologie, jakie regiony chmurowe, jaki hardware. Architektura to co, infrastruktura to jak.
Ocena architektury dla Twojej organizacji
Analizujemy Twój istniejący krajobraz systemowy i pokazujemy, jak architektura 7-warstwowa pasuje do Twojej infrastruktury.
Umów spotkanie