En casi todas las empresas medianas con las que conversamos aparece la misma escena: la gerencia sabe que la inteligencia artificial puede aportar, hay una lista larga de ideas y nadie tiene claro por dónde empezar. Algunas ideas vienen de un proveedor, otras de una conferencia y otras de un área que lleva años pidiendo ayuda. El riesgo no es elegir mal la tecnología; es elegir un primer proyecto que no se pueda medir, que dependa de datos que no existen o que nadie dentro de la operación quiera usar.
El primer caso de uso tiene un peso desproporcionado. Si sale bien, abre presupuesto y genera confianza para los siguientes. Si se queda en piloto eterno, la conclusión interna suele ser «la IA no es para nosotros», aunque el problema haya sido la selección. Por eso vale la pena dedicarle unas semanas de análisis antes de escribir una sola línea de código.
Empieza por el problema, no por la herramienta
Una buena pregunta inicial no es «¿dónde podemos usar IA?», sino «¿qué tarea consume tiempo valioso, se repite con frecuencia y tiene un resultado que podemos verificar?». Recorre las áreas con esa pregunta y anota procesos concretos: responder solicitudes de cotización, clasificar correos de servicio al cliente, revisar documentos de proveedores, conciliar facturas o preparar informes semanales.
Para cada proceso, escribe en una línea quién lo hace hoy, cuántas veces ocurre y qué pasa cuando sale mal. Ese inventario, aunque sea imperfecto, ya es más útil que cualquier lista de tecnologías.
Cuatro criterios para filtrar la lista
Con el inventario en la mano, califica cada candidato en cuatro dimensiones. No hace falta una fórmula sofisticada: una escala de uno a cinco y una conversación honesta con los dueños de cada proceso suelen bastar.
- Valor de negocio. ¿Cuánto tiempo, dinero o riesgo se mueve si el proceso mejora? Expresa el beneficio en términos que entienda el área financiera: horas liberadas, días de ciclo, errores evitados o ventas que hoy se pierden por falta de respuesta.
- Disponibilidad de datos. ¿Existen los datos que la solución necesita, en formato digital y con un acceso razonable? Un caso brillante que depende de información dispersa en hojas de cálculo personales o en papel tiene un costo oculto alto.
- Riesgo y control. ¿Qué pasa si el sistema se equivoca? Los primeros proyectos funcionan mejor cuando una persona revisa el resultado antes de que llegue al cliente o a un sistema crítico. Así el error se vuelve aprendizaje y no incidente.
- Adopción. ¿Hay un equipo que quiere la solución y un responsable dispuesto a usarla todos los días? Sin un dueño en la operación, incluso un buen modelo termina sin uso.
Los candidatos con mejor puntaje rara vez son los más vistosos. Suelen ser procesos de apoyo, frecuentes y algo tediosos, donde el equipo agradece la ayuda y el resultado se compara con facilidad con el trabajo manual.
Define el éxito antes de construir
Antes de arrancar, acuerda con el área dueña tres cosas: la línea base (cómo se hace hoy y cuánto toma), la métrica principal que va a cambiar y el umbral a partir del cual el proyecto se considera exitoso. Si no puedes medir la situación actual, mídela durante dos o tres semanas antes de empezar. Sin línea base, cualquier resultado se vuelve discutible.
También conviene definir qué no hará el sistema. Un alcance acotado, por ejemplo «clasificar los correos de garantías y sugerir una respuesta, sin enviarla», reduce el riesgo y acelera la entrega.
Piensa en producción desde el primer día
Un prototipo que funciona en el computador de un analista no es un caso de uso resuelto. Desde el diseño, pregunta dónde va a vivir la solución, con qué sistemas se integra (ERP, CRM, correo, WhatsApp), quién la mantiene y cómo se detecta si su calidad empieza a bajar. Estas preguntas no frenan el proyecto: evitan que se quede en demostración.
Si el caso involucra datos personales de clientes o empleados, revisa desde el inicio las obligaciones de la Ley 1581 de 2012: finalidad informada, autorización del titular cuando corresponda y medidas de seguridad adecuadas. Es más barato diseñar con estas reglas que corregir después.
Un plan razonable para el primer trimestre
- Semanas 1 a 3: inventario de procesos, calificación con los cuatro criterios y elección de un caso principal y uno de respaldo.
- Semanas 4 a 6: medición de la línea base, revisión de los datos y prototipo con información real.
- Semanas 7 a 12: versión integrada en el flujo de trabajo, con revisión humana, métricas visibles y una decisión explícita al final: escalar, ajustar o detener.
Detener un proyecto también es un resultado válido si se decide con datos. Lo que conviene evitar es el piloto que nunca termina.
El mejor primer caso de uso no es el más ambicioso, sino el que demuestra valor medible en pocas semanas y deja capacidades —datos ordenados, integraciones, criterios de calidad— para el siguiente.
Si quieres contrastar tu lista de candidatos con una mirada externa, nuestro diagnóstico inicial está pensado para eso: ordenar las ideas, revisar los datos disponibles y proponer por dónde empezar.
