Većina AI inicijativa ne propada zato što je model slab. Propadaju zato što se od modela traži da tumači poslovanje koje ne može vidjeti.

Chatbot može imati pristup dokumentima, tiketima i poljima baze podataka, a ipak davati odgovore koji zvuče uvjerljivo, ali promašuju bit. Ne zna koji su klijenti najvažniji, koje su iznimke skupe, kada je „dovršena” narudžba zapravo ugrožena ili zašto zahtjev za podršku treba eskalirati. Ta pravila često žive u kodu, timskim navikama i glavama iskusnih ljudi.

Stoga je izgradnja AI-ja koji doista razumije vaše poslovanje arhitektonski problem prije nego problem odabira modela. Cilj nije uliti svaki artefakt tvrtke u upit. Cilj je poslovno znanje učiniti eksplicitnim, pouzdanim, dostupnim i upravljivim.

Počnite s odlukama, a ne podacima

„Koristite AI na našim podacima” preširoko je da bi usmjerilo koristan tehnički dizajn. Umjesto toga počnite od odluke koju proizvod ili tim treba donositi bolje.

Na primjer, tim za operacije usluga možda treba pomoć pri odlučivanju je li dolazni problem rutinski zahtjev, vjerojatan prekid rada ili problem koji ugrožava ugovornu obvezu. To je složeniji problem od „sažmi tikete podrške”. Ima korisnike, posljedice, izvorne sustave, pragove pouzdanosti i vlasnika.

Dobro definiran slučaj upotrebe pojašnjava što sustav mora razumjeti:

• Koje su činjenice mjerodavne, poput statusa računa, razine usluge i trenutačnih incidenata.
• Koje poslovne koncepte treba tumačiti, poput hitnosti, rizika obnove ili spremnosti za ispunjenje narudžbe.
• Koje radnje AI smije preporučiti, izraditi nacrt, izvršiti ili nikada ne smije izvršiti.
• Kada osoba mora pregledati rezultat.

Ovo uokvirivanje štiti timove od izgradnje impresivnih demonstracija koje ne mogu preživjeti susret sa stvarnim radom u produkciji. Koristan AI sustav trebao bi poboljšati stvarni radni proces, a ne samo stvarati tečan tekst o njemu.

Učinite domenu vidljivom u svom softveru

AI ne može pouzdano zaključiti operativni model tvrtke iz zbirke tablica nazvanih orders, events i status_code. Ne mogu ni novi inženjeri, voditelji proizvoda ni budući održavatelji. Dvosmislen kod skup je mnogo prije dolaska AI značajke.

Koristite nazive i granice koji odražavaju poslovanje. Autorizacija plaćanja nije isto što i naplata plaćanja. Pauziranje pretplate nije otkazivanje. Oznaka za pošiljku nije isporučena narudžba. Te bi se razlike trebale vidjeti u tipovima, uslugama, događajima i testovima.

type DeliveryStatus =
  | "planned"
  | "dispatched"
  | "delivered"
  | "delivery_failed";

function canOfferReplacement(order: Order): boolean {
  return order.deliveryStatus === "delivery_failed"
    && order.replacementEligibility.isActive;
}

Primjer je namjerno običan. Njegova je vrijednost u tome što politiku pretvara u vidljivu tvrdnju koju je moguće testirati. Kada su politike skrivene u SQL upitima, uvjetima korisničkog sučelja i neformalnom znanju tima, AI sloj reproducirat će tu fragmentaciju.

Dizajn vođen domenom ne mora značiti razrađen program radionica i dijagrama. Znači dovoljno ozbiljno shvatiti poslovni jezik da softver očuva njegovo značenje. Izradite zajednički glosar važnih pojmova. Odlučite gdje je pojedini koncept u vlasništvu. Izbjegavajte dopustiti da pet usluga različito izračunava „vrijednost klijenta” zato što je svakom timu brzo trebao odgovor.

Izgradite pouzdane putove do znanja

AI značajci treba više od pristupa informacijama; treba joj način procjene kojim informacijama vjerovati. Svaki izvor tretirajte kao integraciju proizvoda s definiranim ugovorom.

Za svaki izvor odredite njegova vlasnika, očekivanje svježine podataka, pravila pristupa i značenje. Bilješka u CRM-u može pružiti koristan kontekst, ali ne bi trebala nadjačati zapis sustava naplate o blokadi računa. Dokument s pravilima može objasniti proces iznimke, ali odobrena usluga radnog procesa trebala bi ostati autoritet za to je li iznimka trenutačno dopuštena.

Odvojite kontekst od autoriteta

Praktičan obrazac jest razlikovati dohvaćeni kontekst od provjerenih poslovnih činjenica. Dohvaćeni kontekst pomaže modelu objasniti, usporediti i izraditi nacrt. Provjerene činjenice dolaze iz kontroliranih aplikacijskih sučelja ili modela za čitanje i pokreću odluke.

Zamislite AI asistenta koji priprema odgovor na zakašnjelu pošiljku. Može dohvatiti prethodnu korespondenciju s klijentom i relevantna pravila usluge. No prije nego što obeća povrat novca ili zamjenu, aplikacija bi trebala dohvatiti stanje narudžbe uživo i procijeniti relevantno poslovno pravilo.

Time se model zadržava u ulozi koju dobro obavlja: tumačenju nestrukturiranih informacija i jasnoj komunikaciji. Provedba pravila ostaje tamo gdje pripada: u determinističkom kodu s mogućnošću revizije.

Dizajnirajte za neizvjesnost i predaju slučajeva

Poslovna stvarnost sadržava nepotpune podatke, proturječne upute i iznimke. Sustav koji uvijek zvuči sigurno opasan je upravo zato što može biti uvjerljiv.

Učinite neizvjesnost ishodom prvog reda. AI bi trebao moći reći da mu nedostaje potrebna činjenica, navesti izvor koji je upotrijebio i usmjeriti slučaj pravoj osobi. Dizajn proizvoda ovdje je jednako važan kao i oblikovanje upita. Oznaka pouzdanosti bez korisne sljedeće radnje samo prenosi tjeskobu na korisnika.

• Zahtijevajte potvrdu prije radnji s posljedicama, poput izdavanja kredita ili promjene pristupa računu.
• Prikažite poslovne činjenice korištene za donošenje preporuke.
• Osigurajte put eskalacije s dovoljno konteksta da pregledavatelj ne počinje od nule.
• Zabilježite predložene radnje, odobrenja, konačne ishode i naknadne ispravke.

Ta povratna sprega ključna je. Ako pregledavatelji opetovano ispravljaju AI preporuku, odgovor može biti bolja uputa, izvor koji nedostaje, nejasna politika ili nedostatak u temeljnom radnom procesu. Nemojte pretpostaviti da se svaki problem rješava promjenom modela.

Dodijelite sustavu jasno vlasništvo

AI značajke obuhvaćaju proizvod, podatke, sigurnost, operacije i inženjerstvo. Bez eksplicitnog vlasništva često nakon lansiranja postaju ničija trajna odgovornost.

Zdrav tim dodjeljuje vlasnike za radni proces, izvorne podatke, poslovna pravila, korisničko iskustvo i operativnu kvalitetu. Za to nije potreban velik odbor. Potrebno je znati tko može odgovoriti na konkretna pitanja: Tko odobrava novu radnju? Tko rješava proturječnu politiku? Tko odlučuje je li sustav dovoljno siguran za širu primjenu?

Za udaljene timove pisani zapisi odluka posebno su vrijedni. Zabilježite namjeravano ponašanje, poznata ograničenja, hijerarhiju izvora i pristup vraćanja na prethodno stanje jezikom koji mogu koristiti i proizvodni i inženjerski timovi. To smanjuje ovisnost o sastancima i omogućuje pregled odluka kada ljudi rade u različitim vremenskim zonama.

Isporučujte usko, mjerite temeljito

Najodrživiji put jest uzak radni proces sa smislenom granicom. Počnite s izradom nacrta internih sažetaka, klasifikacijom zahtjeva ili preporučivanjem sljedećeg koraka obučenom operateru. Promatrajte gdje ne uspijeva. Poboljšajte model domene i integracije. Zatim proširite ovlasti samo kada to dokazi podupiru.

Mjerite više od kvalitete izlaza modela. Pratite prihvaćaju li korisnici preporuke, koliko ih često ispravljaju, kreću li se slučajevi brže te grupiraju li se obrasci pogrešaka oko određenog segmenta klijenata, politike ili izvornog sustava. Važan je i kvalitativni pregled: mali broj štetnih nesporazuma može nadmašiti mnoge uglađene odgovore.

Ovaj pristup nije sporiji od lova na potpuno autonomnog asistenta. Tako timovi izbjegavaju gomilanje nove vrste operativnog duga: neprozirnog ponašanja vezanog uz loše definirana poslovna pravila.

Učinite razumijevanje proizvodom

Trajna prednost AI proizvoda rijetko je samo u pametnom upitu. Ona je u kvaliteti poslovnog razumijevanja ugrađenog oko modela: jasnim konceptima, pouzdanim podacima, eksplicitnim pravilima, sigurnim predajama slučajeva i odgovornim timovima.

Arhitekturu svog koda oblikujte tako da sposoban kolega čitajući ga može razumjeti kako vaše poslovanje funkcionira. Zatim AI-ju dajte pažljivo upravljan pristup toj istoj jasnoći. Kada je model utemeljen na stvarnim odlukama, a ne na raspršenim artefaktima, prestaje biti generički asistent i postaje koristan dio načina na koji poslovanje funkcionira.