Inteligencia Artificial Edición diaria
INTELIGENCIA ARTIFICIAL GOBIERNO DE IA
Una automatización no termina cuando arranca: debe demostrar que entregó
Programar un flujo es sólo fijar el disparador. La fiabilidad aparece cuando cada ejecución deja evidencia, comprueba sus salidas, evita duplicados y sabe recuperarse sin esperar a que alguien eche de menos el resultado.
Una automatización suele darse por terminada demasiado pronto. El calendario dispara una tarea, aparece un indicador verde y el equipo asume que el trabajo está hecho. Pero entre arrancar y entregar hay una cadena completa: leer entradas, descartar ruido, producir contenido, generar archivos, publicar, enviar y comprobar que cada destino recibió exactamente una versión. Si el sistema registra sólo el comienzo, una ejecución incompleta puede parecer correcta. La diferencia entre una demo y una operación diaria está en demostrar el resultado, no en celebrar el disparador.
El primer control es un registro de ejecución independiente del texto generado. Cada edición necesita una clave estable, por ejemplo la fecha y el tipo de publicación, además de hora prevista, hora real, estado por etapa, número de entradas examinadas, piezas seleccionadas y huellas de los artefactos. Esa clave impide que una repetición accidental cree dos correos o dos artículos. Si el flujo vuelve a ejecutarse, debe actualizar la misma edición o detenerse con una explicación. La idempotencia no es una palabra decorativa: es lo que permite reintentar sin convertir una avería en una fábrica de duplicados.
Después vienen las pruebas de salida. El PDF no está listo porque exista un archivo: debe abrirse, tener el número esperado de páginas, contener texto extraíble, cargar sus imágenes y renderizar sin cortes. El correo no está enviado porque se haya llamado a una función: debe aparecer en Enviados con el asunto, el destinatario y el adjunto correctos. La publicación web no está completa porque la base de datos acepte una fila: la ruta pública debe responder, mostrar el autor previsto, conservar el cuerpo íntegro y utilizar la imagen asignada. Cada canal tiene una prueba distinta y ninguna sustituye a las demás.
El registro de ejecución debe terminar en una prueba de entrega
La monitorización útil tampoco consiste en recibir un aviso por cada paso correcto. Eso sólo convierte el móvil en una feria. Conviene usar una señal de vida con un plazo claro: la tarea declara que ha terminado antes de una hora límite y el servicio de vigilancia alerta si no recibe esa confirmación. En paralelo, los errores técnicos deben conservar contexto suficiente para investigar: etapa, excepción, intento, duración y dependencia afectada, sin copiar secretos ni contenido sensible. Un resumen diario puede confirmar las ejecuciones sanas; la alerta inmediata queda reservada para ausencia, bloqueo o entrega parcial.
Los reintentos requieren criterio. Repetir una lectura o una comprobación suele ser seguro; repetir un envío o una publicación puede multiplicar efectos. Antes de reintentar, el flujo consulta la clave de edición y el estado del destino. Si el correo ya existe, no lo manda otra vez. Si el artículo está publicado, compara la versión y actualiza sólo cuando el contenido cambia. Si la imagen se cargó pero el registro falló, reutiliza el identificador existente. Esta separación entre operaciones reversibles e irreversibles debe estar escrita en el diseño, no improvisada durante el incidente.
También hace falta una ruta de recuperación manual. Una persona autorizada debe poder ver qué etapa falló, reanudar desde un punto seguro y cerrar la incidencia con una nota breve. El sistema no debería exigir rehacer la investigación ni reconstruir el contenido desde el PDF. Las entradas estructuradas, los textos finales y las imágenes aprobadas se conservan como fuentes de trabajo; el PDF sigue siendo una entrega, no una base de datos clandestina con corbata. De este modo se reduce coste, se mantiene trazabilidad y se evita que una herramienta externa vuelva a interpretar lo que ya estaba decidido.
La prueba definitiva es sencilla: simular un fallo antes de producción. Se corta la conexión al correo, se fuerza una respuesta errónea de la web y se lanza dos veces la misma edición. El flujo debe detectar la ausencia, no duplicar lo ya entregado, permitir continuar y dejar una historia comprensible. Las métricas que importan son porcentaje de entregas completas, tiempo hasta detección, tiempo de recuperación, número de duplicados y ejecuciones sin evidencia. Programar es fácil; operar consiste en saber, cada día y también cada domingo, qué salió, dónde llegó y quién puede demostrarlo.
Etiquetas
- Automatización
- fiabilidad
- Observabilidad
- idempotencia
- gobierno de IA
BOLDERROR Edición diaria Rubén Campoy