Excelencia operativa para la empresa de agentes

La excelencia operativa para sistemas de agentes amplía las prácticas tradicionales de DevOps para abordar las características exclusivas de los agentes de IA: comportamiento no determinista, razonamiento y memoria dependientes del contexto, complejidad de objetivos y costes de inferencia variables. Las aplicaciones convencionales siguen rutas de código predecibles, pero los agentes generan respuestas novedosas basadas en contexto. La supervisión tradicional realiza un seguimiento de mediciones conocidas, mientras que la observabilidad de agentes requiere comprender el razonamiento del modelo de idioma y los patrones de decisión. Las pruebas estándar validan resultados deterministas, pero la validación de agentes evalúa la calidad de la respuesta en múltiples dimensiones, incluyendo precisión, relevancia, seguridad y equidad.

Los productos y sistemas cambian con el tiempo, de modo que aplique estos cinco principios de diseño para integrar la excelencia operativa en cómo los ejecuta: evolucionar con observabilidad, estandarizar procedimientos operativos, adoptar una cultura de DevOps, automatizar para mayor eficiencia y aprender de todos los eventos operativos. El principio de excelencia operacional principal, “Evolucionar con observabilidad”, se vuelve crítico para sistemas agentes porque el comportamiento de los agentes surge de interacciones complejas entre solicitudes, contexto recuperado, comportamiento de modelo e historial de conversación en vez de la ejecución de código determinista. Los arquitectos no pueden predecir cada respuesta de agentes en tiempo de diseño, ya que las respuestas están moldeadas por el modelo, la solicitud y el contexto en vivo, por lo que diseñe para observabilidad y barandillas. La observabilidad integral revela cómo se comportan los agentes en condiciones reales. Esta visibilidad permite mejoras dirigidas por datos y un diagnóstico de problemas rápido cuando los agentes producen resultados inesperados.

“Operaciones como código” adquiere nuevas dimensiones para los agentes. La infraestructura como código tradicional se extiende a la versión de solicitudes, la gestión de la configuración de modelos y la automatización de la implementación de agentes. Los procedimientos operativos de agentes abordan los cambios de versión del modelo, la evolución de solicitudes y las actualizaciones de la base Knowledge, así como las operaciones convencionales de implementación y reversión.

“Aprender de todos los eventos operativos” se vuelve aún más valioso con sistemas agentes. Los incidentes de agentes a menudo revelan problemas de ingeniería de solicitudes sutiles, errores de secuencia de comandos y orquestación, brechas en la base Knowledge o patrones de interacción de usuario inesperados. Las autopsias combinadas con el análisis sistemático de la telemetría de agentes transforman la experiencia operativa en capacidad organizativa que se agrava con el tiempo.

El registro completo de conversaciones forma la base de la observabilidad de los agentes. Capture cada conversación incluyendo entradas de usuario, respuestas de agentes, pasos de razonamiento, acciones invocadas, datos recuperados y resultados finales. Esta telemetría sirve para múltiples propósitos: depuración de incidentes específicos, análisis de calidad entre muchas interacciones, auditoría de cumplimiento, mejora de modelo y análisis de patrón de uso.

Utilice el modelo de rastreo de sesiones nativo sobre el registro personalizado. Agentforce Session Tracing captura datos de interacción de agentes en un modelo de datos unificado en Data 360 en vez de requerir que cree un sistema de telemetría paralelo. El modelo de datos de rastreo de sesiones (STDM) registra la conversación como una jerarquía de rastreo. Cada sesión contiene interacciones (turnos), cada interacción contiene pasos (UserInputStep, LLMExecutionStep, FunctionStep) y los pasos contienen mensajes (comunicaciones de usuario y agente). STDM utiliza objetos estándar de Data 360 como AIAgentSession, AIAgentSessionParticipant, AIAgentInteraction, AIAgentInteractionStep y AIAgentInteractionMessage. Las interacciones llevan identificadores de rastreo distribuido (TelemetryTraceId y TelemetryTraceSpanId), y los pasos llevan un identificador de intervalo (TelemetryTraceSpanId), reflejando un modelo de intervalo al estilo OpenTelemetry.

Modelar conversaciones de agentes como trazas y extensiones es el enfoque estándar del sector para la observabilidad de agentes, y la reutilización del modelo nativo evita los problemas de escala con los que se encuentran los objetos creados a mano: almacenamiento de conversaciones de múltiples turnos, grandes cargas de JSON y un rápido crecimiento de datos. La creación de objetos transaccionales personalizados para registrar conversaciones es una excepción deliberada, por ejemplo, un objeto personalizado ligero que correlaciona el comportamiento de los agentes con los resultados comerciales y no el sustrato de registro principal.

Los metadatos de sesión y conversación capturan contexto crítico incluyendo identificadores de sesión e interacción, identidad de usuario, identidad de agente, hora de inicio y hora de finalización. STDMtambién vincula cada paso de interacción a sus registros de llamadas de modelo de lenguaje grande (LLM) (a través de referencias GenerationId y GenAiGatewayRequest/Response). Los detalles de solicitud, modelo y uso de token están disponibles a través de esas uniones en vez de almacenados como campos de sesión. Los metadatos permiten filtrar y agregar conversaciones para el análisis de patrones.

Los detalles de interacción y nivel de paso capturan cada turno incluyendo entrada de usuario, respuesta de agente, explicación de razonamiento (cuando está disponible), puntuaciones de confianza, contexto recuperado, acciones intentadas y errores encontrados. El rastreo a nivel de paso permite una investigación detallada de incidentes reconstruyendo exactamente lo que sucedió en cada punto de la cadena de razonamiento.

Los pasos de acción registran cada acción que realiza un agente incluyendo llamadas de API, modificaciones de datos, interacciones del sistema externo e integraciones invocadas. Los registros de acciones responden a preguntas como “¿qué cambió este agente?” y “¿a qué sistemas accedió este agente?”. Estas respuestas admiten investigaciones de seguridad y requisitos de cumplimiento. STDM captura acciones de forma nativa como pasos de interacción.

Los rastros de razonamiento del Motor de razonamiento de Atlas revelan procesos de decisión de agentes, lo que ayuda a diagnosticar por qué los agentes eligieron acciones específicas o generaron respuestas particulares. Rastreo de sesiones registra los pasos del planificador como parte de cada interacción. La profundidad del razonamiento expuesto depende del modelo y el planificador, pero cuando están disponibles estas trazas mejoran drásticamente la depuración.

El seguimiento de auditoría de IA generativa de Capa de Einstein Trust captura cada interacción de IA generativa, el texto de solicitud y respuesta, incluyendo versiones enmascaradas de información de identificación personal (PII), los datos de fundamentación recuperados, las puntuaciones de toxicidad y seguridad de respuesta y los detalles del modelo LLM, todo transmitido y almacenado en Data 360. Active IA generativa de Einstein y Recopilación y almacenamiento de datos de comentarios de modo que los datos de auditoría y comentarios se capturen en Data 360, donde puede consultarlos y analizarlos con la creación de informes de Data 360 para la retención a largo plazo.

Ejemplo:

Bueno: Registros de conversaciones almacenados en objetos personalizados de Salesforce con campos para entrada de usuario, respuesta de agente, acciones realizadas, consumo de token y resultado de conversación. El panel muestra índices de éxito de conversación por agente y caso de uso. Mejor: El registro integral incluye rastreos de razonamiento que muestran el proceso de decisión de agentes, contexto recuperado que muestra qué información fundamenta respuestas y puntuaciones de confianza que indican incertidumbre. Mejor: El análisis de conversaciones correlaciona el comportamiento de los agentes con los resultados comerciales, identifica oportunidades de mejora a través del análisis de patrones y alimenta oportunidades en curso de aprendizaje continuo con ejemplos etiquetados como de calidad.

Supervise el rendimiento operativo garantizando que los agentes cumplen los niveles de servicio y operan dentro de los parámetros esperados.

La latencia de respuesta realiza un seguimiento del tiempo de extremo a extremo desde la entrada del usuario hasta la respuesta del agente. La latencia afecta directamente a la experiencia del usuario. Mida la latencia en percentiles (p50, p95, p99) revelando el rendimiento típico y las experiencias en el peor de los casos. Alerta cuando la latencia de p95 supera umbrales que indican degradación del rendimiento.

Los factores de latencia para agentes incluyen el tiempo de inferencia del modelo, la duración de la recuperación de datos y contexto, la ejecución de acciones y herramientas externas y la latencia de red. Instrumente cada fase por separado permitiendo la optimización dirigida cuando la latencia general supera los objetivos.

El consumo de tokens mide tokens utilizados por conversación, por agente y por caso de uso. El consumo de tokens dirige los costes de inferencia y afecta al tiempo de respuesta (más tokens requieren más cálculo de inferencia). Realice un seguimiento de la distribución de tokens que revela si el uso real coincide con proyecciones. Detecte conversaciones atípicas que consumen tokens excesivos sugiriendo problemas de solicitud o mal uso.

Las mediciones de token incluyen tokens de solicitud (entrada en modelo), tokens de finalización (salida de modelo) y tokens totales (suma de solicitud y finalización). Los tokens de solicitud son más controlables que los tokens de finalización. Optimice solicitudes y contexto recuperado reduciendo el consumo de tokens de solicitudes manteniendo la calidad.

La supervisión del rendimiento realiza un seguimiento de conversaciones, solicitudes por segundo y tendencias de volumen de conversaciones simultáneas y puede ayudar a proyectar requisitos de capacidad y escala. Compare el rendimiento actual con los límites de frecuencia conocidos o las líneas base de capacidad que alertan al acercarse a umbrales.

El seguimiento del índice de errores supervisa los fallos por tipo incluyendo errores específicos del modelo, fallos de tiempo de espera, errores de permiso denegado y fallos de integración externa. Los patrones de error revelan problemas sistemáticos que requieren solución. Calcule índices de error como porcentaje del total de solicitudes que permiten la comparación entre agentes y periodos de tiempo.

Distinga entre categorías de error que requieren respuestas diferentes. Los errores específicos del modelo podrían requerir ajustes de solicitud o cambiar a un modelo mejor. Los errores de permisos requieren cambios de configuración de seguridad. Los errores de integración requieren investigación externa del sistema o activación del disyuntor.

La supervisión de disponibilidad mide el tiempo de disponibilidad de los agentes y los periodos de operación correctos. Calcule la disponibilidad como porcentaje de tiempo que los agentes responden con éxito a solicitudes. Realice un seguimiento de la disponibilidad frente a Objetivos a nivel de servicio (SLO), activando la respuesta proactiva cuando la disponibilidad cae por debajo de los objetivos.

Proactive Monitoring evalúa si su organización tiene anomalías en la plataforma y problemas de utilización de recursos que pueden afectar al estado de la infraestructura de los agentes. Aflora señales antes de que se conviertan en problemas visibles para el usuario. Utilícelo para mantenerse al tanto de las condiciones a nivel de infraestructura, como la actividad inusual de la API o el consumo de recursos que tiende a límites de plataforma, que podrían degradar el rendimiento de los agentes. Revise sus señales con respecto a la línea base operativa normal de sus agentes de modo que pueda distinguir anomalías sobre las que se pueden realizar acciones de la variación esperada.

Supervise la calidad de la respuesta de forma continua, detectando la degradación antes de que afecte a los resultados comerciales. Cuando la plataforma ofrece herramientas de evaluación integradas, utilícelas en vez de procesos personalizados o manuales. Comience con herramientas de evaluación y pruebas nativas. El Centro de pruebas de Agentforce le permite mantener conjuntos de casos de prueba reutilizables y ejecutar agentes en ellos por lotes, comprobando si el agente seleccionó el tema y la acción esperados y produjo una respuesta aceptable en vez de crear y ejecutar su propio arnés de prueba. También admite evaluadores nativos, incluyendo dimensiones de calidad de uso inmediato y un enfoque LLM como juez para puntuar la calidad de la conversación, y permite crear evaluadores personalizados para criterios específicos de la organización. Utilice conversaciones representativas en sus conjuntos de pruebas de modo que la evaluación refleje el uso real.

La precisión de respuestas mide si las respuestas de agentes contienen información correcta. La evaluación precisa requiere afirmaciones de respuesta conocida o revisión humana. Para preguntas de hechos con respuestas conocidas, la evaluación automatizada compara respuestas de agentes con respuestas correctas; manténgalas como casos de prueba en Centro de pruebas para una evaluación repetible. Para preguntas abiertas, los evaluadores humanos evalúan la precisión en conversaciones de muestra. Realice un seguimiento de las tendencias de precisión a lo largo del tiempo, revelando si los cambios de solicitud, las actualizaciones de modelo o las modificaciones de la base Knowledge mejoran o degradan el rendimiento.

La relevancia de respuestas mide si las respuestas de agentes abordan preguntas de usuarios de forma apropiada incluso si no son perfectamente precisas. Las respuestas relevantes comprenden la intención del usuario y proporcionan información útil incluso cuando no es posible una respuesta completa. Evalúe la relevancia a través de evaluadores nativos donde esté disponible, revisión humana de conversaciones de muestra y señales de usuario. Para agentes basados en una base Knowledge, el análisis de calidad de recuperación nativo puede evaluar la relevancia del contexto, la relevancia de las respuestas y la fidelidad (fundamentación) de las respuestas.

Las barandillas detectan respuestas inseguras, inapropiadas o dañinas, incluyendo sesgos, contenido ofensivo, consejos peligrosos y respuestas fuera del alcance. La Capa Einstein Trust aplica la detección de toxicidad a interacciones LLM en tiempo de ejecución, que es su primera línea de defensa. Mejore la supervisión de la seguridad a través del filtrado de contenido, el muestreo de revisiones manuales, los mecanismos de creación de informes de usuarios y las auditorías de equidad que evalúan las distribuciones de resultados entre grupos demográficos.

Las mediciones de satisfacción del usuario capturan la calidad de la experiencia subjetiva. Los comentarios Agentforce fluyen a los modelos de datos de Auditoría de IA generativa y Comentarios de Einstein (GenAIFeedback/GenAIFeedbackDetail en Data 360). Estos modelos capturan señales de usuario explícitas (subida/bajada, aceptación/rechazo, modificaciones y comentarios literales) desde un origen humano o del sistema, junto con la solicitud de pasarela y los datos de generación. Capture comentarios explícitos (preguntando antes de la distribución, después del final de una conversación y a través de encuestas de seguimiento) donde los necesite y combine señales explícitas e implícitas para una perspectiva de calidad integral.

Salesforce proporciona varias superficies de modelo. El nivel generativo proporciona los agentes de razonamiento conversacional que se ejecutan en: Los modelos alojados en Agentforce entregan razonamiento de uso inmediato dentro del límite de Trust de Salesforce y aportan sus propios vínculos LLM (BYOLLM) a proveedores o LLM externos. El nivel predictivo proporciona a los agentes de puntuaciones estructuradas basar sus decisiones en: BYOM extrae puntuaciones predictivas de copia cero desde plataformas alojadas externamente y los modelos Einstein nativos producen puntuación y clasificación automatizadas en objetos de CRM. Juntos, estas superficies permiten a un agente autónomo razonar en lenguaje natural mientras fundamenta su flujo de trabajo en datos estadísticos estructurados.

Supervise la desviación del modelo, que indica un rendimiento degradado con el tiempo o condiciones cambiantes que requieren adaptación. Revise notas de versión y pruebe casos de uso críticos en un entorno sandbox antes de que cada versión principal pase a producción. Utilice la matriz de versión y la ventana de vista previa de sandbox para detectar problemas de compatibilidad pronto.

La deriva de rendimiento se produce cuando la precisión, relevancia o seguridad de los agentes se degrada con el tiempo. Realice un seguimiento de mediciones de calidad a lo largo del tiempo detectando disminuciones estadísticamente significativas. La desviación de rendimiento puede ser el resultado de la degradación del modelo, la obsolescencia de la base Knowledge, la desalineación de solicitudes con patrones de uso cambiantes o la desviación de conceptos donde evolucionan las relaciones entre entradas y salidas deseadas.

Establezca el rendimiento de línea base inmediatamente después de la implementación inicial del agente midiendo la precisión, relevancia, seguridad y satisfacción entre casos de prueba representativos. Volver a evaluar periódicamente con los mismos casos de prueba que revelan cambios de rendimiento independientes de turnos de patrón de uso.

Alerta cuando las mediciones de calidad disminuyen más allá de los umbrales aceptables. Defina umbrales basándose en la tolerancia de impacto comercial. Algunos casos de uso toleran una degradación modesta de la calidad; otros requieren una respuesta inmediata a cualquier disminución.

La deriva de distribución se produce cuando los patrones de entrada de usuario cambian significativamente de distribuciones de datos de entrenamiento o ajuste. La desviación de distribución degrada el rendimiento cuando los agentes encuentran tipos de entrada para los que no se diseñaron. Supervise características de entrada incluyendo longitud de pregunta, distribución de tema, complejidad de idioma y terminología de dominio detectando turnos significativos.

Compare las distribuciones de entrada actuales con las líneas base históricas. Los grandes turnos de distribución pueden indicar nuevos casos de uso, cambios en el comportamiento de los usuarios o evolución de los procesos comerciales. Los turnos de distribución pueden requerir actualizaciones de solicitudes, ampliación de la base Knowledge o mejoras de la capacidad de los agentes.

La deriva de comportamiento se produce cuando los patrones de respuesta de los agentes cambian de forma inesperada. Supervise características de respuesta incluyendo longitud de respuesta media, índices de invocación de acciones, frecuencias de distribución y patrones de error. Cambios de comportamiento significativos pueden indicar problemas de solicitud, problemas de modelo o cambios subyacentes del sistema.

Establezca líneas base de comportamiento en una fase temprana de la producción, capturando características operativas normales como patrones de rendimiento regulares, uso de herramientas y rutas de decisión. Estas líneas base se convierten en el indicador con el que se mide la detección de anomalías más adelante. Compare el comportamiento continuo con las líneas base, alertando cuando las desviaciones superan la variación esperada.

Las alertas automatizadas activan la respuesta de desviación proactiva. Configure alertas que se activan cuando las mediciones de desviación superan umbrales desencadenando investigación y posible remediación incluyendo refinamiento de solicitudes, actualizaciones de la base de Knowledge, expansión de conjuntos de pruebas o reentrenamiento del modelo BYOM.

Detecta automáticamente comportamientos inusuales de agentes que requieren investigación.

Anomalías de costes incluyendo picos de consumo de tokens, aumentos de índice de inferencia o aceleración de costes totales. Los picos de coste pueden indicar problemas de solicitud que causan una generación excesiva de tokens, abuso o mal uso que provocan un uso inesperado o problemas de infraestructura que causan llamadas redundantes.

Supervise distribuciones de consumo de tokens detectando conversaciones atípicas. Investigue conversaciones que consumen 10 veces el recuento de tokens habitual, para comprender si representan casos de borde legítimos o problemas que requieren solución.

Pico de índices de error incluyendo aumentos repentinos en índices de fallo, nuevos tipos de error que aparecen que no existían en la línea base o concentraciones de error localizadas que afectan a usuarios, agentes o casos de uso específicos. Los picos de error a menudo preceden a problemas de degradación de la calidad que los clientes pueden ver. La detección proactiva permite la solución antes de una repercusión generalizada.

Cambios de patrón de respuesta incluyendo cambios repentinos en la longitud de respuesta, frecuencia de invocación de acciones o cambios en el índice de distribución. Los cambios de patrón pueden indicar problemas de solicitud, cambios de comportamiento de modelo o patrones de uso en evolución.

El abandono de conversaciones aumenta donde los usuarios abandonan conversaciones a índices más altos sugiere una disminución de la calidad, un aumento de la latencia o brechas de funcionalidad. Realice un seguimiento del abandono por etapa de conversación identificando si los usuarios abandonan durante la interacción inicial, en medio de la conversación o después de intentar completar la tarea. Los patrones de abandono revelan oportunidades de mejora específicas.

Diseñe una arquitectura de alertas que equilibre la notificación rápida con la fatiga de alerta. Enrute fallos de agentes críticos a ingenieros a petición de inmediato. Enrute advertencias de degradación de la calidad a equipos de productos para su investigación durante el horario de oficina. Agregue anomalías menores en resúmenes diarios para el análisis de tendencias.

Solicitudes de control de versiones, configuraciones y metadatos de modelo que permiten la reversión, las pruebas A/B y el mantenimiento de seguimiento de auditoría.

Las plantillas de solicitudes son solicitudes reutilizables creadas en Generador de solicitudes que definen el objetivo, las restricciones y las directrices de marca del agente, además de marcadores de posición para datos de fundamentación dinámicos, como detalles de clientes o productos. Almacene plantillas de solicitudes en Git junto con código de aplicación, tratando las solicitudes como lógica de aplicación crítica que merece el mismo rigor que el código. Los cambios de solicitud pasan por revisión de código, pruebas e implementación controlada.

Utilice Generador de solicitudes para el desarrollo de solicitudes iterativas con historial de versión y funciones de prueba. Cuando utilice plantillas de solicitudes como acciones de agentes, realice una vista previa de la plantilla en Generador de solicitudes para confirmar que los campos de combinación se resuelven correctamente. A continuación utilice el Centro de pruebas para ejecutar pruebas de extremo a extremo que confirman que el agente selecciona la acción y genera los resultados correctos.

Exporte solicitudes listas para producción al control de versiones creando sincronización entre el desarrollo Generador de solicitudes y las oportunidades en curso de implementación controladas por el origen.

La gestión de configuración realiza un seguimiento de la selección del modelo, los parámetros de temperatura, las configuraciones de recuperación y los indicadores de funciones. Almacene configuraciones como código de modo que pueda utilizar valores específicos del entorno, automatizar implementaciones y detectar desviación de configuración.

La versión semántica se aplica a versiones de agentes. Las versiones principales indican cambios de ruptura como contratos de entrada/salida modificados o un comportamiento significativamente cambiado. Las versiones menores indican adiciones o mejoras de funciones que mantienen la compatibilidad. Las versiones de parche indican soluciones de errores. La numeración de versiones comunica el impacto del cambio a los equipos de operaciones y usuarios.

Implemente versiones semánticas para componentes de agentes incluyendo plantillas de solicitudes, configuraciones de agentes y bases Knowledge. Los números de versión en registros activan la correlación de incidentes con implementaciones específicas.

La documentación de cambios captura la justificación de cambios de solicitudes, modificaciones de configuraciones y actualizaciones de modelos. Documente qué cambió, por qué cambió, qué pruebas validaron el cambio y qué procedimientos de reversión existen. La documentación de cambios acelera la investigación de incidentes y la transferencia Knowledge.

Mantenga un registro completo de versiones de modelo, solicitudes, configuraciones e historial de implementación.

El registro de modelo registra qué versiones de modelo se implementan donde se incluye familia de modelos, versión específica, estado de ajuste, entorno de implementación (producción, organización y desarrollo), fecha de implementación y equipo responsable. El registro proporciona una única fuente de verdad para el estado de la infraestructura de agentes.

El seguimiento de implementación registra cada implementación de agente incluyendo la versión implementada, el entorno, la marca de tiempo de implementación, el usuario de implementación, las aprobaciones obtenidas y el resultado de la implementación. Utilice el historial de implementación para evaluar la repercusión cuando surgen problemas (por ejemplo, “¿qué agentes se implementaron antes de que comenzara este incidente?”) y para admitir la creación de informes de cumplimiento.

El seguimiento de dependencias asigna relaciones entre agentes, solicitudes, bases de Knowledge, acciones e integraciones. Cuando se actualiza la base de Knowledge compartida, el seguimiento de dependencias revela qué agentes se ven afectados. Cuando cambia la integración externa, el seguimiento de dependencias identifica agentes afectados.

Documente dependencias de forma explícita en vez de descubrirlas durante incidentes. Cree mapas de dependencias mantenidos a través de procesos de desarrollo e implementación.

Las políticas de obsolescencia definen ciclos de vida para versiones de modelo, incluyendo duración de asistencia, cronología de obsolescencia y requisitos de migración. Las políticas de desaprobación claras gestionan la deuda técnica evitando la compatibilidad indefinida de versiones de modelo antiguas. Establezca una programación de desaprobación comunicando cronologías con suficiente antelación activando migraciones planificadas en vez de respuestas de emergencia a desaprobaciones forzadas. Un periodo de notificación mínimo bien comunicado y respaldado por políticas proporciona tiempo de migración adecuado para cambios críticos.

Los procedimientos de reversión permiten a los equipos recuperarse rápidamente de implementaciones problemáticas. Los procedimientos de reversión de documentos para cada agente incluyen lo siguiente:

• Condiciones que desencadenan una reversión
• A qué versión volver
• Cómo ejecutar la reversión
• Quién autoriza y realiza la reversión
• Qué pruebas confirman que la reversión se realizó con éxito y qué equipos notificar.

Pruebe los procedimientos de reversión regularmente en entornos que no sean de producción para confirmar que funcionan antes de que dependa de ellos durante incidentes de producción. Ensaye con implementaciones simuladas de modo que el equipo sepa exactamente qué hacer. Los procedimientos de reversión no probados a menudo fallan cuando más se necesitan.

Mantenga la calidad de los agentes a través de flujos de trabajo de formación, ajuste y refinamiento continuos.

La recopilación de comentarios recopila sistemáticamente comentarios de usuarios, correcciones de revisiones humanas, evaluaciones de calidad y mediciones de resultados. Los comentarios proporcionan materia prima para la mejora. Sin recopilación sistemática, la mejora se convierte en conjeturas. Recopile comentarios explícitos a través de preguntas formuladas antes de la distribución, después del final de una conversación o a través de encuestas de seguimiento. Recopile comentarios implícitos a través de índices de finalización, frecuencias de distribución y patrones de reintento. Combine señales explícitas e implícitas proporcionando una perspectiva de calidad integral.

El depurado de datos mantiene conjuntos de datos de formación de alta calidad a través del depurado, la revisión de calidad y la comprobación de sesgos. La calidad de los datos de entrenamiento determina directamente la calidad del modelo. Los datos deficientes producen modelos poco fiables; los datos excelentes permiten un rendimiento excepcional.

Depure registros de conversaciones en conjuntos de datos de entrenamiento:

• Filtrado de calidad, incluyendo conversaciones de alta valoración y resultados exitosos
• Eliminación de ejemplos problemáticos, incluyendo infracciones de seguridad y errores
• Garantizar la representatividad, incluyendo escenarios diversos y casos extremos
• Deduplicación: eliminación de ejemplos casi idénticos

Adapte agentes a su dominio (vocabulario especializado, procesos comerciales exclusivos, Knowledge específico de la organización) principalmente a través de la generación aumentada de recuperación (RAG) basada en Data 360 y ajuste de solicitudes, la ruta nativa de Salesforce.

Ningún modelo generativo está ajustado dentro de Salesforce; selecciona y configura modelos a través de modelos de IA y Generador de solicitudes. Cuando la conexión a tierra es insuficiente, ajuste el ajuste externo y luego conecte a través de BYOLLM.

El perfeccionamiento de solicitudes mejora de forma iterativa las solicitudes basándose en datos de rendimiento utilizando Generador de solicitudes. La ingeniería de solicitudes es una práctica continua en vez de un ejercicio puntual. A medida que evolucionan los patrones de uso, cambian los procesos comerciales y cambian las expectativas de los usuarios, las solicitudes requieren ajustes manteniendo un rendimiento óptimo.

Establezca la cadencia de revisión de solicitudes periódica examinando conversaciones recientes, mediciones de calidad y comentarios de usuarios que identifican oportunidades de mejora. Implemente cambios de solicitud de forma incremental con pruebas A/B validando mejoras antes de la implementación completa.

La automatización de evaluaciones ejecuta una evaluación de calidad en conjuntos de pruebas que se retienen, lo que permite una evaluación rápida de los candidatos a mejoras. La evaluación automatizada proporciona una medición objetiva que complementa la evaluación humana subjetiva.

Mantenga conjuntos de pruebas que cubren rutas felices, casos extremos, entradas adversariales y escenarios de problemas históricos. Establezca la automatización de pruebas para ejecutar sus escenarios de prueba con una cadencia regular. Incluya supervisión de resultados automatizada, umbrales y notificaciones para alertar a los administradores sobre anomalías. Estas pruebas automatizadas son cruciales para detectar efectos adversos de factores externos como la desviación del modelo.

Amplíe continuamente los conjuntos de pruebas a medida que aparezcan nuevos casos edge en producción. La automatización de pruebas es clave, pero también puede ejecutar comprobaciones manuales periódicas de puntos, pruebas puntuales y pruebas de gorilas para garantizar que su implementación de agentes resiste casos extremos.

Implemente cambios de agentes gradualmente y supervise la calidad antes de la implementación completa para limitar el radio de explosión de problemas. Cuando un cambio abarca múltiples áreas (solicitudes, configuración de modelo, acciones, fundamentación, integraciones), puede degradar el comportamiento de formas que las pruebas no detectaron. Cuando eso sucede, la regresión de calidad resultante rara vez apunta a una causa raíz única y obvia. Envíe pequeños cambios uno por uno de modo que se pueda rastrear una regresión a su origen, y libere cada uno a una porción limitada de tráfico primero para contener el impacto mientras diagnostica.

Los marcadores de funciones desvinculan la implementación de la versión implementando agentes con funciones desactivadas detrás de la configuración. Implemente indicadores de funciones utilizando lógica o tipos de metadatos personalizados o configuración personalizada. Los indicadores de funciones permiten realizar pruebas en el entorno de producción sin exponer funciones a usuarios, implementaciones graduales en segmentos de usuario específicos, pruebas A/B comparando implementaciones y reversión instantánea desactivando indicadores sin reimplementación.

Utilice indicadores de función para cambios significativos de agentes, donde el radio de explosión de un fallo podría ser grave, como Cambios que afectan a agentes críticos comerciales, Nuevos patrones de razonamiento con comportamiento de producción incierto Integraciones con sistemas externos donde los patrones de interacción pueden diferir de las pruebas.

Las implementaciones canarias liberan cambios en el subconjunto de usuarios pequeño supervisando primero los índices de error, las mediciones de calidad y el rendimiento antes de una implementación más amplia. Utilice conjuntos de permisos para controlar implementaciones canarias: restrinja el acceso de agentes a un subconjunto de usuarios o filtre dentro de la lógica de orquestación basándose en atributos de usuario.

Supervise y mida índices de éxito, calidad de respuesta y comentarios de usuarios. Compare mediciones canarias con grupos de control utilizando la versión de agente anterior. Solo amplíe la implementación cuando canario demuestre un rendimiento equivalente o mejorado.

Las pruebas A/B comparan variaciones de agentes que miden la calidad, el coste y la satisfacción del usuario. Las pruebas A/B proporcionan evidencia empírica para decisiones de mejora. Implemente variantes en subconjuntos de usuarios seleccionados aleatoriamente garantizando la validez estadística. Mida resultados entre múltiples dimensiones (precisión, satisfacción, coste y latencia) proporcionando una comparación integral.

Defina criterios e hipótesis de éxito antes de iniciar pruebas A/B. Criterios claros evitan resultados ambiguos donde algunas mediciones mejoran mientras que otras se degradan. Los criterios de éxito deben alinearse con los objetivos comerciales (por ejemplo, “la Variante B debe coincidir con la precisión de la Variante A en un 2% y reducir el coste en un 15%”).

Las pruebas campeón-desafío implementan versiones de agentes mejoradas en subconjuntos de tráfico en comparación con versiones campeón actuales. El patrón campeón-desafiante gestiona el riesgo de mejora manteniendo la versión probada como reserva. Si el rival tiene un rendimiento inferior, vuelva a campeón sin repercusión en el usuario. Si el retador supera al campeón, promocionelo al nuevo campeón.

Establezca criterios de promoción objetivos, incluyendo el tamaño de muestra mínimo para la validez estadística, los umbrales de calidad que los impugnadores deben superar y la duración de la evaluación antes de las decisiones de promoción. Documente las decisiones de promoción que crean un seguimiento de auditoría de por qué cambiaron las versiones de agentes.

Establezca la detección de incidentes identificando problemas operativos de agentes rápidamente a través de una supervisión integral.

Los modos de fallo difieren de los fallos de aplicación tradicionales. Los modos de fallo comunes incluyen:

• Alucinaciones: generación de información plausible pero incorrecta
• Respuestas fuera de tema: mala comprensión de la intención del usuario
• Consumo de costes excesivo: generación de tokens desbocados
• Fallos de tiempo de espera: la inferencia tarda demasiado
• Errores de permisos: intento de acciones no autorizadas
• Fallos de integración: no disponibilidad del sistema externo
• Infracciones de seguridad: generación de contenido inapropiado

Detecte fallos a través de alertas de supervisión automatizada sobre índices de error, degradación de mediciones de calidad, anomalías de costes, aumentos de latencia y distribuciones de usuarios. Complemente con mecanismos de creación de informes automáticos de usuarios, incluyendo solicitudes de comentarios y directrices claras sobre cómo y dónde proporcionar comentarios, de modo que pueda solucionar brechas reportadas en la automatización.

La clasificación de gravedad enruta incidentes a los respondedores apropiados con la urgencia adecuada. Los incidentes críticos indican que la producción no está disponible y afecta a muchos usuarios, que los datos están dañados por acciones de los agentes, por compromisos de seguridad o por infracciones de seguridad que requieren una respuesta inmediata. La alta gravedad indica una calidad degradada que afecta a agentes clave para el negocio o sobrecostes significativos. La gravedad media indica problemas aislados o umbrales próximos que requieren investigación durante el horario de oficina. La baja gravedad indica problemas menores que se siguen fuera del proceso de gestión de incidentes.

Defina criterios de gravedad objetivamente basándose en impacto de usuario, radio de explosión, riesgo de integridad de datos y urgencia de recuperación. Los criterios objetivos evitan la infravaloración de problemas reales y la sobrevaloración de problemas menores. Mantenga la documentación sobre los resultados de la resolución de incidentes para mejorar continuamente el proceso.

Los procedimientos de respuesta inicial guían las acciones inmediatas para estabilizar la situación. Los procedimientos incluyen:

• Desactivar la activación de agente con fallos - disyuntor
• Enrute usuarios a opciones de reserva: traspaso humano, agente más sencillo, respuestas estáticas
• Recopilar información de diagnóstico: conversaciones recientes, registros de errores, mediciones de recursos
• Notificar a las partes interesadas: ingenieros a petición, propietarios de productos, usuarios afectados
• Iniciar comunicación de incidentes: actualizaciones de página de estado, canales de coordinación internos
• Documente procedimientos de respuesta inicial como libros de ejecución que permiten una ejecución rápida sin requerir investigación específica de incidentes.
• Los libros de ejecución deben ser ejecutables por ingenieros a petición sin experiencia profunda de agentes.

Evite fallos en cascada y mantenga funciones parciales durante incidentes de agentes.

El patrón de disyuntor desactiva automáticamente agentes con fallos que evitan fallos repetidos y el impacto del usuario mientras se resuelven problemas. Implemente disyuntores supervisando los índices de error y la apertura (agente de desactivación) cuando el índice de error supera el umbral para el periodo sostenido.

Configure disyuntores con umbral de error, plazo de duración y pruebas de recuperación. Por ejemplo, un índice de error del 50% con un plazo de cinco minutos y una prueba periódica que solicita probar si el agente se recuperó. Cuando se abra el circuito, enrute las solicitudes a opciones de reserva. Después de un periodo de tiempo de espera, el circuito pasa a un estado medio abierto permitiendo que las solicitudes de prueba pasen. Cuando las solicitudes de prueba se realizan correctamente de forma coherente, cierre el circuito, reanudando el funcionamiento normal.

Las jerarquías de reserva proporcionan una degradación elegante cuando fallan los agentes principales. Diseñe secuencias de reserva intentando opciones cada vez más sencillas hasta que se logre una respuesta aceptable. Ejemplo de jerarquía de reserva: Agente sofisticado principal → Agente de copia de seguridad más sencillo → Respuestas de preguntas más frecuentes estáticas → Transferencia humana.

Implemente lógica de reserva en la capa de orquestación en vez de dentro de agentes activando un comportamiento coherente en el ecosistema de agentes. Pruebe rutas de reserva regularmente validando que funcionan cuando sea necesario.

El traspaso humano se distribuye a agentes humanos cuando los agentes de IA no pueden gestionar solicitudes. Diseñe flujos de trabajo de traspaso preservando el contexto de la conversación, comunicando el motivo del traspaso, enrutando a agentes humanos apropiados con experiencia relevante y realizando un seguimiento de la frecuencia de traspasos revelando oportunidades de mejora.

Supervise los índices de distribución por tema, agente y motivo de fallo. Los índices más altos indican brechas de capacidad de agentes que requieren mejoras rápidas, ampliación de la base de Knowledge o refinamiento de casos de uso.

La degradación elegante mantiene la funcionalidad parcial durante la operación degradada. Cuando falla un razonamiento sofisticado, vuelva a una lógica más sencilla. Cuando los datos en tiempo real no están disponibles, opere con datos en caché. Cuando las integraciones externas fallan, opere en modo de solo lectura. La degradación elegante permite que un sistema siga funcionando en una capacidad reducida en vez de fallar completamente.

Realice revisiones posteriores a incidentes sin culpa centrándose en mejoras del sistema en vez de fallos individuales creando seguridad psicológica para una evaluación honesta.

La reconstrucción de cronología crea una secuencia detallada desde las condiciones iniciales hasta la primera señal, la detección, el acuse de recibo, la investigación, las acciones de respuesta, la recuperación y la validación. Marca la hora de cada evento activando el análisis de duración de cada fase revelando dónde se retrasó la respuesta al incidente.

Incluya lo siguiente en su cronología:

• ¿Qué se implementó recientemente (solicitudes, configuraciones, modelos, integraciones)?
• ¿Qué cambios en los patrones de uso (aumento repentino del tráfico, nuevos tipos de conversación) se observaron?
• ¿Qué factores externos contribuyeron (degradación de servicios externos, actualizaciones de plataforma)?
• ¿Qué hizo que la detección fuera más lenta de lo ideal?

La identificación de causa raíz determina la causa técnica directa. Distinga la causa inmediata (tiempo de espera del modelo) de los factores que contribuyen (diseño de solicitud que supera los límites del token bajo patrones de conversación específicos). El análisis de causa raíz evita conclusiones simplistas (“el agente tenía un fallo”) a favor de hallazgos específicos que dan como resultado una remediación efectiva.

Utilice la técnica de “Cinco por qué”, desglosando desde síntomas hasta causas fundamentales.

Ejemplo de superficie: “El agente produjo información incorrecta” → “¿Por qué? El contexto recuperado contenía datos desfasados” → “¿Por qué? Knowledge base no se actualizó con cambios de productos recientes” → “¿Por qué? No existe ningún proceso para que el equipo de productos desencadene actualizaciones de la base Knowledge” → Causa raíz: Falta un flujo de trabajo que conecte versiones de productos con el mantenimiento de la base Knowledge.

Los factores que contribuyen revelan condiciones organizativas, de proceso o arquitectónicas que activan o amplifican el impacto de incidentes. Los factores comunes incluyen brechas de supervisión que permiten que los problemas persistan más de lo detectado, brechas de prueba que dejan escenarios de fallo descubiertos, brechas de documentación que ralentizan el diagnóstico rápido, brechas de automatización que obligan a pasos de recuperación manual y brechas de arquitectura como puntos de fallo únicos o redundancia que falta.

El análisis factorial que contribuye revela oportunidades de mejora más allá de la solución de causa raíz inmediata. La mayoría de los incidentes tienen múltiples factores que contribuyen, cada uno amplificando la repercusión.

El análisis de detección examina cómo se detectó el incidente y si la detección podría haber sido más rápida. Muchos incidentes de agentes se notifican en primer lugar por usuarios en vez de supervisión automatizada, indicando una brecha de supervisión. Determinar: ¿Qué señal debería haber detectado el problema antes? ¿Qué supervisión permitiría una detección más rápida? ¿Qué criterios de alerta se habrían activado adecuadamente?

Las mejoras del análisis de detección incluyen: Agregar cobertura de supervisión que falta, ajustar umbrales de alerta eliminando falsos negativos, enriquecer el contexto de alerta para un triaje más rápido y mejorar paneles para la identificación de problemas proactiva.

La evaluación de respuestas evalúa qué salió bien y qué fue más lento o más difícil de lo necesario. Preguntas de evaluación de respuestas: ¿Fueron útiles y precisos los libros de ejecución? ¿Fueron las rutas de distribución claras y efectivas? ¿Se probaron y prepararon los procedimientos de reversión? ¿Proporcionaron las herramientas información de diagnóstico necesaria? ¿Fue la comunicación oportuna y eficaz?

Las mejoras de evaluación de respuestas incluyen: actualización de manuales con lecciones aprendidas, aclaración de criterios de distribución, pruebas de procedimientos de reversión regularmente, adición de herramientas de diagnóstico y mejora de plantillas de comunicación de incidentes.

Los elementos de acción especifican mejoras concretas, asignadas y con plazos específicos que evitan la repetición o mejoran la respuesta futura. Evite elementos de acción imprecisos, como “mejorar la supervisión”, en favor de tareas específicas, como “agregar alerta para índice de error de agentes que supera el 5% en un plazo de 10 minutos, asignado: Alex, debido: 2 semanas”.

Realice un seguimiento de la finalización de elementos de acción en revisiones posteriores garantizando que se produzca una mejora continua. Revise elementos de acción abiertos de incidentes anteriores durante cada revisión posterior al incidente. Los bajos índices de finalización indican fallos de procesos de mejora continua que requieren atención.

Revisiones posteriores a incidentes de documentos de colaboración Knowledge en wiki, base de Knowledge o espacio de colaboración compartidos con etiquetado que activa el análisis de patrones entre múltiples incidentes. Las retrospectivas de incidentes deben tener capacidad de búsqueda por modo de fallo, componentes afectados y periodo de tiempo que permitan a los futuros respondedores aprender de incidentes históricos.

Comparta revisiones posteriores a incidentes más allá de los respondedores de incidentes inmediatos. El aprendizaje organizacional requiere propagación de información. Considere presentar aprendizajes de incidentes importantes en reuniones de equipo o sesiones de almuerzo y aprendizaje difundiendo Knowledge y creando capacidad colectiva.

Requiera aprobación antes de implementar agentes de producción garantizando revisión, evaluación de riesgos y alineación de partes interesadas.

La lista de comprobación previa a la implementación valida la preparación incluyendo:

• Pruebas completas completadas: funcionalidad, calidad, seguridad, rendimiento
• Revisión de seguridad aprobada: límites de permisos, acceso a datos, autorización de acciones
• Cumplimiento validado: requisitos normativos, adhesión a políticas
• Documentación completa: libros de ejecución, procedimientos de reversión, rutas de distribución
• Supervisión configurada: mediciones de calidad, índices de error, seguimiento de costes
• Aprobación de las partes interesadas obtenida: propietario del producto, seguridad, cumplimiento

La lista de comprobación proporciona criterios de evaluación coherentes entre agentes. Adapte la lista de comprobación para el perfil de riesgo de agentes en función de la criticidad de los agentes, la confidencialidad de los datos y el nivel de autonomía.

La evaluación de riesgos evalúa el posible impacto de fallos de agentes, incluyendo:

• Radio de explosión - cuántos usuarios afectados por fallos
• Sensibilidad de datos: a qué accede el agente de datos
• Autoridad de acción: qué modificaciones puede realizar el agente
• Dependencias de integración: qué agente del sistema afecta
• Complejidad de recuperación: qué tan difícil es la reversión
• Implicaciones de cumplimiento: qué normativas se aplican

La evaluación de riesgos determina los requisitos de aprobación. Los agentes de alto riesgo requieren aprobación ejecutiva, revisión de seguridad e implementación gradual, mientras que los agentes de bajo riesgo pueden requerir revisión por compañeros y pruebas estándar.

Los flujos de trabajo de aprobación enrutan solicitudes de implementación a través de revisores apropiados. Implemente flujos de trabajo de aprobación utilizando procesos de aprobación de Salesforce o herramientas de implementación externas. Automatice, realice un seguimiento y audite flujos de trabajo de aprobación para activar la creación de informes de cumplimiento e investigación de incidentes.

Documente decisiones de aprobación, creando un seguimiento de auditoría de quién aprobó implementaciones, qué información informó a aprobaciones, qué condiciones o restricciones se aplicaron y qué compromisos de supervisión se realizaron.

Los procedimientos de omisión de emergencia permiten una implementación rápida durante incidentes de producción cuando los procesos de aprobación normales retrasan soluciones críticas. Los procedimientos de emergencia deben requerir la aprobación ejecutiva, incluir documentación justificativa y desencadenar una revisión posterior a la implementación acelerada validando cambios de emergencia.

Realice un seguimiento de las implementaciones de emergencia por separado de las versiones estándar. La alta frecuencia de implementación de emergencia indica problemas del proceso que requieren investigación.

Defina puertas de calidad que los agentes deben pasar antes de la implementación de producción evitando que los agentes problemáticos lleguen a los usuarios.

Las pruebas funcionales validan que los agentes realicen tareas previstas correctamente en escenarios representativos. Pruebe rutas felices que cubren interacciones típicas, casos periféricos que cubren escenarios poco frecuentes pero válidos, rutas de error que prueban si los agentes gestionan entradas no válidas correctamente y condiciones de límite que comprueban si el agente está dentro de límites reguladores, límites de tokens y límites de volumen de datos.

Las pruebas funcionales para agentes difieren de las pruebas tradicionales porque los resultados no deterministas evitan la coincidencia exacta. Características de salida de prueba (contiene información requerida, mantiene el tono apropiado, incluye citas necesarias) en vez de texto exacto.

Las pruebas de calidad de respuestas evalúan la precisión y relevancia de las respuestas en diferentes escenarios de prueba. Las pruebas de calidad requieren evaluación humana o conjuntos de datos de verdad fundamental con resultados esperados. Establezca umbrales de calidad mínimos que los agentes deben cumplir (por ejemplo, “95% de precisión en el conjunto de pruebas retenido, cero infracciones de seguridad, auditoría de equidad no muestra disparidades demográficas que superen el 5%”). Mantenga y amplíe los conjuntos de pruebas de forma continua a medida que se descubran nuevos casos periféricos.

Las pruebas de seguridad validan que los agentes rechazan solicitudes peligrosas, poco éticas o fuera del alcance. Las pruebas de seguridad intentan entradas adversarias incluyendo:

• Solicitar intentos de inyección: intentando sustituir instrucciones
• Intentos de Jailbreak: intentando omitir restricciones de seguridad
• Solicitar distribución: solicitando acciones cada vez más confidenciales
• Solicitudes fuera del alcance: intento de tareas no autorizadas

Asigne pruebas de seguridad a miembros del equipo independiente que no participaron en la creación del agente. Para agentes de alto riesgo, traiga especialistas del equipo rojo.

Las pruebas de rendimiento validan la latencia, el rendimiento y el coste para cumplir las expectativas. Pruebe bajo carga realista incluyendo conversaciones simultáneas, longitudes de conversación típicas y volumen de uso proyectado. Las pruebas de rendimiento revelan problemas de límite regulador, restricciones de recursos y cuellos de botella de escalabilidad invisibles en pruebas de un solo usuario.

Mida el consumo de entorno de prueba durante las pruebas de rendimiento y utilícelo para proyectar necesidades de capacidad de producción.

Las pruebas de seguridad validan límites de permisos, controles de acceso a datos y autorización de acciones. Las pruebas de seguridad confirman: los agentes no pueden acceder a datos no autorizados, los agentes no pueden realizar acciones no autorizadas, la inyección de solicitudes no puede distribuir privilegios y el registro de auditoría captura todas las actividades de los agentes.

Integre el análisis de seguridad de código estático en las oportunidades en curso de implementación utilizando Salesforce Code Analyzer, que explora Apex, Flows, Lightning y Visualforce en busca de vulnerabilidades de seguridad y puede ejecutarse en integración/implementación continua (CI/CD) a través de su interfaz de línea de comandos (CLI) o acción GitHub. Utilice pruebas de seguridad de IA/agente especializadas para detectar vulnerabilidades de inyección de solicitudes y riesgos de exposición de datos confidenciales, ya que son amenazas de entrada LLM en tiempo de ejecución fuera del ámbito del análisis de código estático.

Aplique disciplina de gestión de cambios a implementaciones de agentes garantizando que los cambios se documenten, revisen y comuniquen.

Capturas de documentación de cambios:

• Qué cambió: modificaciones de solicitudes, actualizaciones de configuración, cambios de modelo
• Por qué se realizó ese cambio: mejora de la calidad, optimización de costes, solución de errores
• Qué pruebas validaron ese cambio: resultados de pruebas, puntuaciones de calidad, análisis de seguridad
• Qué procedimiento de reversión existe

La documentación de cambios permite la investigación de incidentes, la creación de informes de cumplimiento y la transferencia Knowledge. Los cambios documentados crean una organización de aprendizaje que se basa en la experiencia anterior en vez de redescubrir lecciones.

La planificación de comunicaciones notifica a las partes interesadas sobre cambios de agentes, incluyendo usuarios afectados, equipos de operaciones, equipos de asistencia y partes interesadas comerciales. La comunicación debe describir: qué está cambiando, cuándo se implementa el cambio, qué beneficios verán los usuarios, qué riesgos existen y con quién ponerse en contacto para problemas.

Establezca plantillas de comunicación para diferentes tipos de cambio estandarizando mensajes y reduciendo el gasto general de preparación de implementación.

Horas de programación de implementación implementaciones de agentes durante periodos de bajo uso informadas por datos de Supervisión de eventos que muestran patrones de uso reales. Evite implementaciones durante el uso máximo, cierre de fin de mes, cierre de fin de trimestre o eventos comerciales importantes. Comunique plazos de implementación incluyendo la duración prevista y la cronología de decisión de reversión.

Considere programar cambios importantes para principios o mediados de la semana y evite implementaciones a finales de la semana, de modo que los problemas se puedan solucionar con recursos adecuados. Dé prioridad a la reversión rápida y la supervisión posterior a la implementación sólida sobre cualquier regla de calendario fija.

Las congelaciones y plazos de cambio protegen periodos comerciales críticos. Establezca periodos de inmovilización de cambios antes de eventos comerciales importantes (final del año fiscal, lanzamientos de productos y campañas de marketing importantes) evitando problemas inducidos por la implementación durante periodos de alto riesgo.

Calendario de inmovilización de cambios de documentos anualmente comunicando periodos restringidos con suficiente antelación permitiendo a los equipos planificar en consecuencia. Las inmovilizaciones excesivas reducen la velocidad; las inmovilizaciones insuficientes crean riesgo comercial.

Establezca bucles de comentarios que conectan la telemetría operativa con la mejora de agentes.

La recopilación de comentarios de usuarios recopila comentarios explícitos a través de preguntas o encuestas de seguimiento. Recopile comentarios implícitos a través de índices de finalización, distribución a agentes humanos, patrones de reintento y preguntas de seguimiento que indican insatisfacción. Combine señales explícitas e implícitas, proporcionando una perspectiva de calidad integral.

Recopile comentarios en línea, justo cuando sucede y no más tarde. La recopilación de comentarios retrasada reduce los índices de respuesta e introduce sesgos de recuperación.

El análisis de uso expone patrones de conversación reales como temas, preguntas y tendencias que se repiten. Prueban si la complejidad de un agente se mantiene, si las funciones no se utilizan debido a la escasa capacidad de detección y si el uso real valida los supuestos de diseño originales.

Consulte registros de conversaciones analizando tipos de preguntas, longitudes de conversaciones, índices de éxito por tema y satisfacción del usuario por características de conversación. Las guías de análisis de patrones de uso solicitan refinamiento, expansión de la base Knowledge y priorización de funciones.

El análisis de patrones de error identifica problemas de calidad sistemáticos que requieren solución. Analice la agrupación de registros de errores por tipo de error, usuarios afectados, patrones de conversación y distribución temporal. Los patrones de error revelan problemas de solicitudes, brechas de la base Knowledge, problemas de integración o casos extremos que requieren gestión.

Priorice la solución de errores por frecuencia e impacto. Los errores de alta frecuencia que afectan a muchos usuarios garantizan la atención inmediata. Los errores de baja frecuencia pueden representar casos límite aceptables dependiendo de la repercusión comercial y el coste de reparación.

La supervisión de tendencias de calidad realiza un seguimiento de la precisión, relevancia, seguridad y satisfacción a lo largo del tiempo detectando la degradación antes de que se vuelva grave. Establezca líneas base de calidad después de la implementación inicial de agentes. Supervise la calidad continua frente a alertas de líneas base cuando las tendencias disminuyen más allá de umbrales aceptables.

La supervisión de la calidad revela si los cambios de solicitud, las actualizaciones de modelo o las modificaciones de la base de Knowledge mejoran o degradan el rendimiento permitiendo decisiones de mejora dirigidas por datos.

Realice un seguimiento de experimentos que informan sistemáticamente de decisiones de mejora con evidencia empírica.

El marco experimental proporciona una estructura coherente para las mejoras de prueba, incluyendo:

• Hipótesis: qué mejora se espera
• Diseño experimental: cómo se implementan las variantes
• Mediciones: qué resultados se miden
• Tamaño de muestra: cuántas interacciones se necesitan para la validez estadística
• Criterios de éxito: qué resultados justifican la promoción

Documente experimentos antes de la ejecución evitando la interpretación ambigua de resultados. Los criterios de éxito predefinidos permiten decisiones de promoción claras evitando debates prolongados sobre si los resultados son “suficientemente buenos”.

Registros de seguimiento de variantes que los usuarios recibieron y variantes que activan la correlación de resultados. Realice un seguimiento de la asignación de variantes en metadatos de conversación que permiten el análisis de calidad, coste y satisfacción por variante.

La validez estadística garantiza que los experimentos se ejecuten el tiempo suficiente con un tamaño de muestra suficiente para conclusiones fiables. Calcule el tamaño de muestra requerido antes de los experimentos basándose en el tamaño de efecto esperado, los requisitos de potencia estadística y los índices de error aceptables. Las muestras insuficientes producen resultados ruidosos que conducen a malas decisiones.

La optimización de bandidos múltiples asigna dinámicamente más tráfico a variantes de mejor rendimiento durante experimentos. Los enfoques de bandidos de múltiples brazos reducen el coste de oportunidad de la experimentación reduciendo la exposición a variantes inferiores mientras recopilan datos suficientes para el análisis estadístico.

El catálogo de experimentos registra las variantes, los resultados y las decisiones de cada experimento. Impide que los equipos vuelvan a probar enfoques fallidos, difunde aprendizajes por toda la organización y crea un registro compartido de lo que realmente funciona.

La excelencia operativa para sistemas agentes requiere ampliar las prácticas tradicionales de DevOps para abordar características de IA exclusivas. La observabilidad integral permite comprender el comportamiento de agentes emergentes. La gestión sistemática del ciclo de vida garantiza la calidad, la seguridad y el control de costes. Los procedimientos de respuesta a incidentes solucionan modos de fallo específicos de agentes. La mejora continua transforma la experiencia operativa en capacidad organizativa.

Prácticas clave para la excelencia operativa en sistemas de agentes:

• Registre conversaciones completas incluyendo entradas, salidas, rastreos de razonamiento, acciones y resultados.
• Supervise la calidad de las respuestas de forma continua a través de mediciones de precisión, relevancia, seguridad y satisfacción.
• Detecte la desviación del modelo y los cambios de comportamiento a través de la comparación de línea base y la detección de anomalías.
• Solicitudes de control de versión, configuraciones y modelos que activan la reversión y las pruebas A/B.
• Implemente la implementación gradual con indicadores de funciones e implementaciones canarias que limitan el radio de explosión.
• Diseñe disyuntores y jerarquías de reserva evitando fallos de agentes en cascada.
• Realice revisiones posteriores a incidentes sin culpa centrándose en mejoras sistemáticas.
• Establezca puertas de calidad y procesos de aprobación evitando que agentes problemáticos lleguen a producción.
• Cree bucles de comentarios que conectan la telemetría operativa con la mejora de agentes.
• Realice un seguimiento sistemático de los experimentos utilizando pruebas empíricas para guiar las decisiones de mejora.

Las organizaciones que invierten en excelencia operativa para agentes obtienen una ventaja competitiva sostenible a través de funciones de IA fiables y de alta calidad que evolucionan continuamente con las necesidades comerciales.

Comparta sus comentarios sobre el Marco bien diseñado.