Inteligența artificială începe să schimbe una dintre regulile nescrise ale infrastructurii enterprise: pentru a opera o platformă complexă nu mai este obligatoriu ca utilizatorul să cunoască API-ul din spatele ei. Trecerea de la AI care interoghează datele la AI care poate modifica, în condiții controlate, platforma însăși deschide o nouă etapă în digitalizarea operațiunilor.
În infrastructura IT enterprise există de mult o regulă simplă: dacă vrei să controlezi cine poate modifica o platformă, controlezi cine are acces la API.
Regula are logică. API-urile sunt precise, pot fi securizate și oferă mecanisme de audit. Într-un sistem de producție, aceste caracteristici sunt esențiale.
Problema apare atunci când această barieră tehnică este aplicată unor operațiuni care, deși necesită acces la API, nu sunt neapărat complexe din punct de vedere al businessului.
O echipă de marketing are nevoie de un nou nivel într-un program de loialitate. Un analist de date nu găsește câmpurile necesare pentru o analiză. O campanie este gata de lansare, dar modelul de date trebuie extins.
În scenariul tradițional, se deschide un ticket. Este solicitat un dezvoltator. Urmează o perioadă de așteptare, iar modificarea este făcută atunci când resursele tehnice devin disponibile.
Un astfel de incident nu pare important. Problema este frecvența.
Repetat de zeci sau sute de ori într-un an, procesul devine o taxă invizibilă asupra productivității organizației. Inginerii consumă timp pentru solicitări de rutină, în timp ce echipele de business ajung să considere timpul de așteptare o parte firească a procesului.
API-ul nu este problema. Accesul la API este.
Schema de date a unei platforme precum Optimizely Data Platform (ODP) este o componentă importantă a infrastructurii de date. Ea stabilește modul în care informațiile despre clienți sunt organizate, extinse și relaționate.
Administrarea unei astfel de structuri presupune, în mod tradițional, cunoașterea API-ului.
Din perspectivă inginerească, abordarea este corectă. Din perspectiva utilizatorului de business, însă, apare o discrepanță între complexitatea instrumentului și complexitatea sarcinii.
Crearea unui obiect pentru recompense de loialitate, adăugarea unor câmpuri sau asocierea unui identificator mobil cu un profil de client sunt operațiuni relativ simple conceptual.
Totuși, pentru a le realiza, utilizatorul trebuie să treacă printr-o infrastructură tehnică destinată, în primul rând, dezvoltatorilor.
Aici apare una dintre direcțiile interesante ale evoluției AI în enterprise: interfața conversațională nu mai este folosită doar pentru a obține informații, ci și pentru a executa operațiuni.
De la „arată-mi datele” la „modifică sistemul”
În ultimii ani, conceptul de conversational BI a devenit tot mai prezent în produsele enterprise. Utilizatorii pot interoga datele în limbaj natural, pot solicita rapoarte sau pot identifica anumite tendințe fără a scrie interogări complexe.
Este un progres important, dar nu rezolvă problema fundamentală a administrării platformei.
AI-ul poate răspunde la întrebarea „ce date avem?”, în timp ce modificarea structurii acelor date continuă să necesite intervenția unui specialist.
Următorul pas este ceea ce poate fi numit conversational operations: AI-ul nu doar interpretează și prezintă informația, ci poate acționa asupra sistemului.
Într-un astfel de model, utilizatorul ar putea formula o solicitare precum:
„Creează un obiect pentru recompensele de loialitate cu câmpuri pentru puncte, nivel și statutul de membru și leagă-l de obiectul customers.”
În spatele unei astfel de instrucțiuni se află în continuare API-ul. Diferența este că utilizatorul nu mai trebuie să interacționeze direct cu el.
Un exemplu al acestei abordări este Opal ODP Tools, dezvoltat de SoftServe pentru Optimizely Data Platform.
Sistemul poate interpreta solicitarea, poate construi modificarea necesară și poate prezenta utilizatorului o previzualizare înainte de executare. Sunt afișate inclusiv tipurile de câmpuri și relațiile care urmează să fie create.
Utilizatorul confirmă, iar modificarea este aplicată.
Conceptul este simplu, dar implicațiile sunt semnificative: cunoștințele despre ceea ce trebuie făcut devin mai importante decât cunoștințele despre cum trebuie apelat API-ul.
Cine câștigă?
Schimbarea este relevantă pentru mai multe categorii de utilizatori.
Pentru echipele de marketing, înseamnă mai puține solicitări către departamentul IT pentru modificări de rutină ale modelului de date.
Pentru analiști și data scientists, înseamnă un proces de onboarding mai rapid. În loc să caute documentație sau să întrebe un dezvoltator ce obiecte și câmpuri există, aceștia pot explora modelul de date prin conversație.
Pentru dezvoltatori, beneficiul este poate cel mai evident: dispar o serie de solicitări cu valoare tehnică redusă.
Timpul economisit nu înseamnă doar productivitate individuală. La nivelul unei organizații, reducerea acestor întreruperi poate însemna mai mult timp pentru proiecte strategice și mai puține blocaje între departamente.
Este, în esență, o formă de self-service controlat.
Dar cine răspunde dacă AI-ul greșește?
Aici se află una dintre cele mai importante diferențe dintre un experiment AI și un instrument care poate fi folosit în producție.
Dacă un chatbot oferă un răspuns greșit despre date, consecințele pot fi limitate. Dacă un sistem AI modifică schema unei platforme enterprise în mod greșit, consecințele pot fi mult mai serioase.
De aceea, un mecanism de control trebuie să facă parte din arhitectură, nu să fie adăugat ulterior.
În cazul Opal ODP Tools, operațiunile de creare sunt precedate de o previzualizare și de o etapă explicită de confirmare. Confirmarea este asociată criptografic solicitării inițiale și este valabilă pentru o perioadă limitată.
Dacă solicitarea se schimbă după emiterea confirmării, execuția este respinsă.
Modelul seamănă cu un proces de code review sau cu aprobarea unui pull request: AI-ul poate pregăti modificarea, dar există o barieră clară înainte ca aceasta să ajungă în sistemul de producție.
Este o idee importantă pentru dezvoltarea agenților AI în enterprise: autonomia nu trebuie să însemne lipsa controlului.
De ce contează descrierea instrumentelor
Un alt aspect mai puțin vizibil, dar esențial pentru astfel de sisteme, este calitatea informațiilor pe baza cărora AI-ul ia decizii.
Opal ODP Tools acoperă 11 operațiuni pentru cele patru tipuri principale de entități din ODP: obiecte, câmpuri, relații și identificatori. Sunt disponibile funcții de listare, inspectare și creare, acoperind principalele etape ale administrării schemei.
Fiecare instrument beneficiază de descrieri, exemple și cazuri de utilizare detaliate.
De ce este important?
Pentru că utilizatorii nu folosesc întotdeauna terminologia oficială a unei platforme. Un om poate vorbi despre „tabele”, „dimensiuni” sau „profiluri”, în timp ce platforma operează cu termenul „objects”.
Un sistem conversațional trebuie să înțeleagă intenția, nu doar cuvintele exacte.
În acest punct, proiectarea instrumentelor devine la fel de importantă ca modelul AI propriu-zis.
O schimbare de paradigmă pentru software-ul enterprise
Ceea ce se întâmplă în jurul platformelor de date poate fi privit ca parte a unei schimbări mai ample.
Prima generație de instrumente AI enterprise a făcut mai ușor accesul la informație. Utilizatorul întreabă, sistemul caută și răspunde.
Următoarea generație începe să introducă o dimensiune suplimentară: acțiunea.
Diferența dintre cele două abordări este esențială. Un sistem care doar interoghează platforma oferă acces la informație. Un sistem care poate opera platforma oferă acces la capabilități.
Această distincție va deveni probabil tot mai importantă pe măsură ce agenții AI vor fi integrați în aplicațiile enterprise.
API-ul nu dispare. Devine invizibil.
Este important de precizat că această evoluție nu înseamnă sfârșitul API-urilor și nici dispariția dezvoltatorilor.
API-ul rămâne infrastructura din spatele operațiunilor. Securitatea, permisiunile, auditul și controlul rămân la fel de importante. Se schimbă însă interfața prin care oamenii accesează aceste capabilități.
Pentru un utilizator de business, API-ul poate deveni un detaliu de implementare, la fel cum motorul unei mașini este invizibil pentru șofer.
În acest model, AI-ul devine stratul dintre intenția umană și infrastructura tehnică.
De la ODP la întregul ecosistem enterprise
Optimizely Data Platform este doar un exemplu al acestei probleme. Același model poate apărea în sisteme de management al conținutului, platforme de marketing, CDP-uri, instrumente de analiză sau alte aplicații enterprise cu API-uri complexe.
În fiecare dintre aceste cazuri există utilizatori care înțeleg foarte bine ceea ce trebuie să obțină, dar nu dețin cunoștințele tehnice necesare pentru a modifica platforma.
AI poate deveni stratul care conectează cele două lumi. Nu este vorba doar despre automatizare. Este vorba despre democratizarea accesului la operațiunile platformei, păstrând în același timp mecanismele necesare de control și guvernanță.
Cine va fi operatorul platformei de mâine?
Poate că una dintre cele mai interesante întrebări pentru industria IT nu este dacă AI va înlocui API-urile. Probabil că nu. Întrebarea este cine va putea opera sistemele construite pe baza lor.
Dacă prima etapă a revoluției AI enterprise a fost despre accesul conversațional la informație, următoarea ar putea fi despre accesul conversațional la acțiune. Iar asta schimbă inclusiv definiția utilizatorului unei platforme. În loc ca accesul la infrastructură să fie rezervat celor care cunosc API-ul, platforma poate deveni accesibilă celor care înțeleg problema pe care vor să o rezolve.
Viitorul software-ului enterprise ar putea aparține nu celor care cunosc toate API-urile, ci celor care construiesc stratul suficient de inteligent și de sigur încât utilizatorul să nu mai fie nevoit să le cunoască.
