↓Ir al contenido
  1. Articulos/

¿Tu empresa necesita IA o necesita resolver otro problema?

·1080 palabras·6 mins
Ilustración tipo cómic con el titular «¿Necesitamos IA?», cajas de procesos y datos y un robot, que plantea empezar por el problema.

Te piden «una estrategia de IA». Suena importante y queda bien en una presentación; además, todavía no obliga a explicar qué problema queremos resolver.

Una empresa puede querer usar IA sin necesitarla para ese problema. A veces el atasco está en un proceso mal diseñado, datos desconectados o una regla de negocio que nadie ha automatizado. Poner un modelo encima puede hacer que todo parezca más moderno, no que funcione mejor.

Yo empezaría por «¿qué resultado queremos mejorar y qué nos lo impide?», no por «¿qué podemos hacer con IA?».

Primero el problema; después la tecnología #

Imaginemos que atención al cliente tarda demasiado en resolver solicitudes. «Añadamos un copiloto» es una hipótesis, no un diagnóstico. Primero averiguaría si el tiempo se pierde buscando información, esperando aprobaciones o interpretando mensajes distintos.

Cada causa apunta a otra solución: aclarar quién aprueba es trabajo de proceso; reunir datos dispersos exige integración; aplicar condiciones claras suele resolverse con reglas verificables. Un modelo puede ayudar a interpretar texto libre, pero no tiene por qué decidir el flujo entero. La IA puede ocupar una etapa mientras las validaciones y acciones siguen en código normal.

Un ejemplo: las devoluciones #

Supongamos que una empresa quiere automatizar las devoluciones. La idea tentadora es que un agente lea el correo, busque el pedido, interprete la política y emita el reembolso. Separaría el flujo antes de construirlo:

  1. Aprobación redundante: revisar el proceso y los límites de autorización.
  2. Pedido y compra en sistemas distintos: integrar los datos, no pedirle al modelo que adivine.
  3. Elegibilidad basada en fecha y política explícita: aplicar reglas que podamos probar y auditar.
  4. Motivo escrito en texto libre: probar un modelo para clasificarlo y medir los errores.

El modelo podría interpretar el texto; el código verifica el pedido y la política; una persona revisa excepciones sensibles. Si las reglas resuelven el caso, no hace falta montar un agente para redescubrirlas con más tokens.

Flujo de devoluciones: la IA interpreta el mensaje, el código valida el pedido y la política, y una persona revisa las excepciones
El modelo interpreta el texto; las reglas verifican la devolución; una persona revisa los casos dudosos.

Cuándo sí merece la pena probar IA #

El texto libre por sí solo no justifica un modelo. Buscaría estas señales antes de probarlo:

  • Hace falta interpretar entradas variables y las reglas empiezan a acumular excepciones.
  • La tarea tiene impacto real, por frecuencia o por el valor de resolverla mejor.
  • Podemos definir y revisar la calidad con ejemplos representativos.
  • El modelo tendrá el contexto necesario y la mejora puede superar el coste completo frente a una solución simple.

La guía de adopción de IA de Microsoft también considera valor, viabilidad y recursos. Estas señales no prueban que «hace falta IA»: justifican una prueba acotada y una comparación con la línea base.

No compares una demo con el proceso actual #

Una demo demuestra que algo puede funcionar en condiciones preparadas, no que mejore el trabajo diario. Google recomienda medir el sistema actual y compararlo con una línea base, como una heurística o una solución simple. Sin datos sobre el tiempo y la calidad actuales, no sabremos si hemos mejorado.

Comparemos las opciones con la misma unidad —por ejemplo, «una devolución resuelta correctamente»— y midamos calidad, tiempo, revisiones y coste total, incluidos integración y supervisión. También importa el impacto de los errores y si podemos revertirlos: el precio por token no es toda la factura.

El AI Risk Management Framework de NIST ayuda a evaluar esa decisión. NIST (National Institute of Standards and Technology) es una agencia federal estadounidense del Departamento de Comercio que desarrolla ciencia de medición y estándares. Su marco voluntario propone, en la función Map, entender propósito, contexto e impactos antes de avanzar; Measure contempla evaluar el sistema antes y durante su uso.

Cuándo no pondría IA, al menos de momento #

También hay motivos para no poner IA —o para posponerla—:

  • El proceso no está definido: aclaremos cómo debería funcionar antes de automatizarlo.
  • Las reglas son estables: un workflow suele ser más predecible y fácil de auditar.
  • Faltan datos fiables o contexto: el modelo no arregla sistemas desconectados ni políticas contradictorias.
  • No podemos evaluar o controlar los errores: sin revisión o forma de revertir una acción sensible, no la dejaría en manos del modelo.

La IA añade coste, variabilidad y trabajo de evaluación. Si una solución sencilla basta, el modelo suma piezas sin una mejora demostrada. Y si no sabemos qué queremos conseguir, no tenemos un caso de uso: tenemos una tecnología buscando empleo.

¿Y los gráficos de mercado? #

Los análisis de proveedores responden a otra pregunta. Una Forrester Wave o un IDC MarketScape compara ofertas con criterios propios; sirve para evaluar opciones cuando ya sabemos qué tipo de solución buscamos.

Que un proveedor aparezca en un gráfico no demuestra que esa tecnología resuelva nuestro problema. Primero decidimos qué necesitamos; después comparamos quién puede cubrirlo. Hacerlo al revés es comprar una solución buscando dónde colocarla.

La IA puede aportar valor, pero no un porcentaje universal #

Tampoco se trata de descartar la IA. Generative AI at Work, de Brynjolfsson, Li y Raymond, estudió un asistente generativo usado por 5.179 agentes de atención al cliente. Reportó un promedio de 14 % más incidencias resueltas por hora, con mayor efecto entre trabajadores novatos y un impacto mínimo entre los más experimentados. NBER identifica una versión publicada en The Quarterly Journal of Economics en 2025.

Es un resultado contextual, no una calculadora de ROI: una herramienta, una tarea, una población y una métrica. No demuestra que cualquier empresa aumentará su productividad un 14 %; muestra que el efecto puede variar según el trabajo y la experiencia.

Una decisión que también puede ser «todavía no» #

Antes de dar luz verde a un proyecto, intentaría responder:

  1. ¿Qué resultado concreto queremos mejorar y cuál es la causa del problema?
  2. ¿Podemos medir la calidad frente a una alternativa más sencilla?
  3. ¿Son aceptables el coste completo, los errores y los controles necesarios?

Si aún no podemos contestar las dos primeras, comprar una plataforma es adelantarnos varias pantallas. Quizá baste con mejorar el proceso, arreglar los datos o automatizar una regla. Resolverlo sin IA no es quedarse atrás; es evitar complejidad innecesaria. Y si la IA gana la comparación, sabremos qué trabajo debe hacer y cómo comprobar su valor.

Diagrama para decidir si probar IA: definir el problema, revisar proceso y datos, comprobar si hace falta interpretar entradas variables y comparar el piloto con una solución simple
La IA se gana su sitio al mejorar una línea base con un coste y un riesgo aceptables.

Recursos #