Politica AI: ce pot introduce angajații în Claude, pe categorii de date

Tema acestui ghid este politica AI: ce pot introduce angajații în Claude, ce rămâne în afara lui și cine decide când apare un caz nou. Claude este asistentul AI dezvoltat de Anthropic, folosit în firme pentru redactare, rezumate, analiză și, tot mai des, pentru lucru direct cu datele din alte sisteme.

O politică AI este un document scurt, scris pentru angajați, nu pentru juriști. Spune ce instrumente sunt aprobate, ce date pot intra în ele și ce date nu intră niciodată. Mai spune cine aprobă excepțiile, ce se păstrează în jurnal și cine răspunde dacă ceva merge prost.

Majoritatea politicilor pe care le vezi circulând pornesc de la instrument: „folosiți doar Claude” sau „nu folosiți ChatGPT”. Problema este că angajatul nu greșește alegând instrumentul. Greșește când lipește în fereastra de chat un contract, o listă de clienți sau o parolă.

De aceea, structura propusă aici pornește de la date. Împarte informația din firmă în trei categorii:

• Permis: date care pot intra liber în contul de firmă.
• Cu atenție: date care intră doar în anumite condiții, cu reguli clare.
• Interzis: date care nu intră niciodată, indiferent de motiv.

Un om de vânzări, un contabil și un tehnician de suport trebuie să poată decide în zece secunde în ce categorie cade ce au în față. Dacă nu pot, politica e prea abstractă și va fi ocolită.

Folosirea AI fără reguli comune are un cost care se vede târziu. Un exemplu bun vine din Congresul american. Potrivit unui articol Antena 3 CNN care preia Politico, biroul care redactează legile Camerei Reprezentanților primește un val de proiecte generate cu AI, multe pline de greșeli.

O sursă citată spune că biroul pierde mai mult timp reparând textele scrise de AI decât i-ar lua să le scrie de la zero. O greșeală frecventă este trimiterea incorectă la părți din Codul Statelor Unite, adică la culegerea legilor federale. Mai interesant pentru tine este altceva: consilierii legislativi nu au voie să folosească AI disponibil comercial, în timp ce membrii Congresului și grupurile de interese îl folosesc.

Asta înseamnă două reguli diferite în aceeași clădire, fără o regulă comună despre cum se verifică rezultatul. Într-o firmă se întâmplă la fel. Un departament are voie, altul nu, iar nimeni nu verifică ce iese din instrument înainte să ajungă la client.

A doua presiune vine din costuri. Mediafax, citând AP, scrie că tot mai multe organizații își schimbă strategia după luni în care și-au încurajat angajații să folosească AI cât mai intens. O politică scrisă de la început te scutește de o frână bruscă mai târziu.

O politică AI utilă are cinci piese. Fiecare răspunde la o întrebare pe care angajații o pun oricum, doar că fără document o pun colegului de birou.

Cele cinci piese

• Instrumente și conturi aprobate: ce aplicații AI folosești, doar din contul firmei, niciodată din conturi personale.
• Datele: cele trei categorii, cu exemple din munca reală a fiecărui departament.
• Aprobări: cine spune „da” când cineva vrea să introducă date din categoria „cu atenție” sau să conecteze un sistem nou.
• Jurnal: ce se înregistrează, unde și cât timp, ca să poți reconstitui ce s-a întâmplat.
• Răspundere: cine deține politica, cine o actualizează și cine răspunde pentru rezultatul trimis mai departe.

Structura documentului, pe secțiuni

1. Scop, într-un paragraf: de ce există politica.
2. Instrumente aprobate și cum primești acces.
3. Tabelul cu cele trei categorii de date.
4. Reguli de verificare: ce citește un om înainte să trimită.
5. Conectori și integrări: ce sisteme pot fi legate de Claude.
6. Aprobări și excepții, cu un nume la fiecare.
7. Jurnal și incidente: ce faci dacă ai introdus ceva greșit.
8. Revizuire: când se recitește documentul.

Ține documentul scurt. Tabelul de date este partea pe care oamenii o vor deschide cel mai des, deci pune-l sus și printează-l separat.

Tabelul de mai jos este nucleul politicii. Exemplele sunt tipice pentru o firmă de servicii sau distribuție. Înlocuiește-le cu documentele pe care le au oamenii tăi pe birou.

Categoria din mijloc este cea care contează. Dacă o scoți și lași doar „permis” și „interzis”, oamenii vor pune totul la „permis”, pentru că altfel nu își pot face treaba. Categoria „cu atenție” recunoaște că datele despre clienți sunt chiar motivul pentru care firma vrea AI, dar le pune condiții.

Când livrăm la Svennis un sistem pe Claude, scriem acest tabel împreună cu managerul și cu câte un om din fiecare departament, pe documentele lor reale, înainte să deschidem primul cont. Greșeala pe care o vedem cel mai des este o politică ce interzice aproape totul și pe care nimeni nu o mai respectă după prima săptămână.

Ia o firmă de distribuție cu trei echipe care vor să folosească Claude: vânzări, contabilitate și suport. Politica se traduce în câteva setări concrete, pe care le poate face administratorul contului de firmă.

Spații de lucru separate

Fiecare echipă primește propriul spațiu de lucru, numit în documentație workspace. Anthropic arată în Claude Cookbook cum poți folosi Admin API prin client.beta.organization în SDK-ul Python ca să inviți utilizatori, să creezi spații de lucru, să verifici cheile API și să creezi conturi de serviciu. Un cont de serviciu este un cont folosit de o aplicație, nu de un om.

Unde rulează modelul

Pentru agenți construiți pe Managed Agents, același cookbook arată cum fixezi regiunea în care rulează modelul, cu model.inference_geo, și cum lucrezi cu politica de spațiu de lucru allowed_inference_geos. Exemplul din documentație fixează regiunea SUA. Politica ta nu trebuie să intre în detalii tehnice, dar trebuie să spună cine decide regiunea permisă și unde e notată decizia.

Ce vede fiecare echipă

• Vânzări: poate lucra cu oferte și emailuri de la clienți (categoria „cu atenție”), fără liste complete de contacte exportate.
• Contabilitate: poate cere explicații pe structura unui raport, fără CNP-uri și fără date de card.
• Suport: poate redacta răspunsuri pe baza tichetului, iar un om citește răspunsul înainte să plece.

Pentru detaliile de lucru zilnic cu aplicația, vezi ghidul despre cum folosești Claude Cowork în firmă.

Politica de mai sus presupune că omul copiază date în Claude. Tot mai des, însă, Claude citește singur datele dintr-un alt sistem. Aici intră MCP.

MCP, adică Model Context Protocol, este un standard open-source pentru conectarea aplicațiilor AI la sisteme externe. Documentația MCP spune că, prin el, aplicații precum Claude sau ChatGPT se pot conecta la surse de date (fișiere locale, baze de date), la instrumente și la fluxuri de lucru. Un server MCP expune date și instrumente, iar un client MCP este aplicația care se conectează la server.

Pentru politica ta, asta schimbă regula. Nu mai întrebi doar „ce lipește angajatul în chat”, ci „ce poate citi conectorul în numele lui”. Dacă legi Claude de Zoho CRM sau de Zoho Desk, conectorul vede tot ce vede contul cu care a fost autorizat. Dacă acel cont vede și câmpuri din categoria „interzis”, politica scrisă nu te mai protejează.

Adaugă în document trei reguli pentru conectori:

• Orice conector nou se aprobă de responsabilul politicii, nu de utilizator.
• Conectorul folosește un cont cu drepturi minime, doar pe câmpurile necesare.
• Întâi citire, abia apoi scriere, după o perioadă de probă.

Pentru un caz concret din zona financiară, ghidul despre Claude conectat la SmartBill, Saga sau contabilitatea ta arată ce date ajung efectiv la model.

Regulile despre date nu funcționează fără trei lucruri administrative. Sunt plictisitoare, dar ele fac diferența când apare prima problemă.

Aprobări

Pune un nume, nu un departament, la fiecare tip de aprobare. Cineva aprobă accesul nou, cineva aprobă un conector, cineva aprobă o excepție de la tabelul de date. Într-o firmă mică pot fi aceeași persoană. Important este ca angajatul să știe pe cine întreabă.

Jurnal

Jurnalul este lista a ceea ce s-a întâmplat: cine a primit acces, ce conectori există, ce chei API sunt active. Admin API descris în cookbook permite verificarea cheilor API, ceea ce îți dă o bază pentru o verificare lunară. Adaugă și un registru simplu de incidente: cine a introdus ce, când și ce ai făcut după.

Cine răspunde pentru rezultat

Regula cea mai importantă: omul care trimite rezultatul răspunde de el, nu instrumentul. Cazul din Congres arată ce se întâmplă altfel. Textele pleacă mai departe cu trimiteri greșite, iar cineva de la capătul lanțului pierde timp reparându-le. Scrie în politică exact ce verifică omul: cifre, nume, trimiteri la contracte sau la legi, prețuri.

Pune și o regulă de incident: dacă ai introdus din greșeală ceva din categoria „interzis”, anunți responsabilul în aceeași zi. Fără vină, dar fără tăcere.

O politică AI nu vorbește doar despre date. Vorbește și despre cât consumi, pentru că fiecare cerere costă. Modelele lucrează cu tokeni, adică fragmente de cuvinte sau propoziții. Cu cât folosești mai mulți tokeni, cu atât costul crește.

Articolul Mediafax descrie un fenomen numit tokenmaxxing: ideea că un angajat performant este cel care folosește intens AI și consumă cât mai multe resurse. Potrivit aceluiași articol, fenomenul pierde teren. Tot acolo se arată că la unele mari companii costurile cu serviciile AI aproape se dublează la fiecare două luni. Vincent Gusdorf de la Moody's Ratings spune că entuziasmul inițial a dus la folosirea AI inclusiv pentru activități care nu justificau costul.

Pentru o firmă mică, cifrele sunt altele, dar mecanismul e același. Trei reguli ajută:

• Buget pe echipă: cookbook-ul arată cum setezi un buget impus pe o sesiune Managed Agents, cu pauză automată la atingerea limitei și posibilitatea de a-l ridica, coborî sau elimina.
• Model potrivit sarcinii: organizațiile adoptă model routing, sisteme care trimit sarcinile simple la modele mai ieftine și pe cele grele la cele mai performante.
• Lucrări în volum, la costuri mai mici: Message Batches API procesează asincron volume mari de cereri, cu o reducere de cost de 50%, potrivit aceluiași cookbook.

Scrie în politică cine urmărește consumul și cât de des.

Pentru o firmă din România, politica AI este în primul rând un document intern de lucru. Nu înlocuiește analiza juridică și nici obligațiile care vin din legislația europeană și națională. Le face însă aplicabile în munca zilnică, pentru că traduce principii generale în „asta da, asta nu”.

Câteva lucruri practice pentru contextul local:

• Scrie politica în română, cu exemple pe documentele care circulă la tine: facturi, oferte, contracte, tichete de suport.
• Pune CNP-ul explicit în categoria „interzis”. Oamenii îl văd zilnic în documente și nu îl mai percep ca pe o dată sensibilă.
• Leagă politica de documentele interne existente, de exemplu de regulile de confidențialitate pe care angajații le-au semnat deja. Un jurist sau responsabilul cu protecția datelor poate confirma forma potrivită.
• Verifică regiunea și furnizorii înainte de a conecta sisteme cu date despre clienți, și notează decizia în jurnal.

Pentru cadrul legal, pagina despre cadrul legal AI în România strânge legislația și implicațiile, iar textul AI Act în română, adnotat poate fi folosit ca referință când politica ajunge la sisteme mai complexe decât un asistent de redactare.

Dacă firma ta folosește deja Teams sau Microsoft 365, gândește politica pentru locul în care oamenii lucrează efectiv. Ghidul despre un asistent AI în instrumentele pe care le folosești deja arată de ce contează acest lucru.

O politică AI nu are nevoie de luni de lucru. Are nevoie de o săptămână concentrată și de oamenii potriviți în cameră. Planul de mai jos poate fi adaptat la mărimea firmei.

După prima lună, recitește tabelul cu aceleași persoane. Vei găsi documente pe care nu le-ai prevăzut și cazuri care trebuie mutate dintr-o categorie în alta. Asta e normal.

Dacă vrei să vezi mai întâi unde se află firma ta înainte să scrii politica, începe cu evaluarea cât de pregătită este compania ta pentru AI. Îți arată ce date, sisteme și obiceiuri ai deja, iar tabelul cu cele trei categorii se scrie mult mai ușor pornind de acolo.