Twoje automatyzacje low-code psują się, bo są zbyt inteligentne dla własnego dobra. Sztywna logika, jeśli to, to wyrok śmierci, gdy mierzysz się z nieuporządkowanymi danymi, które codziennie zawieszają Twoje systemy. Założenie, że dane są czyste, to grzech pierworodny projektowania low-code. Zbudowaliśmy nasz świat na modelu, jeśli to, ale ten model wymaga absolutnej pewności, by działać. Dane w świecie rzeczywistym nie są pewne. Zawierają literówki, brakuje im kontekstu, to chaotyczny strumień ludzkich błędów. Gdy deterministyczny system napotyka 1% odchylenia, nie nagina się i z pewnością nie adaptuje. Po prostu się psuje, tworzy to pułapkę kruchości, w której automatyzacja jest tak silna, jak Twój najczystszy punkt danych. W przedsiębiorstwie to bardzo nisko zawieszona poprzeczka dla sukcesu, ale problemem nie są dane, tylko model, którego używamy do ich przetwarzania. Śmierć determinizmu, logika deterministyczna to relikt ery danych strukturalnych.

Działała, gdy wszystko znajdowało się w tabelach SQL i gdy zmuszaliśmy ludzi do dopasowania się do z góry określonych ram. Ale ten świat już przeminął. Dziś 80% danych w firmach jest nieustrukturyzowanych, co oznacza, że żyją w e-mailach, czatach i nagraniach głosowych. Tradycyjne przepływy Power Automate traktują Jabka i 4PPL3 jak dwa różne wszechświaty. Dla systemu binarnego są to całkowicie niepowiązane ciągi znaków. Osiągnęliśmy punkt krytyczny, w którym koszt ręcznego czyszczenia danych przewyższa wartość samej automatyzacji. Jeśli musisz spędzić dwie godziny na poprawianiu pliku CSV tylko po to, by przepływ działał przez pięć sekund, w rzeczywistości niczego nie zautomatyzowałeś. Po prostu przeniosłeś pracę w inne miejsce. A i to nie tylko błyszcząca nowa funkcja, którą doklejamy do Power Platform. To fundamentalne przejście od dokładnego dopasowania do podobieństwa. Stary model pyta, czy to jest A?

Nowy model pyta, jak bardzo przypomina to A? Pomyśl o tym, jak poruszasz się po swojej skrzynce odbiorczej. Nie uruchamiasz w głowie wyrażeń regularnych, aby znaleźć fakturę. Szukasz wzorców. Szukasz kontekstu. Rozpoznajesz, że INV202 i numer faktury 202 to to samo, nawet jeśli znaki się nie zgadzają. Systemy deterministyczne nie potrafią tego zrobić. Są ślepe na intencje. Widzą tylko składnie. A w miarę zbliżania się do 2026 roku składnia staje się mniej ważna niż semantyka. Obserwujemy ogromną eksplozję ilości danych z czujników IOT, strumieni w czasie rzeczywistym i podsumowań generowanych przez LLM. Jeśli spróbujesz zarządzać tą ilością za pomocą sztywno zakodowanych rozgałęzień, jeśli to Twoja logika stanie się labiryntem. Skończysz z przepływami mającymi 50 zagnieżdżonych warunków, które i tak zepsują się w momencie, gdy dostawca zmieni swój podpis w e-mailu. Model, jeżeli to zakłada idealny świat, w którym dane wejściowe zawsze pasują do schematu.

W rzeczywistości jest jednak dokładnie odwrotnie. To dane są zmienną. Logika powinna być stałą, ale nasza logika była zbyt sztywna, by przetrwać kontakt z rzeczywistością. Budujemy szklane domy w świecie, w którym ciągle pada grat, a potem dziwimy się, że podłoga jest pełna odłamków. Przejście na projektowanie probabilistyczne to budowanie z gumy zamiast ze szkła. Chodzi o tworzenie systemów, które mogą przyjąć uderzenie literówki bez rozpatania się. Odchodzimy od przekonania, że system musi być w 100% poprawny lub w 100% błędny, bo w realnym świecie nic nie ma 100%. Od dekad okłamujemy samych siebie w kwestii jakości naszych danych. Budowaliśmy sterylne pokoje dla naszej logiki, a potem udawaliśmy zaskoczenie, gdy niechlujne dane od zespołu sprzedaży powodowały awarię systemu. Śmierć determinizmu to śmierć tego kłamstwa. To przyznanie, że nie możemy kontrolować danych wejściowych, więc musimy unowocześnić przetwarzanie.

Wkraczamy w erę przybliżonego przedsiębiorstwa, w której akceptujemy, że wystarczająco blisko jest lepsze niż precyzyjnie błędnie. Ponieważ system, który przetworzy 90% dopasowania, jest nieskończenie cenniejszy niż ten, który odrzuca wszystko poza 100% z godnością. To nie tylko zmiana techniczna, to zmiana psychologiczna. Musisz oswoić się z myślą, że twój system może być tylko całkiem pewny danych. Musisz nauczyć się projektować z myślą o wątpliwościach, bo to jedyny uczciwy sposób na obsługę nieustrukturyzowanych informacji. Ta zmiana wymaga przejścia od binarnych wyzwalaczy do czegoś znacznie bardziej subtelnego w wyniku pewności architektury niepewności. Jeśli przyjmiemy, że era logiki binarnej dobiegła końca, musimy zastąpić ją nowymi ramami. Nazywam to modelem orkiestry symfonicznej. W tradycyjnej architekturze id każdy jest solistą grającym ze sztywnego zapisu, a jeśli ktoś chybi choć jedną nutę, cały występ zostaje przerwany.

W architekturze probabilistycznej mamy deterministycznych dyrygentów zarządzających probabilistycznymi muzykami. Dyrygentem jest twój przepływ w powerautomatę. Dostarcza strukturę, narzuca tempo i wyznacza granice. Muzykami są modele AI. Są utalentowani, ale ekspresyjni i nie zawsze trafiają w dokładnie tę samą częstotliwość za każdym razem, gdy grają. Zadaniem dyrygenta nie jest zmuszanie muzyków, by byli robotami. Chodzi o to, by ich słuchać i decydować, czy dźwięk, który wydają jest wystarczająco dobry, by grać dalej. To prowadzi nas do głównego filaru nowoczesnego projektowania wyniku pewności. Wynik pewności to wartość od 0 do 1, która określa stopień wątpliwości. To sposób, w jaki model mówi, sądzę, że to pasuje i oto ile jestem w stanie na to postawić. W dawnym świecie mieliśmy sztywno zakodowane ścieżki. Jeśli temat wiadomości zawiera słowo faktura, zapisz załącznik. W nowym świecie stosujemy przekierowania oparte na poziomie pewności.

Uwidaczniamy wewnętrzne wątpliwości modelu dla systemu. Nie traktujemy już AI jak czarnej skrzynki, lecz jak świadka o określonym poziomie wiarygodności. Oto jak faktycznie zbudować to w Power Platform. Korzystając z AI Builder lub Azure AI nie otrzymujesz tylko wyodrębnionych danych. Otrzymujesz warstwę metadanych, która ujawnia prawdopodobieństwo dla każdego pojedynczego pola. Jeśli model wyodrębni kwotę 1500 dolarów, poinformuje Cię też, że jest tego pewien w 95%. Jako architekt masz teraz trzy odrębne strefy działania. Po pierwsze, strefa zielona. Pewność wynosi 0,90 lub więcej. Ryzyko błędu jest niskie, koszt pomyłki akceptowalny, a rezultat to pełna automatyzacja. System działa bez interwencji człowieka. Po drugie, strefa żółta. Pewność mieści się w przedziale od 0,60 do 0,89. Model jest dość pewny, ale nie ma pewności całkowitej. Może dokument był nieco rozmazany, a może pismo było nieczytelne.

W tej strefie stosujesz oznaczenie. System kieruje dane do weryfikacji przez człowieka w celu szybkiego sprawdzenia. Po trzecie, strefa czerwona. Pewność jest poniżej 0,60. Model zgaduje. W tej strefie odrzucasz dane lub eskalujesz sprawę. Nie dopuszczasz takich danych w pobliże swojej bazy produkcyjnej. To przejrzysta warstwa zarządzania ryzykiem. Pozwala ona skalować automatyzację przy jednoczesnym zachowaniu bezpiecznika. Pomyśl o implikacjach dla ładu korporacyjnego. W systemie deterministycznym błędy są ciche. Przepływ działa, wybiera błędną liczbę z powodu literówki i zapisuje ją w systemie ERP. Dowiadujesz się o tym dopiero pod koniec kwartału. W systemie probabilistycznym błąd ma swoją sygnaturę. System wie, że ma trudności i mówi Hej, przetworzyłem to, ale moja pewność wyniosła tylko 62%. To niezwykle potężny sygnał. Pozwala on zbudować pulpit nawigacyjny wątpliwości. Możesz dokładnie zobaczyć, gdzie twoje modele zawodzą.

Widzisz, którzy dostawcy przesyłają dokumenty, których AI nie może odczytać i które kroki procesów stale trafiają do strefy żółtej. Nie budujesz tylko przepływu, budujesz pętlę inteligencji. I właśnie tutaj Azure AI oraz AI Builder naprawdę błyszczą. Udostępniają one te wyniki na poziomie szczegółowym, więc możesz sprawdzić pewność dla konkretnej tabeli, komórki lub danego zamiaru. Możesz nawet użyć PowerFa, aby stworzyć dynamiczne progi. Być może dla raportu wydatków na 50 dolarów pewność 0,7 jest w porządku, ale dla zamówienia na 50 tysięcy dolarów potrzebujesz 0,98. W końcu dostosowujesz swoją logikę techniczną do ryzyka biznesowego. Traktowaliśmy każdy punkt danych tak, jakby miał taką samą wagę, ale tak nie jest. Projektowanie probabilistyczne pozwala traktować decyzje o wysokiej stawce inaczej niż te o niskiej, nawet w tym samym przepływie. Nie budujesz już dla idealnego świata, budujesz dla świata, w którym dokładnie wiesz, ile niepewności jesteś w stanie tolerować.

A gdy opanujesz wynik, możesz zacząć przyglądać się logice, która wypełnia luki. Dopasowanie rozmyte i logika semantyczna. Ale jak właściwie radzimy sobie z danymi, które wpadają w ten obszar niepewności? Zaczynamy od przyznania, że dokładne dopasowanie zawodzi. Zawodzi, ponieważ brakuje mu kontekstu. W starym modelu, jeśli nazwa dostawcy różniła się choćby kropką, wyszukiwanie kończyło się niepowodzeniem. Wyszukiwanie nie dba o Twój zamiar, liczą się dla niego tylko wartości ASCII. W tym miejscu pojawia się dopasowanie rozmyte. To technika, która identyfikuje i łączy nieidentyczne rekordy poprzez obliczanie wskaźnika podobieństwa i działa jako pomost między IBM a IBM. A ten wpływ nie jest tylko teoretyczny. Badania pokazują, że wdrożenie dopasowania rozmytego może poprawić wskaźniki dopasowań nawet o 24%. To 24% Twoich danych, które wcześniej zostałyby odrzucone lub wysłane do człowieka w celu ręcznej poprawy.

W środowisku o dużej skali oznacza to tysiące godzin odzyskanego czasu. Jednak musisz zrozumieć mechanikę tego procesu. Istnieją dwa główne sposoby myślenia o tym zagadnieniu. Po pierwsze, logika oparta na znakach. Często nazywa się to odległością Lewenshtajna. Liczy ona liczbę edycji potrzebnych do przekształcenia jednego ciągu znaków w drugi. Jest idealna do wykrywania literówek. Jeśli ktoś napisze manage zamiast management, system widzi brakujące EIA, oblicza odległość i widzi, że są niemal identyczne. Po drugie, mamy logikę semantyczną. Tutaj sprawy robią się interesujące. Logika semantyczna nie dba opisownie. Liczy się dla niej znaczenie. Jeśli jeden system mówi klient, a drugi odbiorca, dopasowanie oparte na znakach zawiedzie za każdym razem. Ale model semantyczny wie, że to to samo. To przejście od dopasowywania znaków do dopasowywania pojęć. Łącząc wskaźniki pewności z dopasowaniem rozmytym, tworzysz system, który potrafi poruszać się w chaotycznej rzeczywistości danych biznesowych.

Nie ograniczają Cię już sztywne reguły, które psują się w momencie, gdy człowiek zrobi literówkę. Budujesz system, który rozumie niuanse. Właśnie w ten sposób przechodzisz od prostej automatyzacji do prawdziwej cyfrowej inteligencji, tworząc samokorygujące się przepływy pracy. Nawet z najlepszym dopasowaniem rozmytym na świecie musimy zmierzyć się z rzeczywistością, w której sztuczna inteligencja wciąż halucynuje. Tak po prostu działa obecnie ta technologia. Aktualne dane pokazują, że nawet najbardziej zaawansowane modele mają wskaźniki halucynacji na poziomie od 15 do 20%. Jeśli budujesz systemy dla biznesu, nie możesz ignorować współczynnika błędów wynoszącego 1 na 5 i zdecydowanie nie rozwiążesz tego samym inżynieringiem promptów. Musisz zaakceptować fakt, że osiągnięcie 0% halucynacji to nie magiczka sztuczka. To świadomy wybór architektoniczny. W tym miejscu wykraczamy poza prostą automatyzację i zaczynamy budować odporne, samokorygujące się przepływy pracy.

Robimy to stosując strukturę, którą nazywam wzorcem weryfikacji dwutorowej. Działa ona jak zabezpieczenie, które powstrzymuje kreatywną wyobraźnię, a i przed zniekształceniem Twoich rzeczywistych danych. Istnieje jedna fundamentalna zasada dla nowoczesnego architekta. Nigdy nie pozwalaj dużemu modelowi językowemu wykonywać obliczeń. LLMY to silniki miękkiego rozumowania, co czyni je świetnymi w rozumieniu intencji lub znajdowaniu konkretnych szczegółów w stercie niechlujnego tekstu. Są jednak statystycznie niewiarygodne, jeśli chodzi o podstawową arytmetykę. Jeśli poprosisz AI o wyciągnięcie trzech pozycji z faktury i obliczenie sumy, w zasadzie prosisz system o porażkę. W samokorygującym się projekcie używasz LLM do części wymagającej miękkiego rozumowania, np. do wyciągania danych z nieczytelnego pliku PDF. Gdy masz już te liczby, przekazujesz je do systemu deterministycznego, aby obsłużył twarde ograniczenia.

To Twój przepływ w powerautomatę lub prosty silnik reguł powinien zajmować się dodawaniem. To on powinien sprawdzać podatek lub weryfikować przeliczenie waluty. Jeśli LLM twierdzi, że suma wynosi 500 dolarów, a Twoje obliczenia wskazują na 480 dolarów, system wykrył halucynację w czasie rzeczywistym. Zamiast ulec awarii, system uruchamia ścieżkę odzyskiwania. Może spróbować innego promptu lub oznaczyć błąd do weryfikacji przez człowieka. Na tym polega różnica między przepływem, który się psuje, a takim, który sam się naprawia. Obserwujemy taką samą zmianę w zrobotyzowanej automatyzacji procesów. Tradycyjne RPA jest bardzo kruche, ponieważ zależy od dokładnych współrzędnych na ekranie. Jeśli przycisk przesunie się tylko o 3 piksele w lewo, cały bot przestaje działać. Samonaprawiające się RPA zmienia to dzięki zastosowaniu wizji probabilistycznej. Bot nie szuka już konkretnych współrzędnych pikseli.

Zamiast tego szuka przycisku wyglądającego jak ikona zapisu w górnej części strony. Gdy interfejs się zmienia, bot wykorzystuje kontekst, by dostosować się w locie. Rozpoznaje nowy układ, aktualizuje własną logikę i kończy zadanie. Tworzy to odporną pętlę, w której system widzi potencjalną awarię i tworzy rozwiązanie, zanim użytkownik zorientuje się, że wystąpił problem. Ta zmiana przesuwa nasz punkt ciężkości z wskaźników sukcesu na wskaźniki odzyskiwania sprawności. Przestajemy próbować uczynić AI idealną, co i tak jest niemożliwe, a zaczynamy czynić system niezawodnym. Chodzi o wbudowanie warstwy kontroli w każdą pojedynczą transakcję. Należy traktować AI jak bardzo szybkiego starzystę, który łatwo się rozprasza. Pozwalasz mu na czarną robotę czytania tysięcy e-maili, ale nigdy nie pozwalasz mu podpisywać czeków bez weryfikacji podpisu przez starszego audytora. W tym przypadku to twój deterministyczny kod jest tym audytorem.

Oddzielając myślenie od obliczeń, budujesz system, który radzi sobie z nieładem ludzkiego języka, zachowując precyzję szwajcarskiego zegarka. W ten sposób przenosisz AI z fazy testów do samego rdzenia swojej działalności. Nie ufasz modelowi, ufasz architekturze, którą wokół niego zbudowałeś. Tworzysz tak silną siatkę bezpieczeństwa, że sporadyczne potknięcia modelu nawet nie liczą się jako błąd. Stają się po prostu kolejnym elementem cyklu samokorekty. Brzmi to świetnie w laboratorium, ale w produkcji największym wąskim gardłem nie jest AI, lecz człowiek w pętli decyzyjnej. Brzmi to świetnie w laboratorium, ale w produkcji największym wąskim gardłem nie jest AI, lecz człowiek. Zazwyczaj mówimy o automatyzacji jak o prostym wyborze między człowiekiem a maszyną, ale prawdopodobieństwo zmusza nas do zajęcia niejednoznacznego stanowiska. Standardy branżowe ukazują dość otrzeźwiającą prawdę. Około 50% procesów, a i wciąż wymaga weryfikacji przez eksperta, zanim zostaną zakończone.

To główny powód, dla którego obserwujemy kryzys przy przejściu z fazy pilotażowej do wdrożenia. Jeśli spojrzysz na liczby, 88% programów pilotażowych, a i kończy się niepowodzeniem w ciągu roku. Nie zawodzą dlatego, że technologia jest zepsuta. Zawodzą, ponieważ projektujący je ludzie próbują zbyt wcześnie zautomatyzować zadanie w 100%. Zbudowali system, który działa na czystych danych testowych, ale logika pęka w momencie zetknięcia z rzeczywistymi problemami działu. Ignorując czynnik ludzki, tworzysz ogromne obciążenie weryfikacyjne. Jeśli Twoja sztuczna inteligencja oszczędza 10 minut wprowadzania danych, ale dokłada 50 minut ich sprawdzania, ponieważ zespół jej nie ufa, to w rzeczywistości tracisz produktywność. Zbudowałeś obciążenie, a nie zasób. Skuteczne projekty w 2026 roku będą traktować weryfikację jako kluczową funkcjonalność. Nie postrzegają one weryfikacji przez człowieka jako porażki systemu.

Zamiast tego traktują ją jako niezbędną część architektury. Koszty tej weryfikacji wliczają w zwrot z inwestycji już od pierwszego dnia. Sekretem skuteczności jest tutaj warstwowa logika przeglądu. W ten sposób skalujesz procesy, nie tracąc przy tym zdrowych zmysłów. Transakcje o wysokim stopniu pewności przebiegają bezszelestnie. Jeśli model jest pewny na 98%, a matematyka się zgadza, system po prostu działa dalej. Jednak przypadki o niskiej pewności, jak ta żółta strefa, o której mówiliśmy, wywołają eskalację. To całkowicie zmienia rolę człowieka. Odchodzimy od wprowadzania danych w stronę ich audytowania. W starym modelu człowiek był silnikiem, bo wykonywał całe pisanie i klikanie. W nowym modelu człowiek pełni funkcję zarządczą. Zajmuje się wyjątkami i wprowadza niuanse, których model probabilistyczny nie do końca rozumie. Pomyśl, jak to wpływa na zespół. Gdy ludzie wiedzą, że muszą zająć się tylko 5% faktycznie trudnych przypadków, pozostają znacznie bardziej zaangażowani.

Nie nudzą się już rutynowymi zadaniami. Wyzwania stanowi dla nich złożoność trudnych spraw. Aby to zadziałało, musisz jednak stworzyć odpowiedni interfejs. Nie możesz po prostu wysłać e-maila z informacją, że coś poszło nie tak. Musisz pokazać porównanie obok siebie. Pokaż o sobie źródłowy dokument. Pokaż, co wyodrębniła AI i zaznacz dokładnie to pole, w którym poziom pewności spadł. Jeśli chcesz się skalować, przestań udawać, że ludzka weryfikacja oznacza słabość automatyzacji. Jest wręcz przeciwnie. Dobrze zintegrowany człowiek sprawia, że system probabilistyczny jest wystarczająco silny, by przetrwać w świecie rzeczywistym. To ostatnia warstwa Twojej samokorygującej się architektury. Przyszłość agentowa. Patrzymy w stronę nowego horyzontu zwanego przedsiębiorstwem agentowym. To logiczny punkt końcowy wszystkiego, o czym dziś rozmawialiśmy. Wkraczamy w świat, w którym agenci to już nie tylko proste skrypty czy podstawowe przepływy, ponieważ stają się pełnoprawnymi cyfrowymi pracownikami.

Power Platform zmienia się na naszych oczach. Przekształca się ze standardowego kreatora aplikacji w pełne centrum orkiestracji. W starym modelu tworzyłeś konkretną aplikację, aby rozwiązać konkretny problem. W modelu agentowym tworzysz środowisko, w którym agenci rozwiązują te problemy za Ciebie. Ci agenci nie podążają tylko za statyczną listą kroków. Obserwują swoje otoczenie, oceniają własny poziom pewności i decydują, którego narzędzia najlepiej użyć w następnej kolejności. Do 2026 roku zarządzanie będzie wyglądać zupełnie inaczej niż jeszcze dwa lata temu. Narzędzia takie jak Perview i Sentinel zmierzają w stronę probabilistycznego wykrywania anomalii. Nie szukają już tylko wyciekłych haseł. Zamiast tego wypatrują wzorców zachowań, które po prostu wyglądają podejrzanie. Stosują tę samą logikę

danych, by chronić cały Twój tenant. Ta zmiana jest trwała. Osoby trzymające się sztywnej logiki, jeśli to zostaną z uszkodzonymi systemami i sfrustrowanymi zespołami, utkną w cyklu ciągłej konserwacji, próbując łatać szklany dom, który nigdy nie był budowany na taką pogodę. Przedsiębiorstwo agentowe zaczyna się od jednego spostrzeżenia. Nie musimy kontrolować każdej zmiennej, aby uzyskać niezawodny wynik. Musimy jedynie kontrolować architekturę. Naszym zadaniem jest zdefiniowanie progów i ustawienie zabezpieczeń,

by obsłużyć nowego dostawcę lub inny format dokumentu bez konieczności przepisywania choćby linii kodu przez programistę. To jest prawdziwa obietnica rozwiązań low-code. To zdolność poruszania się z szybkością myśli, a nie szybkością składni. Ale żeby do tego dojść, musisz zacząć dzisiaj. Przestań budować dla idealnego świata i zacznij budować dla tego chaotycznego, w którym naprawdę żyjemy. Musisz zaakceptować wątpliwości. Wyzwanie wdrożeniowe. Oto Twoje zadanie domowe na ten tydzień. Chcę, żebyś znalazł swój proces o najwyższym wskaźniku awaryjności. Nie wybieraj tego najbardziej złożonego, ale ten, który najczęściej zawodzi z powodu złych danych. Celem nie jest naprawa samych danych. Nie masz kontroli nad tym, co zdecydują się wysłać Ci użytkownicy lub dostawcy. Zamiast walczyć z tą rzeczywistością, chcę, żebyś dodał próg ufności. Wejdź do swojego AI Builder lub akcji LLM i udostępnij ten wynik prawdopodobieństwa.

Stwórz prosty warunek. Jeśli wynik ufności jest poniżej 85%, nie pozwól, by proces się zawiesił. Skieruj ten konkretny przypadek do folderu przeglądu lub listy SharePoint w celu ręcznej weryfikacji. Obserwuj, co stanie się z Twoim wskaźnikiem sukcesu. Zobaczysz, jak stres opuszcza Twój system, gdy tylko przestaniesz udawać, że każde wejście będzie idealne. Jeśli ta zmiana myślenia wpłynęła na Twoje podejście, obserwuj mnie, Mirko Petersa, na LinkedIn. Stale udostępniam tam szczegółowe analizy tych wzorców architektonicznych. Udostępnij to swojemu zespołowi, zwłaszcza jeśli Wasze procesy obecnie zawodzą. Musimy przestać budować ze szkła, a zacząć budować z zamierzeniem. Oto ta technika, która skraca czas przestoju o połowę, gdy tylko zaczniesz ją stosować. Jeśli chcesz poznać wersję dla zaawansowanych, której używają profesjonaliści, zobacz kolejny film. Zasubskrybuj, aby otrzymywać więcej poradników.

Przestań walczyć z chaotyczną rzeczywistością swoich danych i zacznij projektować z myślą o nich. Korzystając ze wskaźników ufności, przekształcasz kruche procesy w odporne systemy, które naprawdę działają. Ale jest pewien haczyk. Model działa tylko wtedy, gdy zbudujesz go poprawnie. Jeśli chcesz dokładnie zobaczyć, jak skonfigurować to w Copilot Studio, obejrzyj ten kolejny film już teraz. A jeśli to zmieniło twój sposób myślenia o sztucznej inteligencji, śledź mnie na LinkedIn lub zasubskrybuj Master The New Model.