Seguridad de un LLM privado: controles y pruebas

La seguridad de un LLM privado empieza por el sistema que lo rodea. Identifique usuarios, administradores, aplicaciones, documentos, registros y herramientas conectadas. Para cada elemento describa el acceso permitido y el daño que produciría un uso indebido. Un usuario autorizado a preguntar al modelo no tiene por qué estar autorizado a consultar todos los documentos que puede recuperar la aplicación.

El modelo de amenazas debe contemplar errores internos, credenciales comprometidas, contenido externo malicioso y fallos de operación. No necesita imaginar todos los ataques posibles para ser útil: priorice los recorridos que existen realmente en la arquitectura. El mapa de datos permite identificar dónde se necesitan controles; la evaluación debe abarcar esas fronteras y no solo el endpoint de inferencia.

Prepare datos sintéticos y cuentas autorizadas para estas pruebas. Registre configuración, resultado esperado, resultado observado y fecha. Un control sin evidencia queda pendiente; una prueba fallida debe tener responsable y una decisión antes de producción.

La aplicación debe decidir qué puede consultar el usuario antes de enviar contexto al modelo. Pedirle al modelo que no muestre información de otro departamento es insuficiente si esa información ya se ha incluido en su entrada. Los permisos deben aplicarse en la recuperación y en las herramientas, utilizando la identidad de quien realiza la petición y el alcance de la operación.

OWASP describe la inyección de instrucciones como un riesgo que puede proceder de entradas directas o contenido que procesa el sistema. En un entorno empresarial, un documento debe tratarse como información, no como una nueva autoridad para conceder acceso. Reduzca las capacidades de las herramientas y exija aprobación fuera del modelo para acciones sensibles.

La salida del modelo es una entrada para el siguiente componente. Si debe producir campos estructurados, valide el esquema y los valores permitidos antes de guardarlos. Si produce texto que se muestra en una web, el renderizado debe tratarlo como contenido no confiable. Si sugiere una acción, la aplicación debe volver a comprobar permisos y condiciones de negocio.

Ejemplo ilustrativo: un clasificador de solicitudes devuelve una categoría fuera del catálogo. El comportamiento seguro es marcar la tarea para revisión, no crear automáticamente una nueva categoría con efectos en el proceso. Registre el fallo sin conservar información innecesaria. La guía del piloto propone incluir casos inválidos y de ausencia de datos, además de ejemplos favorables.

Envíe al modelo solo los datos que necesita la tarea. Separar identificadores de contenido o sustituir datos por ejemplos sintéticos durante pruebas puede reducir exposición. Examine también errores, trazas y herramientas de soporte: una excepción que imprime el prompt completo puede ampliar el acceso más que el propio motor. Defina qué se registra y quién puede leerlo.

La referencia de OWASP sobre divulgación de información sensible señala que las restricciones en instrucciones pueden ser eludidas. Por eso el control debe combinar minimización, permisos y validación de resultados. No introduzca contraseñas en el prompt del sistema ni trate ese texto como un almacén de secretos.

Una petición autorizada puede consumir recursos de forma desproporcionada. Limite entrada, salida, concurrencia y duración según el servicio. Defina colas y respuestas de saturación para que un lote no bloquee todos los usuarios interactivos. Compruebe que las métricas permiten distinguir saturación, error del modelo y fallo de una dependencia.

Controle el origen y versión de modelos, contenedores y bibliotecas. Conserve una configuración reproducible y un procedimiento de reversión. Repita las pruebas afectadas tras un cambio de modelo, motor, permisos o herramientas. El plan de operación debe asignar responsables para incidencias, parches y recuperación, en lugar de dejar esos trabajos implícitos.

Entregue un inventario de componentes, fronteras de confianza, controles, pruebas, fallos corregidos y riesgos aceptados. Distinga una observación puntual de una garantía contractual. Indique qué cambios invalidan las pruebas y quién debe revisarlas. Una evaluación es útil cuando otra persona puede reconstruir por qué se permitió el uso del sistema.

La matriz de contratación permite pedir estas evidencias al proveedor. En el servicio de inferencia privada, los controles y las pruebas se concretan para el alcance del proyecto. El despliegue privado no equivale a inmunidad frente a ataques ni a cumplimiento automático de una norma.