La pregunta «¿qué retorno genera la IA?» parece concreta, pero todavía no contiene suficiente información para responder.
La IA no produce un retorno por sí sola. Lo produce —o no— una intervención específica sobre un proceso concreto, utilizada por determinadas personas y medida contra una situación inicial. Un asistente documental, una automatización administrativa y un sistema de predicción no comparten costes, riesgos ni resultados.
Por eso los porcentajes generales sirven poco para decidir. El retorno que importa se calcula con los datos de tu empresa y con una prueba diseñada para poder equivocarse sin comprometer todo el sistema.
Antes del ROI: define el problema
Una empresa puede empezar por la herramienta porque resulta visible y fácil de comprar. El problema puede ser menos atractivo: información dispersa, tareas repetidas, decisiones lentas, errores, conocimiento difícil de transferir o clientes que esperan demasiado.
La primera formulación debería incluir:
- qué proceso se quiere mejorar;
- qué personas intervienen;
- qué ocurre hoy;
- qué resultado tendría valor;
- qué riesgos no son aceptables;
- qué evidencia permitiría decidir.
Si no existe una respuesta concreta, calcular el ROI es prematuro. Solo produciría una cifra decorativa.
La línea base: qué sucede antes de intervenir
No puedes atribuir una mejora si no sabes cómo funcionaba el proceso antes. La línea base debe construirse con observaciones propias, no con un benchmark genérico.
Según el caso, puede incluir:
- tiempo total dedicado al proceso;
- número y tipo de errores;
- esperas entre una tarea y otra;
- volumen que el equipo puede asumir;
- coste de las herramientas actuales;
- retrabajo y excepciones;
- satisfacción de usuarios o clientes;
- riesgos legales, de privacidad o calidad.
No todo necesita convertirse en dinero. Reducir una espera, mejorar la consistencia o evitar una exposición sensible puede ser valioso aunque la traducción financiera no sea inmediata. Lo importante es decidir qué cambio cuenta y cómo se observará.
Costes que también conviene incluir
El precio de una licencia es solo una parte. Una evaluación seria contempla el coste total de poner la solución en funcionamiento y mantenerla.
Comprensión y diseño
Hay que estudiar el proceso, ordenar datos, decidir límites, elegir la intervención y preparar la prueba.
Construcción e integración
Puede incluir configuración, programación, conexión con herramientas existentes, migraciones y controles.
Adopción
Las personas necesitan entender qué cambia, cuándo usar la solución, cuándo no confiar en ella y cómo informar de un error.
Operación
Una solución requiere responsable, mantenimiento, revisión de costes, observación de calidad y respuesta ante cambios del proveedor o del proceso.
Riesgo
Privacidad, propiedad intelectual, errores, dependencia de terceros y decisiones incorrectas también forman parte del coste esperado.
Un proyecto que ahorra tiempo pero introduce una responsabilidad imposible de gobernar puede tener retorno operativo y seguir siendo una mala decisión.
Un cálculo útil
En lugar de partir de una promesa de mercado, construye el cálculo con variables propias:
Retorno observado = valor del cambio demostrado − coste total de la intervención
ROI = retorno observado / coste total de la intervención
La fórmula es sencilla. Lo difícil es evitar que sus componentes sean deseos disfrazados de datos.
Separa:
- dato observado: procede del proceso real;
- hipótesis: lo que crees que cambiará;
- resultado de la prueba: lo que ocurrió durante la validación;
- proyección: lo que podría suceder si se amplía.
Una proyección debe mostrar sus supuestos. No debe presentarse como resultado.
Cómo diseñar una primera prueba
1. Elige un proceso acotado
Debe ser suficientemente relevante para aprender, pero no tan crítico que un fallo cause un daño difícil de revertir.
2. Define el objeto utilizable
Puede ser un asistente interno, un flujo automatizado, un buscador, un protocolo o una herramienta de apoyo. Debe poder usarse en una situación real, no solo demostrarse en una presentación.
3. Mantén una comparación
Compara con la línea base o, cuando sea posible, con una parte del proceso que continúa operando como antes. Sin comparación es fácil atribuir a la IA cualquier variación.
4. Observa calidad además de velocidad
Hacer más rápido una tarea con más errores no es una mejora. Registra excepciones, revisiones humanas, incidencias y consecuencias.
5. Decide antes qué harás con cada resultado
Define qué evidencia permitiría ampliar, qué obligaría a corregir y qué cerraría el proyecto. Así evitas mantenerlo solo porque ya se ha invertido tiempo.
Cuatro errores que falsean el retorno
Contar todo el tiempo liberado como ahorro
El tiempo solo genera valor económico si puede reasignarse a una actividad útil, evitar capacidad adicional o mejorar un resultado relevante.
Ignorar la revisión humana
Si cada salida necesita ser comprobada, esa revisión forma parte del coste del proceso nuevo.
Extrapolar demasiado pronto
Una prueba limitada no demuestra que la solución mantendrá calidad, coste y adopción al ampliarse.
Medir actividad en lugar de resultado
Número de prompts, usuarios registrados o documentos generados no demuestra valor. La métrica debe conectar con el problema inicial.
Cuándo una auditoría de IA puede ser el proyecto correcto
Tiene sentido cuando existen varias oportunidades posibles y la empresa no sabe cuál merece atención; cuando las herramientas ya se usan sin criterio común; o cuando un intento anterior no produjo una decisión clara.
La auditoría no debería terminar con una lista de software. Debería dejar:
- una lectura del proceso y de las personas;
- oportunidades priorizadas;
- riesgos y renuncias visibles;
- una primera prueba recomendada;
- métricas y línea base;
- una decisión de destino.
BTA puede desarrollar este tipo de proyecto cuando existe acceso al contexto y voluntad de contrastar la solución con la realidad. No se presupone que la conclusión sea implementar más IA.
Relacionado: Auditoría de IA para empresas: qué es y cuándo hacerla · Cómo implementar IA sin equipo técnico
Sobre el autor
Marc Duran
Psicólogo e investigador-diseñador de proyectos. En BTA conecta comportamiento humano, filosofía práctica y disciplina de negocio para convertir preguntas en proyectos utilizables.
Conocer a Marc