Većina timova svoj rad s umjetnom inteligencijom započinje promptovima. To je razumljivo: prompt je vidljiv, neposredan i lako ga je poboljšati. No čim značajka umjetne inteligencije mora dohvatiti podatke o korisnicima, poštovati dozvole, objasniti odluku, izdržati ponovne pokušaje i uklopiti se u postojeći proizvod, prompt postaje najmanji dio problema.

Trajna prednost nije pametan odlomak poslan modelu. To je pozadinski sustav koji modelu pruža koristan kontekst, ograničene izbore, pouzdane alate i jasne granice. Drugim riječima, to je arhitektura osmišljena za poslovni instinkt umjetne inteligencije: sposobnost primjerenog djelovanja unutar pravila i stvarnosti vašeg proizvoda.

Premjestite inteligenciju iz prompta u sustav

Prompt može opisati pravila, ali aplikacijski kôd treba ih provoditi. Prompt može zatražiti aktualne podatke o računu, ali servis treba dohvatiti mjerodavan zapis. Prompt može tražiti od modela da ne otkriva osjetljive podatke, ali autorizacija mora spriječiti da ti podaci ikada uđu u njegov kontekst kada pristup nije dopušten.

Ova je razlika važna jer jezični modeli stvaraju uvjerljive odgovore, a ne transakcije baze podataka. Mogu dobro tumačiti informacije, sažimati složenost i birati među definiranim radnjama. Nisu zamjena za vaš identitetski sloj, pravila validacije, pokretač tijeka rada ili revizijski trag.

Korisni mentalni model jest tretirati model kao jednu komponentu u uobičajenom pozadinskom tijeku:

• Vaša aplikacija autentificira pozivatelja i uspostavlja granice zakupca i dozvola.
• Pozadinski servis prikuplja samo relevantan, autorizirani kontekst.
• Model prima fokusirani zadatak uz strukturirane informacije.
• Model može zatražiti odobrenu radnju putem ograničenog sučelja.
• Vaša aplikacija validira, izvršava, bilježi i prijavljuje rezultat.

Model može preporučiti povrat novca, sastaviti odgovor podrške ili klasificirati račun. Pozadinski sustav odlučuje može li se izraditi povrat novca, smije li se odgovor poslati i je li klasifikacija dovoljna za automatizaciju.

Dizajnirajte alate kao API-je, a ne kao konverzacijske prijedloge

Kada značajka umjetne inteligencije treba učiniti više od generiranja teksta, izložite poslovne mogućnosti kroz male, eksplicitne operacije. To je ista disciplina koja se koristi za interne API-je: stabilni nazivi, jasni ulazi, predvidljivi izlazi, autorizacija na granici i korisne pogreške.

Razmotrite asistenta koji pomaže agentu podrške s narudžbom. Izbjegavajte mu dati širok pristup bazi podataka ili dvosmislenu mogućnost poput „upravljaj narudžbom”. Radije odaberite uske operacije kao što su get_order_summary, list_recent_shipments i create_refund_request.

final class CreateRefundRequest
{
    public function handle(
        User $actor,
        string $orderId,
        int $amountCents,
        string $reason
    ): RefundRequestResult {
        $order = $this->orders->findForTenant($actor->tenantId, $orderId);

        $this->authorizer->assertCanRequestRefund($actor, $order);
        $this->validator->validateAmount($amountCents, $order->refundableCents());

        return $this->refunds->createRequest(
            order: $order,
            amountCents: $amountCents,
            reason: $reason,
            requestedBy: $actor->id
        );
    }
}

Model ne bi trebao odlučivati smije li pozivatelj izvršiti tu radnju. On pruža predložene argumente. Vaš domenski servis upravlja validacijom, autorizacijom, prijelazima stanja i pohranom.

Učinite radnje sigurnima za ponovne pokušaje

Mrežni pozivi ne uspijevaju. Zahtjevi modelu mogu isteći nakon što je radnja već stigla do vašeg servisa. Radnici reda čekanja mogu pokušati ponovno. Ako radnja pokrenuta umjetnom inteligencijom mijenja stanje, učinite idempotentnost ključnim zahtjevom.

Upotrijebite ključ idempotentnosti vezan uz namjeru korisnika i pohranite rezultat operacije. Ponovljeni zahtjev trebao bi vratiti izvorni rezultat umjesto stvoriti drugi zahtjev za povrat novca. To je uobičajena higijena distribuiranih sustava, no interakcije s umjetnom inteligencijom čine je vidljivijom jer jedan korisnički zahtjev može uključivati nekoliko koraka i neizvjesno vremensko usklađivanje.

Neka kontekst bude promišljen, aktualan i ograničen

Veliki kontekstni prozori ne uklanjaju potrebu za dizajnom konteksta. Slanje cijele povijesti korisnika ili neobrađenih redaka baze podataka skupo je, teško za pregledati i vjerojatno će zatrpati važnu činjenicu.

Izgradite kontekst kao model prikaza za zadatak. Za objašnjenje kašnjenja pošiljke modelu mogu trebati status narudžbe, događaji prijevoznika, obećani rok isporuke, odobreni tekst pravila i lokalizacija korisnika. Vjerojatno mu ne trebaju tokeni plaćanja, svaka interna bilješka ili popis nepovezanih narudžbi.

Strukturirani podaci osobito su vrijedni. Umjesto ugrađivanja nejasno oblikovanog odlomka o statusu, pružite polja s jasnom semantikom:

{
  "order_id": "ORD-1042",
  "status": "in_transit",
  "promised_delivery_date": "2026-11-09",
  "latest_carrier_event": {
    "occurred_at": "2026-11-06T08:30:00Z",
    "description": "Arrived at regional facility"
  },
  "eligible_for_compensation": false
}

Upute držite odvojeno od dohvaćenog sadržaja. Vanjski tekst, prenesene dokumente i polja koja je pružio korisnik tretirajte kao podatke za analizu, a ne kao ovlaštenje za promjenu ponašanja sustava. To odvajanje čini otpornost na prompt-injection praktičnijom: nepouzdan sadržaj može utjecati na odgovor, ali ne može redefinirati vaše dozvole ili pravila alata.

Izgradite nadziran tijek rada, a ne crnu kutiju

Ako tradicionalni krajnji endpoint donese iznenađujuću odluku, inženjeri pregledavaju zapise zahtjeva, zapise baze podataka, tragove i metrike aplikacije. Tijekovi rada s omogućenom umjetnom inteligencijom trebaju istu operativnu vidljivost.

Zabilježite korelacijski ID kroz zahtjev preglednika, pozadinski tijek rada, interakciju s modelom, pozive alata i asinkrone zadatke. Pohranite revizijski sažetak korištenih izvora podataka, zatraženih radnji, validacija koje su prošle ili nisu prošle te vraćenog konačnog rezultata. Budite promišljeni oko zadržavanja i osjetljivih podataka: nadziranost ne bi trebala postati nezaštićena arhiva sadržaja korisnika.

Mjerite tijek rada umjesto da izlaz modela tretirate kao jedan događaj. Korisni signali uključuju neuspjele pozive alata, odbijanja validacije, latenciju po fazi, broj ponovnih pokušaja, stope rezervnih rješenja i udio slučajeva usmjerenih na ljudski pregled. Oni otkrivaju je li problem kvaliteta konteksta, nestabilna ovisnost, nejasno sučelje ili pravilo koje treba doraditi.

Odaberite razine automatizacije koje odgovaraju cijeni pogreške

Ne bi svaki dobar prijedlog umjetne inteligencije trebao postati automatska radnja. Dobra arhitektura podržava postupnu autonomiju.

• Pomoć: generirajte nacrt, sažetak ili preporuku koju osoba može pregledati.
• Predlaganje: pripremite strukturiranu radnju koju korisnik izričito potvrđuje.
• Automatizacija unutar ograničenja: izvršavajte samo reverzibilne radnje niskog rizika koje zadovoljavaju deterministička pravila.
• Eskalacija: usmjerite dvosmislenosti, iznimke od pravila i slučajeve velikog utjecaja u tijek rada s čovjekom.

To nije oklijevanje; to je dizajn proizvoda. Pravi prag ovisi o reverzibilnosti, financijskom utjecaju, zahtjevima usklađenosti i kvaliteti dostupnih dokaza. Model može samouvjereno formulirati odgovor dok je ispravna radnja i dalje „zatraži pregled”.

Prompt je ugovor, a ne arhitektura

Promptovi su i dalje važni. Oni definiraju ton, uokvirivanje zadatka, oblik izlaza i kriterije odlučivanja. No najbolje funkcioniraju kada su okruženi sustavom koji pruža čist kontekst i odbija nesigurno ponašanje.

Najspremnije proizvode umjetne inteligencije neće izgraditi timovi koji modelima samo postavljaju bolja pitanja. Izgradit će ih inženjeri koji primjenjuju poznatu procjenu pozadinskih sustava na novu vrstu komponente: uska sučelja, mjerodavne podatke, eksplicitna pravila, trajne tijekove rada i vidljive putove neuspjeha.

Tako značajka umjetne inteligencije razvija poslovni instinkt. Ne pametnijim nagađanjem, nego radom unutar sustava koji zna što je važno.