Ograniczenia projektu
Duża firma farmaceutyczna potrzebowała wewnętrznego produktu, który łączyłby kilka funkcji AI i analityki w jednej kontrolowanej przestrzeni. Wyzwanie nie polegało wyłącznie na dodaniu interfejsu konwersacyjnego do danych firmy. Platforma musiała pasować do istniejących zasad tożsamości, uprawnień, zarządzania danymi, przeglądu infrastruktury i utrzymania systemów.
Jednym z planowanych zastosowań był konwersacyjny dostęp do kontrolowanych danych analitycznych. Istniejące pulpity nadal nadawały się do znanych raportów. Pytania eksploracyjne mogły jednak wymagać przechodzenia między wieloma widokami, filtrami i definicjami biznesowymi. Interfejs języka naturalnego mógł skrócić tę ścieżkę tylko wtedy, gdy zachowywał znaczenie zatwierdzonych wskaźników i respektował uprawnienia użytkownika.
Ta sama platforma miała obsługiwać także inne, jasno ograniczone usługi AI. Oddzielna aplikacja dla każdej funkcji powielałaby mechanizmy tożsamości, projektów, promptów, informacji zwrotnej i monitorowania. Bezpośrednie połączenie ogólnego chatbota z tabelami hurtowni tworzyłoby inny problem. Wiarygodnie brzmiąca odpowiedź nie wskazywałaby, czy system użył właściwej definicji, zbioru danych, regionu i usługi.
Udokumentowany zakres projektu obejmował zatem cztery ograniczenia:
- Pytania biznesowe miały być interpretowane przez kontrolowane definicje, a nie nieograniczone surowe tabele.
- Samo zalogowanie nie mogło oznaczać dostępu do każdego zbioru danych ani każdej funkcji AI.
- Poszczególne usługi AI potrzebowały wyraźnych granic, aby można je było niezależnie monitorować i zmieniać.
- Operatorzy potrzebowali możliwości prześledzenia żądania przez interfejs, platformę i połączone z nią silniki.
Zakres platformy
Prace połączyły doświadczenie pracownika i wspólne funkcje platformowe w jednej architekturze. Przestrzeń obejmowała firmowe logowanie, role aplikacyjne, projekty, prompty wielokrotnego użytku, preferencje odpowiedzi, pamięć zarządzaną przez użytkownika, załączniki, informację zwrotną oraz dostęp do zatwierdzonych funkcji AI.
Analityka konwersacyjna była jednym z elementów projektu. Definicje semantyczne nadawały pojęciom biznesowym, wskaźnikom, wymiarom i połączeniom jawne znaczenie, zanim model wygenerował zapytanie. Pozwalało to oddzielić interpretację pytania od autoryzacji. Warstwa semantyczna opisywała sposób rozumienia pytania, a zabezpieczenia aplikacji i danych określały zakres dostępny dla konkretnego użytkownika.
Wyspecjalizowane funkcje AI oddzielono od wspólnej przestrzeni jako modułowe usługi. Rejestr i widok stanu silników miały umożliwiać operatorom sprawdzanie ich dostępności. Centralne zarządzanie promptami i konfiguracją ograniczało różnice między usługami, a zaplanowane kontrole wspierały odświeżanie danych i utrzymanie operacyjne.
Projekt obejmował również wspólne i prywatne przestrzenie pracy. Prompty działowe mogły wspierać powtarzalne zadania, natomiast osobiste prompty i projekty pozwalały pracownikom organizować własną pracę. Pamięć miała pozostać widoczna i edytowalna, zamiast tworzyć ukryty kontekst niedostępny dla użytkownika.
Uprawnienia przed wykonaniem modelu
Najważniejsza granica kontroli znajdowała się poza promptem. Instrukcja może wpływać na zachowanie modelu, ale nie może niezawodnie egzekwować firmowych uprawnień.
Ścieżkę żądania zaprojektowano tak, aby najpierw ustalała firmową tożsamość pracownika, jego rolę aplikacyjną, grupy oraz odpowiednie uprawnienia do danych. Następnie reguły polityk i zakresu ograniczały dozwoloną operację. W przypadku pytań analitycznych wybrana usługa interpretowała pytanie na podstawie zatwierdzonego modelu semantycznego. Zapytanie było wykonywane tylko w dozwolonym kontekście danych.
Taka struktura rozdzielała trzy decyzje:
- czy dana osoba może korzystać z platformy;
- którą funkcję może uruchomić;
- do jakich danych ta funkcja może uzyskać dostęp w jej imieniu.
To rozdzielenie jest ważne w organizacji, w której dostęp zależy od roli, funkcji, zbioru danych lub regionu. Daje też zespołom bezpieczeństwa i właścicielom danych wyraźne miejsce do przeglądu każdej reguły. Instrukcje dla modelu nie muszą wtedy zastępować mechanizmów kontroli dostępu.
Modułowe i kontrolowane działanie
Architektura oddzielała wspólną przestrzeń pracownika od usług wykonujących poszczególne zadania AI. Każda usługa mogła udostępniać stabilne API i być wdrażana niezależnie. Ograniczało to potrzebę wymiany głównej aplikacji przy zmianie jednej funkcji oraz zmniejszało operacyjny wpływ awarii pojedynczego silnika.
Udokumentowany projekt umieszczał platformę w chmurze z ograniczeniami sieciowymi i definiował infrastrukturę jako kod. Dzięki temu proponowane zmiany infrastruktury mogły być przeglądane, a środowiska odtwarzane na podstawie wersjonowanych definicji. Dane produktu, pamięć podręczna, przechowywanie plików i kontrolowane udostępnianie plików stanowiły oddzielne elementy platformy. Nie były zaszyte w pojedynczym silniku AI.
Identyfikowalność była częścią projektu usług. Logi, metryki, stan usług, ślady żądań i informacje zwrotne łączono z odpowiednią interakcją oraz silnikiem. Dawało to operatorom ścieżkę do diagnozowania błędów na granicach usług. Ułatwiało też przegląd działania systemu w porównaniu z pojedynczą, nieprzejrzystą wymianą między użytkownikiem i modelem.
Te mechanizmy wspierają pracę w regulowanym środowisku firmowym, ale same nie potwierdzają formalnej walidacji ani zgodności konkretnego zastosowania. Przeznaczenie systemu, właściwe przepisy, dowody walidacyjne i zatwierdzenie pozostają osobnymi decyzjami wyznaczonych osób w organizacji.
Co ustalono w ramach prac
Udokumentowanym rezultatem jest zintegrowana architektura platformy i zakres prac, a nie potwierdzona informacja o wdrożeniu w całej firmie. Projekt łączy kilka funkcji AI i analityki we wspólnym środowisku pracownika. Tożsamość, uprawnienia, kontrolowane definicje, modułowe usługi i nadzór operacyjny są w nim odpowiedzialnością platformy.
Dostępne materiały nie określają liczby aktywnych użytkowników ani regionów, metody oceny systemu produkcyjnego ani dostatecznie opisanego punktu odniesienia, próby, okresu i źródła dla wyniku liczbowego. Realizacja nie przedstawia więc twierdzeń o adopcji, dostępności, certyfikacji zgodności, produktywności ani zmierzonej oszczędności czasu.
Następny krok dla podobnego projektu
Dla zespołu z branży farmaceutycznej lub life sciences właściwym punktem wyjścia nie jest lista modeli. Najpierw trzeba opisać proces, użytkowników, granice danych, właścicieli decyzji oraz dowody wymagane przy odbiorze. Dopiero wtedy można ustalić, czy potrzebna jest warstwa semantyczna, platforma wewnętrzna, automatyzacja procesu, modułowa usługa AI czy brak nowego oprogramowania.
Zobacz również podejście do branży MedTech i life sciences, warstwy semantyczne oraz rozwiązanie do rozmowy z danymi.