Durante años he tenido la sensación de que me faltaba tiempo para desarrollar muchas de las ideas que tenía.
Podía detectar una oportunidad, imaginar un producto, encontrar una mejora en un proceso o plantear una posible solución técnica. El problema venía después.
Convertir esa intuición en algo suficientemente concreto para poder valorarlo exigía tiempo, análisis y recursos.
Muchas veces también necesitaba implicar demasiado pronto a un desarrollador. Había que explicarle la idea, revisar el contexto, investigar posibles caminos y dedicar unas primeras horas solo para decidir si tenía sentido continuar.
La inteligencia artificial ha reducido parte de esa distancia entre pensar y hacer.
Ahora puedo investigar una oportunidad, auditar una situación, ordenar requisitos, documentar una propuesta y preparar una primera aproximación antes de implicar al resto del equipo.
No significa que cualquier idea pase a ser buena ni que la IA sustituya el trabajo técnico. Significa que puedo llegar mejor preparado al momento de decidir.
Mi interés está precisamente ahí: entender cómo puede una empresa aumentar su capacidad de ejecución sin perder criterio por el camino.
Por eso, cuando me planteo qué procesos automatizar con IA, no empiezo por la tecnología.
La primera pregunta no es qué puede hacer la IA.
La primera pregunta es qué merece la pena automatizar.
Contenidos
El error habitual: automatizar lo más vistoso
Cuando una empresa empieza a explorar la automatización con IA, las ideas aparecen rápido.
Un asistente para atender clientes. Un sistema que genere contenidos. Un agente comercial. Informes automáticos. Respuestas preparadas. Herramientas que analizan documentos o ejecutan tareas.
El problema no suele ser la falta de posibilidades.
Es la falta de criterio para ordenarlas.
Lo más visible tiende a ganar. Una demostración en la que una IA mantiene una conversación resulta más llamativa que un proceso que clasifica información, prepara documentación o detecta un problema antes de que una persona tenga que buscarlo.
Pero lo más llamativo no siempre es lo más útil.
El primer proceso que conviene automatizar suele ser bastante menos espectacular. Normalmente es una tarea que se repite, interrumpe el trabajo, obliga a recopilar información o consume horas antes de llegar a una decisión.
Automatizar con IA no consiste en buscar la solución más sofisticada.
Consiste en encontrar un punto concreto donde la tecnología pueda reducir trabajo, acelerar una parte del proceso o mejorar su consistencia sin introducir un riesgo difícil de controlar.
Automatizar con IA no siempre significa usar IA durante la ejecución
Una de las confusiones más habituales es pensar que una automatización con IA debe llamar constantemente a un modelo de lenguaje.
No siempre es así.
Hay procesos en los que la IA interpreta información, clasifica, resume o propone una respuesta durante cada ejecución.
En otros, la IA sirve para analizar el problema, diseñar el flujo, escribir parte del código, resolver integraciones, documentar y preparar pruebas. Después, la automatización funciona con reglas tradicionales.
Las dos opciones pueden ser válidas.
La decisión depende del problema.
Cuando el proceso necesita interpretar lenguaje, relacionar contenidos o trabajar con información poco estructurada, un modelo puede aportar una capacidad que las reglas convencionales no tienen.
Cuando el resultado depende de fechas, estados, importes o condiciones exactas, las reglas deterministas suelen ser más fiables, económicas y fáciles de auditar.
La pregunta no es si una empresa debe utilizar IA o automatización tradicional.
La pregunta es qué papel debe tener cada una.
Qué procesos automatizar con IA: cuatro preguntas para decidir
Para priorizar qué automatizar, utilizo cuatro preguntas:
¿Con qué frecuencia se repite?
¿Cuánta fricción genera?
¿Qué riesgo de error humano tiene?
¿Cuánto cuesta revisar el resultado?
No es una fórmula matemática cerrada.
Es una forma de comparar procesos con el mismo criterio y evitar que la decisión dependa de una demostración o de la herramienta del momento.
¿Con qué frecuencia se repite?
La frecuencia multiplica cualquier mejora.
Una tarea de treinta minutos que ocurre una vez al año probablemente no sea prioritaria. Una tarea de pocos minutos que interrumpe a varias personas cada día puede acumular un coste mucho mayor.
Pensemos en una empresa que recibe solicitudes desde formularios, correos y otros canales.
Alguien debe leerlas, entender qué necesita cada contacto, comprobar si falta información y asignarlas a la persona adecuada.
Cada acción es sencilla.
El problema es que se repite constantemente.
La automatización podría preparar una clasificación, resumir la solicitud y señalar los datos incompletos. La persona mantendría la decisión final, pero dejaría de empezar desde cero.
La pregunta útil no es solo cuánto tarda una tarea.
También hay que valorar cuántas veces sucede, a cuántas personas interrumpe y cuánto esfuerzo acumula.
¿Cuánta fricción genera?
No todas las tareas costosas ocupan muchas horas seguidas.
Algunas desgastan porque obligan a cambiar continuamente de contexto.
Abrir varias plataformas. Buscar un documento. Recuperar una conversación. Copiar datos entre sistemas. Convertir notas en tareas. Preparar siempre la misma información antes de una reunión.
La fricción está en esos pasos que dificultan avanzar.
Un ejemplo habitual en una agencia es la preparación de informes. Hay que acceder a distintas fuentes, recopilar datos, compararlos y detectar cambios que merecen atención.
No automatizaría la interpretación final.
Un cambio en los resultados puede tener explicaciones muy distintas según el contexto del cliente.
Sí automatizaría la preparación de la información. La persona seguiría aportando el criterio, pero podría dedicarlo a analizar y decidir, no a buscar y copiar.
¿Qué riesgo de error humano tiene?
Cuando una tarea exige revisar muchos registros, seguir siempre la misma secuencia o copiar información repetidamente, es normal que aparezcan errores.
No es necesariamente un problema de capacidad.
El propio diseño del trabajo favorece las omisiones, las incoherencias y la pérdida de atención.
La automatización puede ayudar a localizar campos incompletos, detectar contradicciones, aplicar reglas o señalar casos que no siguen el patrón habitual.
Pero hay una segunda pregunta que debe hacerse siempre: ¿qué ocurre si el sistema se equivoca?
Si el error puede detectarse durante una revisión y corregirse antes de que tenga consecuencias, el proceso puede ser un buen candidato.
Si puede afectar directamente a un cliente, provocar una decisión económica o generar un problema difícil de revertir, hay que añadir más controles o reducir el alcance.
El objetivo no es trasladar el error de una persona a una máquina.
Es diseñar un proceso en el que los errores sean menos frecuentes, más visibles y más fáciles de corregir.
¿Cuánto cuesta revisar el resultado?
Esta es una de las preguntas más importantes.
Una automatización puede producir algo aparentemente útil y, aun así, no ahorrar tiempo.
Sucede cuando comprobar el resultado cuesta casi tanto como hacerlo desde cero.
Una IA puede redactar una propuesta completa. Pero si una persona debe revisar todos los datos, reconstruir el enfoque y comprobar cada afirmación, quizá la supuesta automatización ha añadido trabajo.
En cambio, puede ser útil que prepare una estructura, recupere antecedentes y marque qué apartados requieren una decisión.
En ese caso, revisar es más barato que producir.
Ese es un buen criterio.
La IA no necesita entregar un resultado perfecto. Necesita ofrecer una base que reduzca claramente el esfuerzo posterior.
Dos automatizaciones y dos papeles distintos para la IA
En Emfasi hemos aplicado este criterio de formas diferentes.
Interpretar contenidos para preparar una página en WordPress
Cuando se aprueban los contenidos de una página, todavía queda un trabajo poco visible.
Hay que dividir el documento en secciones, decidir qué componente de la web corresponde a cada una, introducir los textos en sus campos y comprobar que el resultado respeta el contenido aprobado.
Es un trabajo mecánico, pero requiere conocer la estructura técnica de cada proyecto de diseño y desarrollo web.
Para reducirlo, desarrollamos una skill que analiza el documento, consulta los bloques disponibles en ese WordPress y propone cómo encajar cada sección. Una vez validada la estructura, crea la página como borrador mediante la API.
No redacta ni modifica el contenido. Tampoco inventa componentes que no existen. Si el diseño requiere un bloque que la web todavía no tiene, se detiene y lo señala como una tarea pendiente.
Una persona aprueba la estructura propuesta y revisa el borrador antes de publicar.
En este caso, el modelo de IA forma parte del proceso porque debe resolver algo difícil de abordar solo con reglas: leer un documento y entender qué función cumple cada parte.
El código se ocupa de lo que debe ser exacto. La IA, de lo que necesita interpretación.
Un radar diario que no necesita un modelo de lenguaje
En otra automatización queríamos detectar antes determinados problemas de nuestro servicio de soporte y mantenimiento web.
La información estaba repartida entre distintas fuentes. Revisarla manualmente cada día era posible, pero demasiado tedioso para hacerse siempre con la misma disciplina.
Creamos un radar que cruza los datos, aplica reglas y muestra únicamente las situaciones que necesitan atención.
Cada alerta enlaza con el registro que la ha generado. Así, una persona puede comprobarla y actuar sin tener que volver a buscar la información.
Aquí no utilizamos un modelo de lenguaje durante la ejecución.
No era necesario.
Las condiciones dependen de fechas, saldos, estados y reglas claras. Introducir un LLM habría añadido variabilidad a un proceso que necesita ser predecible.
La IA tuvo otro papel: nos ayudó a convertir una preocupación poco definida en reglas concretas, desarrollar las integraciones y documentar los casos que podían fallar.
La automatización final funciona con lógica tradicional.
Este caso demuestra que aplicar IA no consiste en introducirla en todas partes. A veces, su mayor aportación es reducir el esfuerzo necesario para analizar, construir y documentar una automatización que después funciona mejor sin ella.
Qué procesos no automatizar todavía
Hay tres señales que me hacen frenar.
El proceso cambia según quién lo explica
Si cada persona describe unos pasos distintos, todavía no existe un proceso estable.
Automatizarlo puede fijar una forma de trabajar que nadie ha validado.
Antes conviene entender el flujo, identificar las excepciones y acordar qué resultado se considera correcto.
La IA no ordena automáticamente un proceso confuso.
Puede acelerar su confusión.
La información de entrada no es fiable
Toda automatización depende de la información que recibe.
Si los datos están incompletos, los documentos se contradicen o una parte esencial del conocimiento solo está en la cabeza de alguien, el resultado será difícil de controlar.
No hace falta tener una infraestructura perfecta.
Sí hace falta saber qué fuentes pueden utilizarse con confianza.
Nadie puede comprobar el resultado
Si una empresa no puede definir quién revisa, qué debe comprobar y qué ocurre cuando aparece un error, el proceso no está listo.
La supervisión humana no debería añadirse al final.
Debe formar parte del diseño.
Quién valida. Qué valida. En qué situaciones. Con qué límites.
Si estas preguntas no tienen respuesta, la automatización puede generar más incertidumbre que capacidad.
Preguntas frecuentes sobre automatización con IA
¿Qué proceso conviene automatizar primero con IA?
Yo empezaría por una tarea frecuente, bien delimitada y fácil de comprobar. No tiene que ser el proceso que más horas consume ni el más visible, sino uno que genere fricción de forma recurrente y cuyo resultado pueda revisarse sin rehacer todo el trabajo.
También valoraría las consecuencias de un posible error. Para una primera automatización, es preferible escoger un proceso en el que sea posible detectar y corregir un fallo antes de que afecte a un cliente o provoque una decisión difícil de revertir.
¿Una automatización con IA siempre necesita utilizar un LLM?
No. Hay automatizaciones que necesitan interpretar documentos, clasificar información o trabajar con lenguaje natural. En esos casos, un modelo de lenguaje puede formar parte de la ejecución.
Pero muchos procesos dependen de fechas, estados, cálculos o reglas exactas. Para ellos, una integración tradicional suele ser más fiable y fácil de controlar.
La IA puede aportar valor antes: ayudando a entender el problema, definir las reglas, desarrollar la solución, probarla y documentarla. Lo importante no es introducir un LLM en cada proceso, sino asignar a cada tecnología la parte del trabajo que resuelve mejor.
¿Es mejor automatizar un proceso completo o solo una parte?
Normalmente prefiero empezar por una parte concreta.
Puede ser la recopilación de información, una primera clasificación, la preparación de un borrador, la detección de anomalías o la documentación previa a una decisión.
Intentar automatizar todo desde el principio suele aumentar las excepciones, el riesgo y el coste de revisión. Acotar el proceso permite comprobar antes si la solución aporta valor y decidir después si merece la pena ampliarla.
Una automatización útil no necesita eliminar por completo la intervención humana. Puede preparar mejor el trabajo para que una persona decida, revise o ejecute la parte que exige experiencia.
¿Cuándo no compensa automatizar un proceso?
Yo frenaría si el proceso cambia según quién lo explica, si la información de entrada no es fiable o si nadie puede comprobar con claridad que el resultado es correcto.
También evitaría automatizar una tarea cuando revisar la salida cuesta prácticamente lo mismo que hacerla desde cero.
Antes de desarrollar nada, debería ser posible definir qué entra en el proceso, qué resultado esperamos, qué excepciones existen y quién interviene cuando algo no encaja. Si esas preguntas todavía no tienen respuesta, probablemente el problema necesite ordenarse antes de automatizarse.
La experiencia gana valor cuando ejecutar resulta más fácil
Hace más de diez años que no desarrollo de forma habitual ni escribo el código de los proyectos.
Mi papel como CTO está en otro punto.
Ayudo al equipo a entender problemas, estructurar soluciones, anticipar riesgos y planificar el trabajo de la forma más clara posible.
Mi experiencia anterior como desarrollador me permite hacer mejores preguntas. La IA me permite llevar esas preguntas más lejos antes de consumir horas del equipo.
Puedo analizar una idea, preparar una tarea, detectar lo que falta y decidir si tiene sentido implementarla, descartarla o delegarla.
Eso no reduce el valor de la experiencia.
Lo aumenta.
Cuando crear una primera aproximación resulta más fácil, la diferencia ya no está únicamente en quién puede producir más.
Está en quién sabe qué merece la pena construir, qué debe automatizarse, dónde hace falta interpretación y dónde una regla sencilla es mejor que un modelo avanzado.
Por eso no empezaría preguntando qué puede hacer la IA en una empresa.
Empezaría por una tarea frecuente, molesta, fácil de comprobar y con un error asumible.
Después decidiría qué parte debe resolver la IA, qué parte debe funcionar con reglas y qué decisiones deben seguir siendo humanas.
La automatización con IA no debería empezar con una gran promesa. Debería empezar con una mejora real.
Cuando esa mejora funciona, la IA deja de ser una demostración y se convierte en una forma distinta de trabajar.
