Auditoría técnica de IA: qué revisar antes de invertir

Publicado: 2026-10-22

Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative

Qué revisar en una auditoría técnica de IA: datos, permisos, integraciones, evaluación y costes para delimitar un piloto antes de invertir en desarrollo.

Una auditoría técnica de IA sirve para decidir si un caso de uso puede convertirse en una herramienta fiable, qué bloqueos existen y cuánto conviene invertir en resolverlos. No consiste en comprar un modelo ni en reunir una lista de tecnologías. Su resultado debe permitir elegir entre configurar una herramienta, integrar sistemas, desarrollar una solución propia o no continuar.

La necesidad aparece cuando una empresa tiene ideas prometedoras pero poca evidencia: una demo responde bien, los documentos parecen suficientes y el equipo imagina un ahorro importante. Aun así, nadie ha comprobado permisos, excepciones, calidad de las respuestas ni coste por tarea terminada. Ese hueco es precisamente el trabajo del diagnóstico.

Esta guía propone qué revisar, qué pedir al proveedor y cómo convertir los resultados en un primer alcance verificable. Los ejemplos son escenarios hipotéticos de decisión, no resultados atribuidos a proyectos de clientes.

Auditoría técnica de IA: empezar por una decisión de negocio

La primera reunión debería terminar con una tarea descrita sin mencionar IA. Por ejemplo: localizar el procedimiento vigente para resolver una incidencia, preparar el contexto de una cuenta antes de una visita o clasificar solicitudes administrativas con sus documentos asociados. Si la definición es «tener un chat que sepa todo», falta delimitar el problema.

Para cada tarea identifica quién la realiza, cuántas veces ocurre, qué información necesita y cómo reconoce que la ha terminado correctamente. Observa también qué hace esa persona cuando falta un documento o dos sistemas se contradicen. Las excepciones explican mejor la dificultad del proyecto que una demostración con entradas perfectas.

Una buena auditoría recoge la situación actual antes de prometer mejoras. Mide una muestra de tiempos, errores y revisiones; indica su tamaño y sus límites. Si solo se dispone de estimaciones del equipo, deben conservarse como hipótesis. No es lo mismo reducir minutos de búsqueda que liberar capacidad utilizable, y ninguna de las dos cosas equivale automáticamente a ahorrar nóminas.

Qué fuentes y permisos debe revisar el diagnóstico

El inventario de datos debe responder a una pregunta concreta: ¿qué fuentes hacen falta para completar la tarea elegida? Puede incluir documentación, CRM, registros operativos y correos autorizados. No hace falta copiar todo el conocimiento de la empresa para comprobar un primer recorrido útil.

Para cada fuente registra propietario, ubicación, formato, actualización y restricciones. Un manual sin fecha, una tabla sin unidades o una carpeta compartida con permisos ambiguos pueden impedir un resultado fiable aunque el modelo sea competente. La revisión debe distinguir lo accesible de lo autorizado y lo vigente de lo meramente disponible.

• Fuente oficial y responsable de resolver contradicciones.
• Campos o documentos mínimos para el caso de uso.
• Calidad de extracción: texto, tablas, imágenes y referencias.
• Permisos por usuario, equipo, cliente y documento.
• Frecuencia de actualización y retirada de contenido antiguo.
• Condiciones de uso y límites de los sistemas existentes.

Si una persona no puede consultar un contrato, un asistente tampoco debe revelárselo mediante un resumen. Este control no puede depender únicamente de pedir al modelo que sea discreto: debe aplicarse en la recuperación y en las herramientas. También hay que probar que una revocación de acceso alcanza índices, cachés y resultados posteriores.

Auditoría técnica de IA: evaluar antes de elegir arquitectura

Una búsqueda documental, una consulta de stock y una clasificación de texto son problemas diferentes. La primera puede requerir recuperación de fragmentos y citas; la segunda necesita consultar el sistema autorizado; la tercera quizá funcione con una entrada breve y una salida estructurada. El diagnóstico debe explicar qué componente resuelve cada parte y por qué.

No todas las tareas requieren RAG, memoria persistente o agentes. Añadirlos sin una necesidad demostrada aumenta puntos de fallo y coste de operación. Tampoco conviene descartarlos por simplicidad aparente: si una respuesta necesita conocer antecedentes, vigencia documental y permisos individuales, un prompt aislado no cubre el alcance.

Una comparación útil conserva la misma muestra de casos y modifica una variable cada vez. Primero comprueba si se recupera la fuente correcta; después, si la respuesta respeta esa evidencia. Si la recuperación falla, cambiar el estilo del texto puede mejorar la impresión sin corregir el problema de fondo.

Cómo construir una prueba que pueda fallar

El conjunto de evaluación debería incluir preguntas habituales, casos difíciles y consultas que no tienen respuesta en las fuentes. Para cada una define qué evidencia sería suficiente y cuándo el sistema debe pedir aclaración o abstenerse. No basta con preguntar al equipo si las respuestas «parecen buenas».

Por ejemplo, en un escenario hipotético de soporte, una respuesta correcta puede exigir identificar el modelo del producto, recuperar el manual vigente y citar la sección aplicable. Si el usuario no indica la variante, lo adecuado puede ser preguntar. Una respuesta extensa sobre el modelo equivocado debe contar como error, aunque esté bien redactada.

Conviene separar al menos estas dimensiones:

1. Recuperación: encuentra la fuente que realmente resuelve la consulta.
2. Fidelidad: las afirmaciones están respaldadas por esa fuente.
3. Cobertura: responde lo necesario sin omitir una condición importante.
4. Autorización: no revela información ajena al permiso del usuario.
5. Abstención: reconoce que faltan datos o que el caso está fuera de alcance.
6. Operación: mantiene tiempos y costes aceptables con entradas reales.

Los resultados deben incluir fallos, no solo ejemplos seleccionados. Una muestra pequeña puede justificar seguir investigando, pero no demuestra una precisión universal. Guardar los casos y sus criterios permite repetir la evaluación cuando cambian documentos, modelos o integraciones.

Integraciones: comprobar acceso no equivale a resolver el proceso

Que una API responda es solo el comienzo. La auditoría debe verificar identificadores, campos, límites de uso, errores, credenciales y responsabilidades. También debe comprobar si el sistema permite el alcance requerido con la licencia y los permisos disponibles, sin asumir que cualquier conector comercial incluye todas las operaciones.

Para empezar, suele ser razonable limitarse a lectura y propuestas revisables. Si el producto necesita crear registros, enviar comunicaciones o modificar pedidos, hay que especificar quién autoriza cada acción y cómo se comprueba su resultado. Las reglas financieras, permisos y transiciones válidas deben vivir fuera del texto generado por el modelo.

Incluye casos de red interrumpida, eventos duplicados y datos que cambian durante una tarea. Una integración no debería repetir una operación con impacto por no haber recibido la confirmación anterior. Tampoco debe presentar como completado un paso que sigue en cola o ha fallado en un tercero.

Seguridad, privacidad y operación después de la demo

El diagnóstico debe identificar la información que puede salir hacia servicios externos y bajo qué condiciones. Las obligaciones concretas dependen de los datos, contratos, jurisdicción y función de cada parte; requieren validación jurídica cuando corresponda. Una decisión de arquitectura no sustituye esa revisión ni certifica cumplimiento por sí sola.

Desde el punto de vista técnico, pide un mapa de flujos de datos, accesos mínimos, gestión de secretos, entornos separados y retención de registros. Define qué se registra para investigar errores sin convertir los logs en una copia indiscriminada de documentos o conversaciones sensibles.

También interesa saber quién recibe alertas, quién puede detener una automatización y qué recorrido manual queda disponible. Si el proveedor de IA está temporalmente indisponible, el negocio necesita una salida explícita: búsqueda convencional, tarea pendiente, revisión humana o una función reducida claramente identificada.

Cómo estimar inversión y retorno sin falsa precisión

Separa trabajo inicial y operación recurrente. El primero puede incluir preparación de datos, desarrollo, integraciones, interfaz, pruebas y puesta en marcha. El segundo incluye infraestructura, consumo de modelos, actualización de fuentes, supervisión, soporte y evaluación de cambios. Un precio de API aislado no representa el coste del producto.

Para estimar consumo, utiliza la mezcla de tareas observada y escenarios de volumen, no solo una consulta corta de demostración. Considera entradas largas, reintentos, consultas sin respuesta y picos. Explica qué parte del cálculo está medida y qué parte sigue pendiente de validar.

El retorno necesita la misma disciplina. Compara el proceso completo antes y después, incluyendo revisión humana y correcciones. Si una respuesta tarda menos pero requiere comprobar cada párrafo, quizá la mejora neta sea pequeña. Si el equipo utiliza el tiempo liberado para atender más casos, ese beneficio debe medirse en capacidad real y calidad del servicio.

Qué documentos debería entregar una auditoría

El resultado útil es un paquete de decisiones, no un informe que enumere herramientas. Debe permitir presupuestar el siguiente paso, asignar responsables y entender qué información sigue faltando. Una recomendación favorable sin condiciones de éxito resulta difícil de contrastar después.

• Mapa del proceso y caso de uso prioritario, con exclusiones.
• Inventario de fuentes, permisos, calidad y bloqueos.
• Muestra de evaluación, criterios y resultados reproducibles.
• Arquitectura propuesta y alternativas descartadas con motivos.
• Riesgos, dependencias externas y decisiones del cliente.
• Alcance del piloto, entregables y criterios de aceptación.
• Estimación por bloques y supuestos de operación recurrente.
• Recomendación explícita: avanzar, corregir primero o detener.

Cómo contratar el primer paso sin comprometer toda la plataforma

Un diagnóstico puede tener alcance y precio cerrados si se acotan fuentes, interlocutores y muestra. Su aceptación no debería obligar a contratar toda la construcción posterior. Lo importante es que la empresa reciba evidencia y documentación utilizable, incluso si decide no desarrollar o cambia de proveedor.

Después puede acordarse un piloto con un único flujo y usuarios limitados. Define qué demostrará, qué no demostrará y cuál será la decisión al terminar. Ampliar a más departamentos, escribir en sistemas o automatizar acciones son decisiones posteriores, no consecuencias inevitables de haber creado un chat inicial.

Preguntas frecuentes

¿Hace falta tener todos los datos preparados antes de la auditoría?

No. Precisamente debe identificar qué falta. Sí conviene aportar una muestra autorizada, acceso a las personas que conocen el proceso y ejemplos de resultados correctos e incorrectos.

¿Una auditoría garantiza que la IA funcionará en producción?

No. Reduce incertidumbre dentro del alcance evaluado. Producción añade volumen, usuarios, cambios y responsabilidades operativas que deben validarse durante un despliegue controlado.

¿El resultado puede ser no desarrollar IA?

Sí. Si una búsqueda convencional, una regla o una mejora del proceso resuelven el problema con menos complejidad, esa es una conclusión valiosa. El diagnóstico debe proteger la inversión, no justificar una tecnología a cualquier precio.

El marco de gestión de riesgos de IA de NIST organiza el trabajo en gobernar, mapear, medir y gestionar. Puede servir como referencia para estructurar responsabilidades y evidencia; no sustituye la evaluación del caso ni las obligaciones concretas de la empresa.

Lecturas relacionadas

• Preparar los datos antes de un proyecto de IA
• Definir un MVP para validar el caso de uso
• Cómo trabajamos la IA y el conocimiento empresarial