--- title: "Jak zbudować ontologię firmy i podłączyć do niej dane?" url: "https://majchrzycki.com/blog/jak-zbudowac-ontologie-firmy-dane-reguly-agenci" description: "Praktyczny plan budowy ontologii firmy: decyzja, słownik, identyfikatory, mapowanie źródeł, jakość, akcje i uprawnienia. Działa niezależnie od platformy." --- # Jak zbudować ontologię firmy i podłączyć do niej dane? 19 kwietnia 2026·5 min czytania·Krzysztof Majchrzycki Temat: [Ontologia firmy](https://majchrzycki.com/blog/filar/ontologia-firmy) **Dobra ontologia firmy zaczyna się od decyzji, którą ktoś ma podjąć, a nie od importu wszystkich tabel.** Jeśli dyspozytor musi odpowiedzieć „które zamówienia są zagrożone i co mogę z tym zrobić?”, model powinien opisać zamówienie, klienta, dostawę, ograniczenie, zdarzenie i dozwolone działanie. Taką logikę da się zrealizować w [Palantir Ontology](https://www.palantir.com/docs/foundry/architecture-center/ontology-system/), w [Fabric IQ Ontology połączonej z agentem Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/fabric-iq) albo we własnym stosie opartym na otwartych standardach. Nazwy usług są różne; pytania projektowe pozostają podobne. ## 1\. Wybierz jedną decyzję i jej właściciela Zapisz pytanie biznesowe, rolę użytkownika, moment podjęcia decyzji i mierzalny wynik. „Ograniczyć opóźnienia dostaw” to cel; „o 8:00 wskazać zamówienia z ryzykiem spóźnienia i osobę mogącą zmienić plan” to użyteczny przypadek. Właściciel procesu powinien zatwierdzić definicje, a właściciel danych potwierdzić, skąd pochodzą fakty. [Praktyczne zasady projektowania Palantira](https://community.palantir.com/t/ontology-and-pipeline-design-principles/5481) zalecają zacząć od zastosowania i roboczych danych, a następnie rozwijać model oraz pipeline równolegle. To wskazówka praktyka platformy, nie obowiązkowy standard każdej ontologii. ## 2\. Ustal pojęcia i stabilne identyfikatory Narysuj mały fragment świata: `Klient` składa `Zamówienie`; `Zamówienie` dotyczy `Produktu`; `Dostawa` realizuje `Zamówienie`. Dla każdego typu podaj definicję, przykład, właściciela, identyfikator i regułę łączenia z innymi typami. Oddziel `Klient` jako podmiot prawny od kontaktu w CRM. Nie używaj numeru wiersza ani losowego UUID generowanego na każdym przebiegu pipeline jako trwałego klucza obiektu: po odświeżeniu relacje i historia mogą wskazać inny rekord. Zasady stabilnych kluczy i ograniczania zbędnych właściwości są szczegółowo opisane w [poradniku społeczności Palantira](https://community.palantir.com/t/ontology-and-pipeline-design-principles/5481). ## 3\. Podłącz źródła przez jawne mapowanie Zacznij od małej próbki ERP, CRM i dokumentów. Dla każdej właściwości zapisz: system źródłowy, pole, transformację, jednostkę, strefę czasu, częstotliwość aktualizacji i odpowiedzialność. Jedno pojęcie biznesowe może mieć kilka reprezentacji technicznych. Wówczas rozstrzygnij priorytet źródeł i regułę rozbieżności, zamiast ukrywać konflikt w zapytaniu SQL. Przypadki `brak identyfikatora`, `duplikat klienta` i `dostawa bez zamówienia` powinny trafić do jawnej kolejki jakości danych. Własny stos może przechowywać model w [OWL 2 i RDF](https://majchrzycki.com/blog/owl2-rdf-shacl-ai-os), sprawdzać rekordy przez SHACL, udostępniać graf przez Jena lub RDF4J i łączyć go z usługami operacyjnymi. W [Fabric IQ](https://learn.microsoft.com/en-us/fabric/iq/) ontologia jest dziś funkcją platformy Fabric; połączenie z Foundry nie sprawia, że „Foundry IQ Ontology” jest osobną, uniwersalną specyfikacją. [Palantir Ontology](https://majchrzycki.com/blog/palantir-ontology-system-jak-modelowac-decyzje-firmy) z kolei spina obiekty i akcje w obrębie swojej platformy. Wybór wdrożenia wpływa na przenośność, operacje i koszty. Ważny detal to **czas obowiązywania**. Status zamówienia z poniedziałku nie powinien po cichu udawać statusu z czwartku. Przy każdej właściwości określ, czy przechowujemy stan bieżący, historię zmian czy zdarzenia. Jeśli dwa systemy aktualizują tę samą cechę, zdefiniuj regułę konfliktu i pokaż użytkownikowi źródło. Ontologia jest wiarygodna tylko wtedy, gdy da się powiedzieć „ta informacja pochodzi z systemu X, została odczytana o Y, a definicję zatwierdził Z”. Na etapie integracji warto napisać cztery automatyczne testy. Pierwszy sprawdza unikalność klucza obiektu. Drugi wykrywa relacje prowadzące do nieistniejących obiektów. Trzeci porównuje liczbę rekordów i sumy kontrolne z systemem źródłowym. Czwarty sprawdza sytuacje graniczne: anulowane zamówienie, połączone konta klientów i dostawę podzieloną na kilka części. Taki zestaw daje większą wartość niż sam diagram z idealnymi przykładami. ## 4\. Dopiero potem dodaj działania i agenta Najpierw udostępnij odczyt i pokaż, że obiekt ma właściwe powiązania. Następnie nazwij akcję, np. `ZmieńTerminDostawy`, z warunkami wstępnymi, kontrolą uprawnień, skutkiem w systemie źródłowym i dziennikiem audytu. Agent może zaproponować akcję, lecz polityka dostępu i zatwierdzenie muszą być egzekwowane poza tekstem promptu. Nie oznaczaj pola z ERP jako „edytowalne” tylko dlatego, że UI na to pozwala: zapis musi trafić do właściwego systemu i nie może zostać nadpisany przez kolejny import. ## 5\. Wprowadź cykl zmian, nie jednorazowy diagram Przed wdrożeniem sprawdź na realnej próbce pięć pytań: czy identyfikatory są stabilne, czy relacje są kompletne, czy definicje rozumieją użytkownicy, czy dane mają świeżość potrzebną decyzji oraz czy można prześledzić źródło odpowiedzi agenta. Wersjonuj model, testy mapowania i reguły walidacji razem z kodem. Zmianę pojęcia uzgadniaj z właścicielem procesu; wersję techniczną migracji planuj osobno. [Protégé Desktop i WebProtégé](https://majchrzycki.com/blog/protege-ontologia-ai-os) pomagają w redakcji modelu, lecz nie zastępują integracji ani zarządzania uprawnieniami. **Przykładowy kontrakt obiektu** może zawierać `id`, nazwę biznesową, definicję, właściciela, system źródłowy, sposób aktualizacji, datę ważności, dopuszczalne relacje, politykę odczytu i listę akcji. Dla `Zamówienia` dodaj rozróżnienie między numerem handlowym a kluczem technicznym; numer widoczny na dokumencie bywa ponownie użyty w innej spółce albo roku. Dla relacji `maDostawę` określ, czy brak dostawy oznacza błąd, czy zamówienie przed planowaniem. Te niuanse decydują o tym, czy agent zada właściwe pytanie, czy poda fałszywe zapewnienie. ## 6\. Porównaj platformy tym samym testem Nie oceniaj Palantira, Fabric IQ i otwartego stosu liczbą ekranów edytora. Na tym samym przypadku sprawdź: ile pracy wymaga mapowanie źródeł, jak działa historia i lineage, jak ogranicza się odczyt pojedynczych obiektów, jak tworzy i zatwierdza akcje, jak wyeksportować definicje oraz co dzieje się przy zmianie wersji. Palantir może przyspieszyć budowę aplikacji operacyjnej w swoim ekosystemie; Fabric IQ może być naturalne dla danych utrzymywanych w Fabric; otwarty stos daje swobodę formatu, ale wymaga własnego projektu operacji i integracji. To warunki wyboru, nie ranking zwycięzców. W pilocie zapisz też koszt **odejścia**: czy firma zachowa definicje pojęć, mapowania, historię decyzji i testy, jeśli kiedyś zmieni platformę? Nawet gdy wykonanie pozostanie specyficzne dla dostawcy, słownik biznesowy i kryteria jakości mogą być utrzymywane w przenośnej dokumentacji. To praktyczny fundament suwerenności semantycznej. ## 7\. Zaplanuj identyfikację tej samej rzeczy w kilku systemach Najczęstszy problem nie polega na braku pojęcia `Klient`, lecz na tym, że CRM, ERP i sklep wskazują go różnymi identyfikatorami. Utwórz tabelę powiązań: identyfikator kanoniczny, identyfikatory źródłowe, metoda dopasowania, pewność dopasowania i właściciel korekty. Nie łącz rekordów automatycznie tylko dlatego, że mają tę samą nazwę. Dwie spółki mogą nazywać się podobnie, a jedna spółka może mieć kilka nazw handlowych. Dla niepewnych par wprowadź przegląd człowieka i możliwość rozłączenia błędnego scalenia bez utraty historii. To samo dotyczy zdarzeń. W systemie źródłowym `status=wysłane` może oznaczać nadanie paczki, a w innym potwierdzenie odbioru przez przewoźnika. Jeżeli ontologia połączy je w jedno `Dostarczono`, agent zacznie udzielać przedwczesnych zapewnień klientom. Dlatego przy pojęciu zapisuj definicję, moment zdarzenia, system, który ma prawo je stwierdzić, i dowód źródłowy. Diagram relacji jest dopiero początkiem semantyki. ## 8\. Oddziel rozwój modelu od publikacji danych Nową klasę czy relację można zaprojektować na danych przykładowych. Przed włączeniem realnych rekordów sprawdź, czy mapowanie zachowuje kardynalność i nie ujawnia danych między rolami. Wersja robocza modelu powinna być testowana na próbce z przypadkami skrajnymi, a publikacja do użytkowników mieć datę i właściciela. Jeśli zmiana usuwa właściwość, najpierw znajdź zależne aplikacje, zapytania i akcje; samo przemianowanie etykiety może zepsuć działające procesy. Przy każdej wersji zachowaj trzy artefakty: definicje pojęć, mapowanie do źródeł oraz zestaw pytań kontrolnych z oczekiwanymi odpowiedziami. Ten trzeci element jest szczególnie ważny dla agentów. Po zmianie ontologii ten sam agent może zacząć odnajdywać inne rekordy, choć prompt i model się nie zmieniły. Porównanie odpowiedzi przed i po wydaniu szybko ujawni zmianę semantyczną, której test poprawności JSON nie zobaczy. ## 9\. Ustal jasne kryterium gotowości Przed szerszym użyciem wybierz próbę rzeczywistych spraw: poprawnych, brakujących, zdublowanych i spornych. Dla każdej oceń, czy model wskazuje właściwy obiekt, relacje i źródło; czy użytkownik rozumie definicję; czy agent respektuje uprawnienia; czy akcja daje oczekiwany zapis w systemie źródłowym. Nie trzeba osiągać idealnej kompletności całej firmy. Trzeba umieć powiedzieć, **w jakim procesie** ontologia jest wystarczająco wiarygodna, a gdzie jeszcze pokazuje lukę. Pierwsza ontologia nie musi opisywać całej firmy. Jeśli obejmuje jedną decyzję, kilka typów obiektów, dwa źródła i jedną bezpieczną akcję, daje podstawę do sprawdzenia wartości. Rozszerzaj ją dopiero tam, gdzie nowa relacja pomaga człowiekowi lub agentowi podjąć lepszą decyzję. - Dane i analityka - Agenci AI ## Uporządkuj pierwszy krok z AI Bezpłatny poradnik pomaga wybrać proces, pytania diagnostyczne i kolejność działań. [Pobierz poradnik](https://majchrzycki.com/darmowy-poradnik-transformacji-ai-dla-firmy) Strony poradnika transformacji AI: rysunki i opisy cyfrowego modelu firmy ## Czytaj dalej - [Ontologia AI OS: semantyka, działania i decyzje](https://majchrzycki.com/blog/ontologia-ai-os-warstwy-semantyczna-kinetyczna-dynamiczna) - [Protégé Desktop i WebProtégé: ontologia dla AI OS](https://majchrzycki.com/blog/protege-ontologia-ai-os) - [Modelowanie danych: od ERD do ontologii firmy](https://majchrzycki.com/blog/modelowanie-danych-od-erd-do-ontologii-firmy) - [Ontologia Palantira w Enterprise OS: od danych do działania](https://majchrzycki.com/blog/palantir-ontologia-enterprise-os-decyzje-i-dzialania)