Cómo auditar un proyecto de IA que ya implementaste

Por qué casi nadie audita un proyecto de IA que ya está en producción

Un proyecto de IA se audita antes de lanzarlo con mucho más rigor del que se audita después. Existe un comité, una lista de riesgos, alguien que pregunta qué puede salir mal con los datos, con la decisión que toma el sistema, con la reputación de la empresa. Una vez que el sistema entra en producción y no explota en el primer mes, esa disciplina desaparece del calendario. El proyecto pasa de ser “lo que estamos evaluando” a ser “lo que ya tenemos”, y nadie vuelve a hacerle la pregunta incómoda: ¿esto sigue valiendo lo que cuesta?

La diferencia con la auditoría de riesgos es exactamente esa. Auditar riesgos es un ejercicio preventivo: se hace antes de encender el sistema, para decidir si se lanza, se limita el alcance o se espera. Auditar un proyecto ya implementado es un ejercicio retrospectivo: el sistema ya está prendido, ya cuesta una licencia mensual, y la pregunta no es si conviene lanzarlo, es si conviene seguir pagándolo tal como está hoy.

El síntoma más común de esta falta de auditoría no es un sistema que falla de forma ruidosa. Es un sistema que sigue en el presupuesto de tecnología, que aparece en la presentación de resultados como “implementado”, y que en la práctica el equipo dejó de usar hace meses sin que nadie en dirección se enterara. Esta guía es el proceso para detectarlo: un checklist de una semana, ejecutable por cualquier gerente, sin necesidad de leer una línea de código.

Qué es esta auditoría (y qué no)

Esta auditoría no revisa si el modelo de IA es bueno, ni compara proveedores, ni evalúa si la arquitectura técnica es la correcta. Revisa algo más simple y más urgente: si el sistema que ya se implementó sigue generando el resultado de negocio con el que se aprobó, o si se convirtió en un costo fijo que nadie se atreve a cuestionar.

• Una auditoría técnica del modelo o del código: eso lo resuelve el equipo técnico o el proveedor, si hace falta, con otro tipo de revisión.
• La misma auditoría de riesgos que se hace antes de lanzar un proyecto: esa mira lo que puede salir mal antes de encender el sistema, esta mira si valió la pena después de usarlo.
• Confirmar que el sistema está prendido y responde cuando alguien lo prueba. Un sistema que funciona técnicamente y que el equipo dejó de usar fracasó igual que uno que nunca funcionó.
• Un checklist de cumplimiento de TI genérico. Esta auditoría es específica al KPI de negocio con el que se justificó la inversión, no a la infraestructura en general.

Las cinco preguntas que hay que responder, sin excepción

Cada una de estas cinco preguntas se responde con evidencia, no con la opinión de quien lidera el proyecto. Si dos o más quedan sin respuesta clara, la auditoría ya encontró un problema, aunque el sistema siga prendido.

• ¿Se usa todos los días, o el equipo volvió al proceso manual en la sombra? Un sistema de IA se implementa para reemplazar o apoyar una tarea que antes se hacía a mano. Meses después, es común que parte del equipo haya vuelto, en silencio, al Excel o al WhatsApp de siempre, porque el sistema le pareció más lento, menos confiable o porque nadie exigió el cambio de hábito. Esa vuelta casi nunca se reporta hacia arriba: se hace en la sombra, y en el reporte mensual el sistema sigue apareciendo como “en uso”.
• ¿Mueve el KPI de negocio que se prometió al inicio, o nadie volvió a medirlo? Todo proyecto de IA se aprueba con un número detrás: horas ahorradas, errores reducidos, ventas recuperadas, tiempo de respuesta. La pregunta no es si ese número se definió bien al inicio, es si alguien lo sigue midiendo hoy contra la misma línea base. Es frecuente encontrar proyectos donde nadie ha vuelto a calcular el KPI desde el mes de lanzamiento, y el “funciona” se sostiene solo en la memoria de que en algún momento funcionó.
• ¿Los datos que consume el sistema siguen limpios y actualizados? Un sistema que decide o recomienda con datos de hace un año, con catálogos desactualizados o con información que cambió de fuente sin que nadie lo notara, empieza a degradarse en silencio. La calidad de los datos no es un chequeo de una sola vez al lanzar el proyecto, es algo que se puede deteriorar mes a mes sin que el sistema deje de responder.
• ¿Existe documentación de cómo está armado el sistema? Si la única persona que entiende cómo funciona el sistema completo (qué datos entran, qué reglas aplica, qué pasa si falla) renunciara mañana, ¿alguien más en la empresa podría operarlo o explicarlo? Si la respuesta es no, el sistema no está documentado, está memorizado por una persona, y eso es un riesgo que crece cada mes que pasa sin corregirse.
• ¿La empresa depende al cien por ciento del proveedor original para cualquier cambio? Esto es vendor lock-in: si cada ajuste, por pequeño que sea, requiere abrir un ticket con el proveedor externo y esperar su disponibilidad y su tarifa, la empresa no controla el sistema, lo renta con opción a que le suban el precio cuando quiera. Vale la pena distinguir la dependencia razonable (el proveedor sostiene la infraestructura) de la dependencia total (nadie dentro de la empresa entiende ni puede tocar nada).

El proceso: cómo ejecutarla en una semana, sin ser técnico

Este proceso lo puede liderar un gerente de operaciones, de administración o el dueño del negocio, sin necesitar traducir una sola línea de código. Lo único que requiere es autoridad para pedir información a las áreas correctas y disciplina para no conformarse con “sí, funciona bien” como respuesta.

Día 1: medir el uso real, no el uso reportado

• Pide el reporte de uso del sistema (logins, consultas procesadas, tareas completadas) de los últimos tres meses, no la percepción de quien lo administra.
• Compara ese número contra el volumen que el proceso manejaba antes de la implementación: si el volumen procesado por el sistema es menor al que el equipo maneja en total, alguien está compensando por fuera.
• Pregunta directamente al equipo operativo, sin el jefe de área presente, si hay pasos que siguen haciendo manualmente “por si acaso” o “porque es más rápido así”.

Día 2: revisar el KPI contra la línea base original

• Busca el documento o la presentación donde se aprobó el proyecto: ahí debería estar el número que se prometió mover y la línea base contra la que se iba a medir.
• Si nadie puede encontrar ese documento o ese número, ya es un hallazgo de la auditoría: un proyecto sin línea base no se puede evaluar, solo se puede opinar sobre él.
• Si el número existe, pide la medición más reciente. Si la medición más reciente tiene más de tres meses de antigüedad, trátalo como “no medido”, no como “funcionando”.

Día 3: revisar el estado real de los datos

• Pregunta a quien administra los datos que alimentan el sistema cuándo fue la última vez que se revisó su calidad o se actualizó la fuente.
• Pide un ejemplo reciente de una decisión o recomendación del sistema y verifica manualmente si el dato de origen era correcto y estaba vigente.
• Si el sistema depende de una integración con otro software que cambió en los últimos meses (nuevo CRM, nuevo ERP), confirma si esa integración se actualizó o si sigue leyendo información de una fuente que ya no es la oficial.

Día 4: pedir la documentación (o generarla en el momento)

• Pide, por escrito, un documento de una página que explique qué hace el sistema, qué datos usa, quién lo administra y qué pasa si falla.
• Si ese documento no existe, pide a quien conoce el sistema que lo escriba esa misma semana. Que a la empresa le tome un esfuerzo notable producirlo es, en sí mismo, el hallazgo.
• Verifica si más de una persona dentro de la empresa podría explicar el sistema con ese nivel de detalle, o si depende de una sola persona irremplazable.

Día 5: medir la dependencia real del proveedor

• Pregunta qué pasaría si el proveedor subiera el precio del contrato de forma significativa en la próxima renovación: ¿la empresa tiene alternativa real, o tendría que aceptar la condición porque no hay forma de migrar sin rehacer todo?
• Revisa el contrato: ¿la empresa es dueña de sus propios datos y configuraciones, o todo vive dentro de la infraestructura del proveedor sin posibilidad de exportarlo?
• Cierra la semana con una reunión de una hora donde se presentan los cinco hallazgos (uso, KPI, datos, documentación, dependencia) con evidencia concreta, y se decide: seguir igual, corregir, renegociar con el proveedor o dar de baja el sistema.

Errores comunes al auditar un sistema ya implementado

• Confundir “el sistema está prendido” con “el sistema funciona”. Un sistema puede responder perfectamente y estar siendo usado por una fracción del equipo que se supone lo adoptó.
• Preguntar solo al jefe de área que lidera el proyecto, y nunca a quien lo opera todos los días. El jefe de área tiene incentivo para reportar que todo va bien; el operador sabe qué tan seguido lo evita.
• Medir el éxito del proyecto contra “se siente que ayuda” en vez de contra el número exacto que se prometió al aprobarlo.
• Aceptar que “no hay tiempo” para documentar el sistema como una excusa permanente, en vez de tratarlo como el riesgo que es: una empresa que no puede operar su propio sistema sin un proveedor externo.
• Descubrir la dependencia total del proveedor recién cuando este anuncia un aumento de precio o dice que ya no puede seguir dando soporte, en vez de medirla con anticipación.

Cómo se ve esto en la práctica

Una empresa retail mediana en Perú, con canal de ventas online y quince tiendas físicas, implementó un año atrás un sistema de recomendación de productos basado en IA para su tienda en línea, con la promesa de subir el ticket promedio. El proyecto se presentó en su momento como un éxito: el sistema estaba activo, el proveedor mandaba reportes técnicos de que todo funcionaba sin errores, y en la agenda de directorio dejó de mencionarse.

La auditoría, ejecutada por la gerenta de operaciones en una semana, encontró algo distinto a lo que decía el reporte técnico. El sistema seguía activo, pero el equipo de marketing había dejado de revisar sus recomendaciones hacía meses porque, según ellos, “ya no coincidían con el catálogo actual”: el catálogo de productos se actualizaba en un sistema nuevo que la empresa había migrado seis meses antes, y nadie había avisado al proveedor del sistema de recomendación para reconectar esa fuente. El KPI original (ticket promedio) nunca se había vuelto a medir desde el mes de lanzamiento, y cuando se calculó con datos actuales, no mostraba diferencia frente a la línea base de un año atrás.

El hallazgo más incómodo fue el de documentación y dependencia: nadie en la empresa, fuera del proveedor, sabía exactamente qué reglas usaba el sistema para recomendar un producto sobre otro, y cualquier ajuste, incluso reconectar el catálogo actualizado, requería un ticket pagado al proveedor con un tiempo de respuesta de dos a tres semanas. La empresa no tenía un sistema de recomendación funcionando: tenía un contrato activo con un proveedor, desconectado en silencio del negocio real. La decisión, con la evidencia de la auditoría sobre la mesa, fue renegociar el contrato para incluir mantenimiento de la integración de datos y fijar una revisión trimestral obligatoria del KPI, en vez de dar de baja el sistema sin entender primero por qué había dejado de funcionar.

Mi criterio

Cómo saber si esta auditoría se hizo bien

Esta auditoría, igual que el sistema que revisa, se puede evaluar con evidencia concreta al final de la semana.

• Se puede responder, con un número y no con una impresión, qué porcentaje del equipo objetivo usa el sistema hoy de forma consistente.
• Existe una medición del KPI original hecha en los últimos tres meses, comparada contra la línea base de cuando se aprobó el proyecto.
• Alguien, además del proveedor, puede explicar en menos de cinco minutos qué datos usa el sistema, qué reglas aplica y qué pasa si falla.
• La empresa sabe, con evidencia del contrato, qué tan dependiente está del proveedor original para hacer cualquier cambio, y no lo está adivinando.
• La reunión de cierre terminó con una decisión escrita: seguir igual, corregir algo puntual, renegociar el contrato o dar de baja el sistema, no con “lo revisamos y en general está bien”.