Cómo crear una matriz de decisiones para recuperar un AI Sales Copilot

La matriz hace explícita la decisión; no decide por el equipo

Cuando un copiloto falla, la pregunta rara vez es solo si debe seguir encendido. El equipo puede restringir una función, exigir aprobación humana, pasar a un proceso manual, revertir una configuración, restaurar datos, aislar una dependencia o detener por completo. Una matriz ordena esas alternativas para que la respuesta no dependa de memoria, jerarquía informal o presión comercial.

Su valor está en conectar evidencia con una acción autorizada. NIST AI RMF describe la gestión de riesgos de IA como un proceso continuo, contextual y documentado, no como una lista universal. Por eso la matriz debe mostrar qué señales se observan, qué incertidumbre permanece, quién decide, qué control compensa el riesgo y qué prueba permite avanzar.

No conviertas una suma de colores en piloto automático. Una puntuación puede ayudar a comparar casos, pero una condición crítica debe prevalecer: posible exposición entre organizaciones, pérdida de integridad, acción no autorizada, precio incorrecto enviado o imposibilidad de identificar el alcance pueden justificar aislamiento o pausa aunque el promedio parezca bajo.

Define el límite de la decisión y el momento de activación

Especifica qué servicio, versión, organización, integración y recorrido comercial cubre la matriz. “Copilot” es demasiado amplio: redactar un correo, consultar el catálogo, sugerir el siguiente paso, generar una propuesta y escribir en el CRM tienen impactos y opciones de recuperación diferentes.

Activa la matriz cuando una alerta, reporte, prueba o cambio confirmado supera el manejo cotidiano. Puede tratarse de resultados fuera de política, permisos inesperados, datos inconsistentes, una dependencia indisponible, degradación sostenida, una versión defectuosa o un incidente en investigación. Registra quién abre la evaluación y el identificador que une métricas, tickets, decisiones y comunicaciones.

Separa el disparador de la conclusión. Una señal abre el análisis; no demuestra por sí sola la causa ni el alcance. Define además cuándo volver a evaluar: al aparecer nueva evidencia, cambiar el impacto, completar una contención, vencer un límite temporal o recibir información relevante de un proveedor.

Reúne un paquete mínimo de hechos antes de comparar opciones

La primera versión puede ser incompleta, pero debe ser utilizable. Incluye hora y zona horaria, función afectada, versión de modelo, prompt o configuración, fuente del dato, cuentas potencialmente involucradas, acciones ya realizadas, síntomas observados y nivel de confianza. Marca cada elemento como confirmado, probable, descartado o pendiente.

Añade el recorrido comercial: qué personas pudieron ver una sugerencia, si un mensaje o propuesta salió del sistema, si existe una fuente autorizada para reconstruirlo y qué actividad ocurrió después. Una salida equivocada descartada por el vendedor no tiene la misma propagación que un documento abierto por un cliente.

No esperes causa raíz para contener. Sí exige suficiente evidencia para distinguir opciones incompatibles. Si desconoces si el problema está en código, configuración o datos, una reversión apresurada puede ocultar señales o reintroducir información incorrecta. Conserva referencias a logs, versiones y muestras sin copiar secretos ni datos personales a la matriz.

Evalúa dimensiones que cambian la ruta de recuperación

Usa dimensiones observables: impacto en clientes y operación; propagación; integridad y confidencialidad de datos; reversibilidad; confianza de la evidencia; criticidad del proceso; existencia y capacidad del modo manual; dependencia de terceros; y tiempo disponible antes de que el daño aumente. Define ejemplos locales para que dos equipos interpreten cada nivel de forma parecida.

Mantén por separado magnitud y certeza. Un impacto potencial alto con evidencia todavía débil puede exigir contención preventiva y más investigación, no una declaración concluyente. Un impacto moderado con evidencia sólida y propagación activa puede requerir una acción más rápida que un riesgo hipotético mayor.

Documenta también lo que no puede medirse. NIST AI RMF recomienda registrar límites de las métricas y usar evidencia cualitativa y cuantitativa. En ventas B2B, una sola condición comercial incorrecta puede ser material aunque el porcentaje agregado sea pequeño; el denominador no elimina el contexto del caso.

• Impacto actual y posible si continúa la operación.
• Alcance conocido, propagación y posibilidad de localizar destinatarios.
• Integridad, confidencialidad y fuente autorizada de los datos.
• Reversibilidad técnica y comercial de cada acción.
• Capacidad real del proceso alterno y riesgo residual.

Establece líneas rojas que anulan cualquier promedio

Define condiciones que obligan a aislar, detener o escalar sin esperar una puntuación completa. Ejemplos posibles son acceso entre organizaciones, uso de credenciales no autorizado, pérdida de la fuente de precios, corrupción que sigue propagándose, incapacidad de revocar una integración, datos sensibles expuestos o comportamiento que puede ejecutar acciones fuera del alcance aprobado.

Cada línea roja necesita una respuesta inicial, una autoridad y una prueba de salida. “Pausar por seguridad” no basta: indica si se deshabilita una función, se bloquea una credencial, se corta una cola, se conserva evidencia o se activa el proceso manual. Limita la acción al alcance necesario cuando pueda hacerse sin ampliar el riesgo.

Revisa estas condiciones con seguridad, privacidad, legal, negocio, tecnología y responsables locales. No copies plazos ni umbrales de otra empresa. Contratos, sector, arquitectura, datos y jurisdicción pueden modificar la decisión. La matriz debe activar revisión competente, no fingir que la reemplaza.

Describe las opciones operativas y sus requisitos previos

Construye un menú de respuestas antes del incidente. Mantener operación normal exige evidencia de que el control funciona. Limitar alcance puede desactivar una herramienta, organización, canal o tipo de documento. La revisión humana obligatoria reduce automatización, pero solo sirve si hay capacidad, instrucciones y autoridad para rechazar.

El modo degradado conserva una parte segura del servicio; el modo manual sustituye temporalmente la función. Revertir vuelve a una versión conocida de código, prompt, configuración o modelo. Restaurar recupera datos desde una copia; conciliar integra después las operaciones válidas realizadas durante el intervalo. Aislar corta una integración o credencial. Pausar detiene el uso; retirar cierra una capacidad de forma controlada.

Para cada opción registra alcance, responsable, tiempo estimado, dependencias, datos necesarios, riesgo residual, capacidad disponible, comunicación y criterio de éxito. Una alternativa que no ha sido probada no es una recuperación confiable. Si el modo manual solo soporta diez casos por día, el equipo debe priorizar y comunicar esa limitación.

Relaciona señales, opción, requisito y autoridad en una sola vista

La matriz debe permitir que una persona entienda por qué una opción es viable sin leer todo el incidente. Coloca señales y condiciones en filas; muestra respuesta sugerida, requisito previo, decisión responsable y prueba para avanzar. Añade una columna de excepciones para los casos en que una línea roja cambie la ruta.

Evita reglas absolutas basadas en una sola métrica. “Error mayor a cinco por ciento” no explica muestra, impacto ni distribución. Es mejor combinar una condición verificable con contexto: resultados no autorizados confirmados en producción, propagación activa, imposibilidad de identificar destinatarios y ausencia de un control compensatorio.

Usa lenguaje operativo. “Mitigar” no dice qué hacer. “Deshabilitar generación de propuestas para la organización afectada, conservar consulta al catálogo y exigir aprobación del responsable comercial” sí define alcance, continuidad y dueño.

No confundas rollback, restauración y conciliación

Un rollback cambia software, configuración, prompt o modelo a una versión anterior. No deshace automáticamente mensajes enviados, propuestas compartidas ni registros ya modificados. Antes de revertir confirma compatibilidad de esquema, migraciones, dependencias, credenciales y datos producidos por la versión nueva.

Una restauración recupera datos desde un punto conocido. Puede eliminar operaciones válidas posteriores si se aplica sin analizar el intervalo. Por eso se prueba en un entorno aislado, se valida integridad y se construye un delta con altas, cambios y actividades legítimas que deben conservarse.

La conciliación resuelve diferencias entre la copia recuperada, fuentes autorizadas y trabajo realizado durante la degradación. Define precedencia por campo, conflictos, lotes, responsables y criterios de aceptación. Restaurar sin conciliar puede devolver el sistema y perder el negocio; conciliar sin evidencia puede consolidar el error.

Diseña el modo manual como un control temporal con capacidad finita

El modo manual debe indicar qué actividades continúan, cuáles se pausan y dónde se registra cada acción. Usa fuentes autorizadas para precios, condiciones, contactos y etapas. Evita hojas paralelas sin dueño; si son necesarias, asigna acceso, campos mínimos, versión, retención y plan de importación o destrucción.

Calcula capacidad por función y periodo. Si la revisión humana obligatoria genera una cola que supera la capacidad, el control existe solo en papel. Prioriza por impacto comercial y riesgo, establece turnos, límites y escalamiento, y comunica qué tiempos son estimaciones operativas, no promesas universales.

Antes de volver a automatizar, concilia lo realizado manualmente, elimina duplicados y confirma responsables. Conserva la relación entre la actividad temporal y el registro final. La recuperación no termina cuando la pantalla vuelve a cargar; termina cuando el proceso puede operar sin perder ni duplicar decisiones.

Registra la decisión, el desacuerdo y la evidencia utilizada

Cada decisión debe incluir hora, alcance, opción elegida, alternativas descartadas, evidencia disponible, incertidumbre, riesgo residual, responsable, aprobaciones, próxima revisión y condición de salida. Vincula los artefactos originales en lugar de copiarlos sin control.

Registra desacuerdos materiales. Si seguridad recomienda aislar y negocio propone modo manual, conserva las razones y quién resolvió. Esto no busca culpas; permite revisar si la autoridad, la información o la matriz funcionaron. También evita reconstruir la historia desde mensajes dispersos.

Distingue decisión temporal y definitiva. Limitar una función durante treinta minutos puede ser una contención mientras se decide rollback o pausa. Coloca vencimiento a controles temporales: una excepción sin fecha, dueño ni revisión puede convertirse en la operación normal sin haber sido aceptada.

Reanuda por etapas con un gate verificable

Define qué debe comprobarse antes de reanudar: causa o condición controlada, versión identificada, pruebas relevantes aprobadas, permisos válidos, datos conciliados, dependencias disponibles, capacidad de observación, comunicación preparada y persona autorizada. No exijas causa raíz completa si una recuperación segura puede demostrarse, pero registra lo que sigue abierto.

Empieza con un alcance pequeño: entorno interno, datos de prueba, una organización controlada o una función sin escritura. Observa resultados, errores, latencia, permisos, integridad y comportamiento humano. Aumenta el alcance solo después de cumplir el gate; si aparece una señal de retroceso, vuelve a la opción segura definida.

NIST SP 800-184 destaca la planificación, los playbooks, las pruebas y la mejora continua. Convierte esos principios en evidencia local: quién ejecutó, qué casos se probaron, qué resultado se esperaba, qué ocurrió y quién autorizó el siguiente paso. “Se ve bien” no es un criterio de reanudación.

Vincula cada cambio de estado con una comunicación comprobable

La decisión operativa y el mensaje deben partir de la misma bitácora. Informa qué función está limitada, qué alternativa existe, quién debe actuar y cuándo se revisará el estado. No conviertas una acción temporal en promesa de solución ni publiques una causa que todavía es hipótesis.

Adapta el detalle. El equipo de respuesta necesita señales y responsables; Ventas y soporte necesitan instrucciones para casos reales; dirección necesita impacto, opciones y riesgo residual; un cliente afectado necesita hechos relacionados con su alcance y acciones útiles. Los requisitos de notificación dependen del caso y deben revisarse con las funciones competentes.

Cuando se reanuda, explica qué vuelve a estar disponible, qué límites permanecen y cómo reportar anomalías. Distingue servicio recuperado, investigación terminada y remediación completa. Pueden ser hitos distintos y no deben comprimirse en una palabra como “resuelto”.

Prueba la matriz, revisa los resultados y retira opciones inviables

Ejecuta ejercicios con escenarios distintos: recomendación incorrecta sin propagación, propuesta enviada con dato no autorizado, integración que escribe fuera del alcance, pérdida de integridad y proveedor indisponible. Mide tiempo para reunir hechos, decidir, ejecutar, comunicar y volver a evaluar. Observa también decisiones que se retrasaron o dependieron de una sola persona.

Actualiza la matriz cuando cambien arquitectura, modelos, integraciones, datos, procesos comerciales, contratos, responsables o capacidad manual. Elimina rutas que ya no puedan ejecutarse y prueba nuevas dependencias. Una versión extensa y desactualizada puede ser más peligrosa que una tabla corta que el equipo conoce.

Cierra con una revisión sin buscar culpables. Ajusta líneas rojas, requisitos, autoridad, playbooks, monitoreo y capacitación. 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. Cada organización decide su recuperación, obligaciones y tolerancia al riesgo según su propio contexto.