Guía práctica: por dónde empezar con IA en una empresa chica

Conviene bajar las expectativas a cosas que se puedan contar, porque son las que sostienen el proyecto cuando pasa el entusiasmo.

Horas que vuelven. Lo primero y más seguro es tiempo: respuestas que hoy escribe una persona, datos que se copian de un documento a una planilla, informes que se arman a mano cada semana. No es glamoroso y es lo que más rápido se nota.

Menos errores en lo repetitivo. Una máquina que transcribe cien facturas se equivoca distinto que una persona cansada a las siete de la tarde: comete errores sistemáticos, que se detectan y se corrigen de una vez, en vez de errores azarosos que aparecen para siempre.

Respuesta más rápida al cliente. En muchos negocios chicos la diferencia entre ganar y perder una venta es contestar en diez minutos en vez de al día siguiente. Esto se mide y suele ser el caso con mejor retorno.

Ver lo que ya tenías y no mirabas. Casi toda empresa acumula información que nunca se lee: cotizaciones perdidas, motivos de reclamo, estacionalidad real de la demanda. Poder preguntarle a eso en lenguaje común cambia decisiones concretas.

Lo que NO deberías esperar al principio: que reemplace a alguien, que funcione sin supervisión, o que "descubra" oportunidades que nadie definió. Eso llega después, si llega.

Las dificultades son conocidas y todas tienen solución. Ninguna es motivo para no empezar, pero ignorarlas es la forma más común de fracasar.

Tus datos están desordenados. Repartidos entre planillas con nombres distintos, el sistema de facturación, el correo y la cabeza de alguien. Es un costo real, pero ya no es un muro: hoy hay conectores estándar que le dan a una herramienta acceso ordenado a esas fuentes sin migrarlas, y armar un flujo que extraiga, normalice y cargue es trabajo conocido y acotado. Se estima y se cotiza como cualquier otra tarea.

Alguien tiene que traducir el negocio. La herramienta no sabe qué es un cliente bueno en tu rubro ni cuál es la excepción que siempre se hace. Se necesita alguien que entienda las dos lógicas, la del negocio y la de la tecnología. Ese rol existe; lo escaso es encontrarlo junto con la implementación y no cobrado aparte.

El equipo se resiste, y muchas veces tiene razón. Si la herramienta llega como una orden desde arriba y nadie explica para qué, se usa dos semanas y se abandona. La contra es simple: que el primer caso le ahorre trabajo a quien va a usarlo, no a su jefe.

El control no es opcional. Si el sistema responde a clientes o toca datos personales, necesita reglas, registro de lo que hizo y alguien que revise. En Chile la Ley 21.719 fija obligaciones concretas. Se diseña una vez, se mantiene, y sale mucho más barato que ignorarlo.

Y la más importante: si el proceso está roto, automatizarlo te va a dar un proceso roto y más rápido. Primero se arregla, después se automatiza.

Casi todos los dolores caben en dos familias: tareas repetitivas que consumen horas, y decisiones que se toman a ciegas porque los datos no están ordenados. Esta tabla sirve para reconocer el propio caso, no como catálogo cerrado.

Este es el paso que decide si el proyecto sirve, y no es misterioso. Son cuatro movimientos.

Uno. Mirar la operación, no el organigrama. Recorre el camino completo de un pedido o un cliente: cómo entra, quién lo toca, dónde se detiene, cuántas veces se copia el mismo dato de un lugar a otro, en qué punto alguien está esperando a otra persona. Hazlo con quienes hacen el trabajo, no con quienes lo supervisan. Suele tomar tres o cuatro conversaciones y muestra más que cualquier informe.

Dos. Encontrar el dolor y ponerle número. No el que más molesta: el que más horas consume o más plata pierde, y que se pueda medir hoy, antes de tocar nada. Si no se puede medir, no sirve como primer caso por interesante que parezca. Anota el número de partida en una línea; vas a compararlo después.

Tres. Escribir hipótesis, no soluciones. Una hipótesis dice qué esperas, cuánto y en qué plazo: "si el 70% de las consultas que llegan por WhatsApp son las mismas ocho preguntas, un asistente con acceso al catálogo debería bajar a la mitad el tiempo de respuesta en seis semanas". Escrita así se puede refutar, y eso es lo que la hace útil. Normalmente salen tres o cuatro y compiten entre sí.

Cuatro. Elegir la implementación más barata que la pruebe. No la más completa: la más barata que resuelva la duda. Si la hipótesis se cumple, se amplía. Si no, cambias de caso habiendo gastado poco. Esa disciplina es la diferencia entre un proyecto y una apuesta.

Una vez elegido el problema, hay tres formas de resolverlo. Se pueden combinar, y casi siempre se empieza por la primera.

Camino uno: herramienta de estantería. Contratas algo que ya existe —un asistente, un lector de documentos, un chat para tu sitio— y lo configuras. Costo: decenas de dólares al mes. Tiempo: días. Conviene cuando tu problema se parece al de miles de empresas y no depende de datos internos complejos. Su límite: no sabe nada de tu negocio, así que sirve para tareas generales y no para tus excepciones.

Camino dos: conectar lo que ya tienes. La herramienta general se enchufa a tus fuentes —facturación, planillas, correo, catálogo— para que responda con tus datos. Costo: el de un proyecto acotado de semanas. Conviene cuando el valor está justamente en tu información y no en la capacidad genérica del modelo. Es el camino que resuelve la mayoría de los casos de una empresa chica, y el que casi nadie ofrece porque no se vende solo.

Camino tres: construir algo propio. Un flujo o un sistema hecho a medida, eventualmente con un modelo corriendo en máquina propia. Conviene cuando el proceso es tu ventaja competitiva, cuando el volumen hace que pagar por uso salga caro, o cuando los datos no pueden salir de tu empresa por razones legales o de confidencialidad. Es el más caro de los tres y el único que no deberías empezar sin haber probado antes uno de los otros dos.

La regla que usamos para decidir: no se construye nada nuevo si algo que ya existe cubre el sesenta por ciento del problema.

Un primer caso razonable dura entre cuatro y ocho semanas y se parece a esto.

Semana 1 — diagnóstico y línea de base. Recorrido de la operación, elección del problema, número de partida anotado. Al final de esta semana debe existir una hipótesis escrita con su plazo y su métrica.

Semanas 2 y 3 — la versión más simple que funcione. Se conecta lo mínimo, se prueba con datos reales y con las personas que van a usarlo. Es normal que la primera versión sea peor que el proceso manual; lo importante es que se pueda corregir rápido.

Semanas 4 a 6 — uso real y ajuste. La herramienta entra al trabajo diario de un grupo chico. Se anotan los casos donde falla, que son la materia prima del ajuste. Acá se decide si sigue.

Semana final — se vuelve a medir y se decide. Se compara contra el número de partida. Tres resultados posibles y los tres son válidos: funcionó y se amplía, no funcionó y se cambia de caso, o no funcionó y se para. Haber gastado poco es lo que permite que la tercera respuesta no sea un fracaso.

Si alguien te ofrece un proyecto de seis meses sin una medición intermedia, estás comprando una apuesta.

Casi todos los proyectos que se abandonan lo hacen por las mismas razones, y ninguna es técnica.

Empezar por la herramienta y no por el problema. "Necesitamos IA" no es un objetivo. Comprar primero y buscar dónde usarlo después es la causa más frecuente de gasto sin resultado.

No medir antes. Sin número de partida no hay forma de saber si sirvió, y la discusión se resuelve por impresiones — donde siempre gana quien tenga más ganas de que funcione.

Elegir el caso más vistoso en vez del más caro. El que luce bien en una reunión rara vez es el que te está costando horas todas las semanas.

Dejarlo en manos de una sola persona entusiasta. Cuando esa persona se va de vacaciones, el proyecto se detiene. Tiene que haber al menos dos personas que sepan usarlo y un responsable de negocio, no solo de tecnología.

Automatizar un proceso roto. Vale repetirlo porque es el más caro: si el procedimiento no funciona a mano, acelerarlo solo multiplica el problema.

Esta sección es la interesada, y por eso va marcada.

Lo primero que hacemos no es instalar nada, sino el diagnóstico de más arriba: recorrer la operación, encontrar el dolor medible y escribir las hipótesis. De ahí sale si tu caso tiene solución barata, solución cara o no tiene — y las tres respuestas sirven, porque saber que algo no se resuelve con inteligencia artificial también ahorra plata.

Después trabajamos con la misma disciplina que aplicamos a nuestra propia plataforma: planes de suscripción en vez de pago por consumo, varios proveedores según lo que cada tarea necesita, modelos abiertos donde alcanzan —incluso en máquina propia cuando los datos no pueden salir— y la regla de no construir nada nuevo si algo existente cubre el sesenta por ciento del problema.

No publicamos precios acá porque el costo real depende de tu caso. Ofrecemos una conversación de una hora para averiguarlo: admin@sinapsis.in.