Gobernanza de IA

Cómo preparar evidencia para una auditoría de un AI Sales Copilot B2B

Un método para responder qué se revisa, qué criterio aplica, qué evidencia lo demuestra y quién puede reconstruir la decisión sin exponer datos innecesarios.

Respuesta directa

En pocas palabras

Para preparar evidencia de auditoría de un AI Sales Copilot, define primero objetivo, criterio, alcance, versión y periodo; después construye una matriz que conecte cada requisito con el artefacto, sistema fuente, responsable, fecha y método de verificación. El paquete debe cubrir inventario y arquitectura, autoridad y decisiones, procedencia y acceso a datos, evaluaciones, controles, cambios, excepciones, incidentes y registros de operación. La evidencia debe ser íntegra, recuperable, mínima y protegida. Un paquete completo facilita el examen, pero no constituye por sí solo certificación ni prueba de cumplimiento.

La auditoría examina afirmaciones contra criterios definidos

Preparar evidencia no consiste en llenar una carpeta con capturas. Una auditoría necesita relacionar una afirmación con un criterio, un alcance, un periodo y hechos que otra persona pueda examinar. Si la empresa afirma que el copiloto solo utiliza fuentes autorizadas, debe 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 que la autoridad decida si continúa o cambia el sistema. La auditoría evalúa, con el grado de independencia definido, si procesos y resultados se ajustan a criterios establecidos. Pueden compartir artefactos, pero no deben compartir conclusiones por defecto.

NIST AI RMF recomienda documentación estandarizada y vigente sobre propósito, alcance, riesgos, limitaciones, pruebas, dependencias, despliegue y monitoreo. El marco es voluntario y no convierte esta guía en estándar de auditoría. El mandato, la independencia, la competencia y los criterios aplicables pertenecen a cada organización y contexto.

Acordar mandato, criterio y frontera evita pedir evidencia infinita

Registra quién solicita el trabajo, quién lo realiza, para quién se prepara el resultado y qué grado de independencia necesita. Define objetivo: diseño de controles, 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 que construyó el sistema.

Enumera criterios concretos: política interna, requisito contractual, obligación aplicable, control de seguridad, estándar adoptado o condición de una aprobación. Conserva versión y fecha. Una frase como revisar IA responsable no permite distinguir evidencia suficiente de material interesante.

Fija organizaciones, procesos, productos, casos, versiones, ambientes, regiones, datos, integraciones y fechas incluidos. Declara exclusiones y restricciones. Si el auditor no puede acceder a una evidencia por privacidad, secreto o segregación, documenta un mecanismo alternativo; no la marques como examinada.

Construye una matriz de criterios y evidencia antes de recolectar

Crea una fila por criterio o control. Añade identificador, afirmación verificable, riesgo relacionado, artefacto esperado, sistema fuente, propietario, custodio, periodo, frecuencia, población, método de prueba y estado. Diferencia disponible, solicitado, recibido, validado, insuficiente, no aplicable y restringido.

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 puede aportar evidencia de operación; una prueba independiente puede evaluar eficacia. Ninguna sustituye automáticamente a las demás.

Evita duplicar el mismo documento con nombres distintos. Usa referencias estables y conserva el origen. Si un dashboard se actualiza continuamente, registra consulta, filtros, zona horaria, periodo y fecha de extracción para que el resultado pueda reconstruirse.

Congela la identidad del sistema y su configuración examinada

Entrega la ficha de inventario con propósito, caso de uso, 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 de la interfaz no describe el sistema completo.

Relaciona versión de aplicación, modelo, prompt o instrucciones, reglas, fuentes, índices, herramientas, integraciones, permisos, flags y ambientes. No incluyas secretos. Utiliza identificadores, exportaciones protegidas, manifiestos, commits o configuraciones redactadas que permitan demostrar qué operó.

Conserva fechas de activación y retiro y el mapa entre versiones y periodos. Si hubo despliegue gradual, identifica cohortes. Un resultado producido por una versión no debe utilizarse como evidencia de otra sin demostrar equivalencia.

Demuestra autoridad, decisiones y rendición de cuentas

Incluye política de uso, clasificación de riesgo, evaluación de impacto, registro de riesgos y matriz RACI vigentes durante el periodo. Vincula responsables y aprobadores con el alcance de su autoridad, suplencia y segregación. Una lista de nombres sin derechos de decisión no demuestra accountability.

Entrega gates y resoluciones de diseño, lanzamiento, cambios, excepciones, incidentes, reanudación y retiro. Cada decisión debe mostrar versión, evidencia considerada, condiciones, incertidumbre, riesgo residual, fecha y autoridad. Conserva disensos y pendientes materiales.

Comprueba capacitación y comunicación solo cuando el criterio lo requiera. La asistencia a un curso no demuestra que un control técnico operó. Conecta cada artefacto de gobierno con el resultado que debía producir.

Traza datos, fuentes, permisos y retención sin copiar el universo

Documenta categorías de datos, procedencia, propósito, base de autorización aplicable, calidad, vigencia, transformaciones, destinos, regiones, retención y eliminación. Distingue datos de configuración, grounding, entrada, salida, feedback, evaluación, telemetría y soporte.

Muestra cómo la identidad del usuario y del servicio limita recuperación y herramientas. Prueba casos permitidos y denegados con cuentas controladas. Incluye revisiones de acceso, altas, cambios, bajas y excepciones. Un diagrama de permisos no demuestra que la aplicación los aplique antes de recuperar información.

Minimiza el paquete. Entrega inventarios, metadatos, muestras redactadas o acceso controlado cuando basten. No copies conversaciones, catálogos, contactos o documentos completos si el criterio puede verificarse con una referencia y una muestra proporcional.

Conserva evaluaciones reproducibles y límites explícitos

Relaciona cada evaluación 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 riesgo y criterio. Red teaming autorizado documenta permiso, entorno, técnica, condición de parada, hallazgo, causa, corrección y retest. Una prueba de laboratorio no demuestra operación continua.

Vincula fallas confirmadas con regresiones y versiones corregidas. Si cambió el criterio o el conjunto, conserva la línea base y explica por qué la comparación sigue siendo válida o deja de serlo.

Mapa visual de evidencia de auditoría con criterio, versión, fuente, control, prueba y decisión de un AI Sales Copilot
Interfaz de Cerravi · Demo con datos ilustrativosCada artefacto debe responder una pregunta de auditoría y conservar alcance, versión, fuente, periodo, responsable e integridad.

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. Clasifica la evidencia: política o diseño; configuración o implementación; eventos o ejecución; prueba o eficacia. Evita concluir que un control funciona porque aparece en un procedimiento.

Selecciona población y muestra de manera trazable. Registra universo, periodo, criterios de selección, elementos examinados y excepciones. Una muestra dirigida puede buscar casos de mayor riesgo; una muestra representativa responde otra pregunta. No presentes una como si fuera la otra.

Conserva los resultados negativos. La ausencia de errores en una muestra no prueba ausencia en toda la población. Documenta desviaciones, compensaciones, riesgo residual y el límite de la conclusión.

Diseña logs y trazas para reconstruir sin registrar de más

Una traza útil puede relacionar identidad, timestamp, zona horaria, ejecución, versión, entrada o referencia, fuentes recuperadas, herramienta, argumentos, permiso, salida, aprobación y estado final. Microsoft recomienda ampliar observabilidad con procedencia de recuperación e invocaciones de herramientas, pero también gobernar captura y retención mediante contratos de datos.

No todos los campos deben contener texto completo. Usa identificadores, hashes, categorías y referencias cuando permitan reconstruir. Redacta datos personales y secretos, cifra, limita acceso y registra consultas al propio repositorio de auditoría. Define qué no se registra y por qué.

Verifica cobertura antes del periodo examinado. Microsoft Purview documenta propiedades como usuario, momento, aplicación y recursos accedidos para productos compatibles, pero esa cobertura no debe extrapolarse a Cerravi u otra plataforma. Cada empresa debe comprobar qué genera realmente su arquitectura, licencia y configuración.

Protege integridad, cadena de custodia y recuperabilidad

Conserva origen, creador, fecha, versión y transformaciones. Para exportaciones materiales utiliza hash, firma, almacenamiento inmutable o controles equivalentes según riesgo. Si un archivo fue redactado, registra la transformación y conserva el original bajo acceso separado cuando exista una razón autorizada.

Define custodia: quién extrae, transfiere, recibe, consulta y elimina. Usa un canal aprobado y un índice de entregas. Evita adjuntos dispersos en correo o mensajería donde se pierde la versión y se amplía acceso.

Prueba recuperabilidad antes de la auditoría. Un backup que nadie puede localizar, abrir o relacionar con la versión no es evidencia lista. Alinea conservación con obligación, necesidad forense, privacidad y eliminación; retener todo indefinidamente aumenta riesgo y no mejora automáticamente la prueba.

Opera una lista PBC y una sala de evidencia con cambios controlados

Convierte cada solicitud de información en identificador, criterio, descripción, formato, periodo, responsable, fecha, estado y preguntas. Aclara prepared by client, auditor, revisor o tercero según el proceso. Controla duplicados y cambios de alcance.

La sala de evidencia necesita índice, permisos por función, caducidad, registro de acceso, versión y canal para aclaraciones. Los nombres de archivo deben ser estables y legibles. No concedas al equipo auditor acceso administrativo de producción si una consulta o exportación de solo lectura es suficiente.

Realiza una prueba de recorrido: toma una afirmación importante y reconstruye criterio, decisión, configuración, operación y cierre. Si hacen falta mensajes privados o memoria de una persona, existe un vacío documental que debe registrarse, no improvisarse.

Convierte observaciones en hallazgos y cierres verificables

Un hallazgo distingue criterio, condición observada, evidencia, causa, efecto o riesgo y alcance. Separa hecho de recomendación. Permite respuesta del dueño sin borrar el registro original. Clasifica severidad conforme al método acordado, no según incomodidad política.

Cada acción correctiva define resultado, dueño, fecha, dependencia, validación y evidencia de cierre. Una promesa o un ticket cerrado no prueba remediación. Repite la prueba o aplica un procedimiento de seguimiento proporcional.

Conserva asuntos no resueltos, aceptación de riesgo y restricciones. El informe debe explicar limitaciones, muestreo, periodo y dependencia de información proporcionada. No generalices la conclusión a versiones, procesos o regiones fuera del alcance.

Prepara evidencia sobre los límites que Cerravi declara

En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente. La evidencia puede incluir matriz de permisos, pruebas de recorridos, versión desplegada y límites visibles. Una automatización añadida por una empresa pertenece a su propio alcance de auditoría.

Las propuestas utilizan productos y precios presentes en el catálogo cargado. Si falta un importe, se confirma; no se inventa. MXN, USD y otras monedas permanecen separadas salvo conversión aprobada. Para examinar esta afirmación, utiliza catálogos y casos de prueba 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. La evidencia debe distinguir observación, cálculo, inferencia y decisión humana; no convertir una captura favorable en garantía comercial.

Preguntas frecuentes

Dudas comunes sobre este proceso

¿Qué es evidencia suficiente para auditar un AI Sales Copilot?

Depende del criterio, riesgo, periodo y método. Normalmente combina diseño, configuración, registros de operación y prueba. Una política sola rara vez demuestra ejecución; un log aislado tampoco demuestra que el control cubra la población.

¿Es necesario guardar prompts y respuestas completos?

No siempre. Debe equilibrarse reconstrucción con privacidad, minimización, residencia, seguridad y retención. Identificadores, referencias, hashes, categorías o muestras redactadas pueden ser suficientes. El contrato de datos debe definir qué se captura y por qué.

¿Una revisión interna puede llamarse auditoría independiente?

Solo si cumple el grado de independencia, competencia y mandato definido para ese trabajo. Una autoevaluación del equipo puede ser útil, pero no debe describirse como opinión independiente si quienes construyeron u operan el sistema controlan la conclusión.

¿Cómo se demuestra que una versión estuvo activa?

Relacionando manifiestos, commits, configuraciones, despliegues, fechas, cohortes y telemetría mediante identificadores estables. Una captura sin fecha o un nombre informal de versión no basta para reconstruir el periodo examinado.

¿Preparar este paquete demuestra cumplimiento legal?

No. Organiza evidencia para examinar criterios definidos. La conclusión depende de requisitos aplicables, alcance, independencia, muestreo y juicio competente. La empresa debe obtener asesoría y evaluación profesional cuando corresponda.