Poprosiłem agenta AI o zaprojektowanie funkcji rabatowej dla systemu aptecznego. Dostałem projekt szybko i był naprawdę niezły. Progi, komunikaty do klienta, integracja z kartą stałego klienta. Jeden problem: w polskiej aptece wdrożenie sporej części tego projektu bez analizy prawnej stworzyłoby poważne ryzyko.

Agent nie był głupi. Był wytrenowany na świecie, w którym sklep to sklep. A apteka nie jest sklepem, tylko placówką ochrony zdrowia obłożoną przepisami, których nie widać z zewnątrz. Poniżej trzy pułapki, na których wyłoży się każdy system projektowany „jak dla zwykłego retailu”.

Pułapka 1. Komunikacja z pacjentem może być reklamą

Na dziś art. 94a Prawa farmaceutycznego przewiduje szeroki zakaz reklamy aptek i ich działalności. Po wyroku TSUE rząd proceduje projekt UD291, który ma ten model zmienić. Sam projekt nie zmienia jednak obowiązującego prawa, dopóki nowe przepisy nie wejdą w życie. Do tego czasu program lojalnościowy, baner „promocja”, automatyczna wiadomość do pacjenta, czyli standard w każdej drogerii, w aptece wymaga kwalifikacji prawnej przed implementacją, nie po niej.

Dla projektanta systemu wniosek jest praktyczny: każda funkcja komunikacyjna i rabatowa przechodzi przez pytanie „czy to jeszcze informacja, czy już reklama”, system zapisuje podstawę decyzji, a reguły da się zmienić bez przebudowy produktu, bo prawo właśnie jest w ruchu.

Pułapka 2. Cena leku to nie liczba, tylko dane z datą ważności

W zwykłym sklepie cena jest polem w kartotece. W refundacji jest elementem reguły obowiązującej w określonym czasie: wykazy i warunki odpłatności zmieniają się cyklicznie na mocy obwieszczeń, a ten sam lek ma różne poziomy odpłatności zależnie od wskazania i uprawnień pacjenta. System musi wersjonować ceny, znać daty obowiązywania, źródło każdej wartości i mieć testy na przejście między wykazami. Agent bez tego kontekstu zaprojektuje pole „price” i pójdzie dalej, bo w 99% sklepów świata to wystarcza. Tu kończy się to sporem o pieniądze z płatnikiem.

Pułapka 3. Recepta nie jest zamówieniem

Wygląda podobnie: pozycje, ilości, wydanie towaru. Ale recepta ma termin ważności, może być zrealizowana częściowo, pacjent może mieć uprawnienia szczególne zmieniające odpłatność, a za realizacją idzie raportowanie do płatnika. Każdy z tych elementów ma przypadki brzegowe i każdy potrafi wygenerować spór o pieniądze. Kto koduje obsługę recepty jak koszyk w e-commerce, ten o różnicach dowie się z pisma, nie z dokumentacji.

Agent nie wie, że powinien się zatrzymać

Najtrudniejsze nie jest to, że model nie zna wszystkich przepisów. Najtrudniejsze jest to, że nie rozpoznaje momentu, w którym wiedzy mu brakuje. Wygeneruje kompletny, elegancki i pewny siebie projekt, w którym miny są rozmieszczone równomiernie.

Odpowiedzią jest warstwa wiedzy domenowej, którą maszyna musi respektować, zanim zacznie projektować: źródła, reguły, testy, daty obowiązywania, wyjątki i jawny rejestr luk. Właśnie temu służy macierz wymagań regulacyjnych z pierwszego artykułu tej serii: 361 reguł, 1083 scenariusze, 122 karty źródłowe. Agent, który dostaje takie ramy, przestaje być błyskotliwym stażystą z amnezją, a zaczyna być wykonawcą pracującym pod nadzorem.

Ale do zbudowania takich ram trzeba kogoś, kto te miny widział z bliska. Ja przez ponad dwadzieścia lat w farmacji na kilka nadepnąłem osobiście, prowadząc własną aptekę i pracując dla sieci. Ta wiedza nie leży w internecie w formie, z której model umie skorzystać. Leży w ludziach.