Modelul AI din automatizarea ta poate fi oprit peste noapte. Cum construiești automatizări care nu cad

Un scenariu care merge de șase luni nu îți dă niciun semn că se va opri. Într-o dimineață, cineva completează formularul de pe site, nodul de AI răspunde cu eroare, restul pașilor nu se mai execută. Afli peste trei zile, de la un client care întreabă de ce nu i-a răspuns nimeni.

Cauza e aproape mereu aceeași. Modelul scris în nod nu mai există, sau nu mai acceptă setările pe care i le trimiți. Aproape tot ce se scrie despre automatizări explică ce construiești. Textul ăsta e despre luna a șaptea.

Foto: Brett Sayles pe Pexels

Ce înseamnă, de fapt, că un model AI a fost oprit?

Înseamnă că numele trimis către API nu mai răspunde. Cererea nu primește un rezultat mai slab, ci eșuează complet. Orice pas care urmează nodului nu se mai execută, iar dacă scenariul nu are tratare de eroare, se oprește în tăcere.

Nu e o ipoteză. În jurnalul de modificări Gemini, la 1 iunie 2026, scrie că gemini-2.0-flash, gemini-2.0-flash-001, gemini-2.0-flash-lite și gemini-2.0-flash-lite-001 sunt oprite. Am arătat un flux complet, cu punctele lui de rupere, în studiul de caz al agentului de leaduri.

Cât de repede se schimbă modelele acum?

Ritmul din 2026 nu mai e de urmărit din curiozitate. În două luni s-au întâmplat o retragere definitivă la Google, o lansare cu depreciere de parametri și o generație nouă la Anthropic. Pentru o firmă cu un scenariu în producție, asta e o problemă de continuitate.

Ce surprinde cel mai des nu e retragerea unui model, ci deprecierea parametrilor. Pe pagina de deprecieri Anthropic scrie că, pe Claude 4.7 și mai nou, o valoare diferită de cea implicită întoarce eroare 400.

Retine: dacă ai setat cândva „temperature 0.7” într-un nod, exact acel câmp îți poate opri scenariul azi, chiar dacă modelul e încă activ.

De ce cade scenariul fără ca nimeni să te anunțe?

Pentru că preavizul ajunge prin email la contul de API, iar acel cont e rareori citit de cine simte problema. Anthropic scrie că anunță clienții afectați prin email și în documentație, cu cel puțin 60 de zile înainte de retragere. Mesajul pleacă, dar rareori ajunge la omul potrivit.

Din ce am văzut la clienți, contul de API e făcut de cel care a construit scenariul. Dacă persoana aia a plecat sau nu mai lucrează cu tine, avertismentul cade într-o cutie poștală pe care nu o mai deschide nimeni. Documentația furnizorului nu spune ce adresă primește notificarea, deci nu poți presupune că e a ta.

Unde scrii numele modelului ca să nu îl cauți prin zece noduri?

Într-un singur loc, niciodată în fiecare nod. O variabilă globală în Make, o variabilă de mediu în n8n, o constantă în cod. Toate nodurile citesc de acolo. Când furnizorul retrage modelul, modifici o valoare și scenariul merge mai departe, în loc să deschizi zece noduri și să speri că nu ai uitat unul.

Aplic aceeași logică la orice construiesc în zona de automatizări AI: o sursă unică de adevăr pentru orice valoare schimbabilă din exterior.

Foto: Field Engineer pe Pexels

Cum afli despre o retragere înainte să te doară?

Îți pui în calendar o verificare lunară de zece minute pe paginile oficiale de deprecieri ale furnizorilor pe care îi folosești. Amândoi publică datele de retragere cu luni înainte, nu după ce opresc modelul, deci informația e acolo dacă te duci după ea. Nimeni nu te sună să ți-o spună.

A treia linie e cea pe care o sare toată lumea. Fără o listă proprie, paginile oficiale nu îți spun nimic, pentru că nu ai cu ce compara.

Ce faci când automatizarea cade și tu dormi?

Pui o ramură de eroare pe fiecare nod de AI, iar ramura trimite un mesaj către un om. WhatsApp, Telegram, SMS, orice citești într-o oră. Un log într-un panou deschis lunar nu e alertă, e arheologie.

Important: alerta trebuie să conțină ce scenariu a căzut și mesajul exact de eroare. „Ceva a eșuat” te obligă să investighezi de la zero.

Al doilea strat e o rută de rezervă. Dacă nodul principal eșuează, datele merg oricum într-un tabel. Lead-ul rămâne al tău, chiar dacă răspunsul automat lipsește. Același principiu e și în CRM-ul pentru cold calling.

Merită să treci pe cel mai nou model imediat ce apare?

Nu, și de obicei nici nu e nevoie. Un model nou se testează pe o copie a scenariului, cu date reale, înainte să atingă producția. Motivele serioase de migrare sunt o dată de retragere anunțată sau o diferență de cost calculată.

Diferența de preț dintre cele două nu e mică. La intrare, gemini-3.6-flash costă de peste trei ori mai puțin decât Claude Opus 5, iar la ieșire raportul se păstrează. Pentru un scenariu care clasifică lead-uri sau rescrie texte scurte, diferența asta se vede în factura lunară.

Cifrele vin din pagina de prețuri Gemini și din anunțul Claude Opus 5. La Gemini, modul batch costă jumătate, util dacă procesezi lucruri fără răspuns pe loc.

De unde începi

Cu un inventar, într-o singură pagină. Scrii fiecare scenariu care folosește AI, ce model are trecut în el și ce parametri i-ai setat manual. Majoritatea descoperă aici că au un model despre care credeau că e altul.

Apoi faci trei mutări. Muți numele modelului într-o variabilă unică. Pui alerta pe eroare care ajunge la telefonul tău. Îți notezi în calendar verificarea lunară. Sunt sub două ore de lucru pentru un sistem care altfel te lasă descoperit exact când nu ai timp.

Dacă ai scenarii în producție și nu știi ce model rulează în ele, scrie-mi printr-o cerere și le trecem prin inventarul de mai sus.