IA privada cuando el dato no puede salir de tu infraestructura

No, y conviene decirlo con claridad. Los modelos comerciales de frontera siguen por delante en razonamiento complejo, en tareas largas de varios pasos y en generación de código. La distancia se ha estrechado mucho, pero existe.

Ahora bien, la pregunta útil no es cuál es mejor en abstracto, sino si el modelo abierto es suficiente para tu caso. Para clasificar documentos, extraer campos, resumir o responder consultas sobre documentación interna, los modelos abiertos de tamaño medio rinden perfectamente. Para análisis jurídico fino o desarrollo, la diferencia se nota. Por eso probamos con tus preguntas reales antes de decidir.

Depende del tamaño del modelo, de la cuantización y de cuánta gente lo use a la vez. Un modelo pequeño puede correr en una GPU de gama profesional accesible y dar respuestas rápidas a un puñado de usuarios simultáneos. Un modelo grande sin cuantizar exige varias GPU de centro de datos y ya es una inversión de entidad.

El error habitual es dimensionar por el modelo más potente disponible en lugar de por el que resuelve el caso. También se subestima la concurrencia: una máquina que va sobrada con tres usuarios se satura con veinte. Preferimos medir en la prueba de concepto antes que estimar sobre el papel.

En la mayoría de escenarios de empresa mediana, no. Hay que sumar la GPU, el servidor, el consumo eléctrico, la amortización a tres o cuatro años y las horas de administración y actualización. Frente a eso, el coste por token de las API comerciales lleva años bajando. El despliegue privado se justifica por requisito de cumplimiento, por volúmenes muy altos y sostenidos, o por necesidad de operar sin conectividad, no por ahorro esperado. Cuando el motivo es exclusivamente el coste, hacemos el cálculo antes y casi siempre sale que no compensa.

Depende de qué te obligue a cumplir. Si el requisito es residencia del dato en la Unión Europea y ausencia de reutilización para entrenamiento, una región europea con el contrato adecuado lo cubre y es mucho más simple de operar. Si el requisito es que el dato no salga de tu perímetro de red o que puedas señalar físicamente la máquina que lo procesa, entonces no basta y hay que ir a hardware propio o a infraestructura dedicada. La distinción importa porque el salto de coste entre una opción y otra es grande.

Alguien tiene que hacerlo, y esa es la parte que se olvida al presupuestar. Salen versiones nuevas cada pocos meses, cambian las librerías de inferencia, hay que parchear el sistema operativo y hay que revisar que la calidad de las respuestas no se degrada al actualizar. Podemos encargarnos nosotros dentro de un contrato de mantenimiento, o formar a tu equipo de sistemas y dejar el procedimiento documentado. Lo que no recomendamos es desplegarlo y no volver a tocarlo.

Sí, y con frecuencia es la ruta más sensata. Si la aplicación se construye con el modelo como pieza reemplazable y no cableado al resto del código, cambiar el motor implica reajustar los prompts y volver a validar la calidad, pero no rehacer el proyecto. Así se valida primero que el caso de uso aporta valor, con inversión mínima, y sólo se invierte en infraestructura cuando el volumen o el requisito lo piden. El orden inverso, comprar hardware antes de saber si el caso funciona, es el error más caro que vemos.