Toate piesele împreună: arhitectura unui proiect web cu agenți AI

Seria II: De la infrastructură la proiecte agentice în producție. Episodul 20 din 20.

Un portal poate avea infrastructură modernă, agenți de programare și monitorizare, dar să piardă o solicitare între două servicii. Pentru un IMM, arhitectura devine utilă când explică rezultatul, responsabilul și dovada fiecărui pas. Decizia principală: validați un flux complet înainte să extindeți autonomia sau numărul componentelor.

Încheiem seria cu portalul B2B fictiv pentru solicitări și documente. Urmărim o singură funcționalitate: partenerul încarcă un document, primește un identificator, iar un agent pregătește un rezumat pentru verificarea operatorului. Este un scenariu tehnic propus, fără client, rezultate măsurate sau economii pretinse.

Un contract al rezultatului, înainte de tehnologie

Un flux end-to-end, adică de la început până la rezultat, include comportamentul observat de utilizator, nu doar apelul modelului. Considerăm solicitarea acceptată numai după salvarea ei durabilă. Rezumatul trebuie asociat documentului și versiunii corecte; operatorul îl verifică înaintea unei decizii comerciale.

Fixăm de la început limitele: agentul nu aprobă contracte, nu șterge documente și nu trimite automat comunicări externe. Dacă rezumatul nu poate fi produs, solicitarea rămâne vizibilă și poate fi prelucrată manual. O indisponibilitate AI nu trebuie să ascundă cererea clientului.

Saltzer, Reed și Clark explicau în lucrarea academică din 1984 principiul verificării rezultatului la capetele sistemului. Pentru portal, aplicarea propusă este simplă: confirmarea transportului unui mesaj nu demonstrează că rezumatul a fost salvat și verificat.

Două tipuri de agenți, două trasee

Agentul de dezvoltare lucrează asupra codului: primește o sarcină delimitată, folosește regulile repository-ului, depozitul de cod, și propune modificarea. Memoria comună a echipei păstrează decizii de arhitectură și dovezi de testare, nu copii necontrolate ale documentelor partenerilor. Coordonarea previne suprascrierile și atribuie integrarea unui responsabil.

Agentul integrat în portal este o componentă a aplicației în producție. Primește o identitate separată și acces numai la documentele necesare sarcinii curente. Accesul agentului de dezvoltare la cod nu îi conferă acces la datele reale din producție. Aceste limite leagă episoadele despre proiect, instrumente, memorie și identități.

Din cerință într-o versiune instalabilă

Cerința include exemple anonimizate, câmpurile rezumatului și verificări pentru acces între organizații. Evaluăm schimbarea pe aceste cazuri, inclusiv refuzuri și documente incomplete, nu după un singur răspuns convingător.

Fluxul CI/CD, integrarea și livrarea continuă, construiește un artefact, pachetul instalabil al aplicației. Legăm versiunea codului, testele, inventarul dependențelor și proveniența construirii de acest pachet. SLSA 1.2 descrie proveniența ca informație verificabilă despre originea producerii unui artefact. Folosirea unei astfel de dovezi nu certifică automat securitatea aplicației sau corectitudinea răspunsurilor AI.

Propunem testarea pachetului în preproducție, apoi aprobarea umană și instalarea aceluiași pachet. Configurația și secretele mediului rămân separate. Mediile reproductibile și rețelele delimitate susțin fluxul indiferent de amplasarea on-prem, cloud sau hibrid. Nu presupunem că portalul are nevoie de Kubernetes ori de servicii separate pentru fiecare funcție.

Harta minimă a portalului

O arhitectură de referință este o propunere explicată, adaptabilă proiectului, nu o configurație deja validată. Diagrama separă livrarea software-ului de procesarea documentelor. Componentele desenate sunt responsabilități logice; unele pot rula în aceeași aplicație. API este interfața de comunicare dintre componente, iar outbox este registrul evenimentelor de expediat.

Documentele sunt păstrate într-o stocare privată. Baza de date conține solicitarea, versiunea documentului, starea procesării și rezultatul. Numai aplicația autorizată oferă acces la acestea. OWASP recomandă verificarea drepturilor pentru fiecare obiect accesat prin API. Un identificator greu de ghicit nu înlocuiește verificarea.

De la încărcare la rezumat

După validarea documentului încărcat, aplicația salvează solicitarea și evenimentul de procesare în aceeași tranzacție a bazei de date. Tranzacția permite confirmarea împreună sau anularea acestor două scrieri. Nu presupunem că ea include automat și stocarea externă a fișierului.

Un proces separat citește outbox-ul și transmite lucrarea către coada de procesare. Modelul transactional outbox, documentat de AWS, tratează inconsistența dintre scrierea în bază și trimiterea unei notificări. Mesajele pot totuși apărea repetat; consumatorul trebuie să gestioneze duplicatele.

Un worker, proces de fundal, verifică accesul, citește versiunea autorizată și apelează modelul. Validează structura rezultatului și îl salvează cu identificatorul lucrării. Reluarea aceleiași lucrări nu trebuie să creeze rezultate finale duplicate. Interfața afișează starea, iar operatorul verifică rezumatul față de document.

Memoria agentului, contextul trimis modelului și eventualul cache, informația reutilizată, respectă delimitarea organizațiilor. Optimizările din episodul anterior se acceptă numai după măsurarea latenței, consumului și calității acestui traseu. Conținutul public destinat căutării rămâne separat de documentele private.

O eroare simulată care verifică ansamblul

Simulăm oprirea workerului după salvarea rezumatului, înaintea confirmării mesajului. La relivrare, sistemul recunoaște lucrarea deja finalizată și păstrează un singur rezultat. Verificăm această proprietate în aplicație; o coadă declarată fiabilă nu o demonstrează singură.

Apoi simulăm indisponibilitatea modelului. Solicitarea păstrează o stare explicită, cu reluări limitate și posibilitatea prelucrării manuale. Responsabilul operațional decide intervenția. Responsabilitatea operațională înseamnă cine urmărește funcționarea, răspunde incidentelor și poate aplica procedura de recuperare.

Corelăm evenimentele folosind identificatorul solicitării și un trace, urma execuției prin componente. OpenTelemetry oferă instrumentarea pentru semnale precum loguri, metrici și traces; acestea ajută diagnosticul, fără să dovedească automat corectitudinea rezumatului. Evităm documentele integrale și secretele în telemetrie și verificăm filtrarea datelor sensibile.

Testul recuperării folosește copii de siguranță restaurate într-un mediu izolat și verifică legătura dintre cereri, fișiere și rezultate. Revenirea aplicației la o versiune anterioară nu inversează automat modificările bazei de date. Procedura trebuie testată pe starea reală a datelor.

Fișa responsabilităților și acceptarea

Aceasta este fișa propusă pentru funcționalitatea urmărită:

Aceeași persoană poate avea mai multe roluri într-un IMM, dar atribuțiile și înlocuitorul trebuie stabilite. Agentul nu devine aprobatorul propriei lansări.

Acceptăm ansamblul când traseul normal, repetarea, refuzul accesului și recuperarea au dovezi verificabile. Aceasta leagă cele douăzeci de episoade: o arhitectură administrabilă, în care fiecare componentă servește un rezultat, fiecare limită este testată și fiecare intervenție are un responsabil.

Surse

Surse verificate la 20 octombrie 2026. Portalul, diagrama, testele și fișa de responsabilități sunt propuneri tehnice, nu rezultate ale unei implementări sau certificări.

• SLSA 1.2: specificație aprobată
• SLSA 1.2: proveniența artefactelor
• AWS: transactional outbox, duplicate și consistența scrierilor
• OWASP API Security 2023: autorizarea la nivel de obiect
• OpenTelemetry: concepte de observabilitate
• OpenTelemetry: tratarea datelor sensibile
• Saltzer, Reed și Clark: End-to-End Arguments in System Design, ACM TOCS, noiembrie 1984