Capítulo 1 — Sistemas informáticos

Mapa de la lección

Lección 01 publicada. Mapa, ejemplo, EX001.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["1.1 Capas"]
  N2["1.2 Dónde residen los modelos"]
  N3["1.3 Recursos"]
  N4["1.4 Capas y controles"]
  N5["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX001"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["1.1 Capas"]
  N2["1.2 Dónde residen los modelos"]
  N3["1.3 Recursos"]
  N4["1.4 Capas y controles"]
  N5["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]

[Resultados de aprendizaje]
    |
    v
[1.1 Capas]
    |
    v
[1.2 Dónde residen los modelos]
    |
    v
[1.3 Recursos]
    |
    v
[1.4 Capas y controles]
    |
    v
[Síntesis]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX001]

Resultados de aprendizaje

Usted podrá (1) describir las capas de hardware y software sobre las que funciona un servicio de IA; (2) explicar dónde residen los modelos, los pesos y los datos en tiempo de ejecución; (3) identificar los recursos informáticos que un atacante puede agotar; y (4) relacionar las capas del sistema con los controles de seguridad de la IA.

1.1 Capas

Un asistente de tienda como Ask Brightwell no es «solo un modelo». Una petición atraviesa un navegador, un balanceador de carga, una aplicación web, un servicio de orquestación que construye el prompt, un servicio de recuperación, un servidor de modelos (a menudo la API de un proveedor) y servicios de herramientas como la base de datos de pedidos. Cada capa funciona sobre un sistema operativo, en hardware físico o virtual, y cada una tiene sus propias cuentas, registros y modos de fallo. El trabajo de seguridad empieza por dibujar estas capas. El primer dibujo que Jonas hizo de Ask Brightwell encontró un problema en una capa que nadie consideraba de IA: los registros del orquestador.

1.2 Dónde residen los modelos

Un modelo es un archivo de números (pesos) más el código que lo ejecuta. Cuando está autoalojado, los pesos están en disco, se cargan en memoria y suelen ejecutarse en GPU. Cuando se accede a él mediante una API, el proveedor los guarda y usted envía texto. En ambos casos, el prompt, los documentos recuperados y las salidas pasan por la memoria y los registros de sistemas que usted opera, lugares por donde pueden filtrarse datos sensibles. En Ask Brightwell los pesos permanecen en el proveedor, pero los prompts que construía el orquestador, incluidas las direcciones de clientes obtenidas por la herramienta de pedidos, estaban en un contenedor de registros compartido. Los archivos del modelo autoalojado de CodePilot, en cambio, residen en los discos de la propia Brightwell, donde las comprobaciones de integridad son tarea de Brightwell.

1.3 Recursos

La inferencia de los modelos de lenguaje es cara: cada petición consume tiempo y memoria de GPU en proporción a la longitud de la entrada y de la salida. Los atacantes que envían peticiones muy largas o muy numerosas pueden elevar los costes o denegar el servicio; OWASP lo recoge como LLM10 Unbounded Consumption (consumo ilimitado). Saber qué recurso es escaso —GPU, tokens, dinero— indica qué hay que limitar. En Ask Brightwell, el recurso escaso es el dinero: cada token enviado a la API del proveedor se factura, de modo que un punto de acceso sin límites permite que cualquiera dispare la factura. Por eso la primera propuesta de Jonas combinaba un límite de tasa de peticiones con un presupuesto diario de tokens por cuenta.

1.4 Capas y controles

Asigne los controles a las capas: autenticación en el perímetro, límites de tasa en la pasarela, construcción del prompt y tratamiento de las salidas en el orquestador, control de acceso en la recuperación y en las herramientas, comprobaciones de integridad de los archivos del modelo en disco y registros en todas partes. Para Ask Brightwell, el diagrama de Jonas muestra dónde está hoy cada control y dónde falta alguno. No había límite de tasa en la pasarela y los registros de prompts del orquestador podían leerlos 40 ingenieros, así que a dos capas les faltaban controles que el mapa hace evidentes. El servicio de políticas añadido más tarde pertenece a esa misma capa del orquestador, entre el modelo y las herramientas.

1.5 Ejemplo resuelto (caso sintético de Brightwell)

Jonas dibuja Ask Brightwell: navegador → CDN → aplicación web → orquestador → (índice de recuperación de 3000 páginas de políticas y productos; API del modelo del proveedor; herramientas de consulta de pedidos y de devoluciones) → bases de datos. Anota que el orquestador registra los prompts completos, incluidas las direcciones de clientes obtenidas por la herramienta de pedidos, en un contenedor de registros compartido que pueden leer 40 ingenieros. Lo añade a la lista de incidencias del equipo. El hallazgo no tiene nada que ver con el modelo: es un problema corriente de control de acceso en la capa de registro. Como los registros contienen direcciones que obtuvo la herramienta de pedidos, el contenedor se convirtió en uno de los mayores almacenes de datos de clientes del sistema sin que nadie lo decidiera.

1.6 Errores y límites

• Tratar el modelo como si fuera todo el sistema.
• Olvidar que los registros y las cachés son almacenes de datos.
• Ignorar el coste como objetivo de ataque.

El dibujo de Jonas protege contra los tres. Muestra el modelo como una caja entre muchas, incluye el contenedor de registros compartido como almacén de datos con direcciones de clientes y marca la API del proveedor como un coste que hay que proteger. Cada error, si no se hubiera corregido, habría dejado fuera de la lista de incidencias una debilidad real de Ask Brightwell. Los capítulos posteriores vuelven a cada capa con pruebas y controles.

Ejercicios

• EX001 — Diagrama de capas. Dibuje las capas de un chatbot de IA que use y etiquete un control por capa. Rúbrica: 3 = al menos seis capas con controles adecuados; 2 = cuatro o cinco; 1 = dos o tres; 0 = ninguna.
• EX002 — Dónde residen los datos. Enumere cuatro lugares donde podría almacenarse una dirección de cliente durante una petición a Ask Brightwell. Rúbrica: 3 = cuatro lugares plausibles; 2 = tres; 1 = uno o dos; 0 = ninguno.
• EX003 — Recurso escaso. En un modelo autoalojado, ¿qué recurso limitaría primero y cómo? Rúbrica: 3 = tiempo de GPU o tokens, límites por usuario y longitudes máximas; 2 = parcial; 1 = vago; 0 = ninguno.

Síntesis

Los servicios de IA son sistemas por capas. La seguridad empieza por cartografiar por dónde viajan las peticiones, los modelos y los datos, y qué recursos pueden agotar los atacantes.

Siga estudiando — capítulo 01 de 30

← Página del curso · Índice de capítulos del curso · Capítulo 02 (borrador) →