De piloto GenAI a workflow interno: evaluación, controles y fallback humano

El problema enterprise no es acceder a modelos

La mayoria de las organizaciones ya tiene acceso a modelos de frontera, copilotos, APIs y presupuestos de experimentacion. Lo dificil es convertir ese acceso en un workflow que alguien pueda operar, medir, auditar y mejorar. Un piloto que responde algunos prompts curados todavia no es un sistema interno. Se convierte en uno cuando la organizacion puede describir que proceso cambia, quien es responsable de la decision, que datos toca, que fallas importan y que ocurre cuando el modelo no debe actuar.

La unidad de valor no es el prompt. La unidad de valor es el workflow gobernado.

Mirar el workflow cambia la pregunta de implementacion

La primera pregunta no es que modelo usar. Es si un proceso tiene suficiente trabajo repetido, contexto de datos, presion de revision y resultado medible para justificar intervencion con IA. En una empresa, un workflow util suele combinar documentos, reglas de negocio, usuarios, aprobaciones, sistemas aguas abajo y excepciones. La IA generativa es una pieza dentro de ese ciclo operativo.

• Entrada: documentos, tickets, correos, bases de datos, politicas o eventos operacionales.
• Razonamiento: recuperacion, resumen, clasificacion, extraccion o recomendacion.
• Control: politicas, permisos, gates de aprobacion y reglas de escalamiento.
• Accion: redactar, enrutar, actualizar, alertar, crear un registro o derivar a una persona.
• Evidencia: logs, fuentes, version de modelo, version de prompt, output, decision del revisor y etiqueta de falla.

Cuatro gates antes de escalar

1. Gate de utilidad

El workflow debe mejorar una metrica concreta: tiempo de respuesta, capacidad de revision, retrabajo, cobertura, calidad, costo o latencia decisional. Si la metrica es vaga, el caso no esta listo.

2. Gate de riesgo

El equipo debe decidir que puede ver el modelo, que puede generar, que nunca puede hacer y cuando una persona debe aprobar. Esto importa especialmente con datos sensibles, procesos regulados, seguridad y outputs hacia clientes.

3. Gate de evaluacion

Un set pequeno de prueba no basta. El workflow necesita casos realistas, casos adversariales, fallas esperadas, regresion y un umbral explicito de no escalamiento.

4. Gate de operacion

El workflow necesita propiedad despues del lanzamiento: monitoreo, cambios de prompt, cambios de modelo, cambios de acceso, revision de incidentes y mejora continua. Sin ese responsable, el piloto se vuelve deuda tecnica.

Un patron practico de despliegue

Amawta usa una ruta controlada: evaluar el proceso, definir controles, prototipar con usuarios reales, medir fallas y decidir si corresponde implementar. La meta no es maximizar autonomia el primer dia. La meta es crear un workflow que gane autonomia solo cuando acumula evidencia.

• Semana 1: mapa de proceso, inventario de datos, mapa de riesgo y metrica de exito.
• Semana 2: alcance del prototipo, criterios de aceptacion y set de evaluacion.
• Semana 3: piloto interno con logs, fuentes, feedback de usuarios y etiquetas de falla.
• Semana 4: paquete de decision: escalar, ajustar, pausar o rechazar.

Que deberia pedir el comprador

Una propuesta seria de workflow IA debe incluir mas que una demo. Pide plan de evaluacion, frontera de datos, modelo de controles, fallback, auditoria y responsable operativo. Si esas piezas faltan, el riesgo de implementacion no es sofisticacion tecnica. Es ambiguedad organizacional.