Respuesta directa
En pocas palabras
Para gestionar un hallazgo de AI Sales Copilot, documenta el criterio incumplido, la condición observada, la evidencia, el alcance, la causa y el riesgo; valida y prioriza sin alterar los hechos; contiene el impacto cuando sea necesario; asigna una acción correctiva con dueño, fecha, dependencias y criterio de éxito; implementa el cambio con control de versión y rollback; y cierra únicamente después de repetir el caso original, probar variantes y confirmar que el control opera durante el periodo acordado. Un ticket resuelto, un prompt modificado o una demostración exitosa no prueban por sí solos que la causa haya sido eliminada.
Distingue hallazgo, riesgo, incidente y excepción
Un hallazgo es una diferencia sustentada 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. No todo resultado inesperado es todavía un hallazgo: primero hay que confirmar la versión, el recorrido, la evidencia y el criterio aplicable.
Un riesgo describe lo que podría ocurrir y su posible consecuencia. Un incidente es un evento que produjo o pudo producir un impacto y requiere respuesta coordinada. Una excepción autoriza temporalmente apartarse de una regla bajo condiciones. Un defecto describe comportamiento técnico. Pueden estar relacionados, pero necesitan registros y decisiones diferentes. Un incidente puede revelar un hallazgo; un hallazgo puede actualizar un riesgo; una remediación tardía puede requerir una excepción. No los fusiones en un estado llamado pendiente.
El proceso busca decisiones comprobables, no culpables ni una tasa artificialmente baja de hallazgos. Una organización madura hace visible una desviación, limita su efecto, corrige la causa y aprende de ella. Ocultar, renombrar o cerrar prematuramente solo transfiere el riesgo a producción.
Redacta el hallazgo para que otra persona pueda reconstruirlo
Empieza con el criterio: política, requisito, control, condición de lanzamiento, contrato, estándar adoptado o comportamiento aprobado, con versión y fecha. Después describe la condición sin adornos: quién hizo qué, en qué ambiente, con qué identidad, datos, versión y resultado. Separa observación, inferencia y recomendación.
Relaciona la evidencia mínima suficiente: identificador de ejecución, configuración, fuente, log, salida redactada, prueba, hash o referencia restringida. No copies secretos, conversaciones o catálogos completos si un identificador permite examinarlos bajo acceso controlado. Registra procedencia, zona horaria y transformaciones.
Añade alcance conocido y desconocido, población potencial, frecuencia, primera y última observación, rutas relacionadas, causa confirmada o hipótesis, consecuencia y riesgo. Si todavía no conoces la causa, dilo. Una explicación temprana presentada como hecho puede dirigir la corrección al componente equivocado.
Valida antes de priorizar y conserva el resultado original
Confirma que la evidencia corresponde al sistema y periodo indicados. Reproduce con datos controlados cuando sea seguro, revisa permisos, fuente, modelo, instrucciones, reglas, herramientas y estado final. Compara con un caso legítimo. Si no es reproducible, no lo descartes automáticamente: puede depender de concurrencia, una fuente retirada, una cohorte o una condición que ya cambió.
Busca duplicados y relaciones sin borrar historias. Varios síntomas pueden compartir una causa; un mismo síntoma puede provenir de causas distintas. Elige un registro principal y enlaza pruebas, incidentes, riesgos, controles y cambios. Conserva quién reportó y qué observó antes de que una normalización reescriba el relato.
Clasifica el estado con vocabulario explícito: nuevo, en validación, confirmado, duplicado, no reproducido, fuera de criterio, aceptado temporalmente, en remediación, listo para retest, cerrado o reabierto. Fuera de criterio no significa sin importancia; puede requerir actualizar el requisito o abrir otro proceso.
Prioriza por impacto y exposición, no por presión del calendario
Evalúa qué activo, persona, organización o compromiso comercial podría verse afectado; si el efecto es reversible; cuántos recorridos y usuarios están expuestos; qué permisos o condiciones necesita; y si puede propagarse. Una sola lectura entre organizaciones puede justificar prioridad crítica aunque la tasa agregada sea pequeña.
Distingue severidad de urgencia. La severidad representa impacto y exposición. La urgencia incorpora uso actual, lanzamiento, explotación, falta de control compensatorio y tiempo hasta un efecto. Un hallazgo importante no se vuelve menor porque la fecha esté cerca, ni uno menor se vuelve crítico porque sea visible para dirección.
NIST AI RMF Manage propone priorizar respuestas según impacto, probabilidad, recursos y tolerancia, y documentar los planes y equipos responsables. Es una guía voluntaria: cada empresa define su matriz, autoridades y obligaciones. Cuando falte evidencia sobre posibilidad, registra incertidumbre y una investigación con fecha en lugar de inventar una precisión numérica.
Separa contención inmediata de remediación permanente
La contención reduce exposición mientras se investiga: pausar una herramienta, limitar una fuente, retirar un enlace, revocar una credencial, exigir una aprobación adicional, volver al proceso manual o restringir una cohorte. Define quién puede activarla, qué alcance tiene, cómo se comunica y qué evidencia demuestra que quedó aplicada.
Contener no elimina la causa. Un filtro temporal puede evitar una frase y dejar abierta la clase de falla; apagar una integración puede proteger datos y detener un proceso esencial. Registra el impacto operativo, el fallback, la vigencia y la condición para escalar, sustituir o retirar la medida.
Si existe impacto activo, datos expuestos, acción no autorizada o indisponibilidad material, activa el proceso de incidentes en paralelo. El registro de hallazgo no sustituye preservación de evidencia, comunicación, obligaciones de notificación o autoridad de recuperación.
Investiga la causa del recorrido, no solo la respuesta del modelo
Traza desde la entrada hasta el efecto: 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 respuesta errónea puede originarse en datos vencidos, autorización posterior a la recuperación, esquema permisivo, conflicto de versión, interfaz ambigua o revisión sin contexto.
Distingue causa inmediata, causa contribuyente y falla de control. Cambiar un prompt puede modificar una salida y no corregir permisos, procedencia o acciones. La frase causa raíz no garantiza que exista una sola causa. Conserva hipótesis descartadas, pruebas y límites para que el análisis no dependa de memoria individual.
Amplía el alcance cuando la causa sea compartida. Si un validador defectuoso afecta PDF, DOCX, Buyer Room y API, corregir únicamente la pantalla no cubre la población. Relaciona componentes y versiones potencialmente afectadas y decide si necesitan búsqueda retrospectiva.
Convierte la causa en una acción correctiva verificable
Define el resultado esperado en términos observables. Asigna una persona dueña con autoridad, una fecha razonada, dependencias, recursos, criterio de aceptación y evidencia de cierre. Separa tareas auxiliares —investigar, diseñar, desarrollar, documentar, capacitar— del resultado que debe reducir el riesgo.
Considera alternativas: eliminar la ruta, limitar alcance o autonomía, corregir datos o permisos, fortalecer validación, introducir un control compensatorio, volver a un proceso manual, sustituir el componente, transferir una obligación o aceptar residual con autoridad y vencimiento. NIST contempla mitigar, transferir, evitar o aceptar; la elección necesita contexto y documentación, no una etiqueta automática.
Una fecha incumplida no debe resolverse moviendo silenciosamente el plazo. Registra motivo, exposición durante la demora, contención vigente, nueva decisión y autoridad. Escala cuando el residual supera tolerancia, la medida temporal caduca o el dueño carece de recursos.
Implementa con versión, aprobación, rollback y observabilidad
Trata la remediació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. Una corrección urgente todavía necesita una identidad verificable y una ruta de reversión.
Prueba en un entorno proporcional, protege datos y evita efectos reales innecesarios. Define canario, cohorte o despliegue gradual cuando permita detectar regresiones. Establece señales de éxito, error y parada antes de publicar. Si el cambio toca una herramienta o acción externa, valida argumentos, autorización, idempotencia y estado parcial.
Actualiza controles, runbooks, inventario, modelo de amenazas, registro de riesgos, evaluación, documentación y formación cuando corresponda. Corregir el código sin corregir la forma de operar deja una causa organizacional abierta.
Repite el caso original y busca variantes y regresiones
El retest empieza con el procedimiento y los datos que confirmaron el hallazgo, sobre la versión corregida. 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 casos legítimos. Una solución que bloquea también el trabajo autorizado puede cambiar un riesgo por otro. Comprueba desempeño funcional, permisos, trazabilidad, fallback y experiencia del revisor. 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 800-53A ofrece procedimientos adaptables para examinar, entrevistar y probar controles. No es una receta específica para un copiloto comercial, pero ayuda a documentar objetivo, método, objeto y resultado. Ajusta profundidad, muestra e independencia al impacto y declara los límites de la conclusión.
Comprueba operación sostenida antes de declarar eficacia
Una demostración 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 de configuración y confirma que una persona 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 pruebas deterministas y monitoreo continuo. Explica qué cubrió la observación y qué quedó fuera.
Mide tiempo de validación, contención, corrección, retest, reincidencia y hallazgos vencidos, pero evita premiar solo cierres rápidos o pocos reportes. Esos incentivos favorecen dividir, degradar o esconder problemas. Complementa velocidad con calidad de causa, recurrencia, cobertura y residual.
Cierra con evidencia, autoridad y condición de reapertura
El paquete de cierre reúne criterio y condición originales, alcance, causa, contención, cambio, versión, retest, operación, regresiones, residual y limitaciones. Una persona con autoridad distinta del ejecutor revisa cuando el impacto o la independencia lo exigen. El dueño del ticket no debe autoaprobar una conclusión material sin el control previsto.
Elige una disposición clara: remediado, parcialmente remediado, riesgo aceptado, transferido, evitado, sustituido o no válido con justificación. Si queda residual, registra responsable, autoridad, condiciones, compensación, vigencia y siguiente revisión. El cierre administrativo no elimina el registro histórico.
Define disparadores de reapertura: recurrencia, falla de regresión, cambio de versión o dependencia, control compensatorio vencido, nueva evidencia, ampliación del alcance o incidente relacionado. Un hallazgo cerrado puede seguir aportando una prueba esencial y una lección para otros sistemas.
Opera un tablero que muestre riesgo y flujo sin distorsionarlos
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 significan mejora si entraron veinte hallazgos materiales o si el backlog crítico envejece.
Vigila tiempo hasta contención y hasta cierre, reincidencia, extensiones, aceptaciones vencidas, controles sin prueba y porcentaje de cierres rechazados en revisión. Interpreta cada métrica con volumen de uso, cobertura de pruebas y cambios. Una caída de hallazgos puede significar mejor control o menor capacidad de detección.
Revisa tendencias de causa y concentración. Varias desviaciones pequeñas en autorización, datos o cambios pueden revelar una debilidad sistémica. Convierte la revisión en decisiones con dueño y fecha; no la uses para editar severidades hasta que el tablero parezca verde.
Aplica el proceso a los límites verificables de Cerravi
En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. Un hallazgo debe indicar si la desviación ocurrió en la sugerencia, la interfaz, el permiso, una exportación o una automatización añadida por la empresa. No atribuyas a Cerravi acciones que pertenecen a otra integración.
Las propuestas utilizan productos y precios disponibles en el catálogo. Si falta un importe, debe pedirse 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, usando datos de prueba cuando baste.
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 basada en reglas transparentes del CRM, no un modelo predictivo entrenado o calibrado ni una garantía de cierre. Este proceso ayuda a producir evidencia; no certifica Cerravi, a la empresa ni el cumplimiento de una obligación.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué diferencia existe entre un hallazgo y un incidente?
Un hallazgo demuestra una diferencia entre criterio y condición. Un incidente gestiona un evento con impacto real o potencial y puede exigir contención, comunicación y recuperación inmediata. Un incidente puede originar uno o varios hallazgos, pero cerrar la respuesta no demuestra que sus causas hayan sido remediadas.
¿Cambiar el prompt puede cerrar un hallazgo?
Solo si la evidencia demuestra que la causa estaba allí y el cambio cubre el alcance. Debe repetirse el caso original, probar variantes y casos legítimos y observar operación. Un cambio de frase no corrige permisos, fuentes, validaciones o herramientas si esos componentes permitían la falla.
¿Quién debe aprobar el cierre?
La autoridad depende del impacto, el criterio y la independencia requerida. El dueño ejecuta la corrección; el propietario del riesgo o control y una función independiente pueden revisar. La persona que implementó no debería aprobar sola un cierre material cuando el proceso exige segregación.
¿Cuándo se puede aceptar un riesgo residual?
Cuando una autoridad definida entiende el alcance, la evidencia, las alternativas y lo que permanece abierto, y documenta motivo, condiciones, control compensatorio, monitoreo, vigencia y revisión. Si supera tolerancia o una obligación aplicable, limitar, pausar o retirar puede ser necesario.
¿Un ticket cerrado demuestra remediación?
No. Demuestra un estado administrativo. La remediación necesita evidencia del cambio, retest del caso original, variantes, ausencia de regresiones materiales, operación durante el periodo acordado y una decisión autorizada sobre cualquier riesgo residual.