Auditoría de asistentes de IA: evidencia que sí sirve

Un asistente de IA responde algo incorrecto a un cliente. El equipo encuentra la conversación, corrige el texto y cambia una instrucción. ¿Ya quedó resuelto?

Todavía no. Falta saber qué documento consultó, qué permisos tenía, qué versión estaba activa, quién revisó la respuesta y si el mismo error pudo afectar otros casos. La conversación conserva el resultado visible, pero no necesariamente la historia que explica cómo se produjo.

Una auditoría de asistentes de IA sirve para reconstruir esa historia. No es revisar chats al azar ni pedir un reporte con muchas filas. Es seguir casos concretos hasta encontrar la relación entre entrada, fuente, configuración, intervención humana y efecto operativo.

La evidencia empieza con un caso, no con un tablero

Un tablero puede mostrar cantidad de conversaciones, tiempo de respuesta o porcentaje de escalamiento. Es útil para observar tendencias, pero no explica una respuesta específica. Para auditar, conviene comenzar con un caso que tenga una consecuencia clara: una cotización enviada, un ticket mal clasificado, una política comunicada con una versión anterior o una solicitud que nunca llegó al área responsable.

El caso debe conservar un identificador y su estado antes de la intervención del asistente. También debe quedar claro qué ocurrió después. Si una respuesta solo fue una sugerencia interna, la revisión será distinta de la que corresponde a un mensaje enviado al cliente o a una actualización de un registro.

Esta diferencia evita acumular registros que nadie puede interpretar. Una empresa no necesita guardar todo con el mismo nivel de detalle; necesita conservar suficiente evidencia para los usos que pueden afectar dinero, derechos, servicio, reputación o continuidad.

Guardar la conversación no basta

La conversación es una pieza de la auditoría, no el expediente completo. La entrada original pudo incluir un formulario, un archivo adjunto, datos recuperados del CRM, una conversación previa o un campo agregado por una integración. Si solo se conserva el mensaje final que llegó al modelo, se pierden posibles causas del error.

Para cada caso conviene identificar:

• qué pidió la persona y por qué canal;
• qué datos fueron recuperados automáticamente;
• qué documentos o registros se consultaron;
• qué versión tenía cada fuente en ese momento;
• qué respuesta preparó el asistente y qué cambió el revisor;
• qué acción ocurrió después y quién tenía autoridad para ejecutarla.

La lista no debe convertirse en un formulario burocrático. Su propósito es separar hechos observables de supuestos del modelo. Una dirección tomada del CRM no tiene el mismo origen que una frase inferida por el asistente. Mezclarlas en un único bloque hace más difícil corregir el proceso.

La fuente debe ser identificable y vigente

Un asistente puede citar una política correcta usando una copia que ya no aplica. También puede mencionar el nombre de un documento sin mostrar la edición, la fecha efectiva o el fragmento que respaldó la respuesta. Cuando aparece una reclamación, esa diferencia deja de ser un detalle técnico.

La auditoría debería poder responder qué fuente consultó el asistente, cuál era su versión y qué parte utilizó. Si dos documentos se contradicen, el sistema debe mostrar el conflicto o detenerse según la regla definida por la empresa. No debería escoger la frase más completa y ocultar la discrepancia.

Esto requiere responsables. Cada dominio de conocimiento necesita alguien que apruebe cambios, retire documentos reemplazados y defina qué fuente tiene autoridad. Una carpeta con muchos archivos no equivale a una base confiable.

El AI RMF Playbook de NIST propone acciones voluntarias para gobernar, mapear, medir y gestionar riesgos de sistemas de IA. Para una auditoría de asistentes, ese marco ayuda a revisar el uso previsto, los riesgos, la medición y la respuesta durante todo el ciclo de vida, no solo la frase que generó el modelo.

Permisos: quién podía preguntar no es quién puede ver todo

Un asistente puede contestar correctamente y aun así mostrar información a la persona equivocada. Por eso la auditoría debe registrar la identidad o el rol con el que se hizo la consulta, las fuentes habilitadas y las acciones permitidas en ese momento.

La prueba más útil no es una pregunta cómoda. Es una pregunta que cruce áreas. Por ejemplo, un usuario de ventas intenta consultar un documento interno de recursos humanos; una persona externa pregunta por el estado de un caso de otro cliente; un asistente recibe una solicitud que mezcla datos públicos con información restringida.

La respuesta correcta puede ser negar el acceso, pedir una verificación adicional o entregar solo una parte autorizada. Si el sistema responde sin dejar evidencia de la regla aplicada, después será difícil distinguir un permiso bien diseñado de una coincidencia.

Los controles de seguridad y gobernanza de IA deben establecer esa frontera antes del incidente. También deben definir quién puede retirar un permiso, revisar una excepción y detener el asistente sin apagar otros servicios que siguen operando correctamente.

La revisión humana tiene que dejar rastro útil

Decir que una persona "validó" la respuesta no explica mucho. Tal vez solo vio el texto final. Quizá no tuvo acceso a la fuente o aprobó varios casos de una vez. Una auditoría útil conserva la propuesta del asistente, la versión enviada y la evidencia que estaba disponible para la persona que decidió.

La diferencia entre ambas versiones suele revelar más que una calificación general. Si el revisor corrige siempre el mismo dato, puede faltar una fuente. Si elimina una promesa comercial, el asistente quizá tiene demasiado alcance. Si cambia la clasificación de una solicitud, la regla de entrada necesita revisión.

La persona tampoco debería revisar todo con la misma profundidad. Los casos de bajo riesgo pueden seguir reglas simples. Los que afectan pagos, contratos, datos sensibles o compromisos con clientes necesitan contexto y autoridad suficientes. La revisión humana funciona cuando ayuda a decidir, no cuando se convierte en un clic decorativo.

Una automatización de procesos puede conservar esa cadena sin pedirle al equipo que documente cada paso manualmente. El flujo puede asociar la consulta con el caso, guardar la fuente consultada, registrar la revisión y dejar la acción final vinculada a quien la autorizó.

La auditoría debe encontrar el punto que se puede corregir

Al terminar, el informe no debería quedarse en "la respuesta fue incorrecta". Debe señalar dónde se rompió el recorrido. Puede haber sido una fuente vencida, una identidad mal conciliada, un permiso demasiado amplio, una instrucción ambigua, un cambio no probado o una acción que nunca debió estar disponible para el asistente.

Cada causa pide una corrección distinta. Cambiar el prompt no arregla un documento sin dueño. Cambiar de modelo no corrige un acceso heredado. Añadir otra aprobación tampoco ayuda si el revisor no puede ver el respaldo de la respuesta.

La corrección debe comprobarse con el mismo caso y con variantes incómodas: información faltante, documentos contradictorios, usuario sin permiso, fuente retirada y solicitud que exige intervención humana. El resultado esperado no siempre es una respuesta mejor. A veces es una pausa clara, una negativa explicada o un escalamiento con el contexto correcto.

Qué debería quedar al cerrar una auditoría

Una auditoría de asistentes de IA está cerrada cuando deja una explicación que otra persona puede revisar. Como mínimo, debería identificar el caso, la entrada, las fuentes y versiones, la configuración relevante, los permisos, la intervención humana, el efecto producido y la corrección aplicada.

También conviene documentar lo que no se pudo comprobar. Una trazabilidad honesta reconoce una brecha en lugar de rellenarla con una suposición. Esa brecha puede convertirse en una tarea concreta: conectar el registro del asistente con el CRM, controlar versiones de documentos, separar permisos por área o definir quién tiene autoridad para pausar el flujo.

Global Agenttic puede ayudar a revisar asistentes, agentes y automatizaciones desde inteligencia artificial aplicada, con atención a fuentes, permisos, pruebas y operación. El objetivo no es producir más registros. Es que la empresa pueda explicar una decisión y corregir el proceso sin depender de una reconstrucción manual cada vez que algo sale mal.