Sapan Pandya, starszy inżynier oprogramowania i starszy członek IEEE – seria wywiadów

Sapan Pandya jest starszym inżynierem oprogramowania i starszym członkiem IEEE z New Jersey. Ma ponad dziesięć lat doświadczenia w projektowaniu odpornych, rozproszonych systemów transakcyjnych. Zajmuje się integralnością transakcji, integracją oprogramowania z urządzeniami fizycznymi, diagnozowaniem problemów w środowisku produkcyjnym oraz weryfikacją wdrożeń w środowiskach podlegających regulacjom. Uzyskał tytuł magistra informatyki w Stevens Institute of Technology, a także uczestniczy w recenzowaniu prac naukowych i badaniach technicznych.

Badania Pandyi dotyczą cyberbezpieczeństwa kiosków, sztucznej inteligencji na brzegu sieci oraz inżynierii niezawodności wspomaganej przez AI, a jego doświadczenie produkcyjne wpływa na to, jak koncentruje się na dowodach, wynikach transakcji i odpowiedzialności operacyjnej. W tym wywiadzie omawia idempotencję, sprzeczne zapisy transakcji, niepewność w systemach odzyskiwania danych oraz zabezpieczenia niezbędne, zanim agenci AI będą mogli działać w infrastrukturze o kluczowym znaczeniu dla realizacji misji. Odróżnia praktyczne doświadczenie inżynierskie od badań prowadzonych na podstawie analizy literatury oraz testów kontrolowanych lub syntetycznych.

W swojej karierze koncentrował się Pan na niezawodności oprogramowania i rozproszonych systemach transakcyjnych. Jak to doświadczenie wpłynęło na Pana rozumienie niezawodności i jakie wyzwania ukształtowały Pana podejście do wykorzystania AI w zarządzaniu złożonymi systemami?

Zamiast pytać, czy dany komponent działa, coraz częściej zastanawiam się, czy transakcja klienta została zakończona i czy można ją rozliczyć.

Na początku kariery skupiałem się przede wszystkim na działaniu aplikacji: sprawdzaniu poprawności danych wejściowych, obsłudze odpowiedzi i upewnianiu się, że interfejs realizuje założony przebieg pracy. Wraz z rozszerzaniem zakresu moich obowiązków o integrację systemów, diagnozowanie problemów w środowisku produkcyjnym i weryfikację wdrożeń musiałem patrzeć szerzej niż tylko na poszczególne komponenty.

Jedna usługa może zakończyć swoje działanie, podczas gdy inna nadal czeka na potwierdzenie. Oprogramowanie może odnotować pomyślnie wykonaną operację, choć urządzenie fizyczne nie dostarczy oczekiwanego rezultatu. Sam fakt, że każdy komponent przeszedł testy, nie dowodzi jeszcze, że cała interakcja będzie przebiegać prawidłowo.

To doświadczenie sprawiło, że szczególnie interesują mnie granice między systemami. Co wie każdy komponent? Co zakłada? Co się dzieje, gdy te założenia przestają być prawdziwe?

Wpływa ono również na moje podejście do AI. Pomoc inżynierom w gromadzeniu dowodów, rozpoznawaniu wzorców i szybszym badaniu awarii może przynieść realne korzyści. Wyjaśnienie tego, co prawdopodobnie się wydarzyło, różni się jednak od potwierdzonego ustalenia, co faktycznie zaszło.

Chcę, by AI ograniczała nakład pracy potrzebny do zbadania problemu, nie obniżając przy tym standardu dowodów wymaganych do jego rozwiązania.

Podkreślał Pan, że poprawny technicznie kod nie zawsze gwarantuje prawidłowy wynik transakcji. Czy może Pan podać konkretny przykład transakcji, która wydaje się nieudana z powodu przekroczenia limitu czasu, choć w rzeczywistości została zrealizowana? Co może pójść nie tak, gdy system automatycznie ponawia operację, i jak inżynierowie powinni zapobiegać podwójnym transakcjom?

Rozważmy hipotetyczną płatność w wysokości 50 USD. Aplikacja wysyła żądanie, usługa płatnicza pomyślnie je rejestruje, ale odpowiedź ginie, zanim dotrze do aplikacji.

Klient widzi komunikat o przekroczeniu limitu czasu, mimo że płatność została już zrealizowana. Jeśli aplikacja wyśle nowe żądanie płatności, może ponownie obciążyć klienta.

Przekroczenie limitu czasu oznacza, że odpowiedź nie nadeszła na czas. Nie informuje natomiast, czy właściwa transakcja zakończyła się powodzeniem.

Jednym z powszechnych zabezpieczeń jest idempotencja: możliwość ponowienia tego samego logicznego żądania bez wywoływania kolejnego skutku finansowego. Aplikacja zachowuje identyfikator operacji przy kolejnych próbach, a usługa odbierająca rozpoznaje żądanie jako pierwotne, a nie jako nowy zakup.

Nie chodzi tylko o dołączenie identyfikatora. Usługa musi egzekwować jego unikatowość i zachowywać wystarczająco dużo informacji, by odróżnić zakończoną operację od tej, która nadal trwa. Identyfikator nie zabezpieczy działania w dalszej części systemu, jeśli dany komponent go zignoruje.

Gdy wynik pozostaje niepewny, procedura odzyskiwania powinna sprawdzić istniejącą transakcję i uzgodnić odpowiednie zapisy, zamiast od razu tworzyć transakcję zastępczą.

Ograniczyłbym również liczbę ponowień i określił, co zrobić, gdy automatyczne odzyskiwanie nie pozwala ustalić wyniku. Klient potrzebuje jasnej informacji, że transakcja oczekuje na realizację, oraz możliwości jej wyjaśnienia — nie kolejnych obciążeń ani ekranu, na którym przetwarzanie trwa bez końca.

W systemach rozproszonych baza danych, usługa zaplecza i fizyczny kiosk mogą przekazywać sprzeczne informacje o tej samej transakcji. Czy spotkał się Pan z taką niespójnością w środowisku produkcyjnym i jak ją zbadano oraz rozwiązano? Jaką rolę — jeśli w ogóle — mogłaby odegrać AI w uzgadnianiu tych sprzecznych zapisów?

Badanie niespójności stanów transakcji należało do moich obowiązków w środowisku produkcyjnym. Aby wyjaśnić sposób rozumowania bez omawiania incydentu z miejsca pracy, posłużę się hipotetycznym przykładem.

Weźmy pod uwagę typową kasę samoobsługową. Usługa płatnicza odnotowuje udany zakup, drukarka informuje o przyjęciu zadania wydrukowania paragonu, a następnie na ekranie pojawia się błąd. Te obserwacje mogą dotyczyć różnych etapów interakcji, a nie dowodzić, że cała transakcja się nie powiodła.

Najpierw odtworzyłbym przebieg zdarzeń, korzystając z identyfikatora transakcji oraz odpowiednich zapisów usług i urządzeń. Następnie ustaliłbym, co potwierdza każda z obserwacji. To, że drukarka przyjęła zadanie, nie musi oznaczać, że paragon trafił do klienta. Otrzymanie żądania nie musi oznaczać, że jego skutek finansowy został zaksięgowany.

Sposób rozwiązania problemu zależy od tego, który etap zawiódł. Ponowienie całej transakcji może być niewłaściwe, jeśli trzeba zająć się wyłącznie etapem wyjściowym. Jeśli dostępne dowody nie pozwalają ustalić, co się stało, operacja, której dotyczy problem, powinna pozostać pod kontrolą do czasu przeprowadzenia analizy.

Trwałe rozwiązanie musi również wyjaśniać, dlaczego ta niespójność mogła wystąpić, a nie tylko naprawiać pojedynczy zapis.

AI może pomóc powiązać zdarzenia i wskazać brakujące informacje. Poprosiłbym je o przedstawienie konkurencyjnych wyjaśnień oraz dowodów przemawiających za każdym z nich. Powinno ono zawężać zakres analizy, a nie rozstrzygać sprzeczności w zapisach przez wybór wyjaśnienia, które brzmi najbardziej przekonująco.

W miarę jak agenci AI przechodzą od diagnozowania incydentów produkcyjnych do zalecania lub wykonywania działań naprawczych, jakie zabezpieczenia powinny zostać wdrożone, zanim system AI będzie mógł ponawiać, odwracać lub modyfikować transakcje? W jaki sposób deterministyczne mechanizmy, takie jak klucze idempotencji, dzienniki transakcji i mechanizmy uzgadniania danych, mogą zapobiec powodowaniu przez AI kolejnych awarii?

Oddzieliłbym zaproponowanie działania od jego zatwierdzenia i wykonania.

Agent AI może zalecić ponowienie operacji, ale osobny mechanizm kontrolny powinien ustalić, czy jest ono dozwolone. Powinien sprawdzić aktualny stan transakcji, tożsamość operacji, uprawnienia agenta oraz warunki, w których takie działanie jest bezpieczne.

Kontrola musi być przeprowadzana w chwili wykonywania działania, a nie tylko wtedy, gdy model po raz pierwszy analizuje incydent. W międzyczasie inny proces mógł już zakończyć transakcję.

Zakres narzędzi dostępnych agentowi również powinien być ograniczony. Uprawnienie do pobrania informacji o stanie transakcji różni się od uprawnienia do cofnięcia płatności lub modyfikowania dokumentacji finansowej. Agent nie powinien móc samodzielnie rozszerzać swoich uprawnień tylko dlatego, że preferowane przez niego rozwiązanie wymaga większego dostępu.

Idempotencja ogranicza skutki duplikacji. Dzienniki zachowują historię potrzebną do analizy. Uzgadnianie danych pozwala sprawdzić zgodność odpowiednich zapisów. Żaden z tych mechanizmów sam w sobie nie przesądza, czy proponowane działanie jest właściwe.

Zapisywałbym również wykorzystane dowody, zalecenie, decyzję o zatwierdzeniu oraz rzeczywisty wynik. Dzięki temu można później przeanalizować podjętą interwencję.

Te mechanizmy kontrolne powinny być egzekwowane przez testowalne oprogramowanie działające poza modelem. Instrukcje nakazujące agentowi ostrożność są przydatnymi wskazówkami, ale nie zastępują mechanizmu autoryzacji.

Rozważmy sytuację, w której system monitorujący oparty na AI wykrywa pozorną awarię transakcji i zaleca jej automatyczne cofnięcie. Jeśli transakcja faktycznie się powiodła, ale potwierdzenie dotarło z opóźnieniem, taka interwencja może stworzyć nowy problem. Jak zespoły inżynierskie powinny projektować systemy naprawcze oparte na AI, aby rozpoznawały niepewność i unikały działań korygujących podejmowanych na podstawie niepełnych informacji?

System musi mieć rzeczywisty stan „wynik nieznany”. W przeciwnym razie prawdopodobnie uzna brak informacji za dowód, że transakcja się nie powiodła.

Opóźnione potwierdzenie jest powodem do przeprowadzenia analizy, a nie automatycznie do cofnięcia transakcji. Cofnięcie to kolejna operacja finansowa, która ma własne konsekwencje. Wymaga niezależnego uzasadnienia oraz odpowiedniego zatwierdzenia.

Podzieliłbym reakcję na dwie ścieżki. Ścieżka analityczna może obejmować pobranie informacji o stanie transakcji, zebranie brakujących zdarzeń, porównanie zapisów i powiadomienie odpowiedzialnego zespołu. Ścieżka działań finansowych pozostaje zablokowana do czasu spełnienia wymaganych warunków.

Dzięki temu wynik pewności modelu nie zastępuje dowodów dotyczących transakcji. Model może być bardzo pewny wyjaśnienia opartego na niepełnych informacjach.

Należy również określić moment eskalacji. Bezterminowe utrzymywanie transakcji w stanie oczekiwania nie jest dla klienta satysfakcjonującym rozwiązaniem. Ktoś powinien odpowiadać za nierozstrzygniętą sprawę i dysponować wystarczającym kontekstem, by ustalić kolejny bezpieczny krok.

Proces naprawczy powinien zatem umieć powiedzieć zarówno: „Nie mogę jeszcze uzasadnić zmiany tej transakcji”, jak i: „Oto, co trzeba zrobić, aby rozwiązać problem”.

Rozpoznawanie niepewności jest przydatne tylko wtedy, gdy system dysponuje praktycznym sposobem radzenia sobie z nią.

Jednym z najważniejszych pytań dotyczących autonomicznej AI jest to, kiedy ludzka akceptacja nadal pozostaje niezbędna. Które działania naprawcze w środowisku produkcyjnym AI powinna, Twoim zdaniem, móc wykonywać samodzielnie, a które powinny zawsze wymagać zgody człowieka? Jak organizacje powinny wyznaczać te granice, gdy stawką są transakcje finansowe, zgodność z przepisami lub zaufanie klientów?

Wyznaczałbym tę granicę na podstawie konsekwencji błędu, a nie tego, czy dane działanie określa się jako „AI”.

Rozsądnym punktem wyjścia jest analiza wyłącznie do odczytu, pod warunkiem że agent ma dostęp tylko do uprawnionych informacji. Może gromadzić dane diagnostyczne, grupować powiązane alerty i przygotowywać podsumowanie incydentu, nie mogąc przy tym zmieniać samej transakcji.

Niektóre z góry określone procedury naprawcze również mogą nadawać się do automatyzacji, jeśli ich warunki są niezależnie weryfikowane, a ich skutki ograniczone.

Wymagałbym zgody człowieka, gdy proponowana interwencja wykracza poza zatwierdzoną procedurę, gdy dane są sprzeczne, a wynik finansowy pozostaje nierozstrzygnięty, lub gdy działanie zmieniałoby zabezpieczenia albo uprawnienia samego agenta. Agent nie powinien sam udzielać sobie zgody na takie decyzje.

Nie oznacza to, że każda rutynowa operacja finansowa wymaga zatwierdzenia przez człowieka. Przetwarzanie oparte na ustalonych regułach różni się od pozwalania modelowi na wymyślanie korekty w trakcie incydentu.

Weryfikacja przez człowieka musi mieć również rzeczywiste znaczenie. Ekran akceptacji powinien przedstawiać dowody, nierozstrzygnięte wątpliwości, przewidywane skutki i dostępne alternatywy. Prośba o zatwierdzenie przekonująco brzmiącego akapitu bez takiego kontekstu niewiele zwiększa bezpieczeństwo.

Granice te należy uzgodnić przed wdrożeniem. Awaria to niewłaściwy moment na podejmowanie decyzji o tym, jaki zakres uprawnień powinien mieć system automatyczny.

Masz duże doświadczenie w pracy nad odpornymi na awarie systemami zaplecza, narzędziami do monitorowania i obserwowalności oraz integracjami między usługami programowymi a sprzętem fizycznym. Jakich danych telemetrycznych i dowodów z systemu produkcyjnego potrzebowałby agent AI, aby wiarygodnie diagnozować incydenty? Jak zespoły inżynieryjne mogą odróżniać przydatne rekomendacje wygenerowane przez AI od wiarygodnie brzmiących, lecz błędnych wniosków, które mogłyby pogłębić awarię?

Zacząłbym od dowodów, które łączą działania klienta w obrębie zaangażowanych systemów: identyfikatorów transakcji, zdarzeń usług, trwałych zmian stanu, odpowiedzi urządzeń i błędów komunikacji.

Istotne są również wersje oprogramowania i zmiany konfiguracji. Awaria, która zaczyna się po wydaniu nowej wersji, daje osobie prowadzącej analizę przydatny trop, ale sama zbieżność w czasie nie dowodzi związku przyczynowego.

Agent musi też rozumieć ograniczenia dostępnych dowodów. Dzienniki mogą być niekompletne, dane mogą docierać z opóźnieniem, a zegary mogą wskazywać różne godziny. Brak potwierdzenia nie jest równoznaczny z dowodem, że żadna operacja nie została wykonana.

Przydatna diagnoza powinna oddzielać obserwacje od interpretacji. „Klient zarejestrował przekroczenie limitu czasu” to obserwacja. „Zaplecze było niedostępne” to wyjaśnienie wymagające dodatkowego potwierdzenia.

Oczekiwałbym, że rekomendacja wskaże dane, na których się opiera, wyjaśni, co pozostaje niewiadome, i określi, jaka dodatkowa kontrola potwierdzi lub obali przedstawiony wniosek.

Następnie inżynierowie powinni weryfikować istotne rekomendacje na podstawie oryginalnych danych, zamiast polegać wyłącznie na podsumowaniu agenta. Jest to szczególnie ważne, gdy podsumowanie kondensuje długą lub sprzeczną historię zdarzeń.

Stosowałbym prostą zasadę: czy inny inżynier może prześledzić dowody i dojść do uzasadnionego wniosku? Jeśli wyjaśnienie nie wytrzymuje takiej weryfikacji, nie jest gotowe, by stanowić podstawę zmian w środowisku produkcyjnym.

W swoich opublikowanych badaniach nad odpornością kiosków loteryjnych i bukmacherskich na oprogramowanie ransomware oceniałeś wspomagane przez AI ramy bezpieczeństwa w środowisku syntetycznym symulującym działanie 500 kiosków. Jakie były najważniejsze ustalenia i jakie ograniczenia powinni mieć na uwadze czytelnicy, interpretując te wyniki? Jakie dodatkowe testy byłyby konieczne, zanim zaproponowaną architekturę można by zastosować w działającym środowisku produkcyjnym?

Chciałem zbadać odporność wykraczającą poza samo wykrywanie: to, jak środowisko terminali może ograniczyć atak, rozpoznać go i odzyskać sprawność, zachowując jednocześnie dowody pozwalające ustalić, co się wydarzyło.

Powstałe w ten sposób Resilient Security Framework łączyło środki zapobiegawcze, wykrywanie anomalii wspomagane przez AI oraz określone mechanizmy reagowania i odzyskiwania sprawności. Komponent AI służył do wykrywania podejrzanych zachowań. Nie był to eksperyment polegający na umożliwieniu agentowi opartemu na modelu językowym samodzielnego modyfikowania transakcji finansowych.

W ocenie wykorzystano środowisko syntetyczne odwzorowujące 500 kiosków w trakcie 72-godzinnej symulacji. Zastosowano w nim symulacje zachowań charakterystycznych dla ataków ransomware, a nie wdrożenie na 500 fizycznych terminalach.

W porównaniu z zastosowanym w badaniu punktem odniesienia, w którym używano wyłącznie oprogramowania antywirusowego, średni czas wykrycia spadł z 52 do 31 minut, a średni czas odzyskiwania sprawności — ze 120 do 56 minut.

Są to wyniki uzyskane dla połączonych ram działania w warunkach eksperymentalnych. Nie należy przypisywać ich wyłącznie sztucznej inteligencji ani traktować jako gwarancji wydajności w środowisku produkcyjnym. Jednym z istotnych wniosków było to, że samo wcześniejsze wykrywanie nie przyniosło równie dużej poprawy w zakresie odzyskiwania sprawności. Znaczenie miały również sposób ograniczania skutków ataku i projekt procesu odzyskiwania.

Ograniczenia badania są istotne. Symulowane obciążenia, warunki sieciowe, zachowania podczas ataków i zabezpieczenia bazowe nie odzwierciedlają wszystkich środowisk operacyjnych. Różne urządzenia i aplikacje wymagałyby odrębnej walidacji.

Przed wdrożeniem produkcyjnym chciałbym przeprowadzić testy na reprezentatywnym sprzęcie, niezależną ocenę bezpieczeństwa, dłuższe ewaluacje oraz dokładne pomiary liczby fałszywych alarmów i narzutu przetwarzania.

Przetestowałbym również proces odzyskiwania pod kątem zgodności z prawidłowo realizowanymi transakcjami. Przywrócenie działającego obrazu oprogramowania nie wystarczy, jeśli w tym procesie utracone zostaną informacje potrzebne do rozliczenia zrealizowanych transakcji.

Badanie stanowi podstawę do dalszych testów. Wykazanie, że rozwiązanie działa bezpiecznie w rzeczywistym środowisku operacyjnym, to osobny etap.

Łączy Pan wieloletnie doświadczenie w inżynierii systemów produkcyjnych z badaniami akademickimi nad niezawodnością oprogramowania i bezpieczeństwem opartym na sztucznej inteligencji. Czy może Pan rozróżnić mechanizmy niezawodności, które osobiście wdrażał lub obsługiwał w działających systemach produkcyjnych, od rozwiązań analizowanych w ramach badań lub testów symulacyjnych? Które możliwości odzyskiwania sprawności z wykorzystaniem sztucznej inteligencji uważa Pan dziś za praktyczne, a które pozostają w dużej mierze eksperymentalne?

Moja praca przy systemach produkcyjnych obejmowała tworzenie i integrację oprogramowania, walidację transakcji, rozwiązywanie problemów, testowanie oraz walidację wydań.

Opublikowane przeze mnie badania stanowią odrębną część mojej pracy, a każde z nich należy rozpatrywać z uwzględnieniem opisanych metod i ograniczeń.

Artykuł o ransomware ocenia proponowane ramy bezpieczeństwa w syntetycznym środowisku testowym. Mój artykuł o brzegowej sztucznej inteligencji to analiza literatury poświęconej inteligencji działającej na urządzeniu i jej możliwym zastosowaniom w terminalach transakcyjnych. Mój artykuł w IEEE FeedForward analizuje architekturę niezawodności wspomaganą sztuczną inteligencją za pomocą kontrolowanej symulacji obejmującej monitorowanie, eskalację i działanie w razie awarii.

Żadnej z tych publikacji nie należy traktować jako dowodu na to, że wdrożyłem autonomicznego agenta AI uprawnionego do wykonywania operacji na rzeczywistych transakcjach finansowych.

W praktycznych zastosowaniach priorytetowo traktowałbym rozwiązania wspierające pracę inżynierów, których działanie można zweryfikować: podsumowania incydentów powiązane z danymi źródłowymi, korelacje między alertami oraz sugerowane testy diagnostyczne. Ich przydatność nadal trzeba mierzyć w środowisku, w którym będą działać.

Trudniejszym problemem jest odzyskiwanie sprawności w nieprzewidzianych sytuacjach, gdy model samodzielnie wybiera i wprowadza zmiany w okolicznościach, których wcześniej nie przewidziano. Wymaga to znacznie mocniejszych dowodów skuteczności niż użyteczna sugestia diagnostyczna.

Postrzegam moje doświadczenie w pracy z systemami produkcyjnymi i badania jako uzupełniające się obszary: pierwsze pozwala określić problemy operacyjne, które znam, a drugie służy badaniu rozwiązań, które muszą jeszcze potwierdzić swoją wartość w procesie walidacji.

W perspektywie rozwoju, w miarę jak agenci AI będą coraz lepiej wykrywać anomalie, diagnozować awarie i koordynować przywracanie sprawności w systemach rozproszonych, jak wyobraża Pan sobie ewolucję relacji między systemami autonomicznymi a inżynierami? Jakie zabezpieczenia techniczne, dowody potwierdzające skuteczność działania oraz mechanizmy rozliczalności byłyby konieczne, zanim organizacje mogłyby z pełnym przekonaniem przyznać sztucznej inteligencji większe uprawnienia w zakresie krytycznej infrastruktury produkcyjnej?

Spodziewam się, że sztuczna inteligencja będzie przejmować coraz więcej zadań związanych z gromadzeniem informacji o incydencie. Zamiast poświęcać tak dużo czasu na ręczne zbieranie danych, inżynierowie mogliby od razu otrzymywać przydatną oś czasu, listę dotkniętych komponentów, konkurencyjne wyjaśnienia oraz wskazanie brakujących dowodów.

Dzięki temu ludzie mieliby więcej czasu na podejmowanie decyzji wymagających zrozumienia zobowiązań systemu i konsekwencji wprowadzanych zmian.

Rozszerzałbym uprawnienia do wykonywania działań stopniowo. Agent mógłby początkowo działać w trybie obserwacyjnym, przedstawiając rekomendacje bez ich realizowania. Zespoły mogłyby porównywać te rekomendacje z wynikami zweryfikowanymi przez ludzi oraz sprawdzać, jak agent zachowuje się w sytuacjach, gdy informacje są niepełne, sprzeczne lub nieaktualne.

Ewaluacja powinna uwzględniać błędne interwencje, przeoczone problemy, nieuzasadnioną eskalację oraz odzyskiwanie sprawności po błędach samego agenta. Szybka rekomendacja nie jest wartościowa, jeśli prowadzi zespół reagowania w niewłaściwym kierunku.

Przyznanie większych uprawnień powinno być również uzależnione od spełnienia określonych warunków. Aktualizacja modelu lub poważna zmiana systemu mogą sprawić, że wcześniejsze testy przestaną być miarodajne. Zespoły muszą mieć możliwość ograniczenia lub odebrania agentowi uprawnień, gdy jego działanie przestaje spełniać wymagane standardy.

Wraz z rozwojem automatyzacji odpowiedzialność ludzi nie znika. Ktoś musi odpowiadać za zasady działania, wymagane dowody uzasadniające zmianę oraz procedurę badania awarii.

Wyobrażam sobie, że inżynierowie będą poświęcać mniej czasu na gromadzenie informacji, a więcej na określanie, testowanie i utrzymywanie warunków, które uzasadniają podejmowanie działań automatycznych.

Dziękujemy za świetny wywiad. Czytelnicy, którzy chcą śledzić jego prace nad niezawodnością transakcji rozproszonych i odpowiedzialnym odzyskiwaniem wspomaganym przez AI, mogą nawiązać kontakt z Sapan Pandya.