Respuesta directa
En pocas palabras
Para gestionar una excepción de política de un AI Sales Copilot, identifica el requisito que no puede cumplirse, delimita caso, versión, datos, usuarios, acciones y duración, evalúa el riesgo de ese desvío, compara alternativas, exige controles compensatorios verificables y obtiene aprobación de la autoridad correcta. La excepción debe activarse con vencimiento técnico, monitoreo, criterios de pausa y una decisión final de cerrar, renovar con nueva evidencia o convertir el cambio en política.
Una excepción administra un desvío; no borra el requisito
Una excepción permite operar durante un alcance y un tiempo definidos cuando el camino normal no puede cumplirse todavía o impediría una necesidad legítima. No declara que la política era innecesaria, no convierte el riesgo en aceptable por defecto y no autoriza funciones que la organización no tiene facultad para permitir.
El proceso debe conservar el requisito original, la razón concreta del desvío, la exposición adicional, la autoridad que decide y las condiciones que terminan el permiso. Si basta con corregir una configuración, completar una revisión o utilizar el flujo aprobado, no hace falta una excepción: hace falta terminar el trabajo.
NIST AI RMF Manage 1.3 reconoce respuestas como mitigar, transferir, evitar o aceptar y pide planificarlas y documentarlas conforme a tolerancias establecidas. Esta guía aplica ese principio a una autorización temporal para ventas B2B; no reproduce una obligación universal ni sustituye revisión legal o regulatoria.
Distingue excepción, cambio, incidente y aceptación de riesgo
Una excepción autoriza temporalmente apartarse de un requisito. Un cambio modifica una versión, fuente, permiso, herramienta, regla o proceso y debe seguir control de cambios. Un incidente responde a un efecto no deseado que requiere contención y recuperación. La aceptación de riesgo es una respuesta formal a un escenario residual dentro de la tolerancia definida.
Estas rutas pueden relacionarse sin confundirse. Un incidente puede descubrir que hace falta una excepción breve para mantener continuidad; una excepción puede incluir un cambio compensatorio; y su aprobación puede aceptar una exposición residual. Cada artefacto conserva propósito, autoridad, evidencia y cierre propios.
No uses la etiqueta de piloto para evitar controles. Si una prueba accede a datos de producción, llega a clientes o puede ejecutar una acción material, clasifica el recorrido real. Tampoco llames emergencia a una solicitud repetida que pudo planearse.
Exige una solicitud que permita decidir
Registra identificador, solicitante, dueño del caso, requisito afectado y redacción exacta del desvío. Delimita producto, versión, entorno, usuarios, clientes, regiones, datos, fuentes, permisos, herramientas, acciones, volumen y fechas. Una solicitud como permitir el copiloto temporalmente no tiene frontera verificable.
Explica la necesidad comercial y por qué el camino conforme no está disponible. Añade alternativas estudiadas, costo operativo de esperar, dependencias y fecha esperada de remediación. Conserva enlaces a arquitectura, inventario, clasificación de riesgo, evaluaciones, pruebas y registro de riesgos.
Declara supuestos y faltantes. Si no se conoce qué datos procesa un conector, quién recibe una salida o si una acción puede revertirse, la incertidumbre forma parte del riesgo. No completes el formulario con respuestas favorables que nadie demostró.
Define solicitudes que no pueden resolverse por excepción
Publica criterios de rechazo antes de recibir presión. Una excepción interna no puede anular una ley, una obligación contractual, una prohibición aplicable o el derecho de una persona. Tampoco debe autorizar secretos dentro de prompts, acceso entre organizaciones, credenciales compartidas o acciones fuera de la autoridad disponible.
Rechaza o devuelve solicitudes sin dueño, alcance verificable, fecha de salida, evidencia suficiente o capacidad para operar los 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 no debe convertirse en sustituto del presupuesto, personal o mantenimiento. Las renovaciones repetidas para el mismo faltante indican deuda estructural. Escala la decisión de financiar, rediseñar, retirar o cambiar la política.
Evalúa el riesgo incremental del desvío
Compara dos estados: el recorrido conforme y el recorrido con la excepción. Describe qué barrera falta, qué escenario se vuelve posible y qué personas, datos, decisiones u operaciones quedan más expuestos. No vuelvas a calificar todo el producto si el permiso afecta una sola integración o audiencia.
Valora severidad, alcance, duración, frecuencia, detectabilidad, reversibilidad, propagación y dependencia. Revisa si aumenta la autoridad del agente, si elimina una revisión humana, si amplía datos o usuarios y si el equipo puede detener el efecto. Conserva evidencia y confianza; una escala ordinal no es una probabilidad medida.
Conecta el escenario con el registro de riesgos. El nivel de riesgo del caso determina profundidad de revisión, mientras la evaluación de la excepción explica el cambio de exposición. Si el residual queda fuera de tolerancia o no puede estimarse con evidencia suficiente, no apruebes el desvío tal como fue solicitado.
Prefiere la alternativa más estrecha y controles comprobables
Antes de aceptar, intenta una ruta conforme, un entorno aislado, datos sintéticos, menor audiencia, permiso de solo lectura, aprobación por operación, menor volumen o proceso manual. Google Cloud recomienda que las excepciones a políticas sean tan estrechas como sea posible y que las personas que deciden puedan 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, cuota o destino; exigir doble aprobación; redactar datos; mantener logs; 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, evidencia de prueba, cobertura, dependencia, señal de falla y fecha de verificación. Distingue implementado de planeado. Si el permiso solo es aceptable después de aplicar el control, la activación debe depender de esa evidencia.
Separa solicitud, evaluación y aceptación
La persona que necesita la excepción explica el caso, pero no debe aprobar por sí sola el riesgo que introduce. Define con una matriz RACI quién prepara, valida dominio, revisa seguridad, privacidad, datos y operación, y quién acepta finalmente según materialidad.
La decisión debe ser aprobar, aprobar con condiciones, devolver por evidencia, rechazar o escalar. Registra alcance autorizado, controles previos, residual aceptado, fecha de inicio, vencimiento, criterios de pausa, frecuencia de revisión y firmas o equivalentes trazables. No cambies la solicitud aprobada después de la firma.
Evita la aprobación por silencio. También evita comités donde todas las personas aparecen como responsables y ninguna tiene autoridad final. Un suplente puede decidir solo dentro de facultades documentadas.
Convierte el vencimiento en una propiedad técnica
Activa la excepción mediante una configuración identificable, no con una instrucción informal. Cuando sea posible, utiliza acceso just-in-time, grupos dedicados, flags, cuotas, reglas condicionadas o credenciales con expiración. Vincula el identificador de la excepción con cambios, logs y alertas.
Define inicio y fin con zona horaria. El valor seguro al vencer es retirar el permiso o volver al recorrido conforme; no renovar automáticamente. Si una expiración abrupta puede interrumpir un proceso crítico, prepara continuidad y avisos previos sin convertirlos en extensión silenciosa.
Prueba la activación y la reversión antes de producción. Confirma que solo el alcance aprobado recibe la excepción, que el control no puede heredarse 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 con el desvío. Etiqueta eventos con excepción y versión. Sin esa relación, el equipo no puede saber si la exposición permanece dentro del alcance aceptado.
Define señales de pausa: uso fuera de audiencia, dato no autorizado, control compensatorio inactivo, acción inesperada, volumen superior al aprobado, 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 o detalles que faciliten evasión. La transparencia operativa debe ayudar a detectar el desvío, no normalizarlo.
Cierra, renueva o convierte la excepción mediante una nueva decisión
Antes del vencimiento, verifica si se completó la remediación, si la necesidad desapareció o si el uso demostró una necesidad estable. Cerrar significa retirar configuración, permisos, datos temporales, alertas especiales y dependencias, comprobar el estado final y conservar evidencia.
Renovar exige una solicitud nueva o una revisión formal 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 parte legítima del proceso, cambia la arquitectura o la política mediante su propio gobierno. Una excepción no es el mecanismo para modificar silenciosamente la norma. Documenta qué aprendiste y aplica el cambio solo al alcance que la evidencia sostiene.
Mide la deuda de excepciones sin premiar el rechazo
Mantén un registro con estado 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 ocultar solicitudes o empujar equipos a operar sin registro. Tampoco midas solo cantidad; varias excepciones pueden depender del mismo modelo, conector o persona revisora y crear concentración.
Revisa tendencias con dueños de política, producto y operación. Un requisito con muchas solicitudes puede necesitar mejor implementación, comunicación o rediseño. La evidencia puede confirmar la política, revelar deuda o justificar un cambio; no presupongas la conclusión.
Conserva los límites del producto durante cualquier excepció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 herramientas o automatizaciones adicionales debe evaluar y aprobar ese recorrido completo. Una excepción interna no amplía por sí sola las capacidades publicadas del producto.
Las propuestas utilizan productos y precios presentes en el catálogo. Si falta un importe, se confirma; no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. No debe autorizarse por excepción una regla que fabrique precios o agregue 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. Una excepción puede modificar un control operativo aprobado por la empresa; no convierte una inferencia en hecho.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuánto debe durar una excepción para un AI Sales Copilot?
Debe durar solo lo necesario para resolver la necesidad o completar la remediación. No existe un plazo universal. La fecha debe relacionarse con una acción verificable, una persona responsable, avisos previos y vencimiento técnico; no con una renovación automática.
¿Quién puede aprobar una excepción de IA?
La autoridad depende del nivel de riesgo, el requisito y el impacto. Negocio, producto, datos, seguridad, privacidad, riesgo o legal pueden aportar revisión, pero una sola función debe tener autoridad final documentada. La persona solicitante no debería autoaprobar el riesgo que introduce.
¿Un control compensatorio elimina el riesgo?
No necesariamente. Debe interrumpir o reducir un escenario y demostrar cobertura mediante configuración, prueba o monitoreo. El equipo todavía debe describir incertidumbre y riesgo residual y decidir si quedan dentro de la tolerancia aplicable.
¿Se puede renovar una excepción vencida?
Puede evaluarse una nueva autorización, pero no debe extenderse por silencio. Hace falta evidencia de uso, controles vigentes, residual actualizado, razón del retraso y nueva salida. Las renovaciones repetidas deben escalarse como deuda estructural.
¿Cuándo debe detenerse una excepción antes de vencer?
Cuando el uso sale del alcance, falla un control, aparece un dato o acción no autorizados, aumenta el volumen, ocurre un incidente o cambia un supuesto material. La decisión debe incluir criterios de pausa, autoridad y fallback antes de activar.