Respuesta directa
En pocas palabras
Para crear un plan de continuidad de un AI Sales Copilot, define primero qué resultados comerciales deben continuar; identifica procesos, datos, personas, integraciones y terceros críticos; establece impacto y tiempo máximo tolerable por escenario; documenta RTO y RPO como objetivos internos; diseña niveles de degradación y un modo manual con capacidad, autoridad y controles; prepara recuperación, conciliación y comunicación; prueba cada dependencia en condiciones seguras; y convierte resultados en mejoras con responsable y fecha. El plan preserva operaciones esenciales, no garantiza disponibilidad, seguridad, cumplimiento ni recuperación dentro de un plazo universal.
La continuidad protege el resultado comercial, no la presencia de IA
Un plan de continuidad responde cómo conservar trabajo esencial cuando el copiloto, una fuente, integración, identidad o proveedor deja de estar disponible o ya no puede utilizarse con seguridad. No intenta mantener todas las funciones a cualquier costo. Puede reducir el servicio, suspender IA y volver temporalmente a un proceso humano si eso protege clientes, datos y compromisos comerciales.
NIST AI RMF propone verificar procesos de contingencia para sistemas de IA críticos, revisar bypass, respaldo y desactivación, y comprender consecuencias aguas arriba y abajo. NIST SP 800-34 estructura la planificación alrededor de prioridades, recuperación y pruebas. Son referencias voluntarias para adaptar; no crean un SLA, certificación o obligación universal para Cerravi.
El resultado útil es un conjunto pequeño de decisiones ejecutables: qué debe seguir, qué puede esperar, qué se limita, quién activa la alternativa, con qué información se trabaja, cómo se reconcilia después y qué evidencia permite volver. Una lista de contactos sin recorrido probado no constituye continuidad operacional.
Define escenarios y fronteras antes de asignar tiempos
Delimita organización, proceso, caso de uso, versión, ambiente, equipos, regiones, monedas, canales y periodo. Distingue indisponibilidad total, degradación de calidad, datos atrasados, catálogo no vigente, identidad fallida, integración interrumpida, proveedor inaccesible y una pausa deliberada por incidente. Cada condición puede requerir una respuesta diferente.
Registra qué queda fuera y qué plan relacionado toma el control. Un incidente de seguridad puede activar contención y preservación de evidencia antes de continuidad. Una falla física o de red puede depender del plan tecnológico. Una obligación contractual puede cambiar la comunicación. Los planes se conectan, pero no deben competir por autoridad durante la misma hora.
Separa componentes reemplazables del servicio completo. El modelo puede fallar mientras CRM y catálogo siguen disponibles. Una integración puede detenerse sin apagar lectura del pipeline. Diseñar por componente permite una degradación proporcional y evita que una falla localizada elimine trabajo que todavía es seguro.
Analiza impacto por actividad y horizonte temporal
Haz un análisis de impacto sobre actividades concretas: preparar una propuesta, validar precios, revisar una oportunidad, responder una consulta, compartir una Buyer Room, registrar acuerdos o producir Forecast. Para cada una identifica volumen, ventanas críticas, dependencia de datos, trabajo acumulable, personas afectadas y consecuencia de una demora o error.
Observa cómo crece el impacto. Una hora sin recomendaciones puede ser tolerable; una jornada sin acceso al catálogo durante un cierre puede detener propuestas; varios días sin historial pueden producir duplicados o compromisos contradictorios. Separa pérdida de productividad, ingreso diferido, experiencia del cliente, datos, seguridad, privacidad, operación y obligaciones aplicables.
No conviertas cualquier inconveniente en crítico. Prioriza por consecuencia y tiempo, no por visibilidad ejecutiva. Conserva supuestos y fecha de corte. La tolerancia puede cambiar por temporada, campaña, cierre trimestral, región o concentración en una sola persona.
| Criterio | Impacto si se detiene | Alternativa inicial |
|---|---|---|
| Validar precios | Riesgo de compartir importes incorrectos | Catálogo aprobado y revisión manual |
| Registrar acuerdos | Pérdida de contexto y duplicidad | Bitácora temporal con dueño |
| Preparar borradores | Demora y carga adicional | Plantilla controlada sin generación |
| Leer Forecast | Menor visibilidad de gestión | Exportación vigente por moneda |
| Actividad Buyer Room | Señales incompletas | Seguimiento acordado con el cliente |
Clasifica funciones por niveles de servicio degradado
Define qué experiencia existe en operación normal, degradada, mínima y suspendida. Normal incluye las capacidades aprobadas. Degradada conserva el flujo con menos fuentes o automatización. Mínima protege solo tareas esenciales mediante controles humanos. Suspendida detiene la función porque no puede operar dentro de tolerancia.
Cada nivel necesita disparador, funciones disponibles, público, límites, responsable y salida. No uses una etiqueta amarilla sin comportamiento técnico u operativo. Si la recomendación se desactiva, la interfaz y capacitación deben dejar claro qué información ya no está disponible y qué proceso sustituye ese paso.
Evita que degradado signifique sin control. Al contrario, puede requerir menor volumen, doble revisión, plantillas bloqueadas, datos de solo lectura o prohibición de compartir externamente. La capacidad manual determina cuánto trabajo puede aceptar el equipo; una cola ilimitada es una falla diferida.
Usa MTD, RTO y RPO como objetivos explícitos y limitados
El tiempo máximo tolerable de interrupción describe cuándo el impacto deja de ser aceptable para una actividad. El RTO orienta en cuánto tiempo se busca restaurar un nivel definido. El RPO expresa cuánta pérdida o atraso de datos puede tolerarse desde el último punto recuperable. Define estos valores por proceso y escenario; un único número para todo el producto oculta diferencias materiales.
Relaciona cada objetivo con una fuente, un dueño y una capacidad observada. Si restaurar acceso depende de una persona sin suplencia o recuperar datos nunca se ha probado, el objetivo es una aspiración. Registra tiempo de detección, decisión, activación, ejecución y validación por separado para saber dónde se consume la ventana.
RTO y RPO internos no son promesas públicas, garantías ni términos contractuales. Los compromisos externos requieren definición, alcance, exclusiones, medición y revisión jurídica y comercial. Tampoco uses promedios para esconder una recuperación que excedió el límite en un proceso crítico.
| Criterio | Pregunta | Evidencia necesaria |
|---|---|---|
| MTD | ¿Cuándo el impacto resulta intolerable? | Análisis de impacto y autoridad de riesgo |
| RTO | ¿Cuándo debe volver un nivel definido? | Cronología de prueba y recursos disponibles |
| RPO | ¿Cuánto dato puede faltar o llegar tarde? | Puntos recuperables y conciliación probada |
Mapea dependencias y elimina el respaldo imaginario
Traza CRM, base de datos, catálogo, archivos, identidad, correo, almacenamiento, DNS, red, modelo, API, observabilidad, secretos, personas, procedimientos y proveedores. Identifica qué componente alimenta, autoriza, ejecuta o demuestra cada actividad. Una copia de datos no recupera una integración si faltan credenciales, esquema, versión o persona capaz de operarla.
Busca puntos únicos: un administrador, una cuenta propietaria, una región, una clave, un proveedor, una exportación o una plantilla. Evalúa concentración compartida. Dos servicios pueden parecer redundantes y depender del mismo proveedor cloud, identidad o fuente. Documenta dependencias de terceros y condiciones para soporte, portabilidad, acceso a datos y salida.
Verifica el respaldo. Confirma alcance, frecuencia, cifrado, acceso, retención, integridad y restauración. Una captura o exportación manual puede ser suficiente para un proceso limitado, pero debe conservar estructura, fecha y responsable. No copies datos personales o comerciales sin finalidad, autorización y protección adecuadas.
Diseña un modo manual que pueda sostenerse de verdad
Para cada actividad define entrada, plantilla, fuente autorizada, validación, almacenamiento temporal, aprobación, comunicación y responsable. Indica qué no puede hacerse manualmente. Preparar una propuesta puede continuar con catálogo aprobado y plantilla versionada; inferir precios, convertir monedas sin regla o reconstruir intención desde actividad incompleta no.
Calcula capacidad. Cuántos casos por hora puede atender el equipo, qué prioridad usa, cuándo cierra la cola y qué apoyo adicional necesita. La continuidad no debe trasladar silenciosamente una carga imposible a ventas u operaciones. Protege descansos, turnos, suplencia y escalamiento.
Mantén controles proporcionales: mínimo privilegio, revisión de destinatario, versión, producto, cantidad, impuestos, vigencia y moneda. Una hoja temporal requiere acceso, identificadores y fecha. Define quién la reconcilia y elimina después. El modo manual no autoriza atajos permanentes ni datos fuera del alcance aprobado.
Define quién activa, comunica y cambia de nivel
Establece disparadores observables: salud técnica, error, latencia, datos vencidos, catálogo sin validación, proveedor caído, permiso indisponible, control crítico fallido o incidente activo. Una señal abre evaluación; la autoridad decide el nivel salvo que exista una regla automática segura y aprobada.
Asigna mando, dueño del proceso, operación técnica, datos, seguridad, privacidad, soporte, comunicación y autoridad de negocio. Nombra suplentes y límites. Quien detecta una condición grave debe poder contener sin esperar una reunión completa, mientras la reanudación puede exigir evidencia y aprobación adicionales.
La comunicación identifica audiencia, hecho confirmado, impacto conocido, alternativa, acciones esperadas, siguiente actualización y contacto. Separa usuarios, liderazgo, clientes y proveedores. No atribuyas causa ni prometas recuperación antes de comprobarla. Los asuntos contractuales o regulatorios se elevan a las funciones competentes.
Recupera por etapas y valida antes de ampliar
El runbook comienza con precondiciones: causa o condición delimitada, componente disponible, configuración correcta, datos recuperables, secretos vigentes y personal autorizado. Después restaura en un entorno controlado, ejecuta smoke tests, valida casos representativos y comprueba observabilidad antes de exponer usuarios o acciones externas.
Vuelve por etapas: lectura, asistencia interna, borradores, funciones externas y volumen normal. El orden depende del riesgo. Define rollback y criterio para detener cada etapa. Una respuesta HTTP saludable no demuestra catálogo vigente, permisos correctos, monedas separadas o calidad suficiente para compartir una propuesta.
Conserva evidencia de versión, datos, prueba, aprobador, hora y limitaciones. Aplica monitoreo reforzado durante una ventana definida. La recuperación técnica y la continuidad del negocio se cierran por separado: el servicio puede estar disponible mientras quedan registros por conciliar, clientes por informar o decisiones por revisar.
Reconcilia datos y decisiones creados durante la interrupción
Inventaría todo registro temporal: propuestas, tareas, contactos, notas, etapas, precios, aprobaciones y comunicaciones. Usa identificadores para detectar duplicados y define fuente de verdad por campo. No importes en masa antes de comparar versiones, propietarios, fechas, monedas y relaciones.
Clasifica conflictos: coincidencia, dato nuevo, cambio concurrente, duplicado, dato inválido o decisión que requiere revisión. Asigna resolución humana cuando el contexto comercial importa. Conserva una bitácora de importación, rechazo y corrección. Eliminar el archivo temporal ocurre después de validar conciliación y de acuerdo con la retención aplicable.
Recalcula métricas y Forecast solo después de restaurar cobertura suficiente. Marca periodos incompletos para que un dashboard no presente continuidad aparente. Una actividad atrasada puede registrarse con su fecha real y fecha de carga; no debe parecer ejecutada durante la indisponibilidad.
Prueba el plan sin poner en riesgo producción
Combina revisión de escritorio, walkthrough, tabletop, restauración aislada, prueba de modo manual y ejercicio técnico autorizado. Cada método responde preguntas distintas. Un tabletop descubre autoridad ambigua; una restauración comprueba archivos y tiempos; un turno manual revela capacidad y carga; una reconciliación de muestra encuentra duplicados y campos sin dueño.
Define objetivo, alcance, datos sintéticos, condiciones de parada, participantes, evidencia y criterio de éxito. No desconectes producción ni bloquees a clientes para demostrar preparación. Las pruebas con fallas controladas requieren entorno, autorización, observabilidad y rollback específicos.
Mide detección, decisión, activación, capacidad, recuperación, validación, conciliación y comunicación. Registra supuestos y ayuda extraordinaria. Si una persona preparó accesos o corrigió datos fuera del procedimiento, ese apoyo forma parte del resultado. Convierte observaciones en acciones y repite el tramo afectado.
Mantén el plan con cambios, pruebas e incidentes
Revisa el plan cuando cambien modelo, fuente, prompt, integración, proveedor, región, permiso, identidad, equipo, volumen o autoridad. Incidentes, near misses, pruebas, hallazgos y cambios contractuales pueden reabrirlo antes del calendario. Actualiza inventario, contactos, capacidad, runbooks y datos de prueba juntos.
Mide cobertura de actividades críticas, alternativas probadas, objetivos alcanzados, acciones vencidas, fallas repetidas, dependencias sin suplencia y tiempo desde la última restauración. No fabriques un score de resiliencia que compense una brecha material con varias métricas verdes.
Cada acción conserva dueño, fecha, evidencia y criterio de cierre. Una prueba vencida no significa que la recuperación fallará, pero sí que la afirmación ya no está sustentada con la vigencia acordada. Decide revalidar, limitar, aplicar un compensatorio o aceptar temporalmente con autoridad.
Aplica continuidad sin cambiar los límites de Cerravi
Cerravi organiza contexto y propone siguientes pasos; no envía mensajes ni cambia etapas automáticamente. Si Copilot no está disponible, el proceso puede continuar con revisión humana, CRM y plantillas aprobadas según la configuración de la empresa. Esa alternativa no autoriza automatizaciones o accesos que el producto no ofrece.
Las propuestas utilizan productos y precios del catálogo. Si falta un importe, se confirma y no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. La actividad de Buyer Room no confirma identidad, aceptación, contrato, pago o intención. Forecast usa reglas transparentes y no garantiza cierres.
Cerravi aporta capacidades, exportaciones y evidencia dentro de su alcance, pero no publica en esta guía un SLA, RTO o RPO contractual. Cada organización valida su arquitectura, proveedores, respaldo, obligaciones y recursos. El plan no sustituye asesoría de continuidad, seguridad, privacidad, legal o gestión de riesgos.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué debe proteger un plan de continuidad de un AI Sales Copilot?
Los resultados comerciales esenciales, los datos autorizados, la capacidad de decisión y los controles necesarios. El objetivo no es conservar toda función de IA, sino mantener o restaurar un nivel seguro y útil del proceso.
¿Cuál es la diferencia entre RTO y RPO?
RTO orienta cuándo debe recuperarse un nivel definido del servicio o proceso. RPO indica cuánto atraso o pérdida de datos puede tolerarse desde un punto recuperable. Ambos requieren alcance, evidencia y dueño; no son garantías por sí solos.
¿El modo manual siempre es suficiente como respaldo?
No. Debe tener fuentes, controles, capacidad, responsables, almacenamiento temporal y conciliación probados. Si el volumen o el riesgo exceden lo sostenible, el plan necesita limitar la demanda, priorizar o suspender parte del proceso.
¿Con qué frecuencia debe probarse el plan?
No existe una frecuencia universal. La organización la define por impacto, cambio, dependencia y vigencia de evidencia, y repite antes cuando cambia el sistema o un incidente, hallazgo o prueba revela una brecha material.
¿Este plan garantiza que Cerravi estará disponible?
No. La guía ayuda a diseñar objetivos y alternativas internas, pero no publica un SLA ni garantiza recuperación. Los compromisos contractuales deben consultarse en los términos aplicables y con las funciones responsables.