Cómo responder a incidentes de AI Sales Copilot en ventas B2B

Distingue un incidente de una corrección normal

No toda respuesta imperfecta constituye un incidente. Una sugerencia que el usuario detecta, corrige y descarta dentro del flujo previsto puede ser feedback de calidad. El caso cambia cuando existe o puede existir daño relevante: acceso indebido, exposición de datos, acción fuera del alcance, compromiso comercial incorrecto, pérdida de trazabilidad o degradación repetida que el control habitual no contiene.

La clasificación debe considerar el efecto real y potencial, las personas y cuentas involucradas, la reversibilidad, la sensibilidad de los datos y la capacidad de limitar la propagación. La novedad de una salida no determina por sí sola su gravedad.

Separa además incidentes de seguridad, privacidad, calidad, disponibilidad, datos, permisos y proceso. Pueden compartir un mismo punto de entrada, pero requieren responsables y decisiones diferentes. Si existe duda razonable sobre exposición o impacto, escala primero y reclasifica después con evidencia.

Prepara autoridad, señales y alternativa manual antes del incidente

NIST incluye respuesta, recuperación, comunicación, override, cambio y retiro dentro del monitoreo posterior al despliegue. Eso exige definir antes de una crisis quién puede limitar una función, revocar acceso, declarar el incidente, coordinar la respuesta y autorizar la reanudación.

Escribe señales observables para activar el proceso: dato sensible en una salida, usuario fuera de su ámbito, precio o condición no respaldados por una fuente aprobada, mensaje ejecutado sin revisión, comportamiento anómalo repetido o dependencia crítica no disponible. Añade un canal visible para reportarlas.

Mantén una alternativa no basada en IA para las tareas esenciales. Puede ser revisar oportunidades directamente en el CRM, usar una plantilla aprobada o confirmar precios en el catálogo. El modo manual necesita responsables, acceso y materiales vigentes; nombrarlo sin probarlo no crea continuidad.

Abre un registro único y confirma lo que realmente ocurrió

El primer registro debe incluir hora, persona que reporta, función afectada, cuenta u oportunidad relacionada, resultado observado, acción posterior y alcance conocido. Distingue hechos, hipótesis y datos todavía pendientes. Evita copiar información personal o comercial sensible fuera de los sistemas autorizados.

Confirma si la salida fue solo visible, guardada, compartida o ejecutada. Un borrador descartado y una comunicación enviada a un comprador tienen impactos distintos. También verifica si el caso pertenece a una versión, fuente, permiso, integración o grupo de usuarios concretos.

Asigna una persona al mando y un canal de coordinación. Las áreas pueden investigar en paralelo, pero la decisión de contener, comunicar y recuperar necesita una vista común. Los mensajes dispersos no sustituyen una cronología.

Clasifica la severidad por impacto y urgencia

Usa pocos niveles comprensibles y adapta sus nombres a la organización. Evalúa confidencialidad, integridad, disponibilidad, efecto sobre personas, compromisos comerciales, obligaciones aplicables, número de casos, reversibilidad y velocidad de propagación.

Una salida extraña sin uso posterior puede requerir análisis y corrección. Un acceso indebido, una condición comercial enviada sin respaldo o una acción que continúa propagándose puede exigir contención inmediata y participación de seguridad, privacidad, legal u otras funciones responsables.

La severidad inicial es una hipótesis operativa. Actualízala cuando aparece evidencia y registra por qué cambió. No rebajes un caso para proteger una métrica ni lo eleves solo porque contiene IA.

Contén el alcance sin destruir la evidencia

La primera meta no es encontrar toda la causa, sino detener el impacto. Según el caso, limita la función, revoca una sesión o permiso, detén una integración, retira una fuente, obliga a revisión humana o regresa el proceso a modo manual. Aplica la medida más acotada que controle el riesgo conocido, salvo que el alcance todavía sea incierto.

Conserva entradas, salidas, fuentes, versión, permisos, decisiones y cronología necesarias para investigar. Restringe el acceso a esa evidencia y respeta las reglas de privacidad y retención. Borrar el registro para que la salida deje de verse puede impedir entender el incidente.

Microsoft recomienda mecanismos confiables a nivel de sistema para pausar o detener agentes y mantener registros accesibles para auditoría y respuesta. Una instrucción dentro del prompt no sustituye un control de acceso, una aprobación o una interrupción operativa.

Revisa cuentas, propuestas y compromisos afectados

Identifica qué oportunidades, contactos, propuestas, Buyer Rooms, tareas o mensajes pudieron recibir el resultado. No asumas que una salida visible fue enviada ni que una apertura confirma lectura. Busca evidencia de cada transición.

Si un comprador recibió información incorrecta, coordina una corrección clara con las funciones responsables. Conserva la versión anterior, explica qué dato cambia y confirma el siguiente paso. No atribuyas una intención al cliente ni uses el incidente para crear urgencia artificial.

Los precios deben volver a una fuente aprobada. Un importe ausente no se completa con una estimación, y MXN, USD u otras monedas permanecen separadas. La respuesta al incidente tampoco autoriza condiciones comerciales nuevas.

• Lista de cuentas y oportunidades potencialmente afectadas.
• Versión exacta de propuesta o contenido compartido.
• Destinatarios, canal, hora y estado verificable.
• Dato correcto y fuente autorizada.
• Persona responsable de la corrección.
• Siguiente paso y evidencia de cierre.

Investiga con una cronología y preguntas reproducibles

Reconstruye el caso con el contexto disponible: entrada, salida, datos recuperados, fuente, versión de configuración, modelo o proveedor cuando corresponda, permisos, herramientas, usuario, hora y acciones posteriores. La observabilidad debe permitir explicar qué ocurrió sin registrar información innecesaria.

Separa la causa inmediata de las condiciones que permitieron el impacto. Una salida incorrecta puede combinar datos incompletos, una fuente obsoleta, un permiso excesivo, una instrucción ambigua y una revisión humana sin contexto suficiente.

Prueba hipótesis en un entorno controlado. No reproduzcas el incidente con datos reales si una muestra minimizada o sintética es suficiente. Documenta qué pudo reproducirse, qué no y qué incertidumbre permanece.

Comunica hechos confirmados, acciones y próximo corte

Cada audiencia necesita información distinta. Los usuarios deben saber qué función no usar y qué alternativa seguir. Soporte necesita síntomas y criterios de escalamiento. Liderazgo necesita impacto, decisiones y recursos. Las funciones de control determinan obligaciones adicionales según el caso y la jurisdicción.

Distingue lo confirmado de lo investigado. Indica cuándo habrá una nueva actualización, aunque todavía no exista una causa. Evita minimizar, culpar al usuario o prometer una hora de recuperación sin evidencia.

Si una persona externa está afectada, coordina el mensaje con quienes tienen autoridad. Esta guía no sustituye asesoría jurídica, obligaciones de notificación ni procedimientos de seguridad o privacidad de la empresa.

Reanuda por etapas y con una puerta explícita

Corregir una configuración no basta para cerrar el incidente. Define criterios de recuperación: contención confirmada, causa o condición controlada, prueba representativa, permisos revisados, evidencia conservada, proceso manual disponible, responsables informados y monitoreo reforzado.

Reanuda primero con el alcance mínimo necesario. Prueba escenarios normales y excepciones relacionadas con el incidente. Una persona con autoridad distinta de quien aplicó el cambio debe revisar los resultados cuando el impacto lo justifique.

La salida de la puerta puede ser reanudar, mantener la limitación, probar de nuevo, cambiar el proceso o retirar la función. El calendario no obliga a restaurar una capacidad que todavía supera la tolerancia acordada.

Cierra con aprendizaje, no solo con servicio restaurado

Realiza una revisión sin buscar culpables. Describe la cronología, el impacto, las decisiones, qué funcionó, qué retrasó la respuesta y qué señales habrían permitido actuar antes. Incluye incidentes evitados o near misses; revelan controles débiles antes de que exista un daño mayor.

Convierte cada acción en un cambio verificable con responsable, fecha y criterio de cierre. Puede afectar permisos, fuentes, pruebas, interfaz, capacitación, soporte, alertas o autoridad. Registra la nueva versión y evita mezclar métricas anteriores y posteriores como si las condiciones fueran iguales.

Mide detección, contención, recuperación, recurrencia y acciones pendientes con definición, población, fuente y periodo. No uses un tiempo promedio aislado para declarar que la operación es segura. La ausencia de reportes tampoco prueba ausencia de incidentes.

Mantén los límites del copiloto dentro de la operación comercial

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

Un incidente no convierte esas señales en hechos ni autoriza acciones automáticas. El registro de la oportunidad debe conservar qué se observó, qué se corrigió, quién decidió y cuál es el siguiente paso. Las monedas permanecen separadas.

Cerravi puede organizar contexto y trabajo comercial; la empresa sigue siendo responsable de sus procesos, accesos, comunicaciones, revisiones y obligaciones aplicables. El playbook debe adaptarse al riesgo y a la estructura real de cada organización.