Defina qué debe permanecer privado
«IA privada» puede significar cosas distintas. Una organización necesita que sus documentos no salgan de su red. Otra quiere límites sobre entrenamiento con entradas, control de registros o independencia del proveedor. Esos objetivos no se pueden sustituir por una sola etiqueta. Dibuje el recorrido de los datos: de dónde llega la pregunta, qué documentos se buscan, dónde se guarda el historial y quién ve la información de diagnóstico. Después podrá comparar opciones concretas.
Poseer un servidor no crea automáticamente un sistema seguro. Si la aplicación entrega documentos al modelo sin comprobar permisos, la información puede filtrarse dentro de la propia organización. Una API externa puede ofrecer garantías contractuales y técnicas que deben comprobarse para ese proveedor; no existe una afirmación universal sobre privacidad de todas las API. Pregunte quién procesa los datos, cuánto tiempo se conservan, cómo se borran y quién cambia la configuración. La decisión depende de pruebas, no del nombre comercial.
Especifique la tarea del modelo
Comparar modelos sin una tarea se parece a elegir una base de datos por el color de su consola. Reúna casos representativos: preguntas sobre documentos internos, clasificación de solicitudes, propuestas de respuesta o extracción de formularios. Cada caso necesita resultado esperado, tolerancia al error y decisión sobre revisión humana. El riesgo de un texto para clientes difiere de un borrador interno. Incluya situaciones donde la respuesta correcta es «no lo sé» y donde falta una fuente pertinente.
La evaluación debe contener los idiomas reales del producto. Un modelo convincente en inglés puede manejar mal terminología checa o española. Evite poner secretos en entornos de prueba sin verificar; use ejemplos anonimizados. La primera colección no tiene que ser enorme, pero debe cubrir casos habituales y difíciles. Separe los ejemplos para ajustar el sistema de los empleados en la evaluación final. De lo contrario se optimiza para las mismas preguntas con las que luego se anuncia el resultado.
Compare opciones con el mismo criterio
Prepare una matriz sencilla con tres columnas: infraestructura propia, alojamiento aislado y API externa. Para cada una registre frontera de datos, calidad sobre las mismas pruebas, latencia con carga normal y máxima, trabajo operativo, control de cambios y coste total. No deje que una opción destaque solo por recibir mejores instrucciones o documentos recientes. Cambie una variable importante cada vez y conserve las versiones de modelo, instrucciones, fuentes y entorno de cálculo con cada resultado.
La matriz no tiene por qué señalar un ganador para todas las tareas. Resumir documentos internos sensibles quizá exija más control que redactar texto público. Algunas tareas ni siquiera requieren un modelo: la búsqueda o automatización por reglas puede ser más barata y previsible. No es un fracaso del piloto. La comparación debe mostrar dónde el modelo ofrece valor medible, dónde conviene otro método y qué supuestos siguen sin pruebas.
El rendimiento no es una respuesta de demostración
La inferencia propia requiere memoria para pesos, datos de trabajo y peticiones simultáneas. Las longitudes de entrada y salida afectan a latencia y consumo. Cuantizar puede reducir memoria, pero no acelera gratis: un método concreto puede cambiar calidad o rendimiento. Hugging Face documenta enfoques diferentes. Pruébelos con sus tareas y no decida por el nombre del modelo o una sola cifra de benchmark.
Mida tráfico normal, picos y documentos largos. Observe tiempo hasta la primera parte de respuesta, duración total, solicitudes fallidas y coste por tarea completada. Una respuesta lenta puede aceptarse si mejora la calidad; en otro flujo la espera será el obstáculo principal. Incluya reinicio, servidor de modelo inaccesible y cola llena en el ensayo. Una cifra de laboratorio para una consulta en un equipo vacío no describe el servicio real.
El coste incluye capacidad ociosa y personas
Para alojamiento propio cuente equipos o alquiler, energía, almacenamiento, red, copias, actualizaciones, vigilancia y tiempo de personal. Calcule volumen esperado y un pico realista. Si la demanda llega a intervalos, el servidor ocioso puede costar más que llamadas individuales a una API. Con uso alto y estable, una capacidad dedicada podría tener sentido económico. Ninguna conclusión es válida sin carga concreta y mediciones.
Para una API incluya precio de tokens de entrada y salida, servicios auxiliares, límites y costes de integración. Las tarifas cambian; compruébelas con el proveedor al decidir y deje reserva. Compare coste por tarea resuelta, no solo por millar de tokens. Una llamada más cara puede salir más barata si requiere menos correcciones, y también al revés. Añada revisión humana para trabajos con consecuencias. Un precio unitario atractivo no equivale a un presupuesto operativo viable.
La seguridad no termina en la ubicación del modelo
OWASP señala el riesgo de divulgar información sensible en la salida. Por ello, los permisos deben aplicarse al recuperar documentos, componer el contexto y mostrar la respuesta. No guarde automáticamente conversaciones completas en registros sin finalidad y acceso controlado. Diagnósticos, copias y datos de prueba pueden cambiar la verdadera frontera de información. Un servidor propio no protege un documento que la aplicación enseña a la persona equivocada.
Otro problema son las instrucciones escondidas en fuentes. Un documento recuperado o correo entrante puede contener texto destinado a manipular el modelo. OWASP describe la inyección de instrucciones como un riesgo que RAG por sí mismo no elimina. Si la IA puede usar herramientas, la aplicación debe verificar permisos y parámetros de cada acción al margen de lo que diga el modelo. Incluya entradas erróneas y maliciosas en el piloto. La protección afecta al flujo completo, no a una frase del prompt.
Cambiar el modelo significa cambiar el producto
Una versión nueva puede modificar estilo, precisión y forma de rechazar respuestas. También cambian los resultados al actualizar servidor de inferencia, documentos o instrucciones. Pruebe cada cambio relevante con una colección estable de regresión y compárelo con la versión anterior. Registre quién aprobó el paso y cómo volver atrás. En alojamiento propio vigile licencias y procedencia del modelo. Con una API siga la disponibilidad de la versión concreta y el proceso de cambios del proveedor.
La vigilancia operativa debe incluir latencia, errores, capacidad y calidad de resultados reales. El marco de riesgos de IA de NIST entiende la gestión como trabajo continuo, no una prueba única antes de publicar. Dé a los usuarios una forma sencilla de comunicar una respuesta errónea. Cuando se repita un patrón, determine si la causa está en la fuente, el modelo, los permisos o el diseño de la tarea. Cambiar a un modelo más grande no es una cura automática.
Prepare el fallo y la vuelta atrás
¿Qué ocurre si el modelo no responde? Ciertos trabajos pueden esperar en cola; otros necesitan un camino manual inmediato. La interfaz debe distinguir procesamiento, fallo y resultado que requiere revisión. El alojamiento propio añade recuperación de servidores y archivos del modelo; una API externa añade dependencia de red y proveedor. Ambos necesitan límites de tiempo, reintentos acotados y una regla para trasladar el trabajo a una persona.
Antes del piloto anote condiciones para detenerlo o cambiar de opción: tasa de errores, latencia, coste o control de datos sin demostrar. Sin un límite de decisión, el equipo puede ajustar el sistema indefinidamente. Termine la prueba comparando resultados medidos, riesgos abiertos y pasos siguientes. La IA privada sirve cuando una tarea concreta obtiene control y calidad necesarios con un coste total proporcionado. No es un fin por sí sola.