Una confirmació ben dissenyada evita automatitzacions massa segures d’elles mateixes
Una petició aparentment clara pot amagar una decisió delicada. «Tanca la incidència 842», escriu algú a Teams. Quina 842? La que ja té la reparació validada o la que espera una resposta del client? I si la persona ha copiat un identificador equivocat?
Quan un agent de Copilot Studio consulta informació, l’error sol acabar en una resposta imprecisa. Quan modifica un registre, l’error entra al procés. Per això, les eines que creen, tanquen, assignen o eliminen elements han d’incorporar una parada explícita: l’agent prepara l’acció, l’explica amb dades concretes i espera una confirmació humana abans d’executar-la.
Copilot Studio permet activar Ask the end user before running a cada eina. Aquesta opció està desactivada per defecte, i convé reservar-la per operacions amb efecte persistent: canviar l’estat d’una incidència, crear una comanda, reassignar un responsable o enviar una comunicació externa. (learn.microsoft.com)
Imagineu un agent intern per a manteniment. Una tècnica escriu: «Tanca la INC-842, substituïda la font d’alimentació». L’agent localitza el registre i formula una confirmació útil: «Preparat per marcar INC-842 com a resolta, amb la nota “substituïda la font d’alimentació”. Ho confirmes?». Aquest instant redueix errors d’identificador, evita tancaments prematurs i deixa clar què passarà abans que passi.
Per construir-ho amb criteri, cal preparar quatre peces:
-
Separa lectura i escriptura. Crea una eina de consulta que recuperi l’estat, el client i el resum de la incidència, i una segona eina que només actualitzi el registre. La segona rep l’identificador validat i la nota final; no hauria de cercar lliurement ni decidir quin element toca modificar.
-
Descriu l’eina com un contracte. Un nom com
Actualitza incidènciaés massa ampli. Escriu una descripció precisa: «Marca una incidència existent com a resolta quan l’usuari n’ha confirmat l’identificador i la nota de tancament». L’orquestració generativa utilitza nom, descripció, entrades i sortides per decidir quan invoca una eina. (learn.microsoft.com) -
Activa la confirmació i autentica per usuari. A la configuració de l’eina, marca la petició de confirmació i selecciona credencials de l’usuari final. Així, l’acció s’executa amb els permisos reals de qui la demana; si no pot actualitzar aquella incidència, l’agent tampoc. Si la connexió encara no existeix, Copilot Studio mostra una targeta perquè la persona s’autentiqui i reprèn la crida després. (learn.microsoft.com)
-
Valida les entrades abans de la crida. Imposa un format per a l’identificador, limita els estats admesos i exigeix una nota mínima quan el procés ho requereixi. La confirmació protegeix contra una acció involuntària; la validació protegeix la qualitat del registre.
Hi ha un compromís important. Les credencials del creador simplifiquen una primera demostració, però poden concedir a qualsevol usuari capacitats que no li corresponen. En entorns de producció, l’administració pot restringir aquestes credencials i obligar a usar les de l’usuari final. Les polítiques DLP també poden bloquejar connectors o combinacions de dades que l’agent no hauria de fer circular. (learn.microsoft.com)
La confirmació tampoc substitueix un flux d’aprovació ni una auditoria al sistema origen. Fa una feina més concreta i valuosa: manté la decisió humana just abans del canvi.
Petit repte: tria avui una eina del teu agent que modifiqui dades. Activa-hi la confirmació, prova una petició amb un identificador correcte i una altra d’ambigua, i revisa si el missatge de confirmació permet decidir sense haver d’endevinar res.