Cómo saber si tu empresa necesita inteligencia artificial (y cuándo no)

Empieza por el problema, no por la tecnología

El error más común es comenzar con la solución: "queremos un chatbot", "queremos un agente", "queremos usar GPT". Cuando el punto de partida es la herramienta, el proyecto termina buscando un problema que justifique la inversión, y eso rara vez sale bien.

Un mejor punto de partida es preguntar dónde se le va el tiempo al equipo. ¿Qué tareas se repiten todos los días? ¿Dónde se acumulan correos, documentos o solicitudes sin respuesta? ¿Qué decisiones se toman tarde porque la información está dispersa? Esas respuestas, y no la novedad de una tecnología, son las que indican si existe una oportunidad real.

Una vez identificado el problema, la siguiente pregunta es de qué tipo es. Y aquí aparece la distinción más importante de todo el análisis.

Reglas claras o lenguaje ambiguo: la diferencia que define la solución

Muchos procesos que parecen candidatos para IA en realidad se resuelven con automatización tradicional. Si la tarea sigue reglas que se pueden escribir —"cuando llega una factura de este proveedor, registrarla en este sistema y notificar a contabilidad"—, un flujo automatizado es más barato, más predecible y más fácil de auditar que un modelo de lenguaje.

La inteligencia artificial empieza a tener sentido cuando la entrada no es estructurada: textos libres, correos redactados de mil formas distintas, documentos escaneados, conversaciones con clientes, contratos con cláusulas que cambian de un caso a otro. Ahí las reglas fijas se quedan cortas, porque no es posible anticipar todas las variaciones, y un modelo capaz de interpretar lenguaje sí aporta algo que antes requería a una persona leyendo.

• Si puedes escribir la regla completa en una hoja, probablemente necesitas automatización, no IA.
• Si la tarea exige leer, interpretar o resumir texto variable, la IA puede aportar valor.
• Si el error tiene consecuencias graves, la IA debe proponer y una persona debe aprobar.
• Si no hay datos ni ejemplos del proceso, primero hay que ordenarlos.

Casos donde la IA suele funcionar bien

Hay un grupo de tareas en las que los modelos de lenguaje actuales ofrecen resultados consistentes cuando se diseñan con cuidado. La clasificación de solicitudes es uno de ellos: leer un correo o un PQR y decidir a qué área corresponde, qué tan urgente es y qué información falta. Otro es la extracción de datos desde documentos: tomar una orden de compra, una factura o un formulario y convertirlo en campos listos para un sistema.

También funcionan bien los asistentes internos que responden preguntas sobre la documentación propia de la empresa —manuales, políticas, procedimientos—, siempre que se construyan sobre esa información y citen de dónde sale cada respuesta. Y la revisión preliminar de documentos largos, como contratos, donde el modelo no decide, sino que señala las secciones que una persona debe mirar con atención.

En todos estos casos hay un patrón: la IA no reemplaza el criterio de nadie. Reduce el trabajo de leer, ordenar y preparar la información para que el equipo dedique su tiempo a decidir.

Cuándo no vale la pena

Hay situaciones en las que recomendar IA sería un mal consejo. Cuando el proceso es poco frecuente —unas cuantas veces al mes—, el costo de diseñar, probar y mantener una solución inteligente no se recupera. Cuando la información de entrada es muy pobre o contradictoria, el modelo producirá respuestas igual de pobres, con la desventaja de que sonarán convincentes.

Tampoco conviene cuando el proceso todavía no está definido. Si dos personas del mismo equipo resuelven el mismo caso de formas distintas, la IA no va a resolver ese desacuerdo: lo va a reproducir. Primero hay que acordar cómo debería funcionar el proceso y después decidir qué parte automatizar.

Y hay un caso más: cuando la empresa no tiene cómo verificar los resultados. Un sistema que nadie revisa termina tomando decisiones que nadie entiende. Si no existe una forma de medir si la IA está acertando, el proyecto no está listo.

Qué preparar antes de implementar

Una implementación responsable no empieza con código. Empieza con ejemplos reales del proceso: correos, documentos, solicitudes, con sus respuestas correctas. Esos ejemplos sirven para diseñar la solución y, sobre todo, para medirla. Sin ellos, no hay forma objetiva de saber si el sistema funciona.

También hay que pensar en los datos. En Colombia, el tratamiento de datos personales está regulado por la Ley 1581 de 2012, y eso aplica cuando la información de clientes, empleados o proveedores pasa por un servicio de inteligencia artificial. Hay que saber qué datos se envían, a qué proveedor, con qué condiciones de uso y retención, y si es posible anonimizarlos antes de procesarlos.

Finalmente, conviene definir desde el principio qué pasa cuando el sistema no está seguro. Una buena solución de IA sabe cuándo pasar el caso a una persona, y ese camino de escalamiento debe estar diseñado, no improvisado.

• Reunir ejemplos reales del proceso con su resultado esperado
• Definir cómo se medirá el acierto antes de construir
• Revisar qué datos personales se procesan y con qué proveedor
• Diseñar la revisión humana y el escalamiento de casos dudosos
• Empezar con un piloto acotado antes de extenderlo a toda la operación

Un piloto pequeño vale más que una gran promesa

La forma más sensata de adoptar IA es con un piloto: un proceso concreto, un grupo pequeño de usuarios, un periodo definido y una métrica clara. Al final del piloto la pregunta no es si la tecnología es impresionante, sino si el proceso mejoró: menos tiempo por caso, menos errores, respuestas más rápidas o menos trabajo repetitivo.

Si el piloto funciona, se amplía con evidencia. Si no funciona, la empresa aprendió algo importante con una inversión acotada. En ambos casos, la decisión se toma con datos y no con expectativas.