CAPABILITĂȚI / 02
AI Systems & Agents
Inteligență conectată la context, instrumente și acțiuni reale.
Proiectăm sisteme AI care pot înțelege informația organizației, utiliza instrumente, participa în workflows și opera în limite controlabile.
01 Model vs. sistem
Modelul este doar o componentă.
Sistemul este ceea ce îl face util.
Un LLM produce text plauzibil. O capabilitate AI în producție trebuie să producă rezultate corecte în contextul organizației, verificabile și legate de o acțiune. Diferența dintre cele două nu este modelul — este restul sistemului.
02 Arhitectură
Inteligența are nevoie de arhitectură.
Un apel către un model nu este o arhitectură. Traseul de mai jos este forma minimă pe care o are, de obicei, o capabilitate AI care ajunge în producție: o cerere intră în aplicație, orchestrarea decide de ce are nevoie, modelul primește exact acel context, iar rezultatul este validat înainte de a deveni acțiune.
Fiecare pas poate fi observat, măsurat și oprit. Aceasta este diferența față de un apel direct la un model.
03 Context
Fără context, AI-ul doar generează. Cu context, poate participa în sistem.
Contextul nu înseamnă „mai mult prompt”. Înseamnă informația corectă, adusă controlat, pentru cererea curentă — și numai atât cât are voie să vadă utilizatorul care a inițiat-o. Fiecare strat adăugat schimbă natura rezultatului: de la un text general valabil, la un răspuns care se referă la o situație anume.
Contextul este și limita sistemului. Ce nu intră în context nu poate fi folosit — iar ce intră fără permisiune devine un incident de securitate.
Fără context: un răspuns valabil pentru orice organizație.
Cu context parțial: corect ca formă, incert ca fond.
Cu context complet și permisiuni: un răspuns despre această situație, atribuibil unei surse.
04 RAG & knowledge systems
Cunoașterea organizației trebuie să poată fi găsită, nu doar stocată.
Majoritatea organizațiilor au deja informația. Problema este că stă în locuri în care nu poate fi interogată: foldere, atașamente, sisteme separate, formate diferite. Un knowledge system transformă acea informație în ceva ce poate fi regăsit semantic, filtrat după permisiuni și atribuit unei surse.
Ce decide calitatea unui sistem de retrieval
- R1Semantic searchRegăsire după înțeles, nu după potrivirea exactă a cuvintelor.
- R2MetadataTip, sursă, versiune, dată, departament — filtrele care restrâng căutarea înainte de model.
- R3PermisiuniFiltrarea se aplică la retrieval, nu în răspuns. Ce nu are voie să vadă utilizatorul nu ajunge în context.
- R4Source attributionFiecare afirmație poate fi urmărită până la documentul din care provine.
- R5Retrieval qualityMăsurată separat de calitatea răspunsului: dacă fragmentele greșite ajung în context, modelul nu are cum să corecteze.
Surse tipice
Un sistem RAG bine construit reduce semnificativ răspunsurile nefondate și le face verificabile prin atribuire. Nu garantează acuratețe perfectă. De aceea tratăm retrieval-ul ca pe o componentă măsurabilă, cu evaluare proprie, și proiectăm sistemul astfel încât un răspuns incert să poată fi identificat, escaladat sau blocat.
05 AI agents
Un agent nu este un chatbot cu mai multe butoane.
Un AI Agent devine relevant atunci când poate interpreta contextul, decide următorul pas, utiliza instrumente și opera în limite explicite.
Instrumente pe care le poate primi un agent
Ce nu promitem
Un agent nu operează nelimitat și nu înlocuiește responsabilitatea unei echipe. Autonomia lui este o decizie de proiectare: ce instrumente primește, ce poate declanșa fără confirmare, câți pași are voie să facă și când trebuie să se oprească. Aceste limite se stabilesc înainte de implementare, nu după primul incident.
06 Tool use
Inteligența devine operațională atunci când poate utiliza instrumentele potrivite.
Function calling nu înseamnă „modelul face ce vrea”. Înseamnă un set explicit de instrumente, fiecare cu o semnătură, parametri validați și un domeniu de acțiune limitat. Modelul propune apelul; sistemul decide dacă îl execută.
Secvența unui apel
- 01Ruta se activeazăInstrumentul este selectat din setul permis pentru acest utilizator și acest context.
- 02Cererea structurată pleacăParametrii sunt validați față de schemă înainte de execuție.
- 03Rezultatul se întoarceRăspunsul instrumentului intră înapoi în sistem, nu direct în răspunsul final.
- 04Sistemul verificăFormat, coerență cu regulile de business, erori și cazuri limită.
- 05Următoarea stare devine disponibilăContinuare, escaladare către un om sau oprire — în funcție de rezultat.
07 Agentic workflows
Autonomia trebuie proiectată, nu presupusă.
Cele mai stabile fluxuri nu sunt nici complet deterministe, nici complet autonome. Sunt fluxuri în care pașii previzibili rămân cod, iar interpretarea — acolo unde chiar e nevoie de ea — este delegată modelului, sub reguli, praguri și aprobări.
08 Human-in-the-loop
Unele decizii trebuie accelerate. Altele trebuie confirmate.
Un checkpoint uman nu este o frână pusă din neîncredere în AI. Este felul în care o organizație matură își păstrează responsabilitatea acolo unde ea contează — și o elimină acolo unde nu aduce nimic.
CONTROLAT
- H1Approval gatesAcțiunile cu impact real trec printr-o confirmare explicită, nu printr-o notificare.
- H2EscalationCazurile neobișnuite ajung la persoana potrivită, cu tot contextul atașat.
- H3Confidence thresholdsSub un prag definit, sistemul cere confirmare în loc să continue.
- H4Manual review & exception handlingExcepțiile nu se pierd: devin o coadă de lucru, cu stare și responsabil.
- H5OverrideOmul poate corecta propunerea, iar corecția rămâne înregistrată.
- H6AccountabilitySe știe cine a decis, pe ce bază și în ce moment — inclusiv când decizia a fost automată.
09 Guardrails & control
Capabilitatea fără control nu este suficientă.
Între intenția sistemului și un efect în lumea reală există o secvență de porți. Fiecare poate opri acțiunea. Niciuna nu este opțională atunci când acțiunea atinge date sau sisteme reale.
EXTERN
Auditabilitate
Fiecare poartă lasă o urmă: ce s-a cerut, ce s-a permis, ce s-a blocat și pe ce bază. Fără această urmă, un sistem AI nu poate fi nici depanat, nici apărat într-o discuție cu un auditor.
Ce nu garantăm
Nu există arhitectură care să elimine complet riscul. Guardrails reduc suprafața de eroare și fac abaterile vizibile — nu oferă o garanție absolută de securitate sau de corectitudine. Cerințele de securitate și conformitate se stabilesc împreună cu echipele responsabile din organizație.
10 Evaluation
Un sistem AI trebuie evaluat ca sistem, nu admirat într-un demo.
Un demo arată cazul fericit. Evaluarea arată ce se întâmplă în restul cazurilor — și, mai important, unde anume se rupe lanțul: la retrieval, la alegerea instrumentului, la format sau la interpretare.
Pragurile de acceptare se stabilesc per proiect, împreună cu echipa care folosește sistemul. Nu există valori universale, iar cifrele afișate în demo-uri nu se transferă între contexte.
11 Observability
Trebuie să putem vedea ce a făcut sistemul și de ce.
O execuție AI nu este o cutie neagră dacă este instrumentată de la început. Un trace arată contextul regăsit, instrumentele apelate, stările intermediare, erorile și intervențiile umane — în ordinea în care s-au întâmplat.
Ce înregistrăm
Traces, tool calls, contextul regăsit, stările intermediare, erorile, latența, utilizarea modelului, deciziile și intervențiile umane.
Pentru cine
Pentru echipa care operează sistemul, pentru cei care îl îmbunătățesc și pentru cei care trebuie să explice o decizie în afara echipei tehnice.
De ce contează
Fără observability, un comportament nedorit nu poate fi reprodus. Iar ce nu poate fi reprodus nu poate fi reparat.
12 AI în produs
AI-ul este mai puternic atunci când face parte din produs.
O fereastră de chat lipită lângă aplicație transferă efortul înapoi către utilizator: el trebuie să explice contextul pe care produsul îl are deja. Când inteligența stă în interiorul produsului, contextul vine gratis — iar rezultatul se întoarce direct în flux.
Asistență contextuală
Ajutor legat de ecranul, entitatea și sarcina curentă, nu de o conversație separată.
Căutare inteligentă
Regăsire după înțeles peste conținutul și datele produsului, cu permisiunile utilizatorului.
Analiză de documente
Extragere structurată din fișiere, cu validare și trimitere mai departe în flux.
Recomandări
Sugestii derivate din starea reală a sistemului, nu din preferințe generice.
Suport în workflow
Pregătirea pasului următor: completare, sumarizare, propunere de acțiune.
Structurare de conținut
Transformarea textului liber în câmpuri, categorii și relații utilizabile.
Copiloți operaționali
Asistență pentru rolurile care lucrează zilnic în sistem, cu acțiuni permise explicit.
Suport în decizie
Context adunat și prezentat astfel încât decizia să rămână a omului.
Exemple conceptuale de integrare a AI în produs, nu produse existente.
13 AI + Date
Calitatea inteligenței începe cu arhitectura datelor.
Un model bun peste date prost structurate produce răspunsuri sigure pe sine și greșite. Înainte de orice discuție despre modele, întrebarea este dacă informația există într-o formă în care poate fi regăsită, filtrată și atribuită.
- D1Calitatea datelorErorile din sursă devin erori în răspuns, cu un ton mai convingător.
- D2StructuraCe este structurat poate fi filtrat înainte de model; ce nu este, ajunge în context nefiltrat.
- D3MetadataTip, sursă, versiune, proprietar — fără ele, retrieval-ul lucrează orb.
- D4Access controlPermisiunile trebuie să existe în stratul de date, nu improvizate în stratul AI.
- D5SemanticăAceleași noțiuni trebuie să însemne același lucru în toate sistemele.
- D6FreshnessUn index vechi produce răspunsuri corecte pentru o realitate care nu mai există.
- D7Source of truthCând există trei variante ale aceleiași informații, sistemul trebuie să știe care contează.
14 AI + Integrare
Un AI Agent este limitat de sistemele la care se poate conecta.
Un agent care poate doar să răspundă rămâne o interfață. Un agent care poate citi starea unui sistem și declanșa o acțiune în altul devine parte din operațiune. Diferența se face în stratul de integrare, nu în model.
Categorii de sisteme, nu integrări cu furnizori anume.
15 Relevanță
Când AI Systems & Agents devin relevante.
Nu în orice proces. Semnalul apare de obicei acolo unde oamenii petrec timp căutând, citind, reformulând sau transferând informație dintr-un loc în altul.
Nu orice proces are nevoie de AI. Acolo unde regulile sunt clare și stabile, o automatizare deterministă este mai ieftină, mai rapidă și mai ușor de apărat. Prima întrebare pe care o punem este dacă problema chiar are nevoie de interpretare.
16 Capabilități conectate
AI este un strat al arhitecturii, nu o insulă.
17 Soluții
De la AI capability la transformare operațională.
18 Convergență
Toate componentele, într-un singur sistem.
FIG. 13 — Aceleași opt componente din FIG. 01, într-o singură capabilitate
Contact
Ai un proces, produs sau sistem care poate deveni mai inteligent?
Începem cu problema și contextul operațional, apoi definim unde AI-ul aduce valoare și ce arhitectură este necesară pentru a-l integra responsabil.