daun.pw

Automatizar tareas de oficina con IA sin montar un caos

· 11 min de lectura · 2318 palabras

Qué tareas repetitivas conviene automatizar, cuáles no, y cómo hacerlo de forma que siga funcionando dentro de seis meses y sin comprometer datos.

Automatizar tareas de oficina con IA es facilísimo de empezar y facilísimo de abandonar. Casi todo el mundo monta tres flujos en una tarde, los usa dos semanas y a los seis meses nadie recuerda por qué esa carpeta se llena sola de archivos raros. Este artículo va de lo contrario: elegir bien qué automatizar, dejar fuera lo que no toca, proteger los datos que no pueden salir de tu equipo y montarlo de forma que siga funcionando cuando ya no te acuerdes de cómo lo hiciste.

Qué significa automatizar tareas de oficina con IA (y qué no)

Qué conviene automatizar y qué es mejor dejar como está
Qué conviene automatizar y qué es mejor dejar como está

Hay tres cosas distintas metidas dentro de la misma palabra, y confundirlas es el origen de la mitad de los desastres.

La primera es la automatización clásica, la de toda la vida: reglas fijas, plantillas, renombrado de archivos, copiar datos de un sitio a otro. No necesita IA. Es determinista, o sea, con la misma entrada da siempre la misma salida. Si tu tarea encaja aquí, resuélvela con una regla y no metas un modelo por medio.

La segunda es meter un modelo de lenguaje dentro de un flujo que ya existe, para el trozo concreto que ninguna regla sabe hacer: resumir un texto, clasificar un correo por intención, extraer cinco campos de un PDF mal maquetado, redactar un primer borrador. Aquí es donde la IA aporta de verdad en una oficina.

La tercera son los agentes que deciden solos qué pasos dar y ejecutan acciones con consecuencias (enviar, publicar, borrar, pagar). Es lo más vistoso y lo que más se rompe. Si estás empezando, no vayas ahí.

La regla práctica: usa IA solo en la parte que no puedes escribir como regla, y deja el resto del flujo aburrido y predecible. Cuanto más pequeña sea la porción que no es determinista, menos cosas pueden salir mal.

El criterio para decidir qué automatizar

No automatices lo que te molesta. Automatiza lo que sale a cuenta. Tres variables bastan:

Una tarea de dos minutos que haces cincuenta veces al mes vale más que una de una hora que haces una vez al trimestre. Y una tarea con coste de error alto no se automatiza aunque cumpla lo demás: se asiste, que es distinto.

Tarea Frecuencia Coste del error Veredicto
Transcribir y resumir reuniones Alta Bajo, el acta se relee Automatiza
Clasificar correo entrante por tema Muy alta Bajo si solo etiqueta Automatiza
Sacar datos de facturas a una hoja Alta Medio Automatiza con revisión
Redactar borradores repetitivos Alta Bajo si nadie lo envía solo Automatiza con revisión
Responder a un cliente enfadado Media Alto No
Decisiones de personal o nóminas Baja Muy alto No
Informe anual de dirección Muy baja Alto No compensa

La columna que decide es la tercera. Si el resultado va a salir por la puerta sin que nadie lo mire, el coste del error es siempre alto, da igual lo sencilla que parezca la tarea.

Qué NO deberías automatizar

Esta es la parte que se salta todo el mundo, y es justo la que evita el caos.

Procesos que todavía no están definidos. Si tres personas hacen la misma tarea de tres formas distintas, automatizarla congela una de las tres versiones y multiplica el lío. Primero escribes el proceso en cinco líneas, luego lo automatizas.

Cualquier cosa que nadie va a revisar. Un flujo sin revisor es un flujo que fallará en silencio. No hace falta mirar el cien por cien, pero sí una muestra periódica.

Comunicación con carga emocional o legal. Reclamaciones, despidos, avisos de impago, respuestas a quejas públicas, condiciones contractuales. Un modelo puede darte un borrador, pero el envío lo decide una persona.

Decisiones sobre personas. Filtrar candidatos, evaluar rendimiento, priorizar clientes con criterios opacos. Además del problema ético, entras en terreno regulado y tendrás que justificar el criterio ante alguien.

Números que luego se usan sin comprobar. Cálculos, cierres contables, conciliaciones. Un modelo de lenguaje escribe cifras plausibles, y plausible no es correcto. Si hay que sumar, que sume una hoja de cálculo o un script, no el modelo.

Tareas raras y de bajo volumen. Automatizar algo que ocurre dos veces al año cuesta más que hacerlo a mano esas dos veces.

Lo que ya funciona bien. Si un flujo determinista te resuelve la tarea, meterle IA solo añade variabilidad, coste y un punto más de fallo.

Datos sensibles: el aviso que casi nadie te da

Cuando envías un documento a una herramienta en la nube, ese documento sale de tu organización. Aunque el proveedor sea serio, aunque el contrato esté firmado, aunque prometa que no entrena con tus datos. Sale. Y eso cambia quién responde si algo se filtra.

Antes de conectar nada, haz una lista de categorías y ponles un semáforo:

Después, tres preguntas que conviene mirar en las condiciones de cada herramienta antes de meterle nada: si usan tus datos para entrenar, cuánto tiempo los conservan y en qué país están los servidores. Las respuestas cambian con el tiempo y entre planes, así que compruébalas tú en lugar de fiarte de lo que leíste hace un año.

Para lo rojo, la salida sensata es procesarlo en tu propio equipo. Un modelo local no manda nada a ningún sitio, y para transcribir, resumir, clasificar o extraer campos de documentos internos hay modelos pequeños que funcionan bien en un portátil normal, más despacio pero suficientes para esas tareas. Si nunca lo has probado, instalar una IA local con Ollama te lleva menos de una tarde. Y si tu equipo no tiene tarjeta gráfica dedicada tampoco es un muro: hay margen real, aunque conviene saber hasta dónde llegas ejecutando modelos sin GPU antes de prometerle nada a nadie.

Un detalle poco intuitivo para terminar: el riesgo no está solo en el documento que subes, está en el pegado casual. La fuga típica de oficina no es un flujo mal configurado, es alguien copiando el correo entero de un cliente en un chat para que se lo resuma. Escribe la norma en una línea y ponla donde se vea.

Las automatizaciones que sí aguantan seis meses

Estas son las que sobreviven. Todas tienen algo en común: entrada estable, salida revisable y ningún envío automático.

Transcripción y resumen de reuniones

Grabas, transcribes y generas un acta con acuerdos y responsables. Es de las que mejor relación dan entre esfuerzo y beneficio. El coste del error es bajo porque el acta se lee, y la entrada (un archivo de audio) casi nunca cambia de formato.

Si la fuente es una charla, un webinar o una formación publicada en internet, el primer paso es tener el archivo en local. Ahí encaja Daun: descargas el audio y a partir de ahí trabajas con tus herramientas, sin depender de que ese vídeo siga colgado la semana que viene.

Triaje y etiquetado de correo o tickets

El modelo no responde: clasifica. Etiqueta por tema, urgencia o departamento y mueve a una carpeta. Cero acciones irreversibles, ahorro diario, y si se equivoca lo peor que pasa es que un correo acabe en la carpeta de al lado.

Extracción de datos de documentos a tabla

Facturas, albaranes, formularios en PDF. El modelo saca los campos, un script comprueba que el formato cuadra (fechas válidas, importes numéricos, identificador presente) y lo que no pasa la validación va a una bandeja de revisión manual. Esa validación por reglas es lo que hace fiable el conjunto, no el modelo.

Primeros borradores de textos repetitivos

Descripciones, respuestas frecuentes, fichas de producto, resúmenes internos. El borrador lo escribe la máquina, la versión final la firma una persona. Si tu trabajo es de contenidos o campañas, elegir la herramienta según la fase cambia bastante el resultado, y lo tienes desglosado en la guía de software de IA para marketing por fases.

Preparación y ordenación de material

Renombrar según una convención, mover a carpetas por fecha o cliente, generar un índice. Aquí ni siquiera hace falta IA la mayoría de las veces, y precisamente por eso es la automatización que menos se rompe.

Local o en la nube: cómo decidir

No es una cuestión ideológica, es una tabla.

Criterio Modelo en la nube Modelo en local
Datos sensibles Salen de la organización No salen del equipo
Calidad en tareas complejas Superior hoy Suficiente en tareas acotadas
Coste Por uso, crece con el volumen Hardware que ya tienes, más luz
Funciona sin internet No
Estabilidad del comportamiento El proveedor actualiza cuando quiere Tú decides cuándo cambias de versión
Esfuerzo de puesta en marcha Bajo Medio

La penúltima fila es la que más se subestima. Un flujo que depende de un modelo en la nube puede cambiar de comportamiento sin que tú toques nada, porque el proveedor ha actualizado el modelo por detrás. En local, la versión se queda donde la dejaste hasta que decides moverla. Para automatizaciones que deben ser estables durante meses, eso vale mucho.

Lo habitual y sensato es mezclar: nube para lo público y lo complejo, local para lo interno y lo repetitivo.

Cómo montar la primera sin liarla

Siete pasos, en este orden. Saltarse el orden es lo que genera el caos del título.

  1. Escribe el proceso a mano en cinco líneas. Si no puedes, no está listo para automatizar.
  2. Elige una sola tarea. La más frecuente y con menor coste de error. Una, no cinco.
  3. Define la entrada y la salida exactas. Qué carpeta, qué formato, qué nombre de archivo, dónde aparece el resultado.
  4. Monta la versión tonta primero. Sin IA, o con la IA haciendo solo el trozo imprescindible. Que funcione feo antes que elegante.
  5. Pon una validación por reglas después del modelo. Campos obligatorios, longitudes, formatos. Lo que no valide, a revisión manual.
  6. Deja registro de cada ejecución. Una línea de texto plano por pasada te ahorrará una tarde de investigación dentro de tres meses.
  7. Ponle dueño y fecha de revisión. Un nombre y un día en el calendario. Sin esto, el flujo muere solo.

Así de aburrido debería ser el núcleo del flujo:

# Entrada fija, salida fija, nada que adivinar
for f in entrada/*.txt; do
  base=$(basename "$f" .txt)
  cat "$f" | ollama run llama3.1 "Resume en 10 puntos el texto siguiente" > "salida/$base.md"
  # aqui va tu validacion por reglas antes de dar la pasada por buena
  echo "$(date +%F) | resumen | $base | ok" >> registro.log
done

Y el registro, en texto plano, sin bases de datos ni paneles:

2026-09-09 | resumen-reuniones | 14 archivos | 0 errores | revisa: Marta
2026-09-10 | resumen-reuniones | 11 archivos | 2 a revision | revisa: Marta

Con dos líneas así ya sabes, de un vistazo, si el flujo se ejecutó, cuánto procesó y quién tenía que mirarlo.

Por qué se rompen a los seis meses (y cómo evitarlo)

Las automatizaciones no fallan de golpe. Se degradan, que es peor, porque nadie se entera.

Cambia la entrada. El proveedor rediseña su factura, alguien empieza a mandar los archivos en otro formato, la plantilla de correo se actualiza. El flujo sigue ejecutándose y produciendo basura convincente.

Cambia el modelo. Actualización del proveedor y tus instrucciones, que estaban afinadas al milímetro, dejan de devolver el mismo formato de salida.

Cambia la persona. Quien lo montó pasa a otro puesto y nadie más sabe dónde está el script ni qué clave usa.

Caducan las credenciales. Una clave de API expira un viernes por la tarde y el flujo lleva tres semanas parado cuando alguien se da cuenta.

Cuatro hábitos baratos previenen casi todo: revisar una muestra pequeña cada mes (diez casos al azar bastan), guardar el flujo y sus instrucciones junto al resto de la documentación del equipo, hacer que avise cuando no produce nada (el silencio no es éxito) y anotar en el calendario la fecha en la que toca revisarlo.

Y una regla final que resume el artículo entero: si no sabrías detectar que el flujo está fallando, todavía no está listo para funcionar solo.

Preguntas frecuentes

¿Merece la pena automatizar si somos un equipo de tres personas?

Sí, pero menos cosas. En equipos pequeños compensan las tareas de alta frecuencia y bajo riesgo: transcripciones, etiquetado de correo, renombrado y ordenación de archivos, borradores repetitivos. Lo que no compensa es montar un sistema con muchas piezas conectadas entre sí, porque el mantenimiento recae siempre sobre la misma persona, que ya va justa.

¿Puedo usar herramientas en la nube con datos de clientes?

Depende del contrato y del tipo de dato. Con un proveedor con el que tengas firmado un contrato de tratamiento de datos, y para información comercial normal, es habitual. Para datos personales sensibles, salud, nóminas o documentación bajo confidencialidad, la respuesta prudente es procesarlo en local. Y decidirlo antes de montar el flujo, no cuando ya lleva tres meses funcionando.

¿Necesito una tarjeta gráfica potente para hacerlo en local?

Para transcribir, clasificar, extraer campos y resumir textos de longitud normal, no. Con un equipo moderno y memoria RAM suficiente se llega bien, aunque más lento, y en el artículo sobre qué se puede hacer sin tarjeta gráfica están los límites concretos. Una gráfica NVIDIA RTX con 8 GB de VRAM abre modelos más grandes y acelera bastante, y a partir de 16 o 24 GB entras en otra liga, pero empezar sin nada de eso es perfectamente viable.

¿Por dónde empiezo si nunca he automatizado nada?

Por la tarea que hagas más veces y que menos daño cause si sale mal. Hazla a mano una vez documentando cada paso, luego automatiza solo ese camino, ponle un registro y úsala un mes entero antes de tocar la segunda. Una automatización que aguanta seis meses vale más que cinco montadas en una tarde.