Una tarea repetitiva no es automáticamente una buena candidata para automatizar. Repetirla muchas veces puede indicar una oportunidad, pero también puede esconder entradas inconsistentes, decisiones de criterio, permisos delicados o excepciones que hacen que el coste de mantener la herramienta supere al tiempo ahorrado.
La pregunta útil no es «¿cómo elimino este trabajo?», sino: ¿puedo convertir este proceso entendido en una herramienta con límites, controles y una persona responsable? Si la respuesta todavía no está clara, el primer paso no es programar. Es observar, medir y describir.
Medir antes de construir
Durante unos días o semanas, registrá cómo se realiza la tarea. No hace falta montar un sistema complejo: una tabla con ejemplos reales y anonimizados suele revelar más que una estimación intuitiva.
Anotá, como mínimo:
- Frecuencia: cuántas veces ocurre y con qué regularidad.
- Volumen: cuántos documentos, líneas, fichas, incidencias o registros se procesan cada vez.
- Tiempo: cuánto dura la ejecución y cuánto cuesta preparar, revisar y corregir.
- Variabilidad: qué cambia entre casos: formato, campos, reglas, proveedores o contexto.
- Errores: qué errores aparecen, cómo se detectan y qué impacto tienen.
- Riesgo: qué puede ocurrir si la salida es incorrecta o si se procesa un dato que no debía usarse.
- Coste de oportunidad: qué trabajo de mayor valor se desplaza mientras alguien repite esta operación.
Una aproximación sencilla al coste actual puede ser:
coste periódico = frecuencia × tiempo medio × coste horario + coste de revisión y corrección
No es una promesa de ahorro. Es una forma de hacer explícitas las variables. A ese coste hay que compararle el diseño, la implementación, las pruebas, la integración, el soporte, los cambios de formato, los permisos y la retirada futura de la herramienta.
La frecuencia importa, pero no decide sola. Una tarea semanal con errores caros puede merecer un piloto antes que una tarea diaria trivial. Y una tarea muy frecuente puede no compensar si cambia cada semana o si exige una aprobación experta en todos los casos.
Interlink contextual: automatizar no sustituye entender el dominio
En iluminación, por ejemplo, se puede automatizar la comprobación de campos de fichas técnicas, la generación de un inventario o la detección de cambios entre revisiones. Pero el sistema necesita conocer qué significa cada campo y qué consecuencias tiene una discrepancia. Para separar control, datos e infraestructura, resulta útil convertir documentación en datos utilizables.
El enlace no convierte el ejemplo en una receta universal. Solo recuerda una regla general: una automatización fiable depende del proceso y del dominio que hay detrás.
Describir el proceso como un contrato
Antes de elegir un script, una integración o una herramienta con IA, escribí el contrato mínimo del proceso. Si no se puede explicar qué entra, qué sale y qué casos quedan fuera, todavía no hay una especificación suficiente.
| Parte | Pregunta que debe quedar respondida |
|---|---|
| Entrada | ¿Qué documentos, datos o eventos acepta? ¿En qué formatos y versiones? |
| Salida | ¿Qué produce exactamente y con qué estado: borrador, validado o publicado? |
| Reglas | ¿Qué transformaciones, cálculos, filtros y límites aplica? |
| Excepciones | ¿Qué casos no puede resolver y cómo los deriva? |
| Permisos | ¿Quién puede leer, ejecutar, aprobar, modificar o publicar? |
| Observabilidad | ¿Qué métricas, registros y alertas permiten saber qué ocurrió? |
| Recuperación | ¿Cómo se repite, deshace o corrige una ejecución fallida? |
| Mantenimiento | ¿Quién actualiza reglas, dependencias, formatos y documentación? |
En un flujo de documentos, la entrada puede ser una ficha técnica o un presupuesto recibido en una carpeta concreta. La salida podría ser un registro estructurado en estado «pendiente de revisión», no un dato publicado automáticamente. En un control de incidencias, una regla puede clasificar por prioridad, pero dejar a una persona la confirmación cuando faltan evidencias.
Definí también la invariante que no debe romperse. Por ejemplo: «ningún precio pasa a un presupuesto aprobado sin conservar documento, versión y revisión humana». Una invariante concreta es más comprobable que «la herramienta debe ser inteligente».
Elegir el nivel mínimo de automatización
No todo proceso necesita una plataforma. Elegí el nivel más pequeño que resuelva el problema sin ocultar decisiones importantes.
- Regla manual asistida: una plantilla, consulta o validación que reduce copia y pega, pero deja el control en la persona.
- Script acotado: transforma entradas previsibles y genera una salida revisable.
- Integración: conecta sistemas cuando el contrato de datos, los permisos y los errores están claros.
- Herramienta interna: añade interfaz, historial, roles y soporte cuando ya existe un proceso estable.
- IA supervisada: propone clasificaciones, extracción o borradores cuando hay ambigüedad, contexto y una revisión explícita.
Un workflow de GitHub Actions, por ejemplo, permite definir automatizaciones como workflows que se ejecutan ante eventos o bajo condiciones configuradas. Esa documentación demuestra una capacidad concreta de la herramienta, no un resultado universal de productividad ni que cualquier proceso deba trasladarse allí: GitHub Actions, documentación oficial.
Reglas y IA no son lo mismo
Una automatización basada en reglas aplica condiciones explícitas. Si una ficha contiene un campo obligatorio vacío, puede marcarla como incompleta. Si una incidencia tiene una etiqueta determinada, puede enviarla a una cola. Su comportamiento es más fácil de inspeccionar mientras las entradas y las reglas estén bien definidas.
Una automatización con IA puede interpretar texto, sugerir una categoría o extraer información con contexto. Eso puede ser útil cuando las entradas no tienen una estructura fija, pero introduce incertidumbre adicional: la salida puede variar, puede omitir una condición o puede parecer convincente sin estar respaldada por la fuente.
Por eso una IA no debe presentarse como una autoridad automática. Documentá:
- qué modelos, versiones y configuraciones intervienen;
- qué entradas están permitidas y cuáles contienen información sensible;
- qué límites, incertidumbres y casos fuera de alcance se conocen;
- qué validación contextual debe hacer una persona;
- qué decisiones están prohibidas sin aprobación;
- cómo se registran errores, revisiones, cambios y incidentes;
- cómo se retira o sustituye el sistema.
El NIST AI Risk Management Framework, especialmente sus funciones Govern, Map, Measure y Manage, ofrece un marco de referencia para gestionar riesgos durante el ciclo de vida de un sistema de IA. Es evidencia de un enfoque de gestión de riesgos, no una garantía de que una solución concreta sea segura, exacta o rentable.
Diseñar el primer prototipo para poder fallar
El primer experimento debería ser pequeño, reversible y medible. Un alcance razonable podría ser procesar un conjunto limitado de documentos, generar un borrador y no publicar ni modificar el sistema de origen.
- Elegí una sola tarea y un conjunto representativo de casos normales y excepcionales.
- Conservá las entradas originales y asignales una versión o identificador.
- Definí una salida revisable: documento, ficha, presupuesto, inventario o control de incidencia.
- Escribí las reglas y los criterios de aceptación antes de mirar el resultado.
- Separá casos procesados, rechazados, incompletos y enviados a revisión.
- Probá permisos con una cuenta de mínimo privilegio y sin datos privados.
- Compará una muestra con un resultado preparado por una persona conocedora del proceso.
- Decidí de antemano qué condición permite continuar y cuál obliga a parar.
En un prototipo de fichas de luminarias, la herramienta podría extraer código, potencia y unidad desde documentos de prueba. No debería inventar el valor de un campo ausente ni convertir automáticamente una sugerencia en una especificación. En un inventario de software, podría detectar cambios de versión y dejar la aprobación de la actualización a quien mantiene el sistema.
Observabilidad, alternativa manual y recuperación
Una herramienta mantenible no solo produce salidas correctas en el caso feliz. También permite saber qué ocurrió cuando no pudo resolver un caso.
Registrá, respetando las políticas de privacidad y retención:
- identificador de ejecución y fecha;
- versión de reglas, modelo o código utilizado;
- entrada y salida mediante referencias auditables, sin copiar secretos;
- duración, estado y causa de fallo;
- cantidad de casos aceptados, rechazados y derivados;
- revisión realizada y responsable de la aprobación;
- reintentos, correcciones y versión finalmente publicada.
La alternativa manual debe ser una ruta diseñada, no un «ya lo arreglaremos». Puede consistir en devolver el caso a una bandeja manual, conservar la salida anterior, detener una publicación o restaurar el último estado válido. Si repetir una ejecución puede duplicar presupuestos, crear incidencias duplicadas o enviar dos veces una notificación, necesitás idempotencia o una comprobación previa.
La documentación del NIST Secure Software Development Framework (SP 800-218) relaciona prácticas de desarrollo seguro con documentación, pruebas, respuesta y triage de problemas, en particular dentro de los grupos PW y RV. Aplicado editorialmente a una automatización, respalda la recomendación de probar, registrar fallos, verificar correcciones y mantener responsables; no aporta una cifra de ahorro para tu caso.
Medir el resultado sin inventar certezas
Después del piloto, medí antes y después sobre tareas comparables. No alcanza con contar ejecuciones automáticas.
| Dimensión | Qué observar |
|---|---|
| Tiempo | tiempo total, incluida preparación, revisión y corrección |
| Calidad | errores detectados, omisiones, falsos positivos y cambios posteriores |
| Cobertura | proporción de casos que resuelve sin derivar, con el alcance definido |
| Mantenimiento | cambios de reglas, formatos, dependencias y soporte |
| Riesgo | incidentes, permisos indebidos, pérdida de trazabilidad o publicaciones incorrectas |
| Experiencia | carga cognitiva de quien revisa y claridad de la alternativa manual |
Compará también el coste de mantener la herramienta con el coste de continuar manualmente. Un piloto puede demostrar que una regla funciona para un conjunto concreto y, al mismo tiempo, demostrar que ampliar el alcance sería imprudente.
No prometas productividad inmediata, porcentajes universales ni eliminación de la revisión humana. El resultado depende del volumen, la calidad de las entradas, la estabilidad del proceso, la capacidad de mantenimiento y el criterio de aceptación.
Cuándo no automatizar
Pará o mantené la tarea manual cuando se cumpla alguna de estas condiciones:
- el proceso cambia tanto que no existe una regla o criterio estable;
- el volumen es bajo y el coste de construir la herramienta no se recupera;
- un error puede causar un daño desproporcionado y no hay controles suficientes;
- las entradas no tienen permisos claros o contienen datos que no se pueden procesar;
- nadie puede revisar, mantener o retirar la automatización;
- no existe una forma razonable de detectar fallos y recuperar el estado anterior;
- la decisión exige contexto profesional que no se puede representar en el prototipo;
- automatizar solo desplaza el trabajo a una revisión más difícil y menos transparente.
«No automatizar todavía» no es fracasar. Puede ser la decisión correcta mientras se estabiliza el proceso, se aclaran responsabilidades o se obtiene mejor evidencia.
Lista de comprobación para decidir
Antes de ampliar una automatización, comprobá que:
- la tarea, su alcance y sus exclusiones están escritos;
- conocés frecuencia, volumen, variabilidad, errores, riesgo y coste de oportunidad;
- las entradas, salidas, reglas y estados son comprensibles;
- las excepciones tienen una ruta manual y un responsable;
- los permisos son mínimos y verificables;
- existen métricas, registros y alertas suficientes;
- el prototipo fue probado con casos normales y difíciles;
- la salida se revisa antes de una acción irreversible;
- hay una alternativa manual, recuperación y un plan de mantenimiento;
- el resultado medido justifica continuar sin ocultar sus límites.
Automatizar merece la pena cuando convierte un proceso estable y entendido en una herramienta más consistente, observable y recuperable. La primera línea de código llega después: primero hay que decidir qué significa hacerlo bien, qué no se va a automatizar y quién responderá cuando la herramienta no sepa qué hacer.
Fuentes consultadas: evidencia y recomendaciones
Las siguientes fuentes documentan capacidades o marcos de trabajo concretos. Las conclusiones sobre alcance, ejemplos, métricas y decisión editorial son recomendaciones de este artículo, no resultados universales derivados de esas fuentes.
- NIST, Secure Software Development Framework (SSDF), SP 800-218, versión final. Prácticas de desarrollo seguro relacionadas con documentación, pruebas, tratamiento de problemas, triage y verificación de correcciones; grupos PW y RV: csrc.nist.gov/pubs/sp/800/218/final.
- NIST, AI Risk Management Framework (AI RMF 1.0). Marco voluntario para gobernar, mapear, medir y gestionar riesgos de sistemas de IA durante su ciclo de vida: nist.gov/itl/ai-risk-management-framework.
- GitHub, GitHub Actions documentation. Documentación de workflows, eventos, jobs y ejecuciones para automatización dentro de GitHub; no es evidencia de un ahorro o resultado universal: docs.github.com/en/actions.
- GitHub Docs, Reviewing proposed changes in a pull request. Documentación de revisión colaborativa de cambios, comentarios y aprobación en pull requests, como referencia para mantener revisión humana y trazabilidad cuando corresponda: docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests.
Las recomendaciones prácticas del texto —medir antes de construir, empezar con un prototipo reversible, conservar una alternativa manual, registrar fallos y asignar un responsable— son criterios editoriales de diseño mantenible. Deben ajustarse al proceso, al riesgo y a las obligaciones del equipo que vaya a implementarlas.
Lecturas relacionadas
También te puede interesar
Para explorar