IA en tu empresa: dónde sí conviene y dónde no

Casi todas las empresas hoy tienen una idea de dónde «meter IA». Pocas tienen un criterio para saber si esa idea vale la pena. La diferencia entre un proyecto útil y un experimento caro suele estar en las preguntas que se hacen antes de empezar.

Lo que sigue no es una lista de tendencias: es un criterio práctico, escrito para quien tiene que decidir si invertir o no.

Dónde suele funcionar

Los modelos actuales son buenos con texto, documentos y patrones en datos históricos. Rinden más cuando hay volumen, cuando un error es corregible y cuando una persona puede revisar lo dudoso. Algunos casos típicos:

• Extracción de datos de documentos. Facturas, contratos, órdenes de compra o expedientes que hoy alguien captura a mano. Lo claro se registra solo y lo dudoso va a una persona.
• Clasificación y enrutamiento. Correos, tickets o solicitudes que llegan a un buzón y se reparten manualmente entre áreas.
• Búsqueda sobre tu propia información. Un asistente que responde preguntas sobre tus manuales y expedientes, citando las fuentes y respetando los permisos de cada persona.
• Borradores que alguien revisa. Resúmenes, respuestas a consultas frecuentes o reportes que una persona aprueba antes de enviarlos.
• Predicciones sobre datos propios. Demanda, mermas, rotación o morosidad, siempre que haya historial suficiente y se evalúe con honestidad si alcanza.

Lo que tienen en común: hay un proceso que ya existe, un costo medible hoy y un lugar natural para la revisión humana.

Dónde no conviene

• Cuando una regla simple resuelve casi todo. Si una condición bien escrita cubre el 90 % de los casos, una regla es más barata, más predecible y más fácil de explicar que un modelo.
• Decisiones con consecuencias legales o económicas sin una persona que las apruebe. Aprobar un crédito, despedir a alguien o rechazar una reclamación no debería delegarse por completo a un modelo.
• Cuando no hay forma de medir si funcionó. Sin una línea base y un criterio de acierto, no se sabe si el proyecto sirvió o solo parece que sí.
• Cuando no hay datos o no se pueden usar. Un modelo sin ejemplos reales de tu operación, o con datos que no puedes compartir, se queda en demostración.
• Cuando el proceso cambia cada mes. Se construiría algo para un proceso que ya no existe.

Cinco preguntas para evaluar un caso

1. ¿Cuánto cuesta hoy el proceso? Casos al mes, minutos por caso y errores actuales. Es la línea base contra la que se compara todo.
2. ¿Qué margen de error se puede aceptar? No hay modelo perfecto: hay que decidir de antemano cuántos errores son tolerables y cuáles no.
3. ¿Quién revisa lo dudoso? La revisión humana no es una debilidad del sistema: es la parte que lo hace seguro.
4. ¿Qué datos hacen falta y se pueden usar? Cantidad, calidad y permisos. Y si contienen información personal o confidencial, qué reglas aplican.
5. ¿Cómo vamos a saber que funcionó? Dos o tres indicadores acordados antes de empezar, medidos de la misma forma antes y después.

Datos y privacidad

Antes de enviar documentos a un modelo, hay que saber a dónde viajan y qué se hace con ellos. Hay varias opciones: usar un servicio comercial con las condiciones adecuadas, ejecutar el modelo en tu propia nube o usar modelos abiertos dentro de tu infraestructura cuando los datos no pueden salir.

La decisión depende de qué información tratas. Si incluye datos personales, conviene revisarla con quien lleva el cumplimiento normativo en tu empresa antes de elegir la arquitectura, no después.

La prueba de concepto

La forma más barata de averiguar si una idea funciona es una prueba de concepto acotada: una tarea concreta, con tus propios datos, un criterio de éxito escrito de antemano y un plazo corto. Termina con una recomendación clara: continuar, ajustar o detenerse.

Detenerse también es un buen resultado. Es mucho más barato descubrirlo en una prueba de unas semanas que después de construir el sistema completo.

Errores frecuentes

• Empezar por la tecnología. «Queremos un chatbot» no es un problema de negocio.
• Pilotos que nunca terminan. Sin criterio de éxito y fecha, un piloto se vuelve permanente.
• Un asistente que responde cualquier cosa. Sin límites ni fuentes citadas, tarde o temprano inventa.
• No evaluar después del lanzamiento. Los datos cambian: sin métricas continuas no se nota cuando el modelo se degrada.
• Prometer ahorros antes de medir. Primero la línea base; los resultados, cuando existen.