O teu axente de IA non é un empregado. Non lle prestes as chaves da empresa

Un asistente de IA responde. Un axente de IA actúa.

Pode ler un correo, atopar o cliente no CRM, consultar documentos, crear unha incidencia, actualizar un estado, preparar unha resposta e, se llo permitimos, enviala.

Ese salto de ler a facer cambia a pregunta. Xa non chega con comprobar se o axente entende a tarefa. Hai que decidir con que identidade entra, que pode ver, que ferramentas pode usar, que accións requiren aprobación e como se detén se se desvía.

A comparación cun «empregado dixital» pode axudar a explicar o concepto. É perigosa para deseñar os accesos.

Un axente necesita as súas propias chaves. E só as que require o seu traballo.

O sinal desta semana non é hipotético

Microsoft publicou o 16 de xullo unha guía específica sobre privilexio mínimo para axentes de IA. A recomendación central é tratalos como identidades de primeiro nivel: identidade propia, responsable humano, propósito explícito, permisos limitados por tarefa, ferramentas autorizadas e revogación rápida.

O mesmo día, VentureBeat publicou unha enquisa orientativa a 107 organizacións de máis de 100 empregados que xa traballan con axentes. O 54% declarou un incidente confirmado ou un case incidente; o 69% compartía credenciais nalgunha parte da frota; e só o 30% illaba os axentes de maior risco.

A mostra é pequena, autoseleccionada e inclinada cara ao mercado medio. Non demostra que esas porcentaxes representen todas as empresas. Si mostra un patrón: a capacidade dos axentes avanza máis rápido ca os controis de identidade e illamento.

Non conectes un axente ao traballo real cunha identidade prestada e permisos que ninguén deseñou.

O contrasinal prestado borra tres fronteiras

Se un axente funciona coa conta dunha persoa, cada ampliación parece pequena: primeiro o correo, despois o CRM, logo incidencias e actualizacións.

Ao cabo duns meses desapareceron tres fronteiras:

Autoría: o rexistro di que actuou a persoa, aínda que o fixese o axente.
Alcance: o axente herda todo o que pode facer esa conta, non só o que necesita.
Revogación: detelo pode obrigar a cambiar credenciais que tamén necesita unha persoa ou outras integracións.

Isto dificulta investigar erros, amplía o impacto posible e converte unha proba rápida en débeda operativa.

Seis controis antes de darlle acceso

1. Identidade propia e responsable

Cada axente de produción debería ter unha identidade separada, un nome recoñecible, un propósito escrito e unha persoa responsable dos cambios e incidentes. Os permisos elevados deben ser temporais, non unha chave mestra permanente.

2. Permiso mínimo por tarefa

«Acceso ao CRM» non é suficientemente preciso. Pode ler todas as fichas? Crear unha nota? Cambiar un enderezo? Exportar ou borrar? Os permisos deben deseñarse por tarefa, datos e acción. Lectura e escritura deben estar separadas.

3. Lista explícita de ferramentas

O axente só debería poder utilizar ferramentas e accións aprobadas. Capacidades aparentemente inocentes pódense encadear e crear un fluxo que ninguén avaliou de principio a fin.

Ademais do least privilege, cómpre least agency: limitar non só os datos que toca, senón canto pode decidir e encadear pola súa conta.

4. Aprobación humana con información real

Preparar, si; comprometer a empresa, non sen aprobación.

Un axente pode preparar un borrador, clasificar unha consulta ou reunir probas. Enviar unha mensaxe sensible, cambiar datos críticos, aplicar un desconto, aprobar un pagamento, borrar información ou afectar unha persoa require unha decisión explícita.

5. Rexistros que expliquen o ocorrido

Gardar só a resposta final non é trazabilidade. O rexistro debe explicar que axente actuou, con que identidade e permiso, por encargo de quen, que ferramenta chamou, que recurso tocou, que cambiou e que aprobación recibiu.

6. Un interruptor de emerxencia probado

A empresa debe poder desactivar a identidade, invalidar tokens, revogar credenciais e bloquear ferramentas sen desmontar media operación. Hai que probar esta parada antes de produción e preparar como reverter accións habituais.

Exemplo: correo de clientes conectado ao CRM

Un deseño controlado sería:

O axente ten identidade propia e responsable.
Só le unha caixa de correo concreta e os campos necesarios do CRM.
Pode buscar, resumir, clasificar e crear un borrador.
Non pode exportar clientes, cambiar condicións nin borrar rexistros.
Unha persoa revisa e envía as respostas sensibles.
Cada consulta, fonte, borrador, revisión e acción queda correlacionada.
Un interruptor probado invalida o seu acceso.

O erro caro: abrilo todo durante o piloto

Moitas empresas pensan que reducirán permisos «cando o piloto funcione». Ese momento case nunca chega. O piloto vólvese útil, conéctase outro sistema, aparecen excepcións e a conta compartida convértese en dependencia.

Os límites non son a fase final da seguridade. Forman parte do deseño funcional porque obrigan a definir que traballo se está automatizando.

A lista de 30 minutos

Ten unha identidade separada e un responsable con nome?
O seu propósito cabe nunha frase concreta?
Que datos, recursos e accións necesita exactamente?
Que ferramentas están permitidas e cales denegadas?
Que pode preparar sen aprobación?
Que accións económicas, externas, sensibles ou destrutivas requiren aprobación?
Os rexistros permiten reconstruír cada paso?
Probouse a revogación de identidade, tokens e ferramentas?

Se unha resposta é vaga, o axente aínda non necesita máis autonomía. Necesita un deseño mellor.

Conclusión: autonomía con chaves propias

Os axentes poden achegar valor real porque conectan información e accións entre varios sistemas. Esa mesma capacidade amplía o impacto dun erro.

A resposta é darlles identidade propia, un traballo limitado, ferramentas coñecidas, unha fronteira humana, rexistros útiles e unha saída de emerxencia.

A semana pasada explicamos por que convén facer inventario antes de despregar axentes. O seguinte paso é decidir que chaves recibe cada un.

O teu axente de IA non é un empregado. Non lle prestes as chaves da empresa.