Definir qué se va a poner en producción
Ejemplo didáctico: un equipo quiere generar un resumen diario de solicitudes de clientes. El piloto produce textos útiles, pero todavía no se ha probado con todos los perfiles ni con fallos de integración. La primera decisión es delimitar el servicio: prepara un borrador, muestra las solicitudes usadas y exige aprobación antes de compartirlo.
Este alcance evita confundir capacidad del modelo con capacidad operativa del producto. Redactar un resumen correcto no demuestra que el flujo respete permisos, procese el conjunto completo o se recupere después de una interrupción. Esas condiciones necesitan controles y pruebas propios.
El documento de alcance identifica usuario, entrada, salida, destino permitido, responsable y exclusiones. Si el sistema solo prepara borradores, el contrato debe impedir que una herramienta o integración los publique directamente. Esa frontera puede cambiar en fases posteriores con evaluación adicional.
Un recorrido completo con estados visibles
La propuesta del sistema comienza con la solicitud de un usuario autenticado. Se valida el permiso y se toma una instantánea de las entradas. Las reglas comprueban completitud y requisitos de datos. El modelo prepara el borrador; el revisor decide si esa versión concreta puede publicarse.
Cada transición conserva un identificador y su resultado. La pantalla puede mostrar recibido, validando, pendiente de revisión, aprobado, publicado o bloqueado. «Publicado» exige evidencia del destino, no solo que el modelo haya solicitado una acción.
Si el revisor modifica el documento, se crea una versión nueva con su procedencia. Si se actualizan las fuentes tras aprobar, la versión aprobada no debe reutilizarse silenciosamente para publicar un resultado distinto.
Elegir workflow o agente según la necesidad
La referencia de Anthropic distingue recorridos prefijados por código de agentes que dirigen dinámicamente sus pasos. Para nuestro ejemplo, la secuencia conocida permite empezar con un workflow. El modelo aporta redacción; no necesita elegir libremente destinatarios ni ampliar el acceso a datos.
Un agente puede ser útil cuando la tarea exige explorar alternativas o elegir herramientas dentro de límites definidos. Esa flexibilidad añade comportamientos que evaluar. Antes de incorporarla, explica qué problema no resuelve el flujo sencillo y qué evidencia demostraría que la autonomía adicional aporta valor.
Este es un criterio de diseño de Asgardium, no una prohibición de agentes. La decisión debe considerar variabilidad de la tarea, impacto del error y capacidad de supervisión. No tiene sentido añadir complejidad que el equipo no pueda observar ni mantener.
Condiciones de aceptación por etapa
Define la aceptación antes de probar. El responsable funcional comprueba utilidad; el propietario del dato comprueba origen y permisos; quien opera el servicio comprueba errores y recuperación. Una demostración puede ocultar precisamente los pasos que cada responsable necesita revisar.
| Etapa | Comprobación | Si falla |
|---|---|---|
| Entrada | Identidad y acceso válidos | Bloquear petición |
| Datos | Colección completa y periodo correcto | Incidencia; no validar resumen |
| Borrador | Afirmaciones con evidencia | Devolver a revisión |
| Aprobación | Autoriza versión y destino concretos | No publicar |
| Publicación | Confirmación de efecto único | Consultar estado antes de repetir |
Evaluación real, simulaciones y límites de evidencia
Los tests con datos sintéticos permiten explorar situaciones concretas de forma controlada. Los mocks comprueban parte del contrato de integración. Ninguno de ellos demuestra por sí solo comportamiento de un proveedor real, un entorno de cliente o una carga sostenida.
Registra para cada prueba versión del sistema, conjunto de datos, proveedor real o simulado, comportamiento esperado y resultado observado. Una cobertura de cientos de pruebas no debe presentarse como validación de producto si solo cubre condiciones simuladas.
Reserva ejemplos que el equipo no haya usado para ajustar el sistema. Incluye datos incompletos, cambios de permisos, respuestas inválidas e interrupciones. Para tareas con impacto significativo, conserva condiciones de parada independientes de una puntuación promedio.
Observabilidad que permita intervenir
Un registro útil conecta solicitud, fuentes, reglas, herramientas y efectos con un identificador estable. Permite distinguir un error de recuperación documental de un error de publicación. Evita copiar secretos o textos completos cuando los identificadores y resúmenes de control son suficientes.
El panel operativo debe mostrar tareas pendientes, bloqueadas y completadas, con responsable de cada excepción. Las alertas se asignan a situaciones sobre las que alguien puede actuar. Registrar más datos sin un procedimiento de respuesta solo acumula información.
Como métricas iniciales proponemos tareas aceptadas, incidencias por categoría, tiempo de revisión, coste por tarea aceptada y tiempo de recuperación. Se acuerdan definiciones y periodo de medida; esta guía no ofrece una línea base ni un resultado de ahorro de cliente.
Recuperación: el efecto puede haber ocurrido aunque no llegue la respuesta
Supón que la herramienta publica el resumen y la conexión se interrumpe antes de confirmar. Repetir de inmediato puede duplicar el documento. El servicio necesita consultar el estado con una referencia estable o utilizar idempotencia cuando la integración lo permita.
Si no puede comprobarse qué ocurrió, el estado debe pasar a revisión. «No sé si se publicó» es un resultado distinto de «no se publicó». El diseño debe representarlo sin que el modelo rellene la incertidumbre con una suposición.
Conserva una versión recuperable de configuración, documentos y componentes. La restauración vuelve a aplicar los permisos actuales. Define quién decide volver a una versión anterior, cómo se comprueba su validez y cómo se reanudan las tareas que quedaron a medias.
Despliegue gradual y decisión de ampliar
Empieza con un grupo acotado, preparación de borradores y revisión explícita. Compara durante un periodo acordado el servicio asistido con el proceso anterior. Si se amplía, documenta qué evidencia lo justifica y qué restricciones continúan vigentes.
La entrega incluye manual operativo, responsables, evaluación, procedimiento de incidentes y recuperación. El checklist descargable propone una estructura de revisión; no certifica que el servicio cumpla normas ni sustituye una validación de seguridad o legal.
Esta publicación describe una arquitectura didáctica. No es un informe de un despliegue real de Asgardium. Su objetivo es que quien compra o desarrolla IA pueda formular mejores requisitos, reconocer vacíos de evidencia y decidir qué falta antes de poner un servicio a disposición de usuarios.
Recursos para trabajar esta guía
Descargas abiertas. Adapta los criterios a tu proceso; los conjuntos de ejemplo contienen datos sintéticos.
Checklist para pasar de piloto a producción
Responsables, evaluación, permisos, aprobación, confirmación de efectos, incidentes y recuperación.
Descargar Markdown ↓Fuentes y alcance
Consulta de referencias: 8 OCT 2026. Los ejemplos y criterios operativos son propuestas editoriales de Asgardium; no demuestran resultados de clientes.
Distinción entre workflows y agentes; el ejemplo de implementación es una propuesta de Asgardium.
Continúa por este tema
Cómo evaluar un sistema de IA antes de ponerlo en producción →
La observabilidad de un agente empieza antes del primer token →
AI Act: qué revisar en la transparencia de un sistema de IA →
ASGARDIUM CONSULTING