Centro de Confianza

Para entender por qué tiene sentido usar nuestros servicios, primero hay que responder una pregunta necesaria: ¿a qué nos referimos cuando hablamos de ciberseguridad en los LLM? En términos simples, nos referimos a la investigación de los modos de falla que pueden tener los LLM durante su uso en producción, las condiciones que llevan a esas fallas, y sus posibles mitigaciones.

Los modelos de lenguaje grandes tienen una probabilidad alta de no comportarse como se espera, de muchas formas distintas — lo que los vuelve inseguros cuando se usan sin los resguardos necesarios. Además, necesitan correr sobre software como PyTorch, ONNX o CUDA, que puede tener sus propias vulnerabilidades. Y la forma en que se implementan los LLM y se usan sus resultados agrega una tercera capa de riesgo: cuando un modelo se comporta de forma inesperada, ese comportamiento en sí mismo se convierte en un riesgo de seguridad.

La seguridad de LLM es un campo mucho más amplio e inexplorado de lo que cubre hoy, por separado, el conocimiento tradicional de seguridad de la información o el de LLM/NLP. Es la unión de ambos: todo lo que ya sabemos sobre seguridad de la información, sumado a todo lo que ya sabemos sobre procesamiento del lenguaje natural.

Existen decenas de herramientas open-source para testear la seguridad de un LLM — las mismas que usamos nosotros: PyRIT, garak, promptfoo, entre otras. Cualquier equipo las puede descargar y correr. El problema no es conseguirlas: es que cada una habla un lenguaje distinto, devuelve resultados en formatos distintos, y ninguna te dice qué significa un hallazgo de garak cruzado con uno de PyRIT, ni si ese hallazgo alcanza para mostrarle a un auditor que tu agente cumple con NIST AI RMF.

Correr una herramienta contra tu modelo te da una lista de warnings en una terminal. No te da un equipo que sepa priorizar cuáles importan, que vuelva a correr el mismo plan de ataque después de cada cambio de modelo o de prompt, que traduzca cada hallazgo en un guardrail activo en producción, o que lo mapee automáticamente a los marcos normativos que un cliente o un regulador te va a terminar pidiendo.

Por eso Vapi no es una caja de herramientas: es el equipo que las opera por vos, cruza los hallazgos entre motores, y los convierte en evidencia lista para auditoría. Las herramientas open-source son el punto de partida de cualquier ejercicio serio de seguridad en IA — nuestro trabajo empieza donde termina la salida de una terminal.

Ese trabajo tampoco se congela el día que lo entregamos: las técnicas de ataque cambian todo el tiempo — nuevos jailbreaks, nuevos métodos de fine-tuning adversarial, nuevas arquitecturas de modelo — y nuestra batería de pruebas se actualiza al mismo ritmo. Un toolkit que descargás una vez queda fijo en la versión del día que salió; nuestros engines se revisan, se suman y se afinan de forma constante, así que lo que probamos hoy sigue siendo relevante contra lo que va a intentar un atacante el mes que viene.

Un detector automático puede marcar como "vulnerable" que un modelo haya generado, por ejemplo, contenido ofensivo a partir de un prompt en ASCII art o un mensaje escondido con esteganografía — probes reales que corren motores como garak. Pero esa alarma solo tiene sentido si antes existe una política que defina qué es lo que el modelo no debería hacer. Sin esa política no hay modo de fallo que evaluar: el modelo no "falló" nada, porque nunca se definió qué contaba como éxito.

Generar contenido adversarial sin política no es, por sí solo, un problema de seguridad — es simplemente mala forma. Confundir las dos cosas es exactamente lo que produce falsos positivos: un hallazgo que se ve grave en un reporte automático pero que, cruzado contra la política real de uso del agente, no representa ningún riesgo. Nuestro equipo revisa cada hallazgo contra la política del cliente antes de reportarlo como vulnerabilidad — no reenviamos la salida cruda de un detector.

Y esa política tampoco es estática: cambia con cada versión del modelo, cada prompt nuevo, cada caso de uso que se agrega. Por eso pensamos la seguridad de los LLM como un red-teaming continuo sobre esa política, y no como una auditoría puntual — cada vez que algo cambia, volvemos a preguntarnos qué cuenta realmente como modo de fallo antes de volver a testear.