Casi todo proveedor de software de IA para empresas ofrece hoy la misma garantía en la primera reunión: se ejecuta en tu propia infraestructura. Suele ser verdad. El problema no es la frase, es que cubre al menos cuatro esquemas distintos, con costos operativos distintos, tratados en la conversación comercial como si fueran uno solo.
Resuelto dónde queda el dato y si el modelo local alcanza para la tarea, queda la pregunta de dónde se instala el software. La respuesta de la primera pieza, la de que Aptabit no ve tus datos, cambia de peso según el esquema que esté en operación en tu entorno, porque es el esquema el que decide dónde queda la frontera de salida.
Cuatro esquemas que caben en la misma frase
La frase dice dónde se instala el software, no dónde queda la frontera. En cada esquema la frontera se apoya en algo distinto. En una pared física, en un contrato de nube, en la ausencia de ruta de salida o en una decisión de configuración de acceso.
Servidor en el centro de datos de la organización. La organización decide todo, y hereda todo lo que un servidor exige: capacidad, energía, refrigeración, guardias y recambio de hardware. Para quien ya tiene centro de datos y equipo, el costo marginal es pequeño. Para quien no lo tiene, es un proyecto de infraestructura con nombre de proyecto de IA. Si el acervo no tiene restricción de salida, esta arquitectura puede ser más costo del que la organización necesita pagar, y un servicio de un tercero resuelve.
Cuenta propia en la nube. La nube privada o la cuenta del cliente en la nube pública devuelven elasticidad sin transferir la titularidad del entorno. Una pared física es una cosa. La configuración de una cuenta es otra. La separación sigue existiendo, pero pasa a depender de quién tiene credenciales y de cómo está diseñado el acceso.
Entorno aislado. Sin conexión de salida, la garantía deja de depender de la configuración. Nada sale porque no existe ruta de salida. Es el esquema más fuerte en confidencialidad y el más caro en operación. Todo lo que entraba por tu red pasa a entrar por procedimiento.
Híbrido decidido por flujo. La mayor parte se ejecuta dentro, y flujos específicos salen hacia un modelo alojado afuera. Es el esquema que más atrae por comodidad y el más fácil de hacer mal. Solo se sostiene mientras la salida sea una decisión explícita, tomada flujo por flujo, y mientras alguien pueda decir qué flujos salen hoy.
Dónde el esquema más cerrado pasa la cuenta
Una pieza que solo enumerara ventajas no ayudaría a nadie a decidir. Nuestro sitio afirma que la plataforma opera sin conexión, y por eso el precio de ese esquema hay que decirlo en voz alta. Tres costos aparecen cuando la conexión de salida deja de existir: dos tuyos y uno nuestro.
El primero es el diagnóstico. Sin ruta de salida no existe soporte remoto mirando el entorno, y el diagnóstico pasa a depender de lo que tu equipo logre recolectar y describir. Es un camino más largo de lo que una demostración deja ver. La pregunta a hacer es cómo conduce el proveedor una investigación en ese modo, no si la conduce.
El segundo es la actualización. La pieza inicial de esta serie ya observó que el software sin canal con el fabricante no recibe correcciones de seguridad por su cuenta. Lo que cambia en el entorno aislado es qué ocupa el lugar de ese canal. La corrección pasa a atravesar la frontera cargada por una persona, y eso convierte cada aplicación en un procedimiento con fecha marcada, responsable definido y verificación del origen antes de empezar. Tres preguntas deciden si el esquema se sostiene en tu casa: cuánto tiempo separa la publicación de una corrección de su entrada en tu entorno, quién en tu equipo ejecuta ese transporte, y qué le pasa al sistema en producción si la aplicación falla a mitad de camino. La última es la que menos se pregunta, porque exige un camino de vuelta planificado antes de que la actualización empiece. Cambiar de modelo recorre la misma ruta.
El tercero es nuestro. Ir hasta el dato obliga al producto a caber en entornos que no elegimos ni administramos, y parte de su comportamiento en producción depende de una infraestructura que no podemos garantizar ni reproducir. Quien aloja su propio software conoce la máquina en la que se ejecuta. Nosotros no conocemos la tuya.
Nada de esto es un argumento en contra del aislamiento. Es la descripción de lo que el aislamiento transfiere. La pregunta a hacer antes de elegir este esquema es quién, en tu equipo, ejecuta esas rutinas, y si esa persona ya existe hoy.
Qué preguntar antes de elegir el esquema
Estas preguntas sirven para cualquier proveedor que se ofrezca a instalar software en tu entorno, y revelan qué esquema sostiene de verdad:
- ¿En qué esquemas de despliegue está soportado este producto, y qué cambia en cada uno?
- ¿Quién es titular de la cuenta de nube donde esto se ejecuta, yo o el proveedor?
- ¿Qué se rompe si corto internet durante una semana?
- ¿Cómo se actualiza y se corrige el producto, y qué exige eso de mí en cada esquema?
- ¿Quién en mi equipo opera esto después del despliegue, y qué pasa si esa persona se va?
La quinta es la que menos favorece a quien vende software para instalar, y roza la pregunta de qué sigue funcionando cuando el contrato termina, tema de una pieza más adelante en esta serie.
Por qué la topología decide antes que la funcionalidad
Nuestro sitio afirma tres cosas sobre dónde se ejecuta la plataforma, y las tres son de topología. Es autoalojada, con Docker o Kubernetes. La base de datos, los archivos y los vectores quedan en la infraestructura del cliente. Los modelos pueden ser locales o de un proveedor externo. Leídas como funcionalidades, esas tres afirmaciones dicen poco. Leídas como topología, describen dónde se puede colocar la frontera, y cuánto cuesta mantener cada posición.
Ir hasta el dato, en vez de pedir que el dato venga hasta nosotros, decide dónde queda la frontera antes de decidir cualquier otra cosa. Elegir el esquema es elegir cuánto de esa frontera pasa a operar tu organización por su cuenta.