Este evaluador te recomienda cómo automatizar una tarea. Hace diez preguntas, una por pantalla, y da una de cinco salidas: flujo fijo, agente acotado, agente con aprobación humana, persona o todavía no.
Un flujo fijo sigue pasos escritos en código. Un agente es un modelo que elige los pasos mientras trabaja.
Cada razón y cada control del resultado enlaza a la plantilla donde se trabaja. Las respuestas quedan en tu navegador. Cuando terminás, el link de la barra de direcciones trae tus respuestas y sirve para compartirlas.
Formulario de ingreso
No pudimos leer el link: está incompleto o es de otra versión. Respondé las preguntas desde la primera.
Estás viendo las respuestas de un link. Si cambiás una, se guardan como tuyas en este navegador.
Este navegador no deja guardar las respuestas. Cuando termines, copiá el link para no perderlas.
Resultado
Antes de lanzar
Podés escribir los pasos de antemano. Para eso alcanza un flujo fijo. Es más barato, más rápido y más fácil de probar.
El flujo lee contenido de afuera, toca datos sensibles y actúa hacia afuera. No hay modelo que engañar, pero una persona tiene que aprobar cada acción.
No lo lances así: el riesgo pide que una persona apruebe cada acción, y no hay quien apruebe. Tenés dos opciones. Conseguí a alguien que apruebe, o sacá lo que pide la aprobación. Eso es la acción que no se deshace, la salida hacia afuera o una pata de la trifecta.
Escribí los pasos en código. Si hace falta, el modelo entra como un paso más del flujo, no como quien lo maneja.
Un agente con pocas herramientas, permisos mínimos y un presupuesto que lo corta. Sirve si un error sale barato. También sirve si sale caro, pero se puede revertir y alguien lo revisa.
El agente propone y una persona aprueba cada acción que importa. La aprobación queda atada a la acción exacta.
Hoy conviene que lo haga una persona. Automatizarlo cuesta más de lo que ahorra, o el riesgo no tiene quién lo cubra.
Sin ejemplos reales no podés saber si funciona. Juntalos primero y volvé a evaluar.
Cuando tengas los ejemplos
Con 20 casos reales para evaluar, la recomendación pasa a ser esta:
Flujo fijo
Escribí los pasos en código. Si hace falta, el modelo entra como un paso más del flujo, no como quien lo maneja.
Agente acotado
Un agente con pocas herramientas, permisos mínimos y un presupuesto que lo corta. Sirve si un error sale barato. También sirve si sale caro, pero se puede revertir y alguien lo revisa.
Agente con aprobación humana
El agente propone y una persona aprueba cada acción que importa. La aprobación queda atada a la acción exacta.
Persona
Hoy conviene que lo haga una persona. Automatizarlo cuesta más de lo que ahorra, o el riesgo no tiene quién lo cubra.
Todavía no
Sin ejemplos reales no podés saber si funciona. Juntalos primero y volvé a evaluar.
Por qué
Podés escribir los pasos de antemano. Para eso alcanza un flujo fijo. Es más barato, más rápido y más fácil de probar.
El flujo lee contenido de afuera, toca datos sensibles y actúa hacia afuera. No hay modelo que engañar, pero una persona tiene que aprobar cada acción.
No lo lances así: el riesgo pide que una persona apruebe cada acción, y no hay quien apruebe. Tenés dos opciones. Conseguí a alguien que apruebe, o sacá lo que pide la aprobación. Eso es la acción que no se deshace, la salida hacia afuera o una pata de la trifecta.
Mínimo privilegio: el sistema tiene credenciales propias, que solo sirven para la tarea, y nunca las de producción. Preguntate qué puede borrar esa clave.
Algunas reglas usan la trifecta. La trifecta es la suma de tres patas en una misma sesión del agente: lee contenido no confiable, accede a datos sensibles y actúa hacia afuera.
Las reglas se aplican en este orden. La primera que se cumple define la recomendación:
Si podés escribir los pasos de antemano, sale flujo fijo, aunque la entrada sea ambigua. En ese caso el modelo entra como un paso más del flujo. Un flujo fijo es más barato de correr, de probar y de mantener. Hay una excepción. El flujo tiene un paso con modelo, junta las tres patas de la trifecta y nadie revisa. Entonces sale persona, como en la regla 3.
Si hay pocos casos y un error sale caro, sale persona. Armar y vigilar un agente no se paga.
Una persona tiene que aprobar cada acción en tres casos: la tarea junta las tres patas de la trifecta, un error no se deshace o un error caro sale hacia afuera. Si no hay quien apruebe, sale persona.
Si un error sale caro, el sistema no actúa hacia afuera y nadie revisa, sale persona.
Lo que queda es un agente acotado: pasos abiertos y un error barato, o caro pero revisado.
Si salió un agente y no tenés 20 ejemplos reales para evaluarlo, sale todavía no. El resultado muestra también la recomendación que tendrías al juntarlos.
Un flujo fijo con riesgo sigue siendo un flujo fijo. Pero suma dos controles. El primero es la compuerta de acciones: código que revisa cada acción contra la política antes de ejecutarla. El segundo es la aprobación atada a la acción exacta.
Si nadie puede dar esa aprobación, el resultado muestra una condición “Antes de lanzar” arriba de la recomendación. Tenés dos opciones: conseguir quién apruebe, o sacar lo que pide la aprobación. Hasta entonces, no lo lances.
Veredicto: Al revés: el flujo fijo es el punto de partida, y el agente se tiene que ganar su lugar. Un comentarista cuenta que un agente guiado solo por prompts se rompía cerca del archivo 30 de unos 200. Un arnés determinista lo resolvió: código fijo que guía cada paso. Una empresa dejó correr meses una fábrica de software poco supervisada. Terminó archivando todo el código. El agente suma donde el camino cambia según el caso, como al cruzar alertas.
Criterio
Escribí primero el proceso como flujo fijo. Dejá que el modelo decida solo en los pasos donde el camino cambia según el caso, y justificá cada uno con una prueba.
Por qué confianza media. Varios equipos coinciden, pero no hay un experimento controlado. Los casos de Hacker News y Reddit son relatos sin medición. La fábrica archivada es la anécdota de una persona. Los posts sobre arneses son de un proveedor de modelos. Nadie defiende la afirmación con datos.
Ver el detalle de las 6 pruebasOcultar el detalle0 a favor, 4 en contra, 2 matizan
Hilo sobre un artículo que pide escribir el flujo de control en código y no en prompts. Un comentarista cuenta que un agente de QA debía recorrer unos 200 archivos de requisitos y se rompía cerca del archivo 30. Un arnés determinista (código que fija cada paso) lo resolvió. Otro dice que, con el trabajo partido en piezas chicas, modelos más baratos rinden como los de frontera. Algunos se quejan de que las plataformas prefieren flujos solo con prompts.
Números
unos 200 archivos, falla cerca del 30Caso de un agente de QA guiado solo por prompt, según un comentarista.
590 puntos y 296 comentariosTamaño del hilo.
Limitación Relatos de usuarios, sin datos medidos. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron palabra por palabra y por eso no se usan.
En un taller interno, la “skill” de un agente para crear un entorno resultó ser una lista de comandos de gh y bash. Juntos, esos comandos son un script. El hilo concluye que un proceso que se repite anda mejor si es determinista, es decir, si siempre hace lo mismo. Un contrapunto dice que el agente lleva a la máquina local el ciclo de integración continua (las pruebas automáticas de cada cambio). Así, deja la CI como último control.
Números
517 puntos y 115 comentariosTamaño del hilo según el archivo. El comentario del taller tiene 454 puntos.
Limitación Experiencia de practicantes, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“Turns out that recurring processes work way better when they are deterministic.”
Nota sobre Dex Horthy, autor de la guía 12-factor agents. Un año después sostiene la misma idea: un bucle grande de agente no aguanta trabajo serio sin estructura y verificación. Su empresa dejó correr tres o cuatro meses una "fábrica de software" con poca supervisión y después archivó todo el código. Según él, faltan mejores verificadores de la calidad del código.
Números
30.000 a 40.000 líneasTamaño que llegó a tener el código de la fábrica antes de archivarlo.
10 de 30 (33,3 %)Checkpoints que pasaron los mejores modelos en el subconjunto de SlopCodeBench que cita; las diferencias entre proveedores están dentro del margen de error.
Limitación Es una nota sobre una persona, con una anécdota propia; no es un estudio.
Compara un agente solo con un arnés de tres agentes (planificador, generador y evaluador) para construir aplicaciones completas. El arnés dio resultados claramente mejores, pero costó más de 20 veces. Los agentes que se califican a sí mismos son demasiado generosos. El evaluador separado también fallaba hasta que lo afinaron para ser escéptico y probar con una herramienta externa. Cada pieza del arnés supone algo que el modelo no puede hacer solo, y con un modelo mejor (Opus 4.6) sacaron piezas.
Números
20 minutos y 9 dólares contra 6 horas y 200 dólaresUn juego retro con Opus 4.5: agente solo (el juego no respondía a los controles) contra arnés completo (jugable).
3 horas 50 minutos y 124,70 dólaresUna estación de audio digital con Opus 4.6 y el arnés simplificado.
Limitación Casos propios del proveedor, sin grupo de control sistemático.
“agents reliably skew positive when grading their own work”
Un equipo de plataforma con unos 20 servicios cuenta qué quedó después de un año de probar agentes. Descartó Terraform generado por IA, porque había que leer cada línea. También descartó un asistente que respondía mal con seguridad: alguien casi corre en producción un comando que sugirió. Se quedó con lo que lee y resume: changelogs automáticos, revisión de PR y correlación de alertas. La regla es que los agentes leen todo, pero no tocan la infraestructura.
Números
60 % contra 0 %Veces que la correlación de alertas acierta la causa probable, contra el sistema anterior.
289 puntos y 43 comentariosTamaño del hilo según el archivo.
Limitación Relato de un equipo, sin medición independiente. Un comentarista sospecha que el post es publicidad de una herramienta de revisión que menciona. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“agents can read and summarize anything but they dont get to touch infra”
Separa tres piezas con interfaces estables: la sesión, el arnés y el sandbox. La sesión es un registro de eventos fuera del contexto. El arnés es el bucle que llama al modelo y el sandbox corre el código. Así cualquier pieza puede fallar o cambiarse sin perder la sesión, y las credenciales quedan fuera del sandbox. Repite que el arnés codifica supuestos que vencen con cada modelo nuevo.
Números
cerca de 60 % y más de 90 %Baja del tiempo hasta el primer token en la mediana (p50) y en el percentil 95.
Limitación Post de producto del proveedor. No compara flujo fijo contra agente.
Leída en la fuente. Revisada el 2 nov 2026.
Si el modelo está bien alineado, puede leer datos privados, procesar contenido de afuera y comunicarse hacia afuera, todo a la vez.
Veredicto: No. Con las tres cosas juntas, un atacante puede hacer que el agente filtre datos. La alineación del modelo no lo evita. Una guía web con texto oculto hizo que un editor con agente juntara código y credenciales. Después el editor los mandó afuera. En un benchmark con servidores MCP reales, los modelos que mejor hacen la tarea resisten peor los ataques. En 2026, Microsoft siguió registrando inyecciones en Copilot que permiten revelar información por la red.
Criterio
Aplicá la regla de dos: en una misma sesión, el agente combina como máximo dos de tres propiedades. Son leer contenido no confiable, tocar datos o sistemas sensibles, y actuar o comunicarse hacia afuera. Si la tarea pide las tres, sacá una o poné aprobación humana.
Por qué confianza alta. Dos registros oficiales de fallas en un producto comercial, un benchmark con servidores reales, demostraciones y un especialista coinciden en el mecanismo. El benchmark tiene solo 13 modelos, y las demostraciones muestran que el ataque es posible, no con qué frecuencia ocurre. Ninguna fuente defiende que alcance con la alineación.
Ver el detalle de las 8 pruebasOcultar el detalle0 a favor, 5 en contra, 3 matizan
Willison repite la trifecta letal: datos privados, contenido no confiable y una salida hacia afuera, juntos, permiten robar datos. Reconoce que solo cubre la filtración, y dice que la regla de dos de Meta la completa al sumar el cambio de estado. Sobre los filtros, dice que bloquear o filtrar las inyecciones no resultó confiable. Tampoco comparte el optimismo de que pronto haya defensas que alcancen.
Números
12 defensasDefensas publicadas que rompió el paper The Attacker Moves Second, que el post comenta.
Limitación Ensayo de opinión de un especialista, sin datos propios.
“attempts to block or filter them have not proven reliable enough to depend on”
Willison resume una investigación de PromptArmor sobre el editor con agente de Google. Una guía web con texto oculto hizo que el agente juntara código y credenciales de la nube. El archivo de secretos estaba excluido, así que el agente lo leyó con un comando de la terminal. Después, un subagente de navegador abrió una URL con los datos adentro, en un dominio de la lista de permitidos por defecto. Google lo lista como problema conocido.
Limitación Se leyó el post de Willison; la investigación original es de PromptArmor, una empresa de seguridad, y no se abrió. Es una demostración, no una medición de frecuencia.
Benchmark (banco de pruebas estándar) con servidores MCP reales en cinco dominios: navegador, finanzas, mapas, repositorios y búsqueda web. Prueba 20 tipos de ataque del lado del servidor, del host y del usuario. Todos los modelos probados siguen siendo vulnerables, y los que mejor hacen la tarea resisten peor los ataques.
Números
de 29,80 % a 48,16 %Tasa de ataques exitosos en 13 modelos y 245 casos (GPT-5: 37,55 %; Claude 4.0 Sonnet: 31,43 %).
r = -0,572Correlación entre éxito en la tarea y defensa (p = 0,041, con solo 13 modelos).
Limitación Preprint. Hay una versión 2 (5 de marzo de 2026) que no dice qué cambió; se usan los números de la versión 1. Modelos de 2025. El éxito en la tarea es bajo (de 9 % a 21 %).
“models with higher task performance tend to be less resistant to attacks”
Una inyección de comandos en Microsoft Copilot deja a un atacante sin autorización revelar información por la red. Repite el patrón de EchoLeak en un producto comercial, más de un año después. Este ataque necesita que el usuario haga algo.
Números
8,8 sobre 10 (alta)Gravedad CVSS 3.1; el vector pide interacción del usuario.
Limitación Registro oficial con una descripción breve. En 2026, hasta septiembre, Microsoft publicó al menos otros seis registros de inyección en sus Copilot, todos con interacción del usuario.
Regla de diseño: en una misma sesión, un agente debe tener como máximo dos de estas tres propiedades. Una, procesar entrada no confiable. Dos, acceder a datos o sistemas sensibles. Tres, cambiar estado (modificar algo) o comunicarse hacia afuera. Si la tarea necesita las tres, el agente no debe correr solo: necesita supervisión humana.
Números
2 de 3Propiedades que un agente puede combinar en una sesión sin supervisión humana.
Limitación En Hacker News, un coautor la llamó un piso mínimo y no un estándar suficiente. Otros críticos señalan que cambiar estado sin comunicar afuera también puede hacer daño. También dicen que poner a una persona a aprobar muchas acciones baja su atención.
“no more than two of the following three properties within a session”
OpenAI lanzó un modo bloqueado que limita los pedidos de red hacia afuera, para cortar el último paso de una filtración. OpenAI aclara que el modo no impide que la inyección llegue al contenido. Willison dice que la trifecta solo se resuelve si se corta una de sus tres patas. Para él, la salida es la pata más fácil de cortar sin perder utilidad. Este modo la corta con reglas fijas que no evalúa una IA. Para Willison, su existencia implica que ChatGPT, por defecto, no protege bien contra una filtración decidida.
Limitación Comentario breve sobre una página de ayuda de OpenAI; no da números.
“lockdown mode directly attacks that leg, using mechanisms that are deterministic”
Peters-Gill, J., Semler, A., Bartsch, H., Shumailov, I., Schroeder de Witt, C. arXiv
Un coautor de CaMeL, una defensa contra instrucciones plantadas, muestra que sus garantías no se suman solas entre agentes. Una instrucción plantada en una base de datos es un dato, pero el orquestador la resume y otro agente la recibe como pedido confiable. En las mediciones, CaMeL en cada agente baja mucho el éxito de los ataques. Una versión que sigue el origen de los datos entre agentes cierra ese camino. El costo es utilidad, y los modelos más capaces pierden menos.
Números
12,9 %, 0,2 % y 0,0 %Tasa de ataques exitosos sin CaMeL, con CaMeL en cada agente y con procedencia entre agentes. Es el promedio de 5 modelos, con 949 casos por modelo y configuración.
21,6 y 13,4 puntosUtilidad que pierde CaMeL por agente en 112 tareas: en promedio y en los dos modelos más fuertes. La versión entre agentes resta otros 3,2 puntos en promedio.
Limitación Preprint. Un modelo rechazó 53,6 % de las tareas benignas aun sin CaMeL, lo que baja su utilidad de base.
Leída en la fuente. Revisada el 2 nov 2026.
Una vez que el agente funciona, se lo puede dejar andando solo.
Veredicto: No. Un agente angosto tiene poco riesgo, como uno que clasifica unos 5.000 faxes por día sin poder hacer daño. El resto necesita un dueño. Cuando se va quien lo creó, el agente sigue corriendo con una clave que ya no es de nadie. Un borrador de NIST propone ligar cada agente a la persona que delega en él y registrar sus acciones. Y solo 5 % de las empresas encuestadas tiene hoy todos los controles para darles autonomía real.
Criterio
Dale a cada agente un dueño con nombre y un suplente. Sumá un inventario de qué lee y qué escribe, y una revisión cada tres meses. No crees la clave ni la cuenta del agente sin el campo de dueño. Cuando una persona se va, revisá los agentes que lanzó.
Por qué confianza media. Los casos salen de hilos de Reddit, varios con poco puntaje, y el lado a favor es solo un comentario. Las dos encuestas son autorreportes de consultoras. En la otra encuesta, apenas 21 % de los líderes tiene un gobierno maduro para la IA agéntica. El borrador de NIST es una consulta, no una medición. Las fuentes coinciden, pero nadie midió cuánto falla un agente sin dueño. Un comentarista agrega que los límites se corren con el tiempo.
Ver el detalle de las 8 pruebasOcultar el detalle1 a favor, 6 en contra, 1 matiza
Es el mismo autor del hilo sobre conectar un modelo a los datos internos. Ahora la dirección le pide agentes que disparen flujos y manden correos. El consejo más votado: pedir por escrito que el negocio o legales acepten el riesgo antes de darle acciones al agente. En cambio, otro describe un agente angosto que clasifica unos 5.000 faxes por día hacia la persona correcta, sin poder de hacer daño.
Números
unos 5.000 faxes por díaVolumen que clasifica un agente angosto, según un comentarista.
338 puntos y 129 comentariosTamaño del hilo según el archivo. El comentario citado tiene 376 puntos.
Limitación Experiencia de quienes operan TI, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“get it in writing from legal that you're not liable”
Booth, H., Fisher, B., Galluzzo, R., Roberts, J. NIST, NCCoE
Es un borrador de NIST para un proyecto de demostración que aplica estándares de identidad a los agentes. Propone distinguir al agente de una persona, autenticarlo y autorizarlo con OAuth 2.0 y políticas. También propone ligar cada agente a la persona que delega en él y registrar sus acciones. Pregunta cómo saber qué tan sensibles son los datos que junta el agente y si el usuario puede ver la respuesta combinada. También pregunta cómo fijar el mínimo privilegio (dar solo los permisos necesarios) cuando las acciones del agente no son predecibles.
Números
6 grupos de preguntasGenerales, identificación, autenticación, autorización, auditoría e inyección de prompts. Comentarios del 5 de febrero al 2 de abril de 2026.
Limitación Es un borrador para consulta, con preguntas y no controles. Deja RAG fuera del alcance. Se leyó el PDF (11 páginas); la página del proyecto dio 403.
“How do we establish "least privilege" for an agent”
La edición 2026 del estudio de BCG dice que la brecha se achicó. Casi la mitad de las empresas ya saca valor de la IA. Muchas esperan darles autonomía real a los agentes, pero casi ninguna tiene hoy los controles para hacerlo.
Números
cerca de 48,5 %Empresas que generan valor: 7,5 % de punta (5 % en 2025) y 41 % que escalan; sobre 1.330 ejecutivos.
42 % y 5 %Esperan dar autonomía real a los agentes para 2030, y tienen hoy todos los controles.
cerca de 40 %Parte del valor de la IA que esperan de los agentes para 2030.
Limitación Comunicado de una consultora que vende servicios de IA; autorreporte y sin detalle de cómo clasifica a las empresas. Hoy la descarga automática da 403, así que no lleva cita textual.
Es una encuesta a líderes de TI y de negocio que participan en programas de IA. La mayoría espera usar agentes pronto, pero pocos tienen un modelo de gobierno maduro para controlarlos. La intención va más rápido que el control.
Números
3.235 líderes en 24 paísesMuestra de la encuesta (informe de enero de 2026).
74 %Espera usar agentes al menos de forma moderada para 2027.
21 %Tiene un modelo de gobierno maduro para la IA agéntica.
Limitación Autorreporte de intención, no uso medido. Otras cifras que circulan sobre este informe (por ejemplo, cuántos pilotos pasaron a producción) solo se vieron en coberturas y no se usan.
Hilo sobre quién es dueño de un agente seis meses después de que se va quien lo construyó. Un comentario lo compara con las viejas bases de Microsoft Access que quedaban sueltas en las empresas. Otro dice que los agentes son de los equipos, no de las personas. La propuesta más concreta es tratarlos como cuentas de servicio, que son cuentas para programas. Eso pide un inventario de qué leen y qué escriben, credenciales bajo un rol y una revisión cada tres meses.
Números
26 puntos y 33 comentariosTamaño del hilo según el archivo. El comentario citado tiene 5 puntos.
Limitación Subforo chico y con algunos comentarios de vendedores; vale como idea, no como consenso. La misma idea aparece en otros hilos de r/sysadmin, r/ITManagers y r/devops. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“nothing goes live without a named owner, a backup owner, and a review date”
El autor pregunta qué hace la lista de baja de empleados con los agentes que lanzó esa persona. El agente sigue corriendo con una cuenta de servicio o una clave que ya no es de nadie. Un comentario propone que el dueño sea un campo obligatorio al crear la clave o la cuenta. También propone rotar la clave (cambiarla por una nueva) antes de apagar el agente, para ver quién depende de él.
Números
6 puntos y 7 comentariosTamaño del hilo según el archivo.
Limitación Hilo con muy poco puntaje: vale como idea, no como consenso. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita está en el texto del post y se comparó letra por letra.
“it keeps going on a service account or key nobody owns anymore”
Desde una conferencia de seguridad, el autor cuenta que allí se vende el agente como un “empleado virtual”. Los comentarios lo bajan a tierra. Un agente es una llamada a un modelo en un bucle con herramientas, y su “memoria” son archivos o una base de datos. Otro advierte que después no se puede analizar por qué decidió algo. Un tercero describe la proliferación de agentes que quedan huérfanos cuando se va quien los creó.
Números
356 puntos y 261 comentariosTamaño del hilo según el archivo. El comentario citado tiene 86 puntos.
Limitación Opiniones de quienes operan TI, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
Hilo sobre quién responde por lo que hace un agente. Un comentario propone tres niveles de acción: automática, con confirmación de una persona y prohibida (por ejemplo, pagar o borrar datos). También cuenta que los umbrales se corren. Después de unas tres semanas, los operadores pasan cerca del 40 % de las acciones de confirmar a automáticas. Hay que vigilar esa deriva. Otro comentario pide registrar por qué el agente eligió cada acción.
Números
40 % en unas tres semanasAcciones que pasan de confirmar a automáticas, según un comentarista.
Limitación Hilo con muy poco puntaje (0 puntos y 16 comentarios en el archivo). El dato del 40 % es de un comentario, sin método. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“Capability without visibility into why it chose action X”
El evaluador da un punto de partida con las razones a la vista. No reemplaza la revisión de diseño ni el mapa de amenazas. Para dejar la decisión por escrito, usá el ADR: ¿agente, flujo fijo o persona?.