Seguridad de la IA es, sobre todo, diseño de sistemas.
La reunión de seguridad después de la demo
La demo había ido bien, como de costumbre. El modelo leyó una pila de documentos internos, respondió a una pregunta sobre políticas, sugirió un siguiente paso y elaboró un resumen ordenado para el expediente del caso. La sala asintió. Alguien preguntó si se podía conectar al sistema de flujo de trabajo. Otro preguntó cuánto tardaría. Entonces el responsable de seguridad preguntó qué pasaría si el modelo se equivocara pero resultara convincente. La sala se interesó mucho por las galletas.
Esa pregunta es donde empieza la seguridad práctica de la IA. No en lo abstracto, ni en un eslogan. En la forma del sistema que rodea a un modelo que a veces se equivocará, a veces estará desactualizado, a veces será demasiado confiado, a veces poco confiado y a veces acertará por razones equivocadas. El problema de seguridad no es solo el comportamiento del modelo. Es lo que el sistema permite que ese comportamiento haga.
Un modelo que redacta una frase es un riesgo. Un modelo que actualiza una decisión de prestaciones es otro. Un modelo que llama a una herramienta con acceso de escritura es otro. Un modelo que deriva a un paciente, rechaza una reclamación, cambia un límite de crédito o controla equipos se sitúa en una clase de peligro completamente distinta. El mismo modelo subyacente puede ser inofensivo, útil, arriesgado o inaceptable según los límites, el estado, las pruebas, la autoridad, la supervisión y la recuperación. Por eso la seguridad de la IA es, sobre todo, diseño de sistemas.
«Sobre todo» hace un trabajo importante en esa frase. La investigación sobre modelos importa. La calidad de los datos importa. Los métodos de alineación importan. La ciencia de la evaluación importa. Pero cuando una organización despliega IA, la seguridad se vuelve operativa. Quién puede preguntar. Qué puede ver el modelo. Qué puede cambiar. Qué pruebas se exigen. Qué estado se conserva. Qué ocurre cuando las fuentes discrepan. Cuándo debe aprobar un humano. Cómo se detecta la deriva. Cómo se revierte un lanzamiento defectuoso. Estas son preguntas de diseño antes que declaraciones éticas. La declaración ética puede ser sincera. El sistema no ejecuta la sinceridad.
La seguridad es un problema de control
Cuando la gente oye «seguridad», suele pensar en valores, datos de entrenamiento, políticas de rechazo y alineación del modelo. Todo eso forma parte del panorama, pero un sistema desplegado también necesita controles. Un control es algo que cambia lo que puede ocurrir: una comprobación de acceso, un esquema, un tiempo de espera, un umbral, una aprobación humana, un entorno aislado, un límite de velocidad, un verificador, una reversión, un interruptor de apagado, un registro que la ruta de servicio no pueda editar. Los controles son aburridos hasta que faltan. Entonces se convierten en el tema de toda la reunión.
Un sistema de IA seguro asume que el modelo puede fallar y diseña la maquinaria que lo rodea en consecuencia. Separa la sugerencia de la acción. Limita la autoridad de las herramientas. Comprueba las pruebas antes de cambiar de estado. Hace visible la incertidumbre. Registra la versión del modelo y el alcance de las fuentes. Se niega cuando faltan campos obligatorios. Da a los operadores una forma de pausar la automatización. Trata la salida del modelo como un candidato, no como un decreto de una hoja de cálculo muy elocuente.
Esto es ingeniería de seguridad ordinaria con un modelo de lenguaje en el centro. La aviación, la medicina, el ferrocarril, el control industrial y las finanzas han aprendido que los sistemas importantes necesitan controles en capas porque ningún componente es perfecto. La versión con IA parece nueva porque el componente habla. El habla hace que el fallo sea socialmente persuasivo. Una respuesta incorrecta que suena tranquila puede pasar desapercibida para un operador cansado con más facilidad que un error rojo parpadeante. Por tanto, el diseño de control debe ser más obstinado que la prosa.
El diseño de control empieza por preguntarse qué se le permite afectar al sistema. Si la IA solo puede redactar, la seguridad se centra en la calidad de las fuentes, la comprobación de alucinaciones, la claridad de la interfaz de usuario y la revisión. Si puede enrutar trabajo, la seguridad añade seguimiento de estado, integridad de colas, niveles de servicio y vías de apelación. Si puede llamar a herramientas, la seguridad añade ámbitos de permiso, validación de argumentos, registros de transacciones y acciones compensatorias. Si puede afectar a derechos o sistemas físicos, la seguridad exige pruebas, revisión formal, autonomía restringida y una planificación seria de incidentes. El modelo es una parte. El perímetro de autoridad es la otra.
El límite es el producto
La línea más importante de un sistema de IA a menudo no es visible en la interfaz. Es el límite entre leer y escribir, recomendar y decidir, resumir y registrar, asistir y actuar. Los límites débiles son cómo los prototipos inofensivos se convierten en servicios inseguros. Un modelo que empieza como ayuda para redactar recibe un botón para aplicar el borrador. Luego recibe una herramienta para actualizar el caso. Luego recibe una regla de enrutamiento porque el equipo está ocupado. Seis meses después, nadie puede explicar qué decisiones están automatizadas y cuáles son meramente asistidas. Esto no es malicia. Es una expansión del alcance con zapatos cómodos.
Los buenos límites son explícitos e inspeccionables. El modelo puede leer estas fuentes, no aquellas. Puede proponer estos campos, no confirmarlos. Puede llamar a esta herramienta con estos argumentos, no con texto arbitrario. Puede enrutar casos de bajo riesgo, no casos impugnados. Solo puede responder cuando las pruebas están actualizadas. No puede usar notas privadas para explicaciones públicas. No puede cruzar de un inquilino, región, cuenta o base jurídica a otra porque el siguiente párrafo parecía útil.
Los límites también deben aplicarse fuera del modelo. Un prompt que dice no escribir en la base de datos de clientes no es un límite si la herramienta tiene acceso de escritura y no hay pasarela. Un mensaje del sistema que dice citar fuentes no es un límite si las respuestas pueden almacenarse sin citas. Un párrafo de política que dice que se requiere aprobación humana no es un límite si el flujo de trabajo permite que la automatización marque como aprobado. Las instrucciones de seguridad dentro del modelo son útiles, pero no son suficientes. El sistema tiene que hacer que los caminos inseguros sean difíciles o imposibles.
Este es el trabajo poco romántico que realmente protege a las personas. Llamadas a herramientas tipadas. Ámbitos estrechos. Valores predeterminados de solo lectura. Servicios de aprobación separados. Operaciones idempotentes. Registros de auditoría. Políticas versionadas. Estados de cola. Estados de rechazo explícitos. El vocabulario suena como si un ingeniero de backend hubiera pasado un fin de semana tranquilo con un portapapeles. Bien. La seguridad en producción suele tener ese aspecto. No intenta ganar un concurso de eslóganes.
El estado es donde la seguridad se vuelve real
Las conversaciones con IA pueden hacer que los sistemas parezcan sin estado. Un usuario pregunta, un modelo responde, la pantalla cambia. La producción no es sin estado. Los casos avanzan. Los tickets envejecen. Los permisos caducan. Los documentos se corrigen. Una versión del modelo cambia. Una persona anula una recomendación. Llega una apelación. Un usuario pregunta por qué ocurrió algo el mes pasado. La seguridad depende de si el sistema conservó el estado necesario para responder.
El estado le dice al sistema qué ha ocurrido ya y qué puede ocurrir después. Sin él, el modelo ve un fragmento y adivina el resto. Así es como ocurren acciones duplicadas, los plazos desaparecen, se asumen aprobaciones y la evidencia antigua vuelve a entrar en una decisión nueva. Un flujo de trabajo seguro registra estados explícitos: borrador, evidencia faltante, política bloqueada, revisión requerida, aprobado, ejecutado, impugnado, corregido, retirado. Estos estados no son decorativos. Evitan que el modelo trate un proceso con consecuencias como si fuera una transcripción de chat con ambiciones.
El estado también da ventaja a las personas. Un operador puede inspeccionar por qué un caso está en revisión. Un gestor puede ver si la automatización está creando un atasco. Un auditor puede reproducir qué versiones de fuentes estaban activas. Un usuario puede impugnar un resultado con algo más sólido que una captura de pantalla. Un desarrollador puede medir si un modelo nuevo aumenta los rechazos, las escalaciones o el retrabajo. Sin estado, toda conversación sobre seguridad se convierte en teatro. La gente habla de responsabilidad, pero el sistema ha extraviado los sustantivos.
Para la IA, el estado debería incluir la versión del modelo y de la política, el identificador de la plantilla o del prompt, el conjunto de fuentes, la marca de tiempo de la recuperación, las llamadas a herramientas, la confianza o incertidumbre, el motivo del rechazo, la acción humana y el efecto posterior. No todo eso pertenece a una sola línea de registro, y no todo debería ser visible para todos. La privacidad y la seguridad importan. Pero la información debe existir bajo acceso controlado. De lo contrario, la seguridad depende de la memoria, y la memoria es una base de datos famosamente mala con excelentes excusas.
La evidencia es la barandilla de seguridad
Una respuesta de un modelo es más segura cuando está conectada a la evidencia. Eso parece obvio hasta que el sistema está bajo presión. La evidencia se omite porque añade latencia. Las citas se guardan como texto en lugar de identificadores. Las puntuaciones de recuperación no se conservan. Las versiones de las fuentes se sobrescriben. El modelo escribe una explicación segura a partir de un documento que desde entonces se ha corregido. Después, todos preguntan por qué la respuesta era incorrecta. La respuesta es que la barandilla era decorativa.
La evidencia útil no es una nota al pie. Es una cadena. La solicitud entró con una identidad y un propósito. Las fuentes se seleccionaron con permiso. La recuperación encontró fragmentos o registros concretos. El modelo produjo una salida bajo una versión con nombre. Un verificador comprobó afirmaciones o umbrales. Una persona aceptó, editó o rechazó. La acción cambió el estado. El sistema almacenó suficiente de esa cadena para reproducirla o cuestionarla. Esto no es burocracia por la burocracia. Es así como la seguridad sobrevive al tiempo.
La evidencia también protege al modelo de que se le pida hacer un trabajo imposible. Si el sistema exige fuentes actuales, el modelo puede rechazar una entrada obsoleta. Si el sistema exige dos registros coincidentes, puede señalar la discrepancia. Si el sistema exige identificadores de fuente, puede detener afirmaciones sin respaldo. El modelo ya no tiene que convertir la falta de pruebas en una gestión fluida de la incertidumbre. Puede devolver un estado seguro. Esto es más amable con el modelo y mucho más amable con la persona afectada por la salida.
Hay un equilibrio. La captura de evidencia no debe convertirse en vigilancia. El contenido sensible puede cifrarse, redactarse, separarse o conservarse durante periodos limitados. La cuestión no es registrarlo todo para siempre. La cuestión es conservar los hechos necesarios para inspeccionar un comportamiento importante. La seguridad sin evidencia es solo confianza con una chaqueta más bonita. Puede tener buen aspecto en el vestíbulo. No aguanta en un incidente.
Las personas necesitan autoridad diseñada
Human in the loop se usa a menudo como una frase mágica. No es magia. Un revisor cansado con poca evidencia, una política poco clara y una cola de doscientos casos no es un sistema de seguridad. Es una persona colocada al final de una cinta transportadora a la que se pide que ejerza de gobernanza. Puede funcionar brevemente, sobre todo si la persona es experimentada y obstinada. No es un diseño.
La autoridad humana tiene que ser específica. Qué casos requieren revisión. Qué evidencia ve el revisor. Puede el revisor cambiar campos estructurados o solo aprobar prosa. Sabe el revisor si el modelo estaba inseguro o si la política exigía escalar. Se retroalimentan los desacuerdos en la evaluación. Están protegidos los revisores del sesgo de automatización. Pueden pausar un flujo de trabajo. Pueden escalar a un especialista. Pueden ver casos similares anteriores. Pueden explicar una decisión a la persona afectada. Estos detalles deciden si la supervisión humana es real u ornamental.
Una buena supervisión también separa el juicio de la limpieza administrativa. Las personas no deberían dedicar su tiempo a localizar identificadores de origen que faltan, a deduplicar reintentos, a traducir el texto del modelo a estados de flujo de trabajo o a adivinar qué versión de la política se aplicó. El sistema debería empaquetar el caso. La persona debería aplicar el juicio donde se necesita: significado en disputa, excepción, proporcionalidad, contexto, empatía y responsabilidad. Si la persona dedica la mayor parte del tiempo a tapar huecos de infraestructura, la organización ha confundido la dotación de personal con la seguridad.
El diseño también debe permitir que las personas discrepen de la automatización sin que la fricción se convierta en un castigo. Si anular el modelo requiere ocho clics y aceptarlo requiere uno, la interfaz tiene una política. Si escalar hace que un equipo parezca lento, las personas evitarán escalar. Si las métricas solo recompensan el rendimiento, las revisiones de seguridad se convertirán en una ceremonia. El diseño de sistemas incluye incentivos, pantallas, colas y valores predeterminados. El modelo puede no conocer la métrica, pero las personas seguro que sí.
La localidad cambia el riesgo
Importa dónde ocurre el trabajo de IA. Un sistema que envía cada documento a un modelo remoto tiene riesgos distintos de uno que realiza la extracción cerca de los datos y envía solo un campo derivado. Un sistema que almacena las trazas en el servicio de entrega tiene riesgos distintos de uno que mantiene registros de auditoría independientes. Un sistema que depende de un único enrutador externo tiene opciones de recuperación distintas de uno que puede degradarse localmente. La localidad no es nacionalismo con un diagrama de red. Es la cuestión práctica de qué riesgos se mueven cuando se mueven los datos, la computación, la política y las pruebas.
Parte del trabajo debería ocurrir cerca de los datos sensibles porque mover los datos crea exposición. Parte del trabajo debería ocurrir cerca de los usuarios porque la latencia afecta a la seguridad. Parte del trabajo debería ocurrir en un servicio central porque se necesita una revisión especializada o hardware. Parte de las pruebas debería almacenarse fuera de la ruta de entrega del modelo porque la ruta de entrega puede ser lo que se está investigando. El diseño seguro rara vez es todo local o todo remoto. Es una colocación deliberada.
La localidad también afecta a la responsabilidad legal y organizativa. Si una llamada al modelo cruza regiones, qué ley rige los datos. Si un índice se construye fuera del sistema de origen, cómo se propagan las eliminaciones. Si un proveedor cambia un modelo, cómo se recibe el aviso y se realizan las pruebas. Si los registros están en un portal del proveedor, ¿puede la organización exportarlos durante un incidente? Estas no son cuestiones abstractas de soberanía. Son cuestiones de seguridad porque determinan si la organización puede controlar y explicar el sistema bajo presión.
Una colocación incorrecta puede encarecer el comportamiento seguro. Si cada paso de verificación requiere un viaje de ida y vuelta remoto, los equipos pueden muestrear en lugar de revisar cada caso. Si los datos de auditoría son difíciles de combinar, las investigaciones se vuelven lentas. Si los datos privados deben viajar para una clasificación simple, el riesgo aumenta sin beneficio. Un buen diseño de localidad reduce el coste de hacer lo seguro. Esto importa porque los controles que son demasiado caros acabarán describiéndose como opcionales, que es como empiezan muchas malas historias.
La evaluación tiene que seguir al sistema
Muchos equipos evalúan el modelo y olvidan evaluar el sistema. Prueban si las respuestas son correctas en un conjunto de indicaciones y luego despliegan en un flujo de trabajo con permisos, frescura de las fuentes, colas, llamadas a herramientas, revisión humana, reintentos y políticas cambiantes. La referencia del modelo puede seguir siendo útil, pero ya no describe todo el riesgo. Los fallos de seguridad suelen vivir en las uniones.
Una evaluación del sistema prueba el comportamiento de extremo a extremo. Pregunta si se recupera la fuente correcta para el usuario correcto. Comprueba si se rechazan los datos obsoletos. Verifica que las llamadas a herramientas se bloqueen sin permiso. Mide si los casos de alto riesgo llegan a los humanos. Prueba la reversión. Prueba el retraso de las colas. Prueba las rutas de actualización del modelo. Prueba casos extraños pero comunes: fecha ausente, cliente duplicado, excepción regional, apelación tras corrección, eliminación de fuente, interrupción parcial, revisor sobrecargado. La producción tiene predilección por los casos que nadie consideró lo bastante dramáticos.
La evaluación debe incluir capacidad negativa. El sistema debe ser bueno para no hacer cosas. No responder sin evidencia. No cruzar límites de permisos. No escalar a la acción cuando solo se permite redactar. No ocultar la incertidumbre. No usar una fuente después de su eliminación. No continuar cuando una herramienta devuelve un estado inconsistente. La seguridad depende tanto del rechazo y la pausa como de la precisión. La salida más importante de un sistema de IA seguro puede ser evidencia insuficiente, que es una frase que ningún equipo de demostración pone en un cartel.
La evaluación del sistema también cambia la gestión de lanzamientos. Un cambio de indicación, un cambio de modelo, una reconstrucción del índice, una actualización de política, un cambio de permisos de herramientas o un cambio en la interfaz del revisor pueden alterar la seguridad. Cada uno necesita un alcance de prueba y un plan de reversión. El equipo debe saber qué comportamientos cambiaron y qué riesgos aumentaron. Esto es tedioso de la misma manera que los cinturones de seguridad lo son. Solo se vuelve interesante cuando falta, y entonces ya es demasiado tarde para estar tranquilo.
La lección
La seguridad de la IA es sobre todo diseño de sistemas porque el daño suele viajar a través de los sistemas. Una salida del modelo se vuelve arriesgada cuando un flujo de trabajo confía demasiado en ella, una puerta de enlace de herramientas es demasiado amplia, falta evidencia, el estado es vago, la revisión está sobrecargada, los registros son débiles o la reversión es imaginaria. El modelo puede ser la fuente visible de la frase, pero el sistema decide si la frase se convierte en acción.
Esta vista es menos dramática que muchos debates sobre seguridad de la IA, y más útil para las organizaciones que despliegan sistemas ahora. Pide a los equipos que tracen límites, nombren la autoridad, conserven pruebas, diseñen estados, ubiquen el trabajo deliberadamente, evalúen de principio a fin y den a los humanos poder real. Trata el modelo como un componente potente en un caso de seguridad, no como todo el caso de seguridad. Esa es la postura adulta. También da a los ingenieros algo que construir además de otro PDF de políticas, lo cual es amable con todos.
La pregunta del responsable de seguridad tras la demo fue exactamente la correcta. ¿Qué ocurre si el modelo se equivoca pero resulta convincente? Un sistema seguro debería tener una respuesta: aquí solo puede redactar, allí debe citar fuentes actuales, no puede llamar a esa herramienta, este caso pasa a revisión, esta acción deja un recibo, este flujo de trabajo se puede pausar, este lanzamiento se puede revertir, esta decisión se puede impugnar. Esas respuestas no son sensaciones. Son diseño.
Siempre habrá incertidumbre en la IA. La tarea práctica es impedir que la incertidumbre se convierta en autoridad sin límites. Eso se logra con interfaces, estados, controles, pruebas, localidad, evaluación, recuperación y juicio humano debidamente equipado. En otras palabras, diseño de sistemas. No porque los valores no importen, sino porque los valores deben hacerse ejecutables antes de poder proteger a nadie.