Un sistem care a fost dezvoltat în primăvara lui 2026 pentru o companie românească din retail-ul de electronice. Nouă luni mai târziu, la final de 2026, a economisit companiei estimativ 340.000 EUR în pierderi prevenite și costuri operaționale. Asta e povestea pe care o construim astăzi – cu detalii tehnice, decizii de arhitectură și ce nu a mers din prima.

Detecția anomaliilor AI a devenit în 2026-2027 una dintre cele mai mature aplicații de machine learning în business. Diferența între un proiect care produce valoare și unul care intră în lista lungă de pilot-uri abandonate stă în detalii. Articolul ăsta merge prin ele.

Detecția anomaliilor cu AI: contextul în care a apărut nevoia

Compania în cauză operează 32 de magazine fizice plus un canal online, cu o cifră de afaceri anuală de aproximativ 80 milioane EUR. Echipa de operațiuni se confruntase ani la rând cu o problemă invizibilă în rapoartele standard: pierderi mici, distribuite, care ajungeau la nivel agregat la sume semnificative.

Tranzacții cu prețuri ușor sub costul de achiziție. Stocuri care nu se închideau perfect la inventarele lunare. Reduceri aplicate manual fără justificare clară. Returnări procesate în pattern-uri ciudate.

Niciuna dintre aceste anomalii nu ieșea la auditul standard. Erau prea mici individual. Cumulat, însă, costau companiei undeva la 400-500.000 EUR pe an.

Soluția tradițională ar fi fost reguli statice scrise în SQL – „flagează tranzacțiile sub costul X”, „raportează reducerile peste Y%”. Echipa de operațiuni încercase asta cu trei ani înainte. Sistemul produsese atât de multe false positives încât a fost ignorat în șase luni.

De ce AI și nu reguli

Distincția nu e ideologică. Reguli statice funcționează când pattern-urile sunt cunoscute și stabile. Detecția anomaliilor AI funcționează când pattern-urile sunt complexe, contextuale și se schimbă în timp.

În cazul de față, „normal” pentru un magazin de centru comercial mare nu e „normal” pentru un magazin de cartier. „Normal” pentru sezon nu e „normal” pentru post-sezon. „Normal” pentru o categorie de produs nu e „normal” pentru alta. Un sistem de reguli care să capteze toate aceste nuanțe ar fi avut peste 800 de reguli individuale – imposibil de menținut.

Modelul AI care învață din contextul tranzacției capturează toate aceste nuanțe simultan, fără să fie programat explicit pentru ele.

Arhitectura – ce s-a construit

Sistemul final, după 4 luni de dezvoltare și 5 luni de operare, are 4 componente:

Ingestia. Date din POS (sistem de casierie) ajung într-un staging area pe PostgreSQL la fiecare 15 minute. Volumul – aproximativ 18.000 tranzacții pe zi în ansamblu, vârfuri de 1.500 pe oră în weekend.

Feature engineering. Aici stă jumătate din muncă. Fiecare tranzacție e îmbogățită cu context – oră, zi a săptămânii, magazin, categorie produs, marjă teoretică, comportament istoric al casierului. Sunt aproximativ 45 de feature-uri per tranzacție.

Modelul. Un Isolation Forest combinat cu un autoencoder. Nu e cel mai modern model posibil – putea fi un model bazat pe transformers – dar e suficient de eficient pentru cazul ăsta și are avantajul de a fi explicabil. Pentru o tranzacție flagată, putem identifica exact ce feature contribuie la scorul de anomalie.

Workflow-ul de revizuire. Tranzacțiile cu scor peste un prag dinamic ajung într-o coadă pentru revizuire umană. Două persoane din echipa de operațiuni le verifică zilnic și marchează rezultatul – „real positive” sau „false positive”. Acest feedback alimentează retraining-ul săptămânal.

Stratul de revizuire e elementul cel mai important pe care echipa l-a învățat pe parcurs. Fără feedback uman structurat, modelul s-ar fi degradat în luni.

Tehnologii folosite

Pentru contextul concret al companiei de 200 angajați cu echipă tehnică mică:

• Python 3.11 cu scikit-learn și PyTorch pentru modele.
• PostgreSQL pentru storage tranzacțional. Snowflake era exagerat pentru volumul real.
• Prefect pentru orchestrarea pipeline-ului. Airflow ar fi fost overkill, n8n insuficient.
• MLflow pentru tracking-ul experimentelor și versionarea modelelor.
• Streamlit pentru interfața de revizuire – construită în 3 zile, suficient de bună pentru 2 utilizatori.
• Slack pentru alerte agregate (sumar zilnic, nu alerte per tranzacție).

Costul total al infrastructurii: 350 EUR/lună. Pentru un sistem care economisește 340.000 EUR/an, e un ROI care nu cere discuții.

Ce nu a mers din prima

Primele 6 săptămâni de operare au expus probleme pe care nicio fază de testing nu le anticipase.

Problema 1: drift sezonier neașteptat. Modelul a fost antrenat pe 8 luni de date. La intrarea în Black Friday, distribuția tranzacțiilor s-a schimbat radical – reduceri agresive, volume mari, categorii cumpărate diferit. Modelul a flagat 47% din tranzacții ca anomalii într-o zi. Soluția: retraining accelerat plus reguli de gating pentru perioade promoționale cunoscute.

Problema 2: bias în datele istorice. Datele de training conțineau deja anomaliile pe care voiam să le detectăm – dar fără să fie etichetate. Modelul a învățat că anumite pattern-uri suspicioase sunt „normale” pentru că le văzuse repetat în date. Soluția: un audit manual al primelor 2.000 tranzacții flagate, plus un al doilea val de antrenare cu date curățate.

Problema 3: false positives la magazinele mici. Magazinele cu volum mic nu produc suficiente date pentru ca modelul să învețe pattern-urile lor specifice. Toate tranzacțiile lor păreau anormale față de magazinele mari. Soluția: feature engineering specific pentru context („tranzacția X e anormală relativ la magazinul ei, nu la întreaga rețea”).

Aceste trei probleme au consumat 3 luni de iterație. Nu sunt unice pentru cazul ăsta – apar predictibil în orice implementare reală de detecție anomalii AI.

Cifrele după 9 luni

La final de 2026, cu 9 luni de operare în spate:

• Sistem rulează 4 cicluri zilnic, procesează ~75.000 tranzacții pe lună.
• Rata de flagare: 1.2% din tranzacții (~900 pe lună).
• Rata de adevăr pozitiv după revizuire: 38% (340 cazuri reale pe lună).
• Pierderi prevenite estimate: ~28.000 EUR/lună.
• Timp uman necesar revizuirii: ~12 ore pe săptămână, două persoane.

Rata de 38% adevăr pozitiv pare scăzută. În realitate, e foarte bună pentru detecție anomalii într-un context cu clase dezechilibrate. Multe sisteme similare din producție operează la 15-25%.

Iar economia reală nu vine doar din tranzacțiile individuale flagate. Vine și dintr-un efect de descurajare – când angajații și partenerii știu că există un sistem care detectează pattern-uri, comportamentele problematice scad.

Ce face AI-ul mai bine ca regulile

Câteva exemple concrete din cazurile reale capturate:

Un casier dintr-un magazin de cartier vindea în mod consistent produse la prețuri ușor sub cele afișate, în benzi orare specifice (târziu seara, cu clienți obișnuiți). Niciun set de reguli n-ar fi prins asta – prețurile erau în intervalul autorizat pentru reduceri excepționale. Modelul AI a identificat pattern-ul: același casier, aceleași produse, aceleași ore, aceiași clienți, reduceri repetate.

O fraudă coordonată între un casier și un client cu returnări fictive – tranzacția de vânzare era normală, returnarea era făcută la 3 zile diferență cu un cod manual. Modelul a corelat pattern-ul de vânzare cu cel de returnare la nivel de pereche casier-client, ceva ce o regulă nu putea face.

Erori sistemice ale unei case de marcat care aplica un discount fix de 2% la toate tranzacțiile peste un anumit prag, fără justificare în sistem. Nu era fraudă, era un bug. Dar costa companiei 1.800 EUR/lună.

Ce să rețină echipele care vor să facă același lucru

Distilarea experienței într-o listă scurtă:

1. Începe cu un caz strâmt. Nu „detectează toate anomaliile”. „Detectează fraude la POS” sau „detectează erori în returnări”. Cu cât e mai strâmt, cu atât e mai ușor să măsori succesul.

2. Construiește feedback loop-ul înainte de model. Cine va revizui flagările? În cât timp? Cu ce instrument? Dacă răspunsurile nu sunt clare, modelul va fi inutil indiferent cât de bun e.

3. Acceptă că primele 8-12 săptămâni sunt iterație continuă. Bugetul de timp pentru un sistem productiv care chiar funcționează e 3-6 luni de la prima idee. Mai puțin de atât, te minți singur.

4. Modele explicabile bat modelele cu 2% mai bune. Pentru un business analyst care explică unui director financiar de ce a fost flagată o tranzacție, „pentru că modelul a învățat” nu e răspuns. „Pentru că suma e cu 35% sub media casierului în ultimul trimestru” e răspuns.

5. Nu uita drift-ul. Un model neretrenat se degradează în 3-6 luni. Schedule-ul de retraining trebuie să fie parte din arhitectură de la început, nu adăugare ulterioară.

Tema se leagă natural de discuția despre Data Analyst, unde am intrat în detaliu pe pattern-urile pe care le observăm în piață. Pentru actualizări și detalii suplimentare, Anthropic rămâne sursa principală pe acest subiect. În fond, anomalii AI nu e doar un concept tehnic — este o decizie de business cu impact direct pe productivitatea echipei.

Outlook

În 2027, detecția anomaliilor AI nu mai e o aplicație de pionierat. E aplicație de mainstream pentru orice business cu volume tranzacționale. Tool-urile vendor (Microsoft Sentinel, Datadog, Anomalo) s-au maturizat semnificativ în 2026 și acoperă acum cazurile generice fără să trebuiască să construiești tu modele custom.

Pentru cazuri specifice – cum a fost cel descris aici – construcția custom rămâne competitivă. Costul total al implementării (5-8 săptămâni inginer plus 350 EUR/lună infrastructură) e accesibil pentru orice companie de peste 100 de angajați cu volume tranzacționale semnificative.

Direcția care va deveni mainstream în 2027-2028 e integrarea agenților AI în workflow-ul de revizuire. Un agent care primește o tranzacție flagată, investighează automat contextul (verifică istoricul casierului, similarități cu cazuri trecute, comportamentul clientului) și produce un brief de o pagină pentru human reviewer. Asta nu e proiecție – sunt deja implementări pilot care funcționează.

Pentru o echipă care evaluează unde să înceapă cu AI în 2027, detecția anomaliilor rămâne unul dintre cele mai bune cazuri inițiale. Risc tehnic moderat, ROI demonstrabil, scopuri delimitate clar. Cele trei calități pe care orice prim proiect AI trebuie să le aibă.

În practică, anomalii AI a trecut de la subiect de roadmap la prioritate operațională pentru echipele care livrează rezultate de business — exact tipul de tracțiune pe care o vedem reflectată în deciziile reale de buget. Pentru cititorii care lucrează zilnic cu anomalii AI, articolul rămâne deschis pentru update-uri pe măsură ce piața evoluează.

Întrebări frecvente

De ce AI și nu reguli scrise în SQL pentru detecția anomaliilor?

Pentru că „normal” diferă de la context la context: ce e normal pentru un magazin dintr-un centru comercial mare nu e normal pentru unul de cartier. Un model care învață din contextul tranzacției captează toate aceste nuanțe simultan, fără să fie programat explicit pentru fiecare.

Din ce e făcut un astfel de sistem?

Din patru componente: ingestia datelor, feature engineering, modelul propriu-zis și workflow-ul de revizuire. Stratul de revizuire s-a dovedit elementul cel mai important, învățat pe parcurs — fără un om care confirmă sau infirmă, alertele își pierd valoarea.

Cât costă infrastructura unui astfel de sistem?

În cazul descris, 350 EUR pe lună, pentru o companie de 200 de angajați cu echipă tehnică mică. Stack-ul: Python cu scikit-learn și PyTorch, PostgreSQL pentru stocare — Snowflake ar fi fost exagerat pentru volumul real — Prefect pentru orchestrare, MLflow pentru versionarea modelelor, Streamlit pentru interfața de revizuire construită în 3 zile, și Slack pentru alerte agregate zilnic, nu per tranzacție.