Tier 3 · Guard & build3.115 min

Medidas de seguridad que puedes establecer

Rows of golden autumn vines below cloud-draped high-country hillsAgents at Work — CC BY 4.0

Si hiciste el curso «Trabajar con Claude», te escribiste cuatro reglas: cómo vas a verificar, qué no vas a pegar, revisar antes de enviarlo y ser siempre quien toma la decisión. Dos de ellas se convirtieron en hábitos: cosas que haces, en el momento, frente al teclado.

Un agente rompe ese acuerdo, y conviene dejar claro cómo. El agente actúa sin supervisión. Tú no estás ante el teclado cuando se ejecuta; no hay momento para que se active un hábito. Así que cada barrera de seguridad que antes tenías en la cabeza ahora tiene que estar integrada en el agente y ser aplicada por la configuración, porque «lo comprobaré en su momento» no es una opción cuando no hay nadie allí en ese momento.

Esa es toda la lección: las mismas cuatro reglas, sacadas de tu cabeza e incorporadas al código.

De los hábitos a las reglas escritas

1. Lo que debe verificar — y cómo señala las dudas. Tu hábito de verificación se convierte en las instrucciones del agente. Indícale, por escrito, que muestre sus pruebas, que diga claramente cuando no esté seguro y que nunca llene un vacío con una suposición segura. Un agente que responde «No he podido encontrar esto — te lo señalo» está haciendo su trabajo; uno que inventa una respuesta plausible para dar la impresión de haber terminado es el peligroso. No puedes verificar en el momento, así que creas un agente que saque a la luz lo que hay que verificar.

2. Lo que nunca debe tocar ni enviar. Tu regla de «lo que no pegaré» se convierte en un límite estricto en la programación, y aquí es donde el principio del «privilegio mínimo» del Nivel 2 se convierte en una norma escrita, no solo en un ajuste. Especifica claramente qué está prohibido: datos personales que no puede reenviar, cuentas en las que no puede escribir, acciones que no puede realizar. En el caso de una persona, «no pegues datos de clientes» es un recordatorio. En el caso de un agente, tiene que ser un muro, porque no hay nadie a quien recordárselo.

3. Detente y espera: la puerta como una regla que no puede traspasar. «Revisar antes de enviarlo» deja de ser algo que te acuerdas de hacer y se convierte en una barrera infranqueable que el agente no puede atravesar. Los verbos vinculantes —enviar, pagar, publicar, rechazar, confirmar— se sitúan al otro lado de una barrera donde el agente se prepara y luego espera a una persona. No es que «normalmente me consulte». No puede seguir adelante sin mí. Configúralo de modo que la opción por defecto sea detenerse, y que seguir adelante requiera la intervención de un humano.

4. Sigue siendo consultivo donde importa. «Sé quien decide» es la regla que subyace a todas las demás, y es el Ancla 3: tú eres responsable de ello. Cuando una decisión tiene peso —dinero, los derechos de alguien, un compromiso por escrito—, el agente presenta las pruebas y una persona decide. Si no pudieras defender un resultado sin decir «lo hizo el agente», la barrera de seguridad no estaría ahí.

Por qué lo escrito y aplicado es mejor que las buenas intenciones

Hay una razón para preferir una regla que el sistema hace cumplir a una que tú pretendes mantener. Una barrera de seguridad por escrito se puede leer, revisar, entregar a quienquiera que ejecute el agente a continuación y —este es el punto de la próxima lección— poner a prueba. Una buena intención no puede ser ninguna de esas cosas. Cuando un agente se ejecuta cien veces mientras duermes, «estaré pendiente de ello» no es una barrera de seguridad; las reglas que has escrito en él y los controles que has creado sí lo son.

Y escríbelas de tal forma que respaldarías cada una de ellas. Si una medida de seguridad es algo que no podrías decir en voz alta a la persona a la que afecta el agente, esa es la señal para cambiar la medida de seguridad, no para ocultarla.

El paso de la implementación

Antes de que un agente se acerque siquiera al trabajo en producción, escribe sus medidas de seguridad de forma clara, en cuatro apartados que puedas defender:

Hazlo lo suficientemente breve como para leerlo en un minuto y lo suficientemente específico como para probarlo. Estos cuatro puntos son el contrato bajo el que opera el agente —y, no por casualidad, son tus propios cuatro pilares convertidos en reglas de desarrollo: aprende lo que hace, mejóralo sobre la marcha, mantén su calidad y asegúrate de que sirva a la persona que está al otro lado.

Piensa en el agente que crearías. Escribe su frase «nunca debe…»: la única acción que, si la llevara a cabo por iniciativa propia, más lamentarías. Ahora bien: ¿es eso actualmente un obstáculo en la configuración, o simplemente algo que esperas que no haga?

Siguiente

Las barreras de seguridad escritas son una afirmación. Las pruebas son la forma de averiguar si se mantienen —y, en el caso de los agentes que interactúan con personas, cómo detectar el sesgo que el diseño por sí solo no puede ver.

Al marcar esta lección como completada, se guarda tu progreso en este dispositivo —sin necesidad de cuenta ni seguimiento—.

Compartido libremente, de buena fe. Si te ha resultado útil, se agradece mucho una contribución de koha para sufragar los costes de desarrollo y funcionamiento.

Deja un koha →

¿Te ha resultado útil? Comparte esta lección con un compañero.