Cómo crear un registro de riesgos para un AI Sales Copilot B2B

Qué es un registro de riesgos de IA y para qué sirve

El registro de riesgos es una memoria de decisiones, no una lista genérica de miedos sobre la inteligencia artificial. Reúne los escenarios que pueden afectar a personas, datos, compromisos comerciales u operación; muestra qué se decidió hacer; y conserva la evidencia necesaria para saber si el tratamiento sigue funcionando. Su utilidad aparece cuando una versión cambia, una señal se repite o alguien debe decidir si ampliar, limitar, pausar o retirar una función.

NIST organiza la gestión del riesgo de IA en actividades de gobierno, contexto, medición y manejo. Su Playbook recomienda documentar el propósito, los impactos, las responsabilidades, la tolerancia, la priorización, la respuesta y los riesgos residuales. Un registro es una forma operativa de mantener esas relaciones en un solo lugar. No reemplaza la evaluación, el monitoreo ni la respuesta a incidentes; los conecta.

Una hoja con etiquetas como privacidad, sesgo y alucinación no permite actuar. Cada fila debe describir una situación verificable dentro de un recorrido comercial. Por ejemplo: una nota externa contiene una instrucción maliciosa, el copiloto la trata como autoridad y prepara una acción con datos de otra cuenta. Así se pueden identificar el límite de confianza, el control preventivo, la señal de detección y la persona que decide el tratamiento.

Define el sistema, la versión y la decisión que están dentro del alcance

Empieza por el recorrido, no por el nombre del proveedor o del modelo. Describe para qué se usa el copiloto, quién lo opera, qué personas pueden verse afectadas y qué decisiones apoya. Separa preparar un borrador, recomendar un siguiente paso, consultar una fuente y ejecutar una acción. Dos funciones que comparten modelo pueden tener riesgos muy distintos por sus datos, herramientas y efectos.

Registra los componentes que determinan el comportamiento: modelo, instrucciones, recuperación, CRM, catálogo, archivos, memoria, permisos, herramientas, validaciones e interfaz. Añade la versión activa o una referencia de configuración. Si la organización no puede reconstruir qué sistema evaluó, tampoco podrá demostrar si un control continúa vigente después de un cambio.

Escribe los límites de uso y una alternativa manual. En ventas, una recomendación puede apoyar a la persona responsable, pero no debe convertirse por sí sola en aceptación del comprador, autorización de descuento o compromiso contractual. El proceso manual permite continuar cuando el riesgo supera la tolerancia o una dependencia deja de estar disponible.

Relaciona activos, actores, dependencias y efectos

Un riesgo siempre afecta algo que importa. Identifica precios, descuentos, contactos, documentos, credenciales, historial, propuestas, reputación, continuidad y decisiones comerciales. Después señala quién crea, consulta, modifica, aprueba y recibe cada elemento. Esta relación evita describir el daño de forma abstracta y ayuda a encontrar a la persona con autoridad para responder.

Incluye dependencias externas y componentes aparentemente auxiliares. Un índice de búsqueda, un conector, una plantilla, un proveedor de correo o un sistema de identidad puede cambiar lo que el copiloto ve y hace. Microsoft recomienda inventariar modelos, herramientas, complementos y fuentes de datos, aplicar control de cambios y diseñar controles compensatorios porque cualquier componente puede fallar.

No confundas activo con propietario. La persona dueña del catálogo mantiene su calidad; la dueña del riesgo decide si el escenario se acepta, se trata o se evita; y la dueña del control opera una medida concreta. En equipos pequeños una persona puede cumplir varios papeles, pero las responsabilidades deben seguir siendo visibles.

Escribe cada riesgo como causa, evento e impacto

La estructura causa–evento–impacto obliga a explicar cómo podría ocurrir el daño. Causa: una fuente no confiable se mezcla con instrucciones. Evento: el copiloto interpreta ese contenido como autoridad. Impacto: consulta o prepara una acción fuera del alcance. Esta formulación permite probar el recorrido y asignar controles en puntos concretos.

Evita escribir solo alucinación, fuga o sesgo. Esas palabras agrupan clases de problemas, pero no indican qué objeto, rol, canal o decisión está expuesto. Tampoco registres como riesgo una falla que ya ocurrió sin distinguirla: un hallazgo es evidencia de una debilidad; un incidente es un evento con impacto; un problema es trabajo pendiente; una excepción es una desviación autorizada y temporal.

Añade las condiciones necesarias y el alcance potencial. Identifica si el resultado solo sería visible, si podría guardarse, compartirse o ejecutarse, y si afectaría una oportunidad, una cuenta, un equipo o varias organizaciones. La misma salida incorrecta cambia de severidad según su efecto y la capacidad de contenerla.

Valora el riesgo inherente sin inventar precisión

El riesgo inherente describe el escenario antes de considerar los controles específicos. Evalúa el impacto y la posibilidad o exposición usando criterios definidos por la organización. NIST señala que la priorización puede considerar impacto, probabilidad, recursos y métodos disponibles, y que los riesgos más serios requieren más atención y recursos de supervisión.

Define escalas con ejemplos observables. Impacto crítico puede significar acceso entre organizaciones, divulgación sensible, acción irreversible o compromiso comercial no autorizado. Exposición alta puede indicar que el recorrido está disponible para muchos usuarios, se ejecuta con frecuencia y no necesita condiciones raras. Documenta los supuestos y la calidad de la evidencia.

Una multiplicación de números no crea conocimiento. Si la probabilidad es desconocida, decláralo y utiliza señales como superficie, frecuencia, accesibilidad y capacidad del atacante o del error. Mantén separado el impacto sobre personas, cumplimiento, operación, finanzas y reputación cuando una puntuación única ocultaría diferencias relevantes.

Asigna una persona responsable con autoridad real

La persona dueña del riesgo debe poder reunir evidencia, pedir un cambio, aceptar una exposición dentro de la tolerancia y escalar cuando no tiene autoridad. Un equipo, un comité o el área de tecnología pueden participar, pero no sustituyen un nombre y un respaldo. NIST pide documentar quién mantiene, revalida, monitorea y actualiza el sistema después del despliegue.

Distingue a quien posee el riesgo de quien opera el control. Seguridad puede mantener una regla de acceso; Datos puede corregir la fuente; Ventas puede aprobar condiciones comerciales; Producto puede limitar una herramienta. La persona dueña del riesgo verifica que el conjunto reduzca el escenario y presenta el riesgo residual a quien tiene autoridad para decidir.

Registra también quién puede aceptar, pausar y reanudar. La aceptación no debe quedar implícita porque el equipo decidió lanzar. Si el riesgo supera la tolerancia, la fecha comercial no reemplaza la autorización. Cuando nadie puede asumirlo legítimamente, la respuesta es reducir el alcance o no desplegar.

Vincula controles preventivos, detectivos, correctivos y de recuperación

Un buen registro muestra cómo se interrumpe el escenario. Los controles preventivos reducen la posibilidad: mínimo privilegio, validación determinista, separación entre datos e instrucciones y aprobación previa. Los detectivos descubren el desvío: alertas, evaluación, monitoreo y revisión. Los correctivos eliminan la causa. Los de recuperación limitan la interrupción y restauran un estado conocido.

Microsoft recomienda permitir solo las herramientas, datos y operaciones necesarios; exigir aprobación para acciones de alto riesgo; mantener mecanismos de pausa; y conservar registros accesibles de acciones, herramientas y resultados. Estas medidas deben existir en el sistema y el proceso. Una advertencia en el prompt no sustituye un permiso, una validación o una puerta de aprobación.

Para cada control registra tipo, responsable, alcance, estado, versión, frecuencia y dependencia. Evita duplicar el texto de una política. Enlaza la regla, la configuración o el procedimiento vigente. Si un control aplica solo a una ruta o rol, dilo; una cobertura parcial no debe presentarse como protección del sistema completo.

• Preventivo: evita o bloquea la ruta antes del efecto.
• Detectivo: identifica una condición o salida fuera de los límites.
• Correctivo: elimina la causa confirmada o reduce su repetición.
• Recuperación: contiene, revierte y mantiene continuidad operativa.
• Compensatorio: reduce temporalmente la exposición cuando falta el control principal.

Exige evidencia que otra persona pueda revisar

La evidencia debe responder qué se probó, con qué versión, bajo qué rol, cuál era el resultado esperado y qué ocurrió. Puede ser una prueba automatizada, un reporte de red teaming, una revisión de permisos, una muestra de producción protegida, un registro de aprobación o un simulacro de pausa. El estado aprobado sin referencia, fecha y resultado no permite revalidar.

Conserva la procedencia sin copiar datos sensibles en la tabla. Enlaza un repositorio restringido, registra el identificador y aplica minimización y retención. Una captura aislada puede ocultar el contexto; una métrica agregada puede esconder un caso grave. Combina resultados resumidos con evidencia reproducible para escenarios críticos.

Define caducidad. Una prueba anterior a un cambio de modelo, permiso, fuente o herramienta puede dejar de demostrar la eficacia actual. El control sigue existiendo, pero su evidencia necesita actualización. Esa diferencia evita declarar vencido el control cuando lo que venció fue la confirmación.

Evalúa el riesgo residual y decide cómo responder

El riesgo residual es lo que permanece después de aplicar los controles. NIST recomienda documentarlo, incluidos los riesgos aceptados, transferidos o con mitigación mínima, y comunicar limitaciones y requisitos de operación a las partes relevantes. No lo calcules restando una puntuación de forma automática: revisa qué parte del escenario sigue abierta, qué tan confiable es la evidencia y qué condiciones podrían degradar el control.

La respuesta puede ser mitigar, evitar, transferir o aceptar. Mitigar añade o mejora controles. Evitar elimina la función, el dato o el efecto. Transferir distribuye una consecuencia mediante contratos u otros mecanismos, pero no elimina la responsabilidad operativa. Aceptar requiere autoridad, justificación, vigencia, condiciones y monitoreo; no significa ignorar.

Si el residual supera la tolerancia, limita el alcance, vuelve al proceso manual, pausa o retira. Registra qué señal reabre la decisión. Un control compensatorio necesita vencimiento y una ruta hacia la solución estable. De otro modo, la excepción se convierte en arquitectura permanente sin revisión.

Conecta el registro con pruebas, monitoreo, feedback e incidentes

El registro recibe evidencia de varias rutas. La evaluación comprueba comportamiento esperado; el red teaming busca rutas adversarias; el monitoreo detecta cambios y señales emergentes; el feedback aporta observaciones del trabajo real; y los incidentes muestran dónde fallaron el escenario o sus controles. Cada vínculo debe actualizar la probabilidad, el impacto, el tratamiento o la confianza en la evidencia.

No conviertas cada alerta en un riesgo nuevo. Vincula señales repetidas a un escenario existente y abre otro solo cuando cambien la causa, el evento o el impacto. De la misma forma, varios riesgos pueden compartir un control. Mantener relaciones evita duplicar trabajo y muestra el alcance de una degradación común, como un proveedor de identidad o un catálogo vencido.

Los cambios necesitan una revisión de riesgos antes y después del despliegue. Un nuevo modelo, prompt, índice, permiso, herramienta o nivel de autonomía puede crear escenarios, modificar la exposición o invalidar evidencia. Etiqueta pruebas y métricas con la versión para que el registro no mezcle resultados de sistemas distintos.

Mantén una cadencia y revisa también por eventos

Define una revisión periódica según criticidad, pero no esperes al calendario cuando cambia el sistema o aparece una señal. Los disparadores incluyen un nuevo caso de uso, una fuente o integración, cambios de permisos, una versión del modelo, un hallazgo, un incidente, una excepción vencida, una degradación o una nueva obligación aplicable.

Cada revisión debe terminar en una decisión: mantener, investigar, mejorar el control, limitar, aceptar por un periodo, pausar, transferir o retirar. Registra la fecha, participantes, evidencia nueva, cambios de valoración y próxima condición. El historial se conserva; no sobrescribas una aceptación anterior como si nunca hubiera existido.

Archiva riesgos cuando el escenario desaparece, no cuando deja de ser cómodo. Conserva la razón, la versión final y las dependencias. Un riesgo puede reabrirse si vuelve la función, cambia el contexto o aparece nueva evidencia. Revisa también la calidad del registro: filas sin responsable, controles sin prueba, aceptaciones vencidas y riesgos idénticos son señales de deuda operativa.

Usa una ficha breve que obligue a tomar decisiones

La herramienta puede ser una base de datos, un módulo de gobernanza o una hoja controlada. Lo importante es que cada campo tenga una función y que las relaciones con pruebas, cambios e incidentes sean estables. Evita una tabla tan extensa que el equipo la complete una vez y la abandone.

Separa descripción, valoración y decisión. La descripción no cambia para justificar una puntuación. La valoración muestra supuestos y evidencia. La decisión identifica autoridad, tratamiento, fecha y condición de revisión. Mantén vocabulario y escalas comunes para comparar sin borrar el contexto del caso.

Aplica el registro a límites verificables de Cerravi

En Cerravi, las sugerencias permanecen sujetas a revisión humana. El producto organiza contexto y propone siguientes pasos; no convierte una señal en una decisión automática. Una apertura de Buyer Room aporta contexto, pero no confirma identidad, lectura, aceptación, contrato, pago ni intención de compra. Estos límites deben aparecer como condiciones del sistema y como controles comprobables.

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 mientras no exista una conversión aprobada con método, fecha y fuente.

Forecast es una estimación operativa basada en reglas transparentes y datos del CRM, no un modelo predictivo entrenado o calibrado. El registro debe distinguir el riesgo de datos incompletos, el de interpretación humana y el de automatización fuera del alcance. El objetivo no es afirmar que no existe riesgo, sino mantenerlo visible, asignado, probado y dentro de los límites que la organización decidió aceptar.