Un sprint de tres semanas se convierte en cinco. Nadie puede explicar por qué. El componente de IA funciona de forma aislada. La integración sigue fallando. Dos ingenieros pasaron cuatro días depurando un problema que un documento de contexto de una página habría evitado.
Eso es una transferencia rota. Es la fuente más común de retrasos en proyectos de IA, y casi nunca se registra como causa raíz.
Qué cuesta realmente una transferencia rota
La unidad de pérdida no son horas. Son reinicios de sprint.
Un reinicio de sprint significa que trabajo ya aceptado se reabre. Decisiones ya tomadas se vuelven a debatir. Ingenieros que habían avanzado son jalados de regreso. El efecto acumulado es peor que el retraso inicial.
Aquí hay un patrón concreto: el Ingeniero A construye un pipeline de datos. El Ingeniero B lo hereda para conectar una capa de inferencia. B no sabe qué campos son anulables, qué fuentes upstream son poco confiables, ni por qué A tomó tres decisiones específicas de esquema. B hace suposiciones. Dos de ellas son incorrectas. La capa de inferencia se entrega con errores silenciosos. QA los detecta en la semana cuatro.
La corrección toma dos días. La investigación toma tres. El sprint se reinicia. Eso es una pérdida de cinco días por una transferencia que no tuvo ningún artefacto escrito.
Multiplica eso a lo largo de un proyecto de seis meses con ocho ingenieros y obtienes un proyecto que entrega en nueve meses — no porque la IA fuera difícil, sino porque el contexto seguía evaporándose entre personas.
Por qué los sistemas de IA empeoran los fallos de transferencia
El software convencional falla de forma ruidosa. Una llamada a una API rota lanza una excepción. Un campo faltante causa un null pointer. La superficie de fallo es visible.
Los sistemas de IA fallan en silencio. Un prompt mal configurado devuelve una salida que parece plausible. Un paso de recuperación extrae los documentos incorrectos sin error. Un modelo de embeddings produce vectores que se agrupan incorrectamente — y el modelo downstream simplemente trabaja con lo que recibe.
Esto significa que los fallos de transferencia en proyectos de IA no siempre aparecen de inmediato. Se acumulan. Un ingeniero hereda un componente, hace un cambio que parece razonable e introduce una degradación sutil que no se manifiesta hasta que el sistema está bajo carga de producción con datos reales.
Tres modos de fallo específicos aparecen repetidamente:
- Suposiciones del modelo sin documentar. El ingeniero original sabía que el modelo era sensible a la longitud del input. El siguiente ingeniero no lo sabía. Los casos borde empezaron a fallar a los 90 días.
- Baselines de evaluación faltantes. Nadie escribió cómo se veía "bueno" antes de la transferencia. El nuevo ingeniero no tenía forma de saber si sus cambios mejoraban o degradaban el comportamiento.
- Contratos de datos implícitos. El pipeline asumía un formato de campo específico. Esa suposición vivía en la cabeza de un ingeniero. Cuando se fue, la suposición se fue con él.
Cada uno de estos es un fallo de proceso, no técnico. La IA no causó el problema. La ausencia de artefactos sí.
El principio operativo: artefactos de proceso sobre heroísmos
En DK1.AI, la regla es simple: si no está escrito, no existe.
Eso no es un valor cultural. Es una restricción operativa. Los sistemas construidos para Brand Presence corren de forma continua. Los ingenieros rotan. El contexto tiene que sobrevivir los cambios de personal sin degradarse.
El conjunto de artefactos para cualquier transferencia de componente de IA incluye:
- Registro de decisiones. Por qué este enfoque y no las alternativas consideradas. Con fecha.
- Inventario de fallos. Qué se rompió durante el desarrollo y por qué. Sin sanitizar.
- Baseline de evaluación. Inputs específicos, outputs esperados, varianza aceptable. Números, no descripciones.
- Contrato de datos. Cada dependencia upstream, su calificación de confiabilidad y qué sucede cuando falla.
- Límites conocidos. Dónde se degrada el componente. Qué inputs maneja mal. Para qué no fue diseñado.
Esto toma tiempo producirlo. Ese es el punto. El tiempo invertido en escribir el artefacto se recupera la primera vez que alguien hereda el componente sin una sesión verbal de tres horas.
Los heroísmos — el ingeniero que guarda todo en su cabeza y siempre está disponible para responder preguntas — son un pasivo. Crean puntos únicos de fallo. Hacen que el sistema dependa de una persona en lugar de un proceso. Cuando esa persona no está disponible, el proyecto se detiene.
Los artefactos de proceso son aburridos. También son lo único que escala.
Cómo se ve esto en la práctica
Un componente se considera completo cuando su conjunto de artefactos está completo — no cuando el código pasa las pruebas. La revisión de código incluye revisión de artefactos. Un PR sin una entrada en el registro de decisiones para elecciones no triviales no se fusiona.
Las transferencias se programan, no son ad hoc. El ingeniero saliente y el entrante recorren juntos el conjunto de artefactos. Los vacíos se llenan antes de cerrar la transferencia. El ingeniero entrante confirma que tiene suficiente contexto para ser dueño del componente.
Esto agrega aproximadamente cuatro horas por transferencia mayor. Elimina los reinicios de sprint. La matemática es directa.
El problema de fondo
Los proyectos de IA fallan en las costuras entre personas, no en el centro de la tecnología. El modelo funciona. El pipeline funciona. La transferencia no.
Corrige el proceso de transferencia y la mayoría de los retrasos en proyectos de IA desaparecen. No porque la IA mejoró — sino porque el sistema a su alrededor se volvió más disciplinado.
El proceso aburrido le gana a los ingenieros heroicos. Siempre.