De la web ubicua al “todo en la nube”
Vivimos en una sociedad donde casi todo pasa por la web, y para las generaciones más jóvenes esto parece el orden natural de las cosas: apps siempre conectadas, smartphones en la mano y un flujo constante de datos y notificaciones. La información compartida, las redes sociales, los likes, los comentarios y las publicaciones en línea dan la sensación de que “siempre fue así” y de que necesariamente debe seguir siéndolo.
Quienes empezamos en sistemas antes de las redes sociales vimos otra película. Muchos entornos eran stand‑alone, luego llegaron las redes locales con servidores compartidos dentro de la empresa, y más tarde Internet cambió por completo el modelo de trabajo. Pasamos a servicios distribuidos, aplicaciones web y arquitecturas cada vez más acopladas a la conectividad global.
La irrupción (masiva) de la IA
La IA no nació con la nube ni con Internet, pero su uso masivo sí. En los últimos años, la combinación de IA + infraestructura cloud —lo que muchos llaman “IA en la nube”— se hizo ubicua: modelos de lenguaje como servicio, APIs de embeddings, RAG gestionados, etc.
El paso a herramientas como ChatGPT, Claude, Gemini y compañía fue bastante natural para la mayoría de desarrolladores. Funcionan como un “súper buscador” y un autocompletado muy potente que ayuda con tareas cotidianas: escribir código, documentar, depurar ideas y automatizar partes repetitivas del trabajo.
Mientras el uso se queda en consulta y experimentación, todo bien.
Cuando la IA deja de ser un juguete
El problema aparece cuando dejamos de usar la IA solo como asistente/buscador y empezamos a integrarla como componente central de proyectos serios:
- Orquestadores de procesos críticos
- Sistemas RAG sobre corpus privados
- MCPs o agentes que coordinan servicios internos
- Automatización de flujos de desarrollo y operación
En ese punto las preguntas cambian:
- ¿Hasta qué nivel es razonable que el backend, el know‑how y los datos sensibles dependan de un servicio de terceros?
- ¿Qué tanto control real tenemos sobre dónde se procesan los datos, quién puede auditarlos y cómo se reutiliza el contenido enviado?
- ¿El modelo o proveedor puede aprender de nuestros prompts, código y documentación interna, directa o indirectamente?
Y, sobre todo: ¿estamos dispuestos a que alguien pueda replicar capacidades similares pagando la misma suscripción de 20, 50 o 100 USD/mes?
No es solo un tema técnico; es estratégico.
Mis dos dolores: costos y control
En mi caso, hubo dos factores que me hicieron poner el freno:
Costos variables difíciles de predecir.
En escenarios de uso intensivo (equipos pequeños pero muy activos, pipelines que llaman a modelos muchas veces al día, pruebas, iteración rápida, etc.) la factura por tokens puede crecer más rápido de lo esperado.Pérdida de control.
No tener claridad plena de dónde, cuándo y cómo se usa lo que envío a un proveedor externo, ni poder auditar la infraestructura de punta a punta, no es precisamente tranquilizador cuando trabajas con lógica de negocio o datos delicados.
A partir de ahí empecé a experimentar con IA local.
Explorando IA local en entornos moderados
No tengo todavía una solución “perfecta”, pero ya tengo modelos corriendo en máquinas locales con recursos moderados (lo que podríamos llamar “dev boxes vitaminadas” o servidores modestos on‑premise).
Al mismo tiempo, empecé a ver un patrón interesante: empresas muy grandes están reconsiderando el modelo todo en la nube para ciertos casos de uso. No hablo del consumo consultivo (usar modelos públicos para buscar, resumir o prototipar, que probablemente seguirá así mucho tiempo), sino del core de los procesos internos:
- Orquestadores de procesos de negocio
- Sistemas RAG sobre documentación corporativa
- MCP y agentes que tocan infraestructura sensible
- Automatización de workflows que representan ventaja competitiva
Para este tipo de escenarios, empiezan a reaparecer conceptos como:
- Stand‑alone y on‑premise para la capa de IA crítica
- Redes locales aisladas para desarrollo y pruebas internas
- Modelos propios o afinados en casa sobre hardware dedicado
Hardware y ecosistema: el péndulo vuelve
El ecosistema de hardware y frameworks está empujando esta tendencia:
- Fabricantes como NVIDIA, Qwen y otros proveedores están ofreciendo modelos y soluciones pensadas para ejecutarse on‑premise o en nubes privadas.
- Surgen chips específicos para aceleración de IA (tipo Willow y equivalentes) que bajan la barrera de entrada para ejecutar modelos grandes localmente.
- Incluso la computación cuántica empieza a asomar como otra capa futura de cómputo especializado.
No es barato todavía. Estar hablando de máquinas alrededor de 4.000 USD o más sigue siendo una inversión seria. Pero son los albores de un cambio: muchas laptops y PCs podrían modificar drásticamente su rol y su patrón de conectividad, pasando de “terminales tontas de la nube” a nodos de cómputo de IA mucho más autónomos.
Modelos asistidos encapsulados: sin lenguaje de programación explícito
En mi caso particular, he venido experimentando con un enfoque algo distinto a la programación “clásica”:
- Uso modelos de programación asistida encapsulados;
- No expongo directamente un lenguaje de programación tradicional en cada caso de uso;
-
En su lugar, defino cápsulas generativas que saben ejecutar procesos:
- Siempre repetitivos
- Deterministas (0 grados de libertad en tiempo de ejecución)
- Basados en un schema y un stack síncrono bien definido
La idea es algo así:
- Defino qué proceso quiero (contrato, entradas, salidas, restricciones).
- Defino cómo debe orquestarse (pasos, dependencias, reglas de validación).
- La cápsula genera y ejecuta la lógica necesaria, pero la interfaz para mí no es un IDE tradicional ni un framework enorme, sino una configuración estructurada.
Esto me ha permitido avanzar más rápido en algunos proyectos porque:
- Me concentro en el diseño del proceso y la semántica, no en detalles de framework o API de bajo nivel.
- Las correcciones se vuelven cambios de contrato/configuración en lugar de grandes refactors de código disperso.
- El entorno se mantiene encapsulado y controlado (sin “copiar y pegar” media base de código en un prompt público).
No es magia ni “soluciona todo”, pero abre un espacio interesante entre “puro código” y “puro prompt”.
La pregunta incómoda: ¿qué tan expuesto quieres estar?
No pretendo vender esto como la solución definitiva. La nube sigue teniendo ventajas enormes: elasticidad, gestión simplificada, ecosistema, servicios administrados, etc.
Pero sí quiero dejar planteada una pregunta que, como ingeniero o arquitecto, tarde o temprano tendrás que responder:
¿Qué tan conveniente es que el desarrollo de tus proyectos críticos,
asistidos por IA, dependa de servicios que pagas “por token”,
exponiendo a la vez tu billetera y, sobre todo,
tu conocimiento y lógica de negocio a una infraestructura pública de terceros?
Tal vez la respuesta siga siendo “cloud first” para muchos casos.
Tal vez, para otros, sea el momento de volver a mirar con cariño el stand‑alone y el on‑premise… pero esta vez con IA dentro.
