La diferencia entre la seguridad de la IA y la protecci\u00f3n de la IA es f\u00e1cil de difuminar hasta que una llamada al modelo puede afectar a un cliente, ticket, documento, transacci\u00f3n o flujo de trabajo de un agente. En ese punto, la distinci\u00f3n importa.<\/p>\n\n\n\n
La seguridad de la IA pregunta si el sistema se comporta de maneras \u00fatiles, confiables y alineadas con el trabajo que se supone que debe hacer. La protecci\u00f3n de la IA pregunta si el sistema, sus datos, sus herramientas o sus rutas de acceso pueden ser atacados o mal utilizados. Los equipos de producci\u00f3n necesitan ambos, porque un modelo seguro a\u00fan puede ser explotado, y una integraci\u00f3n protegida a\u00fan puede producir resultados da\u00f1inos o poco confiables.<\/p>\n\n\n\n
Para los constructores que trabajan con APIs de modelos, el punto de control pr\u00e1ctico suele ser la propia llamada al modelo: qu\u00e9 modelo se selecciona, qu\u00e9 solicitud se env\u00eda, qu\u00e9 herramientas est\u00e1n permitidas, qu\u00e9 datos se adjuntan, qu\u00e9 se registra, qu\u00e9 ruta alternativa est\u00e1 disponible y qu\u00e9 ve el usuario cuando se devuelve la respuesta.<\/p>\n\n\n\n
La seguridad de la IA trata sobre el comportamiento y los resultados de un sistema de IA. La pregunta central es: \u00bfdeber\u00eda el sistema comportarse de esta manera para este usuario, tarea y contexto?<\/p>\n\n\n\n
El trabajo de seguridad a menudo cubre la calidad de salida, contenido da\u00f1ino, sesgo, alucinaciones, comportamiento de rechazo, robustez, evaluaci\u00f3n y supervisi\u00f3n humana. Tambi\u00e9n incluye la pregunta operativa que cada equipo de producto eventualmente enfrenta: \u00bfqu\u00e9 sucede cuando el modelo est\u00e1 incierto, equivocado, incompleto o se le pide hacer algo fuera de su alcance previsto?<\/p>\n\n\n\n
Que el Marco de Gesti\u00f3n de Riesgos de IA de NIST<\/a> es \u00fatil aqu\u00ed porque trata el riesgo de la IA como algo que los equipos deben gobernar, mapear, medir y gestionar, no como una decisi\u00f3n \u00fanica de selecci\u00f3n de modelo. Ese marco es especialmente importante cuando un producto dirige el trabajo a trav\u00e9s de varios modelos o proveedores.<\/p>\n\n\n\n La protecci\u00f3n de la IA trata sobre proteger la integraci\u00f3n del modelo contra ataques, acceso no autorizado, exposici\u00f3n de datos y abuso. La pregunta central es: \u00bfpuede alguien explotar este sistema, su solicitud, sus herramientas, sus fuentes de recuperaci\u00f3n o sus permisos?<\/p>\n\n\n\n El trabajo de protecci\u00f3n a menudo cubre la inyecci\u00f3n de solicitudes, divulgaci\u00f3n de informaci\u00f3n sensible, envenenamiento de datos de entrenamiento o recuperaci\u00f3n, riesgo en la cadena de suministro del modelo, permisos excesivos de herramientas, denegaci\u00f3n de servicio, filtraci\u00f3n de credenciales y dise\u00f1o inseguro de complementos o agentes. OWASP Top 10 para Aplicaciones de Modelos de Lenguaje Grande<\/a> es una referencia \u00fatil porque nombra muchos de los modos de falla que aparecen una vez que los LLMs est\u00e1n integrados en software real.<\/p>\n\n\n\n La protecci\u00f3n no es solo un problema del proveedor del modelo. Los constructores a\u00fan necesitan proteger las claves de API, autenticar usuarios, delimitar permisos de espacio de trabajo, filtrar fuentes de recuperaci\u00f3n, controlar herramientas de agentes y monitorear patrones de uso anormales. Un proveedor puede proteger su propia infraestructura mientras tu aplicaci\u00f3n a\u00fan expone acceso arriesgado a herramientas o datos de usuario.<\/p>\n\n\n\n La superposici\u00f3n es donde ocurren muchas fallas de producci\u00f3n. La inyecci\u00f3n de indicaciones es un problema de seguridad cuando manipula instrucciones o acceso a datos, pero puede convertirse en un problema de seguridad cuando la respuesta manipulada llega a un usuario. Un agente con permisos amplios es una preocupaci\u00f3n de seguridad, pero sus acciones pueden crear riesgos de seguridad y negocios si el modelo toma una decisi\u00f3n poco confiable.<\/p>\n\n\n\n Muchos equipos comienzan con un solo modelo, una sola clave API y una sola indicaci\u00f3n. Eso puede funcionar para un prototipo. Se vuelve fr\u00e1gil cuando el producto agrega m\u00faltiples modelos, configuraciones espec\u00edficas del cliente, herramientas de agentes, recuperaci\u00f3n, enrutamiento de respaldo, controles de costos o facturaci\u00f3n basada en uso.<\/p>\n\n\n\n Una capa de control de llamadas al modelo brinda a los Constructores un lugar consistente para aplicar decisiones antes y despu\u00e9s de la inferencia. Puede ayudar a responder preguntas como:<\/p>\n\n\n\nControles de Protecci\u00f3n de la IA sobre el Riesgo de Explotaci\u00f3n<\/h2>\n\n\n\n
Seguridad vs Protecci\u00f3n: La Diferencia Pr\u00e1ctica<\/h2>\n\n\n\n
\u00c1rea<\/th> Seguridad de la IA<\/th> Protecci\u00f3n de la IA<\/th><\/tr><\/thead> Pregunta principal<\/td> \u00bfDeber\u00eda el sistema producir este comportamiento?<\/td> \u00bfPuede alguien explotar este sistema?<\/td><\/tr> Riesgo t\u00edpico<\/td> Resultados da\u00f1inos, sesgados, poco fiables o enga\u00f1osos<\/td> Inyecci\u00f3n de instrucciones, exposici\u00f3n de datos, abuso o acceso no autorizado<\/td><\/tr> Controles primarios<\/td> Evaluaciones, medidas de protecci\u00f3n, revisi\u00f3n humana, elecci\u00f3n de modelo, pol\u00edticas de salida<\/td> Autenticaci\u00f3n, permisos, controles de entrada, gesti\u00f3n de secretos, aislamiento de herramientas<\/td><\/tr> Ejemplo de fallo<\/td> Un asistente de soporte da orientaci\u00f3n insegura sobre reembolsos<\/td> Un mensaje malicioso enga\u00f1a a un agente para que exponga datos privados de tickets<\/td><\/tr> Superposici\u00f3n de propietario<\/td> Producto, pol\u00edtica, ingenier\u00eda, legal, expertos en dominios<\/td> Seguridad, plataforma, ingenier\u00eda, operaciones<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Por qu\u00e9 las llamadas al modelo necesitan su propia capa de control<\/h2>\n\n\n\n