La pregunta casi nunca es si un modelo puede hacer la tarea. Es si alguien en la empresa sabe escribir cómo se hace hoy esa tarea.
A estas alturas casi todas las empresas han probado algo. Alguien tiene un prompt que pega en una ventana de chat dos veces al día. Otro automatizó un correo con una herramienta sin código y funcionó un mes. Muy pocas tienen un proceso que corre sin que nadie lo esté vigilando.
Esa distancia no es una anécdota. Es la forma del mercado entero.
Lee esos dos números juntos y la conclusión resulta incómoda para cualquiera que venda este trabajo. Casi todo el mundo tiene acceso a la tecnología. Casi nadie la tiene funcionando en producción. El cuello de botella no es el modelo.
Por lo que hemos visto, casi siempre es lo mismo: el proceso que se quiere automatizar nunca se puso por escrito, así que lo que parecía una tarea resulta ser una tarea más cuarenta años de criterio que nadie documentó.
¿Qué debería automatizar primero una empresa?
Empieza por una tarea que ocurra a menudo, que siga una regla que alguien pueda decir en voz alta y cuyo resultado pase por otra persona antes de que ocurra nada irreversible. Clasificar y repartir las consultas que entran, redactar primeras respuestas, extraer datos de facturas o pedidos, mantener coherentes los registros entre dos sistemas. Sirven porque la regla ya existe, el volumen hace real el ahorro y un error se ve y se corrige barato. Empezar por una decisión rara y de mucho peso es el fallo habitual: el beneficio es pequeño y la equivocación sale cara.
Cuatro preguntas para elegir el primer proceso
La mayoría de empresas elige su primera automatización por lo que más molesta a quien más se queja. Un filtro mejor lleva veinte minutos y pregunta cuatro cosas sobre la tarea candidata.
Con qué frecuencia ocurre. Por debajo de unas pocas veces por semana, el ahorro no devuelve el montaje, por muy pesada que le resulte a quien la hace.
Si alguien sabe decir la regla en voz alta. Esta es la que elimina a casi todos los candidatos, y hay que probarla preguntando de verdad. Si la respuesta llega como una secuencia de condiciones, es buen candidato. Si la respuesta es que depende y que uno le va cogiendo el punto, lo que has encontrado es oficio y no un procedimiento, y el oficio no se traslada a un prompt.
Qué pasa cuando se equivoca. No si va a equivocarse, que lo hará. Si equivocarse se nota y se puede deshacer, o es silencioso y permanente.
Si el resultado tiene lector. Las automatizaciones que producen algo que nadie mira fallan en silencio durante meses. Si el resultado aparece delante de una persona como parte de su trabajo normal, se revisa sin que haya que encargárselo a nadie.
Una tarea que pasa las cuatro merece construirse este trimestre. Una que falla la segunda merece ponerse por escrito primero, y ese ejercicio ya vale la pena aunque la automatización no llegue nunca.
Las automatizaciones se rompen en la entrada, no en el modelo
Las demos se hacen con datos limpios. La producción es la foto de una factura sacada torcida, un correo con la petición real enterrada bajo cuatro reenvíos, una hoja de cálculo donde alguien escribió una nota en la columna del total.
Ahí es donde se tuerce el presupuesto, siempre. La parte interesante, conectar el modelo, es una tarde. La parte sin lustre, decidir qué hace el sistema con una entrada para la que no fue diseñado, es casi todo el proyecto.
Hay un principio que ayuda y no es técnico. A una automatización hay que dejarle decir que no sabe. Un sistema que siempre da una respuesta acabará dando una equivocada con seguridad, y una respuesta equivocada con seguridad cuesta más que ninguna respuesta, porque alguien actúa a partir de ella.
- Dale una salida explícita para los casos que no sabe resolver, y que esos vayan a una persona en lugar de adivinarse.
- Registra qué recibió y qué decidió, para que un resultado equivocado se pueda explicar en vez de discutir.
- Mide con qué frecuencia usa esa salida. Que suba significa que el mundo ha cambiado, y eso conviene saberlo pronto.
El fallo ruidoso y el fallo callado
Las automatizaciones fallan de dos maneras y solo una recibe atención.
El fallo ruidoso es una caída. Algo da error, la cola se para, alguien lo nota en unas horas porque dejó de llegarle trabajo. Ese es el bueno. Se ve, tiene fecha y se arregla.
El fallo callado es peor. La automatización sigue funcionando y empieza a equivocarse. Las categorías se van desplazando, un proveedor cambia el formato de sus facturas, un formulario gana un campo. No se rompe nada. Los números siguen siendo verosímiles. Seis meses después alguien descubre que una categoría entera está mal archivada desde la primavera.
Protegerse de eso no tiene ninguna sofisticación. Se toma una muestra del resultado cada cierto tiempo y la mira una persona. Diez casos por semana, revisados por alguien real, detectan la desviación mucho antes que el informe trimestral. Es la línea menos vistosa de cualquier propuesta de automatización y la que más peleamos por mantener.
Lo que cuesta de verdad
La conversación sobre precio se distorsiona porque las llamadas al modelo son baratas. Lo son, y no es ahí donde se va el dinero.
¿Cuánto cuesta automatizar un proceso de empresa con IA?
Para un proceso concreto y bien definido, el montaje suele ir de 1.500 a 12.000 dólares según cuántos sistemas tenga que tocar y lo sucias que vengan las entradas, más un coste mensual que normalmente lo dominan las herramientas y no el modelo. El consumo de modelo para un volumen de oficina corriente suele quedarse en unas decenas de dólares al mes. Los costes mayores y más previsibles son la integración con los sistemas que ya existen, el tratamiento de las entradas que no encajan en el patrón y que alguien se haga cargo del proceso después de lanzarlo. Un presupuesto que solo pone precio al montaje está presupuestando la mitad del trabajo.
Ese último punto es el que conviene apretar en cualquier propuesta que recibas. Pregunta quién responde cuando dé un resultado equivocado en el cuarto mes, y qué pasa cuando el proveedor del otro lado cambie su formato. Si no hay respuesta, el precio no es el precio.
Cuándo automatizar es la respuesta equivocada
Hay tres casos que salen lo bastante a menudo como para nombrarlos, y en los tres la recomendación honesta es no hacer nada.
Cuando el proceso está mal. Automatizar un procedimiento malo produce el mismo mal resultado más rápido y con menos ocasiones de darse cuenta. Arréglalo primero en papel, y bastantes veces el arreglo elimina la necesidad entera.
Cuando no hay volumen. Una tarea que se hace dos veces al mes no justifica un sistema que habrá que mantener durante años, por muy irritantes que sean esos veinte minutos.
Cuando el sentido de la tarea es la relación. La llamada después de una entrega que salió mal, la respuesta a una queja que importa. Automatizar eso ahorra una hora y cuesta algo que no aparece en ninguna hoja de cálculo hasta que el cliente se va.
¿La automatización con IA va a sustituir a mi equipo?
En la gran mayoría de pymes no, y plantearlo así lleva a decisiones malas. Lo que se automatiza bien son las partes repetitivas y con regla de un puesto, no el puesto. Lo que ocurre en realidad es que el mismo equipo absorbe más volumen sin crecer en la misma proporción y dedica su tiempo a los casos que piden criterio. Las empresas que empiezan con la reducción de plantilla como objetivo suelen automatizar lo que no toca, porque eligen por coste salarial y no por si la tarea tiene una regla que se pueda enunciar.
Empieza por algo más pequeño de lo que parece que merece la pena
El error más habitual que vemos es de alcance. Una empresa decide automatizar la atención al cliente, que no es un proceso, es un departamento con treinta dentro.
Una sola tarea, funcionando un mes, con los números anotados antes y después, enseña más sobre lo que es posible en esa empresa concreta que cualquier documento de estrategia. Y además produce lo que necesita todo proyecto posterior: una persona dentro de la casa que ha visto esto funcionar y puede decirlo.
