Cómo hacer un ejercicio tabletop de incidentes de IA para un AI Sales Copilot B2B

Ensaya decisiones sin provocar un incidente

Un tabletop es un ejercicio guiado y basado en conversación. Presenta una situación ficticia para que las personas expliquen qué harían, con qué autoridad, qué evidencia consultarían y cómo coordinarían la respuesta. No desconecta servicios, no introduce fallas en producción y no necesita secretos ni datos reales de clientes. Su propósito es descubrir ambigüedades antes de que el tiempo y el impacto sean reales.

CISA publica paquetes con funciones para planificación, facilitación, evaluación, participantes, feedback y after-action report. NIST integra la preparación, respuesta, recuperación y mejora dentro de la gestión continua del riesgo. Estas referencias ayudan a diseñar el ejercicio; no convierten el material de Cerravi en un estándar obligatorio, auditoría o certificación.

El resultado no es una actuación perfecta. Es un registro honesto de decisiones, dependencias, demoras, contradicciones y capacidades que deben probarse o corregirse. Una respuesta verbal puede sonar convincente y fallar después en acceso, telemetría o recuperación. Por eso cada observación debe terminar en evidencia o en una acción verificable.

Define pocas preguntas que realmente necesiten respuesta

Empieza por el riesgo, no por una historia espectacular. Elige entre tres y cinco objetivos observables: comprobar quién puede pausar una función, cuánto tarda el equipo en reconocer el alcance, qué activa el modo manual, cómo se conserva evidencia o quién aprueba una comunicación externa. Un objetivo como mejorar la preparación es demasiado amplio para evaluar al final.

Delimita organización, proceso comercial, sistema, versión, entorno, integración, población, idioma, región y periodo simulado. Indica qué componentes participan y cuáles quedan fuera. Si el copiloto depende del CRM, un catálogo, un proveedor de modelos y correo, el escenario debe aclarar cuáles están disponibles, degradados o comprometidos en cada momento.

Selecciona el público por la decisión que ensayarás. Un ejercicio inicial puede concentrarse en ventas, producto, operación y seguridad. Un escenario con datos personales, compromisos contractuales o comunicación pública puede requerir privacidad, legal, soporte y comunicación. No invites a toda la empresa si eso diluye autoridad y conversación.

Construye el escenario desde un riesgo plausible

Usa el registro de riesgos, incidentes anteriores, near misses, hallazgos, cambios y dependencias para elegir un caso. Debe ser plausible para el recorrido observado, no una amenaza genérica copiada de otra industria. También necesita suficiente incertidumbre para que las personas tengan que investigar y decidir, en lugar de adivinar la respuesta esperada por quien facilita.

Un escenario útil para ventas B2B puede empezar con una propuesta que muestra un precio sin fuente vigente. Después aparecen más cuentas afectadas, una discrepancia entre catálogo y documento, una Buyer Room abierta por un destinatario no confirmado y una consulta urgente del cliente. La secuencia permite discutir detección, alcance, contención, datos, comunicación, modo manual y recuperación sin afirmar que la apertura demuestra identidad o aceptación.

No uses conversaciones, nombres, precios o documentos reales. Crea datos sintéticos y marca cada pantalla o mensaje como material de ejercicio. Evita reproducir credenciales, vulnerabilidades explotables o información sensible en una sala amplia. Si el aprendizaje depende de una prueba técnica, prográmala después en un entorno aislado con autorización específica.

Separa planificación, control, juego, observación y registro

El patrocinador autoriza alcance y recursos. La persona que diseña coordina objetivos, escenario y logística. Facilitación presenta información, cuida el tiempo y pregunta sin dirigir a una conclusión. Control decide cuándo entregar injects y responde por el mundo simulado. Los participantes toman decisiones desde su función real. Observadores y evaluadores registran hechos contra los objetivos. Una persona dedicada conserva cronología, acuerdos y preguntas abiertas.

Nombra también la autoridad operacional que existiría durante un incidente: incident commander o función equivalente, investigación técnica, negocio, seguridad, privacidad, legal, soporte, comunicación y autoridad para pausar o reanudar. No todos necesitan estar en la primera conversación, pero el grupo debe saber cuándo y cómo incorporarlos.

Evita que una sola persona facilite, interprete todos los sistemas, evalúe y redacte conclusiones. En equipos pequeños se pueden combinar funciones, pero deben declararse los posibles sesgos. Quien diseñó el control no debería ser la única voz que afirma que funcionaría.

Acordar reglas de seguridad protege el aprendizaje

Abre con un exercise brief: propósito, alcance, tiempo, confidencialidad, reglas, canales y forma de pedir aclaraciones. Declara que nadie ejecutará cambios reales, contactará clientes ni probará production. Las decisiones se expresan como acciones simuladas y se anotan junto con la herramienta, acceso o aprobación que requerirían.

Usa una palabra clara para pausar el juego. Si alguien detecta un incidente real, una exposición activa o una condición que exige intervención, detén el ejercicio y transfiere el mando al proceso real. No mezcles la cronología ficticia con evidencia operacional. Registra el momento de separación y aplica las obligaciones internas correspondientes.

Fomenta conversación sin buscar culpables. Se evalúan rutas, criterios, autoridad y capacidad, no la memoria individual. Al mismo tiempo, no aceptes frases como alguien avisaría o normalmente funciona. Pregunta quién, por qué canal, con qué dato, en cuánto tiempo y qué ocurriría si esa persona o sistema no estuviera disponible.

• No ejecutar acciones sobre cuentas, integraciones o clientes reales.
• No mostrar secretos, datos personales ni información comercial real.
• Decir cuándo una respuesta depende de una suposición.
• Separar observaciones del ejercicio y hechos de producción.
• Detener la simulación ante un incidente real.

Prepara artefactos, canales y evidencia antes de comenzar

Reúne el plan de incidentes, contactos, RACI, arquitectura, inventario, niveles de riesgo, catálogo de servicios, dependencias, procedimientos de pausa, modo manual, recuperación y comunicación. Puedes entregar una parte al inicio y reservar otra como inject. Marca versiones y fechas para que una brecha documental no se confunda con una respuesta incorrecta.

Crea un canal de ejercicio separado, una bitácora, una lista de participantes y una carpeta con acceso controlado. Prepara tarjetas para decisiones materiales: clasificar, contener, escalar, comunicar, recuperar y reanudar. Cada tarjeta registra hora simulada, información disponible, autoridad, opción elegida, motivo, consecuencia esperada y evidencia pendiente.

Ensaya la logística con facilitación y control. Comprueba orden de injects, enlaces, permisos, temporizador, subtítulos o accesibilidad, y un canal privado para ajustar el ritmo. El ensayo técnico no debe revelar a los participantes la resolución del escenario.

Usa injects para revelar información y presión de forma gradual

Un inject es una pieza de información que cambia lo que el grupo sabe o necesita decidir. Puede ser una alerta, reporte de usuario, respuesta de proveedor, captura ficticia, llamada simulada, log resumido o solicitud ejecutiva. Cada uno debe servir a un objetivo. Agregar ruido sin propósito solo consume tiempo.

Diseña una línea de tiempo con condición de entrega, contenido, respuesta esperada, posibles ramas y puntos de evaluación. No fuerces al grupo a seguir el guion si toma una decisión razonable que cambia el recorrido. Control puede adaptar el siguiente inject y conservar la razón de la desviación.

Alterna información técnica, comercial y humana. Primero aparece una anomalía. Después surge evidencia de alcance. Más tarde llega presión por reanudar o comunicar. Así se observa si el equipo conserva criterios bajo incertidumbre. No fabriques una respuesta única cuando existen varias opciones válidas; evalúa si la decisión fue autorizada, informada, trazable y proporcional.

Conduce decisiones, no una presentación

Presenta el contexto mínimo y deja que el grupo trabaje. Cuando aparezca una acción, pregunta quién la inicia, quién decide, qué sistema utiliza, qué información falta y qué alternativa existe. Conserva silencios productivos; no resuelvas la ambigüedad por el equipo. Si la conversación se aleja del objetivo, resume el punto y crea un parking lot.

Registra tiempo real y tiempo simulado por separado. Un equipo puede discutir veinte minutos una decisión que, en el escenario, debía ocurrir en cinco. Esa diferencia ayuda a revisar contactos, accesos o criterios, pero no debe convertirse automáticamente en un incumplimiento. Evalúa contra la expectativa que la organización haya definido y documentado.

Pide que las personas usen su autoridad y procesos actuales, no una organización ideal. Si alguien necesita un dato inexistente, anota la dependencia. Si una aprobación no tiene suplente, simula indisponibilidad. Si dos funciones creen tener la A, conserva el conflicto como observación; no lo escondas para mantener el ritmo.

Ejemplo: una propuesta contiene un precio sin respaldo

A las 09:10, una gerente reporta que una propuesta generada muestra un importe que no encuentra en el catálogo vigente. El primer objetivo es clasificar el reporte y evitar nuevos envíos sin destruir evidencia. El grupo debe decidir quién recibe el caso, cómo identifica cuenta, versión, fuente y documento, y qué límite activa mientras confirma el alcance.

A las 09:25 aparece una segunda propuesta de otra cuenta y se descubre una importación incompleta del catálogo. A las 09:40 un cliente pregunta si el importe es válido. A las 10:00 el proveedor confirma que el modelo no cambió. A las 10:20 liderazgo pide restablecer el flujo por una negociación importante. Cada inject obliga a separar causa, alcance, presión comercial y condición de reanudación.

Una respuesta sólida puede limitar la generación o envío afectado, preservar documentos y logs, verificar catálogo y permisos, activar cotización manual, preparar una comunicación basada en hechos y exigir regresión antes de reanudar. No debe interpretar actividad de Buyer Room como confirmación del destinatario ni mezclar MXN y USD para estimar impacto. Tampoco puede asumir que el proveedor descartado elimina una falla de integración o proceso.

Prueba contención, continuidad, comunicación y recuperación

La contención reduce exposición sin borrar la posibilidad de investigar. Pregunta si el equipo puede limitar una función, fuente, versión, integración, usuario o población; quién tiene acceso; y qué efecto secundario produce. Una desactivación total puede ser proporcional o excesiva según alcance. La decisión necesita motivo, dueño y criterio para revisarla.

El modo manual conserva el trabajo esencial. Define qué tareas continúan, con qué plantilla y catálogo, quién revisa, cómo se evita duplicar registros y cuánto tiempo puede sostenerse. Una alternativa no probada es una hipótesis. El ejercicio debe producir una prueba posterior o mostrar evidencia de una validación vigente.

La comunicación separa hechos, inferencias y desconocidos. Identifica audiencias internas y externas, autoridad de aprobación, canal, frecuencia y punto de contacto. No prometas causa, impacto o fecha de recuperación antes de tener evidencia. La reanudación exige corrección, regresión, alcance limpio, riesgo residual aceptado, monitoreo reforzado y autoridad explícita; no solo ausencia de nuevas alertas.

Cierra con un hotwash y un after-action report útil

Reserva tiempo al final para una conversación inmediata. Pregunta qué funcionó, qué generó espera, qué dato o acceso faltó, qué supuesto resultó incorrecto y qué debería conservarse. Incluye participantes, observadores, control y facilitación. El hotwash captura memoria fresca; no sustituye el análisis posterior ni obliga a aceptar una conclusión sin contraste.

El after-action report describe alcance, objetivos, escenario, participantes, cronología, decisiones, fortalezas, observaciones, limitaciones y evidencia. Distingue una falla observada, una capacidad declarada pero no comprobada y una mejora deseable. Evita nombres en señalamientos personales salvo que el proceso interno lo requiera y exista una finalidad legítima.

Relaciona cada observación con objetivo, riesgo, control, proceso o dependencia. Asigna severidad solo con criterios definidos. Una frase como comunicación deficiente no es accionable. Especifica qué audiencia, mensaje, autoridad, canal o tiempo quedó ambiguo y qué resultado debería existir después de corregirlo.

Convierte observaciones en corrección, prueba y aprendizaje

Cada acción necesita responsable con autoridad, fecha, dependencia, resultado esperado, evidencia y criterio de cierre. Separa contención inmediata, corrección del procedimiento, mejora técnica, capacitación y decisión de riesgo. Cambiar un documento no demuestra que el nuevo recorrido funciona; cierra con una muestra, prueba o ejercicio focalizado.

Prioriza por impacto potencial, exposición actual y capacidad para intervenir. No cierres todo como capacitación cuando la causa es un permiso, dato o diseño. Tampoco automatices una ruta cuya autoridad sigue ambigua. Los asuntos legales, contractuales o regulatorios quedan pendientes de la función competente y de las jurisdicciones aplicables.

Mide tiempo hasta triage y decisión, dependencias no disponibles, acciones vencidas, recurrencia, cobertura de retest y cambios que llegaron a controles. Estas medidas describen preparación y seguimiento bajo el escenario observado; no son una probabilidad de seguridad. Repite el ejercicio cuando cambien sistema, autonomía, proveedor, datos o autoridad, o cuando una falla real revele un riesgo material.

• Observación vinculada con un hecho y un objetivo.
• Acción con dueño, fecha, dependencia y prioridad.
• Criterio de cierre y evidencia esperada.
• Prueba, muestra o ejercicio focalizado para validar.
• Riesgo residual y autoridad que acepta o escala.

Respeta los límites verificables de Cerravi

En Cerravi, Copilot organiza contexto y propone siguientes pasos, pero no envía mensajes ni cambia etapas automáticamente. Las propuestas usan productos y precios disponibles en el catálogo; si falta un importe, la persona debe confirmarlo y el sistema no debe inventarlo. El ejercicio puede comprobar si estas fronteras se mantienen en la versión y configuración observadas.

MXN, USD y otras monedas permanecen separadas salvo una conversión aprobada. La actividad de Buyer Room no confirma identidad, aceptación, contrato, pago o intención. Forecast utiliza reglas transparentes del CRM y no garantiza cierres. Un escenario no debe pedir a las personas que traten estas señales como certezas para simplificar la historia.

Cerravi puede aportar registros, configuración y evidencia dentro de su alcance. No decide la clasificación legal de un incidente, no sustituye asesoría de seguridad, privacidad o legal y no certifica la preparación de la organización. Integraciones, automatizaciones o fuentes añadidas por cada empresa cambian el recorrido y requieren su propio ejercicio.