# La confirmación por uso tiene un punto de equilibrio La confirmación por uso solo compensa cuando las llamadas que detiene son lo bastante excepcionales como para merecer otra decisión humana. En cuanto el trabajo rutinario de producción genera un flujo constante de avisos, el control empieza a cobrar al equipo una y otra vez por la misma decisión. El punto de equilibrio suele ser más bajo de lo esperado porque el clic es la parte barata. La espera, leer suficiente contexto para confiar en la solicitud y recuperar el hilo tras la interrupción forman la mayor parte de la factura. Una comparación útil necesita dos cuentas separadas. Una registra el tiempo de los operadores. La otra registra la consecuencia de seguridad de conceder una ventana más amplia. Mezclarlas produce respuestas malas como `doce avisos son molestos` o `producción siempre debe exigir un clic`. Ninguna dice si el aviso cambia una decisión. El modelo siguiente asigna un precio a la interrupción sin fingir que un comando destructivo de base de datos tiene el mismo riesgo que una consulta de estado de solo lectura. ## Calcula el coste completo de una confirmación El coste completo de una confirmación es el tiempo de respuesta más la parte de la recuperación que el aviso causa realmente. Usa segundos, no una valoración vaga como fricción baja. Define estos valores: - `p`: confirmaciones presentadas al día - `t`: mediana de segundos desde que llega el aviso hasta que termina la decisión - `r`: mediana de segundos necesarios para retomar la tarea interrumpida - `q`: fracción de avisos que llegan durante trabajo concentrado - `d`: desarrolladores cuyas cuentas individuales están representadas por `p` Si `p` es una cuenta por desarrollador, el coste diario del equipo es: ```text per_use_seconds = p * d * (t + q * r) ``` Si `p` ya cuenta todas las confirmaciones del equipo, elimina `d`: ```text per_use_seconds = p * (t + q * r) ``` Esta distinción evita el error más frecuente en la hoja de cálculo: tomar un total de avisos de todo el equipo y volver a multiplicarlo por su tamaño. Escribe la unidad junto a cada entrada. `8 prompts/person/day` y `48 prompts/team/day` pueden describir al mismo equipo de seis personas. Usa la mediana para `t` porque unos pocos avisos abandonados pueden deformar la media. Sin embargo, no ocultes esas solicitudes. Cuenta su número por separado como trabajo fallido. Para la recuperación, mide hasta que el desarrollador retoma la anterior acción con sentido, no hasta que se cierra la ventana de aprobación. Si aprueba en nueve segundos y tarda dos minutos en reconstruir una consulta, ha pagado 129 segundos, no nueve. El término `q` evita cobrar recuperación a los avisos atendidos entre tareas. Si todavía no puedes medirlo, calcula un intervalo con `q = 0.5` y `q = 1`. Un intervalo es más honesto que una cifra precisa basada en una suposición. ## Cuenta avisos en el límite que perciben las personas Cuenta cada decisión que una persona debe tomar, no cada solicitud API ni cada notificación que emite el sistema. Una tarjeta que cubre cinco reintentos es una confirmación. Cinco tarjetas causadas por un bucle de reintentos son cinco confirmaciones aunque la operación subyacente sea una sola tarea lógica. El modelo valora trabajo humano, así que la unidad debe coincidir con ese límite. Empieza a contar cuando el aviso se puede atender. Una tarjeta que aparece pero exige abrir un terminal para entenderla ya consume tiempo de respuesta. Incluye denegaciones, avisos caducados y solicitudes duplicadas porque ocupan atención. Registra aparte las llamadas automáticas que nunca preguntan a una persona. Importan para el riesgo y la capacidad, pero no tienen un coste directo de confirmación. La forma de la ráfaga importa aunque el total diario sea igual. Veinte avisos repartidos en diez horas pueden ser tolerables. Los mismos veinte durante un despliegue pueden bloquear a las únicas personas capaces de diagnosticarlo. Conserva un máximo sencillo de confirmaciones en cualquier ventana de 15 minutos. La ecuación diaria estima trabajo; la cifra de ráfaga muestra demora operativa. No trates una alerta enviada a varias personas como varias confirmaciones salvo que varias personas la revisen. Si un aviso de producción se distribuye a cuatro desarrolladores y dos suelen abrirlo antes de que uno apruebe, registra dos respuestas humanas. La entrega de una notificación no marca el coste; la atención sí. Un registro correcto solo necesita unos pocos campos: ```text ts, request_id, responder, decision, shown_at, decided_at, prior_task_resumed_at, key_class 2026-07-21T14:03:10Z, r-1842, dev-3, allow, 14:03:10, 14:03:22, 14:05:01, deploy-read ``` En esa fila, `t` es 12 segundos y la recuperación observada es de 99 segundos. El registro también permite encontrar avisos repetidos para una solicitud, carga desigual y clases de claves costosas sin recoger el secreto ni el contenido solicitado. ## La autorización de sesión cambia el significado La autorización de sesión no elimina la confirmación. Mueve la decisión desde cada uso hasta el comienzo de una ejecución delimitada del agente. La unidad de comparación pasa de llamadas a sesiones. Una aprobación de sesión debe identificar el proceso y terminar cuando ese proceso sale; una aprobación ligada solo a un nombre amable o a una ventana sin final definido es un control distinto y más débil. Define `s` como sesiones nuevas de agente por desarrollador y día, y `a` como la mediana de segundos para revisar y aprobar una sesión. El coste diario del operador es: ```text session_seconds = d * s * a ``` La aritmética favorece pronto a las sesiones porque una decisión puede cubrir muchas llamadas. El débito de seguridad es una autoridad más amplia dentro de la ejecución aprobada. Un proceso comprometido o mal orientado puede hacer otra llamada permitida sin presentar un aviso nuevo. Por eso una comparación de tiempo no puede declarar un ganador universal. Una sesión necesita un final inequívoco. La salida del proceso se entiende bien: la concesión desaparece con el proceso que la recibió. Una ventana fija de ocho horas puede sobrevivir a la tarea, pasar por un relevo y cubrir una acción posterior que nadie consideró al aprobar. Si el sistema no puede revocar una sesión activa ni mostrar qué proceso la posee, valora eso como un defecto del control en vez de fingir que sale gratis. El aviso de sesión también debe dar al responsable identidad suficiente para decidir. Los nombres de ruta y las etiquetas del agente se pueden copiar. La autoridad de firma de código, la identidad del ejecutable y el contexto de inicio aportan pruebas más fuertes sobre qué comenzó. La persona aprueba un principal durante un periodo, no bendice una frase que dice que un agente quiere acceso. ## La ecuación revela el umbral real La confirmación por uso cuesta más tiempo humano cuando sus segundos completos diarios superan el coste de las aprobaciones de sesión. Para una cuenta por desarrollador, iguala las dos ecuaciones: ```text p * d * (t + q * r) = d * s * a p_break_even = (s * a) / (t + q * r) ``` El tamaño del equipo se cancela cuando todos tienen las mismas tasas de avisos y sesiones. Esto no vuelve irrelevante a `d`. Significa que el umbral por persona no cambia al crecer el equipo; el coste total crece en ambos lados. El tamaño vuelve a aparecer si el trabajo está desequilibrado, varias personas revisan el mismo aviso o solo parte del equipo inicia sesiones de agente. Imagina seis desarrolladores. Cada uno inicia dos ejecuciones con acceso a producción al día y una decisión de sesión tarda 15 segundos. Las decisiones por uso tardan una mediana de 12 segundos. El setenta por ciento llega durante trabajo concentrado y la recuperación mediana es de 90 segundos. ```text p_break_even = (2 * 15) / (12 + 0.70 * 90) p_break_even = 30 / 75 p_break_even = 0.4 confirmations per developer per day ``` Con ocho avisos por uso para cada desarrollador, el equipo atiende 48. Su coste completo es: ```text 48 * (12 + 0.70 * 90) = 3,600 seconds = 60 minutes/day ``` Las 12 aprobaciones de sesión cuestan `6 * 2 * 15 = 180 seconds`, tres minutos. La diferencia es de 57 minutos por día de producción. Solo el clic indicaría 9,6 minutos para la aprobación por uso y perdería la mayor parte del coste. El umbral de 0,4 no ordena conceder acceso amplio a todas las sesiones. Dice que los avisos repetidos ya son la forma más cara de aprobar llamadas rutinarias comparables. Conserva decisiones por uso para llamadas cuya consecuencia pueda cambiar con cada ejecución. Mueve trabajo previsible y delimitado a la sesión solo cuando su identidad, duración, canal y revocación hagan aceptable ese alcance. Haz un análisis de sensibilidad antes de actuar. Con las mismas entradas pero sin recuperación, el umbral pasa a `30 / 12 = 2.5` avisos por desarrollador y día. Con tres minutos de recuperación cae por debajo de 0,22. Si la recomendación solo cambia con una estimación inverosímil, la decisión es estable. Si cambia dentro de un intervalo creíble, mide la recuperación en vez de discutirla. ## Un aviso barato aún puede detener la operación El coste laboral y la demora transcurrida responden preguntas distintas. La ecuación suma tiempo humano, pero el agente también espera mientras nadie actúa. Una decisión de 15 segundos puede consumir solo esos 15 segundos y añadir cuatro minutos al despliegue si el aviso permanece 225 segundos sin verse. Sigue ambos valores. El primero muestra cuánto cuesta el control al equipo; el segundo, cuánto cuesta al flujo de producción. Considera un agente que hace una comprobación de despliegue con cinco llamadas: lee el estado, obtiene errores recientes, inspecciona la revisión activa, ejecuta un comando de salud por SSH y registra el resultado. Cada llamada usa una clave configurada para aprobación por uso. La primera tarjeta llega mientras el desarrollador de guardia revisa código. La comprueba y vuelve al cambio. Cuarenta segundos después llega la siguiente llamada, cuando el agente termina de procesar la primera respuesta. El patrón se repite hasta acabar. Los cinco clics pueden sumar solo un minuto. No son una sola interrupción porque los intervalos dejan al desarrollador volver a entrar en la revisión y lo sacan de nuevo. Con 75 segundos de recuperación por interrupción, el coste humano completo llega a 435 segundos: `5 * (12 + 75)`. La demora del agente puede ser mayor porque el trabajo se serializa tras cada aprobación. Ninguna cifra aparece si el panel solo informa la latencia del clic. Supón ahora que la cuarta llamada pide ejecutar el comando de salud contra un host inesperado. El desarrollador la deniega. Esa denegación prueba que un aviso contenía información específica útil. No prueba que las otras cuatro lecturas rutinarias necesitasen decisiones separadas. Un diseño mejor puede autorizar al proceso identificado para las tres lecturas conocidas, conservar aprobación por uso para SSH y rechazar hosts fuera del alcance. El modelo permite esta división porque agrupa costes y denegaciones por clase de clave. El fallo también expone el coste de confirmaciones en serie. Si las llamadas dependen de resultados anteriores, la demora de aprobación queda en el camino crítico. Para llamadas independientes, el agente puede emitir varias juntas y crear una ráfaga que el responsable debe inspeccionar. La ecuación diaria trata de modo parecido el mismo número de decisiones humanas, pero la forma operativa difiere. Registra el tiempo del flujo o la espera del agente cuando importen la velocidad de despliegue y la respuesta a incidentes. No conviertas la espera del agente directamente en dinero de trabajo humano. Un proceso que espera no es una persona trabajando. Informa la espera como demora transcurrida y decide qué perjudica: duración del despliegue, diagnóstico de incidentes, un plazo automático o nada material. Mantener las cuentas separadas evita un total espectacular pero falso. La misma disciplina se aplica a las llamadas denegadas. Una denegación evita la consecuencia de una acción no deseada, que puede superar mucho el coste de interrupción, pero no puedes asignarle un valor monetario creíble sin pruebas. Informa en términos concretos qué detuvo la puerta. `Denied SSH to an unrecognized host` es evidencia de decisión. `La aprobación evitó un incidente grave` es especulación salvo que una investigación lo establezca. Usa el fallo como prueba del diseño. Si retirar cuatro avisos también quita el contexto necesario para detectar el quinto, el alcance de sesión propuesto es demasiado amplio. Si cada llamada usa una clase de clave distinta y la sensible conserva su puerta, los avisos rutinarios añaden coste sin ayudar a esa decisión. La ecuación dice cuándo revisar el diseño; la secuencia de llamadas indica dónde cortarlo. ## La mediana omite colas y trabajo abandonado La mediana describe un aviso atendido típico, pero el trabajo de producción suele fallar en la cola de la distribución. Un aviso que espera al único desarrollador autorizado puede bloquear al agente, al despliegue o a una comprobación mucho más que la mediana. Registra el percentil 90, los avisos caducados y el tiempo hasta la primera respuesta válida junto al valor de la ecuación. No sustituyas sin más la mediana por el percentil 90 en cada cálculo. Cobrarías todos los avisos como si fueran lentos. Usa la mediana para el trabajo ordinario e informa la cola como restricción operativa. Por ejemplo: `42 loaded minutes/day; median decision 11s; p90 decision 96s; 3 expirations/week`. Esa línea dice más que una sola puntuación mezclada. La recuperación también tiene cola. Un aviso mientras alguien lee registros puede costar medio minuto. Si la misma persona mantiene en la memoria una reparación de base de datos aún no ejecutada, puede obligarla a comprobarlo todo. Clasifica la tarea previa en dos o tres grupos como rutinaria, concentrada e incidente. Buscas un límite de política, no un artículo de neurociencia. El trabajo abandonado pertenece a la cuenta. Si un agente agota la espera, reintenta y presenta otra tarjeta, el primer aviso no costó cero porque nadie lo aprobara. Cuenta la atención recibida, la demora del agente y el duplicado si alguien también lo revisa. La fatiga no queda demostrada solo por un número grande. Busca aprobaciones repetidas de la misma clase, menor tiempo de inspección, solicitudes duplicadas y una tasa de denegación cercana a cero en tareas rutinarias. Esas señales indican que la interfaz obliga a reconfirmar una decisión establecida. Una tasa alta de denegación dice que los avisos aún separan llamadas aceptables de las que no lo son, aunque resulten caros. ## Más desarrolladores cambian la coordinación El número de responsables importa porque la distribución rara vez es uniforme. Multiplicar un total del equipo por la plantilla exagera el coste; promediarlo entre todos puede ocultar que dos personas absorben casi todas las interrupciones. Calcula primero minutos completos por persona y luego suma. Informa la mediana y la persona más cargada además del total. Supón que 60 avisos llegan a un grupo de diez, pero el enrutamiento envía 45 a la pareja principal. Un promedio de seis por persona no describe el día de nadie. Los responsables principales pueden necesitar sesiones para llamadas rutinarias aunque el resto apenas note fricción. Rotar el papel distribuye el dolor, pero no reduce el coste total y puede añadir relevo. La distribución múltiple crea otro coste. Cuando un aviso llega a varias personas, una aprobación termina la espera, pero otros quizá ya lo hayan leído. Añade `w`, el número medio de personas que inspecciona cada aviso. La forma para un total de equipo es: ```text per_use_seconds = p * w * (t + q * r) ``` Úsala solo si cada inspección cuesta algo parecido. Si quien aprueba dedica 20 segundos y los demás miran dos, calcula los grupos por separado. El modelo debe ganar algo de detalle cuando lo exige la operación, no porque sobren celdas. El coste de sesión también puede concentrarse. Si solo dos operadores designados inician ejecuciones con producción, usa dos en ese lado, no las diez personas que podrían recibir avisos. Indica la población junto a cada término. La plantilla por sí sola no multiplica el riesgo; importan la distribución de autoridad y la atención real. Aquí también cuenta la propiedad de la cola. Una cola compartida con un responsable de guardia claro reduce inspecciones duplicadas. Difundir cada solicitud a todo el equipo puede acelerar el clic mientras consume en silencio más concentración colectiva. Aprobar rápido y aprobar barato son métricas distintas. ## El riesgo decide qué llamadas siguen por uso El volumen muestra que un control es caro, pero la consecuencia decide si merece la pena. Separa claves o clases de acción según lo que podría hacer otra llamada dentro de la sesión. Inventario de solo lectura, inicio de despliegue, mutación de producción y administración de credenciales no deben heredar un ajuste solo porque los invoque el mismo agente. Se suelen confundir autenticación, autorización y confirmación. La autenticación identifica al proceso o persona. La autorización concede alcance. La confirmación pide a alguien reconsiderar un uso. Repetir confirmaciones no arregla una identidad débil, y una identidad fuerte no vuelve seguro un permiso amplio. Si mezclas las tres, acabas pulsando cada llamada y dando permiso al proceso equivocado. Conserva la confirmación por uso cuando la solicitud incluye hechos que cambian la decisión: host de destino, clase de operación, entorno o recurso afectado. Un comando destructivo contra producción puede merecer revisión incluso con gran volumen. Si aparece cincuenta veces al día y se aprueba sin leer, el diseño ya ha fallado; reduce el volumen de origen o limita la acción en vez de tratar clics rápidos como control. Las sesiones encajan con llamadas repetidas cuando una persona puede decidir una vez sobre el proceso y el alcance. Los buenos candidatos tienen duración delimitada, canal previsible, identidad visible, revocación inmediata y un registro capaz de reconstruir llamadas individuales. La sesión no debe convertirse en un permiso de portador para todo el día entre procesos distintos. Una decisión híbrida suele ser correcta. Coloca lecturas rutinarias de API y comprobaciones conocidas dentro de una sesión ligada al proceso. Mantén aprobación por uso en el pequeño conjunto de claves que puede modificar producción o administrar credenciales. Así baja la interrupción sin quitar la parada deliberada donde una acción cambia el riesgo. No defiendas la confirmación por uso diciendo que más avisos siempre dan más seguridad. Un control aprobado por reflejo tiene mucha ceremonia y poca discriminación. Comprueba si el aviso cambia la decisión con suficiente frecuencia para pagar su coste completo. ## Mide una semana de producción antes de cambiar Una semana suele bastar para sustituir suposiciones por un intervalo creíble si incluye trabajo normal y al menos un periodo de actividad alta. No fabriques un incidente. Exporta eventos, pide a los responsables anotar recuperación en una muestra pequeña y mantén la hoja lo bastante sencilla para terminarla. Usa una fila por responsable y día: ```text date | responder | prompts_seen | prompts_allowed | prompts_denied | median_response_s | focus_share | median_recovery_s | sessions_started | median_session_approval_s 2026-07-21 | dev-3 | 11 | 10 | 1 | 12 | 0.70 | 90 | 2 | 15 ``` Calcula estas celdas: ```text loaded_per_use_min = prompts_seen * (median_response_s + focus_share * median_recovery_s) / 60 session_min = sessions_started * median_session_approval_s / 60 break_even_prompts = sessions_started * median_session_approval_s / (median_response_s + focus_share * median_recovery_s) ``` Después inspecciona por clase de clave. El total indica que hace falta cambiar; el desglose dice qué cambiar. Si el 80 por ciento viene de comprobaciones de solo lectura y las pocas denegaciones afectan a mutaciones de producción, mover todas las claves al mismo modo tiraría la mejor evidencia. Registra un motivo para cada denegación con categorías sencillas: destino incorrecto, operación inesperada, duplicado o contexto insuficiente. Los relatos libres son difíciles de agrupar. La distribución muestra si la puerta detiene solicitudes peligrosas o compensa avisos confusos. Muestrear recuperación no exige vigilar. Pide marcar `0`, `30`, `90` o `180+` segundos para algunos avisos, o infiere el retorno de un rastro local que controla cada persona. Publica el método con el resultado. Una distribución aproximada observada supera una constante inventada con dos decimales. Antes del cambio, escribe la predicción: qué clases desaparecerán, cuántas aprobaciones de sesión las sustituirán y qué puertas seguirán por uso. Mide la semana siguiente con los mismos campos. Si las llamadas suben porque el agente deja de esperar, compara decisiones humanas, no solicitudes API brutas. ## Gasta confirmación donde cambie la decisión El modelo debe producir una ruta por clase, no un umbral global. Para cada clase de clave, compara minutos completos por uso con minutos de sesión y escribe la consecuencia de otra llamada durante una sesión aprobada. Las clases rutinarias con gran diferencia de coste y consecuencia tolerable pueden migrar. Las de alto impacto se quedan por uso aunque su coste sea evidente. Fija una revisión según el comportamiento. Recalcula cuando se duplique el volumen, cambie el grupo responsable, cambie la duración de sesión o se desplacen los motivos de denegación. Un umbral copiado de otro equipo casi no sirve porque la recuperación y la distribución múltiple varían mucho más que el clic. El sistema debe conservar pruebas después del cambio. Registra inicio de sesión, identidad aprobada, revocación y cada llamada. De otro modo, la sesión compra tiempo eliminando el rastro necesario para investigar al agente. Verifica que el historial pueda revelar borrados o alteraciones sin depender del agente que produjo las acciones. Sallyport aplica esta división como una escalera fija: una bóveda bloqueada deniega toda acción, un proceso nuevo recibe una decisión de sesión por defecto y las claves elegidas todavía pueden exigir aprobación en cada uso. Sus diarios Sessions y Activity conservan registros de ejecución y de llamada, por lo que cambiar el alcance no borra acciones individuales. No fijes el umbral en una reunión preguntando cuánto molesta. Introduce siete días de avisos en la ecuación, deja visibles las unidades y separa llamadas rutinarias de aquellas cuyos hechos alteran la decisión. Guarda la hoja original con la decisión para poder discutir las suposiciones. Cuando alguien ha aprobado docenas de veces la misma autoridad delimitada sin denegarla, otra tarjeta idéntica no conserva juicio: lo consume.