Polityki biznesowe i reguły są wszędzie w organizacji. „Zamówienia powyżej 10000 zł wymagają zatwierdzenia dyrektora.” „Klient z historią opóźnień powyżej 60 dni nie dostaje kredytu kupieckiego.” „Priorytet obsługi dla klientów premium jest zawsze 1.”
Tradycyjnie te reguły są zakodowane w aplikacjach — albo wprost w kodzie (co jest złe, bo zmiana reguły wymaga deployment), albo w Business Rules Engine (co jest lepsze, bo reguły można zmieniać bez kodu).
Agenty AI wprowadzają nowe pytanie: gdzie kończą się reguły, a gdzie zaczyna się rozumowanie agenta?
Czym jest business rules engine w kontekście agentów
Business Rules Engine (BRE) to system zarządzania i egzekwowania reguł biznesowych oddzielony od kodu aplikacji — pozwalający na zmianę reguł przez biznes bez programowania — który w architekturach agentowych pełni rolę guardrails: deterministyczne ograniczenia których agent nie może przekroczyć niezależnie od swojego rozumowania.
BRE jako guardrails dla agentów
Agent AI jest probabilistyczny — jego decyzje nie są 100% deterministyczne. Dla decyzji które muszą być deterministyczne (zatwierdzenie transakcji powyżej limitu zawsze wymaga human approval), BRE jest warstwą poniżej agenta która działa niezależnie od modelu.
Architektura: agent proponuje akcję → BRE weryfikuje czy akcja jest zgodna z regułami → jeśli tak: agent wykonuje → jeśli nie: BRE blokuje i/lub eskaluje.
Ten wzorzec zapewnia że nawet gdy agent „chce” zrobić coś niezgodnego z polityką (przez błąd, przez prompt injection), BRE zablokuje na poziomie infrastruktury.
Popularne BRE
Drools (Red Hat/JBoss): open-source, szeroko używany w enterprise Java. Bogaty język reguł, dojrzały ekosystem.
Microsoft Azure Logic Apps Rules: cloud-based, integracja z Power Platform.
IBM ODM (Operational Decision Manager): enterprise-grade, często w dużych bankach i ubezpieczalniach.
Custom JSON/YAML rules: prostsze organizacje definiują reguły w konfiguracji zamiast dedykowanego BRE — wystarczające dla prostych przypadków.
BRE vs LLM — kiedy co
BRE: gdy reguła musi być 100% deterministyczna, gdy reguła jest prosta i wyrażalna przez if-then, gdy zmiana reguły musi być łatwa dla biznesu bez IT.
LLM: gdy decyzja wymaga interpretacji kontekstu, gdy reguła jest zbyt złożona do wyrażenia przez if-then, gdy przypadki edge są różnorodne i nieprzewidywalne.
Dobrze zaprojektowany system agentowy używa obu: BRE dla hard constraints, LLM dla soft judgments.