El primer prototipo suele llegar antes que el acuerdo sobre qué significa que funcione. Entonces aparece una demo convincente, varias opiniones y ninguna decisión clara. La metodología sirve para evitar justo eso: convertir incertidumbres en pruebas y pruebas en decisiones.
No es un proceso lineal de ocho cajas. Habrá vueltas atrás. La diferencia entre iterar y dar tumbos está en dejar evidencia en cada paso.
1. Descubrimiento: observar el trabajo real
La primera fase ocurre cerca del proceso. Entrevistamos a quien lo ejecuta, revisamos casos reales y seguimos las excepciones. Buscamos entradas, decisiones, entregables, esperas, retrabajo y consecuencias del error.
El resultado no debería ser “un chatbot para Operaciones”, sino algo verificable: “reducir el tiempo de preparación de expedientes, extrayendo ocho campos de documentos autorizados y señalando discrepancias para revisión”. También necesitamos un responsable con capacidad para cambiar el flujo.
La evaluación de oportunidades de OpenAI recomienda documentar evidencia observable, frecuencia, alcance, fricción, dependencias, aprobaciones y propietario (OpenAI Academy). Esta disciplina descarta ideas atractivas que no resuelven un trabajo relevante.
2. Línea base y decisión de inversión
Antes de automatizar medimos cómo funciona hoy. Tiempo por caso, volumen, tasa de corrección, esperas, coste y, cuando importe, experiencia del usuario. No todos los indicadores serán precisos; debemos registrar cómo se obtuvieron y qué incertidumbre tienen.
También definimos el umbral de decisión. Por ejemplo: “continuaremos si reduce un 30 % el tiempo mediano, mantiene los errores críticos por debajo del 1 % y al menos ocho de diez usuarios prefieren el nuevo flujo”. Un objetivo así obliga a hablar de compensaciones. Más velocidad no compensa un aumento de errores graves.
OpenAI propone separar evidencia de adopción, eficiencia, calidad, funcionamiento seguro y resultado de equipo, siempre con unidad y periodo definidos (OpenAI Academy).
3. Diseñar el flujo futuro
Ahora decidimos qué hará la IA, qué seguirá siendo determinista y dónde interviene una persona. Las reglas calculan, validan formatos y aplican límites. El modelo interpreta lenguaje, clasifica casos ambiguos o prepara contenido. El usuario resuelve excepciones y aprueba acciones de impacto.
Conviene dibujar el recorrido completo, incluida la salida de emergencia. Si el servicio no responde, si falta un documento o si la confianza es insuficiente, ¿qué ocurre? “Lo revisará alguien” no basta: quién, con qué información y en qué plazo.
En esta fase se fijan datos permitidos, permisos, registros, retención y límites de autonomía. El marco de NIST conecta contexto, medición y gestión del riesgo durante todo el ciclo, no como una aprobación final (NIST AI RMF).
4. Prototipo: atacar la duda más cara
Un prototipo no es una versión pequeña del producto. Es una prueba diseñada para aprender. Si dudamos de la extracción, usamos documentos representativos y medimos campo por campo. Si el riesgo está en la búsqueda, forzamos políticas contradictorias y obsoletas. Si la adopción es incierta, probamos el recorrido con usuarios, aunque algunas integraciones funcionen manualmente detrás.
La muestra debe incluir lo normal y lo incómodo: escaneos deficientes, campos ausentes, idiomas, excepciones y casos límite. Una demostración con cinco ejemplos elegidos por el equipo no estima el comportamiento real.
Al terminar, decidimos: continuar, reducir alcance, cambiar arquitectura o parar. Un resultado negativo que elimina una inversión equivocada es útil.
5. Evaluación antes de integrar
El conjunto de pruebas se convierte en activo del proyecto. Contiene entradas, resultados esperados, criterios y gravedad de cada fallo. Puede combinar métricas automáticas con revisión experta; para tareas abiertas, una rúbrica clara es más útil que pedir si la respuesta “parece buena”.
No evaluamos solo el texto final. En un agente importan la selección de herramienta, los argumentos, el respeto de permisos, las citas, las abstenciones y el número de reintentos. Una respuesta correcta conseguida mediante una acción no autorizada es un fallo.
Las evaluaciones se ejecutan al cambiar instrucciones, modelo, herramientas, recuperación o datos. Así dejan de ser un examen inicial y se convierten en control de regresión.
6. Integración y piloto operativo
La integración demuestra si el diseño sobrevive al entorno real: identidades, latencia, APIs, concurrencia, costes y errores externos. Evitamos cuentas compartidas y damos al agente permisos mínimos. Las acciones sensibles requieren confirmación o una política determinista.
El piloto se hace con usuarios reales, un alcance conocido y soporte cercano. Registramos cuándo aceptan, corrigen, ignoran o rodean la solución. Esas señales cuentan más que las impresiones de una sesión de presentación.
También se prepara la continuidad. Debe existir una ruta manual, un mecanismo de parada y una persona responsable de incidentes. Si el piloto solo funciona con el equipo de desarrollo presente, todavía no está implantado.
7. Adopción: cambiar hábitos y responsabilidades
La formación explica cómo usar una herramienta. La adopción cambia el trabajo. Puede requerir eliminar una plantilla antigua, modificar objetivos, reservar tiempo de revisión o redefinir quién responde por una decisión.
Los usuarios necesitan saber qué hace bien el sistema, dónde falla y cómo escalar. También deben ver qué ocurre con sus correcciones. Si reportan el mismo error durante semanas, dejarán de colaborar.
El propietario del proceso revisa métricas y excepciones; tecnología vigila disponibilidad e integración; seguridad y gobierno observan controles; producto prioriza mejoras. Los nombres concretos importan más que una matriz de responsabilidades archivada.
8. Operar y mejorar
Después del lanzamiento cambian los documentos, el comportamiento de usuarios, las tarifas, los modelos y las APIs. Mantener exige versiones, trazas, alertas, evaluación periódica y presupuesto para correcciones.
Un cuadro de mando pequeño suele ser suficiente: volumen, adopción, resultado de negocio, errores por gravedad, escalados, latencia y coste por trabajo completado. Los tokens aislados dicen poco. Si el sistema usa más inferencia pero reduce a la mitad las gestiones reabiertas, quizá sea una buena decisión.
Cada cambio relevante pasa por el conjunto de pruebas y, según el riesgo, por despliegue gradual. También se revisan permisos, fuentes y reglas de retención. La retirada debe estar prevista: cómo exportar registros, revocar credenciales y volver al flujo anterior.
Los entregables que merecen existir
Una metodología ligera puede sostenerse con pocos documentos vivos:
| Entregable | Decisión que permite |
|---|---|
| Ficha del caso y línea base | ¿Merece la pena invertir? |
| Diseño del flujo y riesgos | ¿Cómo operará con seguridad? |
| Conjunto de evaluación | ¿Funciona y sigue funcionando? |
| Plan de piloto y adopción | ¿Puede usarse en el trabajo real? |
| Ficha de operación | ¿Quién mantiene, mide y detiene? |
Si un documento no ayuda a tomar o auditar una decisión, probablemente sobra.
La metodología no debe proteger al proyecto de cualquier sorpresa. Debe hacer que las sorpresas aparezcan pronto, sean visibles y tengan un responsable. Una implantación madura no presume de haber seguido todas las fases; puede mostrar qué aprendió en cada una y por qué decidió avanzar.
Preguntas frecuentes
¿Cuánto debe durar un piloto?
Lo necesario para observar volumen, excepciones y comportamiento real. En algunos procesos serán semanas; en otros, un ciclo mensual o estacional.
¿Cuándo involucramos a seguridad y legal?
Al definir datos, acciones y riesgo. Si llegan después del prototipo, pueden descubrir restricciones que obliguen a rediseñarlo.
¿Debemos construir la integración completa antes de evaluar?
No. Evalúe primero la capacidad incierta y valide temprano la viabilidad de integración. Construya en profundidad cuando ambas tengan evidencia.
¿Qué hacemos si no existe línea base?
Mida una muestra del proceso actual antes o durante una breve fase inicial. Sin referencia será difícil defender el resultado.
¿Quién aprueba el paso a producción?
El propietario del negocio junto con los responsables técnicos y de riesgo aplicables. La aprobación debe apoyarse en resultados y controles, no en la demo.