Auditoría de IA en empresas: qué revisar antes de seguir usando un sistema

¿Cuándo necesitas una auditoría de IA en empresas?

Una auditoría de IA es una revisión estructurada del sistema y de la forma en que la empresa lo opera. Conviene hacerla cuando la IA toca decisiones, datos sensibles o procesos que afectan a clientes, empleados o proveedores.

• Tienes un asistente que responde sobre políticas, contratos, cartera, PQRS, cotizaciones, certificados o facturas, y nadie mide si acierta.
• El sistema usa documentos internos o búsqueda semántica, pero no sabes si recupera el contexto correcto. En ese caso, la revisión se parece a auditar un sistema RAG en producción.
• Hay agentes que consultan bases de datos, crean tickets, envían correos o llaman APIs. La auditoría debe revisar permisos, límites y mecanismos de parada.
• Un proveedor entregó un chatbot o una automatización con IA, pero el equipo dejó de confiar. Si responde mal o inventa información, puede requerir rescate de proyectos de IA.
• Usas herramientas externas con datos personales, información comercial o documentos confidenciales. Necesitas saber qué se envía, qué se guarda y bajo qué condiciones.
• Vendes o prestas servicios a la Unión Europea, o tu sistema puede quedar cubierto por transparencia, alto riesgo o modelos de propósito general.
• Hay uso no autorizado de IA: personas copiando información en herramientas públicas o flujos creados por áreas sin revisión técnica.

¿Qué revisa una auditoría de IA en un sistema real?

La auditoría debe empezar con inventario. Si no sabes dónde se usa IA, no puedes evaluar riesgos, datos ni resultados.

Una revisión de código puede ser parte de la auditoría, pero no la reemplaza. Un sistema puede tener buen código y aun así responder mal o ejecutar acciones sin control suficiente.

¿Cómo medimos si el sistema responde bien?

Medir un sistema de IA exige casos de prueba, métricas y comparación antes/después. Una demo con pocas preguntas escogidas no dice mucho.

1. Definir el objetivo del sistema. Primero se escribe qué debe hacer y qué no debe hacer. Para preguntas sobre documentos, OpenAI recomienda definir objetivo, recolectar datos, definir métricas, correr evaluaciones y evaluar de forma continua en sus buenas prácticas de evaluación.
2. Construir un conjunto de evaluación. El conjunto debe tener preguntas reales, casos difíciles y casos donde el sistema debe decir “no sé” o escalar. Puede salir de tickets, PQRS, correos de cartera, cotizaciones, facturas rechazadas o búsquedas internas.
3. Medir recuperación y respuesta. En un sistema con RAG se mide si trae el documento correcto y si la respuesta se basa en ese documento. Hemos operado durante 3 años un asistente RAG en una plataforma de lealtad con más de 2 millones de usuarios en 10 países y más de 99% de disponibilidad. También explicamos este enfoque en la guía sobre cómo medir si un asistente de IA responde bien.
4. Revisar riesgos técnicos y de seguridad. La medición no termina en exactitud. NIST incluye precisión, explicabilidad, privacidad, fiabilidad, seguridad, protección y mitigación de sesgos dañinos en su trabajo de medición y evaluación de IA. OWASP incluye inyección de instrucciones, divulgación de información sensible y envenenamiento de datos o del modelo en el OWASP Top 10 for LLMs and Gen AI Apps 2025.
5. Comparar y decidir. La auditoría debe cerrar con una decisión clara: seguir, corregir y volver a medir, limitar el alcance o apagar. En sistemas generativos, NIST recomienda monitorear contenido generado y reevaluar modelos cuando cambian de dominio, dentro de su perfil de IA generativa.

¿Qué regulación y marco puedes usar?

Esta sección no es opinión jurídica. Sirve para ubicar temas que debes revisar con legal, datos, seguridad y tecnología.

En Colombia, el CONPES 4144 de 2025 formuló la Política Nacional de Inteligencia Artificial y plantea capacidades para investigación, desarrollo, adopción y uso ético de IA, según el documento CONPES aprobado el 14 de febrero de 2025.

¿Qué entregables debes pedir en una auditoría de IA?

Pide entregables que permitan actuar. Si el informe no dice qué corregir, quién debe hacerlo y cómo se comprobará la mejora, queda incompleto.

Un buen entregable incluye inventario de sistemas, mapa de datos, revisión de proveedores, matriz de riesgos, resultados de evaluación, hallazgos de seguridad y plan de corrección. Para sistemas en producción, también debe incluir casos de prueba, métricas antes/después y registros que sostienen los hallazgos.

También conviene pedir una decisión por caso de uso: continuar, corregir, limitar o apagar. Esa decisión depende del riesgo, del valor del proceso, de la calidad medida y de si existe una solución sin IA.

Ejemplo ilustrativo, no cliente: una empresa colombiana recibe PQRS por correo y usa un asistente para proponer respuestas. La entrada son correos con adjuntos, historial del cliente y políticas internas. El sistema clasifica la PQRS, busca la política aplicable, propone una respuesta y deja el caso para aprobación humana. La auditoría revisa si la clasificación coincide con el criterio del área, si el documento recuperado es correcto, si la respuesta cita información vigente y si el agente nunca envía sin aprobación. El resultado puede ser seguir con aprobación humana, corregir la base documental y bloquear categorías donde el sistema falla.

Sobre costo y plazo, no hay una respuesta seria sin mirar alcance. Dependen de cuántos sistemas existen, si hay acceso a registros, si el proveedor entrega configuración, si hay datos regulados y si ya existe un conjunto de pruebas.

Las opciones cambian según el problema. Lo que ya trae tu herramienta puede bastar para accesos, retención y registros básicos. Una plataforma de automatización sirve cuando el flujo es simple y se prueba con reglas claras. Un desarrollo a la medida tiene sentido cuando hay RAG, agentes, permisos finos o integración con varios sistemas; ahí suele entrar trabajo de consultoría de IA y arquitectura técnica.

Lo que hacemos

• Consultoría de IA Arquitectura, criterios de evaluación y costo por consulta antes de escribir código.
• Sistemas RAG Segmentación, reordenamiento y búsqueda híbrida, evaluados con recall@k y NDCG.
• Rescate de proyectos El sistema ya está en producción y responde mal. Lo medimos y determinamos qué corregir.