Cuando un sistema basado en un modelo lingüístico grande (LLM) empieza a manejar datos reales o a tomar decisiones de impacto, la frase «funciona la mayoría de las veces» deja de ser un criterio aceptable. Un artículo de Stack Overflow Blog propone, dentro del nivel cuatro de un modelo de madurez para sistemas LLM, incorporar la seguridad y la gobernanza en la propia arquitectura mediante cuatro prácticas interrelacionadas: múltiples salvaguardas, control de los datos personales en cada límite del sistema, un registro de auditoría a prueba de manipulaciones y una memoria con un alcance claramente restringido.
Múltiples salvaguardas, no un único punto de protección
El artículo critica conformarse con un solo filtro para las salidas del modelo y propone convertir cada salvaguarda en un pequeño contrato de software que pueda probarse y ordenarse de manera independiente. Las solicitudes pasan por capas que examinan la entrada y los intentos de inyección de instrucciones, las restricciones de fundamentación y el formato de las salidas, la depuración de los resultados para eliminar infracciones de políticas o datos personales, y después la validación de las reglas de negocio, el uso de un árbitro secundario para los casos que parecen correctos pero son erróneos y, finalmente, la estimación de la confianza y la determinación de si la decisión se ejecutará o necesitará una escalada humana.
La regla fundamental es «fallar deteniéndose»: si una salvaguarda falla o deja de estar disponible, la solicitud no debe continuar automáticamente. Asimismo, cada bloqueo debería registrarse como una señal operativa; un aumento repentino del indicador podría significar un ataque, una regresión de la versión o un fallo en el despliegue. El artículo subraya que las restricciones reales deben hacer que las salidas no permitidas sean imposibles de representar, en lugar de limitarse a instrucciones textuales que el modelo pueda eludir.
Los datos personales se tratan en los límites
Cada transición entre componentes del sistema representa un límite de seguridad: la entrada de datos, su envío al modelo, su escritura en los registros o en el libro de decisiones y su transferencia a otro servicio. El artículo recomienda una clasificación centralizada de la sensibilidad, considerando por defecto que los campos desconocidos son datos personales, y después eliminar, ocultar o segmentar los datos antes de que atraviesen cada límite.
En el registro de decisiones, no debería almacenarse la carga sensible completa para demostrar en qué se basó la decisión. La alternativa es un resumen depurado con un hash con clave mediante HMAC y una clave específica para cada inquilino. El artículo señala que utilizar SHA-256 convencional con datos de baja aleatoriedad, como una dirección de correo electrónico o un número de tarjeta, permite la adivinación inversa. También es necesario adoptar una representación JSON canónica y estable, como la especificación JCS, para que el rehachado produzca el mismo resultado.
Un registro de auditoría que demuestre la historia, en lugar de limitarse a conservar registros
El artículo distingue entre los registros operativos, que sirven para la depuración y pueden rotarse o estar desorganizados, y un libro de auditoría de solo anexado que registra cada decisión y su motivo. Este libro incluye el identificador de la decisión, el inquilino, los permisos, las versiones del modelo y del prompt, la decisión, la confianza y la ruta de enrutamiento, junto con un resumen depurado y entradas segmentadas.
Las correcciones no modifican el registro anterior, sino que crean una nueva entrada que apunta a la entrada que sustituye. Para detectar manipulaciones, las entradas se vinculan mediante una cadena de hashes, con verificación de la secuencia y de su integridad. Sin embargo, la cadena por sí sola no impide eliminar la cola ni reconstruir por completo el registro; por ello, el artículo propone firmar las entradas y publicar puntos de control periódicos en un almacenamiento externo. Además, el anexado debe ejecutarse bajo un bloqueo para impedir que dos operaciones de escritura simultáneas creen dos ramas de la cadena.
Memoria clasificada y una frontera entre lo que se entrega y lo que se adquiere
En los sistemas multiinquilino, la memoria se convierte en una cuestión de gobernanza de datos, no solo en una funcionalidad. El artículo propone categorías separadas, como el conocimiento compartido del inquilino, el espacio del agente, el contexto temporal del flujo de trabajo, el registro de auditoría, el conocimiento semántico y la conversación del usuario. Cada categoría debe tener un alcance de acceso, una política de sensibilidad y una clave de partición que se imponga en el propio almacén de datos, con la prohibición de cualquier lectura o escritura entre inquilinos y el aislamiento de la conversación de un usuario respecto de los agentes de toma de decisiones de otros usuarios.
El artículo también distingue entre los datos iniciales que entrega el equipo, como los prompts, las reglas, los conjuntos de pruebas y los datos de fundamentación, y los datos de ejecución que adquiere el sistema, como la memoria, las señales de desviación y el contexto de las sesiones. Los primeros deben estar controlados mediante versiones y no poder modificarse durante la ejecución, mientras que los segundos pueden depurarse dentro de un alcance definido sin eliminar el registro de auditoría. Cualquier comportamiento nuevo extraído de los datos de ejecución debería pasar por una revisión y pruebas antes de integrarse en una versión posterior; según el artículo, el aprendizaje debería parecerse más a una solicitud de cambio de software que a un efecto secundario imposible de rastrear.
¿Por qué son importantes estas prácticas?
El valor práctico de la propuesta no reside en una herramienta aislada, sino en distribuir la confianza entre capas independientes. La depuración de las salidas no sustituye la validación de las reglas de negocio, un registro de auditoría no justifica conservar los datos sin procesar y la memoria no se vuelve segura simplemente por utilizar una base de datos vectorial. Las restricciones abiertas que aún requieren una decisión de ingeniería son determinar las categorías de datos adecuadas para cada sistema, establecer las políticas de residencia y acceso, definir los casos que requieren revisión humana y demostrar que la depuración de la memoria no elimina entradas necesarias para tomar la decisión.