Cómo se ve un proyecto de integración de IA, semana a semana

Por qué el cronograma es el post#

La mayoría de los "proyectos de IA" que salen mal, salen mal de la misma manera. Alguien vio un demo, imaginó una construcción de seis semanas, y se dio cuenta a los seis meses de que el modelo estaba respondiendo a base de corazonadas y el equipo no podía distinguir si la cosa estaba ayudando o perjudicando. El arreglo no es un modelo más ingenioso — es un proceso más honesto.

Esta es la estructura que corro, de principio a fin, para cualquier integración no trivial de LLM. Son seis semanas de tiempo de calendario, más o menos, y la mayoría de los pasos no son negociables.

Semana 1 — diagnosticar el flujo de trabajo, no el modelo#

La primera semana se pasa con el equipo, en el terreno, mirando cómo se hace realmente el trabajo. ¿En qué bandeja de entrada aterrizan las preguntas difíciles? ¿Qué hace el humano a continuación — y cómo decide? ¿Dónde busca, y qué pega en la respuesta? ¿Qué parte de la respuesta es plantilla, qué parte es juicio, qué parte es un copy-paste desde otro sistema?

Salgo de la semana 1 con un brief de una página: el flujo de trabajo, los pasos humanos que se pueden automatizar, los pasos humanos que tienen que seguir siendo humanos, y los tres o cuatro modos de falla que más me preocupan. No se ha elegido ningún modelo. No se ha escrito código. Si no podemos escribir ese brief, no empezamos.

Semanas 2–3 — el 60% sin glamour: datos y retrieval#

La mayor parte del presupuesto del proyecto va acá. El trabajo es: identificar cada documento, ticket, transcripción o fila de base de datos que el agente necesita leer; limpiarla; chunkearla; embeberla; conectarla a un vector store; y escribir la lógica de retrieval que elija el contexto correcto para la pregunta correcta.

También es donde tomo las decisiones aburridas de infraestructura. Postgres más pgvector si los datos ya están en Postgres. Un Qdrant o Weaviate dedicado si el volumen es alto. Un modelo de embeddings servido por Ollama local si los datos son privados. Nada de esto es glamoroso; todo determina si el agente da buenas respuestas o inventa cosas con confianza.

También instrumento todo desde el día uno. Cada query, cada chunk recuperado, cada prompt, cada respuesta, cada latencia. Si no podemos repetir una conversación en tres meses, construimos una caja negra, no un producto.

Semana 4 — guardrails y evals (cómo sabes realmente que funciona)#

Para la semana 4 tenemos un agente aumentado con retrieval funcionando que responde preguntas reales. Ahora tenemos que probar que las responde bien.

Escribo un set de evaluación de cincuenta a doscientos ejemplos reales sacados de la bandeja de entrada real del equipo — las cosas que desearían no tener que responder dos veces. Cada uno tiene una respuesta conocida-buena o un comportamiento conocido-bueno. Corro el agente contra ese set cada vez que cambia el prompt, el modelo o el retrieval. Si baja el score, no hacemos deploy.

Los guardrails van al lado de los evals. Validación de esquema en la salida. Detección de PII en la salida. Una ruta de rechazo cuando el retrieval no devuelve nada. Un umbral de confianza por debajo del cual el agente pasa el caso a un humano en lugar de adivinar. Las fallas caras en producción rara vez son respuestas malas — son respuestas malas con confianza que el sistema no tenía razón para suprimir.

Semana 5 — piloto con humanos en el loop#

La semana 5 es el piloto. El agente corre en producción, pero cada respuesta la revisa un humano antes de salir de la oficina. Medimos acuerdo: qué tan seguido el humano habría mandado la misma respuesta, qué tan seguido tuvo que reescribirla, y qué tan seguido tuvo que tirarla entera.

También es donde afino los prompts, los umbrales de retrieval, y las reglas de handoff en función de lo que los revisores humanos realmente marcan. No afino a base de corazonadas. Afino a base de los desacuerdos. Si el agente se equivoca en una clase específica de pregunta, arreglo esa clase — no parcho un solo ejemplo.

Soy explícito con el equipo durante el piloto: esto no es una prueba del agente. Esto es una prueba de si el flujo de trabajo tal como lo rediseñamos es algo que los humanos realmente quieren.

Semana 6 — handoff y runbook#

Si el piloto sobrevive, la semana 6 es el handoff. Escribo el runbook: cómo desplegar una actualización del modelo, cómo hacer rollback, cómo leer el dashboard de evals, a quién llamar cuando sube la latencia, y qué hacer cuando el agente se equivoca en producción. Le paso las llaves al equipo que será dueño, y me quedo de retainer el primer mes.

Un runbook no es un manual. Es un documento corto y opinado que le dice al ingeniero de guardia exactamente qué hacer cuando lo pageen a las 02:00. Si no puedo escribir uno en una tarde, el sistema es demasiado complejo para hacer handoff.

Lo que hace que estos proyectos fallen#

Los mismos modos de falla aparecen una y otra vez:

• Scope creep. "Ya que estamos, hagamos también facturación." No. Termina un flujo de trabajo de punta a punta, después expandes.
• Saltarse los evals. "Agregamos los evals después del piloto." No. El piloto es el eval.
• Saltarse el piloto. "El demo se vio increíble, simplemente hagamos deploy." No. Los usuarios reales rompen los sistemas reales.
• Dejar que el modelo elija el flujo de trabajo. El modelo es una herramienta. El flujo de trabajo es una decisión de negocio. Mantenlos separados.
• Tratar el retrieval como una feature. El retrieval es el producto. Si el agente no encuentra el contexto correcto, nada más importa.

Si estás evaluando una integración y quieres una segunda opinión sobre si el flujo de trabajo está listo, la página de servicios lista lo que realmente tomo. Si ya sabes que quieres empezar, cuéntame el flujo de trabajo y te digo honestamente si es un proyecto de seis semanas o de seis meses.

---

Preguntas frecuentes#

¿Todos los proyectos de IA tardan exactamente seis semanas?#

No — seis semanas son para un único flujo de trabajo bien acotado, con datos limpios. Un rollout multi-flujo, una industria regulada, o una arquitectura de datos greenfield puede correr fácilmente tres a cuatro meses. Cualquier cosa que se anuncie más rápido o se está saltando un paso que vas a lamentar, o el flujo de trabajo era trivial desde el principio.

¿Se puede saltar el piloto e ir directo a producción?#

Puedes, y no te voy a detener, pero tampoco le voy a poner mi nombre. Saltarse el piloto significa que los primeros usuarios que rompan el sistema son tus clientes, y las clases de falla que la semana 5 está diseñada para sacar a la luz aparecen en producción en su lugar. El piloto es un seguro barato.

¿Qué pasa si nuestros datos son un desastre?#

Ese es el punto de partida más común, y es exactamente por qué existen las semanas 2 y 3. No finjo que los datos están limpios. El primer entregable de esas semanas es una auditoría honesta: qué está estructurado, qué es semi-estructurado, qué está en la cabeza de alguien, y qué hay que limpiar antes de que cualquier modelo lo toque. A veces la respuesta correcta es "todavía no arranques" — y esa también es una respuesta útil.

---

Fuentes: Anthropic, Building Effective Agents; OpenAI, A Practical Guide to Building Agents.