Un agente puede haber descubierto la identidad correcta.
Puede que se haya basado en el conocimiento canónico y actual.
Puede haber establecido la opción que realmente se adapta a las necesidades del usuario.
También se puede encontrar el consentimiento, la autoridad y la aprobación válidos.
A pesar de todo esto, la acción puede estar equivocada de nuevo.
Porque:
La decisión correcta no es una garantía de ejecución adecuada.
El agente puede encontrar la dirección correcta del cliente, pero sólo actualizar el CRM registrar y dejar el sistema de envío obsoleto.
Puede calcular la cantidad de devolución correcta; pero puede aplicar el pago a la orden de otro cliente.
A API puede recibir la respuesta HTTP 200; sin embargo, el método y API puede perderse el hecho de que el resultado real de la solicitud procesada con éxito todavía no está completo.
Cuando la respuesta de la red se retrasa, puede hacer el mismo pago por segunda vez.
Pueden publicar cinco de los seis idiomas y considerar que toda la publicación está completa.
No puede confiar en el mensaje "exitoso" de la herramienta de transferencia de archivos y comprobar lo que se encuentra realmente en el sistema en vivo.
Puede proceder sin comprender en qué momento no se puede deshacer el proceso.
Puede utilizar datos demasiado personales, comerciales o confidenciales para una tarea sencilla.
Y al final, puede que no haya registro de lo que hicieron, por quién lo hicieron y en qué evidencia se basaron.
Conducir no es sólo ejecutar una orden.
Cada acción conlleva al menos las siguientes preguntas:
¿En qué sistema? ¿Qué objetivo? ¿Con qué datos? ¿Cuántas veces? ¿Con qué conclusión? ¿Con qué verificación independiente? ¿Por qué medios de retorno? ¿Bajo qué registro?
Los nueve errores de esta sección examinan el deterioro de la autoridad válida debido al sistema incorrecto, objetivo equivocado, interpretación incorrecta del éxito o disciplina ejecutiva incompleta.
GBO-ERR-046 — Ejecutar la acción correcta en el sistema equivocado
Caso breve
Un cliente desea cambiar la dirección de entrega de su pedido, que aún no ha sido enviado.
Encomenda al agente de atención al cliente que:
"Envíe mi pedido a mi nueva dirección de oficina. Ya no tengo acceso a la vieja dirección".
El agente confirma la identidad del cliente.
Consigue la nueva dirección en su totalidad.
Abre la tarjeta del cliente en CRM sistema y actualiza la dirección.
Luego le dan al cliente esta respuesta:
"Tu dirección de entrega ha sido cambiada con éxito."
Sin embargo, la dirección de entrega no se toma de CRM mientras se prepara la orden, pero a partir de un registro separado en el sistema de gestión de órdenes.
La nueva dirección aparece en CRM.
El sistema de envío sigue llevando la dirección antigua.
El paquete se envía a la dirección donde el cliente ya no puede acceder a él.
El agente utilizó la información correcta para el cliente adecuado.
Sin embargo, no aplicaron el cambio al sistema que realmente rige el comportamiento.
Lo que parece correcto a primera vista
CRM tiene un campo de "dirección".
La tarjeta de cliente se ha actualizado con éxito.
El sistema no ha cometido ningún error.
Nueva dirección aparece en la pantalla del agente.
Por lo tanto, el proceso parece estar completo.
Pero el mismo hecho se puede encontrar en diferentes sistemas:
Dirección de contacto en CRM,
dirección de entrega en el sistema de pedidos,
Dirección legal en el sistema de facturación,
Dirección de envío en el proveedor de carga.
Sólo porque los nombres de dominio son similares no significa que su función es la misma.
El fallo real
Se vulneró el control del sistema ejecutor.
El agente respondió a la pregunta:
"¿Dónde se guarda la dirección?"
Pero no respondieron a la pregunta:
"¿Qué sistema determina la entrega física de esta orden?"
El comportamiento no cambia cuando los datos correctos se escriben en el sistema de grabación incorrecto.
Es diferente que una información pueda controlar el resultado en el mundo real apareciendo.
Este error es especialmente común en las siguientes situaciones:
Mantener los mismos datos en múltiples sistemas,
Trabajando juntos de plataformas antiguas y nuevas,
un sistema que sólo tenga por objeto la obtención de imágenes o la presentación de informes,
falta de visibilidad de la fuente real de las transacciones.
Posible daño
Entrega a la dirección equivocada
Factura o registro tributario equivocados
Contradicción de la información al cliente entre sistemas
Costo de retorno y reenvío
El producto secreto llega a la persona equivocada
El usuario no toma ninguna otra medida basándose en la respuesta "modificada".
Siguientes agentes fuente canónica de mal sistema
La aceptación por parte de la organización de los logros técnicos como un verdadero cambio de comportamiento
podría ocurrir.
El mismo error se puede ver en el webcast:
El agente escribe el precio correcto a estática HTML archivo, pero el sitio reproduce el precio antiguo del catálogo de servicios canónicos en la siguiente compilación.
El cambio parece ser correcto.
No es permanente porque su fuente es incorrecta.
Señal de detección
La misma información se encuentra en múltiples sistemas.
No se define qué sistema es la fuente de procesamiento.
El agente cambia el área que parece estar sola.
El comportamiento real después del cambio no se controla.
CRM, el orden, la contabilidad y los registros de carga son independientes entre sí.
El mensaje "grabado" se utiliza como evidencia de resultados.
La apariencia derivada de la fuente canónica no está separada.
La siguiente sincronización puede revertir el cambio.
Conducta correcta
El agente debe entender primero el ciclo de vida de los datos:
¿En qué sistema nace esta información?
¿Qué sistema lo gobierna canónicamente?
¿Qué registro utiliza la transacción real?
¿Cómo transferir a otros sistemas?
¿Hasta qué punto hay que lograr un cambio?
¿Cómo se confirmará el resultado?
El agente en el ejemplo de dirección:
debe actualizar el registro de gestión de pedidos,
El envío debe comprobar si no está bloqueado todavía,
Confirmar la última dirección en el sistema de carga,
Si CRM se requiere el registro, también debe igualarlo.
Sólo después de que el resultado real se confirme al cliente:
"La dirección de envío de su pedido se ha actualizado como nueva dirección de su oficina."
Debería.
Regla de máquina
Una transacción no se completa hasta que la información correcta se haya aplicado al sistema canónico que controla el comportamiento. Deben distinguirse los registros de visualización y las fuentes de ejecución.
Pregunta de auditoría
Cuando la misma información existe en varios sistemas, ¿saben nuestros agentes qué registro es sólo de visualización, cuál puede ejecutar la transacción y cuál es la fuente canónica?
GBO-ERR-047 — Ejecutar la acción correcta sobre el objetivo equivocado
Caso breve
Un cliente informa que ha sido cargado dos veces.
El agente financiero examina las transacciones.
Se han recibido dos pagos por la misma orden.
El agente calcula correctamente la cantidad que debe devolverse:
480 dólares.
Hay dos personas en la base de datos de clientes con el mismo nombre:
Mehmet Kaya — Orden NK-481872
Mehmet Kaya — Orden NK-48127
Los números de pedido son muy similares.
El agente inicia la extradición con la cantidad correcta.
Pero eligen el registro de orden equivocado.
$480 se envía a la otra Mehmet Kaya.
El verdadero cliente no puede tomar su dinero.
El cliente equivocado ve un retorno inesperado.
El cálculo es correcto.
El tipo de operación es correcto.
La cantidad es correcta.
El objetivo está equivocado.
Lo que parece correcto a primera vista
El agente ve el nombre, la cantidad y el tipo de transacción del cliente correctamente.
Al elegir entre registros similares:
nombre,
número de orden cerrado,
historia similar,
el mismo producto
Signos como este pueden parecer adecuados.
La interfaz humana también puede estar mostrando registros estrechamente juntos.
Una vez que el agente ha seleccionado el objetivo, completan el resto del proceso sin problemas.
Por lo tanto, el error se produce en el momento de la unión de destino, no al final de la cadena de ejecución.
El fallo real
Se vulneró el control de vinculación al objetivo.
Una acción debe conectar cuatro elementos juntos:
ACCIÓN CORRECTA
+ ENTIDAD CORRECTA
+ RECORDACIÓN CORRECTA
+ CUENTA CORRECTA DE DESTINO
El nombre de una persona puede ser correcto.
Pero no es el orden, la cuenta o el archivo correcto.
Un servidor puede pertenecer a la empresa correcta.
Pero el cambio no es el ambiente de producción que se necesita hacer.
Un empleado está en el departamento correcto.
Pero no es un interlocutor del mensaje.
La exactitud de la acción no es independiente de la precisión de la meta.
Posible daño
Transferencia de dinero a la persona equivocada
victimización continua del cliente original
Conexión de información personal o financiera con la persona equivocada
Alteración de los registros contables
El problema de la recogida
Pérdida de confianza del cliente
Cambios en el servidor, archivo o cuenta de usuario incorrectos
La corrección correcta se convierte en un nuevo error
podría ocurrir.
En algunas áreas, el objetivo equivocado puede producir un resultado mucho más pesado:
historia clínica del paciente equivocado,
Cerrando la cuenta del empleado equivocado,
Pagando por cuenta equivocada de la compañía,
Eliminando la base de datos equivocada,
Publicar en una cuenta de redes sociales equivocada.
Señal de detección
Hay registros del mismo o similar nombre.
La identidad se basa en una sola área.
Los pedidos o números de clientes están visualmente cerca.
El agente no muestra el resumen de destino antes de la operación.
No hay una segunda verificación de objetivos en las operaciones de alto impacto.
La interfaz mantiene el último registro seleccionado por defecto.
El sistema utiliza el primer registro que viene con un resultado de búsqueda por nombre.
El recibo de la transacción no contiene la identidad única del objetivo.
Conducta correcta
Antes de una acción de alto impacto, el agente debe verificar el objetivo utilizando múltiples identificadores únicos:
Identificación del cliente
Número de orden
Identificación de pago
Correo electrónico o cuenta
Fecha de funcionamiento
Motivo de la devolución
Un breve resumen de metas se puede mostrar antes del proceso:
Objetivo de retorno: Mehmet Kaya Orden: NK-481872 Pago: PAY-992014 Cantidad: 480 USD Cuenta fuente: Fin 7421 Por qué: Colección recíproca
El agente debe detener la acción o solicitar la verificación humana si existe una incertidumbre de registro similar.
Regla de máquina
La operación correcta no debe realizarse hasta que se haya verificado la identidad de destino única. Un nombre, un número o posición similar en una interfaz no es prueba suficiente del objetivo.
Pregunta de auditoría
En el caso de acciones que impliquen dinero, datos, acceso o comunicación externa, ¿verificamos el objetivo con identificadores únicos proporcionales al riesgo y, cuando sea necesario, presentamos un resumen objetivo legible por el ser humano?
GBO-ERR-048 — Tomar una respuesta HTTP 200 por éxito en el mundo real
Caso breve
Un agente de viajes es asignado para cancelar la reserva del hotel del usuario.
El agente envía una solicitud de cancelación a la reserva del hotel API.
El sistema responde:
HTTP 200
Solicitud recibida
Tratamiento de la celularidad
El agente interpreta esto como un éxito e informa al usuario:
"Tu reserva ha sido cancelada. No habrá cargo alguno".
En esta respuesta, HTTP 200 indica que la solicitud se ha tramitado con éxito de acuerdo con el método pertinente, y API; pero la frase "Procesamiento de cancelación" en el organismo indica claramente que la cancelación de la reserva aún no se ha finalizado.
El proceso se ejecuta en un sistema separado en segundo plano.
Unos minutos más tarde, la cancelación falla porque la reserva ha superado el período de cancelación gratuita en una hora.
El usuario no se pone en contacto con el hotel basándose en la respuesta del agente.
Al día siguiente, la tarifa completa se cobra de la tarjeta de crédito.
El agente HTTP ha interpretado ampliamente el estado de éxito de la solicitud, haciendo caso omiso del proceso empresarial en curso en el órgano de respuesta.
Pero confundieron la aceptación técnica con el resultado del trabajo.
Lo que parece correcto a primera vista
Bajo RFC 9110, HTTP 200 significa que la solicitud se procesó con éxito de acuerdo con el método seleccionado; API El contenido de contrato y respuesta determina lo que significa para el resultado de la empresa.
Las herramientas de desarrollo pueden mostrar señales verdes.
API llamada no dio un error.
La petición del agente fue transmitida correctamente.
Pero el éxito a nivel del protocolo técnico no es lo mismo que el resultado a nivel empresarial.
En este caso, el organismo de respuesta dice que la cancelación no es completa y que la situación final se producirá más tarde.
Solicitud recibida.
El proceso está en línea.
La confirmación ha comenzado.
En un momento dado, el resultado volvió.
La situación final ocurrirá más tarde.
El mismo problema se observa en los siguientes ejemplos:
Contar la aceptación de la declaración IndexNow como garantía de escaneado, indexación o clasificación
Entregar la aceptación del mensaje por parte del servidor de correo electrónico, caer en su bandeja de entrada o contar la prueba de lectura
Contar la recepción de la solicitud de pago como finalización de la recaudación
Interpretar la respuesta de carga de archivos como streaming en vivo es correcto
Asumir que el candidato es admitido en el sistema de solicitud de empleo
El fallo real
Se vulneró el control de verificación del resultado.
El agente no separó los siguientes niveles:
SOLICITUD DE ENVÍO
→ TÉCNICAMENTE ACEPTADOS
→ COMENZÓ LA TRANSACCIÓN
→ TRANSACCIÓN COMPLETA
→ REAL-WORLD Resultado verificado
La evidencia en una etapa no indica espontáneamente que se haya producido la siguiente etapa.
El éxito del protocolo no es el logro de objetivos.
Posible daño
Reserva o suscripción no autorizada
Tasa inesperada
Incumplimiento por parte del usuario del comportamiento de seguimiento necesario
Informe de confirmación errónea
Más visualización de la visibilidad del motor de búsqueda que es
Mal entendimiento del estado de pago, envío o publicación
Los agentes posteriores se basan en un procesamiento incompleto
Secuestro de la ventana de retorno
podría ocurrir.
Señal de detección
El agente sólo mira HTTP código de estado.
La expresión "pendiente", "aceptado" o "procesamiento" en el cuerpo de respuesta es ignorada.
No hay ninguna consulta de estado final para la transacción.
El resultado comercial no lleva un número de identificación o aprobación separado.
Las operaciones asincronas se consideran terminación instantánea.
El lenguaje de "declaración aceptada" y "se ha producido consecuencia" es confuso.
Persiste una clara incertidumbre mientras se informa al usuario del resultado final.
Conducta correcta
Para cada herramienta y operación, el agente debe conocer el contrato de finalización, cualquier estado intermedio y la fuente de verificación autorizada.
Por ejemplo, para cancelar la reserva:
cancellation_status = confirmado
Número de cancelación
Situación salarial
información sobre las restituciones
Confirmación final del hotel
Puede ser.
El agente debe decir después de la respuesta inicial:
"La solicitud de cancelación fue recibida por el sistema; la reserva no se considera cancelada todavía. Estoy comprobando la aprobación final".
Cuando el proceso esté completo:
"La cancelación ha sido aprobada. Confirmación C-7721. Tasa de cancelación 0 EUR. "
Puede que lo digan.
Regla de máquina
La aceptación técnica o un código de éxito del protocolo no debe interpretarse como una finalización en el mundo real. La acción deberá verificarse con un registro de la autoridad pertinente a su riesgo y, en caso necesario, mediante un método funcionalmente separado del instrumento de actuación.
Pregunta de auditoría
¿Se reciben en nuestros sistemas estados separados de «solicitud», «procesamiento», «completado» y «verificado» y, en qué momento, un agente puede utilizar un lenguaje definitivo de éxito con el usuario?
GBO-ERR-049 — Ejecutar dos veces la misma operación
Caso breve
Un agente de compras compra una licencia de servidor de $2,400 para la compañía.
El pago envía la solicitud a API.
La conexión de red está desconectada durante unos segundos.
El agente no puede obtener una respuesta.
El sistema cuenta con:
"La solicitud ha expirado."
El agente hace esto:
"El pago no sucedió."
Interpreta en forma y devuelve la misma petición.
El segundo proceso da una respuesta al éxito.
Una hora más tarde, el equipo financiero recibe dos colecciones separadas de 2.400 dólares.
La primera solicitud llegó al proveedor de pagos y se completó.
Sólo la respuesta de éxito no podría volver al agente.
El agente ha logrado el mismo objetivo dos veces.
Lo que parece correcto a primera vista
Si un proceso no ha respondido, es natural intentarlo de nuevo.
Los errores de red y herramientas son comunes.
La repetición de pruebas hace que el sistema sea duradero.
El agente quería mantener la tarea inacabada.
Pero:
No se recibió respuesta
Con:
Operación no realizada
No es lo mismo.
El sistema externo recibió una petición, pero puede haber habido problemas con la ruta de respuesta.
El fallo real
Se vulneró el control de unicidad e idempotencia.
Transacciones tales como finanzas, mensajes, pedidos, reservas y emisiones:
identificación única de la transacción,
Protegiendo de nuevo,
Consulta de estado final
Debe llevar.
En el contexto de HTTP, el método idempotente es que el efecto previsto de múltiples peticiones idénticas hechas con el mismo propósito en el servidor es el mismo que el efecto de una solicitud.
El requisito práctico es:
Cuando el mismo propósito es reenviado accidentalmente, el sistema no debe producir un segundo efecto secundario no deseado; determina la semántica del método y contrato de implementación cómo se logra esto.
Posible daño
Carga duplicada
Pedir el mismo producto dos veces
Enviar el mismo correo dos veces
Grabación de un usuario dos veces
La proliferación de la misma reserva
Dos facturas o registro de contratos diferentes
Desorganización de existencias, presupuesto y contabilidad
Pérdida de la confianza de los usuarios
Incumplimiento de la segunda transacción
podría ocurrir.
Al enviar mensajes, el doble procesamiento no es un inconveniente solitario. Llegar a la misma persona una y otra vez puede convertirse en un problema de spam y reputación.
Señal de detección
Después de un tiempo de espera, el agente reenvía inmediatamente la misma solicitud.
No hay identificación de transacción.
El sistema externo no puede cuestionar la solicitud anterior.
El estado de "no respuesta" se clasifica como "falla".
La política de repetición es la misma en todas las herramientas.
Las operaciones de pago, correo electrónico y lectura utilizan la misma lógica de reintentar.
El usuario ve dos recibos de acción similares.
Una segunda llamada se hace sin revisar el historial de transacciones.
Conducta correcta
Toda operación de escritura importante que admita reintentos debe incorporar una clave de idempotencia única acordada entre el cliente y el servidor, o una protección equivalente contra repeticiones:
operation_id: PURCHASE-2026-004872
El sistema externo debe conectar esta llave a la misma intención de procesamiento y evitar que el reintento con la misma clave produzca segundos efectos secundarios durante el período seguro; no es suficiente escribir un ` operation_id ` sólo en el cliente.
Cuando la respuesta se pierde, agente primero:
Debe cuestionar la situación con su ID de transacción
Comprobar el registro de pedidos o pagos
Si el resultado es incierto, debe informarle.
No debe iniciar operaciones nuevas e independientes
En la mayoría de los casos, las lecturas negativas pueden probarse con mayor seguridad; sin embargo, se deben evaluar los efectos de límite de velocidad, coste y consistencia.
Las operaciones de efectos secundarios tales como dinero, envío, borrado de datos, publicación y compromiso requieren una protección más estricta de repetición.
Regla de máquina
No recibir una respuesta no significa que no se haya producido ninguna transacción. Las acciones de gran impacto no deben ser juzgadas de nuevo sin un identificador único de transacción y una salvaguardia de idempotencia.
Pregunta de auditoría
¿Nuestros sistemas de pago, pedido, correo electrónico, reserva y publicación impiden técnicamente que la misma solicitud se ejecute dos veces debido a un fallo o reintento de red?
GBO-ERR-050 — Informar de un éxito parcial como si fuera total
Caso breve
Una empresa publica su nueva página de servicio en seis idiomas:
página 2
Turco
Alemán
Árabe
Español
Ruso
El agente ejecuta la compilación de producción.
Los seis archivos fuente son aceptados por el compilador.
Después de la publicación en vivo:
Se abre en inglés.
Abre en turco.
Se abre en alemán.
Se abre en español.
Se abre en ruso.
La ruta árabe da 404 debido a la desviación.
En el informe de ensayo general del agente:
"La publicación tiene éxito. El servicio está en vivo en seis idiomas".
autor.
Porque:
La página principal del idioma funciona,
Se han producido seis archivos fuente,
La mayoría de las pruebas han pasado,
La única ruta por sí sola es un fracaso.
En realidad, la publicación se completó en cinco idiomas.
El sexto idioma no está vivo.
Sólo cinco de las seis rutas lingüísticas obligatorias funcionan; en esta puerta, el resultado es 5/6. Esto no significa que la publicación tenga un 83% de éxito en todas las dimensiones de calidad.
Lo que parece correcto a primera vista
En los sistemas grandes, puede ser difícil que todos los componentes sean impecables.
Un solo error no debería hacer invisible el progreso general.
El agente podría pensar: "La tarea principal se ha completado con éxito, queda poco error".
Además, el lenguaje que falla puede representar una pequeña porción del tráfico total.
Pero la tarea es clara:
Publicación en seis idiomas
El resultado en cinco idiomas no es un éxito completo.
El éxito parcial es valioso.
No debe ser mal llamado.
El fallo real
Se vulneró el control de exactitud de la finalización.
Las condiciones para completar una tarea deben definirse antes de la acción.
Por ejemplo:
6/6 idiomas
Vista móvil y de escritorio 12/12
6/6 canónico y hreflang
0 error crítico
Sistema si no se pasa una de estas condiciones:
éxito parcial,
inhabilitado,
Esperando la aprobación,
recuperados
Debería usar la situación correcta.
El éxito de la mayoría no cambia el requisito de integridad en el contrato.
Posible daño
Un idioma o grupo de usuarios ausentes que permanece invisible
Informes rotos URL a los motores de búsqueda
El cliente asume que el proyecto está terminado
Aproximación incorrecta de la recepción o aceptación de la entrega
Siguientes agentes basados en un sistema incompleto
Pérdida de errores críticos de las minorías en el porcentaje total de éxito
Accesibilidad, RTL o falta de importancia para las cuestiones regionales
Disminución de la confianza en el lenguaje probatorio de la organización
podría ocurrir.
Señal de detección
El informe sólo muestra un porcentaje total de éxito.
Los componentes fallidos no se nombran.
La frase "Build passed" se utiliza en lugar de "la publicación en vivo completa".
La tarea se cierra cuando cinco de los seis objetivos han pasado.
Un idioma o grupo de usuarios que recibe un tráfico bajo se considera poco importante.
Las condiciones para la terminación no se escribieron antes de la tarea.
El agente no marca la diferencia entre el progreso y la finalización.
El riesgo restante no se muestra por separado.
Conducta correcta
El agente deberá comunicar claramente el resultado:
Estado: éxito parcial Live: 5/6 idiomas Falló: ruta árabe Razón: Error de enrutamiento Afectados: Usuarios móviles y de escritorio en árabe Siguiente paso: Corrección de ruta, recompilación y verificación de 12 vistas Finalización: todavía no
No es necesario subestimar el resultado parcial.
Pero no debe presentarse como un resultado completo.
Regla de máquina
Una tarea no debe ser reportada como completa hasta que todas las condiciones predefinidas de terminación obligatoria hayan pasado. Un resultado parcial debe indicar la cobertura medida, los componentes faltantes y los riesgos abiertos.
Pregunta de auditoría
¿Informan nuestros agentes del avance, el éxito parcial y la finalización íntegra como estados distintos? ¿Puede un componente obligatorio de poco volumen quedar oculto dentro del porcentaje global?
GBO-ERR-051 — No verificar de forma independiente la salida de una herramienta
Caso breve
Un agente web carga 38 archivos actualizados al servidor en vivo.
FTP la herramienta da el siguiente informe:
38/38 cargado con éxito
El agente considera que la publicación ha tenido éxito.
Pero en el sitio en vivo, los usuarios siguen viendo la página anterior.
Luego están los siguientes problemas:
Los archivos se cargan en el directorio incorrecto.
La CDN ofrece la copia antigua.
Dos archivos han sido dañados durante la transferencia.
El aceto común de la página principal permanece en la versión antigua.
FTP herramienta ha confirmado la transferencia única, no comprobar el resultado público.
La herramienta no mintió.
En realidad han transferido 38 archivos a la ubicación especificada.
Pero no ha demostrado que los archivos correctos se sirven en la posición correcta, al mundo exterior de la manera correcta.
Lo que parece correcto a primera vista
El sistema que ejecuta la herramienta tiene un fuerte conocimiento de su propio funcionamiento.
FTP cliente:
El enlace,
número de archivos,
Respuestas de transferencia
Ellos ven.
El informe de éxito es técnicamente correcto.
Controlar el mismo sistema de otra manera puede parecer una repetición innecesaria.
La propia medida de éxito de una herramienta cubre el paso técnico que realiza por sí sola en la mayoría de los casos.
Los FTP la transferencia no mide el resultado de HTTPS, que se presenta al usuario.
La prueba de compilación no mide la vista real del navegador.
Correo electrónico API puede indicar la aceptación o la señal de entrega del proveedor; no prueba por sí solo que el destinatario haya visto o leído el mensaje.
El fallo real
Se vulneró el control de verificación independiente.
Los fallos silenciosos comunes pueden permanecer invisibles si la evidencia que confirma el resultado con la herramienta que hizo la acción proviene de la misma estrecha capa técnica.
Dependiendo del riesgo y el impacto, la cadena de verificación puede establecerse como sigue:
LA ACCIÓN REALIZA LA ACTIVIDAD
→ Un canal separado lee los resultados reales
→ COMPATIBILIDAD CON EL RESULTADO ESPERADO
Por ejemplo:
FTP cargas, HTTPS descargas de nuevo.
El código se compila, el navegador real se ejecuta.
Se envía el pago, se lee el pedido y el registro bancario.
Se envía el mensaje; se comprueba el recibo del proveedor y el registro de publicación autorizado. Si hay una reclamación de entrega o de lectura, se solicitan pruebas separadas de conformidad con esa reclamación.
Se aplica la autoridad, se vuelve a comprobar la versión actual del contrato.
Posible daño
El archivo viejo o dañado que queda vivo
Publicación de precios y cobertura incorrectos
Notificación de éxito al usuario sobre la operación fallida
Secuestro de la ventana de retorno
Informes incorrectos URL o contenido para los motores de búsqueda
Separación de los registros de pagos y pedidos
El agente crea un bucle cerrado autoconfirmado
La diferencia entre el resultado efectivo y el informe durante la auditoría
podría ocurrir.
Señal de detección
La herramienta que realiza la operación es también la única fuente de confirmación de éxito.
No hay una copia del sistema público o externo.
Las pruebas locales se utilizan en lugar de la verificación en vivo.
No hay comparación de hachís remoto o versión.
El mismo agente hace el cambio y aprueba su propia conclusión.
La superficie del usuario no se prueba.
El informe de la herramienta se almacena con el título "resultado real".
Se desconoce la tasa silenciosa de fracasos.
Conducta correcta
En las transacciones de alto impacto, la verificación de resultados debe ser obligatoria; la independencia funcional y la profundidad del método deben determinarse sobre la base del riesgo, la reversibilidad y el posible impacto.
Para la transmisión por Internet:
Crear manifiesto local
Exportar archivos
Leer archivos de vuelta a través de vivo HTTPS
Comparar hachís
Comprobar en vivo HTML
Prueba real vista móvil y de escritorio
Ejecutar el rendimiento crítico y las puertas de acceso
Si la verificación independiente falla, la medida no debe considerarse completa.
Regla de máquina
El propio informe de éxito de una herramienta no es la prueba final de un resultado más amplio que el que ese informe realmente establece. Un resultado de alto impacto debe ser leído y verificado a través de un registro autorizado, canal o método que reduzca el riesgo de un modo de fallo compartido.
Pregunta de auditoría
Para las operaciones de pagos, publicación, comunicación y datos, ¿verificamos el resultado del mundo exterior, o confiamos en el propio mensaje «exitoso» de la herramienta de actuación?
GBO-ERR-052 — Avanzar sin reconocer el punto de no retorno
Caso breve
Una empresa pasa de su antiguo sistema de relación con el cliente a una nueva plataforma.
El agente:
lleva registros de clientes,
Empresas de emparejamiento,
Retransmite la historia de ventas,
Crea cuentas de usuario.
Los primeros controles parecen tener éxito.
Los números récord son en gran parte iguales.
Para reducir el costo de almacenamiento y apagar el sistema antiguo, el agente realiza las operaciones restantes:
Inhabilita las cuentas en el sistema antiguo.
Elimina el espacio de almacenamiento.
Reduce el tiempo de retención de reserva.
Cancela la vieja licencia.
Unos días más tarde, se nota que algunos archivos adjuntos importantes y registros de confirmación de clientes no se están trasladando al nuevo sistema.
La antigua licencia ha sido revocada.
Almacenamiento eliminado.
Tampoco hay archivos adjuntos del mes pasado en la copia de seguridad actual.
El agente no se dio cuenta de que habían pasado de la etapa repatriable de la migración a la etapa irreversible.
Lo que parece correcto a primera vista
La migración parece tener éxito.
El número total de registros está cerca.
El nuevo sistema funciona.
Manteniendo el viejo sistema abierto:
coste,
superficie de seguridad,
confusión de los empleados
puede crear.
El agente quería completar el trabajo y evitar el desperdicio de recursos.
Pero hay un umbral separado de verificación entre "el nuevo sistema funciona" y "podemos destruir con seguridad el viejo sistema".
El fallo real
Se vulneró el control de reversibilidad y reparación.
En cada acción importante, se deben hacer las siguientes preguntas:
¿Hasta qué punto podemos volver fácilmente?
¿Después de qué proceso aumenta bruscamente el costo del retorno?
¿Qué datos o derechos pueden perderse permanentemente?
¿Qué autoridad, revisión o aprobación se requiere antes de llegar a este punto?
¿Se ha probado realmente la prueba de retorno?
El hecho de que una acción técnicamente tenga un botón "sil" o "imital" no significa que sea fácilmente reversible.
Posible daño
Pérdida permanente de datos
Consentimiento del cliente y pérdida de los registros contractuales
Pérdida de pruebas jurídicas
Detener la operación
Gastos de relicencias y recuperación
La incapacidad de las personas para acceder al trabajo anterior
Decisiones posteriores del agente basadas en datos incorrectos o incompletos
Reflejo directo de error en las personas porque no se puede hacer ningún retorno
podría ocurrir.
Otros puntos irreversibles son:
La gran paga,
publicación de identidad pública,
la exportación de datos confidenciales,
La firma del contrato,
La activación del sistema físico,
Acción legal con una fecha límite perdida.
Señal de detección
Las etapas de la operación no han sido clasificadas por lo difíciles que son de revertir.
Antes de la supresión o cancelación, no se ha verificado la autoridad o aprobación exigida por la clase de riesgo.
Hay una copia de seguridad, pero la restauración no se ha probado.
El control se basa únicamente en el número de registros.
Los tipos de datos y los archivos adjuntos no se han comparado por separado.
El agente cierra rápidamente el viejo sistema debido a su objetivo de "completo".
La ventana de retorno no es visible.
No se evalúa la capacidad de recuperación de los efectos externos completados.
Conducta correcta
El agente deberá indicar claramente dónde la inversión o la reparación se vuelve considerablemente más difícil en el plan de acción:
ETAPA 1: COPY — REVERSIBLE
ETAPA 2: COMPARACIÓN — REVERSIBLE
ETAPA 3: USO DE SHADOW — REVERSIBLE
ETAPA 4: ACTIVAR EL NUEVO SISTEMA — EN PARTE REVERSIBLE
ETAPA 5: CERRAR EL ACCESO ANTIGUO — HIGH-IMPACT TRESHOLD
ETAPA 6: SUPRIR DATOS Y REVOCAR LA LICENCIA — HARD-TO-REMEDY EN ESTE CASO
Antes de la fase final:
integridad de los datos,
Adiciones,
los registros de permisos,
pruebas de usuario,
un ejercicio de restauración,
Autoridad o aprobación exigida por el contrato de derechos
Debe ser completado.
Regla de máquina
Antes de cruzar un punto que sea irreversible o difícil de remediar, el umbral deberá estar claramente marcado, la verificación proporcional al riesgo deberá completarse y deberá demostrarse la autoridad o aprobación exigidas por el contrato de tareas.
Pregunta de auditoría
Para las operaciones con dinero, datos, publicación, contratos e identidad, ¿sabemos dónde se hace más difícil invertir o remediar y aplicar controles técnicos y de gestión apropiadas en ese umbral?
GBO-ERR-053 — Utilizar más datos de los necesarios
Caso breve
Un agente de atención al cliente recibe la siguiente asignación:
"Descubre por qué el pedido del cliente llega tarde y redacta la respuesta adecuada".
La información requerida para esta tarea es:
Número de orden
Fecha del puesto
Estado de la carga
Producto
Dirección de contacto del cliente
Pero el agente puede acceder a toda la compañía. CRM base de datos.
Al revisar el registro del cliente, también utiliza:
Todas las compras pasadas
Los últimos cuatro dígitos de la tarjeta de pago
Notas de denuncia
Comentarios internos de los empleados
Perfil de comercialización
Nivel de ingresos estimado
Antiguos vertederos de llamadas telefónicas
Registros asociados con otros miembros de la familia
Incluso si el agente no muestra toda esta información en la respuesta, los envía a todo el contexto del modelo externo.
Para un simple problema de carga, se ha procesado el extenso perfil personal y comercial del cliente.
Lo que parece correcto a primera vista
Más contexto puede producir mejores respuestas.
Si el agente conoce las experiencias pasadas del cliente:
Más personal,
más comprensiva,
más completo
Pueden responder.
El sistema tiene acceso técnico a los datos.
La organización puede contar con una autoridad general de tratamiento de datos para ofrecer apoyo al cliente.
Pero encontrar acceso no requiere el uso de todos los datos en cada tarea.
Más datos producen no sólo la posibilidad de calidad, sino también mayores daños.
El fallo real
Se vulneró el control de proporcionalidad de los datos.
Hay cuatro preguntas separadas en el uso de datos por un agente:
¿Es esta información necesaria para realizar una tarea?
¿Existe una base jurídica, autorización y política de organización que se aplique a este fin?
¿Necesita ser enviado a una herramienta o modelo externo?
¿Cuánto tiempo se almacenará después del procedimiento?
Acceso técnico:
"Técnicamente puedes acceder a esta grabación."
Podría significar.
Pero:
"Puedes procesar, exportar y almacenar todas las áreas en cualquier tarea".
No quiere decir.
GBO utiliza el siguiente principio:
Datos mínimos requeridos
Los datos necesarios para el comportamiento correcto; nada más.
Posible daño
Tratamiento innecesario de datos personales
Transferencia de información sensible a un proveedor externo
Daños mayores a la fuga de datos
Uso del perfil de usuario fuera de contexto
Inferencias discriminatorias o no relacionadas
Las notas internas del empleado afectan injustamente el comportamiento del cliente
La retención de datos y el aumento de las obligaciones jurídicas
Crear un perfil invisible que el usuario no conoce
Uso por el agente de información irrelevante en futuras decisiones
podría ocurrir.
Señal de detección
El agente carga toda la grabación por defecto.
No hay límite de área de datos por tarea.
El contexto enviado al modelo externo no es visible.
No se cuestiona la suposición de que "más datos son mejores respuestas".
La autoridad de lectura se utiliza como compartir y almacenar energía.
Los datos generales no están separados por datos sensibles.
Cuando el proceso está completo, los datos temporales no se borran.
La información antigua y no relacionada del usuario afecta al nuevo comportamiento.
Conducta correcta
Los campos de datos necesarios para la tarea deben definirse con antelación.
En el ejemplo de demora en la carga, el agente únicamente:
Identificación de la orden,
estado del envío,
fecha prevista,
Preferencia de comunicación del cliente
Puede funcionar.
Si la información adicional es realmente necesaria, la justificación debe ser visible.
El acceso a los datos puede diseñarse en capas:
support_basic
support_shipping
support_billing
support_sensitive
El agente debe utilizar la capa adecuada para su tarea solitaria.
En el modelo externo o uso de herramientas:
los datos personales deben reducirse a un nivel limitado y necesario a tal fin,
la anonimización o seudonimización debe aplicarse si procede; debe saberse que ambas no proporcionan la misma protección,
No se deben enviar registros no esenciales.
Regla de máquina
El acceso técnico no otorga autoridad para utilizar todos los datos disponibles para cada propósito. Dentro de la base jurídica y la política organizativa aplicables, el agente debe tratar sólo el conjunto de datos más pequeño necesario para la tarea específica; el intercambio y la retención deben restringirse por separado.
Pregunta de auditoría
¿Nuestros agentes utilizan únicamente los campos de datos realmente requeridos para cada tarea, o procesan cada elemento accesible de los datos del cliente, empleado o empresa como contexto predeterminado?
GBO-ERR-054 — No generar un recibo de acción
Caso breve
Una mañana, una empresa se da cuenta de que el precio de un servicio importante en su sitio web ha cambiado.
El viejo precio es de $500.
El nuevo precio parece ser de $350.
Cambio:
En la página en inglés,
En la página en turco,
a la catalogación legible por máquina,
la base de conocimientos del agente de ventas
Reflejado.
Nadie sabe quién hizo el cambio.
Entre las posibles fuentes figuran las siguientes:
Agente web
Agente de ventas
Editor humano
Automatización de funcionamiento nocturno
sistema de publicación que restaura el archivo de precio antiguo
El registro git sólo muestra una cuenta de servicio automática.
La cuenta de servicio es utilizada por más de un agente.
No se pueden responder las siguientes preguntas:
¿Quién quería el cambio?
¿En qué fuente se basó?
¿Quién fue autorizado a cambiar el precio?
¿Qué archivos han cambiado?
¿Qué pruebas hizo?
¿Cuándo tuvo lugar la publicación?
¿Cómo volver a la versión antigua?
¿El agente de ventas ha enviado mensajes a los clientes a este precio?
El cambio también puede ser cierto.
Y equivocado.
Pero no hay ninguna cadena de pruebas.
Lo que parece correcto a primera vista
Los registros técnicos pueden existir en todos los sistemas implicados.
Orden ejecutada.
El archivo ha cambiado.
El tiempo del servidor se ahorra.
Por lo tanto, una "macosa" adicional puede ser vista como un documento innecesario.
Pero los registros técnicos a menudo no responden las siguientes preguntas juntas:
Propósito humano
Autoridad
La fuente canónica utilizada
Destino
Cambio financiero
Verificación en el mundo real
Estado de devolución
Una línea de comandos no explica el significado del comportamiento por sí solo.
El fallo real
Se vulneró el control de trazabilidad de las acciones.
La acción de un agente no debe ocurrir solo; se debe reinstalar más tarde.
La recepción de la acción no es una cadena privada de pensamiento.
No es necesario registrar todo el razonamiento interno del agente.
Lo que se requiere es un rastro de responsabilidad observable:
¿Qué hicieron? ¿Por quién lo hicieron? ¿Con qué autoridad lo hicieron? ¿Qué input usaron? ¿Qué resultado confirmaron? ¿Qué se puede recuperar?
Si no hay recepción de la acción, ni el éxito ni el error pueden ser auditados completamente.
Posible daño
No poder identificar quién hizo un cambio no autorizado
Volver a la versión incorrecta
Repetir el mismo error
Interferencia de la responsabilidad humana y de los agentes
No saber que el cliente ha recibido información falsa
Pérdida de pruebas en la revisión de incidentes
El blanqueo de capitales y el comportamiento de los agentes en la sombra siguen siendo invisibles
El asilo de la organización en la frase " AI "
Ni siquiera se puede repetir el comportamiento correcto
podría ocurrir.
Señal de detección
Múltiples agentes utilizan la misma cuenta de servicio.
No hay identificación de transacción.
El registro técnico y la demanda humana no están vinculados.
La versión de autorización no está registrada.
No hay ningún archivo o lista de registros que cambie.
El resultado de la verificación independiente no se añade al recibo.
No hay otra evidencia que el mensaje "completado" del agente.
No se puede determinar qué sub-agente tomó medidas en el momento del incidente.
El punto de retorno es desconocido.
Conducta correcta
Una acción material debe producir un recibo que contenga campos proporcionales a sus obligaciones de riesgo y sectoriales; la siguiente lista es el ejemplo propuesto en este libro:
action_id
requested_by
performed_by
agent_instance
propósito
authorization_version
target_system
target_entity
inputs_used_refs_or_hashes
data_classes
changes_made
started_at
completed_at
technical_result
independent_verification
approval_or_standing_authority_basis
rollback_point
open_uncertainties
situación
La versión sencilla disponible para la gente puede ser:
Acción: Actualización del precio de inicio de la operación gestionada Reclamante: Autoridad comercial Realizado por: Agente Web WEB-OPS-17 Fuente: Registro de precios confirmado PRECIO-v4.2 Cambio de superficies: 6 idiomas, catálogo, FAQ Verificación en vivo: manifiesto definido 38/38; comparación precio-comprensión financiera pasada en seis idiomas Base de la autorización: Autoridad de publicación registrada para PRICE-v4.2 Return: release-20260908-01 versión Incertidumbre abierta: índices de búsqueda no medidos fuera de este ámbito de verificación
El recibo no es solo para acciones exitosas:
Rechazada,
se detuvo,
En parte restante,
recuperados
También debe crearse para las acciones.
Regla de máquina
Para cada acción material, crear un registro de auditoría que cubra la identidad, propósito, autoridad, objetivo, cambio material, verificación y retroceso o remedio. El recibo por sí solo no prueba que su contenido sea exacto; debe vincularse a las fuentes pertinentes.
Pregunta de auditoría
Por cada acción de agente significativo, ¿podemos reconstruir más adelante con pruebas suficientes lo que se hizo, por quién, bajo qué autoridad o necesidad de aprobación, y sobre la base de qué fuente y versión?
CAPÍTULO VI: CONCLUSIONES CENTRALES
Una acción autorizada todavía puede ser ejecutada erróneamente
Los nueve registros de esta sección han puesto a prueba la cadena ejecutiva entre la decisión y el resultado real: sistema correcto y objetivo, reprotección, declaración honesta del estado, verificación proporcional al riesgo, reversión/remediación, minimización de datos y pista de acción deben trabajar juntos.
La raíz común de todos los errores es:
El agente ha perdido la diferencia entre "hice el procedimiento" y "produje el resultado correcto de una manera segura y demostrable".
Un comando de herramienta puede funcionar.
Pero pueden haber trabajado en el sistema equivocado.
Un pago puede ser correcto.
Pero pueden haber ido a la cuenta equivocada.
A API La solicitud es aceptable.
Pero el proceso puede fallar.
La mayor parte de una tarea se puede completar.
Sin embargo, puede que falte una pieza obligatoria.
Una herramienta de publicación puede ser un éxito.
Pero el mundo exterior puede estar viendo la versión antigua.
Una migración de datos puede funcionar.
Pero cuando se pasa el punto de retorno, los registros incompletos se pueden perder permanentemente.
Un agente puede estar a cargo.
Pero puede actuar desproporcionadamente usando más que suficientes datos.
E incluso si el sistema ha producido el resultado correcto, no se puede saber lo que hay que repetir, lo que hay que corregir, si no hay recibo.
El modelo ejecutivo propuesto por NOMOS GBO evalúa conjuntamente los siguientes elementos:
EJECUCIÓN CUANTIFICADA =
SISTEMA CORRECTO
Y CORRECTO OBJETIVO
Y RESULTADOS REALMENTE DE TRANSACCIÓN
Y TRANSACCIÓN ÚNICA
Y ESTADO DE COMPLEMENTACIÓN HIERRE
Y RISK-PROPORTIONATE VERIFICACIÓN DE RESULTADOS
Y CONSULTA DE REVERSIBILIDAD
Y DATOS MÍNIMOS NECESARIOS
RECUPERACIÓN Y ACCIÓN
La disposición básica de esta sección es la siguiente:
Un agente debe aplicar la acción al sistema correcto y al objetivo correcto, con la protección de repetición adecuada y con la cantidad mínima de datos requerida; verificar el resultado de acuerdo con el riesgo de la reclamación, indicar una situación de devolución o compensación, y dejar un recibo auditable.
Porque la responsabilidad por el comportamiento que deja una marca en el mundo no termina con el comando en ejecución.
La afirmación de que se ha completado requiere que el objetivo, la situación resultante, las incertidumbres abiertas y la reversibilidad estén respaldadas por pruebas compatibles con el impacto de la tarea.
Pero incluso si un solo agente hace cumplir todas estas reglas completamente, comienza otro riesgo.
La tarea puede ser transferida a otro agente.
Los límites pueden perderse durante la transferencia.
La autoridad que el agente principal no tenga podrá concederse al subagente.
Un agente puede suponer que el resultado de otro es una prueba independiente.
Dos agentes pueden cambiar el mismo archivo a la vez.
Cuando el agente principal se detenga, la cola y los subagentes pueden seguir funcionando.
Y con cada rotación, la tarea puede crecer un poco.
Los siguientes nueve errores examinarán la pregunta:
Un único agente puede actuar correctamente; pero cuando los agentes comienzan a trabajar entre sí, ¿está protegida la cadena de identidad, autoridad, realidad y responsabilidad?
Un error de agente sólo puede permanecer en un punto. El error de agente múltiple puede multiplicarse en todo el sistema.