El teu agent d'IA no és un empleat. No li deixis les claus de l'empresa

Un assistent d'IA respon. Un agent d'IA actua.

Pot llegir un correu, trobar el client al CRM, consultar documents, crear una incidència, actualitzar un estat, preparar una resposta i, si li ho permetem, enviar-la.

Aquest salt de llegir a fer canvia la pregunta. Ja no n'hi ha prou amb comprovar si l'agent entén la tasca. Cal decidir amb quina identitat entra, què pot veure, quines eines pot utilitzar, quines accions requereixen aprovació i com s'atura si es desvia.

La comparació amb un «empleat digital» pot servir per explicar el concepte, però és perillosa per dissenyar els accessos.

Un agent necessita les seves pròpies claus. I només les que exigeix la seva feina.

El senyal d'aquesta setmana no és hipotètic

Microsoft va publicar el 16 de juliol una guia específica sobre privilegi mínim per a agents d'IA. La recomanació central és tractar-los com a identitats de primer nivell: identitat pròpia, responsable humà, propòsit explícit, permisos limitats per tasca, eines autoritzades i revocació ràpida.

El mateix dia, VentureBeat va publicar una enquesta orientativa a 107 organitzacions de més de 100 empleats que ja treballen amb agents. Un 54% va declarar un incident confirmat o un quasi incident; un 69% compartia credencials en alguna part de la flota; i només un 30% aïllava els agents de risc més alt.

La mostra és petita, autoseleccionada i esbiaixada cap al mercat mitjà. No demostra que els percentatges representin totes les empreses. Sí que mostra un patró: la capacitat dels agents avança més de pressa que els controls d'identitat i aïllament.

No connectis un agent a la feina real amb una identitat prestada i permisos que ningú no ha dissenyat.

La contrasenya prestada esborra tres fronteres

Si un agent funciona amb el compte d'una persona, cada ampliació sembla petita: primer correu, després CRM, després incidències i actualitzacions.

Al cap d'uns mesos desapareixen tres fronteres:

Autoria: el registre diu que va actuar la persona, encara que ho fes l'agent.
Abast: l'agent hereta tot el que pot fer aquell compte, no només el que necessita.
Revocació: aturar-lo pot obligar a canviar credencials que també necessita una persona o altres integracions.

Això dificulta investigar errors, amplia l'impacte possible i converteix una prova ràpida en deute operatiu.

Sis controls abans de donar-li accés

1. Identitat pròpia i responsable

Cada agent de producció ha de tenir una identitat separada, un nom recognoscible, un propòsit escrit i una persona responsable dels canvis i incidents. Els permisos elevats han de ser temporals, no una clau mestra permanent.

2. Permís mínim per tasca

«Accés al CRM» no és prou precís. Pot llegir totes les fitxes? Crear una nota? Canviar una adreça? Exportar o esborrar? Els permisos s'han de modelar per tasca, dades i acció. Lectura i escriptura han d'estar separades.

3. Llista explícita d'eines

L'agent només ha de poder utilitzar eines i accions aprovades. Capacitats aparentment innocents es poden encadenar i crear un flux que ningú no ha avaluat completament.

A més del least privilege, cal least agency: limitar no només quines dades toca, sinó quant pot decidir i encadenar tot sol.

4. Aprovació humana amb informació real

Preparar, sí; comprometre l'empresa, no sense aprovació.

Un agent pot preparar un esborrany, classificar una consulta o reunir proves. Enviar un missatge sensible, canviar dades crítiques, aplicar un descompte, aprovar un pagament, esborrar informació o afectar una persona exigeix una decisió explícita.

5. Registres que expliquin què ha passat

Desar només la resposta final no és traçabilitat. El registre ha d'explicar quin agent va actuar, amb quina identitat i permís, per encàrrec de qui, quina eina va cridar, quin recurs va tocar, què va canviar i quina aprovació va rebre.

6. Un interruptor d'emergència provat

L'empresa ha de poder desactivar la identitat, invalidar tokens, revocar credencials i bloquejar eines sense desmuntar mitja operació. Cal provar aquesta parada abans de producció i preparar com revertir accions habituals.

Exemple: correu de clients connectat al CRM

Un disseny controlat seria:

L'agent té identitat pròpia i responsable.
Només llegeix una bústia concreta i els camps necessaris del CRM.
Pot cercar, resumir, classificar i crear un esborrany.
No pot exportar clients, canviar condicions ni esborrar registres.
Una persona revisa i envia les respostes sensibles.
Cada consulta, font, esborrany, revisió i acció queda correlacionada.
Un interruptor provat invalida el seu accés.

L'error car: obrir-ho tot durant el pilot

Moltes empreses pensen que reduiran permisos «quan el pilot funcioni». Aquest moment gairebé mai no arriba. El pilot es torna útil, s'hi connecta un altre sistema, apareixen excepcions i el compte compartit es converteix en dependència.

Els límits no són la fase final de seguretat. Formen part del disseny funcional perquè obliguen a definir quina feina s'està automatitzant.

La llista de 30 minuts

Té una identitat separada i un responsable amb nom?
El seu propòsit cap en una frase concreta?
Quines dades, recursos i accions necessita exactament?
Quines eines estan permeses i quines denegades?
Què pot preparar sense aprovació?
Quines accions econòmiques, externes, sensibles o destructives exigeixen aprovació?
Els registres permeten reconstruir cada pas?
S'ha provat la revocació d'identitat, tokens i eines?

Si una resposta és vaga, l'agent encara no necessita més autonomia. Necessita un disseny millor.

Conclusió: autonomia amb claus pròpies

Els agents poden aportar valor real perquè connecten informació i accions entre diversos sistemes. Aquesta mateixa capacitat amplia l'impacte d'un error.

La resposta és donar-los identitat pròpia, una feina limitada, eines conegudes, una frontera humana, registres útils i una sortida d'emergència.

La setmana passada vam explicar per què convé fer inventari abans de desplegar agents. El pas següent és decidir quines claus rep cadascun.

El teu agent d'IA no és un empleat. No li deixis les claus de l'empresa.