Cómo gestionar cambios de un AI Sales Copilot en producción

Trata como cambio todo lo que pueda alterar una decisión o una salida

Cambiar el modelo es solo uno de los casos. También cuentan una instrucción del sistema, un prompt, una fuente de conocimiento, una regla de recuperación, un permiso, una herramienta, una integración, un umbral, una política, una interfaz o el punto donde una persona debe aprobar. Incluso una actualización del proveedor puede modificar latencia, disponibilidad o comportamiento sin que el flujo visible parezca distinto.

El criterio útil no es si la modificación parece pequeña, sino si puede cambiar qué datos entran, qué resultado aparece, quién puede verlo, qué acción puede prepararse o ejecutarse y cómo se detecta un error. Una corrección de redacción puede ser menor; una frase que amplía el alcance de una recomendación puede requerir volver a validar el escenario completo.

Microsoft señala que un agente puede dejar de cumplir expectativas cuando cambian modelos, datos o uso. Por eso una aprobación inicial no cubre automáticamente todas las versiones posteriores.

Mantén un inventario de la versión que realmente está activa

Antes de cambiar, identifica la configuración en producción. Registra versión del agente, modelo o modalidad de selección, instrucciones, fuentes, herramientas, permisos, integraciones, políticas, responsables y fecha de publicación. Añade los escenarios que esa versión fue autorizada para atender y los límites comunicados a los usuarios.

El inventario debe apuntar a artefactos reproducibles. Escribir que se usa “el prompt nuevo” o “el modelo rápido” no permite comparar, investigar ni revertir. Usa identificadores estables, historial de cambios y acceso restringido a secretos. No copies credenciales dentro del registro de versión.

Conserva la configuración anterior mientras la nueva se estabiliza. Una captura aislada ayuda a explicar lo visible, pero no sustituye archivos, parámetros, reglas y dependencias necesarios para reconstruir el estado.

Abre una solicitud con propósito, alcance y responsable

Una solicitud de cambio debe explicar qué problema observable intenta resolver, qué evidencia lo muestra y qué resultado permitiría evaluar la modificación. Añade el componente afectado, personas o procesos incluidos, dependencias, fecha propuesta y una persona responsable de coordinar la decisión.

Declara también lo que queda fuera. Si el cambio busca mejorar el resumen de una oportunidad, no lo presentes como una mejora general de ventas. Si modifica una fuente para un país o catálogo, no asumas que quedó validado para todas las regiones.

Relaciona la solicitud con incidentes, feedback, métricas o cambios del proveedor cuando existan, pero distingue correlación de causa. El volumen de comentarios no demuestra por sí solo que la solución propuesta sea correcta.

Clasifica el impacto antes de elegir la profundidad de la prueba

Evalúa qué datos puede leer o generar la nueva versión, quién verá el resultado, si interviene en una decisión, si prepara una comunicación externa, si puede afectar dinero o compromisos, si cambia la identidad o los permisos y qué tan reversible es. Considera además población, frecuencia, sensibilidad y capacidad de detectar una salida incorrecta.

Usa niveles comprensibles para la organización. Un cambio acotado y reversible puede seguir una revisión ligera. Un cambio que añade una fuente sensible, amplía permisos, altera precios, influye en personas o habilita una acción externa necesita participación de las funciones responsables y pruebas más profundas.

La clasificación debe producir una decisión operativa: pruebas requeridas, revisores, entorno, tamaño del rollout, monitoreo y autoridad de aprobación. Una etiqueta de riesgo sin consecuencias prácticas no controla el cambio.

• Datos: origen, sensibilidad, vigencia y ámbito.
• Personas: usuarios, clientes y terceros afectados.
• Decisiones: recomendación, preparación, aprobación o ejecución.
• Acceso: identidad, permisos y separación entre cuentas.
• Operación: volumen, latencia, disponibilidad y soporte.
• Reversibilidad: tiempo, evidencia y alternativa manual.

Prueba contra una línea base y casos representativos

Define el conjunto de evaluación antes de mirar el resultado final. Incluye casos habituales, datos incompletos, ambigüedad, solicitudes fuera del alcance, intentos de cambiar instrucciones, permisos insuficientes y escenarios comerciales de alto impacto. Usa datos sintéticos o minimizados cuando sean suficientes.

Compara la versión candidata con la versión activa usando los mismos casos y criterios. Registra resultados aceptados, corregidos y descartados, además de errores, latencia y escalaciones cuando sean relevantes. Conserva ejemplos concretos; una puntuación agregada puede ocultar una falla crítica.

No selecciones únicamente ejemplos donde la nueva versión luce mejor. Si cambias el conjunto, la rúbrica o la población, documenta la diferencia y evita presentar ambos resultados como una comparación directa.

Separa preparación, revisión y autorización según el impacto

La persona que modifica la configuración puede preparar evidencia, pero no debería ser la única que decide si el cambio está listo cuando existe impacto relevante. Negocio valida el proceso y el lenguaje comercial; tecnología revisa configuración y recuperación; datos confirma fuentes; seguridad y privacidad evalúan acceso; soporte prepara respuesta; la función autorizada toma la decisión final.

No todas las modificaciones necesitan un comité. Ajusta el número de revisores al impacto, pero conserva una persona responsable, criterios visibles y registro de la aprobación. La urgencia comercial no elimina controles; si existe una emergencia, usa un procedimiento excepcional con alcance, vencimiento y revisión posterior.

La salida debe ser explícita: aprobada, aprobada con condiciones, rechazada o pendiente de evidencia. El silencio en un canal no equivale a autorización.

Publica una versión nueva sin sobrescribir la evidencia anterior

Microsoft Foundry recomienda guardar cambios posteriores como versiones nuevas e inmutables para poder probar, comparar y conservar integridad. Aplica el mismo principio aunque la plataforma no lo haga automáticamente: asigna un identificador, vincula configuración y pruebas, y registra qué versión reemplaza.

Las notas de versión deben explicar el propósito, componentes modificados, escenarios afectados, riesgos conocidos, controles, responsables, fecha y plan de reversión. Escribe para operación y soporte, no solo para desarrollo.

Separa desarrollo, pruebas y producción. Cuando el riesgo lo justifique, mantén en paralelo una versión estable y una candidata con identidad y acceso claramente diferenciados. Evita probar sobre usuarios reales sin que el alcance y el tratamiento de datos estén autorizados.

Despliega con alcance limitado y una puerta de ampliación

Empieza con el grupo, proceso o escenario mínimo que permita observar la nueva condición. El objetivo no es llamar beta a producción, sino reducir el área de impacto mientras se confirma que los controles funcionan con uso real autorizado.

Define duración, población, versión, soporte, señales, criterios de éxito y condiciones para pausar. Asegura que los usuarios sepan qué cambió, qué sigue igual, qué revisar y dónde reportar. Una activación silenciosa dificulta interpretar feedback y rastrear efectos.

Al terminar la ventana, decide ampliar, mantener, corregir, repetir, revertir o retirar. La fecha del siguiente despliegue expresa intención; la puerta de preparación determina si puede avanzar.

Compara antes y después sin inventar causalidad

Monitorea operación, calidad, riesgo, adopción y efecto comercial por separado. Publica definición, numerador, denominador, población, fuente y periodo. Etiqueta los eventos con la versión activa para no mezclar resultados de configuraciones distintas.

Busca cambios en errores, latencia, correcciones, resultados descartados, abstenciones, escalaciones, permisos, tickets e incidentes. Segmenta los escenarios críticos y los grupos que podrían experimentar un efecto diferente. La ausencia de reportes no prueba ausencia de problemas.

Una diferencia posterior al despliegue no demuestra que el cambio la causó. Pueden intervenir capacitación, estacionalidad, composición de la población, cambios del CRM o del catálogo. Describe la observación, las hipótesis y la evidencia pendiente.

Revierte o contiene sin borrar el historial

Define antes del lanzamiento qué señales obligan a pausar: acceso indebido, exposición de datos, resultado comercial de alto impacto sin control, degradación repetida, pérdida de trazabilidad o soporte desbordado. Identifica quién declara la pausa y quién autoriza la recuperación.

Revertir significa restaurar una configuración conocida y limitar el efecto; no eliminar entradas, salidas o decisiones necesarias para investigar. Si la versión anterior ya no es segura o compatible, usa controles alternativos: deshabilitar una herramienta, retirar una fuente, exigir aprobación o pasar a proceso manual.

Cuando el caso supera el cambio normal, activa el playbook de incidentes. La recuperación requiere confirmar contención, probar el estado restaurado, comunicar el alcance y mantener monitoreo reforzado.

Cierra el cambio y retira versiones que ya no deben usarse

El cambio termina cuando existe una decisión documentada, los materiales reflejan la versión activa, las acciones pendientes tienen responsable y las configuraciones antiguas reciben un tratamiento explícito. Retira accesos, endpoints, credenciales, fuentes y documentación que podrían mantener una versión obsoleta en uso.

Registra qué evidencia confirmó la decisión, qué incertidumbre permanece y cuándo volverá a revisarse. Si la nueva versión no aporta el efecto esperado, conservarla por el esfuerzo invertido no es una razón operativa.

En Cerravi, las sugerencias requieren revisión humana. Los precios proceden del catálogo disponible y un importe faltante exige confirmación; las monedas permanecen separadas. La actividad de una Buyer Room aporta contexto, pero no demuestra identidad, aceptación ni intención. El Forecast usa reglas transparentes del CRM y no garantiza cierre o ingresos.