La mayoría de las páginas de construir-versus-comprar las escribe el lado de comprar y llegan a la conclusión previsible. Esta es la parte que es cierta de todos modos: muchas organizaciones deberían construir esto, y las que no deberían son identificables por una sola propiedad del trabajo, no por su tamaño ni por la calidad de su ingeniería.
Cuándo construir es claramente lo correcto
Cuando las acciones son reversibles. Un agente que redacta, resume, propone o escribe en un entorno de pruebas puede equivocarse sin que nadie lo pague, y en ese contexto la forma más rápida de aprender qué necesita realmente el flujo es construir una versión tosca y usarla. Ningún documento de diseño le dirá lo que le dirán tres semanas de uso real.
Del estándar
“Granting LLMs unchecked autonomy to take action can lead to unintended consequences, jeopardizing reliability, privacy, and trust.”
También es correcto cuando la capacidad misma es el objetivo. Si su estrategia es tener ingeniería agéntica interna en tres años, comprar el primer sistema retrasa eso y enseña menos a su equipo. Construir uno estrecho mal y luego reconstruirlo es una forma legítima de adquirir la habilidad, y es como empezaron la mayoría de las plataformas internas duraderas.
Lo que el estimado omite
Los estimados se construyen con las partes que la gente puede imaginar. Prompts, definiciones de herramientas, una tubería de recuperación, una interfaz — son concretas, son sobre lo que el equipo ha leído, y sí producen una demostración funcional en pocas semanas. La demostración es real. También es aproximadamente la primera quinta parte del trabajo, y las cuatro quintas restantes son invisibles en ella.
| En la estimación | Descubierto en la revisión |
|---|---|
| Prompts y definiciones de herramientas | Aislamiento de ejecución en el hipervisor, no en el espacio de nombres |
| Una canalización de recuperación | Federación de identidad: el agente actúa como la persona, no como una cuenta de servicio |
| Una interfaz | Un conjunto de herramientas intersecado por turno según el rol de esa persona |
| Registro de eventos | Política validada fuera del canal del propio modelo |
| — | Aprobación fijada a un token de versión; se rechaza la repetición |
| — | Una traza que sobrevive a la costura entre control y ejecución |
Cada línea de la derecha existe por un modo de fallo concreto, y ninguna se adapta limpiamente a un prototipo que ya funciona. Esa es la propiedad cara: el sustrato no es una capa que se añade después, es un conjunto de decisiones sobre dónde corre el código y qué autoridad lleva, y cambiarlas significa reconstruir lo que hoy demuestra bien.
El costo que nadie presupuesta: quedarse quieto
Un sistema construido no está terminado cuando se lanza. Los proveedores de modelos cambian el comportamiento entre versiones de formas que no se anuncian como rupturas. Los frameworks reorganizan sus abstracciones. Una estrategia de recuperación que funcionaba con doscientas tablas deja de funcionar con dos mil. Cada uno de esos es una revalidación, no una actualización, y en un contexto regulado la revalidación es papeleo además de ingeniería.
El encuadre honesto no es construir contra comprar, sino dónde quiere a sus mejores ingenieros dentro de dos años. Algunas organizaciones los quieren en el sustrato porque es estratégico. La mayoría los quiere en el problema de dominio al que el sustrato sirve.
Una prueba que lo decide
Escriba la primera acción que el sistema tomará que usted no podría deshacer antes del almuerzo. Si no existe tal acción, constrúyalo — aprenderá más, gastará menos y será dueño del resultado. Si existe, el sustrato es el proyecto, la demostración no lo es, y la decisión es sobre quién carga ese trabajo, no sobre si hace falta.
Se omite demasiado a menudo una tercera opción: construya la capa de dominio y tome el sustrato como código fuente. Cada proyecto aquí incluye transferencia completa de código e infraestructura como código, lo que significa que la pregunta construir-o-comprar puede responderse como ambas, y la parte que su equipo posee es la que codifica su negocio y no la que codifica un modelo de amenazas.
Axionalytics
IA agéntica en producción para equipos empresariales de ingeniería, datos e ingresos.