IA para negocios: cómo empezar en 30 días

La mayoría de negocios que dicen haber probado inteligencia artificial en realidad probaron una herramienta durante una tarde. Abrieron un asistente, escribieron algunas peticiones, obtuvieron resultados irregulares y volvieron a lo de siempre. No es un fallo de la tecnología ni de la persona: es que empezar por la herramienta es el orden equivocado.

Este plan invierte el orden. Cuatro semanas, un solo caso de uso, una métrica y un responsable. Es deliberadamente pequeño, porque el objetivo del primer proyecto no es transformar el negocio: es aprender a implementar el segundo.

Semana 1: encontrar el caso correcto

Durante cinco días, registra el tiempo que dedicas tú y tu equipo a tareas que se repiten. No hace falta un sistema sofisticado: una hoja con tarea, veces por semana y minutos aproximados es suficiente. Casi todos los negocios que hacen este ejercicio se llevan la misma sorpresa: dos o tres tareas invisibles concentran una parte enorme del tiempo.

Con esa lista delante, filtra por tres condiciones. Repetición alta: al menos veinte veces por semana, porque por debajo de eso el ahorro no compensa el esfuerzo de montarlo. Resultado verificable: existe una respuesta correcta y alguien puede comprobar en segundos si está bien. Riesgo bajo: si la máquina se equivoca, se detecta antes de que cueste dinero o un cliente.

Los candidatos que salen de este filtro suelen ser cuatro: responder consultas frecuentes de clientes, extraer datos de documentos que llegan siempre en el mismo formato, redactar primeras versiones de textos comerciales, y clasificar mensajes o solicitudes que entran.

Los candidatos que suelen fallar el filtro, aunque suenen más ambiciosos: predecir la demanda, negociar con clientes, cualquier cosa que tu equipo resuelva con criterio distinto según el caso.

Antes de cerrar la semana, anota la línea base: cuántas horas consume hoy esa tarea, cuánto se tarda en responder, cuántos errores se cometen al mes. Sin este número, dentro de cuatro semanas solo tendrás impresiones.

Semana 2: documentar antes de automatizar

Esta es la semana que casi todo el mundo se salta y la que decide el resultado.

Escribe el proceso paso a paso, como si se lo explicaras a alguien que entra mañana. Qué entra, qué se hace con ello, qué sale, qué casos son excepciones y quién decide en cada bifurcación.

Después reúne la información que el sistema va a necesitar. Si el caso es atención al cliente: las cincuenta preguntas más frecuentes con sus respuestas aprobadas, precios vigentes, políticas de envío y devolución, horarios, condiciones. Si es procesamiento de documentos: ejemplos reales de los formatos que llegan, incluidos los feos. Si es redacción: cinco textos propios que sí funcionaron.

Este material es el activo del proyecto. Las herramientas se cambian en una tarde; esta documentación es lo que hace que el sistema responda cosas ciertas sobre tu negocio en lugar de generalidades plausibles.

Un aviso útil: si al escribir el proceso descubres que nadie lo hace igual, no sigas hacia la automatización todavía. Acabas de encontrar un problema anterior, y resolverlo probablemente rinda más que cualquier herramienta.

Semana 3: montar la versión mínima

Ahora sí, elige herramienta. El criterio no es cuál es la mejor del mercado, es cuál resuelve tu caso concreto con la menor configuración posible. Para la mayoría de primeros proyectos existe un plan gratuito o de bajo coste suficiente para validar.

Monta la versión más pequeña que pueda funcionar. Si es un asistente de atención, empieza con diez preguntas, no con cincuenta. Si es procesamiento de documentos, con un solo tipo de documento y un solo proveedor. Si es redacción, con un tipo de texto.

Y define desde el principio cuándo el sistema se detiene y pasa el control a una persona: cuando el cliente lo pide, cuando no encuentra la respuesta en tu documentación, cuando el caso entra en la lista de exclusiones. Esta regla no es un detalle de configuración, es lo que evita que un fallo se convierta en un problema con un cliente.

Presupuesto realista de esta semana: entre 30 y 100 dólares al mes en herramientas y unas ocho horas de trabajo interno.

Semana 4: probar con casos reales y medir

Prueba solo con trabajo real, nunca con ejemplos inventados. Toma treinta casos de la semana pasada, pásalos por el sistema y compara con lo que se hizo a mano.

Clasifica cada resultado en tres categorías: correcto y utilizable, correcto pero necesita retoque, e incorrecto. La tercera categoría es la que da información: para cada fallo, identifica si fue porque faltaba información en la documentación, porque la instrucción era ambigua o porque el caso simplemente no es automatizable. Las dos primeras causas se arreglan; la tercera se saca del alcance y se deja en manos humanas.

Al final de la semana compara con tu línea base. Si la tarea consumía diez horas semanales y ahora consume cuatro, tienes un resultado. Si no puedes hacer esa comparación, el problema fue no medir al principio, y merece la pena repetir el ciclo bien.

Tres ejemplos de primer proyecto bien acotado

Para que el método no quede en abstracto, así se ve aplicado en tres tipos de negocio distintos.

Comercio con venta por mensajería. Caso elegido: responder fuera de horario las diez preguntas más frecuentes sobre disponibilidad, precios, envíos y devoluciones. Línea base: cuarenta consultas nocturnas semanales, de las que se recuperaban menos de la mitad al día siguiente. Montaje: un asistente conectado a la documentación de la tienda, con derivación inmediata a una persona en cuanto la consulta implique un cambio de pedido. Resultado medible a las cuatro semanas: tasa de recuperación de consultas nocturnas y horas del equipo en la primera hora de la mañana.

Despacho de servicios profesionales. Caso elegido: convertir las notas de las reuniones con clientes en resúmenes con compromisos, responsable y fecha. Línea base: cuarenta minutos por reunión dedicados a pasar notas a limpio, y compromisos que se perdían con frecuencia. Montaje: transcripción de la grabación y un formato de resumen fijo revisado por quien asistió. Resultado: minutos por reunión y número de compromisos que llegan al sistema de seguimiento.

Taller o negocio de servicios con cita previa. Caso elegido: recoger de forma estructurada los datos de una solicitud que llega por mensaje —vehículo o equipo, síntoma, urgencia, disponibilidad— antes de que alguien llame. Línea base: dos llamadas de media para poder agendar. Resultado: llamadas por cita cerrada y tiempo hasta la confirmación.

Los tres comparten la misma forma: una tarea, un número antes, un número después y una regla clara de cuándo interviene una persona.

Los cinco errores que hacen fracasar el primer proyecto

Empezar por la herramienta. Comprar suscripciones y después buscar en qué usarlas produce gasto sin cambio de proceso.

Elegir un caso demasiado grande. “Automatizar la atención al cliente” no es un proyecto, es un área. “Responder las diez preguntas más frecuentes fuera de horario” sí lo es.

No tener dueño. Los proyectos de IA se abandonan por falta de seguimiento más que por fallos técnicos. Alguien tiene que revisar resultados cada semana durante los dos primeros meses.

Saltarse la documentación. Un sistema sin información propia responde con seguridad cosas que no son ciertas. Bastan unas pocas conversaciones así para que el equipo pierda la confianza y lo desconecte.

No medir antes. Sin línea base, la discusión sobre si funcionó se resuelve por opiniones, y las opiniones sobre tecnología se equivocan en las dos direcciones.

Qué hacer después del primer mes

Si el resultado fue bueno, la tentación es abrir tres frentes a la vez. Resístela. Amplía primero el caso que ya funciona: más preguntas, más tipos de documento, más volumen. Es donde el esfuerzo marginal es menor y el aprendizaje ya está pagado.

Cuando ese caso esté estable y medido, elige el segundo de la lista que hiciste en la semana 1. Para entonces tendrás algo más valioso que cualquier herramienta: un método propio, probado en tu negocio, para decidir qué automatizar y cómo comprobar si sirvió.

Conviene además fijar tres hábitos que hacen que lo montado no se degrade.

Revisión semanal los dos primeros meses. Leer una muestra de resultados reales, no un panel de métricas. Los fallos que importan son los que suenan bien y son incorrectos, y esos no aparecen en ningún indicador agregado.

Un dueño con nombre por cada automatización. Las herramientas cambian, los formatos de entrada cambian y los criterios del negocio cambian. Sin alguien responsable de revisarlo cada trimestre, en un año la mitad de lo que montaste habrá dejado de funcionar como esperabas, probablemente sin que nadie se entere.

Una página de reglas sobre datos. Qué información no se introduce nunca en una herramienta externa, qué hay que revisar antes de enviar algo a un cliente y quién retira los accesos cuando alguien sale del equipo. Escribirla cuesta media hora y evita casi todos los incidentes de este tipo, que rara vez ocurren por mala fe y casi siempre por desconocimiento.

Cómo saber si estás listo para el segundo caso

Antes de abrir un frente nuevo, comprueba tres cosas en el que ya funciona. Que el ahorro medido se sostiene un mes entero, no solo la primera semana de novedad. Que la persona que lo usa a diario podría explicárselo a un compañero sin tu ayuda. Y que sabes qué pasa cuando falla: quién lo detecta, en cuánto tiempo y cómo se corrige. Si esas tres respuestas son sólidas, el aprendizaje ya está pagado y ampliar es barato. Si alguna es dudosa, dedica otras dos semanas a consolidar antes de crecer: un segundo caso montado sobre un primero inestable multiplica los problemas en lugar de sumar resultados.