AI ne uči vaše poslovanje samo zato što proizvodu dodate okvir za razgovor. Uči kada softver oko njega poslovne koncepte čini vidljivima, pouzdanima i sigurnima za upotrebu.

Ta je razlika važna. Sposoban model može sažeti zahtjev za podršku, izraditi prijedlog ili objasniti izvješće. No ako je status kupca kodiran u raštrkanim tablicama, pravila određivanja cijena nalaze se u netestiranoj logici proračunskih tablica, a ključne se odluke donose samo u privatnim porukama, model nema pouzdanu poslovnu stvarnost na kojoj može raditi.

Dobra arhitektura pretvara operativno znanje u nešto što AI sustav može dohvatiti, nad čime može zaključivati i na temelju čega može djelovati unutar jasnih granica. Dobit nisu samo pametniji promptovi. To je softver koji može podržati korisne agente, pouzdanu automatizaciju i brže ljudske odluke.

Počnite s poslovnim konceptima, a ne značajkama modela

Timovi često počinju s popisom AI mogućnosti: pretraživanje, sažimanje, klasifikacija ili agent koji može poduzimati radnje. Snažnije polazište jest rječnik poslovanja.

Što je račun? Kada narudžba ispunjava uvjete za povrat novca? Koja polja definiraju kvalificiranog potencijalnog kupca? Tko smije odobriti iznimku? Što znači „dostupna zaliha” kada su artikli rezervirani, u prijevozu ili oštećeni?

Ta pitanja zvuče uobičajeno, ali otkrivaju ugovore koji su AI sustavu potrebni. Ako ljudi ne mogu dati dosljedan odgovor, model ga ne može sigurno zaključiti.

Važne koncepte izričito predstavite u aplikaciji i API-jima. Dajte im stabilna imena, tipizirana polja, vlasništvo, stanja životnog ciklusa i dokumentirana pravila. Izbjegavajte prisiljavati nizvodne korisnike da rekonstruiraju značenje iz slobodnih nizova, oznaka korisničkog sučelja ili slučajnih konvencija baze podataka.

Na primjer, narudžba ne bi trebala postati „spremna za povrat novca” zato što agent uoči određenu bilješku u zahtjevu. Aplikacija bi trebala izložiti namjernu procjenu pravila, kao što je getRefundEligibility(orderId), s odgovorom koji uključuje i odluku i njezin razlog.

Učinite znanje dohvatljivim uz kontekst i ovlasti

Dohvaćanje se često opisuje kao problem pretraživanja dokumenata. U praksi je to problem oblikovanja znanja. Koristan odgovor treba više od relevantnog teksta: treba ispravnu verziju, primjenjiv opseg i način utvrđivanja je li izvor mjerodavan.

Dokument s pravilima može se primjenjivati samo na određenu regiju, razinu proizvoda ili datum ugovora. Operativni priručnik može biti zastario. Zapis o kupcu može biti povjerljiv. Ako te razlike nestanu tijekom indeksiranja, AI asistent može dati odgovore koji zvuče samouvjereno, a operativno su pogrešni.

Izgradite izvore znanja s metapodacima koji odgovaraju načinu na koji poslovanje funkcionira. Korisne dimenzije često uključuju:

• vlasnika i izvorni sustav;
• datum stupanja na snagu i status revizije;
• publiku, poslovnu jedinicu, regiju ili opseg proizvoda;
• klasifikaciju i zahtjeve za pristup;
• veze na kanonski zapis ili pravilo.

Zatim provedite kontrole pristupa prije nego što materijal dospije u kontekst modela. Filtriranje dozvola nije kozmetička značajka dodana nakon dohvaćanja; ono je dio ispravnosti. Asistent koji ne može vidjeti zapis ne bi ga trebao moći sažeti, navesti kao izvor ni upotrijebiti za preporuku.

Kada odgovor utječe na odluku, uz njega vratite podatke o podrijetlu. Čovjek bi trebao moći pregledati pravilo, zapis ili izračun koji stoji iza preporuke bez tretiranja formulacije modela kao konačnog autoriteta.

Dajte prednost uskim alatima pred širokim pristupom sustavu

Agent postaje koristan kada može učiniti više od generiranja teksta. Može provjeriti pošiljku, otvoriti slučaj, pripremiti ponudu ili usmjeriti odobrenje. Također postaje rizičniji jer tečan jezik može prikriti nevaljanu radnju.

Arhitektonski odgovor jest dati agentima uske, namjenski izrađene alate umjesto opće veze s bazom podataka ili neograničenog administrativnog API-ja. Alat bi trebao izraziti poslovnu operaciju, provjeriti svoje ulaze, provesti autorizaciju i vratiti strukturirani rezultat.

type RefundRequest = {
  orderId: string;
  reasonCode: "duplicate" | "damaged" | "not_received";
};

type RefundResult = {
  status: "approved" | "needs_approval" | "rejected";
  reason: string;
  caseId?: string;
};

async function requestRefund(
  actorId: string,
  request: RefundRequest
): Promise<RefundResult> {
  // Authorize actor, load the order, evaluate policy,
  // record an audit event, and create a case if needed.
  return { status: "needs_approval", reason: "Manager approval required" };
}

Ta granica modelu daje ograničen izbor: zatražiti povrat novca putem istog puta pravila koji bi koristio korisnik. Model ne odlučuje primjenjuje li se pravilo, ne zaobilazi kontrole i ne izmišlja uspješan ishod. Prima rezultat koji može točno objasniti.

Alate oblikujte tako da budu idempotentni gdje je to praktično, posebno za radnje pokrenute ponovnim pokušajima. Mrežno vremensko ograničenje nakon poziva alata ne bi trebalo ostaviti agenta da nagađa je li stvorio dva povrata novca ili nijedan. Upotrebljavajte identifikatore zahtjeva, trajne zapise revizije i izričita stanja operacija.

Odvojite prijedloge od obveza

Ne bi svaka radnja trebala biti automatska. Pouzdan je obrazac pustiti AI da pripremi prijedlog, a deterministički tijek rada ili ovlaštenu osobu da preuzme obvezu.

Agent može sastaviti odgovor kupcu, prikupiti potkrepljujuću povijest narudžbe i preporučiti put za povrat novca. Predstavnik podrške može ga pregledati prije slanja ili odobravanja financijske radnje. Za slučajeve niskog rizika koji se ponavljaju, isti tijek rada može kasnije dopustiti automatsko dovršenje nakon što se dokažu pravila, nadzor i pouzdanost.

To nije neuspjeh automatizacije. Tako automatizacija stječe povjerenje uz očuvanje odgovornosti.

Zadržite determinističku logiku izvan prompta

Promptovi su korisni za tumačenje, transformaciju i komunikaciju. Loša su mjesta za skrivanje formula određivanja cijena, pragova usklađenosti, pravila prava na korištenje ili odluka o autorizaciji.

Ako se pravilo mora dosljedno primjenjivati, implementirajte ga u kodu ili usluzi za donošenje odluka. Neka model pozove tu mogućnost i upotrijebi rezultat u svom odgovoru. Tako promjene postaju pregledive, testabilne i sljedive.

Razmotrite prodajnog asistenta kojeg se pita ispunjava li potencijalni kupac uvjete za popust. Model može prepoznati relevantnog kupca i objasniti dostupnu opciju, ali izračun popusta trebao bi dolaziti iz usluge određivanja cijena. Konačna poruka može biti na prirodnom jeziku; brojevi i uvjeti trebali bi biti deterministički.

Ta podjela također olakšava evaluaciju. Poslovnu logiku možete testirati uobičajenim jediničnim i integracijskim testovima, a zatim model zasebno evaluirati za zadatke poput odabira pravog alata, sažimanja dokaza i komuniciranja nesigurnosti.

Ugradite mogućnost opažanja u svaki AI tijek rada

Tradicionalni zapisnici aplikacija odgovaraju na pitanja poput „Je li zahtjev neuspješan?” AI tijekovi rada trebaju dodatne odgovore: „Koje je informacije sustav upotrijebio?” „Koje je pozive alata pokušao?” „Zašto je stao?” i „Može li korisnik reproducirati rezultat?”

Zabilježite trag za značajne tijekove rada, uz zaštitu osjetljivih podataka. Trag bi trebao povezati korisnički zahtjev, rezultate dohvaćanja, pozive alata, ishode pravila, konačni odgovor i svako ljudsko odobrenje. Zabilježite verzije modela i prompta kao operativne metapodatke, a ne naknadnu misao.

Pregledavajte neuspjehe kao signale proizvoda. Ako asistent opetovano traži podatke koji već postoje, poboljšajte alat ili put dohvaćanja. Ako odabire pogrešnu radnju, pojasnite opise alata i dodajte slučajeve za evaluaciju. Ako korisnici nadjačavaju njegove preporuke, provjerite je li problem nedostajući kontekst, dvosmisleno pravilo ili pogrešno automatizirana odluka.

Korisni skupovi za evaluaciju proizlaze iz stvarnih obrazaca rada: rutinskih zahtjeva, dvosmislenih slučajeva, podataka koji nedostaju, sukobljenih pravila, odbijenih dozvola i prolaznih kvarova alata. Demonstracija izgrađena samo na uspješnim scenarijima gotovo vam ništa ne govori o tome je li agent spreman za produkciju.

Arhitektura je dugoročna AI prednost

Modeli će se mijenjati. Prozori konteksta, formati pozivanja alata i izbori pružatelja mijenjat će se s njima. Trajno ulaganje je sustav u kojem poslovno znanje ima jasno vlasništvo, pravila su izvršiva, radnje su ograničene, a ishodi su vidljivi.

Ta arhitektura pomaže ljudima jednako koliko pomaže AI-ju. Novi inženjeri mogu brže razumjeti domenu. Integracije postaju manje krhke. Revizije postaju manje bolne. Automatizaciju je lakše proširiti bez pretvaranja svakog tijeka rada u krhki prompt.

Najučinkovitiji AI sustavi nisu izgrađeni oko iluzije da model zna sve. Izgrađeni su oko discipline da mu se daju pravi kontekst, pravi alati i prave granice. Kada vaš softver može jasno objasniti kako poslovanje funkcionira, AI napokon ima nešto pouzdano iz čega može učiti.