Estrategia de modelos para un Company Brain: OSS, propietarios o ambos
Cómo elegir modelos open source, propietarios o self-hosted cuando el activo real es conocimiento empresarial gobernado.
Cómo elegir modelos open source, propietarios o self-hosted cuando el activo real es conocimiento empresarial gobernado.
“Ser dueño de tus modelos” suena a soberanía. A veces lo es. A veces es teatro caro de soberanía — factura de GPU con los mismos huecos de gobernanza que una API SaaS, más dolor de guardias.
Aquí va un mapa práctico para equipos regulados con mucho documento.
Control del camino de datos. La inferencia se queda en tu VPC o región soberana. Sin ambigüedad de entrenamiento del proveedor — si lo configuras así y lo verificas en contrato y telemetría.
Economía unitaria predecible a escala. Embeddings e inferencia por lotes en volumen alto pueden ser más baratos en GPU propia — si la utilización se mantiene alta y tienes gente para operarlo.
Profundidad de personalización. Fine-tuning, adaptadores de dominio y despliegues cuantizados on-prem importan cuando los modelos genéricos fallan en terminología o documentos con layout complejo.
Entornos air-gapped o restringidos. Defensa, infraestructura crítica y algunas redes financieras no pueden llamar APIs públicas. La propiedad no es preferencia; es restricción.
Ajuste de latencia y residencia. Colocas inferencia junto a almacenamiento e índices vectoriales — útil cuando milisegundos y jurisdicción importan a la vez.
Heredas el impuesto MLOps. GPUs, drivers, deriva de CUDA, model cards, rollback, capacidad, parches de seguridad — eso es un equipo de plataforma, no un side project.
Acantilados de utilización. Un clúster perfecto el lunes a las 9 puede estar idle el domingo. Las APIs gestionadas externalizan esa volatilidad.
Frescura del modelo. Los foundation models avanzan cada trimestre. Quien self-hostea necesita programa de actualización o acepta retraso de capacidades.
Los riesgos de datos siguen ahí. Tener el modelo no significa tener el riesgo resuelto. Un mal RAG, logging o tooling de agentes puede filtrar igual por tu propio stack.
El cumplimiento no es automático. SOC2 tuyo más ISO tuyo más auditoría de tus logs de inferencia. La propiedad traslada responsabilidad — puede ser correcto, pero no es gratis.
Eso es propiedad del sistema — no necesariamente de cada matriz de pesos.
Responde con honestidad antes de comprar GPUs:
| Pregunta | Si la respuesta es “no,” pausa |
|---|---|
| ¿Tenemos cobertura 24/7 para caídas de inferencia? | Self-hosting dolerá |
| ¿El volumen es estable para mantener GPUs ocupadas? | TCO probablemente pierde |
| ¿Podemos actualizar modelos cada trimestre? | Te quedarás atrás |
| ¿Necesitamos air-gap o residencia que APIs no dan? | Propiedad puede ser obligatoria |
| ¿El cuello de botella es calidad de recuperación, no tamaño de modelo? | Arregla RAG antes que hardware |
Tener modelos propios compensa cuando los requisitos de control son duros y la madurez operativa es real. Es malo cuando el objetivo es privacidad por vibes o evitar partidas de API sin contar años de ingeniería.
La jugada ganadora para la mayoría de equipos documentales regulados es ser dueño de evidencia, políticas y evaluación — y tratar el hosting del modelo como una capa deliberada e intercambiable.
Una explicación práctica de la capa que falta entre el conocimiento disperso de la empresa y una automatización con IA fiable.
Por qué los resúmenes de IA necesitan evidencia de origen, frescura y revisión antes de convertirse en conocimiento operativo.
Por qué políticas, contratos y SOPs necesitan contexto gobernado de fuentes antes de que los borradores de IA sean seguros de usar.