Jak tworzyć prompty w AI Builder i wykorzystywać je w przepływach Power Automate?

Czym są prompty w AI Builder i jak współpracują z Power Automate?

Wiadomość e-mail z prośbą klienta może zawierać jednocześnie opis problemu, numer zamówienia i pytanie o zwrot. Klasyczny przepływ automatyzacji bez trudu zapisze taką wiadomość lub prześle ją do wskazanej osoby. Trudniej jednak ustalić za pomocą samych warunków i słów kluczowych, czego dotyczy zgłoszenie i które informacje są najważniejsze. W takich zadaniach przydają się prompty w AI Builder: pozwalają wykorzystać model generatywnej AI do interpretowania i przetwarzania treści.

Prompt jako instrukcja dla modelu AI

Prompt określa zadanie, które ma wykonać model — na przykład streścić korespondencję, przypisać zgłoszenie do kategorii albo przygotować propozycję odpowiedzi. W AI Builder, narzędziu platformy Microsoft Power Platform, można przygotować taki prompt do wielokrotnego użycia, a następnie przekazywać mu dane z kolejnych uruchomień automatyzacji. Instrukcja pozostaje ta sama, zmienia się natomiast materiał do przetworzenia.

Tworzenie promptu nie jest trenowaniem własnego modelu. Polega na zlecaniu zadania dostępnemu modelowi generatywnemu za pomocą instrukcji i dostarczonego kontekstu. To również coś innego niż formuła czy warunek logiczny: prompt może pomóc rozpoznać sens wypowiedzi zapisanej na wiele różnych sposobów, ale jego wynik nie ma takiej przewidywalności jak rezultat obliczenia matematycznego.

Podział ról między AI Builder a Power Automate

AI Builder odpowiada za wykonanie zadania przez model, a Power Automate za przebieg procesu. Przepływ ustala, kiedy uruchomić prompt, skąd pobrać dane i co zrobić z otrzymanym wynikiem. Wywołanie promptu jest więc jednym z etapów automatyzacji, obok pobierania wiadomości, zapisywania rekordów czy wysyłania powiadomień.

Przykładowo po otrzymaniu zgłoszenia Power Automate może przekazać jego treść do promptu w AI Builder. Model przygotuje krótkie streszczenie i zaproponuje kategorię, a przepływ zapisze te informacje przy zgłoszeniu oraz powiadomi odpowiedni zespół. Nie trzeba w tym celu prowadzić osobnej rozmowy z chatbotem — zadanie AI zostaje włączone w proces obsługiwany przez przepływ.

Kiedy warto wykorzystać takie połączenie?

Prompty są szczególnie przydatne tam, gdzie dane mają swobodną, niejednolitą formę i wymagają interpretacji języka. Typowe zastosowania obejmują:

• streszczanie treści — skracanie długich wiadomości, notatek i opisów do informacji potrzebnych pracownikowi;
• klasyfikowanie zgłoszeń — rozpoznawanie tematu lub intencji, nawet gdy autorzy używają różnych sformułowań;
• wydobywanie informacji z tekstu — wskazywanie danych istotnych dla dalszej obsługi sprawy;
• przygotowywanie wersji roboczych — tworzenie propozycji odpowiedzi lub opisów do zatwierdzenia przez człowieka.

Nie każde zadanie wymaga jednak generatywnej AI. Obliczanie kwot, porównywanie dat czy sprawdzanie obowiązkowych pól lepiej pozostawić standardowym działaniom i warunkom Power Automate. Prompt uzupełnia reguły automatyzacji, zamiast je zastępować. Ponieważ model może błędnie zinterpretować treść lub wygenerować nieprawidłową odpowiedź, jego wynik należy traktować jako materiał wymagający odpowiedniej kontroli — szczególnie gdy wpływa na decyzje finansowe, uprawnienia lub komunikację z klientem.

Projektowanie promptu: cel, kontekst i zasady

Dobry prompt w AI Builder powinien opisywać zadanie tak, aby model nie musiał zgadywać, co oznacza poprawny wynik. Polecenie „przeanalizuj wiadomość klienta” pozostawia zbyt wiele swobody: może prowadzić do streszczenia, oceny emocji albo propozycji odpowiedzi. Jeśli wynik ma wspierać przepływ Power Automate, potrzebna jest konkretniejsza instrukcja, na przykład: „Rozpoznaj główny temat zgłoszenia i przypisz je do jednej z podanych kategorii”. W Cognity często słyszymy pytania, jak projektować takie instrukcje w praktyce — odpowiadamy na nie także na blogu.

Określ cel i granice zadania

Zacznij od ustalenia, jaką pracę ma wykonać model i do czego zostanie wykorzystany jej rezultat. Klasyfikacja, wydobywanie informacji i tworzenie treści wymagają różnych instrukcji. Przy klasyfikacji najważniejsze są definicje kategorii i reguły wyboru. Przy wydobywaniu informacji liczy się oparcie odpowiedzi na materiale źródłowym, bez uzupełniania luk domysłami. Przy redagowaniu tekstu trzeba dodatkowo określić odbiorcę, ton wypowiedzi i zakres dozwolonych stwierdzeń.

Nie łącz tych celów automatycznie. Jeżeli potrzebujesz wyłącznie kategorii zgłoszenia, nie proś przy okazji o rozbudowane uzasadnienie i gotową odpowiedź dla klienta. Każde dodatkowe zadanie zwiększa złożoność instrukcji. Gdy kilka czynności jest rzeczywiście potrzebnych, jasno opisz ich kolejność oraz wzajemną zależność.

Dodaj kontekst, który wpływa na decyzję

Kontekst wyjaśnia modelowi znaczenie zadania w danym procesie. Może obejmować opis obsługiwanych spraw, definicje pojęć lub fragment obowiązującej procedury. Samo polecenie „jesteś ekspertem ds. obsługi klienta” nie zastąpi tych informacji. Znacznie użyteczniejsze będzie wyjaśnienie, że pytanie o termin płatności należy traktować jako sprawę rozliczeniową, a informację o niedziałającej funkcji — jako zgłoszenie techniczne.

Wybieraj tylko informacje potrzebne do wykonania zadania. Nadmiar materiału może utrudniać rozpoznanie najważniejszych reguł, zwłaszcza gdy dokumenty zawierają sprzeczne zalecenia. Jeśli korzystasz z kilku źródeł, określ, które z nich ma pierwszeństwo w razie rozbieżności.

Zapisz zasady postępowania i ograniczenia

Prompt powinien wskazywać nie tylko oczekiwane działanie, lecz także sposób postępowania w sytuacjach niejednoznacznych. Szczególnie przydatne są następujące reguły:

• Zakres źródeł: opieraj odpowiedź wyłącznie na przekazanej wiadomości i dołączonych zasadach.
• Brak informacji: nie dopowiadaj brakujących faktów; wskaż, że nie ma podstaw do rozstrzygnięcia.
• Kilka możliwych odpowiedzi: zastosuj podaną regułę pierwszeństwa albo oznacz sprawę jako wymagającą oceny człowieka.
• Granice uprawnień: nie obiecuj zwrotu pieniędzy, rabatu ani terminu realizacji, jeśli nie wynika to z udostępnionych informacji.

Oddziel instrukcje od treści podlegającej analizie. Zaznacz, że wiadomości klientów i załączone dokumenty są materiałem źródłowym, a nie poleceniami dla modelu. To pomaga ograniczać wpływ instrukcji ukrytych w analizowanej treści, choć samo sformułowanie promptu nie stanowi pełnego zabezpieczenia.

Użyj przykładów do wyjaśnienia trudnych rozróżnień

Przykłady są najbardziej wartościowe tam, gdzie sama definicja pozostawia wątpliwości. Dla klasyfikacji zgłoszeń możesz wskazać, że „Nie mogę pobrać faktury, ponieważ pojawia się błąd” oznacza problem techniczny, natomiast „Na fakturze widnieje nieprawidłowa kwota” dotyczy rozliczeń. Taka para pokazuje, że o kategorii decyduje charakter problemu, a nie samo wystąpienie słowa „faktura”.

Każdy przykład powinien być zgodny z zapisanymi zasadami. Jeśli poprawna odpowiedź wymaga wyjątku, opisz go wprost zamiast oczekiwać, że model sam odtworzy regułę z pojedynczego przypadku.

Definiowanie wejść i wyjść w AI Builder: parametry, typy danych i mapowanie

Wejścia i wyjścia promptu tworzą kontrakt między AI Builder a przepływem Power Automate. Wejścia określają, jakie dane model otrzyma do przetworzenia, a wyjścia — jaki wynik będzie dostępny dla kolejnych kroków automatyzacji. Warto zdefiniować ten kontrakt przed podłączeniem promptu do przepływu: ustalić nazwy parametrów, znaczenie przekazywanych wartości oraz zakres oczekiwanej odpowiedzi.

Parametry wejściowe: oddziel dane zmienne od instrukcji

Parametr wejściowy to miejsce na wartość dostarczaną przy każdym uruchomieniu promptu. Może nią być treść wiadomości, opis zgłoszenia lub dokument do analizy. Instrukcja pozostaje częścią promptu, natomiast zawartość parametrów zmienia się zależnie od przetwarzanego rekordu czy pliku.

W edytorze promptu AI Builder należy zdefiniować wejście i umieścić odwołanie do niego w odpowiednim miejscu instrukcji. Samo wpisanie nazwy, na przykład tresc_zgloszenia, jako zwykłego tekstu nie tworzy parametru. Dopiero zdefiniowane wejście można powiązać z danymi przekazywanymi przez przepływ.

Nazwy powinny wskazywać zawartość i przeznaczenie danych. Tresc_zgloszenia oraz jezyk_odpowiedzi są czytelniejsze niż tekst1 i tekst2. Warto też rozdzielać informacje o różnych funkcjach: materiał do analizy nie powinien być połączony w jednym parametrze z ustawieniami dotyczącymi wyniku.

Typ danych: uwzględnij różnicę między źródłem a wejściem promptu

Typ wartości w Power Automate nie zawsze odpowiada typowi wejścia w AI Builder. Przepływ może operować na liczbach, wartościach logicznych, tablicach i obiektach, ale nie oznacza to, że każda z tych struktur ma osobny odpowiednik w edytorze promptu. Podstawowym wejściem jest tekst; dostępność wejść obrazowych lub dokumentowych zależy od obsługiwanych funkcji i wybranego modelu.

Mapowanie: przypisz źródło do konkretnego parametru

Mapowanie oznacza wskazanie, która wartość z przepływu zasila dane wejście promptu. Dla analizy zgłoszeń parametr tresc_zgloszenia może otrzymywać opis z rekordu, a jezyk_odpowiedzi — preferencję językową zapisaną w osobnym polu. Zgodność typów nie wystarcza: musi zgadzać się również znaczenie danych. Temat wiadomości i jej treść są tekstem, lecz dostarczają modelowi innego zakresu informacji.

Dla każdego parametru ustal, czy wartość jest niezbędna, co oznacza jej brak i czy dopuszczasz wartość domyślną. Pusty tekst nie zawsze znaczy to samo co brak danych. Nie należy też zastępować nieznanej kwoty zerem, ponieważ zmienia to sens informacji przekazanej do analizy.

Wyjścia: określ, co przepływ ma otrzymać

Odpowiedź tekstowa sprawdza się przy streszczeniach i projektach wiadomości. Jeżeli przepływ potrzebuje kilku osobnych wartości, na przykład kategorii zgłoszenia i jego streszczenia, lepszym punktem wyjścia jest odpowiedź ustrukturyzowana — tam, gdzie konfiguracja promptu udostępnia taki format.

Na tym etapie określ przede wszystkim nazwy elementów wyniku, ich znaczenie, oczekiwane typy oraz dopuszczalne wartości. Kategoria powinna mieć uzgodniony zakres, a streszczenie zawierać tekst. Nie zakładaj, że liczba zapisana w swobodnej odpowiedzi automatycznie stanie się wartością liczbową w Power Automate. Jasne rozdzielenie treści odpowiedzi od typu danych potrzebnego w przepływie ogranicza późniejsze problemy z wykorzystaniem wyniku.

Wymuszanie formatu odpowiedzi: stabilny JSON, schemat i obsługa błędów

Odpowiedź zrozumiała dla człowieka nie zawsze nadaje się do automatycznego przetwarzania. Dla odbiorcy „Nie znaleziono numeru dokumentu” i „Numer: brak” znaczą niemal to samo. Dla przepływu mogą być dwoma różnymi, trudnymi do obsłużenia wynikami. Dlatego odpowiedź promptu powinna mieć stałą strukturę, jednoznaczne typy wartości i ustalony sposób sygnalizowania braków.

Instrukcja tekstowa a ustrukturyzowane wyjście

Polecenie „zwróć wyłącznie JSON” pomaga określić oczekiwany wynik, ale samo w sobie nie zapewnia jego poprawności. Model może dodać komentarz, otoczyć odpowiedź znacznikami Markdown albo zmienić nazwę pola. Jeżeli konfiguracja promptu w AI Builder udostępnia format wyjściowy JSON, należy wykorzystać tę opcję i zdefiniować oczekiwaną strukturę, zamiast polegać wyłącznie na treści instrukcji.

Warto rozróżnić trzy poziomy poprawności: składnia JSON pozwala odczytać odpowiedź, zgodność ze schematem zapewnia oczekiwany układ i typy pól, a poprawność merytoryczna oznacza zgodność wartości z materiałem źródłowym. Poprawny JSON może nadal zawierać błędnie rozpoznany numer dokumentu. Formatowanie nie zastępuje więc sprawdzenia danych.

Stały kontrakt odpowiedzi

Strukturę wyniku najlepiej traktować jak kontrakt między promptem a przepływem. W Cognity omawiamy projektowanie takiego kontraktu zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników. Nazwy pól nie powinny zależeć od języka dokumentu ani sposobu sformułowania odpowiedzi. Ustal również, czy wynikiem zawsze będzie pojedynczy obiekt, czy tablica obiektów — nawet wtedy, gdy znaleziono tylko jeden element.

• Pola wymagane: określ, które klucze muszą wystąpić w każdej odpowiedzi.
• Typy wartości: rozróżnij tekst, liczby, wartości logiczne, obiekty i tablice. Numer dokumentu zwykle powinien być tekstem, ponieważ może zawierać litery, ukośniki lub zera wiodące.
• Brak danych: wybierz jedno oznaczenie, np. null, i nie zastępuj go zamiennie pustym tekstem, zerem czy słowem „brak”.
• Dozwolone wartości: dla statusów i kategorii stosuj zamknięty zestaw, zamiast swobodnych opisów.

Przykładowa odpowiedź przy nieobecności numeru w materiale źródłowym może wyglądać tak:

{
  "status": "brak_danych",
  "numer_dokumentu": null
}

Instrukcja powinna jasno zabraniać zgadywania brakujących wartości. Należy też wskazać, że wynik nie może zawierać wprowadzenia, komentarzy ani znaczników Markdown otaczających JSON.

Schemat jako punkt odniesienia dla walidacji

Przykładowy obiekt pokazuje oczekiwany wygląd odpowiedzi, ale nie opisuje wszystkich dopuszczalnych wariantów. Do tego służy JSON Schema. Poniższy schemat ilustruje kontrakt dla powyższego wyniku; może być podstawą walidacji po stronie odbiorcy, niezależnie od sposobu definiowania wyjścia w edytorze promptu:

{
  "type": "object",
  "properties": {
    "status": {
      "type": "string",
      "enum": ["ok", "brak_danych"]
    },
    "numer_dokumentu": {
      "type": ["string", "null"]
    }
  },
  "required": ["status", "numer_dokumentu"],
  "additionalProperties": false
}

Wymagany klucz nie oznacza obowiązkowej niepustej wartości: pole numer_dokumentu musi istnieć, ale może zawierać null. Ten prosty schemat nie sprawdza jednak zależności między polami. Reguła „status ok wymaga niepustego numeru” potrzebuje dodatkowego warunku walidacyjnego.

Brak danych to nie błąd techniczny

Warto oddzielić prawidłowy wynik z brakującą informacją od niepoprawnego JSON, naruszenia schematu oraz nieudanego wywołania usługi. Status brak_danych opisuje zawartość dokumentu — nie powinien maskować błędu przetwarzania.

Odpowiedzi niezgodnej z kontraktem nie należy przekazywać dalej jako poprawnych danych ani naprawiać przez przypadkowe usuwanie znaków. Na poziomie kontraktu trzeba ustalić, które niezgodności odrzucają wynik, a które są dopuszczalnym brakiem informacji. Dzięki temu przepływ nie pomyli awarii z dokumentem, w którym rzeczywiście nie znaleziono szukanej wartości.

5. Testowanie i iteracja promptów: przypadki testowe, pomiary jakości i regresje

Poprawna odpowiedź uzyskana podczas pojedynczej próby w AI Builder nie oznacza jeszcze, że prompt jest gotowy do wykorzystania w przepływie Power Automate. Model może dobrze obsłużyć krótki, uporządkowany tekst, a pomylić się przy wiadomości zawierającej kilka wątków, niepełne informacje lub sprzeczne żądania. Testowanie powinno sprawdzać nie tylko jakość pojedynczej odpowiedzi, lecz także powtarzalność zachowania na danych podobnych do tych, które rzeczywiście trafią do procesu.

Przypadki testowe: nie tylko poprawne i kompletne dane

Przygotuj stały zestaw wejść, do którego będziesz wracać po każdej zmianie promptu. Wykorzystaj reprezentatywne dane, po usunięciu lub zastąpieniu informacji poufnych. Dla każdego przypadku zapisz oczekiwany wynik albo kryteria jego akceptacji. W zadaniu klasyfikacyjnym może to być konkretna kategoria; przy streszczaniu — lista faktów, które muszą zostać zachowane, oraz informacji, których model nie powinien dopowiadać.

Zestaw dla promptu analizującego wiadomości może obejmować następujące grupy:

Oddziel przypadki używane podczas dopracowywania promptu od zestawu kontrolnego. Jeśli każdą zmianę oceniasz wyłącznie na tych samych kilku przykładach, możesz nieświadomie dopasować rozwiązanie do testów zamiast poprawić jego skuteczność na nowych danych.

Pomiary jakości: oceniaj wynik według zadania

Ocena „odpowiedź wygląda dobrze” jest zbyt ogólna, by porównywać kolejne warianty. Dobierz miary do zastosowania. Dla klasyfikacji sprawdzaj odsetek poprawnych przypisań oraz pomyłki między kategoriami. Jeżeli przeoczenie pilnego zgłoszenia ma większe konsekwencje niż nadanie pilności zwykłej wiadomości, oceniaj te błędy osobno. Sama średnia skuteczność może ukrywać problem w najważniejszej grupie.

Przy wydobywaniu informacji mierz poprawność poszczególnych pól, pominięcia i wartości dopisane bez podstawy w źródle. W streszczeniach oceniaj zgodność faktów, zachowanie kluczowych ustaleń i brak nieuzasadnionych wniosków. Poprawność techniczną odpowiedzi oddziel od jej poprawności merytorycznej — wynik może mieć oczekiwaną strukturę, a mimo to zawierać błędną decyzję.

Przed testem ustal warunki akceptacji oraz błędy blokujące wdrożenie. Zapisuj też czas odpowiedzi, jeśli wpływa na użyteczność procesu. Wybrane przypadki uruchamiaj wielokrotnie: odpowiedzi modelu mogą się różnić, dlatego pojedynczy sukces nie potwierdza stabilności.

Iteracja i regresje: sprawdzaj, co poprawa mogła zepsuć

Każdą iterację rozpocznij od konkretnej obserwacji, na przykład: „model pomija termin wskazany w dalszej części wiadomości”. Następnie wprowadź ograniczoną zmianę i ponownie wykonaj testy. Modyfikowanie kilku elementów naraz utrudnia ustalenie, który z nich rzeczywiście wpłynął na wynik.

Test regresyjny polega na ponownym sprawdzeniu wcześniej ocenionych przypadków po zmianie promptu lub modelu. Jego celem jest wykrycie sytuacji, w której poprawa jednego zachowania pogarsza inne. Porównuj oba warianty na identycznych wejściach i według tych samych kryteriów, analizując zarówno wyniki zbiorcze, jak i konkretne nowe błędy.

Każdy istotny błąd znaleziony podczas użytkowania warto dodać do zestawu regresyjnego. Dzięki temu kolejne poprawki są oceniane również wobec problemów, które faktycznie wystąpiły, a nie tylko wobec przewidywanych scenariuszy.

6. Wersjonowanie i utrzymanie: zmiany, kompatybilność wsteczna, dokumentacja i wdrożenia

Prompt wykorzystywany w przepływie Power Automate jest częścią logiki rozwiązania, a nie tylko zapisanym poleceniem. Zmiana pojedynczej instrukcji może wpłynąć na klasyfikację zgłoszeń, zawartość podsumowań czy sposób interpretacji dokumentów. Dlatego zmiany promptu warto traktować jak zmiany w aplikacji: identyfikować wydania, oceniać ich wpływ na istniejące przepływy i wdrażać je w kontrolowany sposób.

Rozróżniaj korektę instrukcji od zmiany kontraktu

Kontraktem promptu są oczekiwania dotyczące jego wejść, wyjść oraz znaczenia zwracanych informacji. Korekta językowa, która nie zmienia zachowania, ma inny ciężar niż dodanie obowiązkowego parametru albo zastąpienie dotychczasowych kategorii nowymi. Ta druga sytuacja może wymagać aktualizacji wszystkich przepływów korzystających z promptu.

Pomocna jest umowna numeracja wydań, na przykład MAJOR.MINOR.PATCH. To przyjęta przez zespół zasada zarządzania zmianami, a nie założenie, że AI Builder automatycznie zapewnia taki mechanizm.

Chroń kompatybilność istniejących przepływów

Zgodność formatu nie oznacza jeszcze zgodności działania. Prompt może nadal zwracać pole „priorytet”, ale po zmianie instrukcji inaczej rozumieć wartość „wysoki”. Przepływ nie musi wtedy zgłosić błędu technicznego, choć zacznie podejmować inne decyzje biznesowe.

Przed edycją ustal, które przepływy korzystają z danego promptu i jakie założenia przyjmują. Nie traktuj zmiany współdzielonego promptu jako lokalnej poprawki. Przy zmianach niezgodnych wstecz bezpieczniejszym podejściem jest utrzymanie oddzielnego promptu dla nowego wydania, stopniowe przełączenie odbiorców i wycofanie starego dopiero po zakończeniu migracji. Sama etykieta wersji w nazwie nie gwarantuje, że przepływ korzysta z niezmiennego wydania.

Dokumentuj wydanie, nie tylko treść promptu

Dokumentacja powinna pozwalać ustalić, co działa na produkcji, dlaczego zostało zmienione i kto odpowiada za utrzymanie. Dla każdego wydania zapisz przynajmniej:

• numer wersji, datę oraz osobę lub zespół odpowiedzialny;
• treść instrukcji, definicje wejść i wyjść oraz istotne ustawienia, w tym wybrany model, jeśli jest konfigurowany;
• zakres i powód zmiany oraz ocenę kompatybilności;
• powiązane przepływy, środowiska docelowe i wymagane działania migracyjne;
• odwołanie do wyników weryfikacji oraz plan przywrócenia poprzedniego działania.

Przechowuj te informacje razem z artefaktami wydania w repozytorium lub innym kontrolowanym rejestrze zmian. Numer wersji rozwiązania Power Platform identyfikuje pakiet wdrożeniowy; nie zastępuje historii zmian poszczególnych promptów.

Wdrażaj przez środowiska i przygotuj plan wycofania

Oddziel rozwój, weryfikację i produkcję. Do przenoszenia promptów oraz powiązanych przepływów wykorzystuj rozwiązania Power Platform, uwzględniając wymagane zależności. Przed wdrożeniem sprawdź uprawnienia, dostępność wymaganych funkcji i zasobów AI Builder oraz konfigurację połączeń i zmiennych środowiskowych używanych przez przepływy. Unikaj doraźnych edycji produkcyjnych, które nie trafiają później do dokumentacji i źródłowego pakietu.

Plan wycofania musi być wykonalny, a nie tylko zapisany. Może polegać na ponownym wskazaniu poprzedniego promptu albo przygotowaniu nowego wydania przywracającego wcześniejsze instrukcje i ustawienia. Nie zakładaj, że import starszego pakietu rozwiązania zawsze będzie możliwy. Zachowanie poprzedniej konfiguracji ułatwia odtworzenie działania, ale nie gwarantuje identycznych odpowiedzi modelu generatywnego.

Integracja z Power Automate: wywołanie promptu, walidacja wyników i ścieżki wyjątków

Włączenie promptu do przepływu wymaga czegoś więcej niż dodania akcji AI Builder. Trzeba ustalić, kiedy model ma zostać wywołany, jakie warunki musi spełnić jego odpowiedź oraz co zrobić, gdy wynik nie nadaje się do dalszego użycia. Sukces techniczny akcji nie oznacza jeszcze, że odpowiedź jest poprawna biznesowo. Dlatego między wywołaniem modelu a zapisaniem danych, wysłaniem wiadomości czy zmianą statusu sprawy warto umieścić osobny etap kontroli.

Wywołanie promptu w odpowiednim miejscu przepływu

W Power Automate dodaj akcję AI Builder służącą do uruchamiania promptu, dostępną w angielskim interfejsie jako Run a prompt, a następnie wybierz przygotowany prompt. Przekaż mu dane z wyzwalacza lub wcześniejszych kroków przepływu. Przed uruchomieniem sprawdź, czy wymagane informacje są dostępne — brak treści wiadomości lub nieudany odczyt dokumentu lepiej obsłużyć wcześniej niż przekazywać modelowi niekompletne dane.

Wywołanie AI umieść za warunkami, które odrzucają zgłoszenia niewymagające analizy. Jeśli dalsze działanie można jednoznacznie określić na podstawie istniejącego pola, zwykły warunek Power Automate będzie bardziej przewidywalny niż generowanie odpowiedzi. Sprawdź też, czy w środowisku docelowym dostępne są prompt, wymagane uprawnienia, połączenia oraz odpowiednia pojemność rozliczeniowa dla używanych funkcji AI.

Walidacja przed wykonaniem działania

Odpowiedź modelu traktuj jako dane wymagające sprawdzenia, a nie gotową decyzję. Jeżeli prompt zwraca tekst zawierający JSON, akcja Parse JSON może pomóc zweryfikować jego strukturę i udostępnić pola kolejnym krokom. Nie potwierdzi jednak prawdziwości informacji ani zgodności wyniku z regułami procesu. Do tego służą dodatkowe warunki oraz, w razie potrzeby, porównanie z danymi źródłowymi.

• Kompletność: czy odpowiedź zawiera wszystkie wartości potrzebne do wykonania następnej akcji?
• Dopuszczalne wartości: czy wskazana kategoria, status lub kwota mieszczą się w zasadach przyjętych dla procesu?
• Zgodność ze źródłem: czy identyfikator dokumentu albo sprawy istnieje i odpowiada przetwarzanemu zgłoszeniu?
• Zakres uprawnień: czy wynik nie prowadzi do działania, którego przepływ nie powinien wykonywać automatycznie?

Dopiero po przejściu tych kontroli kieruj wynik do systemu docelowego. Przy operacjach o istotnych skutkach, takich jak zatwierdzenie płatności czy wysłanie wiążącej odpowiedzi, zastosuj akceptację człowieka. Deklarowana przez model „pewność” nie zastępuje weryfikacji.

Osobne ścieżki dla awarii i niepoprawnych wyników

Rozdziel błędy techniczne od odpowiedzi, które nie przeszły walidacji. Wywołanie i przetwarzanie wyniku możesz zgrupować w akcji Scope, a obsługę awarii uruchamiać przez Configure run after dla odpowiednich stanów, na przykład niepowodzenia lub przekroczenia czasu. Wynik poprawny technicznie, lecz niezgodny z regułami biznesowymi, skieruj osobnym warunkiem do ręcznej weryfikacji.

Ponawianie stosuj przede wszystkim przy problemach przejściowych, z ograniczoną liczbą prób. Ponowne wywołanie modelu nie gwarantuje naprawienia błędnej interpretacji. Zabezpiecz też przepływ przed powtórnym wykonaniem tej samej operacji, na przykład przez sprawdzenie identyfikatora zgłoszenia przed utworzeniem rekordu.

Na ścieżce wyjątków zapisuj identyfikator uruchomienia, etap wystąpienia problemu i przyczynę odrzucenia wyniku, ograniczając utrwalanie danych wrażliwych. Brak użytecznej odpowiedzi powinien prowadzić do kontrolowanego zatrzymania lub przekazania sprawy człowiekowi, a nie do podstawienia wartości domyślnej, która uruchomi nieuzasadnione działanie.

Przykłady end-to-end: streszczenie maila, klasyfikacja zgłoszeń, generowanie odpowiedzi dla klienta

W tych trzech zastosowaniach prompt pełni inną funkcję: skraca treść, przypisuje ją do kategorii albo przygotowuje nowy tekst. AI Builder odpowiada za przetworzenie informacji, a Power Automate za przebieg procesu — pobranie danych, przekazanie ich do promptu i wykorzystanie wyniku. Warto oceniać nie tylko jakość samej odpowiedzi modelu, lecz także to, czy pomaga ona wykonać konkretne zadanie. Podczas szkoleń Cognity pogłębiamy te zagadnienia na konkretnych przykładach z pracy uczestników.

Streszczenie maila: od wiadomości do notatki dla zespołu

Przykładowy przepływ rozpoczyna się po otrzymaniu wiadomości w skrzynce obsługiwanej przez zespół. Power Automate przekazuje jej treść do promptu w AI Builder, który przygotowuje krótkie streszczenie: czego dotyczy sprawa, jakiego działania oczekuje nadawca i jakie terminy wskazał. Następnie przepływ publikuje notatkę w Microsoft Teams wraz z odnośnikiem do oryginalnej wiadomości.

Jeśli klient opisuje opóźnioną dostawę, podaje numer zamówienia i prosi o kontakt do piątku, użyteczne streszczenie powinno zachować właśnie te informacje. Nie powinno natomiast dopisywać przyczyny opóźnienia ani przedstawiać oczekiwanego terminu kontaktu jako zobowiązania firmy.

Efektem procesu jest szybsze zapoznanie się ze sprawą, nie zastąpienie wiadomości źródłowej. To zastosowanie sprawdza się przy długiej korespondencji i przekazywaniu spraw między pracownikami. Jeśli do promptu trafia tylko ostatni mail, streszczenie nie obejmie wcześniejszych ustaleń z wątku.

Klasyfikacja zgłoszeń: od opisu problemu do właściwej kolejki

W drugim scenariuszu punktem wejścia jest nowe zgłoszenie z formularza lub skrzynki pocztowej. Prompt analizuje jego opis i wskazuje kategorię z przyjętego zestawu, na przykład: rozliczenia, problem techniczny lub pytanie o ofertę. Power Automate zapisuje wynik przy zgłoszeniu i kieruje sprawę do odpowiedniej kolejki obsługi.

Przykładowo wiadomość o dwukrotnym obciążeniu za tę samą usługę powinna trafić do rozliczeń, nawet jeśli nadawca nie użyje słów „faktura” ani „płatność”. Wartością modelu jest rozpoznanie sensu wypowiedzi, a nie wyłącznie obecności słów kluczowych. Gdy opis łączy kilka problemów lub nie pozwala wybrać kategorii, proces powinien przewidywać ręczną kwalifikację zamiast wymuszać przypadkowy przydział.

Rezultatem jest uporządkowana kolejka pracy. Skuteczność takiego rozwiązania można oceniać po liczbie zgłoszeń, które pracownicy muszą później przekierować do innego zespołu.

Generowanie odpowiedzi: od zgłoszenia do zatwierdzonej wiadomości

Ten scenariusz wymaga więcej niż samej treści pytania klienta. Power Automate pobiera również dostępne informacje potrzebne do odpowiedzi, na przykład aktualny status zamówienia lub zatwierdzony fragment zasad zwrotów. Prompt w AI Builder wykorzystuje ten materiał do przygotowania projektu wiadomości, który następnie trafia do pracownika do weryfikacji.

Jeżeli klient pyta o termin dostawy, a w systemie widnieje jedynie informacja o przygotowaniu przesyłki, projekt odpowiedzi powinien jasno oddać ten stan. Nie może zamieniać braku danych w obietnicę dostawy następnego dnia. Pracownik sprawdza fakty i ewentualne zobowiązania, po czym zatwierdza wiadomość do wysłania.

Automatyzacja kończy się tu gotową do akceptacji odpowiedzią, a niekoniecznie automatyczną wysyłką. To istotna różnica względem streszczania i klasyfikacji: wygenerowany tekst może trafić bezpośrednio do klienta i wpłynąć na jego oczekiwania. Największą korzyścią jest ograniczenie czasu redagowania powtarzalnych wiadomości przy zachowaniu kontroli nad ich treścią.

Najważniejsze narzędzia statystyczne wykorzystywane w Six Sigma 31 października 2026

Jak wykorzystać analizę statystyczną do ograniczenia kosztów złej jakości? 29 października 2026