IA en la nube o en infraestructura dedicada: cómo evaluar las limitaciones reales

«Quiero una inteligencia artificial privada» es casi siempre la respuesta a una preocupación precisa: que los datos de la empresa acaben donde no deberían. Es una preocupación legítima, pero no basta para elegir entre un servicio en la nube, una infraestructura dedicada y un servidor en la empresa. La elección se hace sobre requisitos escritos, comparados con lo que cada solución exige en competencias, mantenimiento y costes recurrentes. Esta guía sirve para construir esa lista.

Qué debéis decidir realmente

«Dónde está el modelo» es la consecuencia, no la pregunta de partida. Las preguntas que hay que hacerse antes son cuatro.

• Qué datos tocará el sistema, y cuáles de ellos no pueden salir de vuestro perímetro. A menudo es una parte pequeña del total: algunas categorías de documentos, no todo el archivo.
• Qué ocurre si el servicio no está disponible durante medio día. Si el trabajo se detiene, el requisito de continuidad lo cambia todo lo demás.
• Quién lo mantendrá, con nombre y apellidos, en los próximos tres años. Es el requisito que se ignora más a menudo y es el que decide más que ningún otro.
• Cuán previsible es el uso. Una carga constante y una carga con picos se pagan de forma muy distinta.

Las tres modalidades, y qué piden a cambio

Simplificando, las opciones son tres. La tabla compara lo que exige cada una, no lo que promete.

Ninguna columna es mejor en términos absolutos: cada una desplaza el trabajo y el riesgo a un punto distinto. La nube los desplaza al contrato, la infraestructura dedicada a la relación con el proveedor, el servidor local a vosotros mismos.

Las competencias que quedan de vuestro lado

Un servidor en la empresa no es un ordenador encendido. Son actividades que alguien debe llevar a cabo con continuidad, y que no desaparecen cuando esa persona cambia de trabajo.

• Actualizaciones de sistema y de seguridad, con una ventana en la que se puedan hacer sin detener a nadie.
• Copias de seguridad de los datos y de las configuraciones, con al menos una restauración probada.
• Gestión de los accesos: quién puede usar el sistema, quién puede cambiar su comportamiento, quién lee los registros.
• Sustitución del hardware averiado, con los plazos que comporta conseguirlo.
• Actualización de los modelos, que no es automática ni indolora: lo que funcionaba puede comportarse de otra forma, y hay que volver a probarlo.

Si estas actividades recaen sobre una persona que ya tiene otras veinte, el sistema se quedará en la versión del día de la instalación. No es pesimismo: es el destino habitual de los servidores olvidados en un armario.

Contratos y flujos de datos

Con un servicio externo las garantías están en el contrato y en la documentación técnica, no en las páginas comerciales. Las cosas que hay que verificar por escrito son pocas y precisas.

• Dónde se tratan y se conservan los datos, y si esto puede cambiar sin previo aviso.
• Durante cuánto tiempo permanecen, y qué ocurre cuando cerráis el servicio.
• Si vuestros contenidos pueden usarse para entrenar modelos, y cómo se excluye.
• Quién, por parte del proveedor, puede acceder a ellos y en qué casos.
• Qué se registra de vuestros usos, y durante cuánto tiempo.

También hay que mirar la cadena: muchos servicios usan otros por debajo. Un proveedor que no sabe deciros de quién depende no os está necesariamente ocultando algo, pero tampoco puede garantizaros nada.

La prueba sobre el mismo caso de uso

La elección se cierra con una prueba, no con una comparación sobre el papel. La condición es que sea la misma tarea, con los mismos datos y el mismo rasero.

1. Elegid una tarea real y acotada, con documentos verdaderos, incluidos los difíciles.
2. Preparad un conjunto de ejemplos de los que ya conocéis la respuesta correcta. Sin esto, la comparación se queda en una impresión.
3. Probad cada opción sobre el mismo conjunto, midiendo calidad de las respuestas, tiempo de espera y comportamiento cuando falta la información.
4. Estimad el coste sobre un volumen realista de un año, no sobre el de la prueba: es aquí donde las opciones se separan de verdad.
5. Añadid a la cuenta las horas internas, las de la prueba y las del mantenimiento futuro.

Una prueba honesta dura pocas semanas y puede concluir con «ninguna de las tres, el problema no es de modelo». Es un resultado tan útil como los demás.

«Local» no significa seguro

La equivalencia entre datos en casa y datos protegidos es el atajo que lleva a las compras equivocadas.

La elección tampoco es obligatoriamente única. Una división frecuente y sensata mantiene dentro los documentos más sensibles, con un sistema local que los busca, y envía al exterior las tareas que no requieren datos confidenciales. El coste de esta solución es la complejidad: dos sistemas que mantener y una regla sobre qué puede pasar de uno al otro. Si la regla no se escribe en tres líneas comprensibles para quien usará el sistema, se sorteará.

Lo que esta guía no cubre

Aquí se elige dónde hacer funcionar un sistema basado en modelos, partiendo de las limitaciones. Las partidas de coste recurrente de un asistente ya en funcionamiento —consumos ligados al uso, revisión de las respuestas, actualizaciones— se tratan aparte, igual que la gestión de permisos, registros y copias de seguridad de un sistema de gestión empresarial, aquí solo esbozada.