Pe scurt
Un pilot demonstrează că un flux poate funcționa pe un domeniu limitat; producția cere dovezi că funcționează repetabil cu utilizatori, date, erori, costuri și incidente reale. Trecerea se aprobă numai după evaluare, securitate, control de acces, fallback, monitorizare, owner și plan de rollback.
Prototipul nu este un sistem de producție
| Dimensiune | Prototip | Producție |
|---|---|---|
| Scop | Demonstrează ipoteza | Livrează un rezultat operațional |
| Date | Eșantion controlat | Varietate, erori și date reale |
| Utilizatori | Echipă restrânsă | Roluri, training și suport |
| Calitate | Exemple selectate | Set reprezentativ și regresii |
| Securitate | Mediu izolat | Auth, permisiuni, loguri, incidente |
| Fiabilitate | Rulare asistată | SLA intern, fallback și rollback |
| Cost | Experiment | Buget, limite și cost per rezultat |
O demonstrație poate evita cazurile dificile, poate folosi date pregătite manual și poate avea un inginer care corectează în fundal. În producție, succesul înseamnă comportament suficient de bun în distribuția reală, inclusiv refuzuri, indisponibilitate și acțiuni repetate.
Business owner, scope și criterii de succes
Fiecare sistem are nevoie de un business owner care poate accepta riscul, prioritiza modificările și opri utilizarea. Definește utilizatorii, datele, acțiunile și cazurile excluse. Succesul include rezultat, calitate, risc, cost și adopție; nu doar faptul că modelul a răspuns.
- Care este decizia sau sarcina susținută?
- Ce rezultat măsurabil trebuie îmbunătățit față de baseline?
- Ce nu are voie sistemul să facă?
- Cine aprobă excepțiile și cine poate opri fluxul?
- Care sunt pragurile de calitate, cost și incident?
- Ce alternativă funcționează când AI nu este disponibil?
Datasetul de evaluare
Construiește setul înainte de optimizarea finală și separă testarea de exemplele folosite pentru prompt sau configurare. Include cazuri frecvente, rare, ambigue, fără răspuns, malițioase și cu impact mare. Etichetele sunt validate de experți, iar dezacordurile sunt documentate.
| Dimensiune | Metrică | Prag | Owner |
|---|---|---|---|
| Task completion | Rezultat complet și utilizabil | Definit pe categorie | Business |
| Acuratețe | Fapte și câmpuri corecte | După severitate | Domain expert |
| Groundedness | Afirmații susținute de surse | Fără invenții critice | Product |
| Refuz | Refuză când trebuie | Prag separat | Risk |
| Siguranță | Injection, leakage, tool misuse | Zero incidente severe | Security |
| Latență | Percentile, nu doar medie | SLO stabilit | Engineering |
| Cost | Cost per rezultat valid | Buget și alertă | Finance |
Acuratețe, halucinații și refuz
Nu folosi o singură acuratețe. O eroare de formatare și o recomandare financiară falsă nu au aceeași severitate. Definește clase de eroare, ponderi și acțiuni. Pentru răspunsuri pe documente, măsoară retrieval-ul și citarea separat de formulare.
Refuzul este o funcție: sistemul trebuie să recunoască lipsa datelor, permisiunilor sau autorității. Testează și refuzurile false, care reduc utilitatea. Când o clarificare ar rezolva cazul, cere informația înainte de a refuza.
Securitate: prompt injection, leakage și tool permissions
Tratează prompturile, documentele recuperate și rezultatele instrumentelor ca intrări neîncrezătoare. Prompt injection poate apărea într-un email, PDF sau site recuperat, nu doar în mesajul utilizatorului. Separă instrucțiunile de date, validează ieșirile și nu acorda modelului acces direct la secrete.
| Risc | Scenariu | Control | Semnal |
|---|---|---|---|
| Prompt injection | Documentul cere exfiltrarea | Izolare, filtre, allowlist de acțiuni | Instrucțiune din conținut |
| Data leakage | Răspunsul include date nepermise | Filtrare înainte de retrieval și output | Canary / audit |
| Tool misuse | Agentul execută acțiune greșită | Schema strictă, scop minim, confirmare | Acțiune respinsă |
| Model drift | Versiunea schimbă comportamentul | Pinning unde există, regresii | Scădere scorecard |
| Cost runaway | Buclă sau context excesiv | Buget, timeout, rate limit | Cost per caz |
| Oversharing | Permisiuni sursă prea largi | ACL, recertificare, fail-closed | Acces neobișnuit |
NIST Generative AI Profile și materialele ENISA sunt cadre de referință, nu certificări sau obligații universale în România. Adaptează controalele la active, atacatori și impact.
Autentificare, autorizare și audit logs
Autentifică persoana și serviciul, autorizează fiecare acțiune și resursă, apoi verifică din nou la execuție. Nu transmite identitatea ca text pe care modelul îl poate modifica. Logurile trebuie să permită reconstrucția incidentului fără a păstra inutil date sensibile: versiuni, permisiuni, surse, acțiuni, aprobări și rezultat.
Human approval și fallback
Aprobarea este plasată înaintea acțiunii ireversibile sau cu impact. Interfața arată ce va face sistemul, cu ce date și de ce. Pentru volum mare, folosește praguri și eșantionare, dar păstrează oprirea automată când distribuția se schimbă.
| Situație | Fallback | Comportament |
|---|---|---|
| Model indisponibil | Proces manual / coadă | Nu pierde cererea |
| Încredere insuficientă | Clarificare sau operator | Nu inventează |
| Tool indisponibil | Draft fără execuție | Informează utilizatorul |
| Permisiuni neclare | Refuz fail-closed | Nu returnează parțial |
| Cost depășit | Model/flux alternativ aprobat | Păstrează pragul de calitate |
Furnizori, modele și schimbări
Furnizorii pot schimba modele, limite, prețuri și politici. Păstrează un registru al dependențelor, versiunea evaluată și notificările. Nu presupune că două modele cu același nume sau un alias dinamic sunt comportamental identice. Orice schimbare relevantă trece prin regresii.
| Verificare | Dovadă |
|---|---|
| Capabilitate | Scorecard complet pe setul înghețat |
| Siguranță | Teste injection, leakage și tool use |
| Date | Termeni, retenție, regiune și subprocesatori |
| Cost | Cost pe caz și scenariu de vârf |
| Latență | p50/p95/p99 și timeout |
| Rollback | Versiunea veche poate fi reactivată |
| Aprobare | Business, security și legal după risc |
Cost controls, rate limits și fiabilitate
Setează bugete pe utilizator, proces și perioadă, limite de context, număr maxim de pași, timeout și protecție la retry. Măsoară costul per rezultat valid, nu per apel. Planifică vârfuri, indisponibilitate regională și degradarea controlată către o funcție mai simplă.
Monitorizare și incident response
Procesul unește semnalul tehnic cu impactul de business și obligațiile aplicabile.
- Detectează și clasifică impactul, datele și utilizatorii afectați.
- Oprește acțiunea, revocă accesul sau treci pe fallback.
- Păstrează dovezile și identifică versiunea, promptul, sursele și tool-urile.
- Notifică ownerii de securitate, business, date și juridic după procedură.
- Remediază și rulează regresii pe cazul incidentului și cazuri similare.
- Repornește numai cu aprobare, apoi urmărește recurența.
Monitorizează distribuția cererilor, calitatea eșantionată, refuzurile, override-urile, incidentele, latența și costul. Feedbackul utilizatorului este semnal, nu ground truth. Un thumbs-up nu confirmă factualitatea, iar un thumbs-down poate reflecta tonul.
Versionare și change management
Versionează promptul, modelul, tool-urile, regulile, indexul și datasetul de evaluare. Leagă fiecare deploy de rezultate și aprobări. Comunică utilizatorilor ce s-a schimbat și actualizează documentația. Pentru utilizări reglementate, păstrează dovezile cerute de cadrul aplicabil.
Training și adopție
Adopția nu se rezolvă prin acces la tool. Utilizatorii trebuie să știe când îl folosesc, când verifică, cum raportează și ce se întâmplă la eroare. Măsoară utilizarea eligibilă, abandonul, corecțiile și munca paralelă. Dacă oamenii copiază rezultatul în alt sistem, integrarea poate fi problema, nu trainingul.
Checklist de production readiness
| Poartă | Criteriu go | Criteriu no-go |
|---|---|---|
| Business | Owner, scope, baseline și valoare | Nimeni nu poate opri |
| Calitate | Praguri pe severitate trecute | Erori critice necontrolate |
| Date | Scop, acces, retenție și ștergere | Surse/permisiuni neclare |
| Securitate | Teste și remedieri | Injection sau leakage sever |
| Operațiuni | Monitorizare, fallback, incident | Dependență fără alternativă |
| Cost | Buget și cost per rezultat | Buclă sau cost imprevizibil |
| Oameni | Training, suport, aprobare | Oversight decorativ |
| Legal | Analiză și documente aplicabile | Clasificare nerezolvată |
Rollback decision table
| Semnal | Acțiune imediată | Reluare |
|---|---|---|
| Expunere de date | Oprire și incident | După remediere și aprobare |
| Acțiune financiară greșită | Blochează tool-ul | Teste + limită nouă |
| Scădere calitate sub prag | Revino la versiune / om | Regresii trecute |
| Cost peste plafon | Limitează și investighează | Buget și cauză validate |
| Indisponibilitate | Fallback | După stabilitate monitorizată |
| Adopție insuficientă | Nu extinde | Proces și UX corectate |
Măsurarea după lansare și decizia de extindere
Recalculează ROI-ul pe date reale și compară rezultatele cu baseline-ul. Extinde pe categorii, nu «la toată compania». Un pilot poate fi oprit dacă valoarea, calitatea sau riscul nu justifică producția. Aceasta este o decizie bună, nu un eșec.
Exemplu ipotetic de production gate
Exemplu ipotetic: un copilot pentru clasificarea tichetelor rulează două săptămâni fără a modifica rutarea. Setul arată performanță bună pe întrebări generale, dar slabă pe incidente de securitate. Echipa activează automatizarea doar pentru trei categorii cu risc redus și păstrează incidentele la operator.
După o lună, rata de corecție și costul rămân sub prag, dar o versiune nouă a modelului schimbă clasificarea. Deploymentul este blocat de regresii; producția rămâne pe versiunea evaluată. Exemplul arată că go-live-ul nu este o aprobare permanentă și că extinderea pe categorii este mai sigură decât un singur comutator.
Cadenta de guvernanță
| Frecvență | Revizuire |
|---|---|
| Continuu | Alerte de securitate, cost, indisponibilitate și incidente |
| Săptămânal | Eșantion de calitate, refuzuri, override și feedback |
| Lunar | KPI de proces, adopție, cost și backlog de risc |
| La schimbare | Model, prompt, tool, date, permisiuni sau furnizor |
| Trimestrial / după risc | Owner, scope, clasificare, acces și continuitate |
Cadenta trebuie adaptată riscului și volumului. Un sistem rar, dar cu impact mare, poate cere review la fiecare caz; un clasificator cu impact mic poate folosi eșantionare. Orice incident sever întrerupe cadenta normală și declanșează procedura dedicată.
Repetiția generală înainte de go-live
Înainte de lansare, rulează un exercițiu cu indisponibilitate, acces neautorizat, cost depășit și rezultat critic greșit. Echipa trebuie să detecteze, să oprească, să folosească fallback-ul și să comunice. Notează timpii, blocajele și permisiunile lipsă.
- Ownerul de business poate opri fluxul fără intervenția furnizorului.
- On-call-ul știe ce loguri și versiuni să păstreze.
- Utilizatorii știu ce alternativă folosesc și cum raportează.
- Security, DPO și juridicul au criterii clare de escaladare.
- Rollback-ul a fost executat într-un mediu relevant, nu doar descris.
Limitări
Niciun checklist nu garantează siguranța sau conformitatea. Cerințele depind de sistem, rol, industrie și persoane afectate. Corelează acest cadru cu ghidul general de implementare, AI Act, Shadow AI, RAG și pagina de securitate.
Resurse pentru pasul următor
Aplică acest cadru într-o situație reală
Implementare AI pentru companii
Serviciul principal asociat cadrului din acest ghid.
Studiul de caz BrandScan
Vezi cum a fost aplicată abordarea într-un produs real.
Radar Business AI
Folosește resursa gratuită pentru primul diagnostic.
Cum să Implementezi AI în Compania Ta — Ghid pentru IMM-uri din România
Continuă cu o metodologie complementară.
Cum Calculezi ROI-ul unui Proiect AI: Formule, Baseline și Perioada de Recuperare
Continuă cu o metodologie complementară.
RAG pentru Companii: Cum Construiești un Asistent AI pe Documentele Interne
Continuă cu o metodologie complementară.
Prețuri și forme de colaborare
Vezi opțiunile publice de lucru cu NextChapter.
Discută cu echipa
Clarifică problema și următorul pas potrivit.
Scris deVlad CovaciFondator & Partener Produs și TehnologieÎntrebări frecvente
- Când este un pilot gata de producție?
- Când trece pragurile stabilite pentru business, calitate, securitate, date, cost și operare și există owner, fallback, incidente, training și rollback.
- Câte exemple trebuie în dataset?
- Nu există un număr universal. Acoperă categoriile, severitățile, cazurile rare și distribuția reală; urmărește acoperirea, nu o cifră arbitrară.
- Este suficient un human in the loop?
- Nu, dacă persoana nu are timp, informații, competență și autoritate. Review-ul trebuie proiectat și măsurat.
- Ce monitorizez după lansare?
- Calitate eșantionată, distribuție, refuz, override, cost, latență, acces, incidente, feedback și performanța procesului.
- Când fac rollback?
- Când apare un incident sever, calitatea scade sub prag, costul scapă de sub control sau fallback-ul este mai sigur. Condițiile trebuie aprobate înainte de lansare.
Termeni cheie din acest ghid
- Human in the Loop — Human in the loop este un control prin care o persoană competentă verifică, aprobă, corectează sau oprește o recomandare ori acțiune AI.
- Prompt Injection — Prompt injection este o intrare care încearcă să schimbe instrucțiunile sau comportamentul unui sistem bazat pe modele de limbaj.
- Halucinație AI — O halucinație AI este un răspuns generat care pare plauzibil, dar conține informații nesusținute, incorecte sau inventate.
- AI Literacy — AI literacy reprezintă cunoștințele și abilitățile necesare pentru a folosi sau opera un sistem AI în mod adecvat contextului și riscului.
Surse și documentație
- NIST — Artificial Intelligence Risk Management Framework 1.026 ianuarie 2023 · Accesat la 3 august 2026 · Cadru voluntar din SUA, folosit aici ca referință de management al riscului, nu ca obligație legală în România.
- NIST — AI RMF: Generative Artificial Intelligence Profile (NIST AI 600-1)26 iulie 2024; pagină actualizată 8 aprilie 2026 · Accesat la 3 august 2026 · Cadru voluntar; tratează riscuri și măsuri pentru AI generativ.
- ENISA — Artificial Intelligence Cybersecurity Challenges15 decembrie 2020 · Accesat la 3 august 2026
- Parlamentul European și Consiliul UE — Regulamentul (UE) 2024/1689 privind inteligența artificială13 iunie 2024 · Accesat la 3 august 2026 · Textul de bază trebuie citit împreună cu modificările ulterioare.
- Parlamentul European și Consiliul UE — Regulamentul (UE) 2026/1744 — Digital Omnibus on AI8 iulie 2026; JO 24 iulie 2026 · Accesat la 3 august 2026 · În vigoare; modifică inclusiv termenele și articolul 4.
- European Data Protection Board — Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models17 decembrie 2024 · Accesat la 3 august 2026 · Evaluările privind anonimitatea și interesul legitim sunt dependente de context.
Ai nevoie de ajutor cu implementarea?
NextChapter ajută companiile românești să aplice exact ce ai citit în acest ghid.
Discută cu echipa NextChapter →