Aprende Cerravi con recorridos breves y claros.

En este video veremos cómo leer la vista de Hoy en Cerravi. Esta es una demostración pública con datos ilustrativos. Ninguna acción modifica negocios reales. La primera sección resume el foco comercial. En este ejemplo, Cerravi identifica tres decisiones que pueden mover la semana usando la salud de la oportunidad, la recencia y las señales registradas. Después aparecen tres indicadores. Pipeline activo muestra el valor de los negocios en curso. Decisiones esta semana señala la carga inmediata. Ritmo del equipo indica qué proporción de oportunidades cuenta con un próximo paso. Más abajo puedes reconocer rápidamente la cuenta, el nombre del negocio, su etapa, monto y estado de salud. Al final, Ritmo comercial convierte el contexto en una agenda visible. Cada tarjeta muestra cuándo actuar, qué hacer, sobre qué oportunidad y con qué nivel de atención. La lectura recomendada es sencilla: primero el foco, después los indicadores, luego las oportunidades y finalmente los próximos pasos. Así empiezas el día con una prioridad clara. Explora la demo en cerravi.com.

Veamos cómo filtrar y comparar oportunidades en el pipeline de Cerravi. La demo utiliza cinco negocios ficticios y montos ilustrativos en pesos mexicanos. La vista Todos reúne las oportunidades disponibles y muestra cuenta, negocio, etapa, monto y salud comercial. Selecciona Propuesta para concentrarte en los negocios que ya llegaron a esa etapa. Aquí aparecen Nexo Ingeniería y Marea Studio. Al elegir una oportunidad, el panel derecho actualiza su contexto. Puedes comparar la señal observada, la etapa y el siguiente paso sugerido. Ahora filtramos por Evaluación. El resultado es Grupo Alera, marcado como En riesgo y con un monto ilustrativo de setecientos cuarenta mil pesos. Con Negociación aislamos Casa Verde, que necesita atención mientras el equipo alinea las condiciones finales. Regresa a Todos para recuperar la vista completa. Los estados En ruta, Atención y En riesgo ayudan a decidir dónde revisar primero. Los filtros cambian la lista visible; no modifican ninguna oportunidad dentro de la demo. Explora el pipeline interactivo en cerravi.com/demo.

Cerravi Copilot te ayuda a interpretar una oportunidad sin ocultar el contexto. Empezamos con Nexo Ingeniería, una oportunidad ficticia que se encuentra en la etapa de Propuesta. La etiqueta Vista explicable indica que la recomendación se acompaña de las razones visibles en pantalla. En la demo, todo se basa en actividad ilustrativa registrada. En Por qué ahora aparecen dos piezas de contexto: la sala fue revisada hace dos horas y el negocio está en Propuesta. La recomendación no aparece aislada de la evidencia. El siguiente mejor paso es confirmar el alcance con Ana. Es una acción concreta que el vendedor puede revisar antes de continuar. Comparemos otro caso. Grupo Alera está En riesgo porque no tiene un siguiente paso registrado desde hace nueve días. Por eso el mensaje cambia: conviene recuperar el ritmo antes de que la oportunidad se enfríe. La propuesta es definir una fecha de decisión. Cerravi presenta la recomendación para revisión. Nada se envía automáticamente y esta demo no modifica ningún negocio. Contexto visible, una razón clara y un siguiente paso concreto. Explora la demo en cerravi.com.

Vamos a revisar un caso completamente ficticio: la oportunidad de Grupo Alera. Todos los nombres, montos y actividades de esta demostración son ilustrativos. Primero filtramos el pipeline por la etapa Evaluación. La lista muestra la oportunidad Migración cloud. El negocio tiene un monto ilustrativo de setecientos cuarenta mil pesos y aparece con el estado En riesgo. Cerravi resume la situación con una indicación directa: hay que recuperar el ritmo antes de que la oportunidad se enfríe. La razón visible es específica. No existe un siguiente paso registrado desde hace nueve días. Además, la oportunidad continúa en Evaluación. Con ese contexto, el siguiente mejor paso propuesto es definir una fecha de decisión. La recomendación no sustituye el criterio del vendedor; organiza la información para facilitar la revisión. En Ritmo comercial, la misma acción aparece programada para el martes a las once, vinculada con la cuenta y la oportunidad correspondientes. El flujo queda conectado: una señal registrada, un estado de salud y una acción siguiente. Así Cerravi ayuda a convertir contexto comercial en una decisión clara.

El Forecast de Cerravi sirve para ordenar una conversación comercial, no para prometer ingresos. Revisa únicamente las oportunidades activas y conserva cada moneda por separado. La banda alta, media o baja utiliza reglas transparentes del CRM, como la etapa, la actividad reciente, el siguiente paso y las fechas registradas. Es una estimación operativa: no es un modelo predictivo entrenado, no está calibrado como machine learning y no garantiza un cierre.

Las métricas del pipeline son útiles cuando conducen a una decisión. Revisa oportunidades activas, distribución por etapa, cobertura de siguiente paso, Deal Health, tareas vencidas y tiempo sin movimiento. Mantén cada moneda separada y evita confundir actividad con avance: una oportunidad progresa cuando existe evidencia de una decisión del comprador. Abre los negocios que explican cada métrica y termina con una acción concreta.

Un plan de cuenta coordina el trabajo alrededor de una empresa importante. Reúne contexto confirmado, objetivos, participantes, oportunidades, riesgos y próximos movimientos. Cada oportunidad conserva su etapa, monto, moneda, siguiente paso y responsable; el potencial de la cuenta no se convierte automáticamente en pipeline. Para cada riesgo, define una acción observable con responsable y fecha.

Antes de compartir una cotización B2B, revisa cuatro elementos: catálogo, precio, moneda y versión. El objetivo es sencillo: que el comprador reciba exactamente la oferta que tu equipo autorizó. Empieza por una fuente aprobada. Cada partida necesita producto, unidad, precio, moneda y vigencia. Si no puedes identificar el origen del importe, la lista todavía no está lista para cotizar. Distingue tres estados. Precio pendiente detiene el documento. Sin cargo representa una decisión aprobada. No aplica indica que el campo no corresponde. Nunca conviertas un vacío en una cifra. Mantén la moneda visible en la lista, cada partida y el total. Si existen conceptos en pesos y dólares, muéstralos por separado. Una conversión requiere tasa, fecha y criterio aprobados. Cada revisión necesita un estado: borrador, en revisión, compartida o sustituida. Registra qué cambió, quién recibió la versión y hasta cuándo sigue vigente. Después retira el acceso anterior. En Cerravi, un precio faltante requiere revisión humana. La propuesta sigue vinculada con la oportunidad y el siguiente paso. Revisa la guía y practica el flujo en la demo de cerravi punto com.

El seguimiento de una cotización empieza antes de enviarla. Confirma quién la revisará, qué decisión debe facilitar y cuándo volverán a conversar. Así el próximo contacto ya tiene un propósito. Al compartirla, registra versión, moneda, vigencia, destinatarios y canal. Añade el siguiente paso con responsable y fecha. El historial debe mostrar exactamente lo que recibió el comprador. No existe un plazo universal para insistir. Usa primero la fecha acordada. Si no existe, considera urgencia, complejidad y participantes. Vuelve a escribir cuando puedas aportar algo útil. El primer mensaje debe ser fácil de responder. Recuerda el objetivo, señala una decisión pendiente y formula una sola pregunta. Después propone una conversación o corrección concreta. Si no hay respuesta, revisa el contexto antes de insistir. Ofrece tres salidas: continuar, ajustar o pausar. Si no existe nueva evidencia, cierra el seguimiento con respeto y conserva el historial. Una apertura en la Buyer Room aporta contexto, pero no confirma interés ni una decisión. Cerravi organiza la señal y el siguiente paso para revisión humana. Practica el flujo en cerravi punto com.

Antes de crear una Buyer Room, define qué decisión debe facilitar, quién revisará la información y qué ocurrirá después. La sala no es una carpeta: es una experiencia preparada para una oportunidad. Incluye la propuesta vigente, la moneda, las condiciones confirmadas y únicamente las alternativas que siguen dentro de la conversación. No expongas notas internas ni conviertas un borrador incompleto en una oferta. Trata el enlace como una credencial. Confirma que la sala esté activa, define una vigencia coherente y compártela solo con los participantes previstos. Si existe un error o una versión nueva, revoca el acceso anterior. Abre la sala en una ventana separada y también desde un teléfono. Comprueba nombres, importes, moneda, orden del contenido y siguiente paso. La vista pública debe entenderse sin las notas que conserva el vendedor. Una apertura indica que el enlace fue utilizado, pero no confirma interés, aceptación, contrato, pago o cierre. Relaciona la señal con la etapa y el acuerdo anterior. Después prepara una pregunta útil para el comprador. Registra destinatarios, versión, fecha y canal dentro de la oportunidad. Añade el siguiente contacto con responsable. Cuando cambie la propuesta, conserva el historial y deja disponible únicamente la sala que sigue vigente.

Una apertura de Buyer Room indica actividad sobre el enlace. No confirma quién lo abrió, qué leyó ni qué decidió. Antes de actuar, separa la señal técnica de la evidencia comercial. Primero valida el registro. Comprueba que corresponde a la oportunidad correcta, a la versión vigente y al periodo que estás revisando. Si el sistema no confirma una identidad o una acción específica, no la inventes. Después abre el contexto. Revisa la etapa, la conversación anterior, las personas que participan, la decisión pendiente y la fecha acordada. Una señal reciente no obliga a adelantar un contacto que ya tiene un momento confirmado. Ordena la evidencia. Una apertura muestra actividad. Una pregunta revela una duda concreta. Un compromiso con responsable y fecha demuestra un siguiente paso verificable. Ninguno de estos datos garantiza el resultado de la venta. Prepara un mensaje neutral. No necesitas decir que observaste la navegación. Recupera el objetivo compartido y pregunta qué falta para continuar. Por ejemplo: ¿necesitan algún dato para comparar las alternativas antes de la reunión del jueves? Finalmente registra una acción observable. Incluye responsable, fecha y resultado esperado. Si cambia la propuesta, sustituye la versión anterior. Si no hay respuesta, conserva el intento y decide si conviene esperar, cambiar de canal, validar otro participante o pausar. Cerravi organiza la actividad junto con el contexto de la oportunidad. La persona responsable revisa la señal y decide el siguiente paso.

Una venta B2B rara vez depende de una sola persona. Para entender la decisión, no empieces por el organigrama. Empieza por la pregunta que la cuenta necesita resolver. Después identifica las funciones que participan. Puede existir alguien que impulsa el proyecto, una persona usuaria, una validación técnica o de seguridad, quien confirma presupuesto, compras y la autoridad final. No todas las oportunidades necesitan la misma lista y una persona puede cumplir varias funciones. El cargo no demuestra la función. Una directora puede usar la solución sin aprobar el contrato. Un especialista puede definir requisitos sin firmar. Registra por separado la influencia y la autoridad, y anota qué evidencia sostiene cada interpretación. Cuando falta información, deja el espacio como desconocido. No inventes un nombre, una relación ni una aprobación para completar el mapa. Una nota de reunión, una pregunta expresa o una presentación confirmada ofrecen evidencia. Un perfil público solo puede ayudarte a preparar una pregunta. Después revisa los vacíos. ¿Quién valida la adopción? ¿Quién revisa seguridad? ¿Quién confirma condiciones y cómo se formaliza la compra? Si todo depende de un solo contacto, ayúdalo a coordinar a las personas necesarias. El objetivo no es rodearlo, sino facilitar la decisión. Termina con un siguiente paso para cada función relevante. Validar el flujo con usuarios. Revisar requisitos con tecnología. Confirmar alcance con finanzas. Alinear documentos con compras. Cada acción necesita responsable, fecha y resultado esperado. Cerravi organiza participantes, evidencia y acciones dentro de la oportunidad. La persona responsable confirma la información y decide cómo continuar.

Un proceso de decisión B2B no es una lista de tareas del vendedor. Es la ruta que la cuenta necesita completar para evaluar, autorizar o rechazar el siguiente movimiento. Empieza por definir la decisión. Aprobar una prueba, validar una integración, seleccionar una alternativa o emitir una orden son resultados distintos. Cada uno necesita criterios y participantes diferentes. Después construye pocos hitos observables. Confirmar el problema. Validar el uso. Resolver requisitos técnicos. Revisar alcance y condiciones. Alinear el proceso de compra. Registrar la decisión final. Un hito queda completo por su resultado, no porque hubo una reunión. Separa siempre actividad comercial de evidencia del comprador. Preparar una demostración es una acción del equipo. Que la persona responsable confirme un requisito es evidencia. Enviar una propuesta tampoco demuestra que la cuenta la revisó o aceptó. Cada hito necesita una función responsable, un criterio y una prueba visible. Si falta el nombre, la fecha o la autoridad, conserva el dato como pendiente. No inventes una aprobación para que la ruta parezca completa. Ordena dependencias y distingue fechas. Una tarea interna puede tener su propio plazo. Una fecha del comprador solo es un compromiso cuando la cuenta la confirmó. Registra quién la confirmó y para qué decisión. El plan puede compartirse en una Buyer Room o una minuta cuando ambas partes reconocen la ruta. Si solo lo preparó tu equipo, llámalo borrador o plan interno. Por último, actualiza cambios sin borrar la historia. Registra qué cambió, qué evidencia apareció y cuál es el siguiente paso con responsable, fecha y resultado esperado. Cerravi conecta la ruta, los participantes, la actividad y las acciones dentro de la oportunidad. El equipo revisa la evidencia y decide si avanzar, esperar, pausar o cerrar.

Una reunión de descubrimiento B2B no es un interrogatorio ni una demostración anticipada. Sirve para comprender la situación, confirmar un problema y decidir si existe un siguiente paso útil. Antes de la reunión, revisa lo que ya conoces y escribe una hipótesis. La hipótesis orienta preguntas, pero no debe registrarse como evidencia. Abre con contexto y una agenda breve. Explica que quieres entender el proceso actual, el resultado esperado y cómo evaluarían una alternativa. Pregunta qué desea añadir la otra persona. Empieza por la situación. ¿Qué ocurre hoy, dónde aparece la fricción y qué han intentado? Profundiza con ejemplos. Una pregunta conectada con la respuesta produce más contexto que completar una lista. Después explora el impacto sin fabricar urgencia. Pregunta qué tarea, decisión o resultado cambia y por qué lo revisan ahora. Si no existe una cifra o una fecha confirmada, conserva el dato como pendiente. Define el resultado esperado y los criterios para reconocer una alternativa adecuada. Después identifica funciones: quién vive el problema, quién revisa requisitos, quién confirma prioridad y cómo se autoriza la compra. Un cargo no demuestra autoridad. Durante la conversación, separa hechos, hipótesis y pendientes. Resume lo escuchado y permite que la cuenta corrija tu interpretación. Si grabas o transcribes, comprueba antes la base jurídica, las políticas, la información necesaria y la retención. Sin autorización suficiente, utiliza notas manuales. Cierra con un resumen compartido. Confirma problema, impacto, criterios, participantes y preguntas abiertas. Después acuerda una acción con responsable, fecha y resultado esperado. Puede ser una demostración enfocada, una revisión técnica, otra conversación o no continuar. Cerravi organiza el contexto y el siguiente paso para revisión humana. La reunión, por sí sola, no cambia la etapa ni garantiza el cierre.

Una demostración de ventas B2B no es una visita por todas las funciones. Es una prueba guiada para ayudar a la cuenta a evaluar un resultado concreto. Empieza con la evidencia de discovery. Revisa el problema, el proceso actual, el resultado esperado, los criterios, los participantes y las preguntas pendientes. Separa lo confirmado de las hipótesis. Después define la decisión que la sesión debe facilitar. Puede ser validar un flujo, decidir si hace falta una revisión técnica o acordar qué información necesita la cuenta para continuar. Construye una historia breve. Recupera la situación actual, muestra el punto de fricción, ejecuta el flujo relevante y presenta el resultado observable. Relaciona cada escena con un criterio y prepara una pregunta para confirmar si responde a la necesidad. Utiliza un entorno de demostración con datos ficticios. Comprueba accesos, permisos, conexión, resolución y notificaciones. Ensaya el recorrido y prepara capturas o un video como respaldo. Si algo falla, explica qué ocurrió; no ocultes el cambio de material. Al iniciar, confirma que el contexto no cambió y comparte la agenda. Durante la demo, trabaja en ciclos cortos: contexto, acción, resultado y pregunta. Escucha correcciones y objeciones. Una reacción positiva o una pregunta detallada no demuestra aceptación ni intención de compra. Si no conoces una respuesta, registra el requisito, la persona responsable y la fecha de seguimiento. No inventes integraciones, capacidades, resultados ni plazos. Muestra precios únicamente cuando estén aprobados, con moneda, vigencia y condiciones visibles. No completes datos faltantes ni mezcles monedas. Cierra recuperando los criterios demostrados, los límites y los pendientes. Después acuerda una acción con responsable, fecha y resultado esperado. Puede ser una revisión técnica, una prueba acotada, una propuesta o detener la evaluación. Cerravi organiza la evidencia y el siguiente paso para revisión humana. Haber realizado la demo no cambia por sí solo la etapa ni garantiza el cierre.

Una prueba de concepto B2B no es una demo más larga ni una implementación gratuita. Sirve para validar pocas incertidumbres que todavía impiden tomar una decisión. Empieza por la pregunta. ¿Qué necesita saber la cuenta y qué supuesto todavía no tiene evidencia? La respuesta debe admitir un sí, un no o un resultado parcial. Antes de configurar, acuerda criterios de entrada y salida. Para entrar necesitas caso de uso, responsables, acceso, datos y entorno. Para salir necesitas un resultado observable y un umbral. Incluye también condiciones de pausa o no go. Limita el alcance. Selecciona pocos escenarios representativos y escribe las exclusiones: migración completa, operación productiva, soporte general, personalizaciones futuras o rendimiento fuera del volumen probado. Una solicitud nueva se registra como cambio; no entra por inercia. Elige los datos según el criterio. Usa datos sintéticos o de muestra cuando sean suficientes. Los datos reales requieren autorización, minimización, acceso, retención y eliminación definidos. Trabaja en un sandbox separado y recuerda: una muestra pequeña no demuestra rendimiento o calidad a escala. Convierte cada objetivo en una prueba. Define precondición, datos, pasos, resultado esperado, evidencia y responsable. Incluye excepciones importantes, pero no intentes cubrir toda una solución productiva. Si buscas una mejora, registra primero la línea base y utiliza el mismo método al final. Durante la ejecución, conserva resultados, incidentes, configuraciones, ayuda manual y cambios. No optimices únicamente para pasar el criterio. Si el resultado depende de una intervención especial, esa dependencia forma parte de la conclusión. Al cerrar, revisa cada criterio como cumplido, no cumplido, parcial o no evaluado. Conserva límites y preguntas abiertas. Después decide: avanzar, ajustar, preparar un pilot, posponer o detener. La PoC demuestra solamente lo probado bajo las condiciones acordadas. No garantiza adopción, costo, seguridad, rendimiento ni operación en producción. Cerravi organiza criterios, evidencia y siguientes pasos para revisión humana. Iniciar o completar la PoC no confirma por sí solo presupuesto, contrato ni cierre.

Un piloto de AI Sales Copilot no es una demo masiva ni un despliegue general. Es un periodo limitado para observar cómo una solución madura funciona con usuarios y procesos reales antes de escalar. Empieza por la decisión. ¿Qué necesitarías comprobar para ampliar, ajustar, extender o detener? Convierte esa decisión en pocos resultados esperados y define una línea base. Uso y resultado no son lo mismo. Una persona puede entrar sin completar el escenario. Un proceso puede mejorar por capacitación u otro cambio. Mide ambos y conserva la explicación. Selecciona una cohorte pequeña, pero representativa. Incluye funciones, experiencia, territorios o tipos de cuenta que puedan cambiar el resultado. No invites únicamente a entusiastas. Los champions ayudan, pero no sustituyen la experiencia del grupo. Define inicio y fin. Limita equipos, escenarios, datos, funciones e integraciones. Escribe también las exclusiones y la regla para extender o cambiar el piloto. Antes de habilitar usuarios, prueba acceso, permisos, datos, configuración y soporte. Un bloqueo técnico puede parecer falta de adopción. Confirma la fuente oficial de cuentas, oportunidades, precios y actividades. La IA no debe completar datos ausentes con supuestos. Comunica por qué existe el piloto, qué se espera y dónde pedir ayuda. Enseña tareas completas, no un recorrido por el menú. Cada participante necesita escenarios observables. Por ejemplo, preparar una reunión, revisar una oportunidad, registrar el siguiente paso o crear una propuesta solo con precios aprobados. Para cada escenario define inicio, acciones, resultado esperado, evidencia y frecuencia. Mide cinco capas por separado. Acceso: quién pudo comenzar. Uso: quién estuvo activo y con qué frecuencia. Calidad: qué resultados se aceptaron, corrigieron o descartaron. Experiencia: utilidad, esfuerzo y confianza. Operación: tiempo, retrabajo, cobertura o actualización frente a la línea base. Añade incidencias y soporte. Indica numerador, denominador, fuente y periodo. El número de sesiones o prompts no demuestra por sí solo adopción, ahorro o impacto comercial. Revisa cada semana feedback, actividad, calidad, tickets y cambios. Separa problemas técnicos, capacitación, proceso y limitaciones del producto. No presiones a las personas para mejorar una cifra sin entender la causa. Al cerrar, marca cada criterio como cumplido, parcial, no cumplido o no evaluado. Conserva diferencias entre grupos y condiciones del piloto. Después decide: escalar, ampliar la cohorte, ajustar y repetir, mantener un uso limitado, posponer o detener. Un piloto acompañado no garantiza el mismo resultado en producción. Cerravi organiza contexto, métricas y siguientes pasos para revisión humana. Iniciar o terminar el piloto no confirma presupuesto, contrato, adopción general ni cierre de la venta.

Escalar un AI Sales Copilot a producción no significa habilitar a todo el equipo después de un piloto favorable. El piloto ocurrió con una cohorte, un alcance y un nivel de acompañamiento concretos. Producción añade más usuarios, volumen, variación de datos, excepciones y dependencia operativa. Primero convierte el cierre del piloto en una puerta de decisión. Revisa criterios cumplidos, parciales, no cumplidos y no evaluados. Conserva incidencias, asistencia manual, diferencias entre grupos y cambios de configuración. Después autoriza una ola específica, con límites y condiciones. Haber terminado el piloto no obliga a escalar. Diseña el rollout por olas. Agrupa personas por función, proceso, región o tipo de cuenta, según la siguiente variación que necesitas observar. Cada ola debe tener objetivo, población, escenarios, datos, capacitación, soporte, fecha de inicio y periodo de estabilización. Deja una ventana entre olas para revisar señales y corregir antes de ampliar. La fecha expresa intención; la puerta de preparación decide si el grupo puede comenzar. Si falta una dependencia crítica, registra el impacto y reprograma. No conviertas el calendario en una autorización automática. Define un modelo operativo con responsables visibles. Negocio es dueño del proceso y del resultado esperado. Tecnología mantiene configuración y dependencias. Datos conserva fuentes y calidad. Seguridad y privacidad revisan acceso y límites. Adopción prepara comunicación y aprendizaje. Soporte clasifica, resuelve y escala. Cada decisión necesita una persona con autoridad. Antes de cada ola, comprueba usuarios, permisos, datos, escenarios críticos, materiales y capacidad de soporte. Ensaya también la pausa y la recuperación. Una puerta útil responde: lista, lista con condiciones o no lista. Conserva revisión humana y límites de acción. Define qué puede recomendar el copiloto, qué puede preparar y qué requiere confirmación. Las acciones que afectan personas, dinero, compromisos comerciales o cumplimiento necesitan contexto y aprobación. En Cerravi, las sugerencias se revisan; los precios provienen del catálogo disponible, los importes faltantes requieren confirmación y las monedas permanecen separadas. El sistema no debe interpretar actividad como aceptación, cambiar etapas ni enviar mensajes por su cuenta. Registra también cada cambio de modelo, prompt, fuente, permiso o integración con versión, prueba, aprobación y comunicación. Monitorea cinco planos por separado. Operación: disponibilidad, errores y latencia. Adopción: acceso, frecuencia y escenarios completados. Calidad: resultados aceptados, corregidos y descartados. Riesgo: permisos, datos incompletos, excepciones y escalaciones. Resultado: efecto operativo frente a una línea base. Añade feedback, tickets, incidentes y capacidad de soporte. Publica definición, numerador, denominador, fuente y periodo. Un incremento de uso no demuestra por sí solo valor, ahorro o impacto comercial. Tampoco atribuyas automáticamente un cambio a la IA: capacitación, estacionalidad o composición de la ola pueden explicar parte del resultado. Prepara criterios para pausar, revertir o retirar. Puede ser acceso indebido, exposición de datos, una salida comercial de alto impacto sin control, degradación repetida o incidencias que superan la capacidad de respuesta. Define quién declara el incidente, qué alternativa manual mantiene el proceso, cómo se conserva evidencia y quién autoriza la reanudación. Al cerrar cada ola, decide continuar, mantener, corregir, repetir, limitar, revertir o retirar. Actualiza materiales, controles y soporte antes de ampliar. Cerravi organiza contexto, responsables y siguientes pasos para revisión humana. Un rollout bien operado reduce incertidumbre; no garantiza adopción, ahorro, ingresos ni el cierre de una oportunidad.

Monitorear un AI Sales Copilot no consiste en llenar un tablero. Consiste en saber si el sistema sigue funcionando, si sus resultados son útiles, si respeta sus límites y si el proceso comercial conserva control humano. Empieza por las decisiones. ¿Qué señal llevaría a investigar, corregir datos, capacitar, limitar una función, abrir un incidente o iniciar un cambio? Cada indicador necesita definición, fuente, población, periodo, responsable y una acción posible. Si nadie sabe qué hacer con una cifra, probablemente solo añade ruido. Conserva una línea base del proceso y vincula cada evento con la versión activa, sus instrucciones, fuentes, herramientas, permisos e integraciones. Separa cinco capas. Operación responde si el servicio y sus dependencias funcionan. Calidad responde si el resultado sirve para el escenario. Riesgo comprueba acceso, datos y límites. Adopción observa si la persona completa el trabajo esperado. Resultado estudia si cambió el tiempo, el retrabajo, la cobertura o la actualización frente a una referencia comparable. No mezcles todo en una puntuación. Un copiloto puede estar disponible y ser poco útil; también puede generar una buena sugerencia que nadie aprovecha por un permiso o una capacitación pendiente. En operación, revisa disponibilidad, latencia, errores, colas, reintentos y llamadas a herramientas. Incluye las fuentes que sostienen la respuesta: CRM, catálogo, autenticación e integraciones. Una respuesta rápida puede ser incorrecta si el dato está desactualizado. Las trazas ayudan a reconstruir llamadas y fallos, pero pueden contener entradas, salidas y contexto comercial. Minimiza lo registrado, evita secretos, restringe quién consulta la telemetría y aplica la retención definida por la organización. Para calidad, define criterios por escenario antes de revisar la salida. Comprueba fidelidad al contexto, uso de la fuente autorizada, integridad de campos, utilidad del siguiente paso y claridad sobre información faltante. Combina una muestra protegida de producción con un conjunto estable de pruebas. Incluye datos incompletos, ambigüedad, permisos insuficientes y solicitudes fuera del alcance. Los evaluadores automáticos amplían cobertura, pero no sustituyen a las personas que conocen ventas, datos, seguridad y operación. Conserva ejemplos aceptados, corregidos y descartados. Los promedios no deben ocultar un caso grave. Mantén señales específicas para acceso indebido, exposición de datos, una herramienta fuera del alcance, una fuente no autorizada o un compromiso comercial incorrecto. Distingue frecuencia y severidad. Ofrece además una ruta clara para reportar, corregir y pedir revisión. Clasifica el feedback por datos, configuración, calidad, permisos, capacitación o proceso. Un aumento de reportes puede significar que el canal funciona mejor, no que el sistema empeoró. Diseña alertas con condición, ventana, versión, evidencia, responsable y respaldo. Diferencia aviso, degradación e incidente. Prueba que la alerta llegue y que el equipo pueda limitar la función o pasar al proceso manual. Después opera una cadencia: señales técnicas y críticas de forma continua; calidad, adopción y resultado en revisiones periódicas. Cada sesión debe terminar con una decisión: mantener, investigar, corregir, capacitar, cambiar, limitar, pausar, revertir o retirar. Revisa también el propio monitoreo. En Cerravi, las sugerencias requieren revisión humana, los precios proceden del catálogo disponible, los importes faltantes exigen confirmación y las monedas permanecen separadas. Forecast es una estimación basada en reglas transparentes y datos del CRM, no un modelo predictivo entrenado o calibrado. El copiloto organiza contexto; no garantiza ingresos ni cierres.

La supervisión humana de un AI Sales Copilot no consiste en agregar un botón de aprobar. Existe control real cuando una persona comprende qué propone el sistema, qué información utilizó, qué falta y qué efecto tendrá la confirmación. También necesita tiempo, competencia y autoridad para corregir, rechazar, escalar o detener. Empieza con un inventario. Enumera lo que el copiloto puede observar, resumir, recomendar, preparar, guardar, compartir o ejecutar. Separa una recomendación interna, un borrador y una acción con efecto externo. Para cada paso identifica las personas o procesos afectados, los datos utilizados, la reversibilidad y la severidad de un error. Asigna el nivel de intervención según impacto y reversibilidad. Un resumen interno con fuentes visibles puede admitir revisión posterior. Un mensaje al cliente, un precio, un descuento, un cambio sobre datos o un compromiso comercial necesita aprobación previa. Una acción relacionada con personas, dinero, acceso o cumplimiento merece un control más estricto. Considera también la propagación. Una salida que alimenta cientos de registros o activa otras herramientas puede ser de alto impacto aunque cada elemento parezca pequeño. Cuando el alcance sea incierto, empieza con el permiso mínimo. Define responsables con autoridad. Negocio confirma el propósito y las condiciones comerciales. Operación coordina el proceso. Datos conserva fuentes y calidad. Tecnología mantiene configuración e integraciones. Seguridad, privacidad y legal revisan los controles aplicables. Soporte recibe y escala señales. Para cada decisión establece quién propone, quién revisa, quién aprueba, quién puede pausar y quién autoriza la reanudación. Asigna también un respaldo y una ruta fuera de horario. Una lista de participantes no sustituye a una persona responsable. Construye una matriz fácil de aplicar. Escribe qué puede hacer el sistema, qué necesita revisión y qué está prohibido. Hazlo por escenario y efecto, con ejemplos. En ventas, el copiloto puede organizar contexto o preparar un borrador con los datos disponibles. La persona autorizada debe confirmar destinatario, alcance, precio, moneda, vigencia y condiciones antes de compartir una propuesta. Si falta un importe o existe conflicto entre fuentes, el flujo se detiene, pide información o escala. La interfaz debe mostrar la recomendación, el fundamento, las fuentes, los datos ausentes y el efecto de confirmar. El revisor necesita opciones reales para corregir, rechazar y escalar. Gestiona excepciones y registra decisiones sin vigilar de más. Una excepción temporal necesita razón, alcance, responsable, control compensatorio y fecha de vencimiento. Conserva la evidencia necesaria para reconstruir la decisión: escenario, versión, fuentes, salida propuesta, cambio humano, aprobación y efecto. No copies por defecto conversaciones completas, secretos o datos personales innecesarios. Revisa correcciones, descartes, excepciones, tiempos y acumulación de colas. Una tasa alta de aprobación no demuestra calidad; también puede señalar fatiga, presión o poco contexto. Prepara la parada antes de necesitarla. Define quién puede limitar una función, qué alcance controla y qué proceso manual mantiene el trabajo esencial. Ensaya cómo rechazar, corregir, escalar, pausar y recuperar. El acceso indebido, la exposición de datos, una acción fuera del alcance o un compromiso comercial sin aprobación deben activar contención. Reanudar requiere una decisión separada, pruebas del control correctivo, permisos revisados y monitoreo reforzado. En Cerravi, las sugerencias requieren revisión humana. El producto no envía mensajes ni cambia etapas automáticamente. Los precios proceden del catálogo disponible; un importe faltante exige confirmación y las monedas permanecen separadas. Forecast aplica reglas transparentes del CRM: no es un modelo predictivo entrenado o calibrado y no garantiza cierres ni ingresos.

Una política de uso para un AI Sales Copilot debe ayudar a decidir, no limitarse a pedir responsabilidad. Empieza por el propósito: qué problema comercial resuelve, quién puede utilizarlo y qué sistemas, datos, entornos e integraciones están incluidos. Registra también la versión y el dueño. Distingue política, procedimiento y control. La política fija la regla y la autoridad. El procedimiento explica cómo cumplirla. El control técnico limita, registra o bloquea la acción. Los tres deben coincidir. Si el documento prohíbe compartir cierta información, pero los permisos siguen abiertos, la política todavía no está implementada. Construye una matriz con cuatro rutas. Permitido: una tarea dentro del alcance y con fuentes autorizadas, como resumir actividad del CRM. Condicionado: un borrador que necesita revisión antes de afectar a un cliente. Prohibido: inventar precios, compromisos, identidades o hechos. Escalar: falta información, existe conflicto entre fuentes o la persona no tiene autoridad. Añade ejemplos del trabajo real. ¿Puede resumir una llamada, redactar un correo, cargar una lista, cambiar una etapa o compartir una propuesta? Para cada caso indica datos, revisión, registro y responsable. No conviertas el silencio de la política en permiso. Decide qué información puede entrar en el sistema. Separa datos públicos, internos, confidenciales, personales, sensibles, credenciales y material de terceros. Define fuentes oficiales, campos excluidos, acceso, retención, exportación y eliminación. Una carpeta disponible o una versión antigua no se vuelve autorizada por existir. Utiliza solo el contenido necesario para la tarea. Separa asistencia, borrador y acción. Observar, resumir y recomendar no equivalen a guardar, enviar, modificar, publicar o conceder acceso. Reserva aprobación para efectos difíciles de revertir o relacionados con personas, dinero, acceso y cumplimiento. La persona debe ver la solicitud, las fuentes, lo que falta, el destinatario y el efecto antes de confirmar. Cuando una acción esté prohibida, usa permisos y bloqueos; una instrucción escrita no sustituye un límite técnico. Asigna derechos de decisión. Nombra al dueño de negocio, al responsable operativo, a datos, tecnología, seguridad, privacidad, legal, soporte, usuarios y revisores. Especifica quién aprueba una excepción, quién puede pausar y quién autoriza la reanudación. Incluye respaldo y ruta fuera de horario. Aplica mínimo privilegio al usuario, al copiloto y a cada herramienta. Separa lectura y escritura, prueba y producción, administración y trabajo diario. Deniega nuevas fuentes e integraciones hasta que tengan finalidad, dueño y revisión. Prueba también la revocación de cuentas, tokens y accesos heredados. Define transparencia y evidencia sin registrar de más. Indica cuándo identificar contenido generado, editado y aprobado. Conserva versión, fuente, acción, cambio humano, aprobación, efecto y excepción de forma proporcional. Limita acceso y retención. La observabilidad no debe convertirse en vigilancia sin propósito. Las excepciones necesitan razón, alcance, responsable, control compensatorio y vencimiento. La ruta de incidentes debe aceptar dudas, exposición de datos, acceso indebido y acciones fuera del alcance. El equipo necesita poder detenerse y reportar sin presión para aprobar. Capacita con casos permitidos, condicionados, prohibidos y ambiguos. Comprueba que cada persona pueda localizar una fuente, conservar la duda, corregir y escalar. Revisa la política con una cadencia y cuando cambien funciones, modelos, proveedores, datos, integraciones, autonomía, usuarios o requisitos aplicables. En Cerravi, el copiloto propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Los precios proceden del catálogo y un importe faltante exige confirmación. Las monedas permanecen separadas. La actividad de una Buyer Room no confirma identidad, aceptación o pago. Forecast utiliza reglas transparentes del CRM; no es un modelo predictivo entrenado o calibrado y no garantiza cierres ni ingresos. La organización debe adaptar y aprobar su propia política con las funciones que correspondan.

Un incidente de AI Sales Copilot no es cualquier respuesta imperfecta. Una sugerencia poco útil que la persona detecta, corrige y descarta puede registrarse como feedback. El proceso de incidentes comienza cuando existe o puede existir un impacto relevante: acceso indebido, exposición de datos, una acción fuera del alcance, un compromiso comercial incorrecto o una degradación que los controles habituales no contienen. Clasifica por efecto, alcance, reversibilidad y velocidad de propagación; no por lo novedosa que parezca la salida. Prepárate antes del primer caso. Define quién puede declarar el incidente, limitar una función, revocar acceso y autorizar la reanudación. Publica un canal de reporte y señales observables. Mantén además una alternativa manual para las tareas esenciales: revisar la oportunidad en el CRM, usar una plantilla aprobada o confirmar precios directamente en el catálogo. Un modo manual que nadie ha probado no es continuidad. Cuando llega una señal, abre un registro único. Conserva la hora, función afectada, cuenta u oportunidad, salida observada y acción posterior. Separa hechos, hipótesis y datos pendientes. Confirma si el resultado solo fue visible, si se guardó, se compartió o se ejecutó. Después contiene el alcance. Puedes limitar una función, retirar una fuente, revocar un permiso, detener una integración o exigir revisión humana. La primera meta es detener el impacto, no explicar toda la causa. Contener no significa borrar. Conserva entradas, salidas, fuentes, versión, permisos, decisiones y cronología necesarias para reconstruir el caso. Restringe el acceso y aplica las reglas de privacidad. Revisa también qué cuentas, propuestas, Buyer Rooms o mensajes pudieron recibir el resultado. No supongas que una salida fue enviada ni que una apertura confirma lectura. Busca evidencia de cada transición. Si hubo información comercial incorrecta, coordina una corrección clara con la fuente autorizada. Investiga la causa inmediata y las condiciones que permitieron el impacto. Datos incompletos, una fuente obsoleta, permisos excesivos, una instrucción ambigua y una revisión sin contexto pueden combinarse. Prueba hipótesis en un entorno controlado y usa datos sintéticos cuando sean suficientes. Comunica lo confirmado, la acción tomada y el momento de la próxima actualización. No culpes al usuario ni prometas una recuperación sin evidencia. La reanudación necesita una puerta explícita. Confirma contención, prueba el control correctivo, revisa permisos y fuentes, informa a usuarios y soporte, activa monitoreo reforzado y registra quién aprueba el alcance. Empieza por el grupo mínimo necesario. Después realiza una revisión sin buscar culpables y convierte cada aprendizaje en una acción con responsable, fecha y criterio de cierre. En Cerravi, las sugerencias requieren revisión humana, los precios provienen del catálogo y las monedas permanecen separadas. El copiloto organiza contexto; no garantiza cierres ni sustituye la responsabilidad operativa de la empresa.

Preparar los datos del CRM para un AI Sales Copilot no significa limpiar toda la base antes de empezar. Significa conocer qué decisión debe apoyar, qué información necesita y qué debe hacer cuando el contexto no alcanza. Empieza por una tarea concreta: resumir una oportunidad, sugerir un siguiente paso o preparar una propuesta. Escribe la entrada, la salida y la revisión humana. Un resumen interno puede tolerar un teléfono ausente. Una propuesta no puede completar un precio, una moneda o una vigencia que no existen en la fuente aprobada. Cada campo debe justificar una decisión o un control. Lo demás puede esperar. Después construye un inventario pequeño de fuentes. Para cada sistema registra finalidad, dueño, campos utilizados, frecuencia de actualización, acceso, retención y restricciones. Distingue el sistema de origen de una copia o una integración. Un dato visible en el CRM puede proceder de una importación antigua o de una sincronización detenida. Conserva suficiente procedencia para investigar una salida: origen, transformación relevante, versión y fecha. Disponible no significa autorizado, y reciente por nombre no significa aprobado. La persona responsable de cada fuente debe poder explicar qué significa, cómo se corrige y cuándo deja de ser válida. Define el modelo comercial mínimo. Relaciona cuenta, contactos, oportunidad, responsable, etapa, actividad, siguiente paso y productos según tu proceso. Separa hechos, interpretaciones y decisiones. Una reunión registrada es un hecho; una etiqueta de interés es una interpretación; mover la etapa es una decisión. Crea un diccionario para términos ambiguos como monto, fecha de cierre o propuesta enviada. Aclara formato, fuente y condición de actualización. Conserva también la diferencia entre faltante, desconocido y no aplicable. Un monto vacío no equivale a cero, una función ausente no convierte a la persona en decisora y una fecha vacía no demuestra que no exista calendario. Resuelve identidades y condiciones comerciales con cuidado. Busca duplicados mediante varias señales y manda los casos ambiguos a revisión. Antes de fusionar, revisa actividades, oportunidades, permisos y archivos; después conserva trazabilidad del cambio. Para productos, identifica variante, unidad, precio, moneda, vigencia y lista autorizada. Mantén MXN, USD y otras monedas como dimensiones separadas. No sumes ni compares importes sin un método aprobado, una fecha de referencia y una fuente. Prueba conflictos: dos listas vigentes, producto sin precio, moneda ausente, precio vencido o descuento fuera de autoridad. Detenerse y pedir confirmación puede ser la respuesta correcta. Aplica acceso mínimo y mide la calidad donde importa. El copiloto no debe revelar un dato que el usuario no puede consultar en el proceso normal. Revisa permisos directos, grupos, cuentas de servicio, enlaces e integraciones. Excluye información personal, confidencial o de terceros que la tarea no necesita. Crea casos de prueba completos y difíciles: datos faltantes, fuentes en conflicto, duplicados, acceso insuficiente, varias monedas y solicitudes fuera del alcance. Define antes qué salida, advertencia o abstención sería aceptable. Mide completitud, validez, consistencia, unicidad, actualidad y procedencia por campo y escenario. Un porcentaje global puede ocultar que falta justo la moneda o el siguiente paso. Finalmente, mejora los datos durante la operación. Clasifica cada reporte por captura, definición, relación, actualidad, permiso, integración o comportamiento del sistema. Una mala salida no siempre exige cambiar el modelo; muchas veces revela un campo ambiguo o una fuente obsoleta. En Cerravi, el copiloto organiza señales del CRM y propone siguientes pasos para revisión humana. Las propuestas utilizan productos y precios disponibles en el catálogo cargado. Si falta un importe, la persona debe confirmarlo; Cerravi no inventa la cifra. Las monedas permanecen separadas. La actividad de una Buyer Room aporta contexto, pero no confirma identidad, aceptación, contrato, pago ni intención de compra. Forecast es una estimación operativa basada en reglas transparentes y datos del CRM, no un modelo predictivo entrenado o calibrado. La meta no es hacer que el sistema responda siempre. Es conseguir que responda con fuentes verificables y se detenga cuando los datos no sostienen la decisión.

Evaluar un AI Sales Copilot no significa preguntar si responde bonito. Significa decidir si puede apoyar una tarea real dentro de límites conocidos. Empieza por una decisión concreta: resumir una oportunidad, proponer un siguiente paso o preparar un borrador comercial. Describe quién usará la salida, qué datos necesita, quién la revisa y qué ocurriría si está equivocada. Un texto interno y una propuesta para un comprador no tienen el mismo impacto. Registra también la versión completa: modelo, instrucciones, fuentes, reglas, herramientas y permisos. La unidad de evaluación es el recorrido que produce el resultado, no únicamente el último párrafo. Así podrás distinguir si una falla nació en los datos, la recuperación, una regla o la generación. Después construye una muestra que se parezca al trabajo real. Incluye escenarios frecuentes, bordes, fallas críticas y regresiones conocidas. Combina oportunidades nuevas y antiguas, varias personas, etapas diferentes, actividad vencida, notas ambiguas, datos faltantes y solicitudes fuera del alcance. Utiliza registros sintéticos o desidentificados cuando conserven las relaciones que necesitas probar, y documenta lo que no pueden validar. Separa los ejemplos usados para ajustar el sistema de los reservados para comprobarlo. Si el equipo mira todos los casos mientras cambia las instrucciones, puede aprender esa colección sin demostrar comportamiento ante situaciones nuevas. Cada falla relevante que se corrija debe regresar como un caso estable de regresión. Escribe cada caso para que otra persona pueda repetirlo. Registra el objetivo, el nivel de impacto, el rol de prueba, la solicitud, el contexto autorizado, las fuentes visibles y los datos que deben permanecer ocultos. Define el comportamiento aceptable antes de ejecutar. En una respuesta abierta puede haber varias redacciones correctas, así que especifica hechos obligatorios, afirmaciones prohibidas, advertencias y una acción posterior válida. Para precios, monedas, permisos o herramientas, utiliza comprobaciones deterministas. Separa relevancia, fundamento, exactitud, utilidad, incertidumbre y cumplimiento de instrucciones. Una respuesta clara no compensa un precio inventado. Una recomendación útil tampoco compensa una violación de acceso. Incluye condiciones comerciales que un promedio no debe esconder. Prueba productos sin precio, listas vencidas, dos fuentes en conflicto, descuentos fuera de autoridad y propuestas con versiones distintas. Mantén MXN, USD y otras monedas explícitas; no permitas sumas o conversiones sin método, fecha y fuente aprobados. Comprueba también las señales: una apertura de Buyer Room no confirma identidad, lectura, aceptación, contrato, pago ni intención de compra. Ejecuta el mismo escenario con roles distintos y añade registros restringidos, enlaces revocados e instrucciones dentro de archivos que intenten cambiar el objetivo o solicitar secretos. Cuando falta contexto o autoridad, una abstención clara con el siguiente paso correcto cuenta como éxito. Calibra la revisión humana antes de automatizarla. Ventas puede revisar utilidad y lenguaje; operaciones, el flujo; datos, las fuentes; seguridad y privacidad, el acceso; producto y tecnología, el comportamiento. Haz una ronda compartida y compara diferencias. Si dos especialistas interpretan una rúbrica de forma distinta, aclárala antes de ampliar la prueba. Los evaluadores automáticos pueden revisar formatos, fundamento o cumplimiento a mayor escala, pero deben compararse con calificaciones humanas. Revisa falsos aprobados y falsos rechazos, sobre todo en los casos críticos. Guarda la versión del evaluador, su instrucción y su umbral. Automatizar la repetición no transfiere la responsabilidad de definir qué es aceptable. Finalmente, compara la versión candidata con una línea base estable usando los mismos casos. Revisa resultados por escenario y criterio, no solo el promedio. Una mejora de redacción puede ocultar una nueva falla de abstención, precio o permiso. Define la puerta de salida antes de ver el resultado: cero fallas críticas, mínimos por escenario y una acción para cada excepción. La decisión debe ser aprobar, aprobar con condiciones, rechazar o pedir más evidencia, con responsable y ruta de reversión. En Cerravi, las sugerencias requieren revisión humana, las propuestas utilizan los precios disponibles en el catálogo y las monedas permanecen separadas. Forecast es una estimación operativa basada en reglas transparentes del CRM, no una garantía. Un buen conjunto no obliga al copiloto a responder siempre. Comprueba que responda con evidencia y se detenga cuando la decisión no está sostenida.

Hacer red teaming de un AI Sales Copilot no significa probar frases llamativas contra un chatbot. Significa someter un recorrido comercial autorizado a condiciones adversarias para descubrir si puede revelar datos, cruzar permisos, alterar una propuesta o ejecutar una acción fuera del alcance. La prueba cubre la aplicación completa: modelo, instrucciones, recuperación, CRM, archivos, memoria, herramientas, validaciones y revisión humana. Empieza por un permiso escrito. Define el entorno, la versión, las identidades, los datos, las técnicas permitidas, el horario, los límites de volumen y costo, el contacto de emergencia y las condiciones de parada. Utiliza cuentas, destinatarios y datos de laboratorio. Si necesitas comprobar una acción, usa un sandbox o un doble que registre el intento sin producir un efecto real. El objetivo es mejorar un sistema propio o expresamente autorizado, nunca probar servicios ajenos. Después construye el modelo de amenazas desde el negocio. Enumera los activos: precios, descuentos, condiciones, contactos, historial, adjuntos, propuestas, etapas y comunicaciones. Pregunta quién controla cada entrada y qué podría ocurrir si el copiloto la tratara como una orden. Una nota escrita por un usuario, una página recuperada y una respuesta de herramienta son contenido, no autoridad. Dibuja el recorrido y sus límites de confianza. Marca dónde se mezclan instrucciones y datos, dónde se decide una consulta, qué identidad usa cada herramienta y en qué momento el lenguaje puede convertirse en un efecto. Prioriza las fallas por impacto. Cambiar el tono de un borrador no equivale a revelar otra cuenta, inventar un precio o compartir una propuesta sin aprobación. Prueba inyección directa e indirecta por separado. La directa llega en la solicitud e intenta reemplazar las reglas. La indirecta vive dentro de una nota, un correo, una página, un archivo, un campo del CRM, la salida de una API o incluso texto procesado desde una imagen. Crea variantes en español, inglés y portugués, con errores, varios turnos e instrucciones divididas entre campos. El resultado seguro conserva la tarea autorizada, trata el contenido recuperado como datos y se detiene cuando no puede continuar con seguridad. Ejecuta el mismo caso con roles distintos. Comprueba que Owner, Admin, Seller y Viewer solo reciban lo que ya pueden consultar. Pide resúmenes, comparaciones y citas que intenten alcanzar una oportunidad restringida. Revisa también cachés, índices, historiales y memoria. Un rechazo en el texto final no corrige una recuperación previa de información prohibida. La autorización debe actuar antes de que el dato llegue al modelo. Somete las herramientas a abuso controlado. Intenta provocar una función innecesaria, cambiar argumentos, repetir llamadas, encadenar acciones o utilizar una identidad más amplia. Incluye respuestas manipuladas que intenten ordenar una segunda acción. La aplicación debe validar en código la identidad, el objeto y los argumentos, limitar las herramientas por tarea y solicitar aprobación humana antes de cualquier efecto relevante. En ventas, prueba catálogos con productos sin precio, versiones vencidas, importes contradictorios y monedas diferentes. Añade contenido que pida ignorar la fuente o aplicar un descuento no autorizado. El comportamiento correcto muestra el conflicto y espera confirmación. Cerravi no inventa precios y mantiene MXN, USD y otras monedas separadas mientras no exista una conversión aprobada. Prueba también la manipulación de señales. Una apertura de Buyer Room no confirma identidad, lectura, aceptación, contrato, pago ni intención de compra. Una etapa o una nota optimista tampoco garantizan el cierre. Forecast es una estimación operativa basada en reglas transparentes y datos del CRM, no un modelo predictivo entrenado o calibrado. El copiloto debe distinguir observación, inferencia y decisión humana. Documenta cada caso con identificador, versión, rol, precondiciones, entrada, contexto recuperado, herramientas, resultado esperado y condición de parada. Conserva la salida, las fuentes, llamadas, argumentos, tiempos y estado final. Empieza con exploración manual para encontrar rutas inesperadas y automatiza después los casos estables. Una tasa agregada no explica qué control falló. Convierte cada hallazgo en una decisión de ingeniería. Describe el impacto y busca la causa en autorización, recuperación, separación de contenido, herramientas, validación, interfaz, aprobación o monitoreo. Cambiar el prompt puede bloquear una frase y dejar abierta la misma clase de falla. Los controles deterministas deben asumir que el modelo puede equivocarse. Después de corregir, repite el caso original, sus variantes y los escenarios legítimos que podrían quedar bloqueados. Añade la falla confirmada al conjunto de regresión y ejecútala cuando cambien modelo, prompt, fuentes, memoria, permisos, herramientas o autonomía. En Cerravi, una prueba exitosa confirma límites concretos: sugerencias sujetas a revisión humana, precios tomados del catálogo, monedas separadas, señales comerciales sin convertir en certezas y ninguna acción fuera de la autoridad visible.

Un ciclo de feedback para un AI Sales Copilot no es una colección de pulgares arriba y abajo. Es un proceso que convierte una observación del equipo en evidencia reproducible, una causa verificada, un cambio controlado y una prueba que evita que la falla regrese. El ciclo comienza con la tarea original y termina cuando la corrección está desplegada, observada y comunicada. No todo comentario exige cambiar el modelo. Una salida puede fallar por un dato vencido, una recuperación incompleta, una instrucción ambigua, una herramienta, la interfaz o el propio proceso comercial. Primero separa las rutas. Feedback describe utilidad, claridad o preferencia. Un defecto contradice una regla definida. Un problema de datos nace en una fuente ausente, ambigua o vencida. Un incidente implica un impacto relevante que puede requerir contención. Una solicitud propone una capacidad nueva. Clasifica por el efecto observado, no por la explicación inicial. Un usuario puede decir que la IA inventó algo cuando existen dos versiones del mismo dato. Conserva su descripción original y añade una clasificación provisional sin borrar la voz de quien reportó. Captura lo mínimo necesario para investigar. Registra qué intentaba hacer la persona, qué esperaba, qué salida observó y qué hizo después. Relaciona el reporte con fecha, versión, rol, entorno e identificador de ejecución. Indica si el resultado solo fue visible, si se corrigió, se guardó, se compartió o produjo una acción. No obligues al vendedor a copiar conversaciones, documentos completos o datos personales dentro de un ticket. Un buen canal recupera la telemetría autorizada por separado y entrega un identificador para seguir el caso. Protege la evidencia. Una traza puede contener solicitud, respuesta, fuentes recuperadas, argumentos de herramientas, tiempos y errores. Guarda una referencia estable en lugar de duplicar el contenido en chats y hojas. Minimiza o redacta datos personales, restringe el acceso y define retención. Nunca almacenes secretos, tokens o credenciales dentro del prompt o de la traza. Si conviertes un caso real en una prueba, sustituye nombres y detalles que no explican la falla, pero conserva relaciones importantes como rol, permiso, moneda, vigencia o secuencia. Después haz triage. Evalúa qué decisión pudo cambiar, cuántas personas u objetos están expuestos, si el efecto es reversible, si puede propagarse y si los controles actuales lo detienen. Un caso poco frecuente de acceso entre cuentas merece más urgencia que muchos ajustes de tono. Asigna severidad provisional, ruta, responsable y fecha de próxima actualización. Si existe exposición, acción fuera del alcance, precio compartido incorrectamente o propagación, contiene y escala. Si falta evidencia, deja el caso pendiente de confirmación; no lo cierres por comodidad. Reproduce la falla con la versión correcta y en un entorno controlado. Identifica modelo, instrucciones, reglas, fuentes, índice, permisos, herramientas y estado de la interfaz. Empieza con la ejecución original y reduce el caso hasta encontrar la condición necesaria. Cambia un elemento por vez: rol, nota, documento, catálogo, fecha o argumento. Una respuesta parecida no demuestra la misma causa. Si el caso es intermitente, registra frecuencia y variantes. Si no se reproduce, documenta los intentos, revisa si la versión cambió y define qué nueva evidencia permitiría reabrirlo. Busca la causa en el recorrido completo. Toma la afirmación incorrecta y pregunta de qué fuente debía proceder. Comprueba si la fuente estaba disponible y autorizada, si la recuperación la encontró, si una regla transformó el valor, si el modelo recibió contexto contradictorio, si la herramienta validó los argumentos y si la interfaz mostró el faltante. Separa la causa primaria de la falla de control. Un precio puede faltar en el catálogo y llegar al usuario porque ninguna validación exigió coincidencia. Cambiar una frase del prompt no resuelve esa clase de problema. Corrige la capa responsable. Actualiza el dato en su sistema de origen. Aplica permisos antes de recuperar información. Valida precios, monedas, objetos y acciones en código. Utiliza instrucciones para orientar el lenguaje, no como único control de acceso o dinero. Versiona el modelo, el prompt, las fuentes, las reglas y las herramientas que cambien. Conserva la línea base y una ruta de reversión. Si la solución completa tarda, limita la función, retira una fuente o exige revisión adicional. Toda mitigación necesita responsable, vencimiento y condición de retiro. Convierte la falla confirmada en una prueba de regresión. Define entrada, rol, contexto autorizado, hechos obligatorios, afirmaciones prohibidas y comportamiento esperado. La prueba debe fallar contra la versión defectuosa y aprobar contra la candidata. Añade variantes cercanas y casos legítimos. Si bloqueas una instrucción escondida en una nota, confirma también que una nota normal siga siendo útil. Si detienes una moneda ausente, comprueba que una partida completa todavía pueda cotizarse. Prevenir una falla no justifica romper el trabajo autorizado. Valida antes de ampliar. Compara la versión activa y la candidata con el mismo conjunto. Revisa el caso original, sus variantes, escenarios frecuentes y controles críticos. Una mejora promedio no compensa una nueva falla de permiso, precio o acción. Después del despliegue, comienza con el alcance mínimo y etiqueta reportes, trazas y métricas con la versión. Observa si disminuye el patrón sin aumentar descartes o correcciones en otra parte. Menos reportes no demuestra mejora si el canal se volvió difícil o el equipo dejó de usar la función. Cierra el ciclo con evidencia y con una respuesta. Comunica qué se confirmó, qué cambió, qué límite permanece y desde qué versión aplica. El estado cerrado exige clasificación, causa o límite de investigación, corrección o mitigación, pruebas, aprobación, despliegue y comunicación. Vincula duplicados para conservar el volumen y los contextos. Mide reportes por tipo y versión, severidad, tiempo de triage, tiempo de reparación, recurrencia, reaperturas y conversión a regresiones. No uses la cantidad de correcciones para vigilar o clasificar vendedores; eso reduce el reporte honesto. En Cerravi, el ciclo refuerza límites verificables. Las sugerencias permanecen sujetas a revisión humana. Las propuestas utilizan productos y precios disponibles en el catálogo cargado. Si falta un importe o existen fuentes contradictorias, Cerravi muestra el faltante y espera confirmación; no inventa la cifra. MXN, USD y otras monedas permanecen separadas sin una conversión aprobada. Una apertura de Buyer Room aporta contexto, pero no confirma identidad, aceptación, contrato, pago ni intención. Forecast es una estimación operativa basada en reglas transparentes del CRM, no una garantía. El objetivo no es lograr que el copiloto parezca correcto. Es conseguir que el equipo pueda detectar, explicar, corregir y comprobar cada falla importante.

Un AI Sales Copilot cambia aunque la pantalla parezca igual. Una nueva versión del modelo, una instrucción, una fuente, un permiso, una integración o un punto de aprobación pueden modificar qué datos entran, qué resultado aparece y quién puede actuar. Por eso la revisión realizada antes del lanzamiento no cubre automáticamente todas las versiones futuras. Empieza por una línea base reproducible. Registra la versión activa, el modelo, las instrucciones, fuentes, herramientas, permisos, integraciones y escenarios autorizados. Usa identificadores estables. Decir que producción utiliza el prompt nuevo no permite comparar ni volver atrás. Conserva la configuración anterior mientras la candidata se estabiliza, sin guardar secretos dentro del historial. Después abre una solicitud. Explica el problema observable, la evidencia disponible, el componente afectado, la población incluida, lo que queda fuera y quién coordina la decisión. Una mejora del resumen de oportunidades no debe presentarse como una mejora general de ventas. Clasifica el impacto antes de decidir las pruebas. Pregunta qué datos puede leer o generar, quién verá el resultado, si interviene en una decisión, si prepara una comunicación externa, si afecta dinero o compromisos y qué tan reversible es. Un cambio técnico pequeño puede tener un impacto operativo alto. Diseña el conjunto de evaluación antes de mirar los resultados. Incluye casos normales, datos incompletos, ambigüedad, permisos insuficientes, solicitudes fuera del alcance y escenarios comerciales críticos. Compara la versión candidata con la activa usando los mismos casos y criterios. Conserva ejemplos aceptados, corregidos y descartados. Una cifra agregada no debe esconder una falla importante. Separa preparación, revisión y autorización según el impacto. Negocio valida el proceso y el lenguaje comercial. Tecnología revisa configuración y recuperación. Datos confirma las fuentes. Seguridad y privacidad evalúan acceso. Soporte prepara la respuesta. La decisión final debe ser explícita: aprobar, aprobar con condiciones, rechazar o pedir más evidencia. Publica una versión nueva sin sobrescribir la anterior. Vincula configuración, pruebas, responsables, riesgos conocidos, fecha y plan de reversión. Separa desarrollo, pruebas y producción. Cuando haga falta, mantén una versión estable y una candidata claramente identificadas. Activa primero el grupo o escenario mínimo que permita observar la nueva condición. Define población, duración, soporte, señales y criterios de pausa. Informa a los usuarios qué cambió, qué sigue igual y dónde reportar. Una activación silenciosa complica el análisis. Monitorea operación, calidad, riesgo, adopción y efecto comercial por separado. Etiqueta los eventos con la versión activa. Revisa errores, latencia, correcciones, descartes, escalaciones, permisos, tickets e incidentes. Una diferencia después del despliegue no demuestra por sí sola que el cambio la causó. Puede intervenir capacitación, estacionalidad o la composición del grupo. Prepara la reversión antes de necesitarla. Define quién puede pausar y qué señales obligan a contener. Revertir significa restaurar un estado conocido o pasar al proceso manual; no borrar evidencia. Si la versión anterior ya no es segura, limita herramientas, fuentes o acciones mientras investigas. Cierra el cambio con una decisión documentada y retira accesos, endpoints y materiales obsoletos. En Cerravi, las sugerencias requieren revisión humana, los precios proceden del catálogo disponible y las monedas permanecen separadas. El copiloto organiza contexto; no garantiza cierres ni sustituye la responsabilidad operativa de la empresa.

Preparar evidencia para auditar un AI Sales Copilot no significa llenar una carpeta con capturas. Una auditoría relaciona una afirmación con un criterio, un alcance, un periodo y hechos que otra persona puede examinar. Si afirmas que el copiloto solo utiliza fuentes autorizadas, debes mostrar cuáles son, qué versión operó, cómo se aplica el permiso y qué prueba permite comprobarlo. Distingue auditoría de revisión periódica. El review operativo reúne señales para decidir si el sistema continúa o cambia. La auditoría examina si procesos y resultados se ajustan a criterios definidos, con el grado de independencia acordado. Pueden compartir artefactos, pero no conclusiones automáticas. Empieza por el mandato. Registra quién solicita el trabajo, quién lo realiza, quién recibe el resultado y qué independencia necesita. Define si examinas diseño, implementación, operación durante un periodo, seguimiento de hallazgos o preparación para una revisión externa. No llames auditoría independiente a una autoevaluación del equipo constructor. Enumera criterios concretos: política, contrato, obligación aplicable, control, estándar adoptado o condición de aprobación, con versión y fecha. Fija organizaciones, procesos, productos, casos, ambientes, regiones, datos, integraciones y periodo incluidos. Declara exclusiones y restricciones. Si una evidencia no puede examinarse por privacidad o segregación, registra un mecanismo alternativo; no la marques como revisada. Construye una matriz antes de recolectar. Crea una fila por criterio o control y añade afirmación verificable, riesgo, artefacto esperado, sistema fuente, propietario, custodio, periodo, población, método de prueba y estado. Diferencia disponible, solicitado, recibido, validado, insuficiente, restringido y no aplicable. Relaciona cada artefacto con la pregunta que responde. Una política demuestra diseño. Una configuración exportada puede demostrar implementación en una fecha. Una muestra de eventos aporta evidencia de operación. Una prueba evalúa eficacia dentro de sus límites. Evita duplicados. Si un dashboard cambia continuamente, registra consulta, filtros, zona horaria, periodo y fecha de extracción para poder reconstruirlo. Congela la identidad del sistema examinado. Entrega ficha de inventario con propósito, caso, responsable, usuarios, personas afectadas, nivel de riesgo, estado y dependencias. Añade arquitectura y flujo de datos con límites de confianza. La marca del modelo o una captura no describe el sistema completo. Relaciona versión de aplicación, modelo, instrucciones, reglas, fuentes, índices, herramientas, integraciones, permisos, flags y ambientes. No incluyas secretos. Usa identificadores, manifiestos, commits o configuraciones redactadas. Conserva fechas de activación y retiro y el mapa entre versiones y periodos. Si hubo despliegue gradual, identifica cohortes. Un resultado de una versión no demuestra otra sin evidencia de equivalencia. Demuestra autoridad y decisiones. Incluye política de uso, nivel de riesgo, evaluación de impacto, registro de riesgos y RACI vigentes durante el periodo. Vincula responsables y aprobadores con alcance de autoridad, suplencia y segregación. Una lista de nombres no demuestra accountability. Entrega resoluciones de diseño, lanzamiento, cambios, excepciones, incidentes, reanudación y retiro. Cada decisión muestra versión, evidencia considerada, condiciones, incertidumbre, residual, fecha y autoridad. Conserva disensos y pendientes materiales. La asistencia a una capacitación puede demostrar participación, pero no que un control técnico operó. Cada artefacto de gobierno debe conectarse con el resultado que tenía que producir. Traza datos, fuentes y permisos sin copiar el universo. Documenta categorías, procedencia, propósito, calidad, vigencia, transformaciones, destinos, regiones, retención y eliminación. Distingue configuración, grounding, entrada, salida, feedback, evaluación, telemetría y soporte. Muestra cómo identidades de usuario y servicio limitan recuperación y herramientas. Prueba accesos permitidos y denegados con cuentas controladas. Incluye altas, cambios, bajas, revisiones y excepciones. Un diagrama no demuestra que la aplicación aplique el permiso antes de recuperar. Minimiza el paquete. Usa inventarios, metadatos, muestras redactadas o acceso controlado cuando basten. No copies conversaciones, catálogos o contactos completos si una referencia verificable responde el criterio. Conserva evaluaciones reproducibles. Relaciona cada prueba con versión, conjunto de casos, población representada, rúbrica, evaluador, configuración, fecha y resultado. Guarda ejemplos aceptados, corregidos y fallidos, no solo un porcentaje. Explica exclusiones, variabilidad, tamaño de muestra y confianza permitida. Incluye pruebas funcionales, seguridad, privacidad, groundedness, exactitud, sesgo o accesibilidad según el riesgo. El red teaming autorizado conserva permiso, entorno, técnica, parada, hallazgo, causa, corrección y retest. Vincula fallas confirmadas con regresiones y versiones corregidas. Si cambia el criterio o el conjunto, conserva la línea base y explica si la comparación sigue siendo válida. Una prueba de laboratorio no demuestra operación continua. Separa evidencia de diseño, implementación, operación y eficacia. Para cada control describe objetivo, riesgo, mecanismo, dueño, frecuencia, cobertura, dependencia, excepción y señal de falla. Una política no prueba implementación; un evento no prueba cobertura; una prueba aislada no garantiza eficacia futura. Selecciona población y muestra de forma trazable. Registra universo, periodo, criterio de selección, elementos examinados y excepciones. Una muestra dirigida busca riesgo alto; una muestra representativa responde otra pregunta. No las confundas. Conserva resultados negativos. La ausencia de errores en una muestra no demuestra ausencia en toda la población. Documenta desviación, compensación, residual y límite de la conclusión. Diseña logs y trazas para reconstruir sin registrar de más. Una traza puede relacionar identidad, timestamp, zona horaria, ejecución, versión, fuente recuperada, herramienta, argumento, permiso, salida, aprobación y estado final. Microsoft recomienda registrar contexto de identidad, procedencia e invocaciones, pero gobernar captura y retención con contratos de datos que consideren privacidad, residencia y minimización. No todos los campos necesitan texto completo. Usa identificadores, hashes, categorías y referencias cuando basten. Redacta datos personales y secretos, cifra y limita acceso. Comprueba qué genera realmente tu arquitectura. La cobertura documentada para un producto o una licencia no debe extrapolarse a Cerravi ni a otra plataforma. Protege integridad y cadena de custodia. Conserva origen, creador, fecha, versión y transformaciones. Para exportaciones materiales usa hash, firma, almacenamiento inmutable o un control proporcional. Si redactas un archivo, registra el cambio y separa el original bajo acceso autorizado. Define quién extrae, transfiere, recibe, consulta y elimina. Evita adjuntos dispersos. La sala de evidencia necesita índice, permisos por función, caducidad, registro de acceso, versión y canal de aclaraciones. Prueba recuperabilidad. Un backup que nadie puede localizar, abrir o relacionar con la versión no está listo. Retener todo indefinidamente aumenta riesgo y no mejora automáticamente la prueba. Opera solicitudes y hallazgos con trazabilidad. Cada solicitud de información tiene identificador, criterio, formato, periodo, responsable, fecha y estado. Controla duplicados y cambios. Haz una prueba de recorrido: toma una afirmación importante y reconstruye criterio, decisión, configuración, operación y cierre. Si depende de mensajes privados o memoria individual, registra un vacío documental. Un hallazgo distingue criterio, condición, evidencia, causa, efecto o riesgo y alcance. Separa hecho de recomendación. Cada acción correctiva define resultado, dueño, fecha, dependencia, validación y evidencia de cierre. Un ticket cerrado no prueba remediación. El informe declara limitaciones, muestreo y dependencia de información proporcionada. En Cerravi, la evidencia debe sostener límites verificables. Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Una automatización añadida por una empresa pertenece a su propio alcance. Las propuestas utilizan productos y precios del catálogo. Si falta un importe, se confirma; Cerravi no lo inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. Examina esto con catálogos y casos controlados, sin publicar precios o clientes reales. Una apertura de Buyer Room es actividad, no identidad, aceptación, contrato, pago o intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. El paquete facilita el examen; no es certificación ni prueba automática de cumplimiento.

Probar un control de AI Sales Copilot no consiste en mostrar que existe una política, una pantalla o un botón. La pregunta es si el mecanismo produce el resultado definido frente al riesgo, dentro del alcance y durante el periodo examinado. Separa cuatro niveles. El diseño explica por qué el control podría funcionar. La implementación confirma que está configurado en la versión y el entorno correctos. La operación demuestra que se ejecutó con la frecuencia y cobertura esperadas. La eficacia examina si realmente redujo el riesgo sin crear una falla material distinta. Un control presente puede ser ineficaz si deja una ruta alternativa, depende de una fuente vencida o genera una alerta que nadie atiende. Empieza por el escenario de riesgo. Describe condición, evento, persona u objeto afectado y consecuencia. Después redacta una afirmación observable. Por ejemplo: una persona sin permiso no puede recuperar una cuenta; una propuesta se detiene si falta precio; una herramienta fuera de la lista autorizada no se ejecuta; una comunicación externa requiere aprobación previa; el proceso manual continúa cuando el copiloto se pausa. Documenta mecanismo, dueño, operador, frecuencia, población, dependencias, entrada, salida, señal de falla y acción esperada. Si dices que existe revisión humana, aclara quién revisa, cuándo, qué información recibe, qué puede cambiar y qué ocurre cuando rechaza. Define el criterio de éxito antes de probar. No ajustes el umbral después para convertir una falla en aprobado. Diseña el procedimiento antes de mirar resultados. NIST SP ochocientos guion cincuenta y tres A distingue métodos como examinar, entrevistar y probar para evaluar controles de seguridad y privacidad. No es una norma específica para un copiloto comercial, pero ayuda a separar evidencias. Examinar confirma documentos, configuraciones y registros. Entrevistar permite comprender responsabilidades y excepciones, aunque una declaración no sustituye la operación. Probar ejecuta el mecanismo y compara el resultado con el criterio. Escribe prerrequisitos, identidad, datos, versión, acción, resultado esperado, evidencia y condición de excepción. Asigna quién prepara, ejecuta, revisa y acepta el residual. Cuando la independencia sea importante, evita que una sola persona diseñe el control, elija la muestra, haga la prueba y apruebe la conclusión. Fija la identidad del sistema. Relaciona versión de aplicación, modelo, instrucciones, reglas, fuentes, permisos, herramientas, integraciones y banderas. Registra fecha, región, cohorte y ambiente. Una prueba en desarrollo no demuestra producción y un resultado de la versión anterior no cubre la candidata sin evidencia de equivalencia. Traza el recorrido desde solicitud hasta efecto: usuario, sesión, API, recuperación, fuente, modelo, herramienta, validación, aprobación, escritura y comunicación. Marca límites de confianza y rutas alternativas. Incluye importaciones, endpoints antiguos, enlaces públicos y tareas administrativas cuando entren en alcance. Usa cuentas y datos controlados. No pruebes acceso indebido con clientes reales si registros sintéticos permiten validar el mecanismo. Define población, cobertura y muestra. La población puede reunir ejecuciones, propuestas, aprobaciones, cambios, usuarios, permisos o alertas de un periodo. Reconcilia el universo con la fuente. Si excluye errores que nunca llegaron al log, no puede demostrar cobertura completa. Selecciona la muestra según la pregunta. Una muestra dirigida busca casos de mayor impacto, roles especiales, datos incompletos, integraciones y excepciones. Una aleatoria ayuda a observar consistencia en una población definida. Una estratificada conserva grupos como rol, región, moneda, canal o versión. Documenta filtros y criterio para no escoger únicamente casos favorables. No existe un tamaño universal. Considera frecuencia, variabilidad, criticidad, historial y cambios. Cero excepciones en la muestra no significa riesgo cero. Combina casos positivos, negativos, de límite y de recuperación. El positivo confirma que el trabajo autorizado sigue funcionando. El negativo intenta ejecutar lo prohibido. El de límite utiliza datos ausentes, contradictorios, vencidos o máximos. El de recuperación fuerza una dependencia indisponible, una aprobación rechazada o una alerta sin entrega. Prueba rutas equivalentes como interfaz, API, importación, automatización y cuenta administrativa. Cambia un factor por vez para encontrar la causa y después combina condiciones plausibles. Conserva fallas y resultados parciales. Un mecanismo puede bloquear el efecto, pero no registrar el intento; puede alertar, pero no contener. Califica prevención, detección, respuesta y recuperación por separado. No promedies preguntas distintas para ocultar un punto crítico. Para datos y grounding, crea una fuente válida, una ausente, una no autorizada, una vencida y dos contradictorias. Comprueba recuperación, atribución, comportamiento ante faltantes y salida visible. El objetivo no es que el texto parezca prudente, sino impedir que la incertidumbre se convierta en un hecho comercial. Para precios, usa catálogos controlados con producto conocido, producto sin importe, versión antigua, moneda distinta, descuento fuera de autoridad y combinación de partidas. Verifica que el valor venga de la fuente aprobada, que el faltante obligue a revisar y que MXN, USD u otras monedas no se sumen ni conviertan sin una regla autorizada. Revisa también PDF, DOCX, Buyer Room e historial. Una validación en el borrador no basta si otra salida puede omitirla. Para permisos, construye una matriz de identidades con acceso permitido y denegado a cuentas, oportunidades, catálogos, notas, archivos y acciones. Prueba aislamiento entre espacios, cambio de rol, usuario desactivado, sesión antigua y credenciales del servicio. Una opción oculta no es control si el endpoint aún responde. Para herramientas, confirma lista autorizada, esquema de argumentos, límites, timeout, idempotencia, aprobación y registro. Intenta parámetros incompletos, objeto de otra cuenta, repetición y llamada después de revocar acceso. La autorización debe aplicarse en la herramienta y en la fuente, no depender solo del prompt. Valida el estado final. Si una acción falla después de escribir parcialmente, prueba compensación y recuperación. Nunca ejecutes una prueba destructiva sin ambiente y mandato autorizados. La supervisión humana también se prueba. La persona adecuada debe recibir contexto suficiente antes del efecto y poder aprobar, editar, rechazar o escalar. Prueba rol, suplencia, ausencia, conflicto, volumen y presión de tiempo. Un botón no sirve si aparece después del envío o si el revisor no puede ver fuente, moneda o cambio material. No midas únicamente tasa de aprobación. Observa tiempo disponible, correcciones, rechazos, escalaciones y errores que escaparon. Una aprobación casi universal puede significar alta calidad o revisión superficial. Ensaya la parada y el modo manual. Pausa el componente de forma controlada, confirma que el equipo reconoce el estado, mantiene el proceso esencial, conserva evidencia y sabe quién puede reanudar. Un runbook guardado no demuestra recuperabilidad. Para demostrar operación durante un periodo, reconcilia ejecuciones esperadas con eventos observados. Si el control opera por transacción, compara población, decisión y excepción. Si es diario o semanal, revisa calendario, ejecuciones omitidas, alertas y resolución. Si es continuo, busca huecos de telemetría y cambios de configuración. Comprueba que la señal llegue a alguien capaz de actuar. Mide tiempo desde evento hasta detección, triage, contención y cierre cuando el objetivo lo requiera. Una alerta abandonada no equivale a una atendida. Cruza fallas con cambios, incidentes, feedback y excepciones. La ausencia de reportes puede indicar buen desempeño, baja adopción o un canal roto. No conviertas correlación en causalidad. Califica cada afirmación con criterio, versión, población, muestra, evidencia, resultado esperado, observado, desviación y límite. Puedes usar eficaz, parcialmente eficaz, ineficaz, no probado y no aplicable, con definiciones previas. No uses no aplicable para esconder evidencia ausente. Distingue excepción aislada, falla sistémica, limitación de diseño y falla de evidencia. Evalúa alcance e impacto antes de agregar. Una sola lectura entre cuentas puede invalidar el aislamiento aunque el promedio parezca alto; varios errores cosméticos no equivalen automáticamente a una exposición. El marco de accountability de GAO propone preguntas sobre gobernanza, datos, desempeño y monitoreo. Puede inspirar cobertura, pero no convierte una prueba interna en auditoría gubernamental, cumplimiento ni certificación. Cierra la corrección con retest. Registra causa, resultado esperado, dueño, fecha, dependencia, contención y criterio de cierre. Corregir un ejemplo no basta si la causa afecta a la población. Ejecuta el caso original contra la versión corregida, añade variantes y confirma que el escenario legítimo siga funcionando. Después observa el control durante un periodo proporcional. Un ticket cerrado o un despliegue exitoso demuestran actividad, no eficacia sostenida. Si aceptas residual, documenta autoridad, motivo, duración, compensación, señal, vencimiento y condición de reapertura. En Cerravi, estas pruebas deben respetar afirmaciones concretas. Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Las propuestas utilizan productos y precios del catálogo cargado. Si falta un importe, se muestra para revisión y no se inventa. Las monedas permanecen separadas salvo conversión aprobada. La actividad de una Buyer Room aporta contexto, pero no prueba identidad, aceptación, contrato, pago o intención. Forecast es una estimación operativa por reglas transparentes del CRM, no una garantía. Una prueba aporta evidencia sobre una versión, población, periodo y criterio. No certifica Cerravi, a la empresa ni todos los usos futuros.

Gestionar un hallazgo de AI Sales Copilot no significa mover un ticket hasta cerrado. Un hallazgo demuestra una diferencia entre un criterio definido y una condición observada. Puede surgir de una auditoría, una evaluación, una prueba de control, red teaming, monitoreo o feedback. Distingue sus registros. Un riesgo describe lo que podría ocurrir. Un incidente coordina la respuesta a un evento con impacto real o potencial. Una excepción autoriza temporalmente apartarse de una regla. Un defecto describe un comportamiento técnico. Pueden relacionarse, pero cerrar uno no resuelve automáticamente los demás. El objetivo no es reducir el número de hallazgos. Es hacer visible una desviación, limitar su efecto, corregir la causa y comprobar que no reaparece. Redacta el hallazgo para que otra persona pueda reconstruirlo. Empieza con el criterio: política, control, requisito, condición de lanzamiento, contrato o comportamiento aprobado, con versión y fecha. Después describe la condición sin adornos: identidad, tarea, entorno, datos, versión, recorrido y resultado. Separa observación, inferencia y recomendación. Relaciona evidencia mínima suficiente, como identificador de ejecución, configuración, fuente, log, salida redactada, prueba o referencia restringida. No copies secretos ni conversaciones completas si un identificador permite examinarlos con acceso controlado. Añade alcance conocido, población potencial, frecuencia, primera y última observación, consecuencia y causa confirmada o hipótesis. Si no conoces la causa, dilo. Valida antes de priorizar. Confirma que la evidencia corresponde al sistema y al periodo indicados. Reproduce con datos controlados cuando sea seguro y revisa permisos, fuente, modelo, instrucciones, reglas, herramientas y estado final. Compara con un caso legítimo. Si no puedes reproducirlo, no lo descartes automáticamente: puede depender de concurrencia, una cohorte o una versión ya retirada. Busca duplicados y relaciones sin borrar historias. Varios síntomas pueden compartir una causa y un mismo síntoma puede tener causas diferentes. Conserva el reporte original. Usa estados explícitos: nuevo, en validación, confirmado, duplicado, no reproducido, fuera de criterio, en remediación, listo para retest, cerrado o reabierto. Prioriza por impacto y exposición, no por presión de calendario. Identifica el activo, la persona, la organización o el compromiso afectado; la reversibilidad; la población expuesta; las condiciones necesarias y la capacidad de propagación. Una sola lectura entre organizaciones puede ser crítica aunque la tasa agregada sea pequeña. Separa severidad y urgencia. La severidad representa impacto y exposición. La urgencia añade uso actual, ausencia de compensación y tiempo hasta un efecto. NIST AI RMF Manage propone priorizar respuestas y documentar planes y equipos responsables. Es una guía voluntaria, no una escala universal. Si falta evidencia sobre posibilidad, conserva la incertidumbre y abre una investigación; no fabriques una precisión numérica. Separa contención de remediación. Contener reduce exposición mientras se investiga: pausar una herramienta, limitar una fuente, retirar un enlace, revocar una credencial, exigir aprobación adicional o volver al proceso manual. Define autoridad, alcance, comunicación, vigencia y evidencia de que quedó aplicada. Contener no elimina la causa. Un filtro puede bloquear una frase y dejar abierta la clase de falla. Apagar una integración puede proteger datos y detener un proceso esencial. Registra fallback, impacto operativo y condición para retirar la medida. Si existen datos expuestos, una acción no autorizada, indisponibilidad material o impacto activo, inicia también la respuesta a incidentes. El registro del hallazgo no sustituye preservación de evidencia, comunicación o recuperación. Investiga el recorrido completo. Traza identidad, sesión, fuente, recuperación, memoria, instrucciones, modelo, herramienta, validación, aprobación, escritura y comunicación. Pregunta dónde debía interrumpirse el escenario y por qué el control no lo hizo. Una salida errónea puede nacer en datos vencidos, autorización aplicada demasiado tarde, esquema permisivo, conflicto de versión, interfaz ambigua o revisión sin contexto. Distingue causa inmediata, contribuyentes y falla de control. Cambiar un prompt puede modificar una respuesta sin corregir permisos, procedencia o acciones. Amplía el alcance cuando la causa sea compartida. Si un validador defectuoso afecta PDF, DOCX, Buyer Room y API, corregir solo la pantalla no cubre la población. Convierte la causa en una acción correctiva verificable. Define el resultado observable, una persona dueña con autoridad, fecha, dependencias, recursos, criterio de aceptación y evidencia de cierre. Separa las tareas de investigar, desarrollar o capacitar del resultado que debe reducir el riesgo. Considera eliminar la ruta, limitar alcance o autonomía, corregir datos o permisos, fortalecer validación, introducir compensación, volver al proceso manual, sustituir el componente o aceptar residual con autoridad y vencimiento. NIST contempla mitigar, transferir, evitar o aceptar riesgos. La elección necesita contexto. Si la fecha cambia, conserva motivo, exposición durante la demora, contención vigente y nueva decisión. No muevas silenciosamente el plazo. Implementa la corrección como un cambio controlado. Relaciona commit, configuración, modelo, instrucciones, fuente, permiso, migración, feature flag y ambiente. Revisa seguridad, privacidad, datos, accesibilidad y operación según el riesgo. Prueba con datos protegidos y evita efectos reales innecesarios. Define despliegue gradual cuando ayude a detectar regresiones, y establece señales de éxito, error, parada y rollback antes de publicar. Para herramientas, valida identidad, objeto, argumentos, límites, idempotencia y estado parcial. Actualiza controles, runbooks, inventario, modelo de amenazas, registro de riesgos, evaluación y formación cuando corresponda. Corregir el código sin corregir la operación puede dejar la causa abierta. El retest empieza con el procedimiento que confirmó el hallazgo, sobre la versión corregida. Repite el caso original y conserva resultado esperado, observado y evidencia. Después prueba variantes de idioma, rol, ruta, objeto, fuente, moneda, integración y secuencia que compartan la causa. Incluye escenarios legítimos. Una solución que también bloquea el trabajo autorizado cambia un riesgo por otro. Comprueba desempeño funcional, permisos, trazabilidad, fallback y experiencia de revisión. Añade el caso estable al conjunto de regresión y ejecútalo cuando cambien modelo, prompts, recuperación, memoria, herramientas, fuentes o permisos. NIST SP ochocientos guion cincuenta y tres A ofrece métodos adaptables para examinar, entrevistar y probar controles; no es una receta específica para un copiloto comercial. Una demostración exitosa confirma que la corrección puede funcionar. Para afirmar que opera, observa la población y el periodo acordados. Reconcilia ejecuciones esperadas con eventos, busca rutas sin telemetría, revisa alertas, excepciones y cambios y confirma que alguien actuó cuando correspondía. El periodo depende de frecuencia y riesgo. Un control por transacción puede necesitar una muestra estratificada; uno semanal necesita varias ejecuciones; un permiso crítico puede requerir prueba determinista y monitoreo continuo. Declara qué cubrió la observación. Mide tiempo hasta validación, contención, corrección y retest, reincidencia y hallazgos vencidos. Evita premiar solo cierres rápidos o pocos reportes, porque esos incentivos favorecen ocultar problemas. Cierra con un paquete de evidencia. Incluye criterio y condición originales, alcance, causa, contención, cambio, versión, retest, operación, regresiones, riesgo residual y limitaciones. Una persona con autoridad distinta del ejecutor revisa cuando el impacto o la independencia lo exigen. Elige una disposición clara: remediado, parcialmente remediado, aceptado, transferido, evitado, sustituido o no válido con justificación. Si queda residual, registra responsable, condiciones, compensación, vigencia y siguiente revisión. Define disparadores de reapertura: recurrencia, falla de regresión, cambio de dependencia, compensación vencida, nueva evidencia, ampliación del alcance o incidente relacionado. El cierre administrativo no elimina la historia ni las pruebas. Opera el portafolio sin distorsionar el riesgo. Agrupa por severidad, estado, edad, dueño, sistema, control, causa y fecha objetivo. Muestra nuevos, confirmados, contenidos, vencidos, listos para retest, reabiertos y cerrados. Separa inventario abierto del flujo del periodo. Diez cierres no son mejora si entraron veinte hallazgos materiales o el backlog crítico envejece. Observa tiempo hasta contención, reincidencia, extensiones, aceptaciones vencidas, controles sin prueba y cierres rechazados. Interpreta cada métrica con volumen de uso y cobertura de detección. Una caída de hallazgos puede significar mejor control o un canal roto. No cambies severidades hasta que el tablero parezca verde. En Cerravi, el proceso se aplica a límites verificables. Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Las propuestas utilizan productos y precios disponibles en el catálogo. Si falta un importe, se pide confirmación; Cerravi no lo inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. La corrección debe cubrir borrador, PDF, DOCX, Buyer Room y cualquier destino aplicable. La actividad de Buyer Room es una señal y no demuestra identidad, aceptación, contrato, pago o intención. Forecast es una estimación operativa por reglas transparentes del CRM, no un modelo predictivo entrenado o calibrado ni una garantía. Un cierre aporta evidencia sobre un alcance, una versión y un periodo; no certifica Cerravi, a la empresa ni el cumplimiento de una obligación.

El aseguramiento continuo de un AI Sales Copilot no es una auditoría permanente ni un tablero que declara confianza para siempre. Mantiene una relación vigente entre riesgo, control, prueba, evidencia y decisión mientras cambian el sistema y su contexto. Distingue los procesos. El monitoreo detecta estado y señales. La evaluación prueba comportamientos. El control de cambios conserva identidad y autorización. La gestión de hallazgos corrige desviaciones. La revisión periódica decide si continuar. El aseguramiento coordina su cobertura para mostrar qué afirmaciones siguen demostradas, cuáles tienen evidencia vencida y dónde existe deuda. NIST AI RMF Measure propone revisar regularmente la pertinencia de las métricas y la eficacia de los controles. Es una guía voluntaria y no define una frecuencia universal ni una certificación. Define primero la unidad que vas a asegurar. Nombra un caso concreto: resumir una oportunidad, proponer un siguiente paso, preparar una propuesta, consultar un catálogo o compartir una Buyer Room. Registra organización, usuario, persona afectada, ambiente, región, datos, modelo, instrucciones, fuentes, memoria, herramientas, permisos, integraciones, interfaz y efectos permitidos. Versiona aplicación, configuración, prompts, índices, reglas, roles, flags y proveedores. Conserva fecha de activación, cohortes y retiro. Una conclusión sobre una versión no cubre automáticamente otra aunque el nombre comercial siga igual. Mantén los límites visibles. Si una automatización externa de correo queda fuera, registra quién asegura esa dependencia y cómo amplía autoridad o exposición. Convierte los riesgos prioritarios en afirmaciones observables. Una persona sin permiso no recupera otra cuenta. Una propuesta se detiene si falta precio. Una herramienta no autorizada no se ejecuta. Una comunicación externa necesita aprobación. Una fuente vencida genera una señal. El proceso esencial continúa cuando el copiloto se pausa. Para cada afirmación registra riesgo, control, mecanismo, dueño, operador, población, frecuencia, dependencia, criterio de éxito, señal de falla y respuesta. Separa diseño, implementación, operación y eficacia. Una política puede demostrar diseño; una configuración, implementación; una población reconciliada, operación; y una prueba con resultado, eficacia dentro de sus límites. La presencia de un control no demuestra el resultado. Crea un mapa de cobertura y deuda de evidencia. Cruza cada afirmación con método y artefacto. Marca probado, parcialmente probado, no probado, no aplicable con justificación y evidencia vencida. Añade última ejecución, versión, población, resultado, hallazgo y próxima fecha o evento. Una celda verde sin enlace ni fecha no es evidencia. Mide cobertura por riesgo, no por cantidad de controles. Diez pruebas de formato no compensan una autorización crítica sin evaluar. Muestra rutas, roles, regiones, monedas, fuentes y destinos no cubiertos. Si un mismo log apoya varios controles, explica qué campos, filtros, periodos y poblaciones sostienen cada afirmación. Una captura aislada no demuestra operación durante un intervalo. Asigna vigencia según riesgo y velocidad de degradación. Considera materialidad, frecuencia, variabilidad, dependencias, historial de fallas y rapidez con la que un cambio modifica el resultado. Un permiso crítico puede comprobarse en cada solicitud; una revisión de responsabilidades puede ser menos frecuente y activarse con cambios organizacionales. NIST señala que cambios operativos, data drift y model drift justifican revisar métricas y controles. No todo copiloto utiliza un modelo propio entrenado o un detector formal de drift. Habla de cambios observados en datos, comportamiento, contexto o dependencias cuando esa sea la evidencia. Documenta por qué elegiste cada intervalo. La evidencia también puede vencer antes por un cambio, hallazgo, incidente o dependencia perdida. Combina calendario y disparadores por evento. Revalida cuando cambien modelo, instrucciones, recuperación, memoria, fuente, índice, permisos, herramientas, integraciones, interfaz, autonomía, población, región, volumen o proveedor. Añade incidentes, hallazgos, excepciones, quejas, degradación y obligaciones nuevas. No repitas todo de forma indiscriminada. Relaciona el componente cambiado con flujos, controles, pruebas y artefactos dependientes. Un cambio de copy puede requerir accesibilidad y comprensión. Un cambio de identidad reabre aislamiento, permisos, logs y recuperación. Un nuevo destino externo amplía aprobación, privacidad y respuesta. Cada disparador necesita una acción y una condición de bloqueo: qué se repite, quién revisa, qué continúa y qué queda limitado. Combina señales automáticas y evaluación humana. Automatiza controles deterministas y comprobaciones estables: autorización, esquemas de argumentos, origen de precios, separación de monedas, expiración, integridad de configuración, cobertura de logs, regresiones y reconciliación de poblaciones. Conserva versión, entrada controlada, resultado y error sin secretos innecesarios. Utiliza muestreo y personas para utilidad, contexto comercial, supervisión significativa, interpretación de señales y casos ambiguos. Define rúbrica, población, selección, evaluador y desacuerdo. Incluye ejercicios menos frecuentes para rutas de alto impacto: red teaming autorizado, pausa, recuperación, revocación, fallo de proveedor y modo manual. NIST SP ochocientos guion ciento treinta y siete aporta un marco de monitoreo continuo de seguridad; no es una norma específica de IA. Obtén evidencia de producción sin vigilar ni registrar de más. Define la población antes de muestrear: ejecuciones, propuestas, aprobaciones, permisos, alertas, cambios o usuarios dentro de un periodo. Reconcilia el universo con su fuente y documenta huecos. Una muestra solo sustenta conclusiones sobre la población que representa. Minimiza los datos. Utiliza identificadores, categorías, hashes, metadatos y referencias restringidas cuando basten. Redacta datos personales y secretos, limita acceso y aplica retención. No conviertas el programa en puntuación individual de vendedores ni copies conversaciones en varios tickets. Distingue salida visible, borrador guardado, objeto compartido y acción ejecutada. Una señal no demuestra causa o impacto sin contexto. Conserva línea base y comparabilidad. Mantén un conjunto estable de controles críticos y casos frecuentes para comparar la versión activa con la candidata. Registra cambios de rúbrica, conjunto, evaluador, población y entorno. Si cambia el método, conserva la línea anterior y limita la comparación. Segmenta por versión, rol, fuente, moneda, canal, región o cohorte cuando sea material. Un promedio puede esconder una falla grave en un grupo pequeño. Tampoco presentes toda variación como causal: capacitación, estacionalidad, composición y volumen pueden intervenir. Define tolerancias y condiciones de investigación antes de mirar la tendencia. No muevas el umbral para conservar un estado verde. Una condición crítica puede obligar a contener aunque aparezca una sola vez. Ajusta independencia y competencia al impacto. Separa preparación, ejecución, revisión y aceptación cuando el riesgo lo requiera. El equipo constructor puede generar evidencia y corregir, pero otra función debe poder cuestionar la muestra, rechazar la conclusión y escalar. NIST recomienda involucrar expertos internos que no fueron desarrolladores de primera línea o evaluadores independientes según tolerancia. Incluye conocimiento de ventas, datos, seguridad, privacidad, accesibilidad, operación y personas afectadas según el recorrido. Independencia sin contexto puede aplicar pruebas irrelevantes; contexto sin capacidad de objeción puede convertirse en autoaprobación. Registra competencia, conflicto, autoridad, suplencia y recursos. Una matriz RACI no demuestra capacidad real. Conecta evidencia vencida y fallas con decisiones diferentes. Evidencia vencida no prueba que el control falló; indica que la afirmación ya no está sustentada con el nivel acordado. Decide revalidar, limitar, compensar o aceptar temporalmente con autoridad. No marques aprobado porque no hubo incidentes. Una prueba fallida abre triage: confirma criterio, condición, versión, alcance y riesgo; contiene cuando sea necesario; investiga causa; corrige; repite el original y variantes; y observa operación. Conserva la falla como regresión. Una excepción mantiene el requisito y autoriza un desvío limitado. Un incidente coordina impacto activo. El programa los vincula, pero no sustituye sus procesos ni sus vencimientos. Termina cada ciclo con una decisión, no con un reporte. La vista debe responder qué está vigente, qué cambió, qué evidencia falta, qué supera tolerancia, qué control se degrada y qué decisión vence. Evita una puntuación compuesta donde disponibilidad o adopción compensen una falla de acceso. Utiliza estados claros: continuar, continuar con acciones, ampliar evidencia, limitar, pausar, revertir, aceptar residual por un periodo, escalar o retirar. Registra unidad, versión, criterio, evidencia, incertidumbre, condiciones, dueño, fecha y autoridad. Mide cobertura por riesgo, edad de evidencia, pruebas vencidas, tiempo de revalidación, fallas, reincidencia, excepciones, cambios sin evaluar y decisiones atrasadas. Interpreta la calidad de la evidencia, no solo su cantidad. En Cerravi, asegura afirmaciones verificables. Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Comprueba esa frontera en interfaz, API, exportación e integraciones y reábrela si la empresa añade automatización. Las propuestas utilizan productos y precios del catálogo cargado. Si falta un importe, se muestra para revisión; Cerravi no lo inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. Prueba fuente, versión, faltante, contradicción y destino compartido con datos controlados. La actividad de Buyer Room es una señal, no identidad, aceptación, contrato, pago o intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. El programa aporta una vista fechada; no certifica Cerravi, a la empresa ni todo uso futuro.

Un dashboard de gobernanza de un AI Sales Copilot reduce el tiempo entre una señal y una decisión. No es un medidor universal de confianza, un expediente completo ni una certificación. Su trabajo es mostrar qué ocurre, qué cambió, qué afirmaciones siguen sustentadas, qué evidencia falta y quién debe actuar. Evita una puntuación única como ochenta y siete por ciento seguro. Disponibilidad, calidad, acceso, adopción, impacto y vigencia responden preguntas distintas. Promediarlas permite que un dato favorable esconda una falla crítica. Mantén dimensiones separadas, reglas de estado explícitas y acceso al detalle. El NIST AI Risk Management Framework organiza resultados voluntarios en Govern, Map, Measure y Manage. Puede ayudar a ordenar cobertura y conversación, pero no prescribe este tablero ni demuestra cumplimiento. Empieza por audiencias y decisiones, no por gráficas. Operación necesita saber si debe investigar o contener. Producto decide si una versión puede ampliar su alcance. Negocio evalúa beneficios, residual y carga humana. Seguridad, privacidad, datos y riesgo revisan condiciones dentro de su autoridad. Dirección necesita excepciones materiales, tendencias y decisiones vencidas, no cada evento técnico. Para cada vista registra pregunta, frecuencia, detalle, latencia aceptable, acción y escalamiento. Una vista diaria puede mostrar alertas y controles críticos; una revisión mensual, cambios, evidencia y acciones; un comité periódico, riesgo residual y continuidad. Define quién opera, quién responde finalmente, quién suple y quién puede limitar, pausar, aceptar o retirar. Ver una alerta no concede autoridad para resolverla. Fija identidad y alcance en la cabecera. Muestra organización, caso de uso, estado, versión de aplicación, modelo, configuración, fuentes, herramientas, entorno, región, cohorte y periodo. No combines propuestas, resumen de oportunidades y automatización externa como si fueran la misma unidad. Incluye hora de actualización, zona horaria, calidad de carga y huecos conocidos. Un tablero actualizado hace diez minutos con una fuente detenida desde ayer no está al día. Separa tiempo de extracción, periodo medido y fecha de la evidencia. Mantén filtros visibles por versión, rol, moneda, canal, región, equipo y fuente. Cuando un filtro reduce la población, indícalo. Una captura parcial no debe circular como estado general del sistema. Organiza cinco capas. Operación y comportamiento cubre disponibilidad, errores, latencia, uso, correcciones y fallback. Riesgo y eventos reúne incidentes, hallazgos, quejas, accesos anómalos y señales emergentes. Controles y evidencia muestra cobertura, última prueba, vigencia, fallas y dependencias. Cambio y exposición identifica versiones, prompts, fuentes, permisos, herramientas, proveedores, población y autonomía modificados. Decisiones y acciones reúne excepciones, residual, mitigaciones, responsables, fechas, bloqueos y cierre. Conecta las capas. Una degradación puede pertenecer a una versión, afectar una afirmación, abrir un hallazgo y condicionar una decisión. No la cuentes cuatro veces como cuatro riesgos, pero tampoco ocultes su relación. Telemetría muestra estado y tendencia; una prueba aporta evidencia bajo condiciones; feedback aporta contexto; una decisión registra autoridad y condiciones. Ninguna pieza lo demuestra todo. Define cada métrica como un contrato. Registra nombre, pregunta, definición, fórmula, unidad, fuente, población, numerador, denominador, exclusiones, ventana, segmentos, actualización, dueño, umbral, acción y limitación. Usa denominadores. Cinco correcciones entre diez sugerencias y cinco entre diez mil no describen lo mismo. Distingue usuarios elegibles, activos, sesiones, ejecuciones, salidas visibles, borradores guardados y objetos compartidos. Una apertura de Buyer Room no equivale a una persona identificada ni a una decisión de compra. Muestra incertidumbre y calidad de datos: población no observada, registros tardíos, duplicados, cobertura de logging y cambios de definición. Cuando no puedas calcular, muestra no disponible con causa. No sustituyas cero ni arrastres un valor antiguo sin advertencia. Usa estados explícitos: vigente, atención, fuera de tolerancia, sin evidencia, no aplicable justificado y datos no disponibles. Cada uno necesita regla, prioridad y acción. Separa salud de la señal y salud del control. Un pipeline de datos roto no prueba que el control falló, pero impide sostener una conclusión. No permitas compensación entre dominios. Un acceso indebido no se vuelve aceptable por alta disponibilidad. Define precedencia para aislamiento, precios, permisos, envío externo, datos y proceso manual. El color siempre acompaña texto, icono y explicación. Verde significa una condición concreta dentro de un periodo, no confianza general. Amarillo no debe durar para siempre. Rojo requiere responsable y respuesta. Gris distingue algo no medido de algo realmente no aplicable. Muestra cobertura y frescura de evidencia. Para cada afirmación registra última prueba, versión, población, método, resultado, vigencia, limitación y artefacto. Agrega cobertura por riesgo y recorrido, no solo porcentaje de controles. Diez comprobaciones de formato no compensan una autorización crítica sin probar. Separa evidencia vigente, próxima a vencer, vencida, insuficiente y ausente. Una evidencia vencida no demuestra falla, pero deja la afirmación sin sustento acordado. La respuesta puede ser revalidar, limitar, aplicar un compensatorio o aceptar temporalmente con autoridad y fecha. NIST AI RMF Measure recomienda seleccionar métricas desde los riesgos relevantes, documentar lo que no puede medirse y revisar métricas y controles cuando cambian entorno y sistema. El tablero debe revelar ausencias, no fabricar precisión. Convierte umbrales en rutas de respuesta. Defínelos antes de observar resultados y relaciónalos con impacto, tolerancia y capacidad. Distingue aviso, investigación, degradación, hallazgo e incidente. Un evento único de alta consecuencia puede exigir contención; una tendencia leve puede justificar análisis sin pausa. Cada alerta necesita señal, criterio, versión, población, hora, evidencia, responsable, plazo, canal, escalamiento y cierre. Deduplica eventos y limita notificaciones repetidas. Una alerta sin capacidad de atención no es control eficaz. Prueba el recorrido completo con una señal controlada: ingestión, estado, notificación, triage, decisión y cierre. Mide tiempos cuando aporten valor, pero no optimices solo velocidad. Una resolución rápida y equivocada puede aumentar el impacto. Cada tarjeta debe abrir un drilldown que reconstruya la conclusión. Incluye definición, tendencia, segmentos, eventos, cambios, pruebas, hallazgos, excepciones, acciones y decisiones relacionadas. El usuario debe explicar el estado sin exportar cinco hojas. Conserva trazabilidad hasta el registro fuente sin duplicar evidencia sensible. Usa identificadores, enlaces con acceso, hashes, versiones y custodios. Registra quién cambió definición, umbral o estado y por qué. Una captura del dashboard no sustituye el artefacto original. Permite comparar línea base, candidata y activa. Marca cambios de fórmula, dataset, evaluador o instrumentación. Si cambia el método, interrumpe la serie o muestra la limitación. No dibujes una tendencia continua con mediciones incompatibles. Reduce vigilancia, acceso y retención. El dashboard gobierna un sistema, no califica personas. Evita rankings de vendedores, lectura masiva de conversaciones y métricas individuales sin necesidad definida. Agrega cuando sea posible y reserva detalle para funciones autorizadas. Minimiza campos, redacta datos personales y secretos, aplica acceso por rol, registra consultas y fija retención. Separa telemetría operativa de evidencia restringida. Dirección no necesita prompts completos, nombres de clientes o conversaciones para comprender una tendencia. Documenta finalidad y usos prohibidos. Un registro creado para investigar calidad no debe convertirse silenciosamente en evaluación laboral. Incluye un canal de corrección cuando una persona detecta una atribución equivocada. Integra el tablero en ritmos de gobierno. Tiempo real sirve a operación; un resumen semanal revisa anomalías y acciones; una sesión mensual examina cambios, cobertura, evidencia y excepciones; una revisión periódica decide continuidad, alcance o retiro. Ajusta frecuencia al riesgo y añade sesiones por evento material. Distribuye un paquete corto antes y usa la reunión para discrepancias y decisiones. Separa hechos, inferencias, preguntas y propuestas. Cada acción conserva resultado esperado, dueño, fecha y criterio de cierre. Cada decisión mantiene autoridad, residual, condiciones y vencimiento. Mide también fuentes atrasadas, alertas sin dueño, acciones vencidas, excepciones renovadas, controles sin prueba y tiempo de revalidación. Un tablero bonito que no cambia decisiones es inventario visual, no gobernanza. Evita falsa seguridad. No uses un AI risk score único, conteos sin denominador, promedios sin segmentos, semáforos sin fecha, incidentes como única señal ni ausencia de quejas como prueba de calidad. No marques no aplicable cuando falta evidencia y no mantengas verde un control cuya versión cambió. No mezcles desarrollo, prueba y producción; datos reales y sintéticos; modelos; proveedores; monedas; eventos, hallazgos y acciones. No premies reducir reportes o cerrar tickets rápido: esos incentivos pueden ocultar problemas. El marco de accountability de GAO organiza prácticas en gobernanza, datos, desempeño y monitoreo y ofrece preguntas para evaluación. Puede inspirar cobertura, pero no certifica Cerravi ni obliga a una empresa mexicana a adoptar esta implementación. En Cerravi, representa fronteras reales. Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. El tablero puede mostrar correcciones y límites, pero no debe insinuar autonomía inexistente. Las propuestas usan productos y precios del catálogo cargado. Si falta un importe, se muestra para revisión y no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. Conserva fuente, versión, moneda y faltantes. La actividad de una Buyer Room aporta contexto, pero no confirma identidad, aceptación, contrato, pago o intención. Forecast usa reglas transparentes del CRM; no es un modelo entrenado o calibrado y no garantiza cierres. El dashboard explica señales, evidencia y límites para decidir. No predice ventas, no certifica el sistema y no declara cumplimiento general.

Un sistema de métricas para un AI Sales Copilot debe ayudar a decidir, no llenar una pantalla. Separa tres preguntas. Un KPI muestra si el sistema y el proceso avanzan hacia un objetivo definido: tiempo, trabajo completado, calidad aceptada o resultado observado. Un KRI señala exposición, deterioro o cercanía a una tolerancia: precios sin fuente, evidencia vencida, accesos anómalos o cambios sin evaluar. Un indicador de control muestra si un mecanismo preventivo, detectivo o correctivo se ejecuta y produce el resultado esperado. La misma cifra puede cambiar de función según la decisión. Una tasa de correcciones puede orientar producto, advertir un riesgo o formar parte de una prueba de revisión humana. Documenta la pregunta. No clasifiques por el nombre. Y evita un score único de confianza: velocidad, adopción, calidad, acceso, privacidad y evidencia no son intercambiables. Un promedio favorable puede ocultar una falla crítica. Empieza por decisiones, objetivos y escenarios de riesgo. Operación puede investigar una degradación; producto, detener un rollout; ventas, cambiar el flujo; seguridad o privacidad, contener una exposición; dirección, aceptar residual o reducir alcance. Una métrica que no cambia ninguna decisión suele convertirse en decoración. Para cada caso escribe objetivo, usuario, objeto, entrada, salida, efecto permitido y límites. Un copiloto que redacta una propuesta, resume una oportunidad y sugiere un siguiente paso necesita indicadores distintos. No combines recorridos, versiones, regiones o monedas para conseguir una cifra ejecutiva. NIST AI RMF propone seleccionar métodos y métricas desde los riesgos identificados y el contexto. También pide documentar lo que no puede medirse. Esa ausencia se atiende con evaluación cualitativa, prueba, restricción, control compensatorio o decisión explícita; no con precisión inventada. Convierte cada indicador en un contrato reproducible. Registra pregunta, definición, fórmula, unidad, fuente, población, numerador, denominador, exclusiones, ventana, zona horaria, segmentos, frecuencia, latencia, dueño, umbral, respuesta y limitación. Conserva versión y fecha efectiva de la definición. Usa denominadores. Diez correcciones entre veinte borradores visibles no significan lo mismo que diez entre veinte mil. Distingue usuarios elegibles, usuarios activos, sesiones, ejecuciones, salidas presentadas, borradores guardados, propuestas compartidas y oportunidades cerradas. Define estados para cero, no disponible, sin población, dato tardío, fuente incompleta y no aplicable justificado. Cero incidentes confirmados no equivale a cero riesgo: también puede reflejar poca actividad o detección deficiente. Si una fuente se detiene, muestra el hueco y la última cobertura válida. No arrastres el valor anterior como si siguiera vigente. Mide utilidad y eficiencia sin prometer causalidad comercial. Puedes observar tiempo hasta un primer borrador revisable, tareas completadas, abandono, reutilización y trabajo manual restante. Define inicio y fin. Tiempo hasta borrador no es tiempo ahorrado si la revisión posterior aumenta. Una salida generada no es una tarea completada si nadie la utiliza. Para calidad, observa aceptación con cambios, correcciones por tipo, rechazo, completitud y revisión dentro del plazo. Interpreta aprobación con cuidado: una tasa alta puede indicar calidad o revisión superficial. Combina comportamiento con una muestra evaluada y feedback contextual. Win rate, ciclo, ticket y conversión pertenecen al sistema comercial completo. Segmenta por mercado, canal, etapa, cohorte y tipo de cuenta; compara una línea base y registra cambios paralelos. La asociación entre uso del copiloto y cierre no demuestra que el copiloto causó el resultado. Diseña KRI desde escenarios concretos de daño. Cada indicador necesita una cadena comprensible: escenario, condición observable, fuente, ventana, tolerancia y respuesta. En propuestas, la exposición puede ser una partida sin precio que llega a una salida compartible. En acceso, una consulta intenta cruzar el límite de un espacio. En herramientas, una acción usa parámetros o permisos fuera del esquema autorizado. Distingue señales adelantadas y rezagadas. Cambios sin evaluar, catálogos vencidos, aumento de faltantes, evidencia próxima a vencer o revisores saturados pueden anticipar exposición. Incidentes confirmados, quejas validadas o propuestas corregidas después de compartir son rezagados. Ninguno predice con certeza un daño futuro. Segmenta por consecuencia y superficie. Una incidencia crítica única puede exigir contención aunque su tasa sea pequeña. Muchos errores cosméticos no equivalen a una fuga entre clientes. Controla grounding, precios, monedas y afirmaciones. Para fuentes registra cobertura, edad, referencias recuperadas, conflictos y salidas sin soporte dentro de una muestra definida. La similitud textual no convierte una frase en verdad. Comprueba si la fuente era autorizada, vigente y suficiente para la afirmación presentada. Para precios separa partidas con importe válido, partidas sin importe, moneda ambigua, catálogo vencido, descuento fuera de autoridad y conflicto entre fuentes. Un indicador crítico es la tasa de escapes: objetos compartibles con valor no sustentado entre todos los objetos revisados bajo esa regla. La meta puede ser cero, pero la operación necesita especificar detección, bloqueo, investigación y cierre. Mantén MXN, USD y otras monedas separadas salvo conversión aprobada con fuente y hora. Nunca transformes un faltante en cero. Mide supervisión humana como capacidad, no como un clic. Una revisión efectiva ocurre antes del efecto, llega a la persona adecuada, presenta contexto suficiente y permite editar, rechazar o escalar. Observa cobertura, tiempo disponible, correcciones materiales, rechazos, escalaciones, backlog y casos fuera de plazo. La tasa de override no es calidad por sí sola. Puede subir porque el sistema empeoró, porque el equipo aprendió a revisar o porque cambió la política. Una tasa casi nula puede reflejar precisión o automatismo. Compleméntala con muestras, entrevistas, casos de límite y resultados posteriores. Incluye capacidad. Una aprobación puede existir y fallar si el volumen supera al equipo, falta suplencia o el revisor no ve fuente y moneda. Define un KRI de saturación y una respuesta concreta: reducir alcance, priorizar riesgos, activar respaldo o pasar temporalmente al proceso manual. Separa presencia, operación y eficacia de controles. Un control configurado no está necesariamente operativo; uno operativo no es necesariamente eficaz. Registra cobertura esperada, ejecuciones observadas, fallas, bypass, alertas entregadas, triage, contención, recuperación y retest. La cobertura técnica debe reconciliarse con la población del proceso. Define indicadores preventivos, detectivos y correctivos. Un validador bloquea un precio ausente; un monitor detecta una ruta que lo omitió; un runbook restaura el proceso manual. Evalúalos por separado. Una alerta producida pero no atendida no demuestra respuesta. Mide dependencias como logging, cola, catálogo, identidad, proveedor, canal de notificación y personal disponible. Si una dependencia común falla, varios controles pueden perder evidencia a la vez. Relaciona la causa y evita contarla como riesgos desconectados. Fija líneas base, tolerancias y respuestas antes de mirar el resultado. Una línea base describe comportamiento observado bajo versión, población y periodo; no define por sí sola lo aceptable. La tolerancia proviene del impacto, obligaciones aplicables, apetito de riesgo y capacidad de respuesta. Usa bandas como observar, investigar, limitar y detener solo si cada una tiene criterio, responsable y autoridad. No copies porcentajes de otra empresa. El mismo uno por ciento puede ser tolerable en formato e inaceptable en aislamiento o precio. Para alta consecuencia usa reglas de evento único; para deterioro gradual, tendencia, volumen mínimo y persistencia. Prueba la alerta de extremo a extremo con una señal autorizada: cálculo, estado, notificación, triage, decisión, recuperación y cierre. Reducir ruido nunca debe ocultar eventos críticos. Publica la calidad del dato junto con la métrica. Cada valor necesita cobertura, frescura, retraso, duplicados, descartes y cambios de instrumentación. Una cifra puntual puede parecer exacta mientras deja fuera la ruta más importante. Muestra qué parte de la población fue observable y por qué falta el resto. Versiona fórmulas, taxonomías y fuentes. Si cambia la definición de corrección material, el evaluador o el registro de eventos, marca una ruptura de serie. No presentes mejora histórica cuando comparas métodos incompatibles. Conserva la definición anterior y un puente de reconciliación cuando sea posible. Controla acceso y retención. Agrega por equipo o recorrido cuando el detalle individual no sea necesario. La telemetría de calidad no debe convertirse silenciosamente en vigilancia de vendedores. Conversaciones, prompts y datos de clientes requieren finalidad, permisos, minimización y conservación definida. Asigna dueño de definición, custodio de datos, operador del control y autoridad de decisión. En un equipo pequeño una persona puede ocupar más de un rol, pero la responsabilidad debe verse. Incluye suplencia y escalamiento. Revisa operación y alertas críticas con la frecuencia que exige su impacto; tendencias y capacidad, semanalmente; definiciones, evidencia y trade-offs, mensualmente o tras un cambio material. Una revisión periódica decide continuidad, ampliación, limitación o retiro. Retira métricas que no cambian decisiones, se duplican, inducen conducta adversa o ya no representan el sistema. Conserva la razón y su sustituto. NIST AI RMF Measure indica que la adecuación de métricas y la eficacia de controles deben reevaluarse cuando cambian el contexto, los datos y el sistema. Una métrica también envejece. Evita métricas vanidosas y objetivos fáciles de manipular. Prompts enviados, textos generados, sesiones abiertas o tarjetas vistas no demuestran valor. Tampoco uses promedios sin distribución, conteos sin denominador, semáforos sin periodo ni crecimiento de uso como prueba de seguridad. Anticipa la conducta que incentiva cada objetivo. Premiar menos correcciones puede reducir reportes; premiar tiempo de respuesta puede producir cierres superficiales; premiar adopción puede empujar usos no adecuados. Equilibra resultado, calidad, riesgo y control, y conserva un canal para impugnar una clasificación incorrecta. NIST y GAO ayudan a formular preguntas y organizar evidencia, pero no certifican este catálogo ni crean requisitos para una empresa mexicana. Una métrica interna no demuestra cumplimiento, ausencia de daño ni impacto causal en ventas. En Cerravi, aplica los indicadores a fronteras reales. Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Mide utilidad de sugerencias y calidad de revisión sin atribuir acciones que el producto no ejecuta. Las propuestas usan productos y precios del catálogo cargado. Si falta un importe, se muestra para revisión y no se inventa. Observa partidas válidas, faltantes, moneda y correcciones, conservando catálogo, versión y denominador. La actividad de Buyer Room aporta contexto, pero no confirma identidad, lectura humana, aceptación, contrato, pago o intención. Forecast utiliza reglas transparentes del CRM; no es un modelo entrenado o calibrado y no garantiza cierres. KPI, KRI e indicadores de control ayudan a decidir dentro de estos límites. No convierten señales en hechos, un dashboard en certificación ni correlación en causalidad.

Un informe ejecutivo de gobernanza de un AI Sales Copilot existe para decidir, no para tranquilizar. Explica qué cambió, qué valor se observa, qué riesgo supera o se acerca a la tolerancia, qué control perdió sustento y qué autoridad debe resolver. No reproduce toda la operación ni busca un semáforo favorable. Separa el informe del dashboard. El dashboard ofrece señales, filtros y drilldowns continuos; el informe fija un corte, una narrativa y asuntos materiales para una audiencia concreta. También se distingue de una auditoría: puede reunir evidencia revisada, pero no crea independencia, criterio formal ni una opinión de aseguramiento. Evita frases como la IA está bajo control o el sistema es seguro. Sustitúyelas por afirmaciones acotadas a un caso, versión, población, periodo y control. Si después de leer el paquete nadie sabe qué decidir, quién decide y cuándo vence, no es un instrumento de gobierno. Define audiencia, mandato, frecuencia y confidencialidad. Aclara si el destinatario es dirección general, comité de riesgo, comité de tecnología, consejo de administración o una combinación. Cada órgano tiene atribuciones distintas. Dirección asigna capacidad y cambia operación; un comité recomienda o aprueba dentro de su mandato; el consejo supervisa y cuestiona sin asumir automáticamente la ejecución diaria. Documenta propósito, decisiones incluidas, umbrales de escalamiento, frecuencia, eventos extraordinarios, responsable del paquete, funciones consultadas y autoridad final. Un reporte mensual puede cubrir tendencias y acciones; uno trimestral, portafolio y tolerancia; un evento material puede exigir comunicación inmediata. Clasifica el contenido. La versión ejecutiva no necesita credenciales, conversaciones completas, datos personales o prompts. Usa identificadores y enlaces con acceso para evidencia restringida. Define distribución, retención, custodia y corrección. Abre con una página ejecutiva que pueda leerse sola. Identifica organización, cartera o caso, periodo, versión y fecha de corte. Resume decisiones requeridas, cambios materiales, beneficio observado, riesgos fuera o cerca de tolerancia, incidentes relevantes, controles críticos sin evidencia vigente y acciones vencidas. Incluye de tres a cinco asuntos prioritarios, cada uno con estado textual, consecuencia, tendencia, responsable, fecha y solicitud. Si algo sigue en investigación, dilo. Si el dato es parcial, no completes el hueco con el valor anterior. Distingue hecho, inferencia y recomendación. Hecho: una fuente dejó de registrar una ruta durante cuatro horas. Inferencia: la cobertura del indicador puede estar incompleta. Recomendación: limitar la expansión hasta reconciliar el universo. Esta separación impide que una opinión se presente como evento confirmado. Muestra alcance, inventario y cambios materiales. Registra caso de uso, estado, dueño, usuarios, población afectada, entorno, región, modelo, instrucciones, datos, fuentes, herramientas, permisos, integraciones y puntos de revisión humana. Separa recorridos activos, limitados, experimentales, pausados y retirados. Resume altas, bajas y cambios desde el corte anterior: modelo o proveedor, prompts, fuentes, permisos, herramientas, autonomía, audiencia, volumen, geografía, retención y proceso comercial. Indica si cada cambio fue evaluado, probado, aprobado y monitoreado. Un cambio pequeño en código puede alterar una consecuencia material. Reconcilia inventario con producción. Señala integraciones laterales, cuentas compartidas o usos fuera del recorrido autorizado sin castigar el reporte. Clasifica la diferencia, contiene cuando corresponda y abre una decisión. No cambies retrospectivamente la línea base para que una desviación desaparezca. Explica valor observado sin atribución automática. Relaciona cada beneficio con el objetivo aprobado. Puede tratarse de tiempo hasta borrador revisable, completitud, menor retrabajo, adopción elegible o un resultado CRM segmentado. Conserva definición, fuente, periodo, denominador, línea base y población. Actividad generada no equivale a valor realizado. Muestra también costo y carga: operación, revisión humana, soporte, evaluación, incidencias, proveedores, remediación y deuda de controles. Un flujo más rápido puede trasladar trabajo a revisión o aumentar correcciones. Dirección necesita beneficio neto y capacidad necesaria para sostenerlo, no solo volumen de uso. No atribuyas win rate, ciclo, ticket o ingresos al copiloto sin un diseño de evaluación adecuado. Presenta asociaciones como observadas, registra otros cambios y declara incertidumbre. Si falta evidencia, muestra la pregunta y el plan de medición, no una promesa de retorno. Presenta riesgos como escenarios materiales frente a la tolerancia. Describe condición, evento, personas u objetos afectados, alcance, controles, exposición actual, incertidumbre y residual. Relaciona cada riesgo con la tolerancia aprobada y la decisión disponible. No uses un score único para compensar dimensiones. Adopción alta o disponibilidad estable no reducen por sí solas una exposición de acceso, privacidad, precio o autorización. Para condiciones críticas conserva reglas de caso único; para deterioro gradual, tendencia, volumen mínimo y persistencia. NIST AI RMF no prescribe la tolerancia. La organización la define según objetivos, impacto, obligaciones y contexto, y puede cambiar con el tiempo. El informe muestra quién la aprobó, cuándo se revisó, qué supuestos contiene y dónde falta una definición suficiente. Tampoco presenta el marco como certificación o mandato local. Resume controles críticos y vigencia de evidencia. Para cada riesgo prioritario muestra control, dueño, cobertura, última prueba, resultado, vigencia, dependencia y limitación. Separa diseñado, implementado, operativo y eficaz. Una política publicada o una configuración visible no demuestran que el control funcionó durante el periodo. Destaca controles fallidos, parcialmente eficaces, no probados, con evidencia vencida o dependencias degradadas. Una evidencia vencida no confirma una falla, pero deja la afirmación sin sustento vigente. Explica si la respuesta es revalidar, limitar, compensar, aceptar temporalmente o detener. No conviertas cobertura en porcentaje sin contexto. Diez pruebas de formato no compensan una autorización crítica sin validar. Muestra cobertura por escenario, ruta, versión y población, junto con asuntos que no pueden medirse o cuya evidencia sigue incompleta. Consolida incidentes, hallazgos, excepciones y terceros. Resume incidentes por impacto, alcance, versión, estado, contención, recuperación y aprendizaje. Distingue reporte, anomalía, hallazgo e incidente. La ausencia de incidentes confirmados no demuestra ausencia de riesgo; revisa adopción, detección y accesibilidad del canal. Agrupa hallazgos por causa y control, no solo por ticket. Muestra reincidencia, acciones vencidas, retests fallidos y residual aceptado. Para excepciones incluye requisito desviado, alcance, compensatorios, autoridad, vencimiento y cierre. Renovaciones repetidas pueden revelar una política inviable o deuda estructural. Para terceros presenta cambios materiales, evidencia vigente, concentración, incidentes, subprocesadores, dependencia, contingencia y salida. Distingue lo confirmado por evidencia, lo declarado por el proveedor y lo que aún no puede verificarse. La responsabilidad no se transfiere con el contrato. Incluye personas, datos y supervisión significativa. Explica quién recibe beneficio y quién absorbe errores, demora, vigilancia o trabajo adicional. Resume feedback, quejas validadas, capacidad de impugnación y diferencias por rol, equipo, región o población. Evita conclusiones generales cuando la muestra no representa a todas las personas afectadas. Para datos, muestra categorías, finalidad, acceso, retención, transferencias, incidentes y cambios. La portada usa agregación y minimización; el anexo restringido conserva detalle solo cuando es necesario. No copies nombres, prompts o conversaciones para hacer el reporte más convincente. Mide supervisión como capacidad antes del efecto: cobertura, contexto, autoridad, tiempo, backlog, suplencia, correcciones y escalaciones. Un botón o una tasa alta de aceptación no demuestran revisión significativa. Si la carga supera la capacidad, presenta la exposición y una decisión para reducirla. Formula cada solicitud con opciones y consecuencias. Cada asunto termina en una pregunta que la audiencia puede resolver. Ofrece alternativas reales: continuar, ampliar, corregir, limitar, pausar, aceptar residual, financiar capacidad, cambiar proveedor o retirar. Para cada opción muestra beneficio, riesgo, costo, dependencia, reversibilidad y consecuencia de no decidir. Identifica recomendación y responsable, pero no escondas alternativas o disenso. Registra funciones consultadas, evidencia pendiente y conflictos de interés. Si la autoridad no está presente, el resultado es recomendación o escalamiento, no aprobación implícita. Fija fecha límite, condiciones, residual, próxima revisión y disparadores de reapertura. Una decisión de continuar solo cubre el caso, versión, población y periodo examinados. Un cambio material, incidente o evidencia contraria puede reabrirla antes. Conserva un anexo que reconstruya cada afirmación. Incluye inventario, definiciones de KPI y KRI, fórmulas, poblaciones, fuentes, calidad del dato, registro de cambios, riesgos, controles, pruebas, incidentes, hallazgos, excepciones, acciones y decisiones anteriores. Usa identificadores estables y enlaces con control de acceso. Cada frase ejecutiva abre el detalle que la sostiene. Una tendencia abre segmentos y cambios de método; un control abre población, muestra y resultado; un riesgo abre eventos, evidencia y residual. Una captura o PDF no sustituye el artefacto original ni su custodia. Marca procedencia, versión, fecha, autor, revisor e integridad. Si aparece un error material, corrige de forma versionada; no sobrescribas silenciosamente el paquete utilizado para decidir. Conserva qué se sabía en ese momento y cómo cambió la conclusión. Usa la reunión para cuestionar y resolver. Distribuye el paquete con tiempo y destaca preguntas abiertas. Empieza por decisiones, cambios materiales y evidencia contraria a supuestos previos. Evita leer el documento en voz alta. Las áreas técnicas explican el detalle, pero la conversación permanece en consecuencias, tolerancia y recursos. Registra preguntas, disensos, recusaciones, decisiones, condiciones, responsables y fechas. Diferencia resolución, recomendación, solicitud de evidencia y asunto fuera del mandato. Una acción termina con resultado verificable y criterio de cierre, no con preparar más información sin propósito. Después actualiza registro de decisiones, riesgos, acciones y calendario. Comunica a quienes operan el sistema lo necesario para ejecutar. Mide asuntos repetidos, acciones vencidas, decisiones reabiertas, paquetes tardíos y métricas que nunca cambian una resolución. En Cerravi, el informe conserva límites verificables. Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Las propuestas usan productos y precios del catálogo cargado. Si falta un importe, se muestra para revisión y no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. La actividad de Buyer Room aporta contexto, pero no confirma identidad, lectura humana, aceptación, contrato, pago o intención. Forecast usa reglas transparentes del CRM; no es un modelo entrenado o calibrado y no garantiza cierres. El informe explica señales, cobertura, incertidumbre y decisiones dentro de esas fronteras. No convierte una visita en intención, una asociación en causalidad, un marco en sello, un paquete interno en auditoría ni un semáforo en confianza general.

Un modelo operativo de gobernanza de inteligencia artificial convierte principios y políticas en trabajo cotidiano. Explica quién registra un caso, quién lo clasifica, quién aporta evidencia, quién decide, quién opera controles y quién responde cuando cambia una condición. El comité es solo una pieza. El trabajo real ocurre en negocio, producto, tecnología, datos, seguridad, privacidad, compras, soporte y operación. Un órgano transversal alinea criterios, resuelve conflictos y trata asuntos que exceden la autoridad de un equipo; no debe revisar cada prompt ni administrar el sistema. NIST describe Govern como una función continua que conecta liderazgo, tolerancia, roles, inventario, terceros y revisión durante todo el ciclo de vida. No prescribe un organigrama universal. La prueba del modelo es sencilla: ante un caso real, cualquier persona debe saber qué ruta sigue, qué evidencia necesita, quién decide y qué ocurre si nadie responde a tiempo. Empieza con una carta de mandato antes de nombrar integrantes. Define el propósito: habilitar usos legítimos, mantener riesgos dentro de tolerancia y conservar una ruta para corregir, limitar, pausar o retirar. Delimita desarrollos propios, funciones compradas, pilotos, automatizaciones, modelos, datos, herramientas e integraciones. Especifica decisiones incluidas y excluidas. El comité puede resolver casos materiales, aceptar residual dentro de facultades delegadas, aprobar excepciones o escalar. No interpreta por sí solo todas las obligaciones, no concede presupuesto que no controla y no reemplaza al dueño de datos. Registra patrocinador, presidencia, secretaría, suplencias, quorum, recusación, confidencialidad, frecuencia, tiempos de respuesta y revisión del mandato. Supervisar toda la IA no es una frontera operable. Cada autoridad necesita una decisión verificable y un límite. Separa cuatro capas. Dirección fija objetivos, tolerancia, recursos y límites de autoridad. La función de gobierno mantiene estándares, taxonomía, inventario, rutas, plantillas, asesoría y visión de portafolio. Los equipos de entrega diseñan, evalúan y documentan cada caso; el dueño de proceso responde por propósito y uso. Operación monitorea, atiende feedback, incidentes, cambios, continuidad y retiro. Una revisión independiente puede ser necesaria en asuntos materiales, pero independencia no significa desconocer el sistema. Necesita criterio, acceso y competencia. Seguridad, privacidad o legal tampoco se vuelven dueños de todo el producto. Cada función responde dentro de su especialidad y una autoridad identificada toma la resolución final. Así se evita que el comité sea responsable en apariencia mientras ninguna persona puede actuar. Elige entre una estructura central, federada o híbrida. Un modelo central concentra estándares y decisiones en una función común. Puede ayudar cuando el portafolio es pequeño o existen pocos especialistas, pero corre el riesgo de crear una fila única. Un modelo federado delega decisiones a unidades o dominios. Acerca la autoridad al proceso, aunque necesita capacitación, límites, evidencia compatible y una vista de exposición agregada. Delegar sin estándares no es federar: es fragmentar. En un modelo híbrido, la organización centraliza taxonomía, prohibiciones, umbrales, herramientas comunes y asuntos de mayor impacto, mientras distribuye evaluación y operación ordinarias. Microsoft presenta estándares centrales con implementación distribuida como una forma de evitar caos y burocracia. Es una referencia de diseño, no una obligación ni prueba de eficacia. La delegación cambia cuando cambian volumen, riesgo o capacidad. Define derechos de decisión, no solo participantes. Enumera las resoluciones del ciclo de vida: aceptar una idea, autorizar datos, aprobar evaluación, lanzar piloto, pasar a producción, ampliar población, cambiar modelo o permisos, aceptar residual, conceder excepción, pausar, reanudar y retirar. Para cada una registra quién prepara, recomienda, consulta, decide, ejecuta y verifica. La matriz RACI ayuda, pero agrega nivel de riesgo permitido, evidencia obligatoria, plazo, suplencia y condición de escalamiento. Una función accountable necesita autoridad real, acceso a información y capacidad para decir no o imponer condiciones. Evita la aprobación por silencio y el consenso ficticio. Si el comité recomienda y dirección decide, el acta debe distinguirlo. Conserva el disenso material y los conflictos de interés; una decisión colectiva no borra responsabilidades individuales. Crea una entrada única y rutas proporcionales al riesgo. El intake captura problema, objetivo, dueño, usuarios, personas afectadas, datos, modelo, proveedor, acciones, autoridad, entorno, región, volumen, reversibilidad y beneficio esperado. Pide lo necesario para clasificar, no un expediente completo antes de saber si el caso continuará. El triage distingue una consulta, experimento aislado, cambio estándar, caso nuevo, excepción, hallazgo e incidente. Un recorrido interno, reversible y sin datos sensibles puede usar autoservicio con controles preaprobados. Un flujo externo, con dinero, acceso, decisiones materiales o baja reversibilidad necesita revisión adicional. Publica criterios y tiempos. Ofrece una ruta segura más estrecha cuando sea posible. No reduzcas el nivel para cumplir una fecha ni envíes cada duda al comité completo. Usa asesoría, revisión asíncrona y especialistas para evitar cuellos de botella. Convoca funciones por decisión, no por organigrama. Mantén un núcleo pequeño con presidencia autorizada, dueño de negocio, producto o tecnología, riesgo o control y secretaría. Invita datos, seguridad, privacidad, legal, compras, recursos humanos, accesibilidad, finanzas, soporte o representantes de usuarios cuando el asunto lo requiere. Una silla permanente sin decisiones relevantes agrega espera. Define competencias en proceso comercial, arquitectura, datos, evaluación, seguridad, impactos y operación. La diversidad útil incluye disciplina, experiencia, contexto regional y proximidad con personas afectadas, además de tiempo e influencia para cuestionar. Quien propuso o vendió una solución puede explicar, pero no debe ocultar alternativas ni ser la única voz que valida. Cuando falta una competencia material, limita la decisión, pide revisión especializada o escala. Diseña foros distintos para intake, decisiones, operación y dirección. La revisión de entrada distribuye casos y elimina bloqueos de información. El foro de decisión trata aprobaciones, residuales y excepciones. La revisión operativa observa cambios, controles, señales, acciones y capacidad. Dirección o consejo recibe asuntos materiales que no caben en la autoridad delegada. La frecuencia sigue volumen y riesgo: intake puede ser semanal; casos ordinarios, asíncronos; portafolio, mensual; y revisiones ejecutivas, cuando exista una decisión. Un incidente no espera el calendario. Fija paquete previo, agenda, tiempo por asunto y regla de salida. Una resolución puede aprobar, aprobar con condiciones, limitar, pedir evidencia, escalar, pausar o rechazar. Pendiente lleva dueño, fecha, restricción provisional y criterio de retorno; no significa que el tema desaparece. Integra los gates al trabajo que ya existe. Compras, seguridad, privacidad, arquitectura, datos y cambios suelen tener controles propios. Añade criterios de IA donde se decide propósito, proveedor, acceso, evaluación, producción, modificación y retiro. Vincula artefactos por identificador en lugar de copiar el mismo dato en varias plantillas. Cada gate responde una pregunta. Descubrimiento confirma dueño y uso; evaluación comprueba desempeño y riesgo; piloto valida operación limitada; producción confirma preparación; cambio analiza el delta; revisión periódica reabre supuestos; retiro verifica dependencias, acceso y continuidad. Aprobar un gate no autoriza versiones futuras. Automatiza comprobaciones estables como inventario, identidad, configuración, vigencia y presencia de pruebas. Conserva juicio humano para contexto, impacto, compensaciones y aceptación de riesgo. Da autoridad para contener sin esperar al comité completo. Nombra quién puede pausar una función, revocar acceso, limitar una población, volver al proceso manual o bloquear una integración ante condiciones definidas. La respuesta inicial protege personas y operación. La reanudación puede exigir pruebas, revisión y aceptación explícita. Documenta contacto, suplencia, severidad, canales, custodia de evidencia y tiempos. Practica escenarios: dato de otra cuenta, precio sin fuente, herramienta no autorizada, falla del proveedor, monitoreo ciego o revisión humana saturada. El ejercicio revela si la matriz funciona bajo presión. Registra decisiones, dependencias y mejoras. Una presentación del plan no demuestra capacidad de respuesta, y una reunión futura no debe retrasar una contención necesaria. Conserva paquetes de decisión y actas que puedan reconstruirse. El paquete identifica caso, versión, entorno, población, solicitud, opciones, beneficio, riesgo, controles, evidencia, incertidumbre, recomendación y asuntos abiertos. La secretaría verifica completitud y distribución, pero no modifica una conclusión técnica para facilitar aprobación. El acta registra participantes, recusaciones, preguntas materiales, evidencia considerada, disenso, resolución, alcance, condiciones, residual, responsable, fecha, cierre y disparadores de reapertura. Distingue aprobación, recomendación, consulta y solicitud de evidencia. Relaciona la resolución con inventario, riesgo, evaluación, excepción, cambio, incidente y acciones. Trazabilidad significa explicar qué se sabía y por qué se decidió, no almacenar conversaciones, prompts o datos personales sin límite. Mide si el gobierno decide bien y a tiempo. Observa volumen por ruta, tiempo hasta triage y decisión, devoluciones por información faltante, acciones vencidas, excepciones renovadas, decisiones reabiertas, incidentes repetidos, controles sin dueño y casos fuera del inventario. Segmenta por riesgo: un promedio puede esconder una espera crítica. Revisa si las condiciones se implementaron, si cambió el residual y si los asuntos vuelven por la misma causa. Una baja tasa de rechazo no prueba buen gobierno; puede reflejar buena preparación, criterios débiles o presión por aprobar. Compara demanda con capacidad y competencias. Si un especialista bloquea todo, crea patrones preaprobados, suplencia o delegación controlada. Una empresa pequeña puede empezar con patrocinador, dueño por caso, responsable técnico, asesoría bajo demanda, inventario, clasificación, RACI, registro de riesgos, plantilla de resolución y ruta de incidentes. En Cerravi, el dueño comercial define propósito, audiencia, proceso y resultado. Producto y tecnología mantienen configuración, integraciones y operación; datos autoriza fuentes; seguridad y privacidad revisan dentro de su alcance; y una autoridad identificada resuelve producción, excepciones, cambios materiales, pausa y retiro. Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Las propuestas utilizan productos y precios del catálogo cargado. Si falta un importe, se muestra para revisión y no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. La actividad de Buyer Room aporta contexto, pero no confirma identidad, aceptación, contrato, pago o intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. El comité gobierna decisiones de la organización; no convierte señales en hechos ni un marco voluntario en certificación o cumplimiento.

La comunicación durante un incidente de AI Sales Copilot no es una nota de prensa. Es una capacidad de respuesta: entrega información útil a quienes deben decidir, contener, operar o protegerse. El objetivo no es aparentar certeza. Es mantener una versión trazable de lo confirmado, evitar instrucciones contradictorias y permitir que cada audiencia actúe. NIST distingue coordinación de la respuesta, notificación formal, comunicación pública e intercambio técnico. Estos flujos no comparten el mismo detalle, autorización ni momento. Un mensaje interno para contener una función no debe copiarse sin revisión a clientes o a un canal público. Define primero qué activa el plan. No cualquier salida imperfecta es un incidente. Puede activarse por acceso indebido, exposición o pérdida de datos, una acción fuera del alcance, información comercial incorrecta compartida, indisponibilidad relevante o una dependencia comprometida. Clasifica por efecto, alcance, reversibilidad, propagación e incertidumbre. Una sugerencia descartada puede requerir registro interno; una propuesta enviada con un precio equivocado exige localizar destinatarios y corregir; una posible exposición entre organizaciones requiere contención y evaluación especializada. Escribe quién puede declarar, escalar, reducir y cerrar cada nivel. Mapea las audiencias antes de necesitar el plan. Incluye respuesta, dirección, Ventas, RevOps, soporte, tecnología, datos, seguridad, privacidad, legal, riesgo y comunicación. Añade clientes, socios, proveedores, aseguradora, asesores o autoridades cuando correspondan. Para cada audiencia registra por qué necesita información, qué decisión tomará, cuánto detalle requiere, el canal, la persona responsable y su suplente. Un contacto comercial no siempre es el contacto de seguridad. Mantén zona horaria e idioma y prueba el directorio en ejercicios. Una lista masiva no reemplaza el análisis de quién puede actuar. Asigna autoridad editorial y derechos de decisión. Una persona coordina la comunicación y otra la respalda. Seguridad confirma hechos técnicos; negocio describe el proceso afectado; soporte aporta preguntas; privacidad y legal evalúan requisitos; dirección decide asuntos materiales; comunicación adapta mensajes externos. Define quién redacta, valida, aprueba y publica para cada audiencia sin crear una cadena que vuelva obsoleta la actualización. Separa además hablar de decidir. La vocería puede explicar el estado sin poder reanudar una función, y quien aprueba una corrección técnica no necesariamente decide una notificación externa. Prepara canales principales y alternos. Necesitas una sala segura de coordinación, una bitácora, canales internos, atención a clientes y una ruta pública cuando el alcance lo requiera. No copies datos personales, secretos, prompts completos o evidencia forense en conversaciones amplias. Supón que correo, identidad o mensajería pueden fallar o estar comprometidos. Mantén contactos fuera de banda, una conferencia alternativa y un directorio protegido. Define cuál canal es oficial y prueba acceso, autenticación, capacidad y trazabilidad. Un grupo improvisado puede ayudar durante minutos, pero no debe convertirse en archivo permanente sin dueño ni reglas de acceso. Abre una bitácora única con identificador, hora, zona horaria, nivel, alcance provisional, funciones afectadas y responsables. Separa hechos confirmados, hipótesis, preguntas, decisiones, acciones y mensajes publicados. Cada elemento necesita fuente, responsable y hora. Conserva versiones. Si cambia un dato, registra qué se corrigió y quién recibió la versión anterior. No edites silenciosamente una cronología que otras personas usaron para decidir. La bitácora tampoco es un depósito sin límites: enlaza evidencia restringida y aplica minimización, acceso y retención. Usa una estructura estable para cada actualización. Empieza con estado y hora de corte. Explica qué está confirmado, qué servicio o proceso está afectado y qué acción realizó el equipo. Indica qué debe hacer la audiencia, qué debe evitar, dónde reportar un caso y cuándo llegará la siguiente actualización. Distingue hechos e investigación. Puedes afirmar que una función fue deshabilitada si existe evidencia. Si todavía revisas el alcance, dilo. No declares que no hubo exposición basándote solo en una muestra. Evita culpa, especulación y plazos de recuperación que no estén sostenidos. Compromete una cadencia aunque todavía no exista una respuesta final. La frecuencia depende del impacto, la velocidad de cambio y la audiencia. El equipo de respuesta puede necesitar continuidad; dirección, hitos de decisión; personal operativo, cambios que afecten su trabajo; clientes, un horario claro mientras exista impacto. La siguiente actualización es un compromiso de comunicación, no de resolución. Si no hay novedades materiales, confirma que la investigación continúa, repite las instrucciones vigentes y entrega el siguiente horario. Marca cada mensaje como inicial, actualización, corrección, recuperación o cierre. Ventas y soporte necesitan una respuesta operativa. Indica qué función evitar, qué alternativa utilizar, cómo reconocer una cuenta posiblemente afectada y dónde escalar. Prepara un guion con hechos autorizados y límites. Incluye preguntas reales: si una propuesta sigue vigente, si un precio debe reconfirmarse, si una Buyer Room continúa accesible, si un seguimiento debe pausarse o si el historial está completo. Vincula cada respuesta con la fuente oficial y una fecha de revisión. No pidas a vendedores investigar por su cuenta ni copiar información sensible a un chat. Cuando corresponda contactar a un cliente, explica el hecho confirmado para su servicio o información, las acciones tomadas, el estado y las instrucciones útiles. Si se compartió una propuesta equivocada, identifica versión y destinatario, retira o marca el documento cuando sea posible y envía una corrección clara basada en el catálogo autorizado. No asumas que una apertura confirma identidad, lectura, aceptación, firma o pago. Los requisitos de notificación dependen de leyes, sector, ubicación, contratos, datos y hechos. El plan debe activar revisión competente; no puede inventar un plazo universal. Coordina también a los proveedores. Define cómo abrir casos con modelo, nube, identidad, correo, CRM, almacenamiento e integraciones. Registra identificador, severidad, versión, región, datos minimizados, preguntas y próximo hito. Pide hechos y acciones. Una página de estado general no demuestra que tu recorrido esté sano. Verifica canales antes de compartir evidencia o ejecutar instrucciones recibidas durante la crisis. Un proveedor puede declarar recuperación mientras tus colas, permisos o datos siguen pendientes. Valida el proceso propio antes de comunicar normalidad. Si el alcance requiere comunicación pública, designa una vocería y una fuente oficial. Publica solo lo que la bitácora pueda sostener. Trata consultas, redes y rumores como señales que deben verificarse, no como hechos. Corrige información falsa sin amplificar detalles sensibles. No confirmes cuentas o datos a una persona sin autenticarla por el canal correcto. Coordina el mensaje público con avisos directos: un cliente afectado no debería enterarse únicamente por una publicación general, pero tampoco debes retrasar una instrucción urgente esperando un comunicado perfecto. Cierra la comunicación solo con una decisión comprobada. Distingue servicio recuperado, investigación terminada y remediación completa; pueden ocurrir en momentos diferentes. El mensaje final resume periodo, impacto conocido, acciones, límites pendientes y canal para consultas. Después revisa tiempos, aprobaciones, canales, contactos, preguntas y contradicciones. Actualiza plantillas y ejercicios. En Cerravi, Copilot propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente, no inventa precios y conserva monedas separadas. La responsabilidad de comunicar y decidir permanece en la organización.

Una matriz de decisiones de recuperación no decide por el equipo. Hace explícita la relación entre evidencia, opciones y autoridad. Cuando falla un AI Sales Copilot, no siempre hay que elegir entre dejarlo encendido o apagarlo por completo. Puede limitarse una función, exigir revisión humana, pasar a modo manual, revertir una versión, restaurar datos, aislar una dependencia o pausar el servicio. La matriz ayuda a comparar rutas sin depender de memoria o presión comercial. Una persona responsable confirma la opción y registra por qué. Además, una condición crítica puede anular cualquier promedio o puntuación. Define el límite antes de usar la matriz. Especifica la función, versión, organización, integración y recorrido comercial. Redactar un correo, consultar un catálogo, generar una propuesta y escribir en el CRM no tienen el mismo impacto. Establece qué señales abren la evaluación: permisos inesperados, datos inconsistentes, resultados fuera de política, degradación sostenida, una dependencia caída o una versión defectuosa. Una señal activa el análisis, pero no demuestra todavía la causa. Registra quién convoca, el identificador común y los eventos que obligan a reevaluar. Reúne un paquete mínimo de hechos. Incluye hora y zona horaria, función afectada, versión de modelo, prompt o configuración, fuente de datos, organizaciones posiblemente involucradas, acciones realizadas y nivel de confianza. Marca cada dato como confirmado, probable, descartado o pendiente. Añade el recorrido comercial: quién pudo ver el resultado, si salió un mensaje o propuesta y si existe una fuente autorizada para reconstruirlo. No esperes la causa raíz para contener, pero evita una reversión improvisada si todavía no sabes si el problema está en código, configuración o datos. Evalúa dimensiones que cambian la ruta. Observa impacto actual y posible, propagación, integridad y confidencialidad, reversibilidad, confianza de la evidencia, criticidad del proceso, capacidad manual, dependencia de terceros y tiempo antes de que el daño aumente. Mantén separadas magnitud y certeza. Un impacto potencial alto con evidencia débil puede requerir contención y más investigación. Un impacto moderado con propagación confirmada puede exigir una acción inmediata. Documenta también lo que no puede medirse: un porcentaje pequeño no vuelve irrelevante una condición comercial equivocada. Define líneas rojas que prevalecen sobre cualquier puntuación. Pueden incluir acceso entre organizaciones, credenciales usadas sin autorización, pérdida de la fuente de precios, corrupción que sigue propagándose, datos sensibles expuestos o una integración que no puede revocarse. Cada línea roja necesita una señal verificable, una acción inicial, una persona autorizada y una prueba para levantar la restricción. No copies umbrales de otra empresa. Arquitectura, datos, contratos, sector y jurisdicción cambian la respuesta; la matriz debe activar la revisión competente, no sustituirla. Prepara el menú de opciones. Mantener operación normal exige demostrar que el control funciona. Limitar alcance deshabilita una función, organización, canal o tipo de documento. La revisión humana obligatoria solo sirve si existe capacidad para revisar y rechazar. El modo degradado conserva una parte segura; el modo manual sustituye temporalmente la automatización. Un rollback vuelve a una versión anterior. Restaurar recupera datos desde una copia. Conciliar integra después el trabajo válido. Aislar corta una dependencia. Pausar detiene el uso y retirar cierra la capacidad de forma controlada. Relaciona señales, opción, requisito y autoridad en una sola vista. En cada fila muestra qué se observó, qué respuesta se recomienda, qué debe existir antes de ejecutarla, quién decide y qué prueba permite avanzar. Evita reglas como error mayor a cinco por ciento sin contexto de muestra, impacto y distribución. Usa lenguaje operativo. En vez de escribir mitigar, especifica: deshabilitar generación de propuestas para la organización afectada, conservar consulta al catálogo y exigir aprobación del responsable comercial. La matriz debe permitir entender la ruta sin releer todo el incidente. No confundas rollback, restauración y conciliación. Un rollback cambia código, configuración, prompt o modelo, pero no deshace mensajes enviados, propuestas compartidas ni registros modificados. Una restauración recupera datos desde un punto conocido y puede perder operaciones válidas posteriores. Por eso se prueba en un entorno aislado. La conciliación compara la copia con fuentes autorizadas y con el trabajo realizado durante la degradación. Define precedencia por campo, conflictos, lotes y criterios de aceptación. Restaurar sin conciliar puede perder negocio; conciliar sin evidencia puede consolidar el error. Diseña el modo manual como un control temporal con capacidad finita. Indica qué continúa, qué se pausa, dónde se registra cada actividad y qué fuente autoriza precios, contactos o condiciones. Evita hojas paralelas sin dueño. Si debes usarlas, define acceso, campos mínimos, versión, retención y plan de incorporación o destrucción. Calcula cuántos casos puede revisar el equipo. Si la cola supera esa capacidad, la supervisión existe solo en papel. Antes de automatizar otra vez, concilia, elimina duplicados y confirma responsables. Registra la decisión y la evidencia. Guarda hora, alcance, opción elegida, alternativas descartadas, incertidumbre, riesgo residual, responsables, aprobaciones, próxima revisión y condición de salida. Conserva también los desacuerdos materiales y quién los resolvió. No se trata de buscar culpables, sino de saber si faltó información, autoridad o un control. Distingue contención temporal de decisión definitiva. Todo control temporal necesita dueño, vencimiento y revisión; de lo contrario puede convertirse en operación normal sin haber sido aceptado. Reanuda por etapas con un gate verificable. Confirma que la condición está controlada, la versión está identificada, las pruebas relevantes pasaron, los permisos son correctos, los datos están conciliados, las dependencias responden y el monitoreo funciona. Empieza con datos de prueba, uso interno, una organización controlada o una función sin escritura. Observa errores, latencia, integridad y comportamiento humano. Amplía solo después de cumplir el gate. Si reaparece una señal, vuelve a la opción segura. Se ve bien nunca debe ser el criterio de recuperación. Vincula cada cambio de estado con una comunicación comprobable. Informa qué función está limitada, qué alternativa existe, quién debe actuar y cuándo se revisará. El equipo técnico necesita señales; Ventas y soporte, instrucciones; dirección, impacto y riesgo residual; un cliente afectado, hechos relacionados con su alcance. No conviertas una mitigación temporal en promesa. Distingue servicio recuperado, investigación terminada y remediación completa. Pueden ocurrir en momentos diferentes, y los requisitos de notificación deben evaluarse según el caso. Prueba la matriz con escenarios distintos y actualízala cuando cambien modelos, integraciones, datos, contratos, responsables o capacidad manual. Mide cuánto tarda el equipo en reunir hechos, decidir, ejecutar, comunicar y reevaluar. Retira rutas que ya no puedan realizarse. En Cerravi, Copilot propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente, no inventa precios y mantiene monedas separadas. La organización conserva la autoridad y la responsabilidad sobre recuperación, obligaciones y tolerancia al riesgo. Una matriz útil es corta, ejecutable, comprobada y capaz de mejorar después de cada ejercicio o incidente.

Una revisión post-incidente convierte lo ocurrido en cambios verificables. No es una recapitulación del ticket ni una reunión para encontrar culpables. Busca comprender qué condiciones técnicas, operativas y organizacionales permitieron el impacto y cómo reducir recurrencia o consecuencias. Incluye incidentes, recuperaciones difíciles y near-misses con aprendizaje material. El resultado no tiene que ser una causa única. Debe ser un conjunto priorizado de controles, decisiones y pruebas con responsables visibles. Abre la revisión cuando la contención y recuperación estén estables, pero antes de perder logs, versiones, mensajes y memoria operativa. Define periodo, organizaciones, funciones, datos, integraciones y recorridos comerciales. Indica qué queda fuera. Separa servicio recuperado, investigación terminada y remediación completa: pueden ocurrir en momentos distintos. Asigna facilitación, registro, fechas para el borrador y una revisión posterior de acciones. Reúne perspectivas del recorrido completo: detección, respuesta, decisiones, modo alterno, clientes y componente afectado. Pueden participar Ventas, RevOps, soporte, producto, ingeniería, datos, seguridad, privacidad, legal, riesgo y proveedores. La persona facilitadora no debe necesitar defender una implementación. Establece hechos antes que interpretaciones, desacuerdo registrado y ninguna represalia por reportar señales. Recoge aportes por escrito cuando jerarquía, idioma o zona horaria limiten la conversación. Construye un inventario de evidencia antes de contar la historia. Referencia alertas, logs, métricas, versiones, cambios, tickets, decisiones, propuestas, actividad del CRM y comunicaciones. Conserva hora, fuente, integridad, acceso y retención sin copiar secretos o datos personales innecesarios. Distingue evidencia directa, inferencia e información no disponible. Una apertura no prueba lectura o aceptación; un proveedor recuperado no demuestra que tus datos estén conciliados. Reconstruye una cronología factual con puntos de decisión. Registra evento inicial, primera señal, detección, clasificación, escalamiento, contención, modo manual, recuperación, comunicación y cierre. En cada punto anota hora, fuente, decisión e información disponible entonces. No juzgues con conocimiento posterior. Pregunta qué señales eran visibles y qué alternativa era viable. Marca huecos, handoffs y versiones contradictorias; no los ocultes mediante consenso. Mide el impacto sin mezclar alcance confirmado y potencial. Separa efectos técnicos, operativos, comerciales, humanos, contractuales y reputacionales. Describe organizaciones, datos, propuestas, precios, permisos o comunicaciones confirmadas. Mantén monedas separadas y evita atribuir pérdida de ingresos sin comparación válida. Registra duración de cada estado y capacidad del proceso alterno. Lo desconocido debe permanecer visible. Separa el desencadenante de las condiciones contribuyentes y latentes. Una nueva configuración puede iniciar la secuencia, pero una prueba incompleta, permisos amplios, monitoreo débil o autoridad confusa explican por qué produjo impacto. Evita cerrar con error humano. Analiza diseño, datos, integraciones, incentivos, documentación y handoffs. Cinco porqués o un árbol causal ayudan, pero no deben fabricar una sola causa. Si falta evidencia, declara causa no determinada y mejora observabilidad. Evalúa detección, decisiones, contención, recuperación y comunicación como capacidades. Comprueba si la alerta llegó a la persona correcta, si la clasificación fue clara, si la autoridad de parada funcionó, si la matriz ofreció opciones y si el modo manual tenía capacidad real. Registra también qué funcionó. Los tiempos solo son comparables bajo condiciones similares. Revisa dependencias, calidad de evidencia y puntos donde una decisión esperó información o aprobación. Relaciona cada hallazgo con el control que debía prevenir, detectar, corregir o recuperar. Pregunta cuál era su objetivo, qué evidencia debía producir y por qué no limitó el resultado. Distingue control ausente, diseño insuficiente, ejecución fallida y evidencia incapaz de demostrar eficacia. No conviertas toda respuesta en capacitación. La formación no reemplaza permisos, límites técnicos, pruebas, monitoreo o autoridad. Convierte cada hallazgo en una acción pequeña y comprobable. Incluye verbo, alcance, dueño, fecha, prioridad, dependencia, evidencia y criterio de cierre. Mejorar monitoreo es ambiguo. Agregar una alerta por escritura fuera del alcance, probarla con casos autorizados y vincularla al on-call sí puede verificarse. Separa contención, corrección inmediata y prevención estructural. Registra riesgo residual y limita la lista a acciones que realmente puedan financiarse y seguirse. Cierra por evidencia y retest, no porque el ticket cambió de color. Define antes cómo demostrar el resultado. Reproduce la condición de forma segura, ejecuta casos normales y adversos, valida permisos y datos, observa falsos positivos y revisa regresiones. Una acción material merece revisión independiente según el riesgo. Si el retest falla, reabre. Si aparece otro riesgo, regístralo. Un ticket en verde nunca prueba por sí solo eficacia. Adapta las conclusiones a cada audiencia. El equipo necesita detalle para corregir; dirección, impacto, riesgo residual y recursos; Ventas y soporte, instrucciones; clientes afectados, hechos y acciones de su alcance. No copies evidencia interna a todos. Corrige mensajes anteriores si cambiaron hechos materiales. Evita culpas, secretos y promesas de que nunca volverá a ocurrir. Las obligaciones dependen del caso y requieren revisión competente. Devuelve el aprendizaje al registro de riesgos, inventario, evaluación de impacto, pruebas, monitoreo, change management, continuidad y capacitación. Busca condiciones similares en otros componentes y proveedores. Revisa acciones vencidas y eficacia después del cierre. En Cerravi, Copilot propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente, no inventa precios y mantiene monedas separadas. La organización conserva responsabilidad sobre investigación, comunicación, riesgo residual y acciones correctivas.

Un plan de acciones correctivas para un AI Sales Copilot no es una lista de tickets cerrados. Reúne compromisos nacidos de incidentes, near-misses, auditorías, evaluaciones, red teaming, feedback, simulacros y terceros. Cada acción debe mostrar qué exposición sigue abierta, qué resultado debe cambiar, quién tiene autoridad y qué evidencia permitirá decidir. El porcentaje completado no demuestra que el riesgo haya disminuido. NIST relaciona los planes de acción con recursos, hitos, fechas, responsabilidad y monitoreo. Son referencias adaptables, no una plantilla universal ni una certificación. Controla la entrada. Registra fuente, identificador, fecha, versión, sistema, organización, recorrido, condición, criterio y evidencia por referencia. Separa reporte, hallazgo validado, contención, corrección inmediata y acción estructural. Una observación pendiente puede entrar como validando, pero no debe confundirse con una acción aprobada. No copies secretos, datos personales ni conversaciones enteras al backlog. Conserva quién validó la condición y qué alcance cubre. Así una tarea rápida no oculta la causa que sigue abierta. Define un registro mínimo. Incluye acción, riesgo, alcance, resultado observable, responsable, ejecutor, validador, autoridad de cierre, prioridad, fecha, hitos, dependencias, estado, evidencia, método de retest, control temporal y residual. Usa estados pocos y explícitos: propuesta, validando, aprobada, planificada, en curso, bloqueada, lista para retest, cerrada, reabierta, sustituida o aceptada temporalmente. Define quién puede mover cada estado y qué prueba exige. El estado describe flujo administrativo; nunca sustituye la conclusión de riesgo. Relaciona duplicados sin borrar historias. Dos tickets pueden compartir una causa, pero afectar versiones, organizaciones o compromisos distintos. Una acción puede necesitar varias implementaciones. Conserva fuentes, evidencia, personas afectadas, severidad y obligaciones de cada origen. Consolida solo cuando una acción cubra todo el criterio y alcance. Marca sustituida cuando otra decisión la reemplace formalmente, con motivo, fecha, autoridad y sucesora. No cierres duplicados para mejorar métricas. Crea una acción principal y subtareas cuando exista una dependencia común. Prioriza por riesgo abierto, urgencia y propagación. Revisa impacto, exposición, población, reversibilidad, privilegios, sensibilidad, dependencia común, recurrencia y eficacia del control temporal. Separa severidad del hallazgo, prioridad de tratamiento y fecha comprometida. No siempre coinciden. No existe una ventana universal. Define fechas según obligaciones, tolerancia, capacidad y contexto. Una acción antigua de bajo impacto no desplaza automáticamente una ruta crítica nueva. Una crítica tampoco espera por haber llegado después al tablero. Separa roles. La persona responsable asegura resultado y recursos. Quien ejecuta implementa tareas. Quien valida comprueba el criterio. La autoridad de cierre decide con evidencia y residual. En un equipo pequeño una persona puede ocupar varios roles, pero la combinación debe verse y ser proporcional al riesgo. Asigna suplencia, escalamiento y tiempo real. Un nombre sin capacidad para cambiar permisos, reservar pruebas o negociar con un proveedor no es propiedad efectiva. Un comité decide, pero no reemplaza una persona responsable por acción. Escribe resultados comprobables. Evita mejorar, fortalecer o revisar sin objeto y resultado. Define qué cambia, dónde, para quién, con qué límite y cómo se probará. Divide investigación, diseño, implementación, despliegue, retest, observación y cierre. Completar capacitación, modificar un prompt o desplegar una regla es un hito; no demuestra eficacia. Cada acción necesita origen, riesgo, cambio, alcance, responsable, hitos, fecha, dependencia, evidencia, retest, residual y autoridad. Haz visible la ruta crítica. Registra dependencias de datos, identidad, catálogo, modelo, proveedor, legal, seguridad, presupuesto, entorno y personas. Señala qué bloquea el inicio, qué bloquea el retest y qué puede degradar el resultado. Limita el trabajo simultáneo según especialistas y entornos disponibles. Marcar cien acciones como urgentes no crea cien equipos. Revisa secuencia y opciones: eliminar alcance, aplicar una barrera temporal, agrupar un cambio común o pausar la función hasta tener evidencia. Gobierna la espera. Si la corrección estructural tarda, documenta el control temporal, cobertura, dueño, prueba, limitación, caducidad y señal de falla. Puedes reducir alcance, retirar una herramienta, exigir doble revisión, bajar permisos, limitar volumen o volver al proceso manual. Temporal no significa informal. Si el control falla, cambia la exposición o vence, reevalúa antes de renovar. Renovaciones repetidas revelan deuda o falta de recursos. Una autoridad decide continuar, limitar, pausar o aceptar por un periodo. Cierra por evidencia, retest y operación. Confirma que el cambio llegó a la versión y población correctas. Repite el caso original, prueba variantes, recorridos legítimos, permisos, trazabilidad, regresiones y fallback. Observa la operación necesaria según frecuencia y riesgo. El paquete de cierre reúne origen, condición, cambio, versión, casos, resultados, limitaciones, periodo y residual. La decisión puede ser cerrar, reabrir, ampliar, sustituir o aceptar temporalmente. Un merge, una capacitación o un ticket verde no bastan. Trata desviaciones como decisiones. Una fecha vencida no se arregla moviéndola en silencio. Conserva motivo, exposición, control temporal, dependencia, nueva fecha y autoridad. Escala antes del vencimiento cuando falte capacidad o cambie el riesgo. Si el retest falla, reabre y conserva el intento. Si la solución crea otro riesgo, relaciónalo. Si el componente fue retirado, verifica que el alcance desapareció. Si aceptas el riesgo, registra justificación, condiciones, vencimiento y monitoreo. Aceptación no es remediación. Mide flujo, riesgo y calidad. Observa inventario por prioridad, edad, tiempo hasta validación, contención, implementación y retest, vencidas, bloqueadas, reabiertas, retests fallidos, recurrencia, excepciones por vencer y cobertura temporal. Separa entradas, salidas y backlog. No uses solo porcentaje cerrado, promedio de días o número de hallazgos: pueden mejorar al dividir acciones, bajar severidad o dejar de reportar. Segmenta por sistema, causa, control, proveedor y responsable. Conserva denominadores y muestra no disponible cuando falte evidencia. Revisa el plan en varios niveles. Operación resuelve bloqueos e hitos. Riesgo decide prioridades, controles temporales y aceptaciones. Dirección asigna recursos y trata exposiciones entre equipos. Reabre la revisión por cambios de modelo, herramienta, permiso, fuente, proveedor, propósito o autonomía. Devuelve aprendizaje a riesgos, inventario, pruebas, monitoreo, cambios, continuidad y proveedores. En Cerravi, Copilot propone siguientes pasos para revisión humana; no ejecuta cierres ni envíos automáticamente, no inventa precios y mantiene monedas separadas. La organización conserva la autoridad y responsabilidad sobre el plan.

Un problema recurrente no es otro nombre para un incidente. El incidente coordina impacto, contención y recuperación. El hallazgo registra una condición contra un criterio. La acción correctiva organiza un cambio. El problema conecta varios eventos para entender por qué comparten síntomas, dependencias o fallas de control. Conserva cada caso y enlázalo. El objetivo es reconocer una exposición sistémica, reducir su recurrencia o consecuencia y dejar una memoria que otra persona pueda usar. No busca una etiqueta elegante ni a quién culpar. Define cuándo evaluar un patrón. No esperes por costumbre a que ocurra tres veces. Un solo caso material puede revelar una condición común. También abre una investigación cuando reaparece después de una corrección, surge en distintas organizaciones, aumenta una tasa fuera de tolerancia, participa la misma dependencia o varios near-misses muestran una ruta equivalente. Una coincidencia no prueba una causa. Usa estado candidato cuando falte evidencia, asigna fecha de revisión y separa impacto, frecuencia, población, propagación y capacidad de detección. Crea un registro con identidad estable. Incluye dueño, estado, fecha, alcance, recorridos, síntomas, impacto agregado, casos relacionados, versiones, dependencias, controles esperados, hipótesis, error conocido, solución temporal, acciones, evidencia, residual y próxima decisión. Distingue confirmado, probable, posible, descartado y desconocido. Una hipótesis no se vuelve causa porque aparece en el campo root cause. Registra qué la respalda, qué la contradice y qué prueba podría cambiarla. Enlaza incidentes y hallazgos sin copiar datos sensibles. Normaliza el contexto antes de comparar. Captura tarea, resultado, severidad, versión de aplicación, modelo, prompt, fuente, catálogo, permiso, herramienta, integración, rol, canal, idioma, moneda, organización, cambio reciente, detección y control esperado. Conserva la descripción original por referencia y utiliza categorías controladas para analizar. Protege trazas y documentos con acceso restringido, minimización y retención. Evita etiquetas como error humano: suelen esconder una interfaz, autoridad, automatización, presión o barrera que permitió el resultado. Agrupa por condiciones compartidas, no solo por palabras parecidas. Compara síntoma, recorrido, objeto, disparador, dependencia, control fallido y cambio reciente. La similitud semántica puede proponer vecinos, pero una persona debe validar el vínculo. Dos reportes sobre precio incorrecto pueden venir de un catálogo vencido, moneda mezclada o edición posterior. Permite relaciones muchos a muchos y conserva excepciones. Un incidente puede pertenecer a un patrón de permisos y otro de despliegue. Un caso que parece igual pero funciona con otra versión ayuda a definir el límite del cluster. Analiza el recorrido completo: usuario, interfaz, sesión, permisos, recuperación, fuente, modelo, herramienta, validación, aprobación, salida y monitoreo. Pregunta qué condición permitió cada caso, qué barrera debía intervenir y por qué no lo hizo. Separa disparador, factores contribuyentes, condiciones latentes y fallas de detección o recuperación. No fuerces una causa única. Un patrón puede requerir catálogo vigente, recuperación correcta y validación de moneda al mismo tiempo. Contrasta la explicación con incidentes parecidos y ejecuciones correctas. Si no explica ambos grupos, sigue siendo una hipótesis. Cuando el patrón está suficientemente entendido, publica un error conocido. Documenta condición, síntoma, alcance, versiones, riesgo, detección, diagnóstico, solución temporal, límites, dueño, vencimiento y escalamiento. Debe ayudar a reconocer el caso sin exponer información sensible ni una ruta de abuso. La protección temporal puede limitar una función, retirar una fuente, exigir revisión, bajar permisos o volver al proceso manual. Comprueba que opere y que alguien vea su falla. Error conocido no significa riesgo aceptado, y workaround no significa problema resuelto. Prioriza el riesgo agregado. Revisa impacto por caso y población, frecuencia, tendencia, exposición, reversibilidad, privilegios, sensibilidad, dependencia común, detección y eficacia temporal. Muchos eventos leves pueden revelar una debilidad más importante que un caso aislado. Separa prioridad del problema, severidad de cada incidente y orden de las acciones. Reserva capacidad para analizar y corregir la fuente: si el equipo solo atiende síntomas, el patrón seguirá creando trabajo. No fabriques probabilidad con pocos datos. Muestra periodo, supuestos y desconocidos. Diseña acciones ligadas a condiciones y controles fallidos. Corrige el dato en su fuente, aplica autorización en la capa que ejecuta, valida precios y monedas en código, reduce rutas alternativas, mejora detección y actualiza recuperación. Un prompt o una capacitación pueden apoyar, pero no sustituyen un control de permisos, dinero o acciones. Lleva responsables, hitos, fechas, dependencias, evidencia y retest al plan de acciones correctivas. Distingue contención, reparación, cambio estructural y prevención en sistemas vecinos. Una tarea cerrada no cierra el problema. Comprueba la mejora con regresiones y operación. Convierte casos históricos, variantes cercanas y recorridos legítimos en pruebas. Cuando sea seguro, confirma que el caso detecta la versión defectuosa y aprueba la candidata. Revisa interfaz, API, PDF, DOCX, Buyer Room, automatizaciones e historial; cambiar el texto visible no basta. Después observa una población y un periodo compatibles con la frecuencia anterior. Compara casos por ejecuciones elegibles, organizaciones o propuestas y segmenta por versión. Cero reportes durante una ventana corta no demuestra eliminación. Asigna un dueño del problema que mantenga la visión del patrón y conduzca decisiones. Investigación, datos, controles, incident response y cambios pueden tener responsables distintos. Una autoridad prioriza recursos o acepta residual. En equipos pequeños es posible combinar funciones, pero debe quedar visible. Revisa nuevos casos, hipótesis, bloqueos y experimentos con una cadencia operativa; revisa exposición y controles temporales con una cadencia de riesgo. Reabre cuando aparezca una variante material, falle una regresión, venza la protección o cambie una dependencia. Mide reconocimiento, exposición y aprendizaje. Observa tiempo desde el primer caso hasta identificar el patrón, población expuesta, recurrencia con denominador, edad, tiempo hasta protección y corrección, acciones vencidas, cobertura de regresiones, variantes y reaperturas. Segmenta por versión, recorrido, control, causa y proveedor. No premies pocos incidentes o cierres rápidos sin cobertura: el canal puede estar roto, la adopción puede caer o el detector puede fallar. Publica definición, fuente, periodo, exclusiones y límites. Las métricas sirven para decidir, no para clasificar personas. Cierra con casos, alcance, análisis, error conocido, controles temporales, acciones, versiones, regresiones, operación observada, tendencias, limitaciones y riesgo residual. Confirma que la corrección llegó a producción, que el workaround fue retirado o gobernado y que sistemas vecinos no conservan la misma condición. Conserva el registro para búsqueda y define disparadores de reapertura. En Cerravi, Copilot propone contexto para revisión humana, no envía ni cambia etapas automáticamente. Usa precios del catálogo y mantiene monedas separadas. Esos límites se prueban en cada versión: la memoria operacional orienta, pero no sustituye evidencia.

Un runbook operativo convierte una señal conocida en una decisión controlada. Le dice a una persona autorizada qué comprobar, qué resultado esperar, cuándo detenerse y a quién escalar. No sustituye la política, el plan de incidentes ni la continuidad. Los conecta cuando hacen falta. En un AI Sales Copilot debe cubrir la aplicación, el modelo, la recuperación, el catálogo, el CRM, los permisos, las integraciones y las salidas. Su prueba más simple es que otra persona pueda usarlo sin depender de la memoria del autor. Primero separa documentos. La política define obligaciones y autoridad. El playbook organiza una respuesta adaptable. El runbook detalla una tarea acotada. El plan de continuidad preserva procesos críticos y el proceso de incidentes coordina impacto activo. Define una frontera clara: el operador puede verificar, reunir evidencia y ejecutar acciones preautorizadas. Debe transferir el control si existe impacto material, datos sensibles, propagación, abuso posible, una acción irreversible o una situación que el diagnóstico no contempla. Abre el runbook con una ficha del servicio. Incluye propósito, dueño, criticidad, usuarios, horario, regiones, recorridos críticos, componentes, proveedores, versiones, dependencias, expectativas de servicio, paneles, registros y contactos. Enlaza el inventario de IA y el mapa de datos. Documenta también límites funcionales verificables. En Cerravi, Copilot propone contexto para revisión humana, no envía mensajes ni mueve etapas automáticamente, usa precios del catálogo y separa monedas. Si tu implementación actúa de otra forma, registra quién autoriza y dónde se controla. Declara las precondiciones antes de los pasos. Rol, aprobación, entorno, ventana, herramientas, fuente de verdad, respaldo y riesgo. El operador confirma organización, versión, región, moneda y objeto comercial. No guardes contraseñas, claves de API, tokens ni enlaces de sesión en el runbook. Enlaza el gestor de secretos por nombre lógico y explica cómo pedir acceso temporal. Si no puedes comprobar identidad, entorno o permiso, detente. El documento no concede autoridad adicional ni permite saltarse controles por urgencia. Organiza rutinas que cambien decisiones. Cada día revisa disponibilidad de recorridos, errores por versión, colas, integraciones, recuperación, permisos, precios sin fuente, monedas mezcladas, salidas bloqueadas, feedback y alertas abiertas. Cada semana busca tendencias, alertas repetidas, deuda, workarounds próximos a vencer, cambios de proveedor y procedimientos que fallaron. Después de un despliegue utiliza una lista breve ligada al cambio. Registra hora, versión, resultado, excepción y siguiente acción. Un check verde sin evidencia no permite reconstruir el estado. Relaciona señal y acción en una matriz. Para cada señal define fuente, población, ventana, umbral, impacto posible, falsos positivos, evidencia mínima, primera comprobación, acción segura, condición de escalamiento y responsable. Separa aviso, ticket y alerta urgente. No interpretes un número sin denominador, cobertura y versión. Cinco errores pueden ser críticos en diez propuestas y ruido en otro contexto. Si no puedes estimar el alcance, declara esa incertidumbre y escala; no la conviertas en precisión inventada. Escribe el diagnóstico como un árbol observable. Empieza por el síntoma, no por una causa histórica. Si una propuesta muestra un precio inesperado, confirma organización y moneda; después producto y catálogo; luego fuente recuperada, permisos, transformación, exportación y cambios recientes. Cada rama necesita una consulta, un resultado esperado y el siguiente destino. Distingue hechos, inferencias e hipótesis. Si una consulta falla, el resultado contradice el árbol o aparece una condición nueva, detente y escala con la evidencia disponible. Limita el runbook a acciones aprobadas, reversibles y verificables. Para cada acción documenta objetivo, autoridad, alcance, parámetros, respaldo, efecto esperado, tiempo máximo, comprobación, rollback y registro. Separa observar, contener, recuperar y corregir. Reiniciar puede recuperar un proceso, pero también destruir una señal o repetir una acción. Usa doble confirmación de entorno, vista previa, límites por lote e idempotencia. Prohíbe limpiar logs, ampliar permisos, modificar datos directamente o desactivar controles globales. Si hay que improvisar, ya no es una operación preautorizada. Prepara un modo degradado que conserve el proceso comercial. Puede apagar sugerencias, congelar una automatización, retirar una fuente, exigir aprobación adicional o volver a una plantilla manual. Define disparador, autoridad, funciones disponibles, mensaje, capacidad, controles compensatorios, operaciones pendientes y criterio de salida. Enlaza el plan de continuidad para objetivos y dependencias. El modo manual también crea riesgo: duplicados, etapas desactualizadas y documentos sin vínculo. Conserva un registro y concilia antes de volver a la operación normal. Haz que escalar sea una decisión, no una búsqueda de contactos. Define rutas por impacto, sistema y horario: operación, aplicación, datos, seguridad, privacidad, proveedor y dirección. Envía un paquete breve con qué ocurre, desde cuándo, población, versión, evidencia, acciones realizadas, cambios recientes, riesgo y decisión solicitada. Declara incidente ante impacto visible, riesgo para datos o dinero, propagación, abuso posible, varios equipos o diagnóstico sin límite. La responsabilidad solo cambia cuando la contraparte acepta explícitamente el handoff. Mantén una bitácora suficiente y protegida. Registra hora, actor, rol, señal, alcance, versión, consultas, resultados, decisiones, aprobaciones, verificaciones y estado. Preserva logs antes de una acción que pueda rotarlos y marca lo desconocido. No reconstruyas huecos con memoria. Minimiza datos: usa identificadores, fragmentos redactados y repositorios con acceso y retención. No copies prompts, archivos de clientes o tokens en chats operativos. La evidencia debe explicar qué se observó y por qué se decidió, no crear otro almacén sensible. Cierra el turno con una entrega explícita. Resume estado, alertas, incidentes, problemas, cambios, modo degradado, acciones en curso, riesgos, próximas horas y enlaces. Separa lo observado de lo supuesto. La persona entrante comprueba accesos y repite las verificaciones críticas. Nombra quién conserva responsabilidad y pide aceptación. Si nadie acepta, escala a quien administra la cobertura. Incluso sin guardia de veinticuatro horas, registra el estado al final del día, el canal de emergencia y qué puede esperar a la siguiente ventana. Prueba el runbook con una persona que no lo escribió. Incluye accesos ausentes, paneles sin datos, proveedor caído, versión distinta y resultados ambiguos. Verifica que se detenga, preserve evidencia, escale y pueda revertir. Versiona dueño, aprobador, sistemas compatibles, último ensayo, hallazgos y próxima revisión. Actualiza después de cambios, incidentes o desvíos y retira copias antiguas. Una plantilla útil termina con objetivo, precondiciones, pasos, resultado esperado, condición de alto, acción segura, rollback, evidencia, escalamiento, modo degradado y entrega. Si la tarea se repite demasiado, automatízala o elimínala. Tu siguiente paso es elegir una operación real y frecuente, no el incidente más dramático. Escribe su ficha, una matriz de señal y acción, un árbol corto, una acción segura, una condición de alto y una entrega. Pide a otra persona que lo ejecute en un entorno controlado. Corrige cada duda que aparezca y registra la versión. En Cerravi puedes mantener contexto comercial, precios de catálogo y próximos pasos visibles mientras la decisión permanece bajo revisión humana. El runbook debe hacer esa operación más clara, trazable y segura.

Un porcentaje verde no demuestra que un AI Sales Copilot esté ayudando a vender. Puede responder y aun así recuperar la cuenta equivocada, mezclar monedas o entregar una cotización tarde. Un SLO útil empieza por la experiencia que el equipo necesita y termina en una decisión operativa. En este recorrido construiremos un indicador, un objetivo y un error budget sin copiar promesas ajenas ni convertir una meta interna en contrato. Primero separa los conceptos. El SLI es la medida: la proporción de eventos que alcanzan un resultado definido. El SLO es el nivel objetivo para esa medida dentro de una ventana. El error budget es la parte que puede quedar fuera del objetivo. El SLA es distinto: contiene consecuencias explícitas y necesita revisión comercial, contractual y legal. Un dashboard interno no crea un SLA por sí solo. Empieza por un recorrido comercial observable. Para cotizar, la persona abre una oportunidad, recupera cuenta y catálogo, selecciona productos, conserva moneda, genera el documento, revisa y exporta. Define dónde empieza y termina la responsabilidad del copiloto. La medición debe acercarse al resultado final. Una API disponible no sirve como única evidencia si el archivo exportado queda vacío o pierde la fuente del precio. Ahora fija el denominador. Un evento elegible cumple las precondiciones del recorrido. Un evento bueno alcanza el resultado. Una cancelación del usuario, una prueba interna o una solicitud inválida necesita una categoría estable. No cambies exclusiones al final del periodo para mejorar el porcentaje. Registra versión, organización, segmento y razón de fallo. Controla también reintentos y duplicados: una segunda respuesta exitosa puede esconder dos documentos creados. No combines todo en una sola media. Disponibilidad pregunta si hubo resultado utilizable. Latencia, si llegó a tiempo. Calidad, si conservó propiedades como producto, moneda, fuente y total. Seguridad, si respetó acceso y límites. Una respuesta rápida con precio incorrecto no compensa una respuesta lenta pero válida. Para propiedades generativas, documenta la rúbrica, la muestra, el desacuerdo humano y la incertidumbre. Segmenta antes de calcular el promedio. Revisa recorrido, versión, integración, organización, región, modelo y nivel de riesgo cuando puedan cambiar el resultado. Publica el volumen junto con la proporción. Un noventa y nueve por ciento sobre cien eventos no tiene la misma estabilidad que sobre cien mil. En poco tráfico, combina la tasa con conteos, ventanas más largas, pruebas sintéticas y revisión de casos materiales. La ventana debe representar el uso real. Define si es móvil o de calendario, la zona horaria, el retraso de datos y el tratamiento de periodos sin actividad. Conserva una vista corta para operación y otra más larga para tendencias. No uses solo promedios. Un mes aceptable puede esconder una interrupción concentrada justo en el cierre comercial. Para latencia, observa colas y percentiles relevantes, no únicamente la media. Elige el objetivo con línea base, necesidad del usuario, impacto, alternativa manual, dependencias, costo y capacidad de respuesta. No copies noventa y nueve punto nueve por ciento porque otra empresa lo publica. Tampoco prometas cien por ciento. Escribe la fórmula completa: recorrido, eventos, propiedades, ventana, segmentos y fuente. Si la definición no cabe en una ficha clara, será difícil operarla y todavía más difícil explicarla. Convierte el objetivo en presupuesto. Si el SLO se expresa como proporción de eventos buenos, el error budget es uno menos el objetivo. Ejemplo únicamente ilustrativo: con diez mil eventos elegibles y un objetivo hipotético de noventa y nueve por ciento, el margen aritmético sería cien eventos. Eso no autoriza cien precios incorrectos. Una clase crítica puede activar respuesta desde el primer caso aunque todavía exista saldo. No esperes al cierre de la ventana. El consumo muestra cuánto presupuesto se gastó; la tasa de consumo indica la velocidad. Usa señales rápidas y lentas para distinguir una falla urgente de una degradación sostenida. En servicios con poco tráfico, una sola solicitud puede generar una tasa extrema. Añade volumen mínimo, duración, criticidad y revisión humana para evitar tanto el silencio peligroso como alertas imposibles de atender. El presupuesto necesita una política acordada antes del incidente. Define qué ocurre al observar consumo normal, acelerado o agotado: registrar, abrir ticket, investigar, limitar despliegues, exigir aprobación, activar modo degradado o declarar incidente. Identifica autoridad, suplencia, excepciones y salida. No uses la política para castigar al equipo. Úsala para negociar confiabilidad y velocidad con una regla visible y evidencia compartida. El tablero debe explicar, no solo colorear. Muestra recorrido, objetivo, ventana, volumen, resultado actual, presupuesto restante, consumo, segmentos, cambios recientes y dueño. Distingue un incumplimiento de un dato retrasado o un detector sin cobertura. Las alertas deben indicar quién actúa y cuándo: atención inmediata, ticket próximo o registro para análisis. Cada una enlaza el panel exacto, la versión y el runbook correspondiente. Versiona la definición como parte del sistema. Conserva consulta, exclusiones, fuente, aprobadores, fecha efectiva, incertidumbre y próxima revisión. No compares periodos como equivalentes después de cambiar el denominador. Empieza con uno o dos recorridos críticos, valida el cálculo contra muestras y observa antes de activar consecuencias. Después ensaya caída completa, degradación lenta, error de calidad, poco tráfico y telemetría retrasada. Un buen SLO no busca fabricar más nueves. Busca que producto, operación y negocio reconozcan la misma experiencia, midan el mismo conjunto y actúen antes de que una degradación se convierta en costumbre. Empieza por un recorrido, define eventos buenos y elegibles, separa calidad de disponibilidad, acuerda el presupuesto y practica la política. En Cerravi, la evidencia organiza la decisión; ninguna cifra sustituye la revisión humana ni crea una garantía universal.

Una guardia para un AI Sales Copilot no existe para vigilar cada error ni para mantener a una persona conectada todo el día. Existe para proteger recorridos que no pueden esperar: acceso entre organizaciones, precios sin fuente, monedas alteradas, propuestas inutilizables o una dependencia que impide revisar el trabajo comercial. Primero delimita servicio, usuarios, horario, versiones, alternativas y consecuencias. Si la frontera no está escrita, cualquier anomalía termina como una interrupción urgente. Separa tres destinos. Una página interrumpe porque alguien debe reconocer, contener o escalar ahora. Un ticket representa trabajo importante con dueño y plazo. Un registro conserva evidencia para tendencia y revisión. Decide por impacto, propagación, reversibilidad, población y alternativa manual. Un precio faltante que el producto bloquea puede esperar un ticket. Un precio perteneciente a otra organización puede requerir contención inmediata, aunque ambos aparezcan como error de catálogo. Elige una cobertura que el equipo pueda sostener. No todo copiloto necesita veinticuatro horas los siete días. Puede existir guardia durante el horario operativo, cierres comerciales o periodos de cambio; también puede ser continua cuando uso, impacto y compromisos lo justifican. Documenta zona horaria, turnos, feriados, ausencias y qué ocurre fuera de cobertura. Si la promesa supera la capacidad, reduce alcance o fortalece el modo manual antes de depender de heroicidad. Asigna una guardia primaria, una secundaria y especialistas localizables. La primaria clasifica la señal. La secundaria cubre falta de respuesta, concurrencia o apoyo. Datos, identidad, seguridad, aplicación, proveedor y negocio participan cuando la evidencia señala su dominio. Para incidentes complejos separa coordinación, operación y comunicación. Cada rol necesita autoridad, prohibiciones y suplencia. Estar de guardia no concede acceso ilimitado ni permiso para aceptar riesgo, cambiar datos comerciales o notificar clientes. Nadie entra a la rotación solo por conocer el código. La preparación cubre arquitectura, recorridos comerciales, señales, permisos, runbooks, comunicación y límites del producto. Practica observación, turnos acompañados y escenarios: alerta falsa, degradación lenta, error de calidad, dependencia externa, posible exposición y recuperación con datos pendientes. Evalúa si la persona puede contener, pedir ayuda y entregar responsabilidad. La preparación termina con evidencia reproducible, no por antigüedad o confianza informal. La matriz de activación describe impacto observable. Incluye recorrido, población, alcance entre organizaciones, integridad, privacidad, duración, propagación, alternativa manual y confianza de la evidencia. Algunas líneas rojas se activan con un caso; una degradación puede necesitar ventana y persistencia. La severidad inicial es una hipótesis que puede subir o bajar. Registra quién la asignó, qué hechos la sostienen y qué condiciones obligan a escalar, sin permitir que un promedio verde cierre un caso material. Construye una escalera que termine en autoridad real. Define a quién contactar, por qué canal, qué evidencia enviar, cuánto esperar según la urgencia y qué hacer si no responde. Avanza de primaria a secundaria, especialistas, incident manager y autoridad para limitar o pausar. Los intervalos los decide cada organización; no existe uno universal. Escalar por incertidumbre o falta de progreso es una acción de control. Prueba periódicamente contactos, grupos, permisos y canales alternos. Una página útil permite empezar sin investigar desde cero. Incluye servicio, entorno, recorrido, severidad, hora, versión, segmento, síntoma, volumen, cambio reciente y enlaces al panel y runbook correctos. Añade la primera verificación segura y la ruta para declarar incidente. No copies propuestas, conversaciones, credenciales o datos personales. Deduplica ráfagas y conserva el conteo. Si la telemetría perdió cobertura, muéstralo: silencio de datos no significa que el sistema esté sano. En el triage separa disponibilidad, calidad, datos y autorización. Confirma qué intentó hacer la persona, qué resultado recibió y qué parte produjo Cerravi, una integración o un proveedor. Revisa organización, rol, versión, catálogo, moneda y fuente. Clasifica el síntoma sin mezclar hechos con hipótesis. Cerravi organiza contexto y propone acciones para revisión; no envía mensajes ni cambia etapas automáticamente. La respuesta debe respetar esa frontera y no atribuir al producto acciones que no ejecuta. Preautoriza acciones seguras. El runbook distingue observar, recolectar evidencia, aislar una dependencia, limitar una función, exigir revisión adicional, activar modo degradado, revertir o pausar. Cada paso indica precondición, permiso, resultado esperado, condición de alto y rollback. La guardia no improvisa descuentos, corrige precios en nombre de ventas, borra registros ni acepta excepciones permanentes. Si la decisión es comercial, legal, de privacidad o seguridad, escala con opciones y consecuencias. El handoff transfiere responsabilidad, no solo información. Registra hechos, impacto, severidad, línea de tiempo, acciones, cambios activos, hipótesis, evidencia pendiente, contactos, decisiones, riesgos y próximo control. Quien recibe confirma comprensión, acceso y responsabilidad. Un mensaje enviado no completa la entrega. Si la persona saliente conserva una tarea, queda como especialista y no como dueña implícita. Entrega antes de que la fatiga degrade decisiones y guarda el resumen en el sistema de registro. Mide la carga para mantener una rotación sostenible. Observa páginas por turno, interrupciones nocturnas, concurrencia, tiempo activo, escalaciones, falsos positivos, trabajo posterior y defectos de handoff. Segmenta por detector y servicio: un promedio bajo puede ocultar una semana inviable. Elimina alertas sin acción, mejora runbooks, automatiza pasos repetibles y reserva capacidad para causas recurrentes. La confiabilidad no debe comprarse con agotamiento ni con una sola persona indispensable. Evalúa la guardia por calidad, no solo por velocidad. Mide tiempo hasta reconocimiento, clasificación, contención y recuperación junto con escalamiento oportuno, cobertura de la entrega, reaperturas y daño evitado. Publica severidad, periodo y denominador. Relaciona las páginas con SLI, SLO, error budget, incidentes, problemas y acciones correctivas. Un reconocimiento rápido sin una decisión útil no demuestra eficacia. Las métricas mejoran el sistema de respuesta; no sirven para castigar a quien pide ayuda temprano. Cierra con ejercicios y revisión. Prueba detector, página, panel, runbook, especialista, autoridad, modo degradado, comunicación, recuperación y handoff. Incluye canal caído, credencial vencida, alerta duplicada, poca evidencia y proveedor ausente. Revisa la rotación cuando cambien modelo, prompt, catálogo, integración, permisos, población, horario, SLO o arquitectura. El objetivo es simple: que una señal material encuentre a una persona preparada, una acción segura y una autoridad clara antes de que el impacto crezca.

Planear capacidad para un AI Sales Copilot no empieza con CPU ni con una cifra de usuarios. Empieza con el recorrido que debe llegar a tiempo. Consultar una cuenta, preparar una reunión, generar un borrador, validar precios y exportar una propuesta consumen recursos distintos. Describe población, horario, concurrencia, tamaño, dependencias, tiempo útil y alternativa manual. Una API puede responder mientras una cola convierte una tarea de minutos en un resultado que ya no sirve para la conversación comercial. Convierte la demanda en unidades que expliquen el costo. Mide usuarios concurrentes, operaciones por tipo, documentos, filas, tamaño de archivos, tokens de entrada y salida, llamadas a herramientas, conexiones, duración y reintentos. Conserva organización, versión, modelo y recorrido sin copiar contenido sensible. Estima el costo cuando admites el trabajo y concílialo al terminar. En modelos generativos, la salida completa se conoce después; utiliza límites y estimaciones conservadoras, no una precisión inventada. Sigue el flujo completo hasta encontrar el primer límite. Mapea navegador o tarea programada, identidad, CRM, catálogo, recuperación, modelo, herramientas, base, exportación, correo y telemetría. Anota cuotas y recursos compartidos. Busca fan-out: una acción puede multiplicarse en búsquedas, herramientas y reintentos. Define si el impacto queda en una organización, una operación, un modelo o todo el servicio. Proteger solo la entrada puede trasladar la sobrecarga a la base o al proveedor. Modela base, pico, crecimiento y mezcla. Separa horario laboral, cierre de mes, campañas, importaciones, nuevos equipos y cambios de modelo. Un promedio diario oculta una ráfaga de veinte minutos. Para una función nueva, multiplica población elegible, adopción, frecuencia, concurrencia y costo por operación. Prueba escenarios normal, alto y extremo. Registra supuestos, rango e información faltante. El forecast orienta una decisión; no garantiza demanda ni rendimiento futuros. Define la envolvente operativa. Reúne volumen, mezcla, latencia, calidad, error, costo y estado de dependencias bajo los cuales el recorrido cumple su objetivo. Marca un punto de advertencia, otro para limitar trabajo y otro para detener. El recurso decisivo puede ser tokens, conexiones, memoria, cola, almacenamiento, presupuesto o capacidad humana de revisión. Reserva margen para ráfagas y escalamiento. No existe un porcentaje universal: depende de criticidad, tiempo de provisión y alternativa disponible. Asigna cuotas por organización, recorrido, operación, modelo y clase de trabajo. Separa límites de usuario, que evitan vecinos ruidosos, y límites de servicio, que protegen al conjunto. Mantén aparte trabajo interactivo, lotes y administración para que una importación no retrase una llamada con cliente. Si permites ráfagas, define duración, deuda y máximo. El límite debe producir una respuesta visible y accionable. Rechazar en silencio provoca reintentos, duplicados y tickets difíciles de reconstruir. Una cola absorbe diferencias temporales, pero no crea capacidad. Mide profundidad, edad del elemento más viejo, entrada, salida y trabajo vencido. Define un máximo. Una cola sin límite convierte un pico breve en horas de atraso y puede llenar memoria o disco. Prioriza por utilidad y fecha límite, no por quién reintenta más. Usa idempotencia para no duplicar mensajes o documentos. Decide qué trabajo puede expirar, cancelarse o volver a solicitarse. Backpressure comunica al origen que reduzca el ritmo. Throttling limita tasa, concurrencia, volumen o costo. Colócalos en la entrada, entre componentes y antes de dependencias. Devuelve espera sugerida y alternativa cuando aplique. Los clientes deben usar backoff, jitter, máximo de intentos y una condición para parar. Un retry inmediato amplifica la demanda cuando queda menos capacidad. Prueba el contrato completo: un cuatro veintinueve no ayuda si otra capa lo oculta y reintenta sin control. Prepara modos degradados antes de necesitarlos. Puedes posponer lotes, limitar exportaciones, reducir contexto no esencial, acotar resultados o mantener solo lectura y borradores. Conserva identidad, autorización, aislamiento, fuente de precios y revisión humana. Cada nivel necesita señal de entrada, funciones disponibles, mensaje, dueño, salida y conciliación. En Cerravi, la presión no autoriza inventar un precio ni mezclar monedas. La alternativa manual también requiere datos, instrucciones y capacidad real. Escala con la señal que representa el cuello de botella. Puede ser concurrencia, edad de cola, cuota, conexiones o una métrica combinada. CPU baja no demuestra capacidad si el sistema espera un CRM o un modelo externo. El escalamiento puede ser programado, automático o manual. Registra tiempo de provisión, calentamiento, drenaje, mínimo y máximo. Añadir instancias tarde no resuelve una ráfaga; mientras llegan necesitas admisión y degradación. Al reducir, drena trabajo y confirma que la demanda ya bajó. Prueba carga y saturación en un entorno autorizado con datos sintéticos. Reproduce una mezcla de lectura, recuperación, generación, herramientas, exportación y tareas de fondo. Ejecuta calentamiento, carga sostenida, ráfaga, escalamiento y recuperación. Después introduce dependencia lenta, cuota reducida, reintentos y un vecino ruidoso. Observa el recorrido, calidad, colas, costo y datos pendientes, no solo throughput. Conserva versión, configuración, modelo, distribución y resultado para poder comparar. Monitorea señales adelantadas y tardías. Adelantadas: cuota, concurrencia, conexiones, memoria, profundidad y edad de cola. Tardías: latencia, error, cancelación, tiempo de recorrido, calidad, tareas vencidas y abandono. Segmenta por organización, versión, operación y dependencia sin exponer contenido. Alerta cuando todavía existe una acción útil: limitar lote, añadir capacidad, reducir fan-out o activar modo degradado. Si la telemetría falla, declara incertidumbre. El silencio no prueba salud. Cada cambio relevante vuelve a abrir la hipótesis de capacidad. Un modelo, prompt, herramienta, índice, catálogo o límite de salida puede cambiar tiempo y costo sin tocar la interfaz. Incluye estimación, prueba comparable, impacto, cuota, señales, umbral de parada y rollback. Despliega por canary u olas cuando puedas aislar población y efecto. Expande solo si experiencia, calidad, costo y colas permanecen dentro de la envolvente. Un build verde no sustituye la observación del uso real. Mantén un registro de supuestos, demanda, límites, pruebas, margen, excepciones, costos y fecha de revisión. Producto aporta roadmap; negocio, periodos críticos; tecnología, medición y escalamiento; finanzas, presupuesto; seguridad y datos, límites que nunca deben degradarse. Revisa por calendario y ante crecimiento, campaña, nuevo proveedor, cambio de precio, incidente o cola persistente. El objetivo es conservar los recorridos importantes, reducir trabajo de forma explícita y recuperar capacidad sin perder control ni trazabilidad.

Un respaldo no está probado porque el archivo existe o porque una tarea aparece en verde. Una prueba de restauración demuestra que una copia concreta puede abrirse, corresponde con una versión conocida, conserva relaciones y permite reconstruir trabajo comercial sin introducir daños nuevos. El objetivo no es completar un comando. Es comprobar que los datos recuperados son técnicamente íntegros, comercialmente comprensibles y conciliables. Define una afirmación limitada: recuperar una base, un grupo de oportunidades, una configuración o actividad capturada durante una interrupción. Si la prueba recibió correcciones manuales no registradas, ese apoyo forma parte del resultado y no puede ocultarse. Empieza por el escenario y el alcance. Puede ser una eliminación accidental, un cambio masivo equivocado, corrupción, un despliegue defectuoso o un incidente ya contenido. Enumera cuentas, contactos, oportunidades, actividades, tareas, catálogo, propuestas, archivos, permisos, auditoría e integraciones incluidas. Distingue restauración completa, parcial y reconstrucción. Define participantes, duración, datos autorizados, criterios de éxito, detención y rollback. El ensayo no debe afectar producción, enviar correos, abrir Buyer Rooms, ejecutar webhooks ni cambiar sistemas externos. Si aparece un incidente real, detén el ejercicio y activa la respuesta operacional. Inventaría todo lo necesario para interpretar la copia. Registra fecha y zona horaria, tipo, alcance, tamaño, ubicación, cifrado, retención, propietario, versión de aplicación, motor, esquema, extensiones y método de creación. Conserva identificador y huella cuando aplique. Añade dependencias: configuración, almacenamiento de documentos, identidad, jobs, catálogo, colas e infraestructura. No copies secretos en el acta ni reutilices credenciales de producción. El respaldo debe cubrir datos, información del sistema y documentación suficiente. Recuperar tablas sin archivos, auditoría o configuración puede dejar una copia imposible de verificar o utilizar. Elige la última versión conocida como correcta, no simplemente la más reciente. Reconstruye una cronología con logs, alertas, despliegues, cambios administrativos, consultas, actividad de usuarios y marcas de backup. Separa hora del evento, detección, contención y respaldo. El daño puede comenzar antes de la alerta. Si existe riesgo de corrupción o código malicioso, seguridad confirma cuándo y cómo analizar la copia. Calcula el intervalo entre el punto seleccionado y el corte. Ese delta contiene altas y cambios que deberán recuperarse desde fuentes autorizadas. Un conteo total parecido no demuestra que no falte una oportunidad material. Restaura primero en un entorno aislado. Usa una red, cuenta o instancia separada, con acceso limitado, registros activos y vida útil definida. Deshabilita correo, webhooks, pagos, enlaces públicos, integraciones y jobs externos. Para prácticas frecuentes, prefiere datos sintéticos. Si necesitas una copia real para verificar escala o relaciones, define finalidad, minimización, autorización, cifrado, acceso, retención y eliminación. Registrar el enmascaramiento importa porque puede alterar unicidad. Comprueba espacio, versiones compatibles, límites de recursos y procedimiento para destruir el entorno antes de iniciar. Ejecuta el runbook por etapas: infraestructura mínima, configuración, esquema compatible, datos, archivos y servicios internos. Mantén toda salida externa bloqueada. Registra inicio, fin, operador, procedimiento, errores, reintentos, ayudas y cambios. Si el respaldo pertenece a otra versión, conserva el original y usa una ruta explícita de actualización. Detén la prueba si se pierde aislamiento, integridad o trazabilidad, si falta espacio, aparece una credencial no autorizada o sale tráfico hacia un tercero. Una prueba fallida bien documentada mejora la recuperación. Una restauración forzada que nadie puede repetir crea falsa confianza. Antes de abrir un dashboard, valida estructura e integridad. Comprueba versiones, migraciones, conteos por entidad, claves, restricciones, relaciones huérfanas, duplicados inesperados, archivos faltantes, fechas, zonas horarias, codificación, permisos y auditoría. Ejecuta invariantes: cada oportunidad tiene una cuenta válida; las tareas conservan responsable y negocio; las propuestas mantienen versión y moneda; el historial conserva orden; los propietarios existen o quedan marcados para reasignación. Separa errores del respaldo, de la restauración, de compatibilidad y problemas que ya existían. Conserva lo esperado, lo observado y diferencias reproducibles. Después valida recorridos comerciales. Selecciona una cuenta con varios contactos, una oportunidad activa, un negocio cerrado, una tarea futura, actividad histórica, una propuesta versionada, un producto con precio aprobado, un usuario inactivo y registros en MXN y USD. Recorre cada relación y pide a Ventas, RevOps y Datos que confirmen significado. Una etapa puede existir y estar equivocada. Una nota puede abrirse y perder autor. Un monto puede conservarse con catálogo incorrecto. Los enlaces de prueba no deben ser públicos. La actividad de Buyer Room no demuestra identidad, aceptación, contrato, pago o intención. Construye el delta antes de conciliar. Inventaría altas, cambios, cierres, notas, tareas, reasignaciones, propuestas, aprobaciones y comunicaciones posteriores al punto recuperado. Para cada elemento conserva procedencia, hora real, hora de captura, responsable y confianza. Define fuente de verdad por campo: el CRM puede gobernar etapa y propietario; el catálogo aprobado gobierna producto, moneda e importe; una comunicación confirmada gobierna un siguiente paso. La fuente más nueva no siempre prevalece si proviene de una hoja incompleta o de la automatización que causó el problema. Usa un corte claro y recalcula si producción sigue avanzando. Clasifica conflictos como coincidencia, alta nueva, actualización única, cambio concurrente, duplicado, relación faltante, valor inválido o decisión humana. Define regla, responsable y evidencia por categoría. Usa identificadores estables y trata las claves de negocio con cuidado: correo, nombre de empresa o título de oportunidad pueden cambiar y no siempre son únicos. Los campos materiales exigen revisión proporcional: producto, cantidad, precio, moneda, impuestos, vigencia, etapa, fecha de cierre, propietario, permiso y acceso público. Cerravi no inventa un importe ausente ni convierte monedas sin una regla aprobada. Ensaya la conciliación en la copia aislada. Transforma un duplicado del delta y ejecuta un dry run o una importación controlada. Carga primero entidades padre y después dependientes: cuentas, contactos, oportunidades, actividades, tareas, propuestas y archivos según el modelo real. Conserva el mapa entre origen y destino, resultados y rechazos. Empieza con un lote pequeño y representativo. Comprueba que repetirlo sea idempotente y no cree duplicados. Aprobar el ensayo no autoriza producción. Una ejecución real necesita respaldo vigente, ventana, control de cambios, verificación y rollback propios. Mide cada tramo: preparar acceso, localizar copia, restaurar, iniciar, validar técnicamente, validar negocio, construir delta y conciliar. Compara solo con RTO y RPO internos dentro del alcance probado. Reporta ayuda extraordinaria, pasos manuales y periodos excluidos. Mide objetos esperados y recuperados, relaciones válidas, archivos accesibles, conflictos, rechazos, duplicados y pendientes con denominadores claros. Un porcentaje alto puede ocultar todas las propuestas activas de una cuenta crítica. Conserva acta, versión, cronología, consultas, muestra, resultados, decisiones y acciones, limitando datos personales y secretos. Cierra con una decisión limitada: aprobado para el alcance probado, aprobado con condiciones, repetir una fase o no aprobado. Registra versión, escenario, punto recuperado, entorno, objetivos observados, limitaciones y vigencia. Cada brecha recibe responsable, fecha, evidencia y criterio de retest. Los cambios de esquema, proveedor, volumen, identidad o proceso pueden exigir otra prueba. Cerravi organiza contexto comercial y Copilot propone siguientes pasos, pero no envía ni cambia etapas automáticamente. Cada organización valida su respaldo, recuperación, RTO, RPO y obligaciones. La prueba no es una certificación ni una garantía universal de disponibilidad o integridad.

Un plan de continuidad para un AI Sales Copilot protege el trabajo comercial esencial cuando falla el copiloto, una fuente, integración, identidad o proveedor. No intenta conservar todas las funciones a cualquier costo. Puede reducir el servicio, suspender inteligencia artificial y volver temporalmente a un proceso humano si eso protege clientes, datos y compromisos. NIST AI RMF recomienda comprobar contingencia, bypass, respaldo y desactivación de sistemas críticos. NIST SP ochocientos guion treinta y cuatro organiza la planificación alrededor de prioridades, recuperación y pruebas. Son referencias para adaptar, no un SLA ni una certificación de Cerravi. La pregunta rectora es sencilla: si la IA desaparece durante una jornada crítica, ¿qué trabajo debe continuar, con qué controles y durante cuánto tiempo puede sostenerse sin crear un riesgo mayor? Define escenarios y fronteras antes de asignar tiempos. Delimita organización, proceso, caso de uso, versión, entorno, equipos, regiones, monedas y canales. Distingue indisponibilidad total, calidad degradada, datos atrasados, catálogo no vigente, identidad fallida, integración interrumpida, proveedor inaccesible y una pausa deliberada por incidente. Cada condición puede necesitar otra respuesta. Registra qué plan relacionado toma el control. Un incidente de seguridad puede exigir contención y preservación de evidencia antes de continuidad. Una falla de infraestructura puede depender del plan tecnológico. Separa componentes reemplazables del servicio completo. El modelo puede fallar mientras CRM y catálogo siguen disponibles. Una integración puede detenerse sin apagar la lectura del pipeline. Diseñar por componente evita que una falla localizada elimine trabajo que todavía es seguro. Analiza impacto por actividad y por tiempo. Revisa preparar una propuesta, validar precios, responder una consulta, registrar acuerdos, compartir una Buyer Room y producir Forecast. Para cada actividad identifica volumen, ventana crítica, datos necesarios, 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 catálogo durante un cierre puede detener propuestas. Varios días sin historial pueden producir duplicados o compromisos contradictorios. Separa productividad, ingreso diferido, experiencia del cliente, datos, seguridad, privacidad y obligaciones aplicables. No conviertas cualquier inconveniente en crítico. Prioriza por consecuencia y horizonte temporal. Conserva supuestos y fecha de corte, porque la tolerancia puede cambiar por temporada, campaña, región o concentración en una sola persona. Clasifica funciones por niveles de servicio. Operación normal conserva capacidades aprobadas. Degradada mantiene el flujo con menos fuentes o automatización. Mínima protege tareas esenciales mediante controles humanos. Suspendida detiene una función que ya no puede operar dentro de tolerancia. Cada nivel necesita disparador, público, funciones disponibles, límites, responsable y salida. Una etiqueta amarilla sin comportamiento técnico u operativo no ayuda. Si se desactiva una recomendación, la interfaz y la capacitación deben indicar qué falta y qué proceso sustituye el paso. Degradado tampoco significa sin control. Puede exigir menor volumen, doble revisión, plantillas bloqueadas, datos de solo lectura o prohibición de compartir externamente. La capacidad manual define cuánto trabajo puede aceptar el equipo. Una cola ilimitada no es continuidad; es una falla diferida. Usa tres objetivos sin confundirlos. El tiempo máximo tolerable de interrupción indica cuándo el impacto deja de ser aceptable para una actividad. RTO orienta en cuánto tiempo se busca restaurar un nivel definido. RPO expresa cuánto atraso o pérdida de datos puede tolerarse desde el último punto recuperable. Define valores por proceso y escenario. Un único número para todo el producto oculta diferencias. Relaciona cada objetivo con fuente, dueño y capacidad observada. Si recuperar acceso depende de una persona sin suplencia o restaurar datos nunca se probó, el objetivo sigue siendo una aspiración. Separa tiempo de detección, decisión, activación, ejecución y validación. RTO y RPO internos no son promesas públicas, garantías ni términos contractuales. Los compromisos externos requieren alcance, exclusiones, medición y revisión jurídica y comercial. Mapea dependencias y elimina el respaldo imaginario. Traza CRM, base de datos, catálogo, archivos, identidad, correo, almacenamiento, 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 alguien capaz de operarla. Busca puntos únicos: administrador, cuenta propietaria, región, clave, proveedor, exportación o plantilla. Dos servicios pueden parecer redundantes y depender de la misma nube, identidad o fuente. Verifica cada respaldo: alcance, frecuencia, cifrado, acceso, retención, integridad y restauración. Una exportación manual puede ser suficiente para un proceso limitado si conserva estructura, fecha y responsable. No copies información personal o comercial sin finalidad, autorización y protección adecuadas. Diseña un modo manual que pueda sostenerse. 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: casos por hora, prioridad, condición de cierre de cola y apoyo necesario. No traslades silenciosamente una carga imposible a ventas u operaciones. Mantén mínimo privilegio y revisión de destinatario, versión, producto, cantidad, impuestos, vigencia y moneda. Una hoja temporal requiere acceso, identificadores, fecha, dueño, conciliación y eliminación. El modo manual preserva el mínimo seguro; no autoriza atajos permanentes ni datos fuera del alcance aprobado. Define quién activa, comunica y cambia de nivel. Usa disparadores observables: salud técnica, errores, 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, salvo 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. La reanudación puede exigir más evidencia. La comunicación indica audiencia, hecho confirmado, impacto conocido, alternativa, acción esperada, próxima 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 la función competente. Recupera por etapas y valida antes de ampliar. El runbook comienza con precondiciones: condición delimitada, componente disponible, configuración correcta, datos recuperables, secretos vigentes y personal autorizado. Restaura primero en un entorno controlado. Ejecuta smoke tests, valida casos representativos y comprueba observabilidad. Después vuelve por etapas: lectura, asistencia interna, borradores, funciones externas y volumen normal. El orden depende del riesgo. Cada etapa necesita rollback y condición de parada. Una respuesta saludable del servidor no demuestra catálogo vigente, permisos correctos, monedas separadas o calidad suficiente para compartir una propuesta. Conserva versión, datos, pruebas, aprobador, hora y limitaciones. Aplica monitoreo reforzado. La recuperación técnica y la continuidad del negocio se cierran por separado, porque pueden quedar registros por conciliar, clientes por informar o decisiones por revisar. Reconcilia los datos creados durante la interrupción. Inventaría propuestas, tareas, contactos, notas, etapas, precios, aprobaciones y comunicaciones temporales. Usa identificadores para detectar duplicados y define la fuente de verdad por campo. No importes en masa antes de comparar versiones, propietarios, fechas, monedas y relaciones. Clasifica coincidencia, dato nuevo, cambio concurrente, duplicado, dato inválido o decisión que requiere revisión. Asigna resolución humana cuando importa el contexto comercial. Conserva una bitácora de importación, rechazo y corrección. El archivo temporal se elimina después de validar conciliación y según la retención aplicable. Recalcula métricas y Forecast solo cuando exista cobertura suficiente. Marca periodos incompletos. Una actividad atrasada conserva 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 otra pregunta. El tabletop descubre autoridad ambigua. Una restauración comprueba archivos y tiempos. Un turno manual revela capacidad y carga. Una conciliació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 clientes para demostrar preparación. Mide detección, decisión, activación, capacidad, recuperación, validación, conciliación y comunicación. Registra ayuda extraordinaria. Si alguien 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 cuando cambien modelo, fuente, instrucciones, integración, proveedor, región, permiso, identidad, equipo, volumen o autoridad. Incidentes, near misses, 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 métricas verdes. Cada acción conserva dueño, fecha, evidencia y criterio de cierre. Una prueba vencida no demuestra que la recuperación fallará, pero sí que la afirmación ya no está sustentada con la vigencia acordada. En Cerravi, Copilot organiza contexto y propone siguientes pasos, pero no envía mensajes ni cambia etapas automáticamente. Si no está disponible, el proceso puede continuar con revisión humana, CRM y plantillas aprobadas según la configuración de la empresa. 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 y evidencia dentro de su alcance, pero esta guía no publica un SLA, RTO o RPO contractual. Cada organización valida arquitectura, proveedores, respaldo, obligaciones y recursos con sus funciones de continuidad, seguridad, privacidad, legal y riesgo.

Un ejercicio tabletop de incidentes de inteligencia artificial ensaya decisiones antes de que el tiempo y el impacto sean reales. Es una conversación guiada sobre una situación ficticia. No desconecta servicios, no introduce fallas en producción y no necesita secretos ni datos reales de clientes. Las personas explican qué harían, quién decidiría, qué evidencia consultarían y cómo coordinarían la respuesta. CISA publica paquetes con funciones para planificación, facilitación, evaluación, participantes, feedback y after-action report. NIST conecta preparación, respuesta, recuperación y mejora con la gestión continua del riesgo. Son referencias para adaptar, no una certificación de Cerravi ni un guion obligatorio. El resultado útil no es una actuación perfecta. Es un registro honesto de decisiones, demoras, contradicciones y capacidades que todavía necesitan evidencia o prueba. Define pocas preguntas observables. Por ejemplo: quién puede pausar una función, cuánto tarda el equipo en reconocer alcance, qué activa el modo manual, cómo se conserva evidencia y quién aprueba una comunicación externa. Mejorar la preparación es demasiado amplio para evaluar. Delimita organización, proceso comercial, sistema, versión, entorno, integración, población, idioma y región. Indica qué queda fuera. Si el copiloto depende del CRM, un catálogo, un proveedor de modelos y correo, aclara qué componente está disponible o degradado en cada momento. Selecciona participantes por las decisiones que deben tomar. Ventas, producto, operación y seguridad pueden cubrir un ejercicio inicial. Un escenario con datos personales, contratos o comunicación pública puede necesitar privacidad, legal, soporte y comunicación. El objetivo no es llenar la sala, sino reunir autoridad y conocimiento pertinentes. Construye el escenario desde un riesgo plausible. Revisa el registro de riesgos, incidentes anteriores, near misses, hallazgos, cambios y dependencias. Evita copiar una amenaza genérica de otra industria. El caso debe pertenecer al recorrido observado y conservar suficiente incertidumbre para investigar. Un ejemplo para ventas B2B comienza 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 abre decisiones sobre detección, alcance, contención, datos, comunicación, modo manual y recuperación. Usa nombres, precios, conversaciones y documentos sintéticos. Marca cada pantalla como material de ejercicio. Si una pregunta requiere una prueba técnica, prográmala después en un entorno aislado y con autorización específica. Separa funciones. El patrocinador autoriza alcance y recursos. Diseño coordina objetivos, escenario y logística. Facilitación presenta información, cuida el tiempo y pregunta sin conducir a una conclusión. Control administra el mundo simulado y decide cuándo entregar cada inject. Los participantes actúan desde su función real. Observadores y evaluadores comparan hechos contra los objetivos. Una persona registra cronología, decisiones y pendientes. Nombra también la autoridad que existiría en un incidente: incident commander o equivalente, investigación técnica, negocio, seguridad, privacidad, legal, soporte, comunicación y autoridad de reanudación. En equipos pequeños se pueden combinar funciones, pero debe quedar visible. Quien diseñó un control no debería ser la única persona que afirma que funcionaría. La separación reduce puntos ciegos y deja a facilitación concentrarse en la conversación. Antes de jugar, acuerda reglas de seguridad. Explica propósito, alcance, tiempo, confidencialidad, canales y forma de pedir información. Nadie ejecutará cambios reales, contactará clientes ni probará producción. Las acciones se expresan como simuladas y se anotan junto con el acceso o aprobación que requerirían. Usa una palabra clara para pausar. Si alguien descubre un incidente real, una exposición activa o una condición que exige intervención, detén la simulación y activa el proceso operacional. No mezcles evidencia ficticia y cronología real. Se evalúan rutas, criterios, autoridad y capacidad, no la memoria o desempeño teatral de una persona. Aun así, no aceptes alguien avisaría o normalmente funciona. Pregunta quién, por qué canal, con qué dato, en cuánto tiempo y qué ocurre si esa persona o sistema no está disponible. Prepara artefactos y evidencia. Reúne el plan de incidentes, contactos, RACI, arquitectura, inventario, niveles de riesgo, dependencias, procedimientos de pausa, modo manual, recuperación y comunicación. Marca versiones y fechas. Crea un canal de ejercicio separado, una bitácora y una carpeta con acceso controlado. Diseña tarjetas para decisiones materiales: clasificar, contener, escalar, comunicar, recuperar y reanudar. Cada tarjeta conserva hora simulada, información disponible, autoridad, opción elegida, motivo y evidencia pendiente. Ensaya logística con facilitación y control. Comprueba injects, enlaces, permisos, temporizador, subtítulos y un canal privado para ajustar el ritmo. Una brecha documental es un hallazgo posible, no una razón para improvisar que el documento existe. Si falta un contacto o acceso material, registra la dependencia y continúa con un supuesto explícito. 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 o log resumido. Cada inject debe servir a un objetivo. Diseña una línea de tiempo con condición de entrega, respuesta que deseas observar, posibles ramas y punto de evaluación. No fuerces el guion si el grupo toma una decisión razonable que cambia el recorrido. 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 inventes una sola respuesta correcta cuando existen varias opciones válidas. Evalúa si la decisión tuvo autoridad, información suficiente, trazabilidad y proporción frente al impacto conocido. Durante la sesión, conduce decisiones y no una presentación. Da el contexto mínimo y deja trabajar al grupo. Cuando aparezca una acción, pregunta quién la inicia, quién decide, qué herramienta utiliza, qué dato falta y qué alternativa existe. Si la conversación se desvía, resume el asunto y llévalo a un parking lot. Registra tiempo real y tiempo simulado por separado. Una discusión de veinte minutos puede representar una decisión que el escenario necesita en cinco. Esa diferencia orienta una mejora, pero se evalúa contra expectativas definidas por la organización, no contra un número inventado. Pide que todos usen procesos actuales, no una organización ideal. Si una aprobación no tiene suplente, simula indisponibilidad. Si dos funciones creen tener autoridad final, conserva el conflicto como observación. Resolverlo por conveniencia escondería el aprendizaje principal. Veamos un caso. A las nueve diez, una gerente reporta que una propuesta generada muestra un importe que no encuentra en el catálogo vigente. El equipo debe clasificar el reporte, identificar cuenta, versión, fuente y documento, y limitar nuevos envíos sin destruir evidencia. A las nueve veinticinco aparece una segunda propuesta y se descubre una importación incompleta del catálogo. A las nueve cuarenta un cliente pregunta si el importe es válido. A las diez el proveedor confirma que el modelo no cambió. A las diez veinte liderazgo pide restablecer el flujo por una negociación importante. Una respuesta sólida puede limitar generación o envío afectados, conservar documentos y logs, verificar catálogo y permisos, activar cotización manual, comunicar solo hechos y exigir regresión antes de reanudar. Descartar al proveedor no elimina automáticamente una falla de integración o proceso. Prueba cuatro capacidades conectadas. La contención reduce exposición sin borrar evidencia. Pregunta si puede limitarse una función, fuente, versión, integración, usuario o población, y quién tiene acceso para hacerlo. El modo manual conserva el trabajo esencial. Define tareas, plantilla, catálogo, revisión, conciliación y tiempo máximo sostenible. Una alternativa nunca probada sigue siendo una hipótesis. La comunicación separa hechos, inferencias y desconocidos; identifica audiencias, aprobación, canal, frecuencia y contacto. No prometas causa, alcance o recuperación antes de tener evidencia. La reanudación necesita corrección, regresión, verificación del alcance, riesgo residual aceptado, monitoreo reforzado y autoridad explícita. La ausencia de nuevas alertas no basta. Cada decisión debe conservar motivo, dueño, límites y una condición para revisarla o volver a pausar. Cierra con un hotwash inmediato. Pregunta qué funcionó, qué generó espera, qué dato o acceso faltó, qué supuesto resultó incorrecto y qué conviene conservar. Incluye participantes, observadores, control y facilitación. El hotwash captura memoria fresca, pero no obliga a aceptar una conclusión sin contraste. Después redacta el after-action report: alcance, objetivos, escenario, participantes, cronología, decisiones, fortalezas, observaciones, evidencia y limitaciones. Distingue una falla observada, una capacidad declarada pero no comprobada y una mejora deseable. No escribas comunicación deficiente. Especifica qué audiencia, mensaje, autoridad, canal o tiempo quedó ambiguo. Relaciona cada observación con objetivo, riesgo, control, proceso o dependencia. La redacción busca mejorar el sistema, no repartir culpa. Convierte observaciones en trabajo verificable. Cada acción necesita responsable con autoridad, fecha, dependencia, resultado esperado, evidencia y criterio de cierre. Separa contención inmediata, corrección de procedimiento, mejora técnica, capacitación y decisión de riesgo. Actualizar un documento no demuestra que el nuevo recorrido funcione; cierra con una muestra, prueba o ejercicio focalizado. Prioriza por impacto potencial, exposición actual y capacidad para intervenir. No conviertas todo en capacitación cuando la causa es un permiso, dato o diseño. Mide tiempo hasta triage y decisión, dependencias ausentes, acciones vencidas, recurrencia, cobertura de retest y cambios que llegaron a controles. Estas medidas describen preparación bajo el escenario observado. No son una probabilidad de seguridad. Repite cuando cambien sistema, autonomía, proveedor, datos o autoridad, o cuando una falla real revele un riesgo material. 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, 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 utiliza reglas transparentes del CRM y no garantiza cierres. El ejercicio debe comprobar estas fronteras en la versión y configuración observadas, sin convertirlas en supuestos. Cerravi puede aportar registros y evidencia dentro de su alcance. No decide la clasificación legal de un incidente, no sustituye revisión de seguridad, privacidad o legal y no certifica la preparación de una organización. Integraciones y automatizaciones añadidas por cada empresa cambian el recorrido y requieren su propia práctica.

Evaluar la madurez de gobernanza de inteligencia artificial no significa otorgar prestigio ni producir una nota para una presentación. Significa comprobar si la organización puede tomar y sostener decisiones de IA de forma consistente. Observa prácticas, responsables, evidencia, resultados y capacidad para aprender. Una empresa puede tener políticas sofisticadas y depender todavía de una sola persona, revisiones tardías o controles sin prueba. NIST organiza la gestión de riesgo alrededor de Govern, Map, Measure y Manage; GAO propone prácticas sobre gobierno, datos, desempeño y monitoreo. Estas referencias ayudan a elegir capacidades, pero no crean una calificación oficial de Cerravi ni prescriben una escala universal. El resultado útil es un mapa de lo que funciona, lo que permanece informal, la evidencia faltante y los próximos movimientos. La madurez crea valor cuando cambia una condición real, no cuando solo mejora un número. Define el alcance antes de abrir el cuestionario. Especifica organización, unidad, proceso, producto, caso de uso, versión, ambiente, región y periodo. Una vista corporativa puede describir capacidades comunes, pero no debe ocultar que ventas, soporte y recursos humanos tienen exposiciones distintas. Tampoco mezcles un piloto aislado con una función en producción que toca clientes, dinero o datos sensibles. Declara qué decisión apoyará el diagnóstico: priorizar inversión, preparar producción, distribuir autoridad, corregir un hallazgo o revisar si el modelo operativo todavía escala. Registra exclusiones, dependencias y fecha de corte. Si identidad o respuesta a incidentes pertenecen a una plataforma común, incorpora su evidencia y dueño. Cuando una dependencia material no puede observarse, marca no evaluado. No la conviertas en madura por herencia ni en inexistente por falta de acceso. Evalúa capacidades completas, no cantidad de documentos. Mandato y autoridad muestran quién puede decidir, ejecutar, contener y responder. Inventario y clasificación delimitan qué existe y qué tratamiento necesita. Datos y terceros cubren origen, acceso, calidad, condiciones y dependencias. Evaluación y controles comprueban el comportamiento del sistema y sus barreras. Operación observa señales, cambios, incidentes, continuidad y retiro. Evidencia conserva la razón de las decisiones. Personas y capacidad sostienen todo lo anterior. Puedes revisar valor y adopción para confirmar un propósito legítimo, pero un beneficio comercial no compensa un control crítico fallido. Una buena disponibilidad tampoco eleva por sí sola la madurez de privacidad, seguridad o supervisión humana. Cada dimensión necesita una pregunta estable, una definición y un dueño de la información. Describe niveles mediante hechos observables. Una escala práctica puede usar cinco estados: ad hoc, repetible, definido, medido y adaptativo. Ad hoc depende de reacción e individuos. Repetible conserva patrones en algunos casos, pero tiene cobertura irregular. Definido cuenta con criterios, responsables y rutas compartidas. Medido usa evidencia operacional para comprobar cobertura y resultados. Adaptativo cambia controles, capacidad y delegación a partir de señales verificables. Los nombres son una convención interna, no un estándar universal. Microsoft publica modelos propios para adopción de agentes y reconoce que una organización puede operar en niveles distintos según criticidad. Úsalos como referencia contextual, no como certificado o benchmark general. Escribe descriptores para cada dimensión. Medido en inventario exige reconciliar contra fuentes reales. Medido en controles exige pruebas y cobertura, no solo una biblioteca. Separa diseño, implementación, operación y eficacia. Una política demuestra diseño. Una configuración, asignación o flujo aprobado puede demostrar implementación. Logs, tickets, minutas y muestras muestran operación. Resultados contra criterios definidos ayudan a evaluar eficacia. No saltes de existe un documento a funciona. Usa registros del sistema, pruebas reproducibles, decisiones fechadas y muestras vinculadas a versión. Las entrevistas explican contexto, pero no sustituyen evidencia cuando el comportamiento puede observarse. Una demostración preparada comprueba un recorrido puntual; no demuestra cobertura continua. Etiqueta evidencia vigente, vencida, parcial, contradictoria o no disponible. Conserva procedencia, propietario, periodo, alcance y limitaciones. Si el acceso está restringido, permite una verificación proporcional, pero no conviertas la confidencialidad en una afirmación automática de eficacia. Combina documentos, muestras y conversaciones. Empieza con inventario, políticas, matrices, evaluaciones, riesgos, controles, cambios, incidentes y reportes operativos. Selecciona una muestra por nivel de riesgo, etapa, unidad y resultado. Recorre decisiones reales desde intake hasta operación o retiro; no elijas solo ejemplos exitosos. Entrevista a patrocinio, negocio, producto, operación, datos, seguridad, privacidad, riesgo, soporte y usuarios cuando corresponda. Pregunta por el último caso: qué ocurrió, quién decidió, qué evidencia faltó, qué pasó al vencer una acción y cómo se habría detenido el sistema. Contrasta respuestas con registros sin asumir mala fe ante una diferencia. Cierra con un taller breve para validar hechos, desacuerdos y dependencias. La persona facilitadora no debe presionar por una nota alta ni borrar una discusión material mediante promedio. Asigna el nivel más alto que la evidencia sustenta, no el que el equipo espera alcanzar. Si una capacidad está definida pero opera en una parte de la cartera, registra nivel, segmento y cobertura. Usa no evaluado cuando falta acceso o el recorrido queda fuera del alcance. No conviertas lo desconocido en cero ni en aprobación implícita. Evita promediar dimensiones heterogéneas. Una media favorable puede esconder que nadie tiene autoridad para contener o que una fuente crítica carece de permiso. Presenta un perfil por capacidad, dependencias y bloqueadores. Si dirección necesita un resumen, muestra estados y decisiones materiales, no una probabilidad inventada de seguridad. Dos evaluadores deberían llegar a conclusiones comparables con la misma evidencia. Para eso hacen falta ejemplos, reglas para cobertura parcial, vigencia y calibración. Ajusta la expectativa al riesgo sin rebajar el mínimo. Un asistente interno, reversible y sin acciones puede usar patrones más ligeros que una función externa que modifica precios, permisos o decisiones. El nivel de riesgo orienta independencia, profundidad, cobertura y frecuencia, pero no elimina dueño, propósito, datos autorizados ni ruta de incidente. Observa también exposición agregada. Varios casos pequeños pueden depender del mismo proveedor, conector, modelo o revisor y crear concentración. Una unidad puede parecer madura porque recibe controles centrales mientras la función compartida está saturada o carece de suplencia. La meta tampoco tiene que ser el nivel máximo. Una capacidad definida y eficaz puede ser suficiente para una exposición acotada. Perseguir sofisticación innecesaria consume recursos. Justifica el estado objetivo por riesgo, escala, obligaciones aplicables y costo de sostenerlo. Convierte cada diferencia en una brecha cerrable. Describe capacidad, alcance, evidencia, consecuencia, causa probable, dependencia y urgencia. No escribas mejorar monitoreo. Indica qué señal falta, qué escenario queda ciego, qué recorrido necesita cobertura y qué decisión depende de ella. Prioriza por exposición y capacidad para intervenir, no por facilidad para subir una nota. Atiende primero falta de autoridad, condiciones fuera de tolerancia, datos o acciones sin límite, controles críticos fallidos, incidentes repetidos y evidencia que contradice una aprobación. Separa contención, corrección y mejora estructural. La contención reduce exposición ahora. La corrección restaura el requisito. La mejora cambia el sistema para evitar recurrencia o ampliar capacidad. Una plantilla nueva no cierra una brecha operacional hasta que se utiliza, verifica y sostiene. Construye un plan de noventa días basado en resultados. Agrupa acciones en estabilizar, definir, comprobar y escalar. Primero contiene exposiciones, asigna dueños y corrige rutas críticas. Después documenta estándares mínimos y conecta artefactos. Luego prueba controles y operación sobre una muestra. Automatiza o delega solo lo que ya tiene criterio estable. Cada iniciativa necesita resultado verificable, responsable con autoridad, fecha, recursos, dependencia, criterio de cierre y evidencia esperada. Si condiciona continuidad, agrega fecha de pausa o límite técnico; una celda vencida no contiene nada. Equilibra quick wins con capacidades base. Un dashboard aporta visibilidad, pero no reemplaza inventario ni fuentes confiables. Capacitar no corrige un permiso excesivo. Automatizar intake no resuelve derechos de decisión. Ordena dependencias para no digitalizar una ambigüedad. Establece una línea base con fecha, alcance y confianza. Revisa acciones según riesgo y reevalúa cuando cambien estructura, plataforma, proveedor, autonomía, datos, región o exposición. Un incidente, un control fallido o un hallazgo material puede reabrir una capacidad antes del calendario. Compara periodos con las mismas definiciones y explica si el movimiento proviene de evidencia nueva, cobertura ampliada, criterio corregido o mejora real. Descubrir una brecha puede bajar el nivel y demostrar al mismo tiempo mejor capacidad de detección. No castigues la transparencia ni premies ausencia de reportes. Observa cierres a tiempo, reincidencia, cobertura, acciones que modificaron controles y dependencia de excepciones. Mide también costo, espera y carga sobre especialistas. La evaluación debe mejorar el gobierno, no convertirse en una ceremonia anual que compite con gobernar. Evita atajos que fabrican madurez. No copies un cuestionario sin adaptarlo, no aceptes autoevaluación sin contraste en asuntos materiales y no midas éxito por documentos producidos. Evita una sola nota corporativa, colores sin evidencia y comparaciones con organizaciones cuyo alcance desconoces. No presentes el diagnóstico como auditoría, certificación o determinación de cumplimiento si no tiene mandato, independencia y procedimientos para ello. La evaluación interna puede preparar una revisión posterior, identificar preguntas legales y mejorar evidencia, pero permanece dentro de su alcance. Tampoco uses madurez para justificar más autonomía por defecto. Una organización puede mejorar inventario, observabilidad y respuesta mientras conserva revisión humana en decisiones comerciales. La capacidad para controlar una función no demuestra que el sistema deba recibir más autoridad. En Cerravi, la evaluación puede comprobar dueño por oportunidad y caso, catálogo vigente, permisos, revisión humana, trazabilidad de cambios y rutas para feedback e incidentes. Copilot organiza contexto y propone siguientes pasos; no envía mensajes ni cambia etapas automáticamente. Las propuestas utilizan productos y precios cargados. Si falta un importe, se confirma y no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. Una apertura de Buyer Room aporta actividad, pero no demuestra identidad, aceptación, contrato, pago o intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. Verifica estos límites en la versión y configuración observadas. Una integración añadida por la empresa puede cambiar el recorrido y necesita evaluación propia. Cerravi aporta funciones y evidencia dentro de su alcance; no certifica madurez, cumplimiento ni eficacia general de la gobernanza de una organización.

Una revisión periódica de gobernanza de un AI Sales Copilot vuelve a comprobar una decisión que puede haber envejecido. Después del lanzamiento cambian el modelo, las instrucciones, las fuentes, los permisos, los usuarios y la forma de utilizar las sugerencias. La aprobación anterior no demuestra que la versión actual conserve el mismo riesgo. El review reúne evidencia para decidir si propósito, alcance, responsables y controles siguen siendo adecuados. No sustituye el monitoreo diario, la respuesta a incidentes, el control de cambios ni una evaluación especializada. Los conecta. Su resultado no es una certificación general, sino una resolución acotada: continuar, corregir, limitar, escalar, reevaluar o retirar. Define el ritmo según el riesgo y los cambios, no por costumbre. Un asistente interno y reversible puede admitir un ciclo ligero. Un sistema externo, con datos sensibles, autonomía o decisiones materiales necesita mayor frecuencia y profundidad. Microsoft incluye una revisión trimestral de madurez para agentes de alto riesgo dentro de su propio modelo, pero el trimestre no es una obligación universal. Justifica el intervalo y registra una fecha máxima. Añade disparadores extraordinarios: cambio de modelo, proveedor, fuente, permiso, audiencia, región, autonomía o volumen; incidente; control fallido; excepción relevante; obligación nueva; o evidencia que contradiga un supuesto. El calendario no debe retrasar una revisión que ya es necesaria. Fija la unidad antes de pedir reportes. Identifica caso de uso, producto, versión, ambiente, población y periodo observado. Vincula la ficha de inventario, el responsable, el proceso comercial, las fuentes, modelos, prompts, herramientas, integraciones, permisos y puntos de revisión humana. Separa lo activo, pausado, experimental y retirado. Incluye componentes de terceros y automatizaciones construidas alrededor del copiloto. Declara qué queda fuera. Si revisas el flujo de propuestas pero no el enriquecimiento de contactos, escríbelo y asigna otro review. El paquete de entrada debe contener línea base, alcance autorizado, nivel de riesgo, evaluación vigente, responsables, cambios, riesgos, controles, excepciones, incidentes, feedback y decisiones pendientes. Reconcilia esa línea base con lo que realmente opera. Compara modelo, instrucciones, reglas, fuentes, índices, herramientas, permisos, identidades, integraciones, regiones, retención y población. Busca también recorridos auxiliares: exportaciones, hojas, extensiones, conectores, cuentas compartidas o prompts que el equipo utiliza fuera del proceso previsto. No castigues el reporte de shadow AI. Devuélvelo al inventario, evalúa la necesidad y decide si se autoriza, rediseña o retira. Clasifica cada diferencia como confirmada, justificada, pendiente o no autorizada. No cambies retrospectivamente la documentación para ocultarla. Una desviación temporal usa una excepción; un impacto activa incidentes; una modificación del sistema abre control de cambios. Reabre la clasificación cuando cambian las consecuencias. Revisa autoridad, audiencia, datos, dinero, decisiones, escala, reversibilidad, propagación, dependencia y posibilidad de supervisión significativa. No reduzcas el nivel porque no aparecieron incidentes. Contrasta beneficios y posibles daños con evidencia nueva. Pregunta quién recibe valor y quién absorbe errores, demora, vigilancia o trabajo adicional. Comprueba si la revisión humana todavía permite corregir o se volvió una confirmación automática por carga. Actualiza escenarios, impacto y riesgo residual cuando cambien contexto, exposición, control o incertidumbre. Conserva el razonamiento anterior. La decisión puede mantener el nivel, elevarlo, reducirlo con evidencia o dividir un caso amplio en recorridos distintos. Comprueba cada control, no solo su existencia documental. Conecta riesgo, control, dueño, mecanismo, cobertura, prueba, resultado, fecha y evidencia. Distingue diseñado, implementado, operativo y eficaz para el escenario. Una política publicada demuestra intención, pero no prueba que el acceso se bloquee o que un precio se valide. Muestrea autorización antes de recuperar datos, validación de objetos y argumentos, separación de monedas, vigencia de fuentes, logs, alertas, fallback, pausa y reversión. Revisa también capacidad y suplencia de quienes aprueban. Si una prueba falla, registra alcance, causa provisional, contención, residual y decisión. Una muestra limitada debe declarar qué permite concluir y qué no. Lee las señales de producción dentro de su contexto. Resume disponibilidad, errores, latencia, calidad, groundedness, correcciones, rechazos, accesos, escalaciones, quejas, incidentes y adopción. Segmenta por versión, rol, equipo, caso y periodo cuando sea necesario. Usa denominadores. Diez correcciones entre veinte usos no significan lo mismo que diez entre veinte mil. Distingue una alerta, una salida visible, un borrador guardado y una comunicación compartida. No confundas ausencia de reportes con ausencia de problemas. Comprueba si el canal es accesible y si las personas entienden qué reportar. Combina telemetría, muestreo, evaluaciones, soporte y feedback sin convertir el proceso en vigilancia del vendedor. Revisa excepciones, terceros e incidentes como un portafolio. Lista excepciones activas, próximas a vencer, renovadas y cerradas. Confirma alcance, controles compensatorios y cierre técnico. Varias excepciones pequeñas sobre el mismo modelo, permiso o revisor pueden crear una exposición agregada. Comprueba cambios de proveedor, subprocesador, modelo, ubicación, términos, soporte y capacidad de salida. No repitas toda la diligencia si la evidencia sigue vigente; confirma fecha, alcance y disparadores. Agrupa incidentes, defectos y feedback por causa y versión. Varios casos leves pueden revelar deriva o deuda sistémica. Verifica que las acciones posteriores llegaron a controles o regresiones y no se cerraron solo porque el ticket dejó de moverse. Convoca una reunión de decisión, no una lectura de documentos. Distribuye el paquete antes y marca preguntas abiertas. Participan solo las funciones necesarias: dueño del caso, producto, operación, dominio, datos, seguridad, privacidad, riesgo o legal según el recorrido. La matriz RACI aclara quién prepara y consulta; una sola autoridad accountable cierra cada resolución. Empieza por cambios materiales y señales contrarias a los supuestos. Después revisa riesgos y controles prioritarios, excepciones, incidentes, terceros y acciones vencidas. Separa hechos, inferencias y propuestas. Una demostración preparada no sustituye evidencia reproducible. Pendiente de evidencia es válido cuando tiene dueño, fecha y una restricción provisional. Cierra el review con estados claros: continuar sin cambio, continuar con acciones, limitar, pausar, escalar, reclasificar o retirar. Registra alcance, versión, fecha, evidencia examinada, disensos, incertidumbres, residual y autoridad. La decisión solo cubre lo revisado. Cada acción necesita resultado verificable, responsable, prioridad, fecha y criterio de cierre. Distingue corrección permanente de mitigación temporal. Si una acción condiciona la continuidad, vincúlala con un límite técnico o una fecha de pausa. Comunica lo necesario a usuarios, soporte y liderazgo. Conserva paquete, minuta, resolución y enlaces a artefactos sin duplicar datos sensibles. La trazabilidad debe reconstruir qué se sabía y por qué se decidió. Mide la salud del proceso sin fabricar una puntuación de confianza. Observa cobertura del inventario, revisiones a tiempo, acciones vencidas, controles probados, fallas, excepciones renovadas, tiempo de decisión, reincidencia y cambios que activaron reevaluación. Muestra tendencias y registros que las explican. No sumes métricas heterogéneas en un semáforo que parezca probabilidad de seguridad o cumplimiento. La disponibilidad no compensa acceso indebido; la adopción no demuestra precisión; pocos incidentes no prueban detección completa. Evalúa también horas, espera, duplicación y capacidad. Si el gobierno no puede sostenerse, prioriza por riesgo, automatiza evidencia estable y elimina reportes que no llevan a una decisión. En Cerravi, la revisión conserva límites verificables. Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Comprueba que permisos o automatizaciones añadidos por la empresa no conviertan ese recorrido en una acción sin autoridad. Las propuestas usan productos y precios del catálogo. Si falta un importe, se confirma; no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. Una apertura de Buyer Room es actividad, no identidad, aceptación, contrato, pago o intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. El objetivo del review no es declarar confianza. Es demostrar que los límites, responsables y decisiones siguen funcionando en la versión que realmente opera.

Gestionar una excepción de política para un AI Sales Copilot significa autorizar un desvío limitado mientras la regla original sigue vigente. No es un atajo para llegar a una fecha, una declaración de cumplimiento ni una forma de borrar el riesgo. El proceso debe responder qué requisito no puede cumplirse, por qué existe una necesidad legítima, qué exposición adicional aparece, quién puede decidir y cuándo termina el permiso. NIST AI RMF reconoce respuestas como mitigar, transferir, evitar o aceptar y pide planificarlas y documentarlas según tolerancias establecidas. Aquí aplicamos ese principio a ventas B2B. Si basta con corregir una configuración, terminar una revisión o usar el camino aprobado, no necesitas una excepción. Necesitas completar el trabajo. La urgencia comercial aporta contexto, pero no demuestra por sí sola que el desvío sea aceptable. Separa rutas que suelen mezclarse. Una excepción autoriza temporalmente apartarse de un requisito. Un cambio modifica modelo, fuente, permiso, herramienta, regla o proceso y sigue control de cambios. Un incidente contiene y recupera un efecto no deseado. La aceptación de riesgo responde formalmente a un escenario residual dentro de una tolerancia definida. Pueden conectarse sin convertirse en lo mismo. Un incidente puede necesitar un permiso breve para continuidad. Una excepción puede incluir un cambio compensatorio y aceptar exposición residual. Cada artefacto conserva dueño, autoridad, evidencia y cierre. No llames piloto a un uso que toca producción, clientes o acciones materiales para evitar controles. Tampoco llames emergencia a una solicitud repetida que pudo planearse. El nombre no reduce la autoridad ni las consecuencias del recorrido real. La solicitud debe permitir decidir. Registra identificador, solicitante, dueño del caso, requisito vigente y redacción exacta del desvío. Delimita producto, versión, entorno, usuarios, clientes, regiones, datos, fuentes, permisos, herramientas, acciones, volumen, inicio y vencimiento. Explica la necesidad y por qué el camino conforme no está disponible. Añade alternativas estudiadas, impacto de esperar, dependencias y fecha esperada de remediación. Relaciona arquitectura, inventario, nivel de riesgo, evaluaciones, pruebas y registro de riesgos. Declara supuestos y faltantes. Si no sabes qué datos procesa un conector, quién recibe una salida o si una acción puede revertirse, esa incertidumbre forma parte del riesgo. Una frase como permitir el copiloto temporalmente no tiene una frontera que pueda activarse, monitorearse ni retirar. Define de antemano lo que una excepción no puede autorizar. Un permiso interno no anula una ley, un contrato, una prohibición aplicable o el derecho de una persona. No debe abrir secretos dentro de prompts, acceso entre organizaciones, credenciales compartidas ni acciones fuera de la autoridad disponible. Devuelve solicitudes sin dueño, alcance verificable, fecha de salida, evidencia o capacidad para operar controles. Si el posible efecto es irreversible, afecta dinero, acceso o condiciones comerciales y no existe revisión significativa, reduce la función o conserva el proceso manual. Una excepción tampoco sustituye presupuesto, personal o mantenimiento. Renovaciones repetidas para el mismo faltante revelan deuda estructural. La decisión entonces es financiar, rediseñar, retirar o cambiar la política mediante su propio gobierno. Evalúa el riesgo incremental, no todo el producto desde cero. Compara el recorrido conforme con el recorrido solicitado. Describe qué barrera falta, qué escenario se vuelve posible y qué personas, datos, decisiones u operaciones quedan más expuestos. Valora severidad, alcance, duración, frecuencia, detectabilidad, reversibilidad, propagación y dependencia. Revisa si aumenta la autoridad del agente, elimina revisión humana, amplía datos o usuarios y si el equipo puede detener el efecto. Conserva evidencia, supuestos y confianza. Una escala ordinal ayuda a comparar, pero no es probabilidad medida. Conecta el escenario con el registro de riesgos. El nivel del caso determina profundidad de revisión; la evaluación de la excepción explica el cambio de exposición. Si el residual queda fuera de tolerancia o falta evidencia material, no apruebes el desvío tal como fue solicitado. Busca primero la alternativa más estrecha. Prueba el camino conforme, un entorno aislado, datos sintéticos, menor audiencia, solo lectura, aprobación por operación, una cuota menor o proceso manual. Google Cloud recomienda limitar las excepciones a políticas al alcance mínimo y usar personas capaces de validar el caso y los controles adicionales. Un control compensatorio debe interrumpir el escenario, no solo recordarlo. Puede restringir identidad, grupo, fuente, campo, herramienta, horario, volumen o destino; exigir doble aprobación; redactar datos; conservar registros; activar alertas; o preparar fallback. Una capacitación genérica no compensa por sí sola un permiso técnico excesivo. Para cada control registra dueño, configuración, prueba, cobertura, dependencia, señal de falla y fecha. Distingue implementado de planeado. Separa solicitud, evaluación y aceptación. La persona que necesita la excepción explica el caso, pero no debe autoaprobar el riesgo que introduce. La matriz RACI define quién prepara, valida dominio, revisa seguridad, privacidad, datos y operación, y quién acepta finalmente según materialidad. La resolución puede aprobar, aprobar con condiciones, pedir evidencia, rechazar o escalar. Registra alcance autorizado, controles previos, residual aceptado, inicio, vencimiento, criterios de pausa, frecuencia de revisión y aprobación trazable. No cambies el alcance después de la firma. Evita la aprobación por silencio y los comités donde todas las personas parecen responsables pero ninguna tiene autoridad final. Un suplente decide solo dentro de facultades documentadas. Convierte el vencimiento en una propiedad técnica. Activa mediante una configuración identificable, no una instrucción informal. Cuando sea posible, usa acceso just-in-time, grupos dedicados, flags, cuotas, reglas condicionadas o credenciales con expiración. Vincula el identificador con cambios, logs y alertas. Define inicio y fin con zona horaria. Al vencer, el valor seguro es retirar el permiso o volver al recorrido conforme, no renovar automáticamente. Si cortar puede interrumpir un proceso crítico, prepara continuidad y avisos sin convertirlos en extensión silenciosa. Prueba activación y reversión. Confirma que solo el alcance aprobado recibe el permiso, que no se hereda a otros espacios y que el rollback elimina permisos, sesiones, caché, tokens y rutas derivadas cuando corresponda. Monitorea las condiciones de la decisión. Observa uso, errores, correcciones, accesos, acciones, volumen, población, fallas de controles, quejas e incidentes relacionados. Etiqueta eventos con identificador y versión. Sin esa relación no puedes demostrar que la exposición permanece dentro del alcance aceptado. Define señales de pausa: uso fuera de audiencia, dato no autorizado, control inactivo, acción inesperada, volumen superior, incidente, cambio de proveedor o evidencia que invalida un supuesto. Nombra quién puede detener y cómo mantener continuidad manual. Informa a usuarios y soporte sobre el límite que necesitan conocer, el canal de reporte y la fecha relevante. No reveles secretos ni detalles que faciliten evasión. La transparencia operativa ayuda a detectar el desvío; no debe normalizarlo. Antes del vencimiento decide cerrar, renovar o convertir. Cerrar significa retirar configuración, permisos, datos temporales, alertas especiales y dependencias, verificar el estado final y conservar evidencia. Renovar exige una revisión con datos de operación, residual actualizado, vigencia de controles, causa del retraso y nueva fecha. No copies la aprobación anterior ni reinicies el reloj. Las renovaciones acumuladas deben elevar autoridad y activar revisión de deuda. Si el desvío se vuelve una necesidad estable, cambia arquitectura o política mediante su proceso normal. Una excepción no modifica silenciosamente la norma. Documenta qué aprendiste y limita cualquier cambio al alcance que la evidencia sostiene. Microsoft recomienda gobernar el ciclo de los agentes mediante registro, aprobación, expiración y retiro; el cierre debe ser una operación verificable. Mantén un registro con estados solicitado, en evaluación, aprobado, activo, pausado, vencido, cerrado o rechazado. Mide tiempo de decisión, excepciones activas y vencidas, edad, renovaciones, controles fallidos, cierres verificados, distribución por requisito y exposición agregada por dependencia. No conviertas una baja tasa de aprobación en objetivo: puede empujar a operar sin registro. Tampoco cuentes solo solicitudes. Varias excepciones pueden depender del mismo modelo, conector o revisor y crear concentración. Revisa tendencias con dueños de política, producto y operación. Muchas solicitudes pueden revelar una implementación difícil, una regla mal explicada o una necesidad de rediseño. La evidencia puede confirmar la política, mostrar deuda o justificar un cambio; no presupongas la conclusión. En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Una empresa que conecte automatizaciones adicionales debe evaluar y aprobar ese recorrido completo. Las propuestas utilizan productos y precios presentes en el catálogo. Si falta un importe, se confirma; Cerravi no inventa la cifra. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. Una excepción no debe autorizar precios fabricados ni sumar monedas como equivalentes. Una apertura de Buyer Room es una señal de actividad, no identidad, aceptación, contrato, pago o intención. Forecast utiliza reglas transparentes del CRM y no garantiza cierres. Un permiso temporal puede modificar un control operativo aprobado por la empresa; no convierte una inferencia en hecho ni amplía por sí solo las capacidades publicadas del producto.

Clasificar el nivel de riesgo de un AI Sales Copilot sirve para decidir cuánta evaluación, revisión y capacidad operativa necesita un uso concreto. No todos los recorridos deben pasar por el mismo proceso. Un resumen interno revisado por una persona no requiere el mismo gobierno que un sistema capaz de escribir en el CRM, contactar a un cliente o afectar una condición comercial. NIST AI RMF plantea ajustar las actividades de gestión a la tolerancia y prioridades de la organización. Microsoft describe tres niveles, desde asistencia individual hasta usos críticos o externos. Aquí utilizaremos una adaptación para ventas B2B, no una obligación ni una certificación. Clasifica el caso de uso y la versión configurada, no la marca, el modelo ni toda la plataforma. Fija primero la unidad de clasificación. Nombra propósito, tarea, usuarios, personas afectadas, versión, entorno, datos, fuentes, herramientas, integraciones y salida. Separa observar, buscar, resumir, recomendar, redactar, guardar, enviar, modificar y administrar. Una etiqueta como copiloto comercial mezcla autoridades incompatibles. Define qué decisión activará el nivel: camino de evaluación, revisiones, responsables, evidencia, gate de producción, monitoreo y cadencia. Si el nivel no cambia ninguna actividad, es una etiqueta decorativa. Registra exclusiones y supuestos. Una función no habilitada queda fuera del alcance; una retención, permiso o población desconocida no se supone favorable. La incertidumbre material puede elevar el nivel o impedir avanzar hasta obtener evidencia. Empieza por la frontera entre asistir y ejecutar. Asistir significa preparar contexto, resumen, borrador o recomendación mientras una persona conserva la decisión y realiza la acción. Ejecutar significa cambiar un sistema de registro, enviar, conceder acceso, comprometer una condición, activar una herramienta o producir un efecto sin otra confirmación suficiente. La revisión humana solo reduce exposición cuando la persona dispone de tiempo, conocimiento, evidencia, autoridad y una interfaz que muestra lo relevante. Un botón de aprobación bajo presión o sin procedencia no convierte una acción material en bajo riesgo. Revisa también la autoridad acumulada: varias funciones limitadas pueden formar juntas un recorrido capaz de actuar. La autorización se comprueba donde ocurre el efecto. Evalúa dimensiones materiales sin esconderlas en un promedio. Revisa autoridad y autonomía; personas y audiencia; datos y sensibilidad; dinero, acceso y compromisos; escala y frecuencia; reversibilidad y propagación; dependencia y continuidad; novedad, desempeño y evidencia. Cada dimensión necesita criterios visibles y ejemplos propios. No promedies una consecuencia alta con varias dimensiones bajas. Acceso entre organizaciones, acción irreversible, datos sensibles o una promesa comercial pueden activar el nivel más exigente por sí solos. Define disparadores absolutos antes de usar una escala. Una puntuación ordinal ayuda a ordenar, pero no es probabilidad medida. Registra fuente, versión, supuestos y confianza. Si no sabes si una herramienta puede escribir, investiga en lugar de asignar un número tranquilizador. Nivel uno corresponde a asistencia interna limitada y reversible. Puede incluir borradores, búsquedas o resúmenes para una persona o equipo pequeño, con fuentes autorizadas, sin acción autónoma y con revisión antes de cualquier efecto. Un error debe ser detectable y corregible sin consecuencia relevante. Exige propósito, dueño, datos permitidos, límites visibles, checklist de lanzamiento, pruebas de casos normales y faltantes, canal de feedback y monitoreo básico de uso y errores. El camino puede ser autoservicio dentro de guardrails publicados. Nivel uno no significa sin riesgo ni libre de políticas. Un resumen puede exponer datos entre cuentas, conservar información indebidamente o convertirse en fuente oficial. Si cambia público, sensibilidad, volumen o autoridad, reclasifica antes de ampliar. Nivel dos cubre conocimiento especializado o un servicio interno material. Una respuesta incorrecta puede orientar mal una decisión, interrumpir trabajo o propagarse a varias personas, aunque la acción final siga bajo control humano. Puede incluir conocimiento de producto, propuestas complejas, priorización operativa o un servicio con datos de negocio. Añade un validador experto del dominio, control de calidad y vigencia de fuentes, evaluación formal por escenarios, release-gate, feedback trazable, monitoreo de correcciones, cambio versionado, fallback y revisión periódica. Seguridad, datos, privacidad u otras funciones participan según el alcance. No rebajes el nivel solo porque exista revisión humana si el volumen vuelve imposible revisar o si la salida se reutiliza fuera de contexto. Prueba el control con carga, idioma y tiempo reales. Nivel tres cubre uso externo, crítico o con acción material. Incluye recorridos orientados a clientes, integrados en procesos críticos, con datos sensibles, permisos amplios, autonomía o capacidad de producir efectos sobre dinero, acceso, contratos, comunicaciones o confianza. También puede aplicar cuando la reversión es difícil o la incertidumbre permanece alta. Requiere dueño de negocio y proceso, evaluación de impacto, revisiones de seguridad y privacidad según corresponda, modelo de amenazas, evaluación representativa, límites de autonomía, gate formal, registros, monitoreo reforzado, respuesta a incidentes, continuidad, rollback y revisión ejecutiva proporcional. Nivel alto no significa prohibido ni daño inevitable. Significa que hacen falta más evidencia, autoridad y capacidad. Si la organización no puede operar los controles, reduce alcance, conserva el proceso manual o no avances. Relaciona cada nivel con un camino de control publicado. Para nivel uno: dueño, límites, checklist, pruebas básicas, feedback y monitoreo. Para nivel dos: validador experto, evaluación formal, gate, control de cambios y fallback. Para nivel tres: revisión multidisciplinaria, decisión formal, registros, respuesta, continuidad y revisión reforzada. Son ejemplos adaptables, no un estándar universal. Clasifica el comportamiento configurado y evita listas cerradas de productos. Una misma función puede subir cuando obtiene un conector, más datos, otro público o capacidad de escribir. El camino debe ser proporcional y previsible: los equipos necesitan saber qué evidencia preparar antes de llegar al gate, no descubrir requisitos nuevos en la última reunión. Documenta la clasificación y su evidencia. Registra identificador, caso, versión, respuestas por dimensión, disparadores, nivel propuesto, nivel decidido, responsable, aprobador, fecha, fuentes, incertidumbres y próxima revisión. Relaciona la decisión con el inventario y la matriz RACI. Si existe desacuerdo, conserva las posiciones y quién tiene autoridad para resolver. No cambies criterios después de ver el resultado para facilitar una fecha. Una excepción necesita alcance, compensación, vencimiento y aceptación explícita. Mide la calidad del proceso: casos sin nivel, decisiones vencidas, niveles sin evidencia, capacidades modificadas sin reclasificar y excepciones abiertas. No premies una mayor cantidad de niveles bajos; eso incentiva describir recorridos de manera incompleta. Conecta el nivel con los demás artefactos. La clasificación decide cuánto trabajo de gobierno necesita el caso. La evaluación comprueba comportamiento. La evaluación de impacto estudia beneficios y efectos sobre personas y operación. El modelo de amenazas explica rutas. El registro de riesgos administra escenarios, controles, evidencia y residual. No uses el nivel como resumen del riesgo residual. Un caso nivel tres puede operar con controles sólidos y residual aceptado; un nivel uno puede contener una falla crítica. La clasificación depende de materialidad y autoridad del uso. El residual depende de escenarios y eficacia demostrada de controles. La matriz RACI asigna quién clasifica, valida, aprueba, monitorea, pausa y reabre. Reclasifica por cambios y señales, no solo por calendario. Reabre cuando cambian propósito, público, datos, modelo, fuente, permiso, herramienta, integración, volumen, región, idioma, autonomía, proveedor o proceso. Añadir escritura al CRM o contacto externo no es una actualización menor aunque el nombre permanezca. Usa señales de operación: correcciones, fallas, quejas, incidentes, uso fuera de alcance, escalaciones, permisos denegados y dependencia excesiva. Una señal no cambia automáticamente el nivel, pero puede activar investigación, control temporal o pausa. Conserva historial. Si reduces autoridad o retiras una fuente para bajar de nivel, verifica el cambio antes de aprobar. Una etiqueta nueva no compensa una capacidad que todavía existe. En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Ese límite reduce autoridad frente a un agente ejecutor, pero no elimina la evaluación de datos, fuentes, usuarios, volumen e integraciones. Las propuestas usan productos y precios disponibles en el catálogo. Un importe faltante exige confirmación; Cerravi no inventa la cifra. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. Una apertura de Buyer Room es una señal operativa, no identidad, aceptación, contrato, pago o intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. Si una empresa conecta nuevas herramientas, amplía permisos o automatiza acciones alrededor de Cerravi, debe clasificar ese recorrido completo.

Una matriz RACI de gobernanza para un AI Sales Copilot convierte políticas y buenas intenciones en trabajo con dueño. Explica quién ejecuta una tarea, quién responde finalmente por el resultado, quién debe aportar criterio antes de decidir y quién recibe la resolución. No es un organigrama ni una lista de todas las personas que participan en el proyecto. NIST AI RMF pide que las funciones, responsabilidades y líneas de comunicación para gestionar riesgos de inteligencia artificial sean claras, y atribuye a la dirección la responsabilidad sobre decisiones de riesgo. Microsoft propone usar RACI para concretar tareas y mantener una sola función accountable por cada una. Aquí adaptaremos esas ideas a ventas B2B. La matriz no demuestra cumplimiento ni sustituye procedimientos, controles, competencias o asesoría aplicable. Empieza por delimitar el sistema, el caso de uso y los derechos de decisión. Nombra la tarea: resumir una cuenta, recomendar un siguiente paso, preparar una propuesta desde catálogo o priorizar revisión. Registra versión, usuarios, datos, fuentes, herramientas, integraciones, entorno y autoridad. Separa observar, redactar, guardar, enviar y modificar. Una matriz para borradores internos no autoriza contacto automático ni cambios de etapa. Distingue gobierno de la plataforma y gobierno del caso. Plataforma puede definir identidad, registros, entornos y estándares; el área comercial responde por propósito, proceso y valor. Escribe quién puede aprobar un piloto, habilitar producción, ampliar población, aceptar riesgo residual, modificar fuentes, conceder permisos, pausar, reanudar y retirar. Si dos foros pueden tomar la misma decisión sin precedencia, la ambigüedad continúa. Construye el inventario de tareas antes de asignar letras. Organiza por ciclo de vida: propuesta, evaluación, diseño, construcción, prueba, aprobación, despliegue, operación, cambio, incidente y retiro. Cada fila comienza con un verbo y termina en un resultado verificable. “Revisar IA” es demasiado amplio; “aprobar el conjunto de evaluación de la versión candidata” se puede asignar y cerrar. Incluye trabajo invisible: confirmar procedencia y vigencia de datos, clasificar información, revisar accesibilidad e idioma, capacitar usuarios, mantener una alternativa, atender correcciones, conservar evidencia, renovar excepciones y revocar accesos. Relaciona cada tarea con una ficha, evaluación, prueba, configuración, aprobación, reporte o registro. Si no existe un resultado observable, nadie podrá comprobar que la responsabilidad fue cumplida. Ahora diferencia las cuatro letras. Responsible, la R, ejecuta el trabajo y produce el resultado. Accountable, la A, responde por su suficiencia y toma o presenta la decisión final. Consulted, la C, aporta criterio antes de cerrar. Informed, la I, recibe el avance o la resolución. No uses C como veto escondido ni I como invitación permanente a todas las reuniones. Cada fila necesita al menos una R y exactamente una A. Puede haber varias personas responsables de partes distintas, pero dos funciones accountable suelen ocultar quién decide cuando existe desacuerdo. Asigna cargos o personas identificables, no palabras vagas como negocio, TI o comité. En equipos pequeños, una persona puede ocupar varias funciones. Conserva las letras y registra suplencia, tiempo, acceso, formación y autoridad real. Asigna al negocio el propósito, el valor y la decisión comercial. El dueño del proceso define el problema, el público, los resultados y los límites. Responde por que el copiloto apoye una tarea legítima y por comparar beneficios con cargas e impactos. También mantiene una alternativa cuando la función no está disponible. El product owner convierte ese propósito en recorrido, requisitos, backlog, criterios de aceptación y comunicación. Puede coordinar evaluaciones y cambios, pero no debe aceptar por sí solo riesgos fuera de su autoridad. Liderazgo establece tolerancia, recursos y escalamiento. No necesita aprobar cada ajuste de texto, pero sí usos de mayor impacto, excepciones críticas, ampliaciones de autonomía o riesgos que superan el umbral del área. Separa siempre quién recomienda de quién puede aprobar. Separa producto, arquitectura, plataforma, operación y datos. Tecnología mantiene componentes, versiones, entornos, integraciones, validaciones y recuperación. Plataforma opera identidad, secretos, observabilidad y disponibilidad. Arquitectura define patrones y excepciones. Aunque una persona desempeñe varias funciones, la matriz conserva quién modifica el sistema y quién verifica su operación. El dueño de datos autoriza fuentes y finalidad. El data steward mantiene definición, calidad, procedencia, acceso y corrección. Conectar el CRM no autoriza reutilizar todos sus campos. Cada permiso se relaciona con una tarea y una persona capaz de revocarlo. Cuando el impacto lo exige, quien desarrolla no debe ser la única persona que confirma preparación. La revisión independiente necesita contexto, criterios y evidencia, no distancia burocrática. Integra seguridad, privacidad, riesgo y legal sin convertirlos en dueños de todo el producto. Seguridad define criterios para identidad, mínimo privilegio, vulnerabilidades, registros y respuesta. Privacidad revisa finalidad, minimización, derechos y tratamiento. Riesgo ayuda con nivel, tolerancia, controles y aceptación. Legal interpreta obligaciones y contratos aplicables. Pueden ser R de una revisión especializada, C en el diseño o A de un gate que la organización les haya delegado. El negocio conserva propósito y uso; tecnología, implementación; y cada control, su operación. Define qué ocurre si existe desacuerdo: conserva hallazgo, evidencia, umbral, autoridad, excepción, vigencia y condiciones. Una votación informal no debe borrar una objeción material. La matriz tampoco puede cambiar responsabilidades impuestas por leyes o contratos. Nombra responsables para operación, soporte, incidentes y continuidad. En producción alguien observa disponibilidad, calidad, correcciones, uso fuera de alcance y cambios. Otra función atiende usuarios, clasifica reportes, investiga, comunica y mantiene el proceso manual. Operar no es solo mantener un servidor. Para incidentes, distingue mando, investigación técnica, negocio, seguridad, privacidad, comunicación y autoridad de recuperación. La primera hora no puede depender de buscar voluntarios o reunir al comité completo. Asigna también el retiro: quién decide la fecha, conserva continuidad, exporta lo necesario, revoca identidades, detiene integraciones, trata datos y verifica que no queden tráfico o dependencias activas. Un servicio apagado sin verificación todavía puede dejar exposición y trabajo huérfano. Construye la cuadrícula con tareas en filas y funciones en columnas. Fuera de ella, añade resultado esperado, evidencia, fecha, escalamiento y suplencia. Para definir propósito, Producto puede ser R y el dueño de negocio A, con Datos y Riesgo consultados. Para autorizar fuentes, Datos y Plataforma pueden ejecutar, el dueño de datos responder y Seguridad ser consultada. Para evaluar una versión, Producto y Evaluación trabajan, el dueño de negocio responde y usuarios o especialistas aportan criterio. Para aprobar producción, el product owner prepara y la autoridad del gate decide. Para un incidente, el equipo responde y el incident commander mantiene la A. Son ejemplos, no un estándar. Una empresa centralizada, federada o pequeña debe adaptar asignaciones a su capacidad y riesgo. Define escalamiento, pausa, excepción y reanudación. La A por sí sola no explica hasta dónde llega la autoridad. Documenta qué puede aprobar cada función, con qué evidencia y cuándo debe elevar. Separa priorizar trabajo, aceptar riesgo, autorizar datos, conceder acceso y asumir un compromiso comercial. Nombra quién puede pausar de inmediato y quién decide reanudar. Quien detecta una condición grave necesita contener sin esperar al responsable del roadmap. La reanudación puede exigir prueba, revisión, aceptación residual y comunicación. Las excepciones llevan alcance, motivo, dueño, control compensatorio, vencimiento y revisión. Una excepción sin fecha se convierte en una nueva regla no evaluada. Conserva discrepancias materiales; cerrar una reunión no exige fingir consenso. Valida la matriz con escenarios breves. Aparece un precio sin fuente, alguien solicita acceso adicional, cambia el modelo, un proveedor falla o un cliente pide corrección. Pregunta quién actúa primero, qué evidencia consulta, quién decide, a quién comunica y cuánto puede esperar. Así aparecen celdas ambiguas antes de una situación real. Confirma que cada persona conoce y acepta la función, tiene tiempo, acceso, formación y suplencia. Busca conflictos y acumulación de autoridad. Actualiza cuando cambien organización, caso de uso, datos, permisos, autonomía, proveedor, control o gate, y después de un incidente o ejercicio que muestre una brecha. Conserva versión, fecha, aprobador y motivo. Una matriz pequeña y vigente vale más que una tabla completa con nombres que ya no ejercen la función. En Cerravi, el dueño comercial define propósito y proceso; producto y tecnología configuran el recorrido; datos autoriza fuentes; y cada usuario revisa las sugerencias antes de actuar. Copilot organiza contexto y propone siguientes pasos, pero no envía mensajes ni cambia etapas automáticamente. La RACI debe preservar esa frontera. Las propuestas usan productos y precios disponibles en el catálogo: asigna quién mantiene la fuente, quién aprueba excepciones y quién detiene un envío si falta un importe. 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 del CRM y no garantiza cierres. Cerravi no decide la estructura legal, laboral, de privacidad o riesgo de la empresa; cada organización adapta funciones y autoridad a su operación.

Una evaluación de impacto de un AI Sales Copilot sirve para decidir si un uso concreto debe avanzar, bajo qué condiciones y quién puede resultar afectado. No es una descripción promocional del sistema ni una promesa de inteligencia artificial responsable. Conecta el propósito comercial con beneficios esperados, posibles daños, personas afectadas, evidencia y límites operativos. NIST propone caracterizar impactos positivos y negativos sobre individuos, grupos, comunidades, organizaciones y sociedad. En ventas B2B, la pregunta práctica es más precisa: ¿qué cambia para el vendedor, el cliente, el equipo y terceros cuando el copiloto observa, recomienda, redacta o actúa? La evaluación debe producir una decisión trazable. Si solo genera un documento sin modificar alcance, controles o lanzamiento, no está cumpliendo su función. Empieza por una decisión y un alcance que puedan revisarse. Nombra el caso de uso, la tarea, el usuario, el entorno, la versión, los datos, las integraciones y el efecto previsto. Separa observar, resumir, recomendar, redactar, guardar, enviar y modificar. Preparar un borrador que revisa una persona no equivale a enviar un mensaje, cambiar una etapa del CRM o comprometer un precio. Define qué decisión habilitará la evaluación: avanzar, avanzar con condiciones, probar en un grupo limitado, rediseñar o no lanzar. Registra también qué queda fuera. Una evaluación para resumir notas internas no autoriza prospección automática ni decisiones sobre personas. Cuando cambia la autoridad, el público, la fuente de datos o la región, el alcance debe reabrirse. Identifica a quienes usan el sistema y a quienes reciben sus efectos, aunque nunca vean la interfaz. Incluye vendedores, líderes, operaciones, administradores, clientes, prospectos, contactos que no respondieron, personas cuyos datos aparecen en documentos y equipos que deberán corregir errores. Pregunta quién obtiene el beneficio, quién soporta la carga de revisión y quién puede quedar en desventaja. Añade perspectivas distintas a la del dueño del proyecto: privacidad, seguridad, legal, soporte y, cuando sea viable, usuarios finales o grupos afectados. Un impacto no desaparece porque ocurra fuera de la pantalla. Una recomendación de prioridad puede alterar atención comercial; una inferencia débil puede etiquetar a un cliente; una automatización puede aumentar mensajes no deseados o trasladar trabajo al equipo de soporte. Describe los beneficios como resultados observables, no como adjetivos. “Más productividad” es demasiado amplio. Es mejor medir tiempo para preparar una propuesta, porcentaje de borradores corregidos, oportunidades con siguiente paso documentado o consultas resueltas sin alterar condiciones comerciales. Establece una línea base, un periodo, una fuente y un responsable. Después revisa la distribución: un promedio favorable puede ocultar que los nuevos vendedores corrigen más errores, que ciertos sectores reciben respuestas menos útiles o que el equipo de operaciones absorbe trabajo adicional. No conviertas correlación en causalidad. Una propuesta vista o una respuesta rápida no demuestra aceptación. El beneficio esperado debe compararse con alternativas más simples, como mejorar datos, plantillas, capacitación o reglas del CRM. Documenta el uso previsto, el uso indebido razonablemente previsible y la dependencia excesiva. El uso previsto explica qué problema resuelve, para quién y con qué revisión. El uso previsible incluye copiar datos no autorizados, ampliar el público, saltarse una aprobación, reutilizar una salida fuera de contexto o interpretar una señal como certeza. La dependencia excesiva aparece cuando la persona deja de verificar porque el texto parece convincente o porque la interfaz presenta una recomendación con demasiada autoridad. Añade deriva de propósito: una función creada para organizar seguimiento puede terminar evaluando desempeño o segmentando personas. No basta con prohibir estos usos en una política. Diseña permisos, límites, mensajes, revisión humana, registros y pruebas que hagan visible o difícil el desvío. Examina impactos en cuatro planos conectados. En personas, revisa privacidad, autonomía, trato desigual, comprensión, posibilidad de corregir y carga cognitiva. En el proceso, revisa errores, demoras, pasos omitidos, reversibilidad y alternativa manual. En la organización, considera seguridad, cumplimiento, reputación, dependencia de proveedores, continuidad y concentración de autoridad. En clientes y terceros, evalúa contacto no deseado, información incorrecta, promesas comerciales, exposición de datos y dificultad para reclamar. No todos los efectos son negativos ni todos tienen la misma materialidad. El objetivo es evitar puntos ciegos y entender interacciones: una automatización que ahorra minutos puede aumentar volumen, amplificar una mala regla y hacer más costosa la corrección. Para cada impacto, registra a quién afecta, dirección positiva o negativa, severidad, alcance, duración, reversibilidad y distribución. La probabilidad puede expresarse con una escala cualitativa si no existe evidencia estadística, pero debe acompañarse de supuestos y nivel de confianza. Distingue una molestia temporal de una pérdida de acceso, una promesa financiera o una exposición de datos. Pregunta si la persona afectada puede detectar el efecto, impugnarlo y recuperarse. Examina impactos acumulativos: un correo incorrecto puede corregirse; cientos de recomendaciones sesgadas durante meses crean un patrón distinto. No sumes números arbitrarios para fabricar precisión. La matriz ordena la conversación; el razonamiento, la evidencia y los umbrales definidos sostienen la decisión. Separa hechos, pruebas, opiniones, supuestos y desconocidos. Enlaza cada afirmación material con una fuente: registros del sistema, prueba controlada, revisión de muestras, entrevista, queja, documento técnico o resultado operativo. Indica versión, fecha, población y limitaciones. Minimiza datos: no recolectes atributos sensibles solo para completar una tabla. Si una diferencia importa pero no puede medirse de forma responsable, documenta la incertidumbre y usa controles conservadores. Confirma que la prueba representa el idioma, el catálogo, las monedas, los roles y los recorridos reales. Una demostración perfecta no reemplaza datos de operación. La ausencia de incidentes no prueba ausencia de impacto, especialmente cuando no existe un canal de reporte o nadie revisa las señales. Compara opciones antes de aceptar el riesgo. Puedes reducir alcance, eliminar una fuente, bajar permisos, exigir aprobación, limitar volumen, mostrar procedencia, añadir validación, separar monedas, mantener una alternativa manual o posponer el lanzamiento. Evalúa si el control realmente reduce el impacto y qué carga introduce. Una revisión humana nominal no ayuda si la persona no tiene tiempo, contexto, autoridad o una interfaz para comparar. Un aviso no compensa una acción irreversible. Asigna dueño, fecha, evidencia de implementación y criterio de efectividad. Revisa también el riesgo residual. La mitigación no borra el impacto; cambia su exposición o capacidad de recuperación. Si el beneficio puede lograrse con una opción más simple y menos invasiva, esa alternativa forma parte de la decisión. Convierte el análisis en una resolución trazable. Registra alcance evaluado, participantes, evidencia, impactos principales, desacuerdos, mitigaciones, riesgo residual y autoridad que decide. Usa resultados claros: avanzar, avanzar con condiciones, piloto limitado, rediseñar o no avanzar. Cada condición necesita dueño, fecha y prueba de cierre. Define umbrales que impidan el lanzamiento o activen una pausa, por ejemplo precios sin fuente vigente, envío sin aprobación, permisos excesivos, tasa de corrección fuera del límite o imposibilidad de revertir. No ocultes incertidumbre detrás de una puntuación agregada. Una decisión responsable puede aceptar un riesgo pequeño con control fuerte y rechazar un beneficio atractivo cuando la consecuencia es grave o no recuperable. La evaluación continúa después del lanzamiento. Define señales para beneficios, daños, distribución, errores, correcciones, quejas, anulaciones, permisos denegados y uso fuera de alcance. Crea un canal para que usuarios y personas afectadas puedan reportar, entender y corregir resultados. Establece frecuencia de revisión y eventos que reabren el análisis: cambio de modelo, prompt, fuente, herramienta, permiso, región, idioma, público, volumen, proveedor o propósito. Conserva muestras y decisiones sin guardar más datos de los necesarios. Si una señal supera el umbral, limita, pausa, revierte o vuelve al proceso manual. El monitoreo no es una ceremonia posterior; comprueba si los supuestos de la decisión siguen siendo válidos en operación. En Cerravi, la evaluación debe respetar límites verificables. El copiloto trabaja con el catálogo y las fuentes autorizadas; no debe inventar precios ni mezclar MXN, USD u otras monedas. Una vista, una apertura o una actividad del CRM es una señal operativa, no una aceptación ni una probabilidad garantizada de cierre. La persona conserva la decisión comercial y la responsabilidad de revisar destinatario, alcance, productos, cantidades, vigencia, impuestos, condiciones y siguiente paso antes de enviar o comprometer algo. La evaluación de impacto no sustituye asesoría legal, revisión de privacidad, seguridad ni obligaciones sectoriales. Su valor está en hacer explícitos los efectos, la evidencia, los límites y la autoridad antes de que una función convincente se convierta en una decisión real.

Un modelo de amenazas de un AI Sales Copilot no es una lista genérica de ataques ni una declaración de que el sistema es seguro. Es una representación de cómo un sistema concreto puede perder confidencialidad, integridad, disponibilidad, control humano o trazabilidad dentro de su contexto comercial. Su resultado debe ayudar a decidir qué cambiar, qué probar, qué observar y quién responde por lo que permanece abierto. NIST sitúa el contexto, las tareas, las personas y todos los componentes dentro de la función Map. Microsoft explica que las amenazas específicas de inteligencia artificial complementan la seguridad tradicional. Aquí utilizaremos una secuencia operativa, no una plantilla obligatoria ni una certificación. Primero fija el alcance. Nombra el caso de uso, la decisión o tarea asistida, la versión de la aplicación, el modelo, los prompts, las fuentes, las herramientas, el entorno y el grupo de usuarios. Un copiloto que redacta un borrador interno no tiene la misma superficie que uno capaz de enviar un mensaje. Dibuja dónde empieza y termina el recorrido. Aclara si una actualización del CRM, un envío o una llamada externa forman parte del sistema. Registra también el proceso manual y lo que queda fuera. Fuera de alcance no significa sin riesgo: asigna quién revisará esa dependencia y qué supuestos todavía no están confirmados. Después identifica los activos y los impactos que importan al negocio. Incluye identidades, secretos, precios, descuentos, monedas, contactos, notas, propuestas, archivos, historial, contratos, reputación y continuidad. Añade a las personas y organizaciones que podrían verse afectadas. Describe consecuencias observables: exposición entre organizaciones, precio no confirmado dentro de una propuesta, etapa modificada sin autorización, mensaje enviado a una persona equivocada o indisponibilidad durante una negociación. Fuga, error y alucinación son etiquetas demasiado amplias. Asigna dueño y severidad con criterios visibles, pero no presentes una escala ordinal como una pérdida cuantificada si no existe evidencia. Ahora traza los datos y las instrucciones desde la entrada hasta el efecto. Representa texto humano, CRM, archivos, recuperación, memoria, reglas, prompt de sistema, modelo y respuesta. Sigue la salida hasta la interfaz, el almacenamiento, la propuesta, el correo, la métrica o la herramienta que pueda consumirla. Distingue datos de instrucciones. Una nota o documento externo puede contener texto que intente dirigir al modelo; recuperarlo no le concede autoridad. Señala dónde se delimita, etiqueta, reduce o valida el contenido. Incluye registros, feedback y telemetría. Para cada flujo conserva fuente, destino, identidad, finalidad, clasificación, retención y comportamiento cuando un dato falta o entra en conflicto. Marca los límites de confianza. Aparecen cuando cambian organización, propietario, identidad, política, entorno o nivel de confianza: navegador y servicio, aplicación y proveedor de modelo, CRM y conector, recuperación y fuente externa, organización y Buyer Room, producción y administración. Registra quién llama a quién y con qué credencial. Separa persona, cuenta de servicio, token, clave, webhook y rol administrativo. Anota permisos de lectura, escritura, envío y ejecución. La autorización se comprueba en el punto de la acción, no se deduce de una frase generada. Busca autoridad acumulada: varios componentes limitados pueden formar juntos una ruta con un efecto mucho mayor. Modela actores por su capacidad, no como una caricatura de atacante. Incluye usuario autorizado que se equivoca, persona interna que abusa de acceso, tercero que controla contenido recuperado, cuenta comprometida, proveedor que cambia y proceso automatizado mal configurado. Considera también fallas sin intención maliciosa: datos obsoletos, permisos heredados, indisponibilidad y colisiones de versión. Pregunta qué puede observar, introducir, modificar, repetir, ocultar o activar cada actor. Separa intención de capacidad. Si una ruta depende de una condición desconocida, conserva el supuesto y diseña una prueba antes de declarar que su exposición es alta o baja. Escribe cada escenario como condición, acción, activo y consecuencia. Por ejemplo: un archivo externo contiene instrucciones; el recuperador las incorpora sin delimitación; el copiloto solicita una herramienta fuera del propósito; y una persona recibe una propuesta con datos no autorizados. Cubre confidencialidad, integridad, disponibilidad, identidad, autorización, procedencia, privacidad y supervisión humana. Para sistemas generativos añade inyección directa e indirecta, recuperación indebida, salida insegura, uso excesivo de herramientas, memoria contaminada y confianza injustificada en una respuesta. No copies una lista sin conectarla al diseño. Mantén un identificador y relaciónalo con activos, componentes, controles, pruebas, hallazgos e incidentes. Prioriza cada escenario con impacto, alcance, accesibilidad, frecuencia, condiciones necesarias, reversibilidad y capacidad de propagación. Distingue el riesgo inherente, antes de controles específicos, del residual después de controles implementados y comprobados. Si la posibilidad es desconocida, dilo y abre la evidencia necesaria. Una puntuación puede ordenar el trabajo si sus criterios son consistentes, pero no convierte incertidumbre en probabilidad. Revisa por separado los escenarios de impacto extremo, en especial acceso entre organizaciones, datos sensibles, acciones externas y recuperación débil. La prioridad debe activar una respuesta: evitar, reducir, transferir, aceptar con condiciones o retirar. Asigna controles a la ruta, no a la etiqueta. Reduce entradas con fuentes autorizadas y delimitación. Limita el acceso mediante identidad y privilegio mínimo. Restringe herramientas con listas permitidas, parámetros y autorización determinista. Valida salidas antes de un efecto. Conserva revisión humana para decisiones materiales y prepara pausa, reversión y fallback. Un prompt que pide prudencia no sustituye un permiso. Un filtro de palabras no cubre todas las variantes. La aprobación humana tampoco funciona si la persona no ve fuente, cambio y consecuencia. Para cada control registra dueño, componente, cobertura, configuración, dependencia, estado, frecuencia y evidencia. Convierte los escenarios prioritarios en pruebas reproducibles. Combina revisión de arquitectura, configuración, permisos, evaluación y red teaming autorizado. Registra precondiciones, versión, rol, datos de prueba, pasos, resultado esperado, observado y evidencia. Utiliza datos sintéticos o protegidos. Prueba casos positivos y negativos: una acción permitida debe funcionar dentro de su alcance y rechazarse para otra organización, rol o recurso. Incluye conflicto de fuentes, dato faltante, contenido adversario, proveedor no disponible, token revocado y respuesta fuera de formato. Un escenario no es un defecto confirmado. Un hallazgo no sustituye al escenario. Relaciónalos y conserva los casos críticos como regresión. Mantén el modelo vivo. Cambios de modelo, prompt, recuperación, memoria, fuente, integración, permiso, herramienta, proveedor, autonomía, usuarios y entorno deben revisar el diagrama y los escenarios relacionados. Conecta señales de producción: denegaciones, reintentos, acceso inusual, herramienta bloqueada, corrección humana, fuente desconocida, latencia y errores de proveedor. Una señal no demuestra ataque ni impacto, pero puede activar investigación, límite, pausa o respuesta a incidentes. Versiona el modelo y conserva decisiones. Cierra un escenario cuando la ruta deja de existir o existe una aceptación autorizada con condiciones, no porque dejó de aparecer en una reunión. En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. El modelo debe preservar esa frontera. Las propuestas utilizan productos y precios disponibles en el catálogo. Un importe faltante exige confirmación y las monedas permanecen separadas salvo conversión aprobada. Prueba que una nota, archivo o prompt no pueda inventar o mezclar esas condiciones. La actividad de Buyer Room no confirma identidad, aceptación, contrato, pago o intención. Forecast usa reglas transparentes del CRM; no es una garantía. La empresa conserva la responsabilidad sobre usuarios, datos, permisos, integraciones, controles y respuesta.

Un inventario de sistemas de IA no es una lista de licencias. Es el mapa que permite saber qué inteligencia artificial utiliza la organización, para qué tarea, con qué datos y autoridad, quién responde y en qué estado se encuentra. Incluye productos comprados, funciones incorporadas, desarrollo interno, modelos abiertos, APIs, automatizaciones, experimentos y usos no autorizados descubiertos. NIST incluye mecanismos para inventariar sistemas de IA dentro de Govern uno punto seis. El inventario hace visibles casos de uso y dependencias para mantenimiento, incidentes, cambios y retiro. No sustituye el catálogo de aplicaciones, el mapa de datos o el registro de riesgos: los conecta alrededor del sistema real. Define correctamente la unidad del registro. No uses solo el nombre del modelo. Un modelo puede resumir notas internas, redactar correos y actualizar el CRM; cada recorrido tiene datos, efectos y controles distintos. También varios modelos pueden formar parte de un solo copiloto. Registra el sistema dentro de su contexto de uso y asigna un identificador estable. Nómbralo con función, proceso y alcance. Vincula aplicación, modelo, recuperación, herramientas, reglas, interfaz e integraciones. Separa registros cuando cambien de forma material las personas afectadas, la decisión, la autoridad, la clase de datos o el entorno. No abras una fila nueva por cada prompt menor. Descubre usos aprobados, experimentales y no autorizados. Revisa compras, contratos, gastos, inicio de sesión, OAuth, extensiones, repositorios, cuentas de nube, endpoints, webhooks, automatizaciones y cuentas de servicio. Entrevista al equipo por tareas: pregunta dónde resumen, generan, clasifican, recomiendan o ejecutan con ayuda de IA. Una función dentro del CRM, correo o documentos puede pasar inadvertida porque no fue adquirida como producto independiente. Busca también sistemas retirados que conservan datos, tokens o jobs. Si encuentras un uso no autorizado, regístralo con acceso restringido, contiene la exposición y decide si se retira, evalúa o reemplaza. Aparecer en el inventario no significa estar aprobado. Captura campos que permitan actuar. La ficha mínima incluye identificador, propósito, área, usuarios, personas afectadas, tarea o decisión apoyada, estado, responsable de negocio, responsable técnico y contacto operativo. Añade fecha de alta, última revisión, próxima revisión, entorno, región y prioridad. Documenta entradas, salidas, fuentes, clases de datos, conservación, modelos, proveedores, versiones, integraciones, herramientas, permisos y revisión humana. Enlaza arquitectura, evaluación, contrato, riesgos, incidentes y continuidad; no copies documentos completos. Describe la autoridad real: observar, resumir, recomendar, redactar, guardar, enviar, modificar o administrar. Una etiqueta como asistente comercial no explica lo que el sistema puede hacer. Utiliza estados de ciclo de vida con criterios claros. Candidato significa uso propuesto todavía no autorizado. Experimento limita datos, usuarios y efectos. Piloto prueba una cohorte con escenarios y criterios. Producción habilita un alcance aprobado y monitoreado. Pausado contiene temporalmente. Retirado cierra operación y conserva trazabilidad. Cada transición necesita responsable, fecha y evidencia. Producción exige versión, controles, soporte, monitoreo y fallback. Retiro exige tratar datos, identidades, integraciones y dependencias. Conserva el historial. Si el sistema vuelve, reabre la evaluación en lugar de cambiar silenciosamente una fila antigua. Asigna propietarios y autoridad. El responsable de negocio confirma propósito, usuarios, decisión y continuidad. El responsable técnico mantiene componentes, versión e integración. El dueño de datos autoriza fuentes y calidad. Quien opera un control conserva configuración y evidencia. Una persona puede ocupar varios papeles en un equipo pequeño, pero las funciones siguen visibles. Registra suplencia y quién aprueba el alta, acepta riesgo residual, pausa, reanuda o retira. Un alias facilita contacto, pero no sustituye un nombre. Revisa registros huérfanos cuando una persona cambia de función. El área que obtiene el beneficio debe responder por el caso de uso; Seguridad no puede ser propietaria de todos los sistemas. Mapea datos, identidad, permisos y efecto posible. Clasifica entradas, contexto recuperado, salidas, feedback y telemetría. Registra fuente oficial, finalidad, región, conservación y acceso. Distingue información pública, interna, confidencial, personal, sensible, credenciales y material de terceros. Una fuente conectada no se vuelve autorizada por estar disponible. Documenta identidades humanas y de servicio, secretos, roles y acciones. Separa lectura, escritura, envío y administración. Indica si el sistema actúa sobre una oportunidad, una cuenta, todo el espacio o un servicio externo. Relaciona cada permiso con la tarea que lo justifica y prueba su revocación. Conecta componentes, proveedores y dependencias compartidas. Representa modelos, prompts, recuperación, índices, herramientas, conectores, APIs, nube, identidad y observabilidad. Registra versión y proveedor. Identifica consumidores aguas abajo: una salida puede alimentar un correo, propuesta, métrica o automatización. Busca concentración. Varios sistemas pueden depender del mismo modelo, identidad o catálogo aunque parezcan independientes. Un fallo común modifica continuidad e impacto. Mantén enlaces estables entre sistema y componentes. Un nuevo modelo cambia versión y activa revisión. Una herramienta nueva con permiso de escritura puede cambiar materialmente el alcance y exigir otra evaluación. Prioriza según impacto, autoridad y exposición. Revisa primero sistemas que afectan personas, dinero, acceso, información sensible, compromisos externos o continuidad. Considera número de usuarios, frecuencia, reversibilidad, autonomía, terceros, novedad y calidad de evidencia. Define niveles con actividades asociadas. Un nivel alto puede exigir evaluación independiente, revisión legal, prueba adversaria, aprobación ejecutiva y monitoreo reforzado. Un nivel bajo todavía necesita dueño, propósito, datos permitidos y fecha de revisión. No presentes prioridad como probabilidad medida si no tienes evidencia. El inventario asigna recursos; los escenarios y riesgos residuales viven en el registro de riesgos. Enlaza evidencia vigente. Cada registro puede apuntar a arquitectura, evaluación, política, revisión de proveedor, contrato, prueba de permisos, riesgos, plan de incidente, monitoreo y salida. Guarda propietario, versión y fecha. Un enlace roto o un documento sin alcance no demuestra control. Mide la calidad del propio inventario: sistemas sin dueño, revisión vencida, versión desconocida, producción sin fallback, permisos no confirmados, evidencia caducada y componentes sin consumidor. Minimiza información sensible. Registra una referencia a secretos o datos restringidos sin copiar valores. Limita acceso al inventario según función y conserva historial de cambios. Mantén el inventario por eventos y conciliación. Un nuevo proveedor, modelo, dato, permiso, integración, entorno, grupo de usuarios, incidente, cambio contractual, pausa o retiro debe actualizar la ficha. Concilia periódicamente con compras, SSO, nube, repositorios, contratos e entrevistas. Que nadie reporte cambios no demuestra que la lista esté completa. Busca herramientas nuevas y servicios retirados que todavía reciben tráfico. Cada revisión termina en mantener, completar, limitar, evaluar, pausar, reanudar, consolidar o retirar. Mide cobertura y vigencia, no el número de filas. Descubrir más sistemas puede mejorar el control aunque el total aumente. En el inventario, Cerravi debe aparecer por los casos de uso realmente habilitados. El copiloto organiza contexto y propone siguientes pasos para revisión humana. No envía mensajes ni cambia etapas automáticamente. Las propuestas utilizan productos y precios disponibles en el catálogo. Si falta un importe, se requiere confirmación; Cerravi no inventa la cifra. Las 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; no es un modelo predictivo entrenado o calibrado como machine learning y no garantiza cierres. Un inventario útil conserva estos límites junto con responsables, datos, permisos, evidencia y estado.

Evaluar a un proveedor de AI Sales Copilot no consiste en preguntar si usa inteligencia artificial responsable y guardar la respuesta. El producto visible puede depender de modelos, datos, APIs, búsqueda, nube, identidad, conectores, bibliotecas y subprocesadores. Cada componente puede cambiar lo que el copiloto ve, produce y hace. La debida diligencia debe empezar antes de contratar, continuar durante la operación y terminar cuando los datos, accesos y dependencias ya fueron tratados. La empresa compradora conserva decisiones que no puede delegar: propósito, datos autorizados, efectos aceptables, supervisión, tolerancia y alternativa operativa. Un proveedor aprobado no significa uso ilimitado. La aprobación corresponde a un caso, una versión, una región, unos permisos y unas integraciones concretas. Empieza por definir el caso de uso y su materialidad. Describe la tarea: resumir actividad del CRM, preparar un correo, recomendar un siguiente paso, generar una propuesta desde el catálogo o actualizar un registro. Separa observar, redactar, recomendar, guardar, enviar y modificar. Una función de apoyo interno con revisión humana no tiene el mismo impacto que una acción sobre clientes, dinero, acceso o compromisos. Identifica personas afectadas, datos, reversibilidad, frecuencia y proceso alternativo. Registra entornos, regiones, idiomas, versiones e integraciones incluidos. Si el proveedor no confirma una condición, trátala como no demostrada. La materialidad determina la profundidad de la evidencia, las pruebas, las aprobaciones y la frecuencia de revisión. Ahora dibuja la cadena de valor desde la entrada hasta el efecto. Incluye la aplicación, modelos base y ajustados, recuperación, índices, fuentes, herramientas, alojamiento, identidad, telemetría, soporte y subprocesadores. Para cada elemento registra proveedor, versión, región, datos tratados, acceso, responsable interno y dependencia aguas abajo. Distingue flujo de datos y flujo de autoridad. Un componente puede recibir información sin poder actuar; otro puede escribir en el CRM o enviar una comunicación. Registra cuentas de servicio, secretos y permisos por organización. Pregunta qué componentes controla directamente el proveedor y cuáles obtiene de terceros. Una actualización del modelo, una biblioteca abandonada o un endpoint modificado pueden afectar calidad, seguridad o continuidad aunque la marca visible no cambie. Separa afirmaciones, artefactos, pruebas y señales operativas. Una respuesta comercial orienta, pero no demuestra que un control exista. Convierte cada afirmación material en una pregunta verificable y pide el artefacto correspondiente: documentación, diagrama, reporte independiente, configuración, historial de cambios, procedimiento o resultado de prueba. Confirma producto, servicio, región, versión y fecha. Un certificado puede respaldar un programa sin demostrar una función concreta. Una prueba propia demuestra un recorrido sin cubrir toda la infraestructura. Combina evidencias. Registra faltantes y contradicciones. No completes con una interpretación favorable una retención desconocida, un cambio sin aviso o una responsabilidad ambigua. La decisión puede ser aprobar con límites, pedir corrección, añadir un control compensatorio, reducir el alcance o descartar la dependencia. Aclara el tratamiento de datos, privacidad, propiedad intelectual y procedencia. Documenta qué información recibe cada tercero, con qué propósito, dónde se procesa, cuánto se conserva y cómo se elimina. Pregunta si entradas, salidas, feedback o telemetría se utilizan para entrenamiento o mejora, bajo qué configuración y con qué excepciones. Separa producción, soporte, evaluación y seguridad porque pueden seguir rutas distintas. Revisa residencia, transferencias, subprocesadores, respaldos y recuperación. Examina procedencia y derechos sobre datos, modelos y salidas, además de mecanismos de reporte y reclamación. La ubicación técnica no resuelve por sí sola las obligaciones aplicables. Contratos, propiedad intelectual y protección de datos requieren revisión profesional según país, sector e información utilizada. Comprueba seguridad, identidad y respuesta a incidentes. Revisa autenticación, separación entre organizaciones, roles, mínimo privilegio, sesiones, administración, secretos y registros. Confirma que lectura, escritura y acciones sensibles puedan limitarse por separado. Una conexión funcional no necesita autoridad adicional por comodidad. Pregunta por gestión de vulnerabilidades, dependencias de software, divulgación responsable, respaldos, continuidad y contacto de incidentes. Define notificaciones y cooperación en documentos aplicables cuando correspondan. La empresa también necesita su propio mecanismo de pausa, revocación y contención. Prueba la baja de un usuario, la rotación de un secreto y la pérdida de un permiso. Los logs deben permitir reconstruir accesos y acciones sin almacenar contenido innecesario. Evalúa calidad, límites, versiones y cambios. Pide documentación sobre capacidades, idiomas, uso previsto, limitaciones y condiciones de evaluación. No traslades una métrica pública a tu proceso sin comprobar población, tarea y criterio. Construye un conjunto propio con casos normales, información incompleta, conflicto entre fuentes, instrucciones externas, permisos insuficientes y solicitudes fuera del alcance. Aclara cómo se identifican versiones, qué puede cambiar sin aviso, qué periodos de deprecación existen y si puedes fijar, probar o revertir una versión. Incluye cambios de filtros, políticas, herramientas y límites de servicio. Define aceptación por escenario y mide utilidad, corrección, fundamento, consistencia, abstención, escalación, latencia y efecto operativo. Repite los casos críticos cuando cambien modelo, prompt, fuente, integración, permiso o proveedor. Asigna responsabilidades entre proveedor y cliente. Construye una matriz con cuatro estados: control del proveedor, control del cliente, control compartido y evidencia esperada. Incluye configuración segura, usuarios, clasificación de datos, monitoreo, soporte, incidentes, cambios, respaldos, eliminación y salida. Compartido no significa que nadie sabe quién actúa primero. Las condiciones materiales deben aparecer en documentos aplicables: servicio, regiones, subprocesadores, uso de datos, notificaciones, soporte, conservación, portabilidad y cooperación ante incidentes. Cuando el riesgo lo justifique, solicita evidencia acordada o derechos de evaluación sujetos a revisión legal. Si una condición crítica no puede obtenerse, reduce datos, permisos o dependencia. No ocultes la incertidumbre detrás de una aceptación genérica. Realiza una prueba controlada que incluya fallas y recuperación. Utiliza un entorno aislado y datos sintéticos o minimizados cuando sea posible. Ejecuta el recorrido completo: acceso, recuperación, generación, revisión, registro y efecto. Deben participar negocio, operación, datos, seguridad y quienes administrarán la integración. Una demo guiada no sustituye la ejecución del equipo. Incluye un precio faltante, dos monedas, una fuente vencida, una instrucción maliciosa, un permiso revocado, una API lenta, un modelo no disponible y una respuesta incompleta. Observa si el sistema conserva la duda, evita inventar, informa el límite y ofrece una ruta segura. Prueba también pausa, proceso manual y recuperación. Registra versión, rol, esperado, observado, evidencia, severidad y decisión. Monitorea cambios, desempeño y concentración. Define señales sobre disponibilidad, latencia, errores, correcciones humanas, abstenciones, incidentes, nuevas versiones, deprecaciones, subprocesadores, documentación y soporte. Cada indicador necesita fuente, responsable, umbral y respuesta. El estado publicado por el proveedor complementa, pero no sustituye, la observación del recorrido propio. Varias funciones pueden depender del mismo modelo, nube, identidad o índice aunque parezcan productos distintos. Un fallo común puede afectar propuestas, seguimiento y análisis a la vez. Registra dependencias compartidas y orden de recuperación. Revisa por cadencia y por eventos: nueva función, región, clase de datos, integración, incidente, cambio contractual, adquisición, degradación o fin de soporte. Diseña contingencia, portabilidad y salida antes de depender. Define qué trabajo debe continuar, con qué datos, durante cuánto tiempo y quién activa el modo alternativo. El fallback puede ser otro proveedor, una versión estable, una capacidad limitada o un proceso manual, pero debe probarse. Aclara formatos de exportación y qué historial, configuraciones, prompts, evaluaciones y registros podrás recuperar. Identifica componentes portables y dependencias difíciles de sustituir. El plan de salida cubre comunicación, congelamiento de cambios, transferencia, revocación de cuentas y secretos, detención de integraciones, tratamiento de datos, verificación y excepciones temporales. No esperes a un incidente o a la renovación para descubrir que no existe una ruta operativa. En Cerravi, el copiloto organiza contexto y propone siguientes pasos para revisión humana. No envía mensajes ni cambia etapas automáticamente. Las propuestas utilizan productos y precios disponibles en el catálogo. Si falta un importe, el sistema debe mostrar el faltante y esperar confirmación; no inventa la cifra. Las monedas permanecen separadas salvo que exista una conversión aprobada. La actividad de una Buyer Room aporta señales, pero no confirma identidad, aceptación, firma, pago ni intención. Forecast utiliza reglas transparentes del CRM; no es un modelo predictivo entrenado o calibrado como machine learning y no garantiza cierres. Estos límites deben compararse con el uso previsto. Una buena evaluación hace visible qué controla el proveedor, qué controla tu empresa y qué ocurrirá cuando una dependencia cambie, falle o deje de servir.

Un registro de riesgos para un AI Sales Copilot no es una lista de palabras como privacidad, sesgo o alucinación. Es una memoria de decisiones. Cada fila explica un escenario concreto, la persona responsable, los controles existentes, la evidencia que demuestra su funcionamiento, el riesgo que todavía permanece y el momento en que debe revisarse. El objetivo no es afirmar que el sistema no tiene riesgos. Es conseguir que los riesgos importantes sean visibles, comparables y tratables durante todo el ciclo de vida. Empieza por definir el alcance. Describe para qué se usa el copiloto, quién lo opera, qué decisiones apoya y qué efectos puede producir. Separa preparar un borrador, recomendar un siguiente paso, consultar una fuente y ejecutar una acción. Registra el modelo, las instrucciones, la recuperación, el CRM, el catálogo, los archivos, la memoria, los permisos, las herramientas, las validaciones y la interfaz. Añade la versión activa y una alternativa manual. Si no puedes reconstruir qué sistema evaluaste, no podrás saber si el control sigue vigente después de un cambio. Después relaciona los activos, las personas y las dependencias. Identifica precios, descuentos, contactos, documentos, credenciales, historial, propuestas, reputación y continuidad operativa. Señala quién crea, consulta, modifica, aprueba y recibe cada elemento. Incluye modelos, herramientas, complementos, fuentes de datos, conectores e identidad dentro del límite de seguridad. Un componente auxiliar también puede cambiar lo que el copiloto ve y hace. Distingue a la persona dueña del activo, a la dueña del riesgo y a quien opera cada control. Escribe el riesgo como causa, evento e impacto. Por ejemplo: una nota externa contiene una instrucción maliciosa; el copiloto la trata como autoridad; y prepara una acción con datos fuera del alcance. Esta estructura permite saber qué probar y dónde intervenir. Evita registrar solo fuga, error o alucinación. Separa además el riesgo futuro de un hallazgo observado, un incidente con impacto, un problema pendiente y una excepción temporal. Pueden relacionarse, pero no siguen el mismo proceso. Valora primero el riesgo inherente, antes de considerar controles específicos. Evalúa el impacto y la posibilidad o exposición con criterios observables. Un impacto crítico puede incluir acceso entre organizaciones, divulgación sensible, acción irreversible o compromiso comercial no autorizado. Una exposición alta puede indicar muchos usuarios, uso frecuente y pocas condiciones necesarias. Si la probabilidad es desconocida, dilo. Utiliza frecuencia, superficie, accesibilidad y capacidad de propagación. Multiplicar números no crea precisión cuando la evidencia no existe. Asigna una persona responsable con autoridad real. Debe poder reunir evidencia, pedir cambios, escalar y presentar el riesgo residual a quien puede aceptarlo. Un comité participa, pero no sustituye un nombre y un respaldo. Separa a quien posee el riesgo de quien opera el control. Seguridad puede mantener permisos, Datos puede corregir una fuente y Ventas puede aprobar condiciones. Registra también quién puede aceptar, pausar y reanudar. La fecha de lanzamiento nunca reemplaza esa autoridad. Vincula controles que interrumpan el escenario. Los preventivos reducen la posibilidad: mínimo privilegio, separación entre datos e instrucciones, validaciones y aprobación previa. Los detectivos encuentran un desvío mediante alertas, evaluación, monitoreo y revisión. Los correctivos eliminan la causa. Los de recuperación contienen, revierten y mantienen el proceso esencial. Para cada control registra responsable, cobertura, estado, versión, frecuencia y dependencia. Una advertencia dentro del prompt no sustituye un permiso o una validación determinista. Exige evidencia que otra persona pueda revisar. Registra qué se probó, con qué versión, bajo qué rol, cuál era el resultado esperado y qué ocurrió. Enlaza pruebas automáticas, ejercicios de red teaming, revisiones de acceso, muestras protegidas, aprobaciones y simulacros de pausa. No copies información sensible dentro de la tabla. Conserva una referencia restringida, aplica minimización y define retención. Añade una fecha de vigencia: una prueba anterior a un cambio de modelo, fuente, permiso o herramienta puede dejar de demostrar la eficacia actual. Ahora evalúa el riesgo residual: lo que permanece después de los controles. No lo calcules restando una puntuación de manera automática. Revisa qué parte del escenario sigue abierta, qué tan confiable es la evidencia y qué condición podría degradar la protección. La respuesta puede ser mitigar, evitar, transferir o aceptar. Aceptar necesita autoridad, justificación, vigencia, condiciones y monitoreo. Si el residual supera la tolerancia, limita el alcance, vuelve al proceso manual, pausa o retira la función. Conecta el registro con el resto de la operación. La evaluación comprueba comportamiento esperado. El red teaming busca rutas adversarias. El monitoreo detecta cambios. El feedback aporta observaciones reales. Los incidentes muestran dónde fallaron el escenario o sus controles. No abras un riesgo nuevo por cada alerta: vincula señales a un escenario existente y crea otro solo cuando cambien la causa, el evento o el impacto. Revisa los riesgos cuando cambien modelo, prompt, fuente, permiso, herramienta, interfaz o autonomía. Mantén una cadencia y revisa también por eventos. Cada sesión debe terminar en una decisión: mantener, investigar, mejorar el control, limitar, aceptar por un periodo, pausar, transferir o retirar. Conserva el historial y la persona que aprobó. Archiva un riesgo cuando el escenario desaparece, no cuando deja de ser cómodo. Busca deuda operativa: filas sin responsable, controles sin prueba, aceptaciones vencidas, excepciones permanentes y riesgos duplicados. En Cerravi, las sugerencias requieren revisión humana y no se convierten automáticamente en decisiones. Las propuestas utilizan productos y precios disponibles en el catálogo. Si falta un importe, Cerravi muestra el faltante y espera confirmación; no inventa la cifra. Las monedas permanecen separadas sin una conversión aprobada. Una apertura de Buyer Room aporta contexto, pero no confirma aceptación, contrato, pago ni intención. Forecast es una estimación operativa basada en reglas transparentes del CRM, no una garantía. Un buen registro mantiene estos límites visibles, asignados y comprobables.

Retirar un AI Sales Copilot no significa que el proyecto fracasó. Puede dejar de cumplir su propósito, duplicar otra herramienta, perder soporte, costar más de lo que aporta o conservar un riesgo que la organización ya no acepta. También puede retirarse solo una fuente, una integración, una acción o una versión. Primero distingue el retiro de una pausa, un rollback y la contención de un incidente. La pausa es temporal. El rollback restaura una versión conocida. La contención limita un impacto urgente. El retiro decide que un alcance ya no debe seguir disponible. Sustenta la propuesta con evidencia. Revisa uso útil, calidad, incidentes, soporte, dependencia manual, costos confirmados, obsolescencia y capacidad de mantener controles. Poco uso no demuestra falta de valor si hubo problemas de acceso o capacitación. Haber invertido tiempo tampoco justifica conservar el sistema. Antes de apagar, construye un inventario. Incluye modelo, prompts, fuentes, identidades, permisos, herramientas, integraciones, webhooks, tareas programadas, endpoints, secretos, almacenamiento, reportes, alertas y materiales. Busca dependencias en ambas direcciones. El CRM puede alimentar al copiloto y, al mismo tiempo, una automatización puede depender de su resultado. Clasifica cada componente como retirar, transferir, conservar temporalmente, archivar o revisar. Asigna una persona responsable y evidencia de cierre. Después define autoridad y alcance. Negocio confirma propósito y continuidad. Operación coordina. Tecnología gestiona componentes. Datos decide el tratamiento. Seguridad revoca accesos. Privacidad y legal revisan obligaciones. Soporte comunica. Registra qué se retira, qué permanece, las condiciones y quién puede detener el proceso. Prepara el trabajo sustituto. Para cada tarea esencial define el sistema alternativo o el modo manual, con instrucciones, responsables, acceso, datos, capacidad y soporte. Probar la alternativa evita descubrir después que una vista, un precio o una aprobación ya no están disponibles. Comunica mediante hitos: anuncio, transición, límite para dependencias nuevas, retiro técnico y confirmación de cierre. Explica qué cambia, qué deben hacer los usuarios, dónde está la alternativa y cómo reportar una dependencia desconocida. No prometas eliminar o conservar todos los datos antes de revisar las reglas aplicables. Clasifica entradas, salidas, conversaciones, logs, evaluaciones, configuraciones y datos derivados. Decide qué transferir, preservar, restringir o eliminar, con propósito, responsable, ubicación, acceso y periodo. Copiar todo al sistema sustituto puede ampliar el riesgo; borrar sin orden puede destruir evidencia necesaria. Revoca identidades y secretos de forma controlada. Incluye usuarios, cuentas de servicio, roles, sesiones, tokens, claves, certificados, conectores y permisos externos. Eliminar la pantalla no invalida un token guardado en el CRM. Desactiva por etapas. Congela cambios, migra consumidores, detén jobs y webhooks, revoca acceso y apaga componentes. Observa tráfico, errores, colas, autenticaciones, tickets y tareas manuales. Una interfaz sin uso no prueba que una integración de fondo dejó de llamar. Comprueba el cierre. Los endpoints retirados no aceptan llamadas, las identidades no se autentican, los secretos están rotados, los jobs no corren y los usuarios siguen el proceso sustituto. Registra excepciones y componentes temporales con dueño y fecha. Una reactivación futura debe volver a pasar por versión, pruebas, permisos y aprobación. En Cerravi, las sugerencias requieren revisión humana, los precios proceden del catálogo disponible y las monedas permanecen separadas. El copiloto organiza contexto; no garantiza cierres ni sustituye la responsabilidad operativa de la empresa.